An entity-relationship data model helps developers define things (entities) that will be stored in the database as they are building a data model. It also defines relationships among those entities.
Entities are things users want to track. It can be a physical object (inventory items) or a logical transaction (sales order). The names are always singular.
Each entity has attributes that describe its characteristics. The entity “Order” has attributes like “OrderNumber” and “OrderDate”.
An identifier is an attribute whose value is associated with one and only one entity instance. “OrderNumber” is the identifier for the “Order” entity because there should only be one number for each order.
Student, Department, Advisor, Email, and Office_Visit are the entity names in this model.
The entity identifiers are StudentNumber, DeptName, and AdvisorName. Not all entities require an identifier.
Relationships join one entity to another entity
One-to-one – 1:1
One-to-many – 1:N
Many-to-many – N:M
This diagram shows that each Department Entity can have multiple Adviser Entities in a one-to-many relationship. Adviser Entities can have a many-to-many relationship with Student Entities.
The line style between entities describes the type of relationship as shown in the entity-relationship diagram below.
This diagram depicts crow’s feet between the entities to describe the relationships. It shows a one-to-many (1:M) relationship between Department and Adviser and a many-to-many (N:M) relationship between Adviser and Student entities.
Converting a poorly structured table into two or more well-structured tables is called normalization.
The table below is poorly designed because it includes the DeptName as part of the Employee record, making it difficult to update.
It also creates data integrity
the DeptName is not
the table after the
data were updated.
Normalizing the tables by splitting the Department data into a separate table, as shown below, allows each table to describe a single topic or theme. The tables have been transformed into a normal form.
By eliminating the duplicate data, you eliminate data integrity problems. That’s called
normalizing for data integrity.
Now, the department
name only needs to
be updated in one place
in the normalized tables.
This chart shows the necessary steps to transform a data model into a relational database design.
The figures below and on the next slide depict the steps used to create a well structured database that will produce useful information.
The figure on the left represents the relationship between tables. The figure on the right shows a normalized table for each entity.
The figure below shows how relationships are represented using foreign keys. It’s the last step in transforming a data model into a database design.
Your role in the database development process is to decide what data should be included and how records should relate to one another.
The best time to change a database structure is during the data modeling stage. It’s easier and cheaper to change your mind before anything is actually built. The costs of correcting the database in time and money later on may be very high.
Each entity must contain all the data you need to do your job.
Each relationship must accurately reflect the appropriate view of your business.
You must be the final judge of how well the database will serve your needs. Do not go forward until the data model is accurate.
Databases are an important resource for most businesses.
As databases touch more aspects of systems and business functions, the utility of a database increases as do potential problems.
Database administration manages the development, operation, and maintenance of databases.
Database administration must protect the database and maximize its availability for authorized use.