PRIORITY CLAIM AND CROSS-REFERENCE

This application claims priority to Indian Patent Application No. 202241038761, filed July 6, 2022, which is hereby incorporated by reference in its entirety.

FIELD OF INVENTION

[0001] The present invention relates to inventory management and entity management within a graph database and more specifically related to a method and a relationship constraint management server for managing relationship constraints associated with multiple entities.

BACKGROUND

[0002] Generally, in a graph database such as for example, j anusgraph database relationship constraints and type of a label defined between two edges or two entities are provided on a global graph level. However, the relationship constraints provided at the global graph level does allow a user to define different types of the same label with smaller scope. As a result, the different types of the same label will not have different multiplicity when defined between different entities or edges.

[0003] For example, consider a graph associated with networking, stored in the graph database. An edge label used here is “contains” which is defined between multiple entities such as CNFC “contains” CNF (step 102), CNF “contains” clusters (step 104) and CNF “contains” NS (step 106), as shown in FIG. 1. At step 102, the edge label “contains” defines a one-to-one relationship between the CNFC and the CNF, whereas the same edge label “contains” defines a many-to-one relationship between the CNF and the clusters and again the same edge label “contains” defines a many-to-one relationship between the CNF and NS. Since the relationship constraints which is indicated by the edge label is considered at the global graph level in the conventional graph database, the edge label “contains” defined at step 104 and step 106 are not allowed as edge label “contains” is defined at the global graph level as only one-to-one relationship, as defined at step 102. Therefore, the conventional graph database restricts the use of the same edge label to define different multiplicity of the same label in a scenario as indicated in the FIG. 1, where the user is required to same label. Thus, it is desired to address the aforementioned disadvantages or other shortcomings or at least provide a useful alternative.

OBJECT OF INVENTION

[0004] The principal object of the embodiments herein is to provide a method and relationship constraint management server for managing relationship constraints associated with entities by generating an entity configuration file for handling controls over relationships between the entities. The proposed relationship constraint management server allows a user to create edge labels with different multiplicity within a graph database which overcomes drawback of existing method of defining the edge labels at a global graph level.

SUMMARY

[0005] Accordingly, the embodiment herein is to provide a method for managing relationship constraints associated with entities in a graph database. The method includes receiving, by a relationship constraint management server, a request to perform an operation associated with an entity and generating, by the relationship constraint management server, an entity configuration file based on the received information of the entity. The request includes information of entity and the entity configuration file includes relationship constraint from a plurality of relationship constraints to be applied while performing the operation. Further, the method includes retrieving, by the relationship constraint management server, metadata corresponding to relationship constraints from a constraint database based on the entity configuration file and performing, by the relationship constraint management server, the operation associated with the entity based on the metadata corresponding to the relationship constraints and the information of the entity.

[0006] In an embodiment, the operation associated with the entity is a create operation, an update operation, and a delete operation.

[0007] In an embodiment, the method further includes determining, by the relationship constraint management server, the determined operation is the create operation and the update operation; and storing, by the relationship constraint management server, the created entity and the updated entity in the graph database.

[0008] In an embodiment, performing, by the relationship constraint management server, the operation associated with the entity based on the metadata corresponding to the relationship constraints and the information of the entity includes determining, by the relationship constraint management server, the operation associated with the entity is one of the create operation, the update operation and the delete operation and validating, by the relationship constraint management server, the information received for performing the determined operation associated with the entity by using a relationship constraint key for each of the relationship constraints on the information received for the entity. The method also includes performing, by the relationship constraint management server, the determined operation associated with the entity based on the metadata corresponding to the relationship constraints and the information of the entity.

[0009] In an embodiment, performing, by the relationship constraint management server, the create operation associated with the entity based on the metadata corresponding to the relationship constraints and the information of the entity includes generating, by the relationship constraint management server, the relationship constraint key for each of the relationship constraints based on the information of the entity. The determined operation is the creation operation. The method also includes adding, by the relationship constraint management server, the relationship constraint key for each of the relationship constraints in a constraint data field of the entity configuration file and validating, by the relationship constraint management server, the information received for creating the entity by using the relationship constraint key for each of the relationship constraints on the information received for creating the entity. The method also includes creating, by the relationship constraint management server, the entity based on the metadata corresponding to the relationship constraints and the information of the entity in response to successful validation of the information received for creating the entity.

[0010] In an embodiment, performing, by the relationship constraint management server, the update operation associated with the entity based on the metadata corresponding to the relationship constraints and the information of the entity includes retrieving, by the relationship constraint management server, the relationship constraint key for each of the relationship constraints in the constraint data field of the entity configuration file of the entity to be updated. The determined operation is the creation operation. The method also includes validating, by the relationship constraint management server, the information received for updating the entity by using the relationship constraint key for each of the relationship constraints on the information received for updating the entity and updating, by the relationship constraint management server, the entity based on the metadata corresponding to the relationship constraints and the information of the entity in response to successful validation of the information received for updating the entity.

[0011] In an embodiment, each relationship constraint of the plurality of constrain includes a relationship constraint type, a relationship constraint scope, a relationship constraint scope field, and a relationship constraint field.

[0012] In an embodiment, performing, by the relationship constraint management server, the delete operation associated with the entity based on the metadata corresponding to the relationship constraints and the information of the entity includes retrieving, by the relationship constraint management server, the relationship constraint key for each of the relationship constraints in the constraint data field of the entity configuration file of the entity to be deleted. The determined operation is the creation operation. The method also includes validating, by the relationship constraint management server, the information received for deleting the entity by using the relationship constraint key for each of the relationship constraints on the information received for deleting the entity and deleting, by the relationship constraint management server, the relationship constraint key for each of the relationship constraints in the constraint data field of the entity configuration file of the entity to be deleted; and deleting, by the relationship constraint management server, the relationship associated with the entity to be deleted.

[0013] Accordingly, the embodiments herein provide a relationship constraint management server for managing the relationship constraints associated with the entities in the graph database. The relationship constraint management server includes a memory, a processor, a communicator and a relationship management controller. The relationship constraint management server is configured to receive the request to perform the operation associated with the entity and generate the entity configuration file based on the received information of the entity. The request comprises the information of the entity and the entity configuration file includes the relationship constraint from the plurality of relationship constraints to be applied while performing the operation. The relationship constraint management server is also configured to retrieve the metadata corresponding to the relationship constraints from the constraint database based on the entity configuration file and perform the operation associated with the entity based on the metadata corresponding to the relationship constraints and the information of the entity.

[0014] Accordingly, the embodiments herein provide a computer program product (CPP) for managing relationship constraints associated with entities in a graph database. The CPP includes a computer executable program code recorded on a computer readable non-transitory storage medium. The said computer executable program code when executed causing the actions including receiving a request to perform an operation associated with an entity and generating an entity configuration file based on the received information of the entity. The request includes information of the entity and the entity configuration file includes relationship constraint from a plurality of relationship constraints to be applied while performing the operation. The said computer executable program code when executed causing the actions also including retrieving metadata corresponding to relationship constraints from a constraint database based on the entity configuration file; and performing the operation associated with the entity based on the metadata corresponding to the relationship constraints and the information of the entity.

[0015] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating preferred embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the scope thereof, and the embodiments herein include all such modifications.

BRIEF DESCRIPTION OF FIGURES

[0016] This invention is illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:

[0017] FIG. 1 is a scenario of a label defined at a global graph level in a graph database, according to a prior art;

[0018] FIG. 2 is a block diagram of a relationship constraint management server for managing relationship constraints associated with entities in the graph database, according to an embodiment as disclosed herein;

[0019] FIG. 3 is a flow chart illustrating a method for managing the relationship constraints associated with the entities in the graph database, according to an embodiment as disclosed herein;

[0020] FIG. 4 illustrates various examples of restricted and unrestricted relationships between various entities, according to an embodiment as disclosed herein;

[0021] FIG. 5A illustrates a one-to-many relationship scenario between multiple entities where a uniqueness violation is observed, according to an embodiment as disclosed herein;

[0022] FIG. 5B illustrates a many-to-one relationship scenario between multiple entities where the uniqueness violation is observed, according to an embodiment as disclosed herein; [0023] FIG. 6A illustrates step-by-step process for application of the relationship constraint at constraint vertex, according to an embodiment as disclosed herein;

[0024] FIG. 6B illustrates step-by-step process for application of the relationship constraints at edge, according to an embodiment as disclosed herein;

[0025] FIG. 7 illustrates step-by-step process for creation of a relationship constraint key during a schema, according to an embodiment as disclosed herein;

[0026] FIG. 8 illustrates step-by-step process for application of the relationship constraints in the graph database, according to an embodiment as disclosed herein;

[0027] FIG. 9 illustrates step-by-step process for deleting the relationship constraints and the generated relationship constraint key associated with the relationship constraints, according to an embodiment as disclosed herein; and

[0028] FIG. 10 illustrates step-by-step process for deleting the relationship constraints from all objects, according to an embodiment as disclosed herein.

DETAILED DESCRIPTION OF INVENTION

[0029] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted to not unnecessarily obscure the embodiments herein. Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments. The term “or” as used herein, refers to a non-exclusive or, unless otherwise indicated. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein can be practiced and to further enable those skilled in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

[0030] As is traditional in the field, embodiments may be described and illustrated in terms of blocks which carry out a described function or functions. These blocks, which may be referred to herein as managers, units, modules, hardware components or the like, are physically implemented by analog and/or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, and the like, and may optionally be driven by firmware. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like. The circuits constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block. Each block of the embodiments may be physically separated into two or more interacting and discrete blocks without departing from the scope of the disclosure. Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the disclosure.

[0031] The accompanying drawings are used to help easily understand various technical features and it should be understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the present disclosure should be construed to extend to any alterations, equivalents, and substitutes in addition to those which are particularly set out in the accompanying drawings. Although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are generally only used to distinguish one element from another.

[0032] Accordingly, the embodiment herein is to provide a method for managing relationship constraints associated with entities in a graph database. The method includes receiving, by a relationship constraint management server, a request to perform operation associated with an entity and generating, by the relationship constraint management server, an entity configuration file based on the received information of the entity. The request includes information of entity and the entity configuration file includes relationship constraint from a plurality of relationship constraints to be applied while performing the operation. Further, the method includes retrieving, by the relationship constraint management server, metadata corresponding to relationship constraints from a constraint database based on the entity configuration file; and performing, by the relationship constraint management server, the operation associated with the entity based on the metadata corresponding to the relationship constraints and the information of the entity.

[0033] Accordingly, the embodiments herein provide a relationship constraint management server for managing relationship constraints associated with entities in a graph database. The relationship constraint management server includes a memory, a processor, a communicator and a relationship management controller. The relationship constraint management server is configured to receive a request to perform operation associated with entity and generate an entity configuration file based on the received information of the entity. The request comprises information of entity and the entity configuration file includes relationship constraint from a plurality of relationship constraints to be applied while performing the operation. The relationship constraint management server is also configured to retrieve metadata corresponding to relationship constraints from a constraint database based on the entity configuration file and perform the operation associated with the entity based on the metadata corresponding to the relationship constraints and the information of the entity.

[0034] Accordingly, the embodiments herein provide a computer program product (CPP) for managing relationship constraints associated with entities in a graph database. The CPP includes a computer executable program code recorded on a computer readable non-transitory storage medium. The said computer executable program code when executed causing the actions including receiving a request to perform an operation associated with an entity and generating an entity configuration file based on the received information of the entity. The request includes information of the entity and the entity configuration file includes relationship constraint from a plurality of relationship constraints to be applied while performing the operation. The said computer executable program code when executed causing the actions also including retrieving metadata corresponding to relationship constraints from a constraint database based on the entity configuration file; and performing the operation associated with the entity based on the metadata corresponding to the relationship constraints and the information of the entity.

[0035] In the conventional graph database such as for example, j anusgraph database relationship constraints are provided on a global graph level for a particular edge label or type. However, the relationship constraints provided at the global graph level restricts defining same edge label or type on a smaller scope based on user requirement. Unlike the conventional graph database, the proposed method provides more flexibility in the graph database by building a custom layer on the top of the janusgrpah to allow the same edge label or type based on user requirement by defining the relationship constraint not at the global graph level.

[0036] Referring now to the drawings and more particularly to FIGS. 2 through 10, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments.

[0037] FIG. 2 is a block diagram of a relationship constraint management server (100) for managing relationship constraints associated with entities in a graph database (185), according to an embodiment as disclosed herein.

[0038] In an embodiment, the relationship constraint management server (100) includes a memory (120), a processor (140), a communicator (160) and a relationship management controller (180).

[0039] The memory (120) is configured to store instructions to be executed by the processor (140). The memory (120) may include nonvolatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (120) may, in some examples, be considered a non-transitory storage medium. The term “non-transitory” may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term “non-transitory” should not be interpreted that the memory (120) is nonmovable. In some examples, the memory (120) can be configured to store larger amounts of information. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

[0040] The processor (140) communicates with the memory (120), the communicator (160), and the relationship management controller (180). The processor (140) is configured to execute instructions stored in the memory (120) and to perform various processes. The processor may include one or a plurality of processors, may be a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an Artificial intelligence (Al) dedicated processor such as a neural processing unit (NPU).

[0041] The communicator (160) includes an electronic circuit specific to a standard that enables wired or wireless communication. The communicator (160) is configured to communicate internally between internal hardware components of the relationship constraint management server (100) and with external devices via one or more networks.

[0042] In an embodiment, the relationship management controller (180) is implemented by processing circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware. The circuits may, for example, be embodied in one or more semiconductors. The relationship management controller (180) includes an entity configuration generator (181), a relationship constraint manager (182), an entity manager (183), a constraint database (184) and a graph database (185).

[0043] In an embodiment, the entity configuration generator (181) is configured to receive a request to perform an operation associated with an entity and generate an entity configuration file based on the received information of the entity. The entity can be for example, students and colleges in a graph associated with academic; various departments of government in a graph associated with government organization, etc. The request includes information of the entity such as for example but not limited to type of entity, relationship of the entity with other entities, properties of the entity, etc. The entity configuration file includes the relationship constraints relevant for the entity out of multiple relationship constraints, to be applied while performing the operation. Each relationship constraint of the multiple constrains includes a relationship constraint type, a relationship constraint scope, a relationship constraint scope field, and a relationship constraint field.

[0044] In an embodiment, the relationship constraint manager (182) is configured to retrieve metadata corresponding to the relationship constraints from the constraint database (184) based on the entity configuration file. The metadata corresponding to the relationship constraints can be for example but not limited to a user details associated with creation of the relationship constraint, date of creation of the relationship constraint, etc.

[0045] In an embodiment, the entity manager (183) is configured to determine the operation associated with the entity is one of a create operation, an update operation and a delete operation and validate the information received for performing the determined operation associated with the entity by using a relationship constraint key for each of the relationship constraints on the information received for the entity. Further, the entity manager (183) is configured to perform the determined operation associated with the entity based on the metadata corresponding to the relationship constraints and the information of the entity. The operation associated with the entity can include but is not limited to the create operation for creation of the entity, the update operation for updating a feature of the already existing entity and the delete operation for deleting the existing entity from the graph database (185). When the operation is either the create operation or the update operation, then the entity manager (183) is configured to store the created entity and the updated entity in the graph database (185) automatically.

[0046] The entity manager (183) performs the create operation as the entity manager (183) is configured to generate the relationship constraint key for each of the relationship constraints based on the information of the entity and add the relationship constraint key for each of the relationship constraints in a constraint data field of the entity configuration file. Further, the entity manager (183) is configured to validate the information received for creating the entity by using the relationship constraint key for each of the relationship constraints on the information received for creating the entity and create the entity based on the metadata corresponding to the relationship constraints and the information of the entity in response to successful validation of the information received for creating the entity.

[0047] The entity manager (183) performs the update operation as the entity manager (183) is configured to retrieve the relationship constraint key for each of the relationship constraints in the constraint data field of the entity configuration file of the entity to be updated and validate the information received for updating the entity by using the relationship constraint key for each of the relationship constraints on the information received for updating the entity. Further, the entity manager (183) is configured to update the entity based on the metadata corresponding to the relationship constraints and the information of the entity in response to successful validation of the information received for updating the entity.

[0048] The entity manager (183) performs the delete operation as the entity manager (183) is configured to retrieve the relationship constraint key for each of the relationship constraints in the constraint data field of the entity configuration file of the entity to be deleted and validate the information received for deleting the entity by using the relationship constraint key for each of the relationship constraints on the information received for deleting the entity. Further, the entity manager (183) is configured to delete the relationship constraint key for each of the relationship constraints in the constraint data field of the entity configuration file of the entity to be deleted and delete the relationship associated with the entity to be deleted.

[0049] In an embodiment, the constraint database (184) is configured to store actual configuration of each of the multiple relationship constraints. The actual configuration of the relationship constraints is not provided to the relationship constraint manager (182), whereas only the metadata corresponding to the relationship constraints are shared with the relationship constraint manager (182) from the constraint database (184) based on the entity configuration file.

[0050] In an embodiment, the graph database (185) includes the entities created by the user. In an embodiment, the constraint database (184) and the graph database (185) may be separate elements located within the relationship constraint management server (100). In another embodiment, the constraint database (184) and the graph database (185) may be a single element located within the relationship constraint management server (100) (indicated by dotted lines in the FIG. 1). The constraint database (184) and the graph database (185) may be located within the memory (120) or out of the memory (120) of the relationship constraint management server (100). For example but not limited to, the graph database (185) is a JanusGraph. The JanusGraph is a scalable graph database optimized for storing and querying graphs containing hundreds of billions of vertices and edges distributed across a multi-machine cluster.

[0051] Although the FIG. 2 shows various hardware components of the relationship constraint management server (100), but it is to be understood that other embodiments are not limited thereon. In other embodiments, the relationship constraint management server (100) may include less or a greater number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined to perform same or substantially similar function to manage the relationship constraints associated with the entities in the graph database (185).

[0052] FIG. 3 is a flow chart illustrating a method for managing the relationship constraints associated with the entities in the graph database (185), according to an embodiment as disclosed herein.

[0053] Referring to the FIG. 3, at step 202, the method includes the relationship constraint management server (100) receiving the request including the information of entity to be created in the graph database (185). For example, in the relationship constraint management server (100) as illustrated in the FIG. 2, the relationship management controller (180) is configured to receive the request including the information of entity to be created in the graph database (185).

[0054] At step 204, the method includes the relationship constraint management server (100) generating the entity configuration file based on the information of the entity to be created. For example, in the relationship constraint management server (100) as illustrated in the FIG. 2, the relationship management controller (180) is configured to generate the entity configuration file based on the information of the entity to be created. [0055] At step 206, the method includes the relationship constraint management server (100) retrieving the metadata corresponding to the relationship constraints from the constraint database based on the entity configuration file. For example, in the relationship constraint management server (100) as illustrated in the FIG. 2, the relationship management controller (180) is configured to retrieve the metadata corresponding to the relationship constraints from the constraint database based on the entity configuration file.

[0056] At step 208, the method includes the relationship constraint management server (100) generating the relationship constraint key for each of the relationship constraints based on the information of the entity. For example, in the relationship constraint management server (100) as illustrated in the FIG. 2, the relationship management controller (180) is configured to generate the relationship constraint key for each of the relationship constraints based on the information of the entity.

[0057] At step 210, the method includes the relationship constraint management server (100) adding the relationship constraint key for each of the relationship constraints in the constraint data field of the entity configuration file. For example, in the relationship constraint management server (100) as illustrated in the FIG. 2, the relationship management controller (180) is configured to add the relationship constraint key for each of the relationship constraints in the constraint data field of the entity configuration file.

[0058] At step 212, the method includes the relationship constraint management server (100) validating the information received for creating the entity by using the relationship constraint key for each of the relationship constraints on the information received for creating the entity. For example, in the relationship constraint management server (100) as illustrated in the FIG. 2, the relationship management controller (180) is configured to validate the information received for creating the entity by using the relationship constraint key for each of the relationship constraints on the information received for creating the entity.

[0059] At step 214, the method includes the relationship constraint management server (100) creating the entity based on the metadata corresponding to the relationship constraints and the information of the entity in response to successful validation of the information received for creating the entity. For example, in the relationship constraint management server (100) as illustrated in the FIG. 2, the relationship management controller (180) is configured to create the entity based on the metadata corresponding to the relationship constraints and the information of the entity in response to successful validation of the information received for creating the entity.

[0060] At step 216, the method includes the relationship constraint management server (100) storing the entity in the graph database (185). For example, in the relationship constraint management server (100) as illustrated in the FIG. 2, the relationship management controller (180) is configured to store the entity in the graph database (185).

[0061] The various actions, acts, blocks, steps, or the like in the flow diagram may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some of the actions, acts, blocks, steps, or the like may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

[0062] FIG. 4 illustrates various examples of restricted and unrestricted relationships between various entities in the graph database (185), according to an embodiment as disclosed herein.

[0063] In general, the graph database (185) does not store the information in the form of rows and columns, rather the graph database (185) stores the information in the form of nodes and vertices, where the nodes and the vertices indicate the entities. In the FIG. 4, circles indicate nodes/vertices and arrows indicate the relationship between any two nodes/vertices.

[0064] The multiplicity of the edge label defines a multiplicity constraint on all edges of the edge label, that is, a maximum number of edges between pairs of vertices. The general edge label multiplicity is provided below:

1. MULTI: Allows multiple edges of the same edge label between any pair of vertices i.e., the graph is a multi-graph with respect to the edge label. There is no constraint on the edge multiplicity.

2. SIMPLE: Allows at most one edge of the edge label between any pair of vertices i.e., the graph is a simple graph with respect to the edge label. Ensures that the edges are unique for a given edge label and pairs of vertices.

3. MANY2ONE: Allows at most one outgoing edge of the edge label on any vertex in the graph but places no constraint on incoming edges. For example, an edge label “mother” with MANY20NE multiplicity since each person has at most one mother but mothers can have multiple children.

4. ONE2MANY: Allows at most one incoming edge of the edge label on any vertex in the graph but places no constraint on the outgoing edges. For example, an edge label winnerOf with ONE2MANY multiplicity since each contest is won by at most one person but a person can win multiple contests.

5. ONE2ONE: Allows at most one incoming and one outgoing edge of the edge label on any vertex in the graph. The edge label marriedTo is an example with ONE2ONE multiplicity since a person is married to exactly one other person.

[0065] In the proposed method the relationship constraints are defined in terms of the type of the entities being connected and the type of relationship between the entities. The relationship constraint represents the restriction on the multiplicity of the relationships on each end-point. The types of relationships which are possible to be defined for the same edge label in the proposed method are provided in table. 1 and indicated in the

FIG. 4.

Table. 1

[0066] Further, the proposed method allows the use of the same edge label with different multiplicity in the graph by defining the source multiplicity and the destination multiplicity in the entity configuration file itself. For example, a YANG syntax of a YANG configuration is extended to include specification of multiplicity/relationship constraints for the entities as indicated in the highlighted portion below: container relationships { description "Relationship definitions"; leaf has_O { type Base:relatedType {

Base:relationship

Base:relType

Base: source

Base:version

Base:sourceMultiplicity

}

}

}

[0067] For example, consider a scenario where the entities include a college and multiple students will have to be connected to the college. Then, the specification is as provided below: container relationships { description "Relationship definitions"; leaf has_0 { type Base:relatedType {

Base:relationship "enrolledln";

Base:relType "College";

Base:source "Clg-source";

Base:version "1.0";

Base:sourceMultiplicity

Base:destMultiplicity "1";

}

}

} [0068] In case of the relationship constraints, the relationship constraints are included in the relationship definition, since the relationship constraints are self-contained and are easier to manage.

[0069] Valid values for the properties of entities are provided in table. 2:

[0070] If the value is not specified then the value of 0..* is assumed, indicating an optional, unrestricted relationship between the entities.

[0071] The specification of the relationship constraint is provided in the entity configuration file and stored in the constraint database (184). The properties used for defining the specification of the relationship constraint are provided in table. 3 :

Table. 3

[0072] Once the specification is defined in the entity configuration file (i.e., the YANG configuration) then the entity configuration file is uploaded by the relationship constraint management server (100) and create an application program interface (API) is called for creating constraint vertex as the metadata in the schema. Further, the configure API is called for configuring the properties in the schema using the configure API. Furthermore, an apply API is called by the relationship constraint management server (100) to apply the defined relationship constraint.

[0073] FIG. 5A illustrates a one-to-many relationship scenario between multiple entities where a uniqueness violation is observed, according to an embodiment as disclosed herein.

[0074] FIG. 5B illustrates a many-to-one relationship scenario between multiple entities where the uniqueness violation is observed, according to an embodiment as disclosed herein.

[0075] The relationship constraint key is mapped to uniqueness conditions. Therefore, in conjunction with the FIG. 4, the one-to-many relationship means that one instance of an object class can relate to any number of “other” instances outgoing (hence no restriction), but from the perspective of the other instance only one instance of a class can have an incoming relationship to the other instance. That is once a relationship of a certain type from a certain class has been created to a specific instance, not more can be added to that instance.

[0076] Symmetrically, in the many-to-one relationship, the outgoing relationships are to be restricted such that once the relationship has been created from the specific instance to the class, no more can be created from that instance. A tabular form of the above is provided in table. 4.

Table. 4 [0077] The meaning of uniqueness can be translated to a graph wide property uniqueness constraint by expressing as: for a relationship defined by a source class, a destination class, and the relationship type, there must be a unique instance assigned to each controlled endpoint i.e., the tuple (relationshipType, sourceClass, destinationclass, end, instance) must be unique.

[0078] The first three elements can be represented by the constraintspecification ID, so this can be reduced to: (constraintSpecId, end, instance). This means, for example that the following three constraints can be supported at the same time in the FIG. 5 A as described in table. 5:

Table. 5

[0079] To enable recording of each relationship constraint on a constraint vertex, a key is built for each relationship constraint. The relationship constraint key can be added either to the constraint vertex of the relevant endpoint vertex, or it can be added to the edge itself. Further, the existing relationship constraint key can be reused for better convenience. The name of the relationship constraint key is required to capture the end classes, the relationship name, and whether this is the in-end of the constraint, or out- end of the constraint (i.e., to disambiguate the ends of a 1-to-l constraint). Therefore, the constraint specification ID is used to capture the requirement of the relationship constraint key naming criteria automatically. However, this makes for potentially invalid relationship constraint key names, and also invalidates the constraints if the relationship constraint specification is recreated. A more maintainable and robust approach is to encode the parameters. For example: class A contains class B: 1-to-many becomes: cons A I B J in. The value of the relationship constraint key is the instance ID of the end that represents the “many” end of the relationship.

[0080] The uniqueness of the relationship constraint in the constraint vertex is determined by defining a property within the constraint vertex using a combination of a source node, a destination node, a source type, a destination type, etc. Referring to the FIG. 5A, consider the relationship constraint specification with the one-to-many relationship as follows: ConstraintDefld: 1234; Field: containsC2Base; multSource: 1; multDest: 1... *.

[0081] At step 1, Cl contains C2 which is represented with instance IDs as Cl : Instl contains C2: Inst2. At step 2, the constraint 2 associated with the C2: Inst2 has the property defined as contains_1234_in:_inst2.

[0082] At step 3, the Cl : Instl contains C2: Inst3 and at step 4, the constraint 3 associated with the C2: Inst3 has the property defined as contains_1234_in:_inst3. Further, at step 5, when the user tries to add the Cl : Inst4 contains C2: Inst3, then the relationship constraint management server (100) provides the error message to the user as the creation of the Cl : Inst4 will create a uniqueness violation for the value “inst3”.

[0083] Similarly, referring to the FIG. 5B, consider the relationship constraint specification with many-to-one relationship as follows: ConstraintDef Id: 1234; Field: containsC2Base; multSource: 1... * and multDest: 1.

[0084] At step 1, Cl : Instl contains C2: Inst3 and at step 2, the property defined as contains_1234_out:_instl. Similarly, at step 3, Cl : Inst2 contains C2: Inst3 with contains_1234_out:_inst2 property defined (step 4). However, at step 5 when the user tries to add Cl : Instl contains C2: Inst4, then the relationship constraint management server (100) provides the error message to the user as the creation of the Cl : Instl contains C2: Inst4 will create a uniqueness violation for the value “instl”. Therefore, the proposed method avoids the creation of the constraint vertex based on the uniqueness criteria violation with the relationship constraint.

[0085] In an example, consider that the entities include a first college vertex and multiple student vertices. Here, in the perspective of the first college vertex the relationship is many-to-one whereas in the perspective of each student vertex the relationship is one-to-one i.e., many students can be associated with a single college whereas a single student is associated with a single college only at any given point in time. Therefore, in the proposed method the relationship constraint is created by adding a constraint vertex for the student label where a property (with the relationship constraint key) is defined such that each student vertex is related to the first college vertex only. Further, if the user tries to relate any of the student vertex to a second college vertex then the relationship constraint management server (100) will provide an error message to the user and hence the relationship between the student vertex and the second college vertex will be invalid.

[0086] Furthermore, consider a scenario where the student is no longer related to the first college vertex and is currently related to the second college vertex. Then, the relationship constraint management server (100) deletes the property (with the relationship constraint key) which defines that each student vertex is related to the first college vertex only from the constraint vertex and adds a new property to the constraint vertex. The new property (with a new relationship constraint key) will define that each student vertex is related to the second college vertex only. Therefore, even when there is an update in the relationship of the entities the relationship constraint management server (100) ensures that there is no overlapping of the relationships.

[0087] In an embodiment, an optional relationship is the “zero or more” type of multiplicity as opposed to the “one or more” type. On determining by the relationship constraint management server (100) that one side of the relationship is not optional an additional check is made to confirm that for all mandatory relationship constraints in the relationship exists. The relationship constraint management server (100) manages the below mentioned two situations with respect to the optional relationship between the entities:

1. where the “1” case where a unique relationship constraint key has been defined

2. where the “1 or more” case, where a unique relationship constraint key has not been defined, since there is no uniqueness requirement. [0088] The relationship constraint management server (100) manages the one-to-one mandatory relationship by carrying out a relationship validation within the scope of a single API call. The validation of the mandatory one-to-one relationship is creation of both related objects together as a composite, since independently creating either object would result in a validation error. Further, the relationship constraint validation can leave the data in an inconsistent state, with an indicator of validity, and a method is available to re-validate. The relationship constraint management server (100) provides a warning return for the operation that created the validation error and assumes that the caller will make additional calls to correct the situation that the object is to be fully re-validated on each API request.

[0089] To process the above-mentioned relationship management, the relationship constraint management server (100) creates the unique relationship constraint keys on the constraint vertex where a uniqueness guarantee is required either at the local end or the adjacent end, or both. Further, the relationship constraint management server (100) on determining that there is the mandatory relationship check is made that the relationship has been added.

[0090] FIG. 6A illustrates step-by-step process for application of the relationship constraint at the constraint vertex, according to an embodiment as disclosed herein.

[0091] FIG. 6B illustrates step-by-step process for application of the relationship constraint at the edge, according to an embodiment as disclosed herein.

[0092] Referring to the FIG. 6A, at step 502a, the relationship constraint management server (100) receives a request to apply the YANG file. This includes loading the constraint specification from the YANG file and creating the schema inside the graph database (185). On execution of the apply option, the user is able to create the instances of the particular type from the YANG file. Further, the relationship constraint management server (100) allows for all provided relationships to inset the relationship constraint keys i.e., at step 504a the one-to-many or one-to-one relationships at other constraint vertex (300). The insert key option is executed as Insert key (constraintid, other-instanceld, constraintName). At step 506a, the many-to- one or one-to-one relationships at self-constraint vertex (200). The insert key option is executed as Insert key (constraintid, self-instanceld, constraintName).

[0093] The relationship constraint management server (100) for all defined mandatory relationships constraints confirms if the relationship constraint key which is inserted exists. At step 508a, the relationship constraint management server (100) for the one-to-many or one-to-one and RHS mandatory relationships confirms that the relationship constraint key exists for (constraintid, other-instanceld, constraintName) and at step 510a, for the many-to-one or one-to-one and LHS mandatory relationships confirms the relationship constraint key exists for (constraintid, self- instanceld, constraintName).

[0094] Therefore, in the proposed method the relationship constraint management server (100) checks for the relationship constraint key creation and thereafter, if on a second request, the same relationship constraint key data comes then the relationship constraint management server (100) rejects it because of the relationship constraints, and loop goes on.

[0095] Referring to the FIG. 6B, in conjunction with the FIG. 6A, in another embodiment, the constraint properties can be added to the edges directly instead of the other constraint vertex (300) or the self-constraint vertex (200). Though the addition of the constraint properties is addition of a new method on top of the existing vertex based approach, but the advantage of adding the constraint properties to the edges directly is that the method includes dealing with fewer objects for relationship constraints, especially when the property constraint vertices would otherwise not be required.

[0096] FIG. 7 illustrates step-by-step process for the creation of the relationship constraint key during the schema in the graph database (185), according to an embodiment as disclosed herein.

[0097] The relationship constraint management server (100) implements a standard interface which is invoked by the constraint framework. At step 602, the relationship constraint management server (100) sends a configure (scpec) command to a relationship constraint handler (800) to load the specification and apply the specification based on the metadata from the graph database (185). At step 604, the relationship constraint handler (800) creates relationship constraint key name. The creation of the constraint properties is performed at the same time as the uniqueness constraints. The property names are generated as: relc_<RELType>_<LHSClass>_<RHSClass>_<L HSMult>_<RHSMult>_ <IN_or_OUT> where: relc is a prefix to indicate relationship constraint,

RELType is the name of the relationship, e.g. contains,

LHSClass is the owner (relationship originating) class, with source, i.e. CNF RCPBase,

RHSClass is the destination class, with source, i.e. NS RCPBase,

LHSMult is left hand side multiplicity, from table above (1, +, *, ?), RHSMult is right hand side multiplicity, from table above (1, +, *, ?), and

IN or OUT indicates the direction of the constraint: 1-to-many set to in, many -to- 1 set to out.

[0098] Further, at step 606, the relationship constraint handler (800) sends mgmt. createPropertyKey (key) command to the graph database (185) to create the relationship constraint key and at step 608 the relationship constraint handler (800) sends mgmt.addProperties(edgeLabel, key) command to the graph database (185) to bind the created property to the edge that is being controlled along with the relationship constraint key . Similarly, at step 610 the relationship constraint handler (800) sends mgmt.buildCompositionIndex().unique(), at step 612 the relationship constraint handler (800) adds a relationship constraint key name to constraintspecification to the graph database (185). At step 614, the relationship constraint handler (800) sends a commit command to end the flow which creates the relationship constraint key during the schema in the graph database (185).

[0099] FIG. 8 illustrates step-by-step process for application of the relationship constraint in the graph database (185), according to an embodiment as disclosed herein. Referring to the FIG. 8, at step 702, the operation apply() is called in response to either object creation or update (full (PUT), or partial (PATCH)) by the relationship constraint management server (100). The names of the relationship constraint key are pre-calculated and saved during the configure process. The operation apply()retrieves the relationship constraint key name for the required situation and stores the instance ID of either the source, or destination object as the relationship constraint key value, on the edge for the relationship. Unlike property uniqueness constraints, a separate constraint vertex is not created. By keeping the constraints properties on the edge, these are automatically cleared when the edge is removed from the graph database (185).

[00100] Further, the relationship constraint management server (100) is configured to apply constraints to the relationship for each unique relationship in input. For all the XX-to-one -relationships are considered where at step 703, the relationship constraint management server (100) gets the relationship constraint key name from the constraintSpec, and at step 704 the relationship constraint key is set at the edge using (keyname, id-of- source-object). Similarly, for all the one-to-XX -relationship relationships are considered where at step 705, the relationship constraint management server (100) gets the relationship constraint key name from the constraintSpec, and at step 706 the relationship constraint key is set at the edge using (keyname, id-of-destinati on-object).

[00101] The relationship constraint management server (100) validates the mandatory endpoints for each mandatory relationship in input which includes relationship mandatory at source and the relationship unique at destination. The relationship constraint management server (100) then determines the success or failure of the validation.

[00102] FIG. 9 illustrates step-by-step process for deleting the relationship constraints and the generated relationship constraint keys associated with the relationship constraints, according to an embodiment as disclosed herein. Referring to the FIG. 9, the process of the deletion of the relationship constraint and henceforth the removal of the generated relationship constraint key is provided. The process is executed based on a user requirement i.e., in case the user wants to delete the relationship constraint then the proposed process is executed.

[00103] At step 801, the relationship constraint management server (100) sends a begin () command to the relationship constraint handler (800). On receiving the begin () command, at step 802, no action is required and first cons object retrieval will auto start transaction at the graph database (185). At step 803, the relationship constraint management server (100) runs through various relationship constraints and at step 804, the relationship constraint management server (100) sends an unapply (object) command to the relationship constraint handler (800). At step 805, the relationship constraint handler (800) sends a command to the graph database (185) to locate the edge where the generated relationship constraint key needs to be deleted.

[00104] At step 806, the relationship constraint handler (800) sends delete cons key edge command to itself to delete the relationship constraint key at the edge. In response, at step 807, the relationship constraint management server (100) runs through various relationship constraints in the graph database (185). Further, the relationship constraint management server (100) ensures that all constraints have been met by sending various commands between step 808 and step 811.

[00105] Therefore, the operation unapply() is used to clean up the relationship constraint keys from the relationship constraint management server (100). The relationship constraint keys are stored on the edge and hence the use of the operation unapply() is redundant if invoked before deleting the relationship. [00106] FIG. 10 illustrates step-by-step process for deleting the relationship constraints from all objects, according to an embodiment as disclosed herein.

[00107] The graph database (185) generally does not allow a property key to be deleted. Hence, an unconfigure() operation is used to delete all existing relationship constraint key values that the graph database (185) owns. Therefore, the entire relationship constraints are deleted. The entities or the objects, on which the relationship constraint keys are applied, are selected and the relationship constraint is deleted from all the entities or the objects.

[00108] Referring to the FIG. 10, at step 901, the relationship constraint management server (100) sends the unconfigure (scpec) to a uniqueness handler (900) to delete the specification related to the relationship constraints from all the objects. At step 902, the uniqueness handler (900) queries all the objects in the graph database (185) with the relationship constraint key. At step 903, the uniqueness handler (900) executes the unconfigure (scpec) operation based on all the specifications of the relationship constraint stored in the graph database (185) by the query in batches to avoid large transactions simultaneously. Further, at step 904, the uniqueness handler (900) sends a delete property value to the graph database (185) and at step 905, the uniqueness handler (900) sends a commit command to the graph database (185) which deletes all the existing properties key values that the graph database (185) owns.

[00109] Another operation which can be used by the relationship constraint management server (100) is reapply () operation. The reapply operation clears the existing relationship constraint key and invokes apply operation to create a new relationship constraint key.

[00110] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the embodiments as described herein.