SQLD 이론 요약 - part 1. 데이터 모델링의 이해
📗 Part 1. 데이터 모델링의 이해
✏️ 데이터 모델링의 이해
1. 데이터 모델의 이해
-
데이터베이스의
모델링: 현실 세계를 반영한모델을 단순화 하여 표현하는 기법 -
모델링이 갖춰야 할 조건
- 현실 세계를 반영 해야 함
- 단순화하여 표현해야 함
- 관리하고자 하는 데이터를 모델로 설계함
-
데이터 모델링 3요소 : 어떤것(Things), 성격(Attributes), 관계(Relationships)
-
모델링 특징 : (현실세계) →
추상화,단순화,명확화→ (모델)- 추상화(Abstraction) : 현실 세계를 일정한 형식으로 표현 = 개념을 간략하게 표현
- 단순화(Simplification) : 정해진 표기법으로 현실세계를 단순하고 쉽게 표현
- 명확화(Clarity) : 불분명함을 제거하고, 명확하게 해석할 수 있도록 기술
-
모델링 3가지 관점
- 데이터 관점 (What, Data)
- 프로세스 관점 (How, Process)
- 데이터와 프로세스의 상관 관점 (Data vs. Process, Interaction)
-
데이터 품질 보장하기 위한 데이터 모델링시 유의점
중복: 같은 데이터가 여러 엔티티에 중복 저장 현상 지양비유연성: 사소한 변경에도 데이터 모델이 수시로 변경되면 안됨 → 데이터 모델과 프로세스 분리를 통해 유연성 높이도록 해야 함비일관성: 다른 데이터와의 연관성 고려하지 않고, 일부 데이터만 변경할 수 있음 → 데이터 간 상호 연관 관계에 대해 명확히 정의해야 함
-
데이터 모델링 3가지 단계 :
개념적→논리적→물리적- 개념적 데이터 모델링 : 추상화 레벨이 가장 높음, 포괄적인 수준의 모델링
- 논리적 데이터 모델링 : 재사용성 가장 높은 모델링, key, 속성, 관계 등 모두 표현하는 단계
- 물리적 데이터 모델링 : DB에 실제 구현하기 위해 성능, 가용성 등의 물리적 성격 고려
-
데이터의 독립성
ANSI-SPARC 아키텍처- 1975년 제안된 DBMS의 추상적인 설계 표준 (DBMS = 데이터 베이스 관리 시스템)
- 해당 아키텍처에서는 스키마를 3단계 구조로 나눔
- 분리 목적 : DB에 대한 사용자의 관점과 실제 DB의 물리적 방식을 분리하기 위함
- 사용자 입장에서는 DB 내부 구조에 대해 알 필요 없이 필요한 데이터만 볼 수 있으면 되고, DBA 입장에서는 애플리케이션에 영향을 주지 않고, DB의 구조를 변경할 수 있어야 독립성이 보장된다 할 수 있음
- 3단계 스키마 구조
외부 스키마: 각 사용자가 보는 개인적 DB 스키마 정의 (사용자 관점 , Multiple Users’View)개념 스키마: 모든 사용자 관점을 통합한 전체 DB (통합된 관점, Community View of DB)내부 스키마: 물리적인 저장 구조 (물리적 관점, Physical Representation)
- 3단계 스키마 구조가 보장하는 데이터 독립성
- ANSI-SPARC 아키텍처에서 스키마를 3단계 구조로 나눈 이유는 독립성 보장하기 위함
- 어떤 독립성을 보장하는가?
논리적 독립성: 개념 스키마가 변경되어도 외부 스키마는 영향 받지 않음물리적 독립성: 내부 스키마가 변경되어도 외부/개념 스키마는 영향 받지 않음
-
ERD (Entity Relationship Diagram)
- 시스템에 어떤 Entity가 존재하고, 그들 간 어떤 관계가 있는지 나타내는 다이어그램
- 엔티티, 관계, 속성으로 이루어짐
- ERD 표기 방식 (데이터 모델 표기법)
- Peter Chen : 대학 교제에서 사용
- IE (Crow’s Foot, 까마귀발 표기법) : 가장 많이 사용
- Barker : 오라클에서 사용되는 모델, Crow’sFoot과 유사
- UML : 소프트웨어 공학에서 주로 사용됨
-
ERD 표준 기호

- IE/Crow’sFoot 표기법

- UML(통합모델링언어)에서의 관계(RelationShip)
- 연관관계 (실선) : 항상 이용하는 관계 ex) 소속된다.
- 의존관계 (점선) : 상대 행위에 의해 발생하는 관계 ex) 주문한다.
- 식별자 관계 VS 비식별자 관계
- 식별자 관계
- 부모 Entity의 식별자가 자식 Entity의 주식별자가 되는 관계
- 주식별자는 반드시 존재해야 하므로, 부모 엔티티가 있어야 생성 가능
- 단일식별자(식별자 1개)인지, 복합식별자(식별자 여러개)인지에 따라 1:1이거나 1:M인지 결정됨
- 비식별자 관계
- 부모 Entity의 식별자가 자식 Entity의 주식별자가 아닌 일반속성이 되는 관계
- 일반 속성의 속성값은 NULL이 될 수 있으므로, 부모 Entity 없는 자식 Entity 생성 가능
- 자식 Entity가 존재하는 상태에서, 부모 Entity가 삭제될 수도 있음
- 식별자 관계
2. Entity (엔티티)
- Entity 의미
- 식별 가능한 객체
- 엔티티는 여러 속성(Attribute)를 가질 수 있음
- Entity 명명
- 현업업무에서 사용하는 용어 사용
- 약어 사용금지, 단수 명사 사용, 고유한 이름 사용, 생성의미대로 부여
- Entity 특징
- 업무에 쓰이는 정보여야 함 → 사용하지 않는 Entity는 삭제하는 것이 좋음
- 유니크함을 보장할 수 있는
식별자가 있어야 함 (식별자에 의해 식별 가능) 2개 이상의 인스턴스를 갖고 있어야 함 → 회원에 1명만 존재한다면 엔티티로 만들 필요 없음- 반드시
속성을 갖고 있어야 함 - 다른 엔티티와 1개 이상의 관계를 갖고 있어야 함 → 통계성/코드성 Entity는 관계 생략 가능
- Entity 분류
- 유형 vs 무형
유형엔티티 : 물리적 형태 존재 → 안정적, 지속적 (ex. 상품, 회원)개념엔티티 : 물리적 형태 없음 → 개념적 정보 (ex. 부서, 학과)사건엔티티 :행위를 함으로써 발생, 빈번함, 통계자료로 이용 가능 (ex. 주문, 이벤트 응모)
- 발생 시점
- 기본 엔티티 → 중심 (中) 엔티티 → 행위 엔티티
- 기본 : 독립적으로 생성, 자식 엔티티 가질 수 있음 (부모 역할) 업무에 원래 존재하는 정보 (ex. 상품, 부서)
- 중심 :
기본 엔티티에서 파생,행위 엔티티생성, 데이터 양이 많이 발생 (ex. 주문, 계약) - 행위 : 2개 이상의 부모 Entity로부터 발생, 초기단계보다 상세 단계에서 많이 도출됨 데이터가 자주 변경되거나 증가할 수 있음 (ex. 주문 내역, 사원 변경 이력)
- 기본 엔티티 → 중심 (中) 엔티티 → 행위 엔티티
- 유형 vs 무형
3. Attribute (속성)
-
속성 의미
- Entity의 특징을 나타내는
최소 데이터 단위,의미상 더이상 분리되지 않는 레벨 - 사물이나 개념의 특징을 설명해줄 수 있는 항목들 → 프로세스에 불필요한 항목은 삭제하는 것이 좋음
- Entity의 특징을 나타내는
-
속성값 : 하나의 인스턴스를 구체적으로 나타내주는 데이터
-
속성 명명
- 해당업무에서 사용하는 이름 부여, 구체적으로 명명하여 데이터 모델에서 유일성 확보
- 서술식 속성명은 사용 금지, 약어 사용 금지
-
Attribute(속성) 분류
특성에 따른 분류 : 기본 / 설계 / 파생 속성- 기본 속성 : 업무 프로세스 분석을 통해 바로 정의 가능한 속성, 일반적 속성
- 설계 속성 : 설계하다보니 필요하다 판단되어 도출해 낸 속성 학생 엔티티에 이름, 학과만으로는 유니크함 보장 불가 → 설계속성으로 학번 생성
- 파생 속성 : 다른 속성으로부터 파생된 속성 → 계산된 값이나 가공된 값이 속함 (ex. 재고) 단, 파생속성을 설계시, 데이터 정합성이 고려되어야함
- 구성 방식에 따른 분류 : PK / FK / 일반 속성
- PK (primary key) 속성 : Entity의 인스턴스들을 식별할 수 있는 속성 (유니크함 부여)
- FK (foreign key) 속성 : 다른 엔티티의 속성에서 가져온 속성 (다른 엔티티와 관계 맺게 해줌)
- 일반속성 : PK와 FK 제외한 나머지 속성
-
엔티티, 인스턴스, 속성, 속성값 관계
- 엔티티 ⊃ 인스턴스 ⊃ 속성 관계 성립
- 1개 Entity는 2개 이상의 인스턴스를 가짐
- 1개의 인스턴스는 2개 이상의 속성을 가짐
- 1개의 속성은 1개의 속성값만 가짐 → 속성에 값이 여러개일 경우, 별도의 엔티티로 분리
- ex) 회원 Entity
- 엔티티는 이름, 전화번호 등 여러 속성을 가짐
- 문슈비는 회원 엔티티의 인스턴스에 해당함
- 나이의 속성은 20이라는 속성값을 가짐
- 엔티티 ⊃ 인스턴스 ⊃ 속성 관계 성립
-
엔티티 : Table
인스턴스 : Row
속성(Attribute) : Column

4. Relationship(관계)
- 관계
- Entity와 Entity와의 관계
- 관계 페어링의 집합 (패어링 = Entity 안에 인스턴스가 개별적으로 관계를 가지는 것)
- 연관성 타입에 따라
존재 관계와행위 관계로 나뉨- 존재 관계 : 존재 자체로 연관성 있는 관계 (ex. 학생-학과, 직원-부서)
- 행위 관계 : 특정 행위를 함으로써 연관성 생기는 관계 (ex. 회원-주문, 학생 - 출석부)
- 관계 표기시 표기 항목 (관계의 표기법)
- 관계명(Membership) : 관계 이름 (학과-학생은 포함한다, 소속된다 관계명 가짐)
- 어떤 관계를 맺고 있는지 나타내는 문장
- 모든 관계는 2개의 관계명을 가짐 (각 엔티티 관점에서 관계명을 하나씩 가지기 때문)
- 관계차수(Cardinality) : 관계에 참여하는 수 (ex. 1:N, N:M, 1:M)
- 관계 선택사양(Optionality) : 필수인지 선택인지 여부
- 관계명(Membership) : 관계 이름 (학과-학생은 포함한다, 소속된다 관계명 가짐)

5. Identifiers (식별자)
-
식별자
- 각각의 인스턴스를 구분하도록 해주는 대표 속성을 의미함
- Entity 내에서 인스턴스를 구분하는 구분자
-
주식별자 : 기본키(PK, PrimaryKey)에 해당하는 속성
- 하나의 속성이 주식별자가 될 수도 있고, 여러개의 속성이 주식별자가 될 수도 있음
- 주식별자 특성 : 유일성, 최소성, 불변성, 존재성
- 각 인스턴스에 유니크함을 부여하여 식별 가능해야 함 (유일성)
- 유일성을 보장하는 최소 개수의 속성이어야 함 (최소성)
- 속성값이 되도록 변하지 않아야 함 (불변성)
- 속성값이 NULL일 수 없음 (존재성)
-
주식별자 분류

✏️ 데이터 모델과 SQL
1. 정규화 (Normalization)
- 정규화 ( - ) : 데이터 정합성을 위해 Entity를 작은 단위로 분리하는 과정
- 데이터 정합성 = 데이터의 정확성과 일관성을 유지하고 보장
- 정규화시 조회 성능은 처리조건에 따라 향상되기도, 저하되기도 함
- 하지만 정규화시 입력, 수정, 삭제 성능은 일반적으로 향상됨
- 제1정규형
- 모든 속성은 반드시 하나의 값만 가져야 함
- 유사 속성 반복되는 경우도 1차 정규화 대상이 됨
- 제2정규형
- 일반속성은 반드시 모든 주식별자에 종속되어야 하는데, 주식별자가 단일 식별자가 아닌 복합식별자인 경우, 일반 속성이 주식별자의 일부에만 종속 될 수 있음
- 일반속성이 복합PK의 부분 종석적인 경우 해당됨
- 제3정규형
- 주식별자가 아닌 속성 간에는 서로 종속될 수 없음

2. 반정규화 (De-Normalization)
- 반정규화 ( + )
- 데이터 조회 성능 향상을 위해 데이터 중복을 허용하거나, 데이터를 그룹핑 하는 과정
- 조회 성능은 향상될 수 있지만, 입력, 수정, 삭제 성능으 저하될 수 있음
- 데이터 정합성 이슈가 발생할 수 있음
- 반정규화는 정규화가 끝난 후 거치게 됨
- 테이블 반정규화
- 테이블 병합 : 1:1 관계 테이블 병합 / 1:M 관계 테이블 병합 / 슈퍼 서브 타입 테이블 병합
- 테이블 분할 : 테이블 수직분할(속성 분할) / 테이블 수평 분할(인스턴스 분할, 파티셔닝)
- 테이블 추가 : 중복, 통계, 이력, 부분 테이블 추가
- 컬럼 반정규화 :
중복/파생/이력 테이블컬럼 추가 중복 관계추가 (관계 반정규화)

3. NULL
- NULL : 값 없음, 존재하지 않음을 의미함
- SQL에서의 NULL 처리
- 가로 연산 : NULL 포함되어 있으면 결과가 NULL (ex. 200-Null = Null)
세로 연산:NULL제외하고 계산(ex. 100+200+null+300 = 600)- 비교 연산 : NULL과 비교연산시 항상 NULL
✏️ 용어
- 트랜잭션 : 데이터 조작하기 위한 하나의 논리적인 작업 단위
- 도메인
- 속성이 가질 수 있는 속성값의 범위
- 속성에 대한 데이터 타입, 크기, 제약사항 지정
- Entity 정의시 데이터 타입과 크기로 나타낼 수 있음
- ex) 우편번호는 5섯자리 숫자라는 범위를 가짐
- 시스템 카탈로그
- 사용자 테이블과 별개로 시스템 자체에 관련이 있는 데이터를 담고 있는 DB
- 시스템 카탈로그에 저장된 데이터를 메타데이터라고 함
- 시스템 테이블로 구성되어 있고, SELECT만 가능함