객체-관계 임피던스 불일치

Object–relational impedance mismatch

오브젝트-관계 임피던스 미스매치는 RDBMS(Relational Database Management System)가 오브젝트 지향 프로그래밍 언어 또는 스타일로 작성된 응용 프로그램(또는 여러 응용 프로그램)에 의해 서비스될 때 자주 발생하는 개념적 및 기술적 어려움의 집합입니다.특히 오브젝트 또는 클래스가 다음과 같이 정의되기 때문입니다.initions는 관계형 스키마에 의해 정의된 데이터베이스 테이블에 매핑해야 합니다.

객체-관계 임피던스 불일치라는 용어는 전기공학 용어 임피던스 매칭에서 파생되었습니다.

불일치

오브젝트(인스턴스)는 서로 참조하기 때문에 수학적 의미(루프와 사이클을 포함한 네트워크)에서 Directed 그래프를 형성합니다.반면 관계형 스키마는 표 형식이며 관계형 대수에 기반하여 링크된 이기종 튜플(데이터 필드의 그룹화 각 필드의 유형이 다른 '행')을 정의합니다. 여기서 링크는 항상 되돌릴 수 있습니다(INNER JOIN은 대칭이므로 외부 키를 거꾸로 따를 수 있음). 이는 Undirecte에 더 가까운 특성입니다.d그래프

객체 지향 개념

캡슐화

객체 지향 프로그램은 내부 표현을 숨길 수 있는 캡슐화된 객체를 생성하는 기술로 설계됩니다.객체 지향 프레임워크에서, 주어진 객체의 기본 속성은 객체와 함께 구현된 인터페이스 이외의 인터페이스에 노출되지 않을 것으로 예상된다.단, 대부분의 객체-관계 매핑접근법에서는 객체의 기본 콘텐츠를 노출하여 객체 구현에서 지정할 수 없는 인터페이스와 상호 작용합니다.따라서 이 오브젝트 관계 매핑은 오브젝트의 캡슐화를 위반합니다.이는 많은 오브젝트 관계 맵퍼가 데이터베이스 열에 대응하는 퍼블릭필드를 자동으로 생성하기 때문입니다.일부 프레임워크는 대신 메타프로그래밍 기술을 사용하기 때문에 캡슐화 위반을 방지합니다.

접근성

관계형 사고에서 "개인" 접근 대 "공공" 접근은 요구에 비례합니다.객체 지향(OO) 모델에서는 데이터 상태의 절대적인 특성입니다.관계형 및 OO 모델은 종종 상대성 대 분류 및 특성의 절대성에 대한 갈등을 겪습니다.

인터페이스, 클래스, 상속 및 다형성

오브젝트 지향 패러다임 하에서 오브젝트에는 그 오브젝트의 내부에만 접근할 수 있는 인터페이스가 있습니다.반면 관계모델은 파생된 관계변수(뷰)를 활용하여 다양한 관점과 제약조건을 제공하여 무결성을 확보한다.마찬가지로 객체 클래스, 상속 및 다형성에 대한 필수 OOP 개념은 관계형 데이터베이스 시스템에서 지원되지 않습니다.

관계 개념에 대한 매핑

관계형 데이터베이스 테이블이 객체 지향 분석에서 발견된 어소시에이션에 링크되어 있는 경우[further explanation needed] 관계형 개념과 객체 지향 개념 간의 적절한 매핑이 이루어질 수 있습니다.

데이터 유형의 차이

기존 관계형 언어와 OO 언어 간의 주요 불일치는 유형 시스템의 차이입니다.관계형 모델은 참조별 속성(또는 포인터)을 엄격히 금지하지만, OO 언어는 참조별 동작을 수용하고 예상합니다.스칼라 타입과 그 연산자 시멘틱스는 모델마다 크게 다르므로 매핑에 문제가 발생할 수 있습니다.

예를 들어, 대부분의 SQL 시스템은 조합이 다양하고 최대 길이가 제한된 문자열 유형을 지원하는 반면(오픈 엔드 텍스트 유형은 성능을 저해하는 경향이 있음) 대부분의 OO 언어는 정렬을 루틴을 정렬하기 위한 인수로 간주하며 문자열은 본질적으로 사용 가능한 메모리에 맞게 크기가 지정됩니다.좀 더 미묘하지만 관련성이 있는 예는 SQL 시스템이 비교를 위해 문자열의 후행 공백을 무시하는 경우가 많은 반면, OO 문자열 라이브러리는 그렇지 않다는 것입니다.일반적으로 OO 언어에서 다른 원시 유형의 가능한 값을 제한하는 문제로서 새로운 데이터 유형을 구성할 수 없습니다.

구조 및 무결성 차이

또 다른 불일치는 대조된 모델의 구조적 측면과 무결성 측면의 차이와 관련이 있다.OO 언어에서 객체는 다른 객체로 구성되거나(종종 높은 수준까지) 보다 일반적인 정의에서 전문화될 수 있습니다.이로 인해 관계형 스키마로의 매핑이 간단하지 않을 수 있습니다.이는 관계 데이터가 명명된 글로벌 비내포 관계 변수 집합에 나타나는 경향이 있기 때문입니다.관계 자체는 모두 동일한 헤더에 부합하는 튜플 집합이므로(태플 관계 미적분 참조) OO 언어에는 이상적인 대응 요소가 없습니다.OO 언어의 제약조건은 일반적으로 그렇게 선언되지 않지만, 캡슐화된 내부 데이터에 대해 동작하는 코드를 둘러싼 보호 논리를 예외적으로 제기하는 것으로 나타난다.한편, 관계 모델에서는 스칼라 타입, 속성, 관계 변수 및 데이터베이스 전체에 대한 선언적 제약이 요구됩니다.

조작상의 차이

그러나, 의미적 차이는 대조된 모델의 조작적 측면에서 특히 뚜렷하다.관계형 모델에는 데이터 쿼리 및 조작에 사용하기 위한 고유하고 비교적 작고 잘 정의된 원시 연산자 집합이 있는 반면, OO 언어는 일반적으로 맞춤형 또는 하위 수준, 사례 및 물리적 액세스 경로별 필수 연산을 통해 쿼리와 조작을 처리합니다.일부 OO 언어는 선언적 쿼리 하위 언어를 지원하지만, OO 언어는 일반적으로 목록과 해시 테이블을 다루기 때문에 조작적 프리미티브는 관계형 [citation needed]모델의 집합 기반 연산과 반드시 구별됩니다.

트랜잭션의 차이

동시성과 트랜잭션 측면도 크게 다릅니다.특히, 데이터베이스에 의해 수행되는 최소 작업 단위인 트랜잭션은 관계형 데이터베이스에서 OO 언어 클래스에서 수행되는 작업보다 훨씬 큽니다.관계형 데이터베이스의 트랜잭션은 동적으로 제한된 임의 데이터 조작 집합인 반면, OO 언어의 트랜잭션 입도는 일반적으로 원시 유형 필드에 대한 개별 할당 수준입니다.일반적으로, OO언어는 고립이나 내구성의 유사성이 없기 때문에 원자성과 일관성은 그러한 원시적인 유형의 필드에 쓸 때만 보장된다.

임피던스 미스매치 해결

오브젝트 지향 프로그램의 임피던스 미스매치 문제에 대한 대처는 사용되는 특정 논리 시스템의 차이를 인식하는 것으로 시작됩니다.그런 다음 [1]불일치를 최소화하거나 보상합니다.

대체 아키텍처

객체-관계 임피던스 불일치 문제는 OO와 데이터베이스 간의 보편적인 문제가 아닙니다.이름에서 알 수 있듯이 이 임피던스 문제는 관계형 데이터베이스에서만 발생합니다.이 문제에 대한 가장 일반적인 해결책은 NoSQL 또는 XML 데이터베이스와 같은 대체 데이터베이스를 사용하는 것입니다.

최소화

임피던스 미스매치 문제를 회피하기 위해 객체 지향 데이터베이스 관리 시스템(OODBMS)을 구축하려는 시도가 있었습니다.그러나 데이터 모델의 [2]기초로서 OOO 원칙의 한계 때문에 관계형 데이터베이스보다 실무적으로 성공하지 못했다.트랜잭션 메모리 등의 개념을 통해 OO언어의 데이터베이스적 기능을 확장하기 위한 연구가 이루어지고 있습니다.

임피던스 미스매치 문제에 대한 일반적인 해결책 중 하나는 도메인과 프레임워크 로직을 레이어하는 것입니다.이 체계에서 OO 언어는 보다 정적 매핑을 시도하는 대신 런타임에 특정 관계 측면을 모델링하는 데 사용됩니다.이 방법을 사용하는 프레임워크는 일반적으로 "데이터셋" 컴포넌트의 "행" 또는 일반 "엔티티 인스턴스" 클래스와 관계에 대한 아날로그뿐만 아니라 튜플에 대한 아날로그를 가집니다.이 접근방식의 장점은 다음과 같습니다.

  • 도메인 데이터의 전송, 프레젠테이션 및 검증을 중심으로 프레임워크와 자동화를 구축하는 간단한 경로.
  • 코드 사이즈가 작아 컴파일 및 로드 시간이 단축됩니다.
  • 스키마를 동적으로 변경할 수 있습니다.
  • 네임스페이스와 시멘틱의 불일치 문제를 회피합니다.
  • 표현적 제약조건 체크
  • 복잡한 매핑 불필요

단점은 다음과 같습니다.

  • 정적 유형 "안전" 점검이 없습니다.이를 완화하기 위한 한 가지 방법으로 유형화된 접근기가 사용될 수 있습니다.
  • 런타임 구축 및 액세스에 따른 가능한 성능 비용입니다.
  • 다형성 등 고유한 OO 측면을 기본적으로 활용할 수 없습니다.

보상

OO 애플리케이션 코드 내에서 담화 수준이 혼합되면 문제가 발생하지만, 이를 보완하기 위해 사용되는 몇 가지 일반적인 메커니즘이 있다.가장 큰 과제는 도메인 데이터가 모델링되는 담화 수준 내에서 프레임워크 지원, 데이터 조작 및 프레젠테이션 패턴의 자동화를 제공하는 것입니다.이를 해결하기 위해 반사 및/또는 코드 생성을 이용한다.반사를 통해 코드(클래스)를 데이터로 처리할 수 있으므로 데이터의 전송, 표시, 무결성 등을 자동화할 수 있습니다.생성은 엔티티 구조를 코드 생성 도구 또는 메타 프로그래밍 언어에 대한 데이터 입력으로 처리함으로써 문제를 해결합니다. 이 툴은 클래스를 생성하고 인프라를 지원하는 기능을 일괄적으로 제공합니다.이 두 가지 계획 모두 이러한 수준의 담론이 합쳐지는 특정 이상 징후가 여전히 나타날 수 있다.예를 들어 생성된 엔티티 클래스는 일반적으로 도메인에 매핑되는 속성(예: 이름, 주소)과 상태 관리 및 기타 프레임워크 인프라를 제공하는 속성(예: IsModified)을 가집니다.

발생.

오브젝트-관계 임피던스 미스매치는 일반적으로 오브젝트 지향 프로그래밍에서 발생할 수 있지만 특정 난이도는 오브젝트 관계 매퍼(ORM)[3]에서 발생합니다.ORM은 설정, 주석 및 제한된 도메인 고유의 언어로 지정되는 경우가 많기 때문에 임피던스 불일치를 해결하기 위한 완전한 프로그래밍 언어의 유연성이 부족합니다.

컨텐션

Christopher J. Date 등의 주장에 따르면 도메인과 클래스는 본질적으로 동일하기 때문에 진정한 관계형 DBMS는 그러한 [4][5][6]문제를 일으키지 않는다.클래스와 관계 스키마 간의 네이티브 매핑은 기본적인 설계 [7]실수입니다.데이터베이스 테이블(관계) 내의 개별 튜플은 복잡한 엔티티 자체의 표현이 아니라 엔티티 간의 관계를 확립하는 것으로 간주해야 합니다.그러나 이 견해는 객체 지향 프로그래밍의 영향과 역할을 감소시키는 경향이 있으며, 이를 필드 유형 관리 시스템에 지나지 않습니다.

임피던스 미스매치는 도메인오브젝트와 사용자 인터페이스 간의 프로그래밍에서 발생합니다.오퍼레이터, 매니저 및 기타 비프로그래머가 데이터베이스 내의 레코드에 액세스하여 조작할 수 있도록 고도의 사용자 인터페이스를 구축하려면 다양한 데이터베이스 속성(이름 및 유형 외)의 특성에 대한 깊은 지식이 필요한 경우가 많습니다.특히, (최종 사용자의 생산성 관점에서) UI가 데이터베이스 제약 조건을 위반하는 부정 트랜잭션의 입력을 방지하도록 사용자 인터페이스를 설계하는 것이 좋습니다.그러기 위해서는 관계형 스키마에 존재하는 논리의 대부분을 코드에 복제해야 합니다.

특정 코드 개발 프레임워크는 데이터베이스의 스키마에서 표현되는 특정 형태의 논리(참조 무결성 제약 등)를 활용할 수 있으므로 이러한 문제는 케이스 바이 케이스로 작성된 애드혹 코드가 아닌 라이브러리 루틴을 통해 일반적이고 표준적인 방식으로 처리됩니다.

SQL은 매우 제한된 도메인 유형(및 기타 알려진 결함)으로 인해 적절한 개체와 도메인 모델링을 어렵게 만들고, SQL은 DBMS와 애플리케이션 프로그램(개체 지향 스타일로 작성되었는지 여부에 관계없이) 간에 매우 손실되고 비효율적인 인터페이스를 구성한다는 주장이 제기되어 왔습니다.단, SQL은 현재 시장에서[citation needed] 유일하게 널리 받아들여지고 있는 공통 데이터베이스 언어입니다.벤더 고유의 쿼리 언어를 사용하는 것은 피할 수 있는 경우 좋지 않은 관행으로 간주됩니다.Business System 12 및 Tutorial D와 같은 다른 데이터베이스 언어가 제안되었지만 DBMS 공급업체에서 널리 채택된 언어는 없습니다.

Oracle 및 Microsoft SQL Server와 같은 주류 "개체 관계형" DBMS의 현재 버전에서는 위의 사항이 문제가 되지 않을 수 있습니다.이러한 엔진을 사용하면 최신 OO 언어(Java for Oracle, Microsoft)로 작성된 저장된 코드(기능 및 절차)를 통해 특정 데이터베이스의 기능을 임의로 확장할 수 있습니다.SQL Server용 NET 언어) 및 이러한 함수는 SQL 문에서 투명한 방식으로 차례로 호출할 수 있습니다. 즉, 사용자는 이러한 함수/프로시저가 원래 데이터베이스 엔진의 일부가 아님을 알지도, 신경도 쓰지 않습니다.최신 소프트웨어 개발 패러다임은 완전히 지원되므로 여러 데이터베이스 스키마에서 재사용할 수 있는 라이브러리 루틴 세트를 만들 수 있습니다.

이 공급업체들은 SQL에 절차적 구조를 추가하려는 ISO SQL-99 위원회의 시도에도 불구하고 SQL은 오늘날의 애플리케이션 프로그래머들이 당연하게 여기는 풍부한 라이브러리 및 데이터 구조를 갖지 못할 것이며, DBMS 백엔드에서 OO 언어 통합을 지원하기로 결정했습니다.e 코어 SQL 언어를 확장하지 않고 가능한 한 직접 실행할 수 있습니다.그 결과, 「어플리케이션 프로그래밍」과 「데이터베이스 관리」의 차이는 불명확하게 되어 있습니다.즉, 제약이나 트리거등의 기능의 견고한 실장에는, DBA/OO 프로그래밍 스킬을 2개 갖춘 개인이나, 이러한 스킬을 조합한 개인간의 파트너십이 필요하게 되는 경우가 많습니다.이 사실은, 이하의 「책임의 분할」의 문제에도 관련하고 있습니다.

그러나 일부에서는 (1) RDBMS는 오브젝트 모델링을 용이하게 하기 위한 것이 아니며 (2) SQL은 일반적으로 RDB를 위한 솔루션을 실현하려고 할 때 '손실' 또는 '비효율적인' 인터페이스 언어로 밖에 인식되지 않기 때문에 이 경합은 무의미하다고 지적합니다.MS는 설계되어 있지 않다.SQL은 대규모 데이터 세트를 쿼리, 정렬, 필터링 및 저장하는 등 설계된 작업을 매우 효율적으로 수행할 수 있습니다.일부에서는 백엔드에 OO 언어 기능을 포함시키면 RDBMS와 반대로 데이터 계층에 높은 수준의 애플리케이션 로직을 허용하기 때문에 단순히 잘못된 아키텍처 관행을 용이하게 한다고 지적할 수도 있습니다.

여기에는 "표준" 상태의 복사본이 있습니다.데이터베이스 모델에서는 일반적으로 데이터베이스 관리 시스템이 기업에 관한 유일한 신뢰할 수 있는 상태 저장소라고 가정합니다.애플리케이션 프로그램에 의해 보관되고 있는 상태의 복사본은 임시 복사본일 뿐입니다(기본 데이터베이스 레코드가 트랜잭션에 의해 나중에 변경된 경우 최신이 아닐 수 있습니다).많은 객체 지향 프로그래머들은 객체 자체의 메모리 내 표현을 표준 데이터로 보고 데이터베이스를 백업 저장소 및 지속성 메커니즘으로 보는 것을 선호합니다.

또 다른 논쟁점은 애플리케이션 프로그래머와 데이터베이스 관리자(DBA) 간의 적절한 책임 분담입니다.요청된 새로운 기능을 구현하기 위해 애플리케이션 코드를 변경해야 하는 경우가 많습니다. 대부분의 조직에서 데이터베이스 정의는 DBA가 담당합니다.실가동 데이터베이스 시스템을 24시간 유지해야 하기 때문에 많은 DBA는 불필요하거나 불필요하다고 생각되는 데이터베이스 스키마를 변경하는 것을 꺼리고 경우에 따라서는 변경을 완전히 거부합니다.개발용 데이터베이스(실가동 시스템 이외)를 사용하면 어느 정도 도움이 되지만 새로 개발된 애플리케이션이 "실가동"되면 DBA는 변경 사항을 승인해야 합니다.일부 프로그래머는 이를 비타협적인 것으로 간주하지만 데이터베이스 정의 변경으로 인해 운영 시스템에서 서비스가 손실되는 경우 DBA가 책임을 지는 경우가 많습니다. 그 결과 많은 DBA는 설계 결함이 치명적인 결과를 초래할 가능성이 훨씬 낮은 애플리케이션 코드에 대한 설계 변경을 억제하는 것을 선호합니다.

단, DBA와 개발자 사이에 기능하지 않는 관계가 있는 조직에서는 위의 문제가 발생하지 않습니다.데이터베이스 스키마를 변경할지 여부는 비즈니스 요구만으로 결정할 수 없기 때문입니다.추가 데이터를 유지하거나 중요한 애플리케이션의 퍼포먼스를 향상시켜야 하는 새로운 요건이 발생하면 스키마 모가 트리거됩니다.예를 들어, 디피케이션.

철학적 차이

OO와 관계형 모델 사이의 주요 철학적인 차이는 다음과 같이 요약할 수 있습니다.

  • 선언적 인터페이스 vs. 필수적 인터페이스 – 관계적 사고는 동작을 인터페이스로 사용하지 않고 인터페이스로 데이터를 사용하는 경향이 있습니다.따라서 이는 OO의 행동 기울기와는 대조적으로 디자인 철학에서 선언적인 기울기를 가지고 있다. (일부 관계형 지지자들은 복잡한 행동을 제공하기 위해 트리거, 저장 프로시저 등을 사용할 것을 제안하지만, 이는 일반적인 관점이 아니다.)
  • Schema bound – 객체는 객체에 속성 또는 접근자가 있는 "부모 스키마"를 따를 필요가 없으며 테이블 행은 엔티티의 스키마를 따라야 합니다.특정 행은 1개의 엔티티에만 속해야 합니다.OO에서 가장 가까운 것은 상속이지만 일반적으로 나무 모양이며 선택 사항입니다.애드혹 열을 허용하는 동적 데이터베이스 시스템은 스키마의 한계를 완화할 수 있지만, 이러한 시스템은 현재 희귀하거나 "관계형"으로 분류하는 데 문제가 있습니다.
  • 액세스 규칙 – 관계형 데이터베이스에서 속성은 미리 정의된 관계 연산자를 통해 액세스 및 변경되며, OO는 각 클래스가 자체 상태 변경 인터페이스 및 관행을 만들 수 있도록 합니다.OO의 "자기 취급 명사" 관점은 관계 모델이 허용하지 않는 각 물체에 독립성을 부여한다.이것은 "표준 대 지역 자유" 논쟁이다.OO는 관계 표준이 표현력을 제한한다고 주장하는 경향이 있는 반면, 관계 지지자들은 규칙 준수를 통해 보다 추상적인 수학과 같은 추론, 무결성 및 설계 일관성이 가능하다고 제안합니다.
  • 명사와 동사 간의 관계 – OO는 동사(동사)와 연산이 작동하는 명사(유사체) 간의 긴밀한 연관성을 장려합니다.명사와 동사를 모두 포함하는 결과물인 단단하게 묶인 실체를 보통 클래스 또는 OO 분석에서 개념이라고 합니다.관계 설계는 일반적으로 (관계 연산자 외) 그러한 긴밀한 연관성에 대해 자연적이거나 논리적인 것이 있다고 가정하지 않는다.
  • 오브젝트 아이덴티티 – 일반적으로 오브젝트(불변하는 오브젝트 제외)는 하나의 아이덴티티를 갖는 것으로 간주됩니다.특정 시점에서 같은 상태를 가진2개의 오브젝트는 동일하지 않은 것으로 간주되지 않습니다.반면에, 관계는 이런 종류의 정체성에 대한 고유한 개념이 없습니다.즉, 글로벌하게 고유한 후보 키를 사용하여 데이터베이스 내의 레코드에 대해 "ID"를 작성하는 것은 일반적인 방법입니다.다만, 많은 경우, 실제의 엔티티와 1 대 1의 대응이 없는 데이터베이스 레코드에 대해서는, 이것을 좋지 않은 프랙티스로 간주하고 있습니다(개체와 같이, 외부 w에 존재하는 경우, 도메인 키를 사용할 수 있습니다).(식별을 위한) orld.실제로 관계형 시스템은 "영구적"이고 검사 가능한 식별 기술을 위해 노력하고 지원하는 반면, 객체 식별 기법은 일시적이거나 상황적인 경향이 있다.
  • 정규화 – 관계 정규화 관행이 OOO 설계에서는 무시되는 경우가 많습니다.하지만, 이것은 OO의 고유 특징 대신 나쁜 습관일 수도 있습니다.또 다른 견해는 일종의 포인터를 통해 상호 연결된 객체의 집합은 네트워크 데이터베이스와 동등하며, 이는 다시 극도로 정규화된 관계형 데이터베이스로 간주될 수 있습니다.
  • 스키마 상속– 대부분의 릴레이셔널 데이터베이스는 스키마 상속을 지원하지 않습니다.OOP와의 충돌을 줄이기 위해 이론적으로 그러한 특징이 추가될 수 있지만, 관계형 지지자들은 집합 기반 분류법이나 분류 체계를 나무보다 더 강력하고 유연한 것으로 보는 경향이 있기 때문에 계층적 분류법과 하위 유형의 효용성을 덜 믿는다.OO 옹호자들은 상속/서브타이핑 모델이 트리에 국한될 필요는 없다고 지적하지만(Java와 같은 많은 인기 있는 OO 언어에서는 제한 사항이지만), 비트리 OO 솔루션은 관계형(relational)이 선호하는 세트 기반 변형 관리 기술보다 공식화하기 더 어려운 것으로 보입니다.적어도 그것들은 관계대수에서 일반적으로 사용되는 기술과는 다르다.
  • 구조 vs. 행동 – OOO는 주로 프로그램의 구조가 합리적인지(유지, 이해, 확장, 재사용, 안전) 확인하는 데 초점을 맞추고 있으며, 관계형 시스템은 결과 런타임 시스템이 어떤 종류의 행동(효율성, 적응성, 결함 허용, 활성, 논리적 무결성 등)을 갖는지에 초점을 맞추고 있습니다.오브젝트 지향 메서드는 일반적으로 오브젝트 지향 코드의 주요 사용자와 그 인터페이스가 어플리케이션 개발자라고 가정합니다.관계형 시스템에서는 시스템의 동작에 대한 최종 사용자의 시각이 더 중요한 것으로 간주되는 경우가 있습니다.그러나 관계형 쿼리와 "보기"는 애플리케이션별 또는 태스크별 구성으로 정보를 표시하는 일반적인 기술입니다.또한 많은 공통 개발 도구가 직접 이러한 기능을 제공하지는 않지만, 관계형에서는 로컬 또는 애플리케이션 고유의 구조나 테이블이 생성되는 것을 금지하지 않습니다.따라서 관계성에 대한 기술된 비개발자 관점이 관계성에 고유한 것인지, 아니면 단지 현재의 관행과 도구 구현 가정의 산물인지를 알기 어렵게 만든다.
  • 설정 vs. 그래프 관계– 다른 항목(개체 또는 레코드) 간의 관계는 패러다임 간에 다르게 처리되는 경향이 있습니다.관계 관계는 보통 집합론에서 가져온 관용어에 기초하는 반면, 객체 관계는 그래프 이론에서 채택된 관용어에 기울어진다.각각은 서로 동일한 정보를 나타낼 수 있지만 정보에 접근하고 관리하기 위해 제공하는 접근 방식은 다릅니다.

객체-관계 임피던스 불일치의 결과로, 논쟁의 양쪽에서 다른 기술을 포기하거나 [8]범위를 축소해야 한다는 주장이 종종 제기됩니다.일부 데이터베이스 옹호자들은 전통적인 "절차적" 언어를 많은 OO 언어보다 RDBMS와 더 호환성이 있다고 보거나 덜 OO 스타일을 사용해야 한다고 제안합니다.(특히 응용 프로그램코드에 오래 지속되는 도메인 오브젝트는 존재해서는 안 된다고 주장되고 있습니다).이러한 오브젝트는 트랜잭션이나 태스크가 완료되었을 때 쿼리가 생성되어 폐기될 때 생성되어야 합니다.반대로, 일부 OO 옹호자들은 OODBMS와 같은 OO 친화적인 지속 메커니즘을 개발하고 사용해야 하며, 관계 기술은 단계적으로 폐지되어야 한다고 주장한다.대부분의 프로그래머와 DBA는 이러한 관점을 모두 가지고 있지 않으며 객체-관계 임피던스 불일치를 정보기술이 다루어야 하는 삶의 사실로 보고 있습니다.

또한 O/R 매핑은 일부 상황에서 성과를 거두고 있지만 아마도 과잉 판매될 수 있다는 주장도 있습니다. 단점 외에도 장점이 있습니다.회의론자들은 이것을 사용하기 전에 신중하게 생각해 볼 가치가 있다고 지적하는데, [9]이는 경우에 따라서는 거의 가치가 없을 것이기 때문이다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ 객체와 관계 임피던스의 불일치 분류.아일랜드, 크리스토퍼, 바우어스, 데이비드, 뉴턴, 마이크와 워, 케빈(2009).객체와 관계 임피던스의 불일치 분류.인: 제1회 데이터베이스, 지식, 데이터 애플리케이션(DBKDA) 국제회의 2009년 3월 1-6일 멕시코 칸쿤.
  2. ^ C. J. 날짜, 릴레이셔널 데이터베이스 기술
  3. ^ 오브젝트-관계매핑 재검토 - 데이터베이스 테크놀로지가 O/R매핑 전략에 미치는 영향에 관한 정량적 연구. M 로렌츠, JP 루돌프, G 헤세, M Uflacker, H 플래트너 하와이 국제시스템과학회의(HICS), 4877-4886(DOI:10.24251/hics.2017.592)
  4. ^ 를 클릭합니다Date, Christopher ‘Chris’ J; Pascal, Fabian (2012-08-12) [2005], "Type vs. Domain and Class", Database debunkings (World Wide Web log), Google, retrieved 12 September 2012.
  5. ^ 를 클릭합니다——— (2006), "4. On the notion of logical difference", Date on Database: writings 2000–2006, The expert’s voice in database; Relational database select writings, USA: Apress, p. 39, ISBN 978-1-59059-746-0, Class seems to be indistinguishable from type, as that term is classically understood.
  6. ^ 를 클릭합니다——— (2004), "26. Object/Relational databases", An introduction to database systems (8th ed.), Pearson Addison Wesley, p. 859, ISBN 978-0-321-19784-9, ...any such rapprochement should be firmly based on the relational model.
  7. ^ Date, Christopher ‘Chris’ J; Darwen, Hugh, "2. Objects and Relations", The Third Manifesto, The first great blunder
  8. ^ Neward, Ted (2006-06-26). "The Vietnam of Computer Science". Interoperability Happens. Retrieved 2010-06-02.
  9. ^ Johnson, Rod (2002). J2EE Design and Development. Wrox Press. p. 256.

외부 링크