Этапы проектирования базы данных и их процедуры

Содержание

• 1. Этапы проектирования базы данных и их процедуры
  • 1. 1. Процедуры концептуального проектирования
  • 1. 2. Процедуры логического проектирования
  • 1. 3. Процедуры физического проектирования
• Список использованной литературы

1 Этапы проектирования базы данных и их процедуры

Проектирование базы данных осуществляется в три этапа:

1) концептуальное проектирование;

2) логическое проектирование;

3) физическое проектирование.

1.1 Процедуры концептуального проектирования

Цель этапа концептуального проектирования — создание концептуаль-ной модели данных исходя из представлений пользователей о предметной области. Для ее достижения выполняется ряд последовательных процедур.

1. Определение сущностей и их документирование. Для идентифи-кации сущностей определяются объекты, которые существуют независимо от других. Такие объекты являются сущностями. Каждой сущности присваива-ется осмысленное имя, понятное пользователям. Имена и описания сущно-стей заносятся в словарь данных. Если возможно, то устанавливается ожи-даемое количество экземпляров каждой сущности.

2. Определение связей между сущностями и их документирование. Определяются только те связи между сущностями, которые необходимы для удовлетворения требований к проекту базы данных. Устанавливается тип каждой из них. Выявляется класс принадлежности сущностей. Связям при-сваиваются осмысленные имена, выраженные глаголами. Развернутое описа-ние каждой связи с указанием ее типа и класса принадлежности сущностей, участвующих в связи, заносится в словарь данных.

3. Создание ER-модели предметной области. Для представления сущностей и связей между ними используются ER-диаграммы. На их основе создается единый наглядный образ моделируемой предметной области — ER-модель предметной области.

4. Определение атрибутов и их документирование. Выявляются все атрибуты, описывающие сущности созданной ER-модели. Каждому атрибуту присваивается осмысленное имя, понятное пользователям. О каждом атрибу-те в словарь данных помещаются следующие сведения: имя атрибута и его описание;

тип и размерность значений;

значение, принимаемое для атрибута по умолчанию (если такое имеется);

может ли атрибут иметь Null-значения;

является ли атрибут составным, и если это так, то из каких простых атрибутов он состоит. Например, атрибут «Ф.И.О. клиента» может состоять из простых атрибутов «Фамилия», «Имя», «Отчество», а может быть простым, содержащим единые значения, как-то «Сидорский Евгений Михайлович». Если пользователь не нуждается в доступе к отдельным элементам «Ф.И.О.», то атрибут представляется как простой;

является ли атрибут расчетным, и если это так, то как вычисляются его значения.

5. Определение значений атрибутов и их документирование. Для каждого атрибута сущности, участвующей в ER-модели, определяется набор допустимых значений и ему присваивается имя. Например, атрибут «Тип сче-та» может иметь только значения «депозитный», «текущий», «до востребова-ния», «карт-счет». Обновляются записи словаря данных, относящиеся к атри-бутам, -в них заносятся имена наборов значений атрибутов.

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

7. Обсуждение концептуальной модели данных с конечными поль-зователями. Концептуальная модель данных представляется ER-моделью с сопроводительной документацией, содержащей описание разработанной мо-дели данных. Если будут обнаружены несоответствия предметной области, то в модель вносятся изменения до тех пор, пока пользователи не подтвердят, что предложенная им модель адекватно отображает их личные представле-ния.

1.2 Процедуры логического проектирования

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

1. Выбор модели данных. Чаще всего выбирается реляционная модель данных в связи с наглядностью табичного представления данных и удобства работы с ними.

2. Определение набора таблиц исходя из ER-модели и их докумен-тирование. Для каждой сущности ER-модели создается таблица. Имя сущ-ности — имя таблицы. Осуществляется формирование структуры таблиц на основании изложенных в параграфе 1.4 правил. Устанавливаются связи меж-ду таблицами посредством механизма первичных и внешних ключей. Струк-туры таблиц и установленные связи между ними документируются.

3. Нормализация таблиц. Для правильного выполнения нормализации проектировщик должен глубоко изучить семантику и особенности использо-вания данных. На этом шаге он проверяет корректность структуры таблиц, созданных на предыдущем шаге, посредством применения к ним процедуры нормализации. Эта процедура была описана в параграфе 1.5. Она заключает-ся в приведении каждой из таблиц, по крайней мере, к ЗНФ. В результате нормализации получается очень гибкий проект базы данных, позволяющий легко вносить в нее нужные расширения.

4. Проверка логической модели данных на предмет возможности выполнения всех транзакций, предусмотренных пользователями. Тран-закция это набор действий, выполняемых отдельным пользователем или прикладной программой с целью изменения содержимого базы данных. Так, примером транзакции в проекте БАНК может быть передача права распоря-жаться счетами некоторого клиента другому клиенту. В этом случае в базу данных потребуется внести сразу несколько изменений. Если во время вы-полнения транзакции произойдет сбой в работе компьютера, то база данных окажется в противоречивом состоянии, так как некоторые изменения уже бу-дут внесены, а остальные еще нет. Поэтому все частичные изменения долж-ны быть отменены для возвращения базы данных в прежнее непротиворечи-вое состояние.

Перечень транзакций определяется действиями пользователей в предметной области. Используя ER-модель, словарь данных и установленные связи между первичными и внешними ключами, производится попытка вы-полнить все необходимые операции доступа к данным вручную. Если какую-либо операцию выполнить вручную не удается, то составленная логическая модель данных является неадекватной и содержит ошибки, которые надо устранить. Возможно, они связаны с ропуском в модели сущности, связи или атрибута.

5. Определение требований поддержки целостности данных и их документирование. Эти требования представляют собой ограничения, кото-рые вводятся с целью предотвратить помещение в базу данных противоречи-вых данных. На этом шаге вопросы целостности данных освещаются безот-носительно к конкретным аспектам ее реализации. Должны быть рассмотре-ны следующие типы ограничений: обязательные данные. Выясняется, есть ли атрибуты, которые не могут иметь Null-значений;

ограничения для значений атрибутов. Определяются допустимые значе-ния для атрибутов;

целостность сущностей. Она достигается, если первичный ключ сущности не содержит Null-значений;

ссылочная целостность. Она понимается так, что значение внешнего клю-ча должно обязательно присутствовать в первичном ключе одной из строк таблицы для родительской сущности;

ограничения, накладываемые бизнес-правилами. Например, в случае с проектом БАНК может быть принято правило, запрещающее клиенту рас-поряжаться, скажем, более чем тремя счетами.

Сведения обо всех установленных ограничениях целостности данных помещаются в словарь данных.

5. Создание окончательного варианта логической модели данных и обсуждение его с пользователями. На этом шаге подготавливается оконча-тельный вариант ER-модели, представляющей логическую модель данных. Сама модель и обновленная документация, включая словарь данных и реля-ционную схему связи таблиц, представляется для просмотра и анализа поль-зователям, которые должны убедиться, что она точно отображает предмет-ную область.

1.3 Процедуры физического проектирования

Цель этапа физического проектирования — описание конкретной реали-зации базы данных, размещаемой во внешней памяти компьютера. Это опи-сание структуры хранения данных и эффективных методов доступа к данным базы. При логическом проектировании отвечают на вопрос — что надо сде-лать, а при физическом — выбирается способ, как это сделать. Процедуры фи-зического проектирования следующие.

1. Проектирование таблиц базы данных средствами выбранной СУБД. Осуществляется выбор реляционной СУБД, которая будет использо-ваться для создания базы данных, размещаемой на машинных носиелях. Глубоко изучаются ее функциональные возможности по проектированию таблиц. Затем выполняется проектирование таблиц и схемы их связи в среде СУБД. Подготовленный проект базы данных описывается в сопровождаемой документации.