(DB실무) Part2-데이터 모델링의 이해
2026년 11월 8일 공유
데이터 모델링의 이해
개요
데이터 모델링은 복잡한 현실 세계를 추상화·단순화·명확화하여 일정한 표기법으로 표현하는 과정이다. 모델링 결과는 데이터베이스의 구조를 설계하는 데 쓰이며, SQL을 올바르게 작성하고 데이터베이스가 의도대로 동작하는 데 필요한 기반이 된다.
강의는 데이터 모델링의 세 단계와 데이터 독립성을 살펴본 뒤, 데이터 모델의 구성 요소인 엔터티·관계·속성·식별자와 ERD 작성 원칙을 설명한다. 학교에서 주로 다루는 이론적 관점과 실무에서 사용하는 관점은 일부 용어와 단계 구분이 다르므로, 문제나 업무 맥락에 맞춰 해석해야 한다.
핵심 개념
- 모델링의 핵심: 추상화, 단순화, 명확화
- 데이터 관점: 어떤 데이터가 필요한지에 초점을 둔다.
- 프로세스 관점: 업무가 어떤 절차와 순서로 수행되는지에 초점을 둔다.
- 모델의 구성 요소: 엔터티, 관계, 속성, 식별자
- 데이터 독립성: 데이터 구조가 바뀌어도 응용 프로그램의 변경을 최소화하는 성질
- 식별자 관계: 부모의 주 식별자가 자식의 주 식별자에 포함되는 관계
- 비식별자 관계: 부모의 주 식별자가 자식의 일반 속성으로 포함되는 관계
상세 노트
1. 데이터 모델링의 단계
일반적인 세 단계는 다음과 같다.
- 개념적 모델링: 업무의 핵심 개념과 관계를 높은 추상화 수준에서 표현한다.
- 논리적 모델링: 엔터티·속성·관계·식별자 등을 구체화하고 논리 구조를 정리한다.
- 물리적 모델링: 특정 DBMS에 맞게 테이블, 데이터 타입, 인덱스, 뷰 등을 설계해 실제 데이터베이스를 구현한다.
다만 학계와 산업계에서 단계의 구분은 다를 수 있다.
- 학계 관점: ER 다이어그램 작성은 대체로 개념적 모델링, 테이블 스키마 도출은 논리적 모델링으로 구분한다.
- 실무 관점: 개념적·논리적 모델링 모두 ERD를 사용하기도 한다. 핵심 중심의 포괄적 ERD를 개념적 모델, 속성과 식별자를 구체화한 ERD를 논리적 모델로 구분할 수 있다.
- 테이블 도출과 키 지정의 단계도 관점에 따라 다르게 분류될 수 있다. 데이터 타입과 인덱스 등 DBMS에 종속되는 설계는 물리적 모델링에 해당한다.
2. 데이터 독립성과 스키마
파일 시스템에서는 응용 프로그램마다 데이터를 따로 관리해 중복과 불일치가 발생하기 쉽다. 데이터베이스 시스템은 데이터를 통합적으로 관리하고 필요한 응용 프로그램이 활용하도록 하여 이러한 문제를 줄인다.
데이터베이스 구조는 세 가지 스키마로 설명한다.
- 외부 스키마: 사용자나 응용 프로그램이 바라보는 데이터 관점
- 개념 스키마: 모든 사용자 관점을 통합한 데이터베이스의 논리적 구조와 관계
- 내부 스키마: 데이터가 저장 장치에 물리적으로 저장되는 방식
세 스키마를 두는 목적은 응용 프로그램과 데이터 간의 종속성을 낮추는 것이다.
- 논리적 데이터 독립성: 개념 스키마가 바뀌어도 외부 스키마나 응용 프로그램에 미치는 영향을 줄인다.
- 물리적 데이터 독립성: 내부 저장 구조가 바뀌어도 개념 스키마와 응용 프로그램에 미치는 영향을 줄인다.
따라서 데이터 모델링은 사용자가 필요로 하는 데이터를 통합해 개념 스키마를 설계하는 과정과 밀접하게 관련된다.
3. 데이터 모델의 구성 요소
- 엔터티(Entity): 업무에서 관리할 대상이나 사건의 집합
- 속성(Attribute): 엔터티가 가진 특성이나 정보
- 관계(Relationship): 엔터티 간의 연관성
- 식별자(Identifier): 엔터티의 인스턴스를 유일하게 구분하는 속성 또는 속성 조합
예를 들어 수강신청 시스템에는 학생과 과목 엔터티가 있고, 학생의 학번·이름과 과목의 과목명·학점은 속성이며, 학생이 과목을 수강하는 것은 관계다.
4. 스키마와 인스턴스
- 스키마: 데이터베이스의 구조를 정의한다. 테이블·속성·제약 조건·키 관계 등이 이에 해당하며 비교적 자주 바뀌지 않는다.
- 인스턴스: 특정 시점에 데이터베이스에 실제 저장된 값이다. 데이터 입력·수정·삭제에 따라 계속 변한다.
엔터티는 일반적으로 스키마 수준의 개념이며, 엔터티에 속한 개별 데이터가 인스턴스다. 속성에 실제로 들어가는 값은 속성값이다.
5. ERD 표기법과 작성 원칙
대표적인 표기법에는 피터 첸 표기법과 정보공학(IE)의 크로우즈풋 표기법 등이 있다.
- 피터 첸 표기법은 관계를 다이아몬드로 나타내며, 관계 자체가 속성을 가질 수 있다.
- 크로우즈풋 표기법은 관계를 선으로 나타내므로 관계 자체에 속성을 직접 붙이지 않는다. 실무에서는 이 표기법이 널리 사용된다.
- 관계에 속성이 필요한 경우 실무 모델에서는 이를 별도의 엔터티로 표현하는 방식이 사용될 수 있다.
- 학교에서 배운 표기법과 실무 표기법은 표현 방식과 용어가 다를 수 있으므로 서로 대응해 이해하는 것이 중요하다.
ERD를 작성할 때는 엔터티를 읽기 좋게 배치하고, 관계선이 불필요하게 꼬이지 않도록 한다. 관계명은 가능한 한 구체적인 동사를 현재형으로 사용한다. 다만 데이터베이스 설계에서 관계의 이름보다 엔터티·속성·연결 구조가 더 직접적인 의미를 갖는다.
6. 엔터티와 관계의 특성
엔터티 유형
- 유형 엔터티: 사람·사물처럼 물리적 형태가 있는 대상. 예: 학생, 강사, 기자재
- 개념 엔터티: 물리적 형태는 없지만 관리해야 하는 개념. 예: 과목, 전공
- 사건 엔터티: 업무 과정에서 발생하며 인스턴스가 많이 쌓이는 사건. 예: 수강신청, 주문
엔터티 후보를 정할 때는 실제 업무에 필요한지, 인스턴스가 둘 이상 생길 수 있는지 확인한다. 특정 시스템에서 단 하나의 값만 존재하고 별도로 관리할 필요도 없다면 독립된 엔터티로 만들 필요가 낮을 수 있다.
엔터티의 주요 조건
- 해당 업무에서 필요한 정보를 담는다.
- 인스턴스를 유일하게 식별할 수 있어야 한다.
- 여러 인스턴스의 집합으로 관리된다.
- 업무 프로세스에서 실제로 사용된다.
- 필요한 속성을 갖고, 업무와 무관한 엔터티나 속성은 제외한다.
CRUD 매트릭스로 업무 프로세스가 각 엔터티를 생성(Create), 조회(Read), 수정(Update), 삭제(Delete)하는지 확인할 수 있다. 어떤 엔터티가 어떠한 업무에서도 사용되지 않는다면 불필요하게 만들었거나 관련 업무를 누락했을 가능성이 있다.
관계의 차수와 선택성
- 차수: 한 인스턴스가 상대 엔터티의 몇 개 인스턴스와 연결될 수 있는지 나타낸다. 대표적으로 1:1, 1:N, M:N 관계가 있다.
- 선택성: 관계에 참여하지 않는 인스턴스가 허용되는지 나타낸다.
- 선택적 참여: 관계에 참여하지 않아도 된다.
- 필수적 참여: 반드시 관계에 참여해야 한다.
학교와 실무에서 ‘차수’와 ‘대응 수’ 등의 용어를 다르게 사용할 수 있으므로, 질문의 표기법과 맥락을 확인한다. 양쪽 모두 선택적인 관계라면 관계 자체가 필요한지 다시 검토할 수 있다.
7. 속성과 도메인
속성은 엔터티의 인스턴스를 구체적으로 설명하는 최소 단위의 정보다. 일반적으로 각 속성은 하나의 값만 갖도록 설계하며, 여러 값을 갖는 속성은 별도 엔터티로 분리할 수 있다. 주소나 이름처럼 나눌 수 있는 값은 업무 목적에 따라 단순 속성으로 분해해 저장하기도 한다.
- 도메인: 속성이 가질 수 있는 값의 범위와 제약 조건. 데이터 타입, 길이, 허용값 등이 포함된다.
- 속성은 업무에 필요한 정보만 포함해야 하며, 주 식별자에 함수적으로 종속되어야 한다.
- 속성명은 현업 용어를 사용하고, 약어와 지나치게 서술적인 이름은 피하는 편이 바람직하다.
- 같은 엔터티 안에서는 속성명이 중복되면 안 된다. 전체 모델에서도 속성명을 가능한 한 고유하게 정한다.
속성의 특성에 따른 분류는 다음과 같다.
- 기본 속성: 업무에서 원래 관리하던 정보. 예: 이름, 주소
- 설계 속성: 식별·관리 등을 위해 데이터 모델링 과정에서 새로 만든 정보. 예: 일련번호, 관리 코드
- 파생 속성: 다른 속성에서 계산하거나 집계해 얻는 정보. 예: 평균, 총인원
파생 속성은 조회에 편리하지만, 원천 데이터가 바뀔 때 값이 불일치할 수 있고 갱신 비용도 생긴다. 필요한 경우에만 사용한다.
8. 식별자와 키
- 주 식별자: 엔터티의 각 인스턴스를 유일하게 구분하도록 선택한 대표 식별자
- 보조 식별자: 식별자로 사용할 수 있지만 주 식별자로 선택되지 않은 후보
- 내부 식별자: 해당 엔터티 안에서 만들어진 식별자
- 외부 식별자: 다른 엔터티의 식별자를 관계를 통해 가져온 것. 일반적으로 외래 키와 관련된다.
- 단일 식별자: 하나의 속성으로 구성된 식별자
- 복합 식별자: 둘 이상의 속성을 조합한 식별자
- 본질 식별자: 업무에 원래 존재하던 속성으로 구성된 식별자
- 인조 식별자: 모델링 과정에서 새로 만든 식별자
주 식별자는 다음 조건을 갖춰야 한다.
- 유일성: 모든 인스턴스를 서로 구별한다.
- 최소성: 유일성을 만족하는 데 필요한 최소한의 속성으로 구성한다.
- 불변성: 식별자 값이 변경되지 않도록 한다.
- 존재성: 값이 반드시 있어야 하며, 비어 있지 않아야 한다.
복합 식별자에 속성이 지나치게 많으면 관계와 쿼리가 복잡해질 수 있다. 이때 인조 식별자를 사용할 수 있다. 주 식별자는 업무에서 자주 사용되는 안정적인 값인지, 이름처럼 중복될 수 있는 값은 아닌지 고려해 선택한다.
9. 식별자 관계와 비식별자 관계
부모 엔터티의 주 식별자가 자식 엔터티로 전달될 때, 자식에서 그 속성이 주 식별자의 일부가 되는지에 따라 구분한다.
- 식별자 관계: 부모의 주 식별자가 자식의 주 식별자에 포함된다. 일반적으로 실선으로 표현한다. 자식이 부모의 식별자에 의존하므로 부모 인스턴스가 있어야 자식 인스턴스를 식별할 수 있다.
- 비식별자 관계: 부모의 주 식별자가 자식의 일반 속성으로 포함된다. 일반적으로 점선으로 표현한다. 자식이 부모의 식별자 없이도 독립적으로 식별될 수 있다.
어느 관계가 항상 더 낫다고 할 수는 없다.
- 식별자 관계를 과도하게 사용하면 주 식별자가 여러 속성으로 길어지고, 식별자 속성의 중복과 쿼리 복잡도가 증가할 수 있다.
- 비식별자 관계를 과도하게 사용하면 필요한 정보를 얻기 위해 여러 테이블을 조인해야 할 수 있다.
- 부모와 자식의 종속성, 자식의 독립적인 식별자 필요성, 식별자 속성의 복잡도 등을 고려해 선택한다.
10. 좋은 데이터 모델의 기준
좋은 모델은 업무에 필요한 정보를 빠짐없이 표현하면서도 불필요한 중복을 줄여야 한다.
- 완전성: 업무에 필요한 데이터가 모두 포함되어야 한다.
- 중복 최소화: 동일한 사실은 한곳에서 관리하고 필요한 곳에서 참조한다. 다만 관계 표현에 필요한 외래 키는 구조상 여러 테이블에 나타날 수 있다.
- 업무 규칙 반영: 규칙을 처리하는 데 필요한 데이터가 모델에 포함되어야 한다.
- 공통 데이터 활용: 부서나 응용 프로그램별로 같은 데이터를 별도로 관리하지 않도록 한다.