Verstoß gegen welche Normalform?

[exzel]

Hallo zusammen,

ich habe eine Frage zu folgendem Tabellenaufbau. Ich weiß, dass dieser so nicht mehr praxisgemäß ist. Es handelt sich um eine reine Verständnisfrage.

Tabelle Kunde hat folgenden Aufbau.

Kundennr. Name Vorname Straße Hausnr. PLZ Einkunftsart
Mit den Einkunftsarten meine ich folgende
http://de.wikipedia.org/wiki/Einkunftsart_(Deutschland)

Gibt es dann noch einen Verstoß und wenn ja, gegen welche Normalform wird verst0ßen?

Gruß und Dank!

 

[ukulele]

Das kommt darauf an: Wenn du z.B. mehrere Personen mit der selben Adresse hast musst du die Adresse in einer eigenen Tabelle führen. (Mit Ort wird das ja scheinbar schon gemacht).

 

[exzel]

Hallo und danke für die Antwort,

ok, also das mit den Adressen leuchtet ein. Abgesehen davon. Was ist mit den Einkunftsarten, wenn eine Person mehrere Einkunftsarten haben kann? Gegen welche Normalform würde dann der Aufbau verstoßen?

 

[exzel]

Hallo!

Ich glaube, ich weiß die Antwort. Es ist der Verstoß gegen die 2. Normalform.

Denn es muss ein jedes Nichtschlüsselattribut vollständig vom Primärschlüssel abhängig sein. Hier ist das Nichtschlüsselattribut Einkunftsart nicht vom Primärschlüssel Kundennr. abhängig, was ein Verstoß darstellt.

Richtig?

 

[ukulele]

Stimmt, das habe ich nicht bedacht. Die Einkunftsarten müssen natürlich in einer eigenen Tabelle stehen und solange du nicht nur Nummern für die Einkunftsarten vergibst brauchst du eine Zwischentabelle, damit nicht zich mal Einkünfte aus nichtselbstständiger Arbeit da steht, das wäre redundant.

 

[exzel]

Hallo nochmal,
ich bin da ein kleiner Erbenzähler, entschuldigt bitte. Aber ich habe nochmal bei Wikipedia nachgelesen. Es heißt dort: "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."

Also ist auch die Tabelle mit der Spalte Einkunftsart in der zweiten Normalform. Es liegt also kein Verstoß gegen die zweite Normalform vor. Gegen welche dann?

Gruß

 

[Tommi]

Hallo exzel,

eine Verletzung er 2.NF liegt in diesem Falle sehr wohl vor. Du musst nicht nur den bereits vergebenen Primary-Key betrachten,
sondern auch die durch die Inhalte gegebenen funktionalen Zusammenhänge.
Dann ergibt sich nämlich durch eine inhaltliche Änderung in nur einer Spalte, dass diese zu einem Schlüsselkandidaten wird. Ansonsten wäre hier bereits die 1.NF verletzt, da nach der Definition dieser ein Datensatz eindeutig Identifizierbar sein muss.
Dadurch hat die Tabelle einen theoretisch zusammengesetzten Primär-Schlüssel (Spalten Kundennr und Einkunftsart), da der Datensatz ansonsten nicht eindeutig identifiziert werden kann.

Die Inhalte der anderen Spalten liegen dann nämlich redundant vor, was es ja zu vermeiden gilt.

Viele Grüße,
Tommi

 

[exzel]

Hallo und danke für die Antwort!

Da habe ich was undeutlich ausgedrückt. Es kann pro Kunde mehrere Einkunftsarten geben. Gilt dann noch, deine Erklärung?

Dadurch hat die Tabelle einen theoretisch zusammengesetzten Primär-Schlüssel (Spalten Kundennr und Einkunftsart), da der Datensatz ansonsten nicht eindeutig identifiziert werden kann.
Tommi

Dann kann Kundennr und Einkunftsart kein zusammengesetzter Primärschlüssel sein, oder?

Gruß

 

[Tommi]

Hallo exzel,

genau dann gilt meine Erklärung. Das verletzt die 1.NF.
Versuch mal einen Eintrag mit doppeltem Primär-Schlüssel in eine Tabelle auf einer Datenbank zu schreiben. Das System wird dir diesen Versuch um die Ohren hauen.
Es darf keinen doppelten Primärschlüssel in einer Tabelle geben. Genau das würde aber passieren, wenn du mit dem Primärschlüssel Kundennr einen zweiten Eintrag erzeugen wolltest,
in dem sich lediglich ein Feld außerhalb des Primärschlüssels unterscheidet, wie z.B. die Einkunftsart.
Daher muss, um eine eindeutige Unterscheidung eines Datensatzes nach 1.NF die Einkunftsart mit zum Primärschlüssel gehören (-> zusammengesetzter Primär-Schlüssel).

Viele Grüße,
Tommi

 

[exzel]

Hallo Tommi,

vielen Dank für deine Geduld und deine Erläuterung. Jetzt habe ich das auch endlich verstanden.

Gruß

 

[MarkO]

Hallo zusammen,

ich hab auch mal ne Frage dazu (ich hoffe es ist in Ordnung, wenn ich meine Frage hier dranhänge?):

Ich hab eine Tabelle MITARBEITER mit folgenden Feldern gegeben:

Pers.Nr, Vorname, Nachname, Geburtstdatum, STATUS

Bei Status können nun folgende Werte eingetragen werden. Arbeiter, Angestellter, Führungskraft, Meister. Müssen dann diese Werte auch in eine separate Tabelle ausgelagert werden? ==> Ich denke schon, da die Daten ansonsten redundant wären (ENTSPRICHT DANN NICHT DER 2. NORMALFORM?)

Wie ist es dann z.B. mit dem Geschlecht?:
PersNr, Vorname, Nachname, Geburtstaum, GESCHLECHT

Müsste dann nicht auch theoretisch das Geschlecht in eine eigene Tabelle ausgelagert werden???

Die Tabelle hat jetzt keinen praktischen Sinn, ich hab nur den Thread hier gelesen und mir auch meine Gedanken dazu gemacht

Danke!

Viele Grüße!

 

[ukulele]

Theoretisch ja, denn sobald deine Information sich in einer Spalte wiederholt ist sie ja redundant vorhanden und deine Tabelle kann eigentlich per Fremdschlüssel darauf verweisen. Das macht aber in der Praxis nur Sinn, wenn du damit auch Platz sparst und deine verlängerte Abfragezeit für die Informationen nicht die Nachteile von mehr Speicherplatz aufwiegt.

Du könntest auch in einem Modell mit 4x Klaus, 5x Hans und 3x Michael als Vorname anfangen, diese Information Vorname in eine eigene Tabelle ausgliedern. Das wird nur immer sinnloser, je seltener Redundanzen auftreten.

 

[Tommi]

Hi,

zunächst: Beim lesen des Beitrags von ukulele müsste ich mal massiv grinsen - toll aufgebläht .
Aber im Grunde ist die Antwort vollkommen richtig. ukulele beschreibt aber hier ein Modell der 4. bzw. der 5. NF, was in der Praxis im Regelfall nicht eingesetzt wird.
(Ich nehme CRM-Systeme oder Spezialfälle hier mal raus).

Man sollte aber ja nicht vergessen, dass wir hier von Modellen sprechen. Diese sind natürlich erst einmal rein theoretischer Natur.

Ob dein Beispiel der Mitarbeitertabelle tatsächlich die 2.NF verletzt hängt von der funktionalen Betrachtung ab.
Bei deinem Beispiel ist es ja in der Regel so, dass ein Mitarbeiter (wobei ich davon ausgehe, dass die PersNr der PKEY ist) immer nur einen Status annehmen kann.
Es gibt vom Mitarbeiter zum Status also eine definierte 1:1-Beziehung. Ich sehe hier eigentlich keine direkte Verletzung der 2.NF, da der Status aufgrund der 1:1-Beziehung direkt vom PKEY abhängt.

Wenn es jedoch so ist, dass ein Mitarbeiter mit der gleichen Personalnummer verschiedene Stati gleichzeitig annehmen kann, dann werden aufgrund der nun vorliegenden 1:n-Beziehung
zwischen PersNr und Status diese beiden Felder zu Schlüsselkandidaten, da nur über diese beiden Informationen ein Datensatz eindeutig identifiziert werden kann.
Ohne einen zusammengesetzten PKEY würde die Tabelle also bereits die 1.NF verletzen!

Mit diesem zusammengesetzten Primärschlüssel würden dann die Spalten Vorname, Nachname und Geburtsdatum die 2.NF verletzen, da diese nicht eindeutig vom gesamten PKEY abhängen.
Diese Daten würden dann redundant vorliegen. Wenn sich dann z.B. bei einer Frau der Nachname ändert, könnte die Tabelle inkonsistent werden, wenn bei der Ersetzung nicht für jeder PersNr dieser Name entsprechend mit berücksichtigt wird (wir sprechen hier von der Möglichkeit, dass dieser Fall eintreten kann.)

Damit die zweite 2.NF in diesem Falle nicht verletzt wird, muss der zusammengesetzte PKEY aufgelöst werden.

Bei der Angabe des Geschlechts ist es ja so, dass diese in der Regel nicht umbenannt wird und je Personalnummer entsprechend eindeutig ist. Außerdem gibt es für die Angabe des Geschlechts ja nun auch nicht grade unendlich viele Möglichkeiten
Hier gehen viele nur deshab auf eine Referenztabelle über, um unterschiedliche Schreibweisen zu vermeiden. Andere Möglichkeit sind natürlich definierte Kürzel mit nur einem Buchstaben.
Dies kann man aber bereits in der Datenbank mit einer Eintragsüberprüfung für das Feld festlegen, dazu benötigt man nicht zwingend eine Referenz. Man muss dies also im Modell nicht berücksichtigen.

Viele Grüße,
Tommi