OODBMS Vs. RDBMS 1
Indholdsfortegnelse Hvorfor skal vi bruge objekt orienteret databaser?... 3 OODBMS i erhvervslivet... 4 Bagsiden af medaljen... 5 OODBMS i praksis... 6 Konklusion... 8 2
Hvorfor skal vi bruge objekt orienteret databaser? Siden 1960 s har konceptet om objekt orienteret programmering eksisteret og lige siden da har det vokset, eksponentielt. Og i dag kommer alle sprog i en alle anden form for objekt orienteret sprog. Og alt funger fint, man opretter objekter i nogen collections som man kan hente og ændre som man har lyst til så længe det lever i rammene. Men så start man skal til at gemme sine objekter i databasen så løber vi ind i et problem. Nemlig det faktum at stort set alle databaser på markedet, køre på den relationale model. Som blev introduceret af E. F. Codd i 1970 erne. Denne model brygger på at data gemmes i tabeller, i det som man kalder tubler. Grunden til at RDBMS tog til selvom at idéen bag objekter udkom før, findes i at på netop dette tidspunkt i tiden, så var der mange folk der stadigvæk var modstander af at kode objekt orienteret, og mente at dette ikke var andet end en fase og den ville dø hurtigt igen. Dette som jeg allerede har været inde på viste sig ikke at være tilfældet. Man kan så diskutere hvis E. F. Codd, havde vidst at OOP ville blive så populært som, det er i dag, om han ikke ville have lanceret en OODMBS i stedet for. Men dette var ikke tilfældet, men hvad er problemet så ved at vi kode OOP og gemmer i en RDBMS? Dette er at der er snakke om to helt vidt forskellige datamodeller, og for at kunne gemme objekter i en RDBMS skal man rive objekterne fra hinanden. Og netop til dette formål blev der skabt normaliserings regler, for at tvinge objekter ned i en RDBMS. Problemet med dette er at vi står med meget arbejde for at søger for at din database lever op til mindst 3 normalform, som mange gange betyder at der bliver brugt meget tid på at skabe din database, tid som i stedet kunne bruges på at skabe et beder program. Samt en masse arbejde på at optimer dine SQL sætninger. I større virksomheder har man taget konsekvensen af dette og valgt at skabe teams som kun har med databaser at gøre. Men hvordan bliver dette forskelligt ved at bruge en OODMBS i stedet for? Den store forskel er at du gemmer din objekt moddel direkte som den er, uden at skulle tage stilling til noget, direkte fra dit udviklings miljø, dette betyder at man ikke længer har brug for folk som kun arbejder med databaser, fordi alt dette bliver styret af programmøren i det sprog som han eller hun koder i. Dette betyder at rollen som database administrator ikke længer er nødvendig. 3
OODBMS i erhvervslivet Som nævnt tidligere så er objekt orienteret databaser, stadigvæk et meget lille område dette skyldes at der ikke er nogen af de store spiller på markedet som Microsoft og Oracle som har valgt at byde sig ind på markedet. Hvilket resulter i at erhvervs livet ikke tør at begynde på at bruge OODBMS er. Da der mangler support og dem som alligevel bruger OODBMS er vælger mange gange at udvikle deres egen, som betyder at der aldrig kommer en stor objekt orienteret database. Og derved ikke bliver mainstream, der findes OODMBS er som kan hentes og bruges en af disse er db4o, denne findes i 2 varianter en til privat brug og en til kommerciel brug. Som jeg skrev tidligere så findes der steder i erhvervs livet hvor man benytter OODBMS er disse er for det meste videnskabelige områder så som organisk kemi hvor der er tale om meget store mængder af data og kompliceret objekter. Hvor det simpelthen kræver for meget tid at skille objekterne fra hinanden og samle dem igen. Her har de med stor fordel valgt at gemme objekterne som de er. Google som jo nok er en af verdens største it virksomheder har også vist deres interesser overfor OODBMS, grundet i at mange af deres nye ydelser vil med fordel kunne udnytte sig af den teknologi som OODBMS er bringer på banen. Dette gælder specialet deres nye tjeneste google goggles hvor det er muligt at tage et billede med din mobil og sende det til Googles søges maskine som herefter vil kunne finde ud af hvor du er i verden samt andet info om din location. Her igen er der tale om at det vil give mere mening at sende billedet som et objekt med alle informationerne i stedet for at dele det op i tabeller og sende det bare for at samle det hele på den anden ende igen. Men fremtiden for OODBMS er i erhvervslivet, som det ser ud nu, ser den ikke lys ud. Fordi større virksomheder ikke tør at kaste sig ud i nye teknologier, dog ses der et lys i at Google er begyndt at kigge på eftersom, hvis Google gør det så vil mange mindre virksomheder hurtigt følge med. Og det kunne derfor tænkes at tendenserne spreder sig. Og Microsoft eller Oracle herefter følger at det måske ville være interessent at lave en OODBMS. 4
Bagsiden af medaljen Jamen hvis jeg sidder og kode et objekt orienteret system, så kan jeg da ikke se nogen negativ side ved at bruge OODBMS, det er dejligt nemt, hurtigt og ikke mindst så slipper jeg for at bruge alt min tid på at normaliser min database så den passer til min objekter. Desværre så er den ikke så simpelt, fordi som programmerings verden er nu. Så er et objekt ikke bare et objekt, alle OO sprog har deres egen måde hvorpå at de definer at et objekt skal se ud. Dette skyldes ikke mindst at framework baseret sprog er blevet så populære. Herunder er de to største.net som er udviklet af Microsoft og Suns / Oracles Java sprog. Disse to frameworks er dybt uenig i hvordan et objekt skal se ud. Og de er begge to så store at de ikke mener at det er dem som skal give sig. Endnu et problem er også web som har på det sidste har fået meget vind i sejlene takket være Cloud computing. Mange web sprog er ikke OO, det skal dog siges at også web har set lyset i OOP og fra php6 så vil php være 100% OO og det samme gælder asp efter de introduceret asp.net. men her igen så er et php objekt og et asp.net objekt langt fra ens. Problemet med at Objekter ikke er ens er ikke når man skal gemme dem, fordi det er jo ikke andet end at lave et plug in i til java og.net. og så længe at alle programmer som tilgår dette objekt er skrevet i det samme sprog så er der heller ikke nogen problemer i at trække dem ud igen. Men hvis det ene program er skrevet i Java og det andet i.net så kan du ikke læse de samme objekter ind i din OO model. Uden der skal konverteres, der er blevet lagt en standart af hvordan et objekt skal se ud, men ligesom med alle andre standarter indenfor IT så er der ikke nogen der gider at overholde den, fordi de alle sammen mener at deres måde at gøre det på er den rigtige. Så fordi de store magter i IT verden ikke kan blive enig, så er det igen os som udvikler som må betale prisen, og som derved gør det svært for os at bruge en OODMBS uden at vi også skal fast lægge os på et sprog til alle vores systemer. 5
OODBMS i praksis Nu kommer det sjove som i forhold til RDBMS er netop er sjovt. Hvordan bruger man en OODBMS i praksis, i dette tilfælde vil jeg benytte mig af OODBMS en som er blevet udviklet af Versant som hedder db4o, denne kommer i 2 variationer en til Java og en til.net. Jeg vil tage udgangspunkt den version til.net og programmerings sproget C#. Efter man har installeret db4o på sin computer, som er nemt eftersom den kommer som en installations pakke hvor man bare klikker næste hele vejen igennem. Herefter starter man Visual studio op hvor efter man skaber en solution og programmer sit program som man normalt ville gøre her har jeg valgt at lave et meget simpelt program, hvor man opretter en person og gemmer den. Det er vigtiget at man husker at tilføje de rigtige assembly refrences, og herefter tilføjer disse using sætninger i toppen. using Db4objects.Db4o; using Db4objects.Db4o.Query; using Db4objects.Db4o.Linq; Herefter skaber / forbinder med sin database som gøres på følgende måde: // Opretter forbindelsen til databasen, hvis den ikke eksiter skaber den en db = Db4oFactory.OpenFile("DB4Ofile.yap"); Og så er din database skabt, den gemmer I en fil type som hedder.yap dette er en fil type som Versant selv har valgt at opfinde. Men hvad er en database uden der er noget data i den, så herunder vises hvordan d gemmer til din database: try { Pilot pilot1 = new Pilot("Kaj Jensen", 20); //Store gemmer objekt som det er db.store(pilot1); Pilot pilot2 = new Pilot("Bo Hansen", 30); db.store(pilot2); S newstring = new S("Hello"); db.store(newstring); } finally { //Lukker forbindelse til databasen db.close(); } Største delen af denne kode er ganske almen C# kode faktisk det eneste kode som bruges her til at gemme dit objekt er db.store(). Og det er det du har nu gemt dit objekt. Og herefter bruger du db.close() som lukker forbindelsen af databasen. Hvis du sammen ligner dette med alt det som du skal gå igennem med 6
din RDBMS, så er det ikke svært at forstå hvorfor programmør som prøver at bruge en OODBMS. Falder for hvor simple den er at bruge. Hvad hvis man nu gerne vil have sit objekt igen? Så gør du det på denne måde. // Opretter forbindelsen til databasen, hvis den ikke eksiter skaber den en db = Db4oFactory.OpenFile("DB4Ofile.yap"); try { //LINQ sætning til at qurrey database var resultlinq = from Pilot p in db where p.name.startswith("bo") select new { p.name, p.points }; } finally { //Lukker forbindelse til databasen db.close(); } Igen så er mest af dette C# kode, her bruges LINQ til at query din database. Dette er kun en måde at gøre dette på, man kan også bruger ganske almen løkker til dette. Jeg fortrækker dog helt klart LINQ eftersom fra mit synes punkt er LINQ nok en af de smarteste ting som Microsoft har udviklet til.net. Grund til dette er at hvis du kigger på opbygningen af LINQ så minder den rigtig meget om SQL. LINQ blev indført i.net 3.5 som en standart måde at query alt inde i.net frameworket. Det kan bruges til at query både collections samt almen RDBMS er og som kan ses herover også OODBMS er. 7
Konklusion Ud fra mit arbejde med OODBMS samt den teori som jeg har læst, så kan jeg konkluder følgende ting. Hele idéen bag at gemme data i en RDBMS når man koder i et OO sprog har altid været mig en gåde. Og i mange tilfælde har jeg valgt enten at serializer objekter ned i en bin fil eller gemme dem i et xml dokument. Bare for at slippe for at skulle tage stilling til alle de problemstillinger som RDBMS er stiller. Men efter jeg fandt db4o er der ingen tvivl om hvilken database jeg vil bruge. Så længe der er tale om et program som jeg selv skriver fra bunden af og er sikker på at kun køre i C#, så snart vi snakker om støre systemer som køre på flere platforme samt mange forskellige programmerings sprog så er der stadigvæk ikke nogen vej uden om RDBMS er endnu. Men jeg tro på at det nok skal komme, fordi OODBMS er en drøm for OO udviklere. Det spare dig ufatteligt meget tid. Og du behøver ikke at læse tykke bøger om hvordan du skal binde ting sammen og query optimer diverse ting. Men du kan fokuser på det som de fleste programmører synes er sjovt nemlig at programmer. Jeg tro aldrig at RDBMS er kommer til at dø men jeg tro at de for en ny spiller på banen som de nok bliver nød til at tage seriøs. Men det kommer nok til at tage et stykke tid, fordi mange folk er konservative i IT verden og holder fast på gamle teknologier. Og vil gøre alt for at slippe for at lave noget om. Hvis OODBMS er rigtigt skal slå igennem så skal der være mere fokus på dem under uddannelsen af programmører. Fordi der er stadigvæk mange som ikke ved at der er en alternativ til den go gamle RDBMS. 8