Share via


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

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

Σημείωμα

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

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

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

Σημείωμα

Το Power BI υποστηρίζει πλέον εγγενώς σχέσεις πολλά προς πολλά. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Εφαρμογή σχέσεων πολλά προς πολλά στο Power BI Desktop.

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

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

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

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

Diagram showing a model containing three tables. The design is described in the following paragraph.

Ο πρώτος πίνακας ονομάζεται Λογαριασμόςκαι περιέχει δύο στήλες: Αναγνωριστικό λογαριασμού και Λογαριασμός. Ο δεύτερος πίνακας ονομάζεται Πελάτης λογαριασμούκαι περιέχει δύο στήλες: Αναγνωριστικό λογαριασμού και Αναγνωριστικό πελάτη. Ο τρίτος πίνακας ονομάζεται Πελάτηςκαι περιέχει δύο στήλες: Αναγνωριστικό πελάτη και Πελάτης. Δεν υπάρχουν σχέσεις μεταξύ των πινάκων.

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

Diagram showing that the model now contains four tables. One-to-many relationships have been added to relate all tables.

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

Σημείωμα

Δεν είναι δυνατή η εμφάνιση γραμμών πίνακα στο διάγραμμα μοντέλου Power BI Desktop. Γίνεται σε αυτό το άρθρο για να υποστηρίξει τη συζήτηση με σαφή παραδείγματα.

Diagram showing that the model now reveals the table rows. The row details for the four tables are described in the following paragraph.

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

  • Ο πίνακας Λογαριασμός έχει δύο γραμμές:
    • Το Αναγνωριστικό λογαριασμού 1 είναι για τον Λογαριασμό-01
    • Το Αναγνωριστικό λογαριασμού 2 είναι για τον Λογαριασμό-02
  • Ο πίνακας Πελάτης έχει δύο γραμμές:
    • Το Αναγνωριστικό πελάτη 91 είναι για τον Πελάτη-91
    • Το Αναγνωριστικό πελάτη 92 είναι για τον Πελάτη-92
  • Ο πίνακας Πελάτης λογαριασμού έχει τρεις γραμμές:
    • Το Αναγνωριστικό λογαριασμού 1 σχετίζεται με το Αναγνωριστικό πελάτη 91
    • Το Αναγνωριστικό λογαριασμού 1 σχετίζεται με το Αναγνωριστικό πελάτη 92
    • Το Αναγνωριστικό λογαριασμού 2 σχετίζεται με το Αναγνωριστικό πελάτη 92
  • Ο πίνακας Συναλλαγή έχει τρεις γραμμές:
    • Ημερομηνία 1 Ιανουαρίου 2019, Αναγνωριστικό λογαριασμού 1, Ποσό 100
    • Ημερομηνία 2 Φεβρουαρίου 2019, Αναγνωριστικό λογαριασμού 2, Ποσό 200
    • Ημερομηνία 3 Μαρτίου 2019, Αναγνωριστικό λογαριασμού 1, Ποσό -25

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

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

Diagram showing two report visuals sitting side by side. The visuals are described in the following paragraph.

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

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

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

  • Το υπόλοιπο λογαριασμού πελάτη-91 είναι 275
  • Το υπόλοιπο λογαριασμού πελάτη-92 είναι 275
  • Το σύνολο είναι 275

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

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

Ακολουθήστε τις οδηγίες φιλτραρίσματος σχέσεων από τον πίνακα Πελάτης στον πίνακα Συναλλαγή . Θα πρέπει να είναι προφανές ότι η σχέση μεταξύ του πίνακα Λογαριασμός και του πίνακα Πελάτης λογαριασμού μεταδίδεται προς λάθος κατεύθυνση. Η κατεύθυνση φίλτρου για αυτήν τη σχέση πρέπει να οριστεί σε Και τα δύο.

Diagram showing that the model has been updated. It now filters in both directions.

Diagram showing the same two report visuals sitting side by side. The first visual has not changed, while the second visual has.

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

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

  • Το υπόλοιπο λογαριασμού πελάτη-91 είναι 75
  • Το υπόλοιπο λογαριασμού πελάτη-92 είναι 275
  • Το σύνολο είναι 275

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

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

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

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

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

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

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

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

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

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

Diagram showing a model containing two tables: Order and Fulfillment.

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

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

Diagram showing that the model now reveals the table rows. The row details for the two tables are described in the following paragraph.

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

  • Ο πίνακας Παραγγελία έχει πέντε γραμμές:
    • Παραγγελία 1 Ιανουαρίου 2019, Αναγνωριστικό Παραγγελίας 1, Γραμμή παραγγελίας 1, Αναγνωριστικό προϊόντος Προϊόν Α, Ποσότητα παραγγελίας 5, Πωλήσεις 50
    • Παραγγελία 1 Ιανουαρίου 2019, Αναγνωριστικό Παραγγελίας 1, Γραμμή παραγγελίας 2, Αναγνωριστικό προϊόντος Προϊόν Β, Ποσότητα παραγγελίας 10, Πωλήσεις 80
    • Παραγγελία 2 Φεβρουαρίου 2019, Αναγνωριστικό Παραγγελίας 2, Γραμμή παραγγελίας 1, Αναγνωριστικό προϊόντος Προϊόν Β, Ποσότητα παραγγελίας 5, Πωλήσεις 40
    • Παραγγελία 2 Φεβρουαρίου 2019, Αναγνωριστικό Παραγγελίας 2, Γραμμή παραγγελίας 2, Αναγνωριστικό προϊόντος Προϊόν Γ, Ποσότητα παραγγελίας 1, Πωλήσεις 20
    • Παραγγελία 3 Μαρτίου 2019, Αναγνωριστικό Παραγγελίας 3, Γραμμή παραγγελίας 1, Αναγνωριστικό προϊόντος Προϊόν Γ, Ποσότητα παραγγελίας 5, Πωλήσεις 100
  • Ο πίνακας Διεκπεραίωση έχει τέσσερις γραμμές:
    • Ημερομηνία διεκπεραίωσης 1 Ιανουαρίου 2019, Αναγνωριστικό διεκπεραίωσης 50, Αναγνωριστικό Παραγγελίας 1, Γραμμή παραγγελίας 1, Ποσότητα διεκπεραίωσης 2
    • Ημερομηνία διεκπεραίωσης 2 Φεβρουαρίου 2019, Αναγνωριστικό διεκπεραίωσης 51, Αναγνωριστικό Παραγγελίας 2, Γραμμή παραγγελίας 1, Ποσότητα διεκπεραίωσης 5
    • Ημερομηνία διεκπεραίωσης 2 Φεβρουαρίου 2019, Αναγνωριστικό διεκπεραίωσης 52, Αναγνωριστικό Παραγγελίας 1, Γραμμή παραγγελίας 1, Ποσότητα διεκπεραίωσης 3
    • Ημερομηνία διεκπεραίωσης 1 Ιανουαρίου 2019, Αναγνωριστικό διεκπεραίωσης 53, Αναγνωριστικό Παραγγελίας 1, Γραμμή παραγγελίας 2, Ποσότητα διεκπεραίωσης 10

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

Diagram showing a table visual with three columns: OrderID, OrderQuantity, and FulfillmentQuantity.

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

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

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

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

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

Diagram showing a model includes six tables: OrderLine, OrderDate, Order, Fulfillment, Product, and FulfillmentDate.

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

  • Το μοντέλο έχει πλέον τέσσερις πρόσθετους πίνακες: Γραμμή παραγγελίας, Ημερομηνία παραγγελίας, Προϊόν και Ημερομηνία διεκπεραίωσης
  • Οι τέσσερις πρόσθετοι πίνακες είναι όλοι πίνακες διαστάσεων και οι σχέσεις "ένα-προς-πολλά" συσχετίζουν αυτούς τους πίνακες με τους πίνακες στοιχείων
  • Ο πίνακας Γραμμή παραγγελίας περιέχει μια στήλη Αναγνωριστικό Γραμμής Παραγγελίας, η οποία αντιπροσωπεύει την τιμή Αναγνωριστικό Παραγγελίας πολλαπλασιασμένη επί 100, καθώς και την τιμή Γραμμή παραγγελίας, ένα μοναδικό αναγνωριστικό για κάθε γραμμή παραγγελίας
  • Οι πίνακες Παραγγελία και Διεκπεραίωση περιέχουν τώρα μια στήλη Αναγνωριστικό Γραμμής Παραγγελίας και δεν περιέχουν πλέον τις στήλες Αναγνωριστικό Παραγγελίας και Γραμμή παραγγελίας
  • Ο πίνακας Διεκπεραίωση περιέχει τώρα τις στήλες Ημερομηνία παραγγελίας και Αναγνωριστικό προϊόντος
  • Ο πίνακας Ημερομηνία διεκπεραίωσης σχετίζεται μόνο με τον πίνακα Διεκπεραίωση
  • Όλες οι στήλες μοναδικού αναγνωριστικού είναι κρυφές

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

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

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

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

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

Diagram showing a model including four tables: Date, Sales, Product, and Target.

Ο πίνακας Στόχος περιέχει τρεις στήλες: Κατηγορία, Ποσότητα-στόχοςκαι Έτος-στόχος. Οι γραμμές του πίνακα αποκαλύπτουν μια υποδιαίρεση του έτους και της κατηγορίας προϊόντων. Με άλλα λόγια, οι στόχοι, που χρησιμοποιούνται για τη μέτρηση της απόδοσης των πωλήσεων, ορίζονται κάθε χρόνο για κάθε κατηγορία προϊόντων.

Diagram showing the Target table has three columns: TargetYear, Category, and TargetQuantity.

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

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

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

Φιλοδώρημα

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

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

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

Diagram showing a matrix visual revealing the year 2020 target quantity as 270.

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

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

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

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

Diagram showing a matrix visual revealing the year 2020 target quantity as 270 with blank monthly values.

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

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

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

Diagram showing a model of the Target and Product tables. A many-to-many relationship relates the two tables.

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

Diagram showing a model containing two tables: Target and Product. A many-to-many relationship relates the two Category columns.

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

Μια ομαδοποίηση απεικονίσεων πίνακα με βάση τη στήλη Κατηγορία από τον πίνακα Προϊόν παράγει το ακόλουθο αποτέλεσμα.

Diagram showing a table visual with two columns: Category and TargetQuantity. Accessories is 60, Clothing is 40, and the total is 100.

Αυτή η απεικόνιση παράγει το σωστό αποτέλεσμα. Ας εξετάσουμε τώρα τι συμβαίνει όταν η στήλη Χρώμα από τον πίνακα Προϊόν χρησιμοποιείται για την ομαδοποίηση της ποσότητας-στόχου.

Diagram showing a table visual with two columns: Color and TargetQuantity. Blue is 100, Green is 40, and the total is 100.

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

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

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

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

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

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

Diagram showing a table visual with two columns: Color and TargetQuantity. Blue is BLANK, Green is BLANK, and the total is 100.

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

Diagram showing a model with Date and Target tables related with a one-to-many relationship.

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

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

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

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