database.sarang.net
UserID
Passwd
Database
ㆍDBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
DBMS Columns 208 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 208
객체관계형데이타베이스 모델링
작성자
정재익(advance)
작성일
2001-12-25 19:39
조회수
7,059

객체관계형데이타베이스 모델링

 

1998, 5

DBMS / USA

 

---------------------------------------------------------------

 

객체관계형 데이타베이스 관리시스템 (ORDBMS)은 관계형 시스템에 새로운 객체 저장 능력을 추가하고 있다. 이러한 새로운 개념은 전통적인 필드 데이타 관리, 시계열 데이타, 지리공간 데이타와 같은 복잡한 객체 , 그리고 오디오, 이미지 , 애플릿 등 다양한 바이너리 미디어들을 통합한다.

ORDMBS 서버는 이러한 데이타 구조와 캡슐화된 방법론에 의해 멀티미디어 및 다른 복잡한 객체들을 찾거나 변형하기 위한 복잡한 분석과 데이타 처리등을 실행할 수 있다.

혁신적인 객체관계형 기술 접근은 아버지격이라고 할 수 있는 관계형의 강력한 트랜잭션 및 성능 관리와 사촌격인 객체지향형의 유연성을 물려받은 것이다. 데이타베이스 설계자들은 새로운 객체 관리 가능성을 구현하면서 이제까지 친숙하였던 테이블 구조와 데이타 정의 언어 (DDL)들을 통해 작업을 수행할 수 있다. 질의 및 절차적 (Procedural) 언어 , ORDBMS내의 call interface는 이미 친숙한 형태이다. 업계 표준 프로시저 언어 SQL-3와 ODBC, JDBC , 전용 call interface 등은 모두 RDBMS 언어와 인터페이스로부터 확장된 것이다. 이 분야의 선도적인 업체로는 잘 알려져 있다시피 IBM , 오라클, 인포믹스 등을 꼽을 수 있다.

하지만 데이타베이스 설계 툴에 있어서는 어떠한가? 설계자들이 데이타 구조에 치중하기보다는 데이타베이스 객체 구축을 돕기 위해 적절히 확장되었거나 재설계 되었는가? 익스텐더, 데이타블레이드,카트리지 등의 써드파티 혹은 벤더 객체 모듈을 사용할 뿐만 아니라 , 벤더 사용자 정의 타입, 기능, 오퍼레이터, 복잡한 객체, 상속성 등 새로운 특징들을 모델링할 수 있는가? 방법론이 사용자의 의사 결정을 도와주는가? 물리적 스키미 -제너레이션 능력이 훌륭한 DDL 스크립트를 만들어 낼 수 있는가? SQL-3를 지원하며 , IBM DB2 유니버설 데이타베이스 , 인포믹스 다이나믹 서버( 유니버설 데이타 옵션 ), 오라클 8 시스템 카탈로그의 뉘앙스를 이해할 수 있는가?

ORDBMS 프로젝트를 추진하기에 앞서 현존하는 관계형 데이타베이스와 애플리케이션을 변형해야하는 것인지, 아니면 새로운 것을 개발해야 하는 것인지, 그리고 가용한 툴의 수용능력과 방법론적인 접근에 대해 이해하는 것은 필수 적이다. 본지에서는 모델링 툴에 새로운 능력이 요구되는 객체관계형 특징들을 살펴보고, 대표적인 모델링 문제를 진단함으로써 모델링 방법론을 조사 할 것이다. 또 대표적인 툴들에 대해 점검하고 , 향후 모델링과 툴의 방향에 대해 분석해본다. 이를 위해 DBMS에 독립적이고 객체관계형 모델링 능력을 가지고 있는 3가지 툴을 소개할 것이다. 로직웍스의 OR-컴파스, 인포모델러의 인포모델러3.1 ( 지난 1월에 비지오가 인포모델러 인수의사를 밝힌 바 있다.) , 실버런테크 놀러지의 유니버설 모델러 1.0 등이 그것이다. 이외에도 ORDBMS를 지원하는 모델링 툴로 플라티늄테크놀러지의 패러다임플러스 등을 들 수 있다.

 

객체관계형의 특징

 

객체관계형 데이타베이스는 친숙한 관계형 테이블 구조로 정보를 체계화 한다. 사실, 객체관계형 구현은 관계형 데이타베이스 모델을 포함하는것이다. ORDBMS는 RDBMS 프로세서의 향상된 업그레이드로 볼 수 있으며 , 객체 데이타베이스 시스템과 달리 객체관계형으로의 이행은 대규모 리코딩을 수반하지 않는다. C++ 컴파일러가 클래스 부족에도 불구하고 C코드를 다루는 것과 마찬가지로 , 일단 사용자가 SQL-92에서 SQL-3로 문장구성법 (Syntactic )의 변화를 추구하게 되면 ORDBMS는 동일한 벤더의 관계형 스키마를 지원한다. 현재 ORDBMS구현에 있어 인포믹스 유니버설 데이타 옵션은 리플리케이션이 미흡하고 , 오라클 8의 경우에는 상속성 지원이 약하다는 등 어느 정도의 차이점을 갖고 있다. 따라서 보다 세부적인 구현에 대해서는 좀더 기다려 보아야 한다.

새로운 객체관계형 특징에 있어 가장 중요한 점은 사용자 정의 타입 (UDT ), 사용자 정의 함수 (UDF ), 그리고 이들을 지원하는 인프라스트럭처 (인덱싱/액세스 방법론과 옵티마이저 향상 등)이다.

사용자 정의 타입은 명확성 (Distinct), 기반이 되는 사항의 불투명성 (Opaque), 연속적인 로우 ( Composite ) 등의 특징을 가지고 있다. 밸류 타입으로 알려진 Distinct 타입은 다른 타입으로부터 파생되지만 그들 자체의 도메인, 오퍼레이션, 함수, 캐스트 (Cast ) 등을 갖추고 있다. ORDBMS 애플리케이션은 애플리 케이션 통합을 통해 강력하게 타입화될 수 있다. 시스템 정의 타입은 매우 친숙하다. 대부분의 RDBMS는 정의된 십진수와 함께 돈을 숫자 타입으로 실행한다. 돈의 가치를 빼거나 더하는 것은 다른 돈의 가치에 의해서가 아니라 수량에 의해 논리적으로 나타난다. 만약 방법론이 이러한 타입을 필요로 한다면 돈의 타입은 실제적인 스트링 (string) 타입에 캐스트하며, 증가하는 이익 성장률과 같은 기능들을 가질 수 있다.

Opaque 타입은 소스 타입으로부터 나온 것이 아니다. 따라서 내부 구조는 이들의 오퍼레이션, 함수, 캐스트와 함께 DBMS에 정의돼야 한다. 일단 적절히 정의되면 Opaque 타입은 Distinct나 Row 타입을 정의하는 소스 타입으로 사용 될 수 있으며 , 테이블내에서 사용된다.

Row타입은 다른 타입의 필드를 취합해 놓은 것이다. 하나의 Row타입은 필드중에 자리잡은 또 다른 Row 타입을 포함할 수 있다. 구성 필드를 다루는 것은 그들의 타입으로부터 도출된다. 따라서 Row타입의 오퍼레이션, 함수 , 캐스트등은 반드시 정의돼야 한다. 컬렉션 타입 (일련의 빌트-인된 가치의 리스트나 세트, 또는 사용자 정의 타입 )은 객체관계형의 또 하나의 혁신적인 사항이다. 사용자는 그룹 반복에 대해 불평을 가짐으로써 단일 아키텍쳐를 사용하고자 하는 이들의 요구에도 불구하고 관계형 데이타베이스를 시뮬레이트하는 것이 가능하다. 카트리지, 데이타블레이드, 익스텐더등은 DBMS의 객체관계형 인프라스트럭처상에 구축된 모듈들이다. 이들은 타입, 데이타 두조, 기능 , 데이타 등으로 구성되며 , 종종 특별한 개발자 인터페이스를 포함하거나 애프리케이셔늘 사전에 구축할 수 있다.

 

기존 방식과의 차이점 인식

 

최근 들어 ORDBMS는 지리공간, 재무 타임 시리즈 데이타 등의 복잡한 데이타와 미디어 객체를 관리하는데 있어 최대의 성공을 거두고 있다. ORDBMS는 종종 웹 애플리케이션이나 특화된 데이타웨어하우스에 사용되고 있다 (이같은 판단은 CA-잉그레스의 오브젝트 매니지먼트 모듈 , 포스트그레스 , 일러스트라 , 인포믹스 다이나믹 서버의 이전 제품, 오라클 관계형 및 OLAP 데이타베이스 등에 의해 90년대초부터 시작된 필자의 경험에 기반을 두고 있다).

진보된 웹 애플리케이션은 미디어, 전통적인 필드 데이타, 다이나믹 페이지를 생성하는 템플릿 등에 대한 통합관리 기능을 제공하는 ORDBMS가 적용될 수 있는 최적의 환경이라고 할 수 있다.

미디어 객체는 오디오, 비디오, 이미지, 포맷되거나 포맷되지 않은 텍스트를 포함한다. 데이타 구조 자체는 그다지 흥미로운 것이 아니다. ORDBMS는 BLOBs ( Binary Large Objects )를 차별화시키지 않는 액세스 방법론을 정의하고 있다.

흥미로운 점은 저장된 데이타를 인덱스화 하고, 검색및 처리하는 서버 기능을 만들어 내는 새로운 가능성에 있다. 예를 들어 인포믹스 웹 데이타블레이드는 미디어와 같은 애플리케이션(템플릿) 페이지를 위한 데이타 구조 뿐만 아니라 SQL 질의, 가변성, HTML내에 내포된 프로시저 태그 등을 처리하는 기능까지 포함하고 있다(SQL질의는 웹 데이타블레이드와 관련없는 다른 서버 함수들을 불러낼 수 있다). 애플리케이션 페이지들은 HTML로 불리는 Opaque 타입인 UDT로 저장되며, 이는 관리와 프로세싱을 위해 정의된 방법론을 갖고 있다. 이 흥미로운 방법론의 소스 타입은 텍스트이다.

시간값에 의해 인덱스화된 가치의 순서 배열인 타임시리즈는 복잡한 데이타 타입의 대표적인 예이다. 모든 주요 객체관계형 DBMS들은 한개 이상의 타임 시리즈 카트리지, 데이타블레이드 혹은 익스텐더들을 보유하고 있거나 보유할 예정이다.

사용자는 처음부터 자신의 타임시리즈구조와 방법론을 구축할 수 있다. 타임시리즈 타입은 소스가 무엇인지에 상관없이 이름과 하나 또는 그이상의 날짜가 인덱스되어 있는 가치 벡터들을 추가한 그밖의 디스크립티브 필드를 갖고 있다. 시리즈 확인과 날짜의 리던던트 스토리지는 제거된다.

시리즈 밸류는 더이상 확장되지 않은 SQL을 통해 접속할 수 없다. 따라서 사용자는 밸류와 전체 시리즈들을 추출해내고 확대하기 위해 일반적인 함수와 오퍼레이터가 필요하다. SERIESNAME과 DATE패러미터를 가진 GETVALUE 함수를 그 예로 들 수 있다. 시리즈 추가와 2개 시리즈의 밸류 합계를 포인트와이즈(Pointwise)하는 2가지 경우를 처리하기 위해 PLUS 오퍼레이터는 과부하가 발생한다.

이러한 예의 핵심은 객체관계형 모델이 데이타와 프로세스 모두를 포함한다는 것이다. 다시 말해 사용자가 가진 정보 자체와 그 정보를 가지고 무엇을 할 것인가하는 방법 모두를 가리킨다. 이와 반대로 관계형 데이타베이스들은 오퍼레이션과 프로세스의 제한된 캡술화만을 지원한다.

디자인 방법론과 툴은 데이타와 오퍼레이션 모두를 모델링해야 하며, 전통적인 데이타베이스와 객체지향 애플리케이션 모두를 커버하는 접근 요구를 수용해야 한다.

그리고 이와 동시에 디자이너들로 하여금 함수를 데이타와 함께 캡술화하거나 데이타베이스 외부에 클래스 혹은 코드 구조를 생성 할 수 있도록 해야 한다. 결국 툴은 빌트-인 타입이나 방법론과 함께 작업하고 , 사용자 정의 타입 , 함수 , 카트리지 , 데이타블레이드, 익스텐더 모듈과 함께 모델을 확장시켜 나갈 수 있는 능력을 제공해야 한다.

 

방법론

 

데이타베이스 및 애플리케이션 코드를 직접 프로그래밍하지 않고 디자인 및 모델링 툴을 사용해 모델을 만들어내는데에는 여러가지 이유가 있다. 모델링은 비지니스 컨셉 ( 개념적 모델 ), 데이타베이스 디자인 (논리적인 모델), 물리적인 데이타베이스 구현 (물리적인 모델 혹은 스키마 )간의 격차를 줄일 수 있다.

디자인 툴로 만들어진 논리적인 모델은 각기 다른 DBMS에서 단일 디자인으로 구현되면서 DBMS 스펙으로 종속된다. 논리적인 모델과 달리 스키마는 특정한 DBMS 서버 제품과 긴밀한 관련을 갖는다.

수년동안 모델링 튤은 리버스 엔지니어링 ( 현존하는 데이타베이스로부터 논리적인 모델을 도출시키는 ) 기능과 포워드 엔지니어링 ( 논리적인 모델로부터 데이타베이스 스키마를 생성하는 ) 기능을 모두 확보해 왔다.

 

관계형 및 객체관계형 모델링

 

엔티티 관계도 (ER: Entity Relationship)는 전통적인 관계형 모델링 접근방법이다. 인포메이션 엔지니어링 (IE)과 IDEFIX는 방법론과 표시방법 ( Notational )에 있어 차이를 가지고 있다. ORDBMS가 관계형을 기반으로 하고 있음에도 불구하고 , 이러한 3가지 접근방법은 객체관계형 데이타베이스 모델링에 적용되어 왔다. 그러나 이들은 모델링에 있어 개념적으로 심각한 약점을 가지고 있으며 , 프로세스를 포착하는 능력이 없기 때문에 난관을 겪고 있다.

예를 들어 IE는 일반화되지 않은 형식을 가지고 있어 모델링되는 비지니스 객체를 묘사하는 데에 어려움이 따른다. IE가 구매자, 프로덕트, 쇼핑 바스켓 엔티티들을 일반화하는 것을 선호하느 단일 개념 엔티티인 오더 ( Oder )를 단적인 예로 들 수 있다.

 

객체 롤 모델링

 

전통적인 RDBMS 모델링 방법론은 전형적인 레벨을 소홀히 다룬다. 객체 롤 모델링 (ORM)은 이러한 규칙을 따르고 있는 방법론이다. ORM개념이 선보인 것은 수년전이지만, 테리 홀핀스의 인포모델러 디자인 툴내에서 구현 작업을 통해 최근 들어서야 주목받기 시작하고 있다.

FORML(Formal Objet Role Modeling Language)는 비지니스 개념을 위한 조직적이고 엄격한 접근을 통해 ORM을 캡슐화한다. FORML개념적인 모델러는 데이타를 언어로 나타내며 , 문장 (Statement)을 구체적으로 설명하는 팩트를 통해 개념적인 모델을 문장 형태내에서 상징화 혹은 다이어그램화 하거나 또는 모델을 유효화한다.

 

UML

 

새로운 데이타베이스 모델링 대안으로 제시되고 있는 것이 오브젝트 매니지먼트 그룹의 UML(Unified Modeling Laguage )이다.

UML 개발은 엔터프라이즈 컴포넌트 모델링 (ECM)으로 불리는 소프트웨어 객체를 위한 단일화된 모델에 기반을 둔 래쇼날소프트웨어에 의해 주도되고 있다. ECM은 클래식, 컴포넌트, 그리고 분산된 시스템과 상세한 디자인 형태를 맵핑하고 , 개념적인 모델링을 커버하는 개념화 및 요구 분석을 포함하는 복잡한 접근방법이다. 그러나 UML의 클래스와 방법론은 ORDBMS타입 및 방법론에 상응한다.

 

ORDBMS 모델링 툴

 

지금부터는 실질적으로 로직웍스의 OR-컴파스, 인포모델러의 인포모델러, 실버런테크놀러지의 유니버설 모델러 등 3가지 객체관계형 데이타베이스 모델링 툴을 살펴보고자 한다.

여기에 서술된 내용은 논리적인 모델 및 스키마 지원을 포함한 객체관계형 모델링에 초점을 맞추고 있다. 필자는 윈도우 NT 4.0상에서 이들 툴을 사용했으며 , SGI/아이릭스 6.2상에서 운영되는 인포믹스 유니버설 서버 버전 9.12.UC에 액세스했다.

각 툴은 사용자에게 테이블과 다른 데이타베이스 객체의 물리적인 데이타베이스의 스페이스, 록킹 모드 등 특정 물리적인 데이타베이스 프로퍼티를 구체화하도록 했다. 이들은 또한 데이타베이스에 직접 물리적인 스키마를 생성했다 ( 예외적으로 인포모델러에서는 데이타 정의 언어 ( DDL ) 파일에 생성했다).

 

OR-컴파스

 

로직웍스의 ER윈/ERX제품군은 IDEFIX 및 IE 표시법을 통한 ER모델링을 수행한다. 또한 모든 주요 RDBMS에 포워드 및 리버스 엔지니어링을 지원하며 , 논리적인 모델 및 물리적인 스키마의 통합이 가능하다.

모델마트로 불리는 웍그룹 기반의 모델 관리 시스템을 제공하고, ER윈/OPEN을 통해 파워빌더, 비주얼베이직 등의 애플리케이션 개발 툴과 연동된다. 여기에 덧붙여 로직웍스는 객체 모델링 툴인 래쇼날 로즈와 메타데이타 교환을 위한 툴을 제공한다.

OR-컴파스는 ER윈/ERX를 단순히 확장한 제품이 아니라 전혀 새로운 신제품으로 사용자는 ERX 모델을 직접 불러올 수 있다. 필자는 OR-컴파스의 1.0베타버전을 가지고 인포믹스와 함께 작업했다. 로직웍스는 1998년초에 오라클 8, IBM DB2유니버설 데이타베이스, 사이베이스 어댑티브 서버 등을 추기 지원할 계획이다. OR-컴파스는 IDEFIX 표시법과 함께 엔티티 관계도 모델링 방법론을 사용한다.

OR-컴파스는 객체관계형 특징을 모델링 하는데 도움을 주는 RTW ( Row Time Wizard )와 FIW (Functional Index Wizard )라는 2개의 위저드를 포함하고 있다. RTW는 관계형 데이타베이스에서 객체관계형 데이타베이스로 마이그레이션하고자 하는 디자이너들을 위한 기능이다.

사용자들은 이를 이용해 선택된 칼럼을 테이블에서 Row티입으로 변화시킬 수 있다. 물론 처음부터 Row 타입을 만들지는 않는다. FIW는 계산된 필드의 밸류에 기반해 테이블 인덱스를 세분화 함으로써 사용자에게 큰 효용성을 제공한다.

모델블레이드 역시 매우 유용하다. 이들은 인포믹스 데이타블레이드 객체를 위한 정의와 도큐멘테이션으로 이루어져 있으며, 데이타블레이드 파일이나 DDL스크립트로부터 임포트된다. 임포트된 모델블레이드 객체는 패키지 익스플로러 프레임에 디스플레이되며 , 이들은 사용자가 만든 모델내에 포함된다.

OR-컴파스는 사용자가 관계 ( Relationship )를 만들 때 ( 테이블명에서 오른쪽 버튼을 클릭해 Insert / Outgoing Relationship 을 선택하거나 Relationship 아이콘 중 하나를 사용함으로써 ) 자동적으로 핵심적인 마이그레이션을 지원한다. 사용자는 다이어그램에서 한개의 테이블로부터 다른 테이블로 칼럼을 드래그앤드롭할 수 있는데, 모델 익스플로러에서는 이러한 작업이 불가능하다.

Row 타입이 다이어그램에 디스플레이되지 않기 때문에 사용자는 하나의 타입에서 또 다른 타입으로 필드를 드래그앤드롭할 수 없는 것이다. 팔레트 ( 툴바 )나 또는 모델 익스플로러를 통해 더욱 사용하기 쉬운 드래그앤드롭 다이어그래밍 인터페이스 작성이 가능하다.

 

인포모델러

 

인포모델러 버전 3.1은 인포믹스와 연결, ORDBMS를 지원하는 최초의 모델링 툴이다. 인포모델러가 지난 1997년 8월 출시한 버전 3.1은 IBM DB2 유니버설 데이타베이스용 스키마 생성 기능을 포함하고 있다. 인포모델러는 FORML 개념적인 모델링 툴로 ER과 IDEFIX 관계형 논리 모델을 지원하는 특징을 가지고 있다.

하지만, 한편으로는 심각한 약점을 가지고 있는데 , 인포모델러가 빌트-인된 타입 컬렉션이 상당히 작다는 것이다. 모든 객체형 타입과 함수에 액세스하기 위해서는 사용자가 ORDBMS에 직접이건 혹은 카트리지나 데이타블레이드, 익스텐더 등과 같은 익스텐션의 일부를 이용하든간에 오프라인 작업을 중단시키는 라이브 데이타베이스 연결이 필요하다.

라이브 데이타베이스 연결은 포워드 및 리버스 엔지니어 데이타베이스를 필요로한다. 다시 말해 사용자는 DDL ㅡ크립트와 함께 작업할 수 없다. 이러한 한계점들이 모빌이나 원격지 개발자에게 문제를 일으킨다는 점은 의심할 여지가 없다. 필자는 컨설턴크로서 사무실에서 멀리 떨어진 클라이언트 사이트에서 작업하는 경우가 많고 , 이러한 업체들은 외부 개발자들이 그들의 데이타베이스 시스템에 접속하는 것을 금지하고 있다.

인포모델러는 아직 모델 서버 함수가 없다. 따라서 서버 함수들은 사용자 정의 타입과 함께 객체관계형에서 객체를 만드는 것이다. 만약 사용자가 라이브 데이타베이스 연결을 할 수 있다면 데이타베이스내에서 이미 정의된 함수들을 디스플레이 할 것이다.

이미 함수가 존재하고 있다면 그 함수들을 사용할 수 는 있다. 하지만 그러한 함수는 사용자가 직접 만들어야 한다. 그런데 인포모델러를 활용해서는 함수를 생성할 수 없으며 , 적절한 서버 기능은 차기 버전에서 지원될 예정이다.

 

유니버설 모델러

 

실버런의 유니버설 모델러는 비지니스 프로세스 모델링을 위한 BPM, 개념적인 관계형 모델링을 위한 ERX ( Entity Relationship Expert ), 물리적인 관계형 데이타 모델링을 위한 RDM등을 포함한 상호운영 가능한 툴 스위트이다. 이 툴들은 각종 RDBMS와 델파이 및 파워빌더 등의 개발 툴과 연동된다. 모델링팀은 실버런 모델 매니지먼트 센터를 모델 리포지토리로 사용할 수 있다.

필자가 유니버설 모델러 1.0을 테스트 했을 때에 그 제품은 인포믹스만을 지원했다. 실버런은 조만간 DB2 유니버설 데이타베이스를 지원할 계획이며, RDM 툴의 차기 버전에서는 오라클 8을 지원하는 한편 ,이를 유니버설 모델러의 객체 툴 컴포넌트에 연결할 것이라고 밝혔다.

유니버설 모델러는 IE, 실버런 ( IE 버전 ), UML 등 3가지 모델링 표시법을 지원한다. 사용자는 모델 익스플로러내의 모듈 타입을 선택함으로써 사용자 정의 타입을 만들 수 있다.

또한 익스플로러 모듈 타입에서 모델러의 Find에 마우스를 위치시키고 , 오른쪽을 클릭함으로써 타입을 비주얼하게 모델링할 수 있다.

이 제품은 사용자가 인포믹스 SPL(Stored Procedure Language ), 외부 루틴 등을 모델링 할수 있도록 해준다. SPL 위저드나 유용한 신탯스 가이드 타입을 확보하는 것은 도움이 될 것이다.

유니버설 모델러는 인포믹스 데이타블레이드에 대한 정보를 불러 올 수 있도록 해준다 ( 이러한 정보를 "실버블레이드 " 라고 한다 ) . 사용자는 모델에서 실버블레이드 객체를 사용할 수 있다. 그러나 유니버설 모델러는 서버 함수를 구체화하는 능력에 있어 부정 소자 ( Nagator )와 정류전환기 ( Commutator )함수, 또는 옵티마이저 비용을 구체화하지 못한다는 제약점을 갖고 있다. 필자는 테이블 칼럼상에서 인덱스를 만들기 위해 익스플로러내의 테이블 네임에서 오른쪽 버튼을 클릭하고 (필자는 모델러에서 인덱스를 만드는 방법을 찾지 못했다 ). 인덱스상에서 필드를 드래그앤드롭했다.

 

기타 모델링 툴

 

그 밖의 모델링 툴을 주시해 보는 것도 의미있는 일이다. 객체관계형 모델링으로 향상되지 못한 데이타베이스 디자인 툴들은 사용자 정의타입, 함수, 기타 객체관계형 특징들을 추가 지원해야 한다.

사이베이스는 현제 공급중인 파워디자이너 6.1이 올해 중반경 완벽한 객체 및 UML 모델링, 추상적인 데이타 타입을 추가적으로 지원할 것이라고 발표했다. C++클래스와 확장된 객체 데이타베이스 스키마 생성을 위한 UML 제품인 오라클의 오브젝트 데이타베이스 디자이너와 객체관계형 모델링 기능을 추가한 오라클 디자이너 / 2000 2.0이 최근 발표됐다. 팝킨 소프트웨어 & 시스템즈는 SA/오브젝트 아키텍처에 UML 객체 모델링 기능을 추가한 객체관계형 모델링 툴을 개발했다.

ECM 툴은 클래스와 방법론을 그들의 객체관계형 타입이나 함수에 맵핑할 필요가 있다. 또한 디자이너에게 애플리케이션 클래스나 데이타베이스내에서 캡슐화하는데 있어 전개 방법의 선택권을 주어야 한다.

ECM 툴에는 플라티늄테크놀러지의 패러다임플러스, 래쇼날소프트웨어의 래쇼날 로즈 , 셀렉트소프트웨어 툴스의 실렉트 엔터프라이즈 등이 있다. 래쇼날의 제품은 데이타베이스 모델링 툴을 대체하기보다는 보완하는 데에 제품 포지셔닝이 맞춰져 있음에도 불구하고 오라클 8 스키마를 생성해 준다.

플라티늄도 상당히 앞선 기술력을 제공하고 있다. UML 기반의 패러다임플러스는 디자인 및 구조가 구체화된 ECM내에서 오라클 8 객체 확장 모델링과 포워드 엔지니어링을 수행한다. 패러다임플러스는 추상적인 데이타타입 및 속성, 방법론, 그리고 오라클 8의 물리적 스키마와 소프트웨어 클래스 모두의 맵핑을 포함한 논리적이고 물리적인 모델을 생성한다. 이는 일반적인 메타 모델을 통해 애플리케이션 객체 모델과 데이타베이스 모델을 연결한다.

 

개념적 모델링

 

앞서 서술한 대표적인 모델링 툴들은 3가지 주요 ORDBMS와 긴밀한 관계를 맺고 있다. 이들은 여전히 미성숙돼 있고 기능적으로도 불완전하다. 더욱이 자체적인 단점으로 인해 타입을 사용하고자 할때 , 어떠한 툴도 풍부한 방법론 혹은 애드혹 논리적 모델링 어시스턴스를 제고하지 못한다.

모델링 기능에 있어 심각하게 여겨지는 문제점은 인포모델러의 한계이다. 비록 실버런의 유니버설 모델러는 몇가지 인터페이스를 사용해야 하지만, 상당히 훌류한 기능들을 제공한다.

로직윅스의 OR-컴파스는 타입의 비주얼 디스플레이 등과 같이 기능 및 인터페이스에 있어 개선이 이뤄져야 할만한 몇가지 사항들이 있다. 실버런 유니버설 모델러와 OR-컴파스 모두 훌륭한 물리적 모델러이지만 , 유니버설 모델러는 물리적 모델링 기능 등 몇가지 기능이 약한 편이다.

ORDBMS는 아직 주류를 형성하고 있지 못하며, 현재에는 소수의 사용자들 ( 개념적인 모델링을 뛰어 넘고자하는 사용자들 )만이 객체관계형 특징들에 대해 탐구하고 있을 것이다.

그러나 개념적인 모델링은 많은 가치를 제공하고 있다. 필자는 개인적으로 지금까지 살펴본 개념적인 모델링 툴들중에서 인포모델러를 가장 우수한 제품으로 여기고 있다.

하이브리드 솔루션이 필요하고 여유가 있는 경우에는 인포모델러를 통해 초기의 개념적인 모델링을 수행, 논리적인 모델링을 만드는 것이 좋다. 그리고 포워드 엔지니어링을 통해 그것을 데이타베이스 스키마로 전환한다.

다음에 보다 나은 논리적, 물리적 모델링 툴을 사용해 스키마를 논리적인 모델로 리버스 엔지니어링하고 사용자의 모델에 맞도록 조정하는 툴을 사용한다. 이러한 방식은 최적의 모델링을 위한 하나의 방안이 될 수 있을 것이다.

 

원본출처 : http://home.hanmir.com/~mhan/article/model/ordbmsmodel.html

[Top]
No.
제목
작성자
작성일
조회
264Issue가 되고 있는 고객관계관리(CRM)의 구축 방안
정재익
2002-01-06
4086
263VLDB (Very Large Database)
정재익
2002-01-06
4131
230DBMS 업계 XML 뉴스
정재익
2002-01-03
4624
208객체관계형데이타베이스 모델링
정재익
2001-12-25
7059
201관계형 데이터베이스 공짜시대가 오는가?
정재익
2001-12-21
4925
195Databases for programmers
정재익
2001-12-18
3835
183새로운 DBMS 접속을 위한 사양 GDBC
정재익
2001-12-16
3918
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.049초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다