4.1 Въведение
Като преобразувате таблиците на базата данни в обикновени таблици, вече можете да анализирате връзките между тях. Броят елементи, взаимодействащи между две свързани таблици, се нарича кардиналност. Кардиналността ви помага да контролирате колко ефективно сте разделor данните си в таблици.
Теоретично всички обекти могат да поддържат взаимоотношения помежду си, но на практика има три типа взаимоотношения между обекти:
- Едно към едно
- Един към много
- много към много
4.2 Комуникация един към един
Ако има само един екземпляр на обект A за всеки екземпляр на обект B, се казва, че те имат връзка едно към едно (често означавано като "1:1"). На ER диаграми такава връзка се обозначава с линия с малка лента в двата края:
Връзката 1:1 обикновено показва, че освен ако нямате основателна причина да ги държите разделени, данните от двете таблици е най-добре да се комбинират в една.
При някои обстоятелства обаче е разумно да се използват таблици с релации 1:1. Ако вашите таблици имат полета с незадължителни данни, като описания, и в много случаи те са празни, има смисъл да преместите всички описания в отделна table, което ще ви позволи да се отървете от честите пропуски и да увеличите ефективността на вашата база данни .
След това, за да картографирате правилно данните, ще трябва да включите поне една идентична колона във всяка table (най-добре е да изберете първичен ключ за това).
4.3 Връзка "един към много".
Този тип връзка възниква, когато запис в една table е свързан с множество обекти в друга. Например, един и същи клиент може да направи няколко поръчки or посетител на библиотека може да заеме няколко книги на едно посещение. Връзките "един към много" (or 1:M за кратко) се изразяват в диаграма, като се използва нотация "пачи крак", Howто е показано в примера по-долу:
За да приложите връзка 1:M, когато планирате база данни, просто добавете първичния ключ от tableта „едно“ като атрибут към tableта „много“. Ако първичният ключ е в друга table, той се нарича "чужд ключ". Таблицата "едно" се счита за родителска table, докато tableта "много" се счита за дъщерна table.
4.4 Връзка много към много
Когато множество обекти в една table могат да бъдат свързани с множество обекти в друга, се счита, че имат връзка много към много (or M:M). Например, такава връзка съществува между ученици и класове, тъй като всеки ученик може да посещава няколко различни класа и съответно много студенти могат да идват във всеки клас.
На ER диаграмата този тип връзка се показва, Howто следва:
За съжаление е невъзможно директно да се приложи такава връзка в базата данни. Следователно той ще трябва да бъде разделен на две релации "един към много".
За да направите това, ще трябва да създадете нов обект между двете таблици. Ако се установи връзка M:M между продажбите и продуктите, новият обект може да се нарече „продадени продукти“, тъй като ще представлява съдържанието на всяка продажба.
С "продадени стоки" и table "продажби" и table "стоки" ще бъдат свързани по тип 1:M. В различните модели такива междинни обекти се наричат по различен начин - "свързващи таблици", "асоциативни обекти" or "възлови таблици".
Всеки запис в table за връзки свързва два различни обекта от съседни таблици (и може също да съдържа допълнителна информация). Например table за връзки между ученици и класове може да изглежда така:
4.5 Задължителни or не?
Друг подход към анализа на връзките е да се определи кой от свързаните обекти е предпоставка за наличието на друг обект. Незадължителната страна на връзката е маркирана с кръг върху багажника.
Например, за да има една държава свой представител в ООН, тя трябва да съществува на картата на света, но твърдението за обратното ще бъде невярно:
Две единици могат да бъдат взаимозависими (т.е. едната не може да съществува без другата).
Рекурсивни връзки
Понякога една table може да се отнася до себе си. Например, table на служителите може да има атрибут "мениджър", който ще ни насочи към друг служител в същата table. Това е рекурсивната връзка.
Допълнителни връзки
Връзките се считат за излишни, ако са изразени повече от веднъж. По правило един от тях може да бъде изтрит, без да се загуби важна информация. Например, ако обектът „ученици“ е свързан с обекта „учители“ не само директно, но и косвено чрез „класове“, има смисъл да се премахне връзката между обектите „ученици“ и „учители“. Това решение се обосновава с факта, че е възможно да се разпределят ученици на учители само чрез часове.
4.6 Референтна цялост на данните
Когато променяте първичните и външните ключове, трябва да спазвате такъв аспект като референтната цялост на данните . Основната му идея е да поддържа две таблици в база данни, които съхраняват едни и същи данни, последователни.
Целостта на данните представлява правилно изградени връзки между таблици с правилно свързване между тях. В Howви случаи целостта на данните може да бъде нарушена:
- Аномалия при изтриване . Възниква при изтриване на ред от основната table. В този случай външният ключ от зависимата table продължава да препраща към изтрития ред от главната table.
- Аномалия на вмъкване . Възниква, когато ред е вмъкнат в зависима table. В този случай външният ключ от зависимата table не съвпада с първичния ключ на нито един от редовете от главната table.
- Актуализиране на аномалия. При такава аномалия няколко реда от една table могат да съдържат данни, които принадлежат на един и същ обект. Ако промените данните в един ред, те могат да влязат в конфликт с данните от друг ред.
Аномалия при изтриване
За да разрешите аномалията при изтриване, външният ключ трябва да бъде настроен на едно от двете ограничения:
Ако ред от зависима table задължително изисква ред от главната table, тогава външният ключ е настроен на каскадно изтриване. Тоест, когато ред се изтрие от главната table, свързаните редове се изтриват от зависимата table.
Ако ред от зависима table не позволява връзка с ред от основната table (т.е. такава връзка не е задължителна), тогава външният ключ е зададен на NULL, когато свързаният ред бъде изтрит от основната table. Колоната с външен ключ трябва да е nullable.
Аномалия на вмъкване
За да разрешите аномалията на вмъкване при добавяне към зависима table с данни, колоната, която представлява външния ключ, трябва да бъде nullable. И по този начин, ако добавеният обект няма връзка с основната table, тогава колоната с външен ключ ще има NULL стойност.
Актуализиране на аномалии
За да се реши проблемът с аномалията на актуализацията, се прилага нормализиране, което беше обсъдено по-рано.
GO TO FULL VERSION