Erstellen einer Datenbank: Schrittweises Vorgehen in der Praxis?

Dinkel

Grünschnabel
Hi,
ich hatte im Uni-Studium bisher nur die Veranstaltung "Datenbanksysteme I" und muss jetzt im Studi-Job in einer Firma für eine Abteilung eine Access-Datenbank erstellen. In der Vorlesung wurde immer die schrittweise Vorgehensweise betont:

-Informelle Beschreibung: Pflichtenheft
-Konzeptioneller Entwurf: E/R-Diagramm
-Relationaler DB-Entwurf: Relationenschema (Normalisierungstheorie als formale Grundlage für den relationalen DB-Entwurf)

Jetzt frage ich mich natürlich, wie das die Profis in der Praxis machen und hoffe, dass sich der ein oder andere findet und hier postet. Also ich hätte folgende Fragen:

-Ist das wirklich die Vorgehensweise in der Praxis bzw. kann bitte jemand etwas mehr darüber schreiben?
-Gibt es vielleicht spezielle Software, die hilfreich ist (ich habe gelesen, dass sich z.B. "Microsoft Visio" für E/R-Diagramme anbietet, wobei ich nicht entdecken konnte, ob man daraus auch Tabellen generieren kann)?
-Verwendet ihr wirklich den Synthesealgorithmus, um die 3. Normalform zu bekommen?
-Wie wichtig sind die insgesamt 6 Normalformen überhaupt?

Danke!

Gruß,
Dinkel
 
Kommt schon Leute, 83 Leser und niemand der etwas posten möchte? ;)
Eventuell gibt es hier kaum/keine "Datenbanker", aber auch in diesem Fall bitte kurz posten (gerne auch ein gutes, spezielles Forum empfehlen).

Danke!
 
Natürlich kann man das so 1 zu 1 in der Praxis auch machen. Nur stellt sich natürlich die frage, wie sinnvoll das ist. Bei komplexen Datenstrukturen und einer von vorne herein großer Skalierbarkeit macht es bestimmt Sinn.
Die meisten Leute hier werden aber Datenbanken im Webapplikationsbereich einsetzen. Da wird das sicherlich nicht oft (eigentlich nie) gemacht. Für die Vereinswebseite, für ein Loginsystem, uvm werden viele einfach (für Mysql) in PHPMyAdmin gehen, ein bisschen rumklicken, und fertig ist die Datenbank.
 
Hi

Pflichtenheft: Kommt drauf an, für wen/wozu man eine DB macht.
Pflichten-/Lastenheft macht Sinn, wenn man gegenüber einem Kunden genau festlegen will,
was man für xy € tut (und alles, was nicht drinsteht, kostet zusätzlich. So ungefähr)
Aber ins Detail zu gehen macht im Allgemeinen keinen Sinn.
Man kann/soll schon sagen, man macht ein Programm das kann A, B, C,
und eine Oracle-DB ist vorhanden, also soll das Programm
die möglichst verwenden statt einer anderen.
Aber keine Tabellenstrukturen etc. reinschreiben


Konzeptioneller Entwurf etc.:
Da stimm ich alxy voll zu.
Solange man nichts mit Datenmengen im Bereich von Google etc. vorhat,
sondern nur "irgendeine" normale Seite...
man kann die ganzen Schritte, Diagramme etc. natürlich machen, wenn man denkt,
man tut sich damit leichter; aber mit etwas Übung ist das dann nur noch Zeitverschwendung.

Was ich gern mach ist, zuerst mal in Deutsch/Englisch zusammenschreiben,
was alles gespeichert werden soll. Dazu eventuell, wovon man wieviel erwartet
und wie oft welche Daten ungefähr gebraucht werden.
Daraus gehts dann ohne Umwege zum SQL weiter.
(oder PHPmyAdmin oder was man eben gern hat)


Synthesealgorithmus verwendet: Nein.


Wie wichtig NFs sind:
Hmm... NF 1 sehr hilfreich, dann abnehmend bis zu NF 5, die alles nur sinnlos umständlich macht :D
(Das, was man bei DBs NF1 nennt hilft wirklich viel. Nicht nur bei Datenbanken)
 
Zuletzt bearbeitet:
Danke erstmal für die Beiträge.

Also soweit ich das überblickt habe kommt da schon einiges an Relationen bzw. Attributen zusammen, von daher ist es denke ich sinnvoll, wenigstens auf Deutsch/Englisch vorher alles aufzuschreiben.

Vielleicht nochmal zu den Normalformen: Es überrascht mich, dass die Normalform anscheinend doch nicht so wichtig in der Praxis sind, denn die Beispiele auf Wikipedia zeigen, dass es doch ziemlich schnell zu Inkonsistenzen kommen kann... Wird das wirklich so lax gehandhabt? :p
 
(Die NF1 bleibt unerwähnt, weil die praktisch Pflicht ist).

Eines von den Sachen, die ich aufschreibe, ist ja
"wovon man wieviel erwartet und wie oft welche Daten ungefähr gebraucht werden."
Der Grund ist vor allem, eine DB zu erstellen, die so wenig Speicher wie möglich braucht
und häufige Abfragen möglichst schnell ausführt.
Wirkt sich nicht nur in Indizes etc. aus, sondern auch schon bei der Tabellenstruktur.

Das Witzige an der Sache ist, dass dadurch die ersten paar NFs
sehr oft automatisch abgedeckt sind.

Um auch ein kleines Beispiel zu machen:
Eine Tabelle für Autos (Inhalt sinnlos)
Code:
Nummerntafel | Farbe | Marke | Marke_Firmengründer | Marke_Gründungsjahr | Marke_Gerichtsstand...

1234 | Rot | Renault | Edgar J. Renault | 1900 | Paris
4321 | Blau | Renault | Edgar J. Renault | 1900 | Paris
3124 | Grün | Renault | Edgar J. Renault | 1900 | Paris
4213 | Gelb | Renault | Edgar J. Renault | 1900 | Paris
0000 | Unsichtbar | Spezial | Inspektor Gadget | 2000 | Marseille
...

Dass das nicht optimal ist sagt einem der Verstand allein.
Wenn man die Firmenbezogenen Daten in eine eigene Tabelle auslagert
und pro Auto nur die Firmen-ID (oder sowas) speichert hat man...
...eine kleinere DB, weil keine doppelten Daten
...schnellere Abfragen nach Autos und Firmen jeweils einzeln (und auch in verschiedenen Kombis)
...und auch noch mehr NFs erfüllt (grad kA wieviel. Eine weitere sicher, vielleicht mehr.)

Ganz ohne Synthesealgo etc. (ich gebe zu, ich "wusste" mal, was bei dem genau zu tun ist.
Vielleicht tu ich es ja unterbewusst trotzdem :p)


Passt zwar nicht ganz zum Rest vom Post,
aber es kann auch Sinn machen, für Teile der DB (einzelne Tabellen) ganz bewusst gegen alle
NFs zu arbeiten (inklusive NF1. Alles egal, hundert Daten in eine Spalte stopfen)
Grund: Wieder mal Geschwindigkeit.
Häufig gebrauchte Daten(zeilen) in eigene Tabellen kopieren,
um die zeitaufwändige Suche in den Gesamtdaten und das Zusammenklauben
aus mehreren Tabellen einzusparen...
 
Danke für den Post.
Ich denke ich weiß jetzt, wie ich am besten vorgehe. Die meisten Dinge sagt einem wirklich der gesunde Menschenverstand, aber wie das eben so ist, wenn man nur die Theorie kennengelernt hat, verhält man sich zunächst wie ein frisch geschlüpftes Küken. ;)

Das Einzige was nicht so optimal ist, ist dass eine Access-Datenbank verwendet wird, aber das liegt leider nicht in meiner Hand...
 
Zurück