Normalisierungsformen

[kszysiu]

hey Leute,

kann mir mal einer erklären, wie die 1 Normalform funktioniert ? 2te und dritte sind kein Problem aber warum hat die 1 Normalform denn 2 Primärschlüssel ? Und nach welchen kriterien werden sie bestimmt.

Donge sagt ein baldiger Prüfling !

[Crush]

Zwei Primärschlüssel ergeben 1.) einmal eine genauere Eindeutigkeit auf einen Eintrag und 2.) läßt sich dann alles schneller "hashen" (falls Dir das was sagt). Man kann so schneller durch Hash-Keys die Positionen von Einträgen in Abhängigkeit der Tabellen ermitteln. Zum Thema Hashing am Besten mal in irgendein C/C++-Buch reinschauen oder im Internet nachschlagen. Ist eine rein Verwaltungstechnische Sache. Arbeitet man mit nur einem Key und einer Tabelle undefinierter Größe gibt es wesentlich mehr Kollisionen und so müssen intensivere, ausgeklügelte und langwierige Kollisionsbehandlungen erfolgen, bei denen freie Eintragspositionen beim Einfügen von Einträgen und genauso beim Heraussuchen von diesen, ermittelt werden müssen. Der Einsatz von 2 Primary-Keys ermöglicht eine genauere Hash-Bestimmung und somit können Kollisionen minimiert werden und Zugriffe beschleunigt. (Hoffentlich hast Du das verstanden, worum es geht - dazu sollte man schon ein wenig mehr Ahnung vom Programmieren haben). Mehr Primary Key = erhöhte Eindeutigkeit

<FONT COLOR="#a62a2a" SIZE="1">[ 10. Oktober 2001 23:58: Beitrag 1 mal editiert, zuletzt von Crush ]</font>

[izofoizbouztoukzrtu6kzcro]

Zwei Primärschlüssel ????? Mehr Primary KeY = Mehr Eindeutigkeit ??? Naja, ich hab das aber anders gelernt :

Es gibt pro Tabelle nur EINEN PRIMARSCHLÜSSEL (und u.u. mehrere Fremdschlüssel)!

2. Normalform :

Heisst,das alle Datenfelder in der Tabelle xy von dem einen primary key der Tabelle abhängig sein müssen, wenn nicht müssen sie ausgelagert werden. Fazit : 1 Pirmary Key prot

Tabelle, oder ?????

Naja, und die erste Normalform hat ja vorerst (soweit ich weiss) nix mit den Schlüsseln zu tuen... es geht nur darum :

Wenn Du eine Tabelle Kunden hast, und bei deinem Entwurf das Attribut "Kundenname" (z.B. Hans Meier, so ist dieses Feld nicht atomar, das heisst, du musst die Attribute Vorname und Name erstellen. Dann hast Du im Bezug auf diese Tabelle (bzw. auf Kundenname) die 1. Normalform realisiert.

Richtig oder falsch ?

:confused:

[Crush]

Die Fremdschlüssel sind ja nur Primary-Keys von anderen Tabellen. Ich habe auch gedacht, ein PK wäre genug und mehr geht nicht, bis mir das mal einer gezeigt hat, daß man sehr wohl 2 Primary-Keys definieren kann. Er meinte auch, daß es Fälle gibt, in denen man das sogar tun MUß! Ich bin eigentlich nicht der Fachmann für sowas, aber aus der Sicht der Hash-Keys verstehe ich, daß mehr PKs u.U. notwendig sind, bzw. Abfragen beschleunigen können. Das mit der Normalform könnte stimmen. Erst muß man alles "sinnvoll" in Felder unterteilen, bevor man irgendwelche Keys und Verknüpfungen verteilt. Das zweite war glaub das Redundanz ausgeschlossen werden soll, indem man gleiche Inhalte in eigenen Tabellen zusammenfaßt. Dann erst kamen die Keys und was das 4. war, keine Ahnung, war aber nix dramatisches, soweit ich weiß. Das mit den 2 Primärschlüssel darf man aber auch nicht so sehen, daß 2 einzelne PKs da sind: Die PKs ergeben wenn ich mich recht erinnere zusammen den Primärschlüssel - KEINE FREMDSCHLÜSSEL. Die Fremdschlüssel werden benötigt um Übereinstimmungen in Tabelleninhalten gleichzeitig zu selektieren. Es war allerdings auch nicht sehr einfach den zweiten PK zu definieren (man mußte an den Eigenschaften viel rumschrauben).

[Althea.Vestrit]

Hallo,

ich wollte das noch mal verdeutlichen mit dem zusammengesetzten Primay Key.

Wenn du zum Beispiel eine Tabelle hast mit den Felder Nachname, Vorname ... dann ist es nicht sehr sinnvoll nur auf das Feld Nachname den PK zu setzen, daß es ja z. B. mehrere "Schmitt" oder "Meier" gibt. Nimmt man aber das Feld Vorname noch hinzu, so wird es schon eindeutiger. Wenn man dann z. B. das Geburtsdatum noch hinzunimmt, dürfte sich die gleiche Kombination sehr wahrscheinlich nicht mehr wieder holen.

So mit haben wir also ein PK der sich aus den Feldern Name, Vorname und Geburtsdatum zusammensetzt.

Ich hoffe ich habe jetzt nicht alle verwirrt.

Althea

[Crush]

Gutes Beispiel.

[izofoizbouztoukzrtu6kzcro]

Warum sollte ich das tun ? Ich kann doch z.B. die Kunden_ID einpflegen und als Primary Key benutzen ! Oder?

[BlearSun]

TAg,

Also im "Normalfall" sollte es in einer Tabelle nur ein eindeutiges Feld (Primärschlüssel) geben, sprich ID-Field, DAS ID-Field macht den Datensatz in der gesamten Datenbank eindeutig. wenn man die GUIDs nimmt, dann sogar Weltweit. Und wenn ich dann z. B. zwei mal in einer Tabelle "Micheal" als Vorname habe, dann darf ich eigentlich nicht die Felder Nachname, Vorname, und z. B. GDatum als Eindeutigkeitskriterien verwenden und nutzen, was durchaus möglich ist. in so einem Fall verwendet man einen Matchcode-Field und dieses Field ist in der Tabelle eindeutig. Hat aber mit ID_Field nichts zutun.

Als Beispiel:

Adressentabelle

ID_ADR --> Primärschlüssel - Eindeutig in der Datenbank

MC_ADR --> Matchcode -Eindeutig in der Tabelle

Vorname

Nachname

und so können auch 10x Micheal Müller erfasst werden mit verschienden MCs natürlich! und auch wenn Micheal Müller aus Hamburg und Micheal Müller aus Nürnberg an einem Tag geburtstag haben (was zwar nicht sein kann, jedoch nicht auszuschließen ist ) tut es uns nicht weh.

Meine Meinung nach ist es immer problematisch mehrere Felder als Eindeutigkeitskriterien zu verwenden.

Gruss

Blear