数据库设计实例---学习数据库最紧张的应用之一

一、弁言【可忽略】

        在学习“数据库体系概述”这门课程时，我一直很好奇，这样一门必修课，毕竟教会了我什么呢？
        由于下课后，，没有拓展本身的眼界，上课时又局限于课堂上老师的讲课水平，我一直不明白这门课的意义。
        我在其中学会了什么呢？坦言，有不少新名词：
        比如范式、变乱、码、聚集运算等等。
        但是，在现实应用中，我发现课堂上讲到的，只有我早就学过的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的接洽，如A：B=1：1，则随意在一张表里，加入另一张表的主键，作为外键【比如在A表中，加入B的主键BID，此时，A表中的BID就是A表的外键】
        第二，1对n的接洽，如A：B=1：n，在n端表，加入1端表的主键，使该主键成为表外键。【即B表中，加入A表主键AID，则B表的外键是AID】
        第三，n对m的接洽，如A：B=n：m，则要把这个接洽抽出，独立成一张新表X，使X拥有A、B两表的主键，并且有主外键要求。X的外键是AID或BID，X的主键是AID并BID。
        那么，本题转换为：
        用户表（ID，用户名，暗码，手机号，邮箱）
        订单表（ID，订单名，价格，描述，用户ID）
        装备表（装备ID，装备名，描述，价格）
        用户装备接洽表（用户ID，装备ID，别的描述）
        订单装备接洽表（订单ID，装备ID，别的描述）
        有时，可能会灵感一现：用户A可能拥有100个装备aa，用户装备接洽表，得有100条重复数据啊！这不符合主键！
        以是，用户装备接洽表加上属性“装备数量”。
        同理，订单装备接洽表加上“装备数量”。
至此，初步的表设计完成。
范式规范化

        第一范式

                1NF要求：在业务层面，要求所有的列都不可分。
                显然满足。
        第二范式

                2NF要求：所有的列，直接或间接依靠主键。
                显然满足。
        第三范式

                3NF要求：所有的列，直接依靠于主键；并且，列与列之间无依靠关系。
                固然这么说欠好，但是确实也满足。
以是，这个数据库就设计完成了，我们拥有了一个可以利用的数据库！
 我是蚊子码农，如有补充或者疑问，接待在评论区留言。个人的知识体系可能没有那么美满，盼望各位多多指正，谢谢大家。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。