체크포인트 1, Steve Trucking의 데이터 설계를 그리고 변호하라

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 과정의 파트 1을 마무리합니다. 제 풀이는 체크포인트 1에 있으니, 먼저 직접 해 보십시오.

시나리오

Steve Trucking은 라스트 마일 배송 회사입니다. 대형 매장인 리테일 파트너들이 가전, TV, 가구를 팔고, Steve Trucking의 2인 배송팀이 그것을 리테일 파트너의 고객(수령인)에게 배송하고, 일부는 설치하고, 오래된 제품은 수거해 갑니다. Steve Trucking 개요의 1–8절을 읽으십시오. 9절(막판 변경 사항)은 건드리지 마십시오. 그건 과정 마지막에 나옵니다.

요구사항

개요 5절(R1–R15)과 6절(S1–S5)의 모든 것. 이 체크포인트가 가장 많이 기대는 것들:

R1. 각 리테일 파트너의 배송 목록을 그 파트너의 형식(SFTP 파일, API, EDI)으로 받아, 다시 입력하지 않고 경로, 정차지, 품목으로 바꾼다.
R3. 각 리테일 파트너의 물류 센터 관리자는 포털에서 자기 배송, 예외, 사진, 클레임을 보고, 다른 파트너의 것은 결코 보지 않는다.
R4. 배송 목록은 당일에 수정된다. 경로 배정 후의 변경도 처리해야 한다.
S2. 리테일 파트너는 다른 파트너의 배송, 가격, 물량, 수령인을 결코 보아서는 안 된다.
S3. 수령인의 추적 링크는 그 배송 하나만 보여 주고, 계정 없이 작동하며, 만료된다.
S4. 수령인의 주소, 전화번호, 배송 메모는 개인정보다. 배송팀은 자기 정차지에 대해서만, 당일에만 그것을 본다.

제약 조건

영업일 하루 약 3,300건, 연간 100만 건의 배송, 매년 30% 성장. 배송당 품목 약 1.6개, 상태 변경 8회. 연간 사진 400만–500만 장. 하루 약 20만 건의 GPS 측정값.
미국의 Salesforce org 하나, 이미 Service Cloud, Field Service, 파트너 포털 운영 중. MuleSoft 라이선스 보유. Data 360 라이선스는 있지만 구현되지 않음.
리테일 파트너 셋, 통합 방식 셋. 물류 센터 아홉 곳.

과제

파트 1 설계를 그리고 변호하십시오. 1–6장에서 배운 것을 쓰십시오.

랜드스케이프(4장): Steve Trucking의 현재 상태 시스템 랜드스케이프를 스티브의 배치로 그리고, 모든 화살표에 무엇이 어떻게 움직이는지 표시하십시오.
모델(2장): 배송 도메인을 개념적으로, 그다음 논리적으로 모델링하십시오. 리테일 파트너, 물류 센터, 배송 목록, 배송, 품목, 경로, 트럭, 배송팀, 설치 체크리스트, 사진, 서명, 예외, 수령인. (과제 D1.)
물리 설계(3장): 그중 어느 것이 표준 개체이고(Field Service에는 작업 주문, 서비스 약속, 서비스 리소스, 서비스 영역이 있습니다) 어느 것이 사용자 정의 개체인가요? 파트너 사용자와 수령인에게는 어떤 라이선스가 필요한가요? 각 종류의 데이터는 어디에 있나요: org 안, 오프코어, 웨어하우스?
키(이 장): 리테일 파트너의 주문 줄을 여러분의 배송에 맞추는 키는 무엇이며, 경로 배정 후 배송 목록이 수정되면 어떻게 되나요? (과제 D3.)
수령인(이 장): 연락처, 개인 계정, 아니면 둘 다 아닌가요? 관계, 물량, 파트너 격리, 데이터의 수명 주기로 논증하십시오.
통합할 것인가(이 장): 수령인은 여러 파트너의 배송 목록에, 때로는 1년에 한 번 이상 나타납니다. 통합하겠습니까, 아니면 의도적으로 하지 않겠습니까? S2를 고려하면 위험은 무엇인가요? (과제 DC1, 막판 변경 없이.)
권한 원천: 다섯 가지 핵심 필드(파트너의 주문 참조, 배송 상태, 수령인의 전화번호, 배송 시간대, 파트너의 법적 이름)에 대해 누가 만들고, 누가 소유하고, 어느 시스템이 기준이며, 누가 바꿀 수 있는지 말하십시오.

각 결정을 두 가지 선택지로 쓰고, 그다음 여러분의 선택을 쓰십시오: “제 전문가적 의견으로는…”

토론

제 풀이는 체크포인트 1: Steve Trucking, 내가 설계한다면입니다. 상자만이 아니라 추론을 비교하십시오. 다르게 선택한 곳에서, 무엇을 얻고 무엇을 포기하는지 말할 수 있나요?

설계 검토

지금은 설계를 보관해 두십시오. 파트 2가 물량, 쿼리, 통합, 마이그레이션, 트랜잭션, 보안으로 그것을 시험하고, 18장의 검토 카드가 3년 차에 그것을 점검합니다.

다루는 시험 목표

DM-1, DM-2(데이터 모델 설계, 공유를 존중하는 모델)
MDM-1, MDM-2, MDM-3, MDM-4(마스터 관리, 권한 원천, 매칭, 추적 가능성)
SDM-1(라이선스), SDM-3(단일 뷰, 그리고 그것을 만들지 말아야 할 때)