DATA MODEL BASIC BUILDING BLOCKS
The basic building blocks of all data models are entities, attributes, relationships, and constraints. An entity is anything (a
person, a place, a thing, or an event) about which data are to be collected and stored. An entity represents a particular type
of object in the real world. Because an entity represents a particular type of object, entities are “distinguishable”—that is,
each entity occurrence is unique and distinct. For example, a CUSTOMER entity would have many distinguishable
customer occurrences, such as John Smith, Pedro Dinamita, Tom Strickland, etc. Entities may be physical objects, such as
customers or products, but entities may also be abstractions, such as flight routes or musical concerts.
An attribute is a characteristic of an entity. For example, a CUSTOMER entity would be described by attributes such as
customer last name, customer first name, customer phone, customer address, and customer credit limit. Attributes are the
equivalent of fields in file systems.
A relationship describes an association among entities. For example, a relationship exists between customers and agents
that can be described as follows: an agent can serve many customers, and each customer may be served by one agent.
Data models use three types of relationships: one-to-many, many-to-many, and one-to-one. Database designers usually
use the shorthand notations 1:M or 1..*, M:N or *..*, and 1:1 or 1..1, respectively. (Although the M:N notation is a
standard label for the many-to-many relationship, the label M:M may also be used.)
One-to-many (1:M or 1..*) relationship. A painter paints many different paintings, but each one of them is
painted by only one painter. Thus, the painter (the “one”) is related to the paintings (the “many”). Therefore,
database designers label the relationship “PAINTER paints PAINTING” as 1:M. (Note that entity names are often
capitalized as a convention, so they are easily identified.) Similarly, a customer (the “one”) may generate many
invoices, but each invoice (the “many”) is generated by only a single customer. The “CUSTOMER generates
INVOICE” relationship would also be labeled 1:M.
Many-to-many (M:N or *..*) relationship. An employee may learn many job skills, and each job skill may be
learned by many employees. Database designers label the relationship “EMPLOYEE learns SKILL” as M:N.
Similarly, a student can take many classes and each class can be taken by many students, thus yielding the M:N
relationship label for the relationship expressed by “STUDENT takes CLASS.”
One-to-one (1:1 or 1..1) relationship. A retail company’s management structure may require that each of its
stores be managed by a single employee. In turn, each store manager, who is an employee, manages only a single
store. Therefore, the relationship “EMPLOYEE manages STORE” is labeled 1:1.
The preceding discussion identified each relationship in both directions; that is, relationships are bidirectional:
One CUSTOMER can generate many INVOICEs.
Each of the many INVOICEs is generated by only one CUSTOMER.
A constraint is a restriction placed on the data. Constraints are important because they help to ensure data integrity.
Constraints are normally expressed in the form of rules. For example:
An employee’s salary must have values that are between 6,000 and 350,000.
A student’s GPA must be between 0.00 and 4.00.
Each class must have one and only one teacher.
How do you properly identify entities, attributes, relationships, and constraints? The first step is to clearly identify the
business rules for the problem domain you are modeling.
BUSINESS RULES
From a database point of view, the collection of data becomes meaningful only when it reflects properly defined business
rules. A business rule is a brief, precise, and unambiguous description of a policy, procedure, or principle within a
specific organization. In a sense, business rules are misnamed: they apply to any organization, large or small—a business,
a government unit, a religious group, or a research laboratory—that stores and uses data to generate information.
Business rules, derived from a detailed description of an organization’s operations, help to create and enforce actions
within that organization’s environment. Business rules must be rendered in writing and updated to reflect any change in
the organization’s operational environment.
Properly written business rules are used to define entities, attributes, relationships, and constraints. Any time you see
relationship statements such as “an agent can serve many customers, and each customer can be served by only one agent,”
you are seeing business rules at work.
