KR20010090596A

KR20010090596A - 점검 유틸리티용 예외 테이블을 유지하는 방법

Info

Publication number: KR20010090596A
Application number: KR1020017005205A
Authority: KR
Inventors: 이싶아만도비주니어
Original assignee: 엘그레시 도론; 컴퓨터 어소시에이츠 싱크, 인코포레이티드
Priority date: 1998-10-27
Filing date: 1999-10-27
Publication date: 2001-10-18
Also published as: WO2000025236A1; ATE546786T1; CN1211744C; CN1324465A; EP1145156A4; US20010016844A1; EP1145156A1; JP2002528822A; US6401089B2; IL142570A0; CA2347785A1; BR9914750A; EP1145156B1; AU1236000A; HK1042563A1; IL142570A

Abstract

점검 유틸리티용 예외 테이블을 유지하는 방법은 미리 정해진 예외 테이블 변수에 대한 키워드 및 관련 값을 포함하는 제어 문장을 발생하는 것을 포함한다. 상기 제어 문장은 예외 테이블을 생성하고 드롭하는데 필요한 SQL 문장을 자동으로 빌딩하고 실행하는 상기 점검 유틸리티에 의해 파싱된다.

Description

점검 유틸리티용 예외 테이블을 유지하는 방법{METHOD FOR MAINTAINING EXCEPTION TABLES FOR A CHECK UTILITY}

널리 공지된 데이터베이스 소프트웨어 프로그램은 IBM사에 의해 분배된 DATABASE 2(DB2) 데이터베이스 소프트웨어이다. 종래에 널리 공지된 바와 같이, DB2는 IBM MVS 운용 시스템 소프트웨어로 동작하는 컴퓨터 시스템의 보조 시스템으로 동작한다. DB2 환경에서, 사용자 데이터는 테이블 공간안의 DB2 테이블에 잔류한다. 예컨대, 테이블 공간은 디스크 드라이브 등의 직접 엑세스 기억 장치(DASD)에 있는 기억 공간의 일부분이다. 예시용으로 아래에 도시된 것은 테이블 공간에 기억될 수 있는 주문_ 입력 테이블이다. 상기 주문_입력 테이블은 열, 즉 고객_번호, 제품_코드, 주문_번호, 구매자_이름, 및 선박_대_우편번호를 포함한다.

주문_입력 테이블

고객_번호	제품_코드	주문_번호	구매자_이름	선박_대_우편번호
1111111111	0010	1234500001	John Doe	60606
1111111111	0040	1234500002	Jane Doe	70707
3333333333	0020	1234500003	Bill Smith	90909
2222222222	0030	1234500004	Fred Smith	80808

상기 주문_입력 테이블이 4개의 행을 도시하는 반면, 그 테이블은 회사의 모든 주문에 대하여 수백만 개의 행, 예컨대 4백만 개의 행을 가질 수 있다. 예컨대, 상기 주문_입력 테이블은 3개의 인덱스 키 및 2개의 외래 키를 갖고 있다. 인덱스 키는 테이블의 특정 행에 대한 식별자이고, 외래 키는 행을 식별하지만 아래에 기술된 바와 같은 참조 보존성에 이용된다. 예컨대, 상기 주문_입력 테이블에서, 한 개의 인덱스 키는 주문_번호에 기초하고, 다른 인덱스 키는 구매자_이름에 기초하며, 제3의 인덱스 키는 선박_대_우편번호에 기초한다. 종래에 공지된 바와 같이, 특정 테이블용 인덱스 키는 행 식별(RID) 및 상기 행에 대하여 선택된 값(예컨대, 인덱스 키 값)을 지시한다.

상기 인덱스 키는 상기 테이블에서 특정 데이터에 대한 차후의 검색을 용이하게 하는 테이블용 인덱스를 발생하는데 이용될 수 있다. 예컨대, 상기 주문_입력 테이블은 3개의 인덱스(예컨대, 각 인덱스 키에 대하여 한 개)를 가질 수 있는데, 각 인덱스는 인덱스 공간에 기억 된다. 테이블 공간과 비슷하게, 예컨대, 인덱스 공간은 DASD의 지정된 부분이다. 따라서, 사용자가 상기 주문_입력 테이블의 특정 구매자 이름을 포함하는 행을 찾지 못하는 경우, 상기 데이터베이스 관리 시스템은 상기 행에 위치하는 전체의 테이블을 판독하지 않고 모든 구매자 이름을 식별하기 위하여 상기 테이블의 구매자 인덱스에 문의해야 한다.

DB2는 한 번의 시도로 데이터베이스 테이블을 엑세스하는 어플리케이션 프로그램에 대한 성능 특성을 분석하여 상기 데이터베이스 테이블로 고속 엑세스하는 최적의 인덱스 구조를 찾는다. 한 개의 인덱스로 이용되는 값은 각 인덱스가 상기데이터베이스 시스템에 부담을 주기 때문에 주의 깊게 선택되어야 한다. 예컨대, 부가 또는 삭제 등의 데이터베이스 테이블에서 각 트랜잭션은 상기 테이블에 대한 각 인덱스를 갱신할 필요성이 있다. 따라서, 한 테이블에 대하여 인덱스의 갯수를 최소화하여 어플리케이션 프로그램의 성능을 향상시키는 것이 바람직하다. 데이터베이스 테이블에 대한 인덱스로 사용되는 값은 상기 테이블의 사용자, 일반적으로 온라인 트랜잭션 사용자에 의해 가장 종종 엑세스된 데이터를 토대로 선택된다. 일반적으로, 인덱스 키는 인증 목적으로 이용되는 외래 키에 근거를 두고 있지 않다(예컨대, 강제 실행).

종래 기술에 공지된 바와 같이, 데이터베이스의 각 테이블은 모 테이블 (parent table), 자 테이블(child table) 또는 이 모든 테이블이 될 수 있다. 자 테이블은 상기 외부 키 값 또는 상기 자 테이블의 열에 포함된 값을 통하여 모 테이블과 관련된다. 예컨대, 외래 키 값은 자 테이블에 여러번 나타날 수 있지만(예컨대, 자 테이블의 복수의 행은 주문_입력 테이블의 고객_번호 및 제품_코드 입력 등의 동일한 외래 키를 가질 수 있다), 각 외래 키는 상기 자 테이블의 모 테이블의 유일한 키와 관련된다.

참조 보존성(Referential integrity)은 모든 외래 키 값이 유효한 것이 확실하다(예컨대, 모 테이블에 해당하는 1차 키). 따라서, 참조 보존성(RI)이 의미하는 것은 상기 테이블 안에 행의 열 값은 다른 테이블의 인덱스에 이러한 값이 있을 때 유효하다. 행이 제약 조건(constraint)을 위반하는 경우, 테이블에 행은 없어야 한다. 상기 도시된 주문_입력 테이블이 2개의 외래 키를 가지면, 그 주문_입력은 고객_번호 및 제품_코드 상에 RI 제약 조건을 갖는다. 종래 기술에 공지된 바와 같이, DB2 데이터베이스 관리 시스템의 사용자가 테이블을 생성할 때, 사용자는 상기 테이블에 대한 제약 조건을 정의한다(예컨대, 사용자는 합리적인 참조 범위를 정의할 수 있다). 아래에 도시된 것은 예시용 제품 테이블 및 예시용 고객 테이블(예컨대, 상기 주문_입력 테이블에서 외래 키에 대한 모 테이블)이다.

제품 테이블

제품_코드	제품_설명	소매_가격
00010	랩톱 PC	1000.00
00020	데스크톱 PC	1100.00
00030	사무용 PC	1200.00
00040	랜 PC	3500.00
00050	가정용 PC	999.99

상기 테이블이 회사의 모든 다른 제품에 대하여 수천 개의 행을 가지고 있더라도, 상기 제품 테이블은 5개의 행을 도시한다. 예컨대, 상기 제품 테이블은 주문이 급증할 때의 값을 도시하는 컬럼 제품_코드에 기초한 인덱스를 갖는다. 상기 컬럼 제품_코드의 값은 각 제품에 대하여 단지 한 개의 제품 코드를 할당하고, 이러한 테이블에서, 제품 코드를 한 개 이상 포함하지 않기 때문에 각각 유일한 것이다. 따라서, 상기 제품 테이블에 대한 인덱스는 키 값(예컨대, 상기 제품_코드 컬럼에 스토리지된 값) 및 RID를 포함한다. 상기 제품 테이블 인덱스는 DB2 인덱스 공간에 잔류할 것이다.

이러한 테이블이 회사의 모든 고객에 대하여 수천 개의 행을 가지고 있더라도, 아래에 도시된 고객 테이블은 4개의 행을 도시한다. 예컨대, 상기 고객 테이블은 주문이 급증하는 값을 나타내는 컬럼 고객_번호를 토대로 인덱스를 갖는다. 상기 컬럼 고객_번호의 값은 각 고객의 이름에 단지 한 개의 고객 번호를 할당하고, 이러한 테이블에 한 개 이상의 고객 번호가 포함되지 않기 때문에 각각 유일한 것이다. 따라서, 상기 고객 테이블에 대한 인덱스는 키 값(예컨대, 상기 컬럼 고객_번호) 및 RID를 포함할 것이다. 또한, 상기 고객 인덱스는 DB2 인덱스 공간에 잔류할 것이다.

고객 테이블

고객_번호	구매자_이름	고객_주소
1111111111	John Doe	A주
2222222222	Fred Smith	B주
3333333333	Bill Smith	C주
4444444444	Steve Jones	D주

상기 테이블에 도시된 바와 같이, 상기 주문_입력 테이블의 모든 행은 유효한 데(참조 보존성 제약 조건 위반이 없다), 그 이유는 상기 주문_입력 테이블의 컬럼 제품_코드의 외래 키 값이 상기 제품 테이블에 존재하고, 상기 주문_입력 테이블의 컬럼 고객_번호의 값이 고객 테이블에 존재하기 때문이다.

DB2 등의 종래의 데이터베이스 관리 시스템은 테이블에 행을 부가하기 전에 행을 충족시키는 특정 조건을 식별하는 능력을 사용자에게 제공한다. 이러한 조건은 행이 포함하는 값을 제한하기 때문에 "제약 조건"으로서 언급된다. 예컨대, 제약 조건은 제약 조건 및 참조 보존성 제약 조건을 점검한다. 예컨대, 제약 조건을 점검하는 것은 00000 내지 99999 범위 내에 있는 우편 번호 값(예컨데, 상기 주문_입력 테이블의 선박_대_우편 번호 값) 등의 특정 값에 대한 범위에 대한 적합한 범위를 포함한다. 상기 토론된 바와 같이, 참조 보존성 제약 조건은 다른 테이블의 인덱스에 상기 값이 존재할 때 테이블의 행의 값이 유효한 것을 확인한다.

제약 조건 실행은 데이터베이스 테이블에 데이터를 로딩하기 전에 또는 데이터베이스 테이블에 이미 데이터를 로딩한 후에 실행될 수 있다. 제약 조건 실행이 데이터베이스 테이블에 데이터를 로딩한 후에, 예컨대, 소프트웨어 불량의 하드웨어에 따른 회복 동작으로 실행될 때, 상기 제약 조건 실행은 일반적으로 IBM사의 점검 데이터, 플레티넘 테크놀로지사의 BMC 소프트웨어 및 FASTCHECK에 의한 CHECK PLUS 등의 CHECK 유틸리티에 의해 실행된다.

종래의 CHECK 유틸리티는 상기 테이블에 설정되는 제약 조건을 상기 테이블의 데이터가 위반하지 않는 것이 확실하다. 제약 조건은 상기 테이블이 발생될 때 설정될 수 있다. 예컨대, 상기 테이블이 상기 데이터베이스 시스템에서 최초에 생성되고 DB2 카탈로그에 기억될 때 형성되어, 상기 제약 조건 정보를 식별하기 위하여 CHECK 유틸리티에 의해 차후에 문의될 수 있다.

제약 조건 실행을 수행하기 위하여, 예컨대, 종래의 CHECK 유틸리티는 종래 기술에 공지된 바와 같이 상기 DB2 카탈로그를 판독함으로써 점검될 테이블에 대하여 적용 가능한 제한 조건을 초기화하여 식별할 것이다. 예컨대, 상기 CHECK 유틸리티는 상기 데이터베이스 테이블의 각 행을 판독한 다음, 제약 조건 위반 및/또는 참조 보존성 제약 조건 위반을 점검할 것이다.

종래 기술에 공지된 바와 같이, CHECK 유틸리티가 테이블 상에 동작하는 매시간 전에 예외 테이블이 발생된다(새로운 예외 테이블은 발생되거나 시간 제약 조건 적용이 실행되는 시간마다 이전의 예외 테이블은 대체된다). 예컨대, 사용자가 작업 스트림을 발생하여 CHECK 유틸리티를 실행할 때, 그 작업 스트림의 단계는 새로운 예외 테이블을 생성하는 단계를 포함한다. 에컨대, 상기 예외 테이블은 상기 예외 테이블만이 제약 조건 위반으로 이루어진 행을 포함하는 것 이외에 데이터베이스 테이블의 미러 이미지(mirror image)이다. 예컨대, CHECK 유틸리티가 제약 조건 위반을 식별할 때마다, 상기 CHECK 유틸리티는 그 전체의 행을 상기 예외 테이블에 복사한다. 예외 테이블에 에러 행을 복사하기 위한 예외적인 SQL 문장은 다음과 같다.

INSERT INTO PDLNR.EXRDOCDPP4

VALUES ('SALE'

,'2004-10-04'

,'07.55.34'

,0

,33329

,'V'

,-.05

,X'0000201'

,CURRENT TIMESTAMP)_;

상기 코드에 의해 도시된 바와 같이, 데이터베이스 테이블 PDLNR.TDOCDPP에 제약 조건 위반을 포함하는 행은 예외 테이블 PDLNR.EXTDOCDPP4에 복사될 것이다.

그러나, 예외 테이블을 이용하는 CHECK 유틸리티 전에, 상기 예외 테이블은생성되어야 한다. 또한, 상기 CHECK 유틸리티가 테이블상에서 이전에 동작했다면, 그 이전에 생성된 예외 테이블은 삭제되고 새로운 예외 테이블은 생성된다. 종래의 CHECK 유틸리티의 실행 예는 예외 테이블의 생성 및 삭제에 관하여 다음과 같다. 예컨대, 3개의 모 테이블 및 31개의 종속 테이블을 갖는 통상적인 사용자 어플리케이션을 가정해보자(모 테이블 및 종속 테이블의 다른 결합은 가능하다). 고객이 상기 종속 테이블에 대한 종래의 CHECK 유틸리티를 실행할 때, 예외 테이블은 각 종속 테이블에 필요하다. 상기 기술되고 종래의 기술에 공지된 바와 같이, 예컨대, 각 예외 테이블은 상기 CHECK 유틸리티가 제약 조건을 위반함으로써 식별하는 행을 포함하는 데 이용된다. 참조 보존성 제약 조건 위반에 대한 종속 테이블 테이블 공간을 점검할 때, 종래의 CHECK 유틸리티의 사용자는 다음과 같은 단계를 실행할 필요성이 있다.

DROP TABLESPACE DBISIP.TSISIPO1;

CREATE TABLESPACE TSISIP01

IN DBISIP

USING STOGROUP SGISIP

PRIQTY 52

SECQTY 26

ERASE NO

FREEPAGE 0

PCTFREEE 5

BUFFERPOOL BP0

LOCKSIZE ANY

CLOSE YES

LOCKMAX SYSTEM

CCSID EBCDIC

CREATE TABLE PDISIP.TBHORDCT

LIKE PDUTL03.TBHORDCT

IN DBISIP.TSISP01;

ALTER TABLE PDISIP.TSISIP01

ADD RID CHAR(4);

ALTER TABLE PDISIP.TBHORDCT

ADD TIME TIMESTAMP NOT NULL WITH DEFAULT

예컨대, 상기 코드는 현존하는 예외 테이블(예컨대, TSISIPO1)을 드롭(drop)하여 점검되는 각 종속 테이블에 대한 새로운 예외 테이블(예컨대, TSISIPO1)을 생성하는 단계를 설정한다. 그 이외에, 상기 코드는 상기 새롭데 생성된 예외 테이블에 대하여 CHECK 유틸리티가 필요한 변경예를 도시한다(예컨대, 행 식별용 신규 열 및 타임 스템프용 신규 열).

상기 예가 31개의 종속 테이블 공간을 갖기 때문에, 상기 코드는 31번 기록하고 실행해야 한다(예컨대, 각각의 종속 테이블 공간에 대하여 한번). 그 이외에, 상기 CHECK 유틸리티의 사용자는 상기 CHECK 유틸리티를 실행할 제어 문장, 즉, 점검될 모든 종속 테이블 공간의 이름을 정하고 그 종속 테이블과 관련된 모든 예외 테이블을 식별하는 제어 문장을 코딩한다. 이러한 목적으로 사용자에 의해 기록될 전형적인 SQL 문장은 아래와 같이 도시된다.

상기 제어 문장에 의해 도시된 바와 같이, 각 종속 테이블 공간은 식별된다(예컨대, "TABLESPACE JTINLAND.SCHORDCT"는 데이터베이스 JTINLAND가 소유한 종속 테이블 SCHORDCT를 식별한다). 상기 31개의 종속 테이블이 식별된 후에, 각 종속 테이블에 이용되는 예외 테이블은 식별된다(예컨대, "FOR EXCEPTION IN PDUTL03. TBHORDCT USE PDISIP.TBHORDCT"는 종속 테이블 TBHORDCT에 사용되는 예외 테이블 TBHORDCT를 식별한다).

제약 조건 적용을 실행하기 위한 종래의 CHECK 유틸리티의 동작을 위하여 기록 및 실행되어야 하는 상기 전형적인 코드에 의해 지시된 바와 같이, 실질적인 노력은 상기 CHECK 유틸리티의 이전 동작으로 생성된 예외 테이블 테이블 공간의 존재를 드롭하는 동시에 새로운 예외 테이블 테이블 공간을 생성하기 위하여 사용자에 의해 확장되어야 한다.

데이터베이스가 종종 많은 종속 테이블을 갖기 때문에, 사용자는 이러한 테이블 및 모든 종속 테이블상에 참조 보존성 점검을 주기적으로 실행해야 한다. 이러한 프로세스는 많은 단계 및 실제적인 양의 핸드 코딩 SQL 명령을 포함하여 점검으로 테이블을 식별하고, 예외 테이블을 생성하는 동시에 그 예외 테이블을 참조 기준성 CHECK 유틸리티로 특정하는데 오래 걸린다. 이러한 프로세스는 시간을 소비할 뿐만 아니라 에러를 일으키기 쉽다. 따라서, 자동화 방법으로 점검하는 종속 테이블 참조 보존성과 관련된 임무를 간단하게 하는 것이 바람직하다.

본 발명은 데이터베이스 관리 시스템에 관한 것으로써, 특히 데이터 베이스 관리 시스템에서 점검 유틸리티용 예외 테이블을 유지하는 방법에 관한 것이다.

도 1은 로드 본 발명의 일 실시예에 따라 CHECK 유틸리티에 대하여 예외 테이블을 유지하는 예시적인 흐름도.

도 2는 본 발명의 일 실시예에 따라 CHECK 유틸리티에 대하여 예외 테이블을 유지하는 다른 예의 흐름도.

본 발명에 따르면, 한 프로세스는 CHECK 유틸리티에 의해 점검되는 테이블공간을 식별하여 그 테이블 공간 및 관련된 예외 테이블 테이블 공간이 자동으로 상기 CHECK 유틸리티로 식별됨으로써, 종래의 CHECK 유틸리티 동작에 필요한 SQL 문장의 실제적인 핸드 코딩에 대한 필요성을 없앤 것이다. 본 발명의 전형적인 실시예에 따르면, 소정의 키워드를 포함하는 제어 문장은 CHECK 유틸리티에 제공되는데, 상기 CHECK 유틸리티는 상기 제어 문장을 파싱하여 현존하는 예외 테이블 테이블 공간을 드롭하는 동시에 새로운 예외 테이블 테이블 공간을 생성한다.

도 1은 본 발명의 일 실시예에 따라 CHECK 유틸리티에 대하여 예외 테이블을 유지하는 흐름도의 예를 도시한다. 도 1에 도시된 바와 같이, 단계(1010)에서, 제어 문장은 상기 바림직한 테이블 공간상에 제약 조건 적용을 실행하는 데 필요한 변수를 식별하는 것이 판독된다. 단계(1020)에서, 상기 제어 문장은 본 발명의 실시예에 따라 수정된 종래의 CHECK 유틸리티에 의해 처리된다. 단계(1030)에서, 예외 테이블을 드롭하거나 생성하는 데 필요한 SQL 문장이 발생된다. 단계(1040)에서, 상기 단계(1030)에서 발생된 SQL 문장은 실행된다.

아래에 설정된 것은 본 발명의 실시예에 따른 예의 SQL 제어 문장이다. 예컨대, 이러한 제어 문장은 도 1에 도시된 단계(1010)에서 CHECK 유틸리티의 사용자에 의해 발생된다. 상기 제어 문장은 본 발명의 실시예에 따라 처리하는 종래의 CHECK

유틸리티에 제공될 것이다.

상기 예의 SQL 제어 문장에 지시된 바와 같이, 상기 제어 문장은 상기 용어 "USING"에 의해 본 발명의 실시예에 따라 종래의 CHECK 유틸리티에 의해 처리되는 몇 개의 키워드를 포함한다. 상기 제어 문장의 포멧이 상기 점검 유틸리티에 의해 처리(예컨대, 파스)될 수 있는 경우, 상기 제어 문장의 포멧은 설계 선택의 문제이다. 그러나, 상기 키워드 이전에, 점검될 종속 테이블 공간의 이름은 사용자에 의해 제공되어, 점검될 종속 테이블이 결정될 수 있다. 예컨대, 상기 CHECK 유틸리티는 종래 기술에 공지된 바와 같이 데이터베이스의 DB2 카탈로그를 판독하는 것에 의해 각 종속 데이터베이스에서 종속 테이블의 이름을 식별할 수 있다. 상기 DB2 카탈로그를 판독하는 방법에 대한 설명은 발명의 명칭이 "제약 조건을 실행하는 최적의 프로세스의 동적 결정"으로 동시 계류중인 출원 번호 제09/151,750호에 포함되어 있으며, 이것은 본 출원의 양수인에게 양도인에게 양도되었고, 본원에 참조용으로 포함된다.

본 발명의 다른 실시예에 있어서, 점검되는 모든 종속 테이블 공간의 이름을 제공하는 대신에, 상기 모 테이블 공간의 이름은 상기 제어 문장에 제공될 수 있다. 이러한 정보에 의하여, 상기 DB2 카탈로그는 그 관련된 종속 테이블 공간을 식별하기 위해 판독되어, 사용자가 상기 종속 테이블 공간을 손으로 식별할 필요성을 없앤다. 예컨대, 상기 모 테이블 공간을 식별하는 제어 문장은 DB2 카탈로그를 액세스할 수 있는 CHECK 유틸리티 또는 다른 DB2 유틸리티와 같이, 상기 포멧 또는 구문이 적합한 입력에 의해 해석되고 처리될 수 있는 경우에 특정된 포멧 또는 구문을 가질 수 있다.

본 발명의 실시예에 따른 예의 SQL 제어 문장은 소정의 예외 테이블 변수에 대한 키워드를 포함한다. 예컨대, 한 개의 키워드는 상기 테이블 공간이 생성될 데이터베이스의 이름이다(예컨대, 새롭게 생성된 테이블 공간의 국부적인 그룹화에 대한 데이터베이스 이름). 이러한 예에 있어서, 상기 데이터베이스의 이름은 DBISIP이다. 다른 키워드는 생성될 예외 테이블 공간 이름, 예컨대 TSISIP(데이터베이스 DBISIP에 있는)이다. 복수의 예외 테이블 공간이 필요하면, 본 발명에 따른방법은 그들, 예컨대, 동일한 테이블 공간 이름(예컨대, TSISIP01,TSISIP02 등)을 이용하는 확실하게 번호를 매긴 테이블 공간을 생성할 것이다. 또한, 상기 키워드는 종래 기술에 공지된 바와 같이 기억 장치 그룹 식별자를 포함한다(예컨대, 상기 예외 테이블이 잔류할). 이러한 예에서, 상기 STOGROUP은 SGISIP로 명명된다.

본 발명의 실시예에 따른 키워드는 상기 기억 장치 그룹내에 이용되는 1차 DASD의 양 및 2차 DASD의 양을 포함한다(예컨대, 상기 예외 테이블 공간에 대하여 DB2에 의해 할당되는 DASD의 페이지). 상기 1차 및 2차 DASD의 양은 종래 기술에 공지된 바와 같이, 예컨대, 상기 CHECK 유틸리티에 의해 식별될 에러의 갯수에 대한 평가를 토대로 사용자에 의해 특정될 수 있다. 이러한 예로서, DASD의 52 페이지는 필요한 경우에 이용할 수 있는 다른 26 페이지로 상기 기억 장치 그룹이 할당된다.

상기 제어 문장에 도시된 바와 같이, 상기 키워드는 이러한 케이스 PDISIP에서 생성되는 예외 테이블의 소유자를 식별할 수 있다. 예컨대, 이러한 소유자는 본 발명의 실시예에 따른 제어 문장에 응답하여 상기 CHECK 유틸리티에 의해 발생된 CREATE TABLE SQL 문장에 이용될 수 있다. 그 이외에, 상기 키워드는 드롭 문장을 포함하여 현존하는 예외 테이블이 새로운 예외 테이블을 생성하기 전에 드롭되는지 여부 또는 현존하는 예외 테이블이 재사용되는 경우를 지시한다. 본 발명의 실시예에 따르면, 새롭게 생성된 예외 테이블은 점검되는 대응하는 종속 테이블과 동일한 이름을 갖으며, 사용자에 의해 제공된 소유자에게 양도된다(예컨대, 다른 소유자 이름을 갖는).

본 발명의 실시예에 따른 예외 테이블을 발생하고 드롭하는 종래의 CHECK 유틸리티에 대한 예시적인 프로세스는 아래에 의사 코드로 설정되고 도 2에 도시된다

도 2는 본 발명의 실시예에 따른 CHECK 유틸리티에 대하여 예외 테이블을 유지하는 다른 예시적인 흐름도를 도시한다. 단계(2010)에서, 제어 문장은 종래의 CHECK 유틸리티에 의해 수신된다. 예컨대, 본 발명의 예시적인 실시예에 따르면, 제어 문장은 전술한 바와 같이 상기 CHECK 유틸리티에 의해 파스하는 소정의 예외 테이블 변수를 포함한다. 단계(2020)에서, 상기 수신된 제어 문장은 파스되고, 예 또는 아니오로 DROP 변수가 설정되는 경우에 결정된다. 그 값이 아니오 인경우, 이전의 점검 동작으로부터 현존하는 예외 테이블 공간은 상기 현재의 점검 동작에 이용될 것이다. 상기 드롭 값이 예인 경우, 단계(2030)에서, 그 현존하는 예외 테이블 공간은 드롭될 것이다.

단계(2030)에 따르면, CREATE TABLESPACE SQL 문장은 상기 파스된 제어 문장으로부터 얻어진 테이블 공간(예컨대, 데이터 구조가 건설된)을 이용하는 CHECK 유틸리티에 의해 단계(2040)에서 설치된다. 단계(2050)에서, 상기 예외 테이블 공간은 예컨대 상기 CREATE TABLESPACE SQL 문장을 실행함으로서 발생된다(예컨대,DASA의 일부분은 상기 예외 테이블 공간에 할당된다.). 단계(2060)에서, 상기 예외 테이블 공간이 이전에 존재하는 경우가 결정된다. 예컨대, DB2는 새로운 예외 테이블 공간이 생성되는 경우(예컨대, 상기 SQL 문장이 성공한 경우) 또는 상기 테이블 공간이 이미 존재하기 때문에 생성되지 않는 경우를 지시한다(예컨대 SQL 코드). 상기 예외 테이블 공간이 이전에 존재하면, 상기 프로세스는 단계(2090)로 진행한다. 상기 예외 테이블 공간이 이전에 존재하지 않았다면, 상기 프로세스는 단계(2070)로 진행한다. 단계(2070)에서, CREATE TABLE SQL 문장은 상기 예외 테이블을 생성하기 위하여 설치되고 실행된다. 단계(2080)에서, 임의의 필요한 ALTER SQL 문장은 행 식별 또는 시간 스템프를 상기 예외 테이블에 부가하기 위하여 실행된다.

단계(2090)에서, 점검할 다른 종속 테이블이 있는지 여부가 결정된다. 더이상 점검할 테이블이 없다면, 상기 프로세스는 단계(2100)에서 종료한다. 점검할 다른 테이블이 있다면, 상기 프로세스는 모든 식별된 테이블이 점검될 때까지 단계(2020)로 복귀한다. 모든 예외 테이블이 상기 점검 유틸리티의 사용자에 의해 식별되는 것이 필요한 예외 테이블을 취급하는 종래의 CHECK 유틸리티와 반대로, 본 발명에 따르면, 상기 종속 테이블은 자동으로 식별되고, 그 해당하는 예외 테이블이 발생되기 때문에, 모든 필요한 예외 테이블을 식별할 대 잠재적인 에러 또는 누락을 피할 수 있다.

따라서, 상기 식별된 프로세스는 종래의 CHECK 유틸리티에 의해 실행되어(예컨대, 상기 방법은 상기 CHECK 유틸리티 소프트웨어에서 소프트웨어 알고리즘으로서 제공될 수 있다) 본 발명의 실시예에 따른 예외 테이블을 생성하고 삭제한다. 예컨대, 본 발명의 방법을 이용하면, 상기 특정된 키워드와 함께 상기 제어 문장의 3개의 모 테이블의 포함은 제약 조건 적용에 필요한 31개의 예외 테이블 테이블 공간을 발생하는데 필요한 SQL 문장을 자동으로 발생하고 실행시킨다. 따라서, 본 발명의 실시예에 따르면, 일반적으로 제약 조건 점검에 필요시되는 참조 보존성 제약 조건 적용에 필요한 예외 테이블을 발생하기 위해 CHECK 유틸리티의 사용자가 실행하는 일은 없다.

Claims

예외 테이블을 유지하는 방법에 있어서,

미리 정해진 예외 테이블 변수를 포함하는 제어 문장을 발생하는 단계와,

상기 제어 문장을 점검 유틸리티(CHECK utility)에서 수신하는 단계와,

상기 각각의 미리 정해진 예외 테이블 변수에 대하여 SQL 문장을 발생하는 단계와,

적어도 하나의 SQL 문장을 실행하는 기능으로 예외 테이블의 발생 및 삭제 중 하나를 수행하는 각각의 SQL 문장을 실행하는 단계를 포함하는 것을 특징으로 하는 예외 테이블 유지 방법.
데이터베이스 시스템에서 예외 테이블을 유지하는 방법에 있어서,

적어도 한 개의 미리 정해진 예외 테이블 변수를 포함하는 제어 문장을 수신하는 단계와,

상기 제어 문장을 파싱(parse)하는 단계와,

상기 적어도 한 개의 예외 테이블 변수에 대하여 상기 파싱된 제어 문장의 기능으로 SQL 문장을 발생하는 단계와,

상기 SQL 문장을 실행하는 단계를 포함하는 것을 특징으로 하는 예외 테이블 유지 방법.
제2항에 있어서, 상기 적어도 한 개의 미리 정해진 예외 테이블 변수는 데이터베이스 이름, 예외 테이블 공간 이름, 기억 장치 그룹 이름, 1차 수량 값, 2차 수량 값, 소유자 이름 및 드롭 값(drop value)을 포함하는 것을 특징으로 하는 예외 테이블 유지 방법.
제3항에 있어서, 상기 제어 문장은 복수의 예외 테이블 변수를 포함하는 것을 특징으로 하는 예외 테이블 유지 방법.
제2항에 있어서, 상기 제어 문장을 파싱하는 단계는 통상의 점검 유틸리티에 의해 수행되는 것을 특징으로 하는 예외 테이블 유지 방법.
제2항에 있어서, 상기 SQL 문장을 발생하는 단계는 복수의 예외 테이블 변수에 대한 SQL 문장을 발생하는 단계를 포함하는 것을 특징으로 하는 예외 테이블 유지 방법.