brief overview over related work is

brief overview over related work is given. Section 3 starts introducing the family of XCube formats. Besides the basic standards for storing dimensions, classification hierarchies and facts also some advanced, dynamic standards are dealt with, that allow to build a basic service infrastructure. Section 5 closes with an outlook how XCube can be combined with Web Services and some remarks on our prototype. 2. MOTIVATING USE CASES Before explaining XCube this section is meant to sketch some typical use cases that could benefit from our approach. The driving force between all the scenarios presented below is that many data warehouses exist containing lots of valuable information spread over different departments of the same company or even over different companies. The exchange of data between these heterogeneous systems could be done much easier if there was a unique format for describing the data warehouse data in a standardized way. 2.1 The “Download” Use Case A web server offers data warehouse cubes for download (figure 1). Every client data warehouse interested in this data can download it and integrate it into its local database. First of all the description of the multidimensional schema of the cube is downloaded, in a second step the master data is exchanged, i.e. the classification hierarchies of the single dimensions. Finally the transaction data is sent to the requestor and integrated into its local data warehouse. The integration on the client side is easy as long as any expression in the new cube does not conflict with those of existing data cubes. If on the other hand for example a dimension already exists the exact relationship between the two has to be carefully checked, which leads to the problem of semantic integration. An interesting tool for integrating data from various sources could be the use of standardized reference dimensions. 2.2 The “Query” Use Case As the amount of data of a multidimensional cube is usually rather large (especially the transaction data part) the possibility to analyze data cubes online, i.e. on the (web) server side, is highly desirable to reduce the consumption of network capacities. In the online query case only schema and master data have to be downloaded from the web server completely which are smaller by magnitudes (steps 1 and 2 in figure 2). With this description in hand the client application (not only data warehouses but e.g. OLAP tools) can decide which subset of the data cube it needs and can then send an according query to the web server (step 3). The server then computes the desired transaction data subcube and sends it to the client (step 4). If the client application is a data warehouse that wants to integrate the result into its own database, this use case is a generalization of the download case presented in section 2.1.
For the query scenario it is important to think about an update strategy for schema and master data on the client side because when the client keeps this data for a longer time it can become outdated. The problem of conflicting expressions has to be treated in the same way as mentioned above.
2.3 The “Generating” Use Case The generating case is about how to create data cubes that can be offered by a web server. In principle data of any format from all kinds of data sources can be converted to a multidimensional cube. The conversion process is the same as when integrating a new source into a warehouse: the data has to undergo the complete ETL workflow. The more interesting case is generating an online cube from an existing data warehouse. Here the expensive integration task is already done and it only has to be decided which subset of the data is to be published. The transformation of multidimensional data (independent of relational or multidimensional storage) is simple and can be done automatically. For implementing this case the introduction of a data mart holding only that subset of data that is meant for going online might be useful. Another interesting design choice for implementation is if transforming the warehouse data into online cubes is done statically or dynamically on demand by a set of SQL queries. 2.4 Requirements for Representing Online Data Cubes The last three subsections gave a set of examples motivating the necessity of a web based format for exchanging data cubes. This paper describes XCube, a family of XML schemas to precisely describe these online cubes. As the cubes are supposed to be transferred over the Internet and contain highly structured data, using XML ([1], [2]) seems reasonable. Before explaining the XCube standards in the next section a list of requirements to a format expressing online data cubes is introduced which can be easily derived from the scenarios presented above. 1. The format has to support a multidimensional data model. 2. The conceptual distinction between the description of schema, master or dimension data and transaction or fact data has to be supported. 3. The format has to be trans

ผลลัพธ์ (ไทย) 1:

ภาพรวมโดยย่อผ่านงานที่เกี่ยวข้องได้ ส่วนที่ 3 เริ่มต้นแนะนำครอบครัวของ XCube รูปแบบ นอกจากมาตรฐานขั้นพื้นฐานสำหรับการจัดเก็บขนาด ประเภทลำดับชั้น และข้อเท็จจริงบางส่วนการ มาตรฐานแบบไดนามิกจะจัดการกับ ที่อนุญาตให้สร้างโครงสร้างพื้นฐานการบริการพื้นฐาน ส่วนที่ 5 ปิด ด้วย outlook วิธี XCube สามารถใช้ร่วมกับบริการเว็บและบางคำสั่งต้นแบบของเรา 2. สร้างแรงจูงใจใช้กรณีก่อนอธิบาย XCube ส่วนนี้จะหมายถึงการร่างบางกรณีใช้งานทั่วไปที่จะได้ประโยชน์จากแนวทางของเรา แรงขับเคลื่อนระหว่างสถานการณ์ทั้งหมดที่ปรากฏด้านล่างว่า คลังข้อมูลมากมายที่มีอยู่ที่ประกอบด้วยจำนวนมากข้อมูลกระจาย ผ่านแผนกต่าง ๆ ของบริษัทเดียวกัน หรือการที่บริษัทต่าง ๆ ได้ การแลกเปลี่ยนข้อมูลระหว่างระบบที่แตกต่างกันเหล่านี้อาจทำได้ง่ายมากถ้ามีรูปแบบเฉพาะสำหรับการอธิบายข้อมูลคลังสินค้าข้อมูลในวิธีมาตรฐาน 2.1 A กรณีใช้ "ดาวน์โหลด" เว็บเซิร์ฟเวอร์มีก้อนสินค้าข้อมูลดาวน์โหลด (รูป 1) คลังข้อมูลลูกค้าทุกที่สนใจข้อมูลนี้สามารถดาวน์โหลด และรวมไว้ในฐานข้อมูลของท้องถิ่น แรกของทุกคำอธิบายของแบบแผนหลายมิติของ cube จะถูกดาวน์โหลด ในสองขั้นตอนมีการแลกเปลี่ยนข้อมูลหลัก เช่นการจำแนกลำดับชั้นของมิติเดียว ในที่สุด ธุรกรรมข้อมูลถูกส่งไป requestor และรวมเข้าคลังข้อมูลภายในเครื่อง รวมบนฝั่งไคลเอ็นต์ได้ง่าย ๆ ตราบใดที่นิพจน์ใด ๆ ใน cube ใหม่ไม่ขัดแย้งกับของลูกบาศก์ข้อมูลที่มีอยู่ ถ้าในมืออื่นๆ ตัวอย่างเช่นมิติอยู่แล้ว ความสัมพันธ์ที่แน่นอนระหว่างสองมีการระมัดระวังตรวจสอบ ซึ่งนำไปสู่ปัญหาของตรรกรวม เครื่องมือสำหรับการบูรณาการข้อมูลจากแหล่งต่าง ๆ ที่น่าสนใจอาจเป็นการใช้มาตรฐานอ้างอิงขนาด 2.2 "สอบถาม" ใช้กรณีที่จำนวนข้อมูลของหลายมิติ cube เป็นมักจะค่อนข้างใหญ่ (โดยเฉพาะอย่างยิ่งธุรกรรมข้อมูลส่วน) ความเป็นไปได้ในการวิเคราะห์ข้อมูลก้อนออนไลน์ เช่นบนฝั่งเซิร์ฟเวอร์ (web) เป็นต้องลดปริมาณการใช้เครือข่ายความจุ ในกรณีแบบสอบถามออนไลน์ ข้อมูล schema และหลักเฉพาะต้องดาวน์โหลดได้จากเว็บเซิร์ฟเวอร์อย่างสมบูรณ์ซึ่งมีขนาดเล็ก โดย magnitudes (ขั้น 1 และ 2 ในรูปที่ 2) ด้วยคำอธิบายนี้ในมือ แอพลิเคชันไคลเอนต์ (ไม่เฉพาะคลังข้อมูลแต่เช่นเครื่องมือ OLAP) สามารถตัดสินใจได้ว่า ชุดย่อยของข้อมูล cube มันต้องแล้วสามารถส่งแบบสอบถามตามเว็บเซิร์ฟเวอร์ (ขั้นตอนที่ 3) เซิร์ฟเวอร์คำนวณ subcube ข้อมูลธุรกรรมที่ต้องการแล้ว และส่งไปยังไคลเอนต์ (ขั้นตอนที่ 4) ถ้าแอพลิเคชันไคลเอนต์เป็นคลังข้อมูลที่ต้องการรวมผลลงในฐานข้อมูลของตนเอง ใช้กรณีนี้เป็นลักษณะทั่วไปที่แสดงในส่วน 2.1 กรณีดาวน์โหลดสอบถามสถานการณ์จึงเป็นสิ่งสำคัญที่คิดเกี่ยวกับกลยุทธ์การปรับปรุงสำหรับเค้าร่างและข้อมูลหลักของไคลเอ็นต์เนื่องจากเมื่อไคลเอนต์เก็บข้อมูลนี้เป็นเวลานานมันจะกลายเป็นล้าสมัย ปัญหาความขัดแย้งนิพจน์มีไว้เหมือนดังกล่าวข้างต้น2.3 The “Generating” Use Case The generating case is about how to create data cubes that can be offered by a web server. In principle data of any format from all kinds of data sources can be converted to a multidimensional cube. The conversion process is the same as when integrating a new source into a warehouse: the data has to undergo the complete ETL workflow. The more interesting case is generating an online cube from an existing data warehouse. Here the expensive integration task is already done and it only has to be decided which subset of the data is to be published. The transformation of multidimensional data (independent of relational or multidimensional storage) is simple and can be done automatically. For implementing this case the introduction of a data mart holding only that subset of data that is meant for going online might be useful. Another interesting design choice for implementation is if transforming the warehouse data into online cubes is done statically or dynamically on demand by a set of SQL queries. 2.4 Requirements for Representing Online Data Cubes The last three subsections gave a set of examples motivating the necessity of a web based format for exchanging data cubes. This paper describes XCube, a family of XML schemas to precisely describe these online cubes. As the cubes are supposed to be transferred over the Internet and contain highly structured data, using XML ([1], [2]) seems reasonable. Before explaining the XCube standards in the next section a list of requirements to a format expressing online data cubes is introduced which can be easily derived from the scenarios presented above. 1. The format has to support a multidimensional data model. 2. The conceptual distinction between the description of schema, master or dimension data and transaction or fact data has to be supported. 3. The format has to be trans

ผลลัพธ์ (ไทย) 2:

ภาพรวมคร่าวๆมากกว่าการทำงานที่เกี่ยวข้องจะได้รับ ส่วนที่ 3 เริ่มต้นแนะนำครอบครัวของรูปแบบ Xcube นอกจากมาตรฐานขั้นพื้นฐานสำหรับการจัดเก็บมิติลำดับชั้นของการจัดหมวดหมู่และข้อเท็จจริงยังสูงมาตรฐานแบบไดนามิกจะจัดการกับที่อนุญาตให้มีการสร้างโครงสร้างพื้นฐานบริการขั้นพื้นฐาน มาตรา 5 ปิดด้วยแนวโน้มวิธี Xcube สามารถใช้ร่วมกับ Web Services และหมายเหตุประกอบบางอย่างเกี่ยวกับต้นแบบของเรา 2. การสร้างแรงจูงใจกรณีการใช้งานก่อนที่จะอธิบาย Xcube ส่วนนี้จะหมายถึงการวาดบางกรณีการใช้งานทั่วไปที่จะได้ประโยชน์จากวิธีการของเรา แรงผลักดันระหว่างทุกสถานการณ์ที่นำเสนอดังต่อไปนี้คือคลังข้อมูลมากมายที่มีอยู่มีจำนวนมากของข้อมูลที่มีค่าแผ่กระจายไปทั่วแผนกต่างๆของ บริษัท เดียวกันหรือแม้กระทั่งมากกว่า บริษัท ที่แตกต่าง การแลกเปลี่ยนข้อมูลระหว่างระบบที่แตกต่างเหล่านี้สามารถทำได้ง่ายมากถ้ามีรูปแบบที่ไม่ซ้ำกันสำหรับการอธิบายข้อมูลคลังข้อมูลในทางที่เป็นมาตรฐาน 2.1 "ดาวน์โหลด" กรณีใช้เว็บเซิร์ฟเวอร์มีก้อนคลังข้อมูลสำหรับการดาวน์โหลด (รูปที่ 1) คลังข้อมูลลูกค้าทุกคนที่สนใจในข้อมูลนี้สามารถดาวน์โหลดได้และบูรณาการลงในฐานข้อมูลท้องถิ่น แรกของทุกรายละเอียดของสคีหลายมิติของลูกบาศก์ที่มีการดาวน์โหลดในขั้นตอนที่สองข้อมูลหลักที่มีการแลกเปลี่ยนคือลำดับชั้นของการจำแนกประเภทของมิติเดียว ในที่สุดข้อมูลการทำธุรกรรมถูกส่งไปยังผู้ร้องขอและบูรณาการเข้าคลังข้อมูลท้องถิ่น บูรณาการในฝั่งไคลเอ็นต์เป็นเรื่องง่ายตราบเท่าที่การแสดงออกใด ๆ ในก้อนใหม่ไม่ได้มีความขัดแย้งกับบรรดาก้อนข้อมูลที่มีอยู่ ถ้าในมืออื่น ๆ เช่นมิติอยู่แล้วความสัมพันธ์ที่แน่นอนระหว่างทั้งสองจะต้องมีการตรวจสอบอย่างรอบคอบซึ่งนำไปสู่ปัญหาของการรวมความหมาย เครื่องมือที่น่าสนใจสำหรับการบูรณาการข้อมูลจากแหล่งข้อมูลต่าง ๆ อาจจะใช้มิติอ้างอิงมาตรฐาน 2.2 "แบบสอบถาม" กรณีใช้เป็นจำนวนข้อมูลของลูกบาศก์หลายมิติมักจะค่อนข้างใหญ่ (โดยเฉพาะอย่างยิ่งส่วนข้อมูลการทำธุรกรรม) ความเป็นไปได้ในการวิเคราะห์ก้อนข้อมูลออนไลน์เช่นบน (เว็บ) ฝั่งเซิร์ฟเวอร์เป็นที่พึงปรารถนาอย่างยิ่งที่จะลด การบริโภคของความจุเครือข่าย ในกรณีแบบสอบถามออนไลน์เท่านั้นคีมาและข้อมูลหลักมีให้ดาวน์โหลดจากเว็บเซิร์ฟเวอร์ได้อย่างสมบูรณ์ซึ่งมีขนาดเล็กโดยการเคาะ (ขั้นตอนที่ 1 และ 2 ในรูปที่ 2) มีคำอธิบายในมือนี้ใบสมัครลูกค้า (ไม่เพียง แต่คลังข้อมูล OLAP เครื่องมือเช่น) สามารถตัดสินใจที่ย่อยของก้อนข้อมูลที่ต้องการแล้วสามารถส่งแบบสอบถามตามไปยังเว็บเซิร์ฟเวอร์ (ขั้นตอนที่ 3) เซิร์ฟเวอร์แล้วคำนวณที่ต้องการ subcube ข้อมูลการทำธุรกรรมและส่งไปยังลูกค้า (ขั้นตอนที่ 4) หากใบสมัครของลูกค้าเป็นคลังข้อมูลที่ต้องการที่จะบูรณาการผลลงในฐานข้อมูลของตัวเองใช้กรณีนี้เป็นลักษณะทั่วไปของคดีดาวน์โหลดที่นำเสนอในส่วน 2.1.
สำหรับสถานการณ์แบบสอบถามมันเป็นสิ่งสำคัญที่จะคิดเกี่ยวกับกลยุทธ์การปรับปรุงสำหรับคีมาและ ข้อมูลหลักในฝั่งไคลเอ็นต์เพราะเมื่อลูกค้าที่ช่วยให้ข้อมูลนี้มาเป็นเวลานานก็จะกลายเป็นล้าสมัย ปัญหาของการแสดงออกที่ขัดแย้งกันจะต้องมีการปฏิบัติในลักษณะเดียวกับที่กล่าวมาข้างต้น.
2.3 "ผลิต" กรณีใช้กรณีที่ก่อให้เกิดเป็นเรื่องเกี่ยวกับวิธีการสร้างก้อนข้อมูลที่สามารถนำเสนอโดยเว็บเซิร์ฟเวอร์ ในข้อมูลหลักการของรูปแบบใด ๆ จากทุกชนิดของแหล่งข้อมูลที่สามารถแปลงเป็นก้อนหลายมิติ ขั้นตอนการแปลงเป็นเช่นเดียวกับเมื่อการบูรณาการแหล่งใหม่เข้าไปในโกดัง A: ข้อมูลที่มีจะได้รับการเวิร์กโฟลว์ ETL สมบูรณ์ กรณีที่น่าสนใจมากขึ้นคือการสร้างก้อนออนไลน์จากคลังข้อมูลที่มีอยู่ นี่คืองานที่บูรณาการที่มีราคาแพงจะทำอยู่แล้วและมันจะต้องมีการตัดสินใจที่ย่อยของข้อมูลที่จะได้รับการเผยแพร่ การเปลี่ยนแปลงของข้อมูลหลายมิติ (เป็นอิสระจากการจัดเก็บข้อมูลเชิงสัมพันธ์หรือหลายมิติ) เป็นเรื่องง่ายและสามารถทำได้โดยอัตโนมัติ สำหรับการดำเนินการกรณีนี้การเปิดตัวของข้อมูลมาร์ทโฮลดิ้งเพียงชุดย่อยของข้อมูลที่มีความหมายสำหรับไปออนไลน์อาจจะมีประโยชน์ อีกหนึ่งทางเลือกที่น่าสนใจการออกแบบสำหรับการดำเนินงานคือถ้าเปลี่ยนข้อมูลคลังสินค้าเป็นก้อนออนไลน์จะทำแบบคงที่หรือแบบไดนามิกตามความต้องการโดยชุดคำสั่งของ SQL 2.4 ความต้องการสำหรับการเป็นตัวแทน Online Data ก้อนช่วงสามส่วนย่อยให้ชุดของตัวอย่างที่สร้างแรงจูงใจความจำเป็นของรูปแบบเว็บที่ใช้สำหรับการแลกเปลี่ยนข้อมูลก้อน กระดาษนี้จะอธิบาย Xcube ครอบครัวของ XML schema ที่แม่นยำเพื่ออธิบายก้อนออนไลน์เหล่านี้ ในฐานะที่เป็นก้อนที่ควรจะถูกโอนผ่านทางอินเทอร์เน็ตและมีข้อมูลที่มีโครงสร้างสูงโดยใช้ XML ([1], [2]) ดูเหมือนว่าเหมาะสม ก่อนที่จะอธิบายมาตรฐาน Xcube ในส่วนถัดไปรายการของข้อกำหนดในการแสดงรูปแบบก้อนข้อมูลออนไลน์เป็นที่รู้จักซึ่งสามารถมาได้อย่างง่ายดายจากสถานการณ์ที่นำเสนอข้างต้น 1. รูปแบบที่ได้ให้การสนับสนุนรูปแบบข้อมูลหลายมิติ 2. ความแตกต่างทางความคิดระหว่างคำอธิบายของสคีต้นแบบหรือมิติข้อมูลและการทำธุรกรรมหรือความเป็นจริงข้อมูลที่ได้รับการสนับสนุน 3. รูปแบบจะต้องมีทรานส์