数据库模型设计
数据库数据模型设计与规范
数据库数据模型设计与规范数据库是组织和存储数据的重要工具，而数据模型则是数据库设计的核心部分。
一个好的数据模型设计可以提高数据库的性能和可扩展性，并确保数据的完整性和一致性。
本文将介绍数据库数据模型设计的原则和规范，并提供一些实用的技巧和建议。
一、概述数据库数据模型是描述数据库中数据结构和关系的图形化表示。
它通过定义实体、属性和关系的方式，帮助我们理解和组织数据。
一个合理的数据模型应该满足以下几个基本要求：1. 数据完整性：确保数据的准确性和一致性，避免数据冗余和不一致的情况。
2. 数据访问性能：优化数据库的读写操作，提高数据库的响应速度。
3. 数据扩展性：便于数据库的升级和扩展，适应业务的变化和发展。
4. 数据安全性：确保数据库的数据不会被非法访问、篡改或丢失。
二、数据模型设计原则在进行数据库数据模型设计时，需要遵循以下几个原则：1. 规范化：通过规范化设计，将数据库中的数据分解成更小的表，减少数据冗余，提高数据的一致性。
2. 实体和属性的定义：确定数据库中的实体和属性，并为它们分配适当的数据类型和长度。
3. 主外键关系：通过定义主外键关系，建立不同表之间的连接，确保数据之间的一致性和完整性。
4. 索引的使用：为数据库中的常用查询字段添加索引，加快查询的速度。
5. 数据安全性：在数据库设计中考虑数据的安全性，包括用户权限管理、数据加密等。
三、数据库数据模型设计规范在实际进行数据库数据模型设计时，还需要遵守一些规范和约定，以确保数据库的可读性和可维护性。
1. 表和字段命名规范：使用有意义的表和字段名称，避免使用过长或过于复杂的名称。
可以使用下划线或驼峰命名法。
2. 主键设计：每个表都应该有一个主键来唯一标识每条记录。
常见的主键设计方式包括自增主键、GUID、业务相关的唯一标识等。
3. 字段类型和长度的选择：根据具体业务需求，选择合适的字段类型和长度。
避免使用过大或过小的字段长度，浪费存储空间或导致数据溢出。
数据库管理中的数据模型设计与分析
数据库管理中的数据模型设计与分析数据模型是数据库中的核心概念，它用于描述数据库中的数据结构、数据属性以及数据之间的联系。
在数据库管理中，数据模型设计与分析是一个关键步骤，它对于业务流程的正确性、数据的一致性以及系统的性能都起着重要的作用。
本文将深入探讨数据库管理中的数据模型设计和分析，并提供一些有效的方法和技巧。
一、数据模型概述数据模型是一种用于表达和组织数据库中信息的方式，常用的数据模型包括层次模型、网络模型、关系模型以及面向对象模型等。
在数据库管理中，关系模型是被广泛应用的，因为它简单、易于理解和使用。
关系模型使用表格、行和列来表示数据，将数据划分为多个实体，实体之间的关系通过关联键来建立。
二、数据模型设计数据模型设计是将现实世界的业务需求转化为关系模型的过程。
在数据模型设计阶段，需要考虑以下几个方面：1. 数据需求分析：在进行数据模型设计之前，首先需要明确业务需求和数据需求。
这包括对数据的基本属性、数据之间的关系以及数据的约束条件进行全面的分析和理解，用于建立关系模型的基础。
2. 概念模型设计：在明确了数据需求之后，可以利用实体关系图（ER图）来表示数据的概念模型。
实体关系图是一种图形化的方法，用于视觉化数据库中的实体、属性和关系。
通过ER图，可以更清晰地了解业务实体之间的关系，包括一对一、一对多和多对多等。
3. 范式设计：范式是关系模型中的规则，用于确保数据库的数据一致性和正规化。
在设计关系模型时，需根据不同的范式进行数据设计。
常用的范式包括第一范式（1NF）、第二范式（2NF）、第三范式（3NF）等。
范式设计可以提高数据库的性能和效率，减少数据冗余和更新异常。
4. 物理模型设计：物理模型是关系模型转化为数据库系统中的数据结构、索引、存储空间以及其他细节等。
在物理模型设计中，需要选择适当的数据类型、优化查询性能、设置合适的索引以及分配存储空间等。
三、数据模型分析数据模型分析是评估和优化数据模型的过程，旨在提高数据库系统的性能和效率。
数据仓库模型的设计
数据仓库模型的设计数据仓库模型的设计大体上可以分为以下三个层面的设计151:.概念模型设计;.逻辑模型设计;.物理模型设计;下面就从这三个层面分别介绍数据仓库模型的设计。
2.5.1概念模型设计进行概念模型设计所要完成的工作是:<1>界定系统边界<2>确定主要的主题域及其内容概念模型设计的成果是，在原有的数据库的基础上建立了一个较为稳固的概念模型。
因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立数据仓库系统的概念模型。
一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。
概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。
1.界定系统的边界数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前:. 要做的决策类型有哪些?. 决策者感兴趣的是什么问题?. 这些问题需要什么样的信息?. 要得到这些信息需要包含原有数据库系统的哪些部分的数据?这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。
因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。
2，确定主要的主题域在这一步中，要确定系统所包含的主题域，然后对每个主题域的内容进行较明确数据仓库建模技术在电信行业中的应用的描述，描述的内容包括:. 主题域的公共码键;. 主题域之间的联系:. 充分代表主题的属性组。
数据库中的数据模型与设计
数据库中的数据模型与设计摘要本文将介绍数据库中的数据模型与设计，包括概念模型、逻辑模型和物理模型，以及如何进行数据库设计。
数据模型是数据库设计的基础，它可以帮助我们理解数据的结构、关系和用途。
1.数据模型的定义数据模型是一种描述系统中数据组织、存储和处理方式的形式化表示。
它是数据库设计的基础，用于描述数据模式和数据结构，以及数据之间的关系。
其中，数据模式是指数据在数据库中的存储方式，包括实体、属性和关系，而数据结构则是指数据的组织方式，包括表、字段和索引等。
数据之间的关系包括一对一、一对多和多对多等。
2.数据模型的分类数据模型可以分为三个层次：概念模型、逻辑模型和物理模型。
其中，概念模型是最高层次的数据模型，用于描述数据的概念和业务规则；逻辑模型是中间层次的数据模型，用于描述数据的结构和关系；而物理模型则是最低层次的模型，用于描述数据在计算机系统中的存储和表示方式。
3.概念模型概念模型是数据库设计的第一步，它用于描述问题域中的概念和业务规则，不涉及到具体的数据库管理系统。
概念模型通常用E-R图表示，其中，E-R图基于实体-关系模型，用于描述实体、属性和关系之间的联系。
实体指问题域中的某个对象，例如学生、教师和课程等；属性指实体所具有的某个特征，例如学生的姓名、年龄和性别等；而关系指实体之间的某种联系，例如学生和课程之间的选课关系等。
4.逻辑模型逻辑模型是在概念模型基础上进一步精细化的数据模型，可以转化为具体的数据库管理系统。
逻辑模型通常用关系模型表示，其中，关系模型基于关系代数和谓词逻辑，用于描述数据的结构和关系。
关系模型由表、字段和索引组成，其中，表用于存储数据，字段用于定义数据的属性，索引用于优化数据的访问。
5.物理模型物理模型是数据库设计的最后一步，用于确定数据在计算机系统中的存储和表示方式。
物理模型通常用DDL语言表示，其中DDL是数据定义语言的缩写，用于定义数据库中的表、字段、索引和约束等。
数据仓库的数据模型设计和数据库系统的数据模型设计有什么不同
数据仓库的数据模型设计和数据库系统的数据模型设计
有什么不同
1.目的和应用：
数据仓库的数据模型设计主要用于支持分析和决策支持系统。
它的目标是将来自多个操作性数据库的数据集成在一个统一的存储中，以便于查询和分析。
数据库系统的数据模型设计主要用于支持业务应用系统的操作和事务处理。
2.数据结构：
3.数据粒度：
4.数据复杂性：
5.数据访问模式：
数据仓库的数据模型设计支持复杂的查询操作，如多维分析和数据挖掘等。
因此，数据仓库的数据模型设计通常需要进行优化，以提高查询性能和响应时间。
数据库系统的数据模型设计则更注重事务处理和并发控制等方面的性能优化。
总结起来，数据仓库的数据模型设计和数据库系统的数据模型设计主要在目的、数据结构、数据粒度、数据复杂性和数据访问模式等方面有所不同。
数据仓库的数据模型设计更注重于支持分析和决策支持系统，采用星型或雪花型的数据结构，关注大量和高层次的数据，需要复杂的数据转换和清洗过程，并进行查询性能优化。
数据库系统的数据模型设计更注重于支持业务应用系统的操作和事务处理，采用关系模型的结构，关注细节
和实时的操作数据，不需要涉及复杂的数据处理过程，并进行事务和并发性能的优化。
数据库数据模型设计方法
数据库数据模型设计方法数据库数据模型是指对数据库中数据的组织和表示方式的规定。
合理的数据模型设计可以提高数据库的性能和可维护性。
在进行数据库数据模型设计时，我们可以采用以下方法：1.需求分析在进行数据模型设计前，首先需要进行需求分析，明确数据库系统所需存储和操作的数据对象。
通过与用户的沟通和分析，确定数据库的功能需求和数据集合。
2.概念设计概念设计是将需求分析得到的概念模型转化为数据库模型的过程。
在进行概念设计时，可以采用E-R模型(Entity-Relationship Model)来描述实体、属性和实体之间的关系。
通过绘制实体关系图，可以可视化地表示数据库中各实体（表）的属性和关系。
3.逻辑设计逻辑设计是指将概念设计的模型转化为特定数据库管理系统（DBMS）支持的数据库模型，如关系模型、层次模型、网络模型等。
其中最为广泛应用的是关系数据库模型。
在逻辑设计过程中，需要定义各个实体的属性和关系、确定实体之间的主外键关系以及选择适当的数据类型和约束。
4.物理设计物理设计是在逻辑设计的基础上，转化为特定的数据库管理系统所支持的物理存储结构和存储方式。
在进行物理设计时，需要考虑数据库的性能和安全性。
可以选择适当的索引策略、分区策略、冗余和一致性控制方式等。
5.性能调优数据模型设计完成后，还需要进行性能调优来提升数据库的查询和操作效率。
可以通过索引优化、查询重写、数据分区等手段来提高数据库的性能。
总结数据库数据模型设计是建立一个高效、可扩展和易维护的数据库的关键。
通过合理的需求分析、概念设计、逻辑设计、物理设计以及性能调优，可以构建出满足各种需求的数据库模型。
同时，不断的优化和维护也是保证数据库性能的重要环节。
数据库模型分析数据库模型的种类特点和设计
数据库模型分析数据库模型的种类特点和设计
1.层次模型：层次模型是数据库中最早出现的模型之一，使用树形结构描述数据的组织关系，层次模型的特点是数据之间存在一对多的关系，一个父节点可以有多个子节点，但一个子节点只能对应一个父节点。
层次模型的设计简单，查询效率高，但不适合表示多对多的关系。
2.网状模型：网状模型通过使用指针来表示数据之间的关系，允许一个子节点对应多个父节点，以及一个父节点对应多个子节点。
网状模型的特点是具有较高的表达能力，能够表示复杂的关系，但设计复杂，难以维护和查询。
5.NoSQL模型：NoSQL模型是一种非关系型数据库模型，主要用于处理大规模、高并发和分布式的数据。
NoSQL模型的特点是没有固定的表结构，可以存储半结构化和非结构化数据，具有高可扩展性和高性能，但牺牲了一致性和事务性。
数据逻辑模型是将实体-关系模型转化为数据库实现的一种模型。
数据逻辑模型包括层次模型、网状模型、关系模型等，用于确定数据库表、列、键、索引、数据类型等细节。
数据库物理模型是在数据逻辑模型的基础上，对数据库的物理存储进行设计。
它主要包括数据存储结构、索引结构、数据分区、数据冗余等方面，用于提高数据库的性能和可靠性。
总的来说，数据库模型是对现实世界进行抽象和组织的一种方式，不同的模型具有不同的特点和适用场景。
在实际应用中，需要根据具体的需求和设计目标选择合适的数据库模型，并进行相应的数据库设计。
数据库模型：分析数据库模型的种类、特点和设计
数据库模型是数据库设计中的核心要素之一，它定义了数据库中数据的组织和结构。
不同的数据库模型适用于不同的应用场景，并具有各自的特点和设计原则。
在本文中，我将介绍数据库模型的种类、特点和设计方法，帮助读者更好地理解和应用数据库模型。
介绍什么是数据库模型数据库模型是对数据库中数据组织和结构的一种抽象表示。
它描述了数据库中的实体、关系、属性之间的对应关系，以及对数据进行存储、检索、修改和删除等操作的规则和约束。
数据库模型是数据库实际设计的基础，决定了数据的可靠性、稳定性和高效性。
数据库模型的重要性数据库模型对数据库的性能、扩展性和易用性有着重要影响。
一个好的数据库模型能够更好地满足应用的需求，提高数据的存储效率和操作效率，同时降低数据冗余和数据不一致性的风险。
因此，选择合适的数据库模型对于数据库设计来说非常重要。
数据库模型的分类数据库模型可以分为以下几种主要类型：层次模型、网状模型、关系模型、面向对象模型、文档模型和键值模型。
接下来，我们分别对这些模型进行详细介绍。
层次模型层次模型是数据库模型的一种最早的形式，它将数据组织成一个树状结构。
层次模型中的数据以父子关系进行组织，每个节点可以有多个子节点，但只能有一个父节点。
这种模型适用于嵌套关系比较简单的数据，例如组织机构、家族关系等。
层次模型的特点是简单直观，易于理解和操作，但对数据的表示能力有一定的限制。
网状模型网状模型是数据库模型的另一种较早期的形式，它将数据组织成一个图状结构。
网状模型中的数据以节点和边的形式表示，节点表示实体，边表示实体之间的关系。
不同于层次模型中只能有一个父节点的限制，网状模型中的节点可以有多个父节点和多个子节点。
这种模型适用于表示复杂的数据关系，例如供应链管理、电力系统等。
网状模型的特点是较好地解决了层次模型的限制，但对于数据操作的复杂性增加了一定的挑战。
关系模型关系模型是当前应用最广泛的数据库模型，它将数据以二维表的形式进行组织。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据库模型设计连载(1～6)最近一直有个愿望：希望把自己所从事的数据库模型设计方面的工作经验和想法付诸文字，算是对此前工作的一个总结，今天终于开始了万里长征的第一步。
在正式开始之前，我先向大家介绍两本书——《数据模型资源手册卷一》、《数据模型资源手册卷二》，国内有机械工业出版社出版的中文译本，很多同行可能都已看过，我本人也看过。
看过之后深受启发，同时也感到两点美中不足：1、这两部书的成书时间较早，且原作内容是基于美国企业的业务需求而建，有些最新的行业信息及“中国特色”的东西没有收录。
2、书中原作者所使用的设计符号是作者专用的，而对于目前国内数据库模型设计的专业人员来说，ER图或者PowerDesigner中的CDM、PDM图更容易理解和沟通。
所以，在今后一段时间，我希望每天能抽出2个小时，结合上面提到的两部书的内容、PowerDesigner 的PDM模型以及本人相关工作经验，在这里做一个数据库模型设计的连载。
本连载计划用120天的时间撰写完毕。
这么做的目的，一方面是将头脑里的无形信息落实到文字上、有效避免遗忘，另一方面更加希望抛砖引玉，在与同行们沟通交流之后对我自己也是个促进和提高，对其他同行也起到各借鉴的作用。
望广大同行们不吝赐教，大家一起来推动数据库模型设计的资源共享计划。
什么是模式？连载之1原创：胖子刘（转载请注明出处及作者，谢谢。
）什么是模式？简单说来，模式类似于定式，就是遇到反复出现的同一问题时所固定使用的解决方案。
下围棋的朋友可能对“定式”这个词比较熟悉，定式包含着下棋时做遇到的各种情况下的下法、急所、手筋及死活等基本原理，例如星定式、小目定式、边定式等等，定式懂的越多，围棋下的越好。
那么是不是数据库设计模式懂得越多，设计工作越完美呢？理论上是这样，但是在我这里，各位朋友所能看到的数据库设计模式只有四种。
为什么只有四种而不是更多？不时有那句话吗：“浓缩的都是精华”！在后面的文章中，您会陆续看到浩浩荡荡的设计实例连篇累牍，却都是利用这四种基本模式设计出来的。
《易传·系辞》曰：“易有太极，是生两仪，两仪生四象，四象生八卦。
”老子在《道德经》中也说：“道生一，一生二，二生三，三生万物。
”设计模式不必多，只要掌握其中关键的几个，再结合实际的业务需求，一个完整的数据库模型就可以推导出来。
下面让我们来逐一介绍这四种主要设计模式——（一）主扩展模式连载之2原创：胖子刘（转载请注明出处及作者，谢谢。
）（一）主扩展模式主扩展模式，通常用来将几个相似的对象的共有属性抽取出来，形成一个“公共属性表”；其余属性则分别形成“专有属性表”，且“公共属性表”与“专有属性表”都是“一对一”的关系。
“专有属性表”可以看作是对“公共属性表”的扩展，两者合在一起就是对一个特定对象的完整描述，故此得名“主扩展模式”。
举例如下（注：这个例子已经作了相当程度的简化，仅仅是用来帮助大家理解“主扩展模式”这个概念来使用的，请大家注意）。
假设某公司包括如下6种类型的工作人员：采购员、营销员、库房管理员、收银员、财务人员和咨询专家，采用主扩展模式进行设计，如下图所示。
无论哪种类型的工作人员，都要访问公司的办公软件，所以都有“登陆代码”和“登录密码”；并且作为一般属性，“姓名”、“性别”、“身份证号”、“入职时间”、“离职时间”等属性，都与个人所从事的工作岗位无关，所以可以抽取出来作为公共属性，创建“公司员工”表。
很显然，公司委派员工采购哪些商品是“采购员”的专有属性，这是由公司的实际业务特点决定的。
换句话说，公司不可能把采购任务放到“营销员”身上，也不可能放到“库房管理员”身上，“采购商品”属性就是“采购员”的专用属性。
“采购员”表的主键与“公司员工”表的主键是相同的，包括字段名称和字段的实际取值；“采购员”表的主键同时是“公司员工”表主键的外键。
在PDM图里可以看到“采购员”表中的“员工ID”字段后面有一个“<pk,fk>”标记，这个标记就说明“员工ID”字段既是“采购员”表的主键，同时也是该表的外键。
“公司员工”表是主表，“采购员”表是扩展表，二者是“一对一”的关系，两个表的字段合起来就是对“采购员”这个对象的完整说明。
同理，“公司员工”表和其他5个表之间也都分别构成了“一对一”的关系。
对于主表来说，从表既可以没有记录，也可以有唯一一条记录来对主表进行扩展说明，这就是“主扩展模式”。
（二）主从模式连载之3原创：胖子刘（转载请注明出处及作者，谢谢。
）（二）主从模式主从模式，是数据库设计模式中最常见、也是大家日常设计工作中用的最多的一种模式，它描述了两个表之间的主从关系，是典型的“一对多”关系。
举例如下（注：这个例子已经作了相当程度的简化，仅仅是用来帮助大家理解“主从模式”这个概念来使用的，请大家注意）。
比如论坛程序。
一个论坛通常都会有若干“板块”，在每个板块里面，大家可以发布很多的新帖。
这时候“板块”和“发帖”就是主从模式，主表是“板块”，从表是“发帖”，二者是“一对多”的关系。
多个潜水员也可以对感兴趣的同一份发帖进行回复，以表达各自的意见，这时候，一个“发帖”就有了多份“回复”，又构成了一个“主从模式”。
（三）名值模式连载之4原创：胖子刘（转载请注明出处及作者，谢谢。
）（三）名值模式名值模式，通常用来描述在系统设计阶段不能完全确定属性的对象，这些对象的属性在系统运行时会有很大的变更，或者是多个对象之间的属性存在很大的差异。
举例如下（注：这个例子已经作了相当程度的简化，仅仅是用来帮助大家理解“名值模式”这个概念来使用的，请大家注意）。
1.使用名值模式进行设计时，如果对“其他属性”仅作浏览保存、不作其它任何特殊处理，则通常会设计一个“属性模板”表，该表的数据记录在系统运行时动态维护。
系统运行时，如需维护“产品其他属性”，可先从“属性模板”中选择一个属性名称，然后填写“属性值”保存，系统会将对应的产品ID、属性模板ID及刚刚填写的“属性值”一起保存在“产品其他属性”里，这样就完成了相关设置。
无论产品的其他属性需求发生怎样的变化、怎样增删改属性，都可以在运行时实现，而不必修改数据库设计和程序代码。
（见下图）2.使用名值模式进行设计时，如果对“其他属性”有特殊处理，比如统计汇总，那么这个属性名称需要在程序代码中作“硬编码”，即该属性名称需要在程序代码中有所体现，此时可以在“产品其他属性”表中直接记录“属性名称”，不再需要“属性模板”表。
系统运行时，如需维护“产品其他属性”，程序直接列出“属性名称”，然后填写“属性值”保存，系统会将对应的产品ID、属性名称及刚刚填写的“属性值”一起保存在“产品其他属性”里，这样就完成了相关设置。
以后如果需求发生变更，则只需修改相应的程序代码即可，不必修改数据库设计。
（见下图）（四）多对多模式连载之5原创：胖子刘（转载请注明出处及作者，谢谢。
）（四）多对多模式多对多模式，也是比较常见的一种数据库设计模式，它所描述的两个对象不分主次、地位对等、互为一对多的关系。
对于A表来说，一条记录对应着B表的多条记录，反过来对于B表来说，一条记录也对应着A表的多条记录，这种情况就是“多对多模式”。
“多对多模式”需要在A表和B表之间有一个关联表，这个关联表也是“多对多模式”的核心所在。
根据关联表是否有独立的业务处理需求，可将其划分为两种细分情况。
1.关联表有独立的业务处理需求。
举例如下（注：这个例子已经作了相当程度的简化，仅仅是用来帮助大家理解“多对多模式”这个概念来使用的，请大家注意）。
比如网上书店，通常都会有“书目信息”和“批发单”。
一条“书目信息”面对不同的购买客户、可以存在多张“批发单”，反过来，一张“批发单”也可以批发多条书目，这就是多对多模式。
中间的“批发单明细”表就是两者的关联表，具备独立的业务处理需求，是一个业务实体对象，因此它具备一些特有的属性，比如针对每一条明细记录而言的“累计退货次数”、“累计退货数量”、“累计结算次数”、“累计结算数量”；由于批发单明细在数据产生后已经打印出纸质清单提供给客户，因此在“批发单明细”表里对纸质清单中打印的书目信息属性作了冗余（逆标准化），这样在将来即使修改了“书目信息”表中的属性，也不会影响跟客户核对批发单明细，不会影响未来的财务结算业务。
2.关联表没有独立的业务处理需求举例如下（注：这个例子已经作了相当程度的简化，仅仅是用来帮助大家理解“多对多模式”这个概念来使用的，请大家注意）。
比如用户与角色之间的关系，一般系统在做权限控制方面的程序时都会涉及到“系统用户表”和“系统角色表”。
一个用户可以从属于多个角色，反过来一个角色里面也可以包含多个用户，两者也是典型的“多对多关系”。
其中的关联表“用户角色关联表”在绝大多数情况下都是仅仅用作表示用户与角色之间的关联关系，本身不具备独立的业务处理需求，所以也就没有什么特殊的属性。
（五）使用上述四种模式的一般原则连载之6原创：胖子刘（转载请注明出处及作者，谢谢。
）（五）使用上述四种模式的一般原则1.什么时候用“主扩展模式”？对象的个数不多；各个对象之间的属性有一定差别；各个对象的属性在数据库设计阶段能够完全确定；各个扩展对象有独立的、相对比较复杂的业务处理需求，此时用“主扩展模式”。
将各个对象的共有属性抽取出来设计为“主表”，将各个对象的剩余属性分别设计为相应的“扩展表”，“主表”与各个“扩展表”分别建立一对一的关系。
2.什么时候用“主从模式”？对象的个数较多且不固定；各个对象之间的属性几乎没有差异；对象的属性在数据库设计阶段能够完全确定；各个对象没有独立的业务处理需求，此时用“主从模式”。
将各个对象设计为“从表”的记录，与“主表”对象建立一对多的关系。
3.什么时候用“名值模式”？对象的个数极多；各个对象之间的属性有较大差异；对象属性在数据库设计阶段不能确定，或者在系统运行时有较大变更；各个对象没有相互独立的业务处理需求，此时用“名值模式”。
4.什么时候用“多对多模式”？两个对象之间互为一对多关系，则使用“多对多模式”。