SQL 명령을 사용하여 의미 체계 뷰 생성하기 및 관리하기¶
이 항목에서는 다음 SQL 명령을 사용하여 의미 체계 뷰 를 만들고 관리하는 방법을 설명합니다.
이 항목에서는 다음 저장 프로시저와 함수를 호출하여 :doc:`YAML 사양 <semantic-view-yaml-spec>`에서 의미 체계 뷰를 생성하고 의미 체계 뷰에 대한 사양을 가져오는 방법에 대해 설명합니다.
의미 체계 뷰를 생성하거나 바꾸는 데 필요한 권한¶
의미 체계 뷰를 생성하거나 바꾸려면 다음 권한이 있는 역할을 사용해야 합니다.
의미 체계 뷰를 생성하는 스키마에 CREATE SEMANTIC VIEW 를 추가합니다.
의미 체계 뷰를 생성하는 데이터베이스 및 스키마에 USAGE 를 추가합니다.
의미 체계 뷰에 사용된 테이블과 뷰에 대한 SELECT 권한
의미 체계 뷰를 쿼리하는 데 필요한 권한에 대한 내용은 의미 체계 뷰를 쿼리하는 데 필요한 권한 섹션을 참조하세요.
CREATE SEMANTIC VIEW 명령을 사용하여 의미 체계 뷰 생성하기¶
의미 체계 뷰를 생성하려면 CREATE SEMANTIC VIEW 명령을 사용합니다.
참고
YAML 사양 <semantic-view-yaml-spec>`에서 의미 체계 뷰를 생성하려면 :doc:/sql-reference/stored-procedures/system_create_semantic_view_from_yaml` 저장 프로시저를 호출합니다.
의미 체계 뷰가 유효해야 합니다. Snowflake가 의미 체계 뷰를 검증하는 방법 섹션을 참조하십시오.
다음 예제에서는 Snowflake에서 사용할 수 있는 :doc:`TPC-H 샘플 데이터 </user-guide/sample-data-tpch>`를 사용합니다. 이 데이터 세트에는 고객, 주문 및 품목을 포함한 단순화된 비즈니스 시나리오를 보여주는 테이블이 포함되어 있습니다.
이 예제에서는 TPC-H 데이터 세트의 테이블을 사용하여 tpch_rev_analysis 라는 이름의 의미 체계 뷰를 생성합니다. 의미 체계 뷰는 다음을 정의합니다.
3개의 논리 테이블(
orders,customers,line_items).orders및customers테이블 간의 관계.line_items및orders테이블 간의 관계.메트릭을 계산하는 데 사용되는 정보.
고객 이름, 주문 날짜 및 주문이 이루어진 연도에 대한 차원.
주문의 평균값 및 주문의 평균 품목 수에 대한 메트릭.
다음 섹션에서는 이 예제에 대해 자세히 설명합니다.
참고
전체 예제는 SQL 을 사용하여 의미 체계 뷰를 생성하는 예제 섹션을 참조하십시오.
논리 테이블 정의하기¶
CREATE SEMANTIC VIEW 명령에서 TABLES 절을 사용하여 뷰의 논리적 테이블을 정의합니다. 이 절에서는 다음을 할 수 있습니다.
실제 테이블 이름과 선택적 별칭을 지정합니다.
논리 테이블에서 다음 열을 식별합니다.
기본 키 역할을 하는 열입니다.
고유한 값을 포함하는 열(기본 키 열 제외).
이러한 열을 사용하여 이 의미 체계 뷰에서 관계를 정의할 수 있습니다.
테이블의 동의어 추가(검색 가능성 개선).
설명이 포함된 설명을 입력합니다.
앞서 제공된 예제 에서 TABLES 절은 세 개의 논리 테이블을 정의합니다.
TPC-H
orders테이블의 주문 정보가 포함된orders테이블.TPC-H
customers테이블의 고객 정보가 포함된customers테이블.line_items-H TPC 테이블의 주문 품목이 포함된lineitem테이블.
이 예에서는 PRIMARY KEY 절을 사용하여 각 논리 테이블의 기본 키로 사용할 열을 식별합니다. 기본 키와 고유 값은 테이블 간(예: 다대일 또는 일대일) :ref:`관계<label-semantic_views_create_relationships>`의 유형을 결정하는 데 도움이 됩니다.
이 예제에서는 논리 테이블을 설명하고 데이터를 더 쉽게 검색할 수 있도록 동의어와 설명도 제공합니다.
논리 테이블 간의 관계 식별하기¶
CREATE SEMANTIC VIEW 명령에서 RELATIONSHIPS 절을 사용하여 뷰에 있는 테이블 간의 관계를 식별합니다. 각 관계에 대해 다음을 지정합니다.
관계의 선택적 이름입니다.
외래 키가 포함된 논리적 테이블의 이름입니다.
해당 테이블에서 외래 키를 정의하는 열입니다.
기본 키 또는 고유 값을 가진 열을 포함하는 논리 테이블의 이름입니다.
해당 테이블에서 기본 키를 정의하거나 고유 값을 포함하는 열입니다.
TABLES 절에서 논리적 테이블에 PRIMARY KEY 를 이미 지정한 경우 관계에서 기본 키 열을 지정할 필요가 없습니다.
TABLES 절에 논리적 테이블에 대한 단일 UNIQUE 키워드가 있는 경우 관계에서 해당 열을 지정할 필요가 없습니다.
:ref:`범위에 열을 조인<label-semantic_views_create_relationships_asof>`하려면 날짜, 시간, 타임스탬프 또는 숫자 열을 지정할 수도 있습니다.
앞서 제공된 예제 에서 RELATIONSHIPS 절은 2개의 관계를 지정합니다.
orders및customers테이블 간의 관계.orders테이블에서o_custkey는customers테이블의 기본 키(c_custkey)를 참조하는 외래 키입니다.line_items및orders테이블 간의 관계.line_items테이블에서l_orderkey는orders테이블의 기본 키(o_orderkey)를 참조하는 외래 키입니다.
날짜, 시간, 타임스탬프 또는 숫자 범위를 사용하여 논리 테이블 조인¶
기본적으로, 두 논리 테이블 간의 관계를 지정하면 테이블이 같음 조건으로 조인됩니다.
날짜, 시간, 타임스탬프 또는 숫자 범위(한 테이블의 열에 있는 값이 다른 테이블의 열에 있는 값과 동일한 범위에 있어야 함)에서 두 개의 논리 테이블을 조인해야 하는 경우 REFERENCES 절에 열 이름과 함께 ASOF 키워드를 지정할 수 있습니다.
위에 정의된 의미 체계 뷰의 쿼리는 MATCH_CONDITION 절에서 >= 비교 연산자를 사용하는 :doc:`ASOF JOIN</sql-reference/constructs/asof-join>`을 생성합니다. 이렇게 하면 두 테이블이 조인되어 ``col_table_1``의 값이 ``col_table_2``의 값보다 크거나 같게 됩니다.
참고
MATCH_CONDITION 절의 다른 어떤 비교 연산자도 지원되지 않습니다.
:ref:`ASOF JOIN과 함께 사용할 수 있는 동일한 유형<label-asof_join_data_types>`의 ASOF 키워드를 사용할 수 있습니다.
참고
주어진 관계의 정의에서 ASOF 키워드를 최대 1개만 지정할 수 있습니다. 목록의 열 앞에 이 키워드를 지정할 수 있습니다.
예를 들어, 고객, 고객 주소, 주문 데이터가 포함된 테이블이 있다고 가정해 보겠습니다.
이 예에서는 customer_address 테이블에 고객이 지정된 주소에 거주하기 시작한 시점을 나타내는 ca_start_date 열이 있습니다. orders 테이블에 주문 날짜인 o_ord_date 열이 있습니다.
고객 주문에 대한 정보를 쿼리하고 주문 시 고객이 거주했던 곳에 해당하는 우편번호를 검색하려고 한다고 가정해 보겠습니다.
ca_start_date 및 o_ord_date 열 사이에 ASOF 조인을 지정하는 의미 체계 뷰를 정의할 수 있습니다.
:doc:`이 의미 체계 뷰를 쿼리<querying>`하여 각 우편번호에 대한 월별 주문 금액의 합계를 반환하려고 합니다.
쿼리는 ASOF JOIN을 효과적으로 사용하여 주문 날짜가 주소 시작 날짜보다 크거나 같은 날짜 열의 테이블을 조인합니다.
값 범위가 포함된 논리 테이블 조인하기¶
첫 번째 테이블에서 가능한 값의 범위를 정의하는 다른 테이블과 테이블을 조인하려는 경우 *범위 조인*을 사용할 수 있습니다. 예를 들어, 한 테이블이 판매 주문을 나타내고 주문 시점의 타임스탬프가 있는 열이 있다고 가정해 보겠습니다. 다른 테이블은 회계 분기를 나타내고 이러한 분기를 나타내는 고유한 시간 범위가 포함되어 있다고 가정해 보겠습니다. 주문의 행에 주문이 이루어진 회계 분기가 포함되도록 두 테이블을 조인하는 의미 체계 뷰를 생성할 수 있습니다.
범위가 포함된 테이블에서 각 범위는 고유해야 합니다. 두 범위는 겹칠 수 없습니다.
테이블 데이터에서 범위에 대해 가능한 가장 낮은 값이나 범위에 대해 가능한 가장 높은 값을 지정하려면 NULL을 사용합니다.
예를 들어, 다음 테이블은 겹치지 않는 시간 범위 세트를 정의합니다.
첫 번째 행은 2024년 1월 1일(해당 날짜는 포함되지 않음)까지의 모든 기간을 포함하는 범위를 다룹니다.
마지막 행은 2024년 3월 20일 이후의 모든 기간을 포함하는 범위를 다룹니다.
참고
어떤 행도 시작 열에 NULL을 포함할 수 없으며, 어떤 행도 마지막 열에 NULL을 포함할 수 없습니다.
이러한 경우에는 범위 조인 쿼리를 지원하는 :doc:`의미 체계 뷰 </user-guide/views-semantic/overview>`를 설정할 수 있습니다. 의미 체계 뷰를 생성할 때 다음을 수행해야 합니다.
기간의 시작 시간과 종료 시간이 포함된 논리 테이블의 경우, 두 범위가 겹치지 않도록 지정하는 제약 조건을 정의합니다.
CREATE SEMANTIC VIEW 명령의 TABLE 절에서 논리 테이블 정의에 CONSTRAINT 절을 지정합니다. 구문은 :ref:`CREATE SEMANTIC VIEW 항목의 CONSTRAINT에 대한 설명서 <label-create_semantic_view_tables_constraint>`를 참조하세요.
한 테이블의 타임스탬프가 포함된 열 및 다른 테이블의 시작 및 종료 시간 열 간의 관계를 정의합니다.
CREATE SEMANTIC VIEW 명령의 RELATIONSHIPS 절에서 BETWEEN 절을 사용하여 시작 및 종료 시간이 포함된 열을 지정합니다. 구문은 :ref:`CREATE SEMANTIC VIEW 항목의 RELATIONSHIP에 대한 설명서 <label-create_semantic_view_relationships>`를 참조하세요.
예를 들어, my_time_periods 테이블은 고유한 기간을 정의한다고 가정해 보겠습니다.
my_events 테이블은 해당 기간 내에 발생한 이벤트를 캡처한다고 가정해 보겠습니다.
테이블을 조인하는 의미 체계 뷰를 정의할 수 있습니다. my_events``의 행은 ``my_time_periods``의 행과 조인되며, 여기서 ``my_events``의 ``event_timestamp 열은 my_time_periods``의 ``start_time 및 ``end_time``으로 지정된 범위 내에 있습니다.
다음 쿼리는 행이 조인되는 방법을 보여줍니다.
예제에서 볼 수 있듯이, 결과의 각 행에 대한 dim_time_period_name 차원은 dim_event_timestamp 차원이 속한 기간의 이름입니다.
팩트, 차원 및 메트릭 정의하기¶
CREATE SEMANTIC VIEW 명령에서 FACTS, DIMENSIONS, METRICS 절을 사용하여 의미 체계 뷰에서 팩트, 차원 및 메트릭을 정의합니다.
의미 체계 뷰에서 1개 이상의 차원 또는 메트릭을 정의해야 합니다.
각 팩트, 차원 또는 메트릭에 대해 지정합니다.
그것이 속한 논리 테이블입니다.
참고
파생 메트릭(하나의 논리적 테이블에만 국한되지 않는 메트릭)을 정의하려면 논리적 테이블 이름을 생략해야 합니다. 파생 메트릭 정의하기 섹션을 참조하십시오.
팩트, 차원 또는 메트릭의 이름입니다.
SQL 식을 사용하여 이를 계산합니다.
참고
차원의 경우 차원에 사용할 Cortex Search Service</user-guide/snowflake-cortex/cortex-search/cortex-search-overview>`를 지정할 수 있습니다. 자세한 내용은 :ref:`label-semantic_views_create_cortex_search_service_dimension 섹션을 참조하십시오.
선택적 동의어 및 설명.
참고
특정 차원에서 메트릭을 집계하지 않아야 하는 경우 해당 차원이 비가산 상태여야 함을 지정해야 합니다.
자세한 내용은 메트릭에 대해 비가산되어야 하는 차원 식별하기 섹션을 참조하십시오.
앞서 제공된 예제 는 몇 가지 정보, 차원 및 메트릭을 정의합니다.
참고
윈도우 함수를 사용하는 메트릭을 정의하는 방법에 대한 추가 지침은 윈도우 함수 메트릭 정의 및 쿼리 섹션을 참조하세요.
Cortex Search Service를 사용하는 차원 정의¶
Cortex Search Service. 예:
파생 메트릭 정의하기¶
메트릭을 정의할 때 메트릭이 속한 논리적 테이블의 이름을 지정합니다. 이는 메트릭이 집계되는 논리적 테이블입니다.
다양한 논리적 테이블의 메트릭을 기반으로 메트릭을 정의하려면 *파생 메트릭*을 정의하면 됩니다. 파생 메트릭은 (특정 논리적 테이블이 아닌) 의미 체계 뷰로 범위가 지정된 메트릭입니다. 파생 메트릭은 여러 논리적 테이블의 메트릭을 결합할 수 있습니다.
파생 메트릭의 정의에서 논리적 테이블 이름을 생략합니다.
예를 들어, table_1.metric_1 및 table_2.metric_2``의 합계인 ``my_derived_metric_1 메트릭을 정의하려고 한다고 가정해 보겠습니다. ``my_derived_metric_1``을 정의할 때 논리적 테이블 이름으로 이름을 한정하지 않습니다.
표현식에서 다른 파생 메트릭을 사용할 수 있습니다. 예:
파생 메트릭을 정의할 때 다음 제한 사항에 유의하세요.
파생 메트릭과 일반 메트릭에 같은 이름을 사용할 수 없습니다.
파생 메트릭에 대한 식은 다음을 사용할 수 있습니다.
의미 체계 뷰의 논리 테이블에 정의된 차원 및 팩트의 집계.
의미 체계 뷰에서 논리 테이블에 정의된 메트릭의 Scalar 식.
기타 파생 메트릭.
다음 예제에서는 다음을 수행합니다.
이름이 모호하지 않은 경우 식에서 메트릭, 차원 또는 팩트의 이름을 한정할 필요가 없습니다. 예:
``metric_1``에는 ``metric_1``이라는 이름의 두 메트릭이 있기 때문에 ``table_1``로 한정되어야 하지만, 이름이 고유하므로 ``my_unique_metric_name``은 한정될 필요가 없습니다.
파생 메트릭에 대한 표현식에는 다음을 사용할 수 없습니다.
메트릭 집계.
윈도우 함수.
물리적 열에 대한 참조.
집계되지 않은 팩트 또는 차원에 대한 참조.
일반 메트릭, 차원 또는 정보에 대한 표현식에는 파생 메트릭을 사용할 수 없습니다. 다른 파생 메트릭만 해당 표현식에서 파생 메트릭을 사용할 수 있습니다.
여러 관계 경로가 있는 경우 메트릭에 대한 관계 지정하기¶
의미 체계 뷰에서 두 개의 특정 논리적 테이블 간에 여러 관계 경로가 존재하는 경우가 있습니다. 이러한 경우 메트릭을 정의할 때 사용할 관계 경로를 지정해야 합니다.
여러 관계 경로의 문제¶
항공편과 공항에 대한 정보가 포함된 두 개의 테이블이 있다고 가정해 보겠습니다.
특정 도시에서 출발하고 특정 도시에 도착하는 총 항공편 수에 대한 정보를 제공하는 의미 체계 뷰를 정의한다고 가정해 보겠습니다.
의미 체계 뷰는 flights 테이블과 airports 테이블(flight_departure_airport 및 flight_arrival_airport) 간에 두 가지 다른 관계를 지정합니다. 테이블 간에는 여러 관계 경로가 있으므로 m_flight_count 메트릭에 대해 쿼리하고 airports.city_name 차원(또는 airports 테이블의 모든 차원)을 선택하면 오류가 발생합니다.
flights``와 ``airports 테이블 간에는 여러 경로가 있으므로 쿼리가 실패합니다. 쿼리가 airports 테이블에서 차원을 선택하지 않았다면 성공했을 것입니다.
사용할 관계 지정하기¶
CREATE SEMANTIC VIEW 명령의 메트릭 정의에서 USING 절을 사용할 관계를 지정할 수 있습니다.
참고
지정하는 각 관계는 메트릭이 포함된 논리 테이블에서 시작해야 합니다. 예를 들어, 다음을 지정한다고 가정해 보겠습니다.
table_a_to_table_b관계는 ``table_a``에서 시작해야 합니다.관계의 시퀀스는 지정할 수 없습니다(예:
table_a_to_table_b및table_b_to_table_c). 각 관계는 메트릭이 포함된 논리 테이블에서 시작해야 합니다.메트릭이 포함된 논리 테이블과 다른 테이블 간의 관계를 식별해야 하는 경우 USING 절에서 관계를 지정하면 됩니다. 예를 들어, ``table_a``에서 ``table_b``로의 특정 관계 및 ``table_a``에서 ``table_c``로의 특정 관계로 메트릭을 계산한다고 가정해 보겠습니다. 이 경우 USING 절에서 두 관계를 모두 지정합니다.
:ref:`파생 메트릭 <label-semantic_views_create_derived_metrics>`에서는 USING 절을 지정할 수 없습니다.
예를 들어, 다음 문은 특정 관계를 사용하는 두 개의 추가 메트릭을 정의합니다.
flight_departure_airport관계를 사용하는m_flight_departure_count.flight_arrival_airport관계를 사용하는m_flight_arrival_count.
이 뷰를 쿼리할 때 특정 관계를 사용하는 두 가지 새로운 메트릭을 지정할 수 있습니다.
동일한 관계를 사용하는 차원 추가¶
이전 예제의 쿼리에서는 관계의 기반이 되는 airports 논리 테이블에 있는 airports.city_name 차원을 사용했습니다.
다른 논리 테이블의 차원을 뷰에 추가하면 해당 차원의 쿼리가 이전에 지정한 관계의 이점을 활용할 수 있습니다.
예를 들어, airports 테이블의 airport_region_code 열에 지정된 공항 리전에 대한 추가 정보가 포함된 ``regions``라는 테이블을 생성한다고 가정해 보겠습니다.
이전에 정의한 의미 체계 뷰를 확장하여 리전 이름을 반환할 수 있습니다.
regions테이블에 대한 새 논리 테이블을 추가합니다.regions테이블과airports테이블 간의 관계를 추가합니다.리전 이름에 대한 차원을 추가합니다.
regions``와 ``airports 간에는 단일 관계가 있으므로 메트릭에 대한 USING 절을 추가로 변경할 필요가 없습니다.
뷰를 쿼리하는 경우 region_name 차원을 지정했는데 어떤 관계를 사용할지 모호한 경우 USING 절에 따라 사용할 관계가 결정됩니다.
다른 테이블에 대한 관계 지정¶
의미 체계 뷰가 여러 테이블의 차원을 사용하고 이러한 차원에 사용할 관계를 지정해야 하는 경우, USING 절에서 여러 관계를 지정할 수 있습니다.
예를 들어, airports 테이블의 공항에 대한 날씨 정보가 포함된 ``weather``라는 테이블을 생성한다고 가정해 보겠습니다.
앞서 정의한 의미 체계 뷰를 확장하여 날씨 조건을 반환할 수 있습니다.
weather테이블에 대한 새 논리 테이블을 추가합니다.weather테이블과flights테이블(출발 항공편용 테이블 1개, 도착 항공편용 테이블 1개) 간의 두 가지 관계를 추가합니다.날씨 정보에 대한 차원을 추가합니다.
메트릭이
weather테이블과flights테이블 간의 두 가지 새로운 관계도 사용해야 함을 지정합니다.
뷰를 쿼리하고 weather_condition 차원을 지정할 때, USING 절에 따라 사용되는 관계가 결정됩니다.
특정 관계를 사용하는 메트릭을 기반으로 파생 메트릭 정의¶
:ref:`파생 메트릭 <label-semantic_views_create_derived_metrics>`에서는 USING 절을 지정할 수는 없지만, USING 절을 지정하는 메트릭을 사용하는 파생 메트릭을 정의할 수는 있습니다.
예를 들어, 다음 의미 체계 뷰는 두 개의 파생 메트릭을 정의합니다.
global_m_departure_arrival_ratioglobal_m_departure_arrival_sum
이러한 파생 메트릭의 정의는 flights.m_flight_departure_count 및 flights.m_flight_arrival_count 메트릭을 사용하며, 두 메트릭 모두 USING 절을 지정합니다.
메트릭에 대해 비가산되어야 하는 차원 식별하기¶
메트릭이 특정 차원에 걸쳐 집계되어서는 안되는 경우가 있습니다. 이러한 경우 차원을 *비가산*으로 표시할 수 있습니다.
일부 차원에서 메트릭 집계 관련 문제 이해하기¶
특정 날짜에 각 고객의 당좌 예금 계좌와 저축 계좌의 계좌 잔액이 포함된 테이블이 있다고 가정해 보겠습니다.
다음을 포함하는 의미 체계 뷰를 정의한다고 가정해 보겠습니다.
다음 차원:
고객 ID
계좌 유형
Year
Month
일
잔액 합계에 대한 메트릭.
다음 문은 위에 나열된 차원과 메트릭을 포함하는 의미 체계 뷰를 생성합니다.
매년 말에 각 고객의 당좌 예금 계좌와 저축 계좌의 총 잔액을 검색하려면 m_account_balance 메트릭에 대한 의미 체계 뷰를 쿼리하고 customer_id_dim 및 year_dim 차원을 지정하면 됩니다.
그러나 m_account_balance 메트릭은 날짜 차원을 기준으로 집계되므로 각 고객에 대한 각 날짜의 잔액 합계가 됩니다.
위의 예제에서 2024년 cust-001``의 경우, ``910``은 각 날짜의 잔액 합계(``100 + 110 + 140 + 150 + 200 + 210)입니다.
특정 차원에서 메트릭 집계 방지하기¶
메트릭이 날짜 차원을 기준으로 집계되지 않도록 하려면 의미 체계 뷰를 생성할 때 NON ADDITIVE BY 절에서 날짜 차원을 지정합니다.
참고
메트릭에 NON ADDITIVE BY 절을 지정하는 경우, 파생되지 않은 메트릭의 정의에서 해당 메트릭을 참조할 수 없습니다. 파생된 메트릭만 비가산 차원을 지정하는 메트릭을 참조할 수 있습니다.
NON ADDITIVE BY 절을 지정하면 메트릭이 반가산 메트릭이 됩니다.
이 의미 체계 뷰를 쿼리하는 경우 m_account_balance 메트릭은 더 이상 날짜 차원을 기준으로 집계되지 않습니다. 이 쿼리는 쿼리된 각 차원 그룹의 기간 말에 계좌 잔액을 집계합니다.
위의 예제에서 2024년 ``cust-001``의 경우, ``210``은 데이터가 포함된 연도의 마지막 날 당좌 예금 계좌와 저축 계좌 잔액의 합계입니다.
데이터가 포함된 2024년의 마지막 날은 ``2024-03-30``입니다.
당좌 예금 계좌에는 해당 날짜가 있는 행이 없으므로, 결과 메트릭은 예금 계좌의 잔액(
210)입니다.
또 다른 예제로, 연도의 마지막 날 모든 고객의 총 계좌 잔액만 확인하려면 year_dim 차원을 지정하면 됩니다.
날짜 차원은 비가산으로 표시되므로 이 쿼리는 각 고객의 당좌 예금 계좌와 저축 계좌 잔액에 대해 기간 말(날짜 기준)의 값을 합산합니다.
쿼리 처리 중에 행이 비가산 차원을 기준으로 정렬되고 마지막 행의 값(값의 최신 스냅샷)이 집계되어 메트릭을 계산합니다.
참고
행은 비가산 차원을 기준으로 정렬되므로 차원을 지정하는 순서가 중요합니다. 이는 ORDER BY 절에서 열을 지정하는 순서와 유사합니다.
비가산 차원의 정렬 순서 지정하기¶
예제에서 볼 수 있듯이, 이 메트릭은 기간이 끝날 때 각 고객의 당좌 예금 계좌와 저축 계좌 잔액의 값을 집계합니다. 정렬 순서를 변경하려면 차원 이름 옆에 있는 ASC 또는 DESC 키워드를 지정하면 됩니다. 예:
이 예제에서 메트릭은 year_dim, month_dim, ``day_dim``에 의해 지정된 가장 빠른 날짜로 평가됩니다.
차원에 NULL 값이 포함된 경우 NULLS FIRST 또는 NULLS LAST 키워드를 사용하여 NULL 값을 결과에서 첫 번째에 정렬할지 또는 마지막에 정렬할지 여부를 지정할 수 있습니다.
팩트 또는 메트릭을 비공개로 표시¶
의미 체계 뷰의 계산에만 사용할 팩트 또는 메트릭을 정의하고 쿼리에서 팩트 또는 메트릭이 반환되지 않도록 하려면 PRIVATE 키워드를 지정하여 팩트 또는 메트릭을 비공개로 표시하면 됩니다. 예:
참고
차원은 비공개로 표시할 수 없습니다. 차원은 항상 공개입니다.
비공개 팩트 또는 메트릭이 있는 의미 체계 뷰를 쿼리할 때는 다음 절에 비공개 팩트 또는 메트릭을 지정할 수 없습니다.
SELECT 목록
SEMANTIC_VIEW 절의 FACTS
SEMANTIC_VIEW 절의 METRICS
METRICS
SELECT 문 또는 SEMANTIC_VIEW 절의 WHERE
일부 명령과 함수에는 다음과 같이 비공개 팩트와 메트릭이 포함됩니다.
비공개 팩트와 메트릭은 DESCRIBE SEMANTIC VIEW 명령의 출력에 나타납니다. 비공개 팩트 및 메트릭 행의
access_modifier열에는PRIVATE이 표시됩니다.비공개 팩트 및 메트릭은 의미 체계 뷰를 위한 SQL 문 가져오기 에 설명된 것처럼 GET_DDL 함수 호출의 반환 값에 나열됩니다.
일부 명령과 함수에는 특정 조건에서만 비공개 팩트와 메트릭이 포함됩니다.
비공개 팩트 및 메트릭은 의미 체계 뷰에 대해 REFERENCES또는 OWNERSHIP 권한이 부여된 역할을 사용하는 경우에만 INFORMATION_SCHEMA:doc:
SEMANTIC_FACTS</sql-reference/info-schema/semantic_facts>및 SEMANTIC_METRICS 뷰에 나열됩니다.그렇지 않으면 이러한 뷰에는 공개 팩트와 메트릭만 나열됩니다.
다른 명령과 함수에는 비공개 팩트와 메트릭이 포함되지 않습니다.
비공개 정보는 SHOW SEMANTIC FACTS 명령의 출력에 표시되지 않습니다.
비공개 메트릭은 SHOW SEMANTIC METRICS 명령의 출력에 표시되지 않습니다.
|cortex-analyst|용 사용자 지정 지침 제공하기¶
의미 체계 뷰에서 다음 방법을 설명하는 :doc:`Cortex Analyst용 지침</user-guide/snowflake-cortex/cortex-analyst/custom-instructions>`을 제공할 수 있습니다.
SQL 문 생성
질문 분류 및 추가 정보를 묻는 메시지 표시
이러한 사용자 지정 지침을 제공하려면 다음 절을 사용합니다.
SQL 문을 생성하는 방법에 대한 지침을 보려면 CREATE SEMANTIC VIEW 명령의 AI_SQL_GENERATION 절을 사용하세요.
예를 들어, |cortex-analyst|에 모든 숫자 열이 소수점 이하 두 자리로 반올림되도록 SQL 문을 생성하라고 지시하려면 다음을 지정합니다.
질문을 분류하는 방법에 대한 지침을 보려면 AI_QUESTION_CATEGORIZATION 절을 사용하세요.
예를 들어, |cortex-analyst|에 사용자에 대한 질문을 거부하라고 지시하려면 다음을 지정합니다.
질문이 명확하지 않은 경우 자세한 내용을 묻는 지침을 제공할 수도 있습니다. 예:
YAML 사양에서 의미 체계 뷰 만들기¶
YAML 사양 <semantic-view-yaml-spec>`에서 의미 체계 뷰를 생성하려면 :doc:/sql-reference/stored-procedures/system_create_semantic_view_from_yaml` 저장 프로시저를 호출하면 됩니다.
먼저, TRUE를 세 번째 인자로 전달하여 YAML 사양에서 의미 체계 뷰를 만들 수 있는지 확인합니다.
다음 예제에서는 YAML에서 지정된 의미 체계 모델 사양을 사용하여 데이터베이스 my_db 및 스키마 my_schema 에 tpch_analysis 이름의 의미 체계를 만들 수 있는지 확인합니다.
이 사양이 유효한 경우 해당 저장 프로시저는 다음 메시지를 반환합니다.
YAML 구문이 유효하지 않은 경우 해당 저장 프로시저는 예외를 발생시킵니다. 예를 들어, 콜론이 누락된 경우 다음 결과가 나타납니다.
저장 프로시저는 예외를 발생시켜 YAML 구문이 유효하지 않음을 나타냅니다.
해당 사양이 존재하지 않는 물리적 테이블을 참조하는 경우 저장 프로시저는 예외를 발생시킵니다.
마찬가지로, 사양이 존재하지 않는 기본 키 열을 참조하는 경우 저장 프로시저는 예외를 발생시킵니다.
그러면 세 번째 인자를 전달하지 않고 저장 프로시저를 호출하여 의미 체계 뷰를 만들 수 있습니다.
다음 예제에서는 데이터베이스 my_db 및 스키마 my_schema 에서 tpch_analysis 이름의 의미 체계 뷰를 만듭니다.
기존 의미 체계 뷰의 주석 수정¶
기존 의미 체계 뷰의 주석을 수정하려면 ALTER SEMANTIC VIEW 명령을 실행합니다.
참고
ALTERSEMANTICVIEW 명령을 사용하는 경우 주석 이외의 속성을 변경할 수 없습니다. 의미 체계 뷰의 다른 속성을 변경하려면 의미 체계 뷰를 바꿉니다. 기존 의미 체계 뷰 바꾸기 섹션을 참조하십시오.
COMMENT 명령을 사용하여 의미 체계 뷰의 주석을 설정할 수 있습니다.
기존 의미 체계 뷰 바꾸기¶
기존 의미 체계 뷰를 바꾸려면(예: 뷰의 정의를 변경하려면) CREATE SEMANTIC VIEW 를 실행할 때 OR REPLACE 를 지정합니다. 기존 의미 체계 뷰에 부여된 권한을 유지하려면 COPY GRANTS 를 지정합니다. 예:
의미 체계 뷰 목록 보기¶
현재 스키마 또는 지정된 스키마에서 의미 체계 뷰를 목록으로 표시하려면 SHOW SEMANTIC VIEWS 명령을 실행합니다. 예:
SHOW OBJECTS 명령의 출력에 의미 체계 뷰가 포함됩니다. kind 열에서 오브젝트 유형은 ``VIEW``로 나열됩니다. 예:
ACCOUNT_USAGE 및 INFORMATION_SCHEMA 스키마 에서 의미 체계 뷰에 대한 뷰를 쿼리할 수도 있습니다.
차원, 정보 및 메트릭 나열하기¶
뷰, 스키마, 데이터베이스 또는 계정에서 사용할 수 있는 차원, 정보, 메트릭을 나열하기 위해 다음 명령을 실행할 수 있습니다.
기본적으로, 이 명령은 현재 스키마에 정의된 의미 체계 뷰에서 사용할 수 있는 차원, 정보, 메트릭을 나열합니다.
다음 예에서는 다양한 범위 내에서 의미 체계 뷰에 대한 차원, 팩트 및 메트릭을 나열하는 방법을 보여줍니다.
현재 데이터베이스의 의미 체계 뷰에 차원, 팩트 및 메트릭을 나열합니다.
특정 스키마 또는 데이터베이스의 의미 체계 뷰에 차원, 팩트 및 메트릭을 나열합니다.
계정의 의미 체계 뷰에 차원, 팩트 및 메트릭을 나열합니다.
특정 의미 체계 뷰에 차원, 팩트 및 메트릭을 나열합니다.
의미 체계 뷰를 쿼리하려는 경우 SHOW SEMANTIC DIMENSIONS FOR METRIC 명령을 사용하여 특정 메트릭을 지정할 때 반환할 수 있는 차원을 결정할 수 있습니다. 자세한 내용은 지정된 메트릭에 대해 반환할 수 있는 차원 선택 섹션을 참조하십시오.
의미 체계 뷰에 대한 SHOW COLUMNS 명령을 실행하는 경우, 출력에는 의미 체계 뷰의 차원, 팩트 및 메트릭이 포함됩니다. kind 열은 행이 차원, 팩트 또는 메트릭을 나타내는지 여부를 나타냅니다.
예:
의미 체계 뷰에 대한 세부 정보 보기¶
의미 체계 뷰의 세부 정보를 보려면 DESCRIBE SEMANTIC VIEW 명령을 실행합니다. 예:
의미 체계 뷰를 위한 SQL 문 가져오기¶
GET_DDL 함수를 호출하여 의미 체계 뷰를 생성한 DDL 문을 검색할 수 있습니다.
참고
의미 체계 뷰에 대해 이 함수를 호출하려면, 의미 체계 뷰에 대해 REFERENCES 또는 OWNERSHIP 권한이 부여된 역할을 사용해야 합니다.
GET_DDL 을 호출할 때 'SEMANTIC_VIEW' 를 오브젝트 유형으로 전달합니다. 예:
반환 값에는 비공개 팩트 및 메트릭 (PRIVATE 키워드로 표시된 팩트 및 메트릭)이 포함됩니다.
의미 체계 뷰의 YAML 사양 가져오기¶
의미 체계 뷰에 대해 YAML 사양 <semantic-view-yaml-spec>`을 가져오려면 :doc:/sql-reference/functions/system_read_yaml_from_semantic_view` 함수를 호출합니다.
다음 예제에서는 데이터베이스 my_db 및 스키마 my_schema 에서 tpch_analysis 이름의 의미 체계 뷰에 대한 YAML 사양을 반환합니다.
의미 체계 뷰를 Tableau 데이터 소스(TDS) 파일로 내보내기¶
의미 체계 뷰를 Tableau 데이터 소스(TDS) 파일<https://help.tableau.com/current/pro/desktop/en-us/export_connection.htm#options-for-saving-a-local-data-source>`_로 내보내려면 :doc:/sql-reference/functions/system_export_tds_from_semantic_view` 함수를 호출합니다.
다음 예제에서는 의미 체계 뷰 ``my_sv_for_export``에 대한 TDS 파일 내용을 반환합니다.
XML을 .tds 파일에 복사하고 Tableau Desktop에서 파일을 엽니다.
Tableau Desktop은 왼쪽의 폴더 목록에 각 논리 테이블에 대한 폴더를 표시합니다. 폴더 이름은 밑줄 대신 공백을 사용하며 각 단어는 대문자로 시작합니다. 예를 들어, date_dim 논리 테이블의 폴더 이름은 ``Date Dim``입니다.
각 폴더에는 의미 체계 뷰의 차원, 팩트, 메트릭에 해당하는 Tableau 차원과 측정값이 포함되어 있습니다.
다음 섹션에서는 변환 프로세스에 대한 자세한 내용과 제한 사항을 제공합니다.
변환 정보¶
이 함수는 의미 체계 뷰의 차원, 팩트 및 메트릭을 Tableau TDS 파일에서 다음과 같은 항목으로 변환합니다.
의미 체계 뷰의 요소 |
Tableau에 해당하는 항목(차원 또는 측정값) |
데이터 집계 방법 |
|---|---|---|
차원 |
|
|
숫자 팩트 |
측정값 |
SUM |
숫자가 아닌 팩트 |
차원 |
|
숫자 메트릭 |
측정값 |
TDS 파일은 메트릭 대신 계산된 필드를 사용합니다. 계산된 필드는 메트릭 값을 Snowflake AGG 함수에 전달합니다. |
숫자가 아닌 메트릭 |
차원 |
|
숫자 파생 메트릭 |
측정값 |
TDS 파일은 메트릭 대신 계산된 필드를 사용합니다. 계산된 필드는 메트릭 값을 Snowflake AGG 함수에 전달합니다. |
숫자가 아닌 파생 메트릭 |
차원 |
|
다음 :doc:`Snowflake 데이터 타입 </sql-reference-data-types>`은 해당 Tableau TDS 데이터 타입에 매핑됩니다.
Snowflake 데이터 타입 |
해당하는 Tableau 데이터 타입 |
|---|---|
NUMBER/FIXED(소수 자릿수가 0보다 큰 경우) |
real |
NUMBER/FIXED(소수 자릿수가 0 또는 Null인 경우) |
정수 |
FLOAT 또는 DECFLOAT |
real |
STRING 또는 BINARY |
문자열 |
BOOLEAN |
boolean |
TIME |
시간 |
DATE |
날짜 |
DATETIME 또는 TIMESTAMP |
날짜/시간 |
GEOGRAPHY |
공간 |
반정형(VARIANT, OBJECT, ARRAY), 정형(ARRAY, OBJECT, MAP), 비정형(FILE), GEOMETRY, UUID, VECTOR |
문자열 |
TDS 파일에는 Snowflake에 연결하기 위해 사용자 지정된 다음 `기능 <https://help.tableau.com/current/pro/desktop/en-us/odbc_capabilities.htm>`_이 있습니다.
사용자 지정 이름 |
값 |
사용자 지정의 효과 |
|---|---|---|
|
|
Tableau가 열 이름을 확인하기 위해 :samp:`SELECT * FROM {table} WHERE 1=0`과 같은 쿼리를 실제로 실행하지 못하게 방지합니다. |
|
|
Tableau가 유형에 대해 알아보기 위해 문을 “준비”(실행하지 않고 구문 분석하도록 Snowflake로 전송)하지 못하게 방지합니다. |
|
|
Tableau가 |
|
|
Tableau가 표준 ODBC |
|
|
데이터베이스 이름을 검색할 때 Tableau가 밑줄을 이스케이프하지 못하게 방지합니다. |
Tableau Desktop에서 의미 체계 뷰 사용 시 제한 사항¶
Tableau Desktop의 의미 체계 뷰에는 다음 제한 사항이 적용됩니다.
의미 체계 뷰에서 추출을 생성할 수 없습니다.
연결을 :extui:`Live`에서 :extui:`Extract`로 변경하는 경우, Tableau Desktop은 다음 오류와 함께 실패합니다.
의미 체계 뷰에서 Measure Values 필드를 사용할 수 없습니다.
의미 체계 뷰에서 Measure Values 필드를 선택하는 경우 Tableau Desktop은 다음 오류를 보고합니다.
의미 체계 뷰에서 Count 필드를 선택할 수 없습니다.
:extui:`SemanticViewName(Count)`를 선택하는 경우 Tableau Desktop은 다음 오류를 보고합니다.
행 수는 쿼리에 지정된 차원, 팩트, 메트릭에 따라 다를 수 있으므로 Tableau Desktop은 의미 체계 뷰의 행 수를 보고할 수 없습니다.
측정값 자체를 드래그할 수 없습니다.
측정값을 드래그하면 Tableau Desktop이 다음 오류를 보고합니다.
숫자가 아닌 메트릭을 직접 사용할 수 없습니다.
SYSTEM$EXPORT_TDS_FROM_SEMANTIC_VIEW는 숫자가 아닌 메트릭을 Tableau의 차원으로 변환합니다. 이러한 차원 중 하나를 사용하려고 하면 Tableau Desktop에서 다음 오류가 보고됩니다.
이 문제를 해결하려면 차원을 측정값으로 변환합니다.
의미 체계 뷰 이름 변경하기¶
의미 체계 뷰의 이름을 변경하려면 :doc:`ALTER SEMANTIC VIEW … RENAME TO … </sql-reference/sql/alter-semantic-view>`를 실행합니다. 예:
의미 체계 뷰 제거하기¶
의미 체계 뷰를 제거하려면 DROP SEMANTIC VIEW 명령을 실행합니다. 예:
의미 체계 뷰에 권한 부여하기¶
의미 체계 뷰 권한 에는 의미 체계 뷰에 부여할 수 있는 권한이 목록으로 표시됩니다.
의미 체계 뷰를 사용하려면 해당 뷰에 대한 다음 권한이 필요합니다.
해당 뷰에 DESCRIBE SEMANTIC VIEW 명령을 실행하려면 모든 권한(예: MONITOR, REFERENCES, SELECT)이 필요합니다.
SHOW SEMANTIC VIEWS 명령의 출력에 해당 뷰를 표시하려면 뷰에 대한 모든 권한이 필요합니다.
의미 체계 뷰를 쿼리하려면 SELECT 권한이 필요합니다.
참고
의미 체계 뷰를 쿼리하려고 할 때 의미 체계 뷰에서 사용되는 테이블에 대한 SELECT 권한은 필요하지 않습니다. 의미 체계 뷰 자체에 대해서만 SELECT 권한이 필요합니다.
이 동작은 표준 뷰를 쿼리하는 데 필요한 권한 과 일치합니다.
Cortex Analyst 에서 소유하지 않은 의미 체계 뷰를 사용하려면 해당 뷰에 대한 REFERENCES 및 SELECT 권한이 있는 역할을 사용해야 합니다.
의미 체계 뷰에 REFERENCES 및 SELECT 권한을 부여하려면 GRANT <privileges> … TO ROLE 명령을 사용합니다. 예를 들어, my_semantic_view``라는 의미 체계 뷰에 대한 REFERENCES 및 SELECT 권한을 ``my_analyst_role 역할에 부여하려면 다음 문을 실행하면 됩니다.
Cortex Analyst 사용자와 공유하려는 의미 체계 뷰가 포함된 스키마가 있는 경우 향후 부여 를 사용하여 해당 스키마에서 생성한 모든 의미 체계 뷰에 대한 권한을 부여할 수 있습니다. 예: