Diskussion:Normalisierung (Datenbank)/Archiv

Uraltes

Die 2. Normalform ist tatsächlich mit einem sehr schlechten Beispiel versehen! Eine TrackID ist doch in gewisser Art und Weise abhängig von der CD?! Ich werd mal einfach ein neues Beispiel einsetzen, welches die Abhängigkeit zum Primärschlüssel besser darstellt. grüße, --der.helge 08:06, 5. Nov 2004 (CET)

gerade habe ich den Artikel zur 2NF korrigiert: Die Definition war in etwa die der 3NF - sicher aber nicht die der 2NF. Das Bsp. war 100% in 2NF nicht aber in 3NF. Mir ist noch aufgefallen, dass da Bsp. zur 3NF nicht so toll ist: eine Kostenstelle kann sich inm der Praxis durchaus auf zwei Abteilungen beziehen. Das alte 2NF Beispie wäre hier besser. Das mache ich evtl. noch später.

Mir ist gerade unter dem Bsp. zur BCNF etwas aufgefallen. Dort steht:

"Durch diese Konstellation ist die Relation nur in 3NF, nicht in BCNF. Wenn die transitive Abhängigkeit gelöst wird, und die im Beispiel aufgeführte Relation in zwei Relationen aufgeteilt wird, ist die Datenbank in BCNF."

Unter 3NF steht jedoch: "Die dritte Normalform ist erreicht, wenn man in den Relationen keine transitiven Abhängigkeiten hat."

Müßte demnach unter dem Bsp. zur BCNF nicht funktionale Abhängigkeit stehen? Also: "Wenn die funktionale Abhängigkeit gelöst wird, und die im Beispiel aufgeführte Relation in zwei Relationen aufgeteilt wird, ist die Datenbank in BCNF." Ich bin mir nicht sicher.

Nein, nein, auf keinen Fall! Bei den Normalformen dreht sich alles um funktionale Abhängigkeiten, eine funktionale Abhängigkeit vomPrimärschlüssel kannst Du gar nicht vermeiden. Die Frage ist, ob es bei der 3NF heißen muss: "..keine transitiven Abhängigkeiten gibt.." oder "..kein Nichtschlüssel von einem Schlüsselkandidat transitiv abhängig ist".

BTW: Bitte Beiträge mit Datum versehen! -- bg phaidros 13:09, 14. Mai 2007 (CEST)

die erklaerung zur zweiten normalform beinhaltet die dritte normalform schon. das ist als erklaerung in meinen augen nicht wirklich guenstig. in der zweiten normalform ist jedem datensatz ein eindeutiger identifizierer, dem primaerschluessel. zuzuordnen. weitere aufteilung ist hier noch nicht erforderlich, da diese in der dritten normalform zum tragen kommt (transitive abhaengigkeiten). hier mal ne oberflaechliche erklaerung zu den normalformen, die ich im datenbanken unterricht im technikerstudium hingeklatscht habe, um einfach ruebergebracht zu erklaeren, was es mit den dingern auf sich hat. vielleicht ist er nicht perfekt, aber von den grundzuegen her stimmt es eben so:

Warum Normalisierung?

Ein nicht normalisierter Datenbestænd fuehrt zu Redundanz. Redundanz fuehrt zu erhoetem Speicherbedarf und schlimmer noch zu Anomalien. Daher sollten Datenbanken unbedingt mindestens in die dritte Normalform (von 9 nach E.F. Codd) gebracht werden.

In der ersten Normalform muessen alle Daten soweit unterteilt sein, das jedes Datum nicht weiter unterteilbar ist. Alle Attribute enthalten somit nur atomare Werte.

Um die Datenbank in die zweite Normalform zu versetzen, muss jeder Datensatz einem eindeutigen Identifizierer, dem Primaerschluessel (en: Primary Key / PK) versehen werden. Der Primaerschluessel kann entweder ein eindeutiges Attribut (oder auch mehrere, die zusammengefasst ein- deutig sind, sollte jedoch vermieden werden), oder alternativ ein kuenstlicher Schluessel (surrogate key) sein. Der Nachteil eines kuenstlichen Schluessels ist die fehlende Symantik (keine aussage- kraeftige Bezeichnung).

In der dritten Normalform sind die Datensaetze soweit aufgeteilt, dass voneinander abhaengige, bzw zusammengehoerige Attribute in eigenen Tabellen zusammengefasst sind. Das heisst, es gibt keine transitiven Abhaengigkeiten zwischen den Attributen mehr, also keine nicht- Schluessel-Attribute, die von anderen nicht-Schluessel-Attributen ab- haengig sind.

lasse mich da aber auch gerne eines besseren belehren.

Falsches Beispiel - Postleitzahlen

Das am Ende des Abschnitts "Beispiel" genannte Beispiel ist nicht korrekt: Zum Beispiel ist beim Speichern von Adressen der Name des Ortes abhängig von der Postleitzahl. Nach der 3. Normalform müsste man bei der Adresse jeweils nur die Postleitzahl speichern und in einer separaten Tabelle die Zuordnung {PLZ, Ort}. Aus Gründen der Performance verzichtet man jedoch meist auf diese Trennung.

Wie in der Wikipedia nachzulesen, haben beispielsweise die Gemeinden Idstein und Hünstetten eine gemeinsame PLZ. Und auch sonst sind die PLZ-Grenzen nicht immer mit Gemeindegrenzen deckungsgleich. Es liegt also eine (n:n) Beziehung von PLZ und GKZ (Gemeindekennziffer) vor.

Das Kennziffersystem der Gebietskörperschaften (Gemeinde - Kreis - Regierungsbezirk - Land) ist dagegen hierarchisch aufgebaut.

Stefan

Dritte Normalform (3NF)

"Die dritte Normalform ist erreicht, wenn sich das Relationenschema in 2NF befindet, und kein Nichtschlüssel vom Primärschlüssel transitiv abhängt."

Ist unverständlich, auf Grund der Formulierung. Ich würde es besser finden, wenn betont wird, dass keine transitive Abhängigkeit vorliegen darf: Es darf keine transitive Abhängigkeit eines Nichtschlüssels vom Primärschlüssel vorliegen. 13.03.2008

Klingt IMO in der Tat besser. Mentor 14:03, 14. Mär. 2008 (CET)

Der Satz beim Bsp zur 2.Normalform: "Der Primärschlüssel der Relation ist aus den Feldern CD_ID und Track zusammengesetzt. Die Felder Album und Interpret sind zwar vom Feld CD_ID abhängig, nicht aber vom Feld Track." Impliziert doch dass auf einer Cd nur EIN einziger Interpret ist oder ? Da das Beispiel ansonsten sehr gut ist würde ich es nur um diese Annahme ergänzen..... Wenn ich überhaupt recht habe zumindest :)

Der Sachverhalt ist in der Tat eigentlich wesentlich komplizierter. Wenn man es gaaanz genau nehmen will, dann gibt es eine Tabelle Lieder. Diese ist 1:n mit einer Tabelle Interpretationen verbunden, da verschiedene Künstler ihre Interpretation eines solchen Liedes haben können (deswegen auch "Interpret"). Die Interpretation ist m:n mit den Künstlern verbunden, da mehrere Künstler an der Sache beteiligt sein können. Ggf. nicht mal vor der Bühne - sondern z.B. als Komponist oder Texter. Und diese Interpretationen sind meiner Meinung nach das, was sich auf den CDs befindet.

Ich erarbeite in meinen längeren Datenbank-Kursen genau dieses Beispiel gerne mit meinen Teilnehmern. Aufgrund seines unerwarteten Komplexitätsgrades finde ich es deswegen als Beispiel eigentlich ungeeignet. Mentor 21:45, 13. Jul. 2007 (CEST)

Ich habe den sehr ausführlichen Artikel gründlich durchgearbeitet, aber ich stoße auf einige Schwierigkeiten, die ich aus dem Text heraus nicht auflösen kann. Wo mich im Detail der Schuh drückt:

<zitat>Unter Normalisierung ... versteht man die schrittweise Zerlegung einer Relation..</zitat> finde ich etwas irreführend, "Zerlegung von Relationen" fände ich besser.

habe ich erledigt -- bg phaidros 10:30, 12. Mai 2007 (CEST)

<zitat>..mittels Normalisierungsalgorithmen</zitat> finde ich verkürzt: Algorithmen sind nur eine Art, die Aufgabe zu erledigen.

einfach "zB" eingefügt, erledigt. -- bg phaidros 10:30, 12. Mai 2007 (CEST)

<zitat>Neben den Abhängigkeiten, die für diese Normalformen "bereinigt" wurden</zitat> Die Abhängigkeiten wurden an dieser Stelle nicht angeführt, geschweige denn erläutert, nicht einmal definiert. Der Leser wird aber hier mit der expliziten Auflistung von Inklusionsabhängigkeit, Template-Abhängigkeit und DKNF eher verwirrt, zumal diese Artikel (noch) gar nicht existieren.

durch verweis erledigt. -- bg phaidros 10:30, 12. Mai 2007 (CEST)

<zitat>..und Anomalien (einander widersprechende Dateninhalte) </zitat> Anomalien sind weit mehr als nur inkonsistente Attributwerte, das ist nur eine der möglichen Anomalien (es fehlen: unvollständiges Einfügen, Löschen mit Informationsverlust & Änderungsaufwand. Das sollten imho wir aufzählen und erläutern.)

durch kleine Umformulierung vorläufig erledigt. -- bg phaidros 10:30, 12. Mai 2007 (CEST)

Die restlichen Punkte wollte ich zu den Unterpunkten dieser Diskussion einordnen, habe es dann aber nicht getan, nachdem ich auf die Zeitstempel geschaut habe. Werde das aber gerne noch umordnen, wenn es gewünscht wird:

1NF: <zitat> Jedes Attribut der Relation muss einen atomaren Wertebereich haben. </zitat> Danach beginnt augenblicklich eine Erläuterung. Hier fehlt mir: "... und frei von Wiederholungsgruppen sein" - in diesem Zusammenhang lediglich implizit von den mengenwertigen Attributen zu sprechen, erachte ich für zu schwach.

durch Texterweiterung erledigt -- bg phaidros 22:51, 13. Mai 2007 (CEST)

Das Beispiel finde ich schlecht gewählt, und schlecht aufgelöst: wenn ich das mengenwertige Attribut Titelliste innerhalb der Tabelle auflöse, so muss ich den Tabellenschlüssel verändern. Daher schlage ich meinen Studenten vor Wiederholungsgruppen aufzulösen, indem eine eigene Relation geschaffen wird. Außerdem ergibt sich daraus eine praktische, gemeinsame Vorgangsweise für sich wiederholende Attributgruppen und nichtprimitive Attribute!

Auch die "NF-Erweiterung": "..und einen Schlüssel haben" ist zwar so bei Codd nicht nachzulesen, ist aber derart sinnvoll, dass ich eine solche Erwähnung empfehle.

eigenen Punkt "Alternative Fomulierungen" aufgenommen. -- bg phaidros 22:51, 13. Mai 2007 (CEST)

2NF ok

BCNF hier geht mir eine Definition ab. <zitat>In der BCNF soll verhindert werden, dass Teile zweier aus mehreren Feldern zusammengesetzter Schlüsselkandidaten voneinander abhängig sind.</zitat> finde ich ehrlich gesagt wischi-waschi. Wie heißt die BCNF?

Vorschlag: 3NF + alle Determinanten KC.

Das widerspricht sich allerdings mit der 3NF, bei der das schon drin steckt, wenn man diese losere Formulierung zulässt, dass nicht alle transitiven funktionalen Abhängigkeiten verboten sind.

Erkennt ihr mein Problem? Ich kriege da kein stehendes Gedankengebäude zusammen. Bitte also auch hier um Diskussion und Vorschläge.

4NF es taucht auf einmal der Begriff 1:n-Beziehung auf. Eine echte Definition für mehrwertige funktionale Abhängikeit fehlt.

Das Beispiel für die 4NF erfüllende Relation verstehe ich ohne weiterführende Erläuterung nicht.

Bemerkungen <zitat>Es wird damit demonstriert, wie man auf keinen Fall ein Datenmodell entwirft – nämlich ausgehend von einer Universaltabelle. Die heutige Bedeutung ist nur noch historisch zu verstehen.</zitat> Ich könnte nicht weniger einverstanden sein! Erstens muss selbstverständlich auch ein intuitiver Entwurf, der meistens schon zu 95% "richtig" ist, nochmal auf Einhaltung der NFn "abgeklopft" werden, und 2. hat die Normalisierung zur Erzeugung von Datenstrukturen aus nichtrelationalen Quellen (zB Formulare oder Spreadsheets) durchaus große Bedeutung!

entsprechenden Absatz eingefügt -- bg phaidros 22:51, 13. Mai 2007 (CEST)

<zitat> denn partielle Abhängigkeiten sind nur spezielle transitive Abhängigkeiten </zitat> verstehe ich nicht, halte ich für nicht richtig - die Konklusio, dass die 2NF entbehrlich ist, dadurch ebenfalls. Bitte um Erläuterung.

Ich möchte nicht mit der Tür ins Haus fallen, aber um ehrlich zu sein: dafür dass der Artikel "lesenswert" ist, ist er in meinen Augen (viel) zu wenig in sich selbst gestützt: Wenn man versucht, die dargebotenen Inhalte zusammenzulegen, kommt einfach kein schlüssiges Bild heraus ODER es fehlen einfach zum Verständnis wesentlich Teile.

Bitte entschuldigt die Länge meines Posts, aber vielleicht seht Ihr daran, dass ich wirklich versucht habe, mich in den Text hineinzudenken.

Dankbar für alle Tipps, Anregungen & Korrekturen -

bG phaidros 13:02, 7. Mai 2007 (CEST)

pS - off Topic: Ich lese immer wieder von 9 Normalformen gemäß Codd. Kann aber nirgendwo etwas Konkretes dazu entdecken. Ist das ein modernes Märchen, oder kann mir jemand eine Quelle nennen? Danke!

da ich keinerlei "harte" Quellen für die 9 Normalformen finden kann, und auch keine genannt wurden, habe ich den Hinweis vorerst entfernt. Ich weiß nur von den 6 Normalformen 1-3, BCNF, 4-5. Lasse mich gern eines Besseren belehren und bitte um Aufklärung bzw. Quelle, danke! -- bg phaidros 22:51, 13. Mai 2007 (CEST)

Ich würde vorschlagen die Definition der 2NF "a ist nicht von einer Teilmenge von KC abhängig" durch "a ist nicht von einer echten Teilmenge von KC abhängig" zu ändern; ich war beim ersten Lesen etwas verwirrt, da im Sprachgebrauch mit "Teilmenge" oft "Teilmenge-gleich" bezeichnet wird und die Definition dann widersprüchlich erscheint. --Baschtlh 22:53, 30. Apr. 2007 (CEST)

Müsste, in der Erklärung zur zweiten Normalform, das rot hinterlegte Feld bei der inkonsistenten Tabelle nicht etwas anderes als "Not that Kind" anzeigen? "Inkonsistenter CD-Name" z.B.

Ich sehe das auch so, dass bei dem Beispiel für die inkonsistente Tabelle keine Inkonsitenz gezeigt worden ist. Ich habe das mal entsprechend geändert. Es ist in der Vergangenheit auch schon mal richtig gewesen, wurde dann aber aufgrund von angeblichem Vandalismus wieder zurückgeändert. Mal sehen, ob es dieses Mal wieder ruckgängig gemacht wird. --89.245.68.109 23:59, 3. Aug. 2007 (CEST)

Das Beispiel(nicht falsch verstehen) zur 3NF ist unpassend. Es beinhaltet die Zusatzbedingung, dass die Beziehung zwischen CD und Künstler mehrwertig ist - das hat aber mit dem Problem nichts zu tun. Die 3NF wäre schon erreicht wenn in 2 Tabellen aufgeteilt würde, mit einer I_ID Spalte in der CD-Tabelle

Wer hat denn den Artikel gelöscht? Recover? --M. Augustine 14:50, 14. Mar 2006 (CET)

Erste Normalform

Hier steht seit Juli 2003, dass die Erste Normalform dann gegeben ist, wenn keine mehrteiligen Attribute vorhanden sind. Nach dem was ich gelernt habe, muss es mehrwertige Attribute heißen und dann passt auch das Name/Vorname Beispiel nicht, sondern eher sowas wie Sonderausstattung beim Auto. Die 1. Normalform wird dann dadurch erreicht, dass man das mehrwertige Attribut in eine Liste auslagert. Stehe ich mit dieser Meinung alleine? --Rat 23:18, 16. Dez 2004 (CET)

Ja, die Definition/Erklärung habe ich noch nie gehört. Habe drei gute Quellen und alle sagen "wenn alle Attribute atomar vorliegen". Atomar ist der beste Ausdruck, wie ich finde. Und das Name/Vorname Beispiel ist genau richtig, klassisch ist es auch oft das Adress-Beispiel, bei dem PLZ/Ort/Straße/HausNr nicht atomar sind. --Surrounder 10:34, 18. Mär 2005 (CET)

Endlich mal eine Antwort, danke. Demnach waeren alle Datenbanken, die Strasse und Hausnummer in ein Feld nehmen, nicht in der ersten Normalform (und damit auch nicht in der 2., 3. usw.)? Das haengt doch alleine von der Anwendung ab, wieweit ich meine Felder aufdroeseln will. Ist ein Geburtsdatumsfeld atomar oder kann ich noch nach Tag/Monat/Jahr differenzieren? Ist es mit Vorname Name genug, oder braucht man Vorname und "middle initial" und Nachname? Kann man das formal entscheiden? --Rat 00:01, 21. Mär 2005 (CET)

Das löst bei meinen Kursteilnehmern auch jedesmal Verwirrung aus. :-) Ich verwende einfach folgenden (persönlichen) Erklärungsansatz: "Eine Information ist im aktuelle Datenbankkontext als atomar anzusehen, wenn ich sie in der weiteren Verarbeitung / Darstellung nicht aufteilen muss - wie einfach die Aufteilungsmethode auch immer aussehen mag." D.h. die meisten Anwendungen kommen mit Strasse und Hausnummer in einem Feld sehr gut zurecht. Aber nimmt z.B. die Tourenplanung bei einem Versandservice. Hier erlebt man sehr häufig, dass man bei Stammdateneingaben im Internet ein eigenes Feld für die Hausnummer hat. Dann kann man halt erst nach den geraden und dann nach den ungeraden Nummern filtern/sortieren. Für die Formalien sollte man vielleicht mal den Herrn Codd fragen. ;-) Mentor 15:18, 21. Mär 2005 (CET)

Stimmt, das ist nicht eindeutig allgemeingültig definierbar. Find den Erklärungsansatz klasse, Mentor :) Übrigens muss ich meine Aussage von oben zurückziehen und hab jetzt auch eine entsprechende Definition wie deine gefunden, Rat. Ein Dozent aus dem BI-Bereich hat sie uns vorgelegt: "Eine Relation ist in der 1. Normalform, wenn sie keine Wiederholgruppen enthält". Also wenn in einer Zeile Sonderausstattg-ID, Sonderausstattg-Name, Merkmal 1, Merkmal 2, Merkmal 3, Preis stehen, die Merkmale also unflexibel auf 3 festgelegt/beschränkt sind. Werde ihn nächstes Mal fragen, wo er das her hat. --Surrounder 00:16, 10. Apr 2005 (CEST)

Zweite Normalform

Angeblich steckt die Hauptarbeit im Erreichen der 2. Normalform. Wenn ich einen organisatorischen Schlüssel (eindeutige Nummer) einführe, ist die 2. Normalform automatisch erfüllt, da es dann keinen Teilschlüssel mehr gibt. Das Problem wird dann auf die 3. Normalform verlagert. Dort steckt IMHO die meiste Arbeit, denn ich muss für jedes Nichtschlüsselattribut prüfen, ob die Abhängigkeit von einem anderen Nichtschlüsselattribut gegeben ist. --Rat 23:24, 16. Dez 2004 (CET)

Die in der Beispieltabelle enthaltenen Attributwerte sollten keine "realen" Werte sondern Phantasiewerte enthalten. Es besteht hier keine Notwendigkeit geschützte Ziffernfolgen als ID zu verwenden.--Thomas 16:21, 2. Jan 2005 (CET)

Ist nicht auch folgendes unvollständig? "Eine Relation ist genau dann in zweiter Normalform, wenn sie ...

  1. in der ersten Normalform ist und
  2. für jeden Schlüsselkandidaten (Key Candidate, KC) und jedes Attribut a der Relation gilt:
         * a gehört zu KC oder
         * a ist nicht von einer echten Teilmenge von KC abhängig."

Hier fehlt doch komplett die Aussage, dass a von der Menge der KC voll funktional abhängig ist! CDehning 08:55, 28. Feb. 2010 (CET)

Dritte Normalform

"Die Bedingungen der 2. NF müssen erfüllt sein UND kein Nicht-Schlüsselfeld darf von keinem anderen Nicht- Schlüsselfeld abhängig sein (ein Fremdschlüssel ist KEIN Nicht-Schlüsselfeld)."

Soll das also bedeuten, dass ein Nicht-Schlüsselattribut (Attribut passt übrigens besser als Feld) von einem Fremdschlüssel funktional abhängig sein darf?!? Das seh ich aber anders, da der Sinn des Fremdschlüssels ja gerade in der Auslagerung der von ihm abhängigen Attribute in eine andere Relation liegt. Oder kann mir das jemand erklären und ein Beispiel bringen? --Surrounder 10:34, 18. Mär 2005 (CET)

Meiner Meinung nach sind Fremdschlüssel bei einer solchen Betrachtung immer aussen vor. Ich denke er will genau das sagen. Dass ein Fremdschlüssel kein Primarschlüssel ist, das ist ja logisch. Der obige Satz sagt halt weiter, dass er auch kein "normales" Attribut im Sinne der dritten Normalform ist. Entsprechend enfällt die Diskussion "Aber Schlüssel X ist doch von diesem Fremdschlüssel dort abhängig und daraus folgt die Nichterfüllung der 3NF." Mentor 11:54, 18. Mär 2005 (CET)

Hier wird ein logischer Bruch eingeführt, den ich nicht auflösen kann: während bei der 2NF noch davon die Rede ist, dass die Nichtschlüsselattribute von den Schlüsselkandidaten voll funktional abhängig sein müssen (ok, verstehe ich), heißt es bei der dritten:

<zitat>..und man in den Relationen keine transitiven Abhängigkeiten hat.</zitat> Das schließt imho mehrere Schlüsselkandidaten aus! Denn es gilt bei 2 Schlüsselkandidaten KC1 & KC2 und Attributen An immer:

KC1 <-> KC2 -> An, also KC1 -> KC2 -> An, aber auch KC2 -> KC1 -> An.

Bei mehreren Schlüsselkandidaten haben wir also immer transitive Abhängigkeiten, die gemäß 3NF verboten sind!

Mein Textvorschlag also: "keine transitiven Abhängigkeiten, bei denen Nichtschlüsselattribute als (Teil von) Determinanten auftauchen."

Ich kenne aber den Originaltext nicht, bitte daher besonders an dieser Stelle um Diskussion und Vorschläge.

<zitat>Einfach gesagt: Kein Nichtprimärattribut darf von einer Menge abhängig sein, die ausschließlich aus Nichtprimärattributen besteht.</zitat>

Diese Aussage halte ich für falsch. Betrachte man das Beispiel R ist Relation mit R= ABCD, Primärschlüssel = AB und F = {BC -> D, AB -> C}. Meiner Meinung nach ist hier gegen die dritte NF verstoßen worden, da D transitiv abhängt vom Primärschlüssel. Laut der "Vereinfachung", wird hier jedoch nicht gegen die 3NF verstoßen.

Ich bitte um Meinungen.

Die Erklärung der transitiven Abhängigkeit ist falsch. Im Text steht "... sodass $(P\rightarrow B)$ und $(B\rightarrow A)$ , aber nicht $(P\rightarrow A)$ ." ABER andererseits folgt aus dem 3. Armstrong-Axiom (siehe auch Funktionale_Abhängigkeit) IMMER, dass, wenn $(P\rightarrow B)$ und $(B\rightarrow A)$ gilt, auch $(P\rightarrow A)$ gilt. Die Einschränkung "aber nicht $(P\rightarrow A)$ " müsste bei der Definition der transitiven Abhängigkeit wegfallen, sonst gäbe es überhaupt keine transitiven Abhängigkeiten... --79.208.116.171 13:21, 25. Aug. 2009 (CEST)

Das stimmt natürlich, so besser? Der Rest wird ja im Verlauf des Textes erklärt. --Euku:^⇄ 13:54, 25. Aug. 2009 (CEST)

Jo, super :) --79.208.116.171 15:56, 25. Aug. 2009 (CEST)

BCNF

Ist im Beispiel nicht bereits die 1NF verletzt? Der Schlüssel KST_Nr setzt sich aus atomaren Bestandteilen zusammen, Abteilungsnummer und Angestelltennummer... imho eine Verletzung der 1NF. Uns wurde die BCNF so erklärt, dass alle Attribute die einen blbg. Schlüsselkandidaten bilden z.b. ABC nirgends als voll funktional abhängige Attribute auftauchen dürfen. --gtb 18:10, 4. Februar 2006 (CET)

Hier wird Determinante beschrieben als: "Determinante (Menge von Attributen, von denen andere voll funktional abhängen)". In unserer Datenbankdesign-Vorlesung wird geschrieben: "Def.: R sei eine Ralation und A,B Attributkombinationen von R. Eine funktionale Abhängigkeit R.A -> R.B heisst Determinante, wenn A und B keine Attribute gemeinsam haben." Die erste Definition ist in jedem Fall zu wage. --Althequick 15:09, 11. Dez 2005 (CET)

Welche Art von Problemen kann eine nicht in die BCNF überführte Tabelle hervorrufen? Das geht aus dem Artikel nicht hervor. --Althequick 16:44, 22. Jan 2006 (CET)

Ich sehe das mit der Verletzung der 1. NF wie gtb und werde aus dem Absatz über die BCNF auch nicht ganz schlau. Vielleicht kann jemand, der sich wirklich damit auskennt, mal ein richtiges Beispiel und auch die dazugehörige Lösung in den Artikel einarbeiten? Virtemulo 09:02, 8. Jun 2006 (CEST)

Ich habe ein komplett neues Beispiel geschrieben (Sportler-Vereinszugehörigkeit) und damit das alte, irreführende Kostenstellen-Beispiel ersetzt. Bitte schaut alle mal drüber, ob das jetzt korrekt ist. --Head 01:44, 28. Sep 2006 (CEST)

Ich finde das hier etwas widersprüchlich ausgedrückt: "Alle Relationen können zwar in die dritte Normalform übertragen werden, aber nicht jede in die Boyce-Codd-Normalform." und "Die Überführung in die BCNF ist zwar immer verlustfrei möglich, aber häufig nicht abhängigkeitserhaltend.". Was stimmt denn jetzt? Ist eine Überführung immer möglich, oder nicht? --mattelacchiato

Ist im Beispiel nicht auch schon 2NF verletzt? Die BCNF muss zunächst in 3NF sein. 3NF ist aber verletzt. Denn Verein hängt partiell von Sportart ab und Sportart ist Untermenge vom Schlüssel Name Sportart. Also ist 2NF verletzt und damit kann auch 3NF nicht erfüllt sein. Gibt es überhaupt einen Unterschied zwischen 3NF und Boyce-Codd? Ich finde einfach kein Beispiel, das in BCNF aber nicht in 3NF ist.

Wo ich mir ziemlich sicher bin: 1. Determinante muss keine minimale Attributenmenge sein. BCNF ist falsch formuliert, die genauere Definition habe ich aus dem Kemper-Buch. Ich korrigiere diese Stellen. --Roman Munich 02:01, 18. Aug. 2008 (CEST)

Das Beispiel stimmt schon, weder die 2NF noch die 3NF sind verletzt, da sowohl {Name,Verein} als auch {Name,Sportart} Schlüsselkandidaten sind. Und wenn alle Attribute sind prim (Teil eines Schlüsselkandidaten) ist die Relation automatisch in der 3NF. Allerdings geht das aus dem Beispiel kaum hervor, werde es deswegen hinzufügen! (nicht signierter Beitrag von 84.152.91.249 (Diskussion | Beiträge) 18:10, 27. Jan. 2010 (CET))

Vierte Normalform

Ich vermisse hier sehr eine Erklärung darüber, warum die Verletzung der vierten Normalform schlecht ist.--Althequick 15:55, 11. Dez 2005 (CET)

Ich auch. Meiner Meinung nach wird die Argumentation ab der 3NF nur noch akademisch (was ja auch nicht falsch ist). Wenn ich die 3NF in der Praxis erreicht habe, dann bin ich eigentlich zufrieden. Mentor 07:17, 12. Dez 2005 (CET)

Das Beispiel für die 4. NF halte ich für Käse. Dort gehen Informationen verloren, durch einen join kann die Ausgangstabelle nicht mehr erreicht werden. Das kann nicht Ziel der 4NF sein.

Ich finde es irritierend, dass die Personennummer blau unterlegt ist, als ob es sich dabei um einen primären Schlüssel handelt. Hat das irgendein Grund? - Michael

Einleitung

Zur Zeit: Die 4. Normalform beschreibt die mehrwertige Abhängigkeit (MWAs). Eine Datenbank ist dann in der 4. Normalform, wenn sie nur noch triviale mehrwertige Abhängigkeiten enthält oder die nicht-trivialen mehrwertigen Abhängigkeiten von Superschlüsseln ausgehen.

Ich denke nicht, dass dies auch für Superschlüssel gilt. Beispiel: Ein (trivialer) Superschlüssel ist das gesamte Tupel. Damit wäre diese Bedingung unwirksam. (Vgl. auch Artikel Schlüssel in Wikipedia.) --Whsky 18:27, 19. Aug. 2008 (CEST)

Den Gedanken hatte ich gestern auch, zumal in der Literatur beide Formulierungen vorkommen. Ich bin dann aber auf den Gedanken gekommen, daß es gar keine mehrwertige Abhängigkeit vom "Superschlüssel ganzer Tupel" geben kann. Die nächste Überlegung war, umzuformulieren in "nicht-triviale mehrwertige Abhängigkeiten von übergeordneten Superschlüsseln, die die funktional abhängige Attributmenge nicht enthalten". Ich fand dann aber, daß das mit der ursprünglichen Formulierung auch zum Ausdruck gebracht wird. "Schlüsselkandidat" ist nach meiner Meinung zu eng: Man ergänze die Tabelle z.B. um eine FamilienID und eine fortlaufende Nummer fürs Familienmitglied. Wenn man das dann weiterspinnt, kommt man darauf, daß "Superschlüssel" vermutlich richtiger ist. Wie gesagt: Ich bin mir nicht sicher. Vielleicht gibts hier ja jemanden, der es genau weiß - würde mich freuen.

Ansonsten ziehe ich übrigens folgende Definition vor: Eine Relation liegt in der vierten Normalform vor, wenn sie in der dritten Normalform steht und aus der Existenz einer mehrwertigen Abhängigkeit B von A in R folgt, dass alle Attribute von R funktional abhängig von A sind (aus "Lehrveranstaltung Datenbanksysteme", TU-Berlin, ohne Jahr und Autor). Alauda 23:11, 19. Aug. 2008 (CEST)

falsche Werte in der Beispieltabelle

Hi,

Ist vielleicht nicht so wichtig, sollte aber dennoch geändert werden. Die Inhalte der Beispieltabelle für die 2. Normalform sind teilweise falsch. Es sollte z.b. nur eine CD mit der ID 4711 geben und nicht 2. Dann sind noch die Preise nicht immer gleich. Mal kostet eine CD 14.59, dann wieder 14.99 oder gar 15,99 Euro. Bitte ändert das, sobald ich das ändern möchte, wird das sofort wieder zurückgesetzt.

Hallo, das mit den zwei CDs mit der ID 4711 ist richtig. Das darf nicht sein. Aber die falschen Werte in einer der Beispieltabellen sind OK. Die Tabelle ist inkonsistent, d.h. DIE WERTE SOLLEN FALSCH SEIN!! Lest doch bitte alle erst mal den Text darüber bevor ihr den Fehler korrigiert.
Sonst ist das Verhalten ja richtig. Anfänger in Wikipedia werden ja angehalten einfach mal mit ein paar Korrekturen zu beginnen. Aber bitte nicht hier! *heul* ;-)

Das erinnert mich an ein altes Adventure, dem als Goody ein Reiseführer mit vielen Rechtschreibfehlern beilag. Als erstes hat ein Lektor alle Fehler wieder rausgenommen. Mentor 11:46, 14. Jun 2005 (CEST)

2. Normalform; Lösungstabelle

Hallo IMHO ist die eine Lösungstabelle zur 2. Normalform falsch. Die CD_ID fungiert als Primärschlüssel. Aber in der Lied-tabelle gibt es keinen Primärschlüssel, da es ja verschiedene Lieder mit gleichem Titel geben könnte. Und die Track_ID ist auch nicht eindeutig. D.h. hier müsste erneut eine Kombination aus den Teilschlüsseln CD_ID und Track_ID erfolgen. Ich weiß aber auch nicht wie es besser geht und überlasse die Änderungen somit euch :D

Gruß, Jan

Hallo Jan,

Gute Frage. Leider wird mein Originalbeispiel nicht mehr behandelt. Ich finde nämlich das Beispiel CD / Lieder nicht trivial. Die Kombination aus CD_ID und Track_ID ist im Prinzip richtig als Primärschlüssel. In der Lied-Tabelle muss es aber trotzdem einen Primärschlüssel geben. Ich muss das Beispiel an sich mal korrigieren! Danke für den Hinweis - ich habe es einfach nicht genau gelesen. Mentor 13:06, 20. Jun 2005 (CEST)

Hallo Rest :-)

Natürlich ist das Beispiel zur 3NF auch falsch, da der Interpret denselben Problemen unterliegt wie das Gründungsjahr. "Anastacia" kommt mehrmals vor und verletzt dabei schon die 2NF(?)

Hallo. Ich bins nochmal, Jan. Ich wollte nur mal zu protokoll geben, dass dieser Beitrag über Normalisierung wesentlich zu den 14 Punkten in meiner Abi-Nachprüfung beigetragen hat! :-D

2. vs. 3. Normalform

Ich habe im Netz keine befriedigende Unterscheidung der beiden Zustände gefunden. Scheinbar wird immer die gleiche Transformation (1 zu 2, 2 zu 3) an 2 verschiedenen Beispielen beschrieben, danach werden krampfhaft Unterschiede herausgearbeitet.

Nachschauen in meinen alten Vorlesungsunterlagen kehrte hervor, dass die 2. Normalform keine mehrwertigen Schlüssel zuläßt:

Lieferung

3 | Hans | Koch

(wobei Hans Koch der Schlüssel für den Lieferant in einer anderen Tabelle ist)

Zur Transformation in die 2. Normalform müsste demzufolge ein künstlicher Schlüssel (in Form einer ID) eingeführt werden. Dies passiert beim Datenbankdesign meist schon instinktiv und somit existiert dieser Zustand (2 aber nicht 3) nur selten in der Praxis. Die 3. Form darf dann keine funktionalen Abhängigkeiten enthalten (wobei für mich funktional transitiv gleichzusetzen ist, bis mir wer den Unterschied erklärt). Feuer frei zur Diskussion. (axm) --axm 23:58, 23. Aug 2005

Wenn die 1.NF gegeben ist, kann die 2.NF nur dann verletzt sein, wenn der Schlüssel aus mehreren Attributen zusammengesetzt ist (z.B. Name+Vorname+GebDat) und ein weiteres Nichtschlüsselattribut bereits durch einen Teil des Primärschlüssels eindeutig bestimmt ist (z.B. Status [Kind, Jugendlcher, Erwachsener] durch GebDat). Wenn du dieses Problem durch Einführung eines nicht zusammengesetzten Schlüssels (z.B. PersID) abstellst, verlagerst du das Problem auf die 3.NF. Insofern ist der Unterschied nicht so riesig. Dass etwas "instinktiv" richtig gemacht wird, liegt daran, dass man es so beigebracht bekommen hat und nie anders sieht. Es gab aber mal Zeiten, wo das nicht so war und das, was später immer richtig gemacht werden sollte, zunächst formalisiert werden musste. --Rat 18:20, 24. Aug 2005 (CEST)

Ja, Name+Vorname+GebDat verletzt die 2. Normalform. Ich behaupte jetzt, das reicht schon (kein "und"). Insofern wird da nichts verlagert, die Auflösung semantischer (oder funktionaler oder transitiver) Abhängigkeiten _ist_ meiner Meinung nach die Transformation zur 3. Normalform. "Instinktiv" hab ich genau so gemeint wie verstanden, genau darunter fällt allerdings auch das Beispiel im Artikel (eine ID existiert bereits), was demnach ungeeignet wäre.--axm 23:39, 24. Aug 2005 (CEST)

Mein Unverständnis an diesem Punkt hing tatsächlich mit der Unterscheidung funktionaler/transitiver Abhängigkeit zusammen. Für alle, die mein Problem teilen (steht zwar alles schon im Artikel, aber vielleicht hilft eine andere Formulierung ja, das ein oder andere Brett vorm Kopp zu durchlöchern, man möge mir also diese Redundanz verzeihen):

funktionale Abhängigkeit: ein Attributswert ist nur über einen einzigen Schlüssel (bzw. Schlüsselkombination) erreichbar

transitive Abhängigkeit: ein Attributswert impliziert einen weiteren Attributswert

In der 2. Normalform muss demnach jede Attributsspalte von _jeder_ Schlüsselspalte abhängig sein. Damit sind weiterhin Inkonsistenzen möglich, nämlich durch Abhängigkeiten zwischen den Attributsspalten selbst. Diese werden erst in der 3. Normalform aufgelöst. --axm 18:19, 14. Sep 2005 (CEST)

In der 3NF müssen m:n Beziehungen berücksichtigt werden. Das heisst, es muss eine Zwischentabelle "tbl_Künstler/CD" erzeugt werden, da ein Künstler mehrere Alben(CD´s) machen kann und es CD´s geben kann, auf denen mehrere Künstler sind.

Lesenswert-Diskussion

Unter Normalisierung des Datenmodells einer relationalen Datenbank versteht man die Anwendung von Kriterien, damit das Modell einen bestimmten Zustand erreicht. Diesen nennt man (xte) Normalform, das heißt, wenn ein Datenmodell bestimmte (in jeder Stufe verschärfte) Bedingungen erfüllt, hat es die dadurch definierte Normalform, kurz xNF.

Pro Ich empfinde den Artikel als äußerst interessant, gut strukturiert und formuliert norro 22:26, 7. Sep 2005 (CEST)
Pro obwohl sich der Artikel leider nur auf die Normalformen beschränkt. Es gibt jedoch auch weitere Normalisierungen, zB funktionale Abhängigkeiten, die zumindest bei kleinen Relationen auch zur Normaliserung führt. Ebenso fehlt der Ansatz, wie man schematisch Tabellen normalisiert und dabei evtl Schluesseltabellen erhält. Eine m:n Verknuepfung führt ja zu drei Tabellen, ebenso kann man nach Schema F eine 1:n oder (0,1):n (nichtobligatorische Teilnahme) und saemtliche andere Kombinationen aufloesen. Potential hat der Artikel also noch, aber das was vorhanden ist, genügt mir für ein pro. --Huebi 09:27, 8. Sep 2005 (CEST)
Pro Ich finde, der Artikel hat sich sehr gut entwickelt. @Huebi, wenn Du mit der Normalisierung eine gedachte Tabelle mit allen Daten drin bis zur 3NF normalisierst, dann tauchen die Verbindungstabellen automatisch auf. Nur bei der Modellierung mittels ERM ist diese zusätzliche Erklärung für die Auflösung von m:n nach 1:n:1 notwendig. OK, das mit den Beispielen ist immer so eine Sache. Machmal brauche ich in Kursen drei bis vier Erklärungsansätze, bis ich die Teilnehmer alle wieder am roten Faden habe. Mentor 13:11, 8. Sep 2005 (CEST)

Es waere schlimm wenn die in der 3NF nicht auftauchen würden. Eine tabellarische Übersicht fand ich aber immer recht praktisch, und ich hab bei Normalisierungen immer diese Tabelle im Kopf und normalisiere danach. --Huebi 21:28, 8. Sep 2005 (CEST)

Neutral Ist zu komliziert beschrieben (und dabei ist der Inhalt gar nicht so kompliziert). So eher für ein Fachbuch zu verwenden. Aufbau, Struktur, Layout und Beispiele sind aber gut. Bin also bereit mein Votum noch mal zu überdenken!

Das wäre toll. Bitte denke daran, dass in den obigen Kriterien explizit auch Artikel als lesenswert zugelassen sind, die für den Laien zu kompliziert, aber fachlich korrekt und für den Experten verständlich sind. Falls Du allerdings meinst, dass der Artikel unnötig umständlich oder kompliziert geschrieben ist, ist die Gegenstimme selbstverständlich gerechtfertigt. Gruß, norro 10:31, 9. Sep 2005 (CEST)

Du hast Recht, darum von Contra auf Neutral geändert! Anki64 11:50, 9. Sep 2005 (CEST)

Pro Der Artikel hat mir weitergeholfen, enthielt mehr Informationen als erwartet und war verständlicher als befürchtet. Danke! --Michael 12:21:35, 9. Sep 2005 (CEST)
Pro Hat auch mir weitergeholfen und war vor einem halben Jahr schon toll! --Flominator 01:36, 12. Sep 2005 (CEST)
Pro Prinzipiell gut, aber der Unterschied 2./3. Normalform würde besser zur Geltung kommen, wenn das Gründungsjahr auch schon im Beispiel der 2. Normalform enthalten wäre (bessere Darstellung des Unterschieds funktionale/transitive Abhängigkeit). --axm 17:57, 14. Sep 2005 (CEST)
Pro Gute, verständliche Darstellung. Aus meiner Sicht etwas "unglücklich" ist das Beispiel zur 2. Normalform und die Lösung dazu: wie aus heiterem Himmel "entsteht" plötzlich eine I_ID, die im Beispiel noch nicht vorhanden ist. Auch ist in der Beispieltabelle der Fall, dass ein CD-Titel mehrere Interpreten haben kann, nicht vorgesehen. Für die Praxis trifft das natürlich zu. Fazit: das CD-Beispiel ist durchaus nicht trivial, will man z.B. auch noch Sampler- und Cover-Versionen berücksichtigen. thomsue 11:50, 21. Mai 2006

Anusformen???

"Es gibt sechs Anusformen, von denen in der zweiten die Hauptarbeit steckt (siehe Bemerkungen):"

Was bitte ist eine Anusform im Sinne der Informatik? Der Duden findet nichts dazu und Google findet 4 Seiten, die garantiert nichts mit Datenbanken zu tun haben. :-)

Dankbar für Aufklärung!

Lutz

Da hat heute eine IP Unsinn eingetragen. Ich habe das rückgängig gemacht. Es heisst natürlich "Normalformen". Danke für Deine Aufmerksamkeit. -- tsor 15:30, 21. Sep 2005 (CEST)

NFNF

Wie sieht es mit der Erwähnung der Non-First-Normal-Form aus? Gruß --Lex912 18:07, 28. Nov 2005 (CET)

Einleitung

Man versucht nicht die Redundanzen zu vermeiden, sondern sie zu verringern. Man stelle sich vor, es gäbe keine Redundanzen bei verknüpften Relationen (Tabellen). Dadurch wären (logische) Verknüpfungen nicht möglich.

Bei der Konsistenz würde ich Daten wählen, weil es von der Formulierung und der Verständlichkeit besser 'klingt'.

kOOni

Das stimmt nicht, denn bei vollständig normalisierten Relationen kommt jedes Attribut genau einmal vor. Fremdschlüssel-Beziehungen sind hier nur Referenzen auf einen Schlüssel (ein Pointer), und nicht redundant gespeicherte Informationen.

Bei der technischen Umsetzung freilig sind es Kopien, die natürlich auch ihre Redundanz mit sich bringen. Bei der technischen Umsetzung bringt man aber manchmal noch wesentlich mehr Redundanz mit herein, um die Zugriffe zu optimieren. Daher ist die Redundanzfreiheit ist eine Forderung, die sich ausschließlich auf das logische Datenmodell bezieht. Sie hat nichts mit der technischen Umsetzung nicht direkt zu tun. -- 82.135.37.138 17:35, 27. Feb. 2007 (CET)

Grundsätzlich: Normalisierung ist zu kompliziert!

Normalisierung ist als Konzept zu schwierig und zu kompliziert. Das sieht man daran, wie schwer hier (im Artikel und in der Diskussion) um die Begriffe und die exakten Aussagen gerungen werden musste und muss. Man sieht es aber auch daran, dass Normalisierung sogar für Normalisierungs-Experten zu schwierig und zu kompliziert ist. Der erste Normalisierungsalgorithmus stammte von Bernstein 1976, er war fehlerhaft, die Theoretiker brauchten aber Jahre, um den Fehler zu bemerken, und weitere Jahre, um ihn zu korrigieren.

Normalisierung ist aber auch Flickschusterei, insofern als damit versucht wird, ein im Grunde (semantisch und/oder syntaktisch) falsches Daten-Schema nachträglich zu flicken aufgrund mühsamer formal-syntaktischer Analyse von (meistens auch nicht gerade präzise erfassten) funktionalen und anderen Abhängigkeiten. Bei der Zerlegung der Relationen bei der Normalisierung wird gezwungenermassen völlig abstrahiert von allen semantischen Aspekten; diese bleiben denn bei der Normalisierung auch oft auf der Strecke, oder sie kommen als formal-mühsam gewonnene Erkenntnis wieder heraus, die man bei sorgfältiger semantischer Analyse der Zusammenhänge direkt hätte gewinnen können. Beispiel: in einem Bestellungserfassungssystem für ein Versandhaus müssen Daten über Kunden und Bestellungen in separaten Tabellen abgelegt werden.

Der bekannte Ausspruch von Niklaus Wirth "In engineering, it is often wiser to avoid a problem rather than solve it!" gilt auch hier. Die Ziele der Normalisierung werden durch gutes systematisches Design von Anfang an sicherer und zuverlässiger erreicht als durch nachträgliches Normalisierungs-Flickwerk. Die für mich beste Methode hierzu ist der von Hanswalter Buff, Zürich, entwickelte und beschriebene ER-Dialekt (Entity Relationship for Relational Databases). Darin stellt Buff sechs Produktionsregeln für "korrekte" ER-Schemata auf; dabei ist der Begriff "korrekt" im streng mathematischen Sinne wohldefiniert: korrekt sind alle ER-Schemata, die aus dem leeren Schema durch sukzessive Anwendung von jeweils einer der sechs Produktionsregeln erzeugt werden können. Das entstandene ER-Schema kann direkt als Relationales DB-Schema interpretiert werden: alle 'Striche' zwischen den Kästchen (Entitätstypen) und Rhomben (Beziehungstypen) sind Pfeile und bedeuten Schlüssel-Fremdschlüssel-Beziehungen. So etwas wie "ER-to-Relational Mapping" wird völlig überflüssig, das ER-Schema ist selbst das Relationale DB-Schema. Wenn man sich an die sechs Produktionsregeln von Buff hält, ist das Ergebnis ein DB-Schema in IDNF (= Inclusion Dependency Normal Form), das ist eine Normalform, die stärker ist als BCNF (= Boyce-Codd Normal Form). Normalisierung wird damit überflüssig, das DB-Schema ist normalisiert 'by design'. (Literatur: Hanswalter Buff: Datenbanktheorie ISBN 3-0344-0201-5)

In Anbetracht dieser Kritik finde ich den Artikel so, wie er jetzt ist, noch nicht wirklich lesenswert. (Kann man beantragen, so eine Klassifikation wieder aufzuheben? Wie?)

Soll ich diese Sachen in den Artikel einbauen? Wenn ja, wo? Eher am Anfang oder eher am Schluss? Wenn nein, gibt das einen eigenen Artikel? (Ich denke, kaum.) — Nol Aders 10:34, 19. Dez 2005 (CET)

Halo Nol, ich habe davon bis jetzt noch nicht gehoert, aber es klingt sehr interessant. Fuer mich klingt das mehr wie ein eigener Artikel, der aber von hier deutlich sichtbar referenziert werden sollte. -- Gruss sparti 13:35, 19. Dez 2005 (CET)

Wenn ich versuche, das einmal zu konkretisieren: neuer Artikel, Arbeitstitel "Entity Relationship Modellierung für Relationale Datenbanken" — ein bisschen lang, (aber da gibt es, glaub'ich, keine formelle Limite, oder?). Alle einverstanden, wenn man das 'ER' englisch und unabgekürzt belässt? Müsste deutlich referenziert werden von diesem Artikel, von Relationale Datenbank, Entity-Relationship-Modell, Structured-Entity-Relationship-Modell, Datenmodellierung, Kardinalität (Datenbanken) u.a. — Nol Aders 16:29, 19. Dez 2005 (CET)

Hi Nol. Auf der Seite WP:KLA können lesenswerte Artikel mit einer entsprechenden Begründung jederzeit in dem Abschnitt "Wiederwahl" wiedergewählt bzw. - falls nicht - abgewählt werden. Läuft gemäß den Regeln oben auf der Seite analog zur normalen Wahl. Gruß, norro 14:18, 19. Dez 2005 (CET)

Danke. — Nol Aders 16:29, 19. Dez 2005 (CET)

Hi. Deine begründung ist nich ganz schlüssig. Nur weil es eine Methode gibt, die es ermöglicht xNF Relationen abzuleiten, sind diese noch nicht hinfällig. Sie stellen eben "nur" eine klassifizierung von Relationen dar. Der von dir angegebene Artikel setzt zb ein korrektes ERM vorraus, was unter umständen gar nicht so einfach sein kann. Das "Flickwerk" sind lediglich Beispiele, die helfen die unterschiede zwischen verschiedenen NF zu verstehen. Wo NF weiterhin sinnvol sind ist zB wenn man mit einer bestehenden Datenbank arbeiten soll, da hilf ERM->Relationen Ableitung wenig. Auserdem verwendet der Artikel selbst das konzept der NF. NFs helfen beim Verstehen der Probleme bei der Datenbankmodellierung, haben also auch eine didaktische Komponente. Zudem möchte man manchaml eben genau eine NF nicht erfüllen um die performance durch einführen von Redundanzen zu erhöhen. Es stimmt auch nicht, dass ER bereits ein relationales Schema sei. ER ist mehr! Es gibt aggregationen und spezialisierung, bei deren abbildung auf relationelles Schema die Semantik verloren geht. Den Artikel find ich gut, allerdings wäre es in der Tat interessant und sinnvol die Ümsetzungsregeln in einem getrennten Artikel zu erklären, da hierbei sehr schön die zusammenhänge verdeutlicht werden können. mfg Tobi

Volle Zustimmung zu jeder Kritik an Normalisierung! Normalisierung ist überflüssig!!! Studenten und Professoren an den Unis verschwenden ihre und unsere Zeit damit. Ich habe in meinem ganzen Leben noch kein Datenmodell erstellt, das nicht schon normalisiert war! --213.61.130.220 10:59, 27. Apr 2006 (CEST)

Spricht da die Frustration eines Studenten? Und was bitteschön ist denn "normalisiert" - die 1.NF? Wie auch immer, wenn du das Lemma für irrelevant hälts und masochistisch veranlagt bist, dann stell doch einen Löschantrag ;-). Ansonsten empfehle ich dir den Gang in eine Bibliothek. Gruß --Revvar %&§ 11:29, 27. Apr 2006 (CEST)

Die Relevanz der Normalisierung ist am Anfang des Artikels zu relativieren – weiter nichts. Ansonsten darf jeder seine Zeit verschwenden womit er will oder muss. --213.61.130.220 11:37, 27. Apr 2006 (CEST)

Bitte verschone den Artikel von deinem persönliche Frust. Nirgendwo steht das Normalisierung per Hand vollzogen werden muß, auch wenn es Studenten zum Begreifen der Materie so aufgezwungen wird. --Revvar %&§ 12:01, 27. Apr 2006 (CEST)

Bitte verschone die Leser der Wikipedia von der Konservierung irrelevanter Informationen. Die Relativierung der Relevanz gehört in die Einleitung und nicht erst in die Schlussbemerkung. Wenn das hier sonst keiner durchsetzen will, dann tut's mir leid um die Wikipedia, deren Qualität nun von den selbsternannten Beschützern der Artikel abhängt. Neuer Vorschlag: Normalisierung ist in der Praxis vermeidbar und deren Notwendigkeit zeugt von fehlerhaftem Datenbanentwurf (siehe Bemerkungen und oben). Sowohl der Normalisierung als auch den Normalformen kommt deshalb vorwiegend theoretische Bedeutung zu. --213.61.130.220 13:23, 27. Apr 2006 (CEST)

Bitte zeige, wo Normalisierung in der Paxis automatisch vollzogen wird (also nicht von Hand). Bitte definiere Enzyklopädie-Stil. Bitte befasse dich mit dem Thema. Bitte nenne Beispiele, wo Studenten dies immer noch aufgezwungen wird. Bitte unterlasse jegliche Unterstellungen bezüglich der Erfahrungen und Stellung des Autors. --213.61.130.220 13:23, 27. Apr 2006 (CEST)

Ich bin hier nicht dein Nachhilfelehrer. Das die Notwendigkeit von Normalisierung auf einen fehlerhaften DB-Entwurf zurückzuführen sein soll ist lächerlich (ja ich habe den Beitrag oben gelesen, aber hast du dies auch bei allen Antworten getan?). Wenn du in deiner Praxis Normalisierung nicht anwendest, dann spricht das für sich - daraus zu folgern das dies grundsätzlich nicht passiert ist vermessen (hast du eine offizielle Studie dazu?). Nimm dir ein beliebiges Fachbuch zum Thema Datenbanken und lies dir dort durch, wann, warum und wieweit Normalisierung und der bewußte Verstoß dagegen sinnvoll ist. --Revvar %&§ 14:15, 27. Apr 2006 (CEST) PS: Enzyklopädiestil

Ich verstehe überhaupt nicht, wo hier die Stoßrichtung der Diskussion ist. Fakt ist, dass es die Theorie der Normalisierung gibt. Ob die Anwendung dieser Theorie sinnvoll ist oder nicht, sagt doch nichts darüber aus, ob es einen Artikel diese Thematik geben soll! --Matthias

Definition von 2. NF ist falsch

Im Artikel steht: "Eine Relation ist in zweiter Normalform, wenn alle Nichtschlüsselattribute von jedem Schlüsselkandidaten voll funktional abhängig sind."

Es muss aber heißen: "Eine Relation ist in zweiter Normalform, wenn alle Nichtschlüsselattribute vom Primärschlüssel voll funktional abhängig sind." ... dementsprechend sind ein paar weitere Aussagen bei der 2 NF falsch.

Ein Beispiel zum Unterschied: Die Tabelle kann man z.B. auch durch Einführen eines künstlichen Schlüssels (Lied_ID o.Ä.) in die 2 NF bringen. Nach der Definition im Artikel wäre sie dann nicht in 2NF.

mfG

Da finde ich leider keine zuverlässige Quelle: legt man den Primärschlüssel zu Grunde (und bei der 3. auch), wird die BCNF ad absurdum geführt, denn die Freiheit von transitiven Abhängigkeiten, wie die dritte sie fordert, würde dann bedingen, dass es nur eine einzige Determinante gibt: den Primärschlüssel. Da ist die Forderung der BCNF hinfällig, dass alle Determinanten Schlüsselkandidat sein müssen.

Also glaube ich, dass die 2NF mit voll f.a. von allen Schlüsselkandidaten richtig ist.

Unser Problem: bei der 3NF schalten wir auf einmal wieder auf "Primärschlüssel" um. Da entsteht nur dann ein sinnvolles Konstrukt, wenn man nicht über die 3NF hinaus geht (und da auch nicht wirklich: Surrogatschlüssel sind in Relationen mit natürlichen Schlüsseln dann verboten!)

Ich glaube daher, dass die Formulierung einer der angegebenen Quellen richtig ist: http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/chap4.htm#Chap4.5 <zitat>Eine Relation ist in der Dritten Normalform, wenn Sie in der Zweiten Normalform ist und jedes Nicht-Schlüssel-Attribut von keinem Schlüsselkandidaten transitiv abhängig ist.</zitat>

Wenn kein Gegenargument kommt, werde ich die 3NF in bald ändern, denn so kann es auf keinen Fall bleiben. Es entsteht mit der reinen Primärschlüssel-Formulierung einfach kein schlüssiges Bild. Meine Theorie ist, dass viele über die 3NF nicht hinaus gingen, daher die etwas komplexeren Gedanken der NFs zu den Schlüsselkandidaten vereinfacht haben. Man denke an Einstein: <zitat>make it as simple as possible, but no simpler</zitat>. Genau das dürfte hier passiert sein.

BG -- bg phaidros 13:09, 14. Mai 2007 (CEST)

2NF und BCNF

Wie bereits richtig erkannt wurde muß das rot hinterlegte Feld einen inkonsistenten Albumnamen erhalten. Ich habe daher " Album" an den bisherigen Albumnamen angehängt. Dies ist doch häufig genau das Problem, dass sich in der Praxis ergeben würde: Man trägt an verschiedenen Tagen Daten in eine Maske ein und heute schreibt man in das Feld Album "Metallica (schwarzes Album)" und an einem anderen Tag "Metallica, black album". Schon besteht eine Inkonsistenz, die bei Einhaltung der 2NF nicht hätte passieren können.

Zur BCNF: Ich bin auch der Ansicht, dass das Gegenbeispiel für die BCNF bereits die 3NF verletzt, da offenbar die funktionale Abhängigkeit Kostenstelle ---> Kst-Leiter besteht.

Nicht verzagen! Wir kriegen das schon noch hin!

MfG

Lösung 3NF ist keine Lösung!?

Die Tabelle "Künstler" in der Lösung zur 3NF erfüllt IMHO selbst die 3NF nicht, da I_ID -> Interpret und Interpret -> Gründungsjahr. Das Problem wird also so nicht wirklich gelöst. Entweder wird in der Lösung einfach Interpret als PK verwendet (was etwas realitätsfremd ist, da "Interpret" wohl nicht Unique ist) oder aber die Tabelle nochmal aufgeteilt.

Aber freitürlich ist das Gründungsjahr genauso abhängig von der I_ID wie es das Attribut Interpret ist. Dafür wird doch letztendlich ein Primärschlüssel erzeugt: Damit man zusammengehörige Attribute wie Interpret, Gründungsjahr, Gründungsort u.s.w. unter einem identifizierenden Attribut zusammenfasst. Sonst wäre ja in einer Tabelle mit Personalnummer, Name, Vorname und Geburtstag der Geburtstag ebenfalls ein Fehlergrund, um der 3NF zu widersprechen. Mentor 17:04, 23. Okt. 2006 (CEST)

Löschanträge Zerlegungsalgorithmus und kanonische Überdeckung

Hallo Kollegen,

für Zerlegungsalgorithmus_Normalform und Kanonische_Überdeckung laufen gerade Löschanträge. Ich finde, die Artikel/Stubs könnte man gut hier integrieren. Mag sich jemand drum annehmen? --Kurt Seebauer 22:04, 15. Nov. 2006 (CET)

Vierte Normalform

Hier wird verlangt dass: Es darf nicht mehrere, voneinander unabhängige, 1:n-Beziehungen in einer Relation geben

Zwischen PNR und Haustier ist doch eine n:m-Beziehung gegeben und keine 1:n. Meines Wissens nach sind hier ohnehin auch n:m-Beziehungen zwischen Attributen zu berücksichtigen.

2NF und BCNF inhaltlich falsch

Die Reversionen<br\> http://de.wikipedia.org/w/index.php?title=Normalisierung_%28Datenbank%29&diff=32132834&oldid=32132788 <br\> http://de.wikipedia.org/w/index.php?title=Normalisierung_%28Datenbank%29&diff=32132878&oldid=32132834 <br\>

sind meiner Meinung nach unberechtigt habe meine Meinung dazu schon in <br\> http://de.wikipedia.org/wiki/Benutzer_Diskussion:Sparti<br\> dargelegt. Wollte hier aber nochmal die Aufmerksamkeit darauf lenken.

Tut mir leid, aber BCNF = 1NF + weiteres kann ich wirklich nicht glauben (und auch aus etlichen Quellen widerlegen). Das kann nicht richtig sein, denn die BCNF verschärft die 3NF, wie Du auch vielerortens nachlesen kannst, und auch selbst zitierst. Bitte denke den Artikel gründlich durch, er ergibt jetzt nicht nur ein tragfähiges Gedankengebäude, sondern lässt sich auch aus der Literatur schlüssig belegen!

Die Formulierungen, bei denen 2NF & 3NF jeweils nur vom Primärschlüssel abhängen sollten würden dazu führen, dass gemäß 3NF eine Relation nur einen einzigen Schlüssel(kandidat), nämlich den Primärschlüssel haben kann, keine weiteren Schlüsselkandidaten(!), und das kann nicht richtig sein!

Ich bin überhaupt der Meinung, dass Quellen zwar sicher wichtig sind, aber - ohne Dir nahetreten zu wollen - man sollte aus eigenem Wissen schreiben können, und Quellen nur zum Belegen als weitere Sicherheit und zur Weiterführung für den Leser benützen (müssen). Ist das nicht der Fall, so wäre Zurückhaltung angebracht - nichts für ungut. Ich lasse mich immer gern eines Besseren belehren, aber ich fürchte, Du wirst die Lücken in "Deiner" Formulierung nicht schließen können- und das wäre der Beweis, dass sie so nicht richtig sein können.

Wenn Du Dich beteiligen willst, bist Du sicher herzlichst willkommen, aber auch ein Username wäre nett - würde auch die Kommunikation erleichtern. -- bg phaidros 21:47, 21. Mai 2007 (CEST)

Hallo IP,

vielen Dank fuer Dein Bemuehen und sorry, dass es so schnell wieder rueckgaengig gemacht wurde. Aber Phaidros hat exakt meine Bedenken ausgedrueck, als ich den Revert durchgefuehrt habe.

Der etwas unfreundlich Ton beim Revert liegt daran, dass ich nicht erwartet habe, dass die Aenderung ernst gemeint war. Warum glaubst Du, dass die Defintion im Artikel falsch und die Deines Vorelsungsskritpes korrekt ist? Viele Gruesse -- sparti 22:55, 21. Mai 2007 (CEST)

Hallo phaidros,<br\>

Ich bin "IP" und wollt hier einmal meine Argumentation untermauern.<br\>

Zur 2NF:<br\>

Du schreibst: <br\>

"Die Formulierungen, bei denen 2NF & 3NF jeweils nur vom Primärschlüssel abhängen sollten würden dazu führen, dass gemäß 3NF eine Relation nur einen einzigen Schlüssel(kandidat), nämlich den Primärschlüssel haben kann ..."<br\>

Jedoch habe ich in meiner Änderung nur geschrieben, dass die 2NF sich nur auf den Primärschlüssel bezieht.

Dein Argument das sich auf die 3NF bezieht, ist also nicht wirksam.<br\><br\>

Hallo IP,

tut mir leid: Mein Argument gilt sehr wohl: 2NF kann sich gar nicht nur auf den Primärschlüssel beziehen, wenn es mehrere Schlüsselkandidaten gibt, da Primärschlüssel und weitere Schlüsselkandidaten reflexiv abhängig sind. Jede transitive Abhängigkeit zu einem Schlüsselkandidaten ist also auch eine transitive Abhängigkeit zum Primärschlüssel und umgekehrt - qed. Wenn daher weiters 3NF heißen müsste, dass die Relation gänzlich frei von transitiven Abhängigkeiten sein muss, dann ist jeder weitere Schlüsselkandidat KC neben dem Primärschlüssel PC verboten, denn: PC <-> KC -> An, also insbesondere: PC -> KC -> An UND KC -> PC -> An; also transitive Abhängigkeiten. Das führt in eine völlig absurde Struktur, wo jeder Schlüsselkandidat aus gründen der "Normalisierung" ausgelagert werden müsste! Da kann ich gut verstehen, wenn so viele dagegen wettern!

Meine Behauptung ist korrekt (und lässt sich auch bestens in der Literatur belegen, was Dir ja sehr wichtig ist, wie Du später noch schreibst). Da außerdem die 3NF so definiert ist, dass für ihre Erfüllung 2NF erfüllt sein muss, ist es selbstverständlich ebenfalls sehr wohl so wie ich behaupte, dass Textänderungen an der 2NF Auswirkungen auf 3NF haben können.

Nachsatz: Habe gerade einen Fehler in meiner eigenen Argumentation entdeckt (habe über 3NF sinniert, obwohl Du 2NF argumentierst). Also, schauen wir mal, wo uns das hinführt: Jedes Nichtschlüsselattribut muss nach Deiner Formulierung vom Primärschlüssel voll funktional abhängen, nicht aber von anderen Schlüsselkandidaten. Das ist zwar etwas anderes, als ich es oben argumentiert habe, aber es würde bedeuten, dass der Primärschlüssel nicht frei unter den Schlüsselkandidaten gewählt werden könnte. Ich hätte unter denen zu wählen, von denen alle Nichtschlüssel voll funktional abhängen, und nicht unter allen Schlüsselkandidaten. Auch das halte ich mindestens für unwahrscheinlich. Denn formal darf ja kein Unterschied bestehen zwischen Primärschlüssel und anderen Schlüsselkandidaten. Ich bleibe also dabei: ich glaube, dass die Formulierungen für 2NF & 3NF, die sich nur auf Primärschlüssel beziehen, aus einer im Grunde unzulässigen "Vereinfachung" der tatsächlichen Normalformen entstanden sind. -- bg phaidros 18:08, 22. Mai 2007 (CEST)

Zur BCNF:<br\>

Du schreibst:<br\>

"... denn die BCNF verschärft die 3NF ... "<br\>

Das ist vollkommen richtig und das habe ich auch nicht bestritten.

Jedoch sagt dieser Satz nicht aus das die BCNF aus der 3NF hergeleitet wird.

Das nicht, aber die Forderung, dass eine Normalform nur erfüllt ist, wenn ihre Vorgänger erfüllt sind. Ich streite ja nicht ab, dass Du algorithmisch aus 1NF BCNF machen kannst.

Eine Relation kann aus der 1NF in die BCNF überführt werden.

Die Ergebnissrelation erfüllt dann automatisch die 3NF und noch mehr. Deswegen auch "verschärft die 3NF"<br\><br\>

Genau. Und damit hast Du selbst mich bestätigt und Dich selbst widerlegt. BCNF heißt: 3NF muss erfüllt sein, wenn nach Überführung in BCNF 3NF automatisch erfüllt ist.

Zu deiner Meinung über Quellen:<br\>

Natürlich ist es eine lobenswerte Eigenschaft aus eigenem Wissen erzählen zu können.

Das ist nicht lobenswert, das ist die Minimalvoraussetzung, die ich an einen Enzyklopädisten stelle. Das ist ja keine Abschreibübung, sonst machen wir einfach ein Quellen~ und Literaturverzeichnis.

Ich halte diese aber für kein hinreichendes Argument um darauf die Richtigkeit von Aussagen zu berufen.

Ich auch nicht: deswegen untermaure ich es ja auch mit Quellen und einer Schritt für Schritt nachvollziehbaren (!!!) Argumentationskette. "Notwendige" Voraussetzung, nicht "hinreichende"!

Ein Gegenbeispiel haben wir, direkt vor unserer Nase.<br\>

Ja, aber nur hier in Form dieser Diskussionsseite, im Artikel zum Glück nicht mehr.

Ich möchte des weitern zu bedenken geben, das dieses Wiki, nach meinem Verständniss, den Anspruch einer Enzyklopädie erhebt. Das heisst es ist keine Meinungssammlung, sondern eine Faktensammlung.

Daher sollten sind Quellenbelege das A und O sein.<br\>

Nein, schon wieder falsch: das ist eine Enzyklopädie, kein Literaturverzeichnis. In der Encyclopedia Britannica wirst Du auch nicht dauernd finden: "die sagt das", "der sagt das". Fachredakteure schreiben zu ihren Themen, und belegen zur Weiterführung, Vertiefung - und natürlich auch zur Absicherung der eigenen Darstellungen. Außerdem, wie Du richtig sagst: keine Meinungssammlung, sondern eine Faktensammlung: Fakt ist nicht gleich Literaturstelle, denn Papier ist geduldig, wie wir ganz besonders deutlich an diesem Beispiel sehen: wie Du selbst bereits festgestellt hast, beide Formulierungen lassen sich irgendwo in der Literatur belegen. Was machen wir jetzt? Natürlich das einzig sinnvolle: wir halten uns an die Formulierungen, die funktionieren, denn die anderen können nicht wahr sein. Und das bringt uns zurück zu den Fakten. Außerdem: Eine Faktensammlung sit bis zu einem gewissen Grad immer eine Meinungssammlung. Was objektives Faktum ist und was nicht, kann die Wissenschaft gar nicht entscheiden (und will es auch gar nicht - da nehme ich den positivistischen Standpunkt ein) Vor Kopernikus stand in jeder "Fakten"sammlung, dass die Erde eine flache Scheibe ist.

Aus diesem Grund werde ich auch sobald, wie möglich versuchen fundierte Quellen nachzuliefern.<br\><br\>

Bin sehr gespannt!

MfG HexGerd 12:19, 22. Mai 2007 (CEST)

Schau Dir bitte die Links am Ende des Artikels an, schau Dir die 7 Links auf 7 verschiedene (!) Universitäten an, die ich auf Diskussion:Schlüssel (Datenbank) angegeben habe (auch wenn's da um ein etwas anderes Thema ging). Du wirst feststellen, dass meine "Behauptungen" bestens belegt sind. Und vor allem: sie ergeben ein schlüssiges Bild. Das tut keine Formulierung, die sich auf Primärschlüssel beschränkt. Und zwar (nicht nur) imho nicht, weil nach der 3NF Schluss ist und BCNF ad absurdum geführt wird. Wenn Du das an einem Tabellenbeispiel widerlegen kannst, lerne ich gerne dazu...

Freue mich, dass Du registriert hast. Vor weiteren Diskussionen bitte die Argumente der Gegenseite Schritt für Schritt nachvollziehen (tue ich ja auch mit Deinen) und danach selbst den Wahrheitsgehalt beurteilen. Nicht unreflektiert argumentieren: "aber beim xy steht's so und so", das ist tatsächlich kein Argument! -- bg phaidros 13:42, 22. Mai 2007 (CEST)

p.S.: Weil's mir gerade so eingefallen ist: ich habe mal die englische Wikipedia als "Quelle" zu Rate gezogen. Der Text dort ist inhaltlich zu 100% deckungsgleich mit "unserem" hier entstandenen, der (mühsamst!) Denkschrittchen für Denkschrittchen die Fehler ausgemerzt hat, bis wir ihn für tragfähig hielten. Das ist imho ein ganz starkes Indiz für die Richtigkeit beider Texte - sofern es zwischen den Texten tatsächlich noch nie Berührungspunkte gab, also jemand vor mir dort "abgekupfert" haben könnte (oder umgekehrt: die von uns ;-) ). Ich habe den englischen Text jedenfalls gerade eben zum ersten Mal gesehen.

<br\><br\>

Hallo nochmal. Zur 2NF: Naja das is ja genau das Problem, in einigen Artikeln ist es so in anderen so beschrieben.<br\> "Datensätze sollten nur vom Primärschlüssel einer Tabelle abhängig sein" ist z.B aus <br\> http://support.microsoft.com/kb/100139/de<br\><br\> eine Der Quellen zu diesem Artikel<br\> oder:<br\> "A relation R is in second normal form (2NF) if and only if it is in 1NF and every nonkey attribute is fully dependent on the primary key."<br\> C.J Date IBM Corporatin : "An Introduction to Database Systems" Addison-Wesley Publishing Company 1982, ISBN 0-201-14471-9 <br\>

Ich war in der Bibliothek und das erschreckende ist, dass es überall unterschiedlich steht. Ich bin deswegen selber verwirrt und bin daher mittlerweile auf dem Standpunkt, Euch bei der Reversion meiner Änderung recht zu geben. Weiss jedoch nicht, wie es richtig ist.<br\> Jedoch:<br\> Die aktuelle Version erfüllt alle Vorausetzungen meiner Version nur etwas mehr. Sollte die Aktuelle Version richtig sein is alles ok. Sollte die laschere Version genügen ist auch alles ok, da noch immer alle Vorausetzungen erfüllt sind. <br\>

Zur BCNF: Dass muss noch ausdikutiert werden. Muss das aber erst noch aufarbeiten also bitte Geduld ^^

MfG HexGerd

Hi,

genau das ist as Problem: die Literatur ist vollkommen widersprüchlich (obwohl man das von einer formalen Disziplin nicht erwarten würde, oder?). Ich war auch verwirrt, als ich versuchte, die Quellen unter einen Hut zu bringen. Mittlerweile bin ich der Meinung, dass wir darauf hinweisen sollten. Vielleicht in einem Kasten oder so. Aber eins nach dem anderen.

MS-Knowledge-Base-Artikel würde ich eher nicht als fundierte Quelle ansehen. Ich versuche immer eine Universität als Quelle zitieren zu können. Denn bei einer kommerziellen Firma wie MS legt man (verständlicherweise) nicht denselben Wert auf Korrektheit wie das bei einer Uni der Fall ist, sondern auf Praktikabilität. Und wenn man zur Überzeugung kommt "das rafft eh keiner", dann kann schon mal die ein oder andere "Vereinfachung" den Weg aufs Papier finden, denk' ich mir jedenfalls... -- bg phaidros 19:05, 22. Mai 2007 (CEST)

Hi,

ich bin immernoch der Meinung, dass die BCNF aus der 1NF hergeleitet werden kann.

Um dies zu Zeigen will ich dieses mal keine Literatur anbringen, da wir deren Unzuverlässigkeit ja gerade geklärt haben. Ich denke jedoch dass, Sie sicher gerne meine Behauptung durch ein Gedankenexperiment überprüfen werden.

Zu zeigen ist, dass eine Realtion R die nicht die 2NF und 3NF erfüllt, nach dem im Artikel beschriebenen Artikel, in eine Menege von Relationen überführt werden kann, die sowohl der 2NF als auch der 3NF genügen.

Deswegen heir nochmal die Definition die mir vorschwebt:<br\>

"Eine Relation ist in BCNF, wenn Determinante (Attributmenge, von denen andere Attribute funktional abhängen) Schlüsselkandidat ist."

Sei in unserer Ausgangsrelation R nun eine Abhängikeit die die 2NF verletzt, so verletzt diese auch die BCNF udn muss daher aus durch den Algorithmus korigiert werden.<br\>

Denn, wäre ein Attribut von R funktional abhängig von einer echten Teilmenge eines Schlüsselkandidaten (KC Keycandidate), so wäre diese Teilmenge ein Determinant. Da dieser Determinant jedoch kein KC seien kann, greift der Algorithmus.

Seien nun alle funktionalen Abhängigkeiten, die die 2NF verletzten durch den Algorithmus aufgelöst, so ist die erste Bedingung für die 3NF erfüllt.

Zu zeigen ist jetzt nurnoch, dass alle transitiven Abhängikeiten von Nicht-Schlüssel-Attributen zu einem KC ebenfalls aufgelöst werden. Es darf also kein Nicht-Schlüssel-Attribut von ausschliesslich Nicht-Schlüssel-Attributen abhängen. Wäre dies der Fall, so wäre diese Menge von Attributen Determinatn. Der Algorithmus würde auch heir greifen und die Relationen weiter zerlegen.

Wenn der Algorithmus terminiert ist Realtionenmenge daher in der 3NF.

Da der Algorithmus jedoch noch weitere Abhängikeiten betrachtet ist die BCNF eine Erweiterung der 3NF.<br\><br\>

Ich hoffe hiermit meine Gedanekn nachvollziehbar dargelegt zu haben

MfG --HexGerd 20:15, 22. Mai 2007 (CEST)

Hallo HexGerd,

also ich gebe Dir recht, dass die 3NF keine Voraussetzung für die BCNF ist, da die BCNF bereits die stärkere Forderung ist. Der Revert war eher ein Kollateralschaden.

Wo ich Dir aber nach wie vor widerspreche, ist dass die 2NF sich lediglich auf den Primaerschluessel beschränkt. Darin sehe ich eine nicht üblich Vereinfachung, mit den oben von Phaidros beschriebenen Nebenwirkungen.

Auch nochmal ein Wort zur Literatur. Es gibt Bücher, die eine weitgehende Anerkennung genießen, die Microsoft Supportseiten gehören da sicherlich nicht zu. Da stehen manchmal seltsame Dinge drin. Auch sind willkürliche Links im Internet nicht wirklich ernst zu nehmen, da nicht beurteilt werden kann, wer da von wem abgeschrieben hat. Auch bitte Vorsicht mit Quellen innerhalb der Wikipedia, die englischen und deutschen Autoren schreiben zu gerne ungeprüft voneinander ab.

Viele Gruesse -- sparti 21:22, 22. Mai 2007 (CEST)

Hi Sparti,

euren Standpunkt zur 2NF habe ich schon akzepiert. Ich denke wir sind uns jetz einig.

Ich bedanke mich für die Diskussion, sie hat mir auf alle Fälle neue Einblicke verschafft.

MfG --HexGerd 23:33, 22. Mai 2007 (CEST)

Hallo HexGerd, hallo Sparti,

bin auch einverstanden: 3NF ist keine formale Voraussetzung für BCNF. Bin aber dafür, dass wir den Text behutsam ändern. Ich selbst habe jahrelang (wirklich!) dran gekiefelt, dass bei der BCNF auf einmal "fehlte": "der Vorgänger muss erfüllt sein und..", und als ich die entsprechende Formulierung auch anderswo fand, war ich beruhigt, und habe dem keine weitere Bedeutung mehr beigemessen.

Halten wir fest:

1NF: Felder atomar, keine Wiederholungsgruppen

2NF: 1NF + Nichtschlüssel voll funktional abhängig von allen Schlüsselkandidaten

3NF: 2NF + Nichtschlüssel nicht untereinander abhängig (= nur abhängig von den Schlüsselkandidaten = Nichtschlüssel nicht transitiv abhängig von irgendeinem Schlüsselkandidat. "Schlüsselkandidaten" umfasst hier auch den Primärschlüssel)

BCNF: alle Determinanten sind Schlüsselkandidat (in meinen Augen gehört dann aber hier eine gründliche Erläuterung über die Sonderstellung der BCNF: wieso sie diese "Kette" durchbricht, und es auch darf. Gehört "1NF" auch hineinformuliert?)

4NF: 3NF + keine unabhängigen mehrwertigen Abhängigkeiten

5NF: 4NF + Schema lässt sich nicht aus einfacheren Relationen durch Verbundoperationen herstellen ("einfachstes Schema")

Kommen wir so weiter?

Mit 4NF und 5NF habe ich auch noch meine liebe Not, aber das ist ein anderes Thema: wenn ich mit einer bestimmten Relation mit 4NF anfange muss ich aus Normalisierungsgründen so lange Relationen aus- und umlagern, bis ich wieder genau dieselbe Relation vor mir habe, die die 4NF ursprünglich verletzte. Da kann etwas an meiner Idee von 4NF & 5NF noch nicht stimmen, deswegen habe ich diese Textteile auch noch nicht angefasst. Bin diesbezüglich in der Nachdenkschleife, aber das ist wie gesagt ein anderes Thema.

Auch ich bedanke mich für die Diskussion: sie hat mich gelehrt, dass die ursprüngliche Formulierung der BCNF OHNE einen Vorgänger zu nennen doch Bestand hat. Ich halte den Fehler aber für nicht dramatisch, denn durch Erfüllung der BCNF ist ja 3NF erfüllt, also entsteht so besehen kein Schaden. Dass man allerdings beim Normalisieren nach 1NF nicht unbedingt über 2NF und 3NF gehen muss, um zu BCNF (und damit doch wieder 3NF) zu gelangen, ist sicher auch einer Erwähnung wert.

Noch eine Frage, was meint Ihr: Sollte 4NF dann nicht heißen "3NF oder BCNF + ..." Ich wäre selbst eher dagegen, denn aus BCNF folgt ja 3NF, würde aber auch hier eine Sondererklärung anregen.

@HexGerd: Frage zur Definition <zitat>Determinante (Attributmenge, von denen andere Attribute funktional abhängen) </zitat>

Müsste es nicht heißen: "Attributmenge, von denen andere Attribute voll funktional abhängen" ? (Nur so wäre dann nämlich auch 2NF erzwungen, glaube ich jetzt so auf die Schnelle)

-- bg phaidros 10:44, 23. Mai 2007 (CEST)

p.S. @HexGerd: Ich ging davon aus, dass hier in der Wikipedia der Du-Jargon vorherrscht, habe aber auch mit "Sie" nicht das geringste Problem - bitte um Entschuldigung, falls ich Sie mit dem Duzen unangenehm berührt habe. Bitte antworten Sie einfach, wie es Ihnen am angenehmsten ist...

Hallo

"Du" ist mir auch lieber, ich bin nur Vorsichtig wenn ich nicht weiss, wie mein Gesprächspartner angesprochen werden möchte.

Zur Determinante: Da hast du wohl recht, das war ein Unaufmerksamkeitsfehler meinerseits (copy&paste).

Danke

Auch wenn es vielleicht gar nicht hierher passt: trotzdem möchte ich die Gelegenheit nutzen um mich recht herzlich bei allen Beteiligten dieses Artikels bedanken. Dieser hat mir sehr für meine Vorbereitung zur Uni-Klausur geholfen, die Übersichtlichkeit und der Ausdruck ist wirklich spitze.

Vielen Dank. :) --RobertPorter 21:25, 23. Jul. 2007 (CEST)

Verständlichkeit

Dieser Artikel ist wirklich sehr ausführlich und auf diesem Niveau auch recht verständlich geschrieben. Dies gilt jedoch fast ausschließlich für Informatiker, die sich auch für die theoretischen Grundlagen interessieren und schon viel Vorwissen haben. Um einem Laien die Grundprinzipien verständlich zu machen, ist er absolut ungeeignet. Ein Lehrbuch "relationale Datenbanken leicht gemacht" (oder so ähnlich) mit einem derartigen Kapitel würde von den Kritikern zu recht in der Luft zerrissen werden.

Mir ist klar, dass sich Wikipedia nicht als möglichst leicht verständliches Lehrbuch versteht, jedoch sollte es auch kein reines Nachschlagewerk für Spezialisten sein, die über eine Sache bereits großes Vorwissen haben. Unter "Normalisierung" erstmal einen wesentlich nicht-informatiker-gerechten Artikel zu finden, der dann für die Spezialisten auf den derzeitigen Artikel verweist, fände ich darum angebrachter.

Als ich den Artikel angefangen hatte, war dies auch meine Intention. Danach wurde es immer theoretischer. Wenn Du eine eingedampfte Version suchst, dann schau Dir doch mal die Version 19. Apr. 2004 Mentor an. Das trifft glaube ich Deinen Wunsch. Mentor 10:16, 26. Jul. 2007 (CEST)

Nicht verzagen: Die sog. Normalisierung geistert seit über 30 Jahren durch die akademische Literatur - vollkommen überbewertet, wie manche meinen. An die "Laien": Wer Normalisierung nicht braucht, hat alles richtig gemacht und muss das nicht verstehen. An die Profis: Wer akademische Weihen benötigt, schreibt etwas zur Normalisierung, das keiner versteht oder nutzbringend anwenden kann ... --213.61.130.220 10:41, 9. Aug. 2007 (CEST)

Wäre das auch ein Beispiel was die 4NF verletzt? ------------------

Ich habe hier eine 1:n und eine 1:1 Beziehung? Sprich, braucht man wirklich 2 oder mehr 1:n Beziehungen um zu zeigen das es die 4NF verletzt?

Beispiel2

Besitz
Personnummer	Haustier	Alter der Person (nicht des Haustiers)
1	Katze	24
1	Pelikan	24
2	Hund	33
2	Katze	33

Bemerkungen: Normalisierung-Intuition

In den Bemerkungen wird von intuitiver Modellierung in bis zur 4. NF gesprochen. Ein guter Informatiker sollte definitiv in der Lage sein ein Datenmodell in 3NF oder 4NF ohne großes Darübernachdenkens (intuitiv) zu erstellen. Aus leidhafter Erfahrung halte ich diese Aussage aber leider für falsch. In meiner bisherigen Praxis sind mir schon die schlimmsten Datenbankentwürfe vorgekommen. Zur Zeit darf ich auch einen Kollegen überzeugen, dass er doch bitte in seinem Datenmodell wenigstens die 3NF einhält. Er will aber lieber "optimieren". Von Intuiition und nur akademischen Interesse kann hier keine Rede sein. Die Normalisierung ist der theoretische Unterbau, den jemand benötigt um ein gutes Datenmoell von einem schlechten unterscheiden zu können. Bzw. kann man die Verstöße dagegen bzgl. ihrere Auswikrungen besser beherrschen, welche Anomalien auftreten können.

Die Bgründung für Intuition und reiner Theorie sind damit für mich zu vergleichen, dass ein Automechaniker nicht wissen muss wie ein Motor prinzipiell funktioniert, da er ihn ja nur austauschen können muss...

Du möchtest den Hinweis auf die intuitive Modellierung entfernen? -- da didi | Diskussion | Bewertung 19:07, 21. Okt. 2007 (CEST)

Falsch ist, dass Normalisierung der theoretische Unterbau ist, den jemand benötigt, um ein gutes Datenmoell von einem schlechten unterscheiden zu können. Richtig ist, dass es einen theoretischen Unterbau zur formalen Unterscheidung von relationalen Schemata bietet. Belegbar und historisch richtig ist, dass akademische Artikel zur Normalisierung der pulizistische Unterbau mancher Theoretiker-Karriere waren. Falsch ist, dass Praktiker Theoretiker um die Veröffentlichung von Problemlösungen für Probleme gebeten haben, die vor Entdeckung der Normalisierung als theoretisches Betätigungsfeld gar nicht exisiert haben. --213.61.130.220 10:57, 25. Okt. 2007 (CEST)

Irreführende und falsche "Bemerkungen" im Text

"In der Praxis der Datenmodellierung werden die erste, zweite, dritte und vierte Normalform beim Erstellen des Datenmodells meist schon intuitiv eingehalten" - das entspricht überhaupt nicht meiner Erfahrung, die meisten "irgendwie" entstandenen Datenbanken halten 3NF nicht ein. Der folgende Absatz sagt denn auch das glatte Gegenteil davon aus ("Leider Häufig erweisen sich existierende Systeme gerade aufgrund unzureichend normalisierter Datemodellierung") und gipfelt gar in dem Satz "Häufige Beispiele sind zusammengesetzte Schlüssel innerhalb eines Attributs oder Vernachlässigung der 3NF".

Hierdurch ausgelöste Änderungen befinden sich im Artikel. --213.61.130.220 11:51, 25. Okt. 2007 (CEST)

"Eine alternative Herangehensweise zur Erstellung eines Datenmodells ist die Benutzung des Entity-Relationship-Modells (ERM)" - weder ist das ERM eine "Alternative" zur Normalisierung (im Artikel zum ERM steht denn auch, dass zusätzlich normalisiert wird) noch ist es eine "Herangehensweise zur Erstellung eines Datenmodells". Es ist vielmehr eine Notation.

--193.30.140.85 14:16, 22. Okt. 2007 (CEST)

Richtig ist: Das Relationale Datenmodell ist (mit welchen Erweiterungen auch immer) zu schwach, um unerfahrene Modellierer zu brauchbaren Datenmodellen zu verhelfen. Falsch ist, dass man Normalisierung in der Praxis braucht, wenn man seine Entwurfspraxis geeignet organisiert. Richtig ist hingegen, dass unerfahrenes und unbelehrbares Personal durch formale Methoden unterstützt werden sollte. Unstrittig ist, dass die formalen Methoden im Zusammenhang mit der Normalisierung traditionell im Akademischen verhaftet sind und nicht viel zur Praxis betragen konnten. --213.61.130.220 10:46, 25. Okt. 2007 (CEST)

Hierdurch inspirierte Änderungen befinden sich im Artikel. --213.61.130.220 11:30, 25. Okt. 2007 (CEST)

Mir ist allerdings nicht ganz klar, was hiermit "Die 1NF wird meist schon durch das verwendete Datenbankmodell bedingt." gemeint ist. Sonst bin ich mit den Änderungen einverstanden. -- sparti 13:06, 25. Okt. 2007 (CEST)

Hallo sparti, ich habe diesen Satz (der nicht von mir stammt) einfach dringelassen, weil ich darüber keine Diskussionen anfangen wollte und er ja (bisher) auch nicht (direkt oder indirekt) kritisiert wurde. Gemeint ist wohl, dass bei einigen Formalismen bzw. Zielsystemen (bewusst) keine Ausdrucksmittel für geschachtelte Relationen (bzw. relationenwertige Attribute) bereitgestellt werden und man folglich gar nicht erst gegen die 1NF verstoßen kann, sich also die Frage nach der 1NF von selbst (per Definition oder Beschränkung) erledigt. Von mir aus kann der Satz ohne Schaden für den Artikel sang- und klanglos gelöscht werden. Ich denke sogar, dass es ein Gewinn wäre. Sei mutig! --Informat 22:08, 26. Okt. 2007 (CEST)

„atomar” vs. „atomisch”

Ich meine, dass das im Artikel verwendete „atomar” zwar semantisch nicht falsch ist, aber in der Praxis (und auch Lehre) so nicht verwendet wird (Ich habe DB-Trainings abgehalten und verwendete das nie so, viel mehr noch: lese das hier zum ersten Mal.)

„Atomar” ist für mich z.B. eine Gefahr, die atomare nämlich, bzw. überhaupt alles was mit Kernspaltung zu tun hat. Und aus diesem Bereich heraus ist „atomar”, auch in der breiten Bevölkerung, sehr stark besetzt. Da ist die Abgrenzung mit der Verwendung von „atomisch” nur natürlich und vollkommen nachvollziehbar (bzw. so wie ich es kennen lernte auch immer schon so gewesen), auch um eventuelle Missverständnisse von Vornherein gar nicht erst aufkommen zu lassen.

Siehe dazu auch: http://bugs.mysql.com/bug.php?id=31570. --Geri, 09:09, 9. Mär. 2008 (CET)

Wie in ACID beschrieben handelt es sich tatsächlich um eine atomare Operation. Vergleich dazu auch die Standardwerke von Kemper/Eickler, Saake/Türker. Den Begriff atomische Operaiton höre ich heute das erste mal. Grusss -- sparti 10:39, 9. Mär. 2008 (CET)

Hmmm, evtl. wieder ein Thema über das sich vortrefflich philosophieren ließe. Nicht nur wegen „WP als Selbstreferenz“ :-).

Mir ist es grundsätzlich gleich, ich verstehe es auch so. Vielleicht hilft es aber dem einen oder anderen, wenn in einer kurzen Anmerkung erwähnt wird, dass mitunter auch die andere Bezeichnung Verwendung findet. Getreu dem Wiki-Motto :-) habe ich das mal eingefügt, wenn es nicht passt kann man's ja revertieren.

Und noch etwas fällt mir auf: „Jedes Attribut der Relation muss einen atomaren Wertebereich haben.“ Wie sinnvoll ist es, bei einem Bereich mit der Kardinalität = 1 (da atomar) überhaupt von einem Bereich (impliziert von..bis) zu sprechen? Was einen Wertebereich hat ist die Domäne, die sich aus eben atomaren Werten zusammensetzt, oder? --Geri, 19:46, 9. Mär. 2008 (CET)

Wie kommst du darauf, dass Kemper/Eickler und Saake eine Selbstrefrenz sei? Bitte verwechsle meinen Hinweis auf den Hauptartikel nicht mit dem Beleg einer Aussage :) -- sparti 21:29, 9. Mär. 2008 (CET)

Wollte natürlich den – durchaus honorigen – Herren damit überhaupt nichts absprechen. Bezog mich tatsächlich lediglich auf den Link zu ACID :)

Wie ist deine Meinung zu dem in meinem letzten Absatz Gesagten? --Geri, 23:00, 9. Mär. 2008 (CET)

Ich hab Deine Änderung noch ein wenig entschärft, sonst gibts nur wieder Streit.

Wegen dem Wertebereich. Nach meinem Verständnis sind Domäne und Wertebereich equivalent. Somit ist die Aussage schon richtig, oder nicht? -- sparti 12:08, 10. Mär. 2008 (CET)

Grundsätzlich ja, aber m.E. im Zus.hang mit Abschn. 2.1. nicht ganz richtig, dort ist von einem Wertebereich für ein Attribut die Rede, der, da atomar, nicht „mengenwertig“, genau einen Wert enthält. Eine Domäne ist die Menge aller Ausprägungen (Werte) die ein Attribut annehmen kann. Oder konkret im physischen DB-Modell ausgedrückt: Ein Attribut (eines Datensatzes) ist ein Feld (mit genau einem - atomischen - Wert). Eine Domäne ist die Menge aller Felder in einer Spalte.

Oder wenn du es von der mathematischen Seite her aufrollen möchtest: „Domäne (Mathematik), der Bereich aller möglichen Eingabewerte einer Funktion“ D.h. ein Attribut ist equivalent einer Funktion, die Domäne die Menge der Eingabewerte, der Rückgabewert (Funktionswert) der Wert des Attributs. Wobei ich für die absolute Korrektheit der Formulierungen dieses letzten Absatzes als mathematischer Halb-Laie, und mehr Praktiker als Theoretiker, die Hand nicht vorbehaltlos ins Feuer legen würde :-) Lasse mich da aber gerne belehren. Lerne immer wieder gerne etwas dazu. --Geri, 22:40, 10. Mär. 2008 (CET)

Ja, ich verstehe, was du meinst. Ich glaube aber, dass die Aussage genau das besagt, was du meinst :)

Also beim Tuerker zB steht: Dass ein Attribut nur atomare Werte annehmen darf. Diese Werte sind aber doch Elemente eines atomaren Wertebereiches. Somit ist die Aussage im Aritkel doch korrekt? -- sparti 23:58, 10. Mär. 2008 (CET)

Ja, du hast recht...und Tuerker natürlich auch. Genau deswegen hab' ich auch nichts dran geändert und auch nicht gesagt, dass es nicht korrekt ist. Ich habe lediglich gefragt, ob es, z.B. für das Verständnis eines interessierten Laien, sinnvoll ist, einen Werte"bereich" mit genau einem Wert überhaupt als „Bereich“ zu bezeichnen. „Atomarer Wertebereich“ klingt in der Kombination ein wenig wie ein Widerspruch in sich. Bzw. ist es korrekter ausgedrückt ein Sonderfall: ein Bereich mit genau einem Element, bei dem damit Anfang und Ende zusammenfallen.

Oder reden wir gar aneinander vorbei? Was meinst du genau wenn du von einem „atomaren Wertebereich“ sprichst? Die Werte, eigentlich den Wert den ein Attribut (ein Feld) einer Entität (eines DSes) annehmen kann? Oder den Wertebereich der Domäne – aus dem sich jede Entität genau einen Wert für ihr Attribut "herauspickt"? Letzterer kann aber in meinem Verständnis nicht als „atomarer Wertebereich“ bezeichnet werden, sondern nur als „Bereich mit atomaren Werten“. --Geri, 22:25, 14. Mär. 2008 (CET)

Hmm, ich meine letzteres und ich bin ganz naiv davon ausgegangen, dass ein "atomarer Wertebereich" ein "Bereich mit atomaren Werten" sei. Ich gebe zu, dass ich mir darueber auch noch keine weiteren Gedanken gemacht habe. Wie sollte es denn richtiger Weise heissen? -- sparti 23:27, 14. Mär. 2008 (CET)

Mit Naivität hat das nichts zu tun, sondern mit deutscher Sprache und deren Grammatik: Substantiv#Zusammengesetzte_Substantive_(Komposita): „Das Genus eines Kompositums bestimmt immer das Hauptwort, welches als letztes steht“. Im einen Fall ist damit also ein Bereich selbst atomar, im anderen die Werte eines Bereichs. Möchtest du mich mit deiner Frage veräppeln? :-) Ich schreibe jetzt zum dritten Mal, dass es besser, verständlicher m.M.n. „Wert“ statt „Wertebereich“ hieße. Wenn also sonst nichts dagegen spricht, werde ich demnächst mal ein paar Sätze von der Seite eines "Praktikers" in den Artikel einstreuen. --Geri, 17:17, 15. Mär. 2008 (CET)

Ja, tut mir leid, dass ich dich nicht gleich verstanden habe. Fuer mich hat das ganze allerdings weniger mit deutscher Grammatik, als mit mathematischen Defintionen zu tun. Naiv war, dass ich annahm es gaebe eine Definition fuer eine "atomare Menge". Die gibt es aber scheinbar nicht. Folglich sollten wir den Begriff meiden und wie du vorschlaegst, ausschliesslich von atomaren Werten reden. -- sparti 21:09, 15. Mär. 2008 (CET)

Beispiel 3. Normalform zeigt nur 2. Normalform

Das Beispiel zur dritten Normalform ist falsch, da es nur die 2. Normalform zeigt: CD_ID ist hier nur ein künstlicher Schlüssel - der tatsächliche Schlüssel besteht aus Interpret + Albumtitel (CD_ID ist nur ein Alias hierfür). "Jahr der Gründung" ist nun nur von Interpret abhängig - d.h. es wird nur die 2. Normalform gezeigt nicht aber die dritte.

powerstat 17:10, 29. Jun. 2008 (CET)

Grundlegende und gründliche Überarbeitung erforderlich

Der Artikel bedarf einer gründlichen und grundlegenden Überarbeitung in mind. folgenden Punkten:

Vor meiner Überarbeitung enthielt er viele veraltete, ungenaue, dem "state of the art" widersprechende und im Verlauf des Artikeltextes widersprüchliche Formulierungen zum Themenkomplex Redundanz/Performance/Konstistenz. Ich habe das tw. bereinigt. Es gibt aber noch viel zu tun.
Der 2. Absatz ist auch in der ggw. Fassung noch sehr unbefriedigend und sollte nochmal von jemandem, der 100%ig in der Theorie drinsteckt, überarbeitet werden.
Das äußerst unglückliche Beispiel der Postleitzahlen, das in dieser Form zumindest für die BRD nicht zutrifft, habe ich entfernt.
Tw. habe ich damit begonnen, die unglücklichen Konjunktivformulierungen durch Indikativ zu ersetzen.
Der Artikel arbeitet im Übermaß mit Anführungsstrichen. Vor allem bei

Tabellennamen, mein Vorschlag: Tabellen einheitlich in dieser Form benennen t_Adressen
bildhaften Ausdrücken: hier hat wohl irgendein Autor, wenn er sich der Ungenauigkeit bewußt war, dies durch Anführungsstriche auszugleichen versucht.

--Alfred 17:42, 28. Dez. 2008 (CET)

Ohne nun jede Zeile mit der Version vom 28. Dez. zu vergleichen, würde ich sagen, dass der Überarbeiten-Baustein raus kann. Viele Punkte, die du aufzählst sehe ich nicht (mehr) im Artikel, weil er überarbeitet wurde. --Euku:^⇄ 11:59, 3. Mär. 2009 (CET)

Das sind alles nur einzelne kleine Änderungen, viele hin- und her-Geschichten, Kosmetik an Tabellen usw. Ne, ne, unter einer gründlichen und grundlegenden Überarbeitung versteht man was anderes. Sonst muß er eben seinen Lesenwert-Stern abgeben. --Alfred 19:20, 3. Mär. 2009 (CET)

Edit vom 31.12.2008

So, das war's, den Rest besorgt Ihr. Sollte sich hier nichts passieren, muß man halt alles, was schlecht bzw. unverständlich formuliert, falsch oder unbelegt ist, rausschmeißen. Täte mir leid um einen ansonsten wirklich sehr informativen und lesenswerten Artikel. --Alfred 17:37, 31. Dez. 2008 (CET)

Bitte Halbsperren!!

Kann bitte mal jemand mit Berechtigung den Artikel halbsperren?!

Ich kann nicht bei jedem Sichtungsvorgang überprüfen, ob es sich um eine Art Vandalismus von irgendwelchen Plattenfans handelt oder es wirklich falsch war, was geändert wurde. Die Arbeit an solchen Artikeln ist nur möglich, wenn die Autoren miteinander kommunizieren können. Das ist bei IPs nicht der Fall. Ich werde ab jetzt bei jedem Sichtungsvorgang Änderungen von IPs zurücksetzen, wenn es sich nicht um eine eindeutig korrekte Änderung handelt. --Alfred 12:07, 19. Feb. 2009 (CET)

Datei:Shot aufsp 31122008 171700.JPG → Datei:Aufspaltung einer Tabelle in zwei (Beispiel).svg

Bevor irgendwelche Proteste wegen meiner Ersetzung kommen, hier die Gründe:

die Köpfe der einzelnen Tabellen auf dem alten Bild kann man kaum lesen
die per Hand gemalten Pfeile wirken sehr schief und pixelig
für sowas nutzt man SVG statt JPG
nun kann man es sogar ohne ohne Vergrößerung im Artikel lesen
Bild liegt auf Commons, statt de-WP

--Euku:^⇄ 16:42, 24. Mai 2009 (CEST)

Warum sollten "Proteste" kommen, ist doch vollkommen ok. --Alfred 23:24, 24. Mai 2009 (CEST)

3NF

Hallo, warum steht bei der 3NF folgender Satz: "Das Problem ist hierbei wieder Datenredundanz. Wird zum Beispiel eine neue CD mit einem existierenden Interpreten eingeführt, so wird das Gründungsjahr zweimal gespeichert." Wenn man ein neues Album von einem Künstler einfügt, von dem es bereits eines gibt, hat man doch genau das selbe Problem. Warum wird das Problem nur in Bezug auf das Gründungsjahr erwähnt? --193.170.133.61 18:33, 6. Jun. 2009 (CEST)

Hallo! Du schreibst "...hat man doch genau das selbe Problem.". Warum "doch"? Das ist genau das, was das Beispiel beschreibt. Das Problem bezieht man auf das Gründungsjahr, weil das eine redundante Information ist. In diesem Beispiel gibt es doch die Abhängigkeit "Interpret" → "Gründungsjahr". Wenn du ein neues Album hinzufügst, musst du auch einen "Interpreten" angeben, und zu diesem auch das "Gründungsjahr", was aber immer vom Interpreten bestimmt wird (=Redundanz). Eine weitere solche Abhängigkeit sehe ich nicht, darum wird auch nur diese erwähnt. Ist das etwas klarer? Gruß --Euku:^⇄ 21:36, 6. Jun. 2009 (CEST)

Hallo, Danke für die Antwort, ich habe mich da wohl leider ungenau ausgedrückt. Ich meinte, dass man, wenn man ein neues Album von einem Künstler einfügt, von dem bereits die Informationen über ein Album vorhanden sind, dann nicht nur beim Gründungsjahr eine Redundanz hat, sondern ebenso beim Künstler, da der selbe so oft gespeichert wird, wie es Alben von ihm in der DB gibt. Deswegen wollte ich wissen, warum das Problem der Redundanz nur in Verbindung mit dem Gründungsjahr genannt wird, jedoch nicht in Verbindung mit mehrmaligem Vorkommen des selben Künstlers.

--193.170.133.37 09:02, 8. Jun. 2009 (CEST)

Abgesehen von Gründungjahr gibt es natürlich bei Interpret die Möglichkeit zu Anomalien, jedoch ist Interpret ein eindeutiger Bezeichner und in der Lösung des Beispiel ein Fremdschlüssel. Man kann ihn ohne Informationsverlust nicht weglassen und das versteht man unter Redundanz. Zum Feststellen, was die 3NF verletzt betrachtet man nicht, was wo wiederholt wird, sondern wie die Abhängigkeiten aussehen. Nur die transitive Abhängigkeit zwischen CD_ID und Gründungsjahr ist entscheidend, da es für den Interpreten keine solche gibt, wird er auch nicht erwähnt.
Die Formulierung im Text war aber mit "zweimal gespeichert" wirklich unglücklich, habe es geändert. --Euku:^⇄ 10:09, 8. Jun. 2009 (CEST)

@Alfred: Bevor du wieder einen Edit-War anfängst, könntest du das und das begründen? --Euku:^⇄ 11:59, 8. Jun. 2009 (CEST)

@Euku: Zur 2. Änderung: Ring dich doch mal durch, die von mir vorgeschlagene Halbsperrung zu machen, dann ist sowas nicht notwendig. Ich habe hier klar gesagt, daß ich Änderungen von IPs, wenn sie keine offensichtlichen Verbesserungen sind, revertiere. Zur 1. Änderung: "Hier liegt offenbar eine Knieverletzung vor: Bei Eröffnung des Kniegelenkes zeigte sich, daß das Knie verletzt war." oder "Hier liegt offenbar eine Knieverletzung vor: Bei Eröffnung des Kniegelenkes zeigte sich, daß der Meniskus eingerissen war." - welcher der Sätze ist deiner Meinung nach informativer, vor allem: Was ist eigentlich von dem 1. Satz zu halten? Du hast eklatante Schwächen im Umgang mit Sprache - ändere das! --Alfred 12:56, 8. Jun. 2009 (CEST)

Nicht alles was hinkt ist ein Vergleich, und ein Knie schon mal gar nicht. Hast du überhaupt gelesen, was 193.170.133.37 schreibt, oder sind IPs für dich so minderwertig? "ein zweites Mal gespeichert" ist keine zusätzliche Information zu "redundant gespeichert" und kann, wie in diesem Fall gezeigt, missverstanden werden. Redundant ist eine Information, die ohne Informationsverlust weggelassen werden kann (wie Gründungsjahr). != Ein Eintrag, der mehrfach gespeichert wird (wie Interpret). Im Beispiel ist die Rede von Redundanz, nicht von mehrfach auftretenden Einträgen.

Zur zweiten Änderung: Weißt du eigentlich oder vermutest du nur, dass die Änderung falsch ist? Oben schreibst du "[Der Absatz]...sollte nochmal von jemandem, der 100%ig in der Theorie drinsteckt, überarbeitet werden". Könnte es sein, dass ein SAP-Mitarbeiter [1] doch etwas von der Materie versteht, wenn er zum zweiten Mal darauf hinweist? Hast du versucht ihn anzusprechen (statische IP)? Schaden kann es nicht... Genau deswegen wird es keine Halbsperrung für den Artikel geben. Was du irgendwo ankündigst, ist nicht maßgeblich.

"Du hast eklatante Schwächen im Umgang mit Sprache - ändere das!"

LOL! Ohne Worte... --Euku:^⇄ 13:53, 8. Jun. 2009 (CEST)

Ich sehe es ein - an der Sprachkompetenz liegt es nicht... EOD. --Alfred 17:12, 8. Jun. 2009 (CEST)

Sondern? Und was ist "es"? --Euku:^⇄ 17:20, 8. Jun. 2009 (CEST)

5. Normalform falsch beschrieben

Eine Relation ist in 5NF, wenn sie durch Projektion und späteren Verbund nicht rekonstruiert werden kann.

Meines Erachtens ist die Wahl der Tupel des Beispiels problematisch. Auf der einen Seite sollen ja die Möglichkeiten der Verbindungen ausgedrückt werden, somit liegt die Relation nur in 4NF vor und läßt sich weiter aufspalten, um zur 5NF zu gelangen. Wenn diese Möglichkeiten jedoch beschrieben werden sollen, dann sollte bzw. muß das unten markierte Tupel bereits oben enthalten sein, denn sonst ist der Datenbestand inkonsistent. So, wie es momentan dargestellt ist, suggerieren die 3 Tupel, daß die tatsächlich erfolgten Lieferungen erfaßt wurden. In diesem Fall läge jedoch auch keine Verbundabhängigkeit vor, die Relation befindet sich dann bereits in 5NF. --ErikReischl 09:02, 13. Okt. 2008 (CEST)

Richtige Anmerkung: die gegebene Definition (Relation lässt sich nicht mehr zerlegen, 18.11.09) ist schlichtweg falsch: sie bedeutet, dass man am Ende NUR mir Tabellen landet, die aus einem Schlüssel und EINEM weiteren Feld bestehen. Genau das Gegenteil ist richtig: die Relation lässt ich nicht durch Verschmelzung aus einfacheren herstellen. Das bedingt bspw. auch, dass man bei 2&3NF gezwungen ist, ALLE Atrribute mit ihrer Determinante in EINE neue Tabelle auszulagern, und nicht etwa mehrere Tabellen für eine Determinante erzeugen darf. Ich ändere das jetzt. -- bg phaidros 08:07, 18. Nov. 2009 (CET)

Wiederholungsgruppen

{Telefon1, Telefon2, Telefon3} ist kein Beispiel für Wiederholungsgruppen, sondern ein Beispiel wäre in _EINER_ Spalte 'Telefon' mehr als eine Telefonnummer. Siehe: http://www.dbdebunk.com/page/page/622301.htm und http://www.dbdebunk.com/page/page/622318.htm. Eine Tabelle die die Spalten {Telefon1, Telefon2, Telefon3} enthält kann laut Definition in der ersten Normalform sein, da sie weder Wiederholungsgruppen, noch nicht atomare Attributwerte enthält. Sie kann sogar in der 2. und 3. Normalform sein, da sowohl Telefon1, als auch Telefon2, als auch Telefon3 von einer Person voll funktional abhängig sind, und auch untereinander keine transitive Abhängigkeit besteht. Ob man diese drei Spalten in eine eigene Relation auslagert ist eine reine Designfrage und hängt von den Anforderungen der Anwendung ab.

Aus der englischen Wikipedia (http://en.wikipedia.org/wiki/First_normal_form#Repeating_groups_across_columns)

This representation, however, makes use of nullable columns, and therefore does not conform to Date's definition of 1NF. Even if the view is taken that nullable columns are allowed, the design is not in keeping with the spirit of 1NF.

"the design is not in keeping with the spirit of 1NF" ist der Schlüsselsatz, denn es wird nicht gesagt, dass sie nicht der 1NF entspricht, sondern dass sie ihrem Geist nicht entspricht! Wenn man "NULL" als Wert erlaubt, befindet sich diese Tabelle in der 1. Normalform!

Selbstverständlich würde man aber in solch einem Fall, aufgrund der Tatsache, dass die Anzahl der Nummern variabel ist, die Telefonnummern "aus Designgründen" in eine eigene Relation auslagern. (Dann würden sich beide Relationen mindestens in der 1. Normalform befinden.) 11:53, 24. Sep. 2009 (CEST) (ohne Benutzername signierter Beitrag von 80.153.29.93 (Diskussion | Beiträge) )

Jepp, das stimmt. Korrigiere es doch direkt. --Euku:^⇄ 12:32, 24. Sep. 2009 (CEST)

Transitivität

Was zum Teufel ist transitiv????(nicht signierter Beitrag von 80.144.251.146 (Diskussion | Beiträge) 09:27, 22. Jan. 2010 (CET))

Das hier ist eine Enzyklopädie und keine Mathe-Nachhilfe. Wenn du wissen willst, was Transitivität ist, frag deinen Lehrer. --P.C. ✉ 09:31, 22. Jan. 2010 (CET)

Weitere Normalformen

Die hier dargestellten Normalformen sind zwar die bekannten aber es gibt in der Datenbanktheorie noch weitere, die zumindest genannt werden sollten: Elementary Key Normal Form (Zaniolo 1982), Key-Complete Normal Form (Vincent 1998), Domain-Key Normal Form (Fagin 1981), Inclusion Normal Form (Ling und Goh 1992), Inclusion Dependency Normal Form (Mannila und Raiha 1986) und die Sixth Normal Form von Date (2004). (nicht signierter Beitrag von 82.113.121.229 (Diskussion | Beiträge) 18:22, 26. Jan. 2010 (CET))

Kritik

Ich muss sagen der Text ist zu abstrakt verfasst und schlecht verständlich. Außerdem: Wo liegt der Unterschied zwischen Beispiel und Lösung?(nicht signierter Beitrag von 194.94.23.23 (Diskussion) 14:33, 26. Jun. 2010 (CEST))

Genauer geht es wohl nicht? --Euku:^⇄ 14:45, 26. Jun. 2010 (CEST)

Fehler im Beispiel für BCNF

Wirklich ein toller Artikel, er hilft mir viel beim Lernen!

Ich glaube jedoch, einen Fehler gefunden zu haben: Das Beispiel hat die funktionalen Abhängigkeiten (FD) {Name, Sportart} → {Verein} und {Verein} → {Sportart} und ist wegen letzterer nicht in BCNF. Es hat somit die Form {AB → C, C → B}. Laut englischer Wikipedia ist es allerdings nicht möglich, ein Schema dieser Form befriedigend in BCNF umzuwandeln.

Die präsentierte Lösung ist zwar in BCNF, es wäre aber das Einfügen des folgenden Tupels möglich: (Verein=FCZ, Sportart=Fußball) und (Name=Schuster, Verein=FCZ)

Es ist möglich, die Anomalie zu unterbinden, das Schema ist dann aber nicht mehr in BCNF: Sportverein = {Verein, Sportart} und Sportler = {Name, Verein, Sportart} mit FK {Verein, Sportart} nach Sportverein

Bitte um anderes Beispiel :-) Ich kann noch keines geben, da ich in diesem Thema noch nicht sattelfest bin.

--82.130.72.8 17:02, 9. Aug. 2010 (CEST)

Definition 3NF

Ich finde den Artikel ganz gut. Eine Sache verstehe ich nicht ganz. Wieso wird der Begriff tranisitiv abhängig verwendet, um 3NF zu erklären, anstatt gleich die Definition zu nehmen, die unter "Einfach gesagt:" steht?

Ich denke, dass das die Anzahl der Leute, die nach dem Durchlesen 3NF verstanden haben, dadurch erheblich verkleinert wird. Ein Beleg dafür, dass dieser Begriff verwirrt, ist die Tatsache, dass die Definition von transitiv abhängig und damit von 3NF bis vor kurzem fehlerhaft war (" $(P\rightarrow B)$ und $(B\rightarrow A)$ , aber nicht $(P\rightarrow A)$ ").

Der Begriff hat sicher seine Berichtigung, aber ich würde die erste Definition von 3NF nicht daran koppeln.

-- 130.83.162.84 16:23, 1. Sep. 2010 (CEST)

Fehler im ersten Beispiel

Gleich das erste Beispiel (Kap. 1.1) ist Käse: In der Tabelle tbl_AdressenAlles ist das Nicht-Schlüssel Attribut "Ort" abhängig von dem Nicht-Schlüsselattribut "PLZ", denn die Postleitzahl determiniert eindeutig den Ort (jedenfalls in Deutschland). Dies widerspricht der 2. Normalform (jedes Nicht-Schlüssel-Attribut darf nur abhängig sein vom gesamten Primärschlüssel), muß also geändert werden. So weit, so richtig.

Nun wird im Kap. 1.1 die Aufteilung der Tabelle tbl_AdressenAlles in zwei andere Tabellen vorgeschlagen, eine davon ist die Tabelle tbl_PLZOrt. Diese Tabelle enthält nicht nur die Attribute "Ort" und "PLZ", sondern zudem noch eine ID für jeden Datensatz "PLZOrtID".

Doch in dieser zweiten Tabelle findet sich derselbe Schönheitsfehler der ursprünglichen Tabelle tbl_AdressenAlles wieder: das Nicht-Schlüssel Attribut "Ort" ist nach wie vor abhängig von dem Nicht-Schlüsselattribut "PLZ", weil immer noch die Postleitzahl eindeutig den Wohnort determiniert. Nach wie vor also ein Verstoß gegen die Normalform. Wir sind mit der zweiten Tabelle tbl_PLZOrt also keinen Schritt über das ursprüngliche Maleur hinausgekommen.

Was soll dieser Blödsinn?

Soweit ich sehe, gibt es die Möglichkeit, in der Tabelle tbl_PLZOrt den Primärschlüssel "PLZOrtID" zu tilgen und stattdessen das Attribut "PLZ" als Primärschlüssel zu definieren. In diesem Fall würde in der Tabelle tbl_PLZOr jedes Nicht-Schlüssel-Attribut allein vom gesamten Primärschlüssel abhängen. Der Primärschlüssel wäre (wie gefordert) eindeutig, weil keine zwei Orte dieselbe PLZ haben.

-- 194.120.88.1 11:02, 1. Jul. 2010 (CEST)

Ja, das ist etwas unglücklich, aber man kann es auch etwas ruhiger erklären. Habe es korrigiert. --Euku:^⇄ 14:59, 1. Jul. 2010 (CEST)

-- Hey Captain Käse junge, in Deutschland gibt es durchaus mehrere Orte mit der gleichen Postleitzahl! Somit ist bei den aktuellen Relationen nicht mehr eindeutig feststellbar in welchem Ort der Kontakt nun wirklich wohnt. Also wars vorher vermutlich schon richtig. -- (nicht signierter Beitrag von 212.7.163.78 (Diskussion) 22:59, 5. Sep. 2010 (CEST))

Ich bin auch grad drüber gestolpert; auf Rügen gab es 1993 mal 150–200 Orte mit derselben PLZ (Auszug). Ich empfehle Ersatz der Adresse durch Bankverbindung={BLZ;Geldinstitut;Kontonummer} mit ausgliederungsfähigem Tupel {BLZ;Geldinstitut}.

Das Beispiel ist ohnehin ein vereinfachtes Spiel; in der realen Welt haben Kunden eine physische/ladungsfähige Adresse, eine Anschrift für Briefpost (Postfach), eine Lieferanschrift (Pakete/Speditionen), … ein Auftrag soll an die Stamm-Anschrift geliefert werden, ein anderer an eine Filiale …

Nur munter zu --PerfektesChaos 16:34, 22. Sep. 2010 (CEST)

4. Normalform?

0. Was da im Artikel unter 4. und 5. Normalform steht, ist nicht verständlich. Ein Bewohner kann mehrere Haustiere haben, also ist das eine 1:n Beziehung (3. Normalform). Auch das Beispiel unter 5., ist nicht klar formuliert.

Es ist in der Regel so, dass man bei einer 1:n Beziehung, eine Relation her muss. Bei einer n:n Beziehung muss eine Mapping-Tabelle her.

Bspw.

Artikel <- Positionen -> Bestellung (Positionen  [Bestellmenge , Artikel_RefID,  Bestellung_RefID] )

1. Wie wäre es, den Datentyp innerhalb der Spaltenbezeichnung mit festzuhalten?

bspw.

Guid_ArticleID string_ArticleNr ...

2. Darüber hinaus, gilt es über die maßgebliche Qualität von Entitäten nachzudenken. Eine Dienstleistung kann schließlich als Artikel gepflegt werden. Dazu muss man also nicht zwangsläufig eine neue Tabelle erstellen (Generalisierung). (nicht signierter Beitrag von 88.75.85.24 (Diskussion) 00:22, 20. Jan. 2011 (CET))

2. und 3. Normalform

Die "Lösung" der 2. Normalform verletzt die 2. Normalform immer noch, da das Gründungsjahr vom Interpreten abhängt und Albumtitel und Interpret ein Schlüsselkandidat sind. Was ist der Sinn der 2NF? Könnte man ein Beispiel schreiben, das nur gegen die 3NF und nicht gegen die 2NF verstößt? Dazu müsste ja ein Album zweimal auf verschiedenen CDs vorkommen. --androl ☖☗ 15:51, 9. Mär. 2011 (CET)

CD
CD_ID	Albumtitel	Interpret	Jahr der Gründung
4711	Not That Kind	Anastacia	1999
4712	Wish You Were Here	Pink Floyd	1964
4713	Freak of Nature	Anastacia	1999
4714	Freak of Nature	Anastacia	1999

so, ich glaube, ich verstehe es inzwischen etwas besser, man müsste annehmen, dass es keinen gleichen Albumtitel von verschiedenen Künstlern gibt. Dann ist Albumtitel+Künstler kein Schlüsselkandidat mehr.

Jetzt ergibt sich aber ein weiteres Problem: ist jetzt die Lösung der 3NF gültig? In der Tabelle CD würde aus dem Albumtitel der Künstler folgen, also eine transitive Abhängigkeit Primärschlüssel->Schlüsselkandidat->Nichtschlüsselattribut! Ist das ein Verstoß gegen die 3NF, oder wäre nur PS->NSA->NSA ein Verstoß? Die Einschränkung ohne dass zugleich auch $A_{2}$ direkt von $P_{1}$ abhängig ist ist jedenfalls Blödsinn, da jedes Attribut vom Primärschlüssel abhängt, ich habe diese Aussage entfernt.

Ein besseres Beispiel ist hier beschrieben: da folgt bei der 2NF aus dem Schüler die Klasse und aus der Klasse der Klassenlehrer, außer der Schülernummer wäre nur Name+Vorname ein Schlüsselkandidat, kein Verstoß gegen 2NF. Bei der 3NF ist keine transitive Abhängigkeit (?? - muss bei der transitiven Abhängigkeit das Zwischenelement ein einzelnes Attribut sein oder wäre auch A->B, A->C und {B,C}->D (A=SchülerNr, B=Vorname, C=Nachname, D=Klasse) ein Verstoß gegen die 3NF?) --androl ☖☗ 11:15, 15. Mär. 2011 (CET)

... aus dem englischen Artikel der 3NF geht hervor: A->B->C ist erlaubt, wenn B->A, also wenn B Schlüsselkandidat! Damit wäre das SK-Problem auch gelöst. --androl ☖☗ 11:38, 15. Mär. 2011 (CET)

Beispiel BCNF

Ich habe eine Frage zum Beispiel im BCNF-Abschnitt und bemerkt, dass die Frage bereits gestellt wurde, jedoch unbeantwortet blieb: Diskussion:Normalisierung (Datenbank)/Archiv

Wenn die Tupel (Verein=FCZ, Sportart=Fußball) und (Name=Schuster, Verein=FCZ) eingefügt werden, bleibt "unentdeckt", dass Schuster in zwei Fußballvereinen spielt. Ist das eine Schwachstelle der BCNF oder ist das ein Fehler im Beispiel? -- 217.162.151.111 10:59, 5. Apr. 2011 (CEST)

Relevanz: Redundanz benötigt Speicherplatz

Ist dieses Argument überhaupt noch in der Praxis relevant? Dass alle Lehrbuch-Autoren seit 30 Jahren voneinander Abschreiben und behaupten dies sei ein Argument kann ich nachvollziehen. Wie sieht es heutzutage in der Praxis aus? Ggf. kann das hier dann ja gelöscht werden. -- 77.187.168.96 18:17, 8. Jun. 2011 (CEST)

Es schreiben auch seit Jahrhunderten die Lehrbuch-Autoren bei Adam Ries ab: 3×3=9 – trotzdem stimmt das immer noch.

Natürlich konsumiert Redundanz Speicherplatz. Ob das viel oder wenig, zu verkraften oder nicht ist, hängt vom Einzelfall ab; vom Umfang der redundanten Datenfelder, von der Zahl der Datensätze. Bei großen Datenmengen und großer Verschwendung kann der zusätzliche Speicherplatz (sowie die Transaktionsmenge bei der Distribution) übermäßig sein; bei Kinderspielchen auf einem PC wird bessere Konzeption und Programmierung halt mit billiger Hardware vom Discounter totgeschlagen.

--PerfektesChaos 20:50, 8. Jun. 2011 (CEST)

Anfangsbeispiel

Das Beispiel am Anfang des Artikels ist nicht korrekt. Zumindest in Deutschland ist die PLZ kein eindeutiger Schlüssel für Orte, da es für unterschiedliche Orte die selbe Postleitzahl geben kann (und auch gibt). Daher ist die Relation TBL_PLZOrt falsch, da sie keinen korrekten Primärschlüssel hat. (nicht signierter Beitrag von 132.187.253.25 (Diskussion) 14:52, 24. Nov. 2011 (CET))

Das ist korrekt, zur PLZ 97355 existieren die Orte Rüdenhausen, Abtswind, Wiesenbronn, Kleinlangheim und Castell, von der PLZ kann man also nicht den Ort ableiten. Umgekehrt wurden Würzburg 8 PLZs zugeteilt (die übrigens alle gerade sind, keine ungeraden PLZs). Die sechsstellige PLZ wurde definitiv nicht eingeführt, um Datenbank-Designer glücklich zu machen.
Wenn mal jemand Zeit hat, bitte das Beispiel korrigieren.
--DerElflein 21:08, 15. Feb. 2012 (CET)

Formulierung 1NF

Es stand da irgendwann »alle Attribute atomar sind und die Relation frei von Wiederholungsgruppen ist«. Der markierte Satzteil ist offenbar irgendwann rausgefallen. Zu Unrecht, wie ich meine, einerseits, andererseits nimmt der restliche Text weiter unten sehr wohl noch Bezug auf Wiederholungsgruppen, die die 1NF gemäß dieser Definition aber gar nicht interessieren! Einwände, wenn ich es wieder reinnehme? -- bg phaidros 01:33, 4. Feb. 2012 (CET)

BCNF: altes Problem

Nachdem offenbar ein alter Dissens aufbricht, ob die 3NF erfüllt sein muss, habe ich eine Umformulierung des Abschnitts versucht.

Bei der Gelegenheit bitte um eine Erhellung bei folgenden Sätzen bzw. Satzteilen:

»Eine Relation ist in BCNF, wenn jede Determinante (Attributmenge, von der andere Attribute funktional abhängen) ein Schlüsselkandidat ist (oder die Abhängigkeit ist trivial)«. Ich verstehe diesen Satz nicht einmal sprachlich. Was ist eine triviale Abhängigkeit, was eine nicht-triviale? Kann jemand ein Beispiel bringen, bei der eine Determinante kein Schlüsselkandidat ist, die Abhängigkeit aber trivial ist, sodass die 3NF erfüllt ist?

»Die BCNF (nach Raymond F. Boyce und Edgar F. Codd) verhindert, dass Teile zweier aus mehreren Feldern zusammengesetzten Schlüsselkandidaten voneinander abhängig sind.« Auch hier: ein Beispiel wäre hilfreich. So sagt, mir jedenfalls, das offen gesagt gar nichts.

-- bg phaidros 06:29, 13. Feb. 2012 (CET)

BCNF: Das Beispiel mit den Sportlern ist nichteinmal 2NF, also erst recht nicht BCNF. Ich versuche mal etwas zu basteln, das in 3NF aber nicht in BCNF ist:

ArtikelNr	ABC-Ware	Grundpreis	maxRabatt
400	A	100 Euro	1 Euro
400	B	80 Euro	4 Euro
400	C	50 Euro	5 Euro
401	A	200 Euro	2 Euro
401	B	180 Euro	9 Euro

Erklärung: Wir verkaufen Produkte in den Qualitätsstufen A, B, C. Je minderwertiger die Ware ist, desto billiger ist der Grundpreis (die Preise für B- und C-Ware werden ziemlich willkürlich festgelegt und können nicht aus dem A-Preis berechnet werden). Besonders netten Kunden kann ein Rabatt eingräumt werden, dabei gilt: für A-Ware maximal 1% Rabatt für B-Ware maximal 5% und für C-Ware maximal 10% Rabatt.

Der einzige Schlüsselkandidat ist (ArtikelNr, ABC-Ware)

ABC-Ware und maxRabatt sind voll funktional abhängig vom PK, somit ist 2NF gegeben.

Es existieren keine Attribute, die transitiv abhängig vom PK sind, somit haben wir auf 3NF

Aber:

(ABC-Ware, Grundpreis) → (maxRabatt), aber die Determinante (ABC-Ware, Grundpreis) ist kein Schlüsselkandidat

--DerElflein 22:13, 15. Feb. 2012 (CET)

Es ist nicht von mir, aber was, meinst Du, wäre am Sportlerbeipsiel ({Name, Sportart, Verein} mit den Schlüsselkandidaten {Name, Sportart} und {Name, Verein}) nicht 2NF? Es gibt nicht mal Attribute, die nicht zu einem Schlüsselkandidaten gehören, sie kann also gar nicht verletzt sein. -- bg phaidros 07:45, 16. Feb. 2012 (CET)

Zu dem Problem "Teile von zusammengesetzten PKs sind ... abhängig":

ArtikelNr	WarengruppenID	Warengruppe	Preis
1000	L	Lebensmittel	50 €
1000	K	Kleidung	100 €
1011	L	Lebensmittel	10 €
1011	K	Kleidung	200 €

Schlüsselkandidaten: (ArtikelNr, WarengruppenID) und (ArtikelNr, Warengruppe)
Determinanten: (ArtikelNr, WarengruppenID) → Preis, (ArtikelNr, Warengruppe) → (Preis), (WarengruppenID)→(Warengruppe), (Warengruppe)→(WarengruppenID)
(Warengruppe) bzw. (WarengruppenID) alleine sind aber keine Schlüsselkandidaten also liegt keine BCNF vor
--DerElflein 22:45, 15. Feb. 2012 (CET)

Trivial

Ehrlich gesagt tue ich mir mit dem Begriff "trivial" noch etwas schwer, Matematiker verwenden diesen immer, wenn sie keine Lust haben etwas zu beweisen :-)
Ist "Abhängigkeit ist trivial" gleichbedeutend mit "die Relation besteht nur aus diesen Attributen"?
Bei mehrwertigen Beziehungen (4NF) liest man ebenfalls das Wort "trivial". Kann man das so verstehen: "Eine mehrwertige Abhängigkeit ist trivial, wenn das abhängige Attribut Teil der Determinante ist ODER Determinante+Attribut die gesamte Relation ergeben"?
Beispiel 1: Relation mit den Attributen A und B mit (A,B)→A ist das trivial?
Beispiel 2: Relation mit den Attributen A, B, C (und keine weiteren Attributen) und (A,B)→(C) ist das trivial?
Vielen Dank schon mal für die Antwort!
--DerElflein 23:02, 15. Feb. 2012 (CET)

5. NF

Kann bitte noch mal jemand über den Abschnitt mit der 5. NF drüber gehen? Ich bin gerade am Herausbekommen, welche der Interpretationen, die so im Netz verteilt herumschwirren, denn die richtige sein könnte. Dieses Beispiel, durch das zusätzliche Daten entstehen, ist nicht gerade zielführend bzw. sauber abgetrennt und erweckt den Eindruck, bei der 5. NF gehe es darum, Tabellen aufzuteilen, egal, ob die Daten danach noch korrekt sind oder nicht. --87.187.235.9 21:06, 18. Jan. 2012 (CET)

Habe die Strukturierungen v. 4NF und 5NF etwas überstiegen. Vielleicht ist damit schon inhaltlich ein wenig klarer? Hoffe, ich komme demnächst dazu, das auch inhaltlich etwas genauer anzuschauen. Die Qualität des Artikels ist jedenfalls unvergleichlich besser als noch vor 2 oder 3 Jahren! Gute Arbeit, danke allen Beteiligten! -- bg phaidros 01:29, 4. Feb. 2012 (CET)

"Sie ist somit sehr generell gehalten und dadurch (vorerst) die letzte Normalform." - Passt das noch zu http://en.wikipedia.org/wiki/Sixth_normal_form ? --134.91.30.13 10:53, 12. Mär. 2012 (CET)

4NF: Die Zerlegung führt zur Inkonsistenz?

Hallo allerseits,

danke für das gute Beispiel zur BCNF und die verständliche Erklärung der 4NF! Das Beispiel zur 4NF macht mich aber nicht ganz glücklich oder vielleicht kann es mir noch mal jemand erklären:

Hier die Tabelle noch einmal, allerdings mit etwas anderen Datensätzen:

Person	Haustier	Fahrzeug
1	Katze	Volkswagen
1	Pelikan	Ferrari
2	Hund	Porsche
...	...	...

Zu beachten: Person 1 besitzt 2 Haustiere und 2 Fahrzeuge der zusammengesetzte PK aus allen drei Attributen muss weiterhin bestehen bleiben Haustier und Fahrzeug sind nachwievor unabhängig

Zerlegen wir jetzt die Relation wie vorgeschlagen

Person	Haustier
1	Katze
1	Pelikan
2	Hund
...	...

Person	Fahrzeug
1	Volkswagen
1	Ferrari
2	Porsche
...	...

Wenn ich die Informationen jetzt wieder zusammenführen möchte, also die beiden Tabellen über die Person verjoine, erhalten wir für Person 1 vier Ergebnisdatensätze (jedes Haustier von Person 1 wird mit jedem Fahrzeug von Person 1 kombiniert). Dies entspricht nicht mehr der Ausgangstabelle, dier Zerlegung ist also fehlgeschlagen!

Wäre total klasse, wenn mir jemand auf den Beitrag antwortet. Danke im Voraus! --DerElflein 18:49, 1. Feb. 2012 (CET)

Mit diesem Problem schlage ich mich seit 20 Jahren herum (kein Witz). M.M.n. ist es (unasugesprochener Weise) der Grund dafür, dass in so gut wie allen Datenbankmanuals irgendwo der Satz steht »3NF liefert hinreichend gute Datenstrukturen«. Die einzige »Lösung«, die ich bislang gefunden habe ist die, die Tabellen aufzuteilen, und parallel dazu die ursprüngliche (!?!) Tabelle mit den MWAs beizubehalten, damit man darauf joinen kann und keine Phantomjoins erhält. Was natürlich unsinnig sein dürfte. -- bg phaidros 01:26, 4. Feb. 2012 (CET)

Ist das nicht einfach nur der Wahl des Beispiels und der (künstlich erzeugten) Bedeutung geschuldet? Das Beispiel im Artikel ist korrekt, da hier eben vier Einträge bestehen (und wir den Rest der Tabelle nicht kennen). In diesem Beispiel liegen halt nur 2 Einträge vor und eine Unabhängigkeit der zweiten und dritten Spalte ist willkürlich unterstellt, weil "Haustier" und "Auto" in unserer Welt nicht abhängig sind. Ersetze ich das durch wertneutrale Bezeichnungen und Spalten oder durch das im Anschluss im Artikel gegebene Beispiel "Personennummner, Partner, Kind" löst sicht das Problem sofort, weil die Tabelle dann per Definition in 4NF ist. --134.91.30.13 14:04, 13. Mär. 2012 (CET)

Dritte Normalform: Einführung eines künstlichen Schlüssels überflüssig

Die Einführung des künstlichen Schlüssels Interpret_ID ist nicht notwendig, um das Schema in die dritte Normalform zu bringen. Ausreichend wäre die Relation CD(CD_ID,Albumtitel,Interpret) und die Relation GRÜNDUNG(Interpret,Jahr).

Die Einführung der Interpret_ID hilft möglicherweise dagegen, dass im Falle mehrerer Bands gleichen Namens keine eindeutige Zuordnung der CDs zu einem Interpreten erfolgen kann, aber um dieses Problem geht es an dieser Stelle nicht. --Martin Schröder (Diskussion) 18:21, 11. Jul. 2012 (CEST)

3NF

Ist es nicht verständlicher, wenn man 3NF so definiert:

Die dritte Normalform ist genau dann erreicht, wenn sich das Relationenschema in 2NF befindet, und keine funktionale Abhängigkeit zwischen Nichtschlüsselattributen existiert.

--Jobu0101 (Diskussion) 11:29, 30. Aug. 2012 (CEST)

4NF

Warum soll im unteren Beispiel Partner und Person → Kind gelten? Kann man nicht mehr als nur ein Kind haben? --Jobu0101 (Diskussion) 11:55, 30. Aug. 2012 (CEST)

1NF

Zum Zusatz ganz am Ende: Hat nicht jede Relation automatisch einen Primärschlüssel? Man nehme einfach alle Spalten zusammen. --Jobu0101 (Diskussion) 09:36, 7. Sep. 2012 (CEST)

2NF

Dort steht:

Somit gilt, dass Relationen, die keinen zusammengesetzten Primärschlüssel sondern lediglich ein einzelnes Attribut als Primärschlüssel haben, automatisch die 2NF erfüllen. Des Weiteren erfüllen sie auch die 1NF.

Das ist doch falsch. Eine Relation, die keinen zusammengesetzten Primärschlüssel, sondern lediglich ein einzelnes Attribut als Primärschlüssel hat, kann doch NF1 verletzen und damit automatisch NF2, oder? --Jobu0101 (Diskussion) 11:23, 30. Aug. 2012 (CEST)

auch mein Dozent an der Hochschule meinte die 2. NF sei hier auf Wikipedia falsch, als wir ihm dazu eine Frage stellten weil sein Skript und der Wiki-Artikel hier voneinander abweichen. Gibt es jemand der sich damit so gut auskennt, dass er den Artikel überarbeiten könnte? Gast: 13:10, 13. Okt. 2012 (CEST) (ohne Benutzername signierter Beitrag von 94.218.73.0 (Diskussion))

Die Einführung des künstl. Schlüssels für die Interpreten_ID bei der dritten Normalform ist unbegründet gewesen und irreführend. (nicht signierter Beitrag von 195.37.0.7 (Diskussion) 11:20, 16. Mai 2013 (CEST))

Inzwischen wurde "wenn sie auch die 1NF erfüllen" ergänzt. Dennoch sehe ich ein Problem. Man könnte ein konstates (d.h. von der leeren Menge abhängiges) Attribut haben. auch dann wäre die 2NF nicht erfüllt. --Martin Thoma 19:05, 13. Jul. 2013 (CEST)

Relation und Relationsschema

Ich habe den Eindruck diese beiden Konzepte werden in diesem Artikel konsequent vermischt.
Tatsächlich ist eine Relation lediglich als Mengentrippel definiert, sie kann angesichts fehlender zusätzlicher Struktur gar keiner Normalform genügen. Aus den Elementen des Graphen ließe sich jedoch sehr wohl ausreichend Information zur entsprechenden Betrachtung gewinnen, man könnte ein Relationsschema mit Attributmengen und funktionalen Abhängigkeiten extrahieren. Bei dieser Art von Reverse-Engineering legt die Relation die funktionalen Abhängigkeiten fest, in der Realität sind letztgenannte aber wohl eher ursprünglich bekannte Integritätsbedingungen (z.B. Schlüssel) und daher mitanzuführen!
Es stellt sich die Frage nach der korrekten Notation einer aus Attributmenge, d.h. dem Relationsschema, und funktionalen Abhängigkeiten, also Funktionen zwischen Projektionen auf der zum Schema gehörenden Relation, bestehenden Struktur.
Hier in meinen Universitätsunterlagen wird ein Relationsschema zwar generell als Menge von Attributen definiert, wiederholt aber auch als Tupel aus Attributs- und Abhängigkeitsmenge angegeben; ein scheinbar nur informelles, dafür aber umso zutreffenderes Konstrukt, das eigentlich Gegenstand der Normalisierungsbetrachtung ist.
Dieser Abschnitt soll einen Aufruf zur Klärung der Unterschiede sowie zur Präzisierung der Notation darstellen.
--91.113.120.206 01:18, 11. Jan. 2013 (CET)

»Ich habe den Eindruck diese beiden Konzepte werden in diesem Artikel konsequent vermischt.«

Stimmt, aber das macht nichts. 77.119.129.160 11:07, 2. Sep. 2013 (CEST)

PLZ Beispiel fehlerhaft

Die PLZ/Ort Beziehung ist nicht eindeutig. Es gibt PLZ, die sich über Orts- und Landesgrenzen hinweg erstrecken. Also ist eine Normalisierung in diesem Falle unzulässig.

Siehe http://de.wikipedia.org/wiki/Postleitzahl_(Deutschland)#Systematik (nicht signierter Beitrag von 62.159.55.100 (Diskussion) 16:00, 29. Jan. 2013 (CET))

Ja, der Einwand ist richtig. Allerdings nicht zielführend. Als Anschauung ist das Beispiel ausreichend. Das es in der Realität dann doch komplexer sein darf, ist ja davon unabhängig. (nicht signierter Beitrag von 77.186.199.219 (Diskussion) 04:06, 24. Jan. 2014 (CET))

Wiederholungsgruppen in 1 NF

Hallo, also die Erklärungen zu den Wiederholungsgruppen stimmen doch nicht. Zitat: "Dass die Relation frei von Wiederholungsgruppen sein muss, bedeutet, dass Attribute, die gleiche oder gleichartige Information enthalten, in eine andere Relation ausgelagert werden müssen."

Es geht aber bei Wiederholungsgruppen nicht darum, dass mehrere Attribute gleichartige Informationen enthalten, sondern darum, dass ein Attribut aus mehreren Werten zusammen gesetzt ist, z.B. das Attribut "Adresse" mehrere Adressen beinhaltet. Auch das Beispiel mit Telefonnummern stimmt nicht. Zitat: "Ein Beispiel für eine Wiederholungsgruppe wäre eine Spalte { Telefon }, die mehrere Telefonnummern enthält oder auch eine Spaltengruppe { Telefon1, Telefon2, Telefon3 }, wobei im letzteren Fall anzumerken ist, dass es sich dabei nicht notwendigerweise um eine Wiederholungsgruppe handeln muss (siehe Alternative Formulierungen)."

Woher kommt denn diese Behauptung? Zum Beispiel in dem Buch von Elmasri und Navathe steht in dem Abschnitt über die 1 NF nichts dergleichen, siehe hier: Grundlagen von Datenbanksystemen Es geht dort nur um den atomaren Bereich des einzelnen Attributs. Genauso steht es auf der englischen Version der Wikipedia-Seite und auch in anderen Quellen. --Heops (Diskussion) 19:36, 4. Apr. 2014 (CEST)

3NF

Zitat aus Artikel: "Überführung in die BCNF ist zwar immer verlustfrei möglich, aber nicht immer abhängigkeitserhaltend". Der Punkt "nicht zwingend abhängigkeitserhaltend" ist zwar angesprochen, es fehlt hingegen eine Begründung und ein schlüssiges Beispiel. (nicht signierter Beitrag von 77.186.199.219 (Diskussion) 04:06, 24. Jan. 2014 (CET))

Beispiel BCNF

Laut angegebenen Bedingungen besteht keine 1:1 Beziehung zwischen Verein und Sportart, vielmehr handelt es sich um eine N:1 Beziehung (ein Verein bietet nur eine Sportart an, eine Sportart kann aber von mehreren Vereinen angeboten werden).

Daraus folgt für mich allerdings, dass {Name, Sportart} kein Schlüsselkandidat ist, da sich daraus der konkrete Verein nicht ableiten lässt (nur in dem Beispiel ist das eindeutig, da pro Sportart nur ein Verein eingetragen ist). Wenn aber {Name, Sportart} kein Schlüsselkandidat ist, dann gibt es hier nicht mehrere, sich bei Attributen überlappende Schlüsselkandidaten, somit kann das auch kein Beispiel für eine verletzte BCNF sein. (nicht signierter Beitrag von 84.113.254.126 (Diskussion) 16:07, 10. Jun. 2014 (CEST))

Nein: Die Bedingungen sind

jeder Verein bietet nur eine Sportart an
ein Sportler kann in verschiedenen Vereinen spielen, aber nur, wenn diese Vereine unterschiedliche Sportarten betreiben. Damit wird sichergestellt, dass der Sportler nie gegen einen Verein spielt, in dem er selbst Mitglied ist.

Also kann ich nur(!) dann in mehreren Vereinen sein, wenn sie unterschiedliche Sportarten anbieten (wegen des "aber nur ..."). Das heisst aber, das zu meinem Namen und der Sportart es höchstens einen Verein (also keine zwei Vereine) gibt, somit ist {Nane, Sportart} ein potenzieller Schlüssel.

Was dich verwirren mag: Aus {Name, Sportart} ist nicht vorherbestimmt, was für ein Verein das ist. Das muss es aber gar nicht. Dafür ist der Datensatz da, der einem sagt, welcher Verein es dann ist.

Was allerdings mit dem Beispiel "nicht stimmt" ist: Das Beispiel zeigt nur, warum die 2.Normalform verletzt ist und damit nicht, warum die zusätzlichen Anforderungen für BCNF verletzt werden. (nicht signierter Beitrag von 92.224.174.214 (Diskussion) 19:27, 16. Mär. 2015 (CET))

5. Normalform

Auch die Überführung in die 5. NF ist selbstredend immer verlustfrei möglich. Das im Beitrag verwendete Beispiel eignet sich sogar vorzüglich um aufzuzeigen, wie das geht:

1. Wir versehen eine der Relationen mit einem neuen abstrakten, idR. numerischen Schlüssel. (in der Praxis werden ja auch Liefernanten, Teile und Projekte über je eine solche Identifikation verfügen, die Primärschlüssel je einer Relation ist, wo Dinge wie Lieferantenadresse resp. Bauteilspezifikationen oder Projektbeschrebung, etc. abgelegt sind). Welche Tabelle erweitert wird, kann nach rein sachlogischen Kriterien ('Realitätsbezug') entschieden werden. Wir definieren also z.B. alle Teile, welche ein Lieferant für ein und dasselbe Projekt liefert, als ein "Lieferset". Die Relation Lieferant-Projekt (wir sollten sie in "Lieferset" umtaufen) sieht dann so aus:

idLF | Lieferant | Projekt

 1  | Müller    | Projekt1
 2  | Müller    | Projekt2
 3  | Maier     | Projekt1

...

idLF ist der Primärschlüssel, das Tupel (Lieferant, Projekt) ein Schlüsselkandidat. Die Relation ist in 4. NF (aufgrund der Einmaligkeit von Schlüsseln kann sie keine mehrwertigen Abhängigkeiten enthalten, verletzt auch sonst keine NF und ist elementar, weil die zu einem Lieferset benötigten Informationen nicht mehr kompakter abgespeichert werden können

2. Nun führen wir die Relation Lieferset-Teil ein:

idLF | Teil

 1  | Schraube   
 1  | Nagel   
 2  | Nagel
 3  | Nagel

Die Information welcher Teile ein Lieferant tatsächlich für ein Projekt liefert ist jetzt nicht verlorengegangen und alles ist schön in 5. NF. Ob man das in der Praxis machen wird, kann von technischen Faktoren (Performance) und von konzeptionellen Überlegungen abhängen. Im vorliegenden Fall ist es durchaus plausibel anzunehmen, dass der neu eingeführte Begriff des Liefersets sich als nützlich und auch für die konzeptionelle Beschreibung des Systems als praktisch erweisen könnte: Wenn man z.B. festlegt, dass nur Teile, die zum gleichen Lieferset gehören, in ein und dieselbe Bestellung aufgenommen werden dürfen, könnte das Heissen, dass der Betrag der zugehörigen Rechnung immer einer einzigen Kostenstelle belastet werden kann und nicht gesplittet werden muss.

Peter Schneider www.ps-ps.ch (nicht signierter Beitrag von 83.173.212.238 (Diskussion) 14:10, 21. Jan. 2015 (CET))

Habt ihr's bald?

Das ist echt nervig. Die Seite sollte für IPs gesperrt werden, damit endlich mal eine Diskussion stattfindet. --[[kgh]] (Diskussion) 14:05, 17. Dez. 2016 (CET)

Albumtitel als Schlüsselkandidat

Beim Abschnitt über die 2. NF steht bei der Lösung: "Auch der Albumtitel allein sei eindeutig, also ein Schlüsselkandidat". Zum einen ist das die falsche Art des Konjunktivs, aber vor allem ist der Albumtitel nicht unbedingt eindeutig, und damit auch kein Schlüsselkandidat. Es könnte mehrere Alben mit dem gleichen Titel geben. (nicht signierter Beitrag von Diabolix17 (Diskussion | Beiträge) 04:22, 11. Sep. 2015 (CEST))

Es gibt vielleicht einen Interpreten mit zwei Alben mit demselben Namen. Aber ganz ehrlich: Das ist die Ausnahme und muss nicht berücksichtig werden.

--Grahovam (Diskussion) 10:04, 27. Jan. 2017 (CET)

fehlende Normalisierungsregeln

Aus dem ersten Satz des Artikels (Hervorhebung durch mich): „Unter Normalisierung eines relationalen Datenschemas (Tabellenstruktur) versteht man die Aufteilung von Attributen (Tabellenspalten) in mehrere Relationen (Tabellen) gemäß den Normalisierungsregeln (s. u.)“. Das Wort Normalisierungsregel(n) kommt im Artikel allerdings nicht mehr vor. Es bleibt also unklar, an welcher Stelle im Artikel die Normalisierungsregeln stehen. Ich weiß es selbst auch nicht. Dort, wo diese Regeln stehen, sollte also das Wort „Normalisierungsregeln“, am besten als Teil einer Überschrift, eingefügt werden. --BlackEyedLion (Diskussion) 09:06, 3. Jul. 2017 (CEST)

Durcheinander mit Erscheinungsjahr und Jahr der Gründung

Hallo zusammen,

nachdem ich bei Pink Floyd über das Erscheinungsjahr 1964 für Wish you were here gestolpert bin, habe ich weiter unten bei 3NF gesehen, dass offenbar das Gründungsjahr der Band gemeint war. Ich habe die Tabellen entsprechend abgeändert, damit alles von 1NF bis 3NF zusammenpasst.

Viele Grüße! (nicht signierter Beitrag von 91.53.155.177 (Diskussion) 08:40, 25. Sep. 2015 (CEST))

Jetzt haben wir ein Durcheinander von Erscheinungsjahr und Gründungsjahr. Bei Anastacia ist 1999 das Gründungsjahr, bei Pink Floyd 1975 das Erscheinungsjahr. --Grahovam (Diskussion) 10:02, 27. Jan. 2017 (CET) Ich habe das jetzt korrigiert. Wenn Änderungen rückgängig gemacht werden, dann bitte nicht ohne Diskussion. Wir haben hier einen ziemlich großen Fehler auf der Seite. --Grahovam (Diskussion) 11:30, 27. Jan. 2017 (CET)

@Grahovam: Du hast recht, hier gab es einiges an Durcheinander und war kaum noch nachvollziehbar. Habe noch ein paar der Beispieldaten bei "Erscheinungsdatum" geändert (ggf. waren die ja auch mal richtig). Hoffe es ist jetzt wieder in der Reihe. Ansonsten sollte man wirklich um eine begrenzte Sperre des Artikels nachdenken. Gruß, --W w smith (Diskussion) 15:22, 31. Jan. 2017 (CET)

Erscheinungsjahr und Gründungsjahr ist weiterhin durcheinander ;-) --Dasichs (Diskussion) 17:00, 4. Apr. 2018 (CEST)

Durcheinander mit Erscheinungsjahr und Jahr der Gründung

Hallo zusammen,

nachdem ich bei Pink Floyd über das Erscheinungsjahr 1964 für Wish you were here gestolpert bin, habe ich weiter unten bei 3NF gesehen, dass offenbar das Gründungsjahr der Band gemeint war. Ich habe die Tabellen entsprechend abgeändert, damit alles von 1NF bis 3NF zusammenpasst.

Viele Grüße! (nicht signierter Beitrag von 91.53.155.177 (Diskussion) 08:40, 25. Sep. 2015 (CEST))

Jetzt haben wir ein Durcheinander von Erscheinungsjahr und Gründungsjahr. Bei Anastacia ist 1999 das Gründungsjahr, bei Pink Floyd 1975 das Erscheinungsjahr. --Grahovam (Diskussion) 10:02, 27. Jan. 2017 (CET) Ich habe das jetzt korrigiert. Wenn Änderungen rückgängig gemacht werden, dann bitte nicht ohne Diskussion. Wir haben hier einen ziemlich großen Fehler auf der Seite. --Grahovam (Diskussion) 11:30, 27. Jan. 2017 (CET)

@Grahovam: Du hast recht, hier gab es einiges an Durcheinander und war kaum noch nachvollziehbar. Habe noch ein paar der Beispieldaten bei "Erscheinungsdatum" geändert (ggf. waren die ja auch mal richtig). Hoffe es ist jetzt wieder in der Reihe. Ansonsten sollte man wirklich um eine begrenzte Sperre des Artikels nachdenken. Gruß, --W w smith (Diskussion) 15:22, 31. Jan. 2017 (CET)

Erscheinungsjahr und Gründungsjahr ist weiterhin durcheinander ;-) --Dasichs (Diskussion) 17:00, 4. Apr. 2018 (CEST)

Kannst du, @Dasichs:, bitte mal präzise angeben, worin dieses Durcheinander besteht und ob es evtl. inzwischen geklärt ist?! --NameDerGeht2018 (Diskussion) 13:40, 1. Feb. 2019 (CET)

2. Normalform: Schlüsselkandidaten?

Zitat aktueller Text: "Anders gesagt: Jedes nicht-primäre Attribut (nicht Teil eines Schlüssels) ist jeweils von allen ganzen Schlüsseln abhängig, nicht nur von einem Teil eines Schlüssels. Wichtig ist hierbei, dass die Nichtschlüsselattribute wirklich von allen Schlüsseln vollständig abhängen."

Widerspruch: 1) "Eine Relation R mit Primärschlüssel S befindet sich in der zweiten Normalform (2NF), wenn sie in der ersten Normalform (1NF, Erste Normalform) ist und jedes Nichtschlüsselattribut voll funktional abhängig vom Primärschlüssel S ist (Funktionale Abhängigkeit)." http://wikis.gm.fh-koeln.de/wiki_db/Datenbanken/Zweite-Normalform

2) "Ein Relationenschema ist in der 2. Normalform, wenn es in der 1. Normalform ist und wenn jedes nicht zum Identifikationsschlüssel gehörige Attribut von diesem voll funktional abhängig ist." http://www.gitta.info/LogicModelin/de/html/DataConsiten_Norm2NF.html

Gibt es da einen offiziellen Standard dazu? Einen 1000-seitigen Wälzer oder so. ;)

Ergänzung am 26.06.17: Ich bin auch der Meinung, dass das Bsp. für die 2NF nicht glücklich erklärt ist, da es nicht 100% zu den beiden unter Widerspruch genannten Definitionen passt. Es geht ja darum, dass folgendes gilt: Track -> Albumtitel, Interpret, Erscheinungsjahr. Das tut es in der Tat nicht, es z.B. verschiedene Albumtitel für den Track 1 gibt. Allerdings bezieht sich das Bsp. ja auf die rot markierten Zellen bei Anastasia. Verschiedene Tracks dürfen durchaus auf gleiche Albumtitel etc. verweisen, nur eben darf der gleiche Track nicht auf verschiedene Albumtitel verweisen. IMO wäre CD_ID (als Schlüsselteil) und Titel ein besseres Beispiel, hier offensichtlich, dass die gleiche ID auf verschiedene Titel verweist. Oder?

Bemerkung zu dieser Frage:

Die aktuelle Formulierung ist korrekt, die beiden Zitate 1) und 2) sind falsch. Bei der 2. Normalform muss jedes Nichtschlüssel-Attribut von jedem Schlüssel voll funktional abhängig sein, nicht nur vom Primärschlüssel.

Siehe Vorlesung von Felix Neumann HPI Potsdam "2NF = 1NF und keine Abhängigkeiten von einem Teil eines Schlüssels". Mit "eines Schlüssels" ist hier "einer der möglichen Schlüssel" gemeint.

Oder: "Eine Relation R mit zugehörigen FDs F ist in zweiter Normalform, falls jedes Nichtschlüssel-Attribut A in R voll funktional abhängig ist von jedem Kandidatenschlüssel der Relation." (A. Kemper, A. Eickler: Datenbanksysteme, Oldenbourg 2006, S.182)

--Paul Setzer (Diskussion) 10:53, 5. Aug. 2019 (CEST)

Merkspruch

@NameDerGeht2018: Du hast meine Bearbeitung trotz meines Verweises auf WP:Was Wikipedia nicht ist mit der Begründung "hier ging es um das Verständnis, das durch den Merkspruch auf alternative, zusammenfassende Art erleichtert werden sollte" revertiert. Wenn du meinem Verweis folgst, findest du im Wortlaut folgendes stehen: "Wikipedia ist keine Sammlung von Anleitungen und Ratgebern. Es ist nicht Aufgabe der Wikipedia, zu erklären, wie man eine Redewendung, ein Gerät oder eine Software verwendet, wie man Käfige und Terrarien für Heimtiere einrichtet oder wie man Pflanzen am besten düngt und gießt. [...] Mit der Erstellung von Lehrbüchern und anderen Sachbüchern beschäftigt sich das Schwesterprojekt Wikibooks". Dies entkräftet deine Begründung mit "das durch den Merkspruch auf alternative, zusammenfassende Art erleichtert werden sollte" in meinen Augen vollkommen. --Wikiolo 💬📷 22:55, 18. Jan. 2019 (CET)

Das ist deine Auffassung. Tatsache ist, daß es sich bei dem von dir gelöschten Abschnitt nicht um eine "Sammlung von Anleitungen und Ratgebern" handelt, noch eine Anleitung, "wie man eine Redewendung, ein Gerät... verwendet" oder eine Anleitung, wie man "Käfige und Terrarien für Heimtiere einrichtet...". Von all dem war da nicht die Rede. Insoweit muß ich mich schon sehr über deine Ausführungen wundern. Insoweit kann da auch nichts entkräftet werden. Ich habe aus deinem Obigen nicht viel Einsicht in den bestehenden Sachverhalt entnehmen können und nehme mir daher die Freiheit, zu bezweifeln, daß du den betr. Abschnitt und/oder meine Revert-Begründung überhaupt verstanden hast. Ließ dir bitte beides nochmal durch und melde dich, falls dann noch Fragen sind, auf meiner Benutzer-Disk. --NameDerGeht2018 (Diskussion) 23:06, 18. Jan. 2019 (CET)

Die zutreffenden, relevanten Punkte habe ich sogar extra gefettet. Wieso gehst du denn nicht einfach darauf ein, wenn ich diesen Service schon mache? Diese Art und Weise deiner Diskussionsführung erachte ich für nicht zielführend. Und nein, auf deiner Benutzerdisk werde ich mich nicht melden, sondern einfach erneut revertieren, wenn ich keine entsprechende Antwort erhalte. --Wikiolo 💬📷 23:33, 18. Jan. 2019 (CET)

Ich halte es nicht für besonders geschickt, daß du hier einen Edit-War ankündigst. Und irgendwie scheinst du nicht lesen zu können. Ich bin doch oben auf jeden deiner Punkte eingegangen, wieso behauptest du das Gegenteil?

Zu dem Punkt "meine Diskussionseite": Es ist eine Regel in der Wikipedia, daß man in einem Konfliktfall den Gegenüber auf seiner Diskussionsseite anspricht. Ich habe den Eindruck, daß du derjenige bist, der die Regeln der Wikipedia zur Kenntnis nehmen sollte, bevor du so weitermachst. --NameDerGeht2018 (Diskussion) 23:50, 18. Jan. 2019 (CET)

Du bist nachwievor auf die gefettwten Punkte eben nicht eingegangen. Daher sehe ich kein Gegenarguent gegeben, die derzeitige Version beizubehalten und Revertiere. Auf die PAs gehe ich nicht weiter ein. --Wikiolo 💬📷 08:38, 19. Jan. 2019 (CET)

3 NF Lösung entspricht (eventuell) nicht der 3NF

In dem aktuellen Artikel wird als Lösung die Datenbank aufgeteilt in CD, Künstler und Lied. Zur Bilduing der Relationen zwischen CD und Künstler werden Surrogatschlüssel (CD_ID, Interpret_ID) verwendet. Somit ist bei der Tabelle "Künstler" die 3. Normalform nicht erfüllt, weil das Attribut "Gründungsjahr" funktional abhängig mit dem Attribut "Interpret" ist und nicht mit dem Primärschlüssel "Interpret_ID". Was ist eure Meinung? --NiborKing2

Hallo NiborKing2, in der aktuellen Version des Artikels gibt es zwei Lösungen. Die Lösung mit dem Relationenschema Künstler(Interpret_ID, Interpret, Gründungsjahr) wird angeboten, falls die Möglichkeit bestehen soll, verschiedene Interpreten mit gleichem Namen zu speichern. In diesem Fall besteht keine funktionale Abhängigkeit "Interpret -> Gründungsjahr", da gleichnamige Interpreten sich nicht im gleichen Jahr gegründet haben müssen. Beantwortet das die Frage? MilesTB (Diskussion) 10:26, 31. Mär. 2021 (CEST)

Unverständlicher & überladener Artikel

Ich arbeite seit 98 mit relationalen Datenbanken und 3NF wende ich an, ohne darüber nachzudenken. Wenn ich jedoch den Artikel lese würde ich es nicht verstehen, wenn ich nicht wüsste worum es geht. Nach meinem Empfinden ist der Artikel völlig überladen mit technokratischen Geschwätz. Da wird darüber gelabert das eine Information atomar sein sollte, es aber auch atomisch genannt wird usw. Was damit gemeint ist wird nicht so ganz klar. Man könnte es ja auch in Deutsch als unteilbar oder eindeutig erklären und dann den Fachbegriff atomar einführen.

Was ist nur aus den guten alten Wikipedia:Omatest geworden. --Stanze (Diskussion) 21:33, 9. Nov. 2020 (CET)

Hallo Stanze, ja, mir fehlt auch die Definition zum Fachbegriff "atomar" aus "atomarer Wertebreich", auch wenn ich den Artikel deshalb nicht schlecht oder insgesamt überladen finde. Insgesamt begrüße ich aber, dass der Artikel die Bedingungen für 3NF korrekt/präzise darzustellen versucht. Ich denke, bevor man 3NF korrekt herstellen kann, ohne darüber nachzudenken, muss man dies irgendwann erlernen und üben. MilesTB (Diskussion) 10:33, 31. Mär. 2021 (CEST)

Der Begriff atomar ist ein feststehender Fachbegriff für Datenbanken, den jeder kennen sollte, der mit Datenbanken zu tun hat. Für die WP:OMA wird er im Folgesatz erklärt.--DixMartin (Diskussion) 10:41, 31. Mär. 2021 (CEST)

Hallo DixMartin, mir ist klar, dass es ein feststehender Fachbegriff ist, und ich benutze ihn oft genug. Als Mathematiker bin ich es aber gewohnt, dass jeder Fachbegriff irgendwo ordentlich definiert ist, also wieso nicht dieser, wenn es doch einer ist? Ich finde auch bei einer Wissensdatenbank, in der sich doch gerade auch (noch) Laien informieren, um ihre Wissenslücken zu schließen, den Hinweis "Sollte jeder kennen" nicht gerade hilfreich. Hast Du eine gute Quelle für diese absoluten Basics, die man zitieren könnte? Das könnte diese Stelle doch qualitativ aufwerten. MilesTB (Diskussion) 13:22, 04. Nov. 2021 (CEST)

unvollständige Begründung der zusätzlichen Zeile bei 5NF

Bei der Umformung in die 5NF wird eine zusätzliche Zeile angezeigt, wobei zwei Begründungen aufgelistet sind. Die erste Begründung passt zur neuen Tabelle „Lieferant-Teil“ und die zweite zur Tabelle „Teil-Projekt“. Wenn ich es richtig verstehe, fehlt hier noch eine Begründung die zur dritten Tabelle passt. Offenbar gibt es eine Beziehung zwischen Lieferant und Projekt, d.h. ein Lieferant kann grundsätzlich nur bestimmte Projekte beliefern (weil er z.B. nah genug stationiert ist oder aus einem anderen Grund). Man sollte also folgenden Stichpunkt hinzufügen:

er Projekt 1 grundsätzlich beliefern kann

--Abrissbirne66 (Diskussion) 15:24, 19. Dez. 2020 (CET)

Anonym

Suche

Diskussion:Normalisierung (Datenbank)/Archiv

Uraltes

Falsches Beispiel - Postleitzahlen

Dritte Normalform (3NF)

Erste Normalform

Zweite Normalform

Dritte Normalform

BCNF

Vierte Normalform

Einleitung

falsche Werte in der Beispieltabelle

2. Normalform; Lösungstabelle

2. vs. 3. Normalform

Lesenswert-Diskussion

Anusformen???

NFNF

Einleitung

Grundsätzlich: Normalisierung ist zu kompliziert!

Definition von 2. NF ist falsch

2NF und BCNF

Lösung 3NF ist keine Lösung!?

Löschanträge Zerlegungsalgorithmus und kanonische Überdeckung

Vierte Normalform

2NF und BCNF inhaltlich falsch

Danke

Verständlichkeit

Beispiel2

Bemerkungen: Normalisierung-Intuition

Irreführende und falsche "Bemerkungen" im Text

„atomar” vs. „atomisch”

Beispiel 3. Normalform zeigt nur 2. Normalform

Grundlegende und gründliche Überarbeitung erforderlich

Edit vom 31.12.2008

Bitte Halbsperren!!

Datei:Shot aufsp 31122008 171700.JPG → Datei:Aufspaltung einer Tabelle in zwei (Beispiel).svg

3NF

5. Normalform falsch beschrieben

Wiederholungsgruppen

Transitivität

Weitere Normalformen

Kritik

Fehler im Beispiel für BCNF

Definition 3NF

Fehler im ersten Beispiel

4. Normalform?

2. und 3. Normalform

Beispiel BCNF

Relevanz: Redundanz benötigt Speicherplatz

Anfangsbeispiel

Formulierung 1NF

BCNF: altes Problem

Trivial

5. NF

4NF: Die Zerlegung führt zur Inkonsistenz?

Dritte Normalform: Einführung eines künstlichen Schlüssels überflüssig

3NF

4NF

1NF

2NF

Relation und Relationsschema

PLZ Beispiel fehlerhaft

Wiederholungsgruppen in 1 NF

3NF

Beispiel BCNF

5. Normalform

Habt ihr's bald?

Albumtitel als Schlüsselkandidat

fehlende Normalisierungsregeln

Durcheinander mit Erscheinungsjahr und Jahr der Gründung

Durcheinander mit Erscheinungsjahr und Jahr der Gründung

2. Normalform: Schlüsselkandidaten?

Merkspruch

3 NF Lösung entspricht (eventuell) nicht der 3NF

Unverständlicher & überladener Artikel

unvollständige Begründung der zusätzlichen Zeile bei 5NF

Navigation

Wikiwerkzeuge

Seitenwerkzeuge