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

객체 타입과 속성

데이터셋의 행이 어떻게 ‘배송 S-101’이라는 객체가 될까요? 객체 타입을 만들 때 반드시 정해야 하는 백킹 데이터소스, 기본 키, 제목 키를 공식 문서 기준으로 확인합니다.

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

01 / UNDERSTAND

핵심 개념

객체 타입(Object type)은 실세계 엔티티나 이벤트의 스키마 정의이고, 객체(object)는 그 타입의 인스턴스 하나, 객체 세트(object set)는 여러 객체의 모음입니다. 문서의 비유로는 객체 타입이 데이터셋, 객체가 행, 객체 세트가 필터된 행 집합에 해당합니다. 속성(Property)은 객체 타입이 가진 특성의 스키마 정의로 열에, 속성 값(property value)은 필드에 해당합니다.

객체를 실제 데이터로 채우는 것이 백킹 데이터소스(backing datasource)입니다. Ontology Manager에서 데이터소스를 고르면 각 열이 속성으로 자동 매핑되고, 필요 없는 속성은 버릴 수 있습니다. 하나의 데이터소스는 하나의 객체 타입만 백킹합니다. 모든 객체를 액션으로 만든다면 백킹 데이터소스 없이 객체 타입을 만들 수도 있지만, 그때도 기본 키는 필요합니다.

기본 키(Primary key)는 객체 타입의 인스턴스를 고유하게 식별하는 속성으로, 데이터소스 기반 객체 타입이라면 모든 행이 서로 다른 값을 가져야 합니다. 문서는 기본 키가 결정적(deterministic)이어야 한다고 강조합니다. 빌드할 때마다 값이 바뀌면 사용자 편집이 사라지고 링크가 끊길 수 있으므로 행 번호나 무작위 키 생성은 피합니다. 제목 키(Title key)는 객체의 표시 이름으로 쓰이는 속성입니다.

속성의 기본 타입(base type)에 따라 키로 쓸 수 있는지가 다릅니다. String·Integer·Short는 기본 키와 제목 키 모두 가능하고, Date·Timestamp·Boolean·Long 등은 기본 키로 권장되지 않으며, Float·Double·Decimal은 기본 키로 쓸 수 없습니다. 문서는 대부분 String을 권합니다. API 이름은 객체 타입이 PascalCase(Shipment), 속성이 camelCase(promisedDate)입니다. OWL이 이름이 달라도 같은 대상일 수 있다고 보는 것(DAY 59)과 달리, 여기서는 기본 키 값이 객체의 정체성을 정합니다.

객체 타입은 백킹 데이터소스의 행을 객체로, 열을 속성으로 매핑하며, 고유하고 결정적인 기본 키와 읽기 쉬운 제목 키가 필요합니다.

02 / WORKED EXAMPLE∑

작은 예제로 따라가기

shipments 데이터셋 여섯 행(DAY 75와 같은 물류 데이터, 기준일 10-07): S-101 한빛상사 delivered, S-102 다온마트 in_transit, S-103 한빛상사 delivered, S-104 바른약국 in_transit, S-105 다온마트 in_transit, S-106 (고객 빈 값) in_transit. 열은 shipment_id, customer_name, status, warehouse_id, promised_date입니다.

shipment_id를 기본 키로 고르면 값 6개가 모두 달라 객체 6개가 만들어집니다. customer_name은 한빛상사·다온마트가 두 번씩 나오고 S-106은 비어 있으며, status는 delivered와 in_transit 두 값뿐이라 둘 다 기본 키가 될 수 없습니다.

제목 키는 고유할 필요가 없으므로 사람이 읽기 쉬운 표시용 속성(예: ‘S-101 · 한빛상사’)을 만들어 지정하거나 shipment_id를 그대로 씁니다. S-106도 객체는 되지만 고객 누락·없는 창고 W-3 같은 문제는 DAY 75의 검증 규칙에서 걸러냅니다.

03 / EXPLORE

직접 실험해 보기

기본 키 후보를 shipment_id, customer_name, status로 바꿔 가며 중복 여부와 만들어지는 객체 수를 먼저 예상하고, 실험 결과와 비교해 어떤 열이 기본 키로 적합한지 판단하세요.

LIVE EXPERIMENT · OBJECT TYPE

백킹 데이터셋의 행을 Shipment 객체로 만들기

객체 타입(Object type) Shipment의 백킹 데이터소스(backing datasource)는 shipments 데이터셋입니다. 어떤 열을 기본 키(primary key)로 해야 행 하나가 객체 하나가 될까요? 바꾸기 전에 중복을 먼저 예상해 보세요.

shipments 데이터셋 · 행 → 객체, 열 → 속성(property) · 기본 키 열: shipment_id · status는 10-07 기준 도착 여부
customer_name	status	warehouse_id	promised_date
한빛상사	delivered	W-1	10-05
다온마트	in_transit	W-1	10-06
한빛상사	delivered	W-2	10-06
바른약국	in_transit	W-2	10-04
다온마트	in_transit	W-1	10-08
(빈 값)	in_transit	W-3	10월 9일

기본 키 shipment_id: 모든 행이 고유 → 객체 6개각 객체는 기본 키 값 하나로 식별됩니다. S-106도 객체가 되지만 고객 누락·없는 창고 W-3·약속일 형식 문제가 있어 검증(DAY 75)에서 따로 걸러냅니다.

제목 키(title key) — 화면에 보이는 이름

제목 키는 객체의 표시 이름일 뿐 식별자가 아니어서 고유할 필요가 없습니다. 다만 customer_name을 제목으로 쓰면 ‘한빛상사’ 객체가 두 개 보여 헷갈릴 수 있습니다. 행의 shipment_id를 눌러 다른 객체를 미리 보세요.

Shipment · 객체(object)S-101기본 키 shipment_id = S-101

shipment_id: S-101
customer_name: 한빛상사
status: delivered
warehouse_id: W-1
promised_date: 10-05

04 / RECALL & PRACTICE

이번에는 직접 풀어 보세요

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

문제 1

창고(Warehouse) 데이터셋의 열은 warehouse_id(문자열, 고유), name(지점마다 ‘중앙창고’가 중복될 수 있음), opened_at(Timestamp), capacity(Double)입니다. 기본 키와 제목 키를 고르고, 나머지 열을 기본 키로 고르지 않은 이유를 쓰세요.

힌트 보기

기본 키는 고유하고 결정적이어야 하고, 제목 키는 사람이 알아보는 이름이면 됩니다. 기본 타입별 허용 여부도 떠올리세요.

풀이와 비교하기

기본 키는 warehouse_id입니다. 고유하고 결정적인 문자열입니다. 제목 키로 name을 쓸 수 있지만 중복되면 목록에서 구별하기 어려우므로 ‘중앙창고(부산)’처럼 지역을 붙인 표시용 속성을 만드는 편이 낫습니다. name은 중복 때문에, opened_at은 Timestamp라 권장되지 않아서, capacity는 Double이라 기본 키로 쓸 수 없어서 제외합니다.

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

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

YOUR NOTES

오늘 이해한 것과 다시 볼 것

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

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

05 / CHECK YOURSELF

오늘의 이해 확인

기본 키로 쓰는 ‘행 번호’를 빌드할 때마다 새로 매기면 생길 수 있는 문제는?

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

더 깊이 읽기

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

Object types: OverviewPalantir Foundry Docs Properties: OverviewPalantir Foundry Docs Create an object typePalantir Foundry Docs

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