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

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

Екземпляр на обект е конкретен екземпляр на този обект. Например служителят Иванов може да бъде екземпляр на обекта Служител.

Всеки обект трябва да има следните свойства:

имат уникално име;

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

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

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

Има следните видове атрибути:

прост - състои се от един елемент от данни;

съставен - състои се от няколко елемента от данни;

недвусмислен - съдържа една стойност за един обект;

многоценен - ​​съдържа няколко стойности за един обект;

по избор - може да има празна (недефинирана) стойност;

извлечено - стойност, получена от стойността на друг атрибут.

Уникалният идентификатор е набор от атрибути, чиито стойности заедно са уникални за всеки екземпляр на обект. Премахването на който и да е атрибут от идентификатор нарушава неговата уникалност. Уникалните идентификатори са подчертани в диаграмата.

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

Връзки между субекти

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

Степента на връзка е броят на субектите, участващи във връзката.

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

В зависимост от стойността на мощността връзката може да има един от трите вида:

едно към едно (означено 1:1).

едно към много (означено като 1:N).

много към много (означени с M:N).

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

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

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

3 . Компоненти на модела на данни

Обект, определение на обект, източници на информация за обекти

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

3.1 Субекти

Субектът е нещо, за което информацията трябва да се съхранява в база данни.

При проектирането на бази данни е достатъчно да се опише текущата ситуация - и повечето съществителни и някои глаголи ще бъдат кандидати за обекти. Например: "Клиентите купуват стоки. Служителите продават стоки на клиентите. Доставчиците доставят стоки" - клиентите, стоките, служителите и доставчиците са субекти. Глаголите "купувам" и "продавам" също са същности (въпреки че могат да бъдат една и съща същност, различна от гледна точка на купувача и продавача).

При проектирането на база данни основният източник на информация за обектите е разговор с клиента, за да се разберат неговите бизнес процеси. Освен това се анализират стандартни документи, използвани в бизнес процесите: формуляри, отчети, инструкции и др. След получаване на такъв списък е необходимо да се провери за пълнота и съгласуваност, както и да се идентифицират дубликати - идентични обекти, които се наричат ​​с различни думи, и обекти, които всъщност са различни, но са описани с един и същ термин.

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

Атрибут.

Предметна област.

База данни. Определение.

СУБД. Определение.

База данни. Определение.

Трета нормална форма. Определение. Пример.

Релационна променлива R е в трета нормална форма тогава и само ако са верни следните условия:

R е във втора нормална форма.

· нито един неключов атрибут R не е в транзитивна функционална зависимост (т.е. зависимостта не се изразява чрез друг атрибут) от потенциалния ключ R.

Неключов атрибут на релация R е атрибут, който не принадлежи към нито един от кандидат ключовете на R.

База данни- това е един или повече файлове с данни, предназначени да съхраняват, променят и обработват големи количества взаимосвързана информация, систематизирани по такъв начин, че тези материали да могат да бъдат намерени и обработени с помощта на електронен компютър (компютър)

Система за управление на бази данни (СУБД)е софтуер, който позволява на потребителите да дефинират, създават и поддържат база данни и който обработва извиквания на база данни от приложения за крайни потребители.

База данни- автоматизирана информационна система за централизирано съхранение и колективно използване на данни. Банката от данни включва една или повече бази данни, директория на база данни, СУБД, както и библиотеки от заявки и приложни програми.

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

Атрибуте най-малката единица от структурата на данните. На всеки елемент се присвоява уникално име при създаването на базата данни. По време на обработката се споменава с това име.

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

Избройте функциите на СУБД

Основните функции на СУБД:

1) Определяне на структурата на създадената база данни, нейната инициализация и първоначално зареждане.

2) Предоставяне на възможност на потребителите да манипулират данни (избиране на необходимите данни, извършване на изчисления, разработване на интерфейс за вход / изход, визуализация).

3) Осигуряване на логическа и физическа независимост на данните.

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

5) Защита на физическата цялост – инструменти за възстановяване на бази данни (транзакции).

6) Управление на потребителските права за достъп до базата данни.

7) Синхронизиране на работата на няколко потребителя.

8) Управление на ресурсите на средата за съхранение - СУБД разпределя ресурси на паметта за нови данни, преразпределя освободената памет, организира опашка от заявки към външна памет и т.н.

9) Подкрепа за дейността на персонала на системата

Терминът "релационен" означава "базиран на връзка". Релационната база данни се състои от обекти (таблици), които имат някаква връзка помежду си. Името идва от английската дума отношение.
Дизайнът на базата данни се състои от две основни фази: логическо и физическо моделиране.
По време на логическото моделиране вие ​​събирате изисквания и разработвате модел на база данни, който е независим от конкретна СУБД (система за управление на релационни бази данни). Това е като да създавате чертежи за вашата къща. Можете да обмислите и нарисувате всичко: къде ще бъде кухнята, спалните, хола. Но всичко това е на хартия и в оформления.
По време на физическото моделиране вие ​​създавате модел, който е оптимизиран за конкретно приложение и СУБД. Именно този модел се прилага на практика. Ако се върнем към къщата от предишния параграф, на този етап ще трябва да построите къща някъде - да носите трупи, тухли ...

Процесът на проектиране на база данни се състои от следните стъпки:

• събиране на информация;
• дефиниране на субекти;
• дефиниране на атрибути за всеки обект;
• определяне на връзки между субекти;
• нормализиране;
• трансформация към физически модел;
• създаване на база данни.

Първите 5 етапа формират фазата на логически дизайн, а останалите два формират фазата на физическо моделиране.

Логическа фаза

Логическата фаза се състои от няколко етапа. Всички те са обсъдени по-долу.

Изисквания за събиране

На този етап трябва да определите как точно ще се използва базата данни и каква информация ще се съхранява в нея. Съберете възможно най-много информация за това какво трябва и какво не трябва да прави системата.

Дефиниция на обект

На този етап трябва да дефинирате обектите, от които ще се състои базата данни.

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

Обектите се състоят от атрибути (колони в таблица) и записи (редове в таблица).

Обикновено базите данни са съставени от няколко основни обекта, свързани с голям брой подчинени обекти. Основните субекти се наричат ​​независими: те не зависят от никой друг субект. Подчинените обекти се наричат ​​зависими: за да съществува един от тях, основната таблица, свързана с него, трябва да съществува.
В диаграмите обектите обикновено се представят като правоъгълници. Името на обекта е посочено вътре в правоъгълника:

Всяка маса има следните характеристики:

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

На този етап трябва да идентифицирате всички категории информация (обекти), които ще се съхраняват в базата данни.

Определение на атрибут

Атрибутът представлява свойство, което описва обект. Атрибутите често са число, дата или текст. Всички данни, съхранявани в даден атрибут, трябва да бъдат от един и същи тип и да имат едни и същи свойства.
Във физическия модел атрибутите се наричат ​​колони.
След дефинирането на обектите е необходимо да се дефинират всички атрибути на тези обекти.
В диаграмите атрибутите обикновено са изброени в рамките на правоъгълника на обекта. На фигурата ще намерите пример за база данни "Къщи", само че сега някои атрибути са дефинирани за обектите от тази база данни.


Всеки атрибут определя типа на данните, размера, разрешените стойности и всякакви други правила. Те включват задължителни, променливи и правила за уникалност.
Задължителното правило определя дали даден атрибут е задължителна част от обект. Ако атрибутът е незадължителна част от обекта, тогава той може да бъде NULL, в противен случай не.
Трябва също да определите дали атрибутът е променлив. Някои стойности на атрибути не могат да се променят след създаването на записа.
И накрая, трябва да определите дали атрибутът е уникален. Ако е така, тогава стойностите на атрибута не могат да се повтарят.

Ключове

Ключът е набор от атрибути, които уникално идентифицират запис. Ключовете са разделени на два класа: прости и сложни.
Простият ключ се състои само от един атрибут. Например в базата данни "Паспорти на гражданите на страната" номерът на паспорта ще бъде прост ключ: все пак няма два паспорта с еднакъв номер.
Композитният ключ се състои от няколко атрибута. В същата база данни "Паспорти на гражданите на страната" може да има съставен ключ със следните атрибути:
фамилия, име, бащино име, дата на раждане. Това е само пример, тъй като този съставен ключ на теория не осигурява гарантирана уникалност на записа.
Има и няколко вида ключове, които са описани по-долу.

Възможен ключ

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

Първични ключове

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

Алтернативни ключове

Всеки възможен ключ, който не е първичен ключ, се нарича алтернативен ключ. Един обект може да има множество алтернативни ключове.

Външни ключове

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

Ключовете са логически конструкции, а не физически обекти. Релационните бази данни имат механизми за съхраняване на ключове.

Определяне на връзки между обекти

Релационните бази данни ви позволяват да комбинирате информация, принадлежаща на различни обекти.
Връзката е ситуация, в която един обект препраща към първичния ключ на втори обект. Като, например, обектите House и Master в предишната фигура.
Връзките се дефинират по време на процеса на базов дизайн. За да направите това, трябва да анализирате обектите и да идентифицирате логическите връзки, които съществуват между тях.
Типът връзка определя броя на записите на обект, свързани с друг запис на обект. Връзките са разделени на три основни типа, които са описани по-долу.

Едно към едно

Всеки запис от първия обект съответства само на един запис от втория обект. И всеки запис на втория обект съответства само на един запис от първия обект. Например, има две единици: хора и удостоверения за раждане. А един човек може да има само един акт за раждане.

Едно към много

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

много към много

Всеки запис на първия обект може да съответства на няколко записа от втория обект. Всеки запис на втория обект обаче може да съответства на няколко записа от първия обект. Например, има две единици: Автор и Книга. Един автор може да напише много книги. Но една книга може да има няколко автора.
Според критерия на облигационните правоотношения се делят на задължителни и факултативни.

• Задължителна връзка означава, че за всеки запис от първия обект трябва да има свързани записи във втория обект.
• Незадължителна връзка означава, че запис от първия обект може да няма запис във втория обект.

Нормализация

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

Първа нормална форма

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

За да приведете обекта Къща в първата нормална форма, е необходимо да премахнете повтарящите се групи от стойности, тоест да премахнете атрибутите Собственик 1-3, като ги поставите в отделен обект. Резултат (Entity House намалена до първата нормална форма):

Втора нормална форма

Таблица във втора нормална форма съдържа само данните, които се отнасят за нея. Стойностите на неключовите атрибути на обекта зависят от първичния ключ. По-точно, атрибутите зависят от първичния ключ, от целия първичен ключ и само от първичния ключ.
Обектите трябва да са в първата нормална форма, за да съответстват на втората нормална форма.
Например, обектът Къща на фигурата има атрибут Цена на литър бензин, който няма нищо общо с къщите. Този атрибут се премахва (или можете да го преместите в друг обект). И също така преместваме атрибута Mayor в отделен обект - този атрибут зависи от града, в който се намира къщата, а не от къщата.
Фигурата показва Къщата на същността във втората нормална форма (Къщата на същността, намалена до втората нормална форма).

трета нормална форма

Третата нормална форма изключва атрибути, които не зависят от целия ключ. Всяко образувание, което е в трета нормална форма, също е във втора нормална форма. Това е най-често срещаната форма на база данни.
В третата нормална форма всеки атрибут зависи от ключа, от целия ключ и от нищо друго освен от ключа.
Например, обектът House Owner на фигурата има атрибут на зодиакален знак, който зависи от датата на раждане на собственика на къщата, а не от неговото име (което е ключът).
За да прехвърлите обекта Собственик на къщата, трябва да създадете обекта Знаци на зодиака и да прехвърлите атрибута Знак на зодиака там (Собственик на обекта, намален до третата нормална форма):

Ограничения

Ограниченияса правилата, наложени от системата за управление на базата данни. Ограниченията определят набора от стойности, които могат да бъдат въведени в колона или колони.
Например, не искате сумата на поръчката във вашия много готин магазин да бъде по-малка от 500 рубли. Просто задавате лимит в колоната Сума на поръчката.

Съхранени процедури

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

ЗАБЕЛЕЖКА
Съхранените процедури се намират в базата данни и се изпълняват на сървъра на базата данни. Те обикновено са по-бързи от SQL изразите, защото се съхраняват в компилиран вид.

Целостта на данните

Като организираме данните в таблици и дефинираме връзките между тях, можем да приемем, че е създаден модел, който правилно отразява бизнес средата. Сега трябва да се уверим, че данните, въведени в базата данни, дават правилна представа за състоянието на въпроса. С други думи, трябва да наложите бизнес правила и да поддържате целостта на базата данни.
Например, вашата компания се занимава с доставка на книги. Едва ли ще приемете поръчка от непознат клиент, защото тогава дори няма да можете да доставите поръчката. Оттук и бизнес правилото: поръчки се приемат само от клиенти, чиято информация е в базата данни.
Коректността на данните в релационните бази данни се осигурява от набор от правила. Правилата за цялост на данните попадат в четири категории.

• Цялост на обекта- всеки запис на обект трябва да има уникален идентификатор и да съдържа данни. В крайна сметка трябва по някакъв начин да разграничите всички тези записи в базата данни.
• Цялост на атрибута- всеки атрибут приема само разрешени стойности. Например сумата на покупката определено не може да бъде по-малка от нула.
• Референтна цялост- набор от правила, които осигуряват логическата последователност на първичните и външните ключове при вмъкване, актуализиране и изтриване на записи. Референтната цялост гарантира, че за всеки външен ключ има съответен първичен ключ. Нека вземем предишния пример с обектите Home Owner и Home. Да кажем, че сте Вася Иванов и притежавате къща. Променихте фамилното си име на Сидоров и направихте съответните промени в обекта собственик на къщата. Определено бихте искали къщата ви да продължи да бъде ваша под новото ви име, а не на някой си Вася Иванов, който вече не съществува.
• Персонализирани правила за цялост- всякакви правила за интегритет, които не принадлежат към нито една от изброените категории.

задейства

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

Бизнес правила

Бизнес правилата определят ограниченията, поставени върху данните според изискванията на бизнеса (тези, за които създавате базата). Бизнес правилата могат да се състоят от набор от стъпки, необходими за изпълнение на конкретна задача, или могат просто да бъдат проверки, които потвърждават, че въведените данни са правилни. Бизнес правилата могат да включват правила за цялост на данните. За разлика от други правила, тяхната основна цел е да гарантират, че бизнес транзакциите се извършват правилно.
Например, в компания на Very Tough Guys може да е обичайно да се купуват само бели, сини и черни коли за служебна употреба.
Тогава бизнес правилото за атрибута Цвят на превозното средство на обекта Дружествени превозни средства ще бъде, че превозното средство може да бъде само бяло, синьо или черно.
Повечето СУБД предоставят средства за:

• за определяне на стойности по подразбиране;
• да проверява данните преди въвеждането им в базата данни;
• поддържане на връзки между таблици;
• да гарантира уникалността на ценностите;
• за съхраняване на съхранени процедури директно в базата данни.

Всички тези функции могат да се използват за прилагане на бизнес правила в база данни.

Физически модел

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

Денормализация

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

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

Днес ще говорим за модела същност-връзка или модел на същност-връзка.

Теория

Моделът Entity-Relationship или ER модел е концептуален модел на данни на високо ниво, който е разработен, за да опрости задачата за проектиране на структури на бази данни.

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

Целта на диаграмите "entity-relationship" е да се създаде точно и пълно представяне на реалната предметна област (SbD), която се използва по-късно като източник на информация за изграждане на база данни на автоматизирани системи за обработка на информация (DB ASOI).

Тази диаграма или концептуален модел на ObD трябва да отговаря на следните изисквания:

• Осигурете адекватно показване на SbA;
• Представяне на език, който е разбираем както за бъдещите потребители на ASOI, така и за разработчиците на бази данни;
• Съдържа информация за ObD, достатъчна за по-нататъшно проектиране на база данни (разработване на логически и физически модели);
• Гарантиране на недвусмислена интерпретация или интерпретация на модела ObA.

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

СЪЩНОСТе набор от обекти от реалния свят с еднакви свойства. Субектът се характеризира с независимо съществуване и може да бъде обект с физическо (или реално) съществуване или обект с концептуално (или абстрактно) съществуване.

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

Практикувайте

ПРИМЕР. Предметна област " Резервация на билети в киното". В киното се прожектират филми, билети за които могат да бъдат закупени в деня на представлението или предварително резервирани. Базата данни съдържа информация за всички филмови прожекции в дадено кино, включително стари. Всяка филмова прожекция има своя цена, т.е. билетите за един и същи филм, но в различни часове, могат да се различават по цена. Филмова прожекция се състои от филм, информацията за който също се съхранява в базата данни.

За Pro " Резервация на билети в киното” обекти ще бъдат следните понятия:

Прожекция на филм

Филми

зрител

Билет

Резервация

Цена

Графично, обектите в диаграмите обект-връзка са представени като правоъгълници:

АТРИБУТ— това е средството, чрез което се дефинират свойствата на даден обект или връзка. Атрибутът е наименована характеристика на обект. Името на атрибута трябва да е уникално за конкретен обект, но може да бъде еднакво за различни обекти.

Конкретният набор от атрибути за даден обект се определя от задачите, в които се използват. Например обектите на ObA „Поръчване на билети в киното“ могат да бъдат описани с помощта на следния набор от атрибути:

Прожекция на филм(Номер на прожекцията на филма, Номер на филма, Дата на прожекцията, Номер на разходите);

Филм(Номер на филма, Заглавие, Продължителност, Кратко описание);

зрител(Номер на зрителя, трите имена, дата на раждане);

Билет(Брой зрители, Брой прожекции на филми, Цена на билета);

Резервация(номер на одитор, номер на скрининг, дата на резервация);

Цена(номер на разходите, номер на скрининга, цена).

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

Удебелен курсив и подчертаване обозначават първични ключове, атрибут на обект, който го характеризира уникално. Подчертаването означава външни ключове - атрибути, които уникално характеризират обектите, към които се отнасят.

ВРЪЗКАе връзка между екземпляри на два (или повече) различни обекта. Механизмът на връзката се използва за дефиниране на връзки между обекти в ObA. Освен това има връзки между атрибутите на отделен обект (трябва да се вземат предвид при изграждането на логически модели).

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

Името на връзката трябва да носи определено значение, за да бъде по-лесно да се разбере как са свързани обектите. Например връзката между обектите Зрител и Билет може да се дефинира като „Купете“.

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

Индикаторът за кардиналност на връзката (характеристика на недвусмислеността) показва степента на връзка между обектите и описва броя на възможните взаимоотношения за всеки от участващите обекти:

• едно към едно (1:1);
• един към много (1:N);
• много към много (N:M).