A database may be defined as a collection of persistent data. The term persistent is somewhat vague, but is intended to imply that the data has a more-or-less independent existence or that it is semipermanent. For instance, data stored on paper in a filing cabinet, or stored magnetically on a hard disk, CD-ROM, or computer tape is persistent, whereas data stored in a computer’s memory is generally not considered to be persistent. (The term permanent is a bit too strong, since very little in life is truly permanent.)

Of course, this is a very general concept. Most real-life databases consist of data that exist for a specific purpose and are thus persistent.

The purpose of a database is to store information about certain types of objects. In database language, these objects are called entities . For example, the entities of the LIBRARY database include books, authors, and publishers.

It is very important at the outset to make a distinction between the entities that are contained in a database at a given time and the world of all possible entities that the database might contain. The reason this is important is that the contents of a database are constantly changing and we must make decisions based not just on what is contained in a database at a given time, but on what might be contained in the database in the future.

For example, at a given time, our LIBRARY database might contain 14 book entities. However, as time goes on, new books may be added to the database, and old books may be removed. Thus, the entities in the database are constantly changing. If, for example, based on the fact that the 14 books currently in the database have different titles, we decide to use the title to identify each book uniquely, we may be in for some trouble when, later on, a different book arrives at the library with the same title as a previous book.

The world of all possible entities of a specific type that a database might contain is referred to as an entity class . We will use italics to denote entity classes. Thus, for instance, the world of all possible books is the Books entity class, and the world of all possible authors is the Authors entity class.

We emphasize that an entity class is just an abstract description of something, whereas an entity is a concrete example of that description. The entity classes in our very modest LIBRARY example database are (at least so far):

The set of entities of a given entity class that are in the database at a given time is called an entity set . To clarify the difference between entity set and entity class with an example, consider the BOOKS table in the LIBRARY database, which is shown in Table 2-1.

The entities are books, the entity class is the set of all possible books, and the entity set (at this moment) is the specific set of 14 books listed in the BOOKS table. As mentioned, the entity set will change as new books (book entities) are added to the table or old ones are removed. However, the entity class does not change.

Incidentally, if you are familiar with object-oriented programming concepts, you will recognize the concept of a class . In object-oriented circles, we would refer to an entity class simply as a class and an entity as an object.

The entities of an entity class possess certain properties, which are called attributes. We usually refer to these attributes as attributes of the entity class itself. It is up to the database designer to determine which attributes to include for each entity class. It is these attributes that will correspond to the fields in the tables of the database.

The attributes of an entity class serve three main purposes:

For now, let us list the attributes for the LIBRARY database that we need to supply information about each entity and to identify each entity uniquely. I will deal with the issue of describing relationships later. Remember that this example is kept deliberately small—in real life we would no doubt include many other attributes.

The attributes of the entity classes in the LIBRARY database are:

Books attributes

Authors attributes

Publishers attributes

Let us make a few remarks about these attributes.

Let us emphasize that an entity class is a description, not a set. For instance, the entity class Books is a description of the attributes of the entities that we identify as books. A Books entity is the “database version” of a book. It is not a physical book, but rather a book as defined by the values of its attributes. For instance, the following is a Books entity:

Title = Gone With the Wind
ISBN = 0-12-345678-9
Price = $24.00

Now, there is certainly more than one physical copy in existence of the book Gone With the Wind, with this ISBN and price, but that is not relevant to our discussion. As far as the database is concerned, there is only one Books entity defined by:

Title = Gone With the Wind
ISBN = 0-12-345678-9
Price = $24.00

If we need to model multiple copies of physical books in our database (as a real library would do), then we must add another attribute to the Books entity class, perhaps called CopyNumber. Even still, a book entity is just a set of attribute values.

These matters emphasize the point that it is up to the database designer to ensure that the set of attributes for an entity uniquely identify the entity from among all other entities that may appear in the database (now and forever, if possible!). For instance, if the Books entity class included only the Title and Price attributes, there would certainly be cause to worry that someday we might want to include two books with the same title and price. While this is allowed in some database-application programs, it can lead to great confusion and is definitely not recommended. Moreover, it is forbidden by definition in a true relational database. In other words, no two entities can agree on all of their attributes. (This is allowed in Microsoft Access, however.)

A set of attributes that uniquely identifies any entity from among all possible entities in the entity class that may appear in the database is called a superkey for the entity class. Thus, the set {ISBN} is a superkey for the Books entity class, and the sets {PubID} and {PubName, PubPhone} are both superkeys for the Publishers entity class.

Note that there is a bit of subjectivity in this definition of superkey, since it depends ultimately on our decision about which entities may ever appear in the database, and this is probably something of which we cannot be absolutely certain. Consider, for instance, the Books entity class. There is no law that says all books must have an ISBN (and many books do not). Also, there is no law that says that two books cannot have the same ISBN. (The ISBN is assigned, at least in part, by the publisher of the book.) Thus, the set {ISBN} is a superkey only if we are willing to accept the fact that all books that the library purchases have distinct ISBNs or that the librarian will assign a uniqueersatz ISBN to any books that do not have a real ISBN.

It is important to emphasize that the concept of a superkey applies to entity classes, and not entity sets. Although we can define a superkey for an entity set, this is of limited use, since what may serve to identify the entities uniquely in a particular entity set may fail to do so if we add new entities to the set. To illustrate, the Title attribute does serve to identify each of the 14 books uniquely in the BOOKS table. Thus, {Title} is a superkey for the entity set described by the BOOKS table. However, {Title} is not a superkey for the Books entity class, since there are many distinct books with the same title.

We have remarked that {ISBN} is a superkey for the Books entity class. Of course, so is {Title, ISBN}, but it is wasteful and inefficient to include the Title attribute purely for the sake of identification.

Indeed, one of the difficulties with superkeys is that they may contain more attributes than is absolutely necessary to identify any entity uniquely. It is more desirable to work with superkeys that do not have this property. A superkey is called a key when it has the property that no proper subset of it is also a superkey. Thus, if we remove an attribute from a key, the resulting set is no longer a superkey. Put more succinctly, a key is a minimal superkey. Sometimes keys are called candidate keys, since it is usually the case that we want to select one particular key to use as an identifier. This particular choice is referred to as the primary key . The primary keys in the LIBRARY database are ISBN, AuID, and PubID.

I should remark that a key may contain more than one attribute, and different keys may have different numbers of attributes. For instance, it is reasonable to assume that both {SocialSecurityNumber} and {FullName, FullAddress, DateofBirth} are keys for a US Citizens entity class.

If we are going to model a database as a collection of entity sets (tables), then we also need to describe the relationships between these entity sets. For instance, an author relationship exists between a book and the authors who wrote that book. We might call this relationship WrittenBy. Thus, Hamlet is WrittenBy Shakespeare.

It is possible to draw a diagram, called an entity-relationship diagram, or E/R diagram,to illustrate the entity classes in a database model, along with their attributes and relationships. Figure 2-1 shows the LIBRARY E/R diagram, with an additional entity class called Contributors (a contributor may be someone who contributes to or writes only a very small portion of a book, and thus may not be accorded all of the rights of an author, such as a royalty).

Figure 2-1. The LIBRARY entity-relationship diagram

Note that each entity class is denoted by a rectangle, and each attribute by an ellipse. The relations are denoted by diamonds. We have included the Contributors entity class in this model merely to illustrate a special type of relationship. In particular, since a contributor is considered an author, there is an IsA relationship between the two entity classes.

The model represented by an E/R diagram is sometimes referred to as a semantic model since it describes much of the meaning of the database.