Hjelp! IT1 Databasemodellering mysql

[Roman88]

Hei!
Jeg tar IT 1 som privatist og jeg sliter med databasemodellering,
men jeg tror at jeg har skjønt ideen bak det.

Er det noen sakkyndige her som kan se om det jeg har gjort virker fornuftig ifhtl. oppgaveteksten?

Oppgave:
Biblioteket vil ha en datamodell. Den skal holde oversikten over bøker og forfattere. En bok kan være skrevet av flere forfattere. Velg selv attributtene du ønsker å ta med. lag en mest mulig komplett datamodell med nødvendige attributter, datatyper og relasjoner.

Ett tilleggsspørsmål:
1.Jeg skjønner ikke helt ideen med kardinalitet.
eks. "Boklinje" tabellen.
En forfatter kan skrive mange bøker, men trenger ikke nødvendigvis å skrive noen. Maks:Flere, Min:0.
En bok kan være med mange boklinjer, men minst en må være med.
Maks:flere, Min:1.

Er dette riktig tolkning?

[/url]

 

Takk for svar!

Endret 12. november 2014 av Roman88

[Aleks855]

Jeg kan sannsynligvis hjelpe deg, men du må utdype litt om hva Boklinje-relasjonen skal representere. Jeg antar det ikke er hver linje i boka. Ut fra kolonnene den vil inneholde antar jeg den mapper forfatter til bok i tilfelle en bok har flere forfattere.

 

Om kardinalitet:

 

Når vi sier at en bok har flere linjer, men minst 1, så sier vi at relasjonen har et en-til-mange-forhold.

 

En bok kan være skrevet av flere forfattere; ergo har vi et en-til-mange-forhold der også.

 

En forfatter kan ha skrevet enten 0 bøker, 1 bok, eller mange bøker. Da sier vi at forfatter-bok har et 0-til-mange-forhold. Men vær oppmerksom; skal en forfatter som ikke har skrevet noen bøker være ført i databasen? Det kan være mer logisk med en-til-mange likevel.

 

Det er en stund siden jeg har tegnet datamodeller, så jeg er litt usikker på hvordan man illustrerer de ulike kardinalitetene. Men jeg merker meg at det ser ut som en bok kun kan tilhøre EN sjanger. Dette burde revurderes. Jeg mener det burde være en-til-mange der også, fordi en bok kan godt være både sci-fi og romantikk, for eksempel. Kanskje komedie også?

 

I så fall, vurder å ha en hjelpetabell slik du har gjort mellom bok/forfatter. På den måten kan en bok også koples til flere sjangere.

Endret 12. november 2014 av Aleks855

[Roman88]

Jeg kan sannsynligvis hjelpe deg, men du må utdype litt om hva Boklinje-relasjonen skal representere. Jeg antar det ikke er hver linje i boka. Ut fra kolonnene den vil inneholde antar jeg den mapper forfatter til bok i tilfelle en bok har flere forfattere.

 

Om kardinalitet:

 

Når vi sier at en bok har flere linjer, men minst 1, så sier vi at relasjonen har et en-til-mange-forhold.

 

En bok kan være skrevet av flere forfattere; ergo har vi et en-til-mange-forhold der også.

 

En forfatter kan ha skrevet enten 0 bøker, 1 bok, eller mange bøker. Da sier vi at forfatter-bok har et 0-til-mange-forhold. Men vær oppmerksom; skal en forfatter som ikke har skrevet noen bøker være ført i databasen? Det kan være mer logisk med en-til-mange likevel.

 

Det er en stund siden jeg har tegnet datamodeller, så jeg er litt usikker på hvordan man illustrerer de ulike kardinalitetene. Men jeg merker meg at det ser ut som en bok kun kan tilhøre EN sjanger. Dette burde revurderes. Jeg mener det burde være en-til-mange der også, fordi en bok kan godt være både sci-fi og romantikk, for eksempel. Kanskje komedie også?

 

I så fall, vurder å ha en hjelpetabell slik du har gjort mellom bok/forfatter. På den måten kan en bok også koples til flere sjangere.

Takk for svar Aleks!

 

Når det gjelder kardinalitet er jeg mer usikker på når jeg skal velge at minimumsverdien skal være 0 eller 1.

Så jeg er enig med deg i at "forfatter" til "boklinje" bør være en-mange med minimumsverdi:1.

Som du sier så er det jo unødvendig å ha med en forfatter i registeret som ikke har skrevet noen bøker?

 

Ang. boklinje så er det bare en koblingstabell mellom et mange-mange forhold mellom "bok" og "forfatter".

Ideen bak navnet fikk jeg fra en annen oppgave der man koblet sammen "ordre" med "produkt" til en "ordrelinje" tabell.

Jeg kom ikke på noe bedre navn enn "boklinje" men nå skjønner jeg jo at det kan misforstås

Bør jeg bare kalle den "Bokforfatter" kanskje?

 

Når det gjelder mitt valg for sjanger så er jeg forsåvidt enig at en bok kan ha flere sjangre.

Men blir det ikke litt problematisk med å ha en koblingstabell mellom "bok" og "sjanger" der man kan skrive flere navn på samme sjangeren?

eks. Komedie, Comedy osv.

Det er derfor jeg har et "en-mange" forhold mellom "bok" og "sjanger" der man kan skrive inn en kode som "Com" for å finne fram til filmer som er i Komedie sjangeren.

 

Endret 13. november 2014 av Roman88

[Aleks855]

Jeg ville kalt den "bok_forfatter". Man bruker ofte _ for å skille ord i databaser.

 

Når det gjelder sjanger, så er du inne på et godt poeng. De fleste databaser som tar høyde for flere språk, bruker egne koplingstabeller for oversettelser.

 

Eksempelvis har du sjanger-tabellen. Den kan ha kolonna "sjanger_id".

 

Så kan du ha "sjanger_oversettelser" (selv om alt burde være på engelsk når man først skal jobbe flerspråklig) der du har kolonnene "sjanger_id", "språk_id", "sjanger_oversettelse".

 

Denne kan da ha verdiene:

 

sjanger_id: 1

språk_id: 32

sjanger_oversettelse: comedy

 

I dette tilfellet er den første sjangeren "comedy", og engelsk er språk #32.

 

(Når det kommer til å fylle slike tabeller, så lager man som regel web-grensesnitt så man slipper å skrive en haug med INSERT-setninger manuelt.)

 

Men da må du også ha en språktabell med "språk_id" og "språk_navn".

 

Jeg ser for meg noe slikt:

 

http://i.imgur.com/CqwUFw3.png

 

Da uten å ta høyde for alt det andre.

 

Du kan også bruke Language-tabellen for å oversette bok-titlene, og alt annet.

Endret 13. november 2014 av Aleks855

[Roman88]

Fantastisk! Aleks, takk skal du ha for svar

Jeg tviler på at jeg må gå såpass i dybden, men jeg tror uansett at det er greit å ha kunnskapen

Har du anledning til å se kjapt over en annen oppgave?

Endret 18. november 2014 av Roman88

[Aleks855]

Bare å poste, så ser jeg på det når jeg får tid

[Roman88]

Oppgaven)

et bilverksted skal lagre informasjon om kunder, biler og reparasjoner. Du skal lage en datamodell for dette. Hvilke tabeller trenger du? Velg hvilke attributter/kolonner du vil ha med. Husk at en bil kan være inne til reparasjon flere ganger.

 

upload img

Kommentaren fra en kompis som har drevet litt med det er at jeg burde ha datoene "dato_innlevert" osv. plassert i hjelpetabellen til "reperasjon" og "bil". Han visste ikke hvordan han skulle forklare hvorfor det skulle være sånn, men han syntes bare at det ble litt rart slik det var i mitt diagram. Jeg har aldri sett noen eksempler der man slenger med ekstra attributter i hjelpetabeller, og hvilken konsekvens det har for modellen.
Hva tenker du?

Endret 18. november 2014 av Roman88

[Aleks855]

Jeg er uenig med kompisen din. En hjelpetabell burde kun inneholde fremmednøkler som viser til innslag i andre tabeller.

 

Derimot ville jeg droppa hjelpetabellen helt. Et innslag i "Reparasjon"-tabellen kan godt inneholde bil-ID'en. Jeg tar da utgangspunkt i at ingen kunder kommer med to biler samtidig. Og selv om de gjør det, så kan det godt legges inn som to innslag.

 

Jeg ser også for meg en tabell "Tjenester". Den kan eksempelvis ha ting som "1, oljeskift", "2, bytte bunnpanne" osv. Kanskje også med ei kolonne for pris.

 

Du kan ha en hjelpetabell mellom Reparasjon og Tjenester, og på den måten vise hvilke tjenester som ble gjort under en reparasjon.

 

Derfra er det en smal sak å skrive en SELECT-setning som henter ut en liste over tjenester som ble gjort på bil med regnr. VF12345 på en viss dato. Eller å hente totalpris for denne reparasjonen.

 

PS: Kanskje ha regnr. med VARCHAR(10) eller høyere, i tilfelle bedriften får kunder med spesialskilter (militære kjøretøy, utenlandske kjøretøy eller liknende).

 

Jeg vil også anbefale å lagre telefonnummer som tekststreng, VARCHAR(12) eller liknende. Man trenger sjeldent å utføre matematikk på telefonnumre, og om den er en tekststreng, så er den også lettere å behandle i diverse programmeringsspråk når den allerede er en streng. Slike små-ting gjør hverdagen bittelitt lettere for utvikleren

[Roman88]

T

Endret 25. november 2014 av Roman88

[Roman88]

 

Takk for svar og tips Aleks!

Jeg har nylig hatt to eksamener, så det er derfor det har tatt meg litt tid å svare.

Så da burde diagrammet bli slik?

 

Spørsmål:

1. Vi kan droppe hjelpetabellen mellom "reperasjon" og "bil" fordi det er lite sannsynlig at en personer kan levere inn to biler samtidig. Om det skulle være tilfelle, så kan man bare legge inn de to bilene, en og en?

Så da blir det bare et en-til-mange forhold mellom bil-reperasjon? En bil kan være inne til mange reparasjoner, men en reparasjon kan bare bli utført på en bil (siden det er usannsynlig at noen leverer inn to biler samtidig?)

 

2. Vi lager hjelpetabell mellom "tjeneste" og "reparasjon" siden det blir et mange-til-mange forhold= "tjeneste_reparasjon".

En tjeneste kan bli gjort på flere reparasjoner, og en reparasjon kan omfatte flere tjenester?

Blir resonnementet noe ala dette?

 

3. Så vi bruker bare datatyper som INT på attributter som sannsynligvis brukes i matematiske sammenhenger? Som tlf, gatenavn, postnr.

Blir dette gjort også på Datetime? Mtp. Fødselsdato (få ut alle som er født etter 1988)?

 

Det er ikke meningen å bombe deg med spørsmål

 

Endret 25. november 2014 av Roman88

[Aleks855]

Skissa ser ok ut. Jeg ville kanskje ikke kalt kundetabellen "Tlf", men det er sikkert bare en slurvefeil.

 

Men apropos tlf; det er ofte hensiktsmessig å ha en hjelpetabell mellom Kunde og Tlf, slik at du kan lagre et arbitrært antall telefonnummer per kunde. Samme med e-postadresser. Dette ville nok vært gjort i praksis.

 

Tabellen for tlf-nummer kan ha kundeid, tlfnr, og en beskrivelse (mobil, jobb, hjem, eventuelt kanskje de er to eiere av den samme bilen).

 

1. Ja, du kan droppe hjelpetabellen mellom Reparasjon og Bil. Hvis en kunde bestiller rep på to biler, så kan det like gjerne registreres som to forskjellige bestillinger. Men begge deler er greie måter å gjøre det på. Da blir det en-til-en mellom reparasjon og bil.

 

2. Ja, det høres fint ut.

 

3. Det finnes en begrensning for hvor store tall som kan lagres som INT. Jeg husker ikke helt hvor grensa går, men du kan f. eks. ha en attributt som skal være et 10-sifret tall. Det laveste er da 1000000000 og det høyeste er 9999999999. Hvis grensa for INT er mellom de to tallene, så kan ikke 9999999999 lagres som INT men må være BIGINT.

 

For å forhindre denne problematikken, så kan det være fordelsmessig å lagre tall som ikke krever matematiske operasjoner, som en streng CHAR(n).

 

For postnummer så spiller dette liten rolle. 4-sifrede tall er lett innafor grensa, så det kan man egentlig gjøre som man vil.

 

DATETIME er en egen variabeltype, så der trenger vi ikke samme resonnement. Alle begrensninger er allerede satt mtp. at vi bare har 12 mnd. i et år, 60 sekunder i et minutt osv. Og det er lenge til vi trenger mer enn 4 siffer for årstall.

 

 

Det er ikke meningen å bombe deg med spørsmål

 

Bedre at du spør enn at du lurer.

Endret 26. november 2014 av Aleks855

[Roman88]

Hei igjen Alex!
Et lite spørsmål.
Vet du hvordan kardinaliteten fungerer når vi to tabeller som er sammenkoblet av en hjelpetabell?
Si det øverste eksempelet med biblioteket.

Skjermbilde_2014_11_12_kl_12_45_26.png
En bok kan ha flere forfattere.
En forfatter kan ha skrevet flere bøker.
En bok kan ha max: flere forfattere

En bok kan ha min: en forfatter.

Derfor får hjelpetabellen Max:mange og min:1 på bok-hjelpetabell.
Men hva er det som definerer hvilke max og min verdier bok tabellen skal ha, mellom bok-hjelpetabell?

Endret 27. november 2014 av Roman88

[Aleks855]

Siden en bok kan ha flere forfattere, så må den kunne ha mange relasjoner til hjelpetabellen. Det samme gjelder hjelpetabellen på forfatter-sida.

 

Jeg ville hatt en-til-mange begge veier.

[Roman88]

Siden en bok kan ha flere forfattere, så må den kunne ha mange relasjoner til hjelpetabellen. Det samme gjelder hjelpetabellen på forfatter-sida.

 

Jeg ville hatt en-til-mange begge veier.

Takk for svar Aleks

 

Om du får tid så hadde det vært helt rått om du kunne hjulpet meg med en siste oppgaver for å se om den er riktig. Du får se hva du orker, det er jo tross alt fredag

 

oppgaven: Togbilletter:

På jernbanestasjonen skal man ha et system for billettsalg. I denne omgang skal du bare lage et forenklet system, hvor vi agrenser virkeligheten kraftig. Du skal ta utgangspunkt i togavganger, og disse går alle fra Kristiansand Jernbanestasjon (NSB). En togavgang beskrives ved et avgangsnummer, et tognummer, en dato og en avgangstid. For å kunne kjøpe billett på NSB-stasjonen må man være registrert som kunde med navn, adresse og telefonnummer. NSB har behov for å kunne sende ut informasjon til alle kundene sine pr.epost. Det må selvsagt være mulig for en tog kunde å kjøpe billetter til ulike togavganger. Billetten må angi vognnummer, sitteplassnummer, om sitteplassen er for røykere eller ikke røykere og prisen som skal betales.

 

 

spørsmål:

1. Jeg er litt usikker på forholdet mellom tog_avgang og billett.

En tog avgang kan ha flere billetter.

En billett kan gjelde for forskjellige avganger?

Derfor mange-mange.

Blir dette feil?

Eller blir det mer riktig å tenke at en billett gjelder for en avgang.

Derfor en-mange?

 

2.Billett tabellen.

Et tog har begrenset med plasser.

Vognnr og sitteplassnr må derfor være primærnøkler for å unngå at kunder kjøper billett som gjelder samme sitte plass I en gitt vogn.

Blir dette riktig?

Om jeg oppretter en ny attributt som heter "billettID" og bruker kun den som PK så vil kunder kunne kjøpe samme billett til samme sete og samme vogn?

 

 

Endret 28. november 2014 av Roman88

[Aleks855]

1. Jeg kan ikke svare på hvorvidt en billett gjelder for flere togavganger. Det må du selv bestemme deg for om scenariet skal inkludere.

 

2. Billett må ha en ID, og denne IDen skal aldri brukes mer enn én gang. Jeg tok kanskje toget i fjor, og fikk billetten med ID 65. Da skal denne billetten ha informasjon om meg som kunde, togavgang (som du har) og diverse andre attributter.

 

Vogn- og plassnr. er ikke alltid relevant da man ikke alltid reserverer en fast plass. Man bare finner seg en plass. Disse burde da kunne være NULL, og burde ikke være nøkler av noe slag.

 

Pris og kundeID kan du beholde.

[Roman88]

Jeg må bare si tusen takk for all hjelpa Aleks!
Jeg hadde eksamen i IT og fikk en 6er!
Det hadde jeg ikke nok klart uten hjelpa di.
Jeg håper du får en fantastisk jul, og godt nyttår!!!!

Endret 14. desember 2014 av Roman88

[arne22]

Imponerende eksempel på bruk av diskusjonsforum ifm med skole/utdanning

[Aleks855]

Jeg må bare si tusen takk for all hjelpa Aleks!

Jeg hadde eksamen i IT og fikk en 6er!

Det hadde jeg ikke nok klart uten hjelpa di.

Jeg håper du får en fantastisk jul, og godt nyttår!!!!

 

Det gleder meg å høre. Gratulerer!

 

Håper du også får ei fin feiring!

Endret 14. desember 2014 av Aleks855