개념: 관계형 데이터베이스 및 객체 지향
주제
소개
이 개념 문서는 객체 모델 및 관계형 데이터 모델의 개요를 제공하고
지속성 프레임워크의 요약 설명을 제공합니다.
관계형 데이터베이스 및
객체 지향
관계형 데이터베이스 및 객체 지향이 완전히 호환 가능한 것은 아닙니다.
이 둘은 실제로 두 가지 다른 보기를 표시합니다.
RDBMS에서는 표시되는 모든 것이 데이터이며
객체 지향 시스템에서는 표시되는 모든 것이 작동입니다. 한 Perspective가 다른
Perspective보다 좋은 것은 아닙니다. 객체 지향 모델은 복잡한 작동과
상태 특정 작동을 포함하는 데이터가 보조인 시스템 또는
데이터가 자연적 계층 구조(예: 부품표)에서
탐색적으로 액세스되는 환경에서 잘 작동합니다. RDBMS 모델은 관계가 동적이거나
임시 어플리케이션 및 시스템을 보고하는 데 가장 적합합니다.
실제 사실은 많은 정보가 관계형 데이터베이스에 저장된다는 것입니다.
객체 지향 어플리케이션에서 해당 데이터에 액세스하려는 경우
RDBMS에서 읽거나 쓸 수 있어야 합니다.
또한 종종 객체 지향 시스템이 비 객체 지향 시스템과 데이터를 공유할 필요가 있습니다.
따라서 RDBMS를 공유 메커니즘으로 사용하는 것이 자연스럽습니다.
객체 지향 및 관계형 설계가 일부 공통 특성을 공유하지만(객체 속성은
엔티티 열과 개념적으로 유사함), 근본적인 차이로 인해
끊김 없는 통합이 도전이 됩니다.
근본적인 차이점은 객체 모델이 데이터를 숨기는 반면(공용 인터페이스 뒤에 캡슐화)
데이터 모델은 데이터를 드러낸다는(열 값을 통해) 점입니다.
관계형 모델은 엔티티 및 관계로 이루어집니다.
엔티티는 실제 테이블 또는 보기로도 알려진
여러 테이블의 논리적 투영일 수 있습니다.
아래 그림은 LINEITEM, ORDER 및 PRODUCT 테이블과 이러한 테이블 사이의 다양한 관계를 나타냅니다.
관계형 모델에는 다음 요소가 포함됩니다.

관계형 모델
엔티티에는 열이 있습니다.
각 열은 이름 및 유형으로 식별됩니다. 위 그림에서
LINEITEM 엔티티에는 LineItem_Id(1차 키), Description, Price, Quantity, Product_Id
및 Order_Id 열(마지막 두 열은 ORDER 및 PRODUCT 엔티티를 링크하는
외부 키)이 있습니다.
엔티티에는 레코드 또는 행이 있습니다.
각 행은 보통 객체의 지속성 데이터를 표시하는
고유 정보 세트를 표시합니다.
각 엔티티에는 하나 이상의 1차 키가 있습니다.
1차 키는 각 레코드를 고유하게 식별합니다(예: Id는 LINEITEM 테이블의 1차 키임).
관계에 대한 지원은 벤더에 특정합니다.
예는 PRODUCT 및 LINEITEM 테이블 간의 논리적 모델 및 관계를 나타냅니다.
실제 모델에서 관계는 일반적으로 외부 키/1차 중요한 참조를 사용하여 구현됩니다.
엔티티가 다른 엔티티와 연관되는 경우 그 엔티티는 외부 키인 열을 포함합니다.
외부 중요한 열은 엔티티의 특정 레코드를 관련된 엔티티에 연관시킬 수 있는 데이터를 포함합니다.
관계는 다양성(카디날리티라고도 함)을 가집니다.
공통 카디날리티는 1 대 1(1:1), 1 대 다(1:m), 다 대 1(m:1) 및 다 대 다(m:n)입니다.
예를 들어, LINEITEM은 PRODUCT과 1:1 관계를 가지며 PRODUCT은
LINEITEM과 0:m 관계를 가집니다.
객체 모델은 다른 것들 사이에서 클래스를 포함합니다(객체 모델의 완전한 정의는
[UML01] 참조).
클래스는 때때로 객체 인스턴스라고 하는
객체 세트의 구조 및 작동을 정의합니다.
구조는 속성(데이터 값) 및 연관(클래스 사이의 관계)으로 표시됩니다.
다음 그림은 클래스의 속성(데이터)만을 표시하는 단순 클래스 다이어그램을 나타냅니다.

객체 모델(클래스 다이어그램)
주문에는 번호(주문 번호) 및 1 이상(1..*) 품목에 대한 연관이 있습니다.
각 품목에는 수량(주문된 수량)이 있습니다.
객체 모델은 상속을 지원합니다.
클래스는 다른 클래스에서 데이터 및 작동을 상속할 수 있습니다(예를 들어,
SoftwareProduct 및 HardwareProduct 제품은 Product 클래스에서 속성 및 메소드를 상속함).
대다수의 비즈니스 어플리케이션은 관계형 기술을 실제 데이터 저장으로 구현합니다.
객체 지향 어플리케이션 개발자가 직면하고 있는 도전은
데이터 모델의 변경이 객체 모델을 "중단"하지 않고
반대의 경우도 그러하도록 관계형 데이터베이스를 충분히 분리하고 캡슐화하는 것입니다.
어플리케이션이 관계형 데이터에 직접 액세스하도록 하는 많은 솔루션이 존재합니다.
객체 모델과 데이터 모델 사이에 끊김 없는 통합 달성이 도전이 됩니다.
데이터베이스 API(Application Programming Interface)는
표준 특성(예: Microsoft의 Open Data Base Connectivity API 또는 ODBC)에서 나온 것이며
독점적(특정 데이터베이스에 대한 고유 바인딩)입니다.
API는 어플리케이션이 원시 관계형 데이터에 액세스할 수 있도록 하는
서비스를 통해 DML(Data Manipulation Language) 전달을 제공합니다.
객체 지향 어플리케이션에서 데이터는 어플리케이션에서 사용되기 이전에
객체 관계형 변환을 받아야 합니다.
이것은 원시 데이터베이스 API를 어플리케이션 객체로 변환하기 위해
상당한 양의 어플리케이션 코드를 필요로 합니다.
객체 지향 프레임워크의 목적은 일반적으로 실제 데이터 저장을 캡슐화하고
적절한 객체 변환 서비스를 제공하는 것입니다.

지속성 프레임워크의 목적
어플리케이션 개발자는 객체 지향 어플리케이션에 관계형 데이터 액세스를 구현하는 데
30% 이상의 시간을 보냅니다.
객체 관계형 인터페이스가 올바르게 구현되지 않으면 투자가 소실됩니다.
객체 관계형 프레임워크 구현은 이 투자를 획득합니다.
객체 관계형 프레임워크는 객체 관계형 구현 비용을
전체 구현 비용의 10% 미만으로 줄여서 후속 어플리케이션에서 재사용될 수 있습니다.
시스템을 구현할 때 고려해야 할 가장 중요한 비용은 유지보수입니다.
전체 라이프사이클에 걸친 시스템 비용 총계의 60% 이상이
유지보수에 드는 비용일 수 있습니다.
불충분하게 구현된 객체 관계형 시스템은 기술적인 유지보수 및 재정적인 유지보수 모두에
악몽입니다.
- 성능. 객체를 데이터로 분해하고 데이터에서 객체를 구성하는
데 세심한 고려가 제공되어야 합니다.
데이터 처리량이 많고 중요한 시스템에서
이것은 종종 잘못 설계된 액세스 계층의 약점입니다.
- 설계 타협 최소화.
관계형 데이터베이스를 구현하는 시스템을 빌드한 객체 공학자에게 익숙한 패턴은
저장영역이 관계형 시스템으로 되도록 객체 모델을 조정하고
객체를 용이하게 저장할 수 있도록 관계형 모델을 변경하는 것입니다.
종종 사소한 조정이 필요하지만, 잘 설계된 액세스 계층은
객체 및 관계형 모델 모두의 설계 저하를 최소화합니다.
- 확장 가능성.
액세스 계층은 일정한 기능이 프레임워크에 요구되는 경우
어플리케이션 개발자가 프레임워크를 확장할 수 있도록 하는
화이트 박스 프레임워크입니다.
일반적으로, 액세스 계층은 확장 없이
어플리케이션 데이터 저장영역 요구사항의 65-85%를 지원합니다.
액세스 계층이 확장 가능한 프레임워크로 설계되지 않은 경우,
어플리케이션 데이터 저장영역 요구사항의 남은 마지막 35-15%를
달성하는 것이 매우 어렵고 비용이 많이 들 수 있습니다.
- 문서화.
액세스 계층은 블랙 박스 컴포넌트 및 화이트 박스 프레임워크 모두입니다.
블랙 박스의 API는 명확하게 정의되고 잘 문서화되어
쉽게 이해할 수 있어야 합니다.
이전에 언급된 대로, 액세스 계층은 확장될 수 있도록 설계됩니다.
확장 가능한 프레임워크는 매우 철저하게 문서화되어야 합니다.
하위 분류될 클래스가 식별되어야 합니다.
각 관련 클래스의 프로토콜 특성이 지정되어야 합니다(예: public, private, protected, final 등).
더욱이, 확장 가능성을 촉진시키기 위해 액세스 계층 프레임워크 설계의 상당한 부분이
노출되고 문서화되어야 합니다.
- 공통 객체 관계형 맵핑에 대한 지원.
액세스 계층은 확장에 대한 요구 없이 일부 기본 객체 관계형 맵핑에 대한 지원을 제공해야 합니다.
이러한 객체 관계형 맵핑은 이 문서의 후속 섹션에서 더 자세히 설명되어 있습니다.
- 지속성 인터페이스: 객체 지향 어플리케이션에서
객체 어플리케이션용 비즈니스 모델은 문제점 도메인에 대한 의미적 지식을 캡처합니다.
개발자는 데이터 저장영역 및 검색 세부사항에 대해
너무 많이 고려하지 않고 객체를 처리하고 객체와 상호 작용해야 합니다.
잘 정의된 지속성 인터페이스 서브세트(저장, 삭제, 찾기)가
어플리케이션 개발자에게 제공되어야 합니다.
객체 관계형 어플리케이션에 대한 공통 패턴이 발표되고 있습니다.
반복적으로 간극(chasm)을 넘어선 IT 전문가들이 성공적인 객체 관계형 어플리케이션이 나타내는 일정한 구조 및 작동을
이해하고 인식하기 시작합니다.
이러한 구조 및 작동은 상위 레벨 CORBA 서비스 스펙(COM/DCOM 기반의 시스템에도 동일하게 잘 적용됨)을
통해 형식화되었습니다.
객체 관계형 맵핑에 대해 고려해야 할 적용 가능하고 유용한
CORBA 서비스 스펙은 다음과 같습니다.
다음 섹션에서는 이런 카테고리를 사용하여 공통 객체 관계형 서비스 설명을 구축합니다.
자세한 세부사항은 해당 CORBA 스펙을 참조하도록 독자에게 권장합니다.
지속성은 객체가 분리된 세션에 걸쳐 상태를 유지보수하기 위해
보조 저장영역 매체를 구현하는 방법을 설명하는 데 사용되는 용어입니다.
지속성은 사용자가 하나의 세션에 객체를 저장하고
이후의 세션에서 저장된 객체에 액세스할 수 있는 능력을 제공합니다.
객체가 이후에 액세스될 때 상태(예: 속성)는 이전 세션과 정확하게 동일합니다.
다중 사용자 시스템에서는 다른 사용자가 동일한 객체에 액세스하고 수정할 수 있으므로
사실상 이렇지 않을 수 있습니다.
지속성은 이 섹션에서 논의된 다른 서비스와 상호 관련됩니다.
관계, 동시성 및 기타에 대한 고려사항은 계획된 것입니다(그리고
서비스의 CORBA 분해와 일치).
다음은 지속성에 의해 제공되는 특정 서비스의 예입니다.
- 데이터 소스 연결 관리: 객체 관계형
어플리케이션은 실제 데이터 소스에 대한 연결을 초기화해야 합니다.
일반적으로 관계형 데이터베이스는 서버 및 데이터베이스의 식별을 필요로 합니다.
연결 관리의 세부사항은 데이터베이스 벤더에 특정한 경향이 있으며
프레임워크는 유연한 융통성 있는 방법으로 적절히 설계되어야 합니다.
- 객체 검색: 객체가 데이터베이스에서 복원될 때
데이터가 데이터베이스에 검색되고 객체로 변환됩니다.
이 프로세스는 데이터베이스 유형으로부터의 데이터를 적절한 객체 유형 및/또는 클래스로 정렬하고
해당 객체를 작성하며 특정 객체 속성을 설정하여
데이터 소스에서 검색된 데이터베이스 특정 구조로부터 추출한 데이터를 포함합니다.
- 객체 저장영역: 객체 저장영역의 프로세스는
객체 검색을 미러링합니다.
적절한 속성값이 객체에서 추출되고 데이터베이스 특정 구조가 속성값을 통해 작성(이것은
SQL 문자열, 스토어드 프로시저 또는 특수 원격 프로시저 호출일 수 있음)되어
그 구조가 데이터베이스에 제출됩니다.
- 객체 삭제: 시스템 내에서 삭제된 객체는
연관된 데이터가 관계형 데이터베이스에서 삭제되도록 해야 합니다.
객체를 삭제하려면 해당 정보가 객체에서 추출되고 삭제 요청이 작성(이것은
SQL 문자열, 스토어드 프로시저 또는 특수 원격 프로시저 호출일 수 있음)되며
그 요청이 데이터베이스에 제출되어야 합니다.
동일한 언어(예: Smalltalk 및 Java)에서는
명시적 삭제가 지원되지 않는 대신 가비지 콜렉션이라는
전략이 지원됩니다.
이런 언어를 지원하는 지속성 프레임워크는
어플리케이션이 더 이상 데이터를 참조하지 않는 경우
데이터베이스에서 데이터를 제거할 수 있는 대안을 제공해야 합니다.
한 가지 일반적인 방법은 데이터베이스가 객체가 다른 객체에서 참조된 횟수의
참조 계수를 유지보수하는 것입니다.
객체에 대한 참조 계수가 0으로 떨어지면
다른 객체가 더 이상 그 객체를 참조하지 않고
삭제될 수도 있습니다.
참조 계수가 0이면 객체가 더 이상 참조되지 않으므로
객체를 삭제하도록 승인될 수 있고 계속 조회될 수 있습니다.
객체 삭제가 허용되는 시기에 대한 전체 데이터베이스 정책이 여전히 필요합니다.
지속적 객체 저장영역은 객체를 검색하기 위한 메커니즘 없이는 거의 소용이 없습니다.
조회 기능은 어플리케이션이 다양한 기준에 따라
객체를 문의하고 검색할 수 있도록 합니다.
객체 관계형 맵핑 프레임워크에서 제공되는 기본 조회 조작은
find 및 find unique입니다.
find unique 조작은 특정 객체를 검색하고 find는 조회 기준을 기반으로 객체 콜렉션을 리턴합니다.
데이터 저장 조회 기능은 매우 다양합니다.
단순 파일 기반 데이터 저장이 고정된 자체 조회 조작을 구현하는 반면
관계형 시스템은 유연한 데이터 조작 언어를 제공합니다.
객체 관계형 맵핑 프레임워크는 데이터 중심보다는 객체 중심이 되도록 관계형 조회 모델을 확장합니다.
또한 pass-through 메커니즘이 관계형 조회 유연성 및 벤더 특정 확장(예: 스토어드 프로시저)을
이용하도록 구현됩니다.
데이터베이스 기반 조회 메커니즘과 객체 패러다임 사이에
약간의 잠재적인 충돌이 있습니다.
데이터베이스 조회 메커니즘은 테이블에서 속성(열)의 값으로 구동됩니다.
해당 객체에서 캡슐화 원칙으로 인해 속성값을 볼 수 없습니다.
속성은 클래스 조작에 따라 캡슐화됩니다.
캡슐화하는 이유는 어플리케이션을 변경하기 쉽게 하기 위해서입니다.
공개적으로 가시적인 클래스 조작이 변경되지 않는 한
종속되는 클래스를 고려하지 않고 클래스의 내부 구조를 변경할 수 있습니다.
데이터베이스를 기반으로 하는 조회 메커니즘은
효과적으로 캡슐화를 중단하는 클래스의 내부적 표시에 종속적입니다.
프레임워크에 대한 도전은 조회로 인해 어플리케이션이 변경에 불안정하게 되는 것을 방지합니다.
트랜잭션 지원은 어플리케이션 개발자가 원자 단위의 작업을 정의할 수 있게 합니다.
데이터베이스 용어에서 이것은 시스템이 데이터베이스에 변경사항 세트를 적용할 수 있어야 하거나
어떤 변경사항도 적용되지 않았음을 보장해야 한다는 것을 의미합니다.
트랜잭션 내의 조작은 모두가 성공적으로 실행되거나
트랜잭션이 전체적으로 실패합니다.
객체 관계형 프레임워크는 최소한 트랜잭션 커미트/롤백 기능과 같은
관계형 데이터베이스를 제공해야 합니다.
다중 사용자 환경에서 객체 관계형 프레임워크를 설계하는 것에는
많은 도전과 신중한 사고가 필요할 수 있습니다.
지속성 프레임워크에서 제공되는 기능 이외에
어플리케이션은 오류를 처리하는 방법에 대해 알아야 합니다.
트랜잭션이 실패하거나 중단될 때, 시스템은 일반적으로 데이터베이스에서
이전 상태 정보를 읽어서 트랜잭션의 상태를 안정된 이전 상태로
복원할 수 있어야 합니다. 따라서 지속성 프레임워크와 오류 처리 프레임워크 사이에 밀접한 상호 작용이 있습니다.
다중 사용자 객체 지향 시스템은 객체에 대한 동시 액세스를 제어해야 합니다.
많은 사용자가 동시에 객체에 액세스할 때 시스템은
지속적 저장소에 있는 객체 수정이 예측 가능하고 제어된 방법으로
이루어질 수 있도록 하는 메커니즘을 제공해야 합니다.
객체 관계형 프레임워크는 비관적 및/또는 낙관적 동시성 제어를 구현할 수 있습니다.
- 비관적 동시성 제어는 객체가 데이터 저장에서 검색될 때 어플리케이션 개발자가
본인의 의도(예: 읽기 전용, 쓰기 잠금 등)를 지정할 것을 요구합니다.
객체가 잠기면 다른 사용자는 객체에 액세스할 수 없고
잠금이 해지되기를 기다려야 할 수 있습니다.
비관적 동시성은 이것이 교착 상태 상황을 만들 수도 있다는 주의와 함께 사용되고 구현되어야 합니다.
- 낙관적 동시성 제어는 동일한 객체가 동시에 액세스되지 않는다고 가정합니다.
수정사항이 데이터베이스에 저장될 때 동시성 충돌이 발견됩니다.
일반적으로, 객체가 검색 이후 다른 사용자에 의해 수정되면
수정 조작 실패를 표시하는 오류가 어플리케이션에 리턴됩니다.
오류를 발견하고 처리하는 것은 어플리케이션의 책임입니다.
이것은 객체의 동시 값을 캐시하고 이 값을 데이터베이스에 비교하기 위해 프레임워크를 호출합니다.
동시성 충돌이 거의 없는 경우 낙관적 동시성에 비용이 덜 들지만
충돌의 수가 상당히 큰 경우 많은 비용이 듭니다(충돌 발생시 다시 작업해야 하므로).
공유 데이터를 사용하는 모든 어플리케이션은 동일한 동시성 전략을 사용해야 합니다.
동일한 공유 데이터에서 낙관적 및 비관적 동시성 제어를 혼합할 수 없습니다.
그렇지 않으면 손상이 발생할 수 있습니다.
일관된 동시성 전략에 대한 요구는
지속성 프레임워크를 통해 가장 잘 처리됩니다.
객체는 다른 객체와의 관계를 가집니다. 주문 객체에는 많은 품목 객체가 있습니다.
책 객체에는 많은 장 객체가 있습니다. 직원 객체는 정확하게 하나의 회사 객체에 속합니다.
관계형 모델에서 엔티티 간의 관계는 외부 키/1차 중요한 참조를 사용하여 구현됩니다.
객체 지향 시스템에서 관계는 보통 속성을 통해 명시적으로 구현됩니다. 주문 객체에
LineItems가 있는 경우 주문은 lineItems라는 속성을 포함합니다.
주문의 lineItems 속성은 많은 품목 객체를 포함합니다.
객체 지향 프레임워크의 관계 측면은
지속성, 트랜잭션 및 조회 서비스와 상호 의존합니다.
객체를 저장, 검색, 처리 또는 조회할 때
관련 객체에 고려사항을 제공해야 합니다.
- 객체가 검색될 때, 연관 객체도 검색되어야 합니까?
간단히 말하면 예라고 답할 수 있지만
필요하지 않은 연관 객체가 매우 비싼 경우는 여기에서 제외됩니다.
좋은 프레임워크는 전략의 혼합을 허용합니다.
- 객체가 저장될 때, 연관 객체가 변경된 경우 연관 객체도 저장되어야 합니까?
다시 말하자면, 응답은 컨텍스트에 따라 다릅니다.
공통 객체 관계형 서비스를 별도로 고려하는 것이 개념적으로 유용하지만
객체 관계형 프레임워크 구현은 상호 의존적입니다.
서비스는 개별 조직에서 뿐 아니라 동일한 데이터를 공유하는 모든 어플리케이션에서
일관적으로 구현되어야 합니다.
프레임워크는 이것을 달성하기 위한 유일한 경제적인 방법입니다.
|