데이터 모델링 기본 개념

 

좋은 모델이란

좋은 모델은 단순하고 명확한 모델입니다. 이론을 원칙으로 적절한 판단이 적용된 상식적인 모델을 의미합니다. 그리고 데이터 무결성이 보장되는 모델입니다. 무결성이 훼손되면 비즈니스 요구사항이 충족되어도, 빠른 성능이 보장되어도 좋은 모델이 될 수 없습니다.

 

무결성 > 비즈니스 요구사항, 빠른 성능

 

데이터 모델링 목표

무결성을 보장하는 데이터 모델을 구축하는 것입니다.

데이터 무결성 보존 원칙은 중복을 제거하는 것입니다. 중복되는 속성, 엔티티를 제거하는 것입니다.

 

좋은 모델은 비즈니스를 효율적으로 표현합니다.

비즈니스 수행에 필요한 데이터 요소만 들어갈 수 있도록 노력해야 합니다. 비즈니스 수행에 필요한 데이터가 누락되지 않도록 해야합니다.

좋은 모델은 기본적으로 모델 표현이 정확해야 합니다. ERD 표기법에 맞게 정확히 표현(엔티티, 속성, 관계)해야 좋은 모델입니다.

 

엔티티명이 애매하거나 관계가 불분명하고 가독성이 나쁘면 좋은 모델이 될 수 없습니다.

 

모델링은 왜 필요한가

사용자의 요구사항을 반영하는 과정이며 모델을 사용하는 사람들이 이해할 수 있도록 하기 위한 작업입니다. 

DB 구현 과정을 지원하고 애플리케이션 개발 중 모델의 변경을 최소화 하는 역할을 갖습니다.

 

좋은 모델러란?

기술적 기준은 명확합니다. 모델링 이론을 잘 알아야 합니다. 정규화를 무엇보다 깊게 이해하고 있어야 합니다.

테이블로 생성되는 물리 모델은 DB 구현과 연관이 깊어 RDBMS 이해도 높아야 합니다.

 

다음은 튜닝입니다. 데이터를 정확하고 빠르게 제공하기 위한 튜닝 요소을 적절히 모델링에 적용할 수 있어야 합니다.

 

분석력도 중요합니다. 속성 하나의 쓰임도 업무와 연관되어 분석할 수 없다면 좋은 모델러가 되기 어렵습니다.

속성 하나도 숙고하며 종합적으로 사고하며 판단하고자 노력한다면 분석력은 향상됩니다.

 

결국, 좋은 모델러가 되기 위해서는 업무에 대한 분석을 기반으로 데이터에 대한 분석을 진행합니다. 데이터 구조를 잡고 중복 속성을 제거합니다.

 

모델링의 목표는 결점이 없는 데이터가 되도록 모델링을 수행하는 것이 가장 우선시되어야 합니다.

 

정규화를 하는 것 때문에 성능이 나빠지는 건 아니라는 것을 분명히 인식해야 합니다.

 

성능은 무엇을 어떻게 조회하는지에 대한 밀접한 관련이 있습니다.

화면에서 보여지는 형태에 따라 성능 이슈가 발생할 수도 있습니다.

 

 

관계형 데이터 모델링

관계형 데이터베이스는 가로와 세로로 이루저니 테이블 2차원 데이터로 머리(Head) 부분과 어트리뷰트 몸통(Body) 부분인 튜플로 구분할 수 있고 튜플의 집합은 릴레이션 입니다.

 

튜플을 식별할 수 있는 유일한 어트리뷰트는 식별자 입니다.

 

이름, 주소와 같이 어트리뷰트(Attribute) 이름을 내포(Intension, Head) 라고 부릅니다.

실제 데이터(Data)는 외포 (Extension, Body) 라고 부릅니다.

릴레이션의 이름과 내포를 스키마라고 합니다.

 

릴레이션에서 튜플의 개수를 카디널리티라고 하며 어트리뷰트의 개수를 차수(Degree)라고 합니다. 차수가 1개 이상이고 카디널리티가 0개 이상이면 유효한 릴레이션 입니다.

 

튜플은 레코드(Record), 로우(Row), 인스턴스(Instance) 라고도 부르며 어트리뷰트는 컬럼(Column), 필드(Feild)라고 부릅니다.

 

데이터를 중복해서 저장하지 않도록 설계하는 것이 관계형 DB 설계의 핵심입니다.

 

가장 기본적인 제약은 릴레이션에서 각 튜플이 유일한 값이어야 합니다.

 

 

무결성 4가지

1. 엔티티 무결성

엔티티에 존재하는 모든 인스턴스는 고유해야 하며 NULL 값을 가지면 안된다는 것이가 무결성입니다.

한 엔터티에는 동일한 주 식별자가 존재할 수 없고, 주 식별자 속성은 Null 값을 허용할 수 없습니다.

 

2. 참조 무결성

Relation(관계)에서 관계선을 표현할 때는 참조 무결성을 기준으로 해야 합니다.

데이터 모델 관계 정의할 때 참조 무결성이 존재하지 않다면 관계를 정의해서는 안됩니다.

 

엔티티의 외래 식별자 속성은 참조되는 엔티티의 주 식별자 값과 일치하거나 Null 값이어야 참조 무결성입니다.

(외래 식별자 속성 값이 상위 엔티티의 인스턴스에 반드시 존재하거나 Null 이어야 합니다.)

 

참조 무결성은 두 엔티티의 연관된 인스턴스 사이에 일관성을 유지하기 위한 목적으로 제약을 사용합니다.

 

3. 도메인 무결성

도메인 무결성은 속성 값에 대한 제약입니다. 엔티티의 특정 속성 값은 같은 데이터 타입과 길이, 동일한 Null 여부, 동일한 기본 값, 동일한 값 허용 등 동일 범주의 값만 존재해야 하니다.

 

예를들어 이름 속성에 김씨, 이씨, 임씨.. 같은 값이 사용되어야 하는데 '12345' 같은 값이 사용되면 안됩니다.

전화번호 속성에 '031-000-0000', '경기도' 성격이 다른 데이터가 사용되어도 안됩니다.

 

4. 업무 무결성

업무 무결성은 기업에서 업무를 수행하는 방법, 데이터를 처리하는 규칙을 의미합니다.

예를 들어 "주문 금액이 1만원 이상이면 배송비가 무료입니다." 등과 같은 무결성입니다.

 

 

 

데이터 변경 규칙

무결성을 지키기 위한 규칙이 존재합니다.

 

1. 입력규칙

상위 엔티티에 해당되는 주 식별자 값이 존재해야지만 하위 엔티티의 외래 식별자에 입력이 가능합니다.

 

상위 엔티티에 해당되는 주 식별자 값이 없을 때,

 - 상위 엔티티에 주 식별자를 생성하고 나서 하위 엔티티의 외래 식별지에 입력합니다

 - 하위 엔티티의 외래 식별자에 기본 값으로 입력, 외래 식별자에 기본 값 설정이 되어있어야 합니다.

 - 하위 엔티티 외래 식별자에 Null 값으로 입력. 외래 식별자는 Null 허용 설정을 해야합니다.

 

2. 삭제규칙

상위 엔티티 주 식별자를 삭제할 때

 - 같은 값이 하위 엔티티의 외래 식별자에 없을 때만 상위 엔티티 주식별자 삭제가 허용됩니다.

 - 같은 값이 하위 엔티티의 외래 식별자에 존재하면 해당 값을 모두 삭제하고 상위 엔티티 주 식별자 삭제가 가능합니다.

 - 같은 값이 하위 엔티티의 외래 식별자에 존재하면 해당 값을 모두 기본 값으로 수정하고 상위 엔티티 주 식별자 삭제를 해야합니다.

 - 같은 값이 하위 엔티티 외래 식별자에 존재하면 해당 값은 모두 Null 값으로 수정하고 상위 엔티티 주 식별자 삭제가 가능합니다.

 

3. 수정 규칙

상위 엔티티의 주 식별자를 업데이트 할 때

 - 같은 값이 하위 엔티티 외래 식별자에 없을 때만 상위 엔티티 주 식별자 수정이 가능합니다.

 - 같은 값이 하위 엔티티 외래 식별자에 존재하면 해당 값을 모두 업데이트한 후 상위 엔티티 주 식별자 수정이 가능합니다.

 

Primary Key	엔티티 무결성
Unique	엔티티 무결성
Foreign Key	참조 무결성
Check	도메인 무결성
Default	도메인 무결성
Data Type	도메인 무결성
Null / Not Null	도메인 무결성
Trigger	업무 무결성

check : 속성 값에 특정 범위 값이나 규칙을 따르는 값만 존재할 수 있습니다.

trigger : 속성 값이 입력 수정, 삭제될 때 자동으로 데이터를 처리할 수 있도록 지정합니다.

 

 

 

주제 영역

데이터 아키텍처 최상위 단계로 비즈니스 목표 달성에 필요한 데이터의 집합입니다.

유사 성격의 데이터를 체계화하여 그룹으로 묶는 것을 의미합니다.

 

주제 영역이 무한히 늘어날 수 없으므로 모든 데이터는 10개 또는 20개로 정의된 주제 영역에 속해야 합니다.

각 주제 영역의 상세화 수준도 균일해야 합니다.

 

주제 영역 도출이 어려운 이유는 데이터의 성격을 파악하는 것이 어렵기 때문입니다.

데이터를 보고 어떤 성격의 데이터인지, 주제가 무엇인지를 알아야만 합니다.

 

그래서 주제 영역을 도출하는 것은 어려운 일입니다.

 

실체 성격의 데이터와 행위 성격의 데이터가 존재하는데 주제 영역도 비슷합니다. 고객, 조직, 계좌 같은 주제 영역은 실체 성격의 주제 영역입니다. 하지만, 이벤트, 거래 등의 주제 영역은 행위 성격의 주제 영역으로 모델러에 따라 모델이 달라질 수 있습니다.

 

주제 영역은 하위 개념의 서브 주제 영역으로 분류할 수 있으며 주제 영역 내에서는 데이터를 상세하게 정의한 엔티티를 관리하게 됩니다.

 

실무에서는 이렇게 주제 영역의 하위 레벨에 개념 모델과 논리, 물리, 데이터 모델이 실무에서 관리되는 것은 쉽지 않습니다.

영역을 도출했더라도 활용은 하지 않습니다. 주제 영역을 이상적으로 활용하는 것은 주제 영역 단위로 모델링을 수행하는 것입니다.

 

현행은 업무 영역이나 어플리케이션 여역으로 데이터 모델이나 물리 테이블이 관리됩니다.

업무 영역은 데이터와 무관하게 주로 어플리케이션 단위로 구성됩니다.

 

예를들어 여러 종류의 계좌가 존재하면 각 계좌를 관리하는 엔티티는 주식, 선물, 펀드, 저축 영역 등으로 분산되어 있습니다. 하지만, 많은 시스템에서는 업무 프로세스에 따라 분산된 경우가 많습니다.

 

 

 

데이터 표준화

일정 기준에 따라 통일하는 것을 의미합니다.

표준화를 수행하는 목적은 일관된 데이터로 데이터의 오류를 감소시키고 품질을 높이기 위해서 입니다.

일관되어 사용만 하더라도 커뮤니케이션을 돕는 효과가 높습니다.

 

데이터 표준화의 시작은 단어 정의입니다.

단어 정의 시 이음동의어를 주의해야 합니다. 이음동의어는 동일한 의미에 대해 여러개의 단어를 사용하는 것입니다.

 

사원과 직원이 동일 의미이면 한 단어만 사용해야 합니다. 사원이 표준어가 되고 직원은 유사어나 금지어로 관리해 사용하지 못하도록 합니다. 그래야만 사원코드만 사용하고 직원코드, 담당자번호 등은 사용되지 않도록 할 수 있습니다.

 

이음 동의어를 사용한다면 논리적으로 사용하는 것이 좋습니다.

예를들어 사원이라는 단어는 회사에 근무하는 사람으로 employee 이고 단축하면 EMP로 정의할 수 있습니다. 정의된 단어는 속성에 사용합니다. 사원번호라면 EMP_NO로 사용하는 것입니다.

 

데이터 표준화 수행에 중요한 요소는 도메인입니다. 도메인은 데이터 타입의 길이, 포맷 등이 같은 값의 집합입니다. 하나의 속성에는 허용된 유효한 값의 형태가 같아야 하기 때문에 도메인이 하나만 사용되어야 합니다.

 

표준화를 하려면 원칙을 구체적으로 정해야 합니다.

 - 특정한 날짜를 의미할 때는 '일자' 사용

 - '시분초' 까지 표현하면 '일시' 사용

 - '년월일' 일부만 의미할 때는 '년', '년월' 등으로 사용

 - 비율을 의미할 때는 '율'을 사용