sqld 1과목. 데이터 모델링의 이해

데이터 모델링의 이해

• 데이터 모델링 개요
• 엔터티
• 속성
• 관계 with ERD
• 식별자
• 성능 데이터 모델링
• 정규화
• 반정규화
• 기타 말문제 개념 정리

 

1) 데이터 모델링의 특징

• 추상화 : 현실 세계를 일정한 형식에 맞춰 표현하기 위함
• 정확화 : 누구나 이해할 수 있도록 현상을 기술
• 단순화 : 복잡한 현실을 이해하기 쉽게 제한된 언어와 표기법으로 단순하게 표현하기 위함
  >>> 현실세계를 단순하게 추상화하여 정확하게 공유하는 작업이 데이터 모델링!!
• 정보시스템을 구축하기 위한 업무 분석 기법
• 현실세계의 데이터에 대해 약속된 표기법으로 표현
• 데이터베이스를 구축하기 위한 분석과 설계를 위한 과정

 

데이터 모델링의 유의사항

• 중복성 :  중복을 최소화해야 함(같은 정보를 여러번 저장하는 것은 지양)
• 비유연성 : 데이터의 정의 <=> 데이터 사용 프로세스, 프로그램 <=> 테이블 간의 연계성을 줄여서, 
           데이터 혹은 프로세스의 변화가 데이터베이스에 중대한 변화를 초래하지 않도록 유연하게 관리해야 함
• 비일관성 : '약속된 표기법'을 준용하는 등 업무를 명확하게 정의해서 정보 관리의 일관성을 최대화 해야함

 

데이터 모델링의 단계

• 개념적 데이터 모델링 : 추상화 수준이 높음, 전사적 모델링 시 많이 함, 포괄적 수준의 모델링
• 논리적 데이터 모델링 : Key, 속성, 관계 등을 정확히 기술하는 모델링
• 물리적 데이터 모델링 : 실제로 데이터 베이스에 이식 가능하도록 저장, 성능 등 물리적인 특성을 고려한 모델링

 

데이터베이스 스키마 구조 3단계

• 외부스키마 : [사용자 관점] 응용프로그램을 사용하는 개별 사용자 관점으로 데이터베이스를 정의하는 구조
• 개념스키마 : [통합 관점] 모든 사용자의 관점을 통합한 조직 전체의 관점의 통합적 데이터 베이스 구조
• 내부스키마 : [개발자 관점] 어떤 데이터를 어떻게 저장할 것인지 데이터베이스의 물리적 저장 구조

 

데이터의 구성

 

엔터티(Entity) 중요!!!

• 해당 업무에서 필요하고 관리해야하는 정보여야 함
• 유일한 식별자에 의해 식별이 가능해야 함 (ex 회원 테이블 상 고객번호)
• 하나의 엔터티는 반드시 2개 이상의 인스턴스를 가져야 함
• 하나의 엔터티는 반드시 속성이 있어야 함 (2개 이상)
• 하나의 엔터티는 반드시 1개 이상의 관계가 있어야 함 (통계성, 코드성 엔터티 제외)

 

- 발생 시점에 따른 엔터티 분류

• 기본엔터티 : 독립적 생성되는 엔터티
• 중심엔터티 : 기본 엔터티로부터 발생하고 행위 엔터티를 생성함
• 행위엔터티 : 기본, 중심 엔터티 등 2개 이상의 엔터티로부터 발생함

 

- 물리적 형태에 따른 엔터티 분류

• 유형엔터티 : 물리적 형태가 있는 엔터티
• 개념엔터티 : 물리적 형태는 없지만 관리해야하는 개념적 정보
• 사전엔터티 : 비즈니스 프로세스 중 생기는 엔터티

 

 

속성(Column)

• 인스턴스에서 관리하고자 하는 의미가 더 이상 부리되지 않는 최소의 데이터 단위
• 1개의 속성은 1개의 속성값을 가진다
• 기본속성 / 설계속성 / 파생속성
  - 설계 속성 : 코드성 컬럼, 일련번호 등 규칙화를 위한 속성
  - 파생 속성 : 계산된 값 (테이블 내에 적을수록 좋음)
  - 기본 속성 : 업무상 바로 정의가 가능한 속성(이름, 계좌번호, 주문일자..)

 

EX) 은행은 고객에게 지급되는 월단위 '이자'를 관리하고자 한다. 이때 이자는 어떤 속성일까? 파생속성

ex) 그렇다면, 예금 분류에 따라 관리되는 '이자율'은 어떤 속상일까? 기본속성

 

• 각 속성이 가질 수 있는 값의 범위를 속성의 '도메일'이라고 함 (데이터 타입, 크기, 제약사항 등 지정)
  ex) 은행계좌 라는 엔터티가 있을 때, 계좌명이라는 속성은 길이가 20자리 이내의 문자열로 정의

 

관계 with ERD(Entity-Relationship Model)

• 하나의 엔터티는 1개 이상의 관계를 가져야 함(통계성, 코드성 엔터티 제외)
• 관계의 구분 : 행위에 의한 관계, 존재에 의한 관계
  >> ERD 에서는 두 관계를 구분없이 동일한 표기법으로 표현함
  (단, 클래스다이어그램에서는 구분하여 연관관계와 의존관계로 실선과 점선의 표기법으로 다르게 표현함)

 

* 두 개의 엔터티 사이에서 관계를 도출할 때 체크해야 하는 사항

• 관심있는 연관규칙 여부
• 정보의 조합 여부
• 업무기술서, 장표에 관계연결을 가능하게 하는 동사 여부
• 업무기술서, 장표에 관계연결에 대한 규칙 서술 여부

 

* ERD 작성순서

1) 엔터티 도출 & 그리기

2) 엔터티 배치(가장 중요한 엔터티를 좌측 상단에 배치, 추가 발생하는 엔터티는 우측과 하단에 배치)

 

3) 엔터티 간의 관계를 설정

4) 엔터티 간의 관계명 기술

 

식별관계와 비식별관계!!!

 

5) 관계의 참여도 기술(1:1, 1:N, M:N)

6) 관계의 필수여부 기술(필수적 관계 : I, 선택적 관계 : O)

 

 

식별자 구분

 

대표성 여부

• 주식별자 : 유일성, 최소성, 대표성을 만족하는 식별자이며 타 엔터티와 참조 관계로 연결될 수 있다.(Primary Key)
• 보조식별자 : 유일성, 최소성은 만족하지만 대표성을 갖지 못하는 식별자이다.

속성의 수

• 단일 식별자
• 복합 식별자 : 2갸 이상의 속성을 구성된 식별자

 

 

스스로 생성 여부

• 내부 식별자 : 엔터티 내에서 생성된 식별자
• 외부 식별자 : 타 엔터티와의 관계를 통해 받아오는 식별자(Foreign Key)

대체 여부

• 본질 식별자 : 업무에 의해 만들어지는 식별자
• 인조 식별자 : 복잡한 원조 식별자 대신에 인위적으로 만들어진 식별자(ex. 일련번호)

 

주식별자

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

 

2) 데이터 모델과 성능

 

성능 데이터 모델링

• 데이터베이스의 성능 향상을 위해 분석/설계 단계부터 성능과 관련된 사항이 데이터 모델리에 반영되도록 하는 것
• 데이터의 증가가 빠를수록 성능 개선 비용이 증가함
• 설계단계부터 고려할 셩우 비용 최소화가 가능함

 

성능 데이터 모델링 순서

1. 데이터 모델링 시 정규화를 정확히 수행함
2. 데이터베이스 용량을 산정함
3. 데이터베이스에 발생하는 트랜잭션 유형을 파악함
4. 용량과 트랜잭션의 유형에 따라 반정규화를 수행함
5. 이력모델, PK/FK 조정, 슈퍼타입/서브타입 조정을 수행함

 

정규화란?

• 데이터를 분해하는 과정
• 목적 : 데이터의 중복을 최소화하고, 유연성을 가지며, 변경을 최소화하고, 데이터가 일관될 수 있도록 하는 방법
• 제 1~5 정규화가 있지만, 주로 1~3 정규화까지 수행함

 

* 제1정규화

• 기본키를 설정하는 과정
• 속성의 원자성과 엔터티의 유일성을 확보함
• 모든 속성이 식별자에 종속되어야 함
  X가 변하면 Y가 변한다(T는 X에 함수적으로 종속됨)
  식별자가 변하면 속성이 변함
• 속성값의 중복 여부 체크! (단일 -> 복합 순)

매장 코드와 메뉴 코드에 따라 가격이 변동되므로 매장 코드와 메뉴코드를 식별자로 선정

 

* 제2정규화

• 기본키가 2개 이상으로 구성될 경우 수행함
• 모든 속성(지역명, 점주명, 메뉴명, 출시일, 가격)이 식별자에 종속해야하며, 아니면 분해해야 함
• 부분함수 종속성을 분해함
• 주식별자 중 일부로부터 독립하여 1:M 의 관계로 재설계

 

* 제 3정규화

• 기본키 외에 컬럼간 종속성을 제거함
• 이행 함수 종속성 제거

 

반정규화

• 정규화를 했을 때 성능이 더욱 악화될 경우, 데이터의 중복을 허용하고 조인을 줄여서 성능을 향상시키는 방법

 

반정규화 기법(컬럼 & 테이블)

* 컬럼 추가 - 중복 컬럼 추가, 파생컬럼 추가(ex. 계산된 컬럼), 이력테이블 컬럼 추가, PK에 의한 칼럼 추가 등

ex) 중복 컬럼 추가
      A 테이블에 있는 a, b 정보를 조회할 때, C 테이블의 c 정보와 D 테이블의 d정보를 늘 함께 조회한다면?

     >>> 과도한 조인을 줄이기 위해 A 테이블에 c, d 컬럼을 추가하여 조회 성능을 향상시킨다.

 

ex) 파생컬럼 추가

      여러 테이블을 JOIN해서 얻을 수 있는 정보 값이 자주 사용된다면?

      >>> 미리 계산된 컬럼을 추가해둔다. ex) SUM(단기)

 

 

* 테이블 병밥 / 테이블 분할 / 테이블 추가

• 테이블 병합 : 1:1관계 테이블 병합, 1:M 관계 테이블 병합, 슈퍼/서브타입 테이블 병합
  * 슈퍼 타입(회웜) <=> 서브 타입(개인회원, 법인회원)
• 테이블 분할
  * 수직분할 : [a, b, c, d] 컬럼 -> [a,b] [c,d] 로 분리하여 보관
  * 수평분할 : 하나의 테이블에 있는 값을 기준으로 테이블 분할(Partition 기법)
  ex. 메일 쌒이는 고객별 위치 정보를 한 테이블에 넣어두면 엑세스 범위가 넓음 -> 연도별로 쪼개서 저장
• 테이블 추가 : 중복테이블, 통계테이블, 이력테이블, 부분테이블

 

기타 성능관련 말문제 개념 정리

 

1. 한 테이블에 너무 많은 칼럼이 존재하며 로우체이님이 발생하는 등 조회성능 저하가 발생한다면
=> 트랜잭션이 접근하는 컬럼 유형을 분석해 테이블을 분리하면, 디스크 I/O가 줄어서 성능이 향상될 수 있다.

2. WHERE문을 통해 조회를 할 때 자주 사용되는 PK 순으로 순서를 변경하고 인덱스를 생성하는 것이 성능에 유리할 수 있다
ex) WHERE 지역명 = '서울' AND 출시일 BETWEEN '20220101' AND '20220331'
-> (1) 상수값으로 조회하는 PK(2) 범위로 조회하는 PK 순
-> 앞쪽에 위치한 속성의 값이 가급적 '=', 최소한 범위를 나타내는 'BETWEEN', '<' '>'가 들어와야 인덱스를 사용할 수 있다

3. 트랜잭션의 통합 / 개별 처리 케이스
- 데이터 전체를 대상으로 일괄 처리하는데 테이블이 분리되어 개별로 관리하면 오히려 연산량을 늘릴 수 있고
- 데이터를 개별로 처리하는데 테이블은 하나로 통합되어 관리하면 불필요하게 많은 데이터의 집적으로 성능이 저하될 수 있음
-> 트랜잭션을 통합하여 처리하면 통합해두는 것이 성능에 좋고, 개별로 처리하면 개별로 유지하는 것이 좋다