AYSTORY

Part1 - Ch1. 데이터 모델링의 이해 본문

SQLD

Part1 - Ch1. 데이터 모델링의 이해

bye0nzn 2025. 7. 24. 23:54

 

데이터 모델링의 유의사항

  • 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 프로세스의 변화로 인해 데이터 모델이 수시로 변경될 가능성을 줄인다. (O)
  • 애플리케이션과 데이터 간의 연계성을 높여 데이터에 대한 정의가 명확해지도록 해야 한다. (X)
    • 애플리케이션과 데이터 간의 연계성이 높으면 애플리케이션이 변경될 때마다 데이터 모델도 변경되어야 하는 상황이 생길 수 있다.
    • 비유연성을 가지게 된다. 

ERD

  • 1:1의 관계 차수를 갖는 엔터티들은 관계에 참여하는 각각의 엔터티에 대해 단지 하나의 관계만을 가지고 있다. (O)
  • 존재에 의한 관계와 행위에 의한 관계를 구분해서 표현한다. (X)
    • ERD에서는 존재에 의한 관계와 행위에 의한 관계를 구분하지 않고 표현하며 클래스 다이어그램에서는 이것을 구분하여 연관 관계와 의존 관계로 표현한다.

엔터티 (Entity)

 

1. 엔터티란?

  • 식별이 가능한 객체
  • 업무에서 쓰이는 데이터를 용도별로 분류한 그룹
  • 명확한 조건이 기준이 되어야 함.
- 엔터티: Table
- 인스턴스: Row
- 속성: Column
  • 각각의 엔터티는 자신을 더 상세하게 나타내기 위해 속성(attribute)를 가짐.
예제
"프랜차이즈 카페에서는 다양한 음료 및 푸드 상품을 판매하고 이 상품들에 대한 카테고리, 상품명, 가격 등을 관리해야한다."
엔터티로 생성할 수 있는 것은? 
즉, 식별이 가능한 개체로 생성할 수 있는 것은? 상품

 

2. 엔터티의 특징

  • 업무에 쓰이는 정보여야 함.
  • unique함을 보장할 수 있는 식별자가 있어야 함.
  • 2개 이상의 인스턴스를 가지고 있어야 함.
    • 현재 인스턴스가 1개만 존재하고 앞으로도 쭉 1개만 존재할 예정이라면 이것은 엔터티로 볼 수 없다. 
    • 예) 쇼핑몰에 '대표'라는 엔터티가 있다고 가정할 때 현재 대표가 1명이고 앞으로도 쭉 1명일 예정이면 이걸 굳이 엔터티로 만들 필요X
  • 반드시 속성을 가지고 있어야 함.
    • 자신을 상세하게 나타낼 수 있는 속성을 가지고 있어야 함.
  • 다른 엔터티와 1개 이상의 관계를 가지고 있어야 함.
    • 각각의 엔터티는 다른 엔터티와의 연관성을 가지고 있어야 한다.
    • 회원 엔터티는 주문 엔터티와 관계를 가지고 있고 주문 엔터티는 상품 엔터티와 관계를 가지고 있다.

3. 엔터티 분류

 

1) 유형 vs. 무형

유형 엔터티 물리적인 형태 존재, 안정적, 지속적
ex) 상품, 회원 등
개념 엔터티 물리적인 형태 X, 개념적
ex) 부서, 학과 등
사건 엔터티 행위를 함으로써 발생, 빈번함, 통계 자료로 이용 가능
ex) 주문, 이벤트 응모 등

 

2) 발생시점

기본 엔터티 - 업무에 원래 존재하는 정보
- 독립적으로 생성되며, 자식 엔터티를 가질 수 있음.
ex) 상품, 회원, 사원, 부서 등
중심 엔터티 - 기본 엔터티로부터 파생되고, 행위 엔터티 생성
- 업무에 있어서 중심적인 역할을 하며 데이터 양이 많이 발생
ex) 주문, 매출, 계약 등
행위 엔터티 - 2개 이상의 엔터티로부터 파생
- 데이터가 자주 변경되거나 증가할 수 있음.
- 보통 설계 초기 단계보다는 상세 설계단계에서 많이 도출됨.
ex) 주문 내역, 이벤트 응모 이력 등

 

Tip. 엔터티 이름을 정할 때 주의할 점

- 업무에서 실제로 쓰이는 용어 사용
- 한글은 약어 사용X, 영문은 대문자 표기
- 단수 명사로 표현, 띄어쓰기X
- 다른 엔터티와 의미상으로 중복X
- 해당 엔터티가 갖고 있는 데이터가 무엇인지 명확하게 표현

속성(Attribute)

 

1. 속성이란?

  • 사물이나 개념의 특징을 설명해줄 수 있는 항목들
  • 의미상 더 이상 쪼개지지 않는 레벨이어야하고 프로세스에 필요한 항목이어야 함.

2. 속성값

  • 각각의 속성은 속성값을 가지며 속성값은 엔터티에 속한 하나의 인스턴스를 구체적으로 나타내주는 데이터
  • 하나의 속성은 한 개의 속성값만 가질 수 있음.
속성 속성값
이름 이지은
생년월일 19930516
소속사 EDAM엔터테인먼트

 

3. 엔터티, 인스턴스, 속성, 속성값의 관계

엔터티 ⊃ 인스턴스 ⊃ 속성
  • 한 개의 엔터티는 두 개 이상의 인스턴스를 가짐.
  • 한 개의 인스턴스는 두 개 이상의 속성을 가짐.
  • 한 개의 속성은 하나의 속성값을 가짐.

4. 분류

 

- 특성에 따른 분류

기본속성 업무 프로세스 분석을 통해 바로 정의가 가능한 속성
설계속성 업무에 존재하지는 않지만 설계하다 보니 필요하다고 판단되어 도출해낸 속성
파생속성 다른 속성의 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성
  • 기본속성
    • 엔터티의 가장 일반적인 속성
    • 업무 프로세스 분석을 통해 바로 정의가 가능한 속성들이 여기에 속함.
    • 엔터티의 가장 많은 %를 차지하는 속성
    • 일부 설계속성과 파생속성을 제외한 모든 속성이 기본 속성에 해당한다고 보면 됨.
  • 설계속성
    • 업무에 존재하지는 않지만, 설계 과정에서 합리적인 모델링을 위해 만들어진 속성
  • 파생속성
    • 다른 속성으로부터 파생된 속성
    • 계산된 값이나 가공된 값이 파생속성에 속함.
    • 파생속성을 설계할 경우 반드시 데이터의 정합성이 고려되어야 하고, 계산 과정에서 누락되는 데이터가 생기는 경우 결과값이 엉터리가 될 수 있는 위험 요소가 존재하기 때문에 불가피하게 필요한 경우에만 정의하는 것이 바람직.

- 구성방식에 따른 분류

PK (Prime Key) 속성 엔터티의 인스턴스들을 식별할 수 있는 속성
FK (Foreign Key) 속성 다른 엔터티의 속성에서 가져온 속성
일반속성 PK, FK를 제외한 나머지 속성
  • PK 속성: 엔터티에 속한 각 인스턴스에 unique함을 부여하는 속성
    • 상품 엔터티의 상품 코드, 학생 엔터티의 학번, 직원 엔터티의 사번 등
  • FK 속성: 다른 엔터티와 관계를 맺게 해주는 매개체 역할을 하는 속성
    • 직원 엔터티의 부서 코드, 학생 엔터티의 학과코드, 회원 엔터티의 회원등급코드 등
  • 일반속성
    • 상품 엔터티의 상품명, 가격, 학생 엔터티의 이름, 생년월일 등

5. 도메인(Domain)

  • 속성이 가질 수 있는 속성값의 범위
  • ex) 우편번호는 다섯 자리의 숫자라는 범위를 가지고 있고, 이것은 엔터티를 정의할 때 data type과 크기로 나타낼 수 있음.
Tip.

- 용어사전: 어떤 시스템이든 속성명은 업무와 직결되는 항목. 속성의 이름을 정확하면서도 직관적으로 부여하고 용어의 혼란을 없애기 위해 용어사전이라는 업무사전을 프로젝트에서 사용.
- 시스템 카탈로그: 사용자 테이블과는 별개로 시스템 자체에 관련이 있는 데이터를 담고 있는 DB이며, 시스템 테이블로 구성되어 있어 SQL을 이용하여 조회할 수 있다. 시스템 카탈로그에 저장된 데이터를 메타 데이터라고 하며 SELECT만 가능하고 INSERT, UPDATE, DELETE는 불가능하다. 

관계 (Relationship)

 

1. 관계란?

  • 엔터티와 엔터티와의 관계를 의미
  • 어떠한 연관성이 있는지 type을 분류하여 존재 관계와 행위 관계로 나눌 수 있음.
존재 관계 엄마와 아기처럼 존재 자체로 연관성이 있는 관계
ex) 직원-부서, 학생-학과 엔터티
행위 관계 특정한 행위를 함으로써 연관성이 생기는 관계
ex) 회원-주문, 학생-출석부 엔터티

 

2. 표기법

관계명 관계의 이름
관계차수 관계에 참여하는 수
관계선택사양 필수인지 선택인지의 여부
  • 관계명
    • 엔터티와 엔터티가 어떠한 관계를 맺고 있는지를 나타내주는 문장
    • 모든 관계에는 두 개의 관계명을 가지고 있음. (각 엔터티 관점에서 관계명을 하나씩 가지기 때문)
    • 반드시 명확한 문장으로 표현 + 현재형이어야 함.
    • ex) 주문한다, 소속된다, 출석을 한다
  • 관계차수
    • 각 엔터티에서 관계에 참여하는 수
    • 일반적으로 1:1, 1:M, M:N 형식으로 구분
  • 관계선택사양
    • 이 관계가 필수요소인지 선택사항인지를 나타내는 말
필수적 관계 참여자가 반드시 존재해야 하는 관계
선택적 관계 참여자가 없을 수도 있는 관계

 

예제
다음 중 엔터티 간의 관계를 정의할 때 고려해야 할 사항이 아닌 것?
1) 두 엔터티 사이를 이어주는 동사가 존재해야 한다.
2) 두 엔터티는 반드시 부모-자식의 관계여야 한다.
3) 두 엔터티 사이에 조합되는 정보가 존재해야 한다.
4) 두 엔터티 사이에 영향력 있는 관계가 존재해야 한다.

정답: 2)번 - 엔터티 간의 관계에는 부모-자식의 관계 외에 다른 관계도 존재할 수 있다.

식별자 (Identifiers)

 

1. 식별자란?

  • 모델 엔터티는 인스턴스를 가지고 있고 인스턴스는 속성으로 자신의 특성을 나타냄. 
  • 식별자는 이런 속성 중에 각각의 인스턴스를 구분 간으하게 만들어주는 대표격인 속성을 의미.

2. 주식별자

  • 기본키, PK에 해당하는 속성
  • 하나의 속성이 주식별자가 될 수도 있고 여러 개의 속성이 주식별자가 될 수도.
유일성 각 인스턴스에 유니크함을 부여하여 식별이 가능하도록 한다.
최소성 유일성을 보장하는 최소 개수의 속성이어야 한다.
불변성 속성값이 되도록 변하지 않아야 한다.
존재성 속성값이 NULL일 수도 있다.

 

3. 분류

 

- 대표성 여부

주식별자 - 유일성, 최소성, 불변성, 존재성을 가진 대표 식별자
- 다른 엔터티와 참조 관계로 연결
보조식별자 - 인스턴스를 식별할 수는 있지만 대표 식별자가 아님
- 다른 엔터티와 참조 관계로 연결X

 

- 스스로 생성되었는지 여부

내부식별자 엔터티 내부에서 스스로 생성된 식별자
외부식별자 다른 엔터티에서 온 식별자, 다른 엔터티와의 연결고리 역할

 

- 단일 속성의 여부

단일식별자 하나의 속성으로 구성된 식별자
복합식별자 두 개 이상의 속성으로 구성된 식별자

 

- 대체 여부

원조식별자 업무 프로세스에 존재하는 식별자, 가공되지 않은 원래의 식별자 (본질식별자)
대리식별자 주식별자의 속성이 두 개 이상인 경우 그 속성들을 하나로 묶어서 사용하는 식별자 (인조식별자)

 

4. 식별자 관계 vs. 비식별자 관계

  • 식별자 관계
    • 부모 엔터티의 식별자가 자식 엔터티의 주식별자가 되는 관계
    • 주식별자는 반드시 존재해야 하므로(존재성) 부모 엔터티가 있어야 생성 가능하며 단일식별자인지 복합식별자인지에 따라 1:1이거나 1:M이거나가 결정됨.
  • 비식별자 관계
    • 부모 엔터티의 식별자가 자식 엔터티의 주식별자가 아닌 일반 속성이 되는 관계
    • 일반 속성의 속성값은 NULL이 될 수 있으므로 부모 엔터티가 없는 자식 엔터티 생성이 가능하고 마찬가지의 이유로 자식 엔터티가 존재하는 상태에서 부모 엔터티가 삭제될 수도 있음.

'SQLD' 카테고리의 다른 글

ORACLE과 SQL Server에서의 차이  (2) 2025.08.19
Part2 - Ch3. 관리 구문  (7) 2025.08.04
Part2 - Ch2. SQL 활용  (2) 2025.07.29
Part2 - Ch1. SQL 기본  (4) 2025.07.28
Part1 - Ch2. 데이터 모델과 SQL  (4) 2025.07.28