Разработка базы данных учета и анализа реализации строительных материалов из магазина

 

Рисунок 1 - Инфологическая модель предметной области

 «Строительный магазин» 

     Связь ПРОДАЖА является связью типа М:М, так как персонал (продавец, кладовщик) может продать несколько товаров, и в реализации товара задействовано несколько человек. Сущности ПЕРСОНАЛ и ТОВАР относятся к обязательному классу принадлежности, вследствие того, что товар должен обязательно реализовываться персоналом.

     Связь ПРИОБРЕТЕНИЕ является связью типа М:М, так как поставляется товары нескольких наименований  и различными поставщиками. Сущности ОПЕРАЦИЯ КУПЛИ и ТОВАР в данной связи имеет обязательный класс принадлежности, так как у каждого товара обязательно есть свой поставщик.

     Связь РЕАЛИЗАЦИЯ является связью типа М:М, так как клиенты могут приобретать множество товаров. Сущность ОПЕРАЦИЯ ПРОДАЖИ имеет обязательный класс принадлежности, так как товар обязательно приобретается клиентом. Сущность ТОВАР в данной связи имеет необязательный класс принадлежности, так как у каждого товара необязательно есть свой клиент. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

     2.4. Логическое проектирование  БД 

     2.4.1. Нормализация отношений  реляционной модели  данных 

     Под нормализацией отношения подразумевается процесс приведения отношения к одной из так называемых нормальных форм (или в дальнейшем НФ). 

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

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

     На  практике, как правило, ограничиваются 3НФ, ее оказывается вполне достаточно для создания надежной схемы БД. 

1. ТОВАР (КОД ТОВАРА, НАИМЕНОВАНИЕ ТОВАРА, ПРОИЗВОДИТЕЛЬ, НОМЕР СКЛАДА, КОД РАБОТНИКА, АДРЕС СКЛАДА, ТЕЛЕФОН СКЛАДА)

• Учет товара ведется по коду товара. Код товара – уникален и является первичным ключом.

• Все атрибуты являются атомарными, следовательно, отношения находятся в 1НФ.
• Первичный ключ – простой и функциональная зависимость всех неключевых атрибутов от первичного ключа – полная, следовательно, отношение находится во 2НФ.
• Все неключевые атрибуты функционально зависят от первичного ключа, других функциональных зависимостей нет, следовательно, отношение находится в 3НФ.

     Но  так как один и тот же товар  может храниться на разных складах то часть атрибутов зависит от неключевого атрибута НОМЕР СКЛАДА.

     НОМ_СКЛАДА àАДРЕС СКЛАДА, ТЕЛЕФОН СКЛАДА

     Таким образом, зависимости КОД ТОВАРА à АДРЕС СКЛАДА, ТЕЛЕФОН СКЛАДА являются транзитивными. Следовательно нам необходимо провести декомпозицию отношения ТОВАР на отношения: 

     ТОВАР (КОД ТОВАРА, НАИМЕНОВАНИЕ ТОВАРА, ПРОИЗВОДИТЕЛЬ, НОМЕР СКЛАДА); 

     СКЛАД (НОМЕР СКЛАДА, АДРЕС СКЛАДА, ТЕЛЕФОН СКЛАДА, КОД РАБОТНИКА) 

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

2. ПЕРСОНАЛ (ФАМИЛИЯ РАБОТНИКА, ИМЯ РАБОТНИКА, ОТЧЕСТВО РАБОТНИКА, ДОЛЖНОСТЬ, ОКЛАД, КОД РАБОТНИКА, ДАТА РОЖДЕНИЯ)

       Процесс нормализации отношения Персонал аналогичен процессу нормализации отношения товар. В результате нормализации этого отношения получили следующие отношения:

       код работника à [все атрибуты]

• Учет персонала магазина ведется по личному номеру работника. Личный номер каждого работника – уникален. В данном отношении первичным ключом является атрибут код работника.
• Все атрибуты являются атомарными, следовательно, отношение находится в 1НФ.
• Первичный ключ – простой и функциональная зависимость всех неключевых атрибутов от первичного ключа – полная, следовательно, отношение находится во 2НФ.
• Все неключевые атрибуты функционально зависят от первичного ключа, других функциональных зависимостей нет, следовательно, отношение находится в 3НФ.

 
     

3. ОПЕРАЦИЯ  КУПЛИ (НОМЕР НАКЛАДОЙ, ДАТА ПОКУПКИ, СТОИМОСТЬ ПОКУПКИ, КОЛИЧЕСТВО ЗАКАЗАННОГО ТОВАРА, РНН ПОСТАВЩИКА, НАИМЕНОВАНИЕ ФИРМЫ, АДРЕС ПОСТАВЩИКА, ТЕЛЕФОН ПОСТАВЩИКА, КОД ТОВАРА)

 

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

     

• Все атрибуты являются атомарными, следовательно, отношение находится в 1НФ.
• Первичный ключ – простой и функциональная зависимость всех неключевых атрибутов от первичного ключа – полная, следовательно, отношение находится во 2НФ.
• Все неключевые атрибуты функционально зависят от первичного ключа.

             Но так как операции покупки  товара могут выполняться у   различных поставщиков то часть  атрибутов зависит от неключевого  атрибута  РНН ПОСТАВЩИКА.

     РНН ПОСТАВЩИКА à НАИМЕНОВАНИЕ ФИРМЫ, АДРЕС ПОСТАВЩИКА, ТЕЛЕФОН ПОСТАВЩИКА

     Таким образом зависимости НОМЕР НАКЛАДНОЙ à НАИМЕНОВАНИЕ ФИРМЫ, АДРЕС ПОСТАВЩИКА, ТЕЛЕФОН ПОСТАВЩИКА являются транзитивными. Следовательно нам необходимо провести декомпозицию отношения ОПЕРАЦИЯ купли на отношения:

     - поставщик (РНН ПОСТАВЩИКА, НАИМЕНОВАНИЕ ФИРМЫ, АДРЕС ПОСТАВЩИКА, ТЕЛЕФОН ПОСТАВЩИКА, КОД ТОВАРА);

     - ОПЕРАЦИЯ купли (НОМЕР НАКЛАДОЙ, ДАТА ПОКУПКИ, СТОИМОСТЬ ПОКУПКИ, КОЛИЧЕСТВО ЗАКАЗАННОГО ТОВАРА, КОД ТОВАРА)

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

4. ОПЕРАЦИЯ  ПРОДАЖИ (НОМЕР КАССОВОГО ЧЕКА, ДАТА РЕАЛИЗАЦИИ, КОЛИЧЕСТВО ПРОДАННОГО ТОВАРА, ЦЕНА ТОВАРА, ФАМИЛИЯ КЛИЕНТА, ИМЯ КЛИЕНТА, ОТЧЕСТВО КЛИЕНТА, АДРЕС КЛИЕНТА, ТЕЛЕФОН КЛИЕНТА, КОД КЛИЕНТА, КОД ТОВАРА)

 

      Учет  операций купли товара ведется по номеру кассового чека продажи товара, который является уникальным для каждой операции. Тогда в качестве первичного ключа можно использовать атрибут НОМЕР КАССОВОГО ЧЕКА. 

     

• Все атрибуты являются атомарными, следовательно, отношение находится в 1НФ.
• Первичный ключ – простой и функциональная зависимость всех неключевых атрибутов от первичного ключа – полная, следовательно, отношение находится во 2НФ.
• Все неключевые атрибуты функционально зависят от первичного ключа.

        Но так как операции продажи  товара могут выполняться различным клиентам, то часть атрибутов зависит от неключевого атрибута  КОД КЛИЕНТА.

      КОД КЛИЕНТА à ФАМИЛИЯ КЛИЕНТА, ИМЯ КЛИЕНТА, ОТЧЕСТВО КЛИЕНТА, АДРЕС КЛИЕНТА, ТЕЛЕФОН КЛИЕНТА

     Таким образом зависимости НОМЕР КАССОВОГО ЧЕКА à  ФАМИЛИЯ КЛИЕНТА, ИМЯ КЛИЕНТА, ОТЧЕСТВО КЛИЕНТА, АДРЕС КЛИЕНТА, ТЕЛЕФОН КЛИЕНТА являются транзитивными. Следовательно нам необходимо провести декомпозицию отношения ОПЕРАЦИЯ ПРОДАЖИ на отношения:

     -     КЛИЕНТЫ (ФАМИЛИЯ КЛИЕНТА, ИМЯ КЛИЕНТА, ОТЧЕСТВО КЛИЕНТА, АДРЕС КЛИЕНТА, ТЕЛЕФОН КЛИЕНТА, КОД КЛИЕНТА); 

     - ОПЕРАЦИЯ ПРОДАЖИ (НОМЕР КАССОВОГО ЧЕКА, ДАТА РЕАЛИЗАЦИИ, КОЛИЧЕСТВО ПРОДАННОГО ТОВАРА, ЦЕНА ТОВАРА, КОД ТОВАРА) 

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

     Таким образом, в результате приведения отношений  к 3НФ получили следующие отношения: КЛИЕНТЫ, ПОСТАВЩИКИ, СКЛАД, ОПЕРАЦИЯ КУПЛИ, ОПЕРАЦИЯ ПРОДАЖИ, ТОВАР, ПЕРСОНАЛ.  

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

    Логическая  структура реляционной базы данных определяется совокупностью логически взаимосвязанных реляционных таблиц. Каждая реляционная таблица имеет структуру, определяемую реквизитным составом одного из информационных объектов полученной ИЛМ. Логические связи таблиц соответствуют структурным связям между объектами. Логическая структура реляционной базы данных, построенная на основе полученной ИЛМ, приведена на рис.2. На этой схеме реляционные таблицы представлены структурой, определяемой составом и последовательностью полей (атрибутов). Ключи выделены подчеркиванием. Логические связи изображены линиями между одинаковыми ключами связи. 

Рисунок 2. Реляционная модель БД 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

     2.4.2 Разработка схем  документов и запросов  пользователей 

     

1. ТОВАР

 
 
     

2. СКЛАД

 
 
 
     

3. ПЕРСОНАЛ

 
 
     

4. поставщик