40 Графики "субект - отношения» (ERD)

№40 Diagrams "субект - отношения» (ERD). Видове връзки (един към един, един-към-много, много-към-много). Изграждане на схема на база данни въз основа на диаграмите ERD

Целта на моделиране на данни - предоставя на разработчиците EIS схема концептуална база данни под формата на един или повече модели на местни модели, които могат да бъдат сравнително лесно нанесени всяка система за база данни.

Най-често срещаните начини за моделиране на данни диаграми са "субект-връзка" (ERD). Нотация, която за първи път е въведен от Питър Чен през 1976 г. и беше доразвита в творчеството на Ричард Баркър. Различни средства CASE употреба малко по-различен от всеки друг нотация ERD. Един от най-често срещаните бройни системи, предлагани Баркър (Oracle Designer). В SilverRun CASE-инструмент използва вариант на нотацията Чен. методология CASE-инструмент Ервин, ER / Студио, Дизайн / IDEF използва IDEF 1Х.

MetodologiyaIDEF1H е разработен за американската армия и се използва широко в държавни агенции, финансови и индустриални корпорации. Е разработването на методологии IDEF 1, но по-фокусирани върху автоматизация и по-лесно да се разбере. Тя ви позволява да се изгради модел на данните, което се равнява на релационния модел, нормализира до трета нормална форма.

Diagrams "същност- отношения" (ERD) са предназначени за развитието на модели на данните и да осигури стандартен начин за определяне на данните и връзките между тях.

В действителност, с помощта на ERD извършва подробно проектира система за съхранение на данни, както и документирана същност система и как те си взаимодействат, включително идентификация на предмети, важни за домейна предмет (лице), свойствата на тези обекти (атрибутите) и връзката им с други обекти (облигации).

Тази диаграма техника, използвана предимно за проектиране на релационни бази данни (макар че може да се прилага с успех и за моделиране на йерархични и мрежови бази данни).

Diagrams "същност- отношения", включват:

Моделиране на структурата на базата данни с използване на алгоритъма за нормализирането на ситуацията, описана в предишните глави, той има сериозни недостатъци:

1. Първоначално поставяне на всички атрибути на едно отношение е много неестествено работа. Интуитивно, разработчикът проектира още веднъж отношения в съответствие с установените лица. Дори и да се ангажират с насилието срещу друг и да се създаде една или повече връзки към включват всички очакваните качества, той е доста неясен смисъл на тази връзка.
2. Невъзможно е да се определи веднага списъка на атрибутите. Хората имат навика да се обадите различни имена на едно и също нещо, или обратното, да назове имената на някои от различни неща.
3. За нормализиране на процедурите, необходими за да се разпределят според атрибутите, което също е много лесно, тъй като трябва изрично да напишете всички зависимости. дори и тези, които са очевидни.

В реалния дизайн на структурата на базата данни се използва друг метод - т.нар семантичен моделиране. Семантичната моделиране е структури за моделиране на данни, въз основа на значението на данните. В различни изпълнения диаграми лице-връзката (- Entity-запознанството ER) се използват като инструмент за семантичен моделиране.

Ще опишем работата с ER-диаграми, близки до Баркър нотация е доста лесно да се разберат основните идеи. Тази глава е по-скоро илюстрация на методите на семантична моделиране, отколкото пълна въведение в тази област.

Основни понятия на ER-диаграми

Определение 1. Същността - клас от подобни обекти, информация за които следва да бъдат взети под внимание в този модел.

Всяко предприятие трябва да има име, изразена чрез съществително в единствено число.

Примери за лица могат да бъдат такива видове обекти като "доставчик", "Персонал", "Фактура".

Всяка структура, в модела изобразени под формата на правоъгълник с името:

Определение 2. Копие от същността - това е един конкретен представител на юридическото лице.

Така например, представител на "служителя" на юридическо лице може да бъде "Полицай Смит".

Копия лица трябва да бъде различима. т.е. Предприятието трябва да има някои качества, които са уникални за всеки отделен случай на предприятието.

3. Умение Definition лице - с име функция, която е юридическо лице, имот.

Атрибутът име трябва да бъде изразена в единствено число (с възможност за характеризиране прилагателни).

Примери за лице атрибути "Служител" може да бъде атрибути като "брой на персонала", "Име", "Име", "Средна", "Позиция", "заплата" и т.н.

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

4. Определяне ключов дух - не-излишни набор от атрибути, по който се оценява в комбинация са уникални за всеки субект, например. Irredundancy се крие във факта, че премахването на атрибут на ключа прекъсва своята уникалност.

Предприятието може да има няколко различни ключове.

Ключови характеристики са представени в диаграмата, като подчерта:

Дефиниция 5. Комуникация - това е някаква връзка между двете автономни. Едно лице може да бъде свързано с друго предприятие или на себе си.

Връзките позволяват едно цяло, за да намерите и други юридически лица, свързани с него.

Така например, отношенията между лица могат да бъдат изразени чрез следната фраза - ". Служител може да има няколко деца", "Всеки служител е длъжен да се регистрира точно в същата катедра"

Графично линк, представляван от линия, свързваща двете автономни:

Всяка връзка има два края, както и една или две имена. Името обикновено се изразява в устна форма неопределени "трябва", "свои", и т.н. Всеки един от елементите, се отнася към края си връзка. Понякога имената не са написани поради тяхната очевидност.

Всяка връзка може да има един от следните видове комуникация.

Вид на връзката, едно към едно означава, че едно копие на първото лице (вляво) се свързва с един-единствен екземпляр на втората структура (вдясно). Едно към едно често показва, че всъщност имаме само един същество неправилно разделена на две.

Съобщение тип едно към много означава, че едно копие на първото лице (вляво) се свързва с множество копия на второто лице (вдясно). Това е най-често използваният тип комуникация. Ляв лице (от "онзи") е майка. надясно (от "много") - дъщерно дружество. Типичен пример за такава връзка е показан на фиг. 4.

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

Всяка връзка може да има едно от следните две условия за комуникация.

Модалност "да" означава, че едно копие на лице може да бъде свързано с едно или повече копия на другото предприятие, а не може да се свърже с всеки един случай.

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

Съобщението може да бъде от различни начини с различни краища (както е показано на фиг. 4).

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

От ляво на дясно: "Всеки служител може да има няколко деца."

От дясно на ляво: "Всяко дете трябва да принадлежи на точно един служител."

Един пример за развитието на една проста ER-модел

В развитието на ER-модели, ние трябва да се следната информация за домейна:

1. Списъкът на лицата, на домейни.
2. Списък на образуванията атрибути.
3. Описание на отношенията между лица.

ER-диаграми са удобни с това, че лица освобождаване процес, атрибути и връзки е повтаряща се. Разработено първата версия на приблизителната графиката, ние ще ги пречисти, интервюиране на експерти в областта. В тази документация, която записва резултатите от интервюта сами са ER-диаграми.

Да приемем, че нашата задача е да се разработи информационна система по нареждане на едро търговска компания. На първо място трябва да се разгледа на предметната област и процесите, които протичат в него. За тази цел, ние интервюирахме служителите на компанията, прочетете документацията, учат под формата на поръчки, фактури и т.н.

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

• Съхранява информация за клиентите си.
• Печат на фактури за продадените стоки.
• За да се следи за наличието на продукти на склад.

Изберете всички съществителни в тези предложения - това ще бъдат потенциални кандидати за лица и принадлежности, които да ги анализират (странен термин, ние ще вземем въпросителен знак):

• Купувачът - очевиден кандидат за предприятието.
• Товарителница - очевиден кандидат за предприятието.
• Стоки - очевиден кандидат за същността
• Склад (?) - и като цяло, колко магазина има компания? Ако повече от един, той ще бъде кандидат за новото предприятие.
• Наличност на стоки (?) - е вероятно да се припише, но атрибутът кой орган?

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

Задайте въпрос на управителя, ние открихме, че фирмата има няколко склада. Освен това, всеки продукт може да се съхранява в множество складове, както и да се продават във всеки магазин.

Къде да поставите същността на "Фактура" и "Склад" и това, което те свързват? Задайте си въпроса как тези лица са свързани помежду си и със същността на "клиент" и "продукт"? Купувачите купуват стоки, докато получаване на фактури, в които са включени данни за броя и цената на закупените стоки. Всеки клиент може да получи няколко сметки. се изисква всяка пратка, която се освобождава от един клиент. Всяка фактура трябва да съдържа няколко продукта (там не са празни отгоре). Всеки елемент от своя страна, може да бъде продаден до няколко купувачи в някои разходи. Също така, всеки законопроект да бъде приключен с определен вид и по всяко съхранение може да се запише много режийни. По този начин, след изясняване на графиката ще изглежда по следния начин:

Това е време да се мисли за атрибутите на предприятието. Пред служителите на компанията, ние открихме следното:

В хода на по-нататъшното разговор с мениджъра аз бях в състояние да се изясни концепцията на различни цени. Оказа се, че всеки продукт има известна текущата цена. Тази цена, на която се продава продуктът в момента. Разбира се, тази цена може да се промени с течение на времето. Цената на същите стоки в различни законопроект, издаден по различно време, може да варира. По този начин, има две цени - цената на стоките в товарителницата и текущата цена на стоката.

Със зараждащата се идея за "Списък на стоките в пратката, имайте предвид, че е" доста ясно. Същност "фактура" и "продукт" свързана връзка един с друг като много-към-много. Такава връзка, както отбелязахме по-рано, трябва да се разделят на два вида комуникация е едно към много. Това изисква допълнителен субект. Това е същността на същността и "Списък на продукти в пратката." връзката си със същността на "Фактура" и "продукт" се характеризира със следната фраза - "всяка фактура е необходимо да има повече от един запис в списъка на стоки в товарителницата", "всяко вписване в списъка на стоките в товарителницата трябва да съдържа точно една фактура", "може да се включи всеки елемент няколко записа от списъка на стоки в товарителницата "," е необходимо всеки запис в списъка на стоки в товарителницата, че са свързани с точно един елемент. " Атрибути "брой стоки в товарителницата" и "Цената на стоки в товарителницата" са атрибутите на същността "на стоките, в списъка на пратка".

По същия начин се процедира с връзката, свързваща същността на "склад" и "продукт". Ние се въведат по-вещество "Продукт е на склад." Умение на този субект ще бъде "номер на стоки на склад." По този начин, продуктът ще бъде листвани на и размера на това на всеки състав ще бъде негова.

Сега можете да направите всичко това в диаграма:

Концептуален и физическа ER-модел

Разработено горе например ER-диаграми на пример на концептуална схема. Това означава, че графиката не взема под внимание специфичните особености на СУБД. Според тази концептуална схема, може да се изгради физическата схема. който има такива функции да бъдат разглеждани като СУБД допустимите видове и имена на полета и таблици, почтеност ограничения и т.н. Физическата версия на диаграмата на фиг. 9 може да се появи, например, както следва:

В тази схема всяка структура е таблица, база данни, всеки атрибут се превръща в колона на съответната таблица. Моля, обърнете внимание на факта, че в много таблици, например, "CUST_DETAIL" и "PROD_IN_SKLAD", в духа на "Запис на консигнация списък" и "Продуктът е в наличност", има нови атрибути, които не са били в концептуалния модел - ключов родител маси атрибути мигрирали към таблиците за деца, за да се осигури връзка между масите с помощта на външни ключове.

Лесно е да се забележи, че в резултат на масата веднага са в 3NF.

Реал средство за моделиране на данни не е формален метод за нормализиране на отношенията и на така наречената семантична моделиране.

В различни изпълнения диаграми лице-връзката (- Entity-запознанството ER) се използват като инструмент за семантичен моделиране.

Entity-отношенията диаграми позволяват да използвате интуитивен графичен нотация за моделиране на лица и техните взаимоотношения.

Разграничаване между концептуални и физически ER-диаграми. Концептуална схема не се вземат предвид специфичните характеристики на базата данни. Физически диаграми са изработени съгласно концептуалното и представляват трансформират на определена база данни. По същество, някои от тях са таблици, атрибути стане колони на таблицата в концептуалната схема (по този начин счита за валидна за дадени видове СУБД данни и имена на колони), комуникациите са реализирани, като мигрират ключовите атрибути на предприятието майка и да се създаде външни ключове.

С правилното определяне на масата за единица получена скоро ще бъде в 3NF. Основното предимство на този метод е, че моделът е изграден чрез последователни подобрения на оригиналните класациите.

В тази глава, които илюстрират методите, ER-симулации не са обсъдени в по-сложни аспекти на диаграми, като подтипове роля допуска комуникация недопустимо поради идентифициране комуникация и т.н.