US 20100169380 A1
Systems and methods for a generic data model for the representation of an arbitrarily complex environment are disclosed. These systems and methods allow the representation of any logical or physical entity and the associations and dependencies between these entities. Components may be used to represent the entities while relationships may be used to represent the associations and dependencies between the entities. A typing system may be utilized in conjunction with a generic data model to define a hierarchy of components and relationships for use with a particular category of environments. The data structures associated with a generic data model may be stored utilizing a table schema which does not change with the addition of new data structures or types of data structures. Applied data models created from these generic data models may be searched utilizing a query language which allows efficient searching of the applied data model, and structuring of the concomitant results.
1. A method of modeling an arbitrarily complex environment, comprising:
providing a system comprising a computer for defining a data model having a set of data structures comprising components and relationships and a database for storing a table for each type of data structure in the data model including a component table for storing components, the component table comprising a component type column, a component type table which defines a set of component types, wherein the component type column of the component table links a defined component to a component type, a relationship table for storing relationship, the relationship table comprising a relationship type column and at least one component ID column wherein the relationship is associated with at least one component in the component table through at least one component ID columns, and a relationship type table which defines a set of relationship types, wherein the relationship type column of the relationship table links a defined relationship to a relationship type;
representing an environment using the data model, wherein representing the environment comprises instantiating components from the plurality of component types to represent a first set of entities in the environment and storing the instantiated components in the component table;
instantiating relationships to represent relationships associated with the first set of entities and storing the instantiated relationships in the relationship table; and
linking each relationship to at least one component in the component table using the at least one component ID column associated with that relationship.
This application claims priority under 35 U.S.C. §120 to U.S. patent application Ser. No. 10/802,304, entitled “Adaptive System For Dynamic Object-Oriented Schemas” by Miller, et al., filed on Mar. 17, 2004, which in turn claims priority under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 60/455,522, entitled “System and Method for Collecting, Modeling and Querying Information Technology Information” by Miller, et al., filed on Mar. 18, 2003. This application is related to U.S. patent application Ser. Nos. 10/803,133, entitled “Method and System for Querying an Applied Data Model” by Miller et al., filed on Mar. 17, 2004, and issued as U.S. Pat. No. 7,558,790 on Jul. 7, 2009; and 10/802,178, entitled “Method and System for Discovering Relationships” by Miller et al., filed on Mar. 17, 2004, and issued on Apr. 21, 2009 as U.S. Pat. No. 7,523,128. All applications cited within this paragraph are assigned to the current assignee hereof and are fully incorporated herein by reference.
This application contains a computer program listing, attached as Appendices A and B.
The material in the attached appendices A-B is hereby fully incorporated by reference.
The invention relates in general to modeling data, and more particularly, to modeling an arbitrarily complex information technology environment with a generic data model.
The world is comprised of a wide and varied assortment of environments and subsystems. Akin to the proverbial butterfly flapping its wings in China and causing a hurricane over Texas, miniscule changes to one part of an environment may have catastrophic ripple effects in a distant part of the same environment. To anticipate these effects, it is helpful to study the ramifications of a change before it occurs. In order to observe the effects of these changes on an environment, it is useful to create a model of the environment. This model can then be used to discover the consequences of a change, and the combinatorial effects of multiple alterations to the environment.
However, because of the varied nature of their composition, many types of environments do not lend themselves to modeling. A microcosm of this problem occurs in many information technology (IT) environments. These IT environment may be intended to have a wide variety of uses: disseminating information about goods and services offered through a site on the World Wide Web, storing internal information related to a business, providing a programming infrastructure for development of software, or keeping track of sales and sales force information.
Consequently, these IT environments grow organically, sewn together in a Frankenstinian manner from a variety of heterogeneous machines and applications. Predicting the effects of machine crashes, application installations, network outages etc. on these IT environments is almost an exercise in futility without some sort of model. However, modeling these types of environments is a daunting prospect.
Typically, there are two approaches to creating models for these IT environments. The first is to create a diagram or a spreadsheet based inventory of the hardware assets and software applications that exist within the environment. This approach is problematic, creating these models requires an in depth evaluation of an IT system and manual creation of the documents, and whole document retention systems must be kept in place to version and store the documents associated with these types of models. Additionally, changes to the IT environment wreak havoc on these models. The effects from these changes must be manually traced through each of the diagrams, which are not only particularly prone to errors, but time consuming as well. Other problems with storing these models in documents include that there may be a large number of users who need to be able to access and modify these documents, and documents of this type don't lend themselves to concurrent modification, and that it is very difficult to cross-reference information across these documents.
The second approach, equally problematic, is to store the machines and applications which comprise the IT environment in tables in a relational database. Models created with these relational database tables, however, are particularly susceptible to changes in the IT environment itself. Adding layers, applications or dependencies to an IT environment may require changes to the table schema implementing the model, which may in turn may entail revising all the SQL statements used to implement the database. Therefore, in order to create a model using a relational database an in depth understanding of the IT environment is required, along with a relatively stable IT environment itself.
Thus, a need exists for methods and systems for a generic data model which can model an arbitrarily complex environment, and which allows the representation of any logical or physical entity and the associations and dependencies between these entities in a stable table schema which may be easily modified.
Systems and methods for a generic data model for the representation of an arbitrarily complex environment are disclosed. These systems and methods allow the representation of any logical or physical entity and the associations and dependencies between these entities. Components may be used to represent the entities while relationships may be used to represent the associations and dependencies between the entities. A typing system may be utilized with a generic data model to define a hierarchy of components and relationships for use with a particular category of environments. The data structures associated with a generic data model may be stored utilizing a table schema which does not change with the addition of new data structures or types of data structures. A query language may be utilized with a generic data model to search specific applications of the generic data model according to specific criteria.
In one embodiment at least two entities in the environment are represented with a component and an association between at least two components is represented with a relationship.
In another embodiment, each component is instantiated based on a component type.
In yet another embodiment, each relationship is instantiated based on a relationship type.
In still other embodiments, each component is represented in a component table.
In yet other embodiments, each relationship is represented in a relationship table.
In some embodiments, the relationship table links each relationship to at least two components.
These, and other, aspects of the invention will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. The following description, while indicating various embodiments of the invention and numerous specific details thereof, is given by way of illustration and not of limitation. Many substitutions, modifications, additions or rearrangements may be made within the scope of the invention, and the invention includes all such substitutions, modifications, additions or rearrangements.
The drawings accompanying and forming part of this specification are included to depict certain aspects of the invention. A clearer impression of the invention, and of the components and operation of systems provided with the invention, will become more readily apparent by referring to the exemplary, and therefore nonlimiting, embodiments illustrated in the drawings, wherein identical reference numerals designate the same components. Note that the features illustrated in the drawings are not necessarily drawn to scale.
The invention and the various features and advantageous details thereof are explained more fully with reference to the nonlimiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well known starting materials, processing techniques, components and equipment are omitted so as not to unnecessarily obscure the invention in detail. Skilled artisans should understand, however, that the detailed description and the specific examples, while disclosing preferred embodiments of the invention, are given by way of illustration only and not by way of limitation. Various substitutions, modifications, additions or rearrangements within the scope of the underlying inventive concept(s) will become apparent to those skilled in the art after reading this disclosure.
Reference is now made in detail to the exemplary embodiments of the invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts (elements).
A few terms are defined or clarified to aid in an understanding of the terms as used throughout the specification. The term “component” is intended to mean a representation of any definable, logical or physical entity. A component may have a group of properties. In an IT environment, an entity may be any portion of the environment desired to be represented, including hardware, such as a server or database, applications which may reside on one or more actual machines, virtual data repositories, firmware and the like. Many levels of abstraction are possible. For example, a network may be represented as a component, a subnetwork of that network may be represented as a component, a server on the subnetwork may also be represented as a component, an application running across that server and other servers may also be represented as a component, a table within that application may be represented as a component, etc.
The term “relationship” is intended to mean a representation of an association or dependency between two or more components. This association may be based on the property values of the components.
The term “blueprint” is intended to mean a representation of a container for two or more components and their associated relationships.
The term “check” is intended to mean a determination whether a relationship is valid, or a determination regarding the value or validity of a property of a component. Checks may be associated with components or relationships. In some cases a check is a piece of software which may be associated with a relationship or component. A check may have an output event, such as an email or notification.
The term “property” is intended to mean a characteristic associated with a component or a relationship. This property may have a name and a value associated with it, and components of the same type may have different values for the same property.
The term “type” is intended to mean a category of a relationship or a component. All relationships or components of the same type will have the same properties, though each instance of a component or a relationship may have different values for those properties. For example, a component type named “ComputerType” may be defined, having the properties of “RAM” and “OSType”. Each instance of component type “ComputerType” will have the properties “RAM” and “OSType”, however in one instance the value of “RAM” may be 4 megabytes, while in another instance the value of “RAM” may be 8 megabytes.
The term “data model” is intended to mean a model for representing anything in the physical world, coupled with logic pertaining to that representation.
The term “query” is intended to mean a statement intended to search an applied data model. A query may be comprised of a component query, which returns one or more components, or a relationship query which returns one or more relationships. A query is usually built with clauses and conjunctions.
The term “clause” is intended to mean a statement that may return a component, relationship, etc. based on criteria, such as a component's core attributes, component sets, relationships etc.
The term “conjunction” is intended to mean any statement which combines clauses or changes the order in which a clause is evaluated. Common conjunctions are “and”, “or”, “not” and the like.
The term “subtype” is intended to mean a specialization of a particular type of component or relationship. For example, a component type “computers” may be defined with certain properties. A more specialized version of the “computer” type may be represented as a subtype of “computer” called “server computer”. The subtype “server computer” will inherit all the properties of its parent type “computer”. A subtype is also a type, consequently subtypes may themselves be parents of subtypes.
Before discussing embodiments of the present invention, a non-limiting, simple IT environment used in depicting embodiments and examples of the present invention is briefly described. After reading this specification, skilled artisans will appreciate that many other more complicated environments may be utilized with embodiments of the present invention.
IT environment 100 may further contain database server application 120 and web server application 130. Database server application 120 and web server application 130 may have certain attributes 122, 132 which pertain to their particular implementation. For example, each may utilize certain storage resources, have a certain filesystem structure, require a certain operating environment, and have a certain footprint. Other attributes will be readily apparent to those of ordinary skill in the art. Each of these software applications 120, 130 may be executing on server computer 110. Additionally each of the computers in
Attention is now directed to methods and systems for the generic modeling of data, and how to apply these generic data models to an arbitrarily complex environment. These systems and methods may model data generically by using a schema composed of three primitive data structures: components, relationships and blueprints. Components may be used to model any type of atomic entity, relationships may be used to model associations or dependencies between two or more components, and blueprints may be used to model an entire environment or subset of an environment. These data structures provide the ability to capture the state of any environment, represent this environment, and dynamically accommodate changes to the environment with a minimum of impact on the model of the environment, the underlying data structures themselves or the way these data structures are stored and represented. Once these applied data models are created they may be searched utilizing a query language which allows efficient searching of the applied data model, and structuring of the concomitant results. Though an IT environment will be used as an exemplary environment to demonstrate the power and flexibility of the data model, after reading this disclosure it will be apparent to those of ordinary skill in the art that this type of data model may be utilized to model any arbitrarily complex environment.
In an illustrative embodiment of the invention, the computer-executable instructions may be lines of assembly code or compiled C++, Java, or other language code. Other architectures may be used. Additionally, a computer program or its software components with such code may be embodied in more than one data processing system readable medium in more than one computer.
Turning now to
Property field 240 may be used to represent the attributes or characteristics of the physical or logical entity represented by component 200, or with which component 200 is associated.
Property field 240 may be associated with one or more properties, a property may consist of a property name which may be associated with a value. This value in turn may correspond to an attribute of the physical or logical entity represented by component 200. A property may be a string, boolean, decimal number, date/time, or an enumerated type, which describes the category of values a particular property may have. In one embodiment, a property may in turn be a data structure which has a name, a description, and a value. This data structure may then be given values based on an attribute of the entity represented by component 200.
Component 200 may also be related to a set of checks 250. A check may be a piece of logic which performs operations based on a certain set of conditions. These operations may consist of checking on the status of certain relationships associated with the component 200 (as described below), checking the status of certain properties 240, and other operations which will be readily apparent. These pieces of logic may be configured to operate automatically at certain time intervals, or may be applied at any point according to a variety of different triggering conditions which will be apparent to one of ordinary skill in the art after reading this disclosure.
Referring briefly back to
Similarly, component 200 may represent database server 120; name field 220 may be set to “DB1”, description 230 may be set to “database server application”, property field 240 may contain three properties “OSType”, “Footprint”, and “Listen Port”, which may be assigned the values corresponding to attributes 122 of database server 120, “Solaris”, “12 MB” and “2100” respectively. As can be seen, component 200 may represent any entity, whether logical or physical equally well.
Turning now to
Returning for a moment to
However, as can be readily imagined, instantiation and definition of components and relationships for a complex environment may be a manually intensive process. To alleviate these concerns, in one embodiment, a typing system is included to allow the ability to define a hierarchy of component and relationship types which may serve as templates to instantiate components or relationships of these different types.
A hierarchy 400 of component types 410, 420, 430 is depicted in
Generic component type 410 may have a set of fields as described above. These fields may include a name or description 412, a set of properties 414, and a set of checks 416. A generic component may be instantiated from generic component type 410, and used to represent an atomic entity. For example, in order to represent server computer 110, a user may instantiate component 200 from generic component type 410, name component 200, define the list of properties pertinent to server computer 110, give these properties values based on the attributes of server computer 110, define checks pertinent to server computer 110, etc. In this manner, component 200 can be created which represents server 110 accurately. However, representing a complex environment in this manner becomes labor intensive, as a component to represent each atomic entity within the environment may have to be created manually.
To remedy this problem, more specific component types may be defined which serve as templates to instantiate components which represent specific entities in an environment. For example, a computer component type 420 may be defined to serve as a template for components which represent computers. This computer component type 420 may contain properties 424 or checks 426 which are designed to represent a generic computer. A property within the set of properties 424 may contain a name and enumerated type corresponding to the values which that property may have. As expressed above, a property within the set of properties 424 may itself be a data structure; in this case a property may contain a name and a reference to a data structure. Examples of property names and their corresponding enumerated types are depicted in properties 424 of computer component type 420. Properties 424 and checks 426 will be common to all components instantiated from computer component type 420; in other words, all components instantiated from computer component type 420 will contain properties 424 and checks 426 of computer component type 420. This computer component type 420 may be used to instantiate component 200 to represent a computer in an environment, this component's 200 properties can then be assigned values based on the attributes of the computer which component 200 is intended to represent.
Returning now to
In some embodiments, a component subtype may be defined with respect to a parent component type. This component subtype represents a specialized subgroup of the respective parent component type. A component instantiated from a component subtype may inherit all the properties and checks corresponding to its respective parent component type. This inheritance mechanism allows the definition of a component subtype to contain only those properties and checks which are desired and which are not contained in the parent component type. Consequently, when component 200 is instantiated from a component subtype, component 200 contains all the properties and checks contained in the definition of the component subtype plus all the properties and checks contained in the definition of the parent component type.
For example, computer component type 420 may be defined to serve as a template for components which represent computers. This computer component type 420 may contain checks 426 or properties 424 which correspond to a generic computer, and will be common to all components instantiated from computer type 420. A server computer component subtype 430 may be defined with respect to parent computer component type 420. This definition may include only properties 434 and checks 436 specific to server computer component subtype 430. Consequently, when a component is instantiated from server computer component subtype 430 this component will contain all the properties 424, 434 and checks 426, 436 contained in both the parent computer component type 420 and the server computer component subtype 430. For example, if component 200 were instantiated from server computer component subtype 430, component 200 would contain the properties named “OSType”, “RAM”, and “CPU” contained in parent computer component type 420, and the property “FreeStorage” contained in server computer component subtype 430. These properties may then be assigned values.
It will be apparent to those of ordinary skill in the art the recursive nature of this type/subtype correlation and the inheritance characteristics that accompany these correlations. For example, a subtype may be the parent type of a second subtype. In addition to containing the checks and properties defined in the second subtype, a component instantiated from the second subtype will contain the checks and properties defined in both the first subtype and the original parent. The power and flexibility of such a system will also be apparent, a component hierarchy specifically tailored to any environment can be defined from a generic component type.
As described above, relationships are used in tandem with components to model arbitrary systems and environments by representing an association or dependencies between two components. As will be readily apparent, the same reasoning that applies to components
with respect to a hierarchy of types may be applied equally well to relationships. Manual instantiation of relationships may be time consuming if the representation of many dependencies or associations is necessary. Consequently, types and subtypes corresponding to a particular category of these dependencies or associations may also be defined for relationships, and relationships instantiated from these defined types and subtypes. All principles described with respect to types and subtypes in the context of components are equally applicable to relationships, including the principle of inheritance.
Moving on to
Database server 120 executes on server computer 110. To represent this association, relationship 640 may be named “runs on”, FirstComponentID field 360 of relationship 740 may be linked to component 620 representing database server 120, while SecondComponentID 370 may be linked with component 610 corresponding to server computer 110, and properties of relationship 640 may be defined accordingly. In this manner, the fact that database server 120 executes on server computer 110 may be modeled by relationship 640. Likewise, the fact that web server 130 also executes on server computer 110 may also be modeled. Relationship 650, also of type “runs on”, may be instantiated, given properties, and associated with components 610, 630 representing web server 130 and server computer 110 using FirstComponentID field 360 and SecondComponentID field 370. This type of data model allows changes to an environment to be accommodated with a minimum of disturbance to the model of that environment. In particular embodiments, a blueprint may be used to contain the entire representation 600 of the IT environment.
Suppose that the IT environment depicted in
Additionally, the data structures corresponding to a particular data model may be stored in a schema which allows the addition of components, relationships, properties and types without any change to the underlying schema used to represent these data structures.
ComponentType table 910 may define component types (as discussed above), and contain a set of columns 915 related to fields of a component type. “Parent” column 912 may be used to represent the parent of a component type, in this case each subtype contains a reference to its parent component type.
RelationshipType table 950 is constructed substantially the same as ComponentType table 910 and contains a set of columns 955 including a parent column 952.
PropertyCategory table 930 may also contain a set of columns 935 related to the definition of a property. PropertyCategory table 930 may define categories of properties, and provide a hierarchical structure for properties based on a type. For example, on computer component 420 there may be three divisions of properties, hardware information, operating system information and IT personnel information. Rather than having these properties mixed together as one large group, it may be helpful to divide these properties into three separate categories. Categories within PropertyCategory table 930 may form an arbitrarily deep tree, where any category in the tree can contain property definitions.
Each category within PropertyCategory table 930 may be associated with a component type or relationship type. In one particular embodiment, this association may be through the componentTypeId field 932 or relationshipTypeId field 934 respectively, while an association with a parent category may be established through the parent field 936.
PropertyDefinition table 940 may contain definitions of particular properties defined by columns 945. Properties within PropertyDefinition table 940 may be defined with respect to a category, and may contain a link to this category in propertyCategoryID field 946. To increase performance, property definitions may also have links back to the component type or relationship type with which they are associated through the componentTypeId field 942 or relationshipTypeId field 944 respectively. Property definitions within PropertyDefinition table 940 may also provide meta information such as name, or input/output attributes. In one embodiment, these definitions do not have values, they only describe what properties exist with respect to a component type or relationship type, not the values these properties actually have.
Relationships are stored in the Relationship table 960. Relationships are associated with components through firstComponentID field 962 and secondComponentID field 964, and may have a link to their relationship type through typeID field 966. Note that this representation depicts relationships as having two ends (that is, they are binary), those of ordinary skill in the art will realize after reading this disclosure that other database schemes could be created that allow relationships to have arbitrary numbers of components simply by removing the firstComponentID and secondComponentID fields from relationship table 960 and creating a new table called RelationshipToComponent that has two columns: a relationship ID and a component ID. Each relationship would have n rows in this table corresponding to the n components attached to the relationship.
Components are stored in the Component table 920. Components may be linked to their type through typeID field 922. Components in turn may have subcomponents, which in turn can have subcomponents etc. Thus, components may form hierarchies of arbitrary depths. This containment correlation should not be confused with the type/subtype correlation described above. For example, a database component may contain table subcomponents, which contain column subcomponents etc. Yet no inheritance is implied, since a column is not a table, which is not a database etc. These component hierarchies are established through the parent field 922 which may link a subcomponent with its parent component.
PropertyValue table 970 may be used to associate a value with a property definition for a particular component or relationship. Each property value within PropertyValue table 970 may have a link to a property definition using the field propertyDefinitionID 972, and a link to either the component or relationship with which it is associated using componentID 974 or relationshipID 976.
To illustrate why a schema of this type may remain static whenever a new property, component or relationship is added, an example is helpful. Suppose there are two components in an environment, “Server1” and “Server2”, and both these components have been instantiated from the one component type, “ComputerType”. Component type “ComputerType” has three properties defined with respect to it, “RAM”, “OSType” and “FreeStorage”. Therefore, “Server1” and “Server2” both have three values associated with these properties.
These properties and values are illustrated in
Now, suppose it is desirable to model another type of property, called “Cache”, with respect to “ComputerType” component shown in ComponentType table 1000. Rather than having to add new tables or columns to the table schema, all that may be required is the addition of rows to the existing table.
The addition of these properties and values is illustrated in
Model 1630 may implement a data model, and the applied data models created using the data model. Model 1630 is responsible for creating the components, relationships, properties and blueprints which may make up an applied data model. These elements of an applied data model may then be stored in the table schema implemented in database 1610. Model 1630 may access these stored elements and make alterations to the applied data model. In one embodiment, to access database 1610, model 1630 may issue an SQL statement, as is commonly known in the art.
Model 1630 may access database 1610 through database connectivity 1640. Database connectivity 1640 may serve as an interface between model 1630 and database 1610. This may consist of translating statements or queries issued by model 1630 into commands which database 1610, or database management system (DBMS) associated with database 1610, may understand. In one particular embodiment, database connectivity 1640 is a standard database access methodology such as Java Database Connectivity (JDBC) or Open Database Connectivity (ODBC) capable of translating SQL commands issued by model 1630 into commands capable of execution by a DBMS associated with database 1610.
Manager 1620 may be a set of service intended to aid in the management, control and access of model 1630. Manager 1620 may be an abstraction layer that allows access to model 1630 from other application which utilize model 1630. As the complexity of model 1630 increases it becomes increasingly difficult to glean desired information, or associations from model 1630. To combat this problem, manager 1620 may provide an efficient system for accessing and retrieving information contained in model 1630.
These systems may be capable of accessing information based on a wide variety of criteria, including properties and groupings of relationships or components. Additionally, these systems may allow access to arbitrary depths of complex dependencies for a component, relationship, property or type of component, relationship or property.
In one embodiment, this system uses a language which aids in searching or querying model 1630 to retrieve a set of components or relationships. This language may translate a statement in a certain format to one or more statements which may be employed by model 1630 or database connectivity 1640.
Users or applications which employ model 1630 may desire to obtain information from model 1630 based on a wide variety of criteria, such as component core attributes, component hierarchies, component types, property values, relationship types, etc. To obtain this information users or applications may formulate a query, which may then be received (block 1710) by model 1630 or manager 1620.
In one embodiment, a language may exist which assists in the formulation of a query. As explained above, an applied data model of an environment may grow very complex and include a wide variety of component types and relationship types. To search through model 1620 which implements such an applied data model, it is helpful to have a language which allows the formulation of a query with a greater degree of specificity. It is also helpful if the language utilized aids efficient searching of database 1610 in which model 1630 is stored.
In a particular embodiment, a language of this sort may support two types of queries, component queries and relationship queries. Component queries may return components, whereas relationship queries may return relationships. These queries may be built with clauses and conjunctions. A clause is a statement that returns components or relationships based on criteria, a conjunction may combine clauses, or change the order in which a clause is evaluated. An example of a syntax and vocabulary for such a language is presented in Appendix C.
Once a query is received (block 1710) this query may be translated into a set of statements (block 1720) or commands which database connectivity 1640 or database 1610, or database management system (DBMS) associated with database 1610, may understand. In one particular embodiment, the set of statements may be translated (block 1720) from a query language into a set of SQL commands capable of execution by a DBMS associated with database 1610. These statements may also be tailored to model 1630 stored in database 1610.
Based on this set of statements, an applied data model resident in database 1610 may be searched (block 1730). Embodiments of the data model described above may be applied to generate an applied data model, and this applied data model may consist of a set of components and a set of relationships that exist between these components. These sets of relationships and components interrelate to one another in such a way that a graph may be used to represent an applied data model.
For example, suppose an applied data model utilizes three component types: “business unit”, “application” and “machine”, and three relationship types: “uses application”, “sends data to”, and “runs on”. The relationship type “uses application” is defined so it may describe associations or dependencies between components of type “business unit” and components of type “application”. The relationship type “sends data to” is defined so it may describe associations or dependencies between components of type “application” and components of type “application”, and relationship type “runs on” is defined so it may describe associations or dependencies between components of type “application” and components of type “machine”. Though these sets of relationships and components may be represented as three component tables and three relationship tables as described above; these sets may also be represented and stored as a graph of components and relationships.
As can be seen from
In embodiments of this algorithm, the temporary table Temp now holds the ID's of all components desired. The table Temp to may be cross-referenced to the Component table (described above) to get the components identified.
It is important to note that using this algorithm to search an applied data model may be especially efficient. Embodiments of the algorithm are independent of the component or relationship types used in a data model. Additionally, embodiments of the algorithm may allow the traversal of a number of arbitrary levels in a particular graph.
For example, “send data to” relationship 1860 may have an arbitrary number of levels depending on the structure and complexity of the environment being represented with an applied data model. Utilizing embodiments of the algorithm these levels may be traversed without regard to their depth.
Embodiments of this algorithm, used with an applied data model of the kind described above, also have the advantage that no understanding of the schema or data model is needed to generate results. For example, a trace may be run on business unit types 1810. This trace (applying an embodiment of the algorithm above) may result in all components of machine type 1820 and application type 1830 related to each business unit component type 1810, agnostic of the relationships in the applied data model.
Moreover, this algorithm will allow efficient searching of an applied data model irrespective of changes to the schema used to represent the applied data model.
Imagine that a new component type “application server” 1910 is inserted into the schema depicted in
Contrast these capabilities with a standard search. For example, using the graph depicted in
As can be seen by one of ordinary skill in the art, this SQL algorithm is not independent of the component types used in an applied data model. The SQL algorithm cannot trace out arbitrary numbers of levels. It is virtually impossible using standard SQL for this algorithm to trace out arbitrary depths along the arbitrarily deep relationship type “sends data to” 1860 path. Thus, the SQL algorithm will not be able to return all the components associated with this relationship type.
Additionally, because the schema is hard-coded in the algorithm, an end user must understand the schema. Essentially the end user has to tell the algorithm the specific path through the entity/relationship diagram to trace. Searches utilizing this SQL algorithm will break if the schema is changed. If we added an “application server” type 1910 as depicted in
Note that not all of the tables, fields, or steps described are necessary, that tables, fields or steps may not be required, and that further tables, fields or steps may be added in addition to those illustrated. Additionally, the order in which each of the activities is listed is not necessarily the order in which they are performed. After reading this specification, a person of ordinary skill in the art will be capable of determining which tables, fields and orderings best suit any particular objective.
In the foregoing specification, the invention has been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of invention.
Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.