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 a method and apparatus for dynamically formatting and displaying tabular data in real time.
• Presenting data records in tabular form is a well-known way to compactly represent large quantities of information.
• people frequently present data records (e.g., printed or displayed) using tables to convey different kinds of information.
• Product catalogs typically contain a large number of tables representative of the various product alternatives available in the catalog. The following example illustrates
• formatting changes are made (e.g., a row or column is moved, filtered, or sorted), the
• Another problem existing programs for manipulating table data have is that these programs lack a mechanism for dynamically formatting table data in real time.
• RDBMS Relational Database Management Systems
• taxonomy structure e.g., organizational structure
• set of attributes associated with each category which makes the report writer approach difficult to maintain as the taxonomy changes
• catalogs that contain tables of product information. The manner in which catalogs are
• the table is dynamically modified so the users can instantaneously view any changes to
• the table caused by the input e.g., WYSIWYG.
• the system accepts various types of input and upon receipt of that input the system changes the appearance of the table in
• the user may repeatedly modify the table by providing different or additional input and viewing the results of the input.
• the user input e.g., layout information
• the user input relates to various types of pivot operations, sorting operation, and /or merging
• the user may, for example, select a certain field and
• the system is configured in
• the system can manipulate the tabular data set without changing the underlying structure of the data.
• the layout information can also be associated with or dependent on a particular set of tabular data and stored along with that data. In this instance, the layout information is part of a file or set of files related to the tabular data.
• Figure 1 is a flow chart that illustrates the process for enabling systems to implement one or more embodiments of the invention.
• Figure 2 illustrates specific types of layout information in accordance with one or more embodiments of the invention.
• Figure 3 illustrates the components of a graphical user interface configured in accordance with an embodiment of the invention.
• FIG. 4 illustrates a tabular data set before the execution of any pivot operations in accordance with an embodiment of the invention.
• Figure 5 is a flow charts that illustrates the functions executed when a stack pivot, horizontal pivot, or vertical pivot is requested in accordance with an embodiment of the invention.
• Figure 6 illustrates a tabular data set in accordance with an embodiment of the invention after a stack pivot is performed in accordance with an embodiment of the invention.
• Figure 7 illustrates a tabular, data set after a stack pivot and horizontal pivot is performed in accordance with an embodiment of the invention.
• Figure 8 illustrates a tabular data set after a stack pivot, horizontal pivot, and vertical pivot is performed in accordance with an embodiment of the invention.
• FIG. 9 is a generalization of several pivot operations in accordance with an embodiment of the invention.
• the appearance of the tabular data comprises records having a defined association
• table represents a set of records sharing a common value (e.g., a field and/or attribute),
• the invention is not limited to manipulating records sharing a common value and systems embodying the invention
• the table is dynamically modified so the users can instantaneously view any changes to
• the table caused by the input e.g., WYSIWYG.
• the system accepts various types of input and upon receipt of that input the system changes the appearance of the table in
• the user may repeatedly modify the table by providing different or additional input and viewing the results of the input.
• the user input e.g., layout information
• the user may, for example, select a certain field and
• the system is configured in accordance with one embodiment of the invention so
• representation of the records can be presented to the user for modification.
• the system may display a subset of the group of records (e.g., step 102) that may include a visual representation of the records associated with the entire family or a
• records the user may provide the system with layout information (e.g., step 104).
• layout information e.g., step 104.
• the layout information is utilized to rearrange or modify
• This layout information can be stored independent of the data
• the layout information is associated with the table data in that
• the layout information can be any layout information.
• the layout information can be any layout information.
• Some examples of the types of operations defined in the layout information include pivot operation such as stack pivots, horizontal pivots, vertical pivots, sorting information, merging information, inheritance properties, and field and /or attributes
• field name can be used as the basis for one or more pivot operations. The specific characteristics of each pivot operation will be described in further detail below.
• the table is dynamically updated
• the updated table (which may be referred to as a preview table), may contain a less redundant set of
• the layout information obtain from the user to generate the preview table can be saved and optionally associated with the appropriate group of records. This way the layout information obtain from the user to generate the preview table can be saved and optionally associated with the appropriate group of records. This way the layout information obtain from the user to generate the preview table can be saved and optionally associated with the appropriate group of records. This way the layout information obtain from the user to generate the preview table can be saved and optionally associated with the appropriate group of records. This way the layout information obtain from the user to generate the preview table can be saved and optionally associated with the appropriate group of records. This way the layout information obtain from the user to generate the preview table can be saved and optionally associated with the appropriate group of records. This way the layout information obtain from the user to generate the preview table can be saved and optionally associated with the appropriate group of records. This way the layout information obtain from the user to generate the preview table can be saved and optionally associated with the appropriate group of records. This way the layout information obtain from the user to generate the preview table can be saved and optionally associated with the appropriate group of records. This way the
• the user can easily recreate the table without having to provide the same layout information again. If the preview table is to be used by another program (e.g., a publication program), the table can be exported to that program. If, for instance, the user is designing tables for a catalog, the user can provide the finalized table to the catalog
• Figure 2 illustrates specific types of layout information in accordance with one or
• layout information may comprise inheritance properties, pivot values, hidden values, sorting information, merging
• inheritance properties can be defined on a node-by-node basis. Child nodes, for instance, may inherit from higher nodes in the hierarchy.
• systems embodying the invention take into account the inheritance properties when dynamically generating the preview table (e.g., step 202).
• all nodes that are children of a parent node in the extended taxonomy inherit the layout structure defined for each node.
• the inherited structure can be overridden on a node-by-node basis so that different children of a category can have different pivoting, sorting, display sequence, and other pivot-specific sorting and display characteristics. Therefore, inheritance properties provide user with a mechanism for identifying on a node-by-node basis whether that node should inherit any properties.
• pivot operations in accordance with the pivot values are executed (see e.g., steps 204 - 216).
• Any field and/or attribute associated with the group of records in the table can become a pivot value.
• a particular field and/or attribute is identified as a pivot value that value is used during the pivot operation. For example, if a stack pivot value is identified, a stack pivot operation is executed (e.g., steps 206, 208).
• a horizontal pivot value e.g., step 210) or a vertical pivot value (e.g., step 214)
• a horizontal pivot (e.g., step 212) or vertical pivot (e.g., step 214) operation executes.
• Layout information in accordance with systems embodying the invention may also comprise sorting information and merging information.
• the sorting information identifies the order of sequence of records to be shown in the preview table. Merging information directs the system to combined
• the cells in the column can be merged into a single column.
• the system also provides a mechanism for identifying hidden values.
• a value that is hidden may be used to perform an operation, but is not shown in the preview table output.
• User may elect to have individual values, fields, attributes, columns or rows
• Systems embodying the invention may contain a graphical user interface that
• the graphical user interface offers users a WYSIWYG system that automatically
• layout specifications e.g., layout information
• graphical user interface 301 comprises layout portion (300) where the records of a table to be manipulated are displayed.
• Layout portion 300 contains the records of a table displayed in tabular form along with the participating fields and /or attributes. In some instances (e.g., when the user or system identifies certain fields or attributes as hidden fields), not all of the fields or attributes associated with the table are shown. The versions that are displayed may therefore have associated fields or attributes that are not visibly displayed, but that are part of the tabular data.
• layout portion 300 contains family data, but the invention is not limited to the display of family data.
• Layout portion can contain any type of table data arranged in columns and rows.
• layout portion 300 may comprise any type of tabular data whether that data is related or unrelated to other records in the table.
• an embodiment of the invention does not require that the table data share a common value.
• Layout information comprises any data or information that relates to changing the appearance or arrangement of tabular data.
• layout information may comprise inheritance information, pivot values, hidden values, sorting information, merging information, or any other types of data
• Layout information may associate
• the user may associated one or more field and /or
• the layout information may identify: (a) the fields and/or attributes
• category-specific attributes can be used to define the pivoting, sorting, display sequence, and other pivot-specific sorting and display characteristics
• pivots of the same type can be nested, while pivots of
• the system automatically applies the layout information
• the updated table (which may be referred to as a
• preview table provides the user with instantaneous interactive feedback as to the
• the user may obtain further feedback by iteratively
• inventions provide a mechanism for obtaining layout information that relates to a set of tabular data and instantaneously generating a corresponding preview in real time, thereby providing instant interactive feedback to the user.
• the user may continue to
• the layout information (e.g., structure /
• formatting data is stored independent from the tabular data itself and /or the partitioning hierarchy that further extends upon the underlying taxonomy structure.
• the user may apply the layout information to different sets of tabular data
• the tabular data is obtained from a database
• the hierarchy is not altered even though the layout of the
• layout information may also be stored in a way that is directly associated with the tabular data to which it relates.
• the tabular data may also be stored in a way that is directly associated with the tabular data to which it relates. In this instance, the tabular data
• layout information can be part of the same file or in separate files that are
• Figure 4 illustrates a table of data 400 (e.g., family data) before the execution of
• Figure 5 illustrates the functions executed when a stack pivot, horizontal pivot, or vertical pivot is requested.
• the values utilized for each pivot operation are typically obtained from the tabular data to be manipulated (see e.g., Figure 5, step 500 and tabular data 300).
• the purpose of each pivot operation is to reduce the amount of redundant information that ultimately ends up in the preview table.
• the user may elect to hide the pivot values so that the information relating to such values is not shown in the preview table.
• a pivot operation is performed by identifying a pivot axis (e.g., a column or row) in a table that corresponds to the identified pivot value (e.g., steps 502 and 504).
• the pivot axis is then removed from the table (e.g., step 506) and the system generates a preview table by breaking the preview table to sub-tables based on the pivot axis (e.g., step 508).
• the group of records in the table may then be sorted into sub-tables based on the pivot value of the pivot axis.
• Figures 6-8 illustrate a few specific examples of preview table as different types of pivot operations are dynamically applied to the tabular data.
• a stack pivot e.g., step 510.
• stack pivot recombines the sub-tables into the preview table in a vertical arrangement.
• system may add an additional row to the preview table that contains the
• pivot value preserve each of the sub-tables, and label the sub-tables with at least one pivot value (e.g., step 512).
• Each pivot operation can be nested within another pivot
• Figure 6 illustrates the table shown in Figure 4 after a stack pivot is performed.
• the user selected the fields / attributes of "main picture” and "film type"
• pivot values 600 Upon selection of those values the system automatically applies a stack pivot operation against table 400 thereby transforming the table into preview table
• preview table 602 now contains values representative of film, made by KodakTM, and separated by film type.
• An additional type of pivot operation is referred to as a horizontal pivot (e.g.,
• step 514 The horizontal pivot recombines the sub-tables into the preview table by
• the system may also add an additional row to
• Horizontal pivots can be performed by:
• Figure 7 illustrates the table shown in Figure 6 after a subsequent horizontal
• pivot is applied to preview table 602 in real-time upon selection of the horizontal pivot
• Preview table 702 now shows the different film types separated by film speed.
• a vertical pivot recombines the sub-tables into the preview table by arranging
• the system may add an additional column containing one or more pivot values for purposes of labeling a group of rows in the tables that make up each sub-table.
• Figure 8 illustrates Figure 7 after a vertical pivot operation is executed.
• Preview table 802 conveys the same information originally shown in table 400 but
• the table it can be optionally output to another computer program or provided to a
• FIG. 9 is a generalization of several pivot operations in accordance with an
• Block 900 illustrates a stack pivot
• block 902 illustrates a
• block 904 illustrates a horizontal (column) pivot.
• the layout information is saved.
• a table generated using that layout information may be provided to a publication
• the layout information may be applied against multiple sets of data and revised using the process described herein.
• a database is a logical collection of interrelated information, managed and
• a record is a representation of a real-world object such as a person, a product, or
• 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
• Each vertical column of the table represents one field that is stored for each row
• a cell is the intersection of a row and a column in a table and contains the data
• a relational database is a database in which all data is organized into tables that
• RDBMS relational database management system
• a lookup uses a pair of matching columns from two tables, taking the value of
• a join combines information from two tables by performing a lookup on every
• ⁇ Value limiting on a lookup table reduces the set of lookup values by eliminating from the set of all possible lookup values those values that do not correspond to any records in the primary table.
• 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. Attributes
• 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
• 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
• a family 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
• a presentation is a formatted family layout consisting of both the common
• 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
• the partition is specified
• the partitioning table is the main table of records that is to be divided into
• a partitioning hierarchy of a partitioning table is a hierarchy in which the nodes
• a partitioning node is a node in the partitioning hierarchy that corresponds to a
• the set of records represented by a partitioning node is exactly the set of records represented by combining the sets of records represented by
• 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 and /or attribute 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.
• the base family set is the complete set of base families that corresponds to the
• the base family set is
• ⁇ A pivot reduces redundant information in a table of records by restructuring the
• Pivots are similar to partitions in that they
• partitions are families, while the sub-groups created by pivots are used to control
• a stack pivot (or depth pivot) recombines each of the resulting sub-tables into a single table by arranging them vertically on top of each other, and adds an
• each of the resulting sub-tables can be preserved, and each simply labeled with
• a row pivot (or vertical pivot) recombines each of the resulting sub-tables into a
• a column pivot (or horizontal pivot) recombines each of the resulting sub-tables
• pivots of the same type can be nested, while pivots of differing types can be combined.
• given family may need to be reassigned to a different family if they no longer have the criteria which define that family because the records are modified or the definition for
• records may be partitioned into categories, with or without a hierarchy, where each category comprises a set of common attributes.
• a category's attributes may not be not physically part of a record, the attributes are considered part of a definition of the record where the record contains a reference to the category. Examples will be based on
• the taxonomy provides an example of a category hierarchy with five categories, the root category being "Printers" and the remaining categories being child (and leaf node) categories of the "Printers" category.
• 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.
• the "Position” field identifies a position within a hierarchical level for a given
• An attributes table i.e., just
• the third table, a featurevalues table may be used to define enumerated values of
• the featurevalues table is an attribute of the attributes table.
• the featurevalues table is an attribute of the attributes table.
• categoryattribute 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 "table per family” approach partitions the records into families by storing the records of each family in its own table.
• taxonomy by building the fixed values for the fields and /or attributes defining the
• the taxonomy structure will become polluted with information that has nothing to do with the original category- and attribute-based taxonomy.
• a single category of related database records will be broken into multiple categories, obscuring the actual relationship between the records and the original
• taxonomy is polluted with data about the manufacturers.
• the new attribute needs only be linked to one node, but in this example, it needs to be linked to two nodes. With more data, there will tend to be more data redundancy. Modifications will require changes to be made in multiple places, each increasing the risk of error being introduced into the data.
• This query can be stored and later referenced to identify and locate the records
• Finding the family for a particular record would require examining each of the queries
• the partitioning hierarchy is stored as a
• table is used to store the fixed field and/or attribute that define the partitions.
• partitioning information directly as part of the hierarchy table is that there may be
• a partition could be defined based on the combination of a field (such as manufacturer) and an attribute
• the first table to the left defines the following family partitioning hierarchy
• initial leaf nodes were Daisy Wheel Printers, Dot Matrix Printers, Inkjet Prmters, and Laser Printers. Under each of these, additional nodes will be added for each
• the criteria are simply the category for each of the initial leaf nodes.
• partitioning hierarchy must also be adjusted in the same manner. This will result in a
• the first table to the left defines the following family partitioning hierarchy:
• descendant nodes of a particular "ancestor" node are automatically assigned the same partition information that is assigned to the ancestor, which makes setting
• inheritance
• inheritance does not affect a node that has any partitions defined nor does it affect any of its
• the first table to the left defines the following family partitioning Inkjet Printers hierarchy: Acme Inkjet Printers Best Inkjet Printers
• a query In order to find the records that belong to a particular family, a query can be
• each record of the partitioning table will be restructured so that family definitions change, each record of the partitioning table will be restructured so that family definitions change, each record of the partitioning table will
• Example 1 The End Brushes category is partitioned by Manufacturer Name (in er te ancestor node)
• Changes to the taxonomy structure that require updates to the partitioning hierarchy include adding, removing, moving, or modifying a category.
• Changes to the domain of a partitioning field include adding, removing or modifying a field value, while changes to the feature domain for a partitioning attribute include adding, removing or modifying a feature value.
• main table records reduces the number of families dramatically to precisely those containing records (and certainly no more than the number of products in the main
• the solution is to automatically adjust the partitioning hierarchy when either the taxonomy structure, the domain of a partitioning field or attribute, or main table
• 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 /attributes and the value replaced could have been the only
• the "single table” approach stores all of the data values for a main table record, including the common information that applies to an entire family of records, within
• 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
• partitioning hierarchy in such a way that the system creates and maintains all of the
• the next step is for the user to assign the common
• each new record in the primary table is automatically linked to the correct common
• Publishing information stored in an RDBMS as properly formatted presentations consisting of common information and tabular information for each group of related family records is relatively straightforward provided that the tabular layout format is relatively simple and the field structure comprising the information is uniform across the entire set of records in the DBMS.
• the tabular layout formats are more sophisticated, when each category of information consists of different data elements, and /or when each family requires its own distinct tabular layout format. In these cases, laying out each individual family requires more sophisticated algorithms and each family requires its own special handling, dramatically increasing the complexity of the publishing task.
• RDBMS include report writers that provide an adequate platform for publishing information stored in the database as formatted presentations with simple tabular layout formats.
• the report writer can be easily coded to combine information from records in multiple tables, format the common information associated with each family in a structured way, and finally sort the records of tabular information.
• This approach works well with a relational database in which the field structure and the set of fields is consistent across the entire set of records, the field definitions are relatively static, and the number of fields is limited; because each field applies across the entire database, special handling and formatting for a particular field or fields is coded only once rather than multiple times.
• the field structure in which the field structure and the set of fields is consistent across the entire set of records, the field definitions are relatively static, and the number of fields is limited; because each field applies across the entire database, special handling and formatting for a particular field or fields is coded only once rather than multiple times.
• the field structure in which the field structure and the set of fields is consistent across the entire set of records, the field definitions are relatively static, and the number
• the report writer must then be recoded each time changes are made to the taxonomy structure and /or the set of attributes associated with each category, which
• the improved solution addresses and completely eliminates these coding
• partitioning hierarchy information but also to define additional layout information about the structure and formatting of each presentation of family records.
• additional layout information about the structure and formatting of each presentation of family records.
• taxonomy structure is extended for each family to include layout specifications that
• This layout specification is performed and stored on a family-by-family basis so that not only fields
• pivots of the same type can be nested, while pivots of differing types can be
• the improved solution - for the first time - offers a WYSIWYG system that automatically generates and displays previews of the tabular layout formats
• Another feature of this scheme is that, just as with the family partitioning hierarchy, the layout structure defined for each node is inherited by all nodes that are children of that node in the extended taxonomy. And once again, the inherited structure
• Horizontal pivots have three variants.
• 2 Stack pivots have three variants.
• Example 1 The Weiler End Brushes family before pivoting
• Example 2 The Weiler End Brushes family after stack, vertical, and horizontal pivoting
• pivoted tabular layout formats in real time and allows the layout process to be interactive, incremental, and iterative; (h) the ability to specify pivot information at any
• the searchable, database-driven electronic catalog can not only serve up the product
• the improved solution substantially eliminates the manual page layout process for paper catalogs. All of the time and effort invested in defining
• the system automatically generates the page layouts by combining product data and formatting data from the database and then
• catalog pages allows changes to the product data to be reflected immediately in subsequently generated output, supports the on-demand generation of custom catalogs on product subsets with no additional effort, and results in a more uniform look
• electronic catalog publishing can then be changed in any way for each paper publication, providing almost unlimited flexibility to create custom paper catalogs each based upon the electronic standard but laid out in a fashion that is as similar to or as
• a product mask can be applied when the snapshot is taken to limit the set of
• masks can also be applied electronically, and /or search parameters specified, to limit the set of products
• a family can be copied from the family partitioning hierarchy into the publication to include families that were not initiallv included in the publication. • Each family can appear in multiple locations in the publication and each 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).
• innovations are: (a) layering both the electronic and paper publishing process on top of the same extended taxonomy structure for automatically formatting and publishing database data; (b) using tabular layout formats that are captured and stored in the database alongside the product data itself rather than stored in the page layout; (c) publishing high-quality output to the web using this layout information stored in the database; (d) using the page layout program's API or intermediate ASCII file format to render pages automatically; (e) allowing a product mask to be applied when the publication is first created; and (f) allowing the layout detail, the column names, the set of records, and the common information to be individually customized for each family of a particular publication.
• 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.
• 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
• This table contains the descriptions of all Primary Data Tables.
• Primary Tables have the name _A2i_ ⁇ :_ 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
• FieldType specifies the SQL field types for the primary tables.
• the Field Structure is as follows
• _A2i_x_ where x is the Id specified in the Tableld field of _A2i_CM_Tables_.
• 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.
• Performance We only need to know the Id of a field to access it. This results in less storage in the server and client components and small network packets. It also speeds up the search for a particular field.
• Cross Database independence This format is valid for SQL databases, Codebase, MS Access or any other standard database system. We use each database simply as a container. By restricting the field names, we guarantee that all names will comply with naming conventions on the various database systems used.
• 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_x_ This additional Mask field stores the bits of a BitVector 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:
• 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 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 creating 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 'SampleCategory Table' 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 'SampleCategory Table' 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 'SampleCategory Table' that describes the 'Monitor' category. Now all records in the main table with 'SampleCategoryField' that link to the record describing the 'Monitor' category in "SampleCategory Table' will have the 'Screen Size' attribute.
• a Text Attribute is an enumerated list of Text Values.
• An example is "Valve Type”.
• 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:
• 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.
• 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.
• x is the Tableld of the HierAttrTable that contains the categories that have the groupings.
• Ix_MS_x_Idl non-unique index on Idl
• Ix_MS_x_Id2 non-unique index on Id2
• 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:
• 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. For example, 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.
• 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 must be initialized with all the values in the category table chosen as the first partition.
• the Itemld, Parentld, and RelativePosition may be initially set to the same value in the category table. Although these values may diverge after time.
• 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
• 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_FamilyItemNalues_
• 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.
• This hierarchical table describes exactly where the data items are. Data items are assigned ids from this table to specify exactly where they are.
• Each record represents 1 part in a part of locations.
• example is A2iUSA ⁇ Dave_Office ⁇ sullivan ⁇ d$ ⁇ work ⁇ images ⁇ testImages
• 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.

Priority Applications (1)

Applications Claiming Priority (2)

Publications (2)

Family

ID=22879523

Family Applications (2)

Family Applications After (1)

Country Status (3)

Cited By (11)

Families Citing this family (182)

Citations (2)

Family Cites Families (15)

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

Patent Citations (2)

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events