Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 3 Data Modeling Copyright © 2014 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent.

Similar presentations


Presentation on theme: "Chapter 3 Data Modeling Copyright © 2014 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent."— Presentation transcript:

1 Chapter 3 Data Modeling Copyright © 2014 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education.

2 Learning Objectives 3-2 LO#1 Understand the purpose of structure models. LO#2 Understand and apply the building blocks for UML Class (structure) Diagrams. LO#3 Describe multiplicities for a UML Class Diagram. LO#4 Understand how to implement a relational database from a UML Class Diagram. LO#5 Describe business rules and various forms of rules.

3 Structure Models Describe the data and information structures inherent in a business process Create a blueprint for the development of a relational database to support the collection, aggregation, and communication of process information Facilitate the use of databases after they are implemented 3-3 LO# 1

4 Unified Modeling Language (UML) UML class diagram notation for structure models Specifications for UML maintained by the Object Management Group, a not-for-profit consortium of computer industry members UML also includes notation for several other types of diagrams, including several structure diagrams, behavior diagrams, and interaction diagrams Class diagrams describe the logical structure of a database system 3-4 LO# 2

5 UML Class Diagram – Building Blocks Classes are separately identifiable collections of things about which the organization wants to collect and store information Associations depict the relationship between two classes. Multiplicities describe the minimum and maximum number of times instances of one class can be associated with instances in another class 3-5 LO# 2

6 UML Class Diagram - Classes 3-6 LO# 2 Classes can represent – organization resources (e.g., trucks, machines, buildings, cash, investments) – persons (e.g., customers, employees) – events (e.g., sales, purchases, cash disbursements, cash receipts), and conceptual structures (e.g., accounts, product categories, budgets)

7 UML Class Diagram - Associations Associations depict the (business) relationship between two classes 3-7 LO# 2

8 UML Class Diagram - Multiplicities 3-8 Each Person owns a minimum of 0 and a maximum of many Autos. Each Auto is owned by a minimum of 1 and a maximum of 1 Person LO# 2 Multiplicities describe the minimum and maximum number of times instances in one class can be associated with instances in another class

9 Attributes Attributes are data elements that describe the characteristics of instances in a class (or rows in a table) The full specification of attributes, i.e., a data dictionary, would also include data type, default value (if any), constraints on the value (such as minimum and maximum possible values), and other descriptive information Attributes include the primary keys that uniquely define instances of the class, foreign keys that support the links between classes shown in the associations, and other data elements for each class Attributes will be specified in a table listing that accompanies each class diagram 3-9 LO# 2

10 Primary Keys An attribute or combination of attributes that uniquely identifies each instance in a class or row in a table A primary key cannot be NULL (blank) A primary key should be controlled by the organization that assigns it so it will not change over time 3-10 LO# 2

11 Foreign Keys 3-11 LO# 2 An attribute or combination of attributes that allows tables to be linked together Implements the link between classes (and resulting tables) shown by the associations In the following model, the primary key of the PERSON class would become a foreign key in the AUTO class to implement the association

12 Table Listing - Example 3-12 LO# 2

13 Best Practices in Preparing Class Diagrams Use common terminology in the organization for class names Link classes on the diagram only when there is a clear business purpose for the relationship. Avoid crossing lines where possible Use consistently sized class rectangles Avoid running association lines close together Opt for simplicity Focus first on the accuracy of the content, then address appearance. Use notes to explain more complex situations LO# 2

14 Implementing a Database from a Class Diagram 1.Map classes to tables 2.Map class attributes to table fields and assign primary keys 3.Map associations to foreign keys 4.Create new tables to implement many-to- many relationships 5.Implement relationships among tables following the class diagram 3-14 LO# 4

15 1. Map Classes to Tables 3-15 LO# 4

16 2. Map Class Attributes to Table Fields and Assign Primary Keys 3-16 LO# 4

17 3. Map one-to-many associations to foreign keys 3-17 One-to-many associations are defined by the maximum multiplicity on each end of the association. The rule of thumb is to go toward the * to post the foreign key. So, in the model above, the primary key of STATE would be a foreign key in AUTO; the primary key of PERSON would be also be a foreign key in AUTO. See Table 1 in Chapter 3 for a listing of posting rules based on multiplicities. LO# 3

18 4. Create New Tables to Implement Many-to-Many Relationships 3-18 Many-to-many associations require the creation of a new, linking table to implement the association. So, in the model above, the association between DEALERS and AUTO would be implemented with a new table DEALER-AUTO with a primary key formed as the combination of primary keys from the two classes. LO# 3

19 5. Implement Relationships Among Tables 3-19 LO# 3

20 Business Rules Succinct statement of constraints on a business process Typically written in text not modeled; however, they influence the structure and flow of models. Establish multiplicities in class models and set criteria for branching in activity models. Stated in short sentences The Object Management Group maintains standards for Semantics of Business Vocabulary and Business Rules (SBVR) since 2008 Make modeling business process easier since they limit the number of options allowed by business policy 3-20 LO# 4

21 Types of Business Rules Obligatory. This rule form states what should occur: payment should be made in U. S. dollars. Prohibited: This rule form states what should not occur: no payments by check. Allowed: This rule form says what is allowed under what conditions: credit card payments are allowed if the card is American Express LO# 5


Download ppt "Chapter 3 Data Modeling Copyright © 2014 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent."

Similar presentations


Ads by Google