【正文】 ividual data elements. Most programming languages support a more plex data structure called an array . Each array element can hold one data value. Each element is assigned a unique identifying number of numbers, and individual data elements can be inserted, extracted, or manipulated by referencing those an array has been filled, it can be written to disk, tape, or any other secondary medium, and later read back into memory for processing. Consider a program that generates name and address labels. For each label, we need a name, a street address, a city, a state, and a zip code. If we needed only a few labels we might store the data in a list, but separating the elements would soon bee tedious. An option is to set up an array of names and addresses, with each row holding the data for a single label. The only problem is that the entire array must be in main memory before the individual elements can be accessed, and main memory space is limited. even with an array, we could generate relatively few labels. A better solution is to organize the data as a file . All puter data begin as patterns of bits. On a file, the bits are grouped to form characters. Groups of characters, in turn, form meaningful data elements called fields. A group of related fields is a record。 the file is a set of related records. For example, in a name and address file, and individual39。s name is a field. Each record holds a plete set of data for a single individual (a name, a street address, and so on). The file consists of all the records. The data in a file are processed record by record. Normally, the file is stored on a secondary medium such as disk. Programs are written to read a record, process its fields, generate the appropriate output, and then read and process another record. Because only one record is in main memory at a time, very little memory is needed. Because many records can be stored on a single disk, a great deal of data can be processed in this limited space. Locating Files Imagine a file stored on disk. The first step in accessing its data is finding the rile. The task is much like finding a program, but there are differences. Following a mand such as LOAD or RUN, programs are loaded by the operating system. Data, on the other hand, are processed by application programs, in the context of a program39。s logic. Typically, just before the data are required, the program asks the operating system to open the file. Each file has a name。 the open logic reads the disk index, searches it by name, and finds the address of the first record in the file. Locating Records Once a file has been located, the process of accessing its records can begin. When a program needs input data, it reads a record。 when it is read go output results, it writes a record. Note that these instructions deal with selected records, not with the entire file. We open files. We read and write records. Let39。s examine the data accessing process more closely. A programmer views data logically, requesting the next record, or the name and address for a particular customer. The data are stored on a secondary medium such as disk. To access a record physically, the disk drive must be given a set of primitive mands: seeks, reads, and writes. The programmer thinks in terms of logical I/O. The external device stores and retrieves physical sectors。 it thinks in terms of physical I/O. There must be a mechanism for translating the programmer39。s logical requests to the appropriate physical mands. On small puters, much of the logic is found in the operation system39。s input/output control system。 on larger machines, access methods are used. Increasingly, the programmer39。s logical data request is translated to physical form by a database management system. The Relative Record Concept How does software, be it operating system, access method, or database software, find specific records in a file? The key to many storage and retrieval techniques is the relative record number. Imagine a string of 100 records. Number the first one 0, the second 1, the third 2, and so on. The numbers indicate a given record39。s position relative to the first record in the file. The file39。s first record (relative record 0) is at start of file plus 0。 its second record is at start of file plus 1, and do on. Now, store the records on disk 。 to keep our initial example simple, we39。ll store one per sector. Number the sectors relative to the start of the file0,1,2, and so on. Note that the relative record number, a logical concept, and the relative sector number, it is possible to pute a relative sector number. Give a relative sector number it is possible to pute a physical address on disk. Assume a file begins at track 30, sector 0, and that one logical record s stored in each sector. As Fig. shows, relative record 0 is stored at track 30, sector0。 relative record 1 is at track 30, sector1。 and so on. Where is relative record 10? It must be stored at track 30, sector 10. In our example, the relative record number indicates how many sectors away from the beginning of the file the record is stored. Thus, we can pute the physical location of any record by adding its relative record number to the startoffile address (which, remember, was extracted from the disk39。s index when the file was opened). The file starts at track 30, sector 0. Retative record 10 is stored 10 sectors away, at track 30, sector 10. To read record 10. We have translated a logical data request to specific physical mands. We might plicate matters by storing two or more logical records in each sector, or by creating a file extending over two or more tracks. While we won39。t discuss the details, in either case it is still possible to develop a simple algorithm to pute a record39。s physical location, given its relative record number. Many different algorithms are used. Some allow records to be stored or retrieved sequentially. Others allow individual records to be accessed in rand