select
customer.id,
customer.full_name,
...

# 모든 주문에 유효한 고객 ID가 있는 것은 아니므로, 유효한 ID를 가진 것만 살펴보겠습니다
where store_sales.customer.id is not null
select
...

where store_sales.customer.state is not null
select
store_sales.customer.id,
...

import std.money; # usd와 같은 풍부한 통화 유형
import item as item;
import date as date;
...

where store_sales.return_customer.state is not null
and store_sales.return_customer.state != store_sales.customer.state
select
...

import customer_demographic as demographics;
key id int;
unique property id.text_id string;
...

파생(derivation), 집계(aggregation), 필터링(filtering)을 깊이 파고들어 보겠습니다. `store_sales`부터 시작합니다.

### 상태별 집계 (State Aggregation)

### 혼합 집계 (Mixed aggregate)

### 필터링 (Filtering)

### 미묘한 필터 (Nuanced Filter)

### 품목별 총 매장 판매액을 기준으로 주(State)별 평균 순위 찾기

준비되셨나요? 쿼리를 직접 시도해 보세요!

팁 (Tips)

기본적인 쿼리의 경우, Trilogy는 SQL과 거의 동일해야 합니다. 확신이 서지 않을 때는 SQL 구문을 사용해 보세요!

- CA 주에서 연도별 판매액은 얼마였나요? >
- CA 주의 평균 연간 판매액은 얼마였나요? >
- 2001년에 가장 많은 매장 판매액을 기록한 고객 인구 통계학적 그룹은 무엇이며, 하와이에서의 해당 그룹 판매액은 얼마였나요? >
- 주문 건수가 5건을 초과하는 고객들이 매사추세츠(Massachusetts)와 켄터키(Kentucky)에서 가장 많이 구매한 품목은 무엇이었나요? >

다음 개념들은 미리 정의되어 있으며 이름으로 참조할 수 있습니다.

합리적으로 보여줄 수 있는 것보다 더 많은 개념이 존재합니다. 영감을 얻으려면 이 상자에서 검색해 보세요:

경고 (Warning)

우선은 동일한 루트를 가진 개념(예: store_sales.x 및 store_sales.y)을 쿼리하는 것에 집중하세요. 아니면, 모형들을 병합하여 교차 네임스페이스 쿼리를 활성화하는 방법을 알아보려면 계속 읽어보세요.

저희는 매장 판매액에 재미를 느꼈지만, 데이터셋의 나머지 부분은 어떨까요?

일반적인 Trilogy 스크립트는 기존 모델을 가져오는 것(importing)을 기반으로 하며, 이 모델들 자체도 가져오기를 포함할 수 있습니다. 저희는 store_sales가 서로 다른 역할 놀이 차원(role-playing dimensions) 하에서 동일한 고객 모델을 어떻게 가져오는지 확인했습니다.

하지만 때로는 예상치 못한 방식으로 데이터를 병합해야 할 필요가 있습니다. SQL은 유연합니다. 임의의 키를 선택하여 병합할 수 있습니다.

두 개의 모델을 연결하고 싶다면 어떻게 할 수 있을까요?

Trilogy는 조인(joins) 기능을 제공합니다. 하지만 테이블이 없다면, 조인이란 무엇일까요?

Trilogy에서 조인은 의미론적 집합 연산(semantic set operation)을 나타냅니다. 두 개의 독립적인 개념을 더 큰 전체의 부분집합으로 선언할 수 있습니다—이를 "full outer join"이라고 부르며, 우리는 이를 "union join"이라고 부릅니다.

또는 하나의 개념 집합이 다른 개념의 부분집합임을 선언할 수도 있습니다—이는 "left outer join"이며, 우리는 이를 "subset"이라고 부릅니다.

진단 또는 임시적인 이유로 비정상적인 키(unnatural keys)를 가진 필드를 연결하고 싶을 수도 있습니다. 이것은 그러한 기능을 쿼리 범위 내에서 수행할 수 있게 해줍니다.

팁

조인은 표현식(expressions)에 대해 작동할 수 있습니다! `union join x + 1 = x`는 하나의 개념 범위 내 값들 간의 조합을 생성하는 유효한 방법입니다.

쿼리 범위 내 조인은 select 목록 뒤에 배치하십시오. subset, union 및 composite-key 예시는 join 참조를 참고하십시오.

예시로, 아마도 귀하의 의미론적 모델은 "Edgewood 지역에서 이 소득 범위에 있는 고객 중, 오프라인 매장에서 구매한 상품을 반품한 사람들과 동일한 인구통계학적 그룹을 가진 고객은 누구인가?"라는 질문에 답하도록 설정되어 있지 않았을 것입니다.

조인은 SQL에서처럼 이러한 임시 교집합(ad hoc intersection)을 쉽게 표현할 수 있게 해줍니다.

팁

쿼리 수준의 조인(Query-level joins)은 쿼리의 범위에만 지속됩니다. 이는 유용한 탐색 도구이지만, 소비를 위해 모델을 구조화할 때는 일반적으로 사전 의미론적 동등성 모델링(upfront semantic equivalence modeling) 및 부분 바인딩(partial bindings)을 선호하여 이를 피하는 것이 좋습니다.

개념 연결이 쿼리를 넘어 재사용 가능한 방식으로 지속되어야 한다면, 모델 수준 병합(model-level merge)을 사용할 수 있습니다. 모델 수준 병합은 개념적으로 조인과 동일하지만, 모델을 사용하는 모든 select에 기본적으로 적용되며 독립적인 구문으로 수정된 문법을 가집니다.

이것은 Trilogy에게 이 두 필드가 "같다"고 알려줍니다. 예를 들어, 판매 데이터셋과 공휴일 데이터셋이 있다고 가정해 봅시다. 이들은 다음과 같은 필드를 가질 수 있습니다:

Sales: 'order_date', 'ship_date', 'returned_date', 'order_id'

Holidays: 'date', 'holiday_name'

휴일 동안 주문된 판매 내역을 알고 싶다면, holidays의 date를 sales.order_date에 병합(merge)하면 됩니다. 그러면 이제 `select holiday_name, count(order_id)`와 같이 쉽게 쿼리할 수 있습니다.

만약 휴일에 배송된 주문 내역을 보고 싶다면, ship date 기준으로 병합하면 되고—두 가지 모두를 쿼리할 수 있도록 하려면, holidays 데이터셋을 두 개의 다른 이름으로 가져와 독립적으로 병합할 수 있습니다.

Model merges는 dataset bindings와 동일한 수정자(modifier) 구문을 사용합니다: `merge a into ~b;`

이는 a가 b의 부분집합임을 의미합니다 (부분집합 조인과 유사).

팁

유일하게, model merges는 `merge a into b;`를 *정확한* 동등성 연산(exact equivalence operation)으로 지원합니다. a 또는 b를 요청하는 모든 것은 두 테이블에 바인딩된 데이터로부터 충족될 수 있습니다. 주의하세요! 이것이 유효하려면 두 개념이 정확히 동일한 범위를 가져야 합니다.

하나로 병합: `MERGE <concept1> into <modifiers?><concept2>`
여러 개로 병합: `MERGE <namespace1>.* into <modifiers?><namespace2>.*`

둘 다 시도해 봅시다:

### Union Join

### Model Merge

팁

여러 병합 구문(merge statements)을 두 모델 사이에 정의할 수 있습니다. 쿼리는 쿼리에서 참조된 모든 개념에 걸쳐 병합됩니다.

대시보드를 구동하기 위해 쿼리를 물질화(materialize)하고 싶다고 상상해 보세요. 선호되는 패턴은 그 결과를 관리형 데이터 소스(managed datasource)로 설명하고, Trilogy가 언제 재구축해야 하는지 결정하도록 하는 것입니다.

외부에서 관리되는 표준 입력(canonical inputs)을 `root`로 표시하세요.
각 파생 데이터 소스(derived datasource)에 대해 `freshness by`를 사용하세요.

물표(watermark)를 식별하여 Trilogy가 상위 입력값과 비교할 수 있도록 합니다. 데이터 소스는 시맨틱 모델의 일부로 유지되며, 물리적 테이블은 원본 물표가 진행될 때마다 재생성될 수 있는 캐시로 취급됩니다.

팁

Trilogy는 또한 명령형 업데이트(imperative updates)와 외부 호출을 제공합니다. 따라서 사용 사례에 가장 적합한 방식으로 선언적(declarative), 자산 기반 새로고침과 명시적 실행을 혼합하여 사용할 수 있습니다.

하나의 파일 또는 모델 디렉터리에 대해 새로고침을 실행합니다:

`refresh`

모델 의존성 그래프를 스캔하고, 데이터 소스 물표를 비교하며, 오래된 관리 자산만 재구축합니다. 추가(append)-지향 모델의 경우 `freshness by` 대신 `incremental by`를 사용하십시오.

팁

실제로는 대부분의 웨어하우스가 보고, 분석 및 성능을 구동하기 위해 주기적으로 새로고침되는 유한한 수의 '루트'와 그로부터 파생된 여러 캐시를 갖게 됩니다. Trilogy는 이러한 캐시들을 데이터 소스로 명시적으로 정의하고 `refresh` 명령어를 통해 관리할 수 있게 합니다.

`persist`

일회성 쿼리의 출력을 의도적으로 저장하려는 경우 여전히 유용합니다. 반복 가능한 파이프라인의 경우, 관리되는 데이터 소스와 `refresh`를 선호하십시오. 이렇게 하면 정의(definition), 계보(lineage), 그리고 새로고침 정책이 모델 내에서 함께 존재하게 됩니다.

오늘의 주제입니다. 실망시키지 않겠습니다: Trilogy는 에이전트와 매우 잘 작동합니다.

Claude Code 또는 다른 어떤 하네스라도 Trilogy CLI를 가리키기만 하면 됩니다. `trilogy agent-info`는 자체 포함된 안내서를 제공하도록 설계되었으며, 전역 `--output-format json --agent` 옵션은 에이전트에 적합한 실패 동작과 함께 기계가 읽을 수 있는 출력을 제공합니다. Studio는 또한 서브프로세스보다 도구 프로토콜을 선호하는 클라이언트를 위해 MCP 서버도 제공합니다.

CLI에는 또한 큐레이션된 Trilogy 도구 세트를 갖춘 네이티브 에이전트 루프가 포함되어 있습니다. 구성된 Trilogy 작업 공간에서 단일 쿼리 대신 결과를 전달하세요:

대화 내용은 기본적으로 저장됩니다. CLI는 제어권을 반환할 때 세션 ID를 출력하므로, 나중에 같은 컨텍스트로 명령을 계속할 수 있습니다:

Provider 및 모델 기본값은 `trilogy.toml`의 `[agent]` 섹션에 속합니다.

; `--provider`

그리고 `--model`로 단일 호출 시 이를 재정의할 수 있습니다. API 키는 provider의 환경 변수에서 읽어옵니다. `--context <경로>`를 사용하여 컨텍스트 파일을 추가하고, 일시적인 세션을 위해 `--no-save`를 사용하며, 전체 에이전트 기반 CLI 및 언어 레퍼런스를 위해 `trilogy agent-info`를 실행하세요.

아래에서 TPC-DS 데이터셋 쿼리 실험을 해볼 수 있습니다 - 단발성 쿼리로!

언어와 철학에 대한 더 깊은 탐색을 원한다면 concepts 페이지로 이동하세요.