You are here

Managing Data Files

21 September, 2015 - 11:32

Let’s quickly review the hierarchy of data that may already be familiar to you. A characteris a basic unit of data such as a letter, number, or special character. A field is a collection of related characters, such as a customer number or a customer name. A record is a collection of related data fields pertaining to a particular entity (person, place, or thing, such as a customer record) or event (sale, hiring of a new employee, and so on). A file is a collection of related records, such as a customer file or a payroll file. A record layout describes the fields making up a record. These relationships are depicted in part (a) of Figure 3.3.

Chapter 1 introduced you to two types of data, master data (entity-type files) and business event data (event-type files). A business event data processing system may operate on one or more files. Some of these files are used to obtain reference information, such as the warehouse location of an item of merchandise. Other files are used to organize and store the data being collected, such as sales orders or inventory data. Some companies still rely on older, legacy systems that use file structures for data storage.

A database approach is a superior data storage method. In a database approach, tables, not files, are used to organize and store data. For now, we want to discuss data management using well-known terms and concepts associated with files; we’ll get to tables later.

Let’s examine two flowcharts. Figure 3.3, part (b), depicts a typical data maintenance activity—the addition of a new customer record to the customer master data. Figure 3.4 depicts a typical business event data processing activity—entering a customer’s order. In this text, we use the more generic term, data store to distinguish the conceptual file from its physical implementation as a file or database table.

What is important about these two figures? First, the data maintenance activity (Figure 3.3, part b) does not involve a business transaction as such; however, the business event data processing activity (Figure 3.4) does.

Second, the existence of the customer record—including the credit limit [see Figure 3.3, part (a)]—provides the basic authorization required to enter the customer order. Without the customer record, the computer would reject the customer order in Figure 3.4. It is important to separate authorizations for data maintenance activities from authorizations for business event data processing activities. This separation provides an important control, a topic explored in greater detail in Chapters 8 and 9.