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