데이터 모델과 질의 언어

관계형 모델과 문서 모델

데이터는 테이블이라 불리는 관계로 구성되고 각 관계는 순서 없는 튜플(row)의 모음이다. 비즈니스 데이터 철, 트랜잭션 처리, 일괄처리로 일상적에서 수행되는 일. 관계형 모델의 목표는 정리된 인터페이스 뒤로 구현 세부 사항을 숨기는 것이다. 오늘날 웹에서 볼 수 있는 대부분의 서비스는 여전히 관계형 데이터베이스를 통해 제공된다.

NoSQL의 탄생

애플리케이션은 저마다 요구사항이 다르고, 사용사례에 맞는 최적의 선택을 한다. 관계형 데이터베이스가 폭넓은 다양함을 가진 비관계형 데이터스토어와 함께 사용될 것이다. 다중 저장소 지속성(polyglot persistence)

객체 관계형 불일치

객체지향 프로그래밍 언어로 개발을 할 때 애플리케이션 코드와 데이터베이스 모델 객체 사이에 거추장스러운 전환 계층이 필요하다. 이런 것을 임피던스 불일치라고 부른다. (Ex :spring에서 Dto -> entity -> DB.) 하이버네이트(Hibernate) 같은 객체 관계형 매핑(ROM) 프레임워크는 그 코드의 양을 줄이지만 차이를 완벽히 숨길 수 없다.

JSON모델이 애플리케이션 코드와 저 계층 간 임피던스 불일치를 줄인다고 생각하는 개발자도 있다. 다중 테이블 스키마보다 더 나은 지역성을 갖는다. 관계형 데이터베이스에서 프로필을 가져오려면 다중 질의, 다중 JOIN을 해야 한다. (사용자, 회사, 직위, 교육 테이블 등)

ID나 텍스트 문자열의 저장 여부는 중복의 문제. ID를 사용하는 경우 사람에게 의미 있는 정보는 한 곳에만 저장하고 그것을 참조하는 모든 것은 ID를 사용한다. 텍스트를 직접 저장한다면 그것을 사용하는 모든 레코드에서 사람을 의미하는 정보를 중복해서 저장하게 된다. ID자체는 아무런 의미가 없기 때문에 변경할 필요가 없다. 시식별정보를 변경해도 ID는 동일하게 유지할 수 있다. 정규화의 문제임.

중복된 데이터를 정규화 하려면 다대일 관계가 필요한대, 관계형 데이터베이스는 문서 모델에 적합하지 않다. 조인이 쉽기 때문에 ID로 다른 테이블의 row를 참조하는 방식은 일반적이다. 문서 DB에서는 일대다 트리 구조를 위한 조인이 필요하지 않지만 조인에 대한 지원이 약하다.

네트워크 모델(코다실 모델)

계층 모델의 트리 구조에서 모든 레코드는 정확하게 하나의 부모가 있다. 하지만 네트워크 모델에서는 다중 부모가 있다. 레코드 간 연결은 FK보다는 포인터와 더 비슷하다. 레코드에 접근하는 유일한 방법은 최상위 레코드에서부터 연속된 경로를 따르는 방법(접근 경로).

관계형 모델

알려진 모든 데이터를 배치하는 것이다. 중첩 구조가 없고, 복잡한 접근 경로가 없다. 따라서 관계형 모델은 애플리케이션에 새로운 기능을 추가하는 작업이 훨씬 쉽다.

문서 데이터베이스와의 비교

별도 테이블이 아닌 상위 레코드 내에 중첩된 레코드를 저장한다. 다대일, 다대다 관계를 표현할 때 관계형 데이터베이스와 문서 데이터베이스는 근본적으로 다르지 않다. 둘 다 고유한 식별자로 참조한다. (FK VS 문서 참조)

문서 데이터 모델의 선호하는 이유는 스키마 유연성, 지역성에 기인한 더 나은 성능.

관계형 모델은 조인, 다대일, 다대다 관계를 더 잘 지원한다.

어떤 모델이 코드를 더 간단하게 하는가?

애플리케이션에서 데이터가 문서와 비슷한 구조라면 문서 모델을 사용하는 것이 좋다. 문서가 깊게 중첩되지만 않으면 일반적으로 문제가 없다 [ex”사용자 251의 직위 목록의 두 번째 항목”] 다대다 관계를 사용한다면 문서 모델은 매력이 떨어진다. 데이터 항목 상에 존재하는 관계 유형에 따라 애플리케이션 코드를 더 간단하게 만드는지 결정해야한다. 상호 연결이 많은 데이터의 경우 문서 모델은 곤란하지만 관계형 모델은 무난하며 그래프 모델은 매우 자연스럽다.

종종 문서 데이터베이스를 스키마리스로 불리지만 보통 구조의 유형을 어느 정도 가정한다. 즉 암묵적인 스키마가 있지만 강요하지는 않는다.

쓰기 스키마(schema -on-write) 모든 데이터가 스키마를 따르고 있음을 보장(관계형)

읽기 스키마 (schema-on-read) 데이터구조는 암묵적이고 읽을 때만 해석된다. 컬렉션 안의 항목이 모두 동일한 구조가 아닐 때 유리하다.

문서 데이터베이스와 관계형 데이터베이스의 통합

대부분의 관계형 데이터베이스는 XML을 지원한다. 지역적 수정과 XML 문서 내부에서 색인하고 질의하는 기능을 포함한다. 서로 부족한 부분을 보완해 나가고 있다.

데이터를 위한 질의 언어

SQL은 선언형 질의이다. 목표를 달성하기 위한 방법이 아니라 알고자 하는 데이터의 패턴, 즉 결과가 충족해야 하는 조건과 데이터를 어떻게 변환할지를 지정하기만 하면 된다. 데이터베이스에게 자동으로 최적화할 수 있는 여지를 더 많이 준다는 의미이다. 병렬 실행에 적합하다.

웹에서도 javascript(명령형)로 직접 style변경하는것보다 css(선언형)로 으로 지정하는 것이 더 간단하다.(마냥 좋다는 것은 아님)

맵리듀스 질의

선언형과 명령형의 그 중간정도에 있다. Map과 reduce함수를 정의하고, 추가적인 데이터베이스 질의를 수행할 수 없어야 하며 부수효과가 없어야 한다. 임의 순서로 어디서나 이 함수를 실행할 수 있고 장애가 발생해도 함수를 재실행할 수 있다.

그래프형 데이터모델

데이터에서 다대다 관계가 매우 일반적이라면 그래프로 데이터를 모델하기 시작하는 편이 더 자연스럽다.

정점(vertex)과 간선(edge)의 두개의 객체로 이루어진다. Ex)소셜 그래프, 웹 그래프, 도로나 철도 네트워크

각 정점은 “고유한 식별자, 유출 간선 집합, 유입 간선 집합, 속성 컬렉션(키-값 쌍)”로 구성된다. 각 간선은 “고유한 식별자, 간선 시작하는 정점, 간선이 끝나는 정점, 관계 유형을 설명, 속성 컬렉션”로 구성

그래프는 발전성이 좋아서 애플리케이션에 기능을 추가하는 경우 애플리케이션의 데이터 구조 변경을 수용하게끔 그래프를 쉽게 확장할 수 있다.

정리

데이터 모델은 광범위한 주제. 애플리케이션에 가장 적합한 모델을 찾아야한다. 데이터를 하나의 큰 트리로 표현하려고 노력했지만 다대다 관계를 표현하기에는 적절하지 않았다. 이 문제 때문에 관계형 모델이 고안됐고, 이것도 적절하지 않은 상황이 발생하여 NoSQL이 등장했다. -> 스키마를 강제하지 않아 변화하는 요구사항에 맞춰 애플리케이션을 쉽게 변경할 수 있다는 점. (명시적, 암시적 구분해야)

1. 문서 데이터베이스(다른 문서 간 관계가 거의 없는 사용 사례)

2. 그래프 데이터베이스(잠재적으로 모든 것이 잠재적으로 관련 있다는 대상)

각 모델은 각자의 영역에서 훌륭하다. 다른 모델로 흉내를 낼 수는 있지만 엉망이다. 단일 만능 솔루션이 아닌 각기 목적에 맞는 다양한 시스템을 보유해야 하는 이유다.

각 데이터 모델은 고유한 질의 언어, 프레임워크를 제공한다.