






Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
Class: Prog+Problem Solving III; Subject: Computer Engr & Computer Sci; University: California State University - Long Beach; Term: Unknown 1989;
Typology: Study notes
1 / 12
This page cannot be seen from the preview
Don't miss anything!
e) There are a number of approaches for deleting records in variable- length record files that allow for the reuse of the space occupied by these records. i) Prior lectures discussed a number of approaches to record deletion, including using a linked list that contains open slots. ii) The various approaches for deleting records that were discussed in prior lectures are viable for the data file because, unlike a sorted data file, the records in this file need not be moved around to maintain an ordering on the file. a) This is one of the advantages of an indexed file organization. b) We have rapid access to individual records by key without disturbing pinned records. c) The index itself pins all the records. f) When we delete a record from the data file, we must also delete the corresponding entry from the index file. i) Since the data file contains variable length records, a linked list showing open slots would be easy to maintain. a) A new node would be created. b) The node would be inserted into the linked list. ii) If the index is contained in an array during program execution, deleting the index record and shifting the other records to close up the space may not be an overly expensive operation. a) Alternatively, we could simply mark the index record as deleted, just as we might mark the corresponding data record. g) Updating records depends on the size of the updated record. i) If the new record is smaller or equal in size, the record can be written directly into its old space. ii) If the new record is bigger, you will need to delete the old record, then add the new record. iii) Updating also depends on whether a key field is being updated. a) If it is, you will need to delete, then add a new index.
c) Associating the Secondary Index file with a new file containing linked lists of references provides some advantages over other structures considered up to this point. i) The only time we need to rearrange the Secondary Index file is when a new composer's name is added or an existing composer's name is changed (perhaps because of a spelling error). ii) Deleting or adding recordings for a composer who is already in the index involves changing only the Label ID List file. iii) Deleting all the recordings for a composer could be handled by modifying the Label ID List file. a) Leave the entry in the Secondary Index file in place. b) Use value of –1 in its reference field to indicate that the list of entries for the composer is empty. iv) In the event that we do need to rearrange the Secondary Index file, the task is quicker now since there are fewer records and each record is smaller. v) Since there is less need for sorting, it follows that there is less of a penalty associated with keeping the Secondary Index files off on secondary storage, leaving more room in RAM for other data structures. vi) The Label ID List file is entry sequenced. That means that it never needs to be sorted. vii) Since the Label ID List file is a fixed-length record file, it would be very easy to implement a mechanism for reusing the space from deleted records, as described in earlier lectures. d) There is a potentially significant disadvantage to this kind of file organization. i) The Label IDs associated with a given composer are no longer guaranteed to be physically grouped together, i.e. with a linked, entry-sequenced structure, it is less likely that there will be locality (physical togetherness) associated with the logical groupings of reference fields for a given secondary key. ii) This lack of locality means that picking up the references for a composer that has a long list of references could involve a large amount of seeking back and forth on the disk. iii) One obvious solution to this seeking problem is to keep the Label ID List file in memory. a) This could be expensive and impractical, given many secondary indexes.