1. LOGO Chapter 5 UNDERSTANDING AND DESIGNING ACCOUNTING DATA King Saud University Noura Al.Madi 1

2. Contents Introduction Identifying and Documenting files Attributes and Relationships Developing UML Class Diagram 2

3. Introduction Relational database: database in which data are represented as a set of two-dimensional tables with columns representing attributes and rows representing records Attributes: The smallest units of data that can have meaning to a user. The columns in a relational database that are equivalent to fields in a file. Attribute (Filed) Row (record) 3

4. Identifying and Documenting Files Transaction files: Used to record information about events in a business process. Attributes include: –Transaction date –Agents associated with transaction –Description of products/services associated with event 4

5. Identifying and Documenting Files Master files: Store reference data Store summary data Events and transaction files: First, identify the events in the business process Then, identify the need for transaction files in the AIS 5

6. Identifying and Documenting Files UML class diagram: 1.Shows relationships between transaction and master files 2.Each box represents a file 3.Connecting lines between files indicate file relationships 4.Can be used to document: –Tables in an AIS –Relationships between tables –Attributes of tables Order Order_Date shipment Invoice Cash collection Table (File) Name Attributes (fields) 1 m Relationship 6

7. Identifying and Documenting Files Guidelines for identifying need for transaction tables: 1: Determine the events in the process 2: Exclude events that do not need to be recorded in the computer system 3: Exclude query and reporting events because they involve using data that have already been recorded in the AIS 4: Exclude maintenance events 7

8. Identifying and Documenting Files Events and master tables: Typical master tables: –Products/services - master tables Describe products/services offered Identify costs and/or prices of products/services –Agents - master tables describe External agents Internal agents 8

9. Identifying and Documenting Files –Cash - master file describes where cash is stored –General ledger master file - needed if general ledger system is Automated and Integrated with the revenue or acquisition cycle. Generally, master tables are used to store relatively permanent data about an entity (continued) 9

10. Identifying and Documenting Files Benefits of master tables: Save data entry time Save storage space Simplify making changes to data Simplify deleting transaction records 10

11. Identifying and Documenting Files Structure UML class Diagram (example) General Ledger Goods/ Service EventsAgents Order Shipment Invoice Cash Collection CustomerInventory General Ledger 11

12. Identifying and Documenting Files -Agent associated with events on the right side of events. -Goods/service associated with the event on the left side of the event. -If required Cash Master File, it would be included in the table in the same column as the inventory. -General Ledger master table to the left of goods/services. -Arranging the transaction tables according to the sequence of events make it easier to read the diagram. Guidelines 12

13. Attributes And Relationships Three important concepts: 1.Primary keys 2.Linking attributes (foreign keys) 3.Relationship cardinalities 13

14. Attributes And Relationships This tables applies concepts: Customer #NameAddress Contact_ PersonTelephone # 3450Brownsville C.CBrownsville, TXSmith956-555-0531 3451Educate, Inc.Fairhaven, MACosta508-888-4531 3452Bunker Hill C.CBunker Hill, MALanfranc617-888-8510 Customer Table Order #Order_DataCustomer # 010001105/11/20033451 010001205/15/20033451 010001305/15/20033450 Order Table Foreign key Primary key 14 Primary key

15. Attributes And Relationships 1.Primary key: Attribute(s) that uniquely identifies a record in a table 2.Foreign key: A field in a table that is the primary key in some other table –Used to link one table to another –Link event records to master records –Link two events that occur in a sequence 15

16. Attributes And Relationships 3.Cardinality of the relationship: Cardinality is an expression of the relationship between common fields (attributes) in two tables. Important in designing a database Represents how many occurrences of one type of entity are associated with another type of entity This relationship can be one-to-one (1,1), one-to- many (1,m), or many-to-many (m,m). 16

17. Attributes And Relationships  One-to-one relationships (1,1) - not nearly as common as one-to-many relationships 17 (continued) ShipmentInvoice 1 invoice per shipment 1 shipment per invoice 11  One-to-many relationships (1,m) - common in accounting systems OrderCustomer 1 customer per order many orders per customer over time m1

18. Attributes And Relationships  Many-to-many relationships (m,m) - can be converted into two one-to-many relationships by adding a “junction table” 18 (continued) InventoryOrder many orders per product over time many product per order mm InventoryOrder many detail record per order; 1 order per detail record 1 product per detail record; many detail record per product mm Order Detail 11

19. Attributes And Relationships Significance of concepts for database applications: 1. Implementing documents and reports 2. Implementing input forms –Input forms are used to make data entry more accurate/efficient –Form designs rely on primary and foreign keys and relationships between tables 19

20. Attributes And Relationships 3. Controlling AIS data – referential integrity –For one-to-many relationships we can specify if we want referential integrity enforced on relationship –Control most effective with two other controls: Segregation of duties and Access controls 20 (continued)

21. Developing A UML Class Diagram Example: Fairhaven convenience Store sells gasoline and other products. Customer select product and bring them to the manager. The manager scan the selected products, and the total amount due is displayed on the cash register. The customer give cash to the manager who puts it in the cash register. He gives change (if any) to the customer. Four managers work at the gas station, but only one manager is in the station at any one time. The manager who is in the third shift places the cash in an envelope and drops it in a deposit slot at the bank. 21

22. Developing A UML Class Diagram Four basic steps in Developing A UML Class Diagram Step 1: Place the required transaction tables (files) on the UML class diagram. A. Identify events in a business process. B. Decide which events will need transaction tables. 22 EventIs a transaction tables needed? Make saleYes, The sale and cash collection data should be record in the AIS. Deposit cashPossibly. The company could record the data of the deposit, the amount, and the manager who made the deposit.

23. Developing A UML Class Diagram C. Start the UML class diagram by showing a box for each event requiring transaction tables 23 (continue step 1) sale Deposit

24. Developing A UML Class Diagram Step 2: Place required master tables (files) on UML class diagram A.For each event on the diagram (from Step 1), determine related goods, services, or agent entities 24 EventProduct/ServiceInternal AgentExternal Agent Make saleInventoryManagerCustomer Deposit cashCashManagerBank Teller

25. Developing A UML Class Diagram B. Determine which identified entities require master tables. 25 (continue step 2) Two master table are needed: Inventory Master Table Manager Master Table Not create master table for: Customer: Customers names and address are not needed because the company will not bill customer since they must pay cash and no advertising will be sent to them. Bank teller: There is no need to identify the bank teller to whom a deposit is made.

26. Developing A UML Class Diagram C. Consider using master tables to track location of cash and effect of events on account balances in the general ledger 26 The store does not need a master table for cash since all cash collections are deposited at the same bank. Currently, the general ledger system is not automated, so no General_Ledger master table will be needed in the system. (continue step 2)

27. Developing A UML Class Diagram D. Add required master tables to appropriate side of the UML class diagram 27 Manager Sale Deposit Inventory (continue step 2)

28. Developing A UML Class Diagram Step 3: Determine required relationship between tables A.For each connecting lines, determine cardinality of the relationship between tables B.Write cardinalities next to line between entities 28 m,1 Manager Sale Deposit Inventory m,1 m,m

29. Developing A UML Class Diagram C. If there are any many-to-many relationships, convert them to one-to-many relationships by adding junction table (The junction table must include the primary keys of each of the tables in the many-to-many relationship) 29 Manager Sale Deposit Inventory m,1 Sales Detail m,1 1,m (continue step 3)

30. Developing A UML Class Diagram Step 4: Determine required attributes by: A.Assigning a primary key to each tables B.Linking related tables by adding a foreign key to one of the pair in the relationship (Linking depends on cardinality of the relationship. 30 Manager Sale Deposit Inventory (m,1) Sales Detail (m,1) (1,m) Sale # SSN Deposit # SSN Sale # Product #

31. Developing A UML Class Diagram C. Assign other attributes as needed for providing information content 31 TableInformation attributes neededPrimary Key Foreign Key ManagerLast_Name, First_Name, Address, Fill stats (tax filing status), Exemptions SSN InventoryDescription, supplier, Reorder_Point, Quantity_on_hand Product # SaleDate, Sales_TaxSale #SSN Sale Detail Quantity_Sold, PriceSale #/ Product # Sale #/ Product # DepositDate, AmountDeposit #SSN (continue step 4)

32. Developing A UML Class Diagram Other Consideration in data design: Simplifying the data design: 1. One master table instead of two If different tables have similar purposes and similar or identical structure 32 Server Customer Take Order Cook Prepare Meal

33. Developing A UML Class Diagram 2. Eliminate redundant relationships Delete a line indicating a relationship between two tables if the relationship can be determined from others that occurred earlier. 33 Order Shipment Customer (continued)

34. Developing A UML Class Diagram 3. One event table instead of two If there is a one-to-one relationship between events in a sequence, the designer has the option Option A: Two records in two tables 34 Rental_Transaction #Videotape #Data_RentedCustomer # 1035522005/14/20033201 Rentals Table (used to record rentals only) Return_Transaction #Videotape #Data_Rented 1035522005/14/2003 Return Table (used to record return only) (continued)

35. Developing A UML Class Diagram Option B: One record in one table 35 Rental_Transaction #Videotape #Data_RentedDate_Returned 1035522005/14/200305/17/2003 Rentals and Return Table (continued) 4. Recording agent data in event tables

36. Developing A UML Class Diagram Communicating the data design: Guidelines in preparing documentation: 1. Be consistent in naming entities 2. Name boxes so can easily correlate UML diagram with preceding documentation 3. Help reader understand how each part of the documentation relates to other parts 36

37. Developing A UML Class Diagram Proper layout can also enhance readability 1. Start each part on a separate page 2. Clearly label each part 3. Write a brief explanation of the information obtainable by reviewing diagram 4. Use bulleted lists to explain linkages between diagrams 5. Use same style throughout 37

38. LOGO 38