如何引用关系数据库中的记录组？
假设我们具有以下表结构： 人类 | HumanID |名|姓氏|性别| | --------- + ----------- + ---------- + -------- | | 1 | Issac |牛顿M | | 2 |玛丽|居里F | | 3 |蒂姆|邓肯| M | 动物 | AmimalID |种类|昵称| | ---------
..
database-normalization相关内容
跳过标准化步骤？
只是好奇：有人出于某种原因不能一步一步完成所有必要的标准化 吗？归一化是否最终会重绘功能依赖关系（FD）图？我们从FD图/图形开始，最后要以图形表示（顶点是属性，如果b是a上的FD，则属性a，b之间有一条边）表示（编辑）BCNF中的关系？ 编辑：我的意思是：我们从FD图开始，这是一个图配对属性a，b，如果b是A上的FD，即我们加入a和b，边缘为iff b = f（a）。 从该图我们想要获
..
确定关系是否为1NF，无数据
我有关系 CAR_SALE（汽车编号，销售日期，销售人员编号，佣金百分比，折扣金额） 主键：{Car＃，Salesperson＃} 其他依赖项：Date_sold-> Discount_amt 销售员＃->佣金％ ，我必须确定它是1NF，2NF还是3NF。我们只得到没有数据的关系模式。我无法确定这是否在1NF中。为了使某项包含在1NF中，该属性不得具有重复的组。在没有实
..
归一化后的功能依赖性
我正在努力理解规范化过程的一个方面，在我对2NF（或3NF）的关系进行规范化之后，我不太了解如何处理功能依赖性。 让我用一个例子来描述它。 我的课本中的练习要求将与2NF，然后与3NF的关系归一化。给予关系 R =（ABCDEF），F = {AD-> FE，BC-> E，FEA-> D ，AC-> DE，F-> E，BD-> A，F-> C，ABC-> AEF，B-> F} 在
..
标准化一个很大的表
我面临以下问题。我有一张大桌子。该表是以前从事该项目的人员的遗产。该表位于MS SQL Server中。 该表具有以下属性： 它有大约300列。它们都具有“文本”类型，但是其中一些最终应表示其他类型（例如，整数或日期时间）。因此，在使用这些文本值之前，必须先将其转换为适当的类型 表中的行超过100毫米。该表的空间很快将达到1 TB 该表没有任何索引 该表没有任何已实现的分区机制。
..
当1NF表没有复合候选键时，它在2NF中吗？
可以肯定地说，当1NF表中没有复合候选键（主键包含多于一列）时，该表会自动处于2NF中吗？ 当表的主键中只有一个列时，表可以破坏2NF吗？ 解决方案 一个relvar R位于2NF中只要没有非平凡的FD，A-> B都由R满足，其中B是非素数，并且A是R的某些候选关键字的适当子集。 您首先必须考虑所有候选键。如果所有候选键都碰巧是单个属性键，则这些键中唯一可能的正确子集是{}（空
..
如何最好地表示同时出现在主记录和明细记录中的属性？
我有一个简单的主从关系，其中两个实体共享一个属性（恰好是时间戳，并且不是键的一部分。）详细记录（按其他属性）从上到下进行排序。业务规则是：（a）如果有明细记录，则将最上面的时间戳记应用于主记录； （b）否则，船长无论如何均须有时间戳记； （c）（很少）允许船长的时间戳不同于最顶层详细记录的时间戳。 最常见的情况是（a），我想避免在主数据和最详细信息中重复时间戳。您将如何设计这种情况？ 非常感谢
..
几乎一棵树的数据库架构
我具有以下结构： A座 Foo 1 酒吧1 Bar 2 Foo 2 Bar 1 Bar 3 Bar 4 Block B Foo 3 每个Foo都完全属于Block。 每个酒吧都完全属于Block。 酒吧不能属于同一酒吧的一个或多个Foo 。 模式当前如下： 块 1 / \1 n / \n
..
像我五岁一样解释->主键如何满足第一范式
谢谢您的预先了解。我正在为参加Microsoft技术考试而学习，其中一个实践问题是： 创建主键可以满足第一种标准形式。是真的还是假的？ 我个人认为这是错误的，因为第一个范式是消除重复的组。但是文本（数据库基础知识，Microsoft Press考试98-364）中有一个句子，内容如下： “第一个规范化形式（1NF）表示数据采用实体格式，这基本上意味着必须满足以下三个条件： •该
..
普通表格-第4普通表格
我有需要输入到第三和第四范式的数据。 我了解范式的基本知识，但是对第三和第四范本感到困惑 我正在创建一个系统正在使用的数据库。 解决方案 在BCNF，3NF和较低NF中也存在4NF的关系。 来自此答案： 超键是一组唯一标识行的列。 候选键是一组唯一标识行的列，而 不包含唯一的 标识行的列的较小（“适当”）子集。 因此， 候选键是一个不包含更小的超级
..
如何不规范连续数据（INTS，FLOATS，DATETIME等）？
根据我的理解-如果我错了，请纠正我-“规范化”是从数据库中删除冗余数据的过程 但是，当我尝试学习数据库优化/性能调整时，遇到了先生。里克·詹姆斯（Rick James）建议反对标准化连续值，例如（INTS，FLOATS，DATETIME等） “规范化，但不要过度规范化。”特别是，请勿对 日期时间或浮点数或其他“连续”值进行规范化。 源 当然，纯粹主义者说可以正常化时间。那
..
如果我们使用自动递增的身份列和PK，则违反3NF
Thomas Connolly和Carolyn Begg在第180页的数据库解决方案第二版中说过： 第三种形式（3NF） 一个表已经存在于1NF和2NF中，并且在 中，可以从 中计算出所有非主键列中的值，而只有主键列，但没有其他列。 我已经看到了许多情况，尽管人们已经拥有主键，但他们仍使用身份列表中的列。一条记录也可以从Identity列中得出，因此如果我们在表中使用自动递增
..
在关系数据库中对相同实体之间的多对多关系进行建模
当两个表具有多对多关系时，或者当一个表与自身具有多对多关系时，我们可以使用联结表对其进行建模。 但是关系的类型可以超出原始类型，例如： 要求：我们有用户。每个用户可以有0个或更多其他用户作为朋友 解决方案：一个用户表和一个称为“ user_user”的联结表。 然后，我们发现了一个新要求：某些友谊是浪漫的，换句话说，两个用户可以用不同于友谊的方式建立联系。 解决方案a
..
标准化要走多远？
我有这些表： 项目（projectID，CreatedByID） 员工（empID，depID） 部门（depID，OfficeID） 办公室（officeID） CreatedByID 是的外键员工。我有一个查询，几乎所有页面加载都运行。 仅添加冗余的 OfficeID 是不好的做法吗？列到 Projects 来消除三个联接？还是应该执行以下操作： 选
..
单表继承会导致非规范化
我们正在尝试提出付款方式的数据模型。可以使用多种付款方式，例如“卡”，“银行转帐”，“电子钱包”，这些付款方式可以进一步分类为：将卡转换为信用卡/借记卡，将银行转帐至ACH / SEPA等。 因此，这是关于将继承建模到数据库表中。一种选择是使用单表继承。我团队中的高级人员将单个表称为非规范化表。但我不明白为什么？我在这里看不到任何插入/删除/更新异常，每个付款方式记录都独立存在，没有多余之处
..
当属性与任何其他属性无关时，如何分解BCNF
分配： 考虑一个关系𝑅（𝐴，𝐵，𝐶，𝐷，𝐸，𝐸，𝐺 ，𝐻）及其FD集𝐹= {𝐴𝐵→𝐶𝐷，𝐸→𝐷，𝐴𝐵𝐶→𝐷𝐸，𝐸→𝐴𝐵，𝐷→𝐴𝐺，𝐴𝐶𝐷→𝐵𝐸}。 如果它不在BCNF中，则将其分解为BCNF关系的集合。确保您的分解是无损加入。 解释 嗨，我正在做数据库作业（“关系设计”一章）。 我想我已经根据课堂示例掌握了基本过
..
可以在没有主键的3NF中使用表吗？
1。 如果满足以下条件的一个，则表将自动以3NF表示： （i）如果一个关系包含两个属性。 （ii）如果2NF表仅包含一个非关键属性。 2。 如果X→A是一个依赖项，则该表位于3NF中，如果存在以下条件之一： （i）如果X是超键 （ii）如果A是超键的一部分 我从此网站获得了上述声明。 / p> 我认为在两个声明中，第二个子点都是错误的。 第一个是
..
规范化数据库模式中是否可以有多个外键？
地址（地址ID ，门牌号，邮政编码，道路名称，城市，县） 预订（预订ID ，房间号， leadGuestID，guest2ID，guest3ID ， &arrivalDate，departmentDate， addressID ，amountOutstanding） Guest（ guestID ，名字，姓氏，adultFlag，电话号码，地址ID ，电子邮件地址） 房
..
4NF，不带功能依赖项的多值依赖项
很抱歉提出一个问题，可能会考虑一个基本问题） 假设我们有一个具有多值依赖关系的关系R（A，B，C，D，E） ： A->> B B->> D。 关系R没有没有任何功能依赖性。 接下来，假设我们将R分解为4NF。 我的考虑： 因为我们不这样做没有任何功能依赖性，唯一的关键就是所有属性（A，B，C，D，E）。我们可以通过两种方式分解关系R： R1（A，B）R2（A
..
规范封面是哪种范式？
我想知道规范封面处于哪种范式。我知道在进行规范化之前我们先找到规范封面，所以我认为它是第一范式。但这可能不是标准格式，因为Wikipedia对1NF的定义是没有行应该重复： 以下是第一个标准格式条件： 消除单个表中的重复组。 为每个表集创建一个单独的表相关数据。 用主键标识每组相关数据 解决方案 普通形式适用于关系（值和变量），而不适用于规范封面。封面是一组FD（功能依赖项
..