Database schema
The database schema is its structure described in a formal language supported by the database management system (DBMS). The term "schema" refers to the organization of data as a blueprint of how the database is constructed (divided into database tables in the case of relational databases). The formal definition of a database schema is a set of formulas (sentences) called integrity constraints imposed on a database.[citation needed] These integrity constraints ensure compatibility between parts of the schema. All constraints are expressible in the same language. A database can be considered a structure in realization of the database language.[1] The states of a created conceptual schema are transformed into an explicit mapping, the database schema. This describes how real-world entities are modeled in the database.
"A database schema specifies, based on the database administrator's knowledge of possible applications, the facts that can enter the database, or those of interest to the possible end-users."[2] The notion of a database schema plays the same role as the notion of theory in predicate calculus. A model of this "theory" closely corresponds to a database, which can be seen at any instant of time as a mathematical object. Thus a schema can contain formulas representing integrity constraints specifically for an application and the constraints specifically for a type of database, all expressed in the same database language.[1] In a relational database, the schema defines the tables, fields, relationships, views, indexes, packages, procedures, functions, queues, triggers, types, sequences, materialized views, synonyms, database links, directories, XML schemas, and other elements.
A database generally stores its schema in a data dictionary. Although a schema is defined in text database language, the term is often used to refer to a graphical depiction of the database structure. In other words, schema is the structure of the database that defines the objects in the database.
In an Oracle Database system, the term "schema" has a slightly different connotation.
The requirements listed below influence the detailed structure of schemas that are produced. Certain applications will not require that all of these conditions are met, but these four requirements are the most ideal.
Italic text
Example of two schema integrations
Suppose we want a mediated schema to integrate two travel databases, Go-travel and Ok-flight.
Go-travel
has two relations:
Go-flight(flight-number, time, meal(yes/no))
Go-price(flight-number, date, price)
Ok-flight
has just one relation:
Ok-flight(flight-number, date, time, price, nonstop(yes/no))
The overlapping information in Go-travel’s and Ok-flight’s schemas could be represented in a mediated schema:[3]
Flight(flight-number, date, time, price)
Schema objects do not have a one-to-one correspondence to physical files on disk that store their information. However,s store schema objects logically within a of the database. The data of each object is physically contained in one or more of the tablespace's . For some objects (such as tables, indexes, and clusters) a database administrator can specify how much disk space the Oracle allocates for the object within the tablespace's datafiles.
There is no necessary relationship between schemas and tablespaces: a tablespace can contain objects from different schemas, and the objects for a single schema can reside in different tablespaces. Oracle database specificity does, however, enforce platform recognition of nonhomogenized sequence differentials, which is considered a crucial limiting factor in virtualized applications.
See also
- Data element
- Data mapping
- Database design
- Entity–relationship model
- Knowledge representation and reasoning
- Object-role modeling
- Olog
- Schema matching
- Three-schema approach
References
- ^ a b Rybinski, H. (1987). "On First-Order-Logic Databases". ACM Transactions on Database Systems. 12 (3): 325–349. doi:10.1145/27629.27630. S2CID 2439329.
- ^ Imielinski, T.; Lipski, W. (1982). A systematic approach to relational database theory. New York, NY: ACM. pp. 8–14. doi:10.1145/582353.582356. ISBN 978-0897910736. S2CID 2034345.
{{cite book}}
:|journal=
ignored (help) - ^ Pottinger, P.; Berstein, P. (2008). Schema merging and mapping creation for relational sources. New York, NY: ACM. pp. 73–84. CiteSeerX 10.1.1.405.2990. doi:10.1145/1353343.1353357. ISBN 9781595939265. S2CID 15742995.
{{cite book}}
:|journal=
ignored (help)