데이터베이스 모델
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
데이터베이스 모델은 데이터를 구조화하고 관리하기 위한 다양한 방식을 의미하며, 계층형, 네트워크, 관계형, 객체 지향형, 그래프 모델 등 여러 유형이 존재한다. 초기 데이터 모델은 계층형 및 네트워크 모델이 주를 이루었으나, 데이터 중복성 문제와 복잡성으로 인해 관계형 모델이 널리 사용되었다. 관계형 모델은 테이블, 속성, 도메인 등의 개념을 기반으로 하며, SQL을 쿼리 언어로 사용한다. 이후 객체 지향 프로그래밍의 영향을 받아 객체-관계형 모델이 등장했으며, 그래프 모델, 다중값 모델 등 특정 목적에 특화된 모델도 개발되었다.
데이터베이스 모델은 데이터베이스가 어떻게 구조화되고 사용되는지에 대한 이론이나 상세한 설명을 의미한다.[1] 다양한 데이터베이스 모델이 존재하며, 각각 고유한 특징과 장단점을 가진다.
1960년대와 1970년대에 주로 사용된 초기 데이터 모델에는 계층형 모델, 네트워크형 모델, 역 파일 모델 등이 있다. 이들은 오늘날에는 주로 오래된 레거시 시스템에서 찾아볼 수 있으며, 데이터 독립성이 부족하다는 특징을 보인다.
2. 데이터베이스 모델의 유형
데이터 모델은 데이터를 구조화하는 방법일 뿐만 아니라, 데이터에 대해 수행할 수 있는 연산 집합을 정의한다.[1] 예를 들어, 관계형 모델은 선택, 투영, 결합과 같은 연산을 정의한다.[1]
일반적인 논리 데이터 모델에는 다음과 같은 유형이 있다.
물리 데이터 모델에는 역 인덱스, 플랫 파일 등이 있다.[1]
그 외에도, 다차원 모델, 다중값 모델, 시맨틱 모델, XML 데이터베이스, 명명된 그래프, 트리플 스토어 등 다양한 모델이 존재한다.[1]
주어진 데이터베이스 관리 시스템은 하나 이상의 모델을 제공할 수 있다.[1] 최적의 구조는 애플리케이션 데이터의 자연스러운 구성과 애플리케이션의 요구 사항(거래 속도, 신뢰성, 유지 관리 용이성, 확장성 및 비용 포함)에 따라 달라진다.[1]
2. 1. 계층형 모델
계층형 모델에서 데이터는 트리 형태의 구조로 구성되며, 각 레코드는 하나의 부모를 가진다. 정렬 필드는 형제 레코드를 특정 순서로 유지한다. 계층 구조는 초기 메인프레임 데이터베이스 관리 시스템, 예를 들어 IBM의 정보 관리 시스템(IMS)에서 널리 사용되었으며, 현재는 XML 문서의 구조를 설명하는 데 쓰인다. 이 구조는 두 가지 유형의 데이터 간의 일대다 관계를 허용한다. 레시피, 목차, 단락/절의 순서, 중첩되고 정렬된 모든 정보 등 실제 세계의 많은 관계를 설명하는 데 매우 효율적이다.
이 계층 구조는 스토리지에서 레코드의 물리적 순서로 사용된다. 레코드 접근은 포인터를 사용하고 순차적으로 접근하여 데이터 구조를 아래로 탐색함으로써 이루어진다. 따라서 각 레코드에 완전한 경로가 포함되지 않은 경우, 특정 데이터베이스 작업에 비효율적이다. 이러한 제한은 기본 물리적 계층 구조에 추가적인 논리적 계층 구조를 적용하여 이후 IMS 버전에서 보완되었다.
2. 2. 네트워크 모델
네트워크 모델은 계층형 모델을 확장하여 여러 부모를 허용하는 트리와 같은 구조에서 다대다 관계를 허용한다. 이는 관계형 모델로 대체되기 전 가장 인기가 있었으며, CODASYL 사양에 의해 정의되었다.[1]
네트워크 모델은 '레코드'와 '세트'라는 두 가지 기본 개념을 사용하여 데이터를 구성한다. 레코드는 필드를 포함하며 (프로그래밍 언어 COBOL과 같이 계층적으로 구성될 수 있다). 세트(수학적 집합과 혼동하지 않도록 주의)는 레코드 간의 일대다 관계를 정의한다. 즉, 하나의 소유자와 여러 멤버가 있다. 레코드는 여러 세트에서 소유자일 수 있으며 여러 세트에서 멤버일 수 있다.[1]
세트는 순환 연결 리스트로 구성되며, 하나의 레코드 유형인 세트 소유자 또는 부모는 각 순환에 한 번 나타나고, 두 번째 레코드 유형인 하위 또는 자식은 각 순환에 여러 번 나타날 수 있다. 이러한 방식으로 두 레코드 유형 간에 계층 구조를 설정할 수 있다. 예를 들어, A 유형은 B의 소유자이다. 동시에 B가 A의 소유자인 다른 세트를 정의할 수 있다. 따라서 모든 세트는 일반적인 방향 그래프 (소유권이 방향을 정의함) 또는 '네트워크' 구조를 구성한다. 레코드에 대한 접근은 순차적 (일반적으로 각 레코드 유형)이거나 순환 연결 리스트에서 탐색하여 이루어진다.[1]
네트워크 모델은 계층적 모델보다 데이터의 중복성을 효율적으로 표현할 수 있으며, 조상 노드에서 후손 노드로 가는 경로가 여러 개 있을 수 있다. 네트워크 모델의 연산은 탐색 스타일이다. 프로그램은 현재 위치를 유지하고, 레코드가 참여하는 관계를 따라 한 레코드에서 다른 레코드로 이동한다. 또한 키 값을 제공하여 레코드를 찾을 수도 있다.[1]
모델의 필수 기능은 아니지만, 네트워크 데이터베이스는 일반적으로 디스크의 레코드 위치를 직접 주소 지정하는 포인터를 사용하여 세트 관계를 구현한다. 이는 데이터베이스 로딩 및 재구성과 같은 작업의 대가로 훌륭한 검색 성능을 제공한다.[1]
이를 활용한 인기 있는 DBMS 제품으로는 Cincom Systems의 Total과 Cullinet의 IDMS가 있었다. IDMS는 상당한 고객 기반을 확보했으며, 1980년대에는 원래의 도구 및 언어 외에도 관계형 모델과 SQL을 채택했다.[1]
대부분의 객체 데이터베이스 (1990년대에 발명됨)는 탐색 개념을 사용하여 객체 네트워크에서 빠른 탐색을 제공하며, 일반적으로 객체 식별자를 관련 객체에 대한 "스마트" 포인터로 사용한다. 예를 들어 Objectivity/DB는 데이터베이스 간에 교차할 수 있는 명명된 일대일, 일대다, 다대일 및 다대다 명명된 관계를 구현한다. 많은 객체 데이터베이스는 SQL을 지원하여 두 모델의 강점을 결합한다.[1]
2. 3. 관계형 모델
관계형 모델은 1970년 E.F. 코드가 제안한 술어 논리와 집합론에 기반한 수학적 모델이다.[2] 이 모델은 데이터를 테이블 형태로 구성하며, SQL을 사용하여 데이터를 조작한다.
관계형 모델에서 주로 사용되는 용어는 ''관계'', ''속성'', ''도메인''이다. 관계는 열과 행으로 구성된 테이블을 의미하며, 속성은 관계의 명명된 열을, 도메인은 속성이 가질 수 있는 값의 집합을 나타낸다.
관계형 모델의 기본 데이터 구조는 테이블이다. 테이블은 특정 개체(예: 직원)에 대한 정보를 행(튜플)과 열로 표현한다. "관계"는 데이터베이스의 여러 테이블을 의미하며, 관계는 튜플의 집합이다. 열은 개체의 속성(예: 직원의 이름, 주소, 전화번호)을 나타내고, 행은 특정 직원과 같이 관계에 의해 표현되는 개체의 실제 인스턴스를 나타낸다.
관계형 데이터베이스의 모든 관계(테이블)는 다음 규칙을 준수해야 한다.
관계형 모델에서는 두 개의 다른 레코드에 나타나는 모든 값이 해당 레코드 간의 관계를 의미한다. 무결성 제약 조건을 적용하기 위해 테이블의 레코드 간의 관계를 명시적으로 정의할 수 있으며, 기수(1:1, (0)1:M, M:M)를 할당하여 식별 또는 비식별 부모-자식 관계를 특징지을 수 있다.
테이블의 행을 고유하게 식별하는 키를 기본 키라고 한다. 키는 두 개 이상의 테이블에서 데이터를 결합하는 데 사용될 수 있다. 예를 들어, ''직원'' 테이블은 ''위치'' 테이블의 키와 일치하는 값을 포함하는 ''위치''라는 열을 포함할 수 있다. 키는 대형 테이블에서 데이터를 빠르게 검색하기 위한 인덱스를 만드는 데에도 사용된다. 모든 열은 키가 될 수 있으며, 여러 열을 복합 키로 그룹화할 수도 있다.
외부의 실제 의미를 갖는 키는 "자연" 키라고 한다. 적절한 자연 키가 없는 경우 임의 또는 대리 키를 할당할 수 있다. (예: 직원에게 ID 번호를 부여). 대부분의 데이터베이스는 생성된 키와 자연 키를 모두 가지고 있다. 생성된 키는 내부적으로 행 간의 링크를 만드는 데 사용될 수 있고, 자연 키는 검색 및 다른 데이터베이스와의 통합에 사용될 수 있다.
관계형 모델에서 사용되는 가장 일반적인 쿼리 언어는 SQL이다. 관계형 모델은 데이터 무결성과 일관성을 유지하는 데 강점이 있으며, 현대 데이터베이스 관리 시스템의 주류를 이루고 있다.[1]
2. 4. 객체-관계형 모델
관계형 모델에 객체 지향 프로그래밍 개념을 도입한 모델이다. 객체 데이터베이스는 테이블의 행과 같이 데이터베이스에 표현된 정보와 애플리케이션 프로그램의 객체 표현 방식 간 변환 오버헤드, 즉 객체 관계형 임피던스 불일치를 피하는 것을 목표로 한다.[1] 복잡한 데이터 구조를 표현하고, 객체 지향 프로그래밍과의 연동을 용이하게 한다.
객체 데이터베이스는 캡슐화, 다형성과 같은 객체 지향 프로그래밍의 핵심 개념들을 데이터베이스에 도입했다.[1] 또한, 특정 애플리케이션에서 사용되는 타입 시스템을 데이터베이스에서 직접 정의할 수 있어 데이터 무결성을 확보할 수 있다.
객체를 데이터베이스에 저장하기 위해 다양한 방법이 시도되었다. 일부 제품은 프로그램에서 조작되는 객체를 영속하게 하여 애플리케이션 프로그래밍 측면에서 접근했다. 다른 제품들은 데이터베이스를 위한 객체 지향 데이터 모델을 정의하고, 데이터베이스 프로그래밍 언어를 통해 데이터베이스 측면에서 접근했다.
객체 데이터베이스는 표준화가 부족하여 어려움을 겪었지만, 엔지니어링 데이터베이스나 분자 생물학 데이터베이스와 같은 특수 응용 분야에서 성공적으로 사용되었다. 객체 데이터베이스의 아이디어는 관계형 벤더에 의해 채택되어 SQL 언어 확장에 영향을 주었다.
객체 관계형 매핑 (ORM) 라이브러리는 객체와 관계형 데이터베이스 간 변환의 대안이다.
2. 5. 객체형 모델
객체 지향 프로그래밍 패러다임이 1990년대 데이터베이스 기술에 적용되면서 객체 데이터베이스라는 새로운 데이터베이스 모델이 등장했다. 객체형 모델은 데이터베이스의 정보 표현 방식(테이블의 행)과 애플리케이션 프로그램의 정보 표현 방식(객체) 간의 변환 오버헤드, 즉 객체 관계형 임피던스 불일치를 해결하고자 한다. 또한, 특정 애플리케이션에서 사용되는 타입 시스템을 데이터베이스에서 직접 정의하여 데이터 무결성을 유지할 수 있다. 객체 데이터베이스는 캡슐화 및 다형성과 같은 객체 프로그래밍의 핵심 개념을 데이터베이스에 도입했다.
객체를 데이터베이스에 저장하는 다양한 방법이 시도되었다. 일부 제품은 프로그램에서 조작되는 객체를 영속하게 하여 애플리케이션 프로그래밍 측면에서 접근했다. 이러한 방식은 기존 프로그래밍 언어에 쿼리 언어를 추가해야 한다. 다른 제품은 데이터베이스를 위한 객체 지향 데이터 모델을 정의하고, 데이터베이스 프로그래밍 언어를 통해 데이터베이스 측면에서 접근했다.
객체 데이터베이스는 표준화가 부족하여 어려움을 겪었지만, ODMG에서 정의한 표준은 제품 간 상호 운용성을 보장하지 못했다. 그럼에도 불구하고 객체 데이터베이스는 엔지니어링 데이터베이스나 분자 생물학 데이터베이스와 같은 특수 애플리케이션에서 성공적으로 사용되었다. 객체 데이터베이스의 아이디어는 관계형 벤더에 의해 채택되어 SQL 언어 확장에 영향을 주었다.
객체 관계형 매핑 (ORM) 라이브러리는 객체와 관계형 데이터베이스 간 변환의 대안이다.
2. 6. 문서형 모델
데이터를 문서 형태로 저장하는 NoSQL 데이터베이스 모델이다. 유연한 스키마를 가지며, 비정형 데이터를 처리하는 데 적합하다. 문서 모델이라고도 한다.
2. 7. 그래프 모델
그래프 데이터베이스는 네트워크 모델보다 더 일반적인 구조를 허용하며, 임의의 노드를 다른 노드에 연결할 수 있다.
2. 8. 기타 모델
이 외에도 역 인덱스, 플랫 파일, 다차원 모델, 다중값 모델, 시맨틱 모델, XML 데이터베이스, 명명된 그래프, 트리플 스토어 등 다양한 모델이 존재한다.[1]
플랫 (또는 테이블) 모델은 단일의 2차원 데이터 요소 배열로 구성되며, 주어진 열의 모든 멤버는 유사한 값이라고 가정하고 행의 모든 멤버는 서로 관련되어 있다고 가정한다.[1] 예를 들어, 시스템 보안 데이터베이스의 일부로 사용될 수 있는 이름과 비밀번호 열이 있다.[1] 각 행에는 개별 사용자와 관련된 특정 비밀번호가 있다.[1] 테이블의 열에는 문자로 된 데이터, 날짜 또는 시간 정보, 정수 또는 부동 소수점 숫자와 같은 유형이 연결되어 있는 경우가 많다.[1] 이 표 형식은 관계형 모델의 전조이다.[1]
''역파일'' 또는 ''역색인''에서 데이터의 내용은 조회 테이블의 키로 사용되며, 테이블의 값은 주어진 내용 항목의 각 인스턴스 위치를 가리키는 포인터이다.[1] 이것은 현대 데이터베이스 색인의 논리적 구조이기도 하며, 조회 테이블의 특정 열의 내용만 사용할 수 있다.[1] ''역파일 데이터 모델''은 이러한 파일에서 필요한 레코드를 효율적으로 직접 액세스하기 위해 기존의 플랫 데이터베이스 파일 옆에 일련의 파일에 색인을 배치할 수 있다.[1]
이 데이터 모델을 사용하는 것으로 유명한 것은 1970년에 출시된 Software AG의 ADABAS DBMS이다.[1] ADABAS는 상당한 고객 기반을 확보했으며 현재까지 존재하고 지원된다.[1] 1980년대에는 원래의 도구 및 언어 외에도 관계형 모델과 SQL을 채택했다.[1]
문서 지향 데이터베이스 Clusterpoint는 역색인 모델을 사용하여 XML 또는 JSON 데이터 객체에 대한 빠른 전체 텍스트 검색을 제공한다.[1]
다중값 데이터베이스는 "덩어리진" 데이터를 저장하며, 관계형 데이터베이스와 동일한 방식으로 데이터를 저장할 수 있지만, 관계형 모델이 하위 테이블을 사용하여 근사적으로만 표현할 수 있는 수준의 깊이를 허용한다.[1] 이는 주어진 필드/속성이 동시에 여러 개의 올바른 값을 가질 수 있다는 점에서 XML이 데이터를 표현하는 방식과 거의 동일하다.[1] 다중값은 XML의 압축된 형태로 생각할 수 있다.[1]
예를 들어, 송장의 경우 다중값 또는 관계형 데이터 모두 (A) 송장 헤더 테이블 - 송장당 하나의 항목, (B) 송장 세부 정보 테이블 - 품목당 하나의 항목으로 볼 수 있다.[1] 다중값 모델에서는 세부 정보를 나타내기 위해 임베디드 테이블을 사용하여 데이터를 하나의 테이블로 저장하는 옵션이 있다: (A) 송장 테이블 - 송장당 하나의 항목, 다른 테이블은 필요하지 않다.[1]
이점은 송장의 원자성(개념적)과 송장의 데이터 표현이 일대일이라는 것이다.[1] 또한 이로 인해 읽기 횟수가 줄어들고, 참조 무결성 문제가 줄어들며, 주어진 트랜잭션 볼륨을 지원하는 데 필요한 하드웨어가 크게 감소한다.[1]
3. 초기 데이터 모델
3. 1. 계층형 모델 (초기)
계층 모델에서 데이터는 트리 형태의 구조로 구성되며, 각 레코드는 하나의 부모를 가진다. 정렬 필드는 형제 레코드를 특정 순서로 유지한다. 계층 구조는 초기 메인프레임 데이터베이스 관리 시스템, 예를 들어 IBM의 정보 관리 시스템(IMS)에서 널리 사용되었으며, 현재는 XML 문서의 구조를 설명하는 데 쓰인다. 이 구조는 두 가지 유형의 데이터 간의 일대다 관계를 허용하며, 레시피, 목차, 단락/절의 순서, 중첩되고 정렬된 모든 정보 등 실제 세계의 많은 관계를 설명하는 데 매우 효율적이다.
이 계층 구조는 스토리지에서 레코드의 물리적 순서로 사용된다. 레코드 접근은 포인터를 사용하여 순차적으로 데이터 구조를 탐색함으로써 이루어진다. 따라서 각 레코드에 완전한 경로가 포함되지 않은 경우, 특정 데이터베이스 작업에 비효율적일 수 있다. 이러한 제한은 이후 IMS 버전에서 기본 물리적 계층 구조에 추가적인 논리적 계층 구조를 적용하여 보완되었다.
3. 2. 네트워크 모델 (초기)
네트워크 모델은 계층형 모델을 확장하여 여러 부모를 허용하는 트리와 같은 구조에서 다대다 관계를 허용한다. 이는 관계형 모델로 대체되기 전 가장 인기가 있었으며, CODASYL 사양에 의해 정의되었다.
네트워크 모델은 '레코드'와 '세트'라는 두 가지 기본 개념을 사용하여 데이터를 구성한다. 레코드는 필드를 포함하며 (프로그래밍 언어 COBOL과 같이 계층적으로 구성될 수 있다). 세트(수학적 집합과 혼동하지 않아야 한다)는 레코드 간의 일대다 관계를 정의한다. 즉, 하나의 소유자와 여러 멤버가 있다. 레코드는 여러 세트에서 소유자일 수 있으며 여러 세트에서 멤버일 수 있다.
세트는 순환 연결 리스트로 구성되며, 하나의 레코드 유형인 세트 소유자 또는 부모는 각 순환에 한 번 나타나고, 두 번째 레코드 유형인 하위 또는 자식은 각 순환에 여러 번 나타날 수 있다. 이러한 방식으로 두 레코드 유형 간에 계층 구조를 설정할 수 있다. 예를 들어, A 유형은 B의 소유자이다. 동시에 B가 A의 소유자인 다른 세트를 정의할 수 있다. 따라서 모든 세트는 일반적인 방향 그래프 (소유권이 방향을 정의함) 또는 '네트워크' 구조를 구성한다. 레코드에 대한 접근은 순차적 (일반적으로 각 레코드 유형)이거나 순환 연결 리스트에서 탐색하여 이루어진다.
네트워크 모델은 계층적 모델보다 데이터의 중복성을 효율적으로 표현할 수 있으며, 조상 노드에서 후손 노드로 가는 경로가 여러 개 있을 수 있다. 네트워크 모델의 연산은 탐색 스타일이다. 프로그램은 현재 위치를 유지하고, 레코드가 참여하는 관계를 따라 한 레코드에서 다른 레코드로 이동한다. 또한 키 값을 제공하여 레코드를 찾을 수도 있다.
모델의 필수 기능은 아니지만, 네트워크 데이터베이스는 일반적으로 디스크의 레코드 위치를 직접 주소 지정하는 포인터를 사용하여 세트 관계를 구현한다. 이는 데이터베이스 로딩 및 재구성과 같은 작업의 대가로 훌륭한 검색 성능을 제공한다.
3. 3. 역 파일 모델
Software AG의 ADABAS DBMS에서 사용되었다.[1] ADABAS는 1970년에 출시되어 상당한 고객 기반을 확보했으며 현재까지 유지 및 지원되고 있다.[1] 1980년대에는 관계형 모델과 SQL을 채택했다.[1]
4. 관계형 모델 이후의 모델 (Post-relational)
관계형 모델보다 일반적인 데이터 모델을 제공하는 제품은 '포스트 관계형'으로 분류된다.[3] "하이브리드 데이터베이스", "객체 향상 RDBMS" 등의 용어도 사용된다. 이러한 데이터 모델은 관계를 포함하지만, E.F. 커드의 정보 원칙, 즉 데이터베이스의 모든 정보가 관계 내의 값으로 표현되어야 한다는 원칙에 얽매이지 않는다.[4]
관계형 모델의 확장 중 일부는 관계형 모델보다 먼저 존재했던 기술 개념을 통합하기도 한다. 예를 들어 트리 구조를 가진 방향 그래프를 표현할 수 있는 GraphDB가 있다.
일부 포스트 관계형 제품은 비관계형 기능을 통해 관계형 시스템을 확장한다. 다른 제품은 관계형 기능을 사전 관계형 시스템에 추가하면서 유사한 방식으로 등장했다. 따라서 PICK이나 MUMPS처럼 역사적으로 사전 관계형이었던 제품도 포스트 관계형으로 분류되기도 한다.
자원 공간 모델(RSM)은 다차원 분류를 기반으로 하는 비관계형 데이터 모델이다.[5]
4. 1. 그래프 모델 (상세)
네트워크 데이터베이스보다 더 일반적인 구조를 허용하며, 임의의 노드는 다른 노드에 연결될 수 있다.[1]4. 2. 다중값 모델
다중값 데이터베이스는 "덩어리진" 데이터를 저장하며, 관계형 모델과 동일한 방식으로 데이터를 저장할 수 있지만, 관계형 모델이 하위 테이블을 사용하여 근사적으로만 표현할 수 있는 수준의 깊이를 허용한다. 이는 주어진 필드/속성이 동시에 여러 개의 올바른 값을 가질 수 있다는 점에서 XML이 데이터를 표현하는 방식과 거의 동일하다. 다중값은 XML의 압축된 형태로 생각할 수 있다.[1]예를 들어, 송장의 경우 다중값 또는 관계형 데이터 모두 (A) 송장 헤더 테이블 - 송장당 하나의 항목, (B) 송장 세부 정보 테이블 - 품목당 하나의 항목으로 볼 수 있다. 다중값 모델에서는 세부 정보를 나타내기 위해 임베디드 테이블을 사용하여 데이터를 하나의 테이블로 저장하는 옵션이 있다. (A) 송장 테이블 - 송장당 하나의 항목, 다른 테이블은 필요하지 않다.
이점은 송장의 원자성(개념적)과 송장의 데이터 표현이 일대일이라는 것이다. 또한 이로 인해 읽기 횟수가 줄어들고, 참조 무결성 문제가 줄어들며, 주어진 트랜잭션 볼륨을 지원하는 데 필요한 하드웨어가 크게 감소한다.
4. 3. 객체 지향 데이터베이스 모델 (상세)
1990년대에 객체 지향 프로그래밍 패러다임이 데이터베이스 기술에 적용되어 객체 데이터베이스라는 새로운 데이터베이스 모델이 탄생했다. 이는 데이터베이스의 정보 표현 방식(예: 테이블의 행)과 애플리케이션 프로그램의 정보 표현 방식(일반적으로 객체) 간의 변환으로 인한 오버헤드인 객체 관계형 임피던스 불일치를 피하는 것을 목표로 한다.[1] 더 나아가 특정 애플리케이션에서 사용되는 타입 시스템을 데이터베이스에서 직접 정의할 수 있으므로 데이터베이스에서 동일한 데이터 무결성 불변성을 적용할 수 있다. 객체 데이터베이스는 또한 캡슐화 및 다형성과 같은 객체 프로그래밍의 핵심 아이디어를 데이터베이스 세계에 도입했다.이러한 객체를 데이터베이스에 저장하는 다양한 방법이 시도되었다. 일부 제품은 프로그램에서 조작되는 객체를 영속하게 함으로써 애플리케이션 프로그래밍 측면에서 이 문제에 접근했다. 일반적으로 기존 프로그래밍 언어는 정보 내용을 기반으로 객체를 찾을 수 없으므로 어떤 종류의 쿼리 언어를 추가해야 한다. 다른 제품은 데이터베이스를 위한 객체 지향 데이터 모델을 정의하고, 기존 쿼리 기능뿐만 아니라 완전한 프로그래밍 기능을 허용하는 데이터베이스 프로그래밍 언어를 정의함으로써 데이터베이스 측면에서 이 문제에 접근했다.
객체 데이터베이스는 표준화 부족으로 인해 어려움을 겪었다. ODMG에서 표준이 정의되었지만 제품 간의 상호 운용성을 보장할 만큼 충분히 잘 구현되지 않았다. 그럼에도 불구하고 객체 데이터베이스는 많은 애플리케이션에서 성공적으로 사용되었다. 일반적으로 주류 상업 데이터 처리보다는 엔지니어링 데이터베이스 또는 분자 생물학 데이터베이스와 같은 특수 애플리케이션에서 사용되었다. 그러나 객체 데이터베이스 아이디어는 관계형 벤더에 의해 채택되었고 이러한 제품 및 실제로 SQL 언어에 대한 확장에 영향을 미쳤다.[1]
객체와 관계형 데이터베이스 간의 변환에 대한 대안은 객체 관계형 매핑 (ORM) 라이브러리를 사용하는 것이다.
5. 한국의 데이터베이스 모델 활용 현황
한국은 IT 강국으로서, 다양한 데이터베이스 모델을 활용하고 있다.
참조
[1]
서적
Fundamentals of database systems
[2]
논문
A relational model of data for large shared data banks
1970-06
[3]
서적
Introducing databases
Thomson
[4]
간행물
When's an extension not an extension?
http://intelligent-e[...]
1999-06-01
[5]
서적
The Web Resource Space Model
Springer
[6]
웹사이트
Data Integration Glossary
http://knowledge.fhw[...]
2001-08
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com