บทที่ 10 Telecommunications and Utilities
description
Transcript of บทที่ 10 Telecommunications and Utilities
บทท่ี 10 Telecommunications and Utilities
สมาชกิกลุ่มนายจริพงษ์ วฒันธรรม 49050909นายนที เสง่ียม 49051022นายพนัส สนุทรไพบูลยก์ลุ 49051113นายสกิุจ เบญจางจารุ 49051253นายธนภัทร สวุรรณนิกรกลุ 49054190
Design Dimensional Model จากจุดท่ีมีความผิดปกติ
What’s wrong with this picture.
ใช้ Billing ของธุรกิจ Telecommunication เป็น Basis Case Study
Geographic Location Dimension
Introduce
สมมติใหค้ณุเป็นหน่ึงในทีมออกแบบ Data Warehouseของบรษัิทการสื่อสารไรส้ายขนาดใหญ่บรษัิทหนึ่ง
บรษัิทมแีนวคิดใหใ้ช้ Data Warehouse ในการบรหิารขอ้มูล
โดยทีมออกแบบได้ระบุ Core Business Process หลายๆอันและจำานวน Dimension ท่ีใช้
Telecommunication Case Study
Data Warehouse Bus Matrix
ฝ่ายบรหิารต้องการที่จะดู◦รายได้จากลกูค้า◦รายได้จากตัวแทนจำาหน่าย◦ รายได้จาก Rate Plan
ซึ่งทีมออกแบบรูส้กึวา่เป็นไปได้ท่ีจะนำาData Warehouse Bus Matrix
ขา้งต้นมาใชแ้ก้ปัญหาใน Business Process น้ี
Business Process
Billing Every Month
BillService Line 1 RatePlan1
Service Line 2 RatePlan1
Service Line 3 RatePlan2
Service Line 4 RatePlan3
Fact table ท่ีทีมงานออกแบบ โดยให้ Grain คือ 1 แถวแสดงถึง 1 Bill ใน
แต่ละเดือน
ตัวอยา่งปัญหาท่ีจะพบได้บอ่ยครัง้
คำาแนะนำาท่ีสามารถชว่ยในการคล่ีคลายปัญหาท่ีเกิดได้
การพจิารณาและตรวจสอบการออกแบบทั่วไป
Q: เรามกัจะได้คำาตอบท่ีไมส่อดคล้องกับคำาถาม จากทีมผู้พฒันา
A: ควรจะกำาหนด Grain ใหก้ระชบัและเขา้ใจง่าย
เพื่อใหท้ีมออกแบบกับผู้ประสานงานทางธุรกิจ
เขา้ใจตรงกัน
Granularity
ควรจะกำาหนด Granularity ใหล้ะเอียดท่ีสดุเท่านี้จะทำาได้ใน Business
Processท่ีสนใจอยู่
* การลงรายละเอียดขอ้มูลในระดับท่ีลึกท่ีสดุไมไ่ด้หมายความวา่เราจะได้ขอ้มูลที่มีความละเอียดจำานวนมากแต่เราต้องใช้ขอ้มูลระดับท่ีเหมาะสมกับการใชง้านต่างหาก
Granularity
Q: ความพยายามที่จะเพิม่ประสทิธภิาพและลด ความซบัซอ้นนัน้ บางครัง้ก็อาจจะทำาใหต้้องใส่
ขอ้มูลยอดรวมต่างๆไวใ้นFact Table ด้วย
A: ตรงนี้เป็นสว่นที่สรา้งปัญหา เน่ืองจากขอ้มูล ไมม่คีณุสมบตัิ additive (ไมส่ามารถบวกรวม
ได้ เชน่ วนั/เดือน/ปี) ซึ่งจะเกิดปัญหาในกรณีที่มี Bill ซำ้ากันทำาให้
ค่าyear-to-date รวมกันทำาใหค่้าที่ได้ไมส่ื่อ
ความหมาย
Fact Granularity
Q: การใช้ Snowflaking หรอื Normalization ในการจดัเก็บ Dimension Table จะชว่ยให้
ลดพื้นท่ี ในการเก็บขอ้มูลแต่จะทำาใหก้าร Query ชา้
A: ในแต่ละ Dimension จะเชื่อมต่อกับ Fact อยู่ โดยใช้ 1 Attribute ในการเชื่อมนัน้คือ Key
Dimension Granularity
Q: บางครัง้ทีมออกแบบมกัจะนำาขอ้มูลเวลาและวนั ท่ีแยกลงไปใน Fact ต่างๆซึ่งจรงิๆแล้วเป็น
เรื่องท่ีไมเ่หมาะสม
A: การนำาไปใสไ่วใ้น Fact ทำาใหย้ากท่ีจะรูว้า่เป็นวนัท่ีของอะไร◦ แนะนำาใหม้ี Date Dimension อันเดียว◦ โดยเลือกเฉพาะ Date ท่ีใชม้าใสใ่น Date Dimension
Date Dimension
นักออกแบบบางคนจะพยายามหลีกเล่ียงการใชง้านDate Dimension ◦สำาหรบัการแสดงขอ้มูลของพวกชว่งเวลาของแต่ละ
เดือนบนขอ้มูลแถวนึงของตาราง month fact ◦ มกีารเก็บขอ้มูลแยกไปเดือนๆไปทัง้หมด 12 เดือน◦ ปัญหาหลายๆอยา่ง เชน่ การเขยีนโค้ดท่ีไมย่ดืหยุน่ ตัวจดัการขอ้มูลนัน้ไมใ่ชเ่ป็น Database แต่เป็น
Application ไมม่ี Date Dimension ท่ีจะนำาขอ้มูลมาลงใสบ่น
ปฎิทินได้ Fixed Slot จะไมม่ปีระสทิธภิาพหากมขีอ้มูลมาก (ไม่
ครบทกุเดือน)
ใช้ Fixed Time-Series Bucket แทนDate Dimension
Q: พบวา่มี Dimension ใดที่มจีำานวนแถวใกล้ เคียงกับ Fact
A: เป็นสญัญาณเตือนวา่น่าจะมีDegenerate Dimension ซอ่นอยูใ่น Dimension ท่ีเราสรา้ง
Degenerate Dimension
การเก็บขอ้มูลการชำาระเงิน (Transaction) โดย เก็บเพยีง หมายเลขการชำาระไว้
เป็นการเก็บแบบ Degenerate Dimension บางครัง้ทีมออกแบบจะทำาการสรา้ง Dimension
แยกออกมา ซึ่งจะเก็บรายละเอียดต่างๆ เชน่ วนัที่ ประเภท
Degenerate Dimension
การระบุตัวตนและการใชร้หสัในDimension Table ควรจะสอดคล้องกันเพื่อใหง่้ายต่อการถอดรหสัเพื่อไมใ่หเ้กิดการเขา้ใจผิด
Dimension Decodes and Descriptions
แทนที่จะใช้ Key หรอื ID ท่ีมมีาใหกั้บDatabase เดิม แนะนำาใหส้รา้ง Surrogate Keys ไวใ้น Dimension◦ ขอ้มูลเพิม่เติมสามารถกลับไปดไูด้ท่ีบทท่ี 2
Surrogate Keys
Dimension ท่ีได้จะอยูร่ะหวา่ง 5 ถึง 15 Dimension
หากออกแบบแล้วได้ 2-3 Dimension อาจจะต้องไปหาขอ้มูลเพิม่เติมจากบทที่ 9
ถ้าหากออกแบบแล้วได้ถึง 25-30 Dimension นัน้สามารถศึกษาเพิม่ได้ท่ีบทที่ 2 และ 5 เพื่อลด
จำานวน Dimension
Dimension มากหรอืน้อยไปหรอืเปล่า?
เริม่พจิารณาจาก Granularity ของ Fact Table ◦ หน่วยท่ีเล็กท่ีสดุควรจะเป็นขอ้มูลของ Service Line
ในแต่ละ Bill ◦ สนใจท่ี Bill Dimension และ Service Line
ท่ีถกูเชื่อมโยงด้วย Service Line Number
* เปล่ียนหน่วยท่ีเล็กที่สดุเป็น หน่วยต่อ Service Line ต่อ Bill
Draft Design Exercise Discussion
การยา้ย Service Line Key เขา้ไปยงั Fact Table นัน้
ทกุครัง้ที่นำาขอ้มูลจรงิใน Bill มาใสเ่ขา้ไปใน Fact Table ขอ้มูลดังกล่าวจะถกูนำามาใสใ่น Bill Date Dimension
ด้วย Bill Date Dimension มจีำานวนขอ้มูลใกล้เคียงหรอื
เท่ากัน กับ Fact Table แก้ปัญหาด้วยการมองวา่ Bill Date Dimension เป็นDegenerate Dimension
Draft Design Exercise Discussion
การเชื่อมตารางท่ีซำ้าซอ้นกันที่ Sale Rep Dimension
และ Sale Org Dimension Sale Rep นัน้มคีวามสมัพนัธแ์บบ Snowflaked ซึ่ง Snowflaked นัน้ไมเ่ป็นท่ีต้องการ เราจงึยุบรวมตารางทัง้ 2 เขา้ด้วยกัน และใสข่อ้มูล
เพิม่ โดยเพิม่ Attributes ใน Sale Rep Dimension แล้วลบSale Org Key ออกจาก Fact Table
เดิมไมไ่ด้ออกแบบให้ Rate Plan เก็บขอ้มูลใน ลักษณะคำาอธบิาย
ขอ้มูลประเภทน้ีเป็นขอ้มูลท่ีมปีระโยชน์ แต่ใชพ้ื้นท่ีในการเก็บภายใน Fact Table ท่ีมากก
วา่การเก็บSurrogate Key ท่ีมกัเป็นตัวเลข
เราจงึเพิม่ Attribute เขา้ไปในRate Plan Dimension Table
Surrogate Key ท่ีใชย้งัไมม่คีวามสอดคล้องกันนัก(ID เชื่อมกับ Key)
หลายๆ Table ยงัคงใช้ System Key เป็นPrimary Key
เราจงึเพิม่ Surrogate Key สำาหรบัทกุๆDimension เขา้ไป
เป็น Primary Key แทนและ เป็น Foreign Keys ใน Fact Table
Year-to-Date อยูใ่น Fact Table โดยเริม่แรกนัน้เราใส่ Attribute Year-to-Date
น้ีเขา้ไปเพื่อใหง่้ายต่อการดึงขอ้มูลมาใช้ Year-to-Date น้ี จำาเป็นต้องมกีาร Update
บอ่ยๆ คือ ทกุวนั ทำาใหเ้ป็นสาเหตขุอง error ต่างๆ
จงึตัด Attribute น้ีออกไป โดยถ้าหากต้องการค่าYear-to-Date ก็สามารถหาได้จาก Date Dimension
ในท่ีสดุการออกแบบก็เสรจ็สมบูรณ์ หลงเหลือบางอยา่งที่ต้องจดัการต่อ เชน่
การรบัมอืกับการเปล่ียนแปลง Attributes ภายใน Dimension
Finally
โทรศัพท์แหง่หนึ่งซึ่งมกีารโยงสายเครอืขา่ยไปยงัจุดต่างๆ
มกัมกีารพฒันาด้าน Location ที่ดี ทำาใหใ้น Dimension ต่างๆ มขีอ้มูลด้าน
ภมูศิาสตรข์อง Location ท่ีแมน่ยำา อยูใ่นรูปของถนน เมอืง รฐั หรอืรหสัไปรษณีย์
หรอืแมก้ระทัง่ พกัิดละติจูด ลองจจูิด
Geographic Location Dimension
เราจะสรา้ง Single Master Location Table โดยใช้ เทคนิค Dimension Role-Playing
Location Table นัน้ควรจะเป็นสว่นหน่ึงของ◦service line telephone number◦อุปกรณ์เครื่องใชแ้ละอุปกรณ์ด้านเครอืขา่ย◦ท่ีดินและสิง่ปลกูสรา้ง◦service location◦ท่ีอยูจ่ดัสง่ของ◦สทิธผ่ิานทาง◦ท่ีอยูข่องลกูค้าและพนักงาน
Geographic Location Dimension
Location เป็นหน่ึงในไมก่ี่แบบท่ีเราสนับสนุนSnowflakes Outriggers
กรณีท่ีแต่ละ Dimension มี Location เป็นของตนเอง
แนะนำาให้ join จากแต่ละ Dimension ท่ีต้องการ อธบิาย Location ไปยงั Clone ของ Location
Table ซึ่งการสรา้ง Location Clone นัน้ เหมอืนกับท่ีได้อธบิายไวใ้นบทท่ี 5 ในการสรา้ง
Date Role-Playing Dimension
Location Outrigger
ขอ้ดีของการทำาเชน่น้ีคือเมื่อเราต้องการเพิม่เติมขอ้มูลด้าน ประชากรลงไปใน Geographic Dimension ในภายหลัง
เราจะได้ทำาในท่ีเดียว ถ้าหาก Location ในแต่ละ Dimension ซำ้ากันเพยีงเล็กน้อย
เราไมจ่ำาเป็นต้องเสยีเวลากับวธิน้ีี ในสถานการณ์น้ีเราจะยอมจา่ย Performance ในการแยก
Location ทัง้หมดท่ีแตกต่างกันออกไปอยูใ่นแต่ละDimension
เรายงัคงต้องยดึถือหลักการในการออกแบบสองขอ้ นัน่คือการ ใชง้าน และ ประสทิธภิาพ
Location Outrigger
Data Warehouse แบบธรรมดาจำานวนน้อยสามารถทำาได้อยา่งมากเพยีงแค่แสดงท่ีอยูเ่ท่านัน้
GIS Tool รบัขอ้มูลและแปลงขอ้มูลของท่ีอยูห่รอืเสน้ทางใหอ้ยูใ่นรูปพกัิดทางภมูศิาสตรไ์ด้
ชว่ยสง่เสรมิการออกแบบและเพิม่คณุสมบติัท่ีชว่ย ขยายการวเิคราะหข์อ้มูลได้อยา่งมากผ่าน GIS
GIS Tool ทำาใหเ้ราสามารถใชป้ระโยชน์จากขอ้มูลท่ีมอียู่
Leveraging Geographic Information System
เราสามารถสรา้งเครื่องมอืแสดงผลกราฟฟกิที่แสดงผลขอ้มูล
แบบสองมติิบนแผนที่ ซึ่งเราไมส่ามารถหาได้จากตารางหรอืรายงาน
เราสามารถตัง้คำาถามเชงิภมูศิาสตรกั์บขอ้มูล ใน Database “ ได้เชน่ หาสายเครอืขา่ยหรอื
สวติชท่ี์อยูภ่ายในหรอือยูใ่กล้กลุ่มประเทศที่” กำาหนด
Leveraging Geographic Information System
กระบวนการที่จะรวบรวมขอ้มูลเพื่อเพิม่คณุภาพ ของขอ้มูลนัน้ขึ้นอยูกั่บชนิดของ GIS Tool
◦เริม่จากการแปลงขอ้มูลดิบของที่อยูใ่หอ้ยูใ่นรูปของparsed form (parsed address)
◦Geocoder จะจบัคู่ parsed address เขา้ กับพกัิดทางภมูศิาสตรใ์น standard street
network database ◦ จะได้ location object ท่ีสามารถนำามา plot
และแสดงผล
Leveraging Geographic Information System
What is the IBM Telecommunications Data Warehouse?
IBM’s Telecommunications Data Warehouse (TDW) enables Operators to build data warehouse solutions to suit their specific needs. TDW includes all of the key components required for the core of a data warehousing solution.
The TDW comprises a flexible and scalable data warehouse infrastructure, enabling Operators to build a comprehensive data warehouse solution through phased development. This solution enables the rapid delivery of high business value by initially focusing on the business areas offering the greatest returns and feasibility, while building within a proven technical warehousing architecture.
The Telecommunications Data Warehouse Model (TDWM) provides Operators with both the content and the infrastructure to support the provision of clean, rationalized and easily accessible data from a central information repository. It allows Operators to exploit the potential of information previously locked in legacy systems and summarized in distributed data marts in accessible to most business users.
What is the Telecommunications Data Warehouse Model?
The Four Business Areas
The TDW Solution contains more than 20BST’s covering four
business areas.