이 문서의 과거 버전 (r1)을 보고 있습니다. 수정일: 2026.02.14 23:09
ERD(Entity-Relationship Diagram)는 데이터베이스 설계의 핵심 도구로, 시스템 내의 데이터 구조를 시각적으로 표현하는 다이어그램이다. 이는 개체-관계 모델을 기반으로 하여, 저장해야 할 정보의 구성 요소와 그들 간의 논리적 관계를 명확하게 보여준다.
ERD는 주로 데이터베이스의 개념적 설계 단계에서 사용되며, 이해관계자들 간의 의사소통을 원활하게 하고 시스템 요구사항을 명확히 하는 데 목적이 있다. 데이터베이스 설계자는 ERD를 통해 엔터티, 속성, 관계라는 기본 구성 요소를 도출하고 구조화한다.
이 다이어그램은 이후 관계형 데이터베이스나 다른 유형의 데이터베이스를 구축하기 위한 청사진 역할을 한다. 잘 작성된 ERD는 데이터의 중복을 방지하고 무결성을 유지하며, 효율적인 데이터 관리와 검색을 가능하게 하는 기반을 마련한다.
ERD는 엔터티, 속성, 관계라는 세 가지 기본 구성 요소로 이루어진다. 이 요소들은 현실 세계의 데이터 구조와 그들 간의 상호작용을 추상화하여 표현한다.
엔터티는 데이터베이스에 저장될 정보의 주체가 되는 독립적인 객체나 개념을 나타낸다. 엔터티는 일반적으로 명사로 표현되며, '고객', '주문', '제품'과 같은 실체가 될 수도 있고, '수업', '계좌'와 같은 개념이 될 수도 있다. 각 엔터티는 유일하게 식별 가능한 인스턴스들의 집합으로 구성된다. 예를 들어, '학생' 엔터티는 개별 학생들을, '책' 엔터티는 각각의 도서를 의미한다. ERD에서 엔터티는 사각형으로 표시된다.
엔터티의 세부적인 특징은 속성으로 정의된다. 속성은 엔터티가 가지는 특성이나 상태를 설명한다. '학생' 엔터티의 속성으로는 학번, 이름, 전공, 학년 등이 있을 수 있다. 속성 중에서 기본키는 엔터티의 각 인스턴스를 유일하게 식별하는 역할을 하는 특별한 속성이다. 속성은 ERD에서 엔터티 사각형 내부에 나열되거나, 타원형으로 별도로 표현되기도 한다.
마지막 구성 요소인 관계는 두 개 이상의 엔터티 간에 존재하는 논리적 연결을 의미한다. 관계는 엔터티들이 서로 어떻게 연관되어 있는지를 보여준다. 예를 들어, '학생' 엔터티와 '수강' 엔터티는 '수강한다'는 관계로 연결될 수 있다. 관계는 일반적으로 동사로 표현되며, 카디널리티 (1:1, 1:N, M:N)와 옵셔널리티 (필수/선택)를 통해 그 성질을 구체화한다. ERD에서 관계는 엔터티들을 연결하는 선이나 마름모 기호로 표시된다.
엔터티는 ERD에서 관리해야 할 실체 또는 객체를 나타낸다. 데이터베이스에서 저장할 대상이 되는 사람, 장소, 사물, 개념, 사건 등을 의미한다. 엔터티는 독립적으로 존재할 수 있으며, 다른 엔터티와 구별되는 고유한 특성을 지닌다. 예를 들어, '학생', '강좌', '주문', '제품' 등이 엔터티가 될 수 있다.
엔터티는 인스턴스의 집합으로 정의된다. 인스턴스는 엔터티의 한 개체를 가리킨다. '학생'이라는 엔터티는 '홍길동', '김철수'와 같은 구체적인 학생 개인들의 집합이다. 각 엔터티는 하나 이상의 속성을 가지며, 이러한 속성들로 각 인스턴스를 식별하고 설명한다.
엔터티는 일반적으로 다음과 같은 특징을 가진다.
유일성: 각 엔터티 인스턴스는 서로 구분될 수 있어야 한다.
관련 속성: 엔터티는 반드시 속성을 가진다.
관계: 다른 엔터티와 하나 이상의 관계를 맺을 수 있다.
엔터티는 ERD에서 사각형으로 표현되며, 사각형 안에 엔터티의 이름을 표기한다. 엔터티의 종류는 약한 엔터티와 강한 엔터티로 구분하기도 한다. 강한 엔터티는 다른 엔터티의 도움 없이 독자적으로 존재할 수 있는 반면, 약한 엔터티는 다른 엔터티(강한 엔터티)의 존재에 의존적으로 존재한다[1].
속성은 엔터티가 가지는 구체적인 특성이나 상태를 나타내는 정보 단위이다. 각 엔터티는 하나 이상의 속성으로 구성되며, 이러한 속성들은 데이터베이스에서 테이블의 열에 해당한다.
속성은 그 특성에 따라 여러 유형으로 분류된다. 주요 유형은 다음과 같다.
속성 유형 | 설명 | 예시 (고객 엔터티) |
|---|---|---|
엔터티의 각 인스턴스를 고유하게 식별하는 속성 |
| |
다른 엔터티의 기본키를 참조하여 관계를 표현하는 속성 |
| |
단순 속성 | 더 이상 분해할 수 없는 원자적인 속성 |
|
복합 속성 | 여러 하위 속성으로 구성될 수 있는 속성 |
|
하나의 인스턴스에 대해 여러 값을 가질 수 있는 속성 |
| |
다른 속성의 값으로부터 계산되거나 유도될 수 있는 속성 |
| |
값이 존재하지 않을 수 있음을 허용하는 속성 |
|
속성은 도메인을 가진다. 도메인이란 해당 속성이 가질 수 있는 값의 범위나 데이터 타입을 정의한 것이다. 예를 들어, 나이 속성의 도메인은 '0 이상의 정수'가 될 수 있다. 속성의 명명과 도메인 정의는 데이터의 무결성과 일관성을 보장하는 데 중요한 역할을 한다.
관계는 엔터티 간의 논리적 연결을 의미하며, 데이터베이스에서 중요한 의미를 갖는 연관성을 표현한다. 관계는 일반적으로 동사나 동사구로 명명되며, 예를 들어 '소속된다', '주문한다', '수강한다'와 같은 형태를 가진다. 관계는 엔터티들이 서로 어떻게 상호작용하는지를 정의함으로써 비즈니스 규칙을 모델링하는 핵심 요소가 된다.
관계는 세 가지 주요 특성, 즉 관계의 차수, 관계의 선택성, 그리고 관계의 명칭으로 정의된다. 관계의 차수는 한 엔터티의 인스턴스가 다른 엔터티의 몇 개의 인스턴스와 연관될 수 있는지를 나타낸다. 가장 일반적인 차수는 다음과 같다.
차수 | 설명 | 예시 |
|---|---|---|
일대일 (1:1) | 엔터티 A의 한 인스턴스가 엔터티 B의 한 인스턴스와만 관계를 맺는다. | 한 사람은 하나의 주민등록번호를 가진다. |
일대다 (1:N) | 엔터티 A의 한 인스턴스가 엔터티 B의 여러 인스턴스와 관계를 맺을 수 있다. | 한 부서에는 여러 명의 사원이 소속된다. |
다대다 (M:N) | 엔터티 A의 여러 인스턴스가 엔터티 B의 여러 인스턴스와 관계를 맺을 수 있다. | 한 학생은 여러 과목을 수강하고, 한 과목은 여러 학생이 수강한다. |
관계의 선택성은 관계가 필수적인지 아니면 선택적인지를 나타낸다. 이를 통해 특정 엔터티의 인스턴스가 반드시 관계를 가져야 하는지, 아니면 관계를 가지지 않을 수도 있는지를 표현한다. 예를 들어, '모든 사원은 반드시 하나의 부서에 소속된다'는 필수 관계이며, '모든 고객이 반드시 주문을 해야 하는 것은 아니다'는 선택 관계이다. 이러한 관계의 특성들은 ERD를 통해 시각적으로 표현되며, 이후 논리적 설계 단계에서 다대다 관계는 일반적으로 연결 테이블을 도입하여 해소한다.
ERD는 다양한 표기법을 사용하여 그릴 수 있으며, 각 표기법은 엔터티, 속성, 관계를 표현하는 시각적 기호와 규칙이 다르다. 가장 널리 알려진 표기법으로는 피터 첸이 제안한 Chen 표기법과 정보 공학 분야에서 흔히 쓰이는 Crow's Foot 표기법이 있다.
Chen 표기법은 역사적으로 가장 먼저 등장한 표기법 중 하나로, 기본 도형을 사용한다. 엔터티는 직사각형, 속성은 타원, 관계는 마름모로 표현한다. 각 요소는 선으로 연결되며, 관계의 카디널리티(1:1, 1:N, M:N)는 선 위에 숫자나 문자(예: 1, N, M)를 표기하여 나타낸다. 이 표기법은 개념적 모델링에 적합하고 구성 요소를 시각적으로 명확히 구분할 수 있는 장점이 있으나, 복잡한 데이터베이스 설계에는 다소 장황해질 수 있다.
Crow's Foot 표기법 (까마귀발 표기법)은 보다 실용적이고 간결한 표현을 지향하며, 특히 물리적 데이터 모델링에 널리 사용된다. 이 표기법에서는 엔터티를 사각형 박스로, 속성을 박스 내부에 나열하여 표현한다. 관계는 엔터티를 연결하는 선으로 표시하며, 선의 끝에 있는 기호(까마귀발 모양의 발가락, 원, 막대기)로 카디널리티와 참여도(필수/선택)를 함께 나타낸다.
특징 | Chen 표기법 | Crow's Foot 표기법 |
|---|---|---|
엔터티 표현 | 직사각형 | 사각형(박스) |
속성 표현 | 타원 (직사각형과 별도) | 사각형 박스 내부에 텍스트로 나열 |
관계 표현 | 마름모 | 연결선 |
카디널리티 표기 | 선 위에 숫자/문자(1, N) 표기 | 선 끝의 기호(까마귀발, 원 등)로 표현 |
주요 사용처 | 개념적 모델링 | 논리적/물리적 모델링 |
이 외에도 UML 클래스 다이어그램을 변형한 표기법이나 IDEF1X와 같은 표기법도 특정 분야에서 사용된다. 표기법의 선택은 설계의 단계(개념/논리/물리), 팀의 관습, 사용하는 CASE 도구의 지원 여부에 따라 결정된다.
Chen 표기법은 1976년 피터 첸이 자신의 논문에서 제안한 엔터티-관계 모델을 시각적으로 표현하는 최초의 표준화된 표기법이다. 이 표기법은 엔터티, 속성, 관계라는 세 가지 기본 구성 요소를 각각 독특한 기하학적 도형으로 표현한다.
구성 요소들은 실선으로 연결되며, 관계의 카디널리티(1:1, 1:N, M:N)는 선 위에 숫자나 문자(예: '1', 'N', 'M')를 표기하여 나타낸다. 속성 중 기본키는 밑줄을 그어 구별한다. 이 표기법은 개념적 모델링 단계에서 데이터의 구조와 의미를 추상적이고 직관적으로 표현하는 데 중점을 두었다.
Chen 표기법은 이후 등장한 Crow's Foot 표기법 등에 비해 다소 복잡하고 공간을 많이 차지한다는 단점이 있지만, ERD의 이론적 기초를 마련했다는 점에서 역사적 의의가 크다. 이 표기법은 학계와 이론 서적에서 개념적 모델을 설명하는 데 여전히 널리 사용된다.
Crow's Foot 표기법은 ERD에서 엔터티 간의 관계를 시각적으로 표현하는 데 널리 사용되는 방법 중 하나이다. 이 표기법은 관계의 카디널리티(기수성)와 옵셔널리티(선택성)를 직관적인 기호로 나타내는 것이 특징이다. 표기법의 이름은 관계선 끝에 그려지는 '까마귀 발' 모양의 기호에서 유래했다.
이 표기법에서는 관계의 세 가지 기본 카디널리티를 다음과 같은 기호로 표현한다.
일대일(1:1): 관계선 양끝에 수직선(|)을 그린다.
일대다(1:N) 또는 다대일(N:1): '다'를 나타내는 쪽에 까마귀 발 모양(三)을, '일'을 나타내는 쪽에 수직선(|)을 그린다.
다대다(N:M): 관계선 양끝에 까마귀 발 모양(三)을 그린다.
또한, 옵셔널리티(해당 관계가 필수인지 선택적인지)는 다음과 같이 표현한다.
필수 관계(반드시 존재해야 함): 관계선 끝에 수직선(|)을 그린다.
선택 관계(존재할 수도 있고 안 할 수도 있음): 관계선 끝에 원(O)을 그린다.
이 두 요소를 조합하여 '하나의 A는 0개 또는 1개의 B와 연결된다'와 같은 복합적인 관계를 정확히 표현할 수 있다. 예를 들어, '한 명의 사원은 반드시 하나의 부서에 속해야 하며, 하나의 부서에는 0명 이상의 사원이 속할 수 있다'는 관계는 사원 쪽에 원과 수직선이 결합된 기호, 부서 쪽에 까마귀 발 기호를 사용하여 나타낸다.
Crow's Foot 표기법은 기호가 직관적이어서 비기술자도 이해하기 비교적 쉽다는 장점이 있다. 이로 인해 데이터베이스 설계 단계에서 이해관계자 간의 의사소통 도구로 자주 활용된다. 많은 현대 ERD 작성 도구들이 이 표기법을 기본 또는 옵션으로 지원한다.
ERD 설계는 일반적으로 요구사항 분석, 개념적 설계, 논리적 설계, 물리적 설계의 네 단계를 거쳐 체계적으로 진행된다. 각 단계는 추상적인 개념에서 구체적인 데이터베이스 스키마로 점진적으로 발전하는 과정을 나타낸다.
첫 단계인 요구사항 분석에서는 시스템이 관리해야 할 데이터의 종류, 업무 규칙, 사용자 요구사항을 명확히 파악한다. 이 단계의 결과물은 자연어로 작성된 요구사항 명세서나 유스케이스 다이어그램 등이 될 수 있다. 다음으로 개념적 설계 단계에서는 파악된 요구사항을 바탕으로 핵심 엔터티와 그들 간의 관계를 도출하여 개념적 ERD를 작성한다. 이 모델은 특정 DBMS나 구현 세부사항과 무관하게 업무의 본질적인 데이터 구조를 표현한다.
설계 단계 | 주요 목표 | 결과물 | 특징 |
|---|---|---|---|
요구사항 분석 | 데이터 요구사항 파악 | 요구사항 명세서 | 기술 중립적 |
개념적 설계 | 핵심 구조 모델링 | 개념적 ERD | 업무 중심, 추상적 |
논리적 설계 | 상세 구조 정의 | 논리적 ERD | 정규화 적용, DBMS 독립적 |
물리적 설계 | 실제 구현 설계 | 물리적 ERD | DBMS 종속적, 성능 고려 |
논리적 설계 단계에서는 개념적 모델을 구체화하여 논리적 ERD를 완성한다. 모든 속성을 정의하고, 엔터티를 관계형 데이터베이스의 테이블에 매핑하며, 정규화를 통해 데이터의 중복을 제거하고 무결성을 확보한다. 마지막 물리적 설계 단계에서는 선택된 특정 DBMS(예: Oracle, MySQL)의 물리적 저장 구조를 고려한다. 테이블과 컬럼의 물리적 이름, 데이터 타입, 인덱스, 파티셔닝 전략 등을 결정하여 최종 물리적 ERD와 DDL 스크립트를 생성한다. 이 단계에서는 조회 성능 최적화를 위해 선택적 비정규화가 수행되기도 한다[2].
요구사항 분석은 ERD 설계의 첫 번째이자 가장 중요한 단계이다. 이 단계의 목표는 데이터베이스가 지원해야 할 비즈니스 영역의 정보 요구사항을 완전하고 정확하게 이해하고 문서화하는 것이다. 시스템의 사용자, 이해관계자, 그리고 관련 문서들을 통해 데이터가 무엇인지, 어떻게 사용되는지, 어떤 규칙을 따라야 하는지를 파악한다.
분석 과정에서는 인터뷰, 설문조사, 워크샵, 기존 문서(양식, 보고서, 화면) 검토 등의 방법이 활용된다. 핵심은 비즈니스에서 다루는 주요 '사물'(엔터티)과 그들 간의 중요한 '연관성'(관계)을 발견하는 것이다. 예를 들어, '주문' 시스템을 분석한다면 '고객', '상품', '주문'이라는 엔터티와 '고객이 주문한다', '주문에는 상품이 포함된다'와 같은 관계를 식별하게 된다. 각 엔터티가 가지는 특징(속성)들, 예를 들어 '고객'의 이름과 연락처, '주문'의 날짜와 상태 등도 함께 정의한다.
이 단계의 최종 산출물은 자연어나 간단한 목록 형태로 표현된 요구사항 명세서이다. 이 문서에는 발견된 엔터티, 속성, 관계에 대한 설명과 함께 중요한 비즈니스 규칙(예: "한 명의 고객은 여러 개의 주문을 가질 수 있다", "각 주문은 반드시 한 명의 고객에 의해 이루어진다")이 명시된다. 요구사항 분석이 정확하지 않으면 이후 설계 단계 전체가 잘못된 방향으로 진행될 수 있으므로, 이해관계자와의 지속적인 검증과 피드백이 필수적이다.
개념적 설계는 요구사항 분석 단계에서 수집된 정보를 바탕으로, 사용자와 개발자가 공유할 수 있는 고수준의 데이터 모델을 만드는 과정이다. 이 단계에서는 실제 데이터베이스 관리 시스템의 제약이나 물리적 저장 구조를 고려하지 않고, 순수하게 업무 영역의 핵심 개체와 그들 간의 관계를 식별하고 정의하는 데 중점을 둔다.
주요 작업은 엔터티를 추출하고, 각 엔터티의 속성을 식별하며, 엔터티 간의 관계를 규명하는 것이다. 이때 생성되는 모델이 개념적 ERD이다. 개념적 설계의 결과물은 특정 DBMS나 구현 기술에 종속되지 않으며, 비기술적 이해관계자도 쉽게 이해할 수 있는 추상화 수준을 유지한다.
설계 단계 | 주요 입력 | 주요 활동 | 산출물 | 특징 |
|---|---|---|---|---|
개념적 설계 | 요구사항 명세서 | 엔터티/속성/관계 식별 | 개념적 ERD | DBMS 독립적, 비기술자와 소통 용이 |
이 단계를 통해 데이터의 논리적 구조와 비즈니스 규칙이 명확해지며, 이후 논리적 설계 단계에서 정규화 등을 적용하기 위한 견고한 기초를 마련한다. 개념적 모델의 정확성은 전체 데이터베이스 설계의 품질을 결정하는 핵심 요소가 된다.
논리적 설계 단계는 개념적 설계에서 도출된 개념적 ERD를 특정 데이터베이스 관리 시스템의 논리적 구조로 변환하는 과정이다. 이 단계에서는 개념적 모델이 구체적인 데이터 모델의 형태로 정제된다. 주로 관계형 데이터베이스를 대상으로 할 경우, 모든 엔터티는 테이블로, 모든 속성은 컬럼으로, 모든 관계는 기본키와 외래키를 통한 참조 무결성 규칙으로 매핑된다. 또한 다대다 관계를 해소하기 위한 교차 엔터티가 생성되고, 각 컬럼의 데이터 타입, 길이, 널 허용 여부 등이 상세히 정의된다.
이 단계의 핵심 작업은 정규화를 적용하여 데이터의 중복을 최소화하고 무결성을 확보하는 것이다. 일반적으로 제3정규형까지의 정규화가 수행되며, 이는 이행적 함수 종속과 같은 이상 현상을 제거한다. 설계자는 각 테이블의 기본키를 명확히 지정하고, 외래키 관계를 통해 엔터티 간의 연결을 구현한다. 그 결과물은 논리적 ERD이며, 이는 시스템의 비즈니스 규칙과 데이터 구조를 기술 스택에 독립적인 형태로 완전히 기술한다.
설계 요소 | 개념적 설계 단계 | 논리적 설계 단계 |
|---|---|---|
주요 대상 | 비즈니스 개념과 관계 | 특정 데이터 모델(예: 관계형) |
구성 요소 | 엔터티, 관계, 속성 | 테이블, 컬럼, 기본키, 외래키, 데이터 타입 |
관계 표현 | 개념적 연결 (예: 선과 마름모) | 참조 무결성 (기본키-외래키 연결) |
주요 활동 | 요구사항을 개념적 모델로 추상화 | 개념적 모델을 정규화된 논리적 스키마로 변환 |
산출물 | 개념적 ERD | 논리적 ERD, 정규화된 테이블 정의서 |
논리적 설계가 완료되면, 특정 DBMS의 물리적 저장 구조, 인덱스, 파티셔닝 등을 고려하는 물리적 설계 단계로 넘어간다. 논리적 설계는 비즈니스 요구사항을 기술적 청사진으로 변환하는 중추적 역할을 한다.
물리적 설계는 논리적 ERD를 특정 데이터베이스 관리 시스템(DBMS)에 실제로 구현하기 위한 구체적인 스키마를 정의하는 단계이다. 이 단계에서는 성능, 보안, 저장 공간 효율성 등 운영 환경의 제약 조건과 요구사항을 반영하여 데이터베이스의 물리적 구조를 결정한다.
주요 작업으로는 데이터 타입 선정, 인덱스 설계, 파티셔닝 및 클러스터링 전략 수립, 접근 권한 설정 등이 포함된다. 예를 들어, 논리적 모델의 '문자열' 속성은 DBMS에 따라 VARCHAR(255) 또는 NVARCHAR(100)과 같은 구체적인 타입으로 변환된다. 또한, 자주 조회되는 컬럼에 대한 인덱스를 생성하여 검색 성능을 향상시키거나, 대용량 테이블은 범위나 해시 기준으로 파티션을 나누어 관리 효율성을 높인다. 물리적 설계의 결과물은 SQL DDL(Data Definition Language) 스크립트 형태로 구체화된다.
설계 요소 | 설명 | 고려 사항 예시 |
|---|---|---|
데이터 타입 매핑 | 논리적 속성을 DBMS 지원 타입으로 변환 | 저장 공간 vs 정밀도, 문자 집합(Charset) |
인덱스 설계 | 검색 성능 향상을 위한 인덱스 정의 | 조회 빈도, 데이터 갱신 비용, 복합 인덱스 순서 |
테이블 스페이스/파일 그룹 | 데이터 파일의 물리적 저장 위치 지정 | 디스크 I/O 분산, 백업 전략 |
제약 조건 정의 | 기본키, 외래키, 유일성, 체크 제약 등 구현 | 데이터 무결성 vs 오버헤드 |
이 단계는 최종적으로 데이터베이스가 생성 및 운영되는 토대를 마련하며, 이후의 성능 튜닝과 용량 계획의 기준이 된다. 따라서 선택한 DBMS의 특성과 애플리케이션의 트랜잭션 패턴, 예상 데이터 규모 등을 종합적으로 분석하여 설계를 진행해야 한다.
ERD는 설계의 추상화 수준과 목적에 따라 크게 세 가지 종류로 구분된다. 각 종류는 데이터 모델링 과정의 특정 단계에 해당하며, 점차 구체화되는 특징을 보인다.
첫 번째는 개념적 ERD이다. 이는 가장 높은 수준의 추상화를 제공하며, 비즈니스의 핵심 엔터티와 그들 간의 주요 관계를 식별하는 데 초점을 맞춘다. 주로 요구사항 분석 단계에서 이해관계자와의 소통을 위해 사용되며, 속성의 상세한 기술은 배제하고 업무의 전체적인 구조를 파악하는 것이 목적이다. 예를 들어, '고객', '주문', '상품'과 같은 주요 개념과 이들의 연결 관계만을 표현한다.
두 번째는 논리적 ERD이다. 개념적 모델을 기반으로 모든 엔터티와 관계를 상세히 정의하고, 각 엔터티의 속성과 기본키, 외래키를 명시한다. 이 단계에서는 데이터의 중복을 최소화하기 위한 정규화가 수행되며, 특정 DBMS에 종속되지 않는 독립적인 데이터 구조를 설계한다. 논리적 ERD는 시스템 분석가와 데이터 설계자가 데이터의 논리적 구조를 완성하는 데 사용하는 핵심 산출물이다.
종류 | 목적 | 주요 특징 | 대상 독자 |
|---|---|---|---|
개념적 ERD | 비즈니스 개념과 관계 파악 | 엔터티와 관계 위주, 속성 생략 | 이해관계자, 비즈니스 분석가 |
논리적 ERD | 상세한 데이터 구조 설계 | 모든 속성, 키, 정규화 적용 | 시스템 분석가, 데이터 설계자 |
물리적 ERD | 실제 데이터베이스 구현 | DBMS 특성 반영(데이터 타입, 인덱스 등) | 데이터베이스 관리자, 개발자 |
마지막으로 물리적 ERD는 선택한 특정 DBMS에 맞춰 논리적 설계를 구체화한 것이다. 여기에는 컬럼의 정확한 데이터 타입, 인덱스, 뷰, 파티셔닝 등 실제 데이터베이스 성능과 저장 효율을 고려한 물리적 구현 사항이 포함된다. 이는 데이터베이스 관리자나 개발자가 스키마를 생성하거나 시스템 성능을 튜닝할 때 참조하는 최종 설계도 역할을 한다.
개념적 ERD는 데이터베이스 설계의 초기 단계에서 생성되는 모델로, 비즈니스 영역에서 존재하는 핵심 엔터티와 그들 간의 관계를 추상적이고 높은 수준에서 표현합니다. 이 모델은 기술적인 세부 사항보다는 비즈니스 개념과 규칙을 이해하는 데 중점을 둡니다. 주로 요구사항 분석 단계의 결과물을 바탕으로 이해관계자들과 소통하며 개발됩니다.
개념적 ERD의 주요 특징은 다음과 같습니다.
* 기술 독립성: 특정 DBMS나 물리적 저장 구조를 고려하지 않습니다.
* 추상화: 비즈니스 세계의 주요 개념만을 엔터티로 식별하고, 그들 간의 의미 있는 연관성을 관계로 정의합니다.
* 의사소통 도구: 개발자, 분석가, 최종 사용자 등 비기술적 이해관계자들도 쉽게 이해할 수 있도록 작성됩니다.
개념적 ERD는 일반적으로 엔터티의 주요 속성만을 포함하며, 기본키나 외래키와 같은 구현 세부사항은 배제합니다. 예를 들어, '고객', '주문', '상품'과 같은 엔터티와 '고객은 주문을 한다', '주문은 상품을 포함한다'와 같은 관계가 중심이 됩니다.
이 모델은 이후 단계인 논리적 설계의 기초가 됩니다. 논리적 설계 단계에서는 개념적 ERD를 바탕으로 속성을 상세화하고, 정규화를 적용하며, 데이터 타입과 키를 정의하여 특정 데이터 모델(예: 관계형 모델)에 맞게 변환합니다. 따라서 개념적 ERD는 비즈니스 요구사항을 데이터 구조로 변환하는 첫 번째이자 가장 중요한 청사진 역할을 합니다.
논리적 ERD는 개념적 ERD에서 정의된 비즈니스 개념과 관계를 구체적인 데이터 구조로 변환한 모델이다. 이 단계에서는 엔터티와 속성이 특정 데이터베이스 관리 시스템(DBMS)에 종속되지 않는 형태로 상세하게 정의된다. 주된 목표는 데이터의 논리적 구조와 무결성 규칙을 명확히 하는 것이다.
논리적 설계에서는 개념적 ERD의 엔터티가 테이블로, 속성은 컬럼으로, 관계는 외래 키로 구체화된다. 각 엔터티의 기본 키가 지정되고, 속성의 데이터 타입(예: 문자열, 숫자, 날짜)과 제약 조건(예: NULL 허용 여부)이 정의된다. 또한 정규화 과정을 통해 데이터의 중복을 최소화하고 일관성을 보장하는 구조를 만드는 것이 핵심 작업이다.
설계 요소 | 개념적 ERD에서의 표현 | 논리적 ERD에서의 표현 |
|---|---|---|
사물/개념 | 엔터티 타입 | 테이블(Table) |
특성 | 컬럼(Column) 및 데이터 타입 | |
고유 식별자 | 개념적 식별자 | 기본 키(Primary Key) |
연관성 | 관계(Relationship) | 외래 키(Foreign Key) 참조 |
이 모델은 아직 물리적인 저장 구조나 성능 최적화를 고려하지 않는다. 대신 비즈니스 규칙을 데이터 규칙으로 완전히 매핑하는 데 중점을 둔다. 결과물은 특정 DBMS(예: 오라클, MySQL, PostgreSQL)로 구현 가능한 상세한 스키마의 청사진 역할을 한다.
물리적 ERD는 논리적 ERD를 특정 데이터베이스 관리 시스템(DBMS)의 물리적 구조에 맞게 구체화한 모델이다. 이 단계에서는 실제 데이터베이스 스키마를 생성하기 위한 모든 기술적 세부사항을 정의한다. 논리적 모델의 엔터티는 테이블로, 속성은 컬럼으로 변환되며, 데이터 타입, 길이, 기본키, 외래키, 인덱스 등이 명시된다. 또한 테이블스페이스, 파티셔닝, 클러스터링과 같은 물리적 저장 구조와 성능 관련 사항이 반영된다.
주요 설계 요소는 다음과 같다.
설계 요소 | 설명 |
|---|---|
데이터 타입 정의 | DBMS별 지원 타입(VARCHAR2, NUMBER, DATE 등)에 맞춰 각 컬럼의 정확한 타입과 길이를 지정한다. |
제약 조건 명시 | 기본키(PRIMARY KEY), 외래키(FOREIGN KEY), UNIQUE, NOT NULL, CHECK 등의 제약 조건을 추가한다. |
인덱스 설계 | 조회 성능을 위해 테이블의 특정 컬럼 또는 컬럼 조합에 대한 인덱스를 생성한다. |
물리적 저장 속성 | 데이터 파일의 저장 위치, 테이블스페이스 할당, 레코드 물리적 순서(클러스터링) 등을 결정한다. |
물리적 ERD는 최종적으로 SQL DDL(Data Definition Language) 문으로 변환되어 데이터베이스를 구축하는 데 직접 사용된다. 따라서 특정 DBMS의 제약과 기능을 고려해야 하며, 정규화된 구조를 유지하면서도 쿼리 성능을 위해 선택적 반정규화를 적용할 수 있다. 이 모델은 데이터베이스 관리자(DBA)와 개발자가 실제 구현을 수행하는 기준이 된다.
ERD 작성에는 전용 데이터 모델링 도구부터 범용 다이어그램 도구까지 다양한 소프트웨어가 활용된다. 이러한 도구들은 시각적 설계를 지원하고, 데이터베이스 스키마를 자동 생성하거나 리버스 엔지니어링하는 기능을 제공하여 설계 효율성을 높인다.
전문적인 데이터 모델링 작업에는 ERwin Data Modeler, SAP PowerDesigner, Oracle SQL Developer Data Modeler와 같은 전용 도구가 널리 사용된다. 이들 도구는 Chen 표기법과 Crow's Foot 표기법을 포함한 다양한 표기법을 지원하며, 설계된 모델로부터 특정 DBMS(데이터베이스 관리 시스템)용 DDL(데이터 정의 언어) 스크립트를 자동 생성하는 기능이 핵심이다. 또한, 기존 데이터베이스의 스키마를 분석하여 ERD로 변환하는 리버스 엔지니어링도 가능하다. 이들은 대규모 프로젝트에서 데이터 사전 관리, 버전 관리, 팀 협업 기능을 제공한다.
보다 접근성이 높은 범용 다이어그램 도구들도 ERD 작성에 활발히 사용된다. draw.io(diagrams.net), Lucidchart, Microsoft Visio, Miro 등이 대표적이다. 이들 도구는 ERD 요소(엔터티, 관계)를 위한 템플릿이나 스텐실을 제공하며, 대부분 웹 기반으로 작동하여 설치 없이 사용할 수 있고 실시간 협업이 용이하다. 무료 플랜을 제공하는 경우가 많아 학습이나 소규모 프로젝트에 적합하다. 최근에는 Visual Studio Code의 확장 프로그램이나 PlantUML과 같은 코드 기반 다이어그램 도구도 인기를 얻고 있다.
도구 유형 | 대표 예시 | 주요 특징 |
|---|---|---|
전용 데이터 모델링 도구 | ERwin, SAP PowerDesigner, Oracle SQL Developer Data Modeler | DDL 자동 생성, 리버스 엔지니어링, 정교한 모델 관리 기능 |
범용 다이어그램/협업 도구 | draw.io, Lucidchart, Miro, Visio | 접근성 용이, 실시간 협업, 다양한 다이어그램 지원 |
코드 기반/기타 도구 | PlantUML, Visual Studio Code 확장 프로그램 | 버전 관리 시스템과의 호환성 우수, 텍스트 기반 설계 |
도구 선택은 프로젝트의 규모, 예산, 팀의 협업 방식, 목표 DBMS와의 통합 필요성 등을 고려하여 결정한다. 전용 도구는 복잡한 엔터프라이즈 환경에, 범용 도구는 신속한 프로토타이핑이나 시각적 커뮤니케이션에 더 적합한 경우가 많다.
전용 ERD 도구는 데이터베이스 설계에 특화된 전문 소프트웨어이다. ERwin Data Modeler와 SAP PowerDesigner가 대표적인 예이다. 이러한 도구들은 개념적 모델링부터 논리적 모델링, 물리적 모델링까지의 전 과정을 지원하며, 다양한 데이터베이스 관리 시스템에 대한 스키마를 자동으로 생성하는 기능을 제공한다. 또한 정규화 검증, 역공학, 버전 관리, 팀 협업 기능 등 강력한 데이터 모델링 생명주기 관리 기능을 갖추고 있다.
이들 도구의 주요 특징은 다음과 같다.
기능 | 설명 |
|---|---|
다중 모델 지원 | |
스키마 생성 | 설계된 모델로부터 특정 DBMS(예: Oracle, SQL Server, MySQL)의 DDL 스크립트를 자동 생성한다. |
역공학 | 기존 데이터베이스로부터 ERD를 추출하여 모델을 복원한다. |
표준 준수 | |
협업 및 버전 관리 | 여러 설계자가 동시에 작업하고 변경 이력을 관리할 수 있다. |
전용 도구는 기업 환경에서 복잡한 대규모 데이터베이스를 설계하고 문서화할 때 그 진가를 발휘한다. 높은 수준의 정확성과 일관성을 유지해야 하는 프로젝트에 적합하다. 그러나 상용 소프트웨어인 경우 라이선스 비용이 발생하며, 사용법을 익히는데 학습 곡선이 존재한다는 점은 고려해야 한다.
다이어그램 도구는 ERD를 포함한 다양한 유형의 다이어그램을 그리는 데 사용되는 범용 도구이다. 전용 데이터 모델링 도구에 비해 기능이 단순할 수 있지만, 접근성과 사용 편의성이 높고 협업 기능에 강점을 보인다. 대부분 웹 기반으로 제공되어 별도의 설치 없이 브라우저에서 바로 작업할 수 있으며, 실시간 공동 편집을 지원하는 경우가 많다.
대표적인 도구로는 draw.io(diagrams.net)와 Lucidchart가 있다. draw.io는 무료 오픈 소스 도구로, 온라인과 오프라인 모두에서 사용 가능하며 Google Drive나 GitHub 등과의 연동이 용이하다. Lucidchart는 프리미엄 기능을 갖춘 상용 서비스로, 템플릿 라이브러리와 고급 협업 기능을 제공한다. 이들 도구는 기본적인 엔터티와 관계 기호를 지원하며, Crow's Foot 표기법을 포함한 여러 표기법을 사용할 수 있다.
도구명 | 주요 특징 | 비용 |
|---|---|---|
draw.io(diagrams.net) | 오픈 소스, 무료, 다양한 저장소 연동 (OneDrive, Google Drive, GitHub 등) | 무료 |
풍부한 템플릿, 강력한 협업 및 통합 기능 (Google Workspace, Microsoft Teams 등) | 프리미엄 유료[3] | |
데스크톱 애플리케이션, Microsoft 365 생태계와 긴밀한 통합 | 유료 (독립 제품 또는 Microsoft 365 구독 포함) |
이러한 다이어그램 도구는 빠른 프로토타이핑, 교육 목적, 또는 소규모 프로젝트의 초기 설계 단계에 적합하다. 그러나 대규모 데이터베이스의 정교한 논리적/물리적 설계, 정규화 자동화, DDL 스크립트 생성, 리버스 엔지니어링과 같은 고급 기능이 필요한 경우에는 ERwin이나 SAP PowerDesigner 같은 전용 데이터 모델링 도구가 더 적합하다.
ERD 설계 시에는 데이터의 논리적 구조를 명확히 표현하는 동시에 실제 시스템의 효율성을 보장하기 위해 몇 가지 중요한 사항을 고려해야 한다. 주요 고려사항으로는 정규화와 성능 최적화가 있으며, 이 둘은 상충되는 목표를 가질 수 있어 설계자의 판단이 필요하다.
정규화는 데이터의 중복을 최소화하고 이상 현상을 방지하기 위한 과정이다. 일반적으로 제1정규형부터 제3정규형 또는 보이스-코드 정규형까지 진행하여, 각 엔터티가 단일 주제에 대한 정보만을 담고 속성들이 완전히 함수적 종속성을 갖도록 구조를 조정한다. 이는 데이터 일관성과 무결성을 유지하는 데 필수적이다. 그러나 지나친 정규화는 너무 많은 엔터티와 관계를 생성하여, 하나의 질의를 처리하기 위해 여러 테이블을 조인해야 하는 상황을 초래할 수 있다.
이에 따라 성능 최적화를 위해 선택적 비정규화가 필요할 수 있다. 자주 함께 조회되는 속성들을 하나의 테이블로 통합하거나, 계산된 값을 미리 저장하는 파생 속성을 추가하는 방법이 사용된다. 또한, 조회 패턴을 분석하여 자주 사용되는 관계 경로를 단순화하거나, 인덱스 설계를 고려한 엔터티 구조를 미리 반영하기도 한다. 설계 단계에서 예상되는 트랜잭션의 유형(조회 위주인지, 갱신 위주인지)과 볼륨을 고려하여 정규화 수준을 결정하는 것이 중요하다.
고려 사항 | 주요 목표 | 일반적 기법 | 주의점 |
|---|---|---|---|
정규화 | 데이터 무결성, 중복 제거 | 함수적 종속성 제거, 엔터티 분리 | 과도한 조인 유발 가능 |
성능 최적화 | 응답 시간 단축, 처리 효율 향상 | 선택적 비정규화, 파생 컬럼 추가, 인덱스 고려 | 데이터 중복 및 갱신 이상 발생 가능 |
결국 효과적인 ERD 설계는 정규화를 통해 얻는 구조적 안정성과 성능 최적화를 위한 실용성 사이의 균형을 찾는 과정이다. 이는 명확한 요구사항 분석과 향후 시스템의 확장성을 함께 고려하여 이루어진다.
정규화는 데이터베이스 설계에서 데이터 중복을 최소화하고 데이터의 무결성을 보장하기 위한 구조화된 프로세스이다. 이는 관계형 데이터베이스 설계의 핵심 원리로, 잘 정의된 일련의 단계(정규형)를 통해 테이블 구조를 점진적으로 개선한다. 정규화의 주요 목표는 삽입, 갱신, 삭제 시 발생할 수 있는 이상 현상을 방지하는 것이다.
정규화는 일반적으로 제1정규형부터 시작하여 보통 제3정규형 또는 보이스-코드 정규형까지 진행된다. 각 정규형은 특정 조건을 만족해야 한다.
정규형 | 약어 | 주요 조건 요약 |
|---|---|---|
제1정규형 | 1NF | 모든 속성의 값이 원자 값이어야 함. 반복 그룹 제거. |
제2정규형 | 2NF | |
제3정규형 | 3NF | 2NF 만족. 모든 비주요 속성이 기본키에 직접 종속적이어야 함(이행적 종속 제거). |
보이스-코드 정규형 | BCNF | 3NF의 강화된 형태. 모든 결정자가 후보키가 되도록 함. |
정규화를 수행하면 데이터는 논리적으로 분리되고 중복이 줄어들어 일관성을 유지하기 쉬워진다. 예를 들어, 주문 정보와 고객 주소 정보가 하나의 테이블에 섞여 있다면, 고객 주소가 변경될 때마다 모든 주문 레코드를 갱신해야 하는 이상 현상이 발생한다. 정규화를 통해 고객 테이블과 주문 테이블을 분리하면 이 문제를 해결할 수 있다.
그러나 지나친 정규화는 성능 저하를 초래할 수 있다. 여러 테이블로 분리되면 데이터를 조회할 때 조인 연산이 빈번해져 응답 시간이 느려질 수 있다. 따라서 실제 데이터베이스 설계에서는 정규화 이론을 준수하되, 시스템의 성능 요구사항을 고려하여 선택적으로 역정규화를 적용하기도 한다.
ERD 설계는 데이터의 논리적 구조를 정의하는 동시에, 최종적으로 구축될 데이터베이스의 성능에 직접적인 영향을 미친다. 따라서 성능 최적화는 물리적 설계 단계에서 중요한 고려사항이 된다. 주요 접근 방식은 정규화된 구조를 일부 조정하여 데이터 접근 효율성을 높이는 것이다. 이는 주로 역정규화 기법을 통해 이루어지며, 자주 함께 조회되는 테이블을 합치거나 계산된 값을 미리 저장하는 파생 컬럼을 추가하는 방법 등이 포함된다.
성능 최적화를 위한 구체적인 전략은 다음과 같다.
최적화 기법 | 설명 | 고려사항 |
|---|---|---|
조인 연산을 줄이기 위해 테이블을 통합하거나 중복 데이터를 허용한다. | 데이터 일관성 유지가 어려워지고, 저장 공간이 증가할 수 있다. | |
인덱스 설계 | 자주 검색 조건으로 사용되는 속성에 인덱스를 생성하여 조회 속도를 향상시킨다. | 너무 많은 인덱스는 데이터 삽입/수정/삭제 성능을 저하시킨다. |
대용량 테이블을 물리적으로 나누어 관리함으로써 I/O 부하를 분산시킨다. | 파티션 키 선정과 관리 복잡도가 증가한다. | |
집계 쿼리 성능을 위해 요약 테이블이나 물질화된 뷰를 생성한다. | 원본 데이터 변경 시 동기화 오버헤드가 발생한다. |
이러한 최적화는 시스템의 예상 워크로드와 트랜잭션 패턴을 기반으로 신중하게 적용해야 한다. 예를 들어, 보고서 생성이 많은 OLAP 시스템에서는 역정규화와 미리 계산이 효과적일 수 있으나, 실시간 트랜잭션 처리OLTP가 주인 시스템에서는 과도한 역정규화가 오히려 성능을 해칠 수 있다. 최적의 설계는 데이터 무결성, 유연성, 그리고 성능 요구사항 사이의 균형을 찾는 과정이다.
ERD는 데이터베이스 설계의 핵심 도구로서 명확한 장점을 제공하지만, 특정 한계점도 존재한다.
주요 장점은 복잡한 데이터 모델을 직관적이고 시각적으로 표현할 수 있다는 점이다. 이는 기술적 배경이 없는 이해관계자와의 의사소통을 용이하게 하여 요구사항 분석과 검증 과정을 효율화한다. 또한, 엔터티와 속성, 관계를 명시적으로 정의함으로써 데이터의 논리적 구조와 무결성 제약 조건을 문서화하는 표준적인 방법을 제공한다. 이는 시스템 개발의 초기 단계에서 설계 오류를 사전에 발견하고, 향후 유지보수 및 확장에 필요한 청사진 역할을 한다.
그러나 ERD에는 몇 가지 한계가 있다. 첫째, ERD는 정적인 구조를 보여주는 데 특화되어 있어, 데이터의 동적인 처리 흐름이나 비즈니스 로직을 표현하기는 어렵다. 둘째, 표기법과 추상화 수준에 따라 동일한 시스템이 다르게 표현될 수 있어, 일관된 해석을 위해서는 명확한 표준과 충분한 설명이 필요하다. 마지막으로, 매우 복잡한 대규모 시스템의 경우, 하나의 다이어그램에 모든 요소를 포함하면 가독성이 현저히 떨어질 수 있다. 이를 보완하기 위해 여러 수준의 ERD를 작성하거나, 다른 모델링 기법(예: 데이터 흐름도)과 함께 사용하는 것이 일반적이다.