Lesson 1

Database designers begin the logical design stage by converting business objects and their characteristics into entities and attributes. They plug both entities and attributes into an ER diagram as the first step in designing a conceptual model.
Keep in mind that a conceptual model does not contain any data; rather, it illustrates the structures of a database, the architecture of the data container. Think of building a house: you build the house before you place any furniture inside. I advise against carrying this analogy too far: when you design a database, you build a house to fit the furniture you already have rather than buying furniture to fit the house.

After completing this module, you will be able to:

1. Define entities and entity attributes
2. Explain the purpose of entity identifiers
3. List rules for creating entity identifiers
4. Describe instances of entities
5. Describe attribute domains and domain types
6. Explain the problem with multi-valued attributes
7. Describe how to resolve multi-valued attributes by adding more attributes
8. Describe how to resolve multi-valued attributes by creating a new entity
9. List entity and attribute constraints

An entity is similar to a semantic object. It represents a specific instance of some thing that you want to track in the object model. Like semantic objects, an entity can be a physical thing (employee, work order) or a logical abstraction (appointment, discussion). Similar entities are grouped into entity classes or entity sets. For example, the employee entities Tom, Dick and Harry belong to the Employee entity set. Like semantic objects, entities include attributes that describe the object that they represent. There are a couple of different methods for drawing entity sets. In the first method, a set is contained within a rectangle. Its attributes are drawn within ellipses and attached to the set with lines. If one of the attributes is an identifier (also called a key or primary key), its name is underlined. Figure 5.1 shows a simple Employee entity set with three attributes. Some developers write entity set names in ALL CAPS, whereas others use Mixed Case.

One problem with this notation is that it takes up a lot of room. If you add all of the attributes to the Employee class (EmployeeId, FirstName, LastName, SocialSecurityNumber, Street, Suite, City, State, ZipCode, HomePhone, CellPhone, Fax, Email, and so forth), you will get a pretty cluttered picture. If you then try to add Department, Project, Manager, and other classes to the picture with all of their attributes, you can quickly build an incomprehensible data set.
A second approach is to draw entity sets in a manner similar to the one used by semantic object models and then place only the set’s name in the ER diagram. Lines and other symbols, which are described shortly, connect the entity sets to show their relationships. This approach allows you greater room for listing attributes while removing them from the main ER diagram so it can focus on relationships.
The next lesson describes entities and their attributes.