Kan deze muziekdatabase efficiënter worden gemaakt?

H

Hevoolst

Gebruiker
Lid geworden
25 nov 2007
Berichten
75
Dag allemaal,

Mijn oorspronkelijke database heb ik in onderdelen gesplitst. Dit is de muziekdatabase. Als eerste onderdeel staat hier de 10 delige serie "De jaren 70", die Radio 2 in de jaren 90 heeft uitgebracht. De database is opgebouwd via diverse sporen

Het eerste spoor is de serie die uit 10 albums bestaat. Op die albums staan verschillende nummers van verschillende artiesten. Een tabel met nummers en een met artiesten zijn via combitabellen aan elkaar gekoppeld.

Het tweede spoor zijn de nummers, die tot een bepaald album horen.

Het derde spoor zijn de kenmerken van de CD's: 2 per album. Op elke cd staan 20 tracks, die elk een bepaalde lengte hebben en een volgorde op de cd Via een combitabel worden de tracks aan de nummers gekoppeld.

Het vierde spoor is de jewelcase, waarin de 2 cd's zijn opgenomen. Ook is er een booklet in de jewelcase.

Het vijfde spoor is de plank in een kast, waarin de booklets staan. Zien jullie nog mogelijkheden om het aantal tabellen te beperken?

Met vriendelijke groeten,

Henk
 

Bijlagen

  • Muziekdatabase_13032024.rar
    156,4 KB · Weergaven: 7
  • Muziektracks_muziekalbum_artiesten.png
    Muziektracks_muziekalbum_artiesten.png
    56,6 KB · Weergaven: 15
  • Vertrek_kast_plank_jewelcase_informatiedragerstype_track_1.png
    Vertrek_kast_plank_jewelcase_informatiedragerstype_track_1.png
    63,3 KB · Weergaven: 13
Ik denk zeker dat het aantal tabellen te beperken is. Zekerheidjes zijn wat mij betreft in ieder geval:
  • Een plank kan maar in één kast zitten, dus een 1-op-veel relatie tussen kast ben plank volstaat en een "combitabel" om een veel-op-veel relatie te realiseren is overbodig.
  • Een album hoort maar bij één serie, dus...
  • Een jewelcase kan maar op één plank liggen/staan, dus...
  • De tabel "informatiedragertype" snap ik niet goed; als ik zo naar de relaties kijk, lijkt het meer bedoeld als "informatiedrager" ("schijf"). In dat geval:
    • Een informatiedrager zit maar in één jewelcase, dus...
    • Een "informatiedragertrack" staat maar op één informatiedrager, dus...

Op een aantal aspecten zet ik vraagtekens:
  • Is een jewelcase wat anders dan een album? Een album i.c. de schijven van een album zit(ten) toch in een jewelcase, dus zou één tabel kunnen volstaan.
  • Is een muziektrack iets anders dan een informatiedragertrack?
  • Je koppelt artiesten zowel aan tracks. Dat vind ik een lastige. Voor het type albums (verzamelaars) dat je beschrijft, heb je geen koppeling tussen album en artiest. Er staan tracks van allerlei artiesten op, dus zou je de artiest alleen aan de track hoeven koppelen (krijg ik hier een déjà vu? 😁)
 
xps351 zei:
Een album hoort maar bij één serie, dus...
Klik om te vergroten...
Met de meeste opmerkingen ben ik het wel eens (ik ben al een aantal keer bezig geweest met wat aanpassingen op dat gebied), maar met deze dus niet helemaal; één plaat/album kan als zodanig best wel in meerdere series zitten. De vraag is natuurlijk of dat nuttige informatie is; je kunt ook teveel willen opslaan. Informatie die nergens toe leidt, kun je beter weglaten.

@TS:
De tabel Jewelcase (en de afgeleide koppel tabellen) vind ik ook overbodig; je kunt immers een album óók op Vinyl hebben, of in een DVD formaat doos. Het is veel makkelijker en handiger om in de tabel Albums op te nemen wat de drager is; uiteindelijk is dát wat je per album wilt weten. Dus in de tabel Albums een extra veld Drager, met een keuzelijst CD, Vinyl, DVD (desnoods ook Cassette en/of Tape) etc. en je bent helemaal klaar.
Een album kan uiteraard uit meerdere schijven bestaan. Jij legt dat in de tabel Jewelcase vast, maar ook dat is niet handig. Een album bevat immers liedjes, dus je hebt sowieso een tabel Album_Songs nodig. In die tabel neem je niet alleen de Album_FK op, maar leg je ook vast op welke cd/plaat dat staat. Bij een album met 4 cd's nummer je dus met 1-4 in dat veld. Elk liedje heeft uiteraard een tijdsduur, maar die mis ik bij jouw liedjes tabel. Vreemd. Dat staat dan weer wel in een (in mijn ogen verder overbodige) tabel Informatiedragertrack.

Wat mij ook bevreemdt: je hebt per liedje velden voor alarmschijf etc, maar dat gaat toch niet werken? In jouw opzet zijn de liedjes uniek, maar dat zijn ze natuurlijk niet. Als een artiest een liedje covert, heeft die uitvoering eigen gegevens. Die hoor je dus gescheiden op te slaan.

Eerste indruk: veel te veel, en verkeerde tabellen. En ook nog eens verkeerde veldtypes voor je sleutelvelden, wat het koppelen er niet makkelijker op maakt. Gebruik Autonummervelden voor je sleutelvelden, en koppel ze met numerieke velden van het type Lange Integer. Geheid dat je daar de komende 300 jaar mee vooruit kan :).
 
Beste Michiel en Peter,

Bedankt voor jullie opbouwende kritiek. Ik ga het verwerken in het aangepaste ontwerp van mijn muziekdatabase. Zodra ik dat klaar heb, post ik het hier opnieuw met uitleg van de keuzes.

Met vriendelijke groet,

Henk
 
Dat laatste scheelt hopelijk, al zou je het Functioneel Ontwerp natuurlijk al lang en breed klaar moeten hebben, dat is immers het uitgangspunt van je ontwerp. Dus dat moet je nu al kunnen posten :).
 
Zeker, maar dat pas ik nu juist aan als gevolg van jullie opmerkingen. Zodra het klaar is, post ik het
 
Ben eigenlijk (veel leerzamer) wel benieuwd naar het originele FO. Daar zal toch wel het e.e.a. instaan van je bedoelingen, die wij, op basis van de geposte db, dus nu al onder vuur hebben genomen (met de beste bedoelingen natuurlijk :)). En daar ben ik dus wel degelijk benieuwd naar.
 
Dat vind ik een goed idee. Ik heb het oorspronkelijk functioneel ontwerp in mijn hoofd zitten. Ik gat het uitwerken in een Word-document, dat ik ga posten.
 
Bijgaand het Word-document, waarin ik in het kort de gedachtenlijn heb neergeschreven, die geleid hebben tot de oorspronkelijk geposte database.

Inmiddels ben ik begonnen met het vereenvoudigen van de muziekdatabase.

Met vriendelijke groet,

Henk
 

Bijlagen

  • Functioneel_ontwerp_database_05042024.docx
    16,5 KB · Weergaven: 7
En heb ‘m doorgelezen vanavond :).

Eerste opmerking: het is geen Functioneel Ontwerp (omdat je verkeerd-om werkt). Je gaat uit van de tabellen (en iets ongrijpbaars dat jij sporen noemt), en niet van de functionaliteit. En, zoals de naam al suggereert, een FO is nou juist bedoeld om de gewenste Functionaliteit van het nieuwe systeem te beschrijven. Oftewel: je hebt een gegevens behoefte en daar wil je iets mee: overzichten uitdraaien, lijst en maken en/of zoeken op muziek die je hebt, of een plaat uit de kast kunnen pakken. Om maar eens wat te noemen.

In het FO beschrijf je die gegevens behoefte, en daar komen dan tabellen en queries uit rollen (doe door de ontwikkelaar bedacht worden :)). Als e.e.a. is gemaakt, wordt het proces verder beschreven en gedocumenteerd. Maar dat is van later zorg, zo ver ben je nog lang niet. Je moet daarbij uitgaan van de juiste entiteiten, zoals de fysieke objecten die de muziek bevatten, en artiesten. Een fysiek object is in dit geval dus een album met één of meer muziekdragers (cd, vinyl, cassette, box).

Daarnaast wil je (ook een onderdeel van het FO) weten wáár de betreffende objecten zich bevinden, en dan heb je het over de entiteit Kamer, de entiteit Kast en de entiteit Plank. Met de fysieke beperking dat een plank zich ten ene male altijd maar in één ruimte kan bevinden. Al dan niet in een kast. Wil je dit werkbaar maken voor elke willekeurige persoon die met het systeem gaat werken, dan moet er een herkenbaarheid in zitten, bijvoorbeeld doordat je de planken stickert met een uniek nummer (elke kast opnieuw nummeren? Doorlopend nummeren? Per kamer opnieuw nummeren? Etc).

Opmerking twee: verlaat het sporenpad, want dat leidt m.i. nergens heen. Denk vanuit de albums en artiesten, en bepaal van daaruit de gewenste informatie die je daar uit wilt halen. Want dát is waar het om gaat: welke informatie wil je op kunnen vragen? En liedjes eenmalig invoeren om redundantie te voorkomen? Zo werkt dat niet, vrees ik. Al was het maar omdat meerdere artiesten liedjes met dezelfde naam hebben geschreven, terwijl dat toch echt aparte liedjes zijn. Als iemand een cover van Jolene opneemt, dan is dat een eigen entiteit. Het maakt niet uit of dat Dolly Parton zelf is, Mindy Smith (overigens een uitstekende versie) of godbetere het Beyoncé. Allemaal aparte liedjes die op één album staan, en dus per album apart beschreven moeten worden.

Anyway, dat is de weg die ik zou bewandelen (en ook doe in mijn eigen muziek database).
 
Beste Michel,

Bedankt voor je opbouwende kritiek Allereerst, ik heb wel degelijk een idee over de informatie, die ik uit de database wil halen. Van elke muziektrack wil ik weten op welke drager deze staat en waar in huis ik die drager kan vinden.

Ik pas het functioneel ontwerp en de muziekdatabase aan, met in achtneming van alle geplaatste opmerkingen. Zodra beide klaar zijn, post ik ze opnieuw.
 
Ik heb ook niet gezegd dat je dat idee niet hebt, maar dat het dus niet is uitgewerkt in je FO :). Wat je nu aangeeft, kan dus op een veel simpelere manier dan zoals je was begonnen. Waarbij je dus op elk album aangeeft wat de drager is, en met een één-op-veel tabel de nummers vastlegt.

Wil je daarbij écht op nummers kunnen zoeken, dan ontkom je er niet aan om van die nummers ook de schrijver(s) vast te leggen, omdat zoals ik al aangaf een nummer met een bepaalde titel best meerdere keren kan voorkomen. Op titels van liedjes kun je nu eenmaal geen octrooi aanvragen :).

Zelf leek het mij leuk om te kunnen terugvinden op welke nummers bepaalde artiesten meespelen. Maar dat bijhouden in een grote database is een dagtaak, dus daar ben ik nog (maar) niet aan begonnen. Op welke nummers speelt Eddie van Halen mee? Jeff Beck? Ik zou daar graag een overzichtje van kunnen uitdraaien!
 
Een een op veel relatie tussen het album en de bijbehorende tracks zal niet gaan, omdat ik ook nogal wat singles en cd-singles heb zonder bijbehorend album. En een 1 op veel relatie tussen de tracks en de artiesten zal ook niet gaan, omdat ik alleen een artiest op trackniveau vermeld, als het om een verzamelalbum met verschillende artiesten gaat of om de singles en cd-singles.

Overigens geeft de combinatie van uitvoerende en track al voldoende houvast? Er zijn volgens mij geen artiesten, die eenzelfde titel van verschillende schrijvers hebben opgenomen.

Tenslotte off topic: ik mag je wel feliciteren met deze voor 010 heugelijke dag :).
 
Hevoolst zei:
Er zijn volgens mij geen artiesten, die eenzelfde titel van verschillende schrijvers hebben.
Klik om te vergroten...
Honderdduizenden artiesten, miljoenen platen en miljarden aan liedjes…. Deze stelling zou ík niet willen verdedigen voor een rechter :).

Jouw argument is in mijn ogen geen argument; een single is net als een album een muziekdrager. Vaak ook met meer dan één liedje er op. In mijn herinnering had een single zelfs twee kanten, met op elke kant een liedje :). Ik heb er nog wel een paar liggen!

Hooguit is het formaat van een single anders dan een album. Maar dat is een plaat op vinyl ook. Ergo: dat attribuut is dus gewoon onderdeel van het veld ‘drager’. Dus naar CD, DVD, Vinyl, Cassette heb je óók het type CD-single. Je denkt nog steeds te ingewikkeld, en ziet volgens mij de grote lijnen nog niet.
 
OctaFish zei:
Hooguit is het formaat van een single anders dan een album. Maar dat is een plaat op vinyl ook. Ergo: dat attribuut is dus gewoon onderdeel van het veld ‘drager’. Dus naar CD, DVD, Vinyl, Cassette heb je óók het type CD-single.
Klik om te vergroten...
Dat weet ik wel; ik heb in de tabel muziektracks ruimte gemaakt voor de maxisingle, cd-single en single.

Een album heeft een naam. Als ik de single in de tabel album opneem, welke naam krijgt hij dan?
 
En dát is dus een verkeerde insteek.

Hevoolst zei:
Een album heeft een naam. Als ik de single in de tabel album opneem, welke naam krijgt hij dan?
Klik om te vergroten...
Simpel: de naam van de titel. Net zoals een album vaak ook de titel krijgt van één van de nummers, geldt dat ook voor een single. Nogmaals: je denkt te moeilijk. Denk in entiteiten (objecten, zoals een elpee of een single). De entiteit ‘geluidsdrager’ kan een single zijn, een elpee, een dubbelelpee of een cd box. Maakt allemaal niet uit. Net zoals de entiteit ‘persoon’ een man kan zijn, of een vrouw. (Voeg daar zelf indien gewenst andere geboortevormen aan toe).

Heb je een entiteit onderkend en gedefinieerd in je FO, dan ga je daarna de attributen bepalen waarmee je de objecten kan/moet beschrijven. Zo heeft de entiteit ‘persoon’ een geboortedatum, een sterfdatum en een geslacht. Meestal ook een naam :). Een ‘geluidsdrager’ kan dus van het type CD, DVD, Elpee, Single, CD-Single etc. zijn.

Elke geluidsdrager heeft een publicatiedatum (of, in jouw geval, een uitgave jaar), een artiest, en nog zo wat gegevens. Er is, voor zover het de database betreft, geen enkel verschil tussen een single en een album. “Een single heeft maar één nummer per kant”, hoor ik je zeggen, “en een elpee heeft er meer”. Fout. Ik heb elpees in de kast staan met maar één nummer per kant. Mag jij uitleggen wat dan nog het verschil is :).
 
Het vergt enige lenigheid van (mijn)geest, maar ik volg je advies op
 
Je moet ingelogd zijn om te kunnen reageren. Log in | Registreer
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan