ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ МОДЕЛИ ДАННЫХ

Теоретические основы логического проектирования

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

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

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

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

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

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

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

· обязательные данные. Выясняется, есть ли атрибуты, которые не могут иметь Null-значений;

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

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

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

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

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

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

Определение отношений, атрибутов и их доменов, обеспечение целостности

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

Для каждой сущности создается таблица. Причем каждому атрибуту сущности соответствует столбец таблицы.

Правила генерации таблиц из ER-диаграмм опираются на два основных фактора – тип связи и класс принадлежности сущности. Изложим их.

Правило 1

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

Правило 2

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

Правило 3

Если связь типа 1: 1 и класс принадлежности обеих сущностей является необязательным, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

Правило 4

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

Правило 5

Если связь типа 1: М и класс принадлежности сущности на стороне М является необязательным, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

Правило 6

Если связь типа М: N, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

Сущности Поставщики книг, Книги, Покупатели концептуальной модели переходят в соответствующие отношения Поставщики книг, Книги, Получатели реляционной модели.

Характеристики каждой сущности переходят в соответствующие атрибуты. Уникальный идентификатор каждой сущности переходит в первичный ключ отношения.

В концептуальной модели между сущностями Покупатели и Счёт-фактура установлена связь «выписывается» мощности «один ко многим» и имеется обязательная степень принадлежности со стороны «многие» (условие правила 4), поэтому при переходе к реляционной модели:

· получаем два отношения Покупатели и Счёт-фактура;

· уникальный идентификатор каждой сущности переходит в первичный ключ соответствующего отношения;

· первичный ключ Код покупателя отношения Покупатели на стороне связи «один» включается как атрибут в отношение Счёт-фактуры со стороны связи «многие».

Так как для идентификации одной Счёт-фактуры достаточно её уникального номера, то первичный ключ сущности Покупатели не включается в состав первичного ключа сущности Счёт-фактуры. Поэтому связь является не идентифицирующей.

В концептуальной модели между сущностями Поставщики и Накладные установлена связь «выдаётся» мощности «один ко многим» и имеется обязательная степень принадлежности со стороны «многие» (условие правила 4), поэтому при переходе к реляционной модели:

· получаем два отношения Поставщики и Накладные;

· уникальный идентификатор каждой сущности переходит в первичный ключ соответствующего отношения;

· первичный ключ Код поставщика отношения Поставщики на стороне связи «один» включается как атрибут в отношение Накладные со стороны связи «многие».

Так как для идентификации одной Накладной достаточно её уникального кода, то первичный ключ сущности Поставщики не включается в состав первичного ключа сущности Накладные. Поэтому связь является не идентифицирующей.

В концептуальной модели между сущностями Счёт-фактуры и Книги установлена связь «содержат» мощности «многие ко многим» (условие правила 6), поэтому при переходе к реляционной модели:

· получаем три отношения Книги, Строки счёт-фактур и счёт-фактуры;

· уникальный идентификатор каждой сущности переходит в первичный ключ соответствующего отношения;

· первичный ключ Кодкниги отношения Книги на стороне связи «один» включается как атрибут в отношение Строки счёт-фактур со стороны связи «многие».

В этом случае, для идентификации одной строки ведомости, первичный ключ сущности Книги включается в состав первичного ключа сущности Строки счёт-фактуры и первичный ключ сущности Счёт-фактуры включается в состав первичного ключа сущности Строки счёт-фактуры. Поэтому связь является идентифицирующей.

В концептуальной модели между сущностями Накладные и Книги установлена связь «имеют» мощности «многие ко многим» (условие правила 6), поэтому при переходе к реляционной модели:

· получаем три отношения Книги, Строки накладных и накладные;

· уникальный идентификатор каждой сущности переходит в первичный ключ соответствующего отношения;

· первичный ключ Кодкниги отношения Книги на стороне связи «один» включается как атрибут в отношение Строки накладных со стороны связи «многие».

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

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

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

· Поставщики книг (КодПоставщика, НаимПоставщика, ИННпост, ЮрАдресПост, БанкПост, НомСчётаПост);

· Книги (КодКниги, Название, Автор, Издательство, ГодИзд, КолСтр, СтоимПриобр, КрСодерж, КомпактД);

· Накладные (КодНакл, КодПоставщика, ДатаНакл);

· Строки накладных (КодКниги, КодНакл, КоличествоКниг);

· Покупатели (КодПокупателя, НазвОрг, ЮрАдресПокуп, ИННпокуп, ФИО, БанкПокуп, НомСчётаПокуп, Телефон);

· Счёт-фактуры (УникНомер, КодПокупателя, Дата);

· Строки счёт-фактуры (КодКниги, УникНомер, Количество);

Определим множество допустимых значений для атрибутов отношений. Каждый атрибут может быть определен только на одном домене, но на каждом домене может быть определено множество атрибутов. В понятие домена входит не только тип данных, но и область значений данных.

Поскольку не должны выполняться математические операции со значениями атрибутов КодПоставщика, НаимПоставщика, ЮрАдресПост, БанкПост, КодКниги, Название, Автор, Издательство, КрСодерж, КодПокупателя, НазвОрг, ИННпокуп, НомСчётаПокуп, ЮрАдресПокуп, ФИО, БанкПокуп, УникНомер, ИННпост, НомСчётаПост, ГодИзд, КодНакл, Телефон то для этих атрибутов определим домен, состоящий из множества значений символьного типа данных.

Значение атрибутов КолСтр, СтоимПриобр, Количество, КоличествоКниг принадлежат домену с числовым (целые числа) типом данных,

Значение атрибута КомпактД принадлежат домену с типом данных Логический.

Значение атрибута Дата и ДатаНакл принадлежат домену с типом данных Дата (время).

⇐ Предыдущая 1 2 345 6 7 8 9 10 Следующая ⇒