บทท่ี 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.