KR20220122619A - 데이터세트 네트워크를 생성하기 위한 시스템 - Google Patents

Abstract

본 발명은 데이터 노드들의 공유 네트워크를 생성하기 위한 플랫폼을 제공한다. 각각의 데이터 노드는 자기 기술(self-describing), 자기 연결 및 자기 보안이다. 본 발명에 개시된 데이터 네트워크는 데이터 사일로 환경을 방지할 수 있다. 각 노드는, 버전 콘트롤되는 데이터가 포함된 데이터세트; 상기 데이터세트에 대한 사용자 액세스를 제한하는 액세스 콘트롤 레이어; 상기 데이터세트의 특성을 규정하고 다른 노드에 연결하는 메타데이터 레이어를 갖는다. 데이터세트의 변경이 데이터 노드들의 네트워크 변경에 영향을 미치도록 데이터 노드들의 네트워크를 생성하기 위해 노드를 후속 노드와 연관시키기 위해 하나 이상의 링크가 생성되며; 상기 데이터 노드들의 네트워크는 데이터세트 및 후속 데이터세트와 상호 작용하는 쿼리 레이어를 포함한다.

Description

데이터세트 네트워크를 생성하기 위한 시스템

본 발명은 데이터 패브릭과 같은 데이터세트의 네트워크, 이와 같은 네트워크를 제공하기 위한 플랫폼, 및 상기 네트워크, 데이터세트 및 시스템을 구축하고 사용하는 방법에 관한 것이다.

관련 기술의 설명

전통적으로 기업은 데이터 사일로 환경에서 운영되어 왔다. 데이터 사일로는 예를 들어 하나의 애플리케이션을 통해 액세스할 수 있지만 해당 조직의 나머지 부분과 격리된 데이터세트들의 그룹이다.

데이터 사일로(data silos)는 일반적으로 분석 도구에 의해 수집된 데이터 또는 비즈니스 애플리케이션에 의해 생성된 데이터의 결과이다. 데이터 사일로 환경에는 많은 문제점들이 존재한다.

예를 들어, 데이터 사일로는 조직 내에서 대량의 시간 낭비를 초래할 수 있다. 애플리케이션들 간에 데이터를 자동으로 간소화할 수 있는 것이 아니라, 데이터가 각 애플리케이션 내에서 격리된다.

즉, 팀은 이들이 갖고 있지 않은 데이터가 필요하다는 것을 깨달을 때까지 기다렸다가 조직 내 데이터가 있는 위치를 찾고 수동으로 액세스 권한을 얻은 다음 그들의 자체 목적에 맞게 분석해야 한다. 이들이 데이터를 수집할 때쯤에는 더 이상 유효하지 않을 수도 있다.

데이터 사일로로 인해 저장 공간이 낭비될 수도 있다. 예를 들어, 조직의 각 직원이 데이터의 카피들을 필요로 하고, 이를 회사 저장소 폴더에 저장하면, 많은 양의 저장소 공간이 낭비되며, 이는 비용이 많이 들 수 있다.

데이터 사일로 환경의 또 다른 단점은 데이터의 정확성을 유지할 수 없다는 것이다.

격리된 데이터가 남아 있으면, 오래되어 부정확하고 사용할 수 없게 될 가능성이 높아진다.

데이터 사일로는 또한 보안 취약성을 야기할 수 있다. 예를 들어 데이터가 복사되면, 데이터세트 소유자는 다른 팀의 규정 준수에 의존하는 어렵고 비용이 많이 드는 프로세스 없이는 더 이상 기밀성을 보장할 수 없다.

데이터세트의 복사본이 각 팀원의 컴퓨터에 저장되어 있을 경우에는, 해킹될 가능성이 더 높아진다.

데이터 사일로는 또한, 데이터 사일로 환경에서 각 팀이 그들 자체의 데이터에만 액세스할 수 있기 때문에, 그들이 함께 작업하는 데이터만 액세스할 수 있어 조직 내에서 마찰을 일으킬 수 있다. 예를 들어, 각 팀은, 공동 작업과 달리 독립적으로 작업하여 분할된 조직을 만들 수 있다.

도 1 및 도 2는, 새로운 데이터 사일로(24)의 생성 및 데이터(26)의 복제를 수반하는 각각의 새로운 커스텀(맞춤형) 애플리케이션의 전통적인 생성을 도시한다.

도 1에 도시된 바와 같이, 전통적으로 개발된 애플리케이션(10)은 각각 그 자신의 사용자 인터페이스(14), API(15)(도 1에는 도시되지 않음), 보안 및 콘트롤장치(16), 데이터 통합부(18), 데이터 퍼시스턴스(20), 및 데이터 공개(22) 기능들을 포함하도록 프로그래밍될 수 있다.

더욱이, 각 애플리케이션(10)은, 데이터베이스(24)에 링크되거나 또는 관련 데이터(26)가 생성, 불러오기, 업데이트, 유지 관리 등으로 되는 그 자신의 데이터베이스(Database)(24)를 필요로 한다.

기업으로부터의 레거시 데이터(Legacy Data)(28) 역시 각 애플리케이션(10)으로 개별적으로 불러올 필요가 있다. 사용자(12)는 별도의 보안 및 콘트롤장치(16)를 사용하여 각 애플리케이션(10)에 대한 액세스 권한이 부여된다.

그 다음, 데이터는 예를 들어 분석 및 기타 데이터 처리 작업을 수행하기 위해 보다 큰 엔터프라이즈 데이터 레이크(Enterprise Data Lake)(30)에 게시될 수 있다.

이들 애플리케이션(10)은 또한 새로운 솔루션을 효과적으로 배포하는 데 필요한 수백 또는 수천 개의 이와 같은 도구(tool)들의 예를 필요로 하는 데스크탑 툴에 크게 의존할 수 있다.

또한, 기존 데이터 사일로에는 충분한 데이터 콘트롤부가 부족한 경우가 많으며, 한 애플리케이션 또는 데이터 사일로에 구현된 콘트롤들을 다른 애플리케이션에서 재사용할 수 없는 경우가 많다.

상기와 같은 비효율성과 중복성으로 인해, 새로운 애플리케이션(10) 및 솔루션을 생성함에 있어서, 배포하는 데 몇 주가 걸리고 몇 달이 걸리는 일이 흔하다. 이들 솔루션이 빠르게 필요한 환경에서는, 배포 시간이 경쟁적 단점으로 간주되거나 최소한 자원 낭비로 간주될 수 있다.

본 발명의 하나의 양태는 데이터 노드들의 공유 네트워크를 생성하기 위한 시스템에 관한 것이다.

상기 시스템은, 적어도 두 개의 노드들로서, 각각의 노드는 버전 콘트롤 데이터를 포함하는 데이터세트를 갖고; 상기 데이터세트에 대한 사용자 액세스를 제한하는 액세스 콘트롤 레이어; 상기 데이터세트의 특성을 규정하고 다른 노드에 연결하는 메타데이터 레이어를 포함한다.

데이터세트의 변경이 데이터 노드들의 네트워크 변경에 영향을 미치도록 데이터 노드들의 네트워크를 생성하기 위해 노드를 후속 노드와 연관시키기 위해 하나 이상의 링크가 생성되고; 데이터 노드들의 네트워크는 데이터세트 및 후속 데이터세트와 상호 작용하도록 하는 쿼리 레이어를 포함한다. 각 데이터 노드는 자기 기술, 자체 연결 및 자체 보안된다.

이하에, 첨부된 도면들을 참조하여 본 발명의 실시예들을 설명한다.
도 1은 데이터 사일로 환경에서 종래 기술의 애플리케이션 개발을 도시하는 개략도이다.
도 2는 데이터 사일로 환경에서 종래 기술의 애플리케이션 개발을 도시한 개략도이다.
도 3은 4개의 앱 익스피리언스들과 함께 도시된 데이터 노드들의 네트워크의 개략도이다.
도 4는 5개의 앱 익스피리언스들과 함께 도시된 데이터 노드들의 네트워크의 개략도이다.
도 5는 노드의 개략도이다.
도 6은 노드 네트워크의 개략도이다.
도 7a는 데이터세트 노드들을 구축하고, 데이터세트 노드들의 네트워크를 구축하고, 이와 같은 네트워크들과 상호작용하기 위한 플랫폼의 개략도이다.
도 7b는 데이터세트 노드들의 네트워크의 네트워크를 구축하고 이와 같은 네트워크와 상호작용하기 위한 플랫폼의 개략도이다.
도 8a는 노드 및 그 데이터의 스크린샷의 일례이다.
도 8b는 해당 노드에 대한 메타데이터의 규정를 포함하여 데이터세트를 설계하는 일례를 도시하는 스크린샷의 일례이다.
도 8c는 현재 데이터세트와 다른 데이터세트 사이의 링크를 규정하기 위한 스크린샷의 일례이다.
도 8d는 데이터의 버전을 표시하는 협업 로그의 스크린샷의 일례이다.
도 8e는 개별 노드에 대한 콘트롤를 구성하기 위해 사용될 수 있는 콘트롤 페이지의 스크린샷의 일례이다.
도 9는 스크립팅 언어 질의의 실행을 예시하는 개략적인 흐름도이다.
도 10은 예시적인 데이터 네트워크와 상호작용할 때 상이한 사용자 관점들을 예시하는 개략도이다.
도 11은 버전 데이터의 스크린샷의 일례이다.
도 12는 독립적인 액세스 콘트롤 허가를 보여주는 데이터세트의 일례이다.
도 13a는 첫 번째의 데이터세트 네트워크의 일례이다.
도 13b는 두 번째의 데이터세트 네트워크의 일례이다.
도 13c는 세 번째의 데이터세트 네트워크의 일례이다.
도 14는 데이터 사일로 환경에서 전통적인 애플리케이션 개발을 예시하는 개략도이다.
도 15는 전통적인 애플리케이션 대 데이터세트 네트워크 익스피리언스의 개략도를 도시한다.
도 16a는 사일로 데이터베이스를 사용하는 전통적인 애플리케이션 개발을 위한 보안 및 콘트롤를 나타내는 개략도이다.
도 16b는 데이터 네트워크를 활용하는 애플리케이션 개발에 대해 도시하는 개략도이다.

본 발명은 다음과 같이 데이터 노드들의 공유 네트워크를 생성하기 위한 플랫폼을 제공한다.

각각의 데이터 노드는 자기 기술(self-describing), 자체 연결(self-connecting) 및 자체 보안(self-securing)이다.

본 명세서에서 설명하는 데이터 네트워크는 대규모(예를 들어: 대기업 수준) 데이터 관리 솔루션을 구축하는 데 필요한 시간과 노력을 줄일 수 있다.

몇 가지 장점들은 다음을 포함한다:

데이터 사일로 환경의 방지;

적응 가능한 애플리케이션 프로그래밍 인터페이스(API) 통합 레이어를 통한 유연한 기업 정렬;

최소한의 노력으로 애플리케이션 전반에 걸친 데이터의 재사용에 기초한 단순화된 데이터 통합으로, 전통적인 의미에서 "애플리케이션들"을 개발할 필요성을 효과적으로 감소시키거나 또는 제거한다.

각각의 노드는, 버전 콘트롤 데이터를 포함하는 데이터세트; 상기 데이터세트에 대한 사용자 액세스를 제한하는 액세스 콘트롤 레이어; 상기 데이터세트의 특성을 규정하고 다른 노드에 연결하는 메타데이터 레이어를 갖는다.

상기 데이터세트의 변경이 데이터 노드들의 네트워크 변경에 영향을 미치도록 데이터 노드들의 네트워크를 생성하기 위해 노드를 후속 노드와 연관시키기 위해 하나 이상의 링크가 생성되며; 상기 데이터 노드들의 네트워크는 데이터세트 및 후속 데이터세트와 상호 작용하는 쿼리 레이어(query layer)를 포함한다.

이하에 기술되는 바와 같이, 본 시스템은, 데이터 협업 네트워크 및 해당 네트워크의 개별 데이터 노드가 데이터에 대한 액세스 권한이 있는 엔티티가 활용하도록 허용함으로써 애플리케이션의 필요성을 제거하도록 전통적인 의미에서 애플리케이션 개발의 필요성을 효과적으로 제거한다.

기존 애플리케이션 개발 및 데이터 사일로 생성과 관련된 상당한 노력을 들이지 않고도 동일한 데이터를 사용할 수 있다.

따라서 시스템은 UI에서 데이터를 분리하고 각 솔루션이나 애플리케이션에 대해 하나씩 코드를 작성하지 않고도 데이터 주변에 보안 및 콘트롤 레이어를 구성할 수 있도록 하여 솔루션을 더 빠르게 전달할 수 있다.

또한, 별도 조직 내의 데이터 협업 네트워크를 서로 연결하여 네트워크 네트워크를 생성할 수 있으므로, 격리된 데이터 사일로가 아닌 연결된 데이터의 슈퍼 네트워크를 생성할 수 있다.

도 2는 새로운 데이터베이스(24)의 생성 및 데이터(26)의 복제를 수반하는 각각의 새로운 맞춤형 애플리케이션의 전통적인 생성을 나타낸다.

전통적으로 개발된 애플리케이션(10)의 각각은, 생성되고, 불러오고, 업데이트되고, 유지 관리 등과 같이 되는 데이터베이스(24)에 링크되거나 또는 관련된 데이터(26)를 갖는 그 자체의 데이터베이스(24)를 필요로 할 수 있다.

각각의 데이터베이스(24)는 애플리케이션(10)에 의해 액세스될 데이터(26)의 사본을 저장한다. 전통적인 애플리케이션들에는 데이터세트들이 내장되어 있다.

전통적으로, 데이터는 개별 애플리케이션(10) 뒤의 데이터 사일로(24)에 데이터 사본들로 저장된다. 이는 데이터 사일로와 같은 환경을 유발할 수 있으며, 이는 문제점으로 될 수 있다.

도 3은 데이터 노드들의 네트워크의 개략도를 도시한다.

데이터 네트워크(34)는 데이터 노드(34)의 네트워크를 형성하기 위해 개별 노드(36)들을 연결함으로써 생성된다.

원시 데이터 또는 데이터(35)의 레코드는 데이터 노드(34)의 네트워크에 연결되는 쿼리 인터페이스(33)를 통해 액세스할 수 있다.

도 3은 동일한 데이터 네트워크로부터의 데이터를 모두 사용하는 4개의 상이한 애플리케이션 익스피리언스(32a, 32b, 32c, 32d)을 도시한다.

이와 같이 하면, 별도의 데이터베이스를 생성하고, 가져오고, 업데이트하고 유지 관리할 필요가 없어질 뿐만 아니라, 각 애플리케이션의 보안 및 콘트롤(security & controls)(16), 데이터 통합(data integration)(18), 데이터 퍼시스턴스(data persistence)(20) 및 데이터 공개(data publishing)(22) 시스템을 관리할 필요가 없어진다.

이와 같이, 새로운 애플리케이션 익스피리언스(application experince)(32)를 추가하는 것은 비교적 용이하다.

도 4는, 도 3에 도시된 기존 아키텍처에 추가되는 새로운 애플리케이션 익스피리언스(32e)을 도시한다.

새로운 애플리케이션 익스피리언스(32e)의 추가는, 추가적인 보안 및 콘트롤(16), 데이터 통합(18), 데이터 퍼시스턴스(20), 및 데이터 공개(22) 능력들을 필요로 하지 않는다. 상기 애플리케이션 익스피리언스(32)은 데이터와 상호작용하기 위한 맞춤형 사용자 인터페이스로서 작용한다.

따라서, 임의의 수의 노드(36)들은 물론, 애플리케이션 익스피리언스(32)들이 네트워크(34)에 추가될 수 있음을 알 수 있다. 새로운 애플리케이션 익스피리언스(32)가 추가됨에 따라, 데이터세트(34)들의 네트워크가 성장하고, 새로운 데이터세트들(26) 사이에 새로운 링크들이 형성된다.

데이터세트 노드들, 데이터 노드들의 네트워크 및 플랫폼 구현

도 5 및 도 6을 참조하면, 본 명세서에 기술된 플랫폼은 데이터 노드들(34)의 네트워크로서 데이터(35)를 관리하도록 구성된다.

도 5는 데이터세트 노드(36)의 일례를 도시하고, 도 6은 노드들(36)의 네트워크(34)의 일례를 도시한다.

각각의 데이터세트(26)는 데이터(35)를 포함한다.

상기 데이터세트는 버전 콘트롤(38)되고, 제1 버전(35a), 제2 버전(35b), 및 제3 버전(35c)과 같은 데이터 버전들을 포함한다. 이로부터 임의 수의 여러 버전들이 가능하다는 것을 알 수 있다.

액세스 콘트롤 레이어(39)는 데이터세트(26) 위에 구축된다. 메타데이터 레이어(37)는 상기 액세스 콘트롤 레이어(39) 위에 구축된다.

도 5에 도시된 단일 노드(36)에 의해 알 수 있는 바와 같이, 노드의 코어에는 데이터(35)의 레코드들이 있다. 상기 데이터(35)의 레코드는 먼저 메타데이터 레이어(37) 및 액세스 콘트롤 레이어(39)를 통하지 않고는 액세스될 수 없다.

노드(36)는, 노드(37)를 자기 기술(self-describing) 및 자기 연결(self-connecting) 하도록 하는 메타데이터 레이어를 포함한다.

따라서, 각각의 데이터세트(26)는, 현재 노드에 있어서의 임의의 레코드들을 다른 노드들에 있어서의 하나 이상의 레코드와 관련시키는 데이터와 함께, 속성과 같은 데이터세트에 대한 정보 및 다른 노드들(즉, 링크들)과의 그의 관계에 관한 정보를 포함하는 그 자체의 메타데이터 레이어(37)을 포함한다.

상기 노드(36)는 데이터의 무결성을 보장하고, 또한 데이터 버전 관리(38) 및 변경 승인과 같은 거버넌스 콘트롤를 제공하기 위해 내장 콘트롤 레이어(39)을 가짐으로써 자체 콘트롤할 수 있다.

데이터 버전 관리(38)가 도 11에 도시되어 있으며, 이하에 보다 자세히 설명된다.

상기 노드(36)는 자격을 관리하기 위한 내장 보안 레이어를 갖는 자체 보안일 수 있다. 노드는 플랫폼의 메타데이터 기반 사용자 인터페이스(user interface) 또는 API를 통해 액세스할 수도 있다.

일반적으로, 개별 애플리케이션(10)에 존재하는 데이터에 대한 보안 및 콘트롤(security & controls)(16)는 도 1에 도시된 종래 기술의 예와 같다.

이는 보안 및 콘트롤이 개별 애플리케이션에 연결되어 있으며, 이에 따라 데이터가 복사될 때 데이터를 따르지 않을 수 있기 때문에 위험할 수 있다. 따라서, 데이터를 복사할 때 취약하거나 안전하지 않을 수 있다.

본 발명에 의해 도시된 시스템에 있어서, 보안 및 콘트롤는 각 데이터세트(26)에 내장되어 있다. 이는 데이터가 어떻게 사용되는지에 관계없이 보편적인 시행을 보장하기 때문에 이것이 훨씬 더 효율적이고 안전하다는 것을 알 수 있다.

도 1에서, 데이터 통합 수행의 일부로서 데이터가 애플리케이션들 간에 복사되는 경우, 보안 및 콘트롤는 데이터를 따르지 않으며, 각 애플리케이션에서 다시 구현되어야 한다.

이는 액세스 콘트롤 레이어(39)가 데이터세트(26) 위에 레이어로서 구축되기 때문에 회피된다.

이제 도 6을 참조하면, 제1 노드(36a)가 제2 노드(36b) 및 제3 노드(36c)에 연결될 수 있음을 알 수 있다. 이는 데이터노드들(34)의 네트워크를 형성한다.

노드들(36)은 노드들(36) 사이의 관계인 링크들(40)을 통해 연결된다. 링크들(37)은 노드의 메타데이타 레이어(37) 내에 규정되고, 이는 데이터노드들(34)의 네트워크에 대한 근간을 형성한다.

링크들(40)은 데이터노드들(34) 내에 데에터 레코드(35)들에 관련되고, 개별 링크(40)는 제1 노드(36a)의 데이터 레코드를 다른 노드들(36b, 36c)의 하나 이상의 데이터 레코드들과 관련시키는 능력을 갖는다.

각각의 노드(36)는 자기 기술, 자체 연결 및 자체 보안이기 때문에, 네트워크(34)의 데이터세트(26)는 애플리케이션의 경계에 의해 제한되지 않는다.

상기 데이터는 도 4에 도시된 종래 기술 예시에서와 같이 더 이상 사일로가 아니다. 이것은 도 1에 도시된 애플리케이션 관리 데이터베이스에 대한 필요성을 제거하여, 데이터세트를 사용하기 위한 더욱 간단하고 더욱 효과적인 방법을 유발한다.

임의의 개인에 대해, 그들의 네트워크는, 이들이 그들과 상호작용하기 위한 데이터세트들에 의해 액세스할 수 있는 데이터세트들에 의해 형상화된다. 노드들을 연결하는 링크들이라도 개인이 링크의 대상에 액세스할 수 있는 경우에만 노출/접근이 가능한다.

도 10에 도시된 바와 같이, 임의의 사용자는 전체 네트워크의 작은 슬라이스에만 액세스할 수 있는 것이 가능하다.

데이터 노드들을 다른 데이터 노드들에 연결될 수 있도록 하면서, 또한 자기 기술, 자체 연결 및 자체 보안을 유지함으로써, 본 발명은 데이터 네트워크 내에서 상호 작용할 때 도 1에 도시된 데이터 공개 및 데이터 통합 구성 요소들을 필요로 할 필요성을 제거한다.

데이터의 복사는 분배되지 않는다. 대신, 액세스 권한이 부여되고 다른 소유자가 관리할 수 있는 데이터를 사용할 수 있도록 링크들이 설정된다.

데이터노드(34)의 네트워크를 생성하고, 수정하고 그와 상호작용하도록 구성되는 플랫폼이 도 7A에 도시되어 있다.

본 시스템은 API(41) 또는 애플리케이션 인터페이스(32)가 그를 통해 데이터를 조회할 수 있는 쿼리 인터페이스(33)를 갖는다. 사용자(12)는, 사용자 인터페이스(42) 또는 애플리케이션 인터페이스(32)와 상호작용하여 노드들의 구성은 물론 노드들의 데이터 모두를 관리하도록 한다.

API(41) 및 UI(42)는 플랫폼 그 자체에서 동적으로 제공될 수 있다.

상기 쿼리 인터페이스(33)는 네트워크 내의 모든 데이터세트(26)들을 포함하는 네트워크(34)와 상호작용하기 위한 쿼리 엔진을 제공한다. 이것은 단일 노드(36)의 범위를 넘어선, 즉, 각 노드(36)에 대해 사용 가능한 API를 사용하여 가능한 것 이상의 상호작용을 가능하게 한다.

쿼리들은 SQL상에 구축되는 일례인 플랫폼 스크립팅 언어로 작성될 수 있으며, 또한 네트워크에서 사용 가능한 링크들의 이점을 취하도록 설계되어, 사용자는 쿼리를 실행할 때 노드들 간의 관계를 탐색할 수 있게 된다.

도 9는 노드를 쿼리할 때 관계를 순회하기 위해 스크립팅 언어의 점 표기법을 활용하는 쿼리의 일례를 제공한다.

플랫폼의 스크립팅 언어를 사용하면 사용자가 데이터를 읽고/생성하고/수정하고/삭제하는 것은 물론 네트워크의 노드들을 관리할 수 있다. 플랫폼의 스크립팅 언어로 작성된 쿼리는 ACID 트랜잭션을 지원할 수 있다.

일 실시예에서, 레거시 데이터(28)는 네트워크(34)로 불러올 수 있다. 커넥터들은 레거시 데이터(28)와 데이터 네트워크(34) 사이의 갭을 연결하기 위해 사용될 수 있다.

커넥터들은 플랫폼의 외부로부터 자기 기술, 자체 연결 및 자체 보안 데이터세트로의 동기화를 가능하게 할 수 있음은 물론, 도 1에 도시된 레거시 애플리케이션 또는 엔터프라이즈 데이터 레이크로 데이터를 푸시하기 위한 역 흐름을 가능하게 할 수 있다.

도 7b는 다수의 네트워크들(34)이 서로 연결된 실시예를 도시한다.

예를 들어, 개별 조직 내의 네트워크들(34)은 격리된 데이터 사일로가 아니라, 연결된 데이터의 네트워크 네트워크를 생성하기 위해 서로 연결될 수 있다. 데이터 네트워크들의 네트워크를 슈퍼 네트워크라고 지칭한다.

이제 도 8a 내지 도 8e를 참조하면, 도 7에 도시된 사용자 체험 구성 요소들을 예시하기 위한 예시적인 스크린 샷이 제공된다.

사용자 익스피리언스(42)은 노드들을 생성하고 관리하기 위해 웹 양식을 사용할 수 있다.

도 8에는, 노드의 일례에 대한 화면의 샘플이 도시되어 있다.

도 8a는 노드에서 데이터를 관리하기 위한 UI이다. 프라이머리 클라이언트 (Primary Client) 컬럼이 링크인 것에 주목할 수 있으며, 도 8c는 규정 (definition)을 나타낸다.

이 체험을 통해 사용자는 링크된 데이터세트의 관련 레코드에 대한 링크를 클릭하여 트래버스할 수 있다.

도 8b에는, 맨 오른쪽 스크린샷의 메타데이터 규정를 포함하여 데이터세트를 설계하기 위한 예시적인 화면이 도시되어 있다.

도 8c는 현재 데이터세트와 다른 데이터세트 사이의 링크를 규정하기 위한 샘플 화면을 제공한다.

도 8d에 도시된 바와 같이. 노드의 모든 데이터 변경 사항은 자동으로 버전 콘트롤된다. 도 8d는 데이터의 버전을 표시하는 협업 로그(Collboration Log)의 샘플 화면이다.

도 8e는 개별 노드상에 구성될 수 있는 콘트롤(Control)의 샘플 스크린샷을 제공한다.

따라서, 플랫폼은 사용자가 데이터 네트워크와 상호작용할 수 있도록 네이티브 메타데이터 기반 사용자 인터페이스를 제공한다. 이것은 맞춤형 애플리케이션 익스피리언스을 생성할 수 있는 능력과 결합되어 도 1에 예시된 의미에서 애플리케이션에 대한 필요성을 대체한다.

위에서 나타낸 바와 같이, 도 9는 데이터 네트워크(34)를 횡단하고 데이터를 검색하기 위해 노드들 사이에 존재하는 링크들의 이점을 취하는 플랫폼 스크립팅 언어 쿼리의 샘플을 제공한다.

구체적으로 설명하면, 플랫폼에서 제공되는 쿼리 인터페이스(33)를 사용함으로써 쿼리 결과를 얻기 위해 점 표기법이 사용될 수 있다.

데이터 버전 관리

플랫폼의 데이터 버전 관리(38)는 데이터에 대해 수행될 수 있다.

도 11은 단일 레코드의 데이터 버전 관리를 나타낸다. 제1 버전은 초기 생성을 나타낼 수 있다. 이어서, 데이터세트가 변경되거나 달라질 때마다 새로운 버전이 생성될 수 있다.

예를 들어, 버전(Version) 18은 2020년 11월 13일 이름이 단 데머스(Dan Demers)라는 사용자에 의해 수행된 변경을 승인했다. 각각의 버전은 변경의 타임스탬프와 함께 변경이 행해지는 사용자의 세부 정보를 캡처한다.

예를 들어, 하나의 버전에 있어서, 사용자는 데이터의 레코드를 삭제할 수 있으며, 이는 그것이 삭제이기 때문에 회색으로 표시된다.

다른 예에 있어서, 사용자는 휴지통으로부터 데이터 레코드를 복원할 수 있으며 이는 사용자에 의해 수행된 복원으로서 표시된다.

다른 예에서, 데이터세트의 제1 버전을 복원하기 위해, 사용자에 의해 되돌리기 작업이 수행될 수 있다. 이와 같이 하면 새 버전이 생성되고, 버전 히스토리에는 영향을 미치지 않는다.

데이터 레벨 액세스 콘트롤

도 10은 2명의 상이한 사용자들(User 12a 및 User 12b)이 데이터 노드들의 동일한 네트워크를 보는 방법의 예시를 제공한다.

여기에는 쿼리 인터페이스(33)를 통해 데이터 네트워크(34)와 상호작용하는 두 명의 다른 사용자들(12a, 12b)이 있다. 블랙 링크들(40) 및 노드들(36)은 사용자가 그에 액세스할 수 있는 데이터세트들(26)을 나타낸다.

어느 쪽이든, 회색 노드들과 점선 링크들은 사용할 수 없으며, 이는 마치 전혀 존재하지 않는 것과 같다.

이것은 각각의 사용자가 데이터 네트워크(34)를 볼 때 그들 자신의 관점을 갖고 있으며, 이는 각각에 대해 매우 다르게 보일 수 있음을 의미한다.

부분적으로 채워진 노드들은, 구성된 규칙에 따라, 사용자가 노드(36) 내의 데이터의 서브세트에만 액세스할 수 있다는 사실을 나타낸다.

노드(36)에 내장된 액세스 콘트롤 레이어(39)는 매우 세분화될 수 있고 사용자(12)가 특정 조건들 하에서 데이터를 보고/편집하고/승인할 수 있도록 하는 규칙을 규정할 수 있다.

도 12는 이하에서 기술되는 데이터 기반 액세스 자격의 일례를 제공한다.

이제 도 12을 참조하면, 데이터세트는 매우 세분화된 액세스 콘트롤이 지원할 수 있다.

도 12는 사용자가 편집할 수 있는 것을 규정하는 두 개의 독립적인 승인을 보여주는 일례이다.

이와 같은 권한 부여 중 하나에는, 현재 노드의 데이터를 기반으로 하는 조들이 있다. 이와 같은 조건들은, 사용자에게 액세스 권한이 있는지 여부를 결정하기 위해 관련된 데이터세트들을 트래버스하도록 하는 링크들을 활용하여 노드들에도 적용될 수 있다. 사용자가 보거나 승인할 수 있는 항목에 대해 유사한 세부 콘트롤들을 사용할 수 있다. 이 예에서 회색으로 표시된 셀은 사용자에 의해 편집될 수 없다.

노드들의 네트워크들은 플랫폼을 이용하고 플랫폼과 그와 상호작용하도록 구성되는 임의의 애플리케이션을 통해 링크될 수 있다.

상기 네트워크는, 데이터들 사이의 관계의 상호 작용이며 기본 퍼시스턴스으로 데이터를 저장하는 데 사용되는 정확한 장치 또는 그의 위치에 반드시 영향을 미치지는 않는다.

이와 같은 방식으로, 하나 이상의 새로운 데이터베이스들을 채택할 필요 없이, 이와 같은 기술을 기반으로 플랫폼을 실행하면서 기업 내의 기존 기술들 사용할 수 있다.

네트워크(34)는 일련의 데이터 노드(36)로부터 구축될 수 있다. 데이터세트(26)는 다른 데이터세트에 링크될 수 있고 쿼리는 본 명세서에 설명된 바와 같이 스크립팅 언어를 적용함으로써 구축될 수 있다.

이를 통해 개발자와 같은 사용자들은 기존 데이터세트를 사용하고 새로운 데이터세트를 생성하여 애플리케이션 익스피리언스을 구축할 수 있기 때문에, 그에 따라 노드들의 기존 네트워크를 활용하고 향후 애플리케이션 개발을 위해 해당 네트워크를 기반으로 구축할 수 있다.

새로 생성된 노드는 사용자에 의해 추가 및 조작된 데이터를 가질 수 있고, 및/또는 예를 들어 레거시 데이터와 같은 기존의 데이터를 불러올 수 있다.

이와 같은 방식으로, 새로운 노드들이 예를 들어 레거시 애플리케이션으로부터의 기업의 기존 데이터 또는 데이터 저장 요소를 사용하여 네트워크에 추가될 수 있다.

노드들은 사용자 관리, 동기화 및/또는 응용 프로그램 관리가 될 수 있으며 임의의 특정 노드는 사용자 관리되고, 동기화되거나 또는 응용 프로그램 관리되는 개별 속성 또는 속성 세트들을 가질 수 있다. 즉, 속성별로 노드를 콘트롤 및 관리할 수 있다.

보다 구체적으로, 한 노드에 있는 레코드들이 다른 노드에 있는 하나 이상의 레코드들에 링크될 수 있다.

기업 환경은 기존의 쿼리 및 노드들을 재사용하여 솔루션을 빠르게 구축할 수 있을 뿐만 아니라, 새로 구축된 솔루션들에 대해 새로운 데이터가 생성되거나 불러올 수 있게 됨에 따라 지속적으로 데이터 네트워크를 개선하거나 또는 그에 추가할 수 있다.

플랫폼의 구성 및 다양한 구성요소들은 기업 및 데이터 구축 솔루션들의 다른 사용자 방식에 따라 개선하는 몇 가지 고유한 기능을 가능하게 한다.

도 6에 도시된 바와 같이 데이터 노드들(34)의 네트워크를 제공하고 또한 해당 데이터 네트워크에 대한 데이터 레이어 콘트롤 및 인터페이스를 제공함으로써, 솔루션들은 데이터 사일로에서 이와 같은 기능들을 복제하는 전통적인 접근 방식보다 적은 노력으로 또한 더욱 빠른 속도로 구축될 수 있다.

종래의 접근 방식에 있어서, 각각의 솔루션은 퍼시스턴스을 위해 별도의 데이터베이스(24)를 필요로 하는 별도의 애플리케이션(10)으로서 구현된다(도 1 참조).

대조적으로, 여기에 기술된 본 방명의 시스템은 다수의 솔루션들에 대한 데이터를 관리하기 위한 단일 플랫폼을 제공한다.

상기 플랫폼을 사용하여, API들에 걸쳐 솔루션들에 대한 퍼시스턴스이 제공될 수 있다.

이와 같은 구조로 인해, 각 솔루션에 개별적으로 필요한 데이터 통합 없이 솔루션들에 걸쳐 데이터들이 재사용될 수 있다. 이는 특히 많은 솔루션들을 생성할 때 인프라구조 부담을 감소시킨다.

전통적인 데이터베이스들은 개발 팀에 의해 작성된 코드에 의해 사용되도록 설계된 것으로 인식된다. 이 코드는 일반적으로 개별 사용자(12)에 대한 별도의 계정이 아닌, 애플리케이션(응용 프로그램)(10)에 대한 계정으로 실행된다.

즉, 전통적인 애플리케이션 개발 환경에 있어서의 액세스 콘트롤은 전형적으로 다수의 애플리케이션(10)들에 대해 여러 팀에서 단일 데이터베이스를 사용할 수 있을 만큼 충분히 강력하지 않다.

이 제한을 극복하기 위해, 여기에 설명된 시스템은 모든 사용자들(개발자들 포함)이 보고 편집할 수 있는 것을 제한하는 데이터 액세스 콘트롤이 제공한다.

플랫폼의 보안 레이어는 이와 같은 콘트롤들을 적용하여, 그에 따라 각 사용자(12)가 그들이 갖는 액세스 권한에 따라 데이터 네트워크의 슬라이스(조각)을 볼 수 있도록 한다.

종래의 접근 방식에 있어서, 데이터 변경 감사는, 이론적으로 애플리케이션 내의 모든 데이터에 대한 일반 기능으로서 애플리케이션 코드에서 구현될 수 있었지만 실제로는 거의 그렇지 않았다.

일반적으로, 애플리케이션(10)의 개발자들은 관심 있는 특정 데이터세트에 대한 변경 사항들을 저장하기 위해 별도의 "감사 로그(audit log)" 테이블을 구축한다.

그러나, 변경 사항들은 모든 데이터세트들에 대해 보편적으로 캡처되지 않으며, 감사 로그가 사용도될 수 있는 경우 체계적인 접근을 통해서는 복구할 수 없는 경우가 많다.

현재 설명된 시스템에서, 상기 플랫폼은 이전 버전으로 롤백하는 기능과 함께 각 개별 레코드의 자동 데이터 버전 관리를 수행하도록 구성된다. 이는, 애플리케이션 개발 노력을 감소시키고 노력 비용/영향(impact)으로 인해 타협하지 않고 모든 데이터에 적용되도록 보장된다.

또한 자동 데이터 버전 관리는 사용자 규정 콘트롤 속성들0(예를 들어: 생성 시간, 생성자 등)을 회피함으로써 데이터 모델을 단순화한다.

상기 플랫폼의 데이터 버전 관리 모듈에 의해 적용된 자동 데이터 버전 관리는, 테이블의 스키마가 변경된 시나리오에서도, 변경 사항을 다시 적용함으로써, 이전 버전들의 보기, 버전들 간의 차이, 특정 버전으로 되돌리는 기능 모두를 허용하는 방식으로 모드 데이터를 저장함으로써 행해질 수 있다.

종래의 접근 방식에 있어서, 데이터를 보고 편집할 수 있는 사람을 제한하는 기능은 애플리케이션 특정 코드(도 1 참조)에서의 각 애플리케이션(10)에 의해 구현된다. 이 애플리케이션 특정 코드는 데이터 레이어가 아니라, 애플리케이션/기능(function)/기능 수준(feature level)에서 작성된다.

위에서 언급되고 도 5 및 6에 도시된 바와 같이, 플랫폼에는 데이터 노드 수준에서 규정된 데이터 액세스 콘트롤이 있으며, 솔루션들은 이와 같은 콘트롤를 자동으로 준수해야 한다.

도 9에 도시된 바와 같이, 플랫폼에 의해 사용되는 스크립팅 언어 쿼리의 실행은, 액세스 콘트롤 메타데이터를 활용하여 쿼리 엔진을 실행함으로써, 데이터 네트워크로부터 불러온 쿼리 결과들이 특정 사용자가 거기에 액세스할 수 있는 것으로 제한되도록 한다.

이 데이터 레이어 액세스 콘트롤들은, 각각 및 모든 애플리케이션에 대한 액세스 콘트롤들을 생성할 필요를 제거함으로써 애플리케이션 개발 노력들을 경감시킨다.

또한, 모든 액세스 채널들(예를 들어: API, UI 등)에 걸쳐 콘트롤들(예를 들어: 단일 사용자가 다수의 애플리케이션들을 통해 동일한 데이터에 액세스하는 것)을 일관되게 시행한다.

종래의 접근 방식에서, 애플리케이션들(10)에 의해 사용되는 데이터베이스(24)의 레코드들 간의 링크들은 열(column) 값들의 복사 및/또는 대리 키들을 사용함으로써 수행된다.

현재 설명된 본 발명의 시스템에서, 상기 플랫폼은 속성 및 속성 값들에 관계없이 한 노드의 레코드를 다른 노드의 하나 이상의 레코드들에 링크하는 기능을 제공한다.

또한, 상기 플랫폼은 쿼리들에 있어서 링크들을 사용하기 위한 능력을 제공한다. 이는 물리적 및 논리적 모델들을 통합함으로써 데이터 모델을 단순화하고 또한 수동으로 규정된 대리 키에 대한 종속성을 방지한다.

또한, 플랫폼을 사용하여 수행된 연결은 통상적으로 복잡한 조인들을 필요로 하는 것들을 회피함으로써 쿼리들을 단순화한다.

링크하는 것는 사용자 규정 컬럼과 별도로 레코드들 간의 링크들을 저장하는 플랫폼에 의해 수행될 수 있다. 사용자 규정 컬럼들에 영향을 받지 않는 방식으로, 이와 같은 관계의 맵핑을 포함하는 별도의 테이블이 사용될 수 있다.

이 링크 메커니즘은 단지 예시 목적을 위한 것일 뿐이며, 정확한 구현은 기본 퍼시스턴스의 유형에 따라 달라질 수 있다.

쿼리 엔진은 기본 퍼시스턴스 언어, 예를 들어, SQL을 생성함으로써 플랫폼의 스크립팅 언어를 실행할 수 있고, 적용 가능한 경우 "점(도트)" 표기법(도 9에 도시됨)을 분해하고 모델로부터 논리적으로 변환한다.

그 다음, 데이터를 논리적으로부터 물리적으로 변환하고 승인된 데이터만 기본 퍼시스턴스로부터 가져오도록 액세스 콘트롤이 적용할 수 있다. 다음, 기본 퍼시스턴스 기본 쿼리가 수행되고 복귀될 수 있다.

사용자 권한별로 데이터 액세스를 필터링하도록 하는 전통적인 접근 방식은, 물리적 데이터베이스 레이어에 대한 데이터 통합, 퍼시스턴스 및 게시 인터페이스에 대한 콘트롤 및 보안의 애플리케이션별 절연 레이어에 의존한다.

이와 같이, 데이터를 보고 편집할 수 있는 사람을 제한하는 기능은, 각 애플리케이션 내에서 애플리케이션 기능/기능 수준에서 작성된 애플리케이션 특정 코드에서 구현된다.

이와 같은 전통적인 접근 방식은 애플리케이션에 구애받지 않으며 광범위하고 시간 소모적인 애플리케이션 개발 노력을 필요로 한다.

이와 같은 전통적인 접근 방식을 다루기 위해, 여기에 설명된 플랫폼은 데이터 레이어에서 데이터 액세스 콘트롤을 규정하기 때문에 그에 따라 애플리케이션 개발 시간을 상당히 감소시키면서 모든 액세스 채널들(예: API 및 UI)에 걸쳐 콘트롤의 일관된 시행을 제공하고(예를 들어, 단일 사용자가 다중 애플리케이션을 통해 동일한 데이터에 액세스함) 부적절한 액세스의 위험을 제거한다.

메타데이터 및 자격 데이터의 캐싱을 주입하고 전용 처리 모듈 및 테이블을 통합하여 상호작용 레이어 내의 개별 테이블에서 자격을 캡처하면 성능을 가속화할 수 있다는 것이 밝혀졌다.

이하에 설명된 캐싱 프로토콜은 액세스 권한 또는 쿼리 그 자체와 관련된 변경 사항들에 따라 점진적으로 캐시 변환 쿼리를 실행하거나 쿼리를 재생성할 수 있으며, 이때 변경 사항들은 신속하거나 거의 즉각적인 방식으로 반영된다.

따라서, 새로운 사용 권한이 적용되는 동안, 과도한 데이터 액세스의 가능성이 제거될 수 있다.

다음은 상호작용 레이어 내에서 자격을 관리한 다음, 고려된 액세스 권한을 채용한 "급하게(on-the-fly)" 쿼리를 재작성하기 위해 쿼리 엔진을 통해 자격을 적용함으로써 데이터 수준 액세스 콘트롤에 대한 프로세스를 설명한다.

이는 메타데이터 및 자격 데이터를 캐싱하고 전용 처리 모듈들 및 테이블들을 통합하여 상호 작용 레이어 내의 별도 테이블들에서 자격을 캡처하도록 하는 동안 수행될 수 있다.

승인 변경

플랫폼에 의해 다루어지는 또 다른 문제는 플랫폼이 성능에 영향을 미치지 않고 원활한 방식으로 변경 승인 프로세스를 구현할 수 있도록 하는 효과적인 기본 데이터 구조들을 설계하는 데 있다.

애플리케이션 쿼리는 승인된 데이터베이스 변경 사항들만에 기초하여 결과들을 계산해야 하며 승인을 위해 보류 중인 변경 사항들을 추적하고 버전 관리해야 한다.

종래의 접근 방식의 기존 변경 승인 기술은, 플랫폼이 직면한 매우 예측할 수 없는 사용 패턴을 처리하도록 설계되지 않은 것으로 밝혀졌으며, 그에 따라 본 명세서에 설명된 플랫폼의 운영에 대해 지나치게 복잡하거나 성능이 떨어지는 것으로 결정되었다.

또한, 이와 같은 기존의 기술들은 고정된 데이터베이스 스키마 설계에 더 적합한 것으로 밝혀진 반면 플랫폼 및 해당 데이터 협업 네트워크(들)는 지속적인 진화를 겪고 있다.

승인되지 않은 변경 사항들을 추적하기 위한 전용의 하나와 승인된 마스터 테이블 그 자체인 다른 하나인 두 개의 개별 테이블을 유지 관리하는 것이 변경 승인에 사용될 수 있음을 발견했다.

이 두 테이블 아키텍처 내의 프로세스들을 실행하여, 응용 프로그램 레이어에 있어서의 상호 작용 레이어 외부와 즉석에서의 변경 사항 계산을 포함하여, 마스터와 승인되지 않은 변경 사항 테이블 간에 변경들이 이루어진 특정 필드를 비교하고 식별했다.

이에 따라 각 마스터 데이터 컬럼에 대한 변경 사항들을 식별하기 위해 지속적 플래그들을 기반으로 하는 프로세스가 생성되었으며, 이는 수용 가능한 성능 및 스토리지 요구 사항 특성들을 제공하고, 또한 플랫폼의 전체 아키텍처의 일부로서 통합되었다.

이와 같이, 승인되지 않은 데이터베이스 변경사항들을 효과적으로 버전화하고 추적하기 위해, 하나는 승인되지 않은 변경사항들을 추적하는 데 전용적이고 다른 하나는 승인된 마스터 테이블 그 자체인 두 개의 개별 테이블들을 유지하는 2-테이블 데이터 구조 설계가 본 발명에 제공된다.

이는, 성능 및 스토리지 요구 사항 특성에 부정적인 영향을 주지 않으면서 각각의 마스터 데이터 컬러의 변경 사항들을 식별하는 앞서 언급한 지속 플래그들이 포함될 수 있다.

데이터 기반 권한

모든 액세스 방법들(예를 들어: API 또는 UI)에 걸쳐 일관되게 데이터베이스에 의해 시행될 수 있는 사용자/그룹 기반 컬럼 수준 자격에 추가하여, 여기에 설명된 플랫폼은 데이터 기반 자격을 허용하도록 구성될 수도 있다.

조건들이 없다면 데이터는 여전히 단편화되고 복제되어야 한다는 것을 알고 있다.

예를 들어, 회사에 있는 모든 사람의 직함과 이름을 보고 싶지만, 그(그녀) 자신의 전화번호와 주소만 볼 수 있고, 그(그녀)의 관리자(들)은 그(그녀)의 급여만 볼 수 있다.

이 정보가 동일한 테이블에 존재하기 위해, 플랫폼은 테이블 내의 데이터를 기반으로 액세스를 콘트롤할 수 있는 별도의 조건들을 적용한다.

컬럼 레벨 자격은 상호작용 레이어를 생성하고 백엔드로 전송되기 전에 쿼리를 다시 작성함으로써 적용될 수 있다. 이것은 사용자의 권한을 실행 중인 쿼리와 결합된다.

사용자 쿼리의 "where 절"은 추가 조건들을 포함하도록 보강될 수 있지만, 어떤 경우에 예를 들어 업데이트를 수행할 때 이는 where 절을 포함하도록 쿼리를 완전히 재구성하는 것을 의미하는 것을 발견했다.

그러나, 이는 사용자의 권한이 액세스 권한이 없는 데이터를 기반으로 할 수 있기 때문에 데이터 기반 권한을 수행하는 데는 충분하지 않을 수 있다.

플랫폼은 해당 사용자의 컨텍스트 하에 전체 쿼리를 실행할 수 있다. 예를 들어 사용자가 이름, 직위, 전화번호, 주소가 있는 테이블의 이름 및 직위에만 액세스할 수 있는 경우, 플랫폼은 해당 사용자의 권한을 적용하고 사용자가 다시 이름 및 직위로 가져오는 데이터를 제한할 수 있다.

데이터 기반 권한을 사용하면, 사용자가 주소 필드에 액세스할 수 없는 경우 플랫폼에서 사용자가 주소가 특정한 주(state) 또는 도(province)에 있는 모든 직원들을 볼 수 있다.

해당 플랫폼은 다른 컬럼들에 영향을 주는 다수의 권한들을 함께 레이어링할 수 있도록 구성될 수도 있다(예를 들어: 당신은 자신의 이름, 직위, 전화번호 및 주소는 볼 수 있지만 다른 직원은 이름과 직위만 볼 수 있다. ).

Where 절을 동적으로 다시 작성함으로써, 플랫폼은 조건들을 개별 컬럼들로 분리하지 못할 수도 있다. 따라서, 플랫폼의 재작성 로직은 조건들이 이 범주에 속할 때 그 조건들의 위치설정을 조정하도록 향상될 수 있다.

또한, 테이블들 사이에 링크가 있는 경우, 현재 데이터세트의 콘트롤에 추가하여, 링크된 테이블의 콘트롤이 적용되어야 함이 인식되었다.

이는 링크들이 다른 링크들을 가리킬 수 있고 그에 따라 하나의 추가적인 조건 세트뿐만 아니라 잠재적으로 다수를 포함할 수 있기 때문에 이는 매우 복잡해질 수 있다.

다욱이, 링크들은 플랫폼 내부에서 다중 선택을 지원하여 하나 대 다수 관계를 허용하도록 한다.

사용자가 데이터의 하위 집합에 액세스할 수 있는 환경에서, 여러 선택 항목들이 있는 경우에는 사용자가 볼 수 있는 항목만 볼 수 있도록 플랫폼을 구성할 수 있다.

이는 이와 같은 조건들을 동적으로 설명하기 위해 다시 쓰기 논리를 더욱 복잡하게 만들 수 있다.

데이터 기반 시나리오를 가능하게 하기 위해, 자격 조건들 내의 사용자가 현재 사용자 및 그들이 속한 그룹에 대한 정보에 액세스할 수 있도록 플랫폼을 구성할 수도 있다. 이와 같은 기능들을 지원하도록 쿼리 언어를 확장함으로써 이를 수행할 수 있다.

잠재적인 성능 문제들을 해결하기 위해(이와 같은 콘트롤이 각 요청의 파싱과 기본 데이터베이스에 대해 실행되는 최종 쿼리에 추가된 복잡성으로 인해) 플랫폼은 스테이트먼트가 플랫폼의 쿼리 엔진에 의해 처리되는 시간의 수를 줄일 수 있는 맞춤 캐싱 레이어를 구현할 수도 있다.

이와 같이, 플랫폼은, 현재 사용자의 자격 증명이 아닌 시스템 사용자를 통해 재작성된 쿼리를 실행하여 데이터 기반 자격을 허용하다수의 자격들을 함께 계층화 수 있는 데이터 레벨 액세스 콘트롤을 위한 프로세스를 제공한다.

데이터 동기화/커넥터 아키텍처

ETL(Extract Transform Load) 툴은 일반적으로 새 데이터를 삽입하거나 또는 스크립트를 실행하여 기존 데이터를 지우는 구성요소를 제공하는 반면, 여기에 설명된 플랫폼은 기존 데이터를 그대로 두고 버전 이력을 보존하기 위해 델타를 적용하는 데이터 동기화를 생성하고자 한다.

플랫폼은, 데이터 동기화 아키텍처가 소스 또는 타겟과 무관한 방식으로 이를 수행하기 위한 것이다. 이와 같은 방식으로, 플랫폼에 무관하게, 인터페이스에 대해 간단한 커넥터들을 구축하여 예를 들어 1-2일의 기간에 걸쳐 보다 짧은 양의 시간으로 새로운 커넥터들의 생성을 가능케 하며, 동기화 운영 방식 방법 및 노출되는 기능에 에 일관성을 유지할 수 있다.

동기화를 구현하는 첫 번째 단계는 조정 논리(reconciliation logic)를 설정하는 것이다.

플랫폼은 구획화(파티셔닝)을 구현하도록 구성될 수 있으며, 이 구획화는 커스텀 인덱싱 및 정렬 전략에 의존하는 커스텀 알고리즘을 생성함으로써 상대적으로 더욱 효과적인 것으로 나타났다.

다음, 동기화 유틸리티와 플랫폼용 웹 애플리케이션 간에 전송할 때 병목 현상이 데이터의 직렬화 및 역직렬화로 이동되는 것이 발견되었다.

구글(Google)에서 제공하는 프로토콜 버퍼(Protocol Buffers)와 같은 다양한 직렬화 프로토콜들이 사용될 수 있다.

프로토콜 버퍼는 일반적으로 고정 페이로드 구조에 정렬되지만, 플랫폼에서는 앞뒤로 이동하는 데이터가 고정 스키마를 준수하지 않을 수도 있다. 이에 따라, 플랫폼은 동적 구조를 해당 유형의 모델에 맞도록 구성하였다.

따라서, 플랫폼은, 동기화 엔진으로부 터 소스 및 타겟을 추출할 수 있는데, 이는 플랫폼이 새로운 커넥터를 추가할 때, 데이터를 소스 및 타겟의 각 조합에 대한 솔루션들을 구현하는 것이 아닌, 그 데이터를 표준 중간 포맷으로 변환하기 위해 그에 대해 작성된 코드를 가질 필요만 있다는 것을 의미힌다.

네트워크 성장

도 13a - 도 13c는 시간에 따른 데이터세트 네트워크(34)의 개발을 나타낸다.

보다 구체적으로, 도 13a는 데이터가 아직 개발 중이기 때문에 초기 단계의 34개 데이터세트 네트워크를 도시한다.

초기 단계에서는, 보다 적은 수의 노드들(36)은 물론 노드들(36) 사이에 보다 적은 수의 링크들(40)이 존재한다.

데이터세트가 개발됨에 따라, 사용자는 데이터세트 네트워크(34)에 더 많은 데이터를 추가하여 네트워크를 성장시킨다.

도 13b는 초기 단계보다 늦은 단계의 데이터세트 네트워크(34)를 도시한다.

이 단계에서, 데이터세트 네트워크는 많은 노드들(36) 및 노드들 사이에 많은 링크들(40)을 갖는다.

도 13c는 도 13b에 도시된 단계보다 훨씬 더 늦은 단계의 데이터세트 네트워크를 도시한다.

이 단계에서, 데이터세트 네트워크는 많은 수의 노드들(36) 및 노드들(36) 사이에 많은 수의 링크들(40)을 갖는다.

도 14 및 도 15는, 데이터세트 네트워크(34)에 대한 전통적인 애플리케이션의 개략도를 제공한다.

도 14 및 도 15는, UI(14), API(15), 로직(Logic), 콘트롤(16), 퍼시스턴스(20)를 포함하고 컴퓨팅 장치(18)의 운영 체제와 통합되는 전통적인 애플리케이션(또는 "앱")을 나타낸다.

한편, 데이터세트 네트워크(34)는, 자기 기술, 자체 연결 및 자체 보안의 노드들(36)을 포함한다.

이와 같이, UI(14), API 또는 운영 체제(18)와의 통합 필요성이 존재하지 않는다. API(41) 또는 애플리케이션 익스피리언스(32)는 쿼리 인터페이스(33)를 통해 데이터 네트워크(34)로부터 직접 데이터(25)를 얻는다.

이는 별도의 데이터베이스를 생성하고, 가져오고, 업데이트하고 유지 관리할 필요성을 제거한다. 이것은 또한, 각 애플리케이션의 보안 및 콘트롤(16), 데이터 통합(18), 데이터 퍼시스턴스(20) 및 데이터 공개 시스템(22)을 관리할 필요성을 제거한다.

상기 데이터세트 네트워크(34)는, 추가적인 보안 및 콘트롤(16)들, 데이터 통합(18), 데이터 퍼시스턴스(20), 및 데이터 공개(22) 능력들을 필요로 하지 않는다.

또한, 쿼리 인터페이스(33)가 사용 가능하기 때문에, 데이터와 상호작용하기 위해 사용자 규정 사용자 인터페이스를 생성하는 것도 선택 사항이다.

따라서, 임의의 수의 데이터세트 노드(36) 및 애플리케이션 익스피리언스가 네트워크(34)에 추가될 수 있음을 알 수 있다. 새로운 애플리케이션이 추가됨에 따라, 데이터의 네트워크가 성장하고 새로운 링크들이 새로운 데이터세트들 사이에 형성된다.

도 16a는 사일로 데이터베이스들을 사용하는 전통적인 애플리케이션 개발을 위한 보안 및 콘트롤(16)을 도시하는 개략도이다.

도 16b는 데이터 네트워크(34)를 사용하는 애플리케이션 개발을 위한 액세스 레이어(39)을 통한 보안 및 콘트롤을 나타내는 개략도이다.

도 16b에서, 데이터(26)는 도 16a에 도시된 바와 같이, 애플리케이션의 서비스 계이 아닌 사용자의 크리덴셜을 통해 액세스된다.

데이터 네트워크(34)의 보안 및 콘트롤(39)은 전통적으로 행해지는 바와 같이 각각의 애플리케이션(10)이 아니라 데이터세트(26)별로 규정된다.

이를 통해 실제의 애플리케이션 간 보안 및 데이터 콘트롤이 가능하고 데이터 중복이 제거된다.

사용자(12)는 또한, 선택적으로 항상 애플리케이션을 통하는 대신에 데이터 네트워크 사용자 인터페이스(42)를 통해 직접 데이터와 상호작용할 수 있다.

예시의 단순성과 명료성을 위해, 적절한 것으로 간주되는 경우, 대응하는 또는 유사한 요소를 나타내기 위해 도면들 사이에 참조 번호가 반복될 수 있다.

또한, 본 명세서에 기술된 실시예의 완전한 이해를 제공하기 위해 다수의 특정 세부사항들이 제시된다.

그러나, 본 명세서에 기재된 실시예는 이와 같은 특정 세부사항 없이 실시될 수 있다는 것이 당업자에 의해 이해될 것이다.

다른 경우에, 잘 알려진 방법들, 절차 및 구성요소들은 여기에 설명된 실시예를 불명료하게 하지 않도록 상세하게 설명되지 않았다. 또한, 설명은 여기에 기술된 실시예의 범위를 제한하는 것으로 간주되어서는 안 된다.

본 명세서에 사용된 예시 및 대응하는 도면들은 단지 예시를 위한 것임을 이해할 것이다. 여기에 표현된 원리를 벗어나지 않으면서 다른 구성 및 용어가 사용될 수 있다.

예를 들어, 구성 요소와 모듈은 이와 같은 원칙에서 벗어나지 않고 다른 연결로 추가, 삭제, 수정 또는 배열될 수 있다.

또한, 명령을 실행하는 본 명세서에 예시된 임의의 모듈 또는 구성요소는 저장 매체, 컴퓨터 저장 매체, 또는 데이터 저장 장치(이동식 및/또는 비이동식)와 같은 컴퓨터 판독 가능 매체를 포함하거나 이에 대한 액세스 권한을 가질 수 있음을 인식해야할 것이다.

예를 들어, 자기 디스크, 광 디스크 또는 테이프와 같은 것들이 있다. 컴퓨터 저장 매체는 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 착탈식 및 비이동식 매체를 포함할 수 있다.

컴퓨터 저장 매체의 예로는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, 디지털 다목적 디스크(DVD) 또는 기타 광학 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 기타 자기 저장 장치가 있다.

원하는 정보를 저장하는 데 사용할 수 있고 애플리케이션, 모듈 또는 둘 다에서 액세스할 수 있는 기타 모든 매체. 이와 같은 컴퓨터 저장 매체는 플랫폼의 일부, 플랫폼의 구성요소 또는 이와 관련된 구성요소 등이 될 수 있으며 액세스하거나 연결할 수 있다.

본 명세서에 설명된 임의의 애플리케이션 또는 모듈은 이와 같은 컴퓨터 판독 가능 매체에 의해 저장되거나 보유될 수 있는 컴퓨터 판독 가능/실행 가능 명령어를 사용하여 구현될 수 있다.

본 명세서에 설명된 흐름도 및 다이어그램의 단계 또는 동작은 단지 일례에 불과하다.

위에서 기술된 원칙에서 벗어나지 않고 이와 같은 단계 또는 작업에 많은 변형이 있을 수 있다. 예를 들어, 단계는 다른 순서로 수행되거나 단계가 추가, 삭제 또는 수정될 수 있다.

상기한 원리들이 특정한 실시 예들을 참조하여 설명되었지만, 첨부된 특허청구범위에 요약된 바와 같이 이들을 다양하게 수정할 수 있음이 당업자에게는 자명할 것이다.

Claims (18)

1. 데이터 노드들의 네트워크를 생성하기 위한 시스템으로서,
   상기 시스템은,
   데이터를 포함하는 제1 데이터세트;
   상기 제1 데이터세트에 대한 사용자 액세스를 제한하는 액세스 콘트롤 레이어;
   상기 제1 데이터세트의 특성을 규정하고 적어도 하나의 후속 노드에 연결하는 메타데이터 레이어를 갖는 제1 노드를 포함하고:
   상기 적어도 하나의 후속 노드는,
   추가 데이터를 포함하는 후속 데이터세트;
   제2 데이터세트에 대한 사용자 액세스를 제한하는 후속 액세스 콘트롤 레이어;
   후속 데이터세트의 특성을 규정하는 메타데이터 레이어를 갖고;
   제1 노드를 후속 노드와 연관시켜 데이터 노드들의 네트워크를 생성하기 위해 하나 이상의 링크들이 생성되고;
   데이터 노드들의 네트워크는 제1 데이터세트 및 적어도 하나의 후속 데이터세트와 상호작용하기 위한 쿼리 레이어를 포함하고;
   복수의 애플리케이션들이 상기 쿼리 레이어를 통해 네트워크에 있어서의 데이터 및 추가 데이터에 액세스하는 시스템.
2. 제1항에 있어서, 내장(built-in) 데이터 보안 레이어는, 데이터가 사용자에게 주어진 특정 레벨의 자격을 지정하기 위해 사용되도록 데이터 레벨 자격을 포함하는 시스템.
3. 제2항에 있어서, 상기 데이터와 직접 상호작용하기 위한 사용자 친화적인 인터페이스를 더 포함하는 시스템.
4. 제2항에 있어서, 레거시 데이터를 데이터세트의 네트워크에 링크하기 위한 하나 이상의 커넥터들을 더 포함하는 시스템.
5. 제1항에 있어서, 상기 쿼리 인터페이스는 메타데이터 기반 API 및 메타데이터 기반 UI를 통해 데이터세트의 네트워크와 상호작용하는 시스템.
6. 제1항에 있어서, 데이터 소스의 자동 데이터 버전 관리를 수행하도록 구성되고, 사용자는 데이터세트 네트워크의 이전 버전으로 롤백할 수 있는 능력을 갖는 시스템.
7. 제1항에 있어서, 상기 데이터 및 추가 데이터는 버전 콘트롤되는 시스템.
8. 제1항에 있어서, 내장 데이터 콘트롤의 레이어는 API 및 UI가 내장 데이터 콘트롤를 자동으로 준수하기 위해 강제되도록 데이터 소스에서 규정되는 시스템.
9. 제1항에 있어서, 상기 데이터 노드들의 네트워크는 슈퍼 네트워크를 생성하기 위해 데이터 노드들의 적어도 하나의 다른 네트워크에 연결될 수 있는 시스템.
10. 데이터 노드들의 네트워크를 생성하기 위한 방법으로서,
    상기 방법은,
    데이터를 포함하는 제1 데이터세트;
    상기 제1 데이터세트에 대한 사용자 액세스를 제한하는 액세스 콘트롤 레이어;
    상기 제1 데이터세트의 특성을 규정하는 메타데이터 레이어를 갖는 제1 노드를 제공하고;
    추가 데이터를 포함하는 후속 데이터세트;
    제2 데이터세트에 대한 사용자 액세스를 제한하는 후속 액세스 콘트롤 레이어;
    후속 데이터세트의 특성을 규정하는 메타데이터 레이어를 갖는 적어도 하나의 후속 노드를 상기 제1 노드에 연결하고;
    제1 데이터세트 및 적어도 하나의 후속 데이터세트와 상호작용하기 위한 쿼리 레이어를 제공하고;
    상기 쿼리 레이어를 통해 네트워크의 데이터 및 추가 데이터에 액세스하는 것을 포함하고,
    제1 데이터세트의 변경이 데이터 노드들의 네트워크의 변경에 영향을 미치도록 데이터 노드들의 네트워크를 생성하기 위해 제1 노드를 후속 노드들과 연관시키도록 하나 이상의 링크들이 생성되는 방법.
11. 제10항에 있어서, 상기 내장 데이터 보안 레이어는, 데이터가 사용자에게 주어진 특정 레벨의 자격을 지정하는 데 사용되도록 데이터 레벨 자격을 포함하는 방법.
12. 제11항에 있어서, 상기 데이터 및 상기 추가 데이터는 버전 콘트롤되는 방법.
13. 제11항에 있어서, 레거시 데이터를 데이터세트의 네트워크에 링크하기 위한 하나 이상의 커넥터들을 더 포함하는 방법.
14. 제10항에 있어서, 상기 쿼리 인터페이스는 메타데이터 기반 API 및 메타데이터 기반 UI를 통해 데이터세트의 네트워크와 상호작용하는 방법.
15. 제10항에 있어서, 데이터 소스의 자동 데이터 버전 관리를 수행하도록 구성되고, 사용자는 데이터세트 네트워크의 이전 버전으로 롤백할 수 있는 능력을 갖는 방법.
16. 제10항에 있어서, 승인되지 않은 변경을 추적하기 위한 제1 테이블 및 승인된 변경을 유지하는 제2 테이블을 포함하는 2-테이블 아키텍처를 포함하는 방법.
17. 제10항에 있어서, 상기 내장 데이터 컨트롤의 레이어는 상기 API 및 UI가 상기 내장 데이터 컨트롤을 자동으로 준수하기 위해 강제되도록 데이터 소스에서 규정되는 방법.
18. 제10항에 있어서, 데이터 노드들의 네트워크는 슈퍼 네트워크를 생성하기 위해 데이터 노드들의 적어도 하나의 다른 네트워크에 연결될 수 있는 방법.

Images