База данни ERD - таблица на връзките (от една към много) - mysql, база данни, erd

ОБЕКТИВЕН

Създайте таблица за Вземания на Сметки, за да въведете данни за фактура / плащане за клиенти. Данните ще се използват за определяне на показателите за застаряване на сметката.

ПОДХОД

1. Създавам customer таблица със съответната информация
2. Създайте invoice таблица със съответната информация (включително customerID)
3. Създавам payments маса, която е свързана customer и invoices заедно

СХЕМА НА ERD

БЕЛЕЖКИ

• 1 Фактурата може да има няколко плащания (например, клиентът прави частични плащания, докато фактурата не приключи)
• Всяко плащане е свързано с един клиент (няколко клиенти няма да плащат от името на друг клиент)

ВЪПРОС

1. Моят ли е един-към-един за Клиента> Плащания правилноВръзка? Клиентите ще плащат само своите фактури, така че считам, че това е връзка „един към един“. Въпреки това, един клиент може да има много плащания (за различни фактури).
2. Ако един клиент извършва многократни плащанияедна фактура, възнамерявам да разгранича плащанията с "date_paid" (таблица за плащания). Има ли по-надежден начин за разграничаване между 1 клиент, извършващ няколко плащания на 1 фактура?

Отговори:

1. Харесва ни клиенти, които правят повече от едно плащане. Плащането е свързано с един клиент. Но клиентът може да има нула, едно или повече плащания.

Връзката с външния ключ изглежда излишна, тъй като едно Плащане е свързано с точно една фактура (FK връзка) и Invoice е свързано с точно едно Customer (FK връзка.)

Наистина не е нужно да съхраняваме Cust_ID на Payment таблица. Ако го направим, ние даваме възможна аномалия. Няма нищо, което да пречи на фактурата да бъде свързана с клиент 11, а плащането по тази фактура да е свързано с друг клиент, 222.

2. Не бих използвал Date_Paid, за да разгранича. Не бихме искали да забраним на клиента да направи две (или повече) плащания на една и съща дата. (Клиентът иска да плати 100 лв. И погрешно прави плащане от 10 щ.д. ,

В моето мислене, Payment е действително лице, а не само връзка между Customer и Invoice образувания. Като такъв бих добавил идентификатор на обект. Ако погледнем съществуващата конвенция за именуване, това би било Payment_ID, Ще го направя първичен ключ на таблицата.