01204451 – Datawarehouse

เนื้อหาทั้งหมดต่อจากนี้ถูกเขียนโดยนิสิตภาควิชาวิศวกรรมคอมพิวเตอร์

คณะวิศวกรรมศาสตร์ มหาวิทยาลัยเกษตรศาสตร์ รุ่นที่ 23

โดยเป็นเนื้อหาจากบทเรียนทีเกิดจากการจดบันทึกในห้องเรียนและศึกษาเพิ่มเติมจากนอกห้องเรียน

โดย มีจุดประสงค์เพื่อเป็นแนวทางในการเรียนรู้ของผู้ที่สนใจหรือรุ่นน้องรุ่น ถัดๆไป โดยมีการคงสภาพของเนื้อหาทั้งหมดไว้ทุกประการ รวมถึง คอมเมนท์ ส่วนที่ไม่ใช่เนื้อหาอื่นๆ เป็นต้น

อย่างไรก็ตาม

ในกรณีที่ถูก นำไปใช้หรือนำไปอ้างอิงด้วยวิธีใดวิธีหนึ่งก็ตาม ในกรณีที่เนื้อหาไม่ถูกต้อง ไม่เหมาะสม ผู้เขียนจะไม่ขอรับผิดชอบใดๆทั้งสิ้น ขอให้อ่านด้วยวิจารณญาณของผู้อ่านเอง

ท่านสามารถอ่านเลคเชอร์ฉบับ Document ได้ที่นี่

===============================================

204451 Datawarehouse

Database System Design

aka. Datawarehouse

เนื้อหาที่จดมามีไม่ครบทั้งหมด ควรอ่านคู่กับสไลด์ของอาจารย์ผู้สอนควบคู่กัน

Course Information

Lecturer: Assoc. Prof. Kisana Waiyamai

Office: 201, Tue 0900-0200 or appointment

Slides:http://course.ku.ac.th ลงทะเบียนวิชา 01204451

Book : the Data Warehouse Toolkit (มีใน M@xLearn แล้ว)

Software Requirement : Microsoft Sqlserver 2008, Microsoft Office Excel, SSAS Score CellSetGrid

Evaluation Policy :

Homework and Paticipation, quiz 10%

Group Assignment 30% << เอาความรู้ที่ไปเรียนมาไปเขียน App จริงๆซักตัวนึงเพื่อวิเคราะห์ข้อมูล

Midterm 30% << สอบ Lab เกี่ยวกับ ETL Tools โดยมีการดึงข้อมูลจากในเครื่องไป db อีกก้อนนึง

Final 30%

Grade: อิง….อะไรวะ ? (อิงกู?) ส่วนมากไม่ตัด F

ต้องเอา laptop ตัวเองมาด้วย

Database Document : http://goo.gl/wI0D4

Lecture 1 : Introduction BI & Data Warehouse

จากวิชาที่แล้วที่เราเรียนเพื่อออกแบบระบบฐานข้อมูลตั้งแต่ต้น มาถึงวิชานี้เราต้องการที่จะนำฐานข้อมูลที่มีอยู่แล้วมาปรับปรุงเพื่อที่จะทำให้ระบบสามารถ Query ได้เร็วยิ่งขึ้น

ความจริงแล้ววิชานี้คือ BI (Business Intelligence)หมายถึงการนำข้อมูลที่มีอยู่แล้วมาใช้ประโยชน์ หรือมองอีกมุมนึงว่าเป็น Data Analysis ก็ได้

Data Warehouse เป็นส่วนสำคัญของ BI เป็นการ design database เพื่อเอาไปอ่าน (query เร็วๆ)

BI เป็น software อันดับแรกที่องค์กรจะต้องการนำไปใช้ในองค์กรของตน จัดเป็นตลาดใหญ่แห่งใหม่สำหรับสาย CPE (ซึ่งตอนนี้ก็ยังอยู่ใน trending)

BI คือ process, tool, tech for transform enterprise data (มาจาก Operational System) into information (data ที่จัดรูปแบบแล้ว และสื่อความหมายกับผู้ใช้ ซึ่งต้องตอบโจทย์กลุ่มเป้าหมายได้) และ information to knowledge ใช้สืบความลับจากข้อมูลทางธุรกิจ เพื่อให้รู้จัก ประเมินตัวเองได้ดี ถูกต้องยิ่งขึ้น โดยออกมาเป็นค่า KPI (Key Performance Indicator) ดูว่า performance เป็นอย่างไรบ้างในหลายๆมุมเช่น รายได้ของบริษัท ค่าความสุขของพนักงาน ยอดขายของพนักงานแต่ละคน etc.

ประเด็นของ BI คือ What is going on ? , understanding the past and predicting the future., What if?

Data => Information => Knowledge

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

BI ที่ดีต้องสามารถบอกในสิ่งที่อยากรู้ได้หรือสามารถลงลึกไปถึงรายละเอียดได้ เช่น ทำไมปีนี้ถึงยอดขายไม่ดี ไม่ดีที่ไตรมาสไหน เดือนอะไร จาก Product อะไร เพราะอะไรถึงขายไม่ออก (ได้ยิ่งลึกยิ่งเด็ด !!)

BI Process

Data Source (Other Source, Operational DB) => Data Storage(Data Warehouse , Data Marts) => OLAP Engine => Front-End (Report, Data Mining)

(รูปจากทางบ้าน)

Data warehouse คือฐานข้อมูลขนาดใหญ่ที่เก็บข้อมูลทุกอย่างขององค์กรมาเก็บไว้ในที่ๆเดียว ซึ่งข้อมูลตัวนี้จะถูกดึงมาจากฐานข้อมูลย่อยจากที่ต่างๆ ผ่านกระบวนการ ETL (Extract,Transform, Load, Refresh) ซึ่งจะอธิบายในภายหลัง

นอกจากนี้ data warehouse ยังต้องสามารถ track ย้อนหลังได้ เช่น ไทน์ เปลี่ยนชื่อเป็น นกกระไทน์ ระบบต้องรู้ว่า นกกระไทน์ กับ ไทน์ คือคนเดียวกัน

Staging เป็นที่พัก Data เพื่อป้องกันการดึงข้อมูลที่กำลังถูกใช้อยู่ ซึ่งอาจจะทำให้ข้อมูลเสียหายได้

เวลาทำงานจริง Part ที่ยุ่งยากสุดคือส่วนของ Extract,Transform, Load, Refresh เพราะว่า DB มันมีหลายชนิดแตกต่างกันไป จะดึงมาใช้รวมกันยังไง

Data Integration , ETL Tools คือ โปรแกรมที่ทำดึงข้อมูลจาก DB หลายๆ ค่าย (ใช้แทนการเขียนโปรแกรมเพื่อ query ถึกๆ ขึ้นมาเองเพื่อรองรับหลายๆ ค่าย)

Multi-Dimension Modeling แบบ star schema เป็นการ design ที่ทำให้ query เร็วที่สุด

ออกมิดเทอมเยอะสุด

ออกมิดเทอมเยอะสุด

ออกมิดเทอมเยอะสุด

ออกมิดเทอมเยอะสุด

ประเด็นสำคัญ คือ security ต้องมีการจำกัด permission ได้ ว่าใครดูได้บ้าง เห็นได้มากน้อยแค่ไหน

แนวโปรเจคกลุ่ม และข้อมูลถูกต้อง (ถูกต้องสำคัญกว่า secure)

  1. ทำ report
  1. อาจทำได้ทั้ง passive (เอาไว้รายงานให้หัวหน้าดู) และ active (custom report) เช่น กราฟยอดขาย
  2. OLAP-Online Analytical Processing (ad-hoc reporting) การวิเคราะห์ข้อมูลแบบ online/dynamic โดยอาศัยความเร็วผ่าน cube
  3. dashboard
  4. ใช้ GIS ดูได้ (geographic information system (GIS) lets us visualize, question, analyze, interpret, and understand data to reveal relationships, patterns, and trends. )
  5. visualization/UI ดีๆ มีชัยไปว่าครึ่ง (หน้าตาดี ใช้ง่าย ก็น่าสนใจใช่มะ ต้องมี ตัวเลขเด้งๆ ด้วย)

แนะนำ BI โหดๆ TDWI เป็นองค์กรที่ดูความเป็นไปของ BI ในโลก ซึ่งหัวใจก็ยังอยู่ที่ Data warehouse

==========================================================

แปะไว้

Data Warehouse = คลังข้อมูล

Data Warehousing = การทำคลังข้อมูล design, implement, deploy

==========================================================

Data Warehouse คือ a pool of data organized in format that

  1. enable users to interpret data
  2. convert into useful information

ลักษณะสำคัญของ Data Warehouse

  1. เก็บทุกอย่างจากหลายๆ แหล่งมาไว้ที่นี่ที่เดียว โดยข้อมูลต้องไม่ขัดแย้งกัน (แก้ช่วง ETL)
  2. Data warehouse เป็น subject-oriented แบ่งตามหัวข้อที่เราสนใจ
  3. optimize เพื่อให้ query เร็วๆ โดยการทำ denormalization
  4. มีปริมาณข้อมูลมหาศาล
  5. non-volatile
  1. ต้องบอกเวลาว่าอันนี้คือข้อมูล ณ เวลาไหน
  1. ไม่ค่อย Update บ่อยเพราะเป็นฐานข้อมูลที่ดึงมาจากฐานข้อมูลอื่นๆอีกที , เน้นการอ่านมากกว่าถูกเขียน เพื่อให้สามารถ track ความเป็นไปของข้อมูลย้อนหลังได้ จึงทำให้อย่างมากก็แค่เพิ่ม entry ไม่มีการเขียนทับ

Data Mart จัดเป็น data warehouse เล็กๆ แยกตามอะไรบางอย่าง แล้วแต่ว่าจะมองจาก bottom-up หรือ top-down

ทำ Data Warehouse เพื่อ

  1. High query performance (read)
  2. doesn’t interfere with local processing at sources
  1. complex queries at warehouse
  2. OLTP at sources
  1. Copy to warehouse
  1. security

function

  1. data quality
  2. ETL
  3. design
  4. admin

assignment อ่านบทที่ 1

Lecture 2 : Introduction Data Warehousing

Information Organization นั้นมีอยู่สองแบบโดยทั่วไปคือ

  1. Operational Systems (Database)
  1. คือ ข้อมูลจะถูกจัดเก็บยังไง
  2. ผู้ใช้เป็นคนขับเคลื่อนองค์กรให้ไปต่อได้
  3. มักใส่ข้อมูลทีละ Record
  4. มักทำงานในลูปเดิมๆเหมือนกันไปเรื่อยๆ ๆ ๆ
  1. Data warehouse (DW)
  1. ดูว่าองค์กรจะขับเคลื่อนไปยังไง
  2. คือทำยังไงถึงจะได้ข้อมูลออกมา
  3. ไปเอาข้อมูลมาจาก DB ไหนบ้าง
  4. ในคำถามหนึ่งๆนั้นจำเป็นต้องใช้ข้อมูลหลายร้อยหลายพัน Record จึงจะได้คำตอบ
  5. คำถามนั้นจะเปลี่ยนแปลงตลอดเวลา
  1. เพราะคนใช้แต่ละคนมีความต่้องการจาก Data warehouse แตกต่างกันกว่าผู้ใช้ใน Database ทั่วไป

จุดประสงค์การใช้งาน Data Warehouse

  1. เป็นศูนย์รวมข้อมูลขององค์กรที่เข้าถึงได้ง่าย พร้อมใช้งาน
  2. ข้อมูลถูกต้องครบถ้วน และไม่ขัดแย้งกันเอง
  3. secure
  4. ประกอบการตัดสินใจ
  1. ลองเอาข้อมูลเก่ามาเปรียบเทียบดูว่า ตรงกันมั้ย
  1. ผู้ใช้ต้องยอมรับว่า Data warehouse มีประโยชน์
  1. บางคนไม่ค่อยยอมรับผลลัพธ์จาก DW แถมไม่ค่อยให้ความร่วมมือ
  2. เพราะคนส่วนใหญ่ไม่ค่อยยอมให้ข้อมูลกับใครง่ายๆ << แหงดิ เก็บข้อมูลมาแทบตายเอ็งกดคลิกเดียวได้ข้อมูลหมดเบยยย << ดราม่าอีก
  1. ผู้บริหารต้องสั่งบังคับออกมาเป็นนโยบายเลย แล้วดราม่าจะจบ (?)
  2. export ออกมาเป็น XML Template ได้จะดี เพราะคนอ่านอ่านง่าย มีมาตรฐาน
  1. ประเด็น คือ โน้มน้าวและชักจูง โน้มน้าวให้บุคลากรเห็นความสำคัญของ data warehouse เพื่อให้ความร่วมมือเป็นไปได้อย่างราบรื่น
  2. มักเกิดปัญหา Data Inconsistency (ใช่มะ?) เพราะแต่ละที่ก็เก็บข้อมูลไม่เหมือนกัน
  1. หลายๆจังหวัดเรียกชื่อผลไม้ไม่เหมือนกัน ทำให้วิเคราะห์ข้อมูลได้ไม่ตรงกับความเป็นจริง

Components of DW

Operational Source => Data Staging Area => Data Presentation Area <= Data Access Tools

Data Mart ต้องพิจารณาถึงความละเอียดของข้อมูลเป็นสำคัญ อาจจะ design แยกตาม product ก็ได้ แต่โดยทั่วไปควรทำเป็น 1 data mart ต่อ 1 business โดยต้องทำให้แต่ละ data mart สอดคล้องกันได้ (เอามารวมกลับเป็น dw ได้อีก, เชื่อมกันได้)

Data Staging Area เป็นทั้งที่พักและ process ข้อมูล สิ่งที่ต้องคิดคือ Clean ยังไง, เก็บยังไง, process อะไรเพิ่มบ้าง

process ใน data staging area คือ ETL มี 3 กระบวนการคือ

Extraction – อ่านข้อมูลจาก DB ต่างๆ ที่จำเป็นสำหรับ DW

Transformation – แก้ไขข้อมูลให้สอดคล้องหรือทำให้ถูกต้องเช่น Correct misspellings, resolve domain conflicts, deal with missing elements, parse into standard formats

Load - ยัดลง DW

Data Presentation Area (DW) จัดการและเก็บสำหรับให้ user query ตรงๆ ได้เลย คือ Data Mart ย่อยๆ เก็บในรูป dimensional schema ซึ่งไม่ควรอยู่ในรูป normalize เพราะไม่เหมาะกับการ Query ในระบบของ DW , ซับซ้อน , ผู้ใช้ไม่เข้าใจ , ใช้งานยาก

ถ้าเก็บด้วย RDBMS เรียกว่า star schema (Relational Database)

ถ้าไม่ใช่ RDBMS เรียกว่า cubes (Multidimensional Database)

Data Mart เป็น DW ย่อยๆ เฉพาะ business ใดๆ อันเดียว (รายละเอียดอ่านจากสไลด์นะ)

Data Access Tools

  1. เพื่อเอาไปใช้เป็น analytics decision making
  2. query จาก DW

สิ่งที่ต้องพิจารณาเพิ่มเติม

  1. Metadata
  2. Operational Data Store

Metadata

  1. ข้อมูลรายละเอียดของ DW ที่ไม่ใช่ตัว Data ที่เราเก็บมาตรงๆ เช่น รายละเอียด partition ซึ่งไม่ได้เป็นไฟล์ที่เก็บใน partition นั้นจริงๆ หรือ ชื่อของ attribute ที่ถูกเปลี่ยนไปในการเขียน Report (เช่น เวลา select ตึ้ดๆ as ต้ึด เป็นต้น)
  2. ทำให้ user พอใจกับรายงานของเรา

Dimensional Modeling ให้มุมมองในการวิเคราะห์แสดงผลรายงานข้อมูล

  1. สิ่งสำคัญในการทำ BI คือ ต้องอินกับธุรกิจประหนึ่งว่านั่นคือธุรกิจของเราก่อน
  1. หา measure กับ dimension ให้ครบ
  1. dimension ที่สำคัญที่สุด คือ เวลา (time)
  1. รองลงมาคือ Product
  2. ตามด้วย Market
  3. การวัด (measure) performance ของธุรกิจ เช่น ยอดขาย, จำนวนนิสิตที่เรียนจบและมีงานทำ
  1. อาจดูจากรายงานเก่าๆ ของบริษัทว่าเค้าดูอะไรกันบ้างเป็นแนวว่าอย่างน้อยควรมีตามนั้น
  2. ชื่อของ column คือ dimension ส่วนจะวัดอะไรคือ measure
  1. ความยากคือ จะรวมยังไงให้เป็น table อันเดียว
  2. เลยอาจแบ่งเป็น 2 table
  1. Fact เก็บ measure ได้หลายอัน
  1. หาข้อมูลแบบภาพรวม/สรุป ได้จาก table นี้
  2. เก็บ event ที่เกิดขึ้นจริง
  1. Dimension เก็บ dimension แต่ระหว่าง dimension table ไม่โยงหากัน
  1. เก็บ dimension เดียวเท่านั้น ไม่เอา dimension อื่นมายุ่ง
  2. เวลาอยากดูรายละเอียดเพิ่มเติม ค่อยมาดูที่ table นี้
  1. star schema ทำให้ query เร็ว เพราะ มีแค่ sum กับ join ซึ่งไม่ค่อยได้ใช้ join มากเท่าไหร่ (อาจจะมีบ้าง แต่ส่วนใหญ่จะพยายามออกแบบให้ไม่มีการ join เลย)

Fact Table

  1. เป็น table หลักของ dimensional model เพื่อเอามาสร้างเป็นชุดคำตอบ
  1. จะเก็บหมดเลย หรือเอามาคำนวณอีกทีก็ได้
  2. มี foreign key ที่ชี้ไปยัง dimension table
  1. store numerical measurement เพราะเอาไปเทียบเป็นข้อมูลเชิงปริมาณได้ เช่น SUM, Average
  2. each measurement is intersection of all dimension
  3. best facts are numeric, continuously valued and additive

อาจจะเป็น Numerical ชนิด additive (เอามาบวกกันได้) หรือเป็น semi-additive (เป็นตัวเลขเหมือนกัน เอามาบวกได้ แต่ไม่ควร เช่น จำนวนเงินในบัญชี เราไม่เอาเงินในสัปดาห์นั้นมาบวกกัน เพราะผลลัพธ์ที่ได้ควรเป็นยอดล่าสุด ไม่ใช่ผลรวมของทุกยอดรวมกัน)

Dimension Table

  1. เอาไว้ดูรายละเอียดของธุรกิจ เพราะส่วนใหญ่ Fact Table มีแต่ตัวเลข ทำให้เราไม่เข้าใจรายละเอียดของมันเท่าไหร่
  2. ถูกอ้างถึงด้วย PK ตัวเดียวและเชื่อมโยงกับ Fact Table
  3. ข้อมูลควรเป็นข้อมูลที่มีรายละเอียดมากๆ เช่น เดือน 1 ก็ควรใช้เป็นเดือนมกราคม
  1. ไม่งั้นก็ต้องมาใช้การ coding หรือ metadata มาแก้อีก ซึ่งเสียเวลาและช้า
  1. โดยทั่วไปต้องเป็น Denormalize และมีขนาดเล็กกว่า Fact Table มาก
  1. improving storage efficiency by normalizing or snowflaking
  1. snowflake means Brand description and category description replace by brand code and create brand table
  1. ควรมีข้อมูลที่ใช้ในการแบ่งลำดับชั้นที่ชัดเจน เช่นปี ไตรมาส เดือน วัน วันในสัปดาห์ สัปดาห์ที่ เวลา etc.
  2. dimension ห้ามเชื่อมกันเอง

สรุป

  1. fact table ควรเป็นตัวเลขที่สามารถวัดได้และมีการเชื่อมโยงหรือ join เข้ากับ dimension table ซึ่่งมีการบอกรายละเอียต่างๆ ของ fact table ได้
  2. ลักษณะการ join คล้ายดาว คือเป็นแฉกๆออกจากตรงกลางเรียกว่า star schema
  3. All dimension are symmetrically equal entry points into the fact table
  1. No preferences for any query

assignment การบ้านบทที่ 2

Lecture 3 : Retail Sales Case Study

บทนี้สนใจเรื่องการขาย (Sales) เป็นหลัก และมีแค่ 1 business process

ในการสร้าง star-schema โดยทั่่วไปมีหลักการหรือวิธีการในการสร้างที่ควรจะต้อง follow อยู่ 4 ขั้นตอนดังนี้

1. Select the business process to model

เลือกส่วนของ business process ที่จะนำมาใช้ เช่น การขาย, สินค้าคงคลัง

2. Declare the grain of the business process

ดูว่าเราต้องการ grain หรือความละเอียดของข้อมูลขนาดไหน การขายในแต่ละช่วงเวลาที่เราต้องการความละเอียดสูงสุด (atomic) ต้องระบุให้ชัดเจน , granularity ละเอียด dimension เยอะ , dimension จะอยู่ประมาณ 15-20

3. Choose the Dimensions that aplly to each fact table row

มักมี 5-20 dimension โดยประมาณ ตัวอย่างยอดนิยม เช่น date, product, customer, transaction type, status

อันที่สำคัญที่สุดคือ Date จะได้รู้ว่าวันไหน

4. Identify the numeric facts that will populate each fact table row (measure)

สุดท้ายคำตอบที่ได้ของการทำตามขั้นตอนจะได้ facts ที่สามารถใช้ในการ วัด อะไรบางอย่างเพื่อใช้เป็นประโยชน์ต่อองค์กรได้

ได้ output เป็น โครง schema คร่าวๆ

Retail Case Study

————————

1. เลือก business process ขึ้นมาก่อน ในที่นี้เราเลือกส่วนของการขายปลีกหรือ POS หรือ Point of Service retail sales โดยขายอะไร ที่ ร้านไหน วันอะไร ใน โปรโมชันอะไร

2.Declare the grain โดยเราสนใจ (POS) แต่ละสินค้าแต่ละรายการใน transaction ของการขาย (ละเอียดมากๆ)

3. เลือก Dimension โดยทั่วไปเราจะได้ dimensions ของ date, product, store, promotion มาเลยทันที (เพราะข้อมูลพวกนี้ยังไงก็ต้องมีอยู่แล้ว)

ในการออกรายงาน ควรเอาสูตรคำนวณใส่ลงไปเลย อย่าไปคำนวณทีหลัง เพราะรองรับการทำงานข้าม platform มากกว่า

dimension

- hierarchy

- ใส่ชื่อเต็ม type เป็น text ไม่มีตัวย่อ

- อาจใส่วันที่รอไว้ได้เลย ขายไม่ขายอีกเรื่องนึง ถ้ามันไม่ขายมันจะไม่ขึ้นใน facts อยู่แล้ว

- อาจารย์แนะนำว่าการออกแบบควรเป็น single table จะดีกว่า เพราะ dw เน้น อ่าน ไม่เน้น เขียน การ denormalized จะทำให้อ่านเร็วกว่ามาก

- ควรเก็บข้อมูลเกี่ยวกับพิกัดหรือที่ตั้งของสาขาหรือร้านเอาไว้ด้วย เพราะในปัจจุบันนิยมออก report เป็นลักษณะ geographic หรือ Infographic มากกว่าเป็น text file (ดึงดูดใจกว่า น่าอ่านกว่า หล่อกว่า)

- Dimension ของ promotion นั้นเป็นส่วนสำคัญมากโดยเฉพาะส่วนของ type ของ Promotion เพราะเราอยากจะรู้ว่า Ad type , Display type , coupon type แบบไหนที่เอามารวมกันถึงทำให้ขายดีหรือไม่ดี

======

DD = Degenerated Dimension

หมายถึงมี Dimension Key แต่ไม่มี Dimension Table เพราะ data ถูกเก็บใน dimension อื่นหมดแล้ว

แล้วมีทำไม ? ก็เอาไว้ reference กับ Operation System หรือเป็น Requirement ของ User เอง หรือใช้ในการจัดกลุ่มเช่น สินค้าในบิลเดียวกันจะมี Invoice number เดียวกัน

======

surrogate keys

สรุปว่ามันคือ key ไร้สาระ

- มีประโยชน์ตอน query เช่น 28/06/2012 ไม่ต้องไปเพิ่มเงื่อนไขว่าต้องเป็น วันที่เท่านี้ เดือนเท่านี้ ปีเท่านี้ (การเทียบเลขsurrogate เร็วกว่าเอาวันที่ไปเทียบ)

- เปลี่ยน ข้อมูล surrogate ก็ไม่เปลี่ยน เช่น ถ้าเอารหัสนิสิตมาเป็น PK แล้วถ้ามีการเปลี่ยงแปลง ก็ทำให้ PK เปลี่ยนไป

- surrogate เป็น sequence สามารถเอาไปใช้ประโยชน์ได้ เช่น ให้เช็คเฉพาะข้อมูลที่ sequence >150 เท่านั้น เพราะเป็นข้อมูลใหม่

partitioning (จริงๆ แล้วมันก็เหมือนกับเทคนิค sharding ของ mongodb http://www.mongodb.org/display/DOCS/Sharding+Introduction) เป็นการแบ่งส่วนข้อมูลย่อยๆ ออกมา เช่น 1-300 แบ่งเป็น 3 ส่วน อันแรกเก็บ 1-100, อันที่สองเก็บ 101-200 อันที่สามเก็บ 201-300 ช่วยให้หาเร็วขึ้น เหมือนทำ index หลายๆ ชั้น

ระวังว่าถ้าเราต้องการแก้ไข schema ใหม่เช่น เพิ่ม attributes , dimensions , measured facts ต้องมั่นใจว่าไม่ส่งผลกระทบต่อข้อมูลเดิมที่ใส่ไปแล้ว (รายละเอียดส่วนนี้ลองไปอ่านในหนังสือหน้า 54)

ข้อควรระวังอีกจุดหนึ่ง สำหรับนักออกแบบใหม่ บางครั้งเราอาจจะ สร้าง Dimension Tableมากเกินไป ทำให้ดูแลลำบาก ซับซ้อนและทำให้มีัขนาดใหญ่เกินไป ต้องระวังในจุดๆนี้ (อ่านในหนังสือหน้า 58)

บางครั้งเราอาจจะสร้าง fact table ของคู่สินค้า เพื่อดูว่า สินค้าสองอย่างมีความเกี่ยวข้องกันอย่างไร เพราะอาจจะนำไปวิเคราะห์ข้อมูลในลักษณะคล้ายๆ การทำ Datamining แต่ใช้ลักษณะของการทำ warehouse แทน (อ่านในหนังสือหน้า 63) << ตรงนี้เรียก Market Basket Analysis

การบ้าน :

- ให้ OLTP มา แล้วให้ทำ 4 step design แล้ววาด star-schema มา อย่าลืม link key , pk , fk ,measure ใส่มาด้วย ส่งพรุ่งนี้ก่อน 4.30pm

- อ่านบทที่ 3

เฉลยการบ้านเรื่องการบิน

วิชานี้มีหลากหลาย solution ไม่ unique ไม่ตายตัว แต่ไม่ควรผิดหลักฉีกแนวไปเยอะ

สังเกตว่าไอ้ที่บอกมาเป็นข้อๆ ในโจทย์ คือ requirement

business process – analyst airline
granularity – ต่อคนที่บินต่อ boarding pass (individual boarding pass) เก็บว่าแต่ละคนที่บิน บินจากไหนไปไหน ราคาเท่าไร <<< ไม่รู้ศัพท์ก็เขียนยาวๆ แบบนี้ได้เหมือนกัน

Dimension table – Time, Departure Date, Customer, City เช่นอยากรู้ว่ามีกี่flightที่บินไปกรุงเทพ, Plane, Flight

*note* การที่สามารถอ้างไปยัง Dimension เช่น Time เรียกว่า Multi Dimension คือมี table เดียวแต่ว่าถูกเรียกได้หลายครั้ง เช่น เวลาออก และ เวลาถึง (Dept_Time, Arrive_Time)

Fact – key ของ แต่ละ dimension, Fare (ราคาที่ลดแล้ว), count (default เป็น 1 ไม่จำเป็นต้องมีก็ได้ เพราะมันนับจากจำนวน record ได้)

*** ควรทำ fact table แยกเรื่อง delay ออกมาต่างหาก แล้วไม่โยงไปหา customer, plane, departure date ผูกแค่กับ flight เท่านั้น (2 Fact table)

****คุยกับ TA เขาบอกว่าถ้าดูจากรีพอร์ตที่ต้องการให้แสดงก็จะเห็นเหมือนกันว่ามี 2 grain อันหนึ่งเก็บตาม flight กับ อีกอันเก็บตาม Customer

Lecture 4 : Inventory

ทบทวนบทที่ 2

grain ต่ำ -> Dimension เยอะ

ถ้าเป็น non-additive fact (มัน sum ไม่ได้) ต้องไปเซ็ตค่าในโปรแกรมไว้ว่าจะใช้ aggregation อะไร (default เป็น sum)

Aggregated Fact Table – บางทีเราควรจะมีอีก fact เพื่อเก็บ aggregated value (ค่าที่ความละเอียดน้อยลง เช่น จากวันเป็นเดือน) เพื่อให้สะดวกกับการออกรายงาน (query เร็วขึ้นไม่ต้องมานั่งบวก)

Based Fact Table – fact ที่เก็บความละเอียดสูงสุด

Factless Fact Table – fact ที่ไม่มีค่า measurement มีแต่ค่าที่มาจาก dimension เท่านั้น

Degenerate dimensions -dimension keys

without corresponding dimension tables)

, dimensions without dimension tables เพราะโดนดึงไปเป็น primary key หมดแล้ว

Role-Playing Dimension – เป็น dimension ที่สามารถใช้ได้หลาย event ส่วนมากมักเป็นพวกเวลา เช่น มี Dept time กับ Arrival time ที่มาจาก time dimension เหมือนกัน

***business process ศึกษาจาก UML (Unified Modeling Language) จะช่วยให้เข้าใจง่ายขึ้น เช่น ตรงไหนคือคอขวดของธุรกิจ

บทที่ 3

value chain ห่วงโซ่ทางธุรกิจ ประกอบด้วยหลาย business process ที่เป็นขั้นตอน ทำให้เราเห็นขั้นตอนต่างๆ ใน business process สังเกตว่ามีการ generate data ทุก step ปัญหาคือ เวลาเราจะวิเคราะห์ภาพรวม จะมองยังไง เรียกว่า cost business process analysis

โดยต้องออกแบบเผื่อให้มันสามารถรวมกันได้ด้วย

แต่ในบทนี้เราสนใจแค่ inventory เท่านั้น

fact table มี 3 ชนิด ขึ้นอยู่กับมุมมอง

  1. Periodic Snapshot Fact จับที่เวลาเป็น routine เช่น ในแต่ละวันจำนวนสินค้าเป็นยังไง
  2. Transaction Fact จับที่สินค้าเข้า-ออกจากคลัง ดูว่าแต่ละ transaction มีผลต่อจำนวนสินค้าคงคลังอย่างไร
  3. Accumulating Snapshot Fact จับที่ lot สินค้าเป็นสำคัญ ดูว่าตั้งแต่สั่งของเข้ามาจนขายออกไป แต่ละ step เป็นอย่างไร เกิดปัญหาตรงไหน

Periodic

  1. หยาบกว่า transaction
  2. ดูตามช่วงเวลาเป็น routine
  3. สนใจว่า หมดวันแล้วเหลือสินค้าใน stock เท่าไหร่
  4. เสียเวลานั่งไล่จำนวนที่เหลือนาน
  5. ทำเพื่อ
  1. ปรับสมดุลจำนวนสินค้าใน stock มากไปก็กินที่ น้อยไปก็ของไม่พอขาย เสียโอกาสทางการค้า
  1. Enhanced Inventory Facts (สูตรคำนวณดูในสไลด์)
  1. Quantity sold
  2. number of turns
  3. number of day’s supply
  4. gross profit
  5. gross margin
  6. GMROI ดูอัตราการไหลของสินค้า ทำให้รู้ได้ว่า สินค้าขายดีแค่ไหน ควรลงทุนไหม

มาก -> ขายดี

Inventory Transaction

event ที่นับว่าเป็น transaction

  1. รับสินค้าจาก vendor
  2. คืนสินค้า
  3. ตีกลับสินค้าเพราะเจอ defect
  4. ฯลฯ

ละเอียดสุดในสามแบบ แต่วุ่นวาย (- -”) เพราะต้องแยกประเภท transaction ด้วยว่าเป็นแบบไหน

Inventory Accumulating Fact

- ต่างจากสองแบบแรกที่สองแบบแรกนั้นโหลดทีเดียวเสร็จ แต่แบบนี้ record ไม่ได้โหลดทีเดียวเสร็จ ออกแนวนับสถิติเป็น counter ไล่ update ไปเรื่อยๆ เหมือนสร้าง record ไว้ก่อน แล้วค่อยๆเติมค่าลงไปทีละ arttibute ถ้าเติมครบแล้วจะสามารถนำไปวิเคราะห์วงจรชีวิตของสินค้า เช่น จำนวนวันที่สินค้าอยู่ในคลัง

- ข้อเสียคือ ต้องมี serial number ของสินค้าประกอบด้วย

- ใช้ multirow dimension เยอะมาก

- เหมาะกับธุรกิจที่ซื้อมาแล้วขายไป มีเลขสินค้าเดิมตลอด

4-step

  1. business process – retail inventory analysis
  2. granularity – ขึ้นอยู่กับชนิดของ facts
  1. Inventory Periodic Snapshot
  1. every time interval
  1. Inventory Transaction
  1. every transaction that has impact on inventory levels as products move through the warehouse
  1. Inventory Accumulating Snapshot
  1. each product delivery and update until the product leaves the warehouse
  1. dimension – ขึ้นอยู่กับชนิดของ facts (ดูตารางประกอบ)
  2. facts – ขึ้นอยู่กับชนิดของ facts (ดูตารางประกอบ)

conformed dimension คือ dimension ที่ละเอียดที่สุด (มี attribute เยอะๆ) และยังสามารถ share กันได้ ซึ่งบางทีอาจจะต้องยอมลดความละเอียดของข้อมูลลงเพื่อให้มันใช้ร่วมกับตัวอื่นได้ หลักคือ มันต้องใช้ primary key เดียวกัน ไม่งั้นคุยกันไม่รู้เรื่อง

รวม fact table ได้เมื่อมัน share dimension เดียวกัน

วิธีที่ดูง่ายที่สุดคือ ทำตาราง bus matrix เพื่อเปรียบเทียบว่าแต่ละ business process ใช้ dimension อะไรบ้าง

row – business process หรือ fact table แล้วแต่ว่าจะไล่ละเอียดแค่ไหน

column – dimension ที่ใช้

การบ้าน รพ. ส่งวันจันทร์ก่อนเที่ยง

- ใช้ความรู้อะไรบ้างในการทำ เช่น factless fact table

- บทที่ 4

เฉลยการบ้าน2 Hospital

  1. report มีแบ่งตาม branch แล้วสามารถดูรายละเียอดของแต่ละคน แล้วก็แบ่งตาม diagnosis
  2. ยังคงเป็น business process เดียวคือ วิเคราะห์รายได้ของโรงพยาบาล
  1. business process – analyze of hospital service and cost
  1. โจทย์นี้มี granularity >1 ของสอง report ไม่เหมือนกัน ตรงนี้เป็นส่วนที่บอกว่าเราควรจะแยก fact table เพราะว่า granularity มีความหลากหลายมากขึ้น
  1. each patient cost
  2. each patient diagnosis cost
  1. ใน star schema สามารถมีหลาย granularity
  2. choose dimension – time, doctor, branch,customer,diagnosis
  3. Fact
  1. total diagnosis cost, medicine cost, equipment cost, operation cost, tax
  2. diagnosis cost
  3. service-duration(pre-calculate), total cost(pre-calculate)

อย่าลืมว่าในการสร้าง Dimension Table ควรคำนึงถึงว่า ควรสร้างให้ผู้ใช้สามารถ “ลากแปะ” attribute ต่างๆออกมาใช้ได้โดยง่ายโดยไม่ต้องผ่านฟังก์ชันอะไรมากมายจะดีที่่สุด โดยเฉพาะในส่วนของ Date Dimension ควรจะต้องมีเสมอ

Chapter 4 : Procurement

  1. ปกติค่าใน DW จะไม่ค่อยเปลี่ยน จะเอาไว้อ่านอย่างเดียว แต่ว่าในบทนี้จะอนุญาตให้เปลี่ยนได้บ้าง (slowly changing)
  2. attribute ที่อยู่ใน dimension ปกติจะไม่ค่อยเปลี่ยน จะคงที่อย่างนั้น เช่น ที่อยู่
  3. ส่วนในบทที่สี่คือเรื่องของเรื่องการจัดซื้อ ซื้อของมาเอาไปขาย resale เอามาแปลงเป็นอย่างอื่นไม่ก็ขายเลย
  4. เป็น business ที่เกี่ยวข้องกับหลาย business process

Blended Fact Table(Single)- คือการรวม Procurement ทั้งหมดไว้ใน Fact Table เดียวโดยมีการเพิ่ม Procurement Transaction Type Key ขึ้นมาเป็นตัวแยกในแต่ละ type และ Procurement Transaction type Dimension ในการบอกลักษณะของแต่ละ type

Separate Fact Table(Multi) – เพราะบางครั้งเราไม่สามารถรวมในแต่ละ type ได้เลย จึงต้องแยกแต่ละ transaction ออกเป็นคนละ Fact Table

แล้วเวลาสร้างจะสร้างแบบไหนดี ?

  1. โดยปกติเราจะถาม end-user ก่อนว่าใช้แบบไหนจะใช้ง่ายที่สุดเพราะบางที user อาจะอยากได้ข้อมูลจากแหล่งเดียวไปเลย หรือบางทีอาจจะต้องการแยกเป็นส่วนๆมากกว่า เช่น ???
  2. ถ้ามี control number ต่างกัน แสดงว่าเป็นคนละ business process ให้ทำเป็น separate
  3. ถ้า fact table มี dimension ต่างกัน ก็แยกเป็น separate ดีกว่า
  4. ยิ่งมี fact table หลายอันยิ่งดี เพราะมันทำให้ใส่ attribute ได้ละเอียดกว่า ทำให้วิเคราะห์ได้เยอะกว่า

Chapter 4 Part 2 : Slowly Changing Dimension

โดยทั่วไปใน DW เราแทบจะไม่เปลี่ยนแปลงข้อมูลใดๆอยู่แล้ว แต่ถ้ามีการเปลี่ยนแปลงจะเป็นการเปลี่ยนแปลงอย่างช้าๆ (Slowly Changing) โดย

  1. ถ้ามีการเพิ่มข้อมูลใหม่ ก็ Add ข้อมูลไปเลย
  2. ถ้ามีการ edit บาง row เราควรต้องมีการเก็บว่าข้อมูลเปลี่ยนแปลงอย่างไร

ดังนั้นเราจึงมี เทคนิคในการจัดการการเปลี่ยนแปลงของข้อมูล มีอยู่ 4 วิธี คือ

Type 1 แก้แม่ง – คืออยากแก้ตรงไหนก็แก้ ง่ายสุด เร็วสุด แต่ปัญหาคือเราไม่สามารถเก็บค่าก่อนหน้าการเปลี่ยนแปลงได้เลย

Type 2 Add Row ใหม่ซะเลย – ใช้สำหรับ track change โดยถ้าเราต้องการแก้บาง attribute เราจะสร้าง surrogate key ให้ข้อมูลที่เพิ่มเข้าไปใหม่เลย และใส่ record ใหม่เข้าไป (ของเดิมก็ยังอยู่)

แต่พอเราใส่เข้าไปใหม่เราจะไม่รู้ว่าตกลงอันล่าสุดคืออันไหนแล้วจะใช้อันไหนดี ? แก้โดยการเพิ่ม atrribute ใหม่เข้าไปคือ Datestamp ซึ่งสามารถบอกได้ว่าข้อมูลไหนไหม่กว่า และเราสามารถใช้เกณฑ์ต่างๆในการแยกข้อมูลในแต่ละ row ได้ด้วยโดยการใช้ Expired Date ในการแบ่งข้อมูล

ข้อดี – สามารถดูอดีตได้ด้วย

ข้อเสีย – เสียเนื้อที่ในการเก็บ row เพิ่มขึ้น

Type 3 เพิ่ม Column เอาดิ – คือมีการเพิ่ม Prior Attribute เข้าไปอีกช่องนึงเลย ไม่ต้องเพิ่ม row ใหม่ แถม query ออกมาได้เลยในครั้งเดียว

ข้อดี – ไม่เปลือง row

- ถ้าต้องการจะรู้ข้อมูลอดีตตลอดเวลา ควรใช้อันนี้ เพราะไม่ต้อง query เพิ่ม

ข้อเสีย – สามารถ track ข้อมูลย้อนหลังได้สูงสุดเท่าจำนวน Prior Attribute เท่านั้น ข้อมูลก่อนหน้านั้นจะไม่สามารถดูได้เลย

Hybrid Slowly Changing Dimension (Predictable Changes) คือสร้าง attribute เผื่อไว้ล่วงหน้าเลย เหมาะสำหรับธุรกิจที่รู้ชัดเจนว่าเราจะเปลี่ยนข้อมูลกี่ครั้ง

ถ้าเป็นแบบ unpredictable (ในหนังสือมี) จะใช้ type 2/type3 ร่วมกัน คือ เวลามีการเปลี่ยนแปลงค่า จะทำการเพิ่ม row แล้วก็เก็บไว้ด้วยว่าค่าเก่าคืออะไร ทำให้สามารถ track ไปเรื่อยๆ ได้

สิ่งที่ต้องทำมาครั้งหน้า

SQL server 2008 business intelligence

SQL server management studio ต้อง connect ได้

Visual Studio 2008

อ่านบท5 เตรียมควิส

Chapter 5 Order Management

เฉลย quiz พี่เลี้ยงเด็ก

ต้องการ

  1. ดูเงินที่ลูกค้าจ่าย
  2. เงินที่พี่เลี้ยงได้
  3. งานทีเสร็จ

BP=babysitter service analysis for different club in a collage not เด็กนั่งดริงซ์ !!

  1. JobNumber เป็น DD
  2. Club ควรจะรวมใน Employee ไปเลยหรือไม่ก็แยกออกมาเป็น dimension นึง ไม่ควรเป็น snowflake ถ้าไม่จำเป็นจริงๆ
  3. ควรมี Time Dimension ด้วย (แต่ต้องมี Date Dimension !!)

Bus Mattrix

ใครอธิบายได้มาอธิบายที = =)|||

1 row คือ 1 business process, column คือ dimension แต่เพื่อความสะดวกในการใช้ dimension รวมกัน เราจึงต้องทำการ conform dimension ก่อน โดยปรกติทั่วไปจะนิยมใช้ bus Matrix เมื่อ business process มีความยุุ่งยากซับซ้อน เพราะบางทีเราจะใช้ข้อมูลจาก หลายๆ Fact ทำให้พอเขียน bus matrix เราก็จะรู้ว่า Fact อันไหนที่ทำอยู่มัน conform กันบ้าง อันไหนใช้อะไรร่วมกันบ้าง

Fact Normalization << ไม่นิยม

เป็นการแยกFact table ออกมา ในกรณีที่ไม่มีการคำนวณร่วมกัน ค่าต่างๆ ที่เป็น Measure ไม่เกี่ยวข้องกัน เอามาคำนวณต่อไม่ได้ ก็ควรจะแยก แต่ถ้ามีการคำนวณค่าร่วมกัน ก็รวมเอาไว้ใน Fact table เดียวกัน จะง่ายตอนที่ใช้ SQL คำนวณตอน query ได้ — ไม่ชัวร์ ช่วยเช็คด้วย

The concept of normalizing the fact table means that we

•reduce the fact table to one measure and

•add a new dimension for fact type (qty, gross, discount, net)

Dimension Role-Playing

เวลาเราเขียน schema บางทีอาจจะมี dimension บางตัวที่มีลักษณะคล้ายๆกัน เช่น Date dimension ของการสั่งซื้อ การจัดส่ง การรับของ etc. ซึ่งถ้าเราแยกออกเป็นแต่ละ dimension จะทำให้ยาก ไม่สัมพันธ์กัน และข้อมูลมีขนาดใหญ่เกินไป โดยทั่วไปเราจะวิธีการรวมเป็นตารางเดียวแล้วใช้ views ในการมองตารางนี้ในหลายๆมุมมองเหมือนมันมีอยู่หลายตาราง

Dimension Revisited

ส่วนใหญ่ตาราง product dimension จะมีลักษณะคล้ายๆกันคือ

1) มีคำอธิบายมาก description มาก ส่วนใหญ่จะเป็นค่าที่คงที่ ไม่ค่อยเปลี่ยนแปลง หรือถ้าเปลี่ยนก็เปลี่ยนช้าๆ

2) ส่วนใหญ่จะมี hierarchy มากกว่า 1 เพราะทำให้เราสามารถ roll up/drill down ได้

วิธีที่จะช่วยเราในการดูแล dimension ต่างๆ คือ

1) เปลี่ยนจาก operational key —> surrogate key เพราะทำให้เราสามารถ track change ได้ง่ายกว่า แล้วบางที เราต้องทำการรวมข้อมูลจากหลายๆแหล่ง ทำให้ operational key ไม่เหมาะสม ใช้ surrogate key จะดีกว่า

2) ค่าที่อยู่ในตาราง ให้ใช้เป็นตัวหนังสือที่แปลความหมายได้เข้าใจ ไม่ใช่ code ถ้าเกิดว่ามี code เป็น attribute แล้ว code นั้นแสดงถึงข้อมูลหลายๆอย่าง ให้เราแยกมันออกมาจากกัน เป็นคนละ field เช่น A0112 = product A subcategory 01 year of manufactuing 2012 ให้เราแยก attribute พวกนี้ออกจากกันซะ ไม่ใช้ code ลับ

3) ตรวจสอบค่าที่ใส่ลงไปให้ดี เพราะว่าถ้าเกิดว่าเรา key ด้วยมือแล้วสะกดผิด เวลาทำ query จะทำให้ได้ข้อมูลออกมาไม่ถูก เพราะว่ามันไม่ match เลย หรือว่าค่าต่างๆ ที่เป็นตัวเลข เช่น เรากรอกช่องที่จะเอาไปใช้เป็นตัวหาร ด้วยเลข 0 เวลา query แล้วคำนวณ มันก็จะผิดได้

4) เก็บข้อมูลเขียนไว้เป็น document สำหรับ พวกความหมายของ attribute ต่างๆ, คำแปล, metadata จะได้ maintain ระบบง่าย

Customer Ship-To Dimension

อาจมี hierarchy แยกตามความเหมาะสม เช่น รายคน หรือรายพื้นที่อาจมีการเรียงลำดับตาม หมู่บ้าน อำเภอ จังหวัด ประเทศ ทวีป etc. ที่มี hierarchy ที่ชัดเจนคล้ายๆ tree นั่นเอง

1. many-to-many => สร้าง bridge table มาช่วย

2. varies over time => ต้องสร้าง fact table เพิ่ม

3. If the sales rep and customer ship-to dimensions

participate independently in other business process fact

tables, we’d likely keep the dimensions separate.

Deal Dimension

เป็น dimention ที่เก็บรายละเอียดของการตกลงกับลูกค้า พวกข้อเสนอที่เราให้กับลูกค้า (ในทางทฤษฎี ข้อเสนอพวกนี้มีผลต่อปริมาณการซื้อของลูกค้า ทำให้เอามาพิจารณา) ใน dimension นี้จะมีการระบุ combination ทั้งหมดของเงื่อนไขต่างๆ ที่ให้กับลูกค้า พวกส่วนลด แล้วก็สิ่งจูงใจ (แปลได้แบบนี้ แต่นึกภาพไม่ออก 55 combination ของเงื่อนไข คือ แต่ละ deal ที่ให้กับลูกค้าแต่ละคนอาจจะไม่เหมือนกันรึเปล่า เดานะ)ถ้าเกิดว่า combination ทั้งหมดของเงื่อนไข ,ส่วนลด , สิ่งจูงใจ มีความสัมพันธ์ต่อกัน เราจะเก็บเอาไว้ใน deal dimention เดียวกัน แต่ถ้าพวกนี้ไม่สัมพันธ์กัน เราจะแยก dimention ออกไป

allowance = ส่วนลด

incentive = สิ่งจูงใจ

ในกรณีที่ Fact table มีขนาดใหญ่มากๆ เราจะไม่แยก dimension เพราะทำให้มี key เพิ่มเข้ามาใน fact table เป็นจำนวนมาก ทำให้กินที่ใน fact table เราเลยจะเลี่ยงการกินพท.เก็บโดยไม่แยก dimension (ถ้ามีแค่ dimension เดียวทำให้ FK ใน fact table มีแค่อันเดียว)

DD

DD ของ order number จะเป็น operation transaction identifier (เหมือนอ้างมาจาก Operational System)

ข้อดีคือ – ทำให้สามารถ group line order ได้ (order หนึ่งๆ มีหลาย product เราสามารถใช้ Ord no group line order ได้) ทำให้เราสามารถตอบคำถามได้ว่า ค่าเฉลี่ยของปริมาณของใน order มีเท่าไหร่ แล้วก็ เพราะว่าเราอ้าง DD มาจาก operational system ทำให้สามารถ Link data warehouse กับ operation system ได้ง่าย

Junk Dimension

บางทีมีข้อมูลอื่นๆ อีก ทีไม่ใช่ทั้ง measure และ dimension เป็นพวก type ของ row นั้นๆ (ดูรูปใน slide แล้วจะเข้าใจมากขึ้น)ไม่รู้ว่าจะเอาไว้ไหนดี แล้วจะทำยังไงดี?

  1. ยัดใส่ fact table แต่ก็ไม่ดี เนื่องจากบางทีมันก็มี บางทีมันก็ไม่มี ทำให้ขนาดของคอลัมภ์ไม่คงที่
  2. ในบางกรณีที่ combination มันเยอะมากๆ ก็ทำให้เปลืองที่เก็บใน fact table เพราะว่ามันเป็นพวก type (แต่ละattribute มีค่าได้แค่ไม่กี่ค่า) มีโอกาสซ้ำกันเยอะ
  3. แยกแต่ละ flag ออกเป็น dimension ใหม่ ก็ไม่ดีอีกเพราะจะมี dimension เยอะเกินไป
  4. ลบออกไปเลย ก็ไม่ดีอีก เพราะมันก็ยังมีประโยชน์อยู่นะ แต่ไม่ได้ใช้บ่อยๆ

วิธีการคือเราเอา flag ทุกตัวนำไปสร้างใน dimension ใหม่ขึ้นมาเลย

สรุปมันคือ dimension สิ้นคิดนั่นเอง ไม่รู้จะเอาลงไหน ก็มายัดลงในนี้ ในกรณีที่ combination ของ indicator มันเยอะมากๆ เราไม่จำเป็นต้องสร้างเตรียมไว้ เราค่อยมาเพิ่ม combination นั้นๆ ตอน runtime เอาก็ได้

Multiple Currencies

โดยทั่วไปทำแค่ local กับ standard พอ แต่ถ้าต้องใช้เยอะจริงๆ ก็สร้างตารางอัตราแลกเปลี่ยนขึ้นมาเลย เป็นตาราง currency conversion fact table เก็บค่าแปลงไปแปลงกลับ

Shipping Order

เวลาเราส่งของ จะมีค่าใช้จ่ายที่โดนชาร์จในแต่ละ order ทีนี้เราจะรู้ได้ยังไงว่าสินค้าแต่ละตัวมีค่าจัดส่งยังไงดี ?

ง่ายๆ ก็กระจายราคาค่าส่งไปไว้ในแต่ละตัวสินค้าไปเลยสิ

ในกรณีนี้ จะเห็นว่า Order header fact เป็นคนละ granularity กับ Order Line fact คือ order line จะละเอียดไปถึง product แต่ละตัว ส่วน order header จะเก็บแค่ส่วน order นั้นๆ ทำให้เวลาที่เราพิจารณาการส่งสินค้า ถ้าดูแต่ order line fact อย่างเดียว (แบบที่ไม่มี การ allocate Order Shipping Charge มา) จะทำให้เราดูความสัมพันธ์ระหว่างการส่งสินค้าของ product แต่ละตัว กับค่าส่งของ order นั้นๆ ได้ ซึ่งทำให้มีการ allocate มา จาก header ไป line level เพื่อให้สามารถพิจารณาความสัมพันธ์ในส่วนนี้ได้ง่าย

แต่มีปัญหาคือเราไม่สามารถที่จะทำเองได้ เพราะเราอาจจะไม่รู้ว่าสินค้าตัวไหนพอแยกออกมาเป็น line แล้วจะมีค่าจัดส่งเท่าไหร่ยังไง อาจจะต้องคุยกับแผนอื่นๆ เพื่อที่จะได้ข้อมูลตรงนี้มา

Invoice Transaction

บึ้ม เป็นผุยผง . นอน

คร่าวๆคือ โดยพื้นฐานที่สุดเรามักใช้ invoice Transaction เป็นข้อมูลในการทำ dw เพราะมีความละเอียดมาก และตรงประเด็นที่สุด ดูจากตัวอย่างโจทย์ที่เราเคยทำมาก็ได้ ส่วนใหญ่เรามักจะเล่นกับใบเสร็จเป็นส่วนใหญ่

Accumulating Snapshot

เป็นการเก็บข้อมูลในแต่ละ cycle ของกระบวนการ ทำให้เราตรวจสอบได้ว่าในแต่ละช่วงของ process เป็นอย่างไร ผลิตช้าเร็วอย่างไร เกิดคอขวดที่ไหน (lag calculation) ทำให้เราตรวจสอบได้ว่าเกิดปัญหาหรือเกิดความล่าช้าที่ไหนบ้าง เหมาะกับ product ที่มีความ unique เช่น เป็นชิ้นส่วนของอุปกรณ์ที่มี serial number ในตารางจะเต็มไปด้วยค่า date มากมาย เพราะเรา track ข้อมูลจาก วันที่ ทำให้เกิด role play ของ date dimension

Fact Table Comparison

 

Characteristic

Transaction

Periodic

Accumulating

ช่วงเวลา

หนึ่งหน่วยเวลา

ช่วงที่กำหนดไว้ เช่น สัปดาห์ เดือน ปี

ตั้งแต่เริ่มต้นจนถึงปัจจุบัน

grain

1 row per transaction

1 row per period

1 row per life

การโหลด

Insert

Insert

Insert and update

Date Dimension

Transaction date

end-of-period

multiple dates for standard milestones

Fact

Transactions activity

Performance ใน 1 ช่วงเวลา

Performance ตลอด lifetime

Real-Time Partitions

ต้องรู้ว่าข้อมูลปัจจุบันอยู่ไหน ค่าล่าสุดที่เรามีคืออะไร สมควร update ค่าใหม่ยัง

index ควรน้อย

grain ควรละเอียดพอๆ กัน จะได้ load เร็วเพราะไม่ต้องมานั่งปรับ

ตัดจบเลยหรออาจารย์ – -” // ปั่นอย่างไวแล้วก็จบอย่างงง = =)||

มิดเทอมออกถึงบท 5 แนวข้อสอบคล้ายวันนี้ แต่โจทย์ชัดเจนกว่า และยากกว่า T^T


Midterm Review

Keywords and Techniques in DW

Ad-hoc Reporting การสร้างรายงานจาก warehouse ออกแนวเขียนเองกับมือ คำถามเฉพาะหน้า (Ad-hoc query)

Ad-hoc Query -คำถามอะไรก็ได้ ที อยู่ภายในขอบเขตของข้อมูล

Slicing and Dicing - การสร้าง combine the data in the warehouse in endless combination ซึ่ง dw ต้องมีคุณสมบัตินี้

ETL – Extract-Transformation-load – กระบวนการนำเข้าข้อมูลจาก Operational DB มาสู่ DW

Data Staging Area – ที่พักข้อมูล อยู่ตรงกลางระหว่าง Operational DB กับ Data Presentation Area

Star-Schema – Schema ที่มีลักษณะเป็นรูปดาว คืิอแยกออกจากตรงกลาง(Facts)ไปเป็นแฉกๆเดียว (Dimensions)

Grain - หน่วย, ความละเอียด (granularity)

OLTP - Online Transaction Process ก็คือการทำงานของระบบ database ทั่วไปที่มีการ query insert ที่ทำงานเป็น routine มีคนเข้าใช้พร้อมกันมากๆ นั้นแหละ

OLAP – Online Analytical Process เป็นการสร้าง report โดยจะดึงข้อมูลใน data warehouse ออกมาใช้ ลอง search ดู นะ ในไฟล์นี้แหละ หรือว่าอ่านจาก link นี้ก็เข้าใจดี

Cubesลองกด search ดูมีความหมายของมันอยู่

Data access tool - ตรงความหมาย

Metadata - data ใน dw ที่เป็นข้อมูลอื่นๆที่ไม่ใช่ตัว data จริงๆ เช่น schema

Operational data store - ?

Degenerate Dimension (DD) – เป็น foreign key ที่ไม่ได้อ้างถึง dimension ใดเลย แต่ที่มีเอาไว้สำหรับอ้างอิงกับ operational database หรือเอาไว้จัดกลุ่ม เช่นสินค้าใดอยู่ในบิลเดียวกัน

Surrogate keys – เป็น integer value ที่สร้างขึ้นมาใหม่ ถูกใช้เป็น primary key ของแต่ละ dimension ปกติเอาค่ามาคำนวณอะไรไม่ได้ ข้อดีคือลดขนาดของ fact table , ใช้ซ้ำได้ ลดขนาดข้อมูลของ dw etc.

Snowflaking - คือ schema ที่มีการทำ normalization ส่งผลให้อาจจะมี table งอกออกมาจาก dimension อีก ดีคือเก็บข้อมูลน้อยลง ไม่ซ้ำ แย่คือซับซ้อน เข้าใจยาก หลายตาราง ต้อง join เยอะ queryช้า

Partitioning - การแบ่งข้อมูลชนิดเดียวกันเป็นหลายๆส่วน (ลองค้นดูในไฟล์นี้)

Market Basket Analysis - เป็นการทำ data mining <ไม่ออกสอบจ้าา> เป็นการแปลง Fact Table ที่มีอยู่เดิมให้เป็น Fact ใหม่โดยมีการเปรียบเทียบกันระหว่างสินค้า 2 ประเภทเพื่อดูความสัมพันธ์ของสินค้าทั้งสอง

Bus Architecture – เป็นการที่ Fact Tables หลายๆตัว ใช้ Dimensions Table ร่วมกัน

Bus Matrix – เป็นตารางสองมิติ ฝั่งนึงเป็น Dimension อีกฝั่งเป็น Fact โดยจะมีเครื่องหมายบอกว่า Fact Table ตัวไหนใช้ Dimension ตัวไหน

Fact tables :

  1. transaction – เก็บ fact ในรูปละเอียดที่สุด คือเก็บทุก activity เลย
  2. periodic snapshot - เก็บเป็นช่วงเวลา เช่น ทุกวันที่ x ของเดือน etc. หมายถึง เก็บค่าของช่วงเวลานั้นๆ ลงใน row เพียง row เดียว มักใช้ในการตรวจสอบยอดสินค้า etc.
  3. accumulating snapshot – เก็บเป็นภาพรวมของทั้งหมด เช่น row หนึ่งๆ เป็น life time ของ product ตัวนั้นๆ ไปจนจบ โดยมีการอัพเดทค่าเรื่อยๆ ตรงไหนยังไม่ได้อัพก็อาจปล่อยเป็น null หรือ ขึ้นเป็น N/A ไว้

Conforms Dimensionจิ้ม

Rollup Dimension - จิ้ม

Conform Fact - ถ้าหลายๆ Fact table มี การวัดค่าที่เหมือนกัน ควรจะใช้ชื่อ Fact ให้เหมือนกัน แต่ถ้าวัดไม่เหมือนกัน ให้ตั้งชื่อคนละชื่อ

Based Fact Table – fact ที่เก็บความละเอียดสูงสุด

Factless Fact Table – fact ที่ไม่มีค่า measurement มีแต่้ค่าที่มาจา่ก dimension เท่านั้น เช่น ตารางที่ตอบคำถามว่า เราได้ขายสินค้าไหนบ้างที่ไม่อยู่ในโปรโมชั่น = ไม่มีตัววัดอะไรเลย มีแค่ค่าจาก dimension เท่านั้น

Fact Normalization - การแยก Fact Table ออกเป็นหลายๆตัว

Dimension Role-Playing - การกำหนดบทบาทของ Dimension ออกเป็นหลายๆบทบาทโดยมองผ่าน View

Junk Dimension - การแยกเก็บ fact ที่มีความสำคัญต่ำใน Fact Table ออกมาเป็น Dimension ใหม่

Multiple Currencies - เก็บค่าใน Dimension เป็นค่ามาตรฐานไว้ค่าหนึ่ง เมื่อต้องการเปลี่ยนเป็นค่าอื่นที่สามารถแปลงได้ให้เทียบกับ Dimension นี้

Accumulating Snapshot - การมองภาพรวมของระบบเพื่อสังเกตความสัมพันธ์ระหว่างกัน

GMROI - สูตรในการประเมินสินค้า ถ้ามีค่ามากๆ แปลว่าสินค้านั้นหมดไวและขายดี ควรเอามาเติมมากๆ ถ้ามีค่าน้อยแปลว่าขายไม่ค่อยออก ไม่ต้องเอามาเติมบ่อยๆก็ได้ มักใช้ใน Fact แบบ Periodic

สมุดจดศัพท์

blanket ครอบคลุม

pundit = professor

coherent = สอดคล้อง

emerged = appear

withstood = endure

tangible = ชัดเจน

guidance = advice

uncanny = weird

credible = น่าเชื่อถือ

resilient = flexible

inevitable = หลีกเลี่ยงไม่ได้

conform = ทำให้คล้ายกัน ทำให้เข้ากันได้

accumulate = สะสม

sediment = ตะกอน

อันนี้จดมาจากในห้อง

ข้อสอบ mid term DW

- เขียน 4 step design

- เขียน star schema

- เขียน query sql นิดหน่อย

- ให้พวก er มา

- คล้ายๆ quiz part 2

- มีตอบคำถามบ้าง เหมือน ตอบ quiz part 1

- หรืออาจจะมี star schema มา แล้วสั่งให้ออกรายงานให้หน่อย เราก็จะต้อง sql query ออกมา

- หรือให้ star schema ผิดๆมาแล้วให้แก้ให้มันถูก

เหมือนจะมีเฉลยอะไรซักอย่างงอกมาอยู่ข้างล่าง ลงไปอ่านหน่อยก็ดี

V

V

Good Luck : )

Time_Dim เป็น Role-Playing Dimension ต้องใช้ VIEW สร้าง RegisterDate_Dim กับ BillingDate_Dim ขึ้นมาก่อน

CREATE VIEW RegisterDate_Dim (Rgt_TimeKey, Rgt_TheDate, Rgt_DayOfWeek, …, Rgt_WeekOfYear)

AS SELECT TimeKey, TheDate, DayOfWeek, …, WeekOfYear

FROM Time_Dim

CREATE VIEW BillingDate_Dim (Bil_TimeKey, Bil_TheDate, Bil_DayOfWeek, …, Bil_WeekOfYear)

AS SELECT TimeKey, TheDate, DayOfWeek, …, WeekOfYear

FROM Time_Dim

ถ้าต้องการ join Diagnosis_Fact เข้ากับ Doctor_Dim และ Patient_Dim เพื่อแสดงชื่อของหมอ และชื่อคนไข้ที่ได้รับการรักษาจากหมอคนนั้นต่อครั้ง และค่าใช้จ่ายที่คนไข้ต้องเสียในครั้งนั้นมากกว่า 1,000 บาท

SELECT Doctor_Dim.FirstName, Patient_Dim.FirstName, Diagnosis_Fact.DiagnosisCost

FROM Diagnosis_Fact

INNER JOIN Doctor_Dim ON Diagnosis_Fact.Doctor_Key = Doctor_Dim.Doctor_Key

INNER JOIN Patient_Dim ON Diagnosis_Fact.Patient_Key = Patient_Dim.Patient_Key

WHERE Diagnosis_Fact.DiagnosisCost > 1000

ถ้าต้องการแสดงชื่อของคนไข้ทั้งหมดที่เคยเสียค่าใช้จ่ายรวมให้โรงพยาบาลเกิน 10,000 บาท เฉพาะที่เริ่มเข้ารับการบริการภายในในปี 2011

SELECT Patient_Dim.FirstName, SUM(Billing_Fact.TotalCost)

FROM Billing_Fact

INNER JOIN RegisterDate_Dim ON Billing_Fact.RegisterDate_Key = RegisterDate_Dim .Rgt_TimeKey

INNER JOIN Patient_Dim ON Billing_Fact.Patient_Key = Patient_Dim.Patient_Key

WHERE RegisterDate_Dim.Year = 2011

GROUP BY Patient_Dim.FirstName

HAVING SUM(Billing_Fact.TotalCost) > 10,000

Chapter 6

==========================================================

ช่วงนี้ระหว่างที่ี M@xlearn มันเดี้ยงก็ใช้ Link นี้ไปก่อน http://kdl.cpe.ku.ac.th/dw/

==========================================================

ETL

a tool that

  1. read data from one or more sources
  2. transforms the data so that it is compatible with a destination
  3. loads the data to the destination

มีทั้งแบบเสียเงินและแบบ opensource

ขั้นตอนคร่าวๆ

  1. สร้าง database, table
  2. ใช้ SQL insert เข้าไปใน relational DB ได้เป็น DW

ETL process กับความปวดตับ

  1. 70-80% ของเวลาทั้งหมดไปอยู่ที่ขั้นตอนนี้
  2. เจ้าของข้อมูลไม่ใช่เรา ไม่ใช่ว่าเราจะไปเอาข้อมูลเขามาง่ายๆ
  3. source จะกระจัดกระจาย (scatter) มีความแตกต่างกันในแต่ละ process
  4. quality ของ data ปกติจะ low มาก เราต้องใช้ความรู้เรื่อง data quality มาช่วย ← แพงตรงนี้!
  5. ถ้าเราไม่มี ETL tools ชีวิตจะเศร้ามาก ต้องเขียน script เอง
  6. ต้องทำ scheduling ได้ด้วย ไม่งั้นเราดึง data มาไม่ได้
  7. ต้องตั้ง audit report ได้ ต้องดู log ได้
  8. ดังนั้น เราต้องให้เวลาและความสำคัญกับ ETL มากๆ

Data Source

  1. ปกติแล้วไม่มีการ clean → dirty data
  1. เช่น ที่อยู่ไม่แยกช่อง ชื่อเป็นเลข 999999 เพศเป็นตัวเลข 20 ราคาติดลบ อายุพันกว่าปี = =)|||
  2. ใช้ data quality ซึ่งโดยปกติจะอยู่ใน ETL อยู่แล้วในการกำจัด noise
  3. ในการกำจัด dirty data อาจจะมีการถามว่าจะแก้เป็นอะไรดี ก็ต้องลองหาข้อมูลที่เหมาะสมที่จะ fill ลงไปใหม่เอา
  1. ปกติจะกระจายอยู่ในหลายๆตาราง เพราะว่า normalization ดังนั้น เราต้องใช้ join เข้ามา เราต้องการ denormalize คือเราต้อง join ทุกอย่างเข้ามาในตารางเดียวก่อน
  2. ถ้าไม่จำเป็นจริงๆตอนเก็บข้อมูลลง DB อย่าให้ User กรอกข้อมูลเอง จับมันเป็น Drop Down ซะ ← แก้ปัญหาต้นเหตุ

Star schema in DW

  1. surrogate key เกิดจากการที่เราสร้างคีย์ขึ้นมาในทุกๆครั้งที่เรา insert data หลักการทั่วไปคือ ต้อง load dimension มาก่อน จะได้รู้คีย์นี้ แล้วจึงโหลด fact table
  2. ถ้าเรา declare datatype ที่ต่างจาก source มากๆ เช่น ใน source ประกาศเป็น string ความยาว 60 แต่ใน warehouse เราประกาศเป็น string ยาว 30 (ระบบจะต้องตัดข้อมูลทิ้ง?หรือทำยังไงดี?) ก็จะยุ่งหน่อย เพราะว่าเราต้องปรับ (data transformation) เยอะ วิธีง่ายคือพยายาม declare ให้ใกล้เคียงกับต้นทาง
  1. ทำมาใกล้เคียงกันก็เหนื่อยตอน ETL น้อยหน่อย

เวลาทำแลป

  1. สร้าง database, table ตาม star schema
  2. เลือกว่าตรงนี้เอาข้อมูลจากตรงไหนของ source ดี
  1. ใช้ join เชื่อมกันก่อน
  2. คำนวณค่าให้เสร็จสรรพ
  3. แล้วค่อยดึงมาแสดง
  1. บางครั้งเราต้องใช้ data ข้างนอก เช่น product มีการแบ่งประเภทแบบไหน
  1. ต้องตามน้ำเค้าไป
  1. ลุย

==========================================================

ช่วงนี้ระหว่าง M@xlearn มันเดี้ยงก็ใช้ Link นี้ไปก่อน http://kdl.cpe.ku.ac.th/dw/ >> อยู่ใน dropbox แย้ว

==========================================================

Code ที่อยู่ใน source เวลาทำ warehouse เราจะใช้ lookup table ช่วย เพื่อ join ค่า code เหล่านั้นให้กลายเป็น text ที่แสดง report ได้ เช่น เพศ = 1 ให้เราเอา ไป join กับตาราง 1 = female , 2 = male ก็จะได้ text Female ออกมา

phase

  1. source table
  2. operation
  3. destination table

Open source Tools

  1. ETL
  1. apatar
  2. Kettle เป็น ETL ของ Pentaho
  1. BI
  1. แนะนำ Pentaho http://www.pentaho.com/

Special – Pentaho Workshop

Open Source + Support = Open Source Commercial

ที่ดังสุดคือ Pentaho รองลงมาจาก Pentaho ก็ Jaspersoft http://www.jaspersoft.com/

วิธีที่ง่ายที่สุดในการศึกษา คือ ต้องมีโจทย์ก่อน

master password ใช้กับ 3 อย่าง

  1. repository root
  1. user ชื่อ root
  1. BA server publish password
  1. solution report
  1. Enterprise console (admin console)
  1. user ชื่อ admin

นิยมเอาไปใช้เป็น analytics

อาจนำไปใช้ร่วมกับ R Project ได้ http://www.r-project.org/

Pentaho มีเครื่องมือ 5 ตัว

data model/source => interactive report

อันนี้เรียกว่าการทำ business view

cube เป็นการสร้าง model ข้อมูลขึ้นมา โดย user สามารถดึงออกมาได้ตามต้องการ

การออกแบบ warehouse ควรทำตามลักษณะของข้อมูล

โดยทั่วไป warehouse ควรทำแบบ column-base แล้วใช้ index เพื่อเพิ่มความเร็ว

Gartner’s Magic Quadrant for Business Intelligence Platforms 2012

http://www.gartner.com/technology/reprints.do?id=1-196WFFX&ct=120207&st=sb

Lecture 7 – Cube

Cube นั้นเป็น logical storage structure ของ dw ในแต่ละ cell เป็น measurement ที่เราคำนวณไว้ก่อนแล้ว เอามาตอบใน report ได้เลย เหมือนเป็น array 3 มิติ ที่มี index โดยแต่ละชั้นนั้นจะเป็น aggregated value จำนวนมากโดยเป็นการคำนวณไว้ให้ล่วงหน้าก่อนแล้ว เวลาผู้ใช้ลาก-วางนั้นจะออก report ได้เร็วกว่าการคำนวณสดๆ

ข้อดีของมันคือเอา dimension กับ measure มารวมกันเป็น model ที่ยืดหยุ่นที่ผู้ใช้สามารถ query report ต่างๆได้เอง คนใช้เค้าจะมองเป็นเป็นข้อมูลที่เค้าดึงมาแสดงได้ (ไม่ใช่ star schema ที่เราออกแบบ)

Cube เป็น subset ของ Data warehouse โดย warehouse หนึ่งอันสามารถเป็นได้หลาย cube / เป็นหลายๆ view ของ data warehouse มีหลายแบบ เช่น

  1. MOLAP ( Multi-Dimensional OLAP) เป็นของ Microsoft โดยมองเหมือนเป็น array ของทุก dimension แล้วใช้วิธี ? ในการดึงข้อมูลออกมา ข้อดีคือเร็วแต่เปลืองที่
  2. ROLAP มองเหมือนเป็น table และสามารถ query จาก sql-command ได้เลย ข้อดีคือใช้พื้นที่น้อยแต่ช้า

โดยทั่วไป MOLAP จะเร็วกว่า เพราะสามารถหยิบมาตอบได้เลย ไม่ต้องมานั่ง SUM ใหม่ แต่ว่าเปลืองที่กว่า เพราะเก็บเป็น array มันทุก dimension ซึ่งก็สามารถ compress cube ให้มันประหยัดที่ได้

สรุป ในทางปฏิบัติ ถ้าเพิ่งสร้างจะใช้ MOLAP ไปก่อน ถ้ากินที่เยอะๆ ไม่ไหวจะเคลียร์ค่อยย้ายไป ROLAP ทีหลัง

Cube ประกอบด้วย

  1. dimension
  1. slice
  2. dice
  1. member
  2. cell
  3. hierarchy
  1. drill-down
  2. roll-up
  1. level

วิธีการสร้าง Cube คร่าวๆ

  1. Define Dimensions and Hierarchies
  2. Identify Fact
  3. Process the Cube

การคำนวณ Cube นั้นไม่จำเป็นต้องสร้าง aggregation ทั้งหมด เพราะ

  1. เสียเวลา
  2. ทำให้ข้อมุูลมีขนาดใหญ่เกินความจำเป็น
  3. โดยทั่วไปจะเป็น Partial Aggregation คือคำนวณไว้บางส่วน เพราะจะได้ query ได้รวดเร็วและมีขนาด Cube ไม่ใหญ่จนเกินไป ยกเว้นแต่ว่ามีขนาดของ storage เพียงพอ ทำ full เลยก็ถือว่าโอเค

ลักษณะโดยทั่วไปของ Cube Aggregation

  1. created when a cube in process
  2. include all measures

Processing Cubes

  1. รับค่าจาก Star-Schema
  2. คำนวณ aggregationจากแต่ละ dimension

งานกลุ่ม

  1. present วันที่ 27
  2. ออกแบบ star, warehouse และ report
  1. เอาไว้ตัดสินใจเรื่องอะไร
  1. กลุ่มละ 4 คน
  1. อาทิตย์หน้าบอกว่าอยู่กับใคร
  2. ทำเรื่องอะไร
  1. อย่าเอาเรื่อง sales
  2. พร้อมอธิบายธุรกิจด้วย

Lecture 8 – ท่าแปลกๆ

Multi-value dimension

เทียบกับ hospital schema แล้ว จะเห็นว่าปกติเป็นความส้มพันธ์ระหว่าง dimension ไปหา fact table เป็น many to one คือ หมอหนึ่งคนสามารถตรวจคนไข้ได้หลายคน แต่ว่าเราไปหาหมอหนึ่งครั้งเราสามารถหาหมอได้แค่คนเดียว จึงขึ้นคีย์ของหมอหลายๆ row ของ fact table แต่ในความเป็นจริงแล้ว เราอาจจะตรวจโดยใช่หมอหลายคนในการตรวจหนึ่งครั้งก็ได้

ใช้ fix จำนวนค่าไม่ได้ เพราะเราไม่มีทางรู้ว่า เราจะใช้หมอกี่คนในการตรวจโรคหนึ่งครั้ง หรือคนไข้มารพ.ทีนึง จะตรวจกี่อย่าง

คำตอบคือต้องใช้ multi-value dimension ซึ่งมีความสัมพันธ์แบบ many-to-many

multi-value dimension คือ dimension ที่เก็บค่ามากกว่า 1 อย่างขึ้นไป

Healthcare possible dimension

  1. calendar date
  2. patient responsible party
  3. employer
  4. health plan
  5. payer เช่น ประกัน
  6. provider เช่น โรงพยาบาล คลินิก
  7. treatment
  8. drug
  9. diagnosis

ในความเป็นจริงเคสหนึ่งเคสอาจจะเกี่ยวข้องกับหมอหลายคนหรือหลายโรงพยาบาลได้

Healthcare billing

  1. นับเงินจาก
  1. คนไข้
  2. รพ.
  3. การตรวจ
  4. การรักษา
  5. วันที่
  1. ใบเสร็จจ่ายไปแล้วยัง
  2. ใช้ accumulating snapshot คือ fact table ที่มีหลายๆ date (role playing)
  3. อาจมีการใช้ role-play dimension
  4. degenerate dimension
  5. diagnosis key ใช้ multivalue dimension

Multi-value diagnosis

คนไข้ 1 คนสามารถตรวจโรคได้มากกว่า 1 อย่าง

ไม่นิยมการเก็บอะไรเป็น string ยาวๆ เช่น เก็บที่อยู่คนไข้เป็นสตริงยาวๆ แบบนี้จะดูอะไรไม่ได้เลย เก็บแยกดีกว่า

  1. Bridge Table *สำคัญสำหรับเทคนิคนี้*

ใช้ bridge table ช่วยจัด group การตรวจได้ ก็นั่งทำ combination ไป ถ้าตรวจได้ n อย่าง ก็มี 2^n group แล้วค่อยมี diagnosis dimension ธรรมดาบอกอีกทีว่ามันตรวจอะไรบ้าง (แอบ snowflake) และนอกจากนี้ เราอาจใช้ weighting factor ได้ เช่น การวินิจฉัยโรคบางอย่าง เราเน้นที่ผลการตรวจอันนึงสำคัญกว่าอย่างอื่น

ใน MS SQL Server รุ่นเก่าๆ มันอ่าน bridge table ตรงๆ ไม่ได้ ก็ต้องสร้าง dimension หลอกๆ มาเป็น key ดักหน้าไว้ก่อน แล้วค่อยตามด้วย bridge table ทีหลัง แต่รุ่น 2008 สามารถอ่าน bridge table ได้แล้ว

การสร้าง bridge table อยู่ในขั้นตอนการทำ ETL คือเราต้อง gen table นี้ขึ้นมา คือสุดท้ายแล้วเป็น many to one เหมือนเดิม แต่ว่าจำลอง multivalue ขึ้นมา จะโยงระหว่าง bridge มาหา dimension ใน bridge จะเก็บคีย์ไว้

ถ้าโปรแกรมเห็น bridge table ได้ ก็สบายไปกว่าครึ่ง ไม่ต้องมานั่งเขียน SQL เอง

เรื่องของบัญชี จะมีส่วนที่น่าสนใจอยู่คือ แต่ละบัญชีสามารถมีคนหลายคนได้ ตรงนี้ก็ต้องใช้ multivalue

Education มองเป็น multi-value ว่ามีการแบ่งช่วงเวลาสั้นๆ มา แล้ววิชานึงกินได้หลาย time slice

ข้อสอบจะมี schema ที่บอกลักษณะบางอย่างว่ามันเป็น multi-value แล้วเราต้องสร้าง bridge table ขึ้นมาเพื่อรองรับ multi-value ตัวนี้ให้ได้

ตัวอย่างจากเว็บ http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/

เป็นกรณีที่นักกีฬาคนนึงสามารถเล่นกีฬาได้หลายอย่าง ต้องการเก็บรายได้ของแต่ละคน จะเห็นว่ามันเป็น many-to-many ทำให้ต้องมี bridge อ้างไป โดยตรงตาราง Sports_bridge จะเป็นตารางที่เข้ามาแทรกระหว่าง many-to-many ให้กลายเป็น 1-to-many สองฝั่งแทน

เวลาเขียน SQL ต้องโยงจาก key ใน fact ไปหา key ใน detailed dimension

ใน MS SQL server สามารถบอกใน cube ได้เลยว่า มันมี bridge อยู่

ถ้าไม่ใช้ bridge ก็ได้ แต่จะเปลืองที่มากๆ

การเก็บข้อมูลที่เป็น string ยาวๆ ให้เก็บแยกย่อยๆๆๆๆ อาจจะต้องเขียน script ตัดคำเอง

ส่วนเรื่องของ slowly changing นั้น MS SQL server ก็รองรับนะ

แต่ว่าบางครั้ง ข้อมูลเปลี่ยนด้วย data rate ที่ไม่เท่ากัน คือจะไม่ static เหมือนเพศ เราต้องแยกเป็นสอง dimension เพราะเก็บตนละ rate แยกเป็น classic กับ mini dimension ซึ่ง mini จะเปลี่ยนบ่อยกว่า classic dim

mini dimension

เป็น one to many แตกออกมา

Variable-Depth Hierarchies

ปกติการทำ hierarchy นั้นจะมีความจำกัดในเรื่องของความลึกของชั้น แต่ว่าอันนี้จะเป็นการทำ variable depth and recursive ซึ่งถ้าจะต้องทำ จะต้องมีวิธีจัดเก็บใน DW คือ ให้เก็บเป็น dimension นึง แต่ว่า hierarchy แปลก คือทำเป็น bridge

มี SQL ให้ในหนังสือที่คำนวณเอายอดเงินมาตอบ

Query to make TimeBridge in U_Star

SELECT tiSK, tsSK

FROM dbo.TimeInterval, dbo.TimeSlice

WHERE CONVERT(TIME, dbo.TimeInterval.startTime) <= CONVERT(TIME, dbo.TimeSlice.startTime) AND

CONVERT(TIME, dbo.TimeInterval.endTime) >= CONVERT(TIME, dbo.TimeSlice.endTime)

Comments are closed.