翻译的数据库设计资料.doc

数据库设计 作者 Philipp K. Janert IEEE.org 翻译 王保荣 Coship 校对 耿春霞 Coship 1．键和数据类型 在该系列讲座中，我将介绍一些数据库设计的最实用的技巧。在第一部分，我要讨论简单数据类型、复合数据类型以及主键和外键等等。 键及分类 关系数据库储存两种信息——数据和通道。数据包括客户名、库存号、注释等业务信息。 通道指主键和外键，它们帮助查询数据记录并把数据表关联起来构成关系数据库。 基本管道 管道应该透明以便建模。许多人在建立数据库时不分数据和管道的区别。增加一些 管道信息会使数据库便于管理和维护，同时也能够提高数据库的性能。 主键 能够唯一确定记录的字段或字段组合。 每一个表都应有一个主键，可以是一个字段也可以是多个字段的组合，它们的值能唯一地标识表中的每行，以其构成和意义不同，介绍以下术语。 代理键 在表中添加的可以唯一确定每条记录的字段作为主键。在业务上，这个字段没有任何实际意义。 主键必需具备的条件： 不为空 唯一 不能更改 引进代理键的三个原因： 使每一实体具有唯一的表识字段，以区别其他实体。 有利于提高效率和便于数据库维护。 代理键通常是简单的数字字段，简化了主键和外键的构成。 外键 一个表中的字段（属性），是其他表中的主键字。外键的命名遵循 other_table_name_fk。 候选键(candidate key) 在选择采用代理键时，不排除选择业务字段组合，使其能够唯一确定每条记录。这样的业务字段组合就叫候选键。 候选键其值都不为空，并且每一个组合在表中都是唯一的。候选键具有逻辑意义，有利于建模。然而，并不是每一个表都具有候选键。比如，一个表中只有人的姓和名两个字段，若有两个人姓和名都相同，这种情况下，就没有候选键。因为字段组合不能区别两个人。 这里的关键问题是，你强调的是字段组合的唯一性还是关键实体的唯一性，当讨论实体的唯一性时，代理键是正确的选择。 选择键 选择键：可见的标识符，代理键在业务上没有任何逻辑意义，故对数据库外的用户不可见。这样便于DBA在必要时变换代理键。如果因业务需求，应提供给用户一个对某些字段的唯一性标志。该标志应该属于真正的业务数据，应与管道数据区别对待。如多加一个字段VisibleAccountNumber，使之成为可见的标志字段（不为空，唯一），这样就构成了一个选择键。这个字段应便于生成和修改，对用户友好。如，当用户打电话给售后服务人员时，便于记录和对话。 主键是否对应用程序可见还是对用户可见，取决于具体的项目。利用数字型别将数据库记录引入应用程序，应尽量避免耦合。因为数字易于在程序中更改，从而改变所代表的记录。在小型系统中，可考虑用字符串型别。 一个较好的选择是用一个简单的包装实体，虽较负责，但不会与其他界面数据混淆。对业务字段组成的键，需要将其串行化（serializing）。 全局标志（Universally Unique Identifier，UUID） 关系数据库并不需要全局标志。管道对于每一个表都应是唯一的，这一目标可通过串行 化数据类型来实现。 UUID可能会有一些技术问题，为了确保唯一性，所有的UUID必须经由一个中心服务产生，这样导致了可测性（scalability）问题。另一方面，如果不用UUID，用字符串或数字组合代表UUID，会使数据库运行变慢。此外，当用于外键时，复合键增加了数据库的复杂度。尽管面向对象特性要求每一业务实体具有一个键，但没有必要将数据库内部运行器建立于此。 总而言之，我建议将业务数据和管道数据分离。利用UUID违反了这一要求，因为UUID是业务数据。 1.2 数据类型 SQL标准定义了一系列的标准数据类型，绝大部分DB供应商支持这些数据类型的同时，增加了自己独有的类型。没有特别的理由，应回避利用这些非标准的数据类型。 字符串和数字 数字类型：考虑选择足够大的类型以支持业务数据。 字符：在定义字符型字段时，没有必要找到最佳的宽度来容纳所储存的信息。只要大致适合信息宽度即可。定义界个固定宽度，同时赋予别名，如：32bytes (Label), 256 bytes (Note), 和4k (Text)。 尽管有的业务要求限定某些字段宽度的某一具体值，但数据库schema不是最好的地方来体现这一规则。当非法输入或请求达到数据库时已是太晚了，除了拒绝没有别的办法。 用户的数据交换和有效性验证应在业务逻辑层实现，而不是在资源层实现。此外，如果将字符串限定于几个有限的宽度，可以大大简化数据库Schema（DB Schema）。 注：Schema可以理解为表格的表头。 时间和货币 SQL提供了时间