IT353 Module 8 PDF - Conceptual Data Modeling

‫الجامعة السعودیة االلكترونیة‬ ‫الجامعة السعودیة االلكترونیة‬ ‫‪26/12/2021‬‬ College of Computing and Informatics System Analysis and Design  Module 8 Analysis: Conceptual Data Modeling  1. Conceptual Data Modeling Process 2. Gathering Information for Concep...

‫الجامعة السعودیة االلكترونیة‬ ‫الجامعة السعودیة االلكترونیة‬ ‫‪26/12/2021‬‬ College of Computing and Informatics System Analysis and Design  Module 8 Analysis: Conceptual Data Modeling  1. Conceptual Data Modeling Process 2. Gathering Information for Conceptual Data Modeling 3. Entity-Relationship Modeling 4. Business rules and domains 5. Class Diagrams Contents  1. Understand the conceptual data modeling of a system. 2. Recognize and understand entity-relationship model. Weekly 3. Define business roles in conceptual data model Learning Outcomes  Required Reading 1. Chapter 8 and Appendix: Structuring System Data Requirement (Modern Systems Analysis and Design, 9th Edition by Joseph S. Valacich and Joey F. George) Recommended Reading 1. Chapter 5 (Bernd Bruegge and Allen H. Dutoit, "Object- Oriented Software Engineering, Using UML, Patterns, and Java", 3rd ed., Prentice-Hall) This Presentation is mainly dependent on the textbook: Modern Systems Analysis and Design, 9th Edition by Joseph S. Valacich and Joey F. George 1. Conceptual Data Modeling Process Conceptual Data Modeling Process A conceptual data model is a representation of organizational data. It is a detailed model that captures the overall structure of organizational data and is independent of any DBMS or any other implementation considerations. The model can be done in parallel with other requirements analysis and structuring steps during analysis phase of a system. For large projects: Part of the team works on data modeling Part of the team works on process or logic modeling The work of all team members is coordinated and shared through the project dictionary or repository. Maintained by a software tool (example: CASE) Conceptual Data Modeling Process Conceptual Data Modeling Process Each of the process, logic, and data model descriptions describes different views of the same information system; therefore, they should consistent and complete. Example: there should be a correspondence between names of data stores on the primitive-level DFDs and the names of data entities in E-R diagrams. If a system being replaced, the conceptual data modeling process begins with developing a conceptual data model. Why? 1. Conversion of the current files or database into the database of the new system. 2. Understanding of the data requirements. A new conceptual data model is built that includes all of the data requirements for the new system. Conceptual Data Modeling Process There are different kinds of data modeling and database design that are conducted during SDLC. These kinds are: 1. Suitable for the planning and analysis phases 2. Can be used with either 1. A data model developed from scratch. 2. Based on a purchased data model. Conceptual Data Modeling Process Evolving of data model during SDLC: 1. Planning phase E-R diagramming Class diagramming. 2. Analysis phase The data model becomes more specific and is validated. 3. Design phase Final data model developed in analysis is : 1. Matched with designs for systems inputs and outputs. 2. Translated into a format from which physical data storage decisions can be made. 4. Implementation phase Files and databases are defined as the system is coded. 5. Maintenance Phase: Evolution of the data model Conceptual Data Modeling Process Conceptual Data Modeling Process Popular conceptual data modeling methods are: E-R modeling Using a special notation to represent as much meaning about data as possible. Class diagramming Used because of the rapidly increasing interest in object-oriented. We will consider E-R modeling An E-R diagram is the primary deliverable of the conceptual data modeling during the analysis phase. The other deliverable is a full set of entries about data objects that will be stored in the project dictionary, repository, or data modeling software.  Conceptual Data Modeling Process In this sample conceptual data model: 1. Rectangels represent major categories of data. 2. Lines connecting rectangles represent business relationships. 2. Gathering Information for Conceptual Data Modeling Gathering Information for Conceptual Data Modeling Questions and investigations that take a data focus is one of the requirements determination techniques. In addition to process and logic focus. Example: Interviews through: JAD sessions Requirements interviews should gain the perspective on data that is needed to develop or purchase a data model. The data model should answer the following: What the organization does? What rules govern performing the work in the organization? The data model should not answer the following: How are data processed or used? When are data processed or used? Gathering Information for Conceptual Data Modeling You can model data through a combination of different perspectives: 1. Top-down approach Source of deriving business rules for a data model is from the intimate understanding of the nature of the business. Basis for a purchased data model. 2. Bottom-up approach Source of deriving business rules for a data model is from reviewing specific business documents such as computer displays, reports, and business forms. These sources will appear as data flows on DFDs.  Gathering Information for Conceptual Data Modeling Questions to elicit the business rules using Top-down approach.  Gathering Information for Conceptual Data Modeling Example on how to elicit the data from the following form using Bottom-up approach. Data that should be in the database: ORDER NO ORDER DATE PROMISED DATE PRODUCT NO DESCRIPTION QUANTITY ORDERED UNIT PRICE CUSTOMER NO NAME ADDRESS CITY-STATE-ZIP 3. Entity-Relationship Modeling Entity-Relationship Modeling The three main constructs in basic E-R modeling notation: 1. Data entities, Entities in the business environment 2. Relationships, The relationships or associations among those entities 3. Associated attributes The attributes or properties of both the entities and their relationships. E-R model is a detailed, logical representation of the data for an organization or for a business area. E-R diagram is a graphical representation for the E-R model. Remember, E-R diagram is the primary deliverable of the conceptual data modeling during the analysis phase. Entity-Relationship Modeling Entity-Relationship Modeling (Entities) An entity is a person, object, place, event, or concept in the user environment about which the organization wants to maintain data. This entity has its own identity that distinguishes it from other entities. Examples of entities: Person: STUDENT, EMPLOYEE, INSTRUCTOR, PATIENT Place: WAREHOUSE, STATE, CITY, STORE Object: BUILDING, AUTOMOBILE, PRODUCT Event: SALE, REGISTRATION, RENEWAL Concept: ACCOUNT, COURSE, WORK CENTER Entity types vs. Entity instances Entity type is a collection of entities that share common properties or characteristics. Entity instance is a single occurrence of an entity type. Entity-Relationship Modeling (Entities) Guidelines for naming an entity: 1. It should be a singular noun 2. It should be concise. 3. Its definition should include what the unique characteristics are for each instance. 4. Its definition should include what entity instances are included and not included. 5. Its definition should include a description of when an instance of the entity type is created and deleted. 6. Its definition should include a description of when an instance of the entity type is changed into an instance of another entity type. 7. Its definition should include a description of what history is to be kept about entity instances. Note, guidelines 6 and 7 are for some entity types. Entity-Relationship Modeling (Attributes) Each entity type has a set of attributes associated with it. The attribute is a property or characteristic of an entity that is of interest to the organization Relationships also can have attributes. Examples of entities and associated attributes: INSTRUCTOR: Instructor_ID, Instructor _Name, Home_Address, Phone_Number, Major AUTOMOBILE: Vehicle_ID, Brand, Color, Weight, Horsepower EMPLOYEE: Employee_ID, Employee_Name, Address, Entity-Relationship Modeling (Attributes) Guidelines for naming an attribute: 1. It should be a singular noun 2. It should be unique 3. It should follow a standard format 4. If the attribute is similar to other attribute belongs to other entity, their names should be similar but distinguishable. 5. Its definition should state what the attribute is its importance. 6. Its definition should include what is included and not included in the attribute’s value 7. Its definition should state any aliases, or alternative names 8. Its definition should state the source of values for the attribute, and state if the value is required or optional. 9. Its definition should state any relationships that attribute has with other attributes 10. Its definition should indicate if a value for the attribute may change once a value is provided and before the entity instance is deleted. Entity-Relationship Modeling (Attributes) A candidate key is an attribute that uniquely identifies each instance of an entity type. Example of candidate keys For an INSTRUCTOR (Instructor_ID) For a STUDENT (Student_ID) For an EMPLOYEE (Employee_ID) A candidate key can be a combination of attributes that uniquely identifies each instance of an entity type. Example of a candidate key FOR an EMPLOYEE (Combination of Employee_ Name and Address) Assuming no two employees live at the same address and have the same name The candidate key that has been selected to be used as the unique characteristic for an entity type is called an identifier. Entity-Relationship Modeling (Attributes) Other Attribute Types: multivalued attribute repeating group required attribute optional attribute composite attribute derived attribute Entity-Relationship Modeling (Relationships) A relationship is an association between the instances of one or more entity types. It means that there is a linkage between entity instances, or an event has occurred. Entity-Relationship Modeling (Relationships) Guidelines for naming a relationship: 1. It should be a verb phrase 2. It should not be vague names 3. Its definition should explain what action is being taken and its importance. 4. Its definition should clarify the action by giving examples 5. Its definition should explain all optional participation and restrictions 6. Its definition should explain the history in the relationship 7. Its definition should explain whether an entity instance involved in a relationship can transfer participation to another relationship instance. 8. Its definition should explain the reason for any explicit maximum cardinality CONCEPTUAL DATA MODELING AND THE E-R MODEL The number of entity types that participate in that relationship is called the degree of a relationship. Most common relationships: 1. Unary relationships a relationship between the instances of one entity type 2. Binary Relationships a relationship between instances of two entity types 3. Ternary Relationships a simultaneous relationship among instances of three entity types Cardinality is the number of instances of entity X that can be associated with each instance of other entity Y. Minimum cardinality: the minimum number of instances of entity X that may be associated with each instance of entity Y. Maximum cardinality: the maximum number of instances. CONCEPTUAL DATA MODELING AND THE E-R MODEL 4. Business rules and domains Business rules and domains Business rules are specifications that preserve the integrity of the logical data model. Types of business rules: 1. Entity integrity. A unique identifier that is not null for each instance. 2. Referential integrity constraints Rules related to the relationships between entity types. 3. Domains Constraints on valid values for attributes. 4. Triggering operations Rules that protect the validity of attribute values. Business rules and domains Example of domains and triggering operations business rules: PACKAGED CONCEPTUAL DATA MODELS Nowadays, it is almost not necessary for an organization to internally develop its data model. Alternative: Purchase and customize a common database pattern for the business situation. The advantages are: 1. Low cost 2. Developed by industry specialists and expert database technology vendors. Types of packaged data models: 3. Universal data model The data models are applicable to any business or organization 4. Industry-specific data model Designed for a specific business or industry such as health care, banking, and education 5. Class Diagrams Objects and Classes An object has a well-defined role in the application domain, and it has state (data), behavior, and identity characteristics An object is a single occurrence of a class The state of an object encompasses its properties (attributes and relationships) and the values of those properties The behavior of an object represents how an object acts and reacts An operation is simply an action that one object performs upon another in order to get a response A Class is a logical grouping of objects that have the same (or similar) attributes, relationships, and behaviors Class Diagram A class diagram shows the static structure of an object-oriented model: the object classes, their internal structure, and the relationships in which they participate In UML, a class is represented by a rectangle with three compartments separated by horizontal lines The class name appears in the top compartment, the list of attributes in the middle compartment, and the list of operations in the bottom compartment of the rectangle Encapsulation The technique of hiding the internal implementation details of an object from its external view UML Class Representation Two classes, Student and Course, along with their attributes and operations Types of Operations Constructor operation: An operation that creates a new instance of a class Query operation: An operation that accesses the state of an object but does not alter the state Update operation: An operation that alters the state of an object Class-scope operation: An operation that applies to a class rather than an object instance Representation Associations Association: A named relationship between or among object classes Association role: The end of an association where it connects to a class An association is shown as a solid line between the participating classes The degree of an association relationship may be one (unary), two (binary), three (ternary), or higher (n-ary) Multiplicity: A specification that indicates how many objects participate in a given relationship Unary, Binary, and Ternary Associations Unary Ternary Binary Associative Classes If an association itself has attributes or operations of its own or when it participates in relationships with other classes, it is useful to model the association as an associative class. In this example, Registration is modeled as an association class, with its own set of features and an association with another class (Computer Account) Stereotypes for Attributes In E-R diagrams, we designated attributes as being primary keys, and we designated them as multivalued, derived, and other types. This can also be done in a class diagram by placing a stereotype next to the attribute. Stereotypes simply extend the common UML vocabulary , are the stereotypes Representing Generalization Generalization is abstraction of the common features (attributes and operations) among multiple classes, as well as the relationships they participate in, into a more general class The classes that are generalized are called subclasses, and the class they are generalized into is called a superclass A generalization path is shown as a solid line from the subclass to the superclass, with an arrow at the end, and pointing toward the superclass A discriminator shows which property of an object class is being abstracted by a particular generalization relationship Abstract classes have no direct instances, but their descendants may have direct instances Concrete classes can have direct instances Representing Generalization Generalization is abstraction of the common features (attributes and operations) among multiple classes, as well as the relationships they participate in, into a more general class The classes that are generalized are called subclasses, and the class they are generalized into is called a superclass A generalization path is shown as a solid line from the subclass to the superclass, with an arrow at the end, and pointing toward the superclass A discriminator shows which property of an object class is being abstracted by a particular generalization relationship Abstract classes have no direct instances, but their descendants may have direct instances Concrete classes can have direct instances Example: Generalization Example of generalizations, inheritance, and constraints Semantic Constraints in Generalization Overlapping: A descendant may be descended from more than one of the subclasses Disjoint: A descendant may not be descended from more than one of the subclasses Complete: All subclasses have been specified (whether or not shown). Incomplete: Some subclasses have been specified, but the list is known to be incomplete Polymorphism and Related Concepts Class-scope attribute: An attribute of a class that specifies a value common to an entire class, rather than a specific value for an instance Polymorphism: The same operation may apply to two or more classes in different ways Abstract operation: Defines the form or protocol of the operation, but not its implementation Method: The implementation of an operation Example: Polymorphism Example of Polymorphism, abstract operation, class- scope attribute, and ordering Aggregation Concepts Aggregation: A part-of relationship between a component object and an aggregate object It is a stronger form of association relationship (with the added “part-of” semantics) and is represented with a hollow diamond at the aggregate end Composition: A part-of relationship in which parts belong to only one whole object, and the parts live and die with the whole object Composition, represented with a solid diamond is a stronger form of aggregation The multiplicity on the aggregate end may not exceed one Deletion of the aggregate object cascades to its components Example: Aggregation Example of Aggregation and composition  Required Reading 1. Chapter 8 and Appendix: Structuring System Data Requirement (Modern Systems Analysis and Design, 9th Edition by Joseph S. Valacich and Joey F. George) Recommended Reading 1. Chapter 5 (Bernd Bruegge and Allen H. Dutoit, "Object- Oriented Software Engineering, Using UML, Patterns, and Java", 3rd ed., Prentice-Hall) This Presentation is mainly dependent on the textbook: Modern Systems Analysis and Design, 9th Edition by Joseph S. Valacich and Joey F. George Thank You