Modelarea unei situații de diagramă ER

Am două entități numite "Biroul principal" și "Sucursala", care aparțin unei companii. Biroul principal poate avea 1 sau mai multe filiale.

Dar o companie poate avea doar un sediu principal, care este un loc central pentru toate celelalte sedii principale. Cum ar trebui să modelez această situație?

  1. Utilizați 2 entități, Principal și Branch , unde Principal va avea un atribut boolean Central . Cred că este rău, deoarece va duce la dependență tranzitorie?
  2. Au 3 entități Main , Branch și Central rând?
  3. Sau, în cele din urmă, să aveți 2 entități Principal și Branch , unde Main >

EDITAȚI | ×: O companie poate avea mai multe birouri principale.

0
Editarea dvs. contravine ceea ce ați spus mai devreme: compania are un singur birou principal . Vă rugăm să prezentați cerințele dvs. pentru ca postarea dvs. să fie consecventă.
adăugat autor Quassnoi, sursa
Care este diferența dintre sediul principal și biroul central? Și este întrebarea dvs. despre cum să configurați diagrama logică pentru entități sau ce tabele aveți în baza de date?
adăugat autor Gordon Linoff, sursa
Probabil ar trebui să revedeți numele entităților voastre, ele sunt predispuse la ambiguități.
adăugat autor Kjir, sursa

4 răspunsuri

Efectuați o relație unu-la-unu între Biroul principal și Company , apoi multi-la-unul dintre Branch birou .

Nu există o relație directă între Branch office și Company , dar se poate deduce cu ușurință prin intermediul codului Principal .

0
adăugat

În scopuri de modelare, probabil că veți avea trei entități: companie, sediu principal, sucursale. Compania ar avea o relație de la 1 la mai multe cu sediul principal; sediul principal ar avea o relație de la 0 la multe cu sucursala. Aceasta pare să capteze structura logică a datelor.

Cred că vă întrebați și despre structura fizică. Structurile logice pot fi cartografiate direct pe structurile fizice, dar acest lucru nu este necesar. Întrebarea se referă la modul în care vor fi utilizate datele.

O implementare rezonabilă a modelului logic ar avea un tabel de companie și un tabel cu birouri unice, cu:

  • un steag care specifică dacă este un sediu principal sau o sucursală
  • o cheie de auto-alăturare pentru filialele care se îndreaptă spre biroul principal, cu constrângerea că "meciul înapoi" trebuie să fie un birou principal
  • o grămadă de câmpuri comune tuturor birourilor
  • un număr mic de câmpuri comune unui tip sau alt tip

O altă implementare rezonabilă ar pune birourile principale și filialele în diferite mese. Aceasta se apropie de modelul logic al datelor. Cu toate acestea, îmi imaginez că o mulțime de întrebări ar fi unirea acestor două mese, făcând abordarea tabelului unic mai eficientă în practică (dar nu neapărat).

Din păcate, bazele de date relaționale nu pun foarte bine în aplicare ideea moștenirii clasei.

0
adăugat

Poate doriți să utilizați moștenirea în modelul dvs. E-R. Aveți o superclasă generică pentru Office și subclasele Sucursale/Principale. Compania va avea o relație Mulți-Unu cu Biroul Principal și o relație One-One cu Biroul Principal pentru a reprezenta biroul central.

0
adăugat

Creați entitate Companie și Entită Office. Creați relații de la 1 la M de la Companie la Office . Oficiul are un tip - fie Main , fie Branch . Creați relații de la 1 la M din Office în sine. Această relație recursivă este asocierea unei filiale la un sediu principal. În cele din urmă, adăugați o relație 1 la 1 din Office înapoi la companie, cu un nume de rol pentru a distinge relația ca identificând Office Central .

De asemenea, puteți face ca Office să aibă un tip super și să facă subtipuri principale și ramuri. Acest lucru vă va permite să modelați o relație 1 la M de la principală la filială și să afișați mai explicit regula de afaceri.

Ar fi grozav dacă aș putea lipi un fragment de model ER aici! Punctul cheie este că Office este singura entitate reală aici, iar principalele și sucursalele sunt sub-tipuri de Office. Central nu este o entitate deloc, ci este un rol de relație între un birou și companie.

0
adăugat