This article is taken from a Wikipedia article under Creative Commons Attribution-Share-Alike License 3.0., and is shared here to provide convenient related information for learning about public records and how to find who you’re looking for using for pay people-finder, search-engine web sites.

A database is a structured collection of data. The data are typically organized to model relevant aspects of reality (for example, the availability of rooms in hotels), in a way that supports processes requiring this information (for example, finding a hotel with vacancies).

The term database is correctly applied to the data and their supporting database system.

The term database system implies that the data are managed to some level of quality (measured in terms of software system that meets many usage requirements to properly maintain its databases which are often large and complex.

This is specially the case with client-server, near-real time transactional systems, in which multiple users have access to data, data is concurrently entered and inquired for in ways that preclude single-thread batch processing. Most of the complexity of those requirements are still present with personal, desktop-based database systems.

Well known DBMSs include end-users as needed.

A way to classify databases involves the type of their contents, for example: bibliographic, document-text, statistical, or multimedia objects. Another way is by their application area, for example: accounting, music compositions, movies, banking, manufacturing, or insurance.

The term database may be narrowed to specify particular aspects of organized collection of data and may refer to the logical database, to the physical database as data content in computer data storage or to many other database sub-definitions.

Contents

[edit] History

[edit] Database concept

The database concept has evolved since the 1960s to ease increasing difficulties in designing, building, and maintaining complex computer networks, the sizes, capabilities, and performance of databases and their respective DBMSs have grown in orders of magnitudes. For decades it has been unlikely that a complex information system can be built effectively without a proper database supported by a DBMS. The utilization of databases is now spread to such a wide degree that virtually every technology and product relies on databases and DBMSs for its development and commercialization, or even may have such embedded in it. Also, organizations and companies, from small to large, heavily depend on databases for their operations.

No widely accepted exact definition exists for DBMS. However, a system needs to provide considerable functionality to qualify as a DBMS. Accordingly its supported data collection needs to meet respective usability requirements (broadly defined by the requirements below) to qualify as a database. Thus, a database and its supporting DBMS are defined here by a set of general requirements listed below. Virtually all existing mature DBMS products meet these requirements to a great extent, while less mature either meet them or converge to meet them.

[edit] Evolution of database and DBMS technology

See also Database management system#History

The introduction of the term database coincided with the availability of direct-access storage (disks and drums) from the mid-1960s onwards. The term represented a contrast with the tape-based systems of the past, allowing shared interactive use rather than daily batch processing.

In the earliest database systems, efficiency was perhaps the primary concern, but it was already recognized that there were other important objectives. One of the key aims was to make the data independent of the logic of application programs, so that the same data could be made available to different applications.

In the period since the 1970s database technology has kept pace with the increasing resources becoming available from the computing platform: notably the rapid increase in affordable capacity and speed of disk storage, and of main memory. This has enabled ever larger databases and higher throughput to be achieved.

The first generation of general-purpose database systems were navigational,[2] applications typically accessed data by following pointers from one record to another. The two main data models at this time were the hierarchical model, epitomized by IBM’s IMS system, and the Codasyl model (Network model), implemented in a number of products such as IDMS.

The Edgar F. Codd, departed from this tradition by insisting that applications should search for data by content, rather than by following links. This was considered necessary to allow the content of the database to evolve without constant rewriting of links and pointers. The relational model is made up of ledger-style tables, each used for a different type of entity. Data may be freely inserted, deleted and edited in these tables, with the DBMS (DataBase Management System) doing whatever maintenance needed to present a table view to the application/user. The relational part comes from entities referencing other entities in what is known as one-to-many relationship, like a traditional hierarchical model, and many-to-many relationship, like a navigational (network) model. Thus, a relational model can express both hierarchical and navigational models, as well as its native tabular model, allowing for pure or combined modeling in terms of these three models, as the application requires.

The earlier expressions of the relational model did not make relationships between different entities explicit in the way practitioners were used to back then, but as primary keys and foreign keys. These keys, though, can be also seen as pointers in their own right, stored in tabular form. This use of keys rather than pointers conceptually obscured relations between entities, at least the way it was presented back then. Thus, the wisdom at the time was that the relational model emphasizes search rather than navigation, and that it was a good conceptual basis for a query language, but less well suited as a navigational language. As a result, another data model, the database design, as it emphasized a more familiar description than the earlier relational model. Later on, entity-relationship constructs were retrofitted as a data modeling construct for the relational model, and the difference between the two have become irrelevant.

Earlier relational system implementations lacked the sophisticated automated optimizations of conceptual elements and operations versus their physical storage and processing counterparts, present in modern DBMSs (DataBase Management Systems), so their simplistic and literal implementations placed heavy demands on the limited processing resources at the time. It was not until the mid 1980s that computing hardware became powerful enough to allow relational systems (DBMSs plus applications) to be widely deployed. By the early 1990s, however, relational systems were dominant for all large-scale data processing applications, and they remain dominant today (2012) except in niche areas. The dominant database language is the standard SQL for the Relational model, which has influenced database languages for other data models.

The rigidity of the relational model, in which all data are held in related tables with a fixed structure of rows and columns, has increasingly been seen as a limitation when handling information that is richer or more varied in structure than the traditional ‘ledger-book’ data of corporate information systems. These limitations come to play when modeling document databases, engineering databases, multimedia databases, or databases used in the molecular sciences.

Most of that rigidity, though, is due to the need to represent new data types other than text and text-alikes within a relational model. Examples of unsupported data types are:

  • graphics (and operations such as pattern-matching and OCR)
  • Multidimensional constructs such as 2D (geographical), 3D (geometrical), and multidimensional hypercube models (data analysis).
  • XML (an hierarchical data modeling technology evolved from EDS and HTML), used for data interchange among dissimilar systems.

More fundamental conceptual limitations came with Object Oriented methodologies, with their emphasis on encapsulating data and processes (methods), as well as expressing constructs such as events or triggers. Traditional data modeling constructs emphasize the total separation of data from processes, though modern DBMS do allow for some limited modeling in terms of validation rules and stored procedures.

Various attempts have been made to address this problem, many of them banners such as post-relational or XML database. The vendors of relational databases have fought off competition from these newer models by extending the capabilities of their own products to support a wider variety of data types.

[edit] General-purpose DBMS

A DBMS has evolved into a complex software system and its development typically requires thousands of person-years of development effort.[citation needed] Some general-purpose DBMSs, like Oracle, Microsoft SQL Server, FoxPro, and IBM DB2, have been undergoing upgrades for thirty years or more. General-purpose DBMSs aim to satisfy as many applications as possible, which typically makes them even more complex than special-purpose databases. However, the fact that they can be used “off the shelf”, as well as their amortized cost over many applications and instances, makes them an attractive alternative (Vs. one-time development) whenever they meet an application’s requirements.

Though attractive in many cases, a general-purpose DBMS is not always the optimal solution: When certain applications are pervasive with many operating instances, each with many users, a general-purpose DBMS may introduce unnecessary overhead and too large “footprint” (too large amount of unnecessary, unutilized software code). Such applications usually justify dedicated development. Typical examples are email systems, though they need to possess certain DBMS properties: email systems are built in a way that optimizes email messages handling and managing, and do not need significant portions of a general-purpose DBMS functionality.

[edit] Types of people involved

Three types of people are involved with a general-purpose DBMS:

  1. DBMS developers – These are the people that design and build the DBMS product, and the only ones who touch its code. They are typically the employees of a DBMS vendor (e.g., systems programmers. DBMS development is a complicated task, and some of the popular DBMSs have been under development and enhancement (also to follow progress in technology) for decades.
  2. embedded database; subject to proper DBMS licensing), or sold separately as an add-on to the DBMS.
  3. Application’s end-users (e.g., accountants, insurance people, medical doctors, etc.) – These people know the application and its end-user interfaces, but need not know nor understand the underlying DBMS. Thus, though they are the intended and main beneficiaries of a DBMS, they are only indirectly involved with it.

[edit] Database machines and appliances

In the 1970s and 1980s attempts were made to build database systems with integrated hardware and software. The underlying philosophy was that such integration would provide higher performance at lower cost. Examples were IBM Exadata).

[edit] Database research

Database research has been an active and diverse area, with many specializations, carried out since the early days of dealing with the database concept in the 1960s. It has strong ties with database technology and DBMS products. Database research has taken place at research and development groups of companies (e.g., notably at elegant solution wins (e.g., SQL). Along their history DBMSs and respective databases, to a great extent, have been the outcome of such research, while real product requirements and challenges triggered database research directions and sub-areas.

The database research area has several notable dedicated IEEE ICDE, and more), as well as an active and quite heterogeneous (subject-wise) research community all over the world.

[edit] Database type examples

The following are examples of various database types. Some of them are not main-stream types, but most of them have received special attention (e.g., in research) due to end-user requirements. Some exist as specialized DBMS products, and some have their functionality types incorporated in existing general-purpose DBMSs. Though may differ in nature and functionality, these various types typically have to comply with the usability requirements below to comply as databases.

  • Active database
An active database is a database that includes an event-driven architecture which can respond to conditions both inside and outside the database. Possible uses include security monitoring, alerting, statistics gathering and authorization.
Most modern relational databases include active database features in the form of database trigger.
  • Cloud database
A Cloud database is a database that relies on Open APIs. More and more such database products are emerging, both of new vendors and by virtually all established database vendors.
  • Data warehouse
Data warehouses archive data from operational databases and often from external sources such as market research firms. Often operational data undergo transformation on their way into the warehouse, getting summarized, anonymized, reclassified, etc. The warehouse becomes the central source of data for use by managers and other end-users who may not have access to operational data. For example, sales data might be aggregated to weekly totals and converted from internal product codes to use mining data, transforming,loading and managing data so as to make them available for further use.
Operations in a data warehouse are typically concerned with bulk data manipulation, and as such, it is unusual and inefficient to target individual rows for update, insert or delete. Bulk native loaders for input data and bulk SQL passes for aggregation are the norm.
  • Distributed database
The definition of a distributed database is broad, and may be utilized in different meanings. In general it typically refers to a modular DBMS architecture that allows distinct DBMS instances to cooperate as a single DBMS over processes, computers, and sites, while managing a single database distributed itself over multiple computers, and different sites.
Examples are databases of local work-groups and departments at regional offices, branch offices, manufacturing plants and other work sites. These databases can include both segments shared by multiple sites, and segments specific to one site and used only locally in that site.
  • Document-oriented database
A document-oriented database is a computer program designed for storing, retrieving, and managing document-oriented, or semi structured data, information. Document-oriented databases are one of the main categories of so-called NoSQL databases and the popularity of the term “document-oriented database” (or “document store”) has grown with the use of the term NoSQL itself.
Utilized to conveniently store, manage, edit and retrieve documents.
  • Embedded database
An embedded database system is a DBMS which is tightly integrated with an [3]
  • End-user database
These databases consist of data developed by individual end-users. Examples of these are collections of documents, spreadsheets, presentations, multimedia, and other files. Several products exist to support such databases. Some of them are much simpler than full fledged DBMSs, with more elementary DBMS functionality (e.g., not supporting multiple concurrent end-users on a same database), with basic programming interfaces, and a relatively small “foot-print” (not much code to run as in “regular” general-purpose databases). However, also available general-purpose DBMSs can often be used for such purpose, if they provide basic user-interfaces for straightforward database applications (limited query and data display; no real programming needed), while still enjoying the database qualities and protections that these DBMSs can provide.
  • Federated database and multi-database
A federated database is an integrated database that comprises several distinct databases, each with its own DBMS. It is handled as a single database by a computer network, and may be geographically decentralized.
Sometime the term multi-database is used as a synonym to federated database, though it may refer to a less integrated (e.g., without an FDBMS and a managed integrated schema) group of databases that cooperate in a single application. In this case typically distributed (global) transactions (vs. local transactions confined to a single DBMS) across the participating databases.
  • Graph database
A graph database is a kind of NoSQL database that uses network databases.
  • Hypermedia databases
The web crawlers and other software provide the equivalent of database indexes to support search and other activities.
  • Hypertext database
In a Hypertext database, any word or a piece of text representing an object, e.g., another piece of text, an article, a picture, or a film, can be linked to that object. Hypertext databases are particularly useful for organizing large amounts of disparate information. For example they are useful for organizing online hyperlinks.
  • In-memory database
An in-memory database (IMDB; also main memory database or MMDB) is a database that primarily resides in main memory, but typically backed-up by non-volatile computer data storage. Main memory databases are faster than disk databases. Accessing data in memory reduces the I/O reading activity when, for example, querying the data. In applications where response time is critical, such as telecommunications network equipment, main memory databases are often used.[4]
  • Knowledge base
A knowledge base (abbreviated KB, kb or Δknowledge. Also a collection of data representing problems with their solutions and related experiences.
  • Operational database
These databases store detailed data about the operations of an organization. They are typically organized by subject matter, process relatively high volumes of updates using customer databases that record contact, credit, and demographic information about a business’ customers, personnel databases that hold information such as salary, benefits, skills data about employees, Enterprise resource planning that record details about product components, parts inventory, and financial databases that keep track of the organization’s money, accounting and financial dealings.
  • Parallel database
A parallel database, run by a parallel DBMS, seeks to improve performance through storage in parallel. In parallel processing, many operations are performed simultaneously, as opposed to serial, sequential processing, where operations are performed with no time overlap.
The major parallel DBMS architectures (which are induced by the underlying hardware architecture are:

  • Shared memory architecture, where multiple processors share the main memory space, as well as other data storage.
  • Shared disk architecture, where each processing unit (typically consisting of multiple processors) has its own main memory, but all units share the other storage.
  • Shared nothing architecture, where each processing unit has its own main memory and other storage.
  • Real-time database
If a DBMS system responses users’ request in a given time period, it can be regarded as a real time database.
  • Spatial database
A spatial database can store the data with multidimensional features. The queries on such data include location based queries, like “where is the closest hotel in my area”.
  • Temporal database
A temporal database is a database with built-in time aspects, for example a temporal data model and a temporal version of Structured Query Language (SQL). More specifically the temporal aspects usually include valid-time and transaction-time.
  • Unstructured-data database
An unstructured-data database is intended to store in a manageable and protected way diverse objects that do not fit naturally and conveniently in common databases. It may include email messages, documents, journals, multimedia objects etc. The name may be misleading since some objects can be highly structured. However, the entire possible object collection does not fit into a predefined structured framework. Most established DBMSs now support unstructured data in various ways, and new dedicated DBMSs are emerging.

[edit] Major database usage requirements

The major purpose of a database is to provide the information system (in its broadest sense) that utilizes it with the information the system needs according to its own requirements. A certain broad set of requirements refines this general goal. These database requirements translate to requirements for the respective DBMS, to allow conveniently building a proper database for the given application. If this goal is met by a DBMS, then the designers and builders of the specific database can concentrate on the application’s aspects, and not deal with building and maintaining the underlying DBMS. Also, since a DBMS is complex and expensive to build and maintain, it is not economical to build such a new tool (DBMS) for every application. Rather it is desired to provide a flexible tool for handling databases for as many as possible given applications, i.e., a general-purpose DBMS.

[edit] Functional requirements

Certain general functional requirements need to be met in conjunction with a database. They describe what is needed to be defined in a database for any specific application.

The database’s structure must be defined. The database needs to be based on a Data definition languages exist to describe the databases within the data model. Such languages are typically data model specific.

A database data model needs support by a sufficiently rich data manipulation language to allow database manipulations, and for information to be generated from the data. Such language is typically data model specific.

A database needs built-in programs). Protection is also provided from types of unintentional breach. Security types and levels should be defined by the database owners.

Manipulating database data often involves processes of several interdependent steps, at different times (e.g., when different people’s interactions are involved; e.g., generating an insurance policy). Data manipulation languages are typically intended to describe what is needed in a single such step. Dealing with multiple steps typically requires writing quite complex programs. Most applications are programmed using common business processes with supporting languages and software packages which considerably simplify the tasks. Traditionally these frameworks have been out of the scope of common DBMSs, but utilization of them has become common-place, and often they are provided as add-ons to DBMSs.

[edit] Operational requirements

Operational requirements are needed to be met by a database in order to effectively support an application when operational. Though it typically may be expected that operational requirements are automatically met by a DBMS, in fact it is not so in most of the cases: To be met substantial work of design and tuning is typically needed by database administrators. This is typically done by specific instructions/operations through special database user interfaces and tools, and thus may be viewed as secondary functional requirements (which are not less important than the primary).

[edit] Availability

A DB should maintain needed levels of availability, i.e., the DB needs to be available in a way that a user’s action does not need to wait beyond a certain time range before starting executing upon the DB. Availability also relates to failure and recovery from it (see Recovery from failure and disaster below): Upon failure and during recovery normal availability changes, and special measures are needed to satisfy availability requirements.

[edit] Performance

Users’ actions upon the DB should be executed within needed time ranges.

[edit] Isolation between users

When multiple users access the database concurrently the actions of a user should be uninterrupted and unaffected by actions of other users. These concurrent actions should maintain the DB’s consistency (i.e., keep the DB from corruption).

[edit] Recovery from failure and disaster

All computer systems, including DBMSs, are prone to failures for many reasons (both software and hardware related). Failures typically corrupt the DB, typically to the extent that it is impossible to repair it without special measures. The DBMS should provide automatic recovery from failure procedures that repair the DB and return it to a well defined state.

[edit] Backup and restore

Sometimes it is desired to bring a database back to a previous state (for many reasons, e.g., cases when the database is found corrupted due to a software error, or if it has been updated with erroneous data). To achieve this a backup operation is done occasionally or continuously, where each desired database state (i.e., the values of its data and their embedding in database’s data structures) is kept within dedicated backup files (many techniques exist to do this effectively). When this state is needed, i.e., when it is decided by a database administrator to bring the database back to this state (e.g., by specifying this state by a desired point in time when the database was in this state), these files are utilized to restore that state.

[edit] Data independence

Data independence pertains to a database’s life cycle (see Database building, maintaining, and tuning below). It strongly impacts the convenience and cost of maintaining an application and its database, and has been the major motivation for the emergence and success of the Relational model, as well as the convergence to a common database architecture. In general the term “data independence” means that changes in the database’s structure do not require changes in its application’s computer programs, and that changes in the database at a certain architectural level (see below) do not affect the database’s levels above. Data independence is achieved to a great extent in contemporary DBMS, but it is not completely attainable, and achieved at different degrees for different types of database structural changes.

[edit] Major database functional areas

The functional areas are domains and subjects that have evolved in order to provide proper answers and solutions to the functional requirements above.

[edit] Data models

A data model is an abstract structure that provides the means to effectively describe specific data structures needed to model an application. As such a data model needs sufficient expressive power to capture the needed aspects of applications. These applications are often typical to commercial companies and other organizations (like manufacturing, human-resources, stock, banking, etc.). For effective utilization and handling it is desired that a data model is relatively simple and intuitive. This may be in conflict with high expressive power needed to deal with certain complex applications. Thus any popular general-purpose data model usually well balances between being intuitive and relatively simple, and very complex with high expressive power. The application’s semantics is usually not explicitly expressed in the model, but rather implicit (and detailed by documentation external to the model) and hinted to by data item types’ names (e.g., “part-number”) and their connections (as expressed by generic data structure types provided by each specific model).

[edit] Early data models

These models were popular in the 1960s, 1970s, but nowadays can be found primarily in old data independence.

[edit] Hierarchical model

In the Hierarchical model different record types (representing real-world entities) are embedded in a predefined hierarchical (pointers combined with sequential accessing.

This model has been supported primarily by the IBM IMS DBMS, one of the earliest DBMSs. Various limitations of the model have been compensated at later IMS versions by additional logical hierarchies imposed on the base physical hierarchy.

[edit] Network model

In this model a hierarchical relationship between two record types (representing real-world entities) is established by the set construct. A set consists of circular directed graph (ownership defines a direction), or network construct. Access to records is either sequential (usually in each record type) or by navigation in the circular linked lists.

This model is more general and powerful than the hierarchical, and has been the most popular before being replaced by the Relational model. It has been IDMS. IDMS gained a considerable customer base and exists and supported until today. In the 1980s it has adopted the Relational model and SQL in addition to its original tools and languages.

[edit] Inverted file model

An inverted file or database indexes. The related Inverted file data model utilizes inverted files of primary database files to efficiently directly access needed records in these files.

Notable for using this data model is the Software AG, introduced in 1970. ADABAS has gained considerable customer base and exists and supported until today. In the 1980s it has adopted the Relational model and SQL in addition to its original tools and languages.

[edit] Relational model

The relational model is a simple model that provides flexibility. It organizes data based on two-dimensional arrays known as relations, or tables as related to databases. These relations consist of a heading and a set of zero or more tuples in arbitrary order. The heading is an unordered set of zero or more attributes, or columns of the table. The tuples are a set of unique attributes mapped to values, or the rows of data in the table. Data can be associated across multiple tables with a key. A key is a single, or set of multiple, attribute(s) that is common to both tables. The most common language associated with the relational model is the Structured Query Language (SQL), though it differs in some places.

[edit] Entity-relationship model

[edit] Object model

In recent years, the polymorphism, into the world of databases.

A variety of these ways have been tried[which?] have attacked the problem from the database end, by defining an object-oriented data model for the database, and defining a database programming language that allows full programming capabilities as well as traditional query facilities.

[edit] Object relational model

[edit] XML as a database data model

[edit] Other database models

Products offering a more general data model than the relational model are sometimes classified as post-relational.[7] Alternate terms include “hybrid database”, “Object-enhanced RDBMS” and others. The data model in such products incorporates relations but is not constrained by E.F. Codd‘s Information Principle, which requires that

all information in the database must be cast explicitly in terms of values in relations and in no other way[8]

Some of these extensions to the relational model integrate concepts from technologies that pre-date the relational model. For example, they allow representation of a directed graph with GraphDB.

Some post-relational products extend relational systems with non-relational features. Others arrived in much the same place by adding relational features to pre-relational systems. Paradoxically, this allows products that are historically pre-relational, such as MUMPS, to make a plausible claim to be post-relational.

The resource space model (RSM) is a non-relational data model based on multi-dimensional classification.[9]

[edit] Database languages

Database languages are dedicated programming languages, tailored and utilized to

  • define a database (i.e., its specific data types and the relationships among them),
  • manipulate its content (e.g., insert new data occurrences, and update or delete existing ones), and
  • query it (i.e., request information: compute and retrieve any information based on its data).

Database languages are data-model-specific, i.e., each language assumes and is based on a certain structure of the data (which typically differs among different data models). They typically have commands to instruct execution of the desired operations in the database. Each such command is equivalent to a complex expression (program) in a regular programming language, and thus programming in dedicated (database) languages simplifies the task of handling databases considerably. An expressions in a database language is automatically transformed (by a compiler or interpreter, as regular programming languages) to a proper computer program that runs while accessing the database and providing the needed results. The following are notable examples:

[edit] SQL for the Relational model

A major Relational model language supported by all the relational DBMSs and a standard.

SQL was one of the first commercial languages for the relational model. Despite not adhering to vendor lock-in.

[edit] OQL for the Object model

An EJB QL, though they cannot be considered as different flavors of OQL.

[edit] XQuery for the XML model

XQuery is an XML based database language (also named XQL). SQL/XML combines XQuery and XML with SQL.[12]

[edit] Database architecture

Database architecture (to be distinguished from DBMS architecture; [13]

  • The external level defines how each end-user type understands the organization of its respective relevant data in the database, i.e., the different needed end-user views. A single database can have any number of views at the external level.
  • The conceptual level unifies the various external views into a coherent whole, global view.[13] It provides the common-denominator of all the external views. It comprises all the end-user needed generic data, i.e., all the data from which any view may be derived/computed. It is provided in the simplest possible way of such generic data, and comprises the back-bone of the database. It is out of the scope of the various database end-users, and serves database application developers and defined by database administrators that build the database.
  • The Internal level (or Physical level) is as a matter of fact part of the database implementation inside a DBMS (see Implementation section below). It is concerned with cost, performance, scalability and other operational matters. It deals with storage layout of the conceptual level, provides supporting storage-structures like materialized views), computed from generic data, if performance justification exists for such redundancy. It balances all the external views’ performance requirements, possibly conflicting, in attempt to optimize the overall database usage by all its end-uses according to the database goals and priorities.

All the three levels are maintained and updated according to changing needs by database administrators who often also participate in the database design.

The above three-level database architecture also relates to and being motivated by the concept of data independence which has been described for long time as a desired database property and was one of the major initial driving forces of the Relational model. In the context of the above architecture it means that changes made at a certain level do not affect definitions and software developed with higher level interfaces, and are being incorporated at the higher level automatically. For example, changes in the internal level do not affect application programs written using conceptual level interfaces, which saves substantial change work that would be needed otherwise.

In summary, the conceptual is a level of indirection between internal and external. On one hand it provides a common view of the database, independent of different external view structures, and on the other hand it is uncomplicated by details of how the data are stored or managed (internal level). In principle every level, and even every external view, can be presented by a different data model. In practice usually a given DBMS uses the same data model for both the external and the conceptual levels (e.g., relational model). The internal level, which is hidden inside the DBMS and depends on its implementation (see Implementation section below), requires a different level of detail and uses its own data structure types, typically different in nature from the structures of the external and conceptual levels which are exposed to DBMS users (e.g., the data models above): While the external and conceptual levels are focused on and serve DBMS users, the concern of the internal level is effective implementation details.

[edit] Database security

Database security deals with all various aspects of protecting the database content, its owners, and its users. It ranges from protection from intentional unauthorized database uses to unintentional database accesses by unauthorized entities (e.g., a person or a computer program).

The following are major areas of database security (among many others).

[edit] Access control

Database access control deals with controlling who (a person or a certain computer program) is allowed to access what information in the database. The information may comprise specific database objects (e.g., record types, specific records, data structures), certain computations over certain objects (e.g., query types, or specific queries), or utilizing specific access paths to the former (e.g., using specific indexes or other data structures to access information).

Database access controls are set by special authorized (by the database owner) personnel that uses dedicated protected security DBMS interfaces.

[edit] Data security

The definition of data security varies and may overlap with other database security aspects. Broadly it deals with protecting specific chunks of data, both physically (i.e., from corruption, or destruction, or removal; e.g., see Data encryption).

[edit] Database audit

Database audit primarily involves monitoring that no security breach, in all aspects, has happened. If security breach is discovered then all possible corrective actions are taken.

[edit] Database design

Database design is done before building it to meet needs of end-users within a given application/information-system that the database is intended to support. The database design defines the needed data and data structures that such a database comprises. A design is typically carried out according to the common three architectural levels of a database (see Database architecture above). First, the conceptual level is designed, which defines the over-all picture/view of the database, and reflects all the real-world elements (entities) the database intends to model, as well as the relationships among them. On top of it the external level, various views of the database, are designed according to (possibly completely different) needs of specific end-user types. More external views can be added later. External views requirements may modify the design of the conceptual level (i.e., add/remove entities and relationships), but usually a well designed conceptual level for an application well supports most of the needed external views. The conceptual view also determines the internal level (which primarily deals with data layout in storage) to a great extent. External views requirement may add supporting storage structures, like materialized views and indexes, for enhanced performance. Typically the internal layer is optimized for top performance, in an average way that takes into account performance requirements (possibly conflicting) of different external views according to their relative importance. While the conceptual and external levels design can usually be done independently of any DBMS (DBMS-independent design software packages exist, possibly with interfaces to some specific popular DBMSs), the internal level design highly relies on the capabilities and internal data structure of the specific DBMS utilized (see the Implementation section below).

A common way to carry out conceptual level design is to use the entity-relationship model (ERM) (both the basic one, and with possible enhancement that it has gone over), since it provides a straightforward, intuitive perception of an application’s elements and semantics. An alternative approach, which preceded the ERM, is using the Relational model and dependencies (mathematical relationships) among data to normalize the database, i.e., to define the (“optimal”) relations (data record or tupple types) in the database. Though a large body of research exists for this method it is more complex, less intuitive, and not more effective than the ERM method. Thus normalization is less utilized in practice than the ERM method.

The ERM may be less subtle than normalization in several aspects, but it captures the main needed dependencies which are induced by keys/identifiers of entities and relationships. Also the ERM inherently includes the important inclusion dependencies (i.e., an entity instance that does not exist (has not been explicitly inserted) cannot appear in a relationship with other entities) which usually have been ignored in normalization.[14] In addition the ERM allows entity type generalization (the Is-a relationship) and implied property (attribute) inheritance (similarly to the that found in the object model).

Another aspect of database design is its security. It involves both defining access control to database objects (e.g., Entities, Views) as well as defining security levels and methods for the data themselves (See Database security above).

[edit] Entities and relationships

The most common database design methods are based on the entity relationship model (ERM, or ER model). This model views the world in a simplistic but very powerful way: It consists of “Entities” and the “Relationships” among them. Accordingly a database consists of entity and relationship types, each with defined attributes (field types) that model concrete entities and relationships. Modeling a database in this way typically yields an effective one with desired properties (as in some normal forms; see normalization below). Such models can be translated to any other data model required by any specific DBMS for building an effective database.

[edit] Database normalization

In the design of a relational database, the process of organizing database relations to minimize redundancy is called normalization. The goal is to produce well-structured relations so that additions, deletions, and modifications of a field can be made in just one relation (table) without worrying about appearance and update of the same field in other relations. The process is algorithmic and based on dependencies (mathematical relations) that exist among relations’ field types. The process result is bringing the database relations into a certain “normal form”. Several normal forms exist with different properties.

[edit] Database building, maintaining, and tuning

After designing a database for an application arrives the stage of building the database. Typically an appropriate general-purpose DBMS can be selected to be utilized for this purpose. A DBMS provides the needed user interfaces to be utilized by database administrators to define the needed application’s data structures within the DBMS’s respective data model. Other user interfaces are used to select needed DBMS parameters (like security related, storage allocation parameters, etc.).

When the database is ready (all its data structures and other needed components are defined) it is typically populated with initial application’s data (database initialization, which is typically a distinct project; in many cases using specialized DBMS interfaces that support bulk insertion) before making it operational. In some cases the database becomes operational while empty from application’s data, and data are accumulated along its operation.

After completing building the database and making it operational arrives the database maintenance stage: Various database parameters may need changes and tuning for better performance, application’s data structures may be changed or added, new related application programs may be written to add to the application’s functionality, etc.

[edit] Miscellaneous areas

[edit] Database migration between DBMSs

See also Database migration in Data migration

A database built with one DBMS is not total costs of ownership-TCO), functional, and operational (different DBMSs may have different capabilities). The migration involves the database’s transformation from one DBMS type to another. The transformation should maintain (if possible) the database related application (i.e., all related application programs) intact. Thus, the database’s conceptual and external architectural levels should be maintained in the transformation. It may be desired that also some aspects of the architecture internal level are maintained. A complex or large database migration may be a complicated and costly (one-time) project by itself, which should be factored into the decision to migrate. This in spite of the fact that tools may exist to help migration between specific DBMS. Typically a DBMS vendor provides tools to help importing databases from other popular DBMSs.

[edit] Implementation: Database management systems

or How database usage requirements are met

A database management system (DBMS) is a system that allows to build and maintain databases, as well as to utilize their data and retrieve information from it. A DBMS implements solutions (see Major functional areas above) to the database usability requirements above. It defines the database type that it supports, as well as its functionality and operational capabilities. A DBMS provides the internal processes for external applications built on them. The end-users of some such specific application are usually exposed only to that application and do not directly interact with the DBMS. Thus end-users enjoy the effects of the underlying DBMS, but its internals are completely invisible to end-users. Database designers and database administrators interact with the DBMS through dedicated interfaces to build and maintain the applications’ databases, and thus need some more knowledge and understanding about how DBMSs operate and the DBMSs’ external interfaces and tuning parameters.

A DBMS consists of software that operates databases, providing storage, access, security, backup and other facilities to meet needed requirements. DBMSs can be categorized according to the database model(s) that they support, such as relational or XML, the type(s) of computer they support, such as a server cluster or a mobile phone, the query language(s) that access the database, such as SQL or XQuery, performance trade-offs, such as maximum scale or maximum speed or others. Some DBMSs cover more than one entry in these categories, e.g., supporting multiple query languages. Database software typically support the Open Database Connectivity (ODBC) standard which allows the database to integrate (to some extent) with other databases.

The development of a mature general-purpose DBMS typically takes several years and many man-years. Developers of DBMS typically update their product to follow and take advantage of progress in computer and storage technologies. Several DBMS products like Oracle and IBM DB2 have been in on-going development since the 1970s-1980s. Since DBMSs comprise a significant market, computer and storage vendors often take into account DBMS requirements in their own development plans.

[edit] DBMS architecture: major DBMS components

DBMS architecture specifies its components (including descriptions of their functions) and their interfaces. DBMS architecture is distinct from database architecture. The following are major DBMS components:

  • DBMS external interfaces – They are the means to communicate with the DBMS (both ways, to and from the DBMS) to perform all the operations needed for the DBMS. These can be operations on a database, or operations to operate and manage the DBMS. For example:
– Direct database operations: defining data types, assigning security levels, updating data, querying the database, etc.
– Operations related to DBMS operation and management: backup and restore, database recovery, security monitoring, database storage allocation and database layout configuration monitoring, performance monitoring and tuning, etc.
An external interface can be either a application programming interface (API) used for communication between an application program and the DBMS.
  • Database language engines (or processors) – Most operations upon databases are performed through expression in Database languages (see above). Languages exist for data definition, data manipulation and queries (e.g., SQL), as well as for specifying various aspects of security, and more. Language expressions are fed into a DBMS through proper interfaces. A language engine processes the language expressions (by a compiler or language interpreter) to extract the intended database operations from the expression in a way that they can be executed by the DBMS.
  • query plan (a partial order (tree) of operations) to be executed to compute the query result.
  • Database engine – Performs the received database operations on the database objects, typically at their higher-level representation.
  • Storage engine – translates the operations to low-level operations on the storage bits. In some references the Storage engine is viewed as part of the Database engine.
  • Transaction engine – for correctness and reliability purposes most DBMS internal operations are performed encapsulated in transactions (see below). Transactions can also be specified externally to the DBMS to encapsulate a group of operations. The transaction engine tracks all the transactions and manages their execution according to the transaction rules (e.g., proper concurrency control, and proper commit or abort for each).
  • DBMS management and operation component – Comprises many components that deal with all the DBMS management and operational aspects like performance monitoring and tuning, backup and restore, recovery from failure, security management and monitoring, database storage allocation and database storage layout monitoring, etc.

[edit] Database storage

Database storage is the container of the physical materialization of a database. It comprises the Internal (physical) level in the database architecture. It also contains all the information needed (e.g., File systems as intermediates for storage layout), storage properties and configuration setting are extremely important for the efficient operation of the DBMS, and thus are closely maintained by database administrators. A DBMS, while in operation, always has its database residing in several types of storage (e.g., memory and external storage). The database data and the additional needed information, possibly in very large amounts, are coded into bits. Data typically reside in the storage in structures that look completely different from the way the data look in the conceptual and external levels, but in ways that attempt to optimize (the best possible) these levels’ reconstruction when needed by users and programs, as well as for computing additional types of needed information from the data (e.g., when querying the database).

In principle the database storage can be viewed as a address space, where every bit of data has its unique address in this address space. Practically only a very small percentage of addresses is kept as initial reference points (which also requires storage), and most of the database data are accessed by indirection using displacement calculations (distance in bits from the reference points) and data structures which define access paths (using pointers) to all needed data in an effective manner, optimized for the needed data access operations.

[edit] Data

[edit] Coding the data and Error-correcting codes
  • Data are MPEG-4).
  • By adding bits to each encoded unit, the redundancy allows both to detect errors in coded data and to correct them based on mathematical algorithms. Errors occur regularly in low probabilities due to Cyclic redundancy check (CRC) method is typically used in storage for error detection.
[edit] Data compression

Data compression methods allow in many cases to represent a string of bits by a shorter bit string (“compress”) and reconstruct the original string (“decompress”) when needed. This allows to utilize substantially less storage (tens of percents) for many types of data at the cost of more computation (compress and decompress when needed). Analysis of trade-off between storage cost saving and costs of related computations and possible delays in data availability is done before deciding whether to keep certain data in a database compressed or not.

Data compression is typically controlled through the DBMS’s data definition interface, but in some cases may be a default and automatic.

[edit] Data encryption

For security reasons certain types of data (e.g., credit-card information) may be kept encrypted in storage to prevent the possibility of unauthorized information reconstruction from chunks of storage snapshots (taken either via unforeseen vulnerabilities in a DBMS, or more likely, by bypassing it).

Data encryption is typically controlled through the DBMS’s data definition interface, but in some cases may be a default and automatic.

[edit] Data storage types

This collection of bits describes both the contained database data and their related metadata (i.e., data that describe the contained data and allows computer programs to manipulate the database data correctly). The size of a database can nowadays be tens of byte is eight bits. The physical materialization of a bit can employ various existing technologies, while new and improved technologies are constantly under development. Common examples are:

  • Magnetic medium (e.g., in magnetic field in magnetic regions on a surface of material (two orientation directions, for 0 and 1).
  • integrated circuit (two states for 0 and 1).

These two examples are respectively for two major storage types:

  • Nonvolatile storage can maintain its bit states (0s and 1s) without electrical power supply, or when power supply is interrupted;
  • Volatile storage loses its bit values when power supply is interrupted (i.e., its content is erased).

Sophisticated storage units, which can, in fact, be effective dedicated parallel computers that support a large amount of nonvolatile storage, typically must include also components with volatile storage. Some such units employ EMC Symmetrix) and thus maintain the content of the volatile storage parts intact. Just before such a device’s batteries lose their power the device typically automatically backs-up its volatile content portion (into nonvolatile) and shuts off to protect its data.

Databases are usually too expensive (in terms of importance and needed investment in resources, e.g., time, money, to build them) to be lost by a power interruption. Thus at any point in time most of their content resides in nonvolatile storage. Even if for operational reason very large portions of them reside in volatile storage (e.g., tens of Gigabytes in volatile memory, for in-memory databases), most of this is backed-up in nonvolatile storage. A relatively small portion of this, which temporarily may not have nonvolatile backup, can be reconstructed by proper automatic database recovery procedures after volatile storage content loss.

More examples of storage types:

  • Volatile storage can be found in processors, computer memory (e.g., DRAM), etc.
  • Non-volatile storage types include Storage arrays, etc.
[edit] Storage metrics

Databases always use several types of storage when operational (and implied several when idle). Different types may significantly differ in their properties, and the optimal mix of storage types is determined by the types and quantities of operations that each storage type needs to perform, as well as considerations like physical space and energy consumption and dissipation (which may become critical for a large database). Storage types can be categorized by the following attributes:

  • Volatile/Nonvolatile.
  • Cost of the medium (e.g., per Megabyte), Cost to operate (cost of energy consumed per unit time).
  • Access speed (e.g., bytes per second).
  • Granularity — from fine to coarse (e.g., size in bytes of access operation).
  • Reliability (the probability of spontaneous bit value change under various conditions).
  • Maximal possible number of writes (of any specific bit or specific group of bits; could be constrained by the technology used (e.g., “write once” or “write twice”), or due to “physical bit fatigue,” loss of ability to distinguish between the 0, 1 states due to many state changes (e.g., in Flash memory)).
  • Power needed to operate (Energy per time; energy per byte accessed), Energy efficiency, Heat to dissipate.
  • Packaging density (e.g., realistic number of bytes per volume unit)
[edit] Protecting storage device content: Device mirroring (replication) and RAID
See also Disk storage replication

While a group of bits malfunction may be resolved by error detection and correction mechanisms (see above), storage device malfunction requires different solutions. The following solutions are commonly used and valid for most storage devices:

  • Device mirroring (replication) – A common solution to the problem is constantly maintaining an identical copy of device content on another device (typically of a same type). The downside is that this doubles the storage, and both devices (copies) need to be updated simultaneously with some overhead and possibly some delays. The upside is possible concurrent read of a same data group by two independent processes, which increases performance. When one of the replicated devices is detected to be defective, the other copy is still operational, and is being utilized to generate a new copy on another device (usually available operational in a pool of stand-by devices for this purpose).
  • Redundant array of independent disks (RAID) – This method generalizes the device mirroring above by allowing one device in a group of N devices to fail and be replaced with content restored (Device mirroring is RAID with N=2). RAID groups of N=5 or N=6 are common. N>2 saves storage, when comparing with N=2, at the cost of more processing during both regular operation (with often reduced performance) and defective device replacement.

Device mirroring and typical RAID are designed to handle a single device failure in the RAID group of devices. However, if a second failure occurs before the RAID group is completely repaired from the first failure, then data can be lost. The probability of a single failure is typically small. Thus the probability of two failures in a same RAID group in time proximity is much smaller (approximately the probability squared, i.e., multiplied by itself). If a database cannot tolerate even such smaller probability of data loss, then the RAID group itself is replicated (mirrored). In many cases such mirroring is done geographically remotely, in a different storage array, to handle also recovery from disasters (see disaster recovery above).

[edit] Database storage layout

Database bits are laid-out in storage in data-structures and grouping that can take advantage of both known effective algorithms to retrieve and manipulate them and the storage own properties. Typically the storage itself is design to meet requirements of various areas that extensively utilize storage, including databases. A DBMS in operation always simultaneously utilizes several storage types (e.g., memory, and external storage), with respective layout methods.

[edit] Database storage hierarchy

A database, while in operation, resides simultaneously in several types of storage. By the nature of contemporary computers most of the database part inside a computer that hosts the DBMS resides (partially replicated) in volatile storage. Data (pieces of the database) that are being processed/manipulated reside inside a processor, possibly in magnetic tapes, on which typically the least active parts of a large database may reside, or database backup generations.

Typically a correlation exists currently between storage speed and price, while the faster storage is typically volatile.

[edit] Data structures

A data structure is an abstract construct that embeds data in a well defined manner. An efficient data structure allows to manipulate the data in efficient ways. The data manipulation may include data insertion, deletion, updating and retrieval in various modes. A certain data structure type may be very effective in certain operations, and very ineffective in others. A data structure type is selected upon DBMS development to best meet the operations needed for the types of data it contains. Type of data structure selected for a certain task typically also takes into consideration the type of storage it resides in (e.g., speed of access, minimal size of storage chunk accessed, etc.). In some DBMSs database administrators have the flexibility to select among options of data structures to contain user data for performance reasons. Sometimes the data structures have selectable parameters to tune the database performance.

Databases may store data in many data structure types.[15] Common examples are the following:

[edit] Application data and DBMS data

A typical DBMS cannot store the data of the application it serves alone. In order to handle the application data the DBMS need to store these data in data structures that comprise specific data by themselves. In addition the DBMS needs its own data structures and many types of bookkeeping data like indexes and logs. The DBMS data are an integral part of the database and may comprise a substantial portion of it.

[edit] Database indexing

binary search with an adjacent reference to the location of the entry, analogous to the index in the back of a book. The same data can have multiple indexes (an employee database could be indexed by last name and hire date.)

Indexes affect performance, but not results. Database designers can add or remove indexes without changing application logic, reducing maintenance costs as the database grows and database usage evolves.

Given a particular query, the DBMS’ query optimizer is responsible for devising the most efficient strategy for finding matching data.

Indexes can speed up data access, but they consume space in the database, and must be updated each time the data are altered. Indexes therefore can speed data access but slow data maintenance. These two properties determine whether a given index is worth the cost.

[edit] Database data clustering

In many cases substantial performance improvement is gained if different types of database objects that are usually utilized together are laid in storage in proximity, being clustered. This usually allows to retrieve needed related objects from storage in minimum number of input operations (each sometimes substantially time consuming). Even for in-memory databases clustering provides performance advantage due to common utilization of large caches for input-output operations in memory, with similar resulting behavior.

For example it may be beneficial to cluster a record of an item in stock with all its respective order records. The decision of whether to cluster certain objects or not depends on the objects’ utilization statistics, object sizes, caches sizes, storage types, etc. In a relational database clustering the two respective relations “Items” and “Orders” results in saving the expensive execution of a Join operation between the two relations whenever such a join is needed in a query (the join result is already ready in storage by the clustering, available to be utilized).

[edit] Database materialized views

Often storage redundancy is employed to increase performance. A common example is storing materialized views, which consist of frequently needed external views or query results. Storing such views saves the expensive computing of them each time they are needed. The downsides of materialized views are the overhead incurred when updating them to keep them synchronized with their original updated database data, and the cost of storage redundancy.

[edit] Database and database object replication
See also Replication below

Occasionally a database employs storage redundancy by database objects replication (with one or more copies) to increase data availability (both to improve performance of simultaneous multiple end-user accesses to a same database object, and to provide resiliency in a case of partial failure of a distributed database). Updates of a replicated object need to be synchronized across the object copies. In many cases the entire database is replicated.

[edit] Database transactions

As with every software system, a DBMS that operates in a faulty computing environment is prone to failures of many kinds. A failure can corrupt the respective database unless special measures are taken to prevent this. A DBMS achieves certain levels of fault tolerance by encapsulating operations within transactions. The concept of a database transaction (or atomic transaction) has evolved in order to enable both a well understood database system behavior in a faulty environment where crashes can happen any time, and recovery from a crash to a well understood database state. A database transaction is a unit of work, typically encapsulating a number of operations over a database (e.g., reading a database object, writing, acquiring lock, etc.), an abstraction supported in database and also other systems. Each transaction has well defined boundaries in terms of which program/code executions are included in that transaction (determined by the transaction’s programmer via special transaction commands).

[edit] ACID rules

Every database transaction obeys the following rules:

  • Atomicity – Either the effects of all or none of its operations remain (“all or nothing” semantics) when a transaction is completed (committed or aborted respectively). In other words, to the outside world a committed transaction appears (by its effects on the database) to be indivisible, atomic, and an aborted transaction does not leave effects on the database at all, as if never existed.
  • Consistency – Every transaction must leave the database in a consistent (correct) state, i.e., maintain the predetermined integrity rules of the database (constraints upon and among the database’s objects). A transaction must transform a database from one consistent state to another consistent state (however, it is the responsibility of the transaction’s programmer to make sure that the transaction itself is correct, i.e., performs correctly what it intends to perform (from the application’s point of view) while the predefined integrity rules are enforced by the DBMS). Thus since a database can be normally changed only by transactions, all the database’s states are consistent. An aborted transaction does not change the database state it has started from, as if it never existed (atomicity above).
  • Isolation – Transactions cannot interfere with each other (as an end result of their executions). Moreover, usually (depending on concurrency control method) the effects of an incomplete transaction are not even visible to another transaction. Providing isolation is the main goal of concurrency control.
  • non-volatile memory).

[edit] Isolation, concurrency control, and locking

Isolation provides the ability for multiple users to operate on the database at the same time without corrupting the data.

  • Recoverabiliry schedule properties. Constraining database access operation execution typically means reduced performance (rates of execution), and thus concurrency control mechanisms are typically designed to provide the best performance possible under the constraints. Often, when possible without harming correctness, the serializability property is compromised for better performance. However, recoverability cannot be compromised, since such typically results in a quick database integrity violation.
  • Locking is the most common transaction concurrency control method in DBMSs, used to provide both serializability and recoverability for correctness. In order to access a database object a transaction first needs to acquire a lock for this object. Depending on the access operation type (e.g., reading or writing an object) and on the lock type, acquiring the lock may be blocked and postponed, if another transaction is holding a lock for that object.

[edit] Query optimization

A query is a request for information from a database. It can be as simple as “finding the address of a person with SS# 123-45-6789,” or more complex like “finding the average salary of all the employed married men in California between the ages 30 to 39, that earn less than their wives.” Queries results are generated by accessing relevant database data and manipulating them in a way that yields the requested information. Since database structures are complex, in most cases, and especially for not-very-simple queries, the needed data for a query can be collected from a database by accessing it in different ways, through different data-structures, and in different orders. Each different way typically requires different processing time. Processing times of a same query may have large variance, from a fraction of a second to hours, depending on the way selected. The purpose of query optimization, which is an automated process, is to find the way to process a given query in minimum time. The large possible variance in time justifies performing query optimization, though finding the exact optimal way to execute a query, among all possibilities, is typically very complex, time consuming by itself, may be too costly, and often practically impossible. Thus query optimization typically tries to approximate the optimum by comparing several common-sense alternatives to provide in a reasonable time a “good enough” plan which typically does not deviate much from the best possible result.

[edit] DBMS support for the development and maintenance of a database and its application

A DBMS typically intends to provide convenient environment to develop and later maintain an application built around its respective database type. A DBMS either provides such tools, or allows integration with such external tools. Examples for tools relate to database design, application programming, application program maintenance, database performance analysis and monitoring, database configuration monitoring, DBMS hardware configuration (a DBMS and related database may span computers, networks, and storage units) and related database mapping (especially for a distributed DBMS), storage allocation and database layout monitoring, storage migration, etc.

[edit] See also

[edit] References

  1. ^ Jeffrey Ullman and Jennifer widom 1997: First course in database systems, Prentice-Hall Inc., Simon & Schuster, Page 1, ISBN 0-13-861337-0.
  2. ^ C. W. Bachmann, The Programmer as Navigator
  3. ^ Graves, Steve. “COTS Databases For Embedded Systems”, Embedded Computing Design magazine, January, 2007. Retrieved on August 13, 2008.
  4. ^ “TeleCommunication Systems Signs up as a Reseller of TimesTen; Mobile Operators and Carriers Gain Real-Time Platform for Location-Based Services”. Business Wire. 2002-06-24. http://findarticles.com/p/articles/mi_m0EIN/is_2002_June_24/ai_87694370.
  5. ^ Argumentation in Artificial Intelligence by Iyad Rahwan, Guillermo R. Simari
  6. ^ “OWL DL Semantics”. http://www.obitko.com/tutorials/ontologies-semantic-web/owl-dl-semantics.html. Retrieved 10 December 2010.
  7. ^ Introducing databases by Stephen Chu, in Conrick, M. (2006) Health informatics: transforming healthcare with technology, Thomson, ISBN 0-17-012731-1, p. 69.
  8. ^ Date, C. J. (June 1, 1999). “When’s an extension not an extension?”. Intelligent Enterprise 2 (8). http://intelligent-enterprise.informationweek.com/db_area/archives/1999/990106/online1.jhtml;jsessionid=Y2UNK1QFKXMBTQE1GHRSKH4ATMY32JVN.
  9. 978-0-387-72771-4.
  10. ^ Chapple, Mike. “SQL Fundamentals”. Databases. About.com. http://databases.about.com/od/sql/a/sqlfundamentals.htm. Retrieved 2009-01-28.
  11. ^ “Structured Query Language (SQL)”. International Business Machines. October 27, 2006. http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=com.ibm.db2.udb.admin.doc/doc/c0004100.htm. Retrieved 2007-06-10.
  12. 3-8366-9609-6
  13. ^ Date 1990, pp. 31–32
  14. ^ Johann A. Makowsky, Victor M. Markowitz and Nimrod Rotics, 1986: “Entity-relationship consistency for relational schemas” Proceedings of the 1986 Conference on Database Theory (ICDT ’86), Lecture Notes in Computer Science, 1986, Volume 243/1986, pp. 306-322, Springer, doi:10.1007/3-540-17187-8_43
  15. Lightstone, Teorey & Nadeau 2007

[edit] Further reading

  • Ling Liu and Tamer M. Özsu (Eds.) (2009). “Encyclopedia of Database Systems, 4100 p. 60 illus. ISBN 978-0-387-49616-0.
  • Beynon-Davies, P. (2004). Database Systems. 3rd Edition. Palgrave, Houndmills, Basingstoke.
  • Connolly, Thomas and Carolyn Begg. Database Systems. New York: Harlow, 2002.
  • Date, C. J. (2003). An Introduction to Database Systems, Fifth Edition. Addison Wesley. ISBN 0-201-51381-1.
  • Gray, J. and Reuter, A. Transaction Processing: Concepts and Techniques, 1st edition, Morgan Kaufmann Publishers, 1992.
  • Kroenke, David M. and David J. Auer. Database Concepts. 3rd ed. New York: Prentice, 2007.
  • Lightstone, S.; Teorey, T.; Nadeau, T. (2007). Physical Database Design: the database professional’s guide to exploiting indexes, views, storage, and more. Morgan Kaufmann Press. ISBN 0-12-369389-6.
  • Teorey, T.; Lightstone, S. and Nadeau, T. Database Modeling & Design: Logical Design, 4th edition, Morgan Kaufmann Press, 2005. ISBN 0-12-685352-5

[edit] External links

This article uses material from the Wikipedia article Database, which is released under the Creative Commons Attribution-Share-Alike License 3.0.