1. Chapter 9 Structuring System Data Requirements

2. Objectives:  Define key data modeling terms.  Draw entity-relationship (E-R) and class diagrams to represent common business situations.  Explain the role of conceptual data modeling in IS analysis and design.  Distinguish between unary, binary, and ternary relationships.  Define four types of business rules.  Compare the capabilities of class diagrams vs. E-R diagrams.  Relate data modeling to process and logic modeling.

3. Structuring System Data Requirements  DFDs show data at rest  Structured English, decision tables and decision trees show the decision logic of processing data  The above techniques do not show the definition, structure and relationships within the data  Structural information about data is essential for automatic program generation  Most common format for data modeling: entity- relationship (E-R) diagrams

6. Conceptual Data Modeling  A detailed model that captures the overall structure of data in an organization Done in parallel with other requirements analysis and structuring steps Work of all team members is shared through the project repository – consistency and completeness is paramount!  Independent of any database management system (DBMS) or other implementation considerations

7. Process of Conceptual Data Modeling  Develop a data model for the current system  Develop a new conceptual data model that includes all requirements of the new system Conceptual data models are suitable for the planning and analysis phases  In the design stage, the conceptual data model is translated into a physical design  Project repository links all design and data modeling steps performed during SDLC Trace field from a physical data record back to an attribute on a data model diagram

8. Deliverables and Outcome  Primary deliverable is an entity-relationship (E- R) diagram or class diagram  As many as 4 E-R or class diagrams are produced: E-R diagram that covers data needed in the project’s application E-R diagram for the application being replaced E-R diagram for the whole database from which the new application’s data are extracted E-R diagram for the whole database from which data for the application system being replaced is drawn

9. Deliverables and Outcome  Second deliverable is a set of entries about data objects to be stored in repository or project dictionary. Repository links data, process, and logic models of an information system. Data elements included in the DFD must appear in the data model and vice versa. Each data store in a process model must relate to business objects represented in the data model.

11. Requirements Determination Questions for Data Modeling  What are subjects/objects of the business? Data entities and descriptions  What unique characteristics distinguish between subjects/objects of the same type? Primary keys  What characteristics describe each subject/object? Attributes and secondary keys  How do you use the data? Security controls and user access privileges

12. Requirements Determination Questions for Data Modeling  Over what period of time are you interested in the data? Cardinality and time dimensions  Are all instances of each object the same? Supertypes, subtypes, and aggregations  What events occur that imply associations between objects? Relationships and cardinalities  Are there special circumstances that affect the way events are handled? Integrity rules, cardinalities, time dimensions

13. Introduction to Entity-Relationship (E-R) Modeling  Entity-Relationship (E-R) Diagram A graphical representation of an E-R model E-R model: A detailed, logical representation of the entities within a business environment, the associations among those entities and the attributes or properties of both the entities and their relationships  Notation uses three main constructs: Data entities Relationships Attributes

14. Person, place, object, event or concept about which data is to be maintained (NOUN, CAPS, inside rectangle) Entity type: collection of entities with common characteristics Entity instance: single entity of an entity type named property or characteristic of an entity (for entity STUDENT: Student_Id, Student_Name, Home_Address) Note formatting! Association between the instances of one or more entity types

15. Naming and Defining Entity Types  Singular noun (Customer, Student)  Descriptive and specific (customer order vs. purchase order)  Concise  What’s included and not included  When an instance might change into an instance of another entity type (quote  order)

16. Naming and Defining Attributes  A named property or characteristic of an entity  Unique noun that follows a standard format  Similar attributes of different entity types should use similar but distinguishing names: Faculty_Phone; Student_Phone  Attribute definition: What’s included and not included: Salary excludes benefits, bonuses, etc. Required or optional  May not appear on CASE diagram; will be in repository

17. Identifier Attributes  Candidate key Attribute (or combination of attributes) that uniquely identifies each instance of an entity type  Identifier A candidate key that has been selected as the unique identifying characteristic for an entity type

18. Identifier Attributes  Selection rules for an identifier 1.Choose a candidate key that will not change its value. 2.Choose a candidate key that will never be null. 3.Avoid using intelligent keys. first two digits of a key for a PART entity may indicate warehouse location which can change 4.Consider substituting single value surrogate keys for large composite keys. Game_ID is a better choice for the entity GAME than Home_Team and Visiting_Team combination

19. Multivalued Attributes  An attribute that may take on more than one value for each entity instance  Represented on E-R Diagram in two ways: double-lined ellipse – may state attribute names within ellipse weak entity – create another entity of the repeating data and then use a relationship to link the weak/repeating entity to its associated regular entity

20. Entity and Attribute Example

21. Degree of Relationship  Relationship: an association between instances of one or more entity types  Degree: number of entity types that participate in a relationship  Three cases: Unary: between two instances of one entity type Binary: between the instances of two entity types Ternary: among the instances of three entity types

23. Cardinality  The number of instances of entity B that can or must be associated with each instance of entity A  Minimum Cardinality The minimum number of instances of entity B that may be associated with each instance of entity A  Maximum Cardinality The maximum number of instances of entity B that may be associated with each instance of entity A  Mandatory vs. Optional Cardinalities Specifies whether an instance must exist or can be absent in the relationship

24. Cardinality Symbols

25. Binary Relationship Examples

26. Naming and Defining Relationships  Verb Phrase  Avoid vague names – use “action” verbs  Definition should: Give examples to clarify the action – relationship Registered_for covers both in-person and online registration Explain optional participation Explain reason for any explicit maximum cardinality – company policy that a sales rep can only carry 10 accounts Explain any restrictions: An employee cannot supervise him or herself Transferable – “places order” cannot be transferred to another customer

27. Associative Entities  An entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances  An associative entity is: An entity A relationship  This is the preferred way of illustrating a relationship with attributes  The data modeler chooses to model the relationship as an entity type to clarify the relationship

29. Ternary relationship …as an associative entity

30. When the associative entity has other relationships with entities besides the relationship that caused its creation then it must be represented as an associative entity.

31. Supertypes and Subtypes  Subtype: a subgrouping of the entities in an entity type that shares common attributes or relationships distinct from other subtypes  Supertype: a generic entity type that has a relationship with one or more subtype  Patient (line with a circle) is connected to two subtypes, Outpatient and Resident Patient  U-shaped symbol by the subtype indicates that it is a subset of the supertype Outpatient, inpatient  Attributes shared by all patients are associated with the supertype  Attributes unique to a particular subtype are associated with that subtype

32. Rules for Supertype/Subtypes Relationships  Total specialization: an entity instance of the supertype must be an instance of one of the subtypes  Partial specialization: an entity instance of the supertype may or may not be an instance of one of the subtypes  Disjoint: an entity instance of the supertype can be an instance of only one subtype  Overlap: an entity instance of the supertype may be an instance of multiple subtypes

34. Business Rules  Specifications that preserve the integrity of the logical data model  Four types Entity integrity: unique, non-null identifiers Referential integrity constraints: rules governing relationships Domains: valid values for attributes Triggering operations: other business rules regarding attribute values

35. Domains  The set of all data types and ranges of values that an attribute can assume  Several advantages 1.Verify that the values for an attribute are valid 2.Ensure that various data manipulation operations are logical 3.Help conserve effort in describing attribute characteristics Characteristics for all types of accounts are the same (checking, savings, loan) Associate each of these accounts with the domain Account_Number (define once, same format)

36. Triggering Operations  An assertion or rule that governs the validity of data manipulation operations such as insert, update and delete  Components: User rule: statement of the business rule to be enforced by the trigger Event: data manipulation operation that initiates the operation Entity Name: name of entity being accessed or modified Condition: condition that causes the operation to be triggered Action: action taken when the operation is triggered

38. Packaged Data Models  Generic data models that can be applied and modified for an organization  Two categories Universal Industry-specific  Benefits Reduced implementation time and cost High-quality modeling

39. Object Modeling Using Class Diagrams  Object-oriented approach  Based on Unified Modeling Language (UML)  Features Objects and classes Encapsulation of attributes and operations Polymorphism Inheritance

40. Objects  Object: an entity with a well-defined role in an application  Each object has: State: encompasses the attributes, their values, and relationships of an object Behavior: represents how an object acts and reacts Identity: uniqueness, no two objects are the same

41. Classes  Class: a logical grouping of objects with similar attributes and behaviors  Operation: a function or service provided by all instances of a class  Encapsulation: the technique of hiding internal implementation details of an object from external view

42. Class Diagram  A diagram showing the static structure of an object-oriented model

43. Types of Operations  Constructor Creates a new instance of a class  Query Accesses the state of an object  Update Alters the state of an object  Scope Applies to a full class rather than an individual instance

44. Representing Associations  Association: a relationship among instances of object classes  Association role: the end of an association where it connects to a class  Multiplicity: indicates how many objects participate in a give relationship

45. UML associations are analogous to E-R relationships. UML multiplicities are analogous to E-R cardinalities.

46. Multiplicity notation: 0..10 means minimum of 0 and maximum of 10 1, 2 means can be either 1 or 2 * means any number

47. Association Class  An association with its own attributes, operations, or relationships

48. Derived Attributes, Associations, and Roles Derived items are represented with a slash (/). Derived attributes are calculated based on other attributes

49. Generalization  Superclass-subclass relationships  Subclass inherits attributes, operations, and associations of the superclass  Types of superclasses Abstract: cannot have any direct instances Concrete: can have direct instances

50. Generalization and inheritance implemented via superclass/subclasses in UML, supertypes/subtypes in E-R

51. Polymorphic Operations  The same operation may apply to two or more classes in different ways  Abstract operations defined in abstract classes defined the protocol, but not the implementation of an operation  Methods the implementation of an operation

52. Polymorphism: Here, each type of student has its own version of calc-tuition() Abstraction: Student is an abstract class and calc-tuition() is an abstract operation (italicized) Class scope: tuitionPerCred is a class-wide attribute

53. Aggregation and Composition  Aggregation A part-of relationship between a component and an aggregate object  Composition An aggregation in which the part object belongs to only one aggregate object and lives and dies with the aggregate object

54. Aggregation is represented with open diamonds Composition is represented with filled diamonds