nicht angemeldet
Nochmal eine Frage zur Normalisierung
Hallo Selfler!
Das Problem aus meinem damaligen Thread (http://forum.de.selfhtml.org/?t=168340&m=1098267) wurde ja durch euch geklärt, allerdings habe ich noch eine weitere Frage.
Außer Schlagwörtern, sind für die Bilder noch weitere Informationen gespeichert. Z.B. ob ein Bild öffentlich oder privat ist, der Titel, wie groß es ist (Auflösung) und das Uploaddatum. Welche dieser Werte sollte ich direkt in die Tabelle mit den Bildern speichern und für welche soll ich eine neue Tabelle und eine Verknüpfungstabelle erstellen?
Für den Titel keine Verknüpfungstabelle oder? Das ist ja was individuelles, für jedes Bild anders. Öffentlich und privat, da auch nicht, das würde nur Performance kosten (ist ja entweder true oder false)
Für die Auflösung? Da bin ich mir z.B. nicht sicher. Jedes Bild hat nur eine Auflösung, also keine neue Tabelle?
Und für das Uploaddatum auch nicht, oder?
Wäre nett, wenn ihr mir helfen könntet. Den Wikipediaartikel über Normalisierung habe ich gelesen, der hat meine Frage aber nicht beantwortet.
Danke,
John M.
-
Hallo,
Kurzum:
Eine Normalisierung kannst Du soweit treiben, dass es in _einer_ Tabelle keine Datensätze mehr gibt, die in irgendeinem Feld denselben Wert haben. In Deinem Fall wären der Content-Type bei allen DS gleich, sofern da nur Bilder sind.Wie gesagt, Du kannst. Musst aber nicht. Für Deinen Fall reicht eine Tabelle.
Zu meiner Schulungs-Zeit hieß es, dass eine Normalisierung nicht unbedingt _das_ Ziel ist und drei Tabellen in etwa das Optimum sind. Meine bisherige Praxis kann das bestätigen.
Viele Grüße,
Horst Haselhuhn-
yo,
Eine Normalisierung kannst Du soweit treiben, dass es in _einer_ Tabelle keine Datensätze mehr gibt, die in irgendeinem Feld denselben Wert haben.
nein, das ist nicht sinn der normalisierung. grundsätzlich entfernt normalisierung keine redundanzen, das ist ein weit verbreiteter irrtum.
Ilja
-
-
Hi,
Außer Schlagwörtern, sind für die Bilder noch weitere Informationen gespeichert. Z.B. ob ein Bild öffentlich oder privat ist, der Titel, wie groß es ist (Auflösung) und das Uploaddatum. Welche dieser Werte sollte ich direkt in die Tabelle mit den Bildern speichern und für welche soll ich eine neue Tabelle und eine Verknüpfungstabelle erstellen?
Wie Horst schon sagte, man *kann* Normalisierung so weit treiben, dass bspw. auch Werte wie die Bildgroesse in eine extra Tabelle ausgelagert werden. Die koennte in einer extra Tabelle liegen, bspw. ein Datensatz mit Bildgroessen-ID #4711, Breite 2048 und Hoehe 1200 Pixel o.ae.
Und bei einem Bild dieser Groesse wird dann im Bilddatensatz nur noch auf die Bildgroessen-ID #4711 referenziert.*Koennte* man machen, waere in der Praxis aber in aller Regel uebertrieben.
Deshalb wuerde ich Titel, Status (oeffentlich/privat) und Bildgroesse direkt am Bilddatensatz ablegen.
Fuer den Status koennte man ein Feld vom Typ ENUM waehlen (bei MySQL, sonst etwas entsprechendes).Und für das Uploaddatum auch nicht, oder?
Nee, auch eher nicht. (Aber natuerlich einen der Datumstypen, den die DB bereitstellt, dafuer nehmen - nicht auf die Idee kommen, das einfach als Textliteral (VARCHAR o.ae.) abzulegen.)
Den Wikipediaartikel über Normalisierung habe ich gelesen, der hat meine Frage aber nicht beantwortet.
Dann weisst du also schon mal, dass man zwischen verschiedenen "Graden" von Normalisierung unterscheidet, und in der Praxis idR. bis zur dritten Normalform, 3NF, geht.
Abweichungen davon, auch teilweise fuer einzelne Eigenschaften, sind natuerlich immer denkbar - wenn man sie ausreichend gut begruenden kann.
Normalisierung sollte kein Selbstzweck sein und damit "auf Teufel komm raus" erfolgen - siehe, oben, *koennte* man fuer die Bildmasze auch machen, duerfte in der Praxis aber eher weniger sinnvoll sein.Manchmal weicht man auch gerade aus Performance-Gruenden bewusst von 3NF ab. Flickr z.B. speichert die Tags seiner Bilder IIRC *nicht* derartig normalisiert, weil's bei dem Datenumfang einfach nicht mehr performant genug waere, dafuer immer in extra Tabellen nachschauen zu muessen, beim Suchen etc. (Irgendwo im Netz kursiert ein PDF, welches den Aufbau der Datenstruktur von Flickr beschreibt; ich hab's nur gerade nicht als Bookmark ...)
MfG ChrisB
-
yo,
Wie Horst schon sagte, man *kann* Normalisierung so weit treiben, dass bspw. auch Werte wie die Bildgroesse in eine extra Tabelle ausgelagert werden. Die koennte in einer extra Tabelle liegen, bspw. ein Datensatz mit Bildgroessen-ID #4711, Breite 2048 und Hoehe 1200 Pixel o.ae.
Und bei einem Bild dieser Groesse wird dann im Bilddatensatz nur noch auf die Bildgroessen-ID #4711 referenziert.auch hier noch mal den hinweis, dieses vorgehen wäre falsch und hätte meiner meinung nach nichts mit normalisierung zu tun.
Ilja
-
Hi,
auch hier noch mal den hinweis, dieses vorgehen wäre falsch und hätte meiner meinung nach nichts mit normalisierung zu tun.
Ok, das akzeptiere ich - wenn du mir auch noch kurz erklaeren koenntest, warum? :-)
Sicher handelt es sich dabei um eine andere "Art" von Daten - aber wo genau liegt deines Erachtens der Unterschied, ob ich nun bspw. den Namen der Person, die ein Bild hochgeladen hat, auslagere - oder eben die Info, dass das Bild, wie viele andere auch, eine Breite von 1024 Pixeln hat?
Wie gesagt, ich wuerde letzteres auch nicht machen wollen - aber eher "rein intuitiv", als dass ich das wirklich stichhaltig begruenden koennte.
Kannst du mir da ein "echtes" Argument nennen?MfG ChrisB
-
Hello Chris,
Ok, das akzeptiere ich - wenn du mir auch noch kurz erklaeren koenntest, warum? :-)
Mmmh, darüber habe ich schon nächtelang mit meiner Freundin gestritten.
Manchmal ist Philosophie wirklich attraktiver als alles andere...Sicher handelt es sich dabei um eine andere "Art" von Daten - aber wo genau liegt deines Erachtens der Unterschied, ob ich nun bspw. den Namen der Person, die ein Bild hochgeladen hat, auslagere - oder eben die Info, dass das Bild, wie viele andere auch, eine Breite von 1024 Pixeln hat?
Normalisierung beschränkt sich auf die Auflösung von Beziehungen und Eigenschaften, je nachdem, aus welcher Richtung dur guckst.
Die typgerechte Auflösung von vernetzten Datenstrukturen bleibt dabei auf der Strecke.
Ein Beispiel hierfür ist die Modellierung einer Kommunikationsverbindung zu einer Person.
Das gibt es Telefon, eMail, Homepage, Betriebsfunkfrfequenz, usw. Lauter Werte, die unterschiedliche Typen oder zumindest stark unterschiedliche Datenlänge haben können.Ndere Beispiele sind noch gravierender.
Versuch mal eine Artikeldatenbank eines EDV-Händlers mit Kenngrößen zu versorgen.
Prozessoren haben andere Kenngrößen als Festplatten.
Die Typen sind immer andere. Die Sortierung funktioniert daher anders.usw...
Liebe Grüße
Tom vom Berg
--
Nur selber lernen macht schlau
-
yo,
ich antworte euch beiden mal in einem beitrag. erst einmal ein paar allgemeine sachen zur normalisierung. hierbei handelt es sich um ein vorgehen, dem ich etwas positives abverlange. es ist kein selbstzweck oder heilige kuh, sondern ich investiere zeit in etwas und will unter dem strich ein mehrgewinn haben.
und der mehrgewinn den ich durch normalisierung und andere prozesse gewinne ist kontrolle, darum geht es bei der normalisierung. ich wollte das noch mal betonen, weil man oftmals bei so vielen regeln vergisst, worum es eigentlich geht, sprich mehrgewinn in form von kontrolle, indem man die abhängigkeiten richtig auflöst. und mit dieser kontrolle verhindere ich viele der bekannten anomalien (update, insert, delete). und wenn man das sich noch mal vor augen führt, kann man auch diese frage:
Sicher handelt es sich dabei um eine andere "Art" von Daten - aber wo genau liegt deines Erachtens der Unterschied, ob ich nun bspw. den Namen der Person, die ein Bild hochgeladen hat, auslagere - oder eben die Info, dass das Bild, wie viele andere auch, eine Breite von 1024 Pixeln hat?
beantworten, nämlich weil der name einer person nicht von einem bild abhängt. diese person und somit auch den namen kann es ganz unabhängig vom dem hochgeladenen bild geben, sprich ich lager es aus. und ändert sich der name, dann ändert er sich "automatisch" auch in allen bilder, die er hochgeladen hat, wo wir dann wieder bei dem thema kontrolle/normalisierung angekommen sind. ich habe damit keine redundanzen entfernt, schließlich steht der name ja noch über seinen fremdschlüssel in vielen datensätzen drinne. das einzige was ich gemacht habe, ich habe die abhängikeiten unter kontrolle gebracht.
dazu ist im gegensatz die bildgröße direkt von dem bild abhängig und sollte dann auch nicht ausgelagert werden. ändert sich die bildgröße eines bildes, sollten sich ja nicht andere automatisch mit verändern. diese eigentschaft gehört zu dem bild, der name des hochladens tut genau das nicht.
gesetzt den fall, ich möchte NICHT, dass sich der name in der tabelle ändert, wer das bild hochgeladen, wenn sie der name der person ändert, dann lager ich den namen auch nicht über einen fremdschlüssel aus, sondern belasse ihn in der tabelle. bei der bild-tabelle mag das erst mal nicht sinnig erscheien, aber bei rechnungen sieht das schon ein wieder anders aus. dort will ich ja die alte rechnungsadresse niemals verändern, egal ob sich nun der name oder die adresse der person in der zukunft ändert.
du siehst, man geht nicht immer gleich vor, sondern ist von fall zu fall verschieden, aber eins gleicht sich immer, abhängikeiten für -> deine <- umgebung erkennen und kontrollierbar machen. diese abhängikeiten können von umgebung zu umgebung verschieden sein, sprich was für den einen ein richtiges daten-design ist, muss es nicht für den anderen sein. insofern kann und darf die normalisierung auch nicht immer zu den gleichen ergebnissen kommen, sondern steht in abhängigkeit zu der jeweiligen wiederzugebenen umgebung.
Normalisierung beschränkt sich auf die Auflösung von Beziehungen und Eigenschaften, je nachdem, aus welcher Richtung dur guckst.
und dann muss ich aus oben genannten gründen auch tom ein wenig widersprechen, es geht nicht um auflösen von beziehungen und eigenschaften, sondern eben um abhängikeiten und diese kontrollierbar zu machen.
Die typgerechte Auflösung von vernetzten Datenstrukturen bleibt dabei auf der Strecke.
auch da will ich widersprechen, aber nicht aus dem grund, weil ich immer dagegen bin. ;-) der datentyp ist immer die obermenge von den werten, die vorkommen können. je nachdem wich ich es modeliere, wähle ich dann den datentyp entsprechend aus.
Ndere Beispiele sind noch gravierender.
Versuch mal eine Artikeldatenbank eines EDV-Händlers mit Kenngrößen zu versorgen.
Prozessoren haben andere Kenngrößen als Festplatten.
Die Typen sind immer andere. Die Sortierung funktioniert daher anders.das liegt mehr an der "faulheit" des designs wenn ich es richtig trennen würde, dann würde ich objekte aus dem wirklichen leben wie prozessoren und festplatten nicht in eine entität zusammen führen, da sich ja wie du bereits gesagt hast, andere eingeschaften haben. und dann werden auch die datentypen entsprechend gesetzt, weil die menge der werte nun wieder unterschiedlich ist.
es gibt gründe, warum man es dennoch in eine tabelle zusammenfasse und es gibt gründe, warum ich es nicht tun würde. die entscheidung darüber trifft die jeweilige umgebung, sprich was will ich eigentlich. manchmal reicht es sie zusammenzufassen, manchmal muss ich sie als eigene entitäten designen.
Ilja
-
Hi Ilja,
und der mehrgewinn den ich durch normalisierung und andere prozesse gewinne ist kontrolle, darum geht es bei der normalisierung.
Danke, das (und die nachfolgenden Erklaerungen) leuchten ein.
gesetzt den fall, ich möchte NICHT, dass sich der name in der tabelle ändert, wer das bild hochgeladen, wenn sie der name der person ändert, dann lager ich den namen auch nicht über einen fremdschlüssel aus, sondern belasse ihn in der tabelle. bei der bild-tabelle mag das erst mal nicht sinnig erscheien, aber bei rechnungen sieht das schon ein wieder anders aus. dort will ich ja die alte rechnungsadresse niemals verändern, egal ob sich nun der name oder die adresse der person in der zukunft ändert.
Gut, aber in so einem Falle wird man in komplexeren Systemen dann doch eher zu einer Address-Tabelle mit Historie greifen, wuerde ich sagen.
(Und dabei haette man dann u.a. auch die Vermeidung redundanter (Text-)Information im Auge, wuerde ich behaupten wollen. Wenn ich ueber Jahre woechentlich Geschaefte mit dir mache, dann muss ich nicht in jedem Datensatz die Info, dass du in der Hauptstrasse 4711 in SELFEntenhausen wohnst, in Textform in jedem Datensatz ablegen.)MfG ChrisB
-
Hello,
(Und dabei haette man dann u.a. auch die Vermeidung redundanter (Text-)Information im Auge, wuerde ich behaupten wollen. Wenn ich ueber Jahre woechentlich Geschaefte mit dir mache, dann muss ich nicht in jedem Datensatz die Info, dass du in der Hauptstrasse 4711 in SELFEntenhausen wohnst, in Textform in jedem Datensatz ablegen.)
Das sehen die Vorschriften für ordnungsgemäße Rechnungslegung/Buchführung und die daraus abgeleiteten Bestimmungen für die elektronische Dokument-Archivierung anders. Jedes Dokument muss in sich abgeschlossen und vollständig sein.
Liebe Grüße
Tom vom Berg
--
Nur selber lernen macht schlau
-
Hi,
(Und dabei haette man dann u.a. auch die Vermeidung redundanter (Text-)Information im Auge, wuerde ich behaupten wollen. Wenn ich ueber Jahre woechentlich Geschaefte mit dir mache, dann muss ich nicht in jedem Datensatz die Info, dass du in der Hauptstrasse 4711 in SELFEntenhausen wohnst, in Textform in jedem Datensatz ablegen.)
Das sehen die Vorschriften für ordnungsgemäße Rechnungslegung/Buchführung und die daraus abgeleiteten Bestimmungen für die elektronische Dokument-Archivierung anders. Jedes Dokument muss in sich abgeschlossen und vollständig sein.
Zwischen der Datenhaltung im System und Dokumentarchivierung sollten wir hier trennen. Andernfalls wuerde, bei deiner Argumentation, selbst SAP mit seinen Produkten diese Anforderungen nicht einhalten :-)
MfG ChrisB
-
-
yo,
Gut, aber in so einem Falle wird man in komplexeren Systemen dann doch eher zu einer Address-Tabelle mit Historie greifen, wuerde ich sagen.
wir haben in unser system eine adress-historie, aber das eine hat mit dem anderen nichts zu tun. es gibt dort einen anderen merksatz, den ich meinen entwicklern immer wieder predige, was gleich aussieht muss nicht gleich sein.
ich sehe es wie tom und es geht wie bereits gesagt um abhängigkeiten. und die rechnungsadresse ist direkt abhängig von dem rechnungsdokument, sprich sie wird auch dort persistiert und zwar mit vollsändigen namen und adresse. sie darf nicht von anderen entitäten abhängig sein, auch nicht von irgendeiner adress-historie. du kannst es dir so vorstellen, dass sich eigentlich niemals wieder die rechnungsadresse ändert, die einmal in einem rechnungsdokument eingetragen wurde. und wenn mal die falsche aus versehen eingetragen wurde, dann darf eine änderung in einem dokument der adresse keine auswirkungen auf andere dokumente haben.
(Und dabei haette man dann u.a. auch die Vermeidung redundanter (Text-)Information im Auge, wuerde ich behaupten wollen. Wenn ich ueber Jahre woechentlich Geschaefte mit dir mache, dann muss ich nicht in jedem Datensatz die Info, dass du in der Hauptstrasse 4711 in SELFEntenhausen wohnst, in Textform in jedem Datensatz ablegen.)
erstens sagte ich ja bereits, dass durch normalsierumg keine redundanzen entfernt werden, das ist leider ein weit verbreiteter irrtum. zum anderen darf genau das nicht passieren, was du gerade schilderst. du "musst" (jeder kann letzlich das machen, was er für richtig hält) zwingend in jeder rechnung auch die rechnungsadresse persistieren.
Ilja
-
Hi,
ich sehe es wie tom und es geht wie bereits gesagt um abhängigkeiten. und die rechnungsadresse ist direkt abhängig von dem rechnungsdokument, sprich sie wird auch dort persistiert und zwar mit vollsändigen namen und adresse. sie darf nicht von anderen entitäten abhängig sein, auch nicht von irgendeiner adress-historie. du kannst es dir so vorstellen, dass sich eigentlich niemals wieder die rechnungsadresse ändert, die einmal in einem rechnungsdokument eingetragen wurde.
Gut, dann aendere ich die dort eingetragene, auf eine bestimmte Rechnungsadresse referenziernde ID im nachhinein also nicht mehr.
und wenn mal die falsche aus versehen eingetragen wurde, dann darf eine änderung in einem dokument der adresse keine auswirkungen auf andere dokumente haben.
Dann wird in der Adresshistorie also nicht editiert, sondern hoechstens hinzufuegend korrigiert (neuer Datensatz mit korrekter Adresse).
zum anderen darf genau das nicht passieren, was du gerade schilderst. du "musst" (jeder kann letzlich das machen, was er für richtig hält) zwingend in jeder rechnung auch die rechnungsadresse persistieren.
Wie gesagt, kenne ich aus den Datenmodellen im SAP-Umfeld anders.
MfG ChrisB
-
yo,
Gut, dann aendere ich die dort eingetragene, auf eine bestimmte Rechnungsadresse referenziernde ID im nachhinein also nicht mehr.
Dann wird in der Adresshistorie also nicht editiert, sondern hoechstens hinzufuegend korrigiert (neuer Datensatz mit korrekter Adresse).
grundsätzlich ist es so, dass man viele möglichkeiten hat, sein daten-design zu entwickeln. so ist es durchaus denkbar, vieles mit nur einer tabelle abzubilden. und auch dein weg würde funktionieren, wenn man bestimmte regeln einführt und sich daran hält.
die frage ist aber, welches ist ein optimales design für meine individuelle umgebung. mal davon abgesehen, dass sich darüber vortrefflich streiten läßt, ohne jemals zu einem gemeinsamen ergebniss kommen zu müssen, ist die normalsierung ein weg, zu diesem ziel zu gelangen. es ist kein muss, aber oftmals doch ein guter ratgeber. man darf sich also nicht nur von der frage leiten lassen, ob etwas geht, viele wege führen nach rom. vielmehr interessiert die frage, was ist das beste design für mich.
und was du vorschlägst verstösst meiner meinung nach gegen die normalisierung, wobei ich nicht alle "hunderte" regeln kenne, aber bleiben wir mal bei den ersten 3, bzw. 4. wie gesagt modeliert man ja nach abhängigkeiten. und du lagerst etwas aus, was zur entität dokument/rechnung gehört. damit es dann wieder funktioniert und du dir keine anomalien einhandelst, musst du zusätzlich bestimmte regelungen einführen, die du dann in jeder applikation implementieren musst, bzw. du musst dich ja auch davor schützen, dass jemand das direkt auf datenbank-ebene macht.
wie gesagt würde das gehen, aber ist das wirklich ein -> mehrgewinn <- für mich oder doch eher ein nachteil ? ich würde natürlich sagen letzteres. man muss zusätzlich regeln beachten, die man eigentlich gar nicht beachten will oder bräuchte, wenn ich es anderes modelieren würde.
lass mich mal ein anderes beispiel anführen, was genau das gleiche macht wie dein vorschlag. stell dir eine einfache kundentabelle vor. dort gibt es unter anderem den nachnamen der kunden. nun kommen die meiers und die müllers als name schon mal öfters vor. also kommt ein mitarbeiter auf die idee, die nachnamen in eine extra tabelle auszulagern und darauf dann entsprechend zu referenzieren. auch dafür würde ich keinen grund sehen, das zu tun, ich hole mir damit nur einen nachteil in das boot.
und um es noch ein wenig auf die spitze zu treiben, selbst wenn meine vorgabe ist, eine extra tabelle mit nachnamen zu führen, die alle möglichen nachnamen enthält, aus denen dann ein nachname ausgewählt werden muss, selbst dann würde ich nicht über einen fremdschlüssel darauf referenzieren, sondern es fest persistieren. die begründung dafür ist immer die die gleiche, nämlich die abhängikeit des nachnames zu der person.
ich würde ja eine kontrolle durch die auslagerung schaffen, wo ich dann mit zusätzlichen regeln dafür sorgen muss, dass diese kontrolle gar nicht benutzt werden darf. oder um es mal umgangssprachlich auszudücken, ich kaufe mir ja nicht etwas, was ich dann gar nicht benutzen darf, weil es mir schaden zufügen könnte.
Wie gesagt, kenne ich aus den Datenmodellen im SAP-Umfeld anders.
auch SAP kocht nur mit wasser ;-)
Ilja
-
Hi,
lass mich mal ein anderes beispiel anführen, was genau das gleiche macht wie dein vorschlag. stell dir eine einfache kundentabelle vor. dort gibt es unter anderem den nachnamen der kunden. nun kommen die meiers und die müllers als name schon mal öfters vor. also kommt ein mitarbeiter auf die idee, die nachnamen in eine extra tabelle auszulagern und darauf dann entsprechend zu referenzieren.
Da wird die Absurditaet natuerlich offensichtlich ...
die begründung dafür ist immer die die gleiche, nämlich die abhängikeit des nachnames zu der person.
Gut, kann man mit der Begruendung natuerlich fuer Rechnung und zugehoerige Adresse genauso sehen, leuchtet ein.
auch SAP kocht nur mit wasser ;-)
Manchmal nicht mal das ...
Ich habe wirklich, ungelogen beim Hinein-Debuggen in den ABAP-Code eines SAP-eigenen Moduls mal im Code eine Kommentarzeile mit in etwa dem Wortlaut
* Warum das so gemacht wird, weiss ich auch nicht, aber XY sagt, das muss so sein
vorgefunden ...
MfG ChrisB
-
yo,
Gut, kann man mit der Begruendung natuerlich fuer Rechnung und zugehoerige Adresse genauso sehen, leuchtet ein.
abhängikeit und konntrolle sind die beiden kriterien, die meiner meinung nach die stichwörter für ein gutes daten-design sind. und mein tipp für dich ist, dich daran zu halten. alles andere wird schwierig.
Ich habe wirklich, ungelogen beim Hinein-Debuggen in den ABAP-Code eines SAP-eigenen Moduls mal im Code eine Kommentarzeile mit in etwa dem Wortlaut
* Warum das so gemacht wird, weiss ich auch nicht, aber XY sagt, das muss so sein
mein motto ist, sich selbst eine meinung machen ist immer besser, als grossen namen zu vertrauen ;-)
Ilja
-
-
-
-
-
-
-
-
-
-