Най-добрите 24 въпроса за интервю за моделиране на данни с подробни отговори

top 24 data modeling interview questions with detailed answers

Списък на най-често задаваните въпроси за интервю за моделиране на данни и отговори, които да ви помогнат да се подготвите за предстоящото интервю:

Тук ще споделя няколко въпроса за интервю за моделиране на данни и подробни отговори въз основа на собствения ми опит по време на интервюта в няколко известни IT MNC.

По-долу въпросите-отговори могат да ви бъдат от голяма помощ, ако имате възможност да се изправите или да вземете интервю за моделиране на данни.

Най-често задавани въпроси за интервю за моделиране на данни

Да започваме!

В # 1) Какво разбирате от моделиране на данни?

Отговор: Моделиране на данни е схематичното представяне, показващо как обектите са свързани помежду си. Това е първоначалната стъпка към дизайна на базата данни. Първо създаваме концептуалния модел, след това логическия модел и накрая преминаваме към физическия модел.

Като цяло моделите на данни се създават във фазата на анализ и проектиране на жизнения цикъл на разработването на софтуер.

Q # 2) Обяснете разбирането си за различни модели данни?

Отговор: Има три типа модели на данни - концептуални, логически и физически. Нивото на сложност и детайлност се увеличава от концептуален към логически до физически модел на данни.

Концептуалният модел показва много основно високо ниво на дизайн, докато физическият модел на данни показва много подробен изглед на дизайна.

• Концептуален модел ще бъде просто изобразяване на имена на обекти и връзки на обекти. Фигура 1, показана в по-късната част на тази статия, изобразява концептуален модел.
• Логически модел ще показва имена на обекти, връзки на обекти, атрибути, първични ключове и външни ключове във всеки обект. Фигура 2, показана във въпрос № 4 в тази статия, показва логически модел.
• Физически модел на данни ще показва първични ключове, външни ключове, имена на таблици, имена на колони и типове данни за колони. Този изглед всъщност изяснява как моделът ще бъде действително внедрен в базата данни.

Q # 3) Хвърлете малко светлина върху опита си в моделирането на данни по отношение на проекти, по които сте работили до момента?

Забележка: Това беше първият въпрос в едно от интервютата ми за моделиране на данни. Така че, преди да влезете в дискусията за интервюто, трябва да имате много ясна представа за това как моделирането на данни се вписва в заданията, по които сте работили.

Отговор: Работил съм по проект за здравноосигурителна компания, където имаме вградени интерфейси Изчислителна техника който трансформира и обработва данните, извлечени от базата данни на Facets и изпраща полезна информация на доставчиците.

Забележка: Facets е цялостно решение за управление на цялата информация за здравната индустрия. Базата данни на фасетите в моя проект е създадена със SQL Server 2012.

Имахме различни обекти, които бяха свързани заедно. Тези субекти бяха абонат, член, доставчик на здравни услуги, иск, сметка, записване, група, допустимост, план / продукт, комисионна, капитализация и др.

По-долу е представен концептуалният модел на данни, показващ как е изглеждал проектът на високо ниво

Фигура 1:

Всеки от обектите на данни има свои собствени атрибути на данни. Например, атрибут на данните на доставчика ще бъде идентификационен номер на доставчика, малко атрибути на данните на членството ще бъдат идентификатор на абонат, идентификатор на член, един от атрибута на данните на исковата молба ще поиска идентификационен номер, всеки здравен продукт или план ще има уникален идентификатор на продукта и скоро.

В # 4) Какви са различните схеми на проектиране при моделирането на данни? Обяснете спример?

Отговор: Има два различни вида схеми в моделирането на данни

• Звезден график
• Схема на снежинка

Сега ще обяснявам всяка от тези схеми една по една.

Най-простата от схемите е звезда, където имаме таблица с факти в центъра, която препраща към таблици с множество измерения около нея. Всички таблици с измерения са свързани с таблицата с факти. Първичният ключ във всички таблици с измерения действа като външен ключ в таблицата с факти.

The Диаграма IS (вижте фигура 2) на тази схема прилича на формата на звезда и затова тази схема е наречена като звездна схема.

Фигура 2:

Схемата на звездата е доста проста, гъвкава и е в денормирана форма.

В схема на снежинка нивото на нормализиране се увеличава. Таблицата с факти тук остава същата като в схемата на звездата. Таблиците с размери обаче са нормализирани. Поради няколко слоя таблици с размери, тя прилича на снежинка и по този начин е наречена като схема на снежинка.

разлика между задействане на портове и пренасочване на портове

Фигура 3:

В # 5) Коя схема използвахте във вашия проект и защо?

В # 6) Коя схема е по-добра - звезда или снежинка?

Отговор: (Комбинирано за Q # 5 и 6): Изборът на схема винаги зависи от изискванията и сценариите на проекта.

Тъй като схемата на звездата е в денормализирана форма, за заявката се изискват по-малко обединения. Заявката е проста и работи по-бързо в звездна схема. Пристигайки към схемата на снежинката, тъй като тя е в нормализирана форма, ще са необходими редица съединения в сравнение със звездна схема, заявката ще бъде сложна и изпълнението ще бъде по-бавно от звездната схема.

Друга съществена разлика между тези две схеми е, че схемата на снежинката не съдържа излишни данни и по този начин е лесна за поддръжка. Напротив, звездната схема има високо ниво на излишък и поради това е трудно да се поддържа.

Сега кой да изберете за вашия проект? Ако целта на вашия проект е да направите повече анализ на измеренията, трябва да изберете схема за снежинка. Например, ако трябва да разберете това „Колко абонати са обвързани с определен план, който е активен в момента?“ - отидете с модела снежинка.

Ако целта на вашия проект е да извършите повече анализ на показателите, трябва да използвате схема със звезди. Например, ако трябва да разберете това „Каква е сумата на иска, платена на определен абонат?“ Отидете със звездна схема.

В моя проект използвахме схема за снежинки, защото трябваше да направим анализ в няколко измерения и да генерираме обобщени отчети за бизнеса. Друга причина за използването на схема за снежинка е, че е по-малко консумация на памет.

В # 7) Какво разбирате под измерение и атрибут?

Отговор: Размерите представляват качествени данни. Например, план, продукт, клас са всички измерения.

Таблица с измерения съдържа описателни или текстови атрибути. Например, категорията на продукта и името на продукта са атрибутите на измерението на продукта.

В # 8) Какво е таблица с факти и факти?

Отговор: Фактите представляват количествени данни.

Например, нетната дължима сума е факт. Фактическата таблица съдържа цифрови данни и външни ключове от свързани таблици с размери. Пример за таблицата с факти може да се види от Фигура 2, показана по-горе.

В # 9) Какви са различните видове измерения, които сте срещали? Обяснете подробно всеки от тях с пример?

Отговор: Обикновено има пет вида размери.

а) Съобразени размери : Измерение, което се използва като част от различни области, се нарича съответстващо измерение. Той може да се използва с различни таблици с факти в една база данни или над многобройни полета за данни / складове.

Например, ако измерението на абоната е свързано с две таблици с факти - таксуване и рекламация, тогава измерението на абоната ще се третира като съответстващо измерение.

б) Нежелана величина : Това е таблица с измерения, състояща се от атрибути, които нямат място в таблицата с факти или в която и да е от текущите таблици с измерения. В общи линии , това са свойства като флагове или индикатори.

Например, това може да бъде флаг за допустимост на членовете, зададен като „Y“ или „N“ или друг индикатор, зададен като true / false, някакви конкретни коментари и др., ако запазим всички такива атрибути на индикатора в таблицата с факти, размерът му се увеличава. Така , ние комбинираме всички такива атрибути и поставяме в една таблица с измерения, наречена нежелана величина, имаща уникални идентификатори за боклук с възможна комбинация от всички стойности на индикатора.

в) Ролево измерение : Това са измеренията, които се използват за множество цели в една и съща база данни.

Например, измерение на датата може да се използва за „Дата на иска“, „Дата на фактуриране“ или „Дата на срока на планиране“. Така , такова измерение ще се нарича Ролево измерение. Първичният ключ на измерението Дата ще бъде свързан с множество външни ключове в таблицата с факти.

г) Бавно променящи се размери (SCD): Те са най-важни сред всички измерения. Това са размерите, при които стойностите на атрибутите варират във времето. По-долу са различните видове SCD

• Тип 0: Това са размерите, при които стойността на атрибута остава стабилна във времето. Например, DOB на абоната е SCD тип 0, защото винаги ще остане същият, независимо от времето.
• Тип 1: Това са размерите, при които предишната стойност на атрибута се заменя с текущата стойност. Не се поддържа история в измерението Тип-1. Например, Адресът на абоната (където бизнесът изисква да запази единствения текущ адрес на абонат) може да бъде измерение от тип 1.
• Тип 2: Това са измеренията, в които се запазва неограничена история. Например, Адрес на абоната (където бизнесът изисква да води запис на всички предишни адреси на абоната). В този случай в таблицата ще бъдат вмъкнати множество редове за абонат с различните му адреси. Ще има някои колони, които ще идентифицират текущия адрес. Например, „Начална дата“ и „Крайна дата“. Редът, където стойността на „Крайна дата“ ще бъде празна, ще съдържа текущия адрес на абоната, а всички останали редове ще имат предишни адреси на абоната.
• Тип 3: Това са типовете измерения, при които се запазва ограничена история. И ние използваме допълнителна колона, за да поддържаме историята. Например, Адрес на абоната (където бизнесът изисква да води запис на текущия и само един предишен адрес). В този случай можем да разтворим колоната „адрес“ в две различни колони - „текущ адрес“ и „предишен адрес“. Така че, вместо да имаме няколко реда, ще имаме само един ред, показващ текущия, както и предишния адрес на абоната.
• Тип 4: При този тип измерения историческите данни се съхраняват в отделна таблица. Основната таблица с измерения съдържа само текущите данни. Например, основната таблица с измерения ще има само един ред на абонат, който държи текущия си адрес. Всички други предишни адреси на абоната ще се съхраняват в отделната таблица на историята. Този тип измерения почти никога не се използва.

д) Дегенерирано измерение: Дегенерираното измерение е измерение, което не е факт, но се представя в таблицата с факти като първичен ключ. Той няма собствена таблица с размери. Можем да го наречем и като единична таблица с измерения на атрибутите.

Но , вместо да го държим отделно в таблица с измерения и да добавим допълнително съединение, ние поставяме този атрибут в таблицата с факти директно като ключ. Тъй като няма собствена таблица с измерения, тя никога не може да действа като външен ключ в таблицата с факти.

Въпрос # 10) Дайте идеята си относно безфактумен факт? И защо го използваме?

въпроси за интервю за софтуерно тестване с отговори

Отговор: Фактическата таблица на фактите е таблица на фактите, която не съдържа фактическа мярка в нея. В него има само ключовете за размери.

Понякога в бизнеса могат да възникнат определени ситуации, при които трябва да имате безбройна фактическа таблица.

Например, да предположим, че поддържате система за записване на присъствие на служители, можете да имате безбройна фактическа таблица с три ключа.

Можете да видите, че горната таблица не съдържа никаква мярка. Сега, ако искате да отговорите на въпроса по-долу, можете лесно да използвате горната единична таблица без факти, вместо да имате две отделни таблици с факти:

„Колко служители от определен отдел присъстваха в определен ден?“

И така, фактическата таблица с факти предлага гъвкавост на дизайна.

В # 11) Разграничаване между OLTP и OLAP?

Отговор: OLTP означава Онлайн система за обработка на транзакции & OLAP означава Онлайн система за аналитична обработка . OLTP поддържа данните за транзакциите на бизнеса и е силно нормализирана като цяло. Напротив, OLAP е за целите на анализа и отчитането и е в денормализирана форма.

Тази разлика между OLAP и OLTP също ви дава начин да изберете дизайна на схемата. Ако вашата система е OLTP, трябва да използвате дизайна на звездна схема, а ако вашата система е OLAP, трябва да използвате схема на снежинка.

В # 12) Какво разбирате от data mart?

Отговор: Данните за данни са в по-голямата си част предназначени за самотен клон на бизнеса. Те са предназначени за отделните отдели.

Например, Преди работех за компания, предоставяща здравно осигуряване, в която имаше различни отдели като финанси, отчетност, продажби и т.н.

Имахме хранилище за данни, което съхраняваше информацията, отнасяща се до всички тези отдели, а след това имаме няколко полета за данни, изградени върху това хранилище за данни. Тези DataMart бяха специфични за всеки отдел. С прости думи можете да кажете, че DataMart е подмножество на хранилище за данни.

В # 13) Какви са различните видове мерки?

Отговор: Имаме три вида мерки, а именно

• Неадитивни мерки
• Полуадитивни мерки
• Адитивни мерки

Неадитивни мерки са тези, върху които не може да се приложи функция за агрегиране. Например, съотношение или процентна колона; флаг или индикаторна колона, присъстваща в действителност в таблица, съдържаща стойности като Y / N и др.

Полуадитивните мерки са тези, върху които могат да се приложат някои (но не всички) агрегиращи функции. Например, такса или салдо по сметката.

Адитивните мерки са тези, върху които могат да бъдат приложени всички функции за агрегиране. Например, закупени единици.

Въпрос # 14) Какво е сурогатен ключ? По какво се различава от първичния ключ?

Отговор: Сурогатният ключ е уникален идентификатор или генериран от системата ключ с пореден номер, който може да действа като първичен ключ. Това може да бъде колона или комбинация от колони. За разлика от първичния ключ, той не е взет от съществуващите полета за данни на приложението.

Въпрос # 15) Вярно ли е, че всички бази данни трябва да са в 3NF?

Отговор: Не е задължително базата данни да е в 3NF. въпреки това , ако целта ви е лесна поддръжка на данни, по-малко излишък и ефективен достъп, тогава трябва да използвате де-нормализирана база данни.

Въпрос # 16) Попадали ли сте някога на сценария на рекурсивни връзки? Ако да, как се справихте?

Отговор: Рекурсивна връзка възниква в случая, когато даден обект е свързан със себе си. Да, попаднал съм на такъв сценарий.

Говорейки за областта на здравеопазването, възможно е доставчикът на здравни услуги (да речем, лекар) да е пациент на всеки друг доставчик на здравни грижи. Защото , ако самият лекар се разболее и се нуждае от операция, той ще трябва да посети някой друг лекар, за да получи хирургично лечение.

Така , в този случай субектът - доставчик на здравни грижи е свързан със себе си. Чуждестранен ключ към номера на здравноосигурителния доставчик ще трябва да присъства в архива на всеки член (пациент).

В # 17) Избройте няколко често срещани грешки, срещнати по време на моделирането на данни?

Отговор: Малко често срещани грешки, срещани по време на моделирането на данни, са:

кой е най-добрият софтуер за копиране на DVD

• Изграждане на масивни модели данни : Големите модели данни искат да имат повече дизайнерски грешки. Опитайте се да ограничите модела си на данни до не повече от 200 таблици.
• Липса на цел : Ако не знаете, за какво е предназначено вашето бизнес решение, може да излезете с неправилен модел на данни. Така че наличието на яснота относно бизнес целта е много важно, за да се излезе с правилния модел на данните.
• Неподходящо използване на заместващи ключове : Сурогатният ключ не трябва да се използва ненужно. Използвайте сурогатен ключ само когато естественият ключ не може да служи за целта на първичен ключ.
• Излишно денормализиране : Не денормализирайте, докато и освен ако нямате солидна и ясна бизнес причина да го направите, защото денормализацията създава излишни данни, които е трудно да се поддържат.

В # 18) Какъв е броят на дъщерни таблици, които могат да бъдат създадени от една родителска таблица?

Отговор: Броят на дъщерни таблици, които могат да бъдат създадени от единичната родителска таблица, е равен на броя полета / колони в родителската таблица, които не са ключове.

В # 19) Данните за здравето на служителя са скрити от работодателя му от доставчика на здравни услуги. Кое ниво на скриване на данни е това? Концептуална, физическа или външна?

Отговор: Това е сценарият на външно ниво на скриване на данни.

В # 20) Каква е формата на таблица с факти и таблица с измерения?

Отговор: Обикновено таблицата с факти е в нормализиран вид, а таблицата с измерения е в денормирана форма.

В # 21) Какви подробности ще ви трябват, за да излезете с концептуален модел в проект за здравна област?

Отговор: За здравен проект по-долу подробности ще бъдат достатъчни за изискването за проектиране на основен концептуален модел

• Различни категории здравни планове и продукти.
• Тип абонамент (групов или индивидуален).
• Набор от доставчици на здравни услуги.
• Преглед на процеса на вземане и фактуриране.

Въпрос # 22) Трудно: Ако към колона се приложи уникално ограничение, ще изведе ли грешка, ако се опитате да вмъкнете две нули в нея?

Отговор: Не, в този случай няма да доведе до грешка, тъй като нулевата стойност е неравна на друга нулева стойност. Така че, повече от една нула ще бъдат вмъкнати в колоната без грешка.

В # 23) Можете ли да цитирате пример за обект от подтип и супер тип?

Отговор: Да, да кажем, че имаме тези различни обекти - превозно средство, кола, велосипед, икономична кола, семейна кола, спортна кола.

Тук превозното средство е субект от супер тип. Автомобилът и моторът са неговите подтипове. Освен това икономичните автомобили, спортните автомобили и семейните автомобили са подтип на субекта на неговия субект автомобил.

Субект от супер тип е този, който е на по-високо ниво. Обектите от подтип са тези, които са групирани заедно въз основа на определени характеристики. Например, всички мотоциклети са двуколесни, а всички автомобили са четириколесни. И тъй като и двете са превозни средства, значи тяхната суперотипна единица е „превозно средство“.

В # 24) Какво е значението на метаданните?

Отговор: Метаданните са данни за данни. Той ви казва какъв вид данни всъщност се съхраняват в системата, каква е целта и за кого са предназначени.

Заключение

• Практическо разбиране на Моделиране на данни Концепцията и как тя се вписва в изпълнените от вас задачи е много необходима за пробиване на интервю за моделиране на данни.
• Най-често задаваните теми в Моделиране на данни интервю са - различни видове модели на данни, видове схеми, видове измерения и нормализация.
• Бъдете добре подготвени и за базирани на сценарии въпроси.

Бих предложил, че когато отговаряте на въпрос на интервюиращия, е по-добре да обясните идеята чрез пример. Това ще покаже, че всъщност сте работили в тази област и много добре разбирате същността на концепцията.

Всичко най-хубаво!!

Препоръчително четене

• 10 най-добри инструмента за моделиране на данни за управление на сложни дизайни
• Най-добрите 24 въпроса за интервю за моделиране на данни с подробни отговори