В една по-ранна статия за моделиране на данни обещахме да ви дадем набор от упражнения, за да практикувате намирането на обекти и атрибути. Ето втората част от нашия проблемен набор. Насладете се.
Проблем 1:Държави
Описание:
Намерете правилните субекти и техните атрибути, които да представят всички страни по света, техните вътрешни региони (които могат да бъдат наречени щати, провинции или региони) и техните градове. Искаме да представим името на всяка страна, континента, датата на независимост, вида на правителството и населението. За всеки регион (или провинция, щат и т.н.) искаме да съхраняваме столицата, името на губернатора и населението. И накрая, за всеки град искаме да имаме име, дата на основаване, население и брой училища на жител. Бихме искали също така да представим това, което всяка страна нарича вътрешни региони.
Решение:
От описанието на проблема с домейна можем ясно да идентифицираме 3 субекта:Country , Region и City .
За Country обект намираме следните атрибути:name , governmentType , population и independenceDay .
За Region обект, откриваме атрибутите name , governorName , population и capitalCity .
За City , имаме name , foundationDate , population и schoolsPerHabitant .
Моделирането на данни се извършва на етапи, наречени итерации. В този момент повтаряме. Връщаме се в Country обект и добавете нов атрибут. Последното изречение от описанието ни помоли да представим името на всяка държава за нейните вътрешни региони. Това име трябва да е на ниво държава, така че ще добавим нов атрибут, наречен categoryRegion до Country субект.
Въпрос:
Населението е представено в Country , Region и City нива. Смятате ли, че това е правилно? Съхранява ли се дублирана информация? Как допускате това?
↑ Щракнете върху логото, за да прегледате модела във вашия браузър | Изтеглете модела като png файл
Проблем 2:Самолет
Описание:
Нова бюджетна авиокомпания иска да влезе на пазара и се нуждае от проста система за управление на своите активи. За да ни помогнем да изградим правилната система, помолихме няколко души да дефинират ключова информация за всяка нова авиокомпания. Въз основа на коментарите по-долу предложете няколко обекта с атрибути за система за управление на самолет.
Опитен пилот:
Работил съм в доста авиокомпании и съм прекарал хиляди часове във въздуха. Винаги искат една и съща информация, когато сменя работодателя. Първо, те искат да знаят името ми, рождения ми ден – много авиокомпании наемат само пилоти в рамките на определен възрастов диапазон. И винаги трябва да проверяват моята сертификация – имам специален лицензионен номер, който им помага да направят това. Броят на летените часове също е много важен; това им казва много за пилота. Щастлив съм, че съм толкова опитен! И, разбира се, винаги ми дават номер на служител – не знам защо, но те се позовават на мен, използвайки номера вместо фамилното ми име.
Представител на производителя на самолети:
Всяка авиокомпания се нуждае от самолет. Цялото описание на всеки самолет е много сложно и мога да продължа да описвам продуктите си от векове, но момчетата с бели якички от авиокомпаниите обикновено се интересуват само от основната информация. Разбира се, те искат да знаят колко пътници могат да летят в самолет – помага им да изчислят разходите, ползите и т.н. И винаги питат за обхвата на круиз, за да знаят колко далеч може да лети всеки самолет. Разбира се, те се нуждаят от името на производителя и името на модела, които да поставят в книгите си. О, и доколкото чух, те винаги дават специални вътрешни номера на всеки самолет, който закупят.
Диспечер на полети:
Има някои основни факти, които пазим за всеки полет на нашето летище. Полетът трябва да има определен номер за идентификация (като FG 432). Трябва да знаем летищата на заминаване и пристигане. И времето също е много важно. Ние съхраняваме не само планираното време на заминаване и пристигане, но и реалното време – самолетите може да закъснеят или дори да пристигнат предсрочно.
Решение:
В нашето описание ясно идентифицираме 3 обекта:Aircraft , Pilot и Flight . След това намираме атрибутите на всеки обект.
За Aircraft обект имаме manufacturer , model , passengerCapacity , cruisingRangeMiles и internalNumber .
За Pilot обект откриваме следните атрибути:employeeNumber , firstName , lastName , birthDate , licenseNumber и flownHours .
И накрая, за Flight ние идентифицираме flightNumber , departureAirport , destinationAirport , scheduledDepartureTime , scheduledArrivalTime , realDepartureTime и realArrivalTime .
За да опростим този модел на данни, приемаме, че всички полети са насрочени за всички дни от седмицата.
↑ Щракнете върху логото, за да прегледате модела във вашия браузър | Изтеглете модела като png файл
В някои случаи описанието на нашия домейн включва атрибути, които трябва да игнорираме. Например решихме да изключим продължителността на полета от този модел на данни, защото можем да го изчислим от реалното време на пристигане и действително заминаване.
Проблем 3:Ръководство за ресторант
Описание:
Самуел иска да създаде онлайн ръководство за ресторанти. Вече има много такива уебсайтове, но той иска да се съсредоточи върху конкретните налични ястия, а не върху самия ресторант. Той е наистина ентусиазиран от идеята си и ето как ни я описа:
Искам да опиша ресторантите подробно на моя сайт, така че имам нужда от основните неща, като имената и адресите им. Адресът трябва да е точен:не само улицата и номерът, но и градът, държавата и държавата. Да, държава; Искам да стана международен! Освен това искам на всеки от тях да бъде даден определен стил, като, знаете, китайски, италиански или нещо подобно. Всеки от тях ще бъде класиран с определен брой звезди
По-важното е, че искам да се съсредоточа върху храната! Ресторантите сервират хиляди ястия и за всяко от тях имам нужда от името и вида на ястието – предястие, основно ястие или десерт. Има различни предястия в различни страни, така че трябва да съхранявам и информация за произхода на предястието. А за основните ястия... добре, мисля, че ще е хубаво да се осигури броят на калориите за хората на диети. Десертите също трябва да съдържат такава информация.
И искам ВСЯКО ястие да бъде показано, заедно с текущата му цена! О, това ми напомня:нека сложим и напитки там. Името, цената... и може би нивото на алкохола, като се замисля.
Въз основа на горното описание предложете няколко субекта и техните атрибути за онлайн ръководство за ресторант на Самуел.
Решение:
Първият обект, който имаме, е Restaurant с атрибутите на name , addressStreet , addressNumber , city , state и country . Други атрибути в Restaurant са:stars и style .
Следващата ни идея може да бъде да създадем обект, наречен Meal и му дайте атрибутите name , type и price . Ако обаче прочетем пълното описание на проблема, ще открием специфични атрибути за десерти, основни ястия и предястия. Затова решаваме да бракуваме Meal и отидете с 3 обекта:Main_course , Appetizer и Dessert .
За MainCourse , ще имаме следните атрибути:name , category и price .
За Appetizer обект, имаме атрибути, наречени name , country и price .
За Dessert намираме атрибутите name , calories и price .
И накрая, Beverage обект с има атрибутите name , alcoholLevel и price .
↑ Щракнете върху логото, за да прегледате модела във вашия браузър | Изтеглете модела като png файл
Проблем 4:Музикални групи
Описание:
Компания за музикално производство иска да моделира света на музикалните групи. Срещнахме се с един от нейните представители и му зададохме няколко въпроса. Прочетете интервюто по-долу и намерете правилните субекти и техните атрибути за модел на музикални групи.
Вертабело: Какви хора има в света на музиката?
Представител: Много, но мисля, че ни трябват само няколко. Групите се състоят от певци и музиканти. И, разбира се, техните мениджъри. За всички тях искаме имената и фамилните им имена в системата. Певците и музикантите обикновено също имат прякор. Музикантите свирят на определен инструмент, а певците имат определен тип глас, като сопрано или тенор.
V: Ами мениджърите? Как поддържате връзка с тях?
R: Зависи. Някои от тях предпочитат мобилни телефони за бърза комуникация, други обичат да им се изпращат имейли, за да могат да обмислят всичко. Мисля, че имаме нужда и от двата вида информация тук.
V: И всички тези хора...
R: ... формирайте музикални групи, да. Всяка група има име, разбира се. Те обикновено свирят различни видове музика, но ние винаги ги приписваме само на един стил, като рок или метъл. това е важно. Трябва да знаем колко време са свирили заедно, защото младите групи имат тенденция да се появяват и изчезват много бързо. Обикновено искаме да знаем кога са изиграли последния си концерт и каква е цената на билета.
V: Имате ли нужда от нещо друго?
R: Трябва да съхраняваме информация за песните. Леле, песните са сложни. Те имат специфични видове текстове, определен ключ, множество инструменти... наистина сложни неща.
V:И всичко това важно ли е за вас?
R: Е, да, но всъщност вече имаме система за песни, така че тук можем... добре, мисля, че ще бъдем добри само с името и продължителността на песента. И може би датата на създаване.
Въпрос:
При дадена песен можем ли да използваме този модел на данни, за да я съпоставим с нейната група? Или нещо липсва?
Решение:
Първият обект, който откриваме, е MusicBand с атрибутите name , mainStyle , foundationDate , lastShowDate и lastShowPlace .
Следващият обект е Musician , където имаме следните атрибути:firstName , lastName , nickName и instrument .
Singer субектът следва подобен модел:имаме като атрибути firstName на певеца , lastName , nickName и voiceLevel .
Следващият ни обект е Song , който има следните атрибути:name , duration и creationDate .
И накрая, последният обект, който идентифицирахме, е Manager; има атрибутите на firstName , lastName , emailAddress и cellPhone .
↑ Щракнете върху логото, за да прегледате модела във вашия браузър | Изтеглете модела като png файл
