개념: 관계형 데이터베이스 및 객체 지향
이 개념은 오브젝트 모델 및 관계형 데이터 모델의 개요를 제공하고 지속성 프레임워크의 요약 설명을 제공합니다.
관계
기본 설명

소개

이 개념 문서는 오브젝트 모델 및 관계형 데이터 모델의 개요를 제공하고 지속성 프레임워크의 요약 설명을 제공합니다.

관계형 데이터베이스 및 객체 지향

관계형 데이터베이스와 객체 지향은 완전히 호환 가능하지 않습니다. 관계형 데이터베이스와 객체 지향은 서로 다른 두 가지의 관점을 표시하는데, RDBMS에서는 데이터만 표시되고 객체 지향 시스템에서는 동작만 표시됩니다. 하나의 관점이 다른 관점보다 낫다고 할 수는 없습니다. 객체 지향 모델은 데이터가 보조적인 상태 특정 동작 및 복잡한 동작을 가지고 있는 시스템이나, 자연적 계층 구조(예: 명세서)에서 탐색하여 데이터에 액세스하는 시스템에 제대로 작동하는 경향이 있습니다. RDBMS 모델은 관계가 동적 또는 임시적인 시스템과 보고서를 작성하는 응용프로그램에 잘 맞습니다.

중요한 점은 많은 정보가 관계형 데이터베이스에 저장된다는 것으로, 객체 지향 응용프로그램이 데이터에 액세스하려고 할 경우 RDBMS에 대해 읽고 쓸 수 있어야 합니다. 또한 객체 지향 시스템은 종종 객체 지향이 아닌 시스템과 데이터를 공유해야 합니다. 따라서 공유 메커니즘으로 RDBMS를 사용하는 것은 자연스러운 것입니다.

객체 지향 및 관계형 디자인이 일부 공통적인 특성을 공유하지만(오브젝트 속성은 개념적으로 엔티티 열과 유사함) 근본적인 차이로 인해 매끄러운 통합이 어려워집니다. 근본적인 차이는, 데이터 모델은 데이터를 노출하고(열 값을 통해) 오브젝트 모델은 데이터를 숨긴다는 것입니다(public 인터페이스 뒤에서 캡슐화).

관계형 데이터 모델

관계형 모델은 엔티티 및 관계로 구성됩니다. 엔티티는 실제 테이블이거나 또는 뷰라고도 하는 몇몇 테이블의 논리적 투영일 수 있습니다. 아래에 있는 그림은 LINEITEM, ORDER 및 PRODUCT 테이블과 이 테이블 사이의 다양한 관계를 보여줍니다. 관계 모델에는 다음과 같은 요소가 있습니다.

다이어그램은 컨텐츠에 자세히 설명되어 있습니다.

관계형 모델

엔티티에는 열이 있습니다. 각 열은 이름 및 유형으로 식별됩니다. 위의 그림에서, LINEITEM 엔티티에는 LineItem_Id(1차 키), 설명, 가격, 수량, Product_Id 및 Order_Id 열이 있습니다(끝으로 두 개의 열은 LINEITEM 엔티티를 ORDER 및 PRODUCT 엔티티에 링크하는 외부 키임).

엔티티에는 레코드나 행이 있습니다. 각 행은 일반적으로 오브젝트의 지속적 데이터를 표시하는 고유한 정보 세트를 표시합니다.  

각 엔티티에는 하나 이상의 1차 키가 있습니다. LineItem_Id는 LINEITEM의 1차 키입니다.

관계 지원은 벤더마다 다릅니다. 예제는 PRODUCT 및 LINEITEM 테이블 사이의 관계와 논리적 모델을 보여줍니다. 실제 모델에서, 관계는 일반적으로 외부 키 / 1차 키 참조를 사용하여 구현됩니다. 하나의 엔티티가 다른 엔티티에 관련되어 있을 경우, 외부 키인 열이 포함됩니다. 외부 키 열에는 엔티티의 특정 레코드를 관련된 엔티티에 관련시킬 수 있는 데이터가 있습니다.

관계에는 다중성(카디널리티라고도 함)이 있습니다. 공통되는 카디널리티는 일 대 일(1:1), 일 대 다수(1:m), 다수 대 일(m:1) 및 다수 대 다수(m:n)입니다. 예제에서, LINEITEM은 PRODUCT와의 1:1 관계를 가지고 있고 PRODUCT는 LINEITEM과의 0:m 관계를 갖습니다.

오브젝트 모델

그 중에서도 특히 오브젝트 모델에는 클래스가 있습니다(오브젝트 모델의 완전한 정의는 [UML01] 참조). 클래스는 오브젝트 세트의 구조 및 동작(간혹 오브젝트 인스턴스라고 함)을 정의합니다. 구조는 속성(데이터 값) 및 연관(클래스 사이의 관계)으로 표시됩니다. 다음 그림은 클래스의 속성(데이터)만 표시하는 단순 클래스 다이어그램을 보여줍니다.

다이어그램은 컨텐츠에 자세히 설명되어 있습니다.

오브젝트 모델(클래스 다이어그램)

주문은 숫자(주문 번호)와 하나 이상의(1..*) 품목에 대한 연관을 가지고 있습니다. 각각의 품목에는 수량(주문된 수량)이 있습니다.

오브젝트 모델은 상속을 지원합니다. 클래스는 다른 클래스로부터 데이터 및 동작을 상속합니다(예: SoftwareProduct 및 하드웨어 제품 제품은 Product 클래스에서 속성과 메소드를 상속함).

지속성 프레임워크

대부분의 비즈니스 응용프로그램은 관계형 기술을 실제 데이터 스토어로 이용합니다. 객체 지향 응용프로그램 개발자가 직면하는 문제는 데이터 모델의 변경사항이 오브젝트 모델을 "위반"하지 않도록 관계형 데이터베이스를 충분히 분리하여 캡슐화하는 것입니다(그 반대로도 마찬가지 임). 응용프로그램이 직접 관계형 데이터에 액세스하도록 하는 많은 솔루션이 존재합니다. 문제는 오브젝트 모델과 데이터 모델 사이의 매끄러운 통합을 이루는 것입니다.

데이터베이스 API는 표준 형태(예: 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 등). 게다가, 액세스 계층 프레임워크 디자인의 기본적인 부분을 노출하고 문서화하여 확장성을 촉진해야 합니다.
  • 공통되는 오브젝트 관계 맵핑 지원. 액세스 계층은 확장하지 않고도 기본적인 오브젝트 관계 맵핑에 대한 지원을 제공해야 합니다. 오브젝트 관계 맵핑은 이 문서의 나중 부분에 있는 섹션에 자세히 설명되어 있습니다.
  • 지속성 인터페이스: 객체 지향 응용프로그램에서, 오브젝트 응용프로그램의 비즈니스 모델은 문제점 도메인의 시맨틱 지식을 캡처합니다. 개발자는 데이터 저장 및 검색 세부사항에 대해 별다른 우려없이 오브젝트를 조작하고 오브젝트와 상호작용해야 합니다. 제대로 정의된 지속적 인터페이스 서브세트(저장, 삭제, 찾기)가 응용프로그램 개발자에게 제공되어야 합니다.

공통되는 오브젝트 관계 서비스

오브젝트 관계 응용프로그램에 대해 공통 패턴이 나타나고 있습니다. 단절된 부분을 반복적으로 가로지른 IT 전문가는 성공적인 오브젝트 관계 응용프로그램이 제시하는 특정의 구조 및 동작을 이해하고 인식하기 시작하고 있습니다. 이 구조와 동작은 상위 레벨의 CORBA 서비스 스펙(COM/DCOM 기반 시스템에 동일하게 제대로 적용되는 스펙)에 의해 정식화되었습니다.

오브젝트 관계 맵핑에 대해 고려할 적용 가능하고 유용한 CORBA 서비스 스펙은 다음과 같습니다.

다음 섹션은 이 카테고리를 사용하여 공통 오브젝트 관계 서비스의 설명을 구조화합니다. 추가 세부사항을 보려면 적절한 CORBA 스펙을 참조하십시오.

지속성

지속성은 오브젝트가 보조 저장 매체를 이용하여 분리된 세션들 사이에 상태를 유지하는 방법을 설명하는 데 사용되는 용어입니다. 지속성은 사용자에게 하나의 세션에서 오브젝트를 저장하고 나중 세션에서 그 오브젝트에 액세스할 수 있는 능력을 제공합니다. 그 뒤로 오브젝트에 액세스할 경우, 상태(예: 속성)는 정확히 이전 세션에서와 같게 됩니다. 다중 사용자 시스템에서는 다른 사용자가 동일 오브젝트에 액세스하여 수정할 수 있으므로 이와 같이 되지 않을 수도 있습니다. 지속성은 이 섹션에 설명된 다른 서비스와 밀접한 관련이 있습니다. 관계, 동시성 및 기타 서비스 고려도 계획됩니다(서비스의 CORBA 분해와도 일치함).

지속성에서 제공되는 특정 서비스 예는 다음과 같습니다.

  • 데이터 소스 연결 관리: 오브젝트 관계 응용프로그램은 실제 데이터 소스와의 연결을 초기화해야 합니다. 관계형 데이터베이스 시스템은 일반적으로 서버 및 데이터베이스의 식별을 필요로 합니다. 연결 관리의 특정사항은 데이터베이스 벤더에 고유한 경향이 있으므로 프레임워크는 이에 따라 유연하고 호의적인 방식으로 디자인해야 합니다.
  • 오브젝트 검색: 데이터베이스에서 오브젝트를 복원할 때 데이터는 데이터베이스에서 검색된 후 오브젝트로 변환됩니다. 이 프로세스에는 데이터 소스에서 검색된 데이터베이스 특정 구조로부터 데이터 추출, 데이터베이스 유형에서 적절한 오브젝트 유형 및/또는 클래스로 데이터 정렬, 적절한 오브젝트 작성, 특정 오브젝트 속성 설정이 포함됩니다.
  • 오브젝트 저장: 오브젝트 저장 프로세스는 오브젝트 검색을 미러링합니다. 오브젝트에서 적절한 속성 값이 추출되고, 속성 값(SQL 문자열, 스토어드 프로시저 또는 특수 원격 프로시저 호출)으로 데이터베이스 특정 구조가 작성되며, 데이터베이스에 구조가 제출됩니다.
  • 오브젝트 삭제: 시스템에서 삭제된 오브젝트는 연관된 데이터도 관계형 데이터베이스에서 삭제해야 합니다. 오브젝트 삭제에서는 오브젝트에서 적절한 정보가 추출되고, 삭제 요청이 생성되며(SQL 문자열, 스토어드 프로시저 또는 특수 원격 프로시저 호출(RPC)), 데이터베이스에 요청이 제출되어야 합니다. 어떤 언어(예: Smalltalk 및 Java)에서는 명시적 삭제가 지원되지 않습니다. 대신 가비지 콜렉션이라고 하는 전략이 지원됩니다. 이 언어를 지원하는 지속성 프레임워크는 응용프로그램이 더 이상 데이터를 참조하지 않을 경우 데이터베이스에서 데이터를 제거하는 대체 방법을 제공해야 합니다. 한 가지의 공통되는 방법은 데이터베이스가 다른 오브젝트에서 오브젝트를 참조하는 횟수의 reference-counts를 유지보수하도록 하는 것입니다. 오브젝트의 참조 계수가 0이 되면 다른 오브젝트는 그 오브젝트를 참조하지 않으므로 삭제할 있습니다. 오브젝트가 더 이상 참조되지 않을 경우에도 계속 오브젝트를 조회할 수 있으므로, 참조 계수가 0인 오브젝트를 삭제하는 것은 허용 가능할 수 있습니다. 오브젝트 삭제가 허용될 경우에 대한 데이터베이스 전체의 정책이 여전히 필요합니다.

조회

지속적 오브젝트 저장은 특정 오브젝트를 검색하기 위한 메커니즘 없이는 거의 사용되지 않습니다. 조회 기능을 통해 응용프로그램은 다양한 기준을 기반으로 오브젝트를 확인하여 검색할 수 있습니다. 오브젝트 관계 맵핑 프레임워크에서 제공되는 기본 조회 오퍼레이션은 find와 find unique입니다. find unique 오퍼레이션은 특정 오브젝트를 검색하고 find는 조회 기준을 기반으로 오브젝트 콜렉션을 리턴합니다.

데이터 스토어 조회 기능은 다양합니다. 단순한 파일 기반 데이터 스토어는 자체 개발된(home-grown) 엄격한 조회 오퍼레이션을 구현할 수 있지만, 관계형 시스템은 유연한 데이터 조작 언어를 제공합니다. 오브젝트 관계 맵핑 프레임워크는 관계형 조회 모델을 확장하여 데이터 중심이 아닌 오브젝트 중심 모델로 만듭니다. 관계형 조회 유연성 및 벤더 특정 확장(예: 스토어드 프로시저)을 가져오기 위해 통과(pass-through) 메커니즘도 구현됩니다.

데이터베이스 기반 조회 메커니즘과 오브젝트 패러다임 사이에 충돌할 가능성이 있습니다. 데이터베이스 조회 메커니즘은 테이블에 있는 속성(열)의 으로 구동됩니다. 해당되는 오브젝트에서, 캡슐화의 원리에 의해 속성 값을 보지 못하도록 금지됩니다. 속성 값은 클래스 오퍼레이션에 의해 캡슐화됩니다. 캡슐화하는 이유는 응용프로그램을 쉽게 변경시킬 수 있기 때문입니다. 공통적으로 볼 수 있는 클래스의 오퍼레이션이 변경되지 않는 한 종속 클래스에 대한 우려 없이 클래스의 내부 구조를 변경할 수 있습니다. 데이터베이스를 기반으로 하는 조회 메커니즘은 클래스의 내부 표시에 종속됩니다(특히, 캡슐화 중단). 프레임워크에 대한 도전은 조회로 인해 응용프로그램이 변경에 대해 불안하게 되는 일이 없도록 하기 위해서입니다.

트랜잭션

트랜잭션 방식 지원으로 응용프로그램 개발자는 작업의 원자 단위를 정의할 수 있습니다. 데이터베이스 용어에서, 이는 시스템이 변경 세트를 데이터베이스에 적용할 수 있어야 함을 의미합니다. 그렇지 않으면 어떤 변경사항도 적용되지 않도록 해야 합니다. 트랜잭션 내의 오퍼레이션은 모두 성공적으로 실행되거나 그렇지 않으면 트랜잭션이 전체적으로 실패합니다. 오브젝트 관계 프레임워크는 최소한 관계형 데이터베이스와 유사한 확약/롤백 트랜잭션 기능을 제공해야 합니다. 다중 사용자 환경에서 오브젝트 관계 프레임워크를 디자인할 경우 많은 문제가 존재할 수 있으므로 주의해야 합니다.

지속성 프레임워크에서 제공하는 기능 외에도, 응용프로그램은 오류 처리 방법을 이해해야 합니다. 트랜잭션이 실패하거나 중단될 경우, 시스템은 상태를 안정된 이전 상태로 복원할 수 있어야 합니다(보통 데이터베이스에서 이전 상태 정보를 읽어서 복원함). 따라서, 지속성 프레임워크와 오류 처리 프레임워크 사이에는 밀접한 상호작용이 있습니다.

동시성

다중 사용자 객체 지향 시스템은 오브젝트에 대한 동시 액세스를 제어해야 합니다. 많은 사용자가 동시에 오브젝트에 액세스할 경우, 시스템은 지속적 저장소에서의 오브젝트 수정사항이 예측 가능하고 제어를 받는 방식으로 발생하도록 하는 메커니즘을 제공해야 합니다. 오브젝트 관계 프레임워크는 비관적 및/또는 낙관적 동시성 제어를 구현할 수 있습니다.

  • 비관적 동시성 제어에서는 데이터 스토어에서 오브젝트를 검색할 때 응용프로그램 개발자가 목적을 지정해야 합니다(예: 읽기 전용, 쓰기 잠금 등). 오브젝트가 잠기면, 다른 사용자는 오브젝트에 액세스할 때 차단되어 잠금을 포기할 때까지 기다려야 할 수도 있습니다. 비관적 동시성은 교착 상태 상황을 발생시킬 수 있으므로 주의하여 사용하고 구현해야 합니다.
  • 낙관적 동시성 제어는 동일 오브젝트가 동시에 액세스할 가능성이 없다고 가정합니다. 수정사항이 데이터베이스에 저장될 때 동시성 충돌이 발견됩니다. 일반적으로, 검색 이후에 다른 사용자가 오브젝트를 수정한 경우, 수정 조작의 실패를 표시하는 오류가 응용프로그램에 리턴됩니다. 오류를 발견하고 처리하는 것은 응용프로그램의 책임입니다. 프레임워크가 오브젝트의 동시 값을 캐시하고 데이터베이스에 대해 값을 비교하도록 요구합니다. 낙관적 동시성은 동시성 충돌이 적을 경우 비용이 적게 들지만 충돌 횟수가 많을 경우 많은 비용이 듭니다(충돌이 발생할 때 다시 수행해야 하기 때문임).

공유 데이터를 사용하는 모든 응용프로그램은 동일한 동시성 전략을 사용해야 합니다. 동일한 공유 데이터에서는 낙관적 및 비관적 동시성 제어를 혼합하여 사용할 수 없습니다. 그렇지 않으면 손상될 수 있습니다. 일관된 동시성 전략의 요구는 지속성 프레임워크를 통해 가장 잘 처리됩니다.

관계

오브젝트는 다른 오브젝트와의 관계를 가지고 있습니다. 주문 오브젝트는 많은 품목 오브젝트를 가지고 있습니다. 서적 오브젝트는 많은 장 오브젝트를 가지고 있습니다. 직원 오브젝트는 정확하게 하나의 회사 오브젝트에 속합니다. 관계형 시스템에서, 엔티티 사이의 관계는 외부 키 / 1차 키 참조를 사용하여 구현됩니다. 객체 지향 시스템에서, 관계는 보통 속성으로 통해 명확하게 구현됩니다. 주문 오브젝트에 품목이 있을 경우, 주문에는 품목이라는 속성 이름이 포함됩니다. 주문의 품목 속성에는 많은 품목 오브젝트가 포함됩니다.

오브젝트 관계 프레임워크의 관계 측면은 지속성, 트랜잭션 및 조회 서비스와는 독립적입니다. 오브젝트를 저장, 검색, 처리 또는 조회할 경우 해당되는 관련 오브젝트를 고려해야 합니다.

  • 오브젝트를 검색할 때, 연관된 오브젝트도 검색해야 합니까? 이에 대한 대답은 간단히 예입니다. 하지만 연관된 오브젝트가 필요하지 않을 때 연관된 오브젝트도 검색하면 비용이 많이 소비됩니다. 좋은 프레임워크에서는 전략을 혼합할 수 있습니다.
  • 오브젝트를 저장할 때, 연관된 오브젝트가 변경된 경우 연관된 오브젝트도 저장해야 합니까? 마찬가지로, 대답은 상황에 따라 다릅니다.

공통되는 오브젝트 관계 서비스를 별도로 고려하는 것이 개념적으로 이득이지만 오브젝트 관계 프레임워크 구현은 종속 관계가 됩니다. 서비스는 개인 조직 뿐만 아니라 같은 데이터를 공유하는 모든 응용프로그램에서 일관성있게 구현해야 합니다. 프레임워크는 이를 달성하기 위한 유일한 경제적 방법입니다.