Database
 sql >> база данни >  >> RDS >> Database

Въведение в модела на данни за ER

Моделът на данни за субект-връзка , наричан още ER , е един от различните модели на данни, които можете да използвате, за да разсъждавате относно вашите данни.

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

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

Чудесно е, защото не мислите за подробностите за внедряването, а вместо това мислите само за данните си и как са организирани . И докато правите това, вие сте принудени да анализирате проблема по начини, за които не сте мислили преди.

Намирам диаграмите за бърза помощ, като ви помагат да анализирате сценарий, в който са включени данни.

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

Има 2 елемента, които съставят ER модел:

  • обектите
  • отношенията

Обектите са типове данни, като елементи или хора, които имат общи свойства.

Отношенията са отношенията между обектите.

Нека ви дам пример, нека да поговорим за книгите и техните автори. Имаме 2 субекта :

  • книга
  • автор

Конкретна книга е екземпляр на обекта книга.

Тъй като имаме 2 субекта, имаме 2 отношения между тях. Едната е връзката между една книга и същността на авторите. Едната е връзката между един автор и същността на книгите. Ако се замислим, имаме:

  • една книга има автор
  • един автор може да напише много различни книги

Визуалната нотация за обекти

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

Забележка:Има много различни начини за начертаване на ER диаграми. Ще използвам този, който според мен , е по-визуален и има повече смисъл.

Обектите са представени като правоъгълници, с някакъв текст в тях, за да ги идентифицират:

Визуалната нотация за отношения

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

Обърнете внимание, че не създадох 2 връзки „книгата има автор“ и „авторът е написал книга“. Направих една-единствена „авторска“ връзка между Книга и Автор.

Кардиналитети

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

  • Колко автори може да има една книга?
  • Може ли един автор да напише няколко книги?
  • Трябва ли един автор да напише поне една книга, за да бъде наречен автор?
  • Може ли една книга да бъде написана от няколко автора?
  • Може ли една книга да съществува поне без автор?

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

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

Предпочитам числа, които правят нещата по-ясни:

Цифрите по-горе означават това:една книга може да бъде автор на 1 или повече автори. n означава произволен брой елементи.

И един автор може да е автор от 0 книги (може би сега пише една) до безкраен брой книги.

Първата се нарича отношение нула към много . Втората е връзкаедин към много .

Можем също да имаме:

  • отношения едно към едно
  • Връзки много към много
  • отношения нула към едно

Атрибути

Всеки обект може да има един или повече атрибути.

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

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

Ето как можем да представим горната информация:

Атрибути на идентификатор

Обектите трябва да бъдат идентифицирани с уникален ключ. Обектът на книгата може да бъде еднозначно идентифициран чрез ISBN атрибута. Всяка книга има един ISBN номер (като се има предвид, че ние не представляваме едно копие на книга, а „заглавие“ на книга).

Ние идентифицираме атрибутите на първичния ключ, като ги залагаме:

Авторът, от друга страна, няма уникален идентификатор в момента. Двама автори могат да имат едно и също име.

Следователно трябва да добавим уникален ключов атрибут. Например id атрибут:

Атрибутите на идентификатора могат да обхващат множество атрибути.

Например идентификационният номер на паспорта и държавата на автора уникално идентифицират лицето и могат да заменят id атрибут, който добавихме:

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

Атрибути на релация

Атрибутите не са уникални за обектите. Отношенията също могат да имат атрибути.

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

Но все още ни липсва информация. Трябва да знаем кога човекът е заел книгата и датата, на която я е върнал, за да можем да съхраняваме информацията за цялата история на дадена книга в нашата библиотека. Тази информация не принадлежи нито на книгата, нито на читателите; тя принадлежи на релацията:

Слаби обекти

По-горе говорихме за първичните ключове и как помощта уникално идентифицира обект.

Някои субекти зависят от други обекти за съществуването си и се наричат ​​слаби субекти .

Да предположим, че трябва да моделираме поръчки за онлайн магазин.

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

Тогава също трябва да знаем какво са поръчали. Създаваме слаб обект „поръчан артикул“, който представлява всеки артикул в количката в момента на плащане.

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

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

Рекурсивни отношения

Един обект може да има рекурсивна връзка със себе си. Да предположим, че имаме лице. Можем да моделираме връзката родител-дете по следния начин:

Човек може да има от 0 до n деца, едно дете има 2 родители (като се вземе предвид най-простият сценарий).

ISA отношения

ISA означава IS-A и е начин за моделиране на обобщения в модела на ER.

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

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

Небинарни отношения

Не всяка връзка е строго бинарна. Да вземем сценарий за урок.

Днес в 10:00 часа в стая на училището се провежда урок с учител, който говори с клас по физика.

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

Можем да го моделираме по следния начин:


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Как се стартират паралелни планове – част 1

  2. SQL Право присъединяване

  3. Друг аргумент за съхранените процедури

  4. Aqua Data Studio

  5. Нови стандартни размери на базата данни на Azure SQL