Проектирование базы данных управления деятельности сети магазинов сотовой связи «Компани"LIFE:)"

     Таблица 2.20 Проверка отношения Rzt2 на НФБК

 

2. Rzt3 (№_zapros, Date_zapr, K_shop),

 
 
 

 
 
 
 
 
 

3. Rtz4 (№_zapros, N_goods, Kolvo_goods)

 
 
 
 
 

     Таблица 2.21 Проверка отношения Rzt3 на НФБК

 

     Таблица 2.22 Проверка отношения Rzt4 на НФБК

 

     Отношения базы данных по документу «Заявка на выдачу товара» (темно-серым цветом выделены вероятные первичные ключи)

 
 
 
 
 
 
 
 

Документ  №5.«Акт приема-передачи денежных средств» 
 

 
 
 
 
 
 
 
 
 
 
 
 

Схема 2.5 Структурная единица информации документ «Акт приема-передачи денежных средств»в графическом виде. 

Таблица 2.23 Универсальное отношение документа  «Акт приема-передачи денежных средств» 

 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

Рис. 2.5 Диаграмма  функциональной зависимости реквизитов документа .«Акт приема-передачи денежных средств»

Таблица 2.24 Проверка полученного отношения на НФБК 

Данное  отношение не находится в НФБК, т.к. детерминанты не совпадают с вероятностными ключами, разделим отношение Rakt (№_akt, K_shop, Tel_№, Address, Name_incasator, K_sum, Date_akt) на два отношения не нарушая целостности данных:

Rakt1 (№_akt, K_shop, Name_incasator, K_sum, Date_akt);

 
 
 
 
 

Rakt2 (K_shop, Tel_№, Address);

 
 
 

Проверим полученные отношения на НФБК:

     Таблица 2.25 Проверка отношения Rakt1 на НФБК.

     Таблица 2.26 Проверка отношения Rakt2 на НФБК.

 

     Данное  отношение находится в НФБК, т.к. детерминанты совпадают с вероятностными ключами.

     Отношения базы данных по документу «Акт приема передачи денежных средств» (темно-серым цветом выделены вероятные первичные ключи):

 

Документ  № 6.Ежедневный отчет 

 
 
 
 
 
 
 
 
 
 
 
 

Рис. 2.6 Диаграмма  функциональной зависимости реквизитов документа «Ежедневный отчет» 

     Таблица 2.27 Проверка полученного отношения на НФБК.

 

Данное отношение  не находится в НФБК, т.к. детерминанты не совпадают с вероятностными ключами, разделим отношение Rrep (Rep_№, Date, K_shop, N_goods; Sum_$; Kolvo_goods) на два отношения не нарушая целостности данных:

Rrep1 (Rep_№, Date, K_shop; Sum_$)

 
 
 
 
 

Rrep2 (Rep_№, N_goods, Kolvo_goods)

 
 
 
 
 

     Таблица 2.27 Проверка отношения Rrep1 на НФБК.

     Таблица 2.28 Проверка отношения Rrep2 на НФБК. 

 
 

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

     Необходимые отношения:

1. Rdg3 (№_doc, Date, Tov_from, Tov_to)
2. Rdg4 (№_doc, N_goods, Kolvo_goods)
3. Rinv2= Rpn2 (N_goods, Type_goods, Ed_izm, K_price)
4. Rinv3 (№_inventar, Date_begin, Komissia,  Date_end)
5. Rinv4 (№_inventar, N_goods, Kolvo_goods)
6. Rpn1 (Nakl_№,  N_goods Date_nakl, K_shop, Name_post, Kolvo_goods)
7. Rpn3 (N_goods, Nakl_№, Kolvo_goods)
8. Rzt3 (№_zapros, Date_zapr, K_shop),
9. Rakt2 (K_shop, Tel_№, Address);
10. Rtz4 (№_zapros, N_goods, Kolvo_goods)
11. Rakt1 (№_akt, K_shop, Name_incasator, K_sum, Date_akt);
12. Rrep1 (Rep_№, Date, K_shop; Sum_$)
13. Rrep2 (Rep_№, N_goods, Kolvo_goods)

Избыточные: Rdg1 (N_goods, Ed_izm, N_price), Rzt1 (N_goods, Type_goods, Ed_izm). 
 
 

 

2. . Построение БД методом ER-проектирования

 

       Проанализировав структуру информационного пространства могу выделить следующие сущности:

• Магазин;
• Товар;
• Накладная прихода товара;
• Заявка на выдачу товара;
• Акт приема-передачи денежных средств;
• Ежедневный отчет;
• Инвентарная опись;
• Форма движения товара.

       И связи между ними представленные на рис. 2.7.

       Под сущностью понимается "нечто", что можно идентифицировать. Сущности могут попадать в различные типы сущностей, которые на ER-диаграммах изображаются в виде прямоугольников. Реальный мир содержит множество объектов, которые можно четко идентифицировать. Некоторые из них интересны при моделировании, другие - нет. В задачи проектировщика входит отобрать именно те типы сущностей, которые нужны и будущей информационной системе.

       Между сущностями могут существовать связи. Связи разделяются на различные типы связей. На диаграммах ER-моделей связи изображаются в виде ромбов, соединенных линиями со связываемыми типами сущностей. 
 

 

 

 

 
 
 

Рис. 2.7 Диаграмма ER-типа 

 

Охарактеризую полученные отношения:

1. В ежедневном отчете отражается  сумма из акта приема-предачи денежных средств. Согласно правил ER-проектирования для бинарной связи 1:1 и классом принадлежности обязательное и необязательное строятся 2 таблицы: одна с ключом необязательной сущности, другая для связи с ключом любой из сущностей.

R1 (Rep_№, K_shop);

R2 (№_akt; K_shop;Rep_№).

2. В ежедневном отчете отражается товар, согласно правилам для отношения с бинарной связью 1:n с классовой принадлежностью обязательное - необязательное строится 3 предварительные отношения: по одному для каждой сущности и третья для связи, ключом которой является составной ключ сущности n.

R3 (Rep_№);

R4 (N_goods);

R5 (Rep_№, N_goods; ).

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