[교육] 실전! 데이터모델링

팀 수석님께서 데이터 모델링을 주제로 사내교육을 진행하셔서 참여할 수 있는 기회가 생겼다. 참여형 실습도 있고 완전 유익하고 재밌는 교육이라고 하셔서 기대를 잔뜩 하고 갔다.

학교에서 데이터베이스 설계 수업 때 배운 내용도 새록새록 생각이 나고 최근에 계속 모델링 작업을 하고 있어서 내용이 더 잘 들리기도 하고, 현업 포인트까지 알 수 있는 값진 시간이었다.

다른 부서분들을 만나는 자체도 재밌었는데 다들 잘 참여해주시고, 얘기도 잘 통해서 즐거운 시간이었다. 특히 실습에서 작은 모델들이 모여서 마지막에 하나의 모델로 탄생할 때 감동이었다..🥺 (수석님 존경합니다..)

 

데이터 표준화의 기본

데이터가 중요하다!

• 비즈니스의 목적이 바뀌지 않는 한, 중요 데이터는 변하지 않는다.
• 데이터 구조를 만드는게 개발의 도구일까?
• 데이터가 목적일 수 있다. 비즈니스 데이터가 그만큼 중요하다.
• 모델링을 할 때 어떤 점을 주안점으로 둘까?
  • 전략과 프로세스가 바뀌어도 데이터는 변하지 않는다
  • 데이터만 봐도 업무 규칙을 알 수 있게
    예) 고객 상품 주문 결제 계약 -> 프로세스나 툴이 바뀌어도 모델 구조가 바뀌지 않게 -> 독립적이고 안정적이게

 

데이터 모델링의 목적

• 일관성, 무결성, 정확성이 보장된 신뢰할 수 있는 고품질 데이터
• 가치 있는 정보, 최상의 성능
  • 데이터 규칙에 대한 명시적인 의사소통의 도구
    예) 만약 내 집을 짓는다면...? 정확한 제대로 된 설계 도면 인력 물량 공사진행 시공

 

데이터 모델링의 절차

개념

• 논리 모델링(비즈니스 중심)
• 물리 모델링(성능 중심) : DBMS 특성을 고려해서 성능, 주요 인덱스 및 파티션 설계
• DB구축 : DDL 작성, 물리 DB 구축, 마이그레이션

데이터 표준 (용어, 도메인, 코드)

 

데이터운영팀에서 검수 중인 것

• 논리와 물리 모델링의 결과에 표준화를 적용 -> DA (사람과 가깝고 좀 더 논리적인 부분)
• 인덱스 설계, 파티션 설계 ~ DB 구축 -> DBA (DBMS와 가까운 사람들, 좀 더 물리적인 부분)

 

논리 모델링의 기본

검수 시 가장 말씀 드리는 3가지

• 시간적으로 달라지는 절차적 사고보다는 집합적 사고
• 중복과 불일치는 NO
• 애매함 < 명확함

 

논리 모델의 구성 요소 - 1

• 엔터티 : 업무가 다루는 어떤 것
• 관계 : 업무가 다루는 것들 사이에 존재하는 연관
• 속성 : 각 사물(엔터티)이 가지고 있는 상세한 특성

 

논리 모델의 구성 요소 - 2

• 예) 은행
  • 엔터티 : 고객 계약 상품 직원
  • 관계 : 계약의 주체, 계약의 대상, 상품담당자, ...
  • 속성 : 세부 속성들이 필요하고

 

논리 모델의 구성 요소 - 3

• ERD를 그린다면
  • 체크리스트를 확인해야 함
    예) 엔터티 : 서비스에서 관리할 필요가 있나? 관리하려는 데이터의 범위는 어디까지? 엔터티인지 속성인지 관계인지

 

논리 모델링의 기본

• ERD 표기법
  • 사내에서 사용하는 툴 : PowerDesigner (IE법 사용, ER-Win도 있음)
  • Barker법 툴 : DA# (집합 개념을 조금 더 나타낸다는 점)

 

관계의 표현 - 1

• 카디널리티(1:1, 1:다, ...), 식별성(식별자 상속, 일반속성 상속), 선택성(0개 nullable 설정)
• 계층, 순환, BOM / Barker법 : 배타관계

 

관계의 표현 - 2

• 부서와 사원 관계의 예시
  • 식별 상속 : 한 명의 사원은 여러 부서에 소속될 수 있음 (사원 엔터티의 도출 필요)
  • 비식별 상속 : 한 명의 사원은 하나의 부서에 소속될 수 있음

겸직 부서 - 사원소속부서 - 사원

 

관계의 표현 - 3

• 직접 종속 관계 만을 표현, 간접 종속 관계는 표현하지 않음 (부모-자식 간만 표현하면 됨)
• 두 엔터티 간에 둘 이상의 관계가 존재할 수 있음 -> 관계명 표현, 컬럼명 수식어(역할 명 role name) 사용
• 가능한 모든 관계를 표현
• 너무 많은 관계선은 피하기 위해 뺄 수도 있음 (공통코드 테이블 등)

데이터 표준화의 기본

• 일관성 유지
• 가독성 강화
• 명확하고 신속한 의사소통, 원하는 시기에 정확한 정보 전달 (개발까지) // 데이터 활용도 증가 정제 비용 감소, 데이터 품질 향상
• 표준화는 대형 시스템에서는 표준화 담당자가 따로 있을 정도로 어려운 부분

 

단어

표준 단어

• DB 오브젝트의 이름 부여 시 사용하기 위한 원자 단위(최소 의미 단위)의 표현을 미리 정해 놓은 것
• 우리 회사는 전사 표준이 따로 있지는 않음, 우리 회사의 경우 다양한 서비스가 있기 때문에 전사 표준 관리는 어려움, 우리 회사 특성상 서비스 별 표준, 조직별 표준이 있음
• 표준 단어(영문, 한글)에는 띄어쓰기, /, _ 등 특수 문자 사용 금지
• 영문 단어는 약어 혹은 full 단어로 정하여 사용
  • 오라클 쓸 때는 컬럼명 길이 제한이 있어서 약어를 많이 썼는데, 요즘엔 mysql 쓰니까 full 단어로 씀
• 복합 단어는 두 개 이상의 단어를 결합하여 하나의 단어로 사용(blacklist, zipcode)

 

표준 용어

• 표준 단어를 조합하여 엔터티명(테이블명)과 속성명(컬럼명)에 사용되는 용어를 구성함
• 동일한 데이터 집합은 동일한 용어를 사용
• 용어의 마지막에는 분류어에 속하는 단어를 사용 (수 count, 일자 date ymd, datetime ymdt 등)

 

도메인

• 속성에 대한 성질을 그룹핑한 개념
• 동일 성질을 가진 컬럼의 데이터 타입 및 데이터 길이를 일관되게 관리함
• 여러 시스템에서 사용되면 공통 도메인을 선정해서 쓰기도 함
• 텍스트, 숫자 도메인은 최대한 통합

분류어 -> 도메인 -> 데이터 타입(길이)

 

코드

• 특수도메인
• 특정 도메인 값(코드 값)이 미리 정의되어 있는 도메인
• 공통코드와 목록성코드(조직코드,...)
  • 3개 이상의 구분 값을 사용하는 경우 '코드' 도메인 사용
  • Yes/No 혹은 True/False의 2가지 값 만을 사용하는 경우 '여부' 도메인 사용
  • 기본 : Not Null, default 값 정의를 권장함

 

명명 규칙

• 엔터티 명명
  • 단수형
  • 부모 엔터티와 강하게 엮인 자식 엔터티는 가급적 부모 엔터티의 이름을 상속받음 (게시물첨부파일, 게시물스크랩)
  • 관계 엔터티의 경우, 두 엔터티의 이름을 상속받아 명명(주문 상품 -> 주문상품)
  • 통계성 테이블의 경우, 통계 주기와 기준이 나타나도록 명명
  • 엔터티 명 마지막 단어에서 엔터티의 유형을 나타내도록 정함
  • 바람직하지 않은 예 : 회원리스트, 주문처리, 급여관리, 쿠폰목록 -> 데이터 관점에서 생각하고, 기능이나 화면의 이름은 필요없음

• 속성 명명
  • 단어의 뒤를 먼저 보면 되도록 명명

• 표준 용어 사전
  • 각 서비스에 해당하는 단어, 도메인, 코드 표준이 정의되면 이를 바탕으로 표준 용어를 구성 함
  • 업무적으로나 DBMS 적용 상 무리가 없는지 검토
  • 누락된 단어 및 도메인, 코드 등이 없는지 확인하고 추가 보완 작업을 수행 함

 

물리 모델링을 하다가 마주치는 고민들

정규화 vs. 반정규화

• 정규화 : 중복을 안 만들고자 하는 구조
• 반정규화
  • 물리모델링 시 정규화된 논리모델을 조정하여 반정규화를 하는 경우가 있음
  • 조상테이블 속성을 자식테이블에 갖다놓는..
  • 테이블의 통합/분리, 속성의 추가, 관계의 중복 등이 포함
  • 데이터의 정합성과 무결성의 유지를 위한 방안과 노력이 반드시 필요함
  • 조회의 성능과 개발의 편의를 위해 반정규화를 한 경우, 그에 따라 변경 작업시의 성능이 저하되는 경우가 많으므로 트레이드-오프를 따져서 적용해야 함

방법

테이블 반정규화

1. 테이블 통합
2. 1:1, 1:N, 수퍼타입/서브타입
3. 테이블 분할
   수직, 수평
4. 테이블 추가
   통계, 이력, 부분-업데이트가 자주 발생하면 따로 떼어내기, 복제-저장소가 다른 경우 원격지에 있는걸 가져다 놓기

컬럼 반정규화

1. 중복컬럼 추가
   테이블 간의 조인을 감소시키기 위해서, 그 컬럼이 잘 바뀌지 않는다는 가정 하에
2. 추출(derived)컬럼 추가
   매번 계산되지 않도록 미리 계산해서 갖다놓기(주문총금액)
3. 이력테이블 컬럼 추가
   최근 값에 대한 컬럼을 미리 추가해놓기

관계 반정규화

• 관계의 중복

• 하기 전에
  • 다른 방법이 있는지 고려해보고 도저히 안 되면 반정규화하기
• 하고 나서
  • ERD 등에 해당 내용을 공유하기

통합 vs. 분리

논리모델에서 설계한 수퍼타입과 서브타입을 물리모델로 전환할 경우 트랜잭션 패턴 및 생성되는 데이터 건수 등에 따라 테이블의 통합 혹은 분리를 검토하여 결정

 

트랜잭션 유형에 의한 결정

1. 개별 트랜잭션 발생 유형
   공용 컬럼을 최대한 도출해서 수직분할 (결제수단코드- ...) or 통합 (모든 값을 한 테이블에, join이나 union all이 너무 많이 발생할 것 같을 때)
2. 수퍼타입+서브타입 트랜잭션 발생 유형
   수평분할 (주문번호 - 카드결제내역 / 휴대폰결제내역 / 계좌이체결제내역) 결제번호가 겹치는 문제가 있을 수 있음

통합을 고려해 보게 되는 경우

1. 식별자가 동일 할 때
2. 관리하는 정보가 유사할 때
3. 자주 join 되거나 union all 되는 경우
4. ARC 관계로 정의되는 경우, 상속이 계속 된다면 부모 테이블의 통합이 가능한지 검토

 

인조 키 vs. 본질 키

인조 키 vs. 본질 키 - 1

PK 선정

• 그 중 식별자 정의, 생성 주체의 단위를 정하는 것
• 본질식별자 혹은 인조식별자 사용 여부도 논리 모델링 단계에서 결정하는 것이 바람직함
• 특징
  • 유일성
  • 안정성 : 절대 변경되지 않아야 함(~명 등 텍스트 성 정보는 하지 않기)
  • 최소성 : 복합 식별자로 구성된 경우 유일성에 기여하지 않는 속성은 제외하고 최소의 조합으로 함
  • 활용성 : 업무에서 가장 많이 사용되는 속성 선택, PK는 자식 테이블에 상속이 됨
  • 보안성 : 주민등록번호, 여권번호 등

 

인조 키 vs. 본질 키 - 2

본질식별자

• 해당 엔터티의 의미상의 주어, 인스턴스를 유일하게 식별하는 최소한의 속성 조합
• 집합의 인스턴스가 생성되는 단위

인조식별자

• 쿼리 복잡도 감소
• 검색에 활용 불가 -> 반정규화의 원인이 되는 경우가 있음
• 중요 데이터의 중복 가능성

인조 키 vs. 본질 키 - 3

• 본질식별자 사용을 먼저 고려
• 인조식별자를 사용한다면, 하위 엔터티에서 다수의 조인이 발생하거나, 반정규화의 원인이 되기도 함
• 인조식별자를 선택하는 경우
  • 본질식별자가 식별자의 조건에 부합하지 않는 경우(로그 성격의 데이터를 보관하는 테이블, 본질식별자를 종종 수정해야 하는 경우)
  • 상속 시 식별자의 증가로 복잡도가 지나치게 증가하는 경우(mysql의 경우는 PK의 개수가 성능에 영향을 미침)
  • 타 영역에서 자주 참조하는 주요 엔터티의 식별자인 경우 인조 식별자의 사용을 검토해야 함
• ~번호, ~일련번호, ~ID를 구분해서 쓰기도 함

 

시스템 속성의 관리

• 모든 테이블에 공통으로 추가하여 관리할 필수 속성을 정의하는 것
• 데이터 추적 관리 용도, 마이그레이션 작업 시, 데이터 분리 보관 작업 시 등 중요한 기준 정보로 활용됨
• 주의 사항
  • 업무 용도로 사용하지 않는 것을 권장함(등록일시:데이터의 실제 Insert 일시와 가입일시는 구분해서 쓰기..)

 

이력의 관리의 형태

이력 관리의 형태 - 1

• 이력 관리 모델
  데이터 복구나 추적이나 고객 응대를 위해서
• 형태
  • 시점이력(변경된 시점에 대한..) 선분이력(유효시작일자, 이런 식으로 구간 관리)
  • 분리형 통합형
  • row column subject

 

데이터 모델 검수

앞을 내다보고, 나중에 관리 측면까지 고려함