Warstwa abstrakcji bazy danych - Database abstraction layer

Warstwa abstrakcji bazy danych ( DBAL lub DAL ) to interfejs programowania aplikacji , który ujednolica komunikację między aplikacji komputerowej i baz danych , takich jak SQL Server , DB2 , MySQL , PostgreSQL , Oracle lub SQLite . Tradycyjnie wszyscy dostawcy baz danych zapewniają własny interfejs dostosowany do ich produktów. Zaimplementowanie kodu interfejsów bazy danych, które będą obsługiwane przez aplikację, należy do programisty aplikacji. Warstwy abstrakcji bazy danych zmniejszają ilość pracy, zapewniając programistom spójny interfejs API i ukrywając specyfikę bazy danych za tym interfejsem w jak największym stopniu. Istnieje wiele warstw abstrakcji z różnymi interfejsami w wielu językach programowania. Jeśli aplikacja ma wbudowaną taką warstwę, nazywa się ją niezależną od bazy danych .

Poziomy abstrakcji w bazach danych

Poziom fizyczny (najniższy poziom)

Najniższy poziom łączy się z bazą danych i wykonuje rzeczywiste operacje wymagane przez użytkowników. Na tym poziomie instrukcja pojęciowa została przetłumaczona na wiele instrukcji zrozumiałych dla bazy danych. Wykonywanie instrukcji we właściwej kolejności umożliwia DAL wykonanie instrukcji koncepcyjnej.

Implementacja warstwy fizycznej może wykorzystywać interfejsy API specyficzne dla bazy danych lub korzystać z technologii dostępu do bazy danych w standardowym języku i wersji SQL bazy danych.

Implementacja typów danych i operacji jest najbardziej specyficzna dla bazy danych na tym poziomie.

Poziom koncepcyjny lub logiczny (średni lub następny najwyższy poziom)

Poziom koncepcyjny konsoliduje zewnętrzne koncepcje i instrukcje w pośrednią strukturę danych, którą można przekształcić w instrukcje fizyczne. Ta warstwa jest najbardziej złożona, ponieważ obejmuje poziomy zewnętrzny i fizyczny. Dodatkowo musi obejmować wszystkie obsługiwane bazy danych i ich dziwactwa, interfejsy API i problemy.

Ten poziom jest świadomy różnic między bazami danych i jest w stanie skonstruować ścieżkę wykonywania operacji we wszystkich przypadkach. Jednak warstwa koncepcyjna ogranicza się do warstwy fizycznej w celu rzeczywistej implementacji każdej indywidualnej operacji.

Poziom zewnętrzny lub widok

Poziom zewnętrzny jest dostępny dla użytkowników i deweloperów oraz zapewnia spójny wzorzec wykonywania operacji na bazie danych. Operacje na bazie danych są reprezentowane tylko luźno jako SQL lub nawet dostęp do bazy danych na tym poziomie.

Każda baza danych powinna być traktowana jednakowo na tym poziomie, bez widocznych różnic pomimo różnych fizycznych typów danych i operacji.

Abstrakcja bazy danych w API

Biblioteki ujednolicają dostęp do baz danych, udostępniając programiście aplikacji jeden niskopoziomowy interfejs programistyczny. Ich zaletami są najczęściej szybkość i elastyczność, ponieważ nie są one związane z określonym językiem zapytań (podzbiorem) i wystarczy zaimplementować cienką warstwę, aby osiągnąć swój cel. Ponieważ wszystkie dialekty SQL są do siebie podobne, programiści aplikacji mogą korzystać ze wszystkich funkcji języka, prawdopodobnie dostarczając konfigurowalne elementy dla przypadków specyficznych dla bazy danych, takie jak zwykle identyfikatory użytkowników i poświadczenia. Cienka warstwa umożliwia uruchamianie tych samych zapytań i instrukcji w różnych produktach bazodanowych przy niewielkim narzutie.

Warstwy abstrakcji baz danych są powszechnie stosowane wśród zorientowanych obiektowo języków programowania , które są podobne do warstw abstrakcji na poziomie interfejsu API. W języku zorientowanym obiektowo, takim jak C ++ lub Java, baza danych może być reprezentowana przez obiekt , którego metody i elementy (lub ich odpowiedniki w innych językach programowania) reprezentują różne funkcje bazy danych. Mają również zalety i wady z interfejsami na poziomie API.

Abstrakcja na poziomie języka

Przykładem warstwy abstrakcji bazy danych na poziomie języka może być ODBC , czyli niezależna od platformy implementacja warstwy abstrakcji bazy danych. Użytkownik instaluje określone oprogramowanie sterownika , za pośrednictwem którego ODBC może komunikować się z bazą danych lub zbiorem baz danych. Użytkownik ma wtedy możliwość komunikowania się programów z ODBC, który następnie przekazuje wyniki między programami użytkownika a bazą danych. Wadą tego poziomu abstrakcji jest zwiększony narzut związany z przekształcaniem instrukcji w konstrukcje zrozumiałe dla docelowej bazy danych.

Alternatywnie istnieją cienkie opakowania, często określane jako lekkie warstwy abstrakcji, takie jak OpenDBX i libzdb. Wreszcie, duże projekty mogą tworzyć własne biblioteki, takie jak na przykład libgda dla GNOME .

Argumenty

Na korzyść

• Okres rozwoju: programiści muszą znać tylko API warstwy abstrakcji bazy danych, a nie wszystkie interfejsy API baz danych, które ich aplikacja powinna obsługiwać. Im więcej baz danych powinno być obsługiwanych, tym większa oszczędność czasu.
• Szersza potencjalna baza instalacji: użycie warstwy abstrakcji bazy danych oznacza, że ​​nie ma wymogu, aby nowe instalacje korzystały z określonej bazy danych, tj. Nowi użytkownicy, którzy nie chcą lub nie mogą zmienić bazy danych, mogą wdrożyć swoją istniejącą infrastrukturę.
• Gotowość na przyszłość: wraz z pojawieniem się nowych technologii baz danych programiści nie będą musieli dostosowywać się do nowych interfejsów.
• Testowanie deweloperskie: produkcyjną bazę danych można zastąpić implementacją danych na poziomie komputerów stacjonarnych do testów jednostkowych na poziomie dewelopera.
• Dodane funkcje bazy danych: w zależności od bazy danych i DAL może być możliwe dodanie funkcji do bazy danych przez DAL. DAL może wykorzystywać narzędzia programowania bazy danych lub inne metody do tworzenia standardowej, ale nieobsługiwanej funkcjonalności lub zupełnie nowej funkcjonalności. Na przykład DBvolution DAL implementuje funkcję odchylenia standardowego dla kilku baz danych, które jej nie obsługują.

Przeciwko temu

• Szybkość: każda warstwa abstrakcji zmniejszy ogólną prędkość mniej więcej w zależności od ilości dodatkowego kodu, który ma zostać wykonany. Im bardziej warstwa bazy danych abstrahuje od natywnego interfejsu bazy danych i próbuje emulować funkcje nieobecne we wszystkich zapleczach bazy danych, tym mniejsza jest ogólna wydajność. Jest to szczególnie prawdziwe w przypadku warstw abstrakcji bazy danych, które próbują ujednolicić język zapytań, a także ODBC.
• Zależność: warstwa abstrakcji bazy danych zapewnia jeszcze jedną funkcjonalną zależność dla systemu oprogramowania, tj. Dana warstwa abstrakcji bazy danych, jak wszystko inne, może ostatecznie stać się przestarzała, przestarzała lub nieobsługiwana.
• Operacje zamaskowane: warstwy abstrakcji bazy danych mogą ograniczyć liczbę dostępnych operacji bazy danych do podzbioru operacji obsługiwanych przez obsługiwane zaplecze bazy danych. W szczególności warstwy abstrakcji bazy danych mogą nie w pełni obsługiwać optymalizacji lub debugowania specyficznych dla zaplecza bazy danych. Problemy te znacznie się powiększają wraz z rozmiarem, skalą i złożonością bazy danych.

Zobacz też

• Mapowanie obiektowo-relacyjne

Bibliografia