EpiData使用经验

-2

依然是以SF-36量表数据库作为例子来学习如何给问卷建立

大家都知道，每次调查，每一份问卷都有唯一的编码，这个是必须保证，也是后面数据库记录与问卷对应的关键变量，是数据库寻找识别的可靠保证。类似于每一本书的目录一样，每页都有唯一的页码与该页对应，所以要查找相关内容，直接可以通过目录页码来寻找。

同样对于数据库也是一样，那么在EPIDATA里面如何实现的呢？下面来介绍KEY 这个命令

首先介绍KEY的基本语法格式：

KEY {UNIQUE} {number}

KEY命令就给是所设置的变量建立一个索引，同事会生成另外一个用来保存索引的文件（.EIX），如果KEY后面加上UNIQUE，那么就是说明此索引为唯一索引，也就是说此变量的值在所有记录中只能出现一次。当然任何变量都是可以作为索引变量的，但是要是作为唯一索引变量就需要保证该变量值是唯一不能出现重复变量值。后面的KEYNUMBER是表示第几个索引，一个数据库允许建立多个索引。但是最多不要超过10个。

在本数据库中，对变量ID也就是问卷编码建立唯一索引，因为编码是唯一不可重复的变量，也是后期查询或者排序等炒作的最佳变量。

命令内容如下：

ID

KEY UNIQUE

END

这里KEY UNIQUE后面会自动添加数字1，在编辑的时候可以不用些数字，系统会根据已经有的索引自动更新索引的数字。

那么KEY命令的好处前面说过，系统总结如下：

1.建立索引和没有建立索引的数据库，在查询的速度和效率上差别很大，建立索引的数据库效率高，类似于你去翻书，想查阅某段资料，如果你有目录，那么你查询的速度当然快，如果没有目录自然就很满没有效率，所以索引可以比作目录去理解。索引有单独的文件保存，犹如目录单独列为一页。

2.排序，同样道理如果没有索引排序的依据没有，如果出现变量值重复率较高的情况，排序效率更低。

3.可以保证每一个ID只能录入一次，如果在录入过程中出现重复的录入变量值，系统会提示是否查询已录入的记录。

4.可以作为对外联系的节点。例如：你去医院看病，你去买动车火车票，买机票都需要出示身份证，那么身份证号码是医院电子病例数据库、机场乘客数据库以及活动动车销售数据库的联系点，因为身份证号是这些数据库的索引，也是节点，对于数据库如果要与外部数据库有链接，建立唯一索引。

发送文章为

PDF 发送

Tagged with: ••

On 2011/07/20, in , by crackman

对于一个数据库，接下来应该是对数据库的测试，那么接下来和大家谈一下数据库测试的目的、内容以及方法。

数据库测试的目的是检测数据库的BUG，提前发现问题并最大可能完善。

很多时候，测试这个环节容易被忽略，很多同学一看到数据库就开始录入数据，录入到一半发现很多错误或者很多不方便的地方，完全可以通过一些设置来完善提高效率，避免错误。但是一提到测试数据库，对于很多非计算机或者理工科的学生来说，一头雾水，觉得这个应该很复杂而且专业，自己搞不定就不去做了，将就着录入数据就可以了，老板给的录入费也不高，何必那么折腾呢？

但是从一个研究者来说，当一个课题最关键的数据资料搜集回来之后，如果在录入环节，发现录入的数据质量如此之差，例如：年龄小于15岁，婚姻状况居然为已婚；年龄为5岁地小孩，学历居然是硕士；测量血压时，发现血压值居然是128/780，舒张压居然是780了？实在很恐怖。等等功亏一篑，重复录入不仅仅效率低下而且会减小录入人员的积极性，恶性循环。

所以在数据库设计好之后，一定要对数据库进行测试，这个测试主要内容包括：

1.完整性：数据库中的问题变量是否足够反映问卷中的信息；是否存在疏漏而有些问题没有在数据库中反映，这点一定要合适正确。

2.逻辑性：每一个变量都有其一些列的属性，例如：变量长度，变量类型以及变量的取值范围等，变量的属性是否符合本问卷设计的要求，能否表达问卷的信息；另外就是逻辑选择，某一个变量作为逻辑关系的判断变量时，一定对逻辑关系各种可能进行测试，对后面的各种判断变量是否符合问卷本身的逻辑关系，进行反复的测试。

3.效率：所谓的效率，就是在数据库的设计中，如何在形式上设计一些技巧，让录入过程显得更加高效，最简单的就是HIDE命令，可以让录入人员减少错误的机会。

对于这些内容，我们似乎都知道应该这样去测试，但是实际操作中，随意输入几个问卷，发现没什么错误，就觉得没问题了。那么我们在测试中应该有哪些技巧呢？

1.常规测试：所谓的常规测试，就是从问卷调查中最常见的情况出发进行测试，发现一些问题然后进行改进，因为常规测试的问题是录入过程最容易碰到的问题，因此具有较高的代表性，必须发现问题，然后进行完善。

2.异常测试：所谓异常测试，就是对于一些特殊的情况进行测试，主要是反映数据库的完整，特殊情况的测试，有几个方面，一个是变量值的极值或异常值情况，例如年龄为1岁的时候什么样的情况；或者说对一些判断节点极值得情况进行测试，如果节点一个，很简单，如果节点几个，需要组合测试。

测试是数据库能否经得起考验的关键，也是后续数据质量的重要环节，所以说测试紧邻让那些本事做过调查而且熟悉数据库的人来完成，而且测试需要非常严谨的思维和踏实的态度，而不是为了测试而走过程。

发送文章为

PDF 发送

Tagged with:

On 2011/07/19, in , by crackman

通过在文章《EpiData使用经验（2）–SF-36生命质量量表数据库的设计》，对整个QES文件的设计到REC文件的生成有了一些了解，不过大家仔细看看，是否存在以下困惑？

1.REC文件的字体是不是和QES里面的字体不一致？

2.REC的背景颜色是浅绿色，如何设置呢？

3.为什么变量值录入框是平的？当鼠标焦点在此框时，背景色则为黄色？

4.每一行之间的间距是否和原始QES里面一样呢？

。。。。。。。。。。。。。。。。。。。。。。。。。。。

我想大家会有很多问题，有思考发现问题去思考，才会学的更快更好！

上面所有的问题都是REC展现形式的问题，关于REC文件的形式例如：颜色、字体、背景、边框背景色等等，都是可以通过软件中菜单“文件”下的“选项”来设置，具体的不在此详细阐述，如果对此方面不清楚，可以给我邮件。

除了形式上的问题，大家有没有思考过问卷内容上的问题？难道这个数据库录入界面就可以使用了么？

1.是不是每一个问卷需要一个唯一标识码？

2.每一份问卷是不是需要注明录入人员以及时间？

对于这个数据库来说，我想上面的两个问题是最基础也是最普遍的问题。接下来，对QES文件重新修改，添加两个变量，一个是ID变量，记录问卷的编码；一个是录入人员记录，以便再后期能够寻找出错误根源。修改好之后，有两个方法重新生成新的REC文件，一个通过菜单点击生成REC文件，覆盖替换即可；或者直接打开原来生成的REC文件，会提示是否根据QES的改变而生成新的REC文件。

现在设置这些都结束了，那么是不是就可以投入使用录入数据了？那么我们再思考一下几个问题：

1.每一个变量如果录入过程中，输入了无效的数字，该录入界面如何避免错误数字的录入呢？

2.如果该问题没有回答，我们应该输入什么数字来表示呢？至少该数字能够区别是调查中是因为真实的没有回答还是调查中调查对象不知道该问题而没有回答？

3.如果同一个问卷录入两次了，如何区别避免重复录入呢？

4.如果录入人员为同一个人，是不是每次录入人员那个变量中，都要输入一次自己的姓名呢？

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

以上几个问题正是反映出整个数据库最关键的部分，效率与质量。