Файл: Проектирование базы данных Учета расчетов с поставщиками и подрядчиками (Описание предметной области. Постановка задачи.).pdf

1.3 Проектирование логической структуры базы данных

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

Особое внимание уделяется этапу проектирования информационно-логической модели, поскольку здесь необходимо добиться оптимального соотношения между предметной областью и абстракцией логической модели. Для проектирования существуют различные средства в том числе и компьютерные. Для этой цели мы воспользовались ER-диаграммой (ER – Entity Relation – «Сущность-Связь»). Сущность – это класс однотипных объектов, информация о которых должна быть учтена в модели. Связь – это некоторое соединение между двумя сущностями. ER-диаграмма – это несколько сущностей, соединенные связями. Модель «Сущность-связь» описывается в терминах сущность, связь, значение. Сущность – понятие которое может быть идентифицировано. Связь – соединение сущностей.

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

Сущность «Поставщик». С поставщиком заключается договор, на основании которого ведется вся остальная деятельность предприятии по поставкам, отправление заявки поставщикам, получение от них счета-фактуры, отправление заказа на поставку, получение товара, оплата поставки. В качестве ключа для данной сущности вводится атрибут № Поставщика.

Сущность «Договор». Договор содержит такие данные как дата договора, номер договора, сумма и срок действия. На основании договора составляются заявки на поставку товара. Договор включает ассортимент товаров. В качестве ключа сущности вводится атрибут № Договора.

Сущность «Заявка». Заявка содержит такие данные на основании какого договора она составлена, дата заявки, номер заявки. На основании заявки создается счет-фактура с указанием цены. Заявка включает перечень товаров. В качестве ключа сущности вводится атрибут №Заявки.

Сущность «Счет-фактура». Счет фактура включает номер счета-фактуры и сумму по заявке. На основании счета-фактуры составляется заказ. В качестве ключа для данной сущности вводится атрибут №счета.

Сущность «Заказ». Заказ содержит данные о номере заказа, ассортименту заказа, номере договора, дате заказа, номере счета. В качестве ключа для данной сущности вводится атрибут № заказа.

Все сущности, их атрибуты и ключи представлены в Таблице 1.

Таблица 1

Сущности, их атрибуты и ключи модели

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

- «Поставщик» заключает «Договор»;

- «Договор» включает «Ассортимент товаров»;

- «Договор» основание «Заявка»;

- «Заявка» включает «Ассортимент товаров»;

- «Заявка» основание «Счет-фактуры»;

- «Счет-фактура» основание «Заказ»;

- «Заказ» включает «Ассортимент товаров».

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

Таблица 2

Логическая модель

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

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

- вторая нормальная форма (2NF): сущность находится во второй нормальной форме, если она находится в первой нормальной форме и каждый не ключевой атрибут полностью зависит от первичного ключа (не должно быть зависимости от части ключа). Вторая нормальная форма имеет смысл только для сущностей, имеющих сложный первичный ключ;

- третья нормальная форма (3NF): сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и никакой не ключевой атрибут не зависит от другого не ключевого атрибута (не должно быть взаимозависимости между не ключевыми атрибутами);

- нормальная форма Бойса-Кодда (усиленная 3NF): отношение находится в усиленной 3NF тогда и только тогда, когда каждый детерминант отношения является возможным ключом.

Разработанная модель находится в 3-й нормальной форме, так как:

– атрибуты сущностей являются атомарными;

– каждый не ключевой атрибут функционально полно зависит от первичного ключа;

– в модели отсутствуют транзитивные зависимости не ключевых атрибутов от ключа.

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

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

Для построения логической модели данных использовалось СASE-средство MS Visio, которое позволяет проектировать реляционные модели данных.

Логическая модель данных представлена на Рисунке 1.

Рисунок 1. Логическая модель данных

1.4 Проектирование физической структуры базы данных

Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует, физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах.

Описанные сущности в предыдущем пункте согласно выбранной СУБД будут иметь следующие физические модели:

- сущность «Поставщик» (таблица 3);

- сущность «Договор» (таблица 4);

- сущность «Ассортимент договора» (таблица 5);

- сущность «Заявка» (таблица 6);

- сущность «Ассортимент заявки» (таблица 7);

- сущность «Счет-фактура» (таблица 8);

- сущность «Ассортимент товара» (таблица 9);

- сущность «Заказ» (таблица 10);

- сущность «Ассортимент заказа» (таблица 11).

Таблица 3

Поставщик

Таблица 4

Договор

Таблица 5

Договор

Таблица 6

Заявка

Таблица 7

Заявка

Таблица 8

Счет-фактура

Таблица 9

Товар