בדוגמה זו, המודל מורכב מארבע טבלאות : קטגוריה , מוצר , שנה ומכירות . טבלת הקטגוריות מתייחסת לטבלת המוצר , וטבלת המוצר מתייחסת לטבלת המכירות . טבלת השנה מתייחסת גם לטבלת המכירות . כל מערכות היחסים הן של אחד לרבים (אשר פרטיהם מתוארים בהמשך מאמר זה).
שאילתה, אולי שנוצרה על ידי כרטיס Power BI חזותי, מבקשת את כמות המכירות הכוללת עבור הזמנות מכירה שבוצעו עבור קטגוריה אחת, Cat-A , ולשנה אחת, CY2018 . זו הסיבה שאתה יכול לראות מסננים שהוחלו בטבלאות הקטגוריה והשנה . המסנן בטבלת הקטגוריה מתפשט לטבלת המוצר כדי לבודד שני מוצרים המוקצים לקטגוריה. Cat-A לאחר מכן מסנני טבלת המוצר מתפשטים לטבלת המכירות כדי לבודד רק שתי שורות מכירות עבור מוצרים אלה. שתי שורות מכירות אלו מייצגות את המכירות של מוצרים שהוקצו לקטגוריה Cat-A. הכמות המשולבת שלהם היא 14 יחידות. במקביל, מסנן טבלת השנה מתפשט לסינון נוסף של טבלת המכירות , וכתוצאה מכך רק שורת המכירות האחת מיועדת למוצרים שהוקצו לקטגוריה Cat-A והוזמנה בשנת. CY2018 ערך הכמות המוחזר על ידי השאילתה הוא 11 יחידות. שים לב שכאשר מסננים מרובים מוחלים על טבלה (כמו טבלת המכירות בדוגמה זו), זו תמיד פעולת AND, הדורשת שכל התנאים חייבים להיות נכונים.
החל עקרונות עיצוב סכימת כוכבים
אנו ממליצים ליישם עקרונות עיצוב סכימת כוכבים כדי לייצר מודל הכולל טבלאות מימד ועובדות. מקובל להגדיר את Power BI כדי לאכוף כללים המסננים טבלאות ממדים, מה שמאפשר לקשרי מודל להפיץ ביעילות את המסננים האלה לטבלאות עובדות.
דיאגרמת המודל של מודל נתוני ניתוח המכירות של Adventure Works
התמונה הבאה היא דיאגרמת המודל של מודל נתוני ניתוח המכירות של Adventure Works. הוא מציג עיצוב סכימת כוכבים הכוללת טבלת עובדות אחת בשם Sales ארבע הטבלאות האחרות הן טבלאות ממדים התומכות בניתוח של מדדי מכירות לפי תאריך, מדינה, אזור ומוצר. שימו לב ליחסי המודל המחברים את כל הטבלאות. קשרי גומלין אלה מפיצים מסננים (במישרין או בעקיפין) לטבלת המכירות.
מאפייני מערכת יחסים
קשר מודל מקשר עמודה אחת בטבלה לעמודה אחת בטבלה אחרת. (יש מקרה מיוחד אחד שבו דרישה זו אינה נכונה, והיא חלה רק על קשרי גומלין מרובי עמודות במודלים של DirectQuery .
הערה
לא ניתן לקשר עמודה לעמודה אחרת באותה טבלה . מושג זה מבולבל לפעמים עם היכולת להגדיר מגבלת מפתח זר של מסד נתונים יחסי המתייחס להפניה עצמית לטבלה. אתה יכול להשתמש במושג מסד נתונים יחסי זה כדי לאחסן קשרי הורה-ילד (לדוגמה, כל רשומת עובד קשורה לעובד "דיווח ל"). עם זאת, אינך יכול להשתמש בקשרי מודל כדי ליצור היררכיית מודל המבוססת על סוג קשר זה. כדי ליצור היררכיית הורה-ילד, ראה פונקציות הורה וילד .
מספר איברים בקבוצה
כל קשר מודל מוגדר על ידי סוג קרדינליות. ישנן ארבע אפשרויות מסוג קרדינליות, המייצגות את מאפייני הנתונים של העמודות הקשורות "מאת" ו"אל" הצד "אחד" פירושו שהעמודה מכילה ערכים ייחודיים; הצד "רבים" אומר שהעמודה יכולה להכיל ערכים כפולים.
הערה
אם פעולת רענון נתונים מנסה לטעון ערכים כפולים בעמודה צדדית "אחד", רענון הנתונים כולו ייכשל.
ארבע האפשרויות, יחד עם סימוני הקיצור שלהן, מתוארות ברשימת התבליטים הבאה:
- אחד לרבים (1:*)
- רבים לאחד (*:1)
- אחד על אחד (1:1)
- רבים לרבים (*:*)
כאשר אתה יוצר קשר ב-Power BI Desktop המעצב מזהה וקובע באופן אוטומטי את סוג הקרדינליות. Power BI Desktop ,שואל את המודל כדי לדעת אילו עמודות מכילות ערכים ייחודיים. עבור דגמי ייבוא, הוא משתמש בסטטיסטיקות אחסון פנימיות; עבור דגמי DirectQuery הוא שולח שאילתות פרופיל למקור הנתונים. עם זאת, לפעמים Power BI Desktop יכול לטעות. זה יכול להשתבש כאשר טבלאות עדיין לא נטענו בנתונים, או בגלל שעמודות שאתה מצפה שיכילו ערכים כפולים מכילות כרגע ערכים ייחודיים. בכל מקרה, אתה יכול לעדכן את סוג הקרדינליות כל עוד עמודות צד "אחת" מכילות ערכים ייחודיים (או שהטבלה עדיין לא נטענת עם שורות של נתונים).
אפשרויות הקרדינליות של אחד לרבים ורבים לאחד הן בעצם זהות, והן גם סוגי הקרדינליות הנפוצים ביותר.
בעת הגדרת קשר של אחד לרבים או רבים לאחד, תבחר את זה שתואם את הסדר שבו קישרת את העמודות. שקול כיצד תגדיר את הקשר מטבלת המוצר לטבלת המכירות באמצעות העמודה ProductID שנמצאת בכל טבלה. סוג הקרדינליות יהיה אחד לרבים , שכן העמודה ProductID בטבלת המוצר מכילה ערכים ייחודיים. אם קישרת את הטבלאות בכיוון ההפוך, מכירות למוצר, הקרדינליות תהיה מרובה
קשר אחד לאחד אומר ששתי העמודות מכילות ערכים ייחודיים. סוג קרדינליות זה אינו נפוץ, וסביר להניח שהוא מייצג עיצוב מודל לא אופטימלי בגלל אחסון נתונים מיותרים.
קשר רב-לרבים אומר ששתי העמודות יכולות להכיל ערכים כפולים. סוג קרדינליות זה נמצא בשימוש נדיר. זה בדרך כלל שימושי בעת תכנון דרישות מודל מורכבות. אתה יכול להשתמש בו כדי לקשר עובדות רבות לרבות או לקשר עובדות גרעיניות גבוהות יותר. לדוגמה, כאשר עובדות יעדי מכירות מאוחסנות ברמת קטגוריית מוצר וטבלת ממדי המוצר מאוחסנת ברמת המוצר.
הערה
סוג הקרדינליות הרבה-לרבים אינו נתמך כעת עבור מודלים שפותחו עבור Power BI Report Server.
עֵצָה
בתצוגת מודל שולחן העבודה של Power BI, תוכל לפרש את סוג הקרדינליות של קשר גומלין על ידי התבוננות במחוונים (1 או *) משני צדי קו הקשר. כדי לקבוע אילו עמודות קשורות, תצטרך לבחור, או לרחף עם הסמן מעל, את קו הקשר כדי להדגיש את העמודות.
כיוון מסנן צולב
כל קשר מודל מוגדר עם כיוון מסנן צולב. ההגדרה שלך קובעת את הכיוונים שהמסננים יתפשטו. אפשרויות הסינון הצולבות האפשריות תלויות בסוג הקרדינליות.
| סוג קרדינליות | אפשרויות סינון צולבות |
| אחד לרבים (או רבים לאחד) | רווק שניהם |
| אחד לאחד | שניהם |
| רבים-לרבים | יחיד (טבלה 1 עד טבלה 2) יחיד (טבלה 2 עד טבלה 1) שניהם |
עבור מערכות יחסים של אחד לרבים, כיוון המסנן הצולב הוא תמיד מהצד "אחד", ובאופן אופציונלי מהצד "רבים" (דו-כיווני). עבור קשרי גומלין אחד לאחד, כיוון המסנן הצלב הוא תמיד משתי הטבלאות. לבסוף, עבור קשרי גומלין רבים-לרבים, כיוון מסנן צולב יכול להיות מאחת מהטבלאות, או משתי הטבלאות. שימו לב שכאשר סוג הקרדינליות כולל צד "אחד", המסננים תמיד יתפשטו מהצד הזה.
כאשר כיוון המסנן הצלב מוגדר לשני , מאפיין אחר הופך זמין. זה יכול להחיל סינון דו-כיווני כאשר Power BI אוכף כללי אבטחה ברמת השורה .
אתה יכול לשנות את כיוון המסנן הצולבות של הקשר, כולל השבתת התפשטות המסנן, באמצעות חישוב מודל. זה מושג על ידי שימוש בפונקציית CROSSFILTER DAX
זכור שמערכות יחסים דו-כיווניות יכולות להשפיע לרעה על הביצועים. יתרה מכך, ניסיון להגדיר קשר דו-כיווני עלול לגרום לנתיבי התפשטות מסננים מעורפלים. במקרה זה, ייתכן ש- Power BI Desktop לא יבצע את שינוי הקשר ויתריע בהודעת שגיאה. עם זאת, לפעמים Power BI Desktop עשוי לאפשר לך להגדיר נתיבי קשר מעורפלים בין טבלאות.
עֵצָה
בתצוגת המודל של, Power BI Desktop אתה יכול לפרש את כיוון המסנן הצולב של קשר גומלין על ידי שימת לב לראשי החצים לאורך קו הקשר. ראש חץ בודד מייצג מסנן חד-כיווני בכיוון ראש החץ; ראש חץ כפול מייצג קשר דו-כיווני.
הפוך את הקשר הזה לפעיל
יכול להיות רק נתיב הפצת מסנן פעיל אחד בין שתי טבלאות מודל. עם זאת, אפשר להציג נתיבי קשר נוספים, אם כי עליך להגדיר קשרים אלה כלא פעילים . ניתן להפוך קשרים לא פעילים לפעילים רק במהלך הערכה של חישוב מודל.
באופן כללי, אנו ממליצים להגדיר מערכות יחסים אקטיביות במידת האפשר. הם מרחיבים את ההיקף והפוטנציאל של האופן שבו מחברי הדוחות יכולים להשתמש במודל שלך. שימוש בקשרים פעילים בלבד פירושו שיש לשכפל טבלאות מימדים של משחק תפקידים במודל שלך.
עם זאת, בנסיבות ספציפיות, אתה יכול להגדיר קשר אחד או יותר לא פעיל עבור טבלת מימדים של משחק תפקידים. אתה יכול לשקול עיצוב זה כאשר:
- אין דרישה לכך שתמונות דיווח יסוננו בו זמנית לפי תפקידים שונים.
- אתה משתמש USERELATIONSHIPבפונקציית DAX כדי להפעיל קשר ספציפי עבור חישובי מודל רלוונטיים.
עֵצָה
בתצוגת מודל Power BI Desktop, אתה יכול לפרש את הסטטוס פעיל לעומת לא פעיל של מערכת יחסים. מערכת יחסים פעילה מיוצגת על ידי קו אחיד; קשר לא פעיל מיוצג כקו מקווקו.
הנח יושרה התייחסותית
המאפיין Assume referential integrity זמין רק עבור קשרי גומלין אחד לרבים ואחד לאחד בין שתי טבלאות מצב אחסון DirectQuery השייכות לאותה קבוצת מקור. אתה יכול להפעיל מאפיין זה רק כאשר העמודה הצדדית "רבים" אינה מכילה NULLs .
כאשר מופעל, שאילתות מקוריות שנשלחות למקור הנתונים יחברו את שתי הטבלאות יחד על ידי שימוש ב- INNER JOINבמקום OUTER JOIN ,בדרך כלל, הפעלת מאפיין זה משפרת את ביצועי השאילתות, אם כי היא תלויה בפרטים הספציפיים של מקור הנתונים.
הפעל תמיד מאפיין זה כאשר קיים אילוץ מפתח זר של מסד נתונים בין שתי הטבלאות. גם כאשר לא קיים אילוץ מפתח זר, שקול להפעיל את המאפיין כל עוד אתה בטוח שקיימת שלמות נתונים.
חָשׁוּב
אם שלמות הנתונים תיפגע, החיבור הפנימי יבטל שורות ללא התאמה בין הטבלאות. לדוגמה, שקול מודל של טבלת מכירות עם ערך עמודת ProductID שלא היה קיים בטבלת המוצר הקשורה. הפצת מסנן מטבלת המוצר לטבלת המכירות תבטל שורות מכירות עבור מוצרים לא ידועים. זה יביא להקטנת תוצאות המכירות.
