แยกรายงานจากแบบPower BI Desktop

เมื่อสร้างโซลูชันPower BI Desktopใหม่ หนึ่งในงานแรกที่คุณต้องสร้างคือ "รับข้อมูล" การรับข้อมูลสามารถส่งผลให้เกิดผลลัพธ์ที่แตกต่างกันที่แตกต่างกันสองอย่าง ซึ่งอาจเป็นได้:

  • สร้าง การเชื่อมต่อสด ไปยังโมเดลที่เผยแพร่แล้ว ซึ่งอาจเป็นชุดข้อมูล Power BI หรือโมเดลข้อมูลที่โฮสต์Analysis Servicesระยะไกล
  • เริ่มการพัฒนาแบบโมเดลใหม่ซึ่งอาจเป็นได้ทั้งแบบนําเข้า DirectQuery หรือโมเดลแบบรวม

บทความนี้เกี่ยวข้องกับสถานการณ์ที่สอง จะให้แนวทางเกี่ยวกับว่าควรรวมรายงานและแบบโมเดลลงในไฟล์Power BI Desktopเดียวหรือไม่

โซลูชันไฟล์เดียว

โซลูชัน ไฟล์เดียว ใช้งานได้ดีเมื่อมีรายงานเดี่ยวที่ยึดตามแบบโมเดลเท่านั้น ในกรณีนี้ อาจไม่มีความพยายามที่จะรวมทั้งแบบโมเดลและรายงานความพยายามของบุคคลเดียวกัน เรากําหนดว่าเป็นโซลูชัน BI ส่วนบุคคล แม้ว่ารายงานจะสามารถแชร์กับผู้อื่นได้ โซลูชันดังกล่าวสามารถแสดงรายงานที่มีขอบเขตบทบาทหรือการประเมินความท้าทายทางธุรกิจได้แบบครั้งเดียว—ซึ่งมักจะอธิบายไว้ เป็นรายงาน เฉพาะงาน

ไฟล์เดียวประกอบด้วยรูปแบบข้อมูลและรายงานที่พัฒนาโดยบุคคลเดียวกัน

แยกไฟล์รายงาน

ซึ่งเหมาะสมที่จะแยกการพัฒนาแบบPower BI Desktopและรายงานเป็นไฟล์แยกต่างหากเมื่อ:

  • ผู้สร้างรูปแบบข้อมูลและผู้เขียนรายงานคนอื่น ๆ
  • เราเข้าใจดีว่าแบบโมเดลจะเป็นแหล่งข้อมูลของหลายรายงาน ในตอนนี้หรือในอนาคต

มีสามไฟล์ PBIX สูตรแรกประกอบด้วยเฉพาะแบบโมเดลเท่านั้น อีกสองรายงานประกอบด้วยรายงานเท่านั้น และเชื่อมต่อสดไปยังแบบโมเดลที่โฮสต์บริการของ Power BIเชื่อมต่อสด รายงานนั้นถูกพัฒนาโดยผู้คนที่แตกต่างกัน

ผู้สร้างรูปแบบข้อมูลยังคงสามารถใช้ประสบการณ์Power BI Desktopการเขียนรายงานเพื่อทดสอบและตรวจสอบการออกแบบแบบโมเดลของพวกเขา อย่างไรก็ตาม หลังจากเผยแพร่ไฟล์ไปยังรายงานแล้ว ในบริการของ Power BIควรลบรายงานออกจากพื้นที่รายงาน และผู้ใช้ต้องอย่าลืมลบรายงานทุกครั้งที่เผยแพร่และเขียนทับชุดข้อมูล

รักษาอินเทอร์เฟซแบบโมเดล

ในบางครั้ง การเปลี่ยนแปลงแบบอย่างหลีกเลี่ยงไม่ได้ ผู้จัดรูปแบบข้อมูลต้องดูแล ไม่ใช่ตัวแบ่งส่วนต่อประสานโมเดล ถ้ารายงานมีสาเหตุจากวิชวลรายงานหรือไทล์แดชบอร์ดที่เกี่ยวข้องจะถูกแบ่งออก วิชวลที่เสียหายจะปรากฏเป็นข้อผิดพลาดและอาจส่งผลให้ผู้สร้างรายงานและผู้บริโภคเกิดความยุ่งยาก และแย่ลง— พวกเขาสามารถลดความน่าเชื่อถือในข้อมูล

ดังนั้นให้จัดการการเปลี่ยนแปลงแบบอย่างคี่ถ้วน ถ้าเป็นไปได้ ให้หลีกเลี่ยงการเปลี่ยนแปลงต่อไปนี้:

  • การเปลี่ยนชื่อตาราง คอลัมน์ ลวจล.ก.ล.ต. หรือหน่วยวัด
  • การปรับเปลี่ยนชนิดข้อมูลของคอลัมน์
  • การปรับเปลี่ยนนิพจน์หน่วยวัดเพื่อให้ส่งกลับชนิดข้อมูลที่แตกต่างกัน
  • การย้ายหน่วยวัดไปยังตารางหลักอื่น เนื่องจากการย้ายหน่วยวัดสามารถแบ่งหน่วยวัดตามขอบเขตรายงานที่หน่วยวัดที่มีคุณสมบัติครบถ้วนด้วยชื่อตารางหลักได้ เราไม่แนะเริ่มให้คุณเขียนนิพจน์ DAX โดยใช้ชื่อหน่วยวัดที่มีคุณสมบัติครบถ้วน โปรดดู DAX: การอ้างอิงคอลัมน์และการวัดผล

การเพิ่มตาราง คอลัมน์ ลวจลหรือหน่วยวัดใหม่มีความปลอดภัย โดยมีข้อยกเว้นหนึ่งข้อ: อาจเป็นไปได้ว่าชื่อหน่วยวัดใหม่สามารถชนกับชื่อหน่วยวัดขอบเขตรายงานได้ เพื่อหลีกเลี่ยงการชน เราขอแนะนําให้ผู้สร้างรายงานใช้แบบแผนการตั้งชื่อเมื่อนิยามหน่วยวัดในรายงานของตน ซึ่งอักขระเหล่านี้สามารถใส่หน้าชื่อหน่วยวัดที่มีขีดล่างหรืออักขระอื่น ๆ

หากคุณต้องการแบ่งการเปลี่ยนแปลงโมเดลของคุณ เราขอแนะนวลให้คุณเลือกอย่างใดอย่างหนึ่ง:

ตัวเลือกทั้งสองช่วยให้คุณสามารถระบุรายงานและแดชบอร์ดที่เกี่ยวข้องต่าง ๆ ได้อย่างรวดเร็ว มุมมองสายข้อมูลอาจเป็นตัวเลือกที่ดีกว่าเพราะเป็นเรื่องง่ายที่จะเห็นผู้ติดต่อของสิ่งประดิษฐ์ที่เกี่ยวข้องแต่ละรายการ อันที่จริงแล้ว เป็นไฮเปอร์ลิงก์ที่เปิดข้อความอีเมลที่แก้ไขไปยังผู้ติดต่อ

เราขอแนะนองให้คุณติดต่อเจ้าของวัตถุที่เกี่ยวข้องแต่ละรายการเพื่อแจ้งให้พวกเขาทราบเกี่ยวกับการเปลี่ยนแปลงการลาออกตามแผนใดๆ ด้วยวิธีนี้ พวกเขาสามารถเตรียมพร้อมและพร้อมที่จะแก้ไขและเผยแพร่รายงานของตนอีกครั้ง ช่วยให้ช่วยลดเวลาหยุดการที่ไม่ได้และยุ่งยาก

ขั้นตอนถัดไป

สำหรับข้อมูลเพิ่มเติมที่เกี่ยวข้องกับบทความนี้ โปรดดูทรัพยากรต่อไปนี้: