nicht angemeldet
Datenbankentwurf
Hi erstmal,
ich schein grad ein wenig auf dem Schlauch zu stehen, vielleicht könnt ihr mir helfen.
Ich versuche gerade eine Datenbank zu entwerfen, die verschiedene Experimente verwaltet. Es soll verschiedene Experimenttypen geben die immer wieder duchgeführt werden aber man soll auch neue Experimenttypen anlegen können, die aber alle verschiedene Anzahlen von Feldern haben können. Wie geh ich da am geschicktesten ran?
Für jeden Typ eine eigene Tabelle? oder kann man das eleganter lösen?
Vielen Dank schon mal!
-
Hello,
Ich versuche gerade eine Datenbank zu entwerfen, die verschiedene Experimente verwaltet. Es soll verschiedene Experimenttypen geben die immer wieder duchgeführt werden aber man soll auch neue Experimenttypen anlegen können, die aber alle verschiedene Anzahlen von Feldern haben können. Wie geh ich da am geschicktesten ran?
Für jeden Typ eine eigene Tabelle? oder kann man das eleganter lösen?
Experiment-Typ Eigenschaft
1 - hat Eigenschaft 1
2 - hat Eigenschaft 2
3 - hat Eigenschaft 3Eigenschafts-Typ
1 - Beschreibung 1
2 - Beschreibung 2
3 - Beschreibung 3Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Für jeden Typ eine eigene Tabelle? oder kann man das eleganter lösen?
Experiment-Typ Eigenschaft
1 - hat Eigenschaft 1
2 - hat Eigenschaft 2
3 - hat Eigenschaft 3Eigenschafts-Typ
1 - Beschreibung 1
2 - Beschreibung 2
3 - Beschreibung 3Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Danke für die schnelle Antwort!
Diesen Ansatz habe ich auch schon mal verfolgt. Was mich daran gehindert hat ihn durchzuziehen war das eingeschränkt sein was die Datentypen angeht. An manche Datensätzen sollen Dateien als BLOB angehängt werden können, dann soll beispielsweise mal nach irgendwelchen Zahlenwerten sortiert werden können und und und... Hier wäre ich ja festgelegt auf die Datentypen "Experiment-Typ Eigenschaft".
-
Hello,
Diesen Ansatz habe ich auch schon mal verfolgt. Was mich daran gehindert hat ihn durchzuziehen war das eingeschränkt sein was die Datentypen angeht. An manche Datensätzen sollen Dateien als BLOB angehängt werden können, dann soll beispielsweise mal nach irgendwelchen Zahlenwerten sortiert werden können und und und... Hier wäre ich ja festgelegt auf die Datentypen "Experiment-Typ Eigenschaft".
Das ist das alte Problem des Denkfehlers in den Normalisierungsregeln. Die berücksichtigen nämlich keine Spaltentypen, sondern nur Abhängigkeiten.
Im Prinzip kannst Du den Fehler nur beheben, indem Du das die Datenbank machen lässt und diese nur mit "varianten Typen" arbeiten lässt, oder soweit runter auflöst, dass nachher jeder Datentyp eine eigene Tabelle hat.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Das ist das alte Problem des Denkfehlers in den Normalisierungsregeln. Die berücksichtigen nämlich keine Spaltentypen, sondern nur Abhängigkeiten.
Im Prinzip kannst Du den Fehler nur beheben, indem Du das die Datenbank machen lässt und diese nur mit "varianten Typen" arbeiten lässt, oder soweit runter auflöst, dass nachher jeder Datentyp eine eigene Tabelle hat.
Über den Ausdruck "variante Typen" bin ich jetzt aber grade gestolpert. Was darf ich mir darunter vorstellen. Ich kann ja der Datenbank nicht sagen "schau einfach mal was das ist und such dir den richtigen Datentyp aus", oder?
-
Hello,
Im Prinzip kannst Du den Fehler nur beheben, indem Du das die Datenbank machen lässt und diese nur mit "varianten Typen" arbeiten lässt, oder soweit runter auflöst, dass nachher jeder Datentyp eine eigene Tabelle hat.
Jein.
Ein varchar ist z.B. so ein varianter Typ.
Manche Datenbanken kennen sogar den Spaltentyp "Variant".
Besser ist es bestimmt, bis auf die Typenebene hinunter auzulösen. Das geht meistens aber nur mit Hilfe von benutzerdefinierten Funktionen und/oder Stored Procedures, da man für die Abfrage aus der einen Tabelle den Typ holen muss und in der Typentabelle nachschauen muss, in welcher Tabelle dann der Wert steht.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
Im Prinzip kannst Du den Fehler nur beheben, indem Du das die Datenbank machen lässt und diese nur mit "varianten Typen" arbeiten lässt,
ein Antipattern. Lesetipp: http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back
oder soweit runter auflöst, dass nachher jeder Datentyp eine eigene Tabelle hat.
möglich :-)
Freundliche Grüße
Vinzenz
-
Hello,
Im Prinzip kannst Du den Fehler nur beheben, indem Du das die Datenbank machen lässt und diese nur mit "varianten Typen" arbeiten lässt,
ein Antipattern. Lesetipp: http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back
Wenn man zu früh aufhört, aufzulösen, wahrscheinlich.
Es geht ja um das Problem, dass ein Kenndatensatz mehrere Eigenschaften haben kann, der durch mehrere Attribute gekennzeichnet werden kann. Dabei hat die eine Eigenschaft z.B.
Beschreibung Text
Breite decimal
Höhe decimalDie andere
Bezeichnung varchar
Version decimal
Speed MHz float
Pins intdie nächste
Date-Entry Date
Date-Leave DateWenn man nun nur bis zur Ebene "Eigenschaftsart" auflösen würde, hätte man in der Tabelle "Eigenschaften" unterschiedliche Typen, die nicht vereinbar wären.
Man müsste also hier nomals "eine Art M:N-Beziehung" einführen, die dann dazu führt, dass nachher alle Ints in einer Tabelle landen, alle Floats in der nächsten, alle Dates in der dritten, usw. Man muss hier also nicht logisch, sondern physisch aufteilen.
Wenn ich schreibe "eine Art M:N-Beziehung", dann deshalb, weil man hier bereits beim Design des Datenmodells eine "steinerndes Union" vorsehen kann. Dass während der Lebensdauer der Datenbank Datentypen hinzukommen, ist relativ unwahrscheinlich, wenn auch nicht unmöglich.
Und das kann man bei den meisten Datenbanken am besten durch benutzerdefinierte Funktionen, mit deren Hilfe man dann eben den Kenndatensatz zusammenbauen kann. Die Funktionen kann man so universell halten, dass man sie für das gesamte Projekt nur einmal zu erstellen hat. Der Rest geht dann durch Parametriesierung in der Abfrage.
Man erspart sich durch eine solche "Union-Funktion" über die "Bau_Steine_" der Datenbank eine Menge Schreibkram in der Abfrage.
Problematisch wird das dann wieder, wenn ich Äpfel mit Computern oder Eierpötte mit Kartoffelarten vergleichen will, was ja eigentlich nicht geht, beim Listen aber immer gerne wieder versucht wird.
Wie groß muss der Ergebnisdatensatz in der Breite dann werden?
Die Eigenschaften müssen daher eine klare semantische Bedeuting haben. Sie müssen auch auf eine eineindeutige Dimension zurückgeführt werden. "Gewicht" ist eine Eigenschaft, über die ich auch Kartoffeln mit Computern vergleich könnte...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
Tach!
Über den Ausdruck "variante Typen" bin ich jetzt aber grade gestolpert. Was darf ich mir darunter vorstellen. Ich kann ja der Datenbank nicht sagen "schau einfach mal was das ist und such dir den richtigen Datentyp aus", oder?
Wenn du SQLite nimmst, das kümmert sich nicht um den angegebenen Typ. Der ist nur zur Zierde da und man kann alles in allem unterbringen.
In anderen Systemen könnte dir ein Serial LOB weiterhelfen. Darin kann man aber nicht mehr wirklich suchen. Überhaupt ist das mit dem Suchen-Können so eine Sache, wenn du alles, von booleschen Werten bis zu Binärdateien, speichern können willst. Da Dateien in der Regel anders behandelt werden als "einfache Daten" (zum Beispiel Downloaden statt direktem Anzeigen oder Einbetten als Bild) solltest du dir über zumindest solch eine Typentrennung Gedanken machen.
dedlfix.
-
Hello,
Wenn du SQLite nimmst, das kümmert sich nicht um den angegebenen Typ. Der ist nur zur Zierde da und man kann alles in allem unterbringen.
Das Problem wird nur der Umgang mit dem Typ.
Wie sortiere ich Spalten, in denen Werte unterschiedlicher Typen stehen?
Wie bilde ich die Summe der Spalte, oder eiens Teiles davon, wenn Texte und Zahlen gemsicht in der Spalte stehen?Das Problem ist nicht neu. Die Normalisierungsregeln nehmen keine Rücksicht auf Spaltentypen bzw. haben dieses Problem bisher nicht behandelt. (Hier würde ich dich gerne zum qualifizierten Widerspruch anregen...)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Tach!
Das Problem wird nur der Umgang mit dem Typ.
Wie sortiere ich Spalten, in denen Werte unterschiedlicher Typen stehen?
Wie bilde ich die Summe der Spalte, oder eiens Teiles davon, wenn Texte und Zahlen gemsicht in der Spalte stehen?Garbage in - Garbage out. Wenn man solche Anforderungen hat, sollte man diese beim Designen berücksichtigen. Sortieren geht vermutlich gut, solange die Daten in Textform gespeichert sind. Allerdings ist dann auch 100 kleiner als 11. Ich sehe keinen Sinn darin, gewürfelte Daten berechnen zu wollen. Da hinter jedem Wert alle möglichen Bedeutungen stecken können, würden dann auch Äpfel mit Birnen zusammengezählt. Auch der Mensch braucht ein Unterscheidungsmerkmal, wenn er an Rechenoperationen mit nur bestimmten Werten interessiert ist, wofür eine Separierung oder zumindest Kennzeichnung erforderlich ist. Bei eienr Separierung kann man gleich den richtigen Typ nehmen, bei einer Kennzeichnung sollte man sich innerhalb eines Merkmals für eine bestimmte Ablageform entscheiden, bei der man dann weiß, wie die Daten zu behandeln sind.
dedlfix.
-
Hello,
Garbage in - Garbage out.
Es handelt sich um eine fast alltägliche Anforderung in der Warenwirtschaft. Meistens wird die Lösung der Aufgabe aber unterlassen, weil den Programmierern das als zuviel Aufwand erscheint. Dabei muss man nur einmal zuende denken.
Wenn man solche Anforderungen hat, sollte man diese beim Designen berücksichtigen. Sortieren geht vermutlich gut, solange die Daten in Textform gespeichert sind. Allerdings ist dann auch 100 kleiner als 11.
Selbst das Problem lässt sich über eine passende Formatierung der Daten (bei der Eingabe) noch lösen. Zahlen werden einfach rechtsbündig (ggf. mit führenden Leerzeichen) abgespeichert.
Ich sehe keinen Sinn darin, gewürfelte Daten berechnen zu wollen.
Richtig. Das muss man dann im View über einen Gruppenwechsel lösen, der den Datentyp der Spalte berücksichtigt und nur für bestimmte "Eigenschaften" z.B. Summen bildet...
Dadurch wird das System aber schon spezialisiert.Da hinter jedem Wert alle möglichen Bedeutungen stecken können, würden dann auch Äpfel mit Birnen zusammengezählt. Auch der Mensch braucht ein Unterscheidungsmerkmal, wenn er an Rechenoperationen mit nur bestimmten Werten interessiert ist, wofür eine Separierung oder zumindest Kennzeichnung erforderlich ist. Bei eienr Separierung kann man gleich den richtigen Typ nehmen, bei einer Kennzeichnung sollte man sich innerhalb eines Merkmals für eine bestimmte Ablageform entscheiden, bei der man dann weiß, wie die Daten zu behandeln sind.
Das ist alles soweit richtig. Nur löst dein Beitrag auch nicht das rudimentäre Problem des OP - sofern ich ihn richtig verstanden habe. So, wie ich es verstanden habe, ist mir das Problem schon sehr oft begegnet. Und irgendwo habe ich auch noch einen Funktionensatz rumfliegen, der dies mit MySQL 5.0 lösen sollte. Der müsste es jetzt unter 5.x (x>0) eigentlich auch bringen.
Ich suche mal.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Tach!
Das ist alles soweit richtig. Nur löst dein Beitrag auch nicht das rudimentäre Problem des OP - sofern ich ihn richtig verstanden habe.
Liegt daran, dass ich nicht in der Lage bin, eine universelle Datenstruktur für unstrukturierte Daten zu erfinden, die für alle möglichen Auswerteformen geeignet ist.
Vielleicht sollte man mit solchen Wünschen die Leistungsmerkmale von NoSQL-Datenbanken prüfen. Da gibt es welche, in die man alles mögliche einkippen kann und statt WHERE-Klauseln für die Auswertungen Javascript oder ähnliches verwenden kann. Damit ist man schon eine Ecke flexibler, allerdings scheitert der Ansatz auch wenn man einfach nur Datenhaufen statt irgendwie strukturierter Dokumente ablegt. - Wobei man dieses Verhalten auch mit Serialized LOB und Stored Functions/Procedures nachbilden kann.
dedlfix.
-
Liegt daran, dass ich nicht in der Lage bin, eine universelle Datenstruktur für unstrukturierte Daten zu erfinden, die für alle möglichen Auswerteformen geeignet ist.
LOL! Versager! ;-)
-
-
-
-
-
-
-
-
-