Автоматизация деятельности торгового предприятия
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
БД.
3. Проектирование базы данных. разработка и настройка необходимых ПО
3.1Проектирование баз данных основного и архивного серверов
В данном параграфе будет спроектирована база данных только для основного сервера, так как база данных на архивном сервере будет иметь аналогичную структуру и организацию. Но, тем не менее, работа с одной из баз данных, будет сильно отличаться от работы с дрогой [12]. Назначения каждого сервера были описаны в постановке задаче. Согласно назначению архивного сервера, все отношения базы данных на нем должны иметь атрибуты, указывающие на тип совершенной операции с данными (добавление, модификация и запись) и дату совершения операции.
3.1.1Описание предметной области
Прежде всего, описываемая предметная область относятся к сфере флористики. О каждом продукте необходимы следующие сведения: наименование, наименование родительской категории, производитель, описание, закупочная цена, минимальная цена реализации, дата вступления в продажу, статус активности.
Категории товаров в свою очередь могут иметь подкатегории. Каждая категория характеризуется наименованием, родительской категорией, и датой добавления.
Списки категорий и реализуемой продукции доступны на каждом складе и на каждой торговой розничной точке. Причем на сладах и торговых точках устанавливается своя цена на один и тот же товар.
Каждая торговая розничная точка должна характеризоваться наименованием, наименованием склада поставляющего продукцию, адресом и процентом надбавки на реализуемую продукцию, от минимальной розничной цены. Всякую торговую розничную точку снабжает только один склад.
Каждый склад должен определяться наименованием, наименованием района в котором расположен, адресом, и процентами надбавки на минимальные оптовые и розничные цены.
О каждом реализованном товаре должно быть известно: номер сделки купли-продажи (зависит от места реализации), сотрудник отпустивший товар, склад/торговая точка на котором отпущен товар, наименование реализованной продукции, количество проданного товара, цена проданного товара, точное время реализации и итоговая сумма.
От торговых точек на склады поступают заказы. О каждом заказе должна быть известна вся информация, необходимая для совершения сделки купли-продажи.
Сотрудники предприятия делятся на несколько групп. Каждая группа имеет свой уровень доступа к базе данных: для кассиров предназначен самый низкий уровень, а для программистов самый высокий. О каждом сотруднике должно быть известно: ФИО, имя пользователя, пароль, склад/торговая точка на котором работает, адрес, контактный номер и уровень доступа.
Поставка продукции на склады осуществляется непосредственно самими производителями. О каждом производителе должно быть известно: наименование, ИНН, ОГРН, ФИО представителя, юридический адрес и контактный номер. Построение реляционной модели данных
3.1.2 Построение реляционной модели данных
В данном проекте используется реляционная модель данных [6]. Поскольку на сегодняшний день реляционные СУБД стали доминирующим типом программных продуктов для обработки данных. В реляционной модели все данные логически структурированы внутри отношений (таблиц). Каждое отношение имеет имя и состоит из именованных атрибутов (столбцов) данных. Каждый кортеж (строка) данных содержит по одному значению каждого из атрибутов. Большое преимущество реляционной модели заключается именно в этой простоте логической структуры. Хотя, конечно же, за этой простотой скрывается серьезный теоретический фундамент, которого нет у моделей первого поколения (т.е. у сетевых и иерархических моделей). В проектируемой базе данных используются следующие отношения: "l_product" отношение сущности "Товар"; "l_category" отношение сущности категориях товар; "l_stock" и "l_store" отношения сущностей "Склад" и "Торговая точка"; "l_sale", "l_delivery" и "l_zakaz" отношения связей "Реализует", "Поставляет" и "Заказывает"; "l_staff" отношение сущности "Сотрудник"; "l_manufacturer" сущности "Производитель". Структуры отношений проектируемой базы данных:
Таблица 1 - Структура отношения "l_manufacturer"
Наименование атрибутаОписание атрибутаТип данныхManufacturer_idID производителяINT(11)NameНаименованиеVARCHAR(255)Juristic_personЮридическое лицоVARCHAR(255)AddressАдрес производителяVARCHAR(255)OGRNОГРНINT(20)INNИННINT(20)ContactКонтактная информацияVARCHAR(255)
Таблица 2 - Структура отношения "l_product"
Наименование атрибутаОписание атрибутаТип данныхProduct_idID продуктаINT(11)Manufacturer_idID производителяINT(11)NameНаименованиеVARCHAR(255)PriceЦенаDECIMAL(15,4)Date_availableДата вступления в продажуDATETIMEStatusСтатус активностиINT(1)CostЗакупочная ценаDECIMAL(15,4)Main_category_idID родительской категорииINT(11)DescriptionОписаниеTEXTТаблица 3 - Структура отношения "l_category"
Наименование атрибутаОписание атрибутаТип данныхCategory_idID категорииINT(11)Parent_idID родительской категорииINT(11)NameНаименованиеVARCHAR(255)Date_addedДата добавленияDATETIME
Таблица 4 - Структура отношения "l_stock"
Имя атрибутаОписание атрибутаТип данныхStock_idID складаINT(11)NameНаименованиеVARCHAR(255)ZoneРайонVARCHAR(255)AddressАдресVARCHAR(255)Markup_wholesaleПроцент оптовой надбавкиDECIMAL(15,4)Markup_retailПроцент розничной надбавкиDECIMAL(15,4)
Таблица 5 - Структура отношения "l_stores"
Наименование атрибутаОписание атрибутаТип данныхStore_idID торговой точкиINT(11)Stock_idID снабжающего складаINT(11)NameНаименованиеVARCHAR(255)AddressАдресVARCHAR(255)Markup_retailПроцент розничной надбавкиDECIMAL(15,4)
?/p>