[SQLD/IT자격증] SQLD 1과목 "데이터모델링의 이해" 이론 정리

SQLD 1과목 데이터모델링의 이해

SQLD(SQL개발자) 시험의 1과목인 데이터 모델링의 이해에서 요구하는 항목은 아래 사진과 같습니다.

출처 : K data

아래 유튜브 채널 강의를 들으며 정리하였습니다.

[개정판] SQLD 1과목 완벽 정리 (2024년 신유형 반영) #데이터모델링 #ERD #정규화 - YouTube

 

기본 용어 정리

• 데이터베이스(Database) = 데이터의 집합
• 하지만 데이터를 파일 형태로 다루게 되면 관리하기 어렵기 때문에 보다 쉽게 관리하기 위해 DBMS(Data base management system)이 등장하였다. 흔히 아는 Oracle이 DBMS의 대표적인 예시이다.

학생 정보를 저장하기 위해 아래와 같은 표를 만들었다고 하자. 이때 이 표를 테이블이라고 한다.

물리적 vs  논리적 설계 방식에 따라 부르는 용어가 다르다.

• 설계도면을 가지고 있다. (논리적 설계)  → Entity, 속성, 인스턴스라 부름
• 건물이 지어졌다. (물리적 설계) → 테이블, 컬럼, 행이라 부름

테이블=Entity, 컬럼=속성이고, 행들의 집합을 인스턴스라 부른다.

 

모델링

데이터를 저장해야 할 상황이 생겨 데이터의 요구사항을 만들어가는 과정을 모델링이라 한다. 예를 들어 가계부를 만드려고 한다면, 날짜/가격 컬럼 등을 정의하고 어떤 유형의 데이터를 만들지 고민하는 행위를 모델링이라 한다.

즉, 현실 세계의 비즈니스 프로세스와 데이터 요구 사항을 추상적이고 구조화된 형태로 표현하는 과정이다.

 

모델링의 특징

1. 단순화 (Simplification)
   • 현실을 단순화 하여 핵심 요소에 집중하고 불필요한 세부 사항을 제거 해야 한다.
2. 추상화 (Abstraction)
   • 현실세계를 일정한 형식에 맞추어 간략하게 표현해야 한다.
3. 명확화 (Clarity)
   • 대상에 대한 모호성 없이 정확하게 현상을 기술해야 한다.

 

모델링의 관점

관점에 따라 정의되는 개념이 달라진다.

1. 데이터 관점
   
   • 업무를 고려하지 않고 데이터만 보는 관점이다. 
   • 데이터가 어떻게 저장되고 접근되고 관리되는지를 정의하는 단계이다.
   • 예 : 자사 서비스에 어떤 데이터가 필요할까? 어떤 속성들이 정의되어야 할까?
2. 프로세스 관점
   • 업무적으로 보는 관점이다.
   • 데이터가 시스템 내에서 어떻게 흐르고 변환되는지를 정의하는 단계이다.
   • 예 : 주문 프로세스에 있어서 어떤 데이터가 흐르고 변환되어야 할까?
3. 데이터와 프로세스 관점
   • 각 프로세스가 어떤 데이터를 필요로 할지 보는 관점이다.
   • 특정 프로세스가 어떤 데이터를 사용하고, 데이터가 어떻게 생성되고 변경되는지 명확하게 정의하는 단계이다.
   • 예 : 주문 프로세스의 각 단계에서 어떤 모델들이 정의되어야 할까?

 

데이터 모델링의 유의점

1. 중복 (Duplication)
   • 저장공간의 낭비를 피하기 위해 같은 정보를 저장하지 않도록 설계해야 한다.
2. 비유연성 (Inflexibility)
   • 유지보수 자원을 절약하기 위해 업무 변동 시 모델 변경이 되지 않도록 설계해야 한다.
   • 데이터 정의를 프로세스와 분리해야 한다.
3. 비일관성 (Inconsistency)
   • DB 내의 정보가 모순되거나 상반된 내용을 갖지 않기 위해 데이터 간의 상호연관 관계를 명확히 정의해야 한다.
   • 중복 데이터가 없어도 비일관성은 발생할 수 있다.

 

데이터 모델링의 3가지 요소

• 대상(Entity): 업무가 관리하고자 하는 대상(객체)
• 속성(Attribute) : 대상들이 갖는 속성(특징)
• 관계(Relationship) : 대상들 간의 관계

 

데이터 모델링의 3단계

아래로 갈수록 구체적이어진다.

1. 개념적 모델링
   • 업무 협의에 있어 어떤 데이터가 필요할지만 개념적으로 만드는 행위이다.
   • 추상화 수준이 가장 높다.
   • 업무 분석 이후, 업무의 핵심 엔티티를 추출하는 단계이다.
   • 이 엔티티를 정리하기 위해 ERD를 작성한다.
2. 논리적 모델링
   • 개념적 모델링의 결과를 토대로 세부속성, 식별자, 관계 등을 정의하는 단계이다.
   • 데이터 정규화를 수행하는 단계이다.
   • 재사용성이 높은 논리적 모델은 유지보수가 용이하다.
3. 물리적 모델링
   • 논리적 모델링의 결과를 물리적으로 생성하는 단계이다.
   • DB의 성능, 디스크 저장구조, HW 보안성 등을 고려해야 한다.
   • 구체화 수준이 가장 높다.

 

스키마의 3단계 구조

모든 객체들에 대한 정보 집합을 스키마라고 한다. 즉, DB의 구조와 제약 조건에 관한 전반적인 명세를 기술한 메타데이터의 집합이다.

바라보는 관점에 따라 3가지 스키마로 분리된다.

1. 외부 스키마
   • 현실적인 관점에서, 사용자가 보는 관점에서, 업무적인 관점에서 정해진 스키마이다.
   • 예 : 사용자나 응용 프로그램이 필요한 데이터를 정의
   • 이 결과 만들어진 스키마는 논리적/물리적 모델링을 거쳐 만들어져야 한다.
2. 개념 스키마
   1. 논리적 모델링 단계에서 만들어진 스키마를 일컫는다.
   2. DB의 전체 논리적 구조를 정의한다.
   3. 전체 DB의 개체, 속성, 관계, 데이터 타입 등을 정의한다.
3. 내부 스키마
   1. 문리적 모델링 단계에서 만들어진 스키마를 일컫는다.
   2. 데이터가 물리적으로 어떻게 저장되는지, 데이터의 실제 저장 구조, 컬럼, 인덱스 등을 정의한다.

이런 3단계 스키마들은 독립적인 구조를 가져야 한다. 여기서 이야기 하는 독립이란, 한 쪽이 변경이 되어도 다른 쪽이 영향을 받으면 안된다는 의미이다. 즉 독립성이란, 물리적/논리적 구조를 변경하더라도 사용자가 사용하는 응용 프로그램에 영향을 주지 않는 특성이다. 이 독립성은 아래 2가지 규칙을 가진다.

• 논리적 독립성 : 논리적 데이터 구조가 변경되어도 (= 개념 스키마가 변경되어도) 응용 프로그램에 영향을 주지 않아야 한다.
• 물리적 독립성 : 물리적 구조가 변경되어도 (=내부 구조가 변경되어도) 개념/외부 스키마에 영향을 주지 않아야 한다.

 

데이터 모델의 표기법 (ERD)

앞서 설계된 엔티티와 엔티티 간의 관계를 시각적으로 표현한 다이어그램을 ERD라고 한다. 일종의 설계도이다.

ERD 작성 절차는 아래 6단계가 있다.

1. 엔티티를 그린다.
2. 엔티티를 배치한다.
3. 엔티티 간의 관계를 설정한다.
4. 관계명을 서술한다.
5. 관계의 참여도를 기술한다. (필수 vs 선택 엔티티)
6. 관계의 필수 여부를 확인한다.

 

엔티티(Entity)

엔티티는 현실 세계에서 독립적으로 식별 가능한 객체나 사물을 나타낸다. 모델링 할 때 필요한 대상을 일컫는다. 엔티티의 구성 요소에는 인스턴스, 속성 등이 있다.

예를 들어 학교 시스템을 구축한다고 하자. 이때의 엔티티는 학생, 속성은 학번/이름/학과 등이 올 수 있고 식별자로는 학번을 예시를 들 수 있다. 이때 인스턴스는 특정 학생의 데이터를 가리킨다. 

 

엔티티의 특징

1. 유일한 식별자에 의해 식별이 가능해야 한다.
   • 각각의 행들의 구분을 위한 식별자가 필요하다.
2. 해당 업무에 필요하고 관리하고자 하는 정보여야 한다.
3. 인스턴스들의 집합이어야 한다.
   • 최소 2개 이상의 인스턴스가 있어야 한다.
4.  반드시 속성을 가져야 한다.
   • 각 엔티티는 2개 이상의 속성을 가져야 한다.
   • 하나의 인스턴스는 각각의 속성에 대해 1개의 속성 값만 가져야 한다.
5. 엔티티는 업무 프로세스에 의해 이용되어야 한다.
   • 실제 사용되지 않는 고립 엔티티는 제거해야 한다.
6. 다른 엔티티와 최소 1개 이상의 관계가 성립해야 한다.
   • 관계가 없는 엔티티는 잘못되었다.

 

엔티티의 분류

우선 유형과 무형에 따른 분류를 할 수 있다.

1. 유형 엔티티
   • 물리적인 형태가 있어 실체가 있는 대상이다.
   • 예 : 사원, 물품
2. 개념 엔티티
   • 물리적인 형태가 없는 엔티티이다.
   • 예 : 보험 상품, 조직
3. 사건 엔티티
   • 업무 수행에 따라 발생하는 엔티티이다.
   • 발생량이 많고 각종 통계자료에 이용한다.
   • 예 : 주문, 청구, 미납

발생 시점에 따라서도 분류할 수 있다.

1. 기본 엔티티
   • 그 업무에 원래 존재하는 정보를 일컫는다.
   • 다른 엔티티와 관계에 의해 생성되지 않고 독립적으로 생성된다.
   • 타 엔티티의 부모 역할을 하며 다른 엔티티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가진다.
   • 예 : 사원, 부서, 고객, 상품 등
2. 중심 엔티티
   1. 기본 엔티티로부터 파생되는 개념으로, 그 업무에서 중심적인 역할을 하는 엔티티이다.
   2. 많은 데이터가 발생되고 다른 엔티티와의 관계를 통해 많은 행위 엔티티를 생성한다.
   3. 예시 : 계약(사원으로부터 파생되는 개념), 사고, 청구, 주문 매출 등
3. 행위 엔티티
   1. 2개 이상의 부모 엔티티로부터 발생하는 엔티티이다.
   2. 자주 내용이 바뀌거나 데이터 양이 증가하는 엔티티이다.
   3. 분석 초기 단계보다는 상세 설계 단계에서 도출이 된다.
   4. 예시 : 주문(고객↔상품 엔티티로부터 발생하기 때문에), 사원변경이력, 이력 등

 

엔티티의 명명

1. 현업에서 사용하는 용어를 사용해야 한다.
2. 약자 사용은 지양해야 한다.
3. 단수 명사를 사용한다.
4. 모든 엔티티에서 유일한 이름을 부여해야 한다.
5. 엔티티 생성 의미대로 이름을 부여해야 한다.

 

엔티티와 인스턴스 표기법

엔티티와 인스턴스가 ERD에서 어떻게 표현되는지에 대한 내용이다.

엔티티는 사각형으로 표현하고 서로의 관계는 선으로 표현한다. 속성은 IE, Baker 표기법이 있다.

 

속성(Attribute)

속성은 업무에서 필요로 하는 고유한 성질, 특징을 의미한다. 즉, 컬럼으로 표현할 수 있는 단위이며 더이상 분리되지 않는 최소의 데이터 단위이다. 예를 들면, 학생 엔티티에 이름, 학법, 학과 등이 속성이 될 수 있다.

속성의 특징은 아래와 같다.

• 해당 업무에 필요하고 관리하고자 하는 정보여야 한다.
• 정해진 주식별자에 함수적 종속성을 가져야 한다.
  • 주식별자는 각 행들을 식별할 수 있는 식별자인데 (예:학번), 이 주식별자에 의해 결정되는 요인이 함수적 종속성을 가져야 한다는 뜻이다. 예를 들면, 학번이 달라지면 이름이 달라지기 때문에 이름이라는 속성은 주식별자인 학번에 함수적 종속성을 가진다고 이야기 할 수 있다.
• 각 속성이 하나의 값을 가지고 있어야 하며 이를 속성의 원자성이라 이야기 한다.
  • 원자성이란 데이터모델에서 각 엔티티의 인스턴스가 해당 속성에 대해 단일하고 명확한 값을 가지는 특성을 이야기 한다.

함수적 종속성을 추가적으로 설명하자면 아래와 같다.

만약 어떤 속성 A의 값에 의해 다른 속성 B도 유일하게 결정된다면 B는 A에 함수적으로 종속되었다 하고 수식으로 A→B라고 표현한다.

함수적 종속에는 2가지 종류가 있다.

• 완전 함수적 종속
  • 특정 컬럼이 기본키에 대해 완전히 종속될 때를 이야기 한다.
  • PK를 구성하는 컬럼이 2개 이상일 경우, PK 값 모두에 의한 종속관계를 나타낼 때 완전 함수 종속성을 만족한다.
  • 아래와 같이 주문번호+제품번호에 의해 수량 컬럼의 값이 결정되는 경우이다.

• 부분 함수적 종속
  • 기본키 일부에 대해 종속될 때를 이야기 한다.
  • 아래와 같이 PK의 일부인 과목에 의해서도 교수가 결정되는 경우이다.

 

엔티티, 인스턴스, 속성, 속성값의 관계

• 한 개의 엔티티는 2개 이상의 인스턴스 집합이어야 한다. = 하나의 테이블은 두 개 이상의 행을 가진다.
• 한 개의 엔티티는 2개 이상의 속성을 가진다. = 하나의 테이블은 두 개 이상의 컬럼으로 구성된다.
• 한 개의 속성은 1개의 속성값을 가진다. 
• 속성은 엔티티에 대해 자세하고 구체적인 값을 가져야 한다.

 

속성의 분류

속성은 특성에 따라 분류할 수 있다.

1. 기본 속성
   • 업무로부터 추출된 모든 속성으로 가장 많이 존재하는 속성이다.
   • 예 : 원금, 예치기간
2. 설계 속성
   • 업무를 규칙화하기 위해 새로 만들어지거나 변형된 속성이다.
   • 예 : 상품코드, 지점코드
3. 파생 속성
   • 다른 속성에 만들어지는 속성으로 계산된 값들이 해당된다.
   • 예 : 합계, 평균, 이자

엔티티 구성방식에 따라서도 분류할 수 있다.

1. PK (Primary Key, 기본키) : 인스턴스를 식별할 수 있는 속성
2. FK (Foreign Key, 외래키) : 다른 엔티티와의 관계에서 포함된 속성
3. 일반 속성 : 엔티티에 포함되어 있으나 PK, FK가 아닌 속성

분해 여부에 따라서도 분류할 수 있다.

1. 단일 속성
   • 하나의 의미로 구성되어 있는 속성이다.
   • 예 : 회원ID, 이름
2. 복합 속성
   • 여러 개의 의미로 구성되어 있는 속성이다.
   • 예 : 주소(시, 구, 동)
3. 다중값 속성
   • 여러 개의 값을 가질 수 있는 속성으로 엔티티로 분해해야 한다.
   • 예 : 상품 리스트

 

속성의 명명규칙

• 업무에서 사용하는 이름을 부여해야 한다.
• 서술식 속성명은 사용하지 않는다.
• 약어의 사용은 지양한다.
• 전체 데이터 모델에서 유일한 명칭이어야 한다.

 

도메인(Domain)

도메인이란 각 속성이 가질 수 있는 값의 범위를 의미한다. 엔티티 내에서 속성에 대한 데이터 타입, 크기, 제약사항 등을 지정하는 것이다.

 

관계(Relationship)

관계는 엔티티 간의 연관성을 나타내는 개념이다. 관계를 정의할 때는 인스턴스 간의 연결고리를 고려해야 한다.

 

관계의 종류

아래와 같은 2가지 종류는 ERD에서 구분하여 표현하지는 않는다.

1. 존재적 관계
   • 한 엔티티의 존재가 다른 엔티티의 존재에 영향을 미치는 관계를 이야기 한다.
   • 예 : 부서 엔티티가 삭제되면 사원 엔티티의 존재에 영향을 미친다.
2. 행위적 관계
   • 엔티티 간의 어떤 행위가 있는 것을 의미한다.
   • 예 : 고객 엔티티의 행동에 의해 주문 엔티티가 발생한다.

 

관계의 구성

1. 관계명
2. 차수 (Cardinality)
3. 선택성 (Optionality)

 

관계의 차수(Cardinality)

한 엔티티의 인스턴스가 다른 엔티티의 인스턴스와 어떻게 연결되는지를 나타내는 표현이다. 1:1, 1:N, N:M 등으로 표현할 수 있다.

1. 1 : 1 관계
   1. 완전 1 : 1 관계
      • 하나의 엔티티에 관계되는 엔티티가 반드시 하나로 존재하는 경우
      • 예 : 사원은 반드시 소속 부서가 있어야 한다.
   2. 선택적 1 : 1 관계
      • 하나의 엔티티에 관계되는 엔티티가 없을 수 있는 경우
      • 예 : 사원은 발령 전일 경우 소속 부서가 없을 수 있다.
2. 1 : N 관계
   • 엔티티 하나의 행에 다른 엔티티의 값이 여러 개 있는 관계
   • 예 : 고객은 여러 개의 계좌를 소유할 수 있다.
3. N : M 관계
   • 이 관계의 경우 조인 시 카테시안 곱이 발생한다. 따라서 두 엔티티를 연결하는 연결엔티티를 통해 1:N 관계로 해소해야 한다.
   • 예 : 한 학생이 여러 강의를 수강할 수 있고, 한 강의에 여러 학생이 있을 수 있다. 이런 경우 구매이력 엔티티를 연결엔티티로 두어야 한다.

 

관계의 페어링

엔티티 안에 인스턴스가 개별적으로 관계를 가지는 것을 이야기 한다. 따라서 관계란 페어링의 집합을 의미한다.

 

관계 vs 페어링 vs 차수

• 학생과 강의 엔티티는 관계를 가진다.
• 한 학생이 여러 강의를 수강할 수 있고 한 강의도 여러 학생에게 수강될 수 있기 때문에 M : N  관계이며 이를 차수라 한다.
• 인스턴스끼리의 관계로 보면 "학생 A가 강의 B를 2023년 1학기에 수강하였고 성적은 A+를 받았다"와 같은 특정한 페어링이 형성된다.

 

식별자

식별자는 엔티티를 대표할 수 있는 속성을 이야기 한다. 하나의 엔티티에는 유일한 식별자가 존재해야 하며 이는 논리 모델링에서 사용하는 용어이다. 물리 모델링으로 가면 Key로 표현한다. 

 

식별자의 분류

대표성 여부에 따라 식별자를 분류할 수 있다.

주식별자	보조식별자
유일성과 최소성을 만족하면서 엔티티를 대표하는 식별자 엔티티 내에서 각 인스턴스를 유일하게 구분할 수 있는 식별자 타 엔티티와 참조관계를 연결할 수 있는 식별자	엔티티 내에서 각 인스턴스를 구분할 수 있는 구분자 대표 성을 가지지 못해 참조 관계 연결을 할 수 없는 식별자 유일성과 최소성은 만족하지만 대표성을 만족하지 못하는 식별자

생성 여부에 따라 식별자를 분류할 수 있다.

내부식별자	외부식별자
다른 엔티티 참조 없이 엔티티 내부에서 스스로 생성되는 식별자	다른 엔티티와 관계로 인해 만들어지는 식별자 (FK)

어떤 엔티티에서는 내부식별자로 정의되던 컬럼이 다른 엔티티에서는 외부식별자로 정의될 수 있다.

속성 수에 따라 식별자를 분류할 수 있다.

단일식별자	복합식별자
하나의 속성으로 구성되는 식별자	2개 이상의 속성으로 구성되는 식별자

대체 여부에 따라 식별자를 분류할 수 있다.

본질식별자(원조식별자)	인조식별자
비즈니스 프로세스에서 만들어지는 식별자 꼭 필요한 식별자	인위적으로 만들어지는 식별자 꼭 필요하지 않지만 관리의 편이성 등을 이유로 만들어지는 식별자

어떤 엔티티, 비즈니스 모델에서 만들어지는지에 따라 하나의 속성이 다르게 정의될 수 있다. 인조식별자는 중복 데이터가 발생할 수 있어 데이터 품질이 저하될 수 있다는 단점이 있다. 또한 불필요한 인덱스를 생성하여 저장공간 낭비나 DNL 성능을 저하시킬 수도 있다.(인덱스는 원래 조회 성능을 향상시키기 위한 객체이며, 인덱스는 DML(INSERT, UPDATE, DELETE)시 INDEX SPLIT 현상을 인해 성능이 저하될 수 있다.)

 

식별자 표기법

출처 : DATA-ON-AIR

 

주식별자의 특징

1. 유일성 : 주식별자에 의해 모든 인스턴스를 유일하게 구분해야 한다.
2. 최소성 : 유일성을 만족하는 최소한의 속성으로 구성해야 한다.
3. 불면성 : 식별자의 값은 변하지 않아야 한다.
4. 존재성 : 반드시 값이 존재해야 한다.

 

주식별자의 도출 기준

1. 해당 업무에서 자주 이용되는 속성을 주식별자로 지정한다.
2. 명칭이나 내역 등과 같은 이름은 피해야 한다. (부서명보다는 부서코드)
3. 속성의 수를 최대한 적게 구성해야 한다. (조인으로 인한 성능 저하 발생을 예방하기 위해서)
   • 예 : 주문 엔티티에 대해 주식별자를 주문일자+주문상품코드+고객번호 등으로 구성한다면 이를 조합하여 주문번호를 만들고 주문번호 속성을 추가하는 것이 좋다.

 

관계 간 엔티티 구분

• 강한 개체 : 독립적으로 존재할 수 있는 엔티티
• 약한 개체 : 독립적으로 존재할 수 없는 엔티티

예를 들어 고객과 계좌 엔티티 중에서 고객은 독립적으로 존재할 수 있어 강한 개체이지만 계좌는 독립적으로 존재할 수 없어 약한 개체이다.

 

식별 관계와 비식별 관계

• 식별 관계 (Identification Relationship)
  • PK를 서로 PK로 가지고 있는 관계 (PK 중 하나로 공유하여도 괜찮다.)
  • ERD에서는 실선으로 표시한다.

• 비식별 관계 (Non-Identification Relationship) 
  • PK를 서로 PK로 가지지 않는 관계
  • 강한 개체의 PK를 다른 엔티티에서는 일반 속성으로 가지는 경우
  • ERD에서는 점선으로 표시한다.

 

Key의 종류

논리 모델링의 식별자가 물리 모델링을 거쳐 Key가 된다.

1. 기본키 (Primary Key) 
   • 엔티티를 대표할 수 있는 키
2. 후보키 (Candidate Key)
   • 유일성과 최소성을 만족하는 키
   • 후보키들 중 하나가 기본키가 되고 나머지는 대체키가 된다.
3. 대체키 (Alternate Key)
   • 여러 후보키 중 기본키가 아닌 키
4. 슈퍼키 (Super Key)
   • 유일성은 만족하지만 최소성을 만족하지 않는 키
5. 외래키 (Foreign Key)
   • 다른 테이블의 기본키를 참조하는 키

 

정규화 (DB Normalization)

정규화는 최소한의 데이터만을 하나의 엔티티에 넣는 방식으로 데이터를 분해하는 과정을 의미한다. 이는 데이터의 일관성, 최소한의 데이터 중복, 최대한의 데이터 유연성을 위한 과정이다. 정규화는 데이터의 중복을 제거하고 데이터 모델의 독립성을 확보하고 데이터의 이상현상을 줄이기 위한 DB 설계 기법이다. 이는 논리적 모델링 수행 시에 실행된다. 정규화는 제1정규화~제5정규화까지 있지만 실제로는 제3까지만 수행한다.

여기서 이야기 하는 이상현상은 삽입이상, 갱신이상, 삭제이상이다.

• 삽입/갱신이상 : 특정 인스턴스가 삽입될 때 정의되지 않아도 되는 속성까지도 반드시 입력되어야 하는현상
• 삭제이상 : 특정 정보만 삭제하면 되는데 관련된 다른 정보까지도 함께 삭제되는 현상

 

정규화 단계

제 1 정규화 (1NF)

• 테이블 칼럼이 원자성을 갖도록 테이블을 분해하는 단계

제 2 정규화 (2NF)

• 제1정규화 이후에 완전 함수 종속을 만들도록 테이블을 분해하는 단계
  • 완전 함수 종속 : 기본키를 구성하는 모든 컬럼의 값이 다른 컬럼을 결정짓는 상태
• PK가 2개 이상일 때 발생하며 PK의 일부와 종속되는 관계가 있다면 분리한다.

좌측 엔티티는 현재 학번+강의명을 PK로 잡고 있는데 강의실은 강의명에 의해서만 결정되기 때문에 부분 함수 종속성을 가진다. 따라서 강의명과 강의실을 속성으로 가지는 새로운 엔티티를 생성해야 한다. 성적은 학번+강의명에 의해서 결정되기 때문에 또 학번, 강의명, 성적을 속성으로 가지는 새로운 엔티티를 생성해야 한다.

제 3 정규화 (3NF)

• 제2정규화 이후에 이행적 종속을 없애도록 테이블을 분해하는 단계
  • 이행적 종속 : A → B, B → C의 관계가 성립할 때, A → C가 성립하는 경우
• 이때 (A,B)와 (B,C)로 분리하는 것이 제3정규화에서 할 일이다.

BCNF (Boyce-Codd Normal Form) 정규화

• 모든 결정자가 후보키가 되도록 테이블을 분해하는 단계
• 결정자가 후보키가 아닌 다른 컬럼에 종속되면 안된다.

제 4 정규화 (4NF)

• 여러 컬럼들이 하나의 컬럼을 종속시키는 경우 분해하는 단계
• 다중값 종속성을 제거한다.

제 5 정규화 (5NF)

• 조인에 의해 종속성이 발생되는 경우 분해하는 단계

 

반정규화 (De-Normalization)

해당 내용은 2024 개정 시험에서는 제외되는 개념입니다.

역정규화라고도 부르며 DB 성능 향상을 위해 데이터 중복을 허용하고 조인을 줄이는 기법이다. 즉, 정규화된 데이터 모델을 중복, 통합, 분리하는 데이터 모델링 기법이다. SELECT 속도는 향상시키지만 데이터 모델의 유연성은 떨어진다.

(비정규화는 다른 용어이며 정규화를 수행하지 않았음을 의미하는 용어이다.)

반정규화는 아래와 같은 경우에 수행된다.

• 정규화에 충실하여 종속성, 활용성은 향상되지만 수행 속도가 느려지는 경우
• 다량의 범위를 자주 처리해야 하는 경우
• 특정 범위의 데이터만 자주 처리하는 경우
• 요약/집계 정보가 자주 요구되는 경우

 

관계(Relationship)

두 엔티티가 관계를 가진다는 의미는 부모의 식별자를 자식에 상속하고 상속된 속성을 매핑키(조인키)로 활용하는 것을 의미한다. (먼저 존재해야 하는 테이블이 부모가 된다.)

관계는 두 가지 분류가 있다. 

1. 존재적 관계
   • 엔티티 간의 상태를 의미하는 관계로 A라는 엔티티가 B라는 엔티티에 존재에 영향을 주는 관계를 의미한다.
2. 행위적 관계
   • 엔티티 간의 어떤 행위가 있는 것을 의미한다.

 

조인

어떤 두 테이블이 위와 같은 관계를 맺게 되면 조인이 필요하게 될 수도 있다. 정규화로 분리된 두 테이블의 데이터를 동시에 출력하거나 관계가 있는 테이블을 참조하기위해서는 데이터를 연결해야 하는데 이 과정을 조인이라고 한다.

 

계층형 데이터 모델

자기 자신끼리의 관계가 발생하여 셀프 조인을 가지는 경우를 계층형 데이터 모델이라 한다. 

아래와 같이 매니저번호(MGR)은 매니저의 사원번호를 의미하는데 결국 사원번호(EMPNO)와 관련이 있는 경우이다.

위 예제를 SQL로 표현하자면 아래와 같다.

SELECT E1.NAME AS 사원이름, E2.NAME AS 매니저이름
FROM EMP.E1, EMP.E2
WHERE E1.MGR = E2.EMPNO;

이 SQL문의 결과는 아래와 같이 나올 것이다.

 

상호 배타적 관계

상호 배타적 관계란 두 테이블 중 하나만 가능한 관계를 의미한다.

예를 들면, 주문 엔티티에는 개인 또는 법인번호 하나만 상속될 수 있는 경우를 말한다. 즉, 주문이 개인고객이나 법인고객 둘 중 하나의 고객만이 가능하다는 이야기이다.

 

트랜잭션(Transaction)

트랜잭션이란 하나의 연속적인 업무 단위를 일컫는데, 하나의 트랜잭션에는 여러 SELECT, INSERT, DELETE, UPDATE 문 등이 포함될 수 있다. 트랜잭션에 의한 관계는 필수적인 관계 형태를 가진다.

예를 들어 A고객이 B고객에게 100만원을 이체하려고 한다고 하자. 그럼 아래와 같은 프로세스가 일어나야 한다.

1. A고객의 잔액이 100만원 이상인지 확인
2. 이상이면 A 고객의 잔액을 - 100 하여 UPDATE
3. B 고객의 잔액에 + 100 UPDATE

이때 2, 3번 과정이 동시에 수행되어야만 한다. 모두 성공하거나 모두 취소 되어야 (All or Nothing) 전산 상의 오류가 없다. 이런 특성을 가지는 연속적인 업무 단위를 트랜잭션이라고 한다. 따라서 위의 과정에서 2, 3번 과정이 서로 독립적으로  발생하면 안되고 부분 COMMIT이 불가하다.

 

필수적 vs 선택적 관계

• 필수적 관계 : 두 엔티티가 하나의 트랜잭션을 이룰 때
• 선택적 관계 : 두 엔티티가 서로 독립적인 수행이 가능할 때
• IE 표기법
  • 원을 사용하여 필수적 vs 선택적 관계를 구분한다.
  • 필수적 관계 : 원 O
  • 선택적 관계 : 원 X
• Baker 표기법
  • 실선과 점선으로 필수적 vs 선택적 관계를 구분한다.
  • 필수적 관계 : 실선
  • 선택적 관계 : 점선

 

NULL

NULL이란 DBMS에서 아직 정해지지 않은 값을 의미한다. 0이나 ""(빈 문자열)과는 또 다른 개념이다. 모델 설계 시에는 각 컬럼별로 NULL을 허용할 것인지를 결정해야 한다.

NULL은 아래와 같은 특성을 가진다.

• NULL을 포함한 연산 결과는 항상 NULL이다.
  • NULL + 800 = NULL
  • 이와 같은 일을 방지하고 싶다면 NULL을 사전에 치환한 후 연산할 수 있다. 
• 집계 함수는 NULL을 제외한 연산 결과를 리턴한다.
  • sum, avg, min, max 등의 함수가 그 예시이다.
  • COUNT를 할 때에도 NOT NULL인 행만 세어 리턴하기 때문에 전체 행의 수보다 적은 값이 출력될 수 있다.

NULL은 IE 표기법에서는 허용 여부를 알 수 없다. Barker 표기법에서는 속상 앞에 동그라미가 있는 경우는 NULL을 허용함을 의미한다.