ODWZOROWANIE OBIEKTOWO-RELACYJNE

PODSTAWY BAZ DANYCH Mateusz Wojtaszek Agnieszka Walczak Kamil Lisiecki

Co to jest ORM? ORM to skrótowe oznaczenie dla

"mapowanie obiektowo-relacyjne" (od angielskiego Object-Relational Mapping). Chodzi więc o zamianę danych w postaci tabelarycznej (relacji w bazie danych) na obiekty, albo w drugą stronę. Jest nowoczesnym podejściem do zagadnienia współpracy z bazą danych, wykorzystującym filozofię programowania obiektowego.

Skąd ten pomysł?

Idea ORM zaczęła się wykluwać w czasach euforii z powodu upowszechnienia programowania obiektowego. Wizjonerzy informatyki wierzyli, że przyszłość będzie należała do obiektowych baz danych. Czyli dane pamiętane w obiektach programu byłyby w takiej samej formie zapisywane w bazie danych, bez dodatkowych operacji zmieniających format z obiektowego na relacyjny i z powrotem.

Krótki rys historyczny

1996 - pierwsze narzędzia do mapowania ORM dla Javy - TopLink,

1999 - powstaje J2EE - standard tworzenia wielowarstwowych aplikacji komponentowych. W jego skład wchdzi standard Enterprise Java Beans (1.1). Standard J2EE jest skomplikowany, miescami mało czytelny, a do tego wymaga kosztownych serwerów aplikacji (aczkolwiek z czasem pokazują się darmowe). J2EE znajduje zastodowanie w dużych aplikacjach korporacyjnych,

2001-2002 - pojawia się szereg bibliotek i narzedzi dla Javy, mających być substytutem różnych funkcjnalności J2EE. W dziedzinie mapowania obiektowo-relacyjnego powstają narzędzia takie jak Hibernate, TopLink(zostaje przejęty przez Oracla), iBatis. Największą popularność zdobywa Hibernate. Rozwiązania ORM trafiają do małych i średnich systemów.

Krótki rys historyczny cd.

2006 - opublikowanie standardu Java EE 5, kolejnej wersji J2EE. Java EE 5 jest znacznie uproszczona w stosunku do dawnego J2EE, w jej skład wchodzi definicja standardu JPA - standardu definiowania mapowania obiektowo-relacyjnego i korzystania z trwałych obiektów. JPA jest dużo prostrze od EJB 1.1, między innymi dzięki temu, że twórcy zaczerpnęli bardzo dużo pomysłów i narzędzi takich jak Hibernate.

2006 - powstaje Hibernate EntityManager, implementacja JPA oparta o dotychczasowego Hibernate. Pozostali twórcy narzedzi ORM również dostosowują się do nowego standardu.

Elementy technologii ORM

1. API (Application Programming Interface, czyli Interfejs programowania aplikacji) do zarządzania trwałością obiektów

2. Mechanizm specyfikowania metadanych opisujących odwzorowanie klas na relacje w bazach danych

3. Język lub API do wykonywania zapytań.

Najpopularniejsze implementacje technologii odwzorowania obiektowo-relacyjnego dla

aplikacji Java to Hibernate (rozwiązanie Open Source firmy JBoss) i Oracle Toplink.

(rozwiązanie firmowe firmy Oracle). Mniejszą popularność zyskała technologia JDO

(firmy Sun).

Dlaczego mapowanie OBIEKTOWE? Koncepcja programowania obiektowego i

projektowania systemów informatycznych w oparciu o paradygmat obiektowości okrzepła, ustabilizowała się i jest obecnie standardem. Dysponujemy dobrymi narzędziami do wspomagania projektowania (np. Rational Rose czy też Enterprise Architect), mamy dojrzałe obiektowe języki programowania (Java, C#). Możliwe jest płynne przejście od biznesowych założeń, przez specyfikację wymagań, projekt techniczny do gotowego programu.

Czy na pewno?

ODP: NIE Dlaczego? Niestety, jak dotąd nie powstała powszechnie

akceptowana koncepcja obiektowej bazy danych. Pojawiły się oczywiście różne koncepcje obiektowych baz danych :

1. repozytoria XML (cała baza to jeden/wiele dokumentów XML);

2. do języków typu Java czy C# pozwalające na przechowywanie zserializowanych obiektów, (Serializacja – w programowaniu komputerów proces przekształcania obiektów, tj. instancji określonych klas, do postaci szeregowej, czyli w strumień bajtów, z zachowaniem aktualnego stanu obiektu),

Jak wygląda praktyka?

W praktyce wszyscy korzystają nadal z relacyjnych baz danych, gdyż systemy zarządzania relacyjnymi bazami danych są szybkie, stabilne i bezpieczne. Poważnym problemem jest przełożenie logicznej obiektowej struktury systemu na relacyjną bazę danych, podobnie nie jest oczywiste korzystanie z takiej bazy danych w obiektowej aplikacji

Ogólny przykład:

Przykładowo, aby zmienić hasło użytkownika w bazi danych użytkowników musimy wykonać poniższą operację :

public void changePassword(User u, String newPassword)

{

con.prepareStatement("UPDATE tab_users SET password = ?

WHERE login = ?").

setString(1, u.getPassword()).

setString(2, u.getLogin()).execute();

}

Ogólny przykład cd.

Podczas gdy my, chcielibyśmy, aby taka operacja wyglądała następująco:

public void changePassword(User u, String newPassword)

{

u.setPassword(newPassword);

}

a więc bez konieczności "grzebania" w relacyjnej bazie danych. Tutaj wkracza mapowanie obiektowo-relacyjne.

Konkretny przykład: HIBERNATE (Java) Najpopularniejsza implementacja

odwzorowania obiektowo-relacyjnego dla języka Java CECHY:

Wysoka wydajność i skalowalność Wiele sposobów wydawania zapytań Wykorzystuje siłę technologii relacyjnych baz

danych Obecnie jedna z implementacji standardu Java

Persistance

Hibernate- garść informacji

Hibernate to najpopularniejsza implementacja odwzorowania obiektowo-relacyjnego dla języka Java. Założeniem jego twórców było zaoferowanie rozwiązania określanego po angielsku jako „Relational Presistance for Idiomatic Java”, co oznacza zapewnienie trwałości obiektów ze wsparciem dla wszystkich mechanizmów obiektowych języka Java, takich jak obsługa: asocjacji, kompozycji, dziedziczenia, polimorfizmu i kolekcji.

Hibernate jest rozwiązaniem kategorii Professional Open Source. Z jednej strony jego źródlą są dostępne, a z drugiej jest on rozwijany przez firmę JBoss, będącą znaczącym graczem na rynku serwerów aplikacji.

Konkretny przykład: LINQ (C#)

część technologii Microsoft .NET, która została opracowana przez Andersa Hejlsberga – znanego z zaprojektowania języka C# i Delphi.

LINQ jest jedną z najpopularniejszych implementacji odwzorowania obiektowo-relacyjnego dla języka C#

LINQ- garść informacji

LINQ stanowi warstwę abstrakcji nad różnymi źródłami danych. Baza danych i jej elementy traktowane są również jak obiekty. Przestrzenie, które obsługuje LINQ, to:

obiekty implementujące interfejs IEnumerable<T>

bazy danych

język XML

LINQ posiada pełne wsparcie dla transakcji, widoków oraz procedur przechowanych. Zapytania stają się częścią języka .NET wspierającego .NET 3.5 (C#, Visual Basic, Delphi Prism itd.). Jeśli LINQ ma działać, musi znać mapę całej bazy danych. Zapytanie LINQ zwraca kolekcję z przestrzeni nazw typów ogólnych. Kolekcja ta może być modyfikowana, a następnie zwrócona do źródła. Dzięki temu zachowywana jest pełna kontrola typów danych i ich konwersji w poszczególnych mechanizmach pośredniczących w pobieraniu danych.

Podsumowując możliwości ORM

Ogółem mówiąc, dzięki ORM możemy:

zdefiniować odwzorowanie zawartości relacyjnej bazy danych na obiekty w używanym przez nas języku programowania,

wykonywać operacje na danych w bazie danych tak jak na zwykłych obiektach języka programowania.

PRACA Z ORM: Kroki postępowania cz.1 1. Tworzymy model danych w obiektowym

języku programowania.

2. Tworzymy schemat bazy danych odpowiadający temu modelowi (może się oczywiście okazać, że już mamy jakąś bazę danych, z którą musimy współpracować).

3. Definiujemy odwzorowanie bazy danych na model relacyjny.

PRACA Z ORM: Kroki postępowania cz.2 4. Tworzymy aplikację obiektową operującą na

modelu obiektowym (tworząc kod aplikacji w zasadzie nie musimy się zastanawiać nak nasze obiekty zostaną zapisane).

5. W razie konieczności pobrania obiektów z bazy danych, bądź utrwalenia jakiegoś nowo utworzonego obiektu, czy też usunięcia utrwalonego obiektu - posługujemy się odpowiednim API danego narzędzia ORM. To jest jedyne miejsce, w którym w naszej aplikacji przejmujemy się tym, że współpracujemy z jakąś bazą danych.

Zalety ORM cz.1 I ty zostaniesz programistą Największą zaletą ORM jest niebywała prostota

użytkowania.

Ponadto, informatycy to ludzie zazwyczaj dość inteligentni. Czemu więc próbowano w miejsce tradycyjnych, sprawdzonych rozwiązań (Tradycyjne Bazy) wprowadzić coś całkowicie odmiennego? Kolejną zaletą jest to, że pomysł był intelektualnie atrakcyjny i łatwo można było przekonać dysponentów kapitału, że warto w niego pakować miliony. A drugą - że można było wykazać ekonomiczną opłacalność takiej inwestycji.

Zalety ORM cz.2 Żeby to zrozumieć, musimy wiedzieć na co firmy wydają

pieniądze w ramach informatyzacji.

Obrazuje to doskonale stary rysunek

Zalety ORM cz.3

Ilość pośredników między klientem a programistą sprawia, że klient dostaje produkt drogi i niedostosowany do jego potrzeb. Dzięki obiektowym bazom danych pozbywamy się co najmniej jednego pośrednika: programisty baz danych.

Na dodatek analityk, który potrafi opisać rzeczywistość w postaci obiektów uzyskuje wgląd i kontrolę nad całym procesem produkcji. Opisany przez niego obiekt pojawia się w całym procesie tworzenia oprogramowania: od projektu po bazę danych

Tabelki trzymają się mocno Pomimo, że programowanie obiektowe zdominowało przemysł

software’owy, w bazach danych królują nadal tradycyjne rozwiązania. Dlaczego? Bo są dobre i sprawdzone w milionach wdrożeń. Firmie Microsoft udało się przekonać ludzi, że potrzebują co raz to nowego systemu na swoje PC-ty, bo to wbrew pozorom nie są to duże koszty. Zmiana bazy danych często powoduje konieczność głębokiej przebudowy systemu i generuje olbrzymie koszty. Jeśli już więc chcemy wdrażać model obiektowy, to zdecydowanie lepiej zacząć od nowych aplikacji.

A ponieważ te aplikacje muszą często czerpać dane z "przestarzałych" baz - pojawia się pole do popisu dla ORM. „Odpuszczono” więc same bazy danych, ale postanowiono je „opakować” obiektami, tak by nie straszyły swą „przestarzałą” strukturą.

Zasadnicze wady ORM 1. Często musimy tworzyć aplikacje

korzystające z gotowych danych i żadne mechanizmy synchronizacji nie wchodzą w rachubę.

2. Wiele aplikacji obecnych na rynku ma tak fatalnie zaprojektowane bezy danych, że zapytania bywają bardzo złożone. Napisanie ich w modelu obiektowym mija się po prostu z celem

Zasadnicze wady ORM cd.

4. Testując aplikację, możemy śledzić kod programu i jego efekty w bazie danych (lub na ekranie). Programując w tradycyjny sposób, te dwa źródła informacji mamy tuż obok siebie. W modelu ORM pomiędzy nimi jest masa niezrozumiałego kodu, który 'coś' robi. Jeśli na dodatek jest to obce oprogramowanie, znalezienie źródła błędu jest utrudnione

5. Przyłączenie do bazy jest zaimplementowane "gdzieś" w bibliotece....

Jeśli wszystko jest zgodne z tym, co programista ORM sobie umyślił, to nie ma problemu. Ale jeśli na przykład w bazie jest inne kodowanie polskich znaków?

Najpoważniejsza wada ORM

Na koniec rzecz, która może się wydawać szukaniem dziury w całym. Chodzi o projektowanie baz danych. Jest to sztuka ważna i poświęcono jej mnóstwo książek. Od lat jednak przemysł software’owy dostarcza rozwiązań, które zdają się problemy dobrego projektu bazy danych unieważniać. Wskutek tego większość baz nie jest efektywna, a czasem bywają one koszmarne. Gdy taka baza ma kilkaset tabel, a brak jest szczegółowej dokumentacji, wyszukiwanie informacji w niej jest bardzo trudne.

Ocena końcowa

Pomimo zawartej w prezentacji krytyki nie należy uważać, by ORM należało na stałe skreślić ze słownika ważnych pojęć związanych z programowaniem.

Jednak umiejętność projektowania baz danych pozostaje jedną z kluczowych dla informatyka. ORM może być atrakcyjny jedynie w stosunkowo prostych projektach.

Dziękujemy za uwagę!