教学数据库设计的好例子[关闭]答案

【问题标题】：Good examples for teaching database design [closed]教学数据库设计的好例子[关闭]
【发布时间】：2010-10-04 23:12:41
【问题描述】：

有没有人有教关系数据库和 SQL 的好场景？我能找到的所有示例要么是微不足道的，要么具有不太可能的域约束（例如全名是唯一的）。

我特别想找到一些规范化的好例子：不能立即适应 3NF 和 BCNF 的表格。目前我为每个级别使用不同的问题。

当然，我也喜欢设计糟糕的数据库的好例子，但在掌握基础知识之前会有点分散注意力。

谢谢，一些很好的例子。我已将学生/班级一标记为答案，因为我认为这是迄今为止最好的，但如果有人想贡献更多，请做。

【问题讨论】：

标签： database-design normalization scenarios

【解决方案1】：

我似乎记得学生/班级是经典的，你也可以把成绩放在那里，让它更复杂一点。

学生可以参加很多课程
班级有很多学生
对于学生参加的每一节课，他们都可以有一个成绩

最初您可以在一张表中执行此操作，然后将其非规范化为三张。

【讨论】：

+1 好，经典的例子
可以走得更远，也有学年/学期的课程
不要忘记教职员工。和部分（课程概念的预定版本）。
很好，通过将考试/课程限制为每年一次，我可以获得一些有趣的依赖关系。

【解决方案2】：

题外话

在教过数据库课程之后，我建议在掌握查询的基础知识之前忘记设计。一旦人们了解了如何从数据库中获取数据，人们就会更好地理解规范化的必要性。如果您从规范化和设计开始，您将失去课堂其余部分的大部分学生。设计应该是数据库课程的最后一个模块，但我看过的所有教科书都是从它开始的。

更好的是让他们在学习查询时同时查询好的和坏的数据库设计，然后他们会真正了解当教授设计时糟糕的设计是多么痛苦。

【讨论】：

我完全同意 - 您需要确定限制是什么，以及是什么驱使您达到更高的设计水平。 (+1)

【解决方案3】：

电子商务/购物车设计很好，因为大多数人都理解这个概念，你可以将它推向许多不同的方向。

您可以做一些简单的事情，例如购物车、购物车项目、用户、订单、订单项目等。

然后您可以更深入地了解 user_addresses、user_emails、items、item_details、item_history 等。

这可以提供很多很好的辩论，因为有很多判断电话。

【讨论】：

谢谢，我也喜欢这个，也许是最后一个问题。
最好的部分是您可以展示一些数据库设计问题，例如当您不存储订单详细信息但依赖于更新价格的产品表时会发生什么季刊。您还可以使用它来显示不加选择地使用级联删除的危险。糟糕，删除客户已从财务报告中删除了订单。

【解决方案4】：

我永远不会忘记的一个概念是整个“复数”与“单数”的命名。很久以前，一位伟大的导师告诉我，您应该将表名设计为复数，将列名设计为单数，并且永远不要为列名创建特定于时间的名称。时间名称示例有 NutsSold1998、NutsSold1999、NutsSold2000 等。切勿在列名称中添加年份、月份或周数或时间等。

表名示例：雇员（非雇员）零件（不是零件）学生（学生）

列名示例： EmployeeID（不是EmployeesID或EmployeeIDS等） PartID（不是 PartsID 或 PartIDS 等） StudentID（不是StudentID或StudentIDS等）

并且要注意 ID、代码、密钥、数字等的正确用法...我总是被教导不要在列的名称中使用“密钥”，除非它是实际的表密钥（主要或外国的，但不一定是替代的）..大多数时候附加“ID”将比附加“数字”或“代码”更好，但这完全取决于上下文。

这伴随着时间和设计桌子的经验，阅读好的材料，如书Database Design For Mere Mortals和Data Modeling for Everyone。此外，花大量时间寻找好的设计并将它们分开。这绝对是一门手艺，只有通过时间和练习才能变得更好。

【讨论】：

【解决方案5】：

另一个好的模型是发票项目模型，因为“最佳选择”取决于各种因素：

写入与读取操作的次数；
性能；
是否需要报告功能？

看看这个数据模型：

发票

身份证
日期

发票项目

发票ID
说明
金额

应用程序功能是：

创建新发票；
每天晚上创建并发送两个报告：(a) 每张发票的总金额，(b) 当天的总金额。

假设您平均每张发票有 5 件商品，每天有 100 张发票，您最终每天都会这样做：

5 x 100 写入 InvoiceItem；
100 次写在发票上；
5 x 100 + 100 = 600 从 Invoice 和 InvoiceItem 读取（报告 (a)）；
5 x 100 + 100 = 600 从 Invoice 和 InvoiceItem 读取（报告 (b)）；

所以总计 = 1800 次操作/天，假设读取和写入的成本相同。

如果在实体“Invoice”上添加“TotalAmount”属性，情况会有所不同：

5 x 100 写入 InvoiceItem；
100 次写入 Invoice（包括 TotalAmount）；
100 来自发票仅（报告 (a)）；
100 仅来自发票（报告 (b)）；

总共有 800 次操作 :)

【讨论】：

【解决方案6】：

这是一个可以追溯到我大学时代的示例 - 它既被用作数据库设计挑战，也被用作面向对象的设计挑战。

并非所有信息都立即披露 - 部分挑战在于了解如何调整设计以处理新要求，以及适当的规范化如何使这变得更容易。

假设您必须为大学/学院的情况设计一个数据库并且想要处理招生。

您已教授课程。每门课程都有一个标题和每周固定的时间段。

每门课程都有一位讲师介绍课程。

每门课程都有许多学生学习该课程。

每门课程都有一名或多名导师帮助学生学习。您无需跟踪哪些导师帮助了哪些学生。

有些课程有多个固定时间段。

有些课程有多个讲师。

讲师和导师是有报酬的，这意味着我们需要跟踪一些信息以用于税收目的。税务部门不在乎他们的报酬是什么——他们希望我们每个人都有一个记录。

在某些课程中，讲师还担任导师，以近距离了解一些学生如何处理材料。

一些导师也是其他课程的讲师。

要成为课程的导师，您必须在更早的时间成为该课程的学生。

并非每个学生都会因通过课程而获得学分 - 有些学生只是在审核课程而不需要学分。

课程未通过的学生可以稍后再次参加该课程。我们需要记录每一次尝试。

【讨论】：

【解决方案7】：

总是有图书馆的例子（图书馆有很多书，每本书都有一个作者和出版商，当你规范化时可以将它们推送到单独的表中）

【讨论】：

【解决方案8】：

回复：

我特别想找到一些规范化的好例子：不能立即适应 3NF 的表格和 BCNF。

您可以在此处找到规范化 数据库架构示例：http://www.microsoft.com/sqlserver/2005/en/us/express-starter-schemas.aspx。您可以从头开始构建它们，以向您的学生展示“标准化方式”。特别看一下联系人管理模式。您可以轻松地对架构进行非规范化并将其恢复为 3NF 或更深。

【讨论】：

【解决方案9】：

Itzik Ben Gan 的新书 Microsoft SQL Server 2008：T-SQL Fundamentals 有一个非常基本的示例，您可以看到该示例源自简化的 Northwind 数据库。

Microsoft SQL Server 2008: T-SQL Fundamentals author support page

【讨论】：