릴레이셔널 데이터베이스

Relational database

관계형 데이터베이스는 1970년 [1]E. F. Codd가 제안한 데이터관계형 모델에 기초한 (가장 일반적으로 디지털) 데이터베이스이다.릴레이셔널 데이터베이스를 유지하기 위해 사용되는 시스템은 릴레이셔널 데이터베이스 관리 시스템(RDBMS)입니다.많은 관계형 데이터베이스 시스템에는 [2]데이터베이스 쿼리 및 유지보수에 SQL(Structured Query Language)을 사용하는 옵션이 있습니다.

역사

"관계형 데이터베이스"라는 용어는 1970년 IBM의 E. F. Codd에 의해 처음 정의되었습니다.Codd는 그의 연구 논문 "대규모 공유 데이터 뱅크를 위한 데이터의 관계형 모델"[3]에서 이 용어를 도입했습니다.이 논문과 이후의 논문에서 그는 "관계적"이라는 것이 무엇을 의미하는지 정의했다.관계형 데이터베이스 시스템을 구성하는 것에 대한 잘 알려진 정의는 Codd의 12가지 규칙으로 구성됩니다.그러나 관계형 모델의 상업적 구현은 Codd의 모든 [4]규칙을 준수하지 않기 때문에 이 용어는 적어도 다음과 같은 광범위한 데이터베이스 시스템 클래스를 점차적으로 설명하게 되었습니다.

  1. 데이터를 관계(표 형식의 프레젠테이션, 즉 행과 열의 세트로 구성된 각 테이블이 포함된 표의 집합)로 사용자에게 제시한다.
  2. 데이터를 표 형식으로 조작할 수 있는 관계 연산자를 제공합니다.

1974년 IBM은 RDBMS [5][6]프로토타입을 개발하기 위한 연구 프로젝트인 System R을 개발하기 시작했습니다. RDBMS로 판매된 첫 번째 시스템은 Multics Relational Data Store([citation needed]1976년 6월)였습니다.Oracle은 1979년 Relational Software(현 Oracle Corporation)[7]에 의해 출시되었습니다.IngresIBM BS12가 그 뒤를 이었다.RDBMS의 다른 예로는 IBM Db2, SAP Sybase ASE 및 Informix있습니다.1984년, Macintosh용 최초의 RDBMS가 개발되기 시작했고, 코드명은 Silver Surfer이며, 1987년에 4D[8]출시되었고, 현재는 4D로 알려져 있습니다.

관계모형의 비교적 충실한 구현이었던 첫 번째 시스템은 다음과 같다.

  • 미시간 대학교– Micro DBMS (1969년)[9]
  • 매사추세츠 공과대학(1971년)[10]
  • IBM UK Scientific Center at Peterlee – IS1(1970-72)과 그 후계자인 PRTV(1973-79)

RDBMS의 가장 일반적인 정의는 데이터를 행과 열의 집합으로 표시하는 제품이다. 비록 RDBMS가 전적으로 관계 이론에 기초하지 않더라도 말이다.이 정의에 따르면 RDBMS 제품은 일반적으로 Codd의 12가지 규칙을 모두 구현하지는 않습니다.

두 번째 학파는 데이터베이스가 Codd의 모든 규칙(또는 Christopher J. Date, Hugh Darwen 등에 의해 표현된 관계형 모델에 대한 현재 이해)을 구현하지 않으면 관계형이 아니라고 주장한다.많은 이론가들과 Codd의 원칙에 대한 엄격한 신봉자들이 공유하는 이 견해는 대부분의 DBMS를 관계성이 없는 것으로 간주할 수 있습니다.알기 쉽게 하기 위해 일부 RDBMS를 True-Relational Database Management System(TRDBMS; 진정한 관계형 데이터베이스 관리 시스템)이라고 부르고 다른 RDBMS를 의사 관계형 데이터베이스 관리 시스템(PRDBMS)이라고 명명합니다.

2009년 현재 대부분의 상용 관계형 DBMS는 SQL을 쿼리 [11]언어로 사용하고 있습니다.

대체 쿼리 언어, 특히 Ingres QUEL의 1996년 이전 구현이 제안되고 구현되었습니다.

관계형 모델

관계 모형은 데이터를 열과 의 하나 이상의 테이블(또는 "관계")로 구성하고 각 행을 식별하는 고유한 키를 사용합니다.행은 레코드 또는 [12]튜플이라고도 합니다.열은 속성이라고도 합니다.일반적으로 각 테이블/관계는 하나의 엔티티 유형(고객 또는 제품 등)을 나타냅니다.행은 해당 유형의 엔티티 인스턴스(예: "Lee" 또는 "chair")와 해당 인스턴스에 속한 값(예: 주소 또는 가격)을 나타냅니다.

예를 들어, 클래스 테이블의 각 행은 클래스에 대응하고 클래스는 여러 학생에 대응하므로 클래스 테이블과 학생 테이블의 관계는 "1 대 다"[13]입니다.

열쇠들.

테이블의 각 행에는 고유한 키가 있습니다.테이블 내의 행은 링크된 행의 고유 키(이러한 열을 외부 키라고 함)에 대한 열을 추가하여 다른 테이블의 행에 링크할 수 있습니다.Codd는 임의 복잡성의 데이터 관계가 단순한 개념 [citation needed]세트로 표현될 수 있음을 보여주었다.

이 처리의 일부에서는 테이블 내의 1개의 행만 일관되게 선택하거나 변경할 수 있습니다.따라서 대부분의 물리 실장에서는 테이블 내의 각 행에 일의의 프라이머리 키(PK)가 있습니다.테이블에 새로운 행이 기록되면 프라이머리 키의 새로운 고유 값이 생성됩니다.이 값은 주로 테이블에 액세스하기 위해 시스템에서 사용되는 키입니다.시스템 성능은 PK에 최적화되어 있습니다. 외, 보다 자연스러운 키를 식별해 대체 키(AK)로서 정의할 수도 있습니다.AK를 형성하기 위해 여러 열이 필요한 경우가 많습니다(일반적으로 단일 정수 열이 PK가 되는 이유 중 하나).PK와 AK 모두 테이블 내의 행을 일의로 식별할 수 있습니다.보다 광범위한 시스템 요건이 있는 경우, 전 세계에서 하나의 ID(글로벌 고유 식별자)를 확보하기 위해 추가 기술을 적용할 수 있습니다.

데이터베이스 내의 프라이머리 키는 테이블 간의 관계를 정의하는 데 사용됩니다.PK가 다른 테이블로 이행하면 다른 테이블의 외부 키가 됩니다.각 셀에 포함할 수 있는 값이 1개뿐이고 PK가 일반 엔티티 테이블로 이행하는 경우 이 설계 패턴은 일대일 또는 일대다 관계를 나타낼 수 있습니다.대부분의 릴레이셔널 데이터베이스 설계에서는 다른 엔티티 테이블의 PK를 포함하는 추가 테이블을 생성하여 다대다 관계를 해결합니다.이러한 관계는 엔티티가 되고 해결 테이블이 적절히 명명되어 2개의 FK가 조합되어 PK가 형성됩니다.PK를 다른 테이블로 이행하는 것은 시스템에서 할당한 정수가 정상적으로 PK로 사용되는 두 번째 주요 이유입니다.일반적으로 다른 유형의 열을 여러 개 이행할 때 효율이나 명확성이 떨어집니다.

관계들

관계는 서로 다른 테이블 간의 논리적 연결로, 이러한 테이블 간의 상호 작용을 기반으로 설정됩니다.

트랜잭션

Database Management System(DBMS; 데이터베이스 관리 시스템)이 효율적이고 정확하게 작동하기 위해서는 ACID [14][15][16]트랜잭션을 사용해야 합니다.

저장 프로시저

RDBMS 내의 프로그래밍의 일부는 Stored Procedure(SP; 스토어드 프로시저)를 사용하여 실행됩니다.대부분의 경우 절차를 사용하여 시스템 내부 및 외부로 전송되는 정보의 양을 크게 줄일 수 있습니다.보안을 강화하기 위해 시스템 설계는 저장 프로시저에만 접근을 허용하고 테이블에는 직접 접근하지 않을 수 있습니다.기본 저장 프로시저에는 새 데이터를 삽입하고 기존 데이터를 업데이트하는 데 필요한 논리가 포함되어 있습니다.데이터 처리 또는 선택과 관련된 추가 규칙 및 논리를 구현하기 위해 보다 복잡한 절차를 작성할 수 있습니다.

용어.

릴레이셔널 데이터베이스 용어

관계형 데이터베이스는 IBM의 San Jose Research [1]Laboratory의 Edgar Codd에 의해 1970년 6월에 처음 정의되었습니다.RDBMS로서 무엇이 자격이 있는지에 대한 Codd의 견해는 Codd의 12가지 규칙에 요약되어 있습니다.관계형 데이터베이스가 주요 데이터베이스 유형이 되었습니다.관계형 모델 이외의 모델에는 계층형 데이터베이스 모델과 네트워크 모델이 있습니다.

다음 표에 가장 중요한 관계형 데이터베이스 용어와 대응하는 SQL 용어를 정리합니다.

SQL 용어 관계형 데이터베이스 용어 묘사
배를 젓다 태플 또는 레코드 단일 항목을 나타내는 데이터 세트
기둥. 속성 또는 필드 태플의 레이블 요소(예: "주소" 또는 "생년월일")
테이블 관계 또는 기준 관계 동일한 속성을 공유하는 튜플 집합, 열 및 행 집합
보기 또는 결과 세트 파생 릴바 임의의 튜플 세트. 쿼리에 대한 응답으로 RDBMS로부터의 데이터 보고서

관계 또는 표

관계형 데이터베이스에서 관계는 동일한 속성을 가진 일련의 튜플입니다.태플은 보통 객체와 해당 객체에 대한 정보를 나타냅니다.개체는 일반적으로 물리적 개체 또는 개념입니다.관계는 보통 과 열로 구성로 설명됩니다.속성이 참조하는 모든 데이터는 동일한 도메인에 있으며 동일한 제약 조건을 따릅니다.

관계 모형은 관계의 튜플에 특정 순서가 없으며 튜플이 속성에 순서를 부여하지 않도록 지정합니다.응용 프로그램은 쿼리를 지정하여 데이터에 액세스합니다. 쿼리는 튜플 식별을 위한 선택, 속성을 식별하기 위한 프로젝트 및 결합 관계를 결합하기 위한 결합 등의 작업을 사용합니다.삽입, 삭제업데이트 연산자를 사용하여 관계를 수정할 수 있습니다.새 튜플은 명시적 값을 제공하거나 쿼리에서 파생될 수 있습니다.마찬가지로 쿼리는 업데이트 또는 삭제를 위한 튜플을 식별합니다.

정의상 튜플은 고유합니다.태플에 후보 키 또는 프라이머리 키가 포함되어 있는 경우는, 확실히 고유합니다.단, 행 또는 레코드에 프라이머리 키를 정의할 필요는 없습니다.태플의 정의에서는 고유해야 하지만 프라이머리 키를 정의할 필요는 없습니다.태플은 고유하기 때문에 정의상 그 속성이 슈퍼키를 구성합니다.

기본 및 파생 관계

모든 데이터는 관계를 통해 저장 및 액세스됩니다.데이터를 저장하는 관계를 "기본 관계"라고 하며, 구현에서는 "테이블"이라고 합니다.다른 관계는 데이터를 저장하지 않지만 다른 관계에 관계 연산을 적용하여 계산됩니다.이러한 관계를 "파생 관계"라고 부르기도 합니다.실장에서는, 이러한 을 「뷰」또는 「쿼리」라고 부릅니다.파생 관계는 여러 관계에서 정보를 얻을 수 있지만 단일 관계로서 기능한다는 점에서 편리합니다.또, 도출된 관계를 추상층으로서 이용할 수도 있다.

도메인

도메인은 특정 Atribute에 대해 가능한 값의 집합을 나타내며 Atribute 값의 제약으로 간주할 수 있습니다.Atribute에 도메인을 부가하는 것은 Atribute의 모든 값이 지정된 세트의 요소여야 함을 의미합니다.예를 들어 문자열 "ABC"는 정수 도메인에 없지만 정수 값 123은 있습니다.도메인의 또 다른 예에서는 "CoinFace" 필드의 가능한 값을 "Heads", "Tails"로 설명합니다.따라서 "CoinFace" 필드에는 (0,1) 또는 (H,T)와 같은 입력 값을 사용할 수 없습니다.

제약

제약은 속성의 도메인을 더 제한할 수 있도록 하기 위해 종종 사용됩니다.예를 들어, 제약조건은 특정 정수 속성을 1 ~10 의 값으로 제한할 수 있습니다.제약사항은 데이터베이스에 비즈니스 규칙을 구현하는 한 가지 방법을 제공하며 애플리케이션 계층 내에서 후속 데이터 사용을 지원합니다.SQL은 검사 제약 조건의 형태로 제약 조건 기능을 구현합니다.제약 조건은 관계에 저장할 수 있는 데이터를 제한합니다.이러한 값은 보통 부울 값이 되는 식을 사용하여 정의되며, 데이터가 제약 조건을 충족하는지 여부를 나타냅니다.제약은 단일 속성, 태플(속성의 조합을 제한하는 것) 또는 관계 전체에 적용할 수 있습니다.모든 Atribute에는 도메인이 관련되어 있기 때문에 제약(도메인 제약)이 있습니다.관계모형에 대한 두 가지 주요 규칙을 실체 무결성 및 참조 무결성이라고 한다.

프라이머리 키

모든 관계/테이블에는 프라이머리 키가 있으며, 이는 관계가 집합[17]결과입니다.프라이머리 키는 테이블 내의 태플을 일의로 지정합니다.자연 속성(입력되는 데이터를 기술하는 데 사용되는 속성)이 좋은 프라이머리 키가 될 수 있지만 대신 대리 키가 사용되는 경우가 많습니다.대리 키는 이를 고유하게 식별하는 객체에 할당되는 인위적인 속성입니다(예를 들어 학교의 학생에 대한 정보 테이블에서는 학생 ID를 구분하기 위해 학생 ID를 모두 할당할 수 있습니다.대리 키는 본질적인(일관적인) 의미는 없지만 태플을 고유하게 식별하는 기능을 통해 유용합니다.특히 N:M 카디널리티와 관련하여 자주 발생하는 또 다른 문제는 복합 키입니다.복합 키는 테이블 내에서 레코드를 [citation needed]고유하게 식별하는 둘 이상의 속성으로 구성된 키입니다.

외부 키

외부 키는 다른 테이블의 프라이머리 키 열에 일치하는 관계형 테이블의 필드를 나타냅니다.그것은 두 개의 키를 관련짓습니다.외부 키는 참조 관계에서 고유한 값을 가질 필요가 없습니다.외부 키는 테이블을 상호 참조하기 위해 사용할 수 있으며, 참조 관계에 있는 속성 값을 효과적으로 사용하여 참조 관계에 있는 하나 이상의 속성의 도메인을 제한한다.이 개념은 공식적으로 다음과 같이 기술됩니다. "참조 속성 위에 투영된 참조 관계 내의 모든 튜플에 대해 각 참조 속성의 값이 참조 속성의 대응하는 값과 일치하도록 동일한 속성 위에 투영된 참조 관계 내에 튜플이 존재해야 합니다."

저장 프로시저

스토어드 프로시저는 데이터베이스와 관련지어져 일반적으로 저장되어 있는 실행 가능한 코드입니다.스토어드 프로시저는 일반적으로 관계태플을 삽입하거나 사용 패턴에 대한 통계 정보를 수집하거나 복잡한 비즈니스 로직과 계산을 캡슐화하는 등의 일반적인 작업을 수집 및 맞춤화합니다.보안 또는 단순화를 위해 API(Application Programming Interface)로 사용되는 경우가 많습니다.SQL RDBMS에 스토어드 프로시저를 구현하면 개발자는 표준 선언형 SQL 구문에 대한 프로시저 확장(종종 벤더 고유)을 활용할 수 있습니다.저장 프로시저는 관계형 데이터베이스 모델의 일부가 아니지만 모든 상용 구현에 포함됩니다.

색인

인덱스는 데이터에 대한 빠른 액세스를 제공하는 한 가지 방법입니다.인덱스는 관계의 속성 조합에 대해 생성할 수 있습니다.이러한 속성을 사용하여 필터링하는 쿼리는 각 태플을 차례로 확인할 필요 없이 인덱스를 사용하여 일치하는 태플을 직접 찾을 수 있습니다(해시 테이블 검색과 유사).이것은 찾고 있는 정보가 있는 페이지로 바로 이동하기 위해 책의 색인을 사용하는 것과 유사합니다. 따라서 찾고 있는 정보를 찾기 위해 책 전체를 읽을 필요가 없습니다.관계형 데이터베이스는 일반적으로 데이터 분포, 관계 크기 및 일반적인 액세스 패턴의 조합에 최적인 여러 색인화 기술을 제공합니다.인덱스는 보통 B+ 트리, R 트리비트맵통해 구현됩니다.인덱스는 일반적으로 데이터베이스의 다른 부분을 유지하는 동일한 그룹에 의해 유지되지만 일반적으로 구현 세부사항으로 간주되기 때문에 데이터베이스의 일부로 간주되지 않습니다.기본 키와 외부 키 모두에서 효율적인 인덱스를 사용하면 쿼리 성능이 크게 향상될 수 있습니다.이는 B-트리 인덱스가 log(n)에 비례하는 쿼리 시간을 생성하기 때문입니다.여기서 n은 테이블 내의 행 수이며 해시 인덱스는 일정한 시간 쿼리를 생성하기 때문입니다(인덱스의 관련 부분이 메모리에 들어 있는 한 크기에 의존하지 않습니다).

릴레이셔널 오퍼레이션

관계 데이터베이스에 대해 이루어진 쿼리와 데이터베이스 내의 파생된 관계수는 관계 미적분 또는 관계 대수로 표현된다.Codd는 원래 관계대수에서 각각 4개의 연산자로 이루어진 두 그룹에 8개의 관계연산자를 도입했다.처음 4개의 연산자는 전통적인 수학적 집합 연산을 기반으로 했다.

  • 합집합 연산자(υ)는 두 관계의 튜플을 결합하고 결과에서 모든 중복 튜플을 제거합니다.릴레이셔널 유니언 연산자는 SQL UNION 연산자와 동일합니다.
  • 교차 연산자( ()는 두 관계가 공통적으로 공유하는 튜플 집합을 생성합니다.교차로는 SQL에서 CRESS 연산자의 형태로 구현됩니다.
  • 설정 차분 연산자(-)는 두 개의 관계에 작용하며 두 번째 관계에 존재하지 않는 첫 번째 관계에서 튜플 집합을 생성합니다.차이는 EXCEPT 또는 MINUS 연산자의 형태로 SQL에 구현됩니다.
  • 두 관계의 데카르트 곱(X)은 어떤 기준에 의해 제한되지 않는 결합이며, 결과적으로 첫 번째 관계의 모든 태플이 두 번째 관계의 모든 태플과 일치한다.데카르트 곱은 SQL에서 교차 결합 연산자로 구현됩니다.

Codd가 제안한 나머지 운영자는 관계형 데이터베이스에 특정한 특수 작업을 수반한다.

  • 선택 또는 제한 연산( ()은 관계에서 튜플을 검색하여 특정 기준, 즉 집합론의 관점에서 부분 집합으로 결과를 제한한다.선택 항목에 해당하는 SQL은 WHERE 이 있는 SELECT 쿼리 문입니다.
  • 투영 연산( ()은 튜플 또는 튜플 집합에서 지정된 속성만 추출합니다.
  • 릴레이셔널 데이터베이스에 정의되어 있는 Join 조작은 보통 Natural Join(')이라고 불립니다.이런 유형의 조인에서는 두 개의 관계가 공통 속성에 의해 연결됩니다.MySQL의 자연 결합 근사치는 내부 결합 연산자입니다.SQL에서 INSER JOIN은 쿼리에 테이블이 두 개 있을 때 데카르트 제품이 발생하는 것을 방지합니다.SQL 쿼리에 추가된 각 테이블에 대해 데카르트 제품을 방지하기 위해 1개의 INSER JOIN이 추가됩니다.따라서 SQL 쿼리에서 N개의 테이블에 대해 데카르트 곱을 방지하려면 N-1 INSER JOIN이 있어야 합니다.
  • 관계 나눗셈(θ) 연산은 약간 더 복잡한 연산이며 기본적으로 두 번째 관계(제수)를 분할하기 위해 한 관계(배당)의 배수를 사용합니다.관계형 나눗셈 연산자는 사실상 데카르트 곱 연산자의 반대입니다(따라서 이름).

관계형 비교 연산자와 중첩 및 계층적 데이터에 대한 지원을 제공하는 확장을 포함하여 Codd의 원본 8개 도입 이후 다른 연산자가 도입 또는 제안되었다.

정규화

정규화는 관계형 모델의 필수적인 부분으로 Codd에 의해 처음 제안되었다.여기에는 단순하지 않은 도메인(비원자 값)과 데이터의 중복성(복제)을 제거하도록 설계된 일련의 절차가 포함되어 있어 데이터 조작의 이상과 데이터 무결성 손실을 방지할 수 있습니다.데이터베이스에 적용되는 가장 일반적인 정규화 형식을 정규화 양식이라고 합니다.

RDBMS

관계형 데이터베이스의 일반적인 구조

Connolly와 Begg는 데이터베이스 관리 시스템(DBMS)을 "사용자가 데이터베이스에 대한 접근을 정의, 작성, 유지 및 제어할 수 있는 소프트웨어 시스템"[18]으로 정의합니다.RDBMS는 기본 데이터베이스가 관계형일 때 사용되는 약어의 확장입니다.

릴레이셔널 데이터베이스 관리 시스템의 대체 정의는 릴레이셔널 모델에 기초한 데이터베이스 관리 시스템(DBMS)이다.오늘날 널리 사용되는 대부분의 데이터베이스는 이 [19]모델을 기반으로 합니다.

RDBMS는 1980년대부터 재무 기록, 제조 및 물류 정보, 인사 데이터 및 기타 애플리케이션에 사용되는 데이터베이스에 정보를 저장하는 일반적인 옵션이었다.RDBMS를 구현하고 관리하기 쉽기 때문에 릴레이셔널 데이터베이스가 레거시 계층 데이터베이스네트워크 데이터베이스를 대체하는 경우가 많습니다.그럼에도 불구하고 관계형 저장 데이터는 XML 데이터베이스 관리자에 의해 1980년대와 1990년대에 객체 데이터베이스 관리 시스템에 의해 (관계형 데이터베이스와 객체 지향 애플리케이션 프로그램 간의 소위 객체-임피던스 불일치에 대처하기 위해 도입된) 계속되었으나 성공하지 못했다.1990년대의 [citation needed]시스템입니다.그러나 컴퓨터 클러스터의 수평 확장과 같은 광범위한 기술 때문에 최근에는 NoSQL 데이터베이스가 RDBMS 데이터베이스의 [20]대안으로 인기를 끌고 있습니다.

분산 관계형 데이터베이스

DRDA(Distributed Relational Database Architecture)는 1988년부터 1994년까지 IBM의 한 워크그룹에 의해 설계되었습니다.DRDA를 통해 네트워크에 연결된 관계형 데이터베이스가 협업하여 [21][22]SQL 요청을 수행할 수 있습니다.DRDA의 메시지, 프로토콜 및 구조 구성요소는 분산 데이터 관리 아키텍처에 의해 정의됩니다.

시장 점유율

DB-Engines에 따르면 2022년 4월에 가장 널리 사용된 시스템은 다음과 같습니다.[23]

  1. Oracle 데이터베이스
  2. MySQL
  3. Microsoft SQL Server
  4. PostgreSQL(자유 소프트웨어)
  5. IBM DB2
  6. Microsoft 액세스
  7. SQLite(무료 소프트웨어)
  8. MariaDB(자유 소프트웨어)
  9. 눈송이
  10. Microsoft Azure SQL 데이터베이스
  11. Apache Hive(자유 소프트웨어)
  12. Teradata Vantage

리서치 회사인 Gartner에 따르면 2011년 매출액 기준으로 상위 5개 독점 소프트웨어 관계형 데이터베이스 벤더Oracle(48.8%), IBM(20.2%), Microsoft(17.0%), SAP(Sybase(4.6%), Teradata(3.7%)[24]

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b Codd, E. F. (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM. 13 (6): 377–387. doi:10.1145/362384.362685. S2CID 207549016.
  2. ^ Ambler, Scott. "Relational Databases 101: Looking at the Whole Picture".[더 나은 소스 필요]
  3. ^ "A Relational Model of Data for Large Shared Data Banks" (PDF).
  4. ^ Date, Chris (5 May 2005). Database in depth: relational theory for practitioners. O'Reilly. ISBN 0-596-10012-4.
  5. ^ Funding a Revolution: Government Support for Computing Research. National Academies Press. 8 Jan 1999. ISBN 0309062780.
  6. ^ Sumathi, S.; Esakkirajan, S. (13 Feb 2008). Fundamentals of Relational Database Management Systems. Springer. ISBN 978-3540483977. The product was called SQL/DS (Structured Query Language/Data Store) and ran under the DOS/VSE operating system environment
  7. ^ "Oracle Timeline" (PDF). Profit Magazine. Oracle. 12 (2): 26. May 2007. Retrieved 2013-05-16.
  8. ^ "New Database Software Program Moves Macintosh Into The Big Leagues". tribunedigital-chicagotribune. Retrieved 2016-03-17.
  9. ^ "ASetTheoreticDataStructureAndRetrievalLanguage-1972.PDF".
  10. ^ SIGFIDET '74 데이터 설명, 접근 및 제어에 관한 1974년 ACM SIGFIDET(현재의 SIGMOD) 워크숍 진행
  11. ^ Ramakrishnan, Raghu; Donjerkovic, Donko; Ranganathan, Arvind; Beyer, Kevin S.; Krishnaprasad, Muralidhar (1998). "SRQL: Sorted Relational Query Language" (PDF). E Proceedings of SSDBM.
  12. ^ "A Relational Database Overview". oracle.com.
  13. ^ "A universal relation model for a nested database", The Nested Universal Relation Database Model, Lecture Notes in Computer Science, Berlin, Heidelberg: Springer Berlin Heidelberg, vol. 595, pp. 109–135, 1992, doi:10.1007/3-540-55493-9_5, ISBN 978-3-540-55493-6, retrieved 2020-11-01
  14. ^ "Gray to be Honored With A. M. Turing Award This Spring". Microsoft PressPass. 1998-11-23. Archived from the original on 6 February 2009. Retrieved 2009-01-16.
  15. ^ Gray, Jim (September 1981). "The Transaction Concept: Virtues and Limitations" (PDF). Proceedings of the 7th International Conference on Very Large Databases. Cupertino, CA: Tandem Computers. pp. 144–154. Retrieved 2006-11-09.
  16. ^ Gray, Jim, and Reuter, Andreas, Distributed Transaction Processing: 개념과 기술.모건 카우프만, 1993년ISBN 1-55860-190-2.
  17. ^ 날짜(1984년), 페이지 268.
  18. ^ Connolly, Thomas M.; Begg, Carolyn E. (2014). Database Systems – A Practical Approach to Design Implementation and Management (6th ed.). Pearson. p. 64. ISBN 978-1292061184.
  19. ^ Pratt, Philip J.; Last, Mary Z. (2014-09-08). Concepts of Database Management (8 ed.). Course Technology. p. 29. ISBN 9781285427102.
  20. ^ "NoSQL databases eat into the relational database market". 4 March 2015. Retrieved 2018-03-14.
  21. ^ Reinsch, R. (1988). "Distributed database for SAA". IBM Systems Journal. 27 (3): 362–389. doi:10.1147/sj.273.0362.
  22. ^ Distributed Relational Database Architecture Reference. IBM Corp. SC26-4651-0. 1990.
  23. ^ "DB-Engines Ranking of Relational DBMS". DB-Engines. Retrieved 2022-04-29.
  24. ^ "Oracle the clear leader in $24 billion RDBMS market". 2012-04-12. Retrieved 2013-03-01.

원천


외부 링크