Data Models and Conceptual Modeling
We mentioned earlier that a schema is written using a data definition language. In fact, it
is written in the data definition language of a particular DBMS. Unfortunately, this type of
language is too low level to describe the data requirements of an organization in a way that
is readily understandable by a variety of users. What we require is a higher-level description
of the schema: that is, a data model.
Data An integrated collection of concepts for describing and manipulating data,
model relationships between data, and constraints on the data in an organization.
A model is a representation of ‘real world’ objects and events, and their associations. It is
an abstraction that concentrates on the essential, inherent aspects of an organization and
ignores the accidental properties. A data model represents the organization itself. It should
provide the basic concepts and notations that will allow database designers and end-users
unambiguously and accurately to communicate their understanding of the organizational
data. A data model can be thought of as comprising three components:
(1) a structural part, consisting of a set of rules according to which databases can be
constructed;
(2) a manipulative part, defining the types of operation that are allowed on the data (this
includes the operations that are used for updating or retrieving data from the database
and for changing the structure of the database);
(3) possibly a set of integrity constraints, which ensures that the data is accurate.
The purpose of a data model is to represent data and to make the data understandable. If
it does this, then it can be easily used to design a database. To reflect the ANSI-SPARC
architecture introduced in Section 2.1, we can identify three related data models:
(1) an external data model, to represent each user’s view of the organization, sometimes
called the Universe of Discourse (UoD);
(2) a conceptual data model, to represent the logical (or community) view that is DBMSindependent;
(3) an internal data model, to represent the conceptual schema in such a way that it can be
understood by the DBMS.
There have been many data models proposed in the literature. They fall into three broad
categories: object-based, record-based, and physical data models. The first two are used
to describe data at the conceptual and external levels, the latter is used to describe data at
the internal level.
We mentioned earlier that a schema is written using a data definition language. In fact, it
is written in the data definition language of a particular DBMS. Unfortunately, this type of
language is too low level to describe the data requirements of an organization in a way that
is readily understandable by a variety of users. What we require is a higher-level description
of the schema: that is, a data model.
Data An integrated collection of concepts for describing and manipulating data,
model relationships between data, and constraints on the data in an organization.
A model is a representation of ‘real world’ objects and events, and their associations. It is
an abstraction that concentrates on the essential, inherent aspects of an organization and
ignores the accidental properties. A data model represents the organization itself. It should
provide the basic concepts and notations that will allow database designers and end-users
unambiguously and accurately to communicate their understanding of the organizational
data. A data model can be thought of as comprising three components:
(1) a structural part, consisting of a set of rules according to which databases can be
constructed;
(2) a manipulative part, defining the types of operation that are allowed on the data (this
includes the operations that are used for updating or retrieving data from the database
and for changing the structure of the database);
(3) possibly a set of integrity constraints, which ensures that the data is accurate.
The purpose of a data model is to represent data and to make the data understandable. If
it does this, then it can be easily used to design a database. To reflect the ANSI-SPARC
architecture introduced in Section 2.1, we can identify three related data models:
(1) an external data model, to represent each user’s view of the organization, sometimes
called the Universe of Discourse (UoD);
(2) a conceptual data model, to represent the logical (or community) view that is DBMSindependent;
(3) an internal data model, to represent the conceptual schema in such a way that it can be
understood by the DBMS.
There have been many data models proposed in the literature. They fall into three broad
categories: object-based, record-based, and physical data models. The first two are used
to describe data at the conceptual and external levels, the latter is used to describe data at
the internal level.
No comments: