Editing Conceptual schema (section)

== Overview ==

A conceptual schema is a map of [[concept]]s and their [[Relational model|relationships]] used for [[database]]s.  This describes the [[semantics]] of an organization and represents a series of [[Logical assertion|assertion]]s about its nature.  Specifically, it describes the things of significance to an [[organization]] (''entity classes''), about which it is inclined to collect information, and their characteristics (''attributes'') and the associations between pairs of those things of significance (''relationships'').

Because a conceptual schema represents the semantics of an organization, and not a [[database design]], it may exist on various levels of abstraction.  The original [[ANSI]] four-schema architecture began with the set of ''external schemata'' that each represents one person's view of the world around him or her.  These are consolidated into a single ''conceptual schema'' that is the superset of all of those external views.  A data model can be as concrete as each person's perspective, but this tends to make it inflexible.  If that person's world changes, the model must change.  Conceptual data models take a more abstract perspective, identifying the fundamental things, of which the things an individual deals with are just examples.

The model does allow for what is called [[Inheritance (object-oriented programming)|inheritance]] in [[object oriented]] terms.  The set of [[Instantiation (computer science)|instance]]s of an entity class may be subdivided into entity classes in their own right.  Thus, each instance of a ''sub-type'' entity class is also an instance of the entity class's ''super-type''. Each instance of the super-type entity class, then is also an instance of one of the sub-type entity classes.

[[supertype|Super-type]]/[[Subtyping|sub-type]] relationships may be ''[[exclusive relationship (programming)|exclusive]]'' or not. A methodology may require that each instance of a super-type may ''only'' be an instance of ''one'' sub-type. Similarly, a super-type/sub-type relationship may be ''exhaustive'' or not. It is exhaustive if the methodology requires that each instance of a super-type ''must be'' an instance of a sub-type. A sub-type named "Other" is often necessary.