毕业设计--设计数据库

毕业设计:数据库设计
功能分析:
系统主要实现前台用户和后台管理员两大功能模块,用户功能主要提供给阅读馆会员的用户使用,包括用户的登录,查询会员办理日期、到期日期、缴费金额、续费提醒;后台管理员功能主要提供给系统的管理员使用,包括登录、增加会员信息、修改会员信息、删除会员信息、分类查询会员信息、自动结算会员费用、计算会员持续时间、会员费用统计、会员数量分期统计等

一、从功能中可以看出,大致分为2大类:管理员和会员用户
接下来我们继续细分!

1*.账号表
从功能看,管理员,仅仅只有一个账号,也不需要什么多余的信息表。而且会员用户也有账号
所以我们可以建一张表专门用来存放账号:

表名为:'account';
设计字段:'a_username'、'a_password'、'jurisdiction';
主键:'a_username';
外键:无;
'a_username'和'a_password'不做多余的解释就是用户和管理员的账号和密码;
'jurisdiction'用来区分权限的,因为我们知道,管理员账号和会员账号权限不一样,也就注定了登录账号不同所跳转到的页面不同。
所以我规定:
  '1'为管理员账号;
  '2'为普通用户账号;
当然也可以建立两张表,分别用来存放管理员与用户的账号。
我这边就选择用了一张表。

二、接下来我们继续分析。这个系统主要是围绕会员用户设计的。所以数据库的表也应该是针对会员用户的
我们再来看看
用户页面需要实现的功能:用户登录,查询会员办理日期、到期日期、缴费金额、续费提醒
管理员页面需要实现的功能:登录、增加会员信息、修改会员信息、删除会员信息、分类查询会员信息、自动结算会员费用、计算会员持续时间、会员费用统计、会员数量分期统计
其中登录已经实现
通过功能我们大致可以了解到,我们所需要建立的表应该有:1.用户信息表;2.用户充值记录表;
我们首先从用户信息入手。
我们都知道办理会员卡,我们要获取用户的部分信息,那么我们应该要获取用户的那部分信息呢?在一些正规的图书馆中,用户都是实名制,所以我们所获取的用户信息应该包括:姓名性别年龄身份证号手机号邮箱。邮箱我们作为一个可选,毕竟许多广告还是要从邮箱和手机短信上推广的,你们都懂得,嘿嘿嘿。。。通过功能还需要添加上会员办理日期到期日期
所以我们的用户信息表就可以创建了!

2*.用户信息表:

表名:'vip_userinfo';
字段:'v_id'、'vip_name'、'vip_sex'、'vip_age'、'vip_IdCard'、'vip_phone_number'、'vip_email'、'vip_start_date'、'vip_end_date'、'a_username';
主键:'v_id';
外键:'a_username';
为什么使用'a_username'为外键呢?'a_username'为表'account'中的唯一主键。
我们设计了信息表,那么这个信息对应那个会员用户呢?是不是就需要通过外键进行关联呢?所以我们选择'a_username'作为外键来关联这两张表

接下来我们分析用户消费信息表:
消费信息表比较简单:根据功能判断,此表中,只存储充值记录即可。

3*.用户充值记录表:

表名:'recharge';
字段:'r_id'、'money'、'r_date';
主键:'r_id';
外键:无

这样表我们就创建完了,那么我们来分析一下表与表之间的关系,
首先:
账号表'account'和用户信息表'user'之间:

一个账号只能对应一个用户信息,所以表'account'与表'vip_userinfo'之间是一对一关系;
一个用户信息也只对应一个账号,表'vip_userinfo'与表'account'之间也是一对一关系;
它们通过'a_username'所关联。

然后:
用户信息表'vip_userinfo'与用户充值记录表:'recharge':

一个用户可以有多条充值记录,所以用户信息表'vip_userinfo'与用户充值记录表:'recharge'之间是一对多关系;
而一条充值记录只能对应一个用户,所以用户充值记录表:'recharge'与用户信息表'vip_userinfo'之间是一对一关系;
因为存在1对多关系,所以需要建立中间表,把它们进行关联起来。(注:一对多,多对多,都需要建立中间表)

中间表:

表名:'userinfo_rechange';
字段:'v_id'、'r_id';
主键:'v_id'、'r_id';('v_id'、'r_id';分别是外键,但是它们两个一起构成了唯一索引,所以'v_id'+'r_id'是主键;它们共同构建为了主键)
外键:'v_id'、'r_id';

最后在删除用户时,我多建一张表用来收集用户信息。现在是大数据时代,所以删除用户信息不存在的。只是从正常的管理表中删除,存储到了专门存储收集用户信息的表中,即:"userinfo_collect"表

表名:'userinfo_collect';
字段:'id'、'user_name'、'sex'、'age'、'IdCard'、'phone_number'、'email';
主键:'id';
外键:无;

到这里我们毕业设计的数据库就创建完成了。
可以参考我的mysql教程《mysql入门:创建和删除数据库操作(DDL)》,哦:http://t.cn/Ru0XftA
也可以关注我的文集《mysql入门到提升》http://t.cn/Ru0XO78学习更多关于数据库的知识,哦。

小白出品,不喜勿喷!

  生活总会给你第二次机会,叫明天。  
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,547评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,399评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,428评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,599评论 1 274
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,612评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,577评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,941评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,603评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,852评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,605评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,693评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,375评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,955评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,936评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,172评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,970评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,414评论 2 342

推荐阅读更多精彩内容