EpiData使用经验.docxVIP

/?tag=epidata-2依然是以SF-36量表数据库作为例子来学习如何给问卷建立索引大家都知道，每次调查，每一份问卷都有唯一的编码，这个是必须保证，也是后面数据库记录与问卷对应的关键变量，是数据库寻找识别的可靠保证。类似于每一本书的目录一样，每页都有唯一的页码与该页对应，所以要查找相关内容，直接可以通过目录页码来寻找。同样对于数据库也是一样，那么在EPIDATA里面如何实现的呢？下面来介绍KEY这个命令首先介绍KEY的基本语法格式：KEY {UNIQUE} {keynumber}KEY命令就给是所设置的变量建立一个索引，同事会生成另外一个用来保存索引的文件（.EIX），如果KEY后面加上UNIQUE，那么就是说明此索引为唯一索引，也就是说此变量的值在所有记录中只能出现一次。当然任何变量都是可以作为索引变量的，但是要是作为唯一索引变量就需要保证该变量值是唯一不能出现重复变量值。后面的KEYNUMBER是表示第几个索引，一个数据库允许建立多个索引。但是最多不要超过10个。在本数据库中，对变量ID也就是问卷编码建立唯一索引，因为编码是唯一不可重复的变量，也是后期查询或者排序等炒作的最佳变量。命令内容如下：IDKEY UNIQUEEND这里KEY UNIQUE后面会自动添加数字1，在编辑的时候可以不用些数字，系统会根据已经有的索引自动更新索引的数字。那么KEY命令的好处前面说过，系统总结如下：1.建立索引和没有建立索引的数据库，在查询的速度和效率上差别很大，建立索引的数据库效率高，类似于你去翻书，想查阅某段资料，如果你有目录，那么你查询的速度当然快，如果没有目录自然就很满没有效率，所以索引可以比作目录去理解。索引有单独的文件保存，犹如目录单独列为一页。2.排序，同样道理如果没有索引排序的依据没有，如果出现变量值重复率较高的情况，排序效率更低。3.可以保证每一个ID只能录入一次，如果在录入过程中出现重复的录入变量值，系统会提示是否查询已录入的记录。4.可以作为对外联系的节点。例如：你去医院看病，你去买动车火车票，买机票都需要出示身份证，那么身份证号码是医院电子病例数据库、机场乘客数据库以及活动动车销售数据库的联系点，因为身份证号是这些数据库的索引，也是节点，对于数据库如果要与外部数据库有链接，建立唯一索引。窗体顶端?? 发送文章为PDF ?? 窗体底端Tagged with: epidata ? key ? 索引? EpiData使用经验（4）–SF-36生命质量量表数据库的设计(续2)On 2011/07/20, in EpiData使用技巧, by crackman0对于一个数据库，接下来应该是对数据库的测试，那么接下来和大家谈一下数据库测试的目的、内容以及方法。数据库测试的目的是检测数据库的BUG，提前发现问题并最大可能完善。很多时候，测试这个环节容易被忽略，很多同学一看到数据库就开始录入数据，录入到一半发现很多错误或者很多不方便的地方，完全可以通过一些设置来完善提高效率，避免错误。但是一提到测试数据库，对于很多非计算机或者理工科的学生来说，一头雾水，觉得这个应该很复杂而且专业，自己搞不定就不去做了，将就着录入数据就可以了，老板给的录入费也不高，何必那么折腾呢？但是从一个研究者来说，当一个课题最关键的数据资料搜集回来之后，如果在录入环节，发现录入的数据质量如此之差，例如：年龄小于15岁，婚姻状况居然为已婚；年龄为5岁地小孩，学历居然是硕士；测量血压时，发现血压值居然是128/780，舒张压居然是780了？实在很恐怖。等等功亏一篑，重复录入不仅仅效率低下而且会减小录入人员的积极性，恶性循环。所以在数据库设计好之后，一定要对数据库进行测试，这个测试主要内容包括：1.完整性：数据库中的问题变量是否足够反映问卷中的信息；是否存在疏漏而有些问题没有在数据库中反映，这点一定要合适正确。2.逻辑性：每一个变量都有其一些列的属性，例如：变量长度，变量类型以及变量的取值范围等，变量的属性是否符合本问卷设计的要求，能否表达问卷的信息；另外就是逻辑选择，某一个变量作为逻辑关系的判断变量时，一定对逻辑关系各种可能进行测试，对后面的各种判断变量是否符合问卷本身的逻辑关系，进行反复的测试。3.效率：所谓的效率，就是在数据库的设计中，如何在形式上设计一些技巧，让录入过程显得更加高效，最简单的就是HIDE命令，可以让录入人员减少错误的机会。对于这些内容，我们似乎都知道应该这样去测试，但是实际操作中，随意输入几个问卷，发现没什么错误，就觉得没问题了。那么我们在测试中应该有哪些技巧呢？1.常规测试：所谓的常规测试，就是从问卷调查中最常见的情况出发进行测试，发现一些问题然后进行改进，因为常规测试的问题是录入过程最容易碰到的问题，因此具有较高的代表性，必须发现问题