Opgelost Kan deze muziekdatabase efficiënter worden gemaakt?

Dit topic is als opgelost gemarkeerd
Status
Niet open voor verdere reacties.
Beste forumleden,

Bijgaand het vernieuwde concept van mijn muziekdatabase en het aangepaste functioneel ontwerp. Bij het maken van beide bestanden heb ik mij laten leiden door de hierboven gemaakte op- en aanmerkingen. Ik ben benieuwd, wat jullie ervan vinden.

Met vriendelijke groeten,

Henk
 

Bijlagen

Ik blijft moeite houden met je combi-tabellen. Zoals ik eerder schreef zou je zo'n tabel moeten gebruiken als er sprake is van een veel-op-veel relatie tussen twee tabellen. Op een paar plaatsen heb je er nog steeds een overbodige combi-tabel tussen geplakt, op een andere plaats mis ik er juist een.

De missende is naar mijn mening die tussen artiest en track. Een artiest kan bij meerdere tracks betrokken zijn en aan een track kunnen meerdere artiesten meegewerkt hebben. Dus een veel-op-veel relatie, dus een combi-tabel.
Ik denk hierbij bijvoorbeeld aan gelegenheidsduo's (Herman Brood & Henny Vrienten - Als je wint).
Het blijft overigens lastig wat je als artiest beschouwt. Een vast duo (Simon & Garfunkel) zou je, net als een band, als één "artiest" kunnen beschouwen, maar ze zijn later solo gegaan (en dat wist je niet toen ze nog een duo waren). Hoe vind je dan alles terug van Paul Simon?

De gevallen waarbij er geen sprake is van een veel-op-veel relatie, maar van een één-op-veel (en er dus geen combi-tabel nodig is) zijn:
  • Vertrek (gebruik consequent enkelvoudige begrippen) - Muziekbox: een muziekbox kan maar in één vertrek staan.
  • Plank - Muziekbox; een muziekbox kan maar op één plank staan.
  • Muziekbox - Muziekalbum; een album kan maar in één box zitten.
 
Een gelegenheidsduo krijgt een aparte vermelding. Daarnaast krijgen de afzonderlijke leden zonodig een aparte vermelding. Een voorbeeld is dr. Hook and the Medicine show. De Medicine Show is in 1975 opgeheven. De latere hits heb ik geregistreerd onder Dr. Hook.

In de tabel muziekbox komen boxen voor, die op de vloer van de zolder staan - de singles -en die in een doos op een plank van een kast zitten- de cd-singles.

Verder beschouw ik lp-doos met vakken als een kast. Een LP- doos zonder vakken is een muziekbox. In die visie zijn er albums die of in een box zitten of in een kast.

Dit heb ik gedaan om het aantal tabellen beperkt te houden.

Met vriendelijke groet,

Henk
 
Het concept ‘muziekboek, ‘lp-doos met vakken’ en ‘lp-doos zonder vakken’ is in mijn ogen een ongewenste vertroebeling van élk systeem dat je maar kan bedenken. Ik snap nog stééds het nut niet. M.i. kun je gewoon volstaan met de tabel tAlbums met een koppeling naar de tabel tAlbumDetails waarin je alle aparte albums/cd’s/platen beschrijft.

Een box met 10 cd’s met de titel “Hits van de jaren ‘90” is dan het album in tAlbum, en de 10 cd’s daarin beschrijf je in tAlbumDetails. En die koppel je dan weer aan de tracks op die albums. Moeilijker hoeft het echt niet. Nog steeds geldt: het album (de box dus) kan maar op één plek staan, in één vertrek.

Wat betreft de artiesten: dat is een redelijk ingewikkelde kwestie, zoals TS ook al beschreef. Maar die beschrijving is volgens mij toch niet helemaal correct :). Van de band ‘dr. Hook and the Medicine Show’ werd het ‘onderdeel’ “and the Medicine Show” niet opgeheven; ze hebben gewoon de naam veranderd. Meer was het niet. Er wás ook nooit sprake van een band ‘dr. Hook’ die samenwerkte met de band ‘the Medicine Show’. En er zijn uiteraard meer voorbeelden: de band “Tyrannosaurus Rex” hernoemde zich begin jaren ‘70 naar (de veel succesvollere) band “T.Rex”. De band “The Golden Earrings” werd “Golden Earring”. Zelfde bands, andere naam.

Maar het wordt nóg ingewikkelder: artiesten maken rustig platen met anderen (of solo) terwijl ze in hun eigen band actief zijn. (Mick Jagger, Bryan Ferry, Thom Yorke om er maar een paar te noemen.) Peter haalt S&G aan, die ná hun ‘groep’ solo verder zijn gegaan. En vraagt zich af hoe je in één zoekactie alles van Paul Simon kan vinden. En noemt Herman Brood & Henny Vrienten een gelegenheidsduo. Onterecht, in mijn optiek: elke artiest die níet solo een plaat maakt, kun je als Band beschouwen. En of ze één plaat maken, of meer, dat boeit natuurlijk niet. Net zo min als het terecht is dat er nu gesproken wordt van ‘Wilders 1’. (Rob Jetten doet dat o.a. Komt er gelukkig niet :)). Dat had moeten zijn: ‘kabinet Wilders’. Pas bij een tweede kabinet van dezelfde minister-president ga je nummeren. (Ik dwaal af).

Of iets een ‘gelegenheidsduo’ is geweest, wordt bepaald door de geschiedenis: als één van de twee bijvoorbeeld overlijdt, waardoor het voortbestaan van het duo ernstig in gevaar wordt gebracht. De kans dat Brood & Vrienten nú nog een plaat uitbrengt, is nihil. Maar dat was die al op het moment van het overlijden van Herman Brood. Zouden ze allebei nog leven, dan was er nog steeds een kans geweest op een tweede nummer, of wellicht zelfs een album.

Dus: in essentie is het heel simpel: je hebt mensen die muziek maken (noemen we hier ‘artiesten’) die alleen of met anderen platen opnemen. De collaboraties noemen we dan vaak een Band. Bands opereren zelden hun volledige bestaan in dezelfde samenstelling (uitzonderingen zoals U2 uitgezonderd), dus er kunnen rustig 20 of meer mensen lid zijn of zijn geweest van een band. Wil je het door Peter gewenste overzicht kunnen maken van alle platen waar Paul Simon aan heeft meegewerkt, dan moet je die geschiedenis per muzikant bijhouden.

Dat is een hele klus, waarvan ik nog niet de eerste aanzet heb gezien, maar dat komt wellicht omdat ik de nieuwe opzet nog niet heb bekeken. Maar goed, als je bijhoudt wanneer welke artiest (persoon dus) in welke band heeft gezeten, en bijhoudt welke artiest (solo of band) welke plaat heeft gemaakt, dan is zo’n overzicht heel makkelijk uit te draaien. Dat lukt dus níet door een tekstfilter te maken op basis van ‘ArtiestNaam’, omdat je dan wél “Paul Simon” en “Simon & Garfunkel” kan vinden door op “Simon” te zoeken, maar de zoekterm “Young” vindt wél “Neil Young” en “Crosby, Stills, Nash & Young”, maar níet “The Flying Burrito Brothers”.
Kortom: het is maar wat je wilt van je database. :).
 
Ik heb ondertussen ook je nieuwe FO gelezen, maar (ja, ik weet dat het een lastig onderwerp is ;)) het is nog steeds geen Functioneel Ontwerp. Je beschrijft namelijk niet wat het doel is van het systeem. Je komt niet veel verder dan dit:
Ik heb veel cd’s, lp’s, cassettes, cd-singles, maxi-singles en singles, opgeborgen in dozen of staand op planken in kasten. Van elk nummer die op 1 of meerdere van die informatiedragers, noteer ik de artiest, de titel van het nummer, het genre, de datum van binnenkomst in de top 40, of het een favoriete schijf is geweest en de informatiedrager.

En daar kan ik met de beste wil van de wereld toch geen doel in zien. Hooguit wat het basismateriaal is waar je iets mee wilt doen. Een doel zou bijvoorbeeld kunnen zijn: ik wil overzichten kunnen maken op basis van artiest, genre, jaar.
Tegenwoordig worden systemen vaak ontworpen a.d.h.v. "user stories". Dan ga je vragen stellen die je m.b.v. het systeem wilt kunnen beantwoorden. Bijvoorbeeld deze: "Pieter wil op een feestje alle treiterschijven uit 1989 draaien". Of: "Jeanette wil graag weten op welke platen Jeff Beck heeft meegespeeld". Nog een leuke: "Anton wil weten hoeveel geld er jaarlijks wordt uitgegeven aan het kopen van muziek". En de ontwerper gaat dan kijken wat er voor nodig is om deze vraag ook daadwerkelijk uit het systeem te kunnen krijgen.
Verschillende vragen stellen dus verschillende eisen aan het systeem.

En die doelen mis ik dus in jouw FO. Het is eigenlijk nog steeds een beschrijving van wat je allemaal in kasten en op de vloer hebt staan, zelfs tot het niveau van de kleur van de doos!

En het onderdeel 'Plank' houdt mij ook al een tijdje bezig:
Een plank is een onderdeel van een kast; wordt genummerd van boven naar beneden en daarna van links naar rechts.
Ik heb mijn hele leven al kasten gehad, maar daarbij zijn de planken altijd horizontaal in de kast terecht gekomen, zodat ik nooit iets anders heb gedaan dan van boven naar beneden nummeren. Nog nooit heb ik planken van links naar rechts genummerd! Dat kan toch alleen als je de plank verticaal in de kast monteert? Hoe blijven de cd's er dan op staan? Ik krijg dat niet gevisualiseerd :).

Volgende stap: weer eens goed naar de database kijken. Of toch maar mijn eigen database verder uitwerken, want daar zit voor mij toch meer logica in :D.
 
Ik heb mijn hele leven al kasten gehad, maar daarbij zijn de planken altijd horizontaal in de kast terecht gekomen, zodat ik nooit iets anders heb gedaan dan van boven naar beneden nummeren. Nog nooit heb ik planken van links naar rechts genummerd!
Dat kan wel. Kijk maar eens naar een grote Billies kast van Ikea. Je begint links van boven naar beneden. Daarna ga je naar het middenstuk en ga je weer van boven naar beneden. Vervolgens ga je bij het rechterdeel weer naar boven en dan naar beneden. Dus daar zit ook een beweging in van links naar rechts. De CD's staan keurig horizontaal op de plank :).

Tja en dan de verschillende doelen:

Een overzicht kunnen maken per artiest; op welke albums hij/zij voorkomt en waar in huis ik die albums kan vinden. En ook nog op welke informatiedrager die albums te vinden zijn.

Welke nummers zijn ooit treiterschijf geweest in de 70-er jaren en tot welk genre behoorden ze?
Welke nummers komen er uit 1989 en hoeveel daarvan zijn hit geweest?

Zo kan ik nog wel even doorgaan. Maar ik heb het idee, dat ik deze vragen met de huidige structuur wel kan beantwoorden.
 
Een box met 10 cd’s met de titel “Hits van de jaren ‘90” is dan het album in tAlbum, en de 10 cd’s daarin beschrijf je in tAlbumDetails. En die koppel je dan weer aan de tracks op die albums. Moeilijker hoeft het echt niet. Nog steeds geldt: het album (de box dus) kan maar op één plek staan, in één vertrek.
Ik wil het ontwerp zo aanpassen dat in de tAlbum ook de nadere plaatsbepaling van het album staat, dus in welke box zit het album en in welke kast en/of vertrek is die box?

Omdat de titel van een single ook in de tAlbum staat, vraag ik mij af welke informatie je over die single in de tAlbumDetails zet, als de beide tracks in de tabel Muziektracks staat.
 
Singles hadden vroeger een eigen toerental, en cd-singles hadden (ooit?) een eigen formaat. Ik koop nooit singles, dus ik weet niet hoe dat tegenwoordig gaat. Maar als singles tegenwoordig hetzelfde formaat hebben als een cd, wat onderscheidt ze dan (volgens jou) van een ‘normaal’ album?
 
Van een CD kun je in de tabel details per CD de totale speelduur vermelden. Per CD krijg je ook de bijbehorende tracks te zien. Voor een (CD)-single kun je dezelfde gegevens vermelden, maar dat doet wat gekunsteld aan.
 
Bij mijn weten hebben ook single’s meerdere tracks. Die cd-singles díe ik heb, hebben minimaal twee nummers. En databases gaan niet over ‘gekunsteld aanvoelen’, maar over het correct beheren van gegevens :). Voor de database maakt het niet uit of de totale speeltijd (die sowieso gerekend is, en nooit met de hand ingevoerd) gelijk is aan de trackduur of niet. Het is gewoon een berekening.
 
Beste forumleden, bijgaand een nieuwe versie van mijn muziekdatabase en een gewijzigd functioneel ontwerp. Ik heb alle op- en aanmerkingen, waarvoor nogmaals mijn dank, hierin verwerkt. Graag hoor ik van jullie of ik met deze database verder kan bouwen.

Met vriendelijke groet,

Henk
 

Bijlagen

Ik raad je wel aan om de soorten speciale muziektracks, zoals Troetelschijf, NCRV-favoriet, NOS Steunplaats etc, in een aparte tabel te plaatsen en deze te koppelen met je muziekplaat. Straks heb je meer muzieksoorten, en dan moet je verticaal je structuur uitbreiden. En zulke dingen wil je juist graag voorkomen.
 
In de velden troetelschijf, treiterschijf, alarmschijf enz. vul ik de datum in, waarop die track het predicaat verkreeg. Het komt ook voor dat een track meerdere predicaten kreeg, al dan niet op dezelfde datum.
 
Dan alsnog loont het om daar een aparte tabel voor te maken.

Muziekpredicaten (bijvoorbeeld)
- ID (PK)
- Naam

En een koppeltabel met Nummer_Muziekpredicaten
- ID
- PlaatID
- Datum

Je kan dan een plaat meerdere predicaten geven en bij elk een datum vasthangen.
En zo voorkom je het onnodige verticale uitbouwen voor elk item.
 
Die tabel Muziekpredicaten kan weg als je in de tabel [Nummer_Muziekpredicaten] een keuzelijst met invoervak maakt op basis van Waarden. Komt er dan een nieuwe waarde bij, dan zet je die gewoon in de keuzelijst bij de Veldeigenschappen.

Tabellen met slechts één nuttig veld, vind ik in beginsel (tenzij het om honderden waarden gaat) overbodige ballast. In dit geval heb je het over een specifiek veld met beperkte waarden, dus dan is een keuzelijst meer dan genoeg.
Wil je meer dan één eigenschap opslaan, dan is een tabel wél weer handiger.
 
Hoezo zou het overbodige ballast zijn? Je kan hier ook nog extra data aan vasthangen, zoals radiozenders. Je maakt het met goede normalisatie juist eenvoudig om makkelijke berekeningen en analyses te maken, zoals bijvoorbeeld: Toon alle predicaten van 3FM.
 
“Bij databases verwijst verticale uitbouw naar een specifieke optimalisatietechniek waarbij tabellen worden verdeeld op basis van kolommen. In tegenstelling tot horizontale uitbouw, die tabellen verdeelt op basis van rijen, richt verticale uitbouw zich op het scheiden van kolommen. Dit kan handig zijn als je bijvoorbeeld alleen bepaalde kolommen wilt opvragen in plaats van volledige rijen. Het doel is om de prestaties te verbeteren en de schaalbaarheid te vergroten.” Dit heb ik van CoPilot

Als ik het goed begrijp, gaat het hier over normalisatie. Gelet op de opmerkingen die ik eerder kreeg, heb ik de normalisatie zo beperkt mogelijk gehouden.

Als ik de oplossingen van Aar en Michel beide zou toepassen, dan houd ik alleen een Koppeltabel over, waarvan een van de te koppelen tabellen niet gebruikt wordt, namelijk Muziekpredicaten. Daar kom ik niet verder mee.
 
Het gaat zeker over databasenormalisatie :).
Maar waarom zou je die tabel Muziekpredicaten niet gebruiken? Je wou toch Troetelschijf, Alarmschijf etc. in je database gebruiken om specifieke nummers in te benoemen?

Ik durf te wedden dat je zeker verder komt met deze optimalisatieslag, maar blijkbaar is het je nog niet duidelijk?
 
Bij de nummers in de database vermeld ik de datum, waarop ze tot een bepaalde schijf werden gekozen, meer niet En omdat het voorkomt, dat een bepaald nummer tegelijkertijd tot meerdere schijven werden gekozen, heeft iedere schijf een eigen kolom met datumveld.

Een eigen tabel voor die schijven zou ik zinvol vinden, als ik, om de Alarmschijf als voorbeeld te nemen:
De stations, die Alarmschijf hebben uitgezonden, zou noemen
De periodes, waarbinnen die stations dat hebben gedaan
Wie de eigenaren zijn geweest van de Alarmschijf
Maar dat ben ik niet van plan.
 
Die data kan je prima kwijt in veel-op-veel relatietabel waarbij je de nummers met de predicaten koppelt met de dag erbij. Wat nu als een bepaald nummer meerdere keren een bepaald predicaat krijgt? Geen idee of het kan, maar dan ben je voorbereid in plaats van dat je vast loopt op één datum.

Je moet, als je het netjes wilt doen, je kolom aanpassen naar een entiteit met rijen. Maar ik heb het idee dat je nog niet begrijpt hoe en wat?
 
Laatst bewerkt:
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan