Maar om op die db terug te komen: ik snap 'm niet. Je hebt twee tabellen met
identieke velden (Boeken en Cassetteboeken). Dát is dus een schoolvoorbeeld van een verkeerde opbouw. Als je een database gaat ontwerpen, moet je denken in
entiteiten. Een entiteit is een object van een bepaald type. Een entiteit wordt bepaald door
overeenkomende eigenschappen. Een boek is zo'n objecttype, en een doos is een ander. Kijk ik naar jouw twee tabellen, dan hebben ze
dezelfde velden, en daarmee geef je overduidelijk aan dat het
identieke objecten zijn. Van die objecten leg je dus dezelfde eigenschappen vast, en derhalve kan er maar één conclusie zijn: je hebt genoeg aan één tabel.
Daarnaast geldt min of meer hetzelfde voor de tabellen Doos en Cassette. Ook dát zijn (bijna) identieke objecten. Ook daarvoor heb je dus maar één tabel nodig. Al leg je van een cassette ook de kleur vast, wat mij eerlijk gezegd verbaast, want probeer jij maar eens een doos te kopen die géén kleur heeft
. Dus waarom de kleur van de doos niet vastleggen?
Ik vermoed verder dat je cassettes opslaat in dozen (ik hoop voor je dat dat altijd past
), maar zelfs met die constructie kun je nog met één tabel volstaan. In dat geval voeg je namelijk aan die tabel een veld ParentID toe, zodat je bij de cassettes aangeeft in welke doos ze zitten. Kortom: ik zou nog eens nadenken over de huidige opzet.
En uiteraard mis ik de tabel waarin je de objecten Boek en Doos/Cassette (verzin daar nog een passende naam voor) koppelt. Dus één boek zit in één doos, maar één doos/cassette kan meerdere boeken bevatten. Koppeltabel dus.
