Data Views
In a multi application, multi user environment different database clients may have different opinions on how their data should look like. By means of hierarchical structure and by means of attribute level content. Giving either of them it's own data silo is not the solution. Instead of holding the same data twice and thrice for each application today's enterprises increasingly ask for consolidated storage. Data views give either client application their private data model while physical data is stored only once and shared consistently. This removes enterprise wide overlapping data sets and the consistency problems associated with data reconciliation across different storage systems. As a result the redundant data is removed, common data is shared and private application data is only visible for the respective authorized application.
As DVTDS is an object oriented database, there are three levels of information, where data model transformations can be applied:
The product offers an outstanding collection of advanced data view techniques on each of these levels. All of them can be configured online via LDAP through the graphical user interface or automated by means of OAM systems while client traffic is ongoing. All transformations work bidirectional and ACID compliant. Please read on for details:
Key conversion. This changes the key supplied by the client request in an approriate way to reach the physical object location in the server. In DVTDS objects can be arranged to flat arrays or hierarchical, tree like layouts. For this reason key conversion can be used to transform the structural relations of objects from the client point of view. The actual conversion is steered by powerful rules that are able to cut nearly every part of the requested key out of the incoming stream and reassemble it to a new key.
Attribute name and value conversion. Think of application that knows the attribute color with the possible values red, green, blue. Another application might have the same concept of color under the (french) attribute name couleur with the possible values 1, 2, 3. The data is semantically identical, so why not share it between the applications? The only thing is to apply for one of the applications a conversion between the attribute name and values given in the request, expected in the response and stored physically in the database. DVTDS goes far beyond this simple example. By means of plugin modules it is able to convert any value format to any other.
Virtual objects. With this powerful feature entire hierarchies and object contents can be adapted to what the client expects. This works similar to the well known view tables in relational databases. Virtual objects are based on rule sets that decompose client requests. They calculate in which objects the target attributes are located and apply updates to the target attributes. For search requests the target attributes are pulled from their locations and displayed to the client. Target attributes may belong to completely different objects spread all over the database. The server takes care to bundle them into consistent objects from the client point of view.
Aggregation. This technique supports to combine several attributes and values or parts of them from arbitrary physical storage locations into new attribute and value representations as seen by the clients. It includes also the change of multiplicity from single value to multi value and vice versa.
Segregation. This mechanism is opposite to aggregation. It splits the value(s) of one or more attributes into arbitrary pieces and present them to the client as a set of other attributes, either of them carrying one or more values.
Client custom data views. Clients with appropriate access rights may adapt their logical data model dynamically using one or more of the above mechanisms. All of them can be configured online via the LDAP interface.
Our conversion engine follows an any to any paradigm: It is able to transform any data. No matter, what the actual storage format is and what a client instead expects, including even transformations on bit level. Moreover there is no downtime or data migration needed when a data view is changed or newly deployed. They can be activated or changed any time while the system is running, taking immediate effect. There is no limit in the number or complexity of such data views. And the performance is far beyond any doubt: The response times stay well below 150 micro seconds. Even for complex reads or writes comprising hundred or more attributes spread across a number of physical locations in the storage engine. Please look here for a presentation of DVTDS data view features.
DVTDS supports this approach explicitly by offering server side data view transformations. Each data view can be associated with one or more client applications. Either of these client applications may have it's own logical data model. The server passes the client requests through the data conversion layer and adapts them on the fly to the physical data structures. On the way out server responses can be converted using reverse or other transformations. The client is not aware of this mechanism. It simply updates or receives objects and attributes according to its logical data model. The transformations are executed within micro seconds inside the DVTDS storage engine. Compared to solutions that emulate these conversions in their access layer this guarantees that clients are not affected by longer response times when using data views instead of direct access.
- Object level. This allows for conversion of hierarchies like flat to structured, structured to flat or any to any tree like shapes. The mapping of access keys belongs also to this class of transformations.
- Attribute level. This mechanism adapts attribute names to whatever the client wants to see. Aggregation and segregation (mappings of attribute sets to other sets of different size) fall also into this category.
- Value level. This type of conversion changes value representations (syntaxes) and multiplicity. Similar to attribute level aggregation and segregation may be applied to sets of values.
The product offers an outstanding collection of advanced data view techniques on each of these levels. All of them can be configured online via LDAP through the graphical user interface or automated by means of OAM systems while client traffic is ongoing. All transformations work bidirectional and ACID compliant. Please read on for details:
Key conversion. This changes the key supplied by the client request in an approriate way to reach the physical object location in the server. In DVTDS objects can be arranged to flat arrays or hierarchical, tree like layouts. For this reason key conversion can be used to transform the structural relations of objects from the client point of view. The actual conversion is steered by powerful rules that are able to cut nearly every part of the requested key out of the incoming stream and reassemble it to a new key.
Attribute name and value conversion. Think of application that knows the attribute color with the possible values red, green, blue. Another application might have the same concept of color under the (french) attribute name couleur with the possible values 1, 2, 3. The data is semantically identical, so why not share it between the applications? The only thing is to apply for one of the applications a conversion between the attribute name and values given in the request, expected in the response and stored physically in the database. DVTDS goes far beyond this simple example. By means of plugin modules it is able to convert any value format to any other.
Virtual objects. With this powerful feature entire hierarchies and object contents can be adapted to what the client expects. This works similar to the well known view tables in relational databases. Virtual objects are based on rule sets that decompose client requests. They calculate in which objects the target attributes are located and apply updates to the target attributes. For search requests the target attributes are pulled from their locations and displayed to the client. Target attributes may belong to completely different objects spread all over the database. The server takes care to bundle them into consistent objects from the client point of view.
Aggregation. This technique supports to combine several attributes and values or parts of them from arbitrary physical storage locations into new attribute and value representations as seen by the clients. It includes also the change of multiplicity from single value to multi value and vice versa.
Segregation. This mechanism is opposite to aggregation. It splits the value(s) of one or more attributes into arbitrary pieces and present them to the client as a set of other attributes, either of them carrying one or more values.
Client custom data views. Clients with appropriate access rights may adapt their logical data model dynamically using one or more of the above mechanisms. All of them can be configured online via the LDAP interface.
Our conversion engine follows an any to any paradigm: It is able to transform any data. No matter, what the actual storage format is and what a client instead expects, including even transformations on bit level. Moreover there is no downtime or data migration needed when a data view is changed or newly deployed. They can be activated or changed any time while the system is running, taking immediate effect. There is no limit in the number or complexity of such data views. And the performance is far beyond any doubt: The response times stay well below 150 micro seconds. Even for complex reads or writes comprising hundred or more attributes spread across a number of physical locations in the storage engine. Please look here for a presentation of DVTDS data view features.