数据库建模
数据库建模技术方案
数据库建模技术方案1.引言1.1 概述数据库建模技术是指通过对现实世界中的数据进行抽象和建模，设计出数据库的结构和关系，以实现数据的存储、管理和处理。
在信息化时代，数据库建模技术成为了一项基础而重要的工作，对于实现企业数据化管理和决策支持具有重要意义。
本文将从数据库建模技术的概述、方案以及未来发展等方面进行详细介绍和分析。
在进行数据库建模时，需考虑到数据的实体、属性、关系等因素，以及数据之间的联系和约束关系。
通过对现实世界的实体进行建模，我们可以将数据划分为不同的实体集合，并定义实体的属性和关系。
通过这样的抽象和建模工作，数据的结构和关系得以清晰地展示出来，为实现高效的数据管理和应用提供了基础。
数据库建模技术方案的选择与设计是数据库建模过程中的重要环节。
不同的数据库建模技术方案适用于不同的场景和需求。
常见的数据库建模技术方案包括关系模型、层次模型、网络模型等。
关系模型是最为常见和广泛应用的数据库建模技术方案，通过表格的形式展现数据之间的关系，具有较好的可扩展性和灵活性。
而层次模型和网络模型则适用于较为特殊的数据结构和应用场景。
在未来，随着大数据、云计算和人工智能等技术的快速发展，数据库建模技术也将不断创新和演进。
比如，随着数据量的增大，分布式数据库建模技术将得到更广泛的应用；随着数据的多样化和复杂化，图数据库建模技术将具备更大的发展空间。
此外，数据库建模技术还应与其他技术进行整合，如面向对象技术、数据挖掘技术等，以提高数据库的性能和功能。
综上所述，数据库建模技术是现代信息管理的重要组成部分，通过对现实世界的数据进行抽象和建模，实现数据的存储、管理和处理。
不同的数据库建模技术方案适用于不同的场景和需求，而未来的发展则需要与其他相关技术相结合。
对于企业和个人而言，熟练掌握和应用数据库建模技术，将有助于提高数据管理和决策支持的效率和质量。
文章结构部分的内容可以包括以下几个方面：1. 文章主题：介绍文章的主要内容和讨论的问题，确保读者能够在阅读前了解文章的目的和意义。
数据库建模与实现过程
数据库建模与实现过程随着信息技术的不断发展，数据的处理和管理已经成为现代社会中不可或缺的一部分。
而数据库作为一种高效的数据管理工具，已经被广泛应用于各个领域。
数据库的建模与实现过程是数据库开发的关键环节，本文将对此进行详细介绍。
一、数据库建模数据库建模是指根据实际需求，将数据转化为逻辑模型的过程。
数据库建模主要包括以下几个步骤：1.需求分析需求分析是数据库建模的第一步，它是确定数据库范围、功能和性能的重要环节。
在需求分析中，需要考虑以下几个方面：（1）数据来源：确定数据库中所需的数据，包括数据的类型、数量和格式等。
（2）数据存储：确定数据存储的方式，包括数据的存储位置、存储方式、存储容量等。
（3）数据访问：确定数据的访问方式，包括数据的查询、修改、删除等。
（4）数据安全：确定数据的安全性要求，包括数据的备份、恢复、加密等。
2.概念设计概念设计是根据需求分析结果，将数据转化为概念模型的过程。
概念设计主要包括以下几个步骤：（1）实体识别：识别数据中的实体，即数据中具有独立存在意义的对象。
（2）属性识别：确定实体的属性，即实体具有的特征。
（3）关系建立：确定实体之间的关系，包括一对一、一对多、多对多等关系。
（4）概念模型：将实体、属性和关系等元素组合成概念模型，以图形方式表示。
3.逻辑设计逻辑设计是在概念模型基础上，将概念模型转化为逻辑模型的过程。
逻辑设计主要包括以下几个步骤：（1）关系模式：将概念模型中的实体、属性和关系映射为关系模式，即数据表。
（2）主键和外键：确定每个数据表的主键和外键。
（3）规范化：对数据表进行规范化，以消除冗余数据和数据依赖等问题。
（4）逻辑模型：将关系模式、主键和外键等元素组合成逻辑模型，以图形方式表示。
二、数据库实现数据库实现是指根据逻辑模型，将数据库建立起来的过程。
数据库实现主要包括以下几个步骤：1.数据库管理系统选择数据库管理系统是实现数据库的关键工具，根据实际需求选择合适的数据库管理系统非常重要。
数据库建模与框架结构搭建
数据库建模与框架结构搭建数据库建模和框架结构搭建是软件开发中非常重要的一部分。
通过合理的数据库建模和框架结构搭建，可以提高系统的性能、可维护性和可扩展性。
本文将介绍数据库建模和框架结构搭建的基本概念和方法。
第一部分：数据库建模数据库建模是指将现实世界的实体和关系转化为数据库中的表和关系的过程。
在进行数据库建模时，首先需要确定系统中的实体和它们之间的关系。
然后根据这些实体和关系来设计数据库中的表和关系。
数据库建模的核心是实体关系模型（ER模型）。
ER模型是一种用于表示实体和实体之间关系的图形化工具。
在ER模型中，实体用矩形表示，关系用菱形表示。
实体和关系之间用线连接，表示它们之间的关系。
在进行数据库建模时，需要注意以下几点：1. 确定实体和关系：在确定实体和关系时，需要考虑系统的需求和业务逻辑。
要尽量简化模型，避免冗余和重复的信息。
2. 设计表和属性：根据实体和关系，设计数据库中的表和属性。
每个实体对应一个表，每个属性对应表中的一个字段。
3. 定义主键和外键：在设计表时，需要为每个表定义主键和外键。
主键用于唯一标识表中的记录，外键用于建立不同表之间的关系。
4. 规范化：规范化是指将数据库中的表和关系按照一定的规则进行优化的过程。
通过规范化可以减少冗余和重复的信息，提高数据库的性能和可维护性。
第二部分：框架结构搭建框架结构搭建是指在软件开发过程中，将系统划分为不同的模块和层次，然后将这些模块和层次组织起来，形成一个完整的框架结构。
在进行框架结构搭建时，需要注意以下几点：1. 划分模块和层次：根据系统的需求和功能，将系统划分为不同的模块和层次。
每个模块和层次都有特定的功能和责任。
2. 定义接口和接口规范：在每个模块和层次之间定义接口和接口规范。
接口定义了模块和层次之间的通信方式和数据传输方式。
3. 实现模块和层次：根据定义的接口和接口规范，实现每个模块和层次。
每个模块和层次都有特定的功能和实现方式。
4. 测试和调试：在完成模块和层次的实现后，进行测试和调试。
数据仓库建模
数据仓库建模引言概述：数据仓库建模是指在数据仓库设计和构建过程中，对数据进行组织、整理和优化，以便于数据分析和决策支持。
数据仓库建模的目标是提供一个统一、一致、可靠的数据源，帮助企业进行全面的数据分析和决策。
正文内容：一、数据仓库建模的基本概念1.1 数据仓库数据仓库是指将来自不同数据源、不同业务系统的数据进行集成、整理和存储的一个中心化的数据存储库。
数据仓库具有面向主题、集成性、稳定性和可查询性等特点，可以支持企业的决策分析需求。
1.2 数据仓库建模数据仓库建模是指对数据仓库中的数据进行组织和优化的过程。
它包括对数据进行抽取、转换和加载（ETL），以及对数据进行维度建模和事实建模等步骤。
数据仓库建模的目标是提供一个可靠、高效的数据结构，以支持数据仓库的查询和分析。
1.3 维度建模和事实建模维度建模是指对数据仓库中的维度进行建模和设计。
维度是描述业务过程的属性，如时间、地点、产品等。
维度建模通过定义维度表和维度属性，将维度的层次结构和关系进行建模，以支持多维分析和查询。
事实建模是指对数据仓库中的事实进行建模和设计。
事实是描述业务过程中的事件或度量，如销售额、库存量等。
事实建模通过定义事实表和事实属性，将事实的度量和关系进行建模，以支持数据仓库的查询和分析。
二、数据仓库建模的步骤2.1 数据需求分析在数据仓库建模过程中，首先需要进行数据需求分析，明确业务用户的数据分析和查询需求。
通过与业务用户的沟通和需求调研，确定数据仓库的主题域和维度、事实的粒度，以及数据仓库的查询和分析要求。
2.2 ETL过程ETL（抽取、转换和加载）是数据仓库建模的重要步骤。
在ETL过程中，需要从不同的数据源中抽取数据，并进行数据清洗、转换和集成，以满足数据仓库的数据质量和一致性要求。
最后，将经过处理的数据加载到数据仓库中。
2.3 维度建模维度建模是数据仓库建模的核心环节。
在维度建模过程中，需要定义维度表和维度属性，并建立维度之间的关系和层次结构。
数据库建模
软件工程环境综合实践结业论文—数据建模1.1数据建模的基本概念在设计数据库时，对现实世界进行分析、抽象、并从中找出内在联系，进而确定数据库的结构，这一过程就称为数据库建模。
数据建模中的三种模型的简介a）概念模型把现实世界中的客观对象抽象为某一种信息结构，这种信息结构并不依赖于具体的计算机系统，不是某一个数据库管理系统①BMS）支持的数据模型，而是概念级的模型，成为概念模型。
b）逻辑模型逻辑模型是对概念模型的扩展。
不仅定义了描述概念模型中对象的相关属性，而且定义了对象之间的逻辑关系，比如：聚合、扩展。
在数据仓库中，它关联着逻辑模型和物理模型两方。
目前最流行就是关系模型也就是对应的关系数据库。
常见的实体联系有：一对一联系，一对多联系，多对多联系。
c）物理模型物理模型定义了数据的物理存储方式。
通常是我们定义的一种数据库。
如关系数据库中的一些对象为表、视图、字段、数据类型、长度、主键、外键、索引、约束、是否可为空、默认值。
1.2MDA转化模型驱动架构（MDA ）的模型转换提供了一个完全可配置的方式将一个模型中的元素和模型片段从一个域转换到另一个域。
这通常涉及到平台无关模型（PIM ）元素转换成指定平台的模型（PSM ）的元素。
从单一的、平台独立的元素到可以负责创建跨多个域的多个平台相关的元素。
也就是说从概念模型可以转化成任何语言的逻辑模型，没有平台的限制，例如：java 、C++、c#等等，数据库建模的时候我们可以给它转化成具体的数据库管理系统。
a ）定义配置转换EA 中提供了MDA 转换模板，打开EA 工具下的Tools 目录下的MDATransformationTemplates,得到下图：本文讲的是数据建模，因此我们选择DDL 语言，在DDL 转换中主要是将逻辑图中的类转化为物理存储系统中的表：比讣'=n-1 Sif c2fl5->Sttre'3type==,'enuncr-3ti[in"S2 KendTeflplafte-S46^STRAMSF(MR_llEFffiEfiKEC labile")(7STRAHSWH-CURfliEhlT ("langu^e J FtEtMjrjw”E l-3nguagE=£qt£^enQp-tI>Ef-9u]LtDat-ab4HseKqt!K9Klijst -"At±ribute'jEepHratnr-"\n"直indent-""S IB Slf e-JetiTypt !-4AssociBtian-K1214 15 16 17 12心U KliTt="Comectar *辭亡TP将类中Attribute 转换为表的列:DDL 尸IM ..L 初时氓赶陆舌Marr 亡耳■占g 吾|0»^紅S H OKS 0M 夢哥 daaeinerTace — 哉沁j 亡5 Lrk&d 否Lr^ed Base 否brtodClflEhlprf-SC?!S Oparatis 舌 Pjramder 否 Comector 習 氐供僧S饬—:;i 占•，叶PirirtaryKey naiE=^tX%C.CWVERT_IWE.(claj-sMane t ，"F B ^CH I 匚ore"j."CaiEl 匚Bie type-®qtSL®C.OMVEHT_TypEi ；genOptlDefaultl>al3ba5t J "Inttgsr ')K¥qtf将类中的Connector创建为表的外键:在DDL转换中，主要是上面三种的转换，对于Operation、Parameter等都没有定义。
数据库建模步骤
数据库建模步骤嘿，朋友们！今天咱就来讲讲数据库建模那些事儿。
你想想看，数据库就像是一个超级大的仓库，里面要放好多好多东西。
那怎么把这些东西放得井井有条呢，这可就得好好规划一下啦，就像你收拾自己的房间一样。
首先呢，咱得搞清楚要存些啥东西，这就是需求分析啦。
就好比你要决定把哪些玩具、哪些书放进你的小柜子里。
这一步可重要啦，要是没搞清楚，后面不就乱套了嘛！然后呢，根据这些需求，开始设计概念模型咯。
这就像是给这个大仓库画个设计图，大概规划出哪里放什么。
比如说，这一块专门放电子产品，那一块专门放文具啥的。
接下来呀，就到了逻辑模型啦。
这就好比把设计图进一步细化，变成具体的房间布局啦。
要确定好每个区域怎么划分，用什么方式来存放东西。
再之后呢，就是物理模型啦。
这可就相当于真的开始打造这个仓库啦，用什么材料呀，怎么搭建呀，都得想好。
数据库建好了，可还没完事呢！还得经常去维护它，就像你得时不时打扫一下房间，整理整理东西。
要是东西放乱了，找起来不就麻烦啦！咱说这数据库建模，不就跟搭积木似的嘛。
一块一块的，得精心设计、仔细摆放，才能搭出漂亮的城堡来呀。
要是随随便便弄，那最后不就成了一堆烂摊子嘛。
你说要是没做好前面的步骤，到后面发现问题了，那得多麻烦呀，就跟盖房子盖到一半发现设计有问题似的，那不得重新来过嘛。
所以啊，每个步骤都得认认真真去做呀。
而且哦，这数据库建模可不是一次性的工作，随着时间变化，需求也可能会变呀。
那咱就得跟着变，就像你的喜好会变，房间的布置也得跟着变一样。
总之呢，数据库建模这事儿，看着好像挺复杂，其实只要一步一步慢慢来，就肯定能做好。
就像走路一样，一步一步走稳了，总能走到目的地。
大家可别嫌麻烦，好好对待这个大工程，以后用起来就知道有多方便啦！这就是我对数据库建模的理解，大家觉得咋样呢？原创不易，请尊重原创，谢谢!。
4种数据仓库建模方法
引言概述在数字化时代，数据成为企业运营和决策的重要驱动力。
为了更好地管理和利用企业数据，很多企业采用数据仓库来集成和存储数据。
数据仓库建模是数据仓库设计的核心环节，它决定了数据在仓库中的组织结构和查询方式。
本文将介绍四种常见的数据仓库建模方法，包括维度建模、实体关系模型、标准化模型以及主题建模。
维度建模维度建模是一种以事实表和维度表作为核心的建模方法。
事实表是存储数值型数据的表，维度表则存储描述性属性的表。
在维度建模中，事实表和维度表通过共享主键来建立关联。
小点详细阐述：1.事实表的设计：事实表应选择合适的粒度，并包含与业务流程相关的度量。
例如，销售事实表可以包含销售额、销售数量等度量。
2.维度表的设计：维度表应包含与业务流程相关的描述性属性，例如时间、产品、地理位置等。
维度应具有层次结构，以便支持多维分析。
3.关系型数据库实现：维度建模通常使用关系型数据库来实现，它通过表和关联键来表示维度和事实之间的关系。
实体关系模型实体关系模型是一种基于关系代数和数据库范式的建模方法。
它通过实体、属性和关系来描述数据的结构。
实体关系模型适用于较复杂的数据仓库场景，其中数据具有多层级和复杂的关系。
小点详细阐述：1.实体的建模：实体是数据仓库中的核心对象，它代表了业务流程中的实际对象。
实体的属性描述了实体的特征。
2.关系的建模：关系描述了实体间的关联和依赖关系。
在实体关系模型中，关系通过外键建立。
3.数据库范式：实体关系模型追求高度的数据规范化，以减少数据冗余和不一致性。
标准化模型标准化模型是一种以消除冗余数据为核心的建模方法。
在标准化模型中，数据被拆分为多个表，并通过关系建立关联。
小点详细阐述：1.数据拆分：标准化模型通过将数据拆分为多个表，将重复的数据存储在一个地方，并通过外键建立关联。
2.数据插入和查询：标准化模型在数据插入和查询时需要进行多表关联操作，对性能有一定影响。
3.适用场景：标准化模型适用于事务性场景，如订单管理、库存管理等。
数据仓库建模方法总结
数据仓库建模方法总结数据仓库建模是数据仓库构建过程中的重要环节，它决定了数据仓库的数据结构和查询性能。
本文将总结几种常见的数据仓库建模方法，包括维度建模、事实建模和标准化建模，并比较它们的优缺点。
1. 维度建模维度建模是一种常见的数据仓库建模方法，它基于维度表和事实表的概念。
维度表包含描述业务过程的属性，如时间、地点、产品等，而事实表包含与业务过程相关的度量。
维度表和事实表通过共同的键连接起来，形成星型或雪花型的模型。
优点：1) 简单直观：维度建模易于理解和使用，可以快速设计和构建数据仓库。
2) 查询性能高：维度建模的星型结构简化了查询的关联操作，提高了查询性能。
缺点：1) 一对一关系：维度表和事实表之间是一对多的关系，无法处理多对多的关系。
2) 数据冗余：维度表中的属性可能存在冗余，造成数据冗余和一致性问题。
2. 事实建模事实建模是基于主题的数据仓库建模方法，它以业务过程为核心构建事实表，包括维度键和度量。
事实表记录了业务过程发生的事实信息，维度键用于连接事实表和维度表，度量用于度量业务过程的指标。
优点：1) 灵活性高：事实建模能够适应复杂的业务逻辑和多对多的关系。
2) 数据粒度控制：事实表可以根据需要控制数据的粒度，提供灵活的查询和分析能力。
缺点：1) 设计复杂：事实建模的设计复杂度较高，需要考虑多对多的关系和度量的粒度控制。
2) 查询性能相对低：事实建模需要进行多表关联操作，查询性能相对较低。
3. 标准化建模标准化建模是一种将数据仓库模型与关系数据库模型类似的建模方法。
它将数据存储在标准化的表中，通过复杂的关联操作来查询和分析数据。
标准化建模与维度建模和事实建模相比，更适用于小型数据仓库和查询较少的情况。
优点：1) 数据一致性：标准化建模减少了数据冗余，提高了数据一致性。
2) 灵活可扩展：标准化建模可以适应不同的查询需求，支持灵活的查询和分析。
缺点：1) 查询复杂：标准化建模需要进行多表关联和聚合操作，查询复杂度较高。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Stars
Contracts
Movies
Studios
一个制片公司与一位特定的影星签约来演一部特定的电影
联系中的角色
实体集在联系中的作用
参与联系的实体集互异 只标注联系名 同一实体集在一个联系中多次出现 标注联系名及角色名
Original
Stars
Movies
Sequel-of
对象某方面的特征，属性就是数据 只由基本数据类型构成 属性的类型，不能是类、也不能从类中构造
Interface Movie { //Movie Class 的ODL说明
attribute string title; attribute integer year; attribute integer length; attribute enum Film { color, blackAndWhite } filmType; };
对象标识 — OID
对象与对象的区别
类
具有相同特性的对象归为一类 对象的归并必须有意义 属于同一类的对象其特性必须相同
面向对象的设计
对象的三个特性
属性：特性 联系：引用 方法：函数
接口说明
interface < 名字 > { < 特性表 > }
属性
Interface Star { attribute string name; attribute Struct Addr { string street,st构类型
联系
对象的引用 对象的关联 对象集合的引用（1:N）
Relationship Set < Star > stars; 单一对象集合的引用（1:1） Relationship Star starOf;
子类继承其超类的所有特性 属性 联系
Interface Cartoon : Movie { relationship set < Star > voices; }
ODL中的多重继承
类的层次 一个类可以有多个超类
Interface MurderMystery : Movie{ attribute string weapon; }
数据库的设计步骤
OODBMS ODL 想法 需求 关系 RDBMS
E/R
ODL
对象定义语言
Object Definition Language 以面向对象的观点、方法，说明数据库的概 念结构 可方便地直接转换成 OODBMS 的说明 经过努力，可以转换成 RDBMS 的说明
面向对象的设计
ODL中的类型 基本类型
原子类型 接口类型
结构类型，可由以下类型组合而成 集合
无重复，次序无关
包
可重复，次序无关
列表
可重复，次序相关
数组 结构
实体联系图（E/R）
用图形的方法，描述实体及实体间的联系 世界由一组称作实体的基本对象及这些对象间
参照完整性约束 要求由某个对象引用的值在数据库中确实存
在 参照与被参照、引用与被引用 参照完整性约束的操作（各产品不同）
禁止删除被引用的对象 级联删除 / 修改
E/R图中参照完整性的表示
Movies
Owns
Studios
弱实体集
弱实体集的属性不足以形成主码 有主码的实体集称为强实体集 弱实体集只有作为一对多联系的一部分（多）
title
year
name
address
Movies
Stars-in
Stars
lenght
filmType
E/R联系的多重性
N与1的表示
Movies
Stars-in
Stars
Studios
Runs
Presidents
Movies
Owns
Studios
联系的多向性
E/R图能方便地描述两个以上实体集间的联系
数据库建模
Database Modeling
重庆
数据库的设计步骤
需求收集和分析
设计概念结构 设计逻辑结构
设计物理结构
物理实现
数据库的设计步骤
需求收集和分析
用户关心什么 用户要什么结果
设计概念结构
设计逻辑结构 设计物理结构 物理实现
数据库的设计步骤
…… N relationship Set <Star> stars inverse Star :: staredIn; relationship Studio ownedBy N inverse Studio :: owns; }; Interface Star{ …… N relationship Set <Moive> staredIn inverse Moive :: stars; }; Interface Studio{ …… 1 relationship Set <Moive> owns inverse Moive :: ownedBy; };
联系的多重性
N:N
在联系中，每个C都和D的集合有关，而在反向联 系中，每个D都和C的集合有关
N:1
在联系中，每个C都和唯一的D有关，而在反向联 系中，每个D都和C的集合有关
1:1
在联系中，每个C都和唯一的D有关，而在反向联 系中，每个D都和唯一的C有关
Interface Moive{
需求收集和分析
设计概念结构 存什么 关系（联系）如何 ODL或E/R图，是各种数据模型的共同基础 设计逻辑结构
设计物理结构
物理实现
数据库的设计步骤
需求收集和分析
设计概念结构 设计逻辑结构 用什么数据模型 数据库的模式（database schema） 用户子模式
的联系组成 元素
实体（Entity） 客观存在并可相互区别的事件或物体 对应于ODL中的对象 实体集（Entity Set） 同类（具有相同类型、相同性质）实体的集合 对应于ODL中的类 用矩形表示
实体联系图（E/R）
元素
属性（Attribute） 实体所具有的某一特性 用与实体集相连的椭圆表示 联系（Relationship） 实体集之间的关联 可涉及多个实体集 可表示双向的联系 用与相应的实体集相连的菱形表示
候选码 其任意真子集都不为超码的超码 一个类（或实体集）中可能有多个候选码
主码 从候选码中选取的一个，一个类（实体集）中只有 一个主码 E / R图中只能表示主码：主码属性名加上下划线
单值约束 要求某个角色的值是唯一的，如键码 当一个属性为单值时 可以要求该属性值存在（not null） 可以允许该属性值任选（null） 构成键码的属性，必须有值存在（not null）
Movies
Sequel Studio of star
Contracts
Studios Producing studio
联系中的属性
联系中可以包含属性 由联系而产生的属性
可为由联系产生的属性建立实体集
salary
Stars
Contracts
Movies
Studios
将多向联系转换成二元联系
键码 在类的范围内唯一标识一个对象（或者在实体集的 范围内唯一标识一个实体）的属性或属性集 一个类中的两个对象（或一个实体集中的两个实体） 在构成键码的属性集上取值不能相同 ODL中键码的表示 interface Movie ( key (title,year) ) { …… }
超码 一个或多个属性的集合，能在一个实体集中唯一地 标识一个实体 一个类（或实体集）中可能有多个超码
Interface Cartoon-MurderMystery : Cartoon,MurderMystery {}
E/R中的子类
Isa
E/R中的继承
对约束的建模
建模包含对现实世界的对象及联系的描述，也
包含对它们的一些约束
键码
单值约束 参照完整性约束 域的约束 一般约束
反向联系 ODL要求显式表示存在的反向联系
Interface Movie { //Movie Class 的ODL说明 attribute string title; attribute integer year; attribute integer length; attribute enum Film { color, blackAndWhite } filmType; relationship Set < Star > stars inverse Star :: starredIn; //Star与Movie的联 系 };
透过E/R图，便于与用户交流
才有意义 弱实体集与其拥有者之间的联系是标识性联系
number Crews Unit-of name Studios addr
关于联系集
联系集的成份
参加联系的实体集的主码 联系集的属性
联系中属性的决策(二元联系)
1:1 联系集的属性：放到任意一端 1:N 联系集的属性：放到 N 端 N:M联系集的属性：只能留在联系集中
联系集的取舍（二元联系）
1:1联系：将一端的主码作为另一端的属性 1:N联系：将一端的主码作为 N 端的属性 N:M联系：必须保留联系集
联系集的键码（二元联系）
1:1联系：任意一端的主码
1:N联系：N端的主码
N:M联系：参加联系的所有实体集的主码