관계형 데이터베이스는 데이터를 행과 열로 구성된 테이블 형태로 구성합니다. 데이터는 일반적으로 여러 테이블로 구조화되며, 이러한 테이블은 기본 키 또는 외래 키를 통해 조인될 수 있습니다. 이러한 고유한 식별자는 테이블 간에 존재하는 다양한 관계를 보여주며, 이러한 관계는 일반적으로 다양한 유형의 데이터 모델을 통해 설명됩니다. 분석가들은 SQL 쿼리를 사용하여 다양한 데이터 포인트를 결합하고 비즈니스 성과를 요약하므로 조직은 인사이트를 얻고, 워크플로우를 최적화하고, 새로운 기회를 찾을 수 있습니다.

예를 들면, 회사가 고객 정보를 포함하는 있는 데이터베이스 테이블을 유지 관리하고 있고, 이는 계정 수준에서의 회사 데이터가 포함되어 있습니다. 해당 계정과 관련된 모든 개별 거래를 설명하는 다른 테이블도 있을 수 있습니다. 이러한 테이블들은 특정 소프트웨어 제품을 구입하는 다른 산업에 대한 정보를 제공할 수 있습니다.

이 고객 테이블의 열(또는 필드)은 고객 ID, 회사 이름, 회사 주소, 산업 등이 될 수 있습니다. 거래 테이블의 열은 거래 날짜, 고객 ID, 거래 금액, 결제 방법 등이 될 수 있습니다. 테이블은 공통된 고객 ID 필드를 사용하여 함께 조인될 수 있습니다. 따라서 산업이나 회사별 판매 보고서와 같은 가치 있는 보고서를 생성하기 위해 테이블을 쿼리할 수 있으며, 이는 잠재적인 고객에 대한 메시징을 결정하는 데 도움이 될 수 있습니다.

관계형 데이터베이스는 일반적으로 명령 또는 트랜잭션을 함께 실행하는 트랜잭션 데이터베이스와 관련이 있습니다. 이를 설명하는 자주 사용되는 예는 은행 이체입니다. 정해진 금액이 한 계좌에서 출금되어 다른 계좌에 입금됩니다. 전체 금액이 출금되고 입금되며, 이러한 트랜잭션은 어떤 부분적인 형태로도 발생할 수 없습니다. 트랜잭션은 특정한 속성을 가지고 있습니다. ACID 약어로 표현되며, ACID 속성은 다음과 같이 정의됩니다.

• 원자성(Atomicity): 모든 데이터 변경 작업은 하나의 단일 작업으로 수행되는 것처럼 수행됩니다. 즉, 모든 변경 사항이 수행되거나 수행되지 않습니다.

• 일관성(Consistency): 데이터는 시작 상태부터 끝 상태까지 일관된 상태를 유지하여 데이터 무결성을 강화합니다.

• 격리성(Isolation): 트랜잭션의 중간 상태는 다른 트랜잭션에서 보이지 않으며, 결과적으로 동시에 실행되는 트랜잭션은 순차적으로 실행되는 것처럼 보입니다.

• 지속성(Durability): 트랜잭션이 성공적으로 완료된 후, 데이터의 변경 사항은 지속되며 시스템 장애가 발생하더라도 변경 사항이 취소되지 않습니다.

이러한 속성들은 신뢰성 있는 트랜잭션 처리를 가능하게 합니다.

관계형 데이터베이스 및 관계형 데이터베이스 관리 시스템

관계형 데이터베이스는 관계형 데이터 모델을 기반으로 데이터를 정리하는 한편, 관계형 데이터베이스 관리 시스템(relational database management system, RDBMS)은 사용자가 이러한 데이터베이스를 관리하도록 지원하는 기반 데이터베이스 소프트웨어를 더 구체적으로 지칭합니다. 이러한 프로그램을 사용하면 사용자는 시스템에서 데이터를 생성, 업데이트, 삽입 또는 삭제할 수 있습니다. 이러한 프로그램은 다음을 제공합니다.

• 데이터 구조

• 다중 사용자 액세스

• 권한 제어

• 네트워크 액세스

인기 있는 RDBMS 시스템의 예로는 MySQL, PostgreSQL, IBM DB2가 있습니다. 또한, 관계형 데이터베이스 시스템은 데이터를 테이블로 저장하지만 기본 데이터베이스 관리 시스템(DBMS)은 정보를 파일로 저장하므로 관계형 데이터베이스 시스템은 DBMS와 다릅니다.

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

위의 예시에 따라 다음 코드를 사용하여 특정 연도에 회사별로 상위 트랜잭션 10가지를 확인하는 쿼리를 만들 수 있습니다.

SELECT COMPANY_NAME, SUM(TRANSACTION_AMOUNT)

FROM TRANSACTION_TABLE A

LEFT JOIN CUSTOMER_TABLE B

ON A.CUSTOMER_ID = B.CUSTOMER_ID

WHERE YEAR(DATE) = 2022

GROUP BY 1

ORDER BY 2 DESC

LIMIT 10

이와 같은 방식으로 데이터를 조인할 수 있으므로 데이터 시스템 안에서 중복성을 줄일 수 있습니다. 이를 통해 데이터 팀은 다른 트랜잭션이 미래에 발생하는 경우 정보를 복제하지 않고 고객에 대한 마스터 테이블을 하나만 둘 수 있습니다. 더 자세히 알아보려면,  여기(IBM 외부 링크)에 제시된 논문에서 SQL의 역사에 대해 자세한 Don의 설명을 참고하세요.

관계형 데이터베이스 이전에 기업들은 데이터 테이블을 위한 트리와 같은 구조를 가진 계층적 데이터베이스 시스템을 사용했습니다. 이 초기 데이터베이스 관리 시스템(database management system, DBMS) 덕분에 사용자는 대량의 데이터를 체계적으로 정리할 수 있었습니다. 그러나, 이 시스템은 복잡했고, 특정 애플리케이션에만 사용할 수 있는 경우가 많았으며, 데이터 내에서 발견하는 능력이 제한적이었습니다. 이러한 한계점 때문에 결국 IBM 연구원인 Edgar F. Codd는1970년에 "A Relational Model of Data for Large Shared Data Banks”(대량의 공유 데이터 은행을 위한 관계형 데이터 모델)라는 제목의 논문(IBM 외부 링크)(PDF, 1.5MB)을 발표했습니다. 이 논문은 관계형 데이터베이스 모델을 이론화했습니다. 제안된 이 모델에서 정보는 전문화된 컴퓨터 지식 없이도 검색할 수 있습니다. 그는 의미 있는 관계를 기반으로 데이터를 튜플 또는 특성-값 쌍으로 배열할 것을 제안했습니다. 튜플 세트를 관계라고 불렀으며, 이러한 관계는 궁극적으로 테이블 간의 데이터 병합을 가능하게 했습니다.

1973년, 지금은 Almaden Research Center라고 알려진 San Jose Research Laboratory는 "산업형 강점 구현"이라고 하는 방법을 통해 이 관계형 이론을 입증하기 위해 System R(R은 relation(관계)의 약자)이라는 프로그램을 시작했습니다. 이는 궁극적으로 SQL의 시험장이 되었으며, 이를 통해 SQL은 단기간 안에 더 널리 채택되게 되었습니다. 그러나, Oracle이 SQL을 채택한 것도 데이터베이스 관리자들 사이에서 SQL의 인기를 높이는 데 도움이 되었습니다.

1983 즈음 IBM은 DB2 관계형 데이터베이스 제품군을 소개했습니다. DB2는 IBM의 두 번째 데이터베이스 관리 소프트웨어 제품군이었으므로 그렇게 이름이 붙여졌습니다. 현재 DB2는 IBM의 가장 성공적인 제품 중 하나이며 클라우드 인프라에서 매일 수십억 건의 트랜잭션을 계속 처리하고 있고 머신 러닝 애플리케이션을 위한 토대가 되는 계층을 제공하고 있습니다.

IBM의 역사에 대해 자세히 보려면  여기를 클릭하세요.

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

• 키-값 저장소: 스키마가 없는 이 데이터 모델은 키-값 쌍으로 구성된 사전으로 조직화되며, 각 항목은 키와 값을 가지고 있습니다. 키는 쇼핑 카트 ID처럼 SQL 데이터베이스에서 사용되는 유사한 어떤 것일 수 있으며, 값은 사용자의 쇼핑 카트에 있는 개별 항목과 같은 일련의 데이터입니다. 이 모델은 쇼핑 카트와 같은 사용자 세션 정보를 캐시하고 저장하는 데 흔히 사용됩니다. 그러나, 이 모델은 한 번에 여러 레코드를 가져와야 할 경우 적합하지 않습니다. Redis와 Memcached는 이 데이터 모델을 사용한 오픈소스 데이터베이스의 예입니다.

• 문서 저장소: 이름에서 알 수 있듯이, 문서 데이터베이스는 데이터를 문서로 저장합니다. 이 저장소는 준정형 데이터를 관리하는 데 유용하며, 데이터는 일반적으로 JSON, XML 또는 BSON 형식으로 저장됩니다. 이 저장소는 데이터가 애플리케이션에서 사용될 때 데이터를 함께 모아두어 데이터를 사용할 때 변환 작업을 줄여줍니다. 또한 문서 간 데이터 스키마(예: name과 first_name)가 일치하지 않아도 되므로 개발자는 더 큰 유연성을 누릴 수 있습니다. 그러나, 이러한 특징은 복잡한 트랜잭션의 경우 문제가 될 수 있으며 데이터 손상을 유발할 수 있습니다. 문서 데이터베이스의 흔한 사용 사례로는 콘텐츠 관리 시스템 및 사용자 프로필이 있습니다. 문서 지향적 데이터베이스의 예로는MongoDB가 있습니다. MongoDB는 MEAN 스택의 데이터베이스 구성요소입니다.

• 와이드-컬럼 저장소: 이 데이터베이스는 정보를 컬럼에 저장하므로 사용자는 관련 없는 데이터에 추가 메모리를 할당하지 않고 특정 컬럼에만 액세스할 수 있습니다. 이 데이터베이스는 키-값 저장소와 문서 저장소의 단점을 해결하려고 합니다. 하지만, 이 데이터베이스는 관리하기가 더 어려운 시스템일 수 있으므로 새로운 팀과 프로젝트에는 권장되지 않습니다. Apache HBase와 Apache Cassandra는 오픈소스 와이드-컬럼 데이터베이스의 예입니다. Apache HBase는 희소 데이터 세트를 저장하는 한 방법을 제공하는 Hadoop Distributed Files System(많은 빅데이터 애플리케이션에서 흔히 사용됨)을 기반으로 구축됩니다. 한편, Apache Cassandra는 여러 서버, 그리고 여러 데이터 센터를 포괄하는 클러스터링에 걸쳐 대량의 데이터를 관리하도록 설계되었습니다. 이 데이터베이스는 소셜 네트워킹 웹사이트 및 실시간 데이터 분석 등 다양한 사용 사례에 사용되어 왔습니다.

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

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

컴퓨터가 네트워크를 통해 실행될 때, 항상 일관된 결과(모든 답이 항상 같은 경우) 또는 높은 가동 시간(이를 "가용성"이라고 부름) 중 무엇을 우선시할지 결정해야 합니다. 이를 "CAP 이론"이라고 하며, CAP는 Consistency(일관성), Availability(가용성) 또는 Partition Tolerance(분할 허용성)를 의미합니다. 관계형 데이터베이스는 정보가 항상 동기화되고 일관성을 유지합니다. Redis와 같은 일부 NoSQL 데이터베이스는 항상 응답을 제공하는 것을 선호합니다. 따라서 사용자가 쿼리를 통해 받는 정보가 몇 초(또는 최대 30초까지)만큼 정확하지 않을 수 있습니다. 이는 소셜 미디어 사이트에서 최신 프로필 사진을 게시한 지 얼마 되지 않은 경우 사용자는 기존 프로필 사진을 보게 됨을 의미합니다. 또는 이 경우 시간초과 또는 오류가 발생할 수 있습니다. 반면에, 은행 및 금융 거래에서 오류가 발생할경우 오래된 부정확한 정보보다는 오류를 수정하고 다시 제출하는 것이 더 나을 수 있습니다.

SQL과 NoSQL의 차이점에 대한 설명 전체를 확인하려면, "SQL과 NoSQL 데이터베이스: 차이점은 무엇인가?"를 참조하세요.

관계형 데이터베이스 접근법의 주된 장점은 테이블을 조인하여 의미 있는 정보를 생성할 수 있다는 것입니다. 테이블을 조인하여 사용자는 데이터터 간의 관계 또는 테이블들이 연결되는 방식을 이해할 수 있습니다. SQL에는 쿼리를 세고, 추가하고, 그룹화하고, 결합할 수 있는 기능이 포함되어 있습니다. SQL은 기본적인 수학 및 소계 함수와 논리적 변환을 실행할 수 있습니다. 분석가는 날짜, 이름 또는 열별로 결과를 주문할 수 있습니다. 이러한 기능 덕분에 관계형 접근법은 현재 비즈니스 분야에서 가장 인기 있는 쿼리 툴이 되었습니다.

관계형 데이터베이스는 다른 데이터베이스 형식과 비교할 때 여러 가지 장점이 있습니다.

사용 편의성

관계형 데이터베이스의 제품 수명으로 인해, 이를 둘러싼 커뮤니티가 더 많이 형성되어 있으며 이는 이 기술의 계속적인 사용을 일부 유지시키고 있습니다. 또한 SQL을 사용하면 쉽게 여러 테이블에서 데이터 세트를 검색하고 필터링 및 집계와 같은 단순한 변환을 수행할 수 있습니다. 또한 관계형 데이터베이스 내에서 인덱스를 사용할 수 있으므로 선택된 테이블에서 각 행을 검색하지 않아도 신속하게 정보를 찾을 수 있습니다.

지금까지 관계형 데이터베이스는 경직되고 유연성 없는 데이터 저장 옵션으로 간주되어 왔지만, 기술 및 DBaaS 옵션의 발전으로 이러한 인식이 바뀌고 있습니다. NoSQL 데이터베이스 오퍼링과 비교하여 SQL 데이터베이스는 스키마를 개발해야 하는 오버헤드가 여전히 더 많지만, 관계형 데이터베이스는 클라우드 환경으로 마이그레이션하면서 더 유연해지고 있습니다.

중복성 감소 

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

또한 저장 프로시저는 반복적인 작업을 줄이는 데에도 도움이 됩니다. 예를 들면, 데이터베이스 액세스가 특정 역할, 기능 또는 팀으로 제한된 경우, 저장 프로시저는 액세스 제어 관리를 도울 수 있습니다. 이러한 재사용 가능한 기능으로 귀중한 애플리케이션 개발자의 시간을 절약하여 영향이 큰 업무에 사용할 수 있습니다.

백업 및 재해 복구 용이성 

관계형 데이터베이스는 트랜잭션형입니다. 즉, 어느 순간에나 시스템 전체의 일관성을 보장합니다. 대부분의 관계형 데이터베이스는 쉬운 내보내기 및 가져오기 옵션을 제공하므로 백업과 복원이 간단해집니다. 이러한 내보내기는 데이터베이스가 실행 중일 때에도 가능하므로 장애 시 복원이 쉬워집니다. 최신 클라우드 기반 관계형 데이터베이스는 지속적 미러링을 할 수 있으므로 복원 대상 손실 데이터를 초 이하 단위로 측정합니다. 대부분의 클라우드 매니지드 서비스에서는 IBM® Cloud Databases for PostgreSQL과 같이 읽기 전용 복제본을 생성할 수 있습니다. 이러한 읽기 전용 복제본을 사용하면 클라우드 데이터 센터에 데이터의 읽기 전용 복사본을 저장할 수 있습니다. 또한 복제본은 재해 복구를 위해 읽기/쓰기 인스턴스로 승격될 수 있습니다.