Craft6 数据库设计教程系列——基本概念(关系模型、实体、联系、域和属性).docx

一、关系模型 Relations Model 关系模型定义： 关系模型是采用二维表格结构表达实体类型及实体间联系的数据模型。 关系模型的规则定义了数据可以被表达的方式（数据结构）、数据可以被保护的方式（数据完整性）以及在数据上可以实现的操作（数据操作）。 结构性定义了数据信息的组织方式和表达的方式，即信息使用关系（relations）来表达，关系则由和元（tuple）组成，而元则是由属性和值组成。通俗来讲：“关系”就是二维表格中全部表头和所有数据的集合。“元”就是一列的表头和该列所有数据的集合。“属性”即表头的名称，即字段名。这样就形成现在关系数据库数据表的表达形式了，所以：关系即表示成关系数据库中的“数据表” 数据完整性定义了结构性组件中，关系之间的生成和维持关联性的方法。如：1. 数据有效性。针对字段的值的有效性控制。2. 实体完整性。要求每一个表中的主键字段都不能为空或者重复的值。3. 参照完整性。即将两个表的“元”关联起来的方式。如1对多关联，即在多方的表要创建记录，该列的元的值必须在1方的元中存在。 数据操作分为数据处理和应用处理两种角度。1. 数据处理：通过若干张表的查询和计算的结果形成新表的数据。2. 应用处理：即基于数据表开发的CRUD以及其它复杂的业务功能。二、实体 Entity 实体就是用来存储信息的事物。 在关系数据库中，现实世界的实体以及实体间的各种联系均用关系来表示。 实体对应现实世界的业务，在分析时需要进行识别，分析出实体模型和它们之间的联系。 如电商系统常见的实体模型有销售订单（SalesOrder）、采购订单（BuyOrder）、客户（Customer）、产品（Product）、优惠券（Coupon）、礼品卡（GiftCard）、购物车（ShoppingCart）等等。 这些实体存在若干属性，每一组属性值可以表达一个独立的实体对象。 有些实体非常复杂，可能涉及使用多个关系（多个表）来表达，比如订单，可能包括订单、订单项、发货地址、发票地址、支付方式、订单备注等等。这些信息构成了完整的订单实体，而这些信息每一个又是一个独立的关系（在数据库设计中会被设计为一张独立的表）。 所以这里存在一个聚合的概念，即由多张表聚合成一个业务意义上的实体模型。三、联系 Relationship 指的是实体之间的联系。 同样是使用关系来表示，即每种联系就是一张表。 联系大多数是二元的，即常见的1对1、1对多、多对1、多对多等联系方式。 但也存在三元或多元的联系，比如“顾客从某商铺购买了某个产品”这个关联。（产品和商铺是多对多关联的） 一对多关联最为常见，而且在实践中，对于多对多也会设计为两个一对多联系。四、域 Domain 一个域是一个属性（字段）可能包括的所有有效值的集合。 单纯从数据结构是无法有效的体现该属性在实际业务中的可选值的，比如对于“产品状态”这个属性，可选的状态有：draft=草稿；on_sale=上架；not_on_sell=下架；forbidden=禁售。（或者更多），但这个约束一般通过应用层面来达成，数据表设计时，是声明这个属性的域定义。 域和数据有效性是不同的。数据有效性是针对数据完整性的概念，比如“邮箱”、“电话号码”等字段的格式验证。但如果规定了只能从某个范围内选择电话号码，则这个范围则是域。 在数据库设计中，如果使用PowerDesigner，有专门的Domain功能可供使用。五、属性 Attribute（即数据表的Column） 系统需要保存每个实体的具体信息，这些信息就是实体的属性。 比如对于客户 Customer，有ID、Name、Title、Job、Gender等。 属性一般分为三类： 单值属性。 多值属性：最简单的是字符串类型，值之间通过逗号分隔，如电话号码（允许多个） 派生属性：根据其它属性的值计算出的属性，如年龄可以根据生日。派生属性属于冗余的范畴，但为了查询的方便和效率，一般也进行设计。 在实际设计中，决定是否将一个属性加入到实体需要看业务需要。 比如对于客户实体的“地址”属性。 在电商系统中：一个客户可能需要保存多个地址，而且地址信息比较复杂，包括国家