top 24 data modeling interview questions with detailed answers
Liste over de mest stilte spørsmålene og svarene på datamodelleringsintervju og svar som hjelper deg med å forberede deg på det kommende intervjuet:
Her skal jeg dele noen spørsmål om datamodelleringsintervju og detaljerte svar basert på min egen erfaring under intervjuinteraksjoner i noen kjente IT-MNC-er.
Nedenfor kan spørsmålssvar være til stor hjelp hvis du får sjansen til å møte eller ta et intervju om datamodellering.
Ofte stilte spørsmål om datamodelleringsintervju
La oss begynne!
Q # 1) Hva forstår du av datamodellering?
Svar: Datamodellering er den diagrammatiske representasjonen som viser hvordan enhetene er relatert til hverandre. Det er det første trinnet mot databasedesign. Vi oppretter først den konseptuelle modellen, deretter den logiske modellen og går til slutt til den fysiske modellen.
Generelt blir datamodellene opprettet i dataanalyse og designfase i livssyklusen for programvareutvikling.
Q # 2) Forklar din forståelse av forskjellige datamodeller?
Svar: Det er tre typer datamodeller - konseptuelle, logiske og fysiske. Kompleksitets- og detaljnivået øker fra konseptuelt til logisk til en fysisk datamodell.
Den konseptuelle modellen viser et veldig grunnleggende høyt designnivå mens den fysiske datamodellen viser en veldig detaljert visning av design.
- Konseptuell modell vil bare skildre enhetsnavn og enhetsforhold. Figur 1 vist i den senere delen av denne artikkelen viser en konseptuell modell.
- Logisk modell vil vise opp enhetsnavn, enhetsrelasjoner, attributter, primærnøkler og utenlandske nøkler i hver enhet. Figur 2 vist i spørsmål nr. 4 i denne artikkelen viser en logisk modell.
- Fysiske datamodell vil vise primærnøkler, utenlandske nøkler, tabellnavn, kolonnenavn og kolonnedatatyper. Denne visningen utdyper faktisk hvordan modellen faktisk skal implementeres i databasen.
Q # 3) Kast litt lys over din erfaring med datamodellering med hensyn til prosjekter du har jobbet med til dags dato?
Merk: Dette var det aller første spørsmålet i et av mine datamodelleringsintervjuer. Så før du går inn i intervju-diskusjonen, bør du ha et veldig klart bilde av hvordan datamodellering passer inn i oppgavene du har jobbet med.
Svar: Jeg har jobbet med et prosjekt for et helseforsikringsselskap der vi har grensesnitt innebygd Databehandling som transformerer og behandler dataene hentet fra Facets-databasen og sender ut nyttig informasjon til leverandører.
Merk: Fasetter er en slutt-til-slutt-løsning for å administrere all informasjon for helsevesenet. Fasettdatabasen i prosjektet mitt ble opprettet med SQL server 2012.
Vi hadde forskjellige enheter som var knyttet sammen. Disse enhetene var abonnent, medlem, helsepersonell, krav, regning, påmelding, gruppe, kvalifisering, plan / produkt, provisjon, capitation, etc.
Nedenfor er den konseptuelle datamodellen som viser hvordan prosjektet så ut på høyt nivå
Figur 1:
Hver av dataenhetene har sine egne dataattributter. For eksempel, en dataattributt til leverandøren vil være leverandøridentifikasjonsnummer, få dataattributter til medlemskapet vil være abonnent-ID, medlems-ID, en av dataattributten i kravet vil kreve ID, hvert helseprodukt eller plan vil ha en unik produkt-ID og så videre.
Q # 4) Hva er de forskjellige designskjemaene i datamodellering? Forklar medeksempel?
Svar: Det er to forskjellige typer skjemaer i datamodellering
- Stjerneplan
- Snøfnuggskjema
Nå skal jeg forklare hver av disse skjemaene en etter en.
Den enkleste av skjemaene er stjerneskjema hvor vi har en faktatabell i midten som refererer til flere dimensjonstabeller rundt den. Alle dimensjonstabellene er koblet til faktatabellen. Primærnøkkelen i alle dimensjonstabeller fungerer som en fremmed nøkkel i faktatabellen.
De ER diagram (se figur 2) av dette skjemaet ligner formen på en stjerne, og det er grunnen til at dette skjemaet blir kalt et stjerneskjema.
Figur 2:
Stjerneskjemaet er ganske enkelt, fleksibelt og er i de-normalisert form.
I et snøfnuggskjema øker normaliseringsnivået. Faktatabellen her forblir den samme som i stjerneskjemaet. Imidlertid er dimensjonstabellene normalisert. På grunn av flere lag med dimensjonstabeller ser det ut som et snøfnugg, og dermed blir det kalt som snøfnuggskjema.
hvilken type test brukes for å verifisere at alle programmer i et program fungerer riktig?
Figur 3:
Sp # 5) Hvilket opplegg brukte du i prosjektet ditt og hvorfor?
Q # 6) Hvilket skjema er bedre - stjerne eller snøfnugg?
Svar: (kombinert for spørsmål nr. 5 og 6): Valget av et skjema avhenger alltid av prosjektets krav og scenarier.
Siden stjerneskjemaet er i de-normalisert form, trenger du færre sammenføyninger for et spørsmål. Søket er enkelt og går raskere i et stjerneskjema. Kommer til snøfnuggskjemaet, siden det er i normalisert form, vil det kreve et antall sammenføyninger sammenlignet med et stjerneskjema, spørringen vil være kompleks og utførelsen vil være tregere enn stjerneskjemaet.
En annen signifikant forskjell mellom disse to skjemaene er at snøfnuggskjemaet ikke inneholder overflødige data og dermed er det enkelt å vedlikeholde. Tvert imot, stjerneskjema har et høyt redundansnivå og dermed er det vanskelig å opprettholde.
Nå, hvilken skal du velge for prosjektet ditt? Hvis formålet med prosjektet ditt er å gjøre mer av dimensjonsanalyse, bør du gå til snøfnuggskjema. For eksempel, hvis du trenger å finne ut av det 'Hvor mange abonnenter er knyttet til en bestemt plan som for øyeblikket er aktiv?' - gå med snøfnuggmodellen.
Hvis formålet med prosjektet ditt er å gjøre mer av en beregning, bør du gå med et stjerneskjema. For eksempel, hvis du trenger å finne ut av det 'Hva er kravbeløpet betalt til en bestemt abonnent?' - gå med et stjerneskjema.
I prosjektet mitt brukte vi snøfnuggskjema fordi vi måtte gjøre analyser på tvers av flere dimensjoner og generere sammendragsrapporter for virksomheten. En annen grunn til å bruke snøfnuggskjema var at det er mindre minneforbruk.
Sp # 7) Hva forstår du etter dimensjon og attributt?
Svar: Dimensjoner representerer kvalitative data. For eksempel, plan, produkt, klasse er alle dimensjoner.
En dimensjonstabell inneholder beskrivende eller tekstlige attributter. For eksempel, produktkategorien og produktnavnet er attributtene til produktdimensjonen.
Q # 8) Hva er fakta og faktatabell?
Svar: Fakta representerer kvantitative data.
For eksempel, netto skyldig beløp er et faktum. En faktatabell inneholder numeriske data og fremmednøkler fra relaterte dimensjonstabeller. Et eksempel på faktatabellen kan sees fra figur 2 vist ovenfor.
Sp # 9) Hva er de forskjellige dimensjonstyper du har kommet over? Forklar hver av dem i detalj med et eksempel?
Svar: Det er vanligvis fem typer dimensjoner.
a) Tilpassede dimensjoner : En dimensjon som brukes som en del av forskjellige områder kalles en tilpasset dimensjon. Det kan brukes med forskjellige faktatabeller i en enkelt database eller over flere datamarkeder / lager.
For eksempel, hvis abonnentdimensjonen er koblet til to faktatabeller - fakturering og krav, vil abonnentdimensjonen bli behandlet som en tilpasset dimensjon.
b) Søppeldimensjon : Det er en dimensjonstabell som inneholder attributter som ikke har plass i faktatabellen eller i noen av de gjeldende dimensjonstabellene. Som regel , Dette er egenskaper som flagg eller indikatorer.
For eksempel, det kan være et medlems kvalifiseringsflagg satt som ‘Y’ eller ‘N’ eller en hvilken som helst annen indikator som er satt som sant / usant, eventuelle spesifikke kommentarer osv. hvis vi holder alle slike indikatorattributter i faktatabellen, blir størrelsen økt. Så , vi kombinerer alle slike attributter og legger i en enkeltdimensjonstabell kalt en søppeldimensjon med unike søppel-IDer med en mulig kombinasjon av alle indikatorverdiene.
c) Rollespilldimensjon : Dette er dimensjonene som brukes til flere formål i samme database.
For eksempel, en datodimensjon kan brukes for 'Kravdato', 'Faktureringsdato' eller 'Plan Term dato'. Så , en slik dimensjon vil bli kalt en rollespilldimensjon. Den primære nøkkelen til datodimensjonen blir assosiert med flere utenlandske nøkler i faktatabellen.
d) Sakte endring av dimensjon (SCD): Disse er viktigst blant alle dimensjonene. Dette er dimensjonene der attributtverdier varierer med tiden. Nedenfor er de forskjellige typene SCD-er
- Type-0: Dette er dimensjonene der attributtverdien holder seg jevn over tid. For eksempel, Abonnentens DOB er en type-0 SCD fordi den alltid vil være den samme uavhengig av tid.
- Type 1: Dette er dimensjonene der den forrige verdien av attributtet erstattes av den nåværende verdien. Ingen historie opprettholdes i Type 1-dimensjonen. For eksempel, Abonnentens adresse (der virksomheten trenger å beholde den eneste nåværende adressen til abonnenten) kan være en type 1-dimensjon.
- Type-2: Dette er dimensjonene der ubegrenset historie er bevart. For eksempel, Abonnentens adresse (der virksomheten krever å føre oversikt over alle de tidligere adressene til abonnenten). I dette tilfellet vil flere rader for en abonnent bli satt inn i tabellen med hans / hennes forskjellige adresser. Det vil være noen kolonner som identifiserer gjeldende adresse. For eksempel, 'Startdato' og 'Sluttdato'. Raden der 'Sluttdato' -verdien vil være tom vil inneholde abonnentens nåværende adresse, og alle andre radene vil ha tidligere adresser til abonnenten.
- Type 3: Dette er typen dimensjoner der begrenset historie er bevart. Og vi bruker en ekstra kolonne for å opprettholde historikken. For eksempel, Abonnentens adresse (der virksomheten trenger å føre oversikt over nåværende og bare én tidligere adresse). I dette tilfellet kan vi oppløse 'adresse' kolonnen i to forskjellige kolonner - 'nåværende adresse' og 'forrige adresse'. Så, i stedet for å ha flere rader, vil vi bare ha en rad som viser gjeldende samt den forrige adressen til abonnenten.
- Type 4: I denne typen dimensjoner er de historiske dataene bevart i en egen tabell. Hoveddimensjonstabellen inneholder bare gjeldende data. For eksempel, hoveddimensjonstabellen vil bare ha en rad per abonnent som holder sin nåværende adresse. Alle andre tidligere adresser til abonnenten vil bli oppbevart i den separate historikktabellen. Denne typen dimensjoner blir nesten aldri brukt.
e) Degenerert dimensjon: En degenerert dimensjon er en dimensjon som ikke er et faktum, men som presenteres i faktatabellen som en primærnøkkel. Den har ikke sin egen dimensjonstabell. Vi kan også kalle det som en enkelt attributtdimensjonstabell.
Men , i stedet for å holde det separat i en dimensjonstabell og sette en ekstra sammenføyning, legger vi denne attributtet i faktatabellen direkte som en nøkkel. Siden den ikke har sin egen dimensjonstabell, kan den aldri fungere som en fremmed nøkkel i faktatabellen.
Spørsmål nr. 10) Gi din ide om faktale fakta? Og hvorfor bruker vi det?
Svar: Faktafaktabell er en faktatabell som ikke inneholder noe faktamål i den. Den har bare dimensjonstastene i seg.
Noen ganger kan det oppstå visse situasjoner i virksomheten der du trenger å ha en sakløs faktatabell.
For eksempel, antar at du opprettholder et system for fremmøte for ansattes tilstedeværelse, kan du ha en sakløs faktatabell med tre nøkler.
| Ansatt ID |
| Avdeling_ID |
| Time_ID |
Du kan se at tabellen ovenfor ikke inneholder noen mål. Nå, hvis du vil svare på spørsmålet nedenfor, kan du enkelt gjøre det ved å bruke den ovennevnte faktaløse faktatabellen i stedet for å ha to separate faktatabeller:
'Hvor mange ansatte i en bestemt avdeling var til stede på en bestemt dag?'
Så, den faktiske faktabordet gir designen fleksibilitet.
Q # 11) Skille mellom OLTP og OLAP?
Svar: OLTP står for Online transaksjonsbehandlingssystem & OLAP står for Online analytisk prosesseringssystem . OLTP opprettholder transaksjonsdataene til virksomheten og er generelt veldig normalisert. Tvert imot er OLAP for analyse- og rapporteringsformål og det er i de-normalisert form.
Denne forskjellen mellom OLAP og OLTP gir deg også muligheten til å velge utformingen av skjemaet. Hvis systemet ditt er OLTP, bør du gå med stjerneskjemautforming, og hvis systemet ditt er OLAP, bør du gå med snøfnuggskjema.
hvordan du åpner .bin filer Windows 10
Spørsmål nr. 12) Hva forstår du av datamart?
Svar: Data marts er for det meste ment for en ensom gren av virksomheten. De er designet for de enkelte avdelingene.
For eksempel, Før jobbet jeg for et helseforsikringsselskap som hadde forskjellige avdelinger i det som økonomi, rapportering, salg og så videre.
Vi hadde et datalager som inneholdt informasjonen som gjelder alle disse avdelingene, og så har vi få datamarkeringer bygget på toppen av dette datalageret. Disse DataMart var spesifikke for hver avdeling. Med enkle ord kan du si at en DataMart er en delmengde av et datalager.
Spørsmål nr. 13) Hva er de forskjellige typer tiltak?
Svar: Vi har tre typer tiltak, nemlig
dobbeltkoblet liste c ++ kode
- Ikke tilsetningsstoffer
- Halvadditiv tiltak
- Tilsetningsstoffer
Ikke-additive tiltak er de som ingen aggregeringsfunksjon kan brukes på. For eksempel, et forhold eller en prosentkolonne; et flagg eller en indikatorkolonne som faktisk er tilstede med verdier som J / N, etc. er et ikke-additivt mål.
Halvadditiv tiltak er de som noen (men ikke alle) aggregeringsfunksjoner kan brukes på. For eksempel, gebyrsats eller kontosaldo.
Tilsetningsmål er de som alle aggregeringsfunksjonene kan brukes på. For eksempel, enheter kjøpt.
Sp # 14) Hva er en surrogatnøkkel? Hvordan er det forskjellig fra en primærnøkkel?
Svar: Surrogatnøkkel er en unik identifikator eller en systemgenerert sekvensnummernøkkel som kan fungere som en primærnøkkel. Det kan være en kolonne eller en kombinasjon av kolonner. I motsetning til en primærnøkkel blir den ikke hentet fra de eksisterende applikasjonsdatafeltene.
Sp # 15) Er dette sant at alle databaser skal være i 3NF?
Svar: Det er ikke obligatorisk for en database å være i 3NF. men , hvis formålet ditt er enkelt vedlikehold av data, mindre redundans og effektiv tilgang, bør du gå med en de-normalisert database.
Spørsmål nr. 16) Har du noen gang kommet over scenariet med rekursive forhold? Hvis ja, hvordan håndterte du det?
Svar: Et rekursivt forhold oppstår i tilfelle der en enhet er relatert til seg selv. Ja, jeg har kommet over et slikt scenario.
Når vi snakker om helsevesenet, er det en mulighet for at en helsepersonell (for eksempel en lege) er pasient til enhver annen helsepersonell. Fordi , hvis legen selv blir syk og trenger kirurgi, må han besøke en annen lege for å få kirurgisk behandling.
Så , i dette tilfellet er enheten - helsepersonell relatert til seg selv. En utenlandsk nøkkel til helseforsikringsleverandørens nummer må vises i hvert medlems (pasient) journal.
Spørsmål nr. 17) List opp noen vanlige feil som oppstod under datamodellering?
Svar: Få vanlige feil som oppstod under datamodellering er:
- Bygger massive datamodeller : Store datamodeller har som flere designfeil. Prøv å begrense datamodellen din til ikke mer enn 200 tabeller.
- Mangel på formål : Hvis du ikke vet hva det er din forretningsløsning er beregnet på, kan du komme med en feil datamodell. Så det å ha klarhet i forretningsformålet er veldig viktig for å komme med den riktige datamodellen.
- Upassende bruk av surrogatnøkler : Surrogatnøkkel skal ikke brukes unødvendig. Bruk surrogatnøkkel bare når den naturlige nøkkelen ikke kan tjene formålet med en primærnøkkel.
- Unødvendig de-normalisering : Ikke denormaliser til og med mindre du har en solid og tydelig forretningsgrunn til å gjøre det fordi de-normalisering skaper overflødige data som er vanskelig å vedlikeholde.
Sp # 18) Hvor mange barn kan det opprettes fra en enslig foreldretabell?
Svar: Antall underordnede tabeller som kan opprettes fra eneforeldretabellen er lik antall felt / kolonner i foreldretabellen som ikke er nøkler.
Spørsmål 19) Ansattes helseopplysninger blir skjult for arbeidsgiveren av helsepersonell. Hvilket nivå av data som skjuler seg er dette? Konseptuelt, fysisk eller eksternt?
Svar: Dette er scenariet for et eksternt nivå av data som skjuler seg.
Spørsmål nr. 20) Hva er formen for faktatabell og dimensjonstabell?
Svar: Generelt er faktatabellen i normalisert form og dimensjonstabellen i de-normalisert form.
Spørsmål nr. 21) Hvilke detaljer trenger du for å komme med en konseptuell modell i et helsevesenet domeneprosjekt?
Svar: For et helseprosjekt vil detaljene nedenfor være tilstrekkelige med kravet til å utforme en grunnleggende konseptuell modell
- Ulike kategorier av helseplaner og produkter.
- Type abonnement (gruppe eller individ).
- Sett med helsepersonell.
- Oversikt over krav og faktureringsprosesser.
Spørsmål nr. 22) vanskelig: Hvis en unik begrensning blir brukt på en kolonne, vil det kaste en feil hvis du prøver å sette inn to null i den?
Svar: Nei, det vil ikke kaste feil i dette tilfellet fordi en nullverdi er ulik en annen nullverdi. Så, mer enn én null vil bli satt inn i kolonnen uten feil.
Spørsmål nr. 23) Kan du sitere et eksempel på en undertype og en supertypenhet?
Svar: Ja, la oss si at vi har disse forskjellige enhetene - kjøretøy, bil, sykkel, økonomibil, familiebil, sportsbil.
Her er et kjøretøy en supertypenhet. Bil og sykkel er dens undertype enheter. Videre er økonomibiler, sportsbiler og familiebiler undertype enheter av dens super-type enhetsbil.
En supertypenhet er den som er på et høyere nivå. Undertypeenheter er de som er gruppert sammen på grunnlag av visse egenskaper. For eksempel, alle sykler er tohjulede og alle biler er firehjulinger. Og siden begge er kjøretøyer, er supertypenheten deres 'kjøretøy'.
Spørsmål nr. 24) Hva er betydningen av metadata?
Svar: Metadata er data om data. Den forteller deg hva slags data som faktisk lagres i systemet, hva er formålet med det og for hvem det er ment.
Konklusjon
- Praktisk forståelse av Datamodellering konseptet og hvordan det passer inn i oppgavene du har gjort, er mye nødvendig for å knekke et datamodelleringsintervju.
- De mest stilte spørsmålene i Datamodellering intervju er - forskjellige typer datamodeller, typer skjemaer, dimensjoner og normalisering.
- Vær også forberedt på scenariobaserte spørsmål.
Jeg vil foreslå at når du svarer på et spørsmål til intervjueren, er det bedre at du forklarer ideen gjennom et eksempel. Dette vil vise at du faktisk har jobbet inn i dette området, og du forstår kjernen i konseptet veldig godt.
Beste ønsker!!