KR19990076947A - 복수의 소스 능력을 가진 데이터 검색 방법 및 장치 - Google Patents

Abstract

2개 또는 그 이상의 소스 데이터 형태 중 어느 형태로도 이루어질 수 있는 데이터 소스에 포함된 정보에 관한 출력 또는 리포트의 생성이 표준화된 또는 균일한 방식으로 제공된다. 예를 들어, 새로운 데이터베이스를 정의하는데 사용하기 위해, 다양한 데이터 소스의 구조적 특성 또는 다른 특성을 식별하기 위한 프로그래밍을 포함하는, 상이한 형태의 소스 데이터에 특정한 다수의 드라이버가 제공된다. 바람직하게는, 새로운 데이터베이스는 고도의 유연성 및/또는 빠른 출력 또는 리포팅을 허용하도록 구성되거나, 또는 그렇지 않으면, 리포팅 목적을 위해 최적화된다. 일실시예에서, 본 발명은 하나 또는 그 이상의 데이터 소스로부터 하나 또는 그 이상의 균일한 데이터베이스로의 변환을 포함하며, 바람직하게는, 데이터를 편성하기 위한 하나 또는 그 이상의 주요(key) 카테고리를 생성하는 것을 포함하고, 선택적으로는, 카테고리 그룹화(groupings) 또는 롤업(rollups) 및 추가적인 데이터 또는 선택적인 레퍼런스를 생성하는 것을 포함한다. 일실시예에서, 매우 상이한 구조를 가질 수도 있는 2개 또는 그 이상의 상이한 데이터 소스에 근거할 수도 있다 할지라도, 구조의 균일도를 가진 하나 또는 그 이상의 데이터베이스가 생성된다. 상이한 데이터 소스가 자동적으로 분석되며, 이러한 분석은 정보를 편성하는데 사용하기 위해 데이터의 카테고리를 식별하고 및/또는 생성하기 위해 이용될 수 있다.

Description

복수의 소스 능력을 가진 데이터 검색 방법 및 장치

관계적 또는 계층적 데이터베이스 관리 시스템, 플랫 파일 데이터 시스템, 스프레드시트(spreadsheet) 시스템 등과 같은, 컴퓨터-억세스가능 정보를 편성하기 위한 많은 방식이 개발되었다. 이들 시스템은, 회계 또는 다른 금융 정보, 과학 또는 기술 정보, 법인체 또는 회사 데이터, 성명, 주소 및 전화번호 데이터, 및 통계 데이터를 포함하여, 무수한 형태의 정보를 저장하고, 조작하고, 디스플레이하기 위해 사용된다. 많은 포맷 및 데이터 구조가 개발되었으며, 이러한 상황은 바람직한 결과 및 바람직하지 못한 결과를 모두 갖고 있다. 긍정적인 측면에서 보면, 다양한 상이한 형태의 시스템을 구비함으로써, 상이한 목적을 위해 최적화되거나(예를 들어, 데이터 분석 및 리포팅의 속도 또는 유연성과 대비하여 데이터 입력 또는 저장을 위해 최적화되거나, 법인체 데이터과 대비하여 회계 데이터에 대해 최적화되는 것 등이 있음), 또는 개인이나 법인체 선호도(preferences)에 호소할 수 있는 사용자 인터페이스 또는 다른 특성을 제공하는 상이한 시스템을 제공하는 것이 가능하다. 그러나, 이러한 정보 시스템의 증가는 예를 들어, 정보를 통합하거나 조합하기 위해 2개의 또는 그 이상의 시스템 내의 정보에 억세스하는데 유용하게 되는 상황에 있어 본질적인 장벽을 제공한다. 이와 같은 상황의 예로는, (1) 표준화된 리포트를 생성하길 원하지만, 그 각각이 회계 데이터를 상이한 형태의 데이터 소스로 관리하는 복수의 고객을 갖고 있는 회계사; (2) 균일한 리포트를 생성하길 원하지만, 상이한 부서가 상이한 법인체 또는 금융 소프트웨어를 사용하는 수개의 부서를 가진 법인체; (3) 균일한 리포트를 생성하길 원하지만, 그 회계 정보를 제1 형태 또는 브랜드의 데이터베이스(또는 다른 데이터 소스)에 관리하고, 그 법인체 정보를 제2의 다른 형태의 데이터베이스에 관리하는 법인체; (4) 공통적인 문제를 연구하고 있지만, 그 각각이 상이한 형태 또는 브랜드의 데이터베이스나 다른 데이터 소스에 데이터를 저장하고 그 저장된 데이터에 억세스하는 과학자 그룹이 있다. 본 명세서를 이해한 이후에 독자들은 다른 예가 더 있다는 것을 이해할 것이다. 또한, 몇몇 상황에서는, 원하는 모든 정보가 단일 형태의 데이터 소스 또는 단일 데이터 파일에 저장되어 있을 때 조차도, 예를 들어, 균일한 및/또는 향상된 데이터 분석 및 리포팅을 제공하도록 데이터에 억세스하는 방식을 제공하는 것이 바람직할 수 있다.

이와 같은 상황은 정보를 편성하는 방식에서의 차이 및 데이터 소스의 형태에서의 차이를 포함하여, 많은 이유로 인해 어려움을 부여한다. 몇몇 상황에서는, 동일한 데이터베이스 소프트웨어가 사용되는 경우 조차도, 유사한 카테고리의 정보가 상이한 방식으로 편성될 수도 있다. 예를 들어, 제1 데이터베이스 소프트웨어 패키지를 사용하는 제1 사례에서는, 회사의 모든 직원의 성명은 제1 테이블 또는 리스트에 저장되고, 모든 주소는 제2 테이블 또는 리스트에 저장되고, 모든 전화번호는 제3 테이블 또는 리스트에 저장되고, 어떤 성명이 어떤 주소 및 어떤 전화번호와 연관되어 있는지를 나타내기 위한 포인터 또는 링크가 저장되도록, 사용자가 회사 직원의 기록을 편성할 수도 있다. 그러나, 동일한 소프트웨어를 사용하는 다른 사례에서는, 직원 정보를 편성하는 다른 사람이 한 테이블 내의 레코드으로부터 다른 테이블의 레코드으로의 링크 또는 포인터 없이, 정보의 각각의 라인 또는 "레코드(record)"가 성명, 주소 및 전화번호를 포함하는 단일의 테이블을 제공할 수도 있다.

또한, 상이한 형태의 데이터 소스는 상이한 구조 및/또는 상이한 데이터 저장 포맷 또는 방식을 가질 수 있다. 예를 들어, 몇몇 데이터베이스 패키지는 계층적 방식(예, 트리 방식)으로 편성되지만, 다른 것은 (행과 열의 2차원 테이블에 모형화된) 관계적 데이터베이스로서 편성될 수도 있다. 또한, "플랫 파일" 형식에 스프레드시트로서 데이터를 저장하는 것과 같이, 엄밀하게 말하면, 데이터베이스 형식이 아닌 형식으로 정보가 저장될 수도 있다. 또한, 상이한 형태의 데이터 소스가 다양한 포맷으로 데이터를 저장할 수도 있다. 예를 들어, 몇몇 데이터베이스 제품은 각각의 테이블, 각각의 리포트 포맷 및 각각의 질의(query)를 하드 디스크와 같은 기억장치에 독립된 파일로서 저장하는 반면에, 다른 소프트웨어는 모든 테이블, 관계, 질의, 리포트 포맷 등을 단일 파일에 저장할 수도 있다. 몇몇의 제품은 각각의 레코드 및/또는 필드를 고정 길이 데이터로서 및/또는 파일 내의 고정 위치에 저장할 수도 있고, 반면에, 다른 제품은 한 레코드와 그 다음 레코드 사이 또는 한 레코드 내의 한 필드와 그 다음 필드 사이를 구별하기 위해 구분문자(delimiters)를 사용할 수도 있다. 2개의 상이한 소프트웨어 제품이 특정 형태의 정보를 소정의 위치에 저장하고 있는 경우 조차도, 이러한 위치가 상이한 소프트웨어 제품에 따라 서로 다를 수도 있다. 또한, 한 제품에서는 아스키(ASCII) 인코딩을 이용하고, 다른 제품에서는 복수-언어(multi-lingual)(멀티-바이트) 문자를 이용하는 것과 같이, 상이한 소프트웨어 제품에서 데이터가 서로 다르게 인코드될 수도 있다. 몇몇의 경우에는, 데이터가 압축 및/또는 암호화될 수도 있다.

데이터 형태 사이에서의 폭넓은 변화의 관점에서 보면, 종래에는, (예를 들어, 리포트 및 분석을 표준화하고 2개 또는 그 이상의 데이터베이스로부터의 정보를 조합 또는 통합하기 위해) 저장된 정보에 억세스하고자 할 때, 컨설턴트 또는 다른 전문가는 그 구조, 관계 데이터 저장 포맷, 데이터베이스 내의 데이터의 편성 등을 이해하기 위해 개별적으로 또는 "수동적인 방식으로(manually)" 각각의 "소스" 데이터 파일 또는 데이터베이스를 분석했다. 다음에, 전문가는 원하는 억세스, 통합 또는 조합을 실현하기 위해 소스 데이터 파일 또는 데이터베이스 내의 데이터의 임포트(import) 또는 질의하는(querying) 소정의 방식을 구성하게 된다. 비록 이러한 접근방법이 실시가능하지만, 이것은 사람의 분석을 필요로 하기 때문에 노동-집약적이며, 또한, 전문가 또는 컨설턴트가 분석 작업을 완료하는데 비교적 긴 시간이 요구되고, 때로는 수행될 억세스, 통합 또는 조합을 위해 수일 또는 수주일이 요구되기 때문에 시간-소비적이다.

따라서, 사람의 분석에 대한 필요성을 없애면서, 다양한 포맷 또는 형식으로되거나 또는 다양한 방식으로 편성된 정보가 억세스, 조합 및/또는 통합될 수 있는 시스템을 제공하고, 따라서, 적어도 부분적으로 자동화되고, 바람직하게는 이전의 방법 보다 덜 노동-집약적이고 덜 시간-소비적인 시스템을 제공하는 것이 유용할 것이다.

본 발명은, 다수의 상이한 포맷으로 이루어질 수도 있으며, 다수의 상이한 소스 중 하나 또는 그 이상의 소스에 저장된 정보를 검색할 수 있고, 그 정보에 근거하여 리포트 및 분석을 제공할 수 있는 컴퓨터-구현 시스템에 관한 것으로서, 특히, 소스 데이터의 사람의 분석에 의존할 필요 없이 구조적(structural) 및/또는 관계적(relational) 정보를 포함하여, 다수의 포맷중 어느 포맷으로 저장된 데이터베이스 정보를 자동적으로 검색할 수 있는 컴퓨터 방법 및 장치에 관한 것이다.

도1은 플랫 파일 데이터 저장의 예를 도시하는 개략도.

도2는 도1에 도시된 데이터 저장과 관련하여 사용될 수 있는 형태의 디렉토리 구조를 도시하는 도면.

도3a 내지 도3c는 도1에 도시된 데이터 저장과 관련하여 사용될 수 있는 데이터 저장 포맷의 예를 도시하는 도면.

도4a 내지 도4f는 관계 데이터베이스의 테이블에 저장된 데이터의 예를 도시하는 개략도.

도5는 도4a 내지 도4f에 도시된 데이터 저장과 관련하여 사용될 수 있는 형태의 디렉토리 구조를 도시하는 도면.

도6은 플랫 파일 데이터 저장의 예를 도시하는 개략도.

도7a 내지 도7d는 관계 데이터베이스의 테이블에 저장된 데이터의 개략도.

도8은 본 발명의 일실시예에 따른 정보 검색을 위한 시스템의 블록도.

도9는 본 발명의 일실시예에 따른 펑션 모듈의 내용의 개략도.

도10은 본 발명의 일실시예에 따른 정보 검색을 위한 프로세스의 흐름도.

도11a 및 도11b는 본 발명의 일실시예에 따른, 디렉토리를 선택 또는 탐색하기 위한 의사코드(pseudocode) 절차를 도시하는 도면.

도12는 본 발명의 일실시예에 따라 제공되는 데이터베이스(808)의 테이블에 저장된 데이터의 개략도.

발명의 요약

본 발명은 예를 들어, 2개의 상이한 정보 저장 시스템 내의 정보에 억세스하고 그 정보의 통합 및/또는 조합을 실현하기 위해 저장된 정보에 대한 억세스를 수행하는 시스템에 관한 것이다. 바람직하게는, 본 발명의 일실시예에서, 관련된 일부 또는 모든 분석이 (사람의 분석을 필요로 하지 않고) 적절하게 프로그램된 컴퓨터를 이용하여 자동적으로 수행된다. 바람직하게는, 이 시스템은 유연성이 있는데, 그 이유는 그것이 본래부터 데이터 포맷에 제한되지 않고, 사실상 어떠한 컴퓨터-판독가능 정보 소스로부터도 데이터를 얻도록 구성될 수 있기 때문이다. 또한, 바람직하게는, 추가적인 형태, 포맷 또는 편성의 데이터에 억세스할 수 있도록 구성요소가 추가될 수 있기 때문에, 이 시스템은 확장가능하다(더욱 바람직하게는, 모듈 방식으로 확장가능하다). 본 발명의 일실시예에서, 데이터의 억세스, 통합 또는조합은 데이터 분석의 확장(enhancement)을 수반하며, 원래의 데이터 소스에 없거나 사용되지 않는 형태의 데이터 분석 및/또는 리포팅을 제공한다. 바람직하게는, 이 시스템은 수가지 형태의 데이터 소스를 통한 데이터 분석 및/또는 리포팅의 표준화를 제공하기 위해 사용될 수 있다. 본 발명의 일실시예에서, 이 시스템은 (예를 들어, 텍스트 인식, 인공지능 및/또는 전문가(expert) 시스템을 이용함으로써) 원하는 결과를 실현하기 위해, 소스 데이터 파일 또는 데이터베이스의 내용 뿐만 아니라 구조에 관한 정보도 이용한다. 일실시예에서, 이 시스템은 데이터가 분석 또는 리포팅에 이용가능하게 되는 방식을 적어도 부분적으로 제어하기 위해 이와 같은 정보를 이용한다. 일실시예에서, 이 시스템은 이와 같은 분석 및 리포트를 제공하는데 있어 이와 같은 정보를 이용한다.

2개 또는 그 이상의 소스 데이터 형태 중 어느 형태로도 이루어질 수 있는 데이터 소스에 포함된 정보에 관한 출력 또는 리포트의 생성이 표준화된 또는 균일한 방식으로 제공된다. 예를 들어, 새로운 데이터베이스를 정의하는데 사용하기 위해, 다양한 데이터 소스의 구조적 특성 또는 다른 특성을 식별하기 위한 프로그래밍을 포함하는, 상이한 형태의 소스 데이터에 특정한 다수의 드라이버가 제공된다. 바람직하게는, 새로운 데이터베이스는 고도의 유연성 및/또는 빠른 출력 또는 리포팅을 허용하도록 구성되거나, 또는 그렇지 않으면, 리포팅 목적을 위해 최적화된다. 일실시예에서, 본 발명은 하나 또는 그 이상의 데이터 소스로부터 하나 또는 그 이상의 균일한 데이터베이스로의 변환을 포함하며, 바람직하게는, 데이터를 편성하기 위한 하나 또는 그 이상의 주요(key) 카테고리를 생성하는 것을 포함하고, 선택적으로는, 카테고리 그룹화(groupings) 또는 롤업(rollups) 및 추가적인 데이터 또는 선택적인 레퍼런스를 생성하는 것을 포함한다.

일실시예에서, 본 발명은 이전의 회계 또는 다른 소프트웨어에 의해 생성된 데이터 파일과 같은 기존의 데이터 파일로부터 변환된 회계 또는 다른 데이터에 근거하여 데이터베이스를 생성하거나 또는 점유(populate)한다.

본 발명의 일실시예에서, 이 시스템은 예를 들어, 갱신되어야 하는 데이터의 하나 또는 그 이상의 프로파일을 저장하고, 및/또는 미리정해진 시간 또는 간격으로 갱신 절차를 자동적으로 실행하도록 스케쥴을 생성 또는 정의함으로써, 새로운 데이터베이스의 일부 또는 전부를 갱신하는 것을 용이하게 하도록 구성된다.

본 발명의 일실시예에서, 예를 들어, 데이터의 소정의 필드 또는 파라미터에 대해 하나 이상의 값이 발견될 때 뷰(view)를 생성하는 것과 같이, 데이터의 바람직한 뷰를 자동적으로 식별하는 확장이 제공된다.

바람직하게는, 잠재적인 에러 또는 문제점을 검출하기 위해, 하나 또는 그 이상의 검증 또는 감사(audit) 툴이 제공된다.

본 발명의 관점에 관해 설명하기 전에, 본 발명의 이해를 촉진하기 위해, 정보를 저장하는 다양한 방식의 예를 제공하는 것이 유용할 것이다. 이것은 회계 정보의 예 및 과학 또는 기술 정보의 예를 포함하여 몇가지 예를 제공함으로써 실현된다. 다음의 테이블1은 2개의 다른 법인체에 의해 저장될 수 있는 데이터 형태의 비교를 제공한다. 테이블1은 2개의 법인체에 대한 회계 또는 다른 정보의 개념적인 편성을 나타내고자 하는 것이며, (비록 원하는 경우에 그렇게 될 수 있다 하더라도) 반드시 데이터베이스에 저장되게 되는 정보는 아니다.

테이블 1 : 회계 편성의 예

법인체 #1 법인체 #2

Account(계정)	Account(계정)
Cash(현금)	Cash(현금)
Accounts Payable(지불계정)	Bank #1(은행 #1)
Accounts Receivable(수취계정)	Bank #2(은행 #2)
	Bank #3(은행 #3)
	Savings(보통예금)
	Checking(당좌예금)
	Accounts Payable(지불계정)
	Parts(파트)
	Consultants(컨설턴트)
	Accounts Receivable(수취계정)
	Sales(판매)
	Interest(이자)

법인체 #1 법인체 #2

Employee(피고용인)	Employee(피고용인)
Salesman #1(판매원 #1)	Sales(판매)
Salesman #2(판매원 #2)	Salesman #1(판매원 #1)
	Salesman #2(판매원 #2)
	Research(연구)
	Researcher #1(연구원 #1)
	Researcher #2(연구원 #2)
Project(프로젝트)	Project(프로젝트)
Research(연구)	Research(연구)
Sales(판매)	Chemical(화학)
	Biomedical(생물의학)
	Sales(판매)
	Old Products(구제품)
	New Lines(신라인)
Product(제품)	Product(제품)
Product #1(제품 #1)	Old Product Lines(구제품라인)
Product #2(제품 #2)	Line #1(라인 #1)
	Product 1(제품 1)
	Product 2(제품 2)
	Line #2(라인 #2)
	Product 3(제품 3)
	Product 4(제품 4)
	New Product Lines(신제품라인)
	Line #3(라인 #3)
	Product 5(제품 5)
	Product 6(제품 6)
	Line #4(라인 #4)
	Product 7(제품 7)
	Product 8(제품 8)
	Subsidiary(자회사)
	Subsidiary #1(자회사 #1)
	Subsidiary #2(자회사 #2)

테이블1의 첫 번째 예에서, 법인체 #1은 계정(account) 정보, 피고용인(employee) 정보, 프로젝트(project) 정보, 제품(product) 정보를 보유하고 있으며, 따라서, 4개의 계정 부분을 간고 있다. 법인체 #1의 계정 정보는 단지 3개의 구성요소, 즉, 현금(cash), 지불 계정(account payable) 및 수취 계정(account receivable)을 포함하고 있다. 이 법인체는 2가지 형태의 프로젝트(연구 및 판매)에 의한 그 판매원^.트랙 정보의 리스트를 보존하고, 그 제품의 리스트를 보존한다. 테이블1의 두 번째 예는 (여전히 간략화되어 있지만) 약간 긴 예이다. 본 예에서, 계정은 계층적으로 복수의 구성요소를 갖고 있다. 비록 법인체 #2의 계정이 현금, 지불 계정 및 수취 계정의 카테고리를 갖고 있지만, 이들 각각의 카테고리는 서브카테고리를 갖고 있으며, 이들 서브카테고리의 일부는 더욱 세분된 부문을 갖고 있다. 이와 유사하게, 피고용인, 프로젝트 및 제품 정보는 수개의 카테고리 및 서브카테고리로 나누어져 있으며, 법인체 #2는 자회사와 같은, 추적되는 추가적인 항목을 갖고 있다.

테이블1은 데이터 소스 및/또는 데이터 저장 포맷 중에서의 차이를 고려하기 전에도, 법인체의 구조 및/또는 그 법인체가 그 정보를 편성하기 위해 선택하는 방식이 한 시스템과 다른 시스템 사이에 차이를 유발하게 된다는 것을 예시하고 있다. 예를 들어, 만일 한 계정이 고객으로서 법인체 #1 및 법인체 #2를 갖고 있고, 이들 2개의 법인체에 대해 균일한 또는 표준화된 리포팅 및 분석 시스템을 사용하길 원하는 경우에는, 법인체 #1 및 법인체 #2가 동일한 데이터베이스 소프트웨어를 사용하고 있고 그 소프트웨어 내의 회계 정보를 유사한 방식으로 편성하였다 할지라도, 그렇게 하는데 있어 상당한 어려움이 있게 된다. 그러므로, 이전의 방법을 이용하면, 법인체의 데이터베이스에 근거하여 2개 법인체에 대한 균일한 또는 표준화된 리포팅 및 분석을 제공하기 위해서는, 통상적으로 테이블1의 정보에 대한 사람의 분석 및 이해를 필요로 한다.

여전히 회계 정보를 고려하는 것과 관련하여, 법인체 #1 및 법인체 #2의 회계 정보를 저장하기 위해, 수가지 형태의 정보 저장이 사용될 수 있다. 예를 들어, 하나 또는 그 이상의 플랫 파일로서 정보가 저장될 수 있다. 적어도 일부의 용법에 따르면, "플랫 파일" 정보 저장은 진정한 데이터베이스 시스템이 아니라는 것을 주목하자. 그럼에도 불구하고, 본 발명은 적어도 일부의 실시예에서, 플랫 파일 데이터 뿐만 아니라 다른 데이터베이스 및 비-데이터베이스 저장 방법도 수용할 수 있다.

도1은 테이블1의 법인체 #2에 대한 정보를 저장하기 위해 다수의 플랫 파일이 어떻게 사용될 수 있는가를 도시하는 개략도이다. 비록 도1이 정보가 다수의 서류 시트 상의 서식으로 되어 있는 것처럼 도시하고 있지만, 데이터는 실제적으로 예를 들어, 후술되는 바와 같이, 하드 디스크와 같은 컴퓨터 판독가능 매체에 저장되게 된다. 도1의 포맷은 다수의 파일(101a-101f)로 편성된 데이터의 논리적인 구조를 도시하고자한 것이며, 여기서, 각각의 파일은 도1에 타이틀 또는 헤더 정보(104a,104b)로서 도시된 파일 식별 정보(104)와 도1에 정보 라인(106a,106b,106c)으로서 도시된 다수의 레코드를 포함하고, 각각의 레코드는 (도1에서 칼럼(108a,108b,108c,108d)으로 편성된) 다수의 필드를 갖고 있다. 프로그래밍 기술 분야에 통상의 지식을 가진자에게는, 도1에 도시된 논리적인 로우 및 칼럼 구조를 갖도록 또는 반영하도록 데이터를 저장하고 억세스하기 위한 방법 및 장치가 잘 알려져 있다. 본 발명은 다수의 플랫 파일 정보 저장 프로그램과 관련하여 사용될 수 있다. 이와 같은 정보 저장 프로그램의 예로는, "Simply Accounting(상표)" 및 "MAS-90(상표)"라는 상표명으로 판매되는 프로그램이 있다.

도1에 도시된 논리적인 구조로 편성된 데이터는 다수의 상이한 포맷으로 저장될 수 있다. 예를 들어, 일실시예에서, 각각의 플랫 파일(101a-101f) 내의 데이터는 개인용 컴퓨터의 하드 디스크 상에 독립된 파일로서 저장된다. 도2는 이와 같은 파일을 저장하기 위해 사용될 수 있는 디렉토리/파일 구조를 도시하고 있으며, 여기서, 도1에 도시된 모든 파일은 단일 서브디렉토리에 저장되어 있다. 이 기술분야에 통상의 지식을 가진자에게 잘 알려진 바와 같이, 비록 도2에 도시된 바와 같은 디렉토리 하이어라키로 편성되었다 할지라도, 다양한 파일이 하드 디스크 상에 다수의 독립된 위치에 물리적으로 저장될 수 있다. 한 파일 내에 데이터를 저장하기 위해 다수의 포맷이 사용될 수 있으며, 그 예는 도3a 내지 도3c에 도시되어 있다. 도3a의 예에서, 파일은 헤더 정보를 포함하고 있으며, 그 뒤로 제1 레코드(106a), 제2 레코드(106b) 등의 저장이 뒤따른다. 도3a의 예에서는, 각각의 레코드(106a,106b)가 동일한 길이(304)르 갖고 있는(즉, 고정된 수의 비트를 차지하는) 고정 길이 데이터 포맷이 사용된다. 도3a의 실시예에서, 각각의 레코드 내의 각 필드도 역시 고정 길이(308a-308d)를 갖고 있다.

도3b는 로우 순서가 아닌 컬럼 순서로 데이터가 저장되어 있는(먼저 모든 날짜가 연속되고, 그 다음에 종류가 연속되는) 다른 고정 길이 데이터 저장 방법을 도시하고 있다. 도3b의 실시예에서, 원하는 데이터를 배치하는데 도움을 주기 위해, 예를 들어, 헤더의 일부로서 레코드 수의 표시(322)를 저장하는 것이 유용할 수도 있다. 예를 들어, 도3a 또는 도3b에 도시된 바와 같이 고정 길이 시스템에서는, 데이터의 개시점으로부터 소정의 거리에(소정의 비트수에) 데이터의 특정 부분이 배치되게 된다. 예를 들어, 도3a에서, 만일 헤더(302)가 4 바이트의 길이를 갖고, 레코드 길이(304)가 8 바이트라는 것을 알고 있다면, 제1 레코드(106a)에 대한 데이터 정보는 반드시 바이트 번호 5에서 시작되고, 제2 레코드(106b)에 대한 데이터 정보는 반드시 바이트 번호 13에서 시작된다는 것을 알게 된다.

도3c는 고정 길이 필드가 아닌 구분된(delimited) 필드의 데이터 저장을 도시하고 있다. 구분된 포맷에서는, 레코드 및/또는 필드의 종료점 또는 개시점을 구분하기 위해, 데이터를 저장하기 위해 사용되는 패턴과는 다른 비트 패턴인, 특수한 심볼이 사용된다. 도3c에 도시된 실시예에서는, 2개의 상이한 특수 심볼이 사용되며, 하나는 레코드의 개시점을 구분하고, 다른 하나는 필드의 개시점을 구분하기위한 것이다. 이들 심볼은 도3c에서 콜론 과 세미콜론으로서 각각 표시되어 있으며, 이것은 어떤 비트 패턴 또는 심볼도 될 수 있다. 도3c의 데이터 포맷에서, 제1 레코드 심볼(324a) 다음에 오고, 제1의 새로운 필드 심볼(324b) 이전에 오는 정보로서 제1 레코드(106a)에 대한 데이터 정보를 지시하는 정보를 식별하는 것이 가능하다. 제2 레코드(106b)로부터의 데이터 정보는 제2의 새로운 레코드 심볼(326a) 다음에 오고, 그 다음의 새로운 필드 심볼(326b) 이전에 오는 정보가 된다. 정보를 저장하기 위한 많은 다른 포맷도 가능하다. 많은 데이터 저장 포맷이 상이한 형태의 정보 저장 시스템 내의 데이터를 억세스, 통합 및 조합하는데 있어 또다른 문제를 제시한다는 것은 도3a 내지 도3c로부터 명백하르 것이다. 이전에는, (데이터베이스 관리 시스템 또는 저장된 정보를 판독하기 위한 다른 소프트웨어를 이용하지 않고) 직접 정보에 억세스하길 원하는 사람은, 몇몇의 경우에는 저장된 정보의 예를 분석함으로써 획득될 수 있는 것과 같은, 데이터 저장 포맷에 대한 지식을 필요로 하였다. 그러므로, 테이블1의 법인체 #1 및 법인체 #2 모두에 대해 저장된 정보에 억세스하길 원하는 회계사의 필요성을 수용하는 것은, 데이터의 논리적인 편성(도1) 및 그 논리적인 디렉토리 구조(도2)에 관한 정보 뿐만 아니라 데이터 저장 포맷(도3a-도3c)에 관한 정보도 필요로 하게된다.

플랫 파일 데이터로서 정보를 저장하는 것에 더하여, 많은 다른 가능성이 있다. 도4a 내지 도4f는 관계 데이터베이스와 관련하여 한 가지 가능한 정보 편성을 도시하고 있다. 도4a 내지 도4f의 예에서, 다수의 레코드(406a-406d)를 가진 제1 트랜잭션 테이블(402)이 저장되어 있다. 도4a에 도시된 레코드는 몇가지 관점에서 도1에 도시된 것과 유사하며, 데이터 필드, 종류 필드, 수량 필드 및 총계 필드를 포함한다. 도4a의 예에서는, 각각의 레코드에 대해 추가적인 인덱스 필드(408)가 제공되어 있다. 도4a의 예에서 트랜잭션 테이블은 도1에 도시된 형태의 헤더 정보(104a)를 포함하고 있지 않으며, (도1의 실시예의 복수의 테이블(101a-101f)이 아닌) 단일의 트랜잭션 테이블만이 제공되어 있다. 도4a 내지 도4f에 도시된 관계 데이터베이스에는, 테이블 1에 도시된 편성을 반영할 수 있는 추가적인 테이블이 제공되어 있다. 예를 들어, 회계 테이블(412)은 테이블 1에 정의된 모든 카테고리의 리스트를 포함하고 있으며, 인덱스(414)는 각각의 계정과 연관되어 있다. 이와 유사하게, 피고용인 테이블(416)은 연관된 인덱스(418)를 각각 갖고 있는, 테이블 1의 피고용인 성명을 포함하고 있다. 또한, 도4c에는, 각각의 성명에 대해, 그 사람이 (테이블 1에 도시된 하이어라키를 반영하는) 판매집단(sales force) 및 연구집단(research force)과 관련되어 있는지 여부에 대한 표시가 있다. 또한, 피고용인 위치를 나타내기 위한 필드가 포함되어 있다. 테이블 1의 편성을 반영하는, 법인체 #2의 다양한 프로젝트, 제품 및 자회사를 기입하기 위해 추가적인 테이블(도시 안됨)이 제공될 수도 있다.

도4d는 트랜잭션 테이블(402)의 각각의 레코드에 대해, 다른 테이블에 대한 원하는 링크를 표시하는 링크 테이블(422)을 도시하고 있다. 예를 들어, 만일 제1 트랜잭션(406a)이 현금 계정의 은행 #1 구성요소에 관련된 트랜잭션이면, 인덱스 값 #1을 가진 트랜잭션 레코드에 대해, 인덱스 #424를 가진 적절한 계정 레퍼런스가 있다는 것을 나타내는 레코드(428)가 제공되게 된다. 이와 유사하게, 피고용인 테이블(416) 및 다른 테이블(도시 안됨)에도 링크가 만들어 질 수 있다. 그러므로, 도1에서는, 계정, 자회사, 제품, 프로젝트 등의 각각의 가능한 조합에 대해 각각의 파일을 제공할 필요가 있는 반면에(비교적 복잡한 회계 구조에 대해서는 매우 많은 수의 파일을 초래할 가능성 있음), 도1의 예에서는 어떤 플랫 파일에 트랜잭션이 저장되어 있는지 알게됨으로써 얻어지는 정보를 링크 테이블(422)이 제공하는 도4a내지 도4f의 실시예에서는 단일의 트랜잭션 테이블(402)만이 필요로 된다.

통상적인 관계 데이터베이스에서는, 예를 들어, 특정 계정 및 특정 피고용인에 대한 트랜잭션과 같이, 소정의 기준에 부합하는 정보만을 식별하고 디스플레이하는 것이 가능하다. 일부의 데이터베이스 소프트웨어에서는, 예를 들어, 선택적인 정보가 공통적으로 필요로 될 때 사용하기 위한 기준 또는 "질의(queries)"를 저장하는 것이 가능하다. 도4e는 예를 들어, 구조적 질의 언어(structured query language:SQL)를 이용하여 이와 같은 다수의 질의를 저장하는 테이블을 도시하고 있다. 특정 데이터베이스 시스템에 사용되는 질의는 회사에 의해 데이터가 분석 또는 편성되는 방식을 반영할 수도 있다. 그러므로, 이와 같은 데이터베이스 내의 정보에 근거하여 리포팅 및 분석을 표준화하는데 관심을 가질 수도 있는 회계사는 다양한 저장된 질의(도4e)에 의해 표현되는 형태의 데이터 분석에 관해 알고 및/또는 그것을 재생할 수 있게 되길 원할 수도 있다.

또한, 사용자로 하여금, (디스플레이 또는 프린트를 위해) 리포트를 설계할 수 있도록 하고, 몇몇의 경우에는 예를 들어, 반복 사용을 위해 이와 같은 리포트를 정의하는 정보를 저장할 수 있도록 하는 많은 형태의 데이터베이스가 있다. 따라서, 이와 같은 리포트에 관한 정보를 보존하기 위해 관계 데이터베이스와 관련하여 또는 그 일부로서 다른 테이블 또는 테이블 셋트(도시 안됨)가 저장될 수도 있다.

도4a 내지 도4f에 도시된 정보 및 구조는 많은 상이한 방식으로 저장될 수 있다. 도5는 다수의 데이터 테이블, 링크 테이블, 질의 테이블 및/또는 리포트 포맷을 저장하기 위해 사용될 수 있는 디렉토리/파일 하이어라키를 도시하고 있다. 이러한 데이터는, 이 기술분야에 통상의 지식을 가진자는 이해할 수 있게 되는 바와 같이, 도3a 내지 도3c에 도시된 포맷 또는 다른 포맷과 같은 다수의 상이한 데이터 포맷으로 저장될 수 있다.

다양한 포맷으로 저장될 수 있는 정보의 다른 예로는 과학 또는 기술 정보가 있다. 도6에는, 예를 들어, 기상 연구(meteorological research)를 위해 지표 온도 정보를 저장하기 위한 플랫 파일 시스템이 제공되어 있다. 도6의 예에서, 각각의 파일(602a,602b,602c)은 그 헤더(604)에 도시된 특정 위치 및 측정 단위(예, 화씨 또는 섭씨)에 대한 정보를 저장한다. 각각의 레코드(606a,606b,606c)에 대해, 날짜와 각각의 시각에 대한 기록이 독립된 필드에 저장된다. 도7a 내지 도7d에는, 이러한 형태의 데이터를 저장하기 위한 관계 데이터베이스 시스템이 도시되어 있다. 데이터 테이블(702)은 모든 관측결과 및 각각의 관측결과에 대해 인덱스(704b)와 함께 측정 단위(704a)를 포함하고 있다. 테이블(706)(도7b) 및 테이블(708)(도7c)은 위치 및 하루중의 시각에 관한 정보를 저장하고 있다. (인덱스 값(704b)으로 표시된 바와 같이) 도7a에 저장된 소정의 데이터 포인트에 대해, 그 데이터 포인트와 관련된 위치 및 그 데이터 포인트와 관련된 하루중의 시각에 대한 인덱스 값을 표시하기 위해 링크 테이블(도7d)의 각각의 라인(722,724)이 사용될 수 있다. 비록 도6 및 도7a 내지 도7d의 예는 간략화되어 있지만, 이 기술분야에 통상의 지식을 가진자에게는, 풍속 및 풍향을 포함하는 기상 데이터, 라디오 음향 데이터 등과 같은 보다 복잡한 일련의 데이터를 저장하기 위해 정보 시스템을 어떻게 구성할지는 자명할 것이다. 만일 연구원이 2개의 기상 데이터 소스, 즉, 도6에 도시된 시스템에 정보를 저장하는 하나의 소스와 도7a 내지 도7d에 도시된 시스템에 정보를 저장하는 다른 소스로부터의 정보를 상호관련시키길 원하는 경우에, 이전의 방법에서는, 통상적으로, 컨설턴트 또는 다른 전문가가 도6 및 도7a 내지 도7d에 도시된 정보 저장 구조 및 편성을 분석하고, 그 데이터의 조합 또는 통합을 허용하는 방식으로 정보에 억세스하기 위한 시스템을 수동적으로 개발할 필요가 있었다.

도8은 상이한 정보 시스템 상에서 데이터를 억세스하고, 통합하고, 또는 조합하는 것과 관련하여 전술한 어려움을 극복하는데 사용하기 위한, 본 발명의 일실시예에 따른 시스템의 블록도이다. 도8의 실시예에서, 메인 프로세스(802)는 다수의 데이터 소스(806a,806b,806c,806d) 내의 정보를 분석 및/또는 억세스하는 것과 관련하여 필요로 될 때, 다양한 드라이버(804a,804b,804c,804d)를 선택적으로 활성화시킨다. 설명 목적을 위해, 도8에 도시된 소스 데이터(806a-806d)는 전술한 바와 같이, 플랫 파일 시스템, 데이터베이스, 스프레드시트 등과 같은, 데이터를 편성하거나 저장하기 위한 다수의 프로그램 또는 시스템 중 어느 것에 의해 저장되거나 생성된 데이터가 될 수 있다. 도8의 프로세스 및 데이터는 하나 또는 많은 컴퓨터 상에 존재할 수도 있다. 일실시예에서, 이 프로세스는 네트워크 서버 컴퓨터, 관련 디스크 또는 다른 기억장치, 및 하나 또는 그 이상의 클라이언트 컴퓨터를 구비한 근거리 통신망(LAN)과 관련하여 구현될 수 있다. 일실시예에서, 메인 프로세스(802)는 클라이언트 컴퓨터 상에서 실행되지만, 정보 소스(806) 및 새로운 데이터베이스(808)에 대한 데이터 파일은 네트워크 서버와 관련된 디스크(또는 다른 데이터 기억장치) 상에 저장된다. 본 발명은 인터넷 등을 통한, 광역 통신망, 모뎀 통신 등과 같은 통신 링크에 의해 링크되는 컴퓨터를 이용하여 복수의 비-네트워크 컴퓨터 또는 단일 컴퓨터와 같은 많은 다른 아키텍처로 구현될 수 있다. 본 발명을 구현하기 위해, IBM사(예, 386,486, 펜티엄, 또는 펜티엄 이상의 컴퓨터) 및 애플사(예, 매킨토시 컴퓨터)에 의해 생산된 컴퓨터 및 이와 같은 컴퓨터의 모조품과 같은 메인프레임 또는 개인용 컴퓨터를 포함하여 많은 형태의 컴퓨터가 사용될 수 있다. 일실시예에서, 프로세스는 DOS 운영체제 및/또는 마이크로소프트 윈도우 또는 윈도우 95 사용자 인터페이스를 이용하여 구현된다.

본 명세서에서 드라이버(804a-804d)로서 언급되는 항목은 소정의 데이터베이스 프로그램에서 제공되는 형태의 데이터 필터와 혼동해서는 안된다. 데이터 필터는 통상적으로, 사용자가 결정할 수 있는 기준에 따라, 소정의 레코드 및/또는 필드를 선택하기 위한 질의 또는 논리적 테스트의 형태이다. 한편, 보다 완전하게 후술되는 바와 같이, 드라이버(804a-804d)는 상이한 형태의 소스 데이터를 분석하고 억세스하기 위한 다수의 펑션(functions)을 가진 프로세스이다. 본 발명의 일실시예에서, 펑션 모듈(804)은 이 기술분야에 통상의 지식을 가진자가 본 명세서를 이해한 이후에 이해하게 되는 방식으로 동적 링크 라이브러리(dynamic link libraries)로서 제공된다. 이들 드라이버(804a-804d)는 특정 데이터베이스 프로그램을 이용하여 생성된 데이터 파일과 같이, 하나 또는 그 이상의 데이터 소스 형태와의 연산을 위해 구성된다. 데이터베이스 프로그램의 특성에 따라, 예를 들어, 데이터베이스 소프트웨어 패키지의 2개의 독립된 버전에 의해 생성되는 데이터 파일에 대해 2개의 독립된 드라이버를 구비하는 것이 필요할 수도 있다. 소정의 상황에서는, 2개의(또는 그 이상의) 상이한 형태 또는 브랜드의 소프트웨어(또는 주어진 브랜드의 데이터베이스 또는 다른 소프트웨어)를 이용하여 생성되는 데이터 파일과 관련하여 사용될 수 있는 단일의 드라이버를 제공하는 것이 가능할 수도 있다.

도8에 도시된 소스 데이터(806a-806d)는 일반적으로 어떠한 컴퓨터 판독가능 정보 소스도 될 수 있다. 그 예로는, 플랫 파일 소스 데이터, 계층 데이터베이스, 관계 데이터베이스, 스프레드시트 등이 있다. 비록 도8이 4개의 데이터 소스가 도시된 실시예를 예시하고 있지만, 본 발명은 단일의 데이터 소스만이 존재하거나 또는 5개 또는 그 이상의 데이터 소스가 존재하는 경우에도 사용될 수 있다. 비록 본 발명이 각각의 데이터 소스(806a-806d)가 다른 형태 또는 브랜드의 소프트웨어를 이용하여 생성되는 상황에 이용될 수 있지만, 또한, 2개 또는 그 이상의 데이터 소스가 동일한 브랜드 또는 형태의 데이터베이스 또는 다른 소프트웨어에 의해 생성되는 상황에 본 발명을 이용하는 것도 가능하다. 한 예로서, 제1 드라이버(804a)는 "dBaseⅡ"를 이용하여 생성된 데이터 파일로부터 정보를 검색하는데 사용하기 위해 구성되고, 제2 드라이버는 "dBaseⅢ"를 이용하여 생성된 데이터 파일로부터 정보를 검색하는데 사용하기 위해 구성되고, 제3 드라이버는 "Simply Accounting(상표)"과 같은 플랫 파일 시스템을 이용하여 생성된 데이터 파일로부터 정보를 검색하는데 사용하기 위해 구성되고, 제4 드라이버는 "Microsoft Access(상표)"를 이용하여 생성된 데이터 파일로부터 정보를 검색하는데 사용하기 위해 구성될 수 있다.

(보다 완전하게 후술되는 바와 같이) 일단 데이터 소스가 분석되었으면, 이러한 분석의 결과는, 검토 또는 편집을 위해 데이터 소스 내의 정보에 대한 사용자-억세스를 제공하는 것, 새로운 데이터베이스를 생성하기 위해 데이터의 일부 또는 전부, 바람직하게는 그 확장부(후술됨)를 카피하는 것, (검토, 프린트, 저장, 전송 등을 위해) 데이터 리포트, 질의 등을 생성하는 것을 포함하여, 다양한 방식으로 사용될 수 있다.

도8의 실시예에서, 메인 프로세스(804)는 드라이버(804)를 이용하여 소스 데이터(806a-806d)의 분석을 수행한 이후에, 다양한 데이터 소스(806a-806d)의 하나 또는 그 이상의 소스로부터의 데이터를 포함하는, 하나 또는 그 이상의 새로운 데이터베이스(808)를 생성할 수도 있다. 일실시예에서는, 각각의 데이터 소스에 대해 하나의 새로운 데이터베이스가 생성된다. 이와 같은 데이터베이스가 유사한 구조를 갖고 있을 때에는, 예를 들어, 표준 데이터베이스 기술을 이용하여 2개 또는 그 이상의 데이터베이스를 결합하는 것이 바람직할 수도 있다. 다른 실시예에서는, 하나의 데이터베이스(806)가 (예를 들어, 한 회사가 판매 정보를 저장하기 위해 한 데이터베이스 또는 다른 데이터 소스를 사용하고, 피고용인 정보를 저장하기 위해 다른 데이터베이스 또는 다른 데이터 소스를 사용하는 경우에) 2개 또는 그 이상의 데이터 소스로부터의 정보를 포함할 수도 있다. 새로운 데이터베이스(808)는 원하는 경우에, 예를 들어 리포트 라이터(writer)(810)를 이용하여 리포트를 생성하기 위해 사용될 수도 있으며, 또한, 원한 다면, 예를 들어, 데이터베이스 관리 시스템(812) 또는 다른 소프트웨어(814)를 이용하여 데이터를 입력, 검토 또는 분석하기 위해 사용될 수도 있다. 일실시예에서, 데이터베이스(808)는, 예를 들어, 표준 금융 리포트를 출력하는 것과 같은 데이터베이스 리포팅 및 분석을 제공하기 위해, 하나 또는 그 이상의 위저드(wizards), 템플릿(templates), 필터 및/또는 툴 키트 소프트웨어(이들 용어는 마이크로소프트 억세스 프로그래밍에 숙련된 사람은 이해할 것이다)를 가진 베이스 코드를 포함하는 Microsoft(상표) 억세스 데이터베이스이다. 일실시예에서, 금융 및 관리 리포팅 소프트웨어는 미국 워싱턴 벨리뷰 소재의 Timeline, Inc.로부터 이용할 수 있는 상표명 MV로 통용되는 확장부(extension) 또는 수정부(modification)로서 제공된다.

바람직하게는, 분석 시스템은 특정 목적 또는 그룹을 위한 리포트 또는 스크린을 생성하거나 제공하기 위해 구성된 모듈을 포함한다. 예를 들어, 도8의 실시예에서, 이그제큐티브(executive) 정보 시스템(EIS)은 바람직하게는 이지-투-유즈(easy-to-use) 사용자 인터페이스를 갖추고 있으며, 바람직하게는, (바 차트와 파이 차트 사이에서 선택하고, 리포팅 주기를 선택하고, 계간 대 주간 리포트를 선택하는 등의 선택을 위해) 네비게이션 툴 또는 그래픽 셀렉터를 이용하여 다양한 스프레드시트, 프리젠테이션 그래픽스 또는 프린트된 형식으로 데이터의 분석을 출력하도록 구성된다. 일실시예에서, 이그제큐티브에는, 전술한 자동 롤업 생성 절차를 이용하여 자동적으로 생성 또는 검출될 수 있는 뷰를 포함하여, 다양한 데이터 뷰의 메뉴가 제공된다.

일실시예에서, 새로운 데이터베이스(808) 내의 정보는 소스 데이터(806a-806d)에 의해 또는 그것을 이용하여 디스플레이되거나 출력되지 않았던 데이터의 분석 또는 관계를 생성하고, 디스플레이 또는 출력하도록 구성된다는 점에서, 예를 들어, 메인 프로세스(802)에 의해 확장된다.

도9는 다양한 드라이버(804a-804d)의 개략도이다. 각각의 드라이버는 다수의 정의된 프로세스 또는 펑션(901-909)을 포함한다. 각각의 펑션은 에를 들어, 후술되는 도10에 도시된 하나 또는 그 이상의 단계를 구현하고 실행하기 위해, 컴퓨터 프로그램 명령어(912)를 포함할 수도 있다. 일실시예에서, 각각의 펑션(901-909)은 호출가능한 서브루틴 또는 절차(procedure)이다. 소정의 드라이버(804b)에서 정의된 펑션(901-909)은 소스 데이터(806a,806b)의 형태에 따라 다르게 수행 또는 실행되어야 하는 펑션을 포함한다. 그러므로, 예를 들어, 원하는 정보가 저장된 하드 디스크 또는 다른 정보 기억장치 상에서 소정의 디렉토리를 선택하도록 설계된 펑션인 펑션 1(901)에 관해서, 디렉토리를 선택하기 위한 절차는 예를 들어, 도2의 예와 도5의 예의 비교로부터 알 수 있는 바와 같이, 소스 데이터(806)의 형태에 따라 달라지게 된다. 따라서, 제1 드라이버(804a)에서 펑션 1을 구현하는 프로그래밍 코드(912)는 제2 드라이버(804b)에서 대응하는 펑션을 구현하는 프로그래밍 코드와 다를 수도 있다. 이러한 방식으로, 각각의 드라이버는 하나의 펑션을 수행하기 위해 하나 또는 그 이상의 프로세스를 정의하며, 이와 같은 절차는 2개 또는 그 이상의 상이한 형태의 소스 데이터의 상이한 특성을 수용하도록 구성된다. 예를 들어, 도11a는 도2에 도시된 디렉토리 구조와 관련하여 디렉토리를 선택 및/또는 탐색하는 것과 관련하여 사용될 수도 있는 형태의, 의사-코드로 표현된, 절차의 일부분을 도시하고, 도11b는 도5에 도시된 디렉토리 구조에 대한 디렉토리를 선택 또는 탐색하는 것과 관련하여 사용될 수도 있는 절차에 대한 의사-코드의 대응하는 부분을 도시하고 있다. 이 기술분야에 통상의 지식을 가진자는 도11a 및 도11b의 예로부터, 2개의 상이한 형태의 소스 데이터에 대해 동일한 펑션을 수행하기 위해 드라이버를 어떻게 구성해야 하는지 이해할 것이다. 비록 도9는 9개의 펑션을 가진 펑션 모듈을 도시하고 있지만, 본 발명은 보다 많거나 보다 적은 수의 펑션을 가진 펑션 모듈에 관해서도 이용될 수 있다. 상이한 펑션 모듈이 상이한 수의 펑션을 정의하고, 및/또는 하나 또는 그 이상의 펑션이 널(null)값 또는 상수값 또는 정보를 제공 또는 반송하도록 구성된 시스템을 구성하는 것이 가능하다.

도10에 도시된 방법을 시작하기 위해(단계 1002) 많은 절차가 사용될 수 있다. 일실시예에서, 도10의 방법은 하드 디스크, CD-ROM, 또는 비-휘발성 매체와 같은 매체 상에 저장된 컴퓨터 프로그램을 이용하여 구현되며, 이 방법은 프로그램을 런치(launch)하기 위해, 즉, 프로그램을 메모리에 로드하여 그 프로그램을 실행시키기 위해 (예를 들어, 키보드, 마스크 등을 통해) 컴퓨터로 명령을 발생함으로써 시작된다. 대안으로, 이 프로그램은 다른 프로그램에 의해 런치될 수도 있다. 예를 들어, 일실시예에서, 새로운 데이터베이스(808)는 프로그램을 런치하기 위해 소위 "위저드"로 불리는 것과 같은 루틴을 포함할 수 있는 마이크로소프트 억세스 데이터베이스이며, 이 프로그램(도10)은 다음에, 이 데이터베이스(808)를 점유하거나 갱신하기 위해 정보 소스(806) 내의 데이터에 억세스한다. 이 실시예에서는, 사용자 인터페이스가 그 데이터베이스(808)에 대한 사용자 인터페이스와 일치되는 상황을 갖게 되도록 필요할 때(예, 단계 1020에서) 사용자 입력을 요구하기 위한 목적으로 프롬프트 또는 "다이얼로그 박스"를 디스플레이하기 위해 위저드를 사용하는 것이 유용할 수 있다.

도10에 도시된 절차에서, 개시 절차(1002) 이후의 제1 단계는 동적 드라이버를 식별하고 초기화하는 것이다(단계 1004). 이와 관련하여, 드라이버는 그것이 예를 들어, 새로운 또는 다른 형태의 데이터 소스를 수용하도록 모듈 방식으로 추가 또는 삭제될 수 있다는 점에서 동적인 것으로 간주된다. 예를 들어, 사용자는 처음에는, 4개의 드라이버를 가진 도8에 도시된 것과 같은 시스템을 갖출수도 있지만, 장래에는, 소프트웨어 판매상으로부터 구입하거나, 정보 서비스, 네트워크, 인터넷 접속 등을 통해 다운로드 받거나, 또는 주문(custom) 드라이버를 기록함으로써 추가적인 드라이버를 추가할 수도 있다. 드라이버의 모듈 특성 또는동적 특성으로 인해, 어떤 드라이버가 이용가능한지 사전에 알지 못하며, 따라서, 프로그램이 개시될 때(단계 1002), 그 프로그램은 그것에 이용가능한 드라이버를 식별한다. 일실시예에서, 이것은 소정의 (부분적인) 파일 명칭 또는 파일 확장부를 가진 파일에 대해 디스크 또는 그 디렉토리를 탐색함으로써 수행된다. 일실시예에서, 이 프로그램은 또한, 이와 같은 파일 명칭 및/또는 파일 확장부에 의해 식별된 파일이 원하는 드라이버인지 검증하기 위해, 예를 들어, 헤더 정보와 같은 각 파일의 선택된 부분을 분석할 수도 있다. 드라이버를 초기화하는 것은 일반적으로, 드라이버 펑션을 식별하고 링킹하는 것과 각각의 드라이버 내의 데이터를 초기화하는 것을 포함한다.

다음에는, 그 절차가 임포트 또는 갱신을 수행할 것인지 판단한다(단계 1006). 임포트의 경우에, 데이터 소스 내의 데이터 및 구조의 모두 또는 대부분이 억세스되어 새로운 데이터베이스로 저장되는 절차가 먼저 수행된다. 갱신의 경우에는, 예를 들어, 새로운 데이터베이스(808) 내의 정보가 데이터 소스(806)에 대해 이루어졌을 수도 있는 최근의 변경 또는 추가를 반영하도록 보장하기 위해 데이터 및/또는 구조의 선택된 부분만이 억세스되는 절차가 수행된다. 통상적인 상황에서는, 임포트는 도8의 시스템이 소정의 데이터 소스로부터의 정보를 억세스 또는 사용할 때 첫 번째로, 또는 그 데이터 소스에 대해 비교적 중요한 변경 또는 추가가 이루어진 경우에 수행되게 된다. 통상적으로, 갱신은 소스 데이터(806) 내의 데이터를 새로운 데이터베이스(808) 내의 데이터와 동기시키기 위해 규칙적인 방식으로(예, 매일 또는 매주에 한 번씩) 수행되게 된다. 일실시예에서, 임포트 또는 갱신에 대한 선택(단계 1006)은 그 절차가 특정 데이터 소스에 억세스한 첫 번째가 아닌한 갱신을 수행함으로써 자동적으로 수행된다. 다른 실시예에서, 사용자는 예를 들어, 키보드 선택을 통하거나 포인터 장치를 이용하여 입력을 제공함으로써 임포트와 갱신 사이에서 선택하도록 허용된다.

만일 임포트가 선택되면(단계 1008), 메인 프로세스(802)는 탐색할 디렉토리를 선택하기 위해 하나 또는 그 이상의 드라이버의 펑션의 실행을 개시하게 된다(단계 1010). 메인 프로세스(802)에 의해 로드되거나 호출되는 드라이버(804)는 어떤 형태의 데이터 소스가 억세스되는가에 따라 달라진다. 특히, 소정의 데이터 소스(806a)에 대해, 메인 프로세스(802)는 그 형태의 소스 데이터(806a)를 수용하도록 구성된 드라이버(804b)를 사용하게 된다. 만일 하나 이상의 데이터 소스(806)가 억세스되는 경우에는, 메인 프로세스(802)는 어느 것이든지 소스 데이터(806)의 각각의 형태를 위해 구성된 드라이버(804)를 사용하게 된다. 데이터 소스의 형태는 파일 및/또는 디렉토리의 명칭(또는 "확장부"), 파일의 수, 크기 및 구조, 그 파일 내의 헤더 또는 다른 정보와 같은 특성에 근거하여 자동적으로 판단되는 것이 바람직하다. 다른 실시예에서, 사용자는 (예를 들어, 데이터 소스 파일을 생성하기 위해 사용된 소프트웨어의 브랜드명 및 버전 번호를 식별하거나, 또는 사용자가 그 절차에 의해 단지 국부적인 디스크 파일만을 탐색하길 원하는지 또는 네트워크 파일을 포함하는 탐색을 수행하길 원하는지를 표시함으로써) 데이터 소스의 형태를 표시하도록 허용되거나 요구된다. 단계(1010)의 종료 이후에, 메인 프로세스(802)는 단계(1004)에서 식별된 드라이버(804)에 의해 식별되는 바와 같은 모든 데이터 소스(806)에 대해 탐색될 디렉토리의 저장된 리스트에 억세스하게 된다. 단계(1010) 이후에, 메인 프로세스(802)는 임포트될 데이터에 대해 단계(1010)에서 선택된 디렉토리를 탐색하기 위해, 펑션 모듈(804a-804d)의 다른 펑션(902)을 로드하거나 활성화 또는 호출한다(단계 1012). 디렉토리의 탐색(단계 1012)은 정보가 상이한 데이터 소스(806)에 어떻게 저장되어 있는가에 의존하게 되는 방식으로 수행된다. 예를 들어, 일부 형태의 소스 데이터에 대해서는, 소정의 파일명 및/또는 소정의 파일 확장부를 가진 파일을 식별하는 것으로 충분할 수도 있다. 다른 형태의 데이터 소스(806)에 대해서는, 예를 들어, 파일의 헤더 부분 또는 그외의 곳에 소정의 구조 또는 내용을 가진 파일을 식별하기 위해 다양한 파일 내의 데이터를 스캐닝할 필요가 있을 수도 있다. 그러므로, 상이한 모듈(804)은 상이한 데이터 소스(806)를 수용하기 위해 상이한 방식으로 "디렉토리 탐색" 펑션(902)을 제공하도록 구성되게 된다.

만일 임포트(단계 1008)가 아니라 갱신(단계 1014)이 수행되는 경우에는, 바람직하게는 임포트가 최초로 수행될 때, 디렉토리를 선택하고 탐색하기 위한 펑션(901,902)의 결과가 나중에 메인 프로세스(802)에 의해 억세스될 수 있는 방식으로 저장되기 때문에, 디렉토리를 선택하고 탐색할 필요가 없다. 그러므로, 이와 같은 저장된 정보를 이용하여, 메인 프로세스(802)는 이전에 임포트되거나 갱신된 데이터를 식별할 수 있게 된다. 일실시예에서, 이것은 리던던트 데이터, 즉 새로운 데이터베이스(808)에 이미 존재하는 데이터를 로딩하는 것을 방지하기에 유용하다. 일반적으로, 전면 갱신(full update)에 있어서는, 단계(1016)에서, 데이터베이스(808) 내의 기존의 적어도 일부의 데이터가 재로드되지 않게 되도록 최종 임포트 또는 갱신 이후에 새로운 또는 변경된 데이터를 식별하는 것이 바람직하다. 일실시예에서는, 리던던트 데이터의 로딩을 방지하기 위해, 시스템은 최종 임포트 또는 갱신 이후에 변경되지 않은 데이터를 식별하기 위해 시도하게 된다. 일반적으로, 만일 이러한 절차가 수반되는 경우에, 그 절차의 종료 시점에서 새로운 데이터베이스(808) 내의 데이터는 소스 데이터(806) 내의 정보와 동기되게 되는데, 즉, 이것은 그 현재의 상태에서 데이터 소스(806)의 구조 및 데이터를 정확하게 나타내는 정보를 포함하게 된다.

도10의 실시예에서는, 사용자에게 임포트 또는 갱신될 데이터를 선택하거나, 또는 소정의 데이터를 임포트 또는 갱신하는 것을 중지할 것을 선택할 기회를 제공하기 위해, 임포트 또는 갱신될 데이터의 신분이 디스플레이된다(단계 1018). 갱신 또는 임포트될 데이터의 표시가 디스플레이를 위해 편성되는 방식은 어떤 형태의 데이터 소스가 억세스되는가에 의존하게 되며, 따라서, 드라이버(804)중 한 드라이버의 펑션(902a)의 호출 또는 활성화에 응답하여 제공되게 된다. 예를 들어, 도4a 내지 도4f에 도시된 데이터 소스와 관련하여 사용하기 위해 구성된 드라이버의 펑션(902a)은 사용자에게 다른 회사에 대한 것을 제외하고, 일부 회사에 대한 데이터를 임포트 또는 갱신할 기회를 제공하기 위해 테이블(430)(도4f)로부터 얻은 자회사의 리스트를 디스플레이할 수도 있다. 바람직하게는, 사용자는 디스플레이된 리스트로부터 하나 또는 그 이상의 회사를 선택할 수 있다. 선택 단계(1018,1020)에서의 디스플레이는 예를 들어, 드라이버의 디스플레이 펑션(902a)이 어떻게 기록 또는 구성되는가에 따라, 소정의 피고용인(416) 또는 소정의 계정(412)에 특정된 데이터의 선택을 디스플레이하고 허용하기 위해, 데이터 소스 내의 다른 형태의 편성 또는 데이터에 대해 반복될 수 있다.

보다 상세하게 후술되는 바와 같이, 몇몇의 경우에는, 새로운 데이터베이스(808)가 생성된 이후에, 사용자는 데이터를 생성, 저장, 편집 및 일부의 경우에는 데이터를 검토하기 위해 원래의 정보 소스(806a-806d)를 게속해서 이용하게 된다. 그러므로, 본 발명은 사용자가 그 사용자에게 이미 친숙한 데이터베이스(806), 사용자 인터페이스 등을 계속 이용하길 원하는 상황과도 호환성이 있다. 그러나, 이러한 경우에는, 새로운 데이터베이스(808)가 최초로 생성된(또는 마지막으로 갱신된) 이후에 발생한 정보 소스(806a-806d) 내의 새로운 또는 편집된 데이터를 반영하도록, 때때로 새로운 데이터베이스(808)를 갱신하는 것이 바람직하다. 이러한 갱신을 수행하기 위한 한가지 방식은 (후술되는 바와 같이) 데이터베이스(808)를 생성하는 전체 프로세스를 반복하는 것이다. 그러나, 많은 상황에서, 이것은 비효율적이며, 그 이유는 최초에 생성된 새로운 데이터베이스(808)의 상당한 부분이 변경되지 않고 여전히 유효하기 때문이다. 그러므로, 본 발명의 일실시예에 따르면, 데이터베이스(808)의 최종 갱신 이후에 변경된 정보 소스(806a-806d)로부터의 데이터에 대해서만, 새로운 데이터베이스(808)가 갱신될 수 있도록 허용하는 절차가 제공된다.

새로운 데이터베이스(808)가 갱신되어야 하는 빈도는 그 데이터베이스(808)의 다양한 이용이 행해지는 빈도에 의존한다. 그러므로, 일주일에 한 번씩만 억세스되는 경우에 데이터베이스(808)를 매일 갱신하는 것은 큰 의미가 없을 수도 있다. 또한, 갱신에 포함되는 특정 정보는 새로운 데이터베이스(808)에 대해 행해지는 이용에 따라 변화될 수도 있다. 그러므로, 만일 공장 생산 데이터가 관리에 의해 단지 분기별로 검토되는 경우에는, 예를 들어, 지역적인 판매를 검토하기 위해 사용될 수도 있는 매주 마다의 갱신에 이와 같은 데이터를 포함시킬 필요가 없다. 다양한 형태의 갱신을 정의하는 하나 또는 그 이상의 프로파일이 생성되어 저장되는 것이 바람직하며, 또한 스케쥴러도 생성되어 저장되는 것이 바람직하다. 스케쥴러는 (사람이 이와 같은 갱신을 개시하기 위해 "달력에 기입하거나(calendar)" 또는 기억할 필요 없이) 이와 같은 갱신을 자동적으로 실행하는 시기를 정의하기 위해 사용된다. 바람직하게는, 예를 들어, 매주 판매 회의 이전에 지역 판매 갱신 절차를 매주 한 번씩 자동적으로 실행하고, 매분기별 생산 검토 이전에 생산 데이터의 매분기별 갱신을 스케쥴링하는 스케쥴러를 제공하는 것과 같이, 상이한 갱신 프로파일이 상이한 시기 또는 간격으로 실행되도록 스케쥴링된다.

도8의 시스템을 이용하는 다른 사람은 매일 매일의 운영을 위해 시스템의 다른 구성요소(예, 정보 소스(806a-806d) 또는 새로운 데이터베이스(808))를 사용할 수도 있기 때문에, 새로운 데이터베이스와 함께 프로파일(822)이 저장되거나, 또는 이전의 데이터베이스와 함께 프로파일(824a-824d)(정보 소스(806a-806d)에 정보를 저장하기 위한 적절한 "기록 허가"가 있는 경우)이 저장될 수도 있으며, 또는 둘다와 함께 저장될 수도 있다.

프로파일을 생성하기 위해 다양한 방식이 사용될 수 있다. 사용자가 (예를 들어, 마이크로소프트 억세스 위저드에 제공된 것과 같은 미리정해진 일련의 스크린 형식 또는 다이얼로그 박스를 통해) 갱신 프로파일의 생성을 요구할 수 있도록 하기 위한 (메뉴 선택사항 또는 버튼과 같은) 명령을 포함시키는 것이 가능하다. 또한, 예를 들어, 사용자가 정의된 파일에 현재 없는 데이터를 이용하는(또는, 그 데이터에 대한 현재의 프로파일 갱신 빈도 보다 더욱 빈번하게 데이터를 이용하는) 스크린 또는 프린트된 리포트를 요구할 때마다, 사용자가 프로파일의 생성 또는 편집에 관한 결정을 행할 것을 자동적으로 촉구하는 것도 가능하다. 일실시예에서, 데이터베이스(808)의 각각의 필드를 기입하고, 각각의 필드에 대해, 그 데이터베이스를 갱신하기 위한 기존의 프로파일이 있는지 여부, 그러한 프로파일의 신분 또는 명칭 및 현재의 갱신 빈도 또는 간격을 표시하는 데이터베이스 테이블을 생성함으로써, 프로파일(822)이 생성된다.

자동적으로 스케쥴링된 갱신 뿐만 아니라, 도8의 시스템의 사용자에게는 또한, 바람직하게도, 언제라도 갱신을 요구하기 위한 옵션이 제공되며, 또한, 바람직하게도, 사전정의된 갱신 프로파일 중에서 선택하거나 전면 갱신을 요구하기 위한 옵션이 제공된다. 만일 원한다면, 이 시스템은 갱신될 이 데이터 셋트가 (전술한 바와 같이) 프로파일로서 저장되어야 하는지에 관한 결정을 행하도록 사용자에게 촉구할 수도 있다. 이 시스템은 또한, 사용자가 (자회사의 리스트와 같은) 디스플레이된 데이터 중에서 선택하는 것이 아니라 사전정의된 프로파일 중에서 선택할 수 있도록 이미 존재하는 또는 정의된 프로파일의 리스트를 제공할 수도 있다.

몇몇의 경우에는, 데이터 소스로부터 이용가능한 모든 정보를 항상 임포트 또는 갱신(전면 갱신)하는 것이 바람직하다는 것이 미리 결정 될 수도 있으며, 따라서, 적용된 드라이버에 대한 펑션(902a)은 단지 프로그램 흐름을 메인 프로세스(802)로 복귀할 수 있다. 예를 들어, 도7a 내지 도7d에 도시된 데이터 소스에 관하여, 모든 위치로부터의 모든 이용가능한 지표 온도 데이터가 항상 모든 임포트 또는 갱신에 포함되는 것으로 결정될 수도 있다. 일실시예에서는, 사용자에게 정보를 포함하는 디렉토리, 서브디렉토리 및 파일의 디스플레이와 같은, 사용자의 선택에 대응하는 데이터의 위치를 나타내는 디스플레이가 제공될 수 있으며, 또한, 선택적으로는, 어떤 디렉토리 및 파일 등이 억세스될 것인지 선택하기 위한 기회가 제공될 수도 있다.

일단 예를 들어, 단계(1018,1020)에 의해, 어떤 데이터가 임포트 또는 갱신될 것인지 결정되면, 단계(1022)에서 일반적인 정보가 로드된다. 만일 2개 또는 그 이상의 데이터 소스로부터 정보에 억세스하는 것이 요구되는 경우에, 이것은 직렬로(즉, 제1 모듈을 이용하여 제1 데이터 소스에 대해 단계(1022-1046)를 수행하고, 그 다음에, 적절한 드라이버를 이용하여 제2 데이터 소스에 대해 단계(1022-1046)를 수행함으로써) 수행되거나, 또는 병렬로(즉, 각각의 정보 모듈 상에서 나중의 단계를 수행하기 전에 적절한 드라이버를 이용하여 각각의 원하는 데이터 소스에 대한 단계를 수행함으로써) 수행될 수 있다.

일반적인 정보는 데이터 소스 내의 데이터의 구조에 관한 정보를 포함한다. 단계(1022)에서 로드되는 일반적인 정보의 형태는 소스 데이터의 다양한 형태에 따라 변하게 된다. 예를 들어, 도4a 내지 도4f에 도시된 것과 같은 데이터베이스와 관련하여 사용하기 위해 기록 또는 구성된 펑션(903)에 있어서, 일반 정보는 예를 들어, 데이터 소스(806)에서 사용된 계정 또는 다른 카테고리의 신분을 포함할 수도 있다. 한편, 만일 펑션(903)이 도1에 도시된 데이터 소스와 관련하여 사용하기 위해 기록 또는 구성된 경우에는, 여전히, 얼마나 많은 구성요소가 데이터 소스에 사용되었는지 판단할 것이 요구될 수도 있지만, 이 경우에, 이 정보는 데이터 소스(806)에서 발견되는 플랫 파일(101a-101f)의 수에 의해 결정되게 된다. 일반 정보는 또한, 데이터 소스(806)에서 얼마나 많은 프로젝트(112), 얼마나 많은 제품(114) 및/또는 제품 라인(116), 또는 얼마나 많은 자회사(118)가 정의되어 있는지와 같은 정보를 포함할 수 있다. 일반 정보는 또한, 회사명, 회계년도의 첫 번째 달, 및 일반적으로, (단계(1024,1033,1036)에서 로드되는, 통상적으로는 루프에서 로드되는 정보와 대비하여) 한 번에 로드될 수 있는 다른 정보를 포함할 수 있다. 만일 "일반 정보 로딩" 펑션(903)이 도6에 도시된 데이터 소스와 관련하여 사용하기 위해 구성된 드라이버에 제공되면, 데이터베이스 내의 위치(602)의 번호와 같은 일반 정보가 단계(1022)에서 로드될 수 있다.

메인 프로세스(802)는 또한, 데이터 정의(definitions)를 로드하기 위해 적절한 드라이버 또는 모듈(804)의 펑션(904)을 호출 또는 활성화시킬 수 있다. 데이터 정의는 데이터 소스(806) 내의 데이터의 특정 클래스 또는 카테고리에 대한 식별자로서 저장된 텍스트명, 필드 크기, 데이터의 형태(스트링, 정수 또는 10진수, 10진 자리의 번호) 및 데이터의 다양한 카테고리에 대한 이와 유사한 특성과 같은 정보를 포함할 수 있다. 바람직하게는, 데이터 정의의 로딩은 새로운 데이터베이스 상에서 수행될 리포팅 또는 분석의 형태에 대해 필요한 모든 구조 및 데이터를 포함하게 되는 하나 또는 그 이상의 새로운 데이터베이스(808)를 생성하기 위해 요구되는 바와 같이, 데이터 소스 내의 데이터 요소 및 데이터 소스 내의 정보의 아키텍처 또는 구조의 표시를 저장하는데 필요한 정보를 얻기 위한 데이터의 문의(interrogation)를 포함한다. "데이터 정의 로딩" 단계에서의 데이터의 문의는 그것이 사실상 어떠한 데이터 소스에도 합치될 수 있고, 예를 들어, 리포팅 및 분석을 위해 데이터 소스의 표준 형식을 저장하는데 필요한 것을 식별할 수 있다는 점에서 지능형 문의이다. 도4a 내지 도4f의 예에서, 소스 데이터의 아키텍처를 표시하기 위해 필요한 정보는 예를 들어, 4개의 계정 부분의 명칭(계정, 회사, 피고용인 및 위치) 뿐만 아니라, 소정의 스트링 계정 부분을 저장하기 위해 필요한 데이터 형태(예, 수치 또는 스트링) 및 길이도 포함하게 된다. 도6의 예에서, 데이터 소스의 아키텍처를 표시하기 위해 필요한 정보는 계정 부분의 명칭(위치 및 날짜) 뿐만 아니라 그 데이터에 대해 사용된 기준의 명칭(단위)을 저장하는 것을 포함한다. 문의는 예를 들어, 송장(invoice) 번호와 같이, 로드될 수 있는 다른 선택적인 데이터를 식별하는 것을 포함할 수 있다. 수행되는 문의의 특정 형태는 분석되는 특정 데이터 소스의 특성에 의존하게 되며, 따라서, 각각의 드라이버(804)에 따라 다르다. 일반적으로, 데이터 또는 정보를 로딩하는 단계(1022,1024,1033,1036)는 드라이버(804) 내의 펑션에 의해 수행되고, 정보를 세이브하는 단계(1026,1028,1030,1032,1034,1038)는 메인 프로세스(802)에 의해 수행된다.

메인 프로세스(802)는 다음에, 데이터베이스 리포지토리(repository)를 식별 또는 생성하게 되는데(단계 1026), 즉, 데이터 소스(806)로부터 로드된 정보가 세이브되게 되는 위치로서 작용하게 되는 새로운 데이터베이스(808) 내의 파일 또는 다른 데이터 저장 구조를 식별 또는 생성하게 된다. 갱신은 통상적으로, 새로운 데이터베이스 또는 데이터베이스 테이블을 생성하는 것을 필요로 하지 않는데, 그 이유는 갱신이 통상적으로는 단순히 기존의 데이터베이스 내의 기존의 테이블에 추가하는 것이기 때문이다.

다음에, 메인 프로세스(802)는 소스 데이터로부터 새로운 데이터베이스(808)로 세이브된 데이터를 저장하기 위해 사용되게 되는 데이터베이스 테이블을 생성하기 위해 하나 또는 그 이상의 드라이버의 적절한 펑션(905)을 호출한다(단계 1028). 데이터베이스 테이블이 생성되게 되는 방식은 바람직하게는 데이터 소스(806) 및 데이터의 구조와 예를 들어, 분석, 리포트 생성 등을 위해 새로운 데이터베이스(808)가 사용되게 되는 방식을 고려한다. 생성된 특정 테이블은 (예를 들어, 단계(1022,1024)에 의해 결정되는 바와 같이) 데이터 소스(806) 내의 정보의 특성에 따라 변화되기 때문에, 데이터베이스 테이블을 생성하는 것은(단계 1028) 억세스를 위해 사용되는 특정 데이터베이스를 위해 구성된 드라이버(804)에 의해 제공되는 펑션이다. 예를 들어, "데이터베이스 테이블 생성" 펑션(905)이 도4a 내지 도4f에 도시된 바와 같은 데이터 소스와 관련하여 사용하기 위해 기록 또는 구성되는 경우에, 생성되는 데이터베이스 테이블은 예를 들어, 계정 테이블, 피고용인 테이블, 자회사 테이블(계정의 롤업이 될 수 있음), 및 세부사항 테이블(보다 상세하게 후술됨)을 포함할 수 있으며, 반면에, 도7a 내지 도7d에 도시된 데이터베이스와 관련하여 사용하기 위해 구성된 드라이버에 기록 또는 제공된 "데이터베이스 테이블 생성" 펑션은 위치 테이블, 날짜 테이블, 시간 테이블, 단위 테이블 및 세부사항(detail) 테이블을 포함할 수 있다. 바람직하게도, 새로운 데이터베이스(808)에서 생성된 테이블은 그것이 다양한 데이터 소스(806)에서 발견될 수도 있는 사실상 어떤 형태의 데이터 정의 또는 구조도 수용할 수 있다는 점에서 동적인 구조 또는 아키텍처를 갖는다. 일실시예에서, 새로운 데이터베이스(808)는 기본적으로 리포트 및 분석을 생성하는 것과 같은 정보를 출력하기 위해 사용되도록 의도된 것이며, 따라서, 후술되는 바와 같이, 이용가능한 출력 및 데이터 분석의 형태에서의 높은 유연성 및 이와 같은 분석 및/또는 출력의 비교적 빠른 실행과 같은 우수한 출력 성능을 제공하도록 구성되는 것이 바람직하다. 이와 관련하여, 한 데이터베이스가 소정의 다른 가능한 구성의 속도 또는 유연성 보다 양호한 출력의 속도 또는 유연성을 제공한다면, 그것은 출력의 속도 및/또는 유연성에 대해 최적화된 것이다. 그러므로, 이와 관련하여, "최적화된다"는 것이 반드시 수학적으로 정확한 최적화를 요구하는 것은 아니다. 일실시예에서는, 단계(1028)에서, 3개의 일반적인 형태의 테이블, 즉, (적절한 경우에 롤업 테이블을 포함하는) 다수의 카테고리 테이블, 적어도 하나의 세부사항 테이블 및 적어도 하나의 엔트리 테이블이 제공된다. 바람직하게는, 카테고리 테이블은 특정 데이터 포인트 또는 레코드가 분류될 수 있는 각각의 방식에 대해 제공된다. 예를 들어, 만일 "데이터베이스 테이블 생성" 펑션(905)이 도4a 내지 도4f에 도시된 바와 같은 데이터베이스와 함께 사용하기 위해 구성된 드라이버(804)에서 제공되면, 도12에 도시된 바와 같이, 새로운 데이터베이스는 예를 들어, 계정의 모든 가능한 계정 카테고리를 기입하는 계정 테이블(1203), 데이터 소스(806)에서 발견되는 모든 가능한 자회사를 기입하는 자회사 테이블(1230), 데이터 소스(806)에서 주목되는 모든 제품을 기입하는 제품 테이블(1232), 데이터 소스(806)에서 주목되는 모든 피고용인을 기입하는 피고용인 테이블(1216), 및 데이터 소스(806)에서 주목되는 다양한 위치, 판매지역 등을 기입하는 위치 테이블(1234)을 포함하는 다수의 카테고리 테이블(1202)을 포함하게 된다. 도시된 실시예에서, 각각의 카테고리 테이블(1202) 내의 각각의 레코드 또는 항목은 후술되는 바와 같이 세부사항 테이블에 사용하기 위한 인덱스와 연관되어 있다.

도12에 도시된 실시예에서는, 일단 점유되면, 데이터 소스(806)에서의 각각의 회계 엔트리 또는 트랜잭션에 대한 레코드를 갖게 되는 세부사항 테이블(1240)이 제공되게 된다. 도12에 도시된 실시예에서는, 필드(1244)에 대해, 데이터 소스에서의 트랜잭션(도4a)에 대응하는, 날짜 필드(1242b), 종류 필드(1242c), 수량 필드(1242d), 및 총계 필드(1242e)가 제공된다. 각각의 레코드에 대한 식별자 번호 또는 인덱스 번호를 저장하기 위한 인덱스 필드(1242a)도 제공된다. 또한, 각각의 레코드에 대해, 계정 카테고리(1242f), 자회사 카테고리(1242g), 제품 카테고리(1242h), 및 피고용인 카테고리(1242i)를 포함하여, 도12의 예에서 일반 정보 로딩 단계(1022)에서 정의된 각각의 카테고리에 대한 적절한 정보의 표시를 저장하기 위해 독립된 필드가 제공된다. 일반적으로, 데이터를 분석 또는 컴퓨팅하기 위해 필요한 만큼, 데이터 소스(806)에 존재하는 많은 상이한 필드, 즉 카테고리를 제공하는 것이 바람직하다. 그러므로, 그 트랜잭션이 관련되어 있는 계정에 따라 트랜잭션을 그룹화하는 리포트를 출력하는 것이 바람직할 수 있기 때문에, 계정 카테고리를 구비하는 것이 유용하다. 또한, 원하는 회계 목적에 따라, 각각의 자회사에 대해 독립된 리포트를 프린트하거나 또는 트랜잭션이 자회사에 의해 그룹화되는 리포트를 프린트하는 것이 바람직할 수도 있으며, 따라서, 자회사 카테고리(1242g)를 구비하는 것이 유용하다. 일반적으로, 데이터를 선택, 그룹화, 리포팅, 프린팅 또는 분석하는 각각의 방법에 대해, 독립된 필드가 세부사항 테이블(1240)에 제공될 수도 있다.

도12에 도시된 데이터베이스의 구조는 도4a 내지 도4f에 도시된 데이터 소스의 구조 및 도1에 도시된 데이터 소스의 구조와 현저한 차이가 있을 수 있다. 예를 들어, 도4a 내지 도4f에 도시된 구조에서는, 특정 트랜잭션(도4a)이 특정 계정(도4b)과 연관되는 방식이 독립된 링크 테이블(도4d)에 표시되어 있지만, 도12의 예에서는, 적절한 계정(1242f)에 대한 인덱스가 트랜잭션 정보를 포함하는 동일한 레코드의 그 고유의 필드(1244)에 저장되게 된다. 그러므로, 비록 도12에 도시된 바와 같은 테이블을 가진 데이터베이스(808)가 도1에 도시된 바와 같은 데이터 소스아 또는 도4a 내지 도4f에 도시된 바와 같은 데이터 소스(또는 다른 방식으로 구성된 데이터 소스)에서 발견되는 정보를 저장할 수 있지만, 도12의 예의 데이터베이스의 구조 또는 아키텍처는 도1에 도시된 데이터 소스 또는 도4a 내지 도4f에 도시된 데이터 소스의 구조와는 다르다. 이와 유사하게, 비록 도12 및 도1의 2가지 구조에 저장된 정보의 형태가 유사하지만, 도12의 관계 데이터베이스 구조는 도1에 도시된 플랫 파일 구조와는 다르다.

메인 프로세스(802)는 예를 들어, 도10의 나중의 단계 및/또는 나중에 수행되는 갱신에 사용하기 위해, 예를 들어, 데이터베이스(808)에 제공된 추가적인 테이블에, (단계 1022에서 로드된) 일반 정보를 세이브하고(단계 1030), (단계 1024에서 로드된) 데이터 정의를 세이브하도록(단계 1032) 구성될 수 있다.

메인 프로세스(802)는 단계(1028)에서 생성된 테이블에 대한 데이터 정의 코드(예, 필드폭, 데이터 형태 등)를 새로운 데이터베이스(808)에 로드하기 위해, 하나 또는 그 이상의 드라이버(804)의 적절한 펑션(908)을 이용한다. 일실시예에서는, 이때 롤업 정보도 로드된다. 일반적으로, 롤업 정보는 데이터의 서브-카테고리, 즉, 한 카테고리 테이블 내의 항목의 그룹을 정의하기 위해 사용되는 정보를 말한다. 예로서, 도12에 도시된 바와 같이, 피고용인 카테고리 테이블은 예를 들어, 각각의 회사 피고용인이 배치되거나 책임을 갖고 있는 위치나 사이트 또는 지역을 식별하기 위해 위치 또는 지역과 연관될 수 있다. 예를 들어, 한 회사에 한 판매 지역과 연관된 많은 판매 피고용인이 있을 수 있다. 다른 예로서, 한 회사의 다양한 제품이 제품 라인으로 롤업되거나 또는 그룹화될 수도 있다. 위치 롤업 코드에 대한 필드(1238)를 정의함으로써, 도12의 구조는 판매 지역에 의해 그룹화된 리포트를 출력하는 것을 가능하게 만든다. 롤업은 또한, 평균치, 표준 편차 등과 같은 그룹 데이터의 통계적 분석을 제공하기 위해 사용될 수 있다. 비록 도12의 실시예에서, 위치 롤업 코드에 대한 필드(1238)가 피고용인 카테고리 테이블(1216)의 필드인 것으로 도시되어 있지만, 이 위치 필드(1238)는 또한, 원하는 경우에 세부사항 테이블에 제공될 수도 있다.

롤업 코드를 로딩하기 위한 펑션(908)이 동작하는 방식은 그것과 함께 작용하도록 구성된 소스 데이터(806)의 형태에 따라 변화되게 되며, 따라서, 상이한 형태의 소스 데이터와 함께 사용하기 위해 상이한 프로그래밍 명령어가 제공될 수 있도록 다양한 드라이버(804)의 펑션으로서 제공된다. 일례로서, "롤업 코드 정의" 펑션(908)은 도4a 내지 도4f에 도시된 데이터베이스와 관련하여 사용하기 위해 구성된 드라이버(804)에 제공될 수 있다. 본 예에서, 위치 필드는 위치 코드 목적을 위해 직접 사용될 수 있는 피고용인 테이블(416)에 이미 정의되어 있다. 이와 대조적으로, 도1에 도시된 실시예에서는, 특정 플랫 파일(101a)과 관련된 피고용인(120)에 대한 위치의 표시가 없다. 그러므로, 일실시예에서는, 도1의 데이터 소스로부터 얻어지는 데이터에 대한 위치 롤업이 가능하지 않을 수도 있다. 그러나, 만일 예를 들어, 회사 내의 각각의 피고용인에 대한 자택주소를 제공하는 다른 파일이 존재한다면, 예를 들어, 개인이 책임질 수 있는 판매 지역을 추정하고, 따라서, 위치 롤업 코드를 추론적으로 정의하기 위해, 각 판매원의 거주 상태를 이용하는 것이 가능할 수 있다. 또한, "롤업 코드 정의" 펑션은 롤업 코드를 정의하기 위해 사용될 수 있는 정보에 대한 억세스를 포함할 수도 있다. 예를 들어, 도6에 도시된 데이터 소스와 관련하여, "롤업 코드 정의" 펑션(908)은 각각의 위치적인 기온 측정소에 대해, 그 측정소가 북반구 측정소인지 또는 남반구 측정소인지를 표시하는 테이블을 그 펑션 내에 포함할 수 있으며, 따라서, 그와 같은 것을 근거로하여 반구 롤업 코드를 생성할 수 있게 된다. 몇몇의 경우에는, 추가적인 롤업 및/또는 구조를 정의하기 위해 데이터베이스 내의 키 워드에 대한 워드 인식 및/또는 탐색을 제공하는 것이 바람직할 수 있다.

몇몇의 상황에서는, 롤업 코드가 (예를 들어, 도6의 데이터 소스에 대한 반구 롤업 코드와 같이) 데이터를 분석 또는 그룹화하기 위한 토대로서 데이터 소스에서 사용되지 않은 정보에 관련되게 된다. 그러므로, 이러한 상황에서는, 롤업 코드를 제공하는 것은 데이터 소스(806) 내의 정보를 출력하거나 분석하기 위해 이용할 수 없는(또는 적어도 사용되지 않은) 추가적인 요소를 자동적으로 제공함으로써 데이터의 확장을 제공하는 것을 수반한다. 데이터는 데이터 소스의 데이터의 철저한 분석에 의해 카테고리로 분류되고 그룹화되는 것이 바람직하다.

이 시스템은 정보 소스(806a-806d) 내의 데이터 또는 그 데이터의 구조에 의존하는 명확도(degree of definiteness)에 의해 결정될 수 있는 소정의 리포팅 관계를 인식하고 추가하도록 구성될 수 있다. 예를 들어, 판매 정보는 (정보 소스(806a-806d)에서 명백한, 또는 전술한 바와 같이 판매원 주소를 이용하여 추정된) 판매 지역에 의해 편성된 판매를 포함할 수 있다. 이들 지역은 또한, 본 발명의 일실시에에 따라, 그 판매 지역에 대한 부사장의 관계가 정보 소스(806a-806d)로부터 명백하게 발견되거나 또는 추정될 수 있다면, 그 각각이 2개 또는 그 이상의 판매 지역을 책임질 수 있는 둘 또는 그 이상의 부사장에 의한 것과 같이, 다른 그룹에 의해 검토되거나 분석될 수도 있다.

바람직하게는, 이와 같은 추가적인 롤업 또는 확장은 롤업 기준에 따라 데이터를 검토하는 것이 의미가 있을 수 있다는 것을 그 데이터가 나타내는 경우에만 정의된다. 예를 들어, 일실시예에서, 확장 또는 추가적인 관계는 바람직하게는, 특정 필드 또는 파라미터를 포함하는 레코드의 수 보다 적은 수의, 그 필드 또는 파라미터에 대한 하나 이상의 값이 존재하지 않는 한, 자동적으로 추가되지 않는다. 예를 들어, 만일 상이한 지역에 대한 책임이 있는 2명의 다른 부사장이 있다면, 각각의 부사장에 대응하는 판매량에 따라 판매를 조사하는 것이 의미가 있을 수도 있다. 그러나, 도6 및 도7의 예에서, 만일 모든 리포트하는 측정소가 열대 지역에 위치되어 있다면, 이 시스템은 강설량의 카테고리에 따라 기상 데이터를 검토하기 위한 롤업 또는 확장을 자동적으로 생성하지 않게 되는데, 그 이유는 본 예에서는, 모든 측정소가 강설량에 대해 제로를 보고할 것이기 때문이다. 그러므로, 사무용 데이터베이스에 있어서, 이 시스템은 바람직하게도, 예를 들어, 한명 이상의 판매원, 하나 이상의 지역 및/또는 하나 이상의 제품이 있는지 판단하기 위해 소스 데이터베이스(806a-806d) 내의 데이터를 검사하게 된다. 만일 데이터베이스의 다양한 레코드에 대한 하나의 필드에 하나 이상의 값이 존재하면, 시스템은 예를 들어, 값의 평균 또는 합계(예, 판매 평균 또는 합계, 비용 등)에 의해 그룹화되는 것과 같이, 그 필드에 따라 데이터를 검토하기 위한 옵션을 자동적으로 제공하도록 구성될 수 있다. 일실시예에서, 이것은 Microsoft Excel "pivot" 테이블을 생성함으로써 실현된다.

일례로서, 도4a 내지 도4e를 참조하면, 도4d의 테이블은 소정의 트랜잭션에 대해, 어떤 피고용인이 그 트랜잭션과 연관되어 있는지 판단하기 위해 사용될 수 있다. 도4c는 소정의 피고용인에 대해, 그 피고용인이 북서지역, 남동지역, 또는 중앙지역과 연관되어 있는지 판단하기 위해 사용될 수 있다. 만일 모든 트랜잭션이 중앙지역의 피고용인과 연관되어 있다면, 지역에 의해 트랜잭션을 디스플레이하는데 있어서의 의미는 없다. 그러나, 도4d의 테이블에서의 트랜잭션이 적어도 2개의 상이한 지역의 피고용인과 연관되어 있다면, 시스템은 그 트랜잭션과 연관된 피고용인과 관련된 위치 또는 지역에 의해 분류된 트랜잭션의 평균 또는 합계(및/또는 도4b로부터 판단되는 바와 같은 특정 계정 형태의 트랜잭션)를 디스플레이하는 롤업을 자동적으로 생성하도록 구성될 수 있다.

롤업을 정의하는 것에 더하여, 이 프로세스는 또한 선택적 참조 필드를 저장할 수 있다. 일반적으로, 선택적 참조 필드는, 리포트에 포함시키는 것이 요구될 수도 있지만, 프리-텍스트 필드(코멘트, 메모 필드, 송장 번호 등)와 같이 데이터를 그룹화하기 위해서는 통상적으로 사용되지 않는 필드를 말한다.

데이터 정의 코드 및 롤업의 로딩 이후에, 이들 데이터 정의 코드 및 롤업은 예를 들어, 다양한 카테고리 테이블(1202)로 카테고리를 기입함으로써, 새로운 데이터베이스(808)에 세이브된다(단계 1034). 단계(1033,1034)에서의 데이터 정의 및 롤업 코드의 로딩 및 세이브는 특정 카테고리(도4a 내지 도4f의 예에서, 특정 계정, 회사, 피고용인 및 위치)를 로딩하고 세이브하기 위해 루프 방식으로 수행된다(단계 1035).

다시 회고해 보면, 도시된 실시예에 따르면, 단계(1024)는 카테고리(예, 계정, 회사, 피고용인 및 위치) 뿐만 아니라 그 데이터 형태(예, 스트링 또는 수치)도 정의한다. 단계(1028)는 단계(1024)에서 정의된 카테고리 테이블(및 단계 1022에서 정의된 다른 테이블)을 생성한다. 단계(1032)는 데이터 정의를 통상적으로 한 표준 테이블에 세이브한다. 단계(1033,1034)는 데이터 정의 및 롤업 코드를 로딩하고 세이브한다.

프로세스의 이 시점에서, 비록 데이터 구조에 관련된 정보가 새로운 데이터베이스(808)에 배치되었지만, 소스 데이터(806)의 주제가 되는 데이터(예, 회계 소스 데이터의 경우에는 회계 엔트리 또는 트랜잭션, 기상 기온 소스 데이터의 경우에는 기온 데이터)는 새로운 데이터베이스(808)로 로딩되지 않았다. 따라서, 메인 프로세스(802)는 적절한 드라이버(804) 내의 펑션(909)을 호출 또는 활성화시켜, 데이터를 로딩하고(단계 1036), 데이터를 세이브하고(단계 1038), 모든 원하는 데이터가 로딩되어 세이브될 때까지(단계 1040) 프로세스를 반복한다(단계 1039). 그러므로, 이러한 절차(1036,1038,1040)의 종료점에서, 새로운 데이터베이스(808)는 하나 또는 그 이상의 데이터 소스(806)로부터의 데이터에 의해 점유된다.

상이한 구조를 가진 및/또는 상이한 브랜드 또는 형태의 소프트웨어를 이용하여 생성된 2개 또는 그 이상의 데이터 소스가 도10의 절차를 이용하여 조합될 때, 이들 상이한 형태의 소스로부터의 데이터는 예를 들어, 도12에 도시된 바와 같은 공통 데이터베이스 구조 내로 점유될 수 있다. 이것은 바람직하게는 출력의 유연성 및 속도를 제공하도록 최적화된, 데이터에 대한 공통의 또는 표준화된 분석 및 리포팅을 용이하게 한다.

도10의 실시예에서, 메인 프로세스(802)는 이제, 요약 질의(summarization queries)와 같은 데이터 질의를 구축할 수 있으며, 원한 다면 실행할 수 있다. 일반적으로, 구축될 수 있는 적어도 3가지 형태의 질의가 있다. 세부사항 테이블 내의 엔트리의 수 또는 소정의 데이터 범위에 대한 엔트리의 수를 제공하는 질의와 같이, 도10의 절차를 이용하여 생성된 모든 새로운 데이터베이스(808)에 공통적인 것이 되는 제1 형태의 질의가 제공될 수 있다. 이미 제공되었을 수도 있는 롤업을 포함하여, 적어도 부분적으로는, 하나 또는 그 이상의 데이터 소스(806)에 관해 획득된 데이터 정의 및 일반 정보에 따라 다른 질의가 구축될 수 있으며, 그에 따라, 원하는 경우에는 특정 데이터 소스에 특정된 드라이버(804)의 일부로서 제공될 수도 있다. (예를 들어, 도4e에 도시된 바와 같은) 원래의 데이터 소스에서 사용된 질의 또는 리포트를 복제하거나 또는 포함시키기 위해 제3 형태의 질의가 제공될 수 있다.

새로운 데이터베이스(808)가 점유된 이후에, 시스템은 일실시예에 따라, 그 시스템이 적절하게 동작했는지 검증하기 위해, 자동적으로 데이터의 소정의 감사 또는 검사를 수행하게 된다. 다양한 형태의 검사가 포함될 수 있다. 데이터가 변조되지 않았는지 검증하기 위해, 새로운 데이터베이스(808)의 데이터 샘플이 소스(806a-806d) 내의 대응하는 데이터와 비교될 수 있다. 또한, 필요한 구조가 존재하는지 검증하기 위해 새로운 데이터베이스(808)가 검사될 수 있다. 예를 들어, 회계 데이터베이스의 경우에, 새로운 데이터베이스(808)는 필요한 계정 부분이 존재하는지 판단하기 위해 자동적으로 검사될 수 있다. 롤업 또는 다른 정의된 확장이 비어있지 않다는 것을 확인하기 위한 것과 같이, 비어있는 셋트에 대해 새로운 데이터베이스(808)가 검사될 수 있다.

일단 새로운 데이터베이스(808)가 점유되어 검증되고 적절한 질의가 구축되면, 메인 프로세스(802)는 예를 들어, 메모리를 비워주기 위해, 테이블 및 데이터베이스를 폐쇄하고(단계 1044) 동적 드라이버를 폐쇄할 수 있다(단계 1046).

비록 본 발명이 하나 또는 그 이상의 데이터 소스 내의 데이터의 표준화된 및/또는 확장된 리포팅 및 분석을 제공하는 것과 관련된 이용에 대해 주로 고찰되었지만, 새로운 데이터베이스(808)와 관련하여 데이터베이스 관리 시스템(예, Microsoft Access, Excel, FoxPro, Btrieve, 등)을 이용한 데이터 입력 및 데이터 저장에 관해 본 발명을 이용하는 것도 가능하다. 비록 본 발명의 주된 이용이 리포팅 및 분석 목적을 위해 새로운 데이터베이스(808)에 동일한 정보의 카피를 유지하면서, 입력 및 저장을 위해 원래의 소스 데이터(806)를 계속해서 사용하는 것을 수반하게 되는 것으로 고찰되었지만, 먼저 전술한 바와 같이 새로운 데이터베이스(808)에 데이터를 저장하고, 그 다음에 새로운 데이터베이스(808)로부터의 정보를 다른 형태의 소스 데이터(806c)로 다운로드하거나 익스포트함으로써, 한 형태의 소스 데이터(806a,806b)로부터 다른 형태(예, 806c)로 데이터를 전달하기 위해 본 발명을 이용하는 것도 가능하다.

전술한 설명의 견지에서, 본 발명의 많은 장점이 이해될 수 있다. 본 발명은 사용되는 데이터의 브랜드 또는 형태의 다양성에도 불구하고, 리포팅 및 분석의 표준화를 용이하게 한다. 본 발명은 데이터를 출력 또는 리포팅하는데 있어 최적화되거나 또는 개선된 성능을 제공할 수 있는 시스템을 제공한다. 본 발명은 또한, 데이터 소스의 데이터 리포팅 및 분석에 비해 확장된 데이터 리포팅 및 분석 능력을 제공한다. 소스 데이터의 보다 복합적인 질의를 통해, 회계 시스템과 관련하여, 본 발명은 데이터 소스에 설정된 계정의 차트를 반영할 수 있다. 일실시예에서, 프로세스는 롤업, 선택적 참조 필드, 회계 기간 정보 등 정의된 정보의 일부 또는 전부를 추출한다. 태스크를 자동적으로 수행하고, 사람의 분석에 대한 필요성을 제거(또는 감소)시킴으로써, 본 발명은 이전의 방법 보다 덜 노동-집약적이고, 덜 시간-집약적이며, 몇몇의 경우에는, 이전의 방법에 의해서는 수일 또는 수주일을 필요로하게 되는 상황에서 수분 또는 수시간에 새로운 데이터베이스(808)를 점유시키는 것을 가능하게 만든다. 일실시예에서, 드라이버(804)는 데이터 소스(806)에서 사용된 보안사항, 패스워드, 허가사항 등을 새로운 데이터베이스(808)에서 검출, 분석 및 유지하도록 구성될 수 있다. 이러한 방식에 있어서, 시스템 관리자가 반드시, 원래의 데이터 소스(806)에 의해 유지되는 것에 더하여, 새로운 데이터베이스(808)에서 새로운 독립된 일련의 계정, 패스워드, 허가사항 등을 유지할 필요가 있는 것은 아니다. 바람직하게도, 이 시스템은 매일, 매주 등 실질적으로 소정의 간격으로 갱신을 수행하도록 구성될 수 있다.

본 발명의 다양한 변형 또는 변경도 역시 이용될 수 있다. 다른 관점을 이용하지 않고 본 발명의 일부의 관점만을 이용하는 것도 가능하다. 예를 들어, 새로운 또는 추가적인 롤업을 정의하지 않고 새로운 데이터베이스(808)를 점유시키는 것도 가능하다. 비록 전술한 설명에서, 다양한 드라이버(804)가 독립된 DLL 파일로서 제공될 수 있고, 단순히 적절한 디렉토리에 추가적인 DLL 파일을 저장함으로써 원하는 만큼 추가될 수 있지만, 펑션 모듈에 의해 수행되는 펑션이 독립적으로 저장된 모듈이 아니고 메인 프로세스(802)에 의해 호출되는 서브루틴 또는 그 일부로서 제공되는 본 발명의 실시가능한 버전을 만드는 것도 가능하다.

비록 본 발명이 소정의 변형 및 변경으로 양호한 실시예를 이용하여 설명되었지만, 다른 변형 및 변경도 이용될 수 있으며, 본 발명은 첨부된 청구범위에 의해 정의된다.

Claims (21)

1. 제1 및 제2의 상이한 데이터 소스 중 하나에 저장될 수 있는 데이터에 억세스하기 위한 명령어를 발생하는 제1 드라이버 - 상기 제1 드라이버는 상기 제1 데이터 소스와 관련하여 사용하기 위해 구성된 프로그램 명령어를 포함함 - 를 제공하는 단계; 및

   상기 제1 데이터 소스의 사람의 분석을 필요로 하지 않고 상기 제1 데이터 소스의 데이터 구조에 관한 정보를 자동적으로 얻기 위해 상기 제1 드라이버를 이용하는 단계

   를 포함하는 컴퓨터-구현 방법.
2. 제1 및 제2의 상이한 데이터 소스 중 하나에 저장될 수 있는 데이터에 억세스하는 것과 관련하여 이용할 수 있는 컴퓨터-구현 방법에 있어서,

   상기 제1 데이터 소스와 관련하여 사용하기 위해 구성된 프로그램 명령어를 포함하는 제1 드라이버를 제공하기 위한 제1 단계; 및

   상기 제1 데이터 소스의 사람의 분석을 필요로 하지 않고 상기 제1 데이터 소스의 데이터 구조에 관한 정보를 자동적으로 얻기 위해 상기 제1 드라이버를 이용하기 위한 제2 단계

   를 포함하는 컴퓨터-구현 방법.
3. 제 2 항에 있어서,

   제1 데이터베이스에 대한 구조를 정의하기 위해 상기 제1 정보를 이용하는 단계를 더 포함하는

   컴퓨터-구현 방법.
4. 제 2 항에 있어서,

   상기 제1 데이터 소스로부터의 적어도 일부의 정보를 제1 데이터베이스에 저장하기 위해 상기 제1 드라이버를 이용하는 단계를 더 포함하는

   컴퓨터-구현 방법.
5. 제 4 항에 있어서,

   상기 제1 데이터베이스는 상기 제1 데이터 소스에 관해 확장되어(enhanced) 있는

   컴퓨터-구현 방법.
6. 제 2 항에 있어서,

   상기 제1 드라이버는 메인 프로세스에 의해 호출가능한 프로그래밍 코드를 포함하고, 상기 방법은, 상기 메인 프로세스의 실질적인 수정이 없는 경우에, 상기 제2 데이터 소스와 관련하여 사용하기 위해 구성된 프로그램 명령어를 포함하는 제2 드라이버를 제공하고 호출함으로써 상기 제2 데이터 소스의 수용을 위해 확장가능한

   컴퓨터-구현 방법.
7. 제 2 항에 있어서,

   상기 방법은, 판독가능한 데이터 소스와 함께 사용하기 위해 구성된 드라이버를 제공함으로써 소정의 판독가능한 데이터에 억세스하는 것이 허용되도록 유연성이 있는

   컴퓨터-구현 방법.
8. 제1 및 제2의 상이한 데이터 소스 - 상기 제1 및 제2 데이터 소스 중 적어도 하나는 적어도 제1 출력을 생성하도록 구성됨 - 중 하나에 저장될 수 있는 데이터에 억세스하는 것과 관련하여 이용할 수 있는 컴퓨터-구현 방법에 있어서,

   상기 제1 데이터 소스와 관련하여 사용하기 위해 구성된 프로그램 명령어를 포함하는 제1 드라이버를 제공하는 단계;

   상기 제2 데이터 소스와 관련하여 사용하기 위해 구성된 프로그래밍 코드를 포함하는, 상기 제1 드라이버와 다른, 제2 드라이버를 제공하는 단계;

   상기 제1 및 제2 데이터 소스의 데이터 구조에 관한 제1 및 제2 정보를 얻기 위해 각각 상기 제1 및 제2 드라이버를 이용하는 단계;

   제1 데이터베이스에 대한 구조를 정의하기 위해 상기 제1 및 제2 정보를 이용하는 단계; 및

   상기 제1 및 제2 데이터 소스로부터의 적어도 일부의 정보를 상기 제1 데이터베이스로 저장하기 위해 상기 제1 및 제2 드라이버를 이용하는 단계

   를 포함하는 컴퓨터-구현 방법.
9. 제 8 항에 있어서,

   상기 제1 데이터베이스 내의 정보에 근거하여 적어도 제1 리포트를 생성하는 단계를 더 포함하는

   컴퓨터-구현 방법.
10. 제 9 항에 있어서,

    상기 제1 리포트는 상기 제1 출력에 관해 확장되어 있는

    컴퓨터-구현 방법.
11. 제 8 항에 있어서,

    각각의 드라이버는 다수의 펑션을 수행하기 위한 프로그램 명령어를 포함하고 있는

    컴퓨터-구현 방법.
12. 제 11 항에 있어서,

    상기 다수의 펑션은, 다음의 펑션, 즉,

    상기 데이터 소스가 위치된 디렉토리를 선택하는 펑션;

    데이터 파일에 대한 디렉토리를 탐색하는 펑션;

    입력 또는 갱신될 데이터를 디스플레이하는 펑션;

    상기 데이터 소스로부터 일반 정보를 로딩하는 펑션;

    상기 데이터 소스로부터 데이터 정의를 로딩하는 펑션;

    상기 데이터 소스로부터의 적어도 일부의 정보를 저장하기 위해 구성된 데이터베이스 테이블을 생성하는 펑션;

    상기 데이터베이스로 부터 획득한 일반 정보를 세이브하는 펑션;

    상기 데이터 소스로부터 데이터 정의를 세이브하는 펑션;

    데이터 정의 코드를 상기 제1 데이터베이스로 로딩하는 펑션;

    롤업 정보를 상기 제1 데이터베이스로 로딩하는 펑션; 및

    상기 데이터 소스로부터의 데이터를 상기 제1 데이터베이스로 로딩하는 펑션;

    중에서 선택된 적어도 하나의 펑션을 포함하는

    컴퓨터-구현 방법.
13. 제 8 항에 있어서,

    상기 제1 데이터베이스는 데이터 출력의 속도에 대해 최적화되어 있는

    컴퓨터-구현 방법.
14. 제 8 항에 있어서,

    상기 제1 데이터베이스는 데이터 출력의 유연성에 대해 최적화되어 있는

    컴퓨터-구현 방법.
15. 제 8 항에 있어서,

    상기 제1 데이터베이스는 다수의 카테고리 테이블, 적어도 하나의 세부사항 테이블 및 적어도 하나의 엔트리 테이블을 포함하는

    컴퓨터-구현 방법.
16. 제1 및 제2의 상이한 데이터 소스 - 상기 제1 및 제2 데이터 소스 중 적어도 하나는 적어도 제1 출력을 생성하도록 구성됨 - 중 하나에 저장될 수 있는 데이터에 억세스하는 것과 관련하여 이용할 수 있는 장치에 있어서,

    상기 제1 및 제2 데이터 소스에 결합되어,

    상기 제1 데이터 소스와 관련하여 사용하기 위해 구성된 프로그램 명령어를 포함하는 제1 드라이버를 제공하고;

    상기 제2 데이터 소스와 관련하여 사용하기 위해 구성된 프로그래밍 코드를 포함하는, 상기 제1 드라이버와 다른, 제2 드라이버를 제공하고;

    상기 제1 및 제2 데이터 소스의 데이터 구조에 관한 제1 및 제2 정보를 얻기 위해 각각 상기 제1 및 제2 드라이버를 이용하고;

    제1 데이터베이스에 대한 구조를 정의하기 위해 상기 제1 및 제2 정보를 이용하고;

    상기 제1 및 제2 데이터 소스로부터의 적어도 일부의 정보를 상기 제1 데이터베이스로 저장하기 위해 상기 제1 및 제2 드라이버를 이용하기 위해

    프로그램된 컴퓨터

    를 포함하는 장치.
17. 제1 및 제2의 상이한 데이터 소스 중 하나에 저장될 수 있는 데이터에 억세스하는 것과 관련하여 이용할 수 있는 장치에 있어서,

    상기 제1 데이터 소스와 관련하여 사용하기 위해 구성된 프로그램 명령어를 포함하는 제1 드라이버 수단;

    상기 제2 데이터 소스와 관련하여 사용하기 위해 구성된 프로그래밍 코드를 포함하는, 상기 제1 드라이버 수단과 다른, 제2 드라이버 수단;

    상기 제1 및 제2 데이터 소스의 데이터 구조에 관한 제1 및 제2 정보를 얻기 위해 각각 상기 제1 및 제2 드라이버 수단을 이용하기 위한 수단;

    제1 데이터베이스에 대한 구조를 정의하기 위해 상기 제1 및 제2 정보를 이용하기 위한 수단; 및

    상기 제1 및 제2 데이터 소스로부터의 적어도 일부의 정보를 상기 제1 데이터베이스로 저장하기 위해 상기 제1 및 제2 드라이버 수단을 이용하기 위한 수단

    을 포함하는 장치.
18. 제1 및 제2의 상이한 데이터 소스 - 상기 제1 및 제2 데이터 소스 중 적어도 하나는 적어도 제1 출력을 생성하도록 구성됨 - 중 하나에 저장될 수 있는 데이터에 억세스하는 것과 관련하여 이용할 수 있는 컴퓨터 프로그램을 그 내부에 저장하고 있는 컴퓨터-판독가능 매체에 있어서,

    상기 컴퓨터 프로그램은,

    상기 제1 데이터 소스와 관련하여 사용하기 위해 구성된 프로그램 명령어를 포함하는 제1 드라이버를 제공하기 위한 명령어;

    상기 제2 데이터 소스와 관련하여 사용하기 위해 구성된 프로그래밍 코드를 포함하는, 상기 제1 드라이버와 다른, 제2 드라이버를 제공하기 위한 명령어;

    상기 제1 및 제2 데이터 소스의 데이터 구조에 관한 제1 및 제2 정보를 얻기 위해 각각 상기 제1 및 제2 드라이버를 이용하기 위한 명령어;

    제1 데이터베이스에 대한 구조를 정의하기 위해 상기 제1 및 제2 정보를 이용하기 위한 명령어; 및

    상기 제1 및 제2 데이터 소스로부터의 적어도 일부의 정보를 상기 제1 데이터베이스로 저장하기 위해 상기 제1 및 제2 드라이버를 이용하기 위한 명령어

    를 포함하는 컴퓨터-판독가능 매체.
19. 제1 데이터 소스에 저장된 데이터에 억세스하기 위한 명령어를 발생하는 제1 드라이버를 제공하는 단계;

    상기 제1 데이터 소스의 데이터 구조에 관한 제1 정보를 얻기 위해 상기 제1 드라이버를 이용하는 단계;

    제1 데이터베이스에 대한 구조를 정의하기 위해 상기 제1 정보를 이용하는 단계;

    상기 제1 데이터 소스로부터의 적어도 일부의 정보를 상기 제1 데이터베이스로 저장하기 위해 상기 제1 드라이버를 이용하는 단계;

    상기 제1 데이터베이스를 갱신하는데 있어 사용될 상기 제1 데이터 소스에 저장된 상기 데이터의 적어도 일부를 정의하는 제2 정보를 저장하는 단계; 및

    상기 제2 정보를 이용하여, 상기 제1 데이터베이스를 갱신하는 단계

    를 포함하는 컴퓨터-구현 방법.
20. 제 8 항에 있어서,

    상기 제1 및 제2 데이터 소스 중 적어도 하나는 데이터 값을 저장하기 위한 다수의 필드를 각각 갖고 있는 다수의 레코드를 포함하고,

    적어도 제1 및 제2의 상이한 데이터 값이 적어도 2개의 레코드의 하나의 필드에 저장되는 적어도 하나의 상기 필드를 식별하는 단계; 및

    상기 제1 및 제2의 상이한 데이터 값에 대응하는 제1 및 제2 데이터 그룹을 디스플레이하는 단계

    를 더 포함하는 컴퓨터-구현 방법.
21. 제 8 항에 있어서,

    에러를 식별하기 위해 상기 제1 데이터베이스에 저장된 정보를 분석하는 단계

    를 더 포함하는 컴퓨터-구현 방법.