| 단계 | 설명 | 특징 |
|---|---|---|
| 개념적 모델링 | 현실 세계의 중요 데이터와 관계를 추상적으로 표현 | 엔터티와 관계 중심으로 기술, 포괄적, 업무 중심 |
| 논리적 모델링 | 특정 데이터베이스 기술에 독립적으로 데이터 구조를 설계 | 모든 엔터티, 속성, 관계, 식별자 정의, 정규화 수행 |
| 물리적 모델링 | 특정 데이터베이스 시스템에 맞게 물리적 구조를 설계 | 테이블, 컬럼, 인덱스 등 구체적 객체 설계, 성능 고려 |
| 구분 | 설명 | 예시 |
|---|---|---|
| 유형 vs 무형 | 물리적 형태 유무에 따라 구분 | 유형: 사원, 상품, 건물 무형: 부서, 주문, 과정 |
| 발생 시점 | 업무 발생에 따른 구분 | 기본/키 엔터티: 사원, 부서 (독립적으로 생성) 중심 엔터티: 주문, 수강 (기본 엔터티로부터 파생) 행위 엔터티: 주문이력, 수강이력 (중심 엔터티로부터 파생) |
| 구분 | 설명 | 예시 |
|---|---|---|
| 기본/설계/파생 | 속성의 생성 방식에 따른 분류 | 기본: 사원명, 상품가격 (업무에서 자연 발생) 설계: 상품코드, 주문번호 (업무 규칙에 따라 인위적 생성) 파생: 총주문금액, 나이 (다른 속성으로부터 계산) |
| 단일값/다중값 | 하나의 인스턴스에 몇 개의 값을 갖는지 | 단일값: 사원번호 (하나의 값만 가짐) 다중값: 전화번호 (여러 값을 가질 수 있음) → 정규화 대상 |
| 단순/복합 | 속성의 분해 가능 여부 | 단순: 나이 (더 이상 분해 불가) 복합: 주소 (시, 구, 동으로 분해 가능) → 정규화 대상 |
관계 차수 (Cardinality): 두 엔터티 간에 참여하는 인스턴스의 개수를 나타냅니다.
사원은 하나의 좌석만 가질 수 있다.부서에는 여러 사원이 소속될 수 있다. (가장 일반적인 관계)학생은 여러 과목을 수강하고, 한 과목은 여러 학생이 수강한다. → 관계형 DB에서 직접 표현 불가, 중간에 관계 엔터티(수강)를 두어 1:N 관계로 해소해야 함.관계 선택성 (Optionality): 다른 엔터티와의 관계가 필수적인지 선택적인지를 나타냅니다.
|: 주문은 반드시 고객이 있어야만 존재할 수 있다. (실선)O: 사원은 프로젝트에 참여할 수도, 안 할 수도 있다. (점선)(학번, 과목코드)는 식별자이지만, (학번, 과목코드, 이름)은 최소성 위반)NOT NULL)| 구분 | 설명 |
|---|---|
| 주/보조 식별자 | 주 식별자: 엔터티를 대표하는 식별자 (PK). 보조 식별자: 유일성은 만족하지만 대표는 아닌 식별자 (Unique Index). |
| 내부/외부 식별자 | 내부 식별자: 엔터티 내부에서 스스로 생성된 식별자 (e.g., 사원번호). 외부 식별자: 다른 엔터티와의 관계를 통해 받아온 식별자 (FK). |
| 식별/비식별 관계 | 식별 관계: 부모 엔터티의 식별자를 자식 엔터티가 자신의 주 식별자로 사용하는 관계 (자식은 부모 없이 존재 불가). 비식별 관계: 부모 엔터티의 식별자를 자식 엔터티가 일반 속성으로 사용하는 관계 (자식은 부모 없이도 존재 가능). |