Schema matching identifies elements of two given schemas that correspond to each other. Although there are many algorithms for schema matching, little has been written about building a system that can be used in practice. We describe our initial experience building such a system, a customizable schema matcher called Protoplasm. Most systems-integration work requires creating mappings between models, such as database schemas, message formats, interface definitions, and user-interface forms. As a design activity, schema mapping is similar to database design in that it requires digging deeply into the semantics of schemas. This is usually quite time consuming, not only in level-of-effort but also in elapsedtime, because the process of teasing out semantics is slow. It can benefit from the development of improved tools, but it is unlikely such tools will provide a silver bullet that automates all of the work. For example, it is hard to imagine how the best tool could eliminate the need for a designer to read documentation, ask developers and endusers how they use the data, or review test runs to check for unexpected results. In a sense, the problem is AI-complete, that is, as hard as reproducing human intelligence. The best commercially-available model mapping tools we know of are basically graphical programming tools. That is, they allow one to specify a schema mapping as a directed graph where nodes are simple data transformations and edges are data flows. Such tools help specify: a mapping between two messages, a data warehouse loading script, or a database query. While such graphical programming is an improvement over typing code, no database design intelligence is being offered. Despite the limited expectations expressed in the previous paragraph, we should certainly be able to offer some intelligence ⎯ automated help, in addition to attractive graphics. There are two steps to automating the creation of mappings between schemas: schema matching and query discovery. Schema matching identifies elements that correspond to each other, but does not explain how they correspond. For example, it might say that FirstName and LastName in one schema are related to Name in the other, but not say that concatenating the former yields the latter. Query discovery picks up where schema matching leaves off. Given the correspondences, it obtains queries to translate instances of the source schema into instances of the target, e.g., using query analysis and data mining [5] . This paper focuses on schema matching. There are many algorithms to solve it [8] . They exploit name similarity, thesauri, schema structure, instances, value distribution of instances, past mappings, constraints, cluster analysis of a schema corpus, and similarity to standard schemas. All of these algorithms have merit. So what we need is a toolset that incorporates them in an integrated package. This is the subject of this paper. The published work on schema matching is mostly about algorithms, not systems. This algorithm work is helpful, offering new ways to produce mappings that previous algorithms were unable to find. However, all of the published algorithms are fragile: they often need manual tuning, such as setting thresholds, providing a thesaurus, or being trained on examples; even after tuning, it is easy to find schemas that the algorithms do not map correctly; and many of them do not scale to large schemas. COMA is the first work to address engineering issues of a schema matching system [1] . Its architecture offers multiple schema-level matchers and a fixed process to combine their results. Matchers exploit linguistic, datatype, and structural information, plus previous matches, to produce similarity matrices forming a cube. The cube is aggregated to a matrix. Then particular similarity values are selected as good match candidates, which are combined to a single value. This process is executed for whole schemas or for two schema elements, and is repeated after the user provides feedback. Experimentation showed that finding good combinations of matchers depends on characteristics of the schemas being matched, demonstrating that customizability of the combination process is crucial. Inspired by COMA's approach, we felt it was important to push further toward building an industrial-strength schema matcher, one that avoids fragility problems, is customizable for use in practical applications, and extends the range of matching solutions being offered. We believe fragility is inherent in the problem. To mitigate it, we need a system that can exploit the best SIGMOD
al, describe a design of an industrialstrength schema matcher called PROTOPLASM REF .
Industrial-strength schema matching
SGMD
Computer Science