1 / 96

Анализ на данните 1

Анализ на данните 1. Гл.ас. Д-р Даниела Гоцева http://dgoceva.info. Entity Relationship Modelling. Жизнен цикъл на анализа на БД Компоненти на Entity Relationship Diagram Какво е relationship? Entities, attributes и relationships в системата Степен на връзката.

clove
Download Presentation

Анализ на данните 1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Анализ на данните 1 Гл.ас. Д-р Даниела Гоцева http://dgoceva.info БД-лекции

  2. Entity RelationshipModelling • Жизнен цикъл на анализа на БД • Компоненти на Entity Relationship Diagram • Какво е relationship? • Entities, attributes и relationships в системата • Степен на връзката БД-лекции

  3. Жизнен цикъл на анализа на БД БД-лекции

  4. Жизнен цикъл на анализа на БД (2) • Начално разучаване на БД • Анализ на ситуациите и изискванията • Дефиниране на проблемите и ограниченията • Дефиниране на обектите • Дефиниране на обхвата и границите • Дизайн на БД • Създаване на концептуален дизайн • Създаване на логически дизайн • Създаване на физичеки дизайн • Реализация и зареждане • Инсталация на СУБД и създаване на БД • Зареждане или преобразуване на данните БД-лекции

  5. Жизнен цикъл на анализа на БД (3) • Тест и оценка • Тестване на БД • Настройка на БД • Оценка на БД и приложните програми, които работят с нея • Операции • Създаване на необходимия информационен поток • Поддържане и развитие • Въвеждане на промени • Подобрения БД-лекции

  6. Дизайн на БД БД-лекции

  7. Дизайн на БД (2) • Концептуален дизайн • Entity Relationship modelling and normalisation • Проверка на модела на данните • Избор на СУБД и софтуера • Data Model Mapping • Логически дизайн • Превод на концептуалния модел в дефиниции на таблици, изгледи… • Физически дизайн • Оптимизация на производителността, достъпа и структурите в паметта • Дизайн на разпределена БД БД-лекции

  8. Entity RelationshipModelling Entity Relationship (ER) modelling • Е design tool • Е графично представяне на БД на системата • Предоставя концептуален модел на данните на високо ниво • Поддържа потребителското възприемане на данните • Е независимо от СУБД и хардуера • Има много варианти • Се състои от entities, attributes и relationships БД-лекции

  9. Entities • entity – произволен обект в системата, който трябва да се моделира и съхрани • Отделните обекти се наричат entities • Групите от еднакви по тип обекти се наричат entity types или entity sets • Entities се представят с правоъгълници (с прави или със заоблени крайща) • Съществуват 2 типа entities; слаби (weak) и силни (strong). БД-лекции

  10. Attribute • Всички данни свързани с entity се съхраняват в техните атрибути. • attribute - property на entity. • Всеки атрибут може да има произволна стойност от domain. • Всяко entity в даден тип: • Може да има произволен брой атрибути. • Може да има различни стойности на атрибути по сравнение на всяко друго entity. • Има еднакъв брой атрибути. БД-лекции

  11. Attribute (2) • Атрибутите могат да бъдат: • Прости или съставни • С една стойност или множество стойности • Атрибутите могат да се покажат в ER модели • Означават се с овали и са свързани с техните entity. • Забележете, че типа на entity може да има голям брой атрибути... Ако се покажат всички, диаграмата става объркваща. Показват се само онези, които добавят информация към ER диаграмата, или изясняват позицията. БД-лекции

  12. Keys • key e данна, която идентифицира уникално всяка стойност на даден тип entity. • Кандидат ключ (candidate key) е атрибут или множество атрибути, които идентифицират уникално всяка стойност на тип entity. • Тип entity (entity type) може да има >=1 възможни кандидат ключове, измежду които се избира един първичен ключ (primary key). • Съставен ключ (composite key) е кандидат ключ, който се състои от >=2 атрибута • Името на атрибута на първичния ключ се подчертава. БД-лекции

  13. Връзки (Relationships) • Тип “връзка” е значеща асоциация между entity типове. • Връзката е асоциация между entities, където асоциацията включва едно entity от всеки участващ във връзката тип entity. • Типовете връзки се представят на ER диаграма чрез множество линии. • Днес съществуват множество означения... БД-лекции

  14. Връзки (2) • Според оригиналното Chen означение, връзките се записват в ромб. Пример: managers manage employees: • Като алтернатива може да се означи връзката като етикет на линията: БД-лекции

  15. Степен на връзката • Степен на връзката – брой entities участващи във връзката. • Ако участват само два типа entity типа на връзката е binary relationship type. • Ако три типа entity участват във връзка тя е ternary relationship type. БД-лекции

  16. Степен на връзката (2) • Съществува и n-ary relationship (quaternary или unary). • Унарна връзка (Unary relationship) е известна като рекурсивна връзка. • Това е връзка, в която един и същи тип участва > 1 с различни роли. • В примера: “employees are managed by employees”. • Ако е необходима повече информация за мениджърите се въвежда нов entity type - manager. БД-лекции

  17. Степен на връзката (3) • Допуска се да има >=2 различни връзки между едни и същи entities. • Не навсякъде е възможно да има атрибути като част на връзка. За да се поддържа тази възможност се добавя нов entity type. БД-лекции

  18. Премахване на тернарна връзка • Тернарните връзки в ER модела се премахват. Понякога се заместват от множество двоични връзки, които свързват двойки на оригиналната тернарна връзка. • Тази модификация може да доведе до загуба на информация – не е ясно кой sales assistant продава на кой customer кой product. БД-лекции

  19. Премахване на тернарна връзка (2) • Връзките се записват с глаголи, а имената на типовете entity са съществителни. • Пример: връзката “sells” става тип на entity “sale”. • sales assistant може да се свърже с зададен customer и двамата към продажба на конкретен продукт. • Този процес работи и при връзки от по високо ниво. БД-лекции

  20. Кардиналност • Повечето връзки не са 1:1 • Например, мениджъра управлява >1 служители • Това се управлява от кардиналността на връзката, която може да бъде в една от 4 категории: • One to one (1:1) relationship • One to many (1:m) relationship • Many to one (m:1) relationship • Many to many (m:n) relationship • В ER диаграма, ако края на връзката е линия, кардиналността е едно, а ако е “пачи крак” - е много. БД-лекции

  21. Кардиналност (2) • Връзка 1:1 – брачна връзка • Връзка 1:m – един мениджър управлява много служители, но всеки служител има само по един мениджър. БД-лекции

  22. Кардиналност (3) • Връзка M:1 – много студенти изучават един курс “БД”. • Връзка M:N – един лектор обучава много студенти, а всеки студент слуша лекции при много лектори. БД-лекции

  23. Опционност • Една връзка може да е задължителна или не. • Ако връзката е задължителна: • entity от единия край на връзката се свързва с entity от другия. • Опционните връзки са различни: • Напр.: студент-учебен план. За студента учебния план е задължителен, следователно връзката ‘student has curriculum’ е задължителна. • Учебният план съществува преди да се запишат студентите в курса, т.е. независимо дали има или не студенти, трябва да се знае как ще се обучават. Връзката ‘curriculum is used by student’ е опционна. • За представяне на опционна връзка, се записва кръг или ‘0’ в опционния край на връзката. БД-лекции

  24. Опционност (2) • Важно е да се знае дали връзката е задължителна или не. При създаване на ново entity, се изисква наличие на задължителните връзки. • Опционна връзка: БД-лекции

  25. Entity Sets • Понякога е полезно да се пробват различни примери на entities от ER модела, за да се провери дали кардиналността и опционността са правилни. В този случай се създава ‘entity set diagram’, за да се покажат примерите нагледно. БД-лекции

  26. Проверка на правилността на модела • Използвайте диаграма за да покажете всички възможни връзки. • Направете справка със спецификация на изискванията, дали са правилни. • Ако има забранени връзки, ги означете, както е показано. БД-лекции

  27. Анализ на данните 2 Гл.ас. Д-р Даниела Гоцева http://dgoceva.info БД-лекции

  28. Entity RelationshipModelling 2 • Определяне параметрите на връзката • Създаване на Entity Relationship Diagram • Конструиране на ER модел • Разрешаване на проблемите свързани с ER модели БД-лекции

  29. Определяне параметрите на връзката • За проверка на коректността на параметрите на връзката, се задават 2 въпроса: • Един курс от колко студенти се изучава? Отговор => ‘нула или повече’. • Този отговор ни дава степента на връзката от страна на студента. • Отговор от вида ‘нула или повече’ означава 2 неща: • Частта ‘повече’ показва кардиналността на връзката (М). • Частта ‘нула’ показва, че връзката не е задължителна. • Ако отговорът е ‘един или повече’, то връзката е задължителна. БД-лекции

  30. Определяне параметрите на връзката (2) • Колко курса слуша един студент? Отговор => ‘един’ • Този отговор показва степента на връзката от страна ‘курс’. • Отговор ‘един’ означава кардиналност на връзката 1 и задължителна връзка. • Ако отговорът е ‘нула или един’, то кардиналността е едно, а връзката е незадължителна. БД-лекции

  31. Излишни връзки • Някои ER диаграми завършват с relationship loop. • В такива случаи се прави проверка дали е възможно да се прекъсне цикъла без загуба на информация. • Ако са дадени 3 entities A, B, C, и връзки A-B, B-C и C-A, проверете дали е възможно да се управлява връзката между A и C през B. Ако е възможно, връзката A-C е излишна (redundant relationship). • Задължително се проверява дали има възможност да се опрости ER диаграмата. Така се улеснява и разбирането на останалата информация. БД-лекции

  32. Излишни връзки - пример • Нека са дадени entities ‘customer’ (customer details), ‘address’ (the address of a customer) и ‘distance’ (distance from the company to the customer address). БД-лекции

  33. Разделяне на връзки M:N • Не е задължително връзките M:N в ER модела да са неправилни. Те могат да се заместят с междинно entity. • Заместването се прави, когато: • Връзка M:N скрива entity • Резултатната ER диаграма се разбира по-лесно. БД-лекции

  34. Разделяне на връзки M:N - пример • Нека е дадена системата ‘a car hire company’. Клиентите наемат коли, един клиент може да наеме много коли и една кола може да се наеме от много клиенти. • Връзката M:N може да се прекъсне с добавяне на ‘hire’ entity, което съдържа атрибут ‘date of hire’. БД-лекции

  35. Конструиране на ERмодел - Entities • Преди начертаване на ER модела прочетете внимателно изискванията към системата. Документирайте всяко допускане, което правите. • Определете entities – направете списък на всички възможни entity types. Това са интересуващите ни обекти в системата. По-добре е на този етап да се поставят всички entities и след това да се унищожават излишните на по-късен етап, а не обратното. • Изтриване на дублираните entities – проверява се дали са два различни entity types или две имена от един и същи тип. • Не трябва да се включва системата като entity type, т.е. ако се моделира библиотека, entity types трябва да бъдат books, borrowers и др. • Библиотеката е система и не може да бъде entity type. БД-лекции

  36. Конструиране на ERмодел - атрибути • Разпишете атрибутите на всяко entity (всички свойства, които описват entity и имат отношение към приложението). • Уверете се, че entity types наистина са необходими. • Има ли някой от тях атрибут на друг entity type? • Ако да, направете ги атрибути и ги задраскайте от списъка entity list. • Не трябва атрибут на едно entity да бъде атрибутa и на друго такова ! • Маркирайте primary keys. • Кои атрибути уникално идентифицират инстанциите на този entity type? • Това може да не е осъществимо за някои слаби entities. БД-лекции

  37. Конструиране на ERмодел - Връзки • Дефинирайте връзките • Проверете всяко entity type за връзките му с другите такива. • Опишете кардиналността и опционността на връзките • Потърсете ограниченията между участниците във връзките. • Премахнете излишните връзки • Проверете ER модела за наличие на излишни връзки. • ER моделирането е итеративен процес. Създайте няколко версии, подобрете всяка една от тях докато не постигнете задоволителен резултат. Забележете, че няма само един верен отговор на даден проблем, но някои решения са по-добри от други! БД-лекции

  38. Автобусна компания - пример Автобусна компания за междуградски превози притежава набор от автобуси. Всеки автобус се движи по зададен маршрут, като по някои маршрути се движат >1 автобуси. Всеки маршрут включва набор от градове. Към автобуса са зачислени >=1 шофьори, които се сменят в градовете. Някои градове имат гараж, където автобусите се паркират. Всеки автобус има регистрационен номер и различен брой места. Всеки маршрут се идентифицира от номер. Налична е информация за средния брой пътници на ден за всеки маршрут. Шофьорите имат служебен номер, име, адрес и телефон (незадължителен). БД-лекции

  39. Entities • Bus – компанията има автобуси и съхранява информация за тях. • Route – автобусите пътуват по маршрути. • Town – градовете, през които преминават автобусите. • Driver – в компанията работят шофьори и тя съхранява техните лични данни. • Stage –маршрута се състои от етапи. • Garage – гаража на автобусите, трябва да знаем всеки автобус къде е. БД-лекции

  40. Relationships • Автобусът се движи по маршрут и един маршрут може да има няколко автобуса. • Bus-route (m:1) ‘is serviced by’ • Маршрутът се състои от >=1 етапи. • route-stage (1:m) ‘comprises’ • >= шофьори обслужват всеки етап от маршрута. • driver-stage (m:1) ‘is allocated’ • Един етап от маршрута може да включва няколко или всички градове. • stage-town (m:n) ‘passes-through’ БД-лекции

  41. Relationships (2) • Маршрутът преминава през някои или всички градове. • route-town (m:n) passes-through • Някои от градовете имат гараж. • garage-town (1:1) is situated • Всеки автобус има гараж, където е зачислен и при престой в градовете ползва техните гаражи. • garage-bus (m:1) is garaged БД-лекции

  42. E-R Diagram БД-лекции

  43. Attributes • Bus (reg-no,make,size,deck,no-pass) • Route (route-no,avg-pass) • Driver (emp-no,name,address,tel-no) • Town (name) • Stage (stage-no) • Garage (name,address) БД-лекции

  44. Проблеми с ER модели • Съществуват множество проблеми, които могат да възникнат при създаване на концептуалния модел на БД. В литературата са познати като клопки на връзката (connection traps). • Съществуват два типа клопки: • Ветрило (fan traps) • Пропаст (chasm traps) БД-лекции

  45. Fan traps • Клопка “ветрило” се получава когато модела представя връзки между типове entity, но пътищата между някои entity са двусмислени. Такава ситуация се случва, когато 1:M връзки се разперват към едно entity. БД-лекции

  46. Fan traps (2) • Една сграда съдържа множество отдели и служители, които работят в тях. Кой служител в кой отдел работи? • За да се премахне ветрилото се преструктурира оригиналния ER модел: БД-лекции

  47. Chasm traps • Клопка “пропаст” се получава, когато моделът предполага наличие на връзка между entity types, но пътят не съществува за някои от entity. • Тази ситуация възниква, когато има връзка с частично участие, която формира част от пътя между свързаните entities. БД-лекции

  48. Chasm traps (2) • Един клон има много служители, които определят, следят характеристиките на рентата. Не всички служители имат достъп до характеристиките и не всяка характеристика се управлява от персонала. • Какви характеристики са достъпни на клона? • Някои от участниците в Staff и Property управляват връзката. Някои характеристики не могат да се свържат с клона или с персонала в него. БД-лекции

  49. Chasm traps (3) • Трябва да се добави връзка ‘has’ между Branch and и Property entities. • Трябва внимателно да се изтриват връзки, за които се счита, че са излишни, за да не получи пропаст. БД-лекции

  50. Анализ на данните 3 Гл.ас. Д-р Даниела Гоцева http://dgoceva.info БД-лекции

More Related