@Emil: Zum Datenbankentwurf kann ich dir keine Software empfehlen. Ich hab dazu in den letzten 20 Jahren alles mögliche an kommerzieller und selbstgeschriebener Software ausprobiert. Aber etwas wirklich befriedigendes hab ich nicht gefunden. Gut, ich bin kein Wirtschaftsinformatiker, sondern komm aus dem systemorientierten technischen Zweig, entwickle Software für Industrieanlagen, und da sind die Anforderungen deutlich andere.
Aber vielleicht nützt dir folgendes etwas: Ich entwerfe Datenbanken nach der Methode von Prof. Kern. Das ist erst einmal das ganz gewöhnliche Entity Relationship Modell, und dann kommt Kern`s Methode zum Einsatz. Eine brauchbare (und kurze!) Beschreibung des ER Modells findest du in Moor, SQL Datenbanken. Interessant sind die ersten 30 oder 40 Seiten.
Zu Kern`s Methode gibt es nur Scripten der FH München, hab zumindest bei Amazon nichts gefunden.
Was du brauchst ist: Ein großes Blatt Papier, einen Stift, um den ersten Entwurf zu zeichnen und dann ein paar Buntstifte (und, falls vorhanden, ein paar farbige Marker). Damit kringelst du alle 1 zu 1 Relationen ein, markierst 1 zu n Relationen und überlegst dir, welche Eigenschaften du verschieben musst, welche Tabellen du zusätzlich brauchst, welche du zusammenfassen kannst und so weiter, bis du den Entwurf in 3NF hast. Üblicher weise musst du dazu den Entwurf 3, maximal 4 mal zeichnen, bis du ihn auf 3NF gebracht hast.
Den Rest kennst du ja.
Die Methode ist zwar sehr schnell, aber wenig flexibel. Wenn du irgend etwas ändern willst, geht das Spiel von vorne los. Anschließend kannst du ja den Entwurf mit irgend einer Software (Visio, Enterprise Architect, Workbench oder was auch immer) noch mal sauber zeichnen, falls dein Auftraggeber (oder Big Boss) das will.
@michi7x7: ERDs sind kein Schrott sondern zwingende Voraussetzung, um Datenbanken oder objektorientierte Software entwerfen zu können. Sobald ein Projekt mehr als 3 Klassendefinitionen enthält, kommst du beim Entwurf ohne ERD nicht mehr aus.
Bei UML muss ich dir jedoch (bedingt) zustimmen. Die 14 Diagramme von UML 2 sind deutlich zuviel, und trotzdem kann man nicht alles darstellen, was man gelegentlich braucht. Das gilt speziell für verteilte Prozesse mit nur zeitweise verfügbaren Resourcen. Trotzdem geht auch das: Mit etwas Nachdenken kann man auch das Problem der speisenden Philosophen in UML aufzeichnen. Nur: Besonders instruktiv wird das nicht…
Gar nicht zustimmen kann ich dir bei der Behauptung, es sei „unmöglich modernes C++ in Diagrammen nachzubilden“. Das Gegenteil ist der Fall. Solltest du eines deiner Projekte nicht in UML abbilden können, dann ist beim Entwurf etwas gewaltig in die Hose gegangen.
Selbst wenn du nicht innerhalb einer Gruppe arbeitest, sondern alleine, kann ich dir nur dringend empfehlen, strukturiert vorzugehen. Ich zwinge meine Mitarbeiter nicht umsonst, immer konsequent nach dem Baseball Modell zu arbeiten: OOA, OOD und zuletzt OOP. Wobei das Baseball Modell es nach jedem Schritt erlaubt, zum vorigen zurück zu springen und dort nötige Korrekturen vorzunehmen. Ich denk, dass das eine sehr intuitive Vorgehensweise ist. Wobei es sich empfiehlt, die einzelnen Schritte (in lesbarer Form!) zu dokumentieren, wenn man nicht selbst sehr schnell den Überblick verlieren will.
Ob man sich jetzt der UML Symbolik bedient, oder sein Projekt auf andere Art dokumentiert, sielt dagegen keine so große Rolle. Entscheidend ist nur, dass sie von allen Beteiligten verstanden wird. Eine Dokumentation halte ich auch für kleine Projekte, an denen man nur alleine bastelt, für unbedingt nötig, da das Programm sonst nach spätestens einem halben Jahr nicht mehr „wartbar“ ist, man es selber nicht mehr vollständig versteht. Kommentare in der Source reichen dazu nicht aus. Und ich kann es mit meiner angeborenen Faulheit nicht vereinbaren, dann erst wieder tagelang ein Programm zu analysieren, nur weil ich etwas am verwendeten Verfahren ändern will…
Schalom,
Schlomo