nicht angemeldet
Primaerschluessel
Hi,
heute hatte ich eine kleine Diskussion, die ohne Konsens endete. Es ging um zusammengesetzte Primaerschluessel, deren Datenfelder eine Bedeutung haben. Ich plaedierte aus zwei Gruenden dagegen: 1.) zusammengesetzte Schluessel sind boese 2.) Schluessel mit Bedeutung sind boese.
Frage: Darf man eigentlich heute noch ungestraft zusammengesetzte und mit Semantik beladene Primaerschluessel propagieren? Und wie hoch waere ggf. die Strafe?
Gruss,
Lude
---
"Realitaet ist das, was noch da ist, wenn man aufgehoert hat zu glauben."
-
Sup!
Die Gegenfrage waere, ob es keine Strafe ist, wenn man sein ganzes Datenbankschema in die Zigste Normalform umbasteln muss, auch wenn es ueberhaupt keinen Sinn macht.
Gruesse,
Bio
-
Hi,
Die Gegenfrage waere, ob es keine Strafe ist, wenn man sein ganzes Datenbankschema in die Zigste Normalform umbasteln muss, auch wenn es ueberhaupt keinen Sinn macht.
warum Gegenfrage? Ich bin doch kein Ideologe. Und bereits die erste Normalform wird in keiner mir bekannten Datenhaltung erreicht. Und auf das Speichern von berechneten Werten darf man in der Praxis auch nicht verzichten.
Gruss,
Lude---
"Bis Weihnachten brauchen wir Klarheit bei der Maut."-
Sup!
warum Gegenfrage? Ich bin doch kein Ideologe. Und bereits die erste Normalform wird in keiner mir bekannten Datenhaltung erreicht. Und auf das Speichern von berechneten Werten darf man in der Praxis auch nicht verzichten.
Es sei denn, es gefaehrdet die Konsistenz und CPU-Leistung ist billiger als Speicher.
Gruesse,
Bio
-
Hi,
Es sei denn, es gefaehrdet die Konsistenz und CPU-Leistung ist billiger als Speicher.
beispielsweise irgendwelche fuer die "kaufmaennischen Ebenen" wichtige berechntete Werte (z.B. Vertragswerte) muessen gespeichert werden, weil ansonsten, wenn die Berechnungsgrundlage sich geaendert hat, irgendwann einmal blass geguckt wird.
Gruss,
Lude-
Sup!
beispielsweise irgendwelche fuer die "kaufmaennischen Ebenen" wichtige berechntete Werte (z.B. Vertragswerte) muessen gespeichert werden, weil ansonsten, wenn die Berechnungsgrundlage sich geaendert hat, irgendwann einmal blass geguckt wird.
Dafuer gibt es ja, zumindest theoretisch, Datenbanken, die eine Revisionsverwaltung haben, so dass man bei der Berechnung von Ergebnissen fuer einen bestimmten Zeitpunkt mit historischen Daten von diesem Zeitpunkt rechnen koennte - und den fuer diesen Zeitpunkt gueltigen, ebenfalls in der DB abgelegten Formeln.
Gruesse,
Bio
-
Hi,
Dafuer gibt es ja, zumindest theoretisch, Datenbanken, die eine Revisionsverwaltung haben, so dass man bei der Berechnung von Ergebnissen fuer einen bestimmten Zeitpunkt mit historischen Daten von diesem Zeitpunkt rechnen koennte - und den fuer diesen Zeitpunkt gueltigen, ebenfalls in der DB abgelegten Formeln.
klar, aber der Overhead fuer eine Funktionentabelle. :-(
Und dann noch die Idee Geschaeftslogik in der Datenhaltung anzusiedeln. :-(Gruss,
Lude-
Sup!
klar, aber der Overhead fuer eine Funktionentabelle. :-(
Und dann noch die Idee Geschaeftslogik in der Datenhaltung anzusiedeln. :-(Ob die Geschaeftslogik nun auf der Platte liegt oder in einer DB, ist doch fuer die Trennung von Geschaeftslogik und Datenhaltung eigentlich egal, auch wenn die eigentlichen Daten und die Funktionsdatenbank zufaellig auf dem gleichen Datenbankserver liegen sollten.
Gruesse,
Bio
-
Hi,
Ob die Geschaeftslogik nun auf der Platte liegt oder in einer DB, ist doch fuer die Trennung von Geschaeftslogik und Datenhaltung eigentlich egal, auch wenn die eigentlichen Daten und die Funktionsdatenbank zufaellig auf dem gleichen Datenbankserver liegen sollten.
der Minimalkonsens des verstandenen Dissenzes duerfte damit erreicht sein. Aber zurueck zum Thema: Also kein Penalty fuer kombinierte bedeutungsbehaftete Schluessel?
Gruss,
Lude---
"Wenn von dorther der Wind ueber die Felder weht, dann weiss ich es wird Sommer."
-
-
-
-
-
-
use Mosche;
Mal so eine Frage als "Schulinformatiker":
Und bereits die erste Normalform wird in keiner mir bekannten Datenhaltung erreicht.
Warum. Mir erscheinen die ersten beiden Normalformen noch größtenteils so elementar, dass ich es beinahe trivial fand, diese einzuhalten (natürlich waren die damaligen Beispiele alle entsprechend einfach). Erst ab der dritten Normalform wurde es schräg.
Aber was spricht denn real gegen die ersten beiden?
use Tschoe qw(Matti);
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.-
Hi,
Und bereits die erste Normalform wird in keiner mir bekannten Datenhaltung erreicht.
Warum. Mir erscheinen die ersten beiden Normalformen noch größtenteils so elementar, dass ich es beinahe trivial fand, diese einzuhalten (natürlich waren die damaligen Beispiele alle entsprechend einfach). Erst ab der dritten Normalform wurde es schräg.
damit eine Tabelle der ersten Normalform entspricht, darf sie keine sich wiederholenden Spaltenwerte halten.
Damit eine Tabelle der zweiten Normalform enstpricht, darf sie keine berechneten Spaltenwerte enthalten, zumindest sofern diese Berechnung ausschliesslich unter Zuhilfenahme von Werten dieser Tabelle erfolgt ist.Gruss,
Lude---
"Klarheit bei der Maut brauchen wir bis Weihnachten."-
Hi Lude
damit eine Tabelle der ersten Normalform entspricht, darf sie keine sich wiederholenden Spaltenwerte halten.
Damit eine Tabelle der zweiten Normalform enstpricht, darf sie keine berechneten Spaltenwerte enthalten, zumindest sofern diese Berechnung ausschliesslich unter Zuhilfenahme von Werten dieser Tabelle erfolgt ist.Setzen, 6. Die 2. Normalform ist anders als du sie darstellst, die erste hast du zu allgemein gefasst.
Gruss Daniela
-
Hi,
damit eine Tabelle der ersten Normalform entspricht, darf sie keine sich wiederholenden Spaltenwerte halten.
Damit eine Tabelle der zweiten Normalform enstpricht, darf sie keine berechneten Spaltenwerte enthalten, zumindest sofern diese Berechnung ausschliesslich unter Zuhilfenahme von Werten dieser Tabelle erfolgt ist.Setzen, 6. Die 2. Normalform ist anders als du sie darstellst, die erste hast du zu allgemein gefasst.
Dein schulmeisterliches Auftreten mit dem Ziel zu Regulieren (Was? - das weiss der Teufel. - Wird aber bestimmt keinen natuerlichen Zielen dienen. ;-) ist ja schon bekannt hier. Dennoch bitte ich Dich, soz. im Verzweiflungsmodus, entweder etwas Nuetzliches zur Diskussion (Thema: "Wie wird die Normalisierung in der Praxis umgesetzt?") beizutragen oder Dich ihr zu enthalten.
Gruss,
Lude---
"Harald Schmidt, wo bist Du?"-
Hi Lude
Dein schulmeisterliches Auftreten mit dem Ziel zu Regulieren (Was? - das weiss der Teufel. - Wird aber bestimmt keinen natuerlichen Zielen dienen. ;-) ist ja schon bekannt hier. Dennoch bitte ich Dich, soz. im Verzweiflungsmodus, entweder etwas Nuetzliches zur Diskussion (Thema: "Wie wird die Normalisierung in der Praxis umgesetzt?") beizutragen oder Dich ihr zu enthalten.
Und ich bitte dich, keine falschen Aussagen zu verbreiten. Deine Normalformen stimmen so einfach nicht.
Gruss Daniela
-
Hi,
Und ich bitte dich, keine falschen Aussagen zu verbreiten. Deine Normalformen stimmen so einfach nicht.
was war denn falsch? Unterstelle mir bitte nicht, dass ich eine Definition der Normalformen versucht habe. - Aus dem Kontext geht klar hervor, dass ich einem "Schulinformatiker" aus meinen Erfahrungen heraus von der (gelegentlichen ;-) Nichtbeachtung der Regeln der Normalisierung berichtet habe.
Gruss,
Lude---
"Beste Filme aller Zeiten: 'Casablanca', 'Pulp Fiction', 'The Good the Bad and the Ugly'-
Hi Lude
was war denn falsch? Unterstelle mir bitte nicht, dass ich eine Definition der Normalformen versucht habe.
Doch genau das hast du getan. Die erste Normalform sagt nicht aus, es darf keinerlei identische Werte in einer Tabelle geben. Die darf es sehr wohl:
Beispiel:
PersonenID Name Vorname
1 asdf jklö
2 asdf oiuzIst sehr wohl zulässig.
2. Normalform: Die hat überhaupt nicht das geringste mit berechneten Werten zu tun sondern nur mit der Abhängigkeit der Werte vom Primärschlüssel.
- Aus dem Kontext geht klar hervor, dass ich einem "Schulinformatiker" aus meinen Erfahrungen heraus von der (gelegentlichen ;-) Nichtbeachtung der Regeln der Normalisierung berichtet habe.
Ja, nur mit einer völlig falschen Begründung. Du musstest nicht völligen Quatsch erzählen um das zu belegen. Es hätte gereicht dass man häufig Werte nicht abtrennt weil ein Join halt teuer ist.
Gruss Daniela
-
Hi,
Doch genau das hast du getan. Die erste Normalform sagt nicht aus, es darf keinerlei identische Werte in einer Tabelle geben. Die darf es sehr wohl:
Beispiel:
PersonenID Name Vorname
1 asdf jklö
2 asdf oiuzIst sehr wohl zulässig.
'1. Normalform: Eine Relation befindet sich in der ersten Normalform, wenn keines ihrer Attribute eine untergeordnete Relation darstellt und wenn alle Attribute nur atomare Werte beinhalten' (Codd)
'Damit einer Tabelle auch nur der ersten Normalform entspricht, darf sie keine sich wiederholenden Werte enthalten. Sich wiederholende Werte koennen die Form mehrfacher Spalten annehmen, die zur Speicherung von Instanzen desselben Wertetyps verwendet werden, oder die merhfache Werte in einer einzelnen Spalte. Diese sich wiederholenden Werte muessen entfernt werden, wenn eine Tabelle als normalisiert angesehen werden soll.' (K.Henderson, 'Transact-SQL', Addison-Wesley, S.279)Ja, nur mit einer völlig falschen Begründung. Du musstest nicht völligen Quatsch erzählen um das zu belegen. Es hätte gereicht dass man häufig Werte nicht abtrennt weil ein Join halt teuer ist.
Die richtige Begruendung ist eben nicht, dass ein JOIN teuer ist, sondern, dass bestimmte (berechnete) Werte in der Tabelle soz. redundant gespeichert werden sollten, weil das, wie ich auch in meiner Diskussion mit 'Bio' erlaeutert habe, fuer den positiven Geschaeftserfolg notwendig ist.
Gruss,
Lude---
"Bis Weihnachten brauchen wir Klarheit bei der Maut."-
Hi Lude
Die richtige Begruendung ist eben nicht, dass ein JOIN teuer ist, sondern, dass bestimmte (berechnete) Werte in der Tabelle soz. redundant gespeichert werden sollten, weil das, wie ich auch in meiner Diskussion mit 'Bio' erlaeutert habe, fuer den positiven Geschaeftserfolg notwendig ist.
Nein, die Begründung halte ich einfach nur für falsch da bei solchen Konstellationen die Datenhaltung imho faul ist. Als Beispiel könntest jetzt Währungsumrechnungskurse anführen. Ich sage allerdings, diese müssen von jedem Zeitpunkt wiederhergestellt werden können. Ich arbeite btw als Programmierin von Buchhaltungsapplikationen und Währungskurse beispielsweise _werden_ historisiert, genauso wie andere Berechnungsregeln. Die Gründe auf Historisierung zu verzichten sind Datenmengen oder Performanceprobleme in den dauernden Neuberechnung der Resultate. Folgt, auf Grund der Daten sind keinerlei Verletzungen der Normalformen nötig. Das ist ja auch der Grund für die Normalformen. Die Integrität der Daten zu gewährleisten.
Gruss Daniela
-
Hi,
Die richtige Begruendung ist eben nicht, dass ein JOIN teuer ist, sondern, dass bestimmte (berechnete) Werte in der Tabelle soz. redundant gespeichert werden sollten, weil das, wie ich auch in meiner Diskussion mit 'Bio' erlaeutert habe, fuer den positiven Geschaeftserfolg notwendig ist.
Nein, die Begründung halte ich einfach nur für falsch da bei solchen Konstellationen die Datenhaltung imho faul ist.
das ist eben der Konflikt zwischen der "reinen Lehre" und den Gegebenheiten. Die Normalisierung nach Codd ist fuer mich einfach ein nuetzliches Regelwerk, keinesfalls ein Dogma. - Wenn, und da stimme ich Dir ja zu, die Sache als "faul" empfindest, dann muestte man tatsaechlich den Weg gehen, den 'Bio' aufgezeigt hat.
Als Beispiel könntest jetzt Währungsumrechnungskurse anführen. Ich sage allerdings, diese müssen von jedem Zeitpunkt wiederhergestellt werden können.
Sehe ich auch so.
Ich arbeite btw als Programmierin von Buchhaltungsapplikationen und Währungskurse beispielsweise _werden_ historisiert, genauso wie andere Berechnungsregeln.
Wir stopfen moeglichst keine Geschaeftslogik in die Datenhaltung. - Aus ideologischen Gruenden.
Die Gründe auf Historisierung zu verzichten sind Datenmengen oder Performanceprobleme in den dauernden Neuberechnung der Resultate.
Neues Thema 'Historisierung in einem RDBMS' (naja, vielleicht morgen ;-)? ;-)
Folgt, auf Grund der Daten sind keinerlei Verletzungen der Normalformen nötig.
Noetig schon, eben wegen der Gegebenheiten.
Das ist ja auch der Grund für die Normalformen. Die Integrität der Daten zu gewährleisten.
Ein gutes Schlusswort.
Gruss,
Lude---
"Wir brauchen bei der Klarheit Maut bis Weihnachten."
-
-
yo,
normalisierung sind komischerweise fast immer falsch beschrieben, egal ob nun in bücher oder dem internet. insofern ist es nicht weiter verwunderlich, wenn viele es falsch weiter geben. normalisierung kann man nicht einzeln betrachten, sondern die einzelnen regeln bauen aufeinander auf.
die diskussion, ob es nach einer normaliserung in einer spalte gleiche werte geben kann, ist nicht so ohne weiteres zu beantworten. die normalisierungsregeln beziehen sich nicht auf inhalte der spalten, aber das datenbankdesign, welches indirekt darauf einfluss nehmen kann.
noch ein weitere tip, eine relation ist eine tabelle und nicht wie so oft verwechselt eine beziehung. und atomare werte bedeutet auch nicht, dass man postleitzahl von dem ort oder der straße trennen muss.
Ilja
-
Hi,
ich weiss zwar nicht aus welchem "Off" Du Dich meldest, aber interessieren taete es mich schon.
normalisierung sind komischerweise fast immer falsch beschrieben, egal ob nun in bücher oder dem internet.
Du sprichst mich an, den Nicht-Ideologen. Und das auch noch referenzfrei.
insofern ist es nicht weiter verwunderlich, wenn viele es falsch weiter geben. normalisierung kann man nicht einzeln betrachten, sondern die einzelnen regeln bauen aufeinander auf.
Klar, ein Regelwerk und natuerlich nichts Absolutes. - Sonst waere es ja auch untauglich. ;-)
die diskussion, ob es nach einer normaliserung in einer spalte gleiche werte geben kann, ist nicht so ohne weiteres zu beantworten.
Man hat diese Frage aber beantwortet - und zwar ohne Einschraenkungen.
die normalisierungsregeln beziehen sich nicht auf inhalte der spalten, aber das datenbankdesign, welches indirekt darauf einfluss nehmen kann.
Bitte erlaeutern.
noch ein weitere tip, eine relation ist eine tabelle und nicht wie so oft verwechselt eine beziehung. und atomare werte bedeutet auch nicht, dass man postleitzahl von dem ort oder der straße trennen muss.
Dito.
Gruss,
Lude---
"Bis wir Klarheit bei der Maut haben brauchen wir Weihnachten."-
yo,
Klar, ein Regelwerk und natuerlich nichts Absolutes. - Sonst waere es ja auch untauglich. ;-)
ich meinte es in einem anderen zusammenhang, es bringt nichts, nur den ersten schritt der normalisierung durchzuführen, ohne die anderen beiden schritten folgen zu lassen. der glaube mit jedem schritt wird die datenbank besser ist falsch, sondern es baut aufeinaner auf. führt man nur den ersten schritt aus, brinkt das mehr probleme als lösungen.
Man hat diese Frage aber beantwortet - und zwar ohne Einschraenkungen.
es gibt keine direkte einschränkung zu der normalsierung, aber eine indirekte, wie ich weiter unten zeigen werde.
die normalisierungsregeln beziehen sich nicht auf inhalte der spalten, aber das datenbankdesign, welches indirekt darauf einfluss nehmen kann.
Bitte erlaeutern.
bei dem normalierungsprozess, spielt der inhalt keine rolle. insofern könnne zum beispiel mehrmals der ort berlin in einer spalte für orte eingetragen werden. mein datenbankdesign kann aber so verlaufen, dass die normaliserung genau das verhindern wird, dass mehrere orte gleichen namens in eine spalte stehen.
wenn ich zum beispiel eine datenbank für kunden entwickle und die kunden in viele orte verteilt sind, werde ich den ort nicht als eigene entität nehmen, sondern in der adresse bestehen lassen. es lohnt sich nicht, da die kunden aus zuvielen unterschiedliche orten kommen. sind aber 2/3 aus berlin und der rest aus der nahen umgebung, da lohnt es sich schon, den ort als eigene entität herauszunehmen.
und genau dann würde der normaliserungsprozess dafür sorgen, dass nur einmal berlin in der spalte vorkommt.
Ilja
-
-
-
-
-
use Mosche;
Aus dem Kontext geht klar hervor, dass ich einem "Schulinformatiker" aus meinen Erfahrungen heraus von der (gelegentlichen ;-) Nichtbeachtung der Regeln der Normalisierung berichtet habe.
Wo?
use Tschoe qw(Matti);
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
-
-
-
-
use Mosche;
damit eine Tabelle der ersten Normalform entspricht, darf sie keine sich wiederholenden Spaltenwerte halten.
Damit eine Tabelle der zweiten Normalform enstpricht, darf sie keine berechneten Spaltenwerte enthalten, zumindest sofern diese Berechnung ausschliesslich unter Zuhilfenahme von Werten dieser Tabelle erfolgt ist.Vielleicht solltest du einmal auf den Ton achten: ich habe eine Frage gestellt, warum es nicht funktionieren sollte, und nicht, was die Normalformen sind.
Weiterhin möchte ich anmerken, dass ich "andere" Normalformen gelernt habe: bei einer kurzen Suche bin ich auf http://lls.informatik.uni-oldenburg.de/lehre/vorlesungen/ss2001_wiwisowi2/vl11_1seitig_farbe.pdf gestossen, was meinen Definitionen nahe liegt.
Zu 1) Als Primärschlüssel müssen Skalare verwendet werden
Zu 2) Das Tupel muss vom gesamtem Schlüssel (und nicht von Schlüsselteilen) anhängig sein.3. Normalform war (wenn ich mich recht erinnere), dass nicht-Schlüssel nicht von anderen nicht-Schlüsselattributen abhängen dürfen (berühmtes (und nicht zutreffendes) Beispiel war immer PLZ <-> Ort, welche nach 3.NF normalisiert werden müssten (wenn es denn eine bijektive Abbildung PLZ -> Ort gäbe, die es nicht gibt.)
Dir 3. NF gehört nicht unbedingt zum Standard, weil dann viele Dinge verkompliziert werden würden, di ersten beiden aber halte ich für Standard.
Warum sollte dies nicht zutreffen?
use Tschoe qw(Matti);
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.-
Hi Matti
Zu 1) Als Primärschlüssel müssen Skalare verwendet werden
Sie geht noch ein Stück weiter und verbietet dir auch, Spalten wie Telnr1 und Telnr2 zu machen.
Gruss Daniela
-
Hi,
ich hatte falsch gequotet. Die Antwort bezog sich auf: 'Aber was spricht denn real gegen die ersten beiden? (RR: Normalformen)' - Hier noch mal die Antwort:
'damit eine Tabelle der ersten Normalform entspricht, darf sie keine sich wiederholenden Spaltenwerte halten. Damit eine Tabelle der zweiten Normalform enstpricht, darf sie keine berechneten Spaltenwerte enthalten, zumindest sofern diese Berechnung ausschliesslich unter Zuhilfenahme von Werten dieser Tabelle erfolgt ist.'
Vielleicht solltest du einmal auf den Ton achten: ich habe eine Frage gestellt, warum es nicht funktionieren sollte, und nicht, was die Normalformen sind.
Ich hatte Dir geantwortet, aber falsch gequotet, sorry.
[Zitate und Anmerkungen zur relationelen Datenbanktheorie]
Warum sollte dies nicht zutreffen?Das moechte ich jetzt nicht diskutieren, auch um die Stimmung nicht weiter aufzuheizen. - Vermutlich waere ich auch der falsche Mann - bin ich doch Praktiker.
Gruss,
Lude---
"Und Du kannst noch so doof sein; hier, im Forum, gibt's immer noch einen der ist doefer."
-
-
-
-
-
-
Hi Lude
Frage: Darf man eigentlich heute noch ungestraft zusammengesetzte und mit Semantik beladene Primaerschluessel propagieren? Und wie hoch waere ggf. die Strafe?
Ich werde das weiterhin machen solange diese Schlüssel in der realen Welt auch Schlüssel darstellen und diese Sinn ergeben.
Gruss Daniela
-
Hi,
Frage: Darf man eigentlich heute noch ungestraft zusammengesetzte und mit Semantik beladene Primaerschluessel propagieren? Und wie hoch waere ggf. die Strafe?
Ich werde das weiterhin machen solange diese Schlüssel in der realen Welt auch Schlüssel darstellen und diese Sinn ergeben.
OK, und siehst Du vielleicht dennoch auch Nachteile?
Gruss,
Lude---
"Ohne Taschengeld der Hund nicht bellt."-
Hi Lude
OK, und siehst Du vielleicht dennoch auch Nachteile?
Ja, zb wenn es Stringwerte sind über die aber nicht gesucht wird und ansonsten kein Index benötigt würde.
Gruss Daniela
-
-