Модел „Същност-Връзка“ (Entity-Relationship, E-R)

между същностите „Студент“ и „Дисциплина“ може да се изрази, както е показано на фигура 2.4.
Фигура 2.4. Модел същност-връзка.
Степента на връзките означава броя обекти, които свързва връзката. Повечето връзки са бинарни (binary) – свързват два обекта. Възможно е да има връзка между повече обекти, например: служител, клон, длъжност. Връзки между повече от три обекта не са типични.
Атрибутът е свойство, притежавано от всички обекти от набора. Възможни са няколко типове атрибути: прости и съставни; с една или много стойности; наследени – които могат да се изчислят от други атрибути.
Моделът се представя с E-R диаграми, при които набор обекти се представя с правоъгълник, връзката се представя с ромб, атрибутите се представят с елипса. Първичният ключ се подчертава, атрибутите с много стойности се ограждат с двойна елипса, а наследените атрибути се ограждат с пунктирана елипса.
Пример за релационната база данни от фигура 2.3, моделиран чрез E-R диаграма е показан на фигура 2.5.

Моделът позволява описание на специализация (наследяване) и генерализация (обединение) на същности, но те няма да бъдат разгледани в курса.
2.6.2 Унифициран език за моделиране (Unified Modeling
Language, UML)
Представлява език за графично моделиране на програмни системи, които се описват чрез класови диаграми (Class
Diagrams), подобни, но с различни символи от E-R модела.
Въпреки че с него може да се моделират целите
Фигура 2.5. E-R диаграма на база данни.

информационни системи, тук се разглежда само моделирането на базата данни. Моделът е официално приет за стандарт за описание на програмни системи в държавната администрация на Република България.
Релационната база данни от фигура 2.3 може да бъде представена чрез UML диаграма, както е показано на фигура
2.6.
Фигура 2.6. UML диаграма на база данни.
2.7 Полуструктуриран модел
Полуструктурираният модел използва за описание езика XML
(Extensible Markup Language), дефиниран от WWW Consortium
(W3C) и наследник на Standard Generalized Markup Language
(SGML). Нарича се полуструктуриран, защото документът има структура, въпреки че тя не е точно определена и може да бъде дефинирана от потребителя. Документите имат маркери
(tags), даващи допълнителна информация за съдържанието на отделните секции, например ако моделираме презентация по бази данни, бихме могли да използваме следната структура:

Introduction to XML

Разбира се няма стандарт, който да определя как да се наричат самите маркери, така че същата функционалност би могла да се постигне със следната структура:
1 2
3 4

XML
Introduction to XML

Видно е, че потребителят, който определя имената на отделните маркери трябва да познава структурата на файла и какво съдържание се крие зад тях, в противен случай няма да знае как да ги интерпретира.
Като предимства на модела могат да се посочат: той е разширяем, за разлика от HTML – потребителите могат да добавят собствени тагове и да определят как да се обработва и визуализира информацията в тях, което го прави универсален. Има възможност за вложени тагове, което позволява йерархия. Може да бъде добър начин за обмен на данни между приложенията, тъй като може да представи всякакви структури от данни. Таговете могат да документират данните (относително), ако се използват правилно.
Като недостатък може да се посочи необходимостта от повторение на информацията – ако един студент изучава няколко дисциплини, данните му трябва да присъстват във всеки XML файл.

Посочената на фигура 2.3 релационна база данни може да се моделира чрез XML например така:


Databases
CST
2
Genkov

?

Genkov
CST
Assistant Professor

?

123456
Ivanov
CST
2
1

?

Езикът XML е официално приет за стандарт за обмен на данни в държавната администрация на Република България.
3. Проектиране на бази от данни (1/10)
В тази глава ще се обсъждат само релационни бази данни.
Правилното проектиране е критично за работата на една база данни. От една страна неправилно проектираната база може да съдържа излишни данни, което да води до заемане на по- голям от необходимия обем или до понижено бързодействие.

От друга страна проектът на базата данни може да не позволи постигането на дадена функционалност или да предизвика аномалии при работата, примери за каквито са описани по- късно.
При проектирането на бази данни често се използва процес, наречен „нормализация“. Нормализацията представлява техника за проектиране на набор релации с желаните свойства, отговарящи на изискванията на моделираната организация (дефиниция на Edgar Codd, 1972). Често се прави като поредица от тестове върху релациите, за да определим дали удовлетворяват или нарушават изискванията към дадена нормална форма. Отделните нормални форми са описани по- късно в главата.
За да опишем нормалните форми, трябва да дефинираме понятието „Функционална зависимост“. Функционалната зависимост изисква стойността на даден набор атрибути еднозначно да определя останалите атрибути в таблицата (да има смисъл на ключово поле). Например в показаната на фигура 3.1 таблица със студенти съществува функционална зависимост на полето „Име“ от полето „Номер“, защото за всеки факултетен номер може еднозначно да се каже какво е името на студента.
Фигура 3.1. Таблица „Студенти"
В тази таблица обаче не съществува функционална зависимост на полето „Име“ от полето „Курс“, защото много студенти са във втори курс и не можем да определим еднозначно даден студент, само по факта, че той е във втори

курс.
При определянето на финкционалните зависимости и в последствие на първичните ключове трябва да внимаваме да не допуснем следната грешка. В горната таблица в момента няма повтарящи се имена на студентите. Гледайки това копие на таблицата ние можем грешно да предположим, че никога няма да има повтарящи се имена и да проектираме таблицата така, сякаш съществува функционална зависимост на останалите колони от името – т.е. да използваме името за първичен ключ. Тогава базата данни ще работи в текущото си състояние, но няма да ни позволи да вмъкнем нов студент с име, което вече съществува в базата, т.е. ще имаме загуба на функционалност.
Процесът на нормализация представлява формална техника за анализиране на релация, на базата на първичния ключ и функционалните зависимости между атрибутите на релацията.
При нормализацията релациите стават по-малко уязвими от аномалии.
Ненормализираната форма е таблица, която в някоя от клетките си съдържа повече от една стойност. Най-често тя се получава когато използваме външен източник (хартиено копие, Microsoft Excel таблица и др.) за въвеждане на информация в базата данни. Пример за таблица в ненормализирана форма е показан на фигура 3.2.

Фигура 3.2. Ненормализирана таблица
В този пример е моделирана таблица, представяща картотека на служителите ни, която съдържа изкуствено ключово поле идентификатор (ID) на служителя, имена, заплата, стая, телефон и информация за децата му. Това, което се забелязва е, че един служител може да няма деца – в този случай клетките за деца и възраст на децата нямат стойности (имат стойност Null), може да имат едно или повече деца. Когато служителят има повече от едно деца, данните за тях се въвеждат в съответните клетки една след друга, използвайки някакъв разделител, в примера запетая.
Тази структура е напълно възможна и използваема, ако имаме хартиена картотека – всеки служител си има картон и когато му се роди дете, просто го добавяме в съответното поле на картона. Структурата е донякъде приложима при електронните таблици (например Microsoft Excel), ако не използваме стредствата му за изчисления – например да искаме автоматично да се изчислят броя деца и средната им възраст. При базите данни обаче тази структура трябва да се избягва по две причини. Първо Null стойностите могат да доведат до грешки в информационните системи и трябва да се избягват. Второ обработката на информацията става по- сложна, например ако трябва да намерим името на второто дете на първия служител трябва да прочетем съдържанието на цялата клетка, след което да търсим разделителя и да интерпретираме текста след него. Ако децата са три или повече, то усложнението е още по-голямо.

За да дефинираме понятието „Първа нормална форма“, трябва да определим понятието „Атомарен атрибут“. Един атрибут е
„атомарен“ ако не може да се раздели на съставни части. В примера от предишната точка атрибутът “Деца“ не е атомарен, защото при първия служител той може да се раздели на две различни деца. Изискването една таблица да бъде в първа нормална форма е всички нейни атрибути са атомарни.
Алгоритъмът за преход от ненормализирана форма към първа нормална форма е:


Изтегляне 1.13 Mb.

Сподели с приятели: