Introduction to Entities and Attributes Logical Design Stage for Database Design
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:
Define entities and entity attributes
Explain the purpose of entity identifiers
List rules for creating entity identifiers
Describe instances of entities
Describe attribute domains and domain types
Explain the problem with multi-valued attributes
Describe how to resolve multi-valued attributes by adding more attributes
Describe how to resolve multi-valued attributes by creating a new entity
List entity and attribute constraints
Entities, Attributes, and Identifiers
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 Larry,
Curly, and Moe 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.
(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’ll 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.