10. 데이터 모델링과 정규화

10.1 데이터 모델링이란

10.1.1 데이터 모델링의 개념

데이터 모델링(data modeling)이란 현실 세계의 어떤 사물이나 현상을 추상화(모형화)해 데이터 간 구조와 관계를 정의한 '데이터 모델'을 만드는 과정입니다. 즉, 데이터 모델링은 데이터를 어떤 구조로 저장하고, 데이터 간 관계는 어떻게 설정할지 등을 정의하는 일입니다. 데이터 모델링을 거치면 약속된 형식의 데이터 모델이 만들어집니다.

10.1.2 데이터 모델링의 이점

설계도 없이 건물을 지으면 안 되는 것처럼, 데이터베이스도 무턱대고 테이블부터 만들면 안 됩니다. 안전한 건물을 짓기 위해 건출 설계도부터 만드는 것처럼 안정적으로 데이터베이스를 구축하려면 데이터 모델링을 해야 합니다.
데이터 모델링의 이점은 6가지가 있습니다.

1. 비즈니스 요구사항을 반영한다

데이터 모델링은 실제 비즈니스 운영 방식에 맞게 데이터베이스를 설계하는 과정입니다. 따라서 비즈니스가 지향하는 목표를 효과적으로 지원합니다.

2. 의사소통 개선에 기여한다

데이터 모델링은 데이터의 구조와 관계를 명확하게 정의하는 과정으로, 데이터베이스 전문가인 기술팀과 비전문가인 비즈니스 관계자, 최종 사용자 등이 서로 소통할 수 있도록 돕습니다. 데이터 모델링을 통해 요구사항이 잘 반영됐는지 공유하고 지속적으로 피드백하는 과정을 통해 불필요한 혼란과 오해를 줄이고 이해 관계자들이 같은 방향을 바라보며 협업할 수 있도록 합니다.

3. 데이터 무결성을 보장한다

데이터 모델링은 데이터베이스의 구조를 명확히 해 데이터 무결성을 보장합니다. 데이터 무결성이란 데이터의 정확성, 일관성, 신뢰성을 유지하는 것으로, 다양한 제약 조건과 규칙을 사용해 데이터의 오류나 왜곡을 방지합니다.

4. 성능을 최적화한다

데이터 모델링은 핵심 데이터를 남기고 무의미한 데이터를 제거함으로써 데이터베이스의 성능을 최적화합니다.
성능 최적화란 주어진 컴퓨팅 자원을 이용해 데이터베이스의 응답 속도는 단축시키고 처리 용량은 증가시키는 것으로 데이터 모델링을 하면 데이터베이스 성능을 최적화할 수 있습니다.

5. 유연한 확장이 가능하다

데이터 모델링을 거친 데이터베이스는 추후 시스템을 확장하거나 변화로 인해 구조를 바꿔야 할 때 유연한 확장성을 발휘합니다. 새로운 요구사항이나 비즈니스 변화가 생길 경우 데이터의 저장 구조를 유연하게 조정할 수 있도록 맨 처음 설계 단계에서부터 이를 고려한 모델링을 수행해야 하기 때문입니다.

6. 비용을 절감한다

데이터 모델링은 초기 설계 단계에서 잠재적인 문제를 식별하고 해결할 수 있게 해줍니다. 따라서 개발 및 운영 단계에서 발생할 수 있는 비용을 절감할 수 있습니다.

10.1.3 데이터 모델링 3단계

데이터 모델링은 개념적 데이터 모델링, 논리적 데이터 모델링, 물리적 데이터 모델링의 3단계를 거쳐 최종 데이터베이스를 구현합니다.

개념적 데이터 모델링

개념적 데이터 모델링은 현실 세계를 구성하는 주요 개체(엔티티)와 그들 간의 관계를 정의하는 단계입니다. 요구사항을 분석해 핵심 엔티티를 찾고, 이들 간 관계를 분석해 정의합니다.
쇼핑몰 사이트를 예로 들면, 쇼핑몰이 운영되는 과정에 참여하는 핵심 엔티티를 '사용자', '주문', '결제', '상품'으로 뽑고, 이들 간의 관계를 '주문하다', '결제하다', '장바구니에 담다'로 연결합니다.

개념적 데이터 모델링을 할 때는 데이터베이스의 기술적인 부분은 고려하지 않고, 기술팀, 비즈니스 관계자, 최종 사용자 등 모든 이해 관계자가 시스템에 대한 큰 그림을 쉽게 그릴 수 있도록 진행합니다.

논리적 데이터 모델링

논리적 데이터 모델링은 개념적 데이터 모델링의 결과로 만들어진 데이터 모델의 세부 내용을 정의하는 단계입니다.
개념적 데이터 모델링이 '무엇을 만들 것인가'에 집중한다면, 논리적 데이터 모델링은 그 무엇을 '어떻게 만들 것인가'에 집중합니다. 앞서 만든 뼈대에 살을 붙인다고 생각하면 이해하기 쉽습니다.

이 단계에서는 엔티티의 속성, 식별자, 관계의 유형을 정의하며, 데이터의 중복을 제거하고 데이터베이스 운영의 효율성을 높이기 위해 정규화를 진행합니다.
논리적 데이터 모델링은 특정 DBMS에 종속되지 않고 반복적인 검증을 통해 개선해 나가는 방식으로 수행합니다. 이를 위해 데이터베이스를 구축/운영하는 기술팀뿐만 아니라 비즈니스 관계자, 최종 사용자 간 지속적인 피드백이 필요합니다.

물리적 데이터 모델링

물리적 데이터 모델링은 논리적 데이터 모델링의 결과로 만들어진 데이터 모델을 특정 DBMS에 맞게 최적화하는 단계입니다.
개념적 데이터 모델링과 논리적 데이터 모델링이 비즈니스 관점에서 '무엇을 어떻게 구현하는가'에 초점을 맞췄다면, 물리적 데이터 모델링은 '높은 성능과 적은 비용으로 어떻게 구현할 것인가'에 초점을 맞춥니다.

물리적 데이터 모델링은 데이터베이스의 물리적 저장 방식, 접근 방식, 성능 등을 고려해 최적의 세부 사항(테이블명, 컬럼명, 기본키, 외래키, 자료형, 제약 조건 등)을 설계합니다.
건축 설계를 예로 들면 건물 내 기자재를 사용자 동선을 고려해 최적의 장소에 배치하는 것, 창문을 채광 효과가 가장 좋은 곳에 두는 것 등이 모두 물리적 데이터 모델링과 같다고 볼 수 있습니다.

10.2 데이터 모델의 구성 요소

데이터 모델링을 통해 만든 데이터 모델은 엔티티, 속성, 관계로 구성됩니다.

10.2.1 엔티티

엔티티란 데이터베이스에서 관리하려는 핵심 대상으로, 비즈니스에서 실제로 존재하거나 개념적으로 중요한 것을 모형화한 것입니다. 쉽게 말해 엔티티는 테이블로 만들어질 대상이라고 할 수 있습니다.
예를 들어, 쇼핑몰 데이터베이스를 구축하려면 '사용자' 정보도 관리해야 하고, '상품'도 관리해야 하고, '주문'에 대한 처리도 해야 합니다. 이러한 비즈니스 요구사항을 바탕으로 만든 '사용자', '상품', '주문' 등은 쇼핑몰 데이터베이스의 엔티티가 됩니다.

• 쇼핑몰 데이터베이스의 엔티티: 사용자, 상품, 주문, ...

엔티티와 연관된 용어로 테이블과 인스턴스가 있습니다. 이들은 서로 비슷하면서도 각기 다른 의미를 갖고 있습니다.

• 테이블: 엔티티를 실제 데이터베이스에 구현한 것으로, 행과 열의 표 형태입니다.
• 인스턴스: 엔티티의 실제 데이터로, 테이블에 저장된 행 단위의 데이터를 말합니다.
  

10.2.2 속성

속성은 엔티티의 특성이나 정보를 나타내는 항목으로, 여러 속성이 모여 하나의 엔티티를 구성합니다. 예를 들어 사용자, 상품, 주문 엔티티는 다음과 같은 속성을 가지며, 이러한 속성을 통해 다른 엔티티와 구분됩니다.

• 사용자 엔티티의 속성: ID, 이메일, 이름
• 상품 엔티티의 속성: ID, 상품명, 가격, 상품 유형
• 주문 엔티티의 속성: ID, 주문 상태, 주문 일시, 사용자 ID

속성과 연관된 용어로 컬럼이 있습니다. 속성을 실제 데이터베이스에 구현하면 테이블의 컬럼이 됩니다.

식별자

속성 중 조금 특별한 속성으로 식별자가 있습니다. 식별자는 엔티티의 각 인스턴스를 고유하게 식별하는 데 사용하는 속성 또는 속성의 조합입니다. 주민등록번호로 개개인을 구분하듯 식별자로 엔티티의 모든 인스턴스를 구분합니다.
속성이 식별자로 사용되기 위해서는 다음 4가지 조건을 만족해야 합니다.

• 유일성: 식별자로 사용되는 속성의 값은 데이터베이스 내에서 다른 레코드와 겹치지 않아야 합니다.
• 불변성: 식별자로 지정된 속성의 값은 생성된 후에도 변경되지 않아야 합니다.
• 존재성: 모든 레코드는 반드시 식별자 속성을 가져야 하며, 식별자 값이 없는 레코드는 존재할 수 없습니다.
• 최소성: 식별자는 유일성을 보장하기 위해 필요한 최소한의 속성으로만 구성되어야 하며, 불필요한 속성을 포함되지 않아야 합니다.

입문 단계에서 알아야 할 주요 식별자로는 기본 식별자, 대체 식별자, 외래 식별자가 있습니다.

• 기본 식별자
  엔티티 내 모든 인스턴스를 고유하게 식별하는 속성 또는 속성의 조합입니다. 값이 반드시 존재하고 유일해야 합니다 (예: 사용자 엔티티의 ID).
• 대체 식별자
  기본 식별자로 선택되지 않은 후보 식별자입니다. 대체 식별자도 식별자이므로 값이 반드시 존재하고 유일해야 합니다 (예: 사용자 엔티티의 이메일).
• 외래 식별자
  한 엔티티의 식별자가 다른 엔티티의 식별자를 참조해 관계를 만드는 식별자입니다 (예: 주문 엔티티의 사용자 ID).

식별자와 키는 같은 뜻의 용어입니다. 데이터 모델링에서는 '식별자', 데이터베이스에서는 '키'라는 용어를 사용할 뿐입니다.
따라서 기본 식별자는 기본키(PK), 대체 식별자는 대체키(Alternate Key, AK), 외래 식별자는 외래키(FK)와 같다고 이해하면 됩니다.

• 기본 식별자 = 기본키(PK)
• 대체 식별자 = 대체키(AK)
• 외래 식별자 = 외래키(FK)

10.2.3 관계

관계란 두 엔티티 간 연결된 방식을 나타내는 것으로, 관계를 설명할 때 카디널리티라는 개념을 사용합니다.

카디널리티란 엔티티의 한 인스턴스가 다른 엔티티의 몇 개 인스턴스와 연결되는지를 나타냅니다.

관계는 카디널리티가 하나(one)냐 여럿(many)이냐에 따라 다음 3가지로 나뉩니다.

• 일대일 관계(1:1, one-to-one)
  엔티티의 한 인스턴스가 상대 엔티티의 한 인스턴스와만 연결되는 관계입니다. 하나의 국가는 하나의 수도만 가지므로 '국가'와 '수도'는 일대일 관계입니다.
• 일대다 관계(1:N, one-to-many)
  엔티티의 한 인스턴스가 상대 엔티티의 여러 인스턴스와 연결되는 관계입니다. 한 팀은 여러 선수로 구성되므로 '팀'과 '선수'는 일대다 관계입니다. 일대다 관계는 상대 엔티티 입장에서는 다대일 관계(N:1, many-to-one)입니다.
• 다대다 관계(N:M, many-to-many)
  두 엔티티 A와 B가 있을 때, A의 한 인스턴스가 B의 여러 인스턴스와 연결될 수 있고, 반대로 B의 한 인스턴스가 A의 여러 인스턴스와 연결될 수 있는 관계를 말합니다. 하나의 주문이 여러 상품을 포함할 수 있고, 하나의 상품도 여러 주문에 포함할 수 있으므로 '주문'과 '상품'은 다대다 관계입니다.

관계를 실제 데이터베이스에서 구현할 때는 기본키와 외래키의 참조를 통해 구현합니다.

• 일대일 관계: 양쪽 테이블 중 어느 쪽에 외래키를 두어도 상관없지만, 주로 사용 빈도가 더 적은 테이블에 외래키를 둡니다.
• 일대다 관계: '다' 쪽 테이블에 왜래키를 둡니다.
• 다대다 관계: 중간 테이블을 만들어 양쪽 테이블의 기본키를 가져와 외래키로 사용합니다.

10.2.4 ER 다이어그램

ER 다이어그램(Entity-Relationship Diagram, ERD)은 데이터 모델을 정의하는 시각적 도구로, 엔티티, 속성, 관계를 기호로 그린 것입니다.
ER 다이어그램에서 엔티티는 사각형, 속성은 엔티티 내부의 텍스트, 관계는 직선으로 나타냅니다.
특히 직선에는 관계의 카디널리티도 표시하는데, 카디널리티가 하나(one)일 경우에는 직선 끝에 수직선을 그리고, 다수(many)일 경우에는 직선 끝에 까치발 모양을 그립니다.

ER 다이어그램에서 관계는 카디널리티뿐만 아니라 선택성도 나타낼 수 있습니다. 선택성이란 관계에 참여하는 엔티티가 선택적으로 관계를 맺을 수 있는지 아니면 필수로 관계를 맺어야 하는지를 나타내는 개념입니다. 선택적으로 관계를 맺을 수 있다면 선택적 관계, 필수로 관계를 맺어야 한다면 필수적 관계라고 합니다.

• 선택적 관계
  카디널리티가 0부터 시작하며, 관계를 나타내는 직선에 원(o)을 추가해 나타냅니다.
• 필수적 관계
  카디널리티가 1부터 시작하며, 관계를 나타내는 직선에 수직선(|)을 추가해 나타냅니다.

다음 그림의 (a)와 (b)는 선택적 관계를, (c)와 (d)는 필수적 관계를 나타냅니다.

• (a)
  일대일 관계에 원(o)이 추가됐습니다.
  따라서 두 엔티티의 카디널리티 범위는 0~1이며, 이를 '선택적 일대일 관계'라고 합니다.
• (b)
  일대다 관계에 원(o)이 추가됐습니다.
  따라서 두 엔티티의 카디널리티 범위는 0~N이며, 이를 '선택적 일대다 관계'라고 합니다.
• (c)
  일대일 관계에 수직선(|)이 추가됐습니다.
  따라서 두 엔티티의 카디널리티 범위는 1~1이며, 이를 '필수적 일대일 관계'라고 합니다.
• (d)
  일대다 관계에 수직선(|)이 추가됐습니다.
  따라서 두 엔티티의 카디널리티 범위는 1~N이며, 이를 '필수적 일대다 관계'라고 합니다.

ERD 예시

위 그림에서 사용자의 프로필에 대한 카디널리티가 0~1입니다. 이는 사용자의 프로필이 없을 수도 있고, 있다면 단 하나의 프로필만 가진다는 의미입니다.
따라서 사용자와 프로필 엔티티는 선택적 일대일 관계입니다.

반대로 프로필은 반드시 1명의 사용자를 참조해야 합니다.
따라서 프로필의 사용자에 대한 카디널리티는 1~1, 즉 필수적 일대일 관계입니다.

위 그림에서 사용자를 기준으로 주문에 대한 카디널리티는 0~N입니다.
이는 선택적 일대다 관계로 사용자가 주문을 하지 않을 수도 있고 여러 주문을 할 수도 있다는 말입니다.

반대로 주문을 기준으로 사용자에 대한 카디널리티는 0~1입니다.
이는 선택적 일대일 관계로 주문이 어떤 사용자와도 관계가 없을 수 있고, 한 명의 사용자와 관계가 있을 수 있다는 의미입니다.
주문이 어떤 사용자와도 관계가 없다는 말은 곧 비회원으로 주문할 수 있다는 것을 의미합니다.

관계를 실제 데이터베이스에서 구현할 때는 기본키와 외래키의 참조를 통해 구현합니다. 그리고 관계의 선택성은 다음과 같이 구현합니다.

• 선택적 관계 구현
  아무런 설정을 하지 않아도 됩니다.
• 필수적 관계 구현
  두 엔티티 간에 관계를 맺기 위해 사용한 외래키에 값이 반드시 입력되도록 NOT NULL 제약 조건을 설정합니다.

10.3 정규화

10.4.1 정규화의 개념

정규화(normalization)란 데이터 모델링 시 데이터가 중복으로 저장되는 것을 최소화하고 데이터 무결성을 보장하기 위해 데이터를 구조화하는 작업입니다. 정규화를 수행하면 잘못된 설계를 발견하고 개선할 수 있습니다.
정규화 과정은 3단계로 나뉩니다. 각 단계를 특정 조건을 만족해야 다음 단계로 넘어갑니다.

제1정규형(First Normal Form, 1NF)

• 각 속성은 원자값(더 이상 분해할 수 없는 값)을 가져야 합니다.
• 같은 속성이라면 모두 동일한 자료형을 가져야 합니다.
• 각 인스턴스는 고유해야 합니다.

제2정규형(Second Normal Form, 2NF)

• 제1정규형을 만족해야 합니다.
• 기본키가 아닌 일반 속성은 기본키의 전체 속성에 의해 결정돼야 합니다.

제3정규형(Third Normal Form, 3NF)

• 제2정규형을 만족해야 합니다.
• 기본키가 아닌 일반 속성은 다른 일반 속성에 의해 결정되지 않아야 합니다.

정규화는 이 3단계 외에도 보이스-코드 정규형, 제4정규형, 제5정규형이 더 있습니다. 하지만 일반적으로 제3정규형까지 만족하면 충분히 올바른 설계라 할 수 있습니다.

10.4.2 제1정규형

제1정규형의 핵심은 속성 값의 원자화(atomicity)입니다. 속성을 더 이상 분해할 수 없을 때까지 잘게 나눠야 한다는 것입니다.

예시: 수강 테이블

이 테이블이 제1정규형을 만족하는지 체크해 봅시다.

• 각 속성은 원자값을 가져야 한다. (X)
• 같은 속성이라면 모두 동일한 자료형을 가져야 한다. (O)
• 각 인스턴스는 고유해야 한다. (O)

확인 결과 수강 테이블은 제1정규형을 만족하지 않습니다. 수강자 속성이 원자값을 가지지 않고 여러 수강자와 성적을 저장하고 있기 때문입니다.

이렇게 테이블을 잘못 설계하면 이상 현상이 발생할 수 있습니다. 이상 현상(anomaly)이란 테이블 설계가 잘못됐거나 비효율적일 때 발생하는 문제로, 테이블에 데이터를 삽입, 삭제, 수정할 때 비정상적인 결과가 나오는 것을 말합니다.
예를 들어, 홍길동이 수강하는 강의를 '수학'에서 '코딩'으로 변경하면 의도치 않게 이순신과 장영실도 '코딩'을 듣는 것으로 바뀌는데, 이는 데이터 수정 과정에서 발생한 이상 현상의 예입니다.

제1정규형을 만족하려면 수강자 속성에 원자값이 저장되도록 수강자 속성을 '학생명'과 '성적'으로 나누어야 합니다.

하지만 위 수강 테이블은 제1정규형을 만족할 뿐 올바르게 설계되었다고 볼 수 없습니다. 왜 그런지 계속해서 2정규형을 알아보겠습니다.

10.4.3 제2정규형

제2정규형의 핵심은 부분 함수 종속을 제거하는 것입니다. 이는 기본키가 아닌 일반 속성이 기본키를 구성하는 전체 속성에 의해 결정되지 않으면 해당 일반 속성을 다른 테이블로 분리하라는 뜻입니다.

위 테이블의 기본키는 '강의 ID'와 '학생명' 2개의 속성으로 이루어진 복합키(강의 ID, 학생명)이고, 기본키가 아닌 일반 속성은 '강의명'과 '성적'입니다.

• 수강 테이블의 기본키: (강의ID, 학생명)
• 수강 테이블의 일반 속성: 강의명, 성적

수강 테이블이 제2정규형을 만족하는지 체크해보면 다음과 같습니다.

• 제1정규형을 만족해야 한다. (O)
• 기본키가 아닌 일반 속성은 기본키의 전체 속성에 의해 결정돼야 한다. (X)

두 번째 조건에 따르면 일반 속성인 '성적'은 기본키의 전체 속성(강의 ID, 학생명)에 의해 결정됩니다. 하지만 '강의명'은 기본키의 전체 속성(강의 ID, 학생명)이 아닌 '강의 ID'만 있어도 결정됩니다. 따라서 수강 테이블은 제2정규형을 만족하지 않습니다.
제2정규형에 따르면 한 테이블에는 완전 함수 종속 관계만 남기고 부분 함수 종속은 다른 테이블로 분리해야 합니다.

완전 함수 종속과 부분 함수 종속

• 완전 함수 종속
  일반 속성이 기본키 전체에 종속된 경우를 말합니다.
  수강 테이블에서 '성적'은 기본키(강의 ID, 학생명)에 완전 함수 종속됩니다.
• 부분 함수 종속
  일반 속성이 기본키의 일부에만 종속된 경우를 말합니다.
  수강 테이블에서 '강의명'은 기본키(강의 ID, 학생명) 중 '강의 ID'에만 종속되므로 부분 함수 종속입니다.

수강 테이블에서 부분 함수 종속을 제거하기 위해 '강의 ID'와 '강의명'을 기존 테이블로부터 분리해 신규 테이블로 만듭니다.

10.4.4 제3정규형

제3정규형의 핵심은 이행적 함수 종속을 제거하는 것입니다. 쉽게 말해 기본키가 아닌 일반 속성에 의해 결정되는 또 다른 일반 속성이 있다면 이를 별도의 테이블로 나누는 것입니다.
예를 들어 앞서 만든 수강 테이블에 성적을 숫자로 환산한 '평점' 속성을 추가한다고 해 봅시다. 이 경우 '평점'은 기본키(강의 ID, 학생명)가 아닌 '성적'에 의해 결정됩니다. 즉, 기본키(강의 ID, 학생명)가 '성적'을 결정하고, '성적'이 '평점'을 결정하는 관계가 성립되는데, 이를 이행적 함수 종속이라고 합니다.

이행적 함수 종속을 가진 테이블은 제3정규형을 만족하지 못합니다.

• 제2정규형을 만족해야 한다. (O)
• 기본키가 아닌 일반 속성은 다른 일반 속성에 의해 결정되지 않아야 한다. (X)

제3정규형을 만족하기 위해 '성적'과 '평점' 속성을 기존 테이블로부터 분리해 신규 테이블로 만들면 이행적 함수 종속을 제거할 수 있습니다.

10.5 정리

10.5.1 데이터 모델링

현실 세계의 어떤 사물이나 현상을 추상화(모형화) 해 데이터 간 구조와 관계를 정의한 '데이터 모델'을 만드는 과정입니다.
데이터 모델링은 개념적 데이터 모델링, 논리적 데이터 모델링, 물리적 데이터 모델링 단계를 거쳐 진행되며, 최종적으로 만들어진 데이터 모델은 데이터베이스의 설계도가 됩니다.

10.5.2 개념적 데이터 모델링

현실 세계를 구성하는 주요 엔티티와 그들 간 관계를 정의하는 것입니다.
요구사항을 분석해 핵심 엔티티를 찾고, 이들 간 관계를 분석해 정의합니다.

10.5.3 논리적 데이터 모델링

개념적 데이터 모델링의 결과로 만들어진 데이터 모델의 세부 내용을 정의합니다.
엔티티의 속성, 식별자, 관계의 유형 등을 정의하며, 데이터의 중복을 제거하고 데이터베이스 운영의 효율을 높이기 위해 정규화를 수행합니다.

10.5.4 물리적 데이터 모델링

논리적 데이터 모델링의 결과로 만들어진 데이터 모델을 특정 DBMS에 맞게 최적화합니다.
데이터베이스의 물리적 저장 방식, 접근 방식, 성능 등을 고려해 최적의 세부 사항(테이블명, 컬럼명, 기본키, 외래키, 자료형, 제약 조건, 인덱스 등)을 설계합니다.

10.5.5 엔티티

데이터베이스에서 관리하려는 핵심 대상으로, 비즈니스에서 실제로 존재하거나 개념적으로 중요한 것을 모형화한 것입니다.
엔티티를 실제 데이터베이스로 구현하면 테이블이 됩니다.

10.5.6 속성

엔티티의 특성이나 정보를 나타내는 항목으로, 속성이 모여 하나의 엔티티를 구성합니다.
속성을 실제 데이터베이스에 구현하면 테이블의 컬럼이 됩니다.

10.5.7 식별자

엔티티의 모든 인스턴스(테이블에 행 단위로 저장된 데이터)를 고유하게 식별하는 속성 또는 속성의 조합입니다. 속성이 식별자로 사용되기 위해서는 유일성, 불변성, 존재성, 최소성을 만족해야 합니다.

• 유일성: 식별자로 사용되는 속성의 값은 데이터베이스 내에서 다른 레코드와 겹치지 않아야 합니다.
• 불변성: 식별자로 지정된 속성의 값은 생성된 후에도 변경되지 않아야 합니다.
• 존재성: 모든 레코드는 반드시 식별자 속성을 가져야 하며, 식별자 값이 없는 레코드는 존재할 수 없습니다.
• 최소성: 식별자는 유일성을 보장하기 위해 필요한 최소한의 속성으로만 구성되어야 하며, 불필요한 속성을 포함되지 않아야 합니다.

10.5.8 관계

두 엔티티 간 연결된 방식을 나타낸 것으로, 카디널리티(엔티티의 한 인스턴스가 다른 엔티티의 몇 개 인스턴스와 연결되는지)에 따라 일대일 관계, 일대다 관계, 다대다 관계로 나뉩니다.

• 카디널리티란 두 엔티티 간의 관계에서 한 엔티티의 특정 인스턴스가 다른 엔티팅의 몇 개의 인스턴스와 연결될 수 있는지를 나타내는 기준입니다.
  예를 들어, 한 사용자가 여러 개의 주문을 할 수 있다면 이는 일대다 관계가 됩니다. 반대로, 하나의 주문이 하나의 사용자와만 연결된다면 이는 일대일 관계입니다.

10.5.9 ER 다이어그램

데이터 모델을 정의하는 시각적 도구로 엔티티는 사각형, 속성은 엔티티 내부의 텍스트, 관계는 두 엔티티 사이를 연결하는 직선으로 나타냅니다.
카디널리티가 하나인 경우에는 직선에 수직선을, 다수인 경우에는 직선에 까치발 모양을 추가합니다.

선택성이란 관계에 참여하는 엔티티가 선택적으로 관계를 맺을 수 있는지 아니면 필수로 관계를 맺어야 하는지를 의미합니다.
선택적 관계는 관계 직선에 원(O)을 추가하고, 필수적 관계는 수직선(|)을 추가합니다.

10.5.10 인덱스

데이터베이스에서 검색 및 정렬 성능을 최적화하는 데이터 구조로, 테이블 전체를 스캔하지 않고도 데이터를 효율적으로 찾을 수 있도록 해 줍니다. MySQL은 기본키(PK), 외래키(FK), 고유키(UK)에 자동으로 인덱스를 생성하는데, 사용자가 특정 컬럼에 인덱스를 직접 생성할 수도 있습니다.

10.5.11 정규화

데이터 모델링 시 데이터가 중복으로 저장되는 것을 최소화하고 데이터 무결성을 보장하기 위해 데이터를 구조화하는 작업입니다.
제1정규형, 제2정규형, 제3정규형, 보이스-코드 정규형, 제4정규형, 제5정규형까지의 단계가 있으며, 일반적으로 제3정규형까지 만족하면 충분히 올바른 설계라 할 수 있습니다.

제1정규형

• 각 속성이 원자값을 가져야 합니다.
• 같은 속성이라면 모두 동일한 자료형을 가져야 합니다.
• 각 인스턴스는 고유해야 합니다.

제2정규형

• 제1정규형을 만족해야 합니다.
• 기본키가 아닌 일반 속성은 기본키의 전체 속성에 의해 결정되어야 합니다.

제3정규형

• 제2정규형을 만족해야 합니다.
• 기본키가 아닌 일반 속성은 다른 일반 속성에 의해 결정되지 않아야 합니다.