A DATABASE is an organized collection of data . It is the collection of schemas , tables , queries , reports, views , and other objects. The data are typically organized to model aspects of reality in a way that supports processes requiring information, such as modelling the availability of rooms in hotels in a way that supports finding a hotel with vacancies.
A DATABASE MANAGEMENT SYSTEM (DBMS) is a computer software
application that interacts with the user, other applications, and the
database itself to capture and analyze data. A general-purpose
* 1 Terminology and overview * 2 Applications * 3 General-purpose and special-purpose DBMSs
* 4 History
* 4.1 1960s, navigational
* 5 Research * 6 Examples
* 7 Design and modeling
* 7.1 Models * 7.2 External, conceptual, and internal views
* 8 Languages
* 9 Performance, security, and availability
* 9.1 Storage
* 9.1.1 Materialized views * 9.1.2 Replication
* 9.2 Security
* 9.3 Transactions and concurrency
* 9.4 Migration
* 9.5 Building, maintaining, and tuning
* 10 See also * 11 Notes * 12 References * 13 Sources * 14 Further reading * 15 External links
TERMINOLOGY AND OVERVIEW
Formally, a "database" refers to a set of related data and the way it is organized. Access to this data is usually provided by a "database management system" (DBMS) consisting of an integrated set of computer software that allows users to interact with one or more databases and provides access to all of the data contained in the database (although restrictions may exist that limit access to particular data). The DBMS provides various functions that allow entry, storage and retrieval of large quantities of information and provides ways to manage how that information is organized.
Because of the close relationship between them, the term "database"
is often used casually to refer to both a database and the
Outside the world of professional information technology , the term _database_ is often used to refer to any collection of related data (such as a spreadsheet or a card index). This article is concerned only with databases where the size and usage requirements necessitate use of a database management system.
Existing DBMSs provide various functions that allow management of a database and its data which can be classified into four main functional groups:
* DATA DEFINITION – Creation, modification and removal of definitions that define the organization of the data. * UPDATE – Insertion, modification, and deletion of the actual data. * RETRIEVAL – Providing information in a form directly usable or for further processing by other applications. The retrieved data may be made available in a form basically the same as it is stored in the database or in a new form obtained by altering or combining existing data from the database. * ADMINISTRATION – Registering and monitoring users, enforcing data security, monitoring performance, maintaining data integrity, dealing with concurrency control, and recovering information that has been corrupted by some event such as an unexpected system failure.
Both a database and its
Physically, database servers are dedicated computers that hold the
actual databases and run only the
Since DBMSs comprise a significant market , computer and storage
vendors often take into account
Databases and DBMSs can be categorized according to the database
model(s) that they support (such as relational or XML), the type(s) of
computer they run on (from a server cluster to a mobile phone), the
query language (s) used to access the database (such as
_ This section DOES NOT CITE ANY SOURCES . Please help improve this section by adding citations to reliable sources . Unsourced material may be challenged and removed . (March 2013)_ _(Learn how and when to remove this template message )_
Databases are used to support internal operations of organizations and to underpin online interactions with customers and suppliers (see Enterprise software ).
Databases are used to hold administrative information and more specialized data, such as engineering data or economic models. Examples of database applications include computerized library systems, flight reservation systems , computerized parts inventory systems , and many content management systems that store websites as collections of webpages in a database.
GENERAL-PURPOSE AND SPECIAL-PURPOSE DBMSS
Application software can often access a database on behalf of
end-users, without exposing the
Following the technology progress in the areas of processors , computer memory , computer storage , and computer networks , the sizes, capabilities, and performance of databases and their respective DBMSs have grown in orders of magnitude. The development of database technology can be divided into three eras based on data model or structure: navigational , SQL/relational , and post-relational.
The relational model , first proposed in 1970 by
Edgar F. Codd ,
departed from this tradition by insisting that applications should
search for data by content, rather than by following links. The
relational model employs sets of ledger-style tables, each used for a
different type of entity. Only in the mid-1980s did computing hardware
become powerful enough to allow the wide deployment of relational
systems (DBMSs plus applications). By the early 1990s, however,
relational systems dominated in all large-scale data processing
applications, and as of 2015 they remain dominant:
IBM DB2 , Oracle ,
MySQL , and
Microsoft SQL Server are the top
Object databases were developed in the 1980s to overcome the inconvenience of object-relational impedance mismatch , which led to the coining of the term "post-relational" and also the development of hybrid object-relational databases .
The next generation of post-relational databases in the late 2000s
became known as No
1960S, NAVIGATIONAL DBMS
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 . The Oxford English Dictionary cites a 1962 report by the System Development Corporation of California as the first to use the term "data-base" in a specific technical sense.
As computers grew in speed and capability, a number of
general-purpose database systems emerged; by the mid-1960s a number of
such systems had come into commercial use. Interest in a standard
began to grow, and
Charles Bachman , author of one such product, the
Integrated Data Store (IDS), founded the "
The CODASYL approach relied on the "manual" navigation of a linked data set which was formed into a large network. Applications could find records by one of three methods:
* Use of a primary key (known as a CALC key, typically implemented by hashing ) * Navigating relationships (called sets) from one record to another * Scanning all the records in a sequential order
Later systems added B-trees to provide alternate access paths. Many CODASYL databases also added a very straightforward query language. However, in the final tally, CODASYL was very complex and required significant training and effort to produce useful applications.
IBM also had their own
1970S, RELATIONAL DBMS
Edgar Codd worked at IBM in San Jose, California , in one of their offshoot offices that was primarily involved in the development of hard disk systems. He was unhappy with the navigational model of the CODASYL approach, notably the lack of a "search" facility.
In this paper, he described a new system for storing and working with
large databases. Instead of records being stored in some sort of
linked list of free-form records as in CODASYL, Codd's idea was to use
a "table " of fixed-length records, with each table used for a
different type of entity. A linked-list system would be very
inefficient when storing "sparse" databases where some of the data for
any one record could be left empty. The relational model solved this
by splitting the data into a series of normalized tables (or
_relations_), with optional elements being moved out of the main table
to where they would take up room only if needed.
The relational model also allowed the content of the database to evolve without constant rewriting of links and pointers. 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.
For instance, a common use of a database system is to track information about users, their name, login information, various addresses and phone numbers. In the navigational approach, all of this data would be placed in a single record, and unused items would simply not be placed in the database. In the relational approach, the data would be _normalized_ into a user table, an address table and a phone number table (for instance). Records would be created in these optional tables only if the address or phone numbers were actually provided.
Linking the information back together is the key to this system. In the relational model, some bit of information was used as a "key ", uniquely defining a particular record. When information was being collected about a user, information stored in the optional tables would be found by searching for this key. For instance, if the login name of a user is unique, addresses and phone numbers for that user would be recorded with the login name as its key. This simple "re-linking" of related data back into a single collection is something that traditional computer languages are not designed for.
Just as the navigational approach would require programs to loop in
order to collect records, the relational approach would require loops
to collect information about any _one_ record. Codd's suggestions was
a set-oriented language, that would later spawn the ubiquitous
Codd's paper was picked up by two people at Berkeley, Eugene Wong and
Michael Stonebraker . They started a project known as
IBM itself did one test implementation of the relational model, PRTV
, and a production one,
Business System 12 , both now discontinued.
In 1970, the
University of Michigan began development of the MICRO
Information Management System based on D.L. Childs' Set-Theoretic
Main article: Database machine
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 System/38 , the early offering of Teradata , and the Britton Lee, Inc. database machine.
Another approach to hardware support for database management was ICL 's CAFS accelerator, a hardware disk controller with programmable search capabilities. In the long term, these efforts were generally unsuccessful because specialized database machines could not keep pace with the rapid development and progress of general-purpose computers. Thus most database systems nowadays are software systems running on general-purpose hardware, using general-purpose computer data storage. However this idea is still pursued for certain applications by some companies like Netezza and Oracle ( Exadata ).
IBM started working on a prototype system loosely based on Codd's
concepts as _System R_ in the early 1970s. The first version was ready
in 1974/5, and work then started on multi-table systems in which the
data could be split so that all of the data for a record (some of
which is optional) did not have to be stored in a single large
"chunk". Subsequent multi-user versions were tested by customers in
1978 and 1979, by which time a standardized query language –
Larry Ellison 's Oracle started from a different chain, based on IBM's papers on System R, and beat IBM to market when the first version was released in 1978.
Stonebraker went on to apply the lessons from
In Sweden, Codd's paper was also read and Mimer
Another data model, the entity–relationship model , emerged in 1976 and gained popularity for 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.
1980S, ON THE DESKTOP
The 1980s ushered in the age of desktop computing . The new computers empowered their users with spreadsheets like Lotus 1-2-3 and database software like dBASE . The dBASE product was lightweight and easy for any computer user to understand out of the box. C. Wayne Ratliff the creator of dBASE stated: "dBASE was different from programs like BASIC, C, FORTRAN, and COBOL in that a lot of the dirty work had already been done. The data manipulation is done by dBASE instead of by the user, so the user can concentrate on what he is doing, rather than having to mess with the dirty details of opening, reading, and closing files, and managing space allocation." dBASE was one of the top selling software titles in the 1980s and early 1990s.
The 1990s, along with a rise in object-oriented programming , saw a growth in how data in various databases were handled. Programmers and designers began to treat the data in their databases as objects. That is to say that if a person's data were in a database, that person's attributes, such as their address, phone number, and age, were now considered to belong to that person instead of being extraneous data. This allows for relations between data to be relations to objects and their attributes and not to individual fields. The term "object-relational impedance mismatch " described the inconvenience of translating between programmed objects and database tables. Object databases and object-relational databases attempt to solve this problem by providing an object-oriented language (sometimes as extensions to SQL) that programmers can use as alternative to purely relational SQL. On the programming side, libraries known as object-relational mappings (ORMs) attempt to solve the same problem.
XML databases are a type of structured document-oriented database
that allows querying based on
In recent years, there was a high demand for massively distributed
databases with high partition tolerance but according to the CAP
theorem it is impossible for a distributed system to simultaneously
provide consistency , availability, and partition tolerance
guarantees. A distributed system can satisfy any two of these
guarantees at the same time, but not all three. For that reason, many
The database research area has several dedicated academic journals
(for example, _
ACM Transactions on Database Systems _-TODS, _
One 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. A third way is by some technical aspect, such as the database structure or interface type. This section lists a few of the adjectives used to characterize different kinds of databases.
* An in-memory database is a database that primarily resides in main
memory , but is typically backed-up by non-volatile computer data
Main memory databases are faster than disk databases, and so
are often used where response time is critical, such as in
telecommunications network equipment.
SAP HANA platform is a very hot
topic for in-memory database. By May 2012, HANA was able to run on
servers with 100TB main memory powered by IBM. The co founder of the
company claimed that the system was big enough to run the 8 largest
* An active database 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. Many databases provide active database features in the
form of database triggers .
* A cloud database relies on cloud technology . Both the database
and most of its
* A mobile database can be carried on or synchronized from a mobile computing device. * Operational databases store detailed data about the operations of an organization. They typically process relatively high volumes of updates using transactions . Examples include 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 systems that record details about product components, parts inventory, and financial databases that keep track of the organization's money, accounting and financial dealings. * A parallel database seeks to improve performance through parallelization for tasks such as loading data, building indexes and evaluating queries.
The major parallel
* 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.
* Probabilistic databases employ fuzzy logic to draw inferences from imprecise data. * Real-time databases process transactions fast enough for the result to come back and be acted on right away. * 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?". * A temporal database has built-in time aspects, for example a temporal data model and a temporal version of SQL. More specifically the temporal aspects usually include valid-time and transaction-time. * A terminology-oriented database builds upon an object-oriented database , often customized for a specific field. * 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.
DESIGN AND MODELING
The first task of a database designer is to produce a conceptual data model that reflects the structure of the information to be held in the database. A common approach to this is to develop an entity-relationship model, often with the aid of drawing tools. Another popular approach is the Unified Modeling Language . A successful data model will accurately reflect the possible state of the external world being modeled: for example, if people can have more than one phone number, it will allow this information to be captured. Designing a good conceptual data model requires a good understanding of the application domain; it typically involves asking deep questions about the things of interest to an organisation, like "can a customer also be a supplier?", or "if a product is sold with two different forms of packaging, are those the same product or different products?", or "if a plane flies from New York to Dubai via Frankfurt, is that one flight or two (or maybe even three)?". The answers to these questions establish definitions of the terminology used for entities (customers, products, flights, flight segments) and their relationships and attributes.
Producing the conceptual data model sometimes involves input from business processes , or the analysis of workflow in the organization. This can help to establish what information is needed in the database, and what can be left out. For example, it can help when deciding whether the database needs to hold historic data as well as current data.
Having produced a conceptual data model that users are happy with, the next stage is to translate this into a schema that implements the relevant data structures within the database. This process is often called logical database design, and the output is a logical data model expressed in the form of a schema. Whereas the conceptual data model is (in theory at least) independent of the choice of database technology, the logical data model will be expressed in terms of a particular database model supported by the chosen DBMS. (The terms _data model_ and _database model_ are often used interchangeably, but in this article we use _data model_ for the design of a specific database, and _database model_ for the modelling notation used to express that design.)
The most popular database model for general-purpose databases is the
relational model, or more precisely, the relational model as
represented by the
The final stage of database design is to make the decisions that affect performance, scalability, recovery, security, and the like. This is often called _physical database design_. A key goal during this stage is data independence , meaning that the decisions made for performance optimization purposes should be invisible to end-users and applications. There are two types of data independence: Physical data independence and logical data independence. Physical design is driven mainly by performance requirements, and requires a good knowledge of the expected workload and access patterns, and a deep understanding of the features offered by the chosen DBMS.
Another aspect of physical database design is security. It involves both defining access control to database objects as well as defining security levels and methods for the data itself.
Main article: Database model Collage of five types of database models
A database model is a type of data model that determines the logical structure of a database and fundamentally determines in which manner data can be stored, organized, and manipulated. The most popular example of a database model is the relational model (or the SQL approximation of relational), which uses a table-based format.
Common logical data models for databases include:
* Navigational databases
An object-relational database combines the two related structures.
Physical data models include:
* Inverted index * Flat file
Other models include:
* Associative model * Multidimensional model * Array model * Multivalue model
Specialized models are optimized for particular types of data:
EXTERNAL, CONCEPTUAL, AND INTERNAL VIEWS
Traditional view of data
A database management system provides three views of the database data:
* The EXTERNAL LEVEL defines how each group of end-users sees the organization of data in the database. A single database can have any number of views at the external level. * The CONCEPTUAL LEVEL unifies the various external views into a compatible global view. It provides the synthesis of all the external views. It is out of the scope of the various database end-users, and is rather of interest to database application developers and database administrators. * The INTERNAL LEVEL (or _physical level_) is the internal organization of data inside a DBMS. It is concerned with cost, performance, scalability and other operational matters. It deals with storage layout of the data, using storage structures such as indexes to enhance performance. Occasionally it stores data of individual views (materialized views ), computed from generic data, if performance justification exists for such redundancy. It balances all the external views' performance requirements, possibly conflicting, in an attempt to optimize overall performance across all activities.
While there is typically only one conceptual (or logical) and physical (or internal) view of the data, there can be any number of different external views. This allows users to see database information in a more business-related way rather than from a technical, processing viewpoint. For example, a financial department of a company needs the payment details of all employees as part of the company's expenses, but does not need details about employees that are the interest of the human resources department. Thus different departments need different _views_ of the company's database.
The three-level database architecture relates to the concept of _data independence_ which was one of the major initial driving forces of the relational model. The idea is that changes made at a certain level do not affect the view at a higher level. For example, changes in the internal level do not affect application programs written using conceptual level interfaces, which reduces the impact of making physical changes to improve performance.
The conceptual view provides 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 abstracts away 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
Separating the _external_, _conceptual_ and _internal_ levels was a major feature of the relational database model implementations that dominate 21st century databases.
A database language may also incorporate features like:
* DBMS-specific Configuration and storage engine management * Computations to modify query results, like counting, summing, averaging, sorting, grouping, and cross-referencing * Constraint enforcement (e.g. in an automotive database, only allowing one engine type per car) * Application programming interface version of the query language, for programmer convenience
PERFORMANCE, SECURITY, AND AVAILABILITY
Because of the critical importance of database technology to the smooth running of an enterprise, database systems include complex mechanisms to deliver the required performance, security, and availability, and allow database administrators to control the use of these features.
Some DBMSs support specifying which character encoding was used to store data, so multiple encodings can be used in the same database.
Various low-level database storage structures are used by the storage engine to serialize the data model so it can be written to the medium of choice. Techniques such as indexing may be used to improve performance. Conventional storage is row-oriented, but there are also column-oriented and correlation databases .
Main article: Materialized view
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.
Main article: Database replication
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.
_ This article APPEARS TO CONTRADICT THE ARTICLE DATABASE SECURITY . Relevant discussion may be found on the talk page . (March 2013)_ _(Learn how and when to remove this template message )_
Main article: 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).
This may be managed directly on an individual basis, or by the
assignment of individuals and privileges to groups, or (in the most
elaborate models) through the assignment of individuals and groups to
roles which are then granted entitlements.
Change and access logging records who accessed which attributes, what was changed, and when it was changed. Logging services allow for a forensic database audit later by keeping a record of access occurrences and changes. Sometimes application-level code is used to record changes rather than leaving this to the database. Monitoring can be set up to attempt to detect security breaches.
TRANSACTIONS AND CONCURRENCY
Further information: Concurrency control
Database transactions can be used to introduce some level of fault tolerance and data integrity after recovery from a crash . 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).
A database built with one
BUILDING, MAINTAINING, AND TUNING
Main article: Database tuning
After designing a database for an application, the next stage is
building the database. Typically, an appropriate general-purpose DBMS
can be selected to be utilized for this purpose. A
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
After the database is created, initialised and populated it needs to be maintained. Various database parameters may need changing and the database may need to be tuned (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.
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.
Static analysis techniques for software verification can be applied also in the scenario of query languages. In particular, the *Abstract interpretation framework has been extended to the field of query languages for relational databases as a way to support sound approximation techniques. The semantics of query languages can be tuned according to suitable abstractions of the concrete domain of data. The abstraction of relational database system has many interesting applications, in particular, for security purposes, such as fine grained access control, watermarking, etc.
For a topical guide to this subject, see Outline of databases .
* Book: Databases
Comparison of database tools
Comparison of object database management systems
Comparison of object-relational database management systems
Comparison of relational database management systems
* ^ This article quotes a development time of 5 years involving 750 people for DB2 release 9 alone.(Chong et al. 2007 )
* ^ "
* Bachman, Charles W. (1973). "The Programmer as Navigator". _Communications of the ACM_. 16 (11): 653–658. doi :10.1145/355611.362534 . (Subscription required (help)).
* Beynon–Davies, Paul (2003). _
* Chapple, Mike (2005). "
* Childs, David L. (1968a). "Description of a set-theoretic data structure" (PDF). _CONCOMP (Research in Conversational Use of Computers) Project_. Technical Report 3. University of Michigan.
* Childs, David L. (1968b). "Feasibility of a set-theoretic data structure: a general structure based on a reconstituted definition" (PDF). _CONCOMP (Research in Conversational Use of Computers) Project_. Technical Report 6. University of Michigan.
* Chong, Raul F.; Wang, Xiaomei; Dang, Michael; Snow, Dwaine R. (2007). "Introduction to DB2". _Understanding DB2: Learning Visually with Examples_ (2nd ed.). ISBN 978-0131580183 . Retrieved 17 March 2013.
* Date, C. J. (2003). _An Introduction to
* Halder, Raju; Cortesi, Agostino (2011). "Abstract Interpretation
* Hershey, William; Easthope, Carol (1972). _A set theoretic data structure and retrieval language_. Spring Joint Computer Conference, May 1972. _ACM SIGIR Forum_. 7 (4). pp. 45–55. doi :10.1145/1095495.1095500 .
* Nelson, Anne Fulcher; Nelson, William Harris Morehead (2001).
_Building Electronic Commerce: With Web
* North, Ken (10 March 2010). "Sets,
* Proctor, Seth (12 July 2013). "Exploring the Architecture of the NuoDB Database, Part 1". Archived from the original on 15 July 2013. Retrieved 12 July 2013.
* Tsitchizris, Dionysios C.; Lochovsky, Fred H. (1982). _Data Models_. Prentice–Hall. ISBN 978-0131964280 .
* Ullman, Jeffrey; Widom, Jennifer (1997). _A First Course in
* Wagner, Michael (2010), _SQL/XML:2006 – Evaluierung der Standardkonformität ausgewählter Datenbanksysteme_, Diplomica Verlag, ISBN 978-3836696098
* Ling Liu and Tamer M. Özsu (Eds.) (2009). "Encyclopedia of
* Teorey, T.; Lightstone, S. and Nadeau, T. _
* Definitions from Wiktionary * Media from Commons * News from Wikinews * Quotations from Wikiquote * Texts from Wikisource * Textbooks from Wikibooks * Learning resources from Wikiversity
* v * t * e
* Requirements * Theory * Models * Database management system * Machine * Server * Application
* datasource * DSN
* Administrator * Lock * Types * Tools
* information retrieval
* Activity monitoring * Audit * Forensics * Negative database
* Entities and relationships (and Enhanced notation) * Normalization * Refactoring
* Abstraction layer * Object-relational mapping
* Migration * Preservation * Integrity
* BOOK * CATEGORY * WIKIPROJECT
* v * t * e
* table * column * row
* Administration and automation * Query optimization * Replication
* v * t * e
* Flat * Hierarchical * Dimensional * Network * Relational
* Graph * Object-oriented * Entity–attribute–value
* v * t * e
CREATING THE DATA WAREHOUSE
* Dimension table * Degenerate * Slowly changing
* Extract-Transform-Load (ETL) * Extract * Transform * Load
USING THE DATA WAREHOUSE
* GND : 4113276-2 * NDL : 00865521
Links: ------ /wiki/Data_(computing) /#cite_note-1