[ DB & SQL(RDBMS, NoSQL) ] 데이터 베이스 기초 이해_02.:RDBMS

▽ 데이터 베이스 기초 이해_02 :RDBMS

1. RDBMS 개요.

---

💬 면접 예상 질문(기본 개념 위주).

1. DBMS와 RDBMS의 차이점은 무엇인가요?

💬 구두 면접형 답변.

"DBMS는 데이터를 파일 형태로 저장하며, 데이터 간의 관계를 명시적으로 정의하지 않습니다.
반면, RDBMS는 데이터를 테이블 형태로 저장하고,
테이블 간의 관계를 명확히 정의하여 데이터 무결성과 중복 방지를 지원합니다."

📝 기술 블로그용 서술형 정리

• DBMS(Database Management System)는

  • 데이터를 파일 시스템에 저장하며, 데이터 간의 관계를 명시적으로 정의하지 않습니다.
  • 이로 인해 데이터 중복과 무결성 문제가 발생할 수 있습니다.

• RDBMS(Relational Database Management System)는

  • 데이터를 테이블 형태로 저장하고, 테이블 간의 관계를 명확히 정의합니다.
  • 이를 통해 데이터 무결성을 유지하고 중복을 최소화할 수 있습니다.
  • 또한, RDBMS는 SQL을 사용하여 데이터에 접근하며,
    트랜잭션 관리와 동시성 제어 등의 기능을 제공합니다.

2. 관계형 데이터 모델이란 무엇인가요?

💬 구두 면접형 답변.

"관계형 데이터 모델은 데이터를 테이블 형태로 표현하며, 각 테이블은 행과 열로 구성됩니다.
테이블 간의 관계를 정의하여 데이터를 구조화하고, SQL을 통해 데이터를 관리합니다."

📝 기술 블로그용 서술형 정리.

• 관계형 데이터 모델은 데이터를 테이블 형태로 표현하는 데이터 모델입니다.
• 각 테이블은 행(레코드)과 열(속성)로 구성되며, 테이블 간의 관계를 정의하여 데이터를 구조화합니다. - 이 모델은 SQL을 통해 데이터를 관리하며, 데이터 무결성과 중복 방지를 지원합니다.

3. 테이블, 레코드, 칼럼의 의미를 각각 설명해주세요.

💬 구두 면접형 답변.

"테이블은 데이터를 저장하는 구조로, 행과 열로 구성됩니다.
각 행은 레코드로, 하나의 데이터 항목을 나타내며, 각 열은 칼럼으로, 데이터의 속성을 나타냅니다."

📝 기술 블로그용 서술형 정리.

• 테이블(Table): 데이터를 저장하는 구조로, 행과 열로 구성됩니다.
• 레코드(Record): 테이블의 각 행으로, 하나의 데이터 항목을 나타냅니다.
• 칼럼(Column): 테이블의 각 열로, 데이터의 속성을 나타냅니다.

4. 기본 키(Primary Key)의 개념과 역할은?

💬 구두 면접형 답변.

"기본 키는 테이블에서 각 레코드를 고유하게 식별하는 열입니다.
중복되거나 NULL 값을 가질 수 없습니다."

📝 기술 블로그용 서술형 정리.

• 기본 키(Primary Key)는 테이블에서 각 레코드를 고유하게 식별하는 열입니다.
• 기본 키는 중복되거나 NULL 값을 가질 수 없으며, 테이블에 하나만 존재할 수 있습니다.
• 기본 키는 외래 키(Foreign Key)를 통해 다른 테이블과의 관계를 정의하는 데 사용됩니다.

5. 외래 키(Foreign Key)는 무엇인가요?

💬 구두 면접형 답변.

"외래 키는 다른 테이블의 기본 키를 참조하는 열로,
테이블 간의 관계를 정의하고 데이터 무결성을 유지합니다."

📝 기술 블로그용 서술형 정리.

• 외래 키(Foreign Key)는 다른 테이블의 기본 키를 참조하는 열로, 테이블 간의 관계를 정의합니다.
• 외래 키는 참조 무결성을 유지하여, 참조된 데이터가 삭제되거나 변경될 때 일관성을 보장합니다.

6. 릴레이션(Relation)이란 무엇인가요?

💬 구두 면접형 답변.

"릴레이션은 관계형 데이터베이스에서 데이터를 저장하는 테이블을 의미합니다.
각 릴레이션은 행과 열로 구성되며, 행은 레코드, 열은 속성을 나타냅니다."

📝 기술 블로그용 서술형 정리.

• 릴레이션(Relation)은 관계형 데이터베이스에서 데이터를 저장하는 기본 구조로, 테이블(Table)이라고도 합니다.
• 각 릴레이션은 행(Row)과 열(Column)로 구성되며, 행은 개별 데이터 항목(레코드)을,
  열은 데이터의 속성(필드)을 나타냅니다.
• 릴레이션은 데이터 간의 관계를 명확히 정의하고, 중복을 최소화하며,
  데이터 무결성을 유지하는 데 중요한 역할을 합니다.

7. RDBMS의 장점은 무엇인가요?

💬 구두 면접형 답변.

"RDBMS는 데이터 무결성과 일관성을 유지하며, SQL을 통해 효율적인 데이터 관리가 가능합니다.
또한, 데이터 중복을 줄이고, 보안과 동시성 제어를 지원합니다."

📝 기술 블로그용 서술형 정리.

관계형 데이터베이스 관리 시스템(RDBMS)의 주요 장점은 다음과 같습니다:

• 데이터 무결성 유지:
  • 제약 조건(Constraints)을 통해 데이터의 정확성과 일관성을 보장합니다.
• 효율적인 데이터 관리:
  • SQL을 사용하여 데이터의 삽입, 수정, 삭제, 조회 등을 효율적으로 수행할 수 있습니다.
• 데이터 중복 최소화:
  • 정규화를 통해 데이터의 중복을 줄이고, 저장 공간을 효율적으로 사용합니다.
• 보안 및 동시성 제어:
  • 사용자 권한 관리와 트랜잭션 제어를 통해 데이터의 보안과 다중 사용자 환경에서의 일관성을 유지합니다.

8. 스키마(Schema)의 개념을 설명해주세요.

💬 구두 면접형 답변.

"스키마는 데이터베이스의 구조를 정의하는 청사진으로, 테이블, 열, 데이터 타입, 제약 조건 등을 포함합니다."

📝 기술 블로그용 서술형 정리.

스키마(Schema)는 데이터베이스의 구조를 정의하는 메타데이터로,
데이터베이스 내의 객체들(테이블, 뷰, 인덱스 등)의 구성과 관계를 명시합니다.
스키마는 다음과 같은 요소를 포함합니다:

• 테이블 구조:

  • 테이블의 이름, 열(Column)의 이름과 데이터 타입, 기본 키 및 외래 키 등의 제약 조건

• 관계 정의:

  • 테이블 간의 관계 및 참조 무결성 제약 조건

• 보안 설정:

  • 사용자 권한 및 접근 제어 설정

스키마는 데이터베이스의 설계와 유지 관리에 있어 중요한 역할을 하며,
데이터의 일관성과 무결성을 유지하는 데 기여합니다.

9. ERD(Entity-Relationship Diagram)란 무엇인가요?

💬 구두 면접형 답변.

"ERD는 엔터티와 그들 간의 관계를 시각적으로 표현한 다이어그램으로, 데이터베이스 설계 시 구조를 이해하고 계획하는 데 사용됩니다."

📝 기술 블로그용 서술형 정리.

ERD(Entity-Relationship Diagram)는 데이터베이스의 구조를 시각적으로 표현한 다이어그램으로, 엔터티(Entity), 속성(Attribute), 관계(Relationship)를 나타냅니다.

ERD는 다음과 같은 요소로 구성됩니다:

• 엔터티(Entity):

  • 데이터베이스에서 관리하는 객체나 개체를 나타내며, 직사각형으로 표현됩니다.

• 속성(Attribute):

  • 엔터티의 특성을 나타내며, 타원형으로 표현됩니다.

• 관계(Relationship):

  • 엔터티 간의 연관성을 나타내며, 마름모형으로 표현됩니다.

ERD는 데이터베이스 설계 초기 단계에서 요구사항을 분석하고,
데이터 구조를 계획하는 데 유용한 도구입니다.

10. DBMS의 언어(DML, DDL, DCL, TCL)의 차이는 무엇인가요?

💬 구두 면접형 답변.

"DBMS 언어는 DML, DDL, DCL, TCL로 구분됩니다.
DML은 데이터 조작, DDL은 구조 정의, DCL은 권한 제어, TCL은 트랜잭션 제어를 담당합니다."

📝 기술 블로그용 서술형 정리.

DBMS에서 사용하는 언어는 기능에 따라 다음과 같이 구분됩니다:

• DML(Data Manipulation Language):

  • 데이터를 조회, 삽입, 수정, 삭제하는 데 사용됩니다.
  • 예: SELECT, INSERT, UPDATE, DELETE

• DDL(Data Definition Language):

  • 데이터베이스 객체를 생성, 수정, 삭제하는 데 사용됩니다.
  • 예: CREATE, ALTER, DROP

• DCL(Data Control Language):

  • 사용자 권한을 부여하거나 회수하는 데 사용됩니다.
  • 예: GRANT, REVOKE

• TCL(Transaction Control Language):

  • 트랜잭션의 시작, 종료, 롤백 등을 제어하는 데 사용됩니다.
  • 예: COMMIT, ROLLBACK, SAVEPOINT

각 언어는 데이터베이스의 다양한 측면을 관리하고 제어하는 데 필수적인 역할을 합니다.

11. 제약조건(Constraints)의 종류와 역할은?

💬 구두 면접형 답변.

"제약조건은 데이터의 무결성과 정확성을 유지하기 위해 사용됩니다.
주요 제약조건으로는 NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK, DEFAULT 등이 있습니다."

📝 기술 블로그용 서술형 정리.

제약조건(Constraints)은 데이터베이스에서 데이터의 정확성과 일관성을 보장하기 위해 사용되는 규칙입니다.

주요 제약조건은 다음과 같습니다:

• NOT NULL: 열에 NULL 값을 허용하지 않음.

• UNIQUE: 열의 모든 값이 고유해야 함.

• PRIMARY KEY: 테이블의 각 행을 고유하게 식별하는 열.

• FOREIGN KEY: 다른 테이블의 PRIMARY KEY를 참조하여 테이블 간의 관계를 정의.

• CHECK: 열의 값이 특정 조건을 만족해야 함.

• DEFAULT: 열에 기본값을 설정.

이러한 제약조건은 데이터의 무결성을 유지하고, 잘못된 데이터 입력을 방지하는 데 중요한 역할을 합니다.

12. 데이터 무결성이란 무엇인가요?

💬 구두 면접형 답변.

"데이터 무결성은 데이터의 정확성, 일관성, 신뢰성을 유지하는 것을 의미합니다.
이를 위해 제약조건과 트랜잭션 관리 등이 사용됩니다."

📝 기술 블로그용 서술형 정리.

데이터 무결성(Data Integrity)은 데이터의 정확성, 일관성, 신뢰성을 유지하는 것을 의미합니다.

주요 무결성 유형은 다음과 같습니다.

• 엔터티 무결성: 테이블의 각 행이 고유하게 식별되어야 함.

• 참조 무결성: 외래 키가 참조하는 기본 키가 존재해야 함.

• 도메인 무결성: 열의 값이 정의된 도메인 내에 있어야 함.

데이터 무결성을 유지하기 위해 제약조건, 트랜잭션 관리, 백업 및 복구 전략 등이 활용됩니다.

13. RDBMS에서 NULL은 어떤 의미인가요?

💬 구두 면접형 답변.

"NULL은 데이터가 존재하지 않거나 알 수 없음을 나타내는 특수한 값입니다.
이는 0이나 빈 문자열과는 다릅니다."

📝 기술 블로그용 서술형 정리.

RDBMS에서 NULL은 데이터가 존재하지 않거나 알 수 없음을 나타내는 특수한 값입니다.

이는 다음과 같은 특징을 가집니다:

• 0이나 빈 문자열과 다름:

  • NULL은 값이 없음을 의미하며, 0이나 빈 문자열은 실제 값을 가진 것입니다.

• 연산 시 주의 필요:

  • NULL과의 연산 결과는 대부분 NULL이 되므로, IS NULL 또는 IS NOT NULL을 사용하여 NULL 값을 처리해야 합니다.

• 데이터 무결성에 영향:

  • NULL 값은 제약조건에 따라 허용되지 않을 수 있으며, 데이터 분석 시 주의가 필요합니다.

데이터 무결성을 유지하기 위해 제약조건, 트랜잭션 관리, 백업 및 복구 전략 등이 활용됩니다.

14. 관계형 모델에서 데이터 중복을 줄이는 원리는?

💬 구두 면접형 답변.

"정규화를 통해 데이터를 여러 테이블로 분리하고, 중복을 최소화하여 데이터 일관성을 유지합니다."

📝 기술 블로그용 서술형 정리.

관계형 모델에서 데이터 중복을 줄이기 위한 주요 원리는 정규화(Normalization)입니다.

정규화를 통해 다음과 같은 이점을 얻을 수 있습니다:

• 데이터 중복 최소화:

  • 동일한 데이터의 반복 저장을 방지하여 저장 공간을 절약하고, 데이터 일관성을 유지합니다.

• 데이터 무결성 향상:

  • 중복된 데이터로 인한 불일치 문제를 방지합니다.

• 유지보수 용이성:

  • 데이터 구조가 명확해져 변경 시 영향 범위를 쉽게 파악할 수 있습니다.

정규화는 일반적으로 제1정규형(1NF)부터 제3정규형(3NF)까지 적용되며,
필요에 따라 더 높은 정규형을 적용할 수 있습니다.

15. 정규화는 왜 필요한가요?

💬 구두 면접형 답변.

"정규화를 통해 데이터를 여러 테이블로 분리하고, 중복을 최소화하여 데이터 일관성을 유지합니다."

📝 기술 블로그용 서술형 정리.

정규화(Normalization)는 데이터베이스 설계 시 데이터를 구조화하여 중복을 최소화하고,
데이터 무결성을 유지하기 위한 과정입니다.

정규화의 주요 목적은 다음과 같습니다:

• 데이터 중복 제거:

  • 동일한 데이터를 여러 곳에 저장하지 않도록 하여 저장 공간을 절약하고, 데이터 일관성을 유지합니다.

• 데이터 무결성 유지:

  • 데이터의 일관성과 정확성을 보장하여 오류를 방지합니다.

• 데이터 구조의 명확화:

  • 데이터 간의 관계를 명확히 하여 유지보수와 확장성을 향상시킵니다.

정규화는 일반적으로 제1정규형(1NF)부터 제3정규형(3NF)까지 적용되며,
필요에 따라 더 높은 정규형을 적용할 수 있습니다.

16. 관계형 모델에서 테이블 간의 관계는 어떻게 표현하나요?

💬 구두 면접형 답변.

"테이블 간의 관계는 외래 키(Foreign Key)를 사용하여 표현합니다.
이를 통해 테이블 간의 연관성을 정의하고, 데이터 무결성을 유지할 수 있습니다."

📝 기술 블로그용 서술형 정리.

관계형 모델에서 테이블 간의 관계는 외래 키(Foreign Key)를 사용하여 표현합니다.

외래 키는 한 테이블의 열이 다른 테이블의 기본 키(Primary Key)를 참조하도록 설정하여,
두 테이블 간의 연관성을 정의합니다.

이를 통해 다음과 같은 이점을 얻을 수 있습니다:

• 데이터 무결성 유지:

  • 참조된 데이터가 존재해야만 데이터를 삽입하거나 수정할 수 있어, 데이터의 일관성을 보장합니다.

• 복잡한 쿼리 작성 가능:

  • 여러 테이블 간의 관계를 기반으로 JOIN 연산 등을 통해 복잡한 데이터를 조회할 수 있습니다.

• 데이터 구조의 명확화:

  • 테이블 간의 관계를 명확히 하여 데이터베이스 설계와 유지보수를 용이하게 합니다.

17. 1:1, 1:N, N:M 관계의 차이점은?

💬 구두 면접형 답변.

"1:1은 두 테이블의 각 행이 서로 하나씩만 연결되는 관계, 1:N은 한 테이블의 한 행이 다른 테이블의 여러 행과 연결되는 관계, N:M은 두 테이블의 여러 행이 서로 여러 행과 연결되는 관계입니다."

📝 기술 블로그용 서술형 정리.

관계형 데이터베이스에서 테이블 간의 관계는 다음과 같이 분류됩니다:

• 1:1 관계(One-to-One):

  • 두 테이블의 각 행이 서로 하나씩만 연결되는 관계. 예: 사용자와 사용자 프로필.

• 1:N 관계(One-to-Many):

  • 한 테이블의 한 행이 다른 테이블의 여러 행과 연결되는 관계. 예: 고객과 주문.

• N:M 관계(Many-to-Many):

  • 두 테이블의 여러 행이 서로 여러 행과 연결되는 관계. 예: 학생과 수업.

  N:M 관계는 일반적으로 중간 테이블을 생성하여 두 개의 1:N 관계로 분해하여 구현합니다.

18. 데이터베이스와 파일 시스템의 차이는?

💬 구두 면접형 답변.

"파일 시스템은 데이터를 단순히 파일로 저장하는 반면,
데이터베이스는 데이터를 구조화하여 저장하고, 효율적인 검색, 보안, 동시성 제어 등을 제공합니다."

📝 기술 블로그용 서술형 정리.

파일 시스템과 데이터베이스의 주요 차이점은 다음과 같습니다:

• 데이터 구조화:

  • 파일 시스템은 데이터를 비구조화된 형태로 저장하는 반면,
    데이터베이스는 데이터를 테이블 형태로 구조화하여 저장합니다.

• 데이터 무결성 및 보안:

  • 데이터베이스는 제약조건과 권한 관리를 통해 데이터 무결성과 보안을 유지할 수 있습니다.

• 동시성 제어:

  • 데이터베이스는 다중 사용자가 동시에 데이터를 접근하거나 수정할 때 충돌을 방지하는 메커니즘을 제공합니다.

• 효율적인 검색 및 관리:

  • 데이터베이스는 인덱스, 쿼리 최적화 등을 통해 대량의 데이터를 효율적으로 검색하고 관리할 수 있습니다.

19. 데이터베이스 키 종류(슈퍼키, 후보키 등)를 설명해주세요.

💬 구두 면접형 답변.

"슈퍼키는 테이블의 각 행을 고유하게 식별할 수 있는 모든 키의 집합이며,
후보키는 최소한의 속성으로 구성된 슈퍼키입니다. 기본 키는 후보키 중에서 선택된 키입니다."

📝 기술 블로그용 서술형 정리.

데이터베이스에서 키(Key)는 테이블의 각 행을 고유하게 식별하기 위해 사용됩니다.

주요 키의 종류는 다음과 같습니다:

• 슈퍼키(Super Key): 테이블의 각 행을 고유하게 식별할 수 있는 속성의 집합.

• 후보키(Candidate Key): 최소한의 속성으로 구성된 슈퍼키.

• 기본 키(Primary Key): 후보키 중에서 선택된 키로, 테이블의 각 행을 고유하게 식별.

• 대체 키(Alternate Key): 기본 키로 선택되지 않은 후보키.

• 외래 키(Foreign Key): 다른 테이블의 기본 키를 참조하는 키로, 테이블 간의 관계를 정의.

20. 뷰(View)는 무엇이고 어떤 경우에 사용하나요?

💬 구두 면접형 답변.

"뷰(View)는 하나 이상의 테이블에서 데이터를 조회하는 SQL 쿼리를 저장한 가상의 테이블입니다.
실제 데이터를 저장하지 않고, 호출 시 정의된 쿼리를 실행하여 결과를 제공합니다.
주로 복잡한 쿼리를 단순화하거나,
특정 데이터에 대한 접근을 제한하는 보안 목적, 그리고 데이터 추상화를 위해 사용됩니다."

📝 기술 블로그용 서술형 정리.

뷰(View)는 SQL에서 하나 이상의 테이블로부터 데이터를 조회하는 쿼리를 저장한 가상의 테이블입니다.
실제 데이터를 저장하지 않으며, 뷰를 호출할 때마다 정의된 쿼리를 실행하여 결과를 제공합니다.

뷰는 다음과 같은 상황에서 유용하게 사용됩니다:

• 복잡한 쿼리의 단순화:

  • 자주 사용되는 복잡한 조인이나 조건을 뷰로 정의하여,
    반복적인 쿼리 작성을 줄이고 가독성을 높일 수 있습니다.

• 데이터 보안 강화:

  • 특정 컬럼이나 행만을 포함하는 뷰를 생성하여,
    사용자가 민감한 데이터에 직접 접근하지 못하도록 제한할 수 있습니다.

• 데이터 추상화:

  • 테이블의 구조 변경이 있더라도,
    뷰를 통해 일관된 데이터 인터페이스를 제공하여 애플리케이션의 수정 없이도 대응할 수 있습니다.

• 논리적 데이터 분할:

  • 대규모 테이블에서 특정 조건에 맞는 데이터만을 뷰로 제공하여,
    성능을 향상시키고 관리의 편의성을 높일 수 있습니다.

💬 면접 예상 질문(실무적인 요소 위주).

1. RDBMS를 선택할 때 어떤 요소들을 고려하시나요?

💬 구두 면접형 답변.

"RDBMS를 선택할 때는 프로젝트의 요구사항, 데이터의 구조와 복잡성, 확장성, 성능, 보안, 커뮤니티 지원 등을 종합적으로 고려합니다.
예를 들어, 트랜잭션이 중요한 시스템에서는 ACID 특성을 잘 지원하는 RDBMS를 선택해야하고,
대규모 데이터를 처리해야 하는 경우에는 확장성이 뛰어난 시스템을 선택해야합니다."

📝 기술 블로그용 서술형 정리.

RDBMS를 선택할 때 고려해야 할 주요 요소는 다음과 같습니다:

• 프로젝트 요구사항:

  • 데이터의 구조, 트랜잭션 처리 필요성, 동시 접속자 수 등을 분석하여 적합한 RDBMS를 선택합니다.

• 성능 및 확장성:

  • 데이터의 양과 처리 속도에 따라 수평적 또는 수직적 확장이 가능한 시스템을 고려합니다.

• 보안:

  • 데이터 암호화, 접근 제어, 감사 로그 등의 보안 기능을 지원하는지를 확인합니다.

• 커뮤니티 및 지원:

  • 활발한 커뮤니티와 공식 지원이 있는 RDBMS는 문제 해결과 유지보수에 유리합니다.

• 비용:

  • 라이선스 비용, 유지보수 비용 등을 고려하여 예산에 맞는 RDBMS를 선택합니다.

2. 프로젝트에서 스키마 설계 시 고려하는 우선순위는?

💬 구두 면접형 답변.

"스키마 설계 시에는 먼저 데이터의 무결성과 일관성을 유지하는 것을 최우선으로 고려합니다. 그 다음으로는 성능 최적화, 확장성, 유지보수 용이성 등을 순차적으로 고려하여 설계를 진행해야 합니다."

📝 기술 블로그용 서술형 정리.

• 데이터 무결성 및 일관성:

  • 정규화를 통해 데이터 중복을 최소화하고, 제약 조건을 설정하여 데이터의 정확성을 확보합니다.

• 성능 최적화:

  • 인덱스 설정, 파티셔닝 등을 통해 쿼리 성능을 향상시킵니다.

• 확장성:

  • 미래의 데이터 증가를 고려하여 스키마를 유연하게 설계합니다.

• 유지보수 용이성:

  • 명확한 명명 규칙과 문서화를 통해 향후 유지보수를 용이하게 합니다.

• 보안:

  • 민감한 데이터에 대한 접근 제어와 암호화를 고려합니다.

3. 외래 키 제약조건을 생략하는 상황은 언제인가요?

💬 구두 면접형 답변.

"외래 키 제약조건은 데이터 무결성을 보장하지만, 성능이 중요한 시스템에서는 생략하기도 합니다.
예를 들어, 대용량 데이터의 일괄 삽입이나 삭제가 빈번한 경우, 외래 키 제약조건이 오버헤드가 될 수 있어 생략하는 경우가 있습니다."

📝 기술 블로그용 서술형 정리.

외래 키 제약조건을 생략하는 상황은 다음과 같습니다:

• 성능 최적화 필요 시:

  • 대량의 데이터를 빠르게 삽입하거나 삭제해야 하는 경우, 외래 키 제약조건이 성능 저하를 일으킬 수 있습니다.

• 데이터 무결성을 애플리케이션에서 관리하는 경우:

  • 비즈니스 로직에서 데이터의 일관성을 관리하는 경우, 데이터베이스 수준의 제약조건을 생략할 수 있습니다.

• 임시 테이블 사용 시:

  • 일시적인 데이터 저장을 위한 테이블에서는 외래 키 제약조건이 필요하지 않을 수 있습니다.

4. ERD를 설계할 때 사용하는 툴과 팁은?

💬 구두 면접형 답변.

"ERD 설계 시에는 Lucidchart, draw.io, ER/Studio 등과 같은 도구를 사용합니다.
설계 시에는 명확한 명명 규칙을 적용하고, 관계를 시각적으로 명확하게 표현하여 이해도를 높입니다."

📝 기술 블로그용 서술형 정리.

ERD 설계에 유용한 도구와 팁은 다음과 같습니다:

• 도구:

  • Lucidchart: 협업 기능이 뛰어나고 다양한 템플릿을 제공합니다.

  • draw.io: 무료로 사용 가능하며, Google Drive와 연동이 가능합니다.

  • ER/Studio: 전문적인 데이터베이스 설계 기능을 제공합니다.

• 설계 팁:

  • 명확한 명명 규칙 적용: 테이블 및 컬럼 이름에 일관된 규칙을 적용하여 가독성을 높입니다.

  • 관계 명확히 표현: 1:1, 1:N, N:M 관계를 정확하게 표현하여 데이터 구조를 명확히 합니다.

  • 주석 활용: 각 요소에 대한 설명을 주석으로 추가하여 이해를 돕습니다.

5. 데이터 무결성 유지가 어려운 상황은?

💬 구두 면접형 답변.

"분산 시스템이나 동시성이 높은 환경에서는 데이터 무결성을 유지하기 어렵습니다.
이러한 경우에는 트랜잭션 관리나 애플리케이션 수준의 검증 로직을 통해 무결성을 보장해야합니다.

📝 기술 블로그용 서술형 정리.

데이터 무결성 유지가 어려운 상황은 다음과 같습니다:

• 분산 시스템:

  • 여러 노드에 데이터가 분산되어 있는 경우, 동기화 문제로 무결성 유지가 어렵습니다.

• 높은 동시성 환경:

  • 다수의 사용자가 동시에 데이터를 수정하는 경우, 충돌이 발생할 수 있습니다.

• 복잡한 비즈니스 로직:

  • 데이터베이스 제약조건만으로는 복잡한 비즈니스 규칙을 모두 적용하기 어려울 수 있습니다.

이러한 상황에서는
트랜잭션 관리, 애플리케이션 수준의 검증 로직, 정기적인 데이터 검증 작업 등을 통해
무결성을 유지합니다.

6. RDBMS 구조 상 병목 현상이 자주 발생하는 부분은?

💬 구두 면접형 답변.

"병목 현상은 주로 인덱스 미사용, 비효율적인 쿼리, 락 경합 등에서 발생합니다.
이를 해결하기 위해 쿼리 최적화, 인덱스 설계, 트랜잭션 관리 등을 수행합니다."

📝 기술 블로그용 서술형 정리.

RDBMS에서 병목 현상이 자주 발생하는 부분은 다음과 같습니다:

• 인덱스 미사용:

  • 적절한 인덱스가 없으면 검색 속도가 느려집니다.

• 비효율적인 쿼리:

  • 불필요한 조인이나 서브쿼리는 성능 저하를 초래합니다.

• 락 경합:
  동시성 제어를 위한 락이 과도하게 발생하면 성능이 저하됩니다.

이러한 병목 현상을 해결하기 위해서는
쿼리 최적화, 적절한 인덱스 설계, 트랜잭션 격리 수준 조정 등을 고려해야 합니다.

7. 시스템에서 테이블 분할(샤딩, 파티셔닝)을 고려한다면?

💬 구두 면접형 답변.

"데이터 양이 많아지고 성능 요구사항이 높아질 때 테이블 분할을 고려합니다.
샤딩은 수평 분할을 통해 데이터베이스를 여러 서버에 분산시키고,
파티셔닝은 테이블을 논리적으로 분할하여 관리합니다."

📝 기술 블로그용 서술형 정리.

테이블 분할을 고려해야 하는 상황과 방법은 다음과 같습니다:

• 샤딩(Sharding):

  • 정의: 데이터베이스를 수평으로 분할하여 여러 서버에 분산 저장하는 방식입니다.

  • 적용 시점: 데이터가 매우 많고, 단일 서버로 처리하기 어려운 경우. 지역별 사용자, 고객 ID 기반 분할 등.

  • 장점: 수평적 확장 가능, 부하 분산.

  • 단점: 트랜잭션 관리 및 조인 연산이 복잡해짐.

• 파티셔닝(Partitioning):

  • 정의: 하나의 테이블을 논리적으로 여러 파티션으로 나누는 방식 (예: 날짜, 범위, 해시 기반).

  • 적용 시점: 특정 컬럼 기반으로 데이터 접근이 집중되는 경우 (예: 시간별 로그).

  • 장점: 쿼리 성능 향상, 관리 용이.

  • 단점: 파티션 키 설계가 중요, 데이터 불균형 시 오히려 성능 저하.

8. RDBMS에서 대용량 데이터를 저장할 때 주의할 점은?

💬 구두 면접형 답변.

"대용량 데이터 저장 시에는 인덱스 관리, 파티셔닝, 백업 전략, 아카이빙 전략 등을 함께 고려합니다.
읽기/쓰기 성능을 유지하기 위한 설계가 중요하며, 이로 인해 테이블 구조나 쿼리 방식도 달라집니다."

📝 기술 블로그용 서술형 정리.

대용량 데이터를 저장할 때 고려해야 할 핵심 요소는 다음과 같습니다:

• 인덱스 최적화:
  과도한 인덱스는 쓰기 성능을 저하시킬 수 있으므로 꼭 필요한 인덱스만 유지합니다.

• 파티셔닝 또는 샤딩 도입:
  데이터의 접근 패턴과 분포를 고려하여 논리적 또는 물리적으로 분할합니다.

• 백업 및 복구 전략 수립:
  장애 시 빠른 복구를 위한 백업 주기 및 저장 정책을 수립해야 합니다.

• 아카이빙:
  오래된 데이터를 별도로 저장하여 운영 DB의 부하를 줄입니다.

• 쓰기/읽기 분리:
  Master/Replica 구조를 도입해 읽기 요청을 분산시킵니다.

9. 트랜잭션과의 관계 속에서 데이터 정합성을 보장하는 방법은?

💬 구두 면접형 답변.

"정합성을 보장하기 위해 트랜잭션의 원자성, 격리성 수준을 적절히 설정하고, 에러 발생 시 롤백 처리를 통해 데이터 손상을 방지합니다.
또한 데이터 상태를 체크하는 검증 로직도 중요합니다."

📝 기술 블로그용 서술형 정리.

데이터 정합성을 보장하기 위해 고려해야 할 트랜잭션 관련 요소:

• ACID 원칙 준수:

  • 원자성: 모든 작업은 전부 성공하거나 전부 실패해야 함.

  • 일관성: 트랜잭션 수행 전후 상태가 모두 유효한 상태여야 함.

  • 격리성: 동시 수행되는 트랜잭션이 서로 영향을 주지 않도록 함.

  • 지속성: 커밋된 트랜잭션 결과는 영구 저장됨.

• 격리 수준 선택 (Isolation Level):

  • Read Uncommitted → Read Committed → Repeatable Read → Serializable 순으로 강도가 높아짐.

• 검증 로직:

  • 트랜잭션 전/후 상태 검증, 비즈니스 로직 기반 제약 체크.

10. 정규화를 포기하게 되는 이유는?

💬 구두 면접형 답변.

" 읽기 성능 향상이나 쿼리 단순화를 위해 정규화를 일부 포기하기도 합니다. 특히 리포트 쿼리처럼 조인이 많아지는 상황에서는 반정규화가 유리할 수 있습니다."

📝 기술 블로그용 서술형 정리.

정규화를 포기하거나 반정규화를 적용하는 대표적인 이유:

• 성능 최적화:

  • 조인 연산이 많고 쿼리가 복잡해지는 경우, 성능을 위해 데이터를 중복 저장.

• 읽기 위주의 시스템:

  • 조회 성능이 중요한 경우, 중복을 허용하고 데이터를 한 번에 가져오도록 설계.

• 데이터 모델이 안정적일 경우:

  • 변경 가능성이 낮은 경우에는 중복 저장에 따른 유지 비용이 낮음.

• 데이터 일관성을 비즈니스 로직으로 보장할 수 있는 경우

11. 관계형 DB 사용 중 발생가능한 성능 이슈는 무엇이고, 해결법은?

💬 구두 면접형 답변.

“대표적인 성능 이슈로는 인덱스 미사용, 느린 쿼리, N+1 문제, 락 경합 등이 있습니다.
이를 해결하기 위해 실행계획(EXPLAIN)으로 병목을 분석하고, 인덱스를 최적화하며,
ORM 사용 시 select_related나 join fetch를 적극 활용합니다.
또한 커넥션 풀을 적절히 조정하고 쿼리 리팩토링도 병행합니다.”

📝 기술 블로그용 서술형 정리.

관계형 데이터베이스(RDBMS)를 사용할 때 흔히 발생하는 성능 이슈는 다음과 같습니다:

• 인덱스 미사용 또는 부적절한 인덱스 설계

  • 쿼리 조건이 인덱스를 타지 않으면 Full Table Scan 발생

  • 해결: 복합 인덱스 / 커버링 인덱스 활용, 실행계획(EXPLAIN) 분석

• N+1 문제 (ORM 연동 시)

  • 지연 로딩으로 인해 루프마다 추가 쿼리 실행

  • 해결: JOIN FETCH, select_related, eager loading 사용

• 락 경합(Lock Contention)

  • 동시성 이슈로 인한 대기 → 성능 저하

  • 해결: 트랜잭션 범위 축소, 격리 수준 조정

• 쿼리 복잡도 증가 (JOIN, Subquery)

  • 불필요한 연산, 스캔 증가

  • 해결: 쿼리 리팩토링, 뷰(View) 또는 CTE(Common Table Expressions) 사용

• Connection Pool 한계

  • 동시 접속자가 많을 때 병목

  • 해결: 커넥션 풀 크기 조절, ORM 설정 튜닝

12. 스키마 변경이 시스템에 미치는 영향은 어떻게 관리하나요?

💬 구두 면접형 답변.

“스키마 변경은 애플리케이션 로직과 밀접하게 연관되어 있어 장애로 이어질 수 있습니다.
따라서 마이그레이션 툴(예: Flyway, Liquibase)을 활용해 버전 관리하고,
CI/CD 파이프라인에 포함시켜 사전 테스트와 단계적 배포로 위험을 최소화합니다.”

📝 기술 블로그용 서술형 정리.

스키마 변경(DDL)은 데이터 정합성과 애플리케이션 동작에 직결되므로 아래 전략으로 대응합니다:

• 마이그레이션 툴 사용: Flyway, Liquibase 등으로 DDL 버전 관리

• Zero Downtime 전략:

  • 신규 컬럼은 nullable로 추가 → 코드 반영 → 배포 후 NOT NULL 전환

  • 컬럼 삭제는 단계적으로(deprecated → 제거)

• 테스트 환경 검증 및 Rollback 가능성 확보

• CI/CD 파이프라인에 포함하여 사전 자동화 테스트 적용

13. 스키마 버저닝 전략 어떻게 운영해야할까?

💬 구두 면접형 답변.

“스키마는 코드와 함께 버전 관리되어야 하며, Flyway나 Liquibase를 통해 마이그레이션 스크립트를 적용하고, 버전 순서대로 자동 적용되도록 구성합니다.
Git과 연계하여 코드 변경과 DB 변경이 동일 커밋에 포함되도록 유지합니다.”

📝 기술 블로그용 서술형 정리.

스키마 버저닝 전략은 다음 원칙에 기반합니다:

• 버전 명명 규칙(V1init.sql, V2add_column.sql 등)

• DDL 파일을 Git으로 버전 관리하여 이력 추적 가능

• CI/CD 통합: 배포 시점에 DB 마이그레이션 자동 적용

• Down Migration 스크립트 별도 관리 (롤백 대응)

14. ORM을 사용할 때 관계형 모델과 충돌하는 경우는??

💬 구두 면접형 답변.

“ORM은 객체지향과 정규화된 관계형 모델 간의 간극이 존재합니다.
예를 들어 다대다 관계는 중간 테이블이 필요하지만 ORM에서는 직접적인 매핑이 어려울 수 있어,
명시적 엔티티로 모델링합니다. 또, Lazy Loading이 성능 문제를 유발할 수 있습니다.”

📝 기술 블로그용 서술형 정리.

ORM은 편리하지만 다음과 같은 관계형 모델과의 충돌 문제가 있습니다:

• 다대다(M:N) 관계

  • ORM에서 중간 테이블을 숨기면 추적 불가능한 구조 발생

  • 해결: 중간 테이블을 명시적으로 JoinTable 또는 별도 엔티티로 구성

• Lazy vs Eager Loading

  • Lazy는 지연 로딩으로 성능 저하, Eager는 과도한 Join

  • 해결: 상황에 따라 Fetch 전략 선택 + 쿼리 최적화

• 객체 상속 구조 vs 테이블 정규화 불일치

  • ORM에서 상속을 표현하기 어려움 (단일 테이블, 조인 전략 등)

15. 동시성 문제를 방지하기 위한 DB 설계 전략은?

💬 구두 면접형 답변.

“낙관적 락(Optimistic Locking)을 활용해 버전 필드 기반 충돌을 감지하거나, 비관적 락(Pessimistic Locking)으로 업데이트를 제어합니다. 트랜잭션 격리 수준 조정과 인덱스를 통한 범위 락 최소화도 전략 중 하나입니다."

📝 기술 블로그용 서술형 정리.

동시성 문제를 방지하는 주요 설계 전략:

• Optimistic Locking:

  • version 컬럼 사용 → 변경 시 충돌 여부 확인

• Pessimistic Locking:

  • SELECT ... FOR UPDATE 사용하여 행 단위 Lock

• 트랜잭션 격리 수준 관리

  • READ COMMITTED, REPEATABLE READ 등 상황에 맞게 조정

• Lock 범위 축소

  • 인덱스를 사용해 Lock Scope를 최소화

16. 데이터 모델링 시 연관 관계보다 중요하게 본 포인트는?

💬 구두 면접형 답변.

“연관 관계보다는 실제 데이터의 흐름, 사용 빈도, 검색/조인 패턴을 우선 고려합니다.
정규화와 반정규화를 균형 있게 설계해 성능과 유연성을 동시에 확보하는 것이 중요합니다.”

📝 기술 블로그용 서술형 정리.

연관 관계 외에 중요하게 보는 데이터 모델링 관점:

• 업무 도메인 흐름 중심 설계

  • 실제 시나리오 기준으로 모델링

• 정규화 vs 반정규화 균형

  • 과도한 정규화는 조인 비용 증가

• 조회 패턴 최적화

  • 자주 조회되는 컬럼, 조인 구조 분석 후 설계

18. DB 설계와 백엔드 API 설계를 어떻게 연계해야 할까요?

💬 구두 면접형 답변.

“DB 설계는 API의 Input/Output 구조와 긴밀히 연관되어 있습니다.
특히 DTO와 엔티티 간의 변환, 복잡한 조인 대신 조회 전용 View나 Projection을 활용해
API 응답 성능을 확보합니다.”

📝 기술 블로그용 서술형 정리.

DB와 API는 다음 요소로 연계됩니다:

• 엔티티 ↔ DTO 매핑

  • 도메인 모델과 View 모델 분리

• 조회 성능 확보를 위한 View / Projection 사용

• Input Validation → DB Constraint 이중 보장

• 트랜잭션/비즈니스 로직 → 서비스 계층으로 분리

19. DBMS 마이그레이션 시 고려해야 할 점은?

💬 구두 면접형 답변.

“데이터 타입, 인코딩, 함수 호환성, 트랜잭션 동작 차이를 먼저 확인합니다.
데이터 이전은 dump + 검증 자동화 스크립트를 작성하고,
애플리케이션에서의 쿼리 호환성도 테스트합니다.”

📝 기술 블로그용 서술형 정리.

DBMS 마이그레이션 시 주요 체크리스트:

• 데이터 타입 호환성 (예: DATETIME, UUID)

• SQL 문법/함수 차이 (예: LIMIT, TOP, ROWNUM)

• 트랜잭션 격리 수준 및 락 정책 차이

• Dump/Restore 검증 + 이관 자동화 스크립트

• 애플리케이션 쿼리 테스트

20. RDBMS를 사용하는 대신 NoSQL로 바꿔야 하는 케이스는?

💬 구두 면접형 답변.

“스키마가 자주 변경되거나, 수평 확장이 필요하고, 일관성보다 가용성이 중요할 경우 NoSQL이 적합합니다.
예를 들어 실시간 로그 수집, 캐시, 사용자 정의 필드 저장 등이 있습니다.”

📝 기술 블로그용 서술형 정리.

RDBMS 대신 NoSQL을 선택하는 대표적 케이스:

• 스키마 유연성이 필요한 경우: JSON 기반 저장

• 고속 쓰기/읽기 처리: 로그 수집, 실시간 통계

• 대용량 수평 확장 필요: Cassandra, MongoDB

• 관계보다는 단일 객체 위주 접근: 게시글, 사용자 정의 필드 등

• CAP 이론상 가용성/분산성이 중요한 경우