기업-속성-가치 모형

Entity–attribute–value model

기업-속성-가치모형(EAV)은 이들을 기술하는 데 사용될 수 있는 속성(속성, 매개변수)의 수가 잠재적으로 방대하지만, 주어진 기업에 실제로 적용될 수는 상대적으로 적은 수의 기업을 공간 효율적인 방식으로 인코딩하는 데이터 모델이다. 그러한 실체는 희박한 행렬의 수학적 개념에 해당한다.

EAV는 객체 특성-가치 모델, 수직 데이터베이스 모델, 개방형 스키마로도 알려져 있다.

데이터 구조

이러한 데이터 표현은 비어 있지 않은 값만 저장되는 희소 행렬을 저장하는 공간 효율적인 방법과 유사하다. EAV 데이터 모델에서 각 속성-값 쌍은 엔터티를 설명하는 사실이며, EAV 테이블의 행은 단일 사실을 저장한다. EAV 테이블은 종종 "긴 길이와 마른 길이"로 설명된다. "긴 길이"는 행의 수를 가리키며, 몇 개의 열에 "피부"를 가리킨다.

데이터는 세 개의 열로 기록된다.

  • 엔티티: 설명하고 있는 항목.
  • 속성 또는 매개 변수: 일반적으로 속성 정의 표에 외래 키로 구현됨. 속성 정의 테이블에는 속성 ID, 속성 이름, 설명, 데이터 유형 및 입력 유효성 검사를 지원하는 열(예: 최대 문자열 길이 및 정규식, 허용되는 값 집합 등)이 포함될 수 있다.
  • 속성의 값.

예

관계형 데이터베이스에서 범용 임상 기록을 나타내는 방법을 생각해 보십시오. 수천 개의 열이 있는 테이블(또는 테이블 세트)을 명확하게 만드는 것은 대부분의 열이 null이기 때문에 가능하지 않다. 일을 복잡하게 만들려면 시간이 지남에 따라 환자를 따르는 종적 의학 기록에는 같은 파라미터의 여러 가지 값이 있을 수 있다. 예를 들어, 아이의 키와 몸무게가 자라면서 변한다. 마지막으로, 임상 결과의 우주는 계속 증가하고 있다. 예를 들어 질병이 출현하고 새로운 실험실 테스트가 고안된다. 이는 칼럼을 지속적으로 추가하고 사용자 인터페이스를 지속적으로 수정해야 할 것이다. (속성의 목록이 자주 바뀌는 상황을 데이터베이스 용어로 "속성 변동성"이라고 한다.)

다음은 1998년 1/5일 아침 발열로 의사를 방문했을 때의 임상 소견에 대한 EAV 표의 스냅샷을 보여준다. 대괄호 안에 표시된 항목은 이해하기 쉽도록 인코딩된 외래 키 값이 아닌 텍스트로 여기에 표시된 다른 표의 항목에 대한 참조다. 이 예에서 값은 모두 리터럴 값이지만 미리 정의된 값 리스트일 수도 있다. 후자는 가능한 값이 제한되어 있다고 알려진 경우(즉, 열거할 수 있는 경우) 특히 유용하다.

  • 실체. 임상 결과의 경우, 기업은 환자 사건이다. 즉, 최소한 환자 ID와 설명되는 사건이 발생한 시기를 기록하는 하나 이상의 시간 스탬프(예: 검사 날짜/시간의 시작 및 끝)를 포함하는 표에 외래 키를 삽입하는 것이다.
  • 속성 또는 매개 변수: 속성 정의 표(이 예에서는 임상 결과의 정의)에 대한 외래 키. 최소한 속성 정의 표에는 속성 ID, 속성 이름, 설명, 데이터 유형, 측정 단위 및 입력 유효성 검사를 지원하는 열(예: 최대 문자열 길이 및 정규식, 최대 및 최소 허용 값, 허용 값 집합 등)이 포함될 수 있다.
  • 속성의 값. 이는 데이터 유형에 따라 달라질 수 있으며, 우리는 값이 어떻게 저장되는지에 대해 논의한다.

아래의 예는 폐렴 환자에게서 볼 수 있는 증상 발견을 예시한다. 

(<환자 XYZ라는 1/5/98 9시 30분 AM>, <,도의 온도 Fahrenheit>,"102")(<환자 XYZ라는 1/5/98 9시 30분 AM>,<>Cough> 경험 유무,"True")(<환자 XYZ라는 1/5/98 9시 30분 AM>, <, Cough&gt의 매개 변수 형식,"가래-피와, 노란 색, 줄무늬")(;환자 XYZ라는 1/5/98 9시 30분 AM>,<,<>심장율 minute&g 당 비트에.t;,"98"음...

위에서 설명한 EAV 데이터는 (데이터베이스의 판매 라인 항목 테이블에 반영될) 슈퍼마켓 판매 영수증의 내용과 비교 가능하다. 영수증에는 고객이 구매했을 수도 있지만 구매하지 않았을 모든 제품을 나열하는 대신 실제로 구매한 품목의 상세 내역만 기재돼 있다. 특정 환자의 임상 결과처럼 판매 영수증도 희박하다.

  • "엔티(entity)"는 판매/거래 ID로, 판매 트랜잭션 테이블의 외래 키입니다. 영수증에 판매에 대한 정보가 상단(매장 위치, 판매 날짜/시간)과 하단(총 판매 가치)에 표시되지만, 이는 각 라인 항목에 내부적으로 태그를 지정하는 데 사용된다.
  • "속성"은 제품 테이블로 들어가는 외래어 키로, 설명, 단가, 할인, 프로모션 등을 살펴본다(제품은 임상 결과만큼 휘발성이 강하며, 어쩌면 더욱 그럴지도 모른다: 신상품은 매월 출시되는 반면, 소비자 수용도가 낮을 경우 다른 제품은 시장에서 퇴출된다. 어떤 유능한 데이터베이스 설계자도 도리토스나 다이어트 콜라 같은 개별 제품을 테이블의 열로 하드코딩하지 않을 것이다.)
  • "값"은 구매 수량 및 총 라인 품목 가격이다.

어떤 것에 관한 사실(이 경우 판매 거래)이 복수의 열이 아닌 복수의 행으로 기록되는 [clarification needed]행 모델링은 표준 데이터 모델링 기법이다. 행 모델링과 EAV(행 모델링의 일반화로 간주될 수 있음)의 차이는 다음과 같다.

  • 행으로 된 표는 그것이 설명하는 사실에서 동질적이다: 라인 항목 표는 판매되는 제품만을 설명한다. 대조적으로, EAV 테이블은 거의 모든 유형의 사실을 포함하고 있다.
  • 행 모델링된 표에 있는 값 열/s의 데이터 유형은 기록된 사실의 특성에 의해 미리 결정된다. 대조적으로, EAV 표에서 특정 행의 값의 개념 데이터 유형은 해당 행의 속성에 따라 달라진다. 그것은 데이터베이스 엔진 자체가 강력한 입력 검증을 수행할 수 없기 때문에 생산 시스템에서 EAV 테이블에 직접 데이터 입력을 허용하는 것은 재앙의 비법이 될 것이다. 속성별 무한 코딩 없이 입력 검증의 대부분의 작업을 수행하는 일반 프레임워크를 구축하는 것이 어떻게 가능한지 나중에 알게 될 것이다.

임상 데이터 저장소에서 행 모델링은 또한 많은 용도를 발견한다; 실험실 테스트 결과는 일반적으로 숫자이거나 숫자로 인코딩될 수 있기 때문에 실험실 테스트 하위 체마는 일반적으로 이러한 방식으로 모델링된다.

표준 행 모델에서 EAV로 전환해야 하는 상황은 다음과 같다.

  • 개별 속성의 데이터 유형은 다양하다(임상 소견에서 볼 수 있다).
  • 데이터의 범주는 다양하고, 증가하거나, 변동하지만, 각 범주 내의 인스턴스(기록/행) 수는 매우 적다. 여기서, 전통적인 모델링에서 데이터베이스의 개체-관계 다이어그램은 수백 개의 표를 가질 수 있다. 즉, 수 천/백만 개의 행/인스턴스를 포함하는 테이블은 행이 매우 적은 테이블과 동일한 정도로 시각적으로 강조된다. 후자는 EAV 대표로 전환될 후보들이다.

이러한 상황은 온톨로지 모델링 환경에서 발생하며, 범주("클래스")는 종종 즉시 생성되어야 하며, 일부 클래스는 후속 프로토타이핑 사이클에서 제거되는 경우가 많다.

특정("하이브리드") 클래스는 일부 속성이 sparse가 아닌(모든 또는 대부분의 경우에 있음)인 반면, 다른 속성은 매우 가변적이고 희소하다. 후자는 EAV 모델링에 적합하다. 예를 들어 대기업에서 만든 제품에 대한 설명은 제품 범주에 따라 달라진다. 예를 들어 전구 브랜드를 설명하는 데 필요한 속성은 의료용 영상 장치를 설명하는 데 필요한 속성과는 상당히 다르지만 두 가지 모두 포장 단위와 항목당 비용 같은 공통 속성이 있다.

개념 설명

엔티티

임상 데이터에서 기업은 위에서 기술한 바와 같이 일반적으로 임상 사건이다. 좀 더 범용적인 설정에서, 기업은 데이터베이스의 모든 "개체"(사물)에 대한 공통 정보(최소한, 선호되는 이름과 간략한 설명, 그리고 그것이 속한 개체의 범주/종류)를 기록하는 "개체" 표에 외래 키가 된다. 이 표의 모든 레코드(개체)에는 기계 생성 객체 ID가 할당된다.

"객체 테이블" 접근법은 톰 슬레작과 로렌스 리버모어 연구소의 19번 염색체 데이터베이스에 대한 동료들에 의해 개척되었으며, 현재 대부분의 대형 생물정보학 데이터베이스에서 표준화되고 있다. 객체 테이블의 사용은 EAV 설계의 동시 사용을 의무화하지 않는다: 기존 테이블을 사용하여 각 객체의 범주별 세부 정보를 저장할 수 있다.

중앙 객체 테이블의 주요 이점은 객체 동의어와 키워드의 지원 테이블을 보유함으로써 사용자가 관심 객체에 대한 정보를 찾을 수 있는 표준 구글과 같은 검색 메커니즘을 전체 시스템에 걸쳐 제공할 수 있다는 것이다.(이것은 b에서 중요하다)"아세틸콜린"과 같은 키워드가 신경전달물질인 분자 자체 또는 그것이 결합하는 생물학적 수용체를 가리키는 ioscience 시스템)

속성

EAV 테이블 자체에서, 이것은 단지 속성 ID일 뿐, 위에 언급된 것처럼 속성 정의 테이블의 외래 키 입니다. 그러나, 속성 관련 정보를 포함하는 메타데이터 테이블이 여러 개 있으며, 이러한 테이블은 잠시 후에 논의된다.

값

위의 EAV 데이터 예에서와 같이 모든 값을 문자열로 강제하면 단순하지만 확장 불가능한 구조: 값을 사용하여 어떤 작업을 하려면 일정한 데이터 유형 간 변환이 필요하며, EAV 테이블의 값 열의 인덱스는 본질적으로 무용지물이다. 또한 영상과 같은 큰 이진 데이터를 Base64 인코딩 형태로 작은 정수나 문자열과 같은 표에 저장하는 것이 편리하지 않다. 따라서 대형 시스템은 각 데이터 유형(이진 대형 객체, "BLOBS" 포함)에 대해 별도의 EAV 테이블을 사용하며, 주어진 속성에 대한 메타데이터는 데이터가 저장될 EAV 테이블을 식별한다. 사용자가 작업하기로 선택한 특정 클래스 또는 폼의 속성 메타데이터의 양은 메모리에 쉽게 캐슁될 수 있기 때문에 이 접근방식은 실제로 상당히 효율적이다. 그러나 속성의 데이터 유형이 변경되는 경우 테이블 간에 데이터를 이동해야 한다.

역사

EAV는 지식 표현의 범용 수단으로서 "관련 목록"(속성-값 쌍)의 개념에서 비롯되었다. 오늘날 일반적으로 사용되는 이것들은 LISP 언어에 처음 도입되었다.[1] 속성-값 쌍은 구성 파일(속성 = 값과 같은 간단한 구문 사용)과 같은 다양한 애플리케이션에 널리 사용된다. EAV를 데이터베이스화하지 않고 사용하는 예는 UIMA(Unstructured Information Management Architecture)에 있다. UIMA는 현재 아파치 재단이 관리하고 있으며 자연어 처리와 같은 분야에 고용되어 있다. 텍스트를 분석하는 소프트웨어는 일반적으로 세그먼트를 표시("알림")한다. UIMA 튜토리얼에 제공된 예는 문서에 NER(Named-entity 인식)를 수행하는 프로그램으로, 주석 속성 값 트리플(Person, Full_Name, "George W. Bush")[2]으로 텍스트 세그먼트에 주석을 달았다. 이러한 주석은 데이터베이스 테이블에 저장될 수 있다.

EAV가 AV-pares와 직접 연결되지는 않지만 스테드와 해몬드는 임의의 복잡한 데이터의 지속적인 저장을 위해 사용한다는 것을 처음으로 생각해낸 것으로 보인다.[3] 첫번째 의학 기록 시스템 EAV을 고용할 수 있는데 가장Regenstrief 전자 의료 기록(노력 클레멘스 맥도널드 씨가 이끄는)[4]윌리엄 스테드와 에드 해먼즈 수송 이동 허가(그 의무 기록)제도와 HELP임상 데이터 저장소(사령관)선로 전압 강하 보상기 병원, 유타 주 솔트 레이크 시티에서 호머 워너의 무리가 만들어 낸.[5][6](Regenstrief 시스템의 실제 사용된다. Patient-Attribute-Timestamp-Value 설계: 지정된 환자/특성에 대한 값 검색을 지원하는 타임스탬프 사용) 1970년대에 개발된 이 모든 시스템은 E.F.에 기반을 둔 상업적 시스템보다 먼저 출시되었다. Codd의 관계형 데이터베이스 모델은 사용 가능했지만 HELP는 훨씬 나중에 관계형 아키텍처에 포팅되어 3M 법인에 의해 상용화되었다. (Codd의 랜드마크 논문이 1970년에 발표되었지만, 그것의 수학적인 어조는 비 컴퓨터 과학 유형들 간의 접근성을 떨어뜨리고 결과적으로 IT와 소프트웨어 공급업체 서클에서의 모델의 수용을 지연시키는 불행한 효과를 가져왔다는 점에 주목한다. IBM의 Codd의 동료인 Christopher J. Date가 이러한 아이디어를 접근 가능한 언어로 번역하는 데 기여한 이후 그 가치는 과대평가될 수 없다.)

컬럼비아-프레즈비테리언 메디컬 센터의 한 그룹은 EAV 시스템의 기초로서 관계형 데이터베이스 엔진을 처음으로 사용했다.[7]

Nadkarni 외 연구소의 오픈 소스 TrialDB 임상 연구 데이터 관리 시스템은 DBMS 데이터 유형별로 하나씩 여러 EAV 테이블을 처음으로 사용했다.[8]

주로 루이스 마렌코와 프라카시 나드카르니가 설계한 EAV/CR 프레임워크는 객체 지향의 원리를 EAV에 중첩시켰으며,[9] Tom Slezak의 객체 테이블 접근법에 기초하였다("Entity" 섹션의 앞부분에서 설명함). 공개적으로 접근할 수 있는 신경과학 데이터베이스인 SenseLab은 EAV/CR 프레임워크로 구축되었다.

데이터베이스에서 사용

"EAV 데이터베이스"란 데이터의 상당 부분을 EAV로 모델링하는 데이터베이스 설계를 말한다. 그러나 "EAV 기반"으로 기술된 데이터베이스에서도 시스템의 일부 테이블은 전통적인 관계형 테이블이다.

위에서 언급한 바와 같이 EAV 모델링은 속성이 많고 희박한 임상 소견과 같은 데이터 범주에 대해 타당하다. 이러한 조건이 충족되지 않는 경우, 표준 관계 모델링(즉, 속성당 하나의 열)이 바람직하다. EAV를 사용한다고 해서 좋은 관계 설계의 상식이나 원칙을 포기하는 것은 아니다. 임상 기록 장치에서 subschemas 환자 인구 통계 및 청구서 발송을 다루는 일반적으로 전통적으로(대부분의 제조 업체 데이터베이스 스키마 소유, VistA, 시스템은 미국 재향 군인회 부서의 전체를 통해서 사용된(VA)의료 체계는 보훈(초고공)[10]로 알려진open-sou은 모델로 한 것입니다..rce 관계형 데이터베이스보다는 MUMPS 데이터베이스 엔진을 사용하지만 스키마는 쉽게 검사할 수 있다.)

잠시 논의한 바와 같이, EAV 데이터베이스는 기본적으로 지원 메타데이터를 포함하는 수많은 지원 테이블 없이는 유지보수가 불가능하다. 일반적으로 최소 3개 이상의 인수로 EAV 테이블을 능가하는 메타데이터 테이블은 일반적으로 표준 관계형 테이블이다.[8][9] 메타데이터 테이블의 예로는 위에서 언급한 속성 정의 테이블이 있다.

EAV/CR: 계층 및 관계가 있는 하부 구조를 나타냄

단순한 EAV 설계에서 속성의 값은 데이터베이스 엔진에 관한 한 단순하거나 원시 데이터 유형이다. 그러나 매우 다양한 데이터의 표현에 사용되는 EAV 시스템에서는 주어진 객체(클래스 인스턴스)가 하부 구조를 가질 수 있다. 즉, 그 속성의 일부는 임의의 복잡성 수준으로 하위 구조를 가질 수 있는 다른 종류의 객체를 나타낼 수 있다. 예를 들어, 자동차는 엔진, 트랜스미션 등을 가지고 있으며, 엔진은 실린더와 같은 구성품을 가지고 있다. (특정 등급에 대한 허용 가능한 하부 구조는 나중에 논의한 바와 같이 시스템의 속성 메타데이터 내에서 정의된다. 따라서 예를 들어 "랜덤 액세스 메모리" 속성은 클래스 "컴퓨터"에는 적용될 수 있지만 클래스 "엔진"에는 적용되지 않는다.

하부 구조를 나타내기 위해, 값 열이 시스템의 다른 실체에 대한 참조를 포함하는 특수 EAV 표(즉, 객체 표에 외래 키 값)를 통합한다. 주어진 개체에 대한 모든 정보를 얻으려면 메타데이터의 재귀적 통과가 필요하며, 검색된 모든 속성이 단순할 때(원자적) 중단되는 데이터의 재귀적 통과가 필요하다. 개별 클래스의 세부 정보가 재래식 또는 EAV 형식으로 표시되는지 여부에 관계없이 재귀적 통과가 필요하다. 예를 들어 그러한 통과는 표준 객체-관계 시스템에서 수행된다. 실제로 재귀의 레벨 수는 대부분의 클래스에서 비교적 적은 경향이 있으므로, 재귀에 의한 성능 벌칙은 특히 객체 ID의 지수화에 의해 미미한 편이다.

EAV/CR(계급과 관계가 있는 EAV)은 복잡한 하부 구조를 지원하는 프레임워크를 말한다. 그것의 이름은 다소 잘못 알려진 것이다: EAV 시스템에 대한 작업의 일부였지만, 실제로 그러한 시스템의 많은 또는 심지어 대부분의 클래스는 속성이 희박한지 또는 밀도인지에 기초하여 표준 관계형식으로 표현될 수 있다. EAV/CR은 실제로 매우 상세한 메타데이터가 특징인데, 이는 클래스별 사용자 인터페이스 코드를 작성할 필요 없이 개별 클래스에 대한 브라우징 인터페이스의 자동 생성을 지원할 수 있을 만큼 충분히 풍부하다. 이러한 브라우저 인터페이스의 기본은 우선 메타데이터를 참조하고 메타데이터 정보를 사용하여 데이터 테이블에 대한 질의 순서를 생성함으로써 객체의 클래스와 독립된 동적 SQL 조회 일괄 생성이 가능하며, 이러한 쿼리 중 일부는 임의로 재귀적일 수 있다. 이 접근방식은 웹 기반 탐색 인터페이스에서처럼 개체 이름을 클릭하면 개체의 모든 세부 정보가 별도의 페이지에 나타나는 것처럼 개체별 쿼리에 잘 작동한다. 즉, 해당 개체의 클래스와 관련된 메타데이터도 개체 세부 정보의 표시를 용이하게 하는데, 이는 개별 속성의 캡션을 포함하기 때문이다. 그룹화 방법뿐만 아니라 이들을 표시하는 순서.

EAV/CR에 대한 한 가지 접근방식은 컬럼이 JSON 구조를 고정할 수 있도록 하여 필요한 등급 구조를 제공하는 것이다. 예를 들어, Postgre.SQL은 버전 9.4를 기준으로 JSON 바이너리 컬럼(JSONB) 지원을 제공하므로 JSON 속성을 쿼리, 인덱싱 및 결합할 수 있다.

메타데이터

교수의 말에 의하면. Dr. Daniel Masys(전 Vanderbilt University의 의학 정보학부 석좌)는 EAV 데이터베이스에서 "물리적 스키마"(데이터가 저장되는 방식)가 "논리적 스키마" 즉 사용자 방식과 통계 패키지, registic package와 같은 많은 소프트웨어 애플리케이션과 근본적으로 다르다는 사실에서 EAV와 함께 작업하는 데 어려움을 겪고 있다.즉, 개별 클래스에 대한 전통적인 행과 열로 해석한다. (EAV 테이블은 개념적으로 사과, 오렌지, 자몽, 찹수이를 혼합하기 때문에 표준 기성 소프트웨어를 사용하여 데이터를 분석하려면 대부분의 경우 해당 테이블의 하위 세트를 주상형 형태로 변환해야 한다.[14] 피벗이라고 하는 이것을 하는 과정은 별도로 논의될 만큼 중요하다.)

메타데이터는 사용자가 물리적 스키마가 아닌 논리적 스키마 측면에서 시스템과 상호작용할 수 있도록 하는 손쉬운 수행을 돕는다. 소프트웨어는 데이터 프레젠테이션, 대화형 유효성 검사, 대량 데이터 추출 및 임시 쿼리와 같은 다양한 작업에 대한 메타데이터를 지속적으로 참조한다. 메타데이터는 실제로 시스템의 동작을 사용자 정의하는 데 사용될 수 있다.

EAV 시스템은 데이터의 물리적 구조와 논리적 구조의 단순성을 그들의 메타데이터의 복잡성과 교환하며, 무엇보다도 데이터베이스 제약조건과 참조 무결성이 표준 데이터베이스 설계에서 수행하는 역할을 한다. 생산 시스템의 일반적인 혼합 스키마에서는 기존의 관계형 테이블의 데이터도 자동 인터페이스 생성과 같은 기능성의 이점을 얻을 수 있기 때문에 이러한 절충은 일반적으로 가치가 있다. 메타데이터의 구조는 데이터베이스 내에서 자체 서브체마를 구성할 정도로 복잡하다. 데이터 테이블의 다양한 외래 키는 이 서브체마 내의 표를 참조한다. 이 하위 체마는 표준 관계형이며, 구속조건 및 참조 무결성과 같은 특징이 자루에 사용된다.

의도된 시스템 동작의 관점에서 메타데이터 컨텐츠의 정확성은 매우 중요하며, 정확성을 확보하는 과제는 EAV 시스템을 만들 때, 문제 도메인을 아는 팀원(예: 임상 메디치)이 사용할 수 있는 메타데이터 편집을 위한 사용자 인터페이스 구축에 상당한 설계 노력을 기울여야 함을 의미한다.ne) 그러나 반드시 프로그래머일 필요는 없다. (역사적으로, 사전 관계형 TMR 시스템이 홈 기관이 아닌 다른 사이트에서 채택되지 못한 주된 이유 중 하나는 모든 메타데이터가 비직관적 구조를 가진 단일 파일에 저장되었기 때문이다. 시스템을 망가뜨리지 않고 이 파일의 내용을 변경하여 시스템 동작을 커스터마이징하는 것은 시스템 저자들이 자신들만 믿고 할 정도로 섬세한 작업이었다.)

RDF를 통하여 EAV 시스템을 구현하는 경우, RDF Schema 언어를 편리하게 사용하여 그러한 메타데이터를 표현할 수 있다. 이 스키마 정보는 EAV 데이터베이스 엔진에서 최고의 효율성을 위해 내부 테이블 구조를 동적으로 재구성하는 데 사용될 수 있다.[15]

메타데이터와 관련된 최종 주의 사항:

  • 비즈니스 논리는 데이터베이스 스키마에 명시적이기보다는 메타데이터에 있기 때문에(즉, 전통적으로 설계된 시스템에 비해 한 레벨이 제거됨), 시스템에 익숙하지 않은 사람에게는 덜 명백하다. 따라서 메타데이터 검색 및 메타데이터 보고 도구는 EAV 시스템의 유지 관리 가능성을 보장하는 데 중요하다. 메타데이터가 관계형 하위 스키마로 구현되는 일반적인 시나리오에서, 이러한 툴은 메타데이터 테이블에서 작동하는 기성 보고나 쿼리 툴을 사용하여 구축된 애플리케이션에 지나지 않는다.
  • 지식이 부족한 사용자는 메타데이터를 손상(즉, 비일관성과 오류를 도입)하기 쉽다. 따라서 메타데이터에 대한 접근은 제한되어야 하며, 복수의 개인이 메타데이터에 접근하는 상황을 처리하기 위해 접속 및 변경에 대한 감사 추적을 실시해야 한다. 메타데이터에 RDBMS를 사용하면 트랜잭션 지원 등의 RDBMS 기능을 활용하여 메타데이터 생성 및 편집 시 일관성을 유지하는 프로세스가 단순화된다. 또한 메타데이터가 데이터 자체와 동일한 데이터베이스의 일부인 경우, 이를 통해 데이터 자체만큼 자주 백업되므로 특정 시점까지 복구할 수 있다.
  • 메타데이터 내의 주석 및 문서화 품질(즉, 메타데이터 하위 스키마의 설명 열에 있는 서술/설명 텍스트)은 개발 팀의 다양한 구성원이 쉽게 이해할 수 있도록 훨씬 높아야 한다. 메타데이터 품질을 보장하는 것(그리고 시스템이 발전함에 따라 최신 상태를 유지하는 것)은 EAV 구성요소를 사용하는 설계의 장기적 관리 및 유지보수에 매우 높은 우선순위를 가진다. 제대로 문서화되지 않았거나 오래된 메타데이터는 시스템의 장기 생존 가능성을 손상시킬 수 있다.[16][17]

메타데이터에 캡처된 정보

속성 메타데이터

  • 유효성 검사 메타데이터에는 데이터 유형, 허용 값 범위 또는 일련의 값 집합의 멤버십, 정규식 일치, 기본값, 값이 null로 허용되는지 여부 등이 포함된다. 하위 구조로 클래스를 나타내는 EAV 시스템에서 검증 메타데이터는 주어진 속성이 있는 경우 어떤 클래스에 속하는지 기록한다.
  • 프리젠테이션 메타데이터: 사용자에게 속성을 표시하는 방법(예: 텍스트 상자 또는 지정된 차원의 이미지, 풀다운 목록 또는 라디오 버튼 집합) 복합 객체가 EAV/CR 설계에서와 같이 복수의 속성으로 구성되는 경우, 속성이 제시되어야 하는 순서에 따라 추가 메타데이터가 존재하며, 이러한 속성이 선택적으로 그룹화되어야 하는 방법(설명 제목 아래)이 있다.
  • 실험실 매개변수가 되는 속성의 경우 연령, 성별, 생리학적 상태 및 검사 방법에 따라 달라질 수 있는 정상 값의 범위가 기록된다.
  • 메타데이터 그룹화: 속성은 일반적으로 전문성별 형태와 같은 고차 집단의 일부로 표시된다. 메타데이터 그룹화에는 속성이 표시되는 순서와 같은 정보가 포함된다. 글꼴/색상 및 행당 표시되는 속성 수와 같은 특정 프리젠테이션 메타데이터는 그룹 전체에 적용된다.

고급 유효성 검사 메타데이터

  • 종속성 메타데이터: 많은 사용자 인터페이스에서 특정 필드/속성에 특정 값을 입력하여 특정 필드를 비활성화/숨기거나 다른 필드를 활성화/표시해야 한다.(예를 들어, 사용자가 "환자가 당뇨병에 걸렸는가?"라는 부울 질문에 "아니오"를 선택한 경우, 당뇨병 지속 기간에 대한 후속 질문, 당뇨병 등에 대한 약물은 반드시 불구가 되어야 한다.) 이를 일반적 프레임워크에서 실현하기 위해서는 제어 속성과 제어된 속성 사이의 종속성 저장이 포함된다.
  • 계산 및 복잡한 검증: 스프레드시트에서와 같이 특정 속성의 값은 앞서 순서대로 제시된 필드에 입력된 값을 기준으로 계산하여 표시할 수 있다(예를 들어, 신체 표면적은 높이와 너비의 함수). 마찬가지로, 데이터가 유효하려면 "불확실성"이 있을 수 있다. 예를 들어, 차등 백혈구 수에서 개별 백혈구 유형의 카운트의 합은 항상 100이어야 한다. 개별 카운트가 백분율을 나타내기 때문이다. 계산식 및 복잡한 검증은 일반적으로 사용자가 입력하는 값으로 매크로 대체되고 평가될 수 있는 메타데이터에 식을 저장함으로써 영향을 받는다. 웹 브라우저에서 자바스크립트와 VBScript 모두 이러한 목적으로 활용할 수 있는 Eval() 함수를 가지고 있다.

검증, 프리젠테이션 및 그룹화 메타데이터를 사용하면 데이터 브라우징은 물론 대화형 편집 모두를 위한 자동 사용자 인터페이스 생성을 지원하는 코드 프레임워크를 만들 수 있다. 웹을 통해 제공되는 프로덕션 시스템에서 EAV 데이터의 검증 작업은 기본적으로 백엔드/데이터베이스 계층(이 작업에 대해 무력한)에서 중간 /웹 서버 계층으로 이동된다. 백엔드 검증은 항상 이상적이지만, 테이블로 직접 데이터 입력을 시도함으로써 전복되는 것은 불가능하기 때문에 일반 프레임워크를 통한 미들 계층 검증은 상당량의 소프트웨어 설계 노력이 먼저 프레임워크 구축에 들어가야 하지만 상당히 실행 가능하다. 개별 요구에 대해 연구하고 수정할 수 있는 오픈 소스 프레임워크의 가용성은 휠 재발명을 피하는 데 큰 도움이 될 수 있다.[citation needed]

사용 시나리오

(이 섹션의 첫 부분은 센트럴에 있는 디누/나드카니 참조 기사의 프리시스로,[18] 독자가 더 자세한 내용을 지시한다.)

EAV 모델링은 "일반적인 데이터 모델링" 또는 "개방형 스키마"라는 대체 용어로, 오랫동안 고급 데이터 모델러를 위한 표준 도구였다. 다른 진보된 기술처럼, 양날짜로 쓸 수 있고, 현명하게 사용되어야 한다.

또한 EAV의 고용은 동일한 데이터베이스 스키마 내에서 전통적인 관계형 데이터베이스 모델링 접근법의 사용을 배제하지 않는다. 임상 데이터 서브체마에 EAV 접근방식을 사용하는 Cerner와 같이 RDBMS에 의존하는 EMR에서 스키마에서 대부분의 테이블은 사실상 전통적으로 모델링되며, 행이 아닌 개별 열로 표현되는 속성이 있다.

사실, EAV 시스템의 메타데이터 하위 체계의 모델링은 메타데이터의 다양한 구성요소들 사이의 상호관계 때문에 전통적인 모델링에 매우 적합하다. 예를 들어 TrialDB 시스템에서는 스키마의 메타데이터 테이블 수가 데이터 테이블보다 10대 1 정도 많다. 메타데이터의 정확성과 일관성은 EAV 시스템의 정확한 작동에 매우 중요하므로, 시스템 설계자는 RDBMS 엔진 휠을 재창조할 필요 없이 참조 무결성 및 프로그램 가능한 제약조건과 같이 RDBMS가 제공하는 모든 기능을 최대한 활용하고자 한다. 따라서 EAV 설계를 지원하는 수많은 메타데이터 테이블은 일반적으로 제3의 정규 관계형이다.

상용 전자 건강 기록 시스템(EHR)은 별도의 표로 구분된 진단, 수술 절차 및 실험실 테스트 결과와 같은 데이터 클래스에 행-모델링을 사용한다. 각 표에서 "entity"는 환자 ID와 진단을 수행한 날짜/시간(또는 수술 또는 실험실 테스트 수행)의 합성어로서, 속성은 통제된 어휘(예: 진단을 위한 ICD-10, 수술 절차를 위한 현재 절차 용어)를 포함하는 특수 지정 검색 테이블에 외래 키로, 세트가 설정된다. (예를 들어, 실험실 시험 결과의 경우, 측정된 값, 정상, 낮음 또는 높음 범위, 시험을 수행하는 담당자의 ID, 시험을 수행한 날짜/시간 등을 기록할 수 있다.) 앞에서 설명한 바와 같이, 슈퍼마켓의 판매 테이블에 있는 제품 ID의 도메인이 제품 테이블의 제품 도메인으로 제한되는 것처럼, 주어진 테이블에 대한 속성 도메인이 제한되기 때문에 이것은 완전한 EAV 접근법이 아니다.

그러나, 표준 어휘에서 항상 정의되지 않는 파라미터에 대한 데이터를 캡처하기 위해, EHR은 또한 "순수" EAV 메커니즘을 제공한다. 여기서 특별히 지정된 파워 유저는 새로운 속성, 데이터 유형, 최대 및 최소 허용 값(또는 값/코드의 허용 가능한 집합)을 정의하고, 그 다음에 다른 사용자가 이를 기반으로 데이터를 캡처할 수 있도록 허용한다.조공 에픽(TM) EHR에서는 이 메커니즘을 "플로우시트"라고 하며, 일반적으로 입원환자 간병 관찰 데이터를 캡처하는 데 사용된다.

희소 속성 모델링

EAV 모델을 사용하는 일반적인 경우는 위에서 설명한 것처럼 전자 의료 기록(EMR)의 임상 파라미터와 같이 매우 희박하고 이질적인 속성에 대한 것이다. 그러나 여기서도 EAV 모델링 원리가 모든 내용보다는 데이터베이스의 하위 스키마에 적용된다고 기술하는 것이 정확하다.(예를 들어 환자의 인구통계학은 가장 자연스럽게 1열-속성별, 전통적인 관계 구조로 모델링된다.)

따라서 EAV 대 "관계" 설계에 대한 주장은 문제에 대한 불완전한 이해를 반영한다. EAV 설계는 희소성 속성을 모델링해야 하는 데이터베이스의 하위 스키마에 대해서만 채택되어야 한다. 여기서도, 그것들은 세 번째 정규 양식 메타데이터 테이블로 지원되어야 한다. 희소성 속성이 발생하는 데이터베이스 설계 문제는 상대적으로 적다. 따라서 EAV 설계를 적용할 수 있는 상황은 상대적으로 드물다. 이러한 데이터들이 마주치는 경우에도 희박한 데이터를 다룰 수 있는 유일한 방법은 EAV 테이블 집합이 아니다. 즉, 엔티티당 최대 속성 수가 상대적으로 적은 경우 XML 기반 솔루션(아래 설명)을 적용할 수 있으며, 희소성 데이터의 총 볼륨도 이와 유사하게 겸손하다. 이러한 상황의 예로는 다양한 제품 유형에 대한 가변 속성 캡처 문제가 있다.

조직이 광범위하고 매우 다양한 상품군을 구매하거나 판매하는 전자상거래 상황에서도 희소성 속성이 발생할 수 있으며, 개별 상품 범주의 세부내용은 매우 다양하다. Magento 전자상거래 소프트웨어는 이 문제를 해결하기 위해 EAV 접근방식을 채택한다.

클래스당 인스턴스 수가 매우 적은 수많은 클래스 모델링: 매우 동적인 스키마

EAV의 또 다른 적용 분야는 동적인 모델링 클래스 및 속성이다. 그러나 클래스당 데이터 행의 수는 상대적으로 적지만(최대 200개 행이지만 일반적으로 수십 개) 시스템 개발자는 매우 짧은 시간 내에 웹 기반 최종 사용자 인터페이스를 제공해야 한다. 시간. "동적"은 진화하는 데이터 모델을 나타내기 위해 새로운 클래스와 속성을 지속적으로 정의하고 변경해야 함을 의미한다. 이 시나리오는 온톨로지 개발뿐만 아니라 빠르게 진화하는 과학 분야에서도 발생할 수 있으며, 특히 프로토타이핑 및 반복적인 정교화 단계에서 발생할 수 있다.

새로운 범주의 데이터를 나타내기 위한 새로운 테이블과 열의 생성은 특별히 노동 집약적인 것은 아니지만, 유형 및 범위 기반 검증을 통한 탐색 또는 기본 편집을 지원하는 웹 기반 인터페이스의 프로그래밍은 다음과 같다. 이러한 경우에 보다 유지보수가 가능한 장기적 해결책은 클래스 및 속성 정의가 메타데이터에 저장되고, 소프트웨어는 이 메타데이터로부터 기본적인 사용자 인터페이스를 동적으로 생성하는 프레임워크를 만드는 것이다.

앞서 언급한 EAV/CR 프레임워크는 바로 이 상황을 다루기 위해 만들어졌다. 여기서 EAV 데이터 모델은 필수적인 것은 아니지만, 시스템 설계자는 이를 총 2,000개 이하의 행이 포함된 60개 이상의 테이블을 만드는 데 사용할 수 있는 대안이라고 생각할 수 있다. 여기서는 클래스당 행 수가 너무 적기 때문에 효율성 고려사항이 덜 중요하다. 클래스 ID/속성 ID에 의한 표준 인덱싱으로, DBMS 옵티마이저는 해당 클래스 또는 속성과 관련된 쿼리를 실행할 때 메모리의 작은 클래스에 대한 데이터를 쉽게 캐시할 수 있다.

동적 속성 시나리오에서, RDF(Resource Description Framework)가 시멘틱-웹 관련 온톨로지 작업의 기초가 되어 채용되고 있다는 점에 주목할 필요가 있다. RDF는 정보를 표현하는 일반적인 방법으로서 EAV의 한 형태로서, RDF 3중주는 물체, 재산, 그리고 가치로 구성된다.

저자는 존 벤틀리(Jon Bentley)의 저서 '작성 효율화 프로그램(Writing Efficient Programs)'의 끝부분에서 코드를 보다 효율적으로 만들면 일반적으로도 이해와 유지보수가 어려워지기 때문에 성능 문제가 있다고 처음 판단하지 않는 한 서둘러 코드를 수정하지 않으며, 코드 프로파일링과 같은 조치들이 정확한 위치를 정확히 파악했다고 경고한다.병목의 이온 일단 그렇게 하고 나면 더 빨리 실행해야 하는 특정 코드만 수정한다. 유사한 고려사항이 EAV 모델링에도 적용된다. 기존 관계형 모델링이 다루기 어려운 것으로 알려진 하위 시스템(임상 데이터 영역과 동일)에만 적용되거나 시스템 진화 중에 발견되어 상당한 유지보수 문제가 발생하는 경우. 데이터베이스 구루(현재 오라클 Corporation의 핵심 기술 부사장) 톰 Kyte,[20]예를 들어, 정확하게 점 EAV. 오라클의 보건학 사단 자체의 고용(그러나 그는은 전반적인 주장은 EAV 모든 상황에 금물어야만 한다는 것을 사용하기 위해 그냥"유연성"가 아니다 충분한 기준을 만든다 전통적인 사업 시나리오에서 EAV으로 단점 지적한다.E이란 말예요.AV는 상용 시스템인 ClinalTrial[21] 및 Oracle Clinical에서 임상 데이터 속성을 모델링한다.)[22]

EAV 데이터 작업

EAV의 아킬레스건은 대량의 EAV 데이터로 작업하는 것의 어려움이다. 동일한 데이터의 칼럼니어와 행 또는 EAV 모델 표현 간에 일시적 또는 영구적으로 상호 변환해야 하는 경우가 많다. 이는 CPU 집약적일 뿐만 아니라 수동으로 수행하면 오류가 발생하기 쉽다. 속성과 속성 그룹화 메타데이터를 활용하는 일반적인 프레임워크는 전자의 한계를 다루지만 후자의 한계는 다루지 않는다. 이러한 프레임워크의 사용은 전통적인 관계형 데이터와 EAV 데이터가 혼합된 스키마의 경우 다소 의무화되어 있으며, 오류 인수는 매우 중요할 수 있다.

변환 작업을 피벗이라고 한다. 피벗은 EAV 데이터뿐만 아니라 어떤 형태나 행 모델링된 데이터에도 필요하다.(예를 들어, 특정 제품의 구매자도 구매하기 쉬운 다른 제품을 식별하기 위해 슈퍼마켓 판매 데이터를 처리하는 데 널리 사용되는 연합 분석을 위한 Apriori 알고리즘의 구현, 첫 번째 단계로서 피벗 행 모델링된 데이터) 많은 데이터베이스 엔진은 피벗을 용이하게 하기 위해 독점적인 SQL 확장을 가지고 있으며, 마이크로소프트 엑셀과 같은 패키지도 그것을 지원한다. 선회할 필요가 있는 상황은 다음과 같다.

  • 개별 엔터티에 대해 적은 양의 데이터 검색, 선택적으로 상호 종속성에 기반한 데이터 편집. 이 작업은 필요한 지원 메타데이터의 적은 양을 캐싱함으로써 촉진된다. TrialDB와 같은 일부 프로그램은 메타데이터를 보유하는 데이터 구조뿐만 아니라 내장된 프로그래밍 코드가 포함된 정전기 웹 페이지를 생성하기 위해 메타데이터에 액세스한다.
  • 대량 추출은 대량의 데이터(예: 임상 연구의 전체 데이터)를 일련의 관계형 표로 변환한다. CPU 사용량이 많은 동안에는 이 작업이 자주 발생하지 않으며 실시간으로 수행될 필요가 없다. 즉, 사용자는 일괄 처리된 프로세스가 완료될 때까지 기다릴 수 있다. 특히 EAV 구조를 전혀 모르는 표준 제3자 도구로 데이터를 처리하거나 분석하려는 경우에는 대량 추출의 중요성을 과대평가할 수 없다. 여기서, 일반적인 프레임워크를 통해 전체 휠 세트를 재창조하려고 하는 것은 바람직하지 않으며, EAV 데이터를 관계형 테이블로 대량 추출한 다음 표준 도구를 사용하여 작업하는 것이 최선이다.
  • 개별 속성의 관점에서 쿼리할 때(예: "간 질환이 있는 모든 환자를 간기능 장애의 징후가 있고 알코올 남용 이력이 없는 환자") 행 또는 EAV 모델링 데이터에 대한 임시 쿼리 인터페이스는 일반적으로 개별 속성으로 쿼리 결과를 별도의 열로 표시해야 한다. 대부분의 EAV 데이터베이스 시나리오에서 임시 쿼리 성능은 허용 가능해야 하지만, 쿼리는 본질적으로 탐구적인 경향이 있기 때문에 초 미만의 응답은 필요하지 않다.

관계분할

그러나 EAV 데이터 모델의 구조는 관계분할의 완벽한 후보 입니다. 관계대수를 참조하십시오. 훌륭한 인덱싱 전략을 사용하면 10억 행 EAV 테이블에서 수백 밀리초 이내에 응답 시간을 얻을 수 있다. 마이크로소프트 SQL 서버 MVP인 Peter Larsson은 노트북에서 이것을 증명했고 이 솔루션을 일반에 사용할 수 있게 만들었다.[23]

피벗 성능 최적화

  • 한 가지 가능한 최적화는 별도의 "창고" 또는 질의 가능한 스키마를 사용하는 것으로, 이 스키마는 컨텐츠가 생산(트랜잭션) 스키마와 배치 모드로 새로 고쳐진다. 데이터 웨어하우징을 참조하십시오. 창고에 있는 테이블은 여러 테이블을 하나로 묶어 테이블 조인으로 인한 성능 저하를 최소화하도록 디노말라이징을 이용해 고도로 인덱싱되고 최적화된다.
  • 웨어하우스의 특정 EAV 데이터는 "구체화된 뷰"(데이터 웨어하우스 참조)를 사용하여 표준 테이블로 변환할 수 있지만, 이러한 종류의 뷰 수는 시스템의 속성 수와 함께 비선형적으로 증가하는 경향이 있기 때문에 일반적으로 신중하게 사용해야 하는 마지막 수단이다.[14]
  • 메모리 내 데이터 구조: 한 번에 한 그룹씩 데이터를 피벗하기 위해 속성 그룹화 메타데이터와 함께 메모리에 해시 테이블과 2차원 어레이를 사용할 수 있다. 이 데이터는 평평하게 구분된 파일로 디스크에 기록되며, 첫 번째 행의 각 속성에 대한 내부 이름: 이 형식은 관계형 테이블로 쉽게 대량 가져올 수 있다. 이 "메모리 내" 기법은 EAV 테이블에 대한 쿼리를 가능한 한 단순하게 유지하고 I/O 작업 수를 최소화함으로써 대체 접근법을 크게 능가한다.[14] 각 문장은 대량의 데이터를 검색하며, 해시 테이블은 주어진 속성 인스턴스에 대한 값을 적절한 행과 열에 배치하는 것을 포함하는 피벗 작업을 수행하는데 도움이 된다. RAM(Random Access Memory)은 최신 하드웨어에서 충분히 풍부하고 가격이 저렴하여 대규모 데이터 집합에서도 단일 속성 그룹에 대한 전체 데이터 집합이 메모리에 완전히 들어맞을 수 있지만, 알고리즘은 그렇지 않은 경우 데이터 조각에 대해 작업함으로써 더 스마트하게 만들 수 있다.

분명히, 어떤 접근방식을 취하든, EAV를 쿼리하는 것은 특정 유형의 쿼리에 대한 표준 칼럼 모델링 관계 데이터를 쿼리하는 것만큼 빠르지 않을 것이다. 희박한 행렬의 요소 접근은 비파수 행렬의 요소 접근 속도만큼 빠르지 않다. (Sparse matrix, usiii를 나타낸다.링크된 목록과 같은 ng 구조는 주어진 X-Y 위치에서 요소에 접근하기 위해 목록 통과를 요구하는 반면 2-D 어레이로 대표되는 행렬의 요소에 대한 액세스는 빠른 CPU 레지스터 작업을 사용하여 수행할 수 있다.) 그러나 해결하려는 문제에 대해 EAV 접근방식을 올바르게 선택했다면, 이것은 당신이 지불하는 가격이다. 이 점에서 EAV 모델링은 공간(및 스키마 유지보수) 대 CPU 시간 트레이드오프의 예다.

대안

EAV 대 범용 데이터 모델

원래 Maier, Ulman, Vardi에 의해 상정된 "Universal Data Model"(UDM)은 모든 것이 하나의 거대한 "Universal Table"에 저장되어 있다는 착각을 일으키면서, 순진한 사용자에 의한 복잡한 관계 스키마의 질의를 단순화하려고 한다.[24] 사용자가 어떤 테이블에 어떤 속성이 들어 있는지 신경 쓸 필요가 없도록 테이블 간 관계를 활용해 이를 수행한다. C.J. 날짜, however,[25]이 테이블과 다른(위치는 개인의 아버지와 어머니 또한 개인 족보 데이터베이스, 또는 모든 주소 중심적으로, 조직 다른 사무실 주소와 수송 주소를 가질 수 있게 저장된 사업 데이터베이스의 와)과 관련된 상황에서, 그들은 지적했다.eis 데이터베이스 스키마 내에 메타데이터가 부족하여 모호하지 않은 조인을 지정할 수 없음. UDM이 상용화되었을 때 SAP BusinessObjects에서와 같이 이러한 제한은 테이블 세트 사이에 사전 정의된 결합이 있는 관계형 뷰인 "University" 개발자가 서로 다른 별칭을 사용하여 다중 관련 테이블을 뷰에 여러 번 포함시킴으로써 모호한 결합을 모호하게 구분하는 "University"를 생성함으로써 해결된다.

데이터를 명시적으로 모델링하는 방식과는 별도로(UDM은 사용자와 데이터베이스 스키마 사이에서 중재하기 위해 관계형 뷰를 사용함) EAV는 UDM에서처럼 쿼리 지향(읽기 전용) 시스템뿐만 아니라 트랜잭션 시스템에도 적용된다는 점에서 범용 데이터 모델과는 다르다. 또한 임상 데이터 쿼리 시스템의 기초로 사용되는 경우 EAV 구현이 사용자가 관심 객체의 클래스를 지정해야 하는 것을 반드시 보호하지는 않는다. 예를 들어 [26]EAV 기반 i2b2 임상 데이터 마트에서는 사용자가 용어를 검색할 때 사용자가 관심 있는 데이터의 범주를 지정할 수 있는 옵션이 있다. 예를 들어 '리튬'이라는 문구는 약물(양극성 질환 치료에 사용되는 약물)이나 환자의 혈액 내 리튬 농도에 대한 실험실 검사를 가리킬 수 있다. (리튬의 혈액 수준은 주의 깊게 관찰해야 한다: 약물의 과다 섭취는 심각한 부작용을 야기하는 반면, 너무 적은 약물은 효과가 없다.)

XML 및 JSON

개방형 스키마 구현은 표의 XML 열을 사용하여 변수/스파스 정보를 캡처할 수 있다.[27] 유사한 아이디어가 JSON 값 열을 지원하는 데이터베이스에 적용될 수 있다: 희박한 계층적 데이터는 JSON으로 나타낼 수 있다. 데이터베이스에 Postgre와 같은 JSON 지원이 있는 경우SQL 및 (부분적으로) SQL Server 2016 이상, 그런 다음 속성을 쿼리하고 인덱싱하고 결합할 수 있다. 이것은 순진한 EAV 구현에 비해 1000배 이상의 성능 향상을 제공할 수 있지만,[28] 반드시 전체 데이터베이스 애플리케이션을 더욱 견고하게 만드는 것은 아니다.

XML 또는 JSON 데이터를 저장할 수 있는 두 가지 방법이 있다는 점에 유의하십시오. 하나는 데이터베이스 서버에 불투명하고 일반 문자열로 저장하는 것이고, 다른 하나는 구조를 "탐색"할 수 있는 데이터베이스 서버를 사용하는 것이다. 불투명한 문자열을 저장하는 데는 분명 심각한 단점이 있다. 이러한 문자열은 직접 쿼리할 수 없고, 내용에 따라 인덱스를 구성할 수 없으며, 내용에 따라 조인을 수행할 수 없다.

메타데이터 테이블과 애플리케이션 프레임 구조 코드의 관점에서 개발되어야 하는 인프라의 범위 때문에 EAV 모델을 사용할 때 데이터를 관리해야 하는 애플리케이션을 구축하는 것은 매우 복잡해진다. XML을 사용하면 서버 기반 데이터 검증(EAV 기반 프레임워크에서 중간 계층 및 브라우저 기반 코드로 수행해야 함) 문제가 해결되지만 다음과 같은 단점이 있다.

  • 프로그래머 집약적이다. XML 스키마는 손으로 쓰기가 까다롭기로 악명 높으며, 관계형 테이블을 정의하고 XML 스키마 코드를 생성한 다음 이러한 테이블을 삭제하여 스키마를 만드는 것이 권장된다. 이는 특정 애플리케이션 도메인(예: 재고 관리 또는 바이오의약품)을 이해하지만 반드시 프로그래머가 아닌 파워 유저에 의해 새로운 속성이 정의되어야 하는 동적 스키마를 포함하는 많은 생산 작업에서 문제가 된다. 이와는 대조적으로 EAV를 사용하는 프로덕션 시스템에서는 그러한 사용자가 GUI 애플리케이션을 통해 새로운 속성(및 각 속성과 관련된 데이터 유형 및 유효성 검사)을 정의한다. 유효성 검사 관련 메타데이터는 표준화 설계에서 여러 관계형 테이블에 저장해야 하기 때문에, 이러한 테이블을 하나로 묶어 적절한 메타데이터 일관성 검사를 시행하는 GUI 애플리케이션은 최종 결과가 나오더라도 고급 개발자에게도 속성 정보의 입력을 허용하는 유일한 실용적인 방법이다. 별도의 관계 테이블 대신 XML 또는 JSON을 사용한다.
  • 잘못된 데이터를 삽입하려고 시도할 경우(예: 범위 검사 또는 정기적인 표현 패턴 위반) XML/JSON 솔루션과 함께 발생하는 서버 기반 진단은 최종 사용자에게 암호화된다. 오류를 정확하게 전달하려면 최소한 상세하고 사용자 친화적인 오류 진단을 각 속성과 연결해야 한다.
  • 이 솔루션은 사용자 인터페이스 생성 문제를 해결하지 않는다.

위의 단점들은 모두 메타데이터와 애플리케이션 코드의 레이어를 만들어 보완이 가능하지만, 이를 만들면서 프레임워크를 만들지 않아도 된다는 원래의 '장점'은 사라졌다. 사실 희박한 데이터 속성을 강력하게 모델링하는 것은 어떤 스토리지 접근방식을 사용하든 데이터베이스 애플리케이션 설계의 어려운 문제라는 것이다. Sarka의 work,[27] 하지만,( 다른 제품 종류의 예를 들어, 변동하는 제품 특성)은 XML기반 솔루션은EAV-table-based보다 콤팩트가 발생한 상황에서 실체에 특성의 수가 겸손하다.(XM은 data-storage 계층을 위한 형식별 관계 EAV 표 아닌 XML필드를 사용하는 실행 가능성을 증명한다.나는 나는tself는 관계 테이블보다는 구조화된 텍스트에 기초하지만 속성-값 데이터 표현 수단으로 간주될 수 있다.)

트리 구조 및 관계형 데이터베이스

관계형 데이터베이스에서 XML, JSON 또는 중첩된 집합 모델과 같은 다른 형식과 같이 트리 구조화된 데이터를 표현하기 위한 몇 가지 다른 접근법이 존재한다. 한편, 데이터베이스 벤더는 IBM DB2와 같이 XML 데이터가 표와 분리된 XML로 저장되는 IBM DB2와 같이 SQL 문의 일부로 XPath 쿼리를 사용하거나 Postgre에 JSON 및 XML 지원을 데이터 구조와 쿼리 기능에 포함하기 시작했다.인덱싱 및 쿼리할 수 있는 JSON 데이터 유형이[29] 포함된 SQL. 이러한 개발은 EAV 모델 접근방식을 달성, 개선 또는 대체한다.

JSON과 XML의 사용은 중복될 수 있지만 EAV 모델의 사용과 반드시 동일하지는 않다. XML은 단일 엔터티에 대해 볼륨이 비교적 작은 임의 계층적 데이터의 경우 EAV보다 바람직하다. 즉, 데이터 관리 성능에 대해 수 기가바이트 수준으로 확장하려는 의도는 아니다.[citation needed] XML은 희박한 속성 문제와 관련이 없으며, 나타낼 정보의 기초가 되는 데이터 모델을 관계 구조로 쉽게 분해할 수 있을 때, XML은 1차 스토리지 메커니즘보다는 데이터 교환의 수단으로 더 적합하다. 앞에서 설명한 것처럼 EAV는 희소속 시나리오에만 특별히 적용된다. 그러한 시나리오가 존재할 때, 엔티티, 속성, 그리고 단순한 SQL 문을 통해 조작되고 인덱싱될 수 있는 데이터 유형별 속성-값 테이블의 사용은 XML 트리 구조의 사용보다 훨씬 더 확장성이 높다.[citation needed] 위에서 언급된 구글 앱 엔진은 타당한 이유로 강력한 형식의 가치표를 사용한다.[citation needed][citation needed]

그래프 데이터베이스

EAV 구조화된 데이터와 관련된 다양한 문제를 관리하기 위한 대안적인 접근법은 그래프 데이터베이스를 사용하는 것이다. 이것들은 도면요소를 그래프나 하이퍼그래프의 노드로 나타내며, 속성은 해당 그래프의 링크나 가장자리로 나타낸다. 테이블 조인의 문제는 Apache TinkerPop이나 [30]OpenCog atomspace 패턴 매처와 같은 그래프별 쿼리 언어를 제공함으로써 해결된다.[31]

SPARQL 저장소를 이용하는 것도 하나의 대안이다.

서버 소프트웨어에 대한 고려 사항

PostgreSQL: JSONB 열

PostgreSQL 버전 9.4에는 쿼리, 색인화 및 결합이 가능한 JSON 이진 열(JSONB)에 대한 지원이 포함되어 있다. 이를 통해 기존 EAV 테이블 설계보다 1,000개 이상의 요인에 의한 성능 향상이 가능하다.[28]

JSONB를 기반으로 하는 db 스키마는 항상 적은 수의 테이블을 가지고 있다. 즉, 엔티티 테이블의 JSONB 유형 필드에 속성-값 쌍을 중첩시킬 수 있다. 그것은 DB 스키마를 이해하기 쉽고 SQL 쿼리를 간결하게 만든다.[32] 추상화 계층에서 데이터베이스 개체를 조작하는 프로그래밍 코드는 훨씬 더 짧아진다.[33]

SQL Server 2008 이상: 스파스 열

Microsoft SQL Server 2008은 EAV에 대한 (수용) 대안을 제공한다.[34] 원자 데이터 유형(예: 숫자, varchar 또는 datetime 열)이 있는 열은 CREATE TABLE 문의 열 정의에 스파스라는 단어를 포함하기만 하면 희소성으로 지정할 수 있다. 희소 열은 NULL 값 저장을 최적화하며(지금은 공간을 전혀 차지하지 않음) 표의 대다수 레코드가 해당 열에 대해 NULL 값을 가질 때 유용하다. 희소성 열의 인덱스도 최적화된다. 값이 있는 행만 인덱싱된다. 또한 테이블의 특정 행에 있는 모든 희소 열의 내용을 하나의 XML 컬럼(컬럼 세트)으로 일괄 집계할 수 있으며, 그 내용은 형식이다. [<column-name>column contents </column-name>]*.... 실제로 CREATE TABLE 문장의 일부로 표에 대해 열 집합을 정의한 경우 후속으로 정의된 모든 희소 열은 일반적으로 표에 추가된다. 이것은 SQL 문이라는 흥미로운 결과를 가지고 있다. SELECT * from <tablename> 개별 희소 열은 반환하지 않지만, 모든 희소 열을 열 집합의 이름인 단일 XML 열(따라서 가상의 계산된 열 역할을 함)으로 연결한다. 희소성 컬럼은 제품 종류에 따라 적용 가능한 속성이 크게 변동될 수 있지만 제품 종류별 총 가변 속성 수가 상대적으로 적은 사업용 정보 등에 편리하다.

스파스 속성의 제한 사항

그러나 희박한 속성을 모델링하는 이 접근방식은 몇 가지 한계가 있다. 경쟁 DBMS는 특히 자신의 엔진을 위해 이 아이디어를 빌리지 않기로 선택했다. 제한 사항:

  • 표의 최대 희소 열 수는 10,000개로 임상 데이터 저장과 같은 일부 구현에서는 부족할 수 있으며, 여기서 가능한 속성 수는 1배 더 크다. 따라서 이는 환자의 *모든* 가능한 임상 속성을 모델링하는 솔루션이 아니다.
  • EAV 모델이 모색될 수 있는 주요 이유 중 하나인 새로운 속성의 추가는 여전히 DBA가 필요하다. 또한, 희박한 속성 데이터를 위한 사용자 인터페이스를 구축하는 문제는 다루어지지 않으며, 스토리지 메커니즘만 합리화된다. * 애플리케이션은 런타임에 테이블에서 희박한 열을 동적으로 추가 및 제거하기 위해 작성될 수 있다. 이와는 대조적으로 다른 사용자/프로세스가 여전히 테이블을 사용하고 있는 다중 사용자 시나리오에서 그러한 작업을 수행하려는 시도는 희박한 열이 없는 테이블에 대해 금지될 수 있다. 그러나, 이 능력은 힘과 유연성을 제공하지만, 오용을 유발하며, 신중하고 드물게 사용되어야 한다.
    • 이 표를 사용하는 컴파일된 쿼리 계획은 자동으로 무효화되기 때문에 상당한 성능 저하를 초래할 수 있다.
    • 동적 칼럼 추가 또는 제거는 감사해야 하는 작업이다. 칼럼 제거는 데이터 손실을 유발할 수 있기 때문이다. 즉, 응용프로그램이 조치의 정당성을 포함한 어떤 종류의 추적을 유지하지 않고 테이블을 수정할 수 있도록 허용하는 것은 좋은 소프트웨어 관행은 아니다.
  • SQL 제약 조건(예: 범위 검사, 정규식 검사)은 스파스 열에 적용할 수 없다. 적용되는 유일한 점검은 정확한 데이터 유형이다. 제약조건은 프로덕션 EAV 시스템에서와 같이 메타데이터 테이블과 중간 계층 코드에 구현되어야 할 것이다. (이 고려사항은 비즈니스 애플리케이션에도 적용된다.)
  • SQL Server는 열의 저장 형식 변경을 시도하는 경우 행 크기에 제한이 있다. 즉, 데이터가 포함된 행에 있는 모든 원자 데이터 유형 열의 총 내용(스파스 및 비스파스)은 8016바이트를 초과할 수 없다.
  • 데이터가 포함된 희소 열은 데이터 유형 자체(예: 날짜/시간 열의 경우 4바이트)에 대한 저장 외에 열당 4바이트의 저장 오버헤드가 있다. 이는 지정된 행과 연결할 수 있는 희소 열 데이터의 양에 영향을 미친다. 이 크기 제한은 varchar 데이터 유형에 대해 완화되는데, 이는 생산 시스템에서 행 크기 제한에 도달하면 내재가 다른 데이터 유형을 가질 수 있더라도 희소 열을 varchar로 지정하여 작업해야 함을 의미한다. 불행하게도, 이 접근방식은 서버측 데이터 유형 검사를 대체한다.

클라우드 컴퓨팅 제품

많은 클라우드 컴퓨팅 벤더는 EAV 모델에 기반한 데이터 저장소를 제공하며, 여기서 임의의 수의 속성이 주어진 엔티티와 연관될 수 있다. 로저 제닝스는 이것들에 대한 심층적인 비교를[35] 제공한다. 아마존 오퍼링인 SimpleDB에서는 데이터 유형이 문자열로 제한되며, 본질적으로 문자열이 아닌 데이터는 정렬 등의 작업을 수행하려면 문자열(예: 숫자가 선행 0으로 패딩되어야 함)으로 강제해야 한다. 마이크로소프트가 제공하는 Windows Azure Table Storage는 바이트[], bool, DateTime, double, Guid, int, long 및 문자열[1]의 제한된 데이터 유형을 제공한다. 구글 앱 엔진[2]은 숫자 데이터를 int, long 또는 float로 나누는 것 외에도 전화번호, e-mail 주소, 지오코드, 하이퍼링크와 같은 사용자 정의 데이터 유형을 정의한다. 아마존이나 마이크로소프트가 아닌 구글은 메타데이터 모델을 만들 수 있게 함으로써 잘못된 속성이 특정 종류의 엔티티와 연관되지 않도록 하는 메타데이터를 정의할 수 있다.

구글은 당신이 SQL의 서브셋을 사용하여 데이터를 조작할 수 있도록 해주고, 마이크로소프트는 LINQ 공급자를 통해 추상화된 URL 기반 쿼리 구문을 제공하며, 아마존은 보다 제한된 구문을 제공한다. 우려되는 것은, 결합을 통해 서로 다른 실체를 결합하기 위한 내장형 지원은 현재 (10년 4월) 세 엔진 모두 존재하지 않는다는 점이다. 이러한 작업은 애플리케이션 코드에 의해 수행되어야 한다. 이는 애플리케이션 서버가 벤더의 데이터 센터의 데이터 서버와 공동 배치되는 경우 문제가 되지 않을 수 있지만, 두 서버가 지리적으로 분리되어 있다면 많은 네트워크 트래픽이 생성될 것이다.

EAV 접근방식은 모델링되는 속성이 많고 희박한 경우에만 정당화된다. 캡처되는 데이터가 이 요구 사항을 충족하지 못할 경우 클라우드 공급업체의 기본 EAV 접근방식은 종종 진정한 백엔드 데이터베이스를 필요로 하는 애플리케이션(단순히 지속되는 데이터 저장 수단과는 대조적으로)의 불일치가 된다. 전통적인 데이터 모델링 방식을 사용하는 기존 데이터베이스 애플리케이션의 대다수를 EAV 유형의 클라우드 아키텍처에 개조하려면 큰 수술이 필요할 것이다. 예를 들어, 마이크로소프트는 데이터베이스-애플리케이션-개발자 기반이 그러한 노력의 투자를 대부분 꺼린다는 것을 발견했다. 따라서 최근에 마이크로소프트는 클라우드 액세스 가능한 본격적인 관계형 엔진인 SQL 서버 Azure라는 프리미엄 제품을 제공했는데, 이는 기존 데이터베이스 애플리케이션을 약간의 변경으로 포팅할 수 있게 해준다.

SQL Azure의 한 가지 제한사항은 2015년 1월 현재 물리적 데이터베이스의 크기가 500GB로 제한되어 있다는 것이다.[36] 마이크로소프트는 이보다 큰 데이터 세트를 여러 개의 물리적 데이터베이스로 분할하여 병렬 쿼리로 액세스할 것을 권장한다.

참고 항목

참조

  1. ^ Free Software Foundation (10 June 2007), GNU Emacs Lisp Reference Manual, Boston, MA: Free Software Foundation, pp. Section 5.8, "Association Lists", archived from the original on 2011-10-20
  2. ^ Apache Foundation, UIMA 자습서 및 사용자 가이드. url: http://uima.apache.org/downloads/releaseDocs/2.1.0-incubating/docs/html/tutorials_and_users_guides/tutorials_and_users_guides.html. 2012년 10월 접속,
  3. ^ Stead, W.W.; Hammond, W.E.; Straube, M.J. (1982), "A Chartless Record—Is It Adequate?", Proceedings of the Annual Symposium on Computer Application in Medical Care, 7 (2 November 1982): 89–94, doi:10.1007/BF00995117, PMC 2580254, PMID 6688264
  4. ^ McDonald, C.J.; Blevins, L.; Tierney, W.M.; Martin, D.K. (1988), "The Regenstrief Medical Records", MD Computing, 5 (5): 34–47, PMID 3231034
  5. ^ Pryor, T. Allan (1988). "The HELP medical record system". M.D. Computing. 5 (5): 22–33. PMID 3231033.
  6. ^ Warner, H. R.; Olmsted, C. M.; Rutherford, B. D. (1972), "HELP—a program for medical decision-making", Comput Biomed Res, 5 (1): 65–74, doi:10.1016/0010-4809(72)90007-9, PMID 4553324
  7. ^ Friedman, Carol; Hripcsak, George; Johnson, Stephen B.; Cimino, James J.; Clayton, Paul D. (1990), "A Generalized Relational Schema for an Integrated Clinical Patient Database", Proceedings of the Annual Symposium on Computer Application in Medical Care: 335–339, PMC 2245527
  8. ^ a b Nadkarni, MD, Prakash M.; Marenco, MD, Luis; Chen, MD, Roland; Skoufos, PhD, Emmanouil; Shepherd, MD, DPhil, Gordon; Miller, MD, PhD, Perry (1999), "Organization of Heterogeneous Scientific Data Using the EAV/CR Representation", Journal of the American Medical Informatics Association, 6 (6): 478–493, doi:10.1136/jamia.1999.0060478, PMC 61391, PMID 10579606CS1 maint: 여러 이름: 작성자 목록(링크)
  9. ^ a b Marenco, Luis; Tosches, Nicholas; Crasto, Chiquito; Shepherd, Gordon; Miller, Perry L.; Nadkarni, Prakash M. (2003), "Achieving Evolvable Web-Database Bioscience Applications Using the EAV/CR Framework: Recent Advances", Journal of the American Medical Informatics Association, 10 (5): 444–53, doi:10.1197/jamia.M1303, PMC 212781, PMID 12807806
  10. ^ 보훈처: Wayback 기계에 2006-02-21 보관된 재향군인 보건국
  11. ^ * Nadkarni, Prakash, The EAV/CR Model of Data Representation, retrieved 1 February 2015
  12. ^ Nadkarni, P. M.; Marenco, L; Chen, R; Skoufos, E; Shepherd, G; Miller, P (1999), "Organization of Heterogeneous Scientific Data Using the EAV/CR Representation", Journal of the American Medical Informatics Association, 6 (6): 478–493, doi:10.1136/jamia.1999.0060478, PMC 61391, PMID 10579606
  13. ^ Marenco, L; Tosches, N; Crasto, C; Shepherd, G; Miller, P. L.; Nadkarni, P. M. (2003), "Achieving Evolvable Web-Database Bioscience Applications Using the EAV/CR Framework: Recent Advances", Journal of the American Medical Informatics Association, 10 (5): 444–453, doi:10.1197/jamia.M1303, PMC 212781, PMID 12807806
  14. ^ a b c Dinu, Valentin; Nadkarni, Prakash; Brandt, Cynthia (2006), "Pivoting approaches for bulk extraction of Entity–Attribute–Value data", Computer Methods and Programs in Biomedicine, 82 (1): 38–43, doi:10.1016/j.cmpb.2006.02.001, PMID 16556470
  15. ^ GB 2384875, Dingley, Andrew Peter, 2003년 8월 6일 발행된 "준구조화된 데이터의 저장 및 관리"는 Hewlett Packard에 할당되었다.
  16. ^ Nadkarni, Prakash M. (9 June 2011). Metadata-driven Software Systems in Biomedicine: Designing Systems that can adapt to Changing Knowledge. Springer. ISBN 978-0857295095.
  17. ^ Nadkarni, Prakash (2011), Metadata-driven Software Systems in Biomedicine, Springer, ISBN 978-0-85729-509-5
  18. ^ Dinu, Valentin; Nadkarni, Prakash (2007), "Guidelines for the effective use of entity-attribute-value modeling for biomedical databases", International Journal of Medical Informatics, 76 (11–12): 769–79, doi:10.1016/j.ijmedinf.2006.09.023, PMC 2110957, PMID 17098467
  19. ^ Magento 데이터베이스: 개념과 아키텍처. URL: http://www.magentocommerce.com/wiki/2_-_magento_concepts_and_architecture/magento_database_diagram . 2015년 7월 접속.
  20. ^ 키테, 토마스. 설계별 효과적인 오라클. 오라클 프레스, 맥그로우 힐 오스본 미디어 2003년 8월 21일. 2003년 8월 21일. http://asktom.oracle.com/pls/asktom/f?p=100:11:0:::P11_질문_ID:10678084117056
  21. ^ "Oracle Health Sciences Clintrial - Oracle". www.oracle.com.
  22. ^ "Oracle Clinical - Overview - Oracle". www.oracle.com.
  23. ^ "Relationally Divided over EAV".
  24. ^ 데이비드 마이어, 제프리 울먼, 모셰 바디. 보편적 관계 모델의 기초 위에. 데이터베이스 시스템에 대한 ACM 트랜잭션(TODS). 제9권 1984년 6월 2호 페이지 283-308. URL: http://dl.acm.org/citation.cfm?id=318580
  25. ^ 범용 데이터베이스 설계. "데이터베이스 시스템에 대한 소개"에서 Pearson/Addison Wesley, 2003.
  26. ^ Murphy, S. N.; Weber, G; Mendis, M; Gainer, V; Chueh, H. C.; Churchill, S; Kohane, I (2010), "Serving the enterprise and beyond with informatics for integrating biology and the bedside (i2b2)", Journal of the American Medical Informatics Association, 17 (2): 124–130, doi:10.1136/jamia.2009.000893, PMC 3000779, PMID 20190053
  27. ^ a b Itzik Ben-Gan, Dejan Sarka, Inside Microsoft SQL Server 2008: T-SQL 프로그래밍(Microsoft Press)
  28. ^ a b Jeroen Coussement, "2016년 PostgreSQL에서 EAV와 JSONB 교체"
  29. ^ Postgres 9.6, "JSON 유형"
  30. ^ TinkerPop, Apache. "Apache TinkerPop". tinkerpop.apache.org.
  31. ^ "Pattern matching - OpenCog". wiki.opencog.org.
  32. ^ "JsQuery – Json 쿼리 언어 및 GIN 인덱싱 지원"(2014)
  33. ^ "7cart 프로젝트 - Shopify와 Magento의 미래 대안" (2019)
  34. ^ BYHAM. "Use Sparse Columns". msdn.microsoft.com.
  35. ^ Jennings, Roger (2009), "Retire your Data Center", Visual Studio Magazine, February 2009: 14–25
  36. ^ Lardinois, Frederic. "Microsoft's Azure SQL Can Now Store Up To 500GB, Gets 99.95% SLA And Adds Self-Service Recovery - TechCrunch".