관계를 그려라
28개 언어로도 제공
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Data Architect 과정 2장인 의미를 위한 데이터 모델링의 모듈 2/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 명사를 들어라 · 다음: 논리 모델을 만들어라
이 모듈이 답하는 질문: 후보 엔터티를 어떻게 개념 데이터 모델로 바꿀까요?
보드에 명사들이 있습니다. 이제 저는 상자 사이의 선에 대해 알고 싶습니다. 엔터티를 모아 놓은 것만으로는 아직 데이터 모델이 아니기 때문입니다. 의미의 상당 부분은 관계에 있습니다. 리테일 파트너는 물류 센터들을 운영합니다. 배송 목록에는 배송들이 나열됩니다. 배송은 수령인에게 갑니다. 배송팀이 트럭을 운행합니다. 그 문장 하나하나가 비즈니스에 대해 무언가를 알려 주고, 하나하나가 물어볼 질문을 또 하나 줍니다.
비즈니스 언어에서 시작하라
섹션 제목: “비즈니스 언어에서 시작하라 ”아직 Salesforce 이야기는 하고 싶지 않습니다. 조회 관계로 할지 마스터-세부 사항 관계로 할지 묻지도, Salesforce 연결 개체(Salesforce Junction Object)를 생각하지도, 상위 레코드가 삭제되면 어떻게 될지 정하지도 않습니다. 비즈니스 관계를 이해하려는 중입니다.
**“리테일 파트너는 물류 센터들을 운영한다”**를 보십시오. 단순하게 들립니다. 하지만 리테일 파트너는 물류 센터를 하나 가질까요, 여럿 가질까요? Steve Trucking에서는 각 리테일 파트너가 Steve Trucking이 서비스하는 모든 지역에서 지역 물류 센터를 하나씩 운영하므로 여럿입니다. 물류 센터 하나가 둘 이상의 리테일 파트너에 속할 수 있나요? 물류 센터는 자기 직원과 이력을 가진 독립된 존재로서 중요한가요, 아니면 그냥 주소인가요? 리테일 파트너가 떠나도 그 물류 센터들이 여전히 중요한가요?
이것은 Salesforce 질문이 아닙니다. 비즈니스 질문이고, 그 답이 모델을 완전히 바꿀 수 있습니다.
선을 읽어라
섹션 제목: “선을 읽어라 ”더 깊이 들어가기 전에, 지금부터 모든 다이어그램에서 쓸 언어를 드리겠습니다. 작은 언어입니다. 두 상자 사이의 선은 둘이 관계가 있다는 뜻이고, 선 끝의 표시는 몇 개인지를 말합니다.
아무 표시 없는 맨 선부터 시작하십시오. 화이트보드에서 제가 시작하는 곳이 거기입니다. 이 두 명사가 관련 있다는 건 알지만, 아직 어떻게인지 묻지 않았을 뿐입니다. 그다음 선 끝에 표시가 붙습니다. 선을 가로지르는 짧은 막대 하나, 십자는 하나를 뜻합니다. 까마귀 발(crow’s foot), 즉 새의 발처럼 세 갈래로 갈라진 끝은 여럿을 뜻합니다. 이 모듈 후반에는 첫 표시 옆에 막대나 동그라미로 된 두 번째 표시가 나타나는데, 그것은 다른 질문에 답합니다. 하나도 없을 수 있는가?
기억할 규칙은 하나입니다. 각 표시는 그것이 닿은 상자 쪽에서 읽는다. 상자에 가장 가까운 표시가 최대치이고, 그다음 표시가 최소치입니다.
앉아, 기다려, 모델링
섹션 제목: “앉아, 기다려, 모델링 ”Steve Trucking으로 가기 전에, 모듈 1의 개들로 돌아갑시다. 상자가 다섯 개 있었습니다. 주인, 브리더, 개, 품종, 재주. 이제 그 사이의 선에 대해 묻습니다.
하나인가 여럿인가? 주인은 개를 두 마리 이상 키울 수 있습니다. 아나는 두 마리를 키웁니다. 개의 주인은 한 명입니다. 적어도 우리 모델에서는요. 이것이 일대다입니다. 주인 쪽에 막대, 개 쪽에 까마귀 발. 브리더도 같은 모양입니다. 브리더 한 곳이 많은 개를 번식시킵니다.
없을 수도 있는가? 맥스는 유기견 보호소에서 왔으므로 브리더가 전혀 없습니다. 브리더 쪽 끝에는 동그라미가 붙습니다. 개에게 브리더는 0이거나 하나입니다. 하지만 모든 개에게는 주인이 있으므로, 그쪽 끝에는 막대가 하나 더 붙습니다. 정확히 하나.
다대다인가? 개 한 마리는 재주를 많이 알고, 재주 하나, 예를 들어 앉아는 많은 개가 압니다. 이것이 다대다이고, 바로 거기서 저는 숨은 개념을 찾으러 갑니다. 이 개가 이 재주를 안다는 것에 관해 무언가가 있을까요? 얼마나 잘하는지, 그리고 언제 배웠는지. 관계에 자기만의 사실이 있으니, 관계가 독립된 것이 됩니다. 개 재주(Dog Trick). 개의 이름이 먼저 옵니다. 그것을 이끄는 쪽이 개이기 때문입니다.
각 선은 무엇을 의미하는가? 주인은 개를 키운다. 브리더는 개를 번식시킨다. 개는 자기 재주를 안다. 선에 이름을 붙이면 누구나 모델을 다시 읽어 줄 수 있습니다.
지금인가, 시간에 걸쳐서인가? 벨라가 오늘 앉아를 얼마나 잘하는지가 중요할까요, 아니면 어떻게 거기까지 왔는지가 중요할까요? 훈련사가 몇 달마다 벨라를 확인한다면, 확인 하나하나가 독립된 레코드입니다. 재주 평가(Trick Assessment). 날짜, 숙련도, 확인한 사람을 담고, 자기가 속한 개 재주 아래에 놓입니다. 독립된 것이 된 관계조차 자기만의 이력을 가질 수 있습니다.
품종은 지금은 연결하지 않고 둡니다. 여전히 모듈 1의 질문, 즉 독립된 상자인가 개에 적힌 단어인가이고, 모듈 4에서 결론이 납니다.
그 질문들은 하나하나 실제 비즈니스에서도 똑같이 통합니다. 이제 Steve Trucking에 물어봅시다.
“하나인가 여럿인가?”를 물어라
섹션 제목: ““하나인가 여럿인가?”를 물어라 ”관계에 대해 제가 가장 먼저 이해하고 싶은 것 중 하나는 카디널리티입니다. 데이터베이스 용어이고, 질문은 훨씬 단순합니다. 이것 몇 개가 저것 몇 개와 연결될 수 있는가? 개념 수준에는 기본 패턴이 세 가지 있습니다.
이것은 과정에서 중요한 단계입니다. 서로 다른 두 명사를 놓고 그 관계를 이해하는 것. 대부분의 경우 일대다, 또는 다대일입니다. 일대일을 만나는 것은 드문 경우뿐입니다.
일대다는 어디에나 있습니다. 리테일 파트너 하나가 물류 센터 여럿을 가집니다. 배송 목록 하나에 배송 여럿이 나열됩니다. 경로 하나에 정차지가 열 곳쯤 있습니다. 그런 말을 들으면 저는 선을 긋기 시작합니다.
이제 선에 표시가 붙습니다. 각 끝은 그것이 닿은 상자가 몇 개인지 말해 줍니다. 하나는 막대, 여럿은 까마귀 발입니다. 각 상자에서 읽으십시오. 리테일 파트너 하나는 물류 센터 여럿을 가진다.
일대일 관계는 존재하지만 드물고, 하나를 발견하면 저는 몇 가지를 묻습니다. 정말 서로 다른 두 명사인가, 같은 것인가? 다르다면 둘 사이의 일대일 관계는 무엇인가? 그리고 늘 일대일일까, 아니면 지금만 일대일일까? 데이터 모델 설계의 핵심 질문입니다. 배송팀과 트럭은 어느 아침에 보면 일대일처럼 보입니다. 두 사람, 트럭 한 대, 경로 하나. 한 달에 걸쳐 보면 그렇지 않고, 이 모델에서 가장 흥미로운 관계가 바로 거기 숨어 있습니다.
다대다 관계는 특히 흥미롭습니다. 비즈니스에 또 다른 개념이 있다는 신호인 경우가 많기 때문입니다. 배송팀이 시간에 걸쳐 트럭 여러 대를 몰 수 있나요? 네. 트럭 한 대를 여러 배송팀이 몰 수 있나요? 트럭의 수명 동안이라면 당연히요. 그러니 배송팀과 트럭은 다대다 관계입니다. 하지만 이제 더 알고 싶어집니다. 비즈니스는 어떤 배송팀이 언제 그 트럭을 가졌는지 신경 쓸까요? 어느 경로, 어느 날에? 누가 배정했나요? 관계 자체가 우리가 신경 쓰는 정보를 담고 있다면, 또 하나의 비즈니스 개념을 발견한 것입니다. 배송팀 배정(Crew Assignment)입니다.
중요한 모델링 습관입니다. 때로는 가장 흥미로운 것이 처음 들은 명사 중 하나가 아닙니다. 두 명사 사이의 관계 속에 숨어 있습니다.
관계도 실체가 될 수 있다
섹션 제목: “관계도 실체가 될 수 있다 ”관리자들이 다르게 생각하기 시작했으면 하는 지점 중 하나입니다. Salesforce에서 우리는 개체와 필드로 이야기하는 데 익숙해서, 상자를 중요한 부분으로, 선을 배관처럼 여기기 쉽습니다. 하지만 관계 자체가 비즈니스 의미를 가질 수 있습니다.
배송과 거기에 실린 제품을 생각해 보십시오. 배송 하나에 여러 제품, 이를테면 세탁기와 건조기가 실릴 수 있습니다. 같은 냉장고 모델 같은 제품 하나는 수천 건의 배송에 등장합니다. 여기까지는 쉽습니다. 하지만 이 배송에 그 제품이 몇 개 실렸는지, 설치하는지, 헌 제품을 수거하는지 알아야 한다면요? 이제 배송과 제품 사이의 관계에만 관심 있는 게 아닙니다. 배송 품목(Delivery Item)에 관심이 있고, 그 개념은 자기 엔터티를 가질 자격이 있습니다.
Salesforce 출신이라면 벌써 “그거 연결 개체네”라고 생각하고 있을지도 모릅니다. 틀리지 않았습니다. 하지만 저는 거기서 시작하고 싶지 않습니다. 배송 품목은 Salesforce 연결 개체이기 전에 비즈니스 개념입니다. 비즈니스가 먼저, 구현은 그다음.
이런 관계 엔터티에 대해, 결국 어디에 구현되든 제가 가진 습관 몇 가지입니다.
이름을 붙여라. 비즈니스에 이미 그것을 부르는 말이 있다면 그 말을 쓰십시오. 없다면 두 부모의 이름을 합치십시오. 주문과 제품을 생각해 보십시오. 그 사이에 있는 것은 Order Item, 즉 주문과 주문 안의 품목입니다. 두 부모 모두의 자식이고, Salesforce에서는 Salesforce 연결 개체가 될 수 있습니다. 그런데 어느 이름이 먼저일까요? Item Order일까요, Order Item일까요? 각 부모가 어떤 종류의 데이터인지 보십시오. 제품은 참조 데이터이고, 주문은 트랜잭션이며, 그것을 이끄는 것은 주문입니다. 그래서 Salesforce에 Opportunity Product가 있는 것처럼 Order Item, 또는 Order Product입니다. Steve Trucking에서는 Delivery Item(배송 품목)입니다. 이끄는 쪽의 이름이 먼저 오고, 그러면 그 레코드는 앞으로 보게 될 모든 목록에서 주인 옆에 정렬됩니다. (한국어에서도 “배송 품목”처럼 이끄는 말이 앞에 오니, 원칙이 그대로 통합니다.)
자기 키를 주어라. 배송 품목을 배송과 제품의 조합으로 식별한다고 말하고 끝내고 싶어집니다. 그것은 복합 키이고, 복합 키는 다루기가 훨씬 어렵습니다. 그 레코드를 가리키는 모든 시스템이 두 반쪽을 다 들고 다녀야 합니다. 관계 엔터티에 자기 식별자를 주고, 배송과 제품의 조합은 정체성이 아니라 고유성에 대한 규칙으로 두십시오.
여기에 없는 것에 주목하십시오. 일련번호입니다. 수량과 일련번호는 같은 레코드에 속하지 않습니다. 수량은 어떤 것의 여러 개를 세고, 일련번호는 특정한 하나를 식별합니다. 비즈니스에 일련번호가 필요하다면 각 단위가 자기 레코드가 되고, 냉장고 다섯 대는 레코드 다섯 개가 됩니다. 저는 배송 품목 아래에 배송 품목 세부 정보를 두는 경우를 떠올릴 수 없습니다. 둘 중 하나입니다. 수량을 가진 집계, 또는 단위당 레코드 하나. 여기서는 수량입니다.
이력을 원하는 속성을 주시하라. 어떤 관계 엔터티는 생성되면 고정됩니다. 이 배송의 세탁기는 계속 이 배송의 세탁기입니다. 어떤 것은 계속 바뀝니다. 한 배송팀이 이번 주에 117번 트럭을 가졌다가 다음 주에는 그 트럭이 다른 배송팀으로 갑니다. 관계가 바뀌고 비즈니스가 이전 상태를 신경 쓴다면 관계 엔터티에 날짜가 필요하고, 주시해야 할 것이 배송팀 배정입니다. 비즈니스가 지금을 신경 쓰는지 시간에 걸친 것을 신경 쓰는지 일찍 물으십시오. 곧 다시 다룹니다.
관계에는 카디널리티 너머의 의미가 있다
섹션 제목: “관계에는 카디널리티 너머의 의미가 있다 ”“일대다”만으로는 관계를 이해하기에 부족합니다. 저는 관계가 무엇을 의미하는지도 알고 싶습니다.
배송에는 위치가 있습니다. 어느 위치일까요? 출발하는 물류 센터? 도착하는 수령인의 집? 서로 바꿔 쓸 수 없습니다. 두 모델이 정확히 같은 상자와 같은 카디널리티를 가져도 선은 전혀 다른 것을 뜻할 수 있습니다. 그래서 좋은 모델은 선으로 이은 상자에 그치지 않습니다. 선에는 이름이 필요합니다. 제 다이어그램을 다른 아키텍트에게 건넸을 때 관계의 의미를 추측하게 해서는 안 되고, 비즈니스에 보여 줄 때는 그들이 알아보는 언어를 써야 합니다.
선택성도 중요하다
섹션 제목: “선택성도 중요하다 ”“몇 개인가?” 안에는 또 다른 질문이 숨어 있습니다. 관계가 필수인가? 배송이 경로에 배정되기 전에 존재할 수 있나요? 그래야 합니다. 배송 목록은 배송 하루이틀 전에 도착하고, 경로는 전날 저녁에 확정됩니다. 리테일 파트너 없이 배송이 존재할 수 있나요? 아니요. 모든 배송은 파트너의 배송 목록에서 옵니다. 이것이 선택성입니다.
이번에도 곧장 Salesforce의 필수 체크박스로 뛰어들지 마십시오. “모든 배송에는 리테일 파트너가 있어야 한다”와 “레코드를 만들 때 Salesforce가 리테일 파트너 필드를 필수로 요구해야 한다”는 다릅니다. 결국 같은 구현이 될 수는 있지만 같은 진술은 아닙니다. 앞의 것은 비즈니스 규칙이고, 뒤의 것은 그것을 시행하는 한 가지 방법입니다. 아키텍트로서 우리는 뒤의 것을 정하기 전에 앞의 것을 이해하고 싶습니다.
다이어그램에서 선택성은 각 끝의 두 번째 표시입니다. 상자에 가장 가까운 표시는 최대치입니다. 하나는 막대, 여럿은 까마귀 발. 그다음 표시는 최소치입니다. 막대가 하나 더 있으면 최소 하나, 동그라미면 0일 수 있다는 뜻입니다. 그러니 모든 배송은 정확히 하나의 배송 목록에 있고, 배송 목록 하나에는 배송이 하나 이상 나열됩니다. 배송은 정차지 0개 또는 1개에 속하고, 경로에 배정되기 전에는 없으며, 정차지 하나에서는 배송 0건 이상이 내려집니다.
시간은 관계를 바꾼다
섹션 제목: “시간은 관계를 바꾼다 ”제가 자주 하는 질문이 있습니다. 지금을 말하는 건가요, 시간에 걸친 걸 말하는 건가요?
배송팀이 트럭을 운행합니다. 지금? 오늘의 경로에서? 그 두 사람이 함께 일하는 동안 계속? 각각 다른 모델이 나옵니다. 비즈니스가 오늘 배송팀이 어느 트럭을 가졌는지만 신경 쓴다면 모델은 단순하게 유지될 수 있습니다. 배송팀이 몰았던 모든 트럭과 그 시기와 경로가 필요하다면 이력이 필요하고, 우리가 발견한 배송팀 배정이 갑자기 아주 중요해집니다.
이것은 흔한 모델링 실수의 원인입니다. 화면에 보이는 것이 현재 상태이니 현재 상태를 모델링합니다. 그러다 몇 주 뒤 리테일 파트너가 파손 클레임을 제기하고 누군가 묻습니다. “3월 17일에 117번 트럭은 어느 배송팀이 몰았지?” 그리고 배정이 바뀔 때마다 그 답을 덮어써 왔다는 걸 알게 됩니다.
그 이력을 남기는 한 방법은 배정을 별도의 레코드로 만드는 것입니다. 배송팀이 배정되면 시작일을 가진 배송팀 배정을 만듭니다. 배정이 바뀌면 옛 레코드에 종료일을 넣고 새 시작일을 가진 새 레코드를 만듭니다. 이제 “6개월 전에 그 배정을 누가 가졌지?”는 필드 기록이나 데이터 변경 로그를 뒤지는 대신 쉽게 답할 수 있는 질문이 됩니다. 그리고 한 배송팀이 배정을 여러 번 거치면 누군가 어느 것이 현재 배정인지 물을 테니, 활성(Active) 플래그도 추가하겠습니다.
그러니 누군가 관계에 대해 말해 주면, 저는 그것들이 어떻게 연결되는지만 묻지 않습니다. **그 관계가 바뀌는가, 그리고 우리는 그 이력을 신경 쓰는가?**를 묻습니다.
구성하기 전에 그려라
섹션 제목: “구성하기 전에 그려라 ”우리의 Steve Trucking 모델이 쓸모 있어지고 있습니다. 어떤 관계가 일대다인지, 어디서 다대다가 다른 개념을 숨기는지, 어떤 관계가 선택적인지, 어떤 것이 시간에 따라 바뀌는지 압니다. 그리고 아직 Salesforce 개체를 하나도 만들지 않았습니다. 의도된 것입니다.
이 다이어그램은 비즈니스 앞에 놓을 수 있는 것이어야 하고, 그들은 Salesforce를 몰라도 그것이 맞는지 말할 수 있어야 합니다. Salesforce 용어로 가득해서 그들이 검증할 수 없다면, 저는 너무 빨리 물리 설계로 넘어간 것입니다.
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”개념 모델의 관계를 다룰 때, 저는 이것을 결정합니다.
- 주요 비즈니스 엔터티들이 서로 어떻게 연결되는지.
- 각 관계가 지금과 시간에 걸쳐 일대일, 일대다, 다대다 중 무엇인지.
- 각 관계가 필수인지 선택인지.
- 다대다 관계가 의미 있는 비즈니스 개념을 숨기고 있는지.
- 관계가 시간에 따라 바뀌는지, 그리고 그 이력이 필요한지.
조회냐 마스터-세부 사항이냐, 연결 구성, 연쇄 동작, 공유는 물리적 결정이며, 거기까지 갈 것입니다. 지금은 더 중요한 질문에 여전히 답하고 있습니다. 이 비즈니스는 실제로 어떻게 돌아가는가? 엔터티와 그 사이의 관계를 이해하고 나면, 그것들을 기술하는 세부를 더하기 시작할 수 있습니다. 그때 개념 모델이 논리 데이터 모델이 되기 시작합니다.