Οδηγίες για τις σχέσεις πολλά προς πολλά

Αυτό το άρθρο απευθύνεται σε εσάς ως δημιουργός μοντέλων δεδομένων που συνεργάζεται με το Power BI Desktop. Περιγράφει τρία διαφορετικά σενάρια μοντελοποίησης πολλά προς πολλά. Σας παρέχει επίσης οδηγίες σχετικά με τον τρόπο επιτυχούς σχεδίασης για αυτά στα μοντέλα σας.

Σημείωση

Η εισαγωγή στις σχέσεις μοντέλου δεν καλύπτεται σε αυτό το άρθρο. Εάν δεν είστε πλήρως εξοικειωμένοι με τις σχέσεις, τις ιδιότητές τους ή τον τρόπο ρύθμισης των παραμέτρων τους, συνιστούμε να διαβάσετε πρώτα το άρθρο σχέσεων μοντέλου στο Power BI Desktop.

Είναι επίσης σημαντικό να κατανοήσετε τη σχεδίαση αστεροειδούς σχήματος. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Κατανόηση του αστεροειδούς σχήματος και της σημασίας του για το Power BI.

Υπάρχουν τρία διαφορετικά σενάρια "πολλά προς πολλά". Αυτά μπορεί να προκύψουν όταν σας ζητηθεί να κάνετε τα εξής:

• Συσχέτιση δύο πινάκων διαστάσεων
• Συσχέτιση δύο πινάκων δεδομένων
• Συσχέτιση πινάκων δεδομένων με μεγαλύτερη λεπτομέρεια, όταν ο πίνακας δεδομένων αποθηκεύει γραμμές σε υψηλότερο επίπεδο λεπτομέρειας από ότι οι γραμμές πίνακα διαστάσεων

Συσχέτιση διαστάσεων "πολλά προς πολλά"

Το κλασικό σενάριο "πολλά-προς-πολλά" συσχετίζει δύο οντότητες, για παράδειγμα τραπεζικούς πελάτες και τραπεζικούς λογαριασμούς. Θεωρήστε ότι οι πελάτες μπορούν να έχουν πολλούς λογαριασμούς και οι λογαριασμοί μπορούν να έχουν πολλούς πελάτες. Όταν ένας λογαριασμός έχει πολλούς πελάτες, συνήθως καλούνται κάτοχοι κοινών λογαριασμών.

Η μοντελοποίηση αυτών των οντοτήτων είναι απλή. Ένας πίνακας διαστάσεων αποθηκεύει λογαριασμούς και ένας άλλος πίνακας διαστάσεων αποθηκεύει πελάτες. Όπως είναι χαρακτηριστικό των πινάκων διαστάσεων, υπάρχει μια στήλη μοναδικού αναγνωριστικού (ID) σε κάθε πίνακα. Για να μοντελοποιείτε τη σχέση μεταξύ των δύο πινάκων, απαιτείται ένας τρίτος πίνακας. Αυτός ο πίνακας αναφέρεται συνήθως ως πίνακας γεφύρωσης. Σε αυτό το παράδειγμα, σκοπός του είναι η αποθήκευση μίας γραμμής για κάθε συσχέτιση πελάτη-λογαριασμού. Είναι ενδιαφέρον ότι, όταν αυτός ο πίνακας περιέχει μόνο στήλες αναγνωριστικών, ονομάζεται πίνακας δεδομένων.

Ακολουθεί ένα απλοϊκό διάγραμμα των τριών πινάκων μοντέλων.

Ο πρώτος πίνακας ονομάζεται Accountκαι περιέχει δύο στήλες: AccountID και Account. Ο δεύτερος πίνακας ονομάζεται AccountCustomerκαι περιέχει δύο στήλες: AccountID και CustomerID. Ο τρίτος πίνακας ονομάζεται Customerκαι περιέχει δύο στήλες: CustomerID και Customer. Δεν υπάρχουν σχέσεις μεταξύ των πινάκων.

Προστίθενται δύο σχέσεις ένα προς πολλά για να συσχετιστούν οι πίνακες. Ακολουθεί ένα ενημερωμένο διάγραμμα μοντέλου των σχετικών πινάκων. Προστέθηκε ένας πίνακας δεδομένων με το όνομα Transaction. Καταγράφει συναλλαγές λογαριασμών. Ο πίνακας γεφύρωσης και όλες οι στήλες αναγνωριστικών έχουν γίνει κρυφές.

Για να σας βοηθήσει να περιγράψετε πώς λειτουργεί η μετάδοση του φίλτρου σχέσεων, το διάγραμμα μοντέλου τροποποιήθηκε για να αποκαλύψει τις γραμμές του πίνακα.

Οι λεπτομέρειες γραμμής για τους τέσσερις πίνακες παρουσιάζονται στην παρακάτω λίστα με κουκκίδες:

• Ο Account πίνακας έχει δύο γραμμές:
  • AccountID 1 αφορά λογαριασμό-01
  • AccountID 2 προορίζεται για λογαριασμό-02
• Ο Customer πίνακας έχει δύο γραμμές:
  • 91 αφορά Customer-91
  • 92 προορίζεται για Customer-92
• Ο AccountCustomer πίνακας έχει τρεις γραμμές:
  • Το 1 σχετίζεται με 91
  • AccountID 1 σχετίζεται με CustomerID92
  • AccountID 2 σχετίζεται με CustomerID92
• Ο Transaction πίνακας έχει τρεις γραμμές:
  • Date 1η Ιανουαρίου 2019,, AccountID1, Amount100
  • Date 2 Φεβρουαρίου 2019, AccountID2, Amount200
  • Date 3 Μαρτίου 2019, AccountID1, Amount-25

Ας δούμε τι θα συμβεί όταν ερωτηθεί το μοντέλο.

Στην παρακάτω εικόνα, υπάρχουν δύο απεικονίσεις πίνακα που συνοψίζουν τη στήλη Amount του πίνακα Transaction. Η πρώτη απεικόνιση ομαδοποιεί κατά λογαριασμό και, επομένως, το άθροισμα των στηλών Amount αντιπροσωπεύει το υπόλοιπο λογαριασμού. Η δεύτερη απεικόνιση ομαδοποιεί κατά πελάτη και, επομένως, το άθροισμα των στηλών Amount αντιπροσωπεύει το υπόλοιπο πελάτη.

Η πρώτη απεικόνιση πίνακα (Υπόλοιπο λογαριασμού) έχει δύο στήλες: Account και Amount. Εμφανίζει το ακόλουθο αποτέλεσμα:

• λογαριασμός-01, το υπόλοιπο λογαριασμού είναι 75.
• λογαριασμός-02 υπόλοιπο είναι 200.
• Το σύνολο είναι 275.

Η δεύτερη απεικόνιση πίνακα (Υπόλοιπο πελάτη) έχει δύο στήλες: Customer και Amount. Εμφανίζει το ακόλουθο αποτέλεσμα:

• ποσό υπολοίπου Πελάτης-91 275.
• υπόλοιπο Πελάτης-92 είναι 275.
• Το σύνολο είναι 275.

Μια γρήγορη ματιά στις γραμμές του πίνακα και την απεικόνιση Υπόλοιπο λογαριασμού αποκαλύπτει ότι το αποτέλεσμα είναι σωστό, για κάθε λογαριασμό και για το συνολικό ποσό. Αυτό συμβαίνει επειδή κάθε ομαδοποίηση λογαριασμών οδηγεί σε μια μετάδοση φίλτρου στον πίνακα Transaction για αυτόν τον λογαριασμό.

Ωστόσο, κάτι δεν φαίνεται σωστό με την απεικόνιση Υπόλοιπο πελάτη. Κάθε πελάτης σε αυτήν την απεικόνιση έχει το ίδιο υπόλοιπο με το συνολικό υπόλοιπο. Αυτό το αποτέλεσμα θα μπορούσε να είναι σωστό μόνο εάν κάθε πελάτης ήταν ένας κάτοχος κοινού λογαριασμού για κάθε λογαριασμό. Αυτό δεν συμβαίνει σε αυτό το παράδειγμα. Υπάρχει ένα πρόβλημα και σχετίζεται με τη μετάδοση φίλτρου. Τα φίλτρα δεν ρέουν μέχρι τον πίνακα Transaction.

Εάν ακολουθείτε τις κατευθύνσεις φιλτραρίσματος σχέσεων από τον Customer πίνακα στον Transaction πίνακα, μπορείτε να προσδιορίσετε ότι η σχέση μεταξύ των πινάκων Account και AccountCustomer μεταδίδεται προς λάθος κατεύθυνση. Η κατεύθυνση φίλτρου για αυτή τη σχέση πρέπει να οριστεί σε Both.

Όπως αναμενόταν, δεν υπήρξε καμία αλλαγή στην απεικόνιση Υπόλοιπο λογαριασμού.

Ωστόσο, η απεικόνιση Υπόλοιπο πελάτη εμφανίζει τώρα το εξής αποτέλεσμα:

• υπόλοιπο Πελάτης-91 είναι 75.
• υπόλοιπο Πελάτης-92 είναι 275.
• Το σύνολο είναι 275.

Η απεικόνιση Υπόλοιπο πελάτη εμφανίζει τώρα ένα σωστό αποτέλεσμα. Ακολουθήστε τις οδηγίες φιλτραρίσματος για εσάς και δείτε πώς υπολογίστηκαν τα υπόλοιπα πελατών. Επίσης, κατανοήστε ότι το σύνολο απεικόνισης σημαίνει ότι όλοι οι πελάτες.

Κάποιος που δεν είναι εξοικειωμένος με τις σχέσεις μοντέλου μπορεί να συμπεράνει ότι το αποτέλεσμα είναι εσφαλμένο. Μπορεί να ρωτήσουν: Γιατί δεν είναι το συνολικό υπόλοιπο για Customer-91 και το Customer-92 ίσο με 350 (75 + 275);

Η απάντηση στην ερώτησή τους έγκειται στην κατανόηση της σχέσης "πολλά-προς-πολλά". Κάθε υπόλοιπο πελάτη μπορεί να αντιπροσωπεύει την προσθήκη πολλών υπολοίπων λογαριασμών και, επομένως, τα υπόλοιπα πελατών είναι μη προσθετικά.

Οδηγίες συσχέτισης διαστάσεων "πολλά προς πολλά"

Όταν έχετε μια σχέση πολλά-προς-πολλά μεταξύ των πινάκων διαστάσεων, ακολουθήστε αυτές τις οδηγίες:

• Προσθέστε κάθε σχετική οντότητα "πολλά-προς-πολλά" ως πίνακα μοντέλου, εξασφαλίζοντας ότι διαθέτει μια στήλη αναγνωριστικού.
• Προσθέστε έναν πίνακα γεφύρωσης για την αποθήκευση συσχετισμένων οντοτήτων.
• Δημιουργήστε σχέσεις ένα προς πολλά μεταξύ των τριών πινάκων.
• Ορίστε μία σχέση αμφίδρομης κατεύθυνσης για να επιτρέψετε τη μετάδοση φίλτρου για να συνεχίσετε στον πίνακα δεδομένων.
• Όταν δεν είναι σωστό να λείπουν τιμές αναγνωριστικού, απενεργοποιήστε την ιδιότητα Is Nullable— Η ανανέωση δεδομένων θα αποτύχει όταν προέρχονται τιμές που λείπουν.
• Αποκρύψτε τον πίνακα γεφύρωσης (εκτός εάν περιέχει άλλες στήλες ή μετρήσεις που απαιτούνται για την αναφορά).
• Αποκρύψτε τυχόν στήλες αναγνωριστικού που δεν είναι κατάλληλες για αναφορά (για παράδειγμα, όταν οι στήλες αποθηκεύουν υποκατάστατες τιμές κλειδιών).
• Εάν έχει νόημα να αφήσετε ορατή μια στήλη αναγνωριστικού, βεβαιωθείτε ότι βρίσκεται στην πλευρά "ένα" της σχέσης. Να αποκρύπτετε πάντα την πλευρά "πολλά". Αυτό συμβαίνει επειδή τα φίλτρα που εφαρμόζονται στη διαφάνεια "ένα" έχουν ως αποτέλεσμα καλύτερες επιδόσεις φιλτραρίσματος.
• Για να αποφύγετε τη σύγχυση ή την παρερμηνεία, κοινοποιήστε επεξηγήσεις στους χρήστες της αναφοράς σας. Μπορείτε να προσθέσετε περιγραφές με πλαίσια κειμένου ή επεξηγήσεις εργαλείων κεφαλίδας απεικόνισης.

Δεν συνιστούμε να συσχετίζετε απευθείας πίνακες διαστάσεων "πολλά-προς-πολλά". Αυτή η προσέγγιση σχεδίασης απαιτεί τη ρύθμιση μιας σχέσης με πληθικότητα πολλά προς πολλά. Εννοιολογικά μπορεί να επιτευχθεί, ωστόσο υπονοεί ότι οι σχετικές στήλες μπορεί να περιέχουν διπλότυπες τιμές. Ωστόσο, είναι μια καλά αποδεκτή πρακτική σχεδίασης ότι οι πίνακες διαστάσεων έχουν μια στήλη αναγνωριστικού. Οι πίνακες διαστάσεων πρέπει να χρησιμοποιούν πάντα τη στήλη ID ως την πλευρά "ένα" μιας σχέσης.

Συσχέτιση στοιχείων "πολλά προς πολλά"

Ένας διαφορετικός τύπος σεναρίου "πολλά-προς-πολλά" περιλαμβάνει τη συσχέτιση δύο πινάκων δεδομένων. Δύο πίνακες δεδομένων μπορούν να σχετίζονται απευθείας. Αυτή η τεχνική σχεδίασης μπορεί να είναι χρήσιμη για γρήγορη και απλή εξερεύνηση δεδομένων. Ωστόσο, και για να είμαστε ξεκάθαροι, γενικά δεν συνιστούμε αυτή την προσέγγιση σχεδίασης. Θα εξηγήσουμε γιατί αργότερα σε αυτή την ενότητα.

Ας δούμε ένα παράδειγμα που περιλαμβάνει δύο πίνακες δεδομένων: Order και Fulfillment. Ο Order πίνακας περιέχει μία γραμμή ανά γραμμή παραγγελίας και ο πίνακας Fulfillment μπορεί να περιέχει μηδέν ή περισσότερες γραμμές ανά γραμμή παραγγελίας. Οι γραμμές στον πίνακα Order αντιπροσωπεύουν παραγγελίες πωλήσεων. Οι γραμμές στον Fulfillment πίνακα αντιπροσωπεύουν στοιχεία παραγγελιών που έχουν αποσταλεί. Μια σχέση "πολλά-προς-πολλά" συσχετίζει τις OrderID στήλες σε κάθε πίνακα, με τη μετάδοση φίλτρου μόνο από τον Order πίνακα (που σημαίνει ότι ο πίνακας Order φιλτράρει τον Fulfillment πίνακα).

Η πληθικότητα της σχέσης ορίζεται σε Many-to-many για την υποστήριξη της αποθήκευσης διπλότυπων τιμών OrderID στηλών και στους δύο πίνακες. Στον πίνακα Order, μπορούν να υπάρχουν διπλότυπες τιμές αναγνωριστικού, επειδή μια σειρά μπορεί να έχει πολλές γραμμές. Στον πίνακα Fulfillment, μπορεί να υπάρχουν διπλότυπες τιμές αναγνωριστικού, επειδή οι παραγγελίες μπορεί να έχουν πολλές γραμμές και οι γραμμές παραγγελιών μπορούν να ικανοποιηθούν από πολλές αποστολές.

Ας ρίξουμε μια ματιά στις γραμμές του πίνακα. Στον πίνακα Fulfillment, παρατηρήστε ότι οι γραμμές παραγγελιών μπορούν να ικανοποιηθούν από πολλαπλές αποστολές. (Η απουσία μιας γραμμής παραγγελίας σημαίνει ότι η σειρά δεν έχει διεκπεραιωθεί ακόμα.)

Οι λεπτομέρειες γραμμής για τους δύο πίνακες περιγράφονται στην παρακάτω λίστα με κουκκίδες:

• Ο Order πίνακας έχει πέντε γραμμές:
  • OrderDate 1η Ιανουαρίου 2019, OrderID1, OrderLine1, ProductIDProd-A , OrderQuantity5, Sales50
  • OrderDate 1η Ιανουαρίου 2019, OrderID1, OrderLine2, ProductIDProd-B , OrderQuantity10, Sales80
  • OrderDate 2 Φεβρουαρίου 2019, OrderID2, OrderLine1, ProductIDProd-B , OrderQuantity5, Sales40
  • OrderDate 2 Φεβρουαρίου 2019, OrderID2, OrderLine2, ProductIDProd-C , OrderQuantity1, Sales20
  • OrderDate 3 Μαρτίου 2019, OrderID3, OrderLine1, ProductIDProd-C , OrderQuantity5, Sales100
• Ο Fulfillment πίνακας έχει τέσσερις γραμμές:
  • FulfillmentDate 1η Ιανουαρίου 2019, FulfillmentID50, OrderID1, OrderLine1, FulfillmentQuantity2
  • FulfillmentDate 2 Φεβρουαρίου 2019, FulfillmentID51, OrderID2, OrderLine1, FulfillmentQuantity5
  • FulfillmentDate 2 Φεβρουαρίου 2019, FulfillmentID52, OrderID1, OrderLine1, FulfillmentQuantity3
  • FulfillmentDate 1η Ιανουαρίου 2019, FulfillmentID53, OrderID1, OrderLine2, FulfillmentQuantity10

Ας δούμε τι θα συμβεί όταν ερωτηθεί το μοντέλο. Ακολουθεί μια απεικόνιση πίνακα που συγκρίνει τις ποσότητες παραγγελίας και διεκπεραίωσης από τον Order πίνακα OrderID στήλη.

Η απεικόνιση παρουσιάζει ένα ακριβές αποτέλεσμα. Ωστόσο, η χρησιμότητα του μοντέλου είναι περιορισμένη καθώς μπορείτε να φιλτράρετε ή να ομαδοποιήσετε μόνο σύμφωνα με τον Order πίνακα OrderID στήλη.

Οδηγίες συσχέτισης στοιχείων "πολλά προς πολλά"

Γενικά, δεν συνιστούμε να συσχετίζετε απευθείας δύο πίνακες δεδομένων, χρησιμοποιώντας πληθικότητα "πολλά-προς-πολλά". Ο κύριος λόγος είναι ότι το μοντέλο δεν θα παρέχει ευελιξία στους τρόπους με τους οποίους οι απεικονίσεις της αναφοράς σας φιλτράρουν ή ομαδοποιούν. Στο παράδειγμα, οι απεικονίσεις φιλτράρονται ή ομαδοποιούνται μόνο σύμφωνα με τον Order πίνακα OrderID στήλη. Ένας άλλος λόγος σχετίζεται με την ποιότητα των δεδομένων σας. Εάν τα δεδομένα σας έχουν προβλήματα ακεραιότητας, είναι πιθανό ορισμένες γραμμές να παραλειφθούν κατά την υποβολή ερωτημάτων λόγω της πληθικότητας πολλά προς άτομο και περιορισμένες σχέσεις.

Αντί να συσχετίζετε απευθείας πίνακες δεδομένων, προτείνουμε να υλοποιήσετε ένα αστεροειδές σχήμα σχεδίαση. Αυτό σημαίνει ότι προσθέτετε πίνακες διαστάσεων. Στη συνέχεια, αυτοί οι πίνακες διαστάσεων σχετίζονται με τους πίνακες δεδομένων, χρησιμοποιώντας σχέσεις "ένα-προς-πολλά". Αυτή η προσέγγιση σχεδίασης είναι στιβαρή, καθώς παρέχει αποτελεσματικά ευέλικτες επιλογές αναφοράς. Σας επιτρέπει να φιλτράρετε ή να ομαδοποιήσετε χρησιμοποιώντας οποιαδήποτε από τις στήλες του πίνακα διαστάσεων και να συνοψίσετε στήλες οποιουδήποτε σχετικού πίνακα δεδομένων.

Ας εξετάσουμε μια καλύτερη λύση.

Παρατηρήστε τις παρακάτω αλλαγές σχεδίασης:

• Το μοντέλο έχει πλέον τέσσερις επιπλέον πίνακες: OrderLine, OrderDate, Productκαι FulfillmentDate.
• Οι τέσσερις επιπλέον πίνακες είναι όλοι πίνακες διαστάσεων όπου οι σχέσεις "ένα-προς-πολλά" τους συσχετίζουν με τους πίνακες δεδομένων.
• Ο OrderLine πίνακας περιέχει τη στήλη OrderLineID, η οποία αποθηκεύει την OrderID τιμή πολλαπλασιασμένη επί 100, συν την τιμή OrderLine στήλης, ένα αναγνωριστικό για κάθε γραμμή παραγγελίας.
• Οι πίνακες Order και Fulfillment περιέχουν τώρα μια στήλη OrderLineID και δεν περιέχουν πλέον τις στήλες OrderID και OrderLine.
• Ο Fulfillment πίνακας περιέχει τώρα OrderDate και ProductID στήλες.
• Ο FulfillmentDate πίνακας έχει μια σχέση μόνο με τον πίνακα Fulfillment.
• Όλες οι στήλες αναγνωριστικού είναι κρυφές.

Η υιοθέτηση μιας σχεδίασης αστεροειδούς σχήματος προσφέρει τα εξής πλεονεκτήματα:

• Οι απεικονίσεις της αναφοράς σας μπορούν να να φιλτράρουν ή να ομαδοποιούν από οποιαδήποτε ορατή στήλη από τους πίνακες διαστάσεων.
• Οι απεικονίσεις της αναφοράς σας μπορούν να να συνοψίσουν οποιαδήποτε ορατή στήλη από τους πίνακες δεδομένων.
• Τα φίλτρα που εφαρμόζονται στους OrderLine, OrderDateή Product πίνακες μεταδίδονται και στους δύο πίνακες δεδομένων.
• Όλες οι σχέσεις είναι "ένα-προς-πολλά" και κάθε σχέση είναι μια κανονική σχέση. Τα ζητήματα ακεραιότητας δεδομένων δεν θα καλυφθούν. Για περισσότερες πληροφορίες σχετικά με την αξιολόγηση των σχέσεων, ανατρέξτε στο θέμα σχέσεις μοντέλου στο Power BI Desktop.

Συσχέτιση στοιχείων με μεγαλύτερη λεπτομέρεια

Αυτό το σενάριο "πολλά-προς-πολλά" είναι πολύ διαφορετικό από τα άλλα δύο που περιγράφονται ήδη σε αυτό το άρθρο.

Ας εξετάσουμε ένα παράδειγμα που περιλαμβάνει τέσσερις πίνακες: Date, Sales, Productκαι Target. Οι πίνακες Date και Product είναι πίνακες διαστάσεων και οι σχέσεις "ένα-προς-πολλά" συσχετίζουν τον καθένα με τον πίνακα δεδομένων Sales. Μέχρι στιγμής, αντιπροσωπεύει μια καλή σχεδίαση αστεροειδούς σχήματος. Ωστόσο, ο Target πίνακας δεν έχει ακόμα σχετίζεται με τους άλλους πίνακες.

Ο πίνακας Target περιέχει τρεις στήλες: Category, TargetQuantityκαι TargetYear. Οι γραμμές του πίνακα αποκαλύπτουν μια υποδιαίρεση του έτους και της κατηγορίας προϊόντων. Με άλλα λόγια, οι στόχοι, που χρησιμοποιούνται για τη μέτρηση της απόδοσης των πωλήσεων, ορίζονται κάθε χρόνο για κάθε κατηγορία προϊόντων.

Επειδή ο Target πίνακας αποθηκεύει δεδομένα σε υψηλότερο επίπεδο από τους πίνακες διαστάσεων, δεν είναι δυνατή η δημιουργία σχέσης ένα-προς-πολλά. Αυτό ισχύει μόνο για μία από τις σχέσεις. Ας εξετάσουμε τον τρόπο με τον οποίο ο πίνακας Target μπορεί να σχετίζεται με τους πίνακες διαστάσεων.

Συσχέτιση χρονικών περιόδων με μεγαλύτερη λεπτομέρεια

Μια σχέση μεταξύ των Date και Target πινάκων πρέπει να είναι μια σχέση ένα-προς-πολλά. Αυτό συμβαίνει επειδή οι TargetYear τιμές στήλης είναι ημερομηνίες. Σε αυτό το παράδειγμα, κάθε TargetYear στήλη αποθηκεύει την πρώτη ημερομηνία του έτους-στόχου.

Φιλοδώρημα

Κατά την αποθήκευση στοιχείων σε μεγαλύτερη χρονική υποδιαίρεση από την ημέρα, ορίστε τον τύπο δεδομένων στήλης σε Ημερομηνία (ή Ακέραιος αριθμός εάν χρησιμοποιείτε κλειδιά ημερομηνιών). Στη στήλη, αποθηκεύστε μια τιμή που αντιπροσωπεύει την πρώτη ημέρα της χρονικής περιόδου. Για παράδειγμα, μια περίοδος έτους καταγράφεται ως 1 Ιανουαρίου του έτους και μια περίοδος μήνα καταγράφεται ως η πρώτη ημέρα αυτού του μήνα.

Ωστόσο, πρέπει να λαμβάνεται φροντίδα για να διασφαλιστεί ότι τα φίλτρα επιπέδου μήνα ή ημερομηνίας παράγουν ένα ουσιαστικό αποτέλεσμα. Χωρίς κάποια ειδική λογική υπολογισμού, οι απεικονίσεις αναφοράς μπορεί να αναφέρουν ότι οι ημερομηνίες-στόχοι είναι κυριολεκτικά η πρώτη ημέρα κάθε έτους. Όλες οι άλλες ημέρες, καθώς και όλοι οι μήνες εκτός από τον Ιανουάριο, θα συνοψίσουν την ποσότητα-στόχο ως ΚΕΝΟ.

Η παρακάτω απεικόνιση μήτρας εμφανίζει τι συμβαίνει όταν ο χρήστης αναφοράς πραγματοποιεί λεπτομερή έρευνα από ένα έτος στους μήνες του. Η απεικόνιση συνοψίζει τη στήλη TargetQuantity. (Η επιλογή Εμφάνιση στοιχείων χωρίς δεδομένα επιλογή έχει ενεργοποιηθεί για τις γραμμές μήτρας.)

Για να αποφύγετε αυτή τη συμπεριφορά, συνιστούμε να ελέγχετε τη σύνοψη των δεδομένων των στοιχείων σας χρησιμοποιώντας μετρήσεις. Ένας τρόπος για να ελέγξετε τη σύνοψη είναι να επιστρέψετε ΚΕΝΟ όταν γίνεται ερώτημα σε χρονικές περιόδους χαμηλότερου επιπέδου. Ένας άλλος τρόπος, που ορίζεται με κάποια εξελιγμένη DAX, είναι η κατανομή τιμών σε χρονικές περιόδους χαμηλότερου επιπέδου.

Εξετάστε τον παρακάτω ορισμό μέτρησης που χρησιμοποιεί τις συνάρτηση DAX ISFILTERED. Επιστρέφει μια τιμή μόνο όταν οι Date και Month στήλες δεν έχουν φιλτραριστεί.

Target Quantity =
IF(
    NOT ISFILTERED('Date'[Date])
        && NOT ISFILTERED('Date'[Month]),
    SUM(Target[TargetQuantity])
)

Η ακόλουθη απεικόνιση μήτρας χρησιμοποιεί τη μέτρηση Target Quantity. Δείχνει ότι όλες οι μηνιαίες ποσότητες-στόχοι είναι ΚΕΝΕΣ.

Συσχέτιση με μεγαλύτερη λεπτομέρεια (χωρίς ημερομηνία)

Απαιτείται διαφορετική προσέγγιση σχεδίασης κατά τη συσχέτιση μιας στήλης που δεν περιέχει ημερομηνίες από έναν πίνακα διαστάσεων σε έναν πίνακα δεδομένων (και βρίσκεται σε υψηλότερο επίπεδο λεπτομέρειας από τον πίνακα διαστάσεων).

Οι Category στήλες (τόσο από τους πίνακες Product όσο και από Target) περιέχουν διπλότυπες τιμές. Επομένως, δεν υπάρχει πλευρά "ένα" για μια σχέση "ένα-προς-πολλά". Σε αυτή την περίπτωση, θα χρειαστεί να δημιουργήσετε μια σχέση πολλά προς πολλά. Η σχέση θα πρέπει να μεταδίδει φίλτρα προς μία κατεύθυνση, από τον πίνακα διαστάσεων στον πίνακα δεδομένων.

Ας ρίξουμε μια ματιά στις γραμμές του πίνακα.

Στον πίνακα Target, υπάρχουν τέσσερις γραμμές: δύο γραμμές για κάθε έτος-στόχο (2019 και 2020) και δύο κατηγορίες (Ενδύματα και Αξεσουάρ). Στον πίνακα Product, υπάρχουν τρία προϊόντα. Τα δύο ανήκουν στην κατηγορία ενδύματα και το ένα ανήκει στην κατηγορία αξεσουάρ. Ένα από τα χρώματα ρούχων είναι το πράσινο και τα υπόλοιπα δύο είναι μπλε.

Μια ομαδοποίηση απεικόνισης πίνακα με βάση τη στήλη Category από τον πίνακα Product παράγει το ακόλουθο αποτέλεσμα. Ωστόσο, αυτή η απεικόνιση παράγει το σωστό αποτέλεσμα. Ας εξετάσουμε τώρα τι συμβαίνει όταν η στήλη Color από τον πίνακα Product χρησιμοποιείται για την ομαδοποίηση της ποσότητας-στόχου.

Η απεικόνιση παράγει μια εσφαλμένη απεικόνιση των δεδομένων. Τι συμβαίνει εδώ;

Ένα φίλτρο στη στήλη Color από τον πίνακα Product έχει ως αποτέλεσμα δύο γραμμές. Η μία από τις γραμμές αφορά την κατηγορία Ενδύματα και η άλλη την κατηγορία Αξεσουάρ. Αυτές οι δύο τιμές κατηγορίας μεταδίδονται ως φίλτρα στον πίνακα Target. Με άλλα λόγια, επειδή το μπλε χρώμα χρησιμοποιείται από προϊόντα δύο κατηγοριών, αυτές τις κατηγορίες χρησιμοποιούνται για το φιλτράρισμα των στόχων.

Για να αποφύγετε αυτή τη συμπεριφορά, όπως περιγράφεται παραπάνω, συνιστούμε να ελέγχετε τη σύνοψη δεδομένων των στοιχείων σας χρησιμοποιώντας μετρήσεις.

Εξετάστε τον παρακάτω ορισμό μέτρησης. Παρατηρήστε ότι όλες οι στήλες Product πίνακα που βρίσκονται κάτω από το επίπεδο κατηγορίας ελέγχονται για φίλτρα.

Target Quantity =
IF(
    NOT ISFILTERED('Product'[ProductID])
        && NOT ISFILTERED('Product'[Product])
        && NOT ISFILTERED('Product'[Color]),
    SUM(Target[TargetQuantity])
)

Η ακόλουθη απεικόνιση πίνακα χρησιμοποιεί την Target Quantity μέτρηση. Δείχνει ότι όλες οι ποσότητες-στόχοι χρωμάτων είναι ΚΕΝΕΣ.

Η τελική σχεδίαση μοντέλου μοιάζει ως εξής.

Οδηγίες συσχέτισης στοιχείων με μεγαλύτερη λεπτομέρεια

Όταν πρέπει να συσχετίσετε έναν πίνακα διαστάσεων με έναν πίνακα δεδομένων και ο πίνακας δεδομένων αποθηκεύει γραμμές σε υψηλότερο επίπεδο λεπτομέρειας από τις γραμμές του πίνακα διαστάσεων, ακολουθήστε αυτές τις οδηγίες:

• για ημερομηνίες στοιχείων με μεγαλύτερη λεπτομέρεια
  • Στον πίνακα δεδομένων, αποθηκεύστε την πρώτη ημερομηνία της χρονικής περιόδου.
  • Δημιουργήστε μια σχέση ένα προς πολλά μεταξύ του πίνακα ημερομηνιών και του πίνακα δεδομένων.
• Για άλλα στοιχεία με μεγαλύτερη λεπτομέρεια
  • Δημιουργήστε μια σχέση πολλά-προς-πολλά μεταξύ του πίνακα διαστάσεων και του πίνακα δεδομένων.
• Για αμφότερους τους τύπους
  • Έλεγχος σύνοψης με λογική μέτρησης. Επιστρέψτε ΚΕΝΟ όταν χρησιμοποιούνται στήλες κατώτερου επιπέδου για φιλτράρισμα ή ομαδοποίηση.
  • Απόκρυψη στηλών πίνακα δεδομένων με δυνατότητα σύνοψης, το οποίο εξασφαλίζει ότι μόνο οι μετρήσεις μπορούν να χρησιμοποιηθούν για τη σύνοψη του πίνακα δεδομένων.

Σχετικό περιεχόμενο

Για περισσότερες πληροφορίες σχετικά με αυτό το άρθρο, ανατρέξτε στους παρακάτω πόρους:

• Σχέσεις μοντέλου στο Power BI Desktop
• Κατανοήστε το αστεροειδές σχήμα και τη σημασία του για το Power BI
• Οδηγίες για την αντιμετώπιση προβλημάτων με σχέσεις
• Ερωτήσεις? δοκιμάστε να ρωτήσετε το Κοινότητας Fabric
• Προτάσεις? συνεισφέρετε ιδέες για τη βελτίωση του Fabric