|
데이타베이스 리엔지니어링
방난효, 최은만, 엄기현
동국대학교 컴퓨터공학과
전화: (02)260-3345
E-mail: emchoi@cakra.dongguk.ac.kr
1. 서 론
2. 관계형 DB와 객체지향 DB의 비교
3. 관계형 DB와 객체지향 DB의 결합
4. 변환 규칙
5. 결론
1. 서 론
소프트웨어 리엔지니어링은 새로운 기술을 이용하여 노후된 시스템을 개혁하는 과정이다. 예를 들면 관계형 데이타베이스 기술이나 새로운 통신 프로토콜, 분산처리 기술, 객체지향 기술 또는 새로운 사용자 인터페이스 기술들을 적용하는 것이다. 오래된 데이타베이스에 대한 문제는 다음 세 가지로 구분된다. 첫째 자료의 정의에 관한 문제들, 예를 들면 자료의 이름이 명확하지 않거나, 필드 길이가 맞지 않는 경우, 레코드 레이아웃이 부적절한 문제, 상수가 hard-code 된 경우 등이다. 대규모 자료의 경우 자료를 구성하는 각 필드에 대한 설명이 자세히 자료사전에 기록되는데 정확한 정보를 담고 있어야 한다. 두 번째 문제는 자료값 자체에 대한 문제이다. 디폴트 값이 일치하지 않거나 자료값이 존재하지 않거나(missing data), 또는 자료값이 절단된 경우, 자료값의 단위가 일치하지 않는 경우 문제가 된다.
데이타베이스 리엔지니어링이 불가피한 가장 큰 요인은 데이타베이스 패러다임의 전환이다. 화일 저장 방식에서 데이타베이스를 도입하는 경우, 계층적 또는 네트워크형 모형의 데이타베이스에서 관계형 데이타베이스로 전환하려는 경우이다. 경험에 의하면 이 작업은 데이타베이스 구조와 밀접히 관련되어 매우 어려운 작업이다. 즉 계층적 구조에서는 child 레코드와 parent 레코드가 묶여 있어 관계형 데이타베이스에서 필드의 값으로 레코드의 관계를 표현하기가 쉽지 않다.
객체 지향 관련 기술의 발전에 따라 기존의 시스템을 객체 지향 시스템으로 변환하려는 시도가 증가하고 있다. 지금까지 관계형 데이타 모델을 주 모델로 하던 데이타베이스 분야에서도 이러한 추세가 반영되고 있다. 객체 지향 자료 모델은 복잡한 실세계의 모델링이 관계형 자료 모델보다 더 뛰어나다. 또한 멀티미디어 자료형을 데이타베이스에서 처리하기 위해 가장 적합한 모델로 평가되어 많은 멀티미디어 응용 데이타베이스의 기본 모델로 채택되고 있다. 따라서 이미 개발된 관계형 데이타베이스를 객체 지향 데이타베이스로 바꾸는 방법이 고려되어야 하며 그러기 위해서는 사용되던 많은 관계형 데이타의 변환이 선행되어야 한다.
본 논문에서는 관계형 자료 모델과 객체 지향 자료 모델의 설계 과정을 통한 차이점을 분석하고 그에 따른 단계적 변환 과정을 알아본다. 객체 지향 자료 모델을 만들기 위한 방법으로 의미 객체 모델링을 이용하는데 이에 필요한 의미 자료 모델링은 기존 관계 데이타베이스 시스템의 EER(Extended Entity Relationship) 다이어그램으로 한다. 즉, 관계형 자료 모델을 표현한 EER 다이어그램의 자료를 이용하여 그에 대응하는 객체 지향 자료 모델을 생성하는 것이다. EER을 통한 객체형 자료로의 변환 규칙에서는 선정된 객체와 객체간의 관계, 다양한 제약 조건들에서의 매핑 조건들이 논의되고 다루어진다. 또한 자료 흐름도에서 자료 저장소와 입출력 자료 사이의 관계를 분석하여 클래스에서 행해지는 연산을 메소드로 구현한다.
2 관계형 DB와 객체지향 DB의 비교
데이타 모델이란 데이타베이스의 형식적인 프레임워크 내에 어떻게 정보를 표현하고 기술 지에 관한 문제이다. 데이타 모델은 크게 객체 타입의 집합, 연산자의 집합, 일반적인 무결성 규칙의 집합 등 세 가지로 구성된다. 객체 타입이란 데이타베이스에서 표현될 논리적인 구조의 단위를 말하며 연산자란 객체 타입의 인스턴스 값에 수행되는 작업을 말한다. 무결성 규칙은 데이타베이스의 유효(valid) 상태를 확실하게 하기 위한 제약 조건을 의미한다. 이 세 가지의 집합을 정확히 기술해야 보다 구체적인 실세계의 객체를 표현할 수 있고 이를 기반으로 한 데이타베이스 트랜잭션을 수행할 수 있다[1].
데이타 모델 선정은 데이타베이스의 설계 단계 중 개념적 데이타베이스 설계 과정에 속하고 생성된 데이타 모델은 ER 다이어그램이나 EER 다이어그램으로 표현되어 논리적 데이타베이스 설계에 이용된다. 데이타베이스를 설계하는 것은 데이타 객체의 구조와 그들 간의 관계를 정의하여 스키마를 생성하는 것으로 시작된다. 서로 다른 데이타 모델들은 서로 다른 개념의 데이타 구조와 관계를 제공한다. 관계형 데이타 모델에서, 데이타 구조는 테이블로 정의된다. 테이블의 속성은 시스템에서 지정한 단위적인 데이타 타입에 의해 기술된다. 관계는 한 릴레이션 내에 외래 키로 표현되는데 외래키는 자신 또는 다른 릴레이션의 주 키인 것이여야 한다. 각 객체가 테이블의 주 키에 의해 유일하게 식별되므로 관계형 데이타 모델은 한 테이블의 각 외래 키상에 참조적 무결성과 주 키에 객체 무결성을 보장해야 한다 [2].
객체지향 데이타 모델에서 데이타 구조는 클래스로 정의된다. 클래스의 속성들은 사용자 정의형이나 비원자(nonatomic) 형도 가능하다. 관계는 복합 애트리뷰트에 의해 표현되는데, 이것은 연결된 객체를 참조하는 것으로 구현된다. 관계형 데이타 모델과는 달리 객체들은 그 자신들의 식별자에 의해 구별되므로 객체지향 데이타 모델은 주 키나 외래 키 제약이 필요 없다. 다음의 표 1은 OODBMS와 RDBMS의 차이점을 나타낸 것이다.
OODBMS RDBMS
클래스
오브젝트 테이블
사용자 정의 자료형 기능 튜플 또는 행
객체 식별자 (Oid) 내장된 데이타형만 가능
데이타 + 프로시져 키(key)
Navigation, Path 데이타
참조(reference) Join
프로그래밍 언어와 DB언어의 일치 외래키 (Foreign Key)
메모리와 디스크에서의 데이타 표현이 동일 프로그래밍 언어와 DB 언어의 불일치
객체지향 특성 지원 표현이 상이함
- 상속(Inheritance) 지원 못함
- 캡슐화(Encapsulation)
- 다형성 (Polymorphism)
[b]표 1 OODBMS 와 RDBMS 비교[/b]
3 관계형 DB와 객체지향 DB의 결합
RDB와 OODB를 결합하는 방법은 두 데이타베이스 사이에 통로(gateway)를 두는 방법, RDB위에 객체지향 계층(OO-layer)을 두는 방법, RDB와 OODB를 하나로 통합하여 단일 시스템으로 구축하는 방법 등 크게 세 가지가 있다[3]. 통로를 두는 방법에서 OODB는 사용자의 질의를 단순히 변환하여 RDB로 전송하고 RDB는 이를 수행하여 그 결과를 다시 OODB에 전송한다. 이러한 통로 방식은 질의에 검색만 허용한다거나 여러 질의어를 갖는 트랜잭션을 지원하지 못하는 등 단순한 질의만을 허용하여 많은 제약을 갖는다는 단점이 있다. 객체지향 계층을 두는 방법은 사용자가 OODB 언어를 이용하여 시스템에 접근하면 객체지향 계층이 데이타베이스 언어에 나타난 모든 객체지향 측면을 하부의 RDB와 상호 작용할 수 있도록 관계형으로 변환해 준다. 이 방법을 사용하는데 있어서의 장점은 객체지향 계층을 현재 존재하는 다양한 RDB 위에 이식할 수 있다는 것이다. 단, 이러한 유연성은 복잡한 데이타베이스 기능이 요구될 때 심각한 성능 저하와 운영상의 문제를 유발한다는 단점을 가지고 있다. 단일 시스템으로 통합하는 방법은 RDB의 저장 관리 계층과 자료 관리 계층에 필요한 모든 변환을 하여 OODB와 RDB를 하나의 계층으로 만드는 것이다. 이를 위하여는 관계형과 객체지향 자료 모델을 하나의 통합된 모델로 결합하고 데이타베이스 언어가 허용하는 모든 기능의 지원과 관계형이나 객체지향형 어디에도 적용되는 질의를 제공하는 등 많은 기술적인 문제들이 해결되어야 한다.
상이한 두 데이타 모델간에 자료 변환을 하기 위해서는 관계형 데이타베이스에 객체지향 개념을 도입한 확장이 필요하다. 첫째, 테이블의 열 값이 시스템 정의형뿐만 아니라 사용자 정의형도 가능하도록 해야 한다. 이는 사용자가 정의한 임의의 테이블을 다른 테이블의 열 값으로 지정할 수 있게 하여 순환적 참조와 중첩을 가능하게 한다. 두 번째 확장은 객체지향 개념의 캡슐화이다. 캡술화는 데이타를 조작하기 위한 프로그램과 데이타를 결합하는 것이다. 이것은 한 테이블에 속하는 튜플의 열에 대한 연산을 수행하는 프로시져를 그 테이블, 즉 객체에 부착시킴으로써 가능하다. 세 번째는 계승 계층의 개념을 도입하는 것이다. 테이블(객체)간에 계층적 상속을 통해 부모 테이블의 모든 열과 프로시져를 상속받고 두 테이블간의 관계는 IS-A 관계로 관리된다. 네 번째는 테이블의 항목이 임의의 자료형을 포함하는 다중 값을 갖는 것을 허용하는 것이다.
OODB 자료형으로의 변환은 RDB에 기본적으로 위의 네 가지 변환 방법을 적용하고 테이블은 클래스로, 각 튜플은 클래스의 인스턴스로, 프로시져는 클래스의 메소드로 부모와 자식 테이블은 상위, 하위 클래스로 전환하는 설계를 하는 것으로 이루어진다. 세부적인 변환 기법은 계속되는 절에서 설명한다. 실례로 Object Design사의 객체지향 데이타베이스 시스템인 ObjectStore에서는 DBconnect family라는 서비스를 제공하여 다른 데이타베이스 시스템(Oracle, DB2, Sybase 등)과 데이타를 교환한다. DBconnect family는 ObjectStore gateway, ObjectStore SQL 클라이언트, 스키마 매퍼로 구성되어 있다[4]. ObjectStore gateway는 ObjectStore C++ 클라이언트가 타 데이타베이스를 마치 ObjectStore의 데이타베이스인 것처럼 투명하게 액세스하는 응용 프로그램을 개발할 수 있게 한다. 이를 위해서는 스키마 매퍼에 의한 데이타 모델의 매핑이 선행되어야 한다. 스키마 매퍼는 객체 모델과 관계형 모델 사이의 대응을 포착하는 스키마 맵을 생성하고 두 모델 사이의 name space를 매핑하는 능력을 제공한다. ObjectStore SQL 클라이언트는 이러한 환경을 바탕으로 SQL을 이용하여 ObjectStore C++ 데이타를 액세스하여 질의 수행, 레포트 작성, 갱신 등을 할 수 있다.
4. 변환 규칙
EER 스키마를 OODB 스키마로 변환하는 단계는 크게 다음의 세 단계로 나뉘어진다[5].
1. EER의 객체 타입과 관계 타입을 객체 지향 클래스로 사상(map)한다. 단정적으로 기술할 수 없는 제약 조건은 메소드(method)내에서 구현한다.
2. 각 객체 지향 클래스에 부가적인 메소드를 첨가한다.
3. 데이타베이스의 클래스로 전환하기 위해 객체 지향 클래스를 확장한다. 즉, 영속적인(persistent) 객체를 처리하기 위해 시스템에서 제공하는 명령문을 추가한다.
1 단계의 변환에 관한 세부적인 내용은 다음과 같다. 클래스 정의는 각 단계에 따라 적용되는 규칙을 첨가해가며 기술해 나간다[2].
4.1 객체
(1) 객체 (entity)
각 객체는 1 대 1로 클래스로 사상한다. 약 객체(weak entity) 타입은 주 객체(primary entity) 타입과 다르지 않다. 이는 키 애트리뷰트가 OODB에서 객체를 식별하는 데 사용되지 않기 때문이다. EER 내에 객체 타입에서의 계층 관계는 객체지향 클래스의 계층 관계로 그대로 사상되고 다중값 (multivalued) 애트리뷰트는 집합 애트리뷰트로 전환된다.
class Project{ class Child { // weak entity
string name ; string name;
string startdate; string birthdate;
}; };
(2) 애트리뷰트 (attribute)
단일값 애트리뷰트는 클래스 내에 기본 자료 타입을 갖는 애트리뷰트가 된다. 반면 다중값 애트리뷰트 (multivalued attribute)은 값의 순서가 중요할 경우 리스트(list) 애트리뷰트가 된다. 그렇지 않을 경우에는 집합 자료 타입인 애트리뷰트가 된다.
class Department {
string name ;
set <string> locations;
};
유도되는 애트리뷰트(derived attribute)는 값을 오퍼레이션에 의해 생성할 수 있는 유도되는 애트리뷰트가 된다. 복합 애트리뷰트(composite attribute)는 복합 애트리뷰트란 하나의 애트리뷰트가 여러 개의 애트리뷰트로 구성된 것을 말한다. 다음과 같이 ER 다이어그램 내의 복합 애트리뷰트에 대응하는 클래스를 생성하고, 생성된 클래스를 도메인으로 하는 참조 애트리뷰트를 포함시킨다.
class Employee{ class Name {
string ssn; string firstname;
Name nm; string midinit;
integer salary; string lastname;
}; };
1 : 1 관계성의 애트리뷰트는 영속성을 보다 많이 가진 클래스의 애트리뷰트가 된다. 1 : N 관계성의 애트리뷰트는 N-Side 클래스의 애트리뷰트가 된다. M : N 관계성의 애트리뷰트는 M : N관계 규칙에 의해 생성되는 링크 클래스 L의 애트리뷰트가 된다. Works_on 관계의 hours 애트리뷰트가 이에 해당하는데 이 애트리뷰트는 관계 정의 후 생성된 관계 클래스에 기본 속성으로 첨가된다.
(3) 종속 객체
소유 객체에 집합값(Set-Valued) 애트리뷰트로 추가되며, 이 애트리뷰트의 도메인은 종속 클래스가 된다.
class Department { //소유 객체 class Project{ //종속 객체
string name ; string name no_null unique;
set <string> locations; string startdate;
set <Project> control; Department controlled_by;
}; };
4.2 관계 (relationship)
(1) 이진 관계(binary relationship)일 경우
이진 관계형은 객체지향 클래스의 객체 참조(reference)로 전환된다. 만약 시스템이 역방향 참조를 제공한다면 양방향 항해(navigation)를 유용하게 하기 위해 양방향 참조를 이용한다. 관계의 카디널리티(cardinality)가 1보다 크게 되면 객체 참조의 집합을 사용한다.
해당 관계성이 집단화를 구성하고 있을 경우는 집단화에 대응하는 클래스가 생성되어 있는지 확인하여, 생성되었을 경우에는 1:1 이진 관계 규칙으로 진행하고, 생성되지 않았을 경우에는 집단화 규칙을 먼저 적용한다. 1:1인 경우 클래스 A는 클래스 B에 대한 참조 애트리뷰트를 가지며, 클래스 B는 클래스 A에 대한 참조 애트리뷰트를 가진다.
class Department { class Manager : Employee
string name ; Department manager;
set <string> locations; };
Manager manager_by; //참조 애트리뷰트를 두 클래스에 첨가
set <Project> control;
};
1:N인 경우, 클래스 A는 클래스 B에 대한 참조 집합(Reference Set) 애트리뷰트를 가지며 클래스 B는 클래스 A에 대한 참조 애트리뷰트를 가진다.
class Department { class Employee{
string name ; string ssn;
set <string> locations; Name nm;
Manager manager_by; integer salary;
set <Project> control; Department work_for; // 참조 애트리뷰트
set <Employee> hire; };
}; //참조 집합 애트리뷰트
M:N인 경우 다은과 같은 과정으로 변환한다. 먼저 관계에 대응하는 링크 클래스 L을 생성한다.다음은 링크 클래스 L에 클래스 A와 클래스 B에 대한 참조 애트리뷰트를 추가한다. 관계성에 키가 아닌 애트리뷰트가 있을 경우 이를 링크 클래스 L의 애트리뷰트로 추가한다. 마지막으로 클래스 A 및 B에 타입이 L인 참조 집합 애트리뷰트를 추가한다.
class Project{ class Engineer : Employee
string name ; set <string> specialities;
string startdate; set <Work_on> wk;
Department controlled_by; };
set<Work_on> wk;
};
class Work_on { // 링크 클래스 L
Project proj;
Engineer engr;
integer jours;
};
(2) N-ary (N>2) 관계성
이진 관계성과 동일한 방법으로 클래스를 생성한다.
[](3) 객체 A와 객체 B 사이에 ISA 관계성이 있을 경우
클래스 A에 클래스 B를 상위 클래스로 정의한다.
(4) 객체 A에 상위 역할 및 하위 역할을 가지는 되흐름(recursive) 관계성이 있는 경우
1:1(상위 역할 : 하위 역할)이면 클래스 A는 상위 역할 및 하위 역할에 대한 참조 애트리뷰트를 가진다. 1:N(상위 역할 : 하위역할) 클래스 A는 하위역할에 대한 참조 집합 애트리뷰트와 상위 역할에 대한 참조 애트리뷰트를 가진다. N:1(상위 역할 : 하위역할) 클래스 A는 상위 역할에 대한 참조 집합 애트리뷰트와 하위역할에 대한 참조 애트리뷰트를 가진다. M:N인 경우는 먼저 되흐름 관계성을 위한 링크 클래스 L을 생성한다. 다음은 링크 클래스 L에 상위역할과 하위역할에 대한 참조 애트리뷰트를 추가한다. 관계성에 키가 아닌 애트리뷰트가 있을 경우 이를 클래스 L의 애트리뷰트에 추가하고 나면 클래스 A는 상위 역할 및 하위역할 각각에 대한 참조 집합 애트리뷰트를 가진다.
(5) 집단화 (Aggregation)
집단화란 데이타 모델링의 추상적 개념에 하나로 몇 개의 구성 객체를 하나의 복합 개체 집합으로 추상화(abstraction)하는 방법이다. 집단화에는 한 객체의 여러 속성들을 집단화해서 하나의 개체로 만드는 경우와 객체와 객체간의 관계 집합 자체를 하나의 복합 개체로 만들어 일반 객체 집합으로 만드는 경우가 있다. 그러나 보통은 첫 번째 경우보다 두 번째 경우와 같이 관계 집합의 관계를 추상화하는데 그 의미가 크다[6]
먼저 집단화된 객체 내에 포함된 관계성으로부터 집단화된 클래스 G를 생성한다. 다음은 관련된 두 개의 객체를 클래스 G내에 참조 애트리뷰트로 추가하고 관계성에 키가 아닌 애트리뷰트가 있을 경우(즉, 관계 자신의 애트리뷰트), 이를 클래스 G에 단순 애트리뷰트로 추가한다. 관련된 두 객체에 대한 관련성의 카디널리티를 근거로 이진 관계(binary relationship)규칙을 적용하여 집단화를 구성하는 두 객체에 타입이 G인 참조 애트리뷰트 또는 참조 집합 애트리뷰트를 추가한다.
생성된 모델 내에서 발생할 수 있는 상속성 충돌을 방지하기 위해 모델내에 일반화 계층 구조가 있는지 확인하여 다음의 규칙을 추가 적용한다[2]. 하나의 상위 클래스를 가지고 있을 경우는 상위 클래스에 있는 애트리뷰트 명칭이 하위 클래스의 애트리뷰트 명칭과 동일한 경우에는 서로 식별될 수 있도록 어느 한 쪽의 애트리뷰트 명칭을 수정한다. 다수의 상위 클래스를 가지고 있을 경우는 먼저 동일한 애트리뷰트 명칭을 가진 상위 클래스의 수가 1개인 경우에는 위의 규칙 가와 동일한 방법을 적용한다. 동일한 애트리뷰트 명칭을 가진 상위 클래스의 수가 2개 이상인 경우에는 규칙 가와 유사한 방법을 적용하여 모두 식별될 수 있는 애트리뷰트 명칭을 갖도록 애트리뷰트의 명칭들을 조정하거나, 상속받고자 하는 상위 클래스의 명칭을 명시적으로 애트리뷰트 명칭에 포함시켜 기술한다.
4.3 제약 조건 (constraint)
만약 시스템이 제약 조건을 단정적으로 기술하는 기능을 가지고 있지 않다면 그 조건을 메소드로 구현해 주어야 한다[5].
(1) 객체 타입에서의 제약 조건
가능하다면 객체 타입의 키로부터 사상되는 애트리뷰트에 unique나 no_null과 같은 키워드를 기술한다. 객체의 계층 구조상에 overlapping이나 disjoint 등의 제약 조건을 쉽게 구현할 수 있는 방법은 없다. 보통의 경우, 계층 구조상에서 객체의 생성은 계층적 순서에 의해 이루어져야 한다.
(2) 관계 타입에서의 제약 조건
관계 타입 상에 카디널리티 제약 조건은 객체를 구성하거나 소멸하는 메소드에서 구현되거나 객체 참조 집합으로부터 멤버를 삽입 또는 삭제하는 메소드를 통해 구현된다. 관계 타입에 존재하는 종속적 제약 조건도 구성자 객체나 소멸자 객체의 메소드로 실현된다.
가령, DEPARTMENT 와 EMPLOYEE 객체 사이에서의 제약 조건 중 employee의 수가 최소 2 이상 최대 30 이하라는 조건은 DEPARTMENT 객체의 구성자(construct)상에 다음처럼 기술할 수 있다.
Department (set <Employee> emps) {
if (cardinality(emps) < 2 or cardinality(emps) > 30) {
error("Constraint violation");
exit;
}
}
이상의 모든 변환 규칙을 적용해 생성한 클래스는 다음과 같다.
class Employee{
string ssn no_null unique;
Name nm; // 복합 애트리뷰트의 클래스 이름
integer salary;
Department work_for; // 1 : N 관계상에 참조 애트리뷰트
set <Raise> rs; // M : N 관계상에 링크 클래스 참조 집합 애트리뷰트
};
class Name { // 복합 애트리뷰트 클래스
string firstname;
string midinit;
string lastname;
};
class Manager : { // Employee의 하위 클래스
Department manager;
};
class Department {
string name no_null unique;
set <string> locations; // 다중값 애트리뷰트
set <Employee> hire; // 1 : N 관계상에 참조 집합 애트리뷰트
Manager manager_by; // 1 : 1 관계상에 참조 애트리뷰트
set <Project> control; // 종속 객체에 대한 참조 집합 애트리뷰트
};
class Project{
string name no_null unique;
string startdate;
Department controlled_by; // 소유 객체에 대한 참조 애트리뷰트
set<Work_on> wk; // M : N 관계상에 링크 클래스 참조 집합 애트
}; 리뷰트
class Child {
string name ;
string birthdate;
set<Raise> rs; }; // M : N 관계상에 링크 클래스 참조 집합 애트리뷰트
class SalesRep : Employee {
set <string> regions; // 다중값 애트리뷰트
};
class Engineer : Employee {
set <string> specialities; // 다중값 애트리뷰트
set <Work_on> wk; // M : N 관계상에 링크 클래스 참조 집합 애트
}; 리뷰트
class SalesEngineer : SalesRep.Engineer {
}; // 다중 상속 객체
class Work_on { // 링크 클래스
Project proj; // M : N 관계상에 참조 애트리뷰트
Engineer engr; // M : N 관계상에 참조 애트리뷰트
integer hours; // M : N 관계상에 링크 클래스의 애트리뷰트
};
4.4 메소드(Method)
ER 다이어그램에서 식별되는 제약 조건들은 메소드로 구현되어 해당 클래스에 첨부된다. 이 외에 각 기본 객체(클래스)에서 수행되는 삽입, 삭제, 수정 등에 관한 동작도 객체 정의가 확실히 되어 있다면 별도의 분석 없이 최소한의 연산 내용을 식별해 낼 수 있다. 그러나 ER 다이어그램에 나타나지 않거나 기본 연산이 아닌 경우의 연산들은 부수적인 다른 자료나 방법을 통해 식별해 내야 한다. 본 절에서는 자료 흐름도(Data Flow Diagram)를 통한 연산의 식별 및 클래스 할당에 관한 연구를 언급한다[2].
각 클래스가 제공해야 할 연산은 직접 자료 저장소와 자료를 입출력하는 처리 과정을 분석하여 식별할 수 있다. 자료 흐름도에서의 이러한 처리는 연결된 클래스(자료 저장소)에 대해 필수적으로 행해지는 임의의 연산이기 때문에 메소드로 정의가 가능하다. 자료 흐름도를 이용한 방법에서는 최하위 수준의 자료 흐름도에서 자료 저장소와 직접 연결된 처리를 분석하여 연산을 식별한다. 최하위 수준의 자료 흐름도를 사용하는 이유는 여기에 모든 자료 저장소가 표현될 뿐만 아니라, 최하위 단계이므로 각 처리가 단위적으로 수행되어 쉽게 연산으로 사상되기 때문이다. 클래스에 대한 연산을 식별하기 위한 규칙은 다음과 같다.
최하위 수준의 자료 흐름도에서 자료 저장소와 직접 연결된 처리와 이 처리에 관한 소단위 명세서를 이용해서 처리와 연결된 클래스가 제공해야 할 연산을 식별한다.
식별된 연산을 수행해야 할 주 클래스와 이를 지원할 보조 클래스를 구분한다. 처리와 관련된 클래스가 다수인 경우는 단위 명세서나 자료 사전을 이용하여 가장 주된 역할을 수행하거나 또는 처리에 필요한 자료를 가장 많이 포함하고 있는 클래스를 주 클래스로 분류하고, 다른 클래스는 보조 클래스로 구분한다. 보조 클래스가 있다는 것은 연산의 수행을 위해 주 클래스와 보조 클래스 사이에 인터페이스 즉, 메시지 전송이 있다는 것을 의미한다.
식별된 연산에 대해서 주 클래스와 관련된 입출력 자료를 정의한다. 입출력 자료가 될 수 있는 후보 자료는 기본적으로 자료 흐름도에서 처리로 입력되는 자료 흐름 및 처리로부터 출력되는 자료 흐름을 이용하여 식별할 수 있다. 그러나 자료 흐름도에는 처리의 순서가 표현되지 않으므로 최초 입력 및 최종 출력뿐만 아니라 중간 산출물 성격의 입출력 자료도 함께 표현해야 한다. 중간 산출물 성격의 자료는 주로 자료 흐름도에서 처리와 자료 저장소 사이의 자료 흐름이므로 이것을 제외한 부분 즉, 외부나 다른 처리로부터 받은 자료 흐름 및 외부나 다른 처리로 출력되는 자료 흐름이 주 클래스의 입출력 자료가 된다.
파악된 자료를 이용하여 연산 요구표를 작성한다. 위에서 식별된 보조 클래스에 대한 연산을 자료 흐름도, 소단위 명세서를 이용하여 연산 요구표에 추가한다. 연산 요구표는 {연산명, 주 클래스, 보조 클래스, 입력 자료, 출력 자료}등으로 구성된다.
연산 요구표에서 동일한 클래스에 대한 연산의 중복성을 제거하고 보다 일반적인 연산을 생성하기 위해 필요한 연산을 통합한다. 정리된 연산을 연산 할당표를 이용해 각 클래스에 할당한다. 연산 할당표는 {클래스, 연산명, 입력 자료, 출력 자료}등으로 구성된다.
연산 요구표에 기술된 연산중에서 소단위 명세서를 분석하여 연산의 기능을 분할한다. 여기에서 하위 기능을 식별할 수 있는 경우 하위 기능 요구표를 작성하고 동일한 기능은 삭제한다. 더 일반적인 연산이 필요할 경우에는 하위 기능들을 통합하여 강력한 하위 기능을 생성한다.
5. 결론
본 논문은 기존에 만들어진 관계형 데이타를 객체지향 데이타로 변환하는 방법에 관한 논문이다. 객체지향 모델링은 의미 객체 모델링을 이용하였고 이를 위해 필요한 의미 자료 모델링은 관계형 데이타베이스 시스템에서 사용하던 EER 다이어그램을 사용하였다. 변환 규칙은 객체(entity)와 관계(relationship)에 대하여 주로 이루어졌고 EER 다이어그램에서 표현되지 않는 제약 조건은 메소드(프로시져, 연산)를 통해 변환된 클래스에 첨가된다.
그 외에 클래스 객체가 가져야 할 연산은 부수적인 방법을 통해 분석되는데 조사된 논문에서는 자료 흐름도와 모듈의 소단위 명세서를 통한 분석 방법이 소개되었다. 이 방법은 최하위 수준의 자료 흐름도에서 자료 저장소와 그에 관련된 입출력 자료를 추출하여 기본 연산을 정의한다. 상용화되는 객체지향 데이타베이스 시스템은 타 데이타베이스 시스템(관계형 데이타베이스)과의 투명한 자료 교환을 위해 관계형 자료를 객체지향형 자료로 변환시키는 서비스를 제공하고 있다. 객체지향형 데이타베이스 시스템과 관계형 데이타베이스 시스템 사이에서 자료를 교환하는 방법은 기본적으로 다음과 같다.
관계형 자료를 객체지향형 자료로 변환하기 위해서는 자료의 의미적 분석을 통한 객체 선정이 필요하고 객체에 대한 연산이 정의되어야 한다. 객체지향형 자료가 관계형 자료로 변환될 때는 개체의 기본적인 애트리뷰트들만이 테이블로 저장되고 그 외에 처리에 필요한 연산이나 조건들은 자료 처리 저장소에 보관되어 보조적으로 운영된다. 앞서 제시된 규칙들은 이를 지원하는 자동화 도구의 개발 및 설계에 관한 연구와 함께 객체지향 데이타베이스 시스템의 클래스로 확장하기 위한 데이타베이스 시스템 측면의 연구가 병행되어야 한다.
참고 문헌
[1] C. J. Date, " An Introduction to Database Systems", 2nd Ed., Addison Wesley Pub., pp 181- 240, 1986.
[2] 박영우, 진철, 임영수, "자료 흐름도 및 ERD를 이용한 객체 지향 모델로의 변환방법에 관한 연구", 학술 발표 논문집 21권 1호, pp. 669-672, 1994.
[3] 김원, "객체 지향 데이타베이스 기술", 정보과학회지 제 11권 제2호, pp 42-58, 1993.
[4] 이경환, "객체 모델링", 정보과학회지 제 11권 제2호, pp 22-31, 1993.
[5] Byung S. Lee, "OODB with EER",
http://www.sigs.com/publications/docs/joop/9602/joop9602.f.lee.html.
[6] 이석호, "데이타베이스 시스템", 정익사, pp 65-81, 1995.
[7] "ObjectStore (Technical Overview)", LG 소프트웨어
최 은 만
1982년 동국대학교 전자계산학과(학사)
1985년 한국과학기술원 전산학과(석사)
1993년 일리노이 공대 전산학과(박사)
1985∼88년 한국표준연구소 연구원
1988∼89년 한국데이타통신(주) 주임연구원
1993∼현재 동국대학교 컴퓨터공학과 조교수
관심분야: 소프트웨어 유지보수, 역공학, 재사용,
객체지향 소프트웨어 공학
엄 기 현
1975년 서울대학교 응용수학과 졸업
1977년 한국과학기술원 전산학과 졸업
1977-1978 금성통신(주) 연구소
1978-1989 서울대학교 계산통계학과 강사
1994년 서울대학교 대학원 컴퓨터공학과 박사
1978-현재 동국대학교 컴퓨터공학과 교수
관심분야: 데이타베이스 응용, 멀티미디어 데이타베이스,
하이퍼미디어 데이타베이스, 데이타베이스 무결성
원본출처 : http://se.dongguk.ac.kr/menu_data/dbre.htm
|
