Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2001-07-17
2004-09-21
Alam, Shahid (Department: 2172)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06795821
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to data processing systems, methods and computer program products, and more particularly to database systems, methods and computer program products.
BACKGROUND OF THE INVENTION
Database systems, methods and computer program products are widely used for information management. More specifically, database systems, methods and computer program products may be used to reliably manage a large amount of data in a multi-user environment, so that many users can concurrently access the same data. Database systems, methods and computer program products generally include a database that actually stores the data, a database management system and one or more applications that interface with the database management system to provide, for example, user interfaces and other applications.
One widely available database system is the Oracle8i database system that is marketed by Oracle Corporation and that is described, for example, in publications entitled
Oracle
8
i Concepts, Release
8.1.5, February 1999
, Part No. A
67781-01, 1999, and
Oracle
8
i Administrator's Guide, Release
8.1.5, February 1999
, Part A
67772-01, 1999. The disclosures of both of these publications are hereby incorporated herein by reference in their entirety. The design and operation of database systems, methods and computer program products are well known to those having skill in the art, and need not be described further herein.
At a high level, a relational database may be considered as consisting of a set of tables. Each table typically includes a set of columns (fields). Each table also typically includes a “primary key.” A primary key is a column which uniquely identifies each record in a table or a set of its columns whose combined values uniquely identify each record in that table. To speed up query searching, conventionally an index is built on the primary key of each table. An index that is based on a primary key column (or columns) is often called a primary key index, or primary index for short.
A “super key” is conventionally obtained by combining a column or columns to a primary key. An index built on a super key is typically referred to as a super key index. Because a super key contains a column or proper subset of columns whose values can be used to uniquely identify each record, the values of the super key can also be used to uniquely identify each record.
If a table includes non-primary-key columns, i.e. a column or columns that by themselves collectively cannot uniquely identify records in that table, whose values are used to identify records in other tables by matching the primary key values in the other tables, these columns are typically referred to as a foreign key. Often indices are built on the foreign key columns of a table, and these indices are referred to as foreign key indices.
A table having a foreign key may be considered a “child table” of the table or tables to which the foreign key points. A table which is pointed to by a foreign key or keys from another table may be considered a “parent table” of the other tables. The validity of a record in a child table with a foreign key or keys typically depends on the existence of records in all of its parent tables to whom foreign key values of a record point. The referential integrity constraints between parent and child tables are enforced by a database management system that typically attempts to enforce the constraint that the foreign key of each child record must point to a parent record.
In relational database design, real world entities are normally modeled by entity tables, i.e., each of these entity table models, or represents, a class of real world entities. Between two entity tables the relationship is often many-to-may, meaning that each record in each of the two entity tables can relate to more than one record in the other entity table. Typically, the maximum granularity of the number of such associations for each given record is not fixed in advance. There are many ways to represent a many-to-many relationship between two entity tables. One conventional way is to define another table, called a “relationship table,” whose primary key includes both the primary keys of the two entity tables it relates. One such example is illustrated in
FIG. 1
, where Table A and Table B are entity tables with primary keys a and b, respectively, and Table C is a relationship table. Table C has a primary key which includes the primary keys a and b of Tables A and B and has a primary index based on those primary keys. Also Table C has foreign keys a and b and, therefore, is considered a child table of both Table A and Table B such that foreign keys of each record in Table C point to a record in Table A and a record in Table B.
For very large database systems (VLDB), for the purpose of improving performance, table partitioning is often used to manage data with sizes in the range of, for example, multi-gigabytes to multi-terabytes. For example, in the service management systems deployed by service providers, very large quantities of quality of service (QOS) statistics may be continuously collected 24 hours a day, 7 days a week, 365 days a year. This very large quantity data may be stored in a VLDB, and managed by a database management system (DBMS). This data typically may be concentrated in very few data tables. To achieve higher performance for data manipulation and query operations, often these tables are partitioned into smaller sub-partitions.
Partitioning is described in the above-cited
Oracle
8
i Concepts
publication at Chapter 11, entitled
Partitioned Tables and Indexes
. Partitioning also is described in the above-cited
Oracle
8
i Administrator's Guide
at Chapter 13, entitled
Managing Partitioned Tables and Indexes
. As described therein, partitioning can address the problem of supporting very large tables and indexes by allowing the tables to be decomposed into smaller and more manageable pieces called partitions. Partitioned tables or indexes can be divided into a number of pieces, called subpartitions, which have the same logical attributes. For example, all partitions (or subpartitions) in a table share the same column and constraint definitions, and all partitions (or subpartitions) in an index share the same index option. Each partition (or subpartition) is stored in a separate segment, and can have different physical attributes. Usually, a partition scheme requires the use of some partition criteria to determine which partition (or sub-partition) of the table a record belongs. The values of some columns are usually used as partition criteria, where such columns must be included in a super key index of the table. The design and implementation of database partitioning is well known to those having skill in the art and need not be described in further detail herein.
FIG. 2
is an example of a partitioning of the tables of FIG.
1
. In order to partition Tables A, B and C, conventionally, another set of columns are added to the primary key and primary index of each of the tables to be used as partition criteria of a partition scheme. As is further seen in
FIG. 2
, these three sets of columns are illustrated as d, e and f. Following the conventional primary key and index design practice, the key and index are designed to match each other. Thus, the foreign key (a,f) of Table C should match the primary index (a,d) of Table A and the foreign key (a,f) should also match the primary index (b,e) of Table B. However, because of the value discrepancy between d in Table A and e in Table B, in general, the values of column f in Table C can only be used to as a foreign key for one or the other of entries in Table A or Table B. Thus, the column f can be used together with a as foreign key to match (a,d) in Table A or together with b as a foreign key to match (b,d) in Table B, but not both. In other words, in this case, Table C cannot be a child of both Table A and Table B at the same time. Accordingly, in order to maintain the parent-child constraints imposed by the DBMS, one of the foreign k
Alam Shahid
Ehichioya Fred
Myers Bigel Sibley & Sajovec P.A.
Trendium, Inc.
LandOfFree
Database systems, methods and computer program products... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Database systems, methods and computer program products..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Database systems, methods and computer program products... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3200942