BzInsight

ลักษณะการ restatement แบบที่สองจะเป็นการเปลี่ยนแปลงที่เกี่ยวข้องกับข้อมูลอ้างอิง (reference data หรือ master data) โดยเฉพาะ

การเปลี่ยนแปลงในลักษณะนี้จะแตกต่างจาก Transaction Data Restatement ตรงที่ ข้อมูลธุรกรรมที่เกิดขึ้นในอดีตไม่ได้มีการเปลี่ยนแปลงไป การเปลี่ยนแปลงนั้นเกิดจากข้อมูลอ้างอิงโดยเฉพาะ ซึ่งอาจเกิดได้ในสองลักษณะคือการเปลี่ยนแปลงโครงสร้างลำดับชั้น และการเปลี่ยนคุณสมบัติบางประการที่ใช้ในการคำนวณค่าข้อมูลชนิดใหม่

ถึงแม้ว่าตัวข้อมูลธุรกรรมไม่มีการเปลี่ยนแปลง แต่การเปลี่ยนข้อมูลอ้างอิง ก็สามารถส่งผลให้ “เสมือน” ว่าข้อมูลในอดีตมีการเปลี่ยนแปลงไปได้เช่นกัน

• Hierarchy Change

Hierarchy หรือโครงสร้างลำดับขั้น เป็นหนึ่งในลักษณะที่สำคัญของข้อมูลอ้างอิง มีความสำคัญมากต่อการสรุปยอดข้อมูล หรือ aggregation โดยการกำหนดการจัดหมวดหมู่ของข้อมูลให้สอดคล้องกับ ความต้องการใช้งานในกลุ่มผู้ใช้แต่ละกลุ่ม ตัวอย่างเช่น ถ้าบริษัทของคุณมีลูกค้าซัก 1000 ราย และจัดแบ่งหมวดหมู่ตามโครงสร้างการบริหารของฝ่ายขาย ทีนี้สมมติบริษัทคุณแบ่งเขตการขายตามพื้นที่ที่อยู่ของลูกค้า คุณอาจจะมีผู้จัดการฝ่ายขาย 4 คน ประจำภาคเหนือ ใต้ กลาง และอีสาน แต่ละคนก็ดูแลลูกค้าที่มีที่อยู่อยู่ในภาคนั้นๆ ดังนั้น ระบบ business intelligence ที่ใช้รายงานยอดขาย ก็จะรวมยอดขายของลูกค้าแต่ละราย ตามเขตพื้นที่ที่ผู้จัดการฝ่ายขายแต่ละคนดูแลอยู่

ถ้าบริษัทมีการเปลี่ยนแปลงโครงสร้างการดูแลลูกค้า แทนที่จะเป็นตามเขตพื้นที่ แต่แบ่งเป็นตามลักษณะของลูกค้า เช่น ลูกค้าแบบองค์กร ลูกค้ารายย่อย และลูกค้าออนไลน์ โดยมีการจัดสรรผู้จัดการฝ่ายขายใหม่ ตามลักษณะการแบ่งกลุ่มลูกค้า คุณยังคงมีลูกค้า 1000 รายเท่าเดิม ธุรกรรมเดิมที่เคยทำกับลูกค้าเหล่านั้น ก็ไม่ได้มีการเปลี่ยนแปลงไปแต่อย่างใด สิ่งที่เปลี่ยนไป คือการจัดกลุ่มที่แตกต่างออกไป

โดยทั่วไปแล้ว เรามักจะต้องการมองข้อมูลในอดีต ผ่านโครงสร้างปัจจุบัน เช่น ลูกค้าแบบองค์กร ปีนี้ยอดขายเทียบกับปีที่แล้วเป็นอย่างไร ถึงแม้ว่าเมื่อปีที่แล้วกลุ่มลูกค้าเหล่านั้น ยังไม่ได้ถูกเรียกว่าลูกค้าแบบองค์กรก็ตาม ความสามารถแบบนี้เป็นความสามารถโดยทั่วไปของระบบฐานข้อมูลที่ถูก normalized มาแล้วระดับหนึ่ง แต่ในบางกรณี ก็มีความจำเป็นที่จะต้องรายงานและวิเคราะห์ข้อมูล ผ่าน hierarchy ในอดีตด้วยเช่นกัน ประมาณว่า ถ้าเราไม่ได้เปลี่ยนโครงสร้างการจัดหมวดหมู่ลูกค้า ยอดขายของกลุ่มลูกค้าในภาคเหนือจะเป็นอย่างไรในปีนี้ ซึ่งมักจะมีความต้องการในลักษณะนี้มาบ้าง แต่ก็ไม่บ่อยนัก

ระบบ data warehouse หรือ business intelligence ที่ออกแบบมาเพื่อรองรับลักษณะการใช้งานเหล่านี้ จะมีการเก็บประวัติการเปลี่ยนแปลงของ hierarchy ไว้ (หรือถ้าเอาให้ง่ายกว่านั้นหน่อย ก็ใช้วิธีสร้าง hierarchy ใหม่ไปเสียเลย) อาจจะย้อนหลังไปซัก 2-3 เวอร์ชั่น เพื่อให้สามารถตอบสนองการวิเคราะห์ข้อมูลแบบพิเศษนี้ได้

• Attribute Change

คุณลักษณะหรือ attribute ของข้อมูลอ้างอิง บ่อยครั้งอยู่เหมือนกันที่ส่งผลต่อการเปลี่ยนแปลงข้อมูลในอดีต โดยเฉพาะอย่างยิ่ง ข้อมูลที่ derived หรือผ่านการคำนวณมาแล้ว ตัวอย่างที่เห็นอยู่บ่อยๆ ก็คือ การใช้อัตราแลกเปลี่ยนเงิน มาคำนวณยอดขาย ในกรณีของบริษัทที่ใช้สกุลเงินมากกว่าหนึ่งสกุล หรือมีสาขาอยู่ในหลายประเทศ ข้อมูลธุรกรรมที่เกิดขึ้น มักจะถูกบันทึกตามสกุลเงินที่เกิดขึ้นจริงในท้องถิ่น ซึ่งก็เพียงพอต่อการใช้งานในประเทศ แต่เมื่อต้องส่งรายงานสรุปขึ้นไปให้บริษัทแม่ที่อยู่ต่างประเทศ ก็ต้องเลือกใช้เป็นสกุลเงินอื่น และต้องพิจารณาอัตราแลกเปลี่ยนที่เหมาะสมด้วย

ยอดขาย 100 ล้านบาทเท่ากัน อาจแสดงผลในรายงานแตกต่างกันในแต่ละปีได้ ถ้าใช้อัตราแลกเปลี่ยนที่แตกต่างกันของแต่ละปี

Reference data restatement ถือเป็นเรื่องปกติ และเป็นหนึ่งในข้อที่ควรพิจารณาเป็นอย่างยิ่งในการออกแบบคลังข้อมูลหรือระบบ business intelligence ใดๆ ข้อควรพิจารณาประกอบด้วย

• ถึงแม้จะเป็นเรื่องปกติที่มีการเปลี่ยนแปลง แต่ก็ควรทำการกำหนดให้ชัดเจนไปเลยว่า การเปลี่ยนแปลงข้อมูลอ้างอิงแต่ละแบบ จะมีขั้นตอนอย่างไรบ้าง ใครเริ่ม ใครอนุมัติ เปลี่ยนได้บ่อยแค่ไหน และสื่อสารข้อตกลงเหล่านี้ให้ผู้ใช้ระบบทราบ
• การอบรมผู้ใช้ก็มีความสำคัญมาก การจัดการกับการเปลี่ยนแปลงข้อมูลอ้างอิง และผลกระทบที่มีต่อรายงานหรือข้อมูลแต่ละชิ้น ควรจะเป็นหนึ่งในหัวข้อการฝึกอบรมพื้นฐานก่อนเริ่มใช้งานระบบ ผู้ใช้จะต้องรู้ว่าพวกเขากำลังมองข้อมูลแบบไหนอยู่
• ความซับซ้อนของการเปลี่ยนแปลงจะเพิ่มมากขึ้น เมื่อพิจารณารวมทั้งระบบ อย่าลืมคำนึงถึง “เวลา” ที่ใช้ในการประมวลผลเพื่อ restatement ด้วย เพราะในคลังข้อมูลขนาดใหญ่ ที่มีข้อมูลปริมาณมากๆ การประมวลผลข้อมูลใหม่ทั้งหมด ไม่ใช่เรื่องสนุก แต่ละครั้งอาจจะต้องใช้เวลาหลายชั่วโมง หรือเป็นวัน

โดยหลักการทั่วไปแล้ว ข้อมูลในคลังข้อมูลหรือ data warehouse จะมีลักษณะ non-volatile คือ ไม่มีการเปลี่ยนแปลงไปตามเวลา พอข้อมูลเข้าสู่คลังแล้ว มักจะอยู่ในรูปแบบอย่างนั้นไปตลอด แต่พอเอาเข้าจริง ก็มักจะพบกับความต้องการที่จะเปลี่ยนแปลงข้อมูลในคลังข้อมูลอยู่เสมอ เรียกกันว่า Data Restatement

Data Restatement ที่ผมประสบพบเจออยู่บ่อยๆ มีสองแบบ อย่างแรกเลยคือ transaction restatement ประเภทที่สองเรียกว่า reference data restatement ทั้งสองแบบนี้มีวัตถุประสงค์ที่แตกต่างกัน และต้องการการจัดการที่แตกต่างกันด้วย

Transaction Restatement

เป็นการเปลี่ยนแปลงข้อมูลธุรกรรมที่เกิดขึ้นในอดีต สมมติอย่างเช่น มีข้อมูลยอดขายสินค้า A ไปยังลูกค้า ก. ประจำวันที่ 1 ตุลาคม 52 ข้อมูลแรกสุดที่เข้ามาเก็บในคลังข้อมูลบันทึกได้ว่ายอดขายเป็น 100 บาท ตัวเลข 100 บาทนี้ได้ถูกนำไปเผยแพร่ หรือ publish รวมเข้ากับยอดขายสินค้าอื่นๆ ผู้บริหารอาจจะได้ทำการตัดสินใจอะไรบางอย่างไปเรียบร้อยแล้วเกี่ยวกับข้อมูลตัวนี้ (เช่น สั่งเพิ่มปริมาณการผลิตสินค้า A หรือ สั่งให้ส่วนลดพิเศษลูกค้า ก. ไปเรียบร้อยแล้ว) แต่แล้ว ภายหลังพบว่า ข้อมูลยอดขายที่แท้จริงเป็นแค่ 50 บาท จะเกิดอะไรขึ้น? และระบบคลังข้อมูลหรือระบบ business intelligence ควรจะตอบสนองกับกรณีเช่นนี้อย่างไร?

ประเด็นแรกที่ต้องพิจารณา ก็คือ ลักษณะ transaction restatement ควรจะถูกพิจารณาเป็นกรณียกเว้นพิเศษ เพราะถือเป็นการเปลี่ยนแปลงแก้ไขประวัติศาสตร์ โดยเฉพาะอย่างยิ่ง ถ้าเป็นเรื่องที่เกี่ยวข้องกับเงินๆ ทองๆ หรือเกี่ยวข้องกับผลการประกอบการของบริษัท การยอมให้เกิด transaction restatement โดยไม่มีกระบวนการควบคุมที่ดี อาจมีใครบางคนโดน audit เรียกไปคุย หรือแย่ยิ่งกว่านั้น อาจจะต้องถือว่ามีโทษทางกฎหมายด้วยเลยทีเดียว

ดังนั้นแล้วกระบวนการ transaction restatement ต้องได้รับการอนุมัติเป็นกรณีพิเศษ จากผู้บริหารที่สามารถรับผิดชอบผลทางกฎหมายที่จะตามมาจากการแก้ไขข้อมูลได้

สิ่งที่เราพอจะช่วยได้ ก็คือการออกแบบโครงสร้างข้อมูลใน data warehouse ให้รัดกุม ครอบคุลมกระบวนการทางธุรกิจทั้งหลายทั้งปวง อันเป็นที่มาของการแก้ไข transaction ในอดีต รวมไปถึงการทำงานร่วมกับระบบงานอื่นๆ เช่น SCM หรือ ERP เพื่อสร้างระบบควบคุมที่เหมาะสมด้วยเช่นกัน ตัวอย่างเช่น ลงวิเคราะห์กันดูว่า เพราะสาเหตุใดที่ทำให้ยอดขายซึ่งเคยเป็น 100 บาท เปลี่ยนเป็นแค่ 50 บาทได้? เราอาจจะพบว่า เกิดจากพนักงานคีย์ราคาผิด (ควบคุมผ่าน ERP) หรือคีย์จำนวนสินค้าผิด (ควบคุมผ่านกระบวนการส่งของ) หรืออาจจะเกิดจากการที่สินค้าจัดส่งไปแล้ว แต่ลูกค้าคืนสินค้ากลับมาครึ่งหนึง (แก้ไขโดยการออกแบบฐานข้อมูลที่รองรับการคืนสินค้า) เป็นต้น

เอาไว้คราวหน้ามาคุยให้ฟังเรื่อง reference data restatement ต่อแล้วกันครับ

Teradata โชว์ต้นแบบการนำ SSD หรือ Solid-State Disk มาใช้ในงาน data warehouse เพื่อเพิ่มความเร็วในการอ่านข้อมูลได้สูงขึ้นถึงสองเท่า ลดโอกาสที่จะเกิดความผิดพลาดของ I/O เพราะไม่มีชิ้นส่วนกลไกที่ต้องเคลื่อนไหว และยังใช้พลังงานน้อยกว่าเทคโนโลยีฮาร์ดดิสก์แบบเดิมถึงครึ่งหนึ่ง

ได้มีการคาดการณ์ว่า SSD จะเข้ามามีบทบาทสำคัญในการใช้งานเชิงธุรกิจ (หลังจากที่เริ่มบุกตลาด consumer ผ่านทาง netbook มาแล้ว) ในปี 2011 แต่ทาง Teradata คาดว่าจะพร้อมนำ SSD มาใช้ใน Data warehouse appliance ในภายในปี 2009 ที่จะถึงนี้ ขึ้นอยู่กับราคาและประสิทธิภาพในตลาดของเทคโนโลยี SSD

อย่างไรก็ดี Teradata ก็ไม่ได้ทิ้งเทคโนโลยีฮาร์ดดิสก์เสียทีเดียว ระบบสถาปัตยกรรม Teradata Virtual Storage จะช่วยให้ลูกค้าสามารถเลือกใช้เทคโนโลยีการเก็บข้อมูลที่เหมาะสมกับความต้องการได้ ไม่ว่าจะเป็นฮาร์ดดิสก์ล้วน SSD ล้วน หรือจะผสมกันก็ได้ โดยหากเป็นระบบผสม จะสามารถกำหนดให้ข้อมูลที่ต้องการใช้บ่อยหรือ hot data ถูกเก็บไว้ใน SSD และข้อมูลอื่นที่ใช้น้อยกว่าเก็บไว้ในฮาร์ดดิสก์

ที่มา : Teradata Labs Unveils Innovative Data Warehouse Concept ผ่านทาง Teradata Partners - Spinning Solid State Disks

Data Warehouse หรือระบบคลังข้อมูล ถือเป็นองค์ประกอบที่สำคัญมากๆ ในงาน Business Intelligence ถึงแม้โดยพื้นฐานแล้ว data warehouse ก็ถือเป็น database หรือฐานข้อมูลประเภทหนึ่งเหมือนกัน แต่เนื่องจากวัตถุประสงค์ของการใช้งานแตกต่างออกไป ทำให้มีลักษณะสำคัญหลายอย่าง ที่แตกต่างจากระบบฐานข้อมูลที่ใช้ในการดำเนินธุรกรรมทางธุรกิจโดยทั่วไป

วัตถุประสงค์หลักของระบบคลังข้อมูล คือ “ช่วยสนับสนุนการตัดสิืนใจ“ ซึ่งแตกต่างจากวัตถุประสงค์ของระบบฐานข้อมูลในระบบงานคอมพิวเตอร์พื้นฐาน ที่มีเป้าหมายเพื่อเพิ่มประสิทธิภาพในการปฎิบัติงานอย่างใดอย่างหนึ่ง

ลักษณะสำคัญของ Data Warehouse ประกอบด้วย

• Integrated ระบบคลังข้อมูลจะเป็นการรวบรวมข้อมูลการดำเนินธุรกรรมจากหลายๆ แหล่งเข้ามาไว้ภายใต้โครงสร้างเดียวกัน ในขณะที่ฐานข้อมูลในระบบคอมพิวเตอร์โดยทั่วไป มักจะถูกออกแบบมาให้มีประสิทธิภาพสูงสุดในการดำเนินกิจกรรมอย่างใดอย่างหนึ่ง เช่น ระบบบัญชี ก็เน้นประสิทธิภาพสูงสุดในการบันทึกบัญชี ระบบงานขาย หรือระบบวางแผนการผลิตก็เช่นเดียวกัน และบ่อยครั้งที่ในบริษัทเดียวกัน มีการเลือกใช้ระบบงานแตกต่างกัน เช่นใช้ระบบบัญชีของ SAP แต่ใช้ระบบ CRM ของ Siebel เป็นต้น Data Warehouse จะทำหน้าที่ผสานรวมข้อมูลของสองระบบนี้เข้าไว้ด้วยกัน
• Subject-Oriented ลักษณะโครงสร้างของ DW จะจัดหมวดหมู่ตาม “เนื้อหา” ในขณะที่ฐานข้อมูลในระบบงาน OLTP (Online Transaction Processing) จะจัดหมวดหมู่ตาม “กระบวนการทำงาน” (Process-oriented) ตัวอย่างเช่น คลังข้อมูลที่มีข้อมูลการขาย แต่เกิดจากการรวบรวมข้อมูลจากระบบงานที่มีหลายขั้นตอน ตั้งแต่การรับออร์เดอร์ การตรวจสอบเครดิตลูกค้า การตรวจสอบสต็อกสินค้า การจัดเตรียมสินค้า พิมพ์อินวอยซ์ จัดส่ง วางบิล เก็บเงิน รับสินค้าคืนในกรณีที่เสียหายหรือผิดพลาด รวมไปจนถึงการบันทึกบัญชีลูกหนี้ เป็นต้น จะเห็นได้ว่าในหนึ่งเรื่องแค่การขายอย่างเดียว มีกระบวนการที่เกี่ยวข้องด้วยมากมาย แต่เนื้อหายังคงอยู่ในหมวดการขายทั้งสิ้น
• Non-Volatile ข้อมูลที่จะถูกจัดเก็บในคล้งข้อมูล จะมีลักษณะที่ “ไม่เปลี่ยนแปลง” หรือถ้าจะมีการเปลี่ยนแปลงบ้างก็น้อยมาก จนเรียกได้ว่าเป็นกรณียกเว้นเลยทีเดียว เมื่อข้อมูลถูกนำเข้าไปใส่ไว้ในระบบ data warehouse แล้ว การใช้งานโดยส่วนใหญ่ มากกว่า 99% จะเป็นการ “อ่าน” ข้อมูลเพื่อใช้ในการวิเคราะห์และสนับสนุนการตัดสินใจในรูปแบบต่างๆ น้อยมากที่ข้อมูลในคลังข้อมูลจะต้องทำการ “แก้ไข หรือเปลี่ยนแปลง”  แต่ถ้าเปรียบเทียบกับระบบปฎิบัติงานทั่วไปแบบ OLTP อาทิเช่นระบบรับคำสั่งซื้อ หรือระบบบริการลูกค้าทาง call center ข้อมูลใบสั่งซื้อหรือข้อมูลการติดต่อกับลูกค้าแต่ละรายการ จะถูกเปลี่ยนแปลงไปอยู่ตลอดเวลา เพื่อให้สามารถสะท้อนถึงสถานะปัจจุบันของกิจกรรมนั้นๆ ได้ในลักษณะ realtime เช่น คำสั่งซื้อนี้อยู่ในขั้นตอนการตรวจสอบเครดิต ณ เวลานี้ แต่ในอีก 2 นาทีข้างหน้าจะถูกเปลี่ยนสถานะเป็น จัดเตรียมสินค้า เป็นต้น
• Time-Variant โดยมากการตัดสินใจทางธุรกิจ จะต้องใช้ข้อมูลของสิ่งที่เกิดขึ้นในอดีตมาเป็นฐานประกอบการตัดสินใจ ดังนั้นระบบคลังข้อมูลจึงเน้นความสำคัญที่ “การจัดเก็บข้อมูลตามห้วงเวลา” หรือการเก็บรายละเิอียดข้อมูลในอดีตไว้เป็นจำนวนมาก ตัวอย่างเช่น ข้อมูลยอดขายของสินค้ารายการหนึ่ง อาจจะถูกเก็บใน data warehouse ย้อนหลังไป 3 ปี 5 ปี หรืออาจจะตั้งแต่เริ่มจำหน่ายสินค้านั้นเลยก็เป็นได้ เพื่อใ้ห้สามารถวิเคราะห์ถึงแนวโน้มในอดีต และพยากรณ์แนวโน้มในอนาคตต่อไปได้ แต่ถ้าเปรียบเทียบกับระบบสั่งซื้อสินค้า ซึ่งมีวัตถุประสงค์หลักคือเพื่อรับคำสั่งซื้อ ดังนั้นข้อมูลประวัติยอดขายในอดีต จึงมีความสำคัญไม่มากนัก โดยส่วนใหญ่แล้ว มักจะเก็บข้อมูลไว้เพียงแค่ 1-2 รอบทำการ (อาจจะวันหรือเป็นเดือนก็ได้) เมื่อมีการประมวลผลสิ้นวันหรือสิ้นเดือนแล้ว ก็จะทำการ purge ข้อมูลเก่าทิ้งไป เพื่อให้ระบบมีึความคล่องตัว และสามารถประมวลผลคำสั่งซื้อใหม่ๆ ได้อย่างรวดเร็ว

ด้วยลักษณะดังกล่าว ทำให้โดยทั่วไปแล้ว data warehouse มักจะมีขนาดใหญ่ ยิ่งหน่วยงานธุรกิจมีขนาดใหญ่ กระบวนการทำงานซับซ้อน ข้อมูลหลากหลาย ขนาดของ DW ในองค์กรก็จะใหญ่และซับซ้อนตามไปด้วย อย่างไรก็ตาม “ขนาด” ไม่ได้เป็นลักษณะสำคัญโดยเฉพาะ ฐานข้อมูล OLTP ก็สามารถมีขนาดใหญ่ได้ โดยไม่จำเป็นต้องเป็น data warehouse

คราวที่แล้วเอาสไลด์ชุด Data Warehouse 101 มาฝาก วันนี้เป็นบทที่สองจากหนังสือเล่มเดิมนั่นแหละครับ ที่จริงก็ทำไว้แค่สองบทเท่านั้นเอง เป็นการปูพื้น บทที่สองนี้มีชื่อเรียกโดยเฉพาะว่า Business Dimensional Life Cycle เป็นกระบวนการจัดการโครงการที่ทาง The Kimball Group คิดขึ้นมา  มาจนถึงปัจจุบัน วิธีการนี้ก็ไม่ได้แปลกใหม่อะไรเลย แต่ผมคิดว่ายังมีประโยชน์สำหรับคนที่เริ่มทำงานเกี่ยวกับ data warehouse project เป็นครั้งแรก เพราะทำให้มองเห็นภาพได้ชัดเจนว่า โดยรวมๆ แล้ว มีอะไรที่จำเป็นต้องทำบ้าง

หลายปีก่อน ตอนที่เริ่มสร้างทีมงานใหม่ๆ เพื่อทำงานด้านคลังข้อมูล (data warehouse) ผมจัดสอนภายในเลยเตรียม powerpoint ชุดนี้เอาไว้ เพิ่งไปรื้อ backup เก่าๆ มาเลยเอามาฝากกัน

สไลด์ชุดนี้ผมสรุปมาจากบทแรกของหนังสือ The Data Warehouse Lifecyle Toolkit : Expert Methods for Designing, Developing, and Deploying Data Warehouses ของ Ralph Kimball ซึ่งคาดว่าน่าจะเป็นประโยชน์สำหรับคนที่สนใจในด้าน data warehouse

ในบทแรกนี่จะกล่าวถึงองค์ประกอบสำคัญๆ ของระบบคลังข้อมูล รวมถึงโปรเซสหลักๆ ที่มีในระบบด้วย โดยจะเน้นไปที่นิยามหรือคำอธิบายพื้นฐานถึงองค์ประกอบและโปรเซสเหล่านั้น เป็นการปูพื้นล่วงหน้า

เทคโนโลยีหลักในส่วนของการจัดเก็บข้อมูลสำหรับงาน business intelligence คือคลังข้อมูล หรือ Data Warehouse ซึ่งโดยกว้างๆ แล้วก็คือฐานข้อมูลขนาดใหญ่ ที่เก็บรวบรวมข้อมูลไว้ในลักษณะที่เอื้อต่อการนำข้อมูลไปใช้ในสนับสนุนการตัดสินใจ

ลักษณะสำคัญที่ทำให้ data warehouse แตกต่างจากระบบฐานข้อมูล rdbms ที่เราใช้กันอยู่ในระบบ transaction system ทั่วไปประกอบด้วย

• การจัดเก็บข้อมูลแบบ subject-oriented ใน data warehouse จะจัดเก็บข้อมูลตาม “เรื่อง” ที่จะใช้ในการตัดสินใจ ในขณะที่ฐานข้อมูลทั่วไป จะเก็บข้อมูลตามลักษณะธุรกรรม หรือ transaction หลักของระบบงานนั้นๆ
• ผสานข้อมูลจากหลายแหล่ง เนื่องจากต้องการตอบสนองการ ตัดสินใจ ซึ่งมักต้องใช้ข้อมูลมากกว่าหนึ่งชนิด ดังนั้น DW จึงจำเป็นต้องมีความสามารถในการ integrate ข้อมูลจากหลายๆ แห่งเข้าด้วยกัน แต่ระบบฐานข้อมูลอื่นจะรับข้อมูลจากส่วน input ของระบบงานเท่านั้น
• เก็บข้อมูลในอดีตไว้ด้วย ใน DW จะเก็บข้อมูลแบบที่เรียกว่า time-variant คือมีเวลาเป็นตัวแปรสำคัญอย่างหนึ่งเสมอ ดังนั้นช่วงเวลาของข้อมูลในคลังข้อมูลจึงยาวนานเป็นปีๆ หรืออาจจะถึงสิบปี เพื่อการวิเคราะห์แนวโน้มในอดีต ส่วนฐานข้อมูลทั่วไปจะเก็บ “สถานะ” ล่าสุดไว้เท่านั้น หรือถ้าจะเก็บก็เพียงแค่ วันที่ปัจจุบัน หรือเดือนปัจจุบันเท่านั้น
• ข้อมูลมีการเปลี่ยนแปลงน้อย ข้อมูลที่ถูก เก็บไว้ใน DW มักจะมีการเปลี่ยนแปลงเพียงเล็กน้อยเท่านั้น โดยมากมักเป็นการเพิ่มข้อมูลใหม่เข้าไปมากกว่า แต่ในส่วนของฐานข้อมูลระบบงาน ข้อมูลจะเกิดการเปลี่ยนแปลงอยู่เสมอ ทั้งเพิ่ม ลบ หรือแก้ไข เพื่อให้สะท้อนสภาพความเป็นจริงในปัจจุบัน

Data warehouse จัดเป็นองค์ประกอบสำคัญอย่างยิ่ง แต่โดยตัวของมันเอง ก็มีรายละเอียด เทคโนโลยีและเรื่องราวต่างๆ ที่เกี่ยวข้องอีกเป็นจำนวนมาก จนบางครั้งเราอาจจะมองว่า DW อาจจะแยกออกไปเป็นอีกสาขาหนึ่งโดยเฉพาะได้เลยทีเดียว