CA2359880C - Hierarchical indexing for accessing hierarchically organized information in a relational system - Google Patents
Hierarchical indexing for accessing hierarchically organized information in a relational system Download PDFInfo
- Publication number
- CA2359880C CA2359880C CA002359880A CA2359880A CA2359880C CA 2359880 C CA2359880 C CA 2359880C CA 002359880 A CA002359880 A CA 002359880A CA 2359880 A CA2359880 A CA 2359880A CA 2359880 C CA2359880 C CA 2359880C
- Authority
- CA
- Canada
- Prior art keywords
- item
- index
- entry
- child
- array
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99932—Access augmentation or optimizing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99936—Pattern matching access
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Abstract
A method and mechanism are provided for creating. maintaining, and using a hierarchical index to efficiently access information in a relational system based on pathnames, thus emulating a hierarchically organized system. Each item that has any children in the emulated hierarchical system has an index entry in the index.
The index entries in the index are linked together in a way that reflects the hierarchical relationship between the items associated with the index entries. Pathname resolution is performed by following direct links between the index entries associated with the its in a pathname, according to the sequence of the filenames within the pathname. By using an index whose index entries are linked in this manner, the process of accessing the items based on their pathnames is significantly accelerated, and the number of disk accesses performed during that process is significantly reduced.
The index entries in the index are linked together in a way that reflects the hierarchical relationship between the items associated with the index entries. Pathname resolution is performed by following direct links between the index entries associated with the its in a pathname, according to the sequence of the filenames within the pathname. By using an index whose index entries are linked in this manner, the process of accessing the items based on their pathnames is significantly accelerated, and the number of disk accesses performed during that process is significantly reduced.
Description
WO 00/49533 PCTlUS00/03967 HIERARCHICAL INDEXING FOR ACCESSING HIERARCHICALLY
ORGANIZED INFORMATION IN A RELATIONAL SYSTEM
FIELD OF THE INVENTION
The present invention relates generally to database systems, and in particular to using a hierarchical index to access hierarchically organized information in a relational database system.
BACKGROUND OF THE INVENTION
Humans tend to organize information in categories. The categories in which information is organized are themselves typically organized relative to each other in some form of hierarchy. For example, an individual animal belongs to a species, the 1p. species belongs to a genus, the genus belongs to a family, the family belongs to an order, and the order belongs to a class.
With the advent of computer systems, techniques for storing electronic information have been developed that largely reflected this human desire for hierarchical organization. Conventional computer file systems, for example, are typically implemented using hierarchy-based organization principles. Specifically, a typical file system has directories arranged in a hierarchy, and documents stored in the directories.
Ideally, the hierarchical relationships between the directories reflect some intuitive relationship between the meanings that have been assigned to the directories.
Similarly, it is ideal for each document to be stored in a directory based on some intuitive relationship between the contents of the document and the meaning assigned to the directory in which the document is stored.
Fig. 1 shows an example of a typical file system. The illustrated file system includes numerous directories arranged in a hierarchy. Two documents 118 and 122 are stored in the directories. Specifically, documents 118 and 122, both of which are entitled "Example.doc", are respectively stored in directories 116 and 124, which are respectively entitled "Word" and "App4".
In the directory hierarchy, directory 116 is a child of directory 114 entitled "Windows", and directory 114 is a child of directory 110. Similarly, directory 124 is a -t-child of directory 126 entitled "VMS", and directory 126 is a child of directory 110.
Directory 110 is referred to as the "root" directory because it is the directory from which all other directories descend. In many systems, the symbol "/" is used to refer to the root directory.
When electronic information is organized in a hierarchy, each item of information may be located by following a "path" through the hierarchy to the entity that contains the item. Within a hierarchical file system, the path to an item begins at the root directory and proceeds down the hierarchy of directories to eventually arrive at the directory that contains the item of interest. For example, the path to file 118 consists of directories 110, 114 and 116, in that order.
Hierarchical storage systems often allow different items to have the same name.
For example, in the file system shown in Figure 1, bath of the documents 118 and 122 are entitled "Example.doc". Consequently, to unambiguously identify a given document, more than just the name of the document is required.
A convenient way to identify and locate a specific item of information stored in a hierarchical storage system is through the use of a "pathname" . A pathname is a concise way of uniquely identifying an item based on the path through the hierarchy to the item.
A pathname is composed of a sequence of names. In the context of a file system, each name in the sequence of names is a"filename". The term "filename" refers to both the names of directories and the names of documents, since both directories and documents are considered to be " files" .
Within a file system, the sequence of filenames in a given pathname begins with the name of the root directory, includes the names of all directories along the path from the root directory to the item of interest, and terminates in the name of the item of interest. Typically, the list of directories to traverse is concatenated together, with some kind of separator punctuation (e.g., 'f, 'f, or ';') to make a pathname. Thus, the pathname for document 118 is /Windows/Word/Example.doc, while the pathname for document 122 is NMS/App4/Example.doc.
The relationship between directories (files) and their contained content varies significantly between different types of hierarchically organized systems. One model, VVO 00/49533 PCTlUS00103967 employed by various implementations, such as Windo4vs and DOS file systems, requires each file to have exactly one parent, forming a tree. In a more complicated model, the hierarchy takes the form of a directed graph, where files can have multiple parents, as in the UNIX file system in which hard links are used.
In contrast to hierarchical approaches to organizing electronic information, a relational database stores information in tables comprised of rows and columns. Each row is identified by a unique RowID. Each column represents an attribute of a record, and each row represents a particular record. Data is retrieved from the database by submitting queries to a database management system (DBMS) that manages the database.
Each type of storage system has advantages and limitations. A hierarchically organized storage system is simple, intuitive, and easy to implement, and is a standard model used by most application programs. Unfortunately, the simplicity of the hierarchical organization does not provide the support required for complex data retrieval operations. For example, the contents of every directory may have to be inspected to retrieve all documents created on a particular day that have a particular filename. Since all directories must be searched, the hierarchical organization does nothing to facilitate the retrieval process.
A relational database system is well suited for storing large amounts of information and for accessing data in a very flexible manner. Relative to hierarchically organized systems, data that matches even complex search criteria may be easily and efficiently retrieved from a relational database system. However, the process of formulating and submitting queries to a database server is less intuitive than merely traversing a hierarchy of directories, and is beyond the technical comfort level of many computer users.
In the past, hierarchically organized systems and relationally organized systems have been implemented in different ways that were not compatible. With some additional processing, however, a relationally organized system can emulate a hierarchically organized system. This type of emulation is especially desirable when the _3_ storage capability and flexibility of a relational system is ncedcd, but the intuitiveness and ubiquity of the hierarchical system is desired.
Such emulation may be implemented through the use of two relational tables: a "File" table and a "Directory links" table. The File table stores information relating to each file in the emulated hierarchical system. For files that are documents, the File table further stores either the body of the file (in the form of a large binary object (BLOB)), or a pointer to the body of the document. The Directory links table stores all of the link information that indicates the parent-child relationships between files.
To illustrate how these two tables may be used to emulate a hierarchical storage system, suppose that a file system having the hierarchical stntcture of Fig. I
is implemented in a database. The file system of Fig. I can be illustrated as follows (a unique ID, shown in parentheses, is assigned by the system to uniquely identify each file):
-/ (X1) -Windows (X2) -Word (X3) -Example.doc (X4) -Access (XS) -Unix (X6) -Appl (X7) -App2 (X8) -VMS (X9) -App3 (X10) -App4 (X 11 ) -Example.doc (X12) Fig. 2 shows a files table 210, and Fig. 3 shows a directory links table 310, which may be used by a computer system to emulate the file system of Fig. I in a relational database system. Files table 210 contains an entry for each file in the system. Each entry WO 00149533 PCT/US00l03967 includes a RowID, a Tile ID, a name, a body column, and a modification date column (plus other system-maintained information such as creation date, access permission information, etc.).
The FiIeID is a unique ID assigned to each file by the system, the name is the name assigned to the file, which does not need to be unique, and the body is the field in which the contents of a file are stored. The body held may store the actual contents of a file in the form of a binary large object (BLOB), or a pointer to the contents of the file.
Where the entry is for a file having no content (e.g. a directory), the body field is null. In the above example, only the two documents entitled Example.doc have content;
thus, the body field for all of the other entries is null.
In directory links table 310, an entry is stored for each link betveen files in the file system of Fig. 1. Each entry includes a parent ID, a child ID, and a child name field.
For each link, the parent ID field specifies the file which is the parent file for the link, the child ID field specifies the file which is the child file for the link, and the child name field specifies the name of the child file in the link. Thus, for example, in the entry for the link between root directory 110 and Windows directory 114, directory links table 310 specifies that X1 (the FiIeID of the root directory) is the Parent ID, X2 (the FiIeID of the Windows directory) is the child ID, and "Windows" is the child name.
To illustrate how the information in these two tables may be used to implement the file system of Fig. 1, suppose that it is necessary to access document 118. As explained above, document 118 has the path: /Windows/Word/Example.doc. To access this file, the DBMS makes an initial scan of directory links table 310 to find the entry where root directory 110 is the parent file and Windows directory 114 is the child file.
To do this, the DBMS executes something like the following SQL statement:
Select ChildID
from directory-links Where ParentID="X1"
child name="Window".
ORGANIZED INFORMATION IN A RELATIONAL SYSTEM
FIELD OF THE INVENTION
The present invention relates generally to database systems, and in particular to using a hierarchical index to access hierarchically organized information in a relational database system.
BACKGROUND OF THE INVENTION
Humans tend to organize information in categories. The categories in which information is organized are themselves typically organized relative to each other in some form of hierarchy. For example, an individual animal belongs to a species, the 1p. species belongs to a genus, the genus belongs to a family, the family belongs to an order, and the order belongs to a class.
With the advent of computer systems, techniques for storing electronic information have been developed that largely reflected this human desire for hierarchical organization. Conventional computer file systems, for example, are typically implemented using hierarchy-based organization principles. Specifically, a typical file system has directories arranged in a hierarchy, and documents stored in the directories.
Ideally, the hierarchical relationships between the directories reflect some intuitive relationship between the meanings that have been assigned to the directories.
Similarly, it is ideal for each document to be stored in a directory based on some intuitive relationship between the contents of the document and the meaning assigned to the directory in which the document is stored.
Fig. 1 shows an example of a typical file system. The illustrated file system includes numerous directories arranged in a hierarchy. Two documents 118 and 122 are stored in the directories. Specifically, documents 118 and 122, both of which are entitled "Example.doc", are respectively stored in directories 116 and 124, which are respectively entitled "Word" and "App4".
In the directory hierarchy, directory 116 is a child of directory 114 entitled "Windows", and directory 114 is a child of directory 110. Similarly, directory 124 is a -t-child of directory 126 entitled "VMS", and directory 126 is a child of directory 110.
Directory 110 is referred to as the "root" directory because it is the directory from which all other directories descend. In many systems, the symbol "/" is used to refer to the root directory.
When electronic information is organized in a hierarchy, each item of information may be located by following a "path" through the hierarchy to the entity that contains the item. Within a hierarchical file system, the path to an item begins at the root directory and proceeds down the hierarchy of directories to eventually arrive at the directory that contains the item of interest. For example, the path to file 118 consists of directories 110, 114 and 116, in that order.
Hierarchical storage systems often allow different items to have the same name.
For example, in the file system shown in Figure 1, bath of the documents 118 and 122 are entitled "Example.doc". Consequently, to unambiguously identify a given document, more than just the name of the document is required.
A convenient way to identify and locate a specific item of information stored in a hierarchical storage system is through the use of a "pathname" . A pathname is a concise way of uniquely identifying an item based on the path through the hierarchy to the item.
A pathname is composed of a sequence of names. In the context of a file system, each name in the sequence of names is a"filename". The term "filename" refers to both the names of directories and the names of documents, since both directories and documents are considered to be " files" .
Within a file system, the sequence of filenames in a given pathname begins with the name of the root directory, includes the names of all directories along the path from the root directory to the item of interest, and terminates in the name of the item of interest. Typically, the list of directories to traverse is concatenated together, with some kind of separator punctuation (e.g., 'f, 'f, or ';') to make a pathname. Thus, the pathname for document 118 is /Windows/Word/Example.doc, while the pathname for document 122 is NMS/App4/Example.doc.
The relationship between directories (files) and their contained content varies significantly between different types of hierarchically organized systems. One model, VVO 00/49533 PCTlUS00103967 employed by various implementations, such as Windo4vs and DOS file systems, requires each file to have exactly one parent, forming a tree. In a more complicated model, the hierarchy takes the form of a directed graph, where files can have multiple parents, as in the UNIX file system in which hard links are used.
In contrast to hierarchical approaches to organizing electronic information, a relational database stores information in tables comprised of rows and columns. Each row is identified by a unique RowID. Each column represents an attribute of a record, and each row represents a particular record. Data is retrieved from the database by submitting queries to a database management system (DBMS) that manages the database.
Each type of storage system has advantages and limitations. A hierarchically organized storage system is simple, intuitive, and easy to implement, and is a standard model used by most application programs. Unfortunately, the simplicity of the hierarchical organization does not provide the support required for complex data retrieval operations. For example, the contents of every directory may have to be inspected to retrieve all documents created on a particular day that have a particular filename. Since all directories must be searched, the hierarchical organization does nothing to facilitate the retrieval process.
A relational database system is well suited for storing large amounts of information and for accessing data in a very flexible manner. Relative to hierarchically organized systems, data that matches even complex search criteria may be easily and efficiently retrieved from a relational database system. However, the process of formulating and submitting queries to a database server is less intuitive than merely traversing a hierarchy of directories, and is beyond the technical comfort level of many computer users.
In the past, hierarchically organized systems and relationally organized systems have been implemented in different ways that were not compatible. With some additional processing, however, a relationally organized system can emulate a hierarchically organized system. This type of emulation is especially desirable when the _3_ storage capability and flexibility of a relational system is ncedcd, but the intuitiveness and ubiquity of the hierarchical system is desired.
Such emulation may be implemented through the use of two relational tables: a "File" table and a "Directory links" table. The File table stores information relating to each file in the emulated hierarchical system. For files that are documents, the File table further stores either the body of the file (in the form of a large binary object (BLOB)), or a pointer to the body of the document. The Directory links table stores all of the link information that indicates the parent-child relationships between files.
To illustrate how these two tables may be used to emulate a hierarchical storage system, suppose that a file system having the hierarchical stntcture of Fig. I
is implemented in a database. The file system of Fig. I can be illustrated as follows (a unique ID, shown in parentheses, is assigned by the system to uniquely identify each file):
-/ (X1) -Windows (X2) -Word (X3) -Example.doc (X4) -Access (XS) -Unix (X6) -Appl (X7) -App2 (X8) -VMS (X9) -App3 (X10) -App4 (X 11 ) -Example.doc (X12) Fig. 2 shows a files table 210, and Fig. 3 shows a directory links table 310, which may be used by a computer system to emulate the file system of Fig. I in a relational database system. Files table 210 contains an entry for each file in the system. Each entry WO 00149533 PCT/US00l03967 includes a RowID, a Tile ID, a name, a body column, and a modification date column (plus other system-maintained information such as creation date, access permission information, etc.).
The FiIeID is a unique ID assigned to each file by the system, the name is the name assigned to the file, which does not need to be unique, and the body is the field in which the contents of a file are stored. The body held may store the actual contents of a file in the form of a binary large object (BLOB), or a pointer to the contents of the file.
Where the entry is for a file having no content (e.g. a directory), the body field is null. In the above example, only the two documents entitled Example.doc have content;
thus, the body field for all of the other entries is null.
In directory links table 310, an entry is stored for each link betveen files in the file system of Fig. 1. Each entry includes a parent ID, a child ID, and a child name field.
For each link, the parent ID field specifies the file which is the parent file for the link, the child ID field specifies the file which is the child file for the link, and the child name field specifies the name of the child file in the link. Thus, for example, in the entry for the link between root directory 110 and Windows directory 114, directory links table 310 specifies that X1 (the FiIeID of the root directory) is the Parent ID, X2 (the FiIeID of the Windows directory) is the child ID, and "Windows" is the child name.
To illustrate how the information in these two tables may be used to implement the file system of Fig. 1, suppose that it is necessary to access document 118. As explained above, document 118 has the path: /Windows/Word/Example.doc. To access this file, the DBMS makes an initial scan of directory links table 310 to find the entry where root directory 110 is the parent file and Windows directory 114 is the child file.
To do this, the DBMS executes something like the following SQL statement:
Select ChildID
from directory-links Where ParentID="X1"
child name="Window".
This query returns the ID of the child tile, which in this case is X2 (for Windows directory 114). After obtaining the ID <>f the child file., the DBMS
makes a second scan of the directory links table 310. this time looking for the entry where the parent file is Windows directory I 14, and the child tile is Word directory 116. This is achieved by executing the following Select statement:
Select ChildID
from directory_l ink s Where ParentID="X2" and Child name="Word".
This query returns the ID of Word directory I I 6, which in this example is X3.
With this information, the DBMS makes a third scan of directory links table 310, this time searching for the entry where the parent tile is Word directory 116 and the child file is Example.doc document 118. This is achieved with the following Select statement:
Select ChildID
from directory links Where ParentlD="X3" <~nd Child name="Exarnple.doc"
At the end of this process, the IL) of document 118 will have been determined.
Using this ID as the primary key, the proper entry in files table 210 is located, and the contents of document 118 are accessed from the body field. Thus, using this technique, files that are actually stored in a relational structure;, such as table 210, may be located and accessed using hathnames just as if they were stored in a hierarchically organized structure. 'The user submitting the pathname to locate a file need not understand the complexity of a relational system. Conversely, because the files are stored in a relational system, the files may be elticiemtly accessed in more sophisticated ways by users that are familiar with relational systems.
f>
WO 00!49533 PCTlUS00/03967 The process outlined above is the process of pathname resolution, wherein the pathname of the file is resolved into the location on disk where the file data is stored.
The method described is effective for implementing a file system using a relational database, and is the method appropriate for relational theory. Unfortunately, however, the process requires the execution of multiple queries, and hence, multiple scans of directory links table 310. Specifically, it takes an "i" number of scans to resolve the path of a file, where i is the number of levels in the path (each intermediate directory adds a level). This can be a performance problem.
For purposes of simplifying the performance evaluation, assume that the performance of the pathname resolution is directly proportional to the number of disk blocks that must be accessed. (This is because disk access is an order of 100 slower than memory access, and for large file systems, we can assume that most of the data will be on disk.) Assuming that a conventional BTREE'tndex has been built on the directory links table 310, the number of disk block accesses that a DBMS has to perform I S in one scan of a table is log(n)/m where n is the number of entries in the table and m is the munber of entries per block. Thus, using the pathname resolution technique described above, the average number of accesses that the DBMS will have to perform to access a file is i*log(n)/m.
For complex file systems having a large number of links and a large number of link levels, the number of disk accesses can become quite large. Since I/O
operations are very slow relative to other types of operations, having a large number of disk accesses can significantly degrade system performance. In general, the pathname resolution method described is quite slow when applied to large, complex file systems.
While the data structure of the table is appropriate for easy access to the file system data from relational applications, the standard types of indexes used by databases are too slow for efficient pathname-based access to data organized in this manner. What is needed, then, is an apparatus, system or method that emulates a hierarchically organized system using a relationally organized system, but which reduces the number of disk accesses necessary to locate the items in the system when they are accessed based on their pathnames.
_7_ SUMMARY OF TI-IE INVENTION
A method and mechanism are provided for creating, maintaining, and using a hierarchical index to efficiently access information in a relational system based on a pathnames, thus emulating a hierarchically organized system.
According to one aspect of the invention, each item that has any children in the emulated hierarchical system has an index entry in the index. The index entries in the index are linked together in a way that reflects the hierarchical relationship between the items associated with the index entries. Specifically, if a parent-child relationship exists between the items associated with two index entries, then the index entry associated with the parent item has a direct link to the index enhy associated with the child item.
According to another aspect of the invention, pathname resolution is perforn~ed by following direct links between the index entries associated with the items in a pathname, according to the sequence of the filenames within the pathname. By using an index whose index entries are linked in this manner, the process of accessing the items based on their pathnames is significantly accelerated, and the number of disk accesses performed during that process is significantly reduced.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
Fig. 1 is a block diagram illustrating a hierarchically organized file system;
Fig. 2 shows a files table 210 that may be used to emulate a hierarchically organized system in a relationally organized system;
Fig. 3 shows a directory links table 310 that may be used in conjunction with files table 210 of Fig. 2 to emulate a hierarchically organized system;
Fig. 4 is a block diagram illustrating a database system that may be used to implement a hierarchical index in accordance with one embodiment of the invention;
_g_ R'O 00/49533 PCT/US00103967 Fig. 5 shows a hierarchical index that may be used to enhance performance of an emulated hierarchical system within a relational system;
fig. GA is a flowchart illustrating how hierarchical index 510 is maintained during the creation of an item;
Fig. 6B is a flowchart illustrating how hierarchical index 510 is maintained during the deletion of an item;
Fig. 7 is a flowchart showing the process for resolving a pathname using hierarchical index S 10 in accordance with an embodiment of the invention;
Fig. $ is a block diagram illustrating an example of a hardware system that may be used to implement the apparatus, systems and methods consistent with the invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
A method and apparatus for providing efficient pathname-based access to data stored in a relational system is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
FUNCTIONAL OVERVIEW
Techniques are described herein for creating, maintaining, and using a hierarchical index to efficiently access infornation in a relational system based on a pathnames, thus emulating a hierarchically organized system. Each item that has any children in the emulated hierarchical system has an index entry in the index.
The index entries in the index are linked together in a way that reflects the hierarchical relationship between the items associated with the index entries. Specifically, if a parent-child relationship exists between the items associated with two index entries, then the index entry associated with the parent item has a direct link to the index entry associated with the child item.
1~1'O 00/49533 PCTlUS00/03967 Consequently, pathname resolution is perforn~ed by following direct lima between the index entries associated with the items in a pathname, according to the sequence of the filenames within the pathname. By using an index whose index entries are linked in this manner, the process of accessing the items based on their pathnames is significantly accelerated, and the number of disk accesses performed during that process is significantly reduced.
DATABASE ARCHITECTURE
Fig. 4 is a block diagram showing a database architecture that may be used to create, use, and maintain a hierarchical index consistent with the principles of the present invention. The architecture comprises a user interface 410, a DBMS 412, and a database 414. DBMS 412 interacts with the user via user interface 410, and accesses and maintains database 414 in accordance with the user input. DBMS 412 may also interact with other systems (not shown).
DBMS 412 creates, uses, and maintains a hierarchical index in database 414 in accordance with the principles of the present invention. Hierarchical index creation, use and maintenance will be described hereafter in greater detail.
1n general, DBMS 412 creates a database by organizing information in one or more tables. The organization of the table is referred to as a definition. An index is a structure that is used for accessing particular information in the table more quickly.
Therefore, a table definition supports any access mechanism to the data (search by name, by ID, by date, etc.), whereas an index is designed for a specific access method. The index itself is generally not the authoritative source of the data, but rather contains pointers to the disk addresses of the tables storing the authoritative data.
HIERARCHICAL INDEX
Hierarchical indexes consistent with the invention support the pathname-based access method of a hierarchical system, moving from parent items to their children, as specified by the pathname. According to one embodiment, a hierarchical index consistent with the principles of the invention employs index entries that include the following three fields: RowID, File ID, and Dir-entry list (stored as an array).
Fig. 5 shows a hierarchical index 510 consistent with the invention, which may be used to emulate a hierarchical storage system in a database. Hierarchical index 510 is a table. The RowID column contains system generated Ids, specifying a disk address that enables DBMS 412 to locate the row on the disk. Depending on the relational database system, RowID may be an implicitly defined field that the DBMS uses for locating data stored on the disk drive. The FiIeID field of an index entry stores the FiIeID
of the file that is associated with the index entry.
According to one embodiment of the invention, hierarchical index S 10 only stores index entries for items that have children. In the context of an emulated hierarchical file system, therefore, the items that have index entries in the hierarchical index 510 are only those directories that are parents to other directories and/or that are currently storing documents. Those items that do not have children (Example.doc, Access, Appl, App2, App3) are preferably not included. The Dir entry list field of the index entry for a given file stores, in an array, an "array entry" for each of the child files of the given file.
For example, index entry 512 is for the Windows directory 114. The Word directory 116 and the Access directory 120 are children of the Windows directory 114.
Hence, the Dir entry_list field of index entry 512 for the Windows directory includes an array entry for the Word directory 116 and an array entry for the Access directory 120.
According to one embodiment, the specific information that the Dir entry_list field stores for each child includes the filename of the child and the FiIeID
of the child.
For children that have their own entries in the hierarchical index 510, the Dir entry list field also stores the RowID of the child's index entry. For example, the Word directory 116 has its own entry in hierarchical index 510 (entry 514). Hence, the Dir entry-list field of index entry S 12 includes the name of directory I 1 G (" Word" ), the RowID of the index entry for directory 116 in hierarchical index 510 (" Y3" ), and the FiIeID of directory 116 (" X3" ). As shall be described in greater detail, the information contained in the Dir entry-list field makes accessing information based on pathnames much faster and easier.
Several key principles of the hierarchical index arc as follows:
~ The Dir entry_list information in the index entry for a given directory is kept together in as few disk blocks as possible, since the most Ire~quently used filesystem operations (pathname resolution, directory listing) m.~ill need to look at many of the entries in a particular directory whenever that directory is referenced. In other words, directory entries should have a high locality of reference because when a particular directory entry is referenced, it is likely that other entries in the same directory will also be referenced.
~ The information stored in the index entries of the hierarchical index must be kept to a minimum, so as to fit the maximum number of entries in a particular disk block. Grouping directory entries together in an array means that there is no need to replicate a key identifying the directory they arc in; all of the entries in a directory share the same key. This is in contrast to the typical relational table model shown in the directory links table (table 310).
~ 'The time needed to resolve a pathname should be proportional to the number of directories in the path, not the total number of files in the filesystem. This allows the user to keep frequently-accessed files toward the top of the filesystem tree, where access time is lower.
These elements are all present in typical file system directory structures, such as the UNIX system of modes and directories. The use of a hierarchical index, as described herein, reconciles those goals with the structures that a relational database understands and can query, to allow the database server to do ad-hoc searches of files in a manner other than that used in pathname resolution. To do this, the database concept of an index must be used: a duplicate of parts of the underlying information (in this case, the file data) arranged in a separate data structure in a different manner designed to optimize access via a particular method {in this case, resolution of a pathname in a hierarchical tree).
USING THE HIERARCHICAL INDEX
How hierarchical index 510 may be used to access a file based on the pathname of the file shall now be described with reference to the flowchart in Fig. 7.
It shall be assumed for the purpose of explanation that document 118 is to be accessed through its pathnacne. The pathname for this file is ; Windows/Word/Example.doc, which shall be referred to'hereafter as the "input pathnamc" . Given this pathname, the pathname resolution process starts by locating within hierarchical index 510 the index entry for the first name in the input pathname. In the case of a file system, the first name in a pathname is the root directory. Therefore, the pathname resolution process for locating a file within an emulated file system begins by locating the index entry 508 of the root directory 110 (step 700). Because all pathname resolution operations begin by accessing the root directory's index entry 508, data that indicates the location of the index entry for the root directory 110 (index entry 508) may be maintained at a convenient location outside of the hierarchical index 510 in order to quickly locate the index entry 508 of the root directory at the start of every search.
Once the index entry 508 for the root directory 110 has been located, the DBMS
determines whether there are any more filenames in the input pathname (step 702). If there are no more filenames in the input pathname, then control proceeds to step 720 and the FiIeID stored in index entry 508 is used to look up the root directory entry in the files table 210.
In the present example, the filename " Windows" follows the root directory symbol "/" in the input pathname. Therefore, control proceeds to step 704. At step 704, the next filename (e.g. " Windows" ) is selected from the input pathname. At step 706, _13_ the DBMS looks in the Dir entry-list column of the index entry 508 to locate an array entry pertaining to the selected filename.
In the present example, the filename that follows the root directory in the input pathname is " Windows" . Therefore, step 706 involves searching the Dir entry list of index entry 508 for an array entry for the filename " Windows" . If the Dir-entry- list does not contain an array entry for the selected filename, then control would proceed from step 708 to step 710, where an error is generated to indicate that the input pathnamc is not valid. In the present example, the Dir entry list of index entry 508 does include an array entry for " Windows" . Therefore, control passes from step 708 to step 722.
The information in the Dir entry list of index entry 508 indicates that one of the children ofthe root directory 110 is indeed a file named "Windows". Further, the Dir entry list array entry contains the following information about this child: it has an index entry located at RowID Y2, and its FiIeID is X2.
At step 722, it is determined whether there are any more filenames in the input pathname. If there are no more filenames, then control passes from step 722 to step 720.
In the present example, "Windows" is not the last filename, so control passes instead to step 724.
Because " Windows" is not the last filename in the input path, the FiIeID
information contained in the Dir entry list is not used during this path resolution operation. Rather, because Windows directory 114 is just part of the specified path and not the target, files table 210 is not consulted at this point. Instead, at step 724 the RowID (Y2) for "Windows", which is found in the Dir entry_list of index entry 508, is used to locate the index entry for the Windows directory 114 (index entry 512).
Consulting the Dir entry list of index entry 512, the system searches for the next filename in the input pathname (steps 704 and 706). In the present example, the filename " Word" follows the filename " Windows" in the input pathname. Therefore, the system searches the Dir_ entry list of index entry 512 for an array entry for "Word".
Such an entry exists in the Dir entry list of index entry 512, indicating that "Windows" actually does have a child named "Word" (step 708). At step 722, it is determined that there are more filenames in the input path, so control proceeds to step 724.
Upon finding the array entry for "Word", the system reads the information in the array entry to determine that an index entry for the Word directory 116 can be found in hierarchical index 510 at RowID Y3, and that specific information pertaining to Word directory 116 can be- found in tiles table 210 at row X3.
Since Word directory 116 is just part of the specified path and nc>t the target, files table 210 is not consulted. Instead, the system uses the RowID I;Y3) to locate the index entry 514 for Word directory l 16 (step 724).
At RowID Y3 of hierarchical index 510, the system finds index entry 514. At step 704, the next filename "Example.doc" is selected from the input pathname.
At step 706, the Dir entry-list of index entry 514 is searched to find (step 708) that there is an array entry for "Example.doc", indicating that "Example.doc" is a child of Word directory 116. The system also finds that Example.doc has no indexing information in hierarchical index 510, and that specific information pertaining to Example.doc can be found in tiles table 21 () using the FilelD X4. Since Example.doc is the target file to be accessed (i.e. the last filename in the input path), control passes to step 720 where the system uses the FiIeID X4 to access the appropriate row in the files table 210, and to extract the tile body (the BL<)I3) stared in the body column of that row. Thus, the Example.doc tile is accessed.
In accessing this file, only hierarchical index 510 was used. No table scans were necessary. With typical sizes of blocks and typical filename lengths, at least 100 directory entries will tit in a disk black, and a typical directory has less than 100 entries. This means that the list of directory entries in a given directory will typically fit in a single block. In other words, any single index entry of hierarchical index 510, including the entire Dir entry list array of the index entry, will typically fit entirely in a single block, and therefore can be read in a single 1/O operation.
In moving from index entry to index entry in the hierarchical index 510, it is possible that some disk accesses will need to be performed if the various index entries in the index reside in dih ferent disk blocks. If each index entry entirely fits in a single block, then the number of disk accesses, however, will at most be i. In other words, one disk access is used for each directory in the path. Evan if the size of an average index entry does not m WO 00!49533 PCT/t)S04/03967 fit in a single disk block, but requires 2 or ~i blocks, this will be a constant term, and will not increase with the total number of files in the file system. Unlike the prior methodology, the number of disk I/Os will not be i*log(n)im. Thus, file access using the present invention will be much faster.
CREATION OF HIERARCHICAL INDEX
As explained above, a filename is the name used to reference any file stored in a directory, and is a component of the pathname. For example, in the patl-mame "/Windows/WordlExample.doc", "Windows" is the filename of a directory, " Word"
is the filename of a directory within " Windows", and "Example.doc" is the filename of a document stored in the "Word" directory. Note that a separator character divides the filenames within a pathname. 'The separator character may differ in individual file system implementations. Microsoft file systems, for example, have generally used a backslash ("\") character, UNIX file systems use a forward slash, and Apple Macintosh 61e systems use a colon (":") to separate filenames.
According to one embodiment, the FileID is the primary key in the files table 210, where the actual file data is stored. However, any primary key that references the data stored for each file could be used in the hierarchical index in place of the FiIeID.
The FiIeID in this case is what is usually referred to as a "foreign key" in the hierarchical index 510.
Initially there are no files in the file system other than the root directory (n.
Therefore, the hierarchical index is created by inserting one row into the index 510 (Fig.
5) for the root directory. Because there are no files in the root directory at this point, the Dir entry list field of the root directory's index entry should be left empty.
The user of the hierarchical index should keep the RowlD of the root entry in a separate location (for example, in dynamic memory or in a separate table in the database with only one entry).
The root entry is the staring point for every use of the hierarchical index 510, so it is important to have the location of that entry readily available. As new files are added to the file system, the hierarchical index S l 0 is updated as described in the section below entitled "Maintenance of Hierarchical Index."
If the hierarchical index 510 is to be created alter the file system has been populated, it may be created by traversing the entire file system and adding hierarchical index entries for each file present in the file system in the same manner as if the file had just been added to the system, according to the method described in "Maintenance of Hierarchical Index."
MAIN~fENANCE OF HIERAIZCH1CAL INDEX
The maintenance of one embodiment of a hierarchical index shall now be described with reference to Figs. 6A and 6B. Referring to Fig. 6A, it is a flowchart illustrating steps performed in response to a file being created in a file system that is being emulated in a relational system that uses a hierarchical index. At step 600, the new file is created. At step 602, it is determined whether the new file is the first child of the file that has been designated as its parent. For example, assume that a document Docl.doc is being created in the Appl directory. Currently, Appl does not have any children, so Docl.doc would be its first child and control would pass to step 604.
At step 604, an index entry is created for the parent. In the present example, an index entry would be created for " App 1 " . At step 610, the array entry for the parent, which resides in the index entry for the parent's parent, is updated to include a link to the newly created index entry. In the present example, the array entry 518 for "Appl" that resides in the index entry 516 for "Unix" is updated to include the RowID, within hierarchical index 510, of the newly created index entry for "Appl" . At step 606, an array entry for the new file Docl.doc is inserted into the Dir entry_list of the newly created index entry for " App 1" .
if the file being created is not the first child of the designated parent, then control passes to step 608. At step 608, the index entry for the designated parent is located, and at step 606 an array entry for the new file is inserted into the Dir_ entry list of the parent's index entry.
Figure 6B is a flowchart illustrating the steps for updating a hierarchical index in response to a file being deleted. At step 650, the file is deleted. At step 652, it is determined whether the file was the only child of a parent. If the deleted file was the only child of a parent, then the index entry for the parent is removed from the index (step 6~4) and the array envy for the parent that resides in the index entry of the parent's parent is updated (step 660) to reflect that the parent no longer has an index entry in the index. If the child was not the only index entry for the parent, then the array entry for the deleted file is removed from the Dir entry-list of the parent.
Whether or not the deleted file was the only child of its parent, any index entry for the deleted file and index entries for the deleted file's descendants are also deleted (Step 658).
When files are moved from one location in the hierarchy to another, the hierarchical index is updated by removing the array entry for the file from the Dir entry list of its old parent, and adding an array entry for the item to the Dir entry list of its new parent.
SEARCHING THE DIR ENTRY LIST ARRAY
As explained above, one step of the pathname resolution process involves searching through the Dir entry list array for an array entry of a particular child (Fig. 7, step 706). According to one embodiment, this search process is facilitated by storing the array entries in each Dir entry list array in alphabetical order. By storing the array entries in order, more efficient searching techniques, such as a binary search, may be used to find the entry for a given child. However, maintaining the array entries in sorted order incurs additional maintenance overhead. Consequently, in one embodiment, only arrays that have more than a threshold number of array entries are ordered.
VARIATIONS
Specific embodiments have been used to illustrate the use of a hierarchical index to access hierarchical data in a relational system. However, the present invention is not limited to the embodiments described. For example, hierarchical index 510 only includes index entries for those items that have at least one child. However, a hierarchical index may optionally include index entries for all items, whether or not they have children.
As illustrated, the Dir entry list array entries of an index entry in hierarchical index 510 include the FiIeID, which may be used to locate the child in the files table. However, the actual fields stored in each Dir entry___list array entry may vary from implementation to implementation. For example, the Dir entry_ list may additionally or alternatively include the RowID of the corresponding row in the files table, or any other unique, non-null key that can be used to locate the corresponding entry in the tiles table.
According to one embodimealt, the Fi'IeID is generated sequentially, in contrast to rowids that are typically based on disk block addresses. The FiIeID values are useful in importing/exporting the directories in and out of the database (e;.g. for backup/restore l0 purposes), since the RowIDs used by the exporting database may be different than the RowIDs used for the same rows by the importing database. if the importing database finds a different place on disk to load the directory.
According to one embodiment, the hierarchical index does not have a separate FiIeID
column, as shown in Figure 5. Instead, the FiIeID of the target item is extracted from the array entry for the target item, which is located in the Dir_ entry_ list of the parent of the target item. The FiIeID of the root directory, which has no parent, may be stored separate from the hierarchical index.
In addition, the Dir entry list entries may be used to "cache" useful information about the items to which they correspond. Such additional information may include, for example, information about the security privileges associated with the item.
In some cases, the additional information stored in the array entry for an item may include all of the information required to satisfy a query that references the item, thus completely avoiding the need tc> access the item's files table information. However, the desire to cache useful information in the Dir entry_list must be weighed against the need to limit the size of the Dir entry list to reduce the number of I/Os required to read each index entry.
Embodiments of the invention have been described in the context of a file system.
However, the techniques described herein are applicable tc> the storage, within a relationally organized system, of any hierarchically organized information. For example, a relational system may be used to store records about animals, where the animal records are to be accessed based on a hierarchical "path" consisting of the class, order, family and species to which the animals belong.
HARDWARE OVERVIEW
Figure 8 is a block diagram that illustrates a computer system 800 upon which an embodiment of the invention may be implemented. Computer system 800 includes a bus 802 or other communication mechanism for communicating information, and a processor 804 coupled with bus 802 for processing information. Computer system 800 also includes a main memory 806, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 802 for storing information and instmetions to be executed by processor 804. Main memory 806 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 804. Computer system 800 further includes a read only memory {ROM) 808 or other static storage device coupled to bus 802 for storing static information and instructions for processor 804. A storage device 810, such as a magnetic disk or optical disk, is provided and coupled to bus 802 for storing information and mstruerions.
Computer system 800 may be coupled via bus 802 to a display 812, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 814, including alphanumeric and other keys, is coupled to bus 802 for communicating information and command selections to processor 804. Another type of user input device is cursor control 816, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 804 and for controlling cursor movement on display 812. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
The invention is related to the use of computer system 800 for accessing hierarchically organized information stored in a relational system. According to one embodiment of the invention, computer system 800 creates, maintains and uses a hierarchical index in response to processor 804 executing one or more sequences of one or more instructions contained in main memory 806. Such instructions may be read into main memory 80G from another computer-readable medium, such as storage device 810.
Execution of the scqucnccs of instructions contained in main memory 80G causes processor 804 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The term "computer-readable medium" as used herein refers to any medium that participates in providing instructions to processor 804 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 810. Volatile media includes dynamic memory, such as main memory 80G. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 802. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.
Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASI-I-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 804 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 800 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 802. Bus 802 carries the data to main memory 80G, from which processor 804 retrieves and executes the WO 00149533 PCT/US00l03967 instructions. The instructions received by main memory 806 may optionally be stored on storage device 810 either before or after execution by processor 804.
Computer system 800 also includes a communication interface 818 coupled to bus 802. Communication interface 818 provides a two-way data communication coupling to a network link 820 that is connected to a local network $22. For example, communication interface 818 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 818 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 818 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link 820 typically provides data communication through one or more networks to other data devices. For example, network link $20 may provide a connection through local network 822 to a host computer 824 or to data equipment operated by an Internet Service Provider (ISP) 826. ISP 826 in tum provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 828. Local network 822 and Internet both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 820 and through communication interface 818, which carry the digital data to and from computer system 800, are exemplary forms of carrier waves transporting the information.
Computer system 800 can send messages and receive data, including program code, through the network(s), network link 820 and communication interface 818. In the Internet example, a server 830 might transmit a requested code for an application program through Internet 828, ISP 826, local network 822 and communication interface 818.
The received code may be executed by processor 804 as it is received, andlor stored in storage device 810, or other non-volatile storage for later execution. In this manner, computer system 800 may obtain application code in the form of a carrier wave.
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to Lie regarded in an illustrative rather than a restrictive sense.
makes a second scan of the directory links table 310. this time looking for the entry where the parent file is Windows directory I 14, and the child tile is Word directory 116. This is achieved by executing the following Select statement:
Select ChildID
from directory_l ink s Where ParentID="X2" and Child name="Word".
This query returns the ID of Word directory I I 6, which in this example is X3.
With this information, the DBMS makes a third scan of directory links table 310, this time searching for the entry where the parent tile is Word directory 116 and the child file is Example.doc document 118. This is achieved with the following Select statement:
Select ChildID
from directory links Where ParentlD="X3" <~nd Child name="Exarnple.doc"
At the end of this process, the IL) of document 118 will have been determined.
Using this ID as the primary key, the proper entry in files table 210 is located, and the contents of document 118 are accessed from the body field. Thus, using this technique, files that are actually stored in a relational structure;, such as table 210, may be located and accessed using hathnames just as if they were stored in a hierarchically organized structure. 'The user submitting the pathname to locate a file need not understand the complexity of a relational system. Conversely, because the files are stored in a relational system, the files may be elticiemtly accessed in more sophisticated ways by users that are familiar with relational systems.
f>
WO 00!49533 PCTlUS00/03967 The process outlined above is the process of pathname resolution, wherein the pathname of the file is resolved into the location on disk where the file data is stored.
The method described is effective for implementing a file system using a relational database, and is the method appropriate for relational theory. Unfortunately, however, the process requires the execution of multiple queries, and hence, multiple scans of directory links table 310. Specifically, it takes an "i" number of scans to resolve the path of a file, where i is the number of levels in the path (each intermediate directory adds a level). This can be a performance problem.
For purposes of simplifying the performance evaluation, assume that the performance of the pathname resolution is directly proportional to the number of disk blocks that must be accessed. (This is because disk access is an order of 100 slower than memory access, and for large file systems, we can assume that most of the data will be on disk.) Assuming that a conventional BTREE'tndex has been built on the directory links table 310, the number of disk block accesses that a DBMS has to perform I S in one scan of a table is log(n)/m where n is the number of entries in the table and m is the munber of entries per block. Thus, using the pathname resolution technique described above, the average number of accesses that the DBMS will have to perform to access a file is i*log(n)/m.
For complex file systems having a large number of links and a large number of link levels, the number of disk accesses can become quite large. Since I/O
operations are very slow relative to other types of operations, having a large number of disk accesses can significantly degrade system performance. In general, the pathname resolution method described is quite slow when applied to large, complex file systems.
While the data structure of the table is appropriate for easy access to the file system data from relational applications, the standard types of indexes used by databases are too slow for efficient pathname-based access to data organized in this manner. What is needed, then, is an apparatus, system or method that emulates a hierarchically organized system using a relationally organized system, but which reduces the number of disk accesses necessary to locate the items in the system when they are accessed based on their pathnames.
_7_ SUMMARY OF TI-IE INVENTION
A method and mechanism are provided for creating, maintaining, and using a hierarchical index to efficiently access information in a relational system based on a pathnames, thus emulating a hierarchically organized system.
According to one aspect of the invention, each item that has any children in the emulated hierarchical system has an index entry in the index. The index entries in the index are linked together in a way that reflects the hierarchical relationship between the items associated with the index entries. Specifically, if a parent-child relationship exists between the items associated with two index entries, then the index entry associated with the parent item has a direct link to the index enhy associated with the child item.
According to another aspect of the invention, pathname resolution is perforn~ed by following direct links between the index entries associated with the items in a pathname, according to the sequence of the filenames within the pathname. By using an index whose index entries are linked in this manner, the process of accessing the items based on their pathnames is significantly accelerated, and the number of disk accesses performed during that process is significantly reduced.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
Fig. 1 is a block diagram illustrating a hierarchically organized file system;
Fig. 2 shows a files table 210 that may be used to emulate a hierarchically organized system in a relationally organized system;
Fig. 3 shows a directory links table 310 that may be used in conjunction with files table 210 of Fig. 2 to emulate a hierarchically organized system;
Fig. 4 is a block diagram illustrating a database system that may be used to implement a hierarchical index in accordance with one embodiment of the invention;
_g_ R'O 00/49533 PCT/US00103967 Fig. 5 shows a hierarchical index that may be used to enhance performance of an emulated hierarchical system within a relational system;
fig. GA is a flowchart illustrating how hierarchical index 510 is maintained during the creation of an item;
Fig. 6B is a flowchart illustrating how hierarchical index 510 is maintained during the deletion of an item;
Fig. 7 is a flowchart showing the process for resolving a pathname using hierarchical index S 10 in accordance with an embodiment of the invention;
Fig. $ is a block diagram illustrating an example of a hardware system that may be used to implement the apparatus, systems and methods consistent with the invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
A method and apparatus for providing efficient pathname-based access to data stored in a relational system is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
FUNCTIONAL OVERVIEW
Techniques are described herein for creating, maintaining, and using a hierarchical index to efficiently access infornation in a relational system based on a pathnames, thus emulating a hierarchically organized system. Each item that has any children in the emulated hierarchical system has an index entry in the index.
The index entries in the index are linked together in a way that reflects the hierarchical relationship between the items associated with the index entries. Specifically, if a parent-child relationship exists between the items associated with two index entries, then the index entry associated with the parent item has a direct link to the index entry associated with the child item.
1~1'O 00/49533 PCTlUS00/03967 Consequently, pathname resolution is perforn~ed by following direct lima between the index entries associated with the items in a pathname, according to the sequence of the filenames within the pathname. By using an index whose index entries are linked in this manner, the process of accessing the items based on their pathnames is significantly accelerated, and the number of disk accesses performed during that process is significantly reduced.
DATABASE ARCHITECTURE
Fig. 4 is a block diagram showing a database architecture that may be used to create, use, and maintain a hierarchical index consistent with the principles of the present invention. The architecture comprises a user interface 410, a DBMS 412, and a database 414. DBMS 412 interacts with the user via user interface 410, and accesses and maintains database 414 in accordance with the user input. DBMS 412 may also interact with other systems (not shown).
DBMS 412 creates, uses, and maintains a hierarchical index in database 414 in accordance with the principles of the present invention. Hierarchical index creation, use and maintenance will be described hereafter in greater detail.
1n general, DBMS 412 creates a database by organizing information in one or more tables. The organization of the table is referred to as a definition. An index is a structure that is used for accessing particular information in the table more quickly.
Therefore, a table definition supports any access mechanism to the data (search by name, by ID, by date, etc.), whereas an index is designed for a specific access method. The index itself is generally not the authoritative source of the data, but rather contains pointers to the disk addresses of the tables storing the authoritative data.
HIERARCHICAL INDEX
Hierarchical indexes consistent with the invention support the pathname-based access method of a hierarchical system, moving from parent items to their children, as specified by the pathname. According to one embodiment, a hierarchical index consistent with the principles of the invention employs index entries that include the following three fields: RowID, File ID, and Dir-entry list (stored as an array).
Fig. 5 shows a hierarchical index 510 consistent with the invention, which may be used to emulate a hierarchical storage system in a database. Hierarchical index 510 is a table. The RowID column contains system generated Ids, specifying a disk address that enables DBMS 412 to locate the row on the disk. Depending on the relational database system, RowID may be an implicitly defined field that the DBMS uses for locating data stored on the disk drive. The FiIeID field of an index entry stores the FiIeID
of the file that is associated with the index entry.
According to one embodiment of the invention, hierarchical index S 10 only stores index entries for items that have children. In the context of an emulated hierarchical file system, therefore, the items that have index entries in the hierarchical index 510 are only those directories that are parents to other directories and/or that are currently storing documents. Those items that do not have children (Example.doc, Access, Appl, App2, App3) are preferably not included. The Dir entry list field of the index entry for a given file stores, in an array, an "array entry" for each of the child files of the given file.
For example, index entry 512 is for the Windows directory 114. The Word directory 116 and the Access directory 120 are children of the Windows directory 114.
Hence, the Dir entry_list field of index entry 512 for the Windows directory includes an array entry for the Word directory 116 and an array entry for the Access directory 120.
According to one embodiment, the specific information that the Dir entry_list field stores for each child includes the filename of the child and the FiIeID
of the child.
For children that have their own entries in the hierarchical index 510, the Dir entry list field also stores the RowID of the child's index entry. For example, the Word directory 116 has its own entry in hierarchical index 510 (entry 514). Hence, the Dir entry-list field of index entry S 12 includes the name of directory I 1 G (" Word" ), the RowID of the index entry for directory 116 in hierarchical index 510 (" Y3" ), and the FiIeID of directory 116 (" X3" ). As shall be described in greater detail, the information contained in the Dir entry-list field makes accessing information based on pathnames much faster and easier.
Several key principles of the hierarchical index arc as follows:
~ The Dir entry_list information in the index entry for a given directory is kept together in as few disk blocks as possible, since the most Ire~quently used filesystem operations (pathname resolution, directory listing) m.~ill need to look at many of the entries in a particular directory whenever that directory is referenced. In other words, directory entries should have a high locality of reference because when a particular directory entry is referenced, it is likely that other entries in the same directory will also be referenced.
~ The information stored in the index entries of the hierarchical index must be kept to a minimum, so as to fit the maximum number of entries in a particular disk block. Grouping directory entries together in an array means that there is no need to replicate a key identifying the directory they arc in; all of the entries in a directory share the same key. This is in contrast to the typical relational table model shown in the directory links table (table 310).
~ 'The time needed to resolve a pathname should be proportional to the number of directories in the path, not the total number of files in the filesystem. This allows the user to keep frequently-accessed files toward the top of the filesystem tree, where access time is lower.
These elements are all present in typical file system directory structures, such as the UNIX system of modes and directories. The use of a hierarchical index, as described herein, reconciles those goals with the structures that a relational database understands and can query, to allow the database server to do ad-hoc searches of files in a manner other than that used in pathname resolution. To do this, the database concept of an index must be used: a duplicate of parts of the underlying information (in this case, the file data) arranged in a separate data structure in a different manner designed to optimize access via a particular method {in this case, resolution of a pathname in a hierarchical tree).
USING THE HIERARCHICAL INDEX
How hierarchical index 510 may be used to access a file based on the pathname of the file shall now be described with reference to the flowchart in Fig. 7.
It shall be assumed for the purpose of explanation that document 118 is to be accessed through its pathnacne. The pathname for this file is ; Windows/Word/Example.doc, which shall be referred to'hereafter as the "input pathnamc" . Given this pathname, the pathname resolution process starts by locating within hierarchical index 510 the index entry for the first name in the input pathname. In the case of a file system, the first name in a pathname is the root directory. Therefore, the pathname resolution process for locating a file within an emulated file system begins by locating the index entry 508 of the root directory 110 (step 700). Because all pathname resolution operations begin by accessing the root directory's index entry 508, data that indicates the location of the index entry for the root directory 110 (index entry 508) may be maintained at a convenient location outside of the hierarchical index 510 in order to quickly locate the index entry 508 of the root directory at the start of every search.
Once the index entry 508 for the root directory 110 has been located, the DBMS
determines whether there are any more filenames in the input pathname (step 702). If there are no more filenames in the input pathname, then control proceeds to step 720 and the FiIeID stored in index entry 508 is used to look up the root directory entry in the files table 210.
In the present example, the filename " Windows" follows the root directory symbol "/" in the input pathname. Therefore, control proceeds to step 704. At step 704, the next filename (e.g. " Windows" ) is selected from the input pathname. At step 706, _13_ the DBMS looks in the Dir entry-list column of the index entry 508 to locate an array entry pertaining to the selected filename.
In the present example, the filename that follows the root directory in the input pathname is " Windows" . Therefore, step 706 involves searching the Dir entry list of index entry 508 for an array entry for the filename " Windows" . If the Dir-entry- list does not contain an array entry for the selected filename, then control would proceed from step 708 to step 710, where an error is generated to indicate that the input pathnamc is not valid. In the present example, the Dir entry list of index entry 508 does include an array entry for " Windows" . Therefore, control passes from step 708 to step 722.
The information in the Dir entry list of index entry 508 indicates that one of the children ofthe root directory 110 is indeed a file named "Windows". Further, the Dir entry list array entry contains the following information about this child: it has an index entry located at RowID Y2, and its FiIeID is X2.
At step 722, it is determined whether there are any more filenames in the input pathname. If there are no more filenames, then control passes from step 722 to step 720.
In the present example, "Windows" is not the last filename, so control passes instead to step 724.
Because " Windows" is not the last filename in the input path, the FiIeID
information contained in the Dir entry list is not used during this path resolution operation. Rather, because Windows directory 114 is just part of the specified path and not the target, files table 210 is not consulted at this point. Instead, at step 724 the RowID (Y2) for "Windows", which is found in the Dir entry_list of index entry 508, is used to locate the index entry for the Windows directory 114 (index entry 512).
Consulting the Dir entry list of index entry 512, the system searches for the next filename in the input pathname (steps 704 and 706). In the present example, the filename " Word" follows the filename " Windows" in the input pathname. Therefore, the system searches the Dir_ entry list of index entry 512 for an array entry for "Word".
Such an entry exists in the Dir entry list of index entry 512, indicating that "Windows" actually does have a child named "Word" (step 708). At step 722, it is determined that there are more filenames in the input path, so control proceeds to step 724.
Upon finding the array entry for "Word", the system reads the information in the array entry to determine that an index entry for the Word directory 116 can be found in hierarchical index 510 at RowID Y3, and that specific information pertaining to Word directory 116 can be- found in tiles table 210 at row X3.
Since Word directory 116 is just part of the specified path and nc>t the target, files table 210 is not consulted. Instead, the system uses the RowID I;Y3) to locate the index entry 514 for Word directory l 16 (step 724).
At RowID Y3 of hierarchical index 510, the system finds index entry 514. At step 704, the next filename "Example.doc" is selected from the input pathname.
At step 706, the Dir entry-list of index entry 514 is searched to find (step 708) that there is an array entry for "Example.doc", indicating that "Example.doc" is a child of Word directory 116. The system also finds that Example.doc has no indexing information in hierarchical index 510, and that specific information pertaining to Example.doc can be found in tiles table 21 () using the FilelD X4. Since Example.doc is the target file to be accessed (i.e. the last filename in the input path), control passes to step 720 where the system uses the FiIeID X4 to access the appropriate row in the files table 210, and to extract the tile body (the BL<)I3) stared in the body column of that row. Thus, the Example.doc tile is accessed.
In accessing this file, only hierarchical index 510 was used. No table scans were necessary. With typical sizes of blocks and typical filename lengths, at least 100 directory entries will tit in a disk black, and a typical directory has less than 100 entries. This means that the list of directory entries in a given directory will typically fit in a single block. In other words, any single index entry of hierarchical index 510, including the entire Dir entry list array of the index entry, will typically fit entirely in a single block, and therefore can be read in a single 1/O operation.
In moving from index entry to index entry in the hierarchical index 510, it is possible that some disk accesses will need to be performed if the various index entries in the index reside in dih ferent disk blocks. If each index entry entirely fits in a single block, then the number of disk accesses, however, will at most be i. In other words, one disk access is used for each directory in the path. Evan if the size of an average index entry does not m WO 00!49533 PCT/t)S04/03967 fit in a single disk block, but requires 2 or ~i blocks, this will be a constant term, and will not increase with the total number of files in the file system. Unlike the prior methodology, the number of disk I/Os will not be i*log(n)im. Thus, file access using the present invention will be much faster.
CREATION OF HIERARCHICAL INDEX
As explained above, a filename is the name used to reference any file stored in a directory, and is a component of the pathname. For example, in the patl-mame "/Windows/WordlExample.doc", "Windows" is the filename of a directory, " Word"
is the filename of a directory within " Windows", and "Example.doc" is the filename of a document stored in the "Word" directory. Note that a separator character divides the filenames within a pathname. 'The separator character may differ in individual file system implementations. Microsoft file systems, for example, have generally used a backslash ("\") character, UNIX file systems use a forward slash, and Apple Macintosh 61e systems use a colon (":") to separate filenames.
According to one embodiment, the FileID is the primary key in the files table 210, where the actual file data is stored. However, any primary key that references the data stored for each file could be used in the hierarchical index in place of the FiIeID.
The FiIeID in this case is what is usually referred to as a "foreign key" in the hierarchical index 510.
Initially there are no files in the file system other than the root directory (n.
Therefore, the hierarchical index is created by inserting one row into the index 510 (Fig.
5) for the root directory. Because there are no files in the root directory at this point, the Dir entry list field of the root directory's index entry should be left empty.
The user of the hierarchical index should keep the RowlD of the root entry in a separate location (for example, in dynamic memory or in a separate table in the database with only one entry).
The root entry is the staring point for every use of the hierarchical index 510, so it is important to have the location of that entry readily available. As new files are added to the file system, the hierarchical index S l 0 is updated as described in the section below entitled "Maintenance of Hierarchical Index."
If the hierarchical index 510 is to be created alter the file system has been populated, it may be created by traversing the entire file system and adding hierarchical index entries for each file present in the file system in the same manner as if the file had just been added to the system, according to the method described in "Maintenance of Hierarchical Index."
MAIN~fENANCE OF HIERAIZCH1CAL INDEX
The maintenance of one embodiment of a hierarchical index shall now be described with reference to Figs. 6A and 6B. Referring to Fig. 6A, it is a flowchart illustrating steps performed in response to a file being created in a file system that is being emulated in a relational system that uses a hierarchical index. At step 600, the new file is created. At step 602, it is determined whether the new file is the first child of the file that has been designated as its parent. For example, assume that a document Docl.doc is being created in the Appl directory. Currently, Appl does not have any children, so Docl.doc would be its first child and control would pass to step 604.
At step 604, an index entry is created for the parent. In the present example, an index entry would be created for " App 1 " . At step 610, the array entry for the parent, which resides in the index entry for the parent's parent, is updated to include a link to the newly created index entry. In the present example, the array entry 518 for "Appl" that resides in the index entry 516 for "Unix" is updated to include the RowID, within hierarchical index 510, of the newly created index entry for "Appl" . At step 606, an array entry for the new file Docl.doc is inserted into the Dir entry_list of the newly created index entry for " App 1" .
if the file being created is not the first child of the designated parent, then control passes to step 608. At step 608, the index entry for the designated parent is located, and at step 606 an array entry for the new file is inserted into the Dir_ entry list of the parent's index entry.
Figure 6B is a flowchart illustrating the steps for updating a hierarchical index in response to a file being deleted. At step 650, the file is deleted. At step 652, it is determined whether the file was the only child of a parent. If the deleted file was the only child of a parent, then the index entry for the parent is removed from the index (step 6~4) and the array envy for the parent that resides in the index entry of the parent's parent is updated (step 660) to reflect that the parent no longer has an index entry in the index. If the child was not the only index entry for the parent, then the array entry for the deleted file is removed from the Dir entry-list of the parent.
Whether or not the deleted file was the only child of its parent, any index entry for the deleted file and index entries for the deleted file's descendants are also deleted (Step 658).
When files are moved from one location in the hierarchy to another, the hierarchical index is updated by removing the array entry for the file from the Dir entry list of its old parent, and adding an array entry for the item to the Dir entry list of its new parent.
SEARCHING THE DIR ENTRY LIST ARRAY
As explained above, one step of the pathname resolution process involves searching through the Dir entry list array for an array entry of a particular child (Fig. 7, step 706). According to one embodiment, this search process is facilitated by storing the array entries in each Dir entry list array in alphabetical order. By storing the array entries in order, more efficient searching techniques, such as a binary search, may be used to find the entry for a given child. However, maintaining the array entries in sorted order incurs additional maintenance overhead. Consequently, in one embodiment, only arrays that have more than a threshold number of array entries are ordered.
VARIATIONS
Specific embodiments have been used to illustrate the use of a hierarchical index to access hierarchical data in a relational system. However, the present invention is not limited to the embodiments described. For example, hierarchical index 510 only includes index entries for those items that have at least one child. However, a hierarchical index may optionally include index entries for all items, whether or not they have children.
As illustrated, the Dir entry list array entries of an index entry in hierarchical index 510 include the FiIeID, which may be used to locate the child in the files table. However, the actual fields stored in each Dir entry___list array entry may vary from implementation to implementation. For example, the Dir entry_ list may additionally or alternatively include the RowID of the corresponding row in the files table, or any other unique, non-null key that can be used to locate the corresponding entry in the tiles table.
According to one embodimealt, the Fi'IeID is generated sequentially, in contrast to rowids that are typically based on disk block addresses. The FiIeID values are useful in importing/exporting the directories in and out of the database (e;.g. for backup/restore l0 purposes), since the RowIDs used by the exporting database may be different than the RowIDs used for the same rows by the importing database. if the importing database finds a different place on disk to load the directory.
According to one embodiment, the hierarchical index does not have a separate FiIeID
column, as shown in Figure 5. Instead, the FiIeID of the target item is extracted from the array entry for the target item, which is located in the Dir_ entry_ list of the parent of the target item. The FiIeID of the root directory, which has no parent, may be stored separate from the hierarchical index.
In addition, the Dir entry list entries may be used to "cache" useful information about the items to which they correspond. Such additional information may include, for example, information about the security privileges associated with the item.
In some cases, the additional information stored in the array entry for an item may include all of the information required to satisfy a query that references the item, thus completely avoiding the need tc> access the item's files table information. However, the desire to cache useful information in the Dir entry_list must be weighed against the need to limit the size of the Dir entry list to reduce the number of I/Os required to read each index entry.
Embodiments of the invention have been described in the context of a file system.
However, the techniques described herein are applicable tc> the storage, within a relationally organized system, of any hierarchically organized information. For example, a relational system may be used to store records about animals, where the animal records are to be accessed based on a hierarchical "path" consisting of the class, order, family and species to which the animals belong.
HARDWARE OVERVIEW
Figure 8 is a block diagram that illustrates a computer system 800 upon which an embodiment of the invention may be implemented. Computer system 800 includes a bus 802 or other communication mechanism for communicating information, and a processor 804 coupled with bus 802 for processing information. Computer system 800 also includes a main memory 806, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 802 for storing information and instmetions to be executed by processor 804. Main memory 806 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 804. Computer system 800 further includes a read only memory {ROM) 808 or other static storage device coupled to bus 802 for storing static information and instructions for processor 804. A storage device 810, such as a magnetic disk or optical disk, is provided and coupled to bus 802 for storing information and mstruerions.
Computer system 800 may be coupled via bus 802 to a display 812, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 814, including alphanumeric and other keys, is coupled to bus 802 for communicating information and command selections to processor 804. Another type of user input device is cursor control 816, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 804 and for controlling cursor movement on display 812. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
The invention is related to the use of computer system 800 for accessing hierarchically organized information stored in a relational system. According to one embodiment of the invention, computer system 800 creates, maintains and uses a hierarchical index in response to processor 804 executing one or more sequences of one or more instructions contained in main memory 806. Such instructions may be read into main memory 80G from another computer-readable medium, such as storage device 810.
Execution of the scqucnccs of instructions contained in main memory 80G causes processor 804 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The term "computer-readable medium" as used herein refers to any medium that participates in providing instructions to processor 804 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 810. Volatile media includes dynamic memory, such as main memory 80G. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 802. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.
Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASI-I-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 804 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 800 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 802. Bus 802 carries the data to main memory 80G, from which processor 804 retrieves and executes the WO 00149533 PCT/US00l03967 instructions. The instructions received by main memory 806 may optionally be stored on storage device 810 either before or after execution by processor 804.
Computer system 800 also includes a communication interface 818 coupled to bus 802. Communication interface 818 provides a two-way data communication coupling to a network link 820 that is connected to a local network $22. For example, communication interface 818 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 818 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 818 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link 820 typically provides data communication through one or more networks to other data devices. For example, network link $20 may provide a connection through local network 822 to a host computer 824 or to data equipment operated by an Internet Service Provider (ISP) 826. ISP 826 in tum provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 828. Local network 822 and Internet both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 820 and through communication interface 818, which carry the digital data to and from computer system 800, are exemplary forms of carrier waves transporting the information.
Computer system 800 can send messages and receive data, including program code, through the network(s), network link 820 and communication interface 818. In the Internet example, a server 830 might transmit a requested code for an application program through Internet 828, ISP 826, local network 822 and communication interface 818.
The received code may be executed by processor 804 as it is received, andlor stored in storage device 810, or other non-volatile storage for later execution. In this manner, computer system 800 may obtain application code in the form of a carrier wave.
In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to Lie regarded in an illustrative rather than a restrictive sense.
Claims (23)
1. A method for indexing, in a relational system, a plurality of items that belong to a hierarchy, the method comprising the steps of:
creating an index;
storing in the index a first index entry for a first item of the plurality of items, said first item being a child of a second item in said hierarchy; and storing in the index a second index entry for the second item of the plurality of items, said second index entry containing a link to said first index entry for locating said first index entry in said index.
creating an index;
storing in the index a first index entry for a first item of the plurality of items, said first item being a child of a second item in said hierarchy; and storing in the index a second index entry for the second item of the plurality of items, said second index entry containing a link to said first index entry for locating said first index entry in said index.
2. The method of Claim 1 wherein said second item has a plurality of children in the hierarchy, the method further including the step of storing within said second index entry an array of array entries, said away of array entries including an array entry for each child item of said second item.
3. The method of Claim 2 further comprising the step of storing, in each array entry of said array that corresponds to a child item that has its own index entry in said index, a link to the index entry for the child item.
4. The method of Claim 2 further comprising the steps of:
receiving a sequence of names, including a first name associated with the first item and a second name associated with the second item;
using said second name to locate said second index entry;
using said first name to locate, within said array in said second index entry, an array entry for said first item;
reading said link to said first index entry from said array entry for said first item; and following said link to said first index entry.
receiving a sequence of names, including a first name associated with the first item and a second name associated with the second item;
using said second name to locate said second index entry;
using said first name to locate, within said array in said second index entry, an array entry for said first item;
reading said link to said first index entry from said array entry for said first item; and following said link to said first index entry.
5. The method of Claim 1 wherein the plurality of items includes a third item that is a child of said second item, the method including the steps of:
storing in said index a third index entry for said third item; and storing in said second index entry a link to sail third item.
storing in said index a third index entry for said third item; and storing in said second index entry a link to sail third item.
6. The method of Claim 1 wherein:
the first index entry includes information for locating said first item; and the second index entry includes information for locating said second item.
the first index entry includes information for locating said first item; and the second index entry includes information for locating said second item.
7. The method of Claim 1 wherein:
the first item is stored outside said index; and the second index entry includes information for locating said first item outside of said index.
the first item is stored outside said index; and the second index entry includes information for locating said first item outside of said index.
8. The method of Claim 2 further comprising the step of maintaining said array of array entries in sorted order based on the child items with which they are associated.
9. A computer readable medium having stored thereon:
an index for accessing a plurality of items that are related to each other according to a hierarchy, where each item of said plurality of items has zero or more child items;
said index including a plurality of index entries;
wherein each index entry of said plurality of index entries corresponds to an item of said plurality of items, and is linked to all index entries within the index that correspond to child items of said item.
an index for accessing a plurality of items that are related to each other according to a hierarchy, where each item of said plurality of items has zero or more child items;
said index including a plurality of index entries;
wherein each index entry of said plurality of index entries corresponds to an item of said plurality of items, and is linked to all index entries within the index that correspond to child items of said item.
10. The computer readable medium of Claim 9 wherein:
the plurality of items are stored electronically outside said. index; and each index entry of said plurality of index entries stores data for locating, outside said index, the item that corresponds to the index entry.
the plurality of items are stored electronically outside said. index; and each index entry of said plurality of index entries stores data for locating, outside said index, the item that corresponds to the index entry.
11. The computer readable medium of Claim 10 wherein:
the plurality of items are stored in rows of a table; and each index entry of said plurality of index entries stores data for locating in said table the row for the item that corresponds to the index entry.
the plurality of items are stored in rows of a table; and each index entry of said plurality of index entries stores data for locating in said table the row for the item that corresponds to the index entry.
12. The computer readable medium of Claim 9 wherein:
the plurality of items are stored electronically outside said index; and each index entry of said plurality of index entries stores data for locating, outside said index, the child items of the item that corresponds to the index entry.
the plurality of items are stored electronically outside said index; and each index entry of said plurality of index entries stores data for locating, outside said index, the child items of the item that corresponds to the index entry.
13. The computer readable medium of Claim 12 wherein:
the plurality of items are stored in rows of a table; and each index entry of said plurality of index entries stores data for locating in said table the rows for the child items of the item that corresponds to the index entry.
the plurality of items are stored in rows of a table; and each index entry of said plurality of index entries stores data for locating in said table the rows for the child items of the item that corresponds to the index entry.
14. The computer readable medium of Claim 9 wherein each index entry that corresponds to an item that has child items includes an array of array entries, where each array entry in the array stores information about a child item of the item.
15. The computer readable medium of Claim 14 wherein the array entry for each child item stores a name for the child item.
16. The computer readable medium of Claim 15 wherein the array entries within the array are maintained in sorted order based on the names of the child items.
17. The computer readable medium of Claim 14 wherein the array entry for each child item stores:
data for locating the child item outside the index, and for each child item that has its own index entry, a link to the index entry of the child item.
data for locating the child item outside the index, and for each child item that has its own index entry, a link to the index entry of the child item.
18. A method for locating items that belong to a hierarchy that establishes parent-child relationships between the items, the method comprising the steps of:
receiving a sequence of identifiers that identities a path through the hierarchy to a target item;
using a hierarchical index to locate information about said target item by performing the steps of:
locating, within said hierarchical index, an index entry for a first item, wherein said first item is the item identified by the first identifier in said sequence of identifiers;
beginning with said index entry for said first item, following links between index entries, in a sequence dictated by said sequence of identifiers, to arrive at a particular index entry that indicates where said information about the target item is located; and using information in said particular index entry to locate and access said information about said target item.
receiving a sequence of identifiers that identities a path through the hierarchy to a target item;
using a hierarchical index to locate information about said target item by performing the steps of:
locating, within said hierarchical index, an index entry for a first item, wherein said first item is the item identified by the first identifier in said sequence of identifiers;
beginning with said index entry for said first item, following links between index entries, in a sequence dictated by said sequence of identifiers, to arrive at a particular index entry that indicates where said information about the target item is located; and using information in said particular index entry to locate and access said information about said target item.
19. The method of Claim 18 wherein the step of following links includes:
within an index entry for a parent item, searching an array to locate an array entry for a particular child item, wherein the array includes array entries for each child item of the parent item.
within an index entry for a parent item, searching an array to locate an array entry for a particular child item, wherein the array includes array entries for each child item of the parent item.
20. The method of Claim 19 wherein:
the parent item corresponds to an identifier in said sequence of identifiers;
the particular child item corresponds to an identifier in said sequence of identifiers; and the identifier for said parent item immediately precedes the identifier for said particular child item in said sequence of identifiers.
the parent item corresponds to an identifier in said sequence of identifiers;
the particular child item corresponds to an identifier in said sequence of identifiers; and the identifier for said parent item immediately precedes the identifier for said particular child item in said sequence of identifiers.
21. A computer readable medium having stored thereon sequences of instructions for locating items that belong to a hierarchy that establishes parent-child relationships between the items, the sequences of instructions including instructions for performing the steps of:
receiving a sequence of identifiers that identities a path through the hierarchy to a target item;
using a hierarchical index to locate information about said target item by performing the steps of:
locating, within said hierarchical index, an index entry for a first item, wherein said first item is the item identified by the first identifier in said sequence of identifiers;
beginning with said index entry for said first item, following links between index entries, in a sequence dictated by said sequence of identifiers, to arrive at a particular index entry that indicates where said information about the target item is located; and using information in said particular index entry to locate and access said information about said target item.
receiving a sequence of identifiers that identities a path through the hierarchy to a target item;
using a hierarchical index to locate information about said target item by performing the steps of:
locating, within said hierarchical index, an index entry for a first item, wherein said first item is the item identified by the first identifier in said sequence of identifiers;
beginning with said index entry for said first item, following links between index entries, in a sequence dictated by said sequence of identifiers, to arrive at a particular index entry that indicates where said information about the target item is located; and using information in said particular index entry to locate and access said information about said target item.
22. The computer readable medium of Claim 21 wherein the step of following links includes:
within an index entry for a parent item, searching an array to locate an array entry for a particular child item, wherein the array includes array entries for each child item of the parent item.
within an index entry for a parent item, searching an array to locate an array entry for a particular child item, wherein the array includes array entries for each child item of the parent item.
23. The computer readable medium of Claim 22 wherein:
the parent item corresponds to an identifier in said sequence of identifiers;
the particular child item corresponds to an identifier in said sequence of identifiers; and the identifier for said parent item immediately precedes the identifier for said particular child item in said sequence of identifiers.
the parent item corresponds to an identifier in said sequence of identifiers;
the particular child item corresponds to an identifier in said sequence of identifiers; and the identifier for said parent item immediately precedes the identifier for said particular child item in said sequence of identifiers.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/251,757 US6427123B1 (en) | 1999-02-18 | 1999-02-18 | Hierarchical indexing for accessing hierarchically organized information in a relational system |
| US09/251,757 | 1999-02-18 | ||
| PCT/US2000/003967 WO2000049533A2 (en) | 1999-02-18 | 2000-02-17 | Hierarchical indexing for accessing hierarchically organized information in a relational system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2359880A1 CA2359880A1 (en) | 2000-08-24 |
| CA2359880C true CA2359880C (en) | 2006-07-04 |
Family
ID=22953278
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002359880A Expired - Lifetime CA2359880C (en) | 1999-02-18 | 2000-02-17 | Hierarchical indexing for accessing hierarchically organized information in a relational system |
Country Status (6)
| Country | Link |
|---|---|
| US (2) | US6427123B1 (en) |
| EP (1) | EP1145143B1 (en) |
| JP (3) | JP2003505748A (en) |
| AU (1) | AU762942B2 (en) |
| CA (1) | CA2359880C (en) |
| WO (1) | WO2000049533A2 (en) |
Families Citing this family (180)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6201964B1 (en) * | 1998-11-13 | 2001-03-13 | Qualcomm Incorporated | Method and apparatus for fast and random access of variable sized records stored in a partitioned format |
| US7366708B2 (en) * | 1999-02-18 | 2008-04-29 | Oracle Corporation | Mechanism to efficiently index structured data that provides hierarchical access in a relational database system |
| US8335775B1 (en) | 1999-08-05 | 2012-12-18 | Oracle International Corporation | Versioning in internet file system |
| US6760731B2 (en) * | 2000-03-15 | 2004-07-06 | Kent W. Huff | Genealogy registry system |
| US7421541B2 (en) * | 2000-05-12 | 2008-09-02 | Oracle International Corporation | Version management of cached permissions metadata |
| US6853997B2 (en) * | 2000-06-29 | 2005-02-08 | Infoglide Corporation | System and method for sharing, mapping, transforming data between relational and hierarchical databases |
| KR100695303B1 (en) * | 2000-10-31 | 2007-03-14 | 삼성전자주식회사 | Control signal part and fabricating method thereof and liquid crystal display including the control signal part and fabricating method thereof |
| US6625615B2 (en) * | 2000-12-19 | 2003-09-23 | International Business Machines Corporation | Data processing system and method for multi-level directory searches |
| US7200627B2 (en) * | 2001-03-21 | 2007-04-03 | Nokia Corporation | Method and apparatus for generating a directory structure |
| US20030193994A1 (en) * | 2001-03-21 | 2003-10-16 | Patrick Stickler | Method of managing media components |
| US7254570B2 (en) * | 2001-03-21 | 2007-08-07 | Nokia Corporation | Query resolution system and service |
| JP4076078B2 (en) * | 2001-03-30 | 2008-04-16 | キヤノン株式会社 | File management method |
| JP2003022206A (en) * | 2001-07-06 | 2003-01-24 | Fujitsu Ltd | File managing program and file managing device |
| US7299270B2 (en) * | 2001-07-10 | 2007-11-20 | Lycos, Inc. | Inferring relations between internet objects that are not connected directly |
| US6980976B2 (en) * | 2001-08-13 | 2005-12-27 | Oracle International Corp. | Combined database index of unstructured and structured columns |
| US6912542B2 (en) * | 2001-09-26 | 2005-06-28 | Intel Corporation | Method for implementing fast type checking |
| US7047250B1 (en) | 2001-09-28 | 2006-05-16 | Oracle International Corporation | Indexing to efficiently manage versioned data in a database system |
| CA2461871C (en) * | 2001-09-28 | 2012-12-18 | Oracle International Corporation | An efficient index structure to access hierarchical data in a relational database system |
| US7092967B1 (en) | 2001-09-28 | 2006-08-15 | Oracle International Corporation | Loadable units for lazy manifestation of XML documents |
| US7028037B1 (en) * | 2001-09-28 | 2006-04-11 | Oracle International Corporation | Operators for accessing hierarchical data in a relational system |
| AU2002334721B2 (en) | 2001-09-28 | 2008-10-23 | Oracle International Corporation | An index structure to access hierarchical data in a relational database system |
| US7051039B1 (en) | 2001-09-28 | 2006-05-23 | Oracle International Corporation | Mechanism for uniform access control in a database system |
| US7047253B1 (en) | 2001-09-28 | 2006-05-16 | Oracle Interntional Corporation | Mechanisms for storing content and properties of hierarchically organized resources |
| EP1300757A1 (en) * | 2001-10-02 | 2003-04-09 | Sun Microsystems, Inc. | Shareable installation hierarchies |
| US7124358B2 (en) * | 2002-01-02 | 2006-10-17 | International Business Machines Corporation | Method for dynamically generating reference identifiers in structured information |
| US7237192B1 (en) | 2002-04-30 | 2007-06-26 | Oracle International Corporation | Methods and systems for naming and indexing children in a hierarchical nodal structure |
| US6965903B1 (en) | 2002-05-07 | 2005-11-15 | Oracle International Corporation | Techniques for managing hierarchical data with link attributes in a relational database |
| US7548935B2 (en) * | 2002-05-09 | 2009-06-16 | Robert Pecherer | Method of recursive objects for representing hierarchies in relational database systems |
| US7130856B2 (en) * | 2002-07-20 | 2006-10-31 | Microsoft Corporation | Map and data location provider |
| AU2003286187A1 (en) * | 2002-10-18 | 2004-05-04 | International Business Machines Corporation | Method and system for online analytical processing (olap) |
| US8392291B2 (en) * | 2002-10-31 | 2013-03-05 | Sap Aktiengesellschaft | Automated structuring |
| US7020653B2 (en) | 2002-11-06 | 2006-03-28 | Oracle International Corporation | Techniques for supporting application-specific access controls with a separate server |
| US6947950B2 (en) * | 2002-11-06 | 2005-09-20 | Oracle International Corporation | Techniques for managing multiple hierarchies of data from a single interface |
| US7308474B2 (en) | 2002-11-06 | 2007-12-11 | Oracle International Corporation | Techniques for scalably accessing data in an arbitrarily large document by a device with limited resources |
| US8271971B2 (en) * | 2002-11-26 | 2012-09-18 | Hewlett-Packard Development Company, L.P. | System and method for automated program updating in a remote appliance |
| US7191186B1 (en) * | 2002-11-27 | 2007-03-13 | Microsoft Corporation | Method and computer-readable medium for importing and exporting hierarchically structured data |
| US7168619B2 (en) * | 2002-11-27 | 2007-01-30 | Sap Ag | Structuring of temporary systems |
| JP2004272439A (en) * | 2003-03-06 | 2004-09-30 | Konica Minolta Holdings Inc | Directory retrieval method, directory retrieval device, storage medium and program |
| JP2004280283A (en) * | 2003-03-13 | 2004-10-07 | Hitachi Ltd | Distributed file system, distributed file system server, and access method to distributed file system |
| JP4320195B2 (en) | 2003-03-19 | 2009-08-26 | 株式会社日立製作所 | File storage service system, file management apparatus, file management method, ID designation type NAS server, and file reading method |
| US20050044075A1 (en) * | 2003-07-29 | 2005-02-24 | Microsoft Corporation | Method and apparatus for late-binding/dynamic pathname resolution |
| US7401104B2 (en) | 2003-08-21 | 2008-07-15 | Microsoft Corporation | Systems and methods for synchronizing computer systems through an intermediary file system share or device |
| US7555497B2 (en) * | 2003-08-21 | 2009-06-30 | Microsoft Corporation | Systems and methods for separating units of information manageable by a hardware/software interface system from their physical organization |
| US8238696B2 (en) * | 2003-08-21 | 2012-08-07 | Microsoft Corporation | Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system |
| US7590643B2 (en) | 2003-08-21 | 2009-09-15 | Microsoft Corporation | Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system |
| US8131739B2 (en) | 2003-08-21 | 2012-03-06 | Microsoft Corporation | Systems and methods for interfacing application programs with an item-based storage platform |
| US8166101B2 (en) | 2003-08-21 | 2012-04-24 | Microsoft Corporation | Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system |
| US7814047B2 (en) * | 2003-08-25 | 2010-10-12 | Oracle International Corporation | Direct loading of semistructured data |
| US7490093B2 (en) | 2003-08-25 | 2009-02-10 | Oracle International Corporation | Generating a schema-specific load structure to load data into a relational database based on determining whether the schema-specific load structure already exists |
| US8219569B2 (en) | 2003-08-25 | 2012-07-10 | Oracle International Corporation | In-place evolution of XML schemes |
| US8229932B2 (en) * | 2003-09-04 | 2012-07-24 | Oracle International Corporation | Storing XML documents efficiently in an RDBMS |
| US8694510B2 (en) | 2003-09-04 | 2014-04-08 | Oracle International Corporation | Indexing XML documents efficiently |
| US20050147947A1 (en) * | 2003-12-29 | 2005-07-07 | Myfamily.Com, Inc. | Genealogical investigation and documentation systems and methods |
| US8095567B2 (en) | 2003-12-29 | 2012-01-10 | Myfamily.Com, Inc. | Providing alternatives within a family tree systems and methods |
| US8667035B2 (en) * | 2004-02-12 | 2014-03-04 | International Business Machines Corporation | Method of converting a filesystem while the filesystem remains in an active state |
| US9104673B2 (en) * | 2004-02-12 | 2015-08-11 | International Business Machines Corporation | Method for supporting multiple filesystem implementations |
| US7440954B2 (en) * | 2004-04-09 | 2008-10-21 | Oracle International Corporation | Index maintenance for operations involving indexed XML data |
| US7493305B2 (en) * | 2004-04-09 | 2009-02-17 | Oracle International Corporation | Efficient queribility and manageability of an XML index with path subsetting |
| US7398265B2 (en) * | 2004-04-09 | 2008-07-08 | Oracle International Corporation | Efficient query processing of XML data using XML index |
| US7499915B2 (en) * | 2004-04-09 | 2009-03-03 | Oracle International Corporation | Index for accessing XML data |
| US7930277B2 (en) | 2004-04-21 | 2011-04-19 | Oracle International Corporation | Cost-based optimizer for an XML data repository within a database |
| US7275065B2 (en) * | 2004-05-24 | 2007-09-25 | International Business Machines Corporation | Method and system for supporting per-user-per-row read/unread tracking for relational databases |
| JP4709213B2 (en) | 2004-06-23 | 2011-06-22 | オラクル・インターナショナル・コーポレイション | Efficient evaluation of queries using transformations |
| US7885980B2 (en) | 2004-07-02 | 2011-02-08 | Oracle International Corporation | Mechanism for improving performance on XML over XML data using path subsetting |
| US8566300B2 (en) * | 2004-07-02 | 2013-10-22 | Oracle International Corporation | Mechanism for efficient maintenance of XML index structures in a database system |
| US20070208946A1 (en) * | 2004-07-06 | 2007-09-06 | Oracle International Corporation | High performance secure caching in the mid-tier |
| US7668806B2 (en) | 2004-08-05 | 2010-02-23 | Oracle International Corporation | Processing queries against one or more markup language sources |
| US7627616B2 (en) * | 2004-08-30 | 2009-12-01 | Hywire Ltb. | Database storage and maintenance using row index ordering |
| US7801922B2 (en) * | 2004-09-30 | 2010-09-21 | Emc Corporation | File index processing |
| US7716262B2 (en) * | 2004-09-30 | 2010-05-11 | Emc Corporation | Index processing |
| GB2419700B (en) * | 2004-10-29 | 2010-03-31 | Hewlett Packard Development Co | Methods for indexing data, systems, software and apparatus relng thereto |
| US7627547B2 (en) * | 2004-11-29 | 2009-12-01 | Oracle International Corporation | Processing path-based database operations |
| US7849106B1 (en) | 2004-12-03 | 2010-12-07 | Oracle International Corporation | Efficient mechanism to support user defined resource metadata in a database repository |
| US7921076B2 (en) | 2004-12-15 | 2011-04-05 | Oracle International Corporation | Performing an action in response to a file system event |
| US8131766B2 (en) * | 2004-12-15 | 2012-03-06 | Oracle International Corporation | Comprehensive framework to integrate business logic into a repository |
| US9639554B2 (en) | 2004-12-17 | 2017-05-02 | Microsoft Technology Licensing, Llc | Extensible file system |
| US8321439B2 (en) | 2004-12-17 | 2012-11-27 | Microsoft Corporation | Quick filename lookup using name hash |
| US8606830B2 (en) | 2004-12-17 | 2013-12-10 | Microsoft Corporation | Contiguous file allocation in an extensible file system |
| US7523131B2 (en) | 2005-02-10 | 2009-04-21 | Oracle International Corporation | Techniques for efficiently storing and querying in a relational database, XML documents conforming to schemas that contain cyclic constructs |
| US7805422B2 (en) | 2005-02-28 | 2010-09-28 | Microsoft Corporation | Change notification query multiplexing |
| US8346737B2 (en) | 2005-03-21 | 2013-01-01 | Oracle International Corporation | Encoding of hierarchically organized data for efficient storage and processing |
| US7685150B2 (en) | 2005-04-19 | 2010-03-23 | Oracle International Corporation | Optimization of queries over XML views that are based on union all operators |
| US7949941B2 (en) | 2005-04-22 | 2011-05-24 | Oracle International Corporation | Optimizing XSLT based on input XML document structure description and translating XSLT into equivalent XQuery expressions |
| US7908254B2 (en) * | 2005-06-10 | 2011-03-15 | Hewlett-Packard Development Company, L.P. | Identifying characteristics in sets of organized items |
| US8166059B2 (en) | 2005-07-08 | 2012-04-24 | Oracle International Corporation | Optimization of queries on a repository based on constraints on how the data is stored in the repository |
| US8762410B2 (en) * | 2005-07-18 | 2014-06-24 | Oracle International Corporation | Document level indexes for efficient processing in multiple tiers of a computer system |
| US20070016605A1 (en) * | 2005-07-18 | 2007-01-18 | Ravi Murthy | Mechanism for computing structural summaries of XML document collections in a database system |
| AU2006271465A1 (en) * | 2005-07-20 | 2007-01-25 | Renovo Limited | Data storage method |
| US7406478B2 (en) | 2005-08-11 | 2008-07-29 | Oracle International Corporation | Flexible handling of datetime XML datatype in a database system |
| CN101053037B (en) * | 2005-08-31 | 2010-06-23 | 索尼株式会社 | File processing device, file processing method |
| US8073841B2 (en) | 2005-10-07 | 2011-12-06 | Oracle International Corporation | Optimizing correlated XML extracts |
| US8554789B2 (en) | 2005-10-07 | 2013-10-08 | Oracle International Corporation | Managing cyclic constructs of XML schema in a rdbms |
| US9367642B2 (en) | 2005-10-07 | 2016-06-14 | Oracle International Corporation | Flexible storage of XML collections within an object-relational database |
| US8024368B2 (en) | 2005-10-07 | 2011-09-20 | Oracle International Corporation | Generating XML instances from flat files |
| US8356053B2 (en) | 2005-10-20 | 2013-01-15 | Oracle International Corporation | Managing relationships between resources stored within a repository |
| US8949455B2 (en) | 2005-11-21 | 2015-02-03 | Oracle International Corporation | Path-caching mechanism to improve performance of path-related operations in a repository |
| US8015165B2 (en) * | 2005-12-14 | 2011-09-06 | Oracle International Corporation | Efficient path-based operations while searching across versions in a repository |
| US7472140B2 (en) * | 2005-12-20 | 2008-12-30 | Oracle International Corporation | Label-aware index for efficient queries in a versioning system |
| US7543004B2 (en) * | 2005-12-22 | 2009-06-02 | Oracle International Corporation | Efficient support for workspace-local queries in a repository that supports file versioning |
| US7933928B2 (en) * | 2005-12-22 | 2011-04-26 | Oracle International Corporation | Method and mechanism for loading XML documents into memory |
| US7533136B2 (en) * | 2005-12-22 | 2009-05-12 | Oracle International Corporation | Efficient implementation of multiple work areas in a file system like repository that supports file versioning |
| US7730032B2 (en) * | 2006-01-12 | 2010-06-01 | Oracle International Corporation | Efficient queriability of version histories in a repository |
| US9229967B2 (en) * | 2006-02-22 | 2016-01-05 | Oracle International Corporation | Efficient processing of path related operations on data organized hierarchically in an RDBMS |
| US7836032B2 (en) * | 2006-03-28 | 2010-11-16 | International Business Machines Corporation | Remapping child references when parent reference updates are processed |
| US20070250527A1 (en) * | 2006-04-19 | 2007-10-25 | Ravi Murthy | Mechanism for abridged indexes over XML document collections |
| US8510292B2 (en) * | 2006-05-25 | 2013-08-13 | Oracle International Coporation | Isolation for applications working on shared XML data |
| US10318752B2 (en) * | 2006-05-26 | 2019-06-11 | Oracle International Corporation | Techniques for efficient access control in a database system |
| US8463810B1 (en) | 2006-06-01 | 2013-06-11 | Monster Worldwide, Inc. | Scoring concepts for contextual personalized information retrieval |
| US7882539B2 (en) * | 2006-06-02 | 2011-02-01 | Microsoft Corporation | Abstracting security policy from, and transforming to, native representations of access check mechanisms |
| US7499909B2 (en) | 2006-07-03 | 2009-03-03 | Oracle International Corporation | Techniques of using a relational caching framework for efficiently handling XML queries in the mid-tier data caching |
| US20080033967A1 (en) * | 2006-07-18 | 2008-02-07 | Ravi Murthy | Semantic aware processing of XML documents |
| US20080092037A1 (en) * | 2006-10-16 | 2008-04-17 | Oracle International Corporation | Validation of XML content in a streaming fashion |
| US7933935B2 (en) | 2006-10-16 | 2011-04-26 | Oracle International Corporation | Efficient partitioning technique while managing large XML documents |
| US7797310B2 (en) | 2006-10-16 | 2010-09-14 | Oracle International Corporation | Technique to estimate the cost of streaming evaluation of XPaths |
| US7827177B2 (en) | 2006-10-16 | 2010-11-02 | Oracle International Corporation | Managing compound XML documents in a repository |
| US9183321B2 (en) | 2006-10-16 | 2015-11-10 | Oracle International Corporation | Managing compound XML documents in a repository |
| US7739251B2 (en) | 2006-10-20 | 2010-06-15 | Oracle International Corporation | Incremental maintenance of an XML index on binary XML data |
| US8010889B2 (en) * | 2006-10-20 | 2011-08-30 | Oracle International Corporation | Techniques for efficient loading of binary XML data |
| US7840590B2 (en) * | 2006-12-18 | 2010-11-23 | Oracle International Corporation | Querying and fragment extraction within resources in a hierarchical repository |
| US20080147615A1 (en) * | 2006-12-18 | 2008-06-19 | Oracle International Corporation | Xpath based evaluation for content stored in a hierarchical database repository using xmlindex |
| US7860899B2 (en) * | 2007-03-26 | 2010-12-28 | Oracle International Corporation | Automatically determining a database representation for an abstract datatype |
| US7814117B2 (en) | 2007-04-05 | 2010-10-12 | Oracle International Corporation | Accessing data from asynchronously maintained index |
| US7836098B2 (en) * | 2007-07-13 | 2010-11-16 | Oracle International Corporation | Accelerating value-based lookup of XML document in XQuery |
| US7840609B2 (en) * | 2007-07-31 | 2010-11-23 | Oracle International Corporation | Using sibling-count in XML indexes to optimize single-path queries |
| US10089361B2 (en) * | 2007-10-31 | 2018-10-02 | Oracle International Corporation | Efficient mechanism for managing hierarchical relationships in a relational database system |
| US7991768B2 (en) | 2007-11-08 | 2011-08-02 | Oracle International Corporation | Global query normalization to improve XML index based rewrites for path subsetted index |
| US8250062B2 (en) | 2007-11-09 | 2012-08-21 | Oracle International Corporation | Optimized streaming evaluation of XML queries |
| US8543898B2 (en) | 2007-11-09 | 2013-09-24 | Oracle International Corporation | Techniques for more efficient generation of XML events from XML data sources |
| US20090132607A1 (en) * | 2007-11-16 | 2009-05-21 | Lorenzo Danesi | Techniques for log file processing |
| US9842090B2 (en) | 2007-12-05 | 2017-12-12 | Oracle International Corporation | Efficient streaming evaluation of XPaths on binary-encoded XML schema-based documents |
| US20090164418A1 (en) * | 2007-12-19 | 2009-06-25 | Valentina Pulnikova | Retrieval system and method of searching information in the Internet |
| US20090193012A1 (en) * | 2008-01-29 | 2009-07-30 | James Charles Williams | Inheritance in a Search Index |
| US8429196B2 (en) * | 2008-06-06 | 2013-04-23 | Oracle International Corporation | Fast extraction of scalar values from binary encoded XML |
| US8407209B2 (en) * | 2008-07-23 | 2013-03-26 | Oracle International Corporation | Utilizing path IDs for name and namespace searches |
| US7958112B2 (en) | 2008-08-08 | 2011-06-07 | Oracle International Corporation | Interleaving query transformations for XML indexes |
| US8676841B2 (en) | 2008-08-29 | 2014-03-18 | Oracle International Corporation | Detection of recurring non-occurrences of events using pattern matching |
| US8126932B2 (en) * | 2008-12-30 | 2012-02-28 | Oracle International Corporation | Indexing strategy with improved DML performance and space usage for node-aware full-text search over XML |
| US8219563B2 (en) * | 2008-12-30 | 2012-07-10 | Oracle International Corporation | Indexing mechanism for efficient node-aware full-text search over XML |
| US8352517B2 (en) | 2009-03-02 | 2013-01-08 | Oracle International Corporation | Infrastructure for spilling pages to a persistent store |
| US8145859B2 (en) | 2009-03-02 | 2012-03-27 | Oracle International Corporation | Method and system for spilling from a queue to a persistent store |
| US8387076B2 (en) | 2009-07-21 | 2013-02-26 | Oracle International Corporation | Standardized database connectivity support for an event processing server |
| US8321450B2 (en) | 2009-07-21 | 2012-11-27 | Oracle International Corporation | Standardized database connectivity support for an event processing server in an embedded context |
| US8527458B2 (en) | 2009-08-03 | 2013-09-03 | Oracle International Corporation | Logging framework for a data stream processing server |
| US8386466B2 (en) | 2009-08-03 | 2013-02-26 | Oracle International Corporation | Log visualization tool for a data stream processing server |
| US9305057B2 (en) | 2009-12-28 | 2016-04-05 | Oracle International Corporation | Extensible indexing framework using data cartridges |
| US8959106B2 (en) | 2009-12-28 | 2015-02-17 | Oracle International Corporation | Class loading using java data cartridges |
| US9430494B2 (en) | 2009-12-28 | 2016-08-30 | Oracle International Corporation | Spatial data cartridge for event processing systems |
| US8930332B2 (en) * | 2010-03-12 | 2015-01-06 | Salesforce.Com, Inc. | Method and system for partitioning search indexes |
| US8713049B2 (en) | 2010-09-17 | 2014-04-29 | Oracle International Corporation | Support for a parameterized query/view in complex event processing |
| US9189280B2 (en) | 2010-11-18 | 2015-11-17 | Oracle International Corporation | Tracking large numbers of moving objects in an event processing system |
| US9015226B2 (en) | 2011-01-06 | 2015-04-21 | Oracle International Corporation | Techniques for detecting new browser windows |
| US8892635B2 (en) | 2011-01-06 | 2014-11-18 | Oracle International Corporation | Techniques for detecting inactive browser windows |
| US8886592B2 (en) | 2011-01-20 | 2014-11-11 | Kent W. Huff | Efficient genealogy registry system |
| US9424236B2 (en) | 2011-04-26 | 2016-08-23 | Oracle International Corporation | Filtered Stylesheets |
| US8990416B2 (en) | 2011-05-06 | 2015-03-24 | Oracle International Corporation | Support for a new insert stream (ISTREAM) operation in complex event processing (CEP) |
| US9329975B2 (en) | 2011-07-07 | 2016-05-03 | Oracle International Corporation | Continuous query language (CQL) debugger in complex event processing (CEP) |
| US9250872B2 (en) | 2011-10-19 | 2016-02-02 | Oracle International Corporation | Task flow interface in a popup region |
| JP2013174500A (en) * | 2012-02-24 | 2013-09-05 | Shimadzu Corp | Analysis information management system |
| US11487707B2 (en) * | 2012-04-30 | 2022-11-01 | International Business Machines Corporation | Efficient file path indexing for a content repository |
| US11288277B2 (en) | 2012-09-28 | 2022-03-29 | Oracle International Corporation | Operator sharing for continuous queries over archived relations |
| US9563663B2 (en) | 2012-09-28 | 2017-02-07 | Oracle International Corporation | Fast path evaluation of Boolean predicates |
| US8914356B2 (en) | 2012-11-01 | 2014-12-16 | International Business Machines Corporation | Optimized queries for file path indexing in a content repository |
| US10956422B2 (en) | 2012-12-05 | 2021-03-23 | Oracle International Corporation | Integrating event processing with map-reduce |
| US9323761B2 (en) | 2012-12-07 | 2016-04-26 | International Business Machines Corporation | Optimized query ordering for file path indexing in a content repository |
| US10298444B2 (en) | 2013-01-15 | 2019-05-21 | Oracle International Corporation | Variable duration windows on continuous data streams |
| US9098587B2 (en) | 2013-01-15 | 2015-08-04 | Oracle International Corporation | Variable duration non-event pattern matching |
| US9390135B2 (en) | 2013-02-19 | 2016-07-12 | Oracle International Corporation | Executing continuous event processing (CEP) queries in parallel |
| US9047249B2 (en) | 2013-02-19 | 2015-06-02 | Oracle International Corporation | Handling faults in a continuous event processing (CEP) system |
| WO2014175880A1 (en) * | 2013-04-24 | 2014-10-30 | Empire Technology Development Llc | Computing devices with multi-layer file systems |
| US9418113B2 (en) | 2013-05-30 | 2016-08-16 | Oracle International Corporation | Value based windows on relations in continuous data streams |
| US9934279B2 (en) | 2013-12-05 | 2018-04-03 | Oracle International Corporation | Pattern matching across multiple input data streams |
| US9244978B2 (en) | 2014-06-11 | 2016-01-26 | Oracle International Corporation | Custom partitioning of a data stream |
| US9712645B2 (en) | 2014-06-26 | 2017-07-18 | Oracle International Corporation | Embedded event processing |
| US9886486B2 (en) | 2014-09-24 | 2018-02-06 | Oracle International Corporation | Enriching events with dynamically typed big data for event processing |
| US10120907B2 (en) | 2014-09-24 | 2018-11-06 | Oracle International Corporation | Scaling event processing using distributed flows and map-reduce operations |
| US10691299B2 (en) | 2014-09-25 | 2020-06-23 | Oracle International Corporation | Display of hierarchical datasets using high-water mark scrolling |
| WO2017018901A1 (en) | 2015-07-24 | 2017-02-02 | Oracle International Corporation | Visually exploring and analyzing event streams |
| US10866963B2 (en) | 2017-12-28 | 2020-12-15 | Dropbox, Inc. | File system authentication |
| CN111723050A (en) * | 2019-03-22 | 2020-09-29 | 伊姆西Ip控股有限责任公司 | Method, electronic device and computer program product for file management |
| US11803577B1 (en) * | 2021-08-13 | 2023-10-31 | Amazon Technologies, Inc. | Parent/child document indexing |
Family Cites Families (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2001390C (en) * | 1988-12-19 | 1997-12-30 | Ming-Chien Shan | View composition in a data-base management system |
| US5369763A (en) * | 1989-02-01 | 1994-11-29 | Kansas State University Research Foundation | Data storage and retrieval system with improved data base structure |
| US5410691A (en) * | 1990-05-07 | 1995-04-25 | Next Computer, Inc. | Method and apparatus for providing a network configuration database |
| JPH04124774A (en) * | 1990-09-14 | 1992-04-24 | N T T Data Tsushin Kk | Data storage method for hierarchical construction in related data base |
| US5210686A (en) * | 1990-10-19 | 1993-05-11 | International Business Machines Corporation | Multilevel bill of material processing |
| US5454101A (en) * | 1992-09-15 | 1995-09-26 | Universal Firmware Industries, Ltd. | Data storage system with set lists which contain elements associated with parents for defining a logical hierarchy and general record pointers identifying specific data sets |
| AU5670394A (en) * | 1992-11-23 | 1994-06-22 | Paragon Concepts, Inc. | Computer filing system with user selected categories to provide file access |
| US5467471A (en) * | 1993-03-10 | 1995-11-14 | Bader; David A. | Maintaining databases by means of hierarchical genealogical table |
| EP0707725B1 (en) * | 1993-07-07 | 1997-01-29 | EUROPEAN COMPUTER-INDUSTRY RESEARCH CENTRE GmbH | Database structures |
| US5530849A (en) * | 1993-08-16 | 1996-06-25 | Cornell Research Foundation, Inc. | Method of reading dynamic, hierarchical file system directories |
| JPH0785102A (en) * | 1993-09-20 | 1995-03-31 | Hitachi Ltd | Document retrieving method |
| JP3053153B2 (en) * | 1993-09-20 | 2000-06-19 | 株式会社日立製作所 | How to start application of document management system |
| US5524240A (en) * | 1994-05-24 | 1996-06-04 | Panasonic Technologies, Inc. | Method and apparatus for storage and retrieval of handwritten information |
| US5838965A (en) * | 1994-11-10 | 1998-11-17 | Cadis, Inc. | Object oriented database management system |
| US6182121B1 (en) * | 1995-02-03 | 2001-01-30 | Enfish, Inc. | Method and apparatus for a physical storage architecture having an improved information storage and retrieval system for a shared file environment |
| US5842212A (en) * | 1996-03-05 | 1998-11-24 | Information Project Group Inc. | Data modeling and computer access record memory |
| US6208993B1 (en) * | 1996-07-26 | 2001-03-27 | Ori Software Development Ltd. | Method for organizing directories |
| US6137499A (en) * | 1997-03-07 | 2000-10-24 | Silicon Graphics, Inc. | Method, system, and computer program product for visualizing data using partial hierarchies |
| US5917492A (en) * | 1997-03-31 | 1999-06-29 | International Business Machines Corporation | Method and system for displaying an expandable tree structure in a data processing system graphical user interface |
| US5921582A (en) * | 1997-05-28 | 1999-07-13 | Gusack; Mark David | Indexing system, record structure, and linking methodology for paper-based and electronic-based informational assemblies |
| GB2329044B (en) * | 1997-09-05 | 2002-10-09 | Ibm | Data retrieval system |
| US5974407A (en) * | 1997-09-29 | 1999-10-26 | Sacks; Jerome E. | Method and apparatus for implementing a hierarchical database management system (HDBMS) using a relational database management system (RDBMS) as the implementing apparatus |
| US6192273B1 (en) * | 1997-12-02 | 2001-02-20 | The Cleveland Clinic Foundation | Non-programmable automated heart rhythm classifier |
| US6101500A (en) * | 1998-01-07 | 2000-08-08 | Novell, Inc. | System and method for managing objects in a hierarchical data structure |
| US6192373B1 (en) * | 1998-05-15 | 2001-02-20 | International Business Machines Corp. | Managing directory listings in a relational database |
| US6112209A (en) * | 1998-06-17 | 2000-08-29 | Gusack; Mark David | Associative database model for electronic-based informational assemblies |
| US6279007B1 (en) * | 1998-11-30 | 2001-08-21 | Microsoft Corporation | Architecture for managing query friendly hierarchical values |
-
1999
- 1999-02-18 US US09/251,757 patent/US6427123B1/en not_active Expired - Lifetime
-
2000
- 2000-02-17 EP EP00914598.8A patent/EP1145143B1/en not_active Expired - Lifetime
- 2000-02-17 WO PCT/US2000/003967 patent/WO2000049533A2/en active IP Right Grant
- 2000-02-17 JP JP2000600202A patent/JP2003505748A/en active Pending
- 2000-02-17 CA CA002359880A patent/CA2359880C/en not_active Expired - Lifetime
- 2000-02-17 AU AU35967/00A patent/AU762942B2/en not_active Expired
-
2002
- 2002-05-28 US US10/171,728 patent/US6571231B2/en not_active Expired - Lifetime
-
2010
- 2010-02-18 JP JP2010033855A patent/JP2010152916A/en active Pending
-
2011
- 2011-04-12 JP JP2011088245A patent/JP5373846B2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| AU3596700A (en) | 2000-09-04 |
| JP2010152916A (en) | 2010-07-08 |
| JP2011187068A (en) | 2011-09-22 |
| EP1145143B1 (en) | 2014-04-09 |
| JP5373846B2 (en) | 2013-12-18 |
| EP1145143A2 (en) | 2001-10-17 |
| WO2000049533A3 (en) | 2001-07-05 |
| US6571231B2 (en) | 2003-05-27 |
| JP2003505748A (en) | 2003-02-12 |
| AU762942B2 (en) | 2003-07-10 |
| WO2000049533A2 (en) | 2000-08-24 |
| US6427123B1 (en) | 2002-07-30 |
| US20030037056A1 (en) | 2003-02-20 |
| CA2359880A1 (en) | 2000-08-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2359880C (en) | Hierarchical indexing for accessing hierarchically organized information in a relational system | |
| US9898545B2 (en) | Path-caching mechanism to improve performance of path-related operations in a repository | |
| CA2462300C (en) | Providing a consistent hierarchical abstraction of relational data | |
| JP2708331B2 (en) | File device and data file access method | |
| US7366708B2 (en) | Mechanism to efficiently index structured data that provides hierarchical access in a relational database system | |
| US7047253B1 (en) | Mechanisms for storing content and properties of hierarchically organized resources | |
| AU739236B2 (en) | File system interface to a database | |
| EP1604261B1 (en) | Type path indexing | |
| AU2004203241B2 (en) | Internet file system | |
| US20060129584A1 (en) | Performing an action in response to a file system event | |
| AU2002334747A1 (en) | Providing a consistent hierarchical abstraction of relational data | |
| AU2002334721A1 (en) | An index structure to access hierarchical data in a relational database system | |
| CA2461871C (en) | An efficient index structure to access hierarchical data in a relational database system | |
| US7280995B1 (en) | On-the-fly format conversion | |
| US7627547B2 (en) | Processing path-based database operations | |
| US7028037B1 (en) | Operators for accessing hierarchical data in a relational system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20200217 |