Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Colorful XML: One Hierarchy Isn't Enough Authors : H. V. Jagadish, Laks V. S. Lakshmanan, Monica Scannapieco, Divesh Srivastava, Nuwee Wiwatwattana Presented.

Similar presentations


Presentation on theme: "1 Colorful XML: One Hierarchy Isn't Enough Authors : H. V. Jagadish, Laks V. S. Lakshmanan, Monica Scannapieco, Divesh Srivastava, Nuwee Wiwatwattana Presented."— Presentation transcript:

1 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 2 עצים סדורים ומתויגים באופן פורמאלי, מסמך XML יתאר את המבנה הקומבינטורי בעל הרכיבים הבאים:  קבוצת צמתים (nodes) N וקבוצת קשתות E, אשר ביחד מהווים עץ מכוון (בעל שורש).  סדר טוב ">" על הצמתים, אשר שומר על כיווני העץ  אם צומת y הוא בן של x אז x

3 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 -> 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 4 Shallow, Deep Schemas במילים פשוטות יותר,עץ רדוד הוא עץ שאין בו יתירות. עבור כל סדרת אלמנטים S (התואמת לסכמה כלשהי) קיים רק ערך יחיד p.content (לשם הפשטות נבחר p.content באותה מידה יכולנו לבחור( לכן עבור כל סדרת אלמנטים S עלינו לשמור רק פעם אחת את p.content בכדי להבטיח שהכן יהיה קיים ערך יחיד. הגבלה זו מכריחה אותנו לשמור ערך יחיד של p. הדוגמאות הבאות יציגו עצי xml התואמים סכמות מסוימות לתיאור מידע על סטודנטים וקורסים.כאשר הדרישה מהן תהיה שלכל סטודנט מסוים יהיה שם אחד ויחיד.

5 5 Deep Schema - Example קל לראות שהדרישה אינה מתקיימת שכן המידע על שמו של סטודנט (במקרה זה st1) חוזר במספר אלמנטים בעץ.

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

7 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 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 } 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 9 The Problem – Example 2 Shallow-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-role where contains($ma/name, "Oscar") and = and and and return { $m/name }

10 10 The Solution - MCT הפתרון המוצג במאמר משנה את מבנהו הלוגי של מסמך xml באופן הבא:  במקום שהמידע על אלמנט כלשהו ייכתב באופן חלקי בצומת כלשהו ולשארית המידע יהיה רפרנס,המידע על אלמנט יפוזר בעצים שונים אולם לכל אלמנט יהיה צומת אחד שיהיה משותף למספר עצים עליהם המידע מפוזר.  בכדי שנדע להבחין לאיזה צומת של אלמנט אנו מתייחסים ניתן לכל עץ צבע (כך לדוגמא אנו יכולים להתייחס לאלמנט movie בעץ הירוק או לאלמנט movie בעץ האדום – זהו אותו אלמנט בדיוק, רק שחלק מהמידע נשמר עליו בעץ הירוק וחלק בעץ האדום וכאשר אנו רוצים לקבל מידע מסוים עלינו לציין מאיזה עץ לשלוף את המידע). עצים מהסוג זה יקראו Multi-Colored trees, או בקיצור MCT.

11 11 MCT - Example

12 12 MCT data model מודל הנתונים מתאר פורמאלית את מבנה הנתונים של MCT. מודל הנתונים מגדיר MCT כקבוצה של עצים מסודרים באופן הבא: 1. N – finite set of nodes 2. C – finite set of colors 3. A Colored Tree T c = (N c, ε c ) where c  C where 1. N c  N 2. ε c  N c × N c × N c defines an ordered, rooted tree satisfying the tree relationships imposed by the XML data model between the different kinds of nodes, with a triple (n p, n l, n) specifying that node n has n p as its parent and n l as its left sibling.

13 13 MCT data model 4. [MCT database] A multi-colored tree (MCT) is defined as a triple (N,C,{T c }) where : 1. T c, c  C is a colored tree. 2. N =  c N c. 3. Each attribute, text and namespace node n 1 associated with an element node n 2 in any of the colored trees has all the colors of n 2, and has n 2 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 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 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 16 DATA MANIPULATION LANGUAGES מודל הנתונים שהוגדר מהווה הרחבה למודל הנתונים הקיים של XML. המודל מאפשר לנו להרחיב את שפת השאילתות XQuery בהתאמה לשפה חדשה הנקראת MCXQuery.

17 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 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 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 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/{red}child::name} ) Q1 : ”Return names of comedy movies nominated for an Oscar, in which Bette Davis acted”.

21 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 22 SERIALIZATION OF MCT DATABASES XML הוא הסטנדרט בפעל להחלפת מידע. מטרתה של הסריאליזציה היא ליצור מסמך xml ממודל MCT לצורך החלפת מידע בין אפליקציות בצורה נוחה. ברצוננו שגרסת הXML הסריאלית עבור מודל MCT תספק :  יהיה ניתן ביעילות לבנות מחדש את מודל הMCT ממנה.  הגרסה תהיה קומפקטית.

23 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 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 these are 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 25 Real and Primary Colors במילים מעט יותר פורמאליות, לכל צומת ב"עץ" ה MCTניתן לבחור לו primary color באופן הבא :  אם צבעי הצומת זהים או מוכלים בצבעים של אביו אזי צבעו נקבע לפי צבעו של אביו. גם אם הצבע שנבחר לאביו אינו אחד מצבעי הצומת האמתיים.  אחרת אם קיים צבע C שאינו מופיע אצל אביו בהיררכיה. אזי ניתן לבחור גם את C כ primary color עבור אותה צומת.

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

27 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 [ _ ], where 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 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 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 movie-role name (Clint Eastwood) name (Lee Van Cleef) name (spaghetti movie)

30 30 Cost­based Serialization – Example1 one of the options for primary color choice is: blue for movie-role,movie-role/name. spaghetti movie The Good The Bad And The Ugly The Good The Bad movie-genre movie name (The Good The Bad And The Ugly) actors actor movie- role name (Clint Eastwood) name (Lee Van Cleef) name (spaghet ti movie) מספר המזהים/רפרנסים – 3 מספר הצבעים - 4

31 31 Cost­based Serialization – Example2 one of the options for primary color choice is: red for movie-role,movie-role/name spaghetti movie The Good The Bad And The Ugly The Good The Bad actors actor movie- genre movi e name (spaghe tti movie) name (The Good The Bad And The Ugly) movie- role name (Lee Van Cleef) name (Clint Eastwood) movie- role מספר המזהים/רפרנסים – 4 מספר הצבעים - 4

32 32 Optimal Serialization המטרה היא להביא ל- Min sum element e where e is a root in at least one of the colored trees cost(e,c)  כיוון שהפונ' cost סוכמת את התוספות על כל תת העץ של הצומת הנתונה לה הרי שבכדי למצוא את סכום התוספות לכל בסיס הנתונים מספיק להסתכל על סכום התוספות לשורשי העצים. המאמר מביא אלגוריתם ללא הוכחה המביא למינימום של הפונ' הנ"ל. האלגוריתם מניח:  קיים מידע סטטיסטי המכיל מידע עבור מספר הבנים הממוצע מכל סוג שיש לצומת.  לכל צומת ניתן לבחור ל primary color רק צבע שהינו חלק מהמודל כלומר צבע c כך ש c  C.  אין מעגלים בסכמה של המודל.  עבור כל אלמנט במודל, כל ההירארכיות מלאות (כלומר לא קיים אלמנט עבורו חסר מידע בהירארכיה אחת או יותר).

33 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 34 Optimal Serialization – The Algorithm האלגוריתם מקבל סכמת MCT כקלט עובר באופן איטארטיבי בשיטת top-down על האלמנטים בכל עץ ולכל אלמנט בוחר primary color המביא למינימום את הפונ' cost. הפונ' cost כאמור מקבלת אלמנט וprimary color mחוקי ומחזירה את המחיר (במספר אלמנטים נוספים) באם יבחרm להיות primary color.

35 35 Optimal Serialization – The Algorithm אחרי שחשבנו את העלות עבור השינויים בצומת עצמו, נוסיף לעלות את עלויות השינויים המתבקשים בבניו של הצומת (הכוונה לבניו בכל העצים בהם הצומת משתתף). לכל סוג אלמנט שהינו בן של הצומת נמצא את הצבע בעל העלות המינימאלית תחת האילוץ שלאביו (כלומר הצומת) כבר נבחר הצבעshade להיות.primary color את העלות המינימאלית שמצאנו לבן נכפיל במספר הבנים מאותו סוג אלמנט (בעזרת הפונ' quant) ונוסיף את התוצאה לעלות הכוללת של בחירת הצבע לצומת.

36 36 IMPLEMENTATION כיום ישנן גישות רבות כיצד ניתן לאחסן מסמך XML, כולל בצורה של מבנה נתונים רלציוני או מבנה נתונים הקרוב יותר למודל הטבעי של XML (implementation native). במאמר מתואר מימוש ספציפי של מודל לאחסון MCT, המשתמש במערכת אחסון הנתונים Timber עם מספר שינויים.

37 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 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 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 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 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 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 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 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 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 46 The End תודה על ההקשבה


Download ppt "1 Colorful XML: One Hierarchy Isn't Enough Authors : H. V. Jagadish, Laks V. S. Lakshmanan, Monica Scannapieco, Divesh Srivastava, Nuwee Wiwatwattana Presented."

Similar presentations


Ads by Google