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

ВВЕДЕНИЕ
Кодд (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


2 шаг

Нарушение – столбец Сумма является производным столбцом = Колво*Цена, а это недопустимо.

Удаляем столбец Сумма


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

Ном
Заказа

Позиция
Зак

Шифр

Колво

100

1

D567

3

100

2

D570

2

100

3

K238

2

100

4

M279

2

101

1

D570

1

102

1

K238

4

102

2

P237

30

102

3

D570

1

103

1

M279

4

103

2

K238

3


Р
ЗАКАЗЧИКИ

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

ИмяЗаказчика

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




ЗАКАЗЫ

НомЗаказа

ДатаЗаказа

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



езультат:


ПРОДУКТЫ

Шифр

Название

Цена




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

НомЗаказа

ПозицияЗак

Шифр

Колво




1



1



1

