1. Trang chủ
  2. » Luận Văn - Báo Cáo

Lecture Accounting information systems: Chapter 3 - Richardson, Chang, Smith

21 100 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 21
Dung lượng 1,24 MB

Nội dung

Chapter 3 - Data modeling. After reading this chapter, you should be able to: Understand the purpose of structure models, understand and apply the building blocks for UML class (structure) diagrams, describe multiplicities for a UML class diagram, understand how to implement a relational database from a UML class diagram, describe business rules and the various forms of rules.

Chapter Data Modeling Copyrightâ2014McGrawưHillEducation.Allrightsreserved.NoreproductionordistributionwithoutthepriorwrittenconsentofMcGrawưHillEducation Learning Objectives • • 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-2 LO# 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# 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 3-4 LO# 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 3-5 instances in another class LO# UML Class Diagram - Classes • 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) 3-6 LO# UML Class Diagram - Associations • Associations depict the (business) relationship between two classes 3-7 LO# UML Class Diagram - Multiplicities • Multiplicities describe the minimum and maximum number of times instances in one class can be associated with instances in another class Example of Association with Multiplicities Options for Multiplicities I ndicator Meaning Person 1 owns * Multiplicities (Cardinalities) Auto Zero or one 1 One only * 0 or m ore * 1 or m ore Each Person owns a minimum of and a maximum of many Autos Each Auto is owned by a minimum of and a maximum of Person 3-8 LO# 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 3-9 Attributes include the primary keys that LO# 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# Foreign Keys • • • 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 3-11 LO# Table Listing - Example Customers [Customer_Number (PK), Customer_Name, Customer_City, Customer_State, Customer_Zip, Customer_Phone] Orders [Order_Number (PK), Order_Date, Delivery_Date, Order_Amount, Shipping_Cost, Customer_Number (FK)] Order_Items [Order_Number + Product_Number (PK), Quantity_Ordered, Price] Inventory [Product_Number (PK), Product_Description, Quantity_on_Hand (QOH), Unit_of_Issue, Current_List_Price, Standard_Cost] 3-12 LO# 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 3-13 together LO# Implementing a Database from a Class Diagram Map classes to tables Map class attributes to table fields and assign primary keys Map associations to foreign keys Create new tables to implement many-tomany relationships Implement relationships among tables following the class diagram 3-14 LO# Map Classes to Tables 3-15 LO# Map Class Attributes to Table Fields and Assign Primary Keys 3-16 LO# 3 Map one-to-many associations to foreign keys 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 in Chapter for a listing of posting rules based on multiplicities 3-17 LO# Create New Tables to Implement Manyto-Many Relationships 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 3-18 LO# Implement Relationships Among Tables 3-19 LO# 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 3-20 maintains LO# 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 3-21 ... many-tomany relationships Implement relationships among tables following the class diagram 3- 14 LO# Map Classes to Tables 3- 15 LO# Map Class Attributes to Table Fields and Assign Primary Keys 3- 16... product categories, budgets) 3- 6 LO# UML Class Diagram - Associations • Associations depict the (business) relationship between two classes 3- 7 LO# UML Class Diagram - Multiplicities • Multiplicities... foreign key in AUTO See Table in Chapter for a listing of posting rules based on multiplicities 3- 17 LO# Create New Tables to Implement Manyto-Many Relationships Many-to-many associations require the

Ngày đăng: 18/01/2020, 17:45

TỪ KHÓA LIÊN QUAN