Student と School の 2 つの RelationalModels があります。学校には多くの生徒がいます。すべてのデータは Backbone.localStorage に保存されます

次のことをどのように行うべきかアドバイスが必要です。

• モデルごとに 1 つずつ、Student と School の 2 つのコレクションが必要だと思いますか?
• localStorage を使用してデータを保存する方法について混乱しています。各コレクションは独自の localStorage にデータを保存する必要がありますか?

わからないwtfの問題があります。私は説明する ：

Product という名前のモデルがあります:

私のフィールドuser_idは、1人のユーザー（バックボーンのモデルでもあります）の外部キーです：

私のフェッチ関係は、それぞれのモデルで完全に機能します。しかし、Product.user_idと User モデルの間にリレーションを配置すると、wtf エラーが発生します。

私は可能な限りすべてを試しました：すべてのキー（keySource、keyDestination..........可能なすべての値で）。何が起こったのかを監視できるように、Relation Lib にブレークポイントを設定しました ... 言うことはありません。StackOverflow でさえ、このバグを知りません :P (または、ひどく検索しました)

最終的な問題は次のとおりです。

• 私の製品は API によって正しく送信され、バックボーン (OK) に設定されます。
• フィールドuser_idは、最初に製品 API 応答によって数値に設定され、次にオブジェクト ユーザーに置き換えられるのではなく、リレーショナルによって NULL に設定されます (なぜ?)
• ネットワーク デバッガを見ると、Relational は User オブジェクトの API を呼び出します (ここで問題ありuser_idません)。サーバーの応答は良好で、JSON に適切なユーザーが含まれています (OK)。しかし、リレーショナルはこの応答オブジェクトを field にバインドしませんuser_id。これは現在 .... NULL (NOT OK) です。
  • そのため、 User オブジェクトが失われました (ただし、 autoFetch に成功関数を入れた場合は console.log() できます)、フィールドで親の Product に正しくリンクされていませんuser_id。

EDIT : JSFiddle はhttp://jsfiddle.net/gjdass/WNWrm/で利用できます(注意してください。API は応答に時間がかかる場合があります。約 10 秒です。これは正常です)。

よろしくお願いします :/ お時間をいただき申し訳ありません。

わかりました、私はSQLなどにまったく慣れていないので、これが完全に間違っている場合はお詫びします..

私は正しいと感じた ER モデルを設計しました。それをリレーショナル モデルに変換しようとしています。変換のどこが間違っているか、またはヒントについてアドバイスを求めています。私の頭を悩ませます。

私が信じているように..

1 対 1 の関係 エンティティが結合されるか、1 つのエンティティ タイプの主キーが他の関係の外部キーとして配置されます。

1-m 関係 「一側」の主キーは、多側に外部キーとして配置されます。

mn リレーションシップ 複合キーを形成する各エンティティのプライマリ キーを使用して、新しいリレーションが作成されます。

複数値属性 新しいテーブルが作成され、最初のテーブルから主キーが使用され、主キーに沿って 2 番目のテーブルで属性が使用されます。

では、リレーショナル モデルについて説明します。PK は太字、FK はイタリック体です。

ユーザー: ユーザー ID FNAME LNAMEユーザー名 パスワード ユーザータイプ Eメール

顧客: USERID、CUST_ID、BIO

管理者: ユーザー ID ADMIN_ID

アーティスト ユーザーID 、アーティスト_ID、バイオREC_ID

プロデューサー: PROD_ID、名前、電子メール

レコード ラベル: RECORD_ID、名前、説明

アルバム: ALBUMID NAME、COST、TITLE、NOOFSONGS

トラック: トラック ID、名前、コスト、タイトル、説明

TRACK REVIEW: TRACK に依存するので、TRACK ID はこのテーブルに入ります = REVIEW_ID(PK) , TRK_ID(PK) NAME

TRACK PURCHASE TABLE (USER id は外部キーとしてこのテーブルに入ります) TrackPuchaseID user_id , date

ALBUM PURCHASE TABLE AlbumPuchaseID user_id、日付、数量

ジャンル表?: わからない??

BPM: 複数の値の属性なので、別のテーブルになるので、それは GenreID BPMです。

私はこれがすべて間違っているかもしれないことを知っています。しかし、どんな助けも素晴らしいでしょう..FKまたは複合PKなどである必要がある説明、または欠落しているテーブル..

リレーショナル モデルとデータ モデリングを学んでいます。
そして、サブタイプに関して頭の中に混乱があります。

データ モデリングは反復プロセスであり、モデル化にはさまざまな方法があることを私は知っています。
しかし、さまざまなオプションから選択する方法がわかりません。

例

粒子(分子、原子、陽子、中性子、電子など)をモデル化するとします。
簡単にするために、クォークやその他の粒子は無視しましょう。

同じタイプの粒子はすべて同じように動作するため、個々の粒子をモデル化するつもりはありません。
別の言い方をすれば、すべての水素原子を保存するつもりはありません。
代わりに、水素、酸素、およびその他の原子タイプを保存します。
モデル化しようとしているのは、実際には粒子の種類とそれらの間の関係です。

「タイプ」という言葉をうっかり使っています。
水素原子はインスタンスです。水素はタイプです。水素も原子の一種です。
はい、関連する型の階層があります。そして、最低レベル (個々の粒子) を無視しています。

アプローチ

それらをモデル化するためのいくつかのアプローチを考えることができます。

1. モノのタイプ (粒子タイプ) ごとに 1 つのテーブル (関係、エンティティ)。

1.1 頭に浮かんだ最初のアプローチ。

陽子（陽子）
中性子（中性子）
電子（電子）

Atom (原子)
Atom_Proton (原子、陽子、数量)
Atom_Neutron (原子、中性子、数量)
Atom_Electron (原子、電子、数量)

Molecule (分子)
Molecule_Atom (分子、原子、量)

1.2 陽子/中性子/電子は 1 種類しかないので、簡略化できます。

Atom (原子、陽子量、中性子量、電子量)
Molecule (分子)
Molecule_Atom (分子、原子、量)

この単純化されたモデルでは、プロトンに関する事実は失われています。

2. すべてのものを 1 つのテーブルにまとめ、関連テーブルがそれらの間の関係を表します。

2.1 リレーションシップごとに 1 つの連想テーブル

粒子(粒子)

Atom_Proton (粒子、粒子、陽子量)
Atom_Neutron (粒子、粒子、中性子量)
Atom_Electron (粒子、粒子、電子量)
Molecule_Atom (粒子、粒子、原子量)

2.2 単一連想テーブル

Particle (粒子)
ParticleComposition (粒子、粒子、量)

この単純化によって何も失われることはありません。私はそれが良いと思います。しかし、 Atom_Proton / Atom_Neutron / Atom_Electron
に固有の事実がある場合は、2.1 の方が優れている可能性があります。

2.3 2.1 と 2.2 を組み合わせる

粒子(粒子)

Atom_Proton (粒子、粒子、その他の属性)
Atom_Neutron (粒子、粒子、その他の属性)
Atom_Electron (粒子、粒子、その他の属性) Molecule_Atom (粒子、粒子、その他の属性)

ParticleComposition (粒子、粒子、量、その他の属性)

このアプローチでは、粒子組成に関する一般的な属性はParticleCompositionに入り、
粒子組成に関する特別な属性は特別なテーブルに入ります。

3. サブタイプ テーブルを使用します。

3.1 基本タイプParticleの表と、サブタイプ ( Atom、Moleculeなど) の追加表。

粒子(粒子)

Proton (粒子、その他の属性)
Neutron (粒子、その他の属性)
Electron (粒子、その他の属性)
Atom (粒子、その他の属性)
Molecule (粒子、その他の属性)

Atom_Proton (粒子、粒子、陽子量)
Atom_Neutron (粒子、粒子、中性子量)
Atom_Electron (粒子、粒子、電子量)
Molecule_Atom (粒子、粒子、原子量)

3.2 Atom のAtom_XXXQuantityテーブルを組み合わせて、 Pronton / Neutron / Electronを削除することもできます。

粒子(粒子)

原子(粒子、陽子量、中性子量、電子量)
分子(粒子、その他の属性)

Molecule_Atom (粒子、粒子、原子量)

より単純ですが、1.2 のように陽子/中性子/電子に関する情報が失われます。

3.3 Molecule_Atomの名前をより一般的なものに変更できます。

粒子(粒子)

原子(粒子、陽子量、中性子量、電子量)
分子(粒子、その他の属性)

ParticleComposition (粒子、粒子、数量)

これは 2.2 のように見えますが、サブタイプ ( Atom、Molecule ) のテーブルが追加されています。
2.2 は 3.3 の特殊なケースのようです。

3.4 上記のすべてのアプローチを組み合わせて、一般的なモデルを取得できます。

粒子(粒子)

Proton (粒子、その他の属性)
Neutron (粒子、その他の属性)
Electron (粒子、その他の属性)
Atom (粒子、その他の属性)
Molecule (粒子、その他の属性)

ParticleComposition (粒子、粒子、量、その他の属性)

Atom_Proton (粒子、粒子、その他の属性)
Atom_Neutron (粒子、粒子、その他の属性)
Atom_Electron (粒子、粒子、その他の属性)
Molecule_Atom (粒子、粒子、その他の属性)

Atom_Proton 、Atom_Neutron、Atom_Electron、Molecule_AtomはParticleCompositionのサブタイプと考えることができるようです。

このアプローチは最も複雑なもので、多くのテーブルが含まれていますが、各テーブルにはそれぞれの役割があります。

質問

1. 上記の設計のいずれかがリレーショナル モデルのルールを破っていますか?
2. どのアプローチが最適ですか? それは、データに対する考え方に依存しますか? それは要件に依存しますか？

3. 要件に依存する場合は、最初に最も単純な設計を選択し、新しい要件に対応するためにそれをより一般的なものにしますか?
   結果として得られるデータ モデルには多くの類似点がありますが、最初の設計がテーブル/列の命名に影響する可能性があり、キーのドメインが異なります。

   • 物事の種類ごとに 1 つのテーブルを使用することを選択した場合、Atom の原子量と Molecule の分子名など、Atom と Molecule に互換性のないキーを選択する可能性があります。
   • 一般的なアプローチを使用する場合は、すべてのパーティクルに共通のキーを選択できます。
     キーを変更すると、システムへの影響が大きくなる可能性があるため、単純な設計から一般的な設計に進化させるのは容易ではない可能性があります。
     どう思いますか？

PS:これは適切な例ではない可能性があり、解決策には問題がある可能性があり、アプローチにはさらにバリエーションがある可能性がありますが、うまくいけば要点を理解できます。
より良いデザインがあれば、私と共有してください。

---

更新 1

モデル化するデータは何ですか?

最初は、粒子をモデル化しようとしていました。

• それらの間にサブタイピング関係があると思います。これはまさに私が探しているものです。
• 彼らは人々によく理解されています（？）。
• これは、人々が世界をどのように理解しているかを示す良い例です。

ここに私の心の絵があります。

私が何をモデル化しようとしているのかについてもあまり明確ではなかったので、私はこれを明確に述べませんでした.
最初に、Atom は Proton/Neutron/Electron の親であり、Molecule は Atom の親であると考えました。次に、これはコンポジションに関するものであり、サブタイピングに関するものではなく、 Type Hierarchy
に関するものではないことに気付きました。

種類

しばらくの間、タイプ、およびグループ化と分類について考えてきました。

以下は " SQL and Relational Theory "からの引用です:

では、タイプとは正確には何ですか？本質的に、これは名前付きの有限の値のセットです─ 特定の種類の可能なすべての値: たとえば、可能なすべての整数、可能なすべての文字列、可能なすべてのサプライヤー番号、すべての可能な XML ドキュメント、または可能なすべての関係特定の見出し (など)。

整数値のセットを表すために「整数」という名前が付けられました。
実際、人々は物事を識別するために概念と名前を作り出し、世界を理解/モデル化できるように物事をグループ化しました。

陽子は実際の陽子の集合、水素は水素原子の集合などです。
この意味で、実際のパーティクルは型階層の最下位レベルにとどまります。
最初はすべての粒子をモデル化しようとしていましたが、行き詰まってしまいました。

• それぞれの実際の粒子を識別するための適切なキーを思いつきませんでした。
• それらが多すぎてデータベースに保存できません。

そこで、実際の粒子を無視して、代わりに型をモデル化することにしました。

「分子は原子で構成されている」と言うとき、それは「実際の H2O 分子は 2 つの実際の水素原子と 1 つの酸素原子で構成されている」ことを意味し、「任意の (タイプの) 分子が (いくつかのタイプの) で構成されている」ことも意味します。アトム」。

実際の粒子に関するすべての事実を述べる代わりに、粒子の種類に関する事実を述べることができます。
それが、モノや造語（タイプ）をグループ化することで得られるメリットです。

セットとしての粒子タイプ階層

階層はセット定義に変換できます。

第 2 レベル - 実際の粒子の上のタイプ:

より高いレベル

集合論の用語を使用すると、A が B のサブセットである場合、タイプ A は B のサブタイプです。

Atom 型を次のように定義できると最初に考えました。

ただし、セットはリレーションで要素はタプルであるため、リレーション内のタプルに互換性がない場合、結合は機能しません。

サブタイプ テーブルを使用するアプローチは、問題を解決し、サブセットの関係をモデル化します。

しかし、サブタイピング アプローチでは、Atom はまだ2 番目のレベルにあります。

より高いレベルのタイプは、セットのセットとして定義されます。

つまり、粒子は原子のタイプであり、原子は水素のタイプです。

このようにして、粒子間の関係を高いレベルで表現できます。

新しいデータモデル

4. 型を型の階層として扱う

ParticleType (ParticleType, Name)
ParticleTypeHierarchy (ParticleType, ParentType)
ParticleComposition (PartileType, SubParticleType, Quantity)

サンプルデータ：

比較のために、これはサブタイプ テーブル アプローチのサンプル データです。

サブアトム

これらの粒子タイプは人々によって定義され、人々は現実の新しい側面をモデル化するために新しい概念を定義し続けています。
「サブアトム」を定義すると、階層は次のようになります。

アプローチ 4 は、この型階層の変更により簡単に対応できます。

---

更新 2

記録する事実

1. 世界には、陽子、中性子、電子、原子、分子など、さまざまな種類の粒子があります。
2. 原子は、陽子、中性子、および電子で構成されています。
3. 分子は原子で構成されています。
4. 原子には、水素、酸素など、さまざまな種類があります。
5. 分子には、H2O、O2 など、さまざまな種類があります。
6. 水素原子は、1 つの陽子と 1 つの電子で構成されています。...
7. H2O 分子は、2 つの水素原子と 1 つの酸素原子で構成されています。...
8. 異なるタイプの粒子には特別な特性があります。たとえば、原子には原子の重さがあります。
9. ...

次の ER 図から ERM へのマッピングが正しい理由、またはより正確には完全な理由を理解するのに問題があります。この例では、プロジェクト、場所、人物の間に 1:1:N の三項関係があります。

各エンティティには主キー (ProjectID、PlaceID、PersonID) があります。この図を理解すれば、個人とプロジェクトの組み合わせを複数の場所に関連付けることはできません。さらに、人と場所の組み合わせは、1 つのプロジェクトにのみ関連付けることができます。さらに、特定の場所でのプロジェクトには複数の人がいる可能性があります。

三項関係をどのように読み取るかについてのこの理解は、私の問題につながります。ERM を次の RM にマッピングします。

テーブルWorksには、 (Place, PersonID) と (ProjectID, PersonID)の 2 つの候補キーがあります。最初のものを主キーとして選択しましょう。次に、正しいRMが必要です（文献によると）が、個人とプロジェクトの同じ組み合わせが異なる場所に関連付けられていないことを確認する方法がわかりませんか？(ProjectID, PersonID) も候補キーであるとどこかで言う必要はありませんか、それとも RM 表記の一部ではありませんか?