Odwzorowanie obiektowo

Transkrypt

Odwzorowanie obiektowo
PODSTAWY BAZ DANYCH
Mateusz Wojtaszek
Agnieszka Walczak
Kamil Lisiecki
ODWZOROWANIE
OBIEKTOWO-RELACYJNE
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 obiektoworelacyjnego 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ę! 

Podobne dokumenty