Overlay Dataset

Information

  • Patent Application
  • 20070282810
  • Publication Number
    20070282810
  • Date Filed
    October 03, 2006
    18 years ago
  • Date Published
    December 06, 2007
    16 years ago
Abstract
Overlay datasets provide an efficient, flexible and scalable mechanism to represent the logical replication of one or more prior defined datasets. Only changes made to an entity in an overlay dataset's underlying dataset are replicated into the overlay dataset (such changes do not affect the underlying dataset). Read operations directed to the overlay dataset will find entities in the overlay dataset if they exist and in the underlying dataset(s) if no overlay-specific entity exists. Accordingly, overlay datasets provide an efficient mechanism for making changes to an existing dataset without suffering the high processing time and storage overhead associated with prior art copying and versioning techniques. Overlay datasets also provide a natural mechanism to keep two or more datasets in synchronization because changes to a base or underlying dataset's entities are “visible” in its associated overlay dataset (unless the entity has been modified in the overlay dataset).
Description

BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 illustrates, in block diagram form, access operations through an overlay dataset in accordance with one embodiment of the invention.



FIG. 2 shows, in flowchart form, an overlay dataset access technique in accordance with one embodiment of the invention.



FIG. 3 shows, in block diagram form, an overlay dataset in accordance with the invention defined in terms of another overlay dataset.



FIG. 4 shows, in flowchart form, an overlay dataset access technique in accordance with another embodiment of the invention.





DETAILED DESCRIPTION

The following description is presented to enable any person skilled in the art to make and use the invention as claimed and is provided in the context of the particular examples discussed below, variations of which will be readily apparent to those skilled in the art. Accordingly, the claims appended hereto are not intended to be limited by the disclosed embodiments, but are to be accorded their widest scope consistent with the principles and features disclosed herein.


An overlay dataset in accordance with the invention provides an efficient, flexible and scalable mechanism to represent the logical replication (with changes) of one or more prior defined datasets. In one embodiment, an overlay dataset has all the characteristics of any other dataset. On creation, however, an overlay dataset has no instances, elements or records—just a reference to the dataset(s) it is an overlay for. When the overlay dataset is accessed, if the target entity has not been modified from an underlying, base, source or member dataset, or newly added to the overlay dataset, the entity from the underlying dataset is returned. Thus, access of an unmodified entity in an overlay dataset will “read through” the overlay dataset to the underlying dataset to retrieve the target entity. When an entity in one of the overlay dataset's underlying datasets is modified through the overlay dataset (including any associated relationships), that entity is copied or instantiated in the overlay dataset. When such an entity is targeted for access through the overlay dataset, the overlay dataset's copy of the entity is returned. Thus, modified entities “mask out” entries in the underlying dataset(s). It will be recognized that an entity or object may be modified by having one or more of its associated values, attributes or relationships modified or by being designated as deleted. Entities from an underlying dataset designated as deleted in the overlay dataset may be instantiated in the overlay dataset and flagged or marked as deleted. While such entities may be identified during overlay dataset access operations, they are not generally returned (even though they may continue to exist in the underlying dataset). Finally, entities added to the overlay dataset (and do not, therefore, exist in any of its base, source, underlying or member datasets) are accessible through the overlay dataset only. As used herein, the term “entity” indicates a database entry in its most general form. In an object-oriented database, for example, an entity could be an object while in a relational database, an entity could be a record.


Referring to FIGS. 1A-1C, the above-described behavior may be illustrated by considering database 100 that includes overlay dataset 105 which itself includes base, underlying, source or member dataset 110 having entities 115 and 120. As shown in FIG. 1A, when initially created overlay dataset 105 includes no entitles unique to itself so that, for example, access 125 through overlay dataset 105 for entity 120 returns entity 120 as it exists in base, member or source dataset 110. Referring to FIG. 1B, at some later time entity 120 may be modified 130 through overlay dataset 105, resulting in entity 120′ being instantiated or created within overlay dataset 105. Referring now to FIG. 1C, following the modification of entity 120 through overlay dataset 105 to create entity 120′, any subsequent access 135 for entity 120 through overlay dataset 105 will return entity 120′ while access to non-modified entities through overlay dataset 105 continue to return entities as they exist in their base, underlying, source or member dataset (e.g., access 140 to entity 115).


One of ordinary skill in the art will recognize that in practice a dataset may include thousands or millions of separate entities or objects and that each such object may participate in zero or more relationships with other entities. In addition, overlay datasets may be based on any number of underlying datasets. Accordingly, FIG. 1 represents a very simplified or schematic view of an actual embodiment.


Referring to FIG. 2, dataset access technique 200 in accordance with one embodiment of the invention begins when a request for a specified entity from a designated dataset is received (block 205). If the specified entity is found in the designated dataset (the “Yes” prong of block 210), a check is made to determine if the entity has been marked as deleted (block 215). If it has (the “Yes” prong of block 215), an error message is returned indicating the specified entity is not available through the designated dataset (block 220). If the found entity is not marked as deleted (the “No” prong of block 215), the specified entity is returned (block 225). If the specified entity is not found in the designated dataset (the “No” prong of block 210), the designated dataset is checked to determine if it is an overlay dataset (block 230). In one embodiment, for example, a dataset is a data structure that includes metadata indicating whether it is an overlay dataset (e.g., an “overlay” flag attribute or value). If the designated dataset is not an overlay dataset (the “No” prong of block 230), an error message is returned indicating the specified entity could not be found (block 220). If the designated dataset is an overlay dataset (the “Yes” prong of block 230), the overlay dataset's base or source dataset is set to be the designated dataset (block 235), where after processing continues at block 210. It will be appreciated that operations in accordance with block 235 may be invoked for each member dataset comprising an overlay dataset.


On this point, it is further noted that an overlay dataset in accordance with the invention is not limited to being comprised of non-overlay (prior art) datasets. Referring to FIG. 3, for example, overlay dataset 300 may be defined in terms of one or more previously defined overlay datasets such as overlay dataset 305, itself defined in terms of non-overlay, or prior art, datasets 310 and 315, as well as zero or more non-overlay datasets such as dataset 320.


Referring to FIG. 4, dataset access technique 400 in accordance with another embodiment of the invention begins as before when a request for a specified entity from a designated dataset is received (block 205). A search is then performed for the specified entity in the designated dataset and any overlay datasets that are members of the designated dataset (block 405). The results are then placed in overlay order (block 410). As used herein, “overlay order” refers to a sequence wherein entities instantiated in an overlay dataset come before their namesake entities in the overlay dataset's underlying or base dataset. This ordering may be recursive if an underlying or source dataset is itself an overlay dataset. This ordering may be user-specified or automatic as described above. If the specified entity is found in the result set generated in accordance with block 410 (the “Yes” prong of block 415), a further check is made to determine if the specified entity has been marked as deleted (block 420). If so marked (the “Yes” prong of block 420), an error message is returned indicating the specified entity is not available through the designated dataset (block 425). If the entity is not marked as deleted (the “No” prong of block 420), the first-most entity in the result list in accordance with block 410 is returned (block 430). It will be recognized that if the designated dataset is an overlay dataset and the specified entity is a modified form of an entity from an underlying or base dataset, there will be more than one “specified” entity in the result set. If the entity is not found in the result list generated in accordance with block 410 (the “No” prong of block 415), an error message is returned indicating the entity could not be found (block 425).


In summary, from an access perspective, an overlay dataset is simply another dataset and can be accessed and updated as such. From a system perspective, an overlay dataset is a façade over one or more specified, underlying or source datasets. Changes made to the overlay dataset occur within the overlay dataset only and do not affect the underlying dataset(s). Read operations directed to the overlay dataset will find entities in the overlay dataset if they exist and in the underlying dataset(s) if no overlay-specific entity exists. Accordingly, overlay datasets in accordance with the invention provide an efficient mechanism for making changes to a an existing dataset without suffering the high processing time and storage overhead associated with prior art copying and versioning techniques. In addition, entities in an underlying, source or base dataset that are not expressly modified in the overlay dataset are inherently synchronized in the overlay dataset. That is, changes to these entities in the underlying datasets are intrinsically visible when using the overlay dataset (unless the entity has been explicitly modified in the overlay dataset).


By way of example, overlay datasets have been implemented in the BMC Atrium™ CMDB product—a configuration management database product. (BMC ATRIUM is a trademark of BMC Software, Inc. of Houston, Tex.) It will be recognized by one of ordinary skill that a configuration management database is a database that contains information about the components in an organization's information system and the relationships between those components. Such components, within the context of a configuration management database, are generally referred to as configuration items. Thus, configuration items are software structures that represent information technology components. Illustrative configuration items represent: software applications, patches and modules; complete computer systems; components within a computer system such as storage units and network switches; people; departments; computer networks; and the relationships between different configuration items.


The BMC Atrium CMDB product utilizes an object-oriented model on a relational database whose elements are defined in terms of a series of objects organized in accordance with a common data model. As shown in Table 1, one embodiment of a dataset object in accordance with the invention includes two attributes that implement the overlay concept. The DataSetType attribute simply identifies a dataset as being an overlay dataset or a non-overlay dataset. The SourceDatasetId identifies the dataset which is the overlay dataset's underlying, base, source or member dataset. In another embodiment, the SourceDatasetId attribute may be a semicolon delimited list of unique dataset identifiers—thereby permitting more than one dataset to be a base, underlying or source dataset. In addition, each object class such as a collection (e.g., an organization), a logical entity (e.g., a business service), a system component (e.g., a storage disk) or system (e.g., an application suite) has a dataset identifier attribute. When a configuration item is instantiated, its dataset identifier attribute is assigned a value that uniquely identifies the dataset to which it belongs. This attribute provides the “glue” which associates individual configuration items with a dataset.









TABLE 1







Example Dataset Object









Attribute
Type
Comment





Accessibility
Integer
A first value (e.g., “0”) indicates the dataset is




writable by any client - that is, configuration items




may be added to the dataset. A second value (e.g.,




“1”) indicates the dataset is read-only for all clients. A




third value (e.g., “2”) could be ‘client-dependent’ such




that only those clients explicitly identified here (or in




another attribute, not shown) are permitted to have write




access.


CoreDatasetId
Character
Dataset's unique identifier.


DatasetType
Integer
A first value (e.g., “1”) indicates the dataset is on




overlay dataset. A second value (e.g., “0”) indicates




the dataset is a non-overlay dataset.


Name
Character
Name of dataset.


SourceDatasetId
Character
Identifier for the underlying, base or source dataset.









In the illustrative embodiments described above, if any attribute of an entity was modified through an overlay dataset, the entire entity (including its relationships) is replicated into the overlay dataset with the designated changes being made. In other embodiments, however, overlay dataset granularity may be at the attribute or “aggregate entity” level. At the attribute level, only those specific changes to an entity's attributes (including relationships) are replicated into the overlay dataset with all non-modified attributes being retained in the base or underlying dataset's entity. At the aggregate entity level, if any attribute to a specified collection of entities is modified (e.g., a computer system comprising a number of different components, each of which may be associated with an entity/configuration item), the entire collection of entities is replicated into the overlay dataset.


Thus, various changes in the structure as well as in the details of the illustrated operational methods are possible without departing from the scope of the following claims. For example, overlay datasets may be implemented in program code and incorporated in a database management system or configuration management database. Further, acts in accordance with FIGS. 2 and 4 may be performed by a programmable control device executing said program code. A programmable control device may be a single computer processor, a special purpose processor (e.g., a digital signal processor, “DSP”), a plurality of processors coupled by a communications link or a custom designed state machine. Custom designed state machines may be embodied in a hardware device such as an integrated circuit including, but not limited to, application specific integrated circuits (“ASICs”) or field programmable gate array (“FPGAs”). Storage devices suitable for tangibly embodying program instructions include, but are not limited to: magnetic disks (fixed, floppy, and removable) and tape; optical media such as CD-ROMs and digital video disks (“DVDs”); and semiconductor memory devices such as Electrically Programmable Read-Only Memory (“EPROM”), Electrically Erasable Programmable Read-Only Memory (“EEPROM”), Programmable Gate Arrays and flash devices.

Claims
  • 1. A database method, comprising: receiving a request for a database entity associated with an overlay dataset, the overlay dataset comprising one or more base datasets;returning the entity from the overlay dataset if the entity exists in the overlay dataset; andreturning the entity from one of the one or more base datasets if the entity does not exist in the overlay dataset.
  • 2. The method of claim 1, wherein the database comprises an object-oriented database and the entity comprises an object.
  • 3. The method of claim 1, wherein the database comprises a relational database and the entity comprises a record.
  • 4. The method of claim 1, wherein the entity comprises a configuration management database and the entity comprises a configuration item.
  • 5. The method of claim 1, wherein at least one of the one or more base datasets comprise a second overlay dataset.
  • 6. A database method, comprising: receiving a request for a database entity associated with an overlay dataset, the overlay dataset comprising one or more base datasets;searching the overlay dataset and the one or more base datasets for the database entity to generate a result list;sorting the result list; andreturning the first instance of the entity from the result list.
  • 7. The method of claim 6, wherein the database comprises an object-oriented database and the entity comprises an object.
  • 8. The method of claim 6, wherein the database comprises a relational database and the entity comprises a record.
  • 9. The method of claim 6, wherein the entity comprises a configuration management database and the entity comprises a configuration item.
  • 10. The method of claim 6, wherein at least one of the one or more base datasets comprise a second overlay dataset.
  • 11. The method of claim 6, wherein the act of searching the overlay dataset and the one or more base datasets is performed in a single search.
  • 12. A database method, comprising: obtaining, through an overlay dataset, a database entity from a first base dataset, the first base dataset being a member of the overlay dataset;modifying the entity; andreplicating the entity into the overlay dataset such that the entity in the first base dataset is not modified.
  • 13. The method of claim 12, further comprising: receiving a request for the entity through the overlay dataset; andreturning the entity replicated into the overlay dataset.
  • 14. The method of claim 13, further comprising: receiving a request for the entity through the first base dataset; andreturning the entity from the first base dataset.
  • 15. The method of claim 13, further comprising: receiving a request for a second entity through the overlay dataset, the second entity existing in the first base dataset and not the overlay dataset; andreturning the second entity from the first base dataset.
  • 16. The method of claim 12, wherein the database comprises an object-oriented database and the entity comprises an object.
  • 17. The method of claim 12, wherein the entity comprises a configuration management database and the entity comprises a configuration item.
  • 18. A method for using a database, the database including an overlay dataset, the overlay dataset including a first base dataset having a first entity and a second entity, the method comprising: receiving a request for the first entity through the overlay dataset;obtaining the first entity from the first base dataset;modifying the first entity;storing a copy of the modified first entity in the overlay dataset;receiving, thereafter, a request for the first entity through the overlay dataset;returning the modified first entity from the overlay dataset;receiving a request for the second entity through the overlay dataset; andreturning the second entity form the first base dataset.
  • 19. The method of claim 18, wherein the overlay dataset comprises a second base dataset.
  • 20. The method of claim 18, wherein the first base dataset comprises a second overlay dataset.
  • 21. The method of claim 18, wherein the database comprises an object-oriented database and the entity comprises an object.
  • 22. The method of claim 18, wherein the database comprises a relational database and the entity comprises a record.
  • 23. The method of claim 18, wherein the entity comprises a configuration management database and the entity comprises a configuration item.
  • 24. A program storage device, readable by a programmable control device, comprising instructions stored thereon for causing the programmable control device to perform the method of claim 1.
  • 25. A program storage device, readable by a programmable control device, comprising instructions stored thereon for causing the programmable control device to perform the method of claim 6.
  • 26. A program storage device, readable by a programmable control device, comprising instructions stored thereon for causing the programmable control device to perform the method of claim 12.
  • 27. A program storage device, readable by a programmable control device, comprising instructions stored thereon for causing the programmable control device to perform the method of claim 18.
  • 28. An overlay dataset data structure stored in a computer readable medium for use in a database, comprising: a first value uniquely identifying the data structure;a second value identifying the data structure as being associated with an overlay dataset; anda third value identifying one or more additional datasets, wherein each of the one or more additional datasets are associated as members of the overlay dataset.
Parent Case Info

This application claims priority to the U.S. provisional patent application 60/745,870, entitled “Overlay Dataset,” filed 28 Apr. 2006 and which is hereby incorporated by reference. This application is also related to U.S. patent application Ser. No. 11/204,189, entitled “Resource Reconciliation,” filed 15 Aug. 2005 and which is hereby incorporated by reference.

Provisional Applications (1)
Number Date Country
60745870 Apr 2006 US