- •1. Требования, предъявляемые к базе данных
- •2. Этапы жизненного цикла базы данных
- •3. Модель "сущность–связь"
- •4. Преобразование er- модели в реляционную
- •Правило 1
- •Менеджер–филиал
- •Правило 2
- •Правило 3
- •Правило 4
- •Связь между указанными таблицами будет иметь вид ф 1 илиал филиал-заказ
- •Правило 5
- •Правило 6
- •Филиал филиал-заказ
- •5 Общие сведения о case-средствах.
- •5.1 Нормализация данных в реляционных таблицах
- •6.1. Процедуры концептуального проектирования
- •6.3. Процедуры физического проектирования
5.1 Нормализация данных в реляционных таблицах
Нормализация представляет собой процесс реорганизации данных в реляционных таблицах путем ликвидации повторяющихся групп и иных противоречий в хранении данных с целью приведения таблиц к виду, позволяющему осуществить корректное редактирование данных.
Таблица находится в той или иной нормальной форме, если она удовлетворяет определенному набору требований.
Теоретически существуют 5 нормальных форм, хотя на практике используются три нормальные формы, которые рассмотрим более подробно.
Первой нормальной формой называется реляционная таблица, в которой все значения полей являются атомарными, т.е. любая реляционная база данных находится в первой нормальной форме.
Реляционная таблица соответствует второй нормальной форме, если она находится в первой нормальной форме, и ее не ключевые поля зависят от первичного ключа.
Реляционная таблица соответствует третьей нормальной форме, если в таблице не имеется транзитивных зависимостей между не ключевыми полями, т.е. значение любого поля таблицы, не входившего в первичный ключ, не зависит от значения другого поля, не входившего в первичный ключ.
Первая нормальная форма.
Предположим, что сначала все заказы клиентов были сведены в одну таблицу ЗаказИнфо:
ЗаказИнфо
Номер заказа |
Код клиента |
Город |
Улица |
Вес заказа |
Дата заказа |
Код валюты |
Наименование валюты |
1021 |
АА |
Минск |
Правды 11 |
100 |
01.02.06 |
100 |
Бел рубль |
1022 |
АА |
Минск |
Правды 11 |
150 |
01.02.06 |
100 |
Бел рубль |
1023 |
АС |
Пуховичи |
Широкая 1 |
300 |
10.03.06 |
101 |
Росс рубль |
1024 |
АС |
Пуховичи |
Широкая 1 |
400 |
11.03.06 |
101 |
Росс рубль |
1025 |
АС |
Пуховичи |
Широкая 1 |
700 |
12.03.06 |
103 |
Евро |
1026 |
АС |
Пуховичи |
Широкая 1 |
230 |
10.03.06 |
101 |
Росс рубль |
1027 |
АС |
Пуховичи |
Широкая 1 |
120 |
15.04.06 |
101 |
Росс рубль |
1028 |
АС |
Пуховичи |
Широкая 1 |
100 |
15.04.06 |
102 |
Доллар США |
1029 |
АС |
Пуховичи |
Широкая 1 |
300 |
15.04.06 |
101 |
Росс рубль |
1030 |
АВ |
Мюнхен |
Лейбница 8 |
500 |
20.04.06 |
103 |
Евро |
1031 |
АВ |
Мюнхен |
Лейбница 8 |
500 |
20.04.06 |
103 |
Евро |
1032 |
АД |
Минск |
Захарова 20 |
300 |
08.05.06 |
102 |
Доллар |
1033 |
АС |
Пуховичи |
Широкая 1 |
200 |
15.05.06 |
101 |
Росс рубль |
1034 |
АС |
Пуховичи |
Широкая 1 |
300 |
15.05.06 |
101 |
Росс рубль |
Таблицы в первой нормальной форме являются, как правило, избыточными, например сведения о клиенте (Код клиента, Адрес) повторяется в записи о каждом заказанном продукте.
Проблемы такой таблицы:
Узнаем адрес клиента, только в том случае если он что- то заказал
При удалении записи о продукте одновременно удаляются все сведения о самом заказе и о клиенте
Если сменил адрес, например, то его надо менять в каждой записи
Вывод: Данные в таблице необходимо нормализовать путем разбиения исходной таблицы на несколько таблиц, связанных первичными и внешними ключами.
Вторая нормальная форма.
1-й шаг
Для связывания в дальнейшем таблиц, получаемых из Таблицы ЗаказИнфо, в ней нужно определить поле, которое будет первичным ключом. Такое поле рекомендуется выбирать из тех полей, записи в которых являются избыточными. Учитывая выше указанные проблемы таблицы ЗаказИнфо, определим поле Код клиента в качестве первичного ключа.
По определению ссылочной целостности первичный ключ не должен содержать повторяющихся записей, поэтому первая промежуточная таблица, назовем ее ЗаказИнфо1, будет содержать только неповторяющееся записи Кода клиента.
ЗаказИнфо1
Номер заказа |
Код клиента |
Город |
Улица |
Вес заказа |
Дата заказа |
Код валюты |
Наименование валюты |
1021 |
АА |
Минск |
Правды 11 |
100 |
01.02.06 |
100 |
Бел рубль |
1023 |
АС |
Пуховичи |
Широкая 1 |
300 |
10.03.06 |
101 |
Росс рубль |
1030 |
АВ |
Мюнхен |
Лейбниц 8 |
500 |
20.04.06 |
103 |
Евро |
1032 |
АД |
Минск |
Захарова 20 |
300 |
08.05.06 |
102 |
Доллар |
В исходной таблице поле Код клиента определяется как внешний ключ
2-й шаг
В исходной таблице определяем поля, которые зависят только от первичного ключа, т.е. их значения не меняются при одинаковом значении записи первичного ключа. Очевидно, что это поля Город и Улица Только эти поля остаются в таблице ЗаказИнфо1, остальные поля удаляются. Таблица ЗаказИнфо1 переименуем в таблицу Клиенты. Из исходной таблицы ЗаказИнфо эти же поля удаляются и исходная таблица ЗаказИнфо перименовываем в таблицу ЗаказИнфо2:
Клиенты
Код клиента |
Город |
Улица |
АА |
Минск |
Правды 11 |
АС |
Пуховичи |
Широкая 1 |
АВ |
Мюнхен |
Лейбниц 8 |
АД |
Минск |
Захарова 20 |
ЗаказИнфо2
Код клиента |
Номер заказа |
Вес заказа |
Дата заказа |
Код валюты |
Наименование валюты |
АА |
1021 |
100 |
01.02.06 |
100 |
Бел рубль |
АА |
1022 |
150 |
01.02.06 |
100 |
Бел рубль |
АС |
1023 |
300 |
10.03.06 |
101 |
Росс рубль |
АС |
1024 |
400 |
11.03.06 |
101 |
Росс рубль |
АС |
1025 |
700 |
12.03.06 |
103 |
Евро |
АС |
1026 |
230 |
10.03.06 |
101 |
Росс рубль |
АС |
1027 |
120 |
15.04.06 |
101 |
Росс рубль |
АС |
1028 |
100 |
15.04.06 |
102 |
Доллар США |
АС |
1029 |
300 |
15.04.06 |
101 |
Росс рубль |
АВ |
1030 |
500 |
20.04.06 |
103 |
Евро |
АВ |
1031 |
500 |
20.04.06 |
103 |
Евро |
АД |
1032 |
300 |
08.05.06 |
102 |
Доллар США |
АС |
1033 |
200 |
15.05.06 |
101 |
Росс рубль |
АС |
1034 |
300 |
15.05.06 |
101 |
Росс рубль |
В результате получаем вторую нормальную форму, схема данных которой выглядит:
Клиенты ЗаказИнфо2
Код клиента (ПК) |
|
Код клиента (ВК) |
Город |
|
Номер заказа |
Улица |
|
Вес заказа |
|
|
Дата заказа |
|
|
Код валюты |
|
|
Наименование валюты |
Во второй нормальной форме можно также заметить аномалии, в частности в таблице ЗакзаИнфо2:
наименование валюты необходимо повторять при каждом заказе
при удалении заказа может быть удалено и наименование валюты
Вывод: необходимо преобразовать таблицу ЗаказИнфо2, чтобы устранить указанную аномалию.
Третья нормальная форма.
1-й шаг
В таблице ЗаказИнфо2, находящейся во второй нормальной форме, определим поле Код валюты в качестве первичного ключа. Очевидно, что полностью от этого поля зависит только поле Наименование валюты. Из таблице ЗаказИнфо2 выбираются только уникальные (неповторяющиеся) записи Код Валюты, и из полей Код Валюты и Наименование получается третья таблица Банк
Банк
Код валюты |
Наименование валюты |
100 |
Бел рубль |
101 |
Росс рубль |
102 |
Доллар США |
103 |
Евро |
2- й шаг
Из таблицы ЗаказИнфо2 удаляется поле Наименование валюты и таблица ЗаказИнфо2 переименовывается в Таблицу Заказы
Заказы
Код клиента |
Номер заказа |
Вес заказа |
Дата заказа |
Код валюты |
АА |
1021 |
100 |
01.02.06 |
100 |
АА |
1022 |
150 |
01.02.06 |
100 |
АС |
1023 |
300 |
10.03.06 |
101 |
АС |
1024 |
400 |
11.03.06 |
101 |
АС |
1025 |
700 |
12.03.06 |
103 |
АС |
1026 |
230 |
10.03.06 |
101 |
АС |
1027 |
120 |
15.04.06 |
101 |
АС |
1028 |
100 |
15.04.06 |
102 |
АС |
1029 |
300 |
15.04.06 |
101 |
АВ |
1030 |
500 |
20.04.06 |
103 |
АВ |
1031 |
500 |
20.04.06 |
103 |
АД |
1032 |
300 |
08.05.06 |
102 |
АС |
1033 |
200 |
15.05.06 |
101 |
АС |
1034 |
300 |
15.05.06 |
101 |
3-й шаг
Объединяются Таблицы Клиенты, Заказы и Банк с помощью первичных и внешних ключей,
Структура базы данных в третьей нормальной форме:
Клиенты Заказы Банк
К од клиента (ПК) |
|
К од клиента (ВК) |
|
Код валюты (ПК) |
Город |
|
Код валюты (ВК) |
|
Наименование валюты |
Улица |
|
Номер заказа |
|
|
|
|
Дата Заказа |
|
|
|
|
Вес заказа |
|
|
Преимущества нормальных форм таблиц: устранение избыточности таблиц; независимость записей в таблице с первичным ключом от записей в таблице с соответствующим внешним ключом, т.е. записи в таблице с внешним ключом (detail -таблицы) могут быть изменены (удалены) без нарушений в master – таблицы.
6. ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ И ИХ ПРОЦЕДУРЫ
Проектирование базы данных осуществляется в три этапа:
1) концептуальное проектирование;
2) логическое проектирование;
3) физическое проектирование.