2 데이터 모델링 기본 개념

 

2.1 관계형 데이터 모델링

관계형 모델이란? 함수 종속(Functional Dependency)에 의해 정규화(Nomalization)된 모델

관계형모델에서 기초가 되는 개념이 릴레이션

 

릴레이션 (테이블)은 가로 세로로 이루어 진 표 형태이고 머리부분인 어트리뷰트(컬럼)과 몸통부분인 튜플(로우)로 구성됩니다. 튜플의 집합이 릴레이션입니다.

어트리뷰트 중 튜플을 유일하게 식별할 수 있는 어트리뷰트를 식별자(PK)라고 합니다.

어트리뷰트의 수를 차수(Degree)라고 하며 튜플의 수를 카티널리티(Cardinality)라고 합니다.

 

특징

1.릴레이션에서 각 튜플을 유일해야 한다는 것

2.어트리뷰트는 유일한 값이 사용돼야 하며 다중 값이나 복합 값이 존재해서는 안됩니다. (한 로우에 여러 값이 들어가 있는 경우)

3. 전체 모델에서 릴레이션의 이름은 유일해야 하며 릴레이션 내에서 어트리뷰트 이름도 유일해야 합니다.

4.한 릴레이션에는 하나의 데이터 주체만이 포함될 수 있습니다. 모든 릴레이션은 함수 종속 규칙을 따라야 하고 정규화 되어야 합니다.

위와 같은 특징을 지녀야 관계형 모델이라 할 수 있고, 관계형 데이터베이스에서 운영되는 모델이라고 모두 관계형 모델인 것은 아닙니다.

 

관계형 이론에서 용어의 혼동이 생길 수 있는 것이 엔터티 타입과 엔터티입니다. 엔터티 타입은 엔터티들의 집합을 의미하며 엔터티 타입에 속한 특정 튜플을 엔터티라고 합니다. 엔터티 타입은 동일한 어트리뷰트를 가진 엔터티의 집합입니다. 헤드가 엔터티 타입에 해당되고 실제데이터인 바디가 엔터티입니다.

 

2.2 무결성(Intergrity)

무결성은 데이터 값이 정확한 상태를 의미합니다. 정합성은 데이터가 서로 모순이 없이 일관되게 일치해야 한다는 의미이고, 무결성은 데이터가 정확하고 완전해야 한다는 의미입니다.

예를 들어 중복데이터가 다 틀린 값으로 일치하면 정합성은 만족하지만 무결성은 만족하지 못하게 됩니다.

무결성을 지키는 것이 데이터 모델링의 최고의 목표입니다. 사용되는 데이터가 유효하고 정확할 수 있도록 노력해야 합니다.

무결성은 다음과 같은 종류가 있습니다.

- 엔터티 무결성(Entity Intergrity)

엔터티에 존재하는 모든 인스턴스는 고유해야 하며 NULL값을 가지면 안됩니다. 엔터티에는 동일한 주 식별자가 존재할 수 없으며 주 식별자 속성은 모르는 값인 null값을 허용할 수 없다는 뜻입니다.

(첫번째 두번째 고객번호의 값이 동일하고 세번째 고객번호의 값이 Null)

앤터티 무결성은 식별자(PK)에 의해서 지켜질 수 있습니다.

- 참조 무결성(Referential Intergrity)

엔터티의 외래 식별자 속성은 참조되는 엔터티의 주 식별자 값과 일치하거나 NULL값이어야 합니다. 즉, 외래 식별자 속성 값이 상위 엔터티의 인스턴스에 반드시 존재하거나 NULL 값이어야 합니다.

(주문 릴레이션은 고객 릴레이션을 참조하므로 주문 릴레이션의 고객번호 속성은 외래 식별자이고 주문 릴레이션의 고객번호 속성 값은 고객 릴레이션의 주 식별자인 고객번호 속성에 존재해야 합니다)

관계선을 표현할 때는 참조 무결성을 기준으로 해야 합니다. 데이터모델에서 관계를 정의할 때 참조 무결성이 존재하지 않으면 관계를 정의하지 않아야 합니다.

참조 무결성은 FK(Foreign Key)제약에 의해 지켜집니다.

- 도메인 무결성(Domain Intergrity)

속성 값과 관련된 제약입니다. 엔터티의 특정 속성 값을 같은 데이터 타입과 길이, 같은 NULL 여부, 같은 기본 값, 같은 허용 값 등 동일한 범주의 값만이 존재해야 합니다. 도메인 무결성은 기본 값이나 NULLABLE,체크 조건 등으로 지켜질 수 있습니다.

예를들어 고객이름이라는 속성에 ‘123’과 같은 값이 들어가서는 안됩니다. 전화번호에 ‘서울시’라는 값이 들어가서는 안됩니다. 같은 속성에 사용되는 값들은 같은 성격의 값이 사용돼야 합니다.

- 업무 무결성(Business Intergrity)

 기업에서 업무를 수행하는 방법이나 데이터를 처리하는 규칙을 의미합니다. 예를들어 '주문금액이 3만원 이상이면 배송비가 무료이다, 초회 보험료를 입금하지 않은 보험 제약은 효력이 없다' 등이 업무 무결성입니다. 업무 무결성은 범위가 넓어 주로 프로그램에서 체크합니다. 업무 무결성을 물리적으로 강제하는 대표적인 방법에는 트리거가 존재합니다.

참조 무결성과 업무 무결성을 지키기 위한 다양한 규칙이 존재합니다. 이런 규칙은 데이터베이스에서 옵션을 제공하기도 합니다. 하위(자식) 엔터티에 데이터가 입력될 때 발생하는 입력 규칙이나 상위(부모) 엔터티의 데이터가 삭제될 때 발생하는 삭제 규칙, 상위(부모) 엔터티 데이터가 업데이트 될 때 발생하는 수정규칙이 있습니다.

임력규칙

l  Dependent입력규칙 : 상위(부모)엔터티에 해당하는 주 식별자 값이 존재할 때만 하위(자식)엔터티의 외래 식별자에 입력가능

l  Automatic 입력규칙 : 상위(부모)엔터티에 해당하는 주 식별자 값이 없을 때 상위(부모)엔터티에 주 식별자를 생성하고 나서 하위(자식)엔터티의 외래 식별자에 입력

l  Default 입력규칙 : 상위(부모)엔터티에 해당하는 주 식별자 값이 없을 때 하위(자식)엔터티의 외래 식별자에 기본 값으로 입력,외래 식별자에 기본 값이 설정돼 있어야 함

l  Nullfy 입력규칙 : 상위(부모)엔터티에 해당하는 주 식별자 값이 없을 때 하위(자식)엔터티의 외래 식별자에 (Null)값으로 입력, 외래 식별자는 Null허용으로 설정해야 함

삭제규칙

l  Restrict 삭제규칙: 상위(부모)엔터티의 주 식별자를 삭제할 때, 같은 값이 하위(자식)엔터티의 외래 식별자에 없을 때만 상위(부모) 엔터티의 주 식별자 삭제를 허용

l  Cascade 삭제규칙: 상위(부모)엔터티의 주 식별자를 삭제할 때, 같은 값이 하위(자식) 엔터티의 외래 식별자에 존재하면 해당 값을 모두 삭제하고 나서 상위(부모)엔터티의 주 식별자 삭제

l  Default 삭제규칙: 상위(부모)엔터티의 주 식별자를 삭제할 때, 같은 값이 하위(자식)엔터티의 외래 식별자에 존재하면 해당 값을 모두 기본값으로 수정하고 나서 상위(부모)엔터티의 주 식별자 삭제

l  Nullify 삭제규칙: 상위(부모)엔터티의 주 식별자를 삭제할 때, 같은 값이 하위(자식)엔터티의 외래 식별자에 존재하면 해당 값을 모두 Null값으로 수정하고 나서 상위(부모)엔터티의 주 식별자 삭제

수정규칙

l  Restrict 수정규칙: 상위(부모)엔터티의 주 식별자를 업데이트할 때, 같은 값이 하위(자식)엔터티의 외래 식별자에 없을 때만 상위(부모)엔터티의 주 식별자를 수정

l  Cascade 수정규칙: 상위(부모)엔터티의 주 식별자를 업데이트할 때, 같은 값이 하위(자식)엔터티의 외래 식별자에 존재하면 해당 값을 모두 업데이트 한 후에 상위(부모)엔터티의 주 식별자를 수정

데이터 무결성을 논리적으로 지켜야한다는 것은 일종의 약속이나 다름없기 때문에 논리적인 약속보다 물리적인 제약을 사용하는 것이 바람직합니다.

또한 데이터 무결성을 어플리케이션에서 로직에 의해 구현할 때가 많은데 DBMS차원에서 강제하는 것이 바람직합니다. 물리적인 제약 사용 정도에 비례해 데이터 무결성은 높아질 것입니다.

대부분의 모델링 프로젝트에서 엔터티 무결성이나 참조 무결성을 설계하는 태스크는 별도로 존재하지만 속성 값의 무결성을 높일 수 있는 제약을 설계하는 별도의 태스크는 없습니다. 개별적인 속성까지 상세하게 분석할수록 모델의 완성도는 높아집니다. 속성 단위의 무결성을 설계하는 태스크를 두는 것이 바람직합니다.

 

2.3데이터베이스 라이프 사이클

이번 장에서는 데이터베이스를 구축하기 전까지의 일반적인 단계를 간단하게 설명합니다.

요구사항 분석단계는 데이터베이스에서 관리해야 하는 데이터를 도출하고 분석하는 단계입니다. 요구사항은 업무를 수행하는 데 필요한 데이터에 대한 요구일 수도, 데이터 구조에 대한 요구일수도, 업무를 빨리 처리할 수 있도록 하는 성능에 대한 요구일 수 있습니다. 이러한 요구는 사용자의 의견을 최우선으로 따릅니다. 주로 현업과의 인터뷰를 통해 도출합니다. 요구사항을 잘 도출해야 모델링이 실패하지 않으므로 중요한 단계입니다.

개념 모델링 단계에서는 개념모델을 구축합니다. 요구 사항을 분석하고 나서 도축되는 데이터측면의 결과물입니다. 일반적으로는 요구사항 분석과 별도의 단계로 취급하는데 실무에서는 독립된 단계로 보기 어렵습니다. 즉 앞의 단계를 완전히 끝내고 다음 단계로 넘어가기보다는 부분적으로 끝낸다고 보는 것이 현실적입니다. 개념모델은 요구사항을 개념적으로 반영한 모델입니다. 개념모델은 ER 다이어그램이나 UML다이어그램을 사용해서 표현할 수 있지만 주로 ERD를 사용합니다. 이 단계에서는 핵심 데이터를 대상으로 모델링을 수행해야 하며 통합된 모델이 도출돼야 합니다. 모델러 한 사람이 모델링을 수행하더라도 데이터가 통합된 모습이 아닐 수 있는데 보통 여러 명의 모델러가 모델링을 수행하므로 유사한 데이터를 통합하는 문제는 더욱 주의를 기울여야 합니다.

논리 모델링 단계는 핵심데이터를 포함한 모든 데이터를 대상으로 모텔링을 수행하는 단계입니다. 이 단계에서 가장 중요한 태스크는 정규화입니다. 이 단계에서는 더 분해할 수 없는 엔터티의 모습이 나타나게 됩니다. 물론 이 엔터티가 물리 설계단계에서 목적에 의해 하나의 테이블로 합쳐지거나 두 개 이상의 테이블로 분리될 수 있습니다. 이렇게 더 분해되지 않도록 최대한 분해된 모델을 정규형이라고 하고 정규화된 모델을 논리 모델이라고 합니다. 엔터티를 정규화하면 데이터 무결성은 높아집니다.

물리 설계 단계에서는 논리 모델을 물릴 모델로 매핑하고 목적에 따라 테이블을 분해하거나 합치는 작업을 합니다. 이 단계에서는 성능을 최적화해야 합니다. 이 단계에서 중요한 작업은 비정규화입니다. 비정규화를 먼저 고민하고 필요할 때 정규형을 선택하는 것은 잘못된 방향입니다. 정규화가 완전히 끝나야 비정규형을 고려할 수 있습니다. 또한 물리설계 단계에서는 인덱스 설계가 포함됩니다. 매우 중요한 과정인데 물리설계 단계에서 완전하게 이루어지지는 않습니다. 파티셔닝전략을 세우고 많은 테스트를 거쳐야 하며 클러스터링이나 IOT등의 테이블 타입도 신중하게 고려해야 합니다.

데이터베이스 구축단계는 마지막 단계로 물리설계에서 도출된 여러 객체(테이블,인덱스,제약 등)을 생성하는 단계입니다. 물리설계에서 스크립트가 나오므로 이 단계에는 DBA가 보통 수행하게 됩니다.

데이터베이스가 구축되고 나서는 데이터가 적재되고 운영됩니다. 운영하면서 문제점이 발생하면 해결하며 요구사항이 추가되거나 변경되면서 모델변경관리를 하게됩니다.

 

2.4 주제영역(Subject Area)

데이터 아키텍처의 최상위 단계로 비즈니스의 목표를 달성하는 데 필요한 데이터집합을 의미합니다. 여기저기 산재된 유사한 성격의 데이터를 체계화해 그룹으로 묶은 것을 의미합니다.

주제영역이 무엇인지에 대한 정의는 쉽지만, 실제로 주제영역을 도출하고 각 주제영역을 정의하는 것은 결코 쉬운 작업이 아닙니다. 주제영역을 정의하려면 기업에 존재하는 모든 데이터를 파악해야 합니다. 그리고 주제영역이 한없이 늘어날 수 없으므로 모든 데이터는 10개 또는 20개로 정의된 주제 영역에 속해야 합니다. 또한 각 주제영역의 상세화 수준도 균일해야 합니다. 무엇보다 규칙이나 법칙에 의해서 정해질 수 없다는 점이 주제영역작업을 어렵게 합니다. 실제로 주제영역을 도출하는 것이 힘든 이유는 데이터의 성격을 파악하는 힘이 없기 때문입니다. 데이터를 보고 업무나 프로세스밖에 볼 수 없다면 엔터티를 정의하기 어려운 것처럼 주제영역을 도출하기로 어렵습니다.

주제영역은 하위 개념의 서브주체영역으로 분류할 수 있으며 주제영역 내에서는 데이터를 상세하게 정의한 엔터티를 관리하게 됩니다. 주제영역은 기업의 정보체계구조를 한눈에 파악하고 관리할 수 있도록 지원하기 위해 구축됩니다. 즉, 데이터모델링을 하지 않더라도 주제영역은 정의돼야 합니다. 데이터를 체계적으로 분류하는 것은 아키텍처를 구축하지 않더라도 기본이 되는 부분이며 분류체계는 모든 학문의 중요한 접근방법이기도 합니다.

업무영역은 데이터와 무관하게 주로 어플리케이션 단위로 구성됩니다. 예를 들어 여러 종류의 계좌가 존재하면 각 계좌를 관리하는 엔터티는 주식,선물,펀드,저축 등으로 분산돼 있습니다. 최근에는 계좌 데이터를 계좌영역으로 모아서 관리하기도 하지만 여전히 많은 시스템에서는 업무프로세스에 따라 분산된 경우가 많습니다.

원칙적으로는 주제영역이 기준이 되야 하지만 근본적으로 주제영역을 정의할 시간적 여유가 없고 프로젝트의 모든 구성원이 익숙해져있는 업무 영영 개념을 흔들기에는 어려움이 있습니다.

주제영역을 정의하고 현행 엔터티에 주제영역을 할당해야 하는데 현행 엔터티의 이동이 불가피해서 R&R(Roles and Responsibilities)이 혼란스러워집니다. 하지만 어려움이 있더라도 주제영역으로 모델링을 수행하는 것이 바람직합니다.

 

2.5데이터 표준화

표준화란 일정한 기준에 따라 통일하는 것입니다. 통일시키는 것이 데이터 표준화의 핵심입니다. 데이터 표준화를 수행하는 이유는 데이터의 품질을 높이기 위해서입니다. 일관된 사용은 데이터의 오류를 줄여주므로 품질이 높아집니다.

서로 다른 속성이름으로 사용하거나 영문이 다르거나 데이터타입이 다르면 안됩니다. 같은 속성인데 다른 데이터 타입을 사용하면 형 변환에 의해 성능문제도 발생할 수 있습니다. 예를들어 사원과 직원이라는 용어 중 사원을 사용하기로 원칙을 정했다면 ‘사원번호’와 ‘직원번호’가 같이 사용되면 안됩니다. 같이 사용되지 않도록 시스템에서 제어해 줘야 합니다.

데이터 표준화의 출발은 단어를 정의하는 것입니다. 정의된 단어는 궁극적으로 속성에 사용됩니다. 이때 주의할 것이 이음동의어(Synonym)입니다. 사원과 직원이 동일한 의미라면 한 단어만 사용해야 합니다. 사원이 표준어가 되고 직원은 유사어나 금지어로 관리해 사용하지 못하도록 해야합니다. 이음동의어가 문제가 되는 근본적인 이유는 일관적인 용어의 사용에 방해되기 때문입니다. 용어의 일관된 사용이 중요하지 않다면 이음동의어는 문제 되지 않을 것입니다.

만약 이음동의어를 사용하려면 논리적으로 사용하는 것이 좋습니다. 이음동의어로 묶인 단어 중에서 시스템에서 사용할 이음동의어를 지정해 대표로 사용하는 것입니다. 그리고 이음동의어로 묶인 다른 단어들을 참조할 수 있도록 합니다. 논리적으로는 여러 개의 같은 단어가 존재하지만 대표적인 하나의 단어만 사용되는 것입니다.

이음동의어의 문제는 컬럼명과도 관련이 있습니다. 단어를 정의할 때 단어의 영문명을 함께 정의하고 컬럼명에 최종적으로 사용될 단축 영문명도 정의합니다. 예를 들어 사원이라는 단어는 ‘회사에서 근무하는 사람’이라는 뜻이 있으며 영문은 ‘employee’이고 단축 영문명은 ‘EMP’라고 정의합니다. 이렇게 정의된 단어는 속성에 사용되는데 사원번호라는 속성의 컬럼명은 ‘EMP_NO’등이 됩니다. 데이터베이스에서 단축영문명은 중요하게 사용됩니다.

만약 사원의 이음동의어인 직원은 ‘staff’라는 영문과 ‘STAF’라는 단축영문을 사용한다면 직원번호의 컬럼명은 ‘STAF_NO’가 되어 ‘EMP_NO’와 달라지게 됩니다. 이는 혼란을 일으킬 가능성이 존재하므로 바람직하지 않습니다.

이음동의어와 유사한 것이 동음이의어(Homonym)입니다. 동일한 단어를 사용하지만 의미가 다른 것을 의미합니다. 예를 들어 ‘이전’이라는 단어는 ‘이후’에 대한 상대적 의미와 ‘옮긴다’라는 의미로 사용될 수 있습니다. 이때 영문 단어가 달라지며 영문 약어명이 달라지게 됩니다. ‘이전일자’라는 속성을 사용하면 ‘BF_DT’나’TRN_DT’등으로 달라지는데 속성의 의미에 맞는 컬럼명을 사용했는지를 파악하기가 쉽지 않습니다. 옮긴 일자를 의미하는 속성에 ‘BF_DT’를 사용하면 안되는데 잘못 사용될 가능성은 존재합니다.

동음이의어 역시 사용하지 않는 것이 바람직하다고 생각합니다. 다시한번 강조하지만 동일한 의미의 속성명은 통일시키는 것이 데이터표준화의 핵심입니다. 만약 동음이의어의 사용을 허용하면 메타 관리 시스템에서 지원을 철저히 해야합니다. ‘이전’이라는 단어가 포함된 속성을 등록할 때는 두 가지 의미를 보여 선택할 수 있도록 해야 합니다.

데이터표준화를 수행할 때 중요한 또다른 요소는 도메인(Domain)입니다. 도메인은 데이터타입과 길이,포멧등이 같은 값의 집합입니다. 하나의 속성에는 허용된 유효한 값의 형태가 같아야 하므로 도메인이 하나만 사용돼야 합니다. 도메인은 단어와 더불어 표준화의 중요한 대상이므로 도메인을 정의하는 것은 중요합니다.

예를 들면 ‘특정한 날짜를 의미할 때는 ‘일자’를 사용한다’ 던가 ‘’시분초’까지 의미할때는 ‘일시’를 사용한다’ 등으로 원칙을 구체적으로 정해야합니다.

그리고 중요한 것이 코드 속성을 관리하는 것입니다. 공통 코드로 등록해 관리할 코드 속성이 일반 속성과 다른 점은 코드값,코드명이 존재한다는 것입니다. ‘~코드’로 끝나는 속성이 모두 코드값이 존재하는 것은 아닙니다. 코드값이 존재하는 속성에 대해서만 코드값을 등록하는 기능을 부여하면 그만입니다. 코드값이 존재하지 않는 속성은 모두 일반 속성입니다.

표준화는 모델러가 수행하는 기초적인 작업입니다. 하지만 모델링을 수행하는 데 기반이 되는 작업일 뿐 표준화가 모델링에서 많은 부분을 차지하지는 않습니다.

2.6 ERD (Entity Relationship Diagram)

ERD는 데이터를 함축적이고 이해하기 쉽게 표현해주는 다이어그램입니다. 표기법을 정확히 구사하면 많은 것을 표현할 수 있어 관련자 간의 커뮤니케이션을 돕는 훌륭한 도구가 됩니다.

ERD를 작성할 때는 여러 규칙이 있습니다. 우선 엔터티를 배치하는 것이 중요합니다. 그래야 관계선을 표현하기 수월해지며 모델의 가독성이 좋아져 궁극적으로 관련자 간의 케뮤니케이션을 돕게 됩니다.

엔터티를 배치할 때는 상위(부모)엔터티가 하위(자식)엔터티의 위쪽에 있는 것이 좋습니다. 좌우로 위치시키는 것도 좋습니다. 상위엔터티는 왼쪽에 하위엔터티는 오른쪽에 위치시키면 됩니다.

슈퍼타입과 서브타입 관계는 슈퍼타입을 위쪽에, 서브타입을 아래쪽에 위치시키는 것이 일반적입니다. 하지만 서브타입의 개수가 많아 상하로 배치하기 어렵다면 슈퍼타입 오른쪽에 서브타입을 위치시킵니다.

실체 엔터티는 모델의 위쪽에 위치시키는 것이 좋습니다. 행위 엔터티는 일반적으로 실체엔터티의 아래쪽에 있게 됩니다. 가공엔터티는 별도로 위치시킬 수 있고 연관된 행위 엔터티의 주변에 위치시킬 수도 있습니다. 관계가 존재하는 두 개의 행위 엔터티는 좌우로 나란히 위치시키는 것이 좋습니다.

교차엔터티는 양쪽 엔터티 사이에 위치하는 것이 좋은데 교차엔터티의 좌우로 양쪽 엔터티가 위치하는 것이 상하로 위치하는 것보다 가독성이 좋아집니다. 양쪽 엔터티가 상위에, 교차엔터티가 하위에 위치하는 것은 좋지 않습니다.

데이터마트에서 주로 사용되는 팩트(Fact)엔터티와 디멘션(Dimension)엔터티의 관계라면 팩트엔터티 사방으로 디멘션엔터티를 배치시킬 수 있습니다.

엔터티의 속성 순서를 적절하게 위치시키는 것도 모델의 가독성을 높이는 효과를 가져다줍니다. 이론에서 릴레이션의 속성 순서는 의미가 없지만 논리 모델이나 물리 모델에서 엔터티의 속성순서는 나름대로 의미가 있습니다. 중요한 속성이나 자주사용되는 속성은 엔터티 상단에 위치하는 것이 좋습니다. 속성이 많은 엔터티는 일관된 속성순서가 없으면 가독성이 나빠져 속성을 찾기 어려워집니다.

주 식별자는 엔터티의 최상단에 위치해야 합니다. 주 식별자 다음으로는 대체식별자가 오는 것이 좋습니다. 대체식별자는 후보 식별자 중 주 식별자로 선택되지 않은 속성이어서 주 식별자 못지않게 중요하며 자주 사용될 것입니다. 외래식별자도 중요한 속성이므로 엔터티의 위쪽에 위치하게 됩니다. 외재식별자 중에서 참조 데이터로서 관리하는 속성은 아래쪽에 위치할 수도 있습니다.

일반속성은 기초속성이 엔터티 위쪽에 위치하게 됩니다. 추출속성과 중복속성은 기초속성과 주로 같이 사용되는 속성이라면 같은 위치에 존재하는 것이 좋습니다. 기초속성과 주로 같이 사용되지 않으면 엔터티 아래쪽에 존재하는 것이 좋습니다. 엔터티 가장 하단에는 시스템속성이 위치해야 합니다. 위와 같은 속성배치 원칙을 기본으로 하면서 성격이 유사하거나 같이 사용될 수 있는 속성은 같이 위치시킵니다.

동시에 입력되거나 조회되는 속성은 같은 위치에 존재하는 것이 좋습니다. 또한 엔터티 위쪽에 위치하지 않는 일반속성들은 도메인에 따라 그룹으로 배치할 수도 있습니다. 금액,일자 속성등은 모여 있으면 가독성이 좋아집니다.

관계선을 표현할 때는 관계선이 서로 얽히지 않게 표현해야 합니다. 그리고 엔터티를 통과해서 관계선이 표현되지 않도록 해야합니다. 관계선이 엔터티를 통과하면 관계가 없는데도 관계가 있는것처럼 보여 주의해야 합니다.

ERD에 데이터 요소를 표현할 때 색상이나 밑줄,취소선,폰트 사이즈등을 이용하는 것도 좋은방법입니다. 이슈가 존재하는 속성은 빨간색과 밑줄을 사용해서 표현하거나 추가된 속성은 파란색으로 구분하거나 하는 경우입니다.

나름대로 방법을 정해서 일관되게 사용하면 더욱 도움이 될 것입니다. 주의해야 할점은 해결된 이슈 등에 대해서는 정상적인 상태로 돌려놓아야 한다는 것입니다.

ERD는 단순히 박스와 선으로 이루어진 모형이 아니고 분명한 문법이 있으며 응용하면 효율적인 표현법이 있습니다. 다만 ERD는 엔터티의 스키마를 표현하는 도구이므로 ERD만으로는 이해하는 데 한계가 있을 수 있습니다. 중요 데이터에 대해서는 사례 데이터를 릴레이션으로 생성해 놓는 것이 좋습니다.

ERD의 예

출처 : http://jheg.github.io/rails/2015/01/08/building-a-simple-rails-app-part-1/