1. MIS3150 Data and Information Management Lecture 2 - Data and Process Modeling
Arijit Sengupta 1

2. Structure of this semester
MIS3150
Java DB
Applications –
JDBC
4. Applications
1. Design
2. Querying
Transaction
Management
Data
Mining
3. Advanced
Topics
0. Intro
Database
Fundamentals
Conceptual
Modeling
Query
Languages
Relational
Model
Advanced
SQL
Normalization
Newbie
Users
Designers
Developers
Professionals

3. Today’s Buzzwords Data Modeling Process Modeling Data Flow Diagrams
Entity-Relationship Models
Cardinality and Participation Constraints
Weak Entities
Generalization Hierarchies

4. So, where are we? Analysis Design Implementation Testing Installation
Proposal
Requirements
Analysis
Normalization
Modeling
Schema design
Design
Tables
Indexes
Queries
Optimization
Implementation
Testing
Installation

5. Objectives of this lecture
Describe the process inherent in a system
Present a system process in a concise diagrammatic form
Describe the system data in terms of conceptual objects and relationships between them
Translate such conceptual descriptions into actual tables

6. Benefits of Conceptual Design
Projects without a strong conceptual design are more likely to fail
Design is one of the most important aspects of project and business process quality management standards:
ISO 9000
CMM
Designs are typically network structured, not flat like databases
Literature in Relational Model shows Benefits of Conceptual Design in user performance

7. Database Modeling Process Models Data Models
Overview of process components
Inputs and outputs of different processes
Data sources and destinations
Mode of data flow between processes
Data Models
Model only the data, no process
Different components of the data
Relationships between primary data components

8. Models, method, and media
A model
describes business or organization
separates operation from technology
Good modeling requires good methodologies
encompass data, process, decisions
richly expressive and provide for levels of analysis
simple representation
Modeling medium
both formal and visual

9. Data Flow medium Notation: Structure: Source: box
Process (transform): box with rounded corners
File (store): box open on right
Destination: box
Flow: arrow
Structure:
“Explosion” of processes (recursion on structure)

10. Data Flow Diagrams

11. DFD rules
Start with a very basic overview of complete process, showing only the most important processes, sources, destinations, and files
Recursively “explode” each of the processes (note: processes only!):
preserve inputs and outputs
preserve file accesses
new processes, files and sources/destinations can be created, but cannot be used from previous levels if not directly used in the previous level

12. Overview of Data Modeling
Conceptual design: (ER Model is used at this stage.)
What are the entities and relationships in the enterprise?
What information about these entities and relationships should we store in the database?
What are the integrity constraints or business rules that hold?
A database `schema’ in the ER Model can be represented pictorially (ER diagrams).
Can map an ER diagram into a relational schema. 2

13. ER Model Basics
Entity: Real-world object distinguishable from other objects. An entity is described (in DB) using a set of attributes.
Entity Set: A collection of similar entities. E.g., all employees.
All entities in an entity set have the same set of attributes. (Until we consider ISA hierarchies, anyway!)
Each entity set has a key.
Each attribute has a domain.
Employees
ssn
name
dob 3

14. Alternative Entity Representations
Employee
SSN
Name
Dob
SSN
Name
Dob
Employee
Employee
SSN
Name
Dob

15. ER Model Basics (Contd.)
Relationship: Association among two or more entities. E.g., Attishoo works in Pharmacy department.
Relationship Set: Collection of similar relationships.
An n-ary relationship set R relates n entity sets E1 ... En; each relationship in R involves entities e1 E1, ..., en En
Same entity set could participate in different relationship sets, or in different “roles” in same set.
Reports_To
salary
name
Employees
subor-dinate
super-visor
ssn
salary
dname
budget
did
since
name
Works_In
Departments
Employees
ssn 4

16. Model this
An auto repair shop provides services to vehicles brought in by customers. A customer may own multiple vehicles that they bring in for service. Each service request is assigned to a technician. A service consists of different jobs that are assigned fees. A service may need parts as well. The customer is given an invoice with details on all the fees and parts costs.
What should be modeled?
Which items should be modeled as entities?
Which items should be modeled as relationships?
Which items should be modeled as attributes?

17. A thumb rule to modeling
Major nouns become entities
Minor nouns become attributes
Verbs connecting major nouns become relationships

18. Major nouns in our passage?

19. Minor nouns in our passage?

20. Verbs in our passage?

21. ER model for our exercise

22. Business Rules A department must have one and only one manager
A manager may manage multiple departments
An employee works in only one department
A department (of course) has many employees

23. Participation Constraints
Does every department have a manager?
If so, this is a participation constraint: the participation of Departments in Manages is said to be total (vs. partial).
Every did value in Departments table must appear in a row of the Manages table (with a non-null ssn value!)
since
since
name
name
dname
dname
ssn
salary
did
did
budget
budget
0,M
1,1
Manages
Employee
Department
1,1
1,M
Works_In
since 8

24. Structural Constraints
Participation
Do all entity instances participate in at least one relationship instance?
Cardinality
How many relationship instances can an entity instance participate in?
(min,max) (min,max)
Participation Cardinality
0 -- Partial one
1 -- Total (Mandatory) M -- more than one

25. Understanding P/C constraints
0:M
1:1
Employee
manages
Department
1:1
works_in
1:M
John
Accounting
Mary
Susan
Sales
Jack
Peter
Development
Sally

26. Many-Many relationships
Student
Course
takes
0:M
0:M
John
MIS415
Mary
Susan
MIS215
Jack
Peter
MIS345
Sally
MIS490

27. Alternative Approaches
Arity approach
Crow’s foot approach (as in book)
Minmax approach
For this class, use ONLY the Participation-Cardinality approach – this is what will be used in assignments and exams

28. Back to our Auto Service Example
What are the participation/cardinality constraints of the relationships?
Owns -
Assigned to -
Consists of -
Needs part – ?

29. Weak Entities
A weak entity can be identified uniquely only by considering the primary key of another (owner) entity.
Owner entity set and weak entity set must participate in a one-to-many relationship set (one owner, many weak entities).
Weak entity set must have total participation in this identifying relationship set.
name
cost
ssn
salary
pname
age
Employees
Policy
Dependents
0:M
1:1 10

30. Point to ponder
Is there a weak entity in the auto service example?

31. ISA (`is a’) Hierarchies
name
ssn
lot
As in C++, or other PLs, attributes are inherited.
If we declare A ISA B, every A entity is also considered to be a B entity.
Employees
hourly_wages
hours_worked
contractid
Hourly_Emps
Contract_Emps
Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity? (Allowed/disallowed)
Covering constraints: Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? (Yes/no)
Reasons for using ISA:
To add descriptive attributes specific to a subclass.
To identify entitities that participate in a relationship. 12

32. Stop and think Is there an IS-A hierarchy in the auto service example?
What would it do to the design?

33. Conceptual Design Using the ER Model
Design choices:
Should a concept be modeled as an entity or an attribute?
Should a concept be modeled as an entity or a relationship?
Identifying relationships: Binary or ternary? Aggregation?
Constraints in the ER Model:
A lot of data semantics can (and should) be captured.
But some constraints cannot be captured in ER diagrams. 3

34. Entity vs. Attribute
Should address be an attribute of Employees or an entity (connected to Employees by a relationship)?
Depends upon the use we want to make of address information, and the semantics of the data:
If we have several addresses per employee, address must be an entity (since attributes cannot be set-valued).
If the structure (city, street, etc.) is important, e.g., we want to retrieve employees in a given city, address must be modeled as an entity (since attribute values are atomic).

35. Converting model to design
Many-to-many relationships
Each entity becomes a table
The relationship becomes a table
PKs of entities becomes FKs in the relationship
Student( )
Course( )
Takes( )
StudentID
Name
Class
Major
Courseno
Coursename
Credits
takes
0:M
Student
0:M
Course
semester

36. Model to design (contd.)
1-Many relationships
Entities become tables
Copy PK of multi-participant to single participant
Copy attributes of relationship to single participant (why?)
ComputerID
Make
Model
Year
Partno
Type
Make
includes
0:1
Computer
1:M
Part
installdate

37. Model to design (contd.)
1-1 relationships
Entities can be merged, or
copy PK of any entity to the other
Generalization
Copy PK of parent entity to child entity as FK, as well as PK
Weak entities
Copy PK of controlling entity to weak entity as FK as well as part of PK

38. Lets convert our autoservice

39. Summary of Conceptual Design
Conceptual design follows requirements analysis,
Yields a high-level description of data to be stored
ER model popular for conceptual design
Constructs are expressive, close to the way people think about their applications.
Basic constructs: entities, relationships, and attributes (of entities and relationships).
Some additional constructs: weak entities, ISA hierarchies, and aggregation.
Note: There are many variations on ER model. 11

40. Summary of ER (Contd.)
Several kinds of integrity constraints can be expressed in the ER model: key constraints, participation constraints, and overlap/covering constraints for ISA hierarchies. Some foreign key constraints are also implicit in the definition of a relationship set.
Some constraints (notably, functional dependencies) cannot be expressed in the ER model.
Constraints play an important role in determining the best database design for an enterprise. 12

41. Summary of ER (Contd.)
ER design is subjective. There are often many ways to model a given scenario! Analyzing alternatives can be tricky, especially for a large enterprise. Common choices include:
Entity vs. attribute, entity vs. relationship, binary or n-ary relationship, whether or not to use ISA hierarchies
Ensuring good database design: resulting relational schema should be analyzed and refined further. FD information and normalization techniques are especially useful. 13

42. Class Exercise
Design an ER Model for a hospital system, with the following case description. Add other assumptions as needed.
The hospital database stores data about patients, their admission and discharge from hospital’s departments and their treatments. For each patient, we know the name, address, sex, social security number. For each department we know the department’s name, its location, the name of the doctor who heads it, the number of beds available, and the number of beds occupied. A doctor may work in several departments, but may only be the head in one department. Each patient goes through multiple treatments during hospitalization; for each treatment we store its name, duration and the possible reactions to it that the patient may have. A treatment may have one or more follow-up treatments.
Items to ponder:
What other constraints can we apply on this model?