《数据库原理》 城市天气查询系统.docx

上传人:b****8 文档编号:29920756 上传时间:2023-08-03 格式:DOCX 页数:25 大小:633.89KB
下载 相关 举报
《数据库原理》 城市天气查询系统.docx_第1页
第1页 / 共25页
《数据库原理》 城市天气查询系统.docx_第2页
第2页 / 共25页
《数据库原理》 城市天气查询系统.docx_第3页
第3页 / 共25页
《数据库原理》 城市天气查询系统.docx_第4页
第4页 / 共25页
《数据库原理》 城市天气查询系统.docx_第5页
第5页 / 共25页
点击查看更多>>
下载资源
资源描述

《数据库原理》 城市天气查询系统.docx

《《数据库原理》 城市天气查询系统.docx》由会员分享,可在线阅读,更多相关《《数据库原理》 城市天气查询系统.docx(25页珍藏版)》请在冰豆网上搜索。

《数据库原理》 城市天气查询系统.docx

《数据库原理》城市天气查询系统

《数据库原理》课程设计报告

 

设计题目:

城市天气查询系统

专业:

信息管理与信息系统

 

计算机与数据科学学院

2019年01月06日

前言

当代社会,人们在出行前往往要了解当天或者随后几天的天气情况,然后根据天气情况推断自己的出行状态以及该携带何种物品,于是,天气预报就成为了他们判断并了解这些信息的手段。

随着现代社会信息化的发展,天气预报系统及天气查询系统也在不断演变。

及时,准确地向人们发布最新的天气情况是气象信息系统的首要任务,但同时也要确保人们能够通过天气查询系统及时获得准确的天气情况。

这次课程设计,主要采用了SQL语言,设计者通过完善天气管理及查询系统的功能,其中包括查询,修改,增加,删除等,并利用需求分析,E-R图及相关结构设计对天气情况进行分析,为使用者及时,准确的提供当地最新及未来数天的天气情况预报,其中包括时间,温度,空气质量,相对湿度,风向,风力,气压等内容。

使用者可以使用查询功能,按照地域或者时间查找相关的信息以及实现简单的统计功能。

管理员可以凭借其身份认证在网络上完成修改,增加,删除等功能。

从整体上看,此次设计的查询系统从某些方面来说还是可以满足人们的简单需求的,而且操作简单,布局容易,方便易懂。

1概述

1.1选题的背景与意义

随着网络的日益发展,利用网页实现天气预报功能已将相当普遍。

信息化的时代,人们出门前不必再去电视机前等待着观看实时天气预报,而是利用手机,电脑等现代化设备,通过网络连接随时随地掌握当地的天气变化情况。

在众多天气预报查询系统中,此次课程设计旨在开发一个功能完善,界面友好,操作简单,信息齐全,部署方便的天气查询系统。

使用者可以通过查询的方式获得所需的天气信息情况,管理员可以通过其身份认证实现对天气数据的修改,增加,删除等功能。

此次设计其优点就是人们可以通过较为简单的操作就可以获得自己所需的天气信息情况,不足之处就是查询,修改等功能必须在有网络连接的情况下实现。

1.2相关技术分析

操作系统Windows10

数据库软件SQLsever2012

操作语言SQL语言

 

2系统功能设计

2.1系统总体结构设计图

城市天气查询系统包括员工,城市,天气管理模块及用户查询四个模块,其结构图如下图所示:

图2.1系统总体结构设计图

2.2系统功能模块

2.2.1员工管理模块

此模块包含对员工基本信息的添加,修改,删除和查询。

员工输入自己的编号和密码就可以进入管理系统的主界面,员工基本上可以对主界面的所有信息进行操作。

2.2.2城市管理模块

此模块包含城市的添加,查找和删除。

用户可以通过手动输入,自动定位和选择系统内置的热门城市等方式选择目标城市。

也可以在城市管理界面完成对城市的切换。

通过对各个城市进行搜索查询,准确定位到每一个城市,然后再通过查询天气功能准确的显示每个每个城市的准确情况。

2.2.3天气管理模块

此模块主要完成对用户所选城市的天气基本信息,如温度,相对湿度,风力,风向,降水量,紫外线等的添加,修改,删除和查询。

员工可以通过其管理员身份认证进入系统主界面,对相关天气信息进行添加,修改,删除和查询。

2.2.4用户查询模块

此模块主要用于用户通过注册或者登陆的方式进入天气查询系统,通过输入时间和地点获得所需的天气信息。

系统功能模块如图所示:

图2.2员工管理流程图

图2.3用户查询流程图

3数据库设计

3.1需求分析

3.1.1数据流图

图3.1数据流图

3.1.2顶层数据流图

图3.2顶层数据流图

3.1.3数据字典

(1)数据项

表3.1数据项列表

数据项名

含义说明

类型

长度

与其他数据项的关系

eno

员工的编号

int

3

是employees的主键

ename

员工的姓名

vachar

10

epassword

员工的密码

char

12

cityname

城市的名称

vachar

10

是城市表的主键

dates

日期

datetime

10

是天气表的主键

cityname

城市的名称

varchar

10

temperature

温度

float

10

relativeHumidity

相对湿度

char

10

windDirection

风向

vachar

8

wind

风力

int

3

bodyTemperature

体感温度

float

8

airPressure

气压

char

8

airQuality

空气质量

vachar

10

Uitraviolet

紫外线

vachar

10

uno

用户的账号

int

10

是用户表的主键

upassword

用户的密码

char

12

uname

登录名

vachar

10

(2)数据结构

表3.2数据结构列表

数据结构名

含义说明

员工

员工编号,姓名,密码

城市

城市名称

天气

日期,城市名称,温度,相对湿度,风向,风力,体感温度,气压,空气质量,紫外线

用户

用户账号,登录密码,登录名

(3)数据流

表3.3数据流列表

数据流名

输入

输出

变更城市信息

变更信息

城市记录

查询城市信息

城市名称

城市记录

变更天气信息

变更信息

天气记录

查询天气信息

城市名称,日期等

路况信息

变更员工信息

变更信息

员工记录

查询员工信息

员工编号,姓名等

员工记录

变更用户信息

变更信息

用户记录

查询用户信息

用户账号,登录名等

用户记录

(3)数据存储

表3.4数据存储列表

数据存储名

流入过程

流出过程

员工信息

变更员工信息

查询员工信息

城市信息

变更城市信息

查询城市信息

天气信息

变更天气信息

查询天气信息

用户信息

变更用户信息

查询用户信息

(4)处理过程

表3.5处理过程列表

处理过程名

输入

输出

查询

城市名称,日期

所需的天气信息

变更信息

变更信息

再次查询信息

用户登录

用户账号,密码,登录名

用户登录

员工登录

员工编号,姓名,密码

员工登录

3.2概念结构设计

3.2.1局部E-R图

数据抽象后得到了实体和属性,实际上实体和属性是相对而言的,往往要根据实际情况进行必要的整理。

在调整过程中要遵循以下两条原则:

1.实体具有描述信息,而属性没有。

即属性必须是不可分的数据项,不能再由另一些属性组成。

2.属性不能与其他实体具有联系,联系只能发生在实体之间。

 

(1)员工与天气信息E-R图

 

图3.3员工与天气信息E-R图

(2)员工与城市信息E-R图

 

图3.4员工与城市信息E-R图

(3)用户与天气信息E-R图

 

图3.5用户与天气信息E-R图

3.2.2全局E-R图

合并各分E-R图,消除属性冲突、命名冲突、结构冲突等三类冲突,得到初步E-R图,再消除不必要冗余,得到的基本E-R图如下所示:

 

图3.6全局E-R图

3.3逻辑结构设计

逻辑结构设计一般分为三步:

1初始关系模式设计;

2关系模式规范化;

3模式的评价与改进

3.3.1E-R图向关系模式的转换

转换原则:

一个实体转换为一个关系模式,实体的属性就是关系的属性,实体的码就是关系的主码;一个联系转换为一个关系模式,与该联系相连的各实体的主码以及联系的属性均转换为该关系的属性。

该关系的主码有三种情况。

①如果联系为1:

,则每个实体的主码都可以是关系的候选码。

②如果联系为1:

n,则n端实体的主码是关系的主码。

③如果联系为n:

m,则每个实体的主码的组合是关系的主码。

将四个实体转化成关系模式:

员工(员工编号,姓名,密码);

城市(城市名称);

天气(日期,城市名称,温度,相对湿度,气压,风向,风力,空气质量,体感温度,紫外线);

用户(用户账号,登录名,登录密码)

将两个联系转化成关系模式:

管理(员工编号,日期,城市名称);

查询(用户账号,日期,城市名称)

由于上述转换基于的是全局E-R模型,因此,上述转换得到的模式满足3NF。

3.3.2子模式的设计

表3.6员工基本信息表

列名

数据类型

可否为空

说明

eno

int

notnull

员工的编号

ename

vachar

notnull

姓名

epassword

char

notnull

密码

 

表3.7天气基本信息表

列名

数据类型

可否为空

说明

dates

datetime

notnull

日期

cityname

vachar

notnull

城市的名称

temperature

float

notnull

温度

relativeHumidity

char

notnull

相对湿度

windDirection

vachar

notnull

风向

wind

int

notnull

风力

bodyTemperature

float

notnull

体感温度

airPRESSURE

char

notnull

气压

airQuality

vachar

notnull

空气质量

Uitraviolet

vachar

notnull

紫外线

表3.8用户基本信息表

列名

数据类型

可否为空

说明

uno

int

notnull

用户的账号

uname

vachar

notnull

登录名

upassword

char

notnull

用户的密码

3.4物理结构设计

不同的数据库产品所提供的物理环境、存取方法和存储结构有很大差别,能供设计人员使用的设计变量、参数范围也很不相同,隐藏没有通用的物理设计方法可遵循,只能给出一般的设计内容和原则。

数据库上运行的各种事务响应时间小、存储空间利用率高、事务吞吐率大,首先对要进行的事务进行详细分析,获得选择物理数据库设计所需要的参数;其次,要充分了解所用关系数据库管理系统的内部特征,特别是系统所提供的存取方法和存取结构。

以下是确定关系的存取方法的依据:

1.对于数据库查询事务,需要得到:

查询的关系,查询条件所涉及的属性,连接条件所涉及的属性,查询的投影属性。

2.对于数据更新事务,需要得到:

被更新的关系,每个关系上的更新操作条件所涉及的属性,修改操作要改变的属性值。

3.除此之外,还需要制定每个事务在各关系上运行的频率和性能要求。

所谓选择索引存取方法,实际上就是根据应用要求确定对关系的那些属性列建立索引、哪些属性列建立组合索引、哪些索引要设计唯一索引。

1)如果一个(或一组)属性经常在查询条件中出现,则考虑在这个(或这组)属性上建立索引(或组合索引)。

2)如果一个属性经常作为最大值和最小值等聚集函数的参数,则考虑在这个属性上建立索引。

3)如果一个(或一组)属性经常在连接操作的连接条件中出现,则考虑在这个(或这组)属性上建立索引。

而确定数据库存储结构时要综合考虑存取时间、存储空间利用率和维护代价三方面的因素.这三个方面常常是相互矛盾的,例如消除一切冗余数据虽然能够节约存储空间,但往往会导致检索代价的增加,因此必须进行权衡,选择一个折中方案

因此,对于此天气查询系统,我将选择B+树索引。

在此查询系统中,员工信息表,城市信息表,天气信息表,用户信息表中的主键分别为员工编号,城市名称,日期,用户账号,而当用户查询天气信息时,需要对此四个表进行连接才可查询所需信息。

在员工信息表中的员工编号和姓名上创建唯一索引;在城市信息表中的城市名称上创建唯一索引;在天气信息表中的日期,和城市名称上创建唯一索引;在用户信息表中的用户账号和登录名上创建唯一索引,如下图所示:

图3.7创建索引

3.5数据库实施

3.5.1数据库,表建立的代码

(1)创建一个数据库,数据库名为KSM

createdatabaseKSM

(2)创建一个员工信息表,并输入相关的员工编号,姓名,密码信息

createtableemployees

enointprimarykey,--员工编号

enamevarchar(10),--员工姓名

epasswordchar(12)notnull,--员工的密码

unoint,

datesdatetime

insertintoemployeesvalues(001,'ksm','123456',101,2018-2-22);

insertintoemployeesvalues(002,'zhw','532265',102,2018-3-27);

insertintoemployeesvalues(003,'wj','58721YN',103,2018-5-2);

insertintoemployeesvalues(004,'lzp','5498oiw',104,2018-6-26);

图3.8员工信息表

(3)创建一个城市信息表,输入城市的名称

createtablecity(

citynamevarchar(10)primarykey--城市的名称

insertintocityvalues('杭州');

insertintocityvalues('平顶山');

insertintocityvalues('郑州');

insertintocityvalues('上海');

图3.9城市信息表

(4)创建一个天气信息表,输入相关的天气信息。

createtableweather(

datesdatetimeprimarykey,--日期

citynamevarchar(10)foreignkeyreferencescity,--外键城市名称

temperaturefloat(10),--温度

relHumiditychar(10),--相对湿度

windDirvarchar(8),--风向

windint,--风力

bodyTempfloat(10),--体感温度

airPrechar(8),--气压

airQuavarchar(8),--空气质量

Uitravarchar(10),--紫外线

insertintoweathervalues(‘2018-2-22’,'杭州',20.0,'57%','南风',3,21.5,'1kgw/cm2','良好','良好');

insertintoweathervalues(‘2018-3-27’,'平顶山',25.0,'35%','东北风',2,26.5,'1kgw/cm2','严重污染','良好');

insertintoweathervalues(‘2018-5-2’,'郑州',23.0,'40%','东南风',1,23.5,'1kgw/cm2','好','差');

insertintoweathervalues(‘2018-6-26’,'上海',24.0,'56%','西北风',3,21.5,'1kgw/cm2','良好','好');

图3.10天气信息表

(5)创建一个用户表,输入用户的账号,用户密码,登录名

createtableusers(

unointprimarykey,--用户的账号

upasswordchar(12),--用户密码

unamevarchar(10)--登录名

insertintousersvalues(101,'12356','小白');

insertintousersvalues(102,'148ox','小话');

insertintousersvalues(103,'1235wox','小绿');

insertintousersvalues(104,'5621wlk','小黑');

图3.11用户信息表

3.5.2查询语句

(1)查询用户信息

select*fromusers

图3.12查询用户信息

(2)查询天气信息

select*fromweather

图3.13查询天气信息

(3)查询城市信息

select*fromcity

图3.14查询城市信息

(4)查询员工信息

select*fromemployees

图3.15查询员工信息

3.5.3建立视图

(1)用于查询员工基本信息的视图如下:

图3.16员工信息视图

(2)用于查询城市基本信息的视图如下:

图3.17城市信息视图

(3)用于查询天气基本信息的视图如下:

图3.18天气信息视图

(4)用于查询用户基本信息的视图如下:

图3.19用户信息视图

3.5.4触发器

触发器的删除:

当删除城市表中的城市信息时,对应的天气表中有关此城市的天气信息也被删除。

useKSM

go

createtriggerdel_xoncity

afterdelete

as

deletefromweather

whereweather.citynamein(selectcitynamefromdeleted)

go

deletefromcitywherecityname='平顶山'

select*fromcity

select*fromweather

图3.20触发器的删除

触发器的插入:

当在天气表中插入天气信息时,天气表中含有的城市的天气信息会成功插入,不含有的城市天气信息插入失败。

useKSM

go

createtriggerinsert_sxonweather

afterinsert

as

ifexists(select*frominsertedwherecitynamein(selectcitynamefromcity))

print'添加成功'

else

begin

print'插入失败'

rollbacktransaction

end

insertintoweathervalues('2018-2-23','长沙',20.0,'57%','南风',3,21.5,'1kgw/cm2','良好','良好');

insertintoweathervalues('2018-3-8','上海',20.0,'57%','南风',3,21.5,'1kgw/cm2','良好','良好');

select*fromweather

图3.21触发器的插入

图3.22触发器的插入

3.6数据库运行与维护

3.6.1备份与还原的原则

备份类型的选择和还原模式的确定都应遵循这样的原则:

尽最大可能、以最快速度减少或消灭数据丢失。

3.6.2注意事项

(1)如果只进行数据库备份,那么将无法还原自最近一次数据库备份以来数据库中所发生的所有事务。

(2)如果进行数据库备份时也进行事务日志备份,那么可以将数据库还原到失败点。

那些在失败之前为提交的事务将无法还原,但如果您在数据库失败后立即对当前处于活动状态的事务进行备份,则为提交的事务也可以还原。

3.6.3数据库的备份计划

(1)有规律地进行数据库备份,例如每晚进行备份。

(2)以较小的时间进行差异备份,比如每隔3小时或4小时。

(3)在相邻的两次差异备份之间进行事务日志备份,可以每20分钟或30分备份一次

3.6.4数据库的还原计划

如果采用上述的备份方案,在进行还原的时候,我们可以先还原最近一次的数据库备份,接着进行差异备份的还原,最后进行事务日志备份的还原。

但是,在更多情况下我们希望还原到数据库失败的那一刻,此时我们只需按照下面的方法就可以达到目的了

(1)如果能访问数据库的事务日志文件,则应备份当前正处于活动状态的事务日志;

(2)还原最近一次数据库备份;

(3)还原最近一次差异备份;

(4)按顺序还原自差异备份以来进行的事务日志备份

 

4结束语

通过这次课程设计得出一个结论:

知识必须通过应用才能实现其价值!

有些东西以为学会了,但真正到用的时候才发现是两回事,所以我认为只有到真正会用的时候才是真的学会了。

同时在设计的过程中发现了自己的不足之处,对一些前面学过的知识理解得不够深刻,掌握得不够牢固,比如说E-R图的合并,触发器等。

数据库的设计最主要的就是分析,合理设计表的结构,规范表的字段,建立合理的关系及模式图,而在此次设计中均有所体现,虽然设计过程不是很困难,但是操作比较复杂,耗时较多。

但我在整个设计中还是懂得了许多东西,不仅培养了我独立工作的能力,还树立了对自己工作能力的信心,相信会对今后的学习工作生活有非常重要的影响。

而且大大提高了动手和思维的能力,使我充分体会到了在创造过程中探索的艰难和成功时的喜悦。

虽然这个设计做的并不完美,但是在设计过程中所学到的东西是这次课程设计的最大收获和财富,使我终身受益。

对我而言,知识上的收获重要,精神上的丰收是可喜的。

挫折是一份财富,经历是一份拥有。

这次实际操作必将成为我们人生旅途上一个非常美好的回忆!

 

参考文献

[1]陈志泊.数据库原理及应用教程.人民邮电出版社,2018.

[2]高凯.数据库原理与应用.2版.电子工业出版社,2016.

[3]张红娟,傅婷婷.数据库原理.西安电子科技大学出版社,2014.

[4]唐好魁.数据库技术及应用.3版.北京:

电子工业出版社,2015.

[5]杨海霞.数据库原理与设计.2版.北京:

人民邮电出版社,2015.

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 理学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1