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

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

• из каких отношений должна состоять база данных;
• какие атрибуты должны быть у этих отношений;
• какие ограничения должны быть наложены на атрибуты и отношения базы данных, чтобы обеспечить ее целостность.

Требования к выбранному набору отношений и составу их атрибутов должны удовлетворять следующим условиям:

• отношения должны отличаться минимальной избыточностью атрибутов;
• выбранные для отношения первичные ключи должны быть минимальными;
• между атрибутами не должно быть нежелательных функциональных зависимостей;
• выбор отношений и атрибутов должен обеспечивать минимальное дублирование данных;
• не должно быть трудностей при выполнении операций включения, уда-ления и модификации данных;
• время выполнения запросов на выборку данных (см. описание запросов из варианта задания учебного пособия "Введение в проектирование реляционных баз данных") должно удовлетворять предъявляемым требованиям;
• перестройка набора отношений при введении новых типов должна быть минимальной.

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

Процесс получения реляционной схемы базы данных из ER-диаграммы включает следующие шаги:

1. Каждая простая сущность превращается в отношение. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем отношения.

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

3. Компоненты уникального идентификатора сущности превращаются в первичный ключ отношения. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый.

4. Связи M:1 (и 1:1) становятся внешними ключами. Для этого делается копия уникального идентификатора с конца связи "один" и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.

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

6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:

При применении способа (а) таблица создается для наиболее внешнего супертипа. В таблицу добавляется по крайней мере один столбец, содержащий код ТИПА, и он становится частью первичного ключа. Для работы с подтипами могут создаваться представления. При использовании метода (б) супертип воссоздается с помощью конструкции UNION.

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

Выделяют три группы правил целостности:

• целостность по сущностям;
• целостность по ссылкам;
• целостность, определяемая пользователем.

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

По способам реализации ограничения целостности делятся на:

• декларативные, выполняемые средствами языка SQL;
• процедурные, выполняемые посредством триггеров и хранимых процедур.

При выполнении этой лабораторной работы в процессе построения реляционной модели данных должны быть обеспечены декларативные ограничения целостности. Заданию процедурных ограничений целостности посвящена лабораторная работа 14. Декларативные ограничения целостности должны обеспечивать:

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

Последовательность выполнения лабораторной работы:

1. Изучить вопросы теории нормализации, условия нахождения отношения в той или иной нормальной форме

2. Выполнить процедуру построения реляционной модели данных из ER-модели, построив необходимый набор отношений. Определить состав атрибутов отношений.

Определить первичные и внешние ключи отношений.

Выполнить шаги по нормализации полученных отношений, приведя модель к третьей нормальной форме.

5. Задать необходимые декларативные ограничения целостности исходя из специфики предметной области.

6. Представить связи между первичными и внешними ключами в виде вертикальной диаграммы.

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

8. На языке SQL записать выражения для указанных в варианте задания запросов на выборку данных из созданной базы данных. Проверить работоспособность написанных запросов в интерактивном режиме.

9. Оформить следующие разделы отчета:

• "Логическое проектирование реляционной модели базы данных", включив в него информацию из пп. 2 - 6;
• "Типовые запросы на выборку данных", включив в него тексты запросов на языке SQL на выборку данных из созданной базы данных.

1. Каковы задачи, решаемые на этапе логического проектирования?
2. Каковы базовые свойства реляционной модели данных?
3. В чем состоят требования структурной части реляционной модели данных?
4. В чем состоят требования манипуляционной части реляционной модели данных?
5. В чем состоят требования целостной части реляционной модели данных?
6. Каковы общие свойства нормальных форм?
7. Что такое функциональная, функционально полная зависимость?
8. Каковы условия нахождения отношений в первой нормальной форме?
9. Каковы условия нахождения отношений во второй нормальной форме?
10. Каковы условия нахождения отношений в третьей нормальной форме?
11. Каковы условия нахождения отношений в третьей усиленной нормальной форме?
12. Что понимается под многозначной зависимостью?
13. Каковы условия нахождения отношений в четвертой нормальной форме?
14. Что понимается под понятием "проецирование без потерь"?
15. Каковы условия нахождения отношений в пятой нормальной форме?
16. В чем состоят общие требования обеспечения ограничений целостности?
17. Каковы средства задания ограничений целостности в языке SQL?