 |
Общие сведения о CASE-средствах.
|
|
|
|
Наглядное представление концептуальных схем баз данных обусловило широкое распространение ER-модели в CASE-средствах (Computer- Aided System Engineering ).
Эти средства предназначены для автоматизированного проектирования реляционных баз данных.
Широко распространены CASE-системы, позволяющие выполнять ER-диаграммы в соответствии со стандартом IDEF1X. К ним относятся, в частности:
· Erwin,
· Design/IDEF,
· Power Designer.
CASE-средства позволяют:
· строить ER-диаграммы в реальном масштабе времени, используя при этом богатую цветовую палитру,
· сквозную проверку синтаксических правил.
Графические средства моделирования предметной области дают возможность наглядно изучать концептуальную модель данных и перестраивать ее соответственно поставленным целям и имеющимся ограничениям.
Современные CASE-средства обладают, например, такими характерными особенностями, как:
· единый графический язык. Все участники проекта обеспечиваются единым, строгим, наглядным графическим языком, позволяющим получать проект с простой, ясной структурой;
· использование репозитария. Репозитарий – это база данных проекта, предназначенная для хранения всей информации о проекте, которая может использоваться совместно разработчиками соответственно их правам доступа;
· поддержка коллективной разработки и управления проектом. Поддерживаются возможность работы в сети, импорт-экспорт фрагментов проекта, а также функции, необходимые в процессе разработки и сопровождения проектов – планирование, контроль, руководство, взаимодействие;
· макетирование. Можно быстро строить макеты будущей базы данных, что позволяет оценить на ранних этапах разработки, насколько она приемлема для будущих пользователей;
|
|
|
· генерация документации. Вся документация по проекту генерируется автоматически на основе репозитария. Она всегда отображает текущее состояние дел, так как любые изменения в проекте автоматически отображаются в репозитарии;
· верификация проекта. Это проверка проекта на полноту и состоятельность на ранних этапах разработки. Она влияет на успех разработки в целом.
Современные CASE-средства поддерживают все этапы ЖЦБД.
Пример программного окна Erwin показан ниже.
5.1 Нормализация данных в реляционных таблицах
Нормализация представляет собой процесс реорганизации данных в реляционных таблицах путем ликвидации повторяющихся групп и иных противоречий в хранении данных с целью приведения таблиц к виду, позволяющему осуществить корректное редактирование данных.
Таблица находится в той или иной нормальной форме, если она удовлетворяет определенному набору требований.
Теоретически существуют 5 нормальных форм, хотя на практике используются три нормальные формы, которые рассмотрим более подробно.
Первой нормальной формой называется реляционная таблица, в которой все значения полей являются атомарными, т.е. любая реляционная база данных находится в первой нормальной форме.
Реляционная таблица соответствует второй нормальной форме, если она находится в первой нормальной форме, и ее не ключевые поля зависят от первичного ключа.
Реляционная таблица соответствует третьей нормальной форме,если в таблице не имеется транзитивных зависимостей между не ключевыми полями, т.е. значение любого поля таблицы, не входившего в первичный ключ, не зависит от значения другого поля, не входившего в первичный ключ.
Первая нормальная форма.
Предположим, что сначала все заказы клиентов были сведены в одну таблицу ЗаказИнфо:
ЗаказИнфо
| Номер заказа | Код клиента | Город | Улица | Вес заказа | Дата заказа | Код валюты | Наименование валюты |
| АА | Минск | Правды 11 | 01.02.06 | Бел рубль | |||
| АА | Минск | Правды 11 | 01.02.06 | Бел рубль | |||
| АС | Пуховичи | Широкая 1 | 10.03.06 | Росс рубль | |||
| АС | Пуховичи | Широкая 1 | 11.03.06 | Росс рубль | |||
| АС | Пуховичи | Широкая 1 | 12.03.06 | Евро | |||
| АС | Пуховичи | Широкая 1 | 10.03.06 | Росс рубль | |||
| АС | Пуховичи | Широкая 1 | 15.04.06 | Росс рубль | |||
| АС | Пуховичи | Широкая 1 | 15.04.06 | Доллар США | |||
| АС | Пуховичи | Широкая 1 | 15.04.06 | Росс рубль | |||
| АВ | Мюнхен | Лейбница 8 | 20.04.06 | Евро | |||
| АВ | Мюнхен | Лейбница 8 | 20.04.06 | Евро | |||
| АД | Минск | Захарова 20 | 08.05.06 | Доллар | |||
| АС | Пуховичи | Широкая 1 | 15.05.06 | Росс рубль | |||
| АС | Пуховичи | Широкая 1 | 15.05.06 | Росс рубль |
|
|
|
Таблицы в первой нормальной форме являются, как правило, избыточными, например сведения о клиенте (Код клиента, Адрес) повторяется в записи о каждом заказанном продукте.
Проблемы такой таблицы:
· Узнаем адрес клиента, только в том случае если он что- то заказал
· При удалении записи о продукте одновременно удаляются все сведения о самом заказе и о клиенте
· Если сменил адрес, например, то его надо менять в каждой записи
Вывод: Данные в таблице необходимо нормализовать путем разбиения исходной таблицы на несколько таблиц, связанных первичными и внешними ключами.
Вторая нормальная форма.
1-й шаг
Для связывания в дальнейшем таблиц, получаемых из Таблицы ЗаказИнфо, в ней нужно определить поле, которое будет первичным ключом. Такое поле рекомендуется выбирать из тех полей, записи в которых являются избыточными. Учитывая выше указанные проблемы таблицы ЗаказИнфо, определим поле Код клиента в качестве первичного ключа.
По определению ссылочной целостности первичный ключ не должен содержать повторяющихся записей, поэтому первая промежуточная таблица, назовем ее ЗаказИнфо1, будет содержать только неповторяющееся записи Кода клиента.
ЗаказИнфо1
| Номер заказа | Код клиента | Город | Улица | Вес заказа | Дата заказа | Код валюты | Наименование валюты |
| АА | Минск | Правды 11 | 01.02.06 | Бел рубль | |||
| АС | Пуховичи | Широкая 1 | 10.03.06 | Росс рубль | |||
| АВ | Мюнхен | Лейбниц 8 | 20.04.06 | Евро | |||
| АД | Минск | Захарова 20 | 08.05.06 | Доллар |
|
|
|
В исходной таблице поле Код клиента определяется как внешний ключ
Й шаг
В исходной таблице определяем поля, которые зависят только от первичного ключа, т.е. их значения не меняются при одинаковом значении записи первичного ключа. Очевидно, что это поля Город и Улица Только эти поля остаются в таблице ЗаказИнфо1, остальные поля удаляются. Таблица ЗаказИнфо1 переименуем в таблицу Клиенты. Из исходной таблицы ЗаказИнфо эти же поля удаляются и исходная таблица ЗаказИнфо перименовываем в таблицу ЗаказИнфо2:
Клиенты
| Код клиента | Город | Улица |
| АА | Минск | Правды 11 |
| АС | Пуховичи | Широкая 1 |
| АВ | Мюнхен | Лейбниц 8 |
| АД | Минск | Захарова 20 |
ЗаказИнфо2
| Код клиента | Номер заказа | Вес заказа | Дата заказа | Код валюты | Наименование валюты |
| АА | 01.02.06 | Бел рубль | |||
| АА | 01.02.06 | Бел рубль | |||
| АС | 10.03.06 | Росс рубль | |||
| АС | 11.03.06 | Росс рубль | |||
| АС | 12.03.06 | Евро | |||
| АС | 10.03.06 | Росс рубль | |||
| АС | 15.04.06 | Росс рубль | |||
| АС | 15.04.06 | Доллар США | |||
| АС | 15.04.06 | Росс рубль | |||
| АВ | 20.04.06 | Евро | |||
| АВ | 20.04.06 | Евро | |||
| АД | 08.05.06 | Доллар США | |||
| АС | 15.05.06 | Росс рубль | |||
| АС | 15.05.06 | Росс рубль |
В результате получаем вторую нормальную форму, схема данных которой выглядит:
Клиенты ЗаказИнфо2
 Код клиента (ПК)
| Код клиента (ВК) | |
| Город | Номер заказа | |
| Улица | Вес заказа | |
| Дата заказа | ||
| Код валюты | ||
| Наименование валюты |
Во второй нормальной форме можно также заметить аномалии, в частности в таблице ЗакзаИнфо2:
· наименование валюты необходимо повторять при каждом заказе
· при удалении заказа может быть удалено и наименование валюты
Вывод: необходимо преобразовать таблицу ЗаказИнфо2, чтобы устранить указанную аномалию.
|
|
|
Третья нормальная форма.
1-й шаг
В таблице ЗаказИнфо2, находящейся во второй нормальной форме, определим поле Код валюты в качестве первичного ключа. Очевидно, что полностью от этого поля зависит только поле Наименование валюты. Из таблице ЗаказИнфо2 выбираются только уникальные (неповторяющиеся) записи Код Валюты, и из полей Код Валюты и Наименование получается третья таблица Банк
Банк
| Код валюты | Наименование валюты |
| Бел рубль | |
| Росс рубль | |
| Доллар США | |
| Евро |
Й шаг
Из таблицы ЗаказИнфо2 удаляется поле Наименование валюты и таблица ЗаказИнфо2 переименовывается в Таблицу Заказы
Заказы
| Код клиента | Номер заказа | Вес заказа | Дата заказа | Код валюты |
| АА | 01.02.06 | |||
| АА | 01.02.06 | |||
| АС | 10.03.06 | |||
| АС | 11.03.06 | |||
| АС | 12.03.06 | |||
| АС | 10.03.06 | |||
| АС | 15.04.06 | |||
| АС | 15.04.06 | |||
| АС | 15.04.06 | |||
| АВ | 20.04.06 | |||
| АВ | 20.04.06 | |||
| АД | 08.05.06 | |||
| АС | 15.05.06 | |||
| АС | 15.05.06 |
Й шаг
Объединяются Таблицы Клиенты, Заказы и Банк с помощью первичных и внешних ключей,
Структура базы данных в третьей нормальной форме:
Клиенты Заказы Банк
 Код клиента (ПК)
|  Код клиента(ВК)
| Код валюты (ПК) | ||
| Город | Код валюты (ВК) | Наименование валюты | ||
| Улица | Номер заказа | |||
| Дата Заказа | ||||
| Вес заказа |
Преимущества нормальных форм таблиц: устранение избыточности таблиц; независимость записей в таблице с первичным ключом от записей в таблице с соответствующим внешним ключом, т.е. записи в таблице с внешним ключом (detail -таблицы) могут быть изменены (удалены) без нарушений в master – таблицы.
|
|
|
