คู่มือการทำเหมืองข้อมูลที่เป็นมิตรกับงบประมาณ

ต่างจากการเขียนโปรแกรมแอปพลิเคชันทั่วไปที่ฟังก์ชัน API เปลี่ยนแปลงทุกวัน โดยพื้นฐานแล้วการเขียนโปรแกรมฐานข้อมูลยังคงเหมือนเดิม Microsoft Visual Studio .NET เวอร์ชันแรกเปิดตัวในเดือนกุมภาพันธ์ พ.ศ. 2545 โดยมีเวอร์ชันใหม่ออกทุกๆ สองปี ไม่รวมรุ่น Service Pack การเปลี่ยนแปลงอย่างรวดเร็วนี้ทำให้บุคลากรด้านไอทีต้องประเมินแอปพลิเคชันของบริษัททุกๆ สองสามปี โดยปล่อยให้ฟังก์ชันการทำงานของแอปพลิเคชันไม่เสียหาย แต่มีซอร์สโค้ดที่ต่างไปจากเดิมอย่างสิ้นเชิง เพื่อให้ทันกับเทคนิคและเทคโนโลยีล่าสุดอยู่เสมอ

ไม่สามารถพูดได้เหมือนกันเกี่ยวกับซอร์สโค้ดฐานข้อมูลของคุณ แบบสอบถามมาตรฐานของ SELECT / FROM / WHERE / GROUP BY ซึ่งเขียนย้อนกลับไปในยุคแรก ๆ ของ SQL ยังคงใช้งานได้ในปัจจุบัน แน่นอน นี่ไม่ได้หมายความว่าไม่มีความก้าวหน้าใดๆ ในการเขียนโปรแกรมฐานข้อมูลเชิงสัมพันธ์ มีอยู่และ มีเหตุผลมากกว่าทางเทคนิค

เริ่มตั้งแต่สมัยที่ Bill Inmon และ Ralph Kimball เผยแพร่ทฤษฎีของพวกเขาเกี่ยวกับการออกแบบคลังข้อมูล ความก้าวหน้าในการเขียนโปรแกรมฐานข้อมูลได้มุ่งเน้นไปที่การป้องกันการสูญเสียข้อมูลอันมีค่าและดึงข้อมูลที่มีค่าทั้งหมดออกจากข้อมูล เมื่อ Inmon และ Kimball นำโลกของฐานข้อมูลมาสู่คลังข้อมูล การเปลี่ยนแปลงครั้งใหญ่ได้เกิดขึ้นกับเครื่องมือ ETL (Extract/Transform/Load) ที่ทำให้นักพัฒนาฐานข้อมูลเข้าถึงข้อมูลเมตาได้ง่าย และข้อมูลจากแหล่งฐานข้อมูลที่ไม่ใช่เชิงสัมพันธ์ ซึ่งยากต่อการทำงานด้วย ในอดีตที่ผ่านมา. สิ่งนี้เพิ่มปริมาณข้อมูลที่มีอยู่เพื่อดึงข้อมูลที่มีค่า และการเพิ่มขึ้นของข้อมูลที่มีอยู่นี้นำไปสู่ความก้าวหน้าในการประมวลผลข้อมูลผ่านคิวบ์ OLAP และอัลกอริธึมการขุดข้อมูล

การเพิ่มคลังข้อมูล ลูกบาศก์ OLAP และอัลกอริธึมการทำเหมืองข้อมูลให้กับสถาปัตยกรรมฐานข้อมูลของคุณ สามารถเพิ่มความคล่องตัวให้กับกระบวนการทางธุรกิจและให้รูปแบบที่ชัดเจนในข้อมูลของคุณ ซึ่งคุณอาจไม่เคยทราบมาก่อน ระบบอัตโนมัติยังสามารถมีผลกระทบอย่างลึกซึ้งต่อความสามารถทางธุรกิจอัจฉริยะ

อย่างไรก็ตาม ก่อนที่คุณจะเริ่มเพิ่มเครื่องมือและเทคโนโลยีใหม่ คุณควรตรวจสอบให้แน่ใจว่าฐานข้อมูลธุรกรรมถูกสร้างขึ้นอย่างเหมาะสม

ฐานข้อมูลธุรกรรม

ฐานข้อมูลธุรกรรมเป็นพื้นฐาน และหากฐานข้อมูลธุรกรรมของคุณไม่น่าเชื่อถือและแม่นยำ การเพิ่มสิ่งอื่นใดนอกเหนือจากนั้นคือสูตรสำหรับภัยพิบัติ

จุดสำคัญที่ควรคำนึงถึงเมื่อเพิ่มเลเยอร์เพิ่มเติมลงในฐานข้อมูลของคุณคือ ทุกโครงการจำเป็นต้องแสดงผลตอบแทนจากการลงทุน ซึ่งเป็นเหตุผลว่าทำไมจึงดีที่สุดที่จะใช้ประโยชน์สูงสุดจากสถาปัตยกรรมปัจจุบันของคุณก่อนที่จะเพิ่มเลเยอร์เพิ่มเติม เลเยอร์ทั้งหมดเหล่านี้ใช้ข้อมูลที่มาจากฐานข้อมูลธุรกรรม ในหลาย ๆ สถานการณ์ คุณสามารถรับผลลัพธ์เดียวกันได้เพียงแค่สอบถามฐานข้อมูลธุรกรรมของคุณ แน่นอน การอ่านรายงานทั้งหมดของคุณจากคลังข้อมูลหรือ OLAP cube เป็นวิธีที่เหมาะ แต่เมื่อองค์กรไม่พร้อมสำหรับระดับความซับซ้อนนั้น สิ่งที่สำคัญกว่าคือต้องตอบสนองความต้องการด้านการรายงานก่อน เมื่อตอบสนองความต้องการขั้นพื้นฐานในการรายงานแล้ว การเริ่มต้นการสนทนาเกี่ยวกับคลังข้อมูลที่เหมาะสม และอาจเป็นลูกบาศก์ OLAP จะเป็นประโยชน์ต่อธุรกิจได้ง่ายขึ้นมาก

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

โปรแกรมเมอร์ฐานข้อมูลชั้นยอดทุกคนจู้จี้จุกจิกเกี่ยวกับความสามารถในการอ่านของกระบวนงานที่เก็บไว้ มีความคล้ายคลึงกันบางประการในวิธีที่ผู้เชี่ยวชาญด้านฐานข้อมูลจัดรูปแบบการสืบค้น ซึ่งแตกต่างจากนักพัฒนาแอปพลิเคชัน โดยทั่วไป คีย์เวิร์ดและฟังก์ชันการรวมจะใช้ตัวพิมพ์ใหญ่ ในขณะที่ชื่อตารางและฟิลด์ใช้ตัวพิมพ์เล็กหรือตัวพิมพ์เล็ก นามแฝงของตารางมีความสัมพันธ์กับชื่อตารางจริง การจัดตำแหน่งของส่วนต่างๆ ของขั้นตอนการจัดเก็บมีรูปแบบบล็อกบางประเภท

ด้านล่างนี้คือตัวอย่างการสืบค้นที่ใช้รูปแบบที่อ่านได้

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

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

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

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

ETL (Extract Transform Load) และการรายงาน

เมื่อฐานข้อมูลธุรกรรมของลูกค้ามีคิวรีที่ทำงานได้อย่างถูกต้อง ขั้นตอนต่อไปคือการปรับปรุงกระบวนการทางธุรกิจ

วิธีที่ง่ายที่สุดในการระบุความต้องการของธุรกิจสำหรับกระบวนการ ETL หรือการรายงานอัตโนมัติคือการค้นหาว่าใครกำลังอ่านข้อมูลจากฐานข้อมูลธุรกรรม แล้วจัดการข้อมูลโดยใช้สเปรดชีต สเปรดชีตมีโครงสร้างเดียวกับตารางฐานข้อมูล ทั้งสองมีแถวและคอลัมน์ หากคุณมีผู้ใช้ปลายทางที่จัดการข้อมูลด้วยตนเอง คุณควรถามตัวเองว่า “ทำไมกระบวนการนั้นจึงไม่เป็นแบบอัตโนมัติ”

กระบวนการทางธุรกิจแบบอัตโนมัติให้ผลตอบแทนจากการลงทุนในทันที และควรพิจารณาเสมอก่อนที่จะไปยังโครงการที่มีราคาแพงกว่า เช่น คลังข้อมูล การระบุผู้ใช้ปลายทางที่จัดการข้อมูลผ่านสเปรดชีตอาจฟังดูง่าย แต่กระบวนการนี้มีข้อแม้

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

ระบบ ETL ที่สร้างมาอย่างดีควรให้ความสามารถในการย้อนรอยข้อมูลทั้งหมดที่โหลดในฐานข้อมูลธุรกรรมกลับไปยังไฟล์ต้นฉบับดั้งเดิม นี่เป็นส่วนสำคัญของสถาปัตยกรรมฐานข้อมูล หากคุณไม่ทราบวันที่/เวลาที่แน่นอนของการเพิ่มระเบียนแต่ละรายการ พร้อมด้วยชื่อของแหล่งที่มา (ชื่อผู้ใช้หรือชื่อไฟล์) ที่เพิ่มระเบียน แสดงว่าคุณไม่ได้เตรียมที่จะจัดการกับข้อมูลที่ไม่ถูกต้องที่โหลดเข้าสู่ฐานข้อมูลธุรกรรมของคุณ คุณควรถามตัวเองว่า "จะเกิดอะไรขึ้นถ้ามีคนส่งไฟล์ที่ไม่ดีมาให้เรา" คุณจะใช้เวลานานเท่าใดในการระบุบันทึกที่มาจากมัน

คลังข้อมูล

การออกแบบคลังข้อมูลมีสองทฤษฎี ความแตกต่างระหว่างทฤษฎี Inmon และ Kimball สามารถสรุปได้ดังนี้:

ทฤษฎี Inmon คือการพัฒนาคลังข้อมูลก่อนแล้วจึงสร้าง data marts เชิงมิติสำหรับการรายงานจากคลังข้อมูล ทฤษฎี Kimball คือการพัฒนา data marts เชิงมิติสำหรับการรายงานก่อนแล้วจึงรวมเข้าด้วยกันเพื่อสร้างคลังข้อมูล

คุณต้องการให้ลูกค้าได้รับผลตอบแทนจากการลงทุนที่เร็วที่สุดเสมอ การสร้าง data marts เป็นกระบวนการง่ายๆ คุณเริ่มต้นด้วยการสืบค้นหลังรายงานของคุณและเปลี่ยนจากการส่งคืนชุดผลลัพธ์เป็นการจัดเก็บชุดผลลัพธ์ในตารางถาวร คุณเพียงแค่เพิ่มชื่อ TRUNCATE TABLE ; INSERT INTO ก่อน คีย์เวิร์ด SELECT เดิม เมื่อคุณมีตาราง data mart ที่ใช้งานได้ไม่กี่ตาราง การระบุโอกาสในการรวม data marts ควรเข้าที่ ค้นหาแบบสอบถามรายงานที่ใช้รายการตารางเดียวกัน แล้วรวมรายการของเขตข้อมูล สิ่งนี้ต้องการคิวรีที่ซับซ้อนมากขึ้น โดยเฉพาะอย่างยิ่งเมื่อรายการตารางเพิ่มขึ้น อย่างไรก็ตาม ตราบใดที่คุณทดสอบการสืบค้นข้อมูลอย่างละเอียด การเปลี่ยนแปลงที่เพิ่มขึ้นแต่ละครั้งก็สามารถทำได้โดยไม่กระทบต่อกระบวนการทางธุรกิจปกติ

ทุกครั้งที่คุณปรับปรุงการออกแบบคลังข้อมูล Kimball คุณมีโอกาสที่จะแสดง ROI ให้กับลูกค้า นั่นเป็นเพราะคลังข้อมูลถูกสร้างขึ้นก่อนและ data marts การรายงานจะถูกสร้างขึ้นจากคลังข้อมูลแบบคงที่ ดังนั้น คุณจึงต้องเสียค่าใช้จ่ายส่วนใหญ่ในช่วงต้นของโครงการคลังข้อมูล

OLAP Cube

OLAP คิวบ์อาจเป็นประโยชน์ต่อองค์กรโดยการให้ข้อมูลรวมที่มีเวลาตอบสนองที่รวดเร็ว ความสามารถเจาะลึกเฉพาะกิจสำหรับผู้ใช้ปลายทาง และการทำเหมืองข้อมูล เมื่อคุณมีคิวบ์ OLAP ที่เหมาะสม คุณสามารถแยกค่าทุกบิตออกจากข้อมูลของคุณได้ OLAP คิวบ์ถูกสร้างขึ้นบนคลังข้อมูล แต่ใช้ภาษา MDX ที่แตกต่างจาก SQL ฐานข้อมูลมาตรฐาน นอกจากนี้ยังต้องใช้ความพยายามในการกำหนดค่าที่เกี่ยวข้องมากกว่าเซิร์ฟเวอร์ฐานข้อมูล ความซับซ้อนนั้นทำให้โปรเจ็กต์ OLAP มีราคาแพง อีกทั้งหานักพัฒนา MDX ที่มีประสบการณ์ได้ยาก

สถาปนิกข้อมูลบางครั้งเห็นคิวบ์ OLAP ที่มีอยู่โดยไม่มีอะไรมากไปกว่าแดชบอร์ดธรรมดาที่ใช้คิวบ์ โดยไม่มีกระบวนการเดียวที่ไม่สามารถแทนที่ด้วยคิวรี SQL คลังข้อมูล หรือรายงานสำเร็จรูป คิวบ์ OLAP สามารถให้เวลาตอบสนองเร็วกว่ารายงานสำเร็จรูป แต่ในสถานการณ์ส่วนใหญ่ ความแตกต่างจะเล็กน้อย คุณยังสามารถได้รับประโยชน์จากความสามารถในการเจาะลึก อย่างไรก็ตาม ก่อนที่จะให้ความสามารถเจาะลึกผู้ใช้ปลายทาง ควรใช้รายงานสำเร็จรูปที่มีอินเทอร์เฟซเฉพาะกิจที่คล้ายคลึงกัน

ซึ่งช่วยให้คุณบันทึกการสืบค้นข้อมูลเฉพาะกิจที่ผู้ใช้ปลายทางกำลังทำงาน จากนั้นคุณสามารถระบุรายงานสำเร็จรูปใหม่ที่ผู้ใช้ไม่ทราบว่าสามารถสร้างขึ้นได้ เนื่องจากเวลาตอบสนองและการปรับปรุงแบบเจาะลึกมักจะน้อยที่สุดเมื่อพัฒนาคิวบ์ OLAP ไม่จำเป็นต้องแนะนำให้กับลูกค้าจนกว่าพวกเขาต้องการสถาปัตยกรรมฐานข้อมูลที่สามารถจัดการกับการทำเหมืองข้อมูลที่เกี่ยวข้อง นี่คือช่วงเวลาที่คุณสามารถสร้างความประทับใจให้กับลูกค้าและแสดงบางอย่างเกี่ยวกับธุรกิจที่พวกเขาอาจไม่เคยรู้จักมาก่อนหากไม่มีสถาปัตยกรรมฐานข้อมูลที่มีประสิทธิภาพ

ดังที่ได้กล่าวไว้ก่อนหน้านี้ การสร้างคิวบ์ OLAP อาจเป็นสิ่งที่ท้าทาย เป็นนโยบายที่ดีที่จะพิจารณาลูกบาศก์ OLAP แบบไฮบริด PowerPivot ของ Microsoft Excel นำเสนอเครื่องมือการทำเหมืองข้อมูลที่ใช้งานง่าย โดยไม่มีความซับซ้อนของ OLAP cube แบบสมบูรณ์ ข้อเสียเปรียบหลักของไฮบริดคือไม่มีเวลาตอบสนองเท่ากัน อย่างไรก็ตาม ข้อได้เปรียบที่สำคัญคือการสร้างรายงานการทำเหมืองข้อมูลโดยใช้ Excel ทำได้ง่ายกว่าเมื่อเทียบกับการใช้ MDX เมื่อทำเหมืองข้อมูล มีรายงานสามฉบับที่เป็นประโยชน์ เราสามารถดูตัวอย่างในโลกแห่งความเป็นจริงและวิธีตีความได้

รายงานทั้งหมดเหล่านี้มาจากแอปพลิเคชันซื้อขายวันอัตโนมัติที่สร้างโดยผู้เขียน

การรายงานด้วยภาพ

รายงานพล็อตกระจาย

รายงานพล็อตกระจายเป็นรายงานระดับรายละเอียดที่เปรียบเทียบสองตัวแปร การเพิ่มสีและขนาดให้กับจุดจริงช่วยให้เห็นภาพผลลัพธ์จริงที่สัมพันธ์กับตัวแปรเหล่านั้น

รายงานกล่องและหนวด

รายงานนี้สรุปค่า x และ y จากรายงานพล็อตแบบกระจาย ค่าแกน x จะถูกแยกออกเป็นชุดของที่เก็บข้อมูล

ปลายของแต่ละหนวด (บรรทัด) แสดงถึงค่าผิดปกติ แถบสีเหลืองและสีฟ้าอ่อนแสดงถึงช่วงเบี่ยงเบนมาตรฐานด้านบนและด้านล่าง

แบบจำลองการถดถอยเชิงเส้น

รายงานนี้แสดงความสัมพันธ์ระหว่างค่าแกน x และ y พร้อมกับการปรับเส้นให้เรียบ ซึ่งสามารถแสดงด้วยสูตรทางคณิตศาสตร์ รวมค่า R กำลังสองเพื่อแสดงว่าสหสัมพันธ์มีความน่าเชื่อถือเพียงใด

บทสรุป

เมื่อบริษัทของคุณเติบโตขึ้น โดยปกติฐานข้อมูลของคุณก็จะเติบโตเช่นกัน

ในขั้นต้น องค์กรส่วนใหญ่ไม่ต้องการผู้เชี่ยวชาญด้านฐานข้อมูลหรือบริษัทด้านวิทยาศาสตร์ข้อมูลโดยเฉพาะเพื่อจัดการกับความต้องการของพวกเขา พวกเขามีพนักงานไอทีที่รับผิดชอบหลายอย่างหรืออย่างที่พูดกันว่า "สวมหมวกหลายใบ" สิ่งนี้ใช้ได้จนถึงจุดหนึ่ง แต่ในที่สุด คุณต้องนำผู้เชี่ยวชาญเข้ามา

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