Notace vraní nohy

Vraní noha - správně notace Information Engineering - klade na každý konec čáry vztahu dvě značky. Ta dál od entity je maximum a ta blíž k entitě je minimum.

Zkombinujte je a možností jsou přesně čtyři, a to je celá notace:

Tohle je jediná věc na vraní noze, která je opravdu proti intuici, a odpovídá za většinu špatně přečtených diagramů. Symboly na konci popisují entitu na tom konci a čtete je, když cestujete k té entitě.

Na čtvrté čáře diagramu výše je vraní noha na konci u Order. Neznamená to „mnoho zákazníků“. Znamená to: pro jednoho zákazníka je nula nebo více objednávek. Řekněte to jako cestu - „začínám u zákazníka, jdu po čáře a dorazím k nule nebo více objednávkám“ - a směr přestane být dvojznačný.

Praktický návyk, který problém odstraní úplně: napište na čáru slovesnou frázi ve směru, v jakém se čte zleva doprava, a než půjdete dál, přečtěte nahlas opačné čtení. Třicet sekund na vztah - a zachytí to chyby, které v dokumentu přežijí měsíce.

Styl čáry nese druhou informaci a je o klíčích, ne o počtech.

Testem je jedna otázka: šel by tenhle řádek identifikovat bez znalosti jeho rodiče? Položka objednávky číslo 3 nedává smysl, aniž bychom věděli, které objednávky - to je identifikující. Objednávka patřící zákazníkovi 41 je pořád objednávka 8817 bez ohledu na to - to je neidentifikující.

Vraní noha na obou koncích říká „mnoho k mnoha“ a žádná relační databáze to ve dvou tabulkách neuloží. Vztah se stane samostatnou entitou - vazební, asociační nebo spojovací - která drží cizí klíč na každou stranu.

Z toho plynou dvě věci a ta druhá je důvodem, proč se to vyplatí udělat brzy a ne až při implementaci:

1. Vazební entita má obvykle vlastní atributy. Zápis má datum, známku, stav. Ty atributy neměly kde bydlet, dokud byl vztah čarou, a jejich absence skrývala mezeru v modelu.
2. Vazební entita si zaslouží skutečný název. Enrolment, Booking, Assignment - ne StudentCourse. Doménový expert první zná a druhý nedokáže revidovat, a ten název bývá slovem, které byznys už používá.

Všimněte si klíčů ve vazební entitě výše: oba cizí klíče dohromady tvoří primární klíč, a právě to zabrání tomu, aby se tentýž student zapsal na tentýž kurz dvakrát. To omezení přišlo zdarma z pořádného namodelování a jinak by bylo validací, na kterou si někdo vzpomněl.

Nic z toho se nevylučuje. Spousta reálných projektů kreslí vraní nohu pro databázi a diagram tříd pro doménový model a drží obojí, protože odpovídají na jiné otázky o týchž podstatných jménech.

1. Symboly na špatném konci. Nejčastější chyba v téhle notaci. Přečtěte obě věty nahlas.
2. Všechno nepovinné. Kroužek na každé vnitřní pozici znamená, že model netvrdí žádná pravidla - a každé z nich se místo toho stane aplikačním kódem.
3. Vztah M:N ponechaný v logickém modelu. Konceptuálně v pořádku, fyzicky nemožné. Vyřešte ho a vazební entitu pojmenujte.
4. Vazební entity pojmenované zřetězením. OrderProduct recenzentovi neřekne nic; OrderLine mu řekne všechno.
5. Spoléhání jen na styl čáry u identifikujících vztahů. Nástroje se neshodnou. Ukažte složený klíč i v boxu.
6. Neoznačené vztahy. Sloveso je to, co dělá čáru čitelnou nahlas - a čtení nahlas je tou revizí.

Když je kardinalita vyřešená, další otázkou je, jaké tabulky vlastně mají být - a to je návrh schématu: klíče, normalizace a cesta od modelu k DDL.