현실에서 응용할 데이터를 잘 고르고 다듬어서 DBMS에 저장하는 방법이다. 주어진 개념으로부터 논리적인 데이터 모델을 구성하는 작업을 의미한다. 물리적인 데이터베이스 모델로 만들어 반영하는 작업을 포함한다.
데이터 모델링 과정은 크게 아래 4가지 단계로 이루어진다.
- 요구사항 분석 (Requirements Analysis)
: 요구사항을 데이터의 관점에서 분석한다. 요구사항 분석서가 산출된다. - 개념적 설계 (Conceptual Database Design)
: 요구사항을 조금 더 정형화하기 위해 사용된다. 요구사항 분석서를 통해 ERD(Entity-Relationship Diagram)가 산출된다. - 논리적 설계 (Logical Database Design)
: ERD를 실질적 데이터베이스 형태로 바꾸기에는 어렵기 때문에 관계 데이터 모델로 만든다. 관계형 데이터 모델(Relational data model) 또는 논리스키마가 산출된다. - 물리적 설계 (Physical Database Design)
: 논리스키마를 사용하여 실질적인 SQL를 통해 데이터베이스 테이블을 생성한다.
데이터의 관점에서 요구사항을 분석한다.
- 부서는 부서이름, 부서번호, 한명의 부장을 가진다.
- 부장의 업무 시작 날짜를 기록한다.
- 부서는 하나 이상의 장소에 있을 수 있다.
- 부서는 여러 프로젝트를 관리한다.
- 프로젝트는 고유번호, 고유이름, 위치정보를 가진다.
- 한 프로젝트는 하나의 부서에만 속한다.
- 직원은 한 부서에 속한다.
- 직원은 하나 이상의 프로젝트에 참여한다.
- 직원은 사번, 이름, 주소, 성별, 연봉정보를 가진다.
- 각 직원은 프로젝트에 참여한 시간을 관리한다.
- 각 직원은 직속 상관이 없거나 한 명의 직속 상관이 있을 수 있다.
- 경조사 관리를 위해 직원의 가족정보를 유지한다.
- 가족 구성원에 대해 이름, 성별, 생일, 관계만 가진다.
- 개체(Entity): 실제 현실에서 독립적으로 존재하는 것, 직사각형으로 표현
- 속성(Attribute): 개체를 설명하는 특성, 타원으로 표현
- 키속성: 개체마다 고유한 값을 가지는 속성, 밑줄로 표현, 1개 이상 존재가능
개체와 개체 사이의 관계를 나타내며 관계에서도 속성값을 가질 수 있다. 반드시 필요한 관계는 겹줄로 표현한다. 관계는 1:1, 1:N, M:N 3가지 종류가 있다.
- 약개체: 키가 없는 개체를 의미
- 식별관계: 약개체와 부모 개체와의 관계를 의미
부양가족의 경우 직원을 부모개체로 가지지만 키를 가지지 않는다. 자신만의 구분되는 key가 존재하지 않으며 직원이라는 테이블에 의존한다. 직원이라는 테이블에 의존하여 구분된다. 부양가족은 약개체이며, 사원과 부양가족의 관계를 식별관계라고 한다. (약개체는 두겹의 사각형으로 표현)
ERD를 통해서 구체화하여 좀 더 테이블에 가까운 형태로 만든다.
- 개체는 테이블이 된다: 기본적으로 ERD의 개체는 관계데이터모델에서 테이블(릴레이션)이 된다.
관계를 표현하기 위해 **외래키(Foreign Key)**를 사용한다. 테이블이 다른 테이블의 키 속성을 가진다. 외래키는 관계를 표현하기 위해 사용된다. 외래키의 값은 반드시 부모키에 원래 있던 값 중 하나이어야 한다. 1:1 관계에서는 두 줄인(필수적으로 가지는 관계) 테이블에 넣는다.
외래키의 값을 제한하는 제약조건이다.
- 외래키는 참조하는 테이블의 기본키를 가져온다.
- 반드시 (NULL 또는
- 부모테이블에 존재하는 값)이어야 한다.
관계를 맺는 테이블중 한 쪽에 들어간다. 보통 N인 관계의 쪽에 들어간다.
제3의 테이블을 만들어서 관리한다. 새로운 테이블의 기본키는 두 테이블의 외래키를 합친 것을 사용하며, 이것을 복합키 라고 한다.
위의 예시에서는 eid, pid를 합친 것을 복합키로 사용한다.
태생적인 문제를 가지기 때문에 부모의 키와 속성을 합쳐서 기본키로 사용한다.
관계데이터모델로 만들어진 것을 SQL을 사용하여 테이블 형태로 만들면 된다.
- 생활코딩 DB
- 생활코딩에 수업자료로 제공된 이미지를 일부 사용하였습니다 :)