Normalisierung bei folgender Tabelle

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

Hallo zusammen,

bin noch bluter Anfänger bei mysql und benötige Hilfe. Wie muss folgende Tabelle normalisiert werden?

Soweit ich das verstanden habe müssen alle Daten atomar sein, was ja auch der Fall ist.

Aber bei den nächsten zwei Normalisierungsformen bin ich mir nicht mehr sicher.

Jedes Nichtschlüsselattribut muss vollständig vom Primärschlüssel (id_kunde u. id_betreuer) abhängig sein. Und jedes Nichtschlüsselattribut darf von keinem Schlüsselkandidaten transistiv abhängig sein.

Ich vermute mal, dass Ort transistiv von id_vn abhängig ist. Richtig?

id_kunde
id_betreuer
name
vorname
gebdatum
familienstand
beruf
telprivat
telmobil
email
telgesch
arbeitgeber
sozversnr
plz
ort

Vielen Dank!

#2

Moin, Alex,

die Darstellung weckt so viele Zweifel, dass sich keine Antwort geben lässt.

  • Was ist Schlüssel?
  • vn_id fällt vom Himmel. Gibt es eine weitere Tabelle?

Vorschlag zur Darstellung:

**Tablename** (<u>Key-Attr1, ...</u>, Attr1, Attr2, ..., FS\_Attr1, FS\_Attr2)

Gruß Ralf

#3

Hallo und danke für die Rückmeldung.

Der Schlüssel ist id_betreuer und id_vn. id_betreuer ist fest vorgegeben und iv_vn wird per autoincrement vergeben. Eine weitere Tabelle existiert nicht.

Hab’ das jetzt mit der Darstellung nicht so hinbekommen wie du, aber es handelt sich durchweg um Spaltennamen.

Hoffe das hilft.

Gruß

#5

Hallo und sorry,

natürlich sollte id_vn id_kunde heißen. Der Schlüssel id_kunde identifiziert den Kunden.

Wenn nun dieser Betreuer kündigt, werden die Kunden umgeschlüsselt. Aber nicht unbedingt alle auf einen anderen Betreuer, sondern evtl. auf mehrere. Oder wolltest du mit deiner Frage auf eine zusätzliche Tabelle hinweisen, die mit der Kundentabelle verknüpft ist?

Gruß

#6

Hi Alex,

Wenn nun dieser Betreuer kündigt, werden die Kunden
umgeschlüsselt.

keine gute Idee: Was mal eine Identität hat, behält die bis zum Tod. Ein harter, aber sehr sinnvoller Grundsatz.

wolltest du mit deiner Frage auf eine zusätzliche Tabelle
hinweisen, die mit der Kundentabelle verknüpft ist?

So ist es. Im ersten Hieb sollte das so aussehen:

**Betreuer** (<u>Betreuer</u>, FS\_Personalnr, ...) 
**Kunde** (<u>Kunde</u>, Name, Geburtsdatum, SV-Nr, ...)
**Betreuung** (<u>Betreuung</u>, FS\_Kunde, FS\_Betreuer, ...)

Diese Lösung hat den Vorteil, dass der Betreuer wechseln kann, ohne dass sich Schlüssel ändern. Stell Dir vor, an der Betreuung hängen noch Vorgänge - bevor Du „Nein!“ sagen kannst, änderst Du die Schlüssel in der halben Datenbank.

Abgesehen davon: Das Objekt Betreuung sehe ich sehr kritisch. Wozu soll das fachlich dienen? Wer wen betreut, ließe sich auch aus den Vorgängen eruieren, wenn dort der Betreuer als FS vermerkt wird.

Gruß Ralf

#7

Danke für die Antwort,

da hab’ ich noch Fragen.

Wie unterscheidest du nun Betreuung und Betreuer? Was meinst du damit? Und was meinst du mit FS?

Betreuer (Betreuer, FS_Personalnr, …)
Kunde (Kunde, Name, Geburtsdatum, SV-Nr, …)
Betreuung (Betreuung, FS_Kunde, FS_Betreuer, …)

Diese Lösung hat den Vorteil, dass der Betreuer wechseln kann,
ohne dass sich Schlüssel ändern. Stell Dir vor, an der
Betreuung hängen noch Vorgänge - bevor Du „Nein!“ sagen
kannst, änderst Du die Schlüssel in der halben Datenbank.

Abgesehen davon: Das Objekt Betreuung sehe ich sehr kritisch.
Wozu soll das fachlich dienen? Wer wen betreut, ließe sich
auch aus den Vorgängen eruieren, wenn dort der Betreuer als FS
vermerkt wird.

Wie meinst du aus dem Zusammenhang eruieren?

Gruß

#8

Hi Alex,

wir müssen wohl einen Schritt vorher aufsetzen: Warum hat das Ursprungsobjekt den Betreuer und den Kunden im Schlüssel? Und wie soll das Objekt heißen?

FS heißt Fremdschlüssel und macht eine Beziehung augenfällig.

Wie meinst du aus dem Zusammenhang eruieren?

Nicht aus dem Zusammenhang, sondern aus der Tabelle Vorgang , die demnächst hier auftreten wird :smile:

Gruß Ralf

#9

wir müssen wohl einen Schritt vorher aufsetzen: Warum hat das
Ursprungsobjekt den Betreuer und den Kunden im Schlüssel? Und
wie soll das Objekt heißen?

Das Objekt (die Tabelle) soll Kunden heißen und hat deshalb den Betreuer und den Kunden intus, da ich von Datenbankmodellierung keine Ahnung habe.

Ich glaube das mein Ansatz gegen die zweite Normalform verstößt, da die id_kunde alleine schon genügt, um alle Nichtschlüsselattribute zu identifzieren. Und id_kunde ist dann ein Teil des Schlüsselkandidaten id_betreuer und id_kunde.

Deshalb muss die Tabelle Kunden auf den Schlüsselkandidaten id_kunde reduziert werden und eine Tabelle Betreuer mit der id_betreuer als Primärschlüssel erstellt werden, die mit der Tabelle Kunden verknüpft ist. Die Tabelle Betreuer hat die als zweite Spalte die id_kunde, damit die Beziehung von id_betreuer und id_kunde ersichtlich ist.

Oder? Wenn es wieder falsch ist: TROTZDEM HERZLICHEN DANK FÜR DEINE GROßE GEDULD

#10

Deshalb muss die Tabelle Kunden auf den Schlüsselkandidaten
id_kunde reduziert werden und eine Tabelle Betreuer mit der
id_betreuer als Primärschlüssel erstellt werden, die mit der
Tabelle Kunden verknüpft ist.

so muss es sein.

Die Tabelle Betreuer hat die als
zweite Spalte die id_kunde, damit die Beziehung von
id_betreuer und id_kunde ersichtlich ist.

Das darf nicht sein, das Wesen der Beziehung ist wohl noch nicht ganz klar.

Ein Betreuer betreut viele Kunden, richtig? Dann muss in Kunde ein Feld FS_Betreuer vorhanden sein, das auf den Betreuer zeigt. Nur so kann der Betreuer bei beliebig vielen Kunden eingetragen werden.

Gruß Ralf

#11

Die Tabelle Betreuer hat die als
zweite Spalte die id_kunde, damit die Beziehung von
id_betreuer und id_kunde ersichtlich ist.

Das darf nicht sein, das Wesen der Beziehung ist wohl noch
nicht ganz klar.

Ein Betreuer betreut viele Kunden, richtig? Dann muss in Kunde
ein Feld FS_Betreuer vorhanden sein, das auf den Betreuer
zeigt. Nur so kann der Betreuer bei beliebig vielen Kunden
eingetragen werden.

Tabelle: Kunden

id\_kunde | name\_kunde | vorname\_kunde
1 | meier | hans
2 | huber | fred
3 | steiger | alfons

Tabelle: Betreuer

id\_betreuer | name | id\_kunde
1 | großer | 1
1 | großer | 2
1 | großer | 3

Das wäre mein ursprünglicher Vorschlag gewesen. Problem: Redundanz. Pro Kunde müsste eine neue Zeile in der Tabelle Betreuer angelegt werden.

Tabelle: Kunden

id\_kunde | name\_kunde | vorname\_kunde | fs\_betreuer
1 | meier | hans | 1
2 | huber | fred | 1
3 | steiger | alfons | 1

Tabelle: Betreuer

id\_betreuer | name
1 | großer
2 | kleiner
3 | mittler

So sollte das Problem gelöst sein. Da wäre noch eine Frage (wenn mein Beitrag bis jetzt stimmt). Gegen welche Normalisierungsform verstößt mein ursprünglicher Vorschlag? Gegen die dritte Normalisierungsform evtl.?

Danke!

#12

Finster hier auf Sohle 11, langsam krieg ich Schiss.

Gegen welche Normalisierungsform verstößt mein ursprünglicher
Vorschlag? Gegen die dritte Normalisierungsform evtl.?

Gegen keine, der Fehler liegt noch weiter vorn.

Zwischen Betreuer und Kunde besteht eine 1:n-Beziehung:

 Betreuer \> Kunde

Dein erster Entwurf würde gleichzeitig die Beziehung

 Betreuer Kunde

abbilden. Das wäre dann de facto eine m:n-Beziehung, die fachlich aber falsch wäre, weil ein Kunde nur einen Betreuer haben darf.

Gruß Ralf

#13

Danke!
Ich kann dir gar nicht genug für deine Geduld danken!
Hast mir jede Menge Zeit und Geld gespart!

Gruß

Alex