▶ 1. 객체지향 데이터 베이스의 개요
1.1 객체지향의 개념
(1) 종래의 정보 모델의 문제점 : 데이터와 연산 분리 설계
- 자료와 연산간의 연관관계 관리 곤란
- 자료 변환 관리 곤란
- 구조변환 관련 연산집합 관리 곤란
- 설계에 중복발생 가능성
- 유지 보수 복잡
(2) 기존 데이터베이스 기술의 문제점
- 멀티미디어 데이터와 같이 비정형 구조 형태의 데이터 처리 불가능
- 정규화의 원칙성 결여와 성능문제 야기시킴
- 제한된 자료 type만 사용
(3) 객체지향 설계 개념 : 실세계에 존재하는 개념적 엔티티를 중심으로 모델링하는 방식
(4) 객체지향 기술의 장점
- 빠른 개발속도 : 기존의 객체 사용
- 시스템의 품질향상 : 이미 증명된 클래스를 재사용
- 유연성(flexibility)과 관리 용이성(maintainability)
- 사실적인 모델링
(5) 객체지향 데이터베이스가 가져야할 기능
- 복합객체(complex object)
- 객체 식별자(object identifier)
- Encapsulation
- Class
- Inheritance
- 확장성
- DML의 완전성
1.2 관계 DB와 객체지향 DB 의 차이점 비교
1.3 객체지향 데이터베이스의 장단점
(1) 장점
① 데이터 모델링의 다양성 제공
- 의미 자료 모델 개념으로 복잡한 데이터를 관리하는 응용분야에서 데이터의 설계와
유지보수등의 작업을 원활히 할 수 있도록 지원, 다양한 모델링 기법 제공
② 재사용성(reusability)와 확장성(extensibility)
- 재사용성 : 소프트웨어 위기 극복 개념의 부각, 일반화에의해 지원되는 성격, 새로운
환경을 모델링할 때 기존에 제작된 모듈을 다시 사용
- 확장성 : 캪슐화와 상속 기능으로 해결 지원, 기존 시스템에 추가적 요구사항이나
환경의 변화에 대응할 수 있는 능력
③ 개념적 일치성
- 의미 자료 모델의 분류화=세분화, 일반화, 집합화=통합화 등의 개념 지원, 이는
객체지향 언어의 추상화, 상속성, 연관성 개념과 일치된다. 따라서, OODB와 이것을
관리하는 프로그램 언어간의 개념적 불일치가 상대적으로 적다
④ 지원 기능 : query, 복합 객체, 버전 관리, 스키마 변환, 멀티미디어 자료 관리 기능,
긴 트란잭션 처리등의 기능 지원
㉠ 질의어
- 질의 대상이 클래스(class-subclass)가 되고 질의 범위는 지정 클래스나 클래스
계층구조내 모든 부 클래스가 되기도 한다. 질의 결과는 지정된 클래스에 속하며
조건을 만족하는 인스턴트들의 집합이 된다
- 질의 결과 생성시 객체일치(object equality), value equality 등의 일치성 존재
㉡ 복합 객체(composite object)
- 객체 집합(집합화)
- 객체 구성 요소도 객체가 됨
- 구성 객체내의 관계를 기술함으로써 정의되며 이들의 관계는 복합객체 계층 구성도
로 표현된다
㉢ 버전(version)관리
- 하나의 객체변화 과정을 기록하며 과거의 상태변화 역사를 보관 관리하는 것
㉣ 스키마 변환
- 모델링 환경에 따라 스키마가 변화할 필요가 있을수 있는데 이런 변화가 시간적,
외부 조건에 따라 동적으로 발생할 수도 있다
- 클래스 정의 변경, 상속 관계 변경으로 나누어 생각
㉤ 멀티미디어 자료 관리
- 종래 자료 : 텍스트 기반 자료형태에서
- 멀티미디어 자료 : 화상, 동영상, 음향(음악) 자료형태가 추가되었다
- 멀티미디어 자료의 특징 : 대용량, 실시간 처리 요구
- 멀티미디어 데이터 처리를 위해
용량 확장성(extnsibilty), 자료형의 유연성(flexibilty), 처리 속도 효율성(efficiency)
지원
㉥ 긴 트랜잭션 처리
- transaction : 처리 단위
- CAD/CAE등에의 응용 확장으로 긴 트랜잭션 처리를위한 관리 기법 요구
⑤ 기타
㉠ 프로그래밍 생산성 향상
㉡ 유지보수 용이성
㉢ 복잡한 관계성 표현
㉣ 다양한 데이터 타입 제공
㉤ 멀티미디어 기능 제공
㉥ 데이터 추상화 개념 지원
㉦ 일반화와 집합화를 쉽게 표현
(2) 단점
- 이론 부재 : 데이터 모델 및 질의 모델의 정형화 미개발(수학적 기반 결여)
. 관계 DB : 정형화된 데이터 모델 및 관계 대수/해석학 기반 질의 모델 확립
. 구현체마다 개념적 차이 존재 가능, 통합 운영상 장애 가능성
- 복잡성 : 다양성 장점에 비해 구현 복잡 및 관리 복잡
-> 실세계 모델링 편리함 제공, 구현 및 관리시 복잡성과 성능 저하 초래
- 질의 최적화의 복잡성 : 질의어가 일반 PL의 내장형태로 지원 -> 질의 최적화 곤란
- 표준화의 미비
- 안전성, 신뢰성 부족
▶ 2. 객체지향 데이터 모델
- 데이터 모델 : 데이터 베이스의 내용과 의미를 결정하기위한 현실세계의 개체들을
설명하고, 개체들간의 관계, 의미 및 여러 제약 조건등을 기술하기위한
개념적 도구
2.1 객체
ㅇ 객체(object) : 개념적인 실세계 엔티티(실세계에 존재하며 하나의 개체를 생성하는
DB의 구성 단위)
- 객체의 상태를 나타내는 속성(attribute)과 애트리뷰트와 객체를 조작하는
연산집합인 method로 구성, 애트리뷰트 자체도 객체
- 유일 식별자(object identifier, OID)를 가짐 : 객체를 유일하게 구별하기위해
- 원시 객체(primitive(simple) object) : 값만 가지는 스트링, 정수형등
인스탄스 변수 없음
복합 객체(composite object) : 애트리뷰트로 타 객체 참조, 집합값, 벡터, 매트릭스등
인스탄스 변수
- 상태(state)를 포함한 개별(private) 메모리로 구성
. 개별 메모리는 애트리뷰트나 인스탄스 변수(instance variable) 집합에 대한 값들로
이루어짐
. state는 이 값들임, 객체내의 속성의 값
. 즉 객체는 property( , )를 나타내는 instance variable임
. 인스탄스 변수 값 자체도 객체임
- 메소드(method, operations) : 객체내의 애트리뷰트 관리 프로시져
객체의 행위(behavior)는 메소드내에 갶슐화 됨
객체의 상태를 조작하는 코드로 구성됨
객체 정의 일부분임
메소드와 인스탄스 변수는 객체 밖에서는 볼수 없음 : 변경 불가
- 클래스에 속하는 객체를 클래스의 인스탄스라 함
- class 정의의 효과 :
. 각각 정의시보다 기억장치 중복 방지
. set-oriented operation 가능 : 질의 처리 가능하기 때문, 이로인해 질의 시간 빠름
2.2 메시지(message)
- 객체간의 통신 매체(객체간의 인터페이스 역할)
모든 메시지는 객체에 의해 이해되고, 메시지를 실행하는 일치되는 메소드가 있다
- "객체에 해당하는 메소드를 수행하라"
- 객체 접근 권한 제어 기법 : 객체의 내.외부 구분 역할
캪슐화 지원
2.3 클래스
- 유사한 객체들의 구조와 행동을 기술하는 도구
- 객체의 속성과 method로 정의
- 클래스도 하나의 객체임
- 중복된 정의를 방지함으로써 저장공간 절약과 동적 스키마 변경을 지원
: 클래스내에 애트리뷰트와 메소드에 관한 정의를 포함하여
2.4 클래스 계층 구조
- class-hierarchy : class 끼리의 집단화(hierarchy of class)
- 추상화 기법 :
. 일반화(generalization) : super-class 생성 과정, 여러 클래스의 공통 속성 추출
. 특수화(specialization) : subclassing화 과정, 상위 클래스에서 여러개의 하위 클래스로
분류되는 것
- IS-A 관계 : superclass ----> subclass(class)
- 상속 관계(inheritance) : super-class =====> subclass
+---> property(method & instance variable)
하위클래스는 상위클래스의 애트리뷰트와 메소드를 상속 받는다
. 클래스에 대해 정의된 property는 모두 subclass에 상속됨
. 부가적인 속성은 각각의 subclass에 정의될 수 있다
. +--- simple inheritance : 1-superclass로부터 상속, 트리형태
+--- multiple inheritance : n-superclass로부터 상속
DAG(directed acyclic graph) 형태
효과 : 현실 세계 표현 유리, 자료 중복 제거 역할
. 상속의 문제점
- 명칭 충돌(naming conflict) : 모호성 발생 가능(상위클래스:하위클래스),
다중상속에서의 상위클래스간 명칭 충돌
- 상속의 범위 : 완전/선택 상속 결정 문제
선택 상속시 IS-A 개념에 배치되며 상속의 구현 및 관리 복잡
- 캡슐화 위배 : 서브 클래스가 슈퍼 클래스의 애트리뷰트에 지접 접근시
2.5 다중성(polymorphism)
- 상위 클래스의 메소드 정의가 하위 클래스에 부적절시 하위 클래스의 메소드를 재정의
- 동일한 메시지에대해 클래스 마다 서로 다르게 동작하도록 지정할수 있다
다수의 메소드 가능, 다른 클래스에도 가능
2.6 복합 객체
- 객체의 애트리뷰트로 다른 객체를 가질 수 있게 함으로써 포함관계를 갖는 객체를
표현하는데 사용
- 포함하는 객체와 포함되는 객체 사이에 집합화(aggregation : IS-PART-OF) 관계가
성립
- 복합 객체를 관리하기위해서는 동시성제어(concurrency control), 스키마 변경,
버전제어, 권한검사등의 관리에서 대상 객체와 이를 구성하는 구성 객체까지 제어
해야 함
2.7 버전 관리
- 버전이 가능한 객체 : 추상 객체와 하나이상의 버전으로 구성
- 버전의 종류
① 임시 버전(transient) - 버전유도 관계트리에서 단말노드에 위치한 버전으로
갱신과 삭제 가능
② 작업 버전(working) - 임시 버전을 유도시킨 과거의 임시 버전으로 갱신을
허용하지 않지만 삭제는 허용
③ 안정 버전(released) - 작업 버전에서 승격이 되며 안정된 상태에 도달한 버전을
나타내며 갱신, 삭제 모두 금지
- 버전 변경 통보 방법
: 버전의 변경을 연관된 객체에게 메시지를 보냄으로써 통보(즉시통보 or 사용자가
지정한 시간까지 연기했다 통보)
: 타임 스탬프를 이용하는 방법 - 버전 객체에 접근할 때 접근할 객체의 변경통보
시각과 접근하는 객체의 변경 승인 시각을
관리하는 방법
2.8 스키마 변경(schema transformation)
- 각 사용자의 데어터 베이스 접근 목적이 다르므로 각자의 응용 목적에 따라 데어터
베이스의 스키마를 변경
(1) 클래스 정의 변경
1) 애트리뷰트 변경
- 애트리뷰트의 추가 및 삭제
- 애트리뷰트의 명칭, 도메인, 디폴트값 변경
2) 메소드 변경
- 메소드의 추가 및 삭제
- 메소드의 명칭, 코드 변경
3) 클래스 명칭 변경
(2) 상속 관계의 변경
- 상위 클래스의 추가 및 삭제
- 상위 클래스들의 우선순위 변경
- 클래스의 추가 및 삭제
- 여러 클래스로부터 공통점을 추출해 일반화된 상위 클래스로 추가와 통합
- 클래스를 여러 클래스로 분할
- DB 스키마가 객체지향 데이터 모델과 일관성을 유지하기위해 충족되어야 할 성질
: 클래스 계층구조의 불변성
: 명칭의 불변성
: 근원의 불변성
: 완전 상속의 불변성
: 도메인의 불변성
2.9 스키마 버전
- 스키마 변경의 문제점
: 변경시 해당되는 객체의 변화를 기록하지 않는다 - 스키마에서 애트리뷰트가
제거될 때 해당되는 객체들에 대해서 제거되는 애트리뷰트의
값은 모두 제거된다
: 한 사용자의 스키마 변경이 다른 모든 사용자에게 영향을 준다
- 문제점을 해결하기 위해 버전의 개념을 도입
2.10 장기간 트랜잭션
- 단기간 트랜잭션의 문제점
: 자료의 처리가 사용자와 대화하는 환경에서 이루어 진다(작업처리시간 길어짐)
: 작업수행 중에도 사용자와 계속된 대화를 해야하므로 전송하지 않은 자료가
전달될 수 있다
: 하나의 작업이 작은 작업들로 분할될수 있는 경우가 있다
: H/W나 S/W의 문제로 더 이상 작업을 할 수 없을 때 전체 작업을 취소시키면
유실되는 사용자의 작업량이 커진다
: 대화식 사용 환경을 지원하기 위해서는 동시성 제어를 통한 빠른 응답 시간을
제공해야 한다
- 내포형 트랜잭션
- 객체의 버전을 이용한 공유 DB와 개인 데이터 베이스 간의 장기간 트랜잭션
- 약성잠금(soft lock : 접근 충돌시 사용자간의 협상을 통하여 잠금을 해제)을 이용한
장기간 트랜잭션
- 여러 트랜잭션을 하나의 트랜잭션으로 묶어 관리하여 여러 사용자간의 공동 작업을
지원하는 그룹 트랜잭션
- 트랜잭션 복구시 발생하는 작업취소 작업은 연쇄 철회(cascading rollback)가
발생하는데 이를 방지하기위해 작업취소 적업을 보상할 수 있는 보상 트랜잭션
(compensating transaction) 지원
▶ 3. OODBMS의 소개
3.1 개발 현황
(1) IRIS
- C, Pascal로 구현
- HP68000 workstation상에서 실행
- C-interface를 통하여 객체 관리 서비스 제공
- 응용을 위한 SQL, OSQL의 객체지향 확장
- 관계 저장장치 시스템상에서 객체 관리자(object manager) 실행
- DAPLEX 함수형 자료모델에 기반
(2) Orion
(3) EXODUS
3.2 UniSQL
A. 상업 모델
(1) GemStone
- C 언어로 구현
- client/server 구조 지원
- VAX | SUN workstation이 서버로 시용
- IBM-PCs, Apple Macs, Textronix workstation이 client로 사용됨
- 응용으로 C, C++, Smalltalk 인터페이스 제공
- DB 시스템에 Smalltalk80이 확장됨
(2) VBase[ANDR87]
- C 언어로 구현 - UNIX하의 SUN workstation에서 실행
- client/server 구조
- SQL 지원
- 스키마 정의어로 TDL(type definition language) 사용
- 응용을 위한 C Object Processor(COP) 제공
- 객체지향형으로 설계 및 구현됨
(3) Statice
- Common LISP로 구현
- Symbolics LISP 기계상에서 실행
- client/server 구조
- 거의 DAPLEX 함수형 자료모델을 기반으로 구축
B. 산업 연구 시범 모델
(1) IRIS[FISH87]
- C, Pascal로 구현
- HP68000 workstation상에서 실행
- C-interface를 통하여 객체 관리 서비스 제공
- 응용을 위한 SQL, OSQL의 객체지향 확장
(backward-compatible with SQL)
- 관계 저장장치 시스템상에서 객체 관리자(object manager) 실행
- DAPLEX 함수형 자료모델에 기반
(2) O2
- C 언어로 구현
- SUN-OS하의 SUN workstation상에서 실행
- client/server 환경에서 객체지향 패러다임 채용
- C-interface(CO2)와 Basic-Interface(BasicO2) 제공
- Object Manager를 WISS 저장 시스템상에 구현(WISS: wisconcin storage system)
(3) Jasmin
- Fujitsu, Ltd(Japan) 개발
- DAPLEX 함수형 자료모델 기반
- C-interface(Jasmin/C) 제공
C. 대학 연구 시범 모델
(1) POSTRES[STON86, ROWE87]
- INGRES RDBMS에 SEQUEL 채택
(backward-compatible with QUEL)
- ADT, complex object, version 지원
- 애트리뷰트에 대한 valid type으로 'relation' hierarchy와 'procedure' 포함
(=class) (=method)
(2) ENCORE/Observer
- C로 구현
- ENCORE는 front-end object manager로SUN workstation과 VMS하의 DEC 기종에서 실행
- OBServer는 back-end object server로, UNIX하의 SUNs에서 실행
(3) AVANCE
- 완전한 distributed object-oriented DB system
- users of AVANCE program in PAL, language influenced by Simula, Smalltalk, and CLU
- 사무 응용 개발을 지원하도록 설게됨
(4) OZ+
- C와 Turing Plus로 구현
- UNIX하의 SUNs에서 실행
- 관계 DB 시스템인 EMPRESS상에 구현
- 사무 응용의 유용한 기능 구현
(5) EXTRA
- EXODUS 시스템상에 object manager 구축
- C++의 확장형인 E 언어로 EXODUS의 구현
- E 프로그래밍 언어의 기반위에 PL과 DB의 통합
- 데이터 모델은 O2, Gemstone, POSTGRES, GEM, Orion 데이터 모델의 확장임
'DataBase' 카테고리의 다른 글
특정조건에 해당하는 앞에서 원하는 만크만 얻어오기 (0) | 2011.03.27 |
---|---|
[SQLite] PRIMARY KEY 중복 생성 (0) | 2011.03.04 |
데이터베이스 정규화 (0) | 2009.10.31 |
데이터 모델링에서 사용하는 기본 개념 2 (0) | 2009.10.31 |
데이터 모델링에서 사용하는 기본 개념 1 (0) | 2009.10.31 |
댓글