| S. Spaccapietra and C. Parent. View Integration : A Step Forward in Solving Structural Conflicts. TKDE, 6(2):258--274, 1994. |
....or some other way These cases of differing representations between input models are called conflicts. For the most part, conflict resolution is independent of the representation of A and B. Yet most work on merging schemas is data modelspecific, revisiting the same problems for ER variations [19], XML [3] data warehouses [7] semi structured data [4] and relational and object oriented databases [6] Note that these works, like ours, consider merging only the models, not the instances of the models. Some models, such as ontologies and ER diagrams, have no instance data. First Name ....
....also specify property values. For example, in Figure 2 MapAB specifies that one of the elements contained by AllBios is named Official and the other is named Unofficial. Solving representation conflicts has been a focus of the ontology merging literature [14, 15] and of database schema merging [2, 19]. 3.2 Meta model Conflicts A meta model conflict occurs when the merge result violates a meta model specific (e.g. SQL DDL) constraint. For example, suppose that in Figure 2 Actor is a SQL table in model A, an XML database in model B, and a SQL table in the merged model. If the mapping in ....
[Article contains additional citation context not shown here]
Spaccapietra, S. and Parent, C. View Integration: A Step Forward in Solving Structural Conflicts. TKDE, 6(2).
....and transformation. Obviously in information systems, it is in general easier to integrate or align the conceptual models of the systems than to integrate the logical or the physical internal representation of the system, as demonstrated by the literature on view and schema integration (e.g. [SP94]) Therefore, ORM ML as a standardized syntax for ORM models may assist interoperation tools to exchange, parse understand the ORM schemes. 3. Defining ORM Markup Language This section describes the main elements of the ORM ML grammar and demonstrates it using a few selected short examples. The ....
S. Spaccapietra, C. Parent, "View Integration: A Step Forward in Solving Structural Conflicts", IEEE Transactions on Data and Knowledge Engineering 6(2), IEEE, 1994.
....and transformation. In information systems, it is in general easier to integrate or align the conceptual models of the systems than to materially integrate the logical or the physical internal representation of the system, as demonstrated by the literature on view and schema integration (e.g. [SP94]) Therefore, ORM ML as a standardized syntax for ORM models may assist interoperation tools to exchange, parse or understand the ORM schemas. Interoperability for exchanging and sharing conceptual models over the Internet. Facilities are needed to share and exchange ORM conceptual models ....
S. Spaccapietra, C. Parent, "View Integration: A Step Forward in Solving Structural Conflicts", IEEE Transactions on Data and Knowledge Engineering 6(2), IEEE, 1994.
....cases of differing representations between input models are called conflicts. For the most part, conflict resolution is independent of how A and B are represented. Yet most work on merging schemas concentrates on doing it in a data model specific way, revisiting the same problems for ER variations [30], XML [4] data warehouses [11] semistructured data [5] or relational and object oriented databases [10] Note that these works, like ours, consider merging only the models, not the instances of the models. Some models, such as ontologies and ER diagrams, have no instance data, and merging the ....
....the merged model contains all of the objects in the two original models, 2) reconcile representation conflicts in the views (e.g. if a table in one view is matched with a column in another) and (3) require user input to guide the merge. Spaccapietra and Parent have a well known algorithm [30] that consists of a set of rules and a prescribed order to apply them in. Their meta meta model, ERC , has three different object types: attributes, entities, and relations. An entity is an object that is of interest on its own. An attribute describes data that is only of interest while the object ....
Spaccapietra, S. and Parent, C. View Integration: A Step Forward in Solving Structural Conflicts. TKDE, 6(2).
....that can be studied as challenges for the model management operators. This literature is too large to cite here, but we can highlight a few areas where there is obvious synergy worth exploring. Some of them were mentioned earlier: schema matching (see the survey in [23] schema integration [1,8,15,25], which is both an example and a source of algorithms for Match and Merge; and adding semantics to mappings [7,17,21,27] Others include: Data translation [24] Differencing [11,19,26] and . EER style representations and their expressive power, which may help select the best representation ....
Spaccapietra, Stefano and Christine Parent. View integration: A step forward in solving structural conflicts. TKDE 6(2): 258-274 (April 1994).
....all new buildings (S1.Buildings not specialized to old buildings) are included in the second database as habitable buildings. S1.Building: S1.Old Building: S2.Building: S2.Habitable Building: 1 2 3 4 5 Figure 2: Extensional Overlapping of Input Classes Most existing integration approaches [13, 12, 21, 3, 7, 22, 15, 8, 14] do only mark pairs of classes with a possibly non empty population intersection as candidates for integration. Additionally, attributes may be marked to be corresponding. The resulting integration assertions can be listed in the notation proposed by [22] S1fflBuilding S2fflBuilding ....
....approaches [13, 12, 21, 3, 7, 22, 15, 8, 14] do only mark pairs of classes with a possibly non empty population intersection as candidates for integration. Additionally, attributes may be marked to be corresponding. The resulting integration assertions can be listed in the notation proposed by [22]: S1fflBuilding S2fflBuilding Attribute correspondence: S1fflBuildingfflAddress j S2fflBuildingfflAddress S1fflBuilding S2fflHabitable Building Attribute correspondence: S1fflBuildingffl#flats j S2fflHabitable Buildingffl#flats S1fflOld Building S2fflBuilding Attribute ....
S. Spaccapietra and P. Parent. View Integration: A Step Forward in Solving Structural Conflicts. IEEE Transactions on Knowledge and Data Engineering, 6(2):258--274, April 1994.
....any instance of a general engineering activity. For instance, several database design methodologies have been proposed so far, ranging from standard ERA based approches to the more recent OO approaches. Less common activities such as database reverse engineering [HAI,93a] or schema integration [SPACCA,92] have been formally described through specific methodologies as well. Describing methodologies relates to (software design) process modelling, a discipline that is concerned with the understanding, representation and computer based support of the software engineering activities [POTTS,88] ....
Spaccapietra, S., Parent, C., View Integration : A Step Forward in Solving Structural Conflicts, IEEE Trans. on Knowledge and Data Engineering, October, 1992
.... to formalize nature of the subject and leads to an abundance of ad hoc solutions and methodologies (see also [9] A lot of approaches to classifying and managing structural conflicts were proposed ( 3, 1, 8, 12] and others) the most fundamental to date research is that one by Spaccapietra et al. ([14, 13]) where a taxonomy distinguishing semantic, descriptional, structural and heterogeneity conflicts was suggested. However, the taxonomy appears to be an informal description rather than a precise specification capable to support automated integration. In general, while the phenomenon of semantic ....
S. Spaccapietra, C. Parent, and Y. Dupont. View integration: a step forward in solving structural conflicts. IEEE Transactions on KDE, 1992. This article was processed using the L a T E X macro package with LLNCS style
....structures and other tricks. The second strategy implies conceptualizing a larger number of (often similar, if not identical) views, and dropping useful hints from the physical structures. However, view integration is easier, since it corresponds to processes that are now standard 8 [B1] B3] [S1]. 7. DATA STRUCTURE CONCEPTUALIZATION The objective of this process is to discard technical constructs from the DMS compliant schema, to reduce DBMS dependent constructs, to eliminate performanceoriented data redundancies, to make hidden conceptual data structures explicit, and to produce a ....
Spaccapietra, S., Parent, C., View Integration : A Step Forward in Solving Structural Conflicts, Res. Report , EPFL, Lausanne (CH), IEEE Trans. on Knowledge and Data Engineering, October, 1992
....federated database systems (FDBS) integration is a function regularly performed at different levels and by different services depending on the organization of the FDBS environment. The value of the problem is well known, various approaches, techniques and sometimes tools were proposed (see, eg, [7, 22, 35, 36, 30, 29, 26] and surveys [2, 27] In spite of the diversity of approaches, several common points can be well identified. Integration consists of schema integration composing a global schema from the set of local ones, and data integration computing virtual extension of the global schema. Schema ....
....same data can be structured in different ways, and resolving such structural conflicts between representations is the key for correct integration. In fact, a methodology of integration is mainly determined by the treatment and the taxonomy of conflicts it adopts. Several approaches were proposed ([7, 19, 28, 30] and others) the most fundamental to date research is [29] where a taxonomy distinguishing semantic, descriptional, structural and heterogeneity conflicts was developed. It appears however that this is rather a substantial description of various situations leading to conflicts (and, indeed, it ....
S. Spaccapietra, C. Parent, and Y. Dupont. View integration: a step forward in solving structural conflicts. IEEE Transactions on KDE, 1992.
....Schema integration is a main component of conceptual design which is itself a part of the overall activity of database design. This explains the significant interest in schema integration methodologies: a vast diversity of various approaches, techniques and sometimes tools were proposed (see, eg, [10, 30, 42, 43, 40, 39, 36] and surveys [4, 37, 33] Moreover, to date the value of the issue has increased greatly due to the evident tendency of organizing modern (and of the nearest future) information systems on cooperative federal principals. Indeed, in the context of federated database systems (FDBS) integration is ....
....local schemas but not captured by any of them. All this constitutes a heuristic and hard to formalize nature of the subject and leads to an abundance of ad hoc solutions and methodologies (see also [31] A lot of approaches to classifying and managing structural conflicts were proposed ([10, 4, 25, 38, 40] and others) the most fundamental to date research is [39] where a taxonomy distinguishing semantic, descriptional, structural and heterogeneity conflicts was suggested. It appears however that this is rather an informal descrip 2 This phenomenon is often called semantic relativism. Moreover, a ....
S. Spaccapietra, C. Parent, and Y. Dupont. View integration: a step forward in solving structural conflicts. IEEE Transactions on KDE, 1992.
....outside the scope of the proposed techniques, and even structural conflicts within a sufficiently rich (in its collection of modeling constructs) data model is still a challenge. In particular, it appears that the taxonomy of conflicts between views proposed by Spaccapietra et al. (see, eg, SP91, SPD92b, SPD92a] where semantic, descriptional, structural and heterogeneity conflicts are distinguished, encompasses adequately the intuition and the diversity of approaches but says little about formal specification of conflicts. In contrast, in the paper we propose a formal graphical language for ....
....diagram markers from the local sketches. However, here diagram conflicts can arise, and these are real conflicts between views which can bring to light inconsistency of views 9 Thus, in respect to the taxonomy of conflicts and correspondence assertions proposed by Spaccapietra et al. [SP91, SPD92b, SPD92a] it can be said that owing to introducing additional interschema sketches into integration, AGO reduces all that conflicts to conflicts of two kinds structural conflicts (of being basic derived) and constraint conflicts (between diagram markers) while all kinds of correspondence ....
S. Spaccapietra, C. Parent, and Y. Dupont. View integration: a step forward in solving structural conflicts. IEEE Transactions on KDE, 1992.
.... heterogeneous attributes [9] Recent work on integrating object oriented schemas has analyzed the formal properties of integrated schemas with respect to information preservation [39] and extended the transformational expressiveness of rules to cope with more kinds of modeling differences [53, 52, 31, 9]. 2.2. Linguistic Analysis There exists a long research tradition in computer linguistics for the problem of extracting the meaning from free texts. Typical linguistic approaches rely on a syntactical and semantical analysis of the given text source. In the context of information extraction, the ....
Stefano Spaccapietra and Christine Parent. View integration: A step forward in solving structural conflicts. TKDE, 6(2):258--274 (1994).
....details provided in [LMR90, SL90] The work in database schema integration also addresses these issues and has a longstanding research history. Much of this work was surveyed in 1986 [BLN86] but continuing research has also led to many later results, for example, the results in [LNE89, BCW90, SP94] As the Web has become more prominent, a host of recent data extraction work has appeared, for example [AK97a, AK97b, Bri98, DEW97, EJN99, ECJ 99, HGMC 97, KWD97, MMK98, SL97, Sod97] and has been highlighted in many recent workshops, for example [CM99] Attacking the problem head on, ....
....we present. For (2) The semantic transformations we present focus on values, including value coercion, value decomposition and aggregation, object identifiers (OIDs) and generalizations and specializations of value sets. We also provide more traditional transformations similar to those found in [SP94] but in terms of OSM, which has a two component view of the world in terms of objects and relationships rather than the more popular three component view in terms of entities, relationships, and 3 attributes. Finally, for (3) the formalisms we present are complementary to the formalisms ....
[Article contains additional citation context not shown here]
S. Spaccapietra and C. Parent. View integration: A step forward in solving structural conflicts. IEEE Transactions on Knowledge and Data Engineering, 6(2):258--274, April 1994.
....phase: ffl An n ary relationship r between n entities e 1 ; e n can be transformed into a new entity r with n binary relationships between r and e 1 ; e n . ffl A complex attribute a of an entity e which is an aggregation of n attributes s 1 ; s n , e.g. as used by [20], can be transformed into an entity a with n attributes s 1 ; s n and a relationship r between e and a. The domain of a is the Cartesian product of the domains of s 1 ; s n and this knowledge can subsequently be used in applying k b transformations. ffl A generalisation hierarchy ....
S. Spaccapietra and C. Parent. View integration: A step forward in solving structural conflicts. Technical report, Ecole Polytechnique Federale de Lausanne (1990).
....this architecture it is necessary to adopt a methodology that disciplines activities that accommodate the local schemas into a global one, and maps distributed and heterogeneous resources into global applications. The adoption of a conventional database integration methodology [3] 6] 17] [18] does not lead to a solution for GIS integration. They do not consider the graphic aspects for the representation of schemas nor the diversity and richness of semantic representation of the geographic data stored by the GIS. This work presents the MMultiGIS methodology to be incorporated into the ....
SPACCAPIETRA, S. & PARENT, C., 1994, "View integration: a step forward in solving structural conflicts", IEEE Transactions on Knowledge and Data Engineering, v.6, n. 2 (Apr.), pp. 240-274
....which consists of object databases, a global object schema created by integrating schemas of the component databases provides a uniform interface and high level location transparency for the users to retrieve data. A variety of approaches to schema integration have been proposed [1] 9] 15] [17]. In our previous work, we had presented a schema integration mechanism to achieve a global object schema for existing multiple object databases [13] Moreover, a form of equation was defined to denote the mapping between the global and component schemas in [14] One mechanism for processing the ....
S. Spaccapietra and C. Parent, View Integration: A Step Forward in Solving Structural Conflicts, IEEE Trans. on Knowledge and Data Eng., 6(2) (1994) pp.258-274. parameters description default setting for each global query Ndb number of component databases involved 3 N c number of global classes involved 1 4
....to an entity type from another schema, a relationship type compared to a relationship type, an attribute compared to an attribute. No mixed comparison (an attribute with an entity type, for instance) is supported. The consequence is poor interoperability and error prone techniques, as shown in [11]. With current methodologies, there is nothing which can be asserted between S5 and S6. An integration process instructed to merge S5 with S6 would produce a schema showing both entity types, just as they are. To avoid such an incorrect result, the DBA has to modify the input schemas before ....
S. Spaccapietra, C. Parent, Y. Dupont: "View integration: a step forward in solving structural conflicts", to appear in IEEE Transactions on Knowledge and Data Engineering , October 1992
No context found.
S. Spaccapietra and C. Parent. View Integration : A Step Forward in Solving Structural Conflicts. TKDE, 6(2):258--274, 1994.
No context found.
S. Spaccapietra and C. Parent. View Integration : A Step Forward in Solving Structural Conflicts. TKDE, 6(2):258--274, 1994.
No context found.
S. Spaccapietra and C. Parent, View integration: A step forward in solving structural con icts, IEEE Transactions on Knowledge and Data Engineering, 6(2):258-274, 1994.
No context found.
S. Spaccapietra and C. Parent. View integration: A step forward in solving structural conflicts. IEEE Transactions on Software and Data Engineering, 6(2):258--274, 1994.
No context found.
S. Spaccapietra and C. Parent. View Integration : A Step Forward in Solving Structural Conflicts. TKDE, 6(2):258--274, 1994.
No context found.
S. Spaccapietra and C. Parent. View Integration : A Step Forward in Solving Structural Conflicts. TKDE, 6(2):258--274, 1994. 29
No context found.
Spaccapietra, S., Parent, C., View Integration : A Step Forward in Solving Structural Conflicts, Res. Report , EPFL, Lausanne (CH), August
First 50 documents Next 50
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