---
sourceDocument: 요코하마 ServiceNow AI 플랫폼 관리
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ko-KR/yokohama/platform-administration

 Release :

    - yokohama

ft:locale :

    - ko-KR

ft:publication_title :

    - 요코하마 ServiceNow AI 플랫폼 관리

ft:clusterId :

    - platadm

bundleId :

    - platadm

workflow :

    - Platform


---

# 스토리지 별칭

# 스토리지 별칭 {#ariaid-title1}

* 릴리스 버전: Yokohama
* 
* 업데이트 날짜 2025년 01월 30일
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 소요 시간: 4분

에서 데이터 조작 및 필드 생성 Now Platform에서 저장소 별칭이 수행하는 역할에 대해 알아봅니다.

스토리지 별칭을 이해하는 것은 특히 작업 \[task\] 테이블과 같은 복잡한 테이블 계층 구조를 처리할 때 에서 효과적인 데이터 관리 및 스키마 사용자 지정 Now Platform에 중요합니다.

기본적으로 관리자는 인스턴스 내에서 저장소 열 별칭 \[sys_storage_alias\] 테이블에 액세스할 수 있습니다. 그러나 이 테이블에 대한 트랜잭션 프로세스는 사용자 인터페이스에서 관리자가 수행할 수 없습니다.

## 테이블 계층 구조 및 모델 {#storage-aliases__section_ny2_sr1_scc}

저장소 별칭을 이해하려면 계층 구조당 테이블과 클래스당 테이블의 두 가지 모델을 포함하는 작업 \[task\] 테이블 내의 테이블 계층 구조에 대한 지식이 필요합니다.

계층 구조당 테이블

:   이 모델은 단일 물리적 테이블인 작업 \[task\] 테이블을 사용하며, 이 테이블은 작업 계층 구조 내의 모든 열이 작업 테이블에만 존재하는 평면화된 계층 구조를 특징으로 합니다. 예를 들어 변경 요청과 관련된 필드는 별도의 변경 요청\[change_request\] 테이블에 있지 않지만 작업 \[task\] 테이블에 통합됩니다. 테이블 \[sys_db_object\] 테이블에서 확장 모델 필드를 확인하여 테이블이 계층 구조당 테이블인지 확인할 수 있습니다. 테이블의 상위가 작업 \[task\] 테이블의 직계 하위인 경우 테이블은 계층 구조당 테이블을 사용합니다.확장된 테이블은 상위 테이블의 계층 구조를 상속합니다. 예를 들어 IMAC \[change_request_imac\] 테이블은 작업 \[task\] 테이블을 확장하는 변경 요청 \[change_request\] 테이블의 하위 테이블입니다. 변경 요청 \[change_request\] 테이블은 계층 구조당 테이블이므로 IMAC \[change_request_imac\] 테이블 모델도 계층 구조당 테이블입니다. 인시던트 \[incident\] 테이블, 변경 요청 \[change_request\] 테이블 및 문제 \[problem\] 테이블과 같은 레거시 테이블은 모두 평면화된 작업 \[task\] 테이블 계층 구조의 일부입니다.

클래스당 테이블
:   이 모델은 데이터베이스에 물리적으로 존재하는 테이블에 적용됩니다. 작업 행 수가 100만 개 행을 초과할 때 작업 \[task\] 테이블에서 직접 확장되는 새 테이블에 사용됩니다. 계층 구조당 테이블과 달리 클래스당 테이블은 평면화된 계층 구조 내에서 작동하지 않으므로 glomming을 사용하지 않습니다.

## 스토리지 별칭 정의 {#storage-aliases__section_q1q_zs1_scc}

스토리지 별칭은 인스턴스 내 테이블의 모든 필드에 대해 생성됩니다. 저장소 열 별칭 \[sys_storage_alias\] 테이블의 키 필드를 숙지합니다.

요소 이름
:   필드가 사용자에게 표시되는 방식을 나타내며, 이는 사용자 인터페이스 상호작용과 스크립팅에 중요합니다.

스토리지 별칭
:   필드의 데이터가 저장되는 정확한 실제 열을 나타냅니다. 저장소 별칭 값은 table_name 값과 함께 사용되어 조작할 데이터를 식별합니다. 저장소 별칭 값은 작업 \[task\] 테이블의 실제 실제 열입니다.

스토리지 테이블 이름
:   요소를 포함하는 실제 테이블을 지정합니다. 계층 구조 테이블당 테이블의 경우 값은 항상 task입니다. 클래스당 테이블의 경우 값은 실제 테이블의 이름입니다.

테이블
: 실제 작업 \[task\] 테이블에서 각 요소가 연결되는 논리 클래스를 지정합니다. Table 요소에는 클래스 판별자인 table_name 값이 있습니다.  
그림 1. 스토리지 열 별칭

이 예에서 cab_delegate 요소의 스토리지 별칭은 a_ref_2이고 데이터가 저장되는 실제 스토리지 테이블은 task입니다. 이 예는 실제 작업 \[task\] 테이블의 동일한 별칭 a_ref_2에 모두 연결되는 작업 \[table\]의 서로 다른 논리 클래스에 있는 10개의 논리적 요소를 보여줍니다.

형제 요소는 작업 \[task\] 테이블에서 하나의 물리적 열을 공유한다는 것을 의미합니다. 다음과 같은 쿼리를 사용하여 논리적 요소 cab_delegate에서 데이터를 쿼리할 수 있습니다.

    SELECT a_ref_2 from task WHERE sys_class_name='change_request' AND a_ref_2 IS NOT NULL

쿼리는 실제 열 a_ref_2의 데이터를 지정합니다. 클래스 판별자 change_request는 저장소 별칭 a_ref_2와 함께 사용되어 물리적 작업 \[task\] 테이블의 논리 클래스 change_request에서 논리 요소 cab_delegate을 쿼리합니다.

실제 실제 테이블에 생성된 필드의 명명 규칙은 필드 유형에 따라 다를 수 있습니다. 이 예에서 a_ref_2는 참조 필드의 값을 포함하는 작업 \[task\] 테이블의 별칭입니다.

## 기능 및 사용법 {#storage-aliases__section_lyv_mt1_scc}

저장소 별칭은 다양한 용도로 사용됩니다.

매핑
:   별칭은 논리적 요소(계층 구조당 테이블) 또는 물리적 요소(클래스당 테이블)를 백엔드 데이터베이스의 실제 물리적 열에 매핑합니다. 논리 요소는 논리 요소의 max_length보다 큰 실제 열로 표시될 수 있습니다.

글로밍
:   별칭을 사용하면 여러 형제 요소가 계층 구조 모델당 테이블의 단일 물리적 열을 공유할 수 있습니다.

레이블 매핑
:   별칭은 sys_documentation(레이블) 기록을 해당 요소와 연결하여 양식, 보고서 및 목록 뷰의 가시성을 향상시킵니다.

## 제한 및 규칙 {#storage-aliases__section_e14_rt1_scc}

* 같은 클래스 내의 두 논리 요소는 실제 열을 공유할 수 없습니다. 예를 들어 인시던트 \[incident\] 테이블에 생성된 두 개의 문자열 필드는 데이터베이스의 동일한 실제 열에 매핑할 수 없습니다.
* 상위 요소와 해당 하위 요소는 실제 열을 공유할 수 없습니다. 예를 들어, 실제 열이 이미 작업 \[task\] 테이블의 필드에 매핑되어 있는 경우 인시던트 \[incident\] 테이블에 생성된 필드를 실제 열에 매핑할 수 없습니다.
* 형제 요소만 실제 열을 공유할 수 있습니다. 예를 들어, 변경 요청 \[change_request\] 테이블의 참조 필드와 인시던트 \[incident\] 테이블의 참조 필드는 모두 동일한 물리적 열에 매핑될 수 있습니다.
* 작업 \[task\] 테이블에서 직접 생성된 필드(여기서 sys_class_name는 "task")는 적용할 수 없습니다.
{#storage-aliases__ul_ktv_st1_scc}