Proč utrácet peníze za datové modelování?
Fakt: Je stále poměrně běžnou praxí, že návrh databáze je ponechán na aplikačním vývojáři.
Struktura databáze je tak "ušita přímo na míru" aplikaci. Žádné složité modelování tak není potřeba. U malých společností, kde je za celý vývoj zodpovědný jediný pracovník, je pak použití modelovacích nástrojů vnímáno jako nepatřičný luxus. Jednak datový model i veškerou aplikační logiku "nosí" takový člověk v hlavě, a ještě navíc pro něj znamená použití specializovaného nástroje další finanční investici a také více práce. U větších společností se CASE nástroje většinou používají, ale často pouze jako generátor skriptů pro vytvoření schématu databáze. Cena kvalitních nástrojů pro datové modelování se pohybuje v řádech desítek tisíc korun. To zvláště v dnešní době není zanedbatelná suma. Lze vůbec počítat s nějakou návratností takové investice?
Pokud strukturu databáze navrhne programátor a připraví příslušné CREATE skripty pro vytvoření databáze, bude s vysokou pravděpodobností vše fungovat bez větších problémů. Je zde však několik ale:
Výkon? - Struktura ideální pro aplikaci nemusí být ideální i pro databázový stroj. Při malých objemech dat (předání aplikace a zahájení provozu) se takové nedostatky nemusí vůbec projevit. Po určitém čase se však mohou začít objevovat problémy s odezvou a výkonem databáze. Nevhodně navržené schéma lze jen obtížně optimalizovat bez zásahu do aplikace. Ať se již uživatel nakonec rozhodne jít cestou úpravy kódu nebo navýšení výkonu na straně DB, znamená to v každém případě vícenáklady. Ale s tím, že se nabídnutá cena od té finální významně liší, jsme se už všichni smířili a od začátku s tím počítali. Nebo ne?
Kvalita? - Dodavatelé aplikací si často (a často i právem) stěžují na kvalitu zadání. Bez použití CASE nástroje nelze s uživatelem diskutovat nad srozumitelnou grafickou podobou modelu nebo například ukládat k jednotlivým objektům informace proč a na základě kterého požadavku byl kód navržen či modifikován právě tímto způsobem. Nakonec, i při sebelepší vůli obou stran, se celá řada námětů a potřeb objeví až po nějaké době reálného provozu nového systému. I přidá se tabulka, uložená procedura či nový pohled. Zde se však již bez nástroje pro datové modelování dá jen obtížně zajistit, aby prováděné změny neměly negativní dopad na již existující objekty, nebo se naopak některá data neukládala duplicitně. Problémy vzniklé vinou změn či následně sníženou kvalitou dat lze však jistě alespoň z části vyřešit v čase, který byl ušetřen na modelování. Takže nepoužívat modelovací nástroj je vlastně dobře, že?
Dokumentace? - Když už uživatel data do systému trpělivě vkládá, očekává možnost s nimi následně pracovat. Kromě bohaté nabídky předpřipravených sestav vyžaduje někdy uživatel i takzvané „Ad hoc" dotazy nebo dokonce možnost data analyzovat. Vzhledem k absenci CASE nástroje jsme také ušetřili čas, který by padl na návrh jmenných konvencí, optimalizaci schématu nebo vygenerování dokumentace (stejně by ji nikdo nečetl). Vždyť se analytik při budování datového skladu nebo při snaze o integraci s novou aplikací může kdykoliv s důvěrou obrátit na programátora. Pracuje teď už, pravda, u jiné firmy, ale mlhavě si ještě pamatuje, že objem reklamací se dá získat z tabulek "UR_PRI_VSE2", "TYP_R_20667", "POM_TB17" a "PROD_SKL_TEMP"."Ano, cena tam je uvedena s daní. Tedy alespoň myslím. A kdyby ne, kdo si toho všimne? Počítač má vždycky pravdu!"
Produktivita? - Na prvním projektu může důsledné použití modelovacích nástrojů a metodik znamenat prodloužení vývoje až o 30%. U druhého a každého dalšího projektu však již nástroj přináší výrazné zvýšení productivity a zkrácení doby vývoje. O kvalitě a udržovatelnosti výsledných aplikací nemluvě. Ale to se nás nejspíš netýká; každý náš projekt je unikátní a neopakovatelný.
Máte obavy, že by se to mohlo týkat i Vašeho systému či aplikace? Klid, to všechno si vymysleli prodejci CASE nástrojů, pro zvýšení prodeje, v praxi se to vůbec neděje!