Στο παρασκήνιο του τείχους προστασίας προσωπικών δεδομένων

Note

Τα επίπεδα προστασίας προσωπικών δεδομένων δεν είναι προς το παρόν διαθέσιμα στις ροές δεδομένων Power Platform, αλλά η ομάδα προϊόντων εργάζεται για την ενεργοποίηση αυτής της λειτουργικότητας.

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

Formula.Firewall: Query 'Query1' (step 'Source') references other queries or steps, so it may not directly access a data source. Please rebuild this data combination.

Ή ίσως:

Formula.Firewall: Query 'Query1' (step 'Source') is accessing data sources that have privacy levels which cannot be used together. Please rebuild this data combination.

Αυτά Formula.Firewall τα σφάλματα είναι αποτέλεσμα του τείχους προστασίας δεδομένων του Power Query (γνωστό και ως τείχος προστασίας), το οποίο μερικές φορές μπορεί να φαίνεται ότι υπάρχει αποκλειστικά για να απογοητεύει τους αναλυτές δεδομένων σε όλο τον κόσμο. Είτε το πιστεύετε είτε όχι, ωστόσο, το Τείχος προστασίας εξυπηρετεί έναν σημαντικό σκοπό. Σε αυτό το άρθρο, εμβαθύνουμε κάτω από την κουκούλα για να κατανοήσουμε καλύτερα πώς λειτουργεί. Οπλισμένοι με μεγαλύτερη κατανόηση, ελπίζουμε ότι θα είστε σε θέση να διαγνώσετε και να διορθώσετε καλύτερα τα σφάλματα του τείχους προστασίας στο μέλλον.

Τι είναι?

Ο σκοπός του τείχους προστασίας προσωπικών δεδομένων είναι απλός: υπάρχει για να αποτρέψει την ακούσια διαρροή δεδομένων μεταξύ προελεύσεων από το Power Query.

Γιατί χρειάζεται αυτό; Θέλω να πω, θα μπορούσατε σίγουρα να συντάξετε κάποιο M που θα περνούσε μια τιμή SQL σε μια ροή OData. Αλλά αυτό θα ήταν σκόπιμη διαρροή δεδομένων. Ο συγγραφέας του mashup θα ήξερε (ή τουλάχιστον θα έπρεπε) ότι το έκανε αυτό. Γιατί τότε η ανάγκη προστασίας από ακούσια διαρροή δεδομένων;

Η απάντηση? Πτυσσόμενα.

Πτυσσόμενα?

Η αναδίπλωση είναι ένας όρος που αναφέρεται στη μετατροπή παραστάσεων στο M (όπως φίλτρα, μετονομασίες, σύνδεσμοι κ.λπ.) σε λειτουργίες σε μια μη επεξεργασμένη προέλευση δεδομένων (όπως SQL, OData κ.λπ.). Ένα τεράστιο μέρος της ισχύος του Power Query προέρχεται από το γεγονός ότι το Power Query μπορεί να μετατρέψει τις λειτουργίες που εκτελεί ένας χρήστης μέσω της διεπαφής χρήστη του σε σύνθετες γλώσσες προέλευσης δεδομένων SQL ή άλλες γλώσσες προέλευσης δεδομένων υποστήριξης, χωρίς ο χρήστης να χρειάζεται να γνωρίζει τις εν λόγω γλώσσες. Οι χρήστες απολαμβάνουν το πλεονέκτημα απόδοσης των εγγενών λειτουργιών πηγής δεδομένων, με την ευκολία χρήσης ενός περιβάλλοντος εργασίας χρήστη όπου όλες οι πηγές δεδομένων μπορούν να μετασχηματιστούν χρησιμοποιώντας ένα κοινό σύνολο εντολών.

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

Έτσι μπορεί να συμβεί ακούσια διαρροή δεδομένων.

Φανταστείτε αν συνδέατε δεδομένα SQL που περιελάμβαναν Αριθμούς Κοινωνικής Ασφάλισης υπαλλήλων με τα αποτελέσματα μιας εξωτερικής τροφοδοσίας OData και ξαφνικά ανακαλύπτατε ότι οι Αριθμοί Κοινωνικής Ασφάλισης από την SQL αποστέλλονταν στην υπηρεσία OData. Άσχημα νέα, σωστά;

Αυτό είναι το είδος του σεναρίου που προορίζεται να αποτρέψει το Τείχος προστασίας.

Πώς λειτουργεί;

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

Πώς λοιπόν εκπληρώνει αυτή την αποστολή;

Αυτό το επιτυγχάνει διαιρώντας τα M ερωτήματά σας σε κάτι που ονομάζεται διαμερίσματα και, στη συνέχεια, επιβάλλοντας τον ακόλουθο κανόνα:

Ένα διαμέρισμα μπορεί είτε να έχει πρόσβαση σε συμβατές πηγές δεδομένων είτε να αναφέρεται σε άλλα διαμερίσματα, αλλά όχι και στα δύο.

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

Ας το αναλύσουμε αυτό και ας δούμε τον προηγούμενο κανόνα ένα κομμάτι τη φορά.

Τι είναι η κατάτμηση;

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

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

Διαμερίσματα που αναφέρονται σε άλλα διαμερίσματα

Όταν ένα ερώτημα αξιολογείται με ενεργοποιημένο το τείχος προστασίας, το τείχος προστασίας διαιρεί το ερώτημα και όλες τις εξαρτήσεις του σε διαμερίσματα (δηλαδή, ομάδες βημάτων). Κάθε φορά που ένα διαμέρισμα αναφέρεται σε κάτι σε ένα άλλο διαμέρισμα, το Τείχος προστασίας αντικαθιστά την αναφορά με μια κλήση σε μια ειδική συνάρτηση που ονομάζεται Value.Firewall. Με άλλα λόγια, το τείχος προστασίας δεν επιτρέπει στα διαμερίσματα να έχουν άμεση πρόσβαση μεταξύ τους. Όλες οι αναφορές τροποποιούνται για να περάσουν από το τείχος προστασίας. Σκεφτείτε το τείχος προστασίας ως φύλακα. Ένα διαμέρισμα που αναφέρεται σε ένα άλλο διαμέρισμα πρέπει να λάβει την άδεια του τείχους προστασίας για να το κάνει και το τείχος προστασίας ελέγχει εάν τα αναφερόμενα δεδομένα επιτρέπονται ή όχι στο διαμέρισμα.

Όλα αυτά μπορεί να φαίνονται αρκετά αφηρημένα, οπότε ας δούμε ένα παράδειγμα.

Ας υποθέσουμε ότι έχετε ένα ερώτημα που ονομάζεται Υπάλληλοι, το οποίο αντλεί ορισμένα δεδομένα από μια βάση δεδομένων SQL. Ας υποθέσουμε ότι έχετε επίσης ένα άλλο ερώτημα (EmployeesReference), το οποίο απλώς αναφέρεται στο Employees.

shared Employees = let
    Source = Sql.Database(…),
    EmployeesTable = …
in
    EmployeesTable;

shared EmployeesReference = let
    Source = Employees
in
    Source;

Αυτά τα ερωτήματα καταλήγουν να χωρίζονται σε δύο διαμερίσματα: ένα για το ερώτημα Employees και ένα για το ερώτημα EmployeesReference (το οποίο αναφέρεται στο διαμέρισμα Employees). Όταν αξιολογούνται με ενεργοποιημένο το τείχος προστασίας, αυτά τα ερωτήματα ξαναγράφονται ως εξής:

shared Employees = let
    Source = Sql.Database(…),
    EmployeesTable = …
in
    EmployeesTable;

shared EmployeesReference = let
    Source = Value.Firewall("Section1/Employees")
in
    Source;

Σημειώστε ότι η απλή αναφορά στο ερώτημα Υπάλληλοι αντικαθίσταται από μια κλήση στο Value.Firewall, στην οποία παρέχεται το πλήρες όνομα του ερωτήματος Υπάλληλοι.

Όταν αξιολογείται το EmployeesReference, το τείχος προστασίας παρεμποδίζει την κλήση στο , το οποίο έχει πλέον την ευκαιρία να Value.Firewall("Section1/Employees")ελέγξει εάν (και πώς) τα ζητούμενα δεδομένα ρέουν στο διαμέρισμα EmployeesReference. Μπορεί να κάνει πολλά πράγματα: να απορρίψει το αίτημα, να αποθηκεύσει προσωρινά τα ζητούμενα δεδομένα (κάτι που αποτρέπει οποιαδήποτε περαιτέρω αναδίπλωση στην αρχική πηγή δεδομένων τους) και ούτω καθεξής.

Αυτός είναι ο τρόπος με τον οποίο το Τείχος προστασίας διατηρεί τον έλεγχο των δεδομένων που ρέουν μεταξύ των κατατμήσεων.

Διαμερίσματα που έχουν άμεση πρόσβαση σε πηγές δεδομένων

Ας υποθέσουμε ότι ορίζετε ένα ερώτημα Query1 με ένα βήμα (σημειώστε ότι αυτό το ερώτημα ενός βήματος αντιστοιχεί σε ένα διαμέρισμα τείχους προστασίας) και ότι αυτό το μεμονωμένο βήμα έχει πρόσβαση σε δύο προελεύσεις δεδομένων: έναν πίνακα βάσης δεδομένων SQL και ένα αρχείο CSV. Πώς το αντιμετωπίζει αυτό το Firewall, αφού δεν υπάρχει αναφορά κατάτμησης, και επομένως δεν υπάρχει κλήση για Value.Firewall υποκλοπή; Ας αναθεωρήσουμε τον κανόνα που αναφέρθηκε προηγουμένως:

Ένα διαμέρισμα μπορεί είτε να έχει πρόσβαση σε συμβατές πηγές δεδομένων είτε να αναφέρεται σε άλλα διαμερίσματα, αλλά όχι και στα δύο.

Για να επιτραπεί η εκτέλεση του ερωτήματός σας με ένα διαμέρισμα αλλά δύο προελεύσεις δεδομένων, οι δύο προελεύσεις δεδομένων του πρέπει να είναι "συμβατές". Με άλλα λόγια, πρέπει να είναι εντάξει τα δεδομένα να μοιράζονται αμφίδρομα μεταξύ τους. Αυτό σημαίνει ότι τα επίπεδα απορρήτου και των δύο πηγών πρέπει να είναι Δημόσια ή και τα δύο να είναι Οργανωτικά, καθώς αυτοί είναι οι μόνοι δύο συνδυασμοί που επιτρέπουν την κοινή χρήση και προς τις δύο κατευθύνσεις. Εάν και οι δύο προελεύσεις έχουν επισημανθεί ως ιδιωτικές ή μία έχει επισημανθεί ως Δημόσια και μία έχει επισημανθεί ως Εταιρική ή έχουν επισημανθεί χρησιμοποιώντας κάποιον άλλο συνδυασμό επιπέδων προστασίας προσωπικών δεδομένων, τότε η αμφίδρομη κοινή χρήση δεν επιτρέπεται. Δεν είναι ασφαλές να αξιολογηθούν και οι δύο στο ίδιο διαμέρισμα. Κάτι τέτοιο θα σήμαινε ότι θα μπορούσε να προκύψει μη ασφαλής διαρροή δεδομένων (λόγω αναδίπλωσης) και το Τείχος προστασίας δεν θα είχε τρόπο να την αποτρέψει.

Τι συμβαίνει εάν προσπαθήσετε να αποκτήσετε πρόσβαση σε μη συμβατές πηγές δεδομένων στο ίδιο διαμέρισμα;

Formula.Firewall: Query 'Query1' (step 'Source') is accessing data sources that have privacy levels which cannot be used together. Please rebuild this data combination.

Ας ελπίσουμε ότι τώρα καταλαβαίνετε καλύτερα ένα από τα μηνύματα σφάλματος που αναφέρονται στην αρχή αυτού του άρθρου.

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

Γιατί να μην κάνετε και τα δύο;

Ας υποθέσουμε ότι ορίζετε ένα ερώτημα με ένα βήμα (το οποίο αντιστοιχεί και πάλι σε ένα διαμέρισμα) που έχει πρόσβαση σε δύο άλλα ερωτήματα (δηλαδή, δύο άλλα διαμερίσματα). Τι θα γινόταν αν θέλατε, στο ίδιο βήμα, να αποκτήσετε επίσης απευθείας πρόσβαση σε μια βάση δεδομένων SQL; Γιατί ένα διαμέρισμα δεν μπορεί να αναφέρεται σε άλλα διαμερίσματα και να έχει άμεση πρόσβαση σε συμβατές πηγές δεδομένων;

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

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

Formula.Firewall: Query 'Query1' (step 'Source') references other queries or steps, so it may not directly access a data source. Please rebuild this data combination.

Τώρα ελπίζουμε να κατανοήσετε καλύτερα το άλλο μήνυμα σφάλματος που αναφέρεται στην αρχή αυτού του άρθρου.

Χωρίσματα σε βάθος

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

Πώς ακριβώς λοιπόν διαμερίζονται τα ερωτήματα;

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

Ακολουθεί μια περίληψη υψηλού επιπέδου της λογικής κατάτμησης.

Αρχική κατάτμηση
- Δημιουργεί ένα διαμέρισμα για κάθε βήμα σε κάθε ερώτημα
Στατική φάση
- Αυτή η φάση δεν εξαρτάται από τα αποτελέσματα της αξιολόγησης. Αντίθετα, βασίζεται στον τρόπο δομής των ερωτημάτων.
  - Περικοπή παραμέτρων
    - Περικόπτει διαμερίσματα τύπου παραμέτρου, δηλαδή οποιοδήποτε που:
      - Δεν αναφέρεται σε άλλες κατατμήσεις
      - Δεν περιέχει κλήσεις συναρτήσεων
      - Δεν είναι κυκλικό (δηλαδή δεν αναφέρεται στον εαυτό του)
    - Σημειώστε ότι η "αφαίρεση" μιας κατάτμησης την περιλαμβάνει αποτελεσματικά σε οποιαδήποτε άλλη κατάτμηση την αναφέρουν.
    - Η περικοπή κατατμήσεων παραμέτρων επιτρέπει τη λειτουργία αναφορών παραμέτρων που χρησιμοποιούνται σε κλήσεις συναρτήσεων προέλευσης δεδομένων (για παράδειγμα, Web.Contents(myUrl)), αντί να εμφανίζονται σφάλματα "το διαμέρισμα δεν μπορεί να αναφέρει πηγές δεδομένων και άλλα βήματα".
  - Ομαδοποίηση (στατική)
    - Οι κατατμήσεις συγχωνεύονται με σειρά εξάρτησης από κάτω προς τα πάνω. Στα συγχωνευμένα διαμερίσματα που προκύπτουν, τα ακόλουθα είναι ξεχωριστά:
      - Κατατμήσεις σε διαφορετικά ερωτήματα
      - Διαμερίσματα που δεν αναφέρονται σε άλλα διαμερίσματα (και επομένως επιτρέπεται η πρόσβαση σε μια προέλευση δεδομένων)
      - Διαμερίσματα που αναφέρονται σε άλλα διαμερίσματα (και επομένως απαγορεύεται η πρόσβαση σε μια πηγή δεδομένων)
Δυναμική φάση
- Αυτή η φάση εξαρτάται από τα αποτελέσματα της αξιολόγησης, συμπεριλαμβανομένων πληροφοριών σχετικά με πηγές δεδομένων στις οποίες έχουν πρόσβαση διάφορα διαμερίσματα.
- Τακτοποίηση
  - Κόβει χωρίσματα που πληρούν όλες τις ακόλουθες απαιτήσεις:
    - Δεν έχει πρόσβαση σε καμία προέλευση δεδομένων
    - Δεν αναφέρεται σε διαμερίσματα που έχουν πρόσβαση σε προελεύσεις δεδομένων
    - Δεν είναι κυκλικό
- Ομαδοποίηση (δυναμική)
  - Τώρα που τα περιττά διαμερίσματα έχουν περικοπεί, προσπαθήστε να δημιουργήσετε διαμερίσματα Source που είναι όσο το δυνατόν μεγαλύτερα. Αυτή η δημιουργία γίνεται με τη συγχώνευση των κατατμήσεων χρησιμοποιώντας τους ίδιους κανόνες που περιγράφηκαν στην προηγούμενη φάση στατικής ομαδοποίησης.

Τι σημαίνουν όλα αυτά;

Ας δούμε ένα παράδειγμα για να δείξουμε πώς λειτουργεί η πολύπλοκη λογική που παρουσιάστηκε προηγουμένως.

Ακολουθεί ένα δείγμα σεναρίου. Είναι μια αρκετά απλή συγχώνευση ενός αρχείου κειμένου (Επαφές) με μια βάση δεδομένων SQL (Υπάλληλοι), όπου ο διακομιστής SQL είναι μια παράμετρος (DbServer).

Τα τρία ερωτήματα

Ακολουθεί ο κωδικός M για τα τρία ερωτήματα που χρησιμοποιούνται σε αυτό το παράδειγμα.

shared DbServer = "MySqlServer" meta [IsParameterQuery=true, Type="Text", IsParameterQueryRequired=true];

shared Contacts = let

    Source = Csv.Document(File.Contents(
        "C:\contacts.txt"),[Delimiter="   ", Columns=15, Encoding=1252, QuoteStyle=QuoteStyle.None]
    ),

    #"Promoted Headers" = Table.PromoteHeaders(Source, [PromoteAllScalars=true]),

    #"Changed Type" = Table.TransformColumnTypes(
        #"Promoted Headers",
        {
            {"ContactID", Int64.Type}, 
            {"NameStyle", type logical}, 
            {"Title", type text}, 
            {"FirstName", type text}, 
            {"MiddleName", type text}, 
            {"LastName", type text}, 
            {"Suffix", type text}, 
            {"EmailAddress", type text}, 
            {"EmailPromotion", Int64.Type}, 
            {"Phone", type text}, 
            {"PasswordHash", type text}, 
            {"PasswordSalt", type text}, 
            {"AdditionalContactInfo", type text}, 
            {"rowguid", type text}, 
            {"ModifiedDate", type datetime}
        }
    )

in

    #"Changed Type";

shared Employees = let

    Source = Sql.Databases(DbServer),

    AdventureWorks = Source{[Name="AdventureWorks"]}[Data],

    HumanResources_Employee = AdventureWorks{[Schema="HumanResources",Item="Employee"]}[Data],

    #"Removed Columns" = Table.RemoveColumns(
        HumanResources_Employee,
        {
            "HumanResources.Employee(EmployeeID)", 
            "HumanResources.Employee(ManagerID)", 
            "HumanResources.EmployeeAddress", 
            "HumanResources.EmployeeDepartmentHistory", 
            "HumanResources.EmployeePayHistory", 
            "HumanResources.JobCandidate", 
            "Person.Contact", 
            "Purchasing.PurchaseOrderHeader", 
            "Sales.SalesPerson"
        }
    ),

    #"Merged Queries" = Table.NestedJoin(
        #"Removed Columns",
        {"ContactID"},
        Contacts,
        {"ContactID"},
        "Contacts",
        JoinKind.LeftOuter
    ),

    #"Expanded Contacts" = Table.ExpandTableColumn(
        #"Merged Queries", 
        "Contacts", 
        {"EmailAddress"}, 
        {"EmailAddress"}
    )

in

    #"Expanded Contacts";

Ακολουθεί μια προβολή υψηλότερου επιπέδου, που δείχνει τις εξαρτήσεις.

Παράθυρο διαλόγου εξαρτήσεων ερωτήματος.

Ας χωρίσουμε

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

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

Στη συνέχεια, περικόπτουμε τα διαμερίσματα παραμέτρων. Έτσι, ο DbServer περιλαμβάνεται σιωπηρά στο διαμέρισμα Source.

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

Τώρα εκτελούμε τη στατική ομαδοποίηση. Αυτή η ομαδοποίηση διατηρεί το διαχωρισμό μεταξύ των διαμερισμάτων σε ξεχωριστά ερωτήματα (σημειώστε, για παράδειγμα, ότι τα δύο τελευταία βήματα των Υπαλλήλων δεν ομαδοποιούνται με τα βήματα των Επαφών) και μεταξύ των διαμερισμάτων που αναφέρονται σε άλλα διαμερίσματα (όπως τα δύο τελευταία βήματα των Υπαλλήλων) και εκείνων που δεν αναφέρονται (όπως τα τρία πρώτα βήματα των Υπαλλήλων).

Διάγραμμα που δείχνει τα διαμερίσματα τείχους προστασίας μετά τη στατική ομαδοποίηση.

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

Ας προσποιηθούμε

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

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

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

Με την κατάργηση του διαμερίσματος Επαφές, τα δύο τελευταία βήματα του Employees δεν θα αναφέρονται πλέον σε κανένα διαμέρισμα εκτός από αυτό που περιέχει τα τρία πρώτα βήματα του Employees. Έτσι, τα δύο διαμερίσματα θα ομαδοποιηθούν.

Το διαμέρισμα που προκύπτει θα μοιάζει με αυτό.

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

Παράδειγμα: Διαβίβαση δεδομένων από μια προέλευση δεδομένων σε μια άλλη

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

Φανταστείτε ότι θέλετε να αναζητήσετε ένα όνομα εταιρείας από την υπηρεσία OData Northwind και, στη συνέχεια, να χρησιμοποιήσετε το όνομα της εταιρείας για να πραγματοποιήσετε μια αναζήτηση Bing.

Αρχικά, δημιουργείτε ένα ερώτημα εταιρείας για να ανακτήσετε το όνομα της εταιρείας.

let
    Source = OData.Feed(
        "https://services.odata.org/V4/Northwind/Northwind.svc/", 
        null, 
        [Implementation="2.0"]
    ),
    Customers_table = Source{[Name="Customers",Signature="table"]}[Data],
    CHOPS = Customers_table{[CustomerID="CHOPS"]}[CompanyName]
in
    CHOPS

Στη συνέχεια, δημιουργείτε ένα ερώτημα αναζήτησης που αναφέρεται στην Εταιρεία και το μεταβιβάζει στο Bing.

let
    Source = Text.FromBinary(Web.Contents("https://www.bing.com/search?q=" & Company))
in
    Source

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

Formula.Firewall: Query 'Search' (step 'Source') references other queries or steps, so it may not directly access a data source. Please rebuild this data combination.

Αυτό το σφάλμα παρουσιάζεται επειδή το βήμα Προέλευση της Αναζήτησης αναφέρεται σε μια προέλευση δεδομένων (bing.com) και επίσης αναφέρεται σε ένα άλλο ερώτημα/διαμέρισμα (Εταιρεία). Παραβιάζει τον προαναφερθέντα κανόνα ("ένα διαμέρισμα μπορεί είτε να έχει πρόσβαση σε συμβατές πηγές δεδομένων είτε να αναφέρεται σε άλλα διαμερίσματα, αλλά όχι και στα δύο").

Τι να κάνω? Μια επιλογή είναι να απενεργοποιήσετε εντελώς το τείχος προστασίας (μέσω της επιλογής απορρήτου με την ένδειξη Παράβλεψη των επιπέδων απορρήτου και πιθανή βελτίωση της απόδοσης). Τι γίνεται όμως αν θέλετε να αφήσετε ενεργοποιημένο το Τείχος προστασίας;

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

let
    Source = OData.Feed(
        "https://services.odata.org/V4/Northwind/Northwind.svc/", 
        null, 
        [Implementation="2.0"]
    ),
    Customers_table = Source{[Name="Customers",Signature="table"]}[Data],
    CHOPS = Customers_table{[CustomerID="CHOPS"]}[CompanyName],
    Search = Text.FromBinary(Web.Contents("https://www.bing.com/search?q=" & CHOPS))
in
    Search

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

Αυτό είναι ένα περιτύλιγμα

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

Ανάδραση

Ήταν χρήσιμη αυτή η σελίδα;

Last updated on 2025-11-08