- •Проектирование баз данных. Лекция 1. Введение. Банки и базы данных. Архитектура субд.
- •Хранимая база данных (Внутренняя модель)
- •Понятие проектирования баз данных. Различные подходы к проектированию бд.
- •Различные подходы к проектированию данных.
- •Сетевая модель данных.
- •Лекция 2.
- •Реляционные операции над отношениями.
- •Лекция 3. Аномалии хранения данных.
- •Функциональная зависимость.
- •Концептуальное проектирование данных. Нормализация. Понятие функциональной зависимости. Теорема Хита.
- •Теорема Хита.
- •Лекция 4. Пятая нф. Универсальное отношение. I и II нф.
- •Первая нормальная форма.
- •Вторая нормальная форма.
- •Третья нормальная форма. Транзитивные зависимости.
- •Лекция 5. Нормальная форма Бойса-Кодда. Четвертая нормальная форма. «Перенормализованные» модели данных.
- •Четвертая нормальная форма.
- •«Перенормализованные» модели данных.
- •Пример проектирования бд.
- •Отношение “Аптека”
- •Отношение “Лекарство”
- •Отношение “Наличие лекарств”
- •Отношение “Поставщик”
- •Отношение “Лицензия поставщика”
- •Отношение “Запрос на поставку”
- •Лекция 6. Проектирование в терминах «Сущность – связь»
- •Сущности и связи.
- •Классификация связей
- •Предварительные отношения для бинарных связей степени 1:1.
- •Лекция 7. Предварительные отношения для степени связи 1:n и m:n.
- •Предварительные отношения для степени связи m:n.
- •Лекция 14. Предварительные отношения для связей высших порядков. Использование ролевых отношений.
- •Студент
- •Использование ролевых отношений.
- •Рабочий
- •Подчиненный
- •Лекция 8. Развитой пример применения e-r проектирования.
- •Сопоставление методик нормализации и e-r проектирования. Физическое проектирование.
- •Физическое проектирование.
- •Ограничения целостности.
- •Заключение.
Отношение “Аптека”
№ п/п |
Имя атрибута |
Содержание |
Тип поля |
Длина
|
Дес. знаков |
1 |
No_Apt |
Номер аптеки - идентифицирует аптеку |
Numeric |
4 |
0 |
2 |
Adr_Apt |
Адрес аптеки |
Character |
128 |
|
Таблица 4
Отношение “Лекарство”
№ п/п |
Имя атрибута |
Содержание |
Тип поля |
Длина
|
Дес. Знаков |
3 |
Kod |
Код лекарственного средства |
Numeric |
9 |
0 |
4 |
Name |
Наименование лекарственного средства |
Character |
50 |
|
5 |
Pack |
Вид упаковки лекарственного средства |
Character |
20 |
|
8 |
Ed |
Единицы измерения лекарственного средства |
Character |
5 |
|
9 |
Price |
Цена за единицу измерения лекарственного средства |
Numeric |
10 |
0 |
Таблица 5
Отношение “Наличие лекарств”
№ п/п |
Имя атрибута |
Содержание |
Тип поля |
Длина
|
Дес. Знаков |
1 |
No_Apt |
Номер аптеки - идентифицирует аптеку |
Numeric |
4 |
0 |
3 |
Kod |
Код лекарственного средства |
Numeric |
9 |
0 |
6 |
Amount |
Остаток лекарственного средства в аптеке |
Numeric |
10 |
3 |
7 |
Amount_N |
Нормативное количество лекарственного средства |
Numeric |
10 |
3 |
Таблица 6
Отношение “Поставщик”
№ п/п |
Имя атрибута |
Содержание |
Тип поля |
Длина
|
Дес. знаков |
10 |
GNI |
Код ГНИ поставщика |
Numeric |
9 |
0 |
11 |
Salor |
Наименование поставщика |
Character |
200 |
|
Таблица 7
Отношение “Лицензия поставщика”
№ п/п |
Имя атрибута |
Содержание |
Тип поля |
Длина
|
Дес. знаков |
3 |
Kod |
Код лекарственного средства |
Numeric |
9 |
0 |
10 |
GNI |
Код ГНИ поставщика |
Numeric |
9 |
0 |
12 |
Lic |
№ лицензии поставщика для работы с данным лекарственным средством |
Character |
20 |
|
Таблица 8
Отношение “Запрос на поставку”
№ п/п |
Имя атрибута |
Содержание |
Тип поля |
Длина
|
Дес. знаков |
1 |
No_Apt |
Номер аптеки - идентифицирует аптеку |
Numeric |
4 |
0 |
3 |
Kod |
Код лекарственного средства |
Numeric |
9 |
0 |
10 |
GNI |
Код ГНИ поставщика |
Numeric |
9 |
0 |
13 |
DocNum |
№ требования на поставку лекарственного средства |
Numeric |
5 |
0 |
14 |
Volume |
Объем поставки лекарственного средства |
Numeric |
10 |
0 |
Примечание. В таблицах 3..8 в графе “№ п/п” сохранена нумерация, принятая в таблице 1.
Третья нормальная форма. Возможной причиной избыточности информации для отношения, находящегося во II НФ является наличие транзитивных зависимостей, т.е. зависимости, от атрибутов, не вошедших в первичный ключ. Анализируя отношения, представленные в таблицах 3..8, приходим к выводу, что в данном случае отсутствуют транзитивные функциональные зависимости и построив II НФ мы тем самым построили и III НФ.
НФБК. По определению отношение находится в НФБК, если каждый детерминант является первичным ключом. Представленные отношения удовлетворяют этому требованию и, следовательно, находятся в НФБК.
Принято считать, что для решения практических задач достаточно, если отношения, включенные в информационную модель, находятся в НФБК [2]. Тем не менее, проведем анализ на соответствие модели высшим нормальным формам.
IV и V нормальные формы. Поскольку отсутствуют многозначные зависимости, можно утверждать, что все отношения соответствуют требованиям IV НФ. [1]
Анализ атрибутов показывает, что любые две проекции любого из перечисленных отношений будут содержать общий ключ - кандидат, следовательно, все эти отношения находятся и в V НФ, в соответствии с ее формулировкой в [2] .
На этом построение концептуальной модели данных можно считать законченным.