Questions tagged «relational-theory»

在此站点上，此标签适用于有关关系模型理论的问题。数据库管理的关系模型是一种使用与一阶谓词逻辑一致的结构和语言来管理数据的方法。在数据库的关系模型中，所有数据均以元组表示，并分组为关系。根据关系模型组织的数据库是关系数据库。

5
为什么RDBM的集群不能像NoSQL那样？
Nosql DBMS的一大优点是它们可以更轻松地集群。假设使用NoSQL，您可以创建数百个便宜的计算机，这些计算机存储不同的数据并立即查询所有数据。 我的问题是，为什么关系型DBMS不能像mysql或sql server那样？是仅仅是供应商还没有找到一种技术方法来解决现有产品的问题，还是关系模型存在一些问题导致这种情况不可行？NoSQL存储和访问数据（键/值，文档等）的方式有什么好处，可以简化群集操作（如果确实如此）？
5
我应该如何设计友谊表？
如果A是的朋友B，那么我应该同时存储值AB和BA，还是一个就足够了？两种方法的优缺点是什么？ 这是我的观察： 如果同时保留两者，则在收到朋友的请求时必须同时更新两者。 如果我没有同时保留两者，那么我发现在JOIN对该表进行多次处理时很难。 目前，我以一种方式保持这种关系。 那么在这种情况下我该怎么办？有什么建议吗？
3
为什么ANSI SQL将SUM（无行）定义为NULL？
的ANSI SQL标准定义（第6.5章，集功能规范），用于空的结果集的集合函数以下行为： COUNT(...) = 0 AVG(...) = NULL MIN(...) = NULL MAX(...) = NULL SUM(...) = NULL 由于未定义空集的平均值，最小值和最大值，因此对AVG，MIN和MAX返回NULL十分合理。 但是，最后一个让我感到困扰：从数学上来说，空集的SUM是定义明确的：0。使用0 （加法的中性元素）作为基本情况可以使所有内容保持一致： SUM({}) = 0 = 0 SUM({5}) = 5 = 0 + 5 SUM({5, 3}) = 8 = 0 + 5 + 3 SUM({5, NULL}) = NULL = 0 + 5 …
6
在表中任意排序记录
使用数据库时，通常需要按顺序访问记录。例如，如果我有一个博客，我希望能够以任意顺序重新排列我的博客文章。这些条目通常具有很多关系，因此关系数据库似乎很有意义。 我见过的常见解决方案是添加一个整数列order： CREATE TABLE AS your_table (id, title, sort_order) AS VALUES (0, 'Lorem ipsum', 3), (1, 'Dolor sit', 2), (2, 'Amet, consect', 0), (3, 'Elit fusce', 1); 然后，我们可以对行进行排序，order以使其按正确的顺序排列。 但是，这似乎很笨拙： 如果我想将记录0移到开头，则必须对每个记录重新排序 如果我想在中间插入新记录，则必须对每个记录重新排序 如果要删除记录，则必须对它之后的每个记录重新排序 很容易想到这样的情况： 两个记录具有相同的 order order记录之间存在差距 这些可能很容易发生，原因有很多。 这是Joomla之类的应用程序采用的方法： 您可能会争辩说这里的界面很糟糕，他们应该使用箭头或拖放操作来代替人类直接编辑数字，而您可能是正确的。但是在幕后，发生了同样的事情。 有人建议使用小数来存储顺序，以便您可以使用“ 2.5”将记录插入顺序为2和3的记录之间。虽然这样做有所帮助，但可以说它甚至更麻烦，因为您最终会得到奇怪的小数点（您在哪里停止？2.75？2.875？2.8125？） 有没有更好的方法将订单存储在表中？
6
为什么使用“关系”一词？
用英语，我们可能会谈论鲍勃和蒂姆之间的关系。也许他们是表亲。在这种情况下，术语“关系”对我来说很有意义。 在关系数据库的上下文中，我理解该术语所指的含义，但我不理解为什么使用该术语。我认为了解为什么使用它可以帮助我更好地理解该领域，因此我想了解为什么使用它。 例如，为什么一个人被认为是“关系”？用英语来说，关系是描述两个实体如何关联的名词。它不涉及实体本身。在关系数据库的上下文中，“关系”是指实体本身。为什么？ 我知道关系模型是在层次模型和网络模型（例如父级，邻居）之后出现的。但是在这些模型中，实体之间也有关系。那么为什么将此模型称为关系模型呢？是否有更具体的短语/术语？也许我们应该说这三个模型都是关系模型，但是层次模型和网络模型是特定类型的关系模型？ 如果我们拥有彼此不相关的独立实体该怎么办。说，人，门和树。术语“关系”是否仍然适用？ （也许这应该是多个问题。我认为答案是高度相关的-也许只有一个答案-所以我认为这是一个问题是有意义的。如果我错了，请告诉我而是创建单独的问题。） 编辑：此图对于可视化关系将不同的域相互关联起来可能很有用：
3
正确使用查询表
我在弄清楚如何为何时何地在数据库中使用查找表放置良好的边界时遇到了麻烦。我看过的大多数资料都说我永远不会有太多，但是在某些时候，似乎数据库会被分解成很多部分，尽管它可能是有效的，但不再可管理。这是我正在使用的东西的综合示例： 假设我有一个名为“雇员”的表： ID LName FName Gender Position 1 Doe John Male Manager 2 Doe Jane Female Sales 3 Smith John Male Sales 假装数据更加复杂并且包含数百行。我看到可以移至查找表的最明显的东西是位置。我可以创建一个名为Positions的表，并将Positions表中的外键粘贴到Position列中的Employees表中。 ID Position 1 Manager 2 Sales 但是，在信息变得难以管理之前，我可以继续将信息分解为较小的查找表吗？我可以创建一个性别表，并在单独的查找表中将1对应于Male，将2对应于Female。我什至可以将LNames和FNames放入表中。所有“ John”条目都被外键1替换，该外键指向FName表，该表说ID为1对应于John。但是，如果您像这样在这个兔子洞中走得太远，那么Employees表就会变成一堆外键： ID LName FName Gender Position 1 1 1 1 1 2 1 2 2 2 3 2 1 1 …
3
如何与有特权的孩子建立一对多关系？
我想建立一对多关系，其中对于每个父母，一个或零个孩子被标记为“收藏夹”。但是，并不是每个父母都会有一个孩子。（例如，将父母视为本网站上的问题，将孩子视为答案，将喜欢的事物作为接受的答案。）例如， TableA Id INT PRIMARY KEY TableB Id INT PRIMARY KEY Parent INT NOT NULL FOREIGN KEY REFERENCES TableA.Id 我看到的方式可以将以下列添加到TableA中： FavoriteChild INT NULL FOREIGN KEY REFERENCES TableB.Id 或TableB的以下列： IsFavorite BIT NOT NULL 第一种方法的问题在于它引入了可为空的外键，据我所知，它不是标准化形式。第二种方法的问题是，需要做更多的工作以确保最多一个孩子是最爱的。 我应该使用哪种标准来确定使用哪种方法？或者，还有其他我没有考虑的方法吗？ 我正在使用SQL Server 2012。
5
命名表和视图时应遵循什么标准？
命名表和视图时应遵循什么标准？例如，将tbl_之类的东西放在表名的开头是个好主意吗？是否应该以ct_，lut_或codes_之类的方式指定代码/查找表？还有其他的做/不做的事情吗？ 我使用的是MS SQL Server，并且有许多数据库和许多表，因此最好将我们作为标准并带有一些支持性的理由使用。
2
设计用户认证（角色和权利）模块
我正在尝试为MS SQL Server数据库建模用户身份验证模块，该模块将成为Delphi UI应用程序的后端。基本上，我想拥有一个用户帐户，其中该用户仅属于一个组。一个组可以具有“ n”个权限。 我还想将密码历史记录添加到数据库中，因为将要求用户根据应用程序设置（例如，每90天）更改其密码。 我也想在用户每次登录和注销时都记录一个事件。我将来可能会将其扩展到其他事件。 在下面，您会发现我的第一个裂缝。请让我知道任何改进的建议，因为这是我第一次这样做。 您是否发现需要其他属性以实现基于角色的安全性以及密码规则/有效期限的约束？
2
数据库设计：规范“（多对多）对多”关系
精简版 我必须在现有的多对多连接中为每对添加固定数量的其他属性。跳到下图，就优点和缺点而言，选项1-4中的哪一种是通过扩展基本案例来实现此目的的最佳方法？或者，还有没有在这里我没有考虑过的更好的选择？ 较长的版本 我目前有一个通过中间联接表以多对多关系的两个表。现在，我需要向属于这对现有对象的属性添加其他链接。尽管属性表中的一个条目可能适用于多个对（或者甚至可以成对使用多次），但每个对都有固定数量的这些属性。我正在尝试确定执行此操作的最佳方法，并且在梳理如何思考情况时遇到了麻烦。从语义上来说，我似乎可以很好地描述以下任何一种情况： 一对链接到一组固定数量的其他属性 一对链接到许多其他属性 许多（两个）对象链接到一组属性 许多对象链接到许多属性 例 我有两个对象类型，X和Y，每个都有唯一的ID，以及一个objx_objy带有列x_id和的链接表y_id，它们一起构成链接的主键。每个X可以与许多Y相关，反之亦然。这是我现有的多对多关系的设置。 基本情况 现在，我另外在另一个表中定义了一组属性，以及一组条件，在这些条件下，给定（X，Y）对应该具有属性P。条件的数量是固定的，所有对都相同。他们基本上说：“在情况C1中，对（X1，Y1）具有属性P1”，“在情况C2中，对（X1，Y1）对具有属性P2”，依此类推，对于联接中每对的三种情况/条件表。 选项1 在我目前的状况正好有三个这样的条件，我也没有理由认为增加，所以一种可能性是添加列c1_p_id，c2_p_id以及c3_p_id对featx_featy，指定用于给定x_id和y_id，其性能p_id在每个三种情况使用。 在我看来，这并不是一个好主意，因为它使SQL难以选择应用于某个功能的所有属性，并且无法轻松扩展到更多条件。但是，它确实对（X，Y）对执行一定数量的条件的要求。实际上，这是这样做的唯一选择。 选项2 创建一个条件表cond，并将条件ID添加到联接表的主键中。 不利的一面是，它没有为每对指定条件数量。另一个是当我只考虑初始关系时，例如 SELECT objx.*, objy.* FROM objx INNER JOIN objx_objy ON objx_objy.x_id = objx.id INNER JOIN objy ON objy.id = objx_objy.y_id 然后，我必须添加一个DISTINCT子句以避免重复的条目。这似乎已经失去了每个对应该只存在一次的事实。 选项3 在联接表中创建一个新的“对ID”，然后在第一个与属性和条件之间建立第二个链接表。 除了缺乏对每对执行固定数量的条件外，这似乎具有最少的缺点。创建一个除了现有ID之外没有其他标识的新ID是否有意义？ 选项4（3b） 与选项3基本相同，但不创建其他ID字段。这是通过将两个原始ID都放入新的联接表中来完成的，因此它包含x_id和y_id字段，而不是xy_id。 这种形式的另一个优点是它不会更改现有表（尽管它们尚未投入生产）。但是，它基本上多次复制整个表（或者无论如何感觉都是这样），因此似乎也不理想。 摘要 我的感觉是，选项3和4足够相似，我可以选择其中一个。如果不要求对属性进行少量固定的链接，那么到现在我可能已经有了，这使得选项1看起来比其他情况更加合理。根据一些非常有限的测试，DISTINCT在这种情况下向我的查询添加一个子句似乎不会影响性能，但是我不确定选项2和其他情况是否都代表了这种情况，因为放置会引起内在的重复链接表的多行中的相同（X，Y）对。 这些选择是我最好的前进方式，还是我应该考虑另一种结构？
2
如何构建模型以正确，有效地表示关系数据库中的树状数据？
基于使用SQL问题在关系数据库中遍历树状数据的方法，我想知道如何在考虑物理影响的情况下定期用于在关系数据库中描述树状数据的方式？ 我假设RDBMS除了常规的SQL ANSI或常用功能之外，没有其他特殊功能来处理这些功能。 毫无疑问，我一直对MySQL和PostgreSQL以及最终对SQLite感兴趣。
6
举例说明2NF与3NF
我对第二范式（2NF）有疑问，但无法使用Google来解决。这让我发疯，因为我是一名老师，而且我不想向学生们教错误的东西。 让我们有一个包含5个字段的表格。 评分= {学生姓名，学科编号，学科名称，＃考试，年级} 依赖性是这样的： 学生姓名，科目代码，＃考试->年级 SubjectCode-> SubjectName SubjectName-> SubjectCode 因此，候选键1是{StudentName，SubjectCode，#Exam}，候选键2是{StudentName，SubjectName，#Exam}。 主要属性是{StudentName，SubjectCode，SubjectName，＃Exam}，非主要属性是Grade 根据第二范式的定义，非素数属性不能取决于候选密钥的一部分。唯一的非素数属性（Grade）不依赖于候选键的一部分，因此该表看起来像2NF。 问题是我认为有些不对（我可能错了）。我认为受试者应该有自己的桌子。 评分= {学生姓名，学科代码，＃考试，年级} 主题= {主题代码，主题名称} 但是2NF不会产生这种情况。3NF与非素数属性之间的依赖关系有关，因此也不会产生这种情况。但是在我看来，这是正确的结果，因为它没有冗余。 我想如果非素数属性定义为“不是候选键的属性”，则2NF将产生所需的结果。但是我已经一遍又一遍地检查了这一点，并且非素数属性被定义为“对候选键不信任的属性”。 我究竟做错了什么？
3
如何从两个不同的表中将值插入到表中？
我有三张桌子 students table ------------------------------------ id(PK, A_I) | student_name | nationality teachers table ------------------------------------ id(PK, A_I) | teacher_name | email classroom table ---------------------- id(PK, A_I) | date | teacher_id(FK to teachers.id) | student_id(FK to students.id) 如果我得到了老师的名字（david例如）和student_id数据（7例如），并要求插入teacher_id到classroom基于表id的teachers表，我会做： insert into classroom (date, teacher_id, student_id) select '2014-07-08', id, 7 from teachers where teacher_name = …
2
一对一关系是否正常化？
考虑我们有大量的统计数据记录；例如20-30 INT列。最好将整个集合都保留在一个表中，因为它们都属于一条记录，还是创建另一个具有一对一关系的表。 前者的优点是避免JOIN并可以快速访问相应记录的所有统计数据。 后者的优点是使色谱柱保持整洁。第一列是读密集型的，第二列是写密集型的。当然，我认为它对性能没有显着影响，因为我将InnoDB与行级阻塞一起使用。 总的来说，我想知道为一条记录分离不同的数据集是否有用？
3
关系数据库中的完整性约束-我们应该忽略它们吗？
我正在与我工作的公司的开发人员进行永久性讨论，因为他们说最好摆脱关系数据库中的关系强制（通过FOREIGN KEY约束定义），以便加快大型查询并获得更好的结果。性能。 所考虑的平台是MySQL 5.x，并且尚未设置FOREIGN KEY，甚至缺少相关表的一些PRIMARY KEY约束，至少对于我来说，这是不合理的。也许他们是对的，但我是错的，但我没有足够的论点来讨论这种情况。 三年来，这一直是首选方法。我是这家公司的新手（只有一个月），但是随着产品的“上市”，人们在犹豫是否要增强数据库。话说回来，我注意到的第一件事是一页需要1分钟的加载时间（是的，需要60秒！）。 当前事务状态背后的一种说法是，“非规范化”数据库比规范化数据库要快，但我认为那不是真的。 大多数相关查询都包含JOIN操作，这使它们在处理大量数据（数据库包含数百万行）时非常非常非常慢地运行。 通常，“ CRUD”操作的处理是在应用程序代码级别实现的；例如，为了删除一些数据自，例如TableA： 必须首先即时检查TableA和的行之间是否存在某种关系TableB， 如果上述关系被“检测到”，则应用程序代码将不允许删除相关行，但是 如果由于某种原因该应用程序代码失败，则无论涉及的行和表是否存在任何关系，DELETE操作都将“成功”进行。 题 您能帮我拟定一个良好，准确而可靠的答案以丰富辩论的内容吗？ 注意：也许以前有人问过（并回答过）类似的问题，但是我无法通过Google找到任何东西。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.