(DB실무) Part0-Precourse-Conceptual Data Modeling
2026년 11월 8일 공유
데이터 모델링 입문: 개념적 설계와 ER 모델
개요
- 콘텐츠 유형: 강의
- 데이터베이스의 기본 개념을 살펴보고, 데이터베이스 설계 과정 중 개념적 설계에 해당하는 ER 모델링의 핵심 요소와 작성 방법을 학습한다.
- 데이터베이스 모델링은 요구사항을 분석하고, 관리할 데이터와 데이터 간 관계를 구조화하는 과정이다. 이 강의에서는 특히 개체, 관계, 속성, 키, 대응 수를 다룬다.
핵심 개념
- 데이터베이스(DB): 데이터뿐 아니라 데이터 사이의 관계도 저장하는 체계.
- DBMS: 사용자의 질의를 처리하고 데이터베이스에 대한 접근을 관리하는 소프트웨어.
- 스키마와 인스턴스: 스키마는 데이터베이스의 구조와 제약 조건이고, 인스턴스는 특정 시점에 저장된 실제 데이터다.
- 개념적 설계: 요구사항을 이해하기 쉬운 구조로 표현하는 단계. 대표적인 방법은 개체-관계(ER) 모델이며, 결과물은 **ER 다이어그램(ERD)**이다.
- 키 속성: 개체를 유일하게 식별하는 속성 또는 속성의 조합. 키는 유일성과 최소성을 만족해야 한다.
- 대응 수: 한 개체가 관계를 통해 다른 개체와 맺을 수 있는 최대 연결 수를 나타내며, 주로 일대일, 일대다, 다대다로 표현한다.
상세 노트
1. 데이터베이스와 데이터베이스 시스템
데이터베이스는 데이터가 많고 여러 사용자가 동시에 접근하는 상황에서 데이터를 체계적으로 저장하고 효율적으로 관리하기 위해 사용한다. 은행 거래, 호텔 예약, 온라인 쇼핑처럼 기록해야 할 데이터가 많고 동시 이용자가 많은 서비스가 대표적이다. 반면 단순한 신호등 제어나 디지털 도어락처럼 데이터 규모와 동시 접근이 제한적인 경우에는 데이터베이스가 필요하지 않을 수 있다.
데이터베이스 시스템의 주요 요소는 다음과 같다.
- 데이터베이스: 실제 데이터가 저장되는 곳
- 메타데이터: 테이블 구성 등 데이터베이스의 구조를 설명하는 정보
- 질의(Query): 데이터를 조회하거나 변경하기 위해 사용하는 요청
- DBMS: 질의를 해석하고 데이터베이스 작업을 수행하는 소프트웨어
데이터베이스는 학생·과목 같은 개별 데이터뿐 아니라, 학생이 과목을 수강하는 관계와 같은 데이터 간 연결도 관리한다. 질의에 답하기 위해 여러 테이블의 정보를 연결하는 작업을 **조인(Join)**이라고 한다.
2. 스키마와 인스턴스
- 스키마: 데이터베이스의 구조, 데이터 형식, 제약 조건을 정의한 설계도다. 어떤 테이블과 속성이 있는지, 값이 비어도 되는지, 중복이 허용되는지 등을 명세한다. 비교적 자주 바뀌지 않는다.
- 인스턴스: 특정 시점에 데이터베이스에 실제로 저장된 값이다. 데이터의 삽입·삭제·수정에 따라 계속 변한다.
데이터베이스 설계 또는 데이터 모델링은 이 스키마를 만드는 작업으로 볼 수 있다. 강의에서는 데이터베이스 설계와 데이터 모델링을 같은 의미로 사용한다.
3. SQL의 역할과 분류
SQL은 데이터베이스를 질의하고 조작하는 언어다. 사용자가 화면에서 클릭하는 작업도 내부적으로는 SQL 명령으로 처리될 수 있다.
- DDL: 테이블 등 데이터베이스 구조를 정의하거나 변경한다.
- DML: 데이터를 조회·삽입·수정·삭제한다.
- DCL·TCL: 사용자 권한이나 트랜잭션 등을 관리한다.
일반 사용자는 주로 DML을 사용하며, 데이터베이스 설계자는 구조를 정의할 때 DDL도 사용한다.
4. 데이터베이스 설계 과정
설계 과정은 다음 네 단계로 구분한다.
- 요구사항 분석: 관리할 현실 세계의 범위, 즉 미니월드를 정하고 업무 기술서를 작성한다.
- 개념적 설계: 요구사항을 ER 모델로 표현하고 ERD를 작성한다.
- 논리적 설계: 개념 모델을 테이블 형태의 관계형 모델로 변환한다.
- 물리적 설계: 인덱스와 성능 등 실제 저장·구현에 필요한 사항을 고려한다.
이 강의의 중심은 개념적 설계와 ER 모델링이다. 설계에는 여러 타당한 표현 방식이 있을 수 있으므로, 언제나 하나의 정답만 존재한다고 보기는 어렵다.
5. ER 모델의 구성 요소
개체(Entity)
데이터베이스에서 관리할 가치가 있는 대상이다. 학생·자동차·강의실처럼 물리적인 대상뿐 아니라 프로젝트·직업 같은 개념적 대상도 포함한다.
개체 후보를 찾을 때는 먼저 업무에서 중요한 대상을 살펴본다. 다만 데이터베이스 범위에 해당 항목이 한 건만 존재한다면, 별도의 개체로 만들 필요가 없을 수도 있다. 예를 들어 특정 회사 하나만 관리하는 데이터베이스라면 ‘회사’를 개체로 둘 실익이 없을 수 있다.
관계(Relationship)
개체 사이의 연관성을 나타낸다. 예를 들어 학생은 과목을 수강하고, 직원은 부서에 소속된다.
개체와 관계를 구분하기 어려운 경우도 있다. 업무 맥락과 설계 목적에 따라 판단해야 하며, 모든 상황에서 기계적으로 적용되는 규칙이 있는 것은 아니다.
속성(Attribute)
개체 또는 관계가 갖는 성질이다. 학생의 이름·학번, 수강 관계의 학점 등이 예다. 속성의 값들이 특정 시점의 인스턴스를 구성한다.
학점처럼 학생이나 과목 하나만으로 결정할 수 없는 정보는 관계의 속성이 될 수 있다. 예를 들어 학생별·과목별 성적은 학생 개체만의 성질도, 과목 개체만의 성질도 아니라 수강 관계에서 발생한다.
6. 속성의 유형
속성은 여러 기준으로 분류할 수 있다.
- 단일값 속성 / 다중값 속성: 한 개체가 하나의 값만 갖는지, 여러 값을 가질 수 있는지에 따라 구분한다. 나이는 보통 단일값이고 취미는 다중값의 예다.
- 단순 속성 / 복합 속성: 더 작은 의미 있는 항목으로 나눌 필요가 있는지에 따라 구분한다. 주소를 우편번호와 상세 주소로 나누어 쓰는 경우 복합 속성으로 볼 수 있다.
- 저장 속성 / 유도 속성: 다른 저장 데이터로부터 계산할 수 있는지에 따라 구분한다. 시험 점수로 계산할 수 있는 평균이 유도 속성의 예다.
유도 가능한 값도 실제 조회 빈도나 성능 요구에 따라 저장할 수 있다. 따라서 이를 저장할지 계산할지는 설계 목적에 따라 판단한다.
7. 키와 약성 개체
키 속성
키는 개체를 유일하게 식별하는 속성 또는 속성들의 집합이다.
- 혈액형처럼 여러 개체가 같은 값을 가질 수 있는 속성은 키가 될 수 없다.
- 이름도 동명이인이 가능하므로 일반적으로 키로 적합하지 않다.
- 하나의 속성만으로 식별하기 어려우면 여러 속성을 조합한 복합 키를 사용할 수 있다. 예를 들어 선수 데이터에서 팀명과 등번호의 조합이 선수를 식별할 수 있다.
- 복합 키는 불필요한 속성을 포함하지 않아야 한다. 즉 유일성뿐 아니라 최소성도 만족해야 한다.
개체가 둘 이상의 식별자를 가질 수 있으며, 식별자를 갖지 못하는 개체도 있다. 개념적 모델의 식별자와 논리적 모델의 기본 키는 구분이 필요하다. 논리 모델의 각 테이블에는 기본 키가 하나 필요하다.
약성 개체(Weak Entity)
자체 속성만으로 식별할 수 없는 개체다. 다른 개체의 식별자에 의존해 식별된다. 예를 들어 부양가족의 이름만으로는 여러 직원의 부양가족 중 한 명을 유일하게 가리키지 못할 수 있다. 이 경우 직원의 식별자와 부양가족의 부분 키를 결합해 식별한다.
설계 시에는 가능하다면 개체에 고유 ID를 부여해 약성 개체를 피하는 방법도 고려할 수 있다.
8. 관계의 차수와 대응 수
- 차수: 하나의 관계에 참여하는 개체 유형의 수다. 두 개체 사이의 관계는 이항 관계, 세 개체가 참여하는 관계는 삼항 관계다. 대부분의 ERD에서는 이항 관계가 흔하다.
- 대응 수(Cardinality): 한 개체가 관계를 통해 다른 개체와 맺을 수 있는 최대 연결 수다.
- 일대일: 한쪽의 한 개체가 다른 쪽의 최대 한 개체와 연결된다.
- 일대다: 한쪽의 한 개체가 다른 쪽의 여러 개체와 연결될 수 있다.
- 다대다: 양쪽 모두 여러 개체와 연결될 수 있다.
학생과 학과의 관계에서 학생은 하나의 학과에 소속되고, 학과에는 여러 학생이 소속될 수 있으므로 일대다 관계로 표현할 수 있다. 학생과 과목의 수강 관계는 양쪽 모두 여러 개체가 연결되므로 다대다 관계의 예다.
9. 관계의 속성과 다항 관계
근무 시작일처럼 관계가 형성되면서 생기는 정보는 개념적으로 관계의 속성이다. 실무 설계에서는 이 값을 어느 개체 쪽에 둘지 고려해야 한다.
- 일대다 관계에서 속성을 한쪽 개체로 옮겨야 한다면, 관계의 반대편에서 그 값이 여러 개에 걸쳐 모호해지지 않는지 확인한다.
- 다대다 관계의 속성은 어느 한쪽 개체만으로 결정되지 않을 수 있다. 예를 들어 직원이 각 프로젝트에 투입하는 주당 근무 시간은 직원과 프로젝트의 조합에 따라 달라진다.
세 개체가 동시에 참여하는 삼항 관계도 가능하다. 공급업체·프로젝트·부품 관계에서 공급 수량은 이 세 요소의 조합으로 결정될 수 있다. 삼항 관계는 해석과 대응 수 설정이 복잡하므로, 필요에 따라 별도의 개체와 이항 관계들로 변환하는 방식도 고려할 수 있다.
10. 일반화(특수화) 관계
여러 개체가 공통 속성을 갖지만 각자 고유한 속성도 있을 때 사용한다. 예를 들어 대학원생·학부생·고등학생은 이름과 생년월일 같은 공통 속성을 공유하지만, 연구 분야나 학년처럼 유형별 속성은 다를 수 있다.
- 공통 속성은 상위의 일반 개체에 둔다.
- 특정 유형에만 해당하는 속성은 하위 개체에 둔다.
- 하위 개체는 상위 개체의 한 유형으로 표현한다. 예: “대학원생은 학생이다.”
11. ERD 작성 권장 순서
- 업무 기술서에서 주요 개체 후보를 찾는다.
- 주요 개체 사이의 관계를 설정해 전체 구조를 잡는다.
- 각 관계의 대응 수를 결정한다.
- 개체와 관계의 속성을 도출한다.
- 키와 약성 개체 여부를 확인한다.
- 나머지 속성을 배치하고, 중복·유도 속성 등을 점검한다.
개체를 먼저 찾고 관계와 속성을 차례로 정리하는 것이 권장되는 접근이다. 특히 개체와 관계의 골격을 제대로 잡는 것이 ERD 완성의 핵심이다.
핵심 요약: 개념적 설계는 업무 요구사항을 개체·관계·속성으로 표현하는 작업이다. 먼저 관리 대상과 그 관계를 명확히 한 뒤, 대응 수와 식별자를 정하고 속성을 배치한다.