The Hierarchy of Data is described in the "Foundation Data Concepts" section on page 174 and in Figure 5.2. The table below provides a more complete explanation.
| terminology | Explanation and Example |
|---|---|
| bit | A bit is a "1" or a "0". A bit is the simplest state in a computer and, by itself, is quite uninteresting since nothing can be represented by a single bit. |
| byte | A byte is comprised (almost always) of eight bits, with the pattern created by the bits defining the data stored in the byte. Refer to figure 3.28, page 118, for an example of how bits are used to form bytes. One character, letter, number, or punctuation mark can be stored in a byte. This is the simplest usable unit of storage in a computer. It is, however, still not very interesting since not much more than a middle initial or some sort of code, such as "S" for single or "M" for married, can be stored in a byte. |
| field | A field consists of from 1 to "n" bytes ("n" being some positive integer). A field consists of the number of bytes necessary to store the desired data. For example, a Student Number field consists of six bytes since the Registrar has determined that the student number is six digits long. A zip code field could consist of five bytes (unless you want to use the "+4" notation which would require nine bytes unless you want to include the dash in the zip code, which would require ten bytes). A name field could consist of any number of bytes, but we usually specify enough bytes to accommodate most names. All unused bytes in a field remain blank (which wastes disk storage space), so a balance between name lengths and blanks is attempted. A price field could consist of ten bytes (999,999.99 is the largest amount storable in ten bytes). A company with items that have prices that exceed $999,999.99 will have to specify a price field with ten or more bytes. The number of bytes in a field is determined by the data being stored in the field. Fields store "attributes," data that describe or identify items. |
| record | A record consists of from 1 to "n" fields. A record usually identifies and stores all pertinent data for an "entity," a person, place, thing, or concept. For example, each item in a company's inventory would have a corresponding record. Each record would be comprised of the fields necessary to identify and describe the inventory items. Fields such as part number, description, price, and quantity on hand would define each record for each inventory item. The number of fields in a record is defined by the data required to be stored in order to completely identify and describe each entity. |
| file | A file consists of from 1 to "n" records. A file consists of a group of records that logically belong together. For example, all of the records that describe inventory items logically comprise an "Inventory File." All of the employees of a company could have their payroll records grouped together as a "Payroll File." There would be one record for each employee in the file. The number of files in an IS is defined by the data requirements. Large IS can have hundreds of files, each a logical grouping of records of data. Note that we are concerned with the logical grouping of records. We don't care how records are physically grouped to form files. We let the computer worry about that. |
| database | A database consists of from 1 to "n" files that are logically related to each other. A database is comprised of a group of files that are required to provide all data necessary to accomplish a specific task. For example, to accomplish a sale the database can consist of the Customer File, the Salesperson File, and the Inventory File. To accomplish a purchase of an inventory item from a vendor, the database can consist of the Inventory File, the Vendor File, and the Purchasing File. The key point to recognize here is that the same file can be used in numerous databases as required. A database consists of the files necessary to accomplish a specific task. More on this later. |
Data stored in fields is (usually) in one of three formats (although many other special format are available):
It is the responsibility of users who are defining their data requirements to define field types.
Above is an illustration of an Access query developed using the Sales database. The four data files are related via common fields. The "Specific Sales Records" file is the primary file, the file that provides the data for the sales report (Sales by Customer), while the other files are secondary files because they supply additional information (such as customer name, item price) for the report.
The text mentions SQL queries on page 179. SQL is the "official" database management system language in use today. Below is an illustration of the SQL code generated by the query above. Yes, I'll explain it all in class.
Below is the results of the query, the actual data collected by Access from the four data file. Note that the data are for the fields specified in the query above.
Below is the report generated by the Access "Reports" option. You will find this report in the Sales database.
Figure 5.16 and page 190 provide a good introduction to the three types of database management systems. The "Evaluation of Database Structures" section on page 192 provides a good discussion of the pros and cons of each type of database.
It is essential that you understand the concepts introduced in the "Accessing Databases" section beginning on page 193. The key field is the one field in each record that uniquely identifies the record in the data file. It is your responsibility to designate the key field in each data file.
Key fields are also utilized to relate data files together when queries are formed. Figure 5.20 illustrates this concept (as does the Access query design screen above). It is your responsility to design data files to ensure that required relationships can be developed when needed. For example, if our "Specific Sales Records" file doesn't include the "Salesperson Number" field, then the "Salesperson" cannot be related to it and the salespersons' names cannot be included in the report.
| File Type | Strengths | Weaknesses |
| Sequential | Utilizes minimum computer resources, very compact, good when time access isn't critical | Slow access, will not work when customers are waiting, sequentially searches for specific records, always searches forward, never backwards, cannot "update in place" - a new sequential file is created each time changes are made, must be sorted to keep in logical order |
| Index Sequential ISAM | Fast access, works well in time critical applications, can update in place, can delete unused records, can have gaps in key field values, can use any values as key field values | consumes more computer resources than other types, requires more disk space than other types, indexes must be maintained |
| Direct Access | Ultimate access speed, can find any record in a data file in one disk read operation regardless of the number of records, can update in place, requires less resources than ISAM files | Must maintain a "one to one" logical to physical key field value relationship, key field values must be numbers, cannot delete unused records |