s
Section 5.3 Relations and Databases
365
S e c t I o n 5 . 3 Rel ations and databases
A database is a storehouse of associated information about some enterprise. The
user of a database can certainly retrieve some specific fact stored in the database.
But a well-designed database is more than simply a list of facts. The user can perform queries on the database to retrieve information not contained in any single
fact. The whole becomes more than the sum of its parts.
To design a useful and efficient computerized database, it is necessary
to model or represent the enterprise with which the database is concerned. A
conceptual model attempts to capture the important features and workings of
the enterprise. Considerable interaction with those who are familiar with the
enterprise may be required to obtain all the information necessary to formulate
the model.
entity-Relationship Model
One high-level representation of an enterprise is the entity-relationship model.
In this model, important objects, or entities, in the enterprise are identified,
together with their relevant attributes or properties. Then the relationships between these various entities are noted. This information is represented graphically by an entity-relationship diagram, or e-r diagram. In an E-R diagram,
rectangles denote entity sets, ellipses denote attributes, and diamonds denote
relationships.
example 19
The Pet Lovers of America Club (PLAC) wants to set up a database. PLAC has
bought mailing lists from commercial sources, and it is interested in people who
own pets and in some basic information about those pets, such as the name, type
of pet (dog, cat, and so on), and the breed.
Figure 5.10 shows an E-R diagram for the PLAC enterprise. This diagram
says that persons and pets are the entities. Persons have the attributes of Name,
Address, City, and State. Pets have the attributes of PetName, PetType, and Breed.
The diagram also shows that persons own pets. Thinking of the entities as sets, the
Person set and the Pet set, the relationship “owns” is a binary relation from Person
to Pet—the ownership relation is captured by (person, pet) ordered pairs. The “1”
and “N” on the connecting lines indicate that this binary relation is one-to-many;
that is, in this particular enterprise, one person can own many pets, but no pet has
multiple owners. (Pets with multiple owners would result in a many-to-many relation.) Also, in this example, some persons may own no pets, and some pets may
have no owners.
The fact that no pet has multiple owners is one of the “business rules” of
the enterprise. Such business rules are important to identify when designing
a database, because they can determine various features of the database, as we
will see.
Section 5.3 Relations and Databases
365
S e c t I o n 5 . 3 Rel ations and databases
A database is a storehouse of associated information about some enterprise. The
user of a database can certainly retrieve some specific fact stored in the database.
But a well-designed database is more than simply a list of facts. The user can perform queries on the database to retrieve information not contained in any single
fact. The whole becomes more than the sum of its parts.
To design a useful and efficient computerized database, it is necessary
to model or represent the enterprise with which the database is concerned. A
conceptual model attempts to capture the important features and workings of
the enterprise. Considerable interaction with those who are familiar with the
enterprise may be required to obtain all the information necessary to formulate
the model.
entity-Relationship Model
One high-level representation of an enterprise is the entity-relationship model.
In this model, important objects, or entities, in the enterprise are identified,
together with their relevant attributes or properties. Then the relationships between these various entities are noted. This information is represented graphically by an entity-relationship diagram, or e-r diagram. In an E-R diagram,
rectangles denote entity sets, ellipses denote attributes, and diamonds denote
relationships.
example 19
The Pet Lovers of America Club (PLAC) wants to set up a database. PLAC has
bought mailing lists from commercial sources, and it is interested in people who
own pets and in some basic information about those pets, such as the name, type
of pet (dog, cat, and so on), and the breed.
Figure 5.10 shows an E-R diagram for the PLAC enterprise. This diagram
says that persons and pets are the entities. Persons have the attributes of Name,
Address, City, and State. Pets have the attributes of PetName, PetType, and Breed.
The diagram also shows that persons own pets. Thinking of the entities as sets, the
Person set and the Pet set, the relationship “owns” is a binary relation from Person
to Pet—the ownership relation is captured by (person, pet) ordered pairs. The “1”
and “N” on the connecting lines indicate that this binary relation is one-to-many;
that is, in this particular enterprise, one person can own many pets, but no pet has
multiple owners. (Pets with multiple owners would result in a many-to-many relation.) Also, in this example, some persons may own no pets, and some pets may
have no owners.
The fact that no pet has multiple owners is one of the “business rules” of
the enterprise. Such business rules are important to identify when designing
a database, because they can determine various features of the database, as we
will see.