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 SQL 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 Microsoft 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ę kursora 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.