ripuli-6 schrieb:
In dem Falle wäre es sinnvoll die Daten so aufzubereiten, weil ich schließlich nicht den ganzen anderen Krams (password, status etc.) zweimal zu stehen haben will. Denn hätte ich eine Tabelle mit zwei Zeilen für User mit zwei Email-Adressen und ich will das Passwort ändern, muss ich beide Zeilen ändern, was recht aufwändig und fehleranfällig wäre.
solange du noch keine Ahnung von Datenbankperformance hast, würde ich das aufsplitten von Informationen sein lassen, denn dein Beispiel hätte aus Sicht für z.B. MySQL keinerlei Performance-Relevanz gehabt.
ripuli-6 schrieb:
Ist es denn eigentlich sinnvoll in den normalisierten Tabellen auch einen Index anzulegen? Zunächst erscheint es ja, als ein erhöhter Verbrauch von Speicherplatz, aber ich könnte ja später Anwendungen entwickeln, die andere Assoziationen und Daten haben und dann bräuchte ich eventuell den Index?
Einen Index benötigst du um Bedingungen zu erfüllen, eindeutige Werte: Primärschlüsse, Unique Schlüssel oder um die Suche nach Datensätzen mit der gewünschten Spalte zu beschleunigen: Ohne Index wird vom Anfang alles gesucht.
selberbauer, deine Definitionen sind falsch, also nur die 1. stimmt
2. Normalform
Jedes Attribut muss von allen Teilen des Primärschlüssels abhängen (besteht der Primärschlüssel nur aus einer Spalte, ist die Regel autom. erfüllt):
Code:
#cdid | #tracknr | albumtitel | interpret | titel
Falsch da: Albumtitel und Interpret hängen nur von der CD-Id und nicht der Tracknr ab, nur der Titel hängt von beiden ab
Dein Definition ist falsch, weil es sehrwohl Datenbanken mit geteilten Primärschlüsseln geben darf, schau dir mal an, was eine "n:m-Beziehung" ist
3. Normalform
Jedes Attribut muss vom Primärschlüssel abhängen
Code:
#cdid | albumtitel | interpret | jahr der gründung
Falsch da: das Jahr der Gründung hängt nicht von der CD-Id ab, sondern von dem Interpreten.
Edit: deine 3. NF stimmt doch, wenn du Bank zu einem Primärschlüssel machst, was bei dir aktuell nicht der Fall ist.
Die BCNF und alles darüber kannst du getrost ignorieren, die BCNF tritt z.B. nur in sehr speziellen Fällen ein und ist relativ komplex und mit der 3. NF ist deine Datenbank schon gut normalisiert. Bisher habe ich die BCNF und 4. NF auch nur in Uni-Unterlagen und deren Übungen gesehen, die sind schon etwas theoretischer Natur.
Erfüllen solltest du
immer die 1. Normalform*, ob du die 2. und 3. Normalform ebenfalls erfüllst, ist dir überlassen, es entstehen auch jedenfall deutlich besser strukturierte Datenbanken die anpassungsfreundlicher sind, jede weitere Stufe der Normalform geht aber auf Kosten der Datenbankperformance, sofern du dich in Datenbankperformance aber noch nicht sehr gut auskennst, ignorierst du diese Ausnahme und erfüllst immer die Anforderungen bis zur 3. NF.
* auch die 1. NF darf aus Gründen der Datenbankperformance gebrochen werden, aber dann muss man wirklich schon sehr sehr sehr gute Gründe haben, das man solch eine elementare Normalform brechen darf. Anmerkung: atomare Daten pro Spalte darf nie gebrochen werden, einzig die verknüpfte Anforderung, dass es keine Aufzählungsspalten wie telefonnummer1, telefonnummer2, ... geben darf.
