Тема 5 . Моделиране на класовете за съхраняване на информация в релационни бази от данни РБД

1. Тема 5. Моделиране на класовете за съхраняване на информация в релационни бази от данни РБД

2. Моделиране на класовете за съхраняване на информация в релационни бази от данни РБД • Основни понятия; • Моделиране на обектите в РБД • Основни принципи при моделиране на обекти и класове • Създаване на обектни идентификатори в класовете за съхраняване на данни; • Начини за генериране на OID; • Моделиране на обектните наследявания в РДБ; • Моделиране на отношения (релации); • Стратегии за имплементиране на кода: • Стратегия на грубата сила;

3. Основни понятия Определение: Моделът на класовете за съхраняване се нарича даннов модел . Той се използва от всички разработчици на системата. Релационните бази данни не поддържат концепцията на ООП, поради което моделът на базата данни често се различава от класовата диаграма.

4. Основни понятия Основни технологиии предназначение: • Обектната технология, с която се реализира бизнес логиката; • Технологията на релационните бази данни (RDB), за съхраняване на информацията; Съществуват и други процедурни варианти, напр. в COBOL, за реализиране на бизнес логиката и данни, основани на XML или обекно-ориентирани бази данни. COBOL е обект на отделно изучаване, както и базите данни, основани на XML, които се изучават по други дисциплини, а обектните бази данни са технологии от по-ниско ниво. Може да се твърди, че съвременните основни технологии са обектната – за бизнес логиката и релационната - за съхранение на данни RDB.

5. Основни понятия • Основната идея (парадигма) на ООП се основава на утвърдени технически принципи на програмирането. • Основната идея на релационната теория се основава на доказани математически принципи. Тъй като тези основни идеи са различни, двете технологии не си взаимодействат безпроблемно. Това, че двете идеи не се съвместяват се вижда от основния подход при достъпа. Докато в ООП същият се прави посредством отношения, в релационната теория се прави с връзка между таблици. Тази принципна разлика довежда до неидеално комбиниране между двата подхода.

6. Основни понятия Разработчиците типично използват ОО подход при моделиране на приложенията, модели, основани на UML диаграми, докато професионалистите по бази от данни боравят с ориентирани към данни подходи, като логически даннови модели LDM и физически даннови модели PDM. Освен това разработчиците на обектната структура не са квалифицирани в моделирането на данните и обратно.

7. Моделиране на обектите в РБД Основни принципи при моделиране на обекти и класове: • Атрибутите се организират в колони; • Класовете се представят с таблици; • Моделиране на наследяването на класовете в РБД; • Моделиране на отношенията в РДБ; • Едно към едно; • Едно към много; • Много към много; • Асоциация, агрегация и композиция;

8. Основни принципи при моделиране на обекти и класове • Организация на атрибутите в колони. Един атрибут може да се представи с нула или повече колони на релационната база от данни. В базата от данни не се записват всички атрибути. Например, могат да не се записват такива атрибути, стойностите на които могат да се изчислят от други с функции. Инстанциите на класовете могат да имат поле за съхраняване на сумата на фактура, но това поле не е задължително да има представяне в РДБ. • Частни случаи: Когато атрибут на обект е обект, той може да се представи в няколко колони (или самостоятелна таблица). Съвкупност от атрибути могат да се съхраняват в едно поле на базата от данни.

9. Основни принципи при моделиране на обекти и класове Например: Факултетния номер на студента е съвкупност от атрибутите: • година на приемане; • Факултет; • пореден номер. Тази информация може да се организира и в три полета на базата от данни, а формирането на стойността да става посредством метод (съвкупност от операции) на обектите.

10. Основни принципи при моделиране на обекти и класове • Организация на класовете в таблици С изключение на единични таблици, не може да се постигне еднозначно съвпадение на класовете с таблиците за съхраняването им. • Връзката между понятията на релационните бази данни и класовите понятия може да се обобщи със следната схема:

11. Основни принципи при моделиране на обекти и класове

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

13. Основни принципи при моделиране на обекти и класове Например, атрибутът street от класа Address се представя с колона Street на таблица Address. Общият принцип на достъп до атрибута attributeName на клас ClassName съответства на достъпа до ColumnName от таблица TableName. Типични примери за допълнителна специфична информация, свързана с достъпа до данновия обект, търсенето, подредбата в множеството са първичните ключове и автоматично инкрементиращи се полета, които нямат значение за бизнес логиката, както и данните за дата/време на записване на същата.

14. Основни принципи при моделиране на обекти и класове В примера това са колоните: • Address.AddressOID; • Address.UpdateCounter; • Address.DateCreated. които представят класа Address. Предназначение: • Address.AddressOID представя ключово поле в таблицата; • Address.UpdateCounter за защита от конкурентен достъп в многопотребителски режим (заключване на данните от записа); • Address.DateCreated за запис на информация за момента от време, в който е създаден и записан в таблицата текущия запис. Тези три колони са специфични за адресния обект и потенциално могат да се добавят в него.

15. Основни принципи при моделиране на обекти и класове Модел на асоциация между класа Address и държава State. На нея са показани само данновите части на класовете, които имат скрити (частни) атрибути за видимост. Добавени са частни атрибути за идентификация на обектите-Address.addressOID, Address.updateCounter и State.updateCounter. Бизнес обектите имат нужда от информация за конкурентен достъп - Address.updateCounter и State.updateCounter. На диаграмата не са обозначени колоните DateCreated в класовете, защото бизнес обектите няма причина да променят тази информация, докато са в паметта.

16. Основни принципи при моделиране на обекти и класове Методите за достъп на частните членове, които не са показани на схемата, get и set, често са по-сложни от тези за обикновените (бизнес) атрибути. Скритите атрибути най-често са за еднократно четене-те се установяват при първото обръщение за четене от базата и се запомнят. Методите за запис трябва да осигуряват това изискване със съответното документиране защо е така.

17. Създаване на обектни идентификатори в класовете за съхраняване на данни Предназначение: Обектните идентификатори служат за уникално идентифициране на обекта в записващата среда. В релационната терминология те се наричат ключове (key). Еквивалентният термин в обектните йерархии е “обектен идентификатор” (object identifier-OID). OID обикновено се имплементират като различими обекти в приложението, а в релационната схема като цели числа с възможно най-голяма дължина или като низове. OID се използват за осъществяване на връзка между таблиците, като позволяват да се групират елементи на таблиците, които участват в дадено отношение, в крайна сметка за реализиране на агрегация. Затова OID трябва да е уникален в рамките на класовата йерархия, още по-добре в рамките на приложението и най-добре за цялата организация-глобален идентификатор.

18. Създаване на обектни идентификатори в класовете за съхраняване на данни OID е уникален само за инстанциите на обекта Student към Person и има стойност, например 12345, тогава неговата уникалност се губи ако студентът стане професор, т.е. когато смени ролята си. Например, не е логично да има сравнение между студент и упражнение, защото такова преобразуване на обектите е недопустимо. В общият случай може да се очаква обектите да получат различни преобразувания, поради което е най-добре да имат глобален идентификатор.

19. Начини за генериране на OID • Да се използва функция MAX()+1 към данните на колоната, по която се прави уникален идентификатор. Осигурява уникалност в рамките на таблицата. Недостатък е допълнителното време за определяне на стойността; • Да се използва отделна таблица за съхраняване на следващата стойност на ключа. Състои се в четене, увеличаване и запис обратно в таблицата, съхраняваща само числото. По добър е от предходния но има недостатък-необходимостта от промяна на стойността на данните, т.е. допълнително обръщение към базата от данни; • Използване на универсален уникален идентификатор UUID на Open Software Fondation. Това е 128 битова стойност, образувана от Ethernet картата на компютъра или неин програмен еквивалент и текущото време на компютърната система. Предимствата са отлични. Недостатъка е необходимостта от мрежова карта, което не е портируемо както и потенциалната възможност да се управлява картата, респективно, полученият ключ.

20. Начини за генериране на OID • Глобален универсален идентификатор на Microsoft (GUID). Това е подобен на предходния подход като стратегия, получава 128 битов и е хеш от софтуерен идентификатор и времето. Използва се мрежовата карта. Може да осигури пълна уникалност за машината която го е продуцирала. Недостатък-не осигурява пълна уникалност при мрежови приложения; • Използване на създадените от разработчиците на системите за управление на бази от данни (СУБД) генериращи функции. Много от производителите на СУБД включват такива генератори, които могат да се използват в рамките на цялата база от данни и осигуряват уникалност за нея. Недостатък-не може да се използва при разпределена база от данни от различни производители;

21. Начини за генериране на OID • Използване на подходът HIGH/LOW. Подходът е прост и портируем, лесно се реализира и има висока ефективност и уникалност. • Основната идея е OID да се съставя от две части-уникална HIGH стойност, която се получава като код и N-разрядно число, което се присвоява като младша част към нея. Всеки път, когато се получава нова стойност за HIGH, младшата част се нулира. Например, ако HIGH=1701 и разрядността на LOW=4, тогава продуцираният OID ще получи начална стойност 17010000. С увеличаване на LOW с единица се получава следващ и т.н. до 17019999. След това се сменя старшата на 1702 и се нулира младшата. За получаване на HIGH се използват различни начини:

22. Начини за генериране на OID • Да се получи от СУБД. С 4-разрядна младша част се прави един достъп до СУБД на 10000 идентификатора; • Може да се използва мрежовата карта, с предимствата и недостатъците му; • Самостоятелно имплементиране на генератор, например написване на код за генериране на М-разрядно число с функция за увеличаване. Изискванията са кода да е уникален за цялата интегрирана среда.

23. Начини за генериране на OID • При самостоятелно имплементиране на генератор е необходимо: • Източникът да е един и да се използва от всички приложения. • Да се осигури достъп с критична секция до увеличаващата функционалност, както и единственост (Singletion) на обекта, който управлява процеса на създаване. • Разрядността да е достатъчна за обозначаване на всички обекти на организацията. Използват се 128 бита за HIGH и 16 или 32 бита за LOW. По-голямата разрядност позволява с прост алгоритъм да се образува новата уникална стойност. • Стойността на идентификатора не бива да се извежда на интерфейси, да не се допуска някой да може да го редактира или променя както и да го използва за друга цел, защото губи основното си предназначение. • Най-добре е никой да не знае за съществуването на такъв идентификатор с изключение на хората, които се занимават с тестването на схемата на базата от данни при нейното създаване. • Разпределеното проектиране трябва да се основава на подходящата за него HIGH/LOW старатегия.

24. Начини за генериране на OID • Поради това, че обектите са на една организация, може да се включи уникалния единтификатор на организацията към ключа за да се гарантира уникалност между организациите. Такава уникалност се нарича галактическа. Прост начин да се осигури това е на се добави името на Internet Domain адреса към идентификатора, което гарантира пренасянето на собствени стойности за HIGH. Може да се използват UUID и GUID, когато организацията обменя данни с други организации или е възможно сливане или разделяне на организации.

25. Моделиране на обектните наследявания в РДБ РДБ не поддържа от самосебе си наследяването, поради което е необходимо да се представи в схемата структурата на наследяване на класовата йерархия в схемата на данновата схема. Съществуват три подхода при имплементиране на наследяването в релационната база данни: • Представяне на цялата класова йерархия в една схема; • Представяне на всеки конкретен клас в собствена таблица; • Представяне на всеки клас в собствена таблица.

26. Моделиране на обектните наследявания в РДБ

27. Моделиране на обектните наследявания в РДБ Има три начина за представяне на примерната класова йерархия в релационната база данни . Общият подход за ключовете, който се използва в трите подхода на физическия даннов модел, е наличието на идентификатор на обекта (OID), всеки от които представя атрибута Person.oid. • При стратегията с една таблица атрибутите на наследниците се добавят в общата таблица Person. Тя включва допълнителния Person.TypeCode за кодиране на типа на наследствения обект ( student, professor и др.). • При подхода с отделни таблици се използва първичния ключ на таблиците Student и Professor като вторичен за връзка с таблицата Person чрез нейния първичен ключ PersonOID.

28. Моделиране на обектните наследявания в РДБ

29. Моделиране на обектните наследявания в РДБ

30. Моделиране на обектните наследявания в РДБ Пример за оценка на предимства и недостатъци. • добавя се допълнителен клас TenuredProfessor със собствен атрибут tenureDate от тип Date

31. Моделиране на обектните наследявания в РДБ • При първият начин на представяне към таблицата, моделът се разширява с ново поле на таблицата, например TenureDate и номериране на нов тип; • Вторият начин изисква да се създаде таблица, например TenuredProfessor и полета: • TenuredProfessorOID – идентификатор на обекта; • Name – от Person; • StartDate – Professor; • TenureDate – собствено поле. • Третият начин изисква да се създаде таблица, например TenuredProfessor и полета: • PersonOID – идентификатор на обекта; • TenureDate – собствено поле.

32. Моделиране на отношения (релации) Разлика при моделирането между асоциация и агрегация (композиция) • Ассоциациите и агрегация / композициите нямат съществени различия от гледна точка на моделирането им в даннов модел. Разликата е в силата на връзката между обектите един с друг. При агрегация всичко, което трябва да се прави с цялата база от данни се прави и върху частта и. Това не е така при асоциацията. • В обектните схеми отношенията са имплементирани с комбинация от връзки между обектите и операция, а в релационните бази те се осъществяват с вторичните ключове. Вторичният ключ е даннов атрибут(и), който се записва в една таблица и е записан частично или изцяло в друга таблица. Така се осъществява релация (отношение) между редовете на една таблица с редовете на друга таблица.

33. Моделиране на отношения (релации) Начинът за представяне на релациите зависи от техния мултипликатор: • Отношение едно към едно. За да се представи отношението има две стратегии. Ако всеки клас съответства на отделна таблица, както е показано на фигурата за отношенията между класовете Course и CourseVideo, тогава вторичният ключ трябва да се имплементира в една от двете таблици. В този пример колоната CourseVideo.CourseNumber служи като вторичен ключ към таблицата Course. От даннова гледна точка е безразлично в коя таблица ще се постави вторичния ключ. При еднопосочна асоциация е от значение и вторичен ключ се записва в таблицата, която запазва отношението. Например, ако има еднопосочна асоциация от Person към Address, тогава вторичния ключ трябва да се добави в таблицата Person. Втората стратегия се състои в запис на данните на двата класа в една таблица. Например агрегацията между класовете Course and CourseOverview.

34. Моделиране на отношения (релации)

35. Моделиране на отношения (релации) • Отношение едно към много. Такова отношение е отношението offering of на фиг. 5.4. То се инплементира в класовете чрез колекция, например Hashset в страната с мултипликатор 0..* и чрез една референция на обект в страната с мултипликатор 1. В този случай Course.seminars и Seminar.course, съответно. В релационната база тази релация се имплементира чрез вторичен ключ в страната с мултипликатор 0..* , в случая Seminar.CourseNumber. • Отношение много към много. Отношението се имплементира чрез асоциацитивна таблица в базата данни. Тази таблица съдържа само първичните ключове на двете бизнес таблици. На фигурата такова е отношението instructs между класовете Professor и Seminar и се имплементира с таблицата Instructs в базата данни. С добавяне на асоциативна таблица се преобразува отношението много към много в две асоциации едно към много, които се имплементират по указания в т. 2 начин.

36. Моделиране на отношения (релации) Мултипликаторите на асоциацията в класовата диаграма се кръстосват при нейното представяне във физическия даннов модел по показания на следващата фигура начин. Мултипликаторите 1 се асоциират към данновите еквиваленти (таблиците), съответстващи на двата класа. Релацията указва че професорът обучава по 1 или повече семинари, което определя мултипликатора на релацията към асоциативната таблица instructs – 1..*. Обратната асоциация – всеки семинар се ръководи от 0..* професори, дефинирана в обектния модел, се моделира еквивалентно с релацията от таблицата семинар Seminar към асоциативната таблица Instructs.

37. Моделиране на отношения (релации) Мултипликаторите на асоциацията в класовата диаграма се кръстосват при нейното представяне във физическия даннов модел:

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

39. Моделиране на отношения (релации) Рекурсивните отношения са такива, при които в двете страни на отношението се намира един и същ клас. Например, асоциацията prerequisites на примерната йерархия, представя взаимовръзката от клас Course към себе си, определящо, че всеки изучаван курс изисква предварителното изучаване на други курсове. За моделирането на рекурсивните отношения се използва същият подход, като на нерекурсивните. Асоциацията в примера може да се реализира чрез асоциативна таблица- Prerequisites, която съхранява като ключове кодовете на курсовете и техните предварително изучавани курсове 0..* към 0..*.

40. Стратегии за имплементиране на кода Съществуват три основни подхода, наричани стратегии за капселоване при имплементирането на модела на интерфейса за съхраняване на обектите: • На грубата сила; • Създаване на обекти за достъп до базата данни (DAOs); • Със средствата за създаване на слоя за съхраняване. (Persistence frameworks).

41. Стратегия на грубата сила Бизнес обектите директно се обръщат чрез кода на (SQL) към базата данни. В приложенията на Java това е възможно, посредством интерфейсния протокол ( JDBC). Предимствата на този подход са в бързото написване на малки приложения и/или прототипи. Недостатъците са: • Директното вграждане на схемата на релационната база в бизнес класовете затруднява промените и поддръжката на кода. Проста смяна на поле от таблицата на базата от данни предизвиква цялостна преработка на кода, прекомпилация на всичко и разпространяване на файлове. • Изисква да се пишат части от код на SQL които да се тестват и поддържат.

42. Създаване на обекти за достъп до базата данни (DAOs) При този подход освен бизнес класовете, се създават специализирани даннови класове, заключващи в себе си логиката за достъп до базата от данни посредством съответните методи. Типичният случай е да се създава отделен даннов обект за всеки бизнес обект. Например, класът Student има клас StudentData който имплементира кода на SQL. Тази стратегия е подходяща за прототипи, малки системи (с по-малко от 40 - 50 бизнес класове) или системи, при които при които преходното моделиране е много трудно, например когато се използва съществуваща база данни. Главното предимство на DAOs спрямо директния подход е че бизнес класовете не са пряко зависими от базата данни. Данновите класове са пряко зависими от нея. Необходимо е да се създават (напишат на Java) такива класове или да се използва индустриалния стандарт на Java (JDOs), достъпни на страница http://www.jdocentral.com. Главният недостатък на този подход е препрограмирането на данновите класове при промени в базата данни.

43. Със средствата за създаване на слоя за съхраняване. (Persistence frameworks) Слоят на съхраняването напълно капсулира достъпа до базата данни от бизнес обектите. Вместо да се пише код, се дефинират метаданни, които представят съответствието между бизнес обектите и данновите обекти. На базата на тези метаданни се генерира кода за достъп, който той изисква за съхраняването на бизнес обектите и релациите между тях. Същината на тези средства могат да се видят на страница http://www.ambysoft.com/persistenceLayer.html. Предимството на този подход е че програмистите на приложението не се нуждаят от познания за схемата на релационната база. Дори не е нужно да знаят, че техните обекти се съхраняват в релационна база. Посредством административен инстумент се дефинират връзките между модела на обектите и данновия модел. С това се подобрява общата ефективност на слоя за представяне, защото повечето разработчици на програми не знаят всички подходи, които експертите по бази данни използват при изграждане на слоя за представяне на данни. Главният недостатък е че разработчиците трябва да познават средствата за създаване на слоя за съхранение.