Сведения о торгово-посреднической организации. Реляционная модель данных (стр. 2 из 3)

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

Произведем нормализацию отношений, чтобы можно было:

- обеспечить быстрый доступ к данным;

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

- обеспечить целостность данных, т.о. чтобы при изменении одних объектов автоматически происходило соответствующее изменение связанных с ними объектов.

Приведем БД к 1НФ.

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

Добавим в таблицу Заказы поле Код заказа, что позволит однозначно идентифицировать каждый из заказов.

Таблица Заказы содержит 3 группы повторяющихся полей:

Поля, характеризующие поставщика (производителя):

- Наименование фирмы

- ФИО директора

- Телефон

- Адрес

- ИНН

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

Поля, характеризующие товар:

- Наименование товара

- Производитель

- Цена товара за 1 ед.

- Количество на кладе

Вынесем их в отдельную таблицу Товары и добавим новое поле Код товара.

Поля, характеризующие договоры:

- Вид договора

- Дата составления

- Условия оплаты

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

Таблица Заявки содержит 4 группы повторяющихся полей:

Поля, характеризующие клиента:

- Наименование фирмы

- ФИО директора

- Телефон

- Адрес

- ИНН

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

Поля, характеризующие товар и договоры уже вынесены в таблицы Товары и Договоры.

Поля, характеризующие склады:

- Наименование склада

- Номер стеллажа

- Номер полки на стеллаже.

Вынесем их в отдельную таблицу Склады и добавим новое поле Код склада.

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

2 НФ.

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

Определим ключевые поля:

Для таблицы Заказы ключом является поле Код заказа, таблица Заявки – Код заявки, таблица Клиенты – Код клиента, таблица Поставщики – Код поставщика, таблица Договоры – Код договора, таблица Товары – Код товара, таблица Склады – Код склада.

3НФ.

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

Другими словами в таблице нет полей, которые не зависят от ключа.

Все таблицы, приведенные во 2 НФ соответствуют 3 НФ, т.к. в каждой таблице нет полей, которые не зависят от ключа.

При нормализации отношений можно выделить следующие сущности:

- Клиенты (Код клиента, Наименование фирмы, ФИО директора, Адрес, Телефон, ИНН)

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

- Поставщики (Код поставщика, Наименование фирмы, ФИО директора Адрес, Телефон, ИНН).

Эта сущность отводится для хранения сведений о поставщиках (либо производителях товара), с которыми работает организация. У них организация покупает товар.

- Товары (Код товара, Наименование товара, Цена за 1 ед., Производитель, Количество на складе)

Хранит сведения о товаре, количестве на складе для учета продукции.

- Заявки (Код заявки, Код клиента, Дата заявки, Код товара, Количество, Дата отгрузки)

Сведения о заявках (которые утвердил клиент), на основании заявки осуществляется изъятие продукции со склада.

- Заказы (Код заказа, Дата заказа, Код поставщика, Код товара, Количество, Дата доставки)

Эта сущность хранит сведения о поступлениях товара на склад от определенного поставщика/производителя.

- Договоры (Код договора, Вид договора, Дата составления, Код клиента (поставщика), Условия оплаты)

Данные о договорах необходимы для осуществления отгрузки товара с определенными условиями оплаты (предопла, отсрочка, наличные или безналичные).

- Склады (Код товара, Код склада, номер стеллажа, номер полки на стеллаже).

На основании данных сущностей строим инфологическую модель в БД.

Рисунок 3 – Инфологическая модель базы данных торгово-посреднической организации, построенная с помощью языка "Таблицы-связи".

4. Построение инфологической модели на реляционную модель данных

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

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

Реляционная база данных – это совокупность отношений, содержащих всю информацию, которая должна храниться в БД, следовательно, отражение модели "Таблицы-связи" на реляционную модель данных будет выглядеть в виде совокупности таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

- каждый элемент таблицы – один элемент данных;

- все элементы в столбце имеют одинаковый тип и длину;

- порядок следования строк и столбцов может быть произвольным.

Объект - элемент ИС, информация о котором сохраняется в ИС. В реляционной теории БД объект называется сущностью.

Атрибуты объекта - свойства характеризующие объект.

Атрибут записанный на каком-либо носителе информации называют элементом данных, полем данных или просто полем.

Запись совокупность характеристик объекта или кортеж.

Таблица некоторая структурированная информация, содержащая характеристики объекта или класса объектов.

Каждая строка является записью, а каждый столбец полем.

Тип данных характеризует вид хранящихся данных. Различают символьные, числовые данные, даты, время и т.д.

Тип данных вид хранящихся данных. Различают символьные, числовые данные, даты, время и т.д.

База данных совокупность таблиц объединенных вместе по какому-либо признаку.

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

Если отношение имеет более одного возможного ключа, тогда выделяют один ключ, называемый первичным. И наоборот, если отношение не имеет ни одного атрибута, который бы полностью определил объект (строку, кортеж) отношения, то определяется составной ключ, который схематически отображают двойной вертикальной чертой.

Ключ-это такой элемент, по которому можно определить значения других полей.

Пример отношения в реляционной модели данных: Таблица Заказы, имеет первичный ключ Код заказа. Поля: Дата заказа, Код поставщика, Код товара, количество, Дата поставки являются атрибутами в данной таблице.

Все информационные объекты предметной области связаны между собой. Существует 3 вида связи:

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

Связь 1:1 предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В. Каждая запись одной таблицы соответствует одной записи в другой таблице

При связи 1:М одному экземпляру информационного объекта А соответствует 0,1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А. Каждой записи в одной таблице соответствует несколько записей в другой таблице.

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

Между информационными объектами Клиенты и Договоры существует связь 1:М. Один клиент может заключить несколько договоров (например, с разницей в условии оплаты: предоплата или отсрочка). Так же между объектам Поставщики и Договоры существует связь 1:М.

Между информационными объектами Клиенты и Заявки существует связь 1:М. Один клиент может вносить сколько угодно заявок.

Между информационными объектами Товары и Заявки существует связь 1:М. Один и тот же товар может включаться в любое количество заявок, либо заказов.