Chapter 2 Modeling Data in the Organization

Name: Chapter 2 Modeling Data in the Organization
Uploaded: 2017-07-28T12:26:20+00:00
Duration: PTM37S7
Channel: Loren Jefferson
Description: Chapter 2 Modeling Data in the Organization

Chapter 2 Modeling Data in the Organization
Jason C. H. Chen, Ph.D. Professor of MIS School of Business Administration Gonzaga University Spokane, WA 99258

Objectives Definition of terms Importance of data modeling
Write good names and definitions for entities, relationships, and attributes Distinguish unary, binary, and ternary relationships Model different types of attributes, entities, relationships, and cardinalities Draw E-R diagrams for common business situations Convert many-to-many relationships to associative entities Model time-dependent data using time stamps

EMPLOYEE composite derived/ computed multi-valued
e_id e_name e_address dob date_employed skill … years_employed age 1234 John smith 502 Boone Spokane, WA 99258 programming, painting, drawing, 5678 Mary Jones 567 SE Main st, Seattle, WA 98059 2-9-87 Gardening EMPLOYEE e_id e_name e_address (street, city, state, zip) dob date_employed {skill} [years_employed] [age] Should we create “composite” attributes? (see next slide)? Should we create “derived/computed” attributes and save physically/ permanently in the database and why? How to insert values into “multi-valued” attributes? (later this semester)

Can you find out “total number of customers” from state of Washington?
c_id c_name c_address c_phone 1234 John smith 502 Boone Spokane, WA 99258 5678 Mary Jones 567 SE Main St, Seattle, WA 98059 3456 Jerry Walker 450 3rd Ave, San Jose, CA 95130 What is (are) the draw back of creating a CUSTOMER TABLE with “Composite” attribute of c_address? Can you find out “total number of customers” from state of Washington? Can you find out all customers (with their detailed information) from city of Spokane? and more …

Abstraction Concealing irrelevant details from the user.
Abstraction is the process of temporarily ignoring underlying details so we can focus on the big picture of the large problem at hand

E/R Modeling The E/R model is used to construct a conceptual data model -- a representation of the structure and constraints of a database and is the technology independent.

Why Data Modeling is Important?
The characteristics of the data are crucial in the design of the database, programs, and other system components. Data are the most complex aspects of many modern MIS - not the processes. Data tend to be more stable than the business processes that use that data.

Project Identification
SDLC Revisited – Data Modeling is an Analysis Activity (see also Figure 1-7) Project Identification and Selection Purpose –thorough analysis Deliverable – functional system specifications Project Initiation and Planning Analysis Logical Design Physical Design Database activity – conceptual data modeling Implementation Maintenance

Business Rules Statements that define or constrain some aspect of the business Assert business structure Control/influence business behavior Are expressed in terms familiar to end users Are automated through DBMS software

A Good Business Rule is: (Table 2-1)
Declarative – what, not how Precise – clear, agreed-upon meaning Atomic – one statement Consistent – internally and externally Expressible – structured, natural language Distinct – non-redundant Business-oriented – understood by business people

A Good Data Name is: Related to business, not technical, characteristics Meaningful and self-documenting Unique Readable Composed of words from an approved list Repeatable Written in standard syntax

Data Definitions Explanation of a term or fact
Term–word or phrase with specific meaning Fact–association between two or more terms Guidelines for good data definition Gathered in conjunction with systems requirements Accompanied by diagrams Concise description of essential data meaning Achieved by consensus, and iteratively refined 12

E-R Model Constructs Entities: entity type is always SINGULAR
Entity instance: person, place, object, event, concept (often corresponds to a row in a table) Entity Type: collection of entities (often corresponds to a table). entity type is always SINGULAR Relationships: Relationship instance–link between entities (corresponds to primary key-foreign key equivalencies in related tables) Relationship type–category of relationship…link between entity types Attribute property or characteristic of an entity or relationship type (often corresponds to a field in a table) 2

Sample E-R Diagram (Figure 2-1)
3

Basic E-R notation (Figure 2-2)
Entity symbols Attribute symbols A special entity that is also a relationship Relationship symbols Relationship degrees specify number of entity types involved Relationship cardinalities specify how many of each entity type is allowed 8

What Should an Entity Be?
SHOULD BE: An object that will have many instances in the database An object that will be composed of multiple attributes An object that we are trying to model SHOULD NOT BE: A user of the database system An output of the database system (e.g. a report)

Inappropriate entities
Figure 2-4 Example of inappropriate entities System user System output Inappropriate entities Appropriate entities

Attributes Attribute - property or characteristic of an entity type that is of interest to the organization. Classifications of attributes: Required versus Optional Attributes Simple versus Composite Attribute Single-Valued versus Multi-valued Attribute Stored versus Derived Attributes Identifier Attributes 5

Identifiers (Keys) Identifier (Key) - An attribute (or combination of attributes) that uniquely identifies individual instances of an entity type Simple Key versus Composite Key Candidate Key – an attribute that could be a key…satisfies the requirements for being a key 6

Strong vs. Weak Entities, and Identifying Relationships
Strong entities exist independently of other types of entities has its own unique identifier identifier underlined with single-line Weak entity dependent on a strong entity (identifying owner)…cannot exist on its own does not have a unique identifier (only a partial identifier) Partial identifier underlined with double-line Entity box has double line Identifying relationship links strong entities to weak entities

Figure 2-5 Example of a weak identity and its identifying relationship
Strong entity Weak entity

Q: (Review Q:#12; p.101) Another example of Weak Entity
Phone Call (see below) is an example of a weak entity because a phone call must be placed by a PERSON. In this simple example, PHONE CALL is related to only one other entity type, thus, it is not necessary to show the identifying relationship; however, if this data model were ever expanded so that PHONE CALL related to other entity types, it is good practice to always indicate the identifying relationship. Strong entity Weak entity

Required vs. Optional Attributes
Required: Either KEY or Non-key with nn (Not Null value constraint) Optional: Non-Key attribute Required – must have a value for every entity (or relationship) instance with which it is associated Optional – may not have a value for every entity (or relationship) instance with which it is associated 5

E-R Model Constructs (Continued)
Attribute - property or characteristic of an entity type that is of interest to the organization. Simple versus Composite Attribute Fig. 2-7 Single-Valued versus Multivalued Attribute Fig. 2-8 Stored versus Derived Attributes

An attribute broken into component parts
Figure 2-7 A composite attribute: An attribute that has meaningful component parts (attributes) An attribute broken into component parts Figure 2-8 Entity with multivalued attribute (Skill) and derived attribute (Years Employed) Multivalued an employee can have more than one skill Derived from date employed and current date 12

CUSTOMER (after “breaking” the ‘composite’ address)
c_id c_name street city state zip c_phone 1234 John Smith 502 Boone Spokane WA 99258 5678 Mary Jones 567 SE Main St Seattle 98059 3456 Jerry Walker 450 3rd Ave San Jose CA 95130 Now we are able to find out “total number of customers” from state of Washington? HOW? We can find out all customers (with their detailed information) from city of Spokane? and more …

Identifier or Key - An attribute (or combination of attributes) that uniquely identifies individual instances of an entity type. Simple Key versus Composite Key (Fig. 2-9) Candidate Key

Figure 2-9 Simple and composite identifier attributes
The identifier is boldfaced and underlined 14

Criteria for Selecting Identifiers Will not change in value over the life of each instance of the entity type. Will not be NULL. No intelligent identifiers (containing e.g. locations or people that might change) Substitute new, simple (e.g., surrogate attribute) keys for long, composite keys (e.g., entity type of Game: Game# instead of Home_Team and Visitor_Team)

More on Relationships Relationship Types vs. Relationship Instances
The relationship type is modeled as lines between entity types…the instance is between specific entity instances Relationships can have attributes These describe features pertaining to the association between the entities in the relationship Two entities can have more than one type of relationship between them (multiple relationships) Associative Entity–combination of relationship and entity

Modeling Relationships
Relationship Type versus Instance Fig. 2-10 An associative entity An entity type that associates the instances that are peculiar to the relationship between those entity instances. Attributes on Relationships Fig. 2-11

Figure 2-10 Relationship types and instances
a) Relationship type (Completes) b) Relationship instances 17

Associative Entities An entity - has attributes
A relationship - links entities together When should a relationship with attributes instead be an associative entity? All relationships for the associative entity should be many The associative entity could have meaning independent of the other entities The associative entity preferably has a unique identifier, and should also have other attributes The associative entity may participate in other relationships other than the entities of the associated relationship Ternary relationships should be converted to associative entities

Figure 2-11(a) A binary relationship with an attribute
Attribute on a relationship (Link Attribute/Associative) Here, the date completed attribute pertains specifically to the employee’s completion of a course…it is an attribute of the relationship 20

Figure 2-11(b) An associative entity (CERTIFICATE)
Associative entity is like a relationship with an attribute, but it is also considered to be an entity in its own right Note that the many-to-many cardinality between entities in Figure 2-11a has been replaced by two one-to-many relationships with the associative entity 21

Fig. 2-11: (b) An associative entity (CERTIFICATE)
Employee_ID Course_ID What is an alternative to assign the pk?

Figure 2-11(c )An associative entity using Microsoft VISIO

JustLee E-R Model (Fig. 1-5; p.11 Oracle Text)
PUBLISHER PubID CUSTOMERS Customer# ORDERS Order# BOOKS ISBN AUTHOR AuthorID

PUBLISHER PubID CUSTOMERS Customer# ORDERS Order# BOOKS ISBN AUTHOR AuthorID ORDERITEMS Order# Item# BOOKAUTHOR ISBN AuthorID

PUBLISHER PubID PROMOTION Gift CUSTOMERS Customer# ORDERS Order# BOOKS ISBN AUTHOR AuthorID ORDERITEMS Order# Item# BOOKAUTHOR ISBN AuthorID

PUBLISHER PubID PROMOTION Gift CUSTOMERS Customer# ORDERS Order# BOOKS ISBN AUTHOR AuthorID ORDERITEMS Order# ISBN BOOKAUTHOR ISBN AuthorID

E-R Model vs. O-O Model Value
A collection of entities that share common properties or characteristics Entity Type /Entity (attributes) Class Attributes + operations Entity Instance Object A single occurrence of an entity type/class Value

Break ! (Ch. 2 - Part I) In class exercise - #7 (p. 103);
- #11 (a-c) [Part II] - cardinality HW - 1). #10; p. 103 [Draw ER-D (use Word/Visio) ] -2) ER for Northwoods University database (bring a hardcopy to me next class)

Relationships Degree of a Relationship - number of entity types that participate in it (Fig. 2-12) Unary (or Recursive) Relationship (degree 1) Bill-of-Materials (Fig. 2.12; 2-13) Binary Relationship (degree 2) Ternary Relationship (degree 3)

Cardinality of Relationships
One – to – One Each entity in the relationship will have exactly one related entity One – to – Many An entity on one side of the relationship can have many related entities, but an entity on the other side will have a maximum of one related entity Many – to – Many Entities on both sides of the relationship can have many related entities on the other side

Degree of relationships – from Figure 2-2
Entities of two different types related to each other One entity related to another of the same entity type Entities of three different types related to each other 8

Fig. 2-12: Example of relationships of different degrees
(a) Unary relationships 22

Fig. 2-12: (b) Binary relationships
23

Note: a relationship can have attributes of its own
Figure 2-12 Examples of relationships of different degrees (cont.) c) Ternary relationship Note: a relationship can have attributes of its own 22

Fig. 2-18: Cardinality constraints in a ternary relationship
p_id v_id v_id p_id w_id w_id

Fig. 2-13: Representing a bill-of -materials structure
(a) Many-to-many relationship 25

Fig. 2-13: (b) Two instances
26

Fig. 2-13 (c ) : An associative entity - bill of materials structure
This could just be a relationship with attributes…it’s a judgment call 27

Fig. 2-14: Ternary relationships as an associative entity
28

Basic E-R notation (Figure 2-2)
Entity symbols Attribute symbols A special entity that is also a relationship Relationship symbols Relationship degrees specify number of entity types involved Relationship cardinalities specify how many of each entity type is allowed 8

Figure 2-15a and 2-15b Multivalued attributes can be represented as relationships/Associative Entity
simple composite

Fig. 2-15: Using relationships and entities to link related attributes
(c) Composite attribute of data shared with other entity types

Cardinality Constraints
Cardinality Constraints - the number of instances of one entity that can or must be associated with each instance of another entity. Minimum Cardinality If zero, then optional If zero or more, then optional many If one or more, then mandatory many Mandatory One - when min & max both = 1 Maximum Cardinality The maximum number 29

Fig. 2-16: Introducing cardinality constraint
(a) Basic relationship (a) Relationship with cardinality constraints

Figure 2-17 Examples of cardinality constraints
a) Mandatory cardinalities A patient history is recorded for one and only one patient A patient must have recorded at least one history, and can have many 1

(4) Figure 2-17 Examples of cardinality constraints (cont.)
b) One optional, one mandatory (4) A project must be assigned to at least one employee, and may be assigned to many An employee can be assigned to any number of projects, or may not be assigned to any at all 1

Figure 2-17 Examples of cardinality constraints (cont.)
c) Optional cardinalities A person is married to at most one other person, or may not be married at all 1

Fig. 2-18: Cardinality constraints in a ternary relationship
Each part can be supplied by any number of vendors to more than one WH, but each part must supplied by at least one vendor to a WH. Each vendor can supply many parts to any number of wareshouses, but need not supply any parts. Each WH can be supplied with any number of parts from more than one vendor, but each WH must be supplied with at least one part

Relationships Modeling Time-Dependent Data
Time Stamps: a time value that is associated with a data value (Fig. 2-19; 2-20) managing time-dependent data is inadequate using current data models --> data warehousing Multiple Relationship: Business Rules more than one relationship between the same entity types (Fig. 2-21)

Figure 2-19 Simple example of time-stamping
This attribute is both multivalued and composite 37

Fig. 2-20: (a) E-R diagram not recognizing product reassignment
Fig. 2-20: (b) E-R diagram recognizing product reassignment

Fig. 2-20: Pine Valley Furniture product database
(c) E-R diagram with associative entity for product assignment to product line over time Advantage: we now will not miss recording any product line assignment, and we can record information about the assignment (such as the from and to effective dates of the assignment) Disadvantage: the data model NO LONGER has the restriction that a product may be assigned to only one product line at a time (see ENHANCED notation next chapter)

Fig. 2-20: (a) E-R diagram not recognizing product reassignment
In the middle of year, due to a reorganization of the sales function some products are reassigned to different product lines How to reflect product line changed over time? PRODUCT LINE Sales Product Product-Line $50, P B $40, P A (out of $50,000) Assigned Originally, have total year-to-date sales of $5000 and associated with product line B BUT, $4000 of sales may have occurred while the product was assigned to product line A SOLUTION: Adding a new relationship Sales_for_product_line Advantage: we now will not miss recording any product line assignment, and we can record information about the assignment (such as the from and to effective dates of the assignment) Disadvantage: that data model NO LONGER has the restriction that a product may be assigned to only one product line at a time (see ENHANCED notation next chapter) Placed PRODUCT ORDER

Solution: adding a new relationship of “Sales_for_product_line” (b) E-R diagram recognizing product reassignment Sales Product Product-Line $50, P B $40, P A (out of $50,000) $10, P B Originally, have total year-to-date sales of $5000 and associated with product line B BUT, $4000 of sales may have occurred while the product was assigned to product line A SOLUTION: Adding a new relationship Sales_for_product_line Advantage: we now will not miss recording any product line assignment, and we can record information about the assignment (such as the from and to effective dates of the assignment) Disadvantage: that data model NO LONGER has the restriction that a product may be assigned to only one product line at a time (see ENHANCED notation next chapter)

(c) E-R diagram with associative entity for product assignment to product line over time Advantage: we now will not miss recording any product line assignment, and we can record information about the assignment (such as the from and to effective dates of the assignment) Disadvantage: the data model NO LONGER has the restriction that a product may be assigned to only one product line at a time (see ENHANCED notation next chapter)

Fig. 2-21: Examples of multiple relationships
(a) Employees and departments Entities can be related to one another in more than one way 40

?? Fig. 2-21: (b) Professors and courses (fixed upon constraint)
A New Business Rule: An instructor who is scheduled to teach a course must be qualified to teach that course?? (next chapter) ?? So that a course is never the ‘property’ of ONE instructor. Here, minimum cardinality constraint is 2, what’s for? At least two professors must be qualified to teach each course. Each professor must be qualified to teach at least one course.

Database Processing: SQL
Showing Product Information List all details for the various computer desks that are stocked by the company? SELECT * FROM PRODUCT WHERE product_Description LIKE “Computer Desks%”; Showing Customer Order Status How many orders have we received from “Value Furniture? SELECT COUNT (Order_ID) FROM ORDER WHERE Customer_ID = (SEELCT Customer_ID FROM CUSTOMER WHERE Customer_Name = “Value Furniture”);

Fig. 2-22: E-R diagram for Pine Valley Furniture Company
(A Conceptual Data Model) TOP - DOWN Approach vs. BOTTOM - UP Approach

Fig. 2-22: Microsoft Visio Notation for Pine Valley Furniture
E-R diagram Different modeling software tools may have different notation for the same constructs

Fig. 2-22: E-R diagram for Pine Valley Furniture Company
42

Fig. 2-23: Two user views for Pine Valley Furniture
(a) User View 1: Orders for customers (b) User View 2: Orders for products

Figure 1-12 Three-schema architecture
Different people have different views of the database…these are the external schema The internal schema is the underlying design and implementation` 80 80

External View E/R, OO … Relations Database Internal View
Figure 1-12: Three-schema database architecture External View Ch. 4 E/R, OO … Relations Database Ch. 2,3,4 Meta-data/ Repository/ D.D. Ch. 5 Internal View

The Entity Relationship (E-R) Model
Congratulation !! You have just learned one of the most important modeling concept (E-R) for developing the data base systems.

Phase I - Logical Design Phase
MVC_Hospital HW Phase I - Logical Design Phase Draw a entity-relationship diagram (enterprise model) for Mountain View community Hospital, based on the narrative description of the case and this handout (but the entities are from the five (5) figures/reports shown in the assignment sheet). You should create a file and turn in with a hardcopy (file name: MVC_Phase I_ERD_Lname_Fname.docx) contains the following materials: 1. Read and employ materials from chapters 1 and 2 2. Include entities, associations (with detail multiplicity), and attributes. 3. Determine and draw the order of entering data Upload ONLY the .docx file to the Blackboard (under “Assignments”) with the following file name: bmis441_MVC-Phase I_Lastname_Firstname.docx

Problems and Exercises
In class exercise - #11 (a-c), p.103 [ Cardinality] - #13 [Review Questions, p.103] HW (using Visio) 1. #20 ( p.106) turn in with hardcopy 2. MVC mini project- Phase I (ERD both hard and soft copies)

Chapter 2 Modeling Data in the Organization

Similar presentations

Presentation on theme: "Chapter 2 Modeling Data in the Organization"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Chapter 2 Modeling Data in the Organization

Similar presentations

Presentation on theme: "Chapter 2 Modeling Data in the Organization"— Presentation transcript:

Similar presentations

About project

Feedback