ทฤษฎีต่างๆ หลังจบเรียนปริญญาโท

หัวข้อในทฤษฎีของ IT ที่ได้เรียนนั้น ส่วนใหญ่จะเป็นแนวคิดของอาจารย์ IT ต่างๆ ที่ได้ทำเทคโนโลยีและได้แสดงผลงานกันไว้ ซึ่งจะมีสัก 1 ใน 1000 จะนำไปเป็น Product แล้วจากนั้นจึงนำ Product มาศึกษาผลกระทบเป็นทฤษฎีกันต่อไปเรื่อยๆ และนำไปพัฒนาต่อ

สิ่งที่เจอจริงๆ ระหว่าง Product กับ Theory คือ บางครั้งการนำทฤษฎีจริงไปสร้าง Product นั้นเป็นไปไม่ได้ทั้งหมด บางทีมันอาจทำไม่ได้ตามจริงบนโลกความจริง หรือบางทีโลกความจริงก็มีขอบเขตในการทำทฤษฎีให้เป็นจริง

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

ส่วนปัญหาอีกอย่างที่ได้พบกับคนเรียนจบใหม่ การทำงานและการเรียน บ้างครั้งไม่ได้มาด้วยกัน ซึ่งบ้างครั้งเราเลือกการศึกษาที่ไม่ตรงกับตลาดแรงงาน ออกมาแล้วอาจหางานลำบาก

ซึ่งกรณี ที่ผมอยากแนะนำ คือ ให้เลือกศึกษาโปรเจคจบตามนี้

เลือกทฤษฎี สิ่งที่เรียนมาตลอดช่วงมหาวิทยาลัย ERP CRM SCM BI Datawarehouse Network Databased Programming Secuity WebApp BPM Cloud Embeded Moblie Admin VM

เลือกเครื่องมือ เหมือนกับเลือกว่าจะไปทางไหน Cisco Oracel SAP Java Mircsoft IBM

เลือกหัวที่ตัวเองชอบ อันนี้อาจยากสุด การศึกษาไรสักอย่างในมหาวิทยาลัยผมก็ยังมองเห็นข้อจำกัดเยอะเหมือนกัน แต่เมื่อได้ 2 ข้อบนแล้ว ก็ควรพยายามหาให้ได้ครับ


อย่างน้อยก็รับประกันได้ระดับนึงว่า อาจจะหางานได้ง่ายขึ้นระดับนึง


นั้นละครับ คิดว่าที่ผมลองเสนอแนะ น่าจะมีประโยชน์กับเพื่อนๆ พี่ๆ น้องๆ บ้างนะครับ

โชคดีครับ

Magic Quadrant

สมัยต่อผมเรียนปริญญาโท ในหลายๆเนื้อหาวิชานั้น ถ้าไม่อ้างอิงจากตำราหรือบทความวิชาการ ก็อ้างอิงจากบริษัททำวิจัยใหญ่ๆ ระดับโลกอย่างเช่น Gartner เป็นต้น

โดยสิ่งที่ผมชอบในงานวิจัยของ Gartner อย่างหนึ่งคือ Magic Quadrant ซึ่งเป็นการออกแบบการจัดลำดับสิ่งต่างๆ ของ Gartner ซึ่งผมว่ามันเชื่อถือได้ และ เห็นPosition หรือ ตำแหน่งสิ่งที่เราอยากอย่างชัดเจน แถมยังเห็นภาพคู่แข่งด้วย เพื่อไว้เปลี่ยนใจหันมาใช้ Application ตัวอื่นๆ แทน

ลองดูครับ ถ้านำไปไว้ในรายงานจะทำให้รายงานเราดูดีมีชาติตระกูลขึ้นเยอะครับ

Data model ในการออกแบบ Cube

การออกแบบ Cube นั้น ต้องใช้ Data model ซึ่ง Data model คือสิ่งที่ใช้ในทำให้ทราบถึงการออกแบบ ซึ่งมีหลายประเภทเช่น Data model ของ Relational Database หรือ ระบบต่างๆ ซึ่งแต่ละ Data model นั้น ก็จะมีเอกลักษณ์แต่ละตัวต่างกันออกไป ในส่วนระบบ Data Warehouse ที่มี Cube ไว้ ทำ OLAP นั้นก็มี Data Modeling ที่ใช้เพื่อในการออกแบบ Cube เฉพาะแบบของมัน โดยส่วนใหญ่ก่อนจะลง Cube จริง จะทำการออกแบบไว้ใน Data model นี้ก่อน ที่เรียกกันว่า Star schema ซึ่งเป็นแบบพื้นฐานที่สุด ของ Data Model ของ Cube

โดยหลัก ๆ การออกแบบ Data Modelของ Cube นั้นมี อยู่ 3 แบบ

Star schema นั้นเป็น Data Modeling ของ Cube นั้นเอง ที่มีรูปแบบเรียบง่ายไม่ซับซ้อน โดยมี Fact Table อยู่ตรงกลางหนึ่งตาราง และในตาราง ก็มีค่า 2 แบบ คือ Key กับ Measure และถูกเชื่อมโยงด้วย Dimension รอบข้างตามตัว Key ที่บรรจุไว้ใน Fact table โดยเก็บค่า Charatic หรือตัวอักษรไว้อธิบายความหมาย

Snowflake schema
โดยพื้นฐานต่าง ๆ เหมือนกับ Star schema คือ มี Fact table อยู่ตรงกลางและมี Dimension Tableล้อมรอบ แต่ต่างกันที่ ส่วน Dimension Table นั้น จะมีการเชื่อมโยงไปหา Dimension Table อื่นๆ ที่ต้องการข้อมูลเพื่อเติมจากใน Fact table

Galaxy schema
เป็น Data model ที่ซับซ้อนที่สุด เนื่องจากมี Fact table มากกว่า 1 ตัวขึ้น และสามารถใช้ Dimensions table ร่วมกันได้ และอาจมี Dimensions Table ที่แยกจากกัน

เพื่อใช้สร้าง Cube ให้นำไปทำ OLAP ได้อย่างมีประสิทธิภาพ การออกแบบ Data Model ให้ดีก่อนนั้นเป็นสิ่งสำคัญ เพื่อให้เราสามารถได้รายงานออกมาตามความต้องการของผู้ใช้จริง

องค์ประกอบของ Cube

Data modeling ของ Cube นั้น ประกอบด้วย 2 ส่วนคือ Fact Table กับ Dimension Table, Fact table

โดย Fact table คือ ตารางตั้งต้นของ dimensional modelหรือ Cube โดยจะบรรจุค่าที่ใช้วัดหรือตัววัดค่าเช่น ประสิทธิภาพของธุรกิจจากการทำธุรกิจ โดยจะเก็บข้อมูลไว้ 2 ประเภทได้แก่
1. ค่าตัวเลข ไว้เพื่อแสดงผลของค่า Dimension ต่างๆ ที่ดึงมา
2. ค่า Keys เพื่อใช้โยงไปหา Dimension Table ต่างๆ ตามที่มี Key ไว้ใน Fact table บ้างก็เรียก Key เหล่านี้ว่า Foreign key หรือ Surrogate key โดยใช้ key ดังกล่าวทำหน้าที่ ใน เชื่อมโยงไปหา Dimension Table ที่ได้ใช้ในการอธิบาย

The relational database table that contains values for one or more measures at the lowest level of detail for one or more dimensions (16, SQL.Server.2005.Analysis.Services.Step.By.Step)

Dimension Table

Dimension คือ ตารางที่ใช้อธิบายความหมายของค่าต่างๆ ของ Fact table โดยเชื่อมผ่าน Key จาก Fact Table นั้นเอง
A list of labels that can be used to cross-tabulate values from other dimensions (16, SQL.Server.2005.Analysis.Services.Step.By.Step)

Cube คือ

Cube หรือ OLAP Cube คือโครงสร้างข้อมูล (Data structure) รูปแบบหนึ่งเพื่อให้วิเคราะห์ข้อมูลได้เร็วขึ้น ซึ่งใช้กับ OLAP โดยส่วนใหญ่

ในการทำ OLAP นั้น ได้ใช้ Cube เป็นพื้นฐานในการวิเคราะห์ข้อมูลเป็นหลายมิติ หรือ dimensions นั้นเอง โดยส่วนใหญ่ Cube จะถูกสร้างในส่วนของ Data warehouse นั้นเอง เช่น SSAS ของ SQL Server หรือใน Business Information Warehouse ของ SAP นั้นเอง และถ้าระบบ Business intelligence นั้น จะนำ Cube ที่สร้างไปเป็นข้อมูลในการสร้างรายงานต่างๆ

โดยสามารถนำ Cube มาทำเป็น Array 2 มิติ เพื่อนำเสนอข้อมูลในมิติต่างๆได้

ในคำนิยามของ ที่ได้มีคนให้ไว้กับ Cube เช่น

Cube นั้นใช้อธิบายความสัมพันธ์ต่างๆ ผ่าน Fact table กับ Dimension Table
cube to describe what in the relational world would be the integration of the fact table with dimension tables. (18, SQL.Server.2005.Analysis.Services.Step.By.Step)

Cube เป็น กลุ่มของ กลุ่มตัววัดที่ตั้งแต่หนึ่งขึ้นไปโดยมีความสัมพันธ์กับ มิติ
A collection of one or more related measure groups and their associated dimensions (29, SQL.Server.2005.Analysis.Services.Step.By.Step)

ซึ่งเราสามารถลองเล่น Cube ได้จาก Tool ต่างๆนะครับ เช่น BW, SSAS, Essbase เป็นต้น

ความหมายของ OLAP

ในการเริ่มทำงาน OLAP เป็นคำที่พบต้องพบเจอบ่อยมากในการทำงาน ซึ่งหนังสือที่เกี่ยวกข้องกับ BI DSS Data warehouse จะบรรยายถึงคำว่า OLAP ซึ่งมันมาคู่กับ OLTP ซึ่งในบทความนี้เรามาสนใจเฉพาะ OLAP ก่อนแล้วกัน

ก่อนอื่นชื่อเต็ม ของ OLAP คือ online analytical processing เป็นรูปแบบการวิเคราะห์ข้อมูลที่นำมาใช้ในระบบ Data warehouse หรือ Business Intelligence โดยความหมายที่อื่นๆได้กล่าวไว้ดังนี้

ในวิกีพีเดียไทย Online Analytical Processing (OLAP) คือการใช้คำค้น (query) เพื่อค้นหาข้อมูลในคลังข้อมูลเหมือนในฐานข้อมูล เหตุผลที่เราไม่ค้นในฐานข้อมูล แต่มาทำในคลังข้อมูลแทนมีสองสาเหตุคือ
ความเร็ว
ความครอบคลุมของข้อมูลทั้งบริษัทที่มีอยู่ในคลังข้อมูล
http://th.wikipedia.org/wiki/%E0%B8%84%E0%B8%A5%E0%B8%B1%E0%B8%87%E0%B8%82%E0%B9%89%E0%B8%AD%E0%B8%A1%E0%B8%B9%E0%B8%A5

เดียวคิดว่าจะหาข้อมูลมาเพิ่มอีกนะครับ

คำนิยามของคลังข้อมูล (Definition of Data warehouse)

คลังข้อมูลหรือ Data warehouse นั้นเป็นระบบที่ใช้เก็บ รวม และจัดเรียงรูปแบบ ข้อมูลให้อยู่ในที่เดียวกัน โดยมีความสำคัญต่อการนำข้อมูลที่มีอยู่ในระบบองค์กรสักแห่งที่มีระบบ OLPT หลายระบบ มาทำให้ข้อมูลนั้นเป็นรูปแบบเดียวกัน อยู่ที่เดียวกัน โดยคำนิยามที่ผมหามาได้จากหลายๆที่ ได้กล่าวถึง Data warehouse ไว้ดังนี้

คลังข้อมูล เป็นระบบที่เก็บและรวมข้อมูลแต่ละช่วงเวลาจากระบบข้อมูลโดนใส่มิติ(dimensional)หรือที่เก็บข้อมูลที่ normalized
“A data warehouse is a system that retrieves and consolidates data periodically from the source systems into a dimensional or normalized data store” (Building a Data Warehouse: With Examples in SQL Server, Rainardi,1,2008)

คลังข้อมูลคือระบบที่ มีการแบ่งโครงสร้างตามเนื้อหา การรวมข้อมูล ไม่มีการเปลี่ยนแปลงของข้อมูล และ มีความสัมพันธ์กับเวลา โดยถูกเก็บไว้เป็นข้อมูลที่ใช้สนับสนุนการตัดสินใจของผู้บริหาร
“A data warehouse is a subject-oriented, integrated, nonvolatile, and time-variant collection of data in support of management’s decisions.” (Building the Data Warehouse, Inmon,29,2005)

คลังข้อมูลคือ กลุ่มกระบวนการและข้อมูลที่มีจุดประสงค์เพื่อรองรับการวิเคราะร์และการตัดสินใจทางธุรกิจ
“A data warehouse (DW) is the collection of processes and data whose overarching purpose is to support the business with its analysis and decision-making”.( A Manager’s Guide to Data Warehousing, Reeves,4,2009)

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

The Architected Environment

The Architected Environment เป็นแนวคิดเรื่องสถาปัตยกรรมของระดับข้อมูล ของ Bill Inmon ได้นำเสนอไว้ ซึงเป็นพื้นฐานของ Corporate Information Factory (CIF) และระดับของข้อมูลทั่วไปที่นำไปใช้ใน App ต่างๆ

ได้แบ่งข้อมมูลเป็น 4 ระดับ ได้แก่

the operational level.
โดยระดับนี้เป็นข้อมูลแบบเก็บบันทึก เปลี่ยนแปลง และแสดงจากระบบได้ เช่นพวกระบบ Transaction ทั้งหลาย ซึ่งอาจมีมาจากหลายๆ ระบบ ที่สำคัญคือสามารถเปลี่ยนแปลงได้ ทำให้บางครั้งการนำไปใช้อาจผิดพลาดได้ ซึ่งจะอยู่ในระดับของ OLTP หรือ Application ทั่วไป

the atomic ( the data warehouse) level. เป็นระดับที่ใช้เก็บประวัติข้อมูลทั้งหมด จาก operational level ซึ่งเราจะทราบหมดว่ามีการเปลี่ยนแปลงไรข้อมูลบ้าง ใช้ในส่วนของ Datawarehouse

the departmental (or the data mart) level. หรือใช้คำว่า data mart level, the OLAP level, the multidimensional DBMS level ซึ่งน่าจะคุ้นกับ 3 คำหลังมากกว่า ซึ่งเป็ระดับที่ข้อมูลที่ใช้จำเพราะอย่างไว้ เช่น ข้อมูลทางบัญชี การขาย โดยใช้แหล่งข้อมูลมาจาก the data warehouse
.
the individual level.ข้อมูลในระดับนี้ใช้เพื่อค้นหาข้อมูลต่างๆ หรือจะเป็นข้อมูลสำหรับค้นหาความรู้ต่างๆ ใช้สำหรับพวก Executive information systems (EIS) หรืออาจจะ BI ด้วยกันได้

บุคคลสำคัญของวงการ Data warehouse

ที่มาของ Data warehouse คนที่พูดเรื่อง Data warehouse คนแรก ในหนังสือหลายๆ เล่ม นั้นบอกว่าเค้าคือ Bill Inmon หรือ ชื่อเต็มคือ William Harvey Inmon

ซึ่งก่อนหน้ามีแนวคิดเกี่ยวกับ Data warehouse มาก่อนหน้า แต่ Bill Inmon เป็นคนกำหนดนิยาม โดยได้ออกหนังสือชื่อว่า Building the Data Warehouse

ซึ่งได้อธิบายปัญหาที่เกิดขึ้นในระบบจริง แล้วทำไมต้องมี Data warehouse ซึ่งผมคงได้มาเล่าให้ฟังในบทความต่อๆ ไป

ส่วนอีกคนที่ได้รับยอมเรื่องของ Data warehouse คือ Ralph Kimball ซึ่งได้เขียนหนังสือเรื่อง The Data Warehouse Toolkit ซึ่งจะอธิบายวิธีการนำ Data Warehouse ไปใช้ (หนังสือที่ Kimball เขียนมีหลายเล่ม แต่ผมหาอ่านได้เล่มเดียว)

โดยมีหนังสืออีกหลายเล่มหลายจากปี 2000 แต่ส่วนใหญ่ และก็ Application tool หลายตัว ที่เป็น Data warehouse ไม่ว่าจะเป็น SAP BW หรือ เจ้าอื่นๆ ก็จะอ้างอิงจาก 2 ท่านนี้ โดยตัวผมเองได้เจอจาก หนังสือของ BW 310 ได้พูดถึง Bill Inmon ไว้ 2 -3 ที่ และไปหนังสือ ของ SSAS ก็ กล่าวถึงไว้ เลยทำให้สนใจอยากรู้ จึงตามสืบ มาจนเข้าใจว่าเค้าเกี่ยวข้องอย่างไรกับ Data warehouse

ช่วงนี้ผมอ่านหนังสือ Building the Data Warehouse เลยเหมือนได้อารมณ์ว่ากำลังอยู่ในยุคตั้งต้นของ Data warehouse เลย แม้นิยาม การใช้งานจริงบางอย่าง ได้มีการเปลี่ยนแปลงไปแล้วบ้างตามกาลเวลาก็ตาม แต่มันทำให้เข้าใจได้ว่าปัญหาที่ทำให้เกิด Data Warehouse ขึ้นมาเพื่อแก้ไข ปัญหาอะไร

โดยส่วนอื่นๆ ของทฤษฎีผมคงเริ่มอธิบายใน บทความต่อๆ ไปนะครับ

อ้างอิง
http://en.wikipedia.org/wiki/Data_warehouse
http://en.wikipedia.org/wiki/Bill_Inmon
http://en.wikipedia.org/wiki/Ralph_Kimball

Dashboard คือ

เครื่องมือ หรือ Tool อีกตัวหนึ่ง ใน Business intelligence ก็คือ Dashboard หรือเรียกง่ายๆ คือ แผงหน้าปัด นั้นเอง

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

โดยส่วนใหญ่จะนำมาประยุกต์ใช้กับพวก เครื่องมือวัดผลทางธุรกิจ หรือ วัดผลทางองค์กร Preferment management ต่างๆ เช่น Balanced Scorecard, Enterprise Performance Management (EPM Business or Corporate Performance Management (BPM), Business Activity Monitoring (BAM), Six Sigma รวมไปถึงการนำมาแสดงค่า KPI ในส่วนงานต่างๆ ด้วย

โดยผู้พัฒนาเครื่องมือ Dashboard ในตลาดนั้นได้แก่ Business Objects, Cognos, Hyperion, and MicroStrategy. iViz Group, iDashboards, Noetix, QPR Software, and Theoris เป็นต้น