มีวิธีใดบ้างในการใช้ความสัมพันธ์แบบหลายต่อหลายคนในคลังข้อมูล

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

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

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

1. ความลึกไม่ จำกัด
2. ความเป็นปึกแผ่น
3. มีความยืดหยุ่น
4. ความเร็ว.

ในทางตรงกันข้ามจะใช้ตารางพิเศษสำหรับการรวม "-to-many" แต่ละระดับ นี่คือรหัสยากและยากที่จะรักษาจากการปรับปรุงสคีมา

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

ฉันพยายามแก้ไขปัญหานี้มาหลายปีแล้ว เมื่อเร็ว ๆ นี้นี่คือสิ่งที่ฉันมาด้วย

บางสถานการณ์สำหรับความสัมพันธ์ M: M ในรูปแบบคลังข้อมูล

เซิร์ฟเวอร์ OLAP และระบบ ROLAP ส่วนใหญ่มีวิธีจัดการกับโครงสร้างข้อมูล M: M ในขณะนี้ แต่มีข้อควรระวังบางประการเกี่ยวกับเรื่องนี้ที่คุณจะต้องให้ความสนใจ หากคุณใช้ความสัมพันธ์ M: M คุณจะต้องจับตาเลเยอร์การรายงานของคุณและเครื่องมือที่คุณต้องการสนับสนุน

สถานการณ์ที่ 1: M: M มิติลงบนตารางข้อเท็จจริง

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

ตัวเลือก 1 - M: M ตารางบริดจ์ข้อเท็จจริงของไดรเวอร์ ซึ่งจะมีข้อมูลจำนวนมากเนื่องจากมีแถว x ธุรกรรมของไดรเวอร์สำหรับนโยบายที่กำหนด SSAS สามารถใช้โครงสร้างข้อมูลนี้ได้โดยตรง แต่จะช้ากว่าในการสืบค้นผ่านเครื่องมือ ROLAP

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

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

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

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

ข้อดีของตัวเลือกที่ 1: - จัดทำดัชนีอย่างเหมาะสมแบบสอบถามที่ยึดตามการเลือกแถวตารางข้อเท็จจริงที่มีความสัมพันธ์บางอย่างผ่านตาราง M: M อาจมีประสิทธิภาพพอสมควร

• แบบจำลองแนวคิดที่เรียบง่ายขึ้นเล็กน้อย

ข้อดีของตัวเลือกที่ 2: - การจัดเก็บข้อมูลมีขนาดกะทัดรัดมากขึ้น

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

สถานการณ์ที่ 2: M: M ความสัมพันธ์ระหว่างมิติข้อมูล:

ยากที่จะนึกถึงกรณีการใช้งาน แต่ใคร ๆ ก็สามารถมองเห็นบางสิ่งบางอย่างจากการดูแลสุขภาพด้วยรหัส ICD อีกครั้ง ในระบบการวิเคราะห์ต้นทุนการเยี่ยมชมผู้ป่วยในอาจกลายเป็นมิติและจะมีความสัมพันธ์ M: M ระหว่างการเข้าชม (หรือที่ปรึกษาตอนใน NHS-speak) และการเข้ารหัส

ในกรณีนี้คุณสามารถตั้งค่าความสัมพันธ์ M: M และอาจประมวลผลการเรนเดอร์ที่มนุษย์สามารถอ่านได้บนมิติฐาน ความสัมพันธ์สามารถทำได้ผ่านการเชื่อมโยงตาราง M: M ตรงหรือผ่านตาราง 'รวมกัน' บริดจ์เหมือนเมื่อก่อน โครงสร้างข้อมูลนี้สามารถสอบถามได้อย่างถูกต้องผ่าน Business Objects หรือเครื่องมือ ROLAP ที่มีคุณภาพดีกว่า

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

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

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

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

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

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

การสร้างแบบจำลองลำดับชั้นทางเลือกโดยใช้ตารางบริดจ์:

http://www.kimballgroup.com/wp-content/uploads/2012/05/DT62Alternative.pdf

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

http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/

น่าเสียดายที่บทความ Mag / Information Week / DBMS ของ Kimball จำนวนมากไม่มีลิงก์ที่ดีอีกต่อไป ...

วิธีหนึ่งที่เราสามารถแก้ไขปัญหานี้ได้คือการมีตารางข้อเท็จจริงมี 2 คอลัมน์คือกุญแจต่างประเทศจาก 2 มิติที่มีเรือสัมพันธ์มากมาย