스토리지 별칭

  • 릴리스 버전: Yokohama
  • 업데이트 날짜 2025년 01월 30일
  • 읽기4분
  • 에서 데이터 조작 및 필드 생성 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 값을 보유합니다.
    그림 1. 스토리지 열 별칭
    작업 테이블에 스토리지 별칭이 a_ref_2 있는 요소입니다.

    이 예시에서 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'임)는 글롬 기능을 사용할 수 없습니다.