Wir diskutieren gerade in einem Projekt über ein Problem der Datenablage in einer Tabelle und kommen zu keiner Übereinstimmung. Das Problem ist folgendes:
Eine Tabelle hat vier Spalten. Spalte 1 ist „Vorgang“ und der Primary Key. Spalte 2 heißt „Liefersystem“, Spalte 3 „Produkttyp“, Spalte 4 „Marktwert“.
In Abhängigkeit des Wertes in „Liefersystem“ ist entweder „Produkttyp“ oder „Marktwert“ gefüllt und das jeweilige andere Feld hat leer bzw. NULL zu bleiben. Die Felder „Produkttyp“ bzw. „Marktwert“ sind also abhängig von „Liefersystem“ bzw. dessen Inhalt.
Ist das ein Verstoß gegen die Normalisierungsregeln (evtl. 3.NF)? Oder ist es aus praktischen oder Performance-Gründe sinnvoll, diese Konstellation in der Datenbank zuzulassen?
wenn ich mich recht entsinne, wäre es ein verstoß gg. die 3.nf - allerdings sind meine theoretischen kenntnisse über normalisierungen aufgrund der praxis irgendwie aus dem gedächtnis gelöscht worden (nur weil es sich um die 3. normalform handelt, bedeutet dies noch lange nicht, das das ganze wartbarer und perfomanter wird)
dieser falls (wenn feld1=x dann hat nur feld2 einen wert, ansonsten nur feld3) tritt bei uns sehr häufig auf und wird in einer tabelle einerseits mittels constraints, andrerseits in der applikation selber definiert
grüße,
tomh
ps: wenn mich nicht alles täuscht, dann müßte es in der 3.nf noch 2 detail-tabellen für die beiden zustände des feldes „liefersystem“ geben …
nicht Tabellen, sondern Entitäten sind das Objekt der Normalisierung. In der Tabellenwelt ist also alles erlaubt, ob Normalform oder nicht - deswegen wird ja gerade zwischen Modell und Umsetzung unterschieden.
Nach der reinen Lehre habt Ihr 2 Typen von Vorgängen: Solche, die durch den Produkttyp beschrieben werden, und andere, die einen Marktwert tragen; die Teilmengen werden durch das Liefersystem unterschieden. In klassischer ERM-(entity relationship model)Darstellung sähe das so aus:
VORGANG VORGANG-P PRODUKTTYP
VORGANG-M MARKTWERT
So ein Modell dient der Klärung der fachlichen Gegebenheiten, die oft wesentlich komplexer sind als in diesem Fall. Niemand hält Dich davon ab, das Ganze in einer Tabelle mit entsprechenden Regeln zu realisieren.