728x90
1. 객체지향 데이터베이스 개념과 구조
① 객체지향 데이터베이스의 출현 배경
| ∘기존 데이터 모델인 계층, 네트워크, 관계형 같은 데이터 모델은 업무용 기술에 성공적으로 사용되어 왔지만, 공학 설계와 제조(CAD/CAM, CIM), 과학실험, 통신, 지리정보 시스템, 멀티미디어 등의 복잡한 데이터베이스 응용에는 충분하지 못함 ∘이와 같은 새로운 응용들은 복잡한 객체의 구조, 장기 트랜잭션, 이미지나 대형 텍스트 데이터의 저장을 위하여 새로운 데이터 타입, 특정 응용에 의존하는 비표준적인 연산의 정의 등의 기능이 필요함 ∘또 다른 이유는 소프트웨어 응용 개발에 객체 지향 프로그래밍 언어의 사용이 증가하기 때문이며, 기존의 데이터베이스를 C++, SMALLTALK, JAVA 등과 같은 객체지향 언어로 작성된 객체지양 소프트웨어 응용과 함께 사용하는 것이 쉽지 않게 되었음 ∘상업용 객체지향 DBMS가 출현함에 따라 표준 모델과 언어가 필요하게 되었으며, 객체지향 제작사와 사용자들로 구성된 ODMG(Object Database Management Group)라고 불리는 표준화 기구에서 ODMG-93의 표준을 내놓게 되었음 ∘객체지향 데이터베이스는 객체지향 프로그래밍 언어분야에서 정립된 많은 개념을 도입함 ∘객체지향 프로그래밍 언어에는 Simula (1960년대), Smalltalk (1970년대), C++ (1980년대 후반), Java (1990년대) 등의 언어들이 발전되어 왔음 ∘객체지향 데이터베이스의 실험적 시스템에는 MCC의 Orion, HP 연구소의 IRIS, Texas Instruments의 OPEN객체지향DB, ATT Bell 연구th의 ODE 시스템, UC/B의 Postgres - Montage - Illustra, Brown의 ENCORE/ObServer 프로젝트 등이 있음 ∘상용 객체지향 데이터베이스에는 GemStone system의 GEMSTONE/OPAL, Ontos의 ONTOS, Objectivity Inc의 Objectivity, Versant Object Technologies의 Versant, Object Design의 ObjectStore(→Excelon), ARDENT Software의 ARDENT(←O2), POET Software의 POET, Fujitsu-GM의 Jasmine 등이 있음 |
② 객체지향 데이터베이스의 개념
| ∘객체지향 데이터베이스의 주된 관점은 실세계 객체들과 데이터베이스 객체들 간의 직접적인 연관을 유지하여 객체가 자신의 무결성과 식별성을 잃지 않고 쉽게 식별되어 동작되도록 함 ∘객체라 함은 일반적으로 상태(값)와 행위(연산)의 두 구성요소를 가지며, 프로그래밍 언어의 프로그램 변수와 유사하나 복잡한 데이터 구조와 함께 프로그래머에 의해 정의된 특정 연산들을 가짐 ∘객체지향 데이터베이스에서, 객체는 자신을 묘사하기 위해 필요한 모든 정보를 유지해야 하므로 임의의 복잡한 구조를 가지게 되지만, 기존의 데이터베이스 시스템에서, 복합 객체에 관한 정보는 보통 여러 테이블이나 레코드에 분산 저장되어 실세계 객체와 데이터베이스 표현 간에 직접적인 연관성을 잃게 됨 ∘인스턴스 변수 - 객체지향프로그래밍 언어에서 객체의 내부구조는 인스턴스 변수의 명세를 통해 정의됨 - 인스턴스 변수는 객체의 내부 상태를 정의하는 값들을 가짐 - 인스턴스 변수는 애트리뷰트와 비슷한 개념이지만 객체 내에 캡슐화되어 외부 사용자들에게는 안 보이게 할 수 있다는 점에서 애트리뷰트와 차이가 있음 ∘객체의 캡슐화 - 사용자가 객체에 적용할 수 있는 모든 연산들이 미리 정의되어야 하는 객체지향 모델도 있으며, 이 경우에 객체의 완전한 캡슐화가 이루어지게 됨 ∘캡슐화를 장려하기 위해 연산은 두 부분으로 정의됨 - 연산의 이름과 매개변수(파라미터)를 명시하는 연산의 요약(signature) 또는 인터페이스 - 연산의 구현을 명시하는 메소드(method) 또는 몸체(body) ∘연산의 호출과 캡슐화 - 연산 이름과 파라미터로 구성되는 메시지를 객체에 전달함으로써 연산을 호출하며, 객체는 이 때에 해당 연산의 메소드를 실행함 - 캡슐화는 연산을 호출하는 외부 프로그램을 수정할 필요 없이 객체의 내부 구조나 연산의 구현을 변경할 수 있게 함 ∘상속 - 이미 정의된 타입이나 클래스들로부터 대부분의 구조와 연산들을 상속하여 새로운 타입이나 클래스를 정의할 수 있게 함 - 객체의 새로운 타입을 정의할 때 기존의 타입들의 정의를 재사용할 수 있음 ∘버전 기능 - 하나의 객체에 대하여 여러 버전을 지원하는 객체지향 시스템도 있음 (디자인과 공학 응용에 필수인 기능) - 예를 들어, 새로운 디자인이 테스트와 검증될 때까지 테스트와 검증이 된 디자인을 나타내는 객체의 구 버전을 유지할 필요가 있음 - 생산과정 제어, 구조, 소프트웨어 시스템 등의 설계에 매우 중요한 개념임 ∘연산의 다형성 - 서로 다른 타입의 객체들에 동일한 이름의 연산을 적용할 수 있는 기능을 의미하며, 이 경우에 연산의 이름은 적용되는 객체의 타입에 따라 여러 개의 서로 다른 구현을 지정할 수 있는데 이러한 기능을 연산의 중첩정의라고 함 |
③ 객체 식별자, 객체 구조, 타입 생성자(1)
| ∘고유한 객체 식별자 - 객체지향 데이터베이스 시스템은 저장된 각 독립 객체에 고유한 식별자를 제공함 - 고유한 식별자는 일반적으로 시스템이 생성한 객체 식별자(OID)에 의해 구현됨 - OID의 주요 특성은 불변성임. 즉, 특정 객체에 부여된 OID 값은 바뀔 수 없다는 것임 - OID의 이런 특성에 의해 실세계 객체의 식별성이 보존됨 ∘객체지향 데이터베이스에서 복합객체의 상태(현재값)는 다른 객체(또는 다른 값)들로부터 타입 생성자를 사용하여 생성할 수 있음 ∘객체를 표현하는 전형적인 방법은 각 복합객체를 (i,c,v)를 트리플(triple)로 표현함 - i: 객체 식별자(OID) - c: 타입 생성자 - 즉, 객체의 상태가 생성되는 방법 - v: 객체의 상태(현재값)를 의미함 ∘데이터 모델은 일반적으로 여러 가지 타입의 생성자를 포함하는데, 가장 기본적인 세 개의 생성자는 atom, tuple, set 생성자이며, 이외에 list, bag, array 생성자도 흔히 사용되는 생성자들임 - atom 생성자는 정수, 실수, 문자열, 부울 및 시스템에서 직접 지원되는 기본 데이터 타입 등과 같은 모든 기본 원자값을 표현하는데 사용됨 ∘객체의 상태는 타입 생성자 c에 의해 결정됨 - c가 atom이면 v 상태(값)는 시스템이 지원하는 기본값들의 도메인 내의 한 원자값이 됨 - c가 tuple이면 v 상태는 <a1:i1, a2:i2, .... an:in> 형태의 투플이 됨 . aj: 애트리뷰트 이름, ij는 객체 식별자) - c가 list이면 v 상태는 객체 식별자들의 순서리스트 [l1, l2, ..., ln]이 됨 - c가 array이면 v 상태는 객체 식별자들의 일차원 배열이 됨 - 이상의 객체모델에서는 set, list, tuple 및 기타 생성자를 임의로 중첩 시킬 수 있음 - 타입생성자 set, list, bag, array는 기본 타입 및 투플 타입으로 구분하여 모임 타임(collection type) 또는 벌크 타입(bulk type)이라고 함 ∘복합객체의 예 : - i1, i2, i3, . 등은 고유한 시스템 생성 객체 식별자를 희미함 o1 = (i1, atom, ‘Houston’) o2 = (i2, atom, ‘Bellaire’) o3 = (i3, atom, ‘Sugarland’) o4 = (i4, atom, 5) o5 = (i5, atom, ‘Research’) o6 = (i6, atom, ‘1988-05-22’) o7 = (i7, set, {i1, i2, i3}) o8 = (i8, tuple, <dname: i5, dnumber: i4, mgr: i9, locations: i7, employees:i10, projects:i11>) o9 = (i9, tuple, <manager:i12, manager_start_date:i6>) o10 = (i10, set, {i12, i13, i14}) o11 = (i11, set {i15, i16, i17}) o12 = (i12, tuple, <fname:i18, minit:i19, lname:i20, ssn: i21, . . ., salary:i26, supervisor:i27, dept:i8>) . . . |
④ 객체 식별자, 객체 구조, 타입 생성자(2)
 [그림 1] DEPARTMENT 복합 객체의 그래프 표현 |
※ 리스트, 배열, 집합, 백
| ∘리스트(list)는 집합(set)과 유사하지만, 리스트 내에 OID순서가 매겨지므로 리스트 내에 객체들을 순서에 의해 참조할 수 있음 ∘배열(array)과 리스트의 주된 차이점은 리스트는 임의의 개수만큼의 원소를 가질 수 있지만, 배열은 일반적으로 최대크기를 가짐 ∘집합과 백(bag)의 차이점은 집합 내의 모든 원소는 서로 달라야 하지만, 백은 중복된 원소를 가질 수 있음 |
⑤ 객체 식별자, 객체 구조, 타입 생성자(3)
∘타입 생성자를 구체화한 객체 데이터 정의어(ODL: Object Definition Language)는 특정 데이터베이스 응용을 위한 객체의 타입 정의에 사용할 수 있음 [그림 2] 타입 생성자를 사용한 Employee, Date, Department 객체의 타입 정의 |
⑥ 연산의 캡슐화, 메소드, 지속성
| ∘캡슐화의 개념은 객체지향 언어와 시스템의 주요 특징 중 하나이며, 프로그래밍 언어의 추상 데이터 타입 및 정보 은닉 개념과 연관됨 ∘정보은닉과 캡슐화의 개념은 데이터베이스 객체에도 적용할 수 있으며, 이것은 한 타입의 객체들에게 외부에서 적용할 수 있는 연산들을 그 객체 타입의 행위로 정의하는 것을 말함 ∘객체의 내부구조가 은닉되므로 미리 정의된 여러 개의 연산을 통해서만 접근이 가능하며 일반적으로 연산의 구현은 연산을 정의하기 위해 필요한 유연성과 기능을 제공하는 프로그래밍 언어로 명시됨 ∘데이터베이스 응용에서 모든 객체가 완전하게 캡슐화되어야 한다는 요구사항을 만족시키기는 어려우며, 이런 요구사항을 완화하는 한 가지 방법은 객체의 구조를 가시적 애트리뷰트와 은닉된 애트리뷰트(인스턴스 변수)로 구분하는 것임 ∘객체지향 데이터베이스와 객체지향 프로그래밍 언어는 밀접하게 연관이 있으며, 일반적으로 객체는 수행중인 응용프로그램에서 객체 생성자 연산을 호출함으로써 생성됨 ∘모든 객체가 데이터베이스에 영구적으로 저장되는 것은 아니며, 임시 객체는 프로그램이 종료되면 사라지고, 지속 객체는 프로그램 종료 후에도 데이터베이스에 계속 보존됨 ∘객체의 지속성을 지원하기 위한 전형적인 방법에는 이름 부여(naming)방식과 도달 가능성(reachability) 방식이 있음 ∘이름 부여 방식은 지속성이 있는 고유한 이름을 객체에 부여하여 그 프로그램 및 다른 프로그램에서 이 이름(유일해야 함)으로 검색이 가능하게 함 ∘도달 가능성 방식은 수많은 객체에 이름을 부여하는 것은 실용적이지 못하기 때문에 개선책으로 객체를 지속 객체로부터 도달가능하게 하는 방법임 - 객체그래프 상에서 객체 A로부터 B에 이르는 참조 순서가 존재하면 객체 B가 객체 A로부터 도달가능하다고 말함 - [그림 1] DEPARTMENT 복합 객체의 그래프 표현에서 O8이 지속적이라면 이 객체로부터 모든 객체가 도달 가능하기 때문에 모든 객체가 지속적임 ∘관계형 모델과 같은 기존의 데이터베이스 모델에서, 모든 객체는 지속 객체임 ∘객체지향 방식에서, 클래스 정의는 단지 클래스의 타입과 연산을 명시하는 것임 ∘사용자가 독자적으로 타입 set 또는 list의 지속 객체들을 정의할 수 있음 |
⑦ 타입(클래스) 계층구조
| ∘가장 간단한 형태의 타입은 타입 이름을 부여하고 그 타입에 대한 가시적인(전역의) 함수 이름들을 열거함으로써 정의할 수 있음 ∘타입을 명시할 때 함수의 매개변수들을 명시하지 않는 다음과 같은 형식을 사용함 TYPE_NAME: function, function, ..., function - 예를 들면, PERSON의 특성을 나타내는 타입은 다음과 같이 정의할 수 있음 PERSON: Name, Address, Birthdate, Age, SSN - PERSON 타입에서 Name, Address, SSN, Birthdate 함수는 저장 애트리뷰트로 구현될 수 있는 반면, Age 함수는 Birthdate 애트리뷰트 값과 현재 날짜로부터 Age를 계산하는 메소드로 구현될 수 있음 ∘서브타입(subtype)의 개념은 설계자나 사용자가, 이미 정의된 타입과 유사하지만 동일하지는 않은 새로운 타입을 생성해야 할 때 유용하며, 이때 서브타입은 수퍼타입(supertype)이라고 부르는 이미 정의된 타입으로부터 모든 함수를 상속함 - 예를 들면, EMPLOYEE와 STUDENT라는 두 개의 새로운 타입의 정의 EMPLOYEE: Name, Address, Birthdate, Age, SSN, Salary, HireDate, Seniority STUDENT: Name, Address, Birthdate, Age, SSN, Major, GPA - PERSON의 서브타입으로 선언하여 상속을 받는 경우의 선언은 다음과 같이 정의함 EMPLOYEE subtype of PERSON: Salary, HireDate, Seniority STUDENT subtype of PERSON: Major, GPA - 서브타입을 선언하기 위해서 Shape 애트리뷰트 값을 다음과 같이 각 서브타입의 객체들이 만족해야 할 조건으로 명시하는 방법이 있음 RECTANGLE subtype-of GEOMETRY_OBJECT (Shape=‘rectangle’): Width, Height TRIANGLE subtype-of GEOMETRY_OBJECT (Shape=‘triangle’): Side1, Side2, Angle CIRCLE subtype-of GEOMETRY_OBJECT (Shape=‘circle’): Radius ∘대부분의 객체지향 데이터베이스에서 한 외연 내의 객체들은 동일한 타입이나 클래스를 가지지만, 그러나 대부분의 객체지향 데이터베이스는 타입을 지원하기 때문에 여기서는 외연을 같은 타입의 객체들의 모임으로 간주함 ∘지속적 모임은 객체들의 모임이 데이터베이스 내에 영구적으로 보존되는 것으로서 여러 프로그램들이 접근하고 공유할 수 있음 ∘임시 모임은 객체들의 모임이 프로그램이 수행되는 동안에만 일시적으로 존재하고 프로그램이 종료되면 더 이상 보존되지 않는 것임 |
⑧ 복합객체와 기타 객체 지향의 개념
| ∎복합 객체 ∘비구조적 복합 객체 - DBMS가 제공하는 비구조적 복합 객체의 기능은 데이터베이스 응용이 필요로 하는 대형 객체들의 검색 및 기억 장소를 지원함 ∘이진 대형 객체 / BLOB - 비구조적 복합 객체의 대표적인 예로는 비트맵 이미지와 긴 텍스트 스트링(예, 문서)이 있는데, 이런 객체들을 이진 대형 객체(binary large objects) 또는 BLOB 이라고 함 ∘관계형 DBMS에서의 복합객체 지원 방법과 차이점은 관계형 DBMS에서도 복합 객체를 지원할 수 있으나 객체에 대한 연산은 RDBMS 밖에 정의할 수밖에 없음 ∘구조적 복합 객체 - 객체의 구조가 OODBMS에서 제공되는 타입 생성자들을 반복적으로 적용하여 정의된다는 점에서 비구조적 복합 객체와 다르며, 따라서 OODBMS에 의해 객체의 구조가 정의되어 등록됨 ∎기타 객체지향 개념 ∘다형성(연산자 중첩) - 다형성의 개념은 동일한 연산자의 이름 또는 심볼이 그 연산자가 적용될 객체의 타입에 따라 서로 다른 연산자의 구현과 결합될 수 있다는 것임 ∘실행될 메소드의 선택이 컴파일 시에 이루어지는 것은 조기 결합(early binding)이라고 하고, 함수와 구현 메소드 간의 결합이 실행 시에 이루어지는 것을 지연 결합(late or dynamic bing)이라고 함 ∘다중 상속과 선택적 상속 - 타입 계층구조에서 다중 상속은 하나의 서브타입 T가 서로 다른 수퍼타입을 두 개 이상 가지고, 따라서 그 수퍼타입들의 함수(애트리뷰트와 메소드)들을 모두 상속받는 것임 ∘버전과 구성 - 객체지향 시스템을 사용하는 데이터베이스 응용들에서는 동일한 객체에 대해 여러 버전의 관리가 필요하며, 한 객체에 대해 두 개 이상의 버전이 있을 수 있음 ∘복합 객체의 구성(Configuration) - 각 모듈당 하나의 버전으로 구성된 모임으로서 모듈 버전들이 서로 호환적이며 복합 객체의 유효한 버전을 형성함 |
2. 객체-관계 데이터베이스의 특징 및 동향
① 객체-관계 데이터베이스의 배경
| ∘객체-관계 데이터 모델(object-relational data model) - 객체지향 개념과 관계 개념을 종합한 모델 - 관계테이블, 질의어, 객체, 메소드, 클래스, 상속, 캡슐화, 복합객체 등을 지원 ∘객체-관계 데이터베이스(ORDB) - 객체-관계 모델에 따라 정의된 릴레이션과 객체의 집합 ∘객체-관계 데이터베이스 관리시스템(ORDBMS) - 객체-관계 데이터 모델을 직접 지원하는 DBMS - 객체-관계 데이터베이스를 정의하고 처리하여 이용 ∘상용 객체-관계 데이터베이스 - Informix의 Universal Server - Oracle의 Oracle - IBM의 DB2 Universal DB (UDB) ∘RDBMS를 기초로 객체지향개념을 포함시켜 확장 구현했으며, 주요 확장 내용은? - 다양한 유형의 확장 가능한 데이터 타입(data type) - 사용자 정의 데이터 타입과 이들 간의 상속(inheritance) - 사용자 정의 함수, 프로시저, 연산자 - 대형 객체 타입(large object type) ∘SQL의 발전 - SQL은 ANSI와 ISO가 1986년 처음 표준으로 채택 . 이것을 SQL:1986 또는 SQL1 이라고 지칭함 - 1992년 이 표준을 다시 개정하여 표준으로 발표 . 이것을 SQL:1992 또는 SQL2 이라고 지칭함 - 그 이후에 개정과 함께 객체 지향 개념을 지원 함 . 1999년 SQL:1999(SQL3) . 2003년 SQL:2003(SQL4) 새로운 표준의 등장 ∘SQL:1999/2003의 특징 - ORDBMS의 공통적인 인터페이스를 제공 - 관계적 특징: 새로운 데이터 타입, 조건식 및 타입 시스템의 강화 - 객체 지향적 특징: 사용자 정의 타입, 객체, 객체 식별자, 참조 타입, 상속 등의 도입, 함수와 메소드의 지원 - 순환질의(recursive query) - 트리거 개념을 지원하는 능동적 데이터베이스 기능 제공 - 클라이언트-서버 환경 지원 - 보안 및 뷰 갱신 기능 강화 |
② SQL3 표준의 구성요소
| ∘SQL3 표준에 포함되는 구성 요소 - SQL/Framework, SQL/Foundation, SQL/Bindings, SQL/Object - SQL에서 시간과 트랜잭션의 개념을 다루는 새로운 구성요소 - SQL/CLI(Call Level Interface) - SQL/PSM(Persistent Stored Module) ∘SQL/Foundation - 새로운 데이터 타입, 프레디키트, 관계 연산, 커서, 규칙과 트리거, 사용자 정의 타입, 트랜잭션 기능, 저장된 루틴 등을 다룸 ∘SQL/CLI - 전처리 과정과 소스코드 없이 응용 코드의 실행을 허용하는 규칙들을 제공함 - SQL/CLI는 마이크로소프트사의 ODBC와 SQL Access Group 표준에 기반을 두고, SQL 서버와의 연결, 자원의 할당과 회수, 진단과 구현 정보 확보, 트랜잭션의 종료 제어 등과 같은 기능을 위한 약 50개의 루틴을 포함함 ∘SQL/PSM - 응용을 클라이언트와 서버 사이에 분할하는 방안을 명시함 - 이러한 분할의 결과로 클라이언트와 서버 사이의 네트워크 전송량이 최소화되고, 그 결과 성능이 향상됨 ∘SQL/Bindings - 내포된 SQL과 직접 호출 기능을 포함함 - 예외 선언들을 추가로 포함하도록 내포된 SQL이 강화되었음 ∘SQL/Temporal - 이력 데이터, 시계열 데이터 등과 같은 시간 측면에서 확장된 기능을 제공하며, 현재 TSQL2 위원회에서 제안하고 있는 상태임 ∘SQL/Transaction - SQL 구현자를 위하여 XA 인터페이스를 정형화함 |
* ORDBMS의 구성과 객체-관계 모델
| ∘객체-관계 데이터베이스의 구성 - 객체-관계 데이터베이스는 톱 레벨 클래스들의 집합 - 투플 객체(tuple object): <oid, val> / oid: 객체식별자(object ID), val: 투플 값 - 투플을 구성하는 애트리뷰트의 값은 기본값(primitive vlaue), 집합(sets), 다른 객체 대한 참조(reference) 등 ∘객체-관계 모델과 객체 지향 모델의 차이점 - 객체-관계 모델은 각 객체 인스턴스의 톱 레벨 구조가 항상 투플 - 객체 지향 모델은 톱 레벨 구조가 임의의 값이 될 수 있음 ∘객체-관계 모델과 전통적인 관계 모델의 차이점 - 관계 모델에서는 투플 원소가 반드시 기본 값 - 객체-관계 모델에서는 투플 원소가 임의의 값이 될 수 있음 |
③ SQL:1999/2003의 관계적 특징 - 새로운 데이터 타입
| ∎ LOB와 BOOLEAN ∘SQL:1999/2003에는 기본 타입에 LOB와 BOOLEAN 타입이 첨가되었고, 복합 타입을 만들 수 있는 ARRAY와 ROW 타입이 지원됨 ∘새로운 데이터 타입의 LOB(Large OBject) - 현재 DBMS들이 제공하는 대부분의 BOLB 데이터 - 단순한 바이트 스트림으로 아무런 내부 구조나 내용에 대한 지식이 없이 단순한 데이터의 저장과 추출만 가능 - 클라이언트-서버 환경의 시스템에서 클라이언트 응용이 BLOB 데이터의 일부만 필요하더라도 전체 BLOB 데이터 검색해서 전송 → 오버헤드를 피할 수 없음 - 대량의 데이터를 저장하기 위한 타입 - CLOB : 가변길이 문자 스트링 . 접합(||), 서브스트링(SUBSTRING), 문자열 절단(TRIM), 문자 길이(CHAR_LENGTH) 등의 다양한 표준 문자열 처리 함수 사용 - BLOB : 가변길이 이진 스트링 . 8비트(obtet) 스트링으로 정의되며, BLOB간의 접합, 서브스트링 추출, 스트링 절단, 길이 함수(BLOB_LENGTH), LIKE 프레디킷 등에 사용 - DBMS 자체가 Large Object 타입의 데이터 일부에 대한 연산 허용 - 접합, 서브스트링, 길이 함수 등의 몇 가지 연산이 허용됨 - CLOB 타입의 이력서와 BLOB 타입의 사진 필드 첨가 예 ALTER TABLE STUDENT ADD COLUMN RESUME CLOB(100K); ALTER TABLE STUDENT ADD COLUMN PICTURE BLOB(4M); ∘BOOLEAN - 참(TRUE), 거짓(FALSE), 모름(UNKNOWN) 중의 하나의 값을 가짐 - 변수자체로 조건식이 되지는 않음 WHERE B (X) WHERE B IS TRUE (O) ∎ SQL 객체 ∘SQL의 객체는 <oid, v> 형태를 가지며, 여기의 oid는 객체 식별자, v는 투플 값을 칭함 ∘투플 값(tuple value) : [A1 : v1, A2 : v2,···, An : vn]와 같은 형식을 갖는데, A1, ···, A2은 서로 상이한 애트리뷰트 이름이고 각 vi 는 다음과 같은 값들 중의 하나를 취함 - 기본 값(primitive value): CHAR, INTEGER, DECIMAL, BOOLEAN과 같은 일반 SQL의 기본 타입 - 참조 값(reference value): 객체 식별자(oid: object identifier) - 투플 값(tuple value): [A1 : v1, A2 : v2,···, An : vn]과 같은 형식으로 여기서 각 Ai는 상이한 애트리뷰트 이름이고 각 vi는 값 - 집단 값(collection value): MULTISET이나 ARRAY 생성자로 만들어진 값 ∎ROW 타입과 ARRAY 타입 ∘ROW 타입 - 복합 애트리뷰트(composite attributes)로 정의 - 하나의 열에 대한 내부 구조를 정의 ∘ARRAY 타입 - 동일한 타입의 값들의 모임 - 데이터베이스 테이블의 한 열 값으로 저장됨 |
④ SQL:1999/2003의 관계적 특징 - 새로운 데이터 조건식
| ∘새로운 조건식에는 SIMILAR와 DISTINCT 조건이 있음 ∘SIMILAR - 두 문자 스트링이 서로 일치되는가를 검사 - SIMILAR TO가 나오는 스트링 패턴은 다양한 와일드카드를 지원함 예) WHERE NAME SIMILAR TO ‘(SQL:(|1986|1992|1999|2003)) | (SQL(1|2|3|4))’ ∘DISTINCT - 두개의 투플 값이 상이한 것인가를 검사 - 두 개의 투플은 애트리뷰트 수가 같아야 하고 대응되는 애트리뷰트 끼리 타입이 호환 - 두개의 널 값을 같은 것으로 간주한다는 점에서 UNIQUE 조건과 다름 - DISTINCT 조건식의 예 WHERE (SELECT S.Apa[1], S.Gpa[2], S.Gpa[3] FROM STUDENT S WHERE S.Sno=100) IS DISTINCT FROM (SELECT S.Gpa[1], S.Gpa[2], S.Gpa[3] FROM STUDENT S WHERE S.Sno = 200); . 위 DISTINCT FROM 조건식은 왼편 학생을 오른편 학생과 비교해서 같은 학기 성적끼리 모두 동일하거나 같은 학기의 성적이 모두 NULL인 경우에 false가 되고, 그 이외의 경우는 true가 됨 . 예) Sno가 100이 학생의 세 학기 성적이 (85, 95, NULL)이고, Sno가 200인 학생의 성적이 (85, 95, NULL)인 경우 이 두 학생은 동일한 것으로 간주되어 false 반환함 - SQL:1992 다음 조건식에서 WHERE 절이 참이 되기 위해서 3학년 학생들의 이름이 모두 달라야 하며, 이때 하나 이상의 학생 이름이 NULL이 되어도 모두 상이한 것으로 간주하여 true를 반환함 WHERE UNIQUE (SELECT S.Sname FROM STUDENT S WHERE S.Info.Year = 3). |
⑤ SQL:1999/2003의 객체 지향적 특징 - 사용자 정의 타입
| ∘사용자 정의 타입에는 구별 타입(distinct type)과 구조화 타입(structured type)이 있음 ∘구별 타입(distinct type) - SQL에서 정의된 기본 타입만을 이용하여 정의함 - 주로 테이블을 정의할 때 애트리뷰트 도메인을 명세함 - 서브타입(subtype)을 가질 수 없음 - 상이한 애트리뷰트들을 타입만 같다고 그들의 값들을 직접 비교할 수 있게 허용하는 것이 부적절한 경우에 이들을 제한하기 위해 사용 - 구별 타입의 정의의 예는 다음과 같으며, CREATE TYPE DNUMBER AS INTEGER FINAL; CREATE TYPE DYEAR AS INTEGER FINAL; . 키워드 FINAL은 이 타입이 서브타입으로는 아무것도 정의할 수 없다는 표시임 - 정의된 두 구별 타입, DNUMBER와 DYEAR를 이용한 STUDENT 테이블 CREATE TABLE STUDENT (Sno DNUMBER NOT NULL, . . . . Year DYEAR, . . . . ); - 다음 표현은 모두 불법이 됨 WHERE Sno > Year SET Year = Year +1 . 왜냐하면, Sno, Year는 DNUMBER, DYEAR 서로 다른 타입이므로 연산이 불가 - 만일 이러한 연산이 필요한 경우 CAST 함수 이용 WHERE Sno > CAST(Year AS DNUMBER) SET Year = Year + CAST(1 AS DYEAR) ∘구조화 타입(structured type) - 하나 이상의 속성으로 정의됨 - 기본 타입, 복합 타입, 다른 구조화 타입을 가질 수 있음 CREATE TYPE POINT AS (X FLOAT, Y FLOAT); CREATE TYPE LINE AS (BEGIN POINT, END POINT); - 구조화 타입의 모든 형태(연산)는 메소드나 함수로 연산을 표현됨 - 구조화 타입의 애트리뷰트는 캡슐화되어 시스템이 제공하는 검색자와 변경자 함수를 톻해서만 접근되고 수정될 수 있음 - 이 변경자 함수는 get, set함수라고 함 . 예 : A는 FLOAT, P는 POINT, L을 LINE 타입이라고 할 때 P.X /* 점 P의 X원소 값을 취해서 지시 */ L.BEGIN.X /* 선 L의 원소 Begin의 X원소 값을 지시 */ SET P.X=A /* 점 P의 X원소 값으로 A를 지정 */ SET L.BEGIN.X=A /* 선 L의 원소 Begin의 X원소 값으로 A를 지정 */ - 구조화 타입의 값들을 비교할 때는 사용자 정의 함수를 통해서만 가능함 - 구조화 타입은 타입들 간의 수퍼/서브타입 관계를 표현한 타입 계층에 참여 가능하며 서브타입은 수퍼타입의 모든 애트리뷰트와 연산자들을 상속받고, 또 자기 자신의 것을 추가로 가질 수 있음 |
⑥ SQL:1999/2003의 객체 지향적 특징 - 테이블 정의, 참조 애트리뷰트
| ∘테이블 정의를 CREATE TABLE … OF 생성자로 정의하여 타입 테이블로 정의할 수 있음 1) CREATE TABLE STUDENT ( Data STUDENT_TYPE, PRIMARY KEY (Sno)); 2) CREATE TABLE STUDENT OF STUDENT_TYPE ( PRIMARY KEY (Sno)); - 1)은 사용자 정의 타입 STUDENT_TYPE을 사용했으며, Sno접근을 위해서는 도트표현방법을 이용한 경로식을 사용하여 STUDENT.Data.Sno 같이 표현해야 함 - 2)는 키워드 OF와 사용자 정의 타입 STUDENT_TYPE이 테이블 STUDENT의 타입을 정의하는데 사용되었으며, 이 정의에서 Sno의 접근은 STUDENT.Sno 와 같이 표현함 ∘수퍼 테이블 / 서브 테이블 관계를 (UNDER)로 정의할 수 있는데, 테이블 간에도 타입 상속처럼 테이블 상속(table inheritance)이 가능함 CREATE TABLE GR_STUDENT UNDER STUDENT ( /*대학원생 테이블*/ Advisor PROF_TYPE, Thesis CHAR(100)); CREATE TABLE PART_TIME_STUDENT UNDER STUDENT ( /*시간제 학생 테이블*/ P_Sno INTEGER NOT NULL UNIQUE, Studyday DATE, Job CHAR(20), PRIMARY KEY (P_Sno)); ∘테이블 상속 제약 조건 - 수퍼테이블인 STUDENT의 각 투플은 서브테이블인 대학원생 테이블이나 시간제 학생 테이블에 속한 최대 하나의 투플하고만 대응 함 - 서브테이블인 대학원생 테이블과 시간제 학생 테이블에 있는 각 투플은 STUDENT 테이블에 있는 하나의 투플과만 대응함 - 갱신 연산을 수행 중에도 항상 자동적으로 지켜져야 함 . 만일 서브(수퍼)테이블에서 값을 갱신하거나 투플을 삭제 → 대응되는 수퍼(서브)테이블에서도 자동적으로 값이 변경, 삭제 됨 ∘참조 애트리뷰트 - SQL:1999/2003에서 객체(object)를 생성 방법: 타입 테이블에 투플 삽입 - 타입 테이블 . 모든 투플은 자신의 식별자, oid를 가진 객체로 취급 . 타입 테이블 자체는 객체지향 개념의 클래스(class)에 대응 . 그 투플들의 집합은 그 클래스의 익스텐트(extent)에 대응 - REF(STUDENT_Type)라는 참조 타입(reference type)을 이용하여 명시적으로 명세함 - 모든 타입 테이블이 정의될 때 자기 참조 컬럼(self-referencing column)도 정의함 ∘집단 타입 - SQL:2003은 MULTISET 집단 타입(collection type)을 도입하여 더 완전하게 지원함 - 똑 같은 원소가 집단에 하나 이상 있을 수 있다는 것을 제외하고 집합(set)과 동일 - STUDENT_TYPE에 새로운 집합 값 애트리뷰트(set-valued attribute), Enrolled 추가 CREATE TYPE STUDENT_TYPE UNDER PERSON_TYPE AS( Sno INTEGER NOT NULL UNIQUE, Year INTEGER, Major CHAR(10), Enrolled REF(COURSE_TYPE) MULTISET ); - 애트리뷰트 Enrolled의 도메인은 COURSE_TYPE 타입의 투플에 대한 참조 타입으로 똑같은 oid를 포함할 수 있는 다집합, MULTISET |
⑦ ODBMS와 ORDBMS의 유사점과 차이점
| ∘ODBMS와 ORDBMS의 유사점 - 사용자 정의 타입, 구조화 타입, 객체 식별자와 참조 타입, 상속 등을 지원함 - ORDBMS는 확장된 SQL을 지원하고, ODBMS는 자신의 ODL/OQL을 지원함 - 집단 타입을 조작할 수 있는 질의어 제공 - 병행 제어나 복구와 같은 DBMS의 기능 제공 ∘ ODBMS와 ORDBMS의 차이점 - ODBMS . 프로그래밍 언어와 매끄럽게 통합 . 객체를 중심으로 처리 . 몇 개의 객체들만 검색 . 주기억장치 내의 객체들의 효율적인 참조가 중요함 . 트랜잭션이 매우 길다 . 새로운 병행제어 기법이 필요함 . 질의 기능이 미비함 - ORDBMS . 호스트 언어 안에 SQL명령을 삽입 . 대규모 데이터 집단의 처리 . 대규모 데이터를 검색 . 디스크 접근의 최적화가 가장 중요함 . 트랜잭션은 비교적 짧다 . 관계 DBMS의 병행제어 기법을 이용 . 질의 기능이 핵심 부분임 |
3. XML과 인터넷 데이터베이스
① 구조화된 문서, 반구조화된 문서, 구조화되지 않은 문서
| ∘HTML은 웹 문서의 형식화 및 구조화에 널리 사용되고 있지만 데이터베이스로부터 추출된 구조화된 데이터를 명시하는데 적합하지 못함 ∘XML (eXtended Markup Language)은 웹상에서 데이터를 교환하고 구조화하는데 표준으로 등장하고 있음 ∘XML은 웹 페이지의 의미와 구조에 관한 정보를 더욱 상세히 제공하며, 이는 스크린에 디스플레이하기 위하여 웹 페이지를 단순 포메팅하는 것과는 다름 ∘XML에서 포메팅은 XSL (eXtended Stylesheet Language)이라는 별도의 페이지를 사용함 ∘데이터베이스에 저장된 정보는 엄격한 형식을 가지므로 구조화된 데이터(structured data)라고 부름 ∘DBMS는 모든 데이터가 스키마에 정의한 구조와 제약 사항을 따르는지 검사하는 역할을 담당함 ∘어떤 응용에서는 데이터가 어떻게 저장되고 관리될지 정하지 않은 상황에서 수집되는 경우도 있음 ∘이 경우 수집된 데이터는 특정한 구조를 가질 수 있지만 수집된 모든 정보가 동일한 구조를 가지지는 않으며, 이러한 데이터를 반구조화된 데이터(semi-structured data)라고 함 -semi-structured data에서 schema information은 data values와 혼합되어 있음. 이는 각 data object가 다른 속성을 가지며, 미리 알 수가 없으며, 이러한 데이터를 자기 기술형 데이터(self-describing data)라고 함 ∘비 구조화된 데이터(unstructured data)는 데이터 타입에 관한 정보가 매우 제한되어 있음 - 전형적인 예로서 text document를 들 수 있음 - HTML에서 Web pages는 unstructured data에 해당함 ∘Semi-structured data는 방향을 가진 그래프(directed graph)로 표시될 수 있음 ∘방향을 가진 에지의 labels 혹은 tags는 스키마 이름 (속성의 이름, 객체 타입, 관계 등)을 나타냄 ∘중간 노드는 individual objects 혹은 composite attributes를 나타냄 ∘리프 노드는 단순 (혹은 atomic) 속성의 실제 값 (data values)를 나타냄 |
② XML 계층적 데이터 모델
| ∘XML에서 기본 객체는 XML document임. XML 문서를 생성하기 위하여 요소(element)와 속성(attribute)이라고 하는 두가지 구조화 개념을 사용함. XML에서 속성은 요소를 기술하는데 필요한 부가적인 정보를 제공함 ∘HTML과 마찬가지로 문서에서 요소는 시작 태그(start tag)와 종료 태그(end tag)로 표시됨. 태그 이름은 각괄호 <...> 안에 표시되며, 종료 태그는 특별히 </...> 형태로 표시하여 구분함. 단순 요소(simple element)는 데이터 값을 포함하며, 복합 요소(complex element)는 다른 요소들로부터 계층적으로 생성됨 ∘XML 트리 구조와 XML 텍스트 표현 사이의 대응은 분명함. 트리 구조에서 리프 노드는 단순 요소를, 중간 노드는 복합 요소를 각각 표시함. 이러한 유사성 때문에 XML 데이터 모델을 트리 모델 혹은 계층 모델이라고 부름 ∘XML 문서의 세 가지 유형 - 데이터 중심 XML 문서: 이 부류의 문서는 특정한 구조를 따르는 데이터 항목들을 가짐. 주로 구조화된 데이터베이스로부터 추출되며, 인터넷 상에서 데이터의 교환과 디스플레이를 목적으로 XML로 포메팅됨 - 문서 중심 XML 문서: 책이나 논문 등과 같이 대량의 텍스트를 포함함. 구조화된 데이터 항목은 거의 없음 - Hybrid XML 문서: 문서의 일부는 구조화되어 있으며, 나머지 부분은 구조화 되지 않은 문서들임 |
③ XML 문서, DTD
| ∘정형화 된 XML문서 (Well-Formed XML document) - 첫 부분에는 관련된 속성들과 XML 버전을 나타내는 XML declaration으로 시작함 - 다음에는 트리 모델의 구문적 가이드라인이 나타남. 반드시 하나의 single root element를 가지면서, 각 element는 부모 element에 대한 start tag와 end tag의 쌍 안에서 start tag와 end tag의 쌍 내에 포함되어야 함 - well-formed XML 문서는 구문적으로 옳으며, 이러한 이유로 문서를 항해하고 내부 트리 표현을 생성하는 처리기에 의해 처리될 수 있게 됨 - DOM (Document Object Model) – 프로그램이 well-formed XML 문서에 해당하는 트리 표현을 다룰 수 있게 함. 전체 문서는 DOM을 사용하기 전에 파싱되어야 함 - SAX는 XML 문서를 on the fly 방식으로 처리할 수 있게 함. 이것은 start tag와 end tag를 만날 때 마다 처리 프로그램에게 메시지로 알려주기 때문에 가능함 ∘XML DTD 표기법 - 요소 이름 다음에 나타나는 *는 문서에서 그 요소가 0번 이상 나타난다는 의미임; 이러한 요소를 선택적 다중 값 요소 (optional multivalued element)라고 함 - 요소 이름 다음에 나타나는 +는 문서에서 그 요소가 1번 이상 나타난다는 의미임; 이러한 요소를 필수적 다중 값 요소 (required multivalued element)라고 함 - 요소 이름 다음에 나타나는 +는 문서에서 그 요소가 0번 혹은 1번 나타난다는 의미임; 이러한 요소를 선택적 단일값 요소(optional single-valued element)라고 부름 - 이상의 세 가지 기호 없이 나타나는 요소는 문서 내에서 정확히 한번만 나타난다는 의미임; 이러한 요소를 필수적 단일값 요소(required single-valued element)라고 함 - 요소의 타입은 그 요소 다음에 나타나는 괄호로 표시함. 괄호 안에 다른 요소의 이름이 나타난다면 이를 트리 상에서 원래 요소의 자식이라고 하며, #PCDATA나 XML DTD 상의 다른 타입이 나타난다면 그 요소를 리프 노드라고 함. PCDATA는 파싱된 문자 데이터(parsed character data)를 의미하며, 대략 string 데이터 타입에 해당함 - 요소를 표시할 때 괄호를 중첩되게 사용할 수 있음 - 바 기호 (bar symbol) (e1 | e2)는 문서에서 e1 혹은 e2 중 어느 하나가 나타난다는 의미임 ∘XML DTD의 한계 - DTD에서 데이터 타입은 제한적임 - DTD는 고유의 특별한 구문을 가지며, 따라서 특별한 처리기가 필요함 - XML 스키마 문서를 XML 문서와 동일한 구문으로 표시하면 하나의 처리기로 XML 문서와 스키마를 모두 처리할 수 있으므로 이점이 있음 - 모든 DTD 요소들은 특정한 순서를 지켜야 하며, 순서가 없는 요소는 허용되지 않음 |
④ XML 스키마(Schema)
| ∘XML 스키마는 XML문서의 구조(원소, 데이터 타입, 관계 타입, 범위, 기정 값)를 명세하기 위한 고급 데이터 정의 언어이며, 요약하면 다음과 같음 - XML 문서에 대한 데이터 정의 언어 - XML DTD의 제한점 극복 - 일반 XML 문서와 똑같은 구문 규칙⇒XML 문서와 XML 스키마 문서 모두 처리 가능 - XML 스키마구성 개념 . 트리 데이터 모델 기반: 원소, 애트리뷰트 . 데이터베이스와 객체 모델 기반: 키, 참조, 식별자 - DTD보다 복잡 - 더 많은 종류의 원소와 애트리뷰트 타입 명세 ∘XML 스키마 타입 - 시스템 정의 타입 . 기본 타입(primitive type) boolean decimal string . 파생 타입(derived type) integer positiveInteger negativeInteger - 사용자 정의 타입 . 시스템 정의 타입 이용해서 정의, 사용 . 단순 타입 : 다른 원소 포함 불가 . 복합 타입 : 다른 원소 포함 가능 ∘XML 스키마의 기능 - XML 네임스페이스(XML namespace)의 필요성 . 여러 응용 도메인에서 온 태그 이름들의 혼동 방지 . 태그 이름이 어떤 도메인에 속하는지 명세 . 원소 이름의 유일성 보장 . 의미의 명확성 제공 ∘원소(element)와 타입(type) 표기법 - 태그 element의 애트리뷰트 name : 원소의 이름 명세 - complexType 타입 : 자신 속에 원소를 포함할 수 있는 타입 - simpleType 타입: 자신 속에 원소를 포함할 수 없는 타입 - sequence : 여러 개의 하위 원소들을 순차적으로 명세 ∘XML 스키마의 기능적 이점 - 그 자신이 XML 문서이고 같은 구문법 사용 - 보다 많은 시스템 정의 타입을 지원 - 단순 타입을 기초로 문서 작성자가 원하는 임의의 복합 타입을 정의 가능 - 키와 참조 무결성 제약 지원 - 보다 융통성 있는 문서를 명세 가능 ∘XML 스키마의 기능적 단점 - DTD보다 훨씬 더 복잡 |
⑤ XML 문서와 데이터베이스
| ∘XML 문서 저장 방법 - DBMS에 XML 문서 전체를 하나의 애트리뷰트 값으로 저장 - DBMS에 XML 문서 내용을 여러 데이터 원소로 나누어 저장 - XML 데이터 베이스를 설계해서 원래 XML데이터를 저장(XML database) ∘DBMS에 XML 문서 전체를 하나의 애트리뷰트 값으로 저장: 관계 혹은 객체 DBMS를 사용 - XML 문서 전체를 투플이나 객체의 한 애트리뷰트로 저장 - 문서 처리 위한 특수 모듈 필요: 문서의 인덱스 생성, 탐색과 검색 속도 증진 위한 키워드 인덱싱 함수 사용할 수 있어야 함 - 스키마 없는(schemaless) 문서 중심(document-centric) XML 문서의 저장에 적절 - 적합 사용 환경: 주로 XML 문서 전체 접근, 갱신이 거의 없음, 탐색은 보통 소수의 애트리뷰트나 원소를 이용, 감사를 위해 문서를 원래 형식으로 저장해야 하는 함 ∘XML 데이터베이스를 설계해서 원래 XML 데이터를 저장; XML database - 새로운 유형의 데이터베이스 시스템을 설계 - XML 문서 구조의 특징인 트리(계층) 모델을 기반 - 전문 인덱싱 기법과 질의 기법 포함; 모든 종류의 XML 문서에 적용 가능 - 데이터 압축 기법 필요; 문서 저장 시 크기를 줄이기 위한 목적 ∘관계 데이터베이스로부터 XML 문서 추출할 때 문제점 - 관계 데이터베이스 . 관계 데이터 모델 사용, . 참조 무결성 첨가하면 그래프 구조인 ER 모델이 됨 - XML . 계층(트리) 모델 - 관계 데이터 모델을 XML로 변환할 때의 개념적 문제 . 그래프 모델과 트리 모델의 개념적 차이 ∘관계 데이터베이스로부터 XML 문서 추출 방법 - 데이터베이스로부터 추출되는 대부분의 문서 . 데이터베이스의 애트리뷰트, 개체 타입, 관계의 일부만 사용 - 어떤 개체 타입을 루트로 하느냐에 계층 구조가 여러 개 있을 수 있음 . 응용의 요구에 따라 필요한 데이터 추출, 트리 형태로 구성 - 적절한 XML계층과 XML스키마 문서 생성 - 그 외의 부가 작업 필요함 . 데이터 추출을 위한 정확한 SQL 질의문 작성 . 질의문의 실행 결과 테이블로부터 XML 트리 형태로 변환 . 단일 객체나 복수 객체를 검색 가능하도록 질의문 조절: 하나나 여러 개의 객체를 검색해서 문서 생성이 가능해야 함 |
'정보과학 > 데이터베이스특론' 카테고리의 다른 글
| 데이터 마이닝 (1) | 2023.09.07 |
|---|---|
| 데이터 웨어하우스 (0) | 2023.09.07 |
| 데이터베이스 보안과 권한 (0) | 2023.09.05 |
| 동시성 제어와 회복 기법 (0) | 2023.09.05 |
| 트랜잭션 처리 (0) | 2023.09.05 |
