数据库学习笔记_1_数据库设计概论

  E-R model, more precisely, entity-relationship model， 这个模型从概念上来说有两个功能，1，将该库里面的实体用各种方式分别出来（identify）（这里的实体据老师来说就是一堆属性的集合，即通过构成一个实体的属性来区别其本身的独一性），2， 将这些实体以一定的关系来描述。

  overview  of the design progress:

  设计数据库大体看来的三个方面：

    1.数据库的关系结构设定（data schema）

    2.可以访问和更新的程序

    3.一个安全结构控制访问的内容。

   除此以外，由于数据库设计的极大的用户核心性，一些附加的额外要求将极大的影响数据库的物理层面，逻辑层面和可视层面。

   从一个小数据库来说的话，设计是一个很简单的事情，因为设计者通常都是使用者，但是在真实的世界中，往往使用者和设计者不是同一个人，所以说设计者需要和使用者交流，然后出一个在高级层面上对于使用者友善的程序，是的差不多就是win系统那样的东西，GUI界面使得傻瓜式操作变为可能。然后把这些需求在底层实现并优化。

   因为使用者和设计者的交流，一个高层数据模型被生成。这个数据模型对于设计者来说，会提供：

    一个系统概念框架，这个系统框架能系统的描述用户的需求，以及为了实现需求所需要的数据结构。

    （这个时候想想我们对于一个教务系统的schema的需求和这个schema的实现，就很好理解了）

  程序设计的阶段：

    1.对于潜在使用者需求的分析，在这个阶段要和目标领域的专家进行交易 交流，出一份数据输入输出的详细规程，即甲方要求。

    2.选择数据模型，然后将要求用数据模型实现，我们上文提到的ER模型就是一个很好的模型，一般来说，这个阶段的设计应该给出一个图形化的数据schema。设计者在这个阶段应该检查schema是否满足使用者的要求而且要求之间不应该产生冲突。同时应该试着去掉冗余的冗余措施。

       2.1：一个概念化的schema还应该包含一些功能性要求（就是一些封装好的函数？）例如增删改查恢复什么的。这一步也应该被检查。

    3.实现。

因为实现物理存储的改变相对于逻辑层面较为容易，所以在设计逻辑数据库的时候最好take with care.

  设计时要避免的东西：

    1.redundancy: 数据冗余，即是多余的数据拷贝，比如说我对于一节课程，同时给他标上课程名称和课程序号这两个字段，那这就是多余的，因为一个课程名称必然唯一符合与一个课程序号的。

    数据冗余不仅可能造成多余的空间浪费，也可能会带来更新数据的不变，因为如果我要对于一个数据进行更新的话，如果不遍历其所有出现的位置，那么在调用的时候就可能会出现错误。

    总结的来说，一个实体的数据只应该出现在一个位置。

   2.incompleteness:个人觉得这个翻译成数据的独立性比较恰当，就是说如果数据不够细分的话，会影响以后实体的创建，比如说，假设我们把每一节课都赋予它的课程名和id，而不是单独储存的话，那么我们想新加一门课，但是现在这门课没有一个对应的实体（啊这个可以理解，比如说编译原理这种课程是一直存在着的，但是能教的老师屈指可数而且老师还嫌学生太傻所以不愿意教），那么我们就不可能单单加上这门课的概念而不加上对应的实体，这就给教务处的人造成了麻烦。

  坏的设计大概就以上两种，但是好的设计可能很多，拿一个顾客买了物品来做个例子，是物品这个实体和顾客产生关系，还是顾客和物品产生的关系，还是这一笔交易使得物品和顾客产生了关系？所以需要数据库系统需要好好设计。