database-normalization

5热度

2回答

我是新来的卡桑德拉和正在寻找如何有这种一般结构如下数据模型中的最佳实践：的数据是基于“用户”（每用户），每个提供大约500K-2M条目的大数据文件（每天定期更新几次 - 有时全部更新，有时只增量）每个数据文件都有一定的强制性数据字段（~20强制），但可以根据他们的判断增加额外的栏目（最多〜100）。的附加数据字段是NOT必然同为不同用户（字段的名称或类型的那些字段的）实施例（CSV格式:

-1热度

1回答

将以下关系分解为BCNF

给定与属性A，B，C，D，E的关系R以及功能依赖关系A-> B，BC-> E，ED-> A的集合。将其分解为高正常形式。

-1热度

1回答

规范和使用主/外键的SQL Server 2008 R2

注：我以前从来没有做过这样的：有哪些步骤或文档，以帮助恢复正常数据库中的表/视图？目前，数据库中有多个表和视图不使用主键/外键概念，并且在多个表中重复相同的信息。我想清理一下，也有点设置一个进程，保持关系更新。例如，如果一个人的邮编变化或记录被删除，那么它会自动更新其与其他表格行的关系。注意：*我的问题是规范现有的数据库表。这些表格是现场直播的，所以我如何处理标准化？我是否需要创建一个具有我

2热度

2回答

实体关系图冗余：商店，产品，订单，类别

我试图设计一个模型，允许用户成为一个账户的买方和卖方，但一些老师告诉我，这个图是错误的，因为它有冗余。我已经回顾了图表，但我还没有找到解决这种冗余的方法。在表orders我需要知道谁是买家，所以出于这个原因，我没有从表中删除这个。一些想法？

-1热度

1回答

转换关系到BCNF

R（A B C） AB - > C， Ç - >甲 AB是最小超键这是一个候选键。 AB - > C很好。但由于素数属性取决于Non Prime属性，因此C - > A不成立。我知道如何分解，直到3 NF。我也知道为什么关系不在BCNF中。但我不知道如何将这种关系分解为BCNF。任何人都可以把这个关系分解成BCNF。

-1热度

1回答

抽象关系模式的正常形式

我想知道关于关系数据库正常形式的这些考题。在我看来，第一个应该是3NF，第二个是2NF（即第一个应该是错的）。问题9. [...] C int, D int NOT NULL, UNIQUE (B,C) [...] 我的理由是，由于C是独一无二的，它也是一个候选键，因此一个主属性。因此，它也是一个超级键，因此适合3NF的描述。为3NF定义：关系模式R是第三范式（3NF）如果，每当一个非平凡函数

0热度

4回答

不知道这是否构成传递依赖

我有点卡住设计数据库的一部分。我有一张名为Staff的表格。它具有不同的属性： StaffID First Name Last Name Job Title Department Number Telephone Number StaffID是此表中的主键。但是，我的问题是可以根据电话号码找到任何信息（即每个工作人员都有不同的唯一电话号码）。例如，这意味着当我们有Phone N

1热度

2回答

如果我们更改主键值，为什么我们不必更改从属列值？

我看了关于数据库规范化的one tutorial on youtube。表看起来是这样的： |Item(PK) | Supplier | Supplier Phone | Price| --------------------------------------------- | Xbox One| Microsoft| 1234 | 250 | -------------------

0热度

1回答

我的mysql外键约束有什么问题？

我正在开展一个个人项目，并且这是我一生中第一次尝试创建一个规范化的数据库（至少在第一个规范化级别）。下面是涉及我的问题的表格： CREATE TABLE `reoccurrences` ( `name` varchar(15) NOT NULL DEFAULT '', `username` varchar(31) NOT NULL DEFAULT '', `amount

-1热度

1回答

标准化表结构VS平台结构

我们公司对于平板结构与标准化表结构存在争议。到目前为止，我们确实认为我们有一个规范化的数据库，并且应用程序可以很好地运行它。但是，报告是由IT人员在客户端完成的，因为有时会生成一些临时报告。有时他很担心，因为他无法从简单的桌子结构中提取细节。他已经升级到管理层，他们也有这样的印象：高规格化的数据库并不真正有用。我们该如何捍卫规范化数据库vs平坦表结构的上下文。任何人都有过这种经历。