'데이터 모델링 방법' 시리즈의 2부에서는 "다른 데이터 모델링 방법에는 어떤 것이 있나요?"라는 질문에 답합니다. 데이터 모델 유형" 다양한 논리적 모델, 데이터 모델 예시, 장단점, 장단점에 대해 설명합니다.
이 시리즈의 1부에서는 데이터 모델링의 3단계에 대해 설명했습니다: 개념적, 논리적, 물리적.
6가지 표준 데이터 모델 유형, 예제 및 용도
개념 모델을 정의했다면 다음 단계는 논리적 데이터 모델 구축을 시작하는 것입니다. 아직 특정 기술이나 공급업체를 선택하기에는 너무 이른 단계입니다.
그리고 논리적 데이터 모델 관계형, JSON(문서), 키-값, 그래프, 와이드 컬럼, 텍스트 검색 등이 가장 일반적이고 인기 있는 것으로 나타났습니다.
관계형 데이터 모델
관계형 데이터 모델은 1970년 E.F. 코드가 제안했습니다.. 일반적으로 관계형 데이터 모델은 미리 정의된 스키마와 제약 조건을 따르는 데이터를 포함하는 행과 열이 포함된 테이블로 구성됩니다.
"관계형"이라는 용어는 not 는 테이블과 엔티티 간의 관계를 지칭하는 것이 아니라 데이터 도메인의 구성원이며 각각 속성을 포함하는 튜플 집합이라는 이론적 개념입니다.
실제 관계는 관계형 모델(또는 나중에 설명하는 그래프를 제외한 다른 모델)의 일부가 아니지만 일반적으로 여러 테이블과 외래 키 제약 조건으로 구현됩니다.
관계형은 전 세계에서 가장 널리 사용되는 논리적 데이터 모델 유형입니다.
SQL은 원래 관계형 제안의 일부가 아니었지만, 관계형 데이터베이스와 밀접하게(배타적이지는 않지만) 연관되어 있습니다. 실제로 SQL은 일반적으로 관계형 데이터베이스의 데이터와 상호 작용할 수 있는 유일한 방법입니다.
JSON 데이터 모델
대부분의 문서 데이터베이스는 데이터를 다음과 같이 저장합니다. JSON (XML 및 기타 표현은 훨씬 덜 인기가 있습니다).
확장성이 뛰어난 NoSQL 구현은 클러스터링 및 샤딩을 통해 여러 서버에 분산할 수 있는 독립적인 데이터를 선호하여 관계형 제약을 피합니다. JSON은 이러한 종류의 분산 데이터에 널리 사용되는 형식입니다:
-
- 복잡한 구조와 '읽기 스키마'를 제공할 수 있습니다.
- 사람이 읽을 수 있습니다.
- JSON용 (탈)직렬화기는 다음과 같습니다. 거의 모든 프로그래밍 언어와 플랫폼.
- 다음을 지원할 수 있습니다. SQL++는 JSON 데이터 모델용 SQL의 이전 버전과 호환되는 구현입니다.
관계형 배경을 가지고 있지만 확장성, 유연성, 성능, 친숙함 등 'NoSQL'의 이점을 탐색하고 싶다면 JSON 문서 모델이 좋은 출발점이 될 수 있습니다.
문서 데이터베이스의 데이터 액세스 방법에는 일반적으로 개별 JSON 값을 기반으로 필터링할 수 있는 쿼리 언어(SQL++와 같은 표준 또는 MQL과 같은 독점 공급업체 구현)가 포함됩니다(이에 국한되지 않음).
키-값 데이터 모델
키-값 데이터 모델은 각 데이터를 키와 연결합니다. 실제 값은 모든 형식이 될 수 있습니다. JSON, XML, 바이너리, 텍스트 등 모든 형식이 가능합니다.
이러한 유형의 데이터베이스 모델은 캐싱, 세션 스토리지, 사용자 프로필, 장바구니와 같은 특정 사용 사례를 예로 들 수 있습니다.
키-값 읽기 및 쓰기 외에도 "하위 문서" 및 "지도/축소'는 더 많은 데이터 액세스 옵션을 추가하지만, 관계가 복잡한 데이터에 순수한 키-값 논리 모델을 사용하는 것은 매우 어려울 수 있습니다.
그래프 데이터 모델
그래프 데이터 모델은 데이터와 관계의 개념이 모두 내장된 유일한 모델입니다. 그래프 모델에서 데이터 조각을 '노드'라고 하고, 두 노드 간의 관계를 '에지'라고 합니다.
그래프 데이터 모델은 복잡한 관계 시스템을 모델링하는 데 유용할 수 있습니다. 예를 들어, 물리적 컴퓨터 네트워크와 네트워크에 있는 컴퓨터를 모델링하는 것이 그 예입니다. 사기 탐지 및 쇼핑 추천과 같은 특수한 사용 사례에 자주 사용됩니다.
쿼리의 경우 그래프 데이터베이스는 Gremlin 또는 Cypher와 같은 특수 그래프 쿼리 언어를 사용합니다.
참고: GraphQL과 그래프 데이터 모델은 서로 관련이 없습니다.
넓은 열 데이터 모델
넓은 열 데이터 모델에는 관계형 테이블과 유사한 테이블('키 패밀리'라고도 함)이 있지만 행 기반이 아닌 열 기반입니다.
즉, 주어진 행은 다른 행과 다른 임의의 열을 가질 수 있습니다. 또한 기존 행에 열을 계속 추가할 수 있습니다.
각 행에는 키가 있으므로 이 모델을 키 값 저장소의 2차원적 진화라고 생각할 수도 있습니다.
넓은 열 데이터 모델을 위한 쿼리 언어는 데이터베이스별로 다릅니다. 널리 사용되는 예로는 CQL(Cassandra 쿼리 언어)이 있는데, 이는 SQL과 비슷해 보이지만 매우 제한적인 하위 집합입니다.
텍스트 검색 데이터 모델
텍스트 검색 데이터 모델은 텍스트 저장 및 검색에 최적화되어 있습니다. 여기에는 패싯과 퍼지가 포함되지만 지리적 검색도 포함될 수 있습니다.
인덱스 생성은 텍스트 검색과 상호 작용하는 데 있어 핵심적인 부분입니다. 검색은 활성 인덱스에 매개변수를 제공하며, 종종 REST 요청이나 특수 SDK를 통해 수행됩니다. 쿼리 유형 문자열, 일치, 구문, 복합어, 범위, 지리적 공간 등이 사용될 수 있습니다.
데이터 모델 및 이를 지원하는 데이터베이스의 예
다중 모델 데이터베이스는 동일한 데이터 풀로 위에 나열된 여러 유형의 데이터 모델을 지원할 수 있는 데이터베이스를 말합니다. 즉, 다음과 같은 몇 가지 예가 있습니다. 물리적 데이터 모델링 각 모델에 대한 구현 도구(데이터베이스)가 포함된 예제입니다:
-
- 관계형: SQL Server, Oracle, MySQL, MariaDB, PostgreSQL, SQLite, Microsoft Access, Snowflake.
- JSON 문서: 카우치베이스, 코스모스DB*, 다이너모DB, 카우치DB(비슷한 이름이지만 카우치베이스와는 다른 별개의 제품), 몽고DB.
- 키-값: 거의 없습니다. pure 키-값 데이터베이스는 아니지만 키-값을 잘 지원하는 예시입니다: Memcached, Redis, Couchbase.
- 그래프: Neo4j, 코스모스DB*, 아랑고DB.
- 넓은 열: 카산드라, HBase, 코스모스DB*.
- 텍스트/검색: Elasticsearch 및 Solr(Lucene), Couchbase(Bleve)
*코스모스DB를 사용할 때는 반드시 하나의 데이터 모델을 미리 선택해야 합니다.
데이터 모델링 도구
데이터 모델링에는 도구가 필요하지 않으며, 드라이 지우기 보드나 연필과 종이로 할 수 있습니다(물론 물리적 데이터 모델링은 예외입니다). 하지만 팀의 작업을 더 쉽게 만들어 주는 데이터 모델링 도구가 많이 있습니다. 다음은 몇 가지 인기 있는 도구입니다:
JetBrains DataGrip 는 데이터베이스 다이어그램 도구 를 사용하여 기존 데이터베이스에서 모델을 구성할 수 있습니다. 이러한 다이어그램은 UML 또는 PNG로 저장할 수 있습니다. 다음과 같은 경우에 유용합니다. 물리적 데이터 모델링.
Erwin 데이터 모델러 는 개념적, 논리적, 물리적 데이터 모델을 지원하는 매우 인기 있는 도구입니다. Erwin의 제작사인 Quest는 Couchbase와 파트너십을 체결하여 모델링 및 마이그레이션 사용 사례.
해코레이드 은 다양한 데이터 모델(이 게시물에서 언급한 모든 물리적 모델 포함)을 지원하는 또 다른 데이터 모델링 도구입니다. 데이터 모델 마이그레이션.
Idera 에는 모델링을 위한 모든 도구가 포함되어 있습니다. 예를 들어, ER/스튜디오 비즈니스 아키텍트는 개념적 모델링을 제공하고, ER/스튜디오 데이터 아키텍트는 논리적 및 물리적 모델링을 제공합니다.
이러한 도구가 시작하기에 과한 것 같다면 다음과 같은 보다 범용적인 다이어그램 도구를 사용할 수 있다는 점을 기억하세요. Diagrams.net 를 사용하여 팀이 협업할 수 있도록 하세요.
다음 단계 및 리소스
개념적, 논리적, 물리적 모델링이 모두 소개되었습니다. 이전 게시물. 이 포스트에서 자세히 살펴본 논리적 데이터 모델 선택. 데이터 모델 선택 다음 (이 시리즈의 마지막 게시물에서는 물리적 JSON 데이터 모델링에 대해 구체적으로 살펴봅니다.
그동안 자세한 내용은 다음 리소스를 참조하세요:
