Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

A Method for Defining and Storing in a Relational Database the Attributes and Extended Attributes of All Instances of a Class of Objects

IP.com Disclosure Number: IPCOM000016588D
Original Publication Date: 2003-Jul-01
Included in the Prior Art Database: 2003-Jul-01
Document File: 2 page(s) / 192K

Publishing Venue

IBM

Abstract

Disclosed is a method for defining and storing in a relational database the attributes and extended attributes of all instances of a class of objects. This mechanism provides the capability to store the attributes of classes in separate tables according to the data types of the attributes. This eliminates the RDBMS (Relational Database Management System) size constraints on the number of columns and length of a row in a table. Storing the attributes in separate tables improves storage while maintaining reasonable performance by fetching on demand. It also provides applications the flexibility to subclass without the need to change the metadata associated with the base class.

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 56% of the total text.

Page 1 of 2

  A Method for Defining and Storing in a Relational Database the Attributes and Extended Attributes of All Instances of a Class of Objects

  Often data for instances of a class is stored in a single table so that a single query can retrieve all instances of that class. In cases in which subclasses have different data types and numbers of attributes, additional columns need to be added to the table. The number of subclasses that can be defined are limited by 1) the maximum number of columns allowed by the RDBMS (Relational Database Management System) and 2) the maximum length of a row in a relation table.

Also, since all the columns in the table may not be used by each subclass, this approach is an inefficient use of the storage space. For example, class Dog, which has an attribute of breed, and class Cat, which has an attribute of lifeCount, are both subclasses of class Animal. However, for any instance of class Dog stored as a row in the Animal table, the column lifeCount in the table would not be used. In addition, an application cannot dynamically create new subclasses without changing the definition of the existing table.

With the disclosed approach, any application can dynamically store its attributes of different data types in the database without having to change the definition of the existing tables. When an application needs to add subclasses with new attributes, the new attributes are stored in tables other than the table where the base class attributes are...