Data Warehouse : Dimensional Modeling Prime

admin
on June 15, 2009
Comments
- Data warehouse

Chaprter 1 : Dimensional Modeling Primer

Different Information Worlds

– ส่วนใหญ่ information ที่ถูกเก็บโดยองค์กรต่างๆ จะถูกเก็บเอาไว้อยู่ใน 2 รูปแบบ : operational system of record(ที่ๆเราเอา data เก็บไว้), data warehouse(ที่ๆ เราเอา data ออกมา)
– ผู้ใช้ของ operational system จะทำให้การดำเนินงานขององค์กรดำเนินงานไป โดยพวกเค้าจะทำการสั่งสินค้า, รับสมัครลูกค้าใหม่ และ log complaints ซึ่งส่วนใหญ่พวกเค้าจะทำงานกับ 1 record ในช่วงเวลานั้น
– ผู้ใช้ data warehouse จะทำหน้าที่ในการสังเกตการดำเนินการขององค์กร พวกเค้าจะนับจำนวนคำสั่งใหม่และทำการเปรียบเทียบกับคำสั่งของเดิม และถามถึงว่าทำไมถึงมีลูกค้าเพิ่มเข้ามาใหม่และเรื่องที่ลูกค้ามีการติเตียน ส่วนใหญ่พวกเค้าจะไม่ค่อยทำงานกับเพียง row เดียวแต่คำถามของพวกเค้าต้องการเป็นร้อยหรือเป็นพัน row เพื่อทำการค้นหาและทำให้ได้เซตของคำตอบ

Goals of a Data Warehouse

– Data Warehouse จะทำให้การเข้าถึงข้อมูลขององค์กรง่ายขึ้น : เครื่องมือที่ใช้เข้าถึง Data Warehouse จะต้อง simple และง่ายในการใช้งาน โดยจะต้องแสดงผลการ query ให้กับผู้ใช้ในเวลาที่น้อยที่สุด
– Data Warehouse จะต้องแสดงถึงข้อมูลขององค์กรอย่าง consistenlty : ข้อมูลใน Data Warehouse จะต้องมีความเป็นไปได้ โดยจะต้องมีการรวบรวมข้อมูลอย่างรอบคอบจากแหล่งข้อมูลหลายๆแหล่งภายในองค์กร จะต้องมีการรับประกันคุณภาพ และปล่อยข้อมูลออกมาเฉพาะส่วนที่ลูกค้าต้องการ
– Data Warehouse จะต้องมีการ adaptive และ resilient to change : เราไม่สามารถหลีกเลี่ยงการเปลี่ยนแปลงได้ ความต้องการของผู้ใช้, เงื่อนไขทางธุรกิจ, ข้อมูล และเทคโนโลยี เป็นส่วนที่ทำให้เกิดการเปลี่ยนแปลงได้ตลอดเวลา Data Warehouse จะต้องถูกออกแบบมาให้รับมือกับการเปลี่ยนแปลงเหล่านี้
– Data Warehouse จะต้อง secure bastion เพื่อเป็นการปกป้องข้อมูล : warehouse เปรียบเหมือนกับเป็นที่เก็บข้อมูลว่าเรากำลังจะขายของให้กับใครในราคาเท่าใด ซึ่งจะเกิดความเสียหายเป็นอย่างมากถ้าข้อมูลตกไปอยู่ในมือของคนอื่น ดังนั้น Data Warehouse จะต้องมีประสิทธิภาพในการควบคุมการเข้าถึงข้อมูลที่สำคัญขององค์กร
– Data Warehouse จะต้องใช้เหมือนเป็นพื้นฐานสำหรับการตัดสินใจที่ดีขึ้น : Data Warehouse จะต้องมีข้อมูลที่ถูกต้องในการสนับสนุนการตัดสินใจ การตัดสินใจจะส่งผลกระทบต่อธุรกิจและค่าที่เกี่ยวข้องกับ warehouse (Decision support system)
– กลุ่มธุรกิจจะต้องยอมรับ Data Warehouse ถ้ามัน deemed successful : ถ้ากลุ่มธุรกิจไม่เปิดรับ Data Warehouse และทำการใช้มันภายใน 6 เดือนแล้วเราก็จะผิดหวังกับการทดสอบที่ได้รับ

The Publishing Metaphor

– เป้าหมายของ metaphor คือ การวางโครงร่างขนานระหว่าง การเป็น conventional publisher กับ การเป็น data warehouse manager
– คำอธิบายหน้าที่ที่ถูกต้องของ data warehouse manager คือ “publisher of the right data”
– ในการขับเคลื่อนโดยความต้องการทางธุรกิจ data warehouse manager ต้องทำหน้าที่ในการ publish ข้อมูลที่ถูกรวบรวมจากหลายๆ แหล่งข้อมูล และถูกแก้ไขเพื่อให้เกิดคุณภาพและ consistency ซึ่งหน้าที่หลักของ data warehouse manager ก็คือ ให้ข้อมูลกับ business user
– Publishing metaphor เน้นไปยังความต้องการที่ถูกระบุจากลูกค้าโดยตรงแทนที่จะเป็นจากสินค้าหรือกระบวณการ

Components of a Data Warehouse

1. Operational Source Systems
– Operational Source Systems คือ ระบบคำสั่งของ record ที่จับ transaction ของธุรกิจ
– ความสำคัญหลักของsource system คือกระบวณการที่มีประสิทธิภาพและการเข้าถึงได้ง่าย ความแตกต่างของ queries กับ source system ค่อนข้างน้อย โดย การดึงข้อมูลในช่วงเวลาหนึ่งเป็นส่วนหนึ่งของการไหลของ transaction พื้นฐาน และถูกจำกับอย่างรุนแรงภายใต้คำสั่งของ operational system
– source system ดูแลข้อมูลบางส่วนของ historical และถ้าคุณต้องการมี data warehouse ที่ดี source systemต้องสามารถ relieved กับหน้าที่มากมายในการ representing ข้อมูลในอดีต
– แต่ละ source system เป็น natural stovepipe application ที่การลงทุนขนาดย่อมสามารถทำการแชร์ข้อมูลพื้นฐาน เช่น สินค้า, ลูกค้า, สถานที่ หรือปฏิทิน กับ operational systems อื่นภายในองค์กร

2. Data Staging Area
– Data Staging Area ของ data warehouse เป็นทั้ง ส่วนที่ใช้จัดเก็บ และ เซตของกระบวณการพื้นฐาน โดยอ้างเป็น extract-transformation-load (ETL)
– Data Staging Area เป็นทุกๆอย่างระหว่าง operational source system และ data presentation area
– The key architectural requirement for the data staging area is that it is off-limits to
business users and does not provide query and presentation services.
– Extraction เป็นขั้นแรกในการเข้าถึงข้อมูลในคลังข้อมูล โดย Extraction หมายถึงการอ่าน และการเข้าใจถึงแหล่งข้อมูล รวมไปถึงการทำสำเนาข้อมูลที่ต้องการสำหรับคลังข้อมูลในส่วนของ staging area เพื่อการจัดการในอนาคต
– เมื่อข้อมูลถูกแตกออกใน staging area จะมีการเปลี่ยนแปลงที่สำคัญมากมายเช่น การทำข้อมูลให้สมบูรณ์, การรวมข้อมูลจากหลายแหล่ง, การกำหนด warehouse key โดยการเปลี่ยนแปลงเหล่านี้จะเป็นขั้นเริ่มต้นในการนำข้อมูลเข้าสู่ data warehouse presentation area
– จะต้องมีการทำ normalized structures ก่อนที่จะส่งไปยัง presentation area ในส่วนของ querying และ reporting ซึ่งในบางครั้งเราจะเรียกว่า enterprise data warehouse ซึ่งเป็น กลุ่มของ diverse data warehouse components
– It is acceptable to create a normalized database to support the staging processes;
however, this is not the end goal. The normalized structures must be off-limits to
user queries because they defeat understandability and performance. As soon as a
database supports query and presentation services, it must be considered part of the
data warehouse presentation area. By default, normalized databases are excluded
from the presentation area, which should be strictly dimensionally structured.
– ขั้นตอนสุดท้ายของ ETL process คือการโหลดข้อมูล การโหลดข้อมูลเข้าสู่คลังข้อมูลจะต้องอยู่ในรูปแบบของ presenting the quality-assured dimensional tables สู่การโหลด facilities ขนาดใหญ่ของแต่ละ data mart
– เป้าหมายของ data mart คือจะต้องจัด index ของข้อมูลที่เข้ามาใหม่เพื่อประสิทธิภาพในการดึงข้อมูล เมื่อ data mart มีการโหลดเสร็จ, ทำ index, มีผลรวมที่เหมาะสม และมีการรับประกันคุณภาพ กลุ่มของผู้ใช้จะได้รับการแจ้งว่าข้อมูลใหม่ได้มีการ publish แล้ว
– Publishing รวมถึงการสื่อสารเพื่อการเปลี่ยนแปลงที่อาจเกิดขึ้นเมื่อมีความต้องการใหม่

3. Data Presentation
– Data Presentation area เป็นที่ๆ ข้อมูลจะถูกจัดการ, จัดเก็บ และถูกทำให้สามารถเข้าถึงได้ง่ายสำหรับการดึงข้อมูลโดยตรงจากผู้ใช้ คนเขียนรายงาน หรือแอพพลิเคชั่นที่ใช้ในการวิเคราะห์
– เรามักจะอ้างว่า presentation area เป็นลำดับของการรวม data mart ซึ่ง data mart คือ ส่วนประกอบใหญ่ใน presentation area ทั้งหมด มันจะแสดงข้อมูลจากกระบวณการทางธุรกิจแบบเดี่ยว
– ข้อมูลจะถูกแสดง, จัีดเก็บ และเข้าถึงใน dimensional schemas โดยในกลุ่มธุรกิจจะสรุปว่า dimensional modeling คือ เทคนิคที่สามารถใช้งานได้สำหรับการส่งข้อมูลไปยังผู้ใช้ data warehouse
– Dimensional modeling เป็นชื่อใหม่ของเทคนิคเดิมที่ใช้ในการทำให้ฐานข้อมูลมีความไม่ซับซ้อนและ เข้าใจได้ โดยมันค่อนข้างจะต่างจาก third-normal-form (3NF) modeling โดย 3NF คือเทคนิคในการออกแบบที่ทำการค้นหาเพื่อทำการลบข้อมูลที่ซ้ำซ้อน ข้อมูลจะถูกแบ่งออกเป็นหลายๆ entities แต่ละ entities กลายเป็น table ใน relational database
– Normalizes modeling ช่วยทำให้ operational processing มีประสิทธิภาพมากขึ้น เนื่องจากการอัพเดตหรือ insert transaction ต้องการเข้าถึง database เพียงส่วนเดียว แต่อย่างไรก็ตาม Normalized models ก็ยังซับซ้่อนเดินไปสำหรับการดึงข้อมูลของ data warehouse รวมไปถึงการใช้ normalized modeling ใน data warehouse จะเป็นการทำลายเป้าหมายทั้งหมดของการทำ data warehouse ด้วย
– dimensional model ประกอบด้วย ข้อมูลที่เหมือนกันเหมือน normalized modeling แต่จัดเก็บข้อมูลในรูปแบบที่ถูกออกแบบมาให้ผู้ใช้สามารถเข้าใจได้, เพื่อประสิทธิภาพในการดึงข้อมูล และรองรับการเปลี่ยนแปลง
– Data in the queryable presentation area of the data warehouse must be dimensional, must be atomic, and must adhere to the data warehouse bus architecture.

4. Data Access Tools
– All data access tools query the data in the data warehouse’s presentation area.

Additional Considerations
– Metadata : เป็นข้อมูลทั้งหมดใน data warehouse ซึ่ง Metadata เป็นเหมือนสารานุกรมสำกรับ data warehouse
– Operational Data Store : ODS ถูกใช้ในการส่ง operational reporting โดยเฉพาะเมื่อไม่มีสิ่งที่ได้รับสืบมาหรือไม่มี on-line transaction processing (OLTP) ใหม่ ในอีกกรณี ODS จะถูกสร้างขึ้นเพื่อทำการสนับสนุนการโต้ตอบแบบ real-time โดยเฉพาะใน customer relationship management (CRM) application มีการนิยาม ODS ว่าเป็นส่วนนึงของ data warehouse ที่เราเก็บ granular atomix data

Dimensional Modeling Vocabulary

1. Fact Table
– Fact table เป็นตารางพื้นฐานของ dimensional model ซึ่งเป็นที่เก็บผลของการวัดประสิทธิภาพ
– A row in a fact table corresponds to a measurement. A measurement is a row in a
fact table. All the measurements in a fact table must be at the same grain
– The most useful facts in a fact table are numeric and additive.
– A textual measurement is a description of something and is drawn from a discrete list of values.
– all fact table grains fall into one of three categories: transaction, periodic snapshot, and accumulating snapshot.
– Fact tables express the many-to-many relationships between dimensions in dimensional models.

2. Dimension Tables
– Dimension tables มีการเชื่อมโยงอย่างสมบูรณ์กับ Fact Table ซึ่งประกอบด้วยรายละเอียดเกี่ยวกับธุรกิจ โดยในการออกแบบที่ดีของ dimension model นั้น Dimension tables มี หลาย column และ attributes ซึ่้ง attributes จะอธิบาย row ที่อย่ใน dimension table นั้น
– แต่ละ dimension ถูกำหนดโดย primary key ของมันเอง และถูกำหนดโดย PK notation ที่เป็นตัวชี้พื้นฐานสำหรับ referential integrity
– Dimension table attributes มีืบทบาทที่สำคัญใน data warehouse ตั้งแต่ที่มันเป็นแหล่งของข้อจำกัดและreport labels ที่น่าสนใจ มันเป็นตัวที่ทำให้ data warehouse ใช้งานง่ายและเข้าใจได้
– Dimension tables are the entry points into the fact table. Robust dimension attributes deliver robust analytic slicing and dicing capabilities. The dimensions implement the user interface to the data warehouse.

3. Bringing Together Facts and Dimensions
– fact table ประกอบด้วยค่าจากการวัดที่ถูกนำมารวมกันโดยมี dimension
tables มาอธิบายข้อมูลใน fact table โดยลักษณะของโครงสร้างจะเรียกว่า “star join schema”

Dimensional Modeling Myths : Misperceptions of dimensional modeling (Myth = เรื่องหลอกลวง)

Myth 1. Dimensional models and data marts are for summary data only.
– Myth 1 นี้เป็นสาเหตุหลักในการออกแบบ dimension models แบบผิดๆ เนื่องจากว่าเราไม่สามารถที่จะทำนายคำถามทั้งหมดที่จะถูกผู้ใช้ถามได้ เราต้องการที่จะให้ข้อมูลและรายละเอียดมากที่สุดที่สามารถดึงข้อมูลมาได้ ดังนั้นผู้ใช้จึงสามารถเข้าถึงข้อมูลได้เฉพาะส่วนที่ขึ้นกับคำถามในช่วงเวลา นั้น
– ผลที่ตามมาจาก Myth 1 คือจะมีจำนวนของ historical data ที่จำกัดที่ถูกเก็บอยู่ใน dimensional structure

Myth 2. Dimensional models and data marts are departmental, not enterprise, solutions

Myth 3. Dimensional models and data marts are not scalable
– ผลทีตามมาจาก Myth 3 คือ dimensional models จะเหมาะสำหรับพวกการขายเท่านั้น ซึ่งจริงๆแล้ว Dimensional modeling ถูกนำไปประยุกต์ใช้กับธุรกิจจริงๆมากมาย

Myth 4. Dimensional models and data marts are only appropriate when there is a
predictable usage pattern.
– ผลที่ตามมาจาก Myth 4 คือ dimensional model ไม่สามารถตอบสนองต่อความต้องการทางธุรกิจได้
– จุดเริ่มต้นที่ถูกต้องสำหรับ dimensional models คือการทำให้ข้อมูลมีรายละเอียดน้อยที่สุดเพื่อให้เกิดความยืดหยุ่นและสามารถ นำไปขยายต่อได้

Myth 5. Dimensional models and data marts can’t be integrated and therefore lead to stovepipe solutions.
– Dimensional modelsและ data marts สามารถมารวมกันได้ถ้ามันสอดคล้องกับ data warehouse bus architecture

Common Pitfalls to Avoid : หลุมพรางพื้นฐานที่ควรหลีกเลี่ยง

Pitfall 10. Become overly enamored with technology and data rather than focusing on the business’s requirements and goals. : เปลี่ยนเป็นสนใจเรื่องเทคโนโลยีและข้อมูลมากๆ แทนที่จะสนใจในความต้องการทางธุรกิจและเป้าหมาย

Pitfall 9. Fail to embrace or recruit an influential, accessible, and reasonable management visionary as the business sponsor of the data warehouse. :

Pitfall 8. Tackle a galactic multiyear project rather than pursuing more manageable, while still compelling, iterative development efforts.

Pitfall 7. Allocate energy to construct a normalized data structure, yet run out of budget before building a viable presentation area based on dimensional models.

Pitfall 6. Pay more attention to backroom operational performance and ease of development than to front-room query performance and ease of use.

Pitfall 5. Make the supposedly queryable data in the presentation area overly complex. Database designers who prefer a more complex presentation should spend a year supporting business users; they’d develop a much better appreciation for the need to seek simpler solutions.

Pitfall 4. Populate dimensional models on a standalone basis without regard to a data architecture that ties them together using shared, conformed dimensions.

Pitfall 3. Load only summarized data into the presentation area’s dimensional structures.

Pitfall 2. Presume that the business, its requirements and analytics, and the underlying data and the supporting technology are static.

Pitfall 1. Neglect to acknowledge that data warehouse success is tied directly to user acceptance. If the users haven’t accepted the data warehouse as a foundation for improved decision making, then your efforts have been exercises in futility.