스토리지 별칭
에서 데이터 조작 및 필드 생성 ServiceNow AI Platform에서 저장소 별칭이 수행하는 역할에 대해 알아봅니다.
스토리지 별칭을 이해하는 것은 특히 작업 [task] 테이블과 같은 복잡한 테이블 계층 구조를 처리할 때 에서 효과적인 데이터 관리 및 스키마 사용자 지정 ServiceNow AI Platform에 중요합니다.
기본적으로 관리자는 인스턴스 내에서 저장소 열 별칭 [sys_storage_alias] 테이블에 액세스할 수 있습니다. 그러나 이 테이블에 대한 트랜잭션 프로세스는 사용자 인터페이스에서 관리자가 수행할 수 없습니다.
테이블 계층 구조 및 모델
저장소 별칭을 이해하려면 계층 구조당 테이블과 클래스당 테이블의 두 가지 모델을 포함하는 작업 [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을 사용하지 않습니다.
스토리지 별칭 정의
스토리지 별칭은 인스턴스 내 테이블의 모든 필드에 대해 생성됩니다. 저장소 열 별칭 [sys_storage_alias] 테이블의 키 필드를 숙지합니다.
- 요소 이름
- 필드가 사용자에게 표시되는 방식을 나타내며, 이는 사용자 인터페이스 상호작용과 스크립팅에 중요합니다.
- 스토리지 별칭
- 필드의 데이터가 저장되는 정확한 실제 열을 나타냅니다. 저장소 별칭 값은 table_name 값과 함께 사용되어 조작할 데이터를 식별합니다. 저장소 별칭 값은 작업 [task] 테이블의 실제 실제 열입니다.
- 스토리지 테이블 이름
- 요소를 포함하는 실제 테이블을 지정합니다. 계층 구조 테이블당 테이블의 경우 값은 항상 task입니다. 클래스당 테이블의 경우 값은 실제 테이블의 이름입니다.
- 테이블
- 실제 작업 [task] 테이블에서 각 요소가 연결되는 논리 클래스를 지정합니다. Table 요소에는 클래스 판별자인 table_name 값이 있습니다.
이 예에서 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] 테이블의 별칭입니다.
기능 및 사용법
저장소 별칭은 다양한 용도로 사용됩니다.
- 매핑
- 별칭은 논리적 요소(계층 구조당 테이블) 또는 물리적 요소(클래스당 테이블)를 백엔드 데이터베이스의 실제 물리적 열에 매핑합니다. 논리 요소는 논리 요소의 max_length보다 큰 실제 열로 표시될 수 있습니다.
- 글로밍
- 별칭을 사용하면 여러 형제 요소가 계층 구조 모델당 테이블의 단일 물리적 열을 공유할 수 있습니다.
- 레이블 매핑
- 별칭은 sys_documentation(레이블) 기록을 해당 요소와 연결하여 양식, 보고서 및 목록 뷰의 가시성을 향상시킵니다.
제한 및 규칙
- 같은 클래스 내의 두 논리 요소는 실제 열을 공유할 수 없습니다. 예를 들어 인시던트 [incident] 테이블에 생성된 두 개의 문자열 필드는 데이터베이스의 동일한 실제 열에 매핑할 수 없습니다.
- 상위 요소와 해당 하위 요소는 실제 열을 공유할 수 없습니다. 예를 들어, 실제 열이 이미 작업 [task] 테이블의 필드에 매핑되어 있는 경우 인시던트 [incident] 테이블에 생성된 필드를 실제 열에 매핑할 수 없습니다.
- 형제 요소만 실제 열을 공유할 수 있습니다. 예를 들어, 변경 요청 [change_request] 테이블의 참조 필드와 인시던트 [incident] 테이블의 참조 필드는 모두 동일한 물리적 열에 매핑될 수 있습니다.
- 작업 [task] 테이블에서 직접 생성된 필드(여기서 sys_class_name는 "task")는 적용할 수 없습니다.