BIS03 Data Modelling - I
Download as ODP, PDF4 likes2,753 views
The document discusses data modeling, which is the process of analyzing data, identifying relationships, and creating a data model using an entity relationship diagram. It describes the key components of a data model including entities, attributes, primary keys, foreign keys, and relationship types. The goal of data modeling is to visualize informational needs and enable software development.
BIS03 Data Modelling - I
- 1. Business Information Systems Data Modeling - I Prithwis Mukerjee, Ph.D.
- 2. What is a Data Model? DATA MODEL The specification of data structures and business rules to represent business requirements. student id student last name student first name student dormitory student major STUDENT course id course title course number of credits course location course instructor name COURSE attends/ is taught to
- 3. Purpose of Data Modeling Data Modeling is the process used to: Analyze the data Identify the relationships Create the data model We use it to visualize informational needs in the form of an E ntity R elationship D iagram (ERD) Business models often coexist with Data Models to enable software development. Other types of modeling: Business Process Model Functional Model Object Model DATA MODELING A structured approach used to identify major components of an information system’s specifications.
- 4. The Data Modeling Process Modeling Tools Conceptual Data Models Logical Data Models Physical Data Models Modelling Tools ERwin (Entity Relationship Windows) Sterling Software COOL System Architect PowerDesigner DBArtisan VISIO
- 5. CDM A Conceptual Data Model is a structured business view of the data required to support current business processes, business events, and related performance measures. It is a single integrated data structure which reflects the structure of the business functions rather than the processing flow or the physical arrangement of data. Characteristics Represents overall logical structure of data Independent of software or data storage structure Often contains objects not implemented in physical databases Represents data needed to run an enterprise or a business activity
- 6. CDM
- 7. Logical Data Model A Logical Data Model builds upon the business requirements and includes a further level of detail that supports both the business and system requirements. Business rules are incorporated into the LDM and it loses some of the ‘generalities’ from the Enterprise CDM. Characteristics Independent of specific software and data storage structure Includes more specific entities and attributes Includes business rules and relationships Includes foreign keys, alternate keys, and inversion entries
- 8. Entities Each ENTITY represents a set/collection of like individual objects called instances. Each instance must be uniquely identifiable and distinct from all other instances. Each ENTITY should be named using: Unique entity names in a model A non-technical, business-like name A singular noun that describes a singular instance (no collective nouns) ENTITY A person, place, thing, event, or concept about which the business keeps data.
- 9. Defining the Entity Each entity should be fully defined by the business community to: Identify why the business needs this information Improve understanding Avoid redundancy Two types of entities: Independent: depends on no other entity for its identification Dependent: depends on one or more entities for its identification A SERVICE CONTRACT is a PRODUCT representing an AGREEMENT between our COMPANY and the PURCHASER that offers service coverage extending beyond the normal WARRANTY period. LINE ITEM ORDER
- 10. Attributes Attribute Names : Unique attribute names in a model (or entity) A non-technical, business-like name A singular noun that describes a singular instance (no collective nouns) All lowercase (Erwin standard), with spaces attributes employee first name employee last name employee address employee phone number EMPLOYEE ATTRIBUTE A distinct characteristic of an ENTITY for which data is maintained. ENTITY Name (above the box) employee id
- 11. Attribute Types Two types of attributes: Key Non-key consultant id consultant first name consultant last name consultant specialization consultant hourly rate CONSULTANT Key Attribute(s) (above the line) Non-Key Attribute(s) (below the line)
- 12. How do we determine keys? CANDIDATE KEY Any attribute or group of attributes which serves to uniquely identify each instance of an ENTITY. BOOK BOOK BOOK author first name author last name book title book edition book publisher book year published book isbn book lc catalog number author first name author last name book title book edition book publisher book year published book isbn book lc catalog number author first name author last name book title book edition book publisher book year published book isbn book lc catalog number
- 13. Primary Keys Factors to consider: Should be efficient Must not contain any null parts Values must remain static Should be a data element in your control The primary key is always placed above the line in an Entity PRIMARY KEY An ATTRIBUTE or group of attributes that uniquely identifies an instance of the entity. book isbn author first name author last name book title book edition book publisher book year published book lc catalog number BOOK
- 14. Surrogate Keys transaction id account id customer id cash machine id transaction date CASH MACHINE TRANSACTION account id customer id cash machine id transaction date SURROGATE KEY A contrived, non-intelligent, single-attribute key used to replace a long composite key. Composite Key Surrogate Key CASH MACHINE TRANSACTION
- 15. Relationships MOVIE MOVIE COPY is rented as RELATIONSHIP A logical link between two entities that represents a business rule or constraint.
- 16. Foreign Keys FOREIGN KEY (FK) A primary key of a parent entity that is contributed to a child entity across a relationship. contains order number (FK) line item sequence number product code line item quantity line item number line item description LINE ITEM ORDER order number order date order sales representative order customer
- 17. Identifying Relationship The parent Primary Key migrates through the relationship to become part of the Primary Key (IDENTITY) of the child The child is DEPENDENT upon the parent for its identification and cannot exist without the parent Assertion 1: Each MOVIE MASTER <is rented as> 0, 1, or more MOVIE COPYs. Assertion 2: Each MOVIE COPY <is created from> one and only one MOVIE MASTER. Assertion 3: A MOVIE COPY cannot exist without its MOVIE MASTER. MOVIE COPY movie master id (FK) movie copy number movie copy create date movie copy due date movie copy condition is rented as/ is created from MOVIE MASTER movie master id movie name movie star movie type movie rating
- 18. Many-to-Many Relationship A non-specific relationship in which primary keys do not migrate as foreign keys Must have two verb phrases Each phrase states the rule from the perspective of: parent to child child to parent Assertion 1: Each PART <is ordered from > 0, 1, or more SUPPLIERs. Assertion 2: Each SUPPLIER <sends us> 0, 1, or more PARTs. is ordered from/sends us PART SUPPLIER
- 19. Relationship Cardinality PASSENGER AIRPLANE SEAT is ticketed for Z Each parent instance is related to zero, one, or more child instances Each parent instance is related to one or more child instances Each parent instance is related to zero or one child instances Each parent instance is related to exactly “N” child instances CUSTOMER ORDER places DRIVER INSURANCE POLICY covers P TIRE CAR requires N
- 20. Recursive Relationships A recursive relationship: is always a non-identifying relationship allows null values for foreign key A non-identifying non-mandatory relationship in which the same entity is both the parent and the child. RECURSIVE RELATIONSHIP
- 21. Recursive Relationships The parent entity instance’s primary key is migrated to the non-key area of the child entity instance. Each migrating primary key attribute must be given a rolename to clarify the attribute’s foreign key role. Child’s Foreign Key with Rolename Parent’s Primary Key manages EMPLOYEE employee id manager employee id.employee id (FK)
- 22. Referential Integrity : What & Why ? What is the impact of: Inserting, updating, or deleting a Parent Primary Key value? Inserting, updating, or deleting a Child Foreign Key value? None of these actions should break the relationship from Child to Parent Options can be specified as to how the DBMS should manage these actions to maintain referential integrity REFERENTIAL INTEGRITY (RI) Rules that determine what happens when a Parent or Child instance is inserted, updated or deleted.
- 23. Referential Integrity Options RI Option What It Does RESTRICT Does not allow Action CASCADE Duplicates Action in related tables SET NULL Allows Action and sets the Child foreign key to Null SET DEFAULT Allows Action and sets the Child foreign key to the Default value NONE No Restriction placed on Action
- 24. Non-identifying Mandatory Relationship The parent Primary Key migrates as a non-key attribute to the child and does NOT IDENTIFY the child The child is INDEPENDENT of the parent for its identification, but still cannot exist without a parent (mandatory) Assertion 1: Each CUSTOMER <places> 0, 1, or more ORDERs. Assertion 2: Each ORDER <is received from> one and only one CUSTOMER. Assertion 3: An ORDER can be identified without information about a CUSTOMER, but requires a value for the customer id (MUST HAVE A PARENT). ORDER places/ is received from CUSTOMER customer id customer name customer address customer phone order number customer id (FK) order date order status order shipdate
- 25. Non-identifying Optional Relationship The parent Primary Key migrates as a non-key attribute to the child and does NOT IDENTIFY the child The child is INDEPENDENT of the parent for its identification The diamond (optionality indicator) indicates that a child may exist without parent information Assertion 1: Each DEPARTMENT <employs> 0, 1, or more EMPLOYEEs. Assertion 2: Each EMPLOYEE OPTIONALLY <belongs to> a DEPARTMENT. Assertion 3: An EMPLOYEE can be identified without information about the DEPARTMENT, and does not have to be associated with a DEPARTMENT (CAN EXIST WITHOUT A PARENT). employs/ belongs to EMPLOYEE employee id department number (FK) employee name employee address department number department name department location DEPARTMENT
Editor's Notes
- #4: Data models are the communications devices used for the representation of data, generally depicting the entities or “things” of interest to an organization and the relationships between those entities. Data models are an important part of the systems development process; they improve communications with users, and provide a sound logical basis for data base design. Data modeling is the process of creating these communications devices. It is a method of visualizing informational needs and typically takes the form of an ERD (Entity Relationship Diagram). Data modeling is the process used to analyze the data, identify the relationships among these data objects, and create the data model.
- #6: The Conceptual Data Model is a structured business view of the data required to support current business processes, business events, and related performance measurements. This is a single integrated data structure which reflects the structure of the business functions rather than processing flow or physical arrangement of data. It represents the overall logical structure of data required to support the business requirements independent of any software or data storage structure. A conceptual model often contains data objects not yet implemented in physical databases. It is a formal representation of the data needed to run an enterprise or a business activity.
- #7: The conceptual model can then be used to create the logical level, which maps to the designer view in the Zachman framework. The logical model would still be without reference to any specific DBMS, however it would include references to characteristics of databases that are generic in nature (i.e. indices, integrity constraints). It also adds more key and non-key attributes. A Conceptual Data Model represents the entities, which the owners feel are important for doing business. It gives a formal representation of the data needed to run an enterprise or a business activity. The conceptual data model is the owner’s view of the business, and will communicate the framework of the organization to the designers. Conceptual Data Models should be reviewed with business and technical users to ensure the following: to enforce common names, data types and size for the same data elements residing in the operational data store and the data warehouse to enforce common definitions of terms across environments and different business units to ensure agreement on the scope of the data requirements. The Conceptual Data Model (CDM), in conjunction with the business process model, will be used to design both OLTP (On-line Transactional Processing) systems and OLAP (On-line Analytical Processing) systems.
- #8: A Logical Data Model builds upon the business requirements and includes a further level of detail that supports both the business and system requirements. Like the Conceptual Data Model, the Logical Data Model is independent of specific software and data storage structures. Indexes and foreign keys are characteristics of databases that are generic in nature and required of the system for processing. Therefore, a Logical Data Model stores those characteristics without adding anything specific to a single DBMS. Once the development of the logical model is complete, this model can be used to create the physical data model, also known as the builder’s view. This model will reflect characteristics of databases that are the specific requirements of the data stores and the DBMS.