데이터베이스 모델
Database model데이터베이스 모델은 데이터베이스의 논리 구조를 결정하는 데이터 모델의 한 유형입니다.기본적으로 데이터를 저장, 구성 및 조작할 수 있는 방법을 결정합니다.데이터베이스 모델의 가장 일반적인 예는 테이블 기반 형식을 사용하는 관계형 모델입니다.
종류들
데이터베이스의 일반적인 논리 데이터 모델은 다음과 같습니다.
- 데이터베이스 모델의 가장 오래된 형식입니다.IBM이 IMS(Information Management System)용으로 개발했습니다.트리 구조의 정리된 데이터 세트입니다.DB 레코드는 세그먼트라고 하는 여러 그룹으로 구성된 트리입니다.1대 다의 관계를 사용합니다.데이터 액세스도 예측할 수 있습니다.
객체-관계형 데이터베이스는 관련된 두 구조를 결합합니다.
물리 데이터 모델에는 다음이 포함됩니다.
기타 모델은 다음과 같습니다.
관계 및 기능
소정의 데이터베이스 관리 시스템은 하나 이상의 모델을 제공할 수 있다.최적의 구조는 애플리케이션 데이터의 자연스러운 구성과 트랜잭션 속도(속도), 신뢰성, 유지보수성, 확장성 및 비용 등의 애플리케이션 요구사항에 따라 달라집니다.대부분의 데이터베이스 관리 시스템은 하나의 특정 데이터 모델을 기반으로 구축되지만 제품이 여러 모델을 지원할 수도 있습니다.
다양한 물리 데이터 모델이 임의의 논리 모델을 구현할 수 있습니다.대부분의 데이터베이스 소프트웨어는 사용자가 물리적인 구현을 조정할 때 어느 정도 제어할 수 있도록 합니다.이는 선택에 따라 퍼포먼스에 큰 영향을 미치기 때문입니다.
모델은 단순히 데이터를 구조화하는 방법이 아니라 데이터에 [1]대해 수행할 수 있는 일련의 작업도 정의합니다.예를 들어 관계 모델은 선택(프로젝트) 및 결합과 같은 작업을 정의합니다.이러한 연산은 특정 쿼리 언어에서는 명시적이지 않을 수 있지만 쿼리 언어가 구축되는 기반을 제공합니다.
플랫 모델
평면(또는 표) 모델은 단일 2차원 데이터 요소 배열로 구성되며, 여기서 주어진 열의 모든 구성원은 유사한 값으로 간주되고 행의 모든 구성원은 서로 관련이 있는 것으로 간주됩니다.예를 들어 시스템 보안 데이터베이스의 일부로 사용할 수 있는 이름 및 암호 열입니다.각 행에는 개별 사용자와 관련된 특정 암호가 있습니다.표의 열에는 종종 문자 데이터, 날짜 또는 시간 정보, 정수 또는 부동 소수점 숫자로 정의하는 유형이 관련되어 있습니다.이 표 형식은 관계형 모델의 전조입니다.
초기 데이터 모델
이 모델들은 1960년대와 1970년대에 인기가 있었지만, 오늘날에는 주로 오래된 레거시 시스템에서 찾아볼 수 있다.이러한 기능은 주로 논리적 표현과 물리적 표현 간의 강한 연관성과 데이터 독립성 결여로 인해 탐색할 수 있는 것이 특징입니다.
계층 모형
계층형 모델에서 데이터는 각 레코드에 대해 단일 부모를 의미하는 나무와 같은 구조로 구성됩니다.정렬 필드는 형제 레코드를 특정 순서로 보관합니다.계층 구조는 IBM의 IMS(Information Management System)와 같은 초기 메인프레임 데이터베이스 관리 시스템에서 널리 사용되었으며, 현재는 XML 문서의 구조를 설명합니다.이 구조를 통해 두 유형의 데이터 간에 일대다 관계가 가능합니다.이 구조는 레시피, 목차, 문단/버전 순서, 중첩 및 정렬된 정보 등 실제 세계에서의 많은 관계를 설명하는 데 매우 효율적입니다.
이 계층은 저장소에서 레코드의 물리적 순서로 사용됩니다.레코드 액세스는 순차적 액세스와 결합된 포인터를 사용하여 데이터 구조를 아래로 탐색함으로써 이루어집니다.따라서 (상향 링크 및 정렬 필드가 아닌) 전체 경로가 각 레코드에 포함되지 않으면 계층 구조는 특정 데이터베이스 작업에 비효율적입니다.이러한 제한은 이후의 IMS 버전에서 기본 물리 계층에 부과되는 추가 논리 계층에 의해 보완되었습니다.
네트워크 모델
네트워크 모델은 계층 구조를 확장하여 여러 부모 구조를 허용하는 트리 같은 구조에서 다대다 관계를 가능하게 합니다.이것은 관계형 모델로 대체되기 전에 가장 많이 사용되었으며 CODASYL 규격으로 정의된다.
네트워크 모델은 레코드와 세트라고 불리는 두 가지 기본 개념을 사용하여 데이터를 구성합니다.레코드에는 필드(프로그래밍 언어 COBOL과 같이 계층적으로 구성될 수 있음)가 포함됩니다.집합(수학 집합과 혼동하지 말 것)은 레코드 간의 일대다 관계를 정의합니다. 즉, 소유자 1명, 멤버 다수입니다.레코드는 임의의 수의 세트의 소유자가 될 수 있으며 임의의 수의 세트의 멤버가 될 수 있습니다.
세트는 원형 링크 리스트로 구성됩니다.여기서 레코드 유형(세트 소유자 또는 부모)이 각 원에 1회 표시되고, 두 번째 레코드 유형(하위 또는 자식)이 각 원에 여러 번 표시될 수 있습니다.이와 같이 2종류의 레코드 타입 사이에 계층을 확립할 수 있습니다.예를 들어 타입 A는 B의 오너입니다.동시에 B가 A의 소유자일 때 다른 세트를 정의할 수 있다.따라서 모든 세트는 일반 방향 그래프(소유권은 방향을 정의함) 또는 네트워크 구성을 포함합니다.레코드에 대한 액세스는 순차적으로(보통 각 레코드 유형에서) 또는 순환 링크 목록의 네비게이션을 통해 이루어집니다.
네트워크 모델은 계층형 모델보다 데이터의 용장성을 더 효율적으로 나타낼 수 있으며 상위 노드에서 하위 노드로 가는 경로가 여러 개 있을 수 있습니다.네트워크 모델의 조작은 네비게이션 방식으로 이루어집니다.프로그램은 현재 위치를 유지하고 레코드가 참여하는 관계를 따라 레코드 간에 네비게이트합니다.키 값을 입력하여 레코드를 찾을 수도 있습니다.
모델의 필수적인 기능은 아니지만, 네트워크 데이터베이스는 일반적으로 디스크 상의 레코드의 위치를 직접 다루는 포인터에 의해 설정된 관계를 구현합니다.따라서 데이터베이스 로드 및 재구성 등의 작업을 희생하면서 뛰어난 검색 성능을 얻을 수 있습니다.
Cincom Systems의 Total과 Cullinet의 IDMS가 널리 사용되고 있습니다.IDMS는 1980년대에 독자적인 툴과 언어에 더해 관계형 모델과 SQL을 채택했습니다.
대부분의 오브젝트 데이터베이스(1990년대에 발명)는 네비게이션 개념을 사용하여 오브젝트 네트워크를 통해 고속 네비게이션을 제공하며, 일반적으로 오브젝트 식별자를 관련 오브젝트에 대한 "스마트" 포인터로 사용합니다.예를 들어, 객관성/DB는 데이터베이스를 교차할 수 있는 일대일, 일대다, 다대일 및 다대다라는 이름의 관계를 구현합니다.또한 많은 객체 데이터베이스는 SQL을 지원하며 두 모델의 장점을 결합합니다.
반전 파일 모델
반전 파일 또는 반전 인덱스에서 데이터의 내용은 룩업 테이블의 키로 사용되며, 테이블 내의 값은 주어진 콘텐츠 항목의 각 인스턴스의 위치를 가리키는 포인터이다.이는 현대 데이터베이스 인덱스의 논리 구조이기도 하며, 룩업 테이블의 특정 열의 내용만 사용할 수 있습니다.반전된 파일 데이터 모델은 기존 플랫 데이터베이스 파일 옆에 있는 파일 세트에 인덱스를 배치하여 이러한 파일의 필요한 레코드에 효율적으로 액세스할 수 있습니다.
1970년에 도입된 소프트웨어 AG의 ADABAS DBMS가 이 데이터 모델을 사용하는 것으로 주목됩니다.ADABAS는 상당한 고객 기반을 확보하여 현재까지도 존재하며 지원되고 있습니다.1980년대에는 원래의 툴과 언어에 더해 관계형 모델과 SQL을 채택했습니다.
문서 지향 데이터베이스 Clusterpoint는 역색인 모델을 사용하여 XML 또는 JSON 데이터 개체에 대한 전체 텍스트 검색을 빠르게 제공합니다.
관계형 모델
관계형 모델은 E.F.에 의해 도입되었습니다. 데이터베이스 관리 시스템을 특정 애플리케이션으로부터 더욱 독립시키기 위한 방법으로 1970년에[2] Codd.술어 로직과 집합론의 관점에서 정의된 수학적 모델이며, 메인프레임, 미드레인지 및 마이크로컴퓨터 시스템에서 구현되어 왔습니다.
일반적으로 관계형 데이터베이스라고 불리는 제품들은 사실상 Codd에 의해 정의된 수학적 모델에 대한 근사치에 불과한 모델을 구현한다.관계형 데이터베이스 모델에서는 관계, 속성 및 도메인의 3가지 주요 용어가 광범위하게 사용됩니다.관계는 열과 행이 있는 테이블입니다.이 관계의 명명된 열을 속성이라고 하며 도메인은 속성이 취할 수 있는 값의 집합입니다.
관계 모형의 기본 데이터 구조는 표이며, 여기서 특정 엔티티(예: 직원)에 대한 정보는 행(튜플이라고도 함)과 열로 표시됩니다.따라서 "관계 데이터베이스"의 "관계"는 데이터베이스의 다양한 테이블을 참조하며, 관계는 튜플 집합입니다.열에는 엔티티의 다양한 속성(종업원의 이름, 주소, 전화번호 등)이 열거되어 있으며 행은 해당 관계에 의해 표현되는 엔티티(특정 직원)의 실제 인스턴스입니다.그 결과, 종업원 테이블의 각 태플은 한 종업원의 다양한 종업원의 속성을 나타냅니다.
관계 데이터베이스 내의 모든 관계(및 표)는 몇 가지 기본 규칙을 준수해야 관계 자격을 얻을 수 있습니다.첫째, 표에서 열의 순서는 중요하지 않습니다.둘째, 테이블에 동일한 튜플이나 행을 포함할 수 없습니다.셋째, 각 태플에는 각 속성에 대한 단일 값이 포함됩니다.
관계형 데이터베이스에는 "평면" 데이터베이스 모델의 테이블과 유사한 테이블이 여러 개 포함되어 있습니다.관계모형의 강점 중 하나는 원칙적으로 두 개의 서로 다른 기록(같은 표 또는 다른 표에 속함)에서 발생하는 모든 가치가 두 기록 사이의 관계를 의미한다는 것이다.단, 명시적인 무결성 제약을 적용하기 위해 카디널리티(1:1, (0)1:M, M:M)를 할당하는 것으로 특징지어지는 부모-자녀 관계를 식별하거나 식별하지 않음으로써 테이블 내의 레코드 간의 관계를 명시적으로 정의할 수도 있습니다.테이블은 지정된 단일 속성 또는 "키"로서 기능할 수 있는 속성 세트를 가질 수도 있습니다.테이블 내의 각 태플을 일의로 식별하기 위해 사용할 수 있습니다.
테이블 내의 행을 일의로 식별하기 위해 사용할 수 있는 키를 프라이머리 키라고 부릅니다.키는 일반적으로 두 개 이상의 테이블에서 데이터를 결합하거나 결합하는 데 사용됩니다.예를 들어 직원 테이블에는 위치 테이블의 키와 일치하는 값이 들어 있는 위치라는 열이 포함될 수 있습니다.또한 큰 테이블에서 데이터를 빠르게 검색할 수 있도록 지원하는 인덱스를 작성할 때도 키가 중요합니다.임의의 열이 하나의 키가 될 수도 있고 여러 열을 하나의 복합 키로 그룹화할 수도 있습니다.모든 키를 미리 정의할 필요는 없습니다.열은 원래 키가 아니더라도 키로 사용할 수 있습니다.
사람의 이름, 책의 ISBN 또는 자동차의 일련번호와 같은 외부의 실제 의미를 갖는 키를 "자연" 키라고 부르기도 합니다.적절한 자연 키가 없는 경우(Brown이라는 이름의 많은 사용자를 고려), 임의의 키 또는 대리 키를 할당할 수 있습니다(직원에게 ID 번호를 부여하는 등).실제로 대부분의 데이터베이스에는 생성 키와 자연 키가 모두 있습니다.생성된 키는 내부에서 끊을 수 없는 행 간의 링크를 작성하기 위해 사용할 수 있지만 자연 키는 검색 및 다른 데이터베이스와의 통합에 신뢰성이 떨어지기 때문입니다.(예를 들어 독립적으로 개발된2개의 데이터베이스 내의 레코드는 s에 의해 대조될 수 있습니다).사회보장번호(사회보장번호가 잘못되었거나 누락된 경우 또는 변경된 경우 제외)
관계형 모델에서 사용되는 가장 일반적인 쿼리 언어는 SQL(Structured Query Language)입니다.
치수 모형
치수 모델은 온라인 분석 처리 또는 OLAP 쿼리를 사용하여 데이터를 쉽게 요약할 수 있도록 데이터 웨어하우스의 데이터를 표현하기 위해 사용되는 관계형 모델을 전문적으로 채택한 것입니다.차원 모델에서 데이터베이스 스키마는 차원 및 측도를 사용하여 설명하는 하나의 큰 사실 테이블로 구성됩니다.차원은 사실의 컨텍스트(누가 참여했는지, 언제, 어디서 발생했는지, 유형 등)를 제공하며 관련 사실을 그룹화하기 위한 질의에 사용됩니다.치수는 이산적인 경향이 있으며 종종 계층적입니다. 예를 들어 위치에는 건물, 주 및 국가가 포함될 수 있습니다.측정치는 수익과 같은 사실을 설명하는 수량입니다.측정치를 의미 있게 집계하는 것이 중요합니다. 예를 들어, 서로 다른 위치의 수익을 합산할 수 있습니다.
OLAP 쿼리에서는 치수가 선택되고 팩트가 그룹화 및 집약되어 요약이 작성됩니다.
치수 모델은 종종 사실을 포함하는 하나의 고도로 정규화된 표와 각 차원을 포함하는 주변 정규화된 표로 구성된 스타 스키마를 사용하여 관계형 모델 위에 구현됩니다.Snowflake 스키마라고 불리는 대체 물리적 구현은 차원 내의 다단계 계층을 여러 테이블로 정규화합니다.
데이터 웨어하우스에는 차원 테이블을 공유하는 여러 차원 스키마를 포함할 수 있으므로 함께 사용할 수 있습니다.표준 치수 세트를 고안하는 것은 치수 모델링의 중요한 부분입니다.
높은 성능으로 인해 치수 모델은 OLAP에 가장 인기 있는 데이터베이스 구조가 되었습니다.
사후 관계형 데이터베이스 모델
관계형 모델보다 더 일반적인 데이터 모델을 제공하는 제품은 때때로 사후 [3]관계형으로 분류됩니다.대체 용어로는 "하이브리드 데이터베이스", "개체 확장 RDBMS" 등이 있습니다.이러한 제품의 데이터 모델은 관계를 통합하지만 E.F.에 의해 제약을 받지 않는다. Codd's Information Principle(정보의 원칙)은 다음과 같습니다.
데이터베이스 내의 모든 정보는 관계에서의 가치의 관점에서 명시적으로 주조되어야 하며 다른 방법으로 주조되어서는 안 된다.
--
관계형 모델에 대한 이러한 확장 중 일부는 관계형 모델 이전의 기술에서 나온 개념을 통합한다.예를 들어 노드에 트리가 있는 방향 그래프를 표시할 수 있습니다.독일 기업은 이 개념을 GraphDB에 구현하고 있습니다.
일부 사후 관계형 제품은 비 관계형 기능을 사용하여 관계형 시스템을 확장합니다.다른 것들은 사전 관계형 시스템에 관계형 기능을 추가함으로써 거의 같은 위치에 도달했습니다.역설적으로, PICK나 MUMP와 같이 역사적으로 관계가 이전이었던 제품들은 관계가 이후라는 그럴듯한 주장을 할 수 있다.
RSM(Resource Space Model)은 다차원 [5]분류에 기반한 비관계형 데이터 모델입니다.
그래프 모형
그래프 데이터베이스는 네트워크 데이터베이스보다 더 일반적인 구조를 제공합니다.노드는 다른 노드에 접속할 수 있습니다.
다중값 모델
다중값 데이터베이스는 관계형 데이터베이스와 동일한 방식으로 저장할 수 있다는 점에서 "부족한" 데이터이지만 관계형 모델이 하위 테이블을 통해서만 근사할 수 있는 깊이 수준도 허용합니다.이는 XML이 데이터를 표현하는 방식과 거의 동일합니다.여기서 특정 필드/속성에는 동시에 여러 개의 정답이 있을 수 있습니다.다중값은 XML의 압축된 형식으로 생각할 수 있습니다.
예를 들어, 청구서는 (A) 청구서 헤더 테이블(송장당 1개 항목), (B) 청구서 상세 테이블(한 줄에 1개 항목)로 표시됩니다.멀티값 모델에서는 데이터를 테이블과 같이 저장할 수 있으며, (A) Invoice Table - 청구서당 1개의 엔트리를 포함하지만 다른 테이블은 필요하지 않습니다.
장점은 송장(개념)과 송장(데이터 표현)의 원자성이 일대일이라는 것입니다.그 결과 읽기 수 감소, 참조 무결성 문제 감소, 특정 트랜잭션 볼륨 지원에 필요한 하드웨어의 대폭 감소가 초래됩니다.
객체 지향 데이터베이스 모델
1990년대에 객체 지향 프로그래밍 패러다임이 데이터베이스 기술에 적용되어 객체 데이터베이스로 알려진 새로운 데이터베이스 모델을 만들었습니다.이는 데이터베이스 내의 표현(테이블 내의 행 등)과 애플리케이션 프로그램 내의 표현(일반적으로 객체) 간에 정보를 변환하는 오버헤드인 객체-관계 임피던스 불일치를 방지하는 것을 목적으로 합니다.또한 특정 애플리케이션에서 사용되는 유형 시스템을 데이터베이스에서 직접 정의할 수 있으므로 데이터베이스는 동일한 데이터 무결성 불변성을 적용할 수 있습니다.오브젝트 데이터베이스는 캡슐화 및 다형성과 같은 오브젝트 프로그래밍의 주요 아이디어를 데이터베이스 세계에 도입합니다.
이러한 다양한 방법으로 오브젝트를 데이터베이스에 저장하려고[by whom?] 시도되고 있습니다.일부[which?] 제품은 프로그램에 의해 조작되는 오브젝트를 영속적으로 함으로써 어플리케이션프로그래밍의 끝에서 문제에 접근하고 있습니다.기존 프로그래밍 언어에는 정보 내용에 따라 객체를 찾는 기능이 없기 때문에 일반적으로 쿼리 언어를 추가해야 합니다.다른[which?] 기업은 데이터베이스의 객체 지향 데이터 모델을 정의하고 기존 쿼리 기능뿐만 아니라 완전한 프로그래밍 기능을 허용하는 데이터베이스 프로그래밍 언어를 정의함으로써 데이터베이스 측에서 문제를 공격했습니다.
표준화의 부족으로 오브젝트 데이터베이스가 어려움을 겪었습니다.표준은 ODMG에 의해 정의되었지만 제품 간의 상호 운용성을 보장할 만큼 충분히 구현되지 않았습니다.그럼에도 불구하고 객체 데이터베이스는 많은 응용 프로그램에서 성공적으로 사용되어 왔습니다. 일반적으로 주요 상용 데이터 처리보다는 엔지니어링 데이터베이스나 분자 생물학 데이터베이스와 같은 특수한 응용 프로그램입니다.그러나 객체 데이터베이스 아이디어는 관계형 벤더에 의해 채택되어 이러한 제품과 SQL 언어에 대한 확장에 영향을 미쳤습니다.
오브젝트와 릴레이셔널 데이터베이스 간에 변환하는 대신 오브젝트 릴레이셔널 맵핑(ORM) 라이브러리를 사용합니다.
「 」를 참조해 주세요.
레퍼런스
- ^ Elmasri, Ramez; Navathe, Shamkant. Fundamentals of database systems (Seventh ed.). p. 33. ISBN 9780133970777.
- ^ E.F. Codd(1970)."대규모 공유 데이터 뱅크를 위한 데이터 관계형 모델"입력: ACM 아카이브의 통신.제13권제6호(1970년 6월) 페이지 377-387.
- ^ Stephen Chu의 데이터베이스 소개, M. Conrick, (2006) Health Informatics: 기술을 통한 의료 혁신, Thomson, ISBN 0-17-012731-1, 페이지 69.
- ^ Date, C. J. (June 1, 1999). "When's an extension not an extension?". Intelligent Enterprise. 2 (8).
- ^ Zhuge, H. (2008). The Web Resource Space Model. Web Information Systems Engineering and Internet Technologies Book Series. Vol. 4. Springer. ISBN 978-0-387-72771-4.