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

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 27.06.2023

Просмотров: 213

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

Поставщик

Название поля

Описание

Тип поля

Длина поля

Первичный ключ

N

Номер

Number

8

Да

Name

Наименование

Alpha

30

Adress

Адрес

Alpha

40

Phone

Номер телефона

Alpha

15

Таблица 4

Договор

Название поля

Описание

Тип поля

Длина поля

Первичный ключ

N

Номер

Number

8

Да

Name

Наименование

Alpha

30

Adress

Адрес

Alpha

40

Phone

Номер телефона

Alpha

15


Таблица 5

Договор

Название поля

Описание

Тип поля

Длина поля

Первичный ключ

NDogovora

Номер договора

Number

8

Да

NTovara

Номер товара

Number

8

Да

Таблица 6

Заявка

Название поля

Описание

Тип поля

Длина поля

Первичный ключ

N

Номер заявки

Number

8

Да

NDogovora

Номер договора

Number

8

Date

Дата

Date

4

Таблица 7

Заявка

Название поля

Описание

Тип поля

Длина поля

Первичный ключ

NZayavki

Номер заявки

Number

8

Да

NTovara

Номер товара

Number

8

Да

Quantity

Количество

Number

8

Таблица 8

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

Название поля

Описание

Тип поля

Длина поля

Первичный ключ

N

Номер счета

Number

8

Да

NZayavki

Номер заявки

Number

8

Да

Price

Сумма счета

Money

8

Таблица 9

Товар

Название поля

Описание

Тип поля

Длина поля

Первичный ключ

N

Номер товара

Number

8

Да

Name

Наименование

Alpha

40