Реляционная модель данных

 

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

В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение. По сути дела, в предыдущих двух разделах этой лекции мы рассматривали именно понятия и свойства структурной составляющей реляционной модели.

В манипуляционной части модели утверждаются два фундаментальных механизма манипулирования реляционными БД - реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями), а второй - на классическом логическом аппарате исчисления предикатов первого порядка.

Понятие целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений.

 

Процесс нормализации базы данных

 

Процесс проектирования БД можно в некоторой степени формализовать.

Одной из таких формализации является требование, согласно которому реляционная база данных должна быть нормализована. Процесс нормализации (см. Рис. 4.1.1) имеет своей целью устранение избыточности данных и заключается в приведении к третьей нормальной форме (ЗНФ).

Рис.4.1.1 Процесс нормализации

 

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

Первая нормальная форма (1НФ) требует, чтобы каждое поле таблицы БД было неделимым и не содержало повторяющихся групп.

Неделимость поля означает, что содержащиеся в нем значения не должны делиться на более мелкие.

Повторяющимися являются поля, содержащие одинаковые по смыслу значения.

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

В данной работе необходимо автоматизировать процесс отпуска товаров со склада по накладной, вид которой показан на рис.4.1.2.

 

Рис.4.1.2 Общий вид накладной

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

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

 

ОТПУСК-ТОВАРОВ-СО-СКЛАДА

Дата Покупатель Город Адрес Товар Ед_измерения Цена_за_ед_измер Отпущено_ед Общая_стоимость Номер_накладной

Рис. 4.1.3 Таблица без составных полей и циклических групп

 

Выделим поля, которые входят в первичный ключ. Дата накладной и номер накладной по отдельности не могут уникально определять запись, поскольку они будут одинаковы для всех записей, относящихся к одной и той же накладной (напомним, что одна накладная в таблице рис. 4.1.3 представляется несколькими записями). Поэтому введем в первичный ключ поле «Товар». При этом исходим из предположения, что по одной накладной может быть отпущено одно наименование конкретного товара, то есть не может иметь место ситуация, когда отпуск одного и того же товара оформляется в накладной двумя строками, что повлекло бы за собой две одинаковые записи в таблице «Отпуск товаров со склада».

На рис. 4.1.4 показана структура таблицы после выделения полей в составе первичного ключа (эти поля отчеркнуты от прочих полей линией и располагаются в верхней части структуры таблицы).

 

ОТПУСК-ТОВАРОВ-СО-СКЛАДА

Дата Покупатель Номер_накладной Товар

Город Адрес Ед_измер Цена_за_ед_измер Отпущено_ед Общая_стоимость

Рис. 4.1.4 Таблица с избыточным первичным ключом

 

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

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

Нетрудно увидеть, что созданный нами первичный ключ является избыточным: поле «Номер накладной» однозначно определяет дату и покупателя. Для данной накладной не может быть никакой иной даты и никакого иного покупателя. Поле «Товар» в комбинации с номером накладной, напротив, однозначно идентифицирует запись. После уточнения состава полей в первичном ключе получим таблицу со структурой, показанной на рис. 4.1.5.

ОТПУСК-ТОВАРОВ-СО-СКЛАДА

Номер_накладной Товар

Дата Покупатель Город Адрес Ед_измер Цена_за_ед_измер Отпущено_ед Общая_стоимость

Рис. 4.1.5 Таблица с неизбыточным первичным ключом, но еще не приведенная к 2НФ

 

Первое требование 2НФ выполнено, чего не скажешь о втором, гласящем, что значения всех полей записи должны однозначно зависеть от совокупного значения первичного ключа и не должна иметь место ситуация, когда некоторые поля зависят от части первичного ключа. В таблице на рис. 4.1.5 поля «Единица измерения», «Цена за единицу измерения» зависят от значения поля «Товар», входящего в первичный ключ. Поэтому выделяем эти поля в самостоятельную таблицу «Товары» и определяем связь: поскольку один товар может присутствовать во многих накладных, таблицы «Товары» и «Отпуск товаров со склада» находятся в связи один-ко-многим (рис. 4.1.6).

 

Рис. 4.1.6 Выделение таблицы «Товары»

После анализа структуры таблицы можно заметить, что значение поля «Покупатель» никоим образом не зависит от пары значений «Номер накладной», «Товар», а зависит только от значения поля «Номер накладной». Поэтому данное поле и зависящие от его значения поля «Город», «Адрес» выделяем в таблицу «Покупатели» (рис. 4.1.7).

Анализируя далее структуру таблицы «Отпуск товаров со склада», обнаруживаем, что одно из оставшихся полей - «Дата» - зависит только от значения поля «Номер накладной». Поэтому выделяем поля «Дата» и «Номер накладной» в самостоятельную таблицу «Накладные» (рис. 4.1.8).

Установим связи между таблицами. Один покупатель может встречаться во многих накладных. Поэтому между таблицами «Покупатели» и «Накладные» имеется связь один-ко-многим по полю «Покупатель». Одной накладной может соответствовать несколько товаров. Поэтому между таблицами «Накладные» и «Отпуск товаров со склада» имеется связь один-ко-многим по полю «Номер накладной» (рис. 4.1.9).

 

Рис. 4.1.7 Выделение таблицы «Покупалели»

Рис. 4.1.8 Выделение таблицы «Накладные»

 

Рис. 4.1.9 Связи между таблицами

 

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

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

В таблице «Отпуск товаров со склада» имеется зависимость значения поля «Общая стоимость» от значения поля «Количество». Значение поля «Общая стоимость» может вычисляться как значение поля «Количество», умноженное на значение поля «Цена за единицу измерения» из таблицы «Товары» (из записи с таким же значением поля «Товар»). Поэтому поле «Общая стоимость» из таблицы «Отпуск товаров со склада» удаляем. В результате получаем нормализованную базу данных, структура которой приводится на рис. 4.1.10.

В таблице «Покупатели» значение поля «Адрес» зависит от значения поля «Город», поскольку в разных городах могут оказаться улицы с одинаковыми названиями и, соответственно, дома с одинаковыми номерами (вспомним известный кинофильм «Ирония судьбы, или с легким паром»). Однако такой зависимостью можно пренебречь, поскольку поле «Адрес» в нашем случае носит чисто информационный характер и не должно входить в условия запросов самостоятельно. Вообще говоря, на практике не всегда возможно получить идеально нормализованную БД.

Полная реализация реляционной структуры БД отражена на плакате.

Рис. 4.1.10. Нормализованная база данных

 

Целостность данных

 

Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени.

Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений. Современные СУБД имеют ряд средств для обеспечения поддержания целостности (так же, как и средств обеспечения поддержания безопасности).

Выделяют три группы правил целостности:

1. Целостность по сущностям.

2. Целостность по ссылкам.

3. Целостность, определяемая пользователем.

Мотивировка правил целостности, общих для любых реляционных баз данных:

1. Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение.

2. Значение внешнего ключа должно либо:

· быть равным значению первичного ключа цели;

· быть полностью неопределенным, т.е. каждое значение атрибута, участвующего во внешнем ключе должно быть неопределенным.

3. Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируется: уникальность тех или иных атрибутов, диапазон значений (экзаменационная оценка от 2 до 5),принадлежность набору значений (пол "М" или "Ж").

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

InterBase поддерживает большинство типов данных, характерных для SQL. Следующая ниже таблица дает краткое описание типов данных, применимых для операторов SQL в InterBase.

В нашем случае зависимости между различными атрибутами будут следующими:

1. Товар определяется ключевым атрибутом «товар» в таблице Товары

2. Факт продажи товара со склада определяется составным ключевым атрибутом «товар» и «номер_накладной» в таблице Отпуск_товаров_со_склада

3. Накладные определяются ключевым атрибутом «номер_накладной» в таблице Накладные

4. Данные о покупателе определяются ключевым атрибутом «покупатель» в таблице Покупатель

Таблицы Товары и Отпуск_товаров_со_склада связаны отношением 1:М по внешнему ключу «Отпуск_товаров_со_склада . товар».

Таблицы Отпуск_товаров_со_склада и Накладные связаны отношением М:1 по внешнему ключу «Отпуск_товаров_со_склада . номер_накладной».

Таблицы Накладные и Покупатели связаны отношением М:1 по внешнему ключу «Накладные . покупатель».