Sammenligning af Objekt-orienteret databaser og Relationelle databaser.

Sammenligning af Objekt-orienteret databaser og Relationelle databaser. Af Louis Fleron

Databaser OODBMS og RDBMS PBS10101 Louis Fleron Side 2 Af 11 Indholdsfortegnelse 1. Forord....3 2. Hvad er et OODBMS?...3 2.1. Hvorfor vælge OODBMS i stedet for RDBMS?...4 2.1.1. Alternativ til OODBMS ORM...5 2.2. Strukturen bag et OODBMS...5 3. Historien/kronologien af OODBMS...7 4. OQL...8 4.1. Ligheder og forskelle mellem OQL og SQL...8 4.2 Native Queries...9 5. Query Optimization i RDBMS...9 5.1. Hvad er Query Optimization...9 5.2. Eksempel...9 6. Query Optimization i OODBMS....10 6.2. Hvorfor forskes der indenfor Query Optimization til OODBMS?...10 7. Kilder...11

Databaser OODBMS og RDBMS PBS10101 Louis Fleron Side 3 Af 11 1. Forord. I denne opgave vil jeg sammenligne Objekt-orienteret databaser med relationelle databaser. I mange år har relationelle databaser været den dominerende teknologi indenfor databaser, der findes dog mange alternativer til Relational Database Management Systems (RDBMS). En af disse alternativer er Object Oriented Database Management Systems (OODBMS), men denne teknologi har endnu ikke været i stand til at fjerne RDBMS som den dominerende tankegang indenfor databaser. Det objekt-orienteret paradigme begyndte tilbage i 1960'erne og siden 1990'erne har objektorienteret programmering været det dominerende paradigme indenfor programmering, jeg vil undersøge hvorfor OODBMS teknologien ikke har overlevet denne fremgang. 2. Hvad er et OODBMS? Akronymet OODBMS står for Object Oriented Database Management System, hvilket betyder et database management system der behandler information som objekter. Dette giver en perfekt afspejling af den model som skabes i objekt-orienteret programmering, denne model er baseret på associationer mellem objekter. Denne måde på at gemme informationer står i kontrast til relationelle database systemer som benytter en relationel model som grundlag for opbevaring. Den relationelle model er baseret på matematisk logik, mere præcist Første-Ordens logik også kendt som mængdelære. Listen over Objekt-orienteret database management systemer er lang, men de mest kendte er: 1. Oracle 2. ObjectStore 3. PostgreSQL 4. DB4O 5. JADE Oracle og PostgreSQL er hybrid systemer, ORDBMS, som både håndterer den relationelle model og den objekt-orienteret model. JADE er en platform som indeholder sit eget programmeringssprog og objekt-orienteret database system, men JADE indeholder en API som tillader.net og Java brug af det objekt-orienteret database system. ObjectStore og DB4O er rene objekt-orienteret database systemer. Vi har arbejdet med DB4O i timerne og jeg må tilstå at objekt-orienteret database systemer gør persistens af data utroligt nemt.

Databaser OODBMS og RDBMS PBS10101 Louis Fleron Side 4 Af 11 Følgende eksempel på at gemme et objekt (DB4O). //Gem et objekt af type ObjectX ObjectX x = new ObjectX(); x.age = 27; x.name = "Dette er et navn"; db.store(x); Eksempel på at hente objekter fra databasen (DB4O). //Hent alle objekter med type ObjectX ObjectX y = new ObjectX(); IObjectSet result = db.querybyexample(y); foreach (ObjectX o in result) { Console.WriteLine(o.ToString()); } Der er ikke brug for at lave en database i et andet program, eller lave tabeller samt relationer mellem tabellerne. Alt foregår i det valgte objekt-orienteret sprog, hvilket gør håndtering af databaser utroligt nemt og flydende. 2.1. Hvorfor vælge OODBMS i stedet for RDBMS? Hvis et system udvikles i et Objekt Orienteret miljø og systemet kræver høj ydeevne samt indeholder komplekse data, så kan der med fordel benyttes et OODBMS i stedet for en traditionel Relationel database. Komplekse data kendetegnes ved brug af Inheritance, Polymorphism, Cross-referencing mellem mange objekter. Disse egenskaber gør oversættelsen fra et objekt-orienteret miljø til en relationel model, besværlig og tidskrævende. Sandsynligheden for mulige fejl i databasen stiger. Cross-references oversættes til Foreign Keys i en relationel model, problemet opstår når et objekt refererer til et andet objekt som igen refererer til andre objekter. Der skal skrives en relativ kompleks forespørgsel for at udtrække disse objekter i en Relationel model. En anden grund til at benytte en OODBMS, opstår når objekterne indeholder Kollektioner, disse kollektioner kendetegner en klassisk En til Mange relation. Denne relation vil typisk blive oversat til en ny tabel i den relationelle model. Der er også problemer tilknyttet OODBMS, såsom manglende standarder til håndtering af objekter og manglende vilje fra mange firmaer til at foretage datamigration fra et allerede kørende relationelt miljø til et nyt Objekt-orienteret miljø.

Databaser OODBMS og RDBMS PBS10101 Louis Fleron Side 5 Af 11 2.1.1. Alternativ til OODBMS ORM Som et alternativ til en total migration fra RDBMS til OODBMS, er det muligt at benytte en ORM, hvilket står for Object Relations Mapping(Mapper). ORM er et lag mellem et system skrevet i et objekt-orienteret miljø og den relationelle database. Laget har til opgave at oversætte objekterne i systemet til relationer i databasen. ORM er en måde på at samle alle problemstillinger nævnt i det forrige afsnit i et modul, dette modul håndterer derefter kommunikation mellem de to modeller. Der findes mange eksisterende ORM'er på markedet, for at nævne de mest kendte indenfor.net. Nhibernate ibatis ADO.Net Entity Framework (Del af.net 4.0) 2.2. Strukturen bag et OODBMS. Nu har vi set eksempler på brugen af et Objekt-orienteret database system, men jeg vil nu undersøge hvordan databasen håndterer selve objekterne. I det Objekt-Orienteret Database System Manifest, beskrives krav til hvad en OODBMS skal kunne, de mest kendte krav er: Komplekse objekter. Object Identifier (OID). En unik identifikation af objektet som er uafhængighed af attributter. Indkapsling(Encapsulation). Typer eller klasser. Nedarvning(Inheritance). Dynamisk binding. Traditionelle DBMS'er har en model bestående af to lag: Application Storage model i hukommelsen som består af data der skal bruges i en applikation. Database Storage model på disk som består af relationer og tupler. OODBMS giver illusionen af en model som består af et lag, dette opnås ved at bruge Object Identifier. Der findes to typer af OIDs. Logical OID: Uafhængig af den fysiske placering af objektet på disken. Physical OID: Placering er en del af OID. Begge typer er forskellige i størrelsen sammenlignet med normale memory-pointers og det er nødvendigt at konvertere mellem OID og pointers i hukommelsen. Til at gøre dette, bruges Pointer- Swizzling.

Databaser OODBMS og RDBMS PBS10101 Louis Fleron Side 6 Af 11 Der findes tre typer for Pointer-Swizzling 1. Copy versus in-place. Beslutning om data skal kopieres ind i applikationens lokale cache eller om data skal tilgås fra object managerens page cache. 2. Eager versus lazy. Eager betyder at alle objekter som applikationen bruger, skal 'swizzles' fra disk til hukommelsen, før applikationen kan bruge objekter. Lazy er det modsatte, kun de objekter som skal bruges hentes ind i hukommelsen. 3. Direct versus indirect. Direct betyder at Swizzling-pointeren peger på et objekt udenfor hukommelsen, hvor indirect betyder at der oprettes et temporært objekt i hukommelsen som indeholder adressen til objektet. Disse tre typer for Pointer-Swizzling kan kombineres på otte forskellige måder. Når OODBMS skal hente et objekt fra disk til hukommelsen, sker følgende. OODBMS bestemmer hvilken side på disk som indeholder objektet. OODBMS udfører Pointer-Swizzling, modifikation af objekt så det passer til programmeringssproget. Eksempelvis.Net objekter til Java objekter. Applikationen kan nu tilgå objektet. På grund af Pointer-Swizzling mellem memory-pointers og OID, opnår OODBMS illusionen af et simpelt enkeltlags system. Det er også muligt at undlade brugen af swizzling og benytte en tabel til holde styr på objekter i hukommelsen. Dette kaldes Resident Object Table (ROT) og indeholder OID af objektet og hukommelsesadressen. Denne metode kan give problemer med performance hvis et objekt skal bruges mange gange. Hver gang skal der fortages en forespørgsel i ROT, dette tager tid og dermed forringes performance. Når et objekt bliver persistent er det normalt OID og objektets tilstand som gemmes, men det er også muligt at inddrage kildekode og program/thread execution state. Dette giver en mere elegant løsning som omfatter alle aspekter af objektet. Persistens af kildekode vil dog føre til redundans, da kildekoden allerede findes i filsystemet. Der er tre forskellige persistens måder. Checkpointing: Hele programmet kopieres til sekundær disk. Dette kaldes for et checkpoint. Det er dog kun programmet som kan benytte dette checkpoint og det kan indeholde store mængder data som ikke skal bruges. Serialization: med Serialization gøres alle objekter som kan tilgås fra et startobjekt flade og deres data samt struktur skrives til sekundær disk. Der er et problem med denne måde, den er ikke inkrementel. Hvis der fortages små ændringer skal hele strukturen igennem den samme proces igen. Dette er ikke effektivt.

Databaser OODBMS og RDBMS PBS10101 Louis Fleron Side 7 Af 11 Explicit paging: Her er det applikationsprogrammøren som står for persistens af objekter. Denne metode gør brug af konverteringen mellem disk baseret og hukommelse pointers, Pointer Swizzling. Der er to metoder, Reachability-based og Allocation-based. Reachability-based persistens betyder at et objekt bliver gjort persistent hvis objektet kan nås fra et rod objekt. Denne metode passer godt sammen med Java og C# som indeholder garbage collection. Allocation-based persistens betyder at et objekt kun bliver gjort persistent hvis objektet er erklæret persistent fra applikationen. Her er der to måder, By Class betyder at en klasse erklæres for at værende persistens og alle instanser af denne klasse bliver gjort persistente ved oprettelse. Den anden måde er By explicit call, her er det programmøren som kalder en funktion der udfører den nødvendige persistens. 3. Historien/kronologien af OODBMS. Dette er en kort gennemgang af de vigtigste punkter indenfor udviklingen af OODBMS, såsom hvornår kom det første OODBMS frem og hvad er der sket siden. I løbet af 1980'erne samtidigt med fremgangen af objekt-orienteret programmering, begyndte programmører at behandle data i databasen som sammenhængende entiteter. Objekt-orienteret programmering havde ændret hvorpå data blev opfattet, fra en ren data model til en associativ model. Følgende tidslinje viser udviklingen. Tidlig 1980'erne - Won Kim begynder et forskningsprojekt vedrørende objekt-orienteret databaser. Navnet er ORION. To databaser systemer benytter ORION som grundlag, ITASCA og Versant. Sen 1980'erne - Lisp-baseret database system, Graphael dukker op. Senere bliver Graphael omskrevet til Matisse. Servo-Logic begynder på Gemstone database systemet. 1990s Vækst Markedet for OODBMS produkter vokser op til 100 millioner $. 1991 - Object Data Management Group. Rick Cattell grundlægger ODMG sammen med fem store OODBMS producenter. Den første standard ODMG 1.0 frigives i 1993. 1995 - OODBMS Manifestet Malcolm Atkinson skriver manifestet som definerer hvad OODBMS skal indeholde. 2001 - ODMG 3.0 standarden frigives. ODMG går i opløsning, arbejdet fortsættes i Java som JDO, Java Data Objects. 2004 Open Source. DB4O frigives som en gratis og open source OODBMS. DB4O er den første til at implementere Native Queries som helt afhænger af programmeringssproget.

Databaser OODBMS og RDBMS PBS10101 Louis Fleron Side 8 Af 11 4. OQL Object Query Language var det første forsøg fra ODMG på at lave en standard indenfor data forespørgsel. ODMG valgte at benytte SQL syntaksen som grundlag for OQL og derfor ligner de hinanden, jeg viser et eksempel på denne lighed. OQL blev aldrig overholdt af producenterne og i dag findes der andre sprog og metoder som tager udgangspunkt i OQL. 4.1. Ligheder og forskelle mellem OQL og SQL. Følgende eksempel viser OQL og SQL. SELECT DISTINCT x.attribut FROM (tabel eller objekt) x WHERE x.attribut2 = Betingelse Dette eksempel virker i både OQL og SQL. Forskellen er hvad de leverer tilbage. SQL leverer en tabel med alle tupler som overholder betingelsen, hvor OQL leverer en kollektion med alle objekter som overholder den samme betingelse. Der er et problem med OQL, moderne integrated development environments, tjekker ikke strings for syntaks eller semantiske fejl. Hvis vi har forespørgsel i OQL som skal finde alle studerende som har en alder der er mindre end 20 i en database, følgende kode er nødvendigt. String oql = "select * from student in AllStudents where student.age < 20"; OQLQuery query = new OQLQuery(oql); Object students = query.execute(); Dette eksempel kræver at både student.age og 20 er numeriske, der vil opstå en fejl hvis student.age ændres til noget andet. Refactoring af kode giver et andet problem, hvis age ændres til _age, så virker vores query ikke mere. Til at løse vores problemer, så er det muligt at skrive vores queries i selve programmeringssproget og dermed bruge vores IDE til at sikre korrekte typer. Dette er Native Queries.

Databaser OODBMS og RDBMS PBS10101 Louis Fleron Side 9 Af 11 4.2 Native Queries Følgende eksempel er fra DB4O og skrevet i C#. IList <Student> students = database.query <Student> ( delegate(student student){ return student.age < 20 && student.name.contains("f"); }); I stedet for at benytte strings, så bruges en delegate som indeholder betingelsen. OODBMS'et, i dette tilfælde DB4O, tager Native Query og oversætter den til SODA. SODA står for Simple Object Data Access og er DB4Os low level sprog. 5. Query Optimization i RDBMS. 5.1. Hvad er Query Optimization. Den relationelle model er baseret på mængdelære og når en person ønsker at udtrække data fra modellen, kan der være mange forskellige måder på at gøre dette. Det kræver mange udregninger for at identificere en effektiv måde på at udføre brugerens forespørgsel, heldigvis indeholder RDBMS'er en komponent som løser vores problem. Query Optimizer er en komponent som håndterer beregninger og estimater af vores forespørgsel. Komponenten tager forespørgsler fra brugeren, som normalt er skrevet i SQL eller T-SQL(MS-SQL) og prøver at optimere denne forespørgsel ved at erstatte de tunge dele i forespørgselen med hurtigere dele. Der skabes flere cost plans som viser hvor meget det koster i tid at udføre brugerens forespørgsel, den billigste plan vælges og udføres. En normal bruger benytter ikke Query Optimizer, direkte, men det er muligt at angive små hints til DBMS'et som påvirker optimeringen. 5.2. Eksempel. Som et eksempel på brug af Query Optimizer hints, har jeg valgt at vise hvordan en bruger kan påvirke en af de mest brugte operationer i en RDBMS, Join operationen. Join operationen gør det muligt at hente data fra flere tabeller i samme forespørgsel, hvis tabellerne har data tilfælles. SELECT column_name(s) FROM table_name1 JOIN table_name2 ON table_name1.column_name=table_name2.column_name

Databaser OODBMS og RDBMS PBS10101 Louis Fleron Side 10 Af 11 Query Optimizer vil nu forsøge at beregne den bedste plan, ved at undersøge tabellerne og antallet af tupler. Resultatet er en Execution plan som benytter den bedste JOIN mulighed mellem tabellerne. Det er muligt at tvinge Query Optimizer til at benytte en bestemt form for JOIN ved at benytte OPTION ( LOOP JOIN ) Dette tvinger Optimizeren til at udfører alle JOINs som LOOP-JOINs. Der findes også MERGE-JOINs og HASH-JOINs som udfører operationen på forskellige måder, dette påvirker CPU-tid og I/O operationer af hele vores forespørgsel. Det er sjældent nødvendigt at bruge Query Optimizer hints ved normal brug af en RDBMS, men det kan forekomme at der skabes en ineffektiv Execution plan og det er derfor nødvendigt at tvinge en bestemt fremgangsmåde. 6. Query Optimization i OODBMS. I OODBMS findes denne Query Optimizer ikke, da der ikke er behov for andet end Hent og Gem objekter. Der er ikke behov for at udføre JOINs mellem objekter, da det bryder med en af hovedprincipperne i objekt-orienteret tankegang, Encapsulation. Objekter indeholder referencer til andre objekter og dermed er brugen af JOINs unødvendig. Alligevel forskes der indenfor Query Optimization i OODBMS. 6.2. Hvorfor forskes der indenfor Query Optimization til OODBMS? Der forskes indenfor Query Optimizer til OODBMS, da meget komplekse datastrukturer kræver meget IO eller plads i hukommelsen, især hvis der bruges en Pointer-Swizzling strategi som omfatter Copy/Eager/Indirect. Eksempel på problemet kan være: Objekt R indlæses, men objekt R indeholder tre kollektioner af typerne X,Y,Z. Disse objekter skal også indlæses, hvis X indeholder andre kollektioner, så skal de også indlæses. Samt alle objekter skal kopieres ind i applikationens lokale cache. Dette giver en del I/O arbejde og pladskompleksiteten er meget høj, især hvis det kun er det første objekt i X-kollektionen som skal bruges. Lazy Pointer-Swizzling løser dette problem, men giver os et andet problem. Hver gang et nyt objekt skal bruges så skal OODBMS undersøge om objektet findes i hukommelsen eller om det findes på disk. Så i stedet for at indlæse alle objekter fra harddisk, så ville det være mere optimalt at have en objekt-orienteret algebra som beregner hvilke objekter som skal bruges. Den relationelle model er baseret på mængdelære hvor der er meget veldefineret matematiske regler som bruges til udregning af den bedste måde på at udføre en forespørgsel, men i den objekt-orienteret verden mangler vi en objekt-orienteret algebra som kan udføre dette arbejde.

Databaser OODBMS og RDBMS PBS10101 Louis Fleron Side 11 Af 11 Når vi snakker om objekter så nævnes attributter og typer, men vi glemmer helt at et objekt indeholder metoder. En mulig Objekt-orienteret Query Optimizer er baseret på Metode semantik. Forskning indenfor metode-semantik baseret optimering har ført til et nyt sprog som kaldes VQL, eller VODAK Query Language. I stedet for at bruge attributter i en forespørgsel, så er det muligt at benytte metoder som indeholder langt flere informationer vedrørende hvordan objektet kommer til at opfører sig. Optimering sker på grundlag af metodens omkostninger, hvilket kan være CPU eller I/O i form af kald til andre objekter. Dette eksempel er bare et af flere forskellige forsøg på at implementere Query Optimization i OODBMS. Desværre har den langsomme udvikling og accept af OODBMS, medført at forskningen sker langsomt eller helt droppes. 7. Kilder Database Systems, A Practical Approach to Design, Implementation, and Management Thomas Connolly og Carolyn Begg. Fourth Edition. Kapitel 26 og 27. Dissecting SQL Server Execution Plans Grant Fritchey. Kapitel 5, Controlling Execution Plans with Hints. 215-OODB Dokument vedrørende OQL og SQL. P1995-28 Semantic Query Optimization for Methods in Object-Oriented Database Systems V11-12 - Contribution to the Query Optimization in the Object-Oriented Databases http://www.odbms.org/introduction/history.aspx - Kronologi af OODBMS.