개발자 취업준비

데이터 모델링(Data Modeling)과 ERD

naspeciallist 2025. 2. 25. 23:59

 

1. 모델링이란?

 

모델링(Modeling)이란 현실세계를 대상으로 일종의 모델을 만드는 것을 의미 합니다. 여기서 모델이란 현실세계의 사물 혹은 개념을 구성요소로 나누고 이를 일정하게 도식화 한것이라고 할 수 있습니다. 이때 도식화는 약속된 표기법에 따라 한것을 모델링이라고 할 수 있습니다. 저희가 모델링을 하는 이유는 업무의 흐름을 가시화하고 명세화하여 이를 설계, 개발 또는 시스템 관리에 사용하기 위함입니다. 

 

업무의 흐름을 가시화하고 명세화하는 것을 업무형상화라고 합니다.

 

모델링은 기본적으로 추상화를 이용하여 나타냅니다. 추상화는 사물을 있는 그대로 나타내는 것이 아니라 특징만 추려서 간단하게 나타내는 것입니다. 모델링도 이와 마찬가지로 업무프로세스의 데이터를 불필요하게 구체화 하는 것이 아니라 추상화하여 단순 명료하게 표현하는 것이 가장 중요한 목표라고 할 수 있습니다.

 

데이터베이스를 설계하는 것도 마찬가지로 하나의 모델링이며 이를 데이터베이스 모델링이라고 합니다.

 

 

 

2. 모델링의 특징

 

모델링의 특징은 다음과 같습니다.

  • 추상화(Abstraction)
  • 단순화(Simplification)
  • 명확화(Clarity)

모델링은 위에서 설명한 것처럼 데이터의 특징을  추출하여 일정한 형식으로 표현합니다. 또한 복잡한 현실세계를 그대로 표현하기 보다는 단순하게 표현합니다. UML이나 ERD같이 제한된 언어나 약속된 표기법을 이용하여 누구나 이해하기 쉽게 단순하게 표현 합니다. 또한 모델링은 읽는 사람에 따라 서로 다르게 해석되면 안됩니다. 약속된 표기법에 따라 누구나 명확하게 이해 할 수 있도록 기술해야 합니다.

 

모델링의 3가지 단계

  • 개념적 데이터 모델링: 개체와 개체들 간의 관계에서 ER다이어그램을 만드는 과정
  • 논리적 데이터 모델링: ER다이어그램을 사용하여 관계 스키마 모델을 만드는 과정
  • 물리적 데이터 모델링: 관계 스키마 모델의 물리적 구조를 정의하고 구현하는 과정

데이터 모델링은 거시적 포괄적 수준에서 먼저 모델링을 수행하고 점차 상세한 수준으로 들어가 최종적으로 물리적 모델링을 수행합니다. 개념적 모델링은 요구사항을 수집하고 분석한 결과를 토대로 업무의 핵심적은 개념을 구분하고 전체적인 뼈대를 만드는 과정입니다. 업무와 개념 중심으로 포괄적인 모델링을 수행하며 EA(Enterprise Architecture)를 수립할 때 많이 이용합니다. 이 단계에서는 엔티티와 속성을 도출하여 ER다이어그램을 만드는 과정입니다.

 

논리적 데이터 모델링이란 개념적 모델링에서 만든 ER다이어그램을 사용하려는 DBMS에 맞게 사상(Mapping)하여 실제 데이터 베이스로 구현하기 위한 관계 스키마 모델을 만드는 과정 입니다. 데이터 모델에 대한 키(Key), 속성(Attribute), 관계(Relationship)등을 표현하며 서로 다른 DBMS에 적용이 가능한 수준에 맞게 추상화 레벨을 가지기 때문에 재사용성이 높습니다. 상세속성 추출, 정규화수행, 데이터 표준화가 수행되며 식별자를 도출하고 관계를 정의합니다.

 

물리적 데이터 모델링은 특정 DBMS에 맞추어 구현이 가능한 수준에서 모델링을 수행하는 것으로 DBMS의 성능이나 보안, 가용성등을 고려하여 설계하는 것입니다. 가장 낮은 수준에서의 추상화 레벨을 가지며 DBMS의 특성에 맞게 저장 구조를 정의하여 데이터 베이스가 최적의 성능을 낼 수 있게 합니다. 물리적 모델링을 하는 경우 트랜잭션, 저장공간 설계의 측면에서 3가지를 고려해 주어야 하는데 응답시간을 최소화해야 하고, 동시에 많은 트랜잭션을 발생시킬 수 있어야 하며, 데이터가 저장될 공간을 효율적으로 배치해야합니다.

 

데이터 모델링 예시

 

 

 

 

3.ANSI-SPARC 에서 정의한 3단계 스키마 구조

 

ANSI-SPARC( American National Standards Institute , Standards Planning And Requirements Committee) 에서는 데이터의 독립성을 보장하기 위해 3단계의 스키마 구조로 설계방법을 제시하였습니다. 이는 DBMS의 추상적인 설계표준으로 제안되었으며 사용자,설계자, 개발자 관점에서 스키마를 정의하였습니다.

 

1. 외부 스키마(External Schema)

사용자의 관점입니다. 사용자 또는 애플리케이션이 바로보는 데이터베이스 스키마를 정의한 것 입니다. 뷰 또는 SQL쿼리를 통해 외부 스키마를 구성할 수 있습니다. 개념 스키마로 부터 생성되거나 사용 될 수 있으며 한개의 개념스키마로부터 여러개의 외부 스키마가 만들어 질 수 있습니다. 동일한 데이터에 대해 서로 다른 표현을 제공할 수 있습니다.

 

2. 개념 스키마(Conceptual Schema)

설계자 관점, 모든 사용자가 바라보는 데이터 베이스 스키마를 통합하여 나타냅니다. 전체 데이터베이스에 저장되는 데이터와 그 관계를 정의하며 통합된 뷰를 제공합니다. 전체데이터베이스의 논리적인 구조를 기술하며 무결성 제약조건들이 명시되어 있는지를 기술합니다. 관계 데이터 모델에서 테이블들의 집합으로 표현됩니다.

 

3. 내부 스키마(Internal Schema)

개발자 관점, 디스크나 메모리 상의 물리적, 실질적 저장구조를 나타내며, 테이블 칼럼,인덱스 등을 정의합니다. 물리적 뷰를 제공합니다. 

 

3단계 스키마 구조를 통해 데이터의 독립성이 보장됩니다. 예를 들어 개념스키마가 변경되어도 외부 스키마는 영향을 받지 않습니다. 또한 내부 스키마가 변경되어도 개념스키마나 외부 스키마는 영향을 받지 않습니다.

 

 

4. ERD

 

ERD는 데이터베이스를 구성하는 데이터의 놀리적 구성요소를 엔티티(Entity)로 정의하고 엔티티간의 관계를 특별한 표기법으로 나타냄으로써 스키마를 설계하는 방법을 제공합니다.

 

  • ER모델: 세상의 모든 사물을 개체(Entity)와 개체간의 관계(Relationship)로 표현한것입니다.
  • 개체: 독립적인 의미를 지니고 있는 유무형의 사람 또는 사물로 개체의 특성을 나타내는 속성(Attribute)에 의해 식별됩니다.

ER 모델은 현실세계에서 개체들을 도출하고 개체들 사이의 관계를 기술하는 것으로 ER모델을 이용하여 ERD(ER Diagram)을 만들 수 있습니다. ERD에서는 개체는 ㅁ , 개체의 속성은 ㅇ,  개체 사이의 관계는 ◇로 표현됩니다. 

 

ERD 예시

 

데이터베이스에서 개체란 데이터를 가진 대상입니다. 그리고 데이터들이 가진 공통의 속성이 개체타입(Entity Type)이 되며 여러개의 개체가 모여있는 것을 개체 집합(Entity Set) 라고 합니다. 엔티티란 데이터베이스 구성 요소 중 독립적으로 식별가능한 객체를 말합니다. 데이터 모델링은 엔티티를 정의하는 것으로부터 시작됩니다.

 

 

ER다이어그램상에서 개체 타입은 직사각형으로 표현됩니다. 개체에는 약한 개체와 강한 개체가 있는데 강한 개체란 다른 개체의 도움없이 독자적으로 존재할 수 있는 객체이고 약한 객체는 독자적으로 존재 할 수 없으며 반드시 상위 개체 타입을 가지며 2중ㅁ를 이용하여 그립니다.

 

위 그림을 예시로 들어보겠습니다. 회사의 직원이라는 개체가 있습니다. 직원은 독자적으로 존재 할 수 있는 개체로 강한 개체타입입니다. 그에 비해 부양가족은 직원이 없으면 존재하지 못하므로 상위 개체 타입으로 직원을 가지는 약한 개체 타입입니다.

 

 

엔티티는 2가지 분류기준에 따라 나눌 수 있습니다. 첫번째로 발생 시점과 상속 관계에 따른 분류 입니다. 여기서는 엔티티를 기본 엔티티, 중심 엔티티, 행위 엔티티 3가지로 분류 할 수 있습니다.

  • 기본 엔티티 : 자신의 고유한 주식별자를 가지는 독립적으로 생성되는 엔티티입니다.
  • 중심 엔티티 : 기본엔티티부터 주식별자를 상속받아 생성되며 업무의 중심 역할을 하는 엔티티입니다.
  • 행위 엔티티 : 두개 이상의 엔티티를 상속받아 생성되는 엔티티이며 내용이 자주 변경되거나 데이터양이 계속 증가합니다.

두번째로 물리적 형태의 존재 여부에 따라 분류할 수 있습니다. 여기서는 엔티티를 유형 엔티티, 개념 엔티티, 사건 엔티티로 분류 할 수 있습니다.

  • 유형 엔티티 : 물리적 형태가 존재하는 엔티티
  • 개념 엔티티 : 물리적 형태 없이 개념적으로 정의되는 엔티티
  • 사건 엔티티 : 업무를 수행하면서 발생하는 행위나 이벤트를 나타내는 엔티티

 

엔티티의 특징

엔티티는 다음과 같은 특징을 가지고 있습니다.

  1. 업무에서 필요로 하고 관리하고자 하는 정보이어야 한다.
  2. 식별이 가능하도록 유일한 식별자를 가져야 한다..
  3. 영속적으로 존재하는 인스턴스가 두개 이상인 집합을 이루어야 한다.
  4. 하위요소로 반드시 속성을 가져야한다
  5. 엔티티는 다른 엔티티와 한 개 이상의 관계를 가져야 한다. 단 통계성 엔티티나 코드성 엔티티의 경우 관계를 생략 할 수 있다.

 

속성(Attribute)

속성이란 엔티티에 대한 자세하고 구체적인 정보를 나타낸 것으로 엔티티의 하위 요소 입니다. 속성은 개체가 가진 성질을 의미하며 기본적으로 ER다이어그램에서 타원으로 표현하며 개체 타입을 나타내는 직사각형과 실선으로 연결합니다.

속성의 이름은 타원의 중앙에 표기하며 속성이 개체를 유일하게 식별 할 수 있는 키일 경우 속성 이름에 밑줄을 긋습니다.

 

 

 

속성의 개수에는 제한이 없지만 처리하고자 하는 업무 프로세스에 꼭 필요한 것인지 따져보고 해당 엔티티를 정의하는데 필수적인 것들로 최소화해야 합니다.

 

속성은 자신이 가질 수 있는 속성값들의 집합이라고 할 수 있습니다. 즉 속성값이란 속성이 가질 수 있는 특정 값을 말하며 하나의 엔티티 인스턴스가 가진 속성의 구체적인 값을 말합니다. 하나의 엔티티 인스턴스에서 각각의 속성은 한개의 속성 값만을 가져야 합니다. 속성값이 여러개인 경우 정규화를 통해서 한개의 속성값만을 갖게 할 수 있습니다.

 

속성은 특성과 구성방식에 따라 분류 할 수 있습니다.

 

먼저 속성의 특성에 따른 분류입니다. 기본 속성, 설계 속성, 파생 속성 3가지로 분류할 수 있습니다.

  • 기본 속성: 엔티티가 본래부터 가지고 있어야 하는 속성
  • 설계 속성: 엔티티가 본래부터 가지고 있던 속성은 아니지만 설계시 필요하다고 판단되어 도출한 속성
  • 파생 속성: 다른 속성으로부터 계산되거나 특정 규칙에 따라 변형되어 만들어진 속성

다음은 속성의 구성방식에 따른 분류 입니다.

  • PK(Primary Key, 기본키) 속성 : 해당 엔티티의 인스턴스를 유일하게 식별 할 수 있는 속성
  • FK(Foreign Key, 외래키) 속성 : 관계를 통해 다른 엔티티의 속성을 가져와 포함시킨 속성
  • 일반속성 : 키(PK,FK)가 아닌 나머지 일반 속성

 

위에서 정리했던 엔티티, 인스턴스 속성값들은 다음과 같은 특징들을 가지고 있습니다.

  • 한개의 엔티티는 두 개 이상의 인스턴스를 가진다.(엔티티는 인스턴스의 집합이다.)
  • 한개의 엔티티는 두개 이상의 속성을 가진다.(엔티티는 속성의 집합이다.)
  • 한개의 속성은 한개의 속성값만 가진다.

 

관계(Relationship)

관계란 엔티티와 엔티티 간에 맺고 있는 연관성을 의미합니다. 관계 타입이란 개체 타입과 개체 타입간의 연결 가능한 관계를 정의한 것이고 관계 집합은 관계로 연결된 집합을 의미합니다.

 

관계에는 존재적 관계와 행위적 관계가 있습니다. 사원과 부서의 관계처럼 일종의 소속 관계를 갖는 경우로 존재 자체로 서로 연관성을 갖는 관계를 존재적 관계라고 합니다. 행위적 관계는 고객과 주문의 관계처럼 한 엔티티가 특정 행위나 이벤트를 일으킬 경우에 연관성이 발생하는 관계를 의미합니다.

 

관계차수(Cardinality)

관계에는 관계차수라는 개념이 있습니다. 두 개체 타입의 관계에 실제로 참여하는 개별 개체수를 관계차수라고 정의합니다. 관계 차수는 일대일 관계, 일대다 관계, 다대일 관계, 다대다 관계가 있습니다. 한 학생이 하나의 학번을 갖는 것을 일대일 관계, 한개의 학과에 여러 명의 학생이 있는 것을 일대다 관계, 여러 명의 학생이 여러 개의 강좌를 듣는 것을 다대다 관계라고 합니다.

 

 

관계선택사항(Optionality)

필수적 관계인지 선택적 관계인지 나타내는것으로(Null가능 여부를 의미합니다.) 필수적 관계일 경우 Null값을 가질 수 없고 선택형 관계인 경우 Null값이 허용됩니다. 선택적 관계인 경우 실선과 까치발 기호에 o표시가 덧붙입니다. 

 

 

다음은 참고하면 좋은 ER다이어그램 기호 입니다.

 

 

식별자(Identifier)

일반적으로 사람을 신분증으로 구분하는 것처럼 엔티티 인스턴스 역시 유일하게 구별 할 수 있는 속성이 있어야 하며 이런 속성을 식별자라고 부릅니다. 

 

주식별자: 주식별자는 해당 엔티티 인스턴스를 유일하게 구별해주는 식별자로서 PK에 해당하는 속성을 말합니다. 주식별자는 아래의 네가지 성질을 만족해야 합니다.

  1. 유일성 : 각 엔티티 인스턴스를 유일하게 구별 할 수 있어야 합니다.
  2. 최소성 : 유일성을 보장하면서도 최소 개수의 속성이 되어야 합니다.
  3. 불변성 : 속성값이 최초 생성 시 부여된 값에서 변경되지 않고 유지되어야 합니다.
  4. 존재성 : 반드시 값을 가져야 하며 NULL값을 가질 수 없습니다.

보조식별자 (Alternate Key) : 해당 엔티티를 유일하게 구별할 수 있는 식별자이기는 하나 대표성을 가지지 못하며 다른 엔티티와 참조관계를 연결 할 수 없는 식별자입니다. 보통 AK(Alternate Key)라고도 합니다

 

내부식별자(Internal Identifier) : 엔티티 내부에서 스스로 만들어지는 식별자 입니다.

외부식별자(Foreign Identifier) : 관계를 통해 다른 엔티티로부터 받아오는 식별자이며 FK라고도 합니다.

 

단일식별자(Single Identifier) : 식별자를 구성하는 속성이 하나인 식별자입니다.

복합식별자(Composite Identifier): 식별자를 구성하는 속성이 둘 이상인 식별자 입니다.

 

 

식별자 관계

부모엔티티의 식별자가 자식엔티티의 주식별자의 구성에 포함될 때 입니다. 엔티티간의 강한 연결관계라고도 하며 ER다이어그램에서 실선으로 표현합니다. 부모 엔티티 인스턴스와 자식엔티티 인스턴스가 같은 생명주기를 가질 때 식별자 관계로 표현하는 것이 적합합니다.

 

비식별자 관계

앤티티간에 약한 연결 관계로 부모 엔티티의 식별자가 자식 엔티티의 일반 속성이 됩니다. ER다이어그램으로 표현할 때 점선으로 표현 합니다. 부모와 자식 엔티티 인스턴스가 다른 생명주기를 가질 때 비식별자 관계가 더 적합합니다.