4과목 ① — 모델링 이해와 개념 데이터 모델링

4과목은 20문항 / 40 %로 혼자서 나머지 세 과목과 맞먹는다. 공식 출제 범위는 네 덩어리다.

이해            모델링 개요 · 기법 · 표기법
개념 데이터 모델링  주제영역 정의 → 후보엔터티 선정 → 핵심엔터티 정의 → 관계 정의 → 개념모델 작성
논리 데이터 모델링  속성 정의 · 엔터티 상세화 · 이력관리 정의 · 품질검토
물리 데이터 모델링  물리요소 조사 · 논리-물리 변환 · 반정규화 · 품질검토

이 권은 이해와 개념 모델링을, 05권이 논리를, 06권이 물리를 다룬다.

---

1부 · 데이터 모델링 이해

1. 데이터 모델링이란

현실의 업무를 데이터 관점에서 추상화하여 약속된 표기법으로 표현하는 과정.

1.1 세 가지 관점

모델을 볼 때 무엇에 주목하는가에 따라 나뉜다.

DAsP는 데이터 관점을 다룬다. "업무 처리 절차와 분기 조건을 정의한다" 같은 보기는 프로세스 관점이므로 오답이다.

1.2 모델링의 세 가지 목적

1  업무를 정확히 이해하고 표현한다          — 분석 도구
2  관련자 사이의 의사소통 수단이 된다        — 소통 도구
3  데이터베이스 구축의 청사진을 제공한다      — 설계 도구

1.3 좋은 모델의 요건

업무 규칙 표현이 자주 나온다. "화면에서 통제하면 된다" 는 규칙이 모델에 없다는 뜻이라 오답이다. 다른 경로로 데이터가 들어오면 막을 수 없다.

---

2. 데이터 모델링 기법

2.1 하향식과 상향식

둘은 함께 쓴다. 하향식으로 뼈대를 잡고 상향식으로 검증하는 것이 실무의 일반적 방식이다. "두 기법은 함께 쓸 수 없다" 는 오답이다.

2.2 모델링 접근 순서

전사 데이터 모델  →  업무 영역 데이터 모델  →  개별 시스템 데이터 모델
     (전사 관점)         (주제 영역 단위)          (구축 단위)

위로 갈수록 추상적이고 안정적이며, 아래로 갈수록 구체적이고 자주 바뀐다.

---

3. 표기법

3.1 IE 표기법 (Information Engineering)

가장 널리 쓰인다. 까마귀발(Crow's Foot)로 다(多)를 표시한다.

관계선      실선 = 식별관계      점선 = 비식별관계
자식 쪽     ─<   다(M)          ─│   하나(1)
참여        ─○   선택(0 허용)    ─│   필수(1 이상)

조합해서 읽는다.

──○<     0 또는 다      (선택 참여, 다)
──│<     1 이상         (필수 참여, 다)
──○│     0 또는 1       (선택 참여, 하나)
──││     정확히 1       (필수 참여, 하나)

3.2 바커 표기법 (Barker)

오라클 계열에서 쓴다.

관계선      실선 = 필수 참여     점선 = 선택 참여
자식 쪽     까마귀발로 다(多) 표시
식별자      #  주식별자,  *  필수 속성,  o  선택 속성

핵심 차이 — IE는 실선/점선으로 식별관계 여부를, 바커는 실선/점선으로 참여 필수 여부를 나타낸다. 같은 점선이 두 표기법에서 다른 뜻이다.

3.3 자주 나오는 함정

✗  IE 표기법에서는 식별관계와 비식별관계를 구분할 수 없다
   → 실선·점선으로 구분한다

✗  표기법이 다르면 모델이 담는 의미도 달라진다
   → 표기 수단만 다를 뿐 같은 의미를 표현할 수 있다

---

2부 · 개념 데이터 모델링

개념 모델링의 공식 절차는 다섯 단계다.

순서 문제가 매 회 나온다. 범위를 정하고 → 후보를 모으고 → 핵심을 고르고 → 잇고 → 그린다.

---

4. 주제 영역 정의

4.1 무엇인가

업무를 성격이 유사한 데이터 집합 단위로 묶은 상위 분류.

고객 영역   고객, 고객연락처, 고객등급
상품 영역   상품, 상품분류, 상품가격이력
주문 영역   주문, 주문상세, 주문상태이력

4.2 왜 먼저 하는가

전사 데이터를 한 번에 그리면 읽을 수 없다. 범위를 나누어야 각 영역을 독립적으로 진행하고 나중에 합칠 수 있다.

4.3 분할 기준

기준이 아닌 것도 나온다.

✗  엔터티 수를 영역마다 같게 맞춘다
✗  테이블 파일이 생성된 날짜
✗  엔터티의 예상 인스턴스 건수
✗  물리 테이블과 1:1로 대응시킨다

주제 영역은 여러 엔터티를 포함하는 단위이지 테이블과 대응하는 개념이 아니다.

4.4 분할 시 원칙

· 영역 사이의 중복이 최소가 되게 한다
· 영역 사이의 관계(참조)가 최소가 되게 한다
· 하나의 영역이 지나치게 커지지 않게 한다

---

5. 후보 엔터티 선정

5.1 도출 방법

업무 기술서 · 요건 정의서 · 인터뷰 결과에서 명사 추출
        ↓
후보 목록 작성
        ↓
검증 · 정제
        ↓
후보 엔터티 확정

5.2 검증 기준

명사를 뽑는 것은 시작일 뿐이다. 검증 없이 확정하면 안 된다.

5.3 정제 작업

중복 통합    회원 / 고객 → 하나로
동의어 정리  거래처 / 공급사 → 대표 용어 결정
분해         '주문정보' → 주문 + 주문상세
제외         관리 대상이 아닌 후보 제거

5.4 명명 원칙

· 업무에서 실제로 쓰는 용어를 쓴다
· 표준 용어 사전의 용어를 조합한다
· 단수형 명사로 쓴다
· 약어보다 의미가 분명한 이름을 쓴다
· '정보' '내역' 같은 군더더기를 붙이지 않는다
· 화면 이름을 그대로 쓰지 않는다

화면 이름 금지가 특히 자주 나온다. 화면은 가장 자주 바뀌는 대상이라, 엔터티명으로 쓰면 화면 개편 때마다 데이터 구조의 이름이 흔들린다.

---

6. 핵심 엔터티 정의

6.1 무엇이 핵심인가

업무의 중심이 되고 다른 엔터티와의 관계가 집중되는 엔터티.

판단 기준은 셋이다.

· 업무 흐름의 중심에 있는가
· 관계가 여러 방향으로 뻗는가
· 다른 엔터티가 이것을 참조하는가

6.2 엔터티 분류

두 축으로 나뉜다. 둘을 섞은 보기가 함정으로 나온다.

유형에 따라 — 실체가 있는가

발생 시점에 따라 — 무엇에 의존하는가

자주 나오는 함정 — "기본 엔터티는 다른 엔터티로부터 파생되어 생성된다". 기본은 스스로 존재하는 것이고, 파생되는 것은 행위 엔터티다.

6.3 코드 엔터티

값의 목록을 제공하는 엔터티다. 핵심 엔터티가 아니다.

주문상태코드(코드값, 코드명, 사용여부)

참조되는 관계가 많더라도 업무가 그것을 중심으로 돌아가지 않으므로 부가 엔터티로 분류한다.

---

7. 관계 정의

7.1 관계의 세 가지 속성

셋을 섞은 보기가 반복 출제된다. 차수는 엔터티 수, 카디널리티는 인스턴스 수로 구분한다.

7.2 관계 읽기 — 양방향

관계는 양방향으로 문장을 만들어 업무 규칙과 맞는지 확인한다.

부서 → 사원   "한 부서에 사원이 여럿 있을 수 있다"
사원 → 부서   "한 사원은 하나의 부서에 속한다"

한 방향만 읽으면 반대 방향의 오류를 놓친다. 겸직이 가능한 조직이라면 이 모델은 틀렸다.

현업 확인 방법 — 기호를 설명하지 말고 업무 문장으로 물어야 한다. 현업은 카디널리티 기호를 판단할 수 없지만 "한 사원이 두 부서에 속할 수 있나요?"에는 즉시 답할 수 있다.

7.3 관계의 종류

7.4 M:N 관계의 해소

관계형 구조는 다대다를 직접 표현하지 못한다.

교차 엔터티를 두어 1:M 두 개로 분해한다.

수강신청(학번, 강의코드, 신청일시, 성적)
          └────┬────┘
        두 부모의 식별자가 주식별자

교차 엔터티는 단순한 연결 고리가 아니다. 관계 자체가 갖는 속성(신청일시, 성적)을 담을 자리가 된다. 이 속성들은 학생의 것도 강의의 것도 아니고 "이 학생이 이 강의를 들은 건" 의 속성이다.

7.5 순환 관계

같은 엔터티의 인스턴스끼리 맺는 관계다.

장점    계층 깊이와 무관하게 엔터티 하나로 표현
사례    조직도, 부품 구성(BOM), 카테고리 트리, 댓글 트리
주의    최상위는 참조 대상이 없으므로 선택 참여여야 한다

함정 — "순환 관계에서는 외래식별자가 생성되지 않는다". 상위부서코드가 바로 외래식별자다. 참조 대상이 자기 자신일 뿐이다.

7.6 배타적 관계

여러 관계 중 하나만 성립하는 구조다.

결제(결제번호, 결제수단구분, 카드번호, 계좌번호)

  '카드' → 카드번호만 존재, 계좌번호 NULL
  '계좌' → 계좌번호만 존재, 카드번호 NULL

동시에 성립할 수 없으므로 배타적 서브타입으로 모델링하는 것이 일반적이다.

7.7 관계 정의 시 확인 사항

✓  두 엔터티 사이에 업무적 연관이 실제로 존재하는가
✓  카디널리티가 업무 규칙과 일치하는가
✓  참여가 필수인지 선택인지 확인했는가
✓  관계에 업무 용어로 이름을 붙였는가

✗  관계는 많을수록 좋으므로 최대한 연결한다

근거 없는 관계는 제약과 조인 경로만 늘려 모델을 읽기 어렵게 만든다. "관련 있어 보여서" 는 업무 규칙이 아니다.

---

8. 개념 모델 작성

8.1 무엇을 담는가

담는다      핵심 엔터티 10여 개 · 주요 관계 · 주제 영역 구분
안 담는다   전체 속성 · 자료형 · 식별자 확정 · 인덱스

세부를 덜어 내는 것이 목적이다. 한 장에서 전체가 보여야 소통 도구로 쓸 수 있다.

8.2 활용

8.3 자주 나오는 함정

✗  모든 속성과 데이터 타입을 빠짐없이 정의해야 한다
   → 논리·물리 단계의 일이다

✗  정규화를 마친 전체 엔터티를 담는다
   → 그것은 논리 모델이다

✗  물리 테이블의 DDL 을 현업에게 보여 준다
   → 현업이 판단할 수 없는 형식이다

---

9. 한 줄 정리