Язык sql, быстрый старт.

                Рассмотрим простой пример базы данных платежных поручений. Именно платежные поручения были взяты мной, т.к. это достаточно короткий пример, чтобы можно было не расплываться по древу во время повествования, здесь можно показать на примере все нормальные формы таблицы, можно показать основные принципы работы в Delphi при создании программ баз данных.

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

 

Наименование поля	Тип	Размер	Пояснения
Отчетный год	S		Это поле необходимо, чтобы платежки разных лет можно было отличать друг от друга, ведь у одного плательщика в новом году номера начнутся снова с единицы
Номер	I
Дата	D
Сумма	F
ИНН плательщика	A	10
Наименование организации плательщика	B		Текст
Наименование банка плательщика	B		Текст
Расчетный счет плательщика в банке	A	20
Бик банка плательщика	A	9
Кор. Счет банка плательщика	A	20
ИНН получателя	A	10
Наименование организации получателя	B		Текст
Наименование банка получателя	B		Текст
Расчетный счет получателя	A	20
Бик банка получателя	A	9
Кор. Счет банка получателя	A	20
Вид оплаты	A	6
Назначение платежа	A	6
Код	A	6
Срок платежа	D		Как правило, не заполняется
Очередность платежа	A	6
Назначение платежа	A	6	Здесь храниться код назначения, что-то вроде: 6, 2, 4 и т.д.

 

Условные обозначения типов:      A – строка;

                           S – короткое целое;

I – целое число;

F – дробное число;

D – дата;

B – BLOB массив, например текст.

                Таблица в первой нормальной форме, но у нас многие значения в строке с платежкой будут повторяться. Давайте приведем ее ко второй нормальной форме. Сразу договоримся не включать в рассмотрение поля, начиная с вида оплаты и ниже. Почему? Далее я поясню, что бывают исключения из правил. Как говориться нормализуй, но не переусердствуй!

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

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

Список платежных поручений

 

Наименование поля	Тип	Размер	Пояснения
Отчетный год	S		Отчетный год, номер и код плательщика – это первичный ключ списка платежных поручений.   Внешний ключ к по первичному ключу справочника организаций
Номер	I
Плательщик	I
Получатель	I		Внешний ключ к по первичному ключу справочника организаций
Дата	D
Сумма	F
Вид оплаты	A	6
Назначение платежа	A	6
Код	A	6
Срок платежа	D		Как правило, не заполняется
Очередность платежа	A	6
Назначение платежа	A	6	Здесь храниться код назначения, что-то вроде: 6, 2, 4 и т.д.

 

Справочник организаций

 

Наименование поля	Тип	Размер	Пояснения
Код организации	I		Первичный ключ
ИНН организации	A	10
Наименование организации	B		Текст
Наименование банка организации	B		Текст
Расчетный счет организации в банке	A	20
Бик банка организации	A	9
Кор. Счет банка организации	A	20

 

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

 

Справочник организаций

 

Наименование поля	Тип	Размер	Пояснения
Код организации	I		Первичный ключ
ИНН организации	A	10
Наименование организации	B		Текст
Код банка организации	I		Внешний ключ к по первичному ключу справочника банков
Расчетный счет организации в банке	A	20

 

Справочник банков

 

Наименование поля	Тип	Размер	Пояснения
Код банка	I		Первичный ключ
Наименование банка	B		Текст
Бик банка	A	9
Кор. Счет банка	A	20

 

Итак, вроде бы, все таблицы во второй нормальной форме. Посмотрим, что можно сделать дальше.

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

                Для начала запишем наши определения таблиц в виде, более приближенном к тому, с чем имеет дело программист.

 

Список платежных поручений

Наименование поля	Тип	Размер	Пояснения
Year_Now	S		Первичный ключ - отчетный год, номер и код плательщика
Number	I
ID_Plat	I
ID_Pol	I		Код  получателя
Date_Now	D		Дата
Balance	F		Сумма
Opl_Type	A	6	Вид оплаты
Nazn_Type	A	6	Назначение платежа
Kod_Type	A	6	Код
Date_Plat	A		Срок платежа
Och_Type	A	6	Очередность платежа
Naznachenie	B	6	Назначение платежа

 

 

Справочник организаций

Наименование поля	Тип	Размер	Наименование поля
ID_Num	I		Код организации, первичный ключ
INN	A	15	ИНН организации
Short_Name	A	40	Короткое наименование организации
Full_Name	В		Юридическое имя организации
OKONH	A	10	ОКОНХ
OKPO	A	15	ОКПО
ID_Bank	I		Код банка организации
PC_In_Bank	A	25	Расчетный счет организации в банке

 

Справочник банков

Наименование поля	Тип	Размер	Пояснения
ID_Num	I		Код банка, первичный ключ
Short_Name	A	40	Короткое наименование банка
Full_Name	B		Наименование банка
BIK	A	15	Бик банка
KC1	A	25	Кор. Счет банка
KC2	A	25	Кор. Счет банка для валютных платежей
KC3	A	25	Кор. Счет банка банка для валютных платежей
KC4	A	25	Кор. Счет банка банка для валютных платежей

 

                Заметьте, что я изменил размеры полей некоторых таблиц и добавил несколько новых полей в таблицы. Увеличение длины строкового поля продиктовано стремлением к возможности подстраиваться к новым условиям при изменении отчетности. Так уже несколько раз было. На моей памяти уже три раза за два года. Поля OKONH и OKPO добавлены как информационные. Они ни как не участвуют в процессе создания платежки, но почему бы ни хранить их в справочниках, ведь платежка – это оплата по договору или по накладной, а для их составления неплохо знать ОКОНХ и ОКПО организации. В справочник банков было добавлено еще три корсчета. Это связано с тем, что валютный платеж проходит не напрямую из банка в банк, а через несколько посредников. В таком случае, нужно внести в наименование банка все наименования посредников и напечатать их корреспондентские счета. Это несколько неправильно с точки зрения нормализации, но сравним плату за нормализацию с потерями от ненормальной формы. При соблюдении нормальной формы, нам потребуется создать новую таблицу с корреспондентскими счетами банка, и указывать их все для создания валютной платежки, т.е. хранить эту информацию в списке платежек. Это увеличит потребность в системных ресурсах. Т.к. банков будет явно меньше, чем платежек, то оставив лишних три поля в таблице справочника банков, мы наоборот сэкономим системные ресурсы, тем более, что можно объявить поля как VARCHAR(25). Эти же  рассуждения справедливы и для полей Opl_Type, Nazn_Type, Kod_Type, Och_Type. Выделив их в отдельную таблицу, мы только усложним структуру базы данных, а эта плата неприемлемо высока.

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

 

Справочник организаций

Наименование поля	Тип	Размер	Наименование поля
ID_Num	I		Код организации, первичный ключ
INN	A	15	ИНН организации
Short_Name	A	40	Короткое наименование организации
Full_Name	В		Юридическое имя организации
OKONH	A	10	ОКОНХ
OKPO	A	15	ОКПО
ID_Rec	I		Код реквизита в банке по умолчанию

 

Справочник реквизитов организации

Наименование поля	Тип	Размер	Наименование поля
ID_Num	I		Код
ID_Company	I		Код организации
ID_Bank	I		Код банка организации
PC_In_Bank	A	25	Расчетный счет организации в банке

 

                Опять используем суррогатный первичный ключ. Связь таблиц организации и ее реквизитов организуем по внешнему ключу ID_Company. Обратите внимание, что формально соблюдая законы нормализации, мы получили более правильное представление об организации. Добиваясь третьей нормальной формы, мы пришли к тому, что организация может иметь несколько счетов в одном банке или в нескольких банках, что, вообще-то говоря, соответствует реальному положению дел. Поле ID_Rec оставлено в справочнике организаций, чтобы при создании новой платежки, автоматически выбирались реквизиты по умолчанию. Теперь, нам нужно пересмотреть список платежек, т.к. в этой таблице нет информации о реквизитах организации.      

 

Список платежных поручений

Наименование поля	Тип	Размер	Пояснения
Year_Now	S		Первичный ключ - отчетный год, номер и код плательщика
Number	I
ID_Plat	I
ID_Rec_Plat	I		Код реквизита плательщика
ID_Pol	I		Код  получателя
ID_Rec_Pol	I		Код реквизита получателя
Date_Now	D		Дата
Balance	F		Сумма
Opl_Type	A	6	Вид оплаты
Nazn_Type	A	6	Назначение платежа
Kod_Type	A	6	Код
Date_Plat	D		Срок платежа
Och_Type	A	6	Очередность платежа
Naznachenie	B	6	Назначение платежа

 

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

                Обратите внимание, что на каком-то этапе, мы потеряли часть данных в списке платежек, но впоследствии восстановили правильное представление, так вот, мы добились полной декомпозиции. Как правило, при переводе таблицы в третью нормальную форму при соблюдении полной декомпозиции, мы получаем пятую нормальную форму автоматически.

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

                Обратите внимание на то, что поля ID_Plat, ID_Rec_Plat, ID_Pol, ID_Rec_Pol связывают список платежек со справочниками по первичному ключу, а это и есть пятая нормальная форма. На этом можно было бы остановиться, но я думаю, что пользователю неудобно выбирать плательщика и получателя из справочника организаций, т.к. справочник организаций – это и плательщики, и получатели вместе. База данных с организациями, возможно, будет использоваться как справочник и в других программах, поэтому, там могут появиться и другие организации, которые не имеют никакого отношения к получателям и плательщикам.  Эти рассуждения подвигают нас к тому, чтобы создать еще две таблицы с плательщиками и получателями. В этих таблицах будут храниться только коды плательщиков и получателей соответственно.             

 

Справочник плательщиков

Наименование поля	Тип	Размер	Наименование поля
ID_Company	I		Код организации, первичный ключ
Name	A	10	Поле для сортировки по наименованию

 

Справочник получателей

Наименование поля	Тип	Размер	Наименование поля
ID_Company	I		Код организации, первичный ключ
Name	A	10	Поле для сортировки по наименованию

 

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