Menedżer dostępu do danych
Data Access Manager (DAM) był interfejsem API dostępu do bazy danych dla klasycznego systemu Mac OS , wprowadzonym w 1991 roku jako rozszerzenie Systemu 7 . Podobny w koncepcji do ODBC , DAM był mało używany i ostatecznie został usunięty pod koniec lat 90. Używało go tylko kilka produktów, chociaż we wczesnych latach 90. używano go w niektórych niezwykle imponujących wersjach demonstracyjnych . Bardziej nowoczesne wersje klasycznego systemu Mac OS i macOS zamiast tego używają ODBC do tej roli.
koncepcje
DAM i ODBC są podobne pod wieloma względami. Głównym celem obu systemów było wysłanie „ciągów zapytań” do dostawcy danych, który odpowiedziałby (potencjalnie) „zbiorem wyników” składającym się z wierszy danych. Oczekiwano, że oba systemy będą konwertować dane do iz odpowiednich formatów systemu, na przykład liczb całkowitych i łańcuchów. Dodatkowo oba zapewniały podsystem komunikacyjny, który ukrywał szczegóły wysyłania zapytań i danych między klientem a serwerem.
Podobnie jak większość oprogramowania Apple, DAM starał się maksymalnie uprościć proces wysyłania zapytań dla użytkowników, zarówno użytkowników aplikacji, jak i programistów piszących te aplikacje. Szczególnie godną uwagi cechą była koncepcja „dokumentów zapytań”. Dokumenty zapytań zawierały dowolną liczbę predefiniowanych zapytań (lub innych poleceń serwera) wraz z opcjonalnym kodem umożliwiającym ich modyfikację przed wysłaniem na serwer. Na przykład typowy dokument zapytania może zawierać ciąg zapytania, który loguje się do serwera bazy danych, a jeśli to się powiedzie, wyszukaj bieżącą datę z lokalnego komputera klienckiego za pomocą wywołania systemu Mac OS, a następnie użyj tej daty w zapytaniu który zwraca zapasy w magazynie na zadaną datę. Dokumenty zapytań mogą również zawierać kod komputerowy i zasoby potrzebne do obsługi tego procesu, na przykład okno dialogowe z prośbą o podanie nazwy użytkownika i hasła.
Aplikacje mogą używać dokumentów zapytań, nie mając pojęcia o wewnętrznych elementach zapytania. Po prostu otworzyli dokument, który składał się z serii zasobów i uruchomili po kolei każdy zasób zapytania. DAM zapewniłby, że każdy potrzebny kod w dokumencie zostanie uruchomiony bez wiedzy aplikacji, a ostatecznie wyniki zostaną przekazane z powrotem do aplikacji w celu wyświetlenia. Cała operacja była nieprzejrzysta, umożliwiając aplikacjom łatwe dodawanie obsługi DAM.
DAM zawierał również dwa bardziej bezpośrednie interfejsy API, interfejs wysokiego poziomu i interfejs niskiego poziomu. Wysoki poziom był dość podobny do korzystania z dokumentów zapytań, chociaż oczekiwano, że aplikacja będzie konstruować zapytania w kodzie, a nie w zasobach. Interfejs wysokiego poziomu jest zasadniczo podobny do publicznego interfejsu ODBC. Niski poziom umożliwił programiście interweniowanie w dowolnym momencie procesu zapytania, na przykład pobieranie danych linia po linii.
Jedna główna różnica między DAM i ODBC powstała w dużej mierze przez przypadek. Przed opracowaniem DAM firma Apple kupiła produkt oprogramowania pośredniego bazy danych, który sprzedawała jako język dostępu do danych lub DAL. DAL był zasadniczo znormalizowanym językiem SQL z translatorami dla różnych baz danych, które działały po stronie serwera. Standardy SQL były wówczas bardzo podstawowe i stosunkowo słabo obsługiwane, DAL rozwiązał ten problem, mając jeden język i konwertując do iz innych systemów. Oprogramowanie klienckie, w tym DAM, mogło wysyłać zapytania w standardowym języku DAL, które byłyby następnie tłumaczone i wykonywane niezależnie od wewnętrznej bazy danych.
W przeciwieństwie do tego, ODBC został opracowany od początku jako system oparty na SQL, oparty na standardowym interfejsie Call-Level z X/Open (obecnie część Open Group ). W OBDC każde źródło danych wyglądało jak serwer SQL. W przypadku źródeł bezserwerowych, takich jak pliki tekstowe, lokalny parser SQL zinterpretuje polecenia i odczyta plik. W ramach ODBC oczekuje się, że wszystkie sterowniki źródła danych będą rozumieć język SQL i w razie potrzeby tłumaczyć go na lokalny dialekt, a także konwertować dane do standardowych formatów po ich zwróceniu.
Ta różnica sprawiła, że DAM był znacznie mniej użyteczny niż ODBC w praktyce. Ponieważ oczekiwano, że DAL zapewni standaryzację zapytań, DAM nie miał warstwy podobnej do ODBC do tłumaczenia różnych dialektów. Aby DAM był naprawdę użyteczny, użytkownik musiał również kupić i zainstalować serwer DAL dla swojej konkretnej bazy danych. Powszechnie wiadomo, że DAL był powolny i kosztowny, co poważnie obniżało ogólną wartość DAM. Ponadto DAM nie ustandaryzował języka dostępu do źródeł danych innych niż SQL; adapter dla pliku tekstowego może zamiast tego używać języka innego niż SQL lub systemu całkowicie opartego na wywołaniach funkcji. Nie było też żadnych prostych interfejsów dla plików tekstowych lub podobnych źródeł danych dołączonych do podstawowych instalacji DAM.
Używa
Jednym z głównych klientów DAM była HyperCard , menedżer danych Apple/ system szybkiego tworzenia aplikacji . Połączenie doskonałego systemu formularzy HyperCard z danymi z DAM zaowocowało czymś, czego nikt nigdy nie widział przed aplikacjami GUI opartymi na danych. Najpopularniejsze demo systemu pokazywało stos HyperCard wysyłający zapytania do serii Baskin-Robbins , co wcześniej było niemożliwe, ponieważ każdy obszar regionalny korzystał z własnych serwerów baz danych, które teraz DAL połączył w jeden. Ponowne zamówienia na większe zapasy można składać, przeciągając serię gałek lodów na graficznym wyświetlaczu bieżących zapasów magazynowych.
System był tak imponujący, że inni dostawcy baz danych starali się dostarczać podobne systemy; Oracle Corporation natychmiast zakupiła PLUS od Spinnaker Software , wypuszczając go najpierw jako Oracle Card , a następnie Oracle Media Objects . Inne firmy poszły podobną drogą i wkrótce front-end bazy danych sterowany zdarzeniami stał się standardową funkcją większości systemów.
Szereg innych aplikacji również korzystało z systemu, być może, jak na ironię, różne produkty Office firmy Microsoft robiły to z największą regularnością. Poza tym obsługa DAM była dość rzadka, a produkt nie był szeroko stosowany. Być może wiele z tego wynikało z niekompletności systemu DAM jako całości ; potrzeba oprogramowania pośredniego DAL w większości przypadków i brak tanich konstruktorów dokumentów zapytań (było kilka drogich) sprawiły, że narzut związany z używaniem DAM był dość wysoki.
połowie lat 90. i całkowicie zanikły na jakiś czas przed wydaniem Mac OS X. „Klasyczna” wersja ODBC dla systemu Mac OS była dostępna przez pewien czas, chociaż wsparcie było ograniczone. Począwszy od wydania systemu OS X 10.2 Jaguar , firma Apple rozpoczęła dystrybucję wersji wieloplatformowych sterowników ODBC iODBC . Począwszy od OS X 10.4 Tiger , firma Apple wprowadziła nowy, znacznie „wyższy poziom” system znany jako Core Data . Core Data umożliwia programistom serializację danych w SQLite do przetwarzania, podobnie jak ODBC, gdy jest używany ze źródłem danych innym niż SQL.