1 / 37

Chapter 7

Chapter 7. Data and Process Modeling. The Data Model. A data model is a plan, or blueprint, for a database design . A data model is more generalized and abstract than a database design.

kelly-conner
Download Presentation

Chapter 7

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 7 Data and Process Modeling

  2. The Data Model • A data model is a plan, or blueprint, for a database design. • A data model is more generalized and abstract than a database design. • It is easier to change a data model than it is to change a database design, so it is the appropriate place to work through conceptual database problems.

  3. E-R Model • Entity-Relationship model is a set of concepts and graphical symbols that can be used to create conceptual schemas. • Versions • Original E-R model— Peter Chen (1976). • Extended E-R model — Extensions to the Chen model. • Information Engineering (IE)— James Martin (1990); it uses “crow’s foot” notation, is easier to understand and we will use it. • IDEF1X— A national standard developed by the National Institute of Standards and Technology [see Appendix B] • Unified Modeling Language (UML)— The Object Management Group; it supports object-oriented methodology [see Appendix C]

  4. Entities • Something that can be identified and the users want to track • Entity class— a collection of entities of a given type • Entity instance— the occurrence of a particular entity • There are usually many instances of an entity in an entity class.

  5. CUSTOMER:The Entity Class and Two Entity Instances

  6. Attributes • Attributes describe an entity’s characteristics. • All entity instances of a given entity class have the same attributes, but vary in the values of those attributes.

  7. Relationships • Entities can be associated with one another in relationships: • Relationship classes: associations among entity classes • Relationship instances: associations among entity instances • In the original E-R model, relationships could have attributes but today this is no longer done. • A relationship class can involve two or more entity classes.

  8. Degree of the Relationship • The degreeof the relationshipis the number of entity classes in the relationship: • Two entities have a binary relationship of degree two. • Three entities have a ternary relationship of degree three. • An example of a binary relationshop

  9. Binary Relationship

  10. Entities and Tables • The principle difference between an entity and a table (relation in a well designed database) is that you can express a relationship between entities without using foreign keys. • This makes it easier to work with entities in the early design process where the very existence of entities and the relationships between them is uncertain.

  11. Cardinality • Cardinality means “count,” and is expressed as a number. • Maximum cardinality is the maximum number of entity instances that can participate in a relationship. • Minimum cardinality is the minimum number of entity instances that must participate in a relationship.

  12. Maximum Cardinality • Maximum cardinality is the maximum number of entity instances that can participate in a relationship. • There are three types of maximum cardinality: • One-to-One [1:1] • One-to-Many [1:N] • Many-to-Many [N:M]

  13. Three Types ofMaximum Cardinality & Binary Relationships

  14. ID-Dependent Entities • An ID-dependent entity is an entity (child) whose identifier includes the identifier of another entity (parent). • The ID-dependent entity is a logical extension or sub-unit of the parent: • BUILDING : APARTMENT • Item: Order_Item • The minimum cardinality from the ID-dependent entity to the parent is always one.

  15. Subtype Entities • A subtype entity is a special case of a supertype entity: • STUDENT : UNDERGRADUATE or GRADUATE • The supertype contains all common attributes, while the subtypes contain specific attributes. • The supertype may have a discriminator attribute that indicates the subtype.

  16. Subtypes: Exclusive or Inclusive • If subtypes are exclusive, one supertype relates to at most one subtype. • If subtypes are inclusive, one supertype can relate to one or more subtypes.

  17. Subtypes: Exclusive or Inclusive (Continued)

  18. Subtypes: IS-A relationships • Relationships connecting supertypes and subtypes are called IS-A relationships, because a subtype IS A supertype. • The identifer of the supertype and all of its subtypes must be identical, i.e., the identifier of the supertype becomes the identifier of the related subtype(s). • Subtypes are used to avoid value-inappropriate nulls.

  19. Chen’s Format

  20. The Relational (Visio) -- explained • Arrowhead on line end to signify “one”; plain line end to signify “many” • Matches object diagram format • Arrowhead points to “parent” • Attributes listed inside entity rectangles • Unique identifiers shown above horizontal line; may be underscored and/or noted with “PK” • Foreign keys usually noted with “FK” • No Many-To-Many relationships, use bridge entities instead

  21. Information Engineering (IE) Format

  22. IE Format -- explained • Widely used • Entities: • Shown with rectangles • Dependent (weak) entities have rounded corners • Name appears outside the rectangle • Foreign keys marked with “(FK)” • Rectangle divided with identifying attributes above the dividing line

  23. IE Format – explained (2) • Relationships: • Identifying Relationships (those with FK included in PK) shown with solid line; • Nonidentifying Relationships shown with dotted line • Maximum cardinality shown at line end with short vertical line (one) or “crow’s foot” (many) • Minimum cardinality shown near line end with circle (zero) or short vertical line (one)

  24. Few skips and discussions • SKIP the rest of ER notations • Subclass design #2 is the best – why? • Process design • Leave it for IS425 and/or IS430 • Flowchart – too old to mention, also not agile • Swim Lane diagram – for object oriented design • Data flow – just too old (younger than flowchart) • CURD – useful for system design IS425, may be

  25. Highline University • The Highline University [HU] database will track such entities as: • Colleges • Departments • Faculty • Students • We have gathered a set of HU reports that will be the source documents for a data model

  26. The College Report

  27. Data Model from the College Report This is a weak, but not ID-dependent, 1:N relationship

  28. The Department Report

  29. The DEPARTMENT / PROFESSOR Relatioship:Alternate Model 1: Using an N:M Relationship This is an N:M relationship

  30. The DEPARTMENT / PROFESSOR Relatioship:Alternate Model 2: Using a 1:N Relationship This is a 1:N relationship

  31. The DEPARTMENT / PROFESSOR Relatioship:Alternate Model 3: Using an Association Pattern This is an association pattern

  32. The DEPARTMENT / PROFESSOR Relatioship:Alternate Model 4: Using a Association Patternand a 1:N Relationship This is a 1:1 relationship This is an association pattern

  33. The Department Major Report

  34. Data Model with STUDENT Entity

  35. The Student Acceptance Letter

  36. Data Model with Advises Relationship

  37. Final Highline University Data Model

More Related