Object-Based Data Models
Object-based data models use concepts such as entities, attributes, and relationships. An
entity is a distinct object (a person, place, thing, concept, event) in the organization that is
to be represented in the database. An attribute is a property that describes some aspect of
the object that we wish to record, and a relationship is an association between entities.
Some of the more common types of object-based data model are:
n Entity–Relationship
n Semantic
n Functional
n Object-Oriented.
The Entity–Relationship model has emerged as one of the main techniques for database
design and forms the basis for the database design methodology used in this book. The
object-oriented data model extends the definition of an entity to include not only the
attributes that describe the state of the object but also the actions that are associated
with the object, that is, its behavior. The object is said to encapsulate both state and
behavior. We look at the Entity–Relationship model in depth in Chapters 11 and 12 and
the object-oriented model in Chapters 25–28. We also examine the functional data model
in Section 26.1.2.
Record-Based Data Models
In a record-based model, the database consists of a number of fixed-format records possibly
of differing types. Each record type defines a fixed number of fields, each typically
of a fixed length. There are three principal types of record-based logical data model: the
relational data model, the network data model, and the hierarchical data model. The
hierarchical and network data models were developed almost a decade before the relational
data model, so their links to traditional file processing concepts are more evident.
Relational data model
The relational data model is based on the concept of mathematical relations. In the relational
model, data and relationships are represented as tables, each of which has a number
of columns with a unique name. Figure 2.4 is a sample instance of a relational schema for
part of the DreamHome case study, showing branch and staff details. For example, it
shows that employee John White is a manager with a salary of £30,000, who works at
branch (branchNo) B005, which, from the first table, is at 22 Deer Rd in London. It is
important to note that there is a relationship between Staff and Branch: a branch office has
staff. However, there is no explicit link between these two tables; it is only by knowing
that the attribute branchNo in the Staff relation is the same as the branchNo of the Branch
relation that we can establish that a relationship exists.
Note that the relational data model requires only that the database be perceived by
the user as tables. However, this perception applies only to the logical structure of the
database, that is, the external and conceptual levels of the ANSI-SPARC architecture. It
does not apply to the physical structure of the database, which can be implemented using
a variety of storage structures. We discuss the relational data model in Chapter 3.
Network data model
In the network model, data is represented as collections of records, and relationships
are represented by sets. Compared with the relational model, relationships are explicitly
modeled by the sets, which become pointers in the implementation. The records are
organized as generalized graph structures with records appearing as nodes (also called
segments) and sets as edges in the graph. Figure 2.5 illustrates an instance of a network
schema for the same data set presented in Figure 2.4. The most popular network DBMS is
Computer Associates’ IDMS/ R. We discuss the network data model in more detail on the
Web site for this book (see Preface for the URL).
Hierarchical data model
The hierarchical model is a restricted type of network model. Again, data is represented as
collections of records and relationships are represented by sets. However, the hierarchical
model allows a node to have only one parent. A hierarchical model can be represented
as a tree graph, with records appearing as nodes (also called segments) and sets as edges.
Figure 2.6 illustrates an instance of a hierarchical schema for the same data set presented
in Figure 2.4. The main hierarchical DBMS is IBM’s IMS, although IMS also provides
non-hierarchical features. We discuss the hierarchical data model in more detail on the
Web site for this book (see Preface for the URL).
Record-based (logical) data models are used to specify the overall structure of the
database and a higher-level description of the implementation. Their main drawback lies
in the fact that they do not provide adequate facilities for explicitly specifying constraints
on the data, whereas the object-based data models lack the means of logical structure
specification but provide more semantic substance by allowing the user to specify constraints
on the data.
The majority of modern commercial systems are based on the relational paradigm,
whereas the early database systems were based on either the network or hierarchical data
models. The latter two models require the user to have knowledge of the physical database
being accessed, whereas the former provides a substantial amount of data independence.
Hence, while relational systems adopt a declarative approach to database processing (that
is, they specify what data is to be retrieved), network and hierarchical systems adopt a
navigational approach (that is, they specify how the data is to be retrieved).
Physical Data Models
Physical data models describe how data is stored in the computer, representing information
such as record structures, record orderings, and access paths. There are not as many
physical data models as logical data models, the most common ones being the unifying
model and the frame memory.
Conceptual Modeling
From an examination of the three-level architecture, we see that the conceptual schema is
the ‘heart’ of the database. It supports all the external views and is, in turn, supported by
the internal schema. However, the internal schema is merely the physical implementation
of the conceptual schema. The conceptual schema should be a complete and accurate
representation of the data requirements of the enterprise.† If this is not the case, some
information about the enterprise will be missing or incorrectly represented and we will
have difficulty fully implementing one or more of the external views.
Figure 2.6
A sample instance
of a hierarchical
schema.
† When we are discussing the organization in the context of database design we normally refer to the business
or organization as the enterprise.
Conceptual modeling, or conceptual database design, is the process of constructing
a model of the information use in an enterprise that is independent of implementation
details, such as the target DBMS, application programs, programming languages, or any
other physical considerations. This model is called a conceptual data model. Conceptual
models are also referred to as logical models in the literature. However, in this book we
make a distinction between conceptual and logical data models. The conceptual model is
independent of all implementation details, whereas the logical model assumes knowledge
of the underlying data model of the target DBMS. In Chapters 15 and 16 we present a
methodology for database design that begins by producing a conceptual data model, which
is then refined into a logical model based on the relational data model. We discuss database
design in more detail in Section 9.6.
Object-based data models use concepts such as entities, attributes, and relationships. An
entity is a distinct object (a person, place, thing, concept, event) in the organization that is
to be represented in the database. An attribute is a property that describes some aspect of
the object that we wish to record, and a relationship is an association between entities.
Some of the more common types of object-based data model are:
n Entity–Relationship
n Semantic
n Functional
n Object-Oriented.
The Entity–Relationship model has emerged as one of the main techniques for database
design and forms the basis for the database design methodology used in this book. The
object-oriented data model extends the definition of an entity to include not only the
attributes that describe the state of the object but also the actions that are associated
with the object, that is, its behavior. The object is said to encapsulate both state and
behavior. We look at the Entity–Relationship model in depth in Chapters 11 and 12 and
the object-oriented model in Chapters 25–28. We also examine the functional data model
in Section 26.1.2.
Record-Based Data Models
In a record-based model, the database consists of a number of fixed-format records possibly
of differing types. Each record type defines a fixed number of fields, each typically
of a fixed length. There are three principal types of record-based logical data model: the
relational data model, the network data model, and the hierarchical data model. The
hierarchical and network data models were developed almost a decade before the relational
data model, so their links to traditional file processing concepts are more evident.
Relational data model
The relational data model is based on the concept of mathematical relations. In the relational
model, data and relationships are represented as tables, each of which has a number
of columns with a unique name. Figure 2.4 is a sample instance of a relational schema for
part of the DreamHome case study, showing branch and staff details. For example, it
shows that employee John White is a manager with a salary of £30,000, who works at
branch (branchNo) B005, which, from the first table, is at 22 Deer Rd in London. It is
important to note that there is a relationship between Staff and Branch: a branch office has
staff. However, there is no explicit link between these two tables; it is only by knowing
that the attribute branchNo in the Staff relation is the same as the branchNo of the Branch
relation that we can establish that a relationship exists.
Note that the relational data model requires only that the database be perceived by
the user as tables. However, this perception applies only to the logical structure of the
database, that is, the external and conceptual levels of the ANSI-SPARC architecture. It
does not apply to the physical structure of the database, which can be implemented using
a variety of storage structures. We discuss the relational data model in Chapter 3.
Network data model
In the network model, data is represented as collections of records, and relationships
are represented by sets. Compared with the relational model, relationships are explicitly
modeled by the sets, which become pointers in the implementation. The records are
organized as generalized graph structures with records appearing as nodes (also called
segments) and sets as edges in the graph. Figure 2.5 illustrates an instance of a network
schema for the same data set presented in Figure 2.4. The most popular network DBMS is
Computer Associates’ IDMS/ R. We discuss the network data model in more detail on the
Web site for this book (see Preface for the URL).
Hierarchical data model
The hierarchical model is a restricted type of network model. Again, data is represented as
collections of records and relationships are represented by sets. However, the hierarchical
model allows a node to have only one parent. A hierarchical model can be represented
as a tree graph, with records appearing as nodes (also called segments) and sets as edges.
Figure 2.6 illustrates an instance of a hierarchical schema for the same data set presented
in Figure 2.4. The main hierarchical DBMS is IBM’s IMS, although IMS also provides
non-hierarchical features. We discuss the hierarchical data model in more detail on the
Web site for this book (see Preface for the URL).
Record-based (logical) data models are used to specify the overall structure of the
database and a higher-level description of the implementation. Their main drawback lies
in the fact that they do not provide adequate facilities for explicitly specifying constraints
on the data, whereas the object-based data models lack the means of logical structure
specification but provide more semantic substance by allowing the user to specify constraints
on the data.
The majority of modern commercial systems are based on the relational paradigm,
whereas the early database systems were based on either the network or hierarchical data
models. The latter two models require the user to have knowledge of the physical database
being accessed, whereas the former provides a substantial amount of data independence.
Hence, while relational systems adopt a declarative approach to database processing (that
is, they specify what data is to be retrieved), network and hierarchical systems adopt a
navigational approach (that is, they specify how the data is to be retrieved).
Physical Data Models
Physical data models describe how data is stored in the computer, representing information
such as record structures, record orderings, and access paths. There are not as many
physical data models as logical data models, the most common ones being the unifying
model and the frame memory.
Conceptual Modeling
From an examination of the three-level architecture, we see that the conceptual schema is
the ‘heart’ of the database. It supports all the external views and is, in turn, supported by
the internal schema. However, the internal schema is merely the physical implementation
of the conceptual schema. The conceptual schema should be a complete and accurate
representation of the data requirements of the enterprise.† If this is not the case, some
information about the enterprise will be missing or incorrectly represented and we will
have difficulty fully implementing one or more of the external views.
Figure 2.6
A sample instance
of a hierarchical
schema.
† When we are discussing the organization in the context of database design we normally refer to the business
or organization as the enterprise.
Conceptual modeling, or conceptual database design, is the process of constructing
a model of the information use in an enterprise that is independent of implementation
details, such as the target DBMS, application programs, programming languages, or any
other physical considerations. This model is called a conceptual data model. Conceptual
models are also referred to as logical models in the literature. However, in this book we
make a distinction between conceptual and logical data models. The conceptual model is
independent of all implementation details, whereas the logical model assumes knowledge
of the underlying data model of the target DBMS. In Chapters 15 and 16 we present a
methodology for database design that begins by producing a conceptual data model, which
is then refined into a logical model based on the relational data model. We discuss database
design in more detail in Section 9.6.
No comments: