I en tidigare artikel om datamodellering lovade vi att ge dig en uppsättning övningar för att öva på att hitta enheter och attribut. Här är den andra delen av vår problemuppsättning. Njut.
Problem 1:Länder
Beskrivning:
Hitta rätt enheter och deras attribut för att representera alla länder i världen, deras inre regioner (som kan kallas stater, provinser eller regioner) och deras städer. Vi vill representera varje lands namn, kontinent, datum för självständighet, typ av regering och befolkning. För varje region (eller provins, stat, etc.) vill vi lagra huvudstaden, namnet på guvernören och befolkningen. Slutligen vill vi för varje stad ha namn, grunddatum, befolkning och antal skolor per invånare. Vi skulle också vilja representera vad varje land kallar sina inre regioner.
Lösning:
Från domänproblembeskrivningen kan vi tydligt identifiera tre enheter:Country , Region och City .
För Country enhet hittar vi följande attribut:name , governmentType , population och independenceDay .
För Region enhet, upptäcker vi attributen name , governorName , population och capitalCity .
För City , vi har name , foundationDate , population och schoolsPerHabitant .
Datamodellering görs i steg som kallas iterationer. Vid det här laget upprepar vi. Vi går tillbaka till Country entitet och lägg till ett nytt attribut. Den sista meningen i beskrivningen bad oss att representera varje lands namn för dess inre regioner. Det namnet bör vara på landsnivå, så vi lägger till ett nytt attribut som heter categoryRegion till Country enhet.
Fråga:
Befolkningen är representerad i Country , Region och City nivåer. Tycker du att detta är korrekt? Lagras det duplicerad information? Hur tillåter du detta?
↑ Klicka på logotypen för att förhandsgranska modellen i din webbläsare | Ladda ner modellen som en png-fil
Problem 2:Flygplan
Beskrivning:
Ett nytt lågprisflygbolag vill komma in på marknaden och behöver ett enkelt system för att hantera sina tillgångar. För att hjälpa oss bygga rätt system bad vi några personer att definiera nyckelinformation för ett nytt flygbolag. Baserat på kommentarerna nedan, föreslå några enheter med attribut för ett flygplanshanteringssystem.
En erfaren pilot:
Jag har arbetat på en hel del flygbolag och jag har tillbringat tusentals timmar i luften. De ber alltid om samma information när jag byter arbetsgivare. Först vill de veta mitt namn, min födelsedag – många flygbolag anställer bara piloter inom ett visst åldersintervall. Och de måste alltid kontrollera min certifiering – jag har ett speciellt licensnummer som hjälper dem att göra det. Antalet flygtimmar är också mycket viktigt; det säger dem mycket om piloten. Tur att jag är så erfaren! Och naturligtvis får jag alltid ett anställdsnummer – jag vet inte varför, men de hänvisar till att jag använder numret istället för mitt efternamn.
En flygplanstillverkares representant:
Varje flygbolag behöver flygplan. Hela beskrivningen av vilket flygplan som helst är mycket komplex och jag skulle kunna fortsätta att beskriva mina produkter i evigheter, men tjänstemännen från flygbolagen är vanligtvis bara intresserade av den grundläggande informationen. Naturligtvis vill de veta hur många passagerare som kan flyga i ett flygplan – hjälper dem att beräkna kostnader, fördelar etc. Och de frågar alltid om kryssningsräckvidden så att de vet hur långt varje plan kan flyga. Naturligtvis behöver de tillverkarens namn och modellnamnet att skriva i sina böcker. Åh, och vad jag hört ger de alltid speciella interna nummer till alla flygplan de köper.
En flygledare:
Det finns några grundläggande fakta som vi har om varje flyg på vår flygplats. Flygningen måste ha ett visst nummer av identifieringsskäl, (som FG 432). Vi behöver känna till avgångs- och ankomstflygplatserna. Och tiden är också väldigt viktig. Vi lagrar inte bara den planerade avgångs- och ankomsttiden, utan även de verkliga tiderna – flygplan kan vara försenade eller kan till och med anlända före schemat.
Lösning:
I vår beskrivning identifierar vi tydligt tre enheter:Aircraft , Pilot och Flight . Sedan hittar vi attributen för varje entitet.
För Aircraft enhet vi har manufacturer , model , passengerCapacity , cruisingRangeMiles och internalNumber .
För Pilot enhet vi upptäcker följande attribut:employeeNumber , firstName , lastName , birthDate , licenseNumber och flownHours .
Slutligen, för Flight vi identifierar flightNumber , departureAirport , destinationAirport , scheduledDepartureTime , scheduledArrivalTime , realDepartureTime och realArrivalTime .
För att förenkla denna datamodell gör vi antagandet att alla flyg är schemalagda på alla dagar i veckan.
↑ Klicka på logotypen för att förhandsgranska modellen i din webbläsare | Ladda ner modellen som en png-fil
I vissa fall innehåller vår domänbeskrivning attribut som vi måste ignorera. Till exempel beslutade vi att utesluta flygets varaktighet från denna datamodell eftersom vi kan beräkna den från de verkliga ankomst- och avgångstiderna.
Problem 3:Restaurangguide
Beskrivning:
Samuel vill skapa en restaurangguide online. Det finns redan många sådana hemsidor, men han vill fokusera på de speciella rätterna som är tillgängliga snarare än på restaurangen i sig. Han är verkligen entusiastisk över sin idé och så här beskrev han den för oss:
Jag vill beskriva restauranger i detalj på min webbplats, så jag behöver grundläggande saker som deras namn och adresser. Adressen måste vara exakt:inte bara gatan och numret, utan också staden, staten och landet. Ja, land; Jag vill bli internationell! Dessutom vill jag att var och en av dem ska få en speciell stil, som, ni vet, kinesiska, italienska eller något liknande. Var och en av dem kommer att rankas med ett visst antal stjärnor.
Och ännu viktigare, jag vill fokusera på maten! Restauranger serverar tusentals måltider, och för var och en av dem behöver jag rättens namn och typ – förrätt, huvudrätt eller efterrätt. Det finns olika aptitretare i olika länder, så jag måste lagra information om aptitretarnas ursprung också. Och för huvudrätter ... ja, jag tror att det kommer att vara trevligt att ge antalet kalorier för personer som går på dieter. Desserter bör också innehålla denna typ av information.
Och jag vill att VARJE rätt ska visas tillsammans med dess nuvarande pris! Åh, det påminner mig:låt oss sätta på drycker där också. Namnet, priset... och kanske alkoholnivån, kommer att tänka på.
Baserat på beskrivningen ovan, föreslå några enheter och deras attribut för Samuels restaurangguide online.
Lösning:
Den första enheten vi har är Restaurant med attributen name , addressStreet , addressNumber , city , state och country . Andra attribut i Restaurant är:stars och style .
Vår nästa idé kan vara att skapa en enhet som heter Meal och ge den attributen name , type och price . Men om vi läser hela problembeskrivningen hittar vi specifika attribut för desserter, huvudrätter och aptitretare. Så vi bestämmer oss för att skrota Meal och gå med 3 enheter:Main_course , Appetizer och Dessert .
För Main_course , kommer vi att ha följande attribut:name , category och price .
För Appetizer enhet, vi har attribut som heter name , country och price .
För Dessert vi hittar attributen name , calories och price .
Slutligen, Beverage enhet med har attributen name , alcoholLevel och price .
↑ Klicka på logotypen för att förhandsgranska modellen i din webbläsare | Ladda ner modellen som en png-fil
Problem 4:Musikband
Beskrivning:
Ett musikproduktionsbolag vill förebilda musikbandens värld. Vi träffade en av dess representanter och ställde några frågor till honom. Läs intervjun nedan och hitta rätt enheter och deras attribut för en modell av musikband.
Vertabelo: Vilken typ av människor finns det i musikens värld?
Representant: Många, men jag tror att vi bara behöver några. Banden består av sångare och musiker. Och, naturligtvis, deras chefer. För alla vill vi ha deras för- och efternamn i systemet. Sångare och musiker brukar också ha ett smeknamn. Musiker spelar ett visst instrument och sångare har en speciell rösttyp, som sopran eller tenor.
V: Hur är det med chefer? Hur håller du kontakten med dem?
R: Det beror på. Vissa av dem föredrar mobiltelefoner för snabb kommunikation, andra gillar att få e-post så att de kan tänka igenom allt. Jag tror att vi behöver båda typerna av information här.
V: Och alla dessa människor...
R: …bilda musikband, ja. Varje band har såklart ett namn. De spelar vanligtvis olika sorters musik, men vi tilldelar dem alltid bara en stil, som rock eller metal. Det är viktigt. Vi måste veta hur länge de har spelat tillsammans, för unga band har en tendens att komma upp och försvinna väldigt snabbt. Vi brukar vilja veta när de spelade sin senaste konsert och vad biljettpriset var.
V: Behöver du något mer?
R: Vi behöver lagra information om låtar. Oj, låtar är komplicerade. De har specifika typer av texter, en viss tonart, ett antal instrument inblandade... riktigt komplicerade saker.
V:Och är allt detta viktigt för dig?
R: Tja, ja, men vi har faktiskt redan ett system för låtar, så här kan vi... ja, jag tror att vi kommer att bli bra med bara låtens namn och varaktighet. Och kanske skapelsedatumet.
Fråga:
Med tanke på en låt, kan vi använda den här datamodellen för att matcha den med dess band? Eller saknas något?
Lösning:
Den första enheten vi hittar är MusicBand med attributen name , mainStyle , foundationDate , lastShowDate och lastShowPlace .
Nästa enhet är Musician , där vi har följande attribut:firstName , lastName , nickName och instrument .
Singer enhet följer ett liknande mönster:vi har som attribut sångarens firstName , lastName , nickName och voiceLevel .
Vår nästa enhet är Song , som har följande attribut:name , duration och creationDate .
Slutligen är den sista enheten vi identifierade Manager; den har attributen för firstName , lastName , emailAddress och cellPhone .
↑ Klicka på logotypen för att förhandsgranska modellen i din webbläsare | Ladda ner modellen som en png-fil
