Предисловие Системы управления базами данных (субд) – это программные комплексы, предназначенные для работы со специально организованными файлами (массивами данных, долговременно хранимыми во внешней памяти вычислительных систем), которые называются

Вид материала

Документы

Содержание II. Выбор программного обеспечения СУБД Инструментальные средства и возможности СУБД. Логическое проектирование Физическое проектирование 6.4.3. Реализация и загрузка данных Create table professor ( Class_days char(3) not null Grant use of table professor to prob I Производительность Физическая безопасность (physical security). Защита с помощью паролей (password security). Права доступа (access rights). Контрольные журналы (audit trails). Шифрование данных (data encryption). Бездисковые рабочие станции (diskless workstation). Резервное копирование и восстановление Стандарты компании Управление параллельным выполнением операций Но процесс В все еще оперирует в памяти исходным значением в 500 единиц. 6.4.4. Тестирование и оценка ... Полное содержание

Подобный материал:

• Системы управления базами данных (субд). Назначение и основные функции, 30.4kb.
• Программа курса лекций "Базы данных в научных исследованиях", 49.32kb.
• Система управления базами данных это комплекс программных и языковых средств, необходимых, 150.5kb.
• Лекция 2 Базы данных, 241.25kb.
• Любая программа для обработки данных должна выполнять три основных функции: ввод новых, 298.05kb.
• Вопросы к государственному экзамену по специальности «Информационные системы и технологии», 39.93kb.
• Лекция № Технологии баз данных, 92.24kb.
• Проектирование базы данных, 642.58kb.
• Системы управления базами данных, 313.7kb.
• Программа дисциплины Системы управления базами данных Семестры, 22.73kb.

Проектирование распределенной базы данных

Фрагменты проекта базы данных могут физически находиться в разных места Процессы, требующие доступа к базе данных, также могут варьироваться в зависи­мости от их местонахождения. Например, процессы системы учета розничном тор­говли и процессы информационного хранилища, скорее всего, находятся в разных местах. Если процессы базы данных распределены по всей системе, проектировщик должен также разработать распределение данных и стратегии размещения базы дан­ных. Мы подробно исследуем сложности проектирования, возникающие при рас­пределенных процессах, в гл. 10.

II. Выбор программного обеспечения СУБД

Выбор программного обеспечения очень важен для успешного выполнения опера­ций информационной системы. Следовательно, преимущества и недостатки про­граммного обеспечения необходимо тщательно изучить. Конечный пользователь должен знать об ограничениях как СУБД, так и базы данных, чтобы избежать непредсказуемых результатов.

Хотя факторы, влияющие на решение о приобретении СУБД, разные в разных компаниях, все же можно выделить наиболее общие из них.

• Стоимость. Стоимость покупки, обслуживания, эксплуатации, лицензии, установки, обучения и конвертирования.
  
• Инструментальные средства и возможности СУБД. В программное обеспечение некоторых СУБД включены различные инструментальные средства, облегчающие разработку приложений. Например, выполнение запроса по образцу (QBE, Quer By Example), системы цветовой раскраски, генераторы отчетов, генераторы при­ложений, словари данных и т. д. помогают создать более привлекательную про­граммную среду как для пользователей, так и для прикладных программистов. Н. выбор СУБД оказывают влияние средства обеспечения администрирования БД обеспечения запросов, простоты использования, эффективности, безопасности. управления параллельным выполнением операций, обработки транзакций, а так­же поддержка программ сторонних фирм.
  
• Тип основной модели. Иерархическая, сетевая, реляционная, объектно-реляцион­ная или объектная.
  
• Переносимость. Независимость от платформы, операционной системы и языка.
  
• Требование СУБД к оборудованию. Процессор, RAM (оперативная память), дисковое пространство и т. д.
  

III. Логическое проектирование

Примеры логического проектирования, представленные в гл. 3, мы подробнее изу­чим в гл. 7 и 8. Логическое проектирование начинается после принятия решения об использовании определенной модели БД (иерархическая, сетевая или реляционная). После того как модель базы данных определена, можно отобразить концептуальное проектирование на логический проект, привязанный к выбранной модели БД. По­этому логическое проектирование является программно зависимым.

Логическое проектирование используется для перенесения концептуального проекта на внутреннюю модель выбранной системы управления базой данных (СУБД), на­пример, DB2, SQL Server, Oracle, IMS, Informix, Access и т. д. При этом все объекты отображаются на модель с определенной структурой, используемой выбранным программным обеспечением БД. Для реляционных СУБД логическое проектирова­ние включает в себя проектирование таблиц, индексов, представлений, транзакций, авторизации доступа и т. д. Далее мы конвертируем простую концептуальную мо­дель, представленную на рис. 6.11, в логический проект, основанный на реляцион­ной модели.



Рис. 6.11. Простая концептуальная модель⁴

Преобразование концептуальной модели, представленной на рис. 6. II, требует опре­деления доменов атрибута, проектирования необходимых таблиц и форматов огра­ничения доступа. Например, определения доменов для атрибутов CLASS_CODE, CLASS_DAYS и CLASS_TIME, представленных на рис. 6.11, можно записать так: CLASS_CODE (допустимый код группы)

Тип: числовой

Диапазон: мин. значение = 1000 макс, значение = 9999

Формат отображения: 9999

Длина: 4

⁴ Вы должны помнить из гл. 3, что генерируемая в Visio аббревиатура IE обозначает Inversion Entry (инвертированный компонент), определяемый в Visio как "неуникальный идентификатор доступа к сущности". Это означает, что внешний ключ не обязательно должен быть уникаль­ным. И поэтому так обозначается реализация "строгая сушность-слабая (неидентифицируемая) связь" (рис. 6.11). но "строгая (идентифицируемая) связь-слабая сущность" (см. рис. 6.7). Если сущность слабая, то FK представляет собой часть РК, поэтому он не может иметь пустое зна­чение или быть многозначным.

CLASS_DAYS (допустимое обозначение дня)

Тип: символьный

Допустимые значения: MWF, TTh, M, T, W, Th, F

Формат отображения: XXX

Длина: 3

CLASS_TIME (допустимое время) Тип: символьный

Формат отображения: 99:99 (24-часовой формат) Диапазон отображения: от 00:01 до 24:00 Длина: 5

Эти таблицы соответствуют сущностям PROFESSOR и CLASS, представленным га рис. 6.11, а столбцы таблицы соответствуют атрибутам этих сущностей (PROFJD. PROF_LNAME, PROF_FNAME, PROFJNITIAL, PROF_PHONE, CLASS_CODE. CLASSSECTION и т. д.). Например, первоначально схема таблицы PROFESSOR может выглядеть так, как представлено в табл. 6.5.

Таблица 6.5. Простая схема таблицы PROFESSOR



В процессе логического проектирования также должны быть определены права на пользование базой данных: кто будет иметь право использовать таблицы, какие уча­стки таблицы (или таблиц) доступны и каким пользователям. В реляционной среде для того, чтобы ответить на такие вопросы, требуется определить соответствующие представления и права доступа.

Короче говоря, логическое проектирование переводит программно-независимую концептуальную модель в программно-зависимую модель определением подходящих I доменов, необходимых таблиц и соответствующих ограничений на доступ. Теперь наступило время определить физические требования, позволяющие системе функ­ционировать в рамках выбранного оборудования.

IV. Физическое проектирование

Физическое проектирование представляет собой процесс определения характеристик хранилища данных и доступа к данным в БД. Свойства хранилища зависят от типа устройств хранения, типа доступа к данным, поддерживаемого системой, и от СУБД. На этапе физического проектирования определяется не только местоположе­ние данных на устройствах хранения, но и общая производительность системы.

Физическое проектирование является чисто технической задачей, более типичной для клиент-серверных архитектур и систем мэйнфреймов, чем для конфигураций персональных компьютеров. И все-таки даже в сложных системах с миникомпьюте- рамп и мэйнфреймами современное программное обеспечение БД берет на себя основную часть физического проектирования.

Физическое проектирование имело большое значение в устаревших иерархических и сетевых моделях, описанных в гл. 1. Реляционные БД более изолированы от физического уровня, чем старые модели. Все же несмотря на то, что в реляционной модели, как правило, сложные физические свойства скрыты от пользователя, они оказывают большое влияние на производительность реляционных БД. Производительность может определяться характеристиками устройства хранения, например, временем поиска, размером сектора (блока), размером буфера, числом пластин жесткого диска и количеством головок чтения/записи. Кроме того, на производительность реляционной базы данных и на время доступа к данным влияет такой фактор, как правильно созданный индекс.

Необходимо тщательно проанализировать даже тип данных запроса для того, чтобы определить оптимальный метод доступа, который удовлетворял бы установленным требованиям к приложению, объему хранимых данных и предполагаемой производительности. Некоторые СУБД автоматически резервируют пространство, необходимое для хранения определений БД и пользовательских данных на постоянном запоминающем устройстве. Это необходимо для гарантии хранения данных в последовательной форме и в одном месте, что уменьшает время доступа к данным и уве­личивает производительность системы.

Физическое проектирование становится еще более сложным, если данные распреде­лены по различным местам, поскольку эффективность будет определяться пропускной способностью средств связи.

С учетом Всех этих трудностей становится понятно, почему проектировщики при­ветствуют программное обеспечение, которое берет на себя большую часть работ, связанных с физическим проектированием.

В предыдущих разделах этой главы мы отдельно обсуждали логическое и физиче­ское проектирование. На самом деле, два этих процесса выполняются параллельно, таблица за таблицей (или файл за файлом). Логическое и физическое проектирова­ние также параллельно выполняются в рамках иерархической и сетевой модели. Та­кие действия требуют от проектировщика глубокого понимания программного и аппаратного обеспечения для того, чтобы использовать их с максимальной эффек­тивностью.

6.4.3. Реализация и загрузка данных

В большинстве современных СУБД, таких как DB2 фирмы IBM, Microsoft SQL Server или Oracle, реализация новой базы данных требует создания специальных структурных компонентов для хранения таблиц конечных пользователей. К таким компонентам относятся группа хранения (storage group), область таблиц (table space) и сами таблицы (рис. 6.12). Обратите внимание, что в области таблиц может находиться больше одной таблицы.




Рис. 6.12. Физическая организация среды базы данных DB2

Например, для реализации логического проекта в СУБД DB2 фирмы IBM потребуется выполнить следующие шаги.

Шаг 1. Создать группу хранения базы данных. Этот шаг (выполняемый системным администратором или SYSADM) необходим для баз данных, развертываемых на мэйнфреймах, например, для DB2. Другие СУБД могут создавать подобные груши хранения автоматически. При создании базы данных (см. Шаг 2) обязательно изучите справочное руководство вашей СУБД с тем, чтобы выяснить, нужно ли вам создавать группы хранения, и если это необходимо, то какой синтаксис команд npil этом используется.

Шаг 2. Создать в рамках группы хранения базу данных (также выполняется системным администратором).

Шаг 3. Назначить право на использование базы данных группе системного администратора (DBADM)⁵.

Шаг 4. Создать внутри базы данных область (области) таблиц (обычно выполняет

DBADM).

⁵ В других СУБД, упоминаемых в книге (не DB2), администратор базы данных называла I DBA.

Шаг 5. Создать таблицу (таблицы) внутри области таблиц (также обычно выполня-IhDBADM). Общий вид создания таблицы в SQL может выглядеть так:

CREATE TABLE PROFESSOR (

PROF _ID NUMBER NOT NULL,

PROF_LNAME CHAR (15) NOT NULL,

PR0F_PHONE CHAR (8),

PRIMARY KEY (PROF_ID) ) ;

CREATE TABLE CLASS (

CIASS_CODE NUMBER NOT NULL,

CLASS_SECTION NUMBER NOT NULL,
CLASS_DAYS CHAR(3) NOT NULL,

CUiSSJTIME CHAR (14) NOT NULL,

PROF_ID NUMBER, PRIMARY KEY (CLASS_CODE) , FOREIGN KEY (PROF_ID) REFERENCES PROFESSOR;

Шаг 6. Присвоить права области таблиц и самим таблицам, которые в них определены (еще одна обязанность DBADM). Права доступа могут быть ограничены пред­ставлениями, а не доступом к самим таблицам. Создание представлений не требует доступа к базе данных в реляционной среде, и представления предпочтительны с точки зрения обеспечения безопасности.

Права доступа к таблице с названием PROFESSOR могут быть предоставлены лицам с идентификационным именем PROB с помощью такой команды:

GRANT USE OF TABLE PROFESSOR TO PROB;

Вместо таблицы PROFESSOR можно использовать представление с именем PROF:

CREATE VIEW PROF SELECT PROF_LNAME FROM PROFESSOR;

После создания базы данных необходимо загрузить данные в таблицы. Если данные хранятся к этому моменту в формате, отличном от того, который требует СУБД, то перед загрузкой их необходимо преобразовать в подходящий формат.

При использовании иерархической модели реализация должна включать в себя язык определения данных (DDL) для каждой базы данных. Кроме того, иерархическая база данных, например, IMS, требует создания блоков спецификации программ (PSB, program specification block), чтобы программы могли получать доступ к базе данных.

При использовании сетевой модели требуется создание DDL, в который должны быть включены все типы записей, способы размещения, множества, способы вставки, вы­борки множеств и т. д. Сетевые базы данных также требуют использования языка описания физической организации (DMCL, device media control language) и всех необходимых представлений для того, чтобы программы могли получить доступ к БД.



Для вас, видимо, не стало неожиданностью то, что большинство операций, описанных в жизненном цикле базы данных (DBLC), напоминают операции жизней цикла разработки систем (SDLC). Все-таки именно SDLC представляет оперативную среду, в которой разрабатывается DBLC. Сводка всех схожих операций, выполняемых в среде SDLC и DBLC, представлена на рис. 6.13.



Приведенная сводка операций по реализации базы данных предполагает использование сложных СУБД. Все современные базы данных для мэйнфреймов и для архитектура клиент-сервер предлагают возможности, которые будут обсуждаться в дальнейшем, к времени написания этой книги лишь несколько баз данных для персональных компьюте­ров предлагали подобные возможности. Более сложные БД для персональных компью­теров, которые поддерживают такие возможности, как правило, происходят от БД р мэйнфреймов (например, DB2, Oracle и SQL Server в настоящее время используются! на персональных компьютерах).

В процессе реализации и загрузки данных также необходимо обратить внимание на производительность, безопасность, создание резервных копий и восстановление, I целостность, стандарты компании и управление параллельным выполнением. Эти I вопросы будут обсуждаться далее (эти проблемы также обсуждаются подробно в гл. 9и10).

I Производительность

Производительность базы данных это один из наиболее важных факторов для некоторых реализаций баз данных. Однако не у всех СУБД есть встроенные средства наблюдения за производительностью, что затрудняет оценку эффективности работы СУБД.

Оценка производительности затрудняется еще и тем, что отсутствуют стандартные система оценок определения эффективности баз данных. Производительность меняется в зависимости от оборудования и программного обеспечения. Естественно, размер базы данных также влияет на производительность: поиск по 10 кортежам, конечно же, выполняется быстрее, чем по 100 000.

К важным факторам, влияющим на производительность БД, относятся также пара­метры конфигурации системы и базы данных, такие как размещение данных, опре­деление путей доступа, использование индексов и размер буфера.

Хотя производительность очень важна, она не является единственным (и даже не самым главным) фактором оценки базы данных. Не менее важными являются про­блемы, которые мы будем обсуждать ниже.

Безопасность

Данные, хранящиеся в базе данных компании, должны быть защищены от неавто­ризованного доступа (нетрудно вообразить, что произойдет, если студенты получат доступ к базе данных студентов или сотрудник получит доступ к платежной ведомо­сти!). Следовательно, необходимо обеспечить (по крайней мере) следующие меро­приятия.

• Физическая безопасность (physical security). Разрешает физический доступ только авторизованным лицам. Поскольку физическая безопасность зависит от типа реализации БД, однако ее не всегда можно осуществить на практике. Например, исследовательская база данных университета не лучший пример физической безопасности. Существование больших мультисерверных, многотерминальных сетей часто не позволяет обеспечить физическую безопасность.
  

• Защита с помощью паролей (password security). Позволяет устанавливать права до­
  ступа определенным авторизованным пользователям. Защита с помощью паролей
  обычно осуществляется во время регистрации пользователя в системе.
  
• Права доступа (access rights). Могут быть установлены с помощью программного
  обеспечения БД. Права доступа могут ограничивать выполнение операций
  (CREATE, UPDATE, DELETE и т. д.) на предопределенных объектах, таких как
  базы данных, таблицы, представления, запросы и отчеты.
  
• Контрольные журналы (audit trails). Предоставляются СУБД для контроля нару­шений прав доступа.. Хотя контрольные журналы являются средством "пост­фактум", одно лишь их существование препятствует неавторизованному доступу.
  

• Шифрование данных (data encryption). Нужно для того, чтобы неавторизованные
  персоны, возможно, преодолевшие некоторые уровни защиты БД, не могли к
  пользовать данные напрямую.
  
• Бездисковые рабочие станции (diskless workstation). Позволяют конечным пользова­телям получать доступ к БД, не загружая какую-либо информацию на свою рабочую станцию.
  

Резервное копирование и восстановление

Своевременность информации — критично важная вещь в современном информа­ционном пространстве. К сожалению, в базах данных нередко происходит потеря информации вследствие непреднамеренного удаления, аварийного выключения пи­тания и т. д. Процедуры резервного копирования и восстановления являются своего рода предохранительным клапаном, позволяющим администратору БД обеспечил доступность и непротиворечивость данных.

Целостность

Целостность данных реализуется с помощью надлежащего использования прав! первичного и внешнего ключа.

Стандарты компании

Стандарты базы данных могут частично определяться специфическими требования­ми предприятия. Администратор БД должен реализовать и проводить в жизнь эти стандарты.

Управление параллельным выполнением операций

Эта функция позволяет получать одновременный доступ к БД при сохранении цело­стности данных. Ошибки управления параллельным выполнением могут сильно снизить эффективность базы данных. Рассмотрим сценарий, представленный в табл. 6.6:

1. Начальный хранимый запас = 500 единиц.
   

1. Процесс А уменьшает запас на 150 единиц; процесс В уменьшает запас еще на
   300 единиц.
   
2. Конечный запас должен быть равен 500 — 150 — 300 = 50. Однако если исполь­зовать неправильную последовательность, приведенную в табл. 6.6, в базе данных
   будет храниться неправильное значение 200.
   

Таблица 6.6. Необходимость управления параллельным выполнением операций



Табл. 6.6 показывает, что может произойти в базе данных при проведении транзакций. I Вот как можно описать последовательность транзакций, представленных в табл. 6.6.

1. В период Tl процесс А считывает доступный блок из 500 единиц.

2. В период Т2 процесс В считывает доступный блок до того, как процесс А уменьшит значение в БД на 150 единиц. То есть процесс В тоже "видит" в БД 500 единиц.

3.У В период ТЗ процесс А уменьшает значение в БД на 150 единиц и записывает оставшиеся 350 единиц в базу данных. Но процесс В все еще оперирует в памяти исходным значением в 500 единиц.

4. В период Т4 процесс В уменьшает значение в памяти на 300 единиц и готов за­писать в БД оставшиеся 200 единиц! Поскольку процесс В записывает в БД по­сле процесса А, то в БД будет записано значение (неправильное!) 200 единиц, которое будет использоваться в дальнейших транзакциях.

Такого сценария можно избежать с помощью алгоритма управления параллельным выполнением операций. В гл. 9 подробно описывается использование методов блокировки для управления параллельными операциями.

6.4.4. Тестирование и оценка

После того как данные загружены в БД, администратор БД тестирует и настраивает базу данных на оптимальную производительность, целостность, параллельный дос-туп и ограничения безопасности. Этап тестирования и оценки происходит парал­лельно с программированием приложений.

Программисты используют инструментарий БД для создания прототипов приложе­ний во время разработки программ. На этапе создания прототипов прикладным программистам особенно полезны такие инструментальные средства, как генераторы отчетов, генераторы экранов и генераторы меню.

Если реализация БД не отвечает некоторым системным критериям, то для ее улуч­шения можно применять некоторые специальные действия:

0 в целях повышения производительности проектировщик должен настроить спе­цифические системные параметры и параметры СУБД. Сведения по настойке та­ких параметров лучше всего искать в справочном руководстве по программному и аппаратному обеспечению;

• модифицировать физический проект (например, применение индексирования
  увеличивает производительность и облегчает позиционирование указателя);
  
• модифицировать логический проект;
  
• обновить или изменить программное обеспечение СУБД и/или аппаратную
  платформу.