Browse Prior Art Database

Database elements in a dependecy hierarchy Disclosure Number: IPCOM000022384D
Original Publication Date: 2004-Mar-12
Included in the Prior Art Database: 2004-Mar-12
Document File: 5 page(s) / 95K

Publishing Venue



The article describes a way to score database elements in order to organize them in a hierarchy indicating which ones depends on the other. This hierarchy would be a guideline to database structure update making the user understand which elements are interested/implied by every other element update/drop.

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

Page 1 of 5

Database elements in a dependecy hierarchy

Disclosed is a technique to organize database elements in a structure guiding the user to easy understand inter-dependencies between database elements.

    A typical embodiment for the technique is database based application development: here there's the typical problem to provide procedures modifying database structure in order to bring it to the new release format without data loss . These procedures are typically composed by an ordered sequence of structures creation, altering and dropping. Developers must continuously keep track of the consequences of every step on the others database elements and work to repair unwished consequences. They could look at the elements hierarchy as from this article to quickly individuate every action consequences and decide actions order according.

The hierarchy can be built by exhaustively applying a positioning/scoring criterion on all of the possible database elements:

A database element is at a lower level and has an higher score than another

can be referred to it; is contained in it and depending on its existence; is referred/contained in another element at a lower level than the other.

    Here is an example: indexes can be referred to columns. Since columns are contained in tables and strictly depending on their existence, indexes are at lower level than tables. So tables could have score X while indexes could have score X+Y.

    Hierarchy is built step by step. Every step considers the next element and tries to compare it with all the ones in the hierarchy as from the output of the previous step. Fig.1 shows the algorithm:



Page 2 of 5

    The article develops an example of building scored hierarchy on some of the IBM DB2 elements but the technique can be applied on whatever DBMS (Data Base Management System) creating the specific DBMS hierarchy. Moreover new DB2 elements can be inserted in the final hierarchy by applying the criterion on them and the hierarchy itself.


[This page contains 1 picture or other non-text object]

Page 3 of 5

    IBM DB2 considered database elements are: tables - constraints - triggers - indexes - views - aliases - packages - types - table spaces - buffer pools.

    A brief definition on every element is needed to determine criterion comparisons results:

Tables are logical structures maintained by the database manager made up of columns and rows.

A constraint is a rule that the database manager enforces. It generally applies to one or more table column.

A trigger defines a set of actions that are executed at, or triggered by, a delete, insert, or update operation on a specified table.

An index is an ordered set of pointers to rows of a base table. Each index is based on the values of data in one or more table col...