ERD(Entity-Relationship Diagram)는 데이터베이스의 논리적 구조를 시각적으로 표현한 설계도이다. 이 다이어그램은 시스템에 저장될 데이터의 구성 요소인 엔터티(Entity), 그 엔터티의 특성을 나타내는 속성(Attribute), 그리고 엔터티 간의 관계(Relationship)를 도형과 선으로 표현한다. 데이터베이스 설계의 초기 단계에서 핵심적인 역할을 하며, 개발자, 분석가, 이해관계자 간의 효과적인 의사소통 도구로 사용된다.
ERD의 주요 목적은 복잡한 비즈니스 요구사항을 명확하고 구조화된 데이터 모델로 전환하는 것이다. 이를 통해 설계의 오류나 누락을 사전에 발견하고, 데이터의 중복을 방지하며, 일관된 데이터 구조를 확립할 수 있다. ERD는 이후 물리적 데이터베이스 스키마를 생성하는 직접적인 근거가 된다.
용어 | 설명 |
|---|---|
비즈니스 요구사항을 기술 중심으로 표현한 모델. ERD가 이에 해당한다. | |
특정 DBMS에 독립적으로 데이터 구조를 상세화한 모델. | |
특정 DBMS의 특성을 반영하여 실제 저장 구조를 정의한 모델. |
ERD 작성은 소프트웨어 개발 수명 주기(SDLC)의 분석 및 설계 단계에서 수행되며, 잘 구성된 ERD는 데이터 무결성 보장, 시스템 성능 향상, 유지보수 용이성에 기여한다.
ERD는 데이터베이스의 논리적 구조를 시각적으로 표현한 설계도이다. 이 다이어그램은 시스템에 저장될 데이터의 주요 구성 요소인 엔터티, 속성, 그리고 이들 간의 관계를 추상화하여 보여준다. ERD를 작성하는 근본적인 목적은 이해관계자들 간의 명확한 의사소통을 촉진하고, 데이터 요구사항을 체계적으로 분석하며, 최종적으로 효율적이고 오류가 적은 물리적 데이터베이스 스키마를 구축하는 기반을 마련하는 데 있다.
가장 핵심적인 구성 요소는 엔터티이다. 엔터티는 데이터베이스에 저장할 정보의 주체가 되는 독립적인 실체를 의미한다. 예를 들어, '고객', '주문', '상품' 등이 엔터티에 해당한다. 각 엔터티는 자신을 고유하게 식별할 수 있는 기본 키를 가진다. 다음으로, 속성은 각 엔터티가 가지는 세부적인 특성이나 정보를 나타낸다. '고객' 엔터티의 경우 '고객ID', '이름', '이메일', '주소' 등이 속성이 된다. 속성은 다시 단일값을 가지는 단순 속성과, 여러 하위 속성으로 구성된 복합 속성, 그리고 여러 값을 가질 수 있는 다중값 속성 등으로 구분된다.
마지막 핵심 요소는 관계이다. 관계는 두 개 이상의 엔터티 간에 존재하는 논리적인 연결을 정의한다. 예를 들어, '고객' 엔터티와 '주문' 엔터티는 '주문한다'는 관계로 연결된다. 이 관계는 참여하는 엔터티 인스턴스들 간의 수적 제약을 나타내는 카디널리티로 더욱 구체화된다. 주요 카디널리티에는 1:1(일대일), 1:N(일대다), N:M(다대다) 관계가 있다. 또한, 관계에 참여하는 것이 필수적인지 선택적인지를 나타내는 참여 제약도 함께 정의된다.
엔터티는 ERD에서 관리해야 할 정보의 주체가 되는 독립적인 실체를 나타낸다. 데이터베이스에서 저장할 가치가 있는 사람, 장소, 사물, 개념, 사건 등이 이에 해당한다. 예를 들어, '고객', '제품', '주문', '부서'는 모두 엔터티가 될 수 있다. 각 엔터티는 고유한 이름을 가지며, 일반적으로 명사로 지어진다. 데이터베이스 설계 단계에서는 이러한 엔터티들이 이후 테이블로 변환된다.
엔터티는 그 특성에 따라 여러 유형으로 구분된다. 유형 엔터티는 물리적인 형태가 있는 실체를, 개념 엔터티는 물리적 형태는 없지만 관리해야 할 개념을 의미한다. 또한, 엔터티 집합 내의 각각의 개별 실체는 엔터티 인스턴스라고 부른다. 예를 들어, '고객'이라는 엔터티 집합에 속한 "홍길동", "김철수"와 같은 개별 고객 기록이 엔터티 인스턴스에 해당한다.
엔터티를 식별할 때는 다음 조건을 충족해야 한다.
* 두 개 이상의 속성을 가져야 한다.
* 하나 이상의 속성이 유일성을 보장하는 기본키로 지정될 수 있어야 한다.
* 데이터베이스에서 관리할 필요가 있는 정보여야 한다.
* 다른 엔터티와 하나 이상의 관계를 맺을 수 있어야 한다.
엔터티 유형 | 설명 | 예시 |
|---|---|---|
강한 엔터티(Independent Entity) | 자신의 기본키만으로 독립적으로 존재할 수 있는 엔터티 |
|
약한 엔터티(Weak Entity) | 다른 엔터티의 존재에 의존적이며, 일반적으로 식별 관계를 통해 존재 의미를 완성하는 엔터티 |
|
엔터티가 가지는 구체적인 특성이나 상태를 나타내는 가장 작은 논리적 단위이다. 속성은 엔터티를 구성하고 설명하는 데 필요한 정보 항목으로, 데이터베이스 테이블의 열(Column)에 해당한다. 예를 들어, '고객'이라는 엔터티는 '고객ID', '이름', '전화번호', '주소' 등의 속성으로 구성된다.
속성은 그 특징에 따라 여러 유형으로 분류된다. 주요 분류 기준은 다음과 같다.
분류 기준 | 유형 | 설명 | 예시 |
|---|---|---|---|
구성 방식 | 단순 속성 | 더 이상 분해할 수 없는 원자적인 속성이다. | 나이, 이름 |
복합 속성 | 두 개 이상의 단순 속성으로 구성될 수 있는 속성이다. | 주소(시, 구, 동, 상세주소) | |
값의 특성 | 단일값 속성 | 하나의 값만을 가지는 속성이다. | 주민등록번호 |
다중값 속성 | 두 개 이상의 값을 가질 수 있는 속성이다. | 연락처(집전화, 휴대전화, 회사전화) | |
유도 가능성 | 저장 속성 | 실제로 데이터베이스에 저장되는 기본 속성이다. | 생년월일 |
유도 속성 | 다른 속성의 값으로부터 계산되거나 유추되어 얻어지는 속성이다. | 나이(생년월일로부터 계산), 총구매액 |
속성은 엔터티의 인스턴스(개별 데이터)를 유일하게 식별하는 데 핵심적인 역할을 한다. 이를 위해 하나 이상의 속성은 기본 키로 지정된다. 기본 키는 엔터티의 각 인스턴스를 고유하게 구분하며, 널 값을 가질 수 없고 중복될 수 없다. '고객ID'나 '학번'이 대표적인 예이다.
관계는 두 개 이상의 엔터티가 서로 어떻게 연관되어 있는지를 정의하는 연결 고리이다. 관계는 엔터티 간의 업무 규칙이나 논리적 연결을 표현하며, ERD에서 마름모 기호나 선으로 표시된다. 예를 들어, '학생' 엔터티와 '강의' 엔터티 사이에는 '수강한다'라는 관계가 존재할 수 있다. 관계는 단순히 연결만을 나타내는 것이 아니라, 그 연결의 성격과 수적 제약을 함께 표현한다.
관계의 중요한 특성 중 하나는 카디널리티이다. 카디널리티는 한 엔터티의 인스턴스가 다른 엔터티의 몇 개의 인스턴스와 연결될 수 있는지를 나타내는 수적 관계이다. 주요 카디널리티에는 다음과 같은 세 가지 유형이 있다.
관계 유형 | 설명 | 예시 (고객 : 주문) |
|---|---|---|
일대일 (1:1) | 한 엔터티의 하나의 인스턴스가 다른 엔터티의 하나의 인스턴스와만 관계를 맺는다. | 한 사람은 하나의 주민등록증을 가진다. |
일대다 (1:N) | 한 엔터티의 하나의 인스턴스가 다른 엔터티의 여러 인스턴스와 관계를 맺는다. | 한 고객은 여러 개의 주문을 할 수 있다. |
다대다 (M:N) | 한 엔터티의 여러 인스턴스가 다른 엔터티의 여러 인스턴스와 관계를 맺는다. | 한 학생은 여러 강의를 수강하고, 한 강의에는 여러 학생이 등록한다. |
다대다(M:N) 관계는 데이터베이스에 직접 구현될 수 없으므로, 일반적으로 연결 엔터티(또는 교차 엔터티)를 생성하여 두 개의 일대다(1:N) 관계로 분해한다. 예를 들어, '수강'이라는 연결 엔터티를 도입하여 '학생'과 '강의'의 다대다 관계를 해결한다. 또한, 관계는 선택적이거나 필수적일 수 있으며, 이는 관계선 위에 표시되는 선택성 기호(동그라미 또는 수직선)로 표현되어 특정 관계가 반드시 존재해야 하는지 여부를 나타낸다.
ERD 작성은 일반적으로 체계적인 단계를 거쳐 진행된다. 요구사항 분석에서 시작하여 최종적으로 정규화된 모델을 완성하는 과정이다.
첫 번째 단계는 요구사항 분석이다. 이 단계에서는 데이터베이스가 저장해야 할 정보와 시스템이 수행해야 할 기능을 명확히 파악한다. 사용자 인터뷰, 기존 문서 분석, 업무 프로세스 조사 등을 통해 핵심 데이터 객체와 그들 간의 업무 규칙을 도출한다. 분석 결과는 요구사항 명세서나 유스케이스 다이어그램 등으로 문서화한다.
다음으로, 분석된 요구사항을 바탕으로 엔터티와 속성을 정의한다. 핵심 명사나 개념을 추출하여 엔터티 후보로 선정하고, 각 엔터티를 설명하는 특성이나 데이터 항목을 속성으로 나열한다. 이때 각 엔터티는 유일한 기본키 속성을 갖도록 식별한다. 예를 들어, '회원' 엔터티에는 회원번호, 이름, 이메일 등의 속성이 포함될 수 있다.
단계 | 주요 활동 | 산출물 예시 |
|---|---|---|
요구사항 분석 | 인터뷰, 문서 분석, 업무 흐름 파악 | 요구사항 명세서, 유스케이스 |
엔터티/속성 정의 | 핵심 객체 추출, 특성 나열 | 엔터티-속성 목록 |
관계 설정 | 엔터티 간 연관성 및 관계 차수 정의 | 초기 ERD 스케치 |
정규화 적용 | 데이터 중복 제거, 구조 개선 | 정규화된 최종 ERD |
세 번째 단계는 엔터티 간의 관계를 설정하고 카디널리티를 정의하는 것이다. 엔터티들이 어떻게 서로 연관되는지(예: '회원'이 '주문'을 한다)를 식별하고, 관계의 유형(일대일, 일대다, 다대다)과 선택적/필수적 참여 여부를 결정한다. 이 정보는 관계선 위에 표기법(예: Crow's Foot)을 사용하여 표시한다. 마지막으로 정규화를 적용하여 데이터의 중복을 최소화하고 무결성을 확보한다. 일반적으로 제1정규형부터 제3정규형 또는 보이스-코드 정규형까지 진행하여 논리적 데이터 모델을 완성한다.
요구사항 분석은 ERD 작성의 첫 번째이자 가장 중요한 단계이다. 이 단계에서는 데이터베이스가 저장하고 관리해야 할 정보와 시스템이 수행해야 할 기능을 명확히 규정한다. 분석 결과는 이후 모든 설계 결정의 근거가 되므로, 철저하고 정확하게 수행되어야 한다.
분석 과정은 일반적으로 다음과 같은 활동을 포함한다.
분석 활동 | 주요 내용 |
|---|---|
이해관계자 인터뷰 | 시스템 사용자, 관리자, 클라이언트 등과의 대화를 통해 비즈니스 프로세스와 데이터 필요성을 파악한다. |
문서 분석 | 기존 시스템 명세서, 업무 매뉴얼, 보고서, 양식 등을 검토하여 데이터 흐름과 구조를 이해한다. |
유스케이스 정의 | 시스템이 사용자에게 제공해야 할 기능적인 요구사항을 시나리오 형태로 정리한다. |
분석을 통해 도출해야 할 핵심 산출물은 다음과 같다. 첫째, 시스템에서 관리해야 할 주요 정보 객체, 즉 후보 엔터티와 그 속성 목록이다. 예를 들어, '서점 관리 시스템'에서는 '고객', '도서', '주문' 등이 후보 엔터티가 될 수 있다. 둘째, 이러한 엔터티들 간의 업무적 연관성, 즉 관계의 유형과 규칙이다. '한 명의 고객은 여러 주문을 할 수 있다'와 같은 비즈니스 규칙이 여기에 해당한다. 마지막으로 데이터에 대한 제약 조건, 예를 들어 '주문 금액은 0보다 커야 한다'거나 '고객 이메일은 고유해야 한다'는 등의 규칙을 명시해야 한다.
요구사항 분석이 미흡할 경우, 설계 단계에서 중요한 엔터티나 관계가 누락되거나, 실제 비즈니스 규칙을 반영하지 못하는 데이터베이스가 만들어질 수 있다. 이는 개발 후반부에 큰 수정을 필요로 하여 비용과 시간을 낭비하는 결과를 초래한다. 따라서 분석 단계에서 명확하고 모호함이 없는 요구사항 명세서를 작성하는 것이 성공적인 데이터베이스 설계의 기초를奠定한다.
엔터티는 데이터베이스에 저장할 대상이 되는 실체나 개념을 의미한다. 예를 들어, '고객', '주문', '상품'과 같은 명사 형태의 독립적인 존재가 엔터티가 된다. 각 엔터티는 고유한 이름을 가지며, 동일한 종류의 여러 개체(인스턴스)의 집합을 나타낸다. 강한 엔터티는 독립적으로 존재할 수 있고, 약한 엔터티는 다른 엔터티의 존재에 의존한다[1].
속성은 엔터티가 가지는 세부적인 특성이나 데이터 항목을 말한다. '고객' 엔터티의 경우 '고객ID', '이름', '전화번호', '주소' 등이 속성에 해당한다. 속성은 다음과 같이 분류된다.
속성 유형 | 설명 | 예시 |
|---|---|---|
기본키(Primary Key) | 엔터티의 각 인스턴스를 고유하게 식별하는 속성 |
|
외래키(Foreign Key) | 다른 엔터티와의 관계를 정의하는 참조 속성 |
|
단순 속성 | 더 이상 분해할 수 없는 원자적인 속성 |
|
복합 속성 | 여러 하위 속성으로 구성될 수 있는 속성 |
|
유도 속성 | 다른 속성의 값으로부터 계산되어 파생되는 속성 |
|
엔터티와 속성을 정의할 때는 명확한 명명 규칙을 따르고, 각 속성의 데이터 타입과 제약 조건을 고려하는 것이 중요하다. 또한, 하나의 엔터티 내에서 속성들은 해당 엔터티에 종속되어야 하며, 다른 엔터티의 기본키를 제외한 속성을 중복해서 가지지 않도록 설계한다. 이 과정은 이후 정규화의 기초가 된다.
엔터티와 속성을 정의한 후, 다음 단계는 엔터티 간의 관계를 식별하고 정의하는 것이다. 관계는 엔터티들이 서로 어떻게 연관되어 있는지를 표현하며, 이때 관계의 수적 제약을 나타내는 카디널리티를 함께 명시해야 한다.
카디널리티는 일반적으로 세 가지 주요 유형으로 구분된다. 이는 두 엔터티 간에 하나의 인스턴스가 상대방 엔터티의 몇 개의 인스턴스와 연결될 수 있는지를 정의한다.
카디널리티 유형 | 설명 | 예시 (고객 : 주문) |
|---|---|---|
일대일 (1:1) | 엔터티 A의 하나의 인스턴스가 엔터티 B의 하나의 인스턴스에만 연관된다. | 한 명의 고객은 하나의 기본 배송지 정보를 가진다. |
일대다 (1:N) | 엔터티 A의 하나의 인스턴스가 엔터티 B의 여러 인스턴스와 연관될 수 있다. | 한 명의 고객은 여러 개의 주문을 할 수 있다. |
다대다 (M:N) | 엔터티 A의 여러 인스턴스가 엔터티 B의 여러 인스턴스와 연관될 수 있다. | 하나의 제품은 여러 주문에 포함될 수 있고, 하나의 주문에는 여러 제품이 포함될 수 있다. |
다대다 관계는 데이터베이스에서 직접 구현될 수 없으므로, 일반적으로 연결 엔터티(교차 엔터티 또는 관계 테이블)를 생성하여 두 개의 일대다 관계로 분해한다. 예를 들어, '주문'과 '제품' 사이의 다대다 관계는 '주문상세'라는 새로운 엔터티를 도입하여 '주문'과 '주문상세'는 일대다, '제품'과 '주문상세'는 일대다 관계로 재설정한다.
관계를 설정할 때는 선택적 관계(0 또는 1)인지 필수적 관계(반드시 1 이상)인지를 나타내는 모달리티(선택성)도 함께 고려한다. 예를 들어, "한 부서에는 0명 이상의 사원이 소속된다"에서 '0명 이상'은 카디널리티(다수)와 모달리티(선택적)를 함께 표현한 것이다. 이러한 관계성과 제약 조건을 명확히 정의하는 것이 논리적 데이터 모델의 핵심이 된다.
정규화는 데이터베이스 설계에서 데이터의 중복을 최소화하고 이상 현상을 방지하기 위해 관계형 데이터베이스의 테이블을 구조화하는 체계적인 과정이다. 이 과정은 주로 ERD의 논리적 설계 단계에서 엔터티와 속성을 분석하여 적용한다. 정규화의 핵심 목표는 데이터의 무결성을 유지하고 저장 공간을 효율적으로 사용하며, 갱신 이상을 예방하는 데 있다.
정규화는 일반적으로 제1정규형부터 제3정규형 또는 보이스-코드 정규형까지 단계적으로 진행된다. 각 정규형은 특정 조건을 만족해야 하며, 이전 정규형을 만족한 상태에서 다음 단계로 진행된다. 주요 정규형의 요구사항은 다음과 같다.
정규형 | 약어 | 주요 요구사항 |
|---|---|---|
제1정규형 | 1NF | 모든 속성의 값이 원자값을 가져야 한다. 즉, 반복 그룹이나 복합 값을 허용하지 않는다. |
제2정규형 | 2NF | 부분 함수적 종속을 제거한다. 모든 비주요 속성이 기본키에 완전 함수적으로 종속되어야 한다. |
제3정규형 | 3NF | 이행적 함수 종속을 제거한다. 비주요 속성이 기본키에만 종속되어야 하며, 다른 비주요 속성에 종속되어서는 안 된다. |
정규화를 적용할 때는 함수적 종속 관계를 분석하는 것이 핵심이다. 예를 들어, 한 테이블에 주문 정보와 고객 주소가 함께 포함되어 있고, 고객 주소가 고객 ID에 종속된다면, 이는 제3정규형을 위반할 수 있다. 이 경우 고객 정보를 별도의 엔터티로 분리하여 이행적 종속을 제거한다.
과도한 정규화는 너무 많은 조인 연산을 유발하여 성능을 저하시킬 수 있다. 따라서 실제 물리적 데이터베이스 설계 단계에서는 쿼리 성능을 위해 선택적으로 반정규화를 수행하기도 한다. 그러나 논리적 설계 단계인 ERD 작성 시에는 이상 현상을 방지하고 명확한 구조를 확립하기 위해 정규화 원칙을 충실히 따르는 것이 바람직하다.
ERD를 표현하는 데에는 여러 가지 시각적 표기법이 존재하며, 각각은 엔터티, 속성, 관계를 표현하는 방식에 차이가 있다. 가장 널리 알려진 표기법으로는 Chen 표기법, IE/Crow's Foot 표기법, 그리고 UML 클래스 다이어그램이 있다.
Chen 표기법은 1976년 피터 첸이 제안한 최초의 ERD 표기법으로, 직사각형으로 엔터티를, 타원형으로 속성을, 마름모꼴로 관계를 표현한다. 관계의 카디널리티는 '1', 'N', 'M'과 같은 문자를 관계선 옆에 표기한다. 이 표기법은 개념적 모델링에 적합하며, 각 요소를 시각적으로 명확히 구분할 수 있는 장점이 있다. 그러나 다이어그램이 복잡해질수록 그림이 커지고 공간을 많이 차지하는 단점이 있다.
IE/Crow's Foot 표기법은 정보 공학(Information Engineering)에서 유래했으며, '까마귀 발(Crow's Foot)' 모양의 기호로 카디널리티를 표현하는 것이 특징이다. 이 표기법은 엔터티를 박스로, 관계를 선으로 표현하며, 선의 끝에 다양한 기호를 추가한다. 예를 들어, 직선은 '1'을, 까마귀 발 세 갈래 모양은 '다수(Many)'를 의미한다. 이 방식은 직관적이고 공간 효율적이어서 실무에서 가장 널리 사용되는 표기법 중 하나이다.
표기법 | 엔터티 표현 | 관계 표현 | 카디널리티 표현 | 주요 사용처 |
|---|---|---|---|---|
Chen 표기법 | 직사각형 | 마름모꼴 | 관계선 옆에 '1', 'N' 등 문자 표기 | 학술, 개념적 모델링 |
IE/Crow's Foot 표기법 | 박스 | 선 | 선 끝의 기호(│, ○, ┤, ├ 등) | 실무 데이터베이스 설계 |
UML 클래스 다이어그램 | 3구획 박스 | 다양한 선(실선, 점선) | 선 끝의 숫자나 기호(1, 0..*, 1..*) | 객체지향 소프트웨어 설계 |
UML 클래스 다이어그램은 소프트웨어 공학의 통합 모델링 언어에서 비롯되었다. 엔터티는 클래스로 표현되며, 이름, 속성, 메서드를 포함하는 3구획 박스를 사용한다. 관계는 연관, 집합, 일반화 등 다양한 형태로 표현되며, 카디널리티는 '1', '0..*', '1..*'와 같은 다중성(Multiplicity) 표기로 나타낸다. 이 표기법은 객체지향 분석 및 설계와 데이터베이스 설계를 통합하는 데 유용하지만, 순수한 데이터 관계 모델링에는 다소 복잡할 수 있다. 표기법 선택은 프로젝트의 성격, 팀의 관습, 사용하는 설계 도구의 지원 여부에 따라 결정된다.
Chen 표기법은 1976년 피터 첸이 제안한 최초의 ERD 표기법으로, 개념적 데이터 모델링을 위한 시각적 언어의 기초를 마련했다. 이 표기법은 엔터티, 속성, 관계라는 세 가지 기본 구성 요소를 직사각형, 타원, 마름모라는 독특한 기호로 명확히 구분하여 표현한다.
표기법의 주요 구성 요소와 규칙은 다음과 같다.
구성 요소 | 기호 | 설명 |
|---|---|---|
직사각형 | 관리 대상이 되는 실체나 개념을 나타낸다. | |
타원 | 엔터티나 관계의 특성이나 상태를 설명한다. 속성은 해당 엔터티나 관계에 선으로 연결된다. | |
마름모 | 두 개 이상의 엔터티 간에 존재하는 연관성을 나타낸다. 관계의 이름은 마름모 안에 기재한다. |
이 표기법에서 카디널리티는 관계선 위에 1, N, M 등의 기호를 표기하여 표현한다. 예를 들어, 한 명의 고객이 여러 개의 주문을 할 수 있다면, 고객 엔터티와 주문 엔터티 사이의 관계 마름모에서 고객 쪽에는 1, 주문 쪽에는 N을 표기한다. 이는 일대다(1:N) 관계를 의미한다. 속성 중에서 기본키를 식별하기 위해 속성 이름에 밑줄을 그어 표시하는 것이 일반적이다.
Chen 표기법은 개념 모델의 본질을 직관적으로 보여주는 데 강점이 있으나, 다이어그램이 복잡해질수록 기호와 선이 많아져 가독성이 떨어질 수 있다는 단점도 있다. 이후 등장한 IE 표기법이나 UML 등은 실용성을 높이기 위해 이 표기법을 단순화하거나 변형한 경우가 많다. 그러나 데이터 모델링의 기본 원리를 학습하고 이해하는 데에는 여전히 유용한 표준으로 남아 있다.
IE 표기법 또는 Crow's Foot 표기법은 1976년 고든 에버렛(Gordon Everest)에 의해 제안되었으며, 이후 정보 공학(Information Engineering) 분야에서 널리 채택되어 현재 가장 보편적으로 사용되는 ERD 표기법 중 하나이다. 이 표기법은 시각적 직관성이 뛰어나고, 엔터티 간의 관계와 카디널리티를 상세히 표현하는 데 강점을 지닌다.
표기법의 핵심은 관계선의 끝 모양을 통해 카디널리티를 나타내는 것이다. "까마귀 발"이라는 이름은 관계선 끝의 세 갈래 모양이 까마귀 발자국을 닮은 데서 유래했다. 주요 기호와 의미는 다음과 같다.
기호 | 명칭 | 의미 |
|---|---|---|
\ | 단일 선 | |
O | 원 | 0 또는 1(Zero or One) |
<\ | 까마귀 발(세 갈래) | |
>O | 원이 붙은 까마귀 발 | 0 또는 다수(Zero or Many) |
이 기호들을 조합하여 다양한 관계를 표현한다. 예를 들어, 한 명의 고객이 여러 개의 주문을 생성할 수 있고, 하나의 주문은 반드시 한 명의 고객에 의해 생성된다고 가정하자. 이 경우 '고객' 엔터티에서 '주문' 엔터티로 향하는 관계선의 끝은 <\| (다수)로, 반대 방향인 '주문' 엔터티에서 '고객' 엔터티로 향하는 관계선의 끝은 \| (정확히 1)로 표시한다. 이를 통해 "일대다(1:N)" 관계를 명확히 보여준다.
이 표기법은 대부분의 현대 ERD 도구(예: ERwin Data Modeler, MySQL Workbench, Lucidchart)의 기본 표기법으로 채택되어 있다. 실무에서는 관계선 위나 옆에 관계의 이름(예: '생성한다', '소속된다')을 기술하며, 선택적 관계(Optional)와 필수적 관계(Mandatory) 역시 기호 조합을 통해 직관적으로 이해할 수 있다[2]. 이러한 명확성 덕분에 데이터베이스 설계자와 개발자, 비즈니스 분석가 간의 원활한 의사소통을 가능하게 한다.
UML 클래스 다이어그램은 객체 지향 프로그래밍의 개념을 기반으로 시스템의 정적인 구조를 모델링하는 데 주로 사용되지만, 데이터 구조를 표현하는 데에도 활용될 수 있다. 특히 애플리케이션의 도메인 모델을 설계할 때 엔터티와 그 관계를 시각화하는 방법으로 ERD의 대안이 될 수 있다.
클래스 다이어그램에서 클래스는 ERD의 엔터티에 해당하며, 클래스 내의 속성은 데이터베이스 테이블의 컬럼을 의미한다. 메서드는 데이터베이스 설계에는 직접 매핑되지 않지만, 해당 도메인의 비즈니스 로직을 이해하는 데 도움을 준다. 클래스 간의 관계는 연관 관계, 집합 관계, 합성 관계, 일반화 관계 등 다양한 형태로 표현되어 ERD의 관계보다 더 풍부한 의미를 전달할 수 있다.
ERD의 카디널리티는 UML의 다중성으로 표현된다. 다음은 주요 관계와 다중성 표기의 예시이다.
UML 관계 유형 | UML 표기 (다중성) | ERD에서의 의미 (예시) |
|---|---|---|
일대일 연관 | 1 ───── 1 | 하나의 고객은 하나의 기본 주소를 가진다. |
일대다 연관 | 1 ───── 0..* | 하나의 학과에는 여러 명의 학생이 속한다. |
다대다 연관 | * ───── * | 한 학생은 여러 강의를 수강하고, 한 강의는 여러 학생이 듣는다. |
UML 클래스 다이어그램을 데이터 모델링에 사용할 때의 장점은 소프트웨어의 객체 모델과 데이터 모델을 통합적으로 고려할 수 있다는 점이다. 그러나 데이터베이스 특화된 개념인 정규화나 외래 키 제약 조건을 명시적으로 표현하기에는 한계가 있다. 따라서 이 방법은 주로 객체-관계 매핑이 중요한 애플리케이션의 초기 분석 및 설계 단계에서 유용하게 적용된다.
ERD 설계는 단순히 도형을 나열하는 것이 아니라, 효율적이고 유지보수 가능한 데이터베이스의 기초를 구축하는 과정이다. 이를 위해 몇 가지 핵심 원칙을 준수하는 것이 중요하다.
첫째, 명확성과 일관성이 필수적이다. 모든 엔터티, 속성, 관계의 이름은 그 의미를 직관적으로 전달할 수 있어야 하며, 프로젝트 전반에 걸쳐 통일된 명명 규칙을 적용해야 한다. 예를 들어, '고객' 엔터티를 'Customer'로 명명했다면 '주문' 엔터티는 'Order'로, '상품'은 'Product'로 일관되게 영어 단수형을 사용하는 식이다. 또한, 동일한 데이터는 전체 다이어그램에서 동일한 속성 이름과 데이터 타입으로 표현되어야 한다.
둘째, 데이터의 중복을 최소화하고 정규화 원칙을 적용하는 것이 좋다. 같은 정보가 여러 엔터티에 반복되어 저장되면 데이터 불일치가 발생할 가능성이 높아지고 저장 공간이 낭비된다. 예를 들어, 주문 정보에 고객의 주소를 직접 포함시키기보다는 고객 엔터티에 주소를 저장하고 주문 엔터티는 고객 ID를 통해 참조하는 방식이 선호된다. 이는 데이터 무결성을 보장하는 데 핵심적이다.
마지막으로, 시스템의 확장성을 미리 고려해야 한다. 비즈니스 요구사항은 시간이 지남에 따라 변화하기 때문에, ERD는 이러한 변화를 수용할 수 있도록 설계되어야 한다. 새로운 속성이나 엔터티를 추가하기 쉬운 구조인지, 관계의 카디널리티가 미래의 데이터 성장을 반영하고 있는지 점검해야 한다. 지나치게 복잡하게 결합된 구조는 차후 변경을 어렵게 만든다.
ERD는 이해 관계자 간의 의사소통 도구로서, 그 자체만으로도 명확하게 설계 의도를 전달할 수 있어야 합니다. 모든 엔터티, 속성, 관계의 이름은 해당 도메인의 비즈니스 용어를 반영하여 직관적이고 모호하지 않게 지어야 합니다. 예를 들어, '날짜'라는 속성보다는 '주문일자'나 '생성일시'처럼 구체적인 이름을 사용하는 것이 좋습니다. 또한, 전체 다이어그램에서 동일한 요소는 일관된 이름과 표기법으로 나타내어야 합니다.
설계의 일관성은 구조적 측면에서도 중요합니다. 유사한 유형의 엔터티는 비슷한 속성 집합을 가지도록 하고, 기본키나 외래키의 명명 규칙을 사전에 정의하여 준수해야 합니다. 관계선의 기호나 표시 방법도 선택한 ERD 표기법에 따라 통일되게 적용합니다. 이러한 일관성은 다이어그램의 가독성을 높일 뿐만 아니라, 이후 물리적 데이터베이스로 변환하는 과정에서 오류를 줄이는 데 기여합니다.
명확성과 일관성을 유지하기 위한 구체적인 방법은 다음과 같습니다.
원칙 | 설명 | 예시 |
|---|---|---|
명확한 명명 | 엔터티와 속성의 이름은 역할과 의미를 명확히 드러낸다. |
|
일관된 표기 | 선택한 표기법(예: Crow's Foot 표기법)을 전체에 걸쳐 동일하게 적용한다. | 모든 관계선의 끝 모양(까마귀발, 원 등)을 통일한다. |
구조적 패턴 통일 | 유사한 엔터티(예: 모든 '사람' 관련 엔터티)는 공통 속성(생성일시, 수정일시 등)을 공유하도록 설계한다. |
|
문서화 | 중요한 설계 결정사항, 약어, 명명 규칙을 별도의 문서나 다이어그램 내 주석으로 기록한다. | "모든 기본키는 '엔터티명+ID' 형식으로 명명한다"는 규칙을 정의한다. |
이러한 원칙을 따르면 ERD는 단순한 그림을 넘어 시스템의 청사진으로서 신뢰성을 얻을 수 있습니다. 모든 참여자가 동일한 이해를 바탕으로 논의하고, 이후의 구현 및 유지보수 작업이 원활하게 진행될 수 있는 기반을 마련합니다.
정규화 과정을 통해 데이터의 중복을 체계적으로 제거하는 것이 핵심이다. 이는 주로 동일한 정보가 여러 곳에 저장되는 것을 방지하여 데이터 무결성을 보호하고 저장 공간을 효율적으로 사용하기 위함이다. 예를 들어, '고객' 정보가 주문 테이블에 반복적으로 포함된다면, 고객의 주소가 변경될 때 모든 관련 레코드를 수정해야 하는 번거로움과 일관성 유지 실패의 위험이 발생한다.
중복을 최소화하기 위한 구체적인 접근법은 다음과 같다.
엔터티 분리: 하나의 엔터티가 두 가지 이상의 독립적인 개념을 포함하고 있다면, 이를 분리하여 별도의 엔터티로 정의한다.
파생 속성 제거: 다른 속성의 값으로부터 계산될 수 있는 파생 속성은 가능한 한 포함하지 않는다[3].
중복 유형 | 문제점 | 해결 방법 |
|---|---|---|
데이터 값 중복 | 갱신 이상[4] 발생, 저장 공간 낭비 | 엔터티 분리 및 정규화 적용 |
엔터티 중복 | 동일한 실세계 객체를 표현하는 엔터티가 여러 개 존재 | 엔터티 통합 및 명확한 경계 정의 |
관계 중복 | 이미 다른 관계로 표현 가능한 불필요한 관계 존재 | 관계의 필요성 재검토 및 제거 |
단, 성능 향상을 위한 목적으로 의도적으로 데이터 중복을 허용하는 반정규화도 이후 단계에서 고려될 수 있다. 그러나 ERD 설계 단계에서는 논리적 구조의 순수성과 무결성을 우선시하여 중복을 최소화하는 방향으로 진행하는 것이 원칙이다.
ERD 설계 시 확장성을 고려하는 것은 시스템의 미래 요구사항 변화에 유연하게 대응할 수 있는 데이터 구조를 만드는 것을 의미한다. 이는 초기 설계 단계에서 데이터 모델의 진화 가능성을 예측하고, 변경에 따른 비용과 복잡도를 최소화하기 위한 접근이다.
확장성을 고려한 설계의 핵심은 변화를 수용할 수 있는 유연한 구조를 만드는 것이다. 예를 들어, 새로운 엔터티나 속성이 추가될 가능성이 높은 경우, 미리 일반화된 구조를 설계하거나 확장 테이블을 별도로 구성하는 방안을 검토한다. 또한 카디널리티 설정 시, 현재는 1:1 관계일지라도 미래에 1:N 또는 M:N 관계로 변경될 수 있는지를 평가하여 관계의 방향성을 유연하게 정의한다. 이는 향후 외래 키와 조인 테이블 추가 없이 구조를 확장할 수 있게 한다.
고려 사항 | 확장성 높은 설계 예시 | 주의점 |
|---|---|---|
엔터티 구조 | 공통 속성을 가진 하위 엔터티들을 하나의 일반화된 상위 엔터티로 통합[5] | 지나친 일반화는 복잡한 조회를 유발할 수 있음 |
속성 추가 | 자주 추가될 가능성이 있는 속성군을 위해 확장 가능한 별도의 '속성' 테이블을 설계 (EAV 패턴)[6] | EAV 패턴은 데이터 무결성 유지와 쿼리 복잡도가 증가하는 단점이 있음 |
관계 변화 | 현재 1:1 관계라도, 미래를 고려하여 1:N 관계로 초기 설계 (예: 사용자-프로필) | 불필요한 복잡성을 초래하지 않도록 실제 비즈니스 변화 가능성에 근거해야 함 |
결국 확장성 있는 ERD는 단순히 미래를 예측하는 것이 아니라, 변경이 발생했을 때 최소한의 영향으로 구조를 조정할 수 있는 탄력성을 확보하는 것이다. 이를 위해 설계자는 비즈니스 도메인의 성장 방향과 기술적 트렌드를 이해하고, 정규화와 성능 사이의 적절한 균형점을 찾아야 한다. 과도한 최적화나 지나치게 추상화된 구조는 오히려 유지보수 비용을 증가시킬 수 있다.
ERD 설계를 지원하는 도구는 다양하며, 각 도구는 시각적 모델링, 자동 생성, 협업, 리버스 엔지니어링 등의 기능을 제공한다. 주요 상용 및 오픈소스 도구들은 데이터베이스 설계의 효율성과 정확성을 높이는 데 기여한다.
도구명 | 주요 특징 | 라이선스 |
|---|---|---|
업계 표준 도구, 논리적/물리적 모델링, 광범위한 데이터베이스 지원, 정교한 리버스 엔지니어링 | 상용 | |
MySQL 전용 공식 도구, 데이터베이스 설계/개발/관리 통합, SQL 개발 및 마이그레이션 도구 포함 | 오픈소스 | |
웹 기반 협업 도구, ERD 외에도 다양한 다이어그램 지원, 실시간 공유 및 편집 | 프리미엄 SaaS | |
draw.io (diagrams.net) | 무료 웹/데스크톱 애플리케이션, 오프라인 작업 가능, 구글 드라이브/깃허브 등과 연동 | 무료 오픈소스 |
도구 선택 시 프로젝트 규모, 예산, 협업 필요성, 목표 DBMS와의 호환성을 고려해야 한다. 상용 도구는 고급 기능과 엔터프라이즈급 지원을 제공하는 반면, 오픈소스나 웹 기반 도구는 접근성과 협업에 강점을 보인다. 많은 도구들은 SQL DDL 스크립트 자동 생성, 기존 데이터베이스로부터의 모델 자동 추출(리버스 엔지니어링), 버전 관리 기능 등을 포함한다.
ERwin Data Modeler는 CA 테크놀로지스에서 개발한 대표적인 데이터 모델링 도구이다. 주로 개념적, 논리적, 물리적 데이터 모델을 설계하고 관리하는 데 사용되며, 데이터베이스 설계의 표준 도구 중 하나로 널리 인정받는다.
이 도구는 엔터티-관계 다이어그램을 시각적으로 생성하고, 다양한 데이터베이스 관리 시스템에 대한 물리적 데이터 모델을 자동으로 생성할 수 있다. 주요 기능으로는 정규화 지원, 리버스 엔지니어링, 포워드 엔지니어링, 모델 비교 및 동기화, 팀 협업을 위한 버전 관리 등이 포함된다. 또한, 광범위한 데이터베이스 플랫폼(예: Oracle, Microsoft SQL Server, MySQL, IBM DB2)에 대한 스크립트 생성을 지원한다.
ERwin Data Modeler의 사용 환경과 라이선스 정책은 다음과 같다.
항목 | 내용 |
|---|---|
주요 특징 | 시각적 모델링, 다중 데이터베이스 지원, 자동화된 스크립트 생성, 모델 버전 관리 |
운영 체제 | 주로 마이크로소프트 윈도우 환경에서 실행된다. |
라이선스 | 상용 소프트웨어로, 기업용 라이선스를 구매해야 한다. |
대안 도구 | MySQL Workbench, Oracle SQL Developer Data Modeler, Lucidchart |
이 도구는 복잡한 기업 환경의 데이터 구조를 설계하고 문서화하는 데 특히 강점을 보인다. 모델을 통해 데이터 표준을 정의하고, 메타데이터를 관리하며, 데이터베이스 스키마의 변경 이력을 추적할 수 있어 대규모 프로젝트에서 유용하게 활용된다[7].
MySQL Workbench는 오라클이 개발한 공식 GUI 도구로, MySQL 데이터베이스를 위한 통합 개발 환경을 제공한다. 이 도구는 SQL 개발, 데이터베이스 관리, 마이그레이션, 그리고 ERD 설계 기능을 하나의 애플리케이션에 통합했다. 특히 내장된 EER Diagram 편집기를 통해 시각적 데이터 모델링을 지원하며, 생성된 모델로부터 실제 데이터베이스 스키마를 생성하거나 기존 데이터베이스로부터 역공학을 수행해 모델을 추출할 수 있다.
주요 ERD 관련 기능으로는 Chen 표기법과 IE/Crow's Foot 표기법을 지원하는 시각적 모델링 캔버스, 엔터티와 관계를 드래그 앤 드롭으로 추가 및 편집, 자동 정렬 및 레이아웃 기능 등이 포함된다. 또한 정규화 과정을 지원하는 다양한 유효성 검사 도구와 표준 SQL DDL 스크립트를 생성하는 기능을 갖추고 있다.
MySQL Workbench의 장점은 MySQL 데이터베이스와의 긴밀한 통합에 있다. 설계된 ERD 모델을 기반으로 데이터베이스를 포워드 엔지니어링하거나, 운영 중인 데이터베이스로부터 모델을 역공학하여 문서화하는 작업이 비교적 간단하다. 또한 변경 사항을 동기화하는 기능을 제공하여 모델과 실제 데이터베이스 구조의 일관성을 유지하는 데 도움을 준다.
기능 | 설명 |
|---|---|
모델링 표기법 | IE/Crow's Foot 표기법을 기본으로 지원 |
포워드 엔지니어링 | EER Diagram에서 SQL CREATE 문 자동 생성 |
역공학 | 기존 MySQL 데이터베이스로부터 ERD 모델 자동 생성 |
동기화 | 모델과 실제 데이터베이스 간의 구조 변경 사항 관리 및 적용 |
물리적 모델링 |
이 도구는 무료로 제공되며, Windows, macOS, 리눅스를 모두 지원한다. MySQL 생태계에 특화되어 있어 MySQL을 주 데이터베이스로 사용하는 프로젝트의 ERD 설계 및 프로토타이핑에 매우 효율적인 도구이다.
Lucidchart와 draw.io는 웹 기반의 다이어그램 작성 도구로, ERD를 포함한 다양한 시각적 다이어그램을 손쉽게 만들 수 있다. 두 도구 모두 별도의 소프트웨어 설치 없이 브라우저에서 작동하며, 실시간 협업 기능을 제공한다는 공통점을 지닌다. 사용자는 드래그 앤 드롭 방식으로 엔터티와 관계를 배치하고, IE/Crow's Foot 표기법이나 UML 클래스 다이어그램 등 여러 표기법을 지원하는 도형 라이브러리를 활용할 수 있다.
구체적인 특징을 비교하면 다음과 같다.
도구 | 주요 특징 | 무료 플랜 |
|---|---|---|
기업용 협업 기능에 강점, Google Workspace, Microsoft Office 등과의 통합 지원 | 제한적(최대 3개의 다이어그램) | |
draw.io (현재 diagrams.net) | 완전한 오픈 소스, 오프라인 데스크톱 앱 제공, 다양한 클라우드 저장소 연동 | 완전 무료, 광고 없음 |
이들 도구는 ERwin Data Modeler나 MySQL Workbench 같은 전문 데이터 모델링 도구에 비해 고급 정규화 자동화나 물리적 스키마 생성 기능은 부족할 수 있다. 그러나 직관적인 인터페이스와 접근성 덕분에 초기 개념 설계, 요구사항 논의, 간단한 시스템 문서화에 널리 사용된다. 특히 팀원들과 링크를 공유하여 동시에 다이어그램을 편집하고 댓글을 달 수 있는 협업 환경은 설계 과정의 효율성을 높여준다.
ERD는 논리적 데이터 모델을 표현하지만, 최종 목표는 실제 데이터베이스 관리 시스템에서 동작하는 물리적 스키마를 생성하는 것이다. 이 변환 과정은 설계된 개념을 구체적인 데이터베이스 객체로 매핑하는 작업을 포함한다.
첫 번째 단계는 엔터티와 속성을 테이블과 열로 변환하는 테이블 매핑이다. 각 엔터티는 일반적으로 하나의 테이블이 되며, 엔터티의 속성은 테이블의 열이 된다. 예를 들어, '고객' 엔터티는 Customer 테이블로, 그 속성인 '고객ID', '이름', '이메일'은 각각 customer_id, name, email 열이 된다. 관계는 외래 키를 통해 구현된다. 일대다 관계에서는 '일'쪽 테이블의 기본 키를 '다'쪽 테이블에 외래 키로 추가한다. 다대다 관계는 연결 테이블을 새로 생성하여 각 엔터티의 기본 키를 외래 키로 참조하는 방식으로 처리한다.
다음으로 키와 제약조건을 명확히 정의한다. 엔터티의 식별자는 테이블의 기본 키가 되며, PRIMARY KEY 제약조건으로 설정된다. 관계의 무결성을 보장하기 위해 외래 키 제약조건을 생성하여 참조 무결성을 유지한다. 또한 NOT NULL, UNIQUE, CHECK 등의 제약조건을 적절한 열에 추가하여 데이터의 정확성과 비즈니스 규칙을 적용한다. 마지막으로 각 속성에 적합한 데이터 타입을 지정한다. 예를 들어, 이름은 VARCHAR(100), 나이는 INTEGER, 가입일은 DATE 또는 DATETIME 타입으로 변환한다. 이 과정에서 데이터베이스의 성능을 고려하여 인덱스를 설계하고, 정규화 수준에 따라 물리적 저장 구조를 결정하기도 한다.
엔터티는 일반적으로 데이터베이스 테이블로 변환된다. 각 엔터티의 속성은 테이블의 컬럼이 되며, 엔터티의 이름은 테이블 이름의 기초가 된다. 예를 들어, '회원' 엔터티는 Member 또는 USER 테이블로 생성될 수 있다.
관계는 테이블 간의 외래 키를 통해 구현된다. 일대다(1:N) 관계의 경우, '다'쪽에 해당하는 테이블에 '일'쪽 테이블의 기본 키를 참조하는 외래 키 컬럼을 추가한다. 다대다(M:N) 관계는 새로운 관계 테이블(또는 조인 테이블)을 생성하여 각각의 기본 키를 복합 외래 키로 포함시키는 방식으로 매핑한다.
ERD 구성 요소 | 물리적 데이터베이스 매핑 결과 |
|---|---|
컬럼(필드) | |
기본 키 제약조건(Primary Key Constraint) | |
관계 (1:N) | 외래 키 제약조건(Foreign Key Constraint) |
관계 (M:N) | 새로운 관계 테이블 및 두 개의 외래 키 |
여러 개의 단일 컬럼으로 분리 |
약한 엔터티는 자신의 기본 키를 가지지 못하고 소유 엔터티의 기본 키에 의존한다. 이는 물리적 테이블에서 소유 테이블의 기본 키를 자신의 기본 키의 일부로 포함시키는 방식으로 구현된다. 모든 매핑 과정은 선택한 ERD 표기법과 특정 DBMS의 규칙 및 제한 사항을 고려하여 진행되어야 한다.
ERD에서 물리적 데이터베이스 스키마로 변환할 때, 키와 제약조건을 명확히 정의하는 것은 데이터 무결성을 보장하는 핵심 단계이다.
가장 먼저 각 엔터티에 대응하는 테이블의 기본 키를 지정한다. 기본 키는 테이블에서 각 행을 고유하게 식별하는 속성 또는 속성의 집합이다. 일반적으로 단일 컬럼(예: user_id, order_no)을 사용하지만, 필요에 따라 복합 키를 정의할 수도 있다. 기본 키는 NOT NULL 제약조건을 가지며 중복 값을 허용하지 않는다. 다음으로, 엔터티 간의 관계를 구현하기 위해 외래 키를 정의한다. 외래 키는 한 테이블의 컬럼이 다른 테이블의 기본 키를 참조하는 관계를 나타낸다. 예를 들어, 주문 테이블에 있는 고객_ID 컬럼은 고객 테이블의 기본 키를 참조하는 외래 키가 된다. 이때 참조 무결성을 유지하기 위해 CASCADE, SET NULL, RESTRICT 등의 참조 동작을 함께 설정한다.
기본 키와 외래 키 외에도 다양한 데이터 무결성 제약조건을 적용한다. 주요 제약조건은 다음과 같다.
제약조건 | 설명 | 예시 |
|---|---|---|
컬럼의 모든 값이 서로 달라야 함 | 사용자 이메일 주소 | |
컬럼이 NULL 값을 가질 수 없음 | 사용자 이름 | |
컬럼 값이 특정 조건을 만족해야 함 | 나이 >= 0 | |
값이 입력되지 않았을 때 적용되는 기본값 | 가입일자 = CURRENT_DATE |
이러한 키와 제약조건의 정의는 관계형 데이터베이스 관리 시스템이 자동으로 데이터의 정확성과 일관성을 검증할 수 있는 틀을 제공한다. 설계 단계에서 충분히 고려되지 않으면 이후에 데이터 중복이나 불일치 문제가 발생할 수 있다[8].
데이터 타입 지정은 논리적 데이터 모델을 물리적 데이터 모델로 변환하는 핵심 단계이다. 이 과정에서는 각 속성이 데이터베이스 관리 시스템에서 실제로 저장될 형태를 결정한다. 적절한 데이터 타입을 선택하는 것은 데이터의 무결성을 보장하고 저장 공간을 효율적으로 사용하며, 쿼리 성능에 직접적인 영향을 미친다.
주요 데이터 타입은 숫자, 문자, 날짜/시간, 대용량 객체(LOB), 불리언 등으로 구분된다. 숫자 타입에는 정수를 저장하는 INT나 BIGINT, 소수를 저장하는 DECIMAL이나 FLOAT가 있다. 문자 타입은 고정 길이의 CHAR와 가변 길이의 VARCHAR가 대표적이며, 최대 길이를 신중히 설정해야 한다. 날짜와 시간은 DATE, TIME, DATETIME, TIMESTAMP 등을 상황에 맞게 선택한다.
선택 시 고려해야 할 요소는 정밀도, 저장 공간, 그리고 DBMS별 차이이다. 예를 들어, 나이와 같은 작은 정수는 TINYINT를, 통화 금액과 같이 정확한 계산이 필요한 소수는 DECIMAL을 사용한다. 긴 설명 텍스트는 VARCHAR(255)보다 TEXT 타입이 더 적합할 수 있다. 또한, 선택한 데이터 타입은 이후 인덱스 생성 및 조인 연산의 효율성과 밀접한 관련이 있다[9].
고려 요소 | 설명 | 예시 |
|---|---|---|
데이터의 본질 | 저장할 정보의 종류와 형식 | 정수, 가변 문자열, 고정밀 소수 |
범위와 크기 | 값의 가능한 최대/최소 범위 또는 길이 |
|
정밀도 | 숫자 데이터의 소수점 이하 자릿수 필요도 |
|
DBMS 특성 | 사용하는 데이터베이스별 타입 이름과 동작 차이 | MySQL의 |
성능 영향 | 저장 공간과 연산 속도에 미치는 영향 |
|
ERD 작성 시 일관된 명명 규칙을 적용하는 것이 중요하다. 엔터티, 속성, 관계의 이름은 해당 비즈니스 도메인에서 통용되는 용어를 사용하며, 복수형 엔터티명과 단수형 속성명을 따르는 등의 규칙을 정하여 전체 모델의 가독성을 높인다.
관계의 방향성과 카디널리티를 정확히 표현해야 한다. 1:1 관계, 1:N 관계, M:N 관계를 명확히 구분하고, 선택적 관계(Optional)와 필수적 관계(Mandatory)를 구별하여 표기한다. 이는 이후 물리적 데이터베이스 설계에서 외래 키와 제약 조건을 정의하는 근거가 된다.
초기 개념적 설계 단계에서도 성능에 대한 고려를 시작하는 것이 좋다. 빈번한 조회 대상이 되는 속성이나, 대량의 데이터가 예상되는 엔터티는 별도로 표시해 둔다. 특히 M:N 관계는 반드시 연결 테이블(Associative Entity)로 변환해야 하며, 상속 관계를 표현할 때는 단일 테이블 통합, 구체화된 테이블, 클래스별 테이블 전략 중 데이터 접근 패턴에 맞는 방법을 선택한다.
주의사항 | 설명 | 고려 포인트 |
|---|---|---|
명명 규칙 | 엔터티, 속성, 관계의 이름을 일관되게 정의 | 비즈니스 용어 사용, 복수형/단수형 규칙 준수 |
관계의 방향성 | 관계의 카디널리티와 선택성을 정확히 표기 | 1:1, 1:N, M:N 구분, Optional/Mandatory 표시 |
성능 고려사항 | 데이터 접근 패턴과 규모를 미리 예측 | 빈번한 조회 속성, 대용량 엔터티 식별, M:N 관계 처리 방식 |
엔터티, 속성, 관계 등 ERD의 모든 구성 요소에 일관된 이름을 부여하는 것은 설계의 명확성과 유지보수성을 높이는 핵심 요소이다. 효과적인 명명 규칙은 시스템의 이해를 돕고, 개발자 간의 소통을 원활하게 하며, 이후의 데이터베이스 변환 과정을 용이하게 한다.
일반적으로 적용되는 규칙은 다음과 같다. 엔터티의 이름은 단수형의 명사를 사용하며, 해당 비즈니스 영역에서 통용되는 용어를 반영한다. 예를 들어, '주문'이라는 개념은 Order 또는 주문으로 명명한다. 속성의 이름은 해당 엔터티 내에서 유일해야 하며, 엔터티 이름을 반복하지 않는 것이 좋다. 주문 엔터티의 날짜 속성은 주문_날짜보다는 간결하게 날짜 또는 order_date로 정의한다. 관계의 이름은 동사나 전치사 구문을 사용하여 두 엔터티 간의 의미를 명확히 전달한다. 예를 들어, 고객과 주문 사이의 관계는 '발생한다' 또는 'places'로 명명할 수 있다.
구체적인 스타일 가이드로는 다음과 같은 사항을 고려한다.
규칙 대상 | 권장 사례 | 비권장 사례 |
|---|---|---|
이름 형식 | 스네이크 케이스( | 혼합된 형식( |
약어 사용 | 업계 표준이나 조직 내 공통 약어만 제한적으로 사용 | 과도하거나 모호한 약어 |
예약어 충돌 | DBMS의 예약어(예: | 예약어와 동일한 이름 사용 |
길이 제한 | 물리적 데이터베이스의 제한을 고려하여 적절한 길이 유지 | 지나치게 긴 이름 |
이러한 규칙은 팀 또는 조직 차원에서 문서화하여 공유하고 준수해야 한다. 일관된 명명은 ERD가 단순한 다이어그램을 넘어 생명력 있는 설계 문서로서의 역할을 수행하도록 보장한다.
관계(Relationship)의 방향성은 엔터티(Entity) 간의 연결이 어떻게 해석되고 구현되는지를 명확히 정의하는 것을 의미한다. 이는 단순히 선으로 연결하는 것을 넘어, 데이터의 흐름과 비즈니스 규칙을 정확히 반영하는 데 핵심적이다.
방향성은 주로 관계의 카디널리티(1:1, 1:N, M:N)와 함께 표현된다. 예를 들어, '한 명의 학생은 여러 개의 수강 신청을 할 수 있다'는 비즈니스 규칙에서, 엔터티(Entity) '학생'과 '수강신청' 사이에는 1:N 관계가 존재하며, 이 관계의 방향은 '학생'에서 '수강신청'으로 흐른다고 해석할 수 있다. 대부분의 ERD 표기법에서는 관계선 끝머리의 기호(까마귀발, 원 등)로 카디널리티를 표시함으로써 암묵적으로 방향성을 나타낸다.
설계 시 방향성을 명확히 하지 않으면 다음과 같은 문제가 발생할 수 있다.
* 모호한 외래 키(Foreign Key) 배치: 1:N 관계에서 '1'쪽 테이블의 기본 키를 'N'쪽 테이블의 외래 키로 포함시켜야 하는데, 방향성이 불분명하면 어느 쪽에 키를 추가해야 할지 혼란이 생긴다.
* 쿼리 복잡도 증가: 데이터를 조회할 때 조인(JOIN) 조건을 잘못 설정할 가능성이 높아진다.
* 비즈니스 로직 오류: 시스템에서 데이터 무결성을 유지하는 규칙을 잘못 구현할 수 있다.
따라서 ERD를 작성할 때는 단순히 엔터티를 연결하는 것을 넘어, "어느 엔터티가 관계의 시작점이며, 어느 엔터티가 종착점인가"를 염두에 두고 관계선을 그려야 한다. 이는 최종적으로 물리적 데이터베이스 스키마를 생성하고 애플리케이션 로직을 개발하는 데 직접적인 지침이 된다.
ERD 설계는 데이터의 논리적 구조를 정의하는 과정이지만, 이 구조는 최종적으로 물리적 데이터베이스의 성능에 직접적인 영향을 미친다. 따라서 설계 단계에서부터 성능 관련 요소를 고려하는 것이 중요하다. 주요 고려사항에는 정규화와 반정규화의 균형, 인덱스 설계를 위한 접근 경로 예측, 그리고 카디널리티에 기반한 관계의 적절한 표현이 포함된다.
과도한 정규화는 데이터 무결성을 높이는 대신, 여러 테이블을 조인(JOIN)해야 하는 쿼리가 빈번해져 성능 저하를 초래할 수 있다. 특히 트랜잭션 처리 성능이 중요한 OLTP(Online Transaction Processing) 시스템에서는, 자주 함께 조회되는 속성들을 하나의 테이블로 통합하는 선택적 반정규화를 고려해야 한다. 반면, 데이터 분석 중심의 OLAP(Online Analytical Processing) 시스템에서는 높은 수준의 정규화가 더 유리할 수 있다.
엔터티 간의 관계를 설정할 때, 예상되는 데이터의 양(카디널리티)과 접근 패턴을 고려해야 한다. 예를 들어, 한쪽 엔터티의 인스턴스 수가 매우 많을 것으로 예상되는 일대다 관계(1:N)에서는, 외래 키가 위치할 테이블에 적절한 인덱스를 생성해야 함을 ERD에 주석으로 표시하는 것이 좋다. 또한, 빈번한 조회 조건으로 사용될 속성은 엔터티 정의 단계에서 식별하여, 이후 인덱스 설계의 근거로 삼아야 한다.
고려 요소 | 성능에 미치는 영향 | ERD 설계 시 고려사항 |
|---|---|---|
정규화 수준 | 높은 정규화는 무결성 향상 but 조인 증가 | 업무 특성(OLTP/OLAP)에 따라 균형 선택 |
관계의 카디널리티 | 데이터 양에 따른 조인 및 검색 속도 차이 | 예상 데이터 볼륨을 바탕으로 관계 표현 |
자주 접근하는 속성 | 인덱스 생성 여부에 따른 검색 속도 | 주요 조회 조건 속성을 식별 및 표기 |
엔터티 분할/통합 | 테이블 수에 따른 쿼리 복잡도 변화 | 함께 조회되는 빈도가 높은 속성은 통합 고려 |
마지막으로, ERD는 초기 설계 도구이므로 모든 성능 문제를 해결할 수는 없다. 그러나 데이터 접근 경로를 시각적으로 보여주므로, 잠재적인 성능 병목 지점(예: 다대다 관계를 해소하기 위한 연결 테이블의 과도한 사용)을 사전에 식별하는 데 유용하다. 설계 검토 시에는 대용량 데이터가 발생할 엔터티와 빈번한 조인이 예상되는 경로에 특별한 주의를 기울여야 한다.
ERD는 데이터베이스 설계의 핵심 도구이지만, 그 과정에는 때때로 설계자의 철학이나 고민이 반영되기도 합니다. 단순히 규칙을 따라 그림을 그리는 것을 넘어, 데이터의 본질과 비즈니스의 맥락을 어떻게 효과적으로 포착할 것인지에 대한 고민이 수반됩니다.
초보 설계자들은 종종 정규화를 과도하게 적용하여 쿼리 성능을 저하시키거나, 반대로 성능을 우선시하다 보면 데이터의 무결성을 해치는 설계를 만들 위험이 있습니다. 또한, 엔터티와 속성의 경계를 명확히 하지 못해 하나의 엔터티가 지나치게 비대해지는 '갓 엔터티(God Entity)'를 만들기도 합니다. 좋은 ERD는 이러한 균형 감각에서 나옵니다.
ERD 작성 도구의 발전은 협업 방식을 크게 바꾸었습니다. 과거에는 ERwin Data Modeler 같은 전문 도구가 주류였지만, 현재는 draw.io나 Lucidchart 같은 웹 기반 협업 도구를 통해 실시간으로 팀원들과 설계를 검토하고 수정하는 것이 일반화되었습니다. 이는 설계 과정 자체를 더욱 투명하고 민주적으로 만들었습니다.
흥미롭게도, 완성된 ERD는 때로 팀 내에서 가장 효과적인 커뮤니케이션 수단이 되기도 합니다. 복잡한 비즈니스 로직을 긴 문서로 설명하는 것보다, 잘 만들어진 ERD 다이어그램 한 장이 시스템의 구조와 규칙을 더 직관적으로 전달할 수 있습니다. 따라서 ERD는 단순한 설계 문서가 아니라, 이해관계자들 사이의 공통 언어 역할을 하기도 합니다.