Главным является понятие таблицы

Вид материала

Содержание

При проектировании БД или приведении ее к нормализованному виду необходимо
Пример процесса нормализации на этапе проектирования БД
1 шаг Необходимо выявить хотя бы один объект. ЗАКАЗЫ 2 шаг
Первая нормальная форма
Вторая нормальная форма
Третья нормальная форма

Подобный материал:

ВВЕДЕНИЕ

Кодд (E. F. Codd сотрудник фирмы IBM) в 1962 году предложил:

- концепцию реляционной БД
- нормализацию, как краеугольный камень модели проектирования БД (OLTP on line transaction processing).

Кодд дал определение БАЗЫ ДАННЫХ как
«состоящий из набора неупорядоченных таблиц, управление которой может осуществляться с помощью НЕПРОЦЕДУРНЫХ операций, возвращающих таблицы».

Главным является понятие таблицы.

Чтобы ТАБЛИЦА могла рассматриваться, как настоящий объект реляционной базы данных она должна соответствовать следующим условиям:

Таблица должна описывать один объект
В таблице должен присутствовать первичный ключ, обеспечивающий уникальность каждой записи таблицы
Порядок строк и столбцов в таблице не должен иметь значения.

При проектировании БД или приведении ее к нормализованному виду необходимо:

определить правильные объекты
и заранее определить какие действия (процессы) будут выполняться над этими объектами.

Пример процесса нормализации на этапе проектирования БД

ОПИСАНИЕ МОДЕЛИ ПРОЕКТИРУЕМОЙ БАЗЫ ДАННЫХ

Модель продаж, которая предполагает заключение сделки на продажу комплектующих компьютерной техники.

Процессы – Клиент приходит, беседует с сотрудником, который и принимает его заказ.

1 шаг

Необходимо выявить хотя бы один объект. ЗАКАЗЫ

2 шаг

Определение состава столбцов и Первичного ключа

Таблица ЗАКАЗЫ

НомЗаказа

ИмяЗаказч

АдресЗаказчика

ДатаЗаказа

СоставЗаказа

Первичный ключ - НомЗаказа

3 шаг

Заполнить таблицу данными для проведения процесса нормализации

ЗАКАЗЫ

Ном Заказа	Имя Заказчика	Адрес Заказчика	Дата Заказа	Состав Заказа
100	КЕЙ	Литейный	1.2.2000	3-D567, disk, $180; 2-D570, disk; $200; 2-K238, UPS, $88; 2-M279, monit, $136
101	Компьютер	Пушкинская	1.2.2000	1-D570, disk; $200
102	Мир	Невский	5.2.2000	4-K238, UPS, $176; 30-P237,Memory, $900; 1-D570, disk; $100;
103	КЕЙ	Литейный	6.2.2000	4-M279, monit, $272 3-K238, UPS, $132

Нормализация

Цель нормализации - ИСКЛЮЧЕНИЕ ДУБЛИРОВАНИЯ ДАННЫХ и, соответственно, связанных с этим проблем, т.к. дублирование данных в таблицах приводит к различным видам аномалий. Таких как:

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

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

Теория нормализации базируется на концепции нормальных форм.

Нормальные формы - это последовательность правил, применяемых к базе данных, причем, чем выше нормальная форма, тем совершеннее структура БД.

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

Первая нормальная форма (1НФ) требует:

- отсутствие повторяющихся ГРУПП данных

- в каждой ячейке данные должны быть автономными и независимыми.

Если таблица не соответствует этим требованиям с ней проводятся следующие операции:

- повторяющиеся группы данных перемещаются в новые таблицы

- для новых таблиц создаются первичные ключи

- столбцы, содержащие составную информацию, разбиваются на отдельные строки для каждого фрагмента данных.

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

1 шаг

Первое нарушение – повторяющиеся группы данных

Переносим столбцы с группой информации о заказчике в отдельную таблицу. Для таблицы ЗАКАЗЧИКИ задаем первичный ключ. В таблице ЗАКАЗЫ создаем внешний ключ (НомЗаказчика), для связи Заказчиков с заказами.

Результат:

ЗАКАЗЫ

Ном Заказа	Дата Заказа	Ном Заказчика	Состав Заказа
100	1.2.2000	1	3-D567, disk, $180; 2-D570, disk; $200; 2-K238, UPS, $88; 2-M279, monit, $136
101	1.2.2000	2	1-D570, disk; $200
102	5.2.2000	3	4-K238, UPS, $176; 30-P237,Memory, $900; 1-D570, disk; $100;
103	6.2.2000	1	4-M279, monit, $272 3-K238, UPS, $132

ЗАКАЗЧИКИ

Ном Заказчика	Имя Заказчика	Адрес Заказчика
1	КЕЙ	Литейный
2	Компьютер	Пушкинская
3	Мир	Невский

2 шаг

Второе нарушение – состав заказа (ко-во, шифр, название, цена заказа) – не являются элементарными.

Разбиваем составной столбец на отдельные строки для каждого фрагмента данных и добавим стоимость единицы товара

ЗАКАЗЫ

Ном Заказа	Дата Заказа	Ном Заказчика	Шифр	Название	Колво	Цена	Сумма
100	1.2.2000	1	D567	disk	3	60	180
100	1.2.2000	1	D570	disk	2	100	200
100	1.2.2000	1	K238	UPS	2	44	88
100	1.2.2000	1	M279	monit	2	68	136
101	1.2.2000	2	D570	disk	1	200	200
102	5.2.2000	3	K238	UPS	4	44	176
102	5.2.2000	3	P237	Memory	30	30	900
102	5.2.2000	3	D570	disk	1	100	100
103	6.2.2000	1	M279	monit	4	68	272
103	6.2.2000	1	K238	UPS	3	44	132

3 шаг

Новая проблема – первичный ключ перестал быть уникальным.

Чтобы решить эту проблему – добавим новый столбец – ПозицияЗак – отмечающий позицию заказа. И определим составной ключ – НомЗаказаПозицияЗак

ЗАКАЗЫ

Ном Заказа	Позиция Зак	Дата Заказа	Ном Заказчика	Шифр	Название	Колво	Цена	Сумма
100	1	1.2.2000	1	D567	disk	3	60	180
100	2	1.2.2000	1	D570	disk	2	100	200
100	3	1.2.2000	1	K238	UPS	2	44	88
100	4	1.2.2000	1	M279	monit	2	68	136
101	1	1.2.2000	2	D570	disk	1	200	200
102	1	5.2.2000	3	K238	UPS	4	44	176
102	2	5.2.2000	3	P237	Memory	30	30	900
102	3	5.2.2000	3	D570	disk	1	100	100
103	1	6.2.2000	1	M279	monit	4	68	272
103	2	6.2.2000	1	K238	UPS	3	44	132

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

Вторая нормальная форма (2НФ) требует:

- таблица должна удовлетворять 1НФ

- каждый столбец должен зависеть от всего ключа

У нас есть составной ключ, надо проверить ВСЕ ли столбцы зависят от ЦЕЛОГО ключа или есть столбцы, которые зависят только от его части?

ДА, есть нарушение:

ДатаЗаказа и НомЗаказчика

зависят - только от НомЗаказа

и не зависят от ПозицияЗак

Чтобы разрешить это нарушение необходимо:

- создать еще одну таблицу

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

ЗАКАЗЫ

Ном Заказа	Дата Заказа	Ном Заказчика
100	1.2.2000	1
101	1.2.2000	2
102	5.2.2000	3
103	6.2.2000	1

ДЕТАЛИЗАКАЗА

Ном Заказа	Позиция Зак	Шифр	Название	Колво	Цена	Сумма
100	1	D567	disk	3	60	180
100	2	D570	disk	2	100	200
100	3	K238	UPS	2	44	88
100	4	M279	monit	2	68	136
101	1	D570	disk	1	200	200
102	1	K238	UPS	4	44	176
102	2	P237	Memory	30	30	900
102	3	D570	disk	1	100	100
103	1	M279	monit	4	68	272
103	2	K238	UPS	3	44	132

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

Третья нормальная форма (3НФ) требует правильных зависимостей в столбцах:

- таблица должна удовлетворять 2НФ

- ни один столбец не должен зависеть от столбца, не являющегося частью первичного ключа

- запрещается наличие производных данных

1 шаг

Первое нарушение

Название и цена (рассматриваем вариант, что цена никогда не меняется) зависят от Шифра, а не от НомЗаказа и ПозицияЗак.

Чтобы разрешить это нарушение:

- переносим в новую таблицу Шифр, НомЗаказа, ПозицияЗак и Шифр определяем первичным ключом.

ПРОДУКТЫ

Шифр	Название	Цена
D567	disk	60
D570	disk	100
K238	UPS	44
M279	monit	68
D570	disk	200
P237	Memory	30

ДЕТАЛИЗАКАЗА

Ном Заказа	Позиция Зак	Шифр	Колво	Сумма
100	1	D567	3	180
100	2	D570	2	200
100	3	K238	2	88
100	4	M279	2	136
101	1	D570	1	200
102	1	K238	4	176
102	2	P237	30	900
102	3	D570	1	100
103	1	M279	4	272
103	2	K238	3	132