Integracja danych i aplikacji przy użyciu wirtualnych repozytoriów

Wielkość: px
Rozpocząć pokaz od strony:

Download "Integracja danych i aplikacji przy użyciu wirtualnych repozytoriów"

Transkrypt

1 Polsko-Japońska Wyższa Szkoła Technik Komputerowych Integracja danych i aplikacji przy użyciu wirtualnych repozytoriów Michał Lentner Polsko-Japońska Wyższa Szkoła Technik Komputerowych Praca doktorska napisana pod kierunkiem prof. dr hab. inż. Kazimierza Subiety Warszawa, styczeń 2008

2

3 Streszczenie Podstawowym celem rozprawy doktorskiej jest zbadanie nowych paradygmatów ułatwiających proces implementacji systemów informatycznych. Przedstawiona w niej została propozycja narzędzia programistycznego umożliwiającemu pracę programiście bazodanowemu na znacznie wyższym poziomie, niż umożliwiają to popularne współczesne rozwiązania. W tym celu stworzony został nowy, obiektowy język programowania, bezszwowo zintegrowany z konstrukcjami języka zapytań (zapytania jako wyrażenia), razem z jego rozproszonym, bazodanowo zorientowanym środowiskiem wykonawczym. Oprogramowanie to zapewnia funkcjonalność wielu istniejących narzędzi (takich jak np. języki programowania aplikacji baz danych, języki zapytań do baz danych, systemy zarządzania bazami danych, różnego rodzaju middleware) w jednym, spójnym, uniwersalnym, łatwym do wykorzystania i efektywnym w użyciu środowisku programistycznym. Praca została podzielona na siedem rozdziałów. W pierwszym rozdziale przedstawiamy problem integracji danych i aplikacji jako jednego z głównych czynników wpływającego na wydajność inżynierów wytwarzających oprogramowanie biznesowe. Problem ten definiujemy z punktu widzenia dwóch aspektów: integracji języka programowania z bazą danych, oraz integracji istniejących aplikacji w systemach rozproszonych. Rozdział drugi poświęcony jest kilku najbardziej znanym obecnie podejściom do integracji danych i aplikacji. Omawiamy tutaj zagadnienia związane z metodami łączenia aplikacji z relacyjnymi i obiektowymi bazami danych, jak również najważniejsze rodzaje middleware. 3

4 W rozdziale trzecim przedstawiamy skrótowo podejście stosowe do języków zapytań - teoretyczną bazę na podstawie której zaprojektujemy prototypowy język programowania/zapytań zintegrowany z obiektową bazą danych, funkcjonującą również jako middleware. W rozdziale czwartych przedstawimy architekturę zaproponowanego przez nas narzędzia oraz zaprezentujemy przykładowe scenariusze jego zastosowania w dziedzinie integracji danych i aplikacji. Kolejny rozdział, czyli rozdział piąty, jest nieformalnym opisem języka SBQL, rozszerzonego przez nas na potrzeby niniejszej pracy do kompletnego języka programowania. W związku z tym, iż język SBQL posiada szereg mechanizmów deklaratywnych, niezbędne jest zaprojektowanie wydajnych algorytmów optymalizacyjnych dla zapytań. Podstawowe algorytmy optymalizacyjne dla SBQL w środowisku scentralizowanym zostały już sformułowane, jednak optymalizacja zapytań rozproszonych wymaga dodatkowych technik. Temu zagadnieniu poświęcono zatem rozdział szósty. Rozdział siódmy stanowi szczegółowa dyskusja na temat integracji danych za pomocą aktualizowalnych perspektyw. Prezentujemy kod źródłowy prostego systemu trójwarstwowego (klient-serwer integracyjny-serwery kontrybucyjne) oraz objaśniamy mechanizm wymiany danych w takim środowisku. Ostatni rozdział, czyli rozdział ósmy, dokumentuje szereg niskopoziomowych decyzji, jakie zostały podjęte w celu zaimplementowania prototypu zaproponowanego przez nas narzędzia. Obok tekstu niniejszej pracy, prototyp ten jest jednocześnie podstawowym rezultatem badań podjętych przez autora rozprawy. 4

5 Summary The main objective of this Ph.D. thesis is to develop new software construction paradigms that make the implementation of information systems easier. We have proposed an application development environment allowing a database programmer to work on a much higher level of abstraction than it is possible when current solutions are used. To this end, we have created a new object-oriented programming language, seamlessly integrated with query language constructs (queries as expressions) and with its distributed, database-oriented runtime environment. Our software provides functionality of many existing tools (such as: database programming languages, database query languages, database management systems, several kinds of middleware) in a single, consistent, universal, easy to use and effective to apply programming environment. The thesis is divided into seven chapters. In the first chapter, a brief introduction to the problem of data and application integration is discussed. The need for integration is presented as one of the most important factors influencing the work of today s business application developers. The problem is defined from the point of view of two aspects: the integration of a programming language and a database management system, as well as the integration of existing applications being parts of distributed systems. 5

6 The second chapter is focused on highlighting some of the most popular approaches of data and application integration. We have discussed several issues associated with existing methods of connecting applications with relational and object-oriented databases, as well as the most important types of middleware. In the third chapter the Stack-Based Approach to query languages is briefly described. It is presented as a theoretical base allowing us to construct a prototype programming/query language integrated with an object-oriented database having middleware features. In the fourth chapter the architecture of our prototype solution is introduced. Several typical scenarios of its application in the area of data and application integration is also presented. The fifth chapter contains an informal description of the SBQL language, extended by us to a fullyfledged database programming language. Since SBQL contains declarative constructs, it was necessary to design efficient query optimization algorithms. The most important optimizations for SBQL queries executed in a centralized environment have already been designed in other works. However, distributed query processing requires completely new solutions. This issue has been discussed in the sixth chapter. The seventh chapter contains a detailed discussion on data integration with the use of updateable views. The source code of a simple, three-tier (client, integration server, contributory server) system is presented. We have also explain the functionality of several low-level mechanisms responsible for data exchange between particular nodes of the system. The last chapter documents several low-level decisions which have been made in order to implement a prototype of the tool discussed in this thesis. Apart from the text of the disseration, the prototype is the main product of the research conducted by the Author. 6

7 Spis treści Rozdział 1: Wprowadzenie... 9 Rozdział 2: Stan sztuki w dziedzinie integracji danych i aplikacji Rozdział 3: Podejście stosowe do języków zapytań Rozdział 4: Koncepcja architektury narzędzia RAD nowej generacji Rozdział 5: Język SBQL w systemie Odra Rozdział 6: Optymalizacja zapytań rozproszonych Rozdział 7: Integracja danych rozproszonych Rozdział 8: Prototyp Podsumowanie pracy Dodatek A: Przykładowy program SBQL Dodatek B: Kod źródłowy zintegrowanego systemu połączeń kolejowych Dodatek C: Ewaluacja przykładowego zapytania SBQL Dodatek D: Przetwarzanie danych XML za pomocą SBQL Dodatek E: Ważniejsze operacje maszyny wirtualnej SBQL Lista ważniejszych akronimów użytych w pracy Literatura

8

9 Rozdział 1: Wprowadzenie Eksplozja informacji W ostatnich latach obserwowana jest gwałtowna eksplozja ilości informacji, z jaką mają do czynienia systemy informatyczne współczesnych organizacji. Zbadano, iż w ciągu trzech poprzednich lat wygenerowano więcej informacji, niż zapisano w ciągu całej historii ludzkości [1]. Niestety, za tą eksplozją informacji oraz rozwojem potrzeb nie nadąża rozwój narzędzi informatycznych. Nie dziwi więc, iż systemy wielu organizacji często załamują się pod wpływem wielkiej ilości i różnorodności danych, jakie muszą być przetwarzane przez poszczególne (często odizolowane od siebie) składniki tych systemów. Okazuje się, że wraz z rozwojem potrzeb integracyjnych problem przetwarzania danych masowych w rozproszonych i heterogenicznych środowiskach zdobywa coraz większe znaczenie, a narzędzia wspomagające czynności z tym związane stają się coraz potrzebniejsze [2]. Nieprzerwanie rosnąca złożoność tych narzędzi wiąże się jednak z tym, iż programiści coraz rzadziej zdolni są opanować wszystkie czynności, jakie wynikają z produkcji oprogramowania w takich środowiskach. Ilość technologii, interfejsów programistycznych, języków, bibliotek, protokołów, serwerów, etc., które współczesny programista musi znać i używać jest wprost gigantyczna. Ten ciągle rosnący zakres technologii jest jedną z przyczyn ogromnej zlożoności współczesnego oprogramowania, a co za tym idzie - kosztów jego wytwarzania oraz pielęgnacji. Ponieważ w przyszłości problem ten będzie narastał, nieodzowne są prace nad nowymi, prostymi w obsłudze, uniwersalnymi i homogenicznymi narzędziami 9

10 programistycznymi wspomagającymi tworzenie aplikacji baz danych w środowiskach rozproszonych. Obiektowość Walka ze złożonością oprogramowania wymaga przede wszystkim sięgnięcia do źródeł tej złożoności, czyli sposobu postrzegania problemów przez człowieka oraz implementacji tych problemów za pomocą maszyny. Okazuje się, iż im mniejsze są różnice, tym prostsze jest tworzenie systemów informatycznych oraz tym mniejszy jest koszt ich wytworzenia i pielęgnacji. Praktyka pokazała, iż jednym z najbardziej zaawansowanych obecnie paradygmatów umożliwiających niwelowanie tych różnic jest obiektowość. Na przestrzeni lat okazało się, iż pojęcia takie jak obiekt, klasa, asocjacja, metoda, specjalizacja, generalizacja, polimorfizm itp., bliższe są ludzkiemu sposobowi postrzegania świata, a realizowana przy ich pomocy struktura danych/oprogramowania staje się bardziej intuicyjna. Dziś normą jest obiektowa analiza i projektowanie oprogramowania za pomocą obiektowych notacji graficznych, oraz implementacja oprogramowania za pomocą obiektowych języków programowania [6]. Rozwój obiektowości nie jest jednak zakończony. Pomimo wiodącej roli tego podejścia w analizie oraz projektowaniu systemów oraz w językach programowania, idee obiektowości nie zyskały dotychczas szerokiego uznania na polu baz danych. Standard ODMG [12], czyli próba ustandaryzowania obiektowego modelu danych, języka zapytań i interfejsu programistycznego do obiektowych baz danych okazał się klęską. Zaprezentowane w nim idee okazały się w dużym stopniu nieimplementowalne dla twórców systemów zarządzania bazami danych, oraz nieakceptowalne dla programistów aplikacji. Również powstające niezależnie od tego standardu systemy zarządzania obiektowymi bazami danych nie zyskały dotychczas szerszego uznania, dobrze sprawdzając się jedynie w niszowych zastosowaniach. Mnogość tymczasowych rozwiązań zapewniejących mechanizmy odwzorowania relacyjno-obiektowego (realizowanych często ad-hoc przez środowiska przemysłowe) pokazuje jednak, jak ważne dla współczesnych programistów jest operowanie na bazach danych chociażby bez konieczności tłumaczenia struktur relacyjnych na struktury obiektowe i odwrotnie. Zalety obiektowych baz danych w stosunku do baz relacyjnych akcentowane w ubiegłej dekadzie nie straciły zatem nic ze swej aktualności [34, 36, 32]. Są to przede wszystkim: Znacznie bogatszy model danych. 10

11 Brak niezgodności impedancji pomiędzy modelem danych obiektowego języka programowania i bazy danych. Ortogonalna trwałość. Potencjalnie wyższa wydajność (zwłaszcza w zakresie przetwarzania asocjacji). Praktyczna realizacja tych postulatów stała się niestety trudniejsza niż początkowo przypuszczano. Niektórzy specjaliści uważają wręcz, że idea obiektowych baz danych okazała się niemożliwą do spełnienia utopią. Do najczęściej wymienianych wad obiektowych baz danych należą: Zbyt mocne powiązanie aplikacji z operacjami wykonywanymi na bazie danych. Przypadkowość rozwiązań, brak ogólnie przyjętego standardu, takiego jak SQL [87]. Brak lub utrudnione korzystanie z języka zapytań. Wszystkie te wady powodują, iż potrzebne są dalsze badania w tej dziedzinie. Niezbędne staje się opracowanie zupełnie nowych architektur obiektowych baz danych, dramatycznie innych od obecnie stosowanych. W przeciwnym razie bazy danych tego typu na zawsze skazane będą na zastosowania niszowe, jako rozszerzenia tradycyjnych języków programowania. Środowiska programowania aplikacji baz danych Bazy danych są krytycznym elementem każdej współczesnej aplikacji biznesowej. Programiści korzystają z baz danych w celu zapewnienia trwałości danym masowym oraz uzyskania do nich szybkiego i bezpiecznego dostępu. Ponieważ dane lokalne aplikacji oraz dane przechowywane w bazie danych należą do dwóch różnych światów, częścią praktycznie każdej współczesnej aplikacji jest warstwa odpowiedzialna za wymianę danych pomiędzy tymi światami. Implementacja takiej warstwy osiąga często nawet kilkadziesiąt procent objętości całego systemu, jest niejednokrotnie źródłem błędów i frustracji programistów. Nie dziwią więc ciągłe próby podejmowane przez światy naukowy i akademicki, zmierzające do integracji języków programowania z bazami danych. W idealnej sytuacji (postulowanej przez tzw. ortogonalną trwałość) dostęp do obiektów aplikacyjnych i obiektów bazy danych realizowany powinien być z użyciem dokładnie tych samych konstrukcji językowych. W praktyce taka bezszwowa integracja języka programowania z bazą danych nie została dotychczas osiągnięta w satysfakcjonujący sposób. Idea ta realizowana jest obecnie zazwyczaj poprzez rozszerzenie tradycyjnego języka programowania (np. Java) w taki sposób, by niektóre obiekty (np. będące instancjami specjalnej klasy) nie miały charakteru ulotnego 11

12 (znikały po wyłączeniu komputera), ale trwały (zapisywane były automatycznie na dysku komputera). Idea ta została pierwotnie zapoczątkowana przez tzw. języki z trwałością (np. Persistent Modula 3 [24], PJama [23], etc.), a następnie rozwijana w ramach obiektowych baz danych. Dzięki tym rozwiązaniom udało się przede wszystkim ujednolicić modele danych. Ten sam obiektowy model danych znajduje się zatem zarówno po stronie bazy danych, jak i języka programowania. Programista nie jest dzięki temu zmuszony do utrzymywania dwóch równoważnych struktur danych (np. tabel i obiektów), ale w przezroczysty sposób operuje na trwałych obiektach. Technika zapoczątkowana przez języki z trwałością stała się również inspiracją dla technologii wywodzących się ze środowisk przemysłowych i reprezentowanych przez techniki odwzorowania relacyjno-obiektowego. Rozwiązania takie jak Hibernate próbują połączyć zalety ortogonalnej trwałości, oraz dobrze znanych systemów zarządzania relacyjnymi bazami danych. Realizowane jest to poprzez wprowadzenie dodatkowej warstwy metadanych (tworzonych przez programistę), odwzorowującej strukturę obiektową aplikacji na strukturę relacyjnej bazy danych. Języki z trwałością oraz bazujące na nich rozwiązania nie spotkały się z większym uznaniem z powodu wad, w szczególnością jednej która naszym zdaniem całkowicie je dyskwalifikuje. Wadą tą jest brak języka zapytań lub też język zapytań w szczątkowej formie. Powstaje z związku z tym pewien dysonans - operacje aktualizacyjne pozbawione są niezgodności impedancji, natomiast operacje wyszukiwawcze realizowane są w tradycyjny sposób (poprzez zagnieżdżanie zapytań jako literałów, proceduralne przetwarzanie za pomocą iteratorów [29], etc.). Brak możliwości wyjścia z tej sytuacji skłania niektórych autorów do stwierdzenia, że języki zapytań w obiektowych bazach danych nie mogą być poprawnie zdefiniowane, albo wręcz że nie są potrzebne. Zamiast tego proponuje się wyrażanie operacji wyszukiwawczych w bazie danych za pomocą języka takiego jak Java czy C#. Okazuje się tymczasem, że rozwiązania takie jak native queries są nie tylko nieporównywalnie uboższe nawet w stosunku do standardowego SQL, ale również praktycznie uniemożliwiają realizację technik optymalizacyjnych, bez których konstrukcje deklaratywne tracą sens. Naszym zdaniem eliminacja języków zapytań z obiektowych baz danych jest skazaniem ich na porażkę. To właśnie dzięki językowi SQL mógł mieć miejsce tak przytłaczający sukces relacyjnych baz danych. Język zapytań jest niezwykle istotnym składnikiem każdego liczącego się obecnie systemu zarządządzania bazą danych. Podstawowym zadaniem języka zapytań jest podwyższenie wydajności programistów poprzez dostarczenie do ich dyspozycji pojęciowych, makroskopowych 12

13 operacji, pozwalających zapisać złożone operacje związane z przetwarzaniem danych w zwartej, czytelnej i zrozumiałej formie. Powszechną stała się opinia, że jedno zdanie napisane w języku zapytań może zastąpić kilka stron programu napisanego w języku programowania ogólnego przeznaczenia. Ma to krytyczne znaczenie dla tempa wytwarzania oprogramowania, jego kosztu, pielęgnacyjności i modyfikowalności. Następnym powodem jest dążenie do podwyższenia niezawodności produktów programistycznych, czemu sprzyja zwartość zapisu programu, konceptualizacja myślenia programisty i tzw. niezależność danych, przejawiająca się m.in. w abstrahowaniu od ich fizycznej organizacji. Jeszcze jednym powodem jest otwarcie nowych możliwości dla automatycznej optymalizacji programów. Operacje makroskopowe dają w tym względzie znacznie większe możliwości niż języki niskiego poziomu. Ten fakt jest potwierdzony przez szereg badań dowodzących, że dla złożonych zapytań automatyczny optymalizator daje lepsze wyniki niż ręczna optymalizacja [4, 39]. Wydaje się że różnice między językami zapytań i tradycyjnymi językami programowania są na tyle duże, iż ich integracja jest po prostu niewykonalna. Naszym zdaniem nie jest możliwe stworzenie wersji języka takiego jak Java czy C#, która w czysty semantycznie sposób pozwalałaby połączyć ze sobą konstrukcje języka proceduralnego i języka zapytań. Przyczyną tego stanu rzeczy jest to, iż języki zapytań bazują na zupełnie innych założeniach semantycznych i optymalizacyjnych: konstrukcje imperatywne vs. konstrukcje deklaratywne, optymalizacja podczas kompilacji vs. optymalizacja podczas czasu wykonania, algorytmy i struktury danych vs. tabele (w przypadku systemów relacyjnych) i indeksy, wątki vs. transakcje, null jako wskaźnik vs. null jako brak danych, różnice w składni, systemach typów, sposobie enkapsulacji danych, itp. Różnice te znane są powszechnie pod nazwą niezgodność impedancji. Jedynym sposobem na rozcięcie tego węzła gordyjskiego jest wprowadzenie nowej klasy języków programowania, w których wyrażenia byłyby tożsame z zapytaniami, a rezultatami wyrażeń mogły być kolekcje. Wyrażenia takie mogłyby posiadać właściwości tradycyjnych języków programowania (literały, nazwy, operatory), ale mogłyby również umożliwiać deklaratywne przetwarzanie dużych kolekcji danych. Operatory takiego języka powinny dawać się swobodnie łączyć z innymi konstrukcjami języka, wliczając w to konstrukcje imperatywne, instrukcje sterujące oraz abstrakcje programistyczne. Język taki powinien służyć zarówno do programowania strony serwera bazy danych, ale również strony klienckiej. Programy takiego języka powinny być uruchamiane w środowisku posiadającym cechy współczesnych systemów zarządzania bazami 13

14 danych (trwałość, indeksy, optymalizacja zapytań, bezpieczeństwo, transakcje, itd.), ale również maszyn wirtualnych (wirtualny zbiór instrukcji, pamięć, I/O). Poprzez przeniesie poziomu abstrakcji na znacznie wyższy poziom niż w obecnych językach programowania, języki takie pozwoliłyby na znaczące skrócenie czasu programowania oraz zwiększenie jakości wytwarzanego przy ich użyciu oprogramowania. Integracja rozproszonych danych i aplikacji We współczesnych systemach informatycznych zauważyć można tendencję zwiększonego zapotrzebowania na zapewnienie możliwości komunikacji pomiędzy programami komputerowymi, czy wręcz całymi systemami informatycznymi tych samych (Enterprise Application Integration, EAI), bądź całkowicie odrębnych (Business To Business, B2B) organizacji. Użytkownicy domagają się natychmiastowego dostępu do wszystkich informacji jakie posiada dana organizacja, niezależnie od systemu, w jakim informacja ta jest przechowywana. Zadaniem projektantów jest zatem sprawienie, by poszczególne systemy mogły ze sobą współpracować, czyli połączenie tzw. wysp automatyzacji (odizolowanych od siebie systemów realizujące ściśle określone zadania) w jeden wirtualny system informatyczny. Jak dotąd istnieje szereg kontrowersji co do tego, jak taki wirtualny system miałby wyglądać od strony technicznej. Przykładowo, niektórzy specjaliści postulują rozszerzenie tradycyjnego języka programowania o zestaw narzędzi (zwykle bibliotek i/lub generatorów kodu źródłowego) umożliwiających do pewnego stopnia przezroczyste dla programisty wykorzystywanie rozproszonych zasobów. Inni postulują oparcie integracji na tzw. usługach, komunikujących się ze sobą za pomocą standardowych protokołów i języków opisu danych. Jeszcze inni są zwolennikami integracji na poziomie procesów biznesowych, albo poprzez portale biznesowe. Istnieje także grupa zwolenników integracji aplikacji na poziomie danych - poprzez replikację danych (np. w hurtowni danych), albo federację baz danych. Cechą wspólną wszystkich tych rozwiązań jest dążenie do tego, by każda informacja była dostępna natychmiast, niezależniej od tego gdzie i w jakiej postaci jest ona w rzeczywistości przechowywana. Mechanizmy integracyjne muszą zatem działać w czasie rzeczywistym, oraz być na tyle sprawne, aby były w stanie współpracować z różnorodnymi bazami danych, serwerami aplikacji, systemami zarządzania treścią, hurtowniami danych, systemami przepływu prac, językami programowania, protokołami wymiany danych itp. 14

15 Middleware Podstawowym mechanizmem warunkującym sprawną komunikację w środowisku rozproszonym jest tzw. wartstwa pośrednia (middleware) [10]. Jest to oprogramowanie znajdujące się pomiędzy systemem operacyjnym oraz aplikacją po każdej stronie systemu rozproszonego. Istnieje wiele rodzajów middleware: rozproszone obiekty, serwery aplikacji, monitory transakcyjne, serwery integracyjne, brokery komunikatów i inne. Najważniejszym zadaniem middleware jest uczynienie procesu wytwarzania oprogramowania prostszym, poprzez dostarczenie abstrakcji programistycznych wspólnych dla każdej strony systemu rozproszonego, ukrycie heterogeniczności oraz dystrybucji systemów komputerowych, jak również niskopoziomowych szczegółów dotyczących komunikacji. Warto przy tym zauważyć, że aspekt przezroczystości w komunikacji rozproszonej nie jest jedynie domeną middleware. Tematyka ta jest również przedmiotem badań w dziedzinie rozproszonych/ federacyjnych baz danych [47, 48, 51]. Na przestrzeni lat specjaliści z tej dziedziny wypracowali znacznie bardziej zaawansowane aspekty przezroczystości niż te, które charakteryzują współczesne middleware. Do najważniejszych form przezroczystości zapewnianych przez federacyjne (zwane również wirtualnymi) bazy danych należą: przezroczystość dostępu, położenia, współbieżności, heterogeniczności, skalowania, fragmentacji, replikacji, optymalizacji, awarii, migracji, i inne. [89] Tradycyjne rodzaje middleware nie wspierają większości z tych własności, ponieważ nie są one nastawione na przetwarzanie kolekcji, ani danych trwałych za pomocą konstrukcji deklaratywnych. Middleware posiada zwykle charakter proceduralny, czyli znacznie niższy poziom abstrakcji niż języki zapytań. Konieczności przetwarzania kolekcji w systemie rozproszonym nie można jednak uniknąć. Problemy z tym związane widać szczególnie na przykładzie technologii rozproszonych obiektów. Przykładowo, w technologiach takich jak CORBA [25] podjęto próbę ukrycia różnic w dostępie do danych zdalnych i lokalnych. Ta iluzja okazała się zgubna dla wielu projektów programistycznych ze względów wydajnościowych. Źródłem problemów była pokusa operowania na danych zdalnych za pomocą takich samych algorytmów, jakie byłyby użyte gdyby dane te znajdowały się w pamięci operacyjnej lokalnego komputera. Niestety, okazuje się że ze względu na naturę pracy w sieciach komputerowych (czas dostępu, awaryjność) algorytmy te nie mogą być takie same. Twórcy standardu CORBA podjęli próbę wprowadzenia dodatkowych usług (Query Service, Persistence Service) mających usprawnić obsługę danych masowych za pomocą języka zapytań. 15

16 Próba ta nie zakończyła się satysfakcjonującymi rezultatami, głównie ze względu na problem niezgodności impedancji pomiędzy językami zapytań i tradycyjnymi językami programowania. Podobna sytuacja dotyczy popularnej technologii EJB (Enterprise Java Beans) [52] - tzw. ziarna encyjne (Entity Beans) oraz działający na nich język zapytań EJB QL nie rozwiązują naszym zdaniem problemu przetwarzania rozproszonych danych masowych. Pomijając nawet fakt małych możliwości tych języków zapytań, są one wręcz bezużyteczne w sytuacji gdy potrzebna jest aplikacja kombinująca dane z różnych źródeł danych. Ze względu na niskopoziomową (poprzez API) pracę z middleware sytuacje takie wymagają gigantycznych nakładów programistycznych związanych z optymalizacją kodu. Optymalizacja taka rzadko jest możliwa do zrealizowania w idealny sposób poprzez człowieka, ponieważ niejednokrotnie realizacja tej samej operacji dostępu do danych może mieć wiele (np. tysiące) możliwych sposobów implementacji (tzw. planów wykonania). Automatyczna optymalizacja rozproszonych zapytań za pomocą technik znanych z rozproszonych baz danych mogłaby rozwiązać ten problem, niestety współczesne rodzaje middleware nie posiadają takiej możliwości. Panujące obecnie trendy polegają raczej na ucieczce od tego złożonego problemu. Przykładowo, najnowsze rozwiązania, oparte na idei tzw. architektury zorientowanej na usługi (Service Oriented Architecture, SOA) całkowicie ignorują problem przetwarzania danych masowych. Ich zwolennicy przekonują, iż SOA operuje na poziomie usług, czyli na znacznie wyższym, niż zwykłe dane (wysokopoziomowa integracja usług vs. niskopoziomowa integracja danych). Automatycznie zakłada się zatem, że zdalna procedura (usługa) zaprojektowana została w taki sposób, by obsłużyć wszystkie możliwe sytuacje biznesowe związane ze zdalnym dostępem do zasobów. Naszym zdaniem jest to złudne założenie, które prowadzi do odkrywania na nowo dobrze znanych mechanizmów (np. transakcje dla WebServices) przetwarzania danych w środowisku rozproszonym. Obiektowa baza danych jako middleware We współczesnych systemach informatycznych bazy danych wykorzystywane są w projektach integracyjnych najczęściej wówczas, gdy problem da się rozwiązać za pomocą replikacji, federacji lub poprzez budowę hurtowni danych. Jeśli projekt integracyjny wymaga wykorzystania takich pojęć jak logika aplikacji, wówczas wykorzystywane są inne strategie integracyjne, np. integracja poprzez usługi. Zauważmy jednak że te ograniczenia baz danych wynikają z prostoty relacyjnego modelu danych i nie dotyczą baz obiektowych. Obiektowe bazy danych potencjalnie posiadają zarówno zalety relacyjnych baz danych, jak i języków programowania, dlatego każda znana strategia integracyjna może być wyrażona w kontekście takiego systemu. 16

17 Obiektowe bazy danych w projektach integracyjnych posiadają szereg znaczących zalet. Znacznie wyższy poziom abstrakcji, na którym pracuje potencjalny inżynier integracyjny korzystający z obiektowej bazy danych pozwala często wyrazić w jednej linii kod, który przy użyciu np. środków opartych na standardzie CORBA przyjąłby postać dużego programu. Ma to znaczenie nie tylko dla produktywności programistów, łatwości i stabilności tworzonego przez nich oprogramowania, ale również umożliwia automatyczną optymalizację operacji na rozproszonych danych. Taka automatyczna optymalizacja nie jest możliwa jeśli dany komponent systemu (np. usługa) zostanie zaprogramowany w ramach niskopoziomowego języka programowania. Jeśli integrowane mają być dane pochodzące ze źródeł heterogenicznych i integracja ma zachodzić w czasie rzeczywistym, wówczas konieczne jest zbudowanie federacyjnej bazy danych. Obiektowe bazy danych znane są tymczasem ze znacznie bogatszego modelu danych, pozwalającego na łatwiejsze wyspecyfikowanie kanonicznego modelu danych obowiązującego w federacji. Pozwala to zintegrować istniejące, rozproszone i heterogeniczne zbiory danych do postaci jednego, wirtualnego repozytorium wszystkich danych jakimi dysponuje organizacja. Nie zależy to od tego, czy integrowane zasoby to relacyjne, albo obiektowe bazy danych, repozytoria XML, czy dane multimedialne. Tak różnorodne modele danych stanowią problem dla relacyjnego modelu danych, ale nie dla wielu istniejących modeli obiektowych. Zauważmy, że nawet jeśli jako kanoniczny model danych wybrany zostanie stosunkowo uniwersalny model danych XML, taka decyzja nie gwarantuje sukcesu w integracji danych. Najpoważniejszymi problemami są tutaj m.in.: sposób opisu globalnych danych danych, język zapytań i jego optymalizacja, oraz aktualizacji danych z poziomu globalnego użytkownika. Ze względu na brak globalnego identyfikatora obiektu (obecnego np. w CORBA, ale nie istniejącego obecnie w innych niż obiektowe modelach danych), nie jest możliwe stworzenie generalnej metody modyfikowania zintegrowanych danych. Z tego powodu, choć większość obecnych federacyjnych baz danych bez problemu potrafi udostępniać dane do odczytu, operacje modyfikujące stan poszczególnych baz danych nie są możliwe w ogóle, albo tylko w niektórych przypadkach. Ponieważ interfejs do danych globalnych zwykle w federacyjnych bazach danych definiowany jest jako perspektywa, problem ten można rozszerzyć do dużo szerszego i znanego od wielu lat problemu aktualizacji perspektyw. Perspektywy znane z systemów relacyjnych (traktowane jako zapamiętane zapytynia) umożliwiają tymczasem aktualizację danych wirtualnych tylko w najprostszych przypadkach. Przykładowo, nie można aktualizować danych uzyskanych poprzez złączenie (z kilkoma drobnymi wyjątkami), albo wygenerowanych za pomocą operatorów agregujących. Przezroczystość wszystkich operacji 17

18 realizowanych na perspektywach jest tymczasem szczególnie wymagana w federacyjnej bazie danych, gdzie perspektywy mogą integrować dane z tysięcy źródeł danych. Okazuje się, że rozwiązanie problemu aktualizacji perspektyw musi wiązać się z wprowadzeniem dużo bardziej wyspecjalizowanej struktury pełniącej rolę perspektywy. Takie struktury zaprojektowane zostały dla obiektowych baz danych, i tylko w ich kontekście ich moc może być w pełni wykorzystana. Wiąże się to m.in. z koniecznością rozszerzenia identyfikatora obiektu do postaci umożliwiającej opisywanie wirtualnych danych. Wraz z definiowanymi przez twórców perspektyw generycznymi procedurami przeciążającymi podstawowe operacje na wirtualnych obiektach, identyfikatorami posiadającymi informację na temat perspektywy, oraz zapytania za pomocą którego obiekty wirtualne są generowane, perspektywy takie umożliwiają modyfikację dowolnych danych wirtualnych. Strategie integracyjne Specjaliści z dziedziny EAI zgodni są w jednej kwestii - żadna istniejąca obecnie metoda integracji, czy też technologia nie jest złotym środkiem na każdy problem integracyjny [3, 11, 102]. Przykładowo, dla pewnej organizacji, niezbędna może być integracja danych zawartych w jej bazach danych. Organizacja ta wymaga nieograniczonego dostępu do wszystkich swoich danych i nie jest w stanie przewidzieć wszystkich ścieżek dostępu teraz lub w przyszłości. Ponieważ zgodnie np. z architekturą SOA dostęp do nowego zbioru danych wiąże się z budową nowej usługi, oznacza to w takiej sytuacji każdorazową modyfikację systemu docelowego, co z różnych powodów (np. koszt) może być nieakceptowalne. Federacyjna baza danych jest więc tutaj najlepszym rozwiązaniem. Podobny problem może jednak nie dotyczyć takiej organizacji, która może skoncentrować się na integracji logiki aplikacji, a nie przetwarzaniu rozproszonych danych. Poszczególne operacje możliwe do realizacji na zintegrowanych systemach należących do tej organizacji są dobrze znane, a ich interfejsy mają charakter statyczny. Dla takiej organizacji tak niskopoziomowa integracja, jaką jest integracja danych, może okazać się zbyt skomplikowana. Możliwe dla niej jest zatem wydzielenie dobrze zdefiniowanej funkcjonalności każdego z integrowanych systemów i globalne ich opublikowanie jako usługi. Stworzony w ten sposób zbiór usług może stać się następnie podstawą do integracji procesów biznesowych zachodzących w ramach takiej organizacji. Taka wysokopoziomowa (i pożądana z punktu widzenia biznesu) integracja nie może być z kolei wykorzystana w przypadku pierwszej z wymienionych organizacji. 18

19 Zauważmy, iż obecnie obie opisane wyżej organizacje do osiągnięcia swoich celów musiałyby używać różnego zestawu narzędzi. Pierwsza z nich prawdopodobnie wykorzystałaby jakąś relacyjną bazę danych umożliwiającą budowę federacyjnych baz danych (np. DB2 z wbudowanym modułem Garlic), a druga - rozproszonych obiektów, middleware zorientowanego na komunikaty, albo WebServices. Naszym zdaniem wszystkie te rozwiązania możliwe są do wyrażenia za pomocą obiektowej bazy danych zintegrowanej z językiem zapytań rozszerzonym do kompletnego języka programowania. Narzędzie takie wykorzystane jako middleware może wnieść zupełnie nową jakość do tematyki integracji aplikacji. Możliwość wykorzystania tego samego narzędzia do zrealizowania różnych strategii integracyjnych powinna zwiększyć produktywność programistów, ograniczyć koszty wytwarzania oprogramowania, skrócić czas nauki oraz zredukować liczbę struktur, koncepcji i mechanizmów niezbędnych do opanowania przez programistów. W tej pracy skoncentrujemy na zaprojektowaniu architektury takiego narzędzia. Cel pracy doktorskiej Podstawowym celem rozprawy doktorskiej jest zbadanie nowych paradygmatów ułatwiających proces implementacji systemów informatycznych. Zaprojektowana zostanie nowa metodologia tworzenia aplikacji baz danych, wraz z prototypowym narzędziem, umożliwiającym pracę programiście bazodanowemu na znacznie wyższym poziomie, niż umożliwiają to współczesne rozwiązania. W tym celu stworzony zostanie nowy, obiektowy język programowania, bezszwowo zintegrowany z konstrukcjami języka zapytań (zapytania jako wyrażenia), razem z jego rozproszonym, bazodanowo zorientowanym, obiektowym środowiskiem wykonawczym. Technologia ta zapewniać będzie funkcjonalność wielu istniejących narzędzi (takich jak np. języki programowania aplikacji baz danych, języki zapytań do baz danych, systemy zarządzania bazami danych, różnego rodzaju middleware) w jednym, spójnym, uniwersalnym, łatwym do wykorzystania i efektywnym w użyciu środowisku programistycznym. Będzie to jednocześnie propozycja nowej architektury obiektowych baz danych, konkurencyjna wobec istniejących architektur obiektowych i relacyjnych SZBD. Najważniejszym zadaniem takiego środowiska programistycznego będzie integracja rozproszonych zasobów rozumianych jako dane, dlatego zagadnienie to stanowić będzie najpoważniejszy fragment rozprawy. Integracja danych zrealizowana zostanie za pomocą koncepcji znanej pod nazwą wirtualnego repozytorium. Zgodnie z tą koncepcją, wszystkie składniki systemu informatycznego 19

20 widziane będą jako jedna, wirtualna, rozproszona baza danych i usług, dostępna za pomocą języka zapytań. Zapewnienie odpowiedniego stopnia przezroczystości (przezroczystość danych/usług, współbieżności, heterogeniczności, skalowania, fragmentacji, replikacji, migracji, optymalizacji, itp.) niezbędnego w wirtualnym repozytorium osiągalne będzie w satysfakcjonującym stopniu jedynie wówczas, gdy programista aplikacyjny zwolniony zostanie z ich ręcznego zaprogramowania za pomocą języka ogólnego przeznaczenia (jak to ma miejsce w typowych rozwiązaniach). Zamiast tego, za ich realizację odpowiedzialny powinien być system zarządzania bazą danych sterowany za pomocą bardzo wysokopoziomowych konstrukcji deklaratywnych. Aby korzystać z wirtualnego repozytorium, programista nie będzie zatem zmuszony do posługiwania się złożonym API udostępnianym przez obecne middleware. Zamiast tego, pozwolimy mu pracować na znacznie wyższym poziomie abstrakcji, ukrywając złożoność procesów komunikacyjnych, mechanizmów bezpieczeństwa, transakcyjności i optymalizacji. Najważniejszą zaletą naszego wirtualnego repozytorium będzie możliwość aktualizacji danych z poziomu globalnego użytkownika. Właściwość tę osiągniemy poprzez wykorzystanie w pełni aktualizowalnych perspektyw, wykorzystywanych jako osłony/mediatory i nie mających precedensu w istniejących rozwiązaniach z dziedziny integracji danych i aplikacji. Zaproponowane przez nas narzędzie posiadało będzie potencjał zostania samodzielnym środowiskiem programistycznym, dostarczającym możliwości budowy aplikacji baz danych oraz samych baz danych. Integracja danych i aplikacji zbudowanych za pomocą wyłącznie tego środowiska będzie najbardziej pożądaną sytuacją, najmniej pracochłonną programistycznie. Rzeczywiste, rozproszone systemy informatyczne składają się jednak z wielu różnych elementów zbudowanych przy użyciu setek technologii pojawiających się i znikających na przestrzeni lat. Ze względu na koszty, jakie ponoszą organizacje przy wdrażaniu poszczególnych składników takich systemów, ich przepisanie w nowym języku programowania, a często nawet drobna modyfikacja, jest zwykle nierealne. Oznacza to, iż wirtualne repozytorium musi posiadać możliwość integracji zasobów spadkowych o heterogenicznym charakterze. Cel ten zostanie zrealizowany zgodnie z regułami przyjętymi dla federacyjnych baz danych. Zaprojektowany zatem zostanie kanoniczny model danych zdolny reprezentować popularne modele danych wykorzystywanych we współczesnych bazach danych i językach programowania. Ten kanoniczny model danych obowiązywać będzie w całym wirtualnym repozytorium, a każdy integrowany zasób (np. relacyjna baza danych) będzie mógł być wyrażany w jego kategoriach za pomocą zestawu osłon (adapterów) lub filtrów (importerów). Dodatkowe różnice w schematach poszczególnych żródeł danych oraz 20

21 reprezentacji danych (np. różne waluty) rozwiązywane będą za pomocą aktualizowalnych perspektyw pełniących rolę mediatorów. W szczególności, osobna taka perspektywa będzie mogła zostać zdefiniowana dla każdego systemu kontrybuującego do repozytorium (tzw. perspektywa kontrybucyjna) oraz globalna perspektywa prezentująca zawartość całego systemu jako wirtualną całość (tzw. perspektywa integracyjna). Globalny użytkownik korzystał będzie z repozytorium za pomocą jednego języka zapytań (rozszerzonego do języka programowania), niezależnie od tego gdzie fizycznie znajdować się będą integrowane dane/usługi, oraz jakie technologie zostały użyte do ich wygenerowania. Ponieważ tak utworzona rozproszona baza danych widziana jest przez zewnętrznego użytkownika jako pojedyncza, wirtualna baza danych, istnieje także możliwość zbudowania dla niej tradycyjnych interfejsów dostępowych, np. JDBC, czy WebServices. W ten sposób, technologia ta zgodna będzie z przyjętymi w przemyśle standardami, ale jednocześnie niezależna od nich. W niniejszej pracy nie będziemy jednak zajmowali się konstrukcją takich interfejsów dostępowych, ani (w szczególności) wrapperów. Konstrukcja takich modułów (np. osłony do relacyjnej bazy danych) jest zadaniem nietrywialnym i stanowi treść osobnych prac doktorskich. Język programowania/zapytań zaproponowany w rozprawie bazuje na podejściu stosowym (Stack- Based Approach, SBA) do języków zapytań. SBA jest semantyczną ramą ułatwiającą budowę mocnego języka zapytań dla praktycznie dowolnego znanego modelu danych, niezależnie od tego czy jest to model półstrukturalny (np. XML), ustrukturalizowany (np. relacyjna baza danych), czy nieustrukturalizowany (np. dane multimedialne). Przykładowo, obsługa danych XML zapewniona jest poprzez możliwość zaimportowania zawartości dowolnego dokumentu do bazy danych i wyrażenia jego treści w terminach obiektów tej bazy danych. Na takich danych można następnie pracować w taki sposób, jak gdyby były to natywne dane zdefiniowane za pomocą języka definicji danych wbudowanego w SZBD. Budowa kompletnego języka programowania bezszwowo zintegrowanego z konstrukcjami języka zapytań możliwa jest dzięki temu, iż w podejściu stosowym zapytania traktowane są tak, jak wyrażenia w tradycyjnych językach programowania. Semantyka zapytań jest zatem oparta na mechanizmach dobrze znanych z typowych języków - stosie środowisk, stosie arytmetycznym oraz paradygmacie nazwa-zakres-wiązanie. Pozwala to na precyzyjne określenie semantyki operacyjnej języków zapytań z uwzględnieniem cech obiektowości (np. klasy, dynamiczne role obiektów), konstrukcji imperatywnych i abstrakcji programistycznych (np. procedur, perspektyw, modułów). 21

22 Wykorzystanie SBA umożliwi nam znaczną redukcję liczby języków, z jakimi ma do czynienia typowy programista baz danych. W idealnej sytuacji może to być jeden język przeznaczony do programowania aplikacji, definiowania schematu bazy danych, wykonywania zapytań, transformowania danych, itd. Najważniejsze aspekty technologii zaprezentowanej w rozprawie zaimplementowane zostały w postaci prototypu. Jest on podstawowym komponentem systemów e-govbus oraz VIDE, realizowanych przez PJWSTK wspólnie z partnerami, oraz finansowanych w ramach grantów przyznanych przez Unię Europejską. Teza rozprawy doktorskiej Koncepcja wirtualnego repozytorium oparta na jednorodnym obiektowym środowisku programistycznym bazującym na języku zapytań zintegrowanym z językiem programowania jest alternatywą dla wielu obecnie popularnych, eklektycznych technologii. Koncepcja ta potwierdzona została poprzez stworzone oprogramowanie. Jest ono zatem dowodem tezy naukowej dektoratu mówiącej o tym, iż jest możliwe stworzenie metodologii oraz odpowiednich dla niej narzędzi programistych (opartych o zintegrowany język zapytań/programowania), które pozwalą na szybką i tanią budowę wirtualnego repozytorium opartego o kanoniczny model obiektowy. Zadaniem takiego repozytorium jest integracja danych i aplikacji znajdujących się pod kontrolą tych samych lub niezależnych od siebie organizacji, a także umożliwienie szybkiego programowania wydajnych aplikacji baz danych na bardzo wysokim poziomie abstrakcji. Podsumowanie W rozdziale krótko przedstawiliśmy problemy wiążące się z integracją danych i aplikacji w systemach rozproszonych. Przedstawiliśmy w nim nasze stanowisko mówiące o tym, iż obiektowa baza danych z wbudowanym językiem zapytań zintegrowanym z językiem programowania stanowi potencjalne narzędzie do budowy zintegrowanych baz danych oraz ich aplikacji. Dzięki pełnej mocy obliczeniowej porównywalnej z istniejącymi językami programowania, obiektowa baza danych tego typu jest w stanie przykryć funkcjonalnością dowolny istniejący współcześnie rodzaje middleware, a także niektóre języki programowania czwartej generacji. Poprzez zastosowanie w pełni aktualizowalnych perspektyw, system tego typu może również służyć do budowy federacyjnych baz danych. Tak zbudowana baza danych pozbawiona jest dwóch poważnych problemów związanych z takimi bazami danych jeśli realizowane są przy użyciu relacyjnych baz danych: 22

23 1. uproszczonego modelu danych implikowanego przez relacyjny model danych, 2. braku możliwości aktualizacji sfederowanych zasobów danych od strony globalnego klienta. Przedstawiliśmy również cel niniejszej pracy doktorskiej, której zamierzeniem jest zaprojektowanie architektury obiektowej bazy danych nowego typu, jak również zaimplementowanie jej prototypu. 23

24

25 Rozdział 2: Stan sztuki w dziedzinie integracji danych i aplikacji Wprowadzenie W bieżącym rozdziale krótko omówimy najważniejsze teorie, techniki, technologie i inne rozwiązania związane z integracją danych i aplikacji. Ponieważ w niniejszej pracy będziemy dowodzili, iż obiektowa baza danych jest doskonałym narzędziem dla EAI/EII, zanim przejdziemy do dokładniejszego opisu naszej koncepcji, postaramy się pokazać dlaczego naszym zdaniem istniejące techniki programowania aplikacji baz danych powinny zostać w dużej części przedefiniowane. W naszym opisie skoncentrujemy się na trzech aspektach integracyjnych: integracji języków programowania z bazami danych za pomocą języków zapytań, metodach zapewniania komunikacji pomiędzy heterogenicznymi aplikacjami, oraz deklaratywnych sposobach integracji różnorodnych baz danych. Integracja baz danych z językami programowania Metody integracji języków programowania z bazami danych studiowane są od wielu lat. W związku z tym, iż ogólnie przyjętym mechanizmem operowania na bazach danych jest język zapytań, integracja baz danych z językami programowania wiąże się zazwyczaj z integracją języka imperatywnego ogólnego przeznaczenia z językiem deklaratywnym operującym na bazie danych. 25

26 Najbardziej popularna klasyfikacja metod integracji języków programowania z bazami danych oparta jest na dwóch metodach. Pierwsze z tych podejść, tzn. zanurzanie jako literałów kodu języka zapytań w kodzie języka programowania, obarczone są poważną wadą znaną pod nazwą niezgodność impedancji. Alternatywne podejścia (np. Pascal/R [43], Napier88 [44], DBPL [41], LOQIS [31], Fibonacci [28], Oracle PL/SQL) w dużym stopniu pozbawione są tej wady, ponieważ dążą one do stworzenia jednolitego środowiska programistycznego, a konstrukcje imperatywne zintegrowane są z konstrukcjami deklaratywnymi. Poniżej przedstawimy krótki, krytyczny opis najbardziej znanych podejść w dziedzinie integracji języków zapytań z językami programowania. Interfejs poziomu wywołań Najbardziej znanym sposobem dostępu do baz danych jest tzw. interfejs poziomu wywołań (Call Level Interface, CLI). Technika ta polega na zagniedżaniu kodu języka zapytań odpowiedzialnego za operacje realizowane na bazie danych jako literały łańcuchów znaków w kodzie źródłowym programów napisanych w językach proceduralnych, a następnie użyciu pewnej bazodanowej warstwy pośredniej (database middleware) dostępnej jako API. Poniższy kod w języku Java ilustruje sposób korzystania z interfejsu poziomu wywołań. Fragment ten odpowiedzialny jest za wysłanie zapytania SELECT * FROM MyTable do bazy danych, a następnie wyświetlenie na ekranie wszystkich wierszy i kolumn tabeli wynikowej. Statement stmt = conn.createstatement(); try { ResultSet rs = stmt.executequery("select * FROM MyTable"); try { while (rs.next()) { int numcolumns = rs.getmetadata().getcolumncount(); for (int i = 1 ; i <= numcolumns ; i++) System.out.println("COLUMN " + i + " = " + rs.getobject(i)); finally { rs.close(); finally { stmt.close(); Na przestrzeni lat podejście takie zostało mocno skrytykowane jako uniemożliwiające statyczną kontrolę typów zapytań (literały Javy nie są dostępne dla kompilatora SQL), wymagające konwersji 26

27 typów języka programowania na typy bazy danych, stanowiące zagrożenie dla bezpieczeństwa systemu (tzw. sql injection), uniemożliwiające operacje wspomagania programowania realizowane przez środowiska programistyczne (refaktoryzacja, podpowiadanie nazw) i inne. Niedogodności te próbowano ominąć wprowadzając dodatkowy etap kompilacji za pomocą tzw. prekompilatora (np. SQLJ), analizującego specjalne bloki kodu źródłowego z zawartością będącą kodem rozpoznawanym przez prekompilator. Prekompilator zdolny jest analizować wnętrze takich specjalnych klauzul, kontrolować poprawność odwołań zarówno do Javy, jak i do bazy danych, a także automatycznie zamieniać wnętrze tych klauzul na odpowiednie wywołania CLI (w przypadku SQLJ na kod Javy używający JDBC). Niestety okazało się że podejście to jest niewystarczające. Języki z trwałością Języki z trwałością należą do dosyć istotnego nurtu bliskiego bazom danych. Aczkolwiek eksperymentalne projekty (np. Fibonacci [28], PS-Algol [57], DBPL [41], Napier88 [44], Machiavelli [46], PJama [23], i in.) stworzone w ubiegłej dekadzie nie zdobyły popularności poza laboratoriami w których powstały, odegrały one silny wpływ na architekturę obiektowych baz danych. Języki te były zwykle rozszerzonymi tradycyjnymi językami programowania (np. PJama jest rozszerzeniem Javy, a DBPL Moduli2) wprowadzającymi pojęcie trwałych zmiennych/ obiektów. Trwała zmienna to taka, która ma wszystkie własności zmiennej języka programowania, ale zachowuje swoją wartość pomiędzy kolejnymi uruchomieniami programu. Uważano że dzięki takiemu podejściu dowolne bazy danych można traktować jako zestawy trwałych zmiennych. Prawdopodobnie najpoważniejszym wkładem tych języków w dziedzinę obiektowych baz danych stało się pojęcie ortogonalnej trwałości. Koncepcja ortogonalnej trwałości mówi, iż programista nigdy nie powinien być zmuszany do tworzenia kodu odpowiedzialnego za przenoszenie danych pomiędzy trwałym i ulotnym składem danych. Zakładająca pełną unifikację definicji i środków manipulacji trwałymi i ulotnymi danymi, koncepcja ta stanowiła ogromny postęp w zakresie abstrakcji i estetycznego domknięcia pojęć. Przykładowo, projekt PJama zakładał, iż programista nie musi w ogóle korzystać z żadnego API zapewniającego trwałość, gdyż jest ona zapewniana na poziomie systemowym i dotyczy wszystkich zmiennych globalnych. System zapewnia zatem iluzję ciągłej pracy oprogramowania, nawet pomimo zamierzonych lub niezamierzonych wyłączeń. Cel ten próbowano osiągnąć poprzez rozszerzenie funkcjonalności wirtualnej maszyny języka Java w taki sposób, aby w trakcie wystąpienia tzw. punktu kontrolnego bieżący stan aplikacji 27

28 (danych i procesów) był utrwalany. Utrwalone zostają jedyne te dane, które od czasu ostatniego punktu kontrolnego zostały zmodyfikowane. Gdy nastąpi punkt kontrolny, system jest zamrażany, a wirtualna maszyna analizuje całe drzewo obiektów sterty w poszukiwaniu takich obiektów. Po zatrzymaniu aplikacji i jej ponownym uruchomieniu tak zmodyfikowana maszyna potrafi kontynuować przetwarzanie od momentu w którym jego stan został utrwalony w trakcie ostatniego punktu kontrolnego. W innych językach z trwałością stosowano mniej lub bardziej podobne metody utrwalania danych. W większości projektów koncentrowano się na zbudowaniu nowego języka (często z bardzo wymyślną semantyką i systemem typów), albo rozszerzeniu istniejącego o aspekt trwałości, całkowicie ignorując wiążące się z tym implikacje wynikające z konieczności przetwarzania danych masowych. Żaden ze stworzonych w ten sposób języków nie pozwalał na wykorzystywanie typowo bazodanowych konstrukcji, np. indeksów, perspektyw, czy wyzwalaczy. Większość języków z trwałością nie obsługuje również innych krytycznych dla baz danych mechanizmów, np. transakcji, dzienników, dynamicznej optymalizacji, współbieżnego dostępu wielu równoległych sesji, kont użytkowników, uprawnień, itd. Tylko w niewielkiej grupie języków wprowadzone zostały konstrukcje deklaratywne, niezbędne do wygodnego operowania na danych masowych. Niestety, zazwyczaj konstrukcje te były nieortogonalne z resztą języka. Przykładowo, w systemie DBPL można korzystać z języka zapytań, ale tylko w stosunku do specjalnego rodzaju zmiennych zadeklarowanych jako (zagnieżdżone) relacje (próba połączenia języka programowania z modelem relacyjnym). Wyjątkiem był tu jedynie system Loqis [30, 31], w którym przyjęto jednak zupełnie inne założenia. Zamiast rozszerzać język proceduralny o konstrukcje charakterystyczne dla baz danych, rozszerzono bazę danych oraz jej język zapytań o konstrukcje charakterystyczne dla proceduralnych języków programowania. Dosyć podobne podejście (aczkolwiek w nieporównywalnie mniejszym stopniu) dotyczy języka PL/SQL firmy Oracle. Odwzorowanie relacyjno-obiektowe Odwzorowanie relacyjno-obiektowe jest innym rodzajem integracji aplikacji z bazą danych. Celem tej techniki jest stworzenie wirtualnej obiektowej bazy danych na bazie relacyjnej bazy danych oraz obiektowego języka programowania. Zdaniem zwolenników tej metody umożliwia to wykorzystanie istniejących relacyjnych baz danych i obiektowych języków programowania w sposób obiektowy, czyli bez pracochłonnego tłumaczenia struktur relacyjnych na struktury 28

Wykład I. Wprowadzenie do baz danych

Wykład I. Wprowadzenie do baz danych Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles

Bardziej szczegółowo

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe.

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. Warstwa integracji wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. 1. Ukrycie logiki dostępu do danych w osobnej warstwie 2. Oddzielenie mechanizmów trwałości od modelu obiektowego Pięciowarstwowy

Bardziej szczegółowo

Bazy danych 2. Wykład 1

Bazy danych 2. Wykład 1 Bazy danych 2 Wykład 1 Sprawy organizacyjne Materiały i listy zadań zamieszczane będą na stronie www.math.uni.opole.pl/~ajasi E-mail: standardowy ajasi@math.uni.opole.pl Sprawy organizacyjne Program wykładu

Bardziej szczegółowo

Programowanie obiektowe

Programowanie obiektowe Programowanie obiektowe Wykład 13 Marcin Młotkowski 27 maja 2015 Plan wykładu Trwałość obiektów 1 Trwałość obiektów 2 Marcin Młotkowski Programowanie obiektowe 2 / 29 Trwałość (persistence) Definicja Cecha

Bardziej szczegółowo

Podyplomowe Studium Informatyki w Bizniesie Wydział Matematyki i Informatyki, Uniwersytet Łódzki specjalność: Tworzenie aplikacji w środowisku Oracle

Podyplomowe Studium Informatyki w Bizniesie Wydział Matematyki i Informatyki, Uniwersytet Łódzki specjalność: Tworzenie aplikacji w środowisku Oracle Podyplomowe Studium Informatyki w Bizniesie Wydział Matematyki i Informatyki, Uniwersytet Łódzki specjalność: Tworzenie aplikacji w środowisku Oracle EFEKTY KSZTAŁCENIA Wiedza Absolwent tej specjalności

Bardziej szczegółowo

Temat : SBQL 1 obiektowy język zapytań.

Temat : SBQL 1 obiektowy język zapytań. Laboratorium Języki i środowiska przetwarzania danych rozproszonych Temat : SBQL 1 obiektowy język zapytań. Historia zmian Data Wersja Autor Opis zmian 23.4.2012 1.0 Tomasz Kowalski Utworzenie dokumentu

Bardziej szczegółowo

Modelowanie i Programowanie Obiektowe

Modelowanie i Programowanie Obiektowe Modelowanie i Programowanie Obiektowe Wykład I: Wstęp 20 październik 2012 Programowanie obiektowe Metodyka wytwarzania oprogramowania Metodyka Metodyka ustandaryzowane dla wybranego obszaru podejście do

Bardziej szczegółowo

Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski. Bazy danych ITA-101. Wersja 1

Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski. Bazy danych ITA-101. Wersja 1 Włodzimierz Dąbrowski, Przemysław Kowalczuk, Konrad Markowski Bazy danych ITA-101 Wersja 1 Warszawa, wrzesień 2009 Wprowadzenie Informacje o kursie Opis kursu We współczesnej informatyce coraz większą

Bardziej szczegółowo

Systemy baz danych w zarządzaniu przedsiębiorstwem. W poszukiwaniu rozwiązania problemu, najbardziej pomocna jest znajomość odpowiedzi

Systemy baz danych w zarządzaniu przedsiębiorstwem. W poszukiwaniu rozwiązania problemu, najbardziej pomocna jest znajomość odpowiedzi Systemy baz danych w zarządzaniu przedsiębiorstwem W poszukiwaniu rozwiązania problemu, najbardziej pomocna jest znajomość odpowiedzi Proces zarządzania danymi Zarządzanie danymi obejmuje czynności: gromadzenie

Bardziej szczegółowo

Bazy danych. Zenon Gniazdowski WWSI, ITE Andrzej Ptasznik WWSI

Bazy danych. Zenon Gniazdowski WWSI, ITE Andrzej Ptasznik WWSI Bazy danych Zenon Gniazdowski WWSI, ITE Andrzej Ptasznik WWSI Wszechnica Poranna Trzy tematy: 1. Bazy danych - jak je ugryźć? 2. Język SQL podstawy zapytań. 3. Mechanizmy wewnętrzne baz danych czyli co

Bardziej szczegółowo

1 Wprowadzenie do J2EE

1 Wprowadzenie do J2EE Wprowadzenie do J2EE 1 Plan prezentacji 2 Wprowadzenie do Java 2 Enterprise Edition Aplikacje J2EE Serwer aplikacji J2EE Główne cele V Szkoły PLOUG - nowe podejścia do konstrukcji aplikacji J2EE Java 2

Bardziej szczegółowo

Podstawowe pojęcia dotyczące relacyjnych baz danych. mgr inż. Krzysztof Szałajko

Podstawowe pojęcia dotyczące relacyjnych baz danych. mgr inż. Krzysztof Szałajko Podstawowe pojęcia dotyczące relacyjnych baz danych mgr inż. Krzysztof Szałajko Czym jest baza danych? Co rozumiemy przez dane? Czym jest system zarządzania bazą danych? 2 / 25 Baza danych Baza danych

Bardziej szczegółowo

INFORMATYKA Pytania ogólne na egzamin dyplomowy

INFORMATYKA Pytania ogólne na egzamin dyplomowy INFORMATYKA Pytania ogólne na egzamin dyplomowy 1. Wyjaśnić pojęcia problem, algorytm. 2. Podać definicję złożoności czasowej. 3. Podać definicję złożoności pamięciowej. 4. Typy danych w języku C. 5. Instrukcja

Bardziej szczegółowo

Projektowanie architektury systemu rozproszonego. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Projektowanie architektury systemu rozproszonego. Jarosław Kuchta Projektowanie Aplikacji Internetowych Projektowanie architektury systemu rozproszonego Jarosław Kuchta Zagadnienia Typy architektury systemu Rozproszone przetwarzanie obiektowe Problemy globalizacji Problemy ochrony Projektowanie architektury

Bardziej szczegółowo

Czym jest Java? Rozumiana jako środowisko do uruchamiania programów Platforma software owa

Czym jest Java? Rozumiana jako środowisko do uruchamiania programów Platforma software owa 1 Java Wprowadzenie 2 Czym jest Java? Język programowania prosty zorientowany obiektowo rozproszony interpretowany wydajny Platforma bezpieczny wielowątkowy przenaszalny dynamiczny Rozumiana jako środowisko

Bardziej szczegółowo

Problemy optymalizacji, rozbudowy i integracji systemu Edu wspomagającego e-nauczanie i e-uczenie się w PJWSTK

Problemy optymalizacji, rozbudowy i integracji systemu Edu wspomagającego e-nauczanie i e-uczenie się w PJWSTK Problemy optymalizacji, rozbudowy i integracji systemu Edu wspomagającego e-nauczanie i e-uczenie się w PJWSTK Paweł Lenkiewicz Polsko Japońska Wyższa Szkoła Technik Komputerowych Plan prezentacji PJWSTK

Bardziej szczegółowo

Typy przetwarzania. Przetwarzanie zcentralizowane. Przetwarzanie rozproszone

Typy przetwarzania. Przetwarzanie zcentralizowane. Przetwarzanie rozproszone Typy przetwarzania Przetwarzanie zcentralizowane Systemy typu mainfame Przetwarzanie rozproszone Architektura klient serwer Architektura jednowarstwowa Architektura dwuwarstwowa Architektura trójwarstwowa

Bardziej szczegółowo

Usługi analityczne budowa kostki analitycznej Część pierwsza.

Usługi analityczne budowa kostki analitycznej Część pierwsza. Usługi analityczne budowa kostki analitycznej Część pierwsza. Wprowadzenie W wielu dziedzinach działalności człowieka analiza zebranych danych jest jednym z najważniejszych mechanizmów podejmowania decyzji.

Bardziej szczegółowo

Programowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Opracował Jan T. Biernat

Programowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Opracował Jan T. Biernat Programowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Program, to lista poleceń zapisana w jednym języku programowania zgodnie z obowiązującymi w nim zasadami. Celem programu jest przetwarzanie

Bardziej szczegółowo

Virtual Grid Resource Management System with Virtualization Technology

Virtual Grid Resource Management System with Virtualization Technology Virtual Grid Resource Management System with Virtualization Technology System zarządzania zasobami wirtualnego Gridu z wykorzystaniem technik wirtualizacji Joanna Kosińska Jacek Kosiński Krzysztof Zieliński

Bardziej szczegółowo

SPOSOBY POMIARU KĄTÓW W PROGRAMIE AutoCAD

SPOSOBY POMIARU KĄTÓW W PROGRAMIE AutoCAD Dr inż. Jacek WARCHULSKI Dr inż. Marcin WARCHULSKI Mgr inż. Witold BUŻANTOWICZ Wojskowa Akademia Techniczna SPOSOBY POMIARU KĄTÓW W PROGRAMIE AutoCAD Streszczenie: W referacie przedstawiono możliwości

Bardziej szczegółowo

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

Organizacja zajęć BAZY DANYCH II WYKŁAD 1. Plan wykładu. SZBD Oracle 2010-10-21

Organizacja zajęć BAZY DANYCH II WYKŁAD 1. Plan wykładu. SZBD Oracle 2010-10-21 Organizacja zajęć BAZY DANYCH II WYKŁAD 1 Wykładowca dr inż. Agnieszka Bołtuć, pokój 304, e-mail: aboltuc@ii.uwb.edu.pl Liczba godzin i forma zajęć: 15 godzin wykładu oraz 30 godzin laboratorium Konsultacje:

Bardziej szczegółowo

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Jerzy Brzeziński, Anna Kobusińska, Dariusz Wawrzyniak Instytut Informatyki Politechnika Poznańska Plan prezentacji 1 Architektura

Bardziej szczegółowo

Paweł Kurzawa, Delfina Kongo

Paweł Kurzawa, Delfina Kongo Paweł Kurzawa, Delfina Kongo Pierwsze prace nad standaryzacją Obiektowych baz danych zaczęły się w roku 1991. Stworzona została grupa do prac nad standardem, została ona nazwana Object Database Management

Bardziej szczegółowo

SZKOLENIE: Administrator baz danych. Cel szkolenia

SZKOLENIE: Administrator baz danych. Cel szkolenia SZKOLENIE: Administrator baz danych. Cel szkolenia Kurs Administrator baz danych skierowany jest przede wszystkim do osób zamierzających rozwijać umiejętności w zakresie administrowania bazami danych.

Bardziej szczegółowo

ZMODYFIKOWANY Szczegółowy opis przedmiotu zamówienia

ZMODYFIKOWANY Szczegółowy opis przedmiotu zamówienia ZP/ITS/11/2012 Załącznik nr 1a do SIWZ ZMODYFIKOWANY Szczegółowy opis przedmiotu zamówienia Przedmiotem zamówienia jest: Przygotowanie zajęć dydaktycznych w postaci kursów e-learningowych przeznaczonych

Bardziej szczegółowo

Zaawansowane narzędzia programowania rozproszonego

Zaawansowane narzędzia programowania rozproszonego Zaawansowane narzędzia programowania rozproszonego Karol Gołąb karol.golab@tls-technologies.com 28 listopada 2001 1 Streszczenie Omówienie i porównanie popularnych standardów mechanizmów komunikacyjnych:

Bardziej szczegółowo

Oracle11g: Wprowadzenie do SQL

Oracle11g: Wprowadzenie do SQL Oracle11g: Wprowadzenie do SQL OPIS: Kurs ten oferuje uczestnikom wprowadzenie do technologii bazy Oracle11g, koncepcji bazy relacyjnej i efektywnego języka programowania o nazwie SQL. Kurs dostarczy twórcom

Bardziej szczegółowo

Projektowanie aplikacji z bazami danych

Projektowanie aplikacji z bazami danych Systemy mapowania relacyjno-obiektowego Instytut Informatyki Uniwersytet Wrocławski Plan wykładu Wprowadzenie do trwałości Niedopasowanie paradygmatów Architektura warstwowa Czym jest ORM? Problemy i pytania

Bardziej szczegółowo

Analiza i projektowanie aplikacji Java

Analiza i projektowanie aplikacji Java Analiza i projektowanie aplikacji Java Modele analityczne a projektowe Modele analityczne (konceptualne) pokazują dziedzinę problemu. Modele projektowe (fizyczne) pokazują system informatyczny. Utrzymanie

Bardziej szczegółowo

Transformacja wiedzy w budowie i eksploatacji maszyn

Transformacja wiedzy w budowie i eksploatacji maszyn Uniwersytet Technologiczno Przyrodniczy im. Jana i Jędrzeja Śniadeckich w Bydgoszczy Wydział Mechaniczny Transformacja wiedzy w budowie i eksploatacji maszyn Bogdan ŻÓŁTOWSKI W pracy przedstawiono proces

Bardziej szczegółowo

Podstawy programowania

Podstawy programowania Podstawy programowania Część pierwsza Od języka symbolicznego do języka wysokiego poziomu Autor Roman Simiński Kontakt roman.siminski@us.edu.pl www.us.edu.pl/~siminski Niniejsze opracowanie zawiera skrót

Bardziej szczegółowo

Programowanie obiektowe. Wprowadzenie

Programowanie obiektowe. Wprowadzenie 1 Programowanie obiektowe Wprowadzenie 2 Programowanie obiektowe Object-oriented programming Najpopularniejszy obecnie styl (paradygmat) programowania Rozwinięcie koncepcji programowania strukturalnego

Bardziej szczegółowo

INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE

INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE Studia podyplomowe dla nauczycieli INFORMATYKA, TECHNOLOGIA INFORMACYJNA ORAZ INFORMATYKA W LOGISTYCE Przedmiot JĘZYKI PROGRAMOWANIA DEFINICJE I PODSTAWOWE POJĘCIA Autor mgr Sławomir Ciernicki 1/7 Aby

Bardziej szczegółowo

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus Automatyzacja procesów biznesowych Andrzej Sobecki ESB Enterprise service bus Plan prezentacji Zdefiniowanie problemu Możliwe rozwiązania Cechy ESB JBI Normalizacja wiadomości w JBI Agile ESB Apache ServiceMix

Bardziej szczegółowo

poziom: Core wersja: 2.6 moduł: B : Wytwarzanie SYLLABUS

poziom: Core wersja: 2.6 moduł: B : Wytwarzanie SYLLABUS poziom: Core wersja: 2.6 moduł: B : Wytwarzanie SYLLABUS Niniejszy dokument jest syllabusem obowiązującym dla certyfikatu EUCIP ver. 2.6. Prezentuje obszary wiedzy, których znajomość jest niezbędna do

Bardziej szczegółowo

Hurtownie danych - przegląd technologii

Hurtownie danych - przegląd technologii Hurtownie danych - przegląd technologii Problematyka zasilania hurtowni danych - Oracle Data Integrator Politechnika Poznańska Instytut Informatyki Robert.Wrembel@cs.put.poznan.pl www.cs.put.poznan.pl/rwrembel

Bardziej szczegółowo

Tworzenie aplikacji bazodanowych

Tworzenie aplikacji bazodanowych Wydział Informatyki Politechnika Białostocka Studia stacjonarne Tworzenie aplikacji bazodanowych Prowadzący: pokój: E-mail: WWW: Małgorzata Krętowska, Agnieszka Oniśko 206 (Małgorzata Krętowska), 207 (Agnieszka

Bardziej szczegółowo

Plan. Wprowadzenie. Co to jest APEX? Wprowadzenie. Administracja obszarem roboczym

Plan. Wprowadzenie. Co to jest APEX? Wprowadzenie. Administracja obszarem roboczym 1 Wprowadzenie do środowiska Oracle APEX, obszary robocze, użytkownicy Wprowadzenie Plan Administracja obszarem roboczym 2 Wprowadzenie Co to jest APEX? Co to jest APEX? Architektura Środowisko Oracle

Bardziej szczegółowo

Microsoft SQL Server Podstawy T-SQL

Microsoft SQL Server Podstawy T-SQL Itzik Ben-Gan Microsoft SQL Server Podstawy T-SQL 2012 przełożył Leszek Biolik APN Promise, Warszawa 2012 Spis treści Przedmowa.... xiii Wprowadzenie... xv Podziękowania... xix 1 Podstawy zapytań i programowania

Bardziej szczegółowo

SiR_13 Systemy SCADA: sterowanie nadrzędne; wizualizacja procesów. MES - Manufacturing Execution System System Realizacji Produkcji

SiR_13 Systemy SCADA: sterowanie nadrzędne; wizualizacja procesów. MES - Manufacturing Execution System System Realizacji Produkcji System informatyczny na produkcji: Umożliwi stopniowe, ale jednocześnie ekonomiczne i bezpieczne wdrażanie i rozwój aplikacji przemysłowych w miarę zmiany potrzeb firmy. Może adoptować się do istniejącej

Bardziej szczegółowo

Podstawy programowania.

Podstawy programowania. Kod przedmiotu: PPR Podstawy programowania. Rodzaj przedmiotu: kierunkowy; obowiązkowy Wydział: Informatyki Kierunek: Informatyka Specjalność (specjalizacja): - Poziom studiów: pierwszego stopnia Profil

Bardziej szczegółowo

Programowanie MorphX Ax

Programowanie MorphX Ax Administrowanie Czym jest system ERP? do systemu Dynamics Ax Obsługa systemu Dynamics Ax Wyszukiwanie informacji, filtrowanie, sortowanie rekordów IntelliMorph : ukrywanie i pokazywanie ukrytych kolumn

Bardziej szczegółowo

Instalacja SQL Server Express. Logowanie na stronie Microsoftu

Instalacja SQL Server Express. Logowanie na stronie Microsoftu Instalacja SQL Server Express Logowanie na stronie Microsoftu Wybór wersji do pobrania Pobieranie startuje, przechodzimy do strony z poradami. Wypakowujemy pobrany plik. Otwiera się okno instalacji. Wybieramy

Bardziej szczegółowo

Opracował: Jan Front

Opracował: Jan Front Opracował: Jan Front Sterownik PLC PLC (Programowalny Sterownik Logiczny) (ang. Programmable Logic Controller) mikroprocesorowe urządzenie sterujące układami automatyki. PLC wykonuje w sposób cykliczny

Bardziej szczegółowo

Bazy danych i ich aplikacje

Bazy danych i ich aplikacje ORAZ ZAPRASZAJĄ DO UDZIAŁU W STUDIACH PODYPLOMOWYCH Celem Studiów jest praktyczne zapoznanie słuchaczy z podstawowymi technikami tworzenia i administrowania bazami oraz systemami informacyjnymi. W trakcie

Bardziej szczegółowo

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ Sprawozdanie z Seminarium Dyplomowego Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Bardziej szczegółowo

SOA Web Services in Java

SOA Web Services in Java Wydział Informatyki i Zarządzania Wrocław,16 marca 2009 Plan prezentacji SOA 1 SOA 2 Usługi Przykłady Jak zacząć SOA Wycinek rzeczywistości Problemy zintegrowanych serwisów : Wycinek Rzeczywistości Zacznijmy

Bardziej szczegółowo

Platformy programistyczne:.net i Java L ABORATORIUM 7,8: HACKATHON - JTTT

Platformy programistyczne:.net i Java L ABORATORIUM 7,8: HACKATHON - JTTT Platformy programistyczne:.net i Java L ABORATORIUM 7,8: HACKATHON - JTTT O co chodzi? - Przypomnienie Hackathon - http://en.wikipedia.org/wiki/hackathon A hackathon is an event in which computer programmers

Bardziej szczegółowo

Monitoring procesów z wykorzystaniem systemu ADONIS

Monitoring procesów z wykorzystaniem systemu ADONIS Monitoring procesów z wykorzystaniem systemu ADONIS BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management

Bardziej szczegółowo

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych Mariusz Trzaska Modelowanie i implementacja systemów informatycznych Notka biograficzna Dr inż. Mariusz Trzaska jest adiunktem w Polsko-Japońskiej Wyższej Szkole Technik Komputerowych, gdzie zajmuje się

Bardziej szczegółowo

Hurtownie danych. Wstęp. Architektura hurtowni danych. http://zajecia.jakubw.pl/hur CO TO JEST HURTOWNIA DANYCH

Hurtownie danych. Wstęp. Architektura hurtowni danych. http://zajecia.jakubw.pl/hur CO TO JEST HURTOWNIA DANYCH Wstęp. Architektura hurtowni. Jakub Wróblewski jakubw@pjwstk.edu.pl http://zajecia.jakubw.pl/hur CO TO JEST HURTOWNIA DANYCH B. Inmon, 1996: Hurtownia to zbiór zintegrowanych, nieulotnych, ukierunkowanych

Bardziej szczegółowo

Technologia informacyjna (IT - Information Technology) dziedzina wiedzy obejmująca:

Technologia informacyjna (IT - Information Technology) dziedzina wiedzy obejmująca: 1.1. Podstawowe pojęcia Technologia informacyjna (IT - Information Technology) dziedzina wiedzy obejmująca: informatykę (włącznie ze sprzętem komputerowym oraz oprogramowaniem używanym do tworzenia, przesyłania,

Bardziej szczegółowo

Wprowadzenie do technologii Business Intelligence i hurtowni danych

Wprowadzenie do technologii Business Intelligence i hurtowni danych Wprowadzenie do technologii Business Intelligence i hurtowni danych 1 Plan rozdziału 2 Wprowadzenie do Business Intelligence Hurtownie danych Produkty Oracle dla Business Intelligence Business Intelligence

Bardziej szczegółowo

DLA SEKTORA INFORMATYCZNEGO W POLSCE

DLA SEKTORA INFORMATYCZNEGO W POLSCE DLA SEKTORA INFORMATYCZNEGO W POLSCE SRK IT obejmuje kompetencje najważniejsze i specyficzne dla samego IT są: programowanie i zarządzanie systemami informatycznymi. Z rozwiązań IT korzysta się w każdej

Bardziej szczegółowo

Alicja Marszałek Różne rodzaje baz danych

Alicja Marszałek Różne rodzaje baz danych Alicja Marszałek Różne rodzaje baz danych Rodzaje baz danych Bazy danych można podzielić wg struktur organizacji danych, których używają. Można podzielić je na: Bazy proste Bazy złożone Bazy proste Bazy

Bardziej szczegółowo

Szczegółowy harmonogram rzeczowy realizacji prac systemu B2B

Szczegółowy harmonogram rzeczowy realizacji prac systemu B2B Szczegółowy harmonogram rzeczowy realizacji prac systemu B2B NAZWA ZADANIA ZADANIE CZĄSTKOWE TECHNOLOGIA ILOŚĆ OSÓB ILOŚĆ GODZIN TERMIN REALIZACJI 1 2 4 5 6 7 Zadanie 1 - wersji alfa 1 systemu B2B 3 723

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: ADMINISTROWANIE INTERNETOWYMI SERWERAMI BAZ DANYCH Kierunek: Informatyka Rodzaj przedmiotu: moduł specjalności obowiązkowy: Programowanie aplikacji internetowych Rodzaj zajęć: wykład,

Bardziej szczegółowo

Oracle Designer. Oracle Designer jest jednym z głównych komponentów pakietu Oracle Developer Suite. Oracle Designer wspiera :

Oracle Designer. Oracle Designer jest jednym z głównych komponentów pakietu Oracle Developer Suite. Oracle Designer wspiera : Oracle Designer Oracle Designer jest jednym z głównych komponentów pakietu Oracle Developer Suite. Oracle Designer wspiera : - modelowanie procesów biznesowych - analizę systemu informatycznego - projektowanie

Bardziej szczegółowo

JAVA. Java jest wszechstronnym językiem programowania, zorientowanym. apletów oraz samodzielnych aplikacji.

JAVA. Java jest wszechstronnym językiem programowania, zorientowanym. apletów oraz samodzielnych aplikacji. JAVA Java jest wszechstronnym językiem programowania, zorientowanym obiektowo, dostarczającym możliwość uruchamiania apletów oraz samodzielnych aplikacji. Java nie jest typowym kompilatorem. Źródłowy kod

Bardziej szczegółowo

OFERTA SZKOLENIOWA PROGRESS SOFTWARE

OFERTA SZKOLENIOWA PROGRESS SOFTWARE OFERTA SZKOLENIOWA PROGRESS SOFTWARE Szanowni Państwo, Zapraszamy do zapoznania się z naszą ofertą szkoleń w systemie Progress. Kursy organizowane są dla małych grup 3-6 osobowych, w Warszawie. Każdy uczestnik

Bardziej szczegółowo

Modelowanie diagramów klas w języku UML. Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014

Modelowanie diagramów klas w języku UML. Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014 Modelowanie diagramów klas w języku UML Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014 Czym jest UML - Unified Modeling Language - Rodzina języków modelowania graficznego - Powstanie na przełomie lat 80

Bardziej szczegółowo

Rozwiązania bazodanowe EnterpriseDB

Rozwiązania bazodanowe EnterpriseDB Rozwiązania bazodanowe EnterpriseDB Bogumił Stoiński RHC{E,I,X} B2B Sp. z o.o. 519 130 155 bs@bel.pl PostgreSQL Ponad 20 lat na rynku Jedna z najpopularniejszych otwartych relacyjnych baz danych obok MySQL

Bardziej szczegółowo

LITERATURA. Wprowadzenie do systemów baz danych C.J.Date; WNT Warszawa 2000

LITERATURA. Wprowadzenie do systemów baz danych C.J.Date; WNT Warszawa 2000 LITERATURA Wprowadzenie do systemów baz danych C.J.Date; WNT Warszawa 2000 Systemy baz danych. Pełny wykład H. Garcia Molina, Jeffrey D. Ullman, Jennifer Widom;WNT Warszawa 2006 Wprowadzenie do systemów

Bardziej szczegółowo

Bazy Danych. C. J. Date, Wprowadzenie do systemów baz danych, WNT - W-wa, (seria: Klasyka Informatyki), 2000

Bazy Danych. C. J. Date, Wprowadzenie do systemów baz danych, WNT - W-wa, (seria: Klasyka Informatyki), 2000 Bazy Danych LITERATURA C. J. Date, Wprowadzenie do systemów baz danych, WNT - W-wa, (seria: Klasyka Informatyki), 2000 J. D. Ullman, Systemy baz danych, WNT - W-wa, 1998 J. D. Ullman, J. Widom, Podstawowy

Bardziej szczegółowo

Programowanie obiektowe

Programowanie obiektowe Laboratorium z przedmiotu Programowanie obiektowe - zestaw 02 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas i obiektów z wykorzystaniem dziedziczenia.

Bardziej szczegółowo

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV Piotr Jarosik, Kamil Jaworski, Dominik Olędzki, Anna Stępień Dokumentacja wstępna TIN Rozproszone repozytorium oparte o WebDAV 1. Wstęp Celem projektu jest zaimplementowanie rozproszonego repozytorium

Bardziej szczegółowo

DEKLARATYWNE ZARZĄDZANIE W MICROSOFT SQL SERVER

DEKLARATYWNE ZARZĄDZANIE W MICROSOFT SQL SERVER DEKLARATYWNE ZARZĄDZANIE W MICROSOFT SQL SERVER Na podstawie artykułu: Hongfei Guo Dan Jones Jennifer Beckmann Praveen Seshadri Declarative Management in Microsoft SQL Server Marek Wittkowski Nowe podejście

Bardziej szczegółowo

UNIX: architektura i implementacja mechanizmów bezpieczeństwa. Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci

UNIX: architektura i implementacja mechanizmów bezpieczeństwa. Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci UNIX: architektura i implementacja mechanizmów bezpieczeństwa Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci Plan prezentacji: Wprowadzenie do struktury systemów rodziny UNIX

Bardziej szczegółowo

DSL w środowisku Eclipse. Grzegorz Białek Architekt techniczny, Sygnity S.A.

DSL w środowisku Eclipse. Grzegorz Białek Architekt techniczny, Sygnity S.A. DSL w środowisku Eclipse Grzegorz Białek Architekt techniczny, Sygnity S.A. Agenda Wstęp do tematu (10 min) Sens tworzenia języków biznesowych UML jako język biznesu? Zintegrowane środowisko deweloperskie

Bardziej szczegółowo

Tester oprogramowania 2014/15 Tematy prac dyplomowych

Tester oprogramowania 2014/15 Tematy prac dyplomowych Tester oprogramowania 2014/15 Tematy prac dyplomowych 1. Projekt i wykonanie automatycznych testów funkcjonalnych wg filozofii BDD za pomocą dowolnego narzędzia Jak w praktyce stosować Behaviour Driven

Bardziej szczegółowo

Grzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat

Grzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat Grzegorz Ruciński Warszawska Wyższa Szkoła Informatyki 2011 Promotor dr inż. Paweł Figat Cel i hipoteza pracy Wprowadzenie do tematu Przedstawienie porównywanych rozwiązań Przedstawienie zalet i wad porównywanych

Bardziej szczegółowo

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław

Bardziej szczegółowo

Zaawansowana platforma integracyjna aplikacji eadministracji

Zaawansowana platforma integracyjna aplikacji eadministracji egov-bus Advanced egovernment Information Service Bus Zaawansowana platforma integracyjna aplikacji eadministracji egov-bus - Zaawansowana platforma integracyjna aplikacji Administracji (IST-4-026727-STP)

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 4 Narzędzie do wyliczania wielkości oraz wartości parametrów stanu Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 30 maja 2012 Historia dokumentu Nazwa

Bardziej szczegółowo

*Grafomania z. Neo4j. Praktyczne wprowadzenie do grafowej bazy danych.

*Grafomania z. Neo4j. Praktyczne wprowadzenie do grafowej bazy danych. *Grafomania z Neo4j Praktyczne wprowadzenie do grafowej bazy danych. Jak zamodelować relacyjną bazę danych reprezentującą następujący fragment rzeczywistości: Serwis WWW opisuje pracowników różnych firm

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy

Bardziej szczegółowo

STUDIA STACJONARNE I STOPNIA Przedmioty kierunkowe

STUDIA STACJONARNE I STOPNIA Przedmioty kierunkowe STUDIA STACJONARNE I STOPNIA Przedmioty kierunkowe Technologie informacyjne Prof. dr hab. Zdzisław Szyjewski 1. Rola i zadania systemu operacyjnego 2. Zarządzanie pamięcią komputera 3. Zarządzanie danymi

Bardziej szczegółowo

Paradygmaty programowania

Paradygmaty programowania Paradygmaty programowania Jacek Michałowski, Piotr Latanowicz 15 kwietnia 2014 Jacek Michałowski, Piotr Latanowicz () Paradygmaty programowania 15 kwietnia 2014 1 / 12 Zadanie 1 Zadanie 1 Rachunek predykatów

Bardziej szczegółowo

Zaawansowane Systemy Baz Danych

Zaawansowane Systemy Baz Danych Zaawansowane Systemy Baz Danych dr inż. Olga Siedlecka olga.siedlecka@icis.pcz.pl Instytut Informatyki Teoretycznej i Stosowanej Politechnika Częstochowska 4 maja 2009 r. Plan seminarium Wprowadzenie Stosowane

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne

Bardziej szczegółowo

Bazy danych - wykład wstępny

Bazy danych - wykład wstępny Bazy danych - wykład wstępny Wykład: baza danych, modele, hierarchiczny, sieciowy, relacyjny, obiektowy, schemat logiczny, tabela, kwerenda, SQL, rekord, krotka, pole, atrybut, klucz podstawowy, relacja,

Bardziej szczegółowo

Spis treúci. 1. Wprowadzenie... 13

Spis treúci. 1. Wprowadzenie... 13 Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...

Bardziej szczegółowo

Liczba godzin 1,2 Organizacja zajęć Omówienie programu nauczania 2. Tematyka zajęć

Liczba godzin 1,2 Organizacja zajęć Omówienie programu nauczania 2. Tematyka zajęć rzedmiot : Systemy operacyjne Rok szkolny : 015/016 Klasa : 3 INF godz. x 30 tyg.= 60 godz. Zawód : technik informatyk; symbol 35103 rowadzący : Jacek Herbut Henryk Kuczmierczyk Numer lekcji Dział Tematyka

Bardziej szczegółowo

ORACLE (Wykład 1) aragorn.pb.bialystok.pl/~aonisko. Typy rozproszonych baz danych. Systemy klient-serwer. Klient-serwer: Przykład

ORACLE (Wykład 1) aragorn.pb.bialystok.pl/~aonisko. Typy rozproszonych baz danych. Systemy klient-serwer. Klient-serwer: Przykład ORACLE (Wykład 1) aragorn.pb.bialystok.pl/~aonisko Typy rozproszonych baz Systemy typu klient-serwer (jeden serwer) Jednorodna rozproszona baza (kilka serwerow, jeden system zarzadzania baza ) Niejednorodna

Bardziej szczegółowo

REFERAT PRACY DYPLOMOWEJ

REFERAT PRACY DYPLOMOWEJ REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany

Bardziej szczegółowo

FUNKCJONALNOŚ C PORTAL B2B KAMELEON.ŚQL 7.5.60

FUNKCJONALNOŚ C PORTAL B2B KAMELEON.ŚQL 7.5.60 FUNKCJONALNOŚ C PORTAL B2B KAMELEON.ŚQL 7.5.60 W KAMELEON.SQL 7.5.60 została dodana funkcjonalność klasy B2B (na tą funkcjonalność wymagana jest dodatkowa licencja, którą można wykupić w naszej firmie)

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne przedmioty.

Bardziej szczegółowo

STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe

STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe Technologie informacyjne prof. dr hab. Zdzisław Szyjewski 1. Rola i zadania systemu operacyjnego 2. Zarządzanie pamięcią komputera 3. Zarządzanie danymi

Bardziej szczegółowo

Systemy GIS Systemy baz danych

Systemy GIS Systemy baz danych Systemy GIS Systemy baz danych Wykład nr 5 System baz danych Skomputeryzowany system przechowywania danych/informacji zorganizowanych w pliki Użytkownik ma do dyspozycji narzędzia do wykonywania różnych

Bardziej szczegółowo

System generacji raportów

System generacji raportów Zalety systemu Czym jest ProReports? prostota instalacji, wieloplatformowość (AIX, Linux, Windows, Solaris), obsługa popularnych formatów (PDF, XLS, RTF, HTML,TXT,XML,CSV), obsługa wielu baz danych, raporty

Bardziej szczegółowo

2010-10-06 ORGANIZACJA ZAJĘĆ BAZY DANYCH PLAN WYKŁADU SCHEMAT SYSTEMU INFORMATYCZNEGO

2010-10-06 ORGANIZACJA ZAJĘĆ BAZY DANYCH PLAN WYKŁADU SCHEMAT SYSTEMU INFORMATYCZNEGO ORGANIZACJA ZAJĘĆ Wykładowca dr inż. Agnieszka Bołtuć, pokój 304, e-mail: aboltuc@ii.uwb.edu.pl Liczba godzin i forma zajęć: 30 godzin wykładu oraz 30 godzin laboratorium Konsultacje: czwartek 10:15-12:00

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: Kierunek: Informatyka Rodzaj przedmiotu: obowiązkowy w ramach treści kierunkowych, moduł kierunkowy ogólny Rodzaj zajęć: wykład, laboratorium BAZY DANYCH Databases Forma studiów: Stacjonarne

Bardziej szczegółowo

Część I Tworzenie baz danych SQL Server na potrzeby przechowywania danych

Część I Tworzenie baz danych SQL Server na potrzeby przechowywania danych Spis treści Wprowadzenie... ix Organizacja ksiąŝki... ix Od czego zacząć?... x Konwencje przyjęte w ksiąŝce... x Wymagania systemowe... xi Przykłady kodu... xii Konfiguracja SQL Server 2005 Express Edition...

Bardziej szczegółowo

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,

Bardziej szczegółowo

Integracja systemu CAD/CAM Catia z bazą danych uchwytów obróbkowych MS Access za pomocą interfejsu API

Integracja systemu CAD/CAM Catia z bazą danych uchwytów obróbkowych MS Access za pomocą interfejsu API Dr inż. Janusz Pobożniak, pobozniak@mech.pk.edu.pl Instytut Technologii Maszyn i Automatyzacji produkcji Politechnika Krakowska, Wydział Mechaniczny Integracja systemu CAD/CAM Catia z bazą danych uchwytów

Bardziej szczegółowo