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

데이터 모델링의 유의사항
- 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 프로세스의 변화로 인해 데이터 모델이 수시로 변경될 가능성을 줄인다. (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 |
