5
Foreign Key - Redundanzfrei?
Hallo,
ich beschäftige mich zur Zeit mit dem Thema Datenbanken (relationelle) und SQL.
Laut der dritten Normalform soll eine Datenbank vollständig redundanzfrei sein, sprich Daten werden sinnvoll aufgeteilt usw.
Nun kann man ja per SQL den Foreign Key nutzen, um z.b. automatische Updatefunktionen zu nutzen und um Tabellen miteinander zu Verknüpfen.
Jetzt will ich wissen, ob durch diesen Foreign Key die Datenbank dennoch redundanzfrei, d.h. in der dritten Normalform bleibt. Ich habe bereits mehrere Internetseiten studiert, aber ich finde dazu keine Lösung.
Gruß
VB-NET
ich beschäftige mich zur Zeit mit dem Thema Datenbanken (relationelle) und SQL.
Laut der dritten Normalform soll eine Datenbank vollständig redundanzfrei sein, sprich Daten werden sinnvoll aufgeteilt usw.
Nun kann man ja per SQL den Foreign Key nutzen, um z.b. automatische Updatefunktionen zu nutzen und um Tabellen miteinander zu Verknüpfen.
Foreign Key ("Feldname") references TABLE("Feldname")); Jetzt will ich wissen, ob durch diesen Foreign Key die Datenbank dennoch redundanzfrei, d.h. in der dritten Normalform bleibt. Ich habe bereits mehrere Internetseiten studiert, aber ich finde dazu keine Lösung.
Gruß
VB-NET
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 127657
Url: https://administrator.de/contentid/127657
Ausgedruckt am: 25.11.2024 um 21:11 Uhr
5 Kommentare
Neuester Kommentar
Laut der dritten Normalform soll eine Datenbank vollständig redundanzfrei sein
Und an diesem Punkt musst du eine Entscheidung treffen:
- Willst du an die Uni?
- Oder willst du in der Praxis Lösungen programmieren, die echten Anforderungen standhalten?
Sorry, aber Normalformen hin und her: Die Praxis sieht oft anders aus und da geht es nur um eins: Was ist billiger - Speicher oder Prozessorleistung?
Jetzt will ich wissen, ob durch diesen Foreign Key die Datenbank dennoch redundanzfrei, d.h. in der dritten Normalform bleibt.
Eben dafür ist es ja gedacht.
Stell dir vor du hast eine Tabelle:
Musiker
-------
id (primary key)
name (varchar)Jetzt kannst du dir eine zweite Tabelle machen:
Titel
-------
id (primary key)
musiker_id (foreign key)
titelname (varchar)
...In diesem Moment hast du Speicher gespart und die Performance erhöht.
Denn
a) Braucht das speichern einer Zahl weniger Speicher als das eines Texts
b) Ist das Suchen nach einer Zahl schneller als ein Text
c) Läufst du so weniger Gefahr in Probleme wie ""Bernd Horstmann" oder "Horstmann, Bernd" - wonach suche ich?" zu laufen.
Dazu kommt je nach verwendetem RDBMS der Vorteil der "referentiellen Integrität" - praktisch bedeutet das: Löschst du einen Musiker aus der Tabelle Musiker verschwinden auch gleich alle seine Tracks mit.
Grüße
Max
Zum Schluss sei noch ein gegenbeispiel gegeben:
Würdest du deine Datenbank anlegen als:
Titel
----------
id (primary key)
musiker (varchar 255)
titel (varchar)wäre sie redundant.
Denn legst du z.B. 10 Lieder von "Mobby Dick" an verbrauchst du 10*255 Byte speicher.
Mit einer vernünftigen Relation und einem foreign key könntest du das aber aif 10*4 Byte reduzieren (du siehst den Unterschied?)
Und noch ein Beispiel wie man es zu weit treiben kann:
Natürlich haben viele Musiker auch viele Lieder mit gleichem Namen, folglich wäre auch folgende Datenbank möglich (wenn man das Konzept der Normalformen bis zum Ende bringen will):
Musiker
---------
id (primary key)
musiker (varchar 255)
Titelnamen
----------
id (primary key)
titelname (varchar 255)
Titel
---------
id (primary_key)
musiker_id (foreign_key)
titelname_id (foreign_key)Und wenn du das in Erwägung ziehst dann hast du dich ganz oben für ersteres entschieden
Hallo,
wo hast du denn deine Definition der 3NF her? An der Stelle, an der sie steht sollte dann auch genauer definiert sein, was sie unter "Redundanzfreiheit" versteht... Das es keine zwei Zeilen geben darf, in der (ein Teil oder alle) Attribute den gleichen Wert besitzen kann ja wohl kaum gemeint sein, das würde ja direkt die Menge der überhaupt modellierbaren Sachverhalte einschränken.
Ich halte mich bei der Definition lieber an http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/chap4.htm#Chap4.5 Dort heißt es "Eine Relation ist in der Dritten Normalform, wenn Sie in der Zweiten Normalform ist und jedes Nicht-Schlüssel-Attribut von keinem Schlüsselkandidaten transitiv abhängig ist."
Gruß
Filipp
wo hast du denn deine Definition der 3NF her? An der Stelle, an der sie steht sollte dann auch genauer definiert sein, was sie unter "Redundanzfreiheit" versteht... Das es keine zwei Zeilen geben darf, in der (ein Teil oder alle) Attribute den gleichen Wert besitzen kann ja wohl kaum gemeint sein, das würde ja direkt die Menge der überhaupt modellierbaren Sachverhalte einschränken.
Ich halte mich bei der Definition lieber an http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/chap4.htm#Chap4.5 Dort heißt es "Eine Relation ist in der Dritten Normalform, wenn Sie in der Zweiten Normalform ist und jedes Nicht-Schlüssel-Attribut von keinem Schlüsselkandidaten transitiv abhängig ist."
Die Praxis sieht oft anders aus und da geht es nur um eins: Was ist billiger - Speicher oder Prozessorleistung?
Normalisierung hat m.E. nach wenig mit Performance oder Speicherbedarf zu tun. Das ist von einem theorethischen Standpunkt auch erstmal egal. Vielmehr geht es dabei darum Datenkonsistenz und -flexibilität zu gewährleisten.Gruß
Filipp
Hi !
Also in einem Satz gesagt: Es gibt einen himmelweiten Unterschied zwischen der Theorie und der Praxis....
mrtux
Also in einem Satz gesagt: Es gibt einen himmelweiten Unterschied zwischen der Theorie und der Praxis....
mrtux
Hallo VB-NET.
Der Foreign Key ist ja der Primary Key aus einer anderen Tabelle. Die Redundanzfreiheit ist in der einen Tabelle durch den Primary Key gegeben (Eindeutiger Datensatz).
Der Foreign Key bezieht sich nur auf diesen Primary Key. Die Optionen, z.B. CASCADE oder DELETE, die man bei der Darstellung von Beziehungen (REFERENCES) nimmt, haben Auswirkungen, wenn der Primary Key etwas macht, z.B.:
1. ON UPDATE CASCADE -> Der Primary Key bekommt ein Update und gibt es an den Foreign Key weiter (ich bin nicht mehr 3 sondern 99, du jetzt auch)
2. ON DELETE SET NULL -> Der Primary Key wird gelöscht, der Foreign Key wird auf NULL gesetzt (ich bin weg, du bist NULL)
3. Der Primary Key gibt nichts an den Foreign Key weiter -> Es kommt evtl zu Unstimmigkeiten, weil die Referenz auf den Foreign Key nicht mehr möglich ist (ich bin weg, du weißt es nur noch nicht)
Es sollte am besten zu jedem Foreign Key auch ein Pendant geben, alternativ NULL-Werte.
Ich hoffe, es beantwortet deine Frage.
@ die Anderen: Er wollte nicht wissen, wie man es in der Praxis handhabt, sondern seine Frage beantwortet bekommen.
Gruß
Netzheimer
Der Foreign Key ist ja der Primary Key aus einer anderen Tabelle. Die Redundanzfreiheit ist in der einen Tabelle durch den Primary Key gegeben (Eindeutiger Datensatz).
Der Foreign Key bezieht sich nur auf diesen Primary Key. Die Optionen, z.B. CASCADE oder DELETE, die man bei der Darstellung von Beziehungen (REFERENCES) nimmt, haben Auswirkungen, wenn der Primary Key etwas macht, z.B.:
1. ON UPDATE CASCADE -> Der Primary Key bekommt ein Update und gibt es an den Foreign Key weiter (ich bin nicht mehr 3 sondern 99, du jetzt auch)
2. ON DELETE SET NULL -> Der Primary Key wird gelöscht, der Foreign Key wird auf NULL gesetzt (ich bin weg, du bist NULL)
3. Der Primary Key gibt nichts an den Foreign Key weiter -> Es kommt evtl zu Unstimmigkeiten, weil die Referenz auf den Foreign Key nicht mehr möglich ist (ich bin weg, du weißt es nur noch nicht)
Es sollte am besten zu jedem Foreign Key auch ein Pendant geben, alternativ NULL-Werte.
Ich hoffe, es beantwortet deine Frage.
@ die Anderen: Er wollte nicht wissen, wie man es in der Praxis handhabt, sondern seine Frage beantwortet bekommen.
Gruß
Netzheimer
Danke für die Antworten. Es geht nicht um Uni oder an die Praxis, sondern nur was dieser Foreinkey Key macht und ob man da mit redundanzfreien Tabellen arbeitet.
Sprich wenn ich nun in einer Tabelle einen PK habe und den mit dem FK einer anderen Tabelle verbinde, dann kann ich beim Löschen des PK-Datensatzes direkt automatisch den FK löschen usw.
Vielen Dank!
Sprich wenn ich nun in einer Tabelle einen PK habe und den mit dem FK einer anderen Tabelle verbinde, dann kann ich beim Löschen des PK-Datensatzes direkt automatisch den FK löschen usw.
Vielen Dank!
