귤귤의 대모험

이전 글에서 주체가 되는 행위가 누락이 되면

하위 행위가 되는 데이터를 관리하기 힘들어지는 것을 알아보았습니다

그 밖에도 여러 가지의 단점들이 있었습니다

궁금하시다면 아래의 링크를 클릭해서 확인하시길 바랍니다

2022.09.26 - [Data_Modeling/Methodology] - 데이터 모델링 Account와 같은 상위 개체 집합인 행위 주체가 누락된다면?

주 식별자로 데이터의 의미를 읽을 수 있다?

아래의 이미지를 보면

<그룹웨어 ID> 엔터티에서 <그룹웨어ID> 속성은 유일하게 관리됩니다.

<그룹웨어 ID>가 주 식별자 속성이기 때문입니다.

<사원>과 <그룹웨어 ID>는 1:N 관계이므로 한 사원은 여러 그룹웨어 ID를 사용할 수도 있습니다

하지만 <유효 종료일자가>가 지나서 사용이 만료된 경우라도,

즉 아무도 사용하지 않고 있더라도 다른 사원이 이 <그룹웨어 ID>를 재사용할 수 없는 구조입니다.

재 사용할 수 있다는 업무규칙을 지원하려면 M:N 관계가 되어 관계 엔터티를 추가로 식별해내야 한다.

아래의 이미지를 본다면 여러 사원이 같은 <그룹웨어 ID>를 동시에 사용할 수 있는 구조입니다
그것이 가능하다면 상관이 없지만 여러 사원이 사용을 못하도록 요건을 받았다면
모델링이 잘못되었다는 것을 알 수 있습니다

모델링을 어떻게 하느냐에 따라 관계도만으로 데이터를 어떻게 적재하는지 알 수 있습니다
그래서 잘못된 요건을 제대로 적용된 모델링을 해보도록 하겠습니다

<그룹웨어 ID> 엔터티를 자세히 보면 엔터티의 성격이 맞지 않다는 것을 느낄 수 있습니다
그 이유는 그룹웨어 ID라는 엔터티명와 칼럼명을 같이 사용하고 있으며, 

<유효 시작일자>와 <유효 종료일자> 속성은 계정의 본질적인 정보가 아닌 
상품을 구입한 사람과 사용 행위에 종속된 속성이 더 맞다고 할 수 있습니다
그래서 아래와 같이 주체와 행위를 분리하여 정규화할 수 있습니다

그리고 <그룹웨어 계정>과 <사원 그룹웨어 계정 사용>이 1:1 관계로 
사용 종료된 계정은 다른 사원이 사용할 수 없을 관계도만으로도 확인이 가능합니다

이러한 의미에서 식별자로 데이터가 어떻게 저장하게 되는지 그 구조를 파악할 수 있게 됩니다

 처음의 모델#1을 보면  여러 사원이 같은 <그룹웨어 ID>를 동시에 사용할 수 있는 구조입니다

고객사에서 어떠한 요건을 받아 의도한 바라고 한다고 해도

관리 측면에서 사이드 이펙트가 발생할 여지가 있습니다

그럼 고객사의 인터뷰를 통해 정말 필요한 요건인지 다시 확인하는 과정을 거쳐야 하며

정말 필요하다면 예상되는 사이드 이펙트를 해결해야 하는 방법을 제시해야 합니다

그리고 모델#1에서는 그룹웨어 ID가 존재하면서도 사원번호까지 주식별자로 사용하고 있습니다

이렇게 정의된 것은 현재의 구조에서는 의미가 없습니다

<그룹웨어 ID>만으로도 충분히 엔터티를 식별할 수 있으면서도

사원번호를 추가하는 것을 슈퍼 식별자라고 하며 꼭 필요하지 않는다면

효율면에서도 떨어지니 남용하지 않는 것이 좋습니다

또한, 부적합한 데이터가 쌓일 수 있는 구조를 만드는 빌미를 제공하며,

엔터티의 인스턴스가 늘어나는 기준을 불명확하게 만들어 모델의 가독성을 훼손하기도 합니다

프로젝트 성패를 결정짓는 데이터 모델링 이야기 中 김상래 지음

오늘은 주 식별자에 대해서 알아보았습니다

주 식별자는 모델링에서 많이 보는 형태이면서

아무렇지 않게 남용하는 경우도 보셨을 것입니다

이것을 어느 상황에서 써야 할지 모르고 그냥 연결을 하기 위해 사용하는 것은

아닌지 하는 생각을 했습니다

한 번쯤 깊게 고민해서 노트에 정리해야 할 듯합니다

아무튼 오늘도 한걸음 나아가는 보람찬 하루였음을 생각하며

우리 모두 IT 대모험을 이겨내 봅시다

이전 포스팅 업무 행위의 논리적 주체에 대해서

주체에 의해 행위가 이루어지는 업무들이 있다

그런데 행위가 주체로 이루어져 하위 행위들을 개체로 묶어서 사용할 경우도 있습니다

이러한 주체를 찾지 못한다면 비즈니스적으로 유연함이 부족한 모델링이 될 수 있습니다

그래서 그 관점을 풍부하게 해 줄 필요성이 있습니다

더 자세한 사항을 알고 싶다면 아래의 링크를 클릭해주세요!

2022.09.23 - [Data_Modeling/Methodology] - 데이터 모델링 업무 행위의 논리적 주체란 무엇일까?

Account와 같은 상위 개체 집합이 누락된다면

Account는 마스터 데이터에서 비즈니스 업무에서 행위가 주체가 되는 상황에서

Account라고 칭하며 그 의미를 제대로 이해해야 합니다

그 데이터는 <고객> 엔터티와 고객의 행위 업무인 <주문> 엔터티 나타나게 됩니다

이때 아래와 같이 주문 엔터티에 <주문번호>, <주문 상품번호>까지 포함된다면 행위가 발생할 경우 

관리의 단위는 주문한 상품이다라는 것을 알 수 있습니다

그 이유는 주문이라는 행위가 발생하면

하나의 주문번호에 여러 개의 주문 상품번호가 연결이 되지 않아

고객이 3개의 상품을 한 번에 주문했더라도 개체는 3개가 만들어지는 구조입니다

개별 주문 상품을 묶는 단위로서

<주문> 엔터티를 어떻게 만들고

<주문 상세> 엔터티를 생성해서

주문 상품을 연결하는 방법을 생각해야 합니다

행위의 주체가 되는

<주문> 엔터티는 <주문 일자>, <주문 배송지 주소>, <고객번호>등

주문생성에 필요한 정보들을 구성해주고

행위가 되는 하위 데이터의 <주문 상세> 엔터티는 주문한 상품에 대한 정보를 넣어주거나

 <상품 시작일자>, <상품 종료일자>, <주문 상태>를 구성할 수도 있습니다

주문을 대표하는 개체가

주문 취소나 환불, 부분 취소 등의 프로세스로 발생하여

주문 상품 정보가 변경되면 비즈니스의 유연성이 좋아야 합니다

이번 사례는 정말 간단하고 주문이라는 익숙한 업무이기에

문제점이 눈에 확연히 보일 것입니다

하지만 프로젝트를 수행할 때 물류, 정산, 인사 등

여러 가지 비즈니스 업무를 할 경우 업체에서 주어지는 요건에 새로운 행위가 추가된다면

신경 써서 요건을 수립해야 할 것입니다

즉, 행위가 발생할 때 그 행위가 하나의 행위로 끝이 날지?

행위를 묶을 상위의 행위 주체가 필요할지?

항상 기억하고 생각하여야 한다는 것입니다

지금 프로젝트를 진행할 때 주문이 아닌 어떤 다른 행위가 일어날 때 

어떻게 데이터를 형성하는지?

행위를 할 때마다 데이터를 형성하는 것인지?

그 경우 데이터 관리의 단위가 어떤 것인지?

행위의 주체가 필요한지? 

행위를 묶어서 관리가 필요한지? 등

여러 가지를 생각해보아야 합니다

이렇게 오늘도 모델링에 대해 조금더 알아보았습니다

행위가 주체가 되어 하위 행위들을 집단으로 묶는 경우가 발생할지

또 다른 관점으로 데이터를 봐야 할듯합니다

물론 이런 것들을 이해하기 힘들것같습니다

하지만 행위가 주체가 될 수 있다는 점만 알고 있다면

다음 모델링을 하게된다면 조금은 다른 사람들보다

특별한 관점으로 번뜩이는 것이 있지않을까 생각합니다

그럼 파이팅 하시고 IT대모험을 즐겁게 즐기도록!! 하시길 바랍니다

Account 꼭 기억하세요!

이전 포스팅에서 최상위 데이터에 해당하는 마스터 데이터에 대해서

마스터 데이터란 기업이나 조직 활동의 근간을 이루는 데이터로서

조직에서 발생하는 데이터는 육하원칙에 범주 하는 기준 정보를 부모로 표현합니다

그리고 기준에 따라 행위가 주체가 되는 경우도 알아보았습니다

이전 포스팅이 궁금하시다면 아래의 링크를 클릭해주세요

그럼 이 처럼 중요한 마스터 데이터를 논리적 주체에 의해 다시 알아보겠습니다

2022.09.20 - [Data_Modeling/Methodology] - 데이터 모델링 최상위 데이터에 해당하는 마스터 데이터란 무엇일까?

Account라고 하는 마스터 데이터란 무엇일까

업무 행위의 최상위 주체로 관련 업무 처리들을 동일한 성격으로 관리하는 단위입니다

또한 수많은 행위 데이터를 동일한 성격으로 묶을 수 있는 단위 개체입니다

일반적으로 예약 행위를 통해 생성되며, 다른 하위 행위의 직접적인 주체 역할을 담당합니다

즉, 행위 데이터의 주체가 되어 의미를 나타냅니다

행위 주체라는 것은 행위가 해당 주체에 완전 종속되었음을 의미합니다

그래서 Account를 어떤 업무 처리 데이터들을 동일한 범주로 관리할 수 있는 단위입니다

그런 행위의 주체가 되는 것이 무엇이 있는지

예를 살펴봅시다

어느 CC웹 사이트에서 AA라는 사람 BB일반 회원, CC상점 회원 2개의 계정을 만들 수 있다고 합시다

그렇게 회원을 만들려면 물리 개체인 사람과 논리 개체로서의 회원을 분리해야 합니다

이때 AA라는 사람이 CC웹 사이트 활동하는 BB일반 회원, CC상점 회원 계정은 AA라는 물리적 정보가 아닌

BB일반 회원, CC상점 회원이라는 논리적인 계정을 최상위가 된다는 것을 알아야 합니다

또 다른 예로 엄마, 아빠 아들로 구성된 가족은

모두 같은 이동통신사의 서비스를 이용한다고 해봅시다

엄마는 본인이 사용한 서비스와 아들의 서비스 비용을 하나의 청구 단위로 지불할 것을 요청받습니다

즉, 계약 단위가 아닌 계약의 묶음 형태로 청구가 이루어지고 있습니다

그때 <청구계정> 엔터티가 필요합니다

하지만 청구 계정 엔터티가 없다면 이렇게 묶음 서비스를 할 수가 없을 것입니다

하지만 이러한 개념은 알고 있는 사람들이 많을 것입니다

<주문> 엔터티라는 행위의 주체가 되며 

<주문 상세> 엔터티의 관계가 그 사례입니다

이것은 가장 일반적인 구조의 ERD입니다

그래서 비즈니스 업무를 파악할 때 이경우를 제외하고

다양한 형태의 행위의 주체가 되는 것을 찾을 수 있을 것입니다

업무 행위의 주체를 정확하게 식별하고,

업무 서비스의 최상위에 해당하는 Account를 명확하게 정의하기 위해서는

자신만의 안목과 기준을 구축해가는 시간이 필요합니다

프로젝트 성패를 결정짓는 데이터 모델링 이야기 中 김상래 지음

업무의 행위가 주체가 되어 다른 하위 행위의 직접적인 주체가 되는 경우가 

어떤 것이 있을지 주문, 주문상세 이외에는 떠오르지 않습니다

그래서 Account를 계속 생각하며

실무적인 안목을 키워야 할 것 같습니다

정말 데이터 모델링은 어렵고 힘든 작업인 것 같습니다

다음에 이 책으로 공부를 끝내고

어떤 서비스 웹 사이트를 보고 

데이터 모델링하는 과정을 포스팅하도록 하겠습니다

하지만 이 책을 언제 다 볼지 잘 모르겠네요

아무튼 오늘도 이렇게 좋은 한걸음 나아갔습니다

공부는 꾸준히 하시고 다 함께 힘내시길 바랍니다

우리의 IT 대모험은 끝나지 않았으니까요 

이전 포스팅에서 데이터를 읽으려면 데이터 유형 혹은 패턴에 대해서 

데이터 유형을 알아야 데이터를 잘 읽을 수 있습니다

일반적으로 데이터에는 그 성격이 유사해서 하나의 틀로 묶을 수 있는 유형이 존재합니다

그것을 제대로 파악해서 업무 정보는 데이터를 육하원칙에 따라 결합한 체계를 파악할 수 있습니다

더 상세한 정보를 알고 싶으시다면 아래의 링크를 클릭해주세요

2022.09.19 - [Data_Modeling/Methodology] - 데이터 모델링 중 데이터를 읽으려면 데이터 유형 혹은 패턴 제대로 알자

마스터 데이터란

기업 활동의 핵심이 되어 자주 사용되는 데이터로 정의하는 곳도 있습니다

하지만 모델링에서 마스터 데이터는 그렇게 표현하면

데이터의 성질에 맞지만 자주 사용된다는 것은 옳지 못한 표현입니다

그래서 "기업이나 조직 활동의 근간을 이루는 데이터"라고 하는 것이 적당할 것입니다

그리고 무엇보다 활동의 근간이라는 표현에 주목해야 합니다

활동 자체의 데이터는 마스터 데이터가 아니며 활동의 근간 즉 기준이 되는 데이터여야 한다는 것입니다 

그리고 상위 모델을 체계화하지 않은 채 하위 모델을 제대로 조직한다는 것,

결국 관리해야 할 데이터를 정확하고 효율적으로 담을 수 없게 됩니다

마스터 데이터를 생각하여 유형 관점을 찾고 모델링하자

모델이 다단계의 부모-자식 관계를 갖는 이유는

업무 행위가 다른 업무 행위의 주체가 될 수도 있고, 논리적인 개념 역시 상위 집합에 위치할 수 있기 때문입니다

위처럼 다단계 계층을 이루게 되므로,

모델링할 때나 기존 모델을 분석할 때는 족보의 뿌리를 찾아가듯

최상위의 행위자와 행위의 대상을 명확히 정의하고 식별해야 합니다

운영 중인 데이터베이스에서 데이터 모델을 추출하는 리버스 모델링에도 그대로 적용됩니다.

1. 최상위의 고객과 상품을 찾는다.

2. 고객과 상품 수준의 다른 주체와 대상도 찾는다.

3. 고객과 상품이 행한 업무 트랜잭션(주로 계약 수준)을 찾는다.

4. 트랜잭션이 주체로 행한 하위 트랜잭션을 찾는다.

5. 관계를 찾아 연결한다.

6. 각 엔터티를 주요 속성부터 채워나간다.

7. 이력 등 기타 엔터티를 고려하며 전체 모델을 상세화한다.

오늘은 마스터 데이터를 파악하고

그 근원적인 데이터로 다단계층을 구조를 구성하여

 최상위 행위자와 행위의 대상을 명확히 구분 지어야 합니다

아직까지 모델링이란 것이

명확하게 할 수 있다고 할 수 없습니다

계속 공부하고 계속 테이블 설계도를 계속 보면서 눈으로 익혀야 합니다

분석/설계 업무를 할 수 있는 수준까지 올려서

한 단계 올라설 수 있게 노력해야 할 듯합니다

그럼 오늘도 파이팅 하시고

항상 공부하는 습관을 갖도록 노력합시다!

우리의 IT 대모험은 아직 끝나지 않았으니까요!!

이전 글에서 엔터티 모델링이 어려운 이유에 대해서

데이터 집합을 정의하기는 쉽지 않고 데이터 본질을 파악하기도

어렵습니다 그래서 무엇보다 모델링 마인드가 필요하며

다른 많은 이유들로 모델링이 어렵습니다

조금 더 상세한 이유가 필요하시다면 아래의 링크를 클릭해주세요

2022.09.13 - [Data_Modeling/Methodology] - 데이터 모델링 중 엔터티 모델링이 어려운 이유는?

데이터를 읽으려면  데이터 유형 혹은 패턴 제대로 알자

일반적으로 데이터에는 그 성격이 유사해서

하나의 틀로 묶을 수 있는 유형 혹은 패턴이 존재함을 알 수 있습니다

아래의 두 사건을 놓고 생각해 봅시다

A가 S전자의 상품 X를 2015년 10월 17일에 구매했다.

B가 K은행의 계좌 Y에 2015년 10월 18일 15시 27분경 100만원을 입금했다

문장에 주어에 해당하는 구매와 입금에는 행위의 주체인 A와 B가 존재합니다

그리고 이들 행위의 대상인 목적어는 상품 X와 계좌 Y도 존재합니다.

구매와 입금이라는 행위 자체와 행위가 일어난 시각도 물론 확인할 수 있습니다

이렇듯 비즈니스 업무에 해당하는 주체가 어떤 행위를 발현할 경우

육하원칙에 따라 엔터티가 구성될 수 있습니다 

그러므로 육하원칙을 생각하며 그에 상응하는 구조적 체계를 잘 생각해보아야 합니다

업무 데이터는 업무와 관련된 사건의 기록이며, 

업무 정보는 데이터를 육하원칙에 따라 결합한 체계라고 말할 수 있습니다

업무 요건을 어떻게 데이터 모델로 표현할 것인가?는

아래의 이미지를 보면 명쾌한 답이 될 수 있습니다

성격이 같은 데이터는 하나의 유형으로 통합하고

업무 행위는 관련 개체들과의 관계로 표현하는 것이 핵심입니다

즉 비즈니스 업무들이 어떤 업무들이 발현되고

그 업무들의 유사성을 찾아 유형/코드를 생성합니다

그리고 그에 따라 관련된 업무가 어떤 식으로 행위가 이어지는지 확인해야 합니다 

특히 업무 트랜잭션(행위) 성격의 엔터티를 검증할 때 해당 엔터티와

육하원칙 관계에 있는 주변 엔터티들이 모두 제대로 된 관계로 연결되어 있는지 확인합니다

데이터 사이에는 종속관계와 같은 구조적 특성도 발견됩니다

개별 데이터의 성격에서 구현됩니다

예를 들어 대출 상환 업무에서 상환 금액과 상환 일시 데이터는

대출이라는 행위 데이터에 종속될 수밖에 없습니다

대출이라는 업무가 발생하지 않는다면 대출 상환은 절대 존재할 수 없기 때문입니다

중앙 <비즈니스> 엔터티는 주변의 '누가', '무엇을', '언제', '어떤 유형' 등의 데이터에 종속됩니다

주변의 기준 정보가 존재하지 않으면 업무 행위 자체가 발생할 수 없습니다

즉, 부모 역할을 하는 주변 개체들에 대해 깊이 살펴볼 것입니다

트랜잭션의 실질적인 주체와 대상에 해당하는 데이터를 정확히 볼 줄 알아야 합니다

일반적으로 데이터 아키텍처와 방법론에서는 이러한 데이터를 마스터 데이터라고 하며

중요하고 일관되게 관리되어야 합니다

업무 행위와 행위의 주체/대상

업무의 주체나 대상 등 같은 성질의 데이터를 하나의 개체로 통합하고,

업무행위는 관련 개체 사이의 관계로 표현하는 것이 핵심입니다

프로젝트 성패를 결정짓는 데이터 모델링 이야기 中 김상래 지음

데이터를 잘 읽으려면 비즈니스 업무 요건을 

충분히 이해를 하여 데이터 모델링을 해야 합니다

그러기 위해서는 주체를 알고 육하원칙에 맞게 엔터티를 구성해야 합니다

그 구성에 따라 업무에 대한 행위를 다시 생각해보며

그 부모 객체가 누구인지 누구에 의해 발현되고 있는지 확인해야 합니다

육하원칙을 어떤 식으로 파악하고 적용할지에 대한 것들도

업무를 얼마만큼 경험했는지가 중요한 요소인 것 같습니다

물류, 정산, 회계, 인사 등

여러 가지 ERP 업무들이 존재합니다

하지만 그것 또 한 회사마다 다릅니다

그래서 모든 비즈니스 업무를 다 파악할 수 없으며, 현업에 종사하는 사람들도

어떤 업무들이 추가되며 발생할지 예상을 못할 수 있습니다

그렇기 때문에 모델링에서는 모든 업무들을 범용성이 있게 구성하는 것이 가장 이상적이지 않을까 합니다

데이터 모델링을 계속 공부하면서도 부족함을 느낍니다

그래서 다른 교육기관을 가볼까 하고 생각 중입니다

아무튼 배움은 중요하니깐요

모두 힘내시고! 파이팅 하시길 바랍니다

이전 글에서 데이터 모델링이 철학적 관점이 필요한 이유에 대해서

비즈니스 업무를 데이터적 관점으로 보는것은 매우 어려운일이다

그것을 서양 철학적 관점으로 해석으로 데이터 관점을 새롭게 바라볼 수 있는게 하였다

아래에 상세한 내용이 있으니 관심이 있으신분을 링크를 클릭하 시길 바랍니다

2022.09.12 - [Data_Modeling/Methodology] - 데이터 모델링을 철학적 관점이 필요한 이유는?

엔터티 모델링이 어려운 이유는?

엔터티 모델링 어려운 이유를 한마디로 표현하면 엔터티의 핵심적인 특성을 결장하는 기준을 찾기 어렵기 때문입니다

이러한 어려운 이유를 세분화하여 나열해 보았습니다

첫째 데이터 집합을 정의하기가 쉽지않습니다

모델링은 결국 업무 데이터의 분류와 묶음이라는 행위입니다

여신 연체관리 진행이라는 은행 업무가 있다고 한다면

<여신연체관리진행>이라는 엔터티를 만들어야 하는 지,

아니면 <여신연체관리> 엔터티의 <진행> 속성으로 관리해야하는지는

그 기준을 정하기가 어렵다는 것입니다

그 기준이 무엇인지 명확히 밝히고 객관화할 수 있다면 실전에 활용하면 될 것입니다

둘째 데이터의 본질을 볼 줄 알아야 엔터티를 정확하게 정의할 수 있는 점입니다

비즈니스 관점을 제거하는 게 그리 쉬운일은 아닙니다

더욱 데이터 모델링하는 사람들은 업무상 처음 마주한 사람이 대부분입니다

그렇기 때문에 본연의 속성을 파악하기가 쉽지 않을 것입니다

우리는 대상을 인식할 때 우선 복합물로 인식하기 때문입니다

존재에 고유한 특성인지 파악하고 정리할 수 있는 깊은 통찰력이 모델러에게 필요합니다

셋째 엔터티의 추상화 수준을 결정하는 것은 대단히 어렵습니다.

추상화 수준이란 다양한 의미를 포함합니다

사람이라는 집합이라면 이를 성별이라는 관점으로 구분할지, 태어는 나라로 구분할지

그것도 아니면 한 덩어리로 관리할지 전략적으로 결정하기가 쉽지가 않습니다

필요에 따라 유사 집합과 통합하고 분리하는 과정을 거치면서

엔터티의 적절한 크기를 결정할 수 있는 내공이 필요합니다

넷째 하위의 트랜잭션 데이터만을 보고

부모 역할을 하는 상위의 논리적인 집합을 발견하는 것은 어렵습니다.

데이터 모델링에서 엔터티 모델링은 꽃입니다

엔터티를 찾아내지 못하면 모델은 모호하거나 이상하게 그려지고 

결국 데이터가 중복되거나 이상현상이 발생합니다.

눈에는 보이지는 않지만, 분명히 존재하는 논리적인 집합을 발견할 수 있는 통찰이 필요합니다.

다섯째 업무의 방대함과 복잡도에 압도되기 쉽습니다.

차세대 정보시스템 구축 프로젝트의 경우

새롭게 만들어지는 테이블 수가 만 개 이상인 경우도 있습니다

모델러가 데이터의 정체성, 성격, 특징을 파악하고

데이터가 생성되는 규칙까지 읽을 수 있어야 제대로 된 모델이 나올 수 있습니다

하지만 실무에서는 부족한 분석/설계 기간,

작업 분류 체계 자체의 문제점, 업무 정형화에 필요한 현업 인터뷰 부족 등

많은 문제점들이 있습니다

이러한 환경 속에서 주어진 리소스만 가지고 업무의 복잡도를 파악하고

효율을 극대화해주는 방법론이 필요합니다

그렇기 때문에 더 더욱 경험이라는 것이 중요하며

자기만의 업무분야에서 사용할 방법론을 구축해야합니다  

프로젝트 성패를 결정짓는 데이터 모델링 이야기 中 김상래 지음

데이터 모델링을 공부하기위해 여러 기관도 알아보고 책도 많이 보았습니다

이론적인 부분만 본다면 저는 이 책이 정말 좋았습니다

데이터 모델링에 대해 근본적인 생각을 고쳐주며

다른 관점을 보게해주기 때문입니다

하지만 이런 관점을 실무에서 쓸수 있냐 없냐는 자기가 직접 구현해보면서

공부를 해야한다느 것이지요

그래서 이런 관점을 생각하면서 현재 프로젝트 모델링이 되어있는 것을 보면서

생각해보는 것이 필요하겠습니다

이전 글에서 데이터 모델링 정규화에 대해서

정규화 과정이 왜 중요하고

그것이 원론적으로 무엇인지 알아보았습니다

정규화가 정말로 성능적으로 문제가 있을까에 대해서도

알아보았는데 정규화는 성능적인 문제보다는 본질적인 개체를 구분해야

성능면에서도 뛰어나다는 것을 알 수 있었습니다

조금 더 상세한 정보를 알고 싶다면 아래 링크를 클릭하시길 바랍니다

2022.08.23 - [Data_Modeling/Methodology] - 데이터 모델링 정규화 란? 무엇이며, 정규화 성능 저하 정말 그럴까?

데이터 모델링에 철학적 관점이 필요한 이유는?

먼저 우리는 데이터 모델링에 대해서 몇 가지 관점을 알고 있을 것입니다

1. 데이터는 업무 프로세스와 무관하며, 프로세스에 종속적이지 않아야 한다.

2. 비즈니스적 업무 및 절차가 변경된다고 데이터 모델링이 변경되어서는 안 된다.

3. 데이터 모델은 업무의 요건을 함축적으로 정의가 되어야 한다.

이렇게 3가지 정도를 알 수 있습니다

하지만 위의 사항이 약간은 이해가 안되는 부분이 있습니다

데이터 모델이 업무를 표현해야 한다면서,

동시에 업무와 종속성은 최소화되어야 한다는 것 때문입니다

이 부분은  데이터 모델은 업무를 데이터 관점으로

명확히 표현해야 한다는 것만은 알아야 하겠습니다

조금 더 설명하자면

이벤트라는 업무 활동을 하는데 이벤트라는 여러 가지 현상이 일어날 수 있지만

데이터 모델링은 변경이 되어서는 안 된다는 것입니다

이벤트라는 원론적인 본질에서 나타나는 여러가지 현상을

하나의 데이터 모델링으로 만들 수 있게 해야 한다는 말이겠지요

어느 프로젝트를 보면 이벤트를 만들 때마다 테이블을 늘려가며

페이지도 계속 추가되는 형태가 있습니다

하지만 그 현상을 일으키는 근본적인 원형은 이벤트라는 것을 알아야 할 것입니다

이벤트라는 근본적인 본질이 여러 가지의 이벤트라는 현상을 어떻게 범용적으로 품을 수 있을지 생각해야 합니다

이벤트 페이지의 크기 규격화하고, 버튼위치를 명세화하며, 버튼의 갯수를 정의할 수 있게 하는 등

기능들을 어드민 페이지에서 핸들링 할 수 있다면 

분명 이벤트 페이지도 모델링에 적합한 데이터들이 있을 것입니다 

이전 포스팅에 설명한 설문지에 대해서 모델링이 참고할만한 자료가 되겠지요

그래서 아리스토텔레스는 "현상은 복잡하지만 본질은 단순하다"

직접 보이는 세계를 현상이라 하며, 나무 같은 개별 존재의 공통 속성은 본질이라 합니다

추석 이벤트, 출석 이벤트를 현상이라고 본다면 이벤트 자체는 좀 더 원형적인 본질로 이해해야 한다는 것입니다

이처럼 수많은 현상과 사건은 하나하나가 매우 독특하고 개별적이며 끊임없이

변화하기 때문에 안개처럼 겹쳐 본질을 흐리기 쉽습니다

현상에 속지 않고 본질을 들여다보면서 대상을 명확히 하려는 태도와 마음가짐은

모델링에서 무엇보다 중요합니다

과감하게 현상을 버리고 본질을 관통하려면 본질을 기반으로 세상을 이해하는 통찰적 시각을 가져야 합니다.

데이터 모델러는 경험이나 인식의 범위를 초월하여 비즈니스 세계의 본질과 현상을 철저히 분리할 수 있는

높은 수준의 통찰력이 요구됩니다

이를 근간으로 만들어지는 본질과 현상을 분리할 수 있도록 도움이 되는 인식론을 알아보고자 합니다

실제 중심적 철학

서양 철학의 사유 방식 중인 하나는 플라톤과 아리스토텔레스의 인식 방식인 실제 중심적 철학입니다

아리스톤 텔레스는 사유 체계인 범주론을 보면 실제, 분량, 성질, 관계, 장소 시간, 위치 상태 등으로

구성되는 범주 표가 있습니다

이처럼 사유 유형 중에서 본질을 뜻하는 실체로서의 존재는 다른 것과 관련하지 않고

오직 자신과만 관련 있다는 의미로 존재는 독립적이다라고 말하고 있습니다

관계 중심적 철학

위와 다른 사유 방식인 관계(사건, 현상)입니다

반 플라톤적 사상가인 질 들뢰즈에 의해 선명하게 나타납니다

현실세계의 모든 사건, 행위, 현상은 영토성과 코드성으로 이루어집니다

야구공, 배트, 글러브, 야구선수, 심판, 관중 등이 일정하게 자리를 차지하는 영토성이며,

야구 규칙과 스포츠 관람이라는 일정한 코드가 작동함으로써 코드성 

야구 경기가 성립되어 배치성이라는 의미를 가집니다

즉,

야구 선수인 이승엽은 어느 야구시합에서 만루 홈런을 친 것은 배치성을 나타내며

야구장, 각종 야구용품, 선수 등이 영토성을 가지며

이미 존재하는 야구 규칙이 서로 만나 사건으로 인식되는 것입니다

이때 사건과는 무관한 순수하고 본질적인 영역인 영토성 존재가 모델링의 주요 관심 대상이 됩니다

프로젝트 성패를 결정짓는 데이터 모델링 이야기 中 김상래 지음 

위의 글처럼 우리는 데이터 모델링이라는 관점을 새로운 측면에서 봐야 합니다

지금 일어난 사건과 현상에만 집중하지 말고 본질을 볼 수 있는 눈을 키워야 하며

본질에서 어떠한 현상이 나타나는지 잘 판단해서 모델링을 해야 합니다

데이터 모델링은 아무리 공부해도 어려운 것 같습니다

다음에는 실제 사례들로 지금까지 공부한 것을 접목하여 글을 올리도록 하겠습니다

그럼 오늘도 즐거운 하루 되셨길 바라겠습니다

이전 포스팅에서 정규화 이론이 왜 중요한가?

데이터 이상 현상을 제거하기 위해 정규화 이론은 중요하다고 하였습니다

데이터 구조적인 측면에서 중복되는 데이터에 대해서 독립 개체로

관리하기 위해서도 정규화 이론은 필요하다고 했습니다

그 밖에 또 무엇이 있을까요?

더 자세히 알고 싶다면 아래의 링크를 클릭해서 확인하시길 바랍니다

2022.08.22 - [Data_Modeling/Methodology] - 데이터 모델링 정규화 이론이 너무나도 중요한 이유는?

정규화의 의의

데이터 모델링의 핵심이론인 정규화 이론은 몇 가지 특징을 가지고 있습니다

첫째, 속성 간의 종속성을 기준으로 성격이 유사한 속성들은 모이고 관계없는 속성들은 분리합니다

행위와 관계를 구분하고 본질을 파악하여 범주화하는 것이 핵심입니다

둘 때, 정규화는 함수 종속을 없애고 밀접한 속성을 하나의 표에 집약시키는 체계적인 방법입니다

따라서 데이터는 응집도는 높고 결합도는 낮게 분리합니다

결국, 데이터 본질에 충실한 제대로 된 엔터티가 도출될 수밖에 없습니다

셋째, 데이터 중복이 최소화된 효율적이고 구조화된 모델입니다

데이터 이상 현상이 사라지게 됩니다

넷째, 주식별자는 인스턴스를 구분하는 기준이므로 집합의 개체 발생 규칙도 검증되어 더 장확 해집니다

즉, 주 식별자만으로 엔터티가 어떻게 관계되었는지만 본다면

어떻게 데이터가 관리되고 저장되는지

규칙을 확인할 수 있습니다

다섯째, 업무 변경에 따른 확장성이 좋습니다

속성과 그에 따른 데이터가 엔터티 별로 독립 개체로 구성되어

범용성이 높게 구성됩니다

그래서 사용자가 새로운 업무를 추가할 때

확장성이 좋습니다 

여섯째, 데이터 중복을 최소화함으로써 데이터 무결성을 극대화합니다

정규화 과정을 거치면 데이터의 중복성을 제거합니다

그리고 독립 개체를 만들어 데이터 무결성을 보장할 것입니다

일곱째, 정규화된 모델은 그렇지 않은 모델에 비해 대부분 성능이 좋다.

이 부분은 동의를 못하는 사람이 있을 수 있다

정규화가 된 데이터 모델링은 테이블이 늘어나서

조인이 증가하여 성능이 저하된다고 생각할 수 있습니다

아래에서 더 자세히 설명하겠습니다

정규화가 정말 성능 저하의 원인일까?

정규화를 하게 되면 한 개의 테이블이 두 개의 테이블로 분리해야 합니다

그렇게 되면 조인이 증가하기 때문에 성능이 저하될 거라고 합니다

정규화되지 않은 테이블에서는 중복된 데이터를 더 읽어야 하고

정규화가 된 테이블에서는 조건에 맞는 데이터만 읽어 빠르게 처리할 수 있습니다

하지만

조인이 필요하다는 것은 변화가 없지요

인덱스만 정확히 정의되어 있다면 성능상의 차이는 미미할 것입니다

그리고 테이블의 한 행이 2K고 한 블록의 크기가 8K라면 한 블록에서 4개의 개체가 담길 수 있습니다

DBMS는 한 블록, 즉 IO의 최소 단위가 블록이기 때문에 8K를 메모리로 올립니다

그래서 SQL 최적화할 경우 조회할 레코드 수가 아닌 블록의 수가에 집착하는 이유도 바로 이것 때문입니다

그렇기 때문에

정규화가 IO의 대상이 되는 블록수를 줄여줄 수 있는 이야기가 됩니다

모든 속성이 한 개의 테이블에 담겨 있다면 조회하는 속성의 수가

많고 적음에 상관없이 항상 전체 블록을 읽어야 합니다

그러나 정규화가 잘되어 있다면 훨씬 적은 블록을 읽고도 원하는 결과를 얻을 수 있습니다

물론 조인이 많이 걸려 여러 테이블을 조회하는 것이 시간 소요가 발생할 수 있지만

만약 정규화가 된 여러 테이블이 정규화하지 않은 한 개의 테이블로 관리한다면

그것 또한 관리하는 입장에서는 아찔할 수밖에 없습니다

OLTP에서 조인에 의한 성능 저하가 극심한 경우라면 조인의 방법이 잘못되었을 경우가 큽니다

인덱스가 없거나 조인 연결이 이상하게 되어 옵티마이저가 인덱스를 사용하지 못하는 등의 문제지

조인 자체가 문제의 본질인 경우는 드물기 때문입니다

그리고 최근에는 컴퓨터 성능이 좋아져 이전만큼 성능 저하를 많이 느끼지 못합니다

그래서 정규화 때문에 성능 저하라고 하는 것은 조금 아이러니하지요

관리하는 측면에서 정규화는 매우 중요하다는 것이며,

정규화 때문에 성능 저하가 아닌 다른 문제 해결이 정답일 것입니다

데이터 구조적 측면에서 이득이라고 생각합니다

전체적인 것을 본다면 정규화는 대부분의 경우에서 더 뛰어난 성능을 보입니다

프로젝트 성패를 결정짓는 데이터 모델링 이야기 中 김상래 지음

이제 정규화라는 것에 대해 조금은 알 수 있었으면 합니다

몇 개의 포스팅에서 지긋지긋하게 다뤘기 때문에

이제는 조금 익숙해지지 않았을까 합니다

저도 이번 기회에 조금 더 공부하는 계기가 되었습니다

IT공부는 즐거울 때도 정말 지루할 때도 있지만

공부하고 그 결과가 바로바로 올 수 있는 몇 안 되는 직업이라고 생각합니다

능력만 있으면 인정받을 수 있으니 더 힘을 내 봅시다

그럼 우리의 IT 대모험은 끝나지 않았으니

파이팅 하시길 바랍니다

이전 포스팅 모델러의 마음가짐이란?

이전 포스팅에서는 데이터 모델러에 있어 

마음가짐을 어떻게 해야 하는지에 대하여 알아보았습니다

스키마 구조와 모델을 보는 3가지 관점이 왜 중요한지

사용자 관점에서만 모델링을 하다보면

불필요한 공수가 발생하여 장기간 운영해야 하는 서비스에서는

너무나도 불합리한 것이었지요?

더 궁금한 것이 있다면

아래의 링크를 클릭해서 확인하시면 되겠습니다

2022.08.16 - [Data_Modeling/Methodology] - 데이터 모델링의 중요한 마음가짐이란 무엇일까?

데이터 모델링 정규화 이론의 중요성

데이터 모델링에 있어 정규화 과정은 어느 책에든 강좌를 봐도

빠지지 않고 이야기하는 이론입니다

그 이유는 2차 원표(DBMS)에 어떤 데이터를 어떻게 담는 것이 최적인지 고민하는 과정입니다

그 고민에 어떻게 담는 것이 가장 적합한지 알아보기 위해서는 

정규화 이론이 가장 이상적이기 때문입니다

구조적으로 데이터 이상 현상이 존재하지 않는 데이터 구조가 이상적입니다

하지만 위와 같이 데이터가 구조가 구축되어있다면,

아래와 같이 문제점이 발생합니다

- 평가 코드 결과가 홍길동이라는 학생에 대한 정보는 입력이 불가능합니다

- 과목 코드가 CR11인 과목의 이름이 '심리학 입문'으로 변경되면

박영진과 김영희의 CR11 관련 열을 모두 찾아서 수정해야 합니다

- 김영희 F학점 평가 결과를 삭제하면 논리학 개론 과목도 함께 삭제됩니다.

데이터 이상 현상은 속성의 값을 수정할 때나 새로운 개체를 삽입하거나 삭제할 경우 의도하지 않은

다른 데이터에 문제가 발생하는 현상입니다

그런 데이터 이상 현상이 발생하는 데이터 구조를 가지고 있다면,
이상 현상의 원인은 데이터가 독립적이지 않고 중복으로 관리되어

데이터 간의 종속성에 계속 영향을 받기 때문입니다

하나의 종속성이 하나의 표로 관리되도록 분해해가는 과정이 바로 정규화입니다

즉, 종속성을 기준으로 데이터를 어떻게 담는 것이 최적인가에 대한 방법론이 바로 정규화 이론입니다 

1 정규화 적용 사례

* 1 정규화에서는 모든 속성이 값을 반드시 하나만 가져야 합니다

자격증 정보를 사원에 종속된 정보가 아니라 독립된 개체 정보로 유일하게 관리하고자 합니다

아래와 같이 사원이 자격증을 여러 개 가지고 있다면 문제점이 발생한다

그래서 사원 보유 자격증을 만들어서 관리합니다

하지만 이것 또한 문제점이 발생합니다

자격증별로 어떠한 이슈가 있을지 모르기 때문입니다.

그래서 아래와 같이 자격증을 독립적인 개체로 만들어주는 것이 좋습니다

그러면 범용적으로 자격증에 수장 지원 여부나 진급 시 필요한 필수 자격증 여부 등 여러 값들을 관리할 수 있습니다

그래서 1: N로 개체가 연결될 가능성이 있다면 독립 개체로 관리해야 합니다

2 정규화 적용 사례

* 모든 속성이 반드시 주 식별자 전부에 종속되어야 합니다

* 1 정규화로 생성된 집합은 자식이며, 2 정규화로 분리된 집합은 부모가 됩니다.

아래와 같이 데이터가 구성되어있다면

2 정규화를 거쳐서 2개로 분리가 됩니다

그 이유는 단체명이 변경된다면 데이터 이상현상이 발생하기 때문입니다

이때 단체 번호에 종속된 속성을 전부 별도 엔터티로 분리를 합니다

즉, 계약 번호는 같지만, 계약 주체인 단체가 다를 경우에는 계약 내용 등이 다를 수 있음을 주식 별자가 설명하고 있습니다

이렇게 설명은 안되어있지만 엔터티만 보고도 계약과 단체의 데이터 관계를 이해할 수 있어야 합니다

3 정규화 적용 사례

* 주 식별자가 아닌 모든 속성이 상호 종속 관계여서는 안됩니다.

아래와 같이 <고객명>과 <고객등급> 속성은 <고객번호>에 함수적으로 종속되어 있습니다

오른쪽과 같이 고객 집합을 별도로 분리하여 <고객> 엔터티로 만드는 과정이 필요합니다

실제 현장 모델링에서 가장 근원적이고 기반이 되는 핵심사상이 바로 정규화 이론입니다

그리고 통상 4 정규화 이상의 모델은 폭넓게 사용되지 않고 있습니다

이렇게 데이터 이상 현상을 줄이기 위해서는 정규화 이론은 필수 이론이라고 할 수 있습니다

숙지가 잘 안 되더라도 반복적으로 보며 생각하면서

정규화에 대한 개념을 확실히 잡는 것이 중요합니다

그래서 엔터티를 보기만 해도 데이터의 관계성을 파악해서

모델러의 의도를 파악하는 것이 개발자로도 필요한 덕목이라고 생각합니다.

그럼 앞으로 언젠가는 모델러가 될 여러분의 미래를 생각하며

오늘도 한걸음 나아갑시다!

파이팅!!

프로젝트 성패를 결정짓는 데이터 모델링 이야기 中 김상래 지음

이전 포스팅에서 데이터 모델링의 기본적인 스키마 구조와

모델을 보는 3가지 관점이 왜 중요한지 알아보았습니다

각 각의 스키마 구조에 해당하는 중요한 작업들이 있었습니다

사용자가 바라보는 관점과 외부 스키마,

그 관점을 데이터 관점으로 통합한 뷰의 개념 스키마,

데이터 DBMS에 저장되는 논리적 구조의 내부 스키마

그 스키마들이 행하는 근본적인 기준을 제대로 알고 있어야

외부 스키마의 데이터를 개념 스키마를 무시한 채 내부 스키마까지 적용하는 일이 없어야 할 것입니다

그런 기준을 보다 넓은 사고력을 키워 줄 수 있는 시간였던 것 같습니다

궁금하시다면 아래의 포스팅을 클릭해 주시길 바랍니다

2022.08.14 - [Data_Modeling/Methodology] - 데이터 모델링의 기본적인 스키마 구조, 모델을 보는 3가지 관점이 왜 중요한 걸까?

이제 데이터 모델링의 마음가짐이란 무엇일까요?

데이터 베이스가 최상의 성능을 낼 수 있는 구조를 도출해야 합니다

단지 모델링을 단순히 데이터의 저장 구조를 그려내는 것이라고 생각해서는 안된다는 것입니다

그 궁극의 기반 이론이 정규화라는 것도 기억해두시길 바랍니다

정규화를 무시 한채 단순히 데이터의 저장구조를 그리게 된다면 큰 손실을 보게 될 것입니다

단적인 예로 이야기하도록 하겠습니다

주문서의 데이터를 사용자가 필요로 하는 형태로 조직화된 하나의 집합체로 보이지만

그 내부의 데이터는 연관성을 고려하여 여러 테이블의 구조로 이루어져 있습니다

하지만 외부 스키마에서 바라보는 정보들로 내부, 개념 스키마를 구성했다면 어떤 일이 벌어질까요?

그것은 주문서라는 하나의 테이블에 모든 속성을 모아 설게 한 경우가 될 것입니다

이렇게 설계가 된다면 중대한 문제점이 여럿 존재하게 됩니다

그중 세 가지를 살펴보겠습니다.

첫째, 나중에 주문서에 포함된 상품의 이름이 바뀌면

해당 상품과 관련된 주문을 모두 찾아서 상품명을 수정해야 합니다

둘째, 주문을 단 한 번도 하지 않은 고객은 관리 자체가 불가능합니다.

주문을 해야 주문서를 통해 주문 고객의 정보가 들어올 수 있는 구조 이기 때문입니다.

셋째, 주문한 상품을 배송하려면 주문 배송 주소 데이터를 참조해야 합니다

그러나 불필요한 다른 속성들 때문에 대량 주문 처리할 경우 시스템 성능에 악영향을 줄 수 있습니다.

이렇듯 우리가 데이터 모델링을 해야 한다면

먼저 테이블의 데이터를 어떻게 수정할 것인가?

저장된 데이터는 어떻게 관리하며 어떻게 재사용할 수 있을까?

지금 테이블의 구조로 시스템의 성능은 최상으로 유지할 수 있을까?

라는 의문점을 가지고 데이터 모델링을 진행해야 합니다.

프로젝트를 진행하다 보면 정말 많은 테이블 구조와 설계를 보게 됩니다

정말 한숨이 절로 나오는 설계도 있으며

정말 노력의 흔적이 보이는 모델링도 보게 됩니다.

이제 저 또하 데이터 모델링을 하게 된다면

누구에게 어떠한 시선으로 보일지 그것을 생각하며

제 스스로 떳떳할 수 있게 책임감을 가지고 나아가겠습니다.

그럼 공부하시는 IT 개발자 여러분 앞으로도 같이 파이팅 하시길 바랍니다.

그럼 다음 포스팅에서 뵙겠습니다.

오늘도 보람찬 하루가 되었길 바라겠습니다.

이전 포스팅에서 데이터 모델링의 범주화와 추상화에 대해서 알아보았습니다

너무나도 범주화가 중요했지요

범주화는 본질을 정확하게 파악해서 성격이 유사한 개체로 묶는 과정이었습니다

추상화는 가장 핵심적인 특성만 추리하는 과정입니다

이렇게 과정을 거치면서 본질과 현상을 구분하여 본질적인 개체를 무시하게 되면

큰 문제점이 드러나는 것도 알아보았습니다

더 자세한 사항을 알고 싶다면 아래의 포스팅을 확인해보세요

2022.08.12 - [Data_Modeling/Methodology] - 데이터 모델링 개제의 본질적인 정보와 역할 정보를 구분해야 하는 이유는? 범주화와 추상화의 중요성은?

3단계 스키마 구조가 중요한 이유

데이터 모델링을 공부한다고 하면

정말 자주 나오는 것이 3단계 스키마 구조입니다

외부 스키마, 개념 스키마, 내부 스키마

이 3개의 스키마 구조인 이 단어들을 많이 들어보셨을 것입니다

하지만

이 스키마 구조가 왜 중요한지에 대해서는

생각해보지 못했을 수도 있다고 생각합니다

이론적으로 접근해서 

외부 스키마는 사용자 관점의 정보 단위 뷰

개념 스키마는 사용자 관점을 데이터 관점으로 통합한 뷰

내부 스키마 데이터가 DBMS에 저장되는 논리적 구조

위의 사항으로만 인지하고 실제 모델링할 경우

생가지 못한 상황이 발생할 수 있습니다

이제 이야기를 한번 해봅시다

개념 스키마는 외부 스키마와 독립된 계층이라는 것입니다.

하지만 프로젝트를 하다 보면 이상한 구조의 스키마를 보게 됩니다

외부 스키마를 다루듯 테이블을 화면별, 업무 프로세스별로 만드는 경우가 그런 상황입니다

이렇게 되면 스키마가 독립성이 줄어들고 결합도만 커지는 상황이 생깁니다

이런 상황이 발생하면 좋은 스키마 구조라고는 할 수 없습니다

외부 스키마에서 정의된 것들이 개념과 내부 스키마를 무시한 채 구조가 정립된 거라고 할 수 있습니다

화면이 변경되면 테이블을 수정하거나 새로운 테이블을 만드는 상황이 올 수도 있다는 것입니다.

그럼 새 프로그램을 개발하는 상황이 되고 그것을 운영하려면 테스트도 새롭게 해야 합니다.

결론적으로 새로운 공수가 발생하게 됩니다.

그래서 데이터의 독립성을 정확하게 분석하고 이해해서

데이터 독립성을 해치지 않도록 개념 스키마에 근거해서 모델링해야 합니다.

개념 스키마는 외부 스키마보다 데이터의 본질에 가깝습니다.

그 본질을 무시한 체 외부 스키마의 사용자 관점으로 모든 것을 개발하게 되면

개발자들의 공수들이 늘어나게 되며 이것은 운영에서 지속적인 스트레스가 발생할 수 있습니다 

그 데이터들의 형태들을 생각해서 유사한 것을

묶을 수 있는 범주화가 필요할 것입니다

범주화는 이전 포스팅에서 알아보았습니다

우리가 결국 만드는 것은 저장 구조입니다

그 구조의 형태는 스프레드 시트와 같은 2차원 표며,

그 표에 어떤 데이터를 어떻게 관리할 것인지를 고민하는 것이 데이터 모델링입니다

이렇게 우리는 이론적으로 간단하게 생각할 수도 있는 스키마 구조를

본능적으로 이러한 것들을 생각하면서 모델링할 수도 있습니다

하지만 이러한 것들을 생각을 하고 관점을 높일 수 있는 것은 좋은 것 같습니다

개념 모델, 논리 모델, 물리 모델, 그리고 현실적인 논리 모델

데이터 모델을 보는 3가지 관점으로

개념 모델, 논리 모델, 물리 모델이 있습니다.

논리 모델은 물리적인 요소를 고려하지 않고 업무 관점의 모델이며

물리 모델은 물리적인 요소를 고려한 현실적인 모델입니다.

이렇게 관점에 대해 듣다 보면 의문점이 생기기 마련입니다.

논리 모델에서 현실적인 항목을 반영하면 잘못된 것인가?

논리 모델과 물리 모델 간의 차이가 심하면 모델링은 잘못된 것인가?

그리고 개념 모델은 어느 정도의 수준의 모델인가?

이런 의문점을 해결하기 위해서는 

우선 개념 모델링에 대해 정확하게 이해하는 것이 좋습니다.

개념 모델은 주식 별자는 물론이며

엔터티 간의 관계와 주요 속성이 모두 그려진 구체적인 모델입니다.

개념 모델은 가장 특징적인 주요 속성 및 식별까지만 도출해서 전체적인 그림을 그리는 것입니다

품질 좋은 논리 모델을 만들기 위해 반드시 거쳐야 합니다.

논리 모델은 주요 엔터티뿐 아니라

모든 엔터티와 개별 엔터티의 속성이 모두 도출된 구체적이고 정규화된 모델입니다.

논리 모델은 업무 데이터를 테이블 수준이 아닌,

정보 요구사항을 인간이 이해하기 가장 적합한 수준으로

통합하거나 분리한 형태의 모델입니다.

이렇게 개념 모델은 논리 모델을 정확하게 그리기 위해 구체적인 뼈대를 형성하여 만들고

논리 모델은 그 뼈대를 바탕으로 살을 붙이는 과정입니다.

그렇다면 개념 모델은 어느 정도 수준으로 모델링해야 할지 알 수 있을 것입니다. 

이제 남은 것은 물리 모델과 논리 모델의 차이점과 역할을 분명히 할 필요가 있겠습니다.

논리 모델에서 성능 이슈는 아니지만

전체 구조에 영향을 미치는 요소들은 좀 더 일찍 결정하는 것이 중요합니다.

그래서 물리 모델에서는 무결성이 조금 손상되더라도

성능과 같은 현실적인 이슈를 최대한 해결하기 위한 작업이라고 할 수 있습니다

그러니 논리에서는 최대한 사람이 이해하기 가장 쉬우면서

가능한 한 테이블에 유사한 형태의 모델이어야 합니다.

그렇게 작업이 된 상태에서 물리 모델을 적용해서 성능 이슈를 해결해야 할 것입니다

프로젝트 성패를 결정짓는 데이터 모델링 이야기 中 by김상래

오늘의 포스팅은 

이전에 많이 배웠던 기본적인 것들이었습니다

3가지 관점과 3단계 스키마를 단 3줄로 정리된 이론적이 것이었지요

하지만 이렇게 관점을 어떻게 보고 어떻게 생각하는지에 대한

사고력을 높이는 것은 상당히 좋은 경험이었던 것 같습니다

오늘도 이렇게 좋은 한 걸음을 나아간 것 같습니다

그럼 다음 포스팅도 기대해주세요

이전 포스팅에서는 데이터 관점에 대해서 알아보았습니다

그 관점이라는 것은 우리가 필요로 하는 데이터 값을 결정할 때

여러 가지 정보가 기준이 되어 데이터 값에 영향을 주었다면 그 여러 가지 정보가 관점이 됩니다

이렇듯 하나의 데이터에 여러 가지의 관점이 적용되어 데이터가 돌출되는 상황을 잘 이해해야겠죠?

아래에 더 상세한 설명이 있으니 궁금하신 분들은 한번 읽어보시길 바랍니다

2022.08.04 - [Data_Modeling/Methodology] - 데이터의 관점을 제대로 이해해야 하는 이유는? 디멘션 모델링?

그럼 본론으로 데이터 모델링 시 개체의 본질과 역할의 정보가 무엇인지 제대로 알고

구분을 해야 하는 이유를 알아보도록 하겠습니다

데이터 모델링에 개체의 본질이라는 것은 무엇일까?

먼저 본질의 사전적 의미는 대상의 가장 핵심적이고 필수 적인 속성이라고 합니다

단어들이 어렵고 복잡할 수 있습니다

천천히 같이 알아보도록 합시다

우선 한 가지 사례를 살펴보고 더 이야기를 이어나가도록 합시다

아래의 이미지에서 셋 중에 관련이 더 높은 것을 묶어야 한다면 어떤 선택을 하시겠습니까?

동양인의 인식체계는 현상과 관계를 중시합니다

그래서 원숭이는 바나나를 좋아한다라는 행위적 관점에서 바라보게 되고 이 둘이 더 밀접하다고 판단합니다

서양인의 경우는 범주에 의한 분류 사물의 본질을 중시합니다

그래서 포유동물인 원숭이와 판다가 식물인 바나나보다 가까워 원숭이와 판다가 더 밀접하다고 생각합니다

이러한 이유는

개인주의적이고 독립적인 서양 사회의 특성으로

전체 맥락에서 개별 사물을 떼어내어 분석하는 것이 익숙하기 때문입니다

그래서

고대 그리스 철학자들이 세상을 이해는 방식이 데이터 모델링의 영역과 맞닿아 있습니다

사물의 속성 자체에 주의를 기울이고,

그 속성에 근거하여 범주화하고,

그 범주들을 사용해서 규칙을 만들고,

사물의 특성과 움직임을 그 규칙으로 설명한다.

하지만 동양인은 규칙과 무관한 개체 간의 표면적인 유사성에 영향을 받기 쉽습니다 

겉으로 드러나는 현상과 우리가 인식하는 형식의 본질,

즉 궁극적 원인과 분리되어야 합니다

본질적인 현상은 추구하지 않고 겉으로 드러나 보이는 현상에만 집착하는 것은 옳은 방법이 아닙니다

근본적인 존재, 성질, 모습을 분석해야 합니다

이렇게

본질을 제대로 알게 되면 그 속성을 근거하여  동일한 성격을 가진 개체들을 묶을 수 있습니다

즉 범주화하는 것이 가능합니다

본질적 개체가 아닌 역할 별 개체가 가지는 문제

어느 산업은행의 정보시스템에서

직원, 고객, 공급자의 정보를 별도의 엔터티로 관리한다면

<직원> 엔터티의 B와

<공급자> 엔터티 B는 완전히 다른 개체로 취급됩니다.

이는 고객관계 관리의 고객 통합 영역에서 항상 언급되는 동일인 인식 문제에 해당됩니다.

앞서 원숭이와 바나나 이야기를 하면서 본질과 현상을 구분해서 볼 수 있어야 한다고 했습니다.

그렇다면 은행 사례에서의 본질은 무엇일까요?

그리고 현상은 무엇일까요?

본질은 물질적으로 유일한 B라는 개체의 정보,

즉 성명과 같은 사람의 근본적인 정보가 본질에 해당합니다.

비즈니스적으로 어떤 행위에 관여하는지와 무관한 자연인으로서의 정보입니다.

현상은 B가 수행하는 직원, 고객, 공급자라는 3가지 배역은 현상이라고 해야 합니다.

이렇듯 본질적인 개체가 아닌 역할별 개체만을 관리할 경우 발생할 수 있는 문제가 바로 여기서 나오는 이야기입니다.

다시 말해

본질은 사람으로서의 근본적인 정보(물리적으로 유일한 개체인 나)이며,

현상은 논리적 맥락이나 역할(교수, 학생, 고객, 은행원 등)입니다

B라는 존재는 인터넷 뱅킹으로 이체할 때는 고객이 되고,

프린터를 조달할 때는 공급자가 되며,

연말에 인사 고과를 받을 때는 직원이 됩니다.

이렇듯 엔터티를 역할만으로 정의할 경우 개체의 본질적 정보를 관리할 때 다양한 문제가 발생합니다.

그러니 본질과 현상의 차이를 다시 한번 잘 새겨보시길 바랍니다.

어머니를 어머니로만 바라보지 않고 한 여인, 존엄한 인격체로서 바라보게 되면

그 전에는 보이지 않던, 풍경이 들어오기 시작합니다.

범주화와 추상화의 중요성

복잡한 현실 업무의 속성과 규칙을 모델로 정형화하려면

비즈니스 문제 영역의 데이터를 관찰해서 그 안에 숨어 있는 유형과 관계를 찾아내야 합니다.

범주화는 유사한 것들을 일정하게 묶는 과정이며,

추상화는 문제 영역에서 가장 핵심적인 특성만 추리는 과정입니다.

추상화는 현실의 복잡함을 단순화하여 일목요연하게 파악하게 해주는 도구가 될 수도 있는 반면,

단순화하는 과정에서 구체성과 다양성이 소거되어 실재를 정확히 반영하지 못할 수도 있습니다

따라서 우리는 추상화 수준을 항상 고심하게 되며, 적절한 절충점을 결정하는 것 역시 모델러의 필수 역량입니다

즉, 지금까지의 이야기를 종합한다면,

데이터 모델링의 엔터티란 범주화를 통해 만들어진 집합이며,

모델링은 정보를 담는 최소 단위인 본질의 속성을 분석합니다

즉, 추상화에서 유사한 것은 모으고 독립적인 것은 분리하는 과정입니다

이러한 과정을 통하여 속성의 엔터티를 찾아낼 수 있습니다

즉, 관계형 데이터 모델은 나의 정보는 내가 집약해서 갖고,

남의 정보는 필요할 때 관계를 통해 찾아서 원하는 뷰를 만들 내는 구조입니다

데이터 모델링은 결국 어떤 개체의 본질에 맞게 범주화하며,

개체를 추상화 과정에서 분리하고 묶는 수준을 고민하는 과정입니다

범주화와 추상화까지 어려운 용어들로 채워진 이번 포스팅은 

타자를 치면서 몇 번을 곱씹었는지 알 수가 없었습니다

그만큼 어려웠고 이해를 하기가 힘든 부분이 너무 많았습니다

다른 사람은 이런 이론적인 부분은 필요 없다고 말하지만

저는 이러한 관점을 한번 생각해보는 것이 데이터 모델링에 정말 필요한 학습이라고 생각합니다

이렇게 데이터 모델링 공부를 한걸음 끝이 났네요

하지만 아직 갈길이 너무 머네요

다음 년에는 데이터 모델링 쪽으로 일을 할 수 있게 착실히 준비해 놓아야겠습니다

같이 힘내 보아요!

우리의 대모험은 아직 끝나지 않았으니까요!?

데이터를 모델링한다는 것은 데이터 관점을 읽어 모델링 하는 것

디멘션은 팩트를 그룹화 하거나 한정화(필터링)하는 목적으로 사용한다

일반적으로 디멘션 혹은 그룹핑을 위한 논리적인 계층구조는 1:M형태의 부모-자식 관계를 만든다

팩트 테이블의 상위 테이블이 되어야 하며, 디멘션은 다시 상 하위 테이블로 분리되어야한다

현대, 기아, 싸용을 묶는 상위 개념의 국산 완성차업체라고 정의 하는것 처럼

이렇듯 디멘션을 생각하며 아래의 테이블을 생각해보자

위의 표를 유심히 관찰해보면 각 셀의 값을 결정 하는 데 지역, 상품, 기간(년도)이라는 3가지 정보가 영향을 주고 있다

판매량을 집계하는 기준이 존재하는 것, 87개 판매되었다는 사실을 나타낸다

즉 87은 강원도 원주시라는 지역

상품유형은 B고 상품 번호는 B1인 상품

2014년이라는 기간

위의 3가지 관점(디멘션)이 결합된 값이다

87이라는 값이 정보로서 비즈니스적인 가치를 가지려면 그값을 해석하는 맥락이 명확해야한다.

그리고 디멘션이 팩트를 결정하는 기준 정보로서의 부모역활을 하게된다는 것을 명심해야한다

위의 표처럼 관점(디멘션)과 그룹핑 구조를 확인할 수 있다

기간별, 지역별, 상품별, 판매량에서 '~별' 디멘션은 데이터를 해당 디멘션으로 한정하는 동시에 구조화할 수 있다

또한 지역 중분류 지역 소분류와 같은 그룹핑 구조는 유형화를 위한 데이터 계층 조직화를 구축할 수 있다

결론적으로 판매량의 데이터를 어떠한 관점으로 보는지가 가장 중요하며

그 관점을 지역별, 상품별, 판매량이라는 관점을 데이터로 나타낼 수 있게 데이터 모델링 하는것이 핵심이다

데이터 모델링은 말이 어렵고 책을 읽어도 이해하기 힘들다

하지만 제일 처음 이미지를 보면서 요건을 받고 업무를 이해할 때

관점을 파악하고 기준을 제대로 잡는것이 중요하다

한번에 모든 것을 이해못하지만 사례를 계속 살펴보고 읽어보는것이 가장중요한것같다

아무리 관점을 잘 파악하고 업무요건을 잘 정립한다고해도

그 업무에 대해 경험도는 다른 무엇보다 중요하다

그 경험이라는 것은 무시할 수 없기에 요건을 정립하고 업무 파악을 해서

데이터 모델링을 한다고해도 예기치 못한 변수는 발생할 수 밖에 없다

그것을 사전에 예방할 수 있는 방법은 경험밖에 없다고 생각한다

프로젝트를 수행할 때 개발자로 업무를 수행한다고해도

테이블 설계도를 보면서 미리미리 업무를 공부하며 테이블 구조를 보면서 

지금 하고 있는 업무 파악을 좀더 확실히 하고 메모하고 정리 해두어야

그것이 자기의 실력이 되고 누구에게도 인정받는 사람이 될 수 있을 거라 생각한다

데이터 모델링을 한다는 것은 데이터를 이해하고 유형화하여 구조화하는 과정이라고 생각하며

데이터에는 본질을 기준으로 한 몇 가지 유형이 존재한다고 생각한다

데이터 간에는 종속 관계와 계층관계도 존재한다는 것을 생각하고 계속 어떠한 상황에도

데이터 모델링을 관점으로 생각하자

애플리케이션 화면과 RDB의 테이블은 다르다

 - 데이터 모델링에 대한 이해와 경험이 부족한 사람들은 GUI 화면과 테이블을 거의 1:1로 인식하거나 데이터를 조회할 경우 테이블 조인을 직관적인 한가지만 보고 조인할 경우 다른 어떠한 경우에는 원하는 데이터가 나오지 않는 경우가 있다

이렇듯 화면에 구성되어있는 주문서 한장에도 체계적으로 조직화된 하나의 집합체로 구성되어있다

즉, 데이터 모델링은 최종 사용자에게 보이는 하나의 집하체에서 데이터의 구조적인 부분을 분리하는 작업이다

아주 기초적인 질문이지만 하나의 화면에 포함된 데이터들을 여러 테이블, 여러 행으로 분리하는 이유는 무엇일까??

그 이유는 데이터 관리(저장, 수정, 조회등)에 유리하기 때문이다.

중요한 점은 각 부분을 왜 분리해야하는지 그 이유를 정확하게 알고 있어야한다

• 데이터 구조로서의 분리해야 하는 이유
• 테이블을 분리하는 기준과 규칙등 방법론

위와 같은 이유를 알고 분석하려면 데이터를 이해하고 업무 데이터를 어떻게 읽고 분석해야하는지가 가장 중요하다

아래와 같은 사례로 중요한 점을 생각하며 살펴보자

설문 데이터 모델링, 데이터 본질을 읽어 모델링하다

- 정보 시스템으로 관리하려면 데이터 성격과 주제 유사함을 중심으로 구조화해야 한다.

- 즉, 데이터의 유형을 기준으로 관련된것을 묶어내는 과정이 필요하다

- 이를 위해서는 데이터를 이해하는 것이 무엇보다 중요하다

• <회원>, <회원설문참여>, <설문응답>, <설문지>, <설문질문>, <설문보기> 릴레이션이 존재한다고 가정한다.
• A라는 설문의 어떤 질문과 B 설문의 동일 질문을 별개로 인식하고 관리할 것인가? 
• 회사는 업무 특성상 설문을 자주하며, 일반적인 설문을 DB화해서 만들어진 질문과 보기를 패턴화할 것인가?
• 보기는 질문에 종속되지 않고, 질문은 설문지에 종속되지 않은 독립개체로 정의하고 관리할 것인가?
• 독립개체로 정의해서 릴레이션을 개별적으로 정의해야한다 <설문지질문구성>과 <설문지질문보기구성>이 된다
• 좌에서 우로 변경된 릴레이션을 확인할 수 있다.

위와 같이 생각을 하고 아래와 같이 테이블을 생성했다면

질문과 보기를 주변 맥락에서 분리하여 독릭된 객체로 관리해야한다면 다시 모델링을 해야한다

패턴화를 필요로 하며 그럴려면 설문질문에서 여러 질문을 조합하고 보기를 구성하여 하나의 설문지를 만들어내는 것까지

테이블 구성이 필요하기때문이다

아래와 같이  변경이 가능하다

위의 사례로 중요한 것은 업무요건을 보면 데이터가 보여야하고, 업무에서 흘러 다니는 데이터의 성격과 고유한 근본 성질을 이해할 수 있어야한다. 그래서 현장에서도 업무파악이 무엇보다 중요하다 데이터를 조합은 업무파악에서 시작이다 

올바른 데이터 모델링을 위한 기본기

1. 데이터 근본 성격 파악 -> 데이터 집합과 개체 식별
2. 데이터 종속성 분리 -> 데이터의 독립성 확인과 모델 골격조망

업무를 데이터 중심으로 바라볼 수 있는 시선을 소개하며 데이터 모델링을 위해 데이터를 이해한다는것이 무엇인지 업무적으로 어떻게 관리되고 혹은 어떻게 관리되어있는지를 명확하게 해야한다

프로젝트 성패를 결정짓는 데이터 모델링 이야기/ 김상래저