基于SQLite的问卷调查系统的数据库设计

毕业设计写了一个基于Android的问卷调查系统,完成的只有离线部分,为了存储本地的一些数据设计了这个数据库。后来一个做Android开发的同学告诉我,Android项目一般不会把大量数据存储在本地。而在写毕业设计之前我几乎没有接触过Android开发,为了毕业设计,也只好硬着头皮这么做了,至于源码就不贴出来丢人了。这里主要介绍一下数据库的设计吧。希望和有兴趣的人共同讨论学习,本人对数据库比较感兴趣,虽然现在做的工作跟数据库不相关。

首先问卷调查系统得想办法把问卷存储下来,我的做法是用代码解析按照一定规则组织的文本,然后插入到数据库中。为了存储问卷我建了三张表。

title表,用来存储问卷的标题、描述信息和问卷的创建时间。有一个唯一标识id。建表语句如下:

CREATE TABLE [title] (
[t_id] integer PRIMARY KEY AUTOINCREMENT,
[t_title] varchar(50) NOT NULL UNIQUE,
[t_describe] TEXT,
[t_time] DATETIME NOT NULL);

结果如下:

question表,用来存储问卷中的问题内容以及该问题的类型(基本题型有单选题、多选题、判断题、填空题)。以及一个唯一标识id和参照title表的一个外键id,建表语句如下:

CREATE TABLE [question] (
[q_id] integer PRIMARY KEY AUTOINCREMENT,
[t_id] integer NOT NULL REFERENCES [title]([t_id]) ON DELETE CASCADE,
[q_context] text NOT NULL,
[q_type] integer NOT NULL,
UNIQUE([t_id], [q_context]));

结果如下:

item表,用来存储问卷中的问题选项,一个唯一标识id,参照title表的外键id,参照question表的外键id。建表语句如下:

CREATE TABLE [item] (
[i_id] integer PRIMARY KEY AUTOINCREMENT,
[q_id] integer NOT NULL REFERENCES [question]([q_id]) ON DELETE CASCADE,
[t_id] integer NOT NULL REFERENCES [title]([t_id]) ON DELETE CASCADE,
[i_context] text NOT NULL,
UNIQUE([q_id], [i_context]));

结果如下:

以上三张表基本上可以存储一张普通的问卷了,遇到有图片的问题或选项,我的做法是在问题内容或选项内容中用‘-’符号连接一张图片的名称,然后将图片存储在指定文件夹下,通过代码到该文件夹下加载图片。如果问题选项中有一个选项是“其他”或“其它”时,代码就认为该问题是带有填空的单选题或带有填空的多选题。这样题型就扩展到六种。

有了问卷,我还需要存储问卷调查结果。为了达到这一目的,我新建了另外两张表。

questionaire表,存储了调查问卷的创建时间,调查是否完成,是否上传的内容。还有一个标识id,以及参照title表的外键id,这连个id组成联合主键。建表语句如下:

CREATE TABLE [questionaire] (
[qn_id] integer NOT NULL,
[t_id] integer NOT NULL REFERENCES [title]([t_id]) ON DELETE CASCADE,
[qn_time] DATETIME NOT NULL,
[qn_completed] integer NOT NULL,
[qn_up] integer NOT NULL,
CONSTRAINT [sqlite_autoindex_questionaire_1] PRIMARY KEY ([qn_id], [t_id]));

结果如下:

answer表,用来存储问卷的调查结果。以及参照question表的外键id,参照item表的外键id,参照qustionaire表的联合外键id。建表语句如下:

CREATE TABLE [answer] (
[q_id] integer NOT NULL REFERENCES [question]([q_id]) ON DELETE CASCADE,
[t_id] integer NOT NULL,
[qn_id] integer NOT NULL,
[i_id] integer REFERENCES [item]([i_id]) ON DELETE CASCADE,
[context] text,
FOREIGN KEY([t_id], [qn_id]) REFERENCES [questionaire]([t_id], [qn_id]) ON DELETE CASCADE);

结果如下:

再贴一些SQL语句:

select t_id,t_title,t_describe,t_time from title order by t_id asc, 查找问卷标题。

select count(*) as c from questionaire where t_id = ?,‘?’号填充的是title表的标识id,用来统计该问卷下面对应有几项调查问卷。

select q_id,q_context,q_type from question where t_id = ? order by q_id asc ,‘?’号填充的是title表的标识id,用来查找该问卷中的所有问题内容。

select qn_id,qn_time,qn_completed,qn_up from questionaire where t_id = ? order by qn_id asc,‘?’号填充的是title表的标识id,用来查找该问卷对应的所有调查问卷的信息。

select i_id,i_context from item where q_id = ? and t_id = ? order by i_id asc,‘?’号依次填充的是question表的标识id和title表的标识id,用来查找一份问卷对应下面的问题对应的所有选项内容。

最后是顺利毕业了,另外本人现在从事的是c++开发,对行业还是一知半解,希望大牛能为我指一条方向,好继续努力!

时间: 2024-10-10 16:15:18

基于SQLite的问卷调查系统的数据库设计的相关文章

公交车路线查询系统后台数据库设计--换乘算法改进与优化

在<查询算法>一文中已经实现了换乘算法,但是,使用存储过程InquiryT2查询从“东圃镇”到“车陂路口”的乘车路线时,发现居然用了5分钟才查找出结果,这样的效率显然不适合实际应用.因此,有必要对原有的换乘算法进行优化和改进.在本文中,将给出一种改进的换乘算法,相比原有的算法,改进后的算法功能更强,效率更优. 1. “压缩”RouteT0 假设RouteT0有以下几行 如下图所示,当查询S1到S4的二次换乘路线时,将会产生3×2×4=24个结果 从图中可以看出,第1段路线中的3条线路的起点和站

【机房收费系统】数据库设计

概述本文介绍基于机房收费系统  基本遵循三范式的数据库设计. 仅满足最基本功能需求.不包括额外的信息保存. 回想 关系模式设计的好坏直接影响到数据冗余度和数据一致性等问题. 由此我们有了一个评价指标.即范式. 第一范式:关系模式R的每一个关系r的属性值都是不可分的原子值 第二范式:关系模式R是1NF且每一个非主属性全然依赖于候选键 第三范式:关系模式R是1NF且每一个非主属性都不传递依赖于R的候选键 ER图 ER图转换成关系模式集的算法 步骤一(实体类型的转换) 将每一个实体类型转换成一个关系模

机房收费系统重构——数据库设计

终于,走到了机房收费系统重构的阶段-- 之前的一遍机房收费系统的数据库是用的给的那个,只是把每个表都看了一下,当时也没有学习数据库原理那本书,然后就没有深究-- 现在不一样了,我们进行机房收费系统重构,况且学习了数据库原理这本书,对数据库有了更深的认识.所以对于数据库要好好的设计,按照步骤走-- 数据库技术是信息资源管理最有效地手段.数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求. 数据库的设计的步骤和各阶段的主要内容

网上外卖及订餐系统的数据库设计

背景:互联网越来越发达,宅男越来越宅,网上订餐送叫外卖的越来越多. 注:本文仅做后台数据库设计,不做系统功能设计. 一.数据库需求分析 1.用户分为游客.注册用户和管理员用户,只有登录用户才能进行网上订餐,游客仅能浏览餐厅及菜肴信息,只有管理员身份才能进行后台管理 2.一个餐厅设计一张菜单:一张订单对应一个送餐员,可以包含多个菜肴:一个客服管理员可以管理多张订单 3.每个菜肴从属于一个菜系,一个菜单,一个餐厅 4.一个用户可以选择多个菜肴,产生多个订单 5.一张菜单每次对应一个优惠活动 二.数据

【转】多语言系统的数据库设计

首先我们需要确认我们要做的系统,多语言到底是要做多少种语言,以后会不会要求增加更多的语言.比如我们做一个给中国大陆和纽伦新港使用的系统,可以确定的语言就是简体中文.繁体中文和英语,而且可以确定以后也不会增加语言.确定以后是否需要增加语言这一点很重要,决定了我们在数据库设计时,是否需要考虑多语上的扩展性. 先说下在数据库设计时,可以有以下方案实现多语: 一.为每个多语字段建立对应语言的字段列. 比如我们有一个客户表,记录了客户Id.客户名称.客户地址.客户电话等,其中客户名称和客户地址是多语的,而

火车票订票系统的数据库设计与实现(某某乐后端实习面试题)

目的:设计一个车票的数据库,完成一些基本的查询.增删功能. 数据表结构分析: 各个字段分析: 基本数据库.表的建立,数据录入: 复杂查询的实现简要分析. 1 数据库结构分析: 1.1 客户表 目的:查询客户的所有信息. 输出字段:身份证号(主键).姓名.用户名.联系电话.籍贯.类型(学生还是普通) 1.2 订票单表 目的:查询某一客户订单票的信息 输入in:姓名 输出:订单编号,订票时间,乘车日期,订票数量 1.3车票表 输出:车次,出发站,目的站,座位类型,座位号,车票价格,发车时间,到站时间

数据库设计中主键问题

转自: http://www.jb51.net/article/40933.htm 数据库主键在数据库中占有重要地位.主键的选取策略决定了系统是否可靠.易用.高效.本文探讨了数据库设计过程当中常见的主键选取策略,并剖析了其做主键的优缺点,提出了相应的解决问题的方法 在基于关系型数据库设计时候,通常要为每张表指定一个主键,所谓主键就是能够唯一标识表中某一行记录的属性或属性组,一个表只能有一个主键,但可以有多个候选索引.因为主键可以唯一标识某一行记录,所以可以确保执行数据更新.删除.修改时不出现错误

[02]基于webservice的权限系统

前面,已经介绍完了,如何利用cxf搭建webservice.那我们接下来就来介绍此权限系统的表结构. 此权限管理系统分为部门管理,员工管理,角色管理,权限管理,人员授权和业务管理(此处不涉及) 角色管理包括角色定义和角色授权.角色授权的过程是给指定角色以某个权限来完成授权: 权限管理即权限的定义和设置,权限管理的过程是给某个权限以某个对象操作表来完成管理: 人员授权的过程就是给人员以某个角色来完成授权. 这三句话,希望大家仔细品味,这是权限管理系统的核心所在,如果不是很好理解的话,可以接和我下面

性能优化系列六:数据库设计

一.为优化而设计 1. 数据库设计 数据库设计,一个软件项目成功的基石.数据库设计也是门学问.在项目早期由开发者进行数据库设计(后期调优需要DBA).一个精通OOP和ORM的开发者,设计的数据库往往更为合理,更能适应需求的变化.因为数据库的规范化,与OO的部分思想雷同(如内聚).而DBA,设计的数据库的优势是能将DBMS的能力发挥到极致,能够使用SQL和DBMS实现很多程序实现的逻辑,与开发者相比,DBA优化过的数据库更为高效和稳定. 2. 数据库设计与程序设计的差异 有如下的一个系统: 面向对