Accounting Information Systems: Essential Concepts and Applications Fourth Edition by Wilkinson, Cerullo, Raval, and Wong-On-WingChapter 4: Data ManagementSlides Authored by Somnath Bhattacharya, Ph.D.Florida Atlantic University

DataData may be defined broadly to include two interrelated components:Data Models that provide structure to dataFile OrientationData-base OrientationData valuesA firms data resource involves four major functions:Record & Repository CreationRepository Maintenance through additions and updatesData RetrievalData Archival and Removal

EntitiesAn Entity is an object, person, or event about which a firm wants to collect and maintain dataCharacteristics of Entities are AttributesEach attribute stored in the system is a Data ElementThere is usually a one-to-one correspondence between attributes and data elementsA broadly defined attribute may have several specific attributes and therefore data elements. e.g., Shipping AddressStreet AddressCityStateZip CodeCountry

Data ModelsFileRecordData ElementData-sets (or Tables)RecordData ElementData-baseFilesData-basesFigure 4-1

Data ElementsEvery recorded attribute of an entity is a data elementField Length: This is the number of contiguous positions required to store a data elementData Type:CharacterNumericDateRawData Value

Some Specifics

File Classifications (Master Files)Master files: These contain (semi) permanent data (records) pertaining to entities (people, places, and things). Accounting related examples include:General and Subsidiary ledgersGeneral ledger master fileCustomer/Accounts Receivable master fileVendor/Accounts Payable master fileInventory master fileEmployee/Payroll master fileOpen WIP master fileStandard cost master file

File Classification (Transaction Files - I)Transaction files: These contain records pertaining to events currently being processed, such as sales, receipts of goods, etc.Transaction files capture detailed transaction data. They are counterparts to general and special journals in manual systemsTransaction data are periodically posted to related master file(s) and are then either purged or archived

File Classification (Transaction Files - II)Accounting related transaction files include:General/Special journal file (General ledger)Sales/Cash receipts file (Accounts receivable)Receiving/Purchases file, Cash disbursements file (Inventory, Accounts payable)Inventory issuance file/shipment file/sales file/adjustments file (Inventory)Payroll/Cash disbursements (Payroll)

Other File Classifications - IReference files: These contain tables or lists of data needed for making calculations or for checking the accuracy of input data. e.g., product price tables, customer lists, etc.History files: These are also called archive files since they contain records pertaining to completed transactions such as past salesOpen files: These record incomplete transactions. Whereas transaction files are purged or archived at the end of a given period, open files remain indefinitely open. Only individual records from Open files get purged as the transaction actually occurs or does not. e.g., Open sales order file Sales transaction file

Other File Classifications - IIReport files: These are derived from records within master or transaction files. e.g., data may be periodically extracted from the Accounts Receivable master file to construct an aging scheduleBackup file: This is a copy of a current file generated so that the original file can be recreated from itSuspense file: This is a collection of those records of a transaction file that appear to contain erroneous or questionable data

Record-KeyRecord keys: These are data elements within records that serve as sort keys. e.g., customer-account numberTwo types of keys often used in master and transaction file records are a primary key and one or more secondary keysA Primary key (also called a record key) is the attribute that uniquely identifies a specific record. They are usually of numeric or alphanumeric modes, e.g., customer numberA Secondary key is an attribute other than the primary key and represents an alternative way to sort or access records in a file, e.g., customer last name

FlagsFlags that are symbols or characters used for control purposes, e.g., end-of-batch flag.Flags are not visible to the end-user. It is a system-managed field that is transparent to the user.

Logical View Versus Physical Storage of Records - IFile structure pertains either to logical file structures or to physical file structuresThe logical file structure defines the users perspective of a file. For example, each logical record in a computerized customer master file pertains to a particular customerData contained in logical records must necessarily be physically mapped onto storage mediaFile organization refers to the methods by which data in logical records are stored on physical storage media

Logical View Versus Physical Storage of Records - IIFiles stored on physical media are seen as a collection of physical recordsSometimes there may be a one-to-one correspondence between logical and physical records (unusual)Sometimes a logical record may occupy more than one physical record - typically on magnetic disksSometimes two or more logical records may occupy one physical record - typically on magnetic tape

Design Considerations for Records & Files - IManaging files and records requires the answering of questions such as:How should the records be structuredWhat type of file organization and access method (e.g., sequential, indexed sequential, random) should be usedHow long should records be retained

Design Considerations for Records & Files - IIThe answers to the above questions also depend in part on the requirements of the application being designedThese requirements, in turn, are affected by issues such as:storage requirementsefficiency in file maintenanceaccessibility of stored data

Establishing Record Structures - IThe structure of a record is defined by its:content arrangementmodes of data fieldslengths of data fieldskeysGenerally the primary keys are placed to occupy the first fields of the recordsGenerally balance amounts or amounts of transactions are placed in the last fields

Establishing Record Structures - II Transaction records are usually arranged somewhat in accordance with the placement of the elements on the source documents (e.g., sales invoices)The modes and lengths of the fields depend on the nature of data placed therein, while the keys are expressed as codesAn important design issue is the extent to which records should be consolidated. This issue is especially important in relational database normalizations and table designs

File-Oriented Approach to Data StorageIn the file-oriented approach to data storage computer applications maintain their own set of filesThis traditional approach focuses on individual applications, each of which have a limited number of users, who view the data as being owned by them

Deficiencies of the File-Oriented Approach Files and data elements used in more than one application must be duplicated, which results in data redundancyAs a result of redundancy, the characteristics of data elements and their values are likely to be inconsistentOutputs usually consist of preprogrammed reports instead of ad-hoc queries provided upon request. This results in inaccessibility of dataChanges to current file-oriented applications cannot be made easily, nor can new developments be quickly realized, which results in inflexibilityIt is difficult to represent complex objects using file processing systems.

The Database Approach to Data StorageA database is a set of computer files that minimizes data redundancy and is accessed by one or more application programs for data processingThe database approach to data storage applies whenever a database is established to serve two or more applications, organizational units, or types of usersA database management system (DBMS) is a computer program that enables users to create, modify, and utilize database information efficiently

Documenting Data in Data-Base SystemsThe Conceptual Data Model is the logical grouping of data on entitiesTwo common Conceptual Data Modeling techniques are:The Data DictionaryEntity-Relationship Diagrams

Data DictionaryA data dictionary is a computer file that maintains descriptive information about the items in a databaseEach computer record of the data dictionary contains information about a single data item used in an AISExamples of information that might be stored in a data dictionary are source document(s) used to create the data item, programs that update the data item and classification information about the items length and data type

Data Modeling Via the Entity-Relationship Diagram - IThe Entity-Relationship Model is a high level conceptual data model that specifies the data base structure independent of any specific DBMS (hierarchical, network, relational, object-oriented)It is only after completing the E-R model that a particular DBMS is selected. Then the high level model is mapped into schemas using the DDL provided by a given DBMS

Entity-Relationship Diagram - IIIn order to arrive at a specific E-R model, one must select the entities first, and then define the relationship between them (cardinalities: one-to-one, one-to-many, many-to-many)Rectangle=EntityDiamond=RelationshipLine=Links:attribute to entityentity to relationshipattribute to relationshipSometimes we use ellipses to represent specific attributes of entities, e.g., customer_#, student_last_name, etc.To go from the ER model to a specific conceptual data model (hierarchical, network, relational, object-oriented), we typically assign attributes to the entities and relationships so as to obtain fully specified pointers (hierarchical & network), and normalized tables (relational)

Advantages of the Database ApproachEfficient use of computerized storage spaceEach subsystem has access to the others information All application programs utilize the same computer file, thereby simplifying operationsFewer backup files for security purposesRelieves some users from data-gathering responsibilities in situations where these users previously gathered their own data

Disadvantages of the Database ApproachDatabases can be expensive to implement because of hardware and software costs.Additional software, storage, and network resources must be usedA DBMS can only run in certain operating environments,which makes some unsuitable for certain alternate hardware/operating system configurationsBecause it is radically different from the file-oriented approach, the database approach may cause initial inertia, or complications and resistance

Data-Flow DiagramsA data-flow diagram shows the physical and logical flows of data through a transaction processing system without regard to the time period when each occursPhysical devices that transform data are not used in the logical diagramsBecause of the simplified focus, only four symbols are needed

Symbols used in Data Flow DiagramsA square represents an external data source or data destination. The latter is also called a sinkA circle (or bubble) indicates an entity or a process that changes or transforms dataA bubble can either be an internal entity in a physical DFD or a process in a logical DFDAn open-ended rectangle or a set of parallel lines represents a store or repository of dataThe file may represent a view or a portion of a larger entity-wide data baseA line with an arrow indicates the direction of the flow of data

Physical DFDsA Physical DFD documents the physical structure of an existing system. It answers questions such as Where an entity works, How an entity works, the work is done by Whom, etc.Given the very physical focus of a physical DFD, it changes whenever the entities, technology used to implement the system, etc. changesPhysical DFDs have no lower levelsThis limitation makes physical DFDs cumbersome to work with, and usually of limited value

Logical DFDs - ILogical Data flow diagrams are usually drawn in levels that include increasing amounts of detailA top level (or high-level) DFD that provides an overall picture of an application or system is called a context diagramA context diagram is then decomposed, or broken down, into successively lower levels of detail

Logical DFDs - IILogical Data flow diagrams document the processes in an existing or proposed system (What tasks)Because the logic of a system changes infrequently, relative to its physical nature, a logical DFD will remain relatively constant over time Logical Data flow diagrams typically have levels below the level-0 diagram

The Hierarchy of Data-Flow Diagrams

A Context DiagramCustomerCashReceiptsProcessBankPaymentDepositDataflows(Interfaces)Process bubble}Boundary (border between asystem and its environment)Relevant Environmentcomprised of External EntitiesThis is a flow connecting a systemwith its environment

A Physical DFDCustomerSalesClerk1.0Book-Keeper3.0Cashier2.0BankBlue sales bookCashOrder &registertapeVerifiedregister tapeDeposit slip& cashSalesinformationForm 66W1. Bubbles are labeledwith nouns2. Data flows & files havephysical descriptions

A Logical DFDCustomer1.0ReceivePayment2.0CompareCash &Tape4.0RecordSale3.0PrepareDepositBankSales JournalPaymentReceipts &receipts summarySales recordVerified receiptssummarySales dataVerified receiptsDeposit1) Bubbles are labeled withverbs that describe the activitytaking place2) Data flows & files have logicaldescriptions

Accounting Information Systems: Essential Concepts and Applications Fourth Edition by Wilkinson, Cerullo,Raval, and Wong-On-WingCopyright 2000 John Wiley & Sons, Inc. All rights reserved. Reproduction or translation of this work beyond that permitted in Section 117 of the 1976 United States Copyright Act without the express written permission of the copyright owner is unlawful. Request for further information should be addressed to the Permissions Department, John Wiley & Sons, Inc. The purchaser may make back-up copies for his/her own use only and not for distribution or resale. The publisher assumes no responsibility for errors, omissions, or damages, caused by the use of these programs or from the use of the information contained herein.