[stfinternational]

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.

[Alex]

Ett er-diagram borde väl räcka kan man tycka.

[Albax]

Jo, det är väl det man brukar använda. I och för sig säger ett ER-diagram inte så mycket om hur implementationen ser ut, utan är ju mer en modell av verkligheten, men det är nog det jag hade försökt med hur som helst. Det borde ju dock finnas något annat diagram som är lämpligare för uppgiften.

Du kan läsa mer om ER-diagram här:
http://www.databasteknik.se/webbkursen/er/index.html

[Conny Westh]

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.

[brokep]

Ursprungligen postat av ConnyWesth

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.

OMG. OMG. OMG. Nån har tydligen läst för länge på högskola.

En erfaren programmerare som bygger en liten sajt behöver inte alls bry sig om dessa tips. Om man vet vilken data man ska ha så ska man inte använda all tid i världen på att hitta en "bra modell". Bästa modellen är att göra det bara.

[stfinternational]

Tack för alla tips än så länge... Jag kanske måste förtydliga lite grand.

Den dokumentation vi behöver ta fram ska alltså vara ett verktyg (karta) så att vilken programmerare som helst ska kunna fortsätta att utveckla sajten bara han får denna dokumentation i sin hand. Som sagt, ett egendomligt krav från en egendomlig kund och inget som vi kom överrens om i början men nu är det som det är och vi måste hjälpa kunden genom att ta fram någon slags dokumentation.

Någon som har ett enkelt svar eller en mall på hur denna dokumentation bör/kan se ut?

[crazzy]

Originally posted by stfinternational@Nov 23 2008, 17:37
Tack för alla tips än så länge... Jag kanske måste förtydliga lite grand.
Den dokumentation vi behöver ta fram ska alltså vara ett verktyg (karta) så att vilken programmerare som helst ska kunna fortsätta att utveckla sajten bara han får denna dokumentation i sin hand. Som sagt, ett egendomligt krav från en egendomlig kund och inget som vi kom överrens om i början men nu är det som det är och vi måste hjälpa kunden genom att ta fram någon slags dokumentation.
Någon som har ett enkelt svar eller en mall på hur denna dokumentation bör/kan se ut?

Bara skriv ett textdokument med vad som lagras och vart med vilken datatyp osv..

[Karman]

Ursprungligen postat av brokep

OMG. OMG. OMG. Nån har tydligen läst för länge på högskola.

En erfaren programmerare som bygger en liten sajt behöver inte alls bry sig om dessa tips. Om man vet vilken data man ska ha så ska man inte använda all tid i världen på att hitta en "bra modell". Bästa modellen är att göra det bara.

Du beskriver en vanlig vattensfallsprocess, men det där ju till exempel inte tilllämpningsbart på en SCRUM-process.