Citat:
Originally posted by stfinternational@Nov 22 2008, 15:07
Det ska tydligen finnas någon standardiserad form av dokumentation som man bör upprätta över databasen när man gör en mer avancerad sajt så att vilken programmerare som helst kan ta över och enkelt hitta i databasen om han får tillgång till denna dokumentation.
Jag har aldrig behövt upprätta sådan dokumentation till någon kund tidigare men har nu en kund som vill ha en "standardiserad dokumentation" upprättad över MySQL databasen.
Finns det någon här som har en mall över hur en sådan dokumentation bör se ut alternativt en befintlig dokumentation över en databas som ni jobbat med som anses som "standardiserad dokumentation"? En länk till en hemsida som förklarar detta tas också tacksamt emot.
|
Man brukar skapa ett ER (Entity Relationship)-diagram eller ett UML diagram.
Man tar ALDRIG fram en dokumentation av databasen i efterhand, man börjar med att jobba med dokumentation långt INNAN man börjar implementera saker i databaser elelr olika programspråk, annars har man inte koll på utvecklingsprocessen alls.
Sitter man i skiten och har klantat till det så man tappart dokumentationen så är man tvingad att dokumentera i efterhand, men då sitter man riktigt i skiten egentligen.
Här nedan specar jag de mest elementära formerna av dokumenattion som absolut KRÄVS för att få ordning på ett system. Om maninte har så bra koll att man inte ens planerar denna dokumentation ska man över huvud taget inte fundera på att starta ett utvecklings projekt. Det kommer att kosta okontrollerat mycket pengar och kommer inte att vara ett förutsägbart resultat.
Verksamhetsbeskrivning
När man börjar utveckla applikationer så utgpr man ALLTID från en dokumenterad verksamhetsbeskrivning.
Verksamhetsutveckling
Ofta innebär utredningen av hur verksamheten fungerar att man upptäcker bister som är av organisatorisk- eller verksamhets-karaktär, då genomför man en verksamhetsutveckling och konstruerar en ny verksamhetsmodell. Det är denna nya verksamhetsmodell som ligger till grund för Verksamhetskraven...
Verksamhetskrav
Från verksamhetsbeskrivningen och ett antal workshops med nyckelpersonr bland användare tar man fram verksamhetskrav på systemet.
Konceptuell datamodell
Utifrån verksamhetsraven tar man fram en konceptuell datamodell. Den innehåller ett antal objekt kman kunnat identifiera från kravdokumentationen och alla primärnycklar man kunnat identifiera, samt relationer mellan objekten (dubbelriktade relationer kan förekomma). Denna konceptuella modell presenteras i ett UML-diagram som kan diskuteras och stötas och blötas med kundens ansvariga.
Relationsdatabasmodell
När den konceptuella modellen har satt sig och inga fler ändringar sker så är det dags att fördjupa modellen till en reataionsdatabasmodell, då lägger man på andra attribut än primärnycklar och identifierar främmande nycklar samt reder ut alla relationer så att inga dubbelriktade relationer förekommer mellan objekten. Fortfarande så beskrivs modellen oftast i ett UML-diagram. Men vissa kan i detta läge gå över till ett logiskt Entity Relation diagram. Inga datatyper eller index är identifierade i detta skede.
Fysisk databasmodell
När man väl är nöjd med relationsdatabasmodellen så är det då dags att gå ned på djupet och välja vilken databas man ska jobba mot och vilk datatyper varje attribut ska ha, samt vilka indexeringar som ska ske för att göra en grov optimering (var försiktig med indexering då den ofta kan vänta till ett senare skede). Många nybörjare börjar optimera alldeles för tidigt och ägnar mycket onödig tid till sånt som kastas eller blir obolete senare i utvecklingsprocessen.
Här det det lämpligt med en Fysisk ER-modell men UML funkar det oxo. Personligen tycker jag verktyget ERWin ger ett betydligt bättre överblick av databasens struktur än ett UML-diagram.