精华区 [关闭][返回]

当前位置:网易精华区>>讨论区精华>>编程开发>>● VFP>>〖数据设计〗>>数据库设计--方法探讨

主题:数据库设计--方法探讨
发信人: hunter__fox(雁回西楼)
整理人: hunter__fox(2003-05-30 22:24:02), 站内信件
    在上一篇帖子里,我们谈到了通过数据链来达到目标数据,今天,我们就来进一步看看怎么在数据库设计过程中去具体体现它.
    首先,我们要确定一点,就是数据库中所有的表格都是互相有关的,就像一个小社会,所有人都是相关的一样.想一想,你与任何人都有关...这不是谬论.你可能不认识d,但你认识a,a又认识b,b认识c,c认识d...我们的数据库也是这样,没有任何数据是可以独立存在的.
    但是,如果我们在数据库设计过程中,没有去考虑好将来的数据链的问题,那么,我们从一个起点到过目标数据所需要的环节可能会很长,那么,我们必然需要更多的时间去执行,这样的话,系统处理数据的速度就慢下来了.
    我们需要简洁的数据结构.建立简洁的数据库,我们需要好的方法来发现和整理数据.

    让数据简洁很容易,让数据结构简洁就不同了.
    我们在两种方法.
    第一种方法,我们在具体动手设计数据库之前,尽可能的明确数据库的内容,这样,我们在架构这个数据库时,我们已经知道安的具体作用了,我们不必要考虑更多的.我们就有更多的时间去寻找最简单的结构(当然,实际上,不一定需要最简单的结构,很简单的结构就已经可以了).但是,很多时候,我们并不能做动这一点.有时是用户的需求改变了,有时是我们发现数据库中需要新的数据...我们需要更改数据库的结构.结构的更改,很有可能让我们需要重新设计大部分数据链路.
    第二种方式,我们从数据库中找出一些主要的数据内容,它们与绝大多数数据有比较近的关系.如:
   a   b   c   d   e   f   g   h
    \   \ /   / \   \   \ /   /
     --- q ---   \   --- r ---
    /   / \   \   \ /   / \   \
   i   j   k   l   m   n   o   p
很明显,我们将q和r作为主要的链路要点的话,我们可以很快的到达其它的数据.这张图里,我们只画出了一些简单的关系线,事实上,数据库里数据的关系会很复杂,我们要做的工作就是把它们简化成近似这样的工作.这是一个比较烦的工作,而且,也有风险存在----一一旦我们在数据库中发现了一个新的要点数据,那么,我们前面所做的一切工作都需要重来.在这种情况下,我们需要比使用第一种方法更多的工作量来完成.
    所幸的是,我们找到要点数据比找到其它数据要容易很多,很多人凭直觉就能找到一些常用数据库模型中的要点数据.

    因此,如果你是一个新手,建议你先使用第一种方法,虽然你不得得多次重做,但能够让你慢慢学到发现数据的本领,这对以后用较快的速度来设计数据库是很重要的一项能力.
    如果你已经有过多次数据库的设计经验,你就可以试试第二种方法.这让你能很快的理清数据间的关系.

    很多时候,我们是使用生长法来发现数据的.
    我们先确定几个主要的数据内容,如,一个学校的数据库里,有关学生的信息必然是一个主要数据内容.然后,我们会从这些要点数据来寻找与之有关的数据.如,成绩信息就与学生信息有关,住宅楼分配信息也与之有关...这样,我们能发现大总部分数据.
    但是,我们也会漏掉一些数据.如果没有明确的要求,我们就有可能漏掉毕业时间这一项数据---它一旦产生,与之相关的信息都基本上可以算是过时的信息了.
    如果这一遗漏在我们做完数据库时还没有发现,在做完系统后,发现没有办法进行相关的查询,那么,我们的工作量就会大量增加,这有可能导致不能按时守成开发计划.(想一想,我们需要加上些什么样的字段,再同步修改多少界面,然后还有多少测试工作要做,还有文档的更新...)

    好在,我们还有其它的方法可用.
    如果各位阅读过关于XP开发方式(极限开发)的书,就会知道,XP开发的重点是测试,在建立具体的代码(我们这里是数据结构)之前,先建立相应的测试用例.我们可以同样来进行.
    我们找到一项数据后,就将它加入到数据库中,建立它与其它数据的连接,然后测试与它相关的数据的关系.不要用"想像"来代替测试.我认为它可以到达...这不一定是正确的.每个人都会有这样的"认为"...你需要克制不进行测试的想法.我们需要每一次测试都做到.
    虽然没有必要,但我还是建议在测试时做好相应的记录.这样,你就能知道哪测试你做了,哪些没有.测试的工作量很大,一般来说,它占整个工作的三分之二强.
    这里,我们就已经不是在使用生长法来建立数据库了.我们做一个简单的例子看看:
    目标:建立学生的信息库

    数据的最覆盖结果是用于查询和更改,因此,我们先写下几个对应的语句,作为测试用例:
    #Define CON_性别男 .T.
    #Define CON_性别女 .F.
    && 找出年龄大于20岁的学生
    Select * From 学生 ;
          Where 年龄 > 20
    && 年龄大于20岁的男学生
    Select * From 学生 ;
          Where 年龄 > 20 ;
          And 性别 = CON_性别男
    && 大于20岁的,2002年入学的女学生
    Select * From 学生 ;
          Where 年龄 > 20 ;
            And 性别 = CON_性别女 ;
            And Year(入学日期) = 2002
    && 读4年专业的所有学生
    Select * From 学生 ;
          Left Join 专业 On 学生.专业id = 专业.id ;
          Where 专业.学年 = 4
    && 13楼里所有的学生
    Select * From 学生 ;
          Right Join 宿舍 On 学生.id = 宿舍.学生id ;
          Where 宿舍.楼号 = 13
    && 13楼407的入住者
    Select * From 学生 ;
          Right Join 宿舍 On 学生.id = 宿舍.学生id ;
          Where 宿舍.楼号 = 13
            And 宿舍.房号 = "407"
    检查一下,我们发现,年龄的判断需要改成:Year(Date())-Year(出生日期) > 20更好...
    其它的步骤,如,测试用例的进一步修正,用例的测试,这里就不再说了.
    我们根据这里个语句来构成数据表...每构成一个数据表,或者添加进一个字段,我们就执行一次这个测试用例,以便我们知道,下一步我们要完成什么...不要因为我们很早想到了宿舍表的结构而先去完成它.测试用例哪一句不能执行,我们就要修正相应的表....
    直到测试用例完整通过并且结果正确.
    在测试通过之后,我们记录下用例的代码内容,测试日期等信息.在将来的开发中,如果我们相似的语句不能执行通过,那么,通过对比两组语句,就能很容易发现问题所在,而需要修改数据结构时,我们只要确保测试用例通过,就行了.
    这里的这个用例是很简陋的,事实上,我们一般会建立一些语句,每个语句都将测试一个新的字段,组合查询中,我们也列出了所知道将会被使用的各种连接条件.
    有时,这些用例看起来比文档更有实用价值.

    下一次,我们将尝试通过测试用例或其它的(如关系图等)信息中发掘核心数据.


[][][][][][]
[]相关内容[]
[][][][][][]
1:关闭][返回]