หลักสามประการของการพัฒนาคลังข้อมูล

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

การนำคลังข้อมูล Business Intelligence ไปใช้งาน

แม้ว่าเกณฑ์สำหรับคลังข้อมูลข่าวกรองธุรกิจที่ประสบความสำเร็จจะแตกต่างกันไปตามโครงการ แต่ต้องมีข้อกำหนดขั้นต่ำบางประการและจำเป็นในทุกโครงการ ต่อไปนี้คือรายการของแอตทริบิวต์หลักที่มักพบในคลังข้อมูลทางธุรกิจอัจฉริยะที่ประสบความสำเร็จ:

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

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

คลังข้อมูลคืออะไร?

ก่อนที่จะเจาะลึกแนวคิดคลังข้อมูลต่างๆ สิ่งสำคัญคือต้องเข้าใจว่าจริงๆ แล้วคลังข้อมูลคืออะไร

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

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

มีองค์ประกอบหลายอย่างของคลังข้อมูล และไม่ใช่แค่ฐานข้อมูล:

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

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

หลักการ Data Warehouse ประการแรก: Data Quality Reigns Supreme

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

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

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

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

หลักการคลังข้อมูลที่สอง: พลิกสามเหลี่ยม

รูปนี้แสดงให้เห็นถึงการแบ่งความพยายามในการใช้งานและการใช้งานคลังข้อมูลส่วนใหญ่

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

หลักการประการที่สองของการพัฒนาคลังข้อมูลคือการพลิกสามเหลี่ยมดังที่แสดงไว้ที่นี่

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

คุณสามารถปฏิบัติตามหลักการนี้โดยปฏิบัติตามวิธีการพัฒนาแบบเพิ่มหน่วยเมื่อสร้างคลังสินค้าเพื่อให้แน่ใจว่าคุณส่งมอบฟังก์ชันการผลิตได้โดยเร็วที่สุด การปฏิบัติตามกลยุทธ์ data mart ของ Kimball หรือวิธีการออกแบบคลังข้อมูล Data Vault ของ Linstedt จะช่วยให้คุณพัฒนาระบบที่สร้างขึ้นทีละส่วนในขณะที่คำนึงถึงการเปลี่ยนแปลงอย่างราบรื่น ใช้เลเยอร์ความหมายในแพลตฟอร์มของคุณ เช่น คิวบ์ MS SSAS หรือแม้แต่ Business Objects Universe เพื่อให้อินเทอร์เฟซทางธุรกิจที่เข้าใจง่ายกับข้อมูลของคุณ ในกรณีของอดีต คุณจะมีกลไกง่ายๆ สำหรับผู้ใช้ในการสืบค้นข้อมูลจาก Excel ซึ่งยังคงเป็นเครื่องมือวิเคราะห์ข้อมูลยอดนิยม

การรวมเครื่องมือ BI ที่สนับสนุน BI แบบบริการตนเอง เช่น Tableau หรือ PowerBI จะช่วยปรับปรุงการมีส่วนร่วมของผู้ใช้เท่านั้น เนื่องจากขณะนี้อินเทอร์เฟซไปยังข้อมูลการสืบค้นมีความเรียบง่ายอย่างมากเมื่อเทียบกับการเขียน SQL

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

หลักการคลังฐานข้อมูลที่สาม: Plug and Play

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

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

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

ตัวอย่างเช่น ประสิทธิภาพของ ETL ได้รับการปรับปรุงอย่างมากเมื่อใช้กระบวนงานที่จัดเก็บไว้ในฐานข้อมูลเพื่อสร้างข้อมูลการวิเคราะห์ธุรกิจใหม่ ซึ่งต่างจากการดึงข้อมูลและประมวลผลข้อมูลภายนอกฐานข้อมูลโดยใช้ Python หรือ SSIS ในส่วนที่เกี่ยวกับเลเยอร์การรายงาน เครื่องมือการแสดงภาพจะนำเสนอฟังก์ชันบางอย่างที่ไม่พร้อมใช้งานในผู้อื่น—เช่น Power BI รองรับการสืบค้น MDX แบบกำหนดเอง แต่ Tableau ไม่รองรับ ประเด็นของฉันไม่ใช่เพื่อสนับสนุนการละทิ้งขั้นตอนการจัดเก็บหรือการหลีกเลี่ยงคิวบ์ SSAS หรือ Tableau ในระบบของคุณ ความตั้งใจของฉันเป็นเพียงการส่งเสริมความสำคัญของการมีสติในการตัดสินใจใดๆ เพื่อเชื่อมโยงแพลตฟอร์มของคุณเข้ากับเครื่องมืออย่างแน่นหนา

หลุมยุบที่เป็นไปได้อีกประการหนึ่งอยู่ในชั้นการรวม มันง่ายมากที่จะใช้เครื่องมือเช่น SSIS สำหรับการรวมข้อมูลของคุณ เนื่องจากความสามารถในการดีบักหรือความง่ายในการใช้งานกับแพลตฟอร์ม SQL Server อย่างไรก็ตาม การย้ายแพ็กเกจ SSIS หลายร้อยรายการไปยังเครื่องมืออื่นจะกลายเป็นโครงการที่มีราคาแพงมาก ในกรณีที่คุณทำ "EL" เป็นส่วนใหญ่ ให้ใช้เครื่องมือทั่วไปในการประมวลผลของคุณ การใช้ภาษาการเขียนโปรแกรมเช่น Python หรือ Java เพื่อเขียนตัวโหลดทั่วไปหนึ่งตัวเพื่อโหลดเลเยอร์การจัดเตรียมของคุณจะช่วยลดแพ็คเกจ SSIS แต่ละรายการที่คุณต้องการได้ แนวทางนี้ไม่เพียงแต่ช่วยลดค่าใช้จ่ายในการบำรุงรักษาและการย้ายในอนาคต แต่ยังช่วยให้กระบวนการออนบอร์ดข้อมูลในแง่มุมต่างๆ เป็นไปโดยอัตโนมัติ โดยไม่ต้องเขียนแพ็คเกจใหม่ (เชื่อมโยงกับหลักการที่ 2)

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

ห่อ

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

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