nicht angemeldet
Hi Bio,
ohne die Leistung der Self-Autoren damit in Frage stellen zu wollen, aber Datenbankdesign lässt sich auch nicht so leicht formalisieren, wie die Verwendung eines vorgegebenen Rahmens für HTML.
Datenbankdesign ist doch beinahe Geheimwissen ;-)
Oder zumindest soviel weniger nachgefragt als HTML-Wissen, daß noch niemand Self-Datenbankdesign geschrieben hat.
Das ist deshalb Geheimwissenschaft, weil man unter Beachtung aller Regeln (totale Normalisierung, Redundanzfreiheit) wahrscheinlich nie zum Ziel kommt und immer fallbezogen an einigen Stellen davon abweichen MUSS, aber eben an den richtigen. Und das ist Philosophie.
Es gibt gute Versuche, eine Formalisierbarkeit herzustellen. Siehe ACCESS (ist ja leider nie fertig geworden). Oder den Oracle Developer 2000.
Ich gebe mal den Rat:
1. Papier, Bleistift, und Radiergummi bereit halten
2. Einsammeln sämtlicher bisher verwendeter Formulare, Papiere, Ausweise, Rechnungen, etc.
3. Stoffsammlung anlegen (einfach wild alle zu verwaltenden Werte auf ein groooßes Blatt schreiben)
4. Überprüfung, ob sich alle Formulare und Abläufe mit der Menge der gesammelten Werte (Variablen, Felder) darstellen lassen.
5. Regelwerk beschreiben "was passiert dann Maschine"
6. Variablenhaufen durchstrukturieren (Sinngruppen bilden)
7. Normalisierungsverfahren anwenden: welche Felder sind in den gebildeten Datensätzen ähnlich (z. B. hat ein Musterdatensatz vier Telefonnummern für privat, Firma, Sekretariat und Auto) Hier muss eine extra Tabelle angelegt werden. Oder in der vertikalen Richtung: ein komplexer Datenwert kommt immer wieder vor (Kurmittelhaus Garmisch-Partenkirchen). Dann muss er in eine seperate Tabelle mit Nachschlagewert.
8. Validierungen (Konsistenz)
9. Metadaten
10. Geschäftsregeln (Integrität)
11. ...
Das sollte für's erste genügen.
Liebe Grüße
Tom