객체 유형, 링크 유형과 출력 보안

Pipeline Builder에서는 배치 또는 스트리밍 데이터에서 객체 유형과 링크 유형을 만들 수 있습니다. 객체의 속성과 관계를 출력으로 먼저 정의하면 필요한 스키마에 맞춰 변환을 구성할 수 있습니다.

일반적인 스트리밍 데이터셋 기반 객체에는 사용자 편집과 다대다 링크 구성을 지원하지 않습니다. 스트리밍에서 편집이 필요하면 뒤에서 설명하는 Beta direct datasource의 지원 조건을 확인합니다.

객체 유형 추가

오른쪽 Pipeline outputs에서 Object type > Add를 선택하면 빈 객체 템플릿이 열립니다. 이름, 아이콘과 속성을 정합니다.

Name을 입력하면 Plural name과 Object type ID가 자동으로 채워집니다. 처음 배포한 뒤에는 객체 유형 ID를 바꿀 수 없습니다. 파이프라인이 소유한 객체 유형의 API 이름은 이후에도 수정할 수 있습니다.

Enter data manually로 데이터를 입력하거나 기존 데이터셋 및 변환 노드의 출력을 객체 입력에 연결합니다.

이미 변환 노드가 있다면 그 노드에서 Add output > New object type을 선택하면 데이터가 연결된 객체 출력을 만들 수 있습니다.

플랫폼 인스턴스에 온톨로지가 여러 개 있으면 객체를 만들 때 대상 온톨로지를 지정해야 합니다. 지정하지 않으면 An ontology must be specified to publish ontology type outputs 오류가 발생합니다. 객체 또는 아래쪽 패널의 Set ontology에서 선택합니다.

Pipeline Builder에서 새 객체를 정의할 수 있지만, 외부에서 만든 기존 객체를 임의로 수정하거나 삭제하는 기능은 아닙니다. 이 파이프라인의 데이터셋을 기반으로 하는 객체를 가져오는 절차는 뒤의 관리 복귀 항목을 따릅니다.

API 이름과 편집 허용

객체 유형 옆의 Edit에서 API name을 변경합니다. 제출할 때 같은 온톨로지 안의 중복, 이름 형식과 최대 100자 길이를 검사합니다. API 이름 변경과 배포 후 고정되는 객체 유형 ID 변경은 구분합니다.

Pipeline Builder에서 만든 배치 데이터셋 기반 객체는 Builder 또는 Ontology Manager에서 편집을 허용할 수 있습니다. 객체의 Edit에서 Allow edits to objects of this type을 켜고 저장한 뒤 배포합니다.

인터페이스 구현

객체 출력에 인터페이스를 구현하면 인터페이스의 속성을 이 객체의 실제 속성에 연결합니다.

1. 속성 매핑 아래의 Implement interface를 선택합니다.

   

2. 구현할 인터페이스 유형을 검색하고 Next를 선택합니다.

   

3. 인터페이스 속성을 객체 속성에 매핑합니다. Optional이 아닌 모든 속성에 매핑이 필요하며 선택적인 속성은 비워 둘 수 있습니다.

4. Confirm and implement를 선택합니다.

   

구현 목록에서 Re-map으로 매핑을 바꾸거나 제거 버튼으로 구현을 제거할 수 있습니다.

이 경로에서는 인터페이스의 링크 유형 및 액션 유형 제약을 구성하지 못합니다. 객체 속성 역시 Pipeline Builder가 지원하는 속성 구성이어야 합니다. Type class나 render hint를 Builder에서 설정할 수 없으므로 그러한 구성을 요구하는 인터페이스 속성을 이 화면에서 새로 구성할 수는 없습니다.

Direct datasource로 스트리밍 객체 편집 허용

Direct datasource는 낮은 지연 시간과 낮은 처리량의 온톨로지 쓰기에 맞춘 Beta 기능입니다. 플랫폼 인스턴스에 따라 제공되지 않을 수 있으며 스트리밍 기반 객체의 편집도 지원합니다.

1. 스트리밍 파이프라인에 객체 유형 출력을 만듭니다.
2. Use a direct datasource to back this object type과 Allow edits to objects of this type을 모두 켭니다.
3. 객체의 속성과 매핑을 구성하고 배포합니다.

배포 후 객체 유형은 Ontology Manager에 나타나며 객체를 Insight와 Object Explorer에서 볼 수 있습니다.

링크 유형 정의

객체 유형 출력을 준비한 뒤 Pipeline outputs > Link type > Add를 선택합니다. 양쪽 객체 유형과 관계의 다중성을 지정합니다.

Builder에서 정의한 링크는 같은 파이프라인에서 만든 객체 유형끼리만 연결할 수 있습니다. 외부 객체와 연결하려면 Ontology Manager에서 링크를 만듭니다. 최초 배포 후에는 링크 유형 ID와 양쪽 원천 및 대상 객체 유형을 바꿀 수 없습니다.

가상 항공 사례에서 Aircraft 하나와 여러 Flight의 일대다 관계를 만들 수 있습니다. Flight에서 Aircraft로 가는 이름은 Assigned Aircraft, Aircraft에서 Flight들로 가는 복수 이름은 Scheduled Flights처럼 정합니다.

다대다를 선택하면 조인 테이블을 연결하라는 안내가 나타납니다. 테이블은 양쪽 객체 기본 키의 연결 조합을 모두 포함해야 합니다. 예를 들어 Class와 Student를 연결하는 각 행에 수업 키와 학생 키를 둡니다.

그래프에서 객체 출력 두 개를 선택하고 오른쪽 클릭의 New link type을 선택하면 양쪽 정보가 채워집니다.

객체 하나만 선택해 New link type을 만들면 한쪽 정보만 채워지므로 반대쪽을 추가로 지정합니다.

온톨로지 검증 오류 해결

다음 변경은 배포 전에 해결할 검증 오류를 만들 수 있습니다.

• 같은 객체나 링크를 Builder와 Ontology Manager에서 서로 충돌하게 변경한 경우입니다.
• 파이프라인 밖의 링크 유형이 참조하는 객체의 기본 키를 바꾼 경우입니다.
• 객체 스키마를 바꿔 기존 사용자 편집의 스키마 마이그레이션이 필요한 경우입니다.

오른쪽 Deploy this pipeline > Errors에서 오류와 해결 방법을 확인합니다. Resolve에 화살표가 있으면 Ontology Manager로 이동하고, 없으면 Builder 안에서 해결합니다. 해결 전에는 배포할 수 없습니다.

Ontology Manager에서 충돌 해결

안내에 따라 충돌을 해소합니다. 변경이 기존 편집에 영향을 주면 편집을 버릴지 새 객체 버전에 맞게 마이그레이션할지 선택합니다. 추가 선택이 필요 없으면 Apply로 반영합니다.

반영 후 Go back to pipeline으로 돌아갑니다.

복귀 후 Ontology type outputs are out of date with the ontology가 나타날 수 있습니다. 파이프라인이 충돌 해결로 바뀐 온톨로지 상태를 아직 가져오지 않은 경우이므로 Resolve로 갱신합니다.

Builder에서 스키마 마이그레이션

객체 스키마가 온톨로지 main의 최신 스키마와 달라 마이그레이션이 필요하면 Resolve에서 전략을 선택합니다.

영향받는 속성마다 Drop edits from property로 기존 편집을 버리거나 새 속성 버전에 맞게 마이그레이션합니다. 선택을 마친 뒤 Apply migrations를 누릅니다.

객체 관리 가져오기와 넘기기

데이터셋 기반 객체를 다시 가져오기

이 파이프라인의 데이터셋 출력을 기반으로 하는 객체는 Pipeline outputs 옆의 톱니바퀴에서 Replace with objects로 가져올 수 있습니다.

Replace datasets with ontology type outputs 창에서 변환할 데이터셋 출력을 고르고 Import selected outputs를 선택합니다.

변경 사항을 저장하고 배포합니다.

Ontology Manager로 관리 이전

공유 속성 유형이나 런타임 파생 속성처럼 Builder에서 지원하지 않는 객체 구성이 필요하면 해당 객체 유형을 disown하여 Ontology Manager로 관리를 넘길 수 있습니다. 이후 해당 온톨로지 유형의 수정은 Ontology Manager에서 수행합니다.

객체 유형들을 선택하고 Disown selected object and link types를 선택합니다. 선택한 객체를 참조하는 링크 유형도 함께 이전됩니다. 이 작업은 main의 최신 저장 버전이 성공적으로 배포된 상태에서만 가능합니다.

그래프의 객체 출력은 해당 객체를 뒷받침하는 데이터셋 출력으로 바뀝니다. 오른쪽 출력 옆의 아이콘으로 Ontology Manager의 객체를 열 수 있습니다.

Direct datasource 객체를 disown하면 그래프 노드가 스트리밍 데이터셋처럼 표시되지만 실제로는 객체의 direct datasource를 나타냅니다. 일반 스트리밍 데이터셋처럼 자체에 데이터를 저장하는 자산이 아니며 데이터는 온톨로지에 저장됩니다. 이전 후에도 Ontology Manager나 Insight에서 객체를 열 수 있습니다.

관리 이전 후 파이프라인을 배포합니다. 기반 데이터의 열 이름은 객체 속성에 설정한 backing column 이름과 정확히 같아야 합니다. 예를 들어 속성이 routeId 열을 요구하면 출력에도 routeId가 있어야 하며, 다르면 데이터가 빠지거나 인덱싱 job이 실패할 수 있습니다.

행 및 속성 단위 보안

객체 출력에서 Configure granular security를 선택하고 Restricted view policy 또는 Object security policy를 선택합니다.

Restricted view는 행 수준 읽기를 제한합니다. Object security policy는 행과 속성 수준을 함께 제한할 수 있습니다. Builder는 Ontology Manager의 객체 보안 정책 기능 중 일부를 제공합니다.

이 통제는 사용자가 해당 출력에서 읽을 수 있는 데이터를 필터링합니다. 그 규칙이 하위 출력이나 내보내기로 자동 전파되지는 않습니다. Foundry 안의 하위 데이터도 계속 보호해야 하면 보안 표지나 데이터 분류를 함께 적용해야 합니다. 외부로 내보낸 평문 파일에는 Foundry 접근 정책이 자동으로 집행되지 않으므로 반출 허용 범위와 반출 후 보호를 별도로 관리합니다.

객체 보안 정책

Object security policy에는 행 정책, property security policy, 상속 보안 표지 제거와 분류 변경을 설정할 수 있습니다. 기본 객체 정책은 모든 속성에 적용됩니다. 특정 속성에 속성 정책도 설정했다면 사용자는 객체 정책과 속성 정책을 모두 통과해야 그 값을 읽을 수 있습니다.

Granular security 옆의 +를 선택하여 행 수준 정책을 추가합니다. 속성값, 사용자 속성 또는 상수를 비교하는 규칙을 작성합니다.

Marking or classification 사용자 속성을 기준으로 비교할 값은 Marking 또는 Classification 유형이어야 합니다. 상위 변환의 Logical Type Cast로 올바른 논리 유형을 적용합니다.

온톨로지 매핑에서는 보안 표지와 분류를 배열로 감싸야 합니다. 단일 값을 객체 속성에 직접 매핑하면 오류가 발생합니다. 보안 표지는 표시 이름이 아니라 해당 marking ID를 사용해야 합니다.

Back으로 돌아가 Apply를 선택합니다. 상속된 보안 표지는 Mandatory controls에서 제거를 구성하고 Classification에서는 분류를 조정합니다. 직접 입력한 테이블의 분류 조정은 지원하지 않습니다.

속성 정책은 Property security policies > Add로 추가하고 해당 정책의 화살표를 눌러 편집합니다.

Policy name을 정하고 Properties affected에서 대상 속성을 하나 이상 선택합니다. 객체 정책과 같은 방식으로 granular security, mandatory control 또는 classification을 설정합니다. Back으로 돌아가 Apply로 저장합니다.

Restricted view 정책

Restricted view policy 창에서 읽을 수 있는 행을 정합니다. 보안 표지 ID, Marking/Classification 논리 유형과 배열 매핑의 규칙은 객체 보안 정책과 같습니다. 더 많은 구성이 필요하면 restricted view 정책을 객체 정책으로 변환할 수 있습니다.

정책을 구성한 뒤 파이프라인을 저장하고 변경을 제안합니다. 기반 restricted view 및 보안 정책은 변경을 main에 병합하고 성공적으로 배포한 뒤 생성되어 효력이 생깁니다. 브랜치 화면에서 정책을 작성했다는 사실만으로 운영 객체의 접근 통제가 바뀌지는 않습니다.