美文网首页
数据库原理 - 课程设计思路 @ASA

数据库原理 - 课程设计思路 @ASA

作者: 1Z实验室阿凯 | 来源:发表于2016-06-25 21:41 被阅读387次

    学习数据库的套路

    【要不要学 or 为什么要学】

    很多学生在选一门课的时候,最基本的问题往往不会去关心。同时,学生们也没有权利去选择,毕竟有培养计划这种东西。所以老师
    要做的是激发起大家学习的欲望,这一点做的好,往往会水到渠成。
    另一个是,你需不需要学,是找别人帮忙,还是自己做?学习数据库你要花费的时间成本是多少,如果我告诉你掌握数据库需要十年,你当然不干了。
    我学习数据库,是基于我做项目的需求。很简单,我做Web开发需要存储信息,总不能都靠非结构式文件,而且各种查询处理都不方便对吧。

    【DBMS 的选择】

    于是搜索数据库,哇好多种DBMS的种类,而且SQL 与 NoSQL 让人眼花缭乱,看需求吧,首先目前做的项目是单个服务器的,所以不涉及分布式,而且是内部访问,并发不高,而且SQL相关的资料又很多,种种原因,选SQL好了,那么DBMS又有很多: MySQL , Oracle,SQL Server 等等,我选了MySQL,主要因为免费,而且DBMS的很多高级功能我暂时用不上,所以就它了。

    有人会觉得,NoSQL出来了,而且这么火,关系型数据库真LOW,这种东西早就应该被淘汰了吧,(Sorry,我曾经也属于狂热追求新技术的分子)实际上不然,阿里淘宝等国内的大部分公司依然在用MySQL,无论从就业的角度或者是学习的角度,SQL的学习都是必要的,没有一种完美的解决方案,SQL与NoSQL都有各自的短板,接下来的文章里我们再细谈。

    【项目需求分析】

    首先目前我想做的是一个XX系统。

    我这里且叫它课堂交互系统吧,对,就是花了一年都没做出来的那个,心累。

    在数据库设计的第一步,我们要明确需求,就是说,这个课堂交互系统都有哪些功能点,例如:考试开启一次小组互评,小组管理,学生之间的小组互评等等。(在软件工程和产品经理的课程里面有详细的说明)

    【概念模型设计】

    我有了想做的功能,那下一步要做的是不是就是要分析,每个功能模块中对应的都有哪些"实体" ,实体之间的"联系",以及实体本身都有哪些"属性"。
    但是自己在纸上乱涂乱画,好混乱有没有?所以我们需要借助E-R模型来帮助我们分析关系。

    问题 1: 实体之间都有哪些关系呢,每种关系在E-R上都是如何去表示的。

    当我想存选择测验的时候
    (1)一个测验,可以有多个选择题(好吧 ,主观题/简答题这里我们就先不说了),而一个选择题又可能出现在多个测验中,这叫多对多(Many-to-Many)

    (2)一个试题对应多个选项,而且选项不确定。那么好了,这是一对多的关系(单选还是多选,它们都一样吗?存储的方式有啥不同)

    (3)最日狗的地方来了,学生做题的记录怎么存?

    如上的这一系列的思考,并不是我在做哪套题目,而是我在做这个项目的时候,真真切切需要结局的问题。

    问题 2:E-R 如何才能画的好 ? (结构清晰,分层)
    当学会画E-R图的时候,总是发现最后都画成了一坨,而且一个项目的实体又那么多,彼此的关系错综复杂,最后各种跳线,画出了你根本看不懂的E-R图。

    你想我都看不懂了,多大的问题!!
    所以要学会分层,每个功能模块分开画,细节后述。
    这是还可以上升到人生哲学的高度,从顶向下,逐层细分问题,各个击破。完美!

    【关系模型】

    关系模型是数据模型的一种,因为我们这里要使用的是MySQL,所以我们需要采用关系模式进行分析。
    为啥要这样干,因为你又不能通过E-R直接生成表结构。所以你需要将E-R模型“翻译”成关系结构。

    问题3 : 每种E-R中的关系,映射到关系模式中,方式是唯一的吗?E-R图有没有一种设计规则来指导我们呢?他给定的设计规则我一定就要遵守吗?

    显然不是嘛。
    举例来说E-R模型中的Is-a关系 即 继承关系。举例说明,老师和学生之间的关系,这里他们都是这个系统的用户,老师和学生都可以评价小组展示的内容,包括用户的登陆,注册等等功能模块,老师跟学生是很类似的,最后设计出来的表结构,你会发现列的内容只有很少的差别,这里我们将二者抽象成一个User 实体。

    问题来了 :怎么存?
    (1)这两个我能都放在User表中,对一张表,那各有的字段怎么办,比如学生有学号,老师有教工号咋整?冗余字段呗。User中同时有学号和教工号这两列
    (2)第二种是Student和Teacher各自一张表,分家了,自己存自己的。
    (3)三张表,User,Student,Teacher,User中存取共同的部分,Student,Teacher存各自特有的部分

    问题4: 在这里面哪种是最好的设计呢?

    Sorry,这里没有标准答案,这也是数据库设计思想里面最吸引我的地方。

    范式
    虽然有范式(1NF,2NF,3NF,BCNF)的数据库设计理论来消除冗余,但是不必较真,你设计的表结构越分散,就意味着你写查询的时候会很麻烦,耗时也会越长,对大家的要求是,先能够做到功能实现。武林高手的进阶大概会经历这么几个阶段:

    没有对错,只有哪个更适合你此时的需求,对此事的,很可能你系统运行一个月之后会变得很卡,问题的答案又会变掉了。

    同样的,永远都没有完美的数据库设计,好的数据并不是一开始就设计好的,而是一次一次迭代出来的。(可能是需求变更,也可能是数据库设计的优化)
    这里推荐一本书《SQL反模式》。

    给老师的建议
    其实,设计一个数据库是最简单的,这里我先不说好坏,起码你功能实现了。但是在实际的应用中,我觉得是远远不够的。如何测试一个数据设计的好坏,能不能提供大量的数据存入,然后模拟高并发的访问,测试一个数据库的设计的好坏?
    当学生写的一个SQL查询需要执行一天的话,那么,绝对出了问题。 是你数据库设计的问题 (例如:没做好索引)?还是SQL语句的书写需要优化?

    【物理模型设计】

    现在你有了关系模型,感觉它离着变成数据库中真实的表似乎指日可待了对吧。
    别急。。。
    (1) 字段属性
    还记得你的在数据库的概念设计里面实体有很多属性对吧,例如

    学生(学号,学生姓名,年龄,学院ID,专业,注册时间)
    

    属性有了,每个数据采用哪些数据类型呢?你需要了解MySQL中都有哪些数据类型,相似的数据类型区别是啥?

    (2) 各种约束
    实体完整性,根据某几个字段,定位某个特性的行。这个当然不能呢为空啦,要不你都找不到它了。

    参照完整性,例如学生实体的学院ID,学院ID是外码,如果学院ID没有或者对应的学院ID在学院表中不存在,什么鬼,你不属于任何一个学院,那你不是很无助。

    用户自定义完整性
    简单来说除了上面的两种,其他的用户定义的约束,都属于用户自定义约束。
    学生实体中有一个属性是 年龄。
    好,年龄对吧,-1岁,显然不行,今年是2016年你2017年出生了这也太玄幻了,穿越了?,1000岁?能活到这个岁数的应该是王八吧。

    所以我需要给年龄设定一个年龄范围例如 0- 110
    超出这个字段的,我都定义为非法。

    【创建表结构】

    现在你需要学些SQL了,开始的时候你需要创建一个数据库,在数据库中定义表,定义视图,这种操作都叫DDL(Database Define Language ),对应的你需要用DDL写出Create Table的相应的SQL语句。

    【SQL基本操作】

    表结构有了,但是你还没有数据,插插插,将数据Insert进你的表中。
    我还需要查询表(Select),删除(Delete)一条数据,更新(Update)一条记录。

    【加特效 :数据库程序设计】

    视图
    触发器
    存储结构

    Note: 暂时先写到这里,工程经验止于此,不愿意误人子弟。

    心灵硫酸

    老师的职责
    (1) 往那走
    给学生方向上的指引,用哪个DBMS,学习方式,学习资源。
    (2) 喂,走偏了
    点到为止
    老师教的越多,学生能够接收的信息也就越少。
    克制住,先别告诉他原则,让他们违背,走到坑里,很痛苦,记忆也就更深刻,这样才会有需求。
    我们总是被告知,不要这样,要那样!可是为啥呢,我们并没有很深层次的感悟,内心无感。
    在合适的地方,合适的时间,合适的地点,给与适当的指引。
    温柔的告诉他:“也许你应该看一下课本上XX的部分,可能会对你有写帮助”。

    不贪
    不要意味的看各种设计指导原则,不要贪多,想掌握全部的SQL,更多的还是根据自己的需求来吧,你需要用到哪些功能,不够再学吗,循序渐进。
    学习 = 学 + 习,练习实践很重要。
    你学习的内容,能不能转换成生产力,等于你是否在有效学习。

    项目导向
    项目进行中遇到问题了,有了需求,然后去找解决方案。

    不燥
    文章前面有提到,不要盲目的追求新技术

    接受不完美,并且努力做得更好

    给项目管理人员:PDCA理论

    PDCA来自于户外拓展理论,同理它也可以放在数据库设计的过程中。
    Plan 计划
    做计划,一开始就动手做,往往需要频繁的返工。
    指定适当的计划,分解任务,逐层分解。
    Do 尝试
    总计划,不去尝试,等于0。
    一开始,计划绝对是不靠谱的,而且项目管理者往往会时间估计的比较乐观,比如我。
    所以要去试错,做一个Demo,去验证项目计划的可行性。

    Change
    在我们不断的尝试的过程中,发现了计划中很多不合理的地方,咋办,改计划呗。
    循环往复执行,直到计划靠谱。

    Action
    不要怂,开始动手做吧。

    相关文章

      网友评论

          本文标题:数据库原理 - 课程设计思路 @ASA

          本文链接:https://www.haomeiwen.com/subject/qzsadttx.html