KR101152852B1

KR101152852B1 - 스냅객체모델을 사용한 데이터베이스관리시스템

Info

Publication number: KR101152852B1
Application number: KR1020090041689A
Authority: KR
Inventors: 김지암
Original assignee: 이홍재; (주)유알피시스템
Priority date: 2009-05-13
Filing date: 2009-05-13
Publication date: 2012-06-14
Also published as: KR20100122676A

Abstract

본 발명은 스냅객체모델을 사용한 데이터베이스관리시스템 및 데이터베이스관리방법에 관한 것이다. 더 자세하게는 새로운 순차컬럼(예:p_sq)만으로 상하위 구조 파악이 용이한 데이터를 저장하는 코드대비부와 상위데이터정보의 식별자를 저장하는 자기순환관계부로 구성된 스냅객체모델을 사용한 데이터베이스관리시스템 및 데이터베이스관리방법에 관한 것이다.

본 발명은 제 1 관점으로서 스냅객체모델을 사용한 데이터베이스관리시스템에 있어서, 새로운 순차컬럼(예:p_sq)만으로 상하위 구조 파악이 용이한 데이터를 저장하는 코드대비부와 상위데이터정보의 식별자를 저장하는 자기순환관계부로 이루어진 스냅객체모델로 구성된 스냅객체데이터베이스를 포함하는 것을 특징으로 하는 스냅객체모델을 사용한 데이터베이스관리방법이 제시된다.

스냅객체모델, 코드대비부, 순환관계부, 자기순환엔티티

Description

스냅객체모델을 사용한 데이터베이스관리시스템{The database management system using a snap entity model}

현재 IT기반 시스템 구축 시 순환관계를 적용한 부서관리 기법 및 제조업에서의 BOM(bill of material)구조의 관리기법을 포함한 순환(recursive)구조는 과거 코드대비법에서 자기순환(self recursive)구조로 진화되었다. 하지만 새로운 자기순환구조기법은 거의 과거 방식에서 양산되는 많은 문제점을 보완하는 관리기법이기는 하지만 그 구조상 많은 퍼포먼스의 부하를 양산하고 있다.

또한 시스템을 구현하는 개발자들이 SQL을 구사함에 있어서 충분한 능력을 보유하지 않으면 전혀 잘못된 결과를 도출 하는게 현실이다. 실제로 중급자들도 모르는 경우가 많이 있다. 그래서 이러한 환경에서 벗어나고자 하는 열망을 담아 스 냅객체모델(Snap Entity Model)을 사용하여 데이터를 관리하는 시스템을 구현하게 되었다. 코드대비법과 자기순환구조의 장점을 혼용함으로써 이러한 문제를 해결할 수 있는 방법이 스냅객체모델(Snap Entity Model)이다.

코드 대비법이란 과거에 부서관리시 사용하던 기법으로써 부서코드(예:ID)에 상속 개념을 가지고 가며 퍼포먼스는 상당히 뛰어난 기법이었으나 부서 개편시 많은 문제점을 양산하였다. 일례로 부서 이동시 이동된 부서가 새로운 부서코드를 부여 받아야 했기 때문에 해당 부서코드가 바뀌게 되고 그 하위의 모든 부서는 새로운 부서코드체제로 개편되어야만 했다. 따라서 부서를 사용하는 모든 데이터베이스 부서코드는 부서 개편시 새로운 부서코드로 모두 변경을 해야 하는 위험을 안아야 하는 게 현실이었다.

이른바 흔히 사용하는 두개의 엔티티(Entity)간의 관계 (1:M) 순환(recursive)관계를 ID끼리 상속관계를 가짐으로서 하나의 엔티티(Entity)로 해결하였다. 장점은 수행속도가 빠르고 식별자 만으로 구조파악이 용이하다. 또한 시스템 개발시 상당히 간편하다. 단점은 구조변경시 식별자 및 하위식별자 변경으로 인하여 상당한 위험을 초래하고, 과거의 모든 엔티티(Entity)의 식별자가 변경된 식별자로 변환되어야 한다. 도 1은 코드대비법을 이용한 구축예이다.

자기순환(self recursive)구조란 코드대비법의 단점을 해소한 이론으로써 상위부서와 하위부서를 한 레코드(record)에 관리하여 부서개편시 관계만 변경하는 즉 상위부서만 바꾸어 주는 관리기법이다. 도 2는 자기순환(self recursive)구조를 이용한 구축예이다. 이러한 구조는 코드대비법의 단점을 일거에 해소하였다. 하지 만 이 구조의 본질상 내부적으로 지속적인 조인을 양산하며 많은 성능의 부하를 양산하였다.

그리고 SQL에서 이 구조를 사용하기 위해서 CONNECT BY라는 새로운 SQL이 탄생하였고 이는 곧 개발자들의 상당한 SQL 구사능력을 필요로 하게 되었다. 현실에서 SQL구사능력의 문제로 인하여 시스템에 전혀 의도치 못한 결과를 양산하고, 개발기간의 연장이 불가피하고, 또는 모르고 넘어가는게 현실이었다. 이러한 문제로 인하여 시스템 개발시 상당한 문제점을 가지고 있는게 모든 회사의 현실적인 고민이다. 장점으로는 구조가 변경되어도 식별자는 변하지 않으며 변경데이터 적용이 간단하고, 또한 데이터의 유연성으로 관리가 용이하다. 단점으로는 내부적인 메커니즘이 조인을 위주로 하여 수행되어 속도가 저하되고, 개발시 상당한 기술력이 필요하고, 사용이 불편하여 잘못 사용시 의도하지 않는 결과를 초래하기 쉽다. 그리고 이런 entity는 대부분 시조 entity로써 모든 entity에 기초가 되기 때문에 많은 부하를 양산하는 주범이었다. 그래서 더 많은 비용을 들여 튜닝을 하기도 한다.

상기와 같은 종래기술의 문제점을 해결하기 위하여, 코드대비부와 자기순환관계부로 구성된 스냅객체모델을 사용한 데이터베이스관리시스템 및 스냅객체모델을 사용한 데이터베이스관리방법을 제공하는데 목적이 있다.

상기한 목적을 달성하기 위한 기술적 사상으로서, 제 1 관점으로서 스냅객체모델을 사용한 데이터베이스관리시스템에 있어서,새로운 순차칼럼만으로 상하위 구조 파악이 용이한 데이터를 저장하는 코드대비부와; 상위데이터정보의 식별자를 저장하는 자기순환관계부로 이루어진 스냅객체모델로 구성된 스냅객체데이터베이스를 포함하는 것을 특징으로 하는 스냅객체모델을 사용한 데이터베이스관리시스템이 제시된다.

상기 제 1 관점에 있어서,

상기 스냅객체데이터베이스는, 상위데이터정보의 식별자를 저장하는 칼럼을 가지면서 기초데이터를 저장하는 자기순환엔티티를 더 포함하고, 상기 기초데이터에 변경이 가해지는 순간 상기 스냅객체모델에도 데이터가 생성되는 것을 특징으로 하고,

상기 제 1 관점에 있어서,

상기 스냅객체모델은,새로운 순차칼럼이 상하위를 표시하는 순서인 것을 특징으로 하고,

상기 제 1 관점에 있어서,

상기 스냅객체모델은, 데이터를 정렬하기 위해서 소팅시 새로운 순차칼럼을 이용한 힌트를 사용하는 것을 특징으로 하고,

상기 제 1 관점에 있어서,

상기 스냅객체모델은, 상하위데이터의 개편일자 순서로 상하위데이터가 생성되는 것을 특징으로 한다.

제 2 관점으로서, 스냅객체모델을 사용한 데이터베이스관리방법에 있어서, 자기순환엔티티에 데이터를 생성하는 1단계와; 데이터이동수단이 상기 자기순환엔티티에 생성된 데이터를 기초로 상기 스냅객체모델에 데이터를 생성하는 2단계를 포함하고, 상기 스냅객체모델은 새로운 순차칼럼만으로 상하위 구조 파악이 용이한 데이터를 저장하는 코드대비부와 상위데이터정보의 식별자를 저장하는 자기순환관계부로 구성된 것을 특징으로 하는 스냅객체모델을 사용한 데이터베이스관리방법이 제시된다.

상기 제 2 관점에 있어서,

클러스터링팩터(clustering factor)의 적용으로 인한 Hit Ratio의 최고의 효율성으로 인해서 모든 SQL의 성능이 증대되고, CONNECT BY문의 미사용으로 인하여 개발상의 편리성이 있고, 현재 개발중인 시스템에 전혀 영향없이 적용가능한 효과 가 있다.

또한 스냅객체(Snap Entity)의 빠른 생성이 가능하고, 인라인뷰 없이 다른 엔티티와 조인이 가능한 효과가 있고, 개발기간의 단축이 보장된다. 새로운 순차컬럼(예:p_sq)이 조직도를 펼치는 순서이며 개편일자별로 모든 조직이 생성되므로 다양한 쿼리가 가능하고, 모델링시 필요한 많은 인덱스가 불필요하고, 소팅(Sorting)의 부하가 감소하는 효과가 있다.

이하에서는 첨부한 도면을 참조하면서 본 발명의 실시예에 대한 구성 및 작용을 상세하게 설명하기로 한다.

스냅객체모델(snap entity model)을 사용한 데이터베이스 관리기법은 현재 관리기법의 많은 단점을 해소하고자 만들어진 모델로써 코드(CODE)대비법과 자기순환(SELF RECURSIVE)기법을 혼용함으로써 두개의 장점을 동시에 이용하고 서로의 단점을 보완하는 구조로써 본질은 자기순환엔티티(self recursive entity)이며 스냅(snap)으로 존재하는 엔티티(entity)는 코드대비법을 사용하는 스냅객체모델(snap entity model)이다.

실제 기초데이터는 자기순환엔티티(self recursive entity)에서 관리하며 동시에 기초데이터가 변경이 가해지는 순간 스토어드프로시저나 트리거에 의하여 스냅객체모델(snap entity model)의 데이터도 새로 생성이 된다.

즉 이력개념이 적용된다는 것이다.(스냅모델이 모든 기초데이터를 포함하는 것도 가능하다)

따라서 모든 시스템개발자(system developer)나 설계가(modeler), 프로젝트관리자(project manager)들은 시스템(system)개발시 실제로 사용하는 SQL은 기존의간단한 엔티티를 사용하는 것처럼 스냅객체모델(snap entity model)에 접근하여 사용하면 된다. 이건 곧 connect by 라는 SQL이 사라지는 효과를 가져옴으로써 내부적인 조인이 발생하지 않음으로써 성능이 획기적으로 개선되며 동시에 개발자들은 부담없이 손쉬운 SQL을 사용할 수 있다. 단지 connect by가 사용되는 곳은 자기순환엔티티(self recursive entity)를 스냅객체모델(snap entity)로 변환하는 순간(예:부서개편)만 적용된다.

그리고 또 하나의 장점은 스냅객체(snap entity)모델은 Hit Ratio가 상당히 좋다는 점이다. 이건 기존의 코드대비법을 사용하는 엔티티(entity)와는 구별되는 면으로써 클러스터와 비슷한 성능(보통 10배이상)을 가진다는 점이다. 왜냐하면 스냅객체(snap entity)모델은 자기순환엔티티(self recursive entity)가 변경되는 순간 현재 유효한 데이터들을 모두 같은 순간(일자)으로 새로운 데이터를 생성하기 때문이며 이러한 데이터는 변경이 거의 없어 같은 일자의 데이터들은 모두 연이은 공간에 존재하기 때문에 성능을 더욱더 증대시키는 효과를 가져온다.

그리고 이러한 엔티티(entity)는 모두 시조 엔티티(entity)의 성격을 가지고 있기 때문에 main entity, active entity등의 많은 엔티티(entity)들에 상당한 파급효과를 가져오며 이러한 엔티티(entity)들의 가공된 정보를 창출하는 SQL이 사용하기 편리해지게 된다. 만일 데이터의 본질적인 변경이 일어나더라도 최근 데이터 중의 하나일 경우가 확실하므로 이러한 경우도 그 이후의 데이터를 지우고 다시 생 성하면 된다. 이때 상당히 빠른 데이터 삽입(Insert)성능이 나온다.

단. 주의할 점은 확장성을 고려하여 새로운 순차컬럼(예:p_sq)을 만들 시 확장성을 고려하여 유형코드+순차(sq) 또는 순차(sq)를 기초로 생성을 해야 하며 유형(예,AA:부문,BB:본부…)문자접두어를 두문자 이상으로 하여 레벨(LEVLE)간의 문자간격을 확장성을 고려하여 넓히는게 타당하다. 예로서 레벨 1은 AA001, AA010, AA020.., 레벨 2는 BB001, BB010, BB020 등으로 구성하면 향후 확장성,안정성,재사용성에도 전혀 문제가 없을 것이다.

도 3은 스냅객체모델(snap entity model)을 사용한 데이터베이스의 일 예이다. 스냅객체모델(snap entity model)을 사용한 데이터베이스관리시스템은 코드대비부(예:p_sq)와 자기순환관계부로 구성된 스냅객체모델을 사용한다. 상기 코드대비부는 새로운순차컬럼(예:p_sq)만으로 상하위 구조 파악이 용이한 데이터를 저장한다. 상기 자기순환관계부는 상위데이터정보를 포함하는 개념이다. 여기서 p_sq가 코드대비부에 해당하고, ID(부서코드),P_ID(상위부서코드)가 자기순환관계부에 해당한다.

도 4는 스냅객체모델을 사용했을 경우 Hit Ratio와 클러스터링 팩터(clustering factor)가 극대화 되는 예이다. 접근하는 데이터가 캐쉬메모리에 존재하는 비율인 Hit Ratio가 증대되어 성능이 증대된다. 데이터량도 일정하기 때문에 클러스터(cluster)로 변환가능하다.

도 5는 다양한 가공컬럼들의 사용으로 시스템성능이 극대화 되는 예이다.

실시 예를 들어가며 스냅객체모델(Snap Entity Model)을 사용한 데이터베이 스관리시스템을 설명한다. 부서개편은 종류별로 부서의 생성,부서의 이동,부서의 폐쇄가 발생되는 일련의 경우가 생길 경우를 이야기 한다. 예를 들면 XXX 라는 회사에서 2008년 09월 10일 현재 a라는 부서는 상위 부서로써 b라는 부서를 가지고 있으며 하위부서로써 c라는 부서를 가지고 있다. a라는 부서가 d라는 부서의 하위부서로 이동하여 조직이 개편되면 개편된 일자를 가지고 현재 개편된 조직만 상위조직을 업데이트(update) 또는 삽입(Insert)을 하여 데이타를 관리하게 된다. 조직개편의 행위가 엔티티(entity)에 반영이 끝나면 개편일자를 가지고 개편당시의 모든조직을 connect by 구문을 이용하여 순차를 가지고 상하관계를 조합하여 개편당시의 모든 모습을 새로운 엔티티(entity)에 해당일자로 코드(code)대비법에서 사용하는 개념으로 코드대비부(예:p_sq)에 새로운 순차데이터를 만들어내어 스냅객체(snap entity)모델에 저장하게 된다. 따라서 connect by 구문을 사용하는 예는 단 한번 조직 개편시 스냅객체(snap entity)모델을 추출하는 경우만 사용한다. 그래서 모든 조직과 관계된 조인이나 공급자 서브쿼리 또는 확인자 서브쿼리시 모든 SQL은 스냅객체(snap entity)모델을 대상으로 하여 간단한 SQL만 사용하며 I/O효율과 성능을 극대화하게 된다.

일례로 조직도를 그릴때 이후에 나오겠지만 현재 사용하고 있는 SQL에는 정확한 조직도를 펼치기가 힘들고 SQL이 어려우며 스냅객체(snap entity)모델에서 사용하는 SQL과는 극명한 차이를 한눈에 확인 할 수 있다.

제조업체에서 사용되는 BOM(Bill Of Material)구조에서는 더더욱 이러한 관리기법이 필요할 것이다. 스냅객체(Snap Entity)모델의 장점으로써 클러스터링 팩 터(clustering factor)를 가지고 있지만 처음부터 클러스터(cluster)로 지정하는 것도 가능하다. 그리고 업데이트(update)는 거의 일어나지 않을 것이며 모두 삽입(Insert)이 될 것이므로 굳이 클러스터(Cluster)를 사용하지 않아도 계속적으로 클러스터링 팩터(Clustering Factor)를 유지할 것이다.

굳이 최근 데이터 중에서 사용자의 실수로 부서개편 정보를 다시 수정해야 한다면 스냅객체(Snap Entity)모델은 삭제(Delete)와 삽입(Insert)을 사용하면 되고 이 또한 성능이 뛰어날 정도로 빠르게 만들어 낼 수 있다. 이는 오라클9i부터 제공하는 계층정보를 찾아오는 SYS_PATH함수를 이용해서 가능하다. 그리고 과거 부서정보 개편변경은 기존 자기순환구조에서도 주의를 요하는 것은 마찬가지 이다.

이후부터는 부서개편시 스냅객체(Snap Entity)모델을 만드는 SQL을 구체적으로 살펴보자. 아래에는 스냅객체(Snap Entity)모델을 만드는 SQL과 이를 BOM구조에 응용한 SQL이다.

단 . 여기서 스냅모델에서 개편일자를 찾아오는 것은 한건이므로 함수를 사용한다. 사용하는 함수는 예를 들어 F_ID_YMD(XX)로 한다.

-insert into snap_entity

SELECT uid(pk), replace(Sys_connect_by_path(a.sq,'-'),'-','') p_sq, a.*

FROM 부서테이블 a

where :v3 between a.sta_ymd and a.end_ymd

and a.회사코드 = :v1

CONNECT BY PRIOR a.org_cd = a.super_org_cd

and :v3 between a.sta_ymd and a.end_ymd

and a.회사코드=:v1

START WITH a.상위부서코드 = :v2

and :v3 between a.sta_ymd and a.end_ymd

and a.회사코드=:v1

- 응용 : BOM 구조

insert into snap_entity

SELECT uid(pk), replace(Sys_connect_by_path(a.sq,'-'),'-','') p_sq, replace(Sys_connect_by_path(a.수량,'-'),'-','') qty, a.*

FROM 자재테이블 a

where …..

다음으로는 자기순환구조에 의한 SQL과 스냅객체(Snap Entity Model)모델을 사용한 SQL의 구체적인 적용방법을 살펴보자. 아래에는 자기순환구조에 의한 조회 SQL과 스냅객체(Snap Entity Model)모델을 사용한 조회 SQL이 나타나 있다.

-- 자기순환구조에 의한 조회 SQL

select level lvl,a.*

from 부서테이블 a

where :v3(조회일자) between a.개편시작일 and a.개편종료일

and a.회사코드 = :v2(회사코드)

connect by prior a.부서코드 = a.상위부서코드

and :v3(조회일자) between a.개편시작일 and a.개편종료일

and a.회사코드 = :v2(회사코드)

start with 상위부서 코드 = :v1(상위부서코드)

and :v3(조회일자) between a.개편시작일 and a.개편종료일

and a.회사코드 = :v2(회사코드)

-- 스냅객체(Snap Entity Model)모델을 사용한 조회 SQL

select /*+index_asc(a idx_psq)*/

a.*

from snap_entity a

where a.개편일자 =F_ID_YMD(XX)

and a.p_sq > ''

and a.회사코드 = :v2(회사코드)

위의 두개의 쿼리를 비교해 보면 자기순환구조에 의한 조회 SQL(첫번째 쿼리)은 내부적으로 많은 셀프(self)조인을 발생시키며 데이터가 많을수록 클러스터링 팩터가 좋지 않으면 속도는 기하급수적으로 감소한다. 즉 많은 디스크암(Disk Arm)의 이동으로 인하여 데이터 로딩속도가 늦어진다. 그리고 같은 레벨별로 순차를 표시하는 것도 상당히 어렵다. 그렇지만 스냅객체모델(Snap Entity Model)을 사용한 조회 SQL(두번째 쿼리)은 서브쿼리가 단 하나의 인덱스만 바로 읽고 그리고 디스크 클러스터링 팩터의 양호로 인하여 속도보장이 확실하며 이러한 문제를 단번에 해결한다.

아래에는 자기순환구조에 의한 상위조직명 찾는 SQL과 스냅객체모델(Snap Entity Model)을 사용한 상위조직명 찾는 SQL이 나타나 있다.

-- 자기순환구조에 의한 상위조직명 찾는 SQL

select a.상위부서명

from 부서테이블 a

where a.부서코드 = (select b.상위부서코드

from 부서테이블 b

where b.부서코드 = :v1(부서코드)

and :v3(조회일자) between b.개편시작일 and b.개편종료일

and b.회사코드 = :v2(회사코드))

and :v3(조회일자) between a.개편시작일 and a.개편종료일

and a.회사코드 = :v2(회사코드)

-- 스냅객체모델(Snap Entity Model)을 사용한 상위조직명 찾는 SQL

select /*+ index_desc( a idx_psq) */

a.상위부서명

from snap_entity a

where a.p_sq < :v4(화면에서 들어온 새로운 순차컬럼의 값)

and a.회사코드 = :v2(회사코드)

and a.개편일자 =F_ID_YMD(XX)

and a.rownum =1

아래에는 상위부서 모두를 찾을때를 보여준다. 아래에는 자기순환구조에 의한 상위조직명 찾는 SQL과 스냅객체(Snap Entity Model)모델을 사용한 상위조직명 찾는 SQL의 다른예가 나타나 있다.

-- 자기순환구조에 의한 상위조직명 찾는 SQL

select a.*

from 부서테이블 a

where :v3(조회일자) between a.개편시작일 and a.개편종료일

and a.회사코드 = :v2(회사코드)

connect by prior a.상위부서코드 = a.부서코드

and :v3(조회일자) between a.개편시작일 and a.개편종료일

and a.회사코드 = :v2(회사코드)

start with 부서코드 = :v1(부서코드)

and :v3(조회일자) between a.개편시작일 and a.개편종료일

and a.회사코드 = :v2(회사코드)

-- 스냅객체(Snap Entity Model)모델을 사용한 상위조직명 찾는 SQL

select a.*

from snap_entity a

where a.p_sq between :v5(최상위부서 순차컬럼)

and :v6(해당부서코드에 해당하는 새로운 순차컬럼)

and a.회사코드 = :v2(회사코드)

and a.개편일자 =F_ID_YMD(XX)

아래는 자기순환구조에 의한 하위부서 찾는 SQL과 스냅객체(Snap Entity Model)모델을 사용한 하위부서 찾는 SQL이다.

-- 자기순환구조에 의한 하위부서 찾는 SQL

select a.*

from 부서테이블 a

where a.회사코드 = :v2(회사코드)

and :v3(조회일자) between a.개편시작일 and a.개편종료일

connect by prior a.부서코드 = a.상위부서코드

and a.회사코드 = :v2(회사코드)

and :v3(조회일자) between a.개편시작일 and a.개편종료일

start with 부서코드 = :v1(부서코드)

and a.회사코드 = :v2(회사코드)

and :v3(조회일자) between a.개편시작일 and a.개편종료일

-- 스냅객체(Snap Entity Model)모델을 사용한 하위부서 찾는 SQL

select a.*

from snap_entity a

where a.p_sq like :v5(해당부서코드에 해당하는 새로운 순차컬럼) ||‘%’

and a.회사코드 = :v2(회사코드)

and a.개편일자 =F_ID_YMD(XX)

도 6은 기존의 자기순환구조와 본 발명인 스냅객체(Snap Entity)모델을 사용하여 데이터베이스를 관리하는 시스템을 사용했을 때의 데이터를 읽는 순서와 SQL문을 비교하고 있다. 자기순환구조의 경우에는 디스크상에 일렬로 데이터들이 정렬되어 있지 않아 디스크를 이동하면서 데이터를 읽어 들어야 하나 본 발명인 스냅객체(Snap Entity)모델을 사용하여 데이터베이스를 관리하는 시스템에서는 데이더들이 상하위구조로 정렬되어 있어 디스크의 이동없이 데이터를 읽을수 있다.

도 7은 기존의 자기순환구조와 본 발명인 스냅객체(Snap Entity)모델을 사용하여 데이터베이스를 관리하는 시스템을 사용했을 때, 하위그룹을 전개하지 않을 때와 특정의 행을 추출하지 않을 때의 SQL문을 비교하고 있다. 본 발명인 스냅객체(Snap Entity)모델을 사용하여 데이터베이스를 관리하는 시스템의 SQL문이 connect by라는 문을 사용하지 않아 성능이 더 우수하다.

도 8은 본 발명인 스냅객체(Snap Entity)모델을 제조업체에서 사용되는 BOM(Bill Of Material)구조에 적용했을 때의 적용예이다.

현재의 BOM(Bill Of Material)구조에서는

FOR m IN (select id, level lvl, qty

from bom

where ....

connect by prior id = p_id

and ....

start with p_id = *

and ....)

) LOOP

상기 FOR문안의 SQL이 connect by를 사용하고 있으나 여기에 스냅객체모델을 적용했을 경우에는 도시된 바와 같이 아래의 FOR문안의 SQL이 connect by를 사용하고 있지 않아 성능면에서 우수하다.

FOR m IN (select id, level lvl, qty

from bom

where p_sq like 'AA001%'

and ...)

) LOOP

도 9는 본 발명인 스냅객체(Snap Entity)모델을 사용하여 데이터베이스를 관리하는 시스템을 사용했을 때의 프로젝트 관리모습의 일예를 보여주고 있다. 도 8 을 근거로 결론을 내려보면 앞에서 SQL적용사례를 비교해 보면 개발자들은 SQL을 단순화 하면서 SQL의 적정성을 고민할 이유가 없고 데이터의 정확성만이 고려대상으로 바뀌게 된다. 즉 아주 편리한 개발환경이 된다. 그렇다면 무슨 방법을 택하여 프로젝트를 진행할 것인지가 명확해진다. 이런 스냅객체(Snap Entity)모델을 BOM구조에도 적용하게 되면 수량계산시 아주 편리한 기초를 제공할 것이다.

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

도 1은 코드대비법을 이용한 구축예이다.

도 2는 자기순환(self recursive)구조를 이용한 구축예이다.

도 3은 스냅객체모델(snap entity model)을 사용한 데이터베이스의 일 예이다.

도 4는 스냅객체모델을 사용했을 경우 Hit Ratio와 클러스터링 팩터(clustering factor)가 극대화 되는 예이다.

도 6은 기존의 자기순환구조와 본 발명인 스냅객체(Snap Entity)모델을 사용하여 데이터베이스를 관리하는 시스템을 사용했을 때의 데이터를 읽는 순서와 SQL문을 비교하고 있다.

도 7은 기존의 자기순환구조와 본 발명인 스냅객체(Snap Entity)모델을 사용하여 데이터베이스를 관리하는 시스템을 사용했을 때, 하위그룹을 전개하지 않을때와 특정의 행을 추출하지 않을 때의 SQL문을 비교하고 있다.

도 9는 본 발명인 스냅객체(Snap Entity)모델을 사용하여 데이터베이스를 관리하는 시스템을 사용했을 때의 프로젝트 관리모습의 일예를 보여주고 있다.

< 도면의 주요부호에 대한 설명 >

Claims

스냅객체모델을 사용한 데이터베이스관리시스템에 있어서,

유형코드와 순차(sq), 또는 순차(sq)를 기초로 이루어지는 새로운 순차칼럼(p_sq)을 생성하여 저장하기 위한 코드대비부와;

상위데이터정보의 식별자를 저장하는 자기순환관계부로 이루어진 스냅객체모델로 구성된 스냅객체데이터베이스를 포함하는 것을 특징으로 하는 스냅객체모델을 사용한 데이터베이스관리시스템.
청구항 1에 있어서,

상기 스냅객체데이터베이스는,

상위데이터정보의 식별자를 저장하는 칼럼을 가지면서 기초데이터를 저장하는 자기순환엔티티를 더 포함하고,

상기 기초데이터에 변경이 가해지는 순간 상기 스냅객체모델에도 데이터가 생성되는 것을 특징으로 하는 스냅객체모델을 사용한 데이터베이스관리시스템.
청구항 1 또는 2에 있어서,

상기 스냅객체모델은,

새로운 순차칼럼이 상하위를 표시하는 순서인 것을 특징으로 하는 스냅객체모델을 사용한 데이터베이스관리시스템.
청구항 1 또는 2에 있어서,

상기 스냅객체모델은,

데이터를 정렬하기 위해서 소팅시 새로운 순차칼럼을 이용한 힌트를 사용하는 것을 특징으로 하는 스냅객체모델을 사용한 데이터베이스관리시스템.
청구항 1 또는 2에 있어서,

상기 스냅객체모델은,

상하위데이터의 개편일자 순서로 상하위데이터가 생성되는 것을 특징으로 하는 스냅객체모델을 사용한 데이터베이스관리시스템.
스냅객체모델을 사용한 데이터베이스관리방법에 있어서,

자기순환엔티티에 데이터를 생성하는 1단계와;

데이터이동수단이 상기 자기순환엔티티에 생성된 데이터를 기초로 상기 스냅객체모델에 데이터를 생성하는 2단계를 포함하고,

상기 스냅객체모델은 유형코드와 순차(sq), 또는 순차(sq)를 기초로 이루어지는 새로운 순차칼럼(p_sq)을 생성하여 저장하기 위한 코드대비부와 상위데이터정보의 식별자를 저장하는 자기순환관계부로 구성된 것을 특징으로 하는 스냅객체모델을 사용한 데이터베이스관리방법.
청구항 6에 있어서,

상기 스냅객체모델은,

상하위데이터의 개편일자 순서로 상하위데이터가 생성되는 것을 특징으로 하는 스냅객체모델을 사용한 데이터베이스관리방법.