Разработка АИС управления взаимоотношениями с клиентами (стр. 3 из 10)
Чтобы выполнить нормализацию, структура базы данных последовательно приводится к различным формам. Вообще говоря, каждая последующая форма относится и предыдущей категории. Например, чтобы схема базы данных соответствовала второй нормальной форме, она должна также соответствовать и первой нормальной форме. Чтобы схема соответствовала третьей нормальной форме, она должна соответствовать и второй нормальной форме, и т.д. На каждой стадии добавляется все больше правил, которым должна соответствовать схема.
Первая нормальная форма требует, чтобы каждое значение атрибута или столбца было атомарным. Это значит, что каждый атрибут должен содержать единственное значение, а не множество значений или другую строку базы данных.
Рассмотрим таблицу 1.
Таблица 1. Client
| id | f_sob | fio | otv | ur_adr | fiz_adr | tel | vid_doc |
| 3 | Физ. лицо | Аверин А.С. | Леонов А.Ю. | 8 Марта 38 | Советская 45 | 2–24–09 | Вод. удост. |
| 2 | Физ. лицо | Петров П.П. | Синегубов М.С. | Калинина 4 | Пролеткая 24 | 72–80–21 | Воен. билет |
| 5 | Юр. лицо | Ронжин Д.С. | Карикова Т.Н. | Пролет-кая 20 | Маяков-го 150 | 55–12–33 | паспорт |
Это – ненормализованная версия таблицы клиент. Как видите, здесь размешены такие столбцы как form_sob, vid_doc, которые надо привести к первой нормальной форме. Чтобы привести схему к первой нормальной форме, необходимо в столбце товар, покупатели и форма расчета разместить атомарные значения. Это можно сделать различными способами. Первая, наверное, самая очевидная возможность, показана в таблице 2.
Таблица 2. Client
| id | Id_f_sb | fio | otv | ur_adr | fiz_adr | tel | Id_v_dc |
| 3 | 2 | Аверин А.С. | Леонов А.Ю. | 8 Марта 38 | Советская 45 | 2–24–09 | 3 |
| 2 | 2 | Петров П.П. | Синегубов М.С. | Калинина 4 | Пролетарская 24 | 72–80–21 | 2 |
| 5 | 1 | Ронжин Д.С. | Карикова Т.Н. | Пролетарская 20 | Маяковского 150 | 55–12–33 | 1 |
В данной таблице мы выделили по одной строке на каждый элемент в столбцах форма собственности, вид документа. Это решение далеко от идеального, по сколько оно порождает очевидную избыточность данных. Лучший и самый правильный вариант приведения наших данных к нормальной форме показан на рисунке 2.
В этом случае мы выделили данные формы собственности в отдельную таблицу, что позволяет решить проблему избыточности.
После приведения схемы к нормальной форме можно перейти к формам старших порядков, которые немного труднее для понимания. Говорят, что схема находится во второй нормальной форме, если все атрибуты, не являющиеся частью первичного ключа, а сама схема уже находится в первой нормальной форме. Что это значит? Это значит, что каждый атрибут, не является ключом, должен функционально зависеть от всех составляющих ключа. Так, если первичный ключ составлен из нескольких столбцов, то всякий другой атрибут в таблице должен зависеть от комбинации всех этих столбцов.
Рисунок 2 – Нормализация Базы данных
В таблице 2 Client имеет по одной строке на каждый элемент квалификации типов. Таблица находится в первой нормальной форме, но не удовлетворяет второй нормальной форме. Другими словами, мы можем определить наименование vid_doc, используя только кодовый номер типа (Id_vid_doc). Это значит, что указанные атрибуты функционально зависимы только от части первичного ключа, а не от всего первичного ключа. Таким образом, я могу определить эти атрибуты по части первичного ключа, и для этого совсем не нужен весь первичный ключ. Следовательно, указанная схема не находится во второй нормальной форме.
Чтобы привести эту схему ко второй нормальной форме необходимо разбить таблицу на такие таблицы, в которых все не ключевые атрибуты будут полностью функционально зависеть от ключа. Очевидно, что в данном случае этого можно достичь, разделив исходную таблицу на две:
client (Id_vid_doc)
Vid_doc (vid)
Пример показан в таблице 3.
Таблица 3. Vid_doc
| id | Vid |
| 1 | Паспорт |
| 3 | Водительское удостоверение |
| 2 | Военный билет |
Как уже говорилось, эта схема находится в первой нормальной форме, поскольку все значения являются атомарными. Но она также находится и во второй нормальной форме, по сколько каждый атрибут, не являющийся ключом, теперь функционально зависит от всех частей ключа. Для моей схемы не требуется создавать третью нормальную форму, так как моей работе удовлетворяют две формы, то есть первая нормальная форма и вторая нормальная форма.
2.2 Реализация базы данных с помощью программы «Денвер‑2»
В базе данных было решено создать 15 таблицы и назвать её «comb»:
Таблицы базы данных «comb»: client, dan_doc, dog, form_ras, form_sob, men, pam, posher, prod, realiz, sort, upac, vid_doc, vid_posh, vid_pr.
Рассмотрим подробнее структуру каждой из них.
Таблица «client» состоит из 8 полей. В первом храниться уникальный идентификатор записи, имя поля «ID» тип Smallint. Это поле является первичным ключом таблицы. Второе поле «id_form_sob» содержит информацию о форме собственности и является индексным полем в таблице, тип Smallint. Третье поле «fio» это поле содержит информацию о клиенте, тип Varshar. Четвёртое поле «otv» это поле содержит ответсвенное лицо клиента, тип Varchar. Пятое поле «ur_adr» содержит юридический адрес, тип Varchar. Шестое поле «fiz_adr» содержит физический адрес, тип Varchar. Седьмое поле «tel» содержит номер телефона клиента, тип Varchar. Восьмое поле «id_vid_doc» содержит информацию о виде документа и является индексным полем в таблице, тип Smallint. Пример программы приведен на рисунке 3 и рисунке 4.
Рисунок 3 – Структура таблицы «client»
Рисунок 4 – Таблица «client»
Таблица «form_sob» состоит из 2 полей. Первое поле «ID» содержит уникальный идентификатор, по которому происходит связь с индексом «id» таблицы «client». Второе поле «form» содержит форму собственности. Пример программы приведен на рисунке 5 и рисунке 6.
Рисунок 5 – Структура таблицы «form_sob»
Рисунок 6 – Таблица «form_sob»
Таблица «vid_doc» состоит из 2 полей. Первое поле «ID» содержит уникальный идентификатор, по которому происходит связь с индексом «id» таблицы «client». Второе поле «vid» содержит вид документа. Пример программы приведен на рисунке 7 и рисунке 8.
Рисунок 7 – Структура таблицы «vid_doc»
Рисунок 8 – Таблица «vid_doc»
Таблицы «prod» состоит из 9 полей. Первое поле «ID» содержит уникальный идентификатор записи имя поля «id» тип Smallint. Второе поле «id_vid_pr» содержит уникальный идентификатор, по которому происходит связь с индексом «id» таблицы «vid_pr», тип Smallint. Третье поле «naz» содержит название продукции, тип Varchar. Четвертое поле «id_upac» содержит уникальный идентификатор, по которому происходит связь с индексом «id» таблицы «upac», тип Smallint. Пятое поле «id_sort» содержит уникальный идентификатор, по которому происходит связь с индексом «id» таблицы «sort», тип Smallint. Шестое поле «data» содержит дату продукции, тип Varchar. Седьмое поле «sroc» содержит срок годности продукции, тип Varchar. Восьмое поле «cena» содержит цену продукции, тип Varchar. Девятое поле «kol» содердит количество продукции, тип Varchar. Пример программы приведен на рисунке 9 и рисунке 10.
Рисунок 9 – Структура таблицы «prod»
Рисунок 10 – Таблица «prod»
Таблица «vid_pr» состоит из 2 полей. Первое поле «ID» содержит уникальный идентификатор, по которому происходит связь с индексом «id» таблицы «prod». Второе поле «vid_pr» содержит вид продукции, тип Varshar. Пример программы приведен на рисунке 11 и рисунке 12.
Рисунок 11 – Структура таблицы «vid_pr»
Рисунок 12 – Таблица «vid_pr»
Таблица «upac» состоит из 2 полей. Первое поле «ID» содержит уникальный идентификатор, по которому происходит связь с индексом «id» таблицы «prod». Второе поле «upack» содержит вид упаковки, тип Varshar. Пример программы приведен на рисунке 13 и рисунке 14.
Рисунок 13 – Структура таблицы «upac»
Рисунок 14 – Таблица «upac»
Таблица «sort» состоит из 2 полей. Первое поле «ID» содержит уникальный идентификатор, по которому происходит связь с индексом «id» таблицы «prod». Второе поле «sor» содержит сорт продукции, тип Varshar. Пример программы приведен на рисунке 15 и рисунке 16.
Рисунок 15 – Структура таблицы «sort»
Рисунок 16 – Таблица «sort»