데이터 본질 썸네일형 리스트형 어떤 경우에 통합을 고려하는가? – 다양한 경우 이번 글에서는 통합을 고려할 수 있는 다양한 경우를 설명하겠습니다. 다양한 케이스를 소개하지만 결국은 데이터의 본질이 유사하다는 것으로 통하게 됩니다. 역할을 관리하는 엔터티는 [그림1]과 같이 통합 모델을 사용할 때가 많습니다. [그림1] 사원은 특정 계좌에 대해 관리사원·유치사원·주문사원 등 여러 가지 역할을 할 수 있습니다. 여러 역할에 따른 엔터티가 개별로 존재하는 것이 아니라 계좌관계사원 엔터티와 같은 통합 엔터티로 존재하는 것이 바람직합니다. [그림2]와 같이 대칭적인 업무를 관리하는 데이터도 통합을 고려할 수 있습니다. [그림2] 이경우 업무 성격은 대칭적이지만 데이터 성격은 유사합니다. [그림2]는 식별자가 같지만 식별자가 다르더라도(매출전표번호와 매입전표번호) 통합할 수 있습니다. 매도와.. 더보기 어떤 경우에 통합을 고려하는가? - 두 번째 지난 번에 설명한 데이터 성격이 유사하다는 것이 데이터 통합을 고려할 가장 중요한 요소입니다. - 데이터의 성격(본질)이 유사할 때, 즉 집합의 정의가 유사할 때 [그림1]은 고객이 요청한 알림 서비스를 관리하는 엔터티입니다. [그림1] 고객알림서비스 엔터티는 고객별 알림 서비스를 관리하는 엔터티이고, 계좌알림서비스 엔터티는 계좌별 알림 서비스를 관리하는 엔터티입니다. 어떤 종류의 알림 서비스를 원하는지와 어떻게 알림 서비스를 받는지, 서비스 신청 일자와 알림을 몇 번 반복하는지 등의 데이터 성격은 두 엔터티가 동일합니다. 단지 고객을 지정해 서비스를 하는지, 계좌를 지정해 서비스를 하는지가 달라 주 식별자가 달라졌습니다. 그래서 엔터티가 통합되지 못한 예제인데 통합 대상입니다(주 식별자가 다른 여러 엔.. 더보기 어떤 경우에 통합을 고려하는가? 지난 달에 프로젝트를 마치고 중국 여행을 다녀왔습니다. 빚을 내서라도 애들하고 여행하라는 글을 자주 봐서 이번에 빚을 냈습니다. ㅎ 사실 여행에 대한 중요성은 이미 알고 있죠. 여유가 없었을 뿐이죠. 여행을 하면 시야가 넓어집니다. 많은 생각을 할 수 있어 좋고… 홀로 3개월을 돌아다니던 그때가 생각나네요. 어쨌든 고생해서 여행은 갔다왔는데 마음이 풀렸는지 블러그 슬럼프가 왔습니다. 그래서 다시 마음을 다잡고 글을 올리려고 합니다. 오늘부터 데이터를 통합할 수 있는 여러 가지 경우를 설명하겠습니다. 어떻게 통합하느냐에 대한 얘기보다 어떤 것(무엇)을 통합하느냐에 대한 얘기입니다. 가장 원론적인 원칙이 데이터의 성격이 유사할 때입니다. - 데이터의 성격(본질)이 유사할 때, 즉 집합의 정의가 유사할 때 데.. 더보기 이전 1 다음
