Ist meine Tabelle in der 3. NF?
- Themenstarter adfa
- Beginndatum
Ich konnte die NF noch nie auswendig, da ich die Theorie nie gelernt habe und meine ganzen DB-Kenntnisse aus der Praxis habe. Bin aber auch kein Architekt, ergo ists egal, da ich die Tabellenstruktur bekomme.
Aber was ganz anders. Überdenke die Tabellennamen.
Verwende wnn möglich keine Umlaute, mach Tabellennamen die was aussagen. hat,besteht,gehört. Wenn das später mal kein Chaos gibt....
Aber was ganz anders. Überdenke die Tabellennamen.
Verwende wnn möglich keine Umlaute, mach Tabellennamen die was aussagen. hat,besteht,gehört. Wenn das später mal kein Chaos gibt....
Wie yaslaw scjhon schrieb, die Tabellennamen unbedingt überdenken.
Zu dem würde ich folgende Tabellen zusammenfassen:
[bestellt] [hat] [rechnung]
scheint mir eine rechnungstabelle zu sein.
bei [bearbeitet] frage ich mich ob nciht ein fremdschlüssel auf die rechnung besser wäre.
Die Spaltenangaben sagen, mir, leider zu wenig aus ums differenzierter sagen zu können.
Zu dem würde ich folgende Tabellen zusammenfassen:
[bestellt] [hat] [rechnung]
scheint mir eine rechnungstabelle zu sein.
bei [bearbeitet] frage ich mich ob nciht ein fremdschlüssel auf die rechnung besser wäre.
Die Spaltenangaben sagen, mir, leider zu wenig aus ums differenzierter sagen zu können.
BaseBallBatBoy
Erfahrenes Mitglied
Ein paar Bemerkungen:
- Meinem Verständnis nach ist nicht das Fahrrad zentral, sondern die Rechnung
- Zudem: wie bildest du ab, wenn jemand 2x den Artikel 2948 mit einer Lieferung kaufen will?
- Mit den Tabellennamen haben die anderen beiden recht. Mach sie sprechender und entscheide dich für Ein- oder Mehrzahl. Gilt auch für Spaltennamen entweder Nr oder Nummer. Bleibe konsistent. Zudem Fahrradname in der Fahrrad Tabelle ist überflüssig. Es ist ja schon implizit mit dem Tabellennamen klar, worum es sich beim Namen handelt. Ansonsten endest du mit so sinnlosen queries wie select Fahrrad.Fahrradname form Fahrrad; Da ist doch select Fahrrad.Name from Fahrrad; viel sprechender
- Man kann sich noch überlegen auch für die Zwischentabellen einen PK einzufügen
- Meinem Verständnis nach ist nicht das Fahrrad zentral, sondern die Rechnung
- Zudem: wie bildest du ab, wenn jemand 2x den Artikel 2948 mit einer Lieferung kaufen will?
- Mit den Tabellennamen haben die anderen beiden recht. Mach sie sprechender und entscheide dich für Ein- oder Mehrzahl. Gilt auch für Spaltennamen entweder Nr oder Nummer. Bleibe konsistent. Zudem Fahrradname in der Fahrrad Tabelle ist überflüssig. Es ist ja schon implizit mit dem Tabellennamen klar, worum es sich beim Namen handelt. Ansonsten endest du mit so sinnlosen queries wie select Fahrrad.Fahrradname form Fahrrad; Da ist doch select Fahrrad.Name from Fahrrad; viel sprechender
- Man kann sich noch überlegen auch für die Zwischentabellen einen PK einzufügen
Zuletzt bearbeitet:
Und noch ein paar Bemerkungen....
Wenn in diesem kleinen Tabellenkosmos wirklich Bestellungen und Rechnungen abgebildet werden sollen, dann muss minimal diese "Fahrrad-Stammdaten"-Tabelle einen Zeitbezug bzw. GültigVon und GültigBis-Datunsfelder bekommen.
Weil:
- Ein Fahrrad mit der "Fahrradnummer" 4711 ist vielleicht heute nicht mehr bestellbar, aber ist durchaus ein gültiger und nötiger FK für Rechnungen aus den letzten Jahren.
- aber du kannst in deinem Tabellen-Konstrukt keinen "Fahrrad"-Datensatz jemals löschen, nur weil dieses Fahrrad heute nicht bestellbar ist.
(Ebenso gilt das für Mitarbeiter: du brauchst die MA, die letztes Jahr noch bei einer Bestellung zuständig waren und heute ihre Rente auf Mallorca verbraten.
Aber genau diese MA kannst/darfst du heute nicht mehr bei einer neuen Bestellung zuordnen bzw. bei einer Auswahl "zuständiger MA für Bestellung" nicht mehr sehen)
Wie BaseBallBatBoy schon schrieb - die Entität "Rechnung" ist viel zentraler als diese Entität Artikel/Fahrrad und das sollte berücksichtigt werden.
Ebenfalls mal zu überdenken - wie ist die Beziehung zwischen Rechnung/Fahrrad/Komponenten?
1:1? 1:n? m:n?
Die Beispiele, die du gegeben hast suggerieren:
1 Fahrrad mit 1...n Kompnenten sind auf 1 Rechnung.
Okay, zur Not auch 2 Fahrräder mit je 1...n Komponenten auf einer Rechnung.
Aber andere Use Cases?
Kann auch 1 Fahrrad mit 3 Komponenten auf 2 Rechnungen verteilt sein (eine Komponente "Designersattel Daniela" kann erst in 2 Monaten geliefert werden, das Fahrrad innerhalb von drei Werktagen) ?
Kann auch ein Sportlenker (=Komponente) ohne ein ganzes Fahrrad bestellt werden?
Und wenn nein, akzeptiert der Kunde die Begründung "Das geht nicht, ich bin in der 3 NF"?
Hat jede Komponente zwingend einen Bezug zu genau einem Fahrrad?
An diesern Sollbruchstellen würde ich noch ein paar Minuten Zeit investieren.
Grüße
Biber
Wenn in diesem kleinen Tabellenkosmos wirklich Bestellungen und Rechnungen abgebildet werden sollen, dann muss minimal diese "Fahrrad-Stammdaten"-Tabelle einen Zeitbezug bzw. GültigVon und GültigBis-Datunsfelder bekommen.
Weil:
- Ein Fahrrad mit der "Fahrradnummer" 4711 ist vielleicht heute nicht mehr bestellbar, aber ist durchaus ein gültiger und nötiger FK für Rechnungen aus den letzten Jahren.
- aber du kannst in deinem Tabellen-Konstrukt keinen "Fahrrad"-Datensatz jemals löschen, nur weil dieses Fahrrad heute nicht bestellbar ist.
(Ebenso gilt das für Mitarbeiter: du brauchst die MA, die letztes Jahr noch bei einer Bestellung zuständig waren und heute ihre Rente auf Mallorca verbraten.
Aber genau diese MA kannst/darfst du heute nicht mehr bei einer neuen Bestellung zuordnen bzw. bei einer Auswahl "zuständiger MA für Bestellung" nicht mehr sehen)
Wie BaseBallBatBoy schon schrieb - die Entität "Rechnung" ist viel zentraler als diese Entität Artikel/Fahrrad und das sollte berücksichtigt werden.
Ebenfalls mal zu überdenken - wie ist die Beziehung zwischen Rechnung/Fahrrad/Komponenten?
1:1? 1:n? m:n?
Die Beispiele, die du gegeben hast suggerieren:
1 Fahrrad mit 1...n Kompnenten sind auf 1 Rechnung.
Okay, zur Not auch 2 Fahrräder mit je 1...n Komponenten auf einer Rechnung.
Aber andere Use Cases?
Kann auch 1 Fahrrad mit 3 Komponenten auf 2 Rechnungen verteilt sein (eine Komponente "Designersattel Daniela" kann erst in 2 Monaten geliefert werden, das Fahrrad innerhalb von drei Werktagen) ?
Kann auch ein Sportlenker (=Komponente) ohne ein ganzes Fahrrad bestellt werden?
Und wenn nein, akzeptiert der Kunde die Begründung "Das geht nicht, ich bin in der 3 NF"?
Hat jede Komponente zwingend einen Bezug zu genau einem Fahrrad?
An diesern Sollbruchstellen würde ich noch ein paar Minuten Zeit investieren.
Grüße
Biber
Parantatatam
mag Cookies & Kekse
Biber3 hat zwar die ganze Sache schon sehr weit gedacht, aber aus meiner Sicht noch nicht ganz zu Ende, denn ist ein Fahrrad nicht eigentlich auch eine Art Komponente? Oder sind Komponenten und Fahrrad doch zwei Dinge, die sich jedoch unter einem Übergriff – e.g. Produkt – sammeln. Somit könntest Du nämlich auch Komponenten ohne ein Fahrrad kaufen.
Nachtrag: Ich habe mal kurz selber eine Datenbankstruktur für dieses Problem aufgestellt:
Fahrräder
Nachtrag: Ich habe mal kurz selber eine Datenbankstruktur für dieses Problem aufgestellt:
Fahrräder
- ID
- Name
- Herstellungsdatum
- ID
- Gewicht
- Preis
- ID
- Name
- ID
- Name
- ID
- Name
- ID
- Mitarbeiter_ID
- Kunde_ID
- Rechnung_ID
- Komponente_ID
- Komponente_ID
- Komponentengruppe_ID
- Fahrrad_ID
- Komponente_ID
Zuletzt bearbeitet:
BaseBallBatBoy
Erfahrenes Mitglied
@crack
Guter Vorschlag. Nachtrag zu Rechnungen_Komponenten. Ich würde soetwas eher Rechnungspositionen nennen und dann käme da noch eine Spalte für die Bestellmenge dazu. Und die Rechnung selber hat wohl noch ein Bestelldatum.
Guter Vorschlag. Nachtrag zu Rechnungen_Komponenten. Ich würde soetwas eher Rechnungspositionen nennen und dann käme da noch eine Spalte für die Bestellmenge dazu. Und die Rechnung selber hat wohl noch ein Bestelldatum.
Parantatatam
mag Cookies & Kekse
@BaseBallBatBoy: Ich habe mich bei der Benennung an die Rails-Nomenklatur gehalten, zumindest beinahe. Dort werden alle Tabellennamen im Plural angegeben, Spaltennamen im Singular und Hooktables bestehen aus dem Namen der ersten und der zweiten Tabelle, verbunden durch einen Unterstrich, wobei die Namen der beiden Ursprungstabellen alphabetisch geordnet sind. Daher kommt bei mir dieser Name. Außerdem finde ich auch, dass man so schneller sieht, welche Tabellen miteinander verbunden sind.
