Запознайте се с диаграмата за ER (Връзка на обект), нейните части и какво често се обърка при създаването й.
Създавали ли сте някога модел на релационна база данни? Или може би се опитвате да създадете първия си? Знаете (или скоро ще разберете), че превеждането на реални проблеми в логиката на базата данни понякога може да бъде доста трудно.
Един от инструментите, които могат да ви помогнат, е диаграмата на ER. Общата мъдрост при проектиране на база данни гласи, че колкото по-добра е вашата ER диаграма, толкова по-лесно ще бъде изграждането на модела на базата данни. Този важен елемент задава тон за всички бъдещи разочарования или успехи. С добра ER диаграма създаването на модел на релационна база данни е доста лесно. Разбира се, грешки могат да бъдат направени във всяка фаза на моделиране на база данни. Въпреки това, наличието на добра диаграма на ER може да ви помогне да избегнете някои от тези грешки.
И така, нека да видим какво представлява диаграмата на ER и как можем да избегнем често срещаните й грешки.
Какво е ER диаграма?
„ER диаграма“ или ERD е съкращение от диаграма на взаимоотношенията на обекта. Той очертава проблема, който трябва да бъде моделиран, но по структуриран начин, който показва връзките между обектите.
Строителни блокове на ER диаграма
ER диаграмите се състоят от следните елементи:
- Обект
- Взаимоотношения
- Атрибути на обект или връзка
Първият елемент на ER диаграмата е обектът . Обектът е обект или събитие, за което искаме да съхраняваме информация. По принцип това е всичко, за което можем да събираме данни. Например, може да съхраняваме данни за служители, ученици, учители, купувачи, продукти, отдели, плащания, местоположения и т.н.
След като имаме обекти, е необходимо да създадем връзки . Връзката показва как един обект е свързан и асоцииран с един или повече други обекти.
Последният елемент на диаграмата на ER е атрибут на обект или връзка . Атрибутът е описание на свойство, принадлежащо на обект или връзка. Атрибутите имат стойности. Някои атрибути за посочените по-горе обекти могат да бъдат:
- Служител, ученик, учител, купувач – Лична карта, име, фамилия, дата на раждане, адрес и др.
- Продукт – ID, категория, описание, цвят, сериен номер и др.
- Отдел – ИД, име на отдел, ръководител на отдел, брой служители и др.
- Плащания – ИД, дата и час, сума.
- Местоположение – Град, пощенски код, регион, държава, континент.
Видове взаимоотношения
Преди да влезем в обичайните грешки, открити в ER диаграмите, е важно да разберем възможните типове взаимоотношения. Повечето грешки при ERD са по същество погрешно дефинирани връзки между обекти.
Има три типа връзки между обектите:
- Едно към едно (1:1)
- Едно към много (1:N)
- Много към много (M:N)
Връзки едно към едно (1:1)
Първият тип връзка е едно към едно , или 1:1 . В тази връзка единичен екземпляр на един обект може да бъде свързан само с единичен екземпляр на друг обект (и обратно, разбира се).
Да кажем, че имаме обекта студент с атрибутите name и фамилия . Имаме и обекта id с единствения атрибут id . Връзката 1:1 би означавала, че един ученик може да има само един идентификационен номер. Това също така означава, че един идентификационен номер може да принадлежи само на един ученик.
Тази връзка много рядко се наблюдава в бази данни. Ако само един идентификационен номер може да бъде свързан само с един ученик, няма нужда да ги разделяте на две различни единици.
Ето пример за тази връзка:
Връзки едно към много (1:N)
Най-често срещаният тип връзка с база данни е едно към много или 1:N . Връзката „един към много“ означава, че всеки отделен екземпляр на един обект може да бъде свързан с множество екземпляри на друг обект. Това също така означава, че всеки екземпляр на втория обект може да бъде свързан само с един екземпляр на първия обект.
Например, има обект купувач с атрибутите id , име и фамилно име . Искаме да установим връзка с обекта плащане който има атрибутите id , дата и стойност . Това е връзка 1:N, защото един купувач може да извърши едно или много плащания. Едно плащане обаче не може да бъде извършено от няколко купувачи; може да се направи само от един купувач.
Ето примера:
Тази връзка може да се види и обратното. В тази ситуация се нарича много към едно или N:1 . Разбира се, това не е нов тип връзка. То е същото като 1:N, но се гледа от обратната посока.
Като пример, да предположим, че имаме обект служител с атрибутите id , име и фамилно име . Искаме да установим служител връзката на обекта отдел който има атрибутите id и име . Връзката между тези две единици е N:1. Това означава, че всеки служител може да работи само в един отдел, но няколко служители могат да работят в същия отдел.
Връзки много към много (M:N)
A Много към много или M:N връзка означава, че всеки екземпляр на първия обект може да бъде свързан с повече от един екземпляр на втория обект. Това също така означава, че всеки екземпляр на втория обект може да бъде свързан с множество екземпляри на първия обект.
Нека видим как работи това между обектите student и лекция . Да кажем, че студент има атрибутите id , име и фамилно име . Обектът лекция има атрибутите id и име . Връзката много към много може да се тълкува по следния начин:един студент може да присъства на една или повече лекции, докато една лекция може да бъде посещавана от един или повече студенти.
Ето диаграмата за този пример:
При моделирането на база данни такива връзки обикновено се разделят на две или повече връзки 1:N или N:1 чрез въвеждане на нови обекти.
Типични грешки, допуснати при създаване на диаграма на ER
Много грешки в диаграмата на ER се вписват в една от тези четири категории:
- Неправилни връзки между обекти
- Използване на екземпляр на обект вместо обект
- Объркване на атрибут с обект
- Сложни атрибути
Нека разгледаме всеки един поотделно.
Неправилни връзки между обекти
Най-честите грешки възникват при дефиниране на връзката между обекти . В отношенията 1:1 обикновено няма грешки. Въпреки това е много лесно да объркате 1:N връзка с M:N връзка. Това обикновено произтича от неразбиране на изискванията, предоставени от крайния потребител. Жизненоважно е да имате много ясно дефинирани изисквания и дълбоко разбиране защо е необходима базата данни и как ще се използва. Ако създадем ER диаграма с недостатъчни данни и непълно разбиране, това най-вероятно ще доведе до погрешно дефиниране на връзките между обектите.
Нека да разгледаме един пример. Ако създавате база данни за банка, най-вероятно ще създадете ER диаграма с обекта клиент с атрибутите id , име и фамилно име . Ще имате и обект, наречен сметка с атрибутите id и тип . Ако ви липсва опит в банковата индустрия, вероятно ще си помислите, че винаги има връзка 1:N между клиента и сметка субекти, както е показано по-долу.
Един клиент може да има няколко сметки в една банка. Въпреки това, акаунт може да бъде притежаван само от един клиент. Това наистина ли е вярно? Може би е, може би не е. Доста банки предлагат съвместни сметки, които могат да се използват от няколко клиента. Създавате ли ER диаграма за банка, която предлага такава услуга? Ако банката не предлага съвместни сметки, значи сте прави:връзката между клиент и сметка е 1:N. Ако обаче банката предлага съвместни сметки, тогава връзката е M:N.
Използване на екземпляр на обект вместо обект
Друга често срещана грешка е използването на екземпляр на обект вместо на обект. Екземпляр на обект е еднократна поява на определен обект – т.е. обект, който всъщност може да бъде атрибут на по-голяма категория.
Да речем, че работим в компания, която разпределя мобилни телефони и лаптопи на определени служители. Така че в нашата база данни ще имаме обект, наречен лаптоп с атрибутите id и модел и субект, наречен служител с атрибутите id , име и фамилно име , нали?
Тук има проблем:лаптопът всъщност не е обект – има и мобилни телефони, за които трябва да се отчита. Решението е да смените обекта лаптоп с по-общ обект, като оборудване . Този обект може да има атрибутите ID , тип и модел , както е показано по-долу. Типът може да се състои от стойности като телефон , компютър , таблет и лаптоп . По този начин няма нужда да създавате отделен обект за всеки тип оборудване.
Можете да намерите примера тук:
Объркване на атрибут с обект
Следващата често срещана грешка е объркването на атрибут с обект. Да приемем, че сме решили да създадем обект, наречен служител който ще се състои от атрибутите id , име , фамилия , дата_раждане , id_department , име_отдел и главен_отдел . Този обект ще ни създаде проблеми, когато създаваме модел на база данни, защото се състои от твърде много атрибути, които не дефинират еднозначно този конкретен обект .
Не забравяйте, че ние дефинирахме обекти като всичко, за което можем да събираме данни. Имайки това предвид, можем да видим, че настоящият служител обектът може да бъде разделен на две субекти:служител и отдел , както е показано по-долу.
Сложни атрибути
Последната често срещана грешка, за която ще говорим, е включването на сложен атрибут в обект. С други думи, имаме атрибут, който всъщност трябва да бъде негов собствен обект .
Да приемем, че имаме обект, наречен студенти който се дефинира от следните атрибути:id , име , фамилия , дата_раждане , адрес и издържан_изпит . Ето, изпит_издържан е сложен атрибут, който се състои от повече от една информация, т.е. идентификатор на изпита и дата и резултат на студента. Ако го оставим така, би било грешка. Вместо това трябва да направим нов обект извън този сложен атрибут . Новият обект може да бъде наречен изпити и се състои от следните атрибути:id , дата , id_students , и резултат .
Можете да намерите примера тук:
Получихте ли полезни съвети за диаграма на ER?
Тези четири вида грешки са най-често срещаните в процеса на създаване на диаграма за ER. Разбира се, няма пълен списък с типични грешки или видове грешки. В реалния живот има вероятност да се случат много видове грешки. Липсата на планиране, недостатъчната техническа поддръжка и прибързаният процес на проектиране на база данни допринасят за собствените си проблеми. Ако някога сте създавали бази данни или сте участвали в тях от страна на бизнеса, вероятно сте изпитали някои от тях! Всички тези обстоятелства водят до различни грешки, някои от които са доста уникални.
Имате ли свой собствен пример за не толкова добра диаграма на спешната помощ? Или може би има някои други грешки, които откривате често? Моля, уведомете ме в секцията за коментари.
