top 24 data modeling interview questions with detailed answers
Список найбільш часто задаваних питань моделювання даних інтерв’ю та відповідей, які допоможуть вам підготуватися до майбутнього співбесіди:
Тут я поділюсь деякими запитаннями для інтерв’ю із моделюванням даних та детальними відповідями, заснованими на моєму власному досвіді під час взаємодії в кількох відомих ІТ-МНК.
Нижче запитання-відповіді можуть бути вам у великій допомозі, якщо ви отримаєте можливість поспілкуватися чи взяти співбесіду з моделювання даних.
Найчастіші запитання щодо моделювання даних Інтерв’ю
Давайте розпочнемо!
Q # 1) Що ви розумієте під моделюванням даних?
Відповідь: Моделювання даних - це схематичне зображення, що показує, як сутності пов’язані між собою. Це початковий крок до проектування бази даних. Спочатку ми створюємо концептуальну модель, потім логічну модель і, нарешті, переходимо до фізичної моделі.
Як правило, моделі даних створюються на етапі аналізу та проектування життєвого циклу розробки програмного забезпечення.
Q # 2) Поясніть своє розуміння різних моделей даних?
Відповідь: Існує три типи моделей даних - концептуальна, логічна та фізична. Рівень складності та деталізації зростає від концептуальної до логічної до фізичної моделі даних.
Концептуальна модель показує дуже базовий високий рівень проектування, тоді як фізична модель даних показує дуже детальне уявлення про дизайн.
- Концептуальна модель буде просто зображувати імена сутностей та відносини сутності. На рисунку 1, показаному в подальшій частині цієї статті, зображена концептуальна модель.
- Логічна модель буде відображати імена сутностей, відносини сутності, атрибути, первинні ключі та зовнішні ключі в кожній сутності. Рисунок 2, показаний у питанні № 4 у цій статті, зображує логічну модель.
- Фізична модель даних відображатимуться первинні ключі, зовнішні ключі, назви таблиць, назви стовпців та типи даних стовпців. Цей погляд насправді пояснює, як модель буде реально впроваджена в базу даних.
Q # 3) Пролити світло на ваш досвід моделювання даних стосовно проектів, над якими ви працювали до сьогодні?
Примітка: Це було найперше запитання в одному з моїх інтерв’ю з моделювання даних. Отже, перед тим, як перейти до обговорення інтерв’ю, ви повинні мати чітке уявлення про те, як моделювання даних вписується в завдання, над якими ви працювали.
Відповідь: Я працював над проектом для медичної компанії, де ми маємо вбудовані інтерфейси Обчислення що трансформує та обробляє дані, отримані з бази даних Facets, і розсилає корисну інформацію постачальникам.
Примітка: Грані - це наскрізне рішення для управління всією інформацією для галузі охорони здоров’я. База даних аспектів у моєму проекті була створена за допомогою SQL Server 2012.
У нас були різні сутності, пов’язані між собою. Ці організації були абонентом, членом, постачальником медичних послуг, позовом, рахунком, реєстрацією, групою, правом на участь, планом / продуктом, комісією, капітацією тощо.
Нижче представлена концептуальна модель даних, яка показує, як проект виглядав на високому рівні
Фігура 1:
Кожна з сутностей даних має свої атрибути даних. Наприклад, атрибутом даних постачальника буде ідентифікаційний номер постачальника, мало атрибутів даних членства буде ідентифікатором абонента, ідентифікатором члена, один із атрибутів даних претензії буде вимагати ідентифікатор, кожен медичний продукт або план матиме унікальний ідентифікатор продукту та так далі.
Q # 4) Які різні схеми проектування в моделюванні даних? Поясніть ізприклад?
Відповідь: У моделюванні даних існує два різні типи схем
- Розклад зірок
- Схема сніжинки
Тепер я пояснюватиму кожну з цих схем по черзі.
Найпростіша зі схем - це зіркова схема, де ми маємо таблицю фактів у центрі, яка посилається на кілька таблиць розмірів навколо неї. Усі таблиці розмірностей пов'язані з таблицею фактів. Первинний ключ у всіх таблицях вимірів діє як зовнішній ключ у таблиці фактів.
Схема ІС (див. малюнок 2) цієї схеми нагадує форму зірки, і саме тому ця схема називається схемою зірки.
Малюнок 2:
Схема зірок досить проста, гнучка і вона знаходиться в ненормованому вигляді.
У схемі сніжинки рівень нормалізації зростає. Таблиця фактів тут залишається такою ж, як у схемі зірок. Однак таблиці розмірностей нормалізовані. Завдяки декільком шарам таблиць розмірів, вона виглядає як сніжинка, і тому її називають схемою сніжинки.
що робить бета-тестер
Малюнок 3:
Q # 5) Яку схему ви використовували у своєму проекті та чому?
Q # 6) Яка схема є кращою - зірка чи сніжинка?
Відповідь: (Об’єднано для запитань №5 та 6): Вибір схеми завжди залежить від вимог проекту та сценаріїв.
Оскільки схема зірок знаходиться в ненормованій формі, вам потрібно менше об’єднань для запиту. Запит простий і працює швидше в зірковій схемі. Переходячи до схеми сніжинки, оскільки вона знаходиться в нормалізованому вигляді, для неї буде потрібно кілька об’єднань порівняно зі схемою зірки, запит буде складним, а виконання буде повільнішим, ніж схема зірки.
Ще однією суттєвою відмінністю між цими двома схемами є те, що схема сніжинки не містить надлишкових даних, і тому її легко підтримувати. Навпаки, схема зірок має високий рівень надмірності, і тому її важко підтримувати.
Зараз, який вибрати для свого проекту? Якщо метою вашого проекту є більше аналізу розмірностей, вам слід скористатися схемою сніжинки. Наприклад, якщо вам потрібно це з’ясувати 'Скільки передплатників прив'язані до певного тарифного плану, який діє зараз?' - йди з моделлю сніжинки.
Якщо метою вашого проекту є більше аналізу метрик, вам слід використати схему зірок. Наприклад, якщо вам потрібно це з’ясувати 'Яка сума претензії виплачується конкретному абоненту?' - йти зі зірковою схемою.
У моєму проекті ми використовували схему сніжинок, оскільки нам доводилося проводити аналіз за кількома вимірами та створювати зведені звіти для бізнесу. Ще однією причиною використання схеми сніжинки було те, що це менше споживання пам'яті.
Q # 7) Що ви розумієте під вимірами та ознаками?
Відповідь: Розміри представляють якісні дані. Наприклад, план, виріб, клас - це всі розміри.
Таблиця розмірів містить описові або текстові атрибути. Наприклад, категорія товару та назва товару є атрибутами розміру товару.
Q # 8) Що таке таблиця фактів і фактів?
Відповідь: Факти представляють кількісні дані.
Наприклад, чиста сума заборгованості є фактом. Таблиця фактів містить числові дані та зовнішні ключі з відповідних мірних таблиць. Приклад таблиці фактів можна побачити на малюнку 2, показаному вище.
Q # 9) Які існують різні типи розмірів? Поясніть кожен із них детально на прикладі?
Відповідь: Як правило, існує п’ять типів розмірів.
а) Відповідні розміри : Вимір, який використовується як частина різних областей, називається конформним виміром. Він може використовуватися з різними таблицями фактів в одній базі даних або на численних мартах даних / складах.
Наприклад, якщо розмір абонента пов'язаний з двома таблицями фактів - виставлення рахунків та претензій, тоді розмір абонента буде розглядатися як відповідний розмір.
б) Небажаний вимір : Це таблиця розмірів, що складається з атрибутів, які не мають місця в таблиці фактів або в будь-якій з поточних таблиць розмірів. Загалом , це такі властивості, як прапори або індикатори.
Наприклад, це може бути прапор прийнятності члена, встановлений як «Y» або «N», або будь-який інший показник, встановлений як true / false, будь-які конкретні коментарі тощо. Якщо ми зберігаємо всі такі атрибути показника в таблиці фактів, то його розмір збільшується. Тому , ми поєднуємо всі такі атрибути і поміщаємо в єдину таблицю вимірів, яка називається непотрібною розмірністю, що має унікальні ідентифікатори небажаної інформації, з можливою комбінацією всіх значень показника.
в) Рольовий вимір : Це розміри, які використовуються для багатьох цілей в одній базі даних.
Наприклад, розмір дати може використовуватися для “Дата позову”, “Дата виставлення рахунку” або “Дата плану терміну”. Тому , такий вимір буде називатися Рольовим виміром. Первинний ключ вимірювання Date буде пов'язаний з кількома зовнішніми ключами в таблиці фактів.
d) Повільно змінюється розмір (SCD): Вони є найбільш важливими серед усіх вимірів. Це розміри, де значення атрибутів змінюються з часом. Нижче наводяться різні типи SCD
- Тип-0: Це ті розміри, де значення атрибута залишається незмінним з часом. Наприклад, DOB абонента - це SCD типу 0, оскільки він завжди буде незмінним незалежно від часу.
- Тип-1: Це розміри, де попереднє значення атрибута замінено поточним значенням. У вимірі Тип-1 не ведеться жодна історія. Наприклад, Адреса абонента (де компанія вимагає збереження єдиної поточної адреси абонента) може бути виміром типу 1.
- Тип-2: Це ті виміри, де зберігається необмежена історія. Наприклад, Адреса абонента (де компанія вимагає вести облік усіх попередніх адрес абонента). У цьому випадку в таблицю буде вставлено кілька рядків для абонента з його різними адресами. Будуть деякі стовпці, які вказуватимуть поточну адресу. Наприклад, «Дата початку» та «Дата закінчення». Рядок, де значення «Дата завершення» буде порожнім, міститиме поточну адресу абонента, а всі інші рядки матимуть попередні адреси абонента.
- Тип 3: Це ті розміри, де зберігається обмежена історія. І ми використовуємо додатковий стовпець для ведення історії. Наприклад, Адреса абонента (де компанія вимагає вести облік поточної та лише однієї попередньої адреси). У цьому випадку ми можемо розчинити стовпець „адреса” у двох різних стовпцях - „поточна адреса” та „попередня адреса”. Отже, замість кількох рядків ми матимемо лише один рядок, що відображає поточну, а також попередню адресу абонента.
- Тип 4: У цьому виді вимірів історичні дані зберігаються в окремій таблиці. Основна таблиця розмірів містить лише поточні дані. Наприклад, основна таблиця розмірів матиме лише один рядок на кожного абонента, що має поточну адресу. Усі інші попередні адреси абонента зберігатимуться в окремій таблиці історії. Цей тип розмірів навряд чи коли-небудь використовується.
д) Вироджений вимір: Вироджений вимір - це вимір, який не є фактом, але представлений у таблиці фактів як первинний ключ. Він не має власної таблиці розмірів. Ми також можемо назвати його єдиною таблицею вимірів атрибутів.
Але , замість того, щоб зберігати його окремо в таблиці вимірів і вводити додаткове з'єднання, ми поміщаємо цей атрибут у таблицю фактів безпосередньо як ключ. Оскільки вона не має власної таблиці вимірів, вона ніколи не може діяти як зовнішній ключ у таблиці фактів.
Q # 10) Висловіть свою ідею щодо безфактум факту? І чому ми цим користуємось?
Відповідь: Фактична таблиця фактів - це таблиця фактів, яка не містить у собі жодного показника факту. У ньому є лише клавіші розмірності.
Іноді у бізнесі можуть виникнути певні ситуації, коли вам потрібно мати фактичну таблицю фактів.
Наприклад, припустимо, ви підтримуєте систему обліку відвідуваності працівників, у вас може бути безфактумна таблиця фактів, що має три ключі.
| Ідентифікатор працівника |
| Ідентифікатор_відділу |
| Ідентифікатор часу |
Ви бачите, що наведена вище таблиця не містить жодних мір. Тепер, якщо ви хочете відповісти на запитання нижче, ви можете легко зробити, використовуючи наведену вище єдину безфактумну таблицю фактів, а не дві окремі таблиці фактів:
віртуальна реальність, сумісна з xbox one
'Скільки співробітників певного відділу були присутніми в той чи інший день?'
Отже, безфактумна таблиця фактів пропонує гнучкість у дизайні.
Q # 11) Розрізнити OLTP та OLAP?
Відповідь: OLTP розшифровується як Інтернет-система обробки транзакцій & OLAP розшифровується як Інтернет-аналітична система обробки . OLTP підтримує дані про транзакції бізнесу та в цілому дуже нормалізується. Навпаки, OLAP призначений для аналізу та звітності, і він знаходиться в ненормованій формі.
Ця різниця між OLAP та OLTP також дає вам шлях до вибору дизайну схеми. Якщо ваша система OLTP, вам слід вибрати схему зіркової схеми, а якщо ваша система OLAP, вам слід вибрати схему сніжинки.
Q # 12) Що ви розумієте під data mart?
Відповідь: Маркери даних здебільшого призначені для одиночної галузі бізнесу. Вони призначені для окремих відділів.
Наприклад, Раніше я працював у медичній страховій компанії, в якій працювали різні відділи, такі як фінанси, звітність, продажі тощо.
У нас був сховище даних, в якому зберігалася інформація, що стосується всіх цих підрозділів, і тоді у нас є декілька даних, побудованих поверх цього сховища даних. Ці DataMart були специфічними для кожного відділу. Простими словами можна сказати, що DataMart - це підмножина сховища даних.
Q # 13) Які існують різні типи заходів?
Відповідь: У нас є три типи заходів, а саме
- Неадитивні заходи
- Напівадитивні заходи
- Адитивні заходи
Неадитивні заходи - це ті, до яких не можна застосовувати жодну функцію агрегування. Наприклад, коефіцієнт або стовпець у відсотках; прапор чи стовпець індикатора, наявний у таблиці фактично, що містить такі значення, як Y / N тощо, є неадитивної мірою.
Напівадитивні заходи - це ті, над якими можна застосувати деякі (але не всі) функції агрегування. Наприклад, ставка комісії або залишок на рахунку.
Адитивні міри - це ті, над якими можна застосувати всі функції агрегації. Наприклад, одиниць придбано.
Q # 14) Що таке сурогатний ключ? Чим він відрізняється від первинного ключа?
Відповідь: Сурогатний ключ - це унікальний ідентифікатор або згенерований системою ключ порядкового номера, який може діяти як первинний ключ. Це може бути стовпець або комбінація стовпців. На відміну від первинного ключа, він не береться з існуючих полів даних програми.
Запитання №15) Чи правда, що всі бази даних мають бути у 3NF?
Відповідь: База даних не має бути в 3NF. Однак , якщо ваша мета - легке обслуговування даних, менша надмірність та ефективний доступ, тоді вам слід скористатися денормалізованою базою даних.
Q # 16) Ви коли-небудь стикалися зі сценарієм рекурсивних відносин? Якщо так, то як ви це впорались?
Відповідь: Рекурсивні відносини виникають у тому випадку, коли сутність пов'язана із собою. Так, я стикався з таким сценарієм.
Говорячи про сферу охорони здоров’я, існує ймовірність того, що медичний працівник (скажімо, лікар) є пацієнтом для будь-якого іншого медичного працівника. Тому що , якщо лікар сам захворіє і потребує хірургічного втручання, йому доведеться відвідати іншого лікаря для отримання хірургічного лікування.
Тому , у цьому випадку суб'єкт господарювання - постачальник медичних послуг пов'язаний сам з собою. Іноземний ключ до номера медичного страхування повинен бути вказаний в обліку кожного члена (пацієнта).
Q # 17) Перелічіть кілька типових помилок, які траплялися під час моделювання даних?
Відповідь: Кілька найпоширеніших помилок, що виникають під час моделювання даних:
- Побудова масивних моделей даних : Великі моделі даних, як правило, мають більше помилок у дизайні. Спробуйте обмежити модель даних не більш як 200 таблицями.
- Відсутність цілі : Якщо ви не знаєте, для чого призначене ваше бізнес-рішення, ви можете придумати неправильну модель даних. Тож чіткість комерційної мети дуже важлива для того, щоб розробити правильну модель даних.
- Недоречне використання сурогатних ключів : Сурогатний ключ не слід використовувати без потреби. Використовуйте сурогатний ключ лише тоді, коли природний ключ не може служити призначенню первинного ключа.
- Непотрібна денормалізація : Не денормалізуйте, поки у вас немає вагомих і чітких ділових причин для цього, оскільки денормалізація створює зайві дані, які важко підтримувати.
Q # 18) Яка кількість дочірніх таблиць, які можна створити з однієї батьківської таблиці?
Відповідь: Кількість дочірніх таблиць, які можна створити з єдиної батьківської таблиці, дорівнює кількості полів / стовпців у батьківській таблиці, які не є ключами.
c ++ функція сортування міхурів
Q # 19) Інформація про здоров'я працівника приховується від його роботодавця постачальником медичних послуг. Який рівень приховування даних це? Концептуальна, фізична чи зовнішня?
Відповідь: Це сценарій зовнішнього рівня приховування даних.
Q # 20) Яка форма таблиці фактів і таблиці розмірностей?
Відповідь: Як правило, таблиця фактів знаходиться у нормалізованій формі, а таблиця розмірностей - у ненормованій формі.
Запитання №21) Які деталі вам потрібні, щоб розробити концептуальну модель у проекті сфери охорони здоров’я?
Відповідь: Для проекту охорони здоров’я, наведених нижче деталей буде достатньо для вимоги до розробки базової концептуальної моделі
- Різні категорії планів та продуктів охорони здоров’я.
- Тип підписки (групова або індивідуальна).
- Набір медичних працівників.
- Огляд претензій та виставлення рахунків.
Q # 22) Хитрий: якщо до стовпця застосовано унікальне обмеження, то чи видасть воно помилку, якщо ви спробуєте вставити в нього два нулі?
Відповідь: Ні, в цьому випадку це не призведе до помилки, оскільки нульове значення нерівне іншому нульовому значенню. Отже, більше одного нуля буде вставлено в стовпець без помилок.
Q # 23) Чи можете ви навести приклад сутності підтипу та супертипу?
Відповідь: Так, припустимо, у нас є ці різні сутності - транспортний засіб, автомобіль, велосипед, економ-автомобіль, сімейний автомобіль, спортивний автомобіль.
Тут транспортний засіб є суттю супер-типу. Автомобіль та велосипед є його субтипами. Крім того, економічні автомобілі, спортивні та сімейні автомобілі є субтипами цього супертипу.
Суб'єкт супер-типу - це той, що знаходиться на вищому рівні. Субтипи - це об’єднання, які згруповані на основі певних характеристик. Наприклад, всі велосипеди - двоколісні, а всі машини - чотириколісні. І оскільки обидва є транспортними засобами, то їх суперотип є «транспортним засобом».
Q # 24) Яке значення метаданих?
Відповідь: Метадані - це дані про дані. Він повідомляє вам, які дані насправді зберігаються в системі, яке їх призначення та для кого вони призначені.
Висновок
- Практичне розуміння Моделювання даних Концепція та те, як вона вписується у виконані вами завдання, вкрай необхідні для злому інтерв’ю з моделювання даних.
- Найпоширеніші теми в Моделювання даних інтерв'ю - це різні типи моделей даних, типи схем, типи вимірювань та нормалізації.
- Будьте добре підготовлені і до запитань на основі сценарію.
Я б запропонував, щоб, коли ви відповідаєте на запитання інтерв’юеру, краще пояснювати ідею на прикладі. Це свідчить про те, що ви насправді працювали у цій галузі, і ви дуже добре розумієте суть концепції.
Всього найкращого!!