Агентство недвижимости

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

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

2.3.3. Нормализация модели

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

Нормализация осуществляется путем разбиения одного отношения  на два или более.

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

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

Проблемы:

1. Вставки. Необходимо вставить в отношение кортеж, в котором не все значения на момент вставки известны.
2. Обновления. Если в базе содержится много избыточных данных, то необходимо одновременно обновлять все данные.
3. Удаление. При удалении кортежа по какому-то атрибуту может быть потеряна полезная информация об объекте, который описан в этом кортеже.
4. Избыточности. Эта проблема связана с проблемой обновления и удаления.

Нормализация позволяет  снять все перечисленные проблемы. Для того, чтобы провести нормализацию модели, нужно отношения преобразовать  в третью нормальную форму.

Нормальная  форма – отношение с дополнительными ограничениями на хранящиеся в нем значения.

Рассмотрим три вида нормальных форм (НФ) отношений:

1. Первая нормальная форма (1НФ)

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

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

2. Вторая нормальная форма (2НФ)

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

3. Третья нормальная форма (3НФ)

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

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

На основе ранее выделенных сущностей определим отношения  и приведем их в 3НФ:

1. Личные данные пациента (Код больного, Фамилия, Имя, Отчество, Дата Рождения, Телефон)

 

 

 

Выделим функциональные зависимости:

 Код больного

Фамилия

 Имя  

Отчество

Дата Рождения

Телефон

Каждый из реквизитов функционально зависит от уникально  идентификатора – ключа Код больного.

Отношение находится  в 3НФ, так как каждый реквизит имеет  атомарное значение (1НФ), нет неполных функциональных (2НФ) и транзитивных зависимостей (3 НФ).

2. Врачи (Код врача, Фамилия, Имя, Отчество, Дата рождения, Специализация, Телефон)

Выделим функциональные зависимости:

 Код врача

Фамилия

Имя

Отчество 

Дата рождения

Специализация

Телефон

Каждый из реквизитов функционально зависит от уникально  идентификатора – ключа Код врача.

Отношение находится  в 3НФ, так как каждый реквизит имеет атомарное значение (1НФ), нет неполных функциональных (2НФ) и транзитивных зависимостей (3 НФ).

 

 

 

3. Процедура (Код процедуры, процедура)

Выделим функциональные зависимости:

 Код процедуры

процедура

Каждый из реквизитов функционально зависит от уникально идентификатора – ключа Код процедуры.

Отношение находится  в 3НФ, так как каждый реквизит имеет  атомарное значение (1НФ), нет неполных функциональных (2НФ) и транзитивных зависимостей (3 НФ).

4. Пациент (Код больного, Код отделения, Код палаты, Код врача, Код заболевания, Код препарата, Дата поступления, Дата выписки, Код операции, Код процедуры)

Выделим функциональные зависимости:

Код больного

Код отделения

Код палаты

Код врача

Код заболевания

Код препарата

Дата поступления

Дата выписки

Код операции

Код процедуры

Отношение находится  в 3НФ, так как каждый реквизит имеет  атомарное значение (1НФ), нет неполных функциональных (2НФ) и транзитивных зависимостей (3 НФ).

5. Отделение (Код отделения, Название)

Выделим функциональные зависимости:

 Код отделения

 Название

Каждый из реквизитов функционально зависит от уникально  идентификатора – ключа Код отделения.

Отношение находится  в 3НФ, так как каждый реквизит имеет  атомарное значение (1НФ), нет неполных функциональных (2НФ) и транзитивных зависимостей (3 НФ).

6. Палата (Код палаты, Номер)

Выделим функциональные зависимости:

Код палаты

Номер

Каждый из реквизитов функционально зависит от уникально  идентификатора – ключа Код палаты.

Отношение находится  в 3НФ, так как каждый реквизит имеет  атомарное значение (1НФ), нет неполных функциональных (2НФ) и транзитивных зависимостей (3 НФ).

7. Заболевания (Код заболевания, Заболевание)

Выделим функциональные зависимости:

Код заболевания

Заболевание

Каждый из реквизитов функционально зависит от уникально  идентификатора – ключа Код заболевания.

Отношение находится  в 3НФ, так как каждый реквизит имеет  атомарное значение (1НФ), нет неполных функциональных (2НФ) и транзитивных зависимостей (3 НФ).

8. Препараты (Код препарата, Наименование)

Выделим функциональные зависимости:

 Код препарата

Наименование

Каждый из реквизитов функционально зависит от уникально  идентификатора – ключа Код препарата.

Отношение находится  в 3НФ, так как каждый реквизит имеет  атомарное значение (1НФ), нет неполных функциональных (2НФ) и транзитивных зависимостей (3 НФ).

9. Операции (Код операции, Наименование)

Выделим функциональные зависимости:

 Код операции

Наименование

Каждый из реквизитов функционально зависит от уникально  идентификатора – ключа Код операции.

Отношение находится  в 3НФ, так как каждый реквизит имеет атомарное значение (1НФ), нет неполных функциональных (2НФ) и транзитивных зависимостей (3 НФ).

Определим связи между  объектами:

Рассмотрим связи между  информационными объектами и  типами отношений, которыми они характеризуется, для нашей предметной области.

1. Установим связь между объектами Личные данные пациента Пациент. Такая связь характеризуется отношением 1:1 (один к одному), поскольку у каждого пациента свои данные.
2. Связь между объектами Врачи и Пациенты характеризуется отношением 1:М (один ко многим), так как у одного врача может быть несколько пациентов.
3. Связь между объектами Процедура и Пациент характеризуется отношением 1:1,так как каждому пациенту назначена своя процедура.
4. Связь между объектами Операция и Пациент характеризуется отношением 1:1, как и в предыдущем случае.
5. Связь между объектами Отделения и Пациенты характеризуется отношением 1:М (один ко многим), так как пациент может лежать в любом отделении.
6. Связь между объектами Палата и Пациенты характеризуется отношением 1:М (один ко многим), как и в предыдущем случае.
7. Связь между объектами Заболевания и Пациенты характеризуется отношением 1:М (один ко многим), как и в предыдущем случае.
8. Связь между объектами Препараты и Пациенты характеризуется отношением 1:М (один ко многим), как и в предыдущем случае.

2.3.4 Проектирование реляционной  модели на основе концептуальной

Основное требование: каждый неключевой атрибут должен встречаться  только в одном отношении.

1. Реализация бинарной связи 1:1 (связь необязательная)

1.

     Код процедуры    Код процедуры

2. Личные данные пациента (Код больного, … .);

    Пациент (Код  больного, … .).

3. Операция (Код операции, … .);

    Пациент (Код  операции, … .).

2. Реализация бинарной связи 1:М:

В этом случае для каждой сущности создается отдельное отношение. Ключ сущности с необязательной связью добавляется в другое отношение в качестве внешнего ключа.

К таким сущностям относятся:

Код врача              Код врача

2. Отделения (Код Отделения, … );

Пациент (Код Отделения, … );

 

3. Палата (Код палаты, … );

Пациент (Код палаты, … );

4. Заболевания (Код заболевания, … );

Пациент (Код заболевания, … );

5.  Операция (Код операции, … .);

     Пациент  (Код операции, … .).

 

3.ФИЗИЧЕСКИЙ УРОВЕНЬ ПРОЕКТИРОВАНИЯ

Исходные данные для  физического проектирования:

1. Логическая модель, которая представляет собой полностью нормализованные сущности, т.е.:
1. Каждая сущность имеет первичный ключ;
2. Все атрибуты атомарные и не являются частью списка значений;
3. Каждая сущность содержит атрибуты, которые полностью зависят от первичного ключа.
2. Особенности СУБД.

Объекты БД, физические структуры  данных и файлов, способы поддержки  ссылочной целостности ограничений.

3.1. Переход от реляционной модели  к физической

3.1.1 Преобразование отношений в таблицы

Каждому отношению ставится в соответствии таблица. Имя таблицы  может совпадать с именами  отношения, если оно не противоречит требованиям СУБД, и корпоративным  правилам формирования имен (рис. 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10)

 

Преобразование отношения Врачи в таблицу

Рис 3.1

 

 

Преобразование отношения Заболевания в таблицу

Рис 3.2

 

Преобразование отношения Личные данные пациента в таблицу

Рис 3.3

 

 

 

 

 

 

 

Преобразование отношения Операция в таблицу

Рис 3.4

 

Преобразование отношения Отделения в таблицу

Рис 3.5

 

 

 

 

 

 

 

 

 

Преобразование отношения  Палата в таблицу

Рис 3.6

Преобразование отношения  Пациент в таблицу