§ Атрибутите, включени в UID, обозначени със символ "#"
Фигура 3 Същност с атрибути в ER-диаграма
Всяко предприятие трябва да има връзка, представляващи информационните нужди на организацията и правилата. Съобщение (Връзка) - Двупосочна връзка между две лица или юридическо лице, както и собствените си (рекурсивни отношения).
Всяка посока има връзка (Фигура 4):
§ име, като "участва в" или "назначен"
§ "трябва да бъде" - плътна линия на ER-диаграма
§ "може да бъде" - пунктираната линия в ER-диаграма
§ "един и само един" - един ред в ER-диаграма
§ "една или повече" - пилешки крака на ER-диаграма
Рекурсивно връзка с ER-диаграма е определен контур.
Синтаксисът на съобщението:
Всеки служител може да участва в един или повече проекти.
Всеки проект трябва да бъдат причислени към един или повече служители.
Всеки служител може да работи под ръководството на един и само един служител.
Всеки служител може да управлява един или повече служители.
Фигура 4 Представяне на връзки в ER-Диаграма
Уникалният идентификатор може да се състои не само от атрибутите. Техническа същност може да бъде еднозначно различими, също чрез комуникация. Например, под-проект се идентифицират еднозначно чрез своя номер, но ако броят на проектите, а няколко подпроекта може да се повтори. Че въпреки това, подпроекта може да бъде еднозначно идентифицирани, номера на проекта, съдържащ подпроекта, също трябва да бъде част от уникален идентификатор (UID). На входа на ER-диаграма връзка в UID определен напречна линия. Communications, част от уникалния идентификатор трябва да бъдат задължени да прокара "един и само един" в областите, свързани с UID.
видове облигации
Има три вида връзки:
§ Много към едно
§ Много към много
Едно към едно
Power "един и само един" и в двете посоки. Показва такива отношения между обектите, в които всеки отделен случай в едно предприятие, съответства само едно копие на друго предприятие и обратно. Това е рядък тип комуникация. Ако дизайнът на базата данни се появява този вид връзка, се препоръчва да се обмисли дали да слее двете дружества не могат. Например, ако в нашия пример, за да добавите друг субект "Паспорт на данни", връзката между това лице и "служителя" на лице, ще бъде "12:59". В този случай, би било по-добре да добавите атрибут "паспортни данни" до същността на "служител".
Мнозина към едно
Мощност, "една или повече" в една посока и "един и само един" в другата. Такава връзка към релационния модел е най-често. В нашия пример, тази връзка се осъществява между лица "Sub" и "проект".
Много към много
Мощност, "една или повече" и в двете посоки. В нашия пример, тази връзка се осъществява между лица "работник или служител" и "проект". Релационния модел не се отразява пряко прилагане на комуникация "много към много", тъй като в този случай, за да се избегне ситуация, в която множество стойности трябва да се съхраняват в една колона, а това противоречи неделима принцип, според който всяка клетка трябва да съдържа една част от данните. По този начин, свързване "много към много" се заменя с няколко ограничения "много към един" и е представен от пресечната единица (Фигура 5).
Фигура 5 Практическо прилагане на съобщението "много към много" в ER-диаграма
Не забравяйте, че по време на логическо проектиране на системата е необходимо за нормализиране на модела на данни, за да се премахне ненужната информация.
правила за почтеност и ключове
Условия целостта на базата данни - това е ограничено да се запази правилното базата данни и последователни. Спазването на тези ограничения трябва да се наблюдава от сървъра на базата данни или потребителското приложение.
Ограничения за да се гарантира изпълнението на бизнес правила (например, един служител на определен отдел не може да участва в работата на всеки един проект)
сървъра на базата данни контролира целостта на данните с помощта на бутоните:
Първичният ключ (ПК) се използва за уникален идентификационен низ. Първичният ключ трябва да бъде уникален и определено. Първичният ключ може да се състои от множество колони (композитен първичен ключ). Съставният първичен ключ трябва да е уникална комбинация от стойности в колони, които съставят първичния ключ. Никаква част от първичния ключ не може да съдържа нули.
Таблицата може да има няколко колони, като се прилагат към първичния ключ (уникални колони). Уникален ключ - колона или комбинация от колони, които могат да се използват като първичен ключ. В този случай, един от тези уникални ключове трябва да декларира първичния ключ, а останалите напусне уникален (заместник) ключ.
Външен ключ (FK) - колона или комбинация от колони в таблица, която съдържа линк към първичен или уникален ключ в същата или друга маса. Външен ключ е базиран на стойности на данни и е логично показалка. Външен ключ стойност трябва да съответства на съответните първични или уникални клавиши или да бъде нула. Ако външен ключ и е част от първичния ключ, той трябва да бъде определен.
физически дизайн
Веднъж построен ER-модел на база данни, тя трябва да се превърне в модел на маса и да осигури допълнителни съоръжения, предназначени за ускоряване на търсенето на информация (индекси) и удобството на изходните данни (ефективност). Можете също така трябва да се помисли как най-добре да се съхранява обекти на базата данни: по всички медии, колко памет да се разпределят. Тя предоставя на физически дизайн на системата.
Показва ER-модел в модел на маса
За да се покаже ER-модела в табличен вид по модела, използван от инстанция на таблицата с данни. Празен трябва да съдържа име на базата данни на маса, както и да предостави на маса, който колони са колоните на имена таблица на база данни, както и редовете съдържат информация за тези колони: видове ключове, обвързани и уникалност, външни ключове, типове данни и максималната дължина. Той също така препоръчва да се дава примери за данни, които ще се съхраняват в съответната таблица на база данни колони.
При пълнене във форма Таблица използва собствен нотация:
Свързани статии