단일한 진리의 원천

이 글은 검증을 위해 인용구가 추가로 필요하다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선할 수 있도록 도와주십시오. 공급되지 않은 재료는 도전하여 제거할 수 있다. 출처 찾기: "단일 진리의 출처" – 뉴스 · 신문 · 책 · 학자 · JSTOR (2021년 1월) (이 템플릿 메시지를 제거하는 방법과 시기 알아보기)

정보 과학과 정보 기술에서, 정보 시스템의 단일 출처(SSOT) 아키텍처, 또는 단일 진리의 점(SPOT) 아키텍처에서, 정보 시스템의 경우, 정보 모델과 관련 데이터 스키마를 구조화하여, 모든 데이터 요소를 한 곳에서만 마스터(또는 편집)하여, c에 데이터 정규화를 제공한다.양극 형식(예: 데이터베이스 정규화 또는 내용 전폐)이 데이터 요소(아마도 관계 스키마의 다른 영역 또는 먼 연합 데이터베이스의 경우)에 대한 모든 가능한 연결은 참조로만 이루어진다.데이터의 다른 모든 위치는 일차적인 "진실의 출처" 위치를 참조하기 때문에, 일차 위치의 데이터 요소에 대한 업데이트는 전체 시스템에 전파되어 효율성/생산성 향상, 잘못된 불일치(예: 중복 값/복사본)의 손쉬운 여러 장점을 동시에 제공한다.잊어버린 경우), 그리고 버전 관리를 크게 단순화한다.SSOT 아키텍처가 없다면, 만연한 포킹은 명확성과 생산성을 해치고, 힘든 유지보수 요구를 부과한다.

SSOT 아키텍처의 구축은 잘못 연결된 중복 또는 비정규화된 데이터 요소(의도적이거나 의도하지 않은 명시적 데이터 모델의 비정규화의 직접적인 결과)가 구식 정보 검색의 위험을 야기하는 기업 환경에서 점점 더 중요해지고 있으며, 따라서 부정확한 정보를 검색할 수 있다.일반적인 예(예: 구현의 예)는 다음과 같다.

• 전자 건강 기록(EHRs)에서는 SSOT 역할을 하는 단일 참조 저장소에 대해 환자 신원을 정확하게 검증하는 것이 필수적이다.기업 내 데이터의 중복 표현은 데이터베이스 테이블, 행 또는 셀의 중복이 아닌 포인터를 사용하여 구현될 것이다.이렇게 하면 권한 있는 위치의 요소에 대한 데이터 업데이트가 대규모 전체 엔터프라이즈 아키텍처의 모든 연합 데이터베이스 영역에 포괄적으로 배포될 수 있다.EHR은 SSOT 아키텍처가 얼마나 필요하며 달성하기가 어려운지를 예시하는 훌륭한 등급이다: 조직간 건강 정보 교환은 본질적으로 사이버 보안 역량 장애물이기 때문에 도전적이다. 그럼에도 불구하고 의료 오류를 예방하기 위해 비효율성의 낭비되는 비용을 예방하기 위해 필요하다.(중복된 작업 또는 재작업 등), 그리고 (유능한 관리 전환을 달성하기 위해) 일차적 관리 및 의료 가정 개념을 실현한다.
• 일반적인 원칙 또는 컨텐츠 관리에 있어 이상적인 단일 소스 게시물은 나중에 필요할 때 새로 고쳐지는 정적 복사본으로 전파될 수 있는 개체의 라이브러리를 통해(다른 방법으로는 최소한) SSOT를 가지는 것에 의존하며, 이는 복사 붙여넣기 또는 가져오기의 새로 고침이 더 큰 업데이트 이벤트에 의해 트리거되는 경우새로운 과학의 진보나 속보로서.컴포넌트 콘텐츠 관리 시스템은 이 수준에서 역량을 제공하는 것을 목표로 하는 콘텐츠 관리 시스템의 한 종류다.

이상적으로 SSOT 시스템은 인증(및 인증 가능), 관련성 및 참조 가능한 데이터를 제공한다.^[1]

실행

온톨로지 상호작용

인정된 전제조건(어떤 주어진 진실의 출처가 존재할 수 있다는 개념의)은 하나의 진리(특정 사실이나 아이디어에 대하여) 이상 존재하지 않는 온톨로지 조건, 즉 그 단어의 일반적 감각과 IT 감각 모두에서 온톨로지적인 주장이라는 것이다.많은 경우, 이것은 문제를 일으키지 않는다(예를 들어, 이름 충돌이나 광범위한 이름 충돌이 적절히 처리되는 한, 특정 네임스페이스 내에서 또는 네임스페이스 전체에 걸쳐서라도).가장 광범위한 맥락(따라서 존재론적 불일치에 관한 가장 가시적인 상황)은 적절한 인식론적 체제 비교와 화해(또는 최소한 협상이나 거래 교환)를 필요로 한다.이 화해의 전형적인 예는 두 개의 다른 종교(X와 Y)에서 온 두 개의 신학대학원 도서관이 SSOT 건축과 정보를 교환할 수 있지만, 진리의 통일은 "종교 X는 신은 보라색이라고 주장하는 반면 종교 Y는 신은 그르다고 주장하는 것"이라는 진술의 수준에 머물 것이다."신은 보라색"이나 "신은 초록색"의 수준이 아니라 "een"이다.이 플랫폼 불가지론적 개념은 법적 정의의 관할권 차이와 관련하여 민간 애플리케이션과 대외 관계 애플리케이션도 가지고 있다. 예를 들어, 특정 경제 렌즈가 좋은지 나쁜지 또는 동기화가 가능한지 여부(예: 자본주의, 사회주의, 혼합 경제), 결혼에 대한 법적 정의(EHR 예: 환자 X가 결혼한 경우)또는, 어느 주법이나 그 주간의 상호주의에 따라, 성 배정이 법적 성별과 동일한지 여부(EHR 예: 환자 X의 성별 또는 성 정체성은 무엇이며, 환자 본인(자체 보고) 또는 다른 사람에 따른 것인지 등).

아키텍처 또는 아키텍처 기능

SSOT의 이상적인 구현은 대부분의 기업에서 거의 불가능하다.이는 많은 조직이 복수의 정보시스템을 보유하고 있으며, 각 정보시스템은 동일한 실체(예: 고객)와 관련된 데이터에 접근할 필요가 있기 때문이다.종종 이러한 시스템은 판매업체로부터 상용 기성품으로 구매되고 비종교적인 방법으로 수정될 수 없다.따라서 이러한 다양한 시스템 각각은 공통 데이터나 실체의 자체 버전을 저장할 필요가 있으며, 따라서 각 시스템은 레코드의 자체 복사본을 보유해야 한다(위에서 정의한 SSOT 접근법을 즉시 위반).예를 들어, ERP(기업 리소스 계획) 시스템(예: SAP 또는 Oracle e-Business Suite)은 고객 레코드를 저장할 수 있으며, CRM(고객 관계 관리) 시스템도 고객 레코드 복사본(또는 일부)이 필요하며, 창고 발송 시스템도 고객 데이터의 일부 또는 전체 복사본(예: 배송 추가)이 필요할 수 있다.ss). 벤더가 그러한 수정을 지원하지 않는 경우, 이러한 레코드를 SSOT에 대한 포인터로 대체하는 것이 항상 가능한 것은 아니다.

(하나 이상의 정보 시스템을 가진) 단일 진리의 출처를 구현하고자 하는 조직(모든 실체를 위해 다른 시스템에 포인터를 저장하도록 하나의 마스터 시스템을 제외한 모든 것을 수정하지 않음)의 경우, 4개의 지원 아키텍처가 일반적으로 사용된다.^{[citation needed]}

• 엔터프라이즈 서비스 버스(ESB)
• 마스터 데이터 관리(MDM)
• 데이터 웨어하우스(DW)
• SOA(^[2]서비스 지향 아키텍처)
• 이벤트 스토어 및 이벤트 소싱(ES)

엔터프라이즈 서비스 버스(ESB)

기업용 서비스 버스(ESB)는 조직의 모든 시스템이 다른 시스템에서 변경된 데이터의 업데이트를 받을 수 있도록 허용한다.단일 진리의 출처를 구현하려면, 어떤 실체에 대해서도 올바른 데이터의 단일 소스 시스템을 식별해야 한다.이 엔터티에 대한 변경사항(작성자, 업데이트 및 삭제)은 ESB를 통해 발표된다. 즉, 해당 데이터의 복사본을 보관해야 하는 다른 시스템은 이 업데이트에 가입하고 그에 따라 자체 기록을 갱신한다.주어진 실체에 대해서는 마스터 소스를 식별해야 한다(때로는 골든 레코드라고도 함).주어진 시스템은 특정 실체(예: 고객)에 대한 정보를 게시(진실의 원천이 됨)할 수 있으며, 다른 실체(예: 제품)에 대한 정보를 얻기 위해 다른 시스템의 업데이트를 구독할 수도 있다.^{[citation needed]}

대안적인 접근방식은 포인트 투 포인트 데이터 업데이트이지만, 이러한 접근방식은 시스템 수가 증가함에 따라 유지 비용이 기하급수적으로 증가하며, 이러한 접근방식은 IT 아키텍처로서 점점 더 선호되지 않는다.^{[citation needed]}

마스터 데이터 관리(MDM)

MDM 시스템은 다른 시스템에서 반드시 대안적인 "진실의 출처"를 가지지 않을 수 있는 주어진 실체에 대해 진실의 출처 역할을 할 수 있다.일반적으로 MDM은 복수의 시스템에 대한 허브 역할을 하며, 이들 중 다수는 특정 기업에 대한 정보의 다른 측면에 대한 업데이트를 허용할 수 있다(진실의 출처가 될 수 있다).예를 들어, CRM 시스템은 고객의 대부분의 측면에서 "진실의 원천"이 될 수 있으며, 콜센터 운영자에 의해 갱신된다.그러나 고객은 CRM 시스템에서 다른 백엔드 데이터베이스로 고객 서비스 웹 사이트를 통해 주소를 업데이트할 수도 있다(예를 들어).MDM 애플리케이션은 여러 출처로부터 업데이트를 수신하고, 어떤 업데이트가 권위 있는 것으로 간주될지를 결정하는 브로커 역할을 하며(골든 레코드) 이 업데이트된 데이터를 모든 가입 시스템에 통합한다.MDM 애플리케이션은 일반적으로 ESB가 데이터를 여러 가입 시스템에 결합하도록 요구한다.^[3]

데이터 웨어하우스(DW)

데이터 웨어하우스의 주요 목적은 여러 출처에서 결합한 데이터의 보고와 분석을 지원하는 것이지만, 그러한 데이터가 결합되었다는 것은 (데이터 변환 및 통합 프로세스에 내재된 비즈니스 논리에 따라) 데이터 웨어하우스가 사실상의 SSOT로 자주 이용된다는 것을 의미한다.그러나 일반적으로 데이터 웨어하우스에서 이용할 수 있는 데이터는 다른 시스템을 업데이트하는 데 사용되지 않고, 오히려 DW는 복수의 이해관계자에게 보고하는 "단일 진실의 원천"이 된다.이러한 맥락에서 데이터 웨어하우스는 다른 버전의 진리가 운영 데이터 소스에 존재하기 때문에 "진실의 단일 버전"이라고 더 정확하게 언급된다(DW에서 데이터가 생성되지 않으며 단순히 운영 시스템에서 로드된 데이터에 대한 보고 메커니즘일 뿐).^{[citation needed]}

이벤트 스토어 및 이벤트 소싱(ES)

이벤트 지향 아키텍처에서, 시스템 상태를 순서가 정해진 상태 변화 순서에 따라 저장하는 것으로 구성되는 이벤트 소싱 패턴의 구현을 찾는 것이 점점 더 일반화되었다.^[4]이렇게 하려면 시스템 상태를 변경하는 모든 이벤트를 보관하도록 설계된 특정 유형의 데이터베이스인 이벤트 저장소가 필요하다.이벤트 소싱 + 명령 쿼리 책임 분리 + 도메인 기반 설계 + 메시징 아키텍처의 이벤트 스토어는 사실상 "단일 진실의 원천"으로, 이벤트 스토어를 넣을 수 있어 엔터프라이즈 서비스 버스 역할도 할 수 있다는 추가적인 이점이 있으며, 모든 사람이 지나갈수록 이벤트 스토어에 직접 귀를 기울여 상태 변화를 도모한다.또한 모든 이벤트를 저장함으로써 데이터 웨어하우스 역할도 한다.마지막 이점으로서, 이 시스템을 통해 공유 데이터베이스 패턴을 구현할 수 있으며, 단일 진실의 출처를 얻기 위해 언급되지 않은 또 다른 기법이 있다.

솔리드 및 소스 코드

소프트웨어 설계에서, 동일한 스키마, 비즈니스 논리 및 기타 요소들이 복수의 다른 맥락에서 반복되는 경우가 많은 반면, 각 버전은 그 자체를 "소스 코드"라고 부른다.이 문제를 해결하기 위해 SSOT의 개념은 또한 반복적으로 반복적으로 반복적으로 하나의 진실의 원천을 여러 종류의 소스 코드로 변환하는 프로세스를 사용하는 소프트웨어 개발 원칙에도 적용될 수 있는데, 이는 모두 동일한 SSOT에서 파생되었기 때문에 구조적으로 서로 일치하게 될 것이다.^[5]

DSD(분산 SaaS 데이터)

복수의 진실의 출처가 있는 B2B 소프트웨어 데이터 생태계처럼 데이터를 중앙에서 저장하고 참조 위치에 관리하는 것이 비현실적인 경우, 기업은 DSD 시스템을 사용한다.이 시스템은 항공 교통 관제사 역할을 하여 중앙 데이터 관리 및 제어의 베니어(benery)를 제공함으로써, 그것이 저장된 위치의 데이터 정확도를 강화한다.

데이터 액세스 및 현장 생산성

에너지 분야에서는 하나의 진실 실행 모델 채택이 증가하고 있는데, 여기서 Industry 4.0이 가져온 기술 발전으로 사업자들이 현장 생산성을 향상시킬 수 있게 되었다.산업용 자산에 대한 접근 가능한 SSOT를 통해 소유주는 검증 가능한 현장 데이터, 엔지니어링 도면 및 재고와 중앙집중식 운영 전문가와의 커뮤니케이션을 온디맨드 방식으로 가능하게 하는 무선 이동성을 제공하여 근로자 효율성을 극대화할 수 있다.^[6]

참고 항목

• 반복하지 마십시오(DRY)
• SOLID(객체 지향 설계)
• 데이터베이스 정규화
• 진리의 단일 버전
• 기록 체계
• 유닉스 철학
• 간단해, 멍청아 (KISS)
• 순환 보고
• 블록체인

참조