데이터 모델링 Account와 같은 상위 개체 집합인 행위 주체가 누락 된다면?

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

 

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

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

 

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

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

 

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

 

 

 

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

데이터 모델링 업무 행위의 논리적 주체란 무엇일까?

 

---

 

 

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

 

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

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

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

 

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

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

 

주체가 없는 데이터 테이블의 구성도

 

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

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

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

 

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

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

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

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

 

행위의 주체가 되는

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

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

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

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

 

 

반응형

 

주문을 대표하는 개체가

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

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

 

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

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

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

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

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

 

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

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

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

 

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

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

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

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

행위의 주체가 필요한지? 

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

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

 

---

 

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

 

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

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

 

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

 

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

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

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

 

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

Account 꼭 기억하세요!