The disclosures herein relate generally to databases and more particularly to methods and apparatus for storing and accessing information in content management systems.
Conventional content management systems, such as that shown in
One approach employed to store items in a content management system is to model an item in a single table. Unfortunately, such a single table approach results in many fields among the rows and columns of the table being unused. Such an approach is inefficient from the storage viewpoint. In the past, flat data models have been used to store data in a content management system. For example,
What is needed is a methodology and apparatus for providing a superior manner of storing and retrieving information in a content management system through the use of improved table structures.
The disclosure herein involves a content management system which employs a hierarchical item type tree-based structure including tables at different levels to store metadata for items. A principal advantage of the embodiment disclosed herein is the ability to create an item as a complex tree-based hierarchical data structure wherein the number of child table component types horizontally and the number of child table component types vertically are initially unknown. Advantageously, multiple levels of components in a tree-based hierarchical structure for an item may be created by a single application programming interface (API) invocation, as opposed to multiple invocations which require substantially more user effort.
In one embodiment of the disclosed technology, a method is provided for organizing information in a content management system. The system includes a stored procedure which receives a first input that indicates a number of tables to be created horizontally in a tree-based data storage hierarchy. The stored procedure receives a second input which indicates a number of tables to be created vertically in the tree-based data storage hierarchy. The system then creates the specified the tree-based data storage hierarchy including a root table and at least one child table. The tree-based data storage hierarchy thus created includes the number of tables previously indicated horizontally and vertically.
Content management system 10 employs a hierarchical “item type” tree structure including a group of component tables at different levels to store metadata for items. A “Create Tree Hierarchy” stored procedure 35 in library server 25 is used to build a tree-based data storage hierarchy of tables according to input provided by client 15. Significant flexibility is provided to the client user in terms of the number of horizontal child tables or vertical child tables (or levels) for which creation can be requested. A single invocation of this stored procedure will create the entire requested tree hierarchy saving a substantial amount of network communication time.
The library server data model employed in content management system 10 is shown in FIG. 3A and FIG. 3B. More particularly,
A tree hierarchy having a number of child component types horizontally and a number of child component types vertically has been described above. A child table may be connected to a parent or root table above by a component ID that points back to the parent or root. Such a component ID is referred to as a foreign key in this tree structure.
To recapitulate, an item in the data model employed in content management system 10 includes a tree-based hierarchical structure of components. The relationship among the components within an item is established by a root component type and zero (or multiple) child component types in the tree structure. In this particular embodiment, each component is implemented by a DB2 relational database table. An item identified by an item ID has its attribute value stored in a root component table and in zero to multiple child component tables. In this embodiment, one and only one root component instance is created at the time the item is created. Child component instances may be required depending on a cardinality range predefined by a system administrator who provides this cardinality range information as input to system 10 from client 15. Each child component may itself be a parent component for other child component instances.
Stored procedure 35 operates in response to client input to create an item of a complex object, namely a tree-based hierarchy in library server 25. Stored procedure 35 allows the creation of a tree structure including any number of child component types in a tree horizontally. Stored procedure 35 also allows the creation of a tree structure including any number of child component types in a tree vertically. The topology of the tree structure is thus specified. Advantageously, stored procedure 35 can achieve creation of the described tree structure in one API invocation.
As a prelude to a later presented flowchart and representative stored procedure source code, it is noted that the disclosed methodology provides nested and recursive data structures starting from the root component. The root component structure includes the attribute values, the number of child types and a pointer to an array of the child type structures. Each child type structure includes the component type ID, the number of component structures in array, as well as a pointer to the array of the child component structures. Each child component structure is an instance of a component and it contains the attribute values, the number of the next level of child types in array and a pointer to the array of the next level of child type structures using a recursive mechanism. When the number of child types is zero, this implies that this component instance is an end node of the tree and processing of the tree structure is complete.
The nested and recursive data structures employed to create an item exhibiting the above described tree-based data hierachry are now discussed with reference to the flow chart of FIG. 5. This flow chart describes the operation of the CreateItem stored procedure 35. The names of the functions, variables and operations in the flow chart are selected to coincide with their individual purposes and functions in C language to facilitate understanding. Process flow starts at block 300 where creation of a hierarchical structure item commences. The system, by the action of stored procedure 35, then gets or fetches the ItemTypeID, the CompTypeID and a RootComponentStruct. It is noted that there is one ComponentStruct in Array.
Process flow then continues to a loop established by block 305 which loops through all ComponentStructs in Array. For each of these ComponentStructs the stored procedure gets the #OfAttributes (i.e. the number of attributes) and AtttributeValueStruct. A row is then inserted into Component Table. The stored procedure then gets or fetches the #OfChildTypes in Array and gets Array of ChildTypeStruct. A determination is then made at decision block 310 to see if the #OfChildTypes has reached zero as we proceed through loop 305. If the #OfChildTypes has reached zero then process flow stops as per block 315 and the creation of the Item with its hierarchical tree structure is now complete. However, if the #OfChildTypes is not zero, then process flow contiuues to another loop 320.
Loop 320 loops through all ChildTypes in Array. Within the ChildType Struct, the stored procedure gets or fetches the CompTypeID, the ParentCompTypeID, the #OfComponentStruct in Array and also fetches Array of ComponentStruct. Process flow then continues back to loop 305 after which the test at block 310 is again conducted. Once the #OfChildTypes=0, process flow stops and creation of the Item in its tree-based hierarchical form is complete.
Representative commented C language source code for performing the operations described generally in the flow chart of
The above nested and recursive data structures are implemented by stored procedure 35 in library server 25 to permit a client application 17 to be able to create a content management system “item” with any number of the component instances in a tree structure hierarchy of component tables horizontally and vertically by a single API invocation. This provides a very significant convenience for the user in constructing a complex tree-based hierarchy for storing data.
From a root component instance or any parent component instances, specifying the number of child types and providing an array of child type structures, library server 25 will loop through the child type structures specified in the array to process the insertion of the component instances into the corresponding component tables. This nested data structure allows any number of child component tables to be processed horizontally.
For each child table, specifying the number of the components to be created and providing an array of component structures, the library server will loop through the number of components, using the attribute values in each structure of the array to create a component instance. Multiple child component instances can be inserted based on the number of components specified for each child type. After each child component is inserted, the next level of child types can be repeated and recursively specified. The implementation of the repetitive and recursive data structures will be able to achieve the creation of any number of the component instances within a child type and any number of next level child types within a component vertically.
The disclosed content management methodology and apparatus advantageously solves the problem of creating a complex tree-based table data hierarchy with horizontal and vertical dimensions by a single invocation of a stored procedure by the client. The content management system can be stored on virtually any computer-readable storage media, such as CD, DVD and other magnetic and optical media in either compressed or non-compressed form. Of course, it can also be stored on a server computer system or other information handling system.
Although illustrative embodiments have been shown and described, a wide range of modification, change and substitution is contemplated in the foregoing disclosure and in some instances, some features of an embodiment may be employed without a corresponding use of other features. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the embodiments disclosed herein.
Number | Name | Date | Kind |
---|---|---|---|
4751740 | Wright | Jun 1988 | A |
4868733 | Fujisawa et al. | Sep 1989 | A |
4969091 | Muller | Nov 1990 | A |
5615337 | Zimowski et al. | Mar 1997 | A |
5644768 | Periwal et al. | Jul 1997 | A |
5742810 | Ng et al. | Apr 1998 | A |
5752243 | Reiter et al. | May 1998 | A |
5774719 | Bowen | Jun 1998 | A |
5778398 | Nagashima et al. | Jul 1998 | A |
5799310 | Anderson et al. | Aug 1998 | A |
5819252 | Benson et al. | Oct 1998 | A |
5862378 | Wang et al. | Jan 1999 | A |
5875332 | Wang et al. | Feb 1999 | A |
5892902 | Clark | Apr 1999 | A |
5920867 | Van Huben et al. | Jul 1999 | A |
5940616 | Wang | Aug 1999 | A |
6012067 | Sarkar | Jan 2000 | A |
6016394 | Walker | Jan 2000 | A |
6047291 | Anderson et al. | Apr 2000 | A |
6055637 | Hudson et al. | Apr 2000 | A |
6063133 | Li et al. | May 2000 | A |
6065117 | White | May 2000 | A |
6067414 | Wang et al. | May 2000 | A |
6088524 | Levy et al. | Jul 2000 | A |
6104393 | Santos-Gomez | Aug 2000 | A |
6128621 | Weisz | Oct 2000 | A |
6148342 | Ho | Nov 2000 | A |
6161182 | Nadooshan | Dec 2000 | A |
6167405 | Rosensteel, Jr. et al. | Dec 2000 | A |
6173400 | Perlman et al. | Jan 2001 | B1 |
6219826 | De Pauw et al. | Apr 2001 | B1 |
6233586 | Chang et al. | May 2001 | B1 |
6263313 | Milsted et al. | Jul 2001 | B1 |
6263342 | Chang et al. | Jul 2001 | B1 |
6272488 | Chang et al. | Aug 2001 | B1 |
6279111 | Jensenworth et al. | Aug 2001 | B1 |
6282649 | Lambert et al. | Aug 2001 | B1 |
6289344 | Braia et al. | Sep 2001 | B1 |
6289458 | Garg et al. | Sep 2001 | B1 |
6292936 | Wang | Sep 2001 | B1 |
6308274 | Swift | Oct 2001 | B1 |
6314449 | Gallagher et al. | Nov 2001 | B1 |
6327629 | Wang et al. | Dec 2001 | B1 |
6338056 | Dessloch et al. | Jan 2002 | B1 |
6339777 | Attaluri et al. | Jan 2002 | B1 |
6343286 | Lee et al. | Jan 2002 | B1 |
20010002486 | Kocher et al. | May 2001 | A1 |
20010008015 | Vu et al. | Jul 2001 | A1 |
20010019614 | Madoukh | Sep 2001 | A1 |
20040133848 | Hunt et al. | Jul 2004 | A1 |
Number | Date | Country |
---|---|---|
WO 9922362 | May 1999 | WO |
Number | Date | Country | |
---|---|---|---|
20030204537 A1 | Oct 2003 | US |