Database abstraction layer: Difference between revisions

Revision as of 13:47, 7 July 2009

Latest revision as of 05:14, 24 April 2024

(70 intermediate revisions by 50 users not shown)

Line 1:

[[Category:{{Short description|Application programming interfaces]]interface}}

{{context}}{{Unreferenced|date=December 2008}}A '''database abstraction layer''' is an [[application programming interface]] which unifies the communication between a computer application and [[database]]s such as [[MySQL]], [[PostgreSQL]], [[Oracle database|Oracle]] or [[SQLite]]. Traditionally, all database vendors provide their own interface tailored to their products which leaves it to the application programmer to implement code for all database interfaces he would like to support. Database abstraction layers reduce the amount of work by providing a consistent API to the developer and hide the database specifics behind this interface as much as possible. There exist many abstraction layers with different interfaces in numerous programming languages.

{{More citations needed|date=September 2014}}

A '''database abstraction layer''' ('''DBAL'''<ref>{{context}}{{Unreferencedcite book|datefirst1=DecemberTim|last1=Ambler|first2=Nicholas|last2=Cloud|title=JavaScript 2008Frameworks for Modern Web Dev|url=https://books.google.com/books?id=2IfDCgAAQBAJ&pg=PA346|year=2015|publisher=Apress|isbn=978-1-4842-0662-1|page=346}}A</ref> or '''database abstraction layerDAL''') is an [[application programming interface]] which unifies the communication between a computer application and [[database]]s such as [[MSSQL|SQL Server]], [[IBM Db2]], [[MySQL]], [[PostgreSQL]], [[Oracle database|Oracle]] or [[SQLite]]. Traditionally, all database vendors provide their own interface that is tailored to their products. whichIt leavesis itup to the application programmer to implement code for allthe database interfaces hethat wouldwill likebe tosupported supportby the application. Database abstraction layers reduce the amount of work by providing a consistent API to the developer and hide the database specifics behind this interface as much as possible. There exist many abstraction layers with different interfaces in numerous programming languages. If an application has such a layer built in, it is called '''database-agnostic'''.<ref>{{cite web |url=http://searchdatamanagement.techtarget.com/definition/database-agnostic |title = What is database-agnostic? - Definition from WhatIs.com}}</ref>

== APIDatabase levellevels of abstraction ==

=== Physical level (lowest level) ===

The lowest level connects to the database and performs the actual operations required by the users. At this level the conceptual instruction has been translated into multiple instructions that the database understands. Executing the instructions in the correct order allows the DAL to perform the conceptual instruction.

Implementation of the physical layer may use database-specific APIs or use the underlying language standard database access technology and the database's version SQL.

Libraries like [[OpenDBX]] unify access to databases by providing a single low-level programming interface to the application developer. Their advantages are most often speed and flexibility because they are not tied to a specific query language (subset) and only have to implement a thin layer to reach their goal. The application developer can choose from all language features but has to provide configurable statements for querying or changing tables. Otherwise his application would also be tied to one database.

Implementation of data types and operations are the most database-specific at this level.

Popular use for database abstraction layers are among [[object-oriented programming]] languages, which are similar to API level abstraction layers. In an object oriented language like C++ or Java, a database can be represented through an [[Object (computer science)|object]], whose methods and members (or the equivalent thereof in other programming languages) represent various functionalities of the database. They also share the same advantages and disadvantages as API level interfaces.

=== Conceptual or logical level (middle or next highest level) ===

== Language level abstraction ==

The conceptual level consolidates external concepts and instructions into an intermediate data structure that can be devolved into physical instructions. This layer is the most complex as it spans the external and physical levels. Additionally it needs to span all the supported databases and their quirks, APIs, and problems.

This level is aware of the differences between the databases and able to construct an execution path of operations in all cases. However the conceptual layer defers to the physical layer for the actual implementation of each individual operation.

An example of a database abstraction layer on the language level would be [[ODBC]]. ODBC is a platform-independent implementation of a database abstraction layer. The user installs specific driver-software, through which ODBC can communicate with a database or set of databases. The user then has the ability to have programs communicate with ODBC, which then relays the results back and forth between the user programs and the database. The downside of this abstraction level is the increased overhead to transform statements into constructs understood by the target database..

=== ArgumentsExternal foror view level ===

The external level is exposed to users and developers and supplies a consistent pattern for performing database operations.

<ref>{{Cite web|url=http://www.dmst.aueb.gr/dds/etech/db/abstr.htm|title = Levels of Abstraction}}</ref> Database operations are represented only loosely as SQL or even database access at this level.

Every database should be treated equally at this level with no apparent difference despite varying physical data types and operations.

=== Development period ===

== Database abstraction in the API ==

Software developers only have to know the database abstraction layer's API instead of all APIs of the databases his application should support. The more databases should be supported the bigger is the time saving.

Libraries like [[OpenDBX]] unify access to databases by providing a single low-level programming interface to the application developer. Their advantages are most often speed and flexibility because they are not tied to a specific [[query language]] (subset) and only have to implement a thin layer to reach their goal. TheAs all [[SQL]] dialects are similar to one another, application developerdevelopers can choose fromuse all the language features, butpossibly has to provideproviding configurable statementselements for queryingdatabase-specific orcases, changingsuch tablesas typically user-IDs and credentials. OtherwiseA histhin-layer applicationallows wouldthe alsosame bequeries tiedand statements to onerun on a variety of database products with negligible overhead.

Popular use for database abstraction layers are among [[object-oriented programming]] languages, which are similar to API -level abstraction layers. In an object -oriented language like C++ or Java, a database can be represented through an [[Object (computer science)|object]], whose methods and members (or the equivalent thereof in other programming languages) represent various functionalities of the database. They also share the same advantages and disadvantages aswith API -level interfaces.

=== Wider potential install-base ===

== Language -level abstraction ==

Using a database abstraction layer means that there is no requirement for new installations in utilise a specific database, i.e. new users who are unwilling or unable to switch databases can deploy on their existing infrastructure.

An example of a database abstraction layer on the language level would be [[ODBC]]. ODBCthat is a platform-independent implementation of a database abstraction layer. The user installs specific [[driver- software]], through which ODBC can communicate with a database or set of databases. The user then has the ability to have programs communicate with ODBC, which then relays the results back and forth between the user programs and the database. The downside of this abstraction level is the increased overhead to transform statements into constructs understood by the target database..

Alternatively, there are thin wrappers, often described as ''lightweight'' abstraction layers, such as OpenDBX<ref>{{cite web |url=https://www.linuxnetworks.de/doc/index.php?title=OpenDBX |title=OpenDBX |date=24 June 2012 |website=linuxnetworks.de |access-date=26 July 2018}}</ref> and libzdb.<ref>{{cite web |url=http://www.tildeslash.com/libzdb/ |title=Libzdb |access-date=26 July 2018 |year=2018 |website=tildeslash.com}}</ref> Finally, large projects may develop their own libraries, such as, for example, libgda<ref>{{cite web |url=http://www.gnome-db.org/ |title=GNOME-DB |access-date=26 July 2018 |date=12 June 2015 |quote=Libgda library [...] is mainly a database and data abstraction layer, and includes a GTK+ based UI extension, and some graphical tools.}}</ref> for [[GNOME]].

=== Future-proofing ===

== Arguments ==

If a system's legacy database backend is outgrown or becomes unusable for some other reason (e.g. speed or database size), then database abstraction layer supporters claim that it can be rapidly replaced. This is not without debate, however. Firstly, it assumes that the database abstraction layer properly supports a viable alternative. Secondly, some people call in to question whether this type of decision is good engineering practice. For instance [[Jeremy Zawodny]] ([[Yahoo]], [[Craig's List]], [[Friendster]], [[Technorati]], [[Rackspace]], [[LiveJournal]]) states ''That's bullshit. It's never easy.'' ... ''If you truly limit yourself to the subset of features that is common across all major RDBMSes, you're doing yourself and your clients a huge disservice.'' [http://jeremy.zawodny.com/blog/archives/002194.html]

=== DependencyIn favor ===

Software* Development period: software developers only have to know the database abstraction layer's API instead of all APIs of the databases histheir application should support. The more databases should be supported the bigger is the time saving.

Using* Wider potential install-base: using a database abstraction layer means that there is no requirement for new installations into utilise a specific database, i.e. new users who are unwilling or unable to switch databases can deploy on their existing infrastructure.

* Future-proofing: as new database technologies emerge, software developers won't have to adapt to new interfaces.

* Developer testing: a production database may be replaced with a desktop-level implementation of the data for developer-level unit tests.

* Added Database Features: depending on the database and the DAL, it may be possible for the DAL to add features to the database. A DAL may use database programming facilities or other methods to create standard but unsupported functionality or completely new functionality. For instance, the DBvolution DAL implements the standard deviation function for several databases that do not support it.

=== ArgumentsAgainst againstit ===

Any* Speed: any abstraction layer will reduce the overall speed more or less depending on the amount of additional code that havehas to be executed. The more a database layer abstracts from the native database interface and tries to emulate features not present on all database backends, the slower the overall performance. This is especially true for database abstraction layers that try to unify the query language as well like ODBC.

A* Dependency: a database abstraction layer provides yet another functional dependency for a software system, i.e. a given database abstraction layer, like anything else, may eventually become obsolete, outmoded or unsupported.

Database* Masked operations: database abstraction layers may limit the number of available database operations to a subset of those supported by the supported database backends. In particular, database abstraction layers may not fully support database backend -specific optimizationoptimizations or debugging features. These problems magnify significantly with database size, scale, and complexity.

=== SpeedSee also ===

* [[Object–relational mapping]]

== References ==

Any abstraction layer will reduce the overall speed more or less depending on the amount of additional code that have to be executed. The more a database layer abstracts from the native database interface and tries to emulate features not present on all database backends, the slower the overall performance. This is especially true for database abstraction layers that try to unify the query language as well like ODBC.

{{reflist}}

{{Database}}

=== Dependency ===

[[Category:Database APIs| ]]

A database abstraction layer provides yet another functional dependency for a software system, i.e. a given database abstraction layer, like anything else, may eventually become obsolete, outmoded or unsupported.

=== Masked operations ===

Database abstraction layers may limit the number of available database operations to a subset of those supported by the supported database backends. In particular, database abstraction layers may not fully support database backend specific optimization or debugging features.

[[Category:Application programming interfaces]]

[[de:Datenbankabstraktionsschicht]]