Идентифициране на обекти и връзки между тях. Предметна област на базата данни и нейните модели Определяне дали даден атрибут е незадължителен

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

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

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

3.1 Субекти

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

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

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

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

Концепцията на ER модела. Концепцията за субект. Атрибути. Видове атрибути

1. Какви проблеми може да срещне разработчикът при проектирането на база данни?

При проектирането на база данни и разработването на софтуерен продукт най-важният проблем е проблемът за взаимодействието между разработчика и клиента. Задачата на разработчика е да пресъздаде най-точно желанията на клиента при разработването на софтуерен продукт за управление на бази данни. Основният проблем, който разработчикът трябва да реши, е правилното изграждане на базата данни или по-скоро схемата (структурата) на базата данни.

В допълнение, разработчикът допълнително среща други трудности, които включват:

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

На етап на развитие софтуер, който управлява базата данни, разработчикът трябва да научи в детайли изискванията на клиента. Базата данни трябва да бъде проектирана така, че да е разбираема, да отразява най-точно решавания проблем и да не съдържа излишни данни.

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

2. Какво представлява моделът ER (модел на същността и връзката)? Защо трябва да разработите спешен модел?

ER моделът (модел на връзката на обекта или диаграма на връзката на обекта) е семантичен модел на данни, който има за цел да опрости процеса на проектиране на базата данни. Всички видове бази данни могат да бъдат генерирани от ER модела: релационни, йерархични, мрежови, обектни. ER моделът се основава на понятията „субект“, „връзка“ и „атрибут“.

За големи бази данни изграждането на ER модел ви позволява да избегнете грешки в дизайна, които са изключително трудни за коригиране, особено ако базата данни вече работи или е на етап тестване. Грешките в разработването на структурата на базата данни могат да доведат до преработка на софтуерния код, който управлява тази база данни. В резултат на това времето, парите и човешките ресурси ще бъдат използвани неефективно.

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

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

3. Какво е обект в база данни? Примери

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

Пример 1.В базата данни на книжарницата могат да бъдат разграничени следните обекти:

  • Книга;
  • доставчик;
  • разположение в магазина.

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

  • студенти (студенти);
  • учители;
  • групи;
  • дисциплини, които се изучават.
4. Какви типове типове обекти има? Обозначаване на типове обекти в ER модела

В модела "субект"-"връзка" се разграничават два типа типове субекти:

  • слаб тип. Този тип образувание зависи от силно образувание;
  • силен тип. Това е независим тип образувание, което не зависи от никого.

Фигура 1 показва обозначенията на слаби и силни типове обекти в ER модела.

Ориз. 1. Обозначаване на силни и слаби видове субекти

5. За какво са атрибутите? Видове атрибути. Обозначаване на атрибути на модела ER

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

Разграничават се следните видове атрибути:

  • простоатрибути. Това са атрибути, които могат да бъдат част от съставни атрибути. Тези атрибути се състоят от един компонент. Например прости атрибути включват: код на книга в библиотека или курс на обучение на студент в образователна институция;
  • композитенатрибути. Това са атрибути, които се състоят от няколко прости атрибута. Например адресът по местоживеене може да съдържа името на страната, населеното място, улицата, номера на къщата;
  • недвусмисленатрибути. Това са атрибути, които съдържат само една единствена стойност за даден обект. Например, атрибутът „Номер на книжката за оценки“ за тип обект „Студент“ е недвусмислен, тъй като студентът може да има само един номер на книжката (една стойност);
  • полисемантиченатрибути. Това са атрибути, които могат да съдържат множество стойности. Например, многозначният атрибут „Телефонен номер“ за обекта „Студент“, тъй като един студент може да има няколко телефонни номера (домашен, мобилен и т.н.);
  • произволенатрибути. Това са атрибути, чиято стойност се формира въз основа на стойностите на други атрибути. Например, текущият курс на обучение на студент може да бъде изчислен въз основа на разликата между текущата година на обучение и годината, в която студентът е влязъл в образователна институция(ако студентът не е имал проблеми с обучението и е изучавал дисциплината „Организация на бази данни и знания“) добре.

В ER диаграма атрибутите се обозначават, както е показано на фигура 2. Както може да се види от фигурата, всеки атрибут се обозначава като елипса с име вътре в елипсата. Ако атрибутът е първичен ключ, името му е подчертано.

Фигура 2. Представяне на атрибути в диаграми на ER модел

6. Как се внедряват типове обекти и атрибути на ER модела в реални бази данни и управляваните от тях програми?

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

  • изберете добре позната технология като източник на данни (например Microsoft SQL Server, Oracle Database, Microsoft Access, Microsoft ODBC Data Source и т.н.), която вече е проучена, тествана, стандартизирана и има огромен набор от управление на бази данни инструменти;
  • разработете свой собствен формат на база данни и приложете методи за обработката му и приложете взаимодействие с известни източници на данни под формата на специални команди като импортиране/експортиране. В този случай ще трябва лично да програмирате цялата рутинна работа по поддържане и осигуряване на надеждна работа на базата данни;
  • прилагане на комбинация от двата по-горе подхода. Съвременните инструменти за разработка на софтуер разполагат с мощен набор от библиотеки за обработка на сложни набори и визуализиране на данни в тях (колекции, масиви, компоненти за визуализация и др.).

Ако базата данни е внедрена в добре познати релационни СУБД (например Microsoft Access, Microsoft SQL Server и т.н.), тогава типовете обекти се представят от таблици. Атрибутите от модела ER съответстват на полетата на таблицата. Един запис в таблица на база данни представлява едно копие на обект.

Всеки тип атрибут се изпълнява, както следва:

  • прост атрибутили атрибут с една стойност може да бъде представен чрез достъпен набор от основни типове, които се намират във всеки език за програмиране. Например целочислените атрибути са представени от тип int, integer, uint и т.н.; атрибутите, съдържащи дробна част, могат да бъдат представени като float, double; низови атрибути от тип низ и др.;
  • съставен атрибуте обект, който включва няколко вложени прости атрибута. Например в СУБД на Microsoft Access може да се формира съставен атрибут на таблица въз основа на набор от прости типове (полета). В езиците за програмиране обединението на полета се реализира от структури или класове;
  • многозначен атрибутможе да се реализира чрез масив или колекция от прости или съставни атрибути;
  • произволен атрибутизпълнява се от допълнително поле, което се изчислява при достъп до таблицата. Такова поле се нарича изчисляемо поле и се формира на базата на други полета на таблицата;
  • атрибут, който е първичен ключможе да бъде цяло число, низ или друг реден тип. В този случай стойността на всяка клетка от таблицата, която съответства на първичния ключ, е уникална. Най-често първичният ключ е целочислен тип (int, integer).

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

7. Пример за фрагмент от ER модел за тип обект „Студент“.

Горният пример демонстрира фрагмент от ER модела за тип обект „Студент“.

Фигура 3. Фрагмент от ER модела за тип обект „Студент“.

Горната фигура декларира следните атрибути, които в СУБД (програма) могат да имат следните типове:

  • Атрибутът на първичен ключ е уникална целочислена стойност, която се генерира автоматично. В СУБД това е поле за брояч;
  • Атрибутът за година на въвеждане е прост атрибут, който може да бъде имплементиран като цяло число (int, integer);
  • атрибутът Телефонен номер е атрибут с множество стойности, който може да бъде имплементиран като масив или колекция и т.н.;
  • атрибут Номер на книгата– прост атрибут, който може да се реализира като низ от знаци, тъй като номерът на книгата може да съдържа букви в допълнение към числата;
  • атрибут Държава, Град, Улица, Номер на къща са атрибути, които образуват съставния атрибут Адрес. Всички тези атрибути могат да бъдат от тип низ (текст) (низ, Текст);
  • атрибут Фамилия, Собствено име, Бащино име – това са прости атрибути, които са част от съставния атрибут Име на ученика. Всички тези атрибути могат да бъдат от тип низ (текст) (низ, Текст);
  • атрибутът Birthday е прост атрибут от типа Date (DateTime);
  • атрибут Студентска възраст– изчисляемо поле, което се определя като разлика между текущата (системна) дата и стойността на атрибута Рожден ден.

Основни понятия на модела на базата данни “entity-relationship” (ER-model): обекти, връзки между тях и техните атрибути (свойства).

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

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

Връзка– връзката между субектите в предметната област. Връзките са връзки между части от база данни (в релационна база данни те са връзки между записи в таблици).

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

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

Основните предимства на моделите ER: * яснота; * моделите ви позволяват да проектирате бази данни с голям брой обекти и атрибути;

Основните елементи на ER моделите: * обекти (entities); * атрибути на обекти; * връзки между обекти.

Връзката между обектите се характеризира с: * тип връзка (1:1, 1:N, N:M); * клас на принадлежност. Класът може да бъде задължителен или незадължителен. Ако всеки екземпляр на обект е включен във връзка, тогава класът на членство е задължителен, в противен случай е незадължителен.


Концепцията за нормализиране на данните. Функционална зависимост.

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

Функционална зависимост. Нека X и Y са два атрибута на някакво отношение. Казва се, че Y е функционално зависим от X, ако във всеки даден момент всяка стойност на X съответства на не повече от една стойност на атрибута Y.

Функционалната зависимост се обозначава като X -> Y.

Отношение ученик S (Ns, Fio, Ngr, Addr, Tel). Всеки от атрибутите Fio, Ngr, Addr, Tel функционално зависи от атрибута Ns.

Така че в нормализирана релация всички неключови атрибути са функционално зависими от ключа на релацията. Ключът на релацията S е атрибутът Ns.

Основно правилокогато създавате таблици на обекти, това е „отделна таблица за всеки обект“.

Полетата на таблицата с обекти могат да бъдат от два типа: ключИ неключови.Въвеждането на ключове в таблица в почти всички релационни СУБД ви позволява да осигурите уникалността на стойностите в записите на таблицата по ключ, да ускорите обработката на записите на таблицата и също така автоматично да сортирате записите по стойности в ключовите полета.

Определението обикновено е достатъчно простоключ, по-рядко - въведете композитенключ. Таблица със съставен ключ може да бъде например таблица, съхраняваща списък на служители (фамилия, собствено име и отчество), в които се намират съименници. Някои СУБД предлагат на потребителите опцията да дефинират автоматично генерирано поле за номериране на ключ (в Access това е поле от тип „брояч“), което опростява решението на проблема с уникалността на записите в таблицата.

Понякога таблиците с обекти имат полета, описващи свойствата или характеристиките на обектите. Ако таблицата има значителен брой повторения в тези полета и тази информация има значителен обем, тогава е по-добре да ги отделите в отделна таблица (придържайки се към правилото: „всеки обект има отделна таблица“). Освен това трябва да се създаде допълнителна таблица, ако свойствата са взаимосвързани.

Когато обработвате таблици с обекти, имайте предвид следното. Лесно е да добавите и промените нов обект, но когато изтривате, трябва да унищожите всички препратки към него от таблиците за връзки, в противен случай таблиците за връзки ще бъдат неправилни. Много съвременни СУБД блокират неправилни действия при такива операции.

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

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

По-сложните връзки (небинарни) трябва да бъдат сведени до бинарни. За да се опишат връзките на N обекта, са необходими N-1 таблици за отношения. Не трябва да има преходни връзки. Излишъкът от връзки води до противоречия (вижте примера за връзките СЛУЖИТЕЛ-ОТДЕЛ, СЛУЖИТЕЛ-ПРОЕКТ и ОТДЕЛ-ПРОЕКТ в предишния подраздел).

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


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

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

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

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

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

Сред ограниченията за интегритет могат да се разграничат два основни вида ограничения: ценностни ограниченияатрибути на връзката и структурни ограничениякъм кортежи от отношения.

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

Най-гъвкавите средства за осъществяване на контрол върху стойностите на атрибутите са съхранени процедуриИ задейства,налични в някои СУБД.

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

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

Референтната цялост изисква за всяка стойност на външен ключ в родителската таблица да има ред в дъщерната таблица със същата стойност на първичен ключ. Например, ако релация R1 съдържа информация за служителите на отдела и атрибутът на тази релация Must е първичен ключ на релация R2, ​​то в тази релация за всяка позиция от R1 трябва да има ред със съответната заплата.

Много съвременни СУБД имат инструменти за наблюдение на целостта на базата данни.

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

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

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

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

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

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

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

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

Съществуват следните видове атрибути:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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