Historia niejednego dostępu

Microsoft proponował różne metody dostępu do danych. Universal Data Access, wkomponowany w strategię DNA, ma rozwiązać problemy z dostępem do różnego rodzaju danych.

Microsoft proponował różne metody dostępu do danych. Universal Data Access, wkomponowany w strategię DNA, ma rozwiązać problemy z dostępem do różnego rodzaju danych.

Dostęp do danych, obok przedstawionej przed tygodniem logiki aplikacji, odgrywa kluczową rolę w strategii nazywanej DNA - Distributed interNet Application.

Wytrych ODBC

W świecie komputerów dane są gromadzone w najróżniejszych formach - od plików dokumentów, przez lokalne bazy danych, po serwery SQL, serwery WWW i duże bazy na mainframe. Chcąc dostać się do konkretnej informacji z poziomu programu, trzeba skorzystać ze specjalnego interfejsu, właściwego dla danego typu danych.

Podstawowym sterownikiem dostępu do danych jest ODBC, określający złożony zbiór funkcji API, służących do nawiązywania połączenia z bazą, wykonywania kwerend itp. Jednak tworzenie programu bazodanowego, opierającego się wyłącznie na ODBC API, nie jest dobrym rozwiązaniem. Z pewnością posługiwanie się API pozwala na pisanie najbardziej wydajnych aplikacji, zarówno pod względem szybkości działania, jak i zużycia pamięci. Jednak standard ODBC ma wady.

Istnieją trzy poziomy standardu ODBC określającego funkcje API, które można implementować. Podstawowe API i API Level 1 wykorzystują w praktyce wszystkie sterowniki ODBC. Jednak liczba funkcji API Level 1 jest niewystarczająca w większości zastosowań. Istnieje wprawdzie kolejny poziom API Level 2, ale trudno znaleźć sterownik, który wykorzystywałby wszystkie funkcje drugiego poziomu. Zwykle producenci oprogramowania podają, że ich sterownik jest niemal zgodny z API Level 2, a nie wdraża tylko kilku funkcji. W rzeczywistości program korzystający wyłącznie z ODBC API musi być albo dostosowany do konkretnej wersji sterownika ODBC i bazy danych, albo programista musi samodzielne wdrażać uniwersalne mechanizmy dostępu do danych. Podobny problem można napotkać w implementacji gramatyki przez sterowniki ODBC.

Na własną rękę

Skutkiem tej niedoskonałości standardu jest to, że producenci narzędzi obudowują ODBC, tak aby umożliwić programistom pisanie aplikacji w miarę niezależnych od konkretnej bazy danych. Tak uczynił też Microsoft, który zaoferował RDO (Remote Data Object). Firma ułatwiła pracę programistom, uniezależniając ich od ODBC API. Negatywnym skutkiem takiego działania było spowolnienie pracy aplikacji i zwiększenie wymagań pamięciowych.

Innym własnym standardem łączenia z bazami danych typu desktop były ISAM i Jet. Microsoft Jet to sterownik realizujący wszystkie operacje na bazie danych Access. ISAM jest zaś specjalnym sterownikiem towarzyszącym Jet, pozwalającym na dostęp do plików DBF, Paradox i innych. Aby uprościć korzystanie z API Jet (w praktyce rzadko stosowanego), Microsoft wprowadził zbiór obiektów o nazwie DAO (Data Access Object). Ponieważ szybko okazało się, że rozwiązania oparte na Microsoft Jet były łączone z danymi przechowywanymi w dużych bazach, pojawiło się rozszerzenie DAO, o nazwie ODBCDirect, pozwalające na współpracę DAO ze sterownikami ODBC.

Programista piszący aplikacje bazodanowe miał więc szeroki wybór: ODBC API, RDO, DAO, ISAM, ODBCDirect. W rzeczywistości każdy z tych mechanizmów realizował tę samą funkcję. Pozwalał, by program manipulował informacjami z relacyjnej bazy danych. Naturalną konsekwencją takiego stanu była chęć połączenia wielu różnych rozwiązań w jedno.

Uniwersalny dostęp

Wraz z powstaniem pomysłu na architekturę Windows DNA Microsoft zapowiedział nową technologię umożliwiającą dostęp do danych - Universal Data Access (UDA), opartą na obiektowych modelach COM i COM+.

Zamysłem Universal Data Access jest stworzenie dostępu do dowolnego typu danych w jednolity sposób. Podstawą UDA mają być sterowniki OLE DB, a ściślej tzw. prowajder OLE DB. Aplikacje klienckie albo komunikują się bezpośrednio ze sterownikiem OLE DB (są wtedy konsumentem OLE DB), albo korzystają ze specjalnego zbioru obiektów kierujących odwołania do OLE DB. Obecnie Microsoft proponuje dwa zestawy obiektów wykorzystujących OLE DB: ADO (ActiveX Data Object) i MDE (Microsoft Data Engine) - specjalny zbiór klas do Access 2000 dostosowany do prowajdera OLE DB do SQL 7. Składniki ADO czy OLE DB mogą działać w każdej warstwie programu - zarówno po stronie serwera, w warstwie pośredniej, jak i w aplikacji klienckiej.

Prowajder OLE DB można napisać niemal do każdego typu danych. Jako dane, które sterownik OLE DB może obsługiwać, można traktować nawet strukturę katalogów na dysku. Programista może napisać prosty sterownik OLE DB do własnego typu danych.

Jest to równocześnie zaletą i wadą OLE DB. Prosty sterownik można napisać do każdego źródła danych. Realizacja kwerend spada wtedy na specjalną część OLE DB/ADO (bibliotekę itp). Problemy mogą występować w przypadku bardziej złożonych sterowników, które realizują większą część interfejsów standardu OLE DB. Może to przypominać sytuację z różnymi poziomami zgodności ODBC. Na szczęście w przypadku OLE DB sytuacja jest prostsza - standard przewiduje swego rodzaju "miejsca rozszerzeń", gdzie prowajder OLE DB udostępnia dodatkowe właściwości. Program niemal bezproblemowo odczytuje możliwości danego sterownika. Większą cześć tej "czarnej roboty" wykonuje ADO i wtedy program jest niemal zupełnie odizolowany od właściwości konkretnego źródła danych.

ADO od "czarnej roboty"

Pod względem funkcjonalnym ADO łączy elementy DAO i RDO - wcześniejszych propozycji programistycznych Microsoftu. Najważniejsza zmiana to uproszczona hierarchia obiektów. ADO ma wiele cech, które czynią go ciekawą propozycją dla programistów. Po pierwsze, bez większych problemów można wykorzystywać obiekty ADO w różnych wątkach. Próby otwarcia w jednym wątku połączenia z bazą przy użyciu ODBC API, a czytanie z tabeli w innym sprawiało wiele kłopotów. W ADO jest to stosunkowo proste.

Po drugie, ADO 2.0 ma bardzo rozbudowany motor kursora po stronie klienta. Można w nim wyszukiwać informacje bez komunikowania się z serwerem, ustawiać lokalne indeksy itp. Co ważniejsze, można wprowadzić wiele zmian w różnych rekordach, a potem wykonać tylko jedną aktualizację grupową, synchronizując dane z serwerem. Model zgłaszania błędów w ADO pozwala, by po takiej aktualizacji została utworzona specjalna kolekcja zawierająca rekordy, które nie mogą być zaktualizowane. Ponadto można korzystać z RDS (Remote Data Service) i przenosić dane z serwera na stację roboczą, a także pracować z tzw. rozłączonymi zbiorami rekordów, synchronizując je tylko wtedy, gdy jest to możliwe. Co więcej, większość prowajderów OLE DB pozwala zapisywać zbiory rekordów na dysku.

ADO większość operacji może wykonywać asynchronicznie, a także ograniczać liczbę zwracanych rekordów. Cechy te sprawiają, że ADO kwalifikuje się do pisania aplikacji internetowych, gdzie utrzymanie ciągłego połączenia z serwerem bazodanowym może być niemożliwe.

OLE DB w OLE DB

Warto podkreślić jedną cechę OLE DB i ADO. Dzięki tym mechanizmom można stosunkowo łatwo opracować prowajder, który wykorzystuje inne prowajdery OLE DB. Źródłem danych sterownika OLE DB może być inny sterownik, którego funkcje zostaną "opakowane" w bardziej zaawansowany interfejs. W ten sposób powstały dwie ciekawe propozycje dla programistów. Jedna to Microsoft Shape, druga - IBDM.

Shape umożliwia łączenie różnych rekordów w swego rodzaju kostki (przypominające z analizy OLAP), a także tworzenie hierarchicznych rekordów (prezentujących relacje jeden do wielu, a także wiele do wielu). W ten sposób, z punktu widzenia aplikacji, kilka rekordów połączono w jedną strukturę. Można zatem niejako całą bazę danych zmieścić w jednej "tablicy", z tym że niektóre jej kolumny to właściwie inne tablice.

IBDM to specjalny sterownik OLE DB, pracujący w warstwie środkowej aplikacji i przyspieszający dostęp do danych oraz przechowujący często odczytywane rekordy w pamięci podręcznej. Jest to usługa Windows NT, korzystająca z możliwości COM+. IBDM może przyspieszać dostęp nie tylko do serwerów SQL, ale także do danych typu ISAM. IBDM w połączeniu z biblioteką kursora ADO pracuje jak prosty optymalizator kwerend.

Obecnie istnieją prowajdery OLE DB do Microsoft Jet i ISAM, Microsoft SQL Server, Oracle, sterowników ODBC, Index Servera i Microsoft Directory Services (wersja testowa). Komponenty OLE DB mogą znajdować się także po stronie serwera. W ten sposób jest zrealizowana duża część SQL Server 7.0.

Nadal kontynuacja

W połowie 1997 r. Microsoft zapowiadał, że nie będzie rozwijał innych interfejsów obsługi danych poza OLE DB i ADO. Jednak wraz z zestawem aplikacji biurowych Office 2000 pojawia się kolejna wersja Microsoft Jet i DAO 4.0. Wydaje się natomiast, że nie będzie dalej rozwijane RDO - przynajmniej wraz z pakietem programistycznym Microsoft Visual Studio 6 jest rozprowadzana stara wersja RDO 2.0.

Kolejne wersje ADO pojawiają się niemal co 2-3 miesiące i co istotne, nie są to wersje "poprawiające" błędy poprzednich. Równocześnie wiele firm trzecich tworzy interfejsy OLE DB do różnych źródeł danych. Na razie jednak, poza Visual Studio Microsoftu, nie ma narzędzi RAD dla programistów ułatwiających korzystanie z ADO. Delphi, Power++, PowerBuilder i inne konkurencyjne narzędzia programistyczne stosują własne sposoby dostępu do danych i nie wydaje się, by ich producenci chcieli ułatwić korzystanie z ADO. Wprawdzie ADO można zastosować w dowolnym narzędziu, które pozwala na korzystanie z COM/ActiveX, jednak samodzielne pisanie np. kodu związującego kontrolki ze źródłem danych jest dosyć pracochłonne.

Słowniczek DNA

ActiveX

Specjalny typ obiektu COM, dysponujący graficznym interfejsem, czasami nazywany kontrolką

ADO

ActiveX Data Object, uporządkowany zbiór obiektów, pozwalający na łatwe pisanie aplikacji posługujących się OLE DB

COM

Component Object Model, technologia tworzenia komponentów, które mogą być wykorzystywane przez system operacyjny lub aplikacj

COM+

Rozszerzenie COM dostępne w Windows 2000. Od COM różni się sposobem obsługi ze strony systemu operacyjnego; COM+ ma też znacznie większy zbiór usług systemowych

DAO

Data Access Object, uporządkowany zbiór obiektów pozwalający na łatwą obsługę baz typu Jet (MS Access)

DCOM

Sposób komunikacji zdalnych obiektów COM, znajdujących się na różnych komputerach w sieci

DNA

Distributed interNet Application, propozycja Microsoftu określająca zbiór usług Windows, które mogą być wykorzystane w różnych warstwach aplikacji, także aplikacji internetowej

ISAM

Sterowniki/standard dostępu do baz danych plikowych (DBase, Paradox itp.) z poziomu DAO

ODBC

Open DataBase Connectivity, zbiór funkcji API pozwalających na dostęp do relacyjnych baz danych

ODBCDirect?

Rozszerzenie DAO, pozwalające na łączenie się z bazami danych za pośrednictwem ODBC

OLE DB

Standard określający sposób pisania sterowników obsługujących bazy danych

RDO

Remote Data Object, uporządkowany zbiór obiektów ułatwiający korzystanie z ODBC

RDS

Remote Data Service, część ADO obsługująca zdalne rekordy; wykorzystywana w tworzeniu skryptów do MS Internet Information Server

UDA

Universal Data Access, koncepcja uniwersalnego (i jednolitego z punktu widzenia programisty) dostępu do danych


TOP 200