KR20160117965A

KR20160117965A - NoSQL 모델 생성 방법 및 그 장치

Info

Publication number: KR20160117965A
Application number: KR1020150046112A
Authority: KR
Inventors: 장현주; 박경호; 강효정
Original assignee: 삼성에스디에스 주식회사
Priority date: 2015-04-01
Filing date: 2015-04-01
Publication date: 2016-10-11

Abstract

본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법은, 관계형 데이터베이스 모델에 따른 논리 ERD(Entity-Relationship Diagram)를 임포트 하는 단계와, 상기 논리 ERD에 포함 된 각 엔터티(entity) 간 참조 관계에 대한 정보 및 상기 논리 ERD에 포함 된 각 엔터티의 속성이 NoSQL에서만 지원되는 타입을 가지는지 여부에 대한 정보를 포함하는 논리 ERD 보완 정보를 사용자 입력 받는 단계와, 상기 논리 ERD에 포함 된 각 엔터티 중 NoSQL 테이블 생성 대상 엔터티를, 로우키(Rowkey) 항목과 칼럼(column) 항목을 포함하는 NoSQL 물리 ERD 템플릿에 반영하여, NoSQL 물리 ERD를 생성하되, PK(Primary Key) 속성은 로우키 항목에 배치하고, non-PK 속성은 칼럼 항목에 배치하는 단계와, 상기 NoSQL 물리 ERD에 상기 논리 ERD 보완 정보에 따른 변환을 적용하는 단계와, 상기 NoSQL 물리 ERD의 상기 칼럼 항목에 포함 된 항목들 중 로우키에 포함 될 칼럼을 사용자로부터 선택 받고, 선택 된 칼럼을 상기 NoSQL 물리 ERD의 상기 로우키 항목에 포함시키는 로우키 설계 단계와, 상기 NoSQL 물리 ERD를 디스플레이 하거나 기 지정 된 포맷으로 저장하는 단계를 포함한다.

Description

NoSQL 모델 생성 방법 및 그 장치 {Method and apparatus for generating NoSQL model}

본 발명은 NoSQL 모델 생성 방법 및 그 장치에 관한 것이다. 보다 자세하게는, 관계형 데이터베이스 모델에 따른 논리 ERD(Entity-Relationship Diagram)를 NoSQL 물리 ERD로 변환하는 것을 가이드 함으로써, NoSQL 모델을 생성하는 방법 및 그 방법을 수행하는 장치에 관한 것이다.

NoSQL 데이터베이스는 전통적인 관계형 데이터베이스 보다 덜 제한적인 일관성 모델을 이용하는 데이터의 저장 및 검색을 위한 매커니즘을 제공한다. NoSQL 데이터베이스는 단순 검색 및 추가 작업을 위한 최적화된 키 값 저장 공간으로, 레이턴시와 스루풋과 관련하여 상당한 성능 이익을 내는 것이 목적이다.

NoSQL 데이터베이스는 빅데이터와 실시간 웹 애플리케이션의 상업적 이용에 널리 쓰인다. 또, NoSQL 데이터베이스는 SQL 계열 쿼리 언어를 사용하지 않을 수 있다는 사실을 강조한다는 면에서 "Not only SQL"로 불리기도 한다.

NoSQL은 관계형 데이터베이스와 달리 기 정의된 스키마가 존재하지 않아 다양한 형태의 데이터를 저장할 수 있는 반면, 테이블 간의 릴레이션에 기반한 조인(join) 연산이 지원 되지 않는 등 많은 차이를 가진다.

관계형 데이터베이스를 이용하여 데이터 모델링을 하는 경우, 저장하려는 도메인 모델을 먼저 분석한 후에, 개체간의 관계(relationship)를 식별하고, 테이블을 추출해내고, 테이블을 이용하여 쿼리를 구현하여 결과를 추출한다. 반면에, NoSQL의 경우에는 이 접근 방법을 역순으로 진행해야 한다. 관계형 데이터베이스가 도메인 모델, 테이블, 쿼리의 순서로 모델링을 진행 했다면, NoSQL은 도메인 모델, 쿼리 결과, 테이블의 순서로 테이블을 모델링 해야 한다. 또한, 관계형 데이터베이스 의 경우 여러 가지 최적화된 기능으로 테이블을 가지고 자유롭게 쿼리 결과를 출력할 수 있지만, NoSQL의 경우 복잡한 쿼리 기능이 없기 때문에, 도메인 모델에서 어떤 쿼리 결과가 필요한지를 정의한 후에, 쿼리 결과를 얻기 위한 데이터 저장 모델을 역순으로 디자인해야 한다.

또한, 관계형 데이터베이스 모델링에서는 데이터의 일관성과 도메인 모델과의 일치를 위해서 데이터 모델을 정규화(normalize) 한다. 그 중에서도 같은 데이터가 두 개 이상의 테이블에 중복되게 저장하는 것을 제거 하는데, NoSQL은 반대의 접근 방법을 종종 사용한다. 쿼리의 효율성을 위해서 데이터를 정규화하지 않고, 의도적으로 중복된 데이터를 저장하는 등의 비정규화된 데이터 모델 설계 방식이 필요하다.

이처럼 NoSQL을 이용하여 데이터를 모델링 하고자 하는 경우, 기존의 관계형 데이터베이스와는 다른 접근 방식이 필요하다. 그런데, 관계형 데이터베이스에 대하여는 Erwin, PowerDesigner 등 모델링 툴(tool)이 존재하지만, NoSQL 데이터베이스는 사람의 노하우에 의존하여 모델링이 수행 되고 있을 뿐, 체계화된 모델링 툴은 제공 되고 있지 않다.

한국공개특허 제2012-0078908호

본 발명이 해결하고자 하는 기술적 과제는, 관계형 데이터베이스 모델에 따른 논리 ERD를, NoSQL 물리 ERD 모델로 변환하는 방법 및 그 장치를 제공하는 것이다.

본 발명이 해결하고자 하는 다른 기술적 과제는, 관계형 데이터베이스 모델에 따른 논리 ERD를 NoSQL 물리 ERD 모델로 변환하는 과정에서 활용 될 수 있는 도구(TOOL)를 제공하는 것이다.

본 발명이 해결하고자 하는 또 다른 기술적 과제는, 관계형 데이터베이스 모델에 따른 논리 ERD로부터 NoSQL 물리 ERD 모델을 산출하기 위한 사용자 입력을 가이드 하는 방법 및 그 가이드 방법이 적용 된 NoSQL 모델 생성 장치를 제공하는 것이다.

본 발명이 해결하고자 하는 또 다른 기술적 과제는, 관계형 데이터베이스에 비하여 차별화 된 특징을 가지는 NoSQL 테이블 구성을 적절하게 표현할 수 있는 NoSQL 물리 ERD 모델의 표기(notation) 방법 및 그 방법에 따라 NoSQL 모델을 생성하는 장치를 제공하는 것이다.

본 발명이 해결하고자 하는 또 다른 기술적 과제는, 리젼(region) 분할의 기준이 되는 리젼 분할 타입의 로우키 항목, 조회 요청의 검색 기준으로 사용 되는 검색 타입의 로우키 항목 및 sorting의 기준으로 사용 되는 sorting 타입의 로우키 항목을 순서대로 연결하여 NoSQL 테이블의 합성 로우키(compound rowkey)를 생성하고, 상기 NoSQL 테이블에 대한 조회 요청을 상기 합성 로우키를 이용하여 처리하는 방법 및 그 장치를 제공하는 것이다.

본 발명이 해결하고자 하는 또 다른 기술적 과제는, 리젼(region) 분할의 기준이 되는 리젼 분할 타입의 로우키 항목, 조회 요청의 검색 기준으로 사용 되는 검색 타입의 로우키 항목 및 sorting의 기준으로 사용 되는 sorting 타입의 로우키 항목을 순서대로 연결하여 NoSQL 테이블의 합성 로우키(compound rowkey)를 생성하고, 상기 합성 로우키를 이용하여 상기 NoSQL 테이블에 대한 스케일-아웃(scale-out)을 수행하는 방법 및 그 장치를 제공하는 것이다.

본 발명이 해결하고자 하는 또 다른 기술적 과제는, NoSQL 테이블에 적용 될 조회 요청에 부합하는 인덱스 테이블이 생성 되도록 사용자 입력을 가이드하고, 상기 사용자 입력에 따라 상기 인덱스 테이블을 자동으로 생성하며, 상기 인덱스 테이블을 이용하여 상기 NoSQL 테이블에 대한 검색을 수행하는 방법 및 그 장치를 제공하는 것이다.

본 발명이 해결하고자 하는 또 다른 기술적 과제는, 관계형 데이터베이스 모델에 따른 논리 ERD를 직접 모델링 하거나 외부 논리 ERD 데이터를 임포트 한 후, NoSQL 물리 ERD 모델로 변환하며, 변환 된 NoSQL 물리 ERD 모델을 생성하는 스크립트를 생성하여 외부의 NoSQL 서버에 자동 제공함으로써, 관계형 데이터베이스 모델을 이용하여 NoSQL 데이터베이스를 구축하는 전 과정을 가이드 하는 장치를 제공하는 것이다.

본 발명이 해결하고자 하는 또 다른 기술적 과제는, 관계형 데이터베이스 모델에 따른 논리 ERD를 직접 모델링 하거나 외부 논리 ERD 데이터를 임포트 한 후, NoSQL 물리 ERD 모델로 변환하며, 변환 된 NoSQL 물리 ERD 모델을 생성하는 스크립트를 자동 생성하고, 생성 된 스크립트를 실행함으로써, 관계형 데이터베이스 모델을 이용하여 NoSQL 데이터베이스를 구축하는 기능을 구비 한 NoSQL 서비스 장치를 제공하는 것이다.

본 발명의 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 아래의 기재로부터 당업자에게 명확하게 이해 될 수 있을 것이다.

상기 기술적 과제를 해결하기 위한 본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법은, 관계형 데이터베이스 모델에 따른 논리 ERD(Entity-Relationship Diagram)를 임포트 하는 단계와, 상기 논리 ERD에 포함 된 각 엔터티(entity) 간 참조 관계에 대한 정보 및 상기 논리 ERD에 포함 된 각 엔터티의 속성이 NoSQL에서만 지원되는 타입을 가지는지 여부에 대한 정보를 포함하는 논리 ERD 보완 정보를 사용자 입력 받는 단계와, 상기 논리 ERD에 포함 된 각 엔터티 중 NoSQL 테이블 생성 대상 엔터티를, 로우키(Rowkey) 항목과 칼럼(column) 항목을 포함하는 NoSQL 물리 ERD 템플릿에 반영하여, NoSQL 물리 ERD를 생성하되, PK(Primary Key) 속성은 로우키 항목에 배치하고, non-PK 속성은 칼럼 항목에 배치하는 단계와, 상기 NoSQL 물리 ERD에 상기 논리 ERD 보완 정보에 따른 변환을 적용하는 단계와, 상기 NoSQL 물리 ERD를 디스플레이 하거나 기 지정 된 포맷으로 저장하는 단계를 포함한다. 상기 NoSQL 모델 생성 방법은, 상기 NoSQL 물리 ERD의 상기 칼럼 항목에 포함 된 항목들 중 로우키에 포함 될 칼럼을 사용자로부터 선택 받고, 선택 된 칼럼을 상기 NoSQL 물리 ERD의 상기 로우키 항목에 포함시키는 로우키 설계 단계를 더 포함할 수 있다. 예를 들어, 상기 로우키 설계 단계는, 상기 NoSQL 물리 ERD에 상기 논리 ERD 보완 정보에 따른 변환을 적용하는 단계와 상기 NoSQL 물리 ERD를 저장하는 단계의 사이에 수행 될 수 있다. 다만, 상기 로우키 설계 단계는, 반드시 상기 NoSQL 물리 ERD에 상기 논리 ERD 보완 정보에 따른 변환을 적용하는 단계와 상기 NoSQL 물리 ERD를 저장하는 단계의 사이에 수행 되어야 하는 것은 아님을 유의한다.

상기 기술적 과제를 해결하기 위한 본 발명의 다른 실시예에 따른 NoSQL 모델 생성 방법은 NoSQL 테이블의 로우키(Rowkey) 정보 및 칼럼(column) 정보를 얻는 단계와, 상기 로우키 정보를 분석하고, 상기 로우키를 구성하는 각 항목을 밑줄 처리하는 단계와, 상기 칼럼 정보에 기반하여 각 칼럼의 CQ 타입을 판정하는 단계와, 상기 판정 결과 CQ 타입이 static(static) CQ인 경우 상기 CQ를 따옴표로 묶고, CQ 타입이 dynamic(dynamic) CQ인 경우 상기 CQ를 그대로 표시하며, CQ 타입이 nested CQ인 경우, 상기 CQ에 nested CQ임을 가리키는 기 지정 된 표기를 부가하는 단계와, 상기 칼럼 정보에 기반하여 각 칼럼의 밸류가 어레이(array) 타입인지 여부를 판정하고, 어레이 타입의 밸류는 기호 '['와 기호 ']'를 밸류 명칭의 양끝에 추가하는 단계와, 상기 각 칼럼 및 상기 로우키를 구성하는 각 항목에 대하여, CQ를 가리키는 변수 명 및 그에 대응되는 밸류를 가리키는 변수 명을 포함하는 NoSQL 물리 ERD를 디스플레이 하거나 저장하는 단계를 포함한다.

상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 실시예에 따른 NoSQL 기반 검색 방법은 리젼(region) 분할의 기준이 되는 리젼 분할 타입의 로우키 항목, 조회 요청의 검색 기준으로 사용 되는 검색 타입의 로우키 항목 및 sorting의 기준으로 사용 되는 sorting 타입의 로우키 항목을 순서대로 연결한 합성 로우키(compound rowkey)를 생성하는 단계와, 상기 합성 로우키와 하나 이상의 칼럼(column)을 포함하는 NoSQL 테이블을 생성하는 단계와, 상기 NoSQL 테이블을 가리키는 데이터를 저장하는 단계와, 상기 NoSQL 테이블에 대한 조회 요청을 입력 받는 단계와, 상기 합성 로우키를 기준으로 상기 조회 요청에서 요구 된 조회 항목을 검색하는 단계와, 상기 검색 결과를 출력하는 단계를 포함한다.

상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 실시예에 따른 NoSQL 테이블의 스케일-아웃 방법은, 리젼(region) 분할의 기준이 되는 리젼 분할 타입의 로우키 항목, 조회 요청의 검색 기준으로 사용 되는 검색 타입의 로우키 항목 및 sorting의 기준으로 사용 되는 sorting 타입의 로우키 항목을 순서대로 연결한 합성 로우키(compound rowkey)를 생성하는 단계와, 상기 합성 로우키와 하나 이상의 칼럼(column)을 포함하는 NoSQL 테이블을 생성하는 단계와, 상기 NoSQL 테이블을 가리키는 데이터를 스토리지에 저장하는 단계와, 상기 NoSQL 테이블을 상기 합성 로우키를 기준으로 리젼 분할하는 단계와, 분할 된 상기 리젼을 각각 서로 다른 스토리지에 저장하는 단계를 포함한다.

상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 실시예에 따른 NoSQL 기반 검색 방법은, NoSQL 테이블에 적용 될 조회 요청의 검색 조건으로 사용 되는 항목과 조회 대상인 항목을, 상기 NoSQL 테이블의 합성 로우키(Rowkey)를 구성하는 각 로우키 항목 및 각 칼럼(Column) 항목 중에서 선택 받는 단계와, 상기 선택 받은 검색 조건 항목이 상기 합성 로우키의 로우키 항목 및 로우키 항목의 순서를 활용하기에 적합하지 않는 경우, 상기 선택 받은 조회 대상 항목 중 적어도 일부와 조회 요청의 검색 조건 항목으로 구성 되는 인덱스 테이블을 생성하는 단계와, 상기 NoSQL에 대한 조회 요청의 처리를 위해, 상기 인덱스 테이블을 조회하는 단계를 포함한다.

상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 실시예에 따른 컴퓨터 프로그램은, 관계형 데이터베이스 모델에 따른 논리 ERD(Entity-Relationship Diagram)를 임포트 하는 단계와, 상기 논리 ERD에 포함 된 각 엔터티(entity) 간 참조 관계에 대한 정보 및 상기 논리 ERD에 포함 된 각 엔터티의 속성이 NoSQL에서만 지원되는 타입을 가지는지 여부에 대한 정보를 포함하는 논리 ERD 보완 정보를 사용자 입력 받는 단계와, 상기 논리 ERD에 포함 된 각 엔터티 중 NoSQL 테이블 생성 대상 엔터티를, 로우키(Rowkey) 항목과 칼럼(column) 항목을 포함하는 NoSQL 물리 ERD 템플릿에 반영하여, NoSQL 물리 ERD를 생성하되, PK(Primary Key) 속성은 로우키 항목에 배치하고, non-PK 속성은 칼럼 항목에 배치하는 단계와, 상기 NoSQL 물리 ERD에 상기 논리 ERD 보완 정보에 따른 변환을 적용하는 단계와, 상기 NoSQL 물리 ERD의 상기 칼럼 항목에 포함 된 항목들 중 로우키에 포함 될 칼럼을 사용자로부터 선택 받고, 선택 된 칼럼을 상기 NoSQL 물리 ERD의 상기 로우키 항목에 포함시키는 로우키 설계 단계와, 상기 NoSQL 물리 ERD를 디스플레이 하거나 기 지정 된 포맷으로 저장하는 단계를 실행 시키기 위하여, 기록 매체에 저장 된다.

상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 실시예에 따른 NoSQL 모델 생성 장치는, 하나 이상의 프로세서와, 상기 프로세서에 의하여 수행 되는 컴퓨터 프로그램을 로드(load) 하는 메모리와, 논리 ERD를 가리키는 데이터를 저장하고, 상기 컴퓨터 프로그램의 수행 결과에 의하여 생성 된 상기 논리 ERD 대응 NoSQL 물리 ERD를 저장하는 스토리지 장치를 포함한다. 이 때, 상기 컴퓨터 프로그램은, 상기 논리 ERD를 임포트 하는 오퍼레이션과, 상기 논리 ERD에 포함 된 각 엔터티(entity) 간 참조 관계에 대한 정보 및 상기 논리 ERD에 포함 된 각 엔터티의 속성이 NoSQL에서만 지원되는 타입을 가지는지 여부에 대한 정보를 포함하는 논리 ERD 보완 정보를 사용자 입력 받는 오퍼레이션과, 상기 논리 ERD에 포함 된 각 엔터티 중 NoSQL 테이블 생성 대상 엔터티를, 로우키(Rowkey) 항목과 칼럼(column) 항목을 포함하는 NoSQL 물리 ERD 템플릿에 반영하여, NoSQL 물리 ERD를 생성하되, PK(Primary Key) 속성은 로우키 항목에 배치하고, non-PK 속성은 칼럼 항목에 배치하는 오퍼레이션과, 상기 NoSQL 물리 ERD에 상기 논리 ERD 보완 정보에 따른 변환을 적용하는 오퍼레이션과, 상기 NoSQL 물리 ERD의 상기 칼럼 항목에 포함 된 항목들 중 로우키에 포함 될 칼럼을 사용자로부터 선택 받고, 선택 된 칼럼을 상기 NoSQL 물리 ERD의 상기 로우키 항목에 포함시키는 로우키 설계 오퍼레이션을 포함한다.

상기 기술적 과제를 해결하기 위한 본 발명의 다른 실시예에 따른 NoSQL 모델 생성 장치는, 하나 이상의 프로세서와, 상기 프로세서에 의하여 수행 되는 컴퓨터 프로그램을 로드(load) 하는 메모리와, 논리 ERD를 가리키는 데이터를 저장하고, 상기 컴퓨터 프로그램의 수행 결과에 의하여 생성 된 상기 논리 ERD 대응 NoSQL 물리 ERD를 저장하는 스토리지 장치를 포함한다. 이 때, 상기 컴퓨터 프로그램은 NoSQL 테이블의 로우키(Rowkey) 정보 및 칼럼(column) 정보를 얻는 오퍼레이션과, 상기 로우키 정보를 분석하고, 상기 로우키를 구성하는 각 항목을 밑줄 처리하는 오퍼레이션과, 상기 칼럼 정보에 기반하여 각 칼럼의 CQ 타입을 판정하는 오퍼레이션과, 상기 판정 결과 CQ 타입이 static(static) CQ인 경우 상기 CQ를 따옴표로 묶고, CQ 타입이 dynamic(dynamic) CQ인 경우 상기 CQ를 그대로 표시하며, CQ 타입이 nested CQ인 경우, 상기 CQ에 nested CQ임을 가리키는 기 지정 된 표기를 부가하는 오퍼레이션과, 상기 칼럼 정보에 기반하여 각 칼럼의 밸류가 어레이(array) 타입인지 여부를 판정하고, 어레이 타입의 밸류는 기호 '[]'를 밸류 명칭의 양끝에 추가하는 오퍼레이션과, 상기 각 칼럼 및 상기 로우키를 구성하는 각 항목에 대하여, CQ를 가리키는 변수 명 및 그에 대응되는 밸류를 가리키는 변수 명을 포함하는 NoSQL 물리 ERD를 디스플레이 하거나 저장하는 오퍼레이션을 포함한다.

상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 실시예에 따른 NoSQL 기반 검색 장치는, 하나 이상의 프로세서와, 상기 프로세서에 의하여 수행 되는 컴퓨터 프로그램을 로드(load) 하는 메모리와, 논리 ERD를 가리키는 데이터를 저장하고, NoSQL 테이블을 저장하는 스토리지를 포함한다. 이 때, 상기 컴퓨터 프로그램은, 리젼(region) 분할의 기준이 되는 리젼 분할 타입의 로우키 항목, 조회 요청의 검색 기준으로 사용 되는 검색 타입의 로우키 항목 및 sorting의 기준으로 사용 되는 sorting 타입의 로우키 항목을 순서대로 연결한 합성 로우키(compound rowkey)를 생성하는 오퍼레이션과, 상기 합성 로우키와 하나 이상의 칼럼(column)을 포함하는 NoSQL 테이블을 생성하는 오퍼레이션과, 상기 NoSQL 테이블을 가리키는 데이터를 저장하는 단계와, 상기 NoSQL 테이블에 대한 조회 요청을 입력 받는 오퍼레이션과, 상기 합성 로우키를 기준으로 상기 조회 요청에서 요구 된 조회 항목을 검색하는 오퍼레이션과, 상기 검색 결과를 출력하는 오퍼레이션을 포함한다.

상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 실시예에 따른 NoSQL 테이블의 스케일-아웃 관리 장치는, 하나 이상의 프로세서와, 상기 프로세서에 의하여 수행 되는 컴퓨터 프로그램을 로드(load) 하는 메모리와, 다른 스토리지 장치와 연결하는 네트워크 인터페이스와, 하나 이상의 NoSQL 테이블을 저장하는 하나 이상의 스토리지 장치를 포함한다. 이 때, 상기 컴퓨터 프로그램은, 리젼(region) 분할의 기준이 되는 리젼 분할 타입의 로우키 항목, 조회 요청의 검색 기준으로 사용 되는 검색 타입의 로우키 항목 및 sorting의 기준으로 사용 되는 sorting 타입의 로우키 항목을 순서대로 연결한 합성 로우키(compound rowkey)를 생성하는 오퍼레이션과, 상기 합성 로우키와 하나 이상의 칼럼(column)을 포함하는 NoSQL 테이블을 생성하는 오퍼레이션과, 상기 NoSQL 테이블을 가리키는 데이터를 상기 스토리지 장치에 저장하는 오퍼레이션과, 상기 NoSQL 테이블을 상기 합성 로우키를 기준으로 리젼 분할하는 오퍼레이션과, 분할 된 상기 리젼을 각각 서로 다른 스토리지에 저장하는 오퍼레이션을 포함한다. 이 때, 상기 분할 된 리젼은 서로 다른 스케일-아웃 관리 장치에 저장 되거나, 동일한 스케일-아웃 관리 장치에 포함 된 서로 다른 스토리지 장치에 저장 될 수 있다.

상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 실시예에 따른 NoSQL 기반 검색 장치는, 하나 이상의 프로세서와, 상기 프로세서에 의하여 수행 되는 컴퓨터 프로그램을 로드(load) 하는 메모리와, 하나 이상의 NoSQL 테이블을 저장하고, 상기 NoSQL 테이블에 대한 인덱스 테이블을 저장하는 스토리지 장치를 포함한다. 이 때, 상기 컴퓨터 프로그램은, NoSQL 테이블에 적용 될 조회 요청의 검색 조건으로 사용 되는 항목과 조회 대상인 항목을, 상기 NoSQL 테이블의 합성 로우키(Rowkey)를 구성하는 각 로우키 항목 및 각 칼럼(Column) 항목 중에서 선택 받는 오퍼레이션과, 상기 선택 받은 검색 조건 항목이 상기 합성 로우키의 로우키 항목 및 로우키 항목의 순서를 활용하기에 적합하지 않는 경우, 상기 선택 받은 조회 대상 항목 중 적어도 일부와 조회 요청의 검색 조건 항목으로 구성 되는 인덱스 테이블을 생성하는 오퍼레이션과, 상기 NoSQL에 대한 조회 요청의 처리를 위해, 상기 인덱스 테이블을 조회하는 오퍼레이션을 포함한다.

상기와 같은 본 발명에 따르면, NoSQL 모델링에 익숙하지 않은 사용자라도 관계형 데이터베이스 모델에 따른 논리 ERD를 기반으로 쉽게 NoSQL 테이블들을 모델링 할 수 있는 효과가 있다.

또한, 표준화 된 NoSQL 물리 모델 표기법을 이용하여 NoSQL 물리 ERD 모델을 생성함으로써, 생성 된 모델을 보는 사람이 그 의미를 명확하게 파악하도록 돕는 효과가 있다.

또한, 기 지정 된 타입 순서로 합성 로우키의 항목들을 조합함으로써, 고품질의 로우키를 설계하도록 사용자를 가이드 하는 효과가 있다. 이 때, 상기 합성 로우키는 리젼 분할의 기준으로 사용 될 수 있다. 따라서, 상기 합성 로우키를 기준으로 스케일-아웃이 자동으로 수행 되도록 지원하는 효과가 있다.

도 1은 본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법의 순서도이다.
도 2는 본 발명의 몇몇 실시예들을 설명하기 위하여 참조되는 관계형 데이터 베이스를 가리키는 논리 ERD(Entity-Relationship Diagram)의 예시이다.
도 3은 도 2의 논리 ERD에 포함 된 특정 엔터티를 참조하는 참조 엔터티를 선택하기 위한, 본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법 수행 시 제공 될 수 있는 UI의 예시이다.
도 4는 내지 도 7은 도 2의 논리 ERD에 포함 된 특정 엔터티를 참조하는 참조 엔터티를 선택하고, 그 중에서 link 엔터티, nested 엔터티, denormalize 엔터티를 각각 선택하기 위한, 본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법 수행 시 제공 될 수 있는 UI의 예시이다.
도 8은, 도 2의 논리 ERD에 포함 된 속성 중 어레이 타입을 지정하기 위한, 본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법 수행 시 제공 될 수 있는 UI의 예시이다.
도 9는, 도 2의 논리 ERD에 포함 된 속성 중 CQ(Column Qualifier)가 런-타임(run-time)에 결정 되는 dynamic 타입을 지정하기 위한, 본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법 수행 시 제공 될 수 있는 UI의 예시이다.
도 10은, 도 9에 도시 된 UI를 이용하여 dynamic 타입 속성을 지정 한 경우, 그 속성을 가리키는 CQ에 대응하는 밸류(value) 속성을 지정하기 위한, 본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법 수행 시 제공 될 수 있는 UI의 예시이다.
도 11은, 도 2의 논리 ERD에 대하여 특정 엔터티('객체' 엔터티)에 대한 참조 엔터티 지정 및 속성 보완이 마무리 된 후의 상황을 도시한 도면이다.
도 12는, 도 2의 논리 ERD에 포함 된 엔터티들 중에서 NoSQL 테이블로 생성할 엔터티를 선택 받기 위한, 본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법 수행 시 제공 될 수 있는 UI의 예시이다.
도 13은 도 1의 순서도에 따른 방법의 일부 동작을 보다 상세하게 설명하기 위한 순서도이다.
도 14는 본 발명의 몇몇 실시예들에서 참조될 수 있는, NoSQL 물리 ERD 템플릿을 도시한 도면이다.
도 15는 도 11에 도시 된 상태의 '객체' 엔터티를 도 14의 템플릿에 반영한 결과로 생성 된 NoSQL 물리 ERD 초안을 도시한 도면이다.
도 16은 도 11에 도시 된 상태의 '이벤트' 엔터티를 도 14의 템플릿에 반영한 결과로 생성 된 NoSQL 물리 ERD 초안을 도시한 도면이다.
도 17은 도 11에 도시 된 상태의 '이미지' 엔터티를 도 14의 템플릿에 반영한 결과로 생성 된 NoSQL 물리 ERD 초안을 도시한 도면이다.
도 18은 도 15에 도시 된 '객체' 엔터티의 NoSQL 물리 ERD 초안에 nested 엔터티를 가리키는 칼럼들과 비정규화 속성을 가리키는 칼럼을 추가한 상태의 NoSQL 물리 ERD를 도시한 도면이다.
도 19는 도 1의 순서도에 따른 방법의 일부 동작을 보다 상세하게 설명하기 위한 순서도이다.
도 20은 도 19의 순서도에 따른 일부 동작을 보다 상세하게 설명하기 위한 순서도이다.
도 21 내지 도 23은 로우키 설계용 사용자 입력을 위한, 본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법 수행 시 제공 될 수 있는 UI의 예시이다.
도 24는 로우키 설계가 완료 됨에 따라, NoSQL 물리 ERD에 대한 칼럼 항목이 최종 확정 된 이후, 칼럼 항목들을 서로 다른 칼럼 패밀리(Column Family)로 분할하기 위한, 본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법 수행 시 제공 될 수 있는 UI의 예시이다.
도 25 내지 도 26은 인덱스 테이블을 생성하기 위한, 본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법 수행 시 제공 될 수 있는 UI의 예시이다.
도 27은 도 2에 도시 된 논리 ERD를 입력 받아, 도 3 내지 24를 참조하여 설명 된 실시예를 수행한 결과로 출력 되는 NoSQL 물리 ERD의 최종본 중, '객체' 테이블에 대한 인덱스 테이블의 예시이다.
도 28은 도 2에 도시 된 논리 ERD를 입력 받아, 도 3 내지 24를 참조하여 설명 된 실시예를 수행한 결과로 출력 되는 NoSQL 물리 ERD의 최종 본 중 NoSQL 테이블을 도시한 것이다.
도 29는 본 발명의 다른 실시예에 따른 NoSQL 모델 생성 장치의 블록 구성도이다.
도 30은 본 발명의 또 다른 실시예에 따른 NoSQL 데이터베이스 서비스 장치의 블록 구성도이다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예를 상세히 설명한다. 본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 게시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 발명의 게시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

다른 정의가 없다면, 본 명세서에서 사용되는 모든 용어(기술 및 과학적 용어를 포함)는 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 공통적으로 이해될 수 있는 의미로 사용될 수 있을 것이다. 또 일반적으로 사용되는 사전에 정의되어 있는 용어들은 명백하게 특별히 정의되어 있지 않는 한 이상적으로 또는 과도하게 해석되지 않는다. 본 명세서에서 사용된 용어는 실시예들을 설명하기 위한 것이며 본 발명을 제한하고자 하는 것은 아니다. 본 명세서에서, 단수형은 문구에서 특별히 언급하지 않는 한 복수형도 포함한다.

이하, 도 1을 참조하여 본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법을 설명한다. 상기 NoSQL 모델 생성 방법은 연산 수단을 구비한 컴퓨팅 장치에 의하여 수행 될 수 있다. 상기 컴퓨팅 장치는, 예를 들어 도 29 내지 도 30을 참조하여 설명할 NoSQL 모델 생성 장치 또는 NoSQL 데이터베이스 서비스 장치일 수 있다. 이하, 이해의 편의를 위하여, 본 실시예에 따른 NoSQL 모델 생성 방법의 각 동작을 실시하는 주체는 그 기재가 생략될 수 있다.

본 실시예에 따른 NoSQL 모델 생성 방법은 관계형 데이터베이스(이하, 'RDB'라 기재함) 모델에 따른 논리 ERD를 NoSQL 물리 ERD로 변환한다. NoSQL 기술에 따르면 RDB에서는 지원되지 않는 다양한 확장성이 지원 된다. 본 실시예에서는, 이러한 점을 반영하기 위한 사용자 입력을 가이드 한다. 예를 들어, NoSQL에서는 조인(join) 연산이 지원되지 않는 점을 보완하기 위하여, nested 엔터티 등의 다양한 형태의 비정규화(denormalization) 방법을 제공한다. 상기 가이드 되는 사용자 입력은 상기 비정규화를 반영하기 위한 엔터티 간의 참조 관계를 정의하는 입력을 포함한다. 또한, NoSQL에서는 칼럼 값의 데이터 타입이 다양하다. 예를 들어, 어레이(array) 타입의 칼럼 값도 입력 가능하다. 상기 가이드 되는 사용자 입력은, 속성 타입을 변경하기 위한 사용자 입력도 포함한다.

이하, 도 1을 참조하여 본 실시예에 따른 NoSQL 모델 생성 방법을 전체적으로 설명한 후, 도 3 내지 도 28을 참조하여 구체적인 사항에 대하여 개별적으로 설명한다.

먼저, RDB 모델의 논리 ERD가 임포트(import) 되고, 임포트 된 논리 ERD가 분석된다(S100). 상기 논리 ERD는 XML 기반의 파일 또는 테이블 정의 문서 형태로 임포트 될 수 있다. 상기 논리 ERD는, 개념적으로 데이터베이스를 모델링 하기 위하여 작성 된 것으로, 하나 이상의 PK(Primary Key) 속성 및 non-PK 속성을 포함하는 엔터티로 구성되고, 각 엔터티 간의 참조 관계를 정의하며, 각 엔터티에 포함 된 각 속성의 명칭, 데이터 타입 및 데이터 사이즈를 정의할 수 있다. 상기 NoSQL 물리 ERD는, NoSQL 테이블을 실제로 생성하는데 충분한 정보를 포함한다. 상기 NoSQL 물리 ERD는 하나 이상의 NoSQL 테이블에 대한 정보를 포함한다. 상기 NoSQL 물리 ERD는 적어도 일부의 NoSQL 테이블에 대한 인덱스 테이블에 대한 정보를 더 포함할 수 있다.

도 2에는 상기 RDB 모델의 논리 ERD의 일 예가 도시 되어 있다. 도 2는 5개의 서로 다른 엔터티(10, 11, 12, 13, 14)로 구성 되고, 각 엔터티가 서로 참조 관계를 가지는 논리 ERD를 표현한다. 도 2의 논리 ERD에서, 객체 엔터티(10)와 이벤트 엔터티(12)는 소위 m:n(many to many) 관계를 가지고, 객체 엔터티(10)와 객체특성 엔터티(13)는 1:m(parent to child) 관계를 가지며, 객체 엔터티(10)와 이미지 엔터티(14)는 1:m 관계를 가진다. 이벤트연관객체관계 엔터티(11)는 객체 엔터티(10)와 이벤트 엔터티(12) 사이의 m:n 관계를 중계한다. 이벤트연관객체관계 엔터티(11)는, 객체 엔터티(10)와 이벤트 엔터티(12)의 접합 엔터티(junction entity)이다.

본 실시예에서, 외부의 논리 ERD가 임포트 되는 대신, 논리 ERD를 모델링 하기 위한 툴(tool)이 제공 될 수도 있다. 즉, 본 실시예는 별도의 논리 ERD 모델링 툴을 이용하여 미리 생성해 둔 논리 ERD를 임포트 한 후 임포트 된 논리 ERD를 NoSQL 물리 ERD로 변환하는 방법과, 논리 ERD를 생성한 후, 생성 된 논리 ERD를 NoSQL 물리 ERD로 변환하는 방법을 모두 제공할 수 있다.

논리 ERD의 분석 과정은, 상기 논리 ERD에 포함 된 각 엔터티를 식별하고, 식별 된 각 엔터티 내부에 포함 된 속성을 식별하며, 각 엔터티 사이의 참조 관계를 식별하는 것을 포함한다. 임포트 된 상기 논리 ERD가 XML 기반의 파일이라면, 상기 XML 파일을 파싱(parsing) 하는 것에 의하여 상기 분석 과정이 수행 될 수 있을 것이다. 임포트 된 상기 논리 ERD가 기 지정 된 규칙에 의하여 표현 된 스프레드시트(spreadsheet) 파일이라면, 상기 스프레드시트 파일의 편집 프로그램에 의하여 제공 되는 API(Application Programming Interface) 등을 활용하여, 상기 논리 ERD의 분석 과정을 수행할 수 있을 것이다.

논리 ERD의 분석 과정은, 각 엔터티 사이의 길이(length)를 식별하는 것을 더 포함할 수 있다. 예를 들어, 각 엔터티를 버텍스(vertex)로 하고, 각 엔터티 간의 참조 관계를 엣지(edge)로 하는 그래프를 구성하면, 각 엔터티 사이의 길이를 식별할 수 있다. 엔터티 사이의 길이는, 엔터티 사이의 최단 경로에 포함 된 참조 관계의 개수를 가리킨다.

다음으로, 상기 논리 ERD를 NoSQL 물리 ERD로 변환하기 위하여 보완 되어야 하는 부가 정보를 사용자 입력 받기 위한 UI(User Interface)를 제공한다(S200). 본 동작은 도 3 내지 도 13 등을 참조하여 추후 자세히 설명될 것이다. 이 때, 적절하게 부가 정보가 입력 될 수 있도록, 사용자에 Q&A 스타일의 위자드(wizard) 형 UI가 제공 될 수 있다.

다음으로, NoSQL 물리 ERD 템플릿을 바탕으로, 상기 논리 ERD의 NoSQL 물리 ERD 초안을 생성한다(S300). 이 과정은, 하나의 NoSQL 테이블을 가리키는 NoSQL 물리 ERD 템플릿에, 상기 논리 ERD에 포함 된 엔터티 중 NoSQL 테이블 생성 대상인 엔터티의 속성에 대한 정보를 대입한 후, 상기 논리 ERD를 NoSQL 물리 ERD로 변환하기 위하여 보완 되어야 하는 부가 정보를 반영하는 것으로도 이해할 수 있다. 본 동작은 도 14 내지 도 20 등을 참조하여 추후 자세히 설명될 것이다.

다음으로, 각 NoSQL 테이블에 대하여 로우키를 설계한다(S400). 이 때, 적절하게 로우키가 설계 될 수 있도록, 사용자에 Q&A 스타일의 위자드 형 UI가 제공 될 수 있다. 로우키 설계가 끝나면, 각 NoSQL 테이블의 칼럼 항목이 확정 된다. 이 상태에서, 각 칼럼 항목의 칼럼 패밀리(Column Family)를 정의하기 위한 UI가 이어서 제공 될 수 있다. 본 동작은 도 21 내지 도 24 등을 참조하여 추후 자세히 설명 될 것이다.

다음으로, 각 NoSQL 테이블에 대하여 인덱스를 설계한다(S500). 이 때, 적절하게 인덱스가 설계 될 수 있도록, 사용자에 Q&A 스타일의 위자드 형 UI가 제공 될 수 있다. 본 동작은 도 25 내지 도 26등을 참조하여 추후 자세히 설명 될 것이다.

상기 동작들을 수행하면, 상기 논리 ERD에 대응하는 NoSQL 물리 ERD가 완성된다(S600). 완성 된 NoSQL 물리 ERD의 예시는 도 27 및 도 28을 참조하여 추후 자세히 설명 될 것이다. 본 발명의 일 실시예에서는, 상기 NoSQL 물리 ERD를 기반으로 NoSQL 테이블을 생성하기 위한 스크립트를 자동으로 생성한다. 생성 된 상기 스크립트는 NoSQL 서버에 제공 되어, 완성 된 NoSQL 물리 ERD에 따른 NoSQL 데이터베이스가 실제로 생성 되도록 할 수 있다.

이하, 도 3 내지 도 13을 참조하여, 도 2에 도시 된 논리 ERD를 NoSQL 물리 ERD로 변환하기 위하여 보완 되어야 하는 부가 정보를 사용자 입력 받는 동작을 보다 자세하게 설명한다.

임포트 된 논리 ERD의 분석을 통하여, 상기 논리 ERD에 포함된 각 엔터티가 식별 되는 점은 이미 설명한 바 있다. 본 실시예에서는, 식별 된 전체 엔터티 중 적어도 일부에 대하여, 그 엔터티를 참조하는 참조 엔터티(referencing entity)를 사용자 입력 받는다. 논리 ERD에 다수의 엔터티가 포함 되어 있다면, 모든 엔터티에 대하여 참조 엔터티를 지정하는 것은 비효율적이다. 따라서, 예를 들어, 식별 된 전체 엔터티 중, non-PK 속성을 가지고 있지 않은 엔터티 또는 이미 다른 엔터티에 병합할 nested 엔터티로 지정 된 엔터티 등을 참조 엔터티 지정 대상에서 자동으로 제외할 수 있다.

예를 들어, 도 2에 도시 된 논리 ERD에서 총 5개의 엔터티 중, 이벤트 연관객체관계 엔터티는 참조 엔터티 지정 대상에서 자동으로 제외하고, 4개의 엔터티에 대하여 참조 엔터티 지정 UI가 디스플레이 될 수 있다. 물론, 상기 참조 엔터티 지정 UI를 통하여 다른 엔터티의 nested 엔터티로 지정 된 엔터티에 대하여는 상기 참조 엔터티 지정 UI가 디스플레이 되지 않을 것이다.

도 3은 도 2의 논리 ERD에 포함 된 '객체' 엔터티를 참조하는 참조 엔터티를 선택하기 위한, 일 실시예에 따른 NoSQL 모델 생성 방법 수행 시 제공 될 수 있는 참조 엔터티 지정 UI(210)의 예시이다. 상기 참조 엔터티 지정 UI는, '객체' 엔터티와 기 지정 된 한계치 이내의 길이(length)로 연결 된 후보 엔터티(이벤트 연관 객체 관계, 객체특성 속성값, 이벤트, 이미지)가 제시 되고, 각각의 참조 타입이 선택 될 수 있다. 상기 후보 엔터티가 제시 되는 이유는, 논리 ERD에 다수의 엔터티가 포함 되는 경우, 사용자가 어떤 엔터티를 선택해야 할지 혼란스러울 수 있기 때문이다. 상기 후보 엔터티가 제시 됨으로써, 사용자는 보다 쉽게 참조 엔터티를 선택할 수 있다.

임포트 된 논리 ERD의 분석 과정에서, 각 엔터티 간의 길이가 식별 될 수 있는 점은 이미 설명한 바 있다. 따라서, 논리 ERD의 분석 결과를 이용하여, 특정 엔터티와 기 지정 된 한계치 이내의 길이로 연결 된 후보 엔터티를 결정할 수 있을 것이다. 상기 한계치는 1 이상의 자연수로 설정 된다. 예를 들어, 상기 한계치는 2일 수 있다. 1:m 관계를 가지는 두 엔터티는 길이 1으로 연결되고, m:n 관계를 가지는 두 엔터티는 접합 엔터티(junction entity)를 통하여 길이 2로 연결 되기 때문에, 특정 엔터티의 참조 엔터티는 그 엔터티와 길이 2 이내로 연결 된 후보 엔터티들 중에서 선택 될 수 있다.

상기 참조 타입은, 'nested', 'link', 'denormalized', 'none' 중 어느 하나로 선택 될 수 있다. nested 엔터티는 대상 엔터티에 병합 되어야 할 엔터티를 가리킨다. 도 3에서, 이벤트 연관 객체관계 엔터티와 객체특성 속성값 엔터티는 nested 엔터티(22)로 지정 되었다. link 엔터티는 대상 엔터티와 1:m 관계 또는 m:n 관계 등 참조 관계를 가지지만, 그 속성의 값이 빈번하게 변경 되는 엔터티를 가리킨다. NoSQL 물리 ERD에서 link 엔터티 사이에는 link 관계를 가리키는 연결선이 표시 될 수 있다. 도 3에서, 이벤트 엔터티는 link 엔터티(21)로 지정 되었다. denormalized 엔터티는 적어도 일부의 속성이 대상 엔터티에 중복하여 포함 될 엔터티를 가리킨다. 도 3에서, 이미지 엔터티는 denormalized 엔터티(23)로 지정 되었다. 'none'은 참조 관계가 존재하지 않는 것을 의미한다. 상기 참조 엔터티 지정 UI에 포함 된 HELP 링크를 선택하는 경우, 'nested', 'link', 'denormalized', 'none'의 의미에 대한 정보가 디스플레이 된다.

참조 엔터티 지정 UI(210)에서 denormalize 엔터티로 지정 된 엔터티가 존재하면, 도 7에 도시된 바와 같이 denormalize 엔터티의 속성 중 denormalize 대상 속성을 선택 받기 위한 UI(220d)가 디스플레이 될 수 있다.

도 3에 도시 된 참조 엔터티 지정 UI는 한번에 모든 참조 엔터티를 다 지정하는 것이다. 일 실시예에서, 상기 참조 엔터티 지정 UI는 위자드 타입으로 제공 될 수도 있다. 위자드 타입의 참조 엔터티 지정 UI는 단계별로 질의가 디스플레이 되고, 그 응답에 기반하여 다음 질의가 결정 되는 방식을 가리킨다.

도 4는 내지 도 7은 도 2의 '객체' 엔터티를 참조하는 참조 엔터티를 선택하기 위한, 위자드 타입의 참조 엔터티 지정 UI의 예시이다. 위자드 타입의 참조 엔터티 지정 UI는 각각 사용자가 이전 단계로 되돌아가고자 하는 경우 선택 되는 "뒤로" 버튼과, 다음 단계로 넘어가고자 하는 경우 선택 되는 "다음" 버튼을 포함한다.

먼저, 도 4와 같이 '객체' 엔터티의 참조 엔터티(20)를 선택 받기 위한 UI(220a)가 디스플레이 된다. 이 때, 사용자의 선택을 돕기 위해, 상기 후보 엔터티들이 제시 될 수 있다.

다음으로, 도 5와 같이 선택 된 참조 엔터티들 중, link 엔터티를 선택 받기 위한 UI(220b)가 디스플레이 된다. UI(220b)에는 link 엔터티의 의미('속성의 값이 빈번하게 변경')에 대한 정보(21)가 포함 될 수 있다.

다음으로, 도 6과 같이 선택 된 참조 엔터티들 중 link 엔터티를 제외한 엔터티들을 제시하고, 제시 된 엔터티들 중 nested 엔터티를 선택 받기 위한 UI(220c)가 디스플레이 된다.

다음으로, 도 7과 같이 참조 엔터티 중 link 엔터티 및 nested 엔터티로 선택 되지 않은 나머지 엔터티가 denormalize 엔터티로 선정 되었음을 안내하고, denormalize 엔터티의 속성 중 denormalize 대상 속성을 선택 받기 위한 UI(220d)가 디스플레이 된다. 이 때, denormalize 엔터티의 속성 중, denormalize 속성이 복제 될 대상 엔터티에 이미 존재하는 속성은 denormalize 대상 속성으로 선택 될 수 없다. 도 7은, '이미지' 엔터티의 속성 중 '객체ID' 속성이 '객체' 엔터티에 이미 존재하기 때문에, '객체ID'에 대하여는 체크박스를 표시하지 않는 것(221)이 도시 되어 있다.

도 3 또는 도 4 내지 도 7에 도시 된 UI를 이용하여 '객체' 엔터티의 참조 엔터티 지정이 마무리 되면, 다른 엔터티에 대하여도 참조 엔터티의 지정이 수행 된다. 이 때, 논리 ERD에 포함 된 모든 엔터티에 대하여 참조 엔터티의 지정이 수행 될 수도 있으나, non-PK 속성을 가지고 있지 않은 엔터티 또는 이미 다른 엔터티에 병합할 nested 엔터티로 지정 된 엔터티는 참조 엔터티 지정의 대상에서 자동으로 제외 될 수도 있다.

참조 엔터티의 지정이 마무리 되면, 속성의 타입에 대한 보완 정보를 입력 받기 위한 UI가 디스플레이 된다. 도 8은, 도 2의 논리 ERD에 포함 된 속성 중 어레이 타입을 지정 받기 위한 UI(230a)이다. 도 8에 도시된 바와 같이, 각 엔터티에 속한 속성 별로, 어레이 타입을 지정하기 위한 체크 박스가 표시 될 수 있다. 도 8에는 '객체' 엔터티 뿐만 아니라 다른 엔터티들의 속성에 대하여도 어레이 타입 여부를 지정할 수 있는 UI가 도시되어 있다. 그런데, 일 실시예에 따르면 '객체' 엔터티의 속성들 중에서만 어레이 타입 여부를 지정받을 수도 있다. 이는, 현재 선택된 엔터티가 '객체' 엔터티이기 때문이다.

일 실시예에서, 도 9에 도시된 바와 같이, CQ(Column Qualifier)가 런-타임(run-time)에 결정 되는 dynamic type의 속성을 지정 받기 위한 UI(230b)가 더 디스플레이 될 수 있다. nested 엔터티로 지정 된 엔터티의 PK 속성은 자동으로 dynamic type으로 지정 된다. nested 엔터티로 지정 된 이벤트 연관 객체 관계 엔터티의 PK 속성인 이벤트ID 속성의 체크박스(234) 및 객체 특성 엔터티의 PK 속성인 객체ID 속성 및 객체특성ID속성의 체크박스(232, 233)에는 기본으로 체크 표시가 디스플레이 되어 있다. 사용자가 체크박스(232, 233, 234)의 체크를 해제하는 경우, 해당 엔터티를 nested 엔터티에서 해제할 것인지를 질의하는 UI가 디스플레이 될 수 있다. 도 9에는, 이미지 엔터티의 이미지 제목 속성이 사용자에 의하여 dynamic type으로 지정 된 상황이 도시 되어 있다.

사용자에 의하여 dynamic type으로 지정 된 속성이 존재하는 경우, 그 dynamic type의 속성이 dynamic CQ로 변환 되었을 때, 도 10에 도시된 바와 같이, 상기 dynamic CQ에 대응되는 밸류를 선택 받기 위한 UI(230c)가 디스플레이 된다. 도 10에는, 이미지 엔터티에 속한 dynamic type의 속성 이외의 속성들(236) 중에서 상기 dynamic CQ에 대응되는 밸류를 선택할 수도 있고, 이미지 엔터티 이외의 다른 엔터티의 속성들(237) 중에서 상기 dynamic CQ에 대응되는 밸류를 선택할 수도 있는 점이 도시 되어 있다.

도 9와 도 10을 종합하면, 이미지 엔터티는 객체 엔터티의 nested 엔터티가 아님에도 불구하고, 이미지 제목 속성이 dynamic CQ가 되고, 그에 대응 되는 밸류로 이미지 내용 속성이 연결 되도록 변형 될 수 있다. 즉, 본 실시예에 따르면 dynamic CQ의 개념을 확장 적용하여, 다양한 형태의 NoSQL 모델링이 가능하도록 하는 효과가 있다.

도 11은, 도 2의 논리 ERD에 대하여 객체 엔터티(10)에 대한 참조 엔터티 지정 및 속성 보완이 마무리 된 후의 논리 ERD(100b)를 도시한 도면이다. 속성 보완의 측면에서 객체 엔터티(10)의 이벤트 종류 ID 속성이 어레이 타입으로 지정(16)되었고, 이미지 엔터티(14)의 이미지 제목 속성이 dynamic CQ이고, 그 대응 밸류는 이미지 엔터티(14)의 이미지 내용 속성으로 지정 된 점이 표시 된다(17). 또한, 참조 관계 보완의 측면에서, 이벤트 엔터티(12)가 객체 엔터티(10)의 link 엔터티로 지정 되고, 이벤트 연관 객체 관계 엔터티(11)와 객체 특성 엔터티(13)가 객체 엔터티(10)의 nested 엔터티로 지정 되고, 이미지 엔터티(14)의 이미지 내용 속성이 객체 엔터티(10)로 denormalize 되는 점이 표시 된다(15e).

도 12는, 도 2의 논리 ERD에 포함 된 엔터티들 중에서 NoSQL 테이블로 생성할 엔터티를 선택 받기 위한 UI(240)를 도시한다. 참조 엔터티의 지정 결과 및 속성 타입에 대한 보완 결과를 논리 ERD 상에 표시하고, 동일 화면에 각 엔터티에 대한 NoSQL 테이블 생성 여부를 가리키는 체크 박스(241, 242, 243, 244, 245)를 배치함으로써, 사용자가 모든 정보를 고려하여 NoSQL 테이블로 생성할 엔터티를 선택할 수 있도록 가이드 한다. 도 12에서는, 객체 엔터티, 이벤트 엔터티 및 이미지 엔터티가 NoSQL 테이블로 생성 될 대상으로 선택 된 점이 도시 되어 있다.

도 13은, 논리 ERD를 NoSQL 물리 ERD로 변환하기 위하여 보완 되어야 하는 부가 정보를 사용자 입력 받는 단계(S200)에 대한 상세 순서도이다. 도 3 내지 도 12를 참조하여 설명한 동작을, 도 13을 참조하여 다시 한번 정리한다. 먼저, 논리 ERD에 포함 된 적어도 일부의 엔터티에 대하여, 그 엔터티를 참조하는 참조 엔터티를 선택 받는다(S210). 그리고, 논리 ERD에 포함 된 각 엔터티의 속성들 중, 어레이 타입의 속성을 선택 받고(S220), dynamic 타입의 속성을 선택 받는다(S230). 그리고, 논리 ERD에 포함 된 전체 엔터티 중, NoSQL 테이블로 생성할 엔터티를 선택 받는다.

일 실시예에서, 각 동작의 수행 순서가 도 13에 도시 된 것과 달라질 수 있다. nested 엔터티의 PK 속성은 dynamic 타입의 속성을 가져야 하므로, 참조 엔터티를 선택 받는 단계(S210)는, dynamic 타입의 속성을 선택 받는 단계(S230) 보다 먼저 수행 되어야 한다. 그 외의 동작들은 수행 순서가 도 13에 도시 된 것과 서로 달라질 수 있다.

이하, 도 14 내지 도 20을 참조하여, 부가 정보의 보완이 완료 된 논리 ERD를 NoSQL 물리 ERD로 변환하는 방법을 설명한다.

도 14에는, NoSQL 물리 ERD 템플릿(310)이 도시 되어 있다. NoSQL 물리 ERD 템플릿은 아무런 데이터도 포함하지 않는 빈 NoSQL 테이블이다. 설명을 위해, 도 14에는 2개의 로우키 항목과 5개의 칼럼 항목을 기재하였다. NoSQL 물리 ERD 템플릿은 XML, 기 지정 된 다이어그램 포맷 등의 형식을 가진 디지털 데이터이다. 상기 NoSQL 물리 ERD 템플릿은 NoSQL 테이블을 가리키며, 테이블 명칭, 로우키 항목 기재 영역(317), 칼럼 항목 기재 영역(318)으로 구성 된다. 또한, 각 항목에 대한 정보는 CQ(Column Qualifier)(311), CQ에 대응하는 밸류의 명칭(312), CQ의 변수명(313), 밸류(312)의 변수명(314), CQ의 데이터 타입(315) 및 밸류(312)의 데이터 타입(316)을 포함한다.

static CQ의 데이터 타입(315)은 CQ의 변수명(313)의 글자수를 반영하여 결정된다. 예를들어 CQ가 ‘이미지제목’이고, CQ_CODE가 ‘ImgTtl’이라면, CQ의 데이터 타입(315)은 VARCHAR(6) 으로 표기될 것이다. dynamic CQ의 데이터 타입(315) 및 밸류(312)의 데이터 타입(316)은 논리 ERD에 기재 된 것을 그대로 반영하거나, 논리 ERD에 미기재된 경우, 사용자로부터 추가 입력 받을 수 있다.

로우키 항목 기재 영역(317)에는 하나 이상의 로우키 항목이 포함 된다. 될 수 있다. NoSQL 테이블이 합성 로우키(compound rowkey)를 가지는 경우라면, 로우키 항목 기재 영역(317) 둘 이상의 로우키 항목(319)이 포함 된다. 상기 합성 로우키는 로우키 항목 기재 영역(317)에 포함 된 로우키가 순서대로 연결(concatenation) 되어 생성 될 수 있다. NoSQL 데이터베이스가 ordered key-value 타입인 경우, 로우키를 기준으로 정렬 되어 데이터가 저장 되므로, 로우키 항목 기재 영역(317)에 로우키를 기재하는 순서는 중요한 의미를 가진다.

본 발명의 일 실시예에 따르면, 로우키 항목 기재 영역(317)에는 기 지정 된 로우키 타입의 순서로 각 로우키 항목이 기재 된다. 본 실시예에 따르면, 합성 로우키 생성 시, 리젼(region) 분할의 기준으로 사용 되는 등 중요한 로우키 항목이 왼쪽에 배치 되도록 하고, uniqueness를 담보하기 위하여 추가적으로 연결하는 로우키 항목이 오른쪽에 배치 되도록 함으로써, 합성 로우키를 기준으로 데이터를 정렬하는 것에 의하여 데이터를 효과적으로 그룹핑 할 수 있는 효과가 있다. 합성 로우키의 생성과 관련 된 동작은, 도 21 내지 도 23을 참조하여 보다 자세히 설명한다.

로우키 항목 기재 영역(317)에는, 각 로우키 항목의 타입에 대한 정보가 명시 될 수 있다. 일 실시예에서, 로우키 항목은 밑줄 표시하여 칼럼 항목과 차별화 되도록 표시할 수 있다.

칼럼 항목 기재 영역(318)에는 하나 이상의 칼럼 항목이 포함 된다. 그리고, 칼럼 패밀리가 시작되는 칼럼 항목에 칼럼 패밀리 명칭(320, 321)이 부가 될 수 있다. 다른 실시예에서, 칼럼 패밀리에 속한 모든 칼럼 항목들에 대하여 소속 칼럼 패밀리 명칭이 명시 될 수도 있다.

칼럼의 CQ 타입이 static(static) CQ인 경우, 그 CQ는 따옴표로 묶어서 기재(322)한다. 그 CQ에 대응 되는 밸류의 명칭은 따옴표로 묶지 않고 표시한다(323). dynamic 타입의 칼럼으로 사용자에 의하여 지정 된 것이거나, nested 엔터티의 PK 속성이 아닌 경우, 기본적으로 각 엔터티의 속성들은 static 타입의 CQ로 변환된다.

칼럼의 CQ 타입이 dynamic(dynamic) CQ인 경우, 그 CQ는 따옴표로 묶지 않고 그대로 표시한다(324, 325).

nested 엔터티에 속한 칼럼이어서, 칼럼의 CQ 타입이 nested CQ인 경우, 그 칼럼 항목에 nested 엔터티임을 가리키는 기 지정 된 표기가 부가 된다. 예를 들어, 도 14에 도시 된 바와 같이 "Nested#일련번호" 형식의 표기가 nested 칼럼 항목의 좌측에 부가 될 수 있다. "Nested#일련번호" 형식의 표기를 통해, 첫 번째 nested 엔터티에 포함 되었던 칼럼들(326)과 두 번째 nested 엔터티에 포함 되었던 칼럼들(327)을 식별할 수 있다. 일 실시예에서, "Nested#엔터티명칭" 형식의 표기가 부가 될 수도 있다. 예를 들어, 이미지 엔터티 출신의 칼럼 항목이라면, 표기 "Nested#이미지"가 부가 될 것이다.

denormalization의 결과로 추가 되는 칼럼은, 그 칼럼 항목에 "Denorm#일련번호"와 같이 denormalization임을 가리키는 기 지정 된 표기(328)가 부가 된다. 일 실시예에서, "Denorm#엔터티명칭" 형식의 표기가 부가 될 수도 있다. 예를 들어, 이미지 엔터티 출신의 칼럼 항목이라면, 표기 " Denorm#이미지"가 부가 될 것이다.

어레이 타입의 속성으로 지정 된 칼럼은, 그 밸류(312)를 기재함에 있어서, 밸류의 명칭과 밸류의 변수명 양끝에 기호 '[', ']'를 각각 추가한다(330).

논리 ERD를 NoSQL 물리 ERD로 변환하는 것은, NoSQL 테이블의 생성 대상으로 선택 된 엔터티의 속성들을 NoSQL 물리 ERD 템플릿에 입력하는 것으로 시작 된다. 이 때, 논리 ERD 원본에 보완 된 부가 정보가 반영된다. 일 실시예에서는, 엔터티의 속성들에 상기 부가 정보를 반영한 후, NoSQL 물리 ERD 템플릿에 입력할 수도 있고, 엔터티의 속성을 원본 그대로 NoSQL 물리 ERD 템플릿에 입력한 후 상기 부가 정보를 반영할 수도 있고, 엔터티의 속성에 상기 부가 정보 중 일부만을 반영한 후, NoSQL 물리 ERD 템플릿에 입력할 수도 있다.

도 15 내지 도 17은 NoSQL 테이블의 생성 대상으로 선택 된 객체 엔터티, 이벤트 엔터티, 이미지 엔터티 각각의 속성을 NoSQL 물리 ERD 템플릿에 입력하여 생성한 NoSQL 물리 ERD 초안을 생성한 것이다. 이 때, PK 속성은 로우키 항목 기재 영역에 포함시키고, PK가 아닌 non-PK 속성은 칼럼 항목 기재 영역에 포함시킨다. 이미 설명한 바와 같이, dynamic 타입의 칼럼으로 사용자에 의하여 지정 된 것이거나, nested 엔터티의 PK 속성이 아닌 경우, 기본적으로 각 엔터티의 속성들은 static 타입의 CQ로 변환 된다.

도 15는 객체 엔터티의 NoSQL 물리 ERD 초안(340a)이다. 도 12에 도시 된 바와 같이, 객체ID 속성은 PK 속성이므로, 로우키 항목으로 추가 된다(341). 유의할 점은, 로우키 항목은 값만 가지고, CQ 변수명 및 CQ의 데이터 타입은 가지지 않는다는 것이다. 객체 엔터티의 non-PK 속성 8개는 칼럼 항목으로 추가 된다. 상기 추가 된 칼럼 항목은 모두 static CQ로 변환된다. 다만, 이벤트 종류 항목은 어레이 타입의 값을 갖는 것으로 사용자에 의하여 지정 되었으므로, 이벤트 종류 칼럼 항목의 밸류 명칭과 밸류 변수명 양끝에 기호 '[', ']'이 각각 추가(342)된 것을 확인할 수 있다.

도 16은 이벤트 엔터티의 NoSQL 물리 ERD 초안(350)이다. 도 12에 도시된 바와 같이, 이벤트ID 속성은 PK 속성이므로, 로우키 항목으로 추가 되었고, 이벤트 엔터티의 non-PK 속성 6개는 칼럼 항목으로 추가 된 것을 확인할 수 있다.

도 17은 이미지 엔터티의 NoSQL 물리 ERD 초안(360)이다. 도 17에 도시된 바와 같이, 이미지ID 속성은 PK 속성이므로, 로우키 항목으로 추가 되었다. FK(Foreign Key) 속성인 객체ID 속성은, non-PK 속성이므로, static CQ로 변환 되어, 칼럼 항목에 추가 된다. '이미지제목' 속성이 dynamic 속성으로 지정되고, 그 대응 밸류가 '이미지내용' 속성으로 지정 되었으므로, 이미지제목을 가리키는 dynamic CQ(361), 이미지내용을 가리키는 상기 dynamic CQ의 대응 밸류(362)로 구성 된 하나의 칼럼 항목이 추가 된다.

즉, 특정 엔터티에 제1 속성 및 제2 속성이 포함 되고, 상기 제1 속성은 dynamic으로 지정되고, 상기 제2 속성은 그 대응 밸류로 지정 되었다면, 상기 제1 속성의 CQ와 상기 제2 속성의 밸류로 구성된 하나의 칼럼 항목이 구성된다.즉, 이 경우 2개의 칼럼 항목이 하나의 칼럼 항목으로 합쳐지는 것으로 이해 될 수 있다.

도 17의 NoSQL 테이블은, 데이터를 아래의 표 1과 같이 저장할 것이다.

Rowkey	Column
Rowkey	객체ID	이미지제목
...	...	...
IMG3050	객체ID="OBJ43030"	한국여행003="2015년 한국여행에서 찍은 사진으로...."
IMG3051	객체ID="OBJ41030"	미국여행001="2014년 미국여행에서 찍은 사진으로...."
IMG3052	객체ID="OBJ30030"	중국여행003="2013년 중국여행에서 찍은 사진으로, 가족과 함께...."
...	...	...

다음으로, 참조 엔터티 관련 보완 사항을 NoSQL 물리 ERD에 반영하는 방법을 자세히 설명한다. 현재 설명하고 있는 케이스에서는, 도 12에 도시 된 바와 같이 객체 특성 엔터티가 객체 엔터티에 nested 엔터티로서 병합되고, 이벤트 연관 객체 관계 엔터티도 객체 엔터티에 nested 엔터티로서 병합되며, 이미지 엔터티의 이미지 내용 속성은 객체 엔터티에 denormalization을 위해 복제 된다. 도 18은 객체 엔터티의 참조 엔터티 관련 보완 사항이 적용 되어, denormalized 속성 관련 칼럼 항목(343) 및 nested 엔터티 관련 칼럼 항목(344, 345)이 도 15의 NoSQL 물리 ERD에 추가 된 것을 도시한다.

'이미지 내용' 칼럼 항목(343)은, 이미지 엔터티의 속성으로, 이미지 엔터티의 속성이 그대로 객체 테이블(340b)에 복제 된 것이다. '이미지 내용' 칼럼 항목(343)은, 사용자에 의하여 지정 된 denormalization의 결과로 객체 테이블(340b)에 복제 된 것으로, 이미지 테이블에도 동일한 칼럼이 중복 존재한다.

이 때, 일 실시예에서는 denormalization의 결과 병합된 칼럼 항목의 밸류 속성이 자동으로 어레이 타입으로 변환 될 수 있다. 도 18은, 이에 따라 이미지 내용 칼럼 항목(343)의 밸류 속성이 어레이 타입인 점을 표시하고 있다. 즉, 도 18에는 이미지 내용 칼럼의 밸류 변수명 양끝에 기호 '[', ']'이 각각 추가된 점이 도시 되어 있다. denormalization에 의하여 병합된 칼럼 항목의 밸류 속성을 어레이 타입으로 변환하는 이유는, denormalization의 타겟 엔터티와 소스 엔터티의 대응 관계가 1:N(N>=2) 관계일 수 있기 때문이다. 도 12를 참조하여 설명한 예시에서, 객체 엔터티와 이미지 엔터티는 서로 1:N 대응 관계를 가지므로, 객체 NoSQL 테이블에는 객체 엔터티와 대응 관계를 가지는 모든 이미지 엔터티의 '이미지 내용'이 저장 될 필요가 있을 것이다. 따라서, '이미지 내용' 칼럼의 밸류 타입은 어레이로 자동 변환 될 수 있다.

다른 실시예에서는, denormalization의 타겟 엔터티와 소스 엔터티의 대응 관계가 1:N(N>=2) 관계이더라도, denormalization의 소스 엔터티의 레코드들 중 하나를 대표 레코드로 선정하고, 선정 된 대표 레코드의 속성 만을 denormalization 타겟 엔터티에 복제할 수도 있다. 예를 들어, 도 12를 참조하여 설명한 예시에서, 객체 엔터티와 이미지 엔터티는 서로 1:N 대응 관계를 가지지만, 객체 NoSQL 테이블에는 이미지 엔터티의 레코드들 중 기 지정 된 기준에 따라 선정 된 하나의 대표 이미지 레코드의 '이미지 내용'만 저장 될 수 있다. 따라서, 이 경우 '이미지 내용' 칼럼의 밸류 타입은 어레이로 자동 변환되지 않고 일반 문자열 타입으로 지정 된다. 이 경우, 선정 된 대표 엔터티의 속성 만이 denormalize 되었음을 표시하기 위하여, denormalization에 의하여 복제 된 칼럼 항목의 CQ에는 기 지정 된 표기가 자동으로 부가 될 수 있다. 예를 들어, "<대표값>"이라는 표기가 CQ에 부가 될 수 있다. 도 18에 도시 된 케이스의 경우에는, denormalization에 의하여 복제 된 칼럼 항목의 CQ가 '이미지 내용'으로부터 '이미지 내용<대표값>'으로 자동 변환 될 수 있다.

다음으로, 객체 특성 엔터티가 nested 엔터티로 지정(nested#1) 된 것에 의하여 객체 테이블에 추가 되는 nested#1 관련 칼럼 항목의 도출 방법을 설명한다. nested 엔터티의 PK 속성은 dynamic CQ로 변환된다. 또한, nested 엔터티의 non-PK 속성은, PK 속성이 변환 된 dynamic CQ에 대응하는 밸류로 변환된다.

만약 nested 엔터티의 PK 속성이 복수 개 라면, 복수개의 PK 속성이 복합(mashed) dynamic CQ를 구성할 수 있다. e-mail을 가리키는 NoSQL 테이블이, 다른 NoSQL 테이블에 nested 엔터티로서 병합되는 경우를 가정하자. 또한, e-mail 테이블에 '메시지ID'와, 'e-mail제목' 두 개의 PK 속성이 존재하는 경우를 가정하자. 그렇다면, '메시지ID'의 값과 'e-mail제목'의 값이 연결 된 복합 dynamic CQ가 구성 될 수 있다. 이 때, 메시지ID의 값과 e-mail제목의 값 사이에 기 지정 된 구분자(delimiter)가 포함 될 수 있다. 상기 구분자는, 예를 들어 콜론(:), 세미콜론(;), 대쉬(-) 등 기 지정 된 어느 하나의 기호 이거나, 기 지정 된 둘 이상의 기호의 조합일 수 있다.

만약 nested 엔터티의 non-PK 속성이 복수 개 라면, 복수개의 non-PK 속성이 CQ에 대응 되는 복합(mashed) 밸류를 구성할 수 있다. 즉, 복합 dynamic CQ와 복합 밸류를 이용하여, nested 엔터티는 속성의 개수와 무관하게 하나의 칼럼으로 변환될 수 있다.

nested 엔터티가 복합 dynamic CQ와 복합 밸류로 구성 되는 하나의 칼럼으로 변환 되는 방식을 적용하면, 도 12에 도시 된 객체특성 엔터티는 '객체ID' 속성과 '객체 특성 ID' 속성이 복합 dynamic CQ를 구성하고, '객체 특성값' 속성과 '특성값 정상 여부' 속성이 복합 밸류를 구성한다.

일 실시예에서, nested 엔터티에 포함 된 속성들 중, nested 엔터티가 병합 될 엔터티에 이미 존재하는 속성은 병합 대상에서 제외 될 수 있다. 이는 데이터의 중복 저장을 막아서 스토리지의 낭비를 방지하는 효과를 가져온다. 이러한 방식에 의하면, 도 12에 도시 된 객체특성 엔터티에 포함 된 4개의 속성들 중, 객체 엔터티에 이미 존재하는 '객체ID' 속성은 병합 대상에서 제외 된다. 그 결과, nested 엔터티로서의 객체특성 엔터티는, '객체 특성 ID'를 가리키는 dynamic CQ와 '객체 특성값'과 '특성값 정상 여부'의 연결을 가리키는 복합 밸류로 구성 된 하나의 칼럼으로 변환 된다.

한편, A 개의 PK 속성으로 구성 되는 복합 dynamic CQ와 B개의 non-PK 속성으로 구성 되는 복합 밸류로 구성 되는 하나의 칼럼은, 본 실시예에 따른 NoSQL 물리 ERD 상에 Max(A, B) 개의 칼럼 항목으로 표현된다. 예를 들어, nested 엔터티에 2개의 PK 속성(제1 PK, 제2 PK) 및 3개의 non-PK 속성(제1 non-PK, 제2 non-PK, 제3 non-PK)이 포함 되는 경우, 상기 nested 엔터티는 표 2 또는 표 3 또는 표 4와 같이 3개의 칼럼 항목으로 표현 될 수 있다.

PK 속성의 개수가 non-PK 속성의 개수보다 한 개 모자라기 때문에, 3번 째 칼럼 항목에는 PK 속성에 대응되는 값이 존재하지 않는다. 표 2에 표시 된 방식은, PK 속성에 대응되는 값이 존재하지 않더라도, 직전 칼럼 항목의 값을 중복해서 기재하는 방식이고, 표 3에 표시 된 방식은, PK 속성에 대응되는 값이 존재하지 않으면 데이터를 기재하지 않고 비워두는 방식이며, 표 4에 표시 된 방식은, PK 속성에 대응되는 값이 존재하지 않으면, 값이 존재하지 않음을 의미하는 기 지정 된 기호(표 4에는 '!NONE!'으로 표현됨)를 대신 기재하는 방식이다.

CQ	VALUE
제1 PK	제1 non-PK
제2 PK	제2 non-PK
제2 PK	제3 non-PK

CQ	VALUE
제1 PK	제1 non-PK
제2 PK	제2 non-PK
	제3 non-PK

CQ	VALUE
제1 PK	제1 non-PK
제2 PK	제2 non-PK
!NONE!	제3 non-PK

도 18은, nested 엔터티가 병합 될 엔터티에 이미 존재하는 속성은 병합 대상에서 제외하는 방식 및 표 3에 표시 된 방식으로, 도 12에 도시 된 객체특성 엔터티가 2개의 칼럼 항목(344)으로 변환된 후, 객체 NoSQL 물리 ERD에 병합 된 것을 도시한다. 복합(mashed) dynamic CQ를 구성하는 각 CQ는, 콤마(,) 등의 기호에 의하여 구분 된다. 또한, 복합(mashed) 밸류를 구성하는 각 밸류 명칭도 콤마(,) 등의 기호에 의하여 구분 된다. 도 18에는 객체 특성 엔터티에서 병합 되어 합성 밸류를 구성하는 '객체특성값' 밸류 명칭과, '특성값정상여부' 밸류 명칭이 콤마에 의하여 구분 되는 점이 도시 되어 있다.

일 실시예에 따르면, nested 엔터티의 속성들 중 일부만이 병합될 수도 있다. 예를 들어, 객체 엔터티에 대한 nested 엔터티인 객체 특성 엔터티의 속성들 중, 객체특성ID 속성 및 객체특성값 속성 만 사용자에 의하여 선택 되어 객체 엔터티에 병합될 수 있다. 이 때, 객체ID 속성은 이미 객체 엔터티에 존재하므로 당연히 병합 대상에서 제외 되는 것이다. 또한 특성값정상여부 속성은 사용자에 의하여 병합 대상에서 제외 되는 것이다. 본 실시예에 따르면, 도 3 또는 도 6을 참조하여 설명한 nested 엔터티 선정용 UI가 디스플레이 된 이후, nested 엔터티로 선정 된 엔터티에 포함 된 속성들 중, 병합 대상 속성을 선택받기 위한 UI가 추가로 디스플레이 될 수 있다.

다음으로, 객체 엔터티에 병합 될 다른 nested 엔터티인 이벤트 연관 객체관계 엔터티가 어떻게 변환 되어 객체 NoSQL 물리 ERD에 병합 되는지 설명한다. 도 12에 도시 된 바와 같이, 이벤트 연관 객체 관계 엔터티는 객체 엔터티와 이벤트 엔터티의 m:n 관계를 중계하는 접합 엔터티이다. 그리고, non-PK 속성이 존재하지 않는 엔터티이다. 따라서, CQ로 변환될 속성이 존재할 뿐, 상기 CQ에 대응되는 밸류로 변환될 속성이 존재하지 않는다. nested 엔터티가 참조하는 엔터티 중 상기 nested 엔터티가 병합 될 대상 엔터티가 아닌 타 엔터티의 순번을 dynamic CQ 로 지정하고, 상기 타엔티티(이벤트 엔티티)의 로우키를 dynamic CQ에 대응하는 밸류로 변환한다. 도 12의 이벤트 연관 객체 관계 엔터티는 이벤트 객체의 순번을 가리키는 dynamic CQ와, 이벤트 객체의 로우키를 가리키는 밸류로 구성 되는 칼럼 항목(345)으로 변환 되어 객체 엔터티에 병합된다.

한편, nested 엔터티로서 병합 된 칼럼은 복수개가 열거 될 수 있음을 유의한다. 실제 데이터가 저장 될 때, nested 엔터티에 대응하는 칼럼은 nested 엔터티의 개수만큼 열거 될 수 있다.

도 18에 도시 된 객체 테이블의 NoSQL 물리 ERD는 아래 표 5와 같이 데이터를 저장할 것이다. 칼럼이 비교적 많은 관계로, 일부 칼럼은 표기가 생략 되어 있음을 유의한다.

Rowkey	COLUMN
OBJ0001	아이템ID="ASDEC30", 객체유형ID="TYPE3", ..., 이미지내용="2015년 한국여행에서 가족들과 함께 찍은 사진", IMAGE_CHAR_PANORAMA="245642243:OK", IMAGE_CHAR_SNAP="245653343:OK", IMAGE_CHAR_SMILE="245234243:OK", IMAGE_CHAR_BEAUTY="245643563:OK", EVT1="00135674", EVT2="00143D74", EVT3="001457FD", EVT4="0023563D", EVT5="0024DDFS", EVT6="0014DDF0"
OBJ0002	아이템ID="ASDEC31", 객체유형ID="TYPE2", ..., 이미지내용="2013년 중국 여행에서 친구들과 함께 찍은 사진", IMAGE_CHAR_PANORAMA="242342243:OK", IMAGE_CHAR_SNAP="245654343:OK", IMAGE_CHAR_BEAUTY="245643433:OK", EVT1="00135674", EVT2="00143D74"

도 19는, NoSQL 물리 ERD 템플릿을 바탕으로 논리 ERD를 NoSQL 물리 ERD로 변형하는 단계(S300)에 대한 상세 순서도이다. 도 14 내지 도 18을 참조하여 설명한 동작을, 도 19를 참조하여 다시 한번 정리한다.

먼저, 논리 ERD에 포함 된 엔터티들 중, NoSQL 테이블 생성 대상으로 사용자에 의하여 선택 된 엔터티를 가리키는 NoSQL 테이블의 초안을 생성한다(S310). 이 때, 기 지정 된 NoSQL 물리 ERD 템플릿에 엔터티의 속성들이 대입된다. 이 때, 어레이 타입을 갖는 것으로 지정 된 속성들에 대하여는 밸류 값이 어레이 타입을 갖도록 설정한다. 또한, dynamic CQ로 변환되는 것으로 지정 된 속성들에 대하여는 dynamic CQ 및 대응 되는 밸류 값으로 구성되는 칼럼으로 변환한다(S320). 또한, denormalize 대상 속성과, nested 엔터티를 병합한다(S330, S340). nested 엔터티는 dynamic CQ와 그 밸류로 구성 되는 하나의 칼럼으로 변환하여 병합하는 점은 이미 설명한 바 있다. 다음으로, link 엔터티와의 link를 형성한다(S350). 도 28에 도시된 바와 같이, 상기 link는 NoSQL 물리 ERD 상에 각 테이블 사이의 연결선으로 표현 될 수 있다.

도 20은 nested 엔터티를 병합하는 동작을 보다 상세하게 설명하기 위한 순서도이다. 먼저, nested 엔터티에 포함된 속성 중에서, 상기 nested 엔터티가 병합 될 대상 엔터티에 이미 포함 되어 있는 속성을 병합 대상에서 제외한다(S341). 다만, 이러한 중복 속성 삭제 과정은 실시예에 따라 수행되지 않을 수도 있다.

nested 엔터티에 non-PK 속성이 존재하지 않는 경우(S342), nested 엔터티가 참조하는 엔터티 중 상기 nested 엔터티가 병합 될 대상 엔터티가 아닌 타 엔터티의 row 순번을 가리키는 dynamic CQ와, 상기 타 엔터티의 로우키를 가리키고, 상기 dynamic CQ에 대응하는 밸류를 포함하는 칼럼으로 상기 nested 엔터티를 변환한다(S345, S346).

nested 엔터티에 non-PK 속성이 존재하는 경우(S342), PK 속성은 dynamic CQ로 변환하고(S343), non-PK 속성은 상기 dynamic CQ에 대응하는 밸류로 변환한다(S344). 이때, PK 속성이 복수 개인 경우, PK 속성들을 복합 dynamic CQ로 변환하고, non-PK 속성이 복수 개인 경우, non-PK 속성들을 복합 밸류로 변환한다.

이미 설명한 바와 같이, nested 엔터티는 하나의 칼럼으로 변환된다. nested 엔터티를 가리키는 칼럼이 복합 dynamic CQ를 포함하거나, 복합 밸류를 포함하는 경우에는, 상기 nested 엔터티를 가리키는 칼럼은 복수개의 칼럼 항목으로 구성된다. 상기 칼럼 항목은 nested 엔터티가 병합 될 대상 엔터티의 NoSQL 물리 ERD에 추가 된다(S347).

이제, NoSQL 물리 ERD로의 변환을 완성하기 위하여 남은 작업은 로우키(Rowkey)를 설계하고, 칼럼 패밀리를 설정하며, 인덱스 테이블을 설계하는 것이다. 로우키를 설계하는 것은 도 21 내지 도 23을 참조하여 설명하고, 칼럼 패밀리를 설정하는 것은 도 24를 참조하여 설명하고, 인덱스 테이블을 설계하는 것은 도 25 내지 도 26을 참조하여 설명한다.

도 21 내지 도 23은 로우키 설계용 사용자 입력을 위한, 본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법 수행 시 제공 될 수 있는 UI의 예시이다. 본 발명의 일 실시예에 따르면, 도 12에 도시 된 UI에서 "NoSQL 변환" 버튼이 눌리면, 도 21에 도시 된 UI가 디스플레이 될 수 있다.

도 21에 도시 된 UI는, 각 타입의 로우키를 지정 받는다. 하나의 로우키 항목만이 지정 된다면, 그 로우키 항목이 독자적으로 로우키로 사용 될 것이다. 반면에 두 개 이상의 로우키 항목이 지정 된다면, 각각의 로우키 항목이 "순서대로" 연결 되어 합성 로우키(compound rowkey)를 구성한다.

일 실시예에서, 각각의 로우키 항목이 연결 되는 순서는, "리젼 분할 타입->검색 기준 타입->sorting 타입"이다. 다른 실시예에서, 각각의 로우키 항목이 연결 되는 순서는, "리젼 분할 타입->검색 기준 타입->sorting 타입->unique 타입"이다.

NoSQL 테이블은 복수의 리젼(region)으로 분할되고, 각 리젼은 서로 다른 스토리지 장치에 저장 될 수 있다. 따라서, 리젼 분할은 스케일-아웃의 수단으로 사용 될 수 있다. 리젼 분할 타입의 로우키는, 리젼 분할의 기준이 되는 키이다.

리젼 분할 타입은 통합 기준 리젼 분할 타입, 보관 기준 리젼 분할 타입, 확장 기준 리젼 분할 타입, salting 타입으로 다시 구분된다. 2개 이상의 리젼 분할 타입 키가 합성 로우키 구성에 사용 된다면, 상기 합성 로우키는, 통합 기준 리젼 분할 타입, 보관 기준 리젼 분할 타입, 확장 기준 리젼 분할 타입, salting 타입의 로우키 항목을 순차적으로 연결한 것이다.

통합 기준 리젼 분할 타입의 로우키 항목은, 리젼 분할에 있어서 1순위로 적용되어야 하는 기준을 의미한다. 어떤 항목을 통합 기준 리젼 분할 타입의 로우키 항목으로 사용해야 할지는 NoSQL 모델링에 따라 저장 되는 데이터의 속성, 데이터 기록 패턴, 적용 되는 쿼리 형태 등을 종합하여 사용자에 의해 선택 될 것이다.

보관 기준 리젼 분할 타입의 로우키 항목은, 데이터 보관 주기를 가리킨다. 보관 기준 리젼 분할 타입의 로우키 항목을 이용하여 합성 로우키를 구성함으로써, 보관 주기에 따른 데이터 삭제 관리를 자동화할 수 있는 효과가 있다. 예를 들어, 보관기간이 ‘월’ 단위로 정의되는 경우, ‘년월’을 가리키는 칼럼을 합성 로우키 구성에 반영하여, 매 월별로 리젼 분할이 가능하다. 분할 된 리젼은 정책에 따라 자동 삭제 되도록 데이터를 배치 프로세스(batch process) 등을 통하여 관리할 수 있을 것이다.

확장 기준 리젼 분할 타입의 로우키 항목은, 분할 후 리젼의 개수를 결정할 때 기준치로 사용 될 수 있는 항목이다. 확장 기준 리젼 분할 타입은, 분할 단위를 결정하기 위한 기준 값으로 사용 된다. 예를 들어, 매월 1TB의 데이터가 축적 되는 테이블과 매월 100TB의 데이터가 축적 되는 테이블은 서로 다른 개수의 리젼으로 분할되어야 할 것이다. 리젼 분할의 기준이 되는 로우키 항목의 밸류가 1 내지 100의 값을 가진다고 가정하자. 이 때, 상기 확장 기준 리젼 분할 타입의 값이 1인 경우에는 하나의 리젼이 100개의 리젼으로 분할(1, 2, 3, 4, 5, 6, ... 100)되고, 상기 확장 기준 리젼 분할 타입의 값이 10인 경우에는 하나의 리젼이 10개의 리젼으로 분할(1~10, 11~20, ..., 91~100) 될 것이다. 즉, 상기 확장 기준 리젼 분할 타입은 리젼 분할의 기준이 되는 로우키 항목에 대한 리젼 분할 단위를 가리킬 수 있다.

매월 100TB의 데이터가 축적 되는 테이블의 경우, 상기 확장 기준 리젼 분할 타입의 값이 1이어서 하나의 리젼이 100개의 리젼으로 분할되더라도 각 리젼 내 데이터가 너무 많을 수 있다. 이러한 경우, 각 리젼을 추가 분할할 필요가 있을 것이다. salting 타입의 로우키 항목은 리젼을 추가 분할할 필요가 있는 경우, 사용되는 리젼 분할 단위를 가리킨다. 이러한 점에서, salting 타입의 로우키 항목은 추가 확장 기준 리젼 분할 타입을 의미하는 것으로 이해 될 수 있을 것이다.

검색 타입의 로우키는 조회 요청(쿼리)의 검색 기준으로 사용 되는 키이다. 쿼리에서 다수의 항목을 검색 기준으로 사용한다면, 다수의 검색 타입 로우키를 합성 로우키 구성에 반영할 수 있다.

sorting 타입의 로우키는 sorting의 기준으로 사용 되는 키이다. 쿼리의 조회 결과가 특정 기준으로 sorting 되어 있기를 원하는 경우, sorting 타입의 로우키를 합성 로우키 구성에 반영할 수 있다.

unique 타입의 로우키는 합성 로우키가 uniqueness를 만족시키도록 맨 마지막에 더 연결하는 로우키 항목이다. unique 타입의 로우키는 어떤 경우에도 uniqueness를 만족 시키는 항목을 선택하는 것이 바람직하다.

도 21에는 통합 기준 리젼 분할 타입(413), 보관 기준 리젼 분할 타입(414), 확장 기준 리젼 분할 타입(415), salting 타입(416), 검색 기준 타입(417), sorting 기준 타입(418), unique 타입(419)의 로우키 항목을 선택 받기 위한 UI(410)가 도시 되어 있다. 각 타입의 로우키 항목은 복수개가 선택 될 수 있다. 각 타입의 로우키 항목을 설정하기 위하여는 설정 버튼(411)을 누르고, 타입의 로우키 항목을 새로 추가하기 위하여는 추가 버튼(412)을 누르면 된다.

도 22는 도 21에서 설정 버튼(411)을 눌렀을 때 디스플레이 되는 UI(420)이다. '객체' 테이블에 대하여 로우키 설계를 하는 상황이라면, '객체' 테이블에 포함 된 칼럼 항목의 CQ 리스트(421)가 표시 되고, 사용자는 커서(422)를 이동하여 특정 타입의 로우키 항목을 선택할 수 있다. 이 때, 로우키 항목을 선택함에 있어서, 선택한 로우키 항목을 칼럼에서 제외(423)하던지, 선택한 로우키 항목을 칼럼에 잔류(424)시킬 수 있다. 또한, 원하는 로우키 항목이 칼럼에 존재하지 않는 경우, 칼럼에 존재하지 않는 항목을 신설하여 로우키 항목으로 사용할 수도 있다(425). 도 23은 로우키 설계가 마무리 된 상태를 예시한다.

도 23의 UI에서 "다음" 버튼을 누르는 경우, 도 24의 칼럼 패밀리 설정 UI(430)가 디스플레이 된다. 도 24는 로우키 설계가 완료 됨에 따라, NoSQL 물리 ERD에 대한 칼럼 항목이 최종 확정 된 이후, 칼럼 항목들을 서로 다른 칼럼 패밀리(Column Family)로 분할하기 위한, 본 발명의 일 실시예에 따른 NoSQL 모델 생성 방법 수행 시 제공 될 수 있는 UI의 예시이다. 사용자는 경계 바(431)를 위 아래로 움직이는 것(433, 432)에 의하여 칼럼 패밀리(434, 435)를 구성할 수 있다. 칼럼 패밀리 설정 UI(430)는, 칼럼 패밀리의 개수를 증가시키기 위한 버튼(436)도 제공한다.

도 24의 UI에서 "다음" 버튼을 누르는 경우, 도 25의 인덱스 설계 UI(510)가 디스플레이 된다. NoSQL 테이블은 그 테이블에 적용 되는 쿼리를 반영하여 테이블을 모델링 하는 것이 중요하다. 따라서, 쿼리의 검색 조건을 로우키 구성에 반영하는 실시예에 대하여 이미 설명한 바 있다. 하지만, 로우키를 이용하여 쿼리를 처리하는 것이 비효율적인 상황이 발생할 수 있다. 본 실시예는, 사용자가 손쉽게 쿼리를 반영한 인덱스 테이블을 생성할 수 있도록 돕는다.

도 25의 UI(510)를 통하여, NoSQL 테이블에 적용 될 쿼리의 검색 조건으로 사용 되는 항목과 조회 대상인 항목을, 상기 NoSQL 테이블의 합성 로우키(Rowkey)를 구성하는 각 로우키 항목 및 각 칼럼(Column) 항목(511) 중에서 선택 받는다. 쿼리의 검색 조건, 조회 항목에 대한 입력이 완성 되면 "완성" 버튼(512)을 눌러서, 쿼리를 등록 할 수 있다. 도 24에는 2개의 쿼리가 이미 등록 된 상황이 도시 되어 있다. 이미 등록 된 쿼리는 수정(513a) 및 삭제(513b)가 가능하다. V유형코드, 시작년도구분값, 시작일시를 각각 검색 조건으로 가지고, 객체유형ID, 아이템ID, 객체ID, 종료일시를 각각 조회 항목으로 가지는 쿼리 3를 새롭게 등록한다고 가정하자.

"다음" 버튼(514)을 누르면, 등록 된 쿼리와 '객체' 테이블의 로우키 항목 사이의 적합성을 평가한다. 각 쿼리의 검색 조건 항목이 합성 로우키의 제1 로우키 항목 내지 제n(단, n은 2이상, 합성 로우키를 구성하는 로우키 항목의 개수 이하의 자연수) 로우키 항목과 일치하는 경우에 한하여 적합성이 인정된다. 예를 들어, 상기 합성 로우키를 구성하는 로우키 항목이 순서대로 A,B,C,D,E 인 경우, 검색 조건 항목이 A,B,C 인 경우는 검색 조건 항목이 상기 합성 로우키의 제1 내지 제3 로우키 항목과 일치하고, 그 순서도 일치하므로 상기 적합성이 인정되는 경우이다. 상기 합성 로우키를 구성하는 로우키 항목이 순서대로 A,B,C,D,E 인 경우, 검색 조건 항목이 A,C,B 인 경우는 검색 조건 항목이 상기 합성 로우키의 제1 내지 제3 로우키 항목과 일치하지만, 그 순서가 일치하지 않아 상기 적합성이 인정되지 않는다. 상기 적합성은 쿼리의 검색 조건 항목이 로우키 항목 및 로우키 항목의 순서를 활용하기에 적합한지 여부를 가리킨다.

적합성이 인정되는 경우, 해당 쿼리는 로우키를 이용하여 효율적으로 검색이 가능한 것으로 평가 된다. 반면에, 적합성이 인정 되지 않는 경우, 상기 선택 받은 조회 대상 항목 중 적어도 일부(칼럼)와 쿼리의 검색 조건 항목(로우키)으로 구성 되는 인덱스 테이블을 자동 생성한다.

도 23의 객체 테이블 로우키 항목 설계 결과를 참조하여, 쿼리 별 적합성 평가 결과를 설명한다. 쿼리 1의 경우, 검색 조건이 객체 테이블의 제1 로우키 항목 내지 제5 로우키 항목과 일치한다. 따라서, 쿼리 1에 대하여는 쿼리-로우키 간 적합성이 인정된다. 쿼리 2의 경우, 검색 조건이 객체 테이블의 제1 로우키 항목 내지 제3 로우키 항목과 일치한다. 따라서, 쿼리 2에 대하여도 쿼리-로우키 간 적합성이 인정된다. 반면에, 쿼리 3에 대하여는 쿼리-로우키 간 적합성이 인정되지 않는다. 쿼리 3의 검색 조건은 제1 로우키, 제2 로우키 및 제6 로우키로 구성 되어 있기 때문이다. 즉, 객체 테이블의 합성 로우키를 활용하여 '시작일시'를 검색 조건으로 구현하려면, 제3 로우키 내지 제5 로우키도 알아야 한다.

도 26의 UI(520)에는, 쿼리 3에 대하여 인덱스 테이블이 필요하다는 점이 안내 되고 있다. 그리고, 도 26의 UI(520)는, 조회 항목 중 값의 변화가 있는 항목이 존재하는지를 질의한다. 조회 항목 중 값의 변화가 있는 항목이 존재하지 않는 경우(521), 값의 적합성이 깨어지는 경우가 발생하지 않을 것이다. 따라서, 이 경우에는 조회 항목 모두를 칼럼으로 가지는 covering 인덱스 테이블이 생성된다. 도 27에는 객체 테이블의 covering 인덱스 테이블(530)이 도시된다.

반면에, 조회 항목 중 값의 변화가 있는 항목이 존재한다면, 값의 적합성이 깨어지는 경우가 발생할 수 있다. 따라서, 조회 항목은 객체 테이블에 대한 join 연산을 구현하여 얻어와야 한다. 다만, 이 경우에도 칼럼 패밀리에 적어도 하나의 CQ는 존재해야 하므로, 쿼리의 조회 항목 중 임의로 선택 된 하나의 항목을 칼럼으로 가지는 non-covering 인덱스 테이블이 생성된다. 도 27에는 객체 테이블의 non-covering 인덱스 테이블(540)이 도시 된다.

도 27은 도 2에 도시 된 논리 ERD를 입력 받아, 도 3 내지 24를 참조하여 설명 된 실시예를 수행한 결과로 출력 되는 NoSQL 물리 ERD의 최종본 중, '객체' 테이블에 대한 인덱스 테이블의 예시이고, 도 28은 NoSQL 물리 ERD의 최종본 중 NoSQL 테이블을 도시한 것이다. 본 실시예에서, NoSQL 물리 ERD의 최종본은 사용자의 확인 및 검토를 위해 디스플레이 되거나, 기록을 위해 기 지정 된 포맷으로 스토리지 장치에 저장 될 수 있다. 상기 포맷은, 예를 들어 XML(eXtensible Markup Language) 기반의 데이터 포맷이거나, JSON(JavaScript Object Notation) 기반의 데이터 포맷일 수 있다.

또한, 일 실시예에서, 상기 산출 된 NoSQL 물리 ERD에 따른 NoSQL 테이블 및 인덱스 테이블을 자동으로 생성하기 위한 스크립트가 자동으로 생성될 수 있다. 이 때, 사용자로부터 각 테이블 별, <BLOCKCACHE>, <BLOOMFILTER>, <COMPRESSION> 옵션에 대한 입력 값이 입력 될 수 있다. <BLOCKCACHE> 옵션에 대한 선택값 1은 true/false이고, <BLOOMFILTER> 옵션에 대한 선택값 2는 ROW,ROWCOL,NONE이고, <COMPRESSION> 옵션에 대한 선택값 3은 설치 된 압축 알고리즘이다. 테이블 생성을 위한 스크립트의 예시는 아래와 같다. 이 때, 테이블ID, 칼럼 패밀리 명칭(ColumnFamily#n)은 NoSQL 물리 ERD에서 자동 추출 된다.

CREATE '<테이블ID>', {NAME => '<ColumnFamily#n>', BLOCKCACHE => 선택값1, BLOOMFILTER => '선택값2', COMPRESSION => '선택값3'}

도 1 내지 24를 참조하여 설명 된 실시예로부터 아래의 응용 실시예들이 추가적으로 도출 될 수 있다.

제1 응용 실시예에 따른 NoSQL 모델 생성 방법은, NoSQL 테이블의 로우키(Rowkey) 정보 및 칼럼(column) 정보를 얻는 단계와, 상기 로우키 정보를 분석하고, 상기 로우키를 구성하는 각 항목을 밑줄 처리하는 단계와, 상기 칼럼 정보에 기반하여 각 칼럼의 CQ 타입을 판정하는 단계와, 상기 판정 결과 CQ 타입이 static(static) CQ인 경우 상기 CQ를 따옴표로 묶고, CQ 타입이 dynamic(dynamic) CQ인 경우 상기 CQ를 그대로 표시하며, CQ 타입이 nested CQ인 경우, 상기 CQ에 nested CQ임을 가리키는 기 지정 된 표기를 부가하는 단계와, 상기 칼럼 정보에 기반하여 각 칼럼의 밸류가 어레이(array) 타입인지 여부를 판정하고, 어레이 타입의 밸류는 기호 '[', ']'를 밸류 명칭의 양끝에 추가하는 단계와, 상기 각 칼럼 및 상기 로우키를 구성하는 각 항목에 대하여, CQ를 가리키는 변수 명 및 그에 대응되는 밸류를 가리키는 변수 명을 포함하는 NoSQL 물리 ERD를 디스플레이하거나 저장하는 단계를 포함할 수 있다.

상기 제1 응용 실시예는, 예를 들어 도 29에 도시된 NoSQL 모델 생성 장치에 의하여 수행 될 수 있다.

제2 응용 실시예에 따른 NoSQL 기반 검색 방법은, 리젼(region) 분할의 기준이 되는 리젼 분할 타입의 로우키 항목, 쿼리의 검색 기준으로 사용 되는 검색 타입의 로우키 항목 및 sorting의 기준으로 사용 되는 sorting 타입의 로우키 항목을 순서대로 연결한 합성 로우키(compound rowkey)를 생성하는 단계와, 상기 합성 로우키와 하나 이상의 칼럼(column)을 포함하는 NoSQL 테이블을 생성하는 단계와, 상기 NoSQL 테이블을 가리키는 데이터를 저장하는 단계와, 상기 NoSQL 테이블에 대한 쿼리를 입력 받는 단계와, 상기 합성 로우키를 기준으로 상기 쿼리에서 요구 된 조회 항목을 검색하는 단계와, 상기 검색 결과를 출력하는 단계를 포함한다.

상기 제2 응용 실시예는, 예를 들어 NoSQL 기반의 데이터베이스 관리 서비스를 제공하는 장치에 의하여 수행 될 수 있다.

상기 합성 로우키를 생성하는 단계는 상기 sorting 타입의 로우키 항목 다음으로 unique 타입의 로우키 항목을 더 연결하여 상기 합성 로우키를 생성하는 단계를 포함하고, 상기 unique 타입의 로우키 항목은 상기 합성 로우키의 uniqueness를 확보하기 위한 고유의 식별자를 가리키는 것일 수 있다.

제3 응용 실시예에 따른 NoSQL 테이블의 스케일-아웃 방법은, 리젼(region) 분할의 기준이 되는 리젼 분할 타입의 로우키 항목, 쿼리의 검색 기준으로 사용 되는 검색 타입의 로우키 항목 및 sorting의 기준으로 사용 되는 sorting 타입의 로우키 항목을 순서대로 연결한 합성 로우키(compound rowkey)를 생성하는 단계와, 상기 합성 로우키와 하나 이상의 칼럼(column)을 포함하는 NoSQL 테이블을 생성하는 단계와, 상기 NoSQL 테이블을 가리키는 데이터를 제1 스토리지에 저장하는 단계와, 상기 NoSQL 테이블을 상기 합성 로우키를 기준으로 복수의 리젼으로 분할하는 단계와, 상기 복수의 리젼들 중 적어도 일부를 상기 제1 스토리지와 다른 제2 스토리지에 저장하는 단계를 포함한다. 상기 제1 스토리지와 상기 제2 스토리지는, 각각 서로 다른 물리 서버에 구비 된 것일 수 있다. 상기 제1 스토리지와 상기 제2 스토리지는, 동일한 물리 서버 내의 서로 다른 스토리지 장치를 의미할 수도 있다. 예를 들어, 상기 제1 스토리지와 상기 제2 스토리지는, 레이드 스토리지에 구비 된 복수의 스토리지 장치 중 서로 다른 스토리지 장치를 가리킬 수 있다. 상기 제1 스토리지와 상기 제2 스토리지는, 동일한 물리 서버의 동일한 스토리지 장치 내의 서로 다른 스토리지 영역을 가리킬 수도 있다. 예를 들어, 상기 제1 스토리지와 상기 제2 스토리지는, 동일한 물리 서버의 동일한 스토리지 장치 내의 서로 다른 파티션을 가리킬 수도 있다.

상기 제3 응용 실시예는, 예를 들어 스케일-아웃 기능을 지원하고 NoSQL 기반의 데이터베이스 관리 서비스를 제공하는 장치에 의하여 수행 될 수 있다.

상기 리젼 분할 타입의 로우키 항목은, 통합 기준 리젼 분할 타입의 로우키 항목과, 상기 통합 기준 리젼 분할 타입의 로우키 항목 다음으로 연결되는 보관 기준 리젼 분할 타입의 로우키 항목을 포함하고, 상기 통합 기준 리젼 분할 타입의 로우키 항목은, 리젼 분할의 제1 기준이 되는 항목이고, 상기 보관 기준 리젼 분할 타입의 로우키 항목은, 데이터 보관 주기를 가리키는 항목일 수 있다.

상기 분할 된 상기 리젼을 각각 서로 다른 스토리지에 저장하는 단계는, 상기 분할 된 리젼 중, 삭제 대상인 리젼을 결정하는 단계와, 상기 결정 된 삭제 대상 리젼의 데이터는 스토리지에 저장하지 않고 삭제하는 단계를 포함할 수 있다. 일 실시예에서, 리젼의 분할 후 바로 리젼 삭제가 수행될 수도 있고, 리젼의 분할과 리젼의 삭제는 독립적으로 수행될 수도 있다.

상기 분할 된 상기 리젼을 각각 서로 다른 스토리지에 저장하는 단계는, 상기 분할 된 리젼 중, 삭제 대상인 리젼을 결정하는 단계와, 상기 결정 된 삭제 대상 리젼의 데이터는 삭제 대상 데이터 저장용 스토리지에 저장하는 단계를 포함할 수도 있다.

상기 리젼 분할 타입의 로우키 항목은, 상기 보관 기준 리젼 분할 타입의 로우키 항목 다음으로 연결되는 확장 기준 리젼 분할 타입의 로우키 항목을 더 포함하고, 상기 확장 기준 리젼 분할 타입은, 분할 후 리젼 개수를 결정할 때 사용되는 항목일 수 있다.

제4 응용 실시예에 따른 NoSQL 기반 검색 방법은, NoSQL 테이블에 적용 될 쿼리의 검색 조건으로 사용 되는 항목과 조회 대상인 항목을, 상기 NoSQL 테이블의 합성 로우키(Rowkey)를 구성하는 각 로우키 항목 및 각 칼럼(Column) 항목 중에서 선택 받는 단계와, 상기 선택 받은 검색 조건 항목이 상기 합성 로우키의 로우키 항목 및 로우키 항목의 순서를 활용하기에 적합하지 않는 경우, 상기 선택 받은 조회 대상 항목 중 적어도 일부와 쿼리의 검색 조건 항목으로 구성 되는 인덱스 테이블을 생성하는 단계와, 상기 NoSQL에 대한 쿼리의 처리를 위해, 상기 인덱스 테이블을 조회하는 단계를 포함할 수 있다.

상기 제4 응용 실시예는, 인덱스 테이블 기반의 쿼리 처리 기능을 지원하는 NoSQL 기반의 데이터베이스 관리 서비스를 제공하는 장치에 의하여 수행 될 수 있다.

상기 인덱스 테이블을 생성하는 단계는, 쿼리의 조회 대상 항목 중 값의 변화가 있는 항목의 존재 여부를 질의하는 UI를 제공하는 단계와, 상기 UI를 통해 값의 변화가 있는 항목이 존재하는 것을 가리키는 사용자 입력이 입력 되는 경우, non-covering 인덱스 테이블을 생성하는 단계와, 상기 UI를 통해 값의 변화가 있는 항목이 존재하지 않는 것을 가리키는 사용자 입력이 입력 되는 경우, covering 인덱스 테이블을 생성하는 단계를 포함할 수 있다.

지금까지 도 1 내지 도 28을 참조하여 설명된 본 발명의 실시예와, 상기 제1 내지 제4 응용 실시예에 따른 방법들은 컴퓨터가 읽을 수 있는 코드로 구현된 컴퓨터 프로그램의 실행에 의하여 수행될 수 있다. 상기 컴퓨터 프로그램은 인터넷 등의 네트워크를 통하여 제1 컴퓨팅 장치로부터 제2 컴퓨팅 장치에 전송되어 상기 제2 컴퓨팅 장치에 설치될 수 있고, 이로써 상기 제2 컴퓨팅 장치에서 사용될 수 있다. 상기 제1 컴퓨팅 장치 및 상기 제2 컴퓨팅 장치는, 서버 장치, 데스크탑 피씨와 같은 고정식 컴퓨팅 장치, 노트북, 스마트폰, 태블릿 피씨와 같은 모바일 컴퓨팅 장치 및 스마트 와치, 스마트 안경과 같은 웨어러블 컴퓨팅 장치를 모두 포함한다.

이하, 도 29를 참조하여, 발명의 다른 실시예에 따른 NoSQL 모델 생성 장치의 구성 및 동작을 설명한다. 도 29에 도시된 바와 같이, 본 실시예에 따른 NoSQL 모델 생성 장치(1000)는 하나 이상의 프로세서(1001), 네트워크 인터페이스(1003), 스토리지(1005) 및 메모리(RAM)(1009)를 포함할 수 있다. 일 실시예에서, NoSQL 모델 생성 장치(1000)는 디스플레이(1011)를 더 포함할 수 있다. 프로세서(1001), 네트워크 인터페이스(1003), 스토리지(1005), 메모리(RAM)(1009) 및 디스플레이(1011)는 시스템 버스(1007)를 통하여 데이터를 송수신한다.

프로세서(1001)는 메모리(1009)에 로드 된 컴퓨터 프로그램을 실행하고, 메모리(1009)는 상기 컴퓨터 프로그램을 스토리지(1005)에서 로드(load) 한다. 상기 컴퓨터 프로그램은, 논리 ERD 분석 오퍼레이션(1090), 논리 ERD 디자인 오퍼레이션(1091), NoSQL 물리 ERD 생성 오퍼레이션(1092), NoSQL 테이블 생성 오퍼레이션(1093) 및 NoSQL 클라이언트(1094)를 포함할 수 있다.

논리 ERD 분석 오퍼레이션(1090)은 스토리지(1005)에 저장 된 논리 ERD 또는 네트워크 인터페이스(1003)를 통해 외부 장치로부터 수신한 논리 ERD를 임포트 하고, 임포트 된 논리 ERD에 포함 된 각 엔터티에 대한 정보를 식별하고, 각 엔터티 사이의 참조 관계를 분석한다.

논리 ERD 디자인 오퍼레이션(1091)은 논리 ERD를 직접 모델링 할 수 있는 디자인 툴을 제공한다.

NoSQL 물리 ERD 생성 오퍼레이션(1092)은 상기 논리 ERD에 포함 된 각 엔터티(entity) 간 참조 관계에 대한 정보 및 상기 논리 ERD에 포함 된 각 엔터티의 속성이 NoSQL에서만 지원되는 타입을 가지는지 여부에 대한 정보를 포함하는 논리 ERD 보완 정보를 사용자 입력 받는 오퍼레이션과, 상기 논리 ERD에 포함 된 각 엔터티 중 NoSQL 테이블 생성 대상 엔터티를, 로우키(Rowkey) 항목과 칼럼(column) 항목을 포함하는 NoSQL 물리 ERD 템플릿에 반영하여, NoSQL 물리 ERD를 생성하되, PK(Primary Key) 속성은 로우키 항목에 배치하고, non-PK 속성은 칼럼 항목에 배치하는 오퍼레이션과, 상기 NoSQL 물리 ERD에 상기 논리 ERD 보완 정보에 따른 변환을 적용하는 오퍼레이션과, 상기 NoSQL 물리 ERD의 상기 칼럼 항목에 포함 된 항목들 중 로우키에 포함 될 칼럼을 사용자로부터 선택 받고, 선택 된 칼럼을 상기 NoSQL 물리 ERD의 상기 로우키 항목에 포함시키는 로우키 설계 오퍼레이션을 포함한다.

NoSQL 물리 ERD 생성 오퍼레이션(1092)은 NoSQL 테이블에 적용 될 쿼리의 검색 조건으로 사용 되는 항목과 조회 대상인 항목을, 상기 NoSQL 테이블의 합성 로우키(Rowkey)를 구성하는 각 로우키 항목 및 각 칼럼(Column) 항목 중에서 선택 받고, 상기 선택 받은 검색 조건 항목이 상기 합성 로우키의 로우키 항목 및 로우키 항목의 순서를 활용하기에 적합하지 않는 경우, 상기 선택 받은 조회 대상 항목 중 적어도 일부와 쿼리의 검색 조건 항목으로 구성 되는 인덱스 테이블을 생성하는 오퍼레이션을 더 포함할 수 있다.

NoSQL 물리 ERD 생성 오퍼레이션(1092)은 논리 ERD(1050)으로부터 생성한 NoSQL 물리 ERD(1051)를 XML 기반 포맷 또는 JSON 기반 포맷으로 패키징 하여 스토리지(1005)에 저장할 수 있다. NoSQL 물리 ERD 생성 오퍼레이션(1092)은 논리 ERD(1050)으로부터 생성한 NoSQL 물리 ERD(1051)를 다이어그램 그래픽 형태로 디스플레이(1011)를 통하여 디스플레이 할 수 있다.

NoSQL 테이블 생성 오퍼레이션(1093)은, NoSQL 물리 ERD 생성 오퍼레이션(1092)에 의하여 생성 된 NoSQL 물리 ERD를 실제로 생성하기 위한 스크립트를 자동 생성한다.

NoSQL 클라이언트(1094)는, NoSQL 테이블 생성 오퍼레이션(1093)에 의하여 생성 된 스크립트를, 네트워크 인터페이스(1003)를 통하여 연결 된 NoSQL 기반 데이터베이스 관리 서비스 장치(3000)에 제공하기 위한 인터페이스를 제공한다.

본 실시예에 따른 NoSQL 모델 생성 장치(1000)는, 예를 들어 NoSQL 데이터베이스 클라이언트 장치일 수 있다. 예를 들어, 데스크탑 컴퓨터, PDA (Personal Digital Assistants), 포터블(portable) 컴퓨터, 무선 전화기(wireless phone), 스마트폰(smart phone), 태블릿 컴퓨터로 구성 될 수 있다.

본 실시예에 따른 NoSQL 모델 생성 장치(1000)는, 관계형 데이터베이스 모델에 따른 논리 ERD를 직접 모델링 하거나 외부 논리 ERD 데이터를 임포트 한 후, NoSQL 물리 ERD 모델로 변환하며, 변환 된 NoSQL 물리 ERD 모델을 생성하는 스크립트를 생성하여 외부의 NoSQL 서버에 자동 제공함으로써, 관계형 데이터베이스 모델을 이용하여 NoSQL 데이터베이스를 구축하는 전 과정을 가이드 할 수 있다.

이하, 도 30을 참조하여, 발명의 다른 실시예에 따른 NoSQL 기반 데이터베이스 서비스 장치의 구성 및 동작을 설명한다. 도 30에 도시된 바와 같이, 본 실시예에 따른 NoSQL 기반 데이터베이스 서비스 장치(2000)는 하나 이상의 프로세서(2001), 네트워크 인터페이스(2003), 스토리지(2005) 및 메모리(RAM)(2009)를 포함할 수 있다. 프로세서(2001), 네트워크 인터페이스(2003), 스토리지(2005), 메모리(RAM)(2009) 및 디스플레이(2011)는 시스템 버스(2007)를 통하여 데이터를 송수신한다.

프로세서(2001)는 메모리(2009)에 로드 된 컴퓨터 프로그램을 실행하고, 메모리(2009)는 상기 컴퓨터 프로그램을 스토리지(2005)에서 로드(load) 한다. 상기 컴퓨터 프로그램은, 논리 ERD 분석 오퍼레이션(2090), 논리 ERD 디자인 오퍼레이션(2091), NoSQL 물리 ERD 생성 오퍼레이션(2092), NoSQL 테이블 생성 오퍼레이션(2093) 및 NoSQL 엔진(2094)을 포함할 수 있다.

논리 ERD 분석 오퍼레이션(2090)은 스토리지(2005)에 저장 된 논리 ERD 또는 네트워크 인터페이스(2003)를 통해 터미널 장치로부터 수신한 논리 ERD를 임포트 하고, 임포트 된 논리 ERD에 포함 된 각 엔터티에 대한 정보를 식별하고, 각 엔터티 사이의 참조 관계를 분석한다.

논리 ERD 디자인 오퍼레이션(2091)은 논리 ERD를 직접 모델링 할 수 있는 디자인 툴을 제공한다. 상기 디자인 툴은 네트워크 인터페이스(2003)를 통해 터미널 디바이스에 제공 되는 UI 및 상기 UI를 통해 입력 된 사용자 입력을 처리하는 로직으로 구성 된다.

NoSQL 물리 ERD 생성 오퍼레이션(2092)은 상기 논리 ERD에 포함 된 각 엔터티(entity) 간 참조 관계에 대한 정보 및 상기 논리 ERD에 포함 된 각 엔터티의 속성이 NoSQL에서만 지원되는 타입을 가지는지 여부에 대한 정보를 포함하는 논리 ERD 보완 정보를 사용자 입력 받는 오퍼레이션과, 상기 논리 ERD에 포함 된 각 엔터티 중 NoSQL 테이블 생성 대상 엔터티를, 로우키(Rowkey) 항목과 칼럼(column) 항목을 포함하는 NoSQL 물리 ERD 템플릿에 반영하여, NoSQL 물리 ERD를 생성하되, PK(Primary Key) 속성은 로우키 항목에 배치하고, non-PK 속성은 칼럼 항목에 배치하는 오퍼레이션과, 상기 NoSQL 물리 ERD에 상기 논리 ERD 보완 정보에 따른 변환을 적용하는 오퍼레이션과, 상기 NoSQL 물리 ERD의 상기 칼럼 항목에 포함 된 항목들 중 로우키에 포함 될 칼럼을 사용자로부터 선택 받고, 선택 된 칼럼을 상기 NoSQL 물리 ERD의 상기 로우키 항목에 포함시키는 로우키 설계 오퍼레이션을 포함한다.

NoSQL 물리 ERD 생성 오퍼레이션(2092)은 네트워크 인터페이스(2003)를 통해 터미널 디바이스에 사용자 입력 UI를 제공하고, 상기 사용자 입력 UI를 통해 입력 된 사용자 입력을 처리한다.

NoSQL 물리 ERD 생성 오퍼레이션(2092)은 NoSQL 테이블에 적용 될 쿼리의 검색 조건으로 사용 되는 항목과 조회 대상인 항목을, 상기 NoSQL 테이블의 합성 로우키(Rowkey)를 구성하는 각 로우키 항목 및 각 칼럼(Column) 항목 중에서 선택 받고, 상기 선택 받은 검색 조건 항목이 상기 합성 로우키의 로우키 항목 및 로우키 항목의 순서를 활용하기에 적합하지 않는 경우, 상기 선택 받은 조회 대상 항목 중 적어도 일부와 쿼리의 검색 조건 항목으로 구성 되는 인덱스 테이블을 생성하는 오퍼레이션을 더 포함할 수 있다.

NoSQL 물리 ERD 생성 오퍼레이션(2092)은 논리 ERD로부터 생성한 NoSQL 물리 ERD(1051)를 XML 기반 포맷 또는 JSON 기반 포맷으로 패키징 하여 스토리지(2005)에 저장하거나, 네트워크 인터페이스(2003)를 통해 터미널 장치에 송신할 수 있다. NoSQL 물리 ERD 생성 오퍼레이션(1092)은 논리 ERD(1050)으로부터 생성한 NoSQL 물리 ERD(1051)를 다이어그램 그래픽 형태로 디스플레이(1011)를 통하여 디스플레이 할 수 있다.

NoSQL 테이블 생성 오퍼레이션(2093)은, NoSQL 물리 ERD 생성 오퍼레이션(2092)에 의하여 생성 된 NoSQL 물리 ERD를 실제로 생성하기 위한 스크립트를 자동 생성하고, 생성 된 스크립트를 NoSQL 엔진(2094)에 제공한다. NoSQL 엔진(2094)은 스토리지(2005)에 저장 되는 NoSQL 테이블 데이터(2052)에 상기 스크립트에 따른 NoSQL 테이블을 생성한다.

본 실시예에 따른 NoSQL 기반 데이터베이스 서비스 장치(2000)는, NoSQL 기반 데이터베이스 조회, 데이터 삽입, 데이터 수정 등의 서비스를 제공할 뿐만 아니라, RDB 기반 모델링 결과를 NoSQL 모델링으로 변환하는 과정을 가이드하고, 그 결과 생성 된 NoSQL 물리 ERD를 NoSQL 테이블로 실제 생성해주는 동작을 추가적으로 수행한다.

이상 첨부된 도면을 참조하여 본 발명의 실시예들을 설명하였지만, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적인 것이 아닌 것으로 이해해야만 한다.

Claims

NoSQL 모델 생성 장치가, 관계형 데이터베이스 모델에 따른 논리 ERD(Entity-Relationship Diagram)를 임포트 하는 단계;
상기 NoSQL 모델 생성 장치가, 상기 논리 ERD에 포함 된 각 엔터티(entity) 간 참조 관계에 대한 정보 및 상기 논리 ERD에 포함 된 각 엔터티의 속성이 NoSQL에서만 지원되는 타입을 가지는지 여부에 대한 정보를 포함하는 논리 ERD 보완 정보를 사용자 입력 받는 단계;
상기 NoSQL 모델 생성 장치가, 상기 논리 ERD에 포함 된 각 엔터티 중 NoSQL 테이블 생성 대상 엔터티를, 로우키(Rowkey) 항목과 칼럼(column) 항목을 포함하는 NoSQL 물리 ERD 템플릿에 반영하여, NoSQL 물리 ERD를 생성하되, PK(Primary Key) 속성은 로우키 항목에 배치하고, non-PK 속성은 칼럼 항목에 배치하는 단계;
상기 NoSQL 모델 생성 장치가, 상기 NoSQL 물리 ERD에 상기 논리 ERD 보완 정보에 따른 변환을 적용하는 단계; 및
상기 NoSQL 모델 생성 장치가, 상기 NoSQL 물리 ERD를 디스플레이 하거나 기 지정 된 포맷으로 저장하는 단계를 포함하는,
NoSQL 모델 생성 방법.
제1 항에 있어서,
상기 논리 ERD 보완 정보를 사용자 입력 받는 단계는,
대상 엔터티에 포함 될 nested 엔터티를 사용자 입력 받는 단계를 포함하고,
상기 논리 ERD 보완 정보에 따른 변환을 적용하는 단계는,
상기 nested 엔터티의 PK 속성을 가리키는 dynamic CQ(Column Qualifier)와, 상기 nested 엔터티의 non-PK 속성을 가리키는 밸류(value)를 포함하는 칼럼을 상기 NoSQL 물리 ERD에 자동으로 추가하는 단계를 포함하는,
NoSQL 모델 생성 방법.
제2 항에 있어서,
상기 자동으로 추가하는 단계는,
상기 nested 엔터티의 PK 속성이 제1 PK 및 제2 PK를 포함하는 경우, 상기 제1 PK를 가리키는 제1 dynamic CQ를 포함하는 제1 칼럼을 상기 NoSQL 물리 ERD에 자동으로 추가하고, 상기 제2 PK를 가리키는 제2 dynamic CQ를 포함하는 제2 칼럼을 상기 NoSQL 물리 ERD에 자동으로 더 추가하는 단계를 포함하되,
상기 제1 dynamic CQ와 상기 제2 dynamic CQ는 하나의 복합 CQ를 구성하는,
NoSQL 모델 생성 방법.
제3 항에 있어서,
상기 자동으로 추가하는 단계는,
상기 nested 엔터티의 non-PK 속성이 제1 non-PK 속성 및 제2 non-PK 속성을 포함하는 경우, 상기 제1 칼럼에 상기 제1 non-PK 속성을 가리키는 제1 밸류를 추가하고, 상기 제2 칼럼에 상기 제2 non-PK 속성을 가리키는 제2 밸류를 추가하는 단계를 더 포함하되,
상기 제1 밸류와 상기 제2 밸류는 하나의 복합 밸류를 구성하는,
NoSQL 모델 생성 방법.
제2 항에 있어서,
상기 대상 엔터티에 포함 될 nested 엔터티를 사용자 입력 받는 단계는,
상기 사용자 입력에 따라 선정 된 nested 엔터티에 포함 된 속성 중 일부만 병합 대상 속성으로 선정하는 사용자 입력을 더 받는 단계를 포함하고,
상기 NoSQL 물리 ERD에 자동으로 추가하는 단계는,
상기 nested 엔터티에 포함 된 속성 중 상기 병합 대상 속성 만, 상기 NoSQL 물리 ERD에 자동으로 추가되는 칼럼에 반영하는 단계를 포함하는,
NoSQL 모델 생성 방법.
제1 항에 있어서,
상기 논리 ERD 보완 정보를 사용자 입력 받는 단계는,
대상 엔터티에 포함 될 nested 엔터티를 사용자 입력 받는 단계를 포함하고,
상기 논리 ERD 보완 정보에 따른 변환을 적용하는 단계는,
상기 nested 엔터티의 non-PK 속성이 존재하는지 여부를 판정하는 단계;
상기 nested 엔터티의 non-PK 속성이 존재하지 않는 경우, 상기 nested 엔터티가 참조하는 엔터티 중 상기 대상 엔터티가 아닌 타 엔터티의 순번을 가리키는 dynamic CQ와, 상기 타 엔터티의 로우키를 가리키고, 상기 dynamic CQ에 대응하는 밸류를 포함하는 칼럼을, 상기 NoSQL 물리 ERD에 자동으로 추가하는 단계를 포함하는,
NoSQL 모델 생성 방법.
제1 항에 있어서,
상기 논리 ERD를 임포트 하는 단계는,
상기 임포트 된 논리 ERD를 분석하여, 각 엔터티 간의 길이(length)를 결정하는 단계;
상기 논리 ERD 보완 정보를 사용자 입력 받는 단계는,
대상 엔터티와 기 지정 된 한계치 이내의 길이로 연결 된 후보 엔터티를 결정하는 단계; 및
상기 후보 엔터티 중에서 상기 대상 엔터티에 포함 될 nested 엔터티를 선택 받는 UI를 제공하는 단계를 포함하는,
NoSQL 모델 생성 방법.
제7 항에 있어서,
상기 한계치는 2인,
NoSQL 모델 생성 방법.
제1 항에 있어서,
상기 논리 ERD 보완 정보를 사용자 입력 받는 단계는,
대상 엔터티를 참조하는 참조(referencing) 엔터티를 사용자 입력 받는 단계;
상기 사용자 입력에 따른 참조 엔터티 중, 속성의 값이 빈번하게 변경 되는 link 엔터티를 사용자 입력 받는 단계; 및
상기 참조 엔터티에서 상기 링크 대상 엔터티를 제외 한 나머지 엔터티 중에서, 상기 대상 엔터티에 포함 될 nested 엔터티를 사용자 입력 받는 단계를 포함하는,
NoSQL 모델 생성 방법.
제9 항에 있어서,
상기 논리 ERD 보완 정보를 사용자 입력 받는 단계는,
상기 참조 엔터티에서 상기 링크 대상 엔터티 및 상기 nested 엔터티를 제외 한 나머지 엔터티를 denormalize 엔터티로 결정 하는 단계; 및
상기 denormalize 엔터티에 포함 된 속성 중 상기 대상 엔터티에 포함 된 속성을 제외한 나머지 속성을 대상으로 비정규화 대상 속성을 선택 받기 위한 UI를 제공 하는 단계를 포함하는,
NoSQL 모델 생성 방법.
제1 항에 있어서,
상기 논리 ERD 보완 정보를 사용자 입력 받는 단계는,
상기 논리 ERD의 각 엔터티에 포함 된 속성 중, dynamic CQ로 변환 될 제1 속성을 선택 받고, 상기 dynamic CQ에 대응 하는 밸류로 변환 될 제2 속성을 선택 받기 위한 UI를 제공 하는 단계를 포함하고,
상기 논리 ERD 보완 정보에 따른 변환을 적용하는 단계는,
상기 제1 속성의 CQ와 상기 제2 속성의 밸류을 포함하는 칼럼 항목을 구성하는 단계를 포함하는,
NoSQL 모델 생성 방법.
제11 항에 있어서,
상기 UI를 제공 하는 단계는,
상기 제1 속성을 포함하는 엔터티와 다른 엔터티에서 상기 제2 속성을 선택 받기 위한 UI를 제공하는 단계를 포함하는,
NoSQL 모델 생성 방법.
제1 항에 있어서,
상기 NoSQL 모델 생성 장치가, 상기 NoSQL 물리 ERD의 상기 칼럼 항목에 포함 된 항목들 중 로우키에 포함 될 칼럼을 사용자로부터 선택 받고, 선택 된 칼럼을 상기 NoSQL 물리 ERD의 상기 로우키 항목에 포함시키는 로우키 설계 단계를 더 포함하는,
NoSQL 모델 생성 방법.
제13 항에 있어서,
상기 로우키 설계 단계는,
리젼(region) 분할의 기준이 되는 리젼 분할 타입의 제1 로우키 칼럼을 선택 받는 단계;
쿼리의 검색 기준으로 사용 되는 검색 타입의 제2 로우키 칼럼을 선택 받는 단계;
sorting의 기준으로 사용 되는 sorting 타입의 제3 로우키 칼럼을 선택 받는 단계; 및
선택 된 칼럼을 로우키 타입 정보와 함께 상기 NoSQL 물리 ERD의 상기 로우키 항목에 포함시키는 단계를 포함하는,
NoSQL 모델 생성 방법.
제13 항에 있어서,
상기 로우키 설계 단계는,
상기 칼럼 항목에 포함 된 항목들 중 로우키로 이동할 칼럼을 사용자로부터 선택 받아, 선택 된 칼럼을 상기 NoSQL 물리 ERD의 로우키 항목으로 이동하는 단계를 포함하는,
NoSQL 모델 생성 방법.
제1 항에 있어서,
상기 NoSQL 물리 ERD에는 제1 로우키 항목 내지 제M(단, M은 2 이상의 자연수) 로우키 항목을 순차로 포함하는 제1 NoSQL 테이블을 포함하고, 상기 제1 로우키 항목 내지 제M 로우키 항목은 순차로 조합 되어 합성 로우키를 구성하며,
상기 NoSQL 모델 생성 장치가, 제1 NoSQL 테이블에 적용 되는 쿼리의 검색 조건으로 사용 되는 항목과 조회 대상인 항목을, 상기 NoSQL 물리 ERD에 포함 된 상기 제1 NoSQL 테이블의 각 로우키 항목 및 각 칼럼(Column) 항목 중에서 선택 받는 단계;
상기 NoSQL 모델 생성 장치가, 상기 선택 받은 항목이, 상기 제1 NoSQL 테이블의 제1 로우키 항목 내지 제n(단, n은 2이상, M 이하의 자연수) 로우키 항목과 일치하지 않는 경우, 상기 선택 받은 조회 대상 항목 중 적어도 일부와 쿼리의 검색 조건 항목으로 구성 되는 인덱스 테이블을 생성하는 단계; 및
상기 NoSQL 모델 생성 장치가, 상기 생성 된 인텍스 테이블을 디스플레이 하거나 기 지정 된 포맷으로 저장하는 단계를 더 포함하는,
NoSQL 모델 생성 방법.
NoSQL 모델 생성 장치가, NoSQL 테이블의 로우키(Rowkey) 정보 및 칼럼(column) 정보를 얻는 단계;
상기 NoSQL 모델 생성 장치가, 상기 로우키 정보를 분석하고, 상기 로우키를 구성하는 항목을 밑줄 처리하는 단계;
상기 NoSQL 모델 생성 장치가, 상기 칼럼 정보에 기반하여 각 칼럼의 CQ 타입을 판정하는 단계;
상기 NoSQL 모델 생성 장치가, 상기 판정 결과 CQ 타입이 static(static) CQ인 경우 상기 CQ를 따옴표로 묶고, CQ 타입이 dynamic(dynamic) CQ인 경우 상기 CQ를 그대로 표시하며, CQ 타입이 nested CQ인 경우, 상기 CQ에 nested CQ임을 가리키는 기 지정 된 표기를 부가하는 단계;
상기 NoSQL 모델 생성 장치가, 상기 칼럼 정보에 기반하여 각 칼럼의 밸류가 어레이(array) 타입인지 여부를 판정하고, 어레이 타입의 밸류는 기호 '['와, 기호']'를 밸류 명칭의 양끝에 추가하는 단계; 및
상기 NoSQL 모델 생성 장치가, 상기 각 칼럼 및 상기 로우키를 구성하는 각 항목에 대하여, CQ를 가리키는 변수 명 및 그에 대응되는 밸류를 가리키는 변수 명을 포함하는 NoSQL 물리 ERD를 디스플레이 하거나 저장하는 단계를 포함하는,
NoSQL 모델 생성 방법.
NoSQL 데이터베이스 서비스 장치가, 리젼(region) 분할의 기준이 되는 리젼 분할 타입의 로우키 항목, 쿼리의 검색 기준으로 사용 되는 검색 타입의 로우키 항목 및 sorting의 기준으로 사용 되는 sorting 타입의 로우키 항목을 순서대로 연결한 합성 로우키(compound rowkey)를 생성하는 단계;
상기 NoSQL 데이터베이스 서비스 장치가, 상기 합성 로우키와 하나 이상의 칼럼(column)을 포함하는 NoSQL 테이블을 생성하는 단계;
상기 NoSQL 데이터베이스 서비스 장치가, 상기 NoSQL 테이블을 가리키는 데이터를 저장하는 단계;
상기 NoSQL 데이터베이스 서비스 장치가, 상기 NoSQL 테이블에 대한 조회 요청을 입력 받는 단계;
상기 NoSQL 데이터베이스 서비스 장치가, 상기 합성 로우키를 기준으로 상기 조회 요청에서 요구 된 조회 항목을 검색하는 단계; 및
상기 NoSQL 데이터베이스 서비스 장치가, 상기 검색 결과를 출력하는 단계를 포함하는,
NoSQL 기반 검색 방법.
제18 항에 있어서,
상기 합성 로우키를 생성하는 단계는,
상기 sorting 타입의 로우키 항목 다음으로 unique 타입의 로우키 항목을 더 연결하여 상기 합성 로우키를 생성하는 단계를 포함하고,
상기 unique 타입의 로우키 항목은 상기 합성 로우키의 uniqueness를 확보하기 위한 고유의 식별자를 가리키는 것인,
NoSQL 기반 검색 방법.
NoSQL 데이터베이스 서비스 장치가, 리젼(region) 분할의 기준이 되는 리젼 분할 타입의 로우키 항목, 조회 요청에 대한 검색 기준으로 사용 되는 검색 타입의 로우키 항목 및 sorting의 기준으로 사용 되는 sorting 타입의 로우키 항목을 순서대로 연결한 합성 로우키(compound rowkey)를 생성하는 단계;
상기 NoSQL 데이터베이스 서비스 장치가, 상기 합성 로우키와 하나 이상의 칼럼(column)을 포함하는 NoSQL 테이블을 생성하는 단계;
상기 NoSQL 데이터베이스 서비스 장치가, 상기 NoSQL 테이블을 가리키는 데이터를 제1 스토리지에 저장하는 단계;
상기 NoSQL 데이터베이스 서비스 장치가, 상기 NoSQL 테이블을 상기 합성 로우키를 기준으로 하여 복수의 리젼들로 분할하는 단계; 및
상기 NoSQL 데이터베이스 서비스 장치가, 상기 복수의 리젼들 중 적어도 일부를 상기 제1 스토리지와 다른 제2 스토리지에 저장하는 단계를 포함하는,
NoSQL 테이블의 스케일-아웃 방법.
제20 항에 있어서,
상기 리젼 분할 타입의 로우키 항목은, 통합 기준 리젼 분할 타입의 로우키 항목과, 상기 통합 기준 리젼 분할 타입의 로우키 항목 다음으로 연결되는 보관 기준 리젼 분할 타입의 로우키 항목을 포함하고,
상기 통합 기준 리젼 분할 타입의 로우키 항목은, 리젼 분할의 제1 기준이 되는 항목이고,
상기 보관 기준 리젼 분할 타입의 로우키 항목은, 데이터 보관 주기를 가리키는 항목인,
NoSQL 테이블의 스케일-아웃 방법.
제21 항에 있어서,
상기 분할 된 상기 리젼을 각각 서로 다른 스토리지에 저장하는 단계는,
상기 분할 된 리젼 중, 삭제 대상인 리젼을 결정하는 단계; 및
상기 결정 된 삭제 대상 리젼의 데이터는 스토리지에 저장하지 않고 삭제하는 단계를 포함하는,
NoSQL 테이블의 스케일-아웃 방법.
제21 항에 있어서,
상기 분할 된 상기 리젼을 각각 서로 다른 스토리지에 저장하는 단계는,
상기 분할 된 리젼 중, 삭제 대상인 리젼을 결정하는 단계; 및
상기 결정 된 삭제 대상 리젼의 데이터는 삭제 대상 데이터 저장용 스토리지에 저장하는 단계를 포함하는,
NoSQL 테이블의 스케일-아웃 방법.
제21 항에 있어서,
상기 리젼 분할 타입의 로우키 항목은, 상기 보관 기준 리젼 분할 타입의 로우키 항목 다음으로 연결되는 확장 기준 리젼 분할 타입의 로우키 항목을 더 포함하고,
상기 확장 기준 리젼 분할 타입은, 분할 후 리젼 개수를 결정할 때 사용되는 항목인,
NoSQL 테이블의 스케일-아웃 방법.
NoSQL 데이터베이스 서비스 장치가, NoSQL 테이블에 적용 될 조회 요청의 검색 조건으로 사용 되는 항목과 조회 대상인 항목을, 상기 NoSQL 테이블의 합성 로우키(Rowkey)를 구성하는 각 로우키 항목 및 각 칼럼(Column) 항목 중에서 선택 받는 단계;
상기 NoSQL 데이터베이스 서비스 장치가, 상기 선택 받은 검색 조건 항목이 상기 합성 로우키의 로우키 항목 및 로우키 항목의 순서를 활용하기에 적합하지 않는 경우, 상기 선택 받은 조회 대상 항목 중 적어도 일부와 조회 요청의 검색 조건 항목으로 구성 되는 인덱스 테이블을 생성하는 단계; 및
상기 NoSQL 데이터베이스 서비스 장치가, 상기 NoSQL에 대한 조회 요청의 처리를 위해, 상기 인덱스 테이블을 조회하는 단계를 포함하는,
NoSQL 기반 검색 방법.
제25 항에 있어서,
상기 인덱스 테이블을 생성하는 단계는,
조회 요청의 조회 대상 항목 중 값의 변화가 있는 항목의 존재 여부를 질의하는 UI를 제공하는 단계;
상기 UI를 통해 값의 변화가 있는 항목이 존재하는 것을 가리키는 사용자 입력이 입력 되는 경우, non-covering 인덱스 테이블을 생성하는 단계; 및
상기 UI를 통해 값의 변화가 있는 항목이 존재하지 않는 것을 가리키는 사용자 입력이 입력 되는 경우, covering 인덱스 테이블을 생성하는 단계를 포함하는,
NoSQL 기반 검색 방법.
컴퓨팅 장치와 결합하여,
관계형 데이터베이스 모델에 따른 논리 ERD(Entity-Relationship Diagram)를 임포트 하는 단계;
상기 논리 ERD에 포함 된 각 엔터티(entity) 간 참조 관계에 대한 정보 및 상기 논리 ERD에 포함 된 각 엔터티의 속성이 NoSQL에서만 지원되는 타입을 가지는지 여부에 대한 정보를 포함하는 논리 ERD 보완 정보를 사용자 입력 받는 단계;
상기 논리 ERD에 포함 된 각 엔터티 중 NoSQL 테이블 생성 대상 엔터티를, 로우키(Rowkey) 항목과 칼럼(column) 항목을 포함하는 NoSQL 물리 ERD 템플릿에 반영하여, NoSQL 물리 ERD를 생성하되, PK(Primary Key) 속성은 로우키 항목에 배치하고, non-PK 속성은 칼럼 항목에 배치하는 단계;
상기 NoSQL 물리 ERD에 상기 논리 ERD 보완 정보에 따른 변환을 적용하는 단계;
상기 NoSQL 물리 ERD의 상기 칼럼 항목에 포함 된 항목들 중 로우키에 포함 될 칼럼을 사용자로부터 선택 받고, 선택 된 칼럼을 상기 NoSQL 물리 ERD의 상기 로우키 항목에 포함시키는 로우키 설계 단계; 및
상기 NoSQL 물리 ERD를 디스플레이 하거나 기 지정 된 포맷으로 저장하는 단계를 실행 시키기 위하여 기록 매체에 저장 된,
컴퓨터 프로그램.
하나 이상의 프로세서;
상기 프로세서에 의하여 수행 되는 컴퓨터 프로그램을 로드(load) 하는 메모리; 및
논리 ERD를 가리키는 데이터를 저장하고, 상기 컴퓨터 프로그램의 수행 결과에 의하여 생성 된 상기 논리 ERD 대응 NoSQL 물리 ERD를 저장하는 스토리지를 포함하되,
상기 컴퓨터 프로그램은,
상기 논리 ERD를 임포트 하는 오퍼레이션;
상기 논리 ERD에 포함 된 각 엔터티(entity) 간 참조 관계에 대한 정보 및 상기 논리 ERD에 포함 된 각 엔터티의 속성이 NoSQL에서만 지원되는 타입을 가지는지 여부에 대한 정보를 포함하는 논리 ERD 보완 정보를 사용자 입력 받는 오퍼레이션;
상기 논리 ERD에 포함 된 각 엔터티 중 NoSQL 테이블 생성 대상 엔터티를, 로우키(Rowkey) 항목과 칼럼(column) 항목을 포함하는 NoSQL 물리 ERD 템플릿에 반영하여, NoSQL 물리 ERD를 생성하되, PK(Primary Key) 속성은 로우키 항목에 배치하고, non-PK 속성은 칼럼 항목에 배치하는 오퍼레이션;
상기 NoSQL 물리 ERD에 상기 논리 ERD 보완 정보에 따른 변환을 적용하는 오퍼레이션; 및
상기 NoSQL 물리 ERD의 상기 칼럼 항목에 포함 된 항목들 중 로우키에 포함 될 칼럼을 사용자로부터 선택 받고, 선택 된 칼럼을 상기 NoSQL 물리 ERD의 상기 로우키 항목에 포함시키는 로우키 설계 오퍼레이션을 포함하는,
NoSQL 모델 생성 장치.
제28 항에 있어서,
상기 컴퓨터 프로그램은,
상기 NoSQL 물리 ERD에 대응 하는 테이블 생성 스크립트를 자동 생성 하는 오퍼레이션; 및
상기 자동 생성 된 테이블 생성 스크립트를 상기 NoSQL 모델 생성 장치와 네트워크를 통해 연결 된 NoSQL 서버에 자동 제공 하는 오퍼레이션을 더 포함하는,
NoSQL 모델 생성 장치.