私はデータベース設計が初めてです。私が学んだように、エンティティリレーションシップダイアグラムを使用してリレーショナルデータベースを設計します。リレーショナルデータベースに対する正式な設計アプローチがエンティティ - リレーションシップダイアグラムである場合、NOSQLデータベースのアプローチはどのようなものですか？
リレーショナルデータベースへの正式な設計アプローチがERDの場合、NOSQLデータベースのアプローチは何ですか？
エンティティリレーションシップダイアグラムをよく使うと思います。あなたのDBがRDBMSのようにあなたのデータエンティティ間の関係を処理していないからといって、あなたのデータに関係がないことを意味するわけではなく、（Rではない） DBMS。私はあなたのDBの各エントリに格納しようとしている情報を理解することはまだ価値があると思います。
さらに調整したい場合は、問題は"NoSQL" is an umbrella term for a lot of different DB architecturesです。最良の設計手法を決定する前に、使用すると思われるNoSQLデータベースの種類を判断する必要があります。しかし、たとえあなたが使用しているDBが古典的なSQL DB（例えば、キー/値ペアの可変セット）よりも柔軟性を持っていても、あなたのエンティティが持つ属性を理解したいと思っていると思います。
実際、多くのリレーショナルNoSQLデータベースがあります。例えば、グラフデータベースは、関係を保存することしかできません。 –
Jörg、グラフデータベースはリレーショナルデータベースではありません。彼らは非常に異なるものです。グラフデータベースは一般的には関係をサポートしていませんが、リレーショナルデータベースではデータアイテム間のナビゲーションやリンクが許可されていません。実際、グラフモデルはリレーショナルモデルより一般的ではありません。 – sqlvogel
@dportas：辺が頂点間の関係でない場合、それは* * *ですか？ –
キーバリューストアでハッシュマップを使用するには、グラフdbsにグラフを使用します...これらのモデルはかなり単純であるべきですが、それらがモデルと同じくらい有用かどうかは疑問です。
グラフデータベースの場合、エンティティリレーションシップモデル（またはそのオブジェクト指向のいとこ、クラスアソシエーションモデル）は非常に良い一致です。このモデルをネイティブに実行すると、グラフデータベースは非常に良いと思います。
他のすべての種類のデータベース（リレーショナルインクルード）は、モデルをデータベースにマッピングするために開発者に「余分なものを」必要とします。例えば。 SQLデータベースの場合、余分なものは比較的少ない（例えば、N-N関係を余分なテーブルにマッピングし、継承の回避策）。反対に、ハッシュテーブルの余分なものはかなり大きいです（プロパティのシリアライズ、リレーションシップの手動管理など）。
もちろん、異なるグラフデータベースは接続がどのくらいシームレスであるかによって異なります。私はInfoGridと呼ばれるグラフデータベースに関わっています。高レベルモデルからコードへのステップは、コードジェネレータを介して自動的に行われます。
エンティティリレーションシップダイアグラムは、リレーショナルデータベースの設計に使用できる1つのツールです。彼らは唯一の方法ではなく、必ずしも最高のものでもありません。 ERモデリングとER図のずっと前に、リレーショナルデータベースが発明されました。 – sqlvogel