Съставен ключ (Composite key)

Изборът на правилно ключово поле е много важен за проектирането на базата данни. Понякога водени от текущата действителност можем да останем заблудени, че дадено поле не може да се повтаря и да го назначим са първичен ключ.
Например ако в момента в катедра КСТ няма двама преподаватели с еднакви имена, можем грешно да предположим, че никога няма да има и да изберем за първичен ключ името на преподавателя. Така в бъдеще нашата система няма да може да приеме нов преподавател с повтарящо се име.
Понякога, както в случая със студентите обектът си има свойство, което го различава уникално от останалите – факултетен номер или ЕГН. В други случаи обектът няма такова свойство – например бюрата в дадена катедра нямат сериен номер. Докато в практиката ние ги различаваме по местоположение (това е бюрото вляво до прозореца) или преподавател, който ги използва (това е бюрото на...), в базата данни не може да се направи различие по принадлежност или местоположение. В този случай обикновено в базата данни се вмъква изкуствено ключово поле – свойство, което реалният обект не притежава
(например номер на бюро), но то се поставя като колона в таблицата и му се присвоява уникален номер, за да може то да се различава от останалите. И докато в базата данни има бюро номер 5, то в практиката никой не се интересува и не използва този номер, той служи единствено и само като първичен ключ, който да различава отделните редове в таблицата.
Понякога в практиката дори и обектът да има свойство, което го различава от останалите, проектантът на базата данни вмъква изкуствено ключово поле (идентификатор на обекта) и го използва по навик за различаване на редовете. Този подход е работоспособен, но в повечето случаи няма смисъл – студентът си има факултетен номер, защо трябва да му назначаваме още един фиктивен номер, например пореден номер на въвеждане в базата, след като няма да се интересуваме от него.
Пример за релационна база данни е показан на фигура 2.3.

Фигура 2.3. Релационен модел.
В примера има три таблици (релации) – „студенти“,
„преподаватели“ и „дисциплини“. В таблицата „студенти“ първичният ключ е полето „факултетен номер“.
Преподавателите нямат номера, затова в таблицата
„преподаватели“ е вмъкнат изкуствен ключ „номер“, който служи за разграничаване на отделните преподаватели. Така се позволява да има двама преподаватели с еднакви имена, длъжност и катедра. За да се избегне повторението на данни в таблицата „дисциплина“ поле „преподавател“ се вмъква само номерът на преподавателя, по който могат да се прочетат другите му данни – име, длъжност и катедра. Така полето
„преподавател“ в таблицата „дисциплина“ е чужд ключ – в него могат да се пишат само стойности, които вече са въведени в таблицата „преподаватели“, както и не може да се изтрие преподавател от таблицата „преподаватели“, ако на него са му поверени дисциплини. Връзката е по тип „едно към много“, защото една дисциплина се води само от един преподавател, но всеки преподавател може да води повече от една дисциплина.
Връзката на студентите с дисциплините се прави по две полета – курс и специалност, защото дадена дисциплина се изучава от една или повече специалности в един курс.
Връзката е от тип M:N, защото един студент изучава няколко дисциплини и много студенти едновременно изучават една дисциплина. Така ако трябва да се разпечата изпитен протокол по бази данни се изчита редът от таблицата

„дисциплини“, намира се преподавателя в таблицата
„преподаватели“ и неговите данни се изпечатват в горната част на протокола, след което от таблицата „студенти“ се взимат всички, които са в дадената специалност и курс и се добавят в протокола.
Обектният модел на базите данни води началото си от принципите на обектно-ориентираното програмиране. За разлика от структурното програмиране, при което програмата разделя данните и кода, който ги обработва, при обектно- ориентираното данните и кода се обединяват в общ обект.
Обектът се състои от атрибути, които съответстват на данните, съдържащи се в обекта и методи, които са функциите, предвидени за обработка на атрибутите. Наборът обекти, притежаващи общи атрибути и методи се групират в класове.
Типични свойства на обектите са:

Капсулация (Encapsulation) – обединяване на данните с кода, който ги обработва. Обикновено потребителят не борави директно с данните а трябва да има подходящи методи за всяка операция, която иска да извърши с обекта;

Наследяване (Inheritance) – възможността да наследим един обект и да променим неговото поведение или да добавим нова функционалност, чрез подмяна на родителските методи или добавяне на нови;

Полиморфизъм (Polymorphism) – наследеният клас знае всички методи на своите родителски класове, дори и те да са били променени и може при нужда да функционира като родителския клас.
Обектно-ориентираните бази данни са предназначени да съхраняват обекти от обектно-ориентираните езици. Възможно е обектите да се съхраняват в релационна база данни, но това би наложило всичките им атрибути да се сведат до числови и тесктови променливи и да се опишат в таблици, а също така да се запише и кода на методите, което води до много последователни операции при четене и запис. Вместо това в обектно-ориентираната база данни се записва целия обект,

който се идентифицира от неговия уникален идентификатор.
Обектните бази данни се използват при наличие на сложни данни и/или сложни връзки между данните. Типични приложения са мултимедийни и CAD-CAM (computer aided design - computer aided manufacture) приложения.
Обектно-релационният модел има за цел да позволи лесната манипулация на обекти, като позволи те да се съхраняват в таблици, за по-лесна обработка. За да позволят обектно ориентирано поведение релациите могат да се наследяват, като наследената таблица може да добави или промени полетата на родителската. Базата данни може да съдържа код за обработка на данните под формата на съхранени процедури
(Stored procedures), които вместо в потребителското приложение се запазват и изпълняват в базата данни.
Потребителят може да разширява вградените типове данни
(числа, дати), модифицирайки ги до нещо, което е необходимо за приложението. Типичен пример за такива са географските данни, вградени в съвременните версии на MySQL – например обектът „точка“ в пространството може да се дефинира чрез трите си географски координати – x, y и z. Обектът „отсечка“ може да се дефинира като двете си крайни точки и т.н.
Описателните модели не определят начина, по който се записват и обработват данните, а се използват за описание на структурата и връзките между данните. Те имат по-голям смисъл при документирането на бази данни и програмни приложения.

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

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