1.1 简介
设计数据库有点类似于设计 Java 项目的架构。您可以将所有数据放在几个表中，或者您可以从模式和数十个表构建一个漂亮的数据结构。
以下是开发人员在设计数据库时通常面临的任务：
- 确保所有必要的信息都存储在数据库中。
- 确保获得有关所有必要请求的数据的可能性。
- 减少数据的冗余和重复。
- 确保数据库完整性
- 数据访问速度优化
要记住的主要事情是你不能建立一个理想的数据库结构，因为。它和您的代码一样，也会不断变化。设计数据库结构时应牢记三点：
- 结构必须足够好。
- 凡事必有其人能看得懂的逻辑。
- 过早的优化是万恶之源。
你不必做出世界上最好的数据库结构。她还是会变的。你的任务是确保在对数据库结构进行 20 次更改后，很容易弄清楚。
很可能在您工作的头几年，没有人会信任您从头开始设计基地。您将对现有架构进行更改。你需要试着了解它是根据什么原则安排的并遵守它们。凭借他们的宪章，他们不会爬进别人的修道院。
除非有必要，否则不要优化数据库。如果表只有几百行，那么 DBMS 很可能会将其保存在内存中并缓存对它的查询。
另一方面，您应该能够将重要请求的工作速度提高数十倍甚至数百倍。如果您知道该怎么做，那就太好了。他们在高中一年级怎么说？“忘掉你在学校学到的一切……”
如果你知道什么是数据库规范化，那么我赶紧取悦你，在你的工作中你很可能会处理反规范化。对于项目的避难所来说，没有什么比数据库的速度更重要了。而且，如果为了加快从数据库中选择数据的速度，您需要将 200（！）个表合并为一个（具有巨大的冗余），您将不得不这样做。
1.2 图书馆设计
让我们深入探讨一下主题领域，并使用像典型图书图书馆一样简单的东西来思考数据库设计。
任何图书馆的主要任务都是图书基金的处理。很容易区分三个主要的系统用户组：读者、图书管理员、管理员。每个活动都显示在用例图中。
现在已经可以区分未来数据库的一些实体和关系：
这种做法，不清楚如何将读者与书联系起来（读者在“发行/接收”关系中没有实体。如果书有几本，那么它可以发行给几个读者。甚至如果一本书被理解为一本，那么在保存到当前读者的书目表中时，将无法获得谁（以及多少次）之前拿过这本书的信息。
解决方案可能是引入一个额外的实体——发行书籍的卡片。将书发给读者时，会制作一张卡片，将书交给读者时，会在上面打上相应的标记。在这些卡片的帮助下，确定每个用户的债务并计算书籍使用的统计数据。读者在预订文献时，也会启动一张卡片，如果在一定时间内，读者没有取走所预订的文献，卡片就会被销毁。读者可以预订的书籍数量是有限制的。
选择文献时，用户可以查看文献目录，并可以按作者、标题、出版年份过滤搜索结果。
可以计算图书馆所有书籍的统计数据，以及给定时间段内书籍的发行数量。您还可以设置执行计算的书籍实例的最小数量。根据这些统计数据，未使用的书籍已从图书馆注销。
可以区分主题领域的以下主要实体：
- 用户（图书馆员和管理员）；
- 读者;
- 阅览室;
- 书;
- 图书发行卡；
- 预订卡。
修改后的数据库ER图如图所示。
根据图 1 所示的用例，数据库应执行以下查询（并非详尽列表）：
- 显示符合指定条件的书籍；
- 显示持有未按时关闭的发书卡的用户（图书管理员正在寻找欠款人）；
- 显示给定用户的借书卡对应的所有未及时关闭的图书（用户来图书馆借新书——你需要查看他是否是借书人并通知他）；
- 删除超过 N 秒前创建的所有预订卡；
- 显示指定用户未关闭的图书预订卡对应的所有图书（读者订购图书并来到图书馆取阅 - 图书管理员需要获得此列表才能将其分发）。
1.3 模式形成
要形成数据模式，您必须首先用实体的详细信息补充 ER 图（对其进行细化）。有时，与此同时，在构建 ER 图时可能会发现错误——在这个任务中，发现这本书需要“以某种方式”与图书馆大厅相连。
这可以通过在书中放置必要的“大厅编号”来完成，但是，使用这种方法，同一本书将不得不在数据库中被描述多次（如果它出现在不同的大厅）。更正确的做法是引入一个额外的实体“book placement”。该图显示了一个添加了实体和道具的 ER 图。
上面的ER图反映了主要的表、关系和属性，在此基础上可以构建数据库模型。ER图没有标准，但是有很多符号（Chen，IDEFIX，Martin等），但是领域模型的标准和符号都找不到。然而，在构建这样的图表的过程中，关键字段（外部和内部）必须突出显示，有时是索引和数据类型。
在这种情况下，在下图中：
- 对于链接，使用 Martin 符号（使用“鱼尾纹”）；
- 表格显示为分为 3 个部分的矩形：
- 表名；
- 内部键（用标记标记）；
- 其余字段，而必填字段则标有标记。
在开发这个模型时，希望将管理员表与图书馆员表连接起来——添加用户表，但是：
- 管理员与特定房间没有关联（您必须在相应字段中填写空值）；
- 这可能会使访问权限的分配变得复杂 - 现在只有数据库管理员（通过特殊的 DBMS 面板工作并且在开发中的系统中没有帐户）可以访问管理员表。但是，在连接表时，用户查询需要访问新表。
在构建此图时，发现并更正了 ER 图中的一个缺陷 - 添加了一张librarians_rooms将图书管理员和大厅联合起来的表格。这是必要的，因为一个图书馆员可以在几个房间工作，但几个图书馆员可以在同一个房间工作。
在设计数据库的时候，你至少应该能像上面的例子那样推理。如果您认为自己成功了，那么让我们走得更远：甚至更多的理论。