15.5 Общие сведения о case-средствах.

Наглядное представление концептуальных схем баз данных обусловило широкое распространение ER-модели в CASE-средствах (Computer- Aided System Engineering ). Эти средства предназначены для автоматизированного проектирования реляционных баз данных. Широко распространены CASE-системы, позволяющие выполнять ER-диаграммы в соответствии со стандартом IDEF1X. К ним относятся, в частности, Erwin, Design/IDEF, Power Designer.

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

Современные CASE-средства обладают, например, такими характерными особенностями, как:

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

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

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

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

• генерация документации. Вся документация по проекту генерируется автоматически на основе репозитария. Она всегда отображает текущее состояние дел, так как любые изменения в проекте автоматически отображаются в репозитарии;

• верификация проекта. Это проверка проекта на полноту и состоятельность на ранних этапах разработки. Она влияет на успех разработки в целом.

Современные CASE-средства поддерживают все этапы ЖЦБД.

Пример программного окна Erwin показан ниже.

16. Нормализация данных в реляционных таблицах

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

Таблица находится в той или иной нормальной форме, если она удовлетворяет определенному набору требований.

Теоретически существуют 5 нормальных форм, хотя на практике используются три нормальные формы, которые рассмотрим более подробно.

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

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

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

Первая нормальная форма.

Предположим, что сначала все заказы клиентов были сведены в одну таблицу ЗаказИнфо:

ЗаказИнфо

Номер заказа	Код клиента	Город	Улица	Вес заказа	Дата заказа	Код валюты	Наименование валюты
1021	АА	Минск	Правды 11	100	01.02.12	100	Бел рубль
1022	АА	Минск	Правды 11	150	01.02.12	100	Бел рубль
1023	АС	Пуховичи	Широкая 1	300	10.03.12	101	Росс рубль
1024	АС	Пуховичи	Широкая 1	400	5.03.12	101	Росс рубль
1025	АС	Пуховичи	Широкая 1	700	12.03.12	103	Евро
1026	АС	Пуховичи	Широкая 1	230	10.03.12	101	Росс рубль
1027	АС	Пуховичи	Широкая 1	120	15.04.12	101	Росс рубль
1028	АС	Пуховичи	Широкая 1	100	15.04.12	102	Доллар США
1029	АС	Пуховичи	Широкая 1	300	15.04.12	101	Росс рубль
1030	АВ	Мюнхен	Лейбница 8	500	20.04.12	103	Евро
1031	АВ	Мюнхен	Лейбница 8	500	20.04.12	103	Евро
1032	АД	Минск	Захарова 20	300	08.05.12	102	Доллар
1033	АС	Пуховичи	Широкая 1	200	15.05.12	101	Росс рубль
1034	АС	Пуховичи	Широкая 1	300	15.05.12	101	Росс рубль

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

Проблемы такой таблицы:

• Узнаем адрес клиента, только в том случае если он что- то заказал

• При удалении записи о продукте одновременно удаляются все сведения о самом заказе и о клиенте

• Если сменил адрес, например, то его надо менять в каждой записи

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

Вторая нормальная форма.

1-й шаг

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

По определению ссылочной целостности первичный ключ не должен содержать повторяющихся записей, поэтому первая промежуточная таблица, назовем ее ЗаказИнфо1, будет содержать только неповторяющееся записи Кода клиента.

ЗаказИнфо1

Номер заказа	Код клиента	Город	Улица	Вес заказа	Дата заказа	Код валюты	Наименование валюты
1021	АА	Минск	Правды 11	100	01.02.12	100	Бел рубль
1022	АС	Пуховичи	Широкая 1	300	10.03.12	101	Росс рубль
1024	АВ	Мюнхен	Лейбниц 8	500	20.04.12	103	Евро
1025	АД	Минск	Захарова 20	300	08.05.12	102	Доллар

В исходной таблице поле Код клиента определяется как внешний ключ

2-й шаг

В исходной таблице определяем поля, которые зависят только от первичного ключа, т.е. их значения не меняются при одинаковом значении записи первичного ключа. Очевидно, что это поля Город и Улица Только эти поля остаются в таблице ЗаказИнфо1, остальные поля удаляются. Таблица ЗаказИнфо1 переименуем в таблицу Клиенты. Из исходной таблицы ЗаказИнфо эти же поля удаляются и исходная таблица ЗаказИнфо перименовываем в таблицу ЗаказИнфо2:

Клиенты

Код клиента	Город	Улица
АА	Минск	Правды 11
АС	Пуховичи	Широкая 1
АВ	Мюнхен	Лейбниц 8
АД	Минск	Захарова 20

ЗаказИнфо2

Код клиента	Номер заказа	Вес заказа	Дата заказа	Код валюты	Наименование валюты
АА	1021	100	01.02.12	100	Бел рубль
АА	1022	150	01.02.12	100	Бел рубль
АС	1023	300	10.03.12	101	Росс рубль
АС	1024	400	05.03.12	101	Росс рубль
АС	1025	700	12.03.12	103	Евро
АС	1026	230	10.03.12	101	Росс рубль
АС	1027	120	15.04.12	101	Росс рубль
АС	1028	100	15.04.12	102	Доллар США
АС	1029	300	15.04.12	101	Росс рубль
АВ	1030	500	20.04.12	103	Евро
АВ	1031	500	20.04.12	103	Евро
АД	1032	300	08.05.12	102	Доллар США
АС	1033	200	15.05.12	101	Росс рубль
АС	1034	300	15.05.12	101	Росс рубль

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

Клиенты ЗаказИнфо2

Код клиента (ПК)		Код клиента (ВК)
Город		Номер заказа
Улица		Вес заказа
		Дата заказа
		Код валюты
		Наименование валюты

Во второй нормальной форме можно также заметить аномалии, в частности в таблице ЗакзаИнфо2:

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

• при удалении заказа может быть удалено и наименование валюты

Вывод: необходимо преобразовать таблицу ЗаказИнфо2, чтобы устранить указанную аномалию.

Третья нормальная форма.

1-й шаг

В таблице ЗаказИнфо2, находящейся во второй нормальной форме, определим поле Код валюты в качестве первичного ключа. Очевидно, что полностью от этого поля зависит только поле Наименование валюты. Из таблице ЗаказИнфо2 выбираются только уникальные (неповторяющиеся) записи Код Валюты, и из полей Код Валюты и Наименование получается третья таблица Банк. Из таблицы ЗаказИнфо2 удаляется поле Наименование валюты и таблица ЗаказИнфо2 переименовывается в таблицу Заказы

Банк

Код валюты	Наименование валюты
100	Бел рубль
101	Росс рубль
102	Доллар США
103	Евро

2- й шаг

Из таблицы ЗаказИнфо2 удаляется поле Наименование валюты и таблица ЗаказИнфо2 переименовывается в Таблицу Заказы

Заказы

Код клиента	Номер заказа	Вес заказа	Дата заказа	Код валюты
АА	1021	100	01.02.12	100
АА	1022	150	01.02.12	100
АС	1023	300	10.03.12	101
АС	1024	400	05.03.12	101
АС	1025	700	12.03.12	103
АС	1026	230	10.03.12	101
АС	1027	120	15.04.12	101
АС	1028	100	15.04.12	102
АС	1029	300	15.04.12	101
АВ	1030	500	20.04.12	103
АВ	1031	500	20.04.12	103
АД	1032	300	08.05.12	102
АС	1033	200	15.05.12	101
АС	1034	300	15.05.12	101

3-й шаг

Объединяются Таблицы Клиенты, Заказы и Банк с помощью первичных и внешних ключей,

Структура базы данных в третьей нормальной форме:

Клиенты Заказы Банк

К од клиента (ПК)		К од клиента (ВК)		Код валюты (ВК)
Город		Код валюты (ВК)		Наименование валюты
Улица		Номер заказа
		Дата Заказа
		Вес заказа

Преимущества нормальных форм таблиц: устранение избыточности таблиц; независимость записей в таблице с первичным ключом от записей в таблице с соответствующим внешним ключом, т.е. записи в таблице с внешним ключом (detail -таблицы) могут быть изменены (удалены) без нарушений в master – таблицы.