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

การสร้างแบบจำลองคลังข้อมูลไม่ได้แยกแยะระหว่างข้อมูลที่ดีและไม่ดี (“ไม่ดี” หมายถึงไม่สอดคล้องกับกฎทางธุรกิจ) ^{[ 1 ]}สิ่งนี้สรุปได้ในข้อความที่ว่าคลังข้อมูลจัดเก็บ “ ข้อเท็จจริงเวอร์ชันเดียว ” (ซึ่งDan Linstedt กล่าว ไว้ว่า “ข้อมูลทั้งหมด ตลอดเวลา”) ซึ่งแตกต่างจากการปฏิบัติในวิธีการคลังข้อมูลอื่นๆ ที่จัดเก็บ “ ความจริงเวอร์ชันเดียว ” ^{[ 2 ]}โดยที่ข้อมูลที่ไม่สอดคล้องกับคำจำกัดความจะถูกลบออกหรือ “ทำความสะอาด” คลังข้อมูลองค์กรแบบคลังข้อมูลให้ทั้งข้อเท็จจริงเวอร์ชันเดียวและแหล่งที่มาของความจริงเพียงแหล่งเดียว^{[ 3 ]}

วิธีการสร้างแบบจำลองได้รับการออกแบบให้มีความยืดหยุ่นต่อการเปลี่ยนแปลงในสภาพแวดล้อมทางธุรกิจที่ข้อมูลที่ถูกจัดเก็บมาจาก โดยการแยกข้อมูลเชิงโครงสร้างออกจากคุณลักษณะเชิง พรรณนาอย่างชัดเจน ^{[ 4 ]} Data vault ได้รับการออกแบบมาเพื่อเปิดใช้งาน การโหลด แบบขนานให้มากที่สุดเท่าที่จะเป็นไปได้^{[ 5 ]}เพื่อให้การใช้งานขนาดใหญ่มากสามารถขยายขนาดได้โดยไม่ต้องมีการออกแบบใหม่ครั้งใหญ่

ต่างจากสคีมาดาว ( การสร้างแบบจำลองมิติ ) และแบบจำลองเชิงสัมพันธ์ แบบคลาสสิก (3NF) คลังข้อมูลและการสร้างแบบจำลองแองเคอร์นั้นเหมาะสมอย่างยิ่งสำหรับการบันทึกการเปลี่ยนแปลงที่เกิดขึ้นเมื่อระบบต้นทางมีการเปลี่ยนแปลงหรือเพิ่มเติม แต่ถือเป็นเทคนิคขั้นสูงที่ต้องใช้สถาปนิกข้อมูลที่มีประสบการณ์[ 6 ^{]ทั้งคลัง}ข้อมูลและแบบจำลองแองเคอร์เป็นแบบจำลองตามเอนทิตี^{[ 7 ]}แต่แบบจำลองแองเคอร์มีแนวทางที่เป็นมาตรฐานมากกว่า

ในช่วงแรก Dan Linstedt เรียกเทคนิคการสร้างแบบจำลอง ซึ่งต่อมากลายเป็น Data Vault ว่าสถาปัตยกรรมคลังสินค้าพื้นฐานทั่วไป^{[ 8 ]}หรือสถาปัตยกรรมการสร้างแบบจำลองพื้นฐานทั่วไป^{[ 9 ]}ใน การสร้างแบบจำลอง คลังข้อมูลมีสองตัวเลือกที่แข่งขันกันอย่างเป็นที่รู้จักกันดีสำหรับการสร้างแบบจำลองเลเยอร์ที่จัดเก็บข้อมูล ไม่ว่าคุณจะสร้างแบบจำลองตามRalph Kimballโดยใช้มิติที่สอดคล้องกันและEnterprise Data Busหรือคุณจะสร้างแบบจำลองตามBill Inmonโดยใช้ฐานข้อมูลที่ ได้รับ การทำให้เป็นมาตรฐาน^{[ 10 ]}ทั้งสองเทคนิคมีปัญหาเมื่อต้องรับมือกับการเปลี่ยนแปลงในระบบที่ป้อนข้อมูลให้กับคลังข้อมูล สำหรับมิติที่สอดคล้องกัน คุณต้องทำความสะอาดข้อมูล (เพื่อให้สอดคล้องกัน) ซึ่งเป็นสิ่งที่ไม่พึงประสงค์ในหลายกรณี เนื่องจากจะทำให้ข้อมูลสูญหายไปอย่างหลีกเลี่ยงไม่ได้ Data Vault ถูกออกแบบมาเพื่อหลีกเลี่ยงหรือลดผลกระทบของปัญหาเหล่านั้นโดยการย้ายไปยังพื้นที่ของคลังข้อมูลที่อยู่นอกพื้นที่จัดเก็บข้อมูลในอดีต (การทำความสะอาดจะทำใน Data Marts) และโดยการแยกรายการโครงสร้าง (คีย์ธุรกิจและการเชื่อมโยงระหว่างคีย์ธุรกิจ) ออกจากคุณลักษณะเชิงพรรณนา

แดน ลินสเตดท์ ผู้คิดค้นวิธีการนี้ อธิบายฐานข้อมูลที่ได้ดังนี้:

"โมเดล Data Vault เป็นชุดตารางปกติที่เชื่อมโยงกันอย่างเป็นเอกลักษณ์ซึ่งเน้นรายละเอียดในการติดตามประวัติและสนับสนุนพื้นที่การทำงานทางธุรกิจอย่างน้อยหนึ่งส่วน เป็นแนวทางแบบผสมผสานที่รวบรวมสิ่งที่ดีที่สุดระหว่างรูปแบบปกติที่ 3 (3NF) และสคีมาแบบดาวการออกแบบมีความยืดหยุ่น ปรับขนาดได้ สม่ำเสมอ และปรับให้เข้ากับความต้องการขององค์กร" ^{[ 11 ]}

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

อีกประเด็นหนึ่งที่คลังข้อมูล (Data Vault) เข้ามาช่วยแก้ไขคือ ความต้องการในการตรวจสอบและติดตามข้อมูลทั้งหมดในคลังข้อมูลอย่างครบถ้วนมากขึ้นเรื่อยๆ เนื่องจาก ข้อกำหนดของกฎหมาย Sarbanes-Oxleyในสหรัฐอเมริกาและมาตรการที่คล้ายคลึงกันในยุโรป ทำให้เรื่องนี้เป็นประเด็นสำคัญสำหรับการใช้งานระบบ Business Intelligence หลายๆ ระบบ จุดสำคัญของการใช้งานคลังข้อมูลคือ การตรวจสอบและติดตามข้อมูลทั้งหมดได้อย่างครบถ้วน

Data Vault 2.0เป็นข้อกำหนดใหม่ เป็น มาตรฐาน แบบเปิด^{[ 12 ]}ข้อกำหนดใหม่นี้ประกอบด้วยสามเสาหลัก ได้แก่ วิธีการ ( SEI / CMMI , Six Sigma , SDLCเป็นต้น) สถาปัตยกรรม (รวมถึงเลเยอร์อินพุต (data stage ซึ่งเรียกว่าpersistent staging areaใน Data Vault 2.0) และเลเยอร์การนำเสนอ (data mart) และการจัดการ บริการ คุณภาพข้อมูลและบริการข้อมูลหลัก) และแบบจำลอง ภายในวิธีการนี้ มีการกำหนดการนำแนวปฏิบัติที่ดีที่สุดมาใช้ Data Vault 2.0 มุ่งเน้นไปที่การรวมส่วนประกอบใหม่ๆ เช่นบิ๊กดาต้าและNoSQLและยังมุ่งเน้นไปที่ประสิทธิภาพของแบบจำลองที่มีอยู่ ข้อกำหนดเก่า (ส่วนใหญ่บันทึกไว้ที่นี่) มุ่งเน้นไปที่การสร้างแบบจำลอง Data Vault เป็นอย่างมาก มีบันทึกไว้ในหนังสือ: การสร้างคลังข้อมูลที่ปรับขนาดได้ด้วย Data Vault 2.0 ^{[ 13 ]}

จำเป็นต้องปรับปรุงข้อกำหนดให้ครอบคลุมส่วนประกอบใหม่ๆ พร้อมทั้งแนวปฏิบัติที่ดีที่สุด เพื่อให้ระบบ EDW และ BI ทันสมัยและสอดคล้องกับความต้องการและความปรารถนาของธุรกิจในปัจจุบัน

แนวคิดการสร้างแบบจำลอง Data Vault นั้นได้รับการคิดค้นขึ้นครั้งแรกโดย Dan Linstedt ในช่วงทศวรรษ 1990 และได้รับการเผยแพร่ในปี 2000 ในฐานะวิธีการสร้างแบบจำลองสาธารณะ ในบทความห้าตอนใน The Data Administration Newsletter กฎพื้นฐานของวิธีการ Data Vault ได้รับการขยายความและอธิบายเพิ่มเติม ซึ่งประกอบด้วยภาพรวมทั่วไป^{[ 14 ]}ภาพรวมของส่วนประกอบ^{[ 15 ]}การอภิปรายเกี่ยวกับวันที่สิ้นสุดและการเชื่อมต่อ^{[ 16 ]}ตารางเชื่อมโยง^{[ 17 ]}และบทความเกี่ยวกับแนวทางการโหลด^{[ 18 ]}

ชื่อทางเลือก (และไม่ค่อยได้ใช้) สำหรับวิธีการนี้คือ "สถาปัตยกรรมแบบจำลองการบูรณาการพื้นฐานทั่วไป" ^{[ 19 ]}

Data Vault 2.0 ^{[ 20 ] [ 21 ]}ได้ปรากฏตัวขึ้นในปี 2013 และนำเสนอ Big Data, NoSQL, ข้อมูลที่ไม่มีโครงสร้าง, ข้อมูลกึ่งโครงสร้างที่ผสานรวมอย่างราบรื่น พร้อมด้วยวิธีการ สถาปัตยกรรม และแนวปฏิบัติที่ดีที่สุดในการใช้งาน

ตามที่ Dan Linstedt กล่าวไว้ โมเดลข้อมูลได้รับแรงบันดาลใจจาก (หรือจำลองมาจาก) มุมมองที่เรียบง่ายของเซลล์ประสาท เดนไดรต์ และไซแนปส์ โดยที่เซลล์ประสาทจะเชื่อมโยงกับฮับและฮับแซทเทลไลท์ ลิงก์คือเดนไดรต์ (เวกเตอร์ของข้อมูล) และลิงก์อื่นๆ คือไซแนปส์ (เวกเตอร์ในทิศทางตรงกันข้าม) โดยใช้ชุดอัลกอริธึมการขุดข้อมูล ลิงก์สามารถให้คะแนนด้วยความมั่นใจและ ระดับ ความแข็งแกร่งได้ สามารถสร้างและลบลิงก์ได้ทันทีตามการเรียนรู้เกี่ยวกับความสัมพันธ์ที่ยังไม่มีอยู่ โมเดลสามารถเปลี่ยนแปลง ปรับเปลี่ยน และแก้ไขได้โดยอัตโนมัติเมื่อมีการใช้งานและป้อนโครงสร้างใหม่^{[ 22 ]}

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

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

Data Vault 2.0 จัดระเบียบข้อมูลเป็นส่วนประกอบหลัก 3 ส่วนที่แยกตัวระบุที่คงที่ออกจากคุณลักษณะเชิงพรรณนาที่เปลี่ยนแปลง: ^{[ 23 ]}

• ฮับ ​​– จัดเก็บคีย์ธุรกิจเฉพาะสำหรับแนวคิดธุรกิจหลักพร้อมกับเมตาเดต้าขั้นต่ำสำหรับลำดับวงศ์/การตรวจสอบ โดยทำหน้าที่เป็นจุดเชื่อมต่อระหว่างแหล่งข้อมูล^{[ 23 ]}
• ลิงก์ – บันทึกความสัมพันธ์ (มักจะเป็นแบบหลายต่อหลาย) ระหว่างฮับ โดยคีย์ฮับที่เข้าร่วมจะกำหนดระดับของความสัมพันธ์^{[ 23 ]}
• ดาวเทียม – ประกอบด้วยคุณลักษณะเชิงพรรณนาและประวัติที่เกี่ยวข้องกับฮับหรือลิงก์ ดาวเทียมสามารถเพิ่มเติมได้เท่านั้น ดังนั้นการเปลี่ยนแปลงทุกอย่างจึงถูกเก็บรักษาไว้ (มีผลคล้ายกับประวัติประเภท II ในแบบจำลองมิติ) ^{[ 23 ]}

ดาวเทียมเฉพาะทางรองรับความหมายเชิงเวลา ตัวอย่างเช่นดาวเทียมประสิทธิผลบนลิงก์จะบันทึกวันที่เริ่มต้น/สิ้นสุดซึ่งแสดงถึงช่วงเวลาที่ธุรกิจพิจารณาว่าความสัมพันธ์นั้นมีประสิทธิภาพ^{[ 23 ]}

• Raw Vault – เลเยอร์การบูรณาการที่ขับเคลื่อนด้วยแหล่งที่มาซึ่งเก็บรักษาประวัติที่ละเอียดและตรวจสอบได้โดยมีการแปลงน้อยที่สุด^{[ 23 ]}
• Business Vault – เลเยอร์ที่ได้มาซึ่งใช้กฎทางธุรกิจและโครงสร้างช่วยเหลือการสืบค้น (เช่น PIT และตารางเชื่อมโยง) เพื่ออำนวยความสะดวกในการใช้งานปลายทาง^{[ 23 ]}

ในทางปฏิบัติ Data Vault มักทำหน้าที่เป็นเลเยอร์การบูรณาการทางประวัติศาสตร์ ในขณะที่อินเทอร์แอกทีฟมาร์ทแบบสตาร์สคีมาจะถูกฉายจาก Raw/Business Vault เพื่อการวิเคราะห์ที่มีประสิทธิภาพและการเข้าถึงของผู้ใช้ที่ง่ายขึ้น^{[ 24 ] [ 25 ]}

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

ศูนย์กลางประกอบด้วยฟิลด์ต่อไปนี้อย่างน้อย: ^{[ 26 ]}

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

ฮับไม่ได้รับอนุญาตให้มีคีย์ธุรกิจหลายคีย์ ยกเว้นในกรณีที่ระบบสองระบบส่งคีย์ธุรกิจเดียวกัน แต่มีการชนกันที่มีความหมายแตกต่างกัน

โดยปกติศูนย์กลางควรมีดาวเทียมอย่างน้อยหนึ่งดวง^{[ 26 ]}

นี่คือตัวอย่างของตารางศูนย์กลางที่บรรจุรถยนต์ เรียกว่า "รถยนต์" (H_CAR) คีย์หลักคือหมายเลขประจำตัวรถ

ความสัมพันธ์หรือธุรกรรมระหว่างคีย์ทางธุรกิจ (เช่น การเชื่อมโยงศูนย์กลางสำหรับลูกค้าและผลิตภัณฑ์เข้าด้วยกันผ่านธุรกรรมการซื้อ) จะถูกจำลองโดยใช้ตารางเชื่อมโยง ตารางเหล่านี้โดยพื้นฐานแล้วเป็น ตาราง เชื่อมต่อแบบหลายต่อหลาย (many-to-many join tables) พร้อมด้วยเมตาเดต้าบางส่วน

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

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

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

นี่คือตัวอย่างตารางเชื่อมโยงระหว่างศูนย์กลางสองแห่งสำหรับรถยนต์ (H_CAR) และบุคคล (H_PERSON) โดยลิงก์นี้เรียกว่า "คนขับ" (L_DRIVER)

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

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

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

ดาวเทียมที่มีประสิทธิภาพคือดาวเทียมที่สร้างขึ้นบนลิงก์ "และบันทึกช่วงเวลาที่บันทึกลิงก์ที่เกี่ยวข้องเริ่มต้นและสิ้นสุดประสิทธิภาพ" ^{[ 28 ]}

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

(*) คุณลักษณะอย่างน้อยหนึ่งรายการเป็นสิ่งที่จำเป็น (**) หมายเลขลำดับจะกลายเป็นสิ่งที่จำเป็นหากจำเป็นต้องใช้เพื่อบังคับใช้ความไม่ซ้ำกันสำหรับดาวเทียมที่ถูกต้องหลายดวงบนฮับหรือลิงก์เดียวกัน

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

ข้อมูลใดๆ ที่ถือว่าจำเป็นในการแก้ไขคำอธิบายจากรหัส หรือเพื่อแปลคีย์ให้เป็นรูปแบบที่สอดคล้องกัน ฟิลด์เหล่านี้จำนวนมากมีลักษณะเป็น "เชิงพรรณนา" และอธิบายสถานะเฉพาะของข้อมูลสำคัญอื่นๆ ดังนั้น ข้อมูลอ้างอิงจึงอยู่ในตารางแยกต่างหากจากตาราง Data Vaultดิบ^{[ 29 ]}

ตารางอ้างอิงจะถูกอ้างอิงจากดาวเทียม แต่จะไม่ผูกกับคีย์ต่างประเทศทางกายภาพ ไม่มีโครงสร้างที่กำหนดไว้สำหรับตารางอ้างอิง: ใช้สิ่งที่เหมาะสมที่สุดในกรณีเฉพาะของคุณ ตั้งแต่ตารางค้นหาแบบง่ายไปจนถึงคลังข้อมูลขนาดเล็กหรือแม้แต่ดาว ตารางเหล่านี้อาจมีประวัติหรือไม่มีประวัติก็ได้ แต่ขอแนะนำให้คุณใช้คีย์ธรรมชาติและไม่สร้างคีย์ทดแทนในกรณีนั้น^{[ 30 ]}โดยปกติแล้วคลังข้อมูลจะมีตารางอ้างอิงจำนวนมาก เช่นเดียวกับคลังข้อมูลอื่นๆ

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

(*) อย่างน้อยหนึ่งคุณลักษณะเป็นข้อบังคับ

กระบวนการETLสำหรับการอัปเดตโมเดล Data Vault นั้นค่อนข้างตรงไปตรงมา (ดูData Vault Series 5 – Loading Practices ) ขั้นแรก คุณต้องโหลดฮับทั้งหมด โดยสร้าง Surrogate ID สำหรับคีย์ธุรกิจใหม่ใดๆ เมื่อทำเสร็จแล้ว คุณสามารถแปลงคีย์ธุรกิจทั้งหมดเป็น Surrogate ID ได้หากคุณทำการสืบค้นฮับ ขั้นตอนที่สองคือการแปลงลิงก์ระหว่างฮับและสร้าง Surrogate ID สำหรับการเชื่อมโยงใหม่ใดๆ ในขณะเดียวกัน คุณยังสามารถสร้าง Satellite ทั้งหมดที่เชื่อมต่อกับฮับได้ เนื่องจากคุณสามารถแปลงคีย์เป็น Surrogate ID ได้ เมื่อคุณสร้างลิงก์ใหม่ทั้งหมดพร้อมคีย์ Surrogate แล้ว คุณสามารถเพิ่ม Satellite ลงในลิงก์ทั้งหมดได้

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

กระบวนการ ETL นั้นค่อนข้างตรงไปตรงมาและเอื้อต่อการทำงานอัตโนมัติหรือการสร้างเทมเพลตได้ง่าย ปัญหาจะเกิดขึ้นเฉพาะกับลิงก์ที่เกี่ยวข้องกับลิงก์อื่น ๆ เท่านั้น เนื่องจากการแก้ไขคีย์ทางธุรกิจในลิงก์จะนำไปสู่ลิงก์อื่นที่ต้องได้รับการแก้ไขเช่นกัน เนื่องจากสถานการณ์นี้เทียบเท่ากับลิงก์ไปยังฮับหลายแห่ง ความยากลำบากนี้จึงสามารถหลีกเลี่ยงได้โดยการปรับรูปแบบกรณีดังกล่าว และในความเป็นจริงแล้วนี่คือแนวทางปฏิบัติที่แนะนำ^{[ 18 ]}

ข้อมูลจะไม่ถูกลบออกจากคลังข้อมูล เว้นแต่จะมีข้อผิดพลาดทางเทคนิคขณะโหลดข้อมูล

เลเยอร์แบบจำลองคลังข้อมูล (Data Vault Modelled Layer) โดยปกติใช้สำหรับจัดเก็บข้อมูล ไม่ได้ออกแบบมาเพื่อเพิ่มประสิทธิภาพการสืบค้นข้อมูล และไม่สะดวกต่อการสืบค้นด้วยเครื่องมือสืบค้นข้อมูลที่รู้จักกันดี เช่นCognos , Oracle Business Intelligence Suite Enterprise Edition , SAP Business Objects , Pentahoเป็นต้น เนื่องจาก เครื่องมือ ประมวลผลสำหรับผู้ใช้ปลายทาง เหล่านี้ คาดหวังหรือต้องการให้ข้อมูลอยู่ในรูปแบบโมเดลเชิงมิติการแปลงข้อมูลจึงมักเป็นสิ่งจำเป็น

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

โปรดทราบว่าในขณะที่การย้ายข้อมูลจากโมเดลคลังข้อมูลไปยังโมเดลมิติ (ที่ได้รับการทำความสะอาด) นั้นค่อนข้างตรงไปตรงมา แต่การทำในทางกลับกันนั้นไม่ง่ายนัก เนื่องจากลักษณะที่ไม่เป็นมาตรฐานของตารางข้อเท็จจริงของโมเดลมิติ ซึ่งแตกต่างจากรูปแบบปกติที่สามของคลังข้อมูล โดยพื้นฐาน ^{[ 31 ]}

ระเบียบ วิธีจัดเก็บข้อมูลแบบ Data Vault นั้นอิงตาม แนวปฏิบัติที่ดีที่สุดของ SEI / CMMIระดับ 5 โดยประกอบด้วยองค์ประกอบหลายอย่างของ CMMI ระดับ 5 และผสมผสานกับแนวปฏิบัติที่ดีที่สุดจากSix Sigma , การจัดการคุณภาพโดยรวม (TQM) และ SDLC โดยเฉพาะอย่างยิ่ง มุ่งเน้นไปที่ระเบียบวิธีแบบ Agile ของ Scott Ambler สำหรับการสร้างและใช้งานระบบ โครงการ Data Vault มีวงจรการปล่อยเวอร์ชันที่สั้นและควบคุมขอบเขตได้ และควรมีการปล่อยเวอร์ชันสู่การใช้งานจริงทุกๆ 2 ถึง 3 สัปดาห์

ทีมที่ใช้ระเบียบวิธีจัดเก็บข้อมูลแบบคลังข้อมูลควรปรับตัวให้เข้ากับโครงการที่ทำซ้ำได้ สม่ำเสมอ และวัดผลได้ ซึ่งเป็นสิ่งที่คาดหวังได้ในระดับ CMMI ระดับ 5 ข้อมูลที่ไหลผ่านระบบคลังข้อมูล EDW จะเริ่มปฏิบัติตามวงจรชีวิต TQM ซึ่งเป็นสิ่งที่ขาดหายไปนานจากโครงการ BI (ธุรกิจอัจฉริยะ)

ตัวอย่างของเครื่องมือบางชนิด ได้แก่:

• DataVault4dbt
• 2150 ตัวสร้างดาต้าวอลท์
• แอสเตอรา ดีดับบลิว บิลเดอร์
• แวร์สเคป
• วอลท์สปีด
• AutomateDV

• ระบบธุรกิจอัจฉริยะแบบ Agile  – การนำการพัฒนาซอฟต์แวร์แบบ Agile มาใช้สำหรับโครงการระบบธุรกิจอัจฉริยะหน้าเว็บที่แสดงคำอธิบายสั้น ๆ ของเป้าหมายการเปลี่ยนเส้นทาง
• บิล อินมอน  – นักวิทยาศาสตร์คอมพิวเตอร์ชาวอเมริกัน
• ดาต้าเลค  – แหล่งเก็บข้อมูลที่จัดเก็บในรูปแบบข้อมูลดิบ
• คลังข้อมูล  – สถานที่จัดเก็บความรู้แบบรวมศูนย์
• วงจรชีวิตของคิมบอลล์  – ระเบียบวิธีสำหรับการพัฒนาคลังข้อมูลหน้าเว็บที่แสดงคำอธิบายสั้น ๆ ของเป้าหมายการเปลี่ยนเส้นทางพัฒนาโดยราล์ฟ คิมบอลล์  – นักวิทยาศาสตร์คอมพิวเตอร์ชาวอเมริกัน
• พื้นที่เตรียมการ  – สถานที่ที่รวบรวมสิ่งของต่างๆ ก่อนนำไปใช้งาน
• Star schema -- ทางเลือกหลักแทนการสร้างแบบจำลอง Data vault

• Patrick Cuba: ผู้เชี่ยวชาญด้านคลังข้อมูล คู่มือเชิงปฏิบัติเกี่ยวกับการสร้างคลังข้อมูล สำนักพิมพ์อิสระ ไม่ระบุสถานที่ 2020 ISBN 979-86-9130808-6
• จอห์น ไจล์ส: ช้างในตู้เย็น ขั้นตอนสู่ความสำเร็จของดาต้า วอทท์ ผ่านการสร้างแบบจำลองที่เน้นธุรกิจเป็นศูนย์กลาง สำนักพิมพ์ Technics, Basking Ridge 2019, ISBN 978-1-63462-489-3
• เคนท์ กราเซียโน: การสร้างแบบจำลองข้อมูล ที่ดีขึ้น บทนำสู่การวิศวกรรมข้อมูลแบบ Agile โดยใช้ Data Vault 2.0 งานประชุม Data Warrior ที่ฮิวสตัน ปี 2015
• Hans Hultgren: การสร้างแบบจำลองคลังข้อมูลแบบ Agile ด้วย Data Vault. Brighton Hamilton, Denver ua 2012, ISBN 978-0-615-72308-2
• Dirk Lerner: Data Vault สำหรับ Data-Warehouse-Architekturen ที่คล่องตัว ใน: Stephan Trahasch, Michael Zimmer (ชม.): Agile Business Intelligence ทฤษฎีและแพรคซิส dpunkt.verlag, ไฮเดลเบิร์ก 2016, ISBN 978-3-86490-312-0, S. 83–98
• Daniel Linstedt: เพิ่มประสิทธิภาพคลังข้อมูลของคุณให้สูงสุด กฎการสร้างแบบจำลองข้อมูลอันทรงคุณค่าเพื่อนำไปใช้ในการสร้างคลังข้อมูลของคุณ Linstedt, Saint Albans, Vermont 2011, ISBN 978-1-4637-7868-2
• Daniel Linstedt, Michael Olschimke: การสร้างคลังข้อมูลที่ปรับขนาดได้ด้วย Data Vault 2.0. Morgan Kaufmann, Waltham, Massachusetts 2016, ISBN 978-0-12-802510-9.
• Dani Schnider, Claus Jordan ua: พิมพ์เขียวคลังข้อมูล ระบบธุรกิจอัจฉริยะใน der Praxis ฮันเซอร์ มิวนิค 2016, ISBN 978-3-446-45075-2, S. 35–37, 161–173

• หน้าแรกของ Dan Linstedt ผู้คิดค้นแบบจำลอง Data Vault