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, אשר ביחד מהווים עץ מכוון (בעל שורש). סדר טוב ">" על הצמתים, אשר שומר על כיווני העץ  אם צומת y הוא בן של x אז 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 Deep-1: The movie-genrenodes are hierarchically organized,with each movie as a child of its primary movie-genrenode.Each moviehas children movie-awardand movie-rolenodes,and movie-rolenodes have children actornodes. 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>

9. The Problem – Example 2 Shallow-1: The nodes are in a shallower tree structure, and the relationships between movie-genreand movienodes, between movie-award and movienodes, and between movie, actorand movie-rolenodes, are captured via attributes values. Nodes have an id attribute, a movie may have a movieAwardIdRefsand a movieGenreIdRefsattributes, and movieand actornodes have the roleIdRefsattributes. 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-role where contains($ma/name, "Oscar") and $mg/@id = $m/@movieGenreIdRef and contains($m/@movieAwardIdRefs, $ma/@id) and contains($m/@roleIdRefs, $r/@id) and contains($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 כקבוצה של עצים מסודרים באופן הבא: • N – finite set of nodes • C – finite set of colors • 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] Amulti-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 its colored 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 curly braces, 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 Q1 : ”Return names of comedy movies nominated for an Oscar, in which Bette Davis acted”. 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>)

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 realcolors. • Call the hierarchy (color) in which an element is representedin 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 categorysubelements in the green hierarchy, movie-role can have paymentsubelement in the blue hierarchy and description and scenesubelements in the red hierarchy. 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). The name subelement of movie has the same primary color choices, although its choice is determined by that of its parent movie element. So, movie elements have red and green as real colors and these are their only possible primary color choices.

25. Real and Primary Colors • במילים מעט יותר פורמאליות, לכל צומת ב"עץ" ה MCTניתן לבחור לו primary color באופן הבא : • אם צבעי הצומת זהים או מוכלים בצבעים של אביו אזי צבעו נקבע לפי צבעו של אביו. גם אם הצבע שנבחר לאביו אינו אחד מצבעי הצומת האמתיים. • אחרת אם קיים צבע C שאינו מופיע אצל אביו בהיררכיה.אזי ניתן לבחור גם את C כ primary color עבור אותה צומת.

26. Cost­ based Serialization • הסעיף מתייחס לדרישה שגרסת הXML הסריאלית עבור מודל MCT תהיה קומפקטית (כלומר שגודלה בביטים יהיה קטן יותר). • משום שברצוננו לייצג מודל MCT ע"י XML עלינו להתייחס לשני דברים: • במודל MCT אלמנט היה מיוצג ע"י כמה צמתים בכמה עצים. על כן יש לבחור צומת אחת בעץ מסוים ולתת לה להחזיק את המידע עבור אותו אלמנט. בשאר העצים יהיה רפרנס לאותה צומת. • עלינו לשמור מידע על צבעיה האמתיים של צומת בכדי שנוכל לשחזר את מודל ה MCT. • משום שגודלה של גרסה תלוי באורך המחרוזות הנמצאות בה (לדוגמא סביר שהמחרוזת עבור הצבע red תתפוס פחות מקום מהמחרוזת של הצבע pale blue), קשה להעריך את גודלה של גרסה במדויק. • לכן בכדי להעריך את גודלה היחסי של גרסה מסתכלים על מספר האלמנטים אשר אנו מוסיפים למודל הMCT המקורי (כלומר מזהים/רפרנסים ומידע על צבעי הצמתים).

27. Cost­based Serialization • 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. Cost­based Serialization • 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. actors movie-genre name (spaghetti movie) actor actor movie movie-role movie-role movie-role movie-role name (The Good The Bad And The Ugly) name (Lee Van Cleef) name (Clint Eastwood) name (Lee Van Cleef) name (Clint Eastwood) Cost­based Serialization- Example • Consider the cinema example with “few” cutbacks.

30. actors movie-genre name (spaghetti movie) actor actor movie movie-role movie-role name (The Good The Bad And The Ugly) name (Lee Van Cleef) name (Clint Eastwood) 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> מספר המזהים/רפרנסים – 3 מספר הצבעים - 4

31. actors movie-genre actor name (spaghetti movie) actor movie movie-role movie-role name (The Good The Bad And The Ugly) name (Lee Van Cleef) name (Clint Eastwood) 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> מספר המזהים/רפרנסים – 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 אחרי שחשבנו את העלות עבור השינויים בצומת עצמו, נוסיף לעלות את עלויות השינויים המתבקשים בבניו של הצומת (הכוונה לבניו בכל העצים בהם הצומת משתתף). את העלות המינימאלית שמצאנו לבן נכפיל במספר הבנים מאותו סוג אלמנט (בעזרת הפונ' quant) ונוסיף את התוצאה לעלות הכוללת של בחירת הצבע לצומת. לכל סוג אלמנט שהינו בן של הצומת נמצא את הצבע בעל העלות המינימאלית תחת האילוץ שלאביו (כלומר הצומת) כבר נבחר הצבעshade להיות .primary color

36. IMPLEMENTATION • כיום ישנן גישות רבות כיצד ניתן לאחסן מסמך XML, כולל בצורה של מבנה נתונים רלציוני או מבנה נתונים הקרוב יותר למודל הטבעי של XML (implementationnative). • במאמר מתואר מימוש ספציפי של מודל לאחסון 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 intoaseparate child node. If the node is of mixed type, withmultiple 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 did not 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 of a 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 joinaccess 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 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. In some cases, as in TQ9, where we use only color but two trees the performances of MCT substantially better than the shallow’s. 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. The deep database suffer from poor performances when we ask to do operations as : updatesor duplicates elimination operations. • 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 • תודה על ההקשבה