스토리지 별칭
에서 데이터 조작 및 필드 생성 Now Platform에서 저장소 별칭이 수행하는 역할에 대해 알아봅니다.
저장소 별칭을 이해하는 것은 효과적인 데이터 관리 및 스키마 사용자 지정을 Now Platform위해 중요하며, 특히 작업 [task] 테이블과 같은 복잡한 테이블 계층 구조를 처리할 때 중요합니다.
기본적으로 관리자는 인스턴스 내의 스토리지 열 별칭 [sys_storage_alias] 테이블에 액세스할 수 있습니다. 그러나 이 테이블에 대한 트랜잭션 프로세스는 관리자가 사용자 인터페이스에서 수행할 수 없습니다.
테이블 계층 구조 및 모델
저장소 별칭을 이해하려면 작업 [task] 테이블 내의 테이블 계층 구조에 대한 지식이 필요하며, 여기에는 계층 구조당 테이블 및 클래스당 테이블이라는 두 가지 모델이 포함됩니다.
- 계층 구조당 테이블
- 이 모델은 작업 계층 구조 내의 모든 열이 작업 테이블에만 존재하는 평면화된 계층 구조를 특징으로 하는 단일 물리적 테이블인 작업 [task] 테이블을 사용합니다. 예를 들어 변경 요청과 관련된 필드는 별도의 변경 요청[change_request] 테이블에 있지 않지만 작업[task] 테이블에 통합됩니다. 테이블 [sys_db_object] 테이블에서 확장 모델 필드를 확인하여 테이블이 계층 구조당 테이블인지 확인할 수 있습니다. 테이블의 상위가 작업 [task] 테이블의 직계 하위인 경우 테이블은 계층 구조당 테이블을 사용합니다.
확장된 테이블은 상위 테이블의 계층 구조를 상속합니다. 예를 들어, IMAC [change_request_imac] 테이블은 변경 요청 [change_request] 테이블의 하위 테이블로, 작업 [task] 테이블을 확장합니다. 변경 요청 [change_request] 테이블은 계층 구조당 테이블이므로 IMAC [change_request_imac] 테이블 모델도 계층 구조당 테이블입니다. 인시던트 [incident] 테이블, 변경 요청 [change_request] 테이블 및 문제 [problem] 테이블과 같은 레거시 테이블은 모두 평면화된 작업 [task] 테이블 계층 구조의 일부입니다.
- 클래스당 테이블
- 이 모델은 데이터베이스에 실제로 존재하는 테이블에 적용됩니다. 작업 행 수가 100만 행을 초과하는 경우 작업 [task] 테이블에서 직접 확장되는 새 테이블에 사용됩니다. 계층 구조당 테이블과 달리 클래스당 테이블은 평면화된 계층 구조 내에서 작동하지 않기 때문에 글로밍을 사용하지 않습니다.
스토리지 별칭 정의
스토리지 별칭은 인스턴스 내 테이블의 모든 필드에 대해 생성됩니다. 스토리지 열 별칭 [sys_storage_alias] 테이블의 키 필드를 숙지합니다.
- 요소 이름
- 필드가 사용자에게 표시되는 방식을 나타내며 이는 사용자 인터페이스 상호작용 및 스크립팅에 중요합니다.
- 스토리지 별칭
- 필드에 대한 데이터가 저장되는 정확한 물리적 열을 나타냅니다. 스토리지 별칭 값은 table_name 값과 함께 사용되어 조작할 데이터를 식별합니다. 스토리지 별칭 값은 작업 [task] 테이블의 실제 물리적 열입니다.
- 스토리지 테이블 이름
- 요소를 수용하는 물리적 테이블을 지정합니다. 계층 구조 테이블당 테이블의 경우 값은 항상 작업입니다. Table per class tables(클래스당 테이블) 테이블의 경우 값은 물리적 테이블의 이름입니다.
- 테이블
- 각 요소가 실제 작업 [task] 테이블에 링크되는 논리 클래스를 지정합니다. Table 요소는 클래스 판별자인 table_name 값을 보유합니다.
이 예시에서 cab_delegate 요소의 스토리지 별칭은 a_ref_2이고 데이터가 저장되는 물리적 스토리지 테이블은 task입니다. 이 예는 실제 작업 [task] 테이블의 동일한 별칭 a_ref_2에 모두 링크되는 작업 [테이블]의 서로 다른 논리 클래스에 있는 10개의 논리 요소를 보여줍니다.
형제 요소는 글롬(glommed)되어 작업 [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] 테이블에 생성된 두 개의 문자열 필드는 데이터베이스의 동일한 물리적 열에 매핑할 수 없습니다.
- 부모 요소와 해당 자식은 물리적 열을 공유할 수 없습니다. 예를 들어 인시던트 [incident] 테이블에 생성된 필드는 해당 물리적 열이 작업 [task] 테이블의 필드에 이미 매핑되어 있는 경우 물리적 열에 매핑할 수 없습니다.
- 형제 요소만 물리적 열을 공유할 수 있습니다. 예를 들어 변경 요청 [change_request] 테이블의 참조 필드와 인시던트 [incident] 테이블의 참조 필드는 모두 동일한 물리적 열에 매핑할 수 있습니다.
- 작업 [task] 테이블에 직접 생성된 필드(여기서 sys_class_name 'task'임)는 글롬 기능을 사용할 수 없습니다.