Файл: Методичка-ЛАБЫ по Поектированию ИС.doc

СУЩНОСТЬ (атрибут 1, атрибут 2 , ..., атрибут n)

СВЯЗЬ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...] (атрибут 1,..., атрибут n).

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

1. Выделить необходимый набор сущностей, отражающих предметную область и информационные потребности пользователей.

2. Определить необходимый набор атрибутов каждой сущности, выделив идентифицирующие атрибуты.

3. Классифицировать атрибуты каждой сущности (описательные, указывающие, вспомогательные).

4. Определить сущности вида подтип/супертип, где это необходимо.

5. Определить связи между сущностями.

6. Проанализировав структуру связей, исключить избыточные.

7. Определить множественность и условность связей.

8. Дать формулировку связей с точки зрения каждой участвующей сущности.

9. Формализовать связи вида 1:1, 1:M, M:N.

10. Классифицировать сущности, разделив их на стержневые, ассоциативные, характеристические, обозначающие.

11. Построить ER-диаграмму модели базы данных.

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

13. Оформить раздел отчета "Инфологическое проектирование модели базы данных", включив в него информацию из пп. 1 - 12.

Контрольные вопросы

1. Каковы задачи, решаемые на этапе инфологического проектирования?

2. В чем состоит отличие понятия типа сущности и элемента сущности?

3. Каковы способы представления сущности?

4. Каковы правила атрибутов?

5. Как классифицируются атрибуты?

6. Что такое безусловная, условная, биусловная, рекурсивная связь?

7. Каковы фундаментальные виды связей?

8. Как формализуется связь 1:1?

9. Как формализуется связь 1:M?

10. Как формализуется связь M:N?

11. Что такое подтип и супертип?

12. Что такое композиция связей?

Лабораторная работа 13

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

Цель работы

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

Содержание работы и методические указания

к ее выполнению

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

• из каких отношений должна состоять база данных;

• какие атрибуты должны быть у этих отношений;

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

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

• отношения должны отличаться минимальной избыточностью атрибутов;

• выбранные для отношения первичные ключи должны быть минимальными;

• между атрибутами не должно быть нежелательных функциональных зависимостей;

• выбор отношений и атрибутов должен обеспечивать минимальное дублирование данных;

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

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

• перестройка набора отношений при введении новых типов должна быть минимальной.

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

Процесс получения реляционной схемы базы данных из 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?