Разработка структуры базы данных

 

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

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

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

Рассмотрим таблицу 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»

 

Таблица «men» состоит из 2 полей. Первое поле «ID» содержит уникальный идентификатор записи, имя поля «id» тип Smallint. Второе поле «fio1» содержит Ф.И.О. менеджера, тип Varshar. Пример программы приведен на рисунке 17 и рисунке 18.

 

Рисунок 17 – Структура таблицы «men»

 

Рисунок 18 – Таблица «men»

 

Таблица «posher» состоит из 4 полей. Первое поле «ID» содержит уникальный идентификатор записи, имя поля «id» тип Smallint. Второе поле «id_client» содержит Ф.И.О. клиента и является индексным полем в таблице, тип Smallint. Третье поле «id_vid_posh» содержит вид поощрения и является индексным полем в таблице, тип Smallint. Четвертое поле «data» содержит дату, когда поощрить, тип Varshar. Пример программы приведен на рисунке 19 и рисунке 20.

 

Рисунок 19 – Структура таблицы «posher»

 

Рисунок 20 – Таблица «posher»

Таблица «vid_posh» состоит из 2 полей. Первое поле «ID» содержит уникальный идентификатор, по которому происходит связь с индексом «id» таблицы «posher». Второе поле «posh» содержит вид поощрений, тип Varshar. Пример программы приведен на рисунке 21 и рисунке 22.

 

Рисунок 21 – Структура таблицы «vid_posh»

 

Рисунок 22 – Таблица «vid_posher»

 

Таблица «dan_doc» состоит из 6 полей. Первое поле «ID» содержит уникальный идентификатор записи, имя поля «id» тип Smallint. Второе поле «id_vid_doc» содержит вид документа и является индексным полем в таблице, тип Smallint. Третье поле «cer» содержит серию документа, тип Varshar. Четвертое поле «data» содержит дату выдачи документа, тип Varshar. Пятое поле «mest» содержит место выдачи документа, тип Varshar. Шестое поле «kem» содержит, кем выдан документ, тип Varshar. Пример программы приведен на рисунке 23 и рисунке 24.

 

Рисунок 23 – Структура таблицы «dan_doc»

 

Рисунок 24 – Таблица «dan_doc»

 

Таблица «dog» состоит из 5 полей. Первое поле «ID» содержит уникальный идентификатор записи, имя поля «id» тип Smallint. Второе поле «pred» содержит предмет договора, тип Varshar. Третье поле «otv» содержит, ответсвенное лицо договора, тип Varshar. Четвертое поле «id_form_ras» содержит, уникальный идентификатор записи, имя поля «id» тип Smallint. Пятое поле «data» содержит дату подписания договора, тип Varshar. Пример программы приведен на рисунке 25 и рисунке 26.

 

Рисунок 25 – Структура таблицы «dog»

 

Рисунок 26 – Таблица «dog»

 

Таблица «form_ras» состоит из 2 полей. Первое поле «ID» содержит уникальный идентификатор, по которому происходит связь с индексом «id» таблицы «dog». Второе поле «form» содержит форму расчета, тип Varshar. Пример программы приведен на рисунке 27 и рисунке 28.

 

Рисунок 27 – Структура таблицы «form_ras»

 

Рисунок 28 – Таблица «form_ras»

 

Таблица «pam» состоит из 5 полей. Первое поле «ID» содержит уникальный идентификатор записи, имя поля «id» тип Smallint. Второе поле «id_men» содержит, уникальный идентификатор записи, имя поля «id» тип Smallint. Третье поле «id_client» содержит, уникальный идентификатор записи, имя поля «id» тип Smallint. Четвертое поле «data» содержит, дату паятных дат, тип Varshar. Пятое поле «prim» содержит, примечание, тип Varshar. Пример программы приведен на рисунке 29 и рисунке 30.

 

Рисунок 29 – Структура таблицы «pam»

 

Рисунок 30 – Таблица «pam»

 

Таблица «realiz» состоит из 7 полей. В первом храниться уникальный идентификатор записи, имя поля «ID» тип Smallint. Это поле является первичным ключом таблицы. Второе поле «id_men» содержит информацию о менеджере и является индексным полем в таблице, тип Smallint. Третье поле «id_client» содержит информацию о клиенте и является индексным полем в таблице, тип Smallint. Четвёртое поле «id_vid_pr» содержит вид продукции и является индексным полем в таблице, тип Smallint. Пятое поле «id_dog» содержит информацию о договоре и является индексным полем в таблице, тип Smallint. Шестое поле «data» содержит дату когда реализовали товар, тип Varchar. Седьмое поле «kol» содержит количество реализованной продукции, тип Varchar. Пример программы приведен на рисунке 31 и рисунке 32.

 

Рисунок 31 – Структура таблицы «realiz»

 

Рисунок 32 – Таблица «realiz»

 

3 Разработка подсистемы ввода / вывода и генерации отчетов для автоматизированной информационной системы.

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

· «Администрирование» – позволяет добавлять в базу данных готовые проекты и удалять их.

· «Программы вывода информации из базы данных» – интерфейс позволяет просматривать всю информацию, содержащуюся в базе данных.

· «Поиск» – интерфейс позволяет осуществлять поиск данных, в таблицах базы данных, генерирует отчеты на основе запросов пользователя в базе данных.

 

123	Поделиться:

Воспользуйтесь поиском по сайту: