Основи на съвременните бази данни Предговор
Лекция 6. Проектиране на релационни БД
Изтегляне 1.71 Mb.
|
- Навигация на страницата:
- 6.1. Проектиране на релационни бази от данни чрез използване на нормализация
- 6.1.1. Втора нормална форма
- 6.1.2. Трета нормална форма
- 6.1.3. Нормална форма на Бойс-Код
- 6.1.4. Четвърта нормална форма
- 6.1.5. Пета нормална форма
- 6.2. Семантично моделиране на данни, ER-диаграми
- 6.2.1. Семантични модели данни
- 6.2.2. Основни понятия на модела Entity - Relationship (Същност - Връзки)
- 6.2.3. Нормални форми на ER-схеми
- 6.2.4. По- сложни елементи на ER-модела
- 6.2.5. Получаване на релационна схема от ER-схема
- 10.1. Транзакции и цялостност на бази от данни
- 10.2. Изолираност на потребителите
- 10.3. Сериализация на транзакциите
Лекция 6. Проектиране на релационни БДПри проектирането на база от данни се решават два основни проблема:
В случая на релационните бази от данни трудно се представят общи рецепти в частта на физическото проектиране. Твърде много зависи от използваната СУБД. Например, при работа със СУБД Ingres може да се избира един от предлаганите способи за физическа организация на отношенията, при работа със System R следва преди всичко да се помисли за клъстеризацията на отношенията и необходимия набор индекси и т.н. Затова ще се ограничим с въпросите за логическото проектиране на релационни бази от данни, които са съществени при използването на всяка релационна СУБД. Освен това, няма да засягаме много важния аспект на проектирането – определянето на ограниченията за цялостност (с изключение на ограниченията за първичния ключ). Работата е там, че при използването на СУБД с развити механизми на ограниченията за цялостност (например, SQL-ориентираните системи) е трудно да се предложи някакъв общи подход към определението на ограниченията за цялостност. Тези ограничения могат да имат много общ вид, и тяхната формулировка засега се отнася по-скоро към областта на изкуството, отколкото на инженерното майсторство. Най-много, което се предлага по този повод в литературата, това е автоматическа проверка за непротиворечивост на набора ограничения за цялостност. Така че ще смятаме, че проблемът за проектирането на релационна база от данни се състои в обоснованото вземане на решения за това,
6.1. Проектиране на релационни бази от данни чрез използване на нормализацияОтначало ще бъде разгледан класическия подход, при който целият процес на проектиране се извършва в термините на релационния модел на данни по метода на последователните приближения към удовлетворителен набор от схеми на отношения. Изходната точка е представянето на предметната област във вид на едно или няколко отношения, и на всяка стъпка от проектирането се произвежда някакъв набор от схеми на отношения, притежаващи най-добри свойства. Процесът на проектирането представлява процес на нормализация на схемите на отношенията, при това всяка следваща нормална форма притежава свойства по-добри, отколкото предишната. На всяка нормална форма съответствува някакъв определен набор от ограничения, и отношението е в някаква нормална форма, ако удовлетворява свойствения на нея набор от ограничения. Пример за набор от ограничения е ограничението на първа нормална форма - значенията на всички атрибути на отношение да са атомарни. Тъй като изискването на първа нормална форма е базово изискване за класическия релационен модел данни, то ще считаме, че изходният набор от отношения вече съответствува на това изискване. В теорията на релационните бази от данни обикновено изпъква следната последователност от нормални форми:
Основни свойства на нормалните форми:
В основата на процеса на проектирането лежи методът на нормализация, декомпозиция на отношението, намиращо се в предишната нормална форма, в две или повече отношения, удовлетворяващи изискванията на следващата нормална форма. Най-важните на практика нормални форми на отношения се основават на фундаменталното в теорията на релационните бази от данни понятие функционална зависимост. Определение 1. Функционална зависимост В отношение R атрибутът Y функционално зависи от атрибута X (X и Y могат да бъдат съставни) тогава и само тогава, когато на всяка стойност на X съответствува точно една стойност на Y: R.X (r) R.Y. Определение 2. Пълна функционална зависимост Функционалната зависимост R.X (r) R.Y се нарича пълна, ако атрибутът Y не зависи функционално от кое да е точно подмножество на X. Определение 3. Транзитивна функционална зависимост Функционалната зависимост R.X -> R.Y се нарича транзитивна, ако съществува такъв атрибут Z, че съществуват функционалните зависимости R.X -> R.Z и R.Z -> R.Y и отсъства функционалната зависимост R.Z --> R.X. (Ако го нямаше последното изискване щяхме да имаме "неинтересни" транзитивни зависимости във всяко отношение, притежаващо няколко ключа.) Определение 4. Неключов атрибут Неключов атрибут се нарича всеки атрибут на отношение, невлизащ в състава на първичния ключ (в частност, първичния). Определение 5. Взаимно независими атрибути Два или повече атрибута са взаимно независими, ако нито един от тях не е функционално зависим от другите. 6.1.1. Втора нормална формаДа разгледаме следния пример на схема на отношение: СЪТРУДНИЦИ-ОТДЕЛИ-ПРОЕКТИ (СЪТР_НОМЕР, СЪТР_ЗАПЛ, ОТД_НОМЕР, ПРО_НОМЕР, СЪТР_ЗАДАН) Първичен ключ: СЪТР_НОМЕР, ПРО_НОМЕР Функционални зависимости: СЪТР_НОМЕР -> СЪТР_ЗАПЛ СЪТР_НОМЕР -> ОТД_НОМЕР ОТД_НОМЕР -> СЪТР_ЗАПЛ СЪТР_НОМЕР, ПРО_НОМЕР -> СЪТР_ЗАДАН Както се вижда, макар че първичен ключ е съставният атрибут СЪТР_НОМЕР, ПРО_НОМЕР, атрибутите СЪТР_ЗАПЛ и ОТД_НОМЕР функционално зависят от част от първичния ключ, атрибута СЪТР_НОМЕР. В резултат не можем да вмъкнем в отношението СЪТРУДНИЦИ-ОТДЕЛИ-ПРОЕКТИ кортеж, описващ сътрудник, който още не изпълнява никакъв проект (първичният ключ не може да съдържа неопределена стойност). При премахване на кортежа ние не само разрушаваме връзката на дадения сътрудник с дадения проект, но загубваме информацията за това, че той работи в някакъв отдел. При превода на сътрудника в друг отдел ще бъдем принудени да модифицираме всички кортежи, описващи този сътрудник, или ще получим несъгласуван резултат. Такива неприятни явления се наричат аномалии на схемата на отношение. Те се отстраняват чрез нормализация.
Отношение R е във втора нормална форма (2NF) тогава и само тогава, когато е в 1NF, и всеки неключов атрибут напълно зависи от първичния ключ. Може да се извърши следната декомпозиция на отношението СЪТРУДНИЦИ-ОТДЕЛИ-ПРОЕКТИ на двете отношения СЪТРУДНИЦИ-ОТДЕЛИ и СЪТРУДНИЦИ-ПРОЕКТИ: СЪТРУДНИЦИ-ОТДЕЛИ (СЪТР_НОМЕР, СЪТР_ЗАПЛ, ОТД_НОМЕР) Първичен ключ: СЪТР_НОМЕР Функционални зависимости: СЪТР_НОМЕР -> СЪТР_ЗАПЛ СЪТР_НОМЕР -> ОТД_НОМЕР ОТД_НОМЕР -> СЪТР_ЗАПЛ СЪТРУДНИЦИ-ПРОЕКТИ (СЪТР_НОМЕР, ПРО_НОМЕР, СЪТР_ЗАДАН) Първичен ключ: СЪТР_НОМЕР, ПРО_НОМЕР Функционални зависимости: СЪТР_НОМЕР, ПРО_НОМЕР -> CЪТР_ЗАДАН Всяко от тези две отношения е в 2NF, и в тях са отстранени отбелязаните по-горе аномалии (лесно се проверява, че всички указани операции се изпълняват без проблеми). Ако се допусне наличие на няколко ключа, то определение 6 ще има следния вид:
Отношение R е във втора нормална форма (2NF) тогава и само тогава, когато то е в 1NF, и всеки неключов атрибут напълно зависи от всеки ключ R. 6.1.2. Трета нормална формаДа разгледаме още един път отношението СЪТРУДНИЦИ-ОТДЕЛИ, което е в 2NF. Функционалната зависимост СЪТР_НОМЕР -> СЪТР_ЗАПЛ е транзитивна; тя е следствие от функционалните зависимости СЪТР_НОМЕР->ОТД_НОМЕР и ОТД_НОМЕР -> СЪТР_ЗАПЛ. С други думи, работната заплата на сътрудника всъщност е характеристика не на сътрудника, а на отдела, в който той работи (това не е добро естествено предположение, но е достатъчно за примера). В резултат няма да можем да запишем в базата от данни информация, характеризираща работната заплата на отдел, дотогава, докато в този отдел не се появи поне един сътрудник (първичният ключ не може да съдържа неопределена стойност). При изтриване на кортежа, описващ последния сътрудник на даден отдел, ще се лишим от информацията за работната заплата в отдела. За да може съгласувано да се измени работната заплата на отдела, ще сме принудени предварително да намерим всички кортежи, описващи сътрудниците на този отдел. Т.е. в отношението СЪТРУДНИЦИ-ОТДЕЛИ както и преди съществуват аномалии. Тях можем да отстраним чрез по-нататъшна нормализация. Определение 7. Трета нормална форма. (Отново определението се дава при предположение за съществуване на единствен ключ.) Отношение R е в трета нормална форма (3NF) тогава и само тогава, ако е в 2NF и всеки неключов атрибут нетранзитивно зависи от първичния ключ. Може да се извърши декомпозиция на отношението СЪТРУДНИЦИ-ОТДЕЛИ на двете отношения СЪТРУДНИЦИ и ОТДЕЛИ: СЪТРУДНИЦИ (СЪТР_НОМЕР, ОТД_НОМЕР) Първичен ключ: СЪТР_НОМЕР Функционални зависимости: СЪТР_НОМЕР -> ОТД_НОМЕР ОТДЕЛИ (ОТД_НОМЕР, СЪТР_ЗАПЛ) Първичен ключ: ОТД_НОМЕР Функционални зависимости: ОТД_НОМЕР -> СЪТР_ЗАПЛ Всяко от тези две отношения е в 3NF и е свободно от отбелязаните аномалии. Ако се откажем от ограничението, отношението да има единствен ключ, то определението за 3NF ще приеме следната форма:
Отношение R е в трета нормална форма (3NF) тогава и само тогава, ако е в 2NF, и всеки неключов атрибут не е транзитивно зависим от някакъв ключ R. На практика трета нормална форма на схемите на отношения е достатъчна в повечето случаи, и с привеждането към трета нормална форма процесът на проектиране на релационна база от данни обикновено завършва. Но понякога е полезно да се продължи процеса на нормализация.
СЪТРУДНИЦИ-ПРОЕКТИ (СЪТР_НОМЕР, СЪТР_ИМЕ, ПРО_НОМЕР, СЪТР_ЗАДАН) Възможни ключове: СЪТР_НОМЕР, ПРО_НОМЕР СЪТР_ИМЕ, ПРО_НОМЕР Функционални зависимости: СЪТР_НОМЕР -> CЪТР_ИМЕ СЪТР_НОМЕР -> ПРО_НОМЕР СЪТР_ИМЕ -> CЪТР_НОМЕР СЪТР_ИМЕ -> ПРО_НОМЕР СЪТР_НОМЕР, ПРО_НОМЕР -> CЪТР_ЗАДАН СЪТР_ИМЕ, ПРО_НОМЕР -> CЪТР_ЗАДАН В този пример предполагаме, че личността на сътрудник напълно се определя както от номера му, така и от името (това отново не е добро жизнено предположение, но е достатъчно за примера). В съответствие с определение7~ отношението СЪТРУДНИЦИ-ПРОЕКТИ е в 3NF. Но фактът, че има функционални зависимости на атрибутите на отношението от атрибута, явяващ се част от първичния ключ, води до аномалии. Например, за да се измени името на сътрудник с даден номер по съгласуван начин, ще трябва да модифицираме всички кортежи, включващи неговия номер. Определение 8. Детерминанта Детерминанта - произволен атрибут, от който напълно функционално зависи някой друг атрибут. Определение 9. Нормална форма на Бойс-Код Отношение R е в нормална форма на Бойс-Код (BCNF) тогава и само тогава, когато всяка детерминанта е възможен ключ. Очевидно е, че това изискване не е изпълнено за отношението СЪТРУДНИЦИ-ПРОЕКТИ. Може да се извърши декомпозицията му към отношенията СЪТРУДНИЦИ и СЪТРУДНИЦИ-ПРОЕКТИ: СЪТРУДНИЦИ (СЪТР_НОМЕР, СЪТР_ИМЕ) Възможни ключове: СЪТР_НОМЕР СЪТР_ИМЕ Функционални зависимости: СЪТР_НОМЕР -> CЪТР_ИМЕ СЪТР_ИМЕ -> СЪТР_НОМЕР СЪТРУДНИЦИ-ПРОЕКТИ (СЪТР_НОМЕР, ПРО_НОМЕР, СЪТР_ЗАДАН) Възможен ключ: СЪТР_НОМЕР, ПРО_НОМЕР Функционални зависимости: СЪТР_НОМЕР, ПРО_НОМЕР -> CЪТР_ЗАДАН Възможна е алтернативна декомпозиция, ако се избере за основа СЪТР_ИМЕ. В двата случая получаваните отношения СЪТРУДНИЦИ и СЪТРУДНИЦИ-ПРОЕКТИ са в BCNF, и не са им присъщи отбелязаните аномалии. 6.1.4. Четвърта нормална формаДа разгледаме следната схема на отношение: ПРОЕКТИ (ПРО_НОМЕР, ПРО_СЪТР, ПРО_ЗАДАН) Отношението ПРОЕКТИ съдържа номерата на проектите, за всеки проект – списъкът на сътрудниците, които могат да изпълняват проекта, и списъкът задания, предвидени в проекта. СЪТРУДНИЦИ може да участвуват в няколко проекта, и различни ПРОЕКТИ може да включват еднакви задания. Всеки кортеж на отношение свързва проект със сътрудник, участващ в този проек, и заданието, което сътрудникът изпълнява в рамките на дадения проект (предполагаме, че всеки сътрудник, участващ в проекта, изпълнява всички задания, предвидени от този проект). По причина на сформулираните по-горе условия единственият възможен ключ на отношението е съставният атрибут ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН, и няма никакви други детерминанти Следователно, отношението ПРОЕКТИ е в BCNF. Но при това то има недостатъци: ако, например, някой сътрудник се присъедини към дадения проект, трябва да се вмъкнат в отношението ПРОЕКТИ толкова кортежи, колкото задания са предвидени в него. Определение 10. Многозначни зависимости В отношението R (A, B, C) съществува многозначна зависимост R.A -> -> R.B тогава и само тогава, когато множеството значения на B, съответстващо на двойка стойности на A и C, зависи само от A и не зависи от С. В отношението ПРОЕКТИ съществуват следните две многозначни зависимости: ПРО_НОМЕР -> -> ПРО_СЪТР ПРО_НОМЕР -> -> ПРО_ЗАДАН Леко се доказва, че в общия случай в отношението R (A, B, C) съществува многозначната зависимост R.A -> -> R.B тогава и само тогава, когато съществува многозначната зависимост R.A -> -> R.C. Пo-нататъшната нормализация на отношенията, подобни на отношението ПРОЕКТИ, се основава на следната теорема:
Отношението R (A, B, C) може да се проецира без загуби в отношенията R1 (A, B) и R2 (A, C) тогава и само тогава, когато съществува MVD A -> -> B | C. Под проециране без загуби се разбира такъв начин на декомпозиция на отношение, при който изходното отношение напълно и без излишност се възстановява чрез естествено съединение на получените отношения.
Отношение R е в четвърта нормална форма (4NF) тогава и само тогава, ако в случай на съществуване на многозначна зависимост A -> -> B всички останали атрибути на R функционално зависят от A. В нашия пример може да се извърши декомпозиция на отношението ПРОЕКТИ на две отношения ПРОЕКТИ-СЪТРУДНИЦИ и ПРОЕКТИ-ЗАДАНИЯ: ПРОЕКТИ-СЪТРУДНИЦИ (ПРО_НОМЕР, ПРО_СЪТР) ПРОЕКТИ-ЗАДАНИЯ (ПРО_НОМЕР, ПРО_ЗАДАН) Тези две отношения са в 4NF и са свободни от отбелязаните аномалии. 6.1.5. Пета нормална формаВъв всички разгледани до момента нормализации се извършва декомпозиция на едно отношение в две. Понякога това не може да се направи, но е възможна декомпозицията в по-голям брой отношения, всяко от които има по-добри свойства. Да разгледаме, например, отношението СЪТРУДНИЦИ-ОТДЕЛИ-ПРОЕКТИ (СЪТР_НОМЕР, ОТД_НОМЕР, ПРО_НОМЕР) Да предположим, че един и същи сътрудник може да работи в няколко отдела и работи във всеки отдел над няколко проекта. Първичният ключ на това отношение е пълната съвокупност от атрибутите му, отсъстват функционални и многозначни зависимости. Затова отношението е в 4NF. Но в него могат да съществуват аномалии, които може да се отстранят чрез декомпозиция на три отношения.
Отношение R (X, Y, ..., Z) удовлетворява зависимостта за съединение * (X, Y, ..., Z) тогава и само тогава, когато R се възстановява без загуби чрез съединение на своите проекции на X, Y, ..., Z. Определение 13. Пета нормална форма Отношение R е в пета нормална форма (нормална форма на проекция-съединение - PJ/NF) тогава и само тогава, когато всяка зависимост на съединение в R следва от съществуването на някакъв възможен ключ в R. Ще въведем следните имена на съставните атрибути: СО = {СЪТР_НОМЕР, ОТД_НОМЕР} СП = {СЪТР_НОМЕР, ПРО_НОМЕР} ОП = {ОТД_НОМЕР, ПРО_НОМЕР} Да предположим, че в отношението СЪТРУДНИЦИ-ОТДЕЛИ-ПРОЕКТИ съществува зависимостта на съединение:
В примерите лесно се показва, че при вмъквания и изтривания на кортежи може да възникнат проблеми. Тях можем да отстраним чрез декомпозиция на изходното отношение в три нови отношения: СЪТРУДНИЦИ-ОТДЕЛИ (СЪТР_НОМЕР, ОТД_НОМЕР) СЪТРУДНИЦИ-ПРОЕКТИ (СЪТР_НОМЕР, ПРО_НОМЕР) ОТДЕЛИ-ПРОЕКТИ (ОТД_НОМЕР, ПРО_НОМЕР) Пета нормална форма е последната нормална форма, която може да бъде получена чрез декомпозиция. Нейните условия са достатъчно нетривиални, и на практика 5NF не се използва. Да отбележим, че зависимостта на съединение е обобщение както на многозначна зависимост, така и на функционална зависимости. 6.2. Семантично моделиране на данни, ER-диаграмиШирокото разпространение на релационните СУБД и използването им в най-разнообразни приложения показва, че релационния модел данни е достатъчен за моделиране на предметни области. Но проектирането на релационна база от данни в термините на отношенията на основата на разгледания механизъм на нормализация често представлява много сложен и неудобен за проектировчика процес. При това се проявява ограничеността на релационния модел данни в следните аспекти:
6.2.1. Семантични модели данниПотребностите на проектировчиците на бази от данни от по-удобни и мощни средства за моделиране на предметна област предизвикват появата на направлението на семантичните модели данни. Макар, че всеки развит семантичен модел данни, както и релационния модел, включва структурна, манипулационна и цялостна част, главното предназначение на семантичните модели е осигуряването на възможност за изразяване на семантиката на данните. Преди, да разгледаме накратко особеностите на един от най-разпространените семантични модели, ще се спрем на техните възможни приложения. Най-често на практика семантичното моделиране се използва на първия стадий от проектирането на база от данни. При това в термините на семантичния модел се извежда концептуалната схема на базата от данни, която след това ръчно се преобразува в релационна (или друга) схема. Този процес се изпълнява под управлението на методики, в които достатъчно точно са определени всички етапи на такова преобразуване. Не толкова често се реализира автоматизирана компилация на концептуалната схема в релационна. При това са известни два подхода: на основата на явно представяне на концептуалната схема като изходна информация за компилатора и построяването на интегрирани системи за проектиране с автоматизирано създаване на концептуална схема на основата на интервюта с експерти по предметната област. И в единия, и в другия случай в резултат се извежда релационна схема на базата от данни в трета нормална форма (по-точно, не са ни известни системи, осигуряващи по-високо ниво на нормализация). Накрая, третата възможност, която още не е излязла (или сега излиза) извън границите на изследователските и експериментални проекти, - това е работа с базата от данни в семантичния модел, т.е. СУБД, основани на семантични модели данни. При това отново се разглеждат два варианта: осигуряване на потребителски интерфейс на основата на семантичния модел данни с автоматично изобразяване на конструкциите в релационния модел данни (това е задача примерно от такова ниво сложност, като автоматичната компилация на концептуалната схема на база от данни в релационна схема) и пряка реализация на СУБД, основана на семантичен модел данни. Най-близко до втория подход са съвременните обектно-ориентирани СУБД, моделите данни на които по много параметри са близки до семантичните модели (макар че в някои аспекти те са по-мощни, а в други – по-слаби).
Основните понятия на ER-модели са същност, връзка и атрибут. Същност - това е реален или представян обект, информацията за който трябва да се съхранява и да бъде достъпна. В диаграмите на ER-модела същността се представя като правоъгълник, съдържащ името на същността. При това името на същността е име на тип, а не на някакъв конкретен екземпляр от този тип. За по-голяма изразителност и по-добро разбиране името на същност може да се съпровожда с примери за конкретни обекти от този тип. По-долу е изобразена същността АЕРОПОРТ с примерни обекти Шереметьево и Хитроу: 
Всеки екземпляр на същност трябва да е отличим от всеки друг екземпляр на тази същност (това изискване е в някаква степен аналогично на изискването за отсъствие на кортежи-дубликати в релационните таблици). Връзка – това е графично изобразена асоциация, устанавявана между две същности. Тази асоциация винаги е бинарна и може да съществува между две различни същности или между същност и нея самата (рекурсивна връзка). Във всяка връзка изпъкват два края (в съответствие със съществуващата двойка свързани същности), на всеки от които се посочва името на края на връзката, степента на края на връзката (колко екземпляра от дадената същност се свързват), задължителност на връзката (т.е. всеки ли екземпляр от дадената същност трябва да участвува в дадената връзка). Връзката се представя като линия, свързваща двете същности или водеща от същност към нея самата. При това в мястото на "стиковката" на връзката със същността се използва триточков вход в правоъгълника на същността, ако за тази същност във връзката могат да се използват много (many) екземпляри на същността, и едноточков вход, ако във връзката може да участвува само един екземпляр на същността. Задължителният край на връзката се изобразява с плътна линия, а незадължителния – с прекъсната линия. Както и същността, връзката е типово понятие, всички екземпляри на двете двойки свързвани същности се подчиняват на правилата за свързване. В изобразения по-долу пример връзката между същностите БИЛЕТ и ПЪТНИК свързва билети и пътници. При това края на същността с име "за" позволява да се свързват с един пътник повече от един билет, при това всеки билет трябва да е свързан с някакъв пътник. Краят на същността с име "има" означава, че всеки билет может да принадлежи само на един пътник, при това пътникът не е длъжен да има поне един билет. 
Лаконична устна трактовка на изобразената диаграма е следната:
В следващия пример е изобразена рекурсивна връзка, свързваща същността ЧОВЕК със самaта нея. Краят на връзката с име "син" определя факта, че един баща може да има повече от един син. Краят на връзката с име "баща" означава, че не всеки човек може да има синове. 
Лаконична устна трактовка на изобразената диаграма е следната:
Атрибут на същност е всеки детайл, който служи за уточнение, идентификация, класификация, числова характеристика или изразяване на състоянието на същността. Имената на атрибутите се записват в правоъгълника, изобразяващ същността, под името на същността и се изобразяват с малки букви, ако е възможно, с примери. Уникален идентификатор на същност е атрибут, комбинация от атрибути, комбинация от връзки или комбинация от връзки и атрибути, уникално отличаваща всеки екземпляр на същност от другите екземпляри на същността от този тип. 6.2.3. Нормални форми на ER-схемиКакто и в релационните схеми на бази от данни, в ER-схемите се въвежда понятието нормални форми, при това техният смисъл много близко съответствува на смисъла на релационните нормални форми. Формулировките за нормални форми на ER-схемите правят по-понятен смисъла на нормализацията на релационните схеми. Ще приведем само много кратки и неформални определения на трите първи нормални форми. В първата нормална форма на ER-схема се отстраняват повтарящите се атрибути или групи атрибути, т.е. изваждат се на показ неявните същности, "маскирани" като атрибути. Във втора нормална форма се остраняват атрибутите, зависещи само от част на уникалния идентификатор. Тази част на уникалния идентификатор определя отделната същност. В трета нормална форма се отстраняват атрибутите, зависещи от атрибути, невлизащи в уникалния идентификатор. Тези атрибути са основата на отделната същност. 6.2.4. По- сложни елементи на ER-моделаСпряхме се само на най-основните и най-очевидни понятия на ER-модела на данни. Към по-сложните елементи на модела се отнасят следните:
Тези и други по-сложни елементи на модела данни "Същност-Връзки" го правят съществено по-мощен, но одновременно в някаква степен усложняват използването му. Разбира се, при реално използване на ER-диаграмите за проектиране на бази от данни е необходимо да се запознаем с всички възможности. Тук ще се спрем по-подробно само на един от споменатите елементи - подтип на същност. Същност може да бъде разцепена на два или повече взаимно изключващи се подтипа, всеки от които включва общи атрибути и/или връзки. Тези общи атрибути и/или връзки явно се определят един път на по-високо ниво. В подтиповете може да се определят собствени атрибути и/или връзки. По принцип подтипизацията може да продължава на по-ниски нива, но опитът показва, че в повечето случаи са достатъчни две-три нива. Същност, на основата на която се определят подтипове, се нарича супертип. Подтиповете трябва да образуват пълно множество, т.е. всеки екземпляр на супертипа трябва да се съотнася към някакъв подтип. Понякога за пълнота се налага да се определя допълнителен подтип ДРУГИ. Пример: Супертип ЛЕТАТЕЛЕН АПАРАТ
Как би трябвало това да се чете? От супертипа: ЛЕТАТЕЛЕН АПАРАТ, който трябва да е АЕРОПЛАН, ВЪРТОЛЕТ, ПТИЦЕЛЕТ или ДРУГ ЛЕТАТЕЛЕН АПАРАТ. От подтипа: ВЪРТОЛЕТ, който се отнася към типа ЛЕТАТЕЛЕН АПАРАТ. От подтипа, който е едновременно супертип: АЕРОПЛАН, който се отнася към типа ЛЕТАТЕЛЕН АПАРАТ и трябва да е ПЛАНЕР или МОТОРЕН САМОЛЕТ. Понякога е удобно да има две или повече различни разбивания на същност на подтипове. Например, същността ЧОВЕК може да бъде разбита на подтипове по професионален признак (ПРОГРАМИСТ, ДОЯРКА и т.н.), а може - по полов признак (МЪЖ, ЖЕНА).
При използване на способ (а) таблица се създава за най-външния супертип, а за подтиповете може да се създават представяния. В таблицата се добавя поне един стълб, съдържащ кода на ТИПА; той става част от първичния ключ. При използване на метод (б) за всеки подтип от първо ниво (за по-ниските - представяния) супертип се създава с помощта на представянето UNION (от всички таблици на подтипове се избират общите столбове – столбовете на супертипа).
Стъпка 7. Има два начина за работа при наличие на изключващи връзки:
Ако оставащите външни ключи са всички в един домейн, т.е. имат общ формат (способ (а)), то се създават два стълба: идентификатор на връзката и идентификатор на същността. Стълбът на идентификатора на връзката се използва за различаване на връзките, покривани от дъгата на изключението. Стълбът на идентификатора на същността се използва за съхраняване на стойностите на уникалния идентификатор на същността на далечния край на съответната връзка. Ако резултиращите външни ключове не се отнасят към един домейн, то за всяка връзка, покривана от дъгата на изключение, се създават явни стълбци на външни ключове; всички тези стълбци могат да съдържат неопределени значения.
Алтернативни модели на същности: Вариант 1 (лош) 
Вариант 2 (съществено по-добър, ако подтиповете действително съществуват) 
Вариант 3 (приложим при наличие на осмислен супертип D). 
Лекция 10. Управление на транзакции, сериализация на транзакциите Поддържането на механизма на транзакциите е показател за нивото на развитост на СУБД. Коректното поддържане на транзакциите едновременно е основа за обеспечаване целостността на базите от данни (и затова транзакциите са напълно уместни и в еднопотребителските персонални СУБД), а също съставя и базиса на изолираността на потребителите в многопотребителските системи. Често тези два аспекта се разглеждат отделно, но реално те са взаимосвързани, което и ще бъде показано в тази лекция. Макар, че от гледна точка на осигуряването на целостността на базите от данни механизмът на транзакциите би трябвало да се поддържа в персоналните СУБД, на практика това обикновено не се изпълнява. Затова при прехода от персонални към многопотребителските СУБД потребителите се сблъскват с необходимостта от точно разбиране на природата на транзакциите. Под транзакция се разбира неделима, от гледна точка на въздействието върху БД, последователност от оператори за манипулиране с данните (четене, изтриване, вмъкване, модификация) такава, че или резултатите от всички оператори, включени в транзакцията, се отразяват в БД, или въздействието на всички тези оператори напълно отсъствува. Лозунг на транзакцията - "Всичко или нищо": при завършване на транзакцията с оператор COMMIT резултатите гарантирано се фиксират във външната памет (смисълът на думата commit е "да се фиксират" резултатите на транзакция); при завършване на транзакция с оператор ROLLBACK резултатите гарантирано отсъстват във външната памет (смисълът на думата rollback е да се ликвидират резултатите на транзакция).
Затова за поддържане на подобни ограничения за цялостност се допуска тяхното нарушаване вътре в транзакцията с това условие, че към момента на завършване на транзакцията условията за цялостност ще бъдат спазени. В системите с развити средства за ограничение и контрол на целостността всяка транзакция започва при цялостно състояние на БД и трябва да остави това състояние цялостно и след своето завършване. Несъблюдаването на това условие води до това, че вместо фиксация на резултатите на транзакция се извършва нейния откат (т.е. вместо оператора COMMIT се изпълнява оператор ROLLBACK), и БД остава в това състояние, в което се е намирала към момента на началото на транзакцията, т.е. в цялостно състояние. Ако трябва да сме по-точни, различават се два вида ограничения на целостността: незабавно проверявани и отлагани. Към незабавно проверяваните ограничения на целостността се отнасят такива ограничения, проверката на които е безмислено или даже невъзможно да отлага. Пример за ограничения, проверката на които да се отлага е безмислено, са ограниченията на домейн (възрастта на сътрудника не може да превишава 150 години). По-сложно ограничение, проверката на което е невъзможно да се отложи, е следното: заплатата на сътрудник не може да бъде увеличена за една операция с повече от 100,000 рубли. Незабавно проверяваните ограничения на цялостността съответстват на нивото на отделните оператори на езиковото ниво на СУБД. При нарушенията им не се извършва откат на транзакцията, а само се отхвърля съответния оператор. Отлаганите ограничения на целостността са ограничения върху базата от данни, а не върху някакви отделни операции. По подразбиране такива ограничения се проверяват при края на транзакция, и нарушението им предзвиква автоматическа замяна на оператора COMMIT с оператор ROLLBACK. Но в някои системи се поддържа специален оператор за насилствена проверка на ограниченията за цялостност вътре в транзакцията. Ако след изпълнението на такъв оператор се открие, че условията за цялостност не са изпълнени, потребителят може сам да изпълни оператор ROLLBACK или да се постарае да отстрани причините за нецялостното състояние на базата от данни вътре в транзакцията (видимо, това има смисъл само при използване на интерактивен режим на работа). От гледна точка на външното представяне в момента на завършване на транзакция се проверяват всички отлагани ограничения за цялостност, определени в тази база от данни. Но при реализацията стремежът е при изпълнението на транзакция динамически да се определят тези ограничения за цялостност, които действително биха могли да бъдат нарушени. Например, ако при изпълнение на транзакция над базата от данни СЪТРУДНИЦИ-ОТДЕЛИ в нея не са се изпълнявали оператори за вмъкване или изтриване на кортежи от отношението СЪТРУДНИЦИ, то да се проверява споменатато по-горе ограничение за цялостност не се изисква (а проверката на подобни ограничения предизвиква достатъчно много работа).
Във връзка със свойството за съхранение на цялостта на БД транзакциите представляват подходящи единици за изолираност на потребителите. Действително, ако с всеки сеанс на работа с базата от данни се асоциира транзакция, то всеки потребител започва работа със съгласувано състояние на базата от данни, т.е. с такова състояние, в което базата от данни би могла да се намира, даже ако потребителят работи с нея сам. При съблюдаването на задължителното изискване за поддържане на цялостност на базата от данни са възможни следните нива на изолираност на транзакциите:
Съществува възможност за осигуряване на различни нива на изолираност за различните транзакции, изпълнявани в една система бази от данни (в частност, съответстващите оператори са предвидени в стандарта SQL 2). Както вече отбелязахме, за поддържане на цялостност е достатъчнo първото ниво. Съществуват редица приложения, за които първо ниво е достатъчно (например, приложните или системните статистически утилити, за които некоректността на индивидуалните данни е несъществена). При това се удава съществено да се съкратят съпътстващите разходи за СУБД и да се повиши общата ефективност. Към по-тънките проблеми на изолираността на транзакциите се отнася така наречения проблем на кортежите-"фантоми", предизвикващ ситуации, които също противоречат на изолираността на потребителите. Разглеждаме следния сценарий. Транзакция 1 изпълнява оператор A за избиране на кортежи от отношение R с условие на избор S (т.е. избира се част от кортежите на отношение R, удовлетворяващи условието S). До завършване на транзакция 1 транзакция 2 вмъква в отношение R новият кортеж r, удовлетворяващ условието S, и успешно завършва. Транзакция 1 повторно изпълнява оператор A, и в резултат се появява кортеж, който отсъства при първото изпълнение на оператора. Такава ситуация противоречи на идеята за изолираност на транзакциите и може да възникне даже на трето ниво на изолираност на транзакциите. За да се избегне появата на кортежи-фантоми, е необходимо по-високо "логическо" ниво на синхронизация на транзакциите. Идеите за такава синхронизация (предикатни синхронизационни захвати) са известни отдавна, но в повечето системи не са реализирани. 10.3. Сериализация на транзакциитеЯсно е, че за да се постигне изолираност на транзакциите, в СУБД трябва да се използват някакви методи за регулиране на съвместното изпълнение на транзакциите. Планът (способът) за изпълнение на набор транзакции се нарича сериален, ако резултатът от съвместното изпълнение на транзакциите е еквивалентен на резултата от някакво последователно изпълнение на тези транзакции. Сериализацията на транзакциите е механизъм за тяхното изпълнение по някакъв сериален план. Осигуряването на такъв механизъм е основната функция на компонента на СУБД, отговорен за управлението на транзакциите. Система, в която се поддържа сериализация на транзакциите осигурява реална изолираност на потребителите. Основният реализационен проблем се състои в избора на метода за сериализация на набора транзакции, който не ограничава твърде много тяхната паралелност. Идващото на ум тривиално решение се явява действително последователното изпълнение на транзакциите. Но съществуват ситуации, в които може да се изпълняват оператори на различни транзакции в произволен ред със съхраняване на сериалността. За примери могат да служат само четящите транзакции, а също и транзакциите, не конфликтуващи по обектите на базата от данни. Между транзакциите може да съществуват следните видове конфликти:
Практическите методи за сериализация на транзакции се основават на отчитането на тези конфликти. Каталог: tadmin -> upload -> storage storage -> Литература на факта. Аналитизъм. Интерпретативни стратегии. Въпроси и задачи storage -> Лекция №2 Същност на цифровите изображения Въпрос. Основни положения от теория на сигналите storage -> Лекция 5 система за вторична радиолокация storage -> Толерантност и етничност в медийния дискурс storage -> Ethnicity and tolerance in media discourse revisited Desislava St. Cheshmedzhieva-Stoycheva abstract storage -> Тест №1 Отбележете невярното твърдение за подчертаните думи storage -> Лекции по Въведение в статистиката storage -> Търсене на живот във вселената увод storage -> Еп. Константинови четения – 2010 г някои аспекти на концептуализация на богатството в руски и турски език Изтегляне 1.71 Mb. Сподели с приятели:
|
