Wanneer u een blogbericht schrijft over databasemodellering, moet u erop voorbereid zijn dat uw abstracte model niet voldoet aan de behoeften van de meeste lezers. De reden is simpel. Real-life databasemodellen worden meestal gemaakt in nauwe relatie tot specifieke bedrijfs- en ontwikkelingsvereisten, terwijl de blogmodellen dat niet zijn.
De afgelopen weken heb ik blogposts geschreven over het maken van databasemodellen. Onderwerpen varieerden van een algemene benadering van databasemodellering via een eenvoudig online forum tot een model voor een complexere online enquête.
Voor elk databasemodel dat ik maak, probeer ik het bedrijfsdomein duidelijk te begrijpen en in mijn hoofd het grote plaatje van het model uit te werken.
De uitdaging van de ontwikkeling van abstracte databases
Normaal gesproken, als oplossing architect , ik neem specifieke zakelijke vereisten en zet die om in de technische details van wat er vanuit de technische kant moet worden gecreëerd:vertalen van de zakelijke taal naar de technische taal - het ontwerpen van de algoritmen op een hoog niveau en het modelleren van de gegevensvereisten voor de algoritmen.
Helaas kan ik niet bloggen over de echte databasemodellen die ik op mijn werk maak. Ten eerste zijn ze zeer specifiek voor het zakelijke domein en ten andere ben ik beperkt door vertrouwelijkheidsovereenkomsten. Voor de blog maak ik een puur abstracte concept zonder specifieke zakelijke vereisten, behalve degene die ik me voorstel binnen het zakelijke domein. Nu, dat is prima; Ik heb een redelijk goede fantasie en ik wijs er regelmatig op dat uw wensen anders kunnen zijn als ik de keuzes die ik maak omschrijf. Maar dit blogproces deed me nadenken over hoe anders dit proces is dan het maken van de modellen in een echt project.
Het real-life ontwikkelingsproces
In een echte situatie zou ik nauw samenwerken met het ontwikkelingsteam nadat ik de hoogwaardige oplossing en het technische ontwerp had gemaakt in een interactieve manier zodat het model past bij de ontwikkelingsbehoeften.
De ontwikkelaars kunnen klagen dat het datamodel te genormaliseerd is om hoge prestaties te ondersteunen, of ze kunnen op bepaalde gebieden om aanvullende normalisatie vragen. Als er alternatieve sleutels zouden ontbreken, zouden de ontwikkelaars vrij snel klagen en we zouden het ook merken tijdens het testen van de prestaties van de database.
We zouden overwegen wat de exacte veldlengtes zouden moeten zijn op basis van de maximale lengte van de gegevens die moeten worden opgeslagen en op ontwerpen van schermen voor invoer en weergave van de gegevens. Natuurlijk zijn de exacte veldlengtes in een conceptueel databasemodel niet belangrijk.
We zouden voorbeelden doornemen van welke gegevens in de tabellen worden opgeslagen en hoe deze door de toepassing zullen worden gebruikt, en scripts maken om de tabellen vooraf te vullen voor het testen van eenheden van de toepassing. Op deze manier zouden we de hoekgevallen opvangen om ervoor te zorgen dat het model de limieten van de applicatie ondersteunt.
Dus eigenlijk masseren we het model totdat het de zakelijke en niet-functionele vereisten van het systeem echt ondersteunt met behulp van een iteratief proces, totdat we een model hebben ontwikkeld tot iets dat we allemaal kunnen accepteren, ondanks de compromissen die erin zijn ingebouwd.
Zoals ik al zei, zou het een zeer iteratief proces zijn dat vele maanden zou kunnen duren terwijl de applicatiecode, gebruikersinterfaces en applicatie-interfaces worden ontwikkeld.
Beperkingen van goedbedoelde feedback
In de huidige blogsituatie, hoewel mijn weliswaar beperkte aantal lezers me feedback geeft over problemen en uitdagingen die ze met de modellen waarnemen, is het noodzakelijkerwijs oppervlakkig. Ik betwijfel of een van de lezers de modellen rechtstreeks gebruikt om een applicatie te maken en te ontdekken wat echt werkt en waar er problemen zijn.
Dus de opmerkingen als "model niet goed doordacht" zijn vrijwel zeker juist. Aan de andere kant zijn "er ontbreken FK's" vrij precies, maar hopelijk heb ik in de tekst van het artikel uitgelegd waarom ik een externe sleutel opneem of niet.
Conclusie
Lees dit bericht alsjeblieft niet als een klacht of een opmerking over de feedback die lezers geven, ik denk eerder na over de moeilijkheid om een databasemodel te maken als je niet in een omgeving bent die een interactieve uitwisseling met een iteratief ontwikkelingsproces.
Er zijn waarschijnlijk andere situaties waarin databasemodelleurs worden afgesneden van het ontwikkelingsproces, maar ik heb me nu gerealiseerd hoe gevaarlijk dat zou zijn en hoe vatbaar voor problemen ze zouden zijn.
Kunt u zich een databasemodel voorstellen dat nooit wordt gewijzigd? Nooit een enkele aanpassing van een kolom, nooit de toevoeging van een externe sleutel, nooit de noodzaak van een nieuwe tabel. Eerlijk gezegd, de enige situatie die ik me zo kan voorstellen, is wanneer de applicatie die de database gebruikt niet langer evolueert en op een dood spoor is beland:einde levensduur.