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

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 БД-лекции