Making Designer Schemas with Colors

Abstract

MotivationAs XML has evolved from a document markup language to a widely-used format for exchange of structured and semistructured data, managing large amounts of XML data has become increasingly important. Since schema gives meaning to data, and determines the validity of queries and updates against the data, recently XML schema design issues have been investigated [2,3,15]. Fundamentally, XML schema design has two opposing goals: elimination of update anomalies requires that the schema be as normalized as possible; yet simpler query specification and higher query performance may both usually be obtained through the use of schemas that permit redundancy. 1 Ideally, schema design should be completely divorced from physical implementation and hence should be separated from performance concerns. Realistically, physical implementation mimics the given schema, but seeks higher performance only through adding indices, materialized views, and other such auxiliary structures. So the choice of schema has a huge impact on performance. benchmark in Figure 1, where attributes are suppressed but can be readily imagined. There is a straightforward way of transforming such an ER diagram to an XML schema (see Figure 2), where entity types from the ER diagram (see Figure 1) are made children of the schema root, relationship types are made children of one of their participating entity types, and all remaining associations are captured through id/idrefs attribute values (indicated in the figure using directed edges). In such a normalized XML schema, update anomalies are avoided at the expense of poor query performance. Queries like "Q1: list the orders placed by customers having addresses in Japan" require an XQuery expression involving multiple (id/idrefs) value-based joins, and can be expensive to evaluate. One might argue that this schema design is needlessly shallow, as it fails to leverage the nested (tree) structure permitted by XML. Does the tradeoff between opposing design goals still exist when we exploit XML's nesting?To appreciate this issue, consider, the XML schema of Figure 3. In an XML database that conforms to this schema, an order element would be nested under the customer element who made the order, which would be nested under the customer's address element, which would be nested under the corresponding country element. Given the ¢ :£ relationships inherent between relevant entity types in the

Improving query performance on XML documents

“…However, generalization types are not considered in this conversion approach. These conceptual constructs are not considered in [19] either. A methodology to maximize the connectivity between entities related by relationships in an ER schema is proposed by [19].…”

“…The approaches presented by [12] and [19] are focused, essentially, on generating optimized XML structures from a conceptual model. Compact and redundancy-free XML documents are obtained from analysis of the constraints of a schema defined by a generic conceptual model in [12].…”

“…XML documents have been directly stored in databases in their native format [9,15]. Besides, XML documents have been more and more used as containers to store data that will be retrieved or updated by applications [12,19]. Therefore, there is an increasing need for effective design methodologies to produce XML documents with an optimized structure to respond well to retrieval and updating operations of the applications.…”

“…Reference relationships are represented by IDREF or keyref definitions in the XML schema definition languages. Even though reference relationships are necessary in many cases, they generate a disconnected schema that often leads to a poor query performance [14,19,20]. In this paper, we present a conversion method which minimizes the impact of reference relationships in the performance of the application queries.…”

“…XML document design has been considered in a three-level modeling approach [6,12,14,19]. In the first level, a conceptual schema is generated for representing the application domain in a high-level abstraction.…”