Data Modeling for
Database Design 1
Yong Choi
School of Business
CSUB
Part # 2
2
Study Objectives
 Understand concepts of data modeling and its
purpose
 Learn how relationships between entities are
defined and refined, and how such relationships
are incorporated into the database design process
 Learn how ERD components affect database design
and implementation
 Learn how to interpret the modeling symbols
Part # 2
Data Model
 Model: an abstraction of a real-world object
or event
 Useful in understanding complexities of the real-
world environment
 Data model
 A diagram that displays a set of tables and the
relationships between them
 Next Slide: “Restaurant” Access data model
using Entity Relationship Diagram (ERD)
Part # 2
Access Data Model using ERD
4
Part # 2
What is an Entity Relationship
Diagram (ERD)?
 ERD is a data modeling technique used in
software engineering to produce a conceptual
data model of an information system.
 So, ERDs illustrate the logical structure of
databases.
 ERD development using a CASE tool
 Powerdesigner by SAP
 Data Modeler by Orcale
5
Part # 2
The Importance of Data Model
 Blue print: official documentation
 Blue print of house
 Employee’s w/o DB knowledge can understand
 a data model diagram vs. a list of tables
 Used as an effective Communication Tool
 Improve interaction among the managers, the
designers, and the end users
 Independence from a particular DBMS
 Network DB, Object-oriented DB, etc.
Part # 2
7
 The data modeling revolves around discovering
and analyzing organizational and users data
requirements.
 Requirements based on policies, meetings,
procedures, system specifications, etc.
 Identify what data is important
 Identify what data should be maintained
Data Model (con’t)
Part # 2
8
 The major activity of this phase is identifying
entities, attributes, and their relationships to
construct model using the Entity Relationship
Diagram.
 Entity  table
 Attribute  column
 Relationship  line
 Basics of Data Modeling Video
 Until business rules # 3 (9:20)
ERD
Part # 2
9
How to find entities?
 Entity:
 "...anything (people, places, objects, events, etc.)
about which we store information (e.g. supplier,
machine tool, employee, utility pole, airline seat,
etc.).”
 Tangible: customer, product
 Intangible: order, accounting receivable
 Look for singular nouns (beginner)
 BUT a proper noun is not a good candidate….
Part # 2
10
Entity Instance
Entity instance: a single occurrence of an entity.
 6 instances
Student
ID
Last
Name
First
Name
2144 Arnold Betty
3122 Taylor John
3843 Simmons Lisa
9844 Macy Bill
2837 Leath Heather
2293 Wrench Tim
Entity: student
instance
Part # 2
11
How to find attributes?
 Attribute:
 Attributes are data objects that either identify or
describe entities (property of an entity).
 In other words, it is a descriptor whose values are
associated with individual entities of a specific entity
type
 The process for identifying attributes is similar except now
you want to look for and extract those names that appear
to be descriptive noun phrases.
Part # 2
12
How to find relationships?
 Relationship:
 Relationships are associations between entities.
 Typically, a relationship is indicated by a verb
connecting two or more entities.
 Employees are assigned to projects
 Relationships should be classified in terms of
cardinality.
 One-to-one, one-to-many, etc.
Part # 2
13
How to find cardinalities?
 Cardinality:
 The cardinality is the number of occurrences in one
entity which are associated to the number of
occurrences in another.
 There are three basic cardinalities (degrees of
relationship).
 one-to-one (1:1), one-to-many (1:M), and many-to-
many (M:N)
Part # 2
14
“attributes that uniquely identify entity instances”
 Becomes a PK in RDS
 Composite identifiers are identifiers that consist
of two or more attributes
 Identifiers are represented by underlying the
name of the attribute(s)
 Employee (Employee_ID), student (Student_ID)
Identifier
Part # 2
Crow’s Foot Notation
 Known as IE notation (most popular)
 Entity:
 Represented by a rectangle, with its name on the
top. The name is singular (entity) rather than
plural (entities).
15
Part # 2
Attributes
 Identifiers are represented by underlying the
name of the attribute(s)
16
Part # 2
Basic Cardinality Type
 1-to-1 relationship
 1-to-M relationship
 M-to-N relationship
Part # 2
Cardinality con’t
Part # 2
19
Example Model
Part # 2
Data Model by Peter Chen’ Notation
(first - original)
Part # 2
Business Rule Example 1
 Finalized business rules must be
bi-directional.
 Draft: one sentence
 Finalized: two sentences
 A professor advises many
students (professor to student).
Each student is advised by one
professor (student to professor).
 A professor must teach many
classes. Each class must be
taught by one professor.
21
Part # 2
Business Rule 1
 Business Rules are used to define entities, attributes,
relationships and constraints.
 Usually though they are used for the organization
that stores or uses data to be an explanation of a
policy, procedure, or principle.
 The data can be considered significant only after
business rules are defined.
 W/o them it cannot be considered as data for RDS but just
records.
22
Part # 2
Business Rule 2
 When creating business rules, keep them simple,
easy to understand, and keep them broad.
 so that everyone can have a similar understanding and
interpretation.
 Sources of business rules:
 Direct interviews with internal & external stakeholders
 Site visitations (collect data) and observation of the work
process or procedure
 Review and study of documents (Policies, Procedures,
Forms, Operation manuals, etc..)
23
Part # 2
Discovering Business Rules
 Real world example on the class website
 After reviewing and studying the interview and
various forms, develop a draft business rules -
does not need to be bi-directional and less precise
wording…
 Keep on going until “optimized”
 Then, finalize Business Rules: bi-directional.
Part # 2
Business Rule Example 2
 A sales representative must write
many invoices. Each invoice has to
be written by one sales
representative.
 Each sales representative must be
assigned to many department.
Each department has only one
sales representative.
 A customer has to generate many
invoices. An invoice is generated
by only one customer.
25
Part # 2
26
“Describe detail information about an entity ”
 Entity: Employee
 Attributes:
 Employee-Name
 Address (composite)
 Phone Extension
 Date-Of-Hire
 Job-Skill-Code
 Salary
Attributes
Part # 2
27
Classes of attributes
 Simple attribute
 Composite attribute
 Derived attributes
 Single-valued attribute
 Multi-valued attribute
Part # 2
28
 A simple attribute cannot be subdivided.
 Examples: Age, Gender, and Marital status
 A composite attribute can be further
subdivided to yield additional attributes.
 Examples:
 ADDRESS -- Street, City, State, Zip
 PHONE NUMBER -- Area code, Exchange number
Simple/Composite attribute
Part # 2
29
 is not physically stored within the database
 instead, it is derived by using an algorithm.
 Example 1: Late Charge of 2%
 MS Access: InvoiceAmt * 0.02
 Example 2: AGE can be derived from the date of
birth and the current date.
 MS Access: int(Date() – Emp_Dob)/365)
Derived attribute
Part # 2
30
 can have only a single (atomic) value.
 Examples:
 A person can have only one social security number.
 A manufactured part can have only one serial number.
 A single-valued attribute is not necessarily a
simple attribute.
 Part No: CA-08-02-189935
 Location: CA, Factory#:08, shift#: 02, part#: 189935
Single-valued attribute
Part # 2
31
 can have many values.
 Examples:
 A person may have several college degrees.
 A household may have several phones with
different numbers
 A car color
Multi-valued attributes
Part # 2
32
Example - “Movie Database”
 Entity:
 Movie Star
 Attributes:
 SS#: “123-45-6789” (single-valued)
 Cell Phone: “(661)123-4567, (661)234-5678”
(multi-valued)
 Name: “Harrison Ford” (composite)
 Address: “123 Main Str., LA, CA” (composite)
 Gender: “Female” (simple)
 Age: 24 (derived)
Part # 2
Procedure of ERD
 Relatively simple representations of complex
real-world data structures
 Data modeling is iterative process.
 “complete” and “100% error free” model is
not possible!
 Only “Optimized” model is possible….
33

More Related Content

PPT
Entity Relationships using Unified Modelling.ppt
PPT
Lecture-13-ER Modeling using web architecture
PPT
ER Modeling.ppt
PPT
ERD_01B=DBMS DATA BASE MANAGEMENT SYSTEM.ppt
PPT
Entitiy Relationship Introduction Diagram
PPTX
DB-Lec1.pptxUpdatedpython.pptxUpdatedpython.pptx
PDF
Sq lite module4
PDF
Summary data modelling
Entity Relationships using Unified Modelling.ppt
Lecture-13-ER Modeling using web architecture
ER Modeling.ppt
ERD_01B=DBMS DATA BASE MANAGEMENT SYSTEM.ppt
Entitiy Relationship Introduction Diagram
DB-Lec1.pptxUpdatedpython.pptxUpdatedpython.pptx
Sq lite module4
Summary data modelling

Similar to ERD_01.ppt (20)

PPTX
model data objects concepts of entitty.pptx
PDF
Relational data base and Er diagema Normalization
PDF
DATABASE DESIGNS ER DIAGRAMS REATIONA; ALGEBRA
PPT
SA Chapter 10
PPTX
uml.pptx
PDF
Sq lite module3
DOCX
Coit11237 assignment 2 specifications
PDF
03 CHAPTER TWO - CONCEPTUAL DATABASE DESIGN.pdf
PPTX
03 CHAPTER TWO - CONCEPTUAL DATABASE DESIGN.pptx
PPT
Analysis modeling in software engineering
PPTX
ER modeling
PPT
Chapter 5 Analysis Modeling of Software Engineering.ppt
PPT
Analysis modeling
DOCX
PDF
Conceptual Data Modelling Using ER-models
PPT
DB design
PPT
software_engg-chap-03.ppt
PDF
Informatica Data Modelling : Importance of Conceptual Models
PPT
A2 databases
PDF
RDBMS NOTES 1.pdf BWSBFDGFEDRHHYGTRFEDCWXSDFRGTHYUJ7IK89O8IJUY7HGTR
model data objects concepts of entitty.pptx
Relational data base and Er diagema Normalization
DATABASE DESIGNS ER DIAGRAMS REATIONA; ALGEBRA
SA Chapter 10
uml.pptx
Sq lite module3
Coit11237 assignment 2 specifications
03 CHAPTER TWO - CONCEPTUAL DATABASE DESIGN.pdf
03 CHAPTER TWO - CONCEPTUAL DATABASE DESIGN.pptx
Analysis modeling in software engineering
ER modeling
Chapter 5 Analysis Modeling of Software Engineering.ppt
Analysis modeling
Conceptual Data Modelling Using ER-models
DB design
software_engg-chap-03.ppt
Informatica Data Modelling : Importance of Conceptual Models
A2 databases
RDBMS NOTES 1.pdf BWSBFDGFEDRHHYGTRFEDCWXSDFRGTHYUJ7IK89O8IJUY7HGTR
Ad

Recently uploaded (20)

PPTX
Amdahl’s law is explained in the above power point presentations
PPTX
Fundamentals of Mechanical Engineering.pptx
PDF
Improvement effect of pyrolyzed agro-food biochar on the properties of.pdf
PPTX
Module 8- Technological and Communication Skills.pptx
PDF
Categorization of Factors Affecting Classification Algorithms Selection
PDF
UNIT no 1 INTRODUCTION TO DBMS NOTES.pdf
PPTX
ASME PCC-02 TRAINING -DESKTOP-NLE5HNP.pptx
PDF
22EC502-MICROCONTROLLER AND INTERFACING-8051 MICROCONTROLLER.pdf
PPTX
CyberSecurity Mobile and Wireless Devices
PDF
null (2) bgfbg bfgb bfgb fbfg bfbgf b.pdf
PDF
Artificial Superintelligence (ASI) Alliance Vision Paper.pdf
PPTX
Sorting and Hashing in Data Structures with Algorithms, Techniques, Implement...
PPTX
Graph Data Structures with Types, Traversals, Connectivity, and Real-Life App...
PDF
August 2025 - Top 10 Read Articles in Network Security & Its Applications
PDF
Abrasive, erosive and cavitation wear.pdf
PDF
Accra-Kumasi Expressway - Prefeasibility Report Volume 1 of 7.11.2018.pdf
PPTX
Chemical Technological Processes, Feasibility Study and Chemical Process Indu...
PPTX
AUTOMOTIVE ENGINE MANAGEMENT (MECHATRONICS).pptx
PPTX
Information Storage and Retrieval Techniques Unit III
PDF
Exploratory_Data_Analysis_Fundamentals.pdf
Amdahl’s law is explained in the above power point presentations
Fundamentals of Mechanical Engineering.pptx
Improvement effect of pyrolyzed agro-food biochar on the properties of.pdf
Module 8- Technological and Communication Skills.pptx
Categorization of Factors Affecting Classification Algorithms Selection
UNIT no 1 INTRODUCTION TO DBMS NOTES.pdf
ASME PCC-02 TRAINING -DESKTOP-NLE5HNP.pptx
22EC502-MICROCONTROLLER AND INTERFACING-8051 MICROCONTROLLER.pdf
CyberSecurity Mobile and Wireless Devices
null (2) bgfbg bfgb bfgb fbfg bfbgf b.pdf
Artificial Superintelligence (ASI) Alliance Vision Paper.pdf
Sorting and Hashing in Data Structures with Algorithms, Techniques, Implement...
Graph Data Structures with Types, Traversals, Connectivity, and Real-Life App...
August 2025 - Top 10 Read Articles in Network Security & Its Applications
Abrasive, erosive and cavitation wear.pdf
Accra-Kumasi Expressway - Prefeasibility Report Volume 1 of 7.11.2018.pdf
Chemical Technological Processes, Feasibility Study and Chemical Process Indu...
AUTOMOTIVE ENGINE MANAGEMENT (MECHATRONICS).pptx
Information Storage and Retrieval Techniques Unit III
Exploratory_Data_Analysis_Fundamentals.pdf
Ad

ERD_01.ppt

  • 1. Data Modeling for Database Design 1 Yong Choi School of Business CSUB
  • 2. Part # 2 2 Study Objectives  Understand concepts of data modeling and its purpose  Learn how relationships between entities are defined and refined, and how such relationships are incorporated into the database design process  Learn how ERD components affect database design and implementation  Learn how to interpret the modeling symbols
  • 3. Part # 2 Data Model  Model: an abstraction of a real-world object or event  Useful in understanding complexities of the real- world environment  Data model  A diagram that displays a set of tables and the relationships between them  Next Slide: “Restaurant” Access data model using Entity Relationship Diagram (ERD)
  • 4. Part # 2 Access Data Model using ERD 4
  • 5. Part # 2 What is an Entity Relationship Diagram (ERD)?  ERD is a data modeling technique used in software engineering to produce a conceptual data model of an information system.  So, ERDs illustrate the logical structure of databases.  ERD development using a CASE tool  Powerdesigner by SAP  Data Modeler by Orcale 5
  • 6. Part # 2 The Importance of Data Model  Blue print: official documentation  Blue print of house  Employee’s w/o DB knowledge can understand  a data model diagram vs. a list of tables  Used as an effective Communication Tool  Improve interaction among the managers, the designers, and the end users  Independence from a particular DBMS  Network DB, Object-oriented DB, etc.
  • 7. Part # 2 7  The data modeling revolves around discovering and analyzing organizational and users data requirements.  Requirements based on policies, meetings, procedures, system specifications, etc.  Identify what data is important  Identify what data should be maintained Data Model (con’t)
  • 8. Part # 2 8  The major activity of this phase is identifying entities, attributes, and their relationships to construct model using the Entity Relationship Diagram.  Entity  table  Attribute  column  Relationship  line  Basics of Data Modeling Video  Until business rules # 3 (9:20) ERD
  • 9. Part # 2 9 How to find entities?  Entity:  "...anything (people, places, objects, events, etc.) about which we store information (e.g. supplier, machine tool, employee, utility pole, airline seat, etc.).”  Tangible: customer, product  Intangible: order, accounting receivable  Look for singular nouns (beginner)  BUT a proper noun is not a good candidate….
  • 10. Part # 2 10 Entity Instance Entity instance: a single occurrence of an entity.  6 instances Student ID Last Name First Name 2144 Arnold Betty 3122 Taylor John 3843 Simmons Lisa 9844 Macy Bill 2837 Leath Heather 2293 Wrench Tim Entity: student instance
  • 11. Part # 2 11 How to find attributes?  Attribute:  Attributes are data objects that either identify or describe entities (property of an entity).  In other words, it is a descriptor whose values are associated with individual entities of a specific entity type  The process for identifying attributes is similar except now you want to look for and extract those names that appear to be descriptive noun phrases.
  • 12. Part # 2 12 How to find relationships?  Relationship:  Relationships are associations between entities.  Typically, a relationship is indicated by a verb connecting two or more entities.  Employees are assigned to projects  Relationships should be classified in terms of cardinality.  One-to-one, one-to-many, etc.
  • 13. Part # 2 13 How to find cardinalities?  Cardinality:  The cardinality is the number of occurrences in one entity which are associated to the number of occurrences in another.  There are three basic cardinalities (degrees of relationship).  one-to-one (1:1), one-to-many (1:M), and many-to- many (M:N)
  • 14. Part # 2 14 “attributes that uniquely identify entity instances”  Becomes a PK in RDS  Composite identifiers are identifiers that consist of two or more attributes  Identifiers are represented by underlying the name of the attribute(s)  Employee (Employee_ID), student (Student_ID) Identifier
  • 15. Part # 2 Crow’s Foot Notation  Known as IE notation (most popular)  Entity:  Represented by a rectangle, with its name on the top. The name is singular (entity) rather than plural (entities). 15
  • 16. Part # 2 Attributes  Identifiers are represented by underlying the name of the attribute(s) 16
  • 17. Part # 2 Basic Cardinality Type  1-to-1 relationship  1-to-M relationship  M-to-N relationship
  • 20. Part # 2 Data Model by Peter Chen’ Notation (first - original)
  • 21. Part # 2 Business Rule Example 1  Finalized business rules must be bi-directional.  Draft: one sentence  Finalized: two sentences  A professor advises many students (professor to student). Each student is advised by one professor (student to professor).  A professor must teach many classes. Each class must be taught by one professor. 21
  • 22. Part # 2 Business Rule 1  Business Rules are used to define entities, attributes, relationships and constraints.  Usually though they are used for the organization that stores or uses data to be an explanation of a policy, procedure, or principle.  The data can be considered significant only after business rules are defined.  W/o them it cannot be considered as data for RDS but just records. 22
  • 23. Part # 2 Business Rule 2  When creating business rules, keep them simple, easy to understand, and keep them broad.  so that everyone can have a similar understanding and interpretation.  Sources of business rules:  Direct interviews with internal & external stakeholders  Site visitations (collect data) and observation of the work process or procedure  Review and study of documents (Policies, Procedures, Forms, Operation manuals, etc..) 23
  • 24. Part # 2 Discovering Business Rules  Real world example on the class website  After reviewing and studying the interview and various forms, develop a draft business rules - does not need to be bi-directional and less precise wording…  Keep on going until “optimized”  Then, finalize Business Rules: bi-directional.
  • 25. Part # 2 Business Rule Example 2  A sales representative must write many invoices. Each invoice has to be written by one sales representative.  Each sales representative must be assigned to many department. Each department has only one sales representative.  A customer has to generate many invoices. An invoice is generated by only one customer. 25
  • 26. Part # 2 26 “Describe detail information about an entity ”  Entity: Employee  Attributes:  Employee-Name  Address (composite)  Phone Extension  Date-Of-Hire  Job-Skill-Code  Salary Attributes
  • 27. Part # 2 27 Classes of attributes  Simple attribute  Composite attribute  Derived attributes  Single-valued attribute  Multi-valued attribute
  • 28. Part # 2 28  A simple attribute cannot be subdivided.  Examples: Age, Gender, and Marital status  A composite attribute can be further subdivided to yield additional attributes.  Examples:  ADDRESS -- Street, City, State, Zip  PHONE NUMBER -- Area code, Exchange number Simple/Composite attribute
  • 29. Part # 2 29  is not physically stored within the database  instead, it is derived by using an algorithm.  Example 1: Late Charge of 2%  MS Access: InvoiceAmt * 0.02  Example 2: AGE can be derived from the date of birth and the current date.  MS Access: int(Date() – Emp_Dob)/365) Derived attribute
  • 30. Part # 2 30  can have only a single (atomic) value.  Examples:  A person can have only one social security number.  A manufactured part can have only one serial number.  A single-valued attribute is not necessarily a simple attribute.  Part No: CA-08-02-189935  Location: CA, Factory#:08, shift#: 02, part#: 189935 Single-valued attribute
  • 31. Part # 2 31  can have many values.  Examples:  A person may have several college degrees.  A household may have several phones with different numbers  A car color Multi-valued attributes
  • 32. Part # 2 32 Example - “Movie Database”  Entity:  Movie Star  Attributes:  SS#: “123-45-6789” (single-valued)  Cell Phone: “(661)123-4567, (661)234-5678” (multi-valued)  Name: “Harrison Ford” (composite)  Address: “123 Main Str., LA, CA” (composite)  Gender: “Female” (simple)  Age: 24 (derived)
  • 33. Part # 2 Procedure of ERD  Relatively simple representations of complex real-world data structures  Data modeling is iterative process.  “complete” and “100% error free” model is not possible!  Only “Optimized” model is possible…. 33