본문으로 이동

관계형 데이터베이스

위키백과, 우리 모두의 백과사전.

관계형 데이터베이스(關係形 Database, Relational Database, 문화어: 관계자료기지, 관계형자료기지, RDB[1])는 1970년 에드거 F. 코드가 제안한 데이터의 관계형 모델에 기초한 데이터베이스이다.[2]

관계형 데이터베이스 관리 시스템(RDBMS)은 행과 열을 사용하는 구조화된 형식으로 데이터를 저장하는 데이터베이스 관리 시스템의 한 유형이다.

많은 관계형 데이터베이스 시스템은 데이터베이스를 쿼리하고 업데이트하기 위해 SQL(구조화 질의 언어)을 사용하는 옵션을 갖추고 있다.[3]

역사

[편집]

관계형 데이터베이스의 개념은 1970년 IBM의 에드거 F. 코드에 의해 정의되었다. 코드는 그의 연구 논문 "A Relational Model of Data for Large Shared Data Banks"에서 관계형(relational)이라는 용어를 도입했다.[2] 이 논문과 이후의 논문들에서 그는 관계(relation)가 의미하는 바를 정의했다. 관계형 데이터베이스 시스템을 구성하는 요소에 대한 잘 알려진 정의 중 하나는 커드의 12 규칙으로 구성된다.

그러나 관계형 모델의 어떤 상용 구현체도 코드가 제시한 규칙을 모두 준수하지는 않으며,[4] 따라서 이 용어는 점차 다음과 같은 최소한의 요건을 갖춘 더 넓은 부류의 데이터베이스 시스템을 설명하게 되었다.

  1. 사용자에게 데이터를 관계(표 형식의 프레젠테이션, 즉 각 테이블이 행과 열의 집합으로 구성된 테이블의 모음)로 제시한다.
  2. 표 형식의 데이터를 조작하기 위한 관계연산자를 제공한다.

1974년, IBM은 RDBMS 프로토타입을 개발하기 위한 연구 프로젝트인 IBM 시스템 R의 개발을 시작했다.[5][6] RDBMS로 판매된 최초의 시스템은 Multics Relational Data Store(1976년 6월)였다.[7][8] 오라클은 1979년 현재의 오라클 코퍼레이션인 Relational Software에 의해 출시되었다.[9] 인그레스와 IBM BS12가 그 뒤를 이었다. RDBMS의 다른 예로는 IBM DB2, SAP Sybase ASE, IBM Informix 등이 있다. 1984년, 매킨토시 128K를 위한 최초의 RDBMS가 Silver Surfer라는 코드명으로 개발되기 시작하여 1987년 4th Dimension으로 출시되었으며 현재는 4D로 알려져 있다.[10]

관계형 모델을 비교적 충실하게 구현한 최초의 시스템들은 다음과 같다.

  • 미시간 대학교 – Micro DBMS (1969년)[11]
  • 매사추세츠 공과대학교 (1971년)[12]
  • 피터리에 소재한 IBM 영국 과학 센터 – IS1 (1970–72년),[13] 그리고 그 후속작인 PRTV (1973–79년).[14]

RDBMS의 가장 일반적인 정의는 엄격하게 관계형 이론에 기반하지 않더라도 데이터를 행과 열의 모음으로 보여주는 제품을 말한다. 이 정의에 따르면, RDBMS 제품들은 일반적으로 커드의 12 규칙 중 일부를 구현하지만 전부는 아니다.

두 번째 학파는 데이터베이스가 커드의 규칙 전체(또는 크리스토퍼 J. 데이트, 휴 다웬 등이 표현한 관계형 모델에 대한 현대적 이해)를 구현하지 않는다면 그것은 관계형이 아니라고 주장한다. 많은 이론가와 코드의 원칙을 엄격히 고수하는 이들이 공유하는 이 관점은 대부분의 DBMS를 비관계형으로 배제할 것이다. 명확히 하기 위해, 그들은 일부 RDBMS를 진정한 관계형 데이터베이스 관리 시스템(TRDBMS)이라고 부르고, 다른 것들을 유사 관계형 데이터베이스 관리 시스템(PRDBMS)이라고 명명하기도 한다.

2009년 기준으로 대부분의 상용 관계형 DBMS는 SQL을 질의 언어로 채택하고 있다.[15]

대안적인 질의 언어들이 제안되고 구현되었으며, 특히 1996년 이전의 인그레스 QUEL 구현이 유명하다.

관계형 모델

[편집]

관계형 모델은 데이터를 하나 이상의 열과 행으로 이루어진 테이블(또는 "관계")로 구성하며, 각 행은 유일 키로 식별된다. 행은 레코드 또는 튜플이라고도 한다.[16] 열은 속성(attribute)이라고도 불린다. 일반적으로 각 테이블/관계는 하나의 "엔티티 유형"(예: 고객 또는 제품)을 나타낸다. 행은 해당 엔티티의 인스턴스(예: "이씨" 또는 "의자")를 나타내고 열은 해당 인스턴스에 귀속된 값(예: 주소 또는 가격)을 나타낸다.

예를 들어, 학급 테이블의 각 행은 하나의 학급에 해당하고, 하나의 학급은 여러 명의 학생에 해당하므로 학급 테이블과 학생 테이블의 관계는 "일대다"이다.[17]

키

[편집]

테이블의 각 행은 고유한 키를 가진다. 테이블의 행은 연결된 행의 유일 키를 위한 열을 추가함으로써 다른 테이블의 행과 링크될 수 있다(이러한 열을 외래 키라고 한다). 코드는 임의의 복잡성을 가진 데이터 관계가 단순한 개념들의 집합으로 표현될 수 있음을 보여주었다.[2]

이러한 처리 과정의 일부에는 테이블에서 단 하나만의 행을 일관되게 선택하거나 수정할 수 있는 능력이 포함된다. 따라서 대부분의 물리적 구현체는 테이블의 각 행에 대해 고유한 기본 키(PK)를 가진다. 테이블에 새 행이 기록될 때 기본 키를 위한 새로운 유일한 값이 생성된다. 이것이 시스템이 테이블에 액세스하기 위해 주로 사용하는 키이다. 시스템 성능은 기본 키에 최적화되어 있다. 다른 더 자연적인 키들 또한 식별되어 대체키(AK)로 정의될 수 있다. 종종 대체키를 형성하기 위해 여러 개의 열이 필요하기도 한다(이것이 보통 단일 정수 열을 기본 키로 만드는 이유 중 하나이다). 기본 키와 대체키 모두 테이블 내에서 행을 고유하게 식별하는 능력을 가진다. 더 넓은 시스템 요구사항이 있는 경우, 전 세계적으로 고유한 ID를 보장하기 위해 전역 고유 식별자와 같은 추가 기술이 적용될 수 있다.

데이터베이스 내의 기본 키는 테이블 간의 관계를 정의하는 데 사용된다. 기본 키가 다른 테이블로 전이되면 그 테이블에서는 외래 키(FK)가 된다. 각 셀이 하나의 값만 가질 수 있고 기본 키가 일반 엔티티 테이블로 전이될 때, 이 디자인 패턴은 일대일 또는 일대다 관계를 나타낼 수 있다. 대부분의 관계형 데이터베이스 설계는 두 엔티티 테이블의 기본 키를 모두 포함하는 추가 테이블을 생성하여 다대다 관계를 해결한다. 이때 관계 자체가 하나의 엔티티가 되며, 이 해결 테이블에 적절한 이름이 지정되고 두 외래 키가 결합되어 기본 키를 형성한다. 기본 키를 다른 테이블로 전이시키는 것은 시스템에서 할당한 정수가 보통 기본 키로 사용되는 두 번째 주요 이유이다. 한 무더기의 다른 유형의 열들을 전이시키는 것에는 효율성도 명확성도 없기 때문이다.

관계

[편집]

관계는 서로 다른 테이블(엔티티) 사이의 논리적 연결로, 이들 테이블 간의 상호작용을 기초로 설정된다. 이러한 관계들은 개체-관계 모델로 모델링될 수 있다.

트랜잭션

[편집]

데이터베이스 관리 시스템(DBMS)이 효율적이고 정확하게 작동하기 위해서는 ACID 트랜잭션을 사용해야 한다.[18][19][20]

저장 프로시저

[편집]

RDBMS 내 프로그래밍의 일부는 저장 프로시저(SP)를 사용하여 수행된다. 종종 프로시저는 시스템 내외부에서 전송되는 정보의 양을 크게 줄이는 데 사용될 수 있다. 보안 강화를 위해 시스템 설계 시 테이블에 직접 접근하지 않고 저장 프로시저에만 접근 권한을 부여할 수도 있다. 기본적인 저장 프로시저에는 새로운 데이터를 삽입하고 기존 데이터를 업데이트하는 데 필요한 로직이 포함된다. 데이터 처리나 선택과 관련된 추가 규칙 및 로직을 구현하기 위해 더 복잡한 프로시저를 작성할 수도 있다.

용어

[편집]
관계형 데이터베이스 용어

관계형 데이터베이스는 1970년 6월 IBM의 산호세 연구소에 근무하던 에드거 F. 코드에 의해 처음 정의되었다.[2] RDBMS의 자격 요건에 대한 코드의 관점은 커드의 12 규칙에 요약되어 있다. 관계형 데이터베이스는 지배적인 데이터베이스 유형이 되었다. 관계형 모델 이외의 다른 모델로는 계층형 모델과 네트워크 모델 등이 있다.

아래 표는 가장 중요한 관계형 데이터베이스 용어와 그에 대응하는 SQL 용어를 요약한 것이다.

SQL 용어 관계형 데이터베이스 용어 설명
행(Row) 튜플 또는 레코드 단일 항목을 나타내는 데이터 집합
열(Column) 속성(Attribute) 또는 필드 "주소" 또는 "생년월일"과 같이 레이블이 붙은 튜플의 요소
테이블(Table) 관계(Relation) 또는 기본 렐바(Base relvar) 동일한 속성을 공유하는 튜플들의 집합; 열과 행의 집합
뷰(View) 또는 결과 집합 유도 렐바(Derived relvar) 임의의 튜플 집합; 쿼리에 대한 응답으로 RDBMS가 생성한 데이터 보고서

관계 또는 테이블

[편집]

관계형 데이터베이스에서 관계란 동일한 속성들을 가진 튜플들의 집합이다. 튜플은 보통 객체와 그 객체에 대한 정보를 나타낸다. 객체는 일반적으로 물리적 사물이나 개념이다. 관계는 보통 행과 열로 구성된 테이블로 설명된다. 속성에 의해 참조되는 모든 데이터는 동일한 도메인에 있으며 동일한 제약 조건을 준수한다.

관계형 모델은 관계의 튜플들이 특정한 순서를 갖지 않으며, 튜플들 역시 속성에 어떠한 순서도 강요하지 않는다고 규정한다. 애플리케이션은 쿼리를 지정하여 데이터에 접근하는데, 쿼리는 튜플을 식별하기 위한 선택(select), 속성을 식별하기 위한 투영(project), 관계를 결합하기 위한 조인(join)과 같은 연산을 사용한다. 관계는 삽입(insert), 삭제(delete), 업데이트(update) 연산자를 사용하여 수정할 수 있다. 새로운 튜플은 명시적인 값을 제공하거나 쿼리로부터 유도될 수 있다. 마찬가지로 쿼리는 업데이트나 삭제를 위한 튜플을 식별한다.

튜플은 정의상 유일하다. 만약 튜플이 후보 키나 기본 키를 포함하고 있다면 당연히 유일하지만, 행이나 레코드가 튜플이 되기 위해 반드시 기본 키가 정의되어야 하는 것은 아니다. 튜플의 정의는 유일할 것을 요구하지만 기본 키가 정의될 것을 요구하지는 않는다. 튜플은 유일하기 때문에, 그 속성들은 정의상 슈퍼 키를 구성한다.

기본 관계와 유도 관계

[편집]

모든 데이터는 관계를 통해 저장되고 접근된다. 데이터를 저장하는 관계를 "기본 관계"라고 하며, 구현체에서는 "테이블"이라고 부른다. 다른 관계들은 데이터를 저장하지 않지만, 다른 관계에 관계 연산을 적용하여 계산된다. 이러한 관계들을 때때로 "유도 관계"라고 한다. 구현체에서 이들은 "뷰" 또는 "쿼리"라고 불린다. 유도 관계는 여러 관계에서 정보를 가져오더라도 단일 관계처럼 작동하기 때문에 편리하다. 또한, 유도 관계는 추상화 계층으로 사용될 수 있다.

도메인

[편집]

도메인은 주어진 속성에 대해 가능한 값의 집합을 설명하며, 속성값에 대한 제약 조건으로 간주될 수 있다. 수학적으로 속성에 도메인을 연결한다는 것은 해당 속성의 모든 값이 지정된 집합의 원소여야 함을 의미한다. 예를 들어 문자열 "ABC"는 정수 도메인에 속하지 않지만, 정수 값 123은 속한다. 도메인의 또 다른 예로 "동전앞뒷면" 필드에 대해 가능한 값을 ("앞", "뒤")로 설명할 수 있다. 따라서 "동전앞뒷면" 필드는 (0, 1)이나 (H, T)와 같은 입력값을 수락하지 않는다.

제약 조건

[편집]

제약 조건은 속성의 도메인을 더욱 제한할 수 있게 하기 위해 자주 사용된다. 예를 들어 제약 조건은 특정 정수 속성을 1에서 10 사이의 값으로 제한할 수 있다. 제약 조건은 데이터베이스 내에서 비즈니스 규칙을 구현하는 한 가지 방법을 제공하며 애플리케이션 계층 내에서의 후속 데이터 사용을 지원한다. SQL은 체크 제약 조건의 형태로 제약 조건 기능을 구현한다. 제약 조건은 관계에 저장될 수 있는 데이터를 제한한다. 이들은 대개 데이터가 제약 조건을 충족하는지 여부를 나타내는 불리언 결과값을 내는 식을 사용하여 정의된다. 제약 조건은 단일 속성, 튜플(속성 조합의 제한), 또는 관계 전체에 적용될 수 있다. 모든 속성에는 연관된 도메인이 있으므로, 제약 조건(도메인 제약 조건)이 존재한다. 관계형 모델의 두 가지 주요 규칙은 엔티티 무결성과 참조 무결성으로 알려져 있다.

기본 키

[편집]

모든 관계/테이블은 기본 키를 가지며, 이는 관계가 하나의 집합이라는 사실의 결과이다.[21] 기본 키는 테이블 내의 튜플을 유일하게 지정한다. 자연 속성(입력되는 데이터를 설명하는 데 사용되는 속성)이 때때로 좋은 기본 키가 되기도 하지만, 대신 서로게이트 키(대체키)가 자주 사용된다. 서로게이트 키는 객체를 유일하게 식별하기 위해 할당된 인위적인 속성이다(예를 들어, 학교 학생 정보 테이블에서 학생들을 구분하기 위해 모두에게 학생 ID를 할당할 수 있다). 서로게이트 키는 본질적인 의미는 없지만 튜플을 유일하게 식별할 수 있는 능력을 통해 유용하게 사용된다. 또 다른 흔한 사례는 특히 N:M 카디널리티와 관련하여 발생하는 복합 키이다. 복합 키는 레코드를 (함께) 유일하게 식별하는 테이블 내의 두 개 이상의 속성으로 구성된 키이다.[22]

외래 키

[편집]

외래 키란 관계형 테이블에서 다른 테이블의 기본 키 열과 일치하는 필드를 의미한다. 그것은 두 키를 연관시킨다. 외래 키는 참조하는 관계 내에서 반드시 유일한 값을 가질 필요는 없다. 외래 키는 테이블들을 상호참조하는 데 사용될 수 있으며, 참조되는 관계의 속성 값을 효과적으로 사용하여 참조하는 관계에 있는 하나 이상의 속성 도메인을 제한한다. 이 개념은 형식적으로 다음과 같이 설명된다: "참조하는 속성들에 대해 투영된 참조 관계의 모든 튜플에 대하여, 참조하는 각 속성의 값이 참조되는 속성의 해당 값과 일치하도록 동일한 속성들에 대해 투영된 참조되는 관계의 튜플이 반드시 존재해야 한다."

저장 프로시저

[편집]

저장 프로시저는 데이터베이스와 연관되어 있으며 대개 데이터베이스 내에 저장되는 실행 가능한 코드이다. 저장 프로시저는 일반적으로 관계에 튜플을 삽입하거나, 사용 패턴에 대한 통계 정보를 수집하거나, 복잡한 비즈니스 로직 및 계산을 캡슐화하는 것과 같은 공통 연산들을 수집하고 맞춤화한다. 보안이나 단순성을 위해 애플리케이션 프로그래밍 인터페이스(API)로 자주 사용된다. SQL RDBMS의 저장 프로시저 구현은 개발자가 표준 선언형 SQL 구문에 (종종 벤더별로 특화된) 절차적 확장을 활용할 수 있게 해준다. 저장 프로시저는 관계형 데이터베이스 모델의 일부는 아니지만, 모든 상용 구현체는 이를 포함하고 있다.

인덱스

[편집]

인덱스는 데이터에 더 빠르게 접근할 수 있는 한 방법이다. 인덱스는 관계의 속성 조합에 대해 생성될 수 있다. 해당 속성을 사용하여 필터링하는 쿼리는 각 튜플을 차례로 확인할 필요 없이 인덱스를 사용하여 일치하는 튜플을 직접 찾을 수 있다(해시 테이블 조회와 유사). 이는 찾고자 하는 정보가 있는 페이지로 직접 가기 위해 책의 색인을 사용하는 것과 유사하여, 원하는 것을 찾기 위해 책 전체를 읽을 필요가 없게 해준다. 관계형 데이터베이스는 일반적으로 여러 인덱싱 기법을 제공하며, 각 기법은 데이터 분포, 관계 크기 및 일반적인 접근 패턴의 특정 조합에 최적화되어 있다. 인덱스는 보통 B+ 트리, R 트리, 비트맵을 통해 구현된다. 인덱스는 구현의 세부 사항으로 간주되므로 보통 데이터베이스의 일부로 간주되지 않지만, 대개 데이터베이스의 다른 부분을 관리하는 팀에서 함께 관리한다. 기본 키와 외래 키 모두에 효율적인 인덱스를 사용하면 쿼리 성능을 획기적으로 향상시킬 수 있다. 이는 B-트리 인덱스의 경우 쿼리 시간이 테이블의 행 수 n에 대하여 log(n)에 비례하고, 해시 인덱스의 경우 (인덱스의 해당 부분이 메모리에 적합한 한 크기 의존성 없이) 상수 시간 쿼리 결과를 내기 때문이다.

관계 연산

[편집]

관계형 데이터베이스에 대해 수행되는 쿼리와 데이터베이스 내의 유도된 렐바들은 관계 논리 또는 관계대수로 표현된다. 코드는 그의 독창적인 관계대수에서 각각 4개의 연산자로 구성된 두 그룹으로 8개의 관계 연산자를 도입했다. 처음 4개의 연산자는 전통적인 수학적 집합 연산에 기초했다.

  • 합집합 연산자(υ)는 두 관계의 튜플들을 결합하고 결과에서 모든 중복 튜플을 제거한다. 관계형 합집합 연산자는 SQL UNION 연산자와 동일하다.
  • 교집합 연산자(∩)는 두 관계가 공통으로 공유하는 튜플 집합을 생성한다. 교집합은 SQL에서 INTERSECT 연산자의 형태로 구현된다.
  • 차집합 연산자(-)는 두 관계에 대해 작용하며, 첫 번째 관계에는 존재하지만 두 번째 관계에는 존재하지 않는 튜플 집합을 생성한다. 차집합은 SQL에서 EXCEPT 또는 MINUS 연산자의 형태로 구현된다.
  • 두 관계의 곱집합(X)은 어떠한 기준에 의해서도 제한되지 않는 조인으로, 첫 번째 관계의 모든 튜플이 두 번째 관계의 모든 튜플과 짝을 이루게 된다. 곱집합은 SQL에서 교차 조인 연산자로 구현된다.

코드가 제안한 나머지 연산자들은 관계형 데이터베이스 특유의 특별한 연산들을 포함한다.

  • 선택(selection) 또는 제한(restriction) 연산(σ)은 관계에서 튜플을 검색하며, 결과를 특정 기준을 충족하는 것들로만 제한한다. 즉 집합론 관점의 부분집합이다. 선택의 SQL 대응물은 WHERE 절이 포함된 SELECT 쿼리 문이다.
  • 투영 연산(π)은 튜플 또는 튜플 집합에서 지정된 속성만을 추출한다.
  • 관계형 데이터베이스를 위해 정의된 조인 연산은 종종 자연 조인(⋈)으로 지칭된다. 이 유형의 조인에서는 두 관계가 공통 속성에 의해 연결된다. MySQL의 자연 조인 근사치는 내부 조인 연산자이다. SQL에서 내부 조인(INNER JOIN)은 쿼리에 두 개의 테이블이 있을 때 곱집합이 발생하는 것을 방지한다. SQL 쿼리에 추가되는 각 테이블에 대해 곱집합을 방지하기 위해 하나의 추가적인 내부 조인이 더해진다. 따라서 SQL 쿼리의 N개 테이블에 대해 곱집합을 방지하려면 N-1개의 내부 조인이 있어야 한다.
  • 관계형 나눗셈(÷) 연산은 약간 더 복잡한 연산으로, 본질적으로 한 관계(피제수)의 튜플을 사용하여 두 번째 관계(제수)를 분할하는 것을 포함한다. 관계형 나눗셈 연산자는 사실상 곱집합 연산자의 반대이다(그래서 이름이 그렇다).

코드가 처음 8개를 도입한 이후, 관계형 비교 연산자와 중첩 및 계층적 데이터를 지원하는 확장 기능 등 다른 연산자들이 도입되거나 제안되었다.

정규화

[편집]

정규화는 관계형 모델의 필수적인 부분으로서 코드에 의해 처음 제안되었다. 이는 단순하지 않은 도메인(원자값이 아닌 값)과 데이터의 중복을 제거하기 위해 설계된 일련의 절차를 포함하며, 이는 결과적으로 데이터 조작 이상을 방지하고 데이터 무결성을 유지한다. 데이터베이스에 적용되는 가장 일반적인 정규화 형식은 정규형이라고 불린다.

RDBMS

[편집]
관계형 데이터베이스의 일반적인 구조

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

관계형 데이터베이스 관리 시스템의 또 다른 정의는 관계형 모델에 기반한 데이터베이스 관리 시스템(DBMS)이다. 오늘날 널리 사용되는 대부분의 데이터베이스는 이 모델에 기반하고 있다.[24]

RDBMS는 1980년대 이후 금융 기록, 제조 및 물류 정보, 인사 데이터 및 기타 애플리케이션에 사용되는 데이터베이스 정보를 저장하는 일반적인 옵션이었다. 관계형 데이터베이스는 구현과 관리가 더 쉬웠기 때문에 종종 레거시 계층형 데이터베이스와 네트워크 데이터베이스를 대체했다. 그럼에도 불구하고 관계형 저장 데이터는 1980년대와 1990년대에 관계형 데이터베이스와 객체 지향 애플리케이션 프로그램 사이의 소위 객체 관계 임피던스 불일치를 해결하려는 시도로 도입된 객체 지향 데이터베이스 관리 시스템과, 1990년대 XML 데이터베이스 관리 시스템에 의해 지속적이지만 성공적이지 못한 도전을 받았다.[25] 그러나 컴퓨터 클러스터의 수평적 확장과 같은 기술의 확대로 인해 최근에는 NoSQL 데이터베이스가 RDBMS 데이터베이스의 대안으로 인기를 얻고 있다.[26]

분산 관계형 데이터베이스

[편집]

분산 관계형 데이터베이스 아키텍처(DRDA)는 1988년부터 1994년까지 IBM 내의 작업 그룹에 의해 설계되었다. DRDA는 네트워크로 연결된 관계형 데이터베이스들이 협력하여 SQL 요청을 처리할 수 있도록 한다.[27][28] DRDA의 메시지, 프로토콜 및 구조적 구성 요소는 분산 데이터 관리 아키텍처(Distributed Data Management Architecture)에 의해 정의된다.

데이터베이스 엔진 목록

[편집]

DB-Engines에 따르면, 2024년 12월 db-engines.com 웹사이트에서 가장 인기 있는 시스템은 다음과 같다.[29]

  1. 오라클 데이터베이스
  2. MySQL
  3. 마이크로소프트 SQL 서버
  4. PostgreSQL
  5. 스노우플레이크
  6. IBM DB2
  7. SQLite
  8. 마이크로소프트 액세스
  9. 데이터브릭스
  10. MariaDB

조사 기관 가트너에 따르면, 2011년 매출 기준 5대 선도 사유 소프트웨어 관계형 데이터베이스 벤더는 오라클(48.8%), IBM(20.2%), 마이크로소프트(17.0%), 사이베이스를 포함한 SAP(4.6%), 그리고 테라데이터(3.7%)였다.[30]

미국 기업 제품

[편집]

대한민국 기업 제품

[편집]

같이 보기

[편집]

각주

[편집]
  1. ↑ Hastings, Jordan (2003). 《Portable Software Tools for Managing and Referencing Taxonomies》. Digital Mapping Techniques '03 Workshop Proceedings. 2. Relational Database Technology and Taxonomic Representation. 2014년 10월 21일에 원본 문서에서 보존된 문서. 2024년 4월 6일에 확인함 – 미국 지질조사국 경유.
  2. 1 2 3 4 Codd, E. F. (1970). 《A Relational Model of Data for Large Shared Data Banks》. 《커뮤니케이션스 오브 더 ACM》 13. 377–387쪽. doi:10.1145/362384.362685. S2CID 207549016.
  3. ↑ Ambler, Scott (2023년 3월 21일). “Relational Databases 101: Looking at the Whole Picture”.
  4. ↑ Date, Chris (2005년 5월 5일). 《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. 1999년 1월 8일. ISBN 0309062780.
  6. ↑ Sumathi, S.; Esakkirajan, S. (2008년 2월 13일). 《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. ↑ Leavitt, Don (1976년 9월 6일). “MDBM' Backs Network, Relational Approaches” (영어). 《Computerworld》 (IDG Enterprise).
  8. ↑ Schmidt, Joachim W.; Brodie, Michael L. (1982). 《Relational Database Systems: Analysis and Comparison》 (영어). Springer Science & Business Media. 181–220쪽. ISBN 978-3-642-68847-8.
  9. ↑ 《Oracle Timeline》 (PDF). 《Profit Magazine》 12 (Oracle). May 2007. 26쪽. 2013년 5월 16일에 확인함.
  10. ↑ “New Database Software Program Moves Macintosh Into The Big Leagues”. 《tribunedigital-chicagotribune》. 1987년 6월 28일. 2016년 3월 17일에 확인함.
  11. ↑ Hershey, W.R.; Easthope, C.H. (1972년 12월 1일). 《A set theoretic data structure and retrieval language》. 《ACM SIGIR Forum》 7 (ACM). 45–55쪽. doi:10.1145/1095495.1095500. 2024년 1월 4일에 확인함.
  12. ↑ 《SIGFIDET '74: Proceedings of the 1974 ACM SIGFIDET (Now SIGMOD) Workshop on Data Description, Access and Control: Data Models: Data-Structure-Set versus Relational》. ACM. 1975년 1월 1일. doi:10.1145/800297. ISBN 978-1-4503-7418-7. 2024년 1월 4일에 확인함.
  13. ↑ Notley, M.G. (1972). 《The Peterlee IS/1 System》. IBM United Kingdom Scientific Centre. 2024년 1월 4일에 확인함.
  14. ↑ Todd, Stephen (1976). 《The Peterlee Relational Test Vehicle - A System Overview》. 《IBM Systems Journal》 15. 285–308쪽. doi:10.1147/sj.154.0285.
  15. ↑ Ramakrishnan, Raghu; Donjerkovic, Donko; Ranganathan, Arvind; Beyer, Kevin S.; Krishnaprasad, Muralidhar (1998). 《SRQL: Sorted Relational Query Language》 (PDF). 《E Proceedings of SSDBM》.
  16. ↑ “A Relational Database Overview”. 《oracle.com》.
  17. ↑ “A universal relation model for a nested database”, 《The Nested Universal Relation Database Model》, Lecture Notes in Computer Science (Berlin, Heidelberg: Springer Berlin Heidelberg) 595, 1992, 109–135쪽, doi:10.1007/3-540-55493-9_5, ISBN 978-3-540-55493-6, 2020년 11월 1일에 확인함
  18. ↑ “Gray to be Honored With A. M. Turing Award This Spring”. Microsoft PressPass. 1998년 11월 23일. 2009년 2월 6일에 원본 문서에서 보존된 문서. 2009년 1월 16일에 확인함.
  19. ↑ 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. 144–154쪽. 2006년 11월 9일에 확인함.
  20. ↑ Gray, Jim, and Reuter, Andreas, Distributed Transaction Processing: Concepts and Techniques. Morgan Kaufmann, 1993. ISBN 1-55860-190-2.
  21. ↑ Date (1984), 268쪽.
  22. ↑ Connolly, Thomas M; Begg, Carolyn E (2015). 《Database systems: a practical approach to design, implementation, and management》 global판. Boston Columbus Indianapolis: Pearson. 416쪽. ISBN 978-1-292-06118-4.
  23. ↑ Connolly, Thomas M.; Begg, Carolyn E. (2014). 《Database Systems – A Practical Approach to Design Implementation and Management》 6판. Pearson. 64쪽. ISBN 978-1292061184.
  24. ↑ Pratt, Philip J.; Last, Mary Z. (2014년 9월 8일). 《Concepts of Database Management》 8판. Course Technology. 29쪽. ISBN 9781285427102.
  25. ↑ Feuerlich, George (2010년 4월 21일). 《Dateso 10; Database Trends and Directions: Current Challenges and Opportunities》 1판. Prague, Sokolovsk: MATFYZPRESS. 163–174쪽. ISBN 978-80-7378-116-3.
  26. ↑ “NoSQL databases eat into the relational database market”. 2015년 3월 4일. 2018년 3월 14일에 확인함.
  27. ↑ Reinsch, R. (1988). 《Distributed database for SAA》. 《IBM Systems Journal》 27. 362–389쪽. doi:10.1147/sj.273.0362.
  28. ↑ 《Distributed Relational Database Architecture Reference》. IBM Corp. SC26-4651-0. 1990.
  29. ↑ “DB-Engines Ranking of Relational DBMS”. 《DB-Engines》. 2024년 12월 1일에 확인함.
  30. ↑ “Oracle the clear leader in $24 billion RDBMS market”. 《Eye on Oracle》. 2012년 4월 12일. 2014년 1월 8일에 원본 문서에서 보존된 문서. 2013년 3월 1일에 확인함.
원본 주소 "https://ko.wikipedia.org/w/index.php?title=관계형_데이터베이스&oldid=42146853"