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/21—Design, administration or maintenance of databases
  • G06F16/211—Schema design and management
  • G06F16/212—Schema design and management with details for data modelling support
• • 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/24—Querying
  • G06F16/245—Query processing
  • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F40/00—Handling natural language data
  • G06F40/10—Text processing
  • G06F40/166—Editing, e.g. inserting or deleting
  • G06F40/174—Form filling; Merging
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F40/00—Handling natural language data
  • G06F40/10—Text processing
  • G06F40/166—Editing, e.g. inserting or deleting
  • G06F40/177—Editing, e.g. inserting or deleting of tables; using ruled lines
• • 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/953—Organization of data
  • Y10S707/956—Hierarchical
• • 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/953—Organization of data
  • Y10S707/961—Associative
• • 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/99941—Database schema or data structure
  • Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation

Definitions

• This invention relates to the field of computer software. More specifically the invention relates to an improved method and apparatus for structuring, maintaining, and using families of data.
• a detailed arrangement groups items according to the category value and other criteria. For example, products in a certain category, such as paintbrushes, may also be grouped by manufacturer. These groupings are referred to as families. Generally speaking, a family can be defined as a group of records, in a table, related by one or more common fields having the same value.
• Families may also have additional fields of common information, such as images, logos paragraphs of descriptive text, bullets of specifications, and other data. Families provide a way of identifying groupings by fixing one or more common fields and/or attribute values.
• Existing methods use data structures to store and retrieve these families of records. However, these methods present several problems with defining structures. To educate the reader, a brief description of some of the problems with arranging records in families follows.
• a taxonomy provides for the partitioning of a table and its records into multiple categories, with or without a hierarchy, along with the assignment of attributes to each of a number of categories.
• Table 1 a taxonomy is used where a table and its records are partitioned into categories, with or without a hierarchy, where each category comprises a set of common attributes.
• a category's attributes may not be physically part of a record but instead can be considered part of the definition of the record, where the record contains a reference to the category.
• the taxonomy provides an example of a category hierarchy with five categories, a root category (a node that has no parent), identified as "Printers”, and four remaining child (and leaf node) categories associated with the "Printers" category.
• the "Printers” category may have two attributes "ppm” and "color”.
• the first table defines categories within the taxonomy.
• the category table includes a "Parent ID” field that may be used to define a hierarchy and, more particularly, a category's level within a category hierarchy.
• An attributes table (Table 2) defines attributes that may be included in a category.
• Table 3 a feature-values table, may be used to define enumerated values of an attribute of the attributes table. In the example, the feature values table identifies two enumerated values for the "color" attribute.
• Table 4 a category-attribute table, identifies the attributes that are associated with a record of the category table. Inheritance may be used to allow child categories to inherit attributes that are associated with a parent category.
• the families, in the examples, will be defined by the combination of manufacturer and category.
• the fifth table (Table 5) shows a list of data entries for printers.
• the "Position" field identifies a position within a hierarchical level for a given category.
• Each of the records in a uniform fields table i.e., Table 5) references a category record in the category table (Table 1) that defines additional data elements (or attributes) of the referencing record.
• the "table per family” approach partitions the records into families by storing the records of each family in its own table (e.g., Tables 6-11).
• the "table lookup" approach typically requires three steps. First, a table containing a record for each of the families must be created (e.g., Table 12). Second, a lookup field for the family must be added to the partitioning table. Third, the identifier (ID) of the proper family record, in the family table, must be placed into this field for each record of the partitioning table to create a relationship between each record and its corresponding family (e.g., Table 13).
• the related records in a family have the same fixed values for a set of field values, they can be identified by a query specifying these common values. This query can be stored and later referenced to identify and locate the records for the family.
• This approach also has several shortcomings.
• Another common data storage problem concerns the need of a database to store fields of common information that relate to a family of related records rather than just a single record.
• the challenge is to store information in a way that is efficient, easy to implement for existing data, and easy to maintain, as additional records are added to the database.
• the "Multi-Table” approach is consistent with the relational data model and uses multiple tables to store related information.
• the primary table stores the specific information about each main table record while a lookup table contains a record for each family that stores the fields of common information. Records in the tables are linked by placing an identifier in both tables that links each record in the primary table to the corresponding record in the lookup table.
• the advantage of this approach is that the common data values are stored only once in a single record in the lookup table, eliminating duplication and saving space; additionally, changes to the single copy of the common information are automatically reflected in all the records of a family.
• a third aspect related to data storage and retrieval relates to publishing catalogs of product information in paper and electronic media.
• Publishing catalogs of product information in paper and electronic media historically has been two very different and distinct processes, with a very different level and type of effort involved, and very different standards and expectations for quality.
• the challenge is to eliminate the distinctions between paper and electronic output and combine the best of both media in a way that brings to electronic catalogs the structure and high standard of quality typical of paper catalogs and, at the same time, dramatically reduces the cost of laying out paper catalogs by flexibly, programmatically, and automatically generating page layouts in real time.
• electronic catalog pages are typically database-driven and generated programmatically in real-time. Since page layouts do not actually exist until the electronic catalog page is displayed, new products can be added and old products removed without disturbing the system or the published output.
• the downside of this flexibility is that automatically generated electronic catalog pages are usually no more than wide, ugly, "spreadsheet-style" tables of data with redundant information, very little structure, and none of the sophisticated tabular layout formats that are standard for paper pages.
• category-specific attributes and a large number of categories it is even more impractical to have a customized hand-coded display for each family, so generic unstructured presentations are even more the norm.
• the invention is a method and apparatus for structuring, maintaining, and using families of data.
• Each family of data represents a group of records in a database table. Records in a group of records related by one or more common field values.
• the fields and attributes are combined to construct family items.
• Each family item is stored in a family table (or partitioning table).
• a family item refers to one field value item or to a combination of field values.
• Each family possesses a description and is characterized by the values of the fields it comprises. Fields used to construct families possess relationships with each other. Using these relationships, one is able to link field values in a hierarchy.
• a hierarchy can be defined when a group of records (having a set of field values) comprises all the characteristics of a second group of records, and further comprises one or more extra field values.
• the first group is called the parent family and the second one is called the child family.
• An embodiment of the invention uses the fields to generate taxonomy, where each family is identified through a combination of a unique set of field values.
• An embodiment of the invention uses family identifiers to label each record in the family table with a unique identifier.
• the identifiers are also used to populate a field, in the table, reserved for holding the identifier of the parent family, thus allowing for traversing hierarchical trees in both ascending and descending orders.
• Embodiments of the invention partition the records of a table according to the set of families constructed. Partitioning the table records may be performed by setting the value of a field, reserved for the purpose, to a the value of the family to which the record belongs.
• the invention offers means to manage and update family structures.
• embodiments of the invention may reconstruct the family structure upon insertion or deletion of one or more records in the database partition table.
• the invention offers methods to enhance data retrieval, and allows for dynamically changing the data structure for database output.
• An embodiment, of the invention provides means for storing formatting data along with the data in the database. In this case, database driven document generation depends more on the formatting stored in the database and less on the rendering programs that generate the documents.
• Figure 1 is a diagram illustrating how lists of field values can be arranged in a hierarchical structure to build partitioning families in an embodiment of the invention.
• Figure 2 shows a flowchart diagram illustrating the overall steps involved the method of building the family-based partitions in an embodiment of the invention.
• Figure 3 shows a flowchart illustrating the steps involved in obtaining family items from one or more sets of field values in an embodiment of the invention.
• Figure 4 shows a flowchart illustrating the steps involved in building a hierarchy between family items in an embodiment of the invention.
• Figure 5 shows a flowchart illustrating the steps involved in automatically updating the family partitioning in an embodiment of the invention.
• Figure 6 shows a flowchart illustrating the steps involved in obtaining a family item from a record in the partitioning table in an embodiment of the invention.
• Figure 7 shows a flowchart illustrating the steps involved in obtaining all the records for a given family item in an embodiment of the invention.
• An embodiment of the invention comprises a method and apparatus for structuring, mamtaining, and using families of data.
• numerous specific details are set forth to provide a more thorough description of embodiments of the invention. It will be apparent, however, to one skilled in the art, that the invention may be practiced without these specific details. In other instances, well known features have not been described in detail so as not to obscure the invention. A description of some relevant database terminology can be found in Section A.
• Each family of data represents a group of records in a database table that are related by one or more common field having the same value, and that may also have additional fields of common information (e.g., images, logos paragraphs of descriptive text, bullets of specifications and other data). Families are used to partition the records in a database.
• a partition is the division of a group of records into one or more subgroups, each of which is defined by a set of records from that group that have a fixed set of values for one or more field values.
• the partition is specified by the set of fields whose values or value combinations will define the subgroups.
• Each field can include category specific attributes.
• the main table of records that is to be divided into partitions is divided according to a partitioning table.
• the existing taxonomy (e.g., classification structure) in a database is assumed. Further information about family structures can be found in patent application entitled "DATA INDEXING USING BIT VECTORS", U.S. Serial Number 09/643,207, which is incorporated herein by reference.
• the taxonomy represents the partitioning of a table into multiple categories, with or without a hierarchical structure, along with the assignment of attributes to each category.
• a category is a subset of the records of a table that has a set of common field values or combination thereof. Each record in a table belongs to exactly one category.
• Embodiments of the invention take advantage of the fact that each family is defined by fixing a set of common values for one or more fields.
• FIG. 1 is a diagram illustrating how lists of field values can be arranged in a hierarchical structure to build partitioning families in an embodiment of the invention.
• P 0 110 is the root node in the tree.
• P 0 110 may for example be a field describing a set of records in the database.
• all printers possess a "Printer" designation.
• the designation "Printer” is used as a root in a hierarchy of families to specify that all products contained in the hierarchy must be printers.
• the list of field values 100 are selected by a user, or automatically generated using the data records present in the database.
• the lists of field values are used to build families in a hierarchy. Each field value may be a node in the hierarchy tree.
• Color, Laserjet and Printer are descriptions of a product combined to build the family of "Color laserjet printer”.
• Another example of a family is "Color inkjet printer”.
• Each path of the hierarchy tree may be used as an entry in a family table that is also referred as the partitioning table of the partitioning hierarchy.
• a partitioning hierarchy of a partitioning table is a hierarchy in which the nodes of the hierarchy represent partitions of the partitioning table.
• the path 120 is typically a family in the partitioning hierarchy.
• some tree paths are also considered partitioning nodes (e.g. 130) because of the lack of records matching the family specification.
• the partitioning hierarchy may not include a "network dot matrix printer" family. Therefore, a partitioning node is a node in the partitioning hierarchy that corresponds to a particular family of records.
• the set of records represented by a partitioning node is exactly the set of records represented by combining the sets of records represented by each of the descendants of that partitioning node.
• the root partitioning node represents the entire set of records of the partitioning table; each sub-node represents only those records which have a fixed set of field values defined by the partitions, starting at that sub-node and tracing ancestors back up to the root.
• the entire set of leaf partitioning nodes represents the entire set of records and each record of the partitioning table belongs to one and only one leaf partitioning node.
• a base family will refer to a family that corresponds to a leaf partitioning node.
• the base family set will refer to the complete set of base families that corresponds to the complete set of leaf partitions in a partitioning hierarchy. The base family set is useful because each record of the partitioning table belongs to exactly one base family.
• FIG. 2 shows a flowchart diagram illustrating the overall steps involved the method of building the family-based partitions in an embodiment of the invention.
• step 210 one or more sets of field values are collected. This process may involve user intervention through a user interface (see below, in the example of implementation), an automatic process for determining a set (or sets) of field values or categories (see below, in the example of maintaining family-based partitioning), or a combination of both user input and an automatic process.
• the set (or sets) of field values and categories are used to specify product families. Since a category and field-based taxonomy already exists, it would be beneficial to layer the partitioning hierarchy on top of it, so as to leverage the work already done to create the taxonomy.
• each family item in a set of family items is associated with an identifier (e.g. step 230).
• the identifier allows subsequent location of the family item in the partitioning table, and use of the inheritance tree in the hierarchical partitioning.
• inheritance relationships are defined and implemented.
• an embodiment of the invention uses a descriptor (e.g. a field in a database table) to hold the identifier of the parent in the hierarchy.
• partitions are built using each valid path in the partitioning tree.
• FIG. 3 shows a flowchart illustrating the steps involved in obtaining family items from one or more sets of field values in an embodiment of the invention.
• step 310 one or more sets, containing one or more field values, are loaded through a user interface, or through a process for automatically selecting field values.
• each combination of field values is used to form a database query.
• step 320 the query is submitted to the database.
• the test in step 330 indicates whether a combination of field values have any associated records in the database as a result of the query. If the query points to existing records in the database, the combination of field values is retained and processed to produce a family item in step 340. Otherwise the field values are ignored in step 350.
• step 360 a search is performed to check whether all field values in the sets of fields were processed. The processing continues until all field values in the set are processed. In the case of a hierarchical relationship, this is equivalent to traversing all the possible paths in the hierarchy tree.
• FIG. 4 shows a flowchart illustrating the steps involved in building a hierarchy between family items in an embodiment of the invention.
• each family item is assigned an identifier (see above).
• the identifier of the parent of the node is determined.
• the parent node identifier is associated with the node in step 430, for example, by entering the identifier of the parent in the Parent ID field corresponding to the record of the node.
• a position of the field value in the set of field values is provided.
• the family item is then associated with the position in step 450.
• the partitioning hierarchy is stored as a hierarchical structure.
• An additional table is used to store the fixed field values that define the partitions.
• the table contains fields that provide information on the identifier of the partitioning node, the field value that is being partitioned, and positional information to allow for combining and nesting partitions.
• an additional table is used because there may be multiple fields that define a partition.
• a partition could be defined based on the combination of a field (such as the manufacturer) and an attribute (such as color).
• Table 20 defines the following family partitioning hierarchy:
• Table 21 shows an additional partition layered on the top of the previous taxonomy describing using the manufacturer field.
• the family partitioning hierarchy has the same initial structure of the taxonomy, but additional nodes are added to it. These nodes are created because a partitioning exists at the Printers node that is defined to partition according to manufacturer. This causes all leaf nodes under this node to be further partitioned by manufacturer.
• the initial leaf nodes were Daisy Wheel Printers, Dot Matrix Printers, Inkjet Printers, and Laser Printers. Under each of these, additional nodes will be added for each manufacturer that has products defined by the query constructed by taking all of the criteria defined by the ancestor nodes in the family partitioning hierarchy. Since this is the first partition, the criteria are simply the category for each of the initial leaf nodes. Notice that a node is not added for all manufacturers, only those that correspond to actual records in the database.
• Table 22 defines the following family partitioning hierarchy:
• Table 24 defines the following family partitioning hierarchy:
• Table 25 shows, in addition to the manufacturer partitions from the previous example, a third partition (Color).
• Partitioning by multi-valued fields is given special treatment to ensure that a record belongs to exactly one family.
• the combination of values is treated as a distinct unit when determining the unique set of values for the field. For example, if there was a partition on a multi-valued field of color and one of the records had Blue /Green as the value for that field, then the record would be placed in the Blue /Green family, and not in the Blue family or Green family.
• a query in order to find the records that belong to a particular family, can be constructed by setting constraints for each value from the fixed set of common values for that family. Executing that query will locate a set of records that belong to that family.
• each of the leaf partitioning nodes will differ by at least one value or value combination.
• the queries constructed for each of the base families will also differ by at least one constraint. The result is that each query is guaranteed to return a non-overlapping set of records.
• Databases implementing the method provide support for partitioning based on product families and the product families hierarchy.
• Embodiments of the invention provide for efficient storage for families allowing products to be found from families, and, conversely, families to be found from products.
• the layering of partitioning hierarchy on top of a category based taxonomy leverages existing taxonomies.
• Embodiments of the invention provide a method for automatically creating new families as the set of actual field values is changed.
• Embodiments of the invention provide for ensuring that product records automatically belong to the proper family, even as new records are added and existing records are modified.
• the method provides for the ability to partition at any level in the partitioning hierarchy, so that different nodes within a single partition can be partitioned differently.
• Other embodiments of the invention implement inheritance and the overriding of the inheritance of partition information in the partitioning hierarchy
• Figure 6 shows a flowchart illustrating the steps involved in obtaining a family item from a record in the partitioning table in an embodiment of the invention.
• a process starts at the root node of the family tree in step 610, and identifies the partition field value in step 620.
• the process continues fetching child nodes using the value of partition field value in step 630.
• a relevant child node should have a value equal to the partition field value in the record.
• the process checks that the node is a leaf node in 640. If the node is a leaf node (i.e. has no child nodes), the result of the combination of field values is the family item.
• the search is finished in step 650. Otherwise, the process continues searching for child nodes by traversing the partitioning tree.
• Figure 7 shows a flowchart illustrating the steps involved in obtaining all the records for a given family item in an embodiment of the invention.
• the process of obtaining records in a family involves two major steps: 1) building a list of constraints and 2) running a query with those constraints against a database.
• a list of constraints is built starting with the loading of the family node in step 710.
• the node's parent is fetched, and the value of the partition field value by which the parent node is partitioned is added to the constraint list in step 720.
• the search continues by traversing the tree, searching for each current node's parent in step 730.
• the root node is found by checking each current node tested in step 740.
• a query comprising the list of constraints is ran against the database in step 750. The result of such a query returns the records that are part of the family for which the search started. Maintaining Product Families
• Changes to the taxonomy structure that require updates to the partitioning hierarchy include adding, removing, moving, and modifying a category.
• Changes to the domain of a partitioning field include adding, removing and modifying a field value, while changes to the feature domain for a partitioning attribute include adding, removing and modifying a feature value.
• Embodiments of the invention provide a solution to automatically adjust the partitioning hierarchy when the taxonomy structure, the domain of a partitioning field, or the main table records are modified.
• partitioning hierarchy Since the partitioning hierarchy is layered on top of the taxonomy, changes to the structure of the taxonomy hierarchy require updates to the partitioning hierarchy. In particular, nodes that are added, removed, modified, or moved in the taxonomy must be similarly added, removed, modified, or moved in the partitioning hierarchy. In addition, many of the advanced features for in-place schema and data manipulation such as splitting and merging fields can also require updates to the partitioning hierarchy.
• partitioning hierarchy depends on the existence of values in actual product records
• changes to the main table records may require updates to the partitioning hierarchy.
• new families must be created if the records contain a value not yet used in any of the fields that are used in defining the family partitions.
• the corresponding partitioning node must be removed.
• Modification of a main table record can have effects similar to those of adding a new record or deleting an existing one since a new value assigned to a field or record could be a value not yet used in one of the family partitioning fields and the value replaced could have been the only occurrence of a particular value in the family partitioning field value.
• the merging field values in the taxonomy has the same effect as modifying the main table records by replacing the original filed values with the merged field value and can require updates to the partitioning hierarchy.
• FIG. 5 shows a flowchart illustrating the steps involved in automatically updating the family partitioning in an embodiment of the invention.
• new records are detected (e.g. receiving a data insertion query in by the database, or upon an alteration of existing records). Records are checked in step 520 to test whether a new field value is introduced. If a new field value (relevant to the family partitioning) is detected, the family partitioning is reorganized in step 530.
• the method provides a mechanism for automatically maintaining product families and the partitioning hierarchy. For example, the method provides a mechanism for detecting when the partitioning hierarchy needs to be updated due to modifications of the taxonomy or main table records.
• Partitioning nodes may be created based on the actual set of values and value combinations used in main table records rather than the possible set of values and value combinations.
• the method also provides way to detect if a field value disappears (e.g., upon a deletion of records or alteration of the records in the database).
• the method provides a way to check whether a field value was deleted from the database in step 550. If such event occurs, family partitioning is reorganized to optimize the family partitioning.
• An embodiment of the invention checks user input instructions to modify the family partitioning in step 570. If a user inputs data to modify the family partitioning the latter is reorganized to optimize family partitioning.
• An embodiment of the invention provides an improved solution for storing data, allowing maintenance of all the benefits of the multi-table approach, while eliminating the need for a lookup field in the primary table whose value identifies the identifier of the corresponding record in the lookup table.
• This method simultaneously eliminates the need for the user to manually place the identifier of the lookup record into this lookup field in each primary table record.
• the improved solution layers on top of the family partitioning hierarchy in such a way that the system creates and maintains all of the relationships automatically based on the membership of each group of primary table records in each family in the family hierarchy.
• the user assigns the common information for each family to the families corresponding to leaf nodes of the family hierarchy in the next step.
• records in the primary table have already been grouped together into families and common information is then easily assigned to each family.
• Each new record in the primary table is then automatically linked to the correct common information by virtue of its membership in the proper family.
• the data values are stored in a related, secondary table only on an as-needed basis so that, like attributes, they only take up space if they exist.
• Embodiments of the invention provide for means to easily link common information to families and link common information to each family rather than to the main table records by utilizing the family partitioning hierarchy.
• Other embodiments include automatically creating and maintaining all of the relationships between existing and new main table records and common information based on family membership.
• Embodiments of the invention provide a solution to improve media publishing.
• An embodiment of the invention provides a method for a layer on top of the structure to automatically format and publish data from a database. All of the layout formats that are typically stored in the page layout are captured and stored in the database alongside the product data itself.
• the searchable, database-driven electronic catalog can not only serve up the product data but also the formatting data.
• the method allows for rendering in real-time by a report writer (such as ASP-generated HTML). The rendering is done independently of data types, even in a catalog with many categories and category-specific attributes.
• the report writer code itself (or HTML) need only handle the preprocessed pivot tables and requires no complex code for pivoting tabular layout formats, no special coding for each category or family, and no intelligence about the underlying data. More information about pivot tables can be found in co-pending patent application entitled “METHOD AND APPARATUS FOR DYNAMICALLY FORMATTING AND DISPLAYING TABULAR DATA IN REAL TIME", filed on September 20 th , 2001, Serial Number to be assigned, which is incorporated herein by reference. Using the structure described in the previous section, electronic catalogs for the first time can now have the density and layout quality of paper catalog pages while maintaining their database-driven search ability.
• Embodiments of the invention provide improved solutions for publishing database content that substantially eliminate the manual process of page layout for publishing paper catalogs. For example, the time and effort invested on defining the appropriate tabular layout formats are substantially reduced, since the tabular layout formats are set only once and do not have to be repeated for each family to publish catalogs.
• the invention provides solutions that automatically generate page layouts by combining product data and formatting data from the database.
• Embodiments of the invention use the API of the page layout program (e.g., for programs such as QuarkXPress or Adobe InDesign), or an intermediate ASCII file format (for programs such as Xyvision XPP) to render pages automatically.
• the invention provides solutions that result in many ways in reducing the publishing cost.
• embodiments of the invention allow changes to the product data to be reflected immediately in subsequently generated output.
• Embodiments of the invention support the on-demand generation of custom catalogs on product subsets with no additional effort.
• Other embodiments of the invention produce a more uniform look throughout the publication, since every page is generated dynamically and automatically by the system.
• each paper publication starts out as a snapshot of the family partitioning hierarchy and its associated formatting information. Any of the formatting specifications, defined and stored in the family partitioning hierarchy and used for electronic catalog publishing, can be changed in any way for each paper publication. This provides almost unlimited flexibility to create custom paper catalogs, each of which is based upon the electronic standard but is laid out in a fashion that is as similar to, or as different from, any other catalog as necessary. In addition, the system offers the following per-publication flexibility:
• a product mask can be applied when the snapshot is taken to limit the set of products appearing in the paper publication, so that each publication can have a different, custom subset of the entire product set (masks can also be applied electronically, and /or search parameters specified, to limit the set of products appearing in electronic output).
• a family can be copied from the family partitioning hierarchy into the publication to include families that were not initially included in the publication.
• Each family can appear in multiple locations in the publication, can be individually formatted, can include a different subset of the columns and common information, and can contain a different subset of the records in the family (by contrast, each family in the family partitioning hierarchy can appear only once, contains a fixed subset of the columns and common information, and contains all of the records). Additional features for paper publishing that allow publication-specific restructuring and reformatting of each family as well as the entire publication are listed in the table below:
• Embodiments of the inventions offer several improved solutions over existing methods for database driven publishing.
• Embodiments of the invention provide means for layering both the electronic and paper publishing process on top of the same extended taxonomy structure for automatically formatting and publishing database data.
• the invention uses tabular layout formats that are captured and stored in the database alongside the product data itself, instead of storing the formatting in the page layout.
• the invention provides means for publishing high-quality output to the web using layout information stored in the database.
• the invention uses the API of the page layout program (or intermediate ASCII file format) to render pages automatically.
• the invention allows for applying a product mask when the publication is first created.
• it also allows the layout detail, column names, set of records, and common information to be individually customized for each family of a particular publication.
• An embodiment of the invention is implemented in a database system to build a catalog manager.
• a detailed description of a catalog manager is provided in Section B. Section A
• a database is a logical collection of interrelated information, managed and stored as a unit.
• a record is a representation of a real-world object such as a person, a product, or a company.
• a record consists of one or more individual data elements.
• a field describes one of the data elements of a record and is common to all the records in a table.
• a table is a simple, rectangular, row/column arrangement of related data values. Each horizontal row in the table represents a single record and consists of the same set of fields. Each vertical column of the table represents one field that is stored for each row in the table.
• a relational database is a database in which all data is organized into tables that may be related by matching columns.
• a hierarchy is a table in which the records have parent/ child relationships.
• a node is another term for a record in a hierarchy.
• the root node of a hierarchy is a node that has no parent.
• An internal node of a hierarchy is a node that has at least one child.
• a leaf node of a hierarchy is a node that has no children.
• An attribute is a data element that is not common to all the records in a table.
• a category is a subset of the records of a table that has a set of common attributes. Each record in a table must belong to exactly one category.
• a taxonomy is the partitioning of a table and its records into multiple categories, with or without hierarchy, along with the assignment of attributes to each of the categories.
• a f mily is a group of records in a table which are related by one or more common fields and /or attributes that have the same value, and which may also have additional fields of common information, such as an image, a logo, a paragraph of descriptive text, bullets of specifications, and so on.
• a partition is the division of a group of records into one or more subgroups, each of which is defined by the set of records from that group that have a fixed set of values for one or more fields and/or attributes.
• the partition is specified by the set of fields and /or attributes whose values or value combinations will define the subgroups.
• the partitioning table is the main table of records that is to be divided into partitions.
• a partitioning hierarchy of a partitioning table is a hierarchy in which the nodes of the hierarchy represent partitions of the partitioning table.
• a partitioning node is a node in the partitioning hierarchy that corresponds to a particular family of records. Since a partition simply divides a group of records into subgroups, the set of records represented by a partitioning node is exactly the set of records represented by combining the sets of records represented by each of the descendants of that partitioning node.
• the root partitioning node represents the entire set of records of the partitioning table; each sub-node represents only those records which have the fixed set of field values defined by the partitions starting at that sub-node and tracing ancestors back up to the root; the entire set of leaf partitioning nodes (or leaf partitions) represents the entire set of records; and each record of the partitioning table belongs to one and only one leaf partitioning node.
• a base family is a family that corresponds to a leaf partitioning node.
• catalogs on that machine The global database is always named A2i_xCat_DBs. Within it is a table that holds the logical or publicly known names of catalogs and the actual database names used for storage. Three databases are used to represent each catalog.
• Thumbnails database that holds the scaled down 200x200 bitmap data of the original imported images.
• Each A2i Database Server may differ from other DB Servers. Any parameters or settings which are modified for an individual DB Server are maintained in the A2i_xCat_DBs database in a settings table.
• DataPath The directory location where DB data files are to be created.
• BackupPath The directory location where backup files are to be created.
• Each Catalog has a table with a single record that is used to hold for state information Server Table
• This table contains the descriptions of all Primary Data Tables.
• Primary Tables have the name _A2i_;c_ where x is a number starting at 1.
• the Primary Tables table has the following name:
• Id fields are assumed to always exist in every primary table and have the field name Id. They are not included in this table.
• the fields table has the following name _A2i_CM_Fields_ All entries refer to fields; there is no need for a null entry.
• FieldType specifies the SQL field types for the primary tables.
• the Field Structure is as follows
• x is the Id specified in the Tableld field of _A2i_CM_Tables_.
• one table is considered the main table with the remainder acting as sub tables used for multi-values, etc.
• Field type 25 (MeasurementField) has an additional field named Ux (where x is the Fieldld) used to specify the type of units used.
• a Mask table is a special type of primary hierarchical table with an additional field called Mask. Following the same rules, it is named: _A2i_ ⁇ r_ This additional Mask field stores the bits of a Bit Vector to track record Ids in another linked table. It is like a sub-table in that each of the records in this table correspond to multiple records in a linked main table, however the link is stored in this table as a mask instead of in the main table as a category field. For example, a record in the mask table with the mask having bits 1,2 and 10 set means that this record corresponds to records in its linked main table with record ids 1, 2 and 10.
• the mask table entry has a type of
• every mask table has a standard Id field and also has any fields specified for it in the _A2i_CM_Fields_ table.
• the additional Mask field described below, differentiates it from other primary tables.
• a Table of type HierTable and HierAttrTable table relies on an additional table to describe the hierarchy relationship.
• the table is named: _A2i_H_ _ where x is the Tableld of the HierTable or HierAttrTable
• Fields with type 11 (FlatMultiSubTableField), 29 (HierMultiSubTableField), object data fields 13,15,17,19,23,31,32,33 and MultiMeasurementField 37 do not have physical fields in their data table.
• the lookup Ids are stored a separate multi- value table.
• the multi- value tables are named _A2i_xJ_ where x is the Tableld of the table containing a multi-valued field.
• An attribute is a parameter used to classify and describe a record, (i.e. 'screen size' of a monitor). It is similar to a category but only applies to subset of the entire record set. If it applied to all records it would simply be a category. This means that one group of records will have one set of attributes describing them, while another group of records will have completely different attributes describing them.
• An example is 'screen size' of a monitor and 'processor speed' of a computer. Both monitors and computers are records in the same table but they have different attributes describing them.
• Attributes apply to groups of records.
• a group of records is specified by creatmg an Hier AttrSubTableField in the main primary table and setting the value of this field to the Id of a record in a table of type HierAttrTable.
• an Hier AttrSubTableField in the main primary table and setting the value of this field to the Id of a record in a table of type HierAttrTable.
• Hier AttrSubTableField called 'SampleCategoryField' can be created in the main primary table, and another primary table of type HierAttrTable called 'SampleCategory Table' can be created.
• One record in the 'SampleCategoryTable' may be a record describing the 'Monitor' category. Now all records in the main primary table with 'SampleCategoryField' linked to the record describing the 'Monitor' category in 'SampleCategoryTable' are in the Monitor group.
• Attributes are assigned to a group by linking them to a set of records in a table of type HierAttrTable.
• an attribute called 'Screen Size' can be linked to the record in 'SampleCategoryTable' that describes the 'Monitor' category.
• 'Screen Size' can be linked to the record in 'SampleCategoryTable' that describes the 'Monitor' category.
• a Text Attribute is an enumerated list of Text Values. An example is "Valve Type". There is a small finite set of valve types. A Numeric Attribute is continuous. An example is length. Although you could enumerate all lengths in a list of products you gain certain advantages by treating it as Numeric. One is searching by range (not yet implemented). Another is the ability to convert between units (feet to meters). Attribute Definition Tables:
• A2i A x where x is the Tableld of the HierAttrTable that contains all the categories that these attributes are allowed to link to.
• Attributes with lower priorities are shown first. Attributes with the same priority are sorted by Attribute Name.
• _A2i_FV_x_ where x is the Tableld of the HierAttrTable that contains all the categories that these attributes are allowed to link to.
• Featureld should only be unique for records with the same Attrld. Each time the Attrld changes, start Featureld at 0 again. This allows us to use smaller structures to store the Feature Id's in memory resulting in less memory usage and faster searches. Feature Entries Tables
• _A2i_F_x_ where x is the Tableld of the HierAttrTable that contains all the categories that the attributes are allowed to link to.
• a record in this table indicates that for the record matching Id, its Attribute matching Attrld has the Text Value matching Featureld.
• _A2i_C_x_ where x is the Tableld of the HierAttrTable that contains all the categories that the Characteristic Attributes are allowed to link to.
• Coupled Numeric Attribute data This is where all the Coupled Numeric Attribute data is. These tables store pairs of actual Numeric values selected for a particular attribute of a particular record.
• _A__i__CN_x_ where x is the Tableld of the HierAttrTable that contains all the categories that the Characteristic Attributes are allowed to link to.
• CoupledUnits Following is an example of some couples
• Matching sets are a way of associating products in one category with products in another category.
• Nuts and Bolts are two categories.
• the products in the Nuts category match the products in the Bolts category if their Width and Thread Pitch match.
• a matching consists of the two categories and a list of the common attributes that must match for a product to be considered a match.
• the matching set tables store the matching set information.
• the names are the same.
• Families are a way of grouping records by structured queries, then assigning common information to the groups and organizing each group's display of its records. Each group of records is called a family.
• Families are created by Partitioning the records based on a category, then sub- partitioning these groups based on other categories or attributes. With the exception of the first partition, families only exist where the combination of values in the partitioned fields /attribute results in a non-zero set of records.
• the first partition is special in a few ways: l)Its partition field is specified in the _A2i_Server_ table, FamilyCatFieldld 2)It can only be a field, not an attribute, because attribute do not exist at a global level
• the records can be Pivoted by Depth, Vertically or Horizontally. This extracts the values of the pivot field and makes a separate section for records with that value.
• This table holds all the partition, pivot, sorting, ordering and hidden information. Structure is tied to a family node. All children then inherit it, unless the child overrides the inheritance. Children can override each type of structure element individually.
• Partition This determines the hierarchy of the family tree. Only main table lookup fields, and Text Attributes are allowed in the partition. Numeric attributes are not allowed. Every time you add a field /attribute to the partition, you create additional child family nodes below the current child nodes. The records will be split up according to the values they have for the new partition field /attribute.
• Pivot (Depth, Vertical, Horizontal) - This also splits up records into groups, but is used for display only. It does not create new family nodes
• Sorting This specifies which fields /attributes to sort on in the final display. More than one field /attribute can be used. The display will sort first on the first field /attribute, then on the second, etc. Ordering - This is the display order of the fields /attributes in the final display.
• Hidden - This is a list of fields /attributes that should not be displayed.
• Partition and Pivot allow you to concatenate multiple fields at the same level. This has a slightly different effect than placing the fields on different levels.
• a family has 2 attributes available for partitioning, Color(red, blue) and Horsepower(gutless, gas-guzzler). Creating 2 partition levels, the first with Color and the second with Horsepower would look like. red family gutless family gas-guzzler family blue family gutless family gas-guzzler family
• This table holds information about familiy nodes that have been deleted, but had family structure information defined.
• This table holds basic information about the family. It is a global table that applies to the main table in the database.
• This table holds basic information about family nodes that have been deleted, but contained links to common information or structure. This allows users to recover their work when then make a change that destroys these families _A2i_FamilyItemsRecycled_
• This table holds the information describing the partial query for each family node. Every node represents 1 or more criteria. Tracing the node back to the root gives you the entire query.
• Nodes are allowed to have more than 1 field/value combination. This occurs when an ancestors partition specified more than 1 field for the partition's NestedPosition. This node then represents a concatenation of values.
• This Family has the name _A2i_FamilyItemValues_
• ConcatenationPositionEnt 4 not NULL Where in the concatenation of values this value exists. This starts at 0, and continues if more than 1 field are concatenated at this partitions NestedPosition.
• the initial table needs a definition for the ROOT node.
• This table specifies which fields all families have. Just like primary tables, families can have fields. The field values apply to all records in the family.
• This table is like the Attribute _c_ and _f_ table in that if a family item does not have a value set, nothing is stored.
• the organization and structure of large object data (sometime referred to as external or indirect data) is stored in the SQL database.
• the xCat Server does not cache it.
• Each record represents 1 part in a part of locations.
• example is A21US A ⁇ Dave_Of f ice ⁇ sullivanX d$ ⁇ work ⁇ imagesX testlmages
• This table describes a publication, represented as a tree, "x" in the table name corresponds to an entry in the _A2i_CM_Publications_ table.
• This table contains user-defined descriptions of the media type of the item data.
• HasOriginal Bit not NULL, default 0 Specifies whether or not the original pdf is stored in the sql database. If so, there will be a record with the same Datald in the corresponding _A2i_Originals_x_ table which resides in the [DatabaseName] Originals database
• PDF tables have supporting tables in the ⁇ database ⁇ _Originals or ⁇ database ⁇ 0 database.
• the supporting table is _A2i_Originals_x_ where x matches the Id of the main database table
• Image tables have support tables in the ⁇ database ⁇ _Originals and ⁇ database ⁇ __Thumbnails databases.
• the supporting table is _A2i_Originals_x_ where x matches the Id of the main database table
• the supporting table is _A2i_Thumbnails x where x matches the Id of the main database table leld name SQL Field Type Description
• Images in the Catalog Manager can be processed to various specifications and stored.
• An Image Variant is the term used to describe a processed image.
• Variant-Image-Script table There is only one _A2i_Img_VIS_ table in one database. This table stores information about all Variant images.

Priority Applications (1)

Applications Claiming Priority (2)

Publications (2)

Family

ID=22879523

Family Applications (2)

Family Applications Before (1)

Country Status (3)

Cited By (12)

Families Citing this family (181)

Citations (2)

Family Cites Families (15)

• 2001
  • 2001-09-20 US US09/960,902 patent/US6910044B2/en not_active Expired - Lifetime
  • 2001-09-20 US US09/960,541 patent/US7143339B2/en not_active Expired - Lifetime
  • 2001-09-20 AU AU2002214540A patent/AU2002214540A1/en not_active Abandoned
  • 2001-09-20 WO PCT/US2001/029486 patent/WO2002025500A2/en active Search and Examination
  • 2001-09-20 AU AU2002224333A patent/AU2002224333A1/en not_active Abandoned
  • 2001-09-20 WO PCT/US2001/029837 patent/WO2002025471A2/en active Application Filing

Patent Citations (2)

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events