Systems and methods for generating a push-up alert of fault conditions in the distribution of data in a hierarchical database

Embodiments relate to systems and methods for generating a push-up alert of fault conditions in the distribution of data in a hierarchical database. Higher-level data, such as yearly profit, may be desired to be spread from parent nodes to lower nodes, such as quarters, in a hierarchical data store. Parent nodes can be associated with a set of programmatic placeholder nodes. A spreading tool can insert child nodes representing quarters, months, or other insertion point(s) encoded by a placeholder nodes, dividing quantities appropriately. The spreading tool can access or host logic to ensure that data is spread in an order that takes dependencies, formatting, or other factors into account. The spreading tool can also be configured to detect numerical errors, logical errors, or other faults and attempt to identify conflicting rules or other sources of error. Those rules can be automatically removed and/or removed via user selection.

CROSS-REFERENCE TO RELATED APPLICATIONS

The subject matter of this application is related to the subject matter of co-pending U.S. application Ser. No. 12/570,704, filed Sep. 30, 2009, entitled “Systems and Methods for Distribution of Data in a Hierarchical Database via Placeholder Nodes”, by the same inventor as this application, and being assigned or under assignment to the same entity as this application, and to the subject matter of co-pending U.S. application Ser. No. 12/571,009, filed Sep. 30, 2009, entitled “Systems and Methods for Conditioning the Distribution of Data in a Hierarchical Database”, by the same inventor as this application, and being assigned or under assignment to the same entity as this application, each of which applications are incorporated herein in their entirety.

FIELD

The present teachings relate to systems and methods generating a push-up alert of fault conditions in the distribution of data in a hierarchical database, and more particularly, to platforms and techniques for monitoring the distribution of data from parent nodes to a set of child nodes governed by spreading rules to detect conflicts numerical faults, conflicts between rules, or other logical faults or other errors in the spreading process, and optionally, attempt to resolve those faults by automatic or user-selected adjustment of the spreading rules or other parameters.

BACKGROUND OF RELATED ART

In networked database technologies, hierarchical databases such as online analytical processing (OLAP) databases, extensible markup language (XML)-based data stores, and others are known. During operations with hierarchical data stores, it is sometimes necessary or desirable to add or insert additional data values into nodes which lie beneath the parent node in the hierarchy. For instance, if a parent node stores financial data reflecting annual profit for a corporation or other entity, it may be desired at the same time or a later time to insert lower-level breakdowns of that data over smaller intervals. For example, it may be desired to insert child nodes which store quarterly or monthly profit for that entity. In general, the process of pushing or distributing data down to child nodes or other destinations in the database structure can be referred to as “spreading” the data.

In known database platforms, the ability to perform spreading operations can be constrained or limited by limitations in the data structures and logical operations permitted on those platforms. For one, while platforms may exist which permit a user to insert a new child node at a lower level in relation to a parent node, data may only be distributed down from one parent at a time. If, for instance, annual profit is intended to be expanded or spread down to quarterly profit entries over the last ten years or some other group of years, the user may be forced to manually insert the child nodes and manually perform the spreading, year by year.

For another, when performing distribution of data between nodes or levels in a hierarchical data store, the order in which spreading is performed can have effects which the database engine does not take into account. For instance, when spreading annual profit down to quarterly nodes, it may be necessary to check for special charge offs or other factors against profit in a given quarter, or profit for a first fiscal quarter may be affected by a carry-over entry from the previous fiscal year end. Other factors or dependencies can apply, but existing database platforms do not permit the incorporation of dependency rules or other logic to ensure data accuracy or integrity.

Other shortcomings in existing database engines exist. For instance, in a rules-based platform it may be desirable to detect, trap, and attempt to cure a numerical fault, logical fault, and/or other source of erroneous or irregular data spreading outputs. For example, if it is discovered that the insertion of a particular spreading rule causes division by zero in a computation, cell, or other output, tracing and identification of the offending rule to permit suspension, adjustment, or removal of that rule may be helpful. It may be desirable to provide systems and methods for generating a push-up alert of fault conditions in the distribution of data in a hierarchical database which permit the isolation of conflicting rules, notification to the user of that condition, and potential corrections to the set of rules or other parameters to restore reliable data spreading operations.

DESCRIPTION OF EMBODIMENTS

Embodiments of the present teachings relate to systems and methods for generating a push-up alert of fault conditions in the distribution of data in a hierarchical database. More particularly, embodiments relate to platforms and techniques for accessing a set of hierarchical data, such as data stored in OLAP, XML, or other data sources, and manipulating that data for distribution or spreading to lower hierarchical levels. In embodiments, a set of placeholder nodes can be associated with a set of parent nodes, to act as points for insertion for child nodes or other lower level structures, at a current or later time. In embodiments, the placeholder nodes can store linkages to one or more parent nodes, and in embodiments can be invisible to users of the associated database engine until viewing or spreading operations are desired. In embodiments, the set of placeholder nodes can also further represent programmatically manipulable objects, which, for instance, encode inheritance rules, output pipes, or other linkages, or other logic or functions for the subsequent child nodes inserted in their place or at their location. In embodiments, the set of placeholder nodes can be generated, configured, and managed by a spreading tool of an associated database engine which manages the overall hierarchical data store.

When the spreading of data to child nodes or levels is desired, a user can access the spreading tool and view and manipulate the set of placeholder nodes to insert one or more sets of child nodes configured to receive data from, or data derived from, the corresponding parent node. In embodiments, the spreading tool and/or other logic can access the set of placeholder nodes involved in distribution activity, and use those nodes as insertion points to populate the hierarchical data store with new, additional, and/or updated child nodes to receive data. In embodiments, identical, and/or or related placeholder nodes can be associated with more than one parent node, so that, among other things, a set of child nodes and subsequent distribution of data can be performed from multiple parent nodes at the same time. In embodiments, the spreading tool can delete the set of placeholder nodes when a spreading operation or other distribution has been completed. In embodiments, the spreading tool can in addition or instead retain any placeholder nodes used in a distribution of data to child nodes, for instance to maintain a record of the distribution activity. In embodiments, the spreading tool can access and apply a set of spreading rules and/or other logic to ensure data integrity or accuracy in view of potential data dependencies, data formatting requirements, and/or other factors affecting the distribution or computation of data stored in or related to the hierarchical database.

Reference will now be made in detail to exemplary embodiments of the present teachings, which are illustrated in the accompanying drawings. Where possible the same reference numbers will be used throughout the drawings to refer to the same or like parts.

FIG. 1illustrates an overall system100in which systems and methods for generating a push-up alert of fault conditions in the distribution of data in a hierarchical database can operate, according to various embodiments. A set of clients108can communicate with a database engine102via one or more network130. Database engine102can be or include storage, hardware, software, and/or other resources to execute database operations, such as accessing and manipulating OLAP data stores, XML data stores, other database stores, engines, or applications, statistical applications, spreadsheet applications, or other services or applications. database engine102can communicate with and manage a hierarchical data store104, such as an OLAP database, an XML-based database, and/or other data store. Set of clients108can be or include, for example, a set of local or remote desktop computers, laptop computers, wireless devices, and/or other machines or devices which communicate with one or more network130can be or include, for example, the Internet or other public or private networks. Database engine102can be or include a server with associated memory, storage, and other resources configured to receive database requests from one or more clients in set of clients108, and interpret that request to perform database operations on data maintained in data store104.

As likewise shown inFIG. 1, a user of a client in set of clients108can invoke or instantiate spreading tool106of database engine102via a local application or interface, such as a Web browser, database application, or other software. Spreading tool106can, in general, contain logic, storage, and/or other resources to effectuate the distribution, transfer, copying, or other communication of data from parent or other upper-level nodes in data store104to child nodes or other destinations via a set of placeholder nodes. In aspects, the set of placeholder nodes can as placeholders, and can be stored in reserve storage and/or memory locations which can act as insertion points for new or modified child nodes for levels of data that a user may later choose to insert. In embodiments, each placeholder node114can act not merely or only as a temporary, shadow, or otherwise passive storage location or object, but as a programmatically configurable object which is capable of establishing inheritance and other properties for the set of child nodes derived from that placeholder. In embodiments, during the distribution of data to any inserted child nodes, spreading tool120can access a set of spreading rules132to ensure that functional or other dependencies, data formatting, and other data integrity requirements are met.

More particularly, as shown, for example, inFIG. 2, the hierarchical data store104can comprise hierarchical data structures including, for instance, a set of parent nodes112. Set of parent nodes112can be linked to a root node136, illustratively shown as profit for a corporation, although it will be understood that any other data type, category, or format can be used. Set of parent nodes112are illustratively shown as encoding a set of annual profit data arranged in parent nodes each representing one year, although, again, other data types and configurations can be used. In aspects, data other than financial data, such as, for example, medical, technical, scientific, and/or other data can be processed according to embodiments of the present teachings.

In embodiments as shown, the set of parent nodes112can have an associated set of placeholder nodes114linked to them. In embodiments, each parent node in set of parent nodes112can have one or more placeholder nodes associated with it. In embodiments, only a subset of set of parent nodes112can have an associated set of placeholder nodes114established or linked to them. In embodiments, each of the placeholder nodes can constitute a “leaf” node, that is, a node not having any further child nodes. In embodiments, each placeholder node in set of placeholder nodes114can occupy a lower level in data store than104than its associated parent node, although in aspects the set of placeholder nodes114need not all occupy the same level of data store104. In embodiments, set of placeholder nodes114can define data fields and formats that can be used to populate a set of child nodes116that will be inserted into data store104.

In embodiments, when a user of set of clients108or other user wishes to access data store104and insert new or updated child nodes in that data structure, the user can access spreading tool106via network130. The user can use spreading tool106to locate one or more placeholder nodes in set of placeholder nodes114via which the user wishes to add one or more set of child nodes116. In aspects, a user may for instance access a placeholder node in set of placeholder nodes114associated with an annual profit node for the year 2001 in set of parent nodes112. The user can insert, for instance, set of four child nodes representing quarterly profit derived from the annual profit parent node for that year. According to embodiments, the user can direct spreading tool106to initiate the spreading or distribution of annual profit data down to the lower-level set of child nodes116.

Spreading tool106can perform the distribution by dividing the annual profit data encoded in the associated parent node (e.g. year 2001 profit as shown) equally into four quarters, and transmitting the resulting set of spread data134to each of the set of child nodes116associated with that parent node. In embodiments, the set of spread data134need not be equally divided over all child nodes associated with the parent node. In embodiments, the same or different set of spread data134can be generated and distributed from more than one parent in set of parent nodes112at the same time, or as part of the same operation. Other types of child nodes, levels, and formats of set of spread data134can be used, including, for instance, monthly profit nodes, as likewise shown inFIG. 2. Other structures, layers, and relationships between levels of information stored in data store104can be used.

In embodiments, in addition to defined data structures, each node in set of placeholder nodes114can encode or represent a set of specifications for inheritance by set of child nodes116, or other programmatic information for determining the configuration of set of child nodes116or any aspect of their operation. In embodiments, set of placeholder nodes114can serve as passive data-structure objects, acting as a reserve storage or insertion point, a database flag, a database event trigger. In embodiments, increased flexibility in data spreading operations can be enhanced by establishing and utilizing set of placeholder nodes with a set of attributes and/or metadata to allow those nodes to operate as programmatic objects in themselves. For instance, in embodiments, set of placeholder nodes114can be configured as an event or function that triggers a rule, and can for example form part of the object inheritance from one or more parent nodes, themselves. For example, set of placeholder nodes114can be configured to force set of spread data134to conform to U.S. dollar figures or format, and for instance to perform currency conversions to that denomination automatically. For further example, set of placeholder nodes114can store linkages, interfaces, mappings, and/or relationships to other nodes that will require outputs from the set of child nodes116, once those nodes are installed and populated with data. Other programmatic settings can be configured in set of placeholder nodes114. In embodiments, the programmatic settings stored in or associated with set of child nodes114can be updated or extended at any time.

It may be noted that in embodiments, spreading tool106can condition or process the set of spread data134transmitted to one or more child nodes before sending that information, to ensure data integrity or consistency. In embodiments, spreading tool106can invoke or access set of spreading rules132and/or other logic to ensure that data spread from set of parent nodes112is distributed to child nodes in a correct or consistent order. In embodiments, set of spreading rules132can specify that certain child nodes whose data or output is needed by other nodes are the first to receive set of spread data134. In embodiments, set of spreading rules132can specify that set of spread data134be encoded in or converted to formats required by recipient nodes or other destinations. In embodiments, set of spreading rules132can enforce or apply other logic or rules to ensure that set of spread data134is transmitted, formatted, computed, or otherwise manipulated to preserve the consistency or integrity of set of spread data134and/or any calculations, outputs, and/or services that use or depend on that data. It may be noted that in embodiments, the same or different spreading rules in set of spreading rules132can be applied to distributions from two or more parent nodes, in cases where a distribution is carried out from more than one parent node at a time.

FIG. 3illustrates error or fault detection and reporting activities that can be carried out in the distribution of data from set of parent nodes112to set of child nodes116, according to various embodiments. In embodiments as shown, database engine102can comprise a fault detection module138including software, hardware, logic, and/or other resources that can be used to monitor spreading activity performed by spreading tool106using set of spreading rules132, and identify potential or actual faults, errors, bugs, or other irregular conditions. In embodiments as shown, fault detection module138can communicate with spreading tool106, set of spreading rules132, data store104, and/or other storage, nodes, logic, resources, to monitor and supervise the distribution of data from set of parent nodes112and/or other sources to set of child nodes116and/or other destinations. Fault detection module138can, for example, detect a numerical fault or error in the set of spread data134being generated to be spread to a node in set of child nodes116, such as a flag for a divide by zero operation, an flagged infinite value, a negative value for quantities not expected or permitted to be less than zero, and/or other results that represent an incorrect result or condition, or other violation or error state. For instance, an output transmitted to a child node in an incorrect or invalid format may likewise represent a violation of set of spreading rules132, or other logical conditions or criteria.

In embodiments as shown, upon detection of a fault condition and/or other violation, fault detection module138can generate a fault notification140, such as a pop-up menu, gadget, and/or other interface, which can be presented for instance via a graphical user interface (GUI) of operating system126, and/or via other interfaces. In aspects, fault notification140and/or other messaging to the user or other destinations of a data spreading error can be referred to as a “push-up” notification, in regards that the detected error occurring at a relatively lower level in data store104can be communicated upward through higher levels of that store, and/or to a user manipulating that data store and its contents. In embodiments, fault notification140can comprise a rule selection menu142, such as a selectable or highlightable list of set of spreading rules132that have been used to generate the data which is the subject of the attempted distribution or spreading operation. In aspects as shown, the user can for instance operate a mouse pointer to select a rule or rules which the user suspects has caused the spreading violation. For example, the user may select a rule or rules which relate to or communicate with the node in set of child nodes116which contains the data with an error state or other irregularity.

It may be noted that while embodiments as shown can incorporate a rule selection menu142or other interface through which a user can manually select one or more rules to suspend, adjust, and/or remove from set of spreading rules132, in embodiments, fault detection module138can in addition or instead automatically identify one or more rules which may be causing the identified fault or violation. In embodiments, for instance, fault detection module138can employ code tracing and/or other debugging techniques or logic, to attempt to identify one or more rules whose application may be causing the numerical, logical, and/or other fault or condition. In aspects, fault detection module138can for example perform iterative testing on set of spread data134and/or other output while suspending, adjusting, and/or removing various sets or sequences of rules in set of spreading rules132, to determine if or when the error or violation is corrected and then suspending, changing, or terminating the identified rule or rules. In embodiments, fault detection module138can likewise present any automatically identified potentially faulty rules to the user via fault notification140, for instance to allow the user to confirm the deletion, suspension, or adjustment of those rules, to select other or additional rules for termination or modification, and/or take other actions.

FIG. 4illustrates an exemplary configuration of database engine102which can be used in systems and methods for generating a push-up alert of fault conditions in the distribution of data in a hierarchical database, according to embodiments. In embodiments as shown, database engine102can comprise a processor120communicating with memory122, such as electronic random access memory, operating under control of or in conjunction with operating system126. Operating system126can be, for example, a distribution of the Linux™ operating system, the Unix™ operating system, or other open-source or proprietary operating system or platform. Processor120also communicates with data store104, such as a local or remote database, which can be stored, for instance, on one or more hard drives, optical drives, magnetic drives, electronic memory, and/or other storage. Processor120further communicates with network interface124, such as an Ethernet or wireless data connection, which in turn communicates with one or more network130, such as the Internet or other public or private networks. Processor120can, for example, communicate with set of clients108via one or more network130. Processor120also communicates with database engine102, spreading tool106, and/or and other resources to control the processing of hierarchical data including transfer of data between set of parent nodes112, set of placeholder nodes114, set of child nodes116, and/or other nodes, entries, fields, and/or locations. Other configurations of database engine102, associated network connections, and other hardware and software resources are possible.

FIG. 5illustrates a flowchart of data processing operations that can be used in systems and methods for generating a push-up alert of fault conditions in the distribution of data in a hierarchical database, according to various embodiments. In502, processing can begin. In504, a hierarchical data store104can be accessed via database engine102, for instance, by request from a client in set of clients108, or other request. In506, one or more parent nodes in set of parent nodes110can be selected with which or in which to insert a set of placeholder nodes114. In508, set of placeholder nodes114can be associated with one or more parent nodes in set of parent nodes110, for instance, by selection or input by a user. In embodiments, a functional relationship between the one or more parent nodes and set of placeholder nodes114can be defined, such as, for example, to define set of placeholder nodes114to contain or represent a division of annual profit stored in the associated parent node over quarters or other periods. In embodiments, a functional relationship need not be defined when configuring set of placeholder nodes114. In embodiments, a functional relationship can be defined or updated at various later times.

In510, set of placeholder nodes114can be stored to data store104or other storage, as appropriate. In512, spreading tool106and/or other logic can receive user input or other instructions to insert one or more child nodes of one or more corresponding parent node(s) at one or more insertion points represented by one or more placeholder nodes in set of placeholder nodes114. For example, a set of four child nodes representing annual quarters can be established as lower level nodes of a parent node encoding annual profit for a corporation or other entity. In embodiments, the inserted set of child nodes116can each occupy the same hierarchical level in data store104. It may be noted that in embodiments, there may be a one-to-one relationship between a placeholder node and a child node to be introduced at the insertion point represented by the placeholder node. In embodiments, more than one child node may be inserted at the insertion point represented by the placeholder node. Likewise, in embodiments, two or more child nodes in the set of child nodes116can occupy different hierarchical levels in data store104. In embodiments, the inserted set of child nodes116can be associated with more than one parent node. For example, in instances the same set of child nodes116can be duplicated as newly inserted nodes linked to two or more parent nodes.

In514, the set of child nodes116identified or configured for insertion can be established and/or built in data store104, for instance, by storing links to one or more parent nodes along with metadata such as functional relationships with the parent node(s) and/or fellow child nodes. Other configuration data can be specified and/or stored. In516, spreading tool106can access a set of spreading rules132to ensure that dependencies are observed, and/or other rules are applied in the generation of set of child nodes116and/or the distribution or insertion of data into those nodes. For instance, before storing profit to a child node, for example, for Q2 of year 2010, spreading tool106can check set of spreading rules132whether another node for charge-offs or other special transactions or modifications applies to that time period. For further instance, spreading tool106can check set of spreading rules132to determine whether a certain type of data format is required for compatibility with the corresponding parent node, an additional node which will receive output from the child node, or by other nodes or functions of data store104or otherwise.

In518, data from the corresponding parent node(s) can be inserted, distributed, and/or spread to one or more associated child nodes in set of child nodes116. For instance, data for annual profit can be divided over four quarters and spread or inserted into a set of child nodes116representing that set of time periods or other intervals. In520, data engine102can run or perform database operations on data store104, including set of parent nodes110and/or any newly configured or updated set of child nodes116, for instance, to run reports on that information, merge data between nodes or files, or perform other computations/operations. In522, spreading tool106can store one or more nodes of set of placeholder nodes114, for instance to data store104or other local or remote storage, to store a log of the configuration history of data store104, data distributions performed in data store104, or other records of database operations. In embodiments, spreading tool106can also or instead delete one or more nodes of set of placeholder nodes114, for instance, when it is determined that the placeholder node(s) will no longer be needed for spreading or other data operations. In524, processing can repeat, return to a prior processing point, jump to a further processing point, or end.

FIG. 6illustrates processing that can be used in systems and methods for generating a push-up alert of fault conditions in the distribution of data in a hierarchical database, according to various embodiments. In602, processing can begin. In604, a hierarchical data store104, such as an XML-based database or other database, can be accessed via data base engine102. In606, data distribution operations can be initiated between or using set of parent nodes112, set of placeholder nodes114, and/or other nodes, sites, or resources. In embodiments, data spreading or distribution operations can be initiated by a user, and/or automatically, for instance using programming or logic in database engine102. In608, set of spreading rules132can be applied to selected data sources in hierarchical data store104, such as values stored in set of parent nodes112. In610, the output of set of spreading rules132applied to the selected data source(s) can be monitored by or via fault detection module138and/or other logic. In aspects, data or other outputs produced by one or more of the applied rules or logic can be transmitted to fault detection module138before insertion into set of spread data134, or at other times. In612, fault detection module138and/or other logic can detect the occurrence of one or more violations, errors, faults, and/or other conditions in the execution and/or application of set of spreading rules132to the subject data source(s). For example, fault detection module138can detect or identify an output directed or intended to be directed to a particular child node (e.g., quarterly profit or less) which represents division by zero, a nominally infinite quantity, and/or other faults, errors, or conditions. In614, fault detection module138can trap and/or identify one or more rules in the applied set of spreading rules132which potentially causing the detected fault condition, as appropriate. For example, fault detection module138can perform bug tracing or other techniques to identify the spreading rule or rules which last processed or affected a variable or quantify, or could be otherwise linked to a faulty output or operation. In616, one or more rules can be received or identified for suspension, adjustment, and/or termination from data spreading operations. In embodiments, the rules to be suspended, adjusted, and/or terminated can be received via user selection, for instance via rule selection menu142or other interface. In embodiments, the rule or rules identified for removal, suspension, and/or adjustment can be selected automatically, for instance via software or logic in fault detection module138. In embodiments, rule selection menu142can simply present all rules in set of spreading rules132, and/or can present a subset of set of spreading rules132, for instance, only those potentially identified as causing a violation via fault detection module138. In embodiments, no rule selection menu142need be presented, for instance, in cases where potentially faulty or conflicting rules are automatically identified by fault detection module138. In618, fault detection module138and/or other logic can retest and/or reevaluate data distribution operations using the modified set of spreading rules, with potentially conflicting rules modified, suspended or removed, as appropriate. In620, data spreading operation(s) can be executed upon establishing a correct, debugged, or otherwise functionally satisfactory set of spreading rules to apply to the data source(s), as appropriate. In622, processing can repeat, return to a prior processing point, jump to a further processing point, or end.

The foregoing description is illustrative, and variations in configuration and implementation may occur to persons skilled in the art. For example, while embodiments have been described in which data store104can consist of or contain explicit OLAP and/or XML-based databases, in embodiments, other types or categories of data sources or formats can be included in data store104.

Similarly, while embodiments have been described in which a single database engine102generates and manages data store104, in embodiments multiple database engines, for example hosted on multiple servers, can cooperate to generate multiple parent/child mappings, placeholder linkages, distributions, and/or other actions to manage and manipulate hierarchical data. Similarly, while embodiments have been described in which data is hosted and managed in one data store104, in embodiments, multiple data stores can be used. For further example, while embodiments have been described in which database engine102supports database operations including data spreading in connection with a set of local or remote clients108, in networked fashion, in embodiments database engine102and/or other machines or resources can be configured to operate on a stand-alone basis. For still further example, while embodiments have been described in which data spreading rules extracted from a single, unitary, or co-stored set of spreading rules132are analyzed for integrity, in embodiments, multiple sources or stores of sets of spreading rules can be combined and/or analyzed together. Other resources described as singular or integrated can in embodiments be plural or distributed, and resources described as multiple or distributed can in embodiments be combined. The scope of the present teachings is accordingly intended to be limited only by the following claims.