데이터 모델링의 이해

ERD(Entity-Realtionship Diagram)

ERD 개념

• 데이터베이스의 개체(Entity), 관계(Relationship), 속성(Attribute)들을 시각적으로 표현하는 도구
• 데이터베이스 설계 과정에서 데이터 간의 관계를 명확하게 이해하고 표현하기 위해 사용
• ERD는 데이터의 논리적 구조를 시각화
• 이를 통해 복잡한 데이터 구조를 쉽게 이해하고 관리할 수 있음

주요 구성요소

구성요소	설명
개체(Entity)	- 데이터베이스에 저장되는 주요 정보의 단위 - 사람,장소,물건,이벤트 등을 나타낼 수 있음 - ERD에서는 주로 사각형으로 표현
속성(Attribute)	- 개체를 구체적으로 설명하는 데이터 조각 - 예를들어, '고객'개체는 이름, 주소, 전화번호 등의 속성을 가질수 있음 - ERD에서는 주로 작은 원 또는 타원으로 표시
관계(Relationship)	- 두 개체 간의 연관성을 나타내며, 선으로 연결하여 표시 - 관계는 종종 '1대1','1대다','다대다'로 분류

ERD 작성 순서

ERD의 중요성

• 데이터의 구조를 체계적으로 설계하도록 도와줌
• 다양한 정보 시스템의 데이터 구조를 통합하고 표준화하는데 기여
• 데이터 구조상의 문제를 초기에 발견하고 수정할 수 있음
• 개발자와 설계자 간의 명확한 커뮤니케이션 도구 역할을 함

ERD 작성 시 고려사항

고려사항	설명
정확성	- 모든 개체와 속성, 관계가 정확하게 표현되어야 함
명확성	- 도식이 간결하고 이해하기 쉬워야 함
유연성	- 데이터베이스 설계가 변경될 때 쉽게 수정할 수 있어야 함

엔터티(Entity)

엔터티의 개념

• 데이터베이스에서 관리해야 할 대상을 의미
• 현실 세계에 존재하는 객체나 개념을 데이터베이스에서 관리 가능한 형태로 추상화한 것
• 일반적으로 명사 형태로 표현되며, 사람·사물·개념·사건 등을 포함

엔터티의 특징

• 서로 구분될 수 있어야 함
• 일정 기간 저장되어야 함
• 업무에 꼭 필요한 정보여야 함
• 업무 프로세스에서 사용됨
• 다수(둘 이상)의 인스턴스 집합
• 하나 이상의 속성을 가져야 함
• 다른 엔터티와 최소 한 개 이상의 관계를 가져야 함
• 유일한 식별자(주식별자)에 의하여 식별이 가능해야 함

엔터티의 구분

분류	설명	예
유형 엔터티	물리적인 형태가 있고 지속적으로 존재하는 엔터티	사원, 상품, 고객, 학생
개념 엔터티	물리적인 형태는 없지만 관리해야 하는 개념적인 엔터티	조직, 보험상품, 부서, 계좌
사건 엔터티	업무 수행 과정에서 발생하는 사건이나 거래를 나타내는 엔터티	주문, 계약, 결제, 신청

---

분류	설명	예
기본 엔터티	업무에 원래부터 존재하는 정보로, 다른 엔터티의 부모 역할을 하는 엔터티	사원, 고객, 상품, 부서
중심 엔터티	기본 엔터티로부터 발생하며 업무의 중심적인 역할을 하는 엔터티	주문, 계약, 계좌, 사고
행위 엔터티	두 개 이상의 엔터티 간 업무 행위나 거래로 인해 발생하는 엔터티	주문내역, 계약내역, 결제내역, 사원변경이력

속성(Attribute)

속성의 개념

• 엔터티를 구성하는 가장 작은 데이터 단위
• 엔터티의 성질이나 상태를 나타내는 정보를 의미
• 하나의 엔터티는 여러 개의 속성으로 구성
• 엔터티가 관리 대상이면, 속성은 그 대상을 설명하는 정보

속성값

• 특정 엔터티 인스턴스가 가지는 실제 데이터 값
• 속성은 항목(컬럼)이고, 속성값은 그 항목에 저장된 실제 내용
• 하나의 속성은 여러 인스턴스에서 서로 다른 값을 가짐

속성과 관련된 주요 개념

개념	설명	예
원자성	하나의 속성에는 더 이상 쪼갤 수 없는 하나의 값만 저장되어야 함	전화번호 속성에 여러 번호를 한꺼번에 저장하지 않음
유일성	특정 속성의 값이 다른 행과 중복되지 않아 개체를 구별할 수 있어야 함	회원번호, 사번
무결성	속성 값이 정해진 규칙과 범위를 만족하여 데이터의 정확성과 일관성을 유지해야 함	나이에 문자 입력 금지, 필수값은 NULL 금지
관련성	속성은 해당 엔터티와 직접적으로 관련된 정보여야 함	회원 엔터티에 이름, 이메일, 가입일 저장
변경 가능성	속성 값이 업무 수행 중 변경될 수 있는지를 고려해야 함	주소, 전화번호, 이메일은 변경 가능
파생 가능성	다른 속성의 값을 이용해 계산하거나 만들어낼 수 있는 속성인지 판단해야 함	생년월일로 나이 계산, 수량 × 단가로 총금액 계산

속성의 구분

특성 기준

분류	설명	예
기본 속성	업무로부터 직접 도출되며 원래부터 존재하는 속성	이름, 생년월일, 상품명, 주소
설계 속성	데이터 모델링 과정에서 업무 규칙이나 관리를 위해 새롭게 만든 속성	회원번호, 주문번호, 상품코드
파생 속성	다른 속성의 값을 계산하거나 변환하여 만들어지는 속성	나이, 총금액, 평균점수

구조 기준

분류	설명	예
단순 속성	더 이상 의미 있게 나눌 수 없는 하나의 값으로 구성된 속성	성별, 나이, 사번
복합 속성	여러 개의 세부 속성으로 나눌 수 있는 속성	주소 → 시/도, 시/군/구, 상세주소
다중값 속성	하나의 엔터티가 여러 개의 값을 가질 수 있는 속성	전화번호, 이메일, 보유 자격증

역할 기준

분류	설명	예
기본키 속성	엔터티의 각 인스턴스를 유일하게 식별하기 위해 사용하는 속성	회원번호, 사번, 주문번호
외래키 속성	다른 엔터티의 기본키를 참조하여 엔터티 간 관계를 연결하는 속성	주문의 회원번호, 사원의 부서번호
일반 속성	기본키나 외래키가 아닌, 엔터티의 일반적인 특성을 나타내는 속성	이름, 주소, 전화번호, 상품명

도메인

• 도메인은 속성에 허용되는 값의 범위를 의미
• 데이터 타입, 길이, 형식, 허용 값 등을 정의
• 도메인을 통해 데이터 무결성을 강화할 수 있음

도메인 유형	설명	예
정수 도메인	정수 형태의 값만 허용하는 도메인	나이: 0~150, 점수: 0~100
문자열 도메인	문자나 문자열 형태의 값을 허용하는 도메인	이름: "홍길동", 주소: "부산광역시"
열거형 도메인	미리 정해진 값 중 하나만 선택할 수 있는 도메인	성별: {남, 여}, 주문상태: {주문, 배송중, 완료, 취소}

관계

• 관계는 엔터티와 엔터티 사이의 논리적인 연결을 의미
• 데이터베이스에서 데이터가 어떻게 연관되어 있는지를 표현
• 관계를 통해 엔터티 간의 업무 규칙과 흐름을 파악할 수 있다.

관계 종류	IE 표기법	Barker 표기법	특징
1 : 1	┼────────┼	────────	양쪽 모두 반드시 1개
1 : 0 또는 1 : 1	┼────────○┼	──────····	한쪽은 필수, 다른 쪽은 선택
1 : N	┼────────<	────────<	하나의 엔터티가 여러 엔터티와 관계
1 : 1 또는 1 : N	┼────────┼<	────────<	최소 1개, 최대 N개
1 : 0 또는 1 : 1 또는 1 : N	┼────────○│<	········<	최소 0개, 최대 N개

관계의 분류

분류	설명	예
존재에 의한 관계	엔터티가 존재하는 것 자체로 다른 엔터티와 관계가 형성되는 경우 부모가 없으면 자식이 존재할 수 없음(강한 의존성)	부서-사원, 학생-학과
행위에 의한 관계	특정 업무나 행위가 발생함으로써 엔터티 간 관계가 형성되는 경우 서로 독립적으로 존재 가능(약한 의존성)	고객-주문, 회원-결제

연관 관계/의존 관계

분류	설명	관계 성격	표기	예
연관 관계	엔터티 간의 구조적이고 지속적인 관계 서로 관련된 상태가 장기간 유지됨	장기적 관계	실선	학생 - 학과
의존 관계	특정 기능 수행 시 다른 객체나 모듈을 일시적으로 사용하는 관계 필요한 순간에만 참조하거나 호출함	일시적 관계	점선	주문 처리 시 결제 모듈을 일시적으로 호출