I en tidligere artikel om datamodellering lovede vi at give dig et sæt øvelser til at øve dig i at finde entiteter og attributter. Her er anden del af vores problemsæt. God fornøjelse.
Opgave 1:Lande
Beskrivelse:
Find de rigtige enheder og deres egenskaber til at repræsentere alle lande i verden, deres indre regioner (som kan kaldes stater, provinser eller regioner) og deres byer. Vi ønsker at repræsentere hvert lands navn, kontinent, dato for uafhængighed, type regering og befolkning. For hver region (eller provins, stat osv.) ønsker vi at gemme hovedstaden, navnet på guvernøren og befolkningen. Endelig ønsker vi for hver by at have navn, grundlæggelsesdato, befolkningstal og antallet af skoler pr. indbygger. Vi vil også gerne repræsentere, hvad hvert land kalder sine indre regioner.
Løsning:
Fra domæneproblembeskrivelsen kan vi tydeligt identificere 3 enheder:Country , Region og City .
For Country enhed finder vi følgende attributter:name , governmentType , population og independenceDay .
For Region enhed, opdager vi attributterne name , governorName , population og capitalCity .
For City , vi har name , foundationDate , population og schoolsPerHabitant .
Datamodellering udføres i stadier kaldet iterationer. På dette tidspunkt gentager vi. Vi går tilbage til Country enhed og tilføje en ny attribut. Den sidste sætning i beskrivelsen bad os om at repræsentere hvert lands navn for dets indre regioner. Dette navn skal være på landeniveau, så vi tilføjer en ny attribut kaldet categoryRegion til Country enhed.
Spørgsmål:
Befolkningen er repræsenteret i Country , Region og City niveauer. Tror du, at dette er korrekt? Gemmes der duplikerede oplysninger? Hvordan tillader du dette?
↑ Klik på logoet for at få vist modellen i din browser | Download modellen som en png-fil
Opgave 2:Fly
Beskrivelse:
Et nyt lavprisflyselskab ønsker at komme ind på markedet og har brug for et enkelt system til at administrere sine aktiver. For at hjælpe os med at bygge det rigtige system bad vi nogle få personer om at definere nøgleoplysninger for ethvert nyt flyselskab. Baseret på kommentarerne nedenfor, foreslå nogle få enheder med attributter til et flystyringssystem.
En erfaren pilot:
Jeg har arbejdet hos en del flyselskaber, og jeg har brugt tusindvis af timer i luften. De beder altid om de samme oplysninger, når jeg skifter arbejdsgiver. Først vil de gerne vide mit navn, min fødselsdag – mange flyselskaber beskæftiger kun piloter inden for en vis aldersgruppe. Og de skal altid tjekke min certificering – jeg har et særligt licensnummer, som hjælper dem med det. Antallet af fløjne timer er også meget vigtigt; det fortæller dem meget om piloten. Jeg er heldig, at jeg er så erfaren! Og selvfølgelig får jeg altid et medarbejdernummer – jeg ved ikke hvorfor, men de henviser til, at jeg bruger nummeret i stedet for mit efternavn.
En flyproducents repræsentant:
Alle flyselskaber har brug for fly. Hele beskrivelsen af ethvert fly er meget kompleks, og jeg kunne blive ved med at beskrive mine produkter i evigheder, men de funktionærer fra flyselskaber er normalt kun interesserede i den grundlæggende information. Selvfølgelig vil de gerne vide, hvor mange passagerer der kan flyve i et fly – hjælper dem med at beregne omkostninger, fordele osv. Og de spørger altid om krydstogtrækkevidden, så de ved, hvor langt hvert fly kan flyve. Selvfølgelig skal de have producentens navn og modelnavnet til at skrive i deres bøger. Åh, og efter hvad jeg har hørt, giver de altid specielle interne numre til ethvert fly, de køber.
En flyveleder:
Der er nogle grundlæggende fakta, som vi har om hver flyvning i vores lufthavn. Flyet skal have et bestemt nummer af identifikationsgrunde (som FG 432). Vi skal kende afgangs- og ankomstlufthavnene. Og tiden er også meget vigtig. Vi gemmer ikke kun det planlagte afgangs- og ankomsttidspunkt, men også de rigtige tider – fly kan være for sent eller kan endda ankomme før tidsplanen.
Løsning:
I vores beskrivelse identificerer vi tydeligt 3 enheder:Aircraft , Pilot og Aircraft . Derefter finder vi attributterne for hver enhed.
Til Aircraft enhed, vi har manufacturer , model , passengerCapacity , cruisingRangeMiles og internalNumber .
Til Pilot enhed opdager vi følgende attributter:employeeNumber , firstName , lastName , birthDate , licenseNumber og flownHours .
Til sidst til Aircraft vi identificerer flightNumber , departureAirport , destinationAirport , scheduledDepartureTime , scheduledArrivalTime , realDepartureTime , og realArrivalTime .
For at forenkle denne datamodel antager vi, at alle flyvninger er planlagt på alle ugens dage.
↑ Klik på logoet for at få vist modellen i din browser | Download modellen som en png-fil
I nogle tilfælde indeholder vores domænebeskrivelse attributter, som vi skal ignorere. For eksempel besluttede vi at ekskludere flyvarighed fra denne datamodel, fordi vi kan beregne det ud fra de reelle ankomst- og reelle afgangstider.
Opgave 3:Restaurantguide
Beskrivelse:
Samuel vil lave en online restaurantguide. Der findes allerede mange sådanne hjemmesider, men han ønsker at fokusere på de særlige retter, der er til rådighed, snarere end på restauranten selv. Han er virkelig begejstret for sin idé, og sådan beskrev han den for os:
Jeg vil gerne beskrive restauranter i detaljer på mit websted, så jeg har brug for de grundlæggende ting som deres navne og adresser. Adressen skal være præcis:ikke kun gaden og nummeret, men også byen, staten og landet. Ja, land; Jeg vil internationalt! Desuden vil jeg have, at hver af dem får en bestemt stil, som du ved, kinesisk, italiensk eller sådan noget. Hver af dem vil blive rangeret med et bestemt antal stjerner.
Vigtigere er det, jeg vil fokusere på maden! Restauranter serverer tusindvis af måltider, og til hver af dem har jeg brug for rettens navn og type - forret, hovedret eller dessert. Der er forskellige forretter i forskellige lande, så jeg skal også gemme oplysninger om forretternes oprindelse. Og til hovedretter... ja, jeg tror, det vil være rart at give antallet af kalorier til folk på diæter. Desserter bør også indeholde denne form for information.
Og jeg vil have, at HVER ret skal vises sammen med dens aktuelle pris! Åh, det minder mig om:lad os også sætte drikkevarer på der. Navnet, prisen... og måske niveauet af alkohol kommer til at tænke på.
Baseret på ovenstående beskrivelse kan du foreslå nogle få enheder og deres egenskaber til Samuels online restaurantguide.
Løsning:
Den første enhed, vi har, er Restaurant med attributterne name , addressStreet , addressNumber , city , state og country . Andre attributter i Restaurant er:stars og style .
Vores næste idé kunne være at oprette en enhed kaldet Meal og giv den attributterne name , type og price . Men hvis vi læser hele problembeskrivelsen, vil vi finde specifikke egenskaber til desserter, hovedretter og forretter. Så vi beslutter os for at skrotte Meal og gå med 3 entiteter:Main_course , Appetizer og Dessert .
Til Main_course , vil vi have følgende attributter:name , category og price .
Til Appetizer enhed, vi har attributter kaldet name , country og price .
Til Dessert vi finder attributterne name , calories og price .
Til sidst, Beverage enhed med har attributterne name , alcoholLevel og price .
↑ Klik på logoet for at få vist modellen i din browser | Download modellen som en png-fil
Opgave 4:Musikbands
Beskrivelse:
Et musikproduktionsselskab ønsker at modellere musikbandverdenen. Vi mødtes med en af dens repræsentanter og stillede ham et par spørgsmål. Læs interviewet nedenfor og find de rigtige enheder og deres egenskaber til en model af musikbands.
Vertabelo: Hvilken slags mennesker er der i musikkens verden?
Repræsentant: Mange, men jeg tror, vi bare mangler nogle få. Bands består af sangere og musikere. Og selvfølgelig deres ledere. For dem alle ønsker vi deres for- og efternavne i systemet. Sangere og musikere har normalt også et kaldenavn. Musikere spiller et bestemt instrument, og sangere har en bestemt stemmetype, såsom sopran eller tenor.
V: Hvad med ledere? Hvordan holder du kontakten med dem?
R: Det kommer an på. Nogle af dem foretrækker mobiltelefoner til hurtig kommunikation, andre kan lide at få tilsendt e-mails, så de kan tænke det hele igennem. Jeg tror, vi har brug for begge slags oplysninger her.
V: Og alle disse mennesker...
R: … danne musikbands, ja. Hvert band har selvfølgelig et navn. De spiller normalt forskellige slags musik, men vi tildeler dem altid kun én stilart, som rock eller metal. Det er vigtigt. Vi skal vide, hvor længe de har spillet sammen, for unge bands har en tendens til at komme op og forsvinde meget hurtigt. Vi vil normalt gerne vide, hvornår de spillede deres seneste koncert, og hvad billetprisen var.
V: Har du brug for andet?
R: Vi skal gemme oplysninger om sange. Wow, sange er komplicerede. De har bestemte slags tekster, en bestemt toneart, en række instrumenter involveret... virkelig komplicerede ting.
V:Og er alt dette vigtigt for dig?
R: Nå, ja, men vi har faktisk allerede et system til sange, så her kan vi … ja, jeg tror, vi bliver gode med kun sangens navn og varighed. Og måske oprettelsesdatoen.
Spørgsmål:
Givet en sang, kan vi så bruge denne datamodel til at matche den til dens band? Eller mangler der noget?
Løsning:
Den første enhed, vi finder, er MusicBand med attributterne name , mainStyle , foundationDate , lastShowDate og lastShowPlace .
Den næste enhed er Musician , hvor vi har følgende attributter:firstName , lastName , nickName og instrument .
Singer enhed forfølger et lignende mønster:vi har som attributter sangerens firstName , lastName , nickName og voiceLevel .
Vores næste enhed er Song , som har følgende attributter:name , duration og creationDate .
Endelig er den sidste enhed, vi identificerede, Manager; den har attributterne for firstName , lastName , emailAddress og cellPhone .
↑ Klik på logoet for at få vist modellen i din browser | Download modellen som en png-fil
