คําแนะนําการสร้างแบบจําลอง Power BI สําหรับ Power Platform
Microsoft Dataverse เป็นแพลตฟอร์มข้อมูลมาตรฐานสําหรับผลิตภัณฑ์แอปพลิเคชันทางธุรกิจของ Microsoft จํานวนมาก รวมถึงแอปพื้นที่ทํางาน Dynamics 365 Customer Engagement และ Power Apps และยัง Dynamics 365 Customer Voice (เดิมชื่อ Microsoft Forms Pro), การอนุมัติ Power Automate, พอร์ทัล Power Apps และอื่นๆ
บทความนี้ให้คําแนะนําเกี่ยวกับวิธีการสร้างแบบจําลองข้อมูล Power BI ที่เชื่อมต่อกับ Dataverse ซึ่งจะอธิบายความแตกต่างระหว่าง Schema ของ Dataverse และ Schema ของ Power BI ที่ปรับให้เหมาะสม และให้คําแนะนําสําหรับการขยายการมองเห็นของข้อมูลแอปพลิเคชันทางธุรกิจของคุณใน Power BI
เนื่องจากง่ายต่อการตั้งค่า การปรับใช้อย่างรวดเร็ว และการปรับใช้ที่แพร่หลาย ที่เก็บข้อมูลโดย Dataverse และจัดการปริมาณข้อมูลที่เพิ่มขึ้นในสภาพแวดล้อมทั่วทั้งองค์กร ซึ่งหมายความว่ามีความต้องการและโอกาสที่ยิ่งใหญ่กว่าเพื่อรวมการวิเคราะห์กับกระบวนการเหล่านั้น โอกาสทางการขายรวมถึง:
- รายงานเกี่ยวกับข้อมูลทั้งหมดที่มีการย้ายเกินข้อจํากัดของแผนภูมิที่มีอยู่ภายใน
- ให้การเข้าถึงรายงานที่กรองตามบริบทที่เกี่ยวข้องได้อย่างง่ายดายภายในระเบียนที่ระบุ
- ปรับปรุงค่าของข้อมูล verse โดยการรวมกับข้อมูลภายนอก
- ใช้ประโยชน์จากปัญญาประดิษฐ์ (AI) ที่มีอยู่แล้วภายในของ Power BI โดยไม่จําเป็นต้องเขียนโค้ดที่ซับซ้อน
- เพิ่มการนําโซลูชัน Power Platform มาใช้โดยเพิ่มประโยชน์และคุณค่า
- ส่งมอบคุณค่าของข้อมูลในแอปของคุณให้กับผู้มีอํานาจตัดสินใจทางธุรกิจ
เชื่อมต่อ Power BI กับ Dataverse
การเชื่อมต่อ Power BI กับ Dataverse เกี่ยวข้องกับการสร้างแบบจําลองข้อมูล Power BI คุณสามารถเลือกจากสามวิธีในการสร้างแบบจําลอง Power BI
- นําเข้าข้อมูล Dataverse โดยใช้ตัวเชื่อมต่อ Dataverse: เมธอดนี้แคช (จัดเก็บ) ข้อมูล Dataverse ในแบบจําลอง Power BI ซึ่งมีประสิทธิภาพการทํางานที่รวดเร็วด้วยการคิวรีในหน่วยความจํา นอกจากนี้ยังให้ความยืดหยุ่นในการออกแบบสําหรับผู้สร้างแบบจําลอง เพื่อให้สามารถรวมข้อมูลจากแหล่งข้อมูลอื่น ๆ ได้ เนื่องจากจุดแข็งเหล่านี้ การนําเข้าข้อมูลเป็นโหมดเริ่มต้นเมื่อสร้างแบบจําลองใน Power BI Desktop
- นําเข้าข้อมูล verse โดยใช้ Azure Synapse Link: วิธีนี้เป็นการเปลี่ยนแปลงในวิธีการนําเข้า เนื่องจากยังแคชข้อมูลในแบบจําลอง Power BI แต่สามารถทําได้โดยการเชื่อมต่อกับ Azure Synapse Analytics ด้วยการใช้ Azure Synapse Link สําหรับ Dataverse ตาราง Dataverse จะถูกทําซ้ําอย่างต่อเนื่องไปยัง Azure Synapse หรือ Azure Data Lake Storage (ADLS) Gen2 วิธีนี้ใช้เพื่อรายงานเกี่ยวกับระเบียนหลายร้อยพันหรือหลายล้านระเบียนในสภาพแวดล้อม Dataverse
- สร้างการเชื่อมต่อ DirectQuery โดยใช้ตัวเชื่อมต่อ Dataverse: วิธีนี้เป็นทางเลือกในการนําเข้าข้อมูล แบบจําลอง DirectQuery ประกอบด้วยเมตาดาต้าที่กําหนดโครงสร้างแบบจําลองเท่านั้น เมื่อผู้ใช้เปิดรายงาน Power BI ส่งคิวรีในระบบไปยัง Dataverse เพื่อดึงข้อมูล พิจารณาการสร้างแบบจําลอง DirectQuery เมื่อรายงานต้องแสดงข้อมูลที่ใกล้เคียงกับข้อมูลแบบเรียลไทม์ หรือเมื่อ Dataverse ต้องบังคับใช้ความปลอดภัยตามบทบาทเพื่อให้ผู้ใช้สามารถดูข้อมูลที่พวกเขามีสิทธิ์เข้าถึงเท่านั้น
สำคัญ
ในขณะที่แบบจําลอง DirectQuery เป็นทางเลือกที่ดีเมื่อคุณต้องการรายงานแบบใกล้เคียงกับการบังคับใช้การรักษาความปลอดภัย Dataverse ในรายงาน ซึ่งอาจส่งผลให้ประสิทธิภาพการทํางานช้าสําหรับรายงานนั้น
คุณสามารถเรียนรู้เกี่ยวกับ ข้อควรพิจารณาสําหรับ DirectQuery ได้ในภายหลังในบทความนี้
หากต้องการกําหนดวิธีการที่เหมาะสมสําหรับแบบจําลอง Power BI ของคุณ คุณควรพิจารณา:
- ประสิทธิภาพคิวรี
- ปริมาณข้อมูล
- เวลาแฝงของข้อมูล
- ความปลอดภัยตามบทบาท
- ตั้งค่าความซับซ้อน
เคล็ดลับ
สําหรับการอภิปรายโดยละเอียดเกี่ยวกับเฟรมเวิร์กแบบจําลอง (นําเข้า DirectQuery หรือแบบรวม) ประโยชน์และข้อจํากัดและคุณลักษณะของเฟรมเวิร์กเหล่านี้เพื่อช่วยปรับแบบจําลองข้อมูล Power BI ให้เหมาะสม โปรดดู เลือกเฟรมเวิร์กแบบจําลอง Power BI
ประสิทธิภาพคิวรี
คิวรีที่ส่งไปยังแบบจําลองนําเข้าเร็วกว่าคิวรีดั้งเดิมที่ส่งไปยังแหล่งข้อมูล DirectQuery เนื่องจากมีการแคชข้อมูลที่นําเข้าในหน่วยความจําและถูกปรับให้เหมาะสมสําหรับ คิวรี การวิเคราะห์ (ตัวกรอง กลุ่ม และการดําเนินการสรุป)
ในทางกลับกัน แบบจําลอง DirectQuery จะดึงข้อมูลจากแหล่งที่มาหลังจากที่ผู้ใช้เปิดรายงานเท่านั้น ซึ่งส่งผลให้เวลาหน่วงเวลาเป็นวินาทีเมื่อรายงานแสดง นอกจากนี้ การโต้ตอบของผู้ใช้ในรายงานต้องใช้ Power BI เพื่อร้องขอแหล่งข้อมูลอีกครั้ง และลดการตอบสนองได้มากขึ้น
ปริมาณข้อมูล
เมื่อพัฒนาแบบจําลองการนําเข้า คุณควรพยายามลดข้อมูลที่โหลดลงในแบบจําลองให้เหลือน้อยที่สุด ซึ่งเป็นความจริงโดยเฉพาะอย่างยิ่งสําหรับแบบจําลองขนาดใหญ่ หรือแบบจําลองที่คุณคาดว่าจะเติบโตจนมีขนาดใหญ่ขึ้นเมื่อเวลาผ่านไป สําหรับข้อมูลเพิ่มเติม โปรดดู เทคนิคการลดข้อมูลสําหรับการสร้างแบบจําลองการนําเข้า
การเชื่อมต่อ DirectQuery ไปยัง Dataverse เป็นตัวเลือกที่ดีเมื่อผลลัพธ์คิวรีของรายงานไม่ใหญ่ ผลลัพธ์ของคิวรีขนาดใหญ่มีมากกว่า 20,000 แถวในตารางแหล่งข้อมูลของรายงาน หรือผลลัพธ์ที่ส่งกลับไปยังรายงานหลังจากที่มีการใช้ตัวกรองมากกว่า 20,000 แถว ในกรณีนี้ คุณสามารถสร้าง รายงาน Power BI โดยใช้ตัวเชื่อมต่อ Dataverse
หมายเหตุ
ขนาดแถว 20,000 ไม่ใช่ขีดจํากัดที่ยาก อย่างไรก็ตาม คิวรีแหล่งข้อมูลแต่ละคิวรีต้องส่งกลับผลลัพธ์ภายใน 10 นาที ภายหลังในบทความนี้ คุณจะได้เรียนรู้วิธีการทํางานภายในข้อจํากัดเหล่านั้นและเกี่ยวกับข้อควรพิจารณาในการออกแบบ Dataverse DirectQuery อื่น ๆ
คุณสามารถปรับปรุงประสิทธิภาพของแบบจําลองความหมายที่มีขนาดใหญ่ขึ้นได้โดยใช้ตัว เชื่อมต่อ Dataverse เพื่อนําเข้าข้อมูลลงในแบบจําลองข้อมูล
แม้แต่แบบจําลองความหมายที่มีขนาดใหญ่ขึ้น — ด้วยแถวหลายร้อยพันหรือหลายล้านแถว — อาจได้รับประโยชน์จากการใช้ Azure Synapse Link สําหรับ Dataverse วิธีนี้ตั้งค่าไปป์ไลน์ที่มีการจัดการอย่างต่อเนื่องที่คัดลอกข้อมูล verse ลงใน ADLS Gen2 เป็นไฟล์ CSV หรือ Parquet Power BI สามารถคิวรีกลุ่ม SQL แบบไร้เซิร์ฟเวอร์ของ Azure Synapse เพื่อโหลดแบบจําลองการนําเข้า
เวลาแฝงของข้อมูล
เมื่อข้อมูล Dataverse เปลี่ยนแปลงอย่างรวดเร็วและผู้ใช้รายงานจําเป็นต้องดูข้อมูลล่าสุด แบบจําลอง DirectQuery สามารถให้ผลลัพธ์คิวรีใกล้เคียงกับเวลาจริงได้
เคล็ดลับ
คุณสามารถสร้างรายงาน Power BI ที่ใช้ การรีเฟรช หน้าอัตโนมัติเพื่อแสดงการอัปเดตแบบเรียลไทม์ แต่เฉพาะเมื่อรายงานเชื่อมต่อกับแบบจําลอง DirectQuery เท่านั้น
แบบจําลองข้อมูลการนําเข้าต้องเสร็จสิ้นการรีเฟรชข้อมูลเพื่ออนุญาตให้มีการรายงานการเปลี่ยนแปลงข้อมูลล่าสุด โปรดทราบว่ามีข้อจํากัดเกี่ยวกับจํานวนการดําเนินการรีเฟรชข้อมูลตามกําหนดเวลารายวัน คุณสามารถกําหนดตารางเวลาการรีเฟรชได้สูงสุดแปดรายการต่อวันบนความจุที่ใช้ร่วมกัน ในความจุพรีเมียมหรือความจุ Microsoft Fabric คุณสามารถกําหนดตารางเวลาการรีเฟรชได้สูงสุด 48 รายการต่อวัน ซึ่งสามารถทําให้ความถี่ในการรีเฟรชนาน 15 นาทีได้
สำคัญ
ในบางครั้งที่บทความนี้อ้างอิงถึง Power BI Premium หรือการสมัครใช้งานความจุ (P SKU) โปรดทราบว่าในขณะนี้ Microsoft กําลังรวมตัวเลือกการซื้อและหยุดใช้งาน Power BI Premium ต่อความจุ SKU ลูกค้าใหม่และลูกค้าที่มีอยู่ควรพิจารณาซื้อการสมัครใช้งานความจุ Fabric (F SKU) แทน
สําหรับข้อมูลเพิ่มเติม โปรดดู ที่ การอัปเดตที่สําคัญเกี่ยวกับการให้สิทธิ์การใช้งาน Power BI Premium และ คําถามที่ถามบ่อยของ Power BI Premium
นอกจากนี้ คุณยังสามารถพิจารณาใช้ การรีเฟรช แบบเพิ่มหน่วยเพื่อรีเฟรชได้เร็วขึ้นและ ประสิทธิภาพที่ใกล้เคียงกับเวลา จริง (ใช้ได้กับ Premium หรือ Fabric เท่านั้น)
ความปลอดภัยตามบทบาท
เมื่อมีความจําเป็นต้องบังคับใช้การรักษาความปลอดภัยตามบทบาท จะสามารถส่งผลโดยตรงต่อการเลือกเฟรมเวิร์กแบบจําลอง Power BI
Dataverse สามารถบังคับใช้ความปลอดภัยตามบทบาทที่ซับซ้อนเพื่อควบคุมการเข้าถึงระเบียนเฉพาะกับผู้ใช้ที่ระบุ ตัวอย่างเช่น พนักงานขายอาจได้รับอนุญาตให้ดูเฉพาะโอกาสการขายของตน ในขณะที่ผู้จัดการฝ่ายขายสามารถดูโอกาสการขายทั้งหมดสําหรับพนักงานขายทั้งหมด คุณสามารถปรับแต่งระดับความซับซ้อนตามความต้องการขององค์กรของคุณ
แบบจําลอง DirectQuery ที่ยึดตาม Dataverse สามารถเชื่อมต่อโดยใช้บริบทความปลอดภัยของผู้ใช้รายงาน ด้วยวิธีนี้ ผู้ใช้รายงานจะเห็นเฉพาะข้อมูลที่ได้รับอนุญาตให้เข้าถึง วิธีการนี้สามารถลดความซับซ้อนของการออกแบบรายงาน ซึ่งประสิทธิภาพการทํางานจึงเป็นที่ยอมรับได้
สําหรับประสิทธิภาพที่ดีขึ้น คุณสามารถสร้างแบบจําลองการนําเข้าที่เชื่อมต่อกับ Dataverse แทน ในกรณีนี้ คุณสามารถเพิ่ม การรักษาความปลอดภัยระดับแถว (RLS) ไปยังแบบจําลองหากจําเป็น
หมายเหตุ
ซึ่งอาจเป็นเรื่องท้าทายในการทําซ้ําบางการรักษาความปลอดภัยตามบทบาท Dataverse เป็น Power BI RLS โดยเฉพาะอย่างยิ่งเมื่อ Dataverse บังคับใช้สิทธิ์ที่ซับซ้อน นอกจากนี้ อาจจําเป็นต้องมีการจัดการอย่างต่อเนื่องเพื่อให้สิทธิ์ Power BI สามารถซิงค์กับสิทธิ์ Dataverse ได้
สําหรับข้อมูลเพิ่มเติมเกี่ยวกับ Power BI RLS โปรดดูคําแนะนําการรักษาความปลอดภัยระดับแถว (RLS) ใน Power BI Desktop
ตั้งค่าความซับซ้อน
การใช้ตัวเชื่อมต่อ Dataverse ใน Power BI —ไม่ว่าสําหรับแบบจําลองนําเข้าหรือ DirectQuery จะตรงไปตรงมาและไม่จําเป็นต้องมีซอฟต์แวร์พิเศษหรือสิทธิ์ Dataverse แบบยกระดับใดๆ นั่นคือข้อดีสําหรับองค์กรหรือแผนกต่างๆ ที่กําลังเริ่มต้นใช้งาน
ตัวเลือก Azure Synapse Link จําเป็นต้องให้ผู้ดูแลระบบเข้าถึง Dataverse และสิทธิ์บางอย่างของ Azure คุณจําเป็นต้องมีสิทธิ์ Azure เหล่านี้ในการตั้งค่าบัญชีที่เก็บข้อมูลและพื้นที่ทํางาน Synapse
แนวทางปฏิบัติที่แนะนา
ในส่วนนี้จะอธิบายรูปแบบการออกแบบ (และรูปแบบการป้องกัน) ที่คุณควรพิจารณาเมื่อสร้างแบบจําลอง Power BI ที่เชื่อมต่อกับ Dataverse มีเพียงไม่กี่รูปแบบเท่านั้นที่มีเอกลักษณ์สําหรับ Dataverse แต่มีแนวโน้มที่จะเป็นความท้าทายทั่วไปสําหรับผู้สร้าง Dataverse เมื่อพวกเขากล่าวถึงการสร้างรายงาน Power BI
มุ่งเน้นไปที่กรณีการใช้งานเฉพาะ
แทนที่จะพยายามแก้ไข ทุกอย่าง ให้มุ่งเน้นไปที่กรณีการใช้งานเฉพาะ
คําแนะนํานี้อาจเป็นรูปแบบการป้องกันที่พบบ่อยและยากที่สุดที่จะหลีกเลี่ยง การพยายามสร้างแบบจําลองเดี่ยวที่ทําให้ความต้องการการรายงานแบบบริการตนเองทั้งหมดเป็นเรื่องที่ท้าทาย ความจริงก็คือแบบจําลองที่ประสบความสําเร็จถูกสร้างขึ้นเพื่อตอบคําถามเกี่ยวกับชุดข้อเท็จจริงส่วนกลางในหัวข้อหลักเดียว แม้ว่าในตอนแรกอาจดูเหมือนจะจํากัดแบบจําลอง แต่ก็เป็นการเพิ่มประสิทธิภาพเนื่องจากคุณสามารถปรับแต่งและปรับแบบจําลองให้เหมาะสมสําหรับการตอบคําถามภายในหัวข้อนั้นได้
เพื่อช่วยให้แน่ใจว่าคุณมีความเข้าใจที่ชัดเจนเกี่ยวกับวัตถุประสงค์ของแบบจําลอง ให้ถามคําถามต่อไปนี้กับตัวคุณเอง
- หัวข้อใดที่แบบจําลองนี้สนับสนุน
- ใครคือผู้ชมของรายงาน
- รายงานพยายามตอบคําถามใด
- อะไรคือแบบจําลองความหมายขั้นต่ําที่สามารถทํางานได้?
ยืนยันการรวมพื้นที่หัวข้อหลายรายการเข้าด้วยกันเป็นแบบจําลองเดียวเพียงเพราะผู้ใช้รายงานมีคําถามในพื้นที่หัวข้อหลายหัวข้อที่พวกเขาต้องการแก้ไขด้วยรายงานเดียว โดยการแบ่งรายงานนั้นออกเป็นรายงานหลายรายการ โดยแต่ละรายงานมีโฟกัสที่หัวข้อที่แตกต่างกัน (หรือ ตารางข้อเท็จจริง) คุณสามารถสร้างแบบจําลองที่มีประสิทธิภาพปรับขนาดได้และสามารถจัดการได้มากขึ้น
ออกแบบสคีมาแบบดาว
นักพัฒนาข้อมูลและผู้ดูแลระบบที่คุ้นเคยกับ Schema Dataverse อาจถูกชักจูงให้สร้าง Schema เดียวกันใน Power BI อีกครั้ง วิธีนี้เป็นรูปแบบป้องกันและอาจเป็นปัญหาที่ยากที่สุดในการเอาชนะเพราะมัน รู้สึกถึงขวา ที่จะรักษาความสอดคล้อง
Dataverse ในฐานะแบบจําลองเชิงสัมพันธ์เหมาะสําหรับวัตถุประสงค์ อย่างไรก็ตาม แบบจําลองนี้ไม่ได้ออกแบบมาเป็นแบบจําลองการวิเคราะห์ที่ปรับให้เหมาะสมสําหรับ รายงานการวิเคราะห์ รูปแบบที่แพร่หลายมากที่สุดสําหรับข้อมูลการวิเคราะห์การสร้างแบบจําลองคือการออกแบบ Schema รูปดาว แบบจําลองมิติที่มีลักษณะคล้ายดาวคือวิธีการสร้างแบบจําลองที่สมบูรณ์ซึ่งนํามาใช้โดยคลังข้อมูลเชิงสัมพันธ์อย่างกว้างขวาง ซึ่งกําหนดให้ตัวสร้างแบบจําลองจัดประเภทตารางแบบจําลองของตนเป็นมิติหรือข้อเท็จจริง รายงานสามารถกรองหรือจัดกลุ่มโดยใช้คอลัมน์ตารางมิติและสรุปคอลัมน์ตารางข้อเท็จจริงได้
สําหรับข้อมูลเพิ่มเติม โปรดดูทําความเข้าใจ Schema รูปดาวและความสําคัญของ Power BI
ปรับคิวรี Power Query ให้เหมาะสม
กลไกการผสมเข้าด้วยกันของ Power Query มีเป้าหมายเพื่อให้สามารถทําการพับคิวรีได้เมื่อใดก็ตามที่เป็นไปได้เพื่อเหตุผลของประสิทธิภาพ คิวรีที่ทําการพับได้มอบหมายการประมวลผลคิวรีไปยังระบบต้นทาง
ระบบต้นทางในกรณีนี้ Dataverse จากนั้นจะต้องส่งผลลัพธ์ที่กรองหรือสรุปไปยัง Power BI เท่านั้น คิวรีแบบพับมักจะเร็วกว่าและมีประสิทธิภาพมากกว่าคิวรีที่ไม่ได้พับอย่างมีนัยสําคัญ
สําหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีที่คุณสามารถทําการพับคิวรีได้ โปรดดู การพับคิวรีใน Power Query
หมายเหตุ
การปรับ Power Query ให้เหมาะสมเป็นหัวข้อที่กว้างขวาง เพื่อให้เข้าใจได้ดียิ่งขึ้นว่า Power Query กําลังทําอะไรอยู่ขณะเขียนและในเวลาที่รีเฟรชแบบจําลองใน Power BI Desktop โปรดดู การวินิจฉัยคิวรี
ลดจํานวนคอลัมน์คิวรี
ตามค่าเริ่มต้น เมื่อคุณใช้ Power Query เพื่อโหลดตาราง Dataverse ระบบจะดึงข้อมูลแถวและคอลัมน์ทั้งหมด ตัวอย่างเช่น เมื่อคุณคิวรีตารางผู้ใช้ระบบ อาจมีคอลัมน์มากกว่า 1,000 คอลัมน์ คอลัมน์ในเมตาดาต้ามีความสัมพันธ์กับเอนทิตีอื่น และการค้นหาป้ายชื่อตัวเลือก ดังนั้นจํานวนคอลัมน์ทั้งหมดจึงเพิ่มขึ้นด้วยความซับซ้อนของตาราง Dataverse
การพยายามดึงข้อมูลจากคอลัมน์ทั้งหมดเป็นรูปแบบการป้องกัน ซึ่งมักจะส่งผลให้การดําเนินการรีเฟรชข้อมูลขยายและจะทําให้คิวรีล้มเหลวเมื่อเวลาในการส่งกลับข้อมูลเกิน 10 นาที
เราขอแนะนําให้คุณดึงข้อมูลเฉพาะคอลัมน์ที่จําเป็นในรายงานเท่านั้น มักจะเป็นความคิดที่ดีที่จะประเมินค่าคิวรีใหม่และปรับโครงสร้างคิวรีเมื่อการพัฒนารายงานเสร็จสมบูรณ์ ช่วยให้คุณสามารถระบุและลบคอลัมน์ที่ไม่ได้ใช้ได้ สําหรับข้อมูลเพิ่มเติม โปรดดูเทคนิคการลดข้อมูลสําหรับการสร้างแบบจําลองการนําเข้า (ลบคอลัมน์ที่ไม่จําเป็น)
นอกจากนี้ ตรวจสอบให้แน่ใจว่าคุณแนะนําขั้นตอน การลบคอลัมน์ Power Query ตั้งแต่ต้นเพื่อให้พับกลับไปยังแหล่งข้อมูล ด้วยวิธีดังกล่าว Power Query สามารถหลีกเลี่ยงงานที่ไม่จําเป็นในการแยกข้อมูลต้นฉบับเพื่อละทิ้งในภายหลัง (ในขั้นตอนที่ยังไม่ได้แก้ไข)
เมื่อคุณมีตารางที่มีคอลัมน์จํานวนมาก อาจเป็นไปไม่ได้ที่จะใช้ตัวสร้างคิวรีแบบโต้ตอบของ Power Query ในกรณีนี้ คุณสามารถเริ่มต้นโดยการสร้างคิวรีเปล่า จากนั้นคุณสามารถใช้เครื่องมือแก้ไขขั้นสูงเพื่อวางในคิวรีที่น้อยที่สุดที่สร้างจุดเริ่มต้น
พิจารณาคิวรีต่อไปนี้ที่ดึงข้อมูลจากเพียงสองคอลัมน์ของตารางบัญชี
let
Source = CommonDataService.Database("demo.crm.dynamics.com", [CreateNavigationProperties=false]),
dbo_account = Source{[Schema="dbo", Item="account"]}[Data],
#"Removed Other Columns" = Table.SelectColumns(dbo_account, {"accountid", "name"})
in
#"Removed Other Columns"
เขียนคิวรีในระบบ
เมื่อคุณมีข้อกําหนดการแปลงเฉพาะ คุณอาจมีประสิทธิภาพการทํางานที่ดีขึ้นโดยใช้คิวรีดั้งเดิมที่เขียนใน SQL ผกผันข้อมูล ซึ่งเป็นชุดย่อยของ Transact-SQL คุณสามารถเขียนคิวรีดั้งเดิมไปยัง:
- ลดจํานวนแถว (โดยใช้ส่วน
WHERE
คําสั่ง) - รวมข้อมูล (โดยใช้คําสั่ง
GROUP BY
และHAVING
) - รวมตารางด้วยวิธีเฉพาะ (โดยใช้
JOIN
ไวยากรณ์ หรือAPPLY
) - ใช้ฟังก์ชัน SQL ที่ได้รับการสนับสนุน
สำหรับข้อมูลเพิ่มเติม โปรดดู:
ใช้คิวรีในระบบด้วยตัวเลือก EnableFolding
Power Query ดําเนินการคิวรีในระบบของฐานข้อมูลโดยใช้ Value.NativeQuery
ฟังก์ชัน
เมื่อใช้ฟังก์ชันนี้ สิ่งสําคัญคือการเพิ่ม EnableFolding=true
ตัวเลือกเพื่อให้แน่ใจว่าคิวรีจะถูกพับกลับไปยังบริการ Dataverse คิวรีในระบบของฐานข้อมูลจะไม่ถูกพับเว้นแต่ว่าจะมีการเพิ่มตัวเลือกนี้ การเปิดใช้งานตัวเลือกนี้อาจส่งผลให้เกิดการปรับปรุงประสิทธิภาพการทํางานที่มีนัยสําคัญ — เร็วขึ้นสูงสุดถึง 97 เปอร์เซ็นต์ในบางกรณี
พิจารณาคิวรีต่อไปนี้ที่ใช้คิวรีในระบบไปยังแหล่งที่มาของคอลัมน์ที่เลือกจากตารางบัญชี คิวรีในระบบของฐานข้อมูลจะถูกพับเนื่องจากมี EnableFolding=true
การตั้งค่าตัวเลือก
let
Source = CommonDataService.Database("demo.crm.dynamics.com"),
dbo_account = Value.NativeQuery(
Source,
"SELECT A.accountid, A.name FROM account A"
,null
,[EnableFolding=true]
)
in
dbo_account
คุณสามารถคาดหวังที่จะได้รับการปรับปรุงประสิทธิภาพการทํางานที่ดีที่สุดเมื่อดึงข้อมูลชุดย่อยจากปริมาณข้อมูลขนาดใหญ่
เคล็ดลับ
การปรับปรุงประสิทธิภาพการทํางานยังสามารถขึ้นอยู่กับวิธีการคิวรี Power BI ของฐานข้อมูลต้นทาง ตัวอย่างเช่น หน่วยวัดที่ใช้ COUNTDISTINCT
ฟังก์ชัน DAX แสดงว่าแทบจะไม่ได้ปรับปรุงเลยโดยมีหรือไม่มีคําแนะนําการพับ เมื่อมีการเขียนสูตรหน่วยวัดใหม่เพื่อใช้ SUMX
ฟังก์ชัน DAX คิวรีจะถูกพับส่งผลให้มีการปรับปรุง 97 เปอร์เซ็นต์ในคิวรีเดียวกันโดยไม่มีคําแนะนํา
สําหรับข้อมูลเพิ่มเติม โปรดดู Value.NativeQuery (ตัวเลือก EnableFolding
ไม่ได้จัดทําเป็นเอกสารเนื่องจากเป็นตัวเลือกเฉพาะบางแหล่งข้อมูล)
เร่งความเร็วของขั้นตอนการประเมิน
ถ้าคุณกําลังใช้ตัว เชื่อมต่อ Dataverse (เดิมเรียกว่า Common Data Service) คุณสามารถเพิ่ม CreateNavigationProperties=false
ตัวเลือกเพื่อเพิ่มความเร็วขั้นตอนการประเมินของการนําเข้าข้อมูลได้
ลําดับขั้นการประเมินของการนําเข้าข้อมูลจะวนรอบผ่านเมตาดาต้าของแหล่งข้อมูลเพื่อกําหนดความสัมพันธ์ของตารางที่เป็นไปได้ทั้งหมด เมตาดาต้านั้นสามารถครอบคลุมได้โดยเฉพาะอย่างยิ่งสําหรับ Dataverse การเพิ่มตัวเลือกนี้ลงในคิวรี แสดงว่าคุณทําให้ Power Query ทราบว่าคุณไม่ตั้งใจที่จะใช้ความสัมพันธ์เหล่านั้น ตัวเลือกอนุญาตให้ Power BI Desktop ข้ามขั้นตอนดังกล่าวของการรีเฟรช และไปต่อเพื่อดึงข้อมูล
หมายเหตุ
อย่าใช้ตัวเลือกนี้เมื่อคิวรีขึ้นอยู่กับคอลัมน์ความสัมพันธ์ที่ขยายใด ๆ
พิจารณาตัวอย่างที่ดึงข้อมูลจากตารางบัญชี ซึ่งประกอบด้วยสามคอลัมน์ที่เกี่ยวข้องกับอาณาเขต: territory, territoryid และ territoryidname
เมื่อคุณตั้งค่า CreateNavigationProperties=false
ตัวเลือก คอลัมน์ territoryid และ territoryidname จะยังคงอยู่ แต่ คอลัมน์ดินแดน ซึ่งเป็นคอลัมน์ความสัมพันธ์ (ซึ่งแสดง ลิงก์ค่า ) จะถูกแยกออก สิ่งสําคัญคือต้องเข้าใจว่าคอลัมน์ความสัมพันธ์ของ Power Query เป็นแนวคิดที่แตกต่างกันสําหรับ ความสัมพันธ์ของแบบจําลอง ซึ่งเผยแพร่ตัวกรองระหว่างตารางแบบจําลอง
พิจารณาคิวรีต่อไปนี้ที่ใช้ CreateNavigationProperties=false
ตัวเลือก (ใน ขั้นตอนแหล่งข้อมูล ) เพื่อเร่งความเร็วขั้นตอนการประเมินของการนําเข้าข้อมูล
let
Source = CommonDataService.Database("demo.crm.dynamics.com"
,[CreateNavigationProperties=false]),
dbo_account = Source{[Schema="dbo", Item="account"]}[Data],
#"Removed Other Columns" = Table.SelectColumns(dbo_account, {"accountid", "name", "address1_stateorprovince", "address1_country", "industrycodename", "territoryidname"}),
#"Renamed Columns" = Table.RenameColumns(#"Removed Other Columns", {{"name", "Account Name"}, {"address1_country", "Country"}, {"address1_stateorprovince", "State or Province"}, {"territoryidname", "Territory"}, {"industrycodename", "Industry"}})
in
#"Renamed Columns"
เมื่อใช้ตัวเลือกนี้ คุณมีแนวโน้มที่จะได้รับการปรับปรุงประสิทธิภาพการทํางานที่สําคัญเมื่อตาราง Dataverse มีความสัมพันธ์มากมายกับตารางอื่น ๆ ตัวอย่างเช่นเนื่องจาก ตาราง SystemUser เกี่ยวข้องกับตารางอื่น ๆ ในฐานข้อมูลประสิทธิภาพการรีเฟรชของตารางนี้จะเป็นประโยชน์โดยการตั้งค่า CreateNavigationProperties=false
ตัวเลือก
หมายเหตุ
ตัวเลือกนี้สามารถปรับปรุงประสิทธิภาพของการรีเฟรชข้อมูลของตารางนําเข้าหรือตารางโหมดที่เก็บข้อมูลแบบคู่ รวมถึงกระบวนการของการใช้การเปลี่ยนแปลงหน้าต่างตัวแก้ไข Power Query ซึ่งไม่ได้ช่วยปรับปรุงประสิทธิภาพการทํางานของการกรองข้ามแบบโต้ตอบของตารางโหมดที่เก็บข้อมูล DirectQuery
แก้ไขป้ายชื่อตัวเลือกที่ว่างเปล่า
ถ้าคุณพบว่าป้ายชื่อตัวเลือก Dataverse ว่างเปล่าใน Power BI อาจเนื่องมาจากป้ายชื่อยังไม่ได้เผยแพร่ไปยังจุดสิ้นสุดสตรีมข้อมูลแบบตาราง (TDS)
ในกรณีนี้ เปิดพอร์ทัล Dataverse Maker นําทางไปยัง พื้นที่โซลูชัน จากนั้นเลือก เผยแพร่การเลือกกําหนดทั้งหมด กระบวนการเผยแพร่จะอัปเดตจุดสิ้นสุด TDS ด้วยเมตาดาต้าล่าสุด ทําให้ป้ายชื่อตัวเลือกพร้อมใช้งานสําหรับ Power BI
แบบจําลองความหมายที่มีขนาดใหญ่ขึ้นด้วย Azure Synapse Link
Dataverse รวมถึงความสามารถในการซิงโครไนซ์ตารางไปยัง Azure Data Lake Storage (ADLS) จากนั้นจึงเชื่อมต่อกับข้อมูลนั้นผ่านพื้นที่ทํางาน Azure Synapse ด้วยความพยายามที่น้อยที่สุด คุณสามารถตั้งค่า Azure Synapse Link เพื่อรวบรวมข้อมูล Dataverse ลงใน Azure Synapse และช่วยให้ทีมข้อมูลสามารถค้นพบข้อมูลเชิงลึกมากขึ้นได้
Azure Synapse Link ช่วยให้การจําลองข้อมูลและเมตาดาต้าจาก Dataverse ลงใน data lake ได้อย่างต่อเนื่อง นอกจากนี้ยังมีพูล SQL แบบไร้เซิร์ฟเวอร์ในตัวเป็นแหล่งข้อมูลที่สะดวกสําหรับคิวรี Power BI
จุดแข็งของวิธีนี้มีนัยสําคัญ ลูกค้าจะได้รับความสามารถในการเรียกใช้การวิเคราะห์ ข่าวกรองธุรกิจ และปริมาณงานการเรียนรู้ของเครื่องในข้อมูล Dataverse โดยใช้บริการขั้นสูงต่าง ๆ บริการขั้นสูงรวมถึง Apache Spark, Power BI, Azure Data Factory, Azure Databricks และ Azure Machine Learning
สร้างลิงก์ Azure Synapse สําหรับ Dataverse
หากต้องการสร้างลิงก์ Azure Synapse สําหรับ Dataverse คุณจะต้องมีข้อกําหนดเบื้องต้นต่อไปนี้อยู่ในตําแหน่ง
- ผู้ดูแลระบบเข้าถึงสภาพแวดล้อม Dataverse
- สําหรับ Azure Data Lake Storage:
- คุณต้องมีบัญชีเก็บข้อมูลเพื่อใช้กับ ADLS Gen2
- คุณต้องได้รับ มอบหมายให้เจ้าของ Blob Data Storage และ ผู้สนับสนุน ข้อมูล Blob ของที่เก็บข้อมูล เข้าถึงบัญชีเก็บข้อมูล สําหรับข้อมูลเพิ่มเติม ให้ดู การควบคุมการเข้าถึงตามบทบาท (Azure RBAC)
- บัญชีเก็บข้อมูลต้องเปิดใช้งาน เนมสเปซแบบลําดับชั้น
- ขอแนะนําให้บัญชีเก็บข้อมูลใช้พื้นที่จัดเก็บข้อมูลทางภูมิศาสตร์การเข้าถึงแบบอ่านได้ (RA-GRS)
- สําหรับพื้นที่ทํางาน Synapse:
- คุณต้องมีสิทธิ์เข้าถึงพื้นที่ทํางาน Synapse และได้รับมอบหมาย ให้เข้าถึงโดยผู้ดูแลระบบ Synapse สําหรับข้อมูลเพิ่มเติม โปรดดู บทบาทและขอบเขต Synapse RBAC ที่มีอยู่ภายใน
- พื้นที่ทํางานต้องอยู่ในภูมิภาคเดียวกันกับบัญชีเก็บข้อมูล ADLS Gen2
การตั้งค่าเกี่ยวข้องกับการลงชื่อเข้าใช้ Power Apps และการเชื่อมต่อ Dataverse ไปยังพื้นที่ทํางาน Azure Synapse ประสบการณ์เหมือนตัวช่วยสร้างช่วยให้คุณสามารถสร้างลิงก์ใหม่โดยการเลือกบัญชีเก็บข้อมูลและตารางที่จะส่งออก Azure Synapse Link คัดลอกข้อมูลไปยังที่เก็บข้อมูล ADLS Gen2 และสร้างมุมมองในตัวของพูล SQL แบบไร้เซิร์ฟเวอร์ใน Azure Synapse โดยอัตโนมัติ จากนั้น คุณสามารถเชื่อมต่อกับมุมมอง เหล่านั้นเพื่อสร้างแบบจําลอง Power BI ได้
เคล็ดลับ
สําหรับเอกสารประกอบที่สมบูรณ์เกี่ยวกับการสร้าง จัดการ และตรวจสอบลิงก์ Azure Synapse ดู สร้าง Azure Synapse Link สําหรับ Dataverse ด้วยพื้นที่ทํางาน Azure Synapse ของคุณ
สร้างฐานข้อมูล SQL แบบไร้เซิร์ฟเวอร์ตัวที่สอง
คุณสามารถสร้างฐานข้อมูล SQL แบบไร้เซิร์ฟเวอร์ตัวที่สอง และใช้เพื่อเพิ่มมุมมองรายงานแบบกําหนดเองได้ ด้วยวิธีนี้ คุณสามารถนําเสนอชุดข้อมูลที่เรียบง่ายให้กับผู้สร้าง Power BI ที่อนุญาตให้พวกเขาสร้างแบบจําลองที่ยึดตามข้อมูลที่เป็นประโยชน์และเกี่ยวข้อง ฐานข้อมูล SQL แบบไร้เซิร์ฟเวอร์ใหม่จะกลายเป็นการเชื่อมต่อแหล่งข้อมูลหลักของผู้สร้าง และการแสดงข้อมูลที่เรียกง่ายของข้อมูลที่มาจาก data lake
วิธีการนี้นําเสนอข้อมูลไปยัง Power BI ที่เน้น เสริมสร้าง และกรองแล้ว
คุณสามารถสร้างฐานข้อมูล SQL แบบไร้เซิร์ฟเวอร์ในพื้นที่ทํางาน Azure Synapse โดยใช้ Azure Synapse Studio เลือก ไร้ เซิร์ฟเวอร์ เป็นชนิดฐานข้อมูล SQL และป้อนชื่อฐานข้อมูล Power Query สามารถเชื่อมต่อกับฐานข้อมูลนี้โดยการเชื่อมต่อกับจุดสิ้นสุด SQL ของพื้นที่ทํางาน
สร้างมุมมองแบบกําหนดเอง
คุณสามารถสร้างมุมมองแบบกําหนดเองที่ครอบคลุมคิวรีพูล SQL แบบไร้เซิร์ฟเวอร์ มุมมองเหล่านี้จะทําหน้าที่เป็นแหล่งข้อมูลที่สะอาดและตรงไปตรงมาที่ Power BI ที่เชื่อมต่อด้วย มุมมองควร:
- รวมป้ายชื่อที่เกี่ยวข้องกับเขตข้อมูลตัวเลือก
- ลดความซับซ้อนโดยรวมเฉพาะคอลัมน์ที่จําเป็นสําหรับการสร้างแบบจําลองข้อมูล
- กรองแถวที่ไม่จําเป็นออก เช่น ระเบียนที่ไม่ได้ใช้งาน
พิจารณามุมมองต่อไปนี้ที่ดึงข้อมูลการส่งเสริมการขาย
CREATE VIEW [VW_Campaign]
AS
SELECT
[base].[campaignid] AS [CampaignID]
[base].[name] AS [Campaign],
[campaign_status].[LocalizedLabel] AS [Status],
[campaign_typecode].[LocalizedLabel] AS [Type Code]
FROM
[<MySynapseLinkDB>].[dbo].[campaign] AS [base]
LEFT OUTER JOIN [<MySynapseLinkDB>].[dbo].[OptionsetMetadata] AS [campaign_typecode]
ON [base].[typecode] = [campaign_typecode].[option]
AND [campaign_typecode].[LocalizedLabelLanguageCode] = 1033
AND [campaign_typecode].[EntityName] = 'campaign'
AND [campaign_typecode].[OptionSetName] = 'typecode'
LEFT OUTER JOIN [<MySynapseLinkDB>].[dbo].[StatusMetadata] AS [campaign_status]
ON [base].[statuscode] = [campaign_Status].[status]
AND [campaign_status].[LocalizedLabelLanguageCode] = 1033
AND [campaign_status].[EntityName] = 'campaign'
WHERE
[base].[statecode] = 0;
โปรดสังเกตว่ามุมมองมีเพียงสี่คอลัมน์ เท่านั้น ซึ่งแต่ละนามแฝงด้วยชื่อที่เรียกง่าย นอกจากนี้ยังมีข้อ WHERE
ที่จะส่งคืนเฉพาะแถวที่จําเป็นในกรณีนี้คือแคมเปญที่ใช้งานอยู่ นอกจากนี้ มุมมองจะคิวรีตารางการส่งเสริมการขายที่รวมเข้ากับ ตาราง OptionsetMetadata และ StatusMetadata ซึ่งดึงข้อมูลป้ายชื่อตัวเลือก
เคล็ดลับ
สําหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการเรียกใช้เมตาดาต้า ดูเข้าถึงป้ายชื่อตัวเลือกโดยตรงจาก Azure Synapse Link สําหรับ Dataverse
คิวรีตารางที่เหมาะสม
Azure Synapse Link สําหรับ Dataverse ช่วยให้แน่ใจว่าข้อมูลมีการซิงโครไนซ์อย่างต่อเนื่องกับข้อมูลใน data lake สําหรับกิจกรรมการใช้งานสูง การเขียนและการอ่านพร้อมกันสามารถสร้างล็อคที่ทําให้คิวรีล้มเหลว เพื่อให้แน่ใจว่ามีความน่าเชื่อถือเมื่อดึงข้อมูล ข้อมูลตารางสองเวอร์ชันจะถูกซิงโครไนซ์ใน Azure Synapse
- ใกล้กับข้อมูลแบบเรียลไทม์: ให้สําเนาของข้อมูลที่ซิงโครไนซ์จาก Dataverse ผ่าน Azure Synapse Link ในลักษณะที่มีประสิทธิภาพโดยการตรวจหาข้อมูลที่มีการเปลี่ยนแปลงเนื่องจากถูกแยกออกมาหรือซิงโครไนซ์ครั้งล่าสุด
- ข้อมูลสแนปช็อต: ให้สําเนาแบบอ่านอย่างเดียวของข้อมูลที่ใกล้เคียงกับเวลาจริงที่มีการอัปเดตตามช่วงเวลาปกติ (ในกรณีนี้คือทุกชั่วโมง) ชื่อตารางข้อมูลสแนปช็อตมี _partitioned ผนวกเข้ากับชื่อของตารางเหล่านั้น
ถ้าคุณคาดว่าจะมีการดําเนินการอ่านและเขียนในปริมาณมากในเวลาเดียวกัน ให้ดึงข้อมูลจากตารางสแนปช็อตเพื่อหลีกเลี่ยงความล้มเหลวของคิวรี
สําหรับข้อมูลเพิ่มเติม ดู การเข้าถึงใกล้กับข้อมูลแบบเรียลไทม์และข้อมูลสแนปช็อตแบบอ่านอย่างเดียว
เชื่อมต่อกับ Synapse Analytics
ในการคิวรีพูล SQL แบบไร้เซิร์ฟเวอร์ของ Azure Synapse คุณจะต้องมีจุดสิ้นสุด SQL ของพื้นที่ทํางาน คุณสามารถเรียกใช้จุดสิ้นสุดจาก Synapse Studio ได้โดยการเปิดคุณสมบัติพูล SQL แบบไร้เซิร์ฟเวอร์
ใน Power BI Desktop คุณสามารถเชื่อมต่อกับ Azure Synapse โดยใช้ตัว เชื่อมต่อ Azure Synapse Analytics SQL ได้ เมื่อได้รับพร้อมท์สําหรับเซิร์ฟเวอร์ ให้ใส่จุดสิ้นสุด SQL ของพื้นที่ทํางาน
ข้อควรพิจารณาสําหรับ DirectQuery
มีหลายกรณีการใช้งานเมื่อใช้โหมดที่เก็บข้อมูล DirectQuery สามารถแก้ไขความต้องการของคุณได้ อย่างไรก็ตาม การใช้ DirectQuery สามารถส่งผลเสียต่อประสิทธิภาพรายงาน Power BI รายงานที่ใช้การเชื่อมต่อ DirectQuery ไปยัง Dataverse จะไม่เร็วเท่ากับรายงานที่ใช้แบบจําลองการนําเข้า โดยทั่วไป คุณควรนําเข้าข้อมูลไปยัง Power BI เมื่อใดก็ตามที่เป็นไปได้
เราขอแนะนําให้คุณพิจารณาหัวข้อในส่วนนี้เมื่อทํางานกับ DirectQuery
สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการกําหนดเวลาที่จะทํางานกับโหมดที่เก็บข้อมูล DirectQuery โปรดดู เลือกเฟรมเวิร์กแบบจําลอง Power BI
ใช้ตารางมิติข้อมูลโหมดที่เก็บข้อมูลแบบคู่
ตารางโหมดที่เก็บข้อมูลแบบคู่ได้รับการตั้งค่าให้ใช้ทั้งโหมดที่เก็บข้อมูลแบบนําเข้าและ DirectQuery ในเวลาคิวรี Power BI จะกําหนดโหมดที่มีประสิทธิภาพมากที่สุดที่จะใช้ เมื่อใดก็ตามที่เป็นไปได้ Power BI จะพยายามตอบสนองคิวรีโดยใช้ข้อมูลที่นําเข้าเนื่องจากเร็วขึ้น
คุณควรพิจารณาการตั้งค่าตารางมิติเป็นโหมดที่เก็บข้อมูลแบบคู่เมื่อเหมาะสม ด้วยวิธีนี้ วิชวลตัวแบ่งส่วนข้อมูลและรายการบัตรตัวกรอง— ซึ่งมักจะยึดตามคอลัมน์ตารางมิติ— จะแสดงได้อย่างรวดเร็วเนื่องจากวิชวลเหล่านี้จะถูกคิวรีจากข้อมูลที่นําเข้า
สำคัญ
เมื่อตารางมิติจําเป็นต้องสืบทอดแบบจําลองความปลอดภัย Dataverse มันไม่เหมาะสมที่จะใช้โหมดที่เก็บข้อมูลแบบคู่
ตารางข้อเท็จจริง ซึ่งโดยทั่วไปแล้วจะจัดเก็บข้อมูลจํานวนมากควรยังคงเป็นตารางโหมดที่เก็บข้อมูล DirectQuery ซึ่งจะถูกกรองโดยตารางมิติโหมดที่เก็บข้อมูลคู่ที่เกี่ยวข้องซึ่งสามารถเข้าร่วมกับตารางข้อเท็จจริงเพื่อให้ได้การกรองและการจัดกลุ่มที่มีประสิทธิภาพ
พิจารณาการออกแบบแบบจําลองข้อมูลต่อไปนี้ ตารางมิติสามตาราง เจ้าของ บัญชี และการส่งเสริมการขายมีขอบด้านบนที่เป็นแถบซึ่งหมายความว่ามีการตั้งค่าเป็นโหมดที่เก็บข้อมูลแบบคู่
สําหรับข้อมูลเพิ่มเติมเกี่ยวกับโหมดที่เก็บข้อมูลตารางรวมถึงที่เก็บข้อมูลแบบคู่ โปรดดู จัดการโหมดที่เก็บข้อมูลใน Power BI Desktop
เปิดใช้งานการลงชื่อเข้าระบบครั้งเดียว
เมื่อคุณเผยแพร่แบบจําลอง DirectQuery ไปยังบริการของ Power BI คุณสามารถใช้การตั้งค่าแบบจําลองเชิงความหมายเพื่อเปิดใช้งานการลงชื่อเข้าระบบครั้งเดียว (SSO) โดยใช้ Microsoft Entra ID OAuth2 สําหรับผู้ใช้รายงานของคุณ คุณควรเปิดใช้งานตัวเลือกนี้เมื่อคิวรี Dataverse ต้องดําเนินการในบริบทความปลอดภัยของผู้ใช้รายงาน
เมื่อเปิดใช้งานตัวเลือก SSO แล้ว Power BI จะส่งข้อมูลประจําตัว Microsoft Entra ที่รับรองความถูกต้องของผู้ใช้รายงานในคิวรีไปยัง Dataverse ตัวเลือกนี้ช่วยให้ Power BI ทําตามการตั้งค่าความปลอดภัยที่ถูกตั้งค่าในแหล่งข้อมูล
สําหรับข้อมูลเพิ่มเติม ให้ดู การลงชื่อเข้าระบบครั้งเดียว (SSO) สําหรับแหล่งข้อมูล DirectQuery
ทําซ้ําตัวกรอง "ของฉัน" ใน Power Query
เมื่อใช้ Microsoft Dynamics 365 Customer Engagement (CE) และ Power Apps ที่ขับเคลื่อนด้วยแบบจําลองที่สร้างขึ้นบน Dataverse คุณสามารถสร้างมุมมองที่แสดงเฉพาะระเบียนที่มีเขตข้อมูลชื่อผู้ใช้เช่น เจ้าของ เท่ากับผู้ใช้ปัจจุบันได้ ตัวอย่างเช่น คุณอาจสร้างมุมมองที่มีชื่อว่า "โอกาสเปิดของฉัน" "กรณีที่ใช้งานอยู่ของฉัน" และอื่น ๆ
พิจารณาตัวอย่างว่ามุมมอง Dynamics 365 บัญชี ที่ใช้งานอยู่ของฉัน มีตัวกรองที่ เจ้าของเท่ากับผู้ใช้ปัจจุบันอย่างไร
คุณสามารถทําซ้ําผลลัพธ์นี้ใน Power Query ได้โดยใช้คิวรีดั้งเดิมที่ฝัง CURRENT_USER
โทเค็น
พิจารณาตัวอย่างต่อไปนี้ที่แสดงคิวรีในระบบของฐานข้อมูลที่ส่งกลับบัญชีสําหรับผู้ใช้ปัจจุบัน ในส่วน WHERE
คําสั่ง ให้สังเกตว่า คอลัมน์ ownerid ถูกกรองโดย CURRENT_USER
โทเค็น
let
Source = CommonDataService.Database("demo.crm.dynamics.com", [CreateNavigationProperties=false],
dbo_account = Value.NativeQuery(Source, "
SELECT
accountid, accountnumber, ownerid, address1_city, address1_stateorprovince, address1_country
FROM account
WHERE statecode = 0
AND ownerid = CURRENT_USER
", null, [EnableFolding]=true])
in
dbo_account
เมื่อคุณเผยแพร่แบบจําลองไปยังบริการของ Power BI คุณต้องเปิดใช้งานการลงชื่อเข้าระบบครั้งเดียว (SSO) เพื่อให้ Power BI จะส่งข้อมูลประจําตัว Microsoft Entra ที่รับรองความถูกต้องของผู้ใช้รายงานไปยัง Dataverse
สร้างแบบจําลองการนําเข้าเพิ่มเติม
คุณสามารถสร้างแบบจําลอง DirectQuery ที่บังคับใช้สิทธิ์ Dataverse โดย ทราบว่าประสิทธิภาพการทํางานจะช้า จากนั้นคุณสามารถเสริมแบบจําลองนี้ด้วยแบบจําลองการนําเข้าที่กําหนดเป้าหมายหัวเรื่องหรือผู้ชมเฉพาะที่สามารถบังคับใช้สิทธิ์ RLS ได้
ตัวอย่างเช่น แบบจําลองการนําเข้าสามารถให้การเข้าถึงข้อมูลทั้งหมด Dataverse แต่ไม่บังคับใช้สิทธิ์ใด ๆ แบบจําลองนี้เหมาะสมกับผู้บริหารที่มีสิทธิ์เข้าถึงข้อมูลทั้งหมดอยู่แล้ว
อีกตัวอย่างหนึ่ง เมื่อ Dataverse บังคับใช้สิทธิ์ตามบทบาทตามภูมิภาคการขาย คุณสามารถสร้างแบบจําลองการนําเข้าหนึ่งแบบและทําซ้ําสิทธิ์เหล่านั้นโดยใช้ RLS ได้ อีกวิธีหนึ่งคือ คุณสามารถสร้างแบบจําลองสําหรับแต่ละภูมิภาคการขายได้ จากนั้นคุณสามารถให้สิทธิ์ในการอ่านกับแบบจําลองเหล่านั้น (แบบจําลองเชิงความหมาย) ให้กับพนักงานขายของแต่ละภูมิภาคได้ เพื่ออํานวยความสะดวกในการสร้างแบบจําลองภูมิภาคเหล่านี้ คุณสามารถใช้พารามิเตอร์และเทมเพลตรายงานได้ สําหรับข้อมูลเพิ่มเติม ดูสร้างและใช้เทมเพลตรายงานใน Power BI Desktop
เนื้อหาที่เกี่ยวข้อง
สําหรับข้อมูลเพิ่มเติมที่เกี่ยวข้องกับบทความนี้ โปรดดูทรัพยากรต่อไปนี้