做视频赚钱的网站,专业网站建设价格,邹城网站开发,自己电脑做网站好吗一、引言【可忽略】 在学习“数据库系统概述”这门课程时#xff0c;我一直很好奇#xff0c;这样一门必修课#xff0c;究竟教会了我什么呢#xff1f; 由于下课后#xff0c;#xff0c;没有拓展自己的眼界#xff0c;上课时又局限于课堂上老师的讲课水平#xff0c;…一、引言【可忽略】 在学习“数据库系统概述”这门课程时我一直很好奇这样一门必修课究竟教会了我什么呢 由于下课后没有拓展自己的眼界上课时又局限于课堂上老师的讲课水平我一直不理解这门课的意义。 我在其中学会了什么呢坦言有不少新名词 比如范式、事务、码、集合运算等等。 可是在实际应用中我发现课堂上讲到的只有我早就学过的SQL语句会真正使用。 也就是增删改查SELECT、DELETE、UPDATE和INSERT四个语句。 后来从需求文档开始开发一个项目我也是懵懵懂懂由于队友提前把数据库建好了我并没有学到建立数据库的知识。 也是某次契机面试时面试官询问你如何设计这个数据库的 于是回去我恶补了一下花了半个星期终于把我学过的知识联系起来。 数据库设计是比使用SQL语句更重要的知识因为使用SQL语句的基础先是有一个数据库有一些表。
二、数据库建立的六个步骤和笼统的对应目标 正如解数学题一样数据库的建立也有其流程如下
第一步需求分析。 该步骤从实际出发成果物是一份需求文档【专业名词叫“用户需求规格说明书”】。 重点在于拿到用户的数据需求和数据处理需求。【简单地说就是你要存什么数据比如一个学生类以及你要对这些数据做什么处理比如增删改查】 在更实际的开发中我们可能会涉及性能需求、安全需求在此不赘述。
第二步概念结构设计 这个词语很难理解我认为可以叫做“模型设计”。 因为这一步的目标是设计出一个“模型”什么样的模型呢 E-R实体联系模型。 这个模型定义了这个数据库中包含的实体、实体拥有的属性和实体之间的联系有一些特殊实体可能还会在联系中加入一些特殊的约束。
第三步逻辑结构设计 这个词语也不太好理解你可以认为这里的“逻辑”是指从实体模型转化为关系模型抽象了一个层面所以叫做“逻辑”设计。 这一步的目标是得到可以作为数据库的关系模型。【关系模型的意思后面再讲】 我们拿到E-R模型后根据一些转换原则很容易拿到关系模型但是不是所有关系模型都能当数据库使用。 至少经过3步范式才能设计出不容易出问题、面对异常处理比较好用的关系模型。
第四步物理结构设计 这一步不是我们考虑的更多是操作系统开发商和数据库开发商考虑的。
第五步数据库的部署和测试 没什么好说的。
第六步数据库的运维 无。 我们可以发现从0到1的数据库开发重点在于前3步。下面我用一个实例来讲解如何进行。
三、客户需求【从0开始可忽略本节直接看末尾】 小明是个游戏开发人员一直苦于如何将内购模式加入自己的游戏。 有一天他发现某团外卖平台的订单结构非常好但是自己不熟悉如何设计花钱请你帮忙开发。 你询问需求。 小明说“我们的客户每一个都是独一无二的有属于自己的游戏ID、游戏名字、密码和手机号、邮箱等等。” 他又说“某团的结构也是这样所以我们应该能互相转换。” 好我们有了第一个实体这是一份客户表。 你继续询问。 小明说“内购模式最大的问题是如何处理订单因为游戏的装备很多如果玩家A一次性购买20个超级戒指、20瓶恢复药水。” 他顿了顿说道“我也学过一点数据库。对于上述要求如果在一张表里存储要不就用一个集合存储这些装备信息要不就得在一张表存储40个信息可是玩家ID是主键一张表里不可能有40个相同ID更何况这么做信息冗余很多查找起来也麻烦。” “所以我想要一个独立的订单它关联着用户。” 好我们有了第二个实体这是个订单表也许它和客户表有联系不过没有关系目前不在乎。 游戏里有什么戒指、恢复药水的装备以后可能还会增加一些装备如果在订单表里把所有装备都定义上并且用另一列管理它们的购买个数。【类似于HashMap的key、value思想】 可行不过冗余较大。 你继续询问。 “没了。” 就此你大概能知道需要那些东西。 ------从这里开始看。 我们的问题是如何将用户、订单和装备联系起来。 考虑这样的场景玩家A买了3个戒指、4瓶药水、100个卷轴如何存储起来。 第一一个用户表应该是必要的至少要存储用户信息。 第二订单表好像也需要不过订单表里的内容也许需要斟酌。
四、需求分析【真正分析】 由上面的场景我们对每个实体分析一下数据需求和数据处理需求。 用户表基本没什么问题为了一个订单表把用户表全改了是没必要的。 玩家A可能昨天买了一单今天买了3单A与订单之间明显是1对多的关系。 一个玩家可以拥有n个订单。一个订单只能属于一个玩家。 订单和装备呢 用一张装备表存储装备是个不错的想法可是订单可能有n个装备干脆用订单表存储所有的装备 问题是这样想要拓展装备很麻烦。 当我们为这样的问题犹豫时记住2个原则 1.订单涉及的装备明显是个变量一个变量作为表里的一个属性是非常危险的。 2.从关系的角度考虑。 也许我们可以用什么东西表示订单涉及的装备。 订单和装备明显是多对多的关系一个订单可能有n种装备一种装备可能属于m个订单。 所以必须独立出来。
第一用户表 数据需求用户ID、用户名、密码、邮箱、手机。【也许还有订单或者一些描述信息随便】 数据操作需求注册增加、修改密码修改、登录时查看表查找、用户注销也许不会实际删除但起码要表示一下提供一个接口
第二订单表 数据需求可能有订单号ID、订单名字、订单描述、订单价格。 数据操作需求增删改查。
第三装备表 数据需求装备号ID、装备名、装备描述、装备价格【我不确定】 数据操作需求增删改查。
五、概念结构设计 由上面的需求文档画E-R实体联系模型。 这一步主要体现了实体之间不是孤立存在的而是有联系的。 这一步有3个知识点 1.有几张表就画几个实体。 2.实体中的属性就按数据需求画如有增加可临时增加。【当然多人开发需要请示】 3.实体间的联系要画出来。即1对n、n对m E-R图如下 疑问 有的同学可能说了奇怪需求文档没有用户和装备之间的联系啊你演我 确实我刚分析的时候也没有也是刚知道。
六、逻辑结构设计 将E-R图转化为关系模型其实就是把实体转成表只需遵守3个原则。 【注这是在只有2元联系的E-R图适用3元模型大差不差不过尽量把3元模型转化为2元否则不好用】 第一1对1的联系如AB11则随意在一张表里加入另一张表的主键作为外键【比如在A表中加入B的主键BID此时A表中的BID就是A表的外键】 第二1对n的联系如AB1n在n端表加入1端表的主键使该主键成为表外键。【即B表中加入A表主键AID则B表的外键是AID】 第三n对m的联系如ABnm则要把这个联系抽出独立成一张新表X使X拥有A、B两表的主键并且有主外键要求。X的外键是AID或BIDX的主键是AID并BID。 那么本题转换为 用户表ID用户名密码手机号邮箱 订单表ID订单名价格描述用户ID 装备表装备ID装备名描述价格 用户装备联系表用户ID装备ID其它描述 订单装备联系表订单ID装备ID其它描述 有时可能会灵感一现用户A可能拥有100个装备aa用户装备联系表得有100条重复数据啊这不符合主键 所以用户装备联系表加上属性“装备数量”。 同理订单装备联系表加上“装备数量”。
至此初步的表设计完成。
范式规范化 第一范式 1NF要求在业务层面要求所有的列都不可分。 显然满足。 第二范式 2NF要求所有的列直接或间接依赖主键。 显然满足。 第三范式 3NF要求所有的列直接依赖于主键并且列与列之间无依赖关系。 虽然这么说不好但是确实也满足。
所以这个数据库就设计完成了我们拥有了一个可以使用的数据库 我是蚊子码农如有补充或者疑问欢迎在评论区留言。个人的知识体系可能没有那么完善希望各位多多指正谢谢大家。
