คลังขอมูล (Data Warehouse)

บทคัดยอ
ดาตาแวรเฮาส หรือคลังขอมูล คือฐานขอมูลขนาดใหญทรี่ วบรวมขอมูลทั้งจากแหลงขอมูล
ภายในและภายนอกองคกร โดยมีรูปแบบและวัตถุประสงค ของการจัดเก็บขอมูลแตกตางจากฐานขอมูล
ปฏิบัตการทั่วไป การพัฒนาระบบคลังขอมูลเริ่มจากการออกแบบฐานขอมูล ซึ่งวิธีการหนึ่งเรียกวา ระเบียบ
วิธี 9 ชั้นของ Kimball จะเนนทีก ่ ารออกแบบจากระบบงานยอยหรือดาตามารทของแตละระบบงานใน
องคกรกอนจึงนําสวนยอยๆ นั้นมารวมเปนระบบคลังขอมูลขององคกรตอไป ทั้งนี้กระบวนการหนึ่งที่สําคัญ
มากในการพัฒนาระบบคลังขอมูล คือการนําขอมูลจากแหลงขอมูลเขาสูดาตามารทของแตละระบบ หรือ
เรียกวาการแปลงขอมูล โดยจะตองกําหนดการสงขอมูล รวบรวมหรือสรางขอมูลภายนอก วางแผนและ
สรางรูทน ี การแปลงขอมูล จึงตรวจสอบความถูกตองของขอมูลที่ไดกอนนําเขาสูคลังขอมูลเพื่อใหเปน
ขอมูลที่เหมาะสมที่จะนําไปวิเคราะหตอไป

1. บทนํา
เนื่องจากสภาพเศรษฐกิจปจจุบันที่ยังไมจด ั วาพนภาระวิกฤตธุรกิจหลายประเภท จึงยังตองการ
การวิเคราะห วางแผน และตัดสินใจอยางถูกตอง รวดเร็วเพือ ่ ชวยใหธุรกิจสามารถดําเนินไปได ดังนั้น
ขอมูลจึงเปนปจจัยสําคัญยิ่งยวดตอการดําเนินการนั้น การใชขอมูลเปนเครือ ่ งมือสําคัญในการตัดสินใจการ
ลงทุนทางธุรกิจและวางแผนกลยุทธทางการตลาดเพื่อแขงขันกับคูแขงทางการคา ฉะนั้นก็อาจกลาวไดวา
การมีขอมูลมากทําใหมีโอกาสและมีชย ั เหนือคูแขงในระดับหนึ่ง แตทวาหากมองในทางกลับกัน การมี
ขอมูลจํานวนมากแตขาดการจัดเรียงใหเปนระบบยุงยากในการเขาถึงและคนคืน ธุรกิจอาจตองเสีย
คาใชจายจํานวนมหาศาลในการเก็บรักษาขอมูลเหลานั้นไวโดยไมจําเปน เพราะไมไดรับประโยชนจาก
ขอมูลที่มี นอกจากนี้หากมีการนําขอมูลมาวิเคราะหอยางผิดพลาดอาจจะกอใหเกิดผลเสียหายได ซึ่งเปน
การสูญเสียโอกาสทางธุรกิจไป เพราะฉะนั้นในยุคที่ผูบริหารมีความตองการใชขอมูล เพื่อการตัดสินใจมาก
ขึ้น การจัดระบบระเบียบขอมูล เพื่อนําเสนอขอมูลที่มค ี ุณคาและผานการกลัน ่ กรองแลวแกผูบริหารเพื่อใช
ในการตัดสินใจใหทันตอเหตุการณจึงเปนสิ่งที่จําเปนอยางยิง่
แนวความคิดของการสรางคลังขอมูลจึงเกิดขึ้นเพื่อเปนที่เก็บรวบรวมขอมูลสําคัญและจําเปนจากแหลง
ตางๆ ซึ่งเปนประโยชนตอการตัดสินใจของผูบ  ริหาร เพื่อใหผูบริหารสามารถเรียกใชขอมูลที่ตองการได
อยางรวดเร็วและมีประสิทธิภาพมากขึ้น ขอมูลเชิงบริหารนี้จะสามารถชวยลดปญหาที่เกิดจากการใชขอมูล
จากฐานปฏิบต ั ก
ิ าร (operational database) ซึง่ เปนการเก็บขอมูลในรูปแบบ transaction system ได ซึ่ง
โดยทั่วไปปญหาที่พบเมื่อตองการขอมูลทีช ่ ว ยในการตัดสินใจไดแก
- การเรียงขอมูลจากฐานขอมูลปฏิบัตก ิ าร ซึ่งมีขนาดใหญ ทําใหประสิทธิภาพของระบบลดลง
และทํางานไดชาลง
- ขอมูลที่นําเสนอมีรูปแบบเดียว ไมสามารถเปลี่ยนแปลงไดตามความตองการของผูบริหาร
- ไมสามารถหาคําตอบในเชิงพยากรณได
- ไมตอบสนองการทําคิวรีท ่ ซ
ี่ บ ั ซอนไดดีเทาที่ควร
- ขอมูลถูกจัดเก็บอยูตามฐานขอมูลของระบบงานตางๆ ซึ่งยากแกการเรียกใชและขาด
ความสัมพันธทางธุรกิจ

2. สิ่งทีค
่ วรพิจารณากอนสรางคลังขอมูล
เนื่องจากการลงทุนสรางคลังขอมูลขึ้นมาใชเพื่อสนับสนุนการทํางานขององคกรนั้นจําเปนตองมีคาใชจาย
ในการลงทุนมหาศาล ทั้งทีส ่ ามารถวัดออกมาเปนตัวเงินได เชนคาใชจา ยดานฮารดแวร ซอฟตแวร และ
infrastructure อื่นๆ ที่จําเปนตองใช สวนคาใชจายที่ไมเปนตัวเงิน แตมีความสําคัญอยางมากไดแก กําลัง
แรงงานที่เสียไปของทรัพยากรบุคคลขององคกรและเวลาทีใ่ ชในการพัฒนา ดังนั้น เมื่อองคกรตัดสินใจ
สรางคลังขอมูลขึ้นแลว ควรจะประสบความสําเร็จดวย ทั้งนี้ Poe ไดเสนอ The Big Eight หรือ 8 ประการที่
ควรใหความสนใจ โดยมีรายละเอียดดังนี้

1. ควรมีเปาหมายที่ชด
ั เจนรวมของการสรางระบบนี้ของคนในองคกร เหมือนการตอบคําถามวา
ทําไมคุณถึงคิดจะสรางคลังขอมูล? ซึ่งคําตอบขององคกร ทีจ ่ ะไดคือเปาหมายทีต
่ องการ โดย
ควรจะเขียนเปาหมายนี้ออกมาเปนลายลักษณอักษรที่ชด ั เจน เพื่อใหทีมพัฒนาไดเขาใจ
เปาหมายรวมกัน
2. ทําความเขาใจสถาปตยกรรมของระบบ เพื่อใหทมี พัฒนาเขาใจตรงกัน ในที่นี้หมายถึง blueprint
ที่แสดง E-R model รวมของระบบความเขาใจที่ตรงกันทําใหงานเดินไปไดเร็วขึ้น
3. เทคโนโลยี่ทใี่ ชควรอยูในวิสยั ที่เหมาะสม ทั้งดานของตัวเงินและความยากงายในการเรียนรู ทั้งนี้
หมายรวมทั้งฮารดแวร ซอฟตแวร และเครือขาย อาจตองมีการทดสอบและฝกอบรมกอนการใช
งานจริง
 4. ทีมงานตองมีวส
ิ ัยทัศนเชิงบวกในการทํางาน เนื่องจากทีมพัฒนามักมาจากสวนงานดาน
เทคโนโลยีสารสรเทศ แตในเนื้องานจริงๆ แลวผูใ ชขั้นปลายเปนสวนงานอืน ่ ๆ ขององคกร ดังนั้น
จึงจําเปนอยางยิ่งที่จะใหผใู ชขั้นปลายที่เปนเจาของงานเขามารวมทํางานดวยตั่งแตตนโครงการ
5. ตองมั่นใจไดวา ทีมพัฒนาเขาใจเปนอยางดีถงึ ความแตกตางกันระหวางฐานขอมูลปฏิบัติการและ
ฐานขอมูลสนับสนุนการตัดสินใจ
6. จัดใหมีการฝกอบรม โดยควรเปนการฝกอบรมกอนเริ่มโครงการ โดยเฉพาะอยางยิ่งการฝกอบรม
เกี่ยวกับเครื่องมือที่องคกรจะใชพัฒนา ทั้งนี้อาจเปนการฝกอบรมจากบริษท ั ผูขาย
7. ควรหาบุคลากรที่มีประสบการณในการพัฒนาคลังขอมูลเพื่อทําหนาที่เปนผูจ  ัดการโครงการหรือ
ถาในองคกรไมเคยมีประสบการณเลย อาจจางที่ปรึกษาที่มีความเชี่ยวชาญและมีประสบการณ
ดานนี้โดยเฉพาะมาชวยทีมพัฒนา
8. โปรแกรมที่จะใชนําเสนอขอมูลในคลังขอมูล ตองสามารถเรียนรูไดงายและผูใชสามารถใชงาน
ไดอยางมีประสิทธิภาพ

3.แนวคิดเกี่ยวกับคลังขอมูล
3.1 นิยามของคลังขอมูล
คลังขอมูล หมายถึง ฐานขอมูลขนาดใหญขององคกรหรือหนวยงานหนึ่งๆ ซึ่งเก็บรวบรวมขอมูลจาก
ฐานขอมูลระบบงานประจําวัน หรือเรียกอีกอยางวา operational database และฐานขอมูลอืน ่ ภายนอก
องคกร หรือเรียกวา external database โดยขอมูลทีถ
่ ูกจัดเก็บในคลังขอมูลนัน
้ มีวัตถุประสงคในการ
นํามาใชงานและมีลักษณะของการจัดเก็บแตกตางไปจากขอมูลในฐานขอมูลระบบงานอื่น โดยขอมูลใน
คลังขอมูลจะถูกนํามาใชเพื่อสนับสนุนการตัดสินใจบริหารงานของผูบริหาร โดยเฉพาะการเปนขอมูล
พื้นฐานใหกับระบบงาน เพื่อการบริหารงานอืน ่ เชน ระบบ DSS และระบบ CRM เปนตน

3.2 คุณลักษณะเฉพาะของคลังขอมูล
จากนิยามของคลังขอมูลที่บอกถึงความแตกตางกันระหวางคลังขอมูลกับฐานขอมูลปฏิบัตก ิ าร ซึ่งสามารถ
สรุปคุณลักษณะของคลังขอมูลไดดังนี้
1. Subject oriented หรือการแบงโครงสรางตามเนื้อหา หมายถึง คลังขอมูลถูกออกแบบมาเพื่อ
มุงเนนไปในแตละเนื้อหาทีส ่ นใจ ไมไดเนนไปที่การทํางานหรือกระบวนการแตละอยางโดยเฉพาะเหมือน
อยางฐานขอมูลปฏิบัติการในสวนของรายละเอียดขอมูลทีจ ่ ด
ั เก็บในระบบทัง้ สองแบบก็จะแตกตางกันไป
ตามความตองการใชงานดวยเชนกัน คลังขอมูลจะไมจาํ กัดเก็บขอมูลที่ไมมส ี วนเกี่ยวของกับการ
ประมวลผลเพื่อสนับสนุนการตัดสินใจ ในขณะที่ขอมูลนั้นจะถูกเก็บไวในฐานขอมูลปฏิบัติการหากมีสวนที่
เกี่ยวของกับกระบวนการทํางาน
2. Integration หรือการรวมเปนหนึ่ง ซึ่งถือไดวาเปนคุณลักษณะทีส่ ําคัญทีส ่ ด
ุ ของคลังขอมูล คือ
การรวบรวมขอมูลจากหลายฐานขอมูลปฏิบัตก ิ ารเขาดวยกัน และทําใหขอมูลมีมาตราฐานเดียวกัน เชน
กําหนดใหมีคาตัวแปรของขอมูลในเนื่อหาเดียวกันใหเปนแบบเดียวกันทั้งหมด
3. Time variancy หรือความสัมพันธกับเวลา หมายถึงขอมูลในคลังขอมูล จะตองจัดเก็บโดย
กําหนดชวงเวลาเอาไว โดยจะสัมพันธกับการดําเนินธุรกิจของหนวยธุรกิจนัน ้ เพราะในการตัดสินดานการ
บริหารจําเปนตองมีขอมูลเปรียบเทียบในแตละชวงเวลา แตละจุดของขอมูลจะเกี่ยวของกับจุดของเวลา
และขอมูลแตละจุดสามารถเปรียบเทียบกันไดตามแกนของเวลา
4. Nonvolatile หรือความเสถียรของขอมูล หมายถึงขอมูลในคลังขอมูลจะไมเปลี่ยนแปลงบอย
ไมวาจะเปนการเพิ่มเติมขอมูลใหม หรือการปรับปรุงแกไขขอมูลเดิมที่บรรจุอยูแลว ผูใชทําไดเพียงการ
เขาถึงขอมูลเทานั้น

4. สถาปตยกรรมคลังขอมูล (Data Wharehouse Architrcture- DWA)

DWA เปนโครงสรางมาตราฐานที่ใชบอย เพือ ่ ใหเขาใจแนวคิด และกระบวนการของคลังขอมูล
นั้นๆ ซึ่งโดยทั่วไปแลวคลังขอมูลแตละระบบอาจจะมีรูปแบบที่ไมเหมือนกันได เพื่อใหเหมาะสมกับองคกร
นั้นๆ ทั้งนี้สวนประกอบตางๆ ภายใน DWA ที่สาํ คัฯไดแก
1. Operational database หรือ external database layer ทําหนาที่จด ั การกับขอมูลในระบบงาน
ปฏิบัติการหรือแหลงขอมูลภายนอกองคกร
2. Information access layer เปนสวนที่ผใู ชปลายทางติดตอผานโดยตรง ประกอบดวยฮารดแวร
และซอฟตแวร ที่ใชในการแสดงผลเพื่อวิเคราะห โดยมีเครื่องมือชวย เปนตัวกลางทีผ ่ ูใชใชติดตอกับ
คลังขอมูล โดยในปจจุบันเครื่องมือที่ไดรับความนิยมเพิ่มขึ้นอยางรวดเร็วนัน ้ คือ Online Analytical
Processing Tool หรือ OLAP tool ซึ่งเปนเครือ ่ งมือที่มีความสามารถในการวิเคราะหทซ ี่ ับซอน และแสดง
ขอมูลในรูปแบบหลายมิติ
3. Data access layer เปนสวนตอประสานระหวาง Information access layer กับ operational layer
4. Data directory (metadata) layer เพื่อใหเขาใจถึงขอมูลไดงายขึ้น และเปนการเพิ่มความเร็วใน
การเรียกและดึงขอมูลของคลังขอมูล
5. Process management layer ทําหนาที่จดั การกระบวนการทํางานทั้งหมด
6. Application messaging layer เปนมิดเดิลแวร ทําหนาที่ในการสงขอมูลภายในองคกรผาน
ทางเคลือขาย
7. Data warehouse (physical) layer เปนแหลงเก็บขอมูลของทั้ง information data และ external
data ในรูปแบบที่งายแกการเขาถึงและยืดหยุน ได
8. Data staging layer เปนกระบวนการการแกไข และดึงขอมูลจาก external database

5. เทคนิคในการสรางคลังขอมูล
5.1 การเคลื่อนที่ของขอมูลในคลังขอมูล
ขอมูลที่จดั เก็บภายในคลังขอมูลมีการเคลื่อนที่ของขอมูล (information flow) 5 ประเภท ดังนี้
1. Inflow คือการนําขอมูลจากฐานขอมูลอื่นเขาสูคลังขอมูลทั้งฐานขอมูลภายในและภายนอก
องคกร โดยในขั้นนี้อาจมีการเปลี่ยนแปลงโรงสรางขอมูล การทํา denormalize การลบหรือการเพิ่มฟลด
เพื่อใหขอมูลทัง้ หมดอยูใ นเนื้อหาทีส ่ นใจเดียวกัน ในขั้นตอนนี้อาจใชเครื่องมือที่เรียกวา data warehouse
tool
2. Upflow เมื่อขอมูลที่เราตองการอยูในคลังขอมูลแลว ในบางครั้งอาจตองมีการเพิ่มคุณคา
ใหกับขอมูลดวยเพื่อใหขอมูลอยูในรูปแบบทีเ่ ปนประโยชนมากที่สด ุ ตอการนําเครื่องมือมาใช ซึ่งไดแกการ
จัดกลุมขอมูลหาคาทางสถิตท ิ ซี่ ับซอน จัดขอมูลใหอยูใ นรูปแบบหรือเทมเพลตมาตราฐาน
3. Downflow เปนขั้นตอนของการปรับปรุงเปลี่ยนแปลงขอมูลเกา และไมอยูในเนื่อหาที่องคกร
สนใจออกไปจากคลังขอมูลขององคกร
4. Outflow เปนขั้นตอนทีผ ่ ูใชเรียกใชขอมูลในคลังขอมูลผานเครื่องมือตางๆ โดยการเรียกใชอาจ
มีเพียงขอเรียกเปนครั้งคราวเปนประจําทุกวัน/เดือน หรือแมกระทั่งตองการแบบทันที
5. Metaflow ขอมูลที่จด ั เก็บในคลังขอมูลจะถูกทําขอมูลไวอีกชุดหนึ่ง เปนแหลงที่มาของขอมูล
นั้น หรือแมกระทั่งที่อยูของขอมูลนั้นในคลังขอมูลและขอมูลอื่นที่เกี่ยวของ

5.2 วิธีการออกแบบฐานขอมูลสําหรับคลังขอมูล
วิธีการนี้ถูกเสนอโดย Kimball ในป 1996 เรียกวาระเบียบวิธี 9 ชั้น หรือ Nine-Step Methodology โดย
วิธีการนี้เริ่มจากการออกแบบจากสวนยอยทีแ ่ สดงถึงแตละระบบงานขององคกร หรือเรียกอีกอยางหนึ่งวา
ดาตามารท (data mart) โดยเมือ ่ ออกแบบแตละสวนสําเร็จแลว จึงนํามารวมกันเปนคลังขอมูล ขององคกร
ในขั้นสุดทาย ซึ่งขั้นตอนทั้ง 9 ขั้นตอน มีรายละเอียดดังนี้
1. กําหนดดาตามารท คือการเลือกวาจะสรางดาตามารทของระบบงานใดบาง และระบบงานใด
เปนระบบงานแรกโดยองคกรจะตองสราง E-R model ที่รวมระบบงานทุกระบบขององคกรไว แสดงการ
เชื่อมโยงของแตละระบบงานอยางชัดเจน และสิ่งที่ตองคํานึงถึงในการเลือกระบบงานที่จะเปนดาตามาร
ทแรกนั้น มี 3 ปจจัยที่เกี่ยวของ ไดแก จะตองสามารถพัฒนาออกมาไดทน ั ตามเวลาที่ตอ  งการ โดยอยูใ น
งบประมาณที่กําหนดไวและตองตอบปญหาทางธุรกิจใหแกองคกรได ดังนัน ้ ดาตามารทแรกควรจะเปนของ
ระบบงานที่นํารายไดเขามาสูองคกรได เชน ระบบงานขาย เปนตน
2. กําหนด fact table ของดาตามารท คือกําหนดเนื่อหาหลักทีค ่ วรจะเปนของดาตามารท โดยการ
เลือกเอนทิตีหลักและกระบวนการที่เกี่ยวกับเอนทริตน ี ั้นๆ ออกมาจาก E-R model ขององคกร นั้นหมายถึง
วาจะทําใหเราทราบถึง dimension table ที่ควรจะมีดวย
3. กําหนดแอตทริบิวตที่จําเปนในแตละ dimension table คือการกําหนดแอตทริบวิ ตที่บอกหรือ
อธิบายรายละเอียดของ dimension ได ทั้งนี้แอตทริบิวตที่เปน primary key ควรเปนคาทีค ่ ํานวณได กรณีที่
มีดาตามารทมากกวาหนึ่งดาตามารทมี dimension เหมือนกัน นั่นหมายถึงวา แอตทริบิวตืใน dimension
นั้นจะตองเหมือนกันทุกประการ นั้นไมอาจจะแกไขปญหาการจัดเก็บขอมูลซ้ําซอน อันนํามาสูความ
แตกตางกันของขอมูลชุดเดียวกัน ปญหานี้จงึ เปนการดีทจ ี่ ะมีการใช dimension table รวมกันในแตละ fact
table ที่จาํ เปนตองมี dimension ดังกลาว โดยเรียก dimension table ลักษณะแบบนี้วา comformed และ
เรียก fact table วา fact constellation เราสามารถกําหนดขอดีของการใช dimension table รวมกันไดดังนี้
(1) แนใจไดวาในแตละรายงานจะออกมาสอดคลองกัน
(2) สามารถสรางดาตามารทในเวลาตางๆ กันได
(3) สามารถเขาถึงดาตามารทโดยผูพัฒนากลุม  อื่นๆ
(4) สามารถรวบรวมดาตามารทหลายๆ อันเขาดวยกัน
(5) สามารถออกแบบคลังขอมูลรวมกันได

4. กําหนดแอตทริบิวตที่จําเปนใน fact table โดยแอตทริบิวตหลักใน fact table จะมาจาก

primary key ในแตละ dimension table นอกจากนี้แลว ยังสามารถมีแอตทริบิวตทจ ี่ ําเปนอื่นๆ ประกอบอยู
ดวย เชน แอตทริบิวตที่ไดจากการคํานวณคาเบื่องตนที่จําเปนสําหรับการคงอยูของแอตทริบิวตอื่นใน fact
table เรียกอีกอยางหนึ่งวา measure การกําหนดแอตทริบวิ ตนี้ไมควรจะเลือกแอตทริบิวตทค ี่ ํานวณไมได
เชนเปนตัวหนังสือหรือไมใชตวั เลข เปนตน และไมควรเลือกแอตทริบิวตที่ไมเกี่ยวของกับเนื่อหาของ fact
table ที่เราสนใจดวย
5. จัดเก็บคาการคํานวณเบื้องตนใน fact table คือการจัดเก็บที่ไดจากการคํานวณใหเปนแอตทริ
บิวตใน fact table ถึงแมวาจะสามารถหาคาไดจากแอตทริบิวตอื่นๆ ก็ตาม ทัง้ นี้เพื่อใหการสอบถามมี
ประสิทธิภาพมากขึ้น สามารถทํางานดวยความเร็วที่เพิ่มขึ้น เนื่องจากไมตองคํานวณคาใหมทั้งหมด
ถึงแมวาจะเกิดความซ้าํ ซอนของขอมูลในการจัดเก็บบางก็ตาม
6. เขียนคําอธิบาย dimension table ทั้งนี้ก็เพื่อใหผใู ชสามารถใชงานดาตามารทไดอยางมี
ประสิทธิภาพเพราะเกิดความเขาใจอยางดีในสวนตางๆ
7. กําหนดระยะเวลาในการจัดเก็บขอมูลในฐานขอมูล โดยอาจจะเปนการจัดเก็บเพียงชวง
ระยะเวลา 1-2 ป หรือนานกวานั้น ขึ้นอยูกับความตองการขององคกร เนื่องจากองคกรแตละประเภทมีความ
ตองการในการจัดเก็บขอมูลตางชวงเวลากัน ทั้งนี้ขึ้นอยูกับความจําเปนหรือขอกําหนดในการดําเนินธุรกิจ
มีขอสังเกตอยู 2 ประการที่นาสนใจและสําคัญสําหรับการออกแบบแอตทริบิวตในเรื่องของการจัดเก็บ
ขอมูล ดังนี้
(1) ขอมูลที่ถูกจัดเก็บไวนานเกินไปมักเกิดปญหาการอาน หรือแปลขอมูลนัน ้ ๆ จากแฟม
หรือเทปเกา
(2) เมื่อมีการนํารูปแบบเกาของ dimension table มาใชอาจเกิดปญหาการเปลี่ยนแปลง
ของ dimension อยางชาๆ ได
8. การติดตามปญหาการเปลีย ่ นแปลงของ dimension อยางชาๆ คือ การเปลี่ยนเอาแอตทริบิวต
ของ dimension table เกามาใชแลวสงผลกระทบตอขอมูลปจจุบันของ dimension table โดยสามารถแบง
ประเภทของปญหาที่เกิดได 3 ประเภท ดังนี้
(1) เกิดการเขียนทับขอมูลใหมโดยขอมูลเกา
(2) เกิดเรคอรดใหมๆ ขึ้นใน dimension
(3) เกิดเรคอรดที่มที ั้งคาเกาและใหมปนกันไป
9. กําหนดคิวรี่เปนการออกแบบดานกานภาพเพื่อใหผูใชเกิดความสะดวกในการใชงานและ
สามารถทํางานไดอยางมีประสิทธิภาพเมื่อดําเนินการทั้ง 9 ขั้นตอนสําหรับแตละดาตามารทเสร็จแลว จึงจะ
นําทั้งหมดมารวมกันเปนภาพของคลังขอมูลขององคกรตอไป

5.3 การแปลงขอมูลเขาสูดาตามารท
เมื่อเราออกแบบฐานขอมูลสําหรับแตละดาตามารทเสร็จแลว ขั้นตอนตอไปที่สาํ คัญยิ่งก็คือการนําขอมูล
จากแหลงขอมูลไปแปลงใหอยูในแพลตฟอรมของฐานขอมูลที่ไดออกแบบไว นั่นก็คือการแปลงขอมูล
หรือ Extraction Transformation and Loading (ETL) นั่นเอง โดยที่คุณภาพของการแปลงขอมูลเปนสิ่ง
สําคัญมากสําหรับการสรางคลังขอมูล จะแตกตางกันไปตามคลังขอมูลที่แตละองคกรตองการ โดยที่การ
แปลงขอมูลหมายรวมตั้งแตการวิเคราะหแหลงขอมูล กําหนดการสงขอมูลรวบรวมหรือสรางขอมูล
ภายนอก วางแผนและสรางรูทน ี ของการแปลงขอมูล และตรวจสอบความถูกตองของขอมูลที่ไดสามารถ
สรุปเปนขั้นตอนไดดังนี้
1. วิเคราะหแหลงขอมูล เชน ปริมาณของขอมูล จํานวนและชนิดของการเขาถึงแหลงขอมูล
แพลตฟอรมและภาษาโปรแกรมที่ใช เปนตน
2. ยายขอมูลทีต
่ องการจากระบบเดิมมาไวในบริเวณที่ใชปรับแตงขอมูล หรือเรียกบริเวณนี้วา
staging area เพื่อนํามาเลือกเฉพาะสวนทีต ่ องการแปลงขอมูลและตรวจสอบความถูกตอง หรือการทําความ
สะอาดขอมูล
3. กําหนด primary key ของ fact table และ dimension table และกําหนด foreign key ระหวาง
fact table กับ dimension table
4. ยายขอมูลทีท่ ําความสะอาดแลวจาก staging area ลงสูเซิรฟ
 เวอรของดาตามารท
5. สราง metadata ของแตละดาตามารท โดยเก็บรายละเอียดของขอมูลการอัปเดตและสงออกไป
ไวในดาตามารท
6. ตรวจสอบความถูกตองของขอมูล ซึ่งจะตองกระทําตลอดทั้งกระบวนการแปลงขอมูลจําทําได
ดังนี้
(1) ตรวจสอบผลรวมทั้งหมดของจํานวนขอมูลที่ดึงมาจากแหลงขอมูลที่เพิม ่ เขาไป
(2) ตรวจแกขอมูลในระบบเดิมของแหลงขอมูล หรือในรูทีนของการแปลง ซึง่ ควรจะเก็บ
ขอมูลในการตรวจแกไวใน metadata ของการแปลงขอมูลดวย
(3) ตรวจสอบคาของขอมูลใหถูกตองในกระบวนการรวบรวมขอมูล
(4) ตรวจสอบผลรวมของขอมูลหลังจากยายขอมูลลงสูด  าตามารทแลว

6. สรุป
คลังขอมูลเปนการรวบรวมขอมูลจากฐานขอมูลของระบบงานปฏิบัติงานประจําวันขององคกร แลวนํามา
แปลงขอมูลใหอยูในรูปแบบ ที่เหมาะสมในการเก็บและสะดวกในการใชงาน แลวจึงนําขอมูลนั้นเขาไปเก็บ
ในคลังขอมูล
การพัฒนาหรือสรางคลังขอมูลจากฐานขอมูลจะตองมีการพิจารณาถึงองคืประกอบที่จาํ เปนในการสรางให
เหมาะสมดวย ทั้งนี้เพื่อใหเกิดความคุม
 คาในการลงทุนและเกิดประโยชนสูงสุดตอองคกร ถึงแมวา
เทคโนโลยีคลังขอมูล จะใหประสิทธิภาพในการใชขอมูลอยางมากก็ตาม แตสิ่งทีต ่ องคํานึงดวยคือ
ทรัพยากรที่องคกรจะตองทุมเทลงไปในการพัฒนาที่อาจจะเกิดขึ้นจนองคกรไมสามารถจะพัฒนาระบบนี้
จนสําเร็จ และนํามาใชงานได เกิดการลงทุนทีส ่ ูญเปลา ดังนั้นจึงตองมีการวางแผนควบคุมและจัดการให
รอบคอบ