Торговая фирма
Курсовой проект - Компьютеры, программирование
Другие курсовые по предмету Компьютеры, программирование
бизнес-правила.
.Каждый поставщик обязательно живет в каком-либо городе.
.Каждый поставщик живет лишь в одном городе.
.В каждом городе могут жить несколько поставщиков.
.В городе может не жить ни одного поставщика.
Рисунок 5 - ER-диаграмма для сущностей Поставщик - Заявка
Исходя из ER-диаграммы на рисунке 4 можно выделить следующие бизнес-правила.
1.Каждый поставщик может получить/предложить сколь угодно много различных заявок на товар.
.Каждая заявка привязана лишь к одному поставщику.
.Каждая заявка обязана иметь целевого поставщика.
.Поставщик может не иметь заявок.
В общем виде ER-диаграмма продемонстрирована на рисунке 6.
Рисунок 6 - ER-диаграмма в общем виде
1.3 Отношения
Главная цель проектирования базы данных заключается в нормализации предварительных отношений. Выполнение требований нормализации обеспечивает построение реляционной базы данных без дублирования данных и возможность поддержки целостности при внесении изменений. В процессе проектирования к отношениям выдвигают следующие требования:
-информационный объект должен содержать уникальный идентификатор (ключ);
-все описательные реквизиты должны быть взаимонезависимы, т.е. между ними не может быть функциональных зависимостей;
-все реквизиты, входящие в составной ключ, должны быть также взаимонезависимы;
-каждый описательный реквизит должен функционально полно зависеть от ключа, т.е. каждому значению ключа соответствует только одно значение описательного реквизита;
-при составном ключе описательные реквизиты должны зависеть целиком от всей совокупности реквизитов, образующих ключ;
-каждый описательный реквизит не может зависеть от ключа транзитивно, т.е. через другой промежуточный реквизит.
Исходя из анализа описания предметной области, выявленных бизнес-правил, а также правил построения отношений, исходя из ER-диаграмм была получена следующая схема базы данных:
.Товары(код_товара,Наименование,Дополнительная информация)
.Поставщики(код_поставщика,Имя,код_города,код_товара)
.Города(код_города,Имя,Дополнительная информация)
.Склады(код_склада, Адрес, код_города, телефон)
.Хранится(код_товара,код_склада, количество, ограничение)
.Заявки(код_заявки,код_поставщика,количество,цена,статус,флаг)
1.4 Ограничения целостности
При реализации полученной схемы следует учитывать, что предметная область накладывает некоторые ограничения на значения атрибутов. Также следует учитывать, что при реализации на атрибуты будут наложены ограничения, связанные с выбранным типом данных. Таблица 1демонстрирует ограничения целостности и соответствия типов атрибутам отношений.
Таблица 1 - Ограничения
ОтношениеАтрибутОписаниеТип атрибутаОграничениеТоварыКод_товараУникальный номер товара, первичный ключЦелое числоУникальное поле, генерируется автоматическиНаименованиеУникальное наименование товараСтрока (40 символов)Уникальное поле, обязательно для заполненияИнформацияДополнительная информацияСтрока(50 символов) ПоставщикиКод_поставщикаУникальный номер поставщика, первичный ключЦелое числоУникальное поле, генерируется автоматическиИмяУникальное имя поставщикаСтрока (40 символов)Уникальное поле, обязательно для заполненияКод_городаКод города, в котором живет поставщикЦелое числоВнешний ключ, должно существовать в таблице ГородаКод_товараКод товара, который поставляется поставщикомЦелое числоВнешний ключ, должно существовать в таблице ТоварыГородаКод_городаУникальный номер города, первичный ключЦелое числоУникальное поле, генерируется автоматическиНаименованиеУникальное наименование городаСтрока (40 символов)Уникальное поле, обязательно для заполненияИнформацияДополнительная информацияСтрока(50 символов)СкладыКод_складаУникальный номер склада, первичный ключЦелое числоУникальное поле, генерируется автоматическиАдресАдрес склада в городеСтрока (40 символов)Обязательно для заполненияКод_городаКод города, в котором находится складЦелое числоВнешний ключ, должно существовать в таблице ГородаТелефонТелефон складаСтрока (40 символов)ЗаявкиКод_заявкиУникальный номер заявки, первичный ключЦелое числоУникальное поле, генерируется автоматическиКод_поставщикаКод поставщика оставившего (которому предназначена) заявкаЦелое числоВнешний ключ, должно существовать в таблице ПоставщикиКоличествоКоличество предложенного товараЦелое числоОбязательно для заполненияЦенаПредложенная ценаЧисло с плавающей точкойОбязательно для заполненияСтатусСтатус заявки может иметь три значения: принята не принята не рассмотренаБайтЗначение по умолчанию не рассмотренаФлагФлаг может принимать два значения: Заявка адресована фирме от поставщика Заявка адресована поставщику от фирмыБайтОбязательно для заполненияХранитсяКод_товараКод хранимого на складе товараЦелое числоВнешний ключ, должно существовать в таблице ТоварыКод_складаКод склада на котором хранится товарЦелое числоВнешний ключ, должно существовать в таблице СкладыКоличествоКоличество товара, хранящегося на складеЦелое числоЗначение по умолчанию 0, должно быть меньше ограниченияОграничениеМаксимальное количество данного товара на складеЦелое числоОбязательно для заполнения
2.Разработка серверной части
Для создания серверной части базы