IBM의 Don Chamberlin과 Ray Boyce가 발명한 SQL(Structured Query Language)은 관계형 데이터베이스 관리 시스템과 상호 작용하기 위한 표준 프로그래밍 언어로, 데이터베이스 관리자가 데이터 행을 쉽게 추가, 업데이트 또는 삭제할 수 있도록 합니다. 원래 SEQUEL로 알려졌지만 상표 문제로 인해 SQL로 간소화되었습니다. 또한 SQL 쿼리를 사용하면 몇 줄의 코드만 사용하여 데이터베이스에서 데이터를 검색할 수 있습니다. 이러한 관계를 감안할 때 관계형 데이터베이스를 때때로 "SQL 데이터베이스"라고도 하는 이유를 쉽게 알 수 있습니다.  

위의 예시를 사용하여 다음 코드를 사용하여 특정 연도의 회사별 상위 10개 거래를 찾는 쿼리를 작성할 수 있습니다:

SELECT COMPANY_NAME, SUM(TRANSACTION_AMOUNT)

FROM TRANSACTION_TABLE A

좌측 조인 고객_테이블 B

ON A.CUSTOMER_ID = B.CUSTOMER_ID

여기서 year(date) = 2022

1 그룹화

2 DESC 로 주문

제한 10

이러한 방식으로 데이터를 조인할 수 있는 기능은 데이터 시스템 내의 중복성을 줄이는 데 도움이 되며, 데이터 팀은 향후 다른 트랜잭션이 발생할 경우 이 정보를 복제하지 않고도 고객을 위해 하나의 마스터 테이블을 유지할 수 있습니다. 자세한 내용은 Don 의 논문(IBM 외부 링크)에서 SQL의 역사에 대해 자세히 설명합니다.

관계형 데이터베이스 이전에 기업들은 데이터 테이블에 대해 트리와 같은 구조의 계층적 데이터베이스 시스템을 사용했습니다. 이러한 초기 데이터베이스 관리 시스템(DBMS)을 통해 사용자는 대량의 데이터를 구성할 수 있었습니다. 그러나 이들은 복잡하고 특정 애플리케이션에서만 사용할 수 있는 경우가 많았고 데이터 내에서 발견할 수 있는 방법이 제한적이었습니다. 이러한 한계로 인해 결국 IBM의 연구원인 Edgar F. Codd는 1970년에 “대규모 공유 데이터 뱅크를 위한 데이터의 관계형 모델”이라는 제목의 논문 (IBM 외부 링크) (PDF, 1.5MB)을 발표하여 관계형 데이터베이스 모델을 이론화했습니다. " 이 제안된 모델에서는 전문적인 컴퓨터 지식 없이도 정보를 검색할 수 있습니다. 그는 의미 있는 관계를 기반으로 데이터를 튜플 또는 속성-값 쌍으로 정렬할 것을 제안했습니다. 튜플 집합을 관계라고 하는데, 이를 통해 궁극적으로 테이블 간에 데이터를 병합할 수 있게 되었습니다.

1973년, 현재 알마덴 리서치 센터(Almaden Research Center)로 알려진 산호세 연구소(San Jose Research Laboratory)는 이 관계 이론을 "산업적 강점의 구현"으로 증명하기 위해 System R(관계형을 뜻하는 R)이라는 프로그램을 시작했습니다. 궁극적으로 SQL의 시험장이 되어 단기간에 더 널리 채택될 수 있었습니다. 그러나 Oracle이 SQL을 채택하더라도 데이터베이스 관리자 사이에서 인기가 떨어지지는 않았습니다.

1983년에 IBM은 IBM의 두 번째 데이터베이스 관리 소프트웨어 제품군이었기 때문에 DB2 관계형 데이터베이스 제품군을 출시했습니다. 오늘날 IBM의 가장 성공적인 제품 중 하나로, 클라우드 인프라에서 매일 수십억 건의 트랜잭션을 계속 처리하고 머신 러닝 애플리케이션의 기본 계층을 설정합니다.

관계형 데이터베이스는 데이터를 테이블 형식으로 구조화하는 반면, 비관계형 데이터베이스는 데이터베이스 스키마만큼 엄격하지 않습니다. 실제로 비관계형 데이터베이스는 데이터베이스 유형에 따라 데이터를 다르게 구성합니다. 비관계형 데이터베이스의 유형에 관계없이 모두 텍스트, 비디오 및 이미지와 같은 비정형 데이터 형식에 적합하지 않은 관계형 모델에 내재된 유연성 및 확장성 문제를 해결하는 것을 목표로 합니다. 이러한 유형의 데이터베이스는 다음과 같습니다.

• 키-값 저장소: 이 스키마 없는 데이터 모델은 키-값 쌍의 사전으로 구성되며, 각 항목에는 키와 값이 있습니다. 키는 장바구니 ID와 같이 SQL 데이터베이스에서 찾을 수 있는 것과 유사할 수 있지만 값은 해당 사용자의 장바구니에 있는 각 개별 항목과 같은 데이터 배열입니다. 일반적으로 장바구니와 같은 사용자 세션 정보를 캐싱하고 저장하는 데 사용됩니다. 그러나 한 번에 여러 레코드를 가져와야 하는 경우에는 적합하지 않습니다. Redis와 Memcached는 이 데이터 모델을 사용하는 오픈 소스 데이터베이스의 예입니다.

• 문서 저장소: 이름에서 알 수 있듯이 문서 데이터베이스는 데이터를 문서로 저장합니다. 반정형 데이터를 관리하는 데 도움이 될 수 있으며 데이터는 일반적으로 JSON, XML 또는 BSON 형식으로 저장됩니다. 이렇게 하면 응용 프로그램에서 데이터를 사용할 때 데이터를 함께 유지하여 데이터를 사용하는 데 필요한 번역의 양을 줄일 수 있습니다. 또한 개발자는 데이터 스키마가 문서 간에 일치할 필요가 없기 때문에 더 많은 유연성을 얻을 수 있습니다(예: name vs. first_name). 그러나 이는 복잡한 트랜잭션의 경우 문제가 될 수 있으며 데이터 손상으로 이어질 수 있습니다. 문서 데이터베이스의 인기 있는 사용 사례에는 콘텐츠 관리 시스템 및 사용자 프로필이 포함됩니다. 문서 지향 데이터베이스의 예로는 MEAN 스택의 데이터베이스 구성 요소인 MongoDB가 있습니다.

• 와이드 컬럼 스토어: 이러한 데이터베이스는 정보를 열에 저장하여 사용자가 관련 없는 데이터에 추가 메모리를 할당하지 않고도 필요한 특정 열에만 액세스할 수 있도록 합니다. 이 데이터베이스는 키-값 및 문서 저장소의 단점을 해결하려고 하지만 관리하기가 더 복잡한 시스템이 될 수 있으므로 신생 팀이나 프로젝트에는 사용하지 않는 것이 좋습니다. 오픈 소스, 와이드 컬럼 데이터베이스의 예로는 Apache HBase와 Apache Cassandra가 있습니다. Apache HBase는 많은 빅 데이터 애플리케이션에서 일반적으로 사용되는 희소 데이터 세트를 저장하는 방법을 제공하는 Hadoop 분산 파일 시스템 위에 구축되었습니다. 반면 Apache Cassandra는 여러 서버에 걸친 대용량 데이터와 여러 데이터 센터에 걸친 클러스터링을 관리하도록 설계되었습니다. 소셜 네트워킹 웹사이트, 실시간 데이터 분석 등 다양한 사용 사례에 사용되고 있습니다.

• 그래프 저장소: 이 유형의 데이터베이스는 일반적으로 지식 그래프의 데이터를 보관합니다. 데이터 요소는 노드, 에지 및 속성으로 저장됩니다. 모든 개체, 장소 또는 사람이 노드가 될 수 있습니다. 에지는 노드 간의 관계를 정의합니다. 그래프 데이터베이스는 그래프 내의 요소 간 연결 네트워크를 저장하고 관리하는 데 사용됩니다. Neo4j(IBM 외부 링크)는 사용자가 온라인 백업 및 고가용성 확장에 대한 라이센스 또는 백업 및 확장이 포함된 사전 패키지 라이센스 버전을 구매할 수 있는 오픈 소스 커뮤니티 에디션이 포함된 Java 기반 그래프 기반 데이터베이스 서비스입니다.

또한 NoSQL 데이터베이스 는 일관성보다 가용성을 우선시합니다.

컴퓨터가 네트워크를 통해 실행될 때 항상 일관된 결과(모든 응답이 항상 동일함) 또는 "가용성"이라고 하는 높은 가동 시간의 우선 순위를 결정해야 합니다. 이를 "CAP 이론"이라고 하며, 이는 일관성(Consistency), 가용성(Availability) 또는 파티션 허용 오차(Partition Tolerance)를 나타냅니다. 관계형 데이터베이스는 정보가 항상 동기화되고 일관성을 유지하도록 보장합니다. Redis와 같은 일부 NoSQL 데이터베이스는 항상 응답을 제공하는 것을 선호합니다. 즉, 쿼리에서 받은 정보가 몇 초(최대 30분) 동안 정확하지 않을 수 있습니다. 소셜 미디어 사이트에서 이것은 최신 사진이 몇 분 밖에 되지 않았을 때 오래된 프로필 사진을 보는 것을 의미합니다. 대안은 시간 초과 또는 오류일 수 있습니다. 반면에 은행 및 금융 거래에서는 오류가 발생하고 다시 제출하는 것이 오래되고 잘못된 정보보다 나을 수 있습니다.

SQL과 NoSQL의 차이점에 대한 자세한 내용은 "SQL과 NoSQL 데이터베이스: 차이점"을 참조하세요."

관계형 데이터베이스 접근 방식의 주요 이점은 테이블을 조인하여 의미 있는 정보를 만들 수 있다는 것입니다. 테이블을 조인하면 데이터 간의 관계 또는 테이블 연결 방법을 이해할 수 있습니다. SQL에는 쿼리를 계산, 추가, 그룹화 및 결합하는 기능이 포함되어 있습니다. SQL은 기본적인 수학 및 소계 함수와 논리적 변환을 수행할 수 있습니다. 분석가는 날짜, 이름 또는 모든 열을 기준으로 결과를 정렬할 수 있습니다. 이러한 기능으로 인해 관계형 접근 방식은 오늘날 비즈니스에서 가장 인기 있는 단일 쿼리 툴이 되었습니다.

관계형 데이터베이스는 다른 데이터베이스 형식에 비해 다음과 같은 몇 가지 장점이 있습니다.

사용 편의성

제품 수명 덕분에 관계형 데이터베이스를 둘러싼 커뮤니티가 더 많아져 부분적으로 지속적인 사용을 영속화합니다. 또한 SQL을 사용하면 여러 테이블에서 데이터 세트를 쉽게 검색하고 필터링 및 집계와 같은 간단한 변환을 수행할 수 있습니다. 관계형 데이터베이스 내에서 인덱스를 사용하면 선택한 테이블의 각 행을 검색하지 않고도 이 정보를 빠르게 찾을 수 있습니다.

관계형 데이터베이스는 역사적으로 더 엄격하고 유연하지 않은 데이터 스토리지 옵션으로 간주되어 왔지만, 기술 및 DBaaS 옵션의 발전으로 이러한 인식이 바뀌고 있습니다. NoSQL 데이터베이스 오퍼링에 비해 스키마를 개발하는 데 여전히 더 많은 오버헤드가 있지만 관계형 데이터베이스는 클라우드 환경으로 마이그레이션함에 따라 더욱 유연해지고 있습니다.

중복성 감소 

관계형 데이터베이스는 두 가지 방법으로 중복성을 제거할 수 있습니다. 관계형 모델 자체는 정규화라는 프로세스를 통해 데이터 중복성을 줄입니다. 앞서 언급했듯이 고객 테이블은 여러 트랜잭션에 대해 이 정보를 복제하지 않고 고객 정보의 고유한 레코드만 기록해야 합니다.

저장 프로시저는 반복 작업을 줄이는 데도 도움이 됩니다. 예를 들어, 데이터베이스 액세스가 특정 역할, 기능 또는 팀으로 제한되는 경우 저장 프로시저는 액세스 제어를 관리하는 데 도움이 될 수 있습니다. 이러한 재사용 가능한 기능을 통해 애플리케이션 개발자는 영향력이 큰 작업을 처리할 수 있는 시간을 확보할 수 있습니다.

간편한 백업 및 재해 복구 

관계형 데이터베이스는 트랜잭션 데이터베이스로, 전체 시스템의 상태가 언제든지 일관되게 유지되도록 보장합니다. 대부분의 관계형 데이터베이스는 간편한 내보내기 및 가져오기 옵션을 제공하므로 백업 및 복원이 간편합니다. 이러한 내보내기는 데이터베이스가 실행되는 동안에도 발생할 수 있으므로 실패 시 쉽게 복원할 수 있습니다. 최신 클라우드 기반 관계형 데이터베이스는 연속 미러링을 수행할 수 있으므로 복원 시 데이터 손실이 몇 초 이내에 측정됩니다. 대부분의 클라우드 관리 서비스를 사용하면 IBM Cloud® Databases for PostgreSQL에서와 같이 읽기 전용 복제본을 작성할 수 있습니다. 이러한 읽기 전용 복제본을 사용하면 클라우드 데이터 센터에 데이터의 읽기 전용 복사본을 저장할 수 있습니다. 복제본은 재해 복구 를 위해 읽기/쓰기 인스턴스로 승격될 수도 있습니다.