Presentation is loading. Please wait.

Presentation is loading. Please wait.

IS 4420 Database Fundamentals Chapter 3: Modeling Data in the Organization Leon Chen.

Similar presentations


Presentation on theme: "IS 4420 Database Fundamentals Chapter 3: Modeling Data in the Organization Leon Chen."— Presentation transcript:

1 IS 4420 Database Fundamentals Chapter 3: Modeling Data in the Organization Leon Chen

2 2 Systems Development Life Cycle Project Identification and Selection Project Initiation and Planning Analysis Physical Design Implementation Maintenance Logical Design Enterprise modeling Conceptual data modeling Logical database design Physical database design and definition Database implementation Database maintenance Database Dev e lopment Process

3 3 Overview What is data modeling Importance of data modeling Business rules Entity-relationship model: entities, relationships, and attributes

4 4 Conceptual Data Modeling Business Rules -Data names -Data definitions Conceptual Data Model (Entity-Relationship Diagram)

5 5 Data Modeling is the Most Important Input for follow-up processes Data rather than (piuttosto che) processes are the most complex Data tend to be more stable than business processes (I dati tendono ad essere più stabili dei processi)

6 6 Business Rules Statements that define or constrain some aspect of the business. For example:  Friday is business casual dress day  Students can only register a course if prerequisite is successfully completed Automated through DBMS software

7 7 Entity-Relationship Model A logical representation of the data for an organization or for a business area 3 constructs:  Entity - person, place, object, event, concept (often corresponds to a row in a table)  Attribute - property or characteristic of an entity (often corresponds to a field in a table)  Relationship – link between entities (corresponds to primary key-foreign key equivalencies in related tables)  Type vs. instance Entity type: Instructor Entity instance: Leon Chen Entity-Relationship Diagram  A graphical representation of entity-relationship model  Also called E-R diagram or just ERD STUDENT Name Registers

8 8 Sample E-R Diagram (Figure 3-1) Supplier_ID Supplier_Name Supplier_Address Attribute

9 9 Entity Person: EMPLOYEE, STUDENT Place: WAREHOUSE, COUNTRY Object: BUILDING, MACHINE Event: SALE, REGISTRATION Concept: ACCOUNT, COURSE EMPLOYEE DEPENDENT Strong entity Weak entity Associative entity CERTIFICATE

10 10 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 )

11 11 Attribute Attribute - property or characteristic of an entity type Classifications of attributes:  Required vs. Optional Attributes  Simple vs. Composite Attribute  Single-Valued vs. Multivalued Attribute  Stored vs. Derived Attributes  Identifier Attributes - keys

12 12 Required vs. Optional Attributes Example: entity – ONLINE_ACCOUNT  Required attributes (Not NULL) Account_ID Password Owner_Name  Optional attributes Phone_Number Password_Hint

13 13 Figure 3-7 – A composite attribute An attribute broken into component parts

14 14 Figure 3-8 – Entity with a multivalued attribute (Skill) and derived attribute (Years_Employed) Derived from date employed and current date Multivalued: an employee can have more than one skill (speaks Chinese, plays tennis)

15 15 Figure 3-19 – An attribute that is both multivalued and composite This is an example of time-stamping. More examples?

16 16 Identifiers (Keys) Identifier (Key) - An attribute (or combination of attributes) that uniquely identifies individual instances of an entity type Candidate Key – an attribute that could be a key. Examples (for STUDENT, PERSON)? Simple Key versus Composite Key

17 17 Figure 3-9a Simple key attribute The key is underlined

18 18 Figure 3-9b Composite key attribute Flight_NumberDate

19 19 Guidelines for Identifiers Will not change in value Will not be null Substitute new, simple keys for long, composite keys  ?  Game_Number

20 20 Relationship Relationship Type vs. Relationship Instance Degree (grado) of a relationship Cardinality of a relationship (Associative Entity – combination of relationship and entity)

21 21 Figure 3-11a The relationship type is modeled as the diamond and lines between entity types attribute of the relationship

22 22 Relationship Instance is between specific entity instances

23 23 One entity related to another of the same entity type Entities of two different types related to each other Entities of three different types related to each other Degree of a relationship is the number of entity types that participate in it

24 24 Cardinality of a Relationship 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

25 25

26 26

27 27 Note: a relationship can have attributes of its own

28 28 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. Examples?  If zero, then optional  If one or more, then mandatory Maximum Cardinality. Examples?  The maximum number

29 29 Cardinalities Mandatory one Mandatory many Optional one Optional many 11 18

30 30 Figure 3-16a Basic relationship Mandatory minimum cardinalities – Figure 3-17a

31 31 Figure 3-17c Optional cardinalities with unary degree, one-to-one relationship

32 32 max cardinality constraint Maximum Cardinality Constraint

33 33 Entities can be related to one another in more than one way

34 34 Attributes can be transformed to relationships Attributes or Relationship?

35 35 Attributes should be transformed to relationships Attributes or Relationship?

36 36 OPZIONALE(Associative Entities) It’s an entity – it has attributes AND it’s a relationship – it links entities together When should a relationship with attributes 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 should have at least one or more attributes other than the identifier  The associative entity may participate in other relationships other than the entities of the associated relationship  Ternary relationships should be converted to associative entities

37 37 Figure 3-11b – An associative entity (CERTIFICATE)

38 38 Relationship degrees specify number of entity types involved( COINVOLTO ) Entity symbols A special entity that is also a relationship Relationship symbols Relationship cardinalities specify how many of each entity type is allowed Attribute symbols

39 39 Sample E-R Diagram (Figure 3-1) Supplier_ID Supplier_Name Supplier_Address Attribute


Download ppt "IS 4420 Database Fundamentals Chapter 3: Modeling Data in the Organization Leon Chen."

Similar presentations


Ads by Google