top 24 data modeling interview questions with detailed answers
Zoznam najčastejšie kladených otázok a odpovedí na otázky súvisiace s modelovaním údajov, ktoré vám pomôžu pripraviť sa na nadchádzajúci rozhovor:
Tu sa podelím s niekoľkými renomovanými IT MNC o niekoľko otázok týkajúcich sa rozhovorov o dátovom modelovaní a podrobných odpovedí na základe mojich vlastných skúseností počas interakcií s rozhovormi.
Odpovede na nižšie uvedené otázky vám môžu pomôcť, ak máte šancu čeliť alebo absolvovať pohovor o dátovom modelovaní.
Najčastejšie otázky spojené s rozhovorom s modelovaním údajov
Začnime!
Otázka č. 1) Čo rozumiete pod údajovým modelovaním?
Odpoveď: Dátové modelovanie je schematické znázornenie znázorňujúce vzájomný vzťah medzi entitami. Je to prvý krok k návrhu databázy. Najskôr vytvoríme koncepčný model, potom logický model a nakoniec prejdeme k fyzickému modelu.
Dátové modely sa spravidla vytvárajú vo fáze analýzy a návrhu údajov životného cyklu vývoja softvéru.
Otázka č. 2) Vysvetlite svoje pochopenie rôznych dátových modelov?
Odpoveď: Existujú tri typy dátových modelov - koncepčný, logický a fyzický. Úroveň zložitosti a detailov sa zvyšuje od koncepčných cez logické po fyzické dátové modely.
Koncepčný model zobrazuje veľmi základnú vysokú úroveň dizajnu, zatiaľ čo model fyzických údajov zobrazuje veľmi podrobný pohľad na dizajn.
- Koncepčný model bude iba zobrazovať názvy entít a vzťahy entít. Obrázok 1 zobrazený v neskoršej časti tohto článku zobrazuje koncepčný model.
- Logický model bude zobrazovať názvy entít, vzťahy entít, atribúty, primárne kľúče a cudzie kľúče v každej entite. Obrázok 2 uvedený v otázke č. 4 v tomto článku zobrazuje logický model.
- Fyzický dátový model bude zobrazovať primárne kľúče, cudzie kľúče, názvy tabuliek, názvy stĺpcov a dátové typy stĺpcov. Tento pohľad vlastne rozpracováva, ako bude model v databáze skutočne implementovaný.
Otázka č. 3) Vrhnite trochu svetla na svoje skúsenosti s dátovým modelovaním v súvislosti s projektmi, na ktorých ste pracovali dodnes?
Poznámka: Toto bola úplne prvá otázka v jednom z mojich rozhovorov o modelovaní dát. Než teda vstúpite do diskusie na pohovore, mali by ste mať veľmi jasný obraz o tom, ako dátové modelovanie zapadá do úloh, na ktorých ste pracovali.
Odpoveď: Pracoval som na projekte pre spoločnosť poskytujúcu zdravotné poistenie, kde máme zabudované rozhrania Výpočtový ktorá transformuje a spracováva údaje načítané z databázy Facets a odosiela užitočné informácie predajcom.
Poznámka: Facets je komplexné riešenie na správu všetkých informácií pre zdravotnícky priemysel. Fazeta databáza v mojom projekte bola vytvorená pomocou servera SQL Server 2012.
Mali sme rôzne entity, ktoré boli navzájom prepojené. Tieto subjekty boli predplatiteľ, člen, poskytovateľ zdravotnej starostlivosti, nárok, účet, registrácia, skupina, spôsobilosť, plán / produkt, provízia, kapitácia atď.
Ďalej je uvedený koncepčný dátový model, ktorý ukazuje, ako projekt vyzeral na vysokej úrovni
Postava 1:
Každá z dátových entít má svoje vlastné atribúty údajov. Napríklad, dátový atribút poskytovateľa bude identifikačné číslo poskytovateľa, niekoľko údajových atribútov členstva bude ID predplatiteľa, ID člena, jeden z dátových atribútov žiadosti bude ID žiadosti, každý produkt alebo plán zdravotnej starostlivosti bude mať jedinečné ID produktu a tak ďalej.
Otázka č. 4) Aké sú rôzne návrhové schémy v modelovaní údajov? Vysvetlite pomocoupríklad?
Odpoveď: V modelovaní údajov existujú dva rôzne druhy schém
- Rozpis hviezd
- Schéma snehovej vločky
Teraz budem postupne vysvetľovať každú z týchto schém.
Najjednoduchšou zo schém je hviezdna schéma, kde máme v strede tabuľku faktov, ktorá okolo odkazuje na tabuľky viacerých dimenzií. Všetky tabuľky dimenzií sú spojené s tabuľkou faktov. Primárny kľúč vo všetkých tabuľkách dimenzií funguje ako cudzí kľúč v tabuľke faktov.
The Diagram IS (pozri obrázok 2) tejto schémy pripomína tvar hviezdy, a preto je táto schéma pomenovaná ako hviezdicová schéma.
Obrázok 2:
Hviezdna schéma je dosť jednoduchá, flexibilná a je v normalizovanej podobe.
V schéme snehových vločiek sa zvyšuje úroveň normalizácie. Tabuľka faktov tu zostáva rovnaká ako v hviezdnej schéme. Tabuľky dimenzií sú však normalizované. Vďaka niekoľkým vrstvám tabuliek dimenzií vyzerá ako snehová vločka, a preto je pomenovaná ako schéma snehovej vločky.
čo robí beta tester
Obrázok 3:
Otázka č. 5) Ktorú schému ste vo svojom projekte použili a prečo?
Otázka č. 6) Ktorá schéma je lepšia - hviezda alebo snehová vločka?
Odpoveď: (Kombinované pre Q # 5 a 6): Výber schémy vždy závisí od požiadaviek a scenárov projektu.
Pretože schéma hviezd je v normalizovanej podobe, pre dopyt potrebujete menej pripojení. Dotaz je jednoduchý a vo hviezdnej schéme beží rýchlejšie. Pokiaľ ide o schému snehovej vločky, pretože je v normalizovanej podobe, bude vyžadovať počet spojení v porovnaní s hviezdnou schémou, dopyt bude zložitý a vykonávanie bude pomalšie ako hviezdna schéma.
Ďalším významným rozdielom medzi týmito dvoma schémami je, že schéma snehových vločiek neobsahuje nadbytočné údaje, a preto je nenáročná na údržbu. Naopak, hviezdna schéma má vysokú úroveň nadbytočnosti, a preto je ťažké ju udržiavať.
Teraz, ktorý z nich si zvoliť pre svoj projekt? Ak je cieľom vášho projektu urobiť viac z dimenzionálnej analýzy, mali by ste ísť na schému snehovej vločky. Napríklad, ak to potrebuješ zistiť „Koľko predplatiteľov je viazaných na konkrétny plán, ktorý je momentálne aktívny?“ - choďte s modelom snehovej vločky.
Ak je cieľom vášho projektu urobiť viac metrickej analýzy, mali by ste ísť s hviezdnou schémou. Napríklad, ak to potrebuješ zistiť „Aká je výška nároku zaplatená konkrétnemu predplatiteľovi?“ - ísť s hviezdnou schémou.
V mojom projekte sme použili schému snehových vločiek, pretože sme museli urobiť analýzu naprieč niekoľkými dimenziami a vygenerovať súhrnné správy pre firmu. Ďalším dôvodom použitia schémy snehových vločiek bolo, že je to menšia spotreba pamäte.
Otázka č. 7) Čo rozumiete podľa dimenzie a atribútu?
Odpoveď: Dimenzie predstavujú kvalitatívne údaje. Napríklad, plán, produkt, trieda sú všetky rozmery.
Tabuľka dimenzií obsahuje popisné alebo textové atribúty. Napríklad, kategória a názov produktu sú atribútmi dimenzie produktu.
Otázka č. 8) Čo je tabuľka faktov a faktov?
Odpoveď: Fakty predstavujú kvantitatívne údaje.
Napríklad, čistá splatná suma je skutočnosť. Tabuľka faktov obsahuje číselné údaje a cudzie kľúče zo súvisiacich dimenzionálnych tabuliek. Príklad tabuľky faktov je možné vidieť na obrázku 2 zobrazenom vyššie.
Otázka č. 9) Na aké rôzne typy dimenzií ste narazili? Vysvetlite každý z nich podrobne na príklade?
Odpoveď: Zvyčajne existuje päť typov dimenzií.
a) Zhodné rozmery : Dimenzia, ktorá sa používa ako súčasť rôznych oblastí, sa nazýva konformná dimenzia. Môže byť použitý s rôznymi tabuľkami faktov v jednej databáze alebo v mnohých dátových centrách / skladoch.
Napríklad, ak je dimenzia predplatiteľa spojená s dvoma tabuľkami faktov - fakturácia a nárok, potom by sa dimenzia predplatiteľa považovala za konformnú dimenziu.
b) Junk Dimension : Je to tabuľka dimenzií pozostávajúca z atribútov, ktoré nemajú miesto v tabuľke faktov alebo v žiadnej z aktuálnych tabuliek dimenzií. Spravidla , to sú vlastnosti ako príznaky alebo indikátory.
Napríklad, môže to byť príznak spôsobilosti člena nastavený na „Y“ alebo „N“ alebo akýkoľvek iný indikátor nastavený na hodnotu true / false, akékoľvek konkrétne komentáre atď. ak ponecháme všetky tieto atribúty indikátora v tabuľke faktov, jeho veľkosť sa zväčší. Takže , skombinujeme všetky tieto atribúty a vložíme do jednej dimenzionálnej tabuľky s názvom junk dimenzia s jedinečnými ID nevyžiadanej pošty s možnou kombináciou všetkých hodnôt indikátora.
c) Dimenzia hry na hrdinov : Toto sú dimenzie, ktoré sa používajú na rôzne účely v tej istej databáze.
Napríklad, dimenziu dátumu je možné použiť pre „Dátum nároku“, „Dátum fakturácie“ alebo „Dátum termínu plánu“. Takže , takáto dimenzia sa bude nazývať dimenzia hranie rolí. Primárny kľúč dimenzie Dátum bude v tabuľke faktov spojený s viacerými cudzími kľúčmi.
d) Pomaly sa meniaca dimenzia (SCD): To sú najdôležitejšie spomedzi všetkých dimenzií. Toto sú dimenzie, kde sa hodnoty atribútov líšia v závislosti od času. Ďalej uvádzame rôzne typy diskov SCD
- Typ 0: Toto sú dimenzie, kde hodnota atribútu zostáva stabilná s časom. Napríklad, Účastnícky DOB je SCD typu 0, pretože bez ohľadu na čas zostane vždy rovnaký.
- Typ 1: Jedná sa o dimenzie, kde je predchádzajúca hodnota atribútu nahradená aktuálnou hodnotou. V dimenzii typu 1 sa neuchováva žiadna história. Napríklad, Adresa predplatiteľa (ak si podnik vyžaduje ponechanie jedinej aktuálnej adresy predplatiteľa) môže byť dimenziou typu 1.
- Typ 2: To sú dimenzie, kde sa zachováva neobmedzená história. Napríklad, Adresa predplatiteľa (ak podnik vyžaduje uchovanie záznamu o všetkých predchádzajúcich adresách predplatiteľa). V takom prípade sa do tabuľky vloží viac riadkov pre predplatiteľa s jeho rôznymi adresami. Bude niekoľko stĺpcov, ktoré identifikujú aktuálnu adresu. Napríklad, „Dátum začatia“ a „Dátum ukončenia“. Riadok, kde bude hodnota „Dátum ukončenia“ prázdny, bude obsahovať aktuálnu adresu predplatiteľa a všetky ostatné riadky budú mať predchádzajúce adresy predplatiteľa.
- Typ 3: Jedná sa o typ dimenzií, kde sa zachováva obmedzená história. A na udržanie histórie používame ďalší stĺpec. Napríklad, Adresa predplatiteľa (ak si firma vyžaduje zaznamenanie aktuálnej a iba jednej predchádzajúcej adresy). V takom prípade môžeme stĺpec „adresa“ rozpustiť do dvoch rôznych stĺpcov - „aktuálna adresa“ a „predchádzajúca adresa“. Namiesto viacerých riadkov teda budeme mať iba jeden riadok, ktorý zobrazuje aktuálnu aj predchádzajúcu adresu účastníka.
- Typ 4: V tomto type dimenzie sa historické údaje uchovávajú v samostatnej tabuľke. Tabuľka hlavných dimenzií obsahuje iba aktuálne údaje. Napríklad, tabuľka hlavnej dimenzie bude mať iba jeden riadok na každého predplatiteľa, ktorý má svoju aktuálnu adresu. Všetky ostatné predchádzajúce adresy predplatiteľa sa uložia v samostatnej tabuľke histórie. Tento typ dimenzie sa takmer nikdy nepoužíva.
e) Degenerovaný rozmer: Degenerovaná dimenzia je dimenzia, ktorá nie je skutočnosťou, ale predstavuje sa v tabuľke faktov ako primárny kľúč. Nemá svoju vlastnú tabuľku rozmerov. Môžeme to tiež nazvať ako tabuľku dimenzií jedného atribútu.
ale , namiesto toho, aby sme ho osobitne uchovávali v tabuľke dimenzií a vložili ďalšie spojenie, vložili sme tento atribút do tabuľky faktov priamo ako kľúč. Pretože nemá svoju vlastnú tabuľku dimenzií, nikdy nemôže pôsobiť ako cudzí kľúč v tabuľke faktov.
Otázka č. 10) Povedzte svoj názor na fakty? A prečo to používame?
Odpoveď: Tabuľka faktických faktov je tabuľka faktov, ktorá v sebe neobsahuje nijaké opatrenie. Má v sebe iba rozmerové kľúče.
Občas môžu v podnikaní nastať určité situácie, keď potrebujete mať tabuľku faktov.
Napríklad, Predpokladajme, že udržiavate systém evidencie dochádzky zamestnancov. Môžete mať tabuľku faktov s tromi kľúčmi.
| Zamestnanecké ID |
| Department_ID |
| Time_ID |
Vidíte, že vyššie uvedená tabuľka neobsahuje žiadne opatrenia. Teraz, ak chcete odpovedať na nasledujúcu otázku, môžete jednoducho použiť vyššie uvedenú jednoduchú tabuľku faktov, a nie dve samostatné tabuľky faktov:
'Koľko zamestnancov konkrétneho oddelenia bolo v konkrétny deň prítomných?'
Takže tabuľka faktov ponúka flexibilitu dizajnu.
Otázka č. 11) Rozlišovať medzi OLTP a OLAP?
Odpoveď: OLTP znamená Systém online spracovania transakcií & OLAP znamená Systém online analytického spracovania . Spoločnosť OLTP uchováva transakčné údaje o podniku a je všeobecne vysoko normalizovaná. Naopak, OLAP slúži na účely analýzy a vykazovania a je v normalizovanej podobe.
Tento rozdiel medzi OLAP a OLTP vám tiež dáva spôsob, ako zvoliť vzhľad schémy. Ak je váš systém OLTP, mali by ste ísť s návrhom hviezdnej schémy a ak je váš systém OLAP, mali by ste ísť so schémou snehových vločiek.
ako vytvoriť testovacie prípady junit v jave -
Otázka č. 12) Čo rozumiete pod pojmom data mart?
Odpoveď: Dátové trhy sú z väčšej časti určené pre solitérne odvetvie podnikania. Sú určené pre jednotlivé oddelenia.
Napríklad, Pracoval som pre spoločnosť poskytujúcu zdravotné poistenie, ktorá mala rôzne oddelenia, ako napríklad financie, výkazníctvo, predaj a podobne.
Mali sme dátový sklad, ktorý uchovával informácie týkajúce sa všetkých týchto oddelení, a potom sme na vrchole tohto dátového skladu postavili niekoľko dátových trhov. Tieto DataMart boli špecifické pre každé oddelenie. Jednoduchými slovami, môžete povedať, že DataMart je podmnožinou dátového skladu.
Otázka č. 13) Aké sú rôzne typy opatrení?
Odpoveď: Máme tri typy opatrení, a to
rozdiel medzi funkčným a nefunkčným testovaním
- Neaditívne opatrenia
- Poloaditívne opatrenia
- Doplnkové opatrenia
Neaditívne opatrenia sú tie, na ktoré nie je možné použiť žiadnu agregačnú funkciu. Napríklad, stĺpec s pomerom alebo percentami; príznak alebo stĺpec indikátora, ktorý je v skutočnosti v tabuľke, obsahuje hodnoty ako Y / N atď., je neaditívnym opatrením.
Poloaditívne opatrenia sú tie, na ktoré sa dajú použiť niektoré (ale nie všetky) agregačné funkcie. Napríklad, sadzba poplatku alebo zostatok na účte.
Aditívne miery sú tie, na ktoré sa dajú použiť všetky agregačné funkcie. Napríklad, zakúpené jednotky.
Otázka č. 14) Čo je náhradný kľúč? Čím sa líši od primárneho kľúča?
Odpoveď: Náhradný kľúč je jedinečný identifikátor alebo kľúč generovaný systémom podľa poradového čísla, ktorý môže slúžiť ako primárny kľúč. Môže to byť stĺpec alebo kombinácia stĺpcov. Na rozdiel od primárneho kľúča sa nevyberá z existujúcich údajových polí aplikácie.
Otázka č. 15) Je pravda, že všetky databázy by mali byť v 3NF?
Odpoveď: Nie je povinné, aby bola databáza v 3NF. Avšak , ak je vaším účelom ľahká údržba dát, menšia redundancia a efektívny prístup, mali by ste ísť s de-normalizovanou databázou.
Otázka č. 16) Stretli ste sa niekedy so scenárom rekurzívnych vzťahov? Ak áno, ako ste to zvládli?
Odpoveď: Rekurzívny vzťah nastáva v prípade, keď je entita príbuzná sama so sebou. Áno, narazil som na takýto scenár.
Keď hovoríme o doméne zdravotnej starostlivosti, je možné, že poskytovateľ zdravotnej starostlivosti (napríklad lekár) je pacientom iného poskytovateľa zdravotnej starostlivosti. Pretože , ak lekár sám ochorie a potrebuje chirurgický zákrok, bude musieť za účelom chirurgického zákroku navštíviť iného lekára.
Takže , v takom prípade je subjekt - poskytovateľ zdravotnej starostlivosti sám so sebou. Zahraničný kľúč k číslu poskytovateľa zdravotného poistenia bude musieť uviesť v zázname každého pacienta (pacienta).
Otázka 17) Uveďte niekoľko bežných chýb, ktoré sa vyskytli počas modelovania údajov?
Odpoveď: Niekoľko bežných chýb, ktoré sa vyskytli počas modelovania údajov, sú:
- Vytváranie masívnych dátových modelov : Veľké dátové modely môžu mať viac dizajnových chýb. Pokúste sa obmedziť svoj dátový model na najviac 200 tabuliek.
- Nedostatok účelu : Ak neviete, na čo je vaše obchodné riešenie určené, môžete prísť s nesprávnym dátovým modelom. Takže pri objasňovaní obchodných účelov je veľmi dôležité prísť so správnym dátovým modelom.
- Nevhodné použitie náhradných kľúčov : Náhradný kľúč by sa nemal používať zbytočne. Náhradný kľúč používajte, iba ak prirodzený kľúč nemôže slúžiť účelom primárneho kľúča.
- Zbytočná normalizácia : Nenormalizujte, kým a pokiaľ na to nemáte solídny a jasný obchodný dôvod, pretože normalizácia vytvára nadbytočné údaje, ktoré sa ťažko udržiavajú.
Otázka 18) Aký je počet podradených tabuliek, ktoré je možné vytvoriť z jednej nadradenej tabuľky?
Odpoveď: Počet podradených tabuliek, ktoré je možné vytvoriť z tabuľky jedného rodiča, sa rovná počtu polí / stĺpcov v nadradenej tabuľke, ktoré nie sú kľúčmi.
Otázka č. 19) Poskytovateľ zdravotnej starostlivosti pred zamestnávateľom skrýva podrobnosti o zdraví zamestnanca. O ktorú úroveň skrývania údajov sa jedná? Konceptuálne, fyzické alebo externé?
Odpoveď: Toto je scenár externej úrovne skrývania údajov.
Otázka č. 20) Aká je forma tabuľky faktov a tabuľky dimenzií?
Odpoveď: Všeobecne je tabuľka faktov v normalizovanej podobe a tabuľka dimenzií v normalizovanej podobe.
Otázka č. 21) Aké podrobnosti by ste potrebovali, aby ste prišli s koncepčným modelom v projekte domény zdravotnej starostlivosti?
Odpoveď: V prípade projektu zdravotnej starostlivosti by nižšie uvedené podrobnosti postačovali na vytvorenie základného koncepčného modelu
- Rôzne kategórie plánov a produktov zdravotnej starostlivosti.
- Typ predplatného (skupinové alebo individuálne).
- Sada poskytovateľov zdravotnej starostlivosti.
- Prehľad reklamačného a fakturačného procesu.
Otázka č. 22) Tricky one: Ak sa na stĺpec použije jedinečné obmedzenie, spôsobí to chybou, ak sa do neho pokúsite vložiť dve nuly?
Odpoveď: Nie, v tomto prípade to nevyvolá žiadnu chybu, pretože nulová hodnota sa nerovná inej nulovej hodnote. Do stĺpca bude teda bez chyby vložených viac ako jedna nulová hodnota.
Otázka č. 23) Môžete uviesť príklad entity podtypu a supertypu?
Odpoveď: Áno, povedzme, že máme tieto rôzne subjekty - vozidlo, auto, bicykel, ekonomické auto, rodinné auto, športové auto.
V tomto prípade je vozidlo entitou supertypu. Automobil a bicykel sú jeho subtypmi. Ekonomické autá, športové vozidlá a rodinné automobily sú navyše subtypovými entitami jeho supertypu.
Subjekt supertypu je ten, ktorý je na vyššej úrovni. Subjekty podtypu sú tie, ktoré sú zoskupené na základe určitých charakteristík. Napríklad, všetky bicykle sú dvojkolesové a všetky autá sú štvorkolky. A keďže obe sú vozidlami, je ich entita supertypu ‚vozidlo‘.
Otázka č. 24) Aký je význam metadát?
Odpoveď: Metadáta sú údaje o údajoch. Povie vám, aký druh údajov sa v systéme skutočne ukladá, aký je ich účel a pre koho sú určené.
Záver
- Praktické pochopenie Dátové modelovanie koncept a to, ako zapadá do zadaní, ktoré ste vykonali, je veľmi potrebný na uskutočnenie rozhovoru s modelovaním údajov.
- Najčastejšie kladené témy v jazyku Dátové modelovanie rozhovory sú - rôzne typy dátových modelov, typy schém, typy dimenzií a normalizácie.
- Buďte tiež dobre pripravení na otázky založené na scenároch.
Navrhoval by som, že kedykoľvek odpoviete anketárovi na otázku, je lepšie vysvetliť túto myšlienku na príklade. To by ukázalo, že ste sa v tejto oblasti skutočne dopracovali a jadru konceptu veľmi dobre rozumiete.
Všetko najlepšie!!