1. Data Modeling (Entity Relationship Diagram)
Farrokh Alemi, Ph.D.

2. Overview of the Course
Abstract business process into database requirements
Model system requirements into a database, and
Use Standard Query Language to gain access to the data. 

3. Entity Divide the list of fields into entities.
Each entity will represent a table
Each field in the table is an attribute of the entity
An entity is something that has an independent, separate, or self-contained existence. 

4. Entities Describe Data Classes
Entity
Name
Type
Def.
Attribute
1..n
Data
Constr.
Logical Data Types
String Data Types
Binary Data Types
Numeric Data Types
Date/Time Data Types

5. Shared Features Suggest Entities
Examine common features of the fields. 
"Patient's first name," "Patient's last name" and "Patient's birthday" suggest an entity called "Patient." 
"Type of diagnosis" and "Name of diagnosis" suggest an entity called "Diagnosis." 
Make sense to others
Entity names should imply what it is about

6. Naming of Entities "Create a name that is unambiguous
Use the minimum number of words
Do not use physical characteristics of the database
Do not use abbreviations
Do not use words that restrict the data
Do not use words that suggest two concepts
Use singular form of the name."

7. Describing an Entity Always include a brief description of the entity.
Set up expectations about fields  
The entity "Patient" may be defined as: "The clients in the court diversion program who have mental illness. Information about the patients need to be kept in order to track if their court ordered treatment is working and has been followed."

8. Rules for Assigning Entities
No two entities should be about the same things. 
For example, calling one entity "Patient" and another "Client" may create both confusion and inefficiency. 

9. Rules for Assigning Entities
Do not assign the same field in two different entities. 
Patient's name belongs to the "Patient“ entity and not to “Diagnosis” entity.
Satisfy the intuitions of future users of the database 

10. Rules for Assigning Entities
Make sure that time based events are separated from time independent fields. 
A patient's diagnoses does not belong to the entity "Patients" but to “Visits.”

11. Rules for assigning entities
If several entities share the same fields, see if you can partition the shared fields into a separate entity. 
Create a new entity called "Person" and keep shared fields in it.  Then if an employee falls ill or is seen in the court, their name does not need to be entered several times once as an employee, next as a patient and last as a court client. 

12. Rules for Assigning Entities
Include look-up entities as you proceed. 
Look up table
Main entity

13. Review & Revise Entities
Review the fields within entities for completeness. 
Many entities suggest new fields that have not been thought about. 
Review again to see if the fields fit new entities
Share the list with organizational members
Documentation
a name, a description, a statement of why it is important to track the entity, and a list of fields that belong to it

14. Entity Relationships Implied in the very definition of the entity.
Three types of relationships:
One to one
One to many
Many to many
How one entity is mapped into another is also referred to as cardinality of the entity
Cardinality
defined

15. Cardinality Follows Business Rules

16. Many to Many Relationships Reveal New Entities

17. Display of Relationships
Shows a
relationship
Shows
cardinality

18. Display of Relationships
Shows a
relationship
Names the relationship

19. Documentation of Relationships
Name of both entities
The verb phrase that describes the semantics of the linkage
The cardinality of the linkage
All relationships
must be documented before
proceeding to the physical
design of the database