پوشش جامع حوزههای آزمون
این مخزن تستهای تمرینی دقیقاً به گونهای ساختار یافته است که توزیع فنی سوالات در مصاحبههای سطح سازمانی DAX، مدلسازی دادهها و Power BI را بازتاب دهد.
مدلسازی دادهها (۲۰٪): تسلط بر پیادهسازی Star Schema در مقابل Snowflake Schema، مدیریت روابط فعال و غیرفعال، مدیریت خطرات Cross-filtering دوطرفه، نرمالسازی دادهها و بهینهسازی Denormalization برای موتورهای جدولی.
توابع DAX (۲۵٪): بررسی عمیق کانتکستهای ارزیابی (Filter Context و Row Context)، مکانیسمهای انتقال کانتکست و استفاده پیشرفته از توابعی مانند CALCULATE، FILTER، ALL، ALLEXCEPT، RELATED و RELATEDTABLE.
بهینهسازی عملکرد (۱۵٪): به حداکثر رساندن بهرهوری موتور VertiPaq، اطمینان از Query Folding در مراحل بالادستی، پیکربندی سیاستهای Incremental Refresh، تنظیم اتصال DirectQuery، تحلیل کش دادهها و ایندکسگذاری سیستمهای منبع.
طراحی گزارش (۱۰٪): تکنیکهای پیشرفته بصریسازی، چارچوبهای طراحی داشبورد سازمانی، بهینهسازی چیدمان گزارش، پیکربندی تعاملات غنی و پیادهسازی مسیرهای کاربردی Drill-Down.
تحلیل دادهها (۱۰٪): جریانهای کاری عملی برای اکتشاف دادهها، روتینهای پیچیده پاکسازی دادهها، تبدیل دادهها از منابع متعدد، استراتژیهای کارآمد تجمیع دادهها و بصریسازی استراتژیک.
اجزای Power BI (۵٪): مدیریت جامع اکوسیستم Power BI با تمرکز بر اجرای M-code در Power Query، ساخت مدلهای داده قدرتمند در Power Pivot و پیکربندی Power View، Power Maps و قابلیتهای زبان طبیعی Power Q&A.
مباحث پیشرفته (۵٪): معماری مدلهای ترکیبی (Composite Models) پیچیده، پیادهسازی Row-Level Security (RLS) پویا، ارزیابی استراتژیهای Dynamic Data Masking، استقرار ظرفیت Power BI Embedded و بررسی بصریهای سفارشی امن.
سوالات رفتاری (۱۰٪): مدیریت ذینفعان سازمانی، همکاری در تیمهای مهندسی، عیبیابی روشمند در محیط عملیاتی، ارتباطات فنی و حل خلاقانه مسائل در دنیای واقعی.
درباره این دوره
قبولی در مصاحبه برای نقشهای تحلیلگر داده، توسعهدهنده Power BI یا مهندس هوش تجاری، بسیار فراتر از مهارتهای کشیدن و رها کردن (Drag-and-Drop) است. تیمهای مهندسی داده مدرن به دنبال توسعهدهندگانی هستند که انتقال کانتکست، کانتکستهای ارزیابی و هزینه دقیق عملکرد هر تابع اسکالر یا جدولی را که مینویسند، درک کنند. من این بانک سوالات جامع را طراحی کردم تا آمادگی دقیق و سختگیرانهای را که برای عبور با اعتماد به نفس از این مراحل فنی دشوار لازم است، در اختیار شما قرار دهم.
با ۵۵۰ سوال تمرینی بسیار دقیق و دستاول، این دوره فراتر از تئوریهای استاندارد میرود. من معماهای واقعی مدلسازی دادهها، فیلترهای ارزیابی شکسته، گلوگاههای موتور پردازشی و آسیبپذیریهای امنیتی RLS را کالبدشکافی میکنم. هر سوال دارای یک تحلیل فنی جامع است که دقیقاً توضیح میدهد چرا گزینه درست موفق میشود و چرا گزینههای جایگزین در محیط عملیاتی شکست میخورند. چه در حال آماده شدن برای سناریوهای پیچیده طراحی شمای داده باشید و چه در حال بهینهسازی Query Folding برای مجموعههای داده عظیم، این منبع یک شبیهساز نهایی برای کمک به شماست تا در اولین تلاش، ارزیابی فنی خود را پاس کنید.
نمونهای از سوالات تمرینی
برای درک عمق و سبک توضیحات ارائه شده در این بانک سوالات، این سه نمونه سوال با کیفیت بالا را بررسی کنید.
سوال ۱: انتقال کانتکست ارزیابی در توابع تکرارکننده (Iteration Functions)
یک توسعهدهنده یک ستون محاسباتی در جدول 'Sales' ایجاد میکند تا مجموع فروش مشتری را با استفاده از عبارت زیر محاسبه کند: TotalSales = SUMX(Sales, CALCULATE(SUM(Sales[Amount]))). جدول 'Sales' شامل تراکنشهای متعددی برای هر مشتری است. رفتار دقیق این عبارت در هنگام رفرش دادهها چیست؟
الف) عبارت به درستی مجموع کل فروش را برای هر ردیف به صورت متوالی در کل جدول تجمیع میکند.
ب) عبارت فقط مبلغ فروش برای ردیف فعلی را محاسبه میکند و تابع CALCULATE را کاملاً زائد میکند.
ج) عبارت باعث ایجاد یک انتقال کانتکست (Context Transition) میشود و کانتکست ردیفِ تکرار را به یک کانتکست فیلتر تبدیل میکند، که منجر به محاسبه مجموع فروش مشتری برای کانتکست آن ردیف میشود.
د) موتور پردازشی خطای وابستگی چرخشی (Circular Dependency) ایجاد میکند زیرا ستون محاسباتی مستقیماً به جدول والد در داخل یک تابع تکرارکننده ارجاع میدهد.
ه) عبارت کامپایل نمیشود زیرا تابع SUM نمیتواند بدون یک عبارت فیلتر صریح در داخل بلوک تکرارکننده SUMX قرار گیرد.
و) عبارت با دور زدن مکانیسمهای کش پایگاه داده VertiPaq، باعث خطای سرریز حافظه (Memory Overflow) در زمان اجرا میشود.
پاسخ صحیح و توضیح:
پاسخ صحیح: ج
چرا درست است: تابع SUMX به عنوان یک تکرارکننده عمل میکند و یک کانتکست ردیف ایجاد میکند که ردیف به ردیف در جدول 'Sales' پیش میرود. وقتی CALCULATE یک عبارت را در یک کانتکست ردیف فعال قرار میدهد، به طور خودکار یک انتقال کانتکست (Context Transition) را آغاز میکند. این مکانیسم مقادیر منحصر به فرد تمام ستونها در ردیف فعلی را به یک کانتکست فیلتر محدودکننده تبدیل میکند. در نتیجه، SUM(Sales[Amount]) تحت این کانتکست فیلتر جدید ارزیابی شده و مقادیری را که با معیارهای فیلتر فعلی مطابقت دارند تجمیع میکند، به جای اینکه آن را به عنوان یک جستجوی ردیفی ساده در نظر بگیرد.
چرا گزینههای دیگر نادرست هستند:
گزینه الف نادرست است: چون انتقال کانتکست، محاسبه را بر اساس معیارهای هر ردیف فیلتر میکند، یک مجموع کلی بدون فیلتر برنمیگرداند.
گزینه ب نادرست است: CALCULATE رفتار محاسبه را کاملاً تغییر میدهد؛ هرگز در یک حلقه تکرار زائد نیست.
گزینه د نادرست است: وابستگیهای چرخشی تنها زمانی رخ میدهند که چندین ستون محاسباتی بدون ایندکس به محاسبات یکدیگر ارجاع دهند، نه در تکرارهای استاندارد ردیفی.
گزینه ه نادرست است: این یک نحو (Syntax) کاملاً معتبر در DAX است؛ قرار دادن تجمیعکنندهها در داخل تکرارکنندهها با استفاده از CALCULATE یک الگوی برنامهنویسی استاندارد است.
گزینه و نادرست است: اگرچه انتقال کانتکست میتواند سرعت جداول بسیار بزرگ را کاهش دهد، اما ذاتاً لایه کش را برای ایجاد سرریز حافظه نمیشکند یا دور نمیزند.
سوال ۲: اختلال در Query Folding در عملیات پیچیده Power Query
یک توسعهدهنده Power BI متوجه میشود گزارشی که از طریق حالت DirectQuery به یک پایگاه داده SQL Server متصل است، دچار تأخیر شدید شده است. پس از بررسی، متوجه میشود که Query Folding در Power Query مختل شده است. کدام عملیات به احتمال زیاد باعث این شکست در Folding شده است؟
الف) ادغام دو ستون از یک جدول پایگاه داده با استفاده از یک جداکننده فضای استاندارد.
ب) اعمال تبدیل حروف بزرگ (Uppercase) روی یک چیدمان ستون متنی موجود.
ج) تغییر نوع داده یک ستون ID از متن به فرمت عدد صحیح (Integer).
د) گروهبندی ردیفها بر اساس یک ستون بُعد خاص و محاسبه یک تجمیع شمارش (Count) ساده.
ه) ادغام یک جدول بومی SQL Server با یک فایل CSV محلی که حاوی تعدیلات هدف است.
و) فیلتر کردن رکوردهای خالی از یک ستون تاریخ اصلی با استفاده از یک فیلتر مقایسهای استاندارد.
پاسخ صحیح و توضیح:
پاسخ صحیح: ه
چرا درست است: Query Folding مستلزم آن است که موتور mashup در Power Query، مراحل تبدیل را مستقیماً به یک دستور زبان پرسوجوی بومی پایگاه داده (مانند دستور SQL SELECT) ترجمه کند. وقتی سعی میکنید یک جدول پایگاه داده رابطهای را با یک منبع داده محلی غیررابطهای مانند فایل CSV ادغام یا Join کنید، موتور mashup نمیتواند عملیات Join را به پایگاه داده SQL Server برگرداند. در این حالت، موتور باید کل جدول پایگاه داده را به صورت محلی در حافظه دانلود کند تا عملیات را تکمیل کند، که این امر زنجیره Folding را کاملاً میشکند.
چرا گزینههای دیگر نادرست هستند:
گزینه الف نادرست است: الحاق ستونها در یک منبع SQL به راحتی به دستورات بومی SUBSTRING یا CONCAT ترجمه میشود.
گزینه ب نادرست است: تغییرات حروف به طور مستقیم به تابع UPPER() در پایگاه داده SQL ترجمه میشود.
گزینه ج نادرست است: تبدیلهای نوع داده به طور تمیزی به عملگرهای SQL CAST یا CONVERT نگاشت میشوند.
گزینه د نادرست است: گروهبندی و تجمیعها به راحتی با استفاده از مسیرهای اجرای GROUP BY استاندارد پایگاه داده، Folding میشوند.
گزینه و نادرست است: فیلتر کردن ردیفهای ساده مستقیماً به یک شرط استاندارد در عبارت WHERE در SQL نگاشت میشود.
سوال ۳: فیلترینگ پویا در Row-Level Security (RLS) در شمای Snowflake
یک معماری هوش تجاری به Row-Level Security پویا بر اساس پروفایل ورود کاربر نیاز دارد. مدل از یک Snowflake Schema استفاده میکند: UserSecurity، بُعد Region را فیلتر میکند و سپس Region، جدول واقعیت (Fact) اصلی Sales را فیلتر میکند. توسعهدهنده تابع USERPRINCIPALNAME() را در نقش امنیتی پیادهسازی میکند. با این حال، کاربران گزارش میدهند که در طول تست، همچنان میتوانند تمام دادهها را در تمام مناطق ببینند. علت ریشهای چیست؟
الف) Row-Level Security پویا هنگام استفاده از تابع USERPRINCIPALNAME() در سرویس Power BI قابل ارزیابی نیست.
ب) روابط بین جداول بُعد در ساختار Snowflake با جهت فیلتر متقاطع تکطرفه (Single) پیکربندی شدهاند و مانع از رسیدن فیلتر امنیتی به جدول Fact میشوند.
ج) جدول Fact حاوی کلیدهای تکراری است که به طور خودکار فیلترهای امنیتی فعال را در هنگام استقرار لغو میکنند.
د) نقشهای امنیتی پویا مستلزم آن هستند که موتور پایگاه داده از حالت DirectQuery استفاده کند و در تنظیمات Import معمولی شکست میخورند.
ه) رشته فیلتر USERPRINCIPALNAME() به یک دستور ALL صریح نیاز دارد تا محدودیتهای بصری پیشفرض ردیف را پاک کند.
و) ساختارهای Snowflake برای هر گروه امنیتی مجزا که در فضای کاری تعریف شده است، به جداول داده جداگانه نیاز دارند.
پاسخ صحیح و توضیح:
پاسخ صحیح: ب
چرا درست است: فیلترهای امنیتی مستقیماً روی جدولی اعمال میشوند که قانون فیلتر DAX در آن تعریف شده است. برای اینکه آن فیلتر از طریق مدل به جداول دیگر منتشر شود (مانند حرکت از UserSecurity به Region و سپس به Sales)، روابط مدل داده باید اجازه دهند که فیلتر در آن جهت جریان یابد. در یک چیدمان استاندارد Snowflake، روابط به طور طبیعی از ابعاد به سمت جدول Fact جریان دارند. با این حال، اگر رابطه میانی بین UserSecurity و Region دارای جهت فیلتر متقاطع تکطرفهای باشد که به جهت اشتباه اشاره میکند، فیلتر RLS مسدود شده و هرگز برای محدود کردن دادههای Sales به پایین منتشر نمیشود.
چرا گزینههای دیگر نادرست هستند:
گزینه الف نادرست است: USERPRINCIPALNAME() تابع استاندارد صنعت برای دریافت ورودهای فعال کاربران در محیطهای شرکتی است.
گزینه ج نادرست است: کلیدهای تکراری یا پیچیدگیهای Many-to-Many ممکن است محاسبات را تغییر دهند، اما نمیتوانند ذاتاً یک مانع صریح RLS را غیرفعال کنند.
گزینه د نادرست است: RLS در هر دو حالت ذخیرهسازی داده Import و DirectQuery به طور کامل عمل میکند.
گزینه ه نادرست است: افزودن یک دستور ALL دقیقاً همان فیلترهایی را که سعی در اعمال آنها دارید حذف میکند و مشکل را بدتر میکند.
گزینه و نادرست است: ایجاد جداول جداگانه هدف RLS پویا را از بین میبرد؛ یک شمای ستارهای یا Snowflake واحد، قوانین امنیتی را در صورت نگاشت صحیح روابط، به صورت پویا مدیریت میکند.
چه انتظاراتی داشته باشید
به آزمونهای سوالات مصاحبه خوش آمدید تا به شما در آماده شدن برای تستهای تمرینی سوالات مصاحبه DAX کمک کنیم.
میتوانید هر تعداد بار که میخواهید در آزمونها شرکت کنید.
این یک بانک سوالات جامع و دستاول است.
در صورت داشتن سوال، از پشتیبانی مدرسان بهرهمند میشوید.
هر سوال دارای یک توضیح دقیق است.
با اپلیکیشن Udemy کاملاً با موبایل سازگار است.
امیدوارم تا الان متقاعد شده باشید! و سوالات بسیار بیشتری در داخل دوره وجود دارد.
Interview Questions Tests
مربی در Udemy
نمایش نظرات