| ER模型也叫作实体关系模型,是用来描述现实生活中客观存在的事物、事物的属性,以及事物之间关系的一种数据模型。在开发基于数据库的信息系统的设计阶段, |
| 通常使用ER模型来描述信息需求和信息特性,帮助我们理清业务逻辑,从而设计出优秀的数据库 |
| 1、实体:可以看做是数据对象,往往对应于现实生活中的真实存在的个体。在ER模型中,用矩形来表示。实体分为两类,分别是强实体和弱实体。 |
| 2、强实体是指不依赖于其他实体的实体;弱实体是指对另一个实体有很强的依赖关系的实体。 |
| 属性:是指实体的特性。比如超市的地址、联系电话、员工数等。在ER模型中用椭圆形来表示。 |
| 3、关系:是指实体之间的联系。比如超市把商品卖给顾客,就是一种超市与顾客之间的联系。在ER模型中用菱形来表示。 |
| |
| 可以独立存在的是实体,不可再分的是属性。也就是说,属性不能包含其他属性 |
| ER 模型看起来比较麻烦,但是对我们把控项目整体非常重要。如果你只是开发一个小应用,或许简单设计几个表够用了,一旦要设计有一定规模的应用,在项目的初始阶段, |
| 建立完整的 ER 模型就非常关键了。开发应用项目的实质,其实就是 建模 |
| |
| 我们设计的案例是 电商业务 ,由于电商业务太过庞大且复杂,所以我们做了业务简化,比如针对SKU(StockKeepingUnit,库存量单位)和SPU(Standard Product Unit, |
| 标准化产品单元)的含义上,我们直接使用了SKU,并没有提及SPU的概念。本次电商业务设计总共有8个实体,如下所示。 |
| |
| 地址实体 |
| 用户实体 |
| 购物车实体 |
| 评论实体 |
| 商品实体 |
| 商品分类实体 |
| 订单实体 |
| 订单详情实体 |
| |
| 其中, 用户 和 商品分类 是强实体,因为它们不需要依赖其他任何实体。而其他属于弱实体,因为它们虽然都可以独立存在,但是它们都依赖用户这个实体,因此都是弱实体。 |
| 知道了这些要素,我们就可以给电商业务创建 ER 模型了,如图: |
| |
| 在这个图中,地址和用户之间的添加关系,是一对多的关系,而商品和商品详情示一对1的关系,商品和订单是多对多的关系。 这个 ER 模型,包括了 8个实体之间的 8种关系 |
| (1)用户可以在电商平台添加多个地址; |
| (2)用户只能拥有一个购物车; |
| (3)用户可以生成多个订单; |
| (4)用户可以发表多条评论; |
| (5)一件商品可以有多条评论; |
| (6)每一个商品分类包含多种商品; |
| (7)一个订单可以包含多个商品,一个商品可以在多个订单里。 |
| (8)订单中又包含多个订单详情,因为一个订单中可能包含不同种类的商品 |

| 有了这个 ER 模型,我们就可以从整体上 理解 电商的业务了。刚刚的 ER 模型展示了电商业务的框架, |
| 但是只包括了订单,地址,用户,购物车,评论,商品,商品分类和订单详情这八个实体,以及它们之 |
| 间的关系,还不能对应到具体的表,以及表与表之间的关联。我们需要把 属性加上 ,用 椭圆 来表示, |
| 这样我们得到的 ER 模型就更加完整了。 |
| 因此,我们需要进一步去设计一下这个 ER 模型的各个局部,也就是细化下电商的具体业务流程,然后把 |
| 它们综合到一起,形成一个完整的 ER 模型。这样可以帮助我们理清数据库的设计思路。 |
| 接下来,我们再分析一下各个实体都有哪些属性,如下所示。 |
| (1) 地址实体 包括用户编号、省、市、地区、收件人、联系电话、是否是默认地址。 |
| (2) 用户实体 包括用户编号、用户名称、昵称、用户密码、手机号、邮箱、头像、用户级别。 |
| (3) 购物车实体 包括购物车编号、用户编号、商品编号、商品数量、图片文件url |
| (4) 订单实体 包括订单编号、收货人、收件人电话、总金额、用户编号、付款方式、送货地址、下单时间。 |
| (5) 订单详情实体 包括订单详情编号、订单编号、商品名称、商品编号、商品数量。 |
| (6) 商品实体 包括商品编号、价格、商品名称、分类编号、是否销售,规格、颜色。 |
| (7) 评论实体 包括评论id、评论内容、评论时间、用户编号、商品编号 |
| (8) 商品分类实体 包括类别编号、类别名称、父类别编号 |
| 这样细分之后,我们就可以重新设计电商业务了,ER 模型如图: |

| 通过绘制 ER 模型,我们已经理清了业务逻辑,现在,我们就要进行非常重要的一步了:把绘制好的 ER模型,转换成具体的数据表,下面介绍下转换的原则: |
| (1)一个 实体 通常转换成一个 数据表 ; |
| (2)一个 多对多的关系 ,通常也转换成一个 数据表 ; |
| (3)一个 1 对 1 ,或者 1 对多 的关系,往往通过表的 外键 来表达,而不是设计一个新的数据表;(业务量大时,不建议使用外键,约束限制可在应用层实现) |
| (4) 属性 转换成表的 字段 |
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗?
· 10年+ .NET Coder 心语 ── 封装的思维:从隐藏、稳定开始理解其本质意义
· 【设计模式】告别冗长if-else语句:使用策略模式优化代码结构
· 字符编码:从基础到乱码解决
· 提示词工程——AI应用必不可少的技术
2021-06-17 jdbc操作mysql(三):利用注解封装
2021-06-17 jdbc操作mysql(二):封装