SQLD 1. 데이터 모델링의 이해

https://sy-log.tistory.com/62?category=992908

1. 데이터 모델링의 이해

데이터 모델링

(1) 데이터 모델링 - 고객의 비즈니스 프로세스를 이해하고, 규칙을 정의하여, 데이터 모델로 표현함

• 현실세계를 DB로 표현하기 위해 추상화
• 고객과의 의사소통을 통해서, 고객의 업무 프로세스를 이해해야 함
• 업무 프로세스를 추상화 & 소프트웨어를 분석 및 설계하면서 점점 상세해짐
• 모델링 관점
  - 데이터 모델링 표기법 사용
  - 고객이 쉽게 이해할 수 있도록
  - 복잡하지 않게 모델링해야함

데이터 모델링의 특징 - 추상화/ 단순화/ 명확성

• 추상화 : 현실세계를 간략하게 표현, 공통적인 특징을 찾고 간략하게 표현
• 단순화 : 누구나 쉽게 이해할 수 있도록 표현, 복잡한 문제 X
• 명확성 : 명확하게 의미가 해석되어야 하고 한 가지 의미를 가져야 함

데이터 모델링 단계 - 개념적 모델링 -> 논리적 모델링 -> 물리적 모델링

데이터 모델링은 개념적 -> 논리적 -> 물리적 모델링 단계로 이루어 진다.

1. 개념적 모델링(업무적&전사적 관점에서 모델링, 중요한 부분 위주로)
   - 전사적 관점
   - 추상화 수준이 가장 높음
   - 업무 측면에서 모델링
   - 중요한 부분 위주로(복잡 x)
   - 기술적 용어는 가급적 사용 X
   - 엔티티, 속성 도출 -> ERD작성
   
   
2. 논리적 모델링(변환작업(개념적->논리적), 식별자 정의 & 독립성 확보)
   - 특정 데이터베이스 모델에 종속
   - 식별자를 도출하고, 정의함
   - 모든 릴레이션, 관계, 속성 등을 표현
   - 정규화를 통해, 모델의 독립성을 확보하고 재사용성을 높임
3. 물리적 모델링 (데이터베이스 실제 구축)
   - DB 관리시스템에 테이블, 인덱스, 함수 등을 생성
   - 성능, 보안, 가용성 등을 고려

데이터 모델링 관점 : 데이터/ 프로세스/ 데이터와 프로세스

• 데이터 - 비즈니스 프로세스에서 사용되는 데이터
  - 구조분석
  - 정적 분석
• 프로세스 - 비즈니스 프로세스에서 수행하는 작업
  - 시나리오 분석
  - 도메인 분석/ 동적 분석
• 데이터와 프로세스 - 데이터-프로세스 간의 관계
  - CRUD 분석(Create, Read, Update, Delete)

데이터 모델링 고려사항 : 독립성/ 정규화/ 고객 요구사항 표현/ 데이터 품질 확보

데이터 중복/ 비유연성/ 비일관성이 발생하지 않도록 모델링 해야함

• 데이터 모델의 독립성
  - 정규화를 통해 중복 데이터 제거
  - 중복을 제거하여 모델 독립성확보
  - 독립성 확보된 모델은 고객 업무변화에 능동적 대응 가능
• 고객 요구사항의 표현
  - 고객 요구사항을 간결, 명확히 표현
  - 모델을 통해 데이터 모델러와 고객 간의 의사소통이 가능하도록
• 데이터 품질 확보
  - 데이터 표준을 확보해야, 품질 향상 가능
  - 데이터 표준을 정의하고 DB 구축
  - 표준 준수율 관리해야 함

(2) 데이터 모델링을 위한 ERD - 엔터티-엔터티 간 관계를 정의하는 모델링 방법

• ERD : Entity Relationship Diagram
• 사실상 데이터 모델링 표준
• 중요한 엔터니는 왼쪽 상단에 배치
• 이해하기 쉬움 & 복잡하지 않아야 함

ERD 절차 : 엔터티 도출 -> 엔터티 배치 -> 엔터티 관계 설정 -> 관계명 서술 -> 관계 참여도 표현 -> 관계 필수여부 표현

 

ERD 작성 절차

1. 엔터티 도출 및 그림 - 업무에서 관리해야 하는 집합을 도출
2. 엔터티 배치 - 중요한 엔터티는 왼쪽 상단 배치
3. 엔터티 간 관계 설정 - 엔터티간 관련성 파악
4. 관계명 서술 - 엔터티 간의 행위 or 존재
5. 관계 참여도 표현 - 한 엔터티와 다른 엔터티 간에 참여하는 관계의 수
6. 관계 필수여부 표현 - 반드시 존재해야 하는지 or 아닌지 표시

 

[2] 3층 스키마 ( 3-Level Schema)

(1) 3층 스키마 - 3단계 계층(View)으로 분리하여, 데이터베이스의 독립성을 확보하기 위한 방법

• 사용자/ 설계자/ 개발자가 DB를 보는 관점에 따라서, DB를 기술하고 관계를 정의한 ANSI 표준
• 3층 스키마 구조 : 사용자 - 외부/ 설계자 -개념/ 개발자 - 내부
  외부스키마 :
  - 사용자 관점
  - 업무상 관련있는 접근
  -관련 DB의 뷰를 표시
  - 응용 프로그램이 접근하는 DB 정의
  개념 스키마
  - 설계자 관점
  - 사용자 전체 집단의 DB 구조
  - 전체 DB 내의 규칙, 구조 표현
  - 통합 데이터 베이스 구조
  내부 스키마
  - 개발자 관점
  - 물리적 저장 구조
  - 데이터 저장 구조, 레코드 구조, 필드 정의, 인덱스 등
  
  
• 3층 스키마 독립성 : 논리적 독립성 & 물리적 독립성
   - 논리적 독립성 : 개념 스키마가 변경되어도 외부 스키마에 영향 X
   - 물리적 독립성 : 내부스키마가 변경되어도 개념 스키마에 영향 X
   - 독립성 확보시 장점: 데이터 복잡도 증가, 데이터 중복 제거, 사용자 요구사항 변경에 대응력 향상, 관리, 유지보수 비용 절감
  
  

[3] 엔터티 (Entity)

(1) 엔터티 - 업무에서 관리해야 하는 데이터

• 정보가 저장될 수 있는 장소, 사람, 사건, 개념 물건 등(Thomas Bruce, 1992)
• 고객의 비즈니스 프로세스에서 관리, 저장되어야 하는 정보를 추출
• 예를 들어, 고객이 회원가입을 하여 계좌를 개설하는 비즈니스 프로세스 => 고객, 계좌 엔터티 도출
• 엔터티는 다른 개체와 확연히구분되는 특성 가짐 -> 모델의 독립성을 향상 시킴

 

• 엔터티 특징 : 식별자/ 인스턴스 집합/ 속성/ 관계/ 업무
  식별자 - 유일한 식별자가 있어야함 (ex. "고객"의 회원 ID, "계좌"의 계좌번호 등)
  인스턴스 집합 - 2개 이상의 인스턴스가 있어야 함 (ex. "고객" 엔터티의 경우 고객 정보 2명 이상)
  속성 - 반드시 속성을 가지고 있어야함 (ex. "계좌"의 계좌번호, 담당자 등)
  관계 - 다른 엔터티와 최소 1개 이상의 관계 (ex. "고객"은 "계좌"를 개설)
  업무 - 엔터티는 업무에서 관리되어야 하는 집합 (ex. "고객", "계좌")

테이블 = 릴레이션 - 릴레이션에 기본키, 제약조건을 설정하면 테이블

Relationship - 릴레이션 간의 관계

인스턴스 - 릴레이션이 가질 수 있는 값(데이터셋에서 행의 개수)

 

(2) 엔터티 종류 : 유무형에 따라서 - 유형/개념/사건 & 발생시점에 따라서 - 기본/중심/행위

• 물리적 형태의 존재여부에 따라서 : 유형 엔터티/ 개념 엔터티/ 사건 엔터티
  유형 엔터티:
  - 업무에서 도출됨
  - 지속적으로 사용됨
  - ex. "고객", "사원" 등
  개념 엔터티:
  - 물리적 형태 없음
  - 개념적으로 사용됨
  - ex. "거래소 종목", "보험상품" 등
  사건 엔터티:
  - 비즈니스 프로세스 실행하면서 생성됨
  -ex . "주문", "수수료 청구" 등
  
  
• 발생 시점에 따라서 : 기본 엔터티/ 중심 엔터티/ 행위 엔터티
  기본 엔터티  = 키 엔터티:
  - 다른 엔터티의 도움없이 생성됨
  - 다른 엔터티로부터 영향 받지 않음
  - 독립적으로 생성되는 엔터티
  - Ex. "고객", "부서", "상품" 등
  중심 엔터티 = 메인 엔터티:
  - 키와 행위의 중간 (업무처리의 중심)
  - 기본 엔터티로부터 발생/파생됨
  - 행위 엔터티를 생성함
  - ex. "계좌", "주문", "주문취소"
  행위 엔터티
  - 2개 이상의 엔터티로부터 발생
  - 업무처리 중에 발생되는 엔터티
  - 자주 변경됨 & 지속적으로 정보 추가됨 -> 데이터양이 가장 많을 것으로 예상됨
  - ex. "주문 이력", "취소 이력" 등

[4]  속성 ( Attribute)

(1) 속성 - 업무에서 필요한 정보인 엔터티가 가지는 항목, 인스턴스의 구성요소

• 속성은 사물의 본질/ 성질/ 특징을 의미하며, 중복된 값이 존재할 수 있음
  
  
• 속성명 유의사항
  - 속성명은 업무에서 사용하는 명칭을 사용함
  - 속성명은 데이터 모델 내에서 유일해야 함
  - 속성명은 서술어, 약어를 지양해야 함
  
  
• 속성 Attribute
  - 업무에 필요한 정보를 저장
  - 인스턴스의 구성요소
  - 더 이상 분리되지 않음
• 속성의 특징
  - 속성은 1개의 값만 가짐
  - 업무에서 관리되는 정보
  - 주식별자에게 함수적으로 종속됨
  (기본키 변경 -> 속성값 변경)
• 도메인 Domain
  - 하나의 속성이 가질 수 있는 모든 원자들의 집합

(2) 속성 종류 - 분해여부에 따라서 - 단일/ 복합/ 다중값 & 특성에 따라서 - 기본/ 설계/ 파생

• 분해 여부에 따라서 : 단일 속성/ 복합 속성/ 다중값 속성
  • 단일 속성
    - 하나의 의미로 구성됨
    - ex. "회원 ID", "이름" 등
  • 복합 속성
    - 여러 의미가 있음
    - ex. "주소", "주민번호" 등
  • 다중값 속성
    - 속성에 여러 개의 값을 가질 수 있음 => 엔터티로 분해됨
    - "상품 리스트" 등
• 특성에 따라서 : 기본 속성/ 설계 속성/ 파생 속성
  • 기본 속성
    - 비즈니스 프로세스에서 도출됨
    - 본래의 속성
    - ex. "회원 ID", "이름", "계좌번호" 등
  • 설계 속성
    - 데이터 모델링 과정에서 발생함
    - 유일한 값을 부여
    - ex. "지점코드", "상품코드", "과목코드" 등
  • 파생 속성
    - 다른 속성에 의해 만들어짐
    - ex. "합계", "평균", "중앙값" 등

[5] 관계 (Relationship)

 

(1) 관계 - 엔터티 간의 관련성

• 관계 종류: 존재 관계 & 행위 관계
  • 존재 관계
    - 엔터티 간의 상태
    - ex. "고객"과 "관리점"은 존재 관계, 고객이 가입하면, 관리점이 할당되어 관리함.
  • 행위 관계
    - 엔터티 간에 어떤 행위가 있음
    - ex. "계좌"와 "주문이력"은 행위 관계, 증권회사는 계좌를 개설하고 주문을 발주함.
• 필수적 관계 & 선택적 관계
  • 필수적 관계 ( 표현 : | )
    - 반드시 하나가 있어야 함
    - ex. "고객" 엔터티가 있어야, "계좌" 엔터티 개설 가능
  • 선택적 관계 ( 표현 : O )
    - 없을 수도 있는 관계
    - ex. "고객"이 있지만 "계좌"는 없을 수도 있는 상황
• 관계 차수 (Cardinality) : 2개 엔터티 간 관계에 참여하는 수
• 카디널리티 (Cardinality) : 하나의 릴레이션에서 튜플의 전체 개수
  • 1 대 1 관계
    - 완전 1대1 : 1개 엔터티에 관계되는 엔터티의 관계가 1개이며, 반드시 존재함
    - 선택적 1대1 :  관계가 1개이거나 없을 수 있음
  • 1 대 N 관계
    - 엔터티에 행이 1개 있을 때, 다른 엔터티의 값이 여러 개 있는 관계
    - ex. "고객"은 "계좌"를 여러 개 개설 가능
  • M 대 N 관계
    - 2개 엔터티가 서로 여러 개의 관계를 가짐 => 1 대 N, N 대 1로 해소해야 함
    - ex. "학생"과 "과목"의 관계 => "수강" 엔터티를 추가 도출하여 해소

(2) 식별 관계와 비식별 관계

• 강한 개체 & 약한 개체
  • 강한 개체 Strong Entity
    - 다른 개체에게 지배/ 종속되지 않음
    - 독립적으로 존재하는 개체
  • 약한 개체 Weak Entity
    - 다른 개체에 의존함
    - 다른 개체의 존재에 약한 개체의 존재가 달려 있음
• 식별 관계 & 비식별 관계
  • 식별 관계 (Identification Relationship)
    - 실선으로 표현 (강한 연결관계)
    - 강한개체의 기본키를 다른개체의 기본키 중 하나로 공유함
    - 강한개체의 기본키 값이 변경되면, 식별관계에 있는 엔터티의 값도 변경됨
    - 기본키를 공유받은 다른개체는 약간개체가 된다.(독립적으로 존재 불가능)
  • 비식별 관계 (Non-Identification Relationship)
    - 점선으로 표현 (약한 연결관계)
    - 강한 개체의 기본키를 다른개체의 일반키로 공유함
    - 다른 엔터티의 기본키가 아닌 칼럼으로 공유 (단순한 외래키로 참조함)
    - 기본키를 공유받은 다른개체는 약한개체가 아님 (독립적으로 존재 가능)

[6] 엔터티 식별자 (Identifier)

(1) 식별자 - 엔터티를 대표할 수 있는 "유일성"을 만족하는 속성

• 식별자는 최소성 / 유일성 / Not Null을 만족하고, 해당 엔터티를 대표할 수 있어야 함
• 식별자 예시 : 회원ID, 계좌번호, 주민등록번호, 여권번호, 종목번호, 과목번호 등
  
  
• 데이터베이스 키(Key) : 기본키/ 후보키/ 슈퍼키/ 대체키/ 외래키
  • 기본키(Primary Key) : 후보키들 중에서 엔터티를 대표하는 키
  • 후보키(Candidate Key) : 유일성 만족 O, 최소성 만족 O
  • 슈퍼키(Super Key) : 유일성 만족 O, 최소성 만족 X
  • 대체키(Alternative Key) : 여러 후보키들 중 기본키 선정하고 남은키
  • 외래키(Foreign Key) : 하나 or 다수의 다른 테이블의 기본키 필드
• 주식별자 = 기본키 = Primary Key(PK) : 최소성/ 대표성/ 유일성/ 불변성 만족
  • 최소성 : 꼭 필요한 최소의 속성으로 구성되어야 함
  • 대표성 : 기본키는 엔터티를 대표할 수 있어야 함
  • 유일성 : 엔터티의 인스턴스를 유일하게 식별함
  • 불변성 : 기본키는 자주 변경되지 않아야 함
• 외래키 : 하나 혹은 다수의 다른 테이블의 기본키 필드
  - 참조무결성을 확인하기 위해 사용되는 키( 참조 무결성 = Referential Integrity)
  - 허용된 데이터 값만 저장하기 위해 사용되는 키

(2) 식별자 종류 - 대표성 여부/ 생성 여부/ 속성의 수/ 대체 여부에 따라 식별자를 분류함

• 대표성 여부에 따라 - 주식별자/ 보조식별자
• 생성 여부에 따라 - 내부식별자/ 외부식별자
• 속성의 수에 따라 - 단일식별자/ 복합식별자
• 대체 여부에 따라 - 본질 식별자/ 인조 식별자

대표성 여부

• 주 식별자
  - 유일성, 최소성 만족
  - 엔터티를 대표함
  - 다른 엔터티와 참조 관계로 연결될 수 있음
• 보조 식별자
  - 유일성, 최소성 만족
  - 대표성 만족 X

생성 여부

• 내부 식별자
  - 엔터티 내부에서 스스로 생성됨
  - ex. 부서코드, 주문번호 등
• 외부 식별자
  - 다른 엔터티와의 관계로 인해 생성됨

속성의수

• 단일 식별자
  - 1개의 속성으로 구성됨
  - ex. 고객 엔터티에서 회원ID
• 복합 식별자
  - 2개 이상의 속성으로 구성됨

대체 여부

• 본질 식별자
  - 비즈니스 프로세스에서 생성됨
• 인조 식별자
  - 유일한 값을 만들기 위해 인위적으로 생성
  - 최대한 범용적인 값을 사용