SQLD(SQLP) 과목1 - 1장. 데이터 모델의 이해

목차

데이터 모델의 이해

1. 정보 시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
2. 현실 세계의 데이터(what)를 약속된 표기법으로 표현하는 과정
3. 데이터 베이스 구축을 위한 분석 및 설계의 과정

모델링의 특징

• 추상화: 현실 세계를 일정한 형식에 맞추어 표현
• 단순화: 복잡한 현실 세계를 약속된 규약에 의해 제한된 표기법 or 언어로 표현 → 쉽게 이해할 수 있도록 함
• 명확성: 애매모호함 제거, 정확하게 현상 기술 → 누구나 쉽게 이해할 수 있도록 함

모델링의 3가지 관점

데이터 관점 + 프로세스 관점 + 데이터와 프로세스의 상관 관점

1. 데이터(data, what): 업무가 어떤 데이터와 관련이 있는지 / 데이터 간 관계는 무엇인지
2. 프로세스(process, how): 실제하고 있는 업무는 무엇인지 / 무엇을 해야 하는지
3. 상관(data vs process): 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지

중요성

• 파급효과(Leverage): 데이터 구조 변경으로 인한 일련의 변경 작업들은 전체 시스템 구축 프로젝트에서 큰 위험 요소임
• 복잡한 정보 요구 사항의 간결한 표현(Conciseness)
• 데이터 품질(Data Quality): 데이터 품질은 데이터 구조에 의해 결정됨

유의할 점

• 중복 피하기: 여러 장소에 같은 정보 저장 X
• 비유연성 피하기: 데이터의 정의를 데이터의 사용 프로세스와 분리해야 함
• 비일관성 피하기: 데이터와 데이터 간 상호 연관 관계에 대한 명확한 정의 필요

데이터 모델링의 3단계 진행

1. 개념적 모델링(추상화)
   사용자 요구사항 찾고 분석 → 핵심 엔터티와 그들 간의 관계 발견 → ER 다이어그램 이용해 관계 표현
   ▶ 데이터 모델링 과정이 전조직에 걸쳐 이루어진다면 → 전사적 데이터 모델(Enterprise data model) **
   ▶ EA 수립 시 이용 多 **
   ▶ 추상화 수준이 높고 업무 중심적이고 포괄적인 수준의 모델링 **
2. 논리적 모델링(정규화)
   시스템으로 구축하고자 하는 업무에 대해 key, 속성, 관계 등을 정확하게 표현
   ▶ 재사용성 높음 **
   ▶ 데이터 모델링이 최종적으로 완료된 상태 **
   ▶ 데이터 베이스 설계 프로세스의 Input **
   ▶ 논리적 모델링 과정에서 정규화 진행: 일관성 확보, 중복 제거 → 속성들이 가장 적절한 엔터티에 배치되도록 함 **
3. 물리적 모델링(DB)
   실제 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격 고려하여 설계

보통은 데이터 축과 애플리케이션 축으로 구분하여 프로젝트를 진행하지만 객체 지향의 경우 데이터 모델링과 프로세스 모델링을 구분하지 않고 일체형으로 진행함.

 

데이터 독립성

▶ 목적: 유지 보수 비용 절감, 데이터 복잡도 낮춤, 중복된 데이터 줄임 등등...

• 논리적 독립성: 개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않도록 지원하는 것
• 물리적 독립성: 내부 스키마가 변경되어도 외부 및 개념 스키마는 영향을 받지 않도록 지원하는 것 

▶ 데이터 독립성 확보 시 다음과 같은 효과를 얻을 수 있음

1. 각 뷰(view)의 독립성을 유지하고 계층별 뷰에 영향을 주지 않고 변경 가능
2. 단계별 스키마에 따라 데이터 정의어(DDL)와 데이터 조작어(DML)가 다름을 제공

 

데이터 베이스 3단계 구조(three-schema architecture)

1. 외부 스키마(External Schema)
   사용자 관점, 접근하는 특성에 따른 스키마 구성, 개개 사용자가 보는 개인적 DB 스키마
2. 개념 스키마(Conceptual Schema)
   통합 관점, 모든 사용자 관점을 통합한 조직 전체의 DB를 기술하는 것
3. 내부 스키마(Internal Schema)
   물리적 저장 구조, 내부 단계 + 내부 스키마, 데이터가 물리적으로 저장된 방법에 대한 스키마 구조

외부 스키마(뷰) ↔ 개념 스키마(통합된 사용자) ↔ 내부 스키마(물리)

사상(Mapping)

• 외부적, 개념적 사상(논리적 사상): 외부적 뷰 ↔ 개념적 뷰
• 개념적, 내부적 사상(물리적 사상): 개념적 뷰 ↔ DB
  ** DB 구조 변경 시 개념적, 내부적 사상이 변경되어야 함 → 개념적 스키마 유지 위해 

데이터 모델링의 3요소

1. 엔터티(thing): 업무가 관여하는 어떤 것
2. 관계(relationships): 업무가 관여하는 어떤 것 간의 관계
3. 속성(attributes): 어떤 것이 가지는 성격

ERD 작성 순서

1. 엔터티를 그린다
   ▶ 엔터티는 사각형으로 표기
   
2. 엔터티를 적절하게 배치한다
   ▶ 중요한 엔터티: 왼쪽 상단
   
3. 엔터티 간 관계를 설정한다
   ▶ 초기에는 모두 primary key로 속성이 상속되는 식별자 관계를 설정함
   ▶ 중복되는 관계 X, circle 관계 X
   
4. 관계명을 기술한다
   ▶ 현재형 사용
   ▶ 지나치게 포괄적인 용어 X (이다, 가진다 등)
   
5. 관계 차수를 설정(cardinality 표시- 1:1, 1:M, M:M)한다
   ▶ 하나의 관계: IE 표기법 = 실선 / 바커 표기법 = 실선과 점선 혼용
   ▶ 다수 참여의 관계: 까마귀발
   ▶ 필수, 선택 표시: 관계선에 원을 표현
   
6. 관계의 필수여부를 기술한다(필수적, 선택적 관계 표시)

 

 

 

 

---

엔터티

업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 것(Thing)

 

엔터티와 인스턴스에 대한 내용과 표기법

대부분 사각형으로 표현

 

특징

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 함
• 유일한 식별자에 의해 식별이 가능해야 함
• 영속적으로 존재하는 인스턴스의 집합이어야 함 (1개가 아니라 2개 이상)
• 업무 프로세스에 의해 이용되어야 함
• 다른 엔터티와 최소 한 개 이상의 관계가 있어야 함
  ▶ 예외적으로 관계를 생략해 표현해야 하는 경우가 존재: 통계성 엔터티 도출, 코드성 엔터티 도출, 시스템 처리 시 내부 필요에 의한 엔터티 도출 등
  ▶ 통계성 엔터티: 주어진 데이터를 집계(통계)하여 새로운 엔터티를 만들 때 기존의 관계를 직접적으로 유지할 필요가 없는 경우가 있음
     ex) SALES(판매) 테이블이 있고, 매일매일의 판매 데이터를 저장한다고 가정. 하지만 **월별 매출 통계를 저장하는     테이블(MONTHLY_SALES)**을 따로 만든다면?
  ▶ 코드성 엔터티: 코드성 데이터(예: 성별 코드, 국가 코드, 제품 카테고리 등)는 원래의 데이터와 1:N 관계가 아니더라도 별도의 엔터티로 분리해서 관리하는 것이 일반적
     ex) 사용자의 성별을 저장한다고 가정. 성별(M 또는 F)을 직접 USER 테이블에 넣을 수도 있지만, **코드성 엔터티         (GENDER_CODE)**로 분리하는 것이 일반적.
  ▶ 시스템 처리 시 내부 필요에 의한 엔터티 도출: 시스템 내부적으로 데이터를 임시 저장하거나 처리할 필요가 있을 때 관계를 생략하는 경우
     ex) 사용자가 로그인하면, 시스템은 **로그인 기록(LOGIN_HISTORY)**을 남김. 하지만 USER 엔터티와 직접적인 관계     (FK)를 맺지 않을 수도 있음.

 

분류

1. 유무형에 따른 분류

유형 엔터티 (Tangible Entity)	개념 엔터티 (Conceptual Entity)	사건 엔터티 (Event Entity)
ex)  사원, 물품, 강사	ex) 조직, 보험상품	ex) 주문, 청구, 미납

 

2. 발생 시점에 따른 분류

기본 엔터티 (Fundamental Entity, Key Entity)	중심 엔터티 (Main Entity)	행위 엔터티 (Activity Entity)
다른 엔터티와의 관계에 의해 생성되는 것이 아닌 독립적으로 생성되는 것 (부모역할) ex) 사원, 부서, 고객 등	기본 엔터티로부터 발생되고 그 업무에서 중심적인 역할을 함 ex) 계약, 사고, 청구, 주문 등	두 개 이상의 부모 엔터티로부터 발생하고, 자주 내용이 바뀌거나 데이터 양이 증가 ex) 주문 목록, 사원 변경 이력 등

 

 

엔터티의 명명

1. 가능하면 현업에서 사용하는 용어 사용
2. 가능하면 약어 사용 X
3. 단수 명사 사용
4. 모든 엔터티에서 유일하게 이름이 부여되어야 함
5. 엔터티 생성 의미대로 의미 부여

---

속성

업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위

 

• 업무에서 필요로 함
• 의미상 더 이상 분리되지 않음
• 엔터티를 설명하고 인스턴스의 구성요소가 됨

 

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

1. 한 개의 엔터티는 두 개 이상의 인스턴스 집합이어야 함
2. 한 개의 엔터티는 두 개 이상의 속성을 가짐
3. 한 개의 속성은 한 개의 속성값 가짐

 

속성의 표기법

엔터티 내에 이름을 포함하여 표현

 

특징

1. 해당 업무에서 필요하고 관리하고자 하는 정보여야 함
2. 정규화 이론에 근거하여 정해진 주식별자에 함수적 종속성을 가져야 함
3. 하나의 속성은 한 개의 값만을 가짐 → 하나의 속성에 여러 개의 값이 있는 다중값일 경우 별도의 엔터티를 이용하여 분리

 

분류

1. 속성의 특성에 따른 분류

기본속성 (Basic Attribute)	설계 속성 (Designed Attribute)	파생 속성 (Derived Attribute)
코드성 데이터, 엔터티를 식별하기 위해 부여한 일련 번호, 다른 속성을 계산하거나 영향을 받아 생성된 속성을 제외한 모든 속성	업무상 필요한 데이터 이외에 데이터 모델링을 위해, 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성 ex) 코드성 속성, 일련변호, ...	다른 속성에 영향을 받아 발생하는 속성 ex) 계산된 값들

 

2. 엔터티 구성 방식에 따른 분류

PK(Primary Key) 속성	FK(Foreign Key) 속성	일반 속성
엔터티를 식별할 수 있는 속성	다른 엔터티와의 관계에서 포함된 속성	PK/FK에 포함되지 않은 특성

 

 

3. 세부 의미를 쪼갤 수 있는지에 따른 분류

단일값 속성 (Single-Valued Attribute)	다중값 속성 (Multi-Valued Attribute)
속성 하나에 한 개의 값을 가지는 경우 ex) 주민등록번호	속성 하나에 여러 개의 값을 가지는 경우 ex) 전화번호(집 전화번호, 개인 휴대전화번호, ...) → 1차 정규화를 하거나 개별 엔터티를 만들어 관계로 연결해야 함

 

도메인

각 속성이 가질 수 있는 값의 범위

 

속성의 명명

1. 해당 업무에서 사용하는 이름 부여
2. 서술식 속성명 사용 X
3. 약어 사용 가급적 제한
4. 전체 데이터 모델에서 유일성을 확보하는 것이 좋음

---

관계

인스턴스 사이의 논리적인 연관성으로서 존재 또는 행위로써 서로에게 연관성이 부여된 상태

 

관계의 페어링? 같은 엔터티 내의 인스턴스들 간 관계 설정을 의미

 

관계의 표현

이항관계(Binary Relationship) / 삼항 관계(Ternary Relationship) /... / n항 관계

 

 

관계의 분류

1. 목적에 따른 분류 - UML (Unified Modeling Language)

연관 관계 (Association) 존재에 의한 관계	의존 관계 (Dependency) 행위에 의한 관계
ex) 부서(DB팀) - 사원(황경빈) : 소속된다 실선으로 표현됨	ex) 고객(김경재) - 주문(CTA201): 주문한다 점선으로 표현됨

** ERD에서는 존재적 관계와 행위에 의한 관계를 구분하지 않고 표현하는 반면 클래스 다이어그램에서는 이것을 구분하여 연관 관계와 의존 관계로 표현 ** 

 

관계의 표기법

주요 개념 3가지

• 관계명(Membership)
• 관계차수(Cardinality): 1:1, 1:M, M:N
• 관계 선택 사양(Optionality): 필수 관계, 선택 관계

관계명(Membership)

• 관계 시작점(The Beginning)
• 관계 끝점(The end)

관계 시작점과 끝점 모두 관계 이름을 가져야 하며, 참여자의 관점에 따라 관계 이름이 능동적(Active)이거나 수동적(Passive)으로 명명됨

 

명명 규칙

1. 애매한 동사를 피함 
2. 현재형으로 표현

관계 차수(Degree / Cardinality)

이 부분은 책을 참고하는 편이 좋습니다!!

 

관계 선택사양(Optionality)

1. 필수 참여 관계(Mandatory membership)
2. 선택적인 관계(Optional membership)

선택 참여하는 엔터티 쪽을 원으로 표시 (교재 참고)

만약 관계가 표시된 양쪽 엔터티에 모두 선택 참여가 표시된다면, 즉 0:0(zero to zero)의 관계가 된다면 해당 관계는 잘못될 확률이 많으므로 관계 설정이 잘못되었는지를 검토해 보아야 함

 

 

관계 체크사항

• 두 개의 엔터티 사이에 관심 있는 연관 규칙이 존재하는가?
• 두 개의 엔터티 사이에 정보의 조합이 발생하는가?
• 업무 기술서, 장표에 관계 연결에 대한 규칙이 서술되어 있는가?
• 업무 기술서, 장표에 관계 연결을 가능하게 하는 동사(Verb)가 있는가?

관계 읽기

• 기준(Source) 엔터티를 한 개(One) 또는 각(Each)으로 읽음
• 대상(Target) 엔터티의 관계 참여도, 즉 개수(하나, 하나 이상)를 읽음
• 관계 선택 사양과 관계명을 읽음

ex)

각각의/하나의	기준 엔터티 (Souce)	관계 차수	관련 엔터티 (Target)	선택 사양	관계명
각각의	사원은	한	부서에	항상	속한다

 

 

---

식별자

식별자란?

하나의 엔터티 내에서 인스턴스들을 구분할 수 있는 구분자

 

주식별자 특징

• 유일성: 주식별자에 의해 엔터티 내에 모든 인스턴스들이 유일하게 구분되어야 함
• 최소성: 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 함
• 불변성: 지정된 주식별자의 값은 자주 변하지 않는 것이어야 함
• 존재성: 주식별자가 지정이 되면 반드시 값이 들어와야 함

식별자 분류

대표성 여부	주식별자	엔터티 내에서 각 어커런스를 구분할 수 있는 구분자이며, 타 엔터티와 참조 관계를 연결할 수 있는 식별자
	보조식별자	엔터티 내에서 각 어커런스를 구분할 수 있는 구분자이나 대표성을 가지지 못해 참조 관계 연결을 못함
스스로 생성 여부	내부식별자	엔터티 내부에서 스스로 만들어지는 식별자
	외부식별자	타 엔터티와의 관계를 통해 타 엔터티로부터 받아오는 식별자
속성 수	단일식별자	하나의 속성으로 구성된 식별자
	복합식별자	둘 이상의 속성으로 구성된 식별자
대체 여부	본질식별자	업무에 의해 만들어지는 식별자
	인조식별자	업무적으로 만들어지지는 않지만 원조 식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만든 식별자

 

주식별자 도출 기준

• 해당 업무에서 자주 이용되는 속성
• 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정 X
  → 다른 구분자가 존재하지 않을 경우 새로운 식별자 생성(일련번호, 코드 등) 
• 복합으로 주식별자로 구성할 경우 너무 많은 속성이 포함되지 않도록 함
  → 속성의 개수가 많아지는 경우 새로운 인조 식별자를 생성

식별자 관계 / 비식별자 관계

식별자 관계	부모의 주식별자 → 상속 → 자식의 주식별자(1:M, 1:1) ▶ null 값이 온면 안되므로 반드시 부모 엔터티가 생성되어야 자기 자신의 엔터티가 생성되는 경우 ▶ 1:1의 관계: 부모로부터 받은 속성을 자식 엔터티가 모두 사용하고 그것만으로 주식별자로 사용되는 경우 (자식의 주식별자 = 부모로부터 상속받은 속성들) ▶ 1:M의 관계: 부모로부터 받은 속성을 포함하여 다른 부모 엔터티에서 받은 속성을 포함하거나 스스로 가지고 있는 속성과 함께 주식별자로 구성되는 경우 (자식의 주식별자 = 부모로부터 상속받은 속성들 + 스스로 가지고 있는 그 외 속성들) IE에서 실선으로 표현
비식별자 관계	부모의 주식별자 → 상속 → 자식의 일반 속성 ▶ 부모 없는 자식이 생성될 수 있는 경우, null 값이 들어와도 되는 경우 ▶ 엔터티 별로 생명주기(Life Cycle)를 다르게 관리할 경우 ex) 부모가 자식만 남겨두고 먼저 소멸할 수 있음 ▶여러 개의 엔터티가 하나의 엔터티로 통합 및 표현되었는데 각각의 엔터티가 별도의 관계를 가질 때 ex) 교재 참고 ▶ 자식 엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단되는 경우 IE에서 점선으로 표현

 

 

식별자 관계로만 설정할 경우의 문제점

지속적으로 식별자 관계를 연결한 데이터 모델의 PK 속성의 수는 데이터 모델의 흐름이 길어질수록 증가할 수밖에 없는 구조를 갖게 됨

 

비식별자 관계로만 설정할 경우의 문제점

기준 속성이 자식 엔터티로 상속되지 않아 자식 엔터티에서 데이터를 처리할 때 쓸데없이 부모 엔터티까지 찾아가야 하는 경우가 발생

→ 불필요한 조인이 다량으로 유발되어 sql 구문이 길어지고 성능 저하 가능

 

 

---

요즘 SQLD 응시를 위해 열심히 공부하고 있습니다:) 꾸준히 복습용 포스팅 올려볼게요!