Storage level control of a CODASYL data base: Part II
D W Manhood · ITNOW · 1980
In Part I an example schema and storage schema were presented. This initial storage schema is, by default, referred to as Version 1. This article presents Version 2 of the storage schema, the schema remaining unchanged. Figure 1 illustrates the new storage structures and Figures 2 and 3 together are the DSDL description of Storage Schema BANK-STORE Version 2. The first point to note is that Version 2 of BANKSTORE contains the whole of Version 1. The reason for this will be explained later in this article dealing with ‘Reorganisation’. To begin with, however, the Version 2 descriptions will be discussed, because these illustrate the powerful storage structuring facilities of DSDL which were not used in Version 1 of BANKSTORE. Assume, for purposes of illustration, that in general a bank only rarely wishes to communicate with its customers in writing. Then it is conceivable that the ‘name-and-address file’, that is the CUSTOMER-DETAILS records, are not usually online. However, there will be some customers who need frequent written reminders about the states of their overdrafts and it could be deemed inefficient to have to retrieve such a large file at frequent intervals when only the regular offenders’ names and addresses are actually required. (The fact that the name-and-address file is large can be seen from the declaration of the space occupied by the CUSTOMER-DETAILS records in Figure 2). Conditional mapping provides an answer to this problem because it allows the schema record CUSTOMER-ACCOUNT to be mapped on to either two storage records or on to one according as the NOTIFICATION field contains NO or YES. Two questions remain to be answered: