Why we need ER Model

To ensure that we get a precise understanding of the nature of the data and how
it is used by the enterprise, we need to have a model for communication that is
non-technical and free of ambiguities.

E R Model
The EntityRelationship (ER) model is one such example. ER modeling is a top-
down approach to database design that begins by identifying the important
data called entities and relationships between the data that must be represented
in the model. We then add more details such as the information we want to hold
about the entities and relationships called attributes and any constraints on the
entities, relationships, and attributes.

The conceptual schema is a concise description of the data requirements of the

users and includes detailed descriptions of the entity types, relationships, and
constraints; these are expressed using the concepts provided by the high-level
data model (i.e. ER Model). Because these concepts do not include
implementation details, they are usually easier to understand and can be used to
communicate with nontechnical users.

Most current commercial DBMSs use an implementation data model such as the
relational or the object-relational database model-so the conceptual schema is
transformed from the high-level data model (or conceptual Data Model, e.g. - ER
Model) into the implementation data model. This step is called logical design or
data model mapping, and its result is a database schema in the implementation
data model of the DBMS.

Reasons why this separation (External-Conceptual-Inernal ) is desirable:

1. Each user should be able to access the same data, but have a different
customized view of the data. Each user should be able to change the way
he or she views the data, and this change should not affect other users.
2. Users should not have to deal directly with physical database storage
details, such as indexing or hashing (see Appendix C). In other words, a
 users interaction with the database should be independent of storage
considerations.
The Database Administrator (DBA) should be able to change the database
storage structures without affecting the users views.
3. The internal structure of the database should be unaffected by changes to
the physical aspects of storage, such as the changeover to a new storage
device.
4. The DBA should be able to change the conceptual structure of the
database without affecting all users.

Data Sublanguage DDL DML

Data Definition language (DDL), is used by the DBA and by database designers
to define both schemas.(Conceptual & Internal) The DBMS will have a DDL
compiler whose function is to process DDL statements in order to identify
descriptions of the schema constructs and to store the schema description in the
DBMS catalog.
Host Language Java, C++ etc. [See Screenshot]
For a true three-schema architecture
View Definition Language for View Level to specify user views and their
mappings to the conceptual schema.
Storage Definition Language (SDL) is used to specify the internal schema. The
mappings between the two schemas may be specified in either one of these
languages.(SDL or DDL)
DDL is used to specify Conceptual Schema.

storage definition language (SDL), is used to specify the internal schema. The
mappings between the two schemas may be specified in either one of these
languages.

In current DBMSs, a comprehensive integrated language is used that includes

constructs for conceptual schema definition, view definition, ami data
manipulation. Storage definition is typically kept separate, since it is used for
defining physical storage structures to fine tune the performance of the
database system, which is usually done by the DBA staff.
A typical example of a comprehensive database language is the SQL relational
database language which represents a combination of DDL, VDL, and DML, as
well as statements for constraint specification, schema evolution, and other
features. The SDL was a component in early versions of SQL but has been
removed from the language to keep it at the conceptual and external levels only.

The description of the database is the database schema. The data in the
database at any particular point in time is called a database instance. Therefore,
many database instances can correspond to the same database schema. The
schema is sometimes called the intension of the database, while an instance is
called an extension (or state) of the database.

Description of Database (i.e. Database Schema) is stored in Catalogue.

Data Independence the capacity to change the schema at one level of a
database system without having to change the schema at the next higher level.
Data independence occurs because when the schema is changed at some level,
the schema at the next higher level remains unchanged; only the mapping
between the two levels is changed. Hence, application programs referring to the
higher-level schema need not be changed.

1. Logical data independence is the capacity to change the conceptual

schema without having to change external schernas or application
programs. We may change the conceptual schema to expand the database
(by adding a record type or dataitem), to change constraints, or to reduce
the database (by removing a record type or data item). Only the view
definition and the mappings need be changed in a DBMS that supports
logical data independence.

2. Physical data independence is the capacity to change the internal schema

without having to change the conceptual schema. Hence, the external
schemas need not be changed as well. Changes to the internal schema
may be needed because some physical files had to be reorganized-for
example, by creating additional access structures-to improve the
performance of retrieval or update.
Entity type A group of objects in the real world with the same properties, which
are identified by the enterprise as having an independent existence.