top 24 data modeling interview questions with detailed answers
Liste over hyppigst stillede spørgsmål til datamodelleringsinterview og svar til at hjælpe dig med at forberede dig til det kommende interview:
Her vil jeg dele nogle Data Modeling-interviewspørgsmål og detaljerede svar baseret på min egen erfaring under interviewinteraktioner i et par kendte IT MNC'er.
Nedenstående spørgsmål kan være til stor hjælp, hvis du får en chance for at møde eller tage et interview om datamodellering.
Ofte stillede spørgsmål om datamodellering
Lad os begynde!
Spørgsmål nr. 1) Hvad forstår du ved datamodellering?
Svar: Datamodellering er den diagrammatiske gengivelse, der viser, hvordan enhederne er relateret til hinanden. Det er det første skridt mod databasedesign. Vi opretter først den konceptuelle model, derefter den logiske model og går til sidst til den fysiske model.
Generelt oprettes datamodellerne i dataanalyse og designfase af softwareudviklings livscyklus.
Q # 2) Forklar din forståelse af forskellige datamodeller?
Svar: Der er tre typer datamodeller - konceptuelle, logiske og fysiske. Niveauet af kompleksitet og detaljer stiger fra konceptuel til logisk til en fysisk datamodel.
Den konceptuelle model viser et meget grundlæggende højt designniveau, mens den fysiske datamodel viser en meget detaljeret visning af design.
- Konceptuel model vil bare skildre enhedsnavne og enhedsrelationer. Figur 1 vist i den senere del af denne artikel viser en konceptuel model.
- Logisk model vises enhedsnavne, enhedsrelationer, attributter, primære nøgler og udenlandske nøgler i hver enhed. Figur 2 vist inde i spørgsmål nr. 4 i denne artikel viser en logisk model.
- Fysiske datamodel viser primære nøgler, fremmednøgler, tabelnavne, kolonnenavne og kolonnedatatyper. Denne opfattelse uddyber faktisk, hvordan modellen faktisk implementeres i databasen.
Q # 3) Kast lidt lys over din erfaring med datamodellering med hensyn til projekter, du har arbejdet med indtil dato?
Bemærk: Dette var det allerførste spørgsmål i et af mine datamodelleringsinterviews. Så før du går ind i samtalen, skal du have et meget klart billede af, hvordan datamodellering passer ind i de opgaver, du har arbejdet med.
Svar: Jeg har arbejdet på et projekt for et sundhedsforsikringsselskab, hvor vi har indbyggede grænseflader Computing der transformerer og behandler de data, der hentes fra Facets-databasen og sender nyttige oplysninger til leverandører.
Bemærk: Facetter er en ende-til-slut-løsning til styring af al information til sundhedsindustrien. Facetsdatabasen i mit projekt blev oprettet med SQL server 2012.
Vi havde forskellige enheder, der var knyttet sammen. Disse enheder var abonnent, medlem, sundhedsudbyder, krav, regning, tilmelding, gruppe, støtteberettigelse, plan / produkt, provision, capitation osv.
Nedenfor er den konceptuelle datamodel, der viser, hvordan projektet så ud på et højt niveau
Figur 1:
Hver af dataenhederne har sine egne dataattributter. For eksempel, en dataattribut for udbyderen vil være udbyderidentifikationsnummer, få dataattributter for medlemskabet vil være abonnent-id, medlems-id, en af dataattributten i kravet vil kræve id, hvert sundhedsprodukt eller plan vil have et unikt produkt-id og snart.
Spørgsmål nr. 4) Hvad er de forskellige designskemaer i datamodellering? Forklar medeksempel?
Svar: Der er to forskellige slags skemaer i datamodellering
- Stjerneplan
- Snowflake Schema
Nu vil jeg forklare hver af disse skemaer en efter en.
Den enkleste af skemaerne er stjerneskema, hvor vi har en faktatabel i midten, der refererer til flere dimensionstabeller omkring den. Alle dimensionstabellerne er forbundet med faktatabellen. Den primære nøgle i alle dimensionstabeller fungerer som en fremmed nøgle i faktatabellen.
Det ER diagram (se figur 2) af dette skema ligner formen på en stjerne, og det er derfor, dette skema er navngivet som et stjerneskema.
Figur 2:
Stjerneskemaet er ret simpelt, fleksibelt og er i de-normaliseret form.
I et snefnugskema øges normaliseringsniveauet. Faktatabellen her forbliver den samme som i stjerneskemaet. Imidlertid er dimensionstabellerne normaliseret. På grund af flere lag af dimensionstabeller ser det ud som en snefnug, og derfor er den navngivet som snefnugskema.
binært søgetræsprogram i java
Figur 3:
Spørgsmål nr. 5) Hvilket skema brugte du i dit projekt og hvorfor?
Spørgsmål nr. 6) Hvilket skema er bedre - stjerne eller snefnug?
Svar: (Kombineret til Q # 5 & 6): Valget af et skema afhænger altid af projektets krav og scenarier.
Da stjerneskemaet er i de-normaliseret form, har du brug for færre sammenføjninger til en forespørgsel. Forespørgslen er enkel og kører hurtigere i et stjerneskema. Kommer til snefnugskemaet, da det er i normaliseret form, vil det kræve et antal sammenføjninger sammenlignet med et stjerneskema, forespørgslen vil være kompleks og udførelsen vil være langsommere end stjerneskemaet.
En anden væsentlig forskel mellem disse to skemaer er, at snefnugskemaet ikke indeholder overflødige data, og det er derfor let at vedligeholde. Tværtimod har stjerneskemaet et højt redundansniveau, og det er derfor svært at vedligeholde.
Hvilken skal du nu vælge til dit projekt? Hvis formålet med dit projekt er at gøre mere af dimensionanalyse, skal du gå til snefnugskema. For eksempel, hvis du har brug for at finde ud af det 'Hvor mange abonnenter er bundet til en bestemt plan, der i øjeblikket er aktiv?' - gå med snefnugmodellen.
Hvis formålet med dit projekt er at gøre mere af en metrics-analyse, skal du gå med et stjerneskema. For eksempel, hvis du har brug for at finde ud af det 'Hvad er erstatningsbeløbet betalt til en bestemt abonnent?' - gå med et stjerneskema.
I mit projekt brugte vi snefnugskema, fordi vi var nødt til at foretage analyser på tværs af flere dimensioner og generere oversigtsrapporter til virksomheden. En anden grund til at bruge snefnugskema var, at det er mindre hukommelsesforbrug.
Spørgsmål nr. 7) Hvad forstår du ved dimension og attribut?
Svar: Dimensioner repræsenterer kvalitative data. For eksempel, plan, produkt, klasse er alle dimensioner.
En dimensionstabel indeholder beskrivende eller tekstlige attributter. For eksempel, produktkategorien & produktnavnet er attributterne for produktdimensionen.
Q # 8) Hvad er en fakta og en faktatabel?
Svar: Fakta repræsenterer kvantitative data.
For eksempel, det skyldige nettobeløb er en kendsgerning. En faktatabel indeholder numeriske data og fremmednøgler fra relaterede dimensionstabeller. Et eksempel på faktatabellen kan ses fra figur 2 vist ovenfor.
Q # 9) Hvad er de forskellige typer dimensioner, du er stødt på? Forklar hver af dem detaljeret med et eksempel?
Svar: Der er typisk fem typer dimensioner.
a) Tilpassede dimensioner : En dimension, der bruges som en del af forskellige områder kaldes en tilpasset dimension. Det kan bruges med forskellige faktatabeller i en enkelt database eller over adskillige datamærker / lagre.
For eksempel, hvis abonnentdimensionen er forbundet med to faktatabeller - fakturering og krav, vil abonnentdimensionen blive behandlet som en tilpasset dimension.
b) Uønsket dimension : Det er en dimensionstabel, der indeholder attributter, der ikke har plads i faktatabellen eller i nogen af de aktuelle dimensionstabeller. Generelt , disse er egenskaber som flag eller indikatorer.
For eksempel, det kan være et medlems kvalifikationsflag, der er angivet som 'Y' eller 'N' eller en hvilken som helst anden indikator, der er angivet som sand / falsk, eventuelle specifikke kommentarer osv., hvis vi holder alle sådanne indikatoregenskaber i faktatabellen, bliver dens størrelse øget. Så , vi kombinerer alle sådanne attributter og lægger i en enkelt dimensionstabel kaldet en junk-dimension med unikke junk-id'er med en mulig kombination af alle indikatorværdier.
c) Rollespil-dimension : Dette er de dimensioner, der bruges til flere formål i den samme database.
For eksempel, en datodimension kan bruges til 'Kravsdato', 'Faktureringsdato' eller 'Planteringsdato'. Så , en sådan dimension vil blive kaldt en rolle-spiller dimension. Den primære nøgle til dato-dimensionen vil være knyttet til flere udenlandske nøgler i faktatabellen.
d) Langsomt skiftende dimension (SCD): Disse er vigtigst blandt alle dimensioner. Dette er de dimensioner, hvor attributværdier varierer med tiden. Nedenfor er de forskellige typer SCD'er
- Type-0: Dette er de dimensioner, hvor attributværdien forbliver stabil med tiden. For eksempel, Abonnentens DOB er en type-0 SCD, fordi den altid forbliver den samme uanset tid.
- Type 1: Dette er de dimensioner, hvor den tidligere værdi af attributten erstattes af den aktuelle værdi. Ingen historie opretholdes i Type 1-dimensionen. For eksempel, Abonnentens adresse (hvor virksomheden skal beholde den eneste aktuelle adresse på abonnenten) kan være en type 1-dimension.
- Type 2: Dette er de dimensioner, hvor ubegrænset historie bevares. For eksempel, Abonnentens adresse (hvor virksomheden kræver at registrere alle abonnentens tidligere adresser). I dette tilfælde indsættes flere rækker for en abonnent i tabellen med hans / hendes forskellige adresser. Der vil være nogle kolonner, der identificerer den aktuelle adresse. For eksempel, 'Startdato' og 'Slutdato'. Den række, hvor 'Slutdato' -værdien vil være tom, vil indeholde abonnentens aktuelle adresse, og alle andre rækker vil have tidligere adresser til abonnenten.
- Type-3: Dette er typen af dimensioner, hvor begrænset historie bevares. Og vi bruger en ekstra kolonne til at opretholde historien. For eksempel, Abonnentens adresse (hvor virksomheden kræver at registrere den aktuelle og kun en tidligere adresse). I dette tilfælde kan vi opløse kolonnen 'adresse' i to forskellige kolonner - 'nuværende adresse' og 'tidligere adresse'. Så i stedet for at have flere rækker har vi kun en række, der viser nuværende såvel som den tidligere adresse på abonnenten.
- Type 4: I denne type dimension bevares de historiske data i en separat tabel. Hoveddimensionstabellen indeholder kun de aktuelle data. For eksempel, hoveddimensionstabellen vil kun have en række pr. abonnent, der holder den aktuelle adresse. Alle andre tidligere adresser for abonnenten vil blive gemt i den separate historiktabel. Denne type dimension anvendes næsten aldrig.
e) Degenereret dimension: En degenereret dimension er en dimension, der ikke er en kendsgerning, men præsenteres i faktatabellen som en primær nøgle. Det har ikke sin egen dimensionstabel. Vi kan også kalde det som en enkelt attributdimensionstabel.
Men , i stedet for at holde det separat i en dimensionstabel og lægge en ekstra sammenføjning, lægger vi denne attribut direkte i faktatabellen som en nøgle. Da den ikke har sin egen dimensionstabel, kan den aldrig fungere som en fremmed nøgle i faktatabellen.
Spørgsmål nr. 10) Giv din idé om faktiske fakta? Og hvorfor bruger vi det?
Svar: Faktaløs faktatabel er en faktatabel, der ikke indeholder nogen faktamål. Det har kun dimensionstasterne i sig.
bedste gratis pc renere windows 7
Til tider kan der opstå visse situationer i virksomheden, hvor du har brug for en faktuel tabel.
For eksempel, Antag, at du opretholder et medarbejderdeltagelsessystem, du kan have en faktuel tabel med tre nøgler.
| Medarbejder-ID |
| Afdelings-ID |
| Time_ID |
Du kan se, at ovenstående tabel ikke indeholder nogen mål. Nu, hvis du vil besvare nedenstående spørgsmål, kan du gøre det let ved hjælp af ovenstående enkelt faktaløse faktatabel i stedet for at have to separate faktatabeller:
'Hvor mange medarbejdere i en bestemt afdeling var til stede på en bestemt dag?'
Så den faktiske faktabord giver design fleksibilitet.
Spørgsmål nr. 11) Skelner du mellem OLTP og OLAP?
Svar: OLTP står for Online transaktionsbehandlingssystem & OLAP står for Online analytisk behandlingssystem . OLTP vedligeholder transaktionsdataene for virksomheden og er generelt meget normaliseret. Tværtimod er OLAP til analyse- og rapporteringsformål, og det er i de-normaliseret form.
Denne forskel mellem OLAP og OLTP giver dig også mulighed for at vælge skemaets design. Hvis dit system er OLTP, skal du gå med stjerneskema-design, og hvis dit system er OLAP, skal du gå med snefnugskema.
Spørgsmål nr. 12) Hvad forstår du ved datamart?
Svar: Datamærker er for det meste beregnet til en ensom branche. De er designet til de enkelte afdelinger.
For eksempel, Jeg arbejdede tidligere hos et sundhedsforsikringsselskab, der havde forskellige afdelinger som finans, rapportering, salg osv.
Vi havde et datalager, der indeholdt oplysningerne vedrørende alle disse afdelinger, og så har vi få datamærker bygget oven på dette datalager. Disse DataMart var specifikke for hver afdeling. Med enkle ord kan du sige, at en DataMart er en delmængde af et datalager.
Spørgsmål nr. 13) Hvad er de forskellige typer tiltag?
Svar: Vi har tre typer tiltag, nemlig
- Ikke-additive foranstaltninger
- Halvadditive foranstaltninger
- Additive foranstaltninger
Ikke-additive målinger er dem, som ingen aggregeringsfunktion kan anvendes på. For eksempel, et forhold eller en procentkolonne et flag eller en indikatorsøjle, der faktisk findes i tabel, der indeholder værdier som J / N osv., er et ikke-additivt mål.
Halvadditive målinger er dem, som nogle (men ikke alle) aggregeringsfunktioner kan anvendes på. For eksempel, gebyrsats eller kontosaldo.
Additive målinger er dem, som alle aggregeringsfunktioner kan anvendes på. For eksempel, købte enheder.
Spørgsmål nr. 14) Hvad er en surrogatnøgle? Hvordan adskiller den sig fra en primær nøgle?
Svar: Surrogatnøgle er en unik identifikator eller en systemgenereret sekvensnummernøgle, der kan fungere som en primær nøgle. Det kan være en kolonne eller en kombination af kolonner. I modsætning til en primær nøgle hentes den ikke fra de eksisterende applikationsdatafelter.
Spørgsmål nr. 15) Er dette sandt, at alle databaser skal være i 3NF?
Svar: Det er ikke obligatorisk for en database at være i 3NF. Imidlertid , hvis dit formål er nem vedligeholdelse af data, mindre redundans og effektiv adgang, skal du gå med en de-normaliseret database.
Spørgsmål nr. 16) Har du nogensinde stødt på scenariet med rekursive forhold? Hvis ja, hvordan håndterede du det?
Svar: Et rekursivt forhold opstår i det tilfælde, hvor en enhed er relateret til sig selv. Ja, jeg er stødt på et sådant scenario.
Når vi taler om sundhedsområdet, er det en mulighed for, at en sundhedsudbyder (f.eks. En læge) er patient for enhver anden sundhedsudbyder. Fordi , hvis lægen selv bliver syg og har brug for operation, bliver han nødt til at besøge en anden læge for at få den kirurgiske behandling.
Så , i dette tilfælde er enheden - sundhedsudbyderen relateret til sig selv. En fremmed nøgle til sundhedsforsikringsnummerets nummer skal fremgå af hvert medlems (patient) journal.
Spørgsmål nr. 17) Angiv et par almindelige fejl, der opstår under datamodellering?
Svar: Få almindelige fejl, der opstår under datamodellering, er:
- Opbygning af massive datamodeller : Store datamodeller kan lide at have flere designfejl. Prøv at begrænse din datamodel til ikke mere end 200 tabeller.
- Manglende formål : Hvis du ikke ved, hvad din forretningsløsning er beregnet til, kan du komme med en forkert datamodel. Så det er meget vigtigt at have klarhed om forretningsformålet for at komme med den rigtige datamodel.
- Uhensigtsmæssig brug af surrogatnøgler : Surrogatnøgle bør ikke bruges unødigt. Brug kun surrogatnøgle, når den naturlige nøgle ikke kan tjene formålet med en primær nøgle.
- Unødvendig de-normalisering : Undlad at normalisere, før og medmindre du har en solid og klar forretningsgrund til at gøre det, fordi de-normalisering skaber overflødige data, som er vanskelige at vedligeholde.
Spørgsmål nr. 18) Hvad er antallet af underordnede tabeller, der kan oprettes ud fra en enkelt overordnet tabel?
Svar: Antallet af underordnede tabeller, der kan oprettes ud fra den enlige overordnede tabel, er lig med antallet af felter / kolonner i den overordnede tabel, der ikke er nøgler.
Spørgsmål nr. 19) Oplysninger om medarbejdernes sundhed er skjult for sin arbejdsgiver af sundhedsudbyderen. Hvilket niveau af dataskydning er dette? Konceptuel, fysisk eller ekstern?
Svar: Dette er scenariet for et eksternt niveau af datagemulighed.
Spørgsmål nr. 20) Hvad er formen for faktabord og dimensionstabel?
Svar: Generelt er faktatabellen i normaliseret form, og dimensionstabellen er i de-normaliseret form.
Spørgsmål nr. 21) Hvilke oplysninger har du brug for for at komme med en konceptuel model i et sundhedsdomæne-projekt?
Svar: For et sundhedsprojekt er nedenstående detaljer tilstrækkelige med kravet om at designe en grundlæggende konceptuel model
- Forskellige kategorier af sundhedsplaner og produkter.
- Type abonnement (gruppe eller individ).
- Sæt af sundhedsudbydere.
- Oversigt over krav og fakturering.
Spørgsmål nr. 22) Tricky: Hvis der anvendes en unik begrænsning på en kolonne, vil den så kaste en fejl, hvis du prøver at indsætte to nuller i den?
Svar: Nej, det kaster ikke nogen fejl i dette tilfælde, fordi en nulværdi er ulig en anden nulværdi. Så mere end en null indsættes i kolonnen uden nogen fejl.
Spørgsmål nr. 23) Kan du citere et eksempel på en undertype og en supertypenhed?
Svar: Ja, lad os sige, at vi har disse forskellige enheder - køretøj, bil, cykel, økonomibil, familiebil, sportsvogn.
Her er et køretøj en super-type enhed. Bil og cykel er dens undertype enheder. Endvidere er økonomibiler, sportsvogne og familiebiler undertypeenheder i dens super-type enhedsbil.
En super-type enhed er den, der er på et højere niveau. Undertypeenheder er enheder, der er grupperet på basis af visse karakteristika. For eksempel, alle cykler er tohjulede og alle biler er firehjulede. Og da begge er køretøjer, så er deres super-type enhed 'køretøj'.
Spørgsmål nr. 24) Hvad er betydningen af metadata?
Svar: Metadata er data om data. Den fortæller dig, hvilken type data der faktisk er gemt i systemet, hvad er dets formål, og for hvem de er beregnet.
Konklusion
- Praktisk forståelse af Datamodellering koncept og hvordan det passer ind i de opgaver, du har udført, er meget nødvendigt for at knække et datamodelleringsinterview.
- De mest stillede emner i Datamodellering Interview er - forskellige typer datamodeller, typer af skemaer, typer af dimensioner og normalisering.
- Vær også godt forberedt på scenariebaserede spørgsmål.
Jeg vil foreslå, at når du besvarer et spørgsmål til intervieweren, er det bedre, at du forklarer ideen gennem et eksempel. Dette vil vise, at du faktisk har arbejdet inden for dette område, og at du forstår kernen i konceptet meget godt.
Alt det bedste!!
venstre indre sammenføjning mod venstre ydre sammenføjning