这个问题需要一些假设的背景.让我们考虑一个employee有列的表name,date_of_birth,title,salary使用MySQL作为RDBMS.因为如果任何一个人的姓名和出生日期与另一个人相同,那么根据定义,他们是同一个人(除非我们有两个人在1809年2月12日出生的亚伯拉罕·林肯出生的惊人巧合),我们将把独特的按键name和date_of_birth,意思是"不存储同一个人两次." 现在考虑这些数据:

id name        date_of_birth title          salary
 1 John Smith  1960-10-02    President      500,000
 2 Jane Doe    1982-05-05    Accountant      80,000
 3 Jim Johnson NULL          Office Manager  40,000
 4 Tim Smith   1899-04-11    Janitor         95,000

如果我现在尝试运行以下语句,它应该会失败:

INSERT INTO employee (name, date_of_birth, title, salary)
VALUES ('Tim Smith', '1899-04-11', 'Janitor', '95,000')

如果我尝试这个,它会成功:

INSERT INTO employee (name, title, salary)
VALUES ('Jim Johnson', 'Office Manager', '40,000')

现在我的数据将如下所示:

id name        date_of_birth title          salary
 1 …

是否存在将SQL子查询转换为连接的通用过程或算法,反之亦然？也就是说,是否有一组排版操作可以应用于语法正确的SQL查询语句,其中包含一个子查询,该子查询导致函数等效语句没有子查询？如果是这样,它们是什么(即算法是什么),在什么情况下它们不适用？

我在7年的开发经验中看到的每个数据库中的几乎每个表都有一个自动递增的主键.为什么是这样？如果我有一个美国州的表格,其中每个州的每个州都必须有一个唯一的名称,那么自动递增主键的用途是什么？为什么不使用州名作为主键？对我来说似乎是一个允许重复伪装成唯一行的借口.

这对我来说显而易见,但是再一次,似乎没有其他人像我一样到达并采取相同的逻辑结论,所以我必须假设我错了.

我们需要使用自动递增键是否有任何真实的实际原因？

我得到了一个我无法弄清楚的wtf问题.我解释 :

我有一个名为Product的模型:

var Product = Backbone.RelationalModel.extend(
{
    urlRoot: Backbone.rootApiUrl + '/products',
    defaults: {
        id: '',
        name: '',
        description: '',
        current_price: '',
        categories: '',
        duration: '',
        shipping_cost: '',
        start_date: '',
        user_id: null,
        is_buy_it_now: ''
    },

    relation: [{
        type: Backbone.HasOne,
        key: 'user_id',
        relatedModel: User,
        autoFetch: true
    }]
});

我的字段user_id是一个用户的外键(也是Backbone中的模型):

var User = Backbone.RelationalModel.extend(
{
    urlRoot: Backbone.rootApiUrl + '/users',
    defaults: {
        id: '',
        name: '',
        email: '',
        firstname: '',
        lastname: '',
        password: '',
        card_nb: '',
        cart_total: ''
    }
});

我的获取关系在每个单独的模型中都能很好地工作 …

我正在阅读CJ Date的SQL和关系理论:如何编写准确的SQL代码,他认为位置查询很糟糕 - 例如,这INSERT:

INSERT INTO t VALUES (1, 2, 3)

相反,您应该使用这样的基于属性的查询:

INSERT INTO t (one, two, three) VALUES (1, 2, 3)

现在,我理解第一个查询与关系模型不一致,因为元组(行)是无序的属性集(列).我无法理解第一个查询中的伤害位置.谁可以给我解释一下这个？

有谁知道允许自动从UML类模型到数据库关系模型的映射的应用程序(Enterprise Architect,...)？怎么样？

谢谢

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

我知道数据建模是一个迭代过程,有许多不同的方法可以对事物进行建模.
但我不知道如何选择不同的选项.

例

假设我们想要模拟粒子(分子,原子,质子,中子,电子......).
为简单起见,让我们忽略夸克和其他粒子.

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

我不小心使用" 类型 " 这个词.
氢原子是一个实例.氢是一种类型.氢也是一种原子.
是的,涉及的类型层次结构.我们忽略了最低级别(单个粒子).

途径

我可以想到几种模拟它们的方法.

1.每种类型的事物(粒子类型)的一个表(关系,实体).

1.1我想到的第一种方法.

质子(质子)
中子(中子)
电子(电子)

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

分子(分子)
Molecule_Atom(Molecule,Atom,Quantity)

1.2由于只有一种质子/中子/电子,我们可以简化它.

原子(原子,质子数量,中子数量,电子量子)
分子(分子)
分子 _ 原子(分子,原子,数量)

在这个简化的模型中,关于质子的事实已经丢失.

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单关联表

粒子(粒子)
粒子组成(粒子,粒子,数量)

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

2.3结合2.1和2.2

粒子(粒子) …

在关于如何在关系中设置主键的问题中,PerformanceDBA谈到了关系完整性,并指出它与参照完整性不同.

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

在这个问题中,关系完整性和引用完整性是一回事吗？,克里斯说,两者是一回事.

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

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

我一直推迟开发应用程序的这一部分纯粹是因为我想以循环的方式做到这一点,但从我记得我的讲师告诉我回到学校的时候,感觉这是一个坏主意.

我有一个订单系统的设计,忽略了与我留下的这个例子无关的一切:

• 信用卡
• 顾客
• 订购

我想这样,

• 客户可以使用信用卡(0-n)
• 客户有订单(1-n)
• 订单有一个客户(1-1)
• 订单有一张信用卡(1-1)
• 信用卡可以有一个客户(1-1)(唯一ID,因此我们可以忽略cc号的唯一性,丈夫/妻子可以共享cc实例等)

基本上最后一部分是问题出现的地方,有时信用卡被拒绝,他们希望使用不同的信用卡,这需要更新他们的"当前"卡,但这只能更改用于该订单的当前卡,而不是客户可能在磁盘上的其他订单.

实际上,这在三个表之间创建了圆形设计.

可能的解决方案:要么

创建圆形设计,给出参考:

• cc参考订购,
• 客户参考cc
• 客户参考订购

要么

• 客户参考cc
• 客户参考订购
• 创建引用所有三个表ID的新表,并在订单上放置唯一,以便任何时候只有一个cc可以是该订单的当前

基本上两者都是相同的设计模型,但翻译方式不同,我在这个时间点最喜欢后一种选择,因为它看起来不那么循环,而且更加集中.(如果这甚至有意义)

我的问题是,

• 如果有的话各有利弊怎么办？
• 循环关系/依赖的缺陷是什么？
• 这是规则的有效例外吗？
• 有什么理由我应该选择前者而不是后者？

谢谢,如果有任何需要澄清/解释,请告诉我.

--update/Edit--

我注意到我说的要求有误.当试图简化SO的事情时,基本上丢球.付款还有另一张表,增加了另一层.捕获,订单可以多次付款,可以使用不同的信用卡.(如果你真的想知道其他形式的付款).

在此陈述这一点是因为我认为潜在的问题仍然是相同的,这只会增加另一层复杂性.

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

当有人说ER建模时他也暗示了EER建模吗？

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