[면접 준비 - Database]DB 설계, 스키마 3계층

목차

 

Principles

 

설계 자체에 들어가기에 앞서, 좋은 DB 설계란 지켜야 할 몇 가지 원칙이 존재한다.

 

• 하나의 거대한 테이블이 아닌 주제에 맞는 여러 개의 테이블로 분할할 것
• 하나의 테이블 안의 각 필드는 유일한 정보를 가질 것 - 중복 데이터 및 그룹 제거
• 같은 데이터를 가리키는 필드명은 다른 테이블에서도 동일할 것
• 각 테이블은 반드시 PK를 가질 것 - 중복 데이터 방지 및 조회 속도 향상
• 테이블 간 연관관계에 FK를 사용할 것 - 중복 데이터 및 매핑 실수 방지
• 필드 독립성 - 특정 필드 값의 변화가 다른 필드에 영향을 주지 않을 것

데이터 무결성을 포함하는 위와 같은 원칙을 바탕으로 DB 설계는 총 다섯 단계로 나눌 수 있는데, 이를 정리하면 아래와 같다.

 

1. 사용자의 요구조건 분석(Requirement Analysis)
2. 개념적 설계(Conceptual Design) → 개념 스키마 도출
3. 논리적 설계(Logical Design)
4. 물리적 설계(Physical Design) → 내부 스키마 도출
5. 실제 DB를 구현(Implement and Loading)

잠시 옆길로 새서 스키마에 대해 정리한 뒤에, DB 설계의 순서를 따라가 보자.

 

Schema

 

스키마, 혹은 DB 스키마는 (주로) RDB의 구조와 조건을 명시한 스펙이다.

 

여기서 구조와 조건이란 엔티티, 속성, 매핑 관계, 데이터 제약조건 등 일종의 메타 데이터라고 할 수 있다.

 

계속해서 이 스키마란 관점에 따라 보통 세 가지로 분류하는데, 대략 요약하면 아래와 같다.

 

 

• 외부 스키마(External, Sub Schema)
  
  
  • 말 그대로 외부에서 보는 DB의 형태
  • 사용자, 혹은 개발자 개인의 입장에서 바라보는 DB의 논리적 구조, 동일한 DB에 대해 다른 관점 정의 가능
    ex) 하나의 테이블에 대해 쿼리를 하는 A와 여러 개의 테이블을 JOIN 해 쿼리 하는 B가 보는 스키마는 다름
  • 전체가 아닌 일부의 논리적 구조이므로 서브 스키마라고 부르기도 함
• 개념 스키마(Conceptual Schema)
  
  
  • 회사 등 조직에서 바라보는 DB의 추상적인 형태이자 조감도
  • 개별 사용자가 바라보는 형태가 아닌 전체의 논리적인 구조와 속성, 테이블간의 관계와 접근 권한,
    보안 정책 및 데이터 무결성에 대한 명세이며 일반적인 스키마는 이 개념 스키마를 뜻함
  • 쉽게 말하면 부가 정보가 추가된 ERD라고 할 수 있다. 당연히 DB마다 유일하다.
• 내부 스키마(Internal Schema)
  
  
  • 물리적 관점에서 바라보는 DB의 형태
  • 실제 데이터가 저장되는 메모리의 물리적 구조를 나타낸다.
  • 데이터의 저장 방식과 크기, 자료형 등이 설정되어 있다.
  • 역시 DB마다 유일하다.

 

Database Design

 

Requirement Analysis

 

DB 설계를 의뢰한 사람과 사용할 사람의 요구사항을 모아서 분석하는 단계다.

 

조금 더 구체적으로는 저장할 데이터의 종류, 타입, 용도 등을 분석해 명세서를 제작한다.

 

Conceptual Design

 

대략적인 개념 스키마, 그러니까 ERD를 작성하는 단계라고 볼 수 있다.

 

즉, 원칙에 맞춘 엔티티 생성과 그 사이의 관계를 정의한다.

 

다음 단계인 논리적 설계에서 수행할 작업의 컨셉을 스케치한다고 볼 수 있다.

 

Logical Design

 

본격적인 개발에 들어가는 단계.

 

위에서 작성한 개념 스키마를 수정하면서 (RDB라면) 테이블로 매핑하는 단계이다.

 

1 : 1, 1 : N, N : M 등의 매핑관계를 논리적으로 구현하며,

 

이 과정에서 ERD를 바탕으로 테이블 사이의 삽입, 삭제 트랜잭션 인터페이스도 설계한다.

 

또한 위에서 작성한 개념 스키마에 잘못된 부분이 있다면 늦게 알아챌수록 비용이 커지기 때문에

 

스키마 정제 및 정규화를 통해 DBMS에 맞춘 DB의 효율성도 고려해야 한다.

 

Physical Design

 

논리적으로만 존재하는 DB를 물리적 구조로 변환하는 단계이다.

 

DBMS에 DDL을 사용해 CREATE를 던지기만 하면 될 정도로 설계를 마쳐야 한다.

 

• DDL(Data Definition Language) - 데이터 구조를 정의하는 데 사용되는 명령어. CREATE, ALTER, DROP 등

 

또한 위에서 정규화된 테이블을 DBMS에 맞춰 성능을 극대화하는 단계라고 할 수 있는데, 여기서 극대화 방법은 다음과 같다.

 

• 데이터의 크기와 자료형 확정
• 사용자의 쿼리에 따른 트랜잭션(연산의 집합) 예측 및 분석
• 위 단계에서 비용이 큰 트랜잭션의 빈도가 높을 것으로 예상되면 반정규화(Denormalization) 고려
  → 정규화를 깨더라도 자원을 아끼는 것이 돈을 아끼는 길이기 때문(무결성 vs. 성능 최적화)
  → 먼저 다른 방식(뷰 설계, 인덱스 구축, 클러스터링)으로 문제를 해결할 수 있나 살펴야 함
• 자주 사용되는 데이터의 메모리 주소를 가까이 배정해 접근속도 및 캐시의 공간지역성 효율을 높인다(Clustering).
  → JPA 영속성 컨텍스트도 캐시의 일종이다.

 

Implement and Loading

 

DDL을 사용해 실제 테이블을 구현하고 데이터를 채워 넣는다.

 

이후로 SQL문을 사용해 DBMS에 접근하며,

 

설계를 마친 테이블은 외부 스키마로 가공되어 외부에 보여진다.