Tải bản đầy đủ (.pdf) (21 trang)

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

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.24 MB, 21 trang )

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.


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# 1


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# 2

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# 2

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# 2

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# 2

UML Class Diagram - Associations



Associations depict the (business) relationship between
two classes

3-7


LO# 2

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..1

owns

0..*

Multiplicities (Cardinalities)


Auto

0..1

Zero or one

1..1

One only

0..*

0 or m ore

1..*

1 or m ore

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
3-8


LO# 2

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# 2

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

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# 2

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# 2

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# 4

Implementing a Database from a Class
Diagram
1.

2.

3.

4.

5.


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# 4

1. Map Classes to Tables

3-15


LO# 4

2. Map Class Attributes to Table Fields and
Assign Primary Keys

3-16


LO# 3

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 1 in Chapter 3 for
a listing of posting rules based on multiplicities.
3-17


LO# 3

4. 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# 3

5. Implement Relationships Among Tables

3-19


LO# 4


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# 5

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



×