Browse Prior Art Database

Record Architecture for a Relational Database Management System Supporting Null Values and Extensible Tables

IP.com Disclosure Number: IPCOM000036817D
Original Publication Date: 1989-Oct-01
Included in the Prior Art Database: 2005-Jan-29
Document File: 4 page(s) / 44K

Publishing Venue

IBM

Related People

Allan, BAL: AUTHOR [+4]

Abstract

Background Information In the relational data model, a database is a collection of tables (relations). Each row (tuple) of the table contains a sequence of individual data items. All data items in a particular column of the table are of the same type (e.g., integer, character, floating point, decimal). If there is no data value for a corresponding column in the row, the data item value is said to be null. Typically, each row of the table is physically represented as a record in a data set which contains the data for one or more tables. A desirable feature of relational systems is the capability of modifying the table definition by appending columns.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 44% of the total text.

Page 1 of 4

Record Architecture for a Relational Database Management System Supporting Null Values and Extensible Tables

Background Information In the relational data model, a database is a collection of tables (relations). Each row (tuple) of the table contains a sequence of individual data items. All data items in a particular column of the table are of the same type (e.g., integer, character, floating point, decimal). If there is no data value for a corresponding column in the row, the data item value is said to be null. Typically, each row of the table is physically represented as a record in a data set which contains the data for one or more tables. A desirable feature of relational systems is the capability of modifying the table definition by appending columns.

The straightforward approach used by many systems for data record layout is to store the data items in the record from left to right in column sequential order. However, this approach has deficiencies when the row contains data items which can vary in length, such as character strings. Since it is undesirable to waste storage in the record by maintaining space for the maximum length of all varying- length items, most systems reserve only enough storage for the actual length of the data items in that row. This can present a problem in locating individual data values within the record, a frequently-used capability which is required by the relational projection operator. Because of varying-length items, the entire record must be scanned to locate the item of interest. Record Architecture Solution

To avoid a time-consuming search, a different methodology can be used to store data items within a record. Let the record be divided into three contiguous portions: the header, the fixed part, and the variable part. The fixed part of the record has an entry for each data item known at the time of record creation. If a data item is not a varying-length type, (e.g., two-byte integer, fixed-length character string) the actual data is stored in that item's entry in the fixed part. Along with each item's entry in the fixed part is a null indicator field which identifies whether or not the value is null.

Each varying-length data item also has an entry in the fixed part. It consists of the length of the data, its offset into the variable part of the record, and the null indicator. All varying- length data items are stored in the variable part of the record, which follows the fixed part.

The record header is placed before the fixed part and contains the length of the fixed part.

A description of the table (e.g., the column types, number of columns, and the ordering of columns) is stored with the table for use in locating data items and constructing records. As long as the table description is not changed by appending a column, the table description and fixed-part length in each record header are consistent. Since it is not possible to change a table definition by deleting columns or changing their...