팀 수석님께서 데이터 모델링을 주제로 사내교육을 진행하셔서 참여할 수 있는 기회가 생겼다. 참여형 실습도 있고 완전 유익하고 재밌는 교육이라고 하셔서 기대를 잔뜩 하고 갔다.
학교에서 데이터베이스 설계 수업 때 배운 내용도 새록새록 생각이 나고 최근에 계속 모델링 작업을 하고 있어서 내용이 더 잘 들리기도 하고, 현업 포인트까지 알 수 있는 값진 시간이었다.
다른 부서분들을 만나는 자체도 재밌었는데 다들 잘 참여해주시고, 얘기도 잘 통해서 즐거운 시간이었다. 특히 실습에서 작은 모델들이 모여서 마지막에 하나의 모델로 탄생할 때 감동이었다..🥺 (수석님 존경합니다..)
데이터 표준화의 기본
데이터가 중요하다!
- 비즈니스의 목적이 바뀌지 않는 한, 중요 데이터는 변하지 않는다.
- 데이터 구조를 만드는게 개발의 도구일까?
- 데이터가 목적일 수 있다. 비즈니스 데이터가 그만큼 중요하다.
- 모델링을 할 때 어떤 점을 주안점으로 둘까?
- 전략과 프로세스가 바뀌어도 데이터는 변하지 않는다
- 데이터만 봐도 업무 규칙을 알 수 있게
예) 고객 상품 주문 결제 계약 -> 프로세스나 툴이 바뀌어도 모델 구조가 바뀌지 않게 -> 독립적이고 안정적이게
데이터 모델링의 목적
- 일관성, 무결성, 정확성이 보장된 신뢰할 수 있는 고품질 데이터
- 가치 있는 정보, 최상의 성능
- 데이터 규칙에 대한 명시적인 의사소통의 도구
예) 만약 내 집을 짓는다면...? 정확한 제대로 된 설계 도면 인력 물량 공사진행 시공
- 데이터 규칙에 대한 명시적인 의사소통의 도구
데이터 모델링의 절차
개념
- 논리 모델링(비즈니스 중심)
- 물리 모델링(성능 중심) : 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:1, 1:N, 수퍼타입/서브타입
- 테이블 분할
수직, 수평 - 테이블 추가
통계, 이력, 부분-업데이트가 자주 발생하면 따로 떼어내기, 복제-저장소가 다른 경우 원격지에 있는걸 가져다 놓기
컬럼 반정규화
- 중복컬럼 추가
테이블 간의 조인을 감소시키기 위해서, 그 컬럼이 잘 바뀌지 않는다는 가정 하에 - 추출(derived)컬럼 추가
매번 계산되지 않도록 미리 계산해서 갖다놓기(주문총금액) - 이력테이블 컬럼 추가
최근 값에 대한 컬럼을 미리 추가해놓기
관계 반정규화
- 관계의 중복
- 하기 전에
- 다른 방법이 있는지 고려해보고 도저히 안 되면 반정규화하기
- 하고 나서
- ERD 등에 해당 내용을 공유하기
통합 vs. 분리
논리모델에서 설계한 수퍼타입과 서브타입을 물리모델로 전환할 경우 트랜잭션 패턴 및 생성되는 데이터 건수 등에 따라 테이블의 통합 혹은 분리를 검토하여 결정
트랜잭션 유형에 의한 결정
- 개별 트랜잭션 발생 유형
공용 컬럼을 최대한 도출해서 수직분할 (결제수단코드- ...) or 통합 (모든 값을 한 테이블에, join이나 union all이 너무 많이 발생할 것 같을 때) - 수퍼타입+서브타입 트랜잭션 발생 유형
수평분할 (주문번호 - 카드결제내역 / 휴대폰결제내역 / 계좌이체결제내역) 결제번호가 겹치는 문제가 있을 수 있음
통합을 고려해 보게 되는 경우
- 식별자가 동일 할 때
- 관리하는 정보가 유사할 때
- 자주 join 되거나 union all 되는 경우
ARC 관계로 정의되는 경우, 상속이 계속 된다면 부모 테이블의 통합이 가능한지 검토
인조 키 vs. 본질 키
인조 키 vs. 본질 키 - 1
PK 선정
- 그 중 식별자 정의, 생성 주체의 단위를 정하는 것
- 본질식별자 혹은 인조식별자 사용 여부도 논리 모델링 단계에서 결정하는 것이 바람직함
- 특징
- 유일성
- 안정성 : 절대 변경되지 않아야 함(~명 등 텍스트 성 정보는 하지 않기)
- 최소성 : 복합 식별자로 구성된 경우 유일성에 기여하지 않는 속성은 제외하고 최소의 조합으로 함
- 활용성 : 업무에서 가장 많이 사용되는 속성 선택, PK는 자식 테이블에 상속이 됨
- 보안성 : 주민등록번호, 여권번호 등
인조 키 vs. 본질 키 - 2
본질식별자
- 해당 엔터티의 의미상의 주어, 인스턴스를 유일하게 식별하는 최소한의 속성 조합
- 집합의 인스턴스가 생성되는 단위
인조식별자
- 쿼리 복잡도 감소
- 검색에 활용 불가 -> 반정규화의 원인이 되는 경우가 있음
- 중요 데이터의 중복 가능성
인조 키 vs. 본질 키 - 3
- 본질식별자 사용을 먼저 고려
- 인조식별자를 사용한다면, 하위 엔터티에서 다수의 조인이 발생하거나, 반정규화의 원인이 되기도 함
- 인조식별자를 선택하는 경우
- 본질식별자가 식별자의 조건에 부합하지 않는 경우(로그 성격의 데이터를 보관하는 테이블, 본질식별자를 종종 수정해야 하는 경우)
- 상속 시 식별자의 증가로 복잡도가 지나치게 증가하는 경우(mysql의 경우는 PK의 개수가 성능에 영향을 미침)
- 타 영역에서 자주 참조하는 주요 엔터티의 식별자인 경우 인조 식별자의 사용을 검토해야 함
- ~번호, ~일련번호, ~ID를 구분해서 쓰기도 함
시스템 속성의 관리
- 모든 테이블에 공통으로 추가하여 관리할 필수 속성을 정의하는 것
- 데이터 추적 관리 용도, 마이그레이션 작업 시, 데이터 분리 보관 작업 시 등 중요한 기준 정보로 활용됨
- 주의 사항
- 업무 용도로 사용하지 않는 것을 권장함(등록일시:데이터의 실제 Insert 일시와 가입일시는 구분해서 쓰기..)
이력의 관리의 형태
이력 관리의 형태 - 1
- 이력 관리 모델
데이터 복구나 추적이나 고객 응대를 위해서 - 형태
- 시점이력(변경된 시점에 대한..) 선분이력(유효시작일자, 이런 식으로 구간 관리)
- 분리형 통합형
- row column subject
데이터 모델 검수
앞을 내다보고, 나중에 관리 측면까지 고려함