Prosjekt: Musikkdatabase ...

[discostu]

Hei, driver med ett prosjekt på skolen nå, der jeg skal lage en database som registrerer band/album osv..

Har da brukt denne databasemodellen, noen som har noen tips til videre utvikling? Feil osv..?

Dette skal da brukes sammen med php..

Det skal heller ikke være så altfor avansert, så lett som mulig egentlig.

Bilde av modellen:

http://img64.imageshack.us/my.php?image=da...semodell8vd.jpg

Endret 22. februar 2006 av discostu

[kilogram]

Det er ein grei grunnleggande modell, med nokre små feil;

• kvifor har "Band"-tabellen "MedlemsID"?
  
• kvifor har Album-tabellen SangID?
  
• ikkje bland norsk og engelsk; ProdYear == ProdAr == ProdÅr (dersom verktøyet støtter æ,ø,å)
  
• AntSpor i Album treng du ikkje. Det kan du finne ved å telle opp fra Sanger-tabellen
  
• tabellnavn bør vere i eintall; dette er dog ein smakssak. Så lenge du er konsistent internt i modellen er det greit.
  

Nokre spørsmål du bør fundere litt på;

• er det ein sang som tilhøyrer ein viss sjanger, eller er det eit album?
  
• kan eit album innehalde sangar frå fleire artistar?
  
• kan ein person vere med i fleire band?
  
• kan eit band ha ein gjesteartist på ein enkelt sang?
  

Det er sikkert meir du bør tenke på, men det får du fundere på sjølv...

[CruellaDeVille]

Modellen din ser forholdsvis grei ut, men jeg har noen kommentarer utover de du alt har fått. Du sier du skal lagre band... bare band? Hva med å ha en entitet som heter artist og bruke denne både til soloartister og band? (eventuelt et hierarki av artister, med band og soloartist som subentiteter)

 

Slik modellen din er nå kan hvert album bare ha en sang (kardinalitet en til en). Du kan flytte albumID over til sang som fremmednøkkel, eventuelt lage en mellomliggende tabell med sangID og albumID som eneste felt og sammensatt primærnøkkel. Dermed ville du også muliggjøre at en sang kan finnes på flere album (hvilket de også gjør). Eksempelvis har Jeff Buckley laget en cover av Halleluja til Cohen. Slik som du har modellert det nå vil du få en dobbeltoppføring med "halleluja", siden sangen (den samme) er knyttet opp mot to forskjellige album.

[Drittsekken]

Hvis dette ikke skal være en liste over de album e.l. som skolen (eller du) disponerer, trenger du data?

 

Jeg har listet opp hele samlingen min (324 CD'er til nå + singler o.s.v.) i Excel med

 

Artist

Title

Year

Type

Catalog Nr

Serial Nr (strekkode)

Record Company

Time 1 (CD1)

Time 2 (CD2)

Time 3 (CD3)

Track 1...

[boemane]

For en god stund siden hadde jeg Musikk@Nettnyheter oppe, og jeg benyttet meg da av følgende database:

 

CREATE TABLE BandIndex (
 Navn varchar(200) default NULL,
 Artist varchar(200) NOT NULL default '',
 PRIMARY KEY  (Artist)
) TYPE=MyISAM;

CREATE TABLE Diskografi (
 PlateID int(2) NOT NULL auto_increment,
 PlateTittel varchar(200) default NULL,
 PlateType varchar(10) default NULL,
 Band varchar(200) default NULL,
 UtgivelsesAar int(4) default NULL,
 PRIMARY KEY  (PlateID)
) TYPE=MyISAM;

CREATE TABLE Info (
 Bandet text,
 Media text,
 Band varchar(200) NOT NULL default '',
 PRIMARY KEY  (Band)
) TYPE=MyISAM;

CREATE TABLE Plate (
 PlateID int(2) NOT NULL default '0',
 CoverBilde varchar(200) default NULL,
 PlateInfo mediumtext,
 PlateAnmeldelse text,
 PlateKarakter int(1) default NULL,
 band varchar(200) default NULL,
 PRIMARY KEY  (PlateID)
) TYPE=MyISAM;

CREATE TABLE LaatListe (
 PlateID int(2) NOT NULL default '0',
 LaatNr int(2) NOT NULL default '0',
 LaatNavn varchar(200) default NULL,
 LaatLengde varchar(5) default NULL,
 LaatTekst text,
 PRIMARY KEY  (PlateID,LaatNr)
) TYPE=MyISAM;

CREATE TABLE Live (
 LiveID int(2) NOT NULL auto_increment,
 LiveDato date default NULL,
 LiveLokale varchar(200) default NULL,
 LiveBy varchar(100) default NULL,
 LiveLand varchar(100) default NULL,
 band varchar(200) default NULL,
 PRIMARY KEY  (LiveID)
) TYPE=MyISAM;

CREATE TABLE Nyheter (
 NyhetID int(2) NOT NULL auto_increment,
 NyhetDato date default NULL,
 NyhetOverskrift varchar(200) default NULL,
 NyhetInnhold text,
 NyhetPeker varchar(200) default NULL,
 Band varchar(200) default NULL,
 PRIMARY KEY  (NyhetID)
) TYPE=MyISAM;

CREATE TABLE Pekere (
 PekerID int(2) NOT NULL auto_increment,
 PekerNavn varchar(100) default NULL,
 PekerURL varchar(200) default NULL,
 PekerBeskrivelse mediumtext,
 band varchar(200) default NULL,
 PRIMARY KEY  (PekerID)
) TYPE=MyISAM;

 

Det er vel ca. 7-8 år siden jeg opprettet og benyttet denne databasen, men den lagrer band, diskografi, plater, låtene på platene. Bandets Live datoer, Likner (peker) relatert til bandet, nyheter og band-info (en introduksjons-tekst til bandet).

 

Håper det hjelper noe

[discostu]

Takk for mange bra svar, men somsagt var dette kun på planleggingsfasen, Har nå tenkt litt over dette og har kommet fram til at den database som inneholder "sang tekster" ville vært mer "brukerlig".

 

Eneste problemet er at jeg sliter litt med å finne fram til gode ideer til denne modellen.

Kravet er jo at prosjektet skal ha minst 4 tabeller..

 

Ting jeg kom på som bør være med er:

 

Lyric:

 

LyricID ->Primærnøkkel

Artist/Band

Sjanger

Sang

 

Kommer ikke på noe fler, vet ikke om det blir for dumt å dele disse inn i egne tabeller..

 

Artist:

 

ArtistID

Artistnavn

 

Sjanger:

 

SjangerID

Sjanger

Sang:

 

SangID

Sang

 

 

Dette blir kanskje litt for dumt?

[roac]

Takk for mange bra svar, men somsagt var dette kun på planleggingsfasen, Har nå tenkt litt over dette og har kommet fram til at den database som inneholder "sang tekster" ville vært mer "brukerlig".

 

Eneste problemet er at jeg sliter litt med å finne fram til gode ideer til denne modellen.

Kravet er jo at prosjektet skal ha minst 4 tabeller..

 

Dette blir kanskje litt for dumt?

Krav om minst 4 tabeller = skolearbeid.

 

Da har jeg lyst til å stille et par enkle spørsmål:

• Har dere lært noe om design av databaser?
  
• Kjenner du til 3NF (tredje normalform)?
  
• Har du i det hele tatt forsøkt å lage en logisk (konseptuell) modell først?
  

Det virker for meg som om du hiver deg over den fysiske modellen med en gang uten å ha den fjerneste idé om hva du vil ha med deg, og det skaper ekstra arbeid både for deg selv og for oss som prøver å hjelpe deg.

[discostu]

Vi har ikke lært så altfor mye enda nei, men problemet ligger vel egentlig i at jeg sliter litt med logisk tankegang når jeg prøver å få fram en database..

[CruellaDeVille]

Vi har ikke lært så altfor mye enda nei, men problemet ligger vel egentlig i at jeg sliter litt med logisk tankegang når jeg prøver å få fram en database..

5715777[/snapback]

 

Først må du tenke på hva du skal lagre i databasen din. Du skal lagre Cd'er utgitt av en artist. Denne artisten er enten et band eller en soloartist. Cd'ene har sanger , disse har en tekst. Alle Cd'er tilhører en sjanger. Så langt er det greitt. Så må du tenke på:

 

Skal du lagre alle bandmedlemmene, i såfall hvorfor. Videre må du tenke på kardinalitet. Eksempel: en artist kan utgi mange cd'er, en cd er bare utgitt av en artist. Dermed har du en en-til-mange mellom artist og cd. I en en-til-mangeforbindelse skal fremmednøkler lagres på mange-siden (her cd). En cd kan eventuelt være av en sjanger, om dette er tilfelle er et designspørsmål. Det kan være flere plater av en sjanger, dermed har du en en-til-mange mellom cd og sjanger. På samme måte skal da primærnøkkel fra sjanger være fremmednøkkel i cd.

 

Så inneholder en cd mange sanger og en sang kan være utgitt på flere forskjellige plater. Dermed har man en mange-til-mange-forbindelse mellom sang og cd. I en mange-til-mange-forbindelse skal primærnøkler fra begge tabeller flyttes over til en mellomliggende tabell som sammensatt primærnøkke og fremmednøkkel.

 

Du sier at du vil lagre tekster. En sang har bare en tekst, og den er lik selv når sangen utgies på en annen plate eller med en annen artist. Slik kan da tekst være et attributt på sang.

 

Tilbake til artist, som enten er soloartist eller band. Dette kan modellers som arv. Nå støtter ikke relasjonelle databaser arv slik en kjenner det fra programmeringsspråk, eks java, men man kan jukse litt og simulere arv. Dermed kan du modellere artist med en identifikator og attributter som er felles for både soloartister og band. Videre brukes identifikatoren i soloartist og band, og hver entitet får attributter som skiller de fra hverandre (hva nå enn det kan være). Så kan Band ha en relasjon består av til bandmedlem, hvor du kan liste opp alle medlemmene i et band. Denne er en svak entitet, siden ingen kan være medlem av et band som ikke eksisterer. Dermed flyttes primærnøkkelen fra band over til bandMedlem som fremmednøkkel og i tillegg utgjør en sammensatt primærnøkkel sammen med identifikatoren til bandMedlem.

[kaffenils]

Videre må du tenke på kardinalitet. Eksempel: en artist kan utgi mange cd'er, en cd er bare utgitt av en artist.

 

Som heller ikke stemmer. Det er egentlig ikke artisten som har gitt ut cden, det er forlaget. Artisten har bare gitt ut en eller flere sanger. En sang kan finnes på en eller flere cder, f.eks. en samle-cd ala Absolute Music XX.

En musikkdatabase har faktisk en ganske stor relasjonsmatrise, noe som gjør at det kanskje ikke er det første en nybegynner bør begi seg ut på hvis en skal kunne registrere alle eventualiteter.

[roac]

Videre må du tenke på kardinalitet. Eksempel: en artist kan utgi mange cd'er, en cd er bare utgitt av en artist.

 

Som heller ikke stemmer. Det er egentlig ikke artisten som har gitt ut cden, det er forlaget. Artisten har bare gitt ut en eller flere sanger. En sang kan finnes på en eller flere cder, f.eks. en samle-cd ala Absolute Music XX.

En musikkdatabase har faktisk en ganske stor relasjonsmatrise, noe som gjør at det kanskje ikke er det første en nybegynner bør begi seg ut på hvis en skal kunne registrere alle eventualiteter.

5719179[/snapback]

Helt korrekt. Og enda verre, det kan være flere artister/band på en og samme cd. F eks samlealbum. Trekker man det enda lenger så kommer også CD-bokser inn i bildet, som enten kan være flere CDer, eller det kan være flere album som bare er satt sammen. Man har også det faktum at enkelte medier for musikk (LP/MC) er tosidige. Andre er ensidige eller det har ingen betydning (CD/MD). Bare for å gjøre det virkelig morsomt så er det også utgivelser av bokser som har forskjellige medier. Det kan være så enkelt som 2 CDer og en DVD, eller for den saks skyld en LP og en CD.

 

Artister er en egen greie for seg selv. Det samme artistnavnet kan være brukt av flere artister, og en artist kan gjerne ha flere artistnavn. Et eksempel på dette er Silje Nergaard / Silje / Silje Nergård. Vider har vi Silje Vige som vel også ga ut en CD kun som Silje. Hvordan skal vi kunne skille på disse. Et band vil også ha utskifting av medlemmer, slik som f eks når Roger Waters gikk ut av Pink Floyd. Men det forhindrer selvfølgelig ikke en artist å være både solo og i en eller flere band i den samme tidsperioden.

 

Når det gjelder sanger er det også interessant, for en sang kan ha to forskjellige melodier (uten at jeg kommer på noen i farten). Videre kan teksten også være oversatt, f eks Amazing Grace aka Å nåde stor. Teksten kan også (for eldre sanger) bli endret underveis, f eks ved fornying av språket.

 

En utgivelsen kan også inneholde melodier av flere sjangre, og enkelte sjangre kan klassifiseres innunder andre. F eks så er samtidsjazz en form for jazz, og barokk er en form for klassisk.

 

På begynnelsen av 1990 tallet begynte jeg med en DOS-applikasjon, og jeg ga vel opp når jeg kom til 8 eller 9-dimensjonale pekerstrukturer. Men, for all del. Jeg vurderer seriøst om jeg skal ta det opp igjen, for det er en fin utfordring å få dette til å bli både effektivt og brukervennlig.

 

Uansett: For at et prosjekt i denne klassen skal lykkes er det én ting som gjelder: Systemering.

[kaffenils]

... mye fornuftig...

 

Resultatet av denne kompleksiteten skjønner man fort at til og med "proffene" (freedb og gracenote) heller ikke har klart å løse når en ser hvor variert kvaliteten på id3-data en cd-ripper henter fra freedb eller gracenote. Bjorn Eidsvag, Bjørn Eidsvåg, Bjorn Eidsvaag.