Database abstraction layer: Difference between revisions

Revision as of 16:21, 29 November 2014

Revision as of 13:36, 18 December 2014

Line 2:

A '''database abstraction layer''' is an [[application programming interface]] which unifies the communication between a computer application and [[database]]s such as [[MSSQL|SQL Server]], [[IBM DB2|DB2]], [[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 or she 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. If an application has such a layer built in, it is called '''database-agnostic'''.<ref>http://searchdatamanagement.techtarget.com/definition/database-agnostic</ref>

== Database levels of Abstractionabstraction ==

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

It defines how data is stored. It is very complex and used by developers.

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

It defines data in terms of a data model. It tells what data is stored and described in small numbers. This level is usually used by '''DBA''' (Database administrator)

=== External or view level ===

It defines a number of simplified ___domain-specific views. It describes only part of databases . This level is used by users.

<ref>http://www.dmst.aueb.gr/dds/etech/db/abstr.htm</ref>

== Database Abstractionabstraction in the API ==

Libraries 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. As all [[SQL]] dialects are similar to one another, application developers can use all the language features, possibly providing configurable elements for a database-specific cases, such as, typically, user-IDs and credentials. A thin-layer allows the same queries and statements to run on a variety of database products with a 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 as API -level interfaces.

== Language -level abstraction ==

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.

Line 31:

As new database technologies emerge, software developers won't have to adapt to new interfaces.

=== Developer Testingtesting ===

A production database may be replaced with a desktop -level implementation of the data for developer -level unit tests.

== Arguments against ==