ERD 데이터베이스 설계도 작성편집자 확인

엔터티는 ERD에서 관리해야 할 정보의 주체가 되는 독립적인 실체를 나타낸다. 데이터베이스에서 저장할 가치가 있는 사람, 장소, 사물, 개념, 사건 등이 이에 해당한다. 예를 들어, '고객', '제품', '주문', '부서'는 모두 엔터티가 될 수 있다. 각 엔터티는 고유한 이름을 가지며, 일반적으로 명사로 지어진다. 데이터베이스 설계 단계에서는 이러한 엔터티들이 이후 테이블로 변환된다.

엔터티는 그 특성에 따라 여러 유형으로 구분된다. 유형 엔터티는 물리적인 형태가 있는 실체를, 개념 엔터티는 물리적 형태는 없지만 관리해야 할 개념을 의미한다. 또한, 엔터티 집합 내의 각각의 개별 실체는 엔터티 인스턴스라고 부른다. 예를 들어, '고객'이라는 엔터티 집합에 속한 "홍길동", "김철수"와 같은 개별 고객 기록이 엔터티 인스턴스에 해당한다.

엔터티를 식별할 때는 다음 조건을 충족해야 한다.

* 두 개 이상의 속성을 가져야 한다.

* 하나 이상의 속성이 유일성을 보장하는 기본키로 지정될 수 있어야 한다.

* 데이터베이스에서 관리할 필요가 있는 정보여야 한다.

* 다른 엔터티와 하나 이상의 관계를 맺을 수 있어야 한다.

엔터티가 가지는 구체적인 특성이나 상태를 나타내는 가장 작은 논리적 단위이다. 속성은 엔터티를 구성하고 설명하는 데 필요한 정보 항목으로, 데이터베이스 테이블의 열(Column)에 해당한다. 예를 들어, '고객'이라는 엔터티는 '고객ID', '이름', '전화번호', '주소' 등의 속성으로 구성된다.

속성은 그 특징에 따라 여러 유형으로 분류된다. 주요 분류 기준은 다음과 같다.

속성은 엔터티의 인스턴스(개별 데이터)를 유일하게 식별하는 데 핵심적인 역할을 한다. 이를 위해 하나 이상의 속성은 기본 키로 지정된다. 기본 키는 엔터티의 각 인스턴스를 고유하게 구분하며, 널 값을 가질 수 없고 중복될 수 없다. '고객ID'나 '학번'이 대표적인 예이다.

관계는 두 개 이상의 엔터티가 서로 어떻게 연관되어 있는지를 정의하는 연결 고리이다. 관계는 엔터티 간의 업무 규칙이나 논리적 연결을 표현하며, ERD에서 마름모 기호나 선으로 표시된다. 예를 들어, '학생' 엔터티와 '강의' 엔터티 사이에는 '수강한다'라는 관계가 존재할 수 있다. 관계는 단순히 연결만을 나타내는 것이 아니라, 그 연결의 성격과 수적 제약을 함께 표현한다.

관계의 중요한 특성 중 하나는 카디널리티이다. 카디널리티는 한 엔터티의 인스턴스가 다른 엔터티의 몇 개의 인스턴스와 연결될 수 있는지를 나타내는 수적 관계이다. 주요 카디널리티에는 다음과 같은 세 가지 유형이 있다.

다대다(M:N) 관계는 데이터베이스에 직접 구현될 수 없으므로, 일반적으로 연결 엔터티(또는 교차 엔터티)를 생성하여 두 개의 일대다(1:N) 관계로 분해한다. 예를 들어, '수강'이라는 연결 엔터티를 도입하여 '학생'과 '강의'의 다대다 관계를 해결한다. 또한, 관계는 선택적이거나 필수적일 수 있으며, 이는 관계선 위에 표시되는 선택성 기호(동그라미 또는 수직선)로 표현되어 특정 관계가 반드시 존재해야 하는지 여부를 나타낸다.

요구사항 분석은 ERD 작성의 첫 번째이자 가장 중요한 단계이다. 이 단계에서는 데이터베이스가 저장하고 관리해야 할 정보와 시스템이 수행해야 할 기능을 명확히 규정한다. 분석 결과는 이후 모든 설계 결정의 근거가 되므로, 철저하고 정확하게 수행되어야 한다.

분석 과정은 일반적으로 다음과 같은 활동을 포함한다.

분석을 통해 도출해야 할 핵심 산출물은 다음과 같다. 첫째, 시스템에서 관리해야 할 주요 정보 객체, 즉 후보 엔터티와 그 속성 목록이다. 예를 들어, '서점 관리 시스템'에서는 '고객', '도서', '주문' 등이 후보 엔터티가 될 수 있다. 둘째, 이러한 엔터티들 간의 업무적 연관성, 즉 관계의 유형과 규칙이다. '한 명의 고객은 여러 주문을 할 수 있다'와 같은 비즈니스 규칙이 여기에 해당한다. 마지막으로 데이터에 대한 제약 조건, 예를 들어 '주문 금액은 0보다 커야 한다'거나 '고객 이메일은 고유해야 한다'는 등의 규칙을 명시해야 한다.

요구사항 분석이 미흡할 경우, 설계 단계에서 중요한 엔터티나 관계가 누락되거나, 실제 비즈니스 규칙을 반영하지 못하는 데이터베이스가 만들어질 수 있다. 이는 개발 후반부에 큰 수정을 필요로 하여 비용과 시간을 낭비하는 결과를 초래한다. 따라서 분석 단계에서 명확하고 모호함이 없는 요구사항 명세서를 작성하는 것이 성공적인 데이터베이스 설계의 기초를奠定한다.

엔터티는 데이터베이스에 저장할 대상이 되는 실체나 개념을 의미한다. 예를 들어, '고객', '주문', '상품'과 같은 명사 형태의 독립적인 존재가 엔터티가 된다. 각 엔터티는 고유한 이름을 가지며, 동일한 종류의 여러 개체(인스턴스)의 집합을 나타낸다. 강한 엔터티는 독립적으로 존재할 수 있고, 약한 엔터티는 다른 엔터티의 존재에 의존한다[1].

속성은 엔터티가 가지는 세부적인 특성이나 데이터 항목을 말한다. '고객' 엔터티의 경우 '고객ID', '이름', '전화번호', '주소' 등이 속성에 해당한다. 속성은 다음과 같이 분류된다.

엔터티와 속성을 정의할 때는 명확한 명명 규칙을 따르고, 각 속성의 데이터 타입과 제약 조건을 고려하는 것이 중요하다. 또한, 하나의 엔터티 내에서 속성들은 해당 엔터티에 종속되어야 하며, 다른 엔터티의 기본키를 제외한 속성을 중복해서 가지지 않도록 설계한다. 이 과정은 이후 정규화의 기초가 된다.

엔터티와 속성을 정의한 후, 다음 단계는 엔터티 간의 관계를 식별하고 정의하는 것이다. 관계는 엔터티들이 서로 어떻게 연관되어 있는지를 표현하며, 이때 관계의 수적 제약을 나타내는 카디널리티를 함께 명시해야 한다.

카디널리티는 일반적으로 세 가지 주요 유형으로 구분된다. 이는 두 엔터티 간에 하나의 인스턴스가 상대방 엔터티의 몇 개의 인스턴스와 연결될 수 있는지를 정의한다.

다대다 관계는 데이터베이스에서 직접 구현될 수 없으므로, 일반적으로 연결 엔터티(교차 엔터티 또는 관계 테이블)를 생성하여 두 개의 일대다 관계로 분해한다. 예를 들어, '주문'과 '제품' 사이의 다대다 관계는 '주문상세'라는 새로운 엔터티를 도입하여 '주문'과 '주문상세'는 일대다, '제품'과 '주문상세'는 일대다 관계로 재설정한다.

관계를 설정할 때는 선택적 관계(0 또는 1)인지 필수적 관계(반드시 1 이상)인지를 나타내는 모달리티(선택성)도 함께 고려한다. 예를 들어, "한 부서에는 0명 이상의 사원이 소속된다"에서 '0명 이상'은 카디널리티(다수)와 모달리티(선택적)를 함께 표현한 것이다. 이러한 관계성과 제약 조건을 명확히 정의하는 것이 논리적 데이터 모델의 핵심이 된다.

정규화는 데이터베이스 설계에서 데이터의 중복을 최소화하고 이상 현상을 방지하기 위해 관계형 데이터베이스의 테이블을 구조화하는 체계적인 과정이다. 이 과정은 주로 ERD의 논리적 설계 단계에서 엔터티와 속성을 분석하여 적용한다. 정규화의 핵심 목표는 데이터의 무결성을 유지하고 저장 공간을 효율적으로 사용하며, 갱신 이상을 예방하는 데 있다.

정규화는 일반적으로 제1정규형부터 제3정규형 또는 보이스-코드 정규형까지 단계적으로 진행된다. 각 정규형은 특정 조건을 만족해야 하며, 이전 정규형을 만족한 상태에서 다음 단계로 진행된다. 주요 정규형의 요구사항은 다음과 같다.

정규화를 적용할 때는 함수적 종속 관계를 분석하는 것이 핵심이다. 예를 들어, 한 테이블에 주문 정보와 고객 주소가 함께 포함되어 있고, 고객 주소가 고객 ID에 종속된다면, 이는 제3정규형을 위반할 수 있다. 이 경우 고객 정보를 별도의 엔터티로 분리하여 이행적 종속을 제거한다.

과도한 정규화는 너무 많은 조인 연산을 유발하여 성능을 저하시킬 수 있다. 따라서 실제 물리적 데이터베이스 설계 단계에서는 쿼리 성능을 위해 선택적으로 반정규화를 수행하기도 한다. 그러나 논리적 설계 단계인 ERD 작성 시에는 이상 현상을 방지하고 명확한 구조를 확립하기 위해 정규화 원칙을 충실히 따르는 것이 바람직하다.

Chen 표기법은 1976년 피터 첸이 제안한 최초의 ERD 표기법으로, 개념적 데이터 모델링을 위한 시각적 언어의 기초를 마련했다. 이 표기법은 엔터티, 속성, 관계라는 세 가지 기본 구성 요소를 직사각형, 타원, 마름모라는 독특한 기호로 명확히 구분하여 표현한다.

표기법의 주요 구성 요소와 규칙은 다음과 같다.

이 표기법에서 카디널리티는 관계선 위에 1, N, M 등의 기호를 표기하여 표현한다. 예를 들어, 한 명의 고객이 여러 개의 주문을 할 수 있다면, 고객 엔터티와 주문 엔터티 사이의 관계 마름모에서 고객 쪽에는 1, 주문 쪽에는 N을 표기한다. 이는 일대다(1:N) 관계를 의미한다. 속성 중에서 기본키를 식별하기 위해 속성 이름에 밑줄을 그어 표시하는 것이 일반적이다.

Chen 표기법은 개념 모델의 본질을 직관적으로 보여주는 데 강점이 있으나, 다이어그램이 복잡해질수록 기호와 선이 많아져 가독성이 떨어질 수 있다는 단점도 있다. 이후 등장한 IE 표기법이나 UML 등은 실용성을 높이기 위해 이 표기법을 단순화하거나 변형한 경우가 많다. 그러나 데이터 모델링의 기본 원리를 학습하고 이해하는 데에는 여전히 유용한 표준으로 남아 있다.

IE 표기법 또는 Crow's Foot 표기법은 1976년 고든 에버렛(Gordon Everest)에 의해 제안되었으며, 이후 정보 공학(Information Engineering) 분야에서 널리 채택되어 현재 가장 보편적으로 사용되는 ERD 표기법 중 하나이다. 이 표기법은 시각적 직관성이 뛰어나고, 엔터티 간의 관계와 카디널리티를 상세히 표현하는 데 강점을 지닌다.

표기법의 핵심은 관계선의 끝 모양을 통해 카디널리티를 나타내는 것이다. "까마귀 발"이라는 이름은 관계선 끝의 세 갈래 모양이 까마귀 발자국을 닮은 데서 유래했다. 주요 기호와 의미는 다음과 같다.

이 기호들을 조합하여 다양한 관계를 표현한다. 예를 들어, 한 명의 고객이 여러 개의 주문을 생성할 수 있고, 하나의 주문은 반드시 한 명의 고객에 의해 생성된다고 가정하자. 이 경우 '고객' 엔터티에서 '주문' 엔터티로 향하는 관계선의 끝은 <\| (다수)로, 반대 방향인 '주문' 엔터티에서 '고객' 엔터티로 향하는 관계선의 끝은 \| (정확히 1)로 표시한다. 이를 통해 "일대다(1:N)" 관계를 명확히 보여준다.

이 표기법은 대부분의 현대 ERD 도구(예: ERwin Data Modeler, MySQL Workbench, Lucidchart)의 기본 표기법으로 채택되어 있다. 실무에서는 관계선 위나 옆에 관계의 이름(예: '생성한다', '소속된다')을 기술하며, 선택적 관계(Optional)와 필수적 관계(Mandatory) 역시 기호 조합을 통해 직관적으로 이해할 수 있다[2]. 이러한 명확성 덕분에 데이터베이스 설계자와 개발자, 비즈니스 분석가 간의 원활한 의사소통을 가능하게 한다.

UML 클래스 다이어그램은 객체 지향 프로그래밍의 개념을 기반으로 시스템의 정적인 구조를 모델링하는 데 주로 사용되지만, 데이터 구조를 표현하는 데에도 활용될 수 있다. 특히 애플리케이션의 도메인 모델을 설계할 때 엔터티와 그 관계를 시각화하는 방법으로 ERD의 대안이 될 수 있다.

클래스 다이어그램에서 클래스는 ERD의 엔터티에 해당하며, 클래스 내의 속성은 데이터베이스 테이블의 컬럼을 의미한다. 메서드는 데이터베이스 설계에는 직접 매핑되지 않지만, 해당 도메인의 비즈니스 로직을 이해하는 데 도움을 준다. 클래스 간의 관계는 연관 관계, 집합 관계, 합성 관계, 일반화 관계 등 다양한 형태로 표현되어 ERD의 관계보다 더 풍부한 의미를 전달할 수 있다.

ERD의 카디널리티는 UML의 다중성으로 표현된다. 다음은 주요 관계와 다중성 표기의 예시이다.

UML 클래스 다이어그램을 데이터 모델링에 사용할 때의 장점은 소프트웨어의 객체 모델과 데이터 모델을 통합적으로 고려할 수 있다는 점이다. 그러나 데이터베이스 특화된 개념인 정규화나 외래 키 제약 조건을 명시적으로 표현하기에는 한계가 있다. 따라서 이 방법은 주로 객체-관계 매핑이 중요한 애플리케이션의 초기 분석 및 설계 단계에서 유용하게 적용된다.

ERD는 이해 관계자 간의 의사소통 도구로서, 그 자체만으로도 명확하게 설계 의도를 전달할 수 있어야 합니다. 모든 엔터티, 속성, 관계의 이름은 해당 도메인의 비즈니스 용어를 반영하여 직관적이고 모호하지 않게 지어야 합니다. 예를 들어, '날짜'라는 속성보다는 '주문일자'나 '생성일시'처럼 구체적인 이름을 사용하는 것이 좋습니다. 또한, 전체 다이어그램에서 동일한 요소는 일관된 이름과 표기법으로 나타내어야 합니다.

설계의 일관성은 구조적 측면에서도 중요합니다. 유사한 유형의 엔터티는 비슷한 속성 집합을 가지도록 하고, 기본키나 외래키의 명명 규칙을 사전에 정의하여 준수해야 합니다. 관계선의 기호나 표시 방법도 선택한 ERD 표기법에 따라 통일되게 적용합니다. 이러한 일관성은 다이어그램의 가독성을 높일 뿐만 아니라, 이후 물리적 데이터베이스로 변환하는 과정에서 오류를 줄이는 데 기여합니다.

명확성과 일관성을 유지하기 위한 구체적인 방법은 다음과 같습니다.

이러한 원칙을 따르면 ERD는 단순한 그림을 넘어 시스템의 청사진으로서 신뢰성을 얻을 수 있습니다. 모든 참여자가 동일한 이해를 바탕으로 논의하고, 이후의 구현 및 유지보수 작업이 원활하게 진행될 수 있는 기반을 마련합니다.

정규화 과정을 통해 데이터의 중복을 체계적으로 제거하는 것이 핵심이다. 이는 주로 동일한 정보가 여러 곳에 저장되는 것을 방지하여 데이터 무결성을 보호하고 저장 공간을 효율적으로 사용하기 위함이다. 예를 들어, '고객' 정보가 주문 테이블에 반복적으로 포함된다면, 고객의 주소가 변경될 때 모든 관련 레코드를 수정해야 하는 번거로움과 일관성 유지 실패의 위험이 발생한다.

중복을 최소화하기 위한 구체적인 접근법은 다음과 같다.

• 엔터티 분리: 하나의 엔터티가 두 가지 이상의 독립적인 개념을 포함하고 있다면, 이를 분리하여 별도의 엔터티로 정의한다.

• 관계 활용: 분리된 엔터티 간의 논리적 연결은 관계를 통해 표현하며, 외래 키를 사용해 참조한다.

• 파생 속성 제거: 다른 속성의 값으로부터 계산될 수 있는 파생 속성은 가능한 한 포함하지 않는다[3].

단, 성능 향상을 위한 목적으로 의도적으로 데이터 중복을 허용하는 반정규화도 이후 단계에서 고려될 수 있다. 그러나 ERD 설계 단계에서는 논리적 구조의 순수성과 무결성을 우선시하여 중복을 최소화하는 방향으로 진행하는 것이 원칙이다.

ERD 설계 시 확장성을 고려하는 것은 시스템의 미래 요구사항 변화에 유연하게 대응할 수 있는 데이터 구조를 만드는 것을 의미한다. 이는 초기 설계 단계에서 데이터 모델의 진화 가능성을 예측하고, 변경에 따른 비용과 복잡도를 최소화하기 위한 접근이다.

확장성을 고려한 설계의 핵심은 변화를 수용할 수 있는 유연한 구조를 만드는 것이다. 예를 들어, 새로운 엔터티나 속성이 추가될 가능성이 높은 경우, 미리 일반화된 구조를 설계하거나 확장 테이블을 별도로 구성하는 방안을 검토한다. 또한 카디널리티 설정 시, 현재는 1:1 관계일지라도 미래에 1:N 또는 M:N 관계로 변경될 수 있는지를 평가하여 관계의 방향성을 유연하게 정의한다. 이는 향후 외래 키와 조인 테이블 추가 없이 구조를 확장할 수 있게 한다.

결국 확장성 있는 ERD는 단순히 미래를 예측하는 것이 아니라, 변경이 발생했을 때 최소한의 영향으로 구조를 조정할 수 있는 탄력성을 확보하는 것이다. 이를 위해 설계자는 비즈니스 도메인의 성장 방향과 기술적 트렌드를 이해하고, 정규화와 성능 사이의 적절한 균형점을 찾아야 한다. 과도한 최적화나 지나치게 추상화된 구조는 오히려 유지보수 비용을 증가시킬 수 있다.

ERwin Data Modeler는 CA 테크놀로지스에서 개발한 대표적인 데이터 모델링 도구이다. 주로 개념적, 논리적, 물리적 데이터 모델을 설계하고 관리하는 데 사용되며, 데이터베이스 설계의 표준 도구 중 하나로 널리 인정받는다.

이 도구는 엔터티-관계 다이어그램을 시각적으로 생성하고, 다양한 데이터베이스 관리 시스템에 대한 물리적 데이터 모델을 자동으로 생성할 수 있다. 주요 기능으로는 정규화 지원, 리버스 엔지니어링, 포워드 엔지니어링, 모델 비교 및 동기화, 팀 협업을 위한 버전 관리 등이 포함된다. 또한, 광범위한 데이터베이스 플랫폼(예: Oracle, Microsoft SQL Server, MySQL, IBM DB2)에 대한 스크립트 생성을 지원한다.

ERwin Data Modeler의 사용 환경과 라이선스 정책은 다음과 같다.

이 도구는 복잡한 기업 환경의 데이터 구조를 설계하고 문서화하는 데 특히 강점을 보인다. 모델을 통해 데이터 표준을 정의하고, 메타데이터를 관리하며, 데이터베이스 스키마의 변경 이력을 추적할 수 있어 대규모 프로젝트에서 유용하게 활용된다[7].

MySQL Workbench는 오라클이 개발한 공식 GUI 도구로, MySQL 데이터베이스를 위한 통합 개발 환경을 제공한다. 이 도구는 SQL 개발, 데이터베이스 관리, 마이그레이션, 그리고 ERD 설계 기능을 하나의 애플리케이션에 통합했다. 특히 내장된 EER Diagram 편집기를 통해 시각적 데이터 모델링을 지원하며, 생성된 모델로부터 실제 데이터베이스 스키마를 생성하거나 기존 데이터베이스로부터 역공학을 수행해 모델을 추출할 수 있다.

주요 ERD 관련 기능으로는 Chen 표기법과 IE/Crow's Foot 표기법을 지원하는 시각적 모델링 캔버스, 엔터티와 관계를 드래그 앤 드롭으로 추가 및 편집, 자동 정렬 및 레이아웃 기능 등이 포함된다. 또한 정규화 과정을 지원하는 다양한 유효성 검사 도구와 표준 SQL DDL 스크립트를 생성하는 기능을 갖추고 있다.

MySQL Workbench의 장점은 MySQL 데이터베이스와의 긴밀한 통합에 있다. 설계된 ERD 모델을 기반으로 데이터베이스를 포워드 엔지니어링하거나, 운영 중인 데이터베이스로부터 모델을 역공학하여 문서화하는 작업이 비교적 간단하다. 또한 변경 사항을 동기화하는 기능을 제공하여 모델과 실제 데이터베이스 구조의 일관성을 유지하는 데 도움을 준다.

이 도구는 무료로 제공되며, Windows, macOS, 리눅스를 모두 지원한다. MySQL 생태계에 특화되어 있어 MySQL을 주 데이터베이스로 사용하는 프로젝트의 ERD 설계 및 프로토타이핑에 매우 효율적인 도구이다.

Lucidchart와 draw.io는 웹 기반의 다이어그램 작성 도구로, ERD를 포함한 다양한 시각적 다이어그램을 손쉽게 만들 수 있다. 두 도구 모두 별도의 소프트웨어 설치 없이 브라우저에서 작동하며, 실시간 협업 기능을 제공한다는 공통점을 지닌다. 사용자는 드래그 앤 드롭 방식으로 엔터티와 관계를 배치하고, IE/Crow's Foot 표기법이나 UML 클래스 다이어그램 등 여러 표기법을 지원하는 도형 라이브러리를 활용할 수 있다.

구체적인 특징을 비교하면 다음과 같다.

이들 도구는 ERwin Data Modeler나 MySQL Workbench 같은 전문 데이터 모델링 도구에 비해 고급 정규화 자동화나 물리적 스키마 생성 기능은 부족할 수 있다. 그러나 직관적인 인터페이스와 접근성 덕분에 초기 개념 설계, 요구사항 논의, 간단한 시스템 문서화에 널리 사용된다. 특히 팀원들과 링크를 공유하여 동시에 다이어그램을 편집하고 댓글을 달 수 있는 협업 환경은 설계 과정의 효율성을 높여준다.

엔터티는 일반적으로 데이터베이스 테이블로 변환된다. 각 엔터티의 속성은 테이블의 컬럼이 되며, 엔터티의 이름은 테이블 이름의 기초가 된다. 예를 들어, '회원' 엔터티는 Member 또는 USER 테이블로 생성될 수 있다.

관계는 테이블 간의 외래 키를 통해 구현된다. 일대다(1:N) 관계의 경우, '다'쪽에 해당하는 테이블에 '일'쪽 테이블의 기본 키를 참조하는 외래 키 컬럼을 추가한다. 다대다(M:N) 관계는 새로운 관계 테이블(또는 조인 테이블)을 생성하여 각각의 기본 키를 복합 외래 키로 포함시키는 방식으로 매핑한다.

약한 엔터티는 자신의 기본 키를 가지지 못하고 소유 엔터티의 기본 키에 의존한다. 이는 물리적 테이블에서 소유 테이블의 기본 키를 자신의 기본 키의 일부로 포함시키는 방식으로 구현된다. 모든 매핑 과정은 선택한 ERD 표기법과 특정 DBMS의 규칙 및 제한 사항을 고려하여 진행되어야 한다.

ERD에서 물리적 데이터베이스 스키마로 변환할 때, 키와 제약조건을 명확히 정의하는 것은 데이터 무결성을 보장하는 핵심 단계이다.

가장 먼저 각 엔터티에 대응하는 테이블의 기본 키를 지정한다. 기본 키는 테이블에서 각 행을 고유하게 식별하는 속성 또는 속성의 집합이다. 일반적으로 단일 컬럼(예: user_id, order_no)을 사용하지만, 필요에 따라 복합 키를 정의할 수도 있다. 기본 키는 NOT NULL 제약조건을 가지며 중복 값을 허용하지 않는다. 다음으로, 엔터티 간의 관계를 구현하기 위해 외래 키를 정의한다. 외래 키는 한 테이블의 컬럼이 다른 테이블의 기본 키를 참조하는 관계를 나타낸다. 예를 들어, 주문 테이블에 있는 고객_ID 컬럼은 고객 테이블의 기본 키를 참조하는 외래 키가 된다. 이때 참조 무결성을 유지하기 위해 CASCADE, SET NULL, RESTRICT 등의 참조 동작을 함께 설정한다.

기본 키와 외래 키 외에도 다양한 데이터 무결성 제약조건을 적용한다. 주요 제약조건은 다음과 같다.

이러한 키와 제약조건의 정의는 관계형 데이터베이스 관리 시스템이 자동으로 데이터의 정확성과 일관성을 검증할 수 있는 틀을 제공한다. 설계 단계에서 충분히 고려되지 않으면 이후에 데이터 중복이나 불일치 문제가 발생할 수 있다[8].

데이터 타입 지정은 논리적 데이터 모델을 물리적 데이터 모델로 변환하는 핵심 단계이다. 이 과정에서는 각 속성이 데이터베이스 관리 시스템에서 실제로 저장될 형태를 결정한다. 적절한 데이터 타입을 선택하는 것은 데이터의 무결성을 보장하고 저장 공간을 효율적으로 사용하며, 쿼리 성능에 직접적인 영향을 미친다.

주요 데이터 타입은 숫자, 문자, 날짜/시간, 대용량 객체(LOB), 불리언 등으로 구분된다. 숫자 타입에는 정수를 저장하는 INT나 BIGINT, 소수를 저장하는 DECIMAL이나 FLOAT가 있다. 문자 타입은 고정 길이의 CHAR와 가변 길이의 VARCHAR가 대표적이며, 최대 길이를 신중히 설정해야 한다. 날짜와 시간은 DATE, TIME, DATETIME, TIMESTAMP 등을 상황에 맞게 선택한다.

선택 시 고려해야 할 요소는 정밀도, 저장 공간, 그리고 DBMS별 차이이다. 예를 들어, 나이와 같은 작은 정수는 TINYINT를, 통화 금액과 같이 정확한 계산이 필요한 소수는 DECIMAL을 사용한다. 긴 설명 텍스트는 VARCHAR(255)보다 TEXT 타입이 더 적합할 수 있다. 또한, 선택한 데이터 타입은 이후 인덱스 생성 및 조인 연산의 효율성과 밀접한 관련이 있다[9].

엔터티, 속성, 관계 등 ERD의 모든 구성 요소에 일관된 이름을 부여하는 것은 설계의 명확성과 유지보수성을 높이는 핵심 요소이다. 효과적인 명명 규칙은 시스템의 이해를 돕고, 개발자 간의 소통을 원활하게 하며, 이후의 데이터베이스 변환 과정을 용이하게 한다.

일반적으로 적용되는 규칙은 다음과 같다. 엔터티의 이름은 단수형의 명사를 사용하며, 해당 비즈니스 영역에서 통용되는 용어를 반영한다. 예를 들어, '주문'이라는 개념은 Order 또는 주문으로 명명한다. 속성의 이름은 해당 엔터티 내에서 유일해야 하며, 엔터티 이름을 반복하지 않는 것이 좋다. 주문 엔터티의 날짜 속성은 주문_날짜보다는 간결하게 날짜 또는 order_date로 정의한다. 관계의 이름은 동사나 전치사 구문을 사용하여 두 엔터티 간의 의미를 명확히 전달한다. 예를 들어, 고객과 주문 사이의 관계는 '발생한다' 또는 'places'로 명명할 수 있다.

구체적인 스타일 가이드로는 다음과 같은 사항을 고려한다.

이러한 규칙은 팀 또는 조직 차원에서 문서화하여 공유하고 준수해야 한다. 일관된 명명은 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는 초기 설계 도구이므로 모든 성능 문제를 해결할 수는 없다. 그러나 데이터 접근 경로를 시각적으로 보여주므로, 잠재적인 성능 병목 지점(예: 다대다 관계를 해소하기 위한 연결 테이블의 과도한 사용)을 사전에 식별하는 데 유용하다. 설계 검토 시에는 대용량 데이터가 발생할 엔터티와 빈번한 조인이 예상되는 경로에 특별한 주의를 기울여야 한다.