پوشش دقیق حوزههای آزمون
این مخزن جامع تستهای تمرینی مستقیماً با مهارتهای فنی مورد نیاز در تیمهای داده مدرن مطابقت دارد. سوالات در ستونهای ارزیابی اصلی زیر توزیع شدهاند:
مبانی SQL (۲۰٪): سینتکس اصلی SQL، انتخاب دقیق انواع دادهها، محدودیتهای جدول (Primary, Foreign, Unique, Check) و ساختارهای بنیادی کوئری.
بازیابی و دستکاری دادهها (۲۵٪): کاربرد پیشرفته عبارات SELECT، فیلترهای شرطی از طریق WHERE و HAVING، پروتکلهای مرتبسازی، تجمیعهای پیچیده با GROUP BY و اسمبل کردن دادههای چندجدولی با استفاده از انواع JOIN.
مفاهیم پیشرفته SQL (۲۰٪): زیرکوئریهای متقابل و تودرتو، عبارتهای جدولی مشترک (CTEs)، توابع پنجرهای (Window Functions)، مدیریت Viewها، سطوح ایزولاسیون تراکنش ACID، مکانیسمهای ایندکسگذاری و تئوری نرمالسازی پایگاه داده تا سطح BCNF.
بهینهسازی کوئری و کارایی (۱۵٪): تفسیر طرحهای اجرای کوئری (Execution Plans)، شناسایی گلوگاهها، رفع تفاوتهای Index Scan در مقابل Index Seek، تکنیکهای بهینهسازی و تنظیم کارایی در سطح شماتیک.
مدلسازی و طراحی داده (۱۰٪): اصول طراحی پاک پایگاه داده، مدلسازی دادههای عملیاتی، تبدیل نمودارهای پیچیده رابطه موجودیت (ERDs) به شماتیکهای فیزیکی و حفظ یکپارچگی دادهها.
تحلیل دادهها و هوش تجاری (۵٪): محاسبات تحلیلی پیشرفته، تغییر شکل دادهها برای موتورهای هوش تجاری (BI)، ایجاد لایههای تحلیلی Stage و بهینهسازی کوئریها برای ابزارهای گزارشگیری.
SQL تخصصی دامنه (۵٪): الگوهای کوئری هدفمند برای محیطهای عملیاتی خاص، شامل گویشهای تخصصی SQL برای خط لولههای علوم داده، حسابرسی تحلیلی مالی و معماریهای Big Data.
درباره این دوره
موفق شدن در یک مصاحبه فنی پایگاه داده بسیار فراتر از نوشتن دستورات ساده SELECT است. محیطهای دیتابیس در مقیاس تولید (Production)، کوئریهایی را میطلبند که نه تنها دقیق، بلکه بسیار بهینه، مقاوم در برابر بارهای ترافیکی بالا و از نظر ساختاری صحیح باشند. من این منبع تمرینی تخصصی را طراحی کردم تا شکاف بین حفظ کردن سینتکسهای پایه و سناریوهای پیچیده و خاص (Edge-case) را که مهندسان ارشد داده و لیدهای فنی برای ارزیابی کاندیداها استفاده میکنند، پر کنم.
این دوره با دارا بودن ۵۵۰ سوال اختصاصی و با کیفیت، بر تست کردن منطق تحلیلی و شهود شما در اجرای کوئریها تمرکز دارد. من شماتیکهای واقعی جداول، خروجیهای اشتباه کوئریها، مشکلات افت کارایی ایندکس و معماهای طراحی ساختاری را کالبدشکافی میکنم. هر مسئله همراه با یک تحلیل فنی کامل است که رفتار موتور پایگاه داده، دلیل موفقیت کوئری صحیح و دلیل دقیق شکست یا افت کارایی گزینههای جایگزین را توضیح میدهد. چه برای نقش تحلیلگر داده آماده میشوید، چه برای مراحل فنی مهندسی داده یا یک ارزیابی سطح بالای SQL، این بانک سوالات تمرینهای واقعی لازم را برای قبولی با اعتماد به نفس در اولین تلاش فراهم میکند.
نمونه سوالات تمرینی
برای ارزیابی عمق ساختاری و توضیحات ارائه شده در این بانک سوالات، این سه سناریوی نمونه مصاحبه را بررسی کنید:
سوال ۱: تجمیع ارزیابی و رفتار توابع پنجرهای (Window Functions)
یک جدول دیتابیس فروش به نام orders شامل ستونهای order_id، customer_id، order_date و amount را در نظر بگیرید. یک تحلیلگر داده نیاز دارد مجموع هزینههای تجمعی هر مشتری را در طول زمان، مرتب شده بر اساس تاریخ محاسبه کند. کدام کوئری SQL این محاسبه را به درستی انجام میدهد بدون اینکه ردیفهای تراکنشی تکتک را حذف یا ادغام کند؟
A) SELECT customer_id, order_date, SUM(amount) OVER (PARTITION BY customer_id ORDER BY order_date) FROM orders;
B) SELECT customer_id, order_date, SUM(amount) FROM orders GROUP BY customer_id, order_date;
C) SELECT customer_id, order_date, SUM(amount) OVER (ORDER BY order_date) FROM orders;
D) SELECT customer_id, order_date, SUM(amount) OVER (PARTITION BY order_date) FROM orders;
E) SELECT customer_id, order_date, SUM(amount) FROM orders HAVING SUM(amount) is not null;
F) SELECT customer_id, order_date, SUM(amount) OVER (PARTITION BY customer_id) FROM orders GROUP BY customer_id;
پاسخ صحیح و توضیح:
پاسخ صحیح: A
دلیل صحت: توابع Window محاسبات را روی مجموعهای از ردیفهای جدول که با ردیف فعلی مرتبط هستند انجام میدهند. با استفاده از SUM(amount) OVER (PARTITION BY customer_id ORDER BY order_date)، موتور دیتابیس دادهها را بر اساس هر مشتری مجزا بخشبندی کرده و بند ORDER BY در داخل پنجره، یک بازه جاری ایجاد میکند که مبالغ سفارشات را تا تاریخ ردیف فعلی جمع میزند بدون اینکه تعداد ردیفهای خروجی نهایی را کاهش دهد.
دلیل نادرست بودن سایر گزینهها:
گزینه B نادرست است: استفاده از GROUP BY استاندارد، رکوردهای تراکنشهای تکتک را در جفتهای مشتری-تاریخ ادغام میکند که باعث از بین رفتن جزئیات هر ردیف شده و مجموع روزانه را محاسبه میکند نه مجموع تجمعی جاری.
گزینه C نادرست است: حذف بند PARTITION BY customer_id باعث میشود مجموع جاری در کل جدول به صورت زمانی محاسبه شود و دادههای مشتریان مختلف با هم مخلوط شوند.
گزینه D نادرست است: بخشبندی بر اساس order_date، مجموع هر روز را برای تمام مشتریان محاسبه میکند به جای اینکه چرخه عمر هر مشتری را به صورت مجزا بررسی کند.
گزینه E نادرست است: این گزینه فاقد هر دو منطق پنجرهای و اعلانهای گروه تجمیعی معتبر است و منجر به خطای سینتکس در موتورهای دیتابیس رابطهای میشود.
گزینه F نادرست است: ترکیب GROUP BY با یک تابع پنجرهای بدون ساختار، خطاهای معنایی ایجاد میکند زیرا پردازش پنجرهای نیاز دارد ردیفهای زیرین دستنخورده باقی بمانند که با تجمیع استاندارد ردیفها در تضاد است.
سوال ۲: بهینهسازی و تحلیل طرح اجرا برای گزارههای Non-SARGable
یک کوئری اپلیکیشن که روی جدولی در محیط Production با میلیونها رکورد اجرا میشود، بسیار کند است. کوئری شامل بند WHERE YEAR(join_date) = 2025 است. ستون join_date دارای یک ایندکس B-Tree است. چرا موتور دیتابیس به جای Index Seek، از Full Table Scan یا Index Scan کند استفاده میکند؟
A) ساختار ایندکس B-Tree نمیتواند تاریخها را پردازش کند مگر اینکه صراحتاً به متغیرهای رشتهای متن تبدیل شوند.
B) اعمال یک تابع اسکالر بر روی یک ستون ایندکس شده، عبارت را غیر SARGable میکند و موتور را مجبور میکند تابع را برای هر ردیف ارزیابی کند.
C) موتورهای دیتابیس رابطهای هرگاه سال ۲۰۲۰ سپری شود، به طور خودکار جستجوی ایندکس را غیرفعال میکنند.
D) تابع ()YEAR دادههای تخصیص ایندکس زیرین را از فرمتهای عددی به حالتهای اعشاری پیچیده تغییر میدهد.
E) ایندکسها فقط عملیات مرتبسازی از طریق بندهای ORDER BY را تسریع میکنند و در هنگام فیلتر کردن ردیفها در WHERE کاملاً نادیده گرفته میشوند.
F) بهینهساز کوئری قبل از خواندن برگهای ایندکس حاوی فیلدهای تاریخ، به یک راهنمای قفل دیتابیس (Lock Hint) صریح نیاز دارد.
پاسخ صحیح و توضیح:
پاسخ صحیح: B
دلیل صحت: یک گزاره زمانی SARGable (Search Argumentable) است که موتور کوئری بتواند مستقیماً از ایندکس برای سرعت بخشیدن به حلقه اجرا استفاده کند. قرار دادن یک ستون ایندکس شده در داخل تابعی مانند YEAR(join_date) مانع از انجام Index Seek بهینه توسط بهینهساز میشود، زیرا موتور باید خروجی تابع را برای تک تک رکوردهای جدول محاسبه کند تا ببیند آیا با مقدار ۲۰۲۵ مطابقت دارد یا خیر. بازنویسی این عبارت به WHERE join_date >= '2025-01-01' AND join_date < '2026-01-01' قابلیت Seek را بازمیگرداند.
دلیل نادرست بودن سایر گزینهها:
گزینه A نادرست است: موتورهای رابطهای انواع دادههای تاریخ را بدون نیاز به تبدیل متنی، به صورت بهینه ذخیره و ایندکس میکنند.
گزینه C نادرست است: موتورهای دیتابیس هیچ محدودیت دلخواه و وابسته به تاریخ بر اساس سالهای تقویمی خاص ندارند.
گزینه D نادرست است: پردازش اسکالر بر زمان اجرا تأثیر میگذارد اما فرمت ذخیرهسازی فیزیکی ورودیهای ایندکس را تغییر نمیدهد.
گزینه E نادرست است: ایندکسها اساساً برای فیلتر سریع در بندهای WHERE و همچنین Joinها بهینه شدهاند، نه فقط برای مرتبسازی خروجی.
گزینه F نادرست است: بهینهسازها ایندکسها را با استفاده از تحلیل ساختاری استاندارد ارزیابی میکنند و نیازی به تعریف دستی قفل تراکنش توسط کاربر ندارند.
سوال ۳: رفتار محدودیت کلید خارجی و یکپارچگی ارجاعی
یک طراح دیتابیس یک رابطه کلید خارجی بین جدول والد (departments) و جدول فرزند (employees) پیکربندی میکند. این محدودیت با قانون ON DELETE CASCADE ساخته شده است. اگر یک مدیر، رکورد یک دپارتمان عملیاتی را از جدول والد حذف کند، چه اتفاقی در وضعیت دیتابیس فرزند رخ میدهد؟
A) موتور دیتابیس اجرای دستور را متوقف کرده و یک خطای شدید اعتبارسنجی محدودیت ارجاعی صادر میکند.
B) شناسههای دپارتمان مربوطه در جدول فرزند به null تغییر میکنند در حالی که ردیفهای کارمندان دستنخورده باقی میمانند.
C) تمام رکوردهای کارمند مرتبط با آن دپارتمان حذف شده، به طور خودکار از جدول فرزند حذف میشوند.
D) دستور حذف با موفقیت اجرا میشود، اما ایندکس کلید خارجی آفلاین شده و نیاز به بازسازی دستی شماتیک دارد.
E) ردیف والد حذف شده و ردیفهای فرزند به طور خودکار به یک آرشیو بکآپ سیستم آفلاین صادر میشوند.
F) کل سیستم به حالت read-only تغییر میکند تا زمانی که مدیر به طور دستی رکوردهای متأثر را مجدداً لینک کند.
پاسخ صحیح و توضیح:
پاسخ صحیح: C
دلیل صحت: قوانین یکپارچگی ارجاعی تعیین میکنند که موتور چگونه با روابط وابسته برخورد کند. عبارت ON DELETE CASCADE صراحتاً به مدیر دیتابیس میگوید که اگر یک رکورد اصلی در جدول والد حذف شد، تمام ردیفهای وابسته در جدول فرزند مرتبط که حاوی آن کلید خارجی هستند، باید به طور خودکار در همان حلقه تراکنش حذف شوند تا از ایجاد رکوردهای یتیم (Orphan) جلوگیری شود.
دلیل نادرست بودن سایر گزینهها:
گزینه A نادرست است: متوقف کردن اجرا، رفتار مشخص پیکربندیهای ON DELETE RESTRICT یا ON DELETE NO ACTION است.
گزینه B نادرست است: قرار دادن مقادیر در حالت null نتیجه استفاده از پرچم ساختاری ON DELETE SET NULL است.
گزینه D نادرست است: محدودیتهای رابطهای، دید و وجود رکوردهای عملیاتی را به طور خودکار مدیریت میکنند؛ آنها داراییهای ایندکس ذخیرهسازی فیزیکی را خراب یا غیرفعال نمیکنند.
گزینه E نادرست است: موتورهای رابطهای روتینهای آرشیو داده را از طریق قوانین سینتکس آبشاری کلید خارجی استاندارد مدیریت نمیکنند.
گزینه F نادرست است: تغییرات مستقیماً روی جداول تراکنش متأثر اعمال میشوند و کل نمونه (Instance) دیتابیس را به حالت قفل مطلق یا read-only نمیبرند.
آنچه در انتظار شماست
به تستهای سوالات مصاحبه خوش آمدید تا شما را برای آزمون تمرینی سوالات مصاحبه SQL آماده کنیم.
میتوانید آزمونها را هر چند بار که بخواهید تکرار کنید.
این یک بانک سوالات اختصاصی و بسیار گسترده است.
در صورت داشتن سوال، از پشتیبانی مدرسان بهرهمند میشوید.
هر سوال دارای یک توضیح دقیق است.
سازگار با موبایل از طریق اپلیکیشن Udemy.
امیدواریم تا الان متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد.
Interview Questions Tests
مربی در Udemy
نمایش نظرات