NIERELACYJNE BAZY DANYCH

, s. 83-96 Aleksander WÓJCIK Wyższa Szkoła Ekonomii i Innowacji w Lublinie, e-mail: aleksander.w1992@wp.pl NIERELACYJNE BAZY DANYCH OBJECT DATABASES Streszczenie Prześledzenie historycznych sposobów zapisu danych na nośniki trwałe. Przedstawienie podstawowych założeń relacyjnego modelu danych. Omówienie jego wad i zalet, a także zwrócenie uwagi na długoletnią dominującą pozycję na rynku. Zapoznanie słuchaczy z konwencją obiektowych baz danych. Omówienie dwóch modeli (relacyjnego i nierelacyjnego) na podstawie przykładu. Omówienie terminu NoSQL database jako zbioru technologii wykorzystujących rozwiązania nie bazujące na relacyjnym modelu danych. Podział technologii ze względu na rodzaj modelu danych. Dyskusja zalet i wad technologii w porównaniu do relacyjnego modelu. Summary Presenting the historical ways of recording data on durable media. Presentation of the basic assumptions of the relational data model. Discussion of the pros and cons and the explanation of the longterm dominant position on the market. Familiarization with the convention object databases. Discussion of the two models (relational and non-relational) on the basis of an example.discussion of the term NoSQL database as a collection of technologies using solutions, which do not rely on the relational data model. Division of technology due to the type of data model. Discussion about NoSQL technology advantages and disadvantages compared to the relational model. S ł o w a k l u c z o w e : NoSQL, bazy danych, relacyjny model danych, aplikacje bazodanowe, obiektowy paradygmat programowania K e y w o r d s : NoSQL, databases, relational data model, database applications, object oriented programming paradigm

84 Zeszyty Naukowe WSEI seria: TRANSPORT I INFORMATYKA, 4(1/2014) 1. Model relacyjny 1.1. Przyczyny przejścia na system baz danych Systemy informatyczne w miarę rozwoju wymagały zarządzania coraz większą ilością informacji. Początkowo dane były zapisywane w systemie plików. Jednak z wielu przyczyn nastąpiło przejście na systemy baz danych, na przykład: fizyczna i logiczna niezależność danych przechowywanie bez redundancji centralna kontrola integralności języki na wysokim poziomie abstrakcji m.in. ujednolicony mechanizm odczytu i zapisu danych Baza danych to zbiór informacji wraz z możliwością łatwego dostępu oraz ich zmiany (tj. modyfikacją, dodawaniem nowych i usuwaniem starych) z poziomu aplikacji z niej korzystającej. 1.2. Model hierarchiczny i sieciowy Pierwsza generacja Pod koniec lat 60. po raz pierwszy do opisania struktur fizycznych z logicznego punktu widzenia zastosowano matematyczne modele danych. Na podstawie pojęcia grafu opracowano modele hierarchiczny i sieciowy, które dziś mają niewielkie znaczenie. Rys. 1. W hierarchicznym modelu danych każdy węzeł ma dokładnie jednego rodzica, oprócz węzła stojącego na szczycie hierarchii. Drzewo katalogów jest przykładem struktury hierarchicznej

85 Rys. 2. Sieciowy model danych jest mniej restrykcyjny od hierarchicznego. W czerwonej pętli został zaznaczonywęzeł, który jest synem dwóch węzłów Druga generacja Drugą generacją nazywamy systemy oparte na relacyjnym modelu danych i relacyjnej algebrze zaproponowanych przez Edgar F. Codd a w 1970r., które szybko zdobyły popularność. Model ten ma bardzo solidne i precyzyjne podstawy matematyczne, co jest jego ogromną zaletą. 1.3. Podstawowe założenia modelu relacyjnego Wszystkie wartości danych oparte są na prostych typach danych. Wszystkie dane w bazie relacyjnej przedstawiane są w formie dwuwymiarowych tabel (w matematycznym żargonie noszących nazwę relacji ). Każda tabela zawiera zero lub więcej wierszy (w tymże żargonie krotki ) i jedną lub więcej kolumn ( atrybutów ). Na każdy wiersz składają się jednakowo ułożone kolumny wypełnione wartościami, które z kolei w każdym wierszu mogą być inne. Po wprowadzeniu danych do bazy, możliwe jest porównywanie wartości z różnych kolumn, zazwyczaj również z różnych tabel, i scalanie wierszy, gdy pochodzące z nich wartości są zgodne. Umożliwia to wiązanie danych i wykonywanie stosunkowo złożonych operacji w granicach całej bazy danych.

86 Wszystkie operacje wykonywane są w oparciu o algebrę relacji, bez względu na położenie wiersza tabeli. Nie można więc zapytać o wiersze, gdzie (x=3) bez wiersza pierwszego, trzeciego i piątego. Wiersze w relacyjnej bazie danych przechowywane są w porządku zupełnie dowolnym nie musi on odzwierciedlać ani kolejności ich wprowadzania, ani kolejności ich przechowywania. Z braku możliwości identyfikacji wiersza przez jego pozycję pojawia się potrzeba obecności jednej lub więcej kolumn niepowtarzalnych w granicach całej tabeli, pozwalających odnaleźć konkretny wiersz. Kolumny te określa się jako klucz podstawowy (ang. primary key) tabeli. 1.4. Trwałość modelu Model relacyjny od 40-tu lat ma najważniejsze znaczenie i nie chce ustąpić nowym technologiom. W informatyce 40 lat to jest bardzo długi okres czasu, dlatego model relacyjny jest fenomenem jeśli chodzi o trwałość technologii. Przyczyny: system relacyjny nadawał się do budowy dużych systemów informatycznych w latach 80. i bardzo dużo kodu zostało w nim napisane; został rozwijany i wdrażany przez dwie bardzo duże firmy informatyczne: IBM i Oracle; ma wyjątkowo prosty interfejs komunikacji: select, insert, update i delete, natomiast w systemach NoSQL lub w XML-owych bazach danych wymagana jest znajomość programowania do operacji na danych. 1.5. MINUSY MODELU RELACYJNEGO Już kilka lat po spopularyzowaniu się modelu relacyjnego zaczęła się szeroka krytyka modelu. Okazał się on nieelastyczny i trudny w modelowaniu rzeczywistości, z następujących powodów: 1. Brak typów złożonych 2. Atrybuty złożone (np. adres) nie mogą być reprezentowane bezpośrednio składowe muszą być deklarowane indywidualnie jako atrybuty 3. Powiązania pomiędzy tabelami tylko poprzez klucze obce 4. Nieelastyczność modelu, brak możliwości rozszerzenia Szczególnie uciążliwe w modelowaniu rzeczywistości jest: Potrzeba definiowania klucza sztucznego, gdy atrybuty nie są wystarczające do uzyskania unikatowej identyfikacji (np.nazwa firmy może się powtarzać) Atrybuty zbiorowe (np. pracownicy) muszą być rozróżnialne od atrybutów jednowartościowych i reprezentowane w innym schemacie relacyjnym Agregacje i specjalizacje nie są w łatwy sposób obsługiwane i wymagają specjalnych więzów integralności

87 2. Obiektowe bazy danych 2.1. Problemy z modelem relacyjnym a) Niekompatybilność Główną przyczyną szukania innych rozwiązań niż relacyjny model danych jest konflikt występujący w aplikacjach bazodanowych tj. niezgodność pomiędzy modelem umożliwiającym przechowywanie danych (relacyjnym) a modelem, w którym implementowany jest program. Większość dzisiejszych aplikacji jest implementowanych w językach Java, C# lub C++, które bazują na paradygmacie obiektowym. b) Brak jednoznacznego paradygmatu Zarówno standard SQL2 jak i założenia paradygmatu obiektowego są jednoznaczne. Jednak przy próbie połączenia paradygmatów i wypracowania jednolitego standardu pojawiają się duże rozbieżności. Nie jest znany żaden ogólnie, szeroko przyjęty paradygmat obiektowych baz danych, który by dobrze łączył dwa oddzielne paradygmaty. Różnice pomiędzy językami obiektowymi (np. C++ a Java) są dużo mniejsze niż pomiędzy poszczególnymi systemami obiektowych baz danych. 2.2. Rozwiązania Istnieją dwa główne podejścia do projektowania języka, który by rozwiązał problem niekompatybilności pomiędzy modelem danych (relacyjnym), a językiem implementacji programu (obiektowym): 1. Zbliżenie języka proceduralnego SQL do języków obiektowych poprzez uwzględnienie zasad funkcjonowania obiektów. Dokładniej: stworzenie języka baz danych rozszerzonego o funkcje obiektowe. Przykładem takiego rozwiązania jest język SQL 3.0. 2. Zbliżenie możliwości języków obiektowych do SQL poprzez włączenie funkcjonalności baz danych. Dokładniej: rozszerzenie obiektowych języków programowania o funkcje typowe dla baz danych poprzez dołączenie klas bibliotek. 3. Kolejnym pomysłem jest użycie mapowania obiektowo-relacyjnego (tzn. system ORM lub bazy relacyjno-obiektowe), które polega na manipulowaniu danymi jako zestawem obiektów, ale użycie bazy relacyjnej jako wewnętrzny mechanizm przechowywania danych. 2.3. Charakterystyka obiektowej bazy danych W obiektowej bazie danych przechowywane są obiekty zamiast wierszy tabeli jak w modelu relacyjnym. Umożliwia to łatwiejszą integracje z obiektowymi językami programowania. Na obiekt składa się identyfikator obiektu (adres pamięci), który jest unikalny oraz wartości jego wszystkich pól. W szczególności obiekty

88 Zeszyty Naukowe WSEI seria: TRANSPORT I INFORMATYKA, 4(1/2014) mające te same wartości pól mogą być różnymi obiektami (wskazywać na inne adresy pamięci) jak i tymi samymi obiektami (wówczas obiekty są referencjami do tego samego adresu pamięci). W języku Java obiekty (Object o1, Object o2) porównuje się za pomocą dwóch narzędzi: 1. Porównanie: wyrażenie Zwraca wartość prawda, kiedy o1 i o2 to ten sam obiekt, tzn. obiekty wskazują na ten sam adres pamięci 2. Metoda equals: wyrażenie (o1.equals(o2)); Dla większości standardowych klas zwraca wartość prawda, jeśli wartości wszystkich pól są identyczne, jednak programista może tą metodą dowolnie nadpisać w klasach niefinalnych. 2.4. Przykłady obiektowych systemów baz danych [1] Illustra Rozwinięcie Postgresu. Rozszerza pojęcia relacyjne przy pomocy pojęć charakterystycznych dla obiektowości ObjectStore. Rozszerza obiektowy język C++, dodając trwałość GemStone (rozszerzenie Smalltalk-u) Oracle Zauważmy, że najpopularniejsze języki na rok 1997, czyli C++ oraz Smalltalk posiadały biblioteki obsługujące obiektowe bazy danych. Również znane firmy z rynku relacyjnych baz danych: Postgres oraz Oracle miały swoje obiektowe wersje. Po roku 2000. zainteresowanie obiektowymi bazami danych spadło na rzecz systemów mapowania obiektowo-relacyjnego. 2.5. Standard SQL 3.0. Standard języka SQL 2.0. z r. był standardem długo obowiązującym, do którego większość firm się dostosowała wprowadzając swoje własne dialekty języka SQL. Nowy standard SQL 3.0. miał w założeniu wprowadzać do języka SQL cechy obiektowe. W prezentacji [9] z 1998 r. autor przekonuje, że standard nie zostanie przyjęty w realnych zastosowaniach, mimo potencjalnych dużych możliwości i elastyczności standardu. Standard przewiduje: Obiektowość: SQL3 reprezentuje podejście hybrydowe, dodając niektóre cechy obiektowości (takie jak ADT) do tablic znanych z systemów relacyjnych. Rozszerzalność: umożliwienie użytkownikom deklarowania własnych typów. Niekonwencjonalne typy danych: multimedialne, przestrzenne, temporalne. Pełne możliwości uniwersalnego języka programowania dla definiowania i zarządzania trwałymi, złożonymi obiektami. Rozszerzenia w zakresie aktywnych reguł, interfejsów do innych języków programowania, autoryzacji, procedur bazy danych, ewolucji schematu, i inne.

89 Deklarowana jest zgodność w dół ze standardem SQL-92. W nowym standardzie SQL3 twórcy próbują wyeliminować wszelkie wady jego poprzedników. Jednocześnie, próbują wszystko z nich pozostawić. Standard jest ogromny, według różnych szacunków 1200-1600 stron, zaś jego poszczególne części są niezbyt spójne. 3. Nierelacyjne bazy danych 3.1. Termin NoSQL Termin NoSQL czyli Not Only SQL określa systemy zarządzania, które nie bazują na modelu relacyjnym. Konsekwencją odrzucenia modelu relacyjnego jest to, że dane przechowywane w bazie danych nie wymagają ściśle określonych schematów (np. tabel), w wielu przypadkach nie ma w nich złączeń dzięki czemu umożliwiają łatwe skalowanie w poziomie, a co za tym idzie realizacja zapytań jest efektywniejsza. Termin NoSQL często jest mylony z jedną konkretną technologią. W rzeczywistości można go określić jako zbiór rozwiązań służących do przechowywania danych, które stoją w opozycji do modelu relacyjnego. Termin Not Only SQL podkreśla, że systemy mogą dopuszczać elementy SQL-a, w szczególności języki zapytań podobne do SQL-owych. 3.2. Założenia ruchu NoSQL Standaryzacja interfejsu dostępu do baz NoSQL5 Eliminacja najsłabszych rozwiązań. Na rynku muszą pozostać tylko najlepsze rozwiązania. Obecnie można wybierać spośród ponad 50 technologii. Nie sposób ich wszystkich przetestować. Problem z budową zapytań. Aktualnie tworzenie takich zapytań wymaga znajomości programowania Zagwarantowanie wsparcia dla swoich rozwiązań. Na razie są to rozwiązania typu open source, tworzone najczęściej przez małe firmy lub pojedyncze osoby. Istnieje potrzeba zaangażowania dużych firm związanych z bazami danych. 3.3. Założenia technologii NoSQL Rezygnacja z wielu elementów baz relacyjnych. Zauważono, ze duża liczba złączeń tabel powoduje zdecydowany spadek wydajności, a ścisły schemat bazy danych nie zawsze bywa zaletą, gdyż wiele danych nie ma określonej struktury. Zmniejszenie znaczenia schematów danych. Wg założeń NoSQL uwaga powinna być skupiona najpierw na danych, a dopiero potem na schematach. Odejście od postulatów ACID. Stwierdzono, że postulaty są zbyt restrykcyjne. Atomicity atomowość

90 Zeszyty Naukowe WSEI seria: TRANSPORT I INFORMATYKA, 4(1/2014) Consistency spójność Isolation izolacja Durability trwałość 3.4. Niektóre modele baz NoSQL a) Bazy klucz-wartość (ang. key-value). W dużym uproszczeniu są to tabele, zawierające dwie kolumny tekstowe: klucz oraz wartość. Główną zaletą tego modelu jest to, że jest niezwykle szybki (zarówno jeśli chodzi o zapis jak i o odczyt danych). Natomiast wadą jest mała możliwość zastosowania takich baz w codziennym użyciu, ze względu na małe możliwości segregacji danych. Przykładem danych, które mogą być przechowywane w takich tabelach jest usługa DNS oferująca translację nazwy mnemonicznej serwera (np. pl.wikipedia.org) na adres ip (91.198.174.232). Bazy dokumentowe są uogólnieniem baz typu klucz-wartość i mają szersze zastosowanie. b) Bazy kolumnowe. Ich główną ideą jest zmiana sposobu postrzegania danych. Dane zamiast zapisywać dane w wierszach, zapisuje się je w kolumnach. c) Bazy obiektowe. d) Bazy dokumentowe. W ostatnim czasie są szczegółowo rozwijane. W bazach tego typu zamiast tradycyjnych wierszy używa się pojęcia dokumentu, zawierającego pary klucz-wartość. Rozwiązanie to jest bardzo elastyczne, a co za tym idzie dzięki nim możliwe jest bardzo wierne odtwarzanie rzeczywistych danych w systemach informatycznych. Przykładem takiej bazy jest coraz bar-

91 dziej popularne ostatnio MongoDB z którego korzystają już New York Times, Disney, MTV Networks, IGN Entertainment i The Guardian. Lista ta coraz szybciej się wydłuża. Co miesiąc baza pobierana jest około 100 tys. razy. Projekt szybko się rozwija dzięki wielu dotacjom. W niedawno opublikowanej wersji 2.0 znacząco podniosła wydajność, co doceniło już wiele firm. Wg John A De Goes [9] projekt jest dziś wart 1.2 mld $. e) Grafowe bazy danych. f) XML-owe bazy danych. 3. 5. P o r ó w n a n i e p r e z e n t a c j i d a n y c h n a p o d s t a w i e przykładu: Załóżmy, że chcielibyśmy zapisać w bazie następujące dane [A]: Sue ma 26 lat, status A oraz jest zapisana do grup news oraz sports John ma 24 lat, status B oraz jest zapisany do grup news oraz sports Al ma 18 lat, status D oraz jest zapisany do grupy politics Zastosujmy do tego różne modele danych: 1. Model relacyjny Będziemy mieli na pewno tabelę People, w której będziemy przechowywać dane o osobach. Model relacyjny wymusza na nas stosowanie klucza głównego. Mimo, że imiona się nie powtarzają, klucz główny musi być liczbą naturalną, zatem ponumerujemy osoby: 1,2,3 za pomocą dodatkowego pola-klucza sztucznego person_id. W tabeli znajdą się poza tym: informacja o wieku, statusie oraz grupach. Ponieważ ostatnia wartość jest atrybutem zbiorowym, musimy wprowadzić tabelę Group, w której trzymamy wszystkie nazwy grup, do której osoby mogą należeć. Każdą taką nazwę numerujemy za pomocą klucza sztucznego. W tabeli People zapisujemy wszystkie występujące kombinacje grup, do której należy każda osoba, tzn. ciąg kluczy obcych do tabeli Group. Jeśli byłaby potrzeba przechowywać informacje, że osoba może mieć dwa statusy, to również trzeba by było wprowadzić osobną tabelę Status, a w tabeli People przechowywać tylko identyfikatory do odpowiednich wierszy tabeli Status. Dane [A] można prezentować w tabeli w programie Microsoft Excel: Rys. 4. Tabela People z wypełnionymi danymi

92 Zeszyty Naukowe WSEI seria: TRANSPORT I INFORMATYKA, 4(1/2014) Zwróćmy uwagę, że informacja kto należy do jakiej grupy jest zupełnie nieczytelna bez tabeli Group. Rys. 5. Tabela Group z wypełnionymi danymi 2. Bazy obiektowe W bazie obiektowej będziemy mieli definicję klasy Person. Wystarczy utworzyć obiekt klasy Person, przypisać mu odpowiednie atrybuty oraz zapisać stan osoby do bazy za pomocą interfejsu, który dostarcza konkretna technologia. Przykładowa klasa Person napisana w języku Java. Dzięki adnotacji @Data z biblioteki projektu lombok [10] nie trzeba generować getterów, setterów, ani nadpisywać metody tostring(). Kod wygląda zwięźlej. W przypadku nie korzystania z tej biblioteki należy za pomocą skrótu alt+insert wygenerować odpowiedni kod w środowisku IDE NetBeans, Eclipse lub Intellij IDEA. 3. Bazy dokumentowe W bazach dokumentowych dokumentem nazywamy zbiór par klucz-wartość. W naszym przypadku jeden dokument będzie odpowiadał jednej osobie.

93 W bazach dokumentowych sposób prezentacji i zapisu danych jest najbardziej czytelny. Nawiasy klamrowe wyznaczają granicę jednego dokumentu w tym przypadku jednej osoby. Poza tym bazy dokumentowe należą do najszybszych. 4. XML-owe bazy danych W XML-owych bazach danych podstawowym formatem zapisu jest format XML. Zaczyna się on deklaracją wersji formatu XML oraz kodowania. Następnie dane są przechowywane w jednym drzewie znaczników.

94 Zeszyty Naukowe WSEI seria: TRANSPORT I INFORMATYKA, 4(1/2014) Format XML jest prawie tak samo czytelny jak w bazach dokumentowych. Minusem jest jego mała zwięzłość do zapisu tych samych danych jest przeznaczana duża ilość tekstu. Format jest na tyle popularny, że istnieją programy, które automatycznie formatują kod XML oraz podświetlają znacznik zamykający i otwierający. 3.6. Wady i zalety nierelacyjnych baz danych Biorąc pod uwagę powyższy przykład można powiedzieć, że sposób zapisu i prezentacji w nierelacyjnych bazach danych jest prostszy, elastyczniejszy, przejrzystszy i łatwiej czytelny dla człowieka niż w modelu relacyjnym. Warto też zwrócić uwagę na jeden drobny, ale ważny fakt, który porusza autor postu na portalu javadzone [8]. Model relacyjny był w ogromnej większości przedsiębiorstw i uczelni używany jako jedyny, a nierelacyjne bazy danych dopiero niedawno zaczęły pojawiać się w nowszych zastosowaniach. Wobec tego

95 jest bardzo dużo dobrych, przetestowanych i popularnych narzędzi ułatwiających pracę z relacyjnym światem. Natomiast o ile silniki do obsługi nierelacyjnych baz (tzn. przetwarzanie, odczytywanie i zapisywanie danych) są dopracowane i działają niezawodnie i bardzo szybko, to programiści nie mają odpowiednich narzędzi do wygodnej i szybkiej pracy z kodem aplikacji. Powoduje to, że programistom ciągle wygodniej się pracuje z relacyjnymi bazami, pomimo, że chętnie zdecydowaliby się na inny model danych. Autor artykułu nazywa tą niedogodność piętą achillesową (ang. Achilles heel) technologii NoSql. Przedstawione zostanie jeszcze jedno porównanie różnych modeli danych pod względem szybkości i elastyczności. Wg Ben a Scofield a [7] relacyjny model danych jest najmniej elastyczny i razem z grafowymi bazami danych osiąga najmniejszą wydajność. Funkcjonalność baz key-value jest nieokreślona lub żadna, ale ma najwyższą wydajność i najmniejszą złożoność. 4. Podsumowanie Relacyjny model danych nie był pierwszym modelem danych, ale pierwszym, który przyjął się na bardzo szeroką skalę i od 40-stu lat jest stosowany w większości zastosowań. Do głównych jego wad należy trudność w modelowaniu rzeczywistości, nieelastyczność oraz brak typów złożonych. Największą zaletą jest stabilna pozycja na rynku i dostosowanie się szeregu programistycznych narzędzi do modelu. Wraz ze wzrostem popularności języków obiektowych w latach 90. wzrosło zainteresowanie i nadzieje w związku z obiektowymi bazami danych. Dziś stanowią one bardzo mały odsetek używanych technologii, nie przyjęły się komercyjnie. Firmy zdecydowały się stosować rozwiązanie mapowania obiektowo-relacyjnego, które w ostatnim czasie jest intensywnie wdrażane w wielu zastosowaniach.

96 Obecnie istnieje ponad 50 różnych technologii bazujących na nierelacyjnym modelu danych oraz osiągają one pierwsze komercyjne sukcesy. W technologii ukryty jest bardzo duży potencjał, a każdy sukces jest dostrzegany w informatycznych blogach i czasopismach. Brak wielu profesjonalnych narzędzi do obsługi technologii oraz niejednolity i skomplikowany interfejs dostępu do danych są trudnościami, z powodu których technologia nie jest aż tak chętnie wybierana jakby mogła być. Bibliografia [1] Lausen G., Vossen G.: Obiektowe bazy danych. WNT, Warszawa, 2000, ISBN 83-204-2487-9. [2] http://wazniak.mimuw.edu.pl/index.php?title=bazy_danych. [3] http://wazniak.mimuw.edu.pl/index.php?title=zaawansowane_systemy_baz_danych [4] http://edu.pjwstk.edu.pl/wyklady/. [5] http://cts.com.pl/aktualnosci/co-to-jest-nosql. [6] http://webhosting.pl/nie.skreslajcie.nosql.3.przyklady.zastosowania.z.sukcesem.nierelacyjnych.baz. [7] http://en.wikipedia.org/wiki/nosql. [8] http://java.dzone.com/articles/achilles-heel-nosql. [9] Subieta K.: SQL3: Nowy standard języka SQL. Instytut podstaw informatyki PAN, Warszawa. [10] http://projectlombok.org/features/data.html.