nicht angemeldet
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