Zusammengesetzer Primärschlüssel oder nicht

Ich Idiot! Tut mir leid. Als Erkennungsmerkmal dient noch zusätzlich eine Kundenkennung. Das hätte ich dir gleich sagen können.

id(autoincrement)|Version|id_vn|Titel
1|1|1|Bausparvertrag
2|2|2|Bausparvertrag
3|3|3|Bausparvertrag
4|1|4|Bausparvertrag
5|2|1|Bausparvertrag
6|3|1|Bausparvertrag
7|4|1|Bausparvertrag

Somit kann die Zugehörigkeit der Verträge zu dem Kunden ermittelt und daraus die letzte Vertragsversion erkannt werden.


Noch einmal zu deiner Aussage PK, ist eher ein "Sparmodell", um mehr Spalten zu vermeiden. Wie meinst du das?
 
Werbung:
Und wenn ein Kunde zwei Bausparverträge hat?

Noch einmal zu deiner Aussage PK, ist eher ein "Sparmodell", um mehr Spalten zu vermeiden. Wie meinst du das?
Beim Normalisieren (frag mich jetzt nicht welche Form) wird viel Wert auf die Vermeidung von Redundanzen gelegt. Hast du ein eindeutiges Atribut oder mehrere die zusammengesetzt eindeutig sind definiert man diese als Schlüssel. Ein zusätzlicher, künstlicher Schlüssel würde gegen die Normalform verstoßen und mehr Platz für die Tabelle beanspruchen.

Eine normalisierte Datenbankstruktur ist immer erstrebenswert, i.d.R. vermeidet sie Probleme. Platz (und zu einem geringen Teil auch Geschwindigkeit) ist aber heute nicht mehr so problematisch wie vieleicht vor 15 Jahren so das ich einen zusätzlichen, künstlichen Schlüssel (eine ID ist ja genau das) der von keinem Anwender verändert werden kann immer einem Schlüssel wie der Vertragsnummer (die in der Außendarstellung den Vertrag vieleicht eindeutig identifiziert) vorziehen würde.
 
Und wenn ein Kunde zwei Bausparverträge hat?

Ich glaube ich habe dich falsch verstanden. Die Unterscheidung der Verträge nimmt der Anwender vor. Es gibt noch einen wesentlich Teil, den ich bisher noch nicht erwähnt hatte. Die Versionen beziehen sich auf die Zusammenfassung aller bisher eingegebenen Verträge.

Vertragszusammenfassung Version 1 -> beinhaltet z.B. 9 Verträge
Anwender klickt auf "Neue Version erzeugen
Vertragszusammenfassung Version 2 -> beinhaltet die og. 9 Verträge. Anwender gibt 4 neue Verträge ein (4 neue werden von Beginn an mit Version 2 gespeichert) = 13 Verträge mit Version 2

Er sieht in der Vertragsmaske die unterschiedlichen Verträge und kann diese anhand der Gesellschaft, Beitrag, Leistung, Vertragsnummer etc. auseinanderhalten. Zuvor muss er aber eine Version auswählen, damit die Verträge in der Zusammenfassung überhaupt erscheinen. Sobald er dann eine Version ausgewählt hat lädt das Programm ALLE Verträge in der zuvor vom Anwender bestimmten Version.

Wenn der Anwender einen Vertrag ausgewählt hat und diesen ändert, bleibt die id gleich. Gibt der Anwender eine neue Version an werden alle Verträge in der bisherigen Version dubliziert, eine neue id inkl. neue Version für alle neuen Verträge innerhalb der Zusammenfassung vergeben. Gibt der Anwender einen neuen Vertrag ein wird ebenfalls eine neue id vergeben inkl. mit der bereits vorher ausgewählten Version.

Also vom Programm aus gesehen, sieht der Anwender alle Verträge in der jeweiligen Version und kann diese anhand der Beschriftung unterscheiden. Hat der Kunde einen zweiten Vertrag hat dieser eine andere id als der erste, aber die gleiche Versionskennung.

Aus Datenbanktechnischer Sicht ist nicht eindeutig ersichtlich welcher Vertrag in welcher Version vorliegt, da die id einfach aufsteigend vergeben werden und die Versionen auch veränderbar sind. Somit ist es ein Verst0ß gegen die Normalisierung, richtig?
 
Da muss ich passen, das wird mir doch etwas zu kompliziert. Deine Anwendung scheint ja zu funktionieren und die Verträge auseinanderhalten zu können, also ist diese Diskussion eher konzeptionell. Ich z.B. würde auch nie 9 Verträge duplizieren nur weil einer hinzu kommt. Genauso würde ich aber auch kein laufendes System deswegen umbauen...

PS: Aber natürlich, das verstößt so ziemlich gegen jede Normalform. Menschen werden dadurch aber wohl nicht sterben, auch wird deine DB vermutlich keine signifikanten Probleme damit haben.
 
Danke aber trotzdem, dass du dich der Sache angenommen hast. Ich denke da sieht man wieder Theorie und Praxis. Ich hab es halt hinbekommen auch wenn ich gegen die Normalisierungen verstoße.

Nur zum Verständnis. Ich verstoße gegen die 2. Normalisierungsform, da der Datensatz nicht eindeutig Identifizierbar ist. Zwar werden unterschiedliche IDs verwendet, aber um einen Vertrag zu identifizieren müsste bei gleichen Verträgen zumindest die gleiche ID vorliegen.

Und deshalb müsste die Versionskennung inkl. ID zusammengesetzt sein, oder?

Gruß
 
Werbung:
Zurück
Oben