0% found this document useful (0 votes)
15 views11 pages

Organization of Files - Sequential & Multitable

Uploaded by

Jerrin Siby
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views11 pages

Organization of Files - Sequential & Multitable

Uploaded by

Jerrin Siby
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

ORGANIZATION OF RECORDS IN FILES

Module 4
ORGANIZATION OF RECORDS IN FILES

 Given a set of records of a relation, the different ways to organize the records in a
file are:
1. Heap file organization: Any record can be placed anywhere in the file where there is
space for the record. There is no ordering of records.

2. Sequential file organization: Records are stored in sequential order, according to the
value of a “search key” of each record.

3. Hashing file organization: A hash function is computed on some attribute of each


record. The result of the hash function specifies in which block of the file the record
should be placed.
SEQUENTIAL FILE ORGANIZATION

 A sequential file is designed for efficient processing of records in sorted order


based on some search key.

 A search key is any attribute or set of attributes; it need not be the primary key, or
even a super key.

 For fast retrieval of records in search-key order, records are chained together using
pointers which points to the next record in search-key order.

 To minimize the number of block accesses in sequential file processing, records are
stored physically in search-key order, or as close to search-key order as possible.
SEQUENTIAL FILE ORGANIZATION

 The sequential file organization allows records


to be read in sorted order.

 To maintain the physical sequential order,


when records are inserted and deleted, is
costly as we need to move many records as a
result of a single insertion or deletion.

In the eg, the search-key is ID


SEQUENTIAL FILE ORGANIZATION

Rules for insertion:

1. Locate the record in the file that comes before


the record to be inserted in search-key order.

2. If there is a free record (that is, space left after


a deletion) within the same block as this
record, insert the new record there. Otherwise,
insert the new record in an overflow block.

3. In either case, adjust the pointers so as to The structure allows fast insertion of new records
chain together the records in search-key order.
SEQUENTIAL FILE ORGANIZATION

 If relatively few records need to be stored in overflow blocks, this approach


works well.

 The correspondence between search-key order and physical order may be


totally lost over a period of time because of insertions/deletions. The file should
be reorganized so that it is once again physically in sequential order. Such
reorganizations are costly, and must be done during times when the system
load is low and in this case sequential processing is less efficient.
MULTITABLE CLUSTERING FILE ORGANIZATION

 Many relational database systems store the records (fixed length) of each
relation in a separate file. This simple implementation is well suited to low-cost,
small sized database; also it requires reduced amount of code to implement the
system.

 In a multitable clustering file organization, records of several different


relations are stored in the same file; further, related records of the different
relations are stored on the same block, so that one I/O operation fetches related
records from all the relations.
MULTITABLE CLUSTERING FILE ORGANIZATION
 Consider the SQL query for the university database:

select dept name, building, budget, ID, name, salary

from department natural join instructor;

 For each tuple of department, the system must locate the instructor tuples with the
same value for dept name. These records will be located with the help of indices.
 Regardless of how these records are located, they need to be transferred from disk into
main memory.

 In the worst case, each record will reside on a different block, forcing us to do one block
read for each record required by the query.
MULTITABLE CLUSTERING FILE ORGANIZATION

 The instructor tuples for each ID are stored near the department tuple for the corresponding dept name.

 When a tuple of the department relation is read, the entire block containing that tuple is copied from disk
into main memory. Since the corresponding instructor tuples are stored on the disk near the department
tuple, the block containing the department tuple contains tuples of the instructor relation needed to
process the query.

 If a department has so many instructors that the instructor records do not fit in one block, the remaining
records appear on nearby blocks.
MULTITABLE CLUSTERING FILE ORGANIZATION

 As the multitable clustering file organization stores related records of two or more relations in each
block, it allows us to read records that would satisfy the join condition by using one block read.
Thus, we are able to process this particular query more efficiently.

 This clustering of multiple tables into a single file has enhanced processing of a particular join (that
of department and instructor), but it results in slowing processing of other types of queries.
MULTITABLE CLUSTERING FILE ORGANIZATION
 For example, the query select * from department; requires more block accesses than
it did in the scheme under which we stored each relation in a separate file, since each
block now contains significantly fewer department records.

 To locate efficiently all tuples of the department relation in the multitable structure,
chain together all the records of that relation using pointers.

 Careful use of multitable clustering can produce significant performance gains in query
processing.

You might also like