| Arnon Rosenthal and David Reiner. Tools and transformations - rigorous and otherwise - for practical database design. Transactions on Database Systems, 19(2), June 1994. |
....made on current data models [4] and their suitability for the problem concerned. A relational structure has been chosen for the data model, since it allows for easy changes within the database as well as short access time. Moreover, the relational data model is easy to program and to administer [5]. The data model for surgery has been developed after analyzing previous models and the needs of the medical partner institutions, with a view to avoiding the shortcomings of older models such as slow access times, complex adaptation, and redundance [6] In order to meet the varying requirements ....
Rosenthal, A.; Reiner, D.: Tools and Transformations-Rigorous and Otherwise-for practical Database Design, ACM Transactions on Database Systems: Vol.19, No.2, 167-211, 1994.
....separate kinds of metadata information data type, relational and rule based that we feel are useful in assisting a machine learning algorithm to discover more meaningful models of the data. Some, but not all, of this information can be re engineered from existing database system catalogues [4]. Most state of the art machine learning programs have no ability to utilise knowledge of data in a principled fashion. The level of metadata information that is currently being exploited by these algorithms is principally related to data type whether attributes are discrete with unordered ....
Rosenthal, A., and Reiner, D. (1994) "Tools and transformations --- rigorous and otherwise --- for practical database design." ACM Transactions on Database Systems 19 (2), 167-211.
.... an attribute with an equivalent entity type, all are examples of basic operators through which one can carry out such engineering processes as building a conceptual schema [Batini 1992; Batini 1993] schema normalization [Rauh 1995] DBMS schema translation [Hainaut 1993b; Rosenthal 1988; Rosenthal 1994] schema integration [Batini 1992] schema equivalence [D Atri 1984; Jajodia 1983; Kobayashi 1986; Lien 1982] data conversion [Navathe 1980] schema optimization [Hainaut 1993b; Halpin 1995] and others 1. According to the standard taxonomy of process models, this activity can best be described ....
Rosenthal, A., Reiner, D. 1994. Tools and Transformations - Rigorous and Otherwise - for Practical Database Design, ACM TODS, Vol. 19, No. 2
....so far can be used to underpin the schema integration process. We are interested in giving a formal foundation for the transformations that any methodology may perform, and we do not propose a particular methodology, of 322 Peter McBrien and Alexandra Poulovassilis which many already exist [5, 12, 16, 21, 18]. For any particular methodology, a set of composite transformation rules will be defined using the primitive transformations described in the previous section. The types of transformations that should be applied depends on the kind of equivalence (transformational, mapping or behavioural) that is ....
.... removal k b s d Schema Optional attribute removal k b s d restructuring Generalisation of attributes k b s d (Figure 3) Relationship removal (1) k b s d Relationship removal (2) k b s d Table 3: A New Classification of Common Schema Transformations u equivalence for relational models, [14, 15, 18] u equivalence for ER models, and [8] u equivalence for a more general model based on partially ordered sets. None of this work provides a mechanism for defining c equivalence, since it is always necessary in these approaches for the schemas to be equivalent for all possible instances. In effect, ....
A. Rosenthal and D. Reiner. Tools and transformations --- rigorous and otherwise --- for practical database design. ACM Transactions on Database Systems, 19(2):167--211 (1994).
....features are used to interrelate disparate data and resolve potentially different meanings [8, 11] Seen from a higher level, what is needed are mediation services [22] among different representations and systems. Schema Integration: Database design tools have been applied to schema integration [17], and related work formalizes interdatabase dependencies [18] and schema merging [1, 6] Related approaches utilize data migration [16] Some of the work in this area assumes that the resulting target schema or view is to be relational rather than another heterogeneous representation. Object ....
Rosenthal, Arnon, & D.Reiner, Tools and Transformations -- Rigorous and Otherwise -- for Practical Database Design, ACM Trans. on Database Systems, 19(2), June 1994.
....necessary to model a large class of commonly occurring schemas. Furthermore, we require that any reasoning about schema equivalence be done in a form that is easily conveyed back to a schema designer. To aid in this goal, we strive to meet requirements laid out by practitioners in this field [17]. Specifically, the constraints we include in the model are local (that is, they are robust to schemas changes) comprehensible (easily understood and used by a database designer) and not based on unrealistic assumptions about the set of valid instances of a schema. They also appear in some form ....
....sequence of ff transformations or ffi transformations. Corollary 5.5 If S1 ffffi Gamma S2 then S1 int S2. ffl Several researchers have made use of information or equivalence preserving transformations that move or copy attributes between entities or classes within other data models [7, 17]. These transformations are special cases of ffi transformations. However, no complete characterization of dominance under these transformations has been given. Hence, it was not previously possible to determine if an arbitrary schema could be transformed into another via these transformations. ....
[Article contains additional citation context not shown here]
A. Rosenthal and D. Reiner. Tools and Transformations - Rigorous and Otherwise - For Practical Database Design. Technical report, MITRE Corp., Feb. 1993.
....been discussed, especially in the context of other data models. The restriction to a single relationship for the determination of a key for an entity type, similar to the weak entity concept of the Entity Relationship Model ( Che76] can be found in several approaches, e.g. GMP88] KZ95] or [RR94] In [Zan79] for each record type of a network schema a set of synonyms (keys) is derived by inspecting different paths. Missing links are also considered: if an optional set type participates in a path, the result is a pseudo synonym. For the transformation to the relational model pseudo ....
....of entities in an extended ER model is sketched also. Entity identification is reduced to identification in nested relations where different types of equality are considered. Axiomatization or inference rules are not given. In the data model proposed for database design by Rosenthal and Reiner ( RR94] primary keys are allowed to include null attributes as long as unique identification of entities is guaranteed. No further remarks on the type of identification implied by this approach are given. A key set K as introduced in [Tha89] allows the specification of keys with null attributes. ....
A. Rosenthal and D. Reiner. Tools and transformations-rigorous and otherwise-for practical database design. ACM Transactions on Database Systems, 19(2):167-- 211, 1994.
....study was done by Hull [11] where he introduced the notion of relative information capacity for comparing the information content of relational schemas. It has been used as the formal basis of schema containment and schema equivalence for object models [1, 12] and for entity relationship models [15, 17]. In [21] Hull s notion is extended to take into account update semantics. However, the constraint and operator components of schemas are largely ignored in these studies, even though Hull observed that the structure component alone of a relational schema does not contain much information at all ....
....[11] In fact, it is very difficult to generalize the notion of relative information capacity to deal with constraints and operators. For example, it is shown in [15] that the information capacity of a schema can be increased by reducing its capacity of storing constraints; and it is claimed in [17] that the information capacity of a schema remains the same even if we add new operators (surrogate key attributes) Traditionally, schemas have been formalized using a structural approach, which describes the structure component of a schema using a (fixed) set of type constructors. However, the ....
[Article contains additional citation context not shown here]
A. Rosenthal and D. Reiner. Tools and transformations---rigorous and otherwise---for practical database design. ACM Transactions on Database Systems, 19(2):167--211, June 1994.
....was done by Hull [11] where he introduced the notion of relative information capacity for comparing the information content of relational schemas. It has been widely used as the formal basis of schema containment and schema equivalence for object models [1, 12] and for entity relationship models [15, 17]. In [21] Hull s notion is extended to take into account update semantics. However, the constraint and operator components of schemas are largely ignored in these studies, even though Hull observed that the structure component alone of a relational schema does not contain much information at all ....
....not hard to verify that schema5 j schema6. Compared to schema6, schema5 has more redundancy because the third column of R 2 is redundantly stored as the third column of R 1 . Hence replacing schema5 by schema6 removes this redundancy. This schema transformation has been proposed in the literature [8, 17]. 6.2 Schema Integration Let Gamma i = Sigma i ; Phi i ) for 1 i n be n schemas such that Sigma i and Sigma j are unioncompatible for 1 i; j n. When we integrate these schemas into one, the first step is to identify the semantic relationships between them. Suppose that the semantic ....
A. Rosenthal and D. Reiner. Tools and transformations---rigorous and otherwise--- for practical database design. ACM Transactions on Database Systems, 19(2):167-- 211, June 1994.
....expect any standard to anticipate every real world object we want to share. Rather, transformation services should support an evolving schema and should provide a mechanism for extending the underlying model. Transformation between data models, or schemas, is an important research area. Rosenthal [10] describes an approach that uses a unified underlying data model comprised of the union of all features, noting that the complexity of a unified model is increased by any extensions made to it. Bright [11] uses a global data structure, generated from an online system taxonomy, that contains ....
Rosenthal, Arnon, and David Reiner, "Tools and Transformations--Rigorous and Otherwise--for Practical Database Design," ACM Transactions of Database Systems, Vol. 19, No. 2, June 1994, pp. 167-211.
....necessary to model a large class of commonly occurring schemas. Furthermore, we require that any reasoning about schema equivalence be done in a form that is easily conveyed back to a schema designer. To aid in this goal, we strive to meet requirements laid out by practitioners in this field [RR93]. Specifically, the constraints we include in the model are local (that is, they are robust to schema changes) comprehensible (easily understood and used by a database designer) and not based on unrealistic assumptions about the set of valid instances of a schema. They also appear in some form ....
....in which the results are couched is accessible to schema designers. We therefore require that any reasoning about schema equivalence be done in a form that is easily conveyed back to a schema designer. To aid in this goal, we strive to meet requirements laid out by practitioners in this field [RR93]. Specifically, the constraints we include in the model are local (that is, they are robust to schema changes) comprehensible (easily understood and used by a database designer) and not based on unrealistic assumptions about the set of valid instances of a schema. These practical requirements ....
A. Rosenthal and D. Reiner. Tools and Transformations - Rigorous and Otherwise - For Practical Database Design. Technical report, MITRE Corp., February 1993.
No context found.
Arnon Rosenthal and David Reiner. Tools and transformations - rigorous and otherwise - for practical database design. Transactions on Database Systems, 19(2), June 1994.
No context found.
Arnon Rosenthal and David Reiner. Tools and transformations - rigorous and otherwise - for practical database design. Transactions on Database Systems, 19(2), June 1994.
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC