Οδηγίες για σχέσεις πολλά προς πολλάMany-to-many relationship guidance

Αυτό το άρθρο αφορά δημιουργούς μοντέλων που εργάζονται με το Power BI Desktop.This article targets you as a data modeler working with Power BI Desktop. Περιγράφει τρία διαφορετικά σενάρια μοντελοποίησης πολλών προς πολλά.It describes three different many-to-many modeling scenarios. Επίσης, σας παρέχει οδηγίες σχετικά με τον τρόπο με τον οποίο μπορείτε να τα σχεδιάσετε με επιτυχία στα μοντέλα σας.It also provides you with guidance on how to successfully design for them in your models.

Σημείωση

Η εισαγωγή στις σχέσεις μοντέλου δεν καλύπτεται σε αυτό το άρθρο.An introduction to model relationships is not covered in this article. Εάν δεν είστε πλήρως εξοικειωμένοι με τις σχέσεις, τις ιδιότητές τους ή τον τρόπο ρύθμισης των παραμέτρων τους, συνιστάται να διαβάσετε πρώτα το άρθρο Σχέσεις μοντέλου στο Power BI Desktop.If you're not completely familiar with relationships, their properties or how to configure them, we recommend that you first read the Model relationships in Power BI Desktop article.

Είναι επίσης σημαντικό να κατανοήσετε τη σχεδίαση αστεροειδούς σχήματος.It's also important that you have an understanding of star schema design. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Κατανοήστε το αστεροειδές σχήμα και τη σημασία του για το Power BI.For more information, see Understand star schema and the importance for Power BI.

Για την ακρίβεια, υπάρχουν τρία σενάρια "πολλά προς πολλά".There are, in fact, three many-to-many scenarios. Αυτά μπορεί να συμβούν όταν σας ζητηθεί να κάνετε τα εξής:They can occur when you're required to:

Συσχέτιση δύο πινάκων διαστάσεωνRelate many-to-many dimensions

Ας εξετάσουμε τον πρώτο τύπο σεναρίου "πολλά προς πολλά" με ένα παράδειγμα.Let's consider the first many-to-many scenario type with an example. Το κλασικό σενάριο αφορά δύο οντότητες: τους πελάτες τραπεζών και τους τραπεζικούς λογαριασμούς.The classic scenario relates two entities: bank customers and bank accounts. Θεωρήστε ότι οι πελάτες μπορούν να έχουν πολλαπλούς λογαριασμούς και οι λογαριασμοί μπορούν να έχουν πολλούς πελάτες.Consider that customers can have multiple accounts, and accounts can have multiple customers. Όταν ένας λογαριασμός διαθέτει πολλούς πελάτες, συνήθως καλούνται κάτοχοι κοινών λογαριασμών.When an account has multiple customers, they're commonly called joint account holders.

Η μοντελοποίηση αυτών των οντοτήτων είναι απλή.Modeling these entities is straight forward. Ένας πίνακας διαστάσεων αποθηκεύει λογαριασμούς και ένας άλλος πίνακας διαστάσεων αποθηκεύει πελάτες.One dimension-type table stores accounts, and another dimension-type table stores customers. Ένα χαρακτηριστικό στους πίνακες διαστάσεων, είναι ότι υπάρχει μια στήλη αναγνωριστικού σε κάθε πίνακα.As is characteristic of dimension-type tables, there's an ID column in each table. Για να μοντελοποιηθεί η σχέση μεταξύ των δύο πινάκων, απαιτείται ένας τρίτος πίνακας.To model the relationship between the two tables, a third table is required. Αυτός ο πίνακας αναφέρεται συχνά ως πίνακας γεφύρωσης.This table is commonly referred to as a bridging table. Σε αυτό το παράδειγμα, σκοπός του είναι να αποθηκεύσει μία γραμμή για κάθε συσχέτιση πελάτη-λογαριασμού.In this example, it's purpose is to store one row for each customer-account association. Είναι ενδιαφέρον ότι, όταν αυτός ο πίνακας περιέχει μόνο στήλες αναγνωριστικού, ονομάζεται πίνακας δεδομένων.Interestingly, when this table only contains ID columns, it's called a factless fact table.

Ακολουθεί ένα απλοϊκό μοντέλο διαγράμματος των τριών πινάκων.Here's a simplistic model diagram of the three tables.

Διάγραμμα που εμφανίζει ένα μοντέλο που περιέχει τρεις πίνακες.

Ο πρώτος πίνακας ονομάζεται Λογαριασμός και περιέχει δύο στήλες: Αναγνωριστικό λογαριασμού και Λογαριασμός.The first table is named Account, and it contains two columns: AccountID and Account. Ο δεύτερος πίνακας ονομάζεται Πελάτης λογαριασμού και περιέχει δύο στήλες: Αναγνωριστικό λογαριασμού και Αναγνωριστικό πελάτη.The second table is named AccountCustomer, and it contains two columns: AccountID and CustomerID. Ο τρίτος πίνακας ονομάζεται Πελάτης και περιέχει δύο στήλες: Αναγνωριστικό πελάτη και Πελάτης.The third table is named Customer, and it contains two columns: CustomerID and Customer. Δεν υπάρχουν σχέσεις μεταξύ των πινάκων.Relationships don't exist between any of the tables.

Προστίθενται δύο σχέσεις "ένα προς πολλά" για να συσχετιστούν οι πίνακες.Two one-to-many relationships are added to relate the tables. Ακολουθεί ένα ενημερωμένο διάγραμμα μοντέλου των σχετικών πινάκων.Here's an updated model diagram of the related tables. Προστέθηκε ένας πίνακας στοιχείων με την ονομασία Συναλλαγή.A fact-type table named Transaction has been added. Καταγράφει συναλλαγές λογαριασμών.It records account transactions. Ο πίνακας γεφύρωσης και όλες οι στήλες αναγνωριστικού έχουν αποκρυφτεί.The bridging table and all ID columns have been hidden.

Διάγραμμα που δείχνει ότι το μοντέλο περιέχει τώρα τέσσερις πίνακες.

Για να σας βοηθήσει να περιγράψετε τον τρόπο με τον οποίο λειτουργεί η μετάδοση του φίλτρου σχέσεων, το διάγραμμα μοντέλου τροποποιήθηκε για να αποκαλύψει τις γραμμές του πίνακα.To help describe how the relationship filter propagation works, the model diagram has been modified to reveal the table rows.

Σημείωση

Δεν είναι δυνατή η εμφάνιση γραμμών πινάκων στο διάγραμμα μοντέλου Power BI Desktop.It's not possible to display table rows in the Power BI Desktop model diagram. Γίνεται όμως σε αυτό το άρθρο για να υποστηριχθεί η συζήτηση με σαφή παραδείγματα.It's done in this article to support the discussion with clear examples.

Διάγραμμα που δείχνει ότι το μοντέλο αποκαλύπτει τώρα τις γραμμές του πίνακα.

Οι λεπτομέρειες γραμμής για τους τέσσερις πίνακες περιγράφονται στην παρακάτω λίστα με κουκκίδες:The row details for the four tables are described in the following bulleted list:

  • Ο πίνακας Λογαριασμός έχει δύο γραμμές:The Account table has two rows:
    • Το Αναγνωριστικό λογαριασμού 1 είναι για τον Λογαριασμό-01AccountID 1 is for Account-01
    • Το Αναγνωριστικό λογαριασμού 2 είναι για τον Λογαριασμό-02AccountID 2 is for Account-02
  • Ο πίνακας Πελάτης έχει δύο γραμμές:The Customer table has two rows:
    • Το Αναγνωριστικό πελάτη 91 είναι για τον Πελάτη-91CustomerID 91 is for Customer-91
    • Το Αναγνωριστικό πελάτη 92 είναι για τον Πελάτη-92CustomerID 92 is for Customer-92
  • Ο πίνακας Πελάτης λογαριασμού έχει τρεις γραμμές:The AccountCustomer table has three rows:
    • Το Αναγνωριστικό λογαριασμού 1 σχετίζεται με το Αναγνωριστικό πελάτη 91AccountID 1 is associated with CustomerID 91
    • Το Αναγνωριστικό λογαριασμού 1 σχετίζεται με το Αναγνωριστικό πελάτη 92AccountID 1 is associated with CustomerID 92
    • Το Αναγνωριστικό λογαριασμού 2 σχετίζεται με το Αναγνωριστικό πελάτη 92AccountID 2 is associated with CustomerID 92
  • Ο πίνακας Συναλλαγή έχει τρεις γραμμές:The Transaction table has three rows:
    • Ημερομηνία 1 Ιανουαρίου 2019, Αναγνωριστικό λογαριασμού 1, Ποσό 100Date January 1 2019, AccountID 1, Amount 100
    • Ημερομηνία 2 Φεβρουαρίου 2019, Αναγνωριστικό λογαριασμού 2, Ποσό 200Date February 2 2019, AccountID 2, Amount 200
    • Ημερομηνία 3 Μαρτίου 2019, Αναγνωριστικό λογαριασμού 1, Ποσό -25Date March 3 2019, AccountID 1, Amount -25

Ας δούμε τι θα συμβεί όταν τεθεί ερώτημα για το μοντέλο.Let's see what happens when the model is queried.

Ακολουθούν δύο απεικονίσεις που συνοψίζουν τη στήλη Ποσό από τον πίνακα Συναλλαγή.Below are two visuals that summarize the Amount column from the Transaction table. Η πρώτη απεικόνιση ομαδοποιεί κατά λογαριασμό και, επομένως, το άθροισμα των στηλών Ποσό αντιπροσωπεύει το υπόλοιπο λογαριασμού.The first visual groups by account, and so the sum of the Amount columns represents the account balance. Η δεύτερη απεικόνιση ομαδοποιεί κατά πελάτη και, επομένως, το άθροισμα των στηλών Ποσό αντιπροσωπεύει το υπόλοιπο πελάτη.The second visual groups by customer, and so the sum of the Amount columns represents the customer balance.

Διάγραμμα που εμφανίζει δύο απεικονίσεις αναφοράς την μία δίπλα στην άλλη.

Η πρώτη απεικόνιση έχει τίτλο Υπόλοιπο λογαριασμού και έχει δύο στήλες: Λογαριασμός και Ποσό.The first visual is titled Account Balance, and it has two columns: Account and Amount. Εμφανίζει το ακόλουθο αποτέλεσμα:It displays the following result:

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

Η δεύτερη απεικόνιση έχει τίτλο Υπόλοιπο πελάτη και έχει δύο στήλες: Πελάτης και Ποσό.The second visual is titled Customer Balance, and it has two columns: Customer and Amount. Εμφανίζει το ακόλουθο αποτέλεσμα:It displays the following result:

  • Λογαριασμός-91, το υπόλοιπο λογαριασμού είναι 275Customer-91 balance amount is 275
  • Λογαριασμός-92, το υπόλοιπο λογαριασμού είναι 275Customer-92 balance amount is 275
  • Το σύνολο είναι 275The total is 275

Μια γρήγορη ματιά στις γραμμές του πίνακα και στην απεικόνιση Υπόλοιπο, αποκαλύπτει ότι το αποτέλεσμα είναι σωστό, για κάθε λογαριασμό και για το συνολικό ποσό.A quick glance at the table rows and the Account Balance visual reveals that the result is correct, for each account and the total amount. Αυτό συμβαίνει επειδή κάθε ομάδα λογαριασμών καταλήγει σε μια μετάδοση φίλτρου στον πίνακα Συναλλαγή για αυτόν το λογαριασμό.It's because each account grouping results in a filter propagation to the Transaction table for that account.

Ωστόσο, κάτι δεν φαίνεται σωστό με την απεικόνιση Υπόλοιπο πελάτη.However, something doesn't appear correct with the Customer Balance visual. Κάθε πελάτης στην απεικόνιση Υπόλοιπο πελάτη έχει το ίδιο υπόλοιπο με το Συνολικό υπόλοιπο.Each customer in the Customer Balance visual has the same balance as the total balance. Αυτό το αποτέλεσμα θα μπορούσε να είναι σωστό μόνο αν κάθε πελάτης ήταν ένας κάτοχος κοινού λογαριασμού για κάθε λογαριασμό.This result could only be correct if every customer was a joint account holder of every account. Αυτό δεν συμβαίνει σε αυτό το παράδειγμα.That's not the case in this example. Το ζήτημα σχετίζεται με τη μετάδοση φίλτρου.The issue is related to filter propagation. Δεν ακολουθεί ολόκληρη τη διαδρομή προς τον πίνακα Συναλλαγή.It's not flowing all the way to the Transaction table.

Ακολουθήστε τις οδηγίες φιλτραρίσματος σχέσεων από τον πίνακα Πελάτης στον πίνακα Συναλλαγή.Follow the relationship filter directions from the Customer table to the Transaction table. Θα πρέπει να είναι φανερό ότι η σχέση μεταξύ του πίνακα Λογαριασμός και του πίνακα Πελάτης λογαριασμού μεταδίδεται προς λάθος κατεύθυνση.It should be apparent that the relationship between the Account and AccountCustomer table is propagating in the wrong direction. Η κατεύθυνση φίλτρου για αυτή τη σχέση πρέπει να οριστεί σε Και τα δύο.The filter direction for this relationship must be set to Both.

Διάγραμμα που δείχνει ότι το μοντέλο έχει ενημερωθεί.

Διάγραμμα που εμφανίζει τις ίδιες δύο απεικονίσεις αναφοράς, τη μία δίπλα στην άλλη.

Όπως αναμενόταν, δεν υπήρξε καμία αλλαγή στην απεικόνιση Υπόλοιπο λογαριασμού.As expected, there has been no change to the Account Balance visual.

Ωστόσο, η απεικόνιση Υπόλοιπο πελάτη εμφανίζει το εξής αποτέλεσμα:The Customer Balance visuals, however, now displays the following result:

  • Το υπόλοιπο λογαριασμού για το στοιχείο "Λογαριασμός-91" είναι 75Customer-91 balance amount is 75
  • Λογαριασμός-92, το υπόλοιπο λογαριασμού είναι 275Customer-92 balance amount is 275
  • Το σύνολο είναι 275The total is 275

Η απεικόνιση Υπόλοιπο πελάτη εμφανίζει τώρα το σωστό αποτέλεσμα.The Customer Balance visual now displays a correct result. Ακολουθήστε τις οδηγίες φιλτραρίσματος για την δική σας περίπτωση και δείτε τον τρόπο υπολογισμού των υπολοίπων πελατών.Follow the filter directions for yourself, and see how the customer balances were calculated. Επίσης, κατανοήστε ότι το σύνολο απεικόνισης σημαίνει όλοι οι πελάτες.Also, understand that the visual total means all customers.

Κάποιος που δεν είναι εξοικειωμένος με τις σχέσεις μοντέλου μπορεί να συμπεράνει ότι το αποτέλεσμα είναι εσφαλμένο.Someone unfamiliar with the model relationships could conclude that the result is incorrect. Μπορεί να ρωτήσουν: Γιατί δεν είναι το συνολικό ισοζύγιο για τον Πελάτη-91 και τον Πελάτη-92 ίσο με 350 (75 + 275);They might ask: Why isn't the total balance for Customer-91 and Customer-92 equal to 350 (75 + 275)?

Η απάντηση στην ερώτησή τους έγκειται στην κατανόηση της σχέσης "πολλά προς πολλά".The answer to their question lies in understanding the many-to-many relationship. Κάθε υπόλοιπο πελάτη μπορεί να αντιπροσωπεύει την προσθήκη πολλών υπολοίπων λογαριασμών και, επομένως, τα υπόλοιπα πελατών είναι μη προσθετικά.Each customer balance can represent the addition of multiple account balances, and so the customer balances are non-additive.

Οδηγίες συσχέτισης διαστάσεων "πολλά προς πολλά"Relate many-to-many dimensions guidance

Όταν έχετε μια σχέση "πολλά-προς-πολλά" μεταξύ πινάκων διαστάσεων, παρέχουμε τις παρακάτω οδηγίες:When you have a many-to-many relationship between dimension-type tables, we provide the following guidance:

  • Προσθέστε κάθε σχετική οντότητα "πολλά-προς-πολλά" ως πίνακα μοντέλου, εξασφαλίζοντας ότι διαθέτει μια στήλη μοναδικού αναγνωριστικού (ID)Add each many-to-many related entity as a model table, ensuring it has a unique identifier (ID) column
  • Προσθήκη ενός πίνακα γεφύρωσης για την αποθήκευση συσχετισμένων οντοτήτωνAdd a bridging table to store associated entities
  • Δημιουργία σχέσεων "ένα-προς-πολλά" μεταξύ των τριών πινάκωνCreate one-to-many relationships between the three tables
  • Ρυθμίστε τις παραμέτρους μίας αμφίδρομης σχέσης για να επιτρέψετε τη μετάδοση φίλτρου ώστε να συνεχίσετε στους πίνακες στοιχείωνConfigure one bi-directional relationship to allow filter propagation to continue to the fact-type tables
  • Όταν δεν είναι σωστό να λείπουν τιμές αναγνωριστικού, ορίστε την ιδιότητα Is Nullable των στηλών αναγνωριστικού σε FALSE. Η ανανέωση δεδομένων θα αποτύχει, εάν προκύψουν τιμές που λείπουνWhen it isn't appropriate to have missing ID values, set the Is Nullable property of ID columns to FALSE—data refresh will then fail if missing values are sourced
  • Κάντε απόκρυψη του πίνακα γεφύρωσης (εκτός αν περιέχει πρόσθετες στήλες ή μέτρα που απαιτούνται για την αναφορά)Hide the bridging table (unless it contains additional columns or measures required for reporting)
  • Κάντε απόκρυψη τυχόν στηλών αναγνωριστικού που δεν είναι κατάλληλες για την αναφορά (για παράδειγμα, όταν τα αναγνωριστικά είναι υποκατάστατα κλειδιά)Hide any ID columns that aren't suitable for reporting (for example, when IDs are surrogate keys)
  • Εάν έχει νόημα να αφήσετε ορατή μια στήλη αναγνωριστικού, βεβαιωθείτε ότι είναι στη διαφάνεια "ένα" της σχέσης. Να αποκρύπτετε πάντα την πλευρά "πολλά".If it makes sense to leave an ID column visible, ensure that it's on the "one" slide of the relationship—always hide the "many" side column. Αυτό έχει ως αποτέλεσμα την καλύτερη απόδοση φίλτρου.It results in the best filter performance.
  • Για να αποφύγετε τυχόν σύγχυση ή παρερμηνεία, κοινοποιήστε επεξηγήσεις στους χρήστες της αναφοράς σας. Μπορείτε να προσθέσετε περιγραφές με πλαίσια κειμένου ή επεξηγήσεις εργαλείων κεφαλίδας απεικόνισηςTo avoid confusion or misinterpretation, communicate explanations to your report users—you can add descriptions with text boxes or visual header tooltips

Δεν συνιστούμε να συσχετίζετε απευθείας πίνακες διαστάσεων "πολλά προς πολλά".We don't recommend you relate many-to-many dimension-type tables directly. Αυτή η προσέγγιση σχεδίασης απαιτεί τη ρύθμιση μιας σχέσης με πληθικότητα "πολλά προς πολλά".This design approach requires configuring a relationship with a many-to-many cardinality. Εννοιολογικά μπορεί να επιτευχθεί, ωστόσο υπονοεί ότι οι σχετικές στήλες θα περιέχουν διπλότυπες τιμές.Conceptually it can be achieved, yet it implies that the related columns will contain duplicate values. Ωστόσο, η σωστή πρακτική σχεδίασης είναι ότι οι πίνακες διαστάσεων έχουν μια στήλη αναγνωριστικού.It's a well-accepted design practice, however, that dimension-type tables have an ID column. Οι πίνακες διαστάσεων πρέπει να χρησιμοποιούν πάντα τη στήλη "Αναγνωριστικό" ως πλευρά "ένα" μιας σχέσης.Dimension-type tables should always use the ID column as the "one" side of a relationship.

Συσχέτιση στοιχείων "πολλά προς πολλά"Relate many-to-many facts

Ο δεύτερος τύπος σεναρίου "πολλά προς πολλά" περιλαμβάνει τη συσχέτιση δύο πινάκων στοιχείων.The second many-to-many scenario type involves relating two fact-type tables. Δύο πίνακες στοιχείων μπορεί να συσχετιστούν άμεσα.Two fact-type tables can be related directly. Αυτή η τεχνική σχεδίασης μπορεί να είναι χρήσιμη για γρήγορη και απλή εξερεύνηση δεδομένων.This design technique can be useful for quick and simple data exploration. Ωστόσο, και για να είμαστε ξεκάθαροι, γενικά δεν συνιστούμε αυτή την προσέγγιση σχεδίασης.However, and to be clear, we generally don't recommend this design approach. Θα εξηγήσουμε γιατί αργότερα σε αυτή την ενότητα.We'll explain why later in this section.

Ας δούμε ένα παράδειγμα που περιλαμβάνει δύο πίνακες στοιχείων: Παραγγελία και Διεκπεραίωση.Let's consider an example that involves two fact-type tables: Order and Fulfillment. Ο πίνακας Παραγγελία περιέχει μία γραμμή ανά γραμμή παραγγελίας και ο πίνακας Διεκπεραίωση μπορεί να περιέχει μηδέν ή περισσότερες γραμμές ανά γραμμή παραγγελίας.The Order table contains one row per order line, and the Fulfillment table can contains zero or more rows per order line. Οι γραμμές στον πίνακα Παραγγελία αντιπροσωπεύουν παραγγελίες πωλήσεων.Rows in the Order table represent sales orders. Οι γραμμές στον πίνακα Διεκπεραίωση αντιπροσωπεύουν στοιχεία παραγγελιών που έχουν αποσταλεί.Rows in the Fulfillment table represent order items that have been shipped. Μια σχέση "πολλά-προς-πολλά" συσχετίζει τις δύο στήλες Αναγνωριστικό παραγγελίας, με την μετάδοση φίλτρου μόνο από τον πίνακα Παραγγελία (ο πίνακας Παραγγελία φιλτράρει τον πίνακα Διεκπεραίωση).A many-to-many relationship relates the two OrderID columns, with filter propagation only from the Order table (Order filters Fulfillment).

Διάγραμμα που εμφανίζει ένα μοντέλο που περιέχει δύο πίνακες: Παραγγελία και Διεκπεραίωση.

Η πληθικότητα της σχέσης έχει οριστεί σε "πολλά-προς-πολλά" για να υποστηρίξει την αποθήκευση διπλότυπων τιμών Αναγνωριστικό Παραγγελίας και στους δύο πίνακες.The relationship cardinality is set to many-to-many to support storing duplicate OrderID values in both tables. Στον πίνακα Παραγγελία, μπορούν να υπάρχουν διπλότυπες τιμές για το Αναγνωριστικό Παραγγελίας, επειδή μια σειρά μπορεί να έχει πολλές γραμμές.In the Order table, duplicate OrderID values can exist because an order can have multiple lines. Στον πίνακα Διεκπεραίωση, μπορούν να υπάρχουν διπλότυπες τιμές για το Αναγνωριστικό Παραγγελίας, επειδή οι παραγγελίες μπορεί να έχουν πολλές γραμμές και οι γραμμές παραγγελίας μπορούν να ικανοποιηθούν από πολλές αποστολές.In the Fulfillment table, duplicate OrderID values can exist because orders may have multiple lines, and order lines can be fulfilled by many shipments.

Ας ρίξουμε μια ματιά στις γραμμές του πίνακα.Let's now take a look at the table rows. Στον πίνακα Διεκπεραίωση, παρατηρήστε ότι οι γραμμές παραγγελιών μπορούν να ικανοποιηθούν από πολλαπλές αποστολές.In the Fulfillment table, notice that order lines can be fulfilled by multiple shipments. (Η απουσία μιας γραμμής παραγγελίας σημαίνει ότι η σειρά δεν έχει διεκπεραιωθεί ακόμα.)(The absence of an order line means the order is yet to be fulfilled.)

Διάγραμμα που δείχνει ότι το μοντέλο αποκαλύπτει τώρα τις γραμμές του πίνακα.

Οι λεπτομέρειες γραμμής για τους δύο πίνακες περιγράφονται στην παρακάτω λίστα με κουκκίδες:The row details for the two tables are described in the following bulleted list:

  • Ο πίνακας Παραγγελία έχει πέντε γραμμές:The Order table has five rows:
    • Παραγγελία 1 Ιανουαρίου 2019, Αναγνωριστικό Παραγγελίας 1, Γραμμή παραγγελίας 1, Αναγνωριστικό προϊόντος Προϊόν Α, Ποσότητα παραγγελίας 5, Πωλήσεις 50OrderDate January 1 2019, OrderID 1, OrderLine 1, ProductID Prod-A, OrderQuantity 5, Sales 50
    • Παραγγελία 1 Ιανουαρίου 2019, Αναγνωριστικό Παραγγελίας 1, Γραμμή παραγγελίας 2, Αναγνωριστικό προϊόντος Προϊόν Β, Ποσότητα παραγγελίας 10, Πωλήσεις 80OrderDate January 1 2019, OrderID 1, OrderLine 2, ProductID Prod-B, OrderQuantity 10, Sales 80
    • Παραγγελία 2 Φεβρουαρίου 2019, Αναγνωριστικό Παραγγελίας 2, Γραμμή παραγγελίας 1, Αναγνωριστικό προϊόντος Προϊόν Β, Ποσότητα παραγγελίας 5, Πωλήσεις 40OrderDate February 2 2019, OrderID 2, OrderLine 1, ProductID Prod-B, OrderQuantity 5, Sales 40
    • Παραγγελία 2 Φεβρουαρίου 2019, Αναγνωριστικό Παραγγελίας 2, Γραμμή παραγγελίας 2, Αναγνωριστικό προϊόντος Προϊόν Γ, Ποσότητα παραγγελίας 1, Πωλήσεις 20OrderDate February 2 2019, OrderID 2, OrderLine 2, ProductID Prod-C, OrderQuantity 1, Sales 20
    • Παραγγελία 3 Μαρτίου 2019, Αναγνωριστικό Παραγγελίας 3, Γραμμή παραγγελίας 1, Αναγνωριστικό προϊόντος Προϊόν Γ, Ποσότητα παραγγελίας 5, Πωλήσεις 100OrderDate March 3 2019, OrderID 3, OrderLine 1, ProductID Prod-C, OrderQuantity 5, Sales 100
  • Ο πίνακας Διεκπεραίωση έχει τέσσερις γραμμές:The Fulfillment table has four rows:
    • Ημερομηνία διεκπεραίωσης 1 Ιανουαρίου 2019, Αναγνωριστικό διεκπεραίωσης 50, Αναγνωριστικό Παραγγελίας 1, Γραμμή παραγγελίας 1, Ποσότητα διεκπεραίωσης 2FulfillmentDate January 1 2019, FulfillmentID 50, OrderID 1, OrderLine 1, FulfillmentQuantity 2
    • Ημερομηνία διεκπεραίωσης 2 Φεβρουαρίου 2019, Αναγνωριστικό διεκπεραίωσης 51, Αναγνωριστικό Παραγγελίας 2, Γραμμή παραγγελίας 1, Ποσότητα διεκπεραίωσης 5FulfillmentDate February 2 2019, FulfillmentID 51, OrderID 2, OrderLine 1, FulfillmentQuantity 5
    • Ημερομηνία διεκπεραίωσης 2 Φεβρουαρίου 2019, Αναγνωριστικό διεκπεραίωσης 52, Αναγνωριστικό Παραγγελίας 1, Γραμμή παραγγελίας 1, Ποσότητα διεκπεραίωσης 3FulfillmentDate February 2 2019, FulfillmentID 52, OrderID 1, OrderLine 1, FulfillmentQuantity 3
    • Ημερομηνία διεκπεραίωσης 1 Ιανουαρίου 2019, Αναγνωριστικό διεκπεραίωσης 53, Αναγνωριστικό Παραγγελίας 1, Γραμμή παραγγελίας 2, Ποσότητα διεκπεραίωσης 10FulfillmentDate January 1 2019, FulfillmentID 53, OrderID 1, OrderLine 2, FulfillmentQuantity 10

Ας δούμε τι θα συμβεί όταν τεθεί ερώτημα για το μοντέλο.Let's see what happens when the model is queried. Ακολουθεί μια απεικόνιση πίνακα που συγκρίνει τις ποσότητες παραγγελίας και διεκπεραίωσης από τον πίνακα Παραγγελία, στήλη Αναγνωριστικό Παραγγελίας.Here's a table visual comparing order and fulfillment quantities by the Order table OrderID column.

Διάγραμμα που εμφανίζει μια απεικόνιση πίνακα με τρεις στήλες: Αναγνωριστικό Παραγγελίας, Ποσότητα παραγγελίας και Ποσότητα διεκπεραίωσης.

Η απεικόνιση εμφανίζει ένα ακριβές αποτέλεσμα.The visual presents an accurate result. Ωστόσο, η χρησιμότητα του μοντέλου είναι περιορισμένη, επειδή-μπορείτε να φιλτράρετε ή να ομαδοποιήσετε μόνο σύμφωνα με τον πίνακα Παραγγελία, στήλη Αναγνωριστικό Παραγγελίας.However, the usefulness of the model is limited—you can only filter or group by the Order table OrderID column.

Οδηγίες για τη συσχέτιση στοιχείων "πολλά προς πολλά"Relate many-to-many facts guidance

Σε γενικές γραμμές, δεν συνιστούμε να συσχετίζετε απευθείας δύο πίνακες στοιχείων, χρησιμοποιώντας πληθικότητα "πολλά-προς-πολλά".Generally, we don't recommend relating two fact-type tables directly using many-to-many cardinality. Η κύρια αιτία είναι ότι το μοντέλο δεν θα παρέχει ευελιξία στους τρόπους με τους οποίους αναφέρετε φίλτρα ή ομάδες απεικονίσεων.The main reason is because the model won't provide flexibility in the ways you report visuals filter or group. Στο παράδειγμα, οι απεικονίσεις μπορούν να φιλτραριστούν ή να ομαδοποιηθούν μόνο σύμφωνα με τον πίνακα Παραγγελία, στήλη Αναγνωριστικό Παραγγελίας.In the example, it's only possible for visuals to filter or group by the Order table OrderID column. Ένας επιπλέον λόγος σχετίζεται με την ποιότητα των δεδομένων σας.An additional reason relates to the quality of your data. Εάν τα δεδομένα σας έχουν προβλήματα ακεραιότητας, είναι πιθανό ορισμένες γραμμές να παραλειφθούν κατά την υποβολή ερωτημάτων λόγω της φύσης της περιορισμένης σχέσης.If your data has integrity issues, it's possible some rows may be omitted during querying due to the nature of the limited relationship. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Σχέσεις μοντέλων στο Power BI Desktop (αξιολόγηση σχέσεων).For more information, see Model relationships in Power BI Desktop (Relationship evaluation).

Αντί να συσχετίζετε απευθείας πίνακες στοιχείων, συνιστούμε να υιοθετήσετε τις αρχές σχεδίασης Αστεροειδές σχήμα.Instead of relating fact-type tables directly, we recommend you adopt Star Schema design principles. Μπορείτε να το κάνετε με την προσθήκη πινάκων διαστάσεων.You do it by adding dimension-type tables. Οι πίνακες διαστάσεων συσχετίζονται με τους πίνακες στοιχείων, χρησιμοποιώντας σχέσεις "ένα-προς-πολλά".The dimension-type tables then relate to the fact-type tables by using one-to-many relationships. Αυτή η προσέγγιση σχεδίασης είναι στιβαρή, καθώς παρέχει ευέλικτες επιλογές αναφοράς.This design approach is robust as it delivers flexible reporting options. Σας επιτρέπει να φιλτράρετε ή να ομαδοποιήσετε χρησιμοποιώντας οποιαδήποτε από τις στήλες διαστάσεων και να συνοψίσετε κάθε σχετικό πίνακα στοιχείων.It lets you filter or group using any of the dimension-type columns, and summarize any related fact-type table.

Ας εξετάσουμε μια καλύτερη λύση.Let's consider a better solution.

Διάγραμμα που εμφανίζει ένα μοντέλο που περιλαμβάνει έξι πίνακες: Γραμμή παραγγελίας, Ημερομηνία παραγγελίας, Διεκπεραίωση, Προϊόν και Ημερομηνία διεκπεραίωσης.

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

  • Το μοντέλο έχει πλέον τέσσερις πρόσθετους πίνακες: Γραμμή παραγγελίας, Ημερομηνία παραγγελίας, Προϊόν και Ημερομηνία διεκπεραίωσηςThe model now has four additional tables: OrderLine, OrderDate, Product, and FulfillmentDate
  • Οι τέσσερις πρόσθετοι πίνακες είναι όλοι πίνακες διαστάσεων και οι σχέσεις "ένα-προς-πολλά" συσχετίζουν αυτούς τους πίνακες με τους πίνακες στοιχείωνThe four additional tables are all dimension-type tables, and one-to-many relationships relate these tables to the fact-type tables
  • Ο πίνακας Γραμμή παραγγελίας περιέχει μια στήλη Αναγνωριστικό Γραμμής Παραγγελίας, η οποία αντιπροσωπεύει την τιμή Αναγνωριστικό Παραγγελίας πολλαπλασιασμένη επί 100, καθώς και την τιμή Γραμμή παραγγελίας, ένα μοναδικό αναγνωριστικό για κάθε γραμμή παραγγελίαςThe OrderLine table contains an OrderLineID column, which represents the OrderID value multiplied by 100, plus the OrderLine value—a unique identifier for each order line
  • Οι πίνακες Παραγγελία και Διεκπεραίωση περιλαμβάνουν τώρα μια στήλη Αναγνωριστικό Γραμμής Παραγγελίας και δεν περιέχουν πλέον τις στήλες Αναγνωριστικό Παραγγελίας και Γραμμή παραγγελίαςThe Order and Fulfillment tables now contain an OrderLineID column, and they no longer contain the OrderID and OrderLine columns
  • Ο πίνακας Διεκπεραίωση περιέχει τώρα τις στήλες Ημερομηνία παραγγελίας και Αναγνωριστικό προϊόντοςThe Fulfillment table now contains OrderDate and ProductID columns
  • Ο πίνακας Ημερομηνία διεκπεραίωσης σχετίζεται μόνο τον πίνακα ΔιεκπεραίωσηThe FulfillmentDate table relates only to the Fulfillment table
  • Όλες οι στήλες μοναδικού αναγνωριστικού είναι κρυφέςAll unique identifier columns are hidden

Η αφιέρωση χρόνου για την εφαρμογή των αρχών σχεδίασης αστεροειδούς σχήματος παρέχει τα εξής πλεονεκτήματα:Taking the time to apply star schema design principles delivers the following benefits:

  • Οι απεικονίσεις της αναφοράς σας μπορούν να φιλτραριστούν ή να ομαδοποιηθούν από οποιαδήποτε ορατή στήλη από τους πίνακες διαστάσεωνYour report visuals can filter or group by any visible column from the dimension-type tables
  • Οι απεικονίσεις της αναφοράς σας μπορούν να συνοψίσουν οποιαδήποτε ορατή στήλη από τους πίνακες στοιχείωνYour report visuals can summarize any visible column from the fact-type tables
  • Τα φίλτρα που εφαρμόζονται στους πίνακες Γραμμή παραγγελίας, Ημερομηνία παραγγελίας ή Προϊόν θα μεταδοθούν και στους δύο πίνακες στοιχείωνFilters applied to the OrderLine, OrderDate, or Product tables will propagate to both fact-type tables
  • Όλες οι σχέσεις είναι τύπου "ένα-προς-πολλά" και κάθε σχέση είναι μια κανονική σχέση.All relationships are one-to-many, and each relationship is a regular relationship. Τα ζητήματα ακεραιότητας δεδομένων δεν θα καλυφθούν.Data integrity issues won't be masked. Για περισσότερες πληροφορίες, ανατρέξτε στο θέμα Σχέσεις μοντέλων στο Power BI Desktop (αξιολόγηση σχέσεων).For more information, see Model relationships in Power BI Desktop (Relationship evaluation).

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

Αυτό το σενάριο τύπου "πολλά-προς-πολλά" είναι πολύ διαφορετικό από τα άλλα δύο που περιγράφονται ήδη σε αυτό το άρθρο.This many-to-many scenario is very different from the other two already described in this article.

Ας δούμε ένα παράδειγμα που περιλαμβάνει τέσσερις πίνακες: Ημερομηνία, Πωλήσεις, Προϊόν και Στόχος.Let's consider an example involving four tables: Date, Sales, Product, and Target. Οι πίνακες Ημερομηνία και Προϊόν είναι πίνακες διαστάσεων και οι σχέσεις "ένα-προς-πολλά" συσχετίζουν κάθε έναν από αυτούς με τον πίνακα στοιχείων Πωλήσεις.The Date and Product are dimension-type tables, and one-to-many relationships relate each to the Sales fact-type table. Μέχρι στιγμής, αντιπροσωπεύει ένα καλό αστεροειδές σχήμα.So far, it represents a good star schema design. Ωστόσο, ο πίνακας Στόχος δεν έχει συσχετιστεί ακόμα με τους άλλους πίνακες.The Target table, however, is yet to be related to the other tables.

Διάγραμμα που εμφανίζει ένα μοντέλο που περιλαμβάνει τέσσερις πίνακες: Ημερομηνία, Πωλήσεις, Προϊόν και Στόχος.

Ο πίνακας Στόχος περιέχει τρεις στήλες: Κατηγορία, Ποσότητα-στόχος και Έτος-στόχος.The Target table contains three columns: Category, TargetQuantity, and TargetYear. Οι γραμμές του πίνακα αποκαλύπτουν μια υποδιαίρεση του έτους και της κατηγορίας προϊόντων.The table rows reveal a granularity of year and product category. Με άλλα λόγια, οι στόχοι, οι οποίοι χρησιμοποιούνται για τη μέτρηση της απόδοσης των πωλήσεων, ορίζονται κάθε χρόνο για κάθε κατηγορία προϊόντων.In other words, targets—used to measure sales performance—are set each year for each product category.

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

Επειδή ο πίνακας Στόχος αποθηκεύει δεδομένα σε υψηλότερο επίπεδο από τους πίνακες διαστάσεων, δεν είναι δυνατή η δημιουργία σχέσης "ένα-προς-πολλά".Because the Target table stores data at a higher level than the dimension-type tables, a one-to-many relationship cannot be created. Λοιπόν, αυτό ισχύει μόνο για μία από τις σχέσεις.Well, it's true for just one of the relationships. Ας εξετάσουμε τον τρόπο με τον οποίο ο πίνακας Στόχος μπορεί να συσχετιστεί με τους πίνακες διαστάσεων.Let's explore how the Target table can be related to the dimension-type tables.

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

Μια σχέση μεταξύ των πινάκων Ημερομηνία και Στόχος πρέπει να είναι μια σχέση "ένα-προς-πολλά".A relationship between the Date and Target tables should be a one-to-many relationship. Αυτό συμβαίνει επειδή οι τιμές της στήλης Έτος-στόχος είναι ημερομηνίες.It's because the TargetYear column values are dates. Σε αυτό το παράδειγμα, κάθε τιμή της στήλης Έτος-στόχος είναι η πρώτη ημερομηνία του έτους-στόχου.In this example, each TargetYear column value is the first date of the target year.

Συμβουλή

Κατά την αποθήκευση στοιχείων σε μεγαλύτερη χρονική πληθικότητα από την ημέρα, ορίστε τον τύπο δεδομένων στήλης σε ΗμερομηνίαΑκέραιο αριθμό εάν χρησιμοποιείτε κλειδιά ημερομηνίας).When storing facts at a higher time granularity than day, set the column data type to Date (or Whole number if you're using date keys). Στην στήλη, αποθηκεύστε μια τιμή που αντιπροσωπεύει την πρώτη ημέρα της χρονικής περιόδου.In the column, store a value representing the first day of the time period. Για παράδειγμα, μια περίοδος έτους καταγράφεται ως 1 Ιανουαρίου του έτους και η περίοδος ενός μήνα καταγράφεται ως η πρώτη ημέρα αυτού του μήνα.For example, a year period is recorded as January 1 of the year, and a month period is recorded as the first day of that month.

Ωστόσο, πρέπει να λαμβάνεται μέριμνα για να διασφαλιστεί ότι τα φίλτρα επιπέδου μήνα ή ημερομηνίας παράγουν ένα ουσιαστικό αποτέλεσμα.Care must be taken, however, to ensure that month or date level filters produce a meaningful result. Χωρίς κάποια ειδική λογική υπολογισμού, οι απεικονίσεις αναφοράς μπορούν να αναφέρουν ότι οι ημερομηνίες-στόχοι είναι κυριολεκτικά η πρώτη ημέρα κάθε έτους.Without any special calculation logic, report visuals may report that target dates are literally the first day of each year. Όλες οι άλλες ημέρες, καθώς και όλοι οι μήνες εκτός από τον Ιανουάριο, θα συνοψίσουν την ποσότητα-στόχος ως ΚΕΝΟ.All other days—and all months except January—will summarize the target quantity as BLANK.

Η παρακάτω απεικόνιση μήτρας εμφανίζει τι συμβαίνει όταν ο χρήστης της αναφοράς πραγματοποιεί άντληση στοιχείων από ένα έτος στους μήνες του.The following matrix visual shows what happens when the report user drills from a year into its months. Η απεικόνιση συνοψίζει τη στήλη Ποσότητα-στόχος.The visual is summarizing the TargetQuantity column. (Η επιλογή Εμφάνιση στοιχείων χωρίς δεδομένα έχει ενεργοποιηθεί για τις γραμμές μήτρας.)(The Show items with no data option has been enabled for the matrix rows.)

Διάγραμμα που δείχνει μια απεικόνιση μήτρας που αποκαλύπτει την ποσότητα-στόχο του έτους 2020 ως 270.

Για να αποφύγετε αυτή τη συμπεριφορά, συνιστάται να ελέγχετε τη σύνοψη δεδομένων των στοιχείων σας, χρησιμοποιώντας μετρήσεις.To avoid this behavior, we recommend you control the summarization of your fact data by using measures. Ένας τρόπος για τον έλεγχο της σύνοψης είναι η επιστροφή της τιμής ΚΕΝΟ κατά την υποβολή ερωτημάτων σε χρονικές περιόδους κατώτερου επιπέδου.One way to control the summarization is to return BLANK when lower-level time periods are queried. Ένας άλλος τρόπος, που ορίζεται με κάποια εξελιγμένη DAX, είναι η κατανομή τιμών σε περιόδους χαμηλότερου επιπέδου.Another way—defined with some sophisticated DAX—is to apportion values across lower-level time periods.

Εξετάστε τον παρακάτω ορισμό μέτρησης που χρησιμοποιεί τη συνάρτηση DAX ISFILTERED.Consider the following measure definition that uses the ISFILTERED DAX function. Επιστρέφει μια τιμή μόνο όταν οι στήλες Ημερομηνία ή Μήνας δεν φιλτράρονται.It only returns a value when the Date or Month columns aren't filtered.

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

Η ακόλουθη απεικόνιση μήτρας χρησιμοποιεί τώρα την μέτρηση Ποσότητα-στόχος.The following matrix visual now uses the Target Quantity measure. Δείχνει ότι όλες οι μηνιαίες ποσότητες-στόχοι είναι ΚΕΝΕΣ.It shows that all monthly target quantities are BLANK.

Διάγραμμα που εμφανίζει μια απεικόνιση μήτρας που αποκαλύπτει την ποσότητα-στόχο του έτους 2020 ως 270 με κενές τιμές μήνα.

Συσχέτιση με μεγαλύτερη λεπτομέρεια (χωρίς ημερομηνία)Relate higher grain (non-date)

Απαιτείται διαφορετική προσέγγιση σχεδίασης όταν συσχετίζεται μια στήλη που δεν περιέχει ημερομηνίες από έναν πίνακα διαστάσεων σε έναν πίνακα στοιχείων (και βρίσκεται σε υψηλότερο επίπεδο λεπτομέρειας από τον πίνακα διαστάσεων).A different design approach is required when relating a non-date column from a dimension-type table to a fact-type table (and it's at a higher grain than the dimension-type table).

Οι στήλες Κατηγορία (τόσο από τον πίνακα Προϊόν όσο και από τον πίνακα Στόχος) περιέχουν διπλότυπες τιμές.The Category columns (from both the Product and Target tables) contains duplicate values. Επομένως, δεν υπάρχει το τμήμα "ένα" για μια σχέση "ένα-προς-πολλά".So, there's no "one" for a one-to-many relationship. Σε αυτή την περίπτωση, θα χρειαστεί να δημιουργήσετε μια σχέση "πολλά-προς-πολλά".In this case, you'll need to create a many-to-many relationship. Η σχέση θα πρέπει να μεταδίδει φίλτρα προς μία κατεύθυνση, από τον πίνακα διαστάσεων στον πίνακα στοιχείων.The relationship should propagate filters in a single direction, from the dimension-type table to the fact-type table.

Διάγραμμα που δείχνει ένα μοντέλο των πινάκων "Στόχος" και "Προϊόν".

Ας ρίξουμε μια ματιά στις γραμμές του πίνακα.Let's now take a look at the table rows.

Διάγραμμα που εμφανίζει ένα μοντέλο που περιέχει δύο πίνακες: "Στόχος" και "Προϊόν".

Στον πίνακα Στόχος, υπάρχουν τέσσερις γραμμές: δύο γραμμές για κάθε έτος-στόχο (2019 και 2020) και δύο κατηγορίες (Ενδύματα και Αξεσουάρ).In the Target table, there are four rows: two rows for each target year (2019 and 2020), and two categories (Clothing and Accessories). Στον πίνακα Προϊόν, υπάρχουν τρία προϊόντα.In the Product table, there are three products. Τα δύο ανήκουν στην κατηγορία Ενδύματα και το ένα ανήκει στην κατηγορία Αξεσουάρ.Two belong to the clothing category, and one belongs to the accessories category. Ένα από τα χρώματα ενδυμάτων είναι το πράσινο και τα υπόλοιπα δύο είναι μπλε.One of the clothing colors is green, and the remaining two are blue.

Μια ομαδοποίηση απεικονίσεων πινάκων με βάση τη στήλη Κατηγορία από τον πίνακα Προϊόν παράγει το ακόλουθο αποτέλεσμα.A table visual grouping by the Category column from the Product table produces the following result.

Διάγραμμα που εμφανίζει μια απεικόνιση πίνακα με δύο στήλες: Κατηγορία και Ποσότητα-στόχος.

Αυτή η απεικόνιση παράγει το σωστό αποτέλεσμα.This visual produces the correct result. Ας εξετάσουμε τώρα τι συμβαίνει όταν η στήλη Χρώμα από τον πίνακα Προϊόν χρησιμοποιείται για την ομαδοποίηση της ποσότητας-στόχου.Let's now consider what happens when the Color column from the Product table is used to group target quantity.

Διάγραμμα που εμφανίζει μια απεικόνιση πίνακα με δύο στήλες: Χρώμα και Ποσότητα-στόχος.

Η απεικόνιση παράγει μια ψευδή απεικόνιση των δεδομένων.The visual produces a misrepresentation of the data. Τι συμβαίνει εδώ;What is happening here?

Ένα φίλτρο στη στήλη Χρώμα από τον πίνακα Προϊόν καταλήγει σε δύο γραμμές.A filter on the Color column from the Product table results in two rows. Η μία από τις σειρές αφορά την κατηγορία Ενδύματα και η άλλη την κατηγορία Αξεσουάρ.One of the rows is for the Clothing category, and the other is for the Accessories category. Αυτές οι δύο τιμές κατηγορίας μεταδίδονται ως φίλτρα στον πίνακα Στόχος.These two category values are propagated as filters to the Target table. Με άλλα λόγια, επειδή το μπλε χρώμα χρησιμοποιείται από προϊόντα δύο κατηγοριών, αυτές οι κατηγορίες χρησιμοποιούνται για το φιλτράρισμα των στόχων.In other words, because the color blue is used by products from two categories, those categories are used to filter the targets.

Για να αποφύγετε αυτήν τη συμπεριφορά, όπως περιγράψαμε παραπάνω, συνιστούμε να ελέγχετε τη σύνοψη δεδομένων των στοιχείων σας, χρησιμοποιώντας μετρήσεις.To avoid this behavior, as described earlier, we recommend you control the summarization of your fact data by using measures.

Θεωρήστε τον παρακάτω ορισμό μέτρησης.Consider the following measure definition. Παρατηρήστε ότι όλες οι στήλες του πίνακα Προϊόν που βρίσκονται κάτω από το επίπεδο κατηγορίας ελέγχονται για φίλτρα.Notice that all Product table columns that are beneath the category level are tested for filters.

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

Η ακόλουθη απεικόνιση πίνακα χρησιμοποιεί τώρα την μέτρηση Ποσότητα-στόχος.The following table visual now uses the Target Quantity measure. Δείχνει ότι όλες οι ποσότητες-στόχοι χρώματος είναι ΚΕΝΕΣ.It shows that all color target quantities are BLANK.

Διάγραμμα που εμφανίζει μια απεικόνιση πίνακα με δύο στήλες: Χρώμα και Ποσότητα-στόχος.

Η τελική σχεδίαση μοντέλου μοιάζει με την παρακάτω.The final model design looks like the following.

Διάγραμμα που δείχνει ένα μοντέλο με τους πίνακες "Ημερομηνία" και "Στόχος" να σχετίζονται με μια σχέση "ένα-προς-πολλά".

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

Όταν πρέπει να συσχετίσετε έναν πίνακα διαστάσεων με έναν πίνακα στοιχείων και ο πίνακας στοιχείων αποθηκεύει γραμμές σε υψηλότερο επίπεδο λεπτομέρειας σε σχέση με τον πίνακα διαστάσεων, παρέχουμε τις παρακάτω οδηγίες:When you need to relate a dimension-type table to a fact-type table, and the fact-type table stores rows at a higher grain than the dimension-type table rows, we provide the following guidance:

  • Για ημερομηνίες στοιχείων με μεγαλύτερη λεπτομέρεια:For higher grain fact dates:
    • Στον πίνακα στοιχείων, αποθηκεύστε την πρώτη ημερομηνία της χρονικής περιόδουIn the fact-type table, store the first date of the time period
    • Δημιουργία σχέσης "ένα-προς-πολλά" μεταξύ του πίνακα ημερομηνιών και του πίνακα στοιχείωνCreate a one-to-many relationship between the date table and the fact-type table
  • Για άλλα στοιχεία με μεγαλύτερη λεπτομέρεια:For other higher grain facts:
    • Δημιουργία σχέσης "πολλά-προς-πολλά" μεταξύ του πίνακα διαστάσεων και του πίνακα στοιχείωνCreate a many-to-many relationship between the dimension-type table and the fact-type table
  • Και για τους δύο τύπους:For both types:
    • Έλεγχος σύνοψης με λογική μέτρησης. Επιστρέφει ΚΕΝΌ όταν οι στήλες τύπου κατώτερου επιπέδου χρησιμοποιούνται για φιλτράρισμα ή ομαδοποίησηControl summarization with measure logic—return BLANK when lower-level dimension-type columns are used to filter or group
    • Απόκρυψη στηλών πίνακα στοιχείων με δυνατότητα σύνοψης. Με αυτόν τον τρόπο, μπορούν να χρησιμοποιηθούν μόνο μετρήσεις για τη σύνοψη του πίνακα στοιχείωνHide summarizable fact-type table columns—this way, only measures can be used to summarize the fact-type table

Επόμενα βήματαNext steps

Για περισσότερες πληροφορίες σχετικές με αυτό το άρθρο, ελέγξτε τις παρακάτω προελεύσεις:For more information related to this article, check out the following resources: