Opgelost Nieuwe database goed genormaliseerd?

Dit topic is als opgelost gemarkeerd
Da’s heel simpel: nergens aan :). Laat ik het demonstreren met een aantal voorbeeldjes. Het begint met een tabel met minstens deze velden:
1. CatID (Autonummer)
2. Naam (Tekst)
3. ParentID (Numeriek)

Stel je hebt een aantal hoofdcategoriën. Die voer je dan zo in: (CatId en Naam)
1 - Groente
2 - Fruit
3 - Zuivel

Daar vallen meerdere subcategorieën onder, bijvoorbeeld in de categrorie Fruit. Dat voer je dan zo in: (CatId, Naam en ParentID)
4 - Appel - 2
5 - Peer - 2
6 - Citrusvrucht - 2
7 - Melk - 3
8 - Yoghurt - 3

Vervolgens ga je ook gebak verkopen, dat is weer een hoofdcategorie. Dus dat voer je ook in;
9 - Gebak

En dan krijg je wat nieuwe subcategorieën:

10 - Juno - 4
11 - Goudrenet - 4
12 - Vol - 7
13 - Halfvol
14 - Moorkop - 9
15 - Tompouce
16 - Cake - 9
17 - Boerencake - 16
18 - Marmercake - 16

En zo bouw je het systeem door. Er zit dus geen limiet aan de hoeveelheid (sub)categorieën die je kunt invoeren en nesten. Op je formulier begin je dan met het kiezen van de hoofdcategorie (alles zonder ParentID is hoofdcategorie) en met die keuze filter je de tweede keuzelijst. De keuze in de tweede keuzelijst filtert de derde keuzelijst en zo verder. Zelf verberg ik alle keuzelijsten (behalve de eerste natuurlijk) en maak ik de volgende keuzelijsten zichtbaar als er records voor zijn. Wél moet je er natuurlijk voor zorgen dat er voldoende keuzelijsten zijn voor alle niveaus;).
 
Momenteel ben ik bezig met het maken van een auteurstabel, die ik ga koppelen aan mijn boekentabel. Allereerst verwerk ik de auteurs van de AO-reeks, dat zijn ongeveer 800 verschillende auteurs. Het komt voor dat een auteur een student was toen hij zijn eerste boekje schreef. Het tweede boekje kwam er toen hij/zij was afgestudeerd en inmiddels een titel had. Ik kan deze persoon een keer opvoeren met een titel en een keer zonder. Maar in feite vervuil je dan de database. Hoe los je dit het beste op?

Alvast bedankt voor het meedenken.

Henk
 
Ik vraag me af of je daar uit gaat komen en of de eventuele inspanning waard is.

Het dubbel opnemen is inderdaad niet zuiver. Het gaat immers over dezelfde persoon.
Een optie is om een tabel te koppelen aan de auteurstabel (TitelAuteur) waarin je de titel(s) vastlegt; de auteur kan in de loop der tijd meerdere titels vergaren.
Om te kunnen bepalen of je de naam met of zonder titel moet tonen bij een bepaald boek zou je moeten weten wat de publicatiedatum van het boek is en sinds wanneer de auteur de titel draagt (en dat weet je waarschijnlijk niet).
Bijkomend probleem zijn herdrukken; wat is bepalend? De datum van publicatie van de herdruk (toen gold de titel wel) of de datum van publicatie van de eerste druk (toen er nog geen titel was)? En welke druk heb je?
Kortom, ik zou er niet te veel moeite in stoppen en in de auteurtabel een veld titel(s) opnemen met alle nu bekende titels. Bij het tonen van een auteur laat je die bijvoorbeeld tussen haakjes zien.

Vergeet het voorgaande

Enne, bij het koppelen van auteurs en boeken ga je neem ik aan toch wel uit van een veel-op-veel koppeling (een auteur kan meerdere boeken hebben geschreven, een boek kan door meerdere auteurs zijn geschreven)?
 
Laatst bewerkt:
Hoe meer (losse) informatie je van een tupel (auteurs, boeken zijn tupels in een database) wilt vastleggen, hoe meer je moet nadenken over wát je van die informatie wilt hebben. En hoe belangrijk dat is voor je systeem. Als het voor jou relevant is om te weten welke status een auteur had (wel of geen titel, wel of geen literaire prijs) dan zul je dat op moeten slaan, en dat kan op twee manieren: in dezelfde tabel, of in een gekoppelde tabel.
Het eerste heeft voordelen (snel aan te passen in het systeem, redelijk foutloos in te voeren) maar heeft als nadeel dat je van dat specifieke gegeven geen 'losse' informatie hebt. Want als je wilt weten of iemand een titel heeft of niet, dan moet je dat per boek dus weten.

In dit kader zijn er denk ik twee mogelijkheden: ofwel je zet in de auteurs tabel een Ja/Nee veld met titel, en daarmee vergeet je dus het opslaan per boek, of je zet in de tabel Boeken een Ja/Nee veld met Titel. Dan moet je dus, elke keer als je voor die auteur een nieuw boek invoert, dat vinkje aanvinken. En dat moet je op dat moment dus wél in het achterhoofd hebben.
Zelf zou ik, als ik de tweede variant zou doen, dat enigszins automatiseren. Op dezelfde manier als ik prijzen in een bestellingen tabel zet. Dat gaat relatief simpel: als je een nieuw boek invoert, gebruik je de auteurs tabel om de auteur op te zoeken. In die keuzelijst zet je ook het Titel veld. Bij het kiezen van de auteur wordt dan het Titel veld ingevuld (Ja of Nee, afhankelijk van wat er in de Auteurs tabel staat). Dus als een auteur nog geen titel heeft, blijft het selectieveld leeg, en heeft de auteur wél een titel, dan wordt het veld aangevinkt.

In dit systeem hoef je dus maar één keer bij een auteur aan te geven dat hij een titel heeft gekregen, en vanaf dat moment worden alle nieuwe boeken automatisch correct ingevuld. En je kunt dus altijd zien welke boeken wél en welke níet onder titel zijn geschreven. E.e.a. heeft uiteraard niets met (her)drukken te maken; het gaat om het moment van schrijven, en al zijn er 300 herdrukken: dat verandert niets aan het feit dat de auteur op het moment van schrijven zijn bul had. Of niet.

Andere opties zijn overigens ook mogelijk :).
 
Nieuwe ingeving!

Naar aanleiding van het verhaal veel-op-veel realiseerde ik me dat je daarvoor een koppeltabel (AuteurBoek) nodig hebt. De titel(s) van de auteur kan je daar in opslaan. Je kan dan precies vastleggen bij welk boek de auteur welke titel(s) had.
 
Laatst bewerkt:
Nieuwe ingeving? Ik dacht dat we dat al 30 berichtjes geleden hadden getackeld? Daar is in ieder geval mijn antwoord wel op gebaseerd :).
 
Beste forum-leden,

Hartelijk dank nog voor de suggesties over het boekengedeelte. Ik heb bij de AO-reeks gemerkt, dat de titel van de auteur niet altijd juist is vermeld. Dat betekent, dat ik elk AO-boekje ga controleren op de juistheid van de (auteur).

Inmiddels heb ik de database verder uitgebreid met een video- en een audiogedeelte. Daar heb ik enkele voorbeelden uitgewerkt. Die staan in het bijgevoegde bestand. Graag verneem ik van jullie of ik op de goede weg ben.

Met vriendelijke groeten,

Henk
 

Bijlagen

  • Mediatheek_2024.rar
    441,8 KB · Weergaven: 3
Kan je hier ook een schematisch voorbeeld laten zien? Ik weet veel over databasenormalisatie, maar ik gebruik geen Access.
 
Beste Aar,

Hierbij een knipsel van de relaties in mijn database.

Met vriendelijke groet,

Henk
 

Bijlagen

  • Gedeelte_mediadatabase_2024_12032024.png
    Gedeelte_mediadatabase_2024_12032024.png
    97,2 KB · Weergaven: 5
Graag verneem ik van jullie of ik op de goede weg ben.
Ik denk dat je wel een beetje erg optimistisch bent als je denkt dat iemand dit model nog zonder enige uitleg kan begrijpen of daar moeite voor zou willen doen. Denk je nu echt dat we een model met zo'n 50 tabellen met welluidende namen als DVD_combiafleveringinformatiedragerstype_5 even helemaal gaan doorspitten?

Het feit dat we inmiddels bij post #51 zijn aangeland laat zien dat we best van goede wil, maar er zijn grenzen. En ik denk dat je hard op weg bent naar de grens .........
 
Ik zit nu in het Relaties scherm naar je tabellen te kijken, maar wat een zooitje is dat; daar kun je toch niet mee werken? Laat staan dat daar fatsoenlijke adviezen voor te geven zijn. Er zijn sterrenstelsels die simpeler in elkaar zitten.

Maar goed, je vraag ging over normaliseren, en deze tabel kun je daar wel als uitgangspunt voor nemen: [Boeken_Auteurs]. Bekijk het plaatje maar eens.

Tabelontwerp Auteurs.png

In de Access cursus in de Handleidingen sectie kun je prima lezen wat normaliseren inhoudt op de drie belangrijkste normaalvormen, en deze tabel is een mooi voorbeeld van de 1e normaalvorm: herhalende gegevens die niet afhankelijk zijn van de sleutel.

Ik snap de bedoeling van deze tabel (sommige boeken zijn geschreven door meerdere auteurs) en ik snap dat je dat wil vastleggen. Maar dit is niet de manier, want je kunt op deze manier nooit één auteur aan meerdere boeken koppelen. Auteurs plaats je in een eigen tabel (Auteurs) en boeken zet je in een eigen tabel. In die tabel leg je alle vaste boekgegevens vast. Vervolgens hoef je in de koppeltabel alleen maar per record een BoekID vast te leggen en een auteurID. Heb je 5 auteurs, dan krijg je 5 records, heb je er twee, dan twee. En 12 auteurs is dus net zo makkelijk als 3 auteurs. In jouw tabel is dast niet mogelijk.

Kortom: deze tabel is niet genormaliseerd. En zo zijn er vast meer. En volgens mij heb je ook veel te veel tabellen voor vergelijkbare gegevens, dile de overzichtelijkheid ook bepaald niet bevorderen.

En als laatste: je vraag begint nu al behoorlijk af te wijken van de oorspronkelijke vraag, die m.i. al lang en breed is beantwoord. Maak dus een nieuwe vraag aan, als je andere zaken behandeld wilt zien hier, want op deze manier kan het forum niet goed werken. En het onderwerp van je vraag komt ook al lang niet meer overeen met wat je nu wilt weten. Dus: begin een nieuwe vraag :).
 
Beste Peter en Michel,

Het is duidelijk, wat jullie zeggen. Bedankt voor jullie op en aanmerkingen. Ik sluit dit topic af. Als ik een nieuwe vraag heb, start ik een nieuw topic. Deze zet ik op opgelost.

Met vriendelijke groet,

Henk
 
En doe jezelf een lol, en maak om te beginnen aparte databases voor je muziek, films en boeken. Het zijn verschillende onderwerpen die weinig gemeen hebben, al zijn er uiteraard wel muzikanten te vinden die af en toe een boek schrijven, of schrijvers die wel eens een cd-tje opnemen. Maar die uitzonderingen zullen niet zodanig zijn dat je daarvoor één database zal willen maken.
 
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan