NoSQL Data Modeling
Data modeling for RDBMS has been a well-defined discipline for many years. Techniques like logical to physical mapping and normalization / de-normalization have been widely practiced by professionals, including novice users. However, with
Data modeling for RDBMS has been a well-defined discipline for many years. Techniques like logical to physical mapping and normalization / de-normalization have been widely practiced by professionals, including novice users. However, with the recent emergence of NoSQL databases, data modeling is facing new challenges to its relevance. Generally speaking, NoSQL practitioners focus on physical data model design rather than the traditional conceptual / logical data model process for the following reasons:
- Developer-centric mindset – With flexible schema (or schema-free) support in NoSQL databases, application developers typically assume data model design responsibility. They have been ingrained with the notion that the database schema is an integral part of application logic.
- High-performance queries running in massive scale-out distributed environments – Contrary to traditional, centralized scale-up systems (including the RDBMS tier), modern applications run in distributed, scale-out environments. To accomplish scale-out, application developers are driven to tackle scalability and performance first through focused physical data model design, thus abandoning the traditional conceptual, logical, and physical data model design process.
- Big and unstructured data – With its rigidly fixed schema and limited scale-out capability, the traditional RDBMS has long been criticized for its lack of support for big and unstructured data. By comparison, NoSQL databases were conceived from the beginning with the capability to store big and unstructured data using flexible schemas running in distributed scale-out environments.
In this blog post, we explore other important mindset changes in NoSQL data modeling: development agility through flexible schemas vs. database manageability; the business and data model design process; the role of RDBMS in NoSQL data modeling; NoSQL variations that affect data modeling; and visualization approaches for NoSQL logical and physical data modeling. We end the post with a peak into the NoSQL data modeling future.
Development agility vs. database manageability
One highly touted feature in today’s NoSQL is application development agility. Part of this agility is accomplished through flexible schemas, where developers have full control over how data is stored and organized in their NoSQL databases. Developers can create or modify database objects in application code on the fly without relying on DBA execution. The result is, indeed, increased application development and deployment agility.
However, the flexible schema is not without its challenges. For example, dynamically created database objects can cause unforeseen database management issues due to the lack of DBA oversight. Furthermore, unsupervised schema changes increase DBA challenges in diagnosing associated issues. Frequently, such troubleshooting requires the DBA to review application code written in programming languages (e.g., Java) rather than in RDBMS DDL (Data Definition Language) – a skill that most DBAs do not possess.
NoSQL business and data model design process
In old-school software engineering practice, sound business and (relational) data model designs are key to successful medium- to large-scale software projects. As NoSQL developers assume business / data model design ownership, another dilemma arises: data modeling tools. For example, traditional RDBMS logical and physical data models are governed and published by dedicated professionals using commercial tools, such as PowerDesigner or ER/Studio.
Given the nascent state of NoSQL technology, there isn’t a professional-quality data modeling tool for such tasks. It is not uncommon for stakeholders to review application source code in order to uncover data model information. This is a tall order for non-technical users such as business owners or product managers. Other approaches, like sampling actual data from production databases, can be equally laborious and tedious.
It is obvious that extensive investment in automation and tooling is required. To help alleviate this challenge, we recommend that NoSQL projects use the business and data model design process shown in the following diagram (illustrated with MongoDB’s document-centric model):
Figure 1
- Business Requirements & Domain Model: At the high level, one can continue using database-agnostic methodologies, such as domain-driven design, to capture and define business requirements
- Query Patterns & Application Object Model: After preliminary business requirements and the domain model are produced, one can work iteratively and in parallel to analyze top user access patterns and the application model, using UML class or object diagrams. With RDMS, applications can implement database access using either a declarative query (i.e., using a single SQL table join) or a navigational approach (i.e., walking individual tables embedded in application logic). The latter approach typically requires an object-relational mapping (ORM) layer to facilitate tedious plumbing work. By nature, almost all NoSQL databases belong to the latter category. MongoDB can support both approaches through the JSON Document model, SQL-subset query, and comprehensive secondary indexing capabilities.
- JSON Document Model & MongoDB Collection / Document: This part is where native physical data modeling takes place. One has to understand the specific NoSQL product’s strengths and weaknesses in order to produce efficient schema designs and serve effective, high-performance queries. For example, modeling social network entities like followed and followers is very different from modeling online blogging applications. As such, social networking applications are best implemented using Graph NoSQL databases like Neo4j, while online blogging applications can be implemented using other flavors of NoSQL like MongoDB.
RDBMS data modeling influence on NoSQL
Interestingly enough, old-school RDBMS data modeling techniques still play a meaningful role for those who are new to NoSQL technology. Using document-centric MongoDB as an example, the following diagram illustrates how one can map a relational data model to a comparable MongoDB document-centric data model:
Figure 2
NoSQL data model variation
In the relational world, logical data models are reasonably portable among different RDBMS products. In a physical data model, design specifications such as storage clauses or non-standard SQL extensions might vary from vendor to vendor. Various SQL standards, such as SQL-92 and the latest SQL:2008 as defined by industry bodies like ANSI/ISO, can help application portability across different database platforms.
However, in the NoSQL world, physical data models vary dramatically among different NoSQL databases; there is no industry standard comparable to SQL-92 for RDBMS. Therefore, it helps to understand key differences in the various NoSQL database models:
- Key-value stores – Collections comprised of unique keys having 1-n valid values
- Column families – Distributed data stores in which a column consists of a unique key, values for the key, and a timestamp differentiating current from stale values
- Document databases – Systems that store and manage documents and their metadata (type, title, author, creation/modification/deletion date, etc.)
- Graph databases – Systems that use graph theory to represent and store data as nodes (people, business, accounts, or other entities), node properties, and edges (lines connecting nodes/properties to each other)
The following diagram illustrates the comparison landscape based on model complexity and scalability:
Figure 3
It is worth mentioning that for NoSQL data models, a natural evolutionary path exists from simple key-value stores to the highly complicated graph databases, as shown in the following diagram:
Figure 4
NoSQL data model visualization
For conceptual data models, diagramming techniques such as the Entity Relationship Diagram can continue to be used to model NoSQL applications. However, logical and physical NoSQL data modeling requires new thinking, due to each NoSQL product assuming a different native structure. One can intuitively use any of the following three visualization approaches, using a document-centric data model like MongoDB as an example:
- Native visual representation of MongoDB collections with support for nested sub-documents (see Figure 2 above)
Pros – It naturally conveys a complex document model through an intuitive visual representation.
Cons – Without specialized tools support, visualization results in ad-hoc drawing using non-uniform conventions or notations.
- Reverse engineering selected sample documents using JSON Designer (see Figure 5 below)
Pros – It can easily reverse engineer a hierarchical model into a visual representation from existing JSON documents stored in NoSQL databases like MongoDB.
Cons – As of this writing, JSON Designer is available only on iPhone / iPad. Furthermore, it does not include native DB objects, such as MongoDB indexes.
Figure 5
- Traditional RDBMS data modeling tools like PowerDesigner (see Figure 6 below)
Pros – Commercial tools support is available.
Cons – it requires tedious manual preparation and diagram arrangement to represent complex and deeply nested document structure.
Figure 6
In a future post, we’ll cover specific data model visualization techniques for other NoSQL products such as Cassandra, which is based on the Column Family structure.
New NoSQL data modeling opportunities
Like any emerging technology, NoSQL will mature as it becomes mainstream. We envision the following new data modeling opportunities for NoSQL:
- Reusable data model design patterns (some product-specific and some agnostic) to help reduce application development effort and cost
- Unified NoSQL model repository to support different NoSQL products
- Bi-directional, round-trip engineering support for (data) model-driven design processes and tools
- Automated data model extraction from application source code
- Automated code-model-data consistency validation and consistency conformance metrics
- Strong control for application / data model change management, with proactive tracking and reconciliation between application code, embedded data models, and the actual data in the NoSQL databases
原文地址:NoSQL Data Modeling, 感谢原作者分享。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











インターネットの発展に伴い、ビッグデータ分析とリアルタイム情報処理が企業にとって重要なニーズとなっています。このようなニーズを満たすために、従来のリレーショナル データベースはビジネスやテクノロジー開発のニーズを満たせなくなりました。代わりに、NoSQL データベースを使用することが重要なオプションになっています。この記事では、最新のアプリケーションの開発と展開を可能にする、NoSQL データベースと統合された SpringBoot の使用について説明します。 NoSQL データベースとは何ですか? NoSQL は SQL だけではありません

最新の Web アプリケーション開発では、PHP および NoSQL データベースが非常に人気のあるテクノロジの選択肢となっています。これまで、PHP は動的な Web サイトや Web アプリケーションの開発に広く使用されてきましたが、NoSQL データベースは最近登場した新しいデータ ストレージ テクノロジであり、より柔軟でスケーラブルなソリューションを提供します。この記事では、実際のアプリケーションにおける PHP および NoSQL データベースについて説明します。 PHP はもともとサーバーサイドのプログラミング言語です。

多くの集中型取引所で問題が発生した後、ますます多くの仮想通貨投資家が集中型取引所によってもたらされるリスクを軽減するために資産をコールドウォレットに移し始めました。この記事では、2014 年に最初のコールド ウォレットが発売されて以来、世界各国で販売されている世界最古のコールド ウォレット プロバイダーである Trezor について紹介します。 Trezor の製品には、2014 年に発売された Model One と、2018 年に発売された上級バージョンの Model T があります。以下では引き続き、この2製品と他のコールドウォレットの違いについて紹介していきます。 Trezor コールドウォレットとは何ですか? 2014 年、Trezor は最初のコールド ウォレット ModelOne を発売しました。一般的な BTC、ETH、USDT、その他の通貨に加えて、ウォレットは 1,000 以上の他の通貨もサポートしています。

NoSQL (NotOnlySQL) データベースは、近年急速に発展しているデータベースの一種で、従来のリレーショナル データベースと比較して、拡張性とパフォーマンスが優れており、より多くのデータ型とデータ保存方法をサポートしています。その中でもMongoDBはドキュメントデータベースモデルを採用したNoSQLデータベースであり、Webアプリケーション、モバイルアプリケーション、IoTデバイスなどの分野で広く利用されています。この記事では、PHP を使用して MongoDB データベースの基本的な操作を作成する方法を紹介し、例を通じて次の条件を満たす方法を示します。

データ フォルダーには、ソフトウェア設定やインストール パッケージなどのシステム データとプログラム データが含まれています。データ フォルダー内の各フォルダーは、データ ファイルがファイル名データを参照しているか拡張子を参照しているかに関係なく、異なる種類のデータ ストレージ フォルダーを表します。 , これらはすべて、システムまたはプログラムによってカスタマイズされたデータ ファイルです。データは、データ ストレージのためのバックアップ ファイルです。通常、meidaplayer、メモ帳、または Word で開くことができます。

nosql と mysql の違いは次のとおりです: 1. MySQL はテーブル設計に基づくリレーショナル データベースですが、NoSQL は本質的に非リレーショナル ドキュメント ベースの設計です; 2. MySQL の厳格なスキーマ制限は拡張が容易ではありませんが、NoSQL は拡張できます。動的スキーマを通じて機能を簡単に拡張できます。

Django はオープン ソースの Python Web フレームワークであり、MVT (モデル-ビュー-テンプレート) アーキテクチャ パターンを採用し、アプリケーションをモデル、ビュー、テンプレートの 3 つの部分に分割します。その中で、Model は Django フレームワークの基本コンポーネントであり、データの定義と管理に使用されます。この記事では、Django フレームワークの Model について詳しく説明します。 Django のモデルとは

mysql ロード データの文字化けの解決策: 1. 文字化けしている SQL ステートメントを見つけます; 2. ステートメントを「LOAD DATA LOCAL INFILE "employee.txt" INTO TABLE EMPLOYEE Character set utf8;」に変更します。
