Když píšete blogový příspěvek o databázovém modelování, musíte být připraveni, že váš abstraktní model nesplňuje potřeby většiny čtenářů. Důvod je prostý. Modely reálných databází jsou obvykle vytvářeny v úzkém vztahu ke specifickým obchodním a vývojovým požadavkům, zatímco modely blogů nikoli.
Posledních pár týdnů píšu na blog příspěvky o vytváření databázových modelů. Témata sahala od obecného přístupu k databázovému modelování přes jednoduché online fórum až po model pro složitější online průzkum.
U každého databázového modelu, který vytvořím, se snažím jasně porozumět obchodní doméně a vypracovat si v duchu celkový obraz modelu.
Výzva vývoje abstraktní databáze
Normálně jako řešení architekt , beru konkrétní obchodní požadavky a převádím je do technických detailů toho, co je potřeba vytvořit z technické stránky:překládání z obchodního jazyka do technického – navrhování algoritmů na vysoké úrovni a modelování datových požadavků pro algoritmy.
Bohužel nemohu blogovat o modelech skutečné databáze, které vytvářím v práci. Jednak jsou velmi specifické pro obchodní doménu a za druhé mě omezují dohody o mlčenlivosti. Pro blog tvořím čistě abstraktní koncept bez specifických obchodních požadavků kromě těch, o kterých si myslím, že existují v obchodní doméně. Teď, to je v pořádku; Mám docela dobrou představivost a často upozorňuji, že vaše požadavky se mohou lišit, když popisuji volby, které dělám. Ale tento proces blogování mě přiměl přemýšlet o tom, jak se tento proces liší od vytváření modelů ve skutečném projektu.
Proces vývoje v reálném životě
V reálné situaci bych po vytvoření řešení na vysoké úrovni a technického návrhu v interaktivní úzce spolupracoval s vývojovým týmem způsobem, aby model vyhovoval vývojovým potřebám.
Vývojáři si mohou stěžovat, že datový model je příliš normalizovaný na podporu vysokého výkonu, nebo mohou požádat o další normalizaci v určitých oblastech. Pokud by nějaké alternativní klíče chyběly, vývojáři by si velmi rychle stěžovali a také bychom si toho všimli při testování výkonu databáze.
Zvažovali bychom, jaké přesné délky polí by měly být založeny na maximální délce ukládaných dat a na návrzích obrazovek pro zadávání a zobrazování dat. Samozřejmě, přesné délky polí v koncepčním databázovém modelu nejsou důležité.
Propracovali bychom příklady toho, jaká data budou v tabulkách uložena a jak je aplikace využije, a vytvořili bychom skripty pro předvyplnění tabulek pro unit testování aplikace. Tímto způsobem bychom zachytili rohová pouzdra, abychom zajistili, že model podporuje limity aplikace.
Takže v zásadě bychom model masírovali, dokud skutečně nepodporoval obchodní a nefunkční požadavky systému pomocí iterativního procesu, dokud bychom nevyvinuli model v něco, co můžeme všichni přijmout navzdory kompromisům, které jsou v něm zabudované.
Jak jsem řekl, byl by to velmi iterativní proces, který by mohl pokračovat po mnoho měsíců, zatímco se vyvíjí aplikační kód, uživatelská rozhraní a aplikační rozhraní.
Omezení dobře míněné zpětné vazby
V současné blogovací situaci, i když mi můj nepochybně omezený počet čtenářů poskytuje zpětnou vazbu ohledně problémů a výzev, které s modelkami pozorují, je to nutně povrchní. Pochybuji, že některý ze čtenářů přímo používá modely k vytvoření aplikace a zjištění, co skutečně funguje a kde jsou problémy.
Takže komentáře jako „model není dobře promyšlený“ jsou téměř jistě správné. Na druhou stranu „chybí FK“ jsou poměrně přesné, ale doufám, že jsem v textu článku vysvětlil, proč cizí klíč uvádím nebo ne.
Závěr
Nyní prosím nečtěte tento příspěvek jako stížnost nebo komentář ke zpětné vazbě čtenářů, spíše přemýšlím o obtížnosti vytvoření databázového modelu, když nejste v prostředí, které umožňuje interaktivní výměnu s iterativní vývojový proces.
Pravděpodobně existují i jiné situace, kdy jsou databázoví modeláři odříznuti od procesu vývoje, ale nyní jsem si uvědomil, jak nebezpečné by to bylo a jak náchylní k problémům by byli.
Dokážete si představit databázový model, který se nikdy nezmění? Nikdy jediná úprava sloupce, nikdy dodatek cizího klíče, nikdy potřeba nové tabulky. Upřímně řečeno, jediná situace, kterou si takto dokážu představit, je situace, kdy se aplikace využívající databázi již nevyvíjí a dospěla do slepé uličky:konce životnosti.