Chapter 2: Modeling Data in the Organization

Chapter 2: Modeling Data in the Organization
Modern Database Management 12th Edition Jeff Hoffer, Ramesh Venkataraman, Heikki Topi Slides #80-82: Cardinality verbal description

Slides 2-3 and 2-4 can be good summaries
Objectives Define terms Understand 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 Slides 2-3 and 2-4 can be good summaries

(2018-F) Logical structure of key points
Entity Type Instance Ch 2 Summary E-R Diagram Relationship Biz rule     Biz rule Attribute Cardinality Characteristics of entities Attribute of relationship Both directions Degree About # entity instances “Conceptual Modeling in One Diagram” © Yue Zhang, About # entity types

(2018-F) Checklist of “tricky” concepts & skills
A relationship MUST be stated from BOTH directions [2 business rules for 1 relationship] Entity type and entity instance Types of relationships: degree vs cardinality M-M relationship and associative entity Notations of relationship vs of associative entity Multiple relationships between the SAME entity types Unary relationship [will recur in Ch4 – recursive foreign key, and Ch6 – self join] Watch: what cannot be an entity type!! 0 or 1 or M; Optional/Mandatory: MIN or MAX

E-R MODEL CONSTRUCTS (1)
Entities: Entity instance–object, person, place/org, event, concept (often corresponds to a row in a table) Entity Type–collection of entity instances (often corresponds to a table) 【Definition of entities P. 57】 Entity type: UNIVERSITY; entity instances? is there an attribute Student_Last_Name in the above? is there an attribute Name_of_Department in the above? Entity type: DEPARTMENT; entity instances? The format to follow for your HW/proj Entity type would be implemented as a _____, in which each entity instance would be a ___ 2

Attributes: Properties or characteristics of an entity type or relationship type (Zhang: describing/defining the type) (corresponds to a field/column in a table) (exercises last week) Entity (type): Define an entity type Examples: a (performance) show; a transaction; 2

DISCUSSION Entity Attributes
Type of entities–object, person, place, event, concept Entity Attributes object Ex: Bottled water Place/org Ex: State Ex: City people Ex: Student Ex: Patient event Ex: Stud-org-sponsored campus activities Every entity type is described by its own attributes; NO entity type contains the “lower-level” entity type: UNIV does NOT has “Colleges” as attribute, COMPANY does NOT have “Employees” as attribute Think: City names in State table? Similarly: UNIV, DEPT, FACULTY, STUDENT， COURSE COMPANY, DEPT, EMPLOYEE， PRODUCT

Relationships: Relationship instance–link between entities (entity instances) 【Relationship type】– category of relationship…link between entity types 【Descriptions 】P. 58 (often corresponds to ___ /______ among related tables) Q: Same column; how do we know which is which? Try to state a relationship instance? Such as one that is between entity types STUDENT and COURSE? Format for HW/proj A relationship must be stated in BOTH directions – 1st reminder 2

Summary and comparison of basic terms
In Business In DB Concept In DB Implementation Remark Biz function Object/Person/Event… Entity type Entity instance Characteristics Attribute Relationship PK/FK – which is which? 9

A relationship must be stated in BOTH directions – 2nd reminder
Sample E-R Diagram (Figure 2-1) Entity relationship (ER) diagrams include rectangles representing entities, and lines between the entities representing relationships. Relationships have cardinalities, which can be one-to-one, one-to-many, or many-to-many. In addition, on each side of the relationship you can specify that it is mandatory or optional. A relationship must be stated in BOTH directions – 2nd reminder 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 # of entity types involved (unary, binary, ternary) Relationship cardinalities specify # entity instances in the other end of the relationship each entity instance in this end is allowed to associate 8

Degree & cardinality outline
Degree - # of entity types involved in the relationship: Unary – 1 entity Binary – 2 entities Ternary – 3 entities Cardinality: Number [of entity instances on the other end of the relationship] One-to-one One-to-many Many-to-many “Intensity”: Mandatory optional Number of tables invovled How many possible scenarios? Every scenario will be described or constructed from 3 dimensions – Example: binary, mandatory, one-to-many Unary, optional, one-to-one etc

Scenarios of Degree and cardinality
Cardin-intens Binary Unary Ternary 1-1 Optional Mandatory 1-M M-M Will fill later

E-R Diagram Notation – Chen (1976)
Our book: STUDENT Compare Registered-in COURSE

E-R Diagram: Chen Notation
Boxes represent entities Ovals represent attributes Diamonds represent relationships

Business Rules Biz rules must be reflected in ERD ERD must be based on biz rules Are statements that define or constrain some aspect of the business Are derived from policies, procedures, events, functions Assert business structure Control/influence business behavior Are expressed in terms familiar to end users Are automated through DBMS software Data definition language (DDL) Relationships in an ERD are defined by/derived from business rules Each relationship: 2 rules ERDs and biz rules that are not consistent would be judged as mistaken A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. Not all business rules are implemented in a database, and it is the responsibility of the database analyst to determine which business rules can be expressed through ER models and which cannot. A relationship must be stated in BOTH directions – 3rd reminder

Modeling the Rules of an Org
P. 59: “what data modeling is all about?” – To document rules and policies of an organization that govern data Business rules and policies govern – Creating, {ex: enrollment record} Updating, {ex: units attempted; units earned} Removing {ex: customer credit card number} data in an info storage and processing system Business rules and policies must be described along with the data to which they are related

Statement structure of Business Rules
A relationship must be stated in BOTH directions –4th reminder Are statements that define or constrain some aspect of the business Syntax of business rules: ENTITY_1 Relationiship_Verb_Phrase number ENTITY_2 ENTITY_2 Relationiship_Verb_Phrase number ENTITY_1 where Relationiship_Verb_Phrase = Cardinality_adverb + Relationship_Verb Examples: Two examples P. 60 – think about more examples? ENTITY_1 May/Must verb number ENTITY_2 STUDENT may have many ENROLLMENT CAR must be registered to at least one OWNER CUSTOMER be served by only one EMPLOYEE be assigned At most one PERMIT “EACH”/”A”

A Good Business Rule Is:
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 Excellent examples: P. 58 Business rules appear (possibly implicitly) in descriptions of business functions, events, policies, units, stakeholders, and other objects. These descriptions can be found in interview notes from individual and group information systems requirements collection sessions, organizational documents (e.g., personnel manuals, policies, contracts, marketing brochures, and technical instructions), and other sources. Rules are identified by asking questions about the who, what, when, where, why, and how of the organization. Gathering business rules requires good interviewing and listening skills. As a database analyst, you will ask questions about the who, what, when, where, why, and how of the organization. You’ll need to be persistent in clarifying initial statements of rules because initial statements may be vague or imprecise, so this is an iterative inquiry process. 5th reminder There are two business rules for each relationship – P. 58 From entity 1 to 2 From entity 2 to 1

Why? – definition of cardinality Exaggeration to avoid mistake
“Rules of rules” - Each business rule relate TWO and ONLY TWO entity types; [can’t have 3 types! MOST of the times  ]  Except in the case of ternary relationships Each relationship must be described by two rules, one in each direction; All business rules begin with “Each”/ “A” / “An”. Examples Why? – definition of cardinality Exaggeration to avoid mistake

Business Rules Scenarios - Example
Production operation: (From Fig 1-6) Raw material Product Work center Equipment Employee (Also demo “2 rules per relationship”) (1) EACH PRODUCT consists many MATERIAL; (PRODUCT  MATERIAL) (2) EACH MATERIAL is used in many PRODUCT (MATERIAL  PRODUCT)

Excellent examples: P. 57 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 - different people would develop same name Written in standard syntax Excellent examples: P. 57

Salin’s (1990) suggestion on data name
Preparing a definition of the data Removing insignificant words Arranging the words in a meaningful, repeatable way Assigning a standard abbreviation for each word Use qualifiers if needed

Data Definitions Explanation of a term or fact
Term–word or phrase with specific meaning Fact–association between two or more terms Examples: P.63 Guidelines for good data definition A concise description of essential data meaning Gathered in conjunction with systems requirements Accompanied by diagrams Achieved by consensus, and iteratively refined It is difficult to obtain a universally agreed-upon data definition. So, you may want to use multiple definitions to cover the various situations, or alternatively Use a very general definition that will cover most situations. With data definitions, as with most organizational knowledge, the person who controls the meaning of data controls the data. Thus, the definition of data is a source of organizational power.

Modeling Entities and Attributes
The E-R model is most used as a tool for communications between database designers & end users during the analysis phase of database development

Kinds of entities: P.65 Entities Entity – an object, a person, a place/org, an event, or a concept in the user environment, about which the organization wishes to maintain data Entity type – a collection of entities that share common properties or characteristics TRUCK // STUDENT Entity instance – A single occurrence of an entity type 2014 Chevy Tahoe // John Smith, ACCT

Do not confused with one-to-many
An Entity… =A table has many rows. Ex: FACULTY has Jeff Zhang, David Liu… SHOULD BE: An object that will have many instances in the database An object that will be composed of multiple attributes An object that has relationship w other object(s) 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) We use CAPITAL for names of entity types Do not confused with one-to-many Implementation?

Inappropriate entities
Fig 2-4 Example of inappropriate entities: Entity types should NOT be: System user DB System output Inappropriate entities Should NOT be This figure illustrates a mistake many novices will make. The treasurer is a user of the system, and the expense report is an output of the system. Neither of these are entities that should be represented in the database or the ER model. The ER model should represent the objects that are of interest to the user and that will be displayed in the system output. Appropriate entities

Entity Type and Entity Instances
Value of an attribute

Strong vs. Weak Entities, and Identifying Relationships
Strong entity exists 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) entity box and partial identifier have double lines Identifying relationship links strong entities to weak entities – double line - Uses the identifier of the strong entity as its identifier

Another example would be COURSE and SECTION
Figure 2-5 Example of a weak identity and its identifying relationship This figure shows an ER diagram depicting an identifying relationship between an identifying owner (the employee) and a weak entity (the employer’s dependent). Note that the dependent’s identifier is only a partial identifier. The full identification requires the identifying owner’s identifier as well. Also note the double lines that distinguish the weak entity and the identifying relationship. Strong entity Weak entity Another example would be COURSE and SECTION

Guidelines for Naming and Defining Entities
Definitions: “An X is…” Describe unique characteristics of each instance Explicit about what is and is not the entity When an instance is created or destroyed Changes to other entity types History that should be kept Names: Singular noun Specific to organization Concise, or abbreviation For event entities, the result not the process Name consistent for all diagrams More on P. 68 In addition to general guidelines about naming and defining data objects, there are some specific guidelines for naming entity types. These are listed here. 5

Note notations: Bold, (), { }, UL
Attributes Attribute–property or characteristic of an entity or relationship type Attributes in entity type Attribute values in entity instances Classifications of attributes: Required versus Optional Attributes Simple versus (Composite Attribute) Single-Valued versus {Multivalued Attribute} Stored versus Derived Attributes Identifier Attributes Note notations: Bold, (), { }, UL 5

Required vs. Optional Attributes
This figure illustrates the various properties of an entity’s attributes. Required attributes must have a value, whereas optional attributes could be null. Note that the identifier is ALWAYS required. In this case, the student’s major is optional because a student may not yet have declared a major. All the other attributes, however, are required. 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

Simple vs. (Composite) Attributes
Composite attribute – An attribute that has meaningful component parts (attributes) The address is broken into component parts Sometimes many attributes are related to each other, such as the elements of an address. In this case they can be grouped into a composite attribute. For simplicity, we can refer to the “employee address”, but if we want more detail we can break it into street, city, state, and postal code. So, this way we have the option to describe the attribute at a macro or at a micro level. Note the use of parentheses for encompassing the components of a composite attribute. Figure 2-7 A composite attribute 6

{Multi-valued} and Derived Attributes
Multivalued – may take on more than one value for a given entity (or relationship) instance Derived – values can be calculated from related attribute values (not physically stored in the database) Figure 2-8 Entity with multivalued attribute (Skill) and derived attribute (Years Employed) A multivalued attribute is not the same as a composite attribute, although novices may confuse these terms. A composite attribute is one that has many parts, such as an address composed of street, city, state, and zip. By contrast, a multivalued attribute is one that can have many different values, such as an employee being able to do many things. Note that a derived attribute is not one that is physically stored in the database, but rather one that is calculated based on the value of another. The length of time employed, or a person’s age, are classic examples, as they are calculated based on a fixed starting point (date hired or birthdate). Attributes could be both composite and multivalued, and even also derived. So these are distinct concepts. Multivalued an employee can have more than one skill Derived Calculated from date employed and current date 12

Identifiers (Keys) Identifier (Key)–an attribute (or combination of attributes) that uniquely identifies individual instances of an entity type  Q: Can key value be optional? Simple versus Composite Identifier An order line item is identified with… Candidate Identifier–an attribute that could be an identifier…satisfies the requirements for being an identifier Every entity type should have an identifier attribute. No two instances of the entity type may have the same value for the identifier attribute. For example, a person (employee, student, etc.) cannot rely on the first and last name to be an identifier, because many people could have the same name. Rather, the identifier should be something like an employee ID, a social security number, or some other absolutely unique value. 6

Criteria for Identifiers
Choose Identifiers that Will not change in value Will not be null Have unique value for each row (entity instance) Avoid intelligent identifiers (e.g., containing locations or people that might change) Substitute new, simple keys for long, composite keys – example: Think about why An identifier in he ER model will eventually become a primary key in the resulting database table. We’ll see this in a later chapter. Identifiers are required, so cannot be devoid of value. And it should be constant. Consider an employee ID or a social security number. These do not change. A person’s name or home address, however, could change. Also, identifiers must be unique. Several people could have the same name. 7

Figure 2-9 Simple and composite identifier attributes
The identifier is boldfaced and underlined In the ER diagram, and identifier will be underlined. Note also that required attributes are typically boldfaced, so all identifiers will be boldfaced as well. If an identifier is composite, then all its component parts are required. 14

Naming Attributes Name should be a singular noun or noun phrase
Name should be unique Name should follow a standard format e.g. [Entity type name { [ Qualifier ] } ] Class Similar attributes of different entity types should use the same qualifiers and classes Staff_DOB, Stud_DOB Listing_Price, Sale_Price As with all other data objects, there are guidelines for naming and defining attributes. These are listed in this slide and the next. A common naming format is [Entity type name { [ Qualifier ] } ] Class, where [ ] is an optional clause, and { } indicates that the clause may repeat. Entity type name is the name of the entity with which the attribute is associated. The entity type name may be used to make the attribute name explicit. It is almost always used for the identifier attribute (e.g., Customer ID) of each entity type. Class is a phrase from a list of phrases defined by the organization that are the permissible characteristics or properties of entities (or abbreviations of these characteristics). For example, permissible values (and associated approved abbreviations) for Class might be Name (Nm), Identifier (ID), Date (Dt), or Amount (Amt). Class is required. Qualifier (optional) is a phrase from a list of phrases defined by the organization that are used to place constraints on classes. 7

Defining Attributes State what the attribute is and possibly why it is important Make it clear what is and is not included in the attribute’s value Include aliases in documentation State source of values State whether attribute value can change once set Specify required vs. optional State min and max number of occurrences allowed Indicate relationships with other attributes 7

Intro to relationship – (stated in biz rules)
An association representing an interaction among the instances of one or more entity types – P (1: Unary; 2: Binary; 3: Ternary) A relationship has a verb name A name that describes the nature of the relationship - examples: STDENT takes COURSE, MANAGER supervises EMPLOYEE, ENGINEER is assigned to PROJECT, PART is used in PRODUCT… Think about one that involves an organization? EVERY entity must have a relationship line connected with at least one other entity in the ER diagram – what if not? A relationship must be stated in BOTH directions – 6th reminder 5

Modeling 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 ALSO 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) FACULTY teaches CLASS; FACULTY takes CLASS Associative Entity–combination of relationship and entity (“relationship-turned-entity”)

Figure 2-10 Relationship types and instances
a) Relationship type (Completes) b) Relationship instances This figure illustrates the difference between relationship types and relationship instances. The ER diagram depicts types. It depicts both entity types and relationship types. The actual data that would be in the database constitutes instances, both relationship and entity instances. Next slide 17

Ten instances of the Relationship type in Figure 2-10

Figure 2-11a A relationship with an attribute
Sharp-corner box Compare: Dash line Here, the date completed attribute pertains specifically to the employee’s completion of a course…it is an attribute of the relationship. Please note: the above relationship is a many-to-many. What if it is one-to-many? Can we do the same re “Date-completed”? “Grade”? How? - in each scenario, the two attributes would be that of different entities 20

Associative entity: rounded-corner rectangle
Associative Entities Associative entity: rounded-corner rectangle 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-11b 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 (Note that min cardinalities are missing above for the associative entity) P. 78, second paragraph 21

Rounded-corner rectangle
Comparison of 2-11 a and b Figure 2-11a A relationship with an attribute Sharp-corner box Dash line Figure 2-11b An associative entity (CERTIFICATE) Rounded-corner rectangle 16

Comparison of 2-11 a and b Figure 2-11a A relationship with an attribute One M-M relationship Figure 2-11b An associative entity (CERTIFICATE) Two 1-M relationshipS 16

Online references of E-R diagram
A concise but fairly complete E-R model quick reference: E-R diagram elements (Chen and crow’s foot), with examples 16

Disambiguity/alert of common errors (1)
Compare: “In the eyes of EMPLOYEE, the other end is ___; in the eyes of COURSE, the other end is ___”

Associative entity: When & How (to convert)
Last slide 40

Compare: Right or wrong?

Associative entity: Avoid
40

Degree of Relationships
Degree of a relationship is the number of entity types that participate in it Unary Relationship Between instances of a single entity (one table) “Some rows w some other rows in my own table” Binary Relationship Between instances of two entities Ternary Relationship Between instances of three entities Compared w cardinality - # of entity instances associated w EACH one instance 16

Degree of relationships – from Figure 2-2
A line, not a box 1 2 1 1 2 Entities of two different types related to each other; Most common (2 types) Cardinal-ities 2-59 One entity instance related to another of the same entity type (1 type) Cardinal-ities 2-60 3 Entities of three different types related to each other 8

Unary relationships – ONE entity type
Figure 2-12 Examples of relationships of different degrees Unary relationships – ONE entity type One table; relationship means: “Each row is related to some other row(s) in the same table” 1 table! 22

b) Binary relationships – TWO entity types
Figure 2-12 Examples of relationships of different degrees (cont.) b) Binary relationships – TWO entity types “Each row is related to some row(s) in another table” 2 tables Here are binary degree relationships with all he different possible cardinalities. 22

Contains in PRODUCT_LINE and PRODUCT
1-1 1-M M-N Binary Has_Permit in EMPLOYEE and PERMIT Contains in PRODUCT_LINE and PRODUCT Registers_for in STUDENT and COURSE (Entity A & Entity B) Each row in A may related to 1 row in B; Each row in B may related to 1 row in A Each row in A may related to M rows in B; Each row in B may related to 1 row in A (A on 1 side; B on M side) Each row in A may related to M rows in B; Each row in B may related to N rows in A Unary Married_to in PERSON Manages in EMPLOYEE Wins in TEAM (Entity A & Entity “A’ “) Each row may related to 1 other row Each row in A may related to M other rows; Each row in A’ (same as A; only different subset) may relate to 1 other row Each row in A may related to M other rows; Each row in A’ may relate to N other rows

c) Ternary relationship – Three entity types (3 tables)
Figure 2-12 Examples of relationships of different degrees (cont.) c) Ternary relationship – Three entity types (3 tables) The cardinality of this ternary relationship is many-to-many-to-many. In other words, each vendor could supply many parts to many warehouses. Each part could come from many vendors and housed in many warehouses. Each warehouse could have many parts from many vendors. The dashed line is a way of representing the attributes of the relationship. For a given vendor supplying a given part to a given warehouse, here is a shipping mode and a unit cost. Each of these ternary relationship instances could have its own shipping mode and unit cost. Note: a relationship can have attributes of its own 22

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

Figure 2-14 Ternary relationship as an associate entity
Guidelines: PP.82~83 22

More cases of ternary relationships?
PATIENT – TREATMENT – DOCTOR? STUDENT – COURSE – FACULTY? Guidelines: P. 81 22

Attributes or entity? Fig 2-15a

Attributes or entity? Fig 2-15b

Figure 2-15a and 2-15b Multivalued attributes can be represented as relationships
simple In this figure we see two examples of multivalued attributes on the left. On the right we see instead separate entities with relationships. The top figure shows a simple multivalued attribute, whereas the bottom figure shows a composite multivalued attribute. Note that on the right, it is explicit that there are many to many relationships. For example, although the left side shows that a course can have many prerequisites, there is nothing explicit showing that a course could itself be a prerequisite for multiple other courses. Similarly, on the left it is explicitly shown that an employee can many many skills, but it is not explicitly shown that many employees can share the same skill. The figures on the right, however, do make these facts explicit. The right side of each figure is in Microsoft Visio notation. composite

Attributes or entity? Fig 2-15c
Participating in other relationships

Watch out the difference between Degree of relationship And
Cardinality of Relationships Watch out the difference between Degree of relationship And Cardinality!! # entity types involved – one, two, or three # entity INSTANCEs related – one, or many; Also: mandatory or optional

Cardinality of Relationships
Must examine from BOTH sides to determine One-to-One Each entity instance (in “A”) in the relationship will have exactly one related entity instance (in “B”) One-to-Many An entity instance on one side (in “A”) of the relationship can have many related entity instances (in “B”), but an entity instance in “B” will have a maximum of one related entity instance in “A” Many-to-Many Entity instances on both sides of the relationship can have many related ent. Inst. on the other side Corresponds to “each biz rule has two statements”

Cardinality: correct positioning
New for Fall 2018 Cardinality: correct positioning Minimum Cardinality If zero, then optional If one or more, then mandatory Maximum Cardinality - The max number Each ONE MANY rows Row in A May Own/Advise… in B Verb # A B By 1 & only Is Owned/Advised… Each row row in A in B 4 3 2 # Verb 1 Next slide 29

Fig 2-16 Introducing Cardinality Constraints
Watch the positioning/direction of verb and number

Figure 2-17 Examples of cardinality constraints
a) Mandatory cardinalities: MIN > 0 (cannot be zero) A patient must have recorded at least one history, and can have many (viewed L to R; marked on right) A patient history is recorded for one and only one patient (viewed R to L; marked on LEFT) 1

Examples of cardinality constraints
b) Optional cardinalities: MIN = 0 (can be zero) An EMPLOYEE MAY be assigned to M PROJECTs, but can be assigned to NONE (viewed L to R; marked on right) A PROJECT MUST have at least one EMPLOYEE assigned to it (viewed R to L; marked on LEFT) 1

Degree and cardinality: comparison (1)
40

Degree and cardinality: comparison (2)
1-1, 1:1 1-M, 1:M M-M, M:M (watch green lines) 40

Figure 2-17 Examples of cardinality constraints (cont.)
b) One optional, one mandatory An employee (L) can be assigned to any number of projects (R), or may not be assigned to any at all (viewed L to R) This figure shows a binary many-to-many relationship. In this case one side is mandatory and the other is optional. Here every project must have at least one employee assigned to it, but an employee could possibly not be assigned to any projects. A project (R) must be assigned to at least one employee (L), and may be assigned to many (Viewed R to L) 1

Figure 2-17 Examples of cardinality constraints (cont.)
b) One optional, one mandatory Use the “starting” & “ending” to think about cardinalities A project must be assigned to at least one employee, and may be assigned to many (viewed R to L) An employee can be assigned to any number of projects, or may not be assigned to any at all (viewed L to R) 1

Optional/Mandatory: MIN
1 or M: MAX Cardinality Further Explained (1) Restaurant Each Franchisee Min 0, Max 1 Min 1, Max 1 Min 0, Max M Min 1, Max M Remark Meaning Optional one Mandatory one Optional many Mandatory Many Min 0 is optional Symbol On the “far” end More interpretation Could be 0, up to 1 At least 1, up to 1 Could be 0, up to M At least 1, up to M “Simply out” Maximum 1 (could be 0) 1 and only 1 (cannot be 0) Max many (but could be 0) Max many (but cannot be 0) Can be 0? Yes, can be 0 No, can’t be 0 Min >0 is mandatory EACH Franchisee… Owns… Franchisee Restaurant 40

Verbal Desc Cardinality Further Explained (1-2: verbal desc)
Restaurant Each Franchisee Min 0, Max 1 Min 1, Max 1 Min 0, Max M Min 1, Max M Remark Meaning Optional one Mandatory one Optional many Mandatory Many Min 0 is optional Symbol On the “far” end Verbal Desc Could be one or none One and only one Could be any number or none At least one; one or more EACH Franchisee… Owns… Franchisee Restaurant 40

Cardinality Further Explained (2)
Ent A (“College”) Ent B (“Dept”) Remark Each inst in A AND 1 instance in B One-to-one, 1-1, 1:1 1 instance in A Each inst in B M instance in B One-to-Many, 1-M, 1:M Many-to-Many, M-M, M:M M instance in A IMPORTANT ! ! Each relationship must be examined from BOTH Directions! ! ! Watch sequence Starting_Entity_Type Ending_Ent_Type Cardinality Verb 40

Starting_ Entity Ending_ Entity Max Min Cardinality
Cardinality Further Explained (3) Cardinality Min Max Min and Max can be specified w exact #s Starting_ Entity Verb direction Ending_ Entity Verb direction In the verb direction: first Min, then Max Max Min Cardinality In the whole diagram: MIN closer to center; MAX farther on both ends MAX MIN MIN MAX 40

M-M to Associative Entity (2-17b, explained)
“near center”: MIN In the eyes of EMPOLYEE, PROJECT is optional many; In the eyes of PROJECT, EMPLOYEE is mandatory many. After the associative entity is introduced: The “far ends” are ALWAYS _____________(can be explained) In the eyes of EMPLOYEE, ASSIGNMENT is _________ In the eyes of PROJECT, ASSIGNMENT is ____________ “far ends”: MAX EMPLOYEE ASSIGNMENT PROJECT 40

Optional/Mandatory: MIN
Figure 2-17 Examples of cardinality constraints (cont.) c) Optional cardinalities Optional/Mandatory: MIN 1 or M: MAX Use the “starting” & “ending” to think about cardinalities A person is married to at most one other person, or may not be married at all This is a unary one-to-one relationship. According to this, a person could be married to one or no other person. This figure rules out polygamy. Can you see why? How would we be able to allow polygamy in this ER diagram? (Answer: make it many-to-many). Dawn and Fred are single. Shirley is married to Ellis and Mack is married to Kathy. 1

A B Logical structure of stating cardinalities
EACH A, one B; EACH B, one A – One-to-One EACH A, Many B; EACH B, ONE A – One-to-Many EACH A, Many B; EACH B, MANY A – Many-to-Many Verbal statement of optional and mandatory: “may be/have ___ (1 or M), but could be/have 0/none”; “may be/have ___ (1 or M), but must be/have at least 1” 40

MIN and MAX cardinalities
Ent2 Ent1 Ent4 Ent3 Identify the shapes that represent MIN/MAX cardinalities

Side note: Avoid “MAX < MIN”
Basic E-R notation (Figure 2-2; portion) Relationship cardinalities specify - for EACH instance on the “starting entity type,” the # of instances on the “ending entity type” is allowed {“starting” and “ending” here refer to direction of rela.} Maximum one Maximum many Minimum one Minimum zero Side note: Avoid “MAX < MIN” 8

Recap of MIN/MAX The “far ends” are Min? Max?
The “near-center ends” are Min? Max? So one must always ensure that the “far ends” are never _>? / <?_ “near-center ends” 40

Figure 2-18 Cardinality constraints in a ternary relationship
Here is another example of an associative entity, this time as the center of a ternary relationship. 36

Scenarios of Degree and cardinality
Slide #2-13 revisit and completion Scenarios of Degree and cardinality Cardin# Cardin-intens Binary Unary Ternary 1-1 Optional Mandatory 1-M M-M Will fill now

Figure 2-19 Simple example of time-stamping
Time stamps are useful for keeping historical data. In this case, we see a way of keeping track of price changes over time for products. Can you think of how the price history could be represented as a separate entity instead of a multivalued attribute? What would be the cardinality of the relationship between product and price history? (Answer: one-to-many). The Price History attribute is both multivalued and composite. Time stamp – a time value that is associated with a data value, often indicating when some event occurred that affected the data value 37

Example of time, Fig 2-20a

Example of time, Fig 2-20b

Figure 2-20c E-R diagram with associative entity for product assignment to product line over time
The Assignment associative entity shows the date range of a product’s assignment to a particular product line. Modeling time-dependent data has become more important due to regulations such as HIPAA and Sarbanes-Oxley. 37

Figure 2-21 Examples of multiple relationships
a) Employees and departments Here, we see a one-to-many unary relationship between employees. It shows that a given employee MUST have exactly one supervisor and could supervise any number of other employees (or none at all). We also see two binary relationships between employees and departments. First, each department must have at least one, and possibly many, employees. Each employee must work in exactly one department. Also, each department has exactly one employee as a manager, and each employee can manage at most one department, or possible none at all. The figure illustrates that there could be multiple types of relationships between entities. Entities can be related to one another in more than one way 40

Figure 2-21 Examples of multiple relationships (cont.)
b) Professors and courses (fixed lower limit constraint) Again, we see multiple relationships between two entities, this time between professors and courses. The “Is Qualified” relationship is of binary degree and mandatory many-to-many cardinality. A professor must be qualified to teach at least one course. And a course must have at least two qualified professors. The other relationship is actually implemented via what is called an “associative entity” called Schedule, which has an identifier attribute called Semester. We will shortly talk about associative entities in more detail. This associative entity is implementing a many to many relationship between professors and courses, indicating that a particular professor may be scheduled during a particular semester to many courses, and vice versa. Here, min cardinality constraint is 2. At least two professors must be qualified to teach each course. Each professor must be qualified to teach at least one course. 40

Figure 2-21 Examples of multiple relationships
Extension of Figure 2-21 Examples of multiple relationships c) CUSTOMER and COMPANY, in the Web 2.0 age does_business_with CUSTOMER COMPANY ________?________ Relationship 1: CUSTOMER does_business_with COMPANY Relationship 2: CUSTOMER ________________ COMPANY 40

Figure 2-22 Data model for Pine Valley Furniture Company in Microsoft Visio notation Different modeling software tools may have different notation for the same constructs. As you can see, data models can be quite comprehensive, including many different entities and relationships.

Feedback to HW 1 Definition of an entity is NOT definition of an attribute Business rules: Each relationship must have TWO rules, one from entity A to entity B, another from entity B to entity A In a binary relationship, a biz rule only involves TWO entities – there can NEVER be three entities in a biz rule What cannot be in the E-R diagram: (1) the user of the DB; (2) the output of the DB An unary relationship is where some rows relate to some other rows; “folding” an entity into another entity as an attribute does NOT constitute an unary 40

Summer 2018 addenda 1 – Defining entity
Defining a conference of a professional association A formal gathering of the members of the association With a registration fee Usually in a fixed time in a year In a pre-selected venue With a pre-determined theme related to the development in the field of the profession Usually with one or more keynote speakers Usually organized in sessions 40

Summer 2018 addenda 2 – More about DB terms
Entity types – Tables Entity instances – rows in a table Attributes (of entity) – columns in a table For an instance, each attribute (each column) can have only 1 value; i.e., the intersection of a row and a column can have only 1 value Relationship – interaction/association between 2 entity types (sometimes can be among 3 entity types) Each relationship must be stated with 2 business rules, one from each direction; i.e., when there’re entity types A and B, a rule will be stated from A to B and another from B to A Example: Each FAC advises M STUDENTs (from A to B), each STUDENT is advised by 1 FAC (from B to A) 40

Summer 2018 addenda 3 – Cardinality (definition)
In a relationship involving entity types A and B, cardinality is about: From A to B: Take 1 row (1 entity instance) in table A, how many rows (instances) in table B is/are related From B to A: Take 1 row (1 entity instance) in table B, how many rows (instances) in table A is/are related Cardinality is about rows/instances, while “degree” is about entity types (how many entity types/tables are involved) 40

Summer 2018 addenda 4 – Cardinality (scenarios)
B 40

Summer 2018 addenda 5 – Cardinality (scenarios)
B 40

A A A B A B A B C Summer 2018 addenda 6 – Degree
Number of entity TYPEs (tables) participating in a relationship One entity type: Unary Two entity types: Binary Three entity types: Ternary A A A B A B A B C 40

A A Summer 2018 addenda 7 – Unary
Number of entity TYPEs (tables) participating in a relationship One entity type: Unary Meaning: each row in table A relates to 1 (many) OTHER row(s) in its own table (which is A) Only ONE table is involved – “unary” Related to OTHER row(s) – a row would NEVER relate to itself A A 40

Summer 2018 addenda 8 – ERD logic flow
Steps of ERD development (logic flow) Identify/define entity types Identify/define attributes for each entity type Identify/define relationships State business rules (that contains meaning of cardinality – “for each instance in A, 1 (or M) instances of B can be related) Based on the above, draw the ER diagram About minimal cardinality: When we say “may or may not”, it means that the minimal cardinality can be zero When we say “must”, it means that the minimal cardinality must be a non-zero number 40

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