Лекция Разработване на ER диаграма за анализираната предметна област
Съдържание на лекцията: методи за разработване на ER диаграми.
Целта на лекцията: да се разработят ER диаграми за анализираната предметна област.
Основните задачи на концептуалния дизайн са да се определи предметната област на системата и да се формира изглед на софтуера от гледна точка на бъдещите потребители на бази данни. Като пример, нека проектираме концептуален модел на система, предназначена да съхранява информация за книги и области на знанието, представени в библиотека. Описанието на предметната област беше дадено по-рано (лекция 4).
Нека отделим основните набори от обекти. На първо място, има набор от обекти КНИГА, всяка книга има уникален шифър, който е нейният ключ, и редица атрибути, които са взети от описанието на предметната област. Наборът от екземпляри на набор дефинира набора от книги, които се съхраняват в библиотеката. Всеки екземпляр от набора КНИГИ не съответства на конкретна книга на рафта, а на описание на някаква книга, което обикновено се дава в тематичния каталог на библиотеката. Всяка книга може да присъства в няколко екземпляра и това са само онези конкретни книги, които се намират на рафтовете на библиотеката. За да отразим това, трябва да въведем набор от обекти INSTANCES, който ще съдържа описания на всички екземпляри на книги, които се съхраняват в библиотеката. Всеки екземпляр на обекта INSTANCES съответства на конкретна книга на рафта. Всяко копие има уникален номер за достъп, който уникално идентифицира конкретна книга. Освен това всяко копие на книгата може да бъде или в библиотеката, или в ръцете на някой читател, като във втория случай за това копие допълнително се посочва датата на вземане на книгата от читателя и датата на очакваното връщане на книгата. Спомнете си, че връзките сазадължителноинезадължително. Ако обект от един тип е задължително свързан с обект от друг тип, тогава има задължителна връзка между тези типове обекти. В противен случай връзката не е задължителна.
Съществува връзка "един към много" (1:M) между обектите BOOK и COPIES, която е задължителна и от двете страни. Какво определя този тип връзка? Можем да предположим, че всяка книга може да присъства в библиотеката в множество екземпляри, така че връзката е едно към много. Освен това, ако в библиотеката няма нито едно копие на тази книга, тогава ние няма да съхраним нейното описание, следователно, ако книгата е описана в обекта BOOK, тогава поне едно копие от тази книга присъства в библиотеката. Това означава, че от страна на книгата връзката е задължителна. По отношение на същността на ЕКЗЕМПЛЯРИТЕ, в библиотеката не може да има нито един екземпляр, който да не принадлежи към определена книга, следователно от страна на ЕКЗЕМПЛЯРИТЕ връзката също е задължителна.
От описанието на предметната област знаем, че всеки читател може да държи в ръцете си няколко екземпляра от книги. За да отразим тази ситуация, трябва да направим връзка между обектите READERS и INSTANCES. А защо не между същностите ЧИТАТЕЛИТЕ и КНИГИТЕ? Защото читателят взима от библиотеката конкретно копие на конкретна книга, а не просто книга. Но как да разберете коя книга има даден читател? И това може да се установи чрез допълнителна връзка между обектите ЕКЗЕМПЛЯРИ и КНИГИ, като тази връзка свързва по една книга с всеки екземпляр, така че можем недвусмислено да определим във всеки един момент кои книги са в ръцете на читателя, въпреки че свързваме с читателя само инвентарните номера на взетите книги. Установена е връзка "един към много" между обектите READERS и INSTANCES, но неизисква се и от двете страни. Читателят в момента може да не държи нито една книга в ръцете си, а от друга страна, този екземпляр от книгата може да не е притежание на никой читател, а просто да стои на рафт в библиотеката.
От описанието на предметната област знаем, че всяка книга може да съдържа информация от няколко области на знанието, а също така в библиотеката може да има много книги, свързани с една и съща област на знанието, така че трябва да установим връзка много към много между SYSTEM_CATALOG и КНИГИ, задължително от двете страни. Всъщност в системния каталог не трябва да има такава област на знанието, информация за която не е представена в никоя книга на нашата библиотека, в противен случай би било безсмислено. И обратно, всяка книга трябва да бъде причислена към една или повече области на знанието, за да може читателят да я намери по-бързо. Тази релация образувасъставен набор от обекти, за удобство на такива релации понякога се дават имена на обекти - съществителни (в допълнение към името на релацията). Нека наречем този набор ИНФОРМАЦИЯ. Графично едно съставно множество се обозначава с правоъгълник, начертан около релацията и множествата обекти, участващи в нея (фигура 7.1).
Нека проектираме концептуален модел на система, предназначена за съхраняване на информация за издателска компания (предметната област е описана в лекция 4). Нека започнем разработването на модела, като подчертаем основните обекти.
Фигура 7.2 - ER диаграма на модела на издателската компания
И така, диаграмите обект-връзка ви позволяват да използвате визуални графични символи за моделиране на обекти и техните взаимоотношения. Основното предимство на метода е, че моделътсе изгражда по метода на последователните уточнения на изходните диаграми. Концептуалните диаграминеотчитат спецификата на конкретни системи за управление на бази данни.
Лекция. Примери за концептуално моделиране
Съдържание на лекцията: примери за концептуално проектиране на база данни.
Целта на лекцията: да се изучат чрез примери методите за разработване на концептуални схеми на бази данни.
Както беше отбелязано, отношенията могат да се разглеждат като обекти, в който случай те се наричат набори от съставни обекти. Повечето бизнес проблеми изискват използването на съставни обекти. Преди това примерите включваха два набора от обекти (двоичниотношения) във всички отношения. Една релация обаче може да свързва три или повече набора от обекти (n-aryрелации). Нека илюстрираме тази концепция с пример.
Помислете за опита на компания, занимаваща се с международна търговия със стоки. Концепцията на компанията е следната: намиране на производители в различни страни, чиито продукти винаги отговарят на високи стандарти за качество; намиране на фирми, които продават стоки; за установяване на бизнес отношения между производители и продавачи, доставяйки на последните стоки, закупени от избрани производители. Компанията има офиси в различни страни; персоналът на всеки офис се състои от търговски агенти и купувачи.
Нека създадем концептуален модел на данни на компанията. Компанията има клиенти, търговски агенти, продукти, производители на тези продукти. Изберете следните обекти: PRODUCT, CUSTOMER, TRADING_AGENT, MANUFACTURER. Нека установим подходяща връзка между тях, както е показано на фигура 8.1:
Да предположим, че искаме да следим количеството на всеки продукт, продаден на всеки клиент. Трябва да присвоим атрибута QUANTITY на един от обектите. Ако това е атрибут на обекта GOODS, тогава ние не го правимще можем да различим количеството стоки, продадени на различни клиенти, но ако атрибутът е присвоен на обекта CLIENT, няма да можем да различим стоките, продадени на клиента. Следователно КОЛИЧЕСТВОТО е атрибутна връзкатамежду продукта и клиента, а не продукта или клиента поотделно. И така, релацията "sold_to"сама по себе си е набор от обекти или съставен обект, на който е присвоен атрибутът QUANTITY (Фигура 8.2).
Фигура 8.2 - Правилният модел за показване на броя на продажбите
Да предположим, че искаме да запишем броя на продажбите на всеки артикул, продаден на всеки клиент вконкретенден. След това свързваме релацията "sold_to"с обекта DATE и присвояваме атрибута QUANTITY на тази нова релация. Моделът е по-удобно представен като единична тристранна връзка (Фигура 8.3). Трябва да се отбележи, че сред обектите на нашия модел има производители на стоки. Нека изведем този обект на диаграмата. Диаграмата също така показва кардиналностите на връзките.
| * |
Фигура 8.3 - Пълен модел за проследяване на продажбите
За да илюстрирате друга концепция в концептуалното моделиране, разгледайте следния пример. Строителната фирма издига различни сгради. Всички сгради изискват различни материали в различни количества. На различните етапи от проекта работят различни екипи (монтьори, зидари, мазачи и др.). При изготвянето на работния график фирмата променя състава на екипите. Работниците се разпределят в различни екипи според тяхната квалификация. Екипите се съставят по начин, необходим за конкретна сграда. На всяка бригада е назначен бригадир. Един работник може да ръководи един екип и да работи в другпрости работници. Нека създадем концептуален модел на данни, който може да предостави необходимата информация на собственика на компанията. Фигура 8.4 показва връзката между сгради и материали.
Кардиналността на връзката много към много между BUILDINGS и MATERIAL_TYPE. Атрибутът ADDRESS се отнася само за набора BUILDING и може да се използва като ключ за идентифициране на конкретна сграда. Полето около връзката "изисква"показва, че използваме тази връзка като набор от съставни обекти. Даваме на този набор от обекти атрибута QUANTITY, елементите на този набор ще бъдат двойки: тип сграда и материал.
Важно е да се отбележи, че в този пример наборът от обекти MATERIAL_TYPE еконцептуаленобект, а нефизическиобект.Концептуаленобект – обект, обозначаващ вида неща, т.е. елементите на това множество са абстрактни понятия. Тоест, всеки елемент от този набор обозначаватипматериал, а не физическо "парче" материал.Физическинабор от обекти е набор от обекти, чиито елементи са физически обекти. Това понятие за концептуален обект срещу физически обект често се използва в концептуалното моделиране на данни. В разгледания по-рано пример за библиотечен проблем наборът от обекти „Книги“ съхранява информация законцептуалникниги, докатофизическитекниги са копия, томове или, както е обичайно в нашия модел,екземплярина книги. Въпреки че читателят може да не е в състояние да направи разлика между тези понятия, за да реши как да моделира данните, човек трябва да разбере от каква информация се нуждае потребителят на базата данни.
Сега ще покажем формирането на бригади и назначаването на работници и бригадири. Друг пример за концептуаленна обектния набор – TEAM_TYPE – това не саконкретнибригади, атиповебригади (бригада арматурници, зидари и др.). Връзката между сградата и вида на екипажа представлява конкретния екип, назначен да извършва този вид работа на тази сграда. Ще разглеждаме това отношение като обект, нека го наречем ЕКИП.
За всеки екип като елемент от обектното множество ЕКИП се избират работни дни. Това означава, че има връзка много към много между TEAM и DATE.
Следва разпределението на работниците и бригадирите по бригади. Връзката "is_foreman"има кардиналност едно към много, защото една бригада има един бригадир, но един човек може да ръководи няколко бригади.
Фигура 8.5 - Модел на формирането на бригади и бригадири
Фигура 8.6 е обединена диаграма, представяща пълния модел на данни за строителна компания.
Фигура 8.6 - Модел на данни за строителна компания
Моделите, обсъдени по-горе, се основават на информация, вградена в типовете въпроси, които мениджърите или ръководителите задават. Следователно тези модели са в основата на информационните и контролните системи. Трябва да се отбележи, че концептуалният модел може да бъде извлечен от отчетните форми, използвани в бизнес транзакциите.