我有两个关系模型，学生和学校。学校有很多学生。所有数据都将存储在 Backbone.localStorage

我需要建议如何执行以下操作：

• 我想我需要两个系列，每个模型一个，学生和学校？
• 我对如何使用 localStorage 存储数据感到困惑。每个集合是否应该将数据存储在自己的 localStorage 中？

我有一个像这样构建的简单关系模型： Parent ：

第一个孩子画廊

第二个孩子的形象

所以基本上没什么大不了的：一个公寓有一个画廊，一个画廊有很多图像。它工作得很好，问题是当我删除一个公寓时，我想删除与该公寓关联的画廊和图像。

所以我试图覆盖删除方法。公寓被删除，还有画廊，但是图片没有被删除，而且似乎无法使用画廊的删除功能，因为我试图添加一个模具；在函数中，但它永远不会死。

有谁知道我怎么能克服这个？谢谢

我有一个我无法弄清楚的wtf问题。我解释 ：

我有一个名为 Product 的模型：

我的字段user_id是一个用户的外键（也是主干中的模型）：

我的 fetch 关系在每个单独的模型中都能完美运行。但是当我在和我的用户模型之间建立关系时Product.user_id，会发生 wtf 错误。

我已经尝试了所有可能的方法：所有的键（keySource, keyDestination...... ，所有可能的值）。我什至在 Relation Lib 中设置了断点，以便能够看到发生了什么……没什么好说的。甚至 StackOverflow 都不知道这个错误：P（或者我搜索得很糟糕）

最后的问题是：

• 我的产品由 API 正确发送并在 Backbone (OK) 中设置。
• 该字段user_id首先由 Product API 响应设置为一个数字，然后由 Relational 设置为 NULL 而不是由对象 User 替换（为什么？）
• user_id当我查看我的网络调试器时，Relational 使用数字 (OK)调用 User 对象的 API（这里没问题）。服务器响应良好，JSON 中的正确用户（OK）。但是 Relational 不会将此响应对象与 field 绑定，该字段user_id现在是 .... NULL (NOT OK)。
  • 所以我丢失了一个 User 对象（但如果我在我的 autoFetch 中放置一个成功函数，我可以 console.log() 它），没有正确链接到他的父 Product 与 field user_id。

编辑：这里有一个 JSFiddle http://jsfiddle.net/gjdass/WNWrm/（注意，API 响应时间可能很长，大约 10 秒，这是正常的）。

在此先感谢：/ 抱歉，您为此花费了这么多时间。

当我问一个关于 EER 模型的问题时，当有人谈到关系模型时，我感到很困惑。我已经了解了 ER 和 EER 图之间的区别，但我想了解整个建模过程……我知道 EER 是增强的 ER 模型，即具有专业化/泛化的 ER 模型。

当有人说 ER 建模时，他是否也暗示了 EER 建模？

那么数据库规范化呢？这仅适用于关系图吗？

我刚刚开始学习数据建模，希望您对我设计逻辑模型和物理模型的方式有看法。

问题。
1) 一个人可以拥有多个地块。
2) 一个地块可以为多人所有
3) 一个人可以拥有不同类型的地块所有权

土地图式

人物模式

所有权类型架构（单一/联合）

Person_Land_Ownership 模式

请就上述建模方法提供意见/批评/建议。

好的，我对 SQL 等是全新的，如果这完全错误，我深表歉意..

我设计了一个我认为正确的 ER 模型，我正在尝试将其转换为关系模型，并希望得到任何关于我在转换它时出错的地方或任何提示的建议。绞尽脑汁。

正如我所相信的那样。。

1-1 关系 实体要么组合在一起，要么将一种实体类型的主键作为外键放置在另一种关系中。

1-m 关系 来自“一侧”的主键作为外键放置在多侧。

mn 关系 使用来自每个实体的主键创建一个新关系，形成一个复合键。

多值属性 创建一个新表，主键使用第一个表，第二个表中使用的属性与主键相同。

所以这是我对关系模型的尝试，PK 为粗体，FK 为斜体

用户：用户 ID FNAME LNAME 用户名密码用户类型电子邮件

客户： USERID，CUST_ID， BIO

管理员： 用户ID ADMIN_ID

艺术家 USERID，ARTIST_ID， BIO REC_ID

生产者： PROD_ID，姓名，电子邮件

记录标签： RECORD_ID、名称、描述

专辑： 专辑名称、成本、标题、NOOFSONGS

轨道： 轨道 ID、名称、成本、标题、描述

TRACK REVIEW：取决于 TRACK SO TRACK ID 进入此表 = REVIEW_ID(PK) , TRK_ID(PK) NAME

TRACK PURCHASE TABLE（用户 id 作为外键进入该表） TrackPuchaseID user_id , date

ALBUM PURCHASE TABLE AlbumPuchaseID user_id，日期，数量

流派表？：不确定？？

BPM：是多值属性，所以成为单独的表，所以 它.s GenreID BPM

我知道这一切可能都是错的。但是任何帮助都会很棒..解释应该是FK或复合PK等或我缺少哪些表格..

我正在学习关系模型和数据建模。
我对子类型有些困惑。

我知道数据建模是一个迭代过程，并且有许多不同的方法来建模事物。
但我不知道如何在不同的选项之间进行选择。

例子

假设我们要对粒子（分子、原子、质子、中子、电子……）进行建模。
为简单起见，让我们忽略夸克和其他粒子。

由于相同类型的所有粒子行为相同，我们不打算对单个粒子进行建模。
换句话说，我们不会存储每个氢原子。
相反，我们将存储氢、氧和其他原子类型。
我们要建模的实际上是粒子类型和它们之间的关系。

我不小心使用了“类型”这个词。
氢原子就是一个例子。氢是一种类型。氢也是一种原子。
是的，涉及类型的层次结构。我们忽略了最低级别（单个粒子）。

方法

我可以想出几种方法来为它们建模。

1. 每一类事物（粒子类型）一个表（关系、实体）。

1.1 我想到的第一种方法。

质子(Proton)
中子(Neutron)
电子(Electron)

Atom (原子)
Atom_Proton (原子、质子、数量)
Atom_Neutron (原子、中子、数量)
Atom_Electron (原子、电子、数量)

分子（Molecule）
Molecule_Atom（分子，原子，数量）

1.2 由于质子/中子/电子只有一种，我们可以简化一下。

Atom (Atom, ProtonQuantity, NeutronQuantity, ElectronQuantity)
分子(Molecule)
Molecule_Atom (Molecule, Atom, Quantity)

在这个简化的模型中，关于Proton的事实丢失了。

2. 所有事物都在一张表中，关联表表示它们之间的关系。

2.1 每个关系一个关联表

粒子（粒子）

Atom_Proton (Particle, Particle, ProtonQuantity)
Atom_Neutron (Particle, Particle, NeutronQuantity)
Atom_Electron (Particle, Particle, ElectronQuantity)
Molecule_Atom (Particle, Particle, AtomQuantity)

2.2 单关联表

粒子（Particle）
ParticleComposition（粒子、粒子、数量）

这种简化不会丢失任何东西。我认为这更好。
但如果有特定于Atom_Proton / Atom_Neutron / Atom_Electron的事实，2.1 可能会更好。

2.3 结合2.1和2.2

粒子（粒子）

Atom_Proton (Particle, Particle, 其他属性)
Atom_Neutron (Particle, Particle, 其他属性)
Atom_Electron (Particle, Particle, 其他属性) Molecule_Atom (Particle, Particle, 其他属性)

ParticleComposition（粒子、粒子、数量、其他属性）

在这种方法中，关于粒子组成的公共属性放在ParticleComposition中，
而关于粒子组成的特殊属性放在特殊的表中。

3. 使用子类型表。

3.1 基本类型Particle的表，以及子类型（Atom，Molecule，...）的附加表。

粒子（粒子）

质子（粒子，其他属性）
中子（粒子，其他属性）
电子（粒子，其他属性）
原子（粒子，其他属性）
分子（粒子，其他属性）

Atom_Proton (Particle, Particle, ProtonQuantity)
Atom_Neutron (Particle, Particle, NeutronQuantity)
Atom_Electron (Particle, Particle, ElectronQuantity)
Molecule_Atom (Particle, Particle, AtomQuantity)

3.2 我们也可以将 Atom 中的Atom_XXXQuantity表合并，去掉Pronton / Neutron / Electron。

粒子（粒子）

原子（粒子、质子数量、中子数量、电子数量）
分子（粒子、其他属性）

Molecule_Atom (Particle, Particle, AtomQuantity)

它更简单，但有关质子/中子/电子的信息在 1.2 中丢失了。

3.3 我们可以更改Molecule_Atom的名称，使其更通用。

粒子（粒子）

原子（粒子、质子数量、中子数量、电子数量）
分子（粒子、其他属性）

ParticleComposition（粒子、粒子、数量）

这看起来像 2.2，带有子类型（ Atom，Molecule）的附加表。
看来 2.2 是 3.3 的特例。

3.4 我们可以结合以上所有方法，得到一个通用模型。

粒子（粒子）

质子（粒子，其他属性）
中子（粒子，其他属性）
电子（粒子，其他属性）
原子（粒子，其他属性）
分子（粒子，其他属性）

ParticleComposition（粒子、粒子、数量、其他属性）

Atom_Proton (Particle, Particle, 其他属性)
Atom_Neutron (Particle, Particle, 其他属性)
Atom_Electron (Particle, Particle, 其他属性)
Molecule_Atom (Particle, Particle, 其他属性)

似乎Atom_Proton、Atom_Neutron、Atom_Electron和Molecule_Atom可以被认为是ParticleComposition的子类型。

这种方法是最复杂的一种，它包含许多表，但每个表都有其作用。

问题

1. 以上任何设计是否违反了关系模型的规则？
2. 哪种方法最好？这是否取决于我们如何看待数据？这取决于要求吗？

3. 如果取决于需求，我们是否应该先选择最简单的设计，然后再使其更通用以适应新的需求？
   虽然生成的数据模型有很多相似之处，但最初的设计可能会影响表/列的命名，并且键的域不同。

   • 如果我们选择为每种类型的事物使用一个表，我们可以为 Atom 和 Molecule 选择不兼容的键，例如Atom的原子重量和Molecule的分子名称。
   • 如果我们选择使用通用方法，我们可以为所有粒子选择一个公共密钥。
     更改密钥可能会对系统产生更大的影响，因此从简单的设计发展到通用的设计可能并不容易。
     你怎么看？

PS：这可能不是一个合适的例子，解决方案可能有问题，并且方法可能有更多变体，但您希望能明白这一点。
如果你有更好的设计，请与我分享。

---

更新 1

要建模的数据是什么？

最初，我试图对粒子进行建模，因为

• 我认为它们之间存在子类型关系，这正是我正在寻找的。
• 他们很容易被人们理解（？）。
• 这是人们如何理解世界的一个很好的例子。

这是我脑海中的画面。

我没有明确说明这一点，因为我也不太清楚我要建模的内容。
首先，我认为 Atom 是 Proton/Neutron/Electron 的父母，而 Molecule 是 Atom 的父母。
然后我意识到这是关于组合，而不是子类型，而不是类型层次结构。

类型

我一直在思考类型，以及分组和分类。

以下是“ SQL 与关系理论”中的一段话：

那么，究竟什么是类型？本质上，它是一组命名的、有限的值——某种特定类型的所有可能值：例如，所有可能的整数，或所有可能的字符串，或所有可能的供应商编号，或所有可能的 XML 文档，或所有可能的关系某个标题（等等）。

人们创造了“整数”这个名称来表示整数值的集合。
实际上，人们创造了概念和名称来识别事物，对事物进行分组，以便我们可以理解/模拟世界。

质子是一组真正的质子，氢是一组氢原子，依此类推。
从这个意义上说，真正的粒子处于类型层次结构的最低级别。
起初我试图对所有粒子进行建模，但后来我被卡住了，因为

• 我想不出一个合适的键来识别每个真实的粒子。
• 它们太多了，无法存储在数据库中。

所以我决定忽略真实的粒子，而是对类型进行建模。

当我们说“分子由原子组成”时，意思是“一个真正的 H2O 分子由两个真正的氢原子和一个氧原子组成”，也意味着“任何（类型）分子由（某些类型的）原子”。

我们可以只陈述关于粒子类型的事实，而不是陈述关于真实粒子的每一个事实。
这就是我们通过对事物和创造的名称（类型）进行分组而获得的好处。

粒子类型层次作为集

层次结构可以转换为集合定义。

第二级 - 真实粒子之上的类型：

更高级别

使用集合论的术语，如果 A 是 B 的子集，则类型 A 是 B 的子类型。

我首先认为我们可以将 Atom 类型定义为：

但是，集合是关系，元素是元组，所以如果关系中的元组不兼容，联合就不起作用。

使用子类型表的方法可以解决问题并对子集关系进行建模。

但在子类型化方法中，Atom 仍处于第二级。

更高级别的类型被定义为集合的集合。

这意味着粒子是原子的类型，原子是氢的类型。

这样，粒子之间的关系可以在高层次上表示。

新的数据模型

4. 将类型视为类型的层次结构

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

样本数据：

为了比较，这是子类型表方法的示例数据。

亚原子

这些粒子类型是由人们定义的，人们不断定义新概念来模拟现实的新方面。
我们可以定义“子原子”，层次结构如下：

方法 4 可以更容易地适应这种类型层次结构的变化。

---

更新 2

要记录的事实

1. 世界上有不同类型的粒子：质子、中子、电子、原子、分子。
2. 原子由质子、中子和电子组成。
3. 分子由原子组成。
4. 有许多不同类型的原子：氢，氧，......
5. 有许多不同类型的分子：H2O、O2、....
6. 一个氢原子由一个质子和一个电子组成；...
7. 一个 H2O 分子由两个氢原子和一个氧原子组成；...
8. 不同类型的粒子可能具有特殊的性质，例如原子具有原子量等。
9. ...

在How to Set Up Primary Keys in a Relation 问题中，PerformanceDBA谈到了关系完整性并指出它与引用完整性不同。

我听说过与外键有关的参照完整性。 但是关系完整性对我来说似乎很奇怪。

在这个问题中，关系完整性和参照完整性是一回事吗？，克里斯说两者是一回事。

数据库世界中的术语和定义真的让我很困惑。
有人可以解释关系完整性吗？

---

自Edgar F. Codd在 1970年的论文中提出关系模型以来，关系数据库理论已经建立了几十年。 但是，在书籍或网络上对范式、完整性等没有一致的定义。 作为一个学习者，我很困惑。

我无法理解为什么以下从 ER 图到 ERM 的映射是正确的，或者更准确地说是完整的。在给定的示例中，我们在项目、地点和人员之间存在三元 1:1:N 关系。

每个实体都有一个主键（ProjectID、PlaceID、PersonID）。如果我理解此图正确，则一个人和一个项目的组合不能与多个地方相关联。此外，一个人和一个地方的组合只能与一个项目相关联。此外，特定地点的项目可以有多个人。

这种对如何解读三元关系的理解导致了我的问题。我将 ERM 映射到以下 RM：

我现在在Works表中有两个候选键：（Place，PersonID）和（ProjectID，PersonID）。让我们选择第一个作为主键。然后我应该有一个正确的 RM（文献告诉我），但我没有得到的是如何确保人员和项目的相同组合不与不同的地方相关联？难道我不必在某处说 (ProjectID, PersonID) 也是候选键，或者这不是 RM 符号的一部分吗？

我正在寻找将 eer 图转换为相应关系图的最佳方法。我有一个泛化实体，其中一些专业化与其他实体有单独的关系。泛化实体又与实体具有 n 对 m 关系。下图阐明了这种情况： 具有专业化和 n-to-m 关系的 Eer 图。

由于这两个专门的实体有不同的关系，我应该将它们转换为两个单独的表。同时，我应该创建一个建模 n 到 m 关系的表，该表将实体“用户”与实体“新闻通讯”（或者更好的是，它的专业化）相关联。如何应对这个问题？我没有找到任何有用的信息。

我想到的唯一可能的解决方案是创建两个单独的表来模拟 n 到 m 关系，一个链接到“用户”和“编程时事通讯”表，一个链接到“用户”和“旅行时事通讯”表。但我正在为此寻找意见。