Information Technology Reference
In-Depth Information
2 Related Work
Mapping composition and schema changes are fundamental operations in modeling
consistent data quality for the traditional database systems. In this work we reference
the semantics for mapping composition that was introduced by Fagin et. al [3].
Schema Mappings, and declarative constraints that model relationships between
schemas, are the main enabler of data integration and data exchange. They are used to
translate queries over target schema into queries over source schema or to generate
executable transformations that produce a target instance from a source instance.
These transformations are generated from the logical specification of the mappings.
Such schema mappings are normally generated semi-automatically from using well
established mapping tools like Clio, BEA Aqualogic [4][5]. The complexity of large
schemas, lack schema documentation, and the iterative, semi-automatic process of
mapping and transformation generation are common sources of errors. These issues
are compounded by the nuisances of mapping tools (which can produce supposedly a
wide variety of transformations is far from trivial and often time consuming and
expensive). In addition, schema mapping is often done over several data sources that
are themselves dirty or inconsistent. We contend that errors caused by faulty data
cannot be easily separated from errors caused by an incorrect or inconsistent mapping
and/or transformation. In the context of a synchronized VM environment, such
inconsistencies are multiplied ten fold.
3 Transformation Mapping Constraints
If this section we identify the types of mapping constraints and how we apply
enforcements to over come these constraints for enabling data quality within the
synchronized virtual machine environment. We articulate these constraints as a set of
formal mathematical definitions.
Definition 1: Rules R R j
∈ℜ
are mutually inconsistent if
v (R i. A k ) = v (R j. A k )
2) v (R i. C) ≠ v(R j. C)
A k
Α
1) 
Informally condition 1 in the above definition states that all decision making VM
attribute values of R i are the same as the corresponding attribute values of rule R j
and condition 2 states the category attribute value of rule R j . Note that one
assumes that decision making attributes will be in the same order for all rules, a
condition that can easily be satisfied.
One has indirect inconsistency if the two rules are present in different policy sets lead
to contradictory conclusions.Such inconsistencies are difficult to see because they may
not be visible at the time of defining policies and can only be triggered only when
some specific event occur. For example on the VM server a Professor T is allowed to
create a student exam account and Mary a student is allowed to delete accounts. A
policy may state that create and delete operation cannot be performed by the same entity
or identity. Inconsistency could occur if Professor T delegates his rights to Mary.
However from the perspective of having a synchronized VM log audit policy that can
perform data mining on the attribute identities , one could formally define inconsistency
in the following manner.
Search WWH ::




Custom Search