Grundsatzfrage zum Normalisierungsprozess (1NF, 2NF, 3NF) und PK bzw. m:n-Beziehungen

S

SchweinchenSchlau

Neuer Benutzer
Beiträge
4
Hallo Leute,

vielleicht versteht ja hier wer, was ich meine und hat vielleicht sogar eine hilfreiche Antwort. Die Hoffnung stirbt zuletzt.

Also, die Ausgangslage:
1) Ich beziehe mich der Einfachheit halber nur auf Relationen mit einfachem PK.
2) Damit so ein einfacher PK auch eindeutig sein kann, muss ja jedes Attribut in der Relation funktional von ihm abhängen. Richtig?
3) Attribute, die mit dem PK (PK : Attribut) eine 1 : n oder m : n Beziehung bilden, sind nicht funktional von ihm abhängig. Solche Attribute könnten ja meiner Meinung nach von überhaupt keinem anderen Attribut funktional abhängen, oder?

Meine Annahme:
Meiner Meinung nach wird die korrekte Vergabe des PK bzw. die funktionale Abhängigkeit aller Attribute der Relation von einem einfachen PK durch den Normalisierungsprozess mit 1., 2. und 3. NF NICHT gecheckt. Anders gesagt, eine Relation könnte mit einfachem "PK" formell in 3NF sein und trotzdem Attribute haben, die nicht vom "PK" funktional abhängig sind, wodurch dieser dann eigentlich doch kein PK ist weil doch nicht eindeutig -> ganze Relation ein Murks trotz 3NF.

Meine Frage:
Stimmt meine Annahme, oder ergibt sich die funktionale Abhängigkeit aller Attribute von einem einfachen PK durch den Normalisierungsprozess doch irgendwie?

Wenn ich recht habe, wieso ist dieser Check nicht Teil des Normalisierungsprozesses mit 1, 2 und 3NF? Ich hätte gedacht, der Normalisierungsprozess sollte ein Algorithmus / Rezept sein, an das man sich einfach halten kann und wodurch dann am Ende GESICHERT gescheite Relationen rauskommen. Wenn ich aber Recht habe, genügt der Normalisierungsprozess mit 1, 2 und 3NF (und BCNF 4 und 5) nicht, um dies SICHER zu stellen, sondern man muss dann noch SEPARAT davon an die richtige Vergabe des (einfachen) PKs und die funktionale Abhängigkeit aller Attribute von diesem denken, oder?

Vielen lieben Dank an alle Experten für hilfreiche Antworten.
LG
 
Werbung:
Ich werde durchs lesen nicht ganz schlau, liegt wohl an der Uhrzeit...

ein Primärschlüssel ist IMMER eindeutig.
Es gibt Primärschlüssel über EINE oder MEHRERE Spalten, wie ich ein Beispiel nenne:

Code: 
create table alpha(id serial primary key, name text);
create table beta(alpha integer references alpha(id), value integer, primary key (alpha, value));
insert into alpha(name) values ('Alf');
insert into beta(alpha, value) values (1, 1);

zwei tabellen erstellt mit einem foreign key... funktioniert einwandfrei, aber bei einer zweiten eingabe von:
Code: 
insert into beta(alpha, value) values (1, 1);

wirft das ganze einen Fehler, weil 1, 1 bereits vorhanden ist, wobei aber:
Code: 
insert into beta(alpha, value) values (1, 2);

funktioniert, weil die Kombination 1, 2 noch nicht vorhanden ist, sondern nur 1, 1.

eine spalte kann auch eindeutig gemacht werden mittels eines unique-constraints, damit der wert in einer anderen tabelle als foreign key eingebunden werden kann, ist aber weniger typisch.

Ein primary key deklariert eine spalte sozusagen "nur" als unique und not null...

dabei habe ich eine frage:
was meinst du mit funktional abhängig? (das, was mittels eines Foreign Keys gelöst wird? wie in meinem Beispiel oben alpha in der tabelle beta abhängig von der spalte id in der tabelle alpha gemacht wurde?)
 
Tja, das Ganze nennt sich ja Modell. Wir haben ein neues Hochhaus mit Modelcharakter für klimaneutrale Bautechnik. Wir haben eine Modelleisenbahn und noch so Zeug. Was ist nun ein Modell? Ist ein Modell perfekte Darstellung der Funktionalität in der Wirklichkeit oder ist es ein abstrahierendes, vereinfachendes Abbild der Wirklichkeit?
Hast Du ein Beispiel für Deine Frage?
Hier ist mal eins:
Person
Name, Vorname, Geschlecht, Straße, Hausnummer, PLZ, Ort.
Und ein PK dazu.

Ist das normalisiert? Nein, es gibt funktionale Abhängigkeiten in den Attributen. (Und ich meine nicht, dass eine Person mehrere Wohnsitze haben kann)
(Und die gibt es nur, weil die genannten Attribute in der Realität eine besondere Ausprägung haben, die der Attributname für sich als Vokabel nicht unbedingt verrät)
Gemein ist ja auch, das der technische PK immer für Eindeutigkeit sorgt, was vielleicht verwirrend ist. Er ist sozusagen brute force Eindeutigkeit. Das hat aber nichts mit Normalisierung zu tun, sondern ist Teil des Physischen DB Modells.

Funktionale Abhängigkeit innerhalb der Attribute ist nicht unbedingt SICHER zu bestimmen. Bzw. ist Normalisierung m.E. ein akademische Vorgehensweise, die von Verständnis und Semantik formulierter Bedarfe bzw. Sachverhalte abhängt.

Die sprachlichen Probleme, bzw. die Interpretation von fachlichen Anforderungen, die sich schon in meinen geklammerten Bemerkungen (gemeint ist .. /ist nicht ..)zeigen, bilden eine Hürde für die Normalisierung.

Achso, gutes Beispiel: Was meinst Du mit SICHER? Prüfungssicher oder sicher (genug) für ein praktisches Datenmodell?
 
Danke schon mal euch 2 für eure Mühe.

@Kampfgummibaerlie :
Ein echter PK ist immer eindeutig, aber wenn du ein Attribut in der Relation "übersiehst", zu dem das definierte PK-Attribut eine 1 : n-Beziehung hat, dann ist die Relation eben fehlerhaft, würde aber strikt nach 1, 2, 3NF vielleicht nicht auffallen, denke ich.

Mir geht es nicht um eine konkrete Implementierung in einem DMS sondern um die grundsätzliche Theorie der Normalformen bzw. was durch die Normalformen definiert wird und was nicht.

Mit funktionaler Abhängigkeit meine ich das, was hier: Funktionale Abhängigkeit – Wikipedia beschrieben ist.
Funktionale Abhängigkeit heißt also, dass es zu jedem Wert von Attribut A immer nur genau einen gültigen Wert von Attribut B geben kann. A bestimmt B funktional. Ich würde in meinen Worten auch sagen, aus A folgt immer automatisch genau B. Dies trifft laut Definition nur auf Attribute innerhalb einer Relation zu.

@dabadepdu :
Bzgl. deinem Bsp: Ich sehe zwischen den Nicht-PK-Attributen keine funktionalen Abhängigkeiten. Sogar, was du nicht meinst und erwähnst (dass eine Person mehrere Wohnsitze haben kann) ist ja keine funktionale Abhängigkeit in dem oben verlinkten Sinn.

Ein einfaches Beispiel für meine Fragestellung wäre:
Relation Rechnung = {_RechnNr_, ArtikelNr}

Also _RechnNr_ ist als PK definiert. Aber eine _RechnNr_ kann mehrere verschiedene ArtikelNr zugewiesen haben und eine ArtikelNr kann mehreren _RechnNr_ zugewiesen sein (bzw. in mehreren Rechnungen vorkommen). Es sollte zwar sofort auffallen, dass keines vom anderen funktional abhängt und die Relation daher auf 2 Relationen mit einer m : n-Beziehung (mit einer Hilfsrelation in der Mitte) aufgeteilt gehört. ABER theoretisch wäre eine solche (schlechte) Relation Rechnung (ohne Aufteilung) formell in 3NF, oder?

Ich denke, mit SICHER meine ich prüfungssicher, falls ich dich richtig verstanden habe.
 
Zuletzt bearbeitet:
Es gibt eine funktionale Abhängigkeit zwischen Ort und PLZ.

Was meinst Du mit "solche schlechte Relation .. ohne Aufteilung"?

Ich bin mir nicht ganz sicher, von welcher Ebene Du redest. Eine Hilfsrelation kommt m.E. erst mit der Umsetzung in ein physisches DB Modell ins Spiel. Du willst aber nur über Normalisierungstheorie sprechen. Eine Betrachtung von Rechnung und Artikel zur 3NF würde ja erst Sinn machen, wenn man über die Attribute spricht, die jeweils enthalten sind.
 
dabadepdu schrieb:
Es gibt eine funktionale Abhängigkeit zwischen Ort und PLZ.
Zum Vergrößern anklicken....
Ort u. PLZ: Nur theoretisch.
In der Realität (zumindest in Österreich) gibt es Orte mit mehreren PLZs und PLZs, die zu mehreren Orten gehören.

dabadepdu schrieb:
Was meinst Du mit "solche schlechte Relation .. ohne Aufteilung"?
Zum Vergrößern anklicken....
Mamma mia! Damit meine ich die Relation bzw. das Relationenschema wie im Beispiel angeschrieben.

dabadepdu schrieb:
Ich bin mir nicht ganz sicher, von welcher Ebene Du redest. Eine Hilfsrelation kommt m.E. erst mit der Umsetzung in ein physisches DB Modell ins Spiel. Du willst aber nur über Normalisierungstheorie sprechen. Eine Betrachtung von Rechnung und Artikel zur 3NF würde ja erst Sinn machen, wenn man über die Attribute spricht, die jeweils enthalten sind.
Zum Vergrößern anklicken....
Mamma mia²! Das mit der Hilfsrelation war nur zur Erklärung der Verhältnisse. Und ich habe auch über die Attribute gesprochen.
Ich hab die Kernfrage am Ende extra fett hervorgehoben. Wenn du sie nicht beantworten kannst oder willst, auch gut. Darf mir nix ausmachen. Danke für deine Zeit soweit. LG
 
Werbung:
Ich glaube ich bin inzwischen selbst drauf gekommen.

Ich dachte bisher, dass die 2NF nicht auf Relationen mit nur einem einfachen PK zutrifft (also, dass sie nur auf Relationen angewandt wird, die einen zusammengesetzten PK haben). Deshalb schrieb ich auch gleich von der 3NF.

Dies dürfte aber ein Irrtum gewesen sein, da dies (1) in der Fachliteratur, die ich nun nochmals studierte anscheinend eigentlich gar nicht behauptet wird und (2) auch zB hier: Zweite Normalform: Attribute sind voll funktional vom Primärschlüssel abhängig zumindest indirekt bestätigt wird.

Damit wird die funktionale Abhängigkeit aller Attribute vom PK (auch bei einem einfachen PK) anscheinend eh vom Normalisierungsprozess gecheckt, nämlich durch diese 2NF. Hoffe, das stimmt.

Danke nochmals euch 2 für eure Unterstützung.
 
Zurück
Oben