C, PHP, VB, .NET

Дневникът на Филип Петров


* Entity Relationship (ER) модел

Публикувано на 22 януари 2009 в раздел Бази от Данни.

При проектирането на база от данни първо се започва от анализ на предметната област. Нужно е да си изясним абстрактно семантиката на разглежданите обекти. В последствие се преминава и до изготвяне на конкретният им модел и връзката им с конкретни типове данни.

ER модела е един от известните семантични модели за проектиране на бази от данни. Характерно за него е използването на графично представяне на базата от данни, чрез „ER диаграма“. Една ER диаграма обикновено съдържа следните компоненти:

1. Същност – това е наборът от информация за реалeн обект от предметната област. Това може да е информацията за конкретен ученик, учител, учебник, т.н.;

2. Клас – множество от същности, които имат сходни и общи свойства. Това са например всички ученици, всички учители, всички учебници, и т.н. В ER диаграма те се изобразяват като правоъгълници:

Класове обекти

3. Атрибути – това са отделните характеристики за всеки клас. Например всеки учител има ЕГН, име, пол, адрес, и т.н. Уникалната характеристика за всяка същност, която еднозначно го идентифицира спрямо другите същности в даден клас, се нарича „ключ“. Например за ученик от дадена учебна паралелка това може да бъде неговия идентификационен номер, за студент от университет това може да е неговия факултетен номер, и т.н. За всеки клас обекти е задължително да съществува поне един ключ, за да може да бъдат обектите „различими“ един от друг. Възможно е да има повече от един отличителен атрибут за даден клас обекти. В ER диаграмата атрибутите се изобразяват като елипси:

Атрибути

4. Връзки – използват се за свързване на различни същности с препратки. Например връзка се осъществява, когато един учител започне да преподава на даден клас ученици, когато някой служител на фирма бъде назначен в даден отдел, и т.н. Връзките също се характеризират със свойства и също са характеристики на обекти от реалния свят. В ER диаграмата се изобразяват чрез ромб. Има три основни типа връзки:

4.1. Връзка 1:1 се получава когато една същност от даден клас е свързана с точно една същност от друг клас.

Връзка 1:1

4.2. Връзка 1:M (едно към много) се получава когато една същност от даден клас А може да има повече от една връзка със същности от друг клас Б, но една същност от клас Б може да има само една връзка със същност от клас А.

Връзка 1:M

4.3. Връзка M:M (много към много) се получава когато същност от даден клас А има повече от една връзка със същност от друг клас Б и същност от клас Б има повече от една връзка с обекти от клас А.

Връзка M:M

5. Характеризиращи същности – отнасят се към обекти от предметната област, чието съществуване е невъзможно самостоятелно. Например учебните часове са характеризиращи обекти за учебната програма на даден предмет. В ER диаграмата обикновено се обозначават с двойна линия на правоъгълника.

Характеристичен обект

6. Подклас – това са същности, които допълват даден базов за тях клас с допълнителни атрибути. Връзката между базов клас с негов подклас се изобразява с триъгълник.

Подклас

Обикновено при проектирането на ER диаграма първо се определят първо класовете, а след това техните връзки.

Задача: Направете ER диаграма на база от данни за университети, която съдържа:

– Име на университета и град в който се намира;
– Номер и име на факултетите в даден университет;
– Списък с преподавателите в даден факултет;
– Декан на факултета;
– Водени учебни предмети;
– Списък със студенти, записали даден учебен предмет;
– Списък на задочниците и фирмата, в която работят.

Примерно решение:

В примерното решение има един проблем – ако даден студент все още не се е записал за нито един учебен предмет, ние няма да знаем в кой факултет е записан той. Как се решава споменатия казус?

 



14 коментара


  1. Иво каза:

    В горната ER диаграма от връзката между преподавател и предмет излиза че един преподавател може да води много учебни предмети. Не е ли по-логично един учебен предмет да бъде воден от много преподаватели, а един преподавател да води само един учебен предмет както е на практика. Оттам Преподавател:Предмет М:1

  2. Ами въобще не си прав. Ще дам пример с доц. Гоцева – тя води Пик-2, Пик-3, БД и още куп други курсове, т.е. 1 преподавател води „М“ного предмети. В обратната страна – ами предмета „Бази Данни“ се води само от доц. Гоцева. Не може да има двама титуляри на един предмет.

  3. Иво каза:

    Да, разбирам. Бях си представил C,C++,Java,DB…=Компютри и оттам многото преподаватели по компютри, без да има титуляр между тях, и си представих че Д. Гоцева не преподава по Химия. Спирам да философствам :) Със здраве!

  4. Според мен това е хем така хем иначе:) няма да давам досадни примери от ТУ , но действително си има доста титуляри на различни предмети.Така че просто ER диаграмата може да е и с 1:М и М:М.Толкова! Асистент Петров, може ли съвет на кои теми да обърнем най-голямо внимание за контролното по БД?

  5. Не бих могъл да кажа, че има някоя тема, която да е маловажна. Можете да пропуснете темите, които са свързани с потребители, права и привилегии. Наблегнете на SELECT заявките много и научете CREATE TABLE перфектно.

  6. Guest каза:

    Как се реализира връзката „Декан“ между таблици „Факултети“ и „Преподаватели“(1:1) на SQL,1:M и M:M ми станаха ясни,ако може да разясните малко за 1:1 връзките ще Ви бъда благодарен :)

  7. @Guest – добавя се колона в таблицата „факултети“, в която се записват id-тата на преподаватели, които са декани на съответните факултети. Връзката става 1:1 когато й се сложи атрибут „UNIQUE“, т.е. в тази колона не може да има повторения на числа.

  8. TU-Sofia каза:

    А има ли начин да се реализира с външен ключ, без да се вмъква нова колона в таблица „Факултети“ и ако може да поясните?

  9. Може да се направи с колона в „преподаватели“, но там ще има излишество на данни – очаква се преподавателите в един факултет да са много, а деканът да е само един от тях. Тоест ще имаме множество NULL стойности в тази колона, което не желаем.

    Друг вариант е чрез междинна „свързваща“ таблица, в която да се записват id-та на факултети и id-та на техните декани.

    Но най-добрият си остава с колона в таблица „факултети“.

  10. Dimitrov каза:

    Трябва ли да се сложат атрибути (елипса) за ID-тата в ER диаграмата?

  11. Трябва да се слагат.

  12. Ivo каза:

    В учебника пише, че това с наследяването го има само при EER модела и означенията са малко по-различни – кръг за връзките ISA вместо триъгълник, както е показано тук. Ние към кой модел трябва да се придържаме?

  13. Какво имаш предвид под „наседяване“?

    Вие можете да използвате който модел пожелаете – не е важно визуално дали ще е триъгълник или кръг, важно е да е правилно моделирано. Аз лично препоръчвам на студентите да използват означенията от тази статия, защото са най-отчетливи визуално.

  14. Ivo каза:

    Благодаря! А колкото до наследяването – имах предвид това с подкласовете :)

Добави коментар

Адресът на електронната поща няма да се публикува


*