top 24 data modeling interview questions with detailed answers
다가오는 인터뷰를 준비하는 데 도움이되는 가장 자주 묻는 데이터 모델링 인터뷰 질문 및 답변 목록 :
여기에서는 몇 가지 유명한 IT MNC에서 인터뷰를 진행하는 동안 저의 경험을 바탕으로 데이터 모델링 인터뷰 질문과 자세한 답변을 공유하겠습니다.
아래 질문-답변은 데이터 모델링에 대해 면담하거나 면담 할 기회가있을 때 큰 도움이 될 수 있습니다.
가장 자주 묻는 데이터 모델링 인터뷰 질문
시작하자!
Q # 1) 데이터 모델링을 통해 무엇을 이해하고 있습니까?
대답: 데이터 모델링 엔티티가 서로 관련되는 방식을 보여주는 다이어그램 표현입니다. 데이터베이스 설계를 향한 초기 단계입니다. 먼저 개념 모델을 만든 다음 논리적 모델을 만들고 마지막으로 물리적 모델로 이동합니다.
일반적으로 데이터 모델은 소프트웨어 개발 라이프 사이클의 데이터 분석 및 설계 단계에서 생성됩니다.
질문 # 2) 다양한 데이터 모델에 대한 이해를 설명 하시겠습니까?
대답: 데이터 모델에는 개념적, 논리적 및 물리적 세 가지 유형이 있습니다. 복잡성과 세부 사항의 수준은 개념에서 논리적, 물리적 데이터 모델로 증가합니다.
개념적 모델은 매우 기본적인 높은 수준의 디자인을 보여주는 반면 물리적 데이터 모델은 매우 상세한 디자인보기를 보여줍니다.
- 개념적 모델 엔티티 이름과 엔티티 관계 만 표현합니다. 이 기사의 후반부에 나오는 그림 1은 개념적 모델을 보여줍니다.
- 논리 모델 각 엔티티의 엔티티 이름, 엔티티 관계, 속성, 기본 키 및 외래 키가 표시됩니다. 이 기사의 질문 # 4 안에 표시된 그림 2는 논리적 모델을 보여줍니다.
- 물리적 데이터 모델 기본 키, 외래 키, 테이블 이름, 열 이름 및 열 데이터 유형이 표시됩니다. 이보기는 실제로 데이터베이스에서 모델이 실제로 구현되는 방법을 자세히 설명합니다.
질문 # 3) 지금까지 작업 한 프로젝트와 관련하여 데이터 모델링 경험에 대해 조명 해 주시겠습니까?
노트 : 이것은 데이터 모델링 인터뷰 중 첫 번째 질문이었습니다. 따라서 인터뷰 토론을 시작하기 전에 데이터 모델링이 작업 한 과제에 어떻게 부합하는지 매우 명확하게 이해해야합니다.
대답: 저는 인터페이스가 내장 된 건강 보험 회사의 프로젝트에서 일했습니다. 컴퓨팅 Facets 데이터베이스에서 가져온 데이터를 변환 및 처리하고 유용한 정보를 공급 업체에 보냅니다.
노트 : Facets는 의료 산업에 대한 모든 정보를 관리하기위한 종단 간 솔루션입니다. 내 프로젝트의 패싯 데이터베이스는 SQL Server 2012로 생성되었습니다.
우리는 서로 연결되어있는 서로 다른 엔티티를 가졌습니다. 이러한 엔티티는 가입자, 회원, 의료 제공자, 청구, 청구서, 등록, 그룹, 자격, 계획 / 제품, 커미션, 인두 등이었습니다.
아래는 프로젝트가 상위 수준에서 어떻게 보이는지 보여주는 개념적 데이터 모델입니다.
그림 1 :
각 데이터 엔티티에는 고유 한 데이터 속성이 있습니다. 예를 들어 공급자의 데이터 속성은 공급자 식별 번호이고, 멤버십의 몇 가지 데이터 속성은 가입자 ID, 멤버 ID, 클레임의 데이터 속성 중 하나는 ID를 청구 할 것이며, 각 의료 제품 또는 플랜은 고유 한 제품 ID를 갖게됩니다. 곧.
Q # 4) 데이터 모델링의 다른 디자인 스키마는 무엇입니까? 설명예?
대답: 데이터 모델링에는 두 가지 유형의 스키마가 있습니다.
- 스타 일정
- 눈송이 스키마
이제 이러한 각 스키마를 하나씩 설명하겠습니다.
가장 간단한 스키마는 중앙에 여러 차원 테이블을 참조하는 팩트 테이블이있는 스타 스키마입니다. 모든 차원 테이블은 사실 테이블에 연결됩니다. 모든 차원 테이블의 기본 키는 사실 테이블에서 외래 키 역할을합니다.
그만큼 IS 다이어그램 이 스키마 (그림 2 참조)는 별 모양과 유사하므로이 스키마가 별 스키마로 명명되었습니다.
그림 2 :
스타 스키마는 매우 간단하고 유연하며 비정규 화 된 형태입니다.
눈송이 스키마에서는 정규화 수준이 증가합니다. 여기서 사실 테이블은 스타 스키마에서와 동일하게 유지됩니다. 그러나 차원 테이블은 정규화됩니다. 여러 계층의 차원 테이블로 인해 눈송이처럼 보이므로 눈송이 스키마로 이름이 지정됩니다.
DevOps에서 지속적 배포를위한 도구
그림 3 :
Q # 5) 프로젝트에서 어떤 계획을 사용했으며 그 이유는 무엇입니까?
Q # 6) 어떤 스키마가 더 낫습니까? 스타 또는 눈송이?
답변 : (Q # 5 & 6을 위해 결합) : 스키마 선택은 항상 프로젝트 요구 사항 및 시나리오에 따라 다릅니다.
스타 스키마는 비정규 화 된 형식이므로 쿼리에 더 적은 조인이 필요합니다. 쿼리는 간단하고 스타 스키마에서 더 빠르게 실행됩니다. 눈송이 스키마는 정규화 된 형식이므로 스타 스키마에 비해 많은 조인이 필요하며 쿼리가 복잡하고 실행이 스타 스키마보다 느립니다.
이 두 스키마의 또 다른 중요한 차이점은 눈송이 스키마에 중복 데이터가 포함되어 있지 않으므로 유지 관리가 쉽다는 것입니다. 반대로 스타 스키마는 높은 수준의 중복성을 가지고있어 유지 관리가 어렵습니다.
이제 프로젝트에 어떤 것을 선택할까요? 프로젝트의 목적이 더 많은 차원 분석을 수행하는 것이라면 눈송이 스키마를 사용해야합니다. 예를 들어 알아 내야한다면 '현재 활성화 된 특정 요금제에 몇 명의 가입자가 연결되어 있습니까?' – 눈송이 모델을 사용하십시오.
프로젝트의 목적이 더 많은 메트릭 분석을 수행하는 것이라면 스타 스키마를 사용해야합니다. 예를 들어 알아 내야한다면 '특정 구독자에게 지불 된 클레임 금액은 얼마입니까?' – 스타 스키마로 가십시오.
애니메이션을 무료로 시청할 수있는 애니메이션 웹 사이트
내 프로젝트에서는 여러 차원에서 분석을 수행하고 비즈니스에 대한 요약 보고서를 생성해야했기 때문에 눈송이 스키마를 사용했습니다. 눈송이 스키마를 사용하는 또 다른 이유는 메모리 소비가 적기 때문입니다.
Q # 7) 차원과 속성으로 무엇을 이해하고 있습니까?
대답: 치수는 질적 데이터를 나타냅니다. 예를 들어 계획, 제품, 클래스는 모두 차원입니다.
차원 테이블에는 설명 또는 텍스트 속성이 포함됩니다. 예를 들어 제품 카테고리 및 제품 이름은 제품 차원의 속성입니다.
Q # 8) 팩트 및 팩트 테이블이란 무엇입니까?
대답: 사실은 정량적 데이터를 나타냅니다.
예를 들어 미결제 금액은 사실입니다. 사실 테이블에는 관련 차원 테이블의 숫자 데이터와 외래 키가 포함됩니다. 사실 테이블의 예는 위에 표시된 그림 2에서 볼 수 있습니다.
Q # 9) 당신이 만난 차원의 다른 유형은 무엇입니까? 예를 들어 각각을 자세히 설명 하시겠습니까?
대답: 일반적으로 5 가지 유형의 차원이 있습니다.
a) 적합 치수 : 다른 영역의 일부로 사용되는 차원을 준수 차원이라고합니다. 단일 데이터베이스 또는 수많은 데이터 마트 /웨어 하우스에서 다른 팩트 테이블과 함께 활용 될 수 있습니다.
예를 들어 구독자 차원이 두 개의 팩트 테이블 (청구 및 청구)에 연결된 경우 구독자 차원은 준수 차원으로 처리됩니다.
b) 정크 차원 : 팩트 테이블 또는 현재 차원 테이블에 위치가없는 속성으로 구성된 차원 테이블입니다. 일반적으로 , 이들은 플래그 또는 인디케이터와 같은 속성입니다.
예를 들어 'Y'또는 'N'으로 설정된 멤버 자격 플래그 또는 true / false로 설정된 기타 표시기, 특정 설명 등이 될 수 있습니다. 이러한 모든 표시기 속성을 팩트 테이블에 유지하면 크기가 증가합니다. 그래서 , 이러한 모든 속성을 결합하고 모든 표시기 값의 가능한 조합과 함께 고유 한 정크 ID를 갖는 정크 차원이라는 단일 차원 테이블에 넣습니다.
c) 롤 플레잉 차원 : 동일한 데이터베이스에서 여러 목적으로 사용되는 차원입니다.
예를 들어 날짜 차원은 '클레임 날짜', '청구 날짜'또는 '계획 기간 날짜'에 사용할 수 있습니다. 그래서 , 이러한 차원을 롤 플레잉 차원이라고합니다. Date 차원의 기본 키는 사실 테이블의 여러 외래 키와 연결됩니다.
d) 천천히 변화하는 차원 (SCD) : 이는 모든 차원 중에서 가장 중요합니다. 속성 값이 시간에 따라 달라지는 차원입니다. 다음은 다양한 유형의 SCD입니다.
- 유형 -0 : 속성 값이 시간에 따라 일정하게 유지되는 차원입니다. 예를 들어 구독자의 생년월일은 시간에 관계없이 항상 동일하게 유지되므로 0 형 SCD입니다.
- 유형 -1 : 속성의 이전 값이 현재 값으로 대체되는 차원입니다. Type-1 차원에서는 기록이 유지되지 않습니다. 예를 들어 가입자의 주소 (비즈니스에서 가입자의 현재 주소 만 유지해야하는 경우)는 Type-1 차원이 될 수 있습니다.
- 유형 -2 : 이것들은 무한한 역사가 보존되는 차원입니다. 예를 들어 가입자의 주소 (회사에서 가입자의 모든 이전 주소를 기록해야하는 경우). 이 경우 구독자에 대한 여러 행이 다른 주소로 테이블에 삽입됩니다. 현재 주소를 식별하는 열이 있습니다. 예를 들어 ‘시작일’및‘종료일’. '종료일'값이 비어있는 행에는 구독자의 현재 주소가 포함되고 다른 모든 행에는 구독자의 이전 주소가 포함됩니다.
- 유형 3 : 제한된 역사가 보존되는 차원 유형입니다. 그리고 우리는 역사를 유지하기 위해 추가 열을 사용합니다. 예를 들어 가입자 주소 (비즈니스에서 현재 주소와 이전 주소 하나만 기록해야하는 경우). 이 경우 '주소'열을 '현재 주소'와 '이전 주소'라는 두 개의 다른 열로 분리 할 수 있습니다. 따라서 여러 행을 갖는 대신 구독자의 이전 주소와 현재 주소를 표시하는 한 행만 갖게됩니다.
- 유형 -4 : 이러한 유형의 차원에서는 기록 데이터가 별도의 테이블에 보존됩니다. 기본 차원 테이블은 현재 데이터 만 보유합니다. 예를 들어 기본 차원 테이블에는 현재 주소를 보유하는 구독자 당 하나의 행만 있습니다. 구독자의 다른 모든 이전 주소는 별도의 내역 테이블에 보관됩니다. 이러한 유형의 차원은 거의 사용되지 않습니다.
e) 퇴화 된 차원 : 퇴행 된 차원은 팩트가 아니지만 팩트 테이블에 기본 키로 표시되는 차원입니다. 자체 차원 테이블이 없습니다. 단일 속성 차원 테이블이라고도합니다.
그러나 , 차원 테이블에 별도로 유지하고 추가 조인을 넣는 대신이 속성을 사실 테이블에 키로 직접 넣습니다. 자체 차원 테이블이 없기 때문에 팩트 테이블에서 외래 키로 작동 할 수 없습니다.
Q # 10) 사실이없는 사실에 대한 아이디어를 제공합니까? 그리고 우리는 그것을 왜 사용합니까?
대답: Factless 팩트 테이블은 팩트 측정 값이없는 팩트 테이블입니다. 여기에는 차원 키만 있습니다.
때로는 사실이없는 팩트 테이블이 필요한 비즈니스에서 특정 상황이 발생할 수 있습니다.
예를 들어 직원 출석 기록 시스템을 유지하고 있다고 가정하면 세 개의 키가있는 사실없는 팩트 테이블을 가질 수 있습니다.
| Employee_ID |
| Department_ID |
| Time_ID |
위의 표에는 측정 값이 포함되어 있지 않음을 알 수 있습니다. 이제 아래 질문에 답하고 싶다면 두 개의 개별 팩트 테이블을 사용하는 대신 위의 단일 팩트없는 팩트 테이블을 사용하여 쉽게 수행 할 수 있습니다.
'특정 일에 특정 부서의 직원이 몇 명 있었습니까?'
따라서 사실이없는 팩트 테이블은 설계에 유연성을 제공합니다.
Q # 11) OLTP와 OLAP를 구별합니까?
대답: OLTP는 온라인 거래 처리 시스템 & OLAP는 온라인 분석 처리 시스템 . OLTP는 비즈니스의 트랜잭션 데이터를 유지하고 일반적으로 고도로 정규화됩니다. 반대로 OLAP는 분석 및보고 용이며 비정규 화 된 형태입니다.
OLAP와 OLTP의 이러한 차이점은 스키마 디자인을 선택하는 방법도 제공합니다. 시스템이 OLTP 인 경우 스타 스키마 디자인을 사용해야하고 시스템이 OLAP 인 경우 눈송이 스키마를 사용해야합니다.
Q # 12) 데이터 마트에서 무엇을 이해하고 있습니까?
대답: 데이터 마트는 대부분 독립된 비즈니스 지점을위한 것입니다. 개별 부서를 위해 설계되었습니다.
예를 들어 저는 재무,보고, 판매 등과 같은 여러 부서가있는 건강 보험 회사에서 일했습니다.
우리는이 모든 부서와 관련된 정보를 보관하는 데이터웨어 하우스가 있었고이 데이터웨어 하우스 위에 구축 된 데이터 마트는 거의 없습니다. 이 DataMart는 각 부서에 따라 다릅니다. 간단히 말해서 DataMart가 데이터웨어 하우스의 하위 집합이라고 말할 수 있습니다.
Q # 13) 측정 방법에는 어떤 것이 있습니까?
대답: 세 가지 유형의 측정 값이 있습니다.
- 비가 산 측정
- 반 가산 측정
- 추가 조치
비가 산 측정 값은 집계 함수를 적용 할 수없는 맨 위에있는 측정 값입니다. 예를 들어 비율 또는 백분율 열; Y / N 등과 같은 값을 보유하는 실제로 테이블에있는 플래그 또는 표시기 열은 비가 산적 측정입니다.
반 가산 측정은 일부 (전부는 아님) 집계 함수를 적용 할 수있는 상위 측정입니다. 예를 들어 수수료율 또는 계정 잔액.
추가 측정 값은 모든 집계 함수를 적용 할 수있는 상위 측정 값입니다. 예를 들어 구매 한 단위.
Q # 14) 대리 키란 무엇입니까? 기본 키와 어떻게 다릅니 까?
대답: 대리 키는 기본 키 역할을 할 수있는 고유 식별자 또는 시스템 생성 시퀀스 번호 키입니다. 열 또는 열 조합 일 수 있습니다. 기본 키와 달리 기존 애플리케이션 데이터 필드에서 선택되지 않습니다.
Q # 15) 모든 데이터베이스가 3NF에 있어야한다는 것이 사실입니까?
대답: 데이터베이스가 3NF에 있어야하는 것은 필수가 아닙니다. 하나 , 당신의 목적이 데이터의 손쉬운 유지 관리, 적은 중복성, 효율적인 액세스라면 비정규 화 된 데이터베이스를 사용해야합니다.
Q # 16) 재귀 적 관계의 시나리오를 본 적이 있습니까? 그렇다면 어떻게 처리 했습니까?
대답: 재귀 관계는 엔터티가 자신과 관련된 경우에 발생합니다. 예, 그러한 시나리오를 접했습니다.
건강 관리 영역에 대해 이야기하면 건강 관리 제공자 (예 : 의사)가 다른 건강 관리 제공자의 환자 일 가능성이 있습니다. 때문에 , 의사가 몸이 아파서 수술이 필요한 경우에는 다른 의사를 찾아 가서 수술을 받아야합니다.
그래서 , 이 경우 엔티티 – 의료 서비스 제공자는 자신과 관련이 있습니다. 건강 보험 공급자 번호에 대한 외래 키는 각 가입자 (환자)의 기록에 있어야합니다.
Q # 17) 데이터 모델링 중에 발생하는 몇 가지 일반적인 실수를 나열합니까?
대답: 데이터 모델링 중에 발생하는 몇 가지 일반적인 실수는 다음과 같습니다.
- 방대한 데이터 모델 구축 : 큰 데이터 모델은 더 많은 설계 결함이있는 것과 같습니다. 데이터 모델을 200 개 이하의 테이블로 제한하십시오.
- 목적 부족 : 자신의 비즈니스 솔루션이 무엇을위한 것인지 모르는 경우 잘못된 데이터 모델이 나올 수 있습니다. 따라서 비즈니스 목적을 명확하게하는 것은 올바른 데이터 모델을 만드는 데 매우 중요합니다.
- 대리 키의 부적절한 사용 : 대리 키를 불필요하게 사용해서는 안됩니다. 자연 키가 기본 키의 용도를 제공 할 수없는 경우에만 대리 키를 사용하십시오.
- 불필요한 비정규 화 : 비정규 화는 유지 관리가 어려운 중복 데이터를 생성하므로 확실하고 명확한 비즈니스 이유가없는 한 비정규 화하지 마십시오.
Q # 18) 단일 상위 테이블에서 생성 할 수있는 하위 테이블의 수는 얼마입니까?
대답: 단일 부모 테이블에서 생성 할 수있는 자식 테이블의 수는 키가 아닌 부모 테이블의 필드 / 열 수와 같습니다.
Q # 19) 직원 건강 정보는 의료 제공자가 고용주에게 숨겨져 있습니다. 이것은 어떤 수준의 데이터 숨김입니까? 개념적, 물리적 또는 외부 적?
대답: 이것은 외부 수준의 데이터 숨김 시나리오입니다.
Q # 20) 팩트 테이블과 차원 테이블의 형태는 무엇입니까?
대답: 일반적으로 팩트 테이블은 정규화 된 형식이고 차원 테이블은 비정규 화 된 형식입니다.
Q # 21) 의료 영역 프로젝트에서 개념적 모델을 만들기 위해 필요한 세부 사항은 무엇입니까?
대답: 건강 관리 프로젝트의 경우 아래 세부 사항은 기본 개념 모델을 설계하는 데 필요한 요구 사항으로 충분합니다.
- 다양한 범주의 건강 관리 계획 및 제품.
- 구독 유형 (그룹 또는 개인).
- 의료 서비스 제공자 세트.
- 청구 및 청구 프로세스 개요.
Q # 22) 까다로운 것 : 고유 한 제약 조건이 열에 적용되면 두 개의 null을 삽입하려고하면 오류가 발생합니까?
대답: 아니요,이 경우 null 값이 다른 null 값과 같지 않기 때문에 오류가 발생하지 않습니다. 따라서 오류없이 둘 이상의 null이 열에 삽입됩니다.
Q # 23) 하위 유형 및 수퍼 유형 엔티티의 예를 인용 할 수 있습니까?
대답: 예, 자동차, 자동차, 자전거, 이코노미 자동차, 가족 용 자동차, 스포츠카 등 다양한 개체가 있다고 가정 해 보겠습니다.
여기에서 차량은 슈퍼 유형 개체입니다. 자동차와 자전거는 하위 유형 엔티티입니다. 또한 이코노미 카, 스포츠카, 패밀리 카는 슈퍼 타입 엔터 티카의 하위 타입 엔터티이다.
메이크 파일 C ++ 생성
수퍼 유형 엔티티는 상위 레벨에있는 엔티티입니다. 하위 유형 엔티티는 특정 특성을 기반으로 함께 그룹화 된 엔티티입니다. 예를 들어 모든 자전거는 이륜차이고 모든 자동차는 사륜차입니다. 그리고 둘 다 차량이기 때문에 그들의 슈퍼 유형 개체는 '차량'입니다.
Q # 24) 메타 데이터의 중요성은 무엇입니까?
대답: 메타 데이터는 데이터에 대한 데이터입니다. 시스템에 실제로 어떤 종류의 데이터가 저장되어 있는지, 그 목적은 무엇이며 누구를위한 것인지 알려줍니다.
결론
- 의 실질적인 이해 데이터 모델링 개념과 그것이 당신이 한 과제에 어떻게 부합하는지는 데이터 모델링 인터뷰를 깨기 위해 많이 필요합니다.
- 가장 자주 묻는 주제 데이터 모델링 인터뷰는 – 다양한 유형의 데이터 모델, 스키마 유형, 차원 유형 및 정규화입니다.
- 시나리오 기반 질문에 대해서도 잘 준비하십시오.
면접관에게 질문에 답할 때마다 예를 통해 아이디어를 설명하는 것이 좋습니다. 이것은 당신이 실제로 그 분야에서 일했고 당신은 개념의 핵심을 아주 잘 이해하고 있음을 보여줄 것입니다.
모두 제일 좋다!!