Når du skriver et blogindlæg om databasemodellering, skal du være forberedt på, at din abstrakte model ikke opfylder de fleste læseres behov. Årsagen er enkel. Real-life databasemodeller er normalt skabt i tæt relation til specifikke forretnings- og udviklingskrav, mens blogmodellerne ikke er det.
De sidste par uger har jeg skrevet blogindlæg om at lave databasemodeller. Emnerne spændte fra en generel tilgang til databasemodellering gennem et simpelt onlineforum til en model for en mere kompleks onlineundersøgelse.
For hver databasemodel, jeg opretter, forsøger jeg klart at forstå forretningsdomænet og i mit sind finde ud af det store billede af modellen.
Udfordringen med abstrakt databaseudvikling
Normalt som en løsning arkitekt , tager jeg specifikke forretningskrav og konverterer dem til de tekniske detaljer om, hvad der skal oprettes fra den tekniske side:oversættelse fra forretningssproget til fagsproget – design af algoritmerne på et højt niveau og modellering af datakravene til algoritmerne.
Desværre kan jeg ikke blogge om de databasemodeller i den virkelige verden, som jeg laver på arbejdet. Dels er de meget specifikke for forretningsdomænet, og dels er jeg begrænset af fortrolighedsaftaler. Til bloggen laver jeg en rent abstrakt koncept uden specifikke forretningskrav bortset fra dem, som jeg forestiller mig eksisterer inden for forretningsdomænet. Nu er det fint; Jeg har en ret god fantasi, og jeg påpeger ofte, at dine krav kan være anderledes, når jeg beskriver de valg, jeg træffer. Men denne blogproces fik mig til at tænke over, hvor forskellig denne proces er fra at skabe modellerne i et rigtigt projekt.
Den virkelige udviklingsproces
I en reel situation ville jeg arbejde tæt sammen med udviklingsteamet efter at have skabt højniveauløsningen og det tekniske design i en interaktiv måde, så modellen passer til udviklingsbehovene.
Udviklerne klager måske over, at datamodellen er for normaliseret til at understøtte højtydende, eller de kan bede om yderligere normalisering på visse områder. Hvis der manglede alternative nøgler, ville udviklerne klage ret hurtigt, og vi ville også bemærke det under ydelsestest af databasen.
Vi vil overveje, hvad de nøjagtige feltlængder skal være baseret på den maksimale længde af de data, der skal lagres, og på design af skærmbilleder til input og visning af data. Selvfølgelig er de nøjagtige feltlængder i en konceptuel databasemodel ikke vigtige.
Vi vil arbejde gennem eksempler på, hvilke data der vil blive gemt i tabellerne, og hvordan de vil blive brugt af applikationen, og lave scripts til at præ-udfylde tabellerne til enhedstest af applikationen. På denne måde ville vi fange hjørnesager for at sikre, at modellen understøtter applikationens grænser.
Så dybest set vil vi massere modellen, indtil den virkelig understøtter systemets forretningsmæssige og ikke-funktionelle krav ved hjælp af en iterativ proces, indtil vi har udviklet en model til noget, som vi alle kan acceptere på trods af de indbyggede kompromiser.
Som jeg sagde, ville det være en meget iterativ proces, der kan fortsætte over mange måneder, mens applikationskoden, brugergrænseflader og applikationsgrænseflader udvikles.
Begrænsninger af velment feedback
I den nuværende blogsituation, mens mit ganske vist begrænsede antal læsere giver mig feedback på problemstillinger og udfordringer, som de observerer med modellerne, er det nødvendigvis overfladisk. Jeg tvivler på, at nogen af læserne direkte bruger modellerne til at oprette en applikation og opdage, hvad der virkelig virker, og hvor der er problemer.
Så kommentarerne som "model ikke gennemtænkt" er næsten helt sikkert rigtige. På den anden side er "der mangler FK'er" ret præcise, men forhåbentlig har jeg forklaret i artiklens tekst, hvorfor jeg medtager en fremmednøgle eller ej.
Konklusion
Nu, læs venligst ikke dette indlæg som en klage eller en kommentar om den feedback, som læserne giver, men jeg reflekterer over vanskeligheden ved at lave en databasemodel, når du ikke er i et miljø, der tillader en interaktiv udveksling med en iterativ udviklingsproces.
Der er sikkert andre situationer, hvor databasemodellere er afskåret fra udviklingsprocessen, men jeg har nu indset, hvor farligt det ville være, og hvor tilbøjelige til problemer de ville være.
Kan du forestille dig en databasemodel, der aldrig bliver ændret? Aldrig en enkelt justering af en kolonne, aldrig tilføjelsen af en fremmed nøgle, aldrig behovet for en ny tabel. Helt ærligt, den eneste situation, jeg kan forestille mig sådan, er, når applikationen, der bruger databasen, ikke længere udvikler sig og har nået en blindgyde:livets ende.