colorful xml: one hierarchy isn't enough

1

Colorful XML: One Hierarchy Isn't Enough

Authors : H. V. Jagadish, Laks V. S. Lakshmanan, Monica Scannapieco, Divesh Srivastava, Nuwee Wiwatwattana

Presented by : Kohavi Ofer

2

ומתויגים סדורים עצים באופן פורמאלי, מסמךXML יתאר את המבנה הקומבינטורי

בעל הרכיבים הבאים:( קבוצת צמתיםnodes )N וקבוצת קשתות E אשר ביחד ,

מהווים עץ מכוון )בעל שורש(. סדר טוב "<" על הצמתים, אשר שומר על כיווני העץ אם

.x>y אז x הוא בן של yצומת בייצוג גרפי של העץ ניתן לייצג סדר זה ע"י כך שנכתוב

צמתים אחים לפי סדרם, משמאל לימין.( פונקצית תיוגtagging/labeling חלקית מקבוצת הצמתים )N

קבוצת כל התגים אל "אלפבית" סופי כל שהוא )למשל (.HTMLהחוקיים במסמך

פונקצית ערך חלקית מקבוצת הצמתיםN "אל "אלפבית ערכים אלו יהיו מחרוזות וקטעי טקסט.XMLאין-סופי. במסמך

במאמר תוצג בעיה שפתרונה יכלול XMLשינוי במבנה הלוגי של

3

Shallow, Deep Schemas

Let (D,F) be a schema, where D is DTD and F is a set of functional dependencies.

Let S be a finite subset of Paths from F. (D,F) is shallow provided for every non-trivial

functional dependency S -> p.@attr

or S -> p.content that is implied by (D,F) , the functional dependency S -> p is also implied by (D,F) where p is any DTD path from the root.

(D,F) is said to be deep if it is not shallow.

4

Shallow, Deep Schemas

.במילים פשוטות יותר,עץ רדוד הוא עץ שאין בו יתירות עבור כל סדרת אלמנטיםS התואמת לסכמה כלשהי( קיים(

p.content )לשם הפשטות נבחר p.contentרק ערך יחיד . p.@attr) באותה מידה יכולנו לבחור

לכן עבור כל סדרת אלמנטיםS עלינו לשמור רק פעם אחת בכדי להבטיח שהכן יהיה קיים ערך יחיד.p.contentאת

הגבלה זו מכריחה אותנו לשמור ערך יחיד שלp.

התואמים סכמות מסוימות xmlהדוגמאות הבאות יציגו עצי לתיאור מידע על סטודנטים וקורסים .כאשר הדרישה מהן

מסוים יהיה שם אחד ויחיד.sno@תהיה שלכל סטודנט עם

5

Deep Schema - Exampleקל לראות שהדרישה אינה מתקיימת שכן המידע על

שמו של סטודנט )במקרה זה st1 חוזר במספר אלמנטים )

בעץ.

6

Shallow Schema - Example לעומת זאת בעץ זה המידע על שמו של סטודנט נשמר במקום יחיד ועל כן הסכימה שמייצגת אותו עומדת

בדרישה.

7

The Problem

In this presentation, we identify a fundamental tension in XML data modeling: )i( data represented as deep trees are often un-normalized, leading to update anomalies. )ii( normalized data tends to be shallow, resulting in heavy use of expensive value-based joins in queries.

8

The Problem – Example1

Consider the query Q1 :”Return names of comedy movies nominated for an Oscar, in which Bette Davis acted” In the Deep-1 approach, one can write the following XQuery expression:

for $m in document)"mdb.xml"(//movie-genre[name = "Comedy"]//movie[.//actor/name = "Bette Davis"]where contains)$m/movie-award/name, "Oscar"(return >m-name>{ $m/name }>/m-name>

Deep-1: The movie-genre nodes are hierarchically organized, with each movie as a child of its primary movie-genre node. Each movie has children movie-award and movie-role nodes,and movie-role nodes have children actor nodes.

9

The Problem – Example 2Shallow-1: The nodes are in a shallower tree structure, and the relationships between movie-genre and movie nodes, between movie-award and movie nodes, and between movie, actor and movie-role nodes, are captured via attributes values. Nodes have an id attribute, a movie may have a movieAwardIdRefs and a movieGenreIdRefs attributes, and movie and actor nodes have the roleIdRefs attributes.

for $mg in document)"mdb.xml"(//movie-genre [name = "Comedy"]//movie-genre,$m in document)"mdb.xml"(//movie, $ma in document)"mdb.xml"(//movie-award,$a in document)"mdb.xml"(//actor[name = "Bette Davis"],$r in document)"mdb.xml"(//movie-rolewhere contains)$ma/name, "Oscar"( and $mg/@id = $m/@movieGenreIdRef andcontains)$m/@movieAwardIdRefs, $ma/@id( and contains)$m/@roleIdRefs, $r/@id( andcontains)$a/@roleIdRefs, $r/@id(return >m-name>{ $m/name }>/m-name>

10

The Solution - MCT

מסמך הפתרון המוצג במאמר משנה את מבנהו הלוגי שלxml באופן הבא:

במקום שהמידע על אלמנט כלשהו ייכתב באופן חלקי בצומתכלשהו ולשארית המידע יהיה רפרנס,המידע על אלמנט יפוזר

בעצים שונים אולם לכל אלמנט יהיה צומת אחד שיהיה משותף למספר עצים עליהם המידע מפוזר.

בכדי שנדע להבחין לאיזה צומת של אלמנט אנו מתייחסים ניתן בעץ movieלכל עץ צבע )כך לדוגמא אנו יכולים להתייחס לאלמנט

בעץ האדום – זהו אותו אלמנט בדיוק, רק movieהירוק או לאלמנט שחלק מהמידע נשמר עליו בעץ הירוק וחלק בעץ האדום וכאשר אנו

רוצים לקבל מידע מסוים עלינו לציין מאיזה עץ לשלוף את המידע(. עצים מהסוג זה יקראוMulti-Colored trees או בקיצור ,

MCT.

11

MCT - Example

12

MCT data model

מודל הנתונים מתאר פורמאלית את מבנה הנתונים שלMCT . מודל הנתונים מגדירMCT:כקבוצה של עצים מסודרים באופן הבא

1. N – finite set of nodes

2. C – finite set of colors

3. A Colored Tree Tc = )Nc , εc( where c C

where 1. Nc N

2. εc Nc × Nc × Nc defines an ordered, rooted tree

satisfying the tree relationships imposed by the XML

data model between the different kinds of nodes, with a

triple (np , nl , n) specifying that node n has np as its

parent and nl as its left sibling.

13

MCT data model

4. [MCT database] A multi-colored tree (MCT) is defined as a triple (N,C,{Tc}) where : 1. Tc , c C is a colored tree. 2. N = c Nc . 3. Each attribute, text and namespace node n1

associated with an element node n2 in any of the colored trees has all the colors of n2, and has n2 as its parent node in each of its colored trees.

An MCT is said to be an MCT database if the root of each of itscolored trees is the same document node (which, hence, has all colors in it), else it is an MCT database fragment.

14

MCT data model Node accessors:

In order for processors to be able to operate on instances of the data model, the model must expose the properties of the items it contains.

The data model does this by defining a family of accessor functions. These are not functions in the literal sense; they are not available for users or applications to call directly. Rather they are descriptions of the information that an implementation of the data model must expose to applications )for example - attributes Accessor , children Accessor , is-id Accessor …(.

Four of these accessors, namely, dm:parent, dm:string-value, dm:typed-value, and dm:children, would need to be extended to take a color into account.

In addition, a new accessor needs to be dened on all node kinds to determine the colors of a given node:

dm:colors)$n as Node( as xs:string+

15

MCT data model

Node Constructors: In the XML data model, each node kind defines its constructors, which always return a new node with unique identity. This is feasible since

the nodes can be constructed iteratively, in a “bottom-up” fashion in the XML tree. In our MCT data model, it is not always possible to construct a node

only after all its children in each of its colors have been constructed. To effectively permit the construction of multi-colored trees, we define two different types of constructors for each node kind.

First-color node constructors are like constructors in the XML data model, except that they are extended to take a color into account, and return a new node with unique identity.

Next-color node constructors take a previously constructed node, and add a color and the tree relationships in that color;

the same node is returned.

16

DATA MANIPULATION LANGUAGES

מודל הנתונים שהוגדר מהווה הרחבה למודל הנתונים הקיים שלXML. המודל מאפשר לנו להרחיב את שפת השאילתותXQuery בהתאמה

.MCXQueryלשפה חדשה הנקראת

17

MCXQuery Path Expressions

In the MCT logical data model, a node may have multiple colors, in which case it would belong to multiple colored trees.

Hence, an axis and a node test specification )e.g., parent::node)(( does not suffice to uniquely identify the navigation to be performed in a single step, from a context node.

However, since a node belongs to exactly one rooted colored tree, for each of its colors, expanding the specification of a step by a color would serve to provide the necessary disambiguation.

We achieve this by enclosing the color specification in curlybraces, preceding the axis specification in the step expression, e.g. :

{red}descendant::movie, {blue}child::movie-role.

18

MCXQuery Constructor Expression

We would like to create new colored trees in an MCT database.

XQuery provides constructor expressions that can create XML tree structures within a query.

However, The result of an element constructor in XQuery is always a new element, which is inappropriate for constructor expressions in MCXQuery, since such a node would have a different identity from existing nodes.

19

MCXQuery Constructor Expression

MCXQuery constructor expressions need the ability to reuse existing nodes and their descendants, in addition to being able to create element nodes with new identities. This is achieved as follows.

When an enclosed expression is evaluated, its value )a sequence of items( retains the identities of nodes in the sequence,

instead of creating copies by default. This is similar to the behavior of MCXQuery path expressions.

To create node copies, MCXQuery provides a function named createCopy. The createCopy function takes any sequence of items as its argument, and returns copies of the items in the sequence, in the same order.

The function for constructing new colored tree call: CreateColor)color , MCXQuery constructor expressions(

20

MCXQuery Expression - Example

for $m in document)"mdb.xml"(/ {green} descendant::movie-award [contains) {green}child::name, "Oscar"(]/{green}descendant::movie,

$r in document)"mdb.xml"(/{red}descendant::movie-genre[{red}child::name = "Comedy"]/{red}descendant::movie[. = $m]/{red}child::movie-role,

$r in document)"mdb.xml"(/{blue}descendant::actor[{blue}child::name = "Bette Davis"]/ {blue}child::movie-role

return createColor)black, >m-name>{$m/{red}child::name} >/m-name>(

Q1 : ”Return names of comedy movies nominated for an Oscar, in which Bette Davis acted”.

21

MCXQuery Constructor Expression - Example

Q2 :Return the list of Oscar nominated movies, grouped by the number of votes received.

Result of evaluating Q

22

SERIALIZATION OF MCT DATABASES

XML.הוא הסטנדרט בפעל להחלפת מידע מטרתה של הסריאליזציה היא ליצור מסמך

xml ממודל MCT לצורך החלפת מידע בין אפליקציות בצורה נוחה.

ברצוננו שגרסת הXML הסריאלית עבור מודל MCT: תספק

יהיה ניתן ביעילות לבנות מחדש את מודל ה MCT ממנה.

.הגרסה תהיה קומפקטית

23

Real and Primary Colors

For each element node type : Call the colors )hierarchies( in which it appears in the MCT

database its real colors. Call the hierarchy )color( in which an element is represented in a

serialization, its primary color w.r.t. the serialization.

24

Real and Primary Colors - Example

Consider our running example database. For illustration, suppose movie elements additionally have category subelements in the green hierarchy, movie-role can have payment subelement in the blue hierarchy and description and scene subelements in the red hierarchy.

So, movie elements have red and green as real colors and theseare their only possible primary color choices.

The name subelement of movie has the same primary color choices, although its choice is determined by that of its parent movie element.

The movie-role element can have blue or red as its primary color, since it is present in those hierarchies. But, surprisingly green is also a primary color choice for movie-role, even though it is not its real color )true only when movie element’s primary color is chosen to be green(.

25

Real and Primary Colors

במילים מעט יותר פורמאליות, לכל צומת ב"עץ" ה MCT ניתן באופן הבא : primary colorלבחור לו

אם צבעי הצומת זהים או מוכלים בצבעים של אביו אזי צבעו נקבע לפיצבעו של אביו. גם אם הצבע שנבחר לאביו אינו אחד מצבעי הצומת

האמתיים. אחרת אם קיים צבעC.אזי ניתן שאינו מופיע אצל אביו בהיררכיה

עבור אותה צומת. primary color כ Cלבחור גם את

26

Cost based Serialization

הסעיף מתייחס לדרישה שגרסת הXML הסריאלית עבור מודל MCT תהיה קומפקטית )כלומר שגודלה בביטים יהיה קטן יותר(.

משום שברצוננו לייצג מודלMCT ע"י XML:עלינו להתייחס לשני דברים במודלMCT אלמנט היה מיוצג ע"י כמה צמתים בכמה עצים. על כן יש לבחור

צומת אחת בעץ מסוים ולתת לה להחזיק את המידע עבור אותו אלמנט. בשאר העצים יהיה רפרנס לאותה צומת.

עלינו לשמור מידע על צבעיה האמתיים של צומת בכדי שנוכל לשחזר את מודל. MCTה

משום שגודלה של גרסה תלוי באורך המחרוזות הנמצאות בה )לדוגמא תתפוס פחות מקום מהמחרוזת של redסביר שהמחרוזת עבור הצבע

(, קשה להעריך את גודלה של גרסה במדויק.pale blueהצבע בכדי להעריך את גודלה היחסי של גרסה מסתכלים על מספר לכן

המקורי )כלומר MCTהאלמנטים אשר אנו מוסיפים למודל המזהים/רפרנסים ומידע על צבעי הצמתים(.

27


Association of a color attribute with certain elements in the serialization:

The color attribute type is a set of strings of the form >color>[ _ ], where >color> is a string representing a color and _ is one of +, - , and is optional.

If the color attribute of an element e contains the value ”blue+”, it means e as well as its entire subtree in the serial representation have color blue )in addition to others(. Similarly, “blue-” says the relevant subtree is not blue, whereas “blue” only affects e's color.

These color denotations can override: e.g., “blue+” at a descendant of e whose color includes “blue-” overrides the latter and says the descendant has color blue.

28


Let cost)e,c(- for element type e and color c, represent the cost of choosing c as the primary color for e.

This cost function counts the minimal number of id/idrefs and colors we have to add to the subtree of e in the XML file, when choosing c as primary color for e.

29

Cost based Serialization - Example

Consider the cinema example with “few” cutbacks.

movie-genre

movie

name (The Good The Bad And The Ugly)

movie-role

name (Lee Van Cleef)

name(Clint Eastwood)

movie-role

actors

actor actor

movie-role movie-role



name (spaghetti movie)

30

Cost based Serialization – Example1

one of the options for primary color choice is: blue for movie-role,movie-role/name.

>movie-genre color=“red+”> >name>spaghetti movie>/name> >movie id=“1966” >

>name>The Good The Bad And The Ugly>/name>>/movie>

>/movie-genre> >actors color=”blue+” >

>actor>>movie-role movie_id=“1966” color=”red+” >

>name>The Good>/name>>/movie-role>

>/actor>>actor>

>movie-role movie_id=“1966” color=”red+” >>name>The Bad>/name>

>/movie-role>>/actor>

>/actors>

movie-genre

movie


actors

actor actor

movie-role

movie-role




3מספר המזהים/רפרנסים –

4מספר הצבעים -

31

Cost based Serialization – Example2

one of the options for primary color choice is: red for movie-role,movie-role/name >movie-genre color=“red+”> >name>spaghetti movie>/name> >movie>

>name>The Good The Bad And The Ugly>/name>>movie-role actor_id=“Clint EastWood” color=”blue+” >

>name>The Good>/name>>/movie-role>>movie-role actor_id=“Lee Van Cleef” color=”blue+” >

>name>The Bad>/name>>/movie-role>

>/movie> >/movie-genre> >actors color=”blue+” >

>actor id=“Clint EastWood” >>/actor>>actor id=“Lee Van Cleef” >>/actor>

>/actors>

actors

actor actor

movie-genre

movie



movie-role



movie-role

4מספר המזהים/רפרנסים –

4מספר הצבעים -

32

Optimal Serialization

-המטרה היא להביא לMin sumelement e where e is a root in at least one of the colored trees cost)e,c(

'כיוון שהפונcost סוכמת את התוספות על כל תת העץ של הצומת הנתונה לה הרי שבכדי למצוא את סכום התוספות לכל בסיס הנתונים מספיק להסתכל על

סכום התוספות לשורשי העצים.

המאמר מביא אלגוריתם ללא הוכחה המביא למינימום של הפונ' הנ"ל.:האלגוריתם מניח

קיים מידע סטטיסטי המכיל מידע עבור מספר הבנים הממוצע מכל סוג שיש לצומת.

לכל צומת ניתן לבחור ל primary color רק צבע שהינו חלק מהמודל .c C כך ש cכלומר צבע

.אין מעגלים בסכמה של המודל עבור כל אלמנט במודל, כל ההירארכיות מלאות )כלומר לא קיים אלמנט

עבורו חסר מידע בהירארכיה אחת או יותר(.

33

Optimal Serialization

Let quant)m,shade( be a function that for an element type m and color shade returns the average number of children of type m for an element corresponding to m's parent type in the hierarchy with color shade.

For example, quant)movie-role,red( = 10 means on an average, a movie has 10 movie-roles.

34

Optimal Serialization – The Algorithm

MCTהאלגוריתם מקבל סכמת כקלט עובר באופן איטארטיבי

על top-downבשיטת האלמנטים בכל עץ ולכל אלמנט

המביא primary colorבוחר . costלמינימום את הפונ'

כאמור מקבלת costהפונ' חוקי primary color mאלמנט ו

ומחזירה את המחיר )במספר mיבחר אלמנטים נוספים( באם

. primary color להיות

35

Optimal Serialization – The Algorithm

אחרי שחשבנו את העלות עבור השינויים בצומת עצמו,

נוסיף לעלות את עלויות השינויים המתבקשים בבניו של הצומת )הכוונה לבניו בכל העצים בהם הצומת

.משתתף(

לכל סוג אלמנט שהינו בן של הצומת נמצא את

הצבע בעל העלות המינימאלית תחת

האילוץ שלאביו )כלומר הצומת( כבר נבחר

shadeהצבעprimary color.להיות

את העלות המינימאלית שמצאנו לבן נכפיל במספר הבנים מאותו סוג אלמנט

( ונוסיף quant)בעזרת הפונ' את התוצאה לעלות הכוללת

של בחירת הצבע לצומת.

36

IMPLEMENTATION

כיום ישנן גישות רבות כיצד ניתן לאחסן מסמך XML כולל ,בצורה של מבנה נתונים רלציוני או מבנה נתונים הקרוב יותר

.)XML )implementation nativeלמודל הטבעי של במאמר מתואר מימוש ספציפי של מודל לאחסוןMCT ,

עם מספר Timberהמשתמש במערכת אחסון הנתונים שינויים.

37

Timber

Timber is a native XML database, in which XML data is stored directly, retaining its natural tree Structure.

The Data Parser takes an XML document as input, and produces a parse tree as output.

The Data Manager takes each node of this parse tree as it is produced, transforms it incrementally into an internal representation and stores it into Shore )a file system( as an atomic unit of storage.

38

Timber

For storage efficiency reasons, a node in the Timber Data Manager is not exactly the same as a DOM node.

There is a node corresponding to each element, with child nodes for sub-elements )which is called relationships structural node since nodes are linked through it(.

However, all attributes of an element node are clubbed together into a single node, which is then stored as a child node of that element node.

Also, the content of an element node, if any, is pulled out into a separate child node. If the node is of mixed type, with multiple content parts interspersed with sub-elements, each content part is pulled out into a separate child node.

39

MCT Implementation

For a multi-colored element, the content and attribute nodes remain the same as before.

However, for each color hierarchy that the element participates in there is one structural relationships node.

There is only one critical shortcoming with the system we introduced so far. The XML database system we had didnot provide a means to navigate from an attribute or a content

node to his father )structural node(. Hence, there is no way to pass

through the multiple colors ofa given node.

40

MCT Implementation

We addressed this by introducing additional “attributes” for multi-colored nodes that provide links back to each of the corresponding single-colored structural nodes.

41

MCT Implementation – Query Execution

Each MC-query is decomposed into components that have a single color. Each single color query evaluation proceeds in the normal manner.

A color transition is accomplished by a cross-tree join access method, which simply follows the links described above to obtain the structural node of each element for the color being transitioned to.

This access method is implemented in a straightforward fashion as an attribute-value based join.

Since color transitions are not free, alternative plans are often worth considering : it may be preferable to perform a single-color query, then a cross-tree

join, before evaluating the next single-color query, to benefit from a selection that greatly reduces the size of the latter computation.

42

Experimental Evaluation: Setup

All experiments were performed on a single processor Pentium IIIM 866MHz equipped with 512 Mbytes of memory, 30GBytes of disk storage and Windows 2000 operating system. The buffer pool size was set to 256Mbytes and data page size configured to 8Kbtyes.

Data sets TPC-W: from XBench + 5 colors SIGMOD Record: scaled-up )600KB ! 60MB( + 2 colors

Queries TPC-W: 18 queries, 7 updates SIGMOD Record: 6 queries, 4 updates

43

Experimental Evaluation: Storage

Deep tree has many more elements, requires more storage.

MCT has same number of elements as shallow, but requires more storage.

44

Experimental Evaluation: Query Processing Time

On the simple case, when we have only one tree and one color and we don’t have to do joins operation, all queries got about the same performance.

When we have more then one tree and more then one color involve in the Query as in TQ3. The performance of both MCT and the shallow databases are poor comparing to the performance of the deep database as a result of the joins operations.

The deep database suffer from poor performances when we ask to do operations as : updatesor duplicates elimination operations.

In some cases, as in TQ9, where we use only color but two trees the performances of MCT substantially better than the shallow’s.

•Q= Read only

•U= update

•D= without duplicate elimination

•Query processing time in seconds.

• Trees indicates the num of trees we used in the shallow scheme.

45

Future Work

formally extending XML schema to multi-colored trees.

A more sophisticated implementation

which will bring down the cost of a color crossing substantially.

46

The End

תודה על ההקשבה

colorful xml: one hierarchy isn't enough

Documents