DAY 73개념·실험팔란티어 온톨로지 I

링크 타입으로 객체 잇기

배송은 창고 한 곳에서 출발하지만 운송사는 여러 곳을 거칠 수 있습니다. 관계의 개수(카디널리티)에 따라 링크 타입을 외래 키로 만들지 조인 테이블로 만들지가 갈립니다.

약 20분조작형 실험 확인 퀴즈

01 / UNDERSTAND

핵심 개념

링크 타입(Link type)은 두 객체 타입 사이 관계의 스키마 정의이고, 링크(link)는 두 객체 사이에 성립한 그 관계의 인스턴스 하나입니다. 같은 객체 타입끼리도 링크 타입을 만들 수 있습니다(Direct Report ↔ Manager). 서로 다른 온톨로지에 있는 객체 타입 사이의 링크는 지원되지 않습니다. 데이터셋 비유로는 링크 타입이 두 데이터셋의 조인, 링크가 조인된 행 하나입니다.

링크 타입은 양방향입니다. 두 면(side)을 가지며 면마다 표시 이름과 API 이름이 있어, 하나의 링크 타입으로 양쪽 방향을 모두 탐색합니다. 그래서 역방향 링크 타입을 따로 만들 필요가 없습니다. OWL에서 owl:inverseOf로 두 속성을 짝지었던 것과 대비됩니다. 같은 두 객체 타입 사이에 여러 링크 타입을 둘 수 있지만, 각각은 서로 다른 실세계 관계(예: 배정된 항공기와 정비 기록)를 나타내야 합니다.

카디널리티(cardinality)는 일대일, 일대다, 다대일, 다대다입니다. 외래 키(foreign key) 방식은 한 객체 타입의 속성이 다른 객체 타입의 기본 키 값을 저장하는 것으로 일대일·다대일 관계에 쓰며, 일대일은 의도를 표시할 뿐 강제되지 않습니다. 다대다는 두 기본 키 쌍을 담은 조인 테이블 데이터셋(join table dataset)이 링크를 백킹하고, 사용자가 링크를 편집(writeback)하려면 이 백킹 데이터소스가 필요합니다. 링크 자체에 속성이 필요하면 중간 객체 타입이 링크를 백킹하는 객체 기반 링크(object-backed link)를 씁니다.

물류에서 Shipment.warehouse_id가 Warehouse.warehouse_id를 참조하면 여러 배송이 한 창고로 가는 다대일 링크입니다. 한 배송을 구간별로 여러 운송사가 나르고 한 운송사가 여러 배송을 맡는다면 Shipment–Carrier는 다대다이므로 shipment_carrier 조인 테이블이 필요합니다. 구간 순서나 인계 시각처럼 관계 자체의 값이 중요해지면 Leg(구간) 같은 중간 객체 타입을 두는데, DAY 42의 이벤트 노드와 같은 판단입니다. 팔란티어 설계 지침은 링크가 소스 시스템의 조인 키가 아니라 실세계 관계를 나타내야 한다고 강조합니다.

링크 타입은 두 객체 타입 사이 관계를 양방향으로 정의하며, 일대일·다대일은 외래 키로, 다대다는 조인 테이블 데이터셋으로 백킹합니다.

02 / WORKED EXAMPLE∑

작은 예제로 따라가기

Shipment의 warehouse_id 열(외래 키): S-101·S-102·S-105 → W-1 부산센터, S-103·S-104 → W-2 대전센터. 링크 5개가 생기고 창고 하나에 배송 여러 건이 이어지므로 Shipment 쪽에서 다대일입니다. S-106의 W-3은 창고 데이터셋에 없는 키라 링크가 되지 못합니다.

조인 테이블 shipment_carrier: (S-101, K-1), (S-102, K-1), (S-102, K-2), (S-103, K-2), (S-104, K-1), (S-105, K-2). 링크 6개가 생기고, S-102는 운송사 2곳과, 빠른운송(K-1)과 한결물류(K-2)는 각각 배송 3건과 이어지므로 다대다입니다.

S-106은 조인 테이블에 행이 없어 운송사 링크가 0개입니다. 외래 키 방식이었다면 carrier_id 열 하나에 S-102의 운송사 두 곳을 담을 수 없습니다.

03 / EXPLORE

직접 실험해 보기

Shipment–Warehouse(외래 키)와 Shipment–Carrier(조인 테이블)를 번갈아 선택해 어떤 키 열이 어떤 링크를 만드는지 표와 그래프에서 하나씩 대응시키고, footer의 카디널리티를 확인하세요.

LIVE EXPERIMENT · LINK TYPES

외래 키와 조인 테이블로 링크 타입 만들기

부산 = W-1 부산센터 · 대전 = W-2 대전센터 · 주황 점선 = 없는 창고를 가리키는 키

노드를 눌러 한쪽에서 링크를 따라가 보세요. 링크 타입은 양방향이라 두 쪽(side) 어디서든 탐색합니다.

shipments 데이터셋 — warehouse_id 열이 Warehouse의 기본 키를 담은 외래 키(foreign key)
shipment_id	warehouse_id (FK)
S-101	W-1
S-102	W-1
S-103	W-2
S-104	W-2
S-105	W-1
S-106	W-3 (없음)

배송 하나는 창고 하나만 가리키고, 창고 하나는 여러 배송과 이어집니다. S-106의 W-3처럼 없는 기본 키를 가리키는 값은 링크가 되지 못합니다.

04 / RECALL & PRACTICE

이번에는 직접 풀어 보세요

정답을 보기 전에 계산과 이유를 적어 보세요. 해설과 비교하고 확인 표시를 남기면 완료할 수 있습니다.

문제 1

Customer–Shipment(한 고객이 여러 배송을 주문하고, 배송마다 주문 고객은 한 명)와 Warehouse–Carrier(한 창고에 여러 운송사가 드나들고, 한 운송사는 여러 창고를 이용) 두 관계의 카디널리티와 백킹 방식을 정하세요.

힌트 보기

각 객체 쪽에서 상대가 하나인지 여럿인지를 양쪽으로 물어보세요.

풀이와 비교하기

Customer–Shipment는 고객 하나에 배송 여럿이므로 Shipment 쪽에서 보면 다대일입니다. Shipment에 customer_id 외래 키 속성을 두어 Customer의 기본 키를 참조합니다. Warehouse–Carrier는 다대다이므로 (warehouse_id, carrier_id) 쌍을 담은 조인 테이블 데이터셋으로 백킹합니다. 계약 기간 같은 관계 자체의 속성이 필요해지면 Contract 같은 중간 객체 타입을 두는 객체 기반 링크를 고려합니다.

내 풀이를 해설과 비교하고 다른 점을 확인했어요.

풀이와 확인 표시는 이 브라우저에 저장됩니다.

YOUR NOTES

오늘 이해한 것과 다시 볼 것

계산이 달라진 이유, 헷갈린 개념, 다음에 확인할 질문을 남겨 보세요.

메모는 이 브라우저에 저장됩니다. 홈에서 전체 기록을 내려받을 수 있습니다.

05 / CHECK YOURSELF

오늘의 이해 확인

한 배송을 여러 운송사가 나르고 한 운송사가 여러 배송을 맡는 관계를 링크 타입으로 만들 때 필요한 것은?

완료 조건: 확인 퀴즈 정답 · / 직접 풀기 0/1

더 깊이 읽기

예제와 실험 데이터는 이 과정을 위해 만든 것입니다. 원문은 선택 자료이며, 강의와 직접 풀기만으로도 다음 회차를 이어갈 수 있습니다.

Link types: OverviewPalantir Foundry Docs Create a link typePalantir Foundry Docs Link types: Metadata referencePalantir Foundry Docs

이 자료는 개념 학습용입니다. 실제 데이터베이스·라이브러리·플랫폼의 동작과 설정은 제품과 버전마다 다를 수 있습니다.