4과목 ② — 논리 데이터 모델링

공식 출제 범위의 세부 항목은 넷이다.

속성 정의  ·  엔터티 상세화  ·  이력관리 정의  ·  품질검토

개념 모델이 "무엇이 있는가" 를 잡았다면, 논리 모델은 "각각이 무엇을 담고 어떻게 구분되는가" 를 확정한다. 특정 DBMS를 정하지 않은 상태에서 수행한다는 것이 이 단계의 성격이다.

---

1부 · 속성 정의

1. 속성이란

엔터티가 관리해야 할 더 이상 분리되지 않는 최소의 데이터 단위.

회원(회원번호, 회원명, 생년월일, 가입일자, 등급코드)
      └──────────── 각각이 속성 ────────────┘

1.1 속성의 세 가지 원칙

1.2 원자성 위반의 두 형태

① 다중값 속성    한 칸에 값이 여럿
   회원.보유자격증 = "정보처리기사, SQLD, ADsP"
   → 회원자격증 엔터티로 분리, 한 행에 하나씩

② 반복 속성 그룹  같은 성격의 컬럼이 번호를 달고 반복
   강의.학번1, 학번2, 학번3
   → 수강신청 엔터티로 분리

②가 함정으로 나온다. 컬럼을 나누면 해결된 것처럼 보이지만, 수강생이 4명이 되면 대응할 수 없고 이것도 1NF 위반이다.

---

2. 속성의 분류

2.1 특성에 따라

2.2 구성에 따라

2.3 엔터티 구성에 따라

---

3. 파생속성 — 저장할 것인가

파생속성은 저장 여부가 설계 판단이다.

저장 안 함   항상 정확하다 · 매번 계산해야 한다
저장 함      조회가 빠르다 · 원본과 어긋날 위험이 생긴다

3.1 위험도 판단

같은 파생속성이라도 갱신 경로의 수에 따라 위험이 다르다.

회원.최종주문일자    새 주문이 생길 때만 갱신          → 경로 1개, 낮음
회원.누적주문건수    주문 생성 시 +1, 취소 시 -1       → 경로 2개, 높음

감소 경로를 빠뜨리는 것이 가장 흔한 사고다. 한 번 어긋나면 전수 재계산 전까지 드러나지 않는다.

3.2 저장하기로 했다면

· 산출 근거(계산식)를 반드시 함께 정의한다
· 갱신 시점과 갱신 주체를 명시한다
· 주기적으로 원본과 대조하는 점검을 둔다

근거가 없으면 나중에 값이 맞는지 판단할 방법이 없다.

---

4. 속성의 분해

한 칸에 여러 의미가 섞여 있으면 부분만 따로 다룰 수 없다.

분해 전   주소 = "서울특별시 강남구 테헤란로 123"
분해 후   시도 · 시군구 · 상세주소

4.1 분해의 기준

업무에서 그 단위를 독립적으로 사용하는가.

분해한다     지역별 통계를 낸다 · 시군구별 배송비를 다르게 적용한다
분해 안 한다 주소를 통째로 출력만 한다

"속성은 잘게 나눌수록 좋다" 는 오답이다. 쓰지 않는 단위까지 나누면 결합해서 보여 주는 부담만 늘어난다.

4.2 분해 시점

속성 분해는 논리 모델링에서 수행한다. 물리 단계에서 하면 이미 정의된 도메인과 표준이 어긋난다.

---

5. 속성의 배치

어느 엔터티에 넣을지는 식별자 종속 여부로 판단한다.

계약(계약번호, 거래처코드, 계약일자, 계약금액, 거래처명, 거래처대표자)
                                              └──────┬──────┘
                                    거래처코드에 종속 → 거래처로 옮겨야 함

판단 기준    이 속성이 이 엔터티의 식별자에 완전히 종속되는가
기준 아님    화면에 함께 나오는가 · 조회 빈도가 비슷한가 · 자료형이 같은가

이 판단이 곧 정규화다. 06권에서 이어진다.

---

6. 속성 명명

· 표준 용어 사전에 등록된 용어를 조합한다
· 엔터티 안에서 유일해야 한다
· 엔터티명과 중복되는 접두어는 뺀다   (회원.회원가입일자 → 회원.가입일자)
· 이름만으로 의미가 파악되어야 한다
· 짧게 만들자고 표준에 없는 말을 쓰지 않는다

마지막 항목이 함정으로 나온다. 일자 는 표준 단어지만 일 은 아니다. 길이는 명명의 기준이 아니다.

---

2부 · 엔터티 상세화

상세화는 식별자 확정 + 관계 구체화가 핵심이다.

7. 식별자

7.1 주식별자의 네 가지 요건

우선순위가 있다. 유일성이 깨지면 다른 요건을 따질 여지가 없다.

유일성 위반   식별자로 성립 불가
최소성 위반   성립하지만 자식으로 전파되는 외래키가 불필요하게 커짐
불변성 위반   성립하지만 변경 시 참조하는 모든 곳을 연쇄 수정

정도의 비교도 나온다. "이메일은 변경 신청 가능" 과 "부서코드는 이동 시 변경" 중에서는 후자가 더 부적절하다. 부서 이동은 정상 업무 과정에서 반복 발생하기 때문이다.

7.2 식별자 분류 — 네 개의 독립된 축

축이 서로 독립적이라는 것이 핵심이다.

사원.부서코드
  사원 관점   외부식별자 (부서에서 상속)
  부서 관점   본질식별자 (담당자가 업무적으로 부여)

같은 속성이 관점에 따라 다르게 불리는 것이 정상이다.

함정 — "복합식별자를 구성하는 속성은 모두 본질식별자다", "자동 채번되었으므로 내부식별자다". 기준이 다른 축을 섞은 것이다.

7.3 인조식별자 도입 판단

계약의 본질식별자 = {거래처코드, 계약연도, 계약구분, 계약일련번호}

  · 네 속성이 자식 엔터티 다섯 개로 그대로 전파된다
  · 계약구분은 업무 개편 시 값이 바뀔 수 있다

도입 근거는 복잡성과 변경 가능성이다.

얻는 것   조인 조건 단순화 · 외래키 크기 축소 · 변경 영향 차단
내주는 것 식별자만 봐서는 업무 의미를 알 수 없음

본질식별자는 삭제하지 않는다. 유일 인덱스(대체키)로 남겨 업무 규칙을 지킨다. "인조식별자를 두면 본질식별자를 지워 모델이 단순해진다" 는 오답이다.

---

8. 식별관계와 비식별관계

부모의 식별자가 자식의 주식별자에 들어가는가로 갈린다.

식별관계     주문(주문번호)  →  주문상세(주문번호, 상품번호, 수량)
                                        ↑ 주식별자의 일부

비식별관계   부서(부서코드)  →  사원(사원번호, 부서코드, 사원명)
                                          ↑ 일반 속성

8.1 선택 기준

식별관계로 둔다    자식이 부모 없이 존재할 수 없다
                   자식이 부모 안에서만 구분된다 (주문상세의 상품번호)

비식별관계로 둔다  자식이 독립적으로 존재한다
                   식별자 전파를 끊고 싶다

8.2 식별관계의 부작용

식별관계를 깊게 이어가면 손자·증손자로 갈수록 주식별자가 계속 길어진다.

주문(주문번호)
  주문상세(주문번호, 상품번호)
    주문상세이력(주문번호, 상품번호, 변경일시)
      ...

이것이 인조식별자를 도입하는 이유가 되기도 한다.

---

9. 서브타입

9.1 언제 나누는가

속성이나 관계가 일부 인스턴스에만 적용될 때 나눈다.

고객(고객번호, 고객명, 구분, 생년월일, 성별, 사업자번호, 대표자명)

  '개인' → 사업자번호·대표자명이 NULL
  '법인' → 생년월일·성별이 NULL

NULL 영역이 구분에 따라 정확히 갈리는 것이 신호다.

기준이 아닌 것
✗  속성 개수가 많아서       → 전부 공통이면 나눌 이유 없음
✗  인스턴스가 많아서        → 물리 설계의 영역
✗  테이블 용량이 커서       → 물리 설계의 영역

9.2 배타성

9.3 속성 배치

공통 속성  →  슈퍼타입
고유 속성  →  각 서브타입

9.4 관계의 상속

슈퍼타입이 맺은 관계는 모든 서브타입에 적용된다. 특정 서브타입만 갖는 관계는 그 서브타입에 직접 연결한다.

고객 ──< 문의              모든 고객이 문의 가능 → 슈퍼타입에
법인고객 ──< 세금계산서      법인만 발행 → 서브타입에

---

3부 · 이력관리 정의

10. 왜 이력을 남기는가

· 특정 시점의 상태를 되짚어야 한다 (계약 당시 등급으로 정산)
· 변경 과정을 추적해야 한다 (감사, 분쟁 대응)
· 추이를 분석해야 한다

11. 이력 관리 방식

11.1 선분 이력

시작일자와 종료일자로 유효 구간을 표현한다.

갱신    기존 행의 종료일자를 닫고 새 행 추가 (덮어쓰지 않음)
조회    시작일자 <= 기준일 <= 종료일자
현재값  종료일자 = '9999-12-31'

장점 — 시점 조회를 조건 하나로 할 수 있다.

11.2 점 이력

변경이 일어난 시점만 기록한다.

장점    구간 관리가 필요 없어 정합성 부담이 적다
단점    특정 시점 값을 알려면 그 이전의 마지막 변경을 찾아 올라가야 한다

11.3 비교

12. 선분 이력의 두 가지 결함

시험에 반복 출제된다.

12.1 구간 겹침

6월 1~30일이 양쪽에 걸쳐 시점 조회 시 두 행이 반환된다. 이전 행을 5월 31일로 닫았어야 한다.

12.2 구간 공백

6월이 어느 구간에도 속하지 않아 조회 결과가 나오지 않는다.

13. 이력 대상 선정

모든 속성에 이력을 남기면 안 된다.

회원(회원번호, 회원명, 등급코드, 주소, 최종접속일시)

  등급코드      분기마다 변경, 혜택 산정 근거      → 대상
  주소          배송 이력 대조에 필요             → 대상
  회원명        개명은 드물지만 대조에 필요        → 검토
  최종접속일시   화면 진입마다 갱신, 과거값 무가치  → 제외

이력이 정합성을 보장하지 않는다. 오히려 구간 겹침·공백이라는 새 오류 유형이 생긴다. "이력을 남기면 정합성이 자동으로 보장된다" 는 오답이다.

---

4부 · 논리 모델 품질검토

14. 검토 항목

특성을 가르는 연습이 필요하다.

아예 없다      → 완전성
있는데 틀렸다   → 정확성
같은데 다르다   → 일관성
기준을 어겼다   → 준거성

15. 검토 방법

✓  관련자가 모여 모델을 함께 읽는 리뷰
✓  실제 업무 사례(특히 예외 사례)를 대입해 표현되는지 확인
✓  체크리스트로 항목별 누락 점검
✓  샘플 데이터를 넣어 제약이 동작하는지 확인

방법이 아닌 것도 나온다.

✗  모델 파일의 용량 · 작성 소요 시간 · 작성자 경력
✗  엔터티 수가 목표 개수에 도달했는지
✗  모델링 도구의 문법 검사 통과 여부

마지막 것이 미묘하다. 문법 오류가 없어도 업무를 잘못 표현할 수 있다.

16. 논리 단계에서 확인하지 않는 것

✗  DBMS 의 최대 컬럼 수 제한
✗  테이블별 예상 저장 용량
✗  테이블스페이스 배치
✗  인덱스 구성

전부 물리 설계의 관심사다. 논리 모델은 DBMS 독립적으로 검토한다.

---

17. 한 줄 정리