2.1 관계형 데이터 모델 (Relational Data Model)

💡 핵심
- 데이터를 집합적으로 다루어 조회·성능을 극대화하는 모델
- 함수 종속에 기반해 정규화(Normalization)로 데이터 중복을 줄인다.

릴레이션(Relation)

• 관계형 모델에서 기초가 되는 개념으로, 관계형 데이터베이스(Relational Database) 이름의 기원
• 테이블 형태의 2차원 데이터로 어트리뷰트(head)와 튜플(body)의 집합으로 구성

유효한 릴레이션 기준

• 차수(컬럼) ≥ 1
• 카디널리티(튜플) ≥ 0

RDB 장점

• 데이터 정합성 유지, 성능 차원에서 가장 효과적
• 조인으로 중복 최소화

RDB 단점

• 효율적인 데이터 구조 설계 어려움

2.2 무결성(Integrity)

💡 무결성(Integrity)의 의미

• 데이터가 정확하고 완전해야 한다.

정합성과 비교

• 정합성: 데이터 간 모순없는 일관성
• 무결성: 정확성 + 일관성 포함하는 상위 개념

시간에 따른 훼손

• 무결성은 시간이 지남에 따라 깨지므로 무결성을 지키는 방법을 확보해야 한다.

🏷️ 무결성 종류

🔗 데이터베이스 옵션에서 제공하는 무결성 제약

입력 규칙

• Dependent : 상위 PK가 있을 때만, 하위 FK에 입력 가능
• Automatic : 상위 PK가 없으면 상위 엔티티 생성 후, 하위 FK에 입력
• Default : 상위 PK가 없으면 하위 FK에 기본 값으로 입력. 이때 외래 식별자에 기본 값 설정 필수
• Nullify : 상위 PK 없으면, 하위 FK에 널 값으로 입력. 이때 외래 식별자는 널 허용 설정 필수

삭제 규칙

• Restrict : 상위 PK 삭제 시, 하위 FK 없을 때만 삭제 허용
• Cascade : 상위 PK 삭제 시, 하위 해당 FK 다 삭제 후 PK 삭제
• Default : 하위 해당 FK 모두 기본 값으로 수정 후 상위 엔티티의 PK 삭제
• Nullify : 하위 해당 FK 모두 널 값으로 수정 후 상위 엔티티의 PK 삭제

수정 규칙

• Restrict : 상위 PK 업데이트 시, 하위 해당 FK가 없을 때만 PK 수정
• Cascade : 하위 해당 FK 모두 업데이트 후, 상위 PK 수정

📌 속성 수준 무결성 설계는 실무에서 현실적으로 잘 안하지만, 속성 단위의 무결성을 설계하면 모델의 완성도는 높아진다.

2.3 데이터베이스 라이프 사이클

데이터베이스 구축 단계

1️⃣ 요구사항 분석

• 어떤 데이터를 관리할지 정의
• 사용자의 의견이 최우선. 주로 현업 인터뷰를 통해 도출

2️⃣ 개념적 모델링

• 요구사항 분석과 함께 진행되는 단계
• UML 다이어그림 또는 주로 ERD 사용
• 핵심 데이터를 대상으로 한 모델링 수행. 통합된 모델 도출

3️⃣ 논리 모델링 (정규화)

• 핵심 데이터를 포함한 모든 데이터를 대상으로 한 모델링 수행
• 정규화가 핵심. 엔티티의 최소 단위 확보
  • 최대한 분리된 모델을 정규형이라 하고 정규화된 모델을 논리 모델이라 한다.

4️⃣ 물리 설계

• 논리 모델을 물리 모델로 변환
• 목적에 따라 테이블을 분해하거나 합치는 작업 진행
• 성능을 위해 비정규화 고려
  • ⚠️ 단, 정규화를 완전히 끝낸 후 비정규화 진행
• 인덱스 설계가 포함되며, 물리 설계 단계에서 완전하게 이루어지지는 않음 (이후 학습 예정)

5️⃣ DB 구축

• 물리 설계에서 도출된 여러 객체(테이블/인덱스/제약)를 생성하는 단계 (DDL 스크립트 작성)
• 모델러보단 DBA가 주도

👉이후 요구사항 추가/변경되면서 모델 변경 관리를 진행

2.4 주제 영역(Subject Area)

✅ 정의

• 데이터 아키텍처의 최상위 단계
• 비즈니스에서 중요한 것들에 대한 데이터 차원의 분류
  • e.g. 고객, 상품, 조직, 주문

주제 영역 도출의 어려움

• 기업에 존재하는 모든 데이터를 파악해야 하며, 데이터의 성격 파악이 중요
  • 데이터를 보고 어떤 성격의 데이터인지, 데이터의 주제가 무엇인지 파악
  • 업무나 프로세스밖에 볼 수 없다면 도출이 어려움

특징

• 모든 데이터는 10-20개 주제 영역에 속하게 구성, 각 주제 영역의 상세화 수준도 균일해야 함

• 실체/행위 성격으로 구분

  구분	예시	특징
  실체 영역	고객, 조직, 계좌	누가 모델링 하더라도 유사해질 수 있다.
  행위 영역	주문, 거래, 이벤트	모델링 수행하는 사람에 따라 모델이 달라질 수 있다.

활용 목적

• 대규모 시스템 구축 프로젝트에서 주제 영역 별로 모델을 구축하여 모델 간소화
• 데이터 통합
  • 이미 주제 영역이 일반화(Generalization) 개념을 사용해 데이터를 분류한 것
  • 유사한 데이터로 구성돼 있으면 데이터 통합 가능성이 커짐
• 유연한 데이터 구조
  • 데이터 성격에 따른 엔티티 도출을 통해 데이터 일관성과 관리 용이성 향상
• 이상적으로는 실무에서 가장 요긴하게 사용될 논리 모델과 주제 영역은 완전하게 연결돼야 한다.

활용 시 고려

• 기존 업무 중심 데이터 모델을 주제 영역 기준으로 전환하는 것은 부담
• 어렵더라도 이해 당사자 간 공감대만 형성되면 주제 영역을 기준으로 모델링을 수행하는 것이 좋다.

2.5 데이터 표준화

💡 데이터 명칭·정의·형식을 일관되게 통일 ➡️ 데이터 품질과 의사소통 향상

표준화 단계

• 단어 정의 (영문명·약어) ➡️ 궁극적으로 속성에 사용
• 메타 관리 시스템 연동

주의사항

• 이음동의어 문제 예방
  • e.g. 사원(staff, STAF) vs 직원(employee, EMP)
• 도메인 정의
  • e.g. 특정한 날짜를 의미 -> '일자' / 시분초까지 의미 -> 일시 / 년, 월, 일 중 일부만 의미 -> '년', '년월', '월일'
• 표준화에 매몰되어 실질적 설계를 간과하지 않기

추세

• 메타 관리 시스템 연동
  • 핵심은 엔티티 속성을 등록해 관리하는 것
• 담당자를 지정하여 속성명을 일관되게 관리

⚠️ 표준화에 몰두해 모델링 본질을 잊지 말 것!

2.6 ERD(Entity Relationship Diagram)

💡 핵심
ERD는 관계형 모델(Relational Model)의 대표 표현 도구
엔티티와 관계를 시각화
관계형 모델의 의사소통 도구로써, 문법에 맞는 표기법을 정확히 구사해야 함

ERD 작성 시 고려

1️⃣ 엔티티 배치

• 상위/하위 엔티티 관계 : 상위 엔티티가 하위 엔티티의 위쪽에 둔다. 좌우로 위치시키는 것도 괜찮다. 이때 상위 엔티티가 왼쪽.
• 슈퍼타입/서브타입 관계 : 슈퍼타입을 위쪽, 서브타입이 아래쪽. 서브타입이 많다면 슈퍼타입 오른쪽에 서브타입 위치
• 실체 엔티티/행위 엔티티 : 실체 엔티티는 모델의 위쪽, 행위 엔티티는 아래쪽. 관계가 존재하는 두 개의 행위 엔티티는 좌우로 나란히 위치시켜, 관계선을 표현한다.
• 교차 엔티티(Association Entity) : 양쪽 엔티티 사이에 위치시켜, 교차 엔티티의 좌우로 양쪽 엔티티가 위치하는 것이 가독성이 좋다.
• 엔티티 배치는 중요하다. 관계선을 표현하기 수월해지며 모델의 가독성이 좋아져서 기억하기 쉬워진다.

2️⃣ 속성 순서

• 주 식별자, 대체 식별자, 외래 식별자 -> 최상단
• 자주 쓰는 속성 -> 상단
• 일반 속성
  • 기초 속성은 엔티티 위쪽 위치
  • 주로 같이 사용되는 속성은 같은 위치에 존재. 같이 사용되지 않는 속성은 아래쪽 위치
• 널 허용 속성, 외래 식별자 중 참조 데이터로 관리하는 속성 -> 하단
• 시스템 속성 -> 가장 아래
• 긴 텍스트는 별도의 엔티티 분리 고려
• 논리 모델과 물리모델에서 속성 순서는 달라질 수 있음
  • 논리 모델에서는 가독성을 높일 수 있도록 속성을 배치하는 것이 원칙
  • 물리 모델에서는 속성을 효과적으로 저장하고 추출할 수 있도록 배치하는 것이 원칙

3️⃣ 관계선 가독성

• 선이 꼬이지 않도록 복잡하면 복제 엔티티 활용

4️⃣ 색상/폰트 구분

• e.g. 신규 속성 → 파란색
• 이슈 속성 → 빨간색
• 핵심 엔티티 → 연한 하늘색 등

5️⃣ 엔티티 배치 변경 최소화

• 리뷰 시 혼란 방지

🧩 ERD 한계 엔티티의 스키마만 표현하는 도구 중요한 데이터에 대해서는 사례 데이터를 릴레이션으로 생성해놓으면 이해도 향상

고민 포인트

1️⃣ 정규화 vs 비정규화

• 지나친 정규화로 테이블 쪼개지면 조회가 느리고 JOIN 과다 발생
• 너무 합치면 중복·데이터 무결성 저하

👉 비즈니스 요구(트래픽/조회 패턴)에 맞춰 조정

2️⃣ FK 제약 사용 유무

• DB FK 제약

  • 참조 무결성 자동 보장
  • 시스템 성능/배포 시 장애 유발

• 애플리케이션 레벨에서 무결성 검증

  • 제약 유연성 ↑
  • 개발자 실수로 인한 정합성 오류 ↑

👉 서비스 규모와 트랜잭션 특성 고려해서 결정

3️⃣ 업무 무결성(비즈니스 규칙)

• DB 제약 vs 코드 로직 어디 둘까?
  • → 주문 취소 가능 여부, 재고 검증 등

👉 데이터 안정성/비즈니스 정책 변화 주기를 고려

4️⃣ 표준화된 네이밍

2.1 관계형 데이터 모델(Relational Data Model)

• 관계형 데이터 모델은 다른 모델보다 이론이 잘 정립돼 있으며 데이터를 집합적으로 다루므로 조회가 편리하고 좋은 성능을 보인다
• 필자는 함수 종속(Functional Dependency)와 정규화(Normalization)된 모델이 관계형 모델이라 정의한다
• 릴레이션.. 어트리뷰트.. 튜플 등에 대한 개념은 넘어가도록하자
• 관계형 데이터베이스의 Relational은 릴레이션 때문에 붙여진 이름이다
• 조인을 통해서 데이터를 얻을 수 있으므로 데이터를 중복해서 저장하지 않도록 설계하는 것이 핵심이다
• 데이터 정합성과 성능 차원에서 관계형 데이터베이스가 가장 효과적이다

관계형 모델의 몇 가지 특징

• 튜플(각 행)은 유일해야 한다 (엔티티 무결성이 이에 해당한다)
• 어트리뷰트에는 유일한 값이 사용되어야 한다
• 릴레이션의 이름도 유일해야 한다
• 릴레이션이 정규화 되지 않으면 관계형 모델이라 할 수 없다
• 외래 식별자를 통해서 연관관계가 성립된다

엔터티 타입과 엔터티

• 엔터티 타입은 엔터티들의 집합(Set)
• 엔터티 타입에 속한 특정 튜플을 엔터티라고 한다
• 엔터티 타입은 동일한 어트리뷰트를 가진 엔터티의 집합이다
• 다만 엄격하게 구분할 필요는 없다

2.2 무결성(Integrity)

• 무결성은 데이터 값이 정확한 상태를 의미한다
• 정합성은 데이터가 서로 모순이 없이 일관되게 일치해야 한다는 의미이고 무결성은 데이터가 정확하고 안전해야 한다는 의미다
• 중복 데이터가 다 틀린 값으로 일치하면 정합성은 만족하지만 무결성을 만족하지 못한다

불완전한 데이터

• 데이터의 중복이 완전히 제거되더라도 불완전한 데이터는 사용될 수 있다
• 참조 무결성 제약의 생략이나 필요한 초기 값의 생략 등으로 불완전한 데이터가 생성될 수 있다
• 관계형 데이터베이스의 가장 큰 목표는 데이터 무결성을 높이는 것이다

무결성의 종류

• 엔터티 무결성(Entity Integrity)
  • 모든 인스턴스는 고유해야 하며 인스턴스를 대표하는 속성에는 널 값을 가지면 안된다
  • 엔티티 무결성은 식별자에 의해서 지켜질 수 있다
• 참조 무결성(Referential Integrity)
  • 외래 키(FK) 속성은 참조 대상 릴레이션의 기본 키(PK) 값과 일치하거나 NULL이어야 한다
  • 즉, 존재하는 값이거나 NULL이어야 한다
  • 외래 키 제약(FK Constraint)에 의해 보장된다
• 도메인 무결성(Domain Integrity)
  • 특정 속성은 같은 데이터 타입과 길이, 같은 널 여부, 같은 기본값, 같은 허용 값 등 동일한 범주의 값만이 존재해야한다
• 업무 무결성(Business Integrity)
  • 업무를 수행하는 방법이나 데이터를 처리하는 규칙
  • 물리적으로 강제하는 대표적인 방법에 트리거가 있다

물리적인 강제성으로 지켜지는 데이터 무결성

• 애플리케이션 로직보다 DBMS에서 강제하는 것이 좋다

2.3 데이터베이스 라이프 사이클

1. 요구사항 분석
   • DB에서 관리해야 하는 데이터를 도출, 분석
   • 주로 협업과 인터뷰를 통해 도출한다
2. 개념 모델링
   • 요구사항을 분석하고 나서 도출되는 데이터 측면의 결과물
   • 요구사항 분석과 독립된 단계로 보기 어렵다
   • UML 다이어그램으로 표현할 수 있지만 주로 ERD로 표현한다
   • 핵심 데이터를 대상으로 모델링을 수행하며 통합된 모델이 도출되어야 한다
3. 논리 모델링
   • 핵심 데이터 포함 모든 데이터로 모델링을 수행하는 단계
   • 가장 중요한 것은 정규화
   • 함수 종속에 의해 데이터를 분해하는 것이다
   • 정규화를 거친 엔터티는 엔터티 그 자체이다
   • 정규화 된 모델을 논리 모델이라 하며 무결성이 높아진다
4. 물리 설계
   • 논리 모델을 물리 모델로 매핑하고 분해하거나 합친다
   • 가능한 성능을 최적화 해야한다
   • 정규화가 완전히 끝난 후 비정규형을 고려한다
   • 인덱스 설계를 포함한다
5. 데이터베이스 구축
   • 물리 설계에서 도출된 여러 객체를 생성하는 단계
   • 보통 DBA가 수행한다

2.4 주제 영역(Subject Area)

• 주제 영역은 데이터 아키텍처의 최상위 단계로 비즈니스의 목표를 달성하는데 필요한 데이터 집합을 의미한다
• 주제 영역은 데이터 모델을 구축할 수 있는 훌륭한 기준이 된다
• 시스템이 점점 방대해지면 데이터 모델도 매우 크고 복잡해짖므로 주제 영역 별로 모델을 구축하면 모델이 간소화 된다

2.5 데이터 표준화

• 표준화란 일정한 기준에 따라 통일하는 것이다
• 데이터의 품질을 높이고 오류를 줄이고 관련자의 의사소통을 돕는다
• 표준화를 정의할 때 중욯산 것은 일관되도록 사용하는 것이다
• ex. 사원과 직원이 동일한 의미라면 한 단어만 사용해야 한다 --> 이음 동이어
• 혼란을 불러일으킬 수 있는 동음이의어 역시 사용하지 않는 것이 바람직하다

2.6 ERD(Entity Relationship Diagram)

• 관계형 모델은 주로 ERD로 표현한다
• 우선 엔터티를 배치하는 것이 중요하다
  • 상위 엔터티가 하위 엔터티의 위쪽에 있거나, 왼쪽에 배치하는 것이 좋다
• 교차 엔터티는 양쪽 엔터티 사이에 위치하는 것이 좋은데 상하로 위치하는 것보다 가독성이 좋다
• 엔터티에서 중요한 속성이나 자주 사용되는 속성은 엔터티 상단에 위치하는 것이 좋다
  • 단 일관된 속성 순서를 적용하는 것이 좋다
  • 성격이 유사하거나 같이 사용될 수 있는 속성은 같이 위치시킨다
  • 동시에 입력되거나 조회되는 속성도 같은 위치에 존재시킨다
• ERD에서 한번 정해진 배치는 바꾸지 않는 것이 좋다
• 관계선을 표현할 때는 관계선이 서로 얽히지 않도록 표현하고, 엔터티를 통과하지 않도록 한다
• 색상이나 밑줄, 취소선, 폰트 등을 이용하는 것도 좋은 방법이다