《水质数据库表结构和标识符规定》
征求意见及处理情况汇总
1、有很大一部分水质检测站不是水文站，能否考虑先确定相对稳定的水质站网、站码，并以行业标准的形式规定，然后再开展此项工作，否则会在水质数据库的建设中造成混乱。（陕西）
答：不予采纳。在水利部印发的《水文测站编码》方法中已对全国的水文测站（包括水质站）的编码方法进行了统一，见《关于印发<水文测站编码>的通知》(水文[2003]7号)。
2、“经度”、“纬度”能否考虑应用“度”、“分”、“秒”的形式，没必
要保留“度后小数位七位”，这样又麻烦又不实用。（陕西）
P13-P14原A1.1.7经度——A1.1.8纬度，数据精度保留小数点后七位。建议：是否应表示到“度”、“分”。（山西）
12页：经纬度小数位数定为7位，太多，建议改为：经度N（6，3），纬度N（5，3）。（山东）
答：采纳。表101水质监测站基本信息表已做出了相应修改。
3、监测河段中，河源至该测站距离，能否考虑记至小数后一位，不应记至整数位。（陕西）
答：不予采纳。表102地表水水质监测站信息表已有距河口距离项。
4、“溶解氧”的小数位能否考虑记至：“一位小数”，而“有效位三位，小数不过一位”前后矛盾，而且与COD Mn、COD Cr、BOD5又不统一。（陕西）
答：采纳。表202非金属无机物项目数据表已做出了相应修改。
5、A3.5.8、A3.5.9水功能区总评价河长和水功能区达标河长能否考虑记为“小
数不过一位”。（陕西）
答：采纳。表305水功能区评价结果表已做出了相应修改。
6、A3.6.8、A3.6.9水资源分区总评价河长和水资源分区达标河长能否考虑记为“小数不过一位”，均与评价河长保持一致。（陕西）
答：采纳。表水资源分区评价结果表已做出了相应修改。
7、表结构中部分标识符没有按照标识符规定进行命名。（江西）
答：采纳。一、标准中标识符设计一般规定中的不合理条目进行了修改；二、按照修改后的规定对表结构中所有数据库项目进行了标识。
8、表结构中部分类型及长度的数据型位数需进一步核实。（江西）
数据库中项目监测成果的有效位数保留与《水环境监测规范》（SL219-98）不相符。具体为：pH、电导率、氧化还原电位、透明度、矿化度、非离子氨、总砷、硒、钾、钠、总汞、铁、锰、石油类、总大肠菌群、粪大肠菌群等项目（云南）
答：采纳。表结构中部分类型及长度的数据型位数已进行了修改。
9、“A2.3”表中应增加“铝”项目。（江西）
答：采纳。
10、项目标识符不容易理解，特别是元素符号能否与元素周期表一致，字母大小写有区别、上下标明确。（云南）
答：不予采纳。表结构中元素符号是与元素周期表一致的，但都要求大写，化学符号的上下标在数据库标识符中无法实现。
11、水文要素数字表与国家水文数据库一致即可。
答：采纳。
12、数据库表结构中缺少《水环境监测规范》（SL219-98）中“水质站监测情况说明表及位置图”相应的内容。（云南）
答。不予采纳。与该标准制订无关。在水质信息管理系统软件设计与开发中考虑。
13、征求意见稿中没有明确到能否可通过本数据库检索直接得到如监测成果特征值年统计表等成果。（云南）
答。不予采纳。与该标准制订无关。在水质信息管理系统软件设计与开发中考虑。
14、水质数据库表结构的基础应为《水环境监测规范》（SL219-98）中整汇编要求的表格设计内容。（云南）
答。不予采纳。《水环境监测规范》（SL219-98）中的监测项目较少，不能满足如今的需要。
15、水功能区、水资源分区、湖库等与测站关系表中无法看出多个测站时的关系。（云南）
答：采纳。
16、湖库划为多个行政分区时的关系没有表达出来。（云南）
答：采纳。
17、表A1.1水质监测站基本信息表中无测站类别（如地下水、地表水、大气降水、底质）的区分。（云南）
答。不予采纳。地表水、地下水、大气降水、入河排污口已经分了四张表进行储存，可分别进行查询，以免造成不必要的数据冗余。
18、测站编码是典型的地表水测站编码，没有兼顾大气降水、地下水、底质站、排污口的特性，应增加。（云南）
答。不予采纳。测站编码采用统一的水文测站编码见《关于印发《水文测站编码》的通知》（水文[2003]7号）。
19、表阿A3.4测站评价结果表反馈信息过于简单，没有涵盖大部分水质特征值，如样品总数、检出率、超标率、实测范围、最大值及超标倍数、最大值出现日期、均值等。（云南）
答：不予采纳。在水质信息管理系统软件设计与开发中考虑。
20、缺少湖库营养化评价相关信息、成果表。（云南）
答：采纳。
21、表A1.6水功能区监测断面应与地表水监测断面套叠在一起。应标明水功能区的代表监测断面，一个功能区有多个监测断面时，应有地方标明每个监测站的河长。（云南）
答：不予采纳。表A1.1水质监测站基本信息表中已有了每个监测站对应的水功能区，表A1.2地表水水质监测站信息表已有了每个监测站的评价河长，通过数据库的查询，可满足水质信息管理应用软件的开发设计的需要。
22、P14原A1.1.9测站地址：（填列县以下部分）。建议：水质测站地址应详细至具体位置，是否明确为省、市（地区）县（区）、乡（镇）、村（桥下、坝下、坝上等）。（山西）
答：采纳。
23、P37原A2监测信息类表，因为地表水、地下水、生活饮用水、废污水、大气降水等各项指标的标准含量差异较大。建议：是否应体现不同水体类型及分析方法等，如按各类水体评价标准项目列表，同时应留有扩展项目处。（山西）答：不予采纳。本标准水质监测项目的设置已经考虑到未来水质监测的发展，增加了尽可能的监测项目，并根据项目的性质划分为不同的表格进行存储，同时对
数据的精度进行了核实，能满足不同水体监测数据存储精度的要求。表3.4测站评价结果表的备注栏可用于分析评价方法的说明。
24、P38原A2.1.5采样时间。建议：是否应明确记至年、月、日、时、分。如2004年9月13日 16：30。（山西）
答：采纳。
25、P86原A2.13入河排污口排污量统计表。建议：排污单位、入河污染物质及污染物排放量等均应列入该表，内容是否应再增加些。（山西）
答：部分采纳。排污单位放入该表不妥，如生活污水排污口就无排污单位。入河污染物质等建议项目已加入该表。
26、表201中，要求“pH有效数3位，小数不过2位”，有一些pH计的精度达不到2位小数的要求。（河北）
答：不予采纳。表结构的设计要全面一些，所以精度设计比较高，满足更高的需要。
27、表201中、表203中，垂线编号、层面编号的类型为数值型，而表202中二者均为字符型。表203、表204、表205、表206、表209、表210中，采样时间的类型为T（12），表201、表202、表207、表208、表211、表212、表214、表215中为T。（河北）
临测信息类表中的采样时间定义长度不一致，如：37、41、66、71、80、83、87页中的T，应与其他表统一为T（12）。（山东）
答：采纳。统一为T。
28、细菌总数在监测数据中出现：>23800、<9等情况，将其数据类型定义为数值型数据，不能解决“>”、“<”的问题。（河北）
答：采纳。已经细菌总数等项目改为字符型，在应用系统中通过数据类型转换后
进行评价。
29、表304中，评价方法只限定为“单因子评价方法、以评价河长为权重的综合评价方法”两种，是否欠妥？因为日益丰富的社会需求，使得评价方法有了长足的发展，早已打破了两种评价方法一统天下的局面。（河北）
答：采纳。表304中已做出了相应修改。
30、根据新规范的要求，对于小于检出限的监测结果用“ 当某项目检出结果小于检出限时，如何录入？如砷化物未检出时，填“<0.007mg/L”，而以上《规定》中对这些有检测限的项目的检测结果只定义为数字型。（贵州） 答：采纳。建议在应用系统开发中以一个特别数（如-1）来表示 31、表体中有些字段的长度描述和表体后说明中同一字段描述不一致，应统一。如：31页：N（6，2）应为N（6，1）；32页：“计至小数后二位”应为“计至小数后三位”，等等。（山东） 答：采纳。 32、临测信息类表中的采样时间是一个年月日时的合成时间，建议增加一个年份字段（YEAR），以便于用户通过SQL直接查询，对库应用软件设计也有好处。（山东） 答：不予采纳。应用软件解决此类问题并不复杂，增加YEAR字段造成不必要的数据冗余。 33、有些表包含项目太少，建议合并，如A1.11、A1.12与A1.14合并。（山东）答：不予采纳。这些表所含项目间没有必然联系。 34、本标准不一定全部涵盖各单位所需内容，建议各建库单位可根据需要自定义库表结构和字段。（山东） 答：不予采纳。本标准提供水质数据库基本表结构，各建库单位必须执行，以便数据共享，信息交换。有关单位的特殊需要，应在业务软件的编制中考虑，与本数据库标准无关。 35、关于确定监测河段（A1.2.2）的建议：在全国水功能区划及各省水功能区划确定报批以后，地表水水质监测、评价的重点对象应为水功能区，监测评价的基本单元也应以水功能区为主。因此，在合理确定水功能区控制断面的前提下，测站监测河段（测站代表河长）应为水功能区控制断面所代表的相应水功能区的长度。（山东） 答：采纳。 36、P86 A2.13排污口，排放方式，连续或间歇未表达。（珠委水文局） 答：采纳。 37、P12：表编号：101 表7行“河流名称”建议改为“水域名称”，因为若为“湖库”类，有多条垂线组成测站，搞水质的甚至将每条垂线作为一个“测站”（“每一断面作一测站”这一点与水量方面有些不同）。（珠委水文局） 答：采纳。 38、由于已有部颁“中国河流名称代码”（SL249-1999），建议测站编码的前8位就以该代码为准，再加2~3位代表“测站补足号码”，这样就与水量方面的成果相衔接。多加的2~3位其中一位用于表示“测站级别”。（珠委水文局） 答：不予采纳。测站编码应统一按照水利部文件《关于印发《水文测站编码》的通知》（水文[2003]7号）要求执行。 39、监测信息表中的监测指标，个别指标与GB3838-2002的名称相左，建议增加在GB3838-2002中有而本信息表中没有的指标，如“汞”（本表有“总汞”而无“汞”，有“总砷”而无“砷”等）。（珠委水文局） 答：采纳。 40、“A1.5入河排污口基本信息表”部分，应增加排污口经纬度、汇入河道名称等相关信息。（松辽水保局） 答：部分采纳。采纳排污口汇入河道名称；排污口间距离过近，区分起来经纬度精度要求过高，在实际工作中用处也不大，不予采纳。 41、“A1.5.4排放方式”一项，应增加暗管、潜没的排放方式，并规定其相应的代码。（松辽水保局） 答：不予采纳。原排放方式中涵管已包括暗管、潜没的排放方式。 42、“A1.3.2测井类型”中，应增加潜层、承压井混合井（浅深层混合井）。（松辽水保局） 答：采纳。 43、是否需要将管理单位、监测单位从A1.1 拆分出去？（淮委水保局） 答：不予采纳。管理单位、监测单位是测站信息的重要组成部分，不应拆分。 44、是否需要将流域名称、水系名称从A1.1和A1.6拆分出去？（淮委水保局）答：不予采纳。流域名称、水系名称是测站信息的重要组成部分，不应拆分。 45、A1.13湖库与测站关系是否为“一对一”？如果不是，应拆分出湖库基本表。（淮委水保局） 答：采纳。 46、A2.1-A2.9可作为视图（子模式），模式上应合并为一基表。原则是不能让用户重复输入九次主键。（淮委水保局） 答：不予采纳。A2.1-A2.9是根据项目的不同性质划分的，数据输入问题应由应用系统开发解决，与本数据库标准无关。 47、如何排污口排污量统计表应增加COD、氨氮、总磷、总氮、BOD、挥发酚等。（淮委水保局） 答：采纳。 48、“水质表结构”中有些字段的标识符采用了计算机的保留字，在编应用程序时易与计算机编程语言冲突。 A2.1表气温(AT)，标识符AT建议用AIRT代替； A2.2表溶解氧(DO)，标识符DO建议用DOX代替； A2.2表总砷(AS)，标识符AS建议用TAS代替。（长委水文局） 答：采纳。 49、“水质表结构”中有些字段的标识符、类型前后不一致。如： A2.2表垂线编号(PRPNM)，类型及长度为C(1)，而表A2.1、表A2.3、表A2.4等为N(1)，建议统一改为N(1)； A2.2表层面编号(LYNM)，类型及长度为C(1)，同样表A2.1、表A2.3、表A2.4等为N(1)，建议统一改为N(1)； A2.7、A2.8表测站编码(STCD)，类型及长度为N(8)，而其他表均为C(8)，建议统一改为C(8)； A2.7、A2.8表垂线编号标识符为PRPNO，而其他表该栏均为PRPNM，建议统一改为PRPNM。（长委水文局） 答：采纳。 50、同一字段在《规定》前后描述不一致。 部分表中采样时间(GETM)类型及长度用T表示，而表A2.3、A2.4、A2.5、A2.6、A2.9、A2.10中采样时间(GETM)类型及长度表示为T(12)，建议统一改为T。（长委水文局） 答：采纳。 51、该《规定》中计量单位打印不规范，部分单位如：“km”打印为“Km”，“km2”打印为“Km2”；A3.2评价对象基本评价表中评价库容EVR的计量单位“百万m3”打印成“百万m2”。（长委水文局） 答：采纳。 52、A1.1.3测站级别表，建议增加省界断面标识，如：用代码“5”，表示省界断面。（长委水文局） 答：不予采纳。表A1.2地表水水质监测站信息表中测站功能项目已包括省界断面。 53、A1.2.2监测河段表，具体描述方法规则1、2对监测河段的描述方法与年报资料监测河段的描述方法规则不一致。（长委水文局） 答：不予采纳。应该采用新方法。 54、《地表水环境质量标准》（GB3838-2002）中地表水和湖库的总磷评价标准不同，故A3.1.2样品分类表需要增加分类代码，否则会影响湖、库的水质评价，建议用代码“12”表示湖库。（长委水文局） 答：采纳。 55、《规定》中监测项目的有限性和固定性 水质监测项目是随着社会经济的发展以及水域特征而发生变化，目前《规定》中表结构所包括的地表水必测和选测项目是现行《水环境监测规范》（SL219－98）的所列项目，若增加新的监测项目将会出现无处存储的现象。（长委水文 局） 答：不予采纳。本数据库在监测项目的选择上考虑到了水质监测的发展，基本涵盖了未来监测中的新增项目。 56、《规定》中数据精度局限了新仪器的高精度 目前《规定》中字段数据定义是根据现阶段的精度情况进行规定的，可以预见随着高精度先进仪器的使用，某些水质因子的精度会超过《规定》所定的精度，新仪器的精度在数据库中将会无法体现。（长委水文局） 答：不予采纳。本数据库在监测项目精度的设置上考虑到了水质监测的发展，应该能够满足新仪器设备的精度需要。 数据库复习资料 一名词解释 1.数据库 2.候选码 若关系中的一个属性组的值能够唯一地标识一个元组，则称做候选码。 3.外码 “外码”在数据库中是相对主码而言的，即外键（用于建立和加强两个表数据之间的链接的一列或多列）。 4. 关系 实体与实体之间的各种联系 5. 游标 6. 逻辑独立性和物理独立性 7. 日志事件 在数据库中用事务日志文件记录数据的修改操作，其中的每条日志记录或者记录所执行的逻辑操作，或者记录已修改数据的前像和后像。前像是操作执行前的数据复本； 后像是操作执行后的数据复本 8. 数据转储 数据转储是数据库恢复中采用的基本技术。所谓转储即DBA定期地将数据库复制到磁带或另一个磁盘上保存起来的过程。当数据库遭到破坏后可以将后备副本重新装入，将数据库恢复到转储时的状态。 9. 函数依赖 函数依赖简单点说就是：某个属性集决定另一个属性集时，称另一属性集依赖于该属性集。 设R(U)是一个属性集U上的关系模式，X和Y是U的子集。若对于R(U)的任意两个可能的关系r1、r2，若r1[x]=r2[x],则r1[y]=r2[y]，或者若r1[x]不等于r2[x],则r1[y]不等于r2[y]，称X决定Y，或者Y依赖X。 10.完全函数依赖和部分函数依赖 完全函数依赖 设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’→Y，则称Y完全函数依赖于X。 部分函数依赖 设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则 称Y部分函数依赖于X。 11.数据库设计 12.数据库恢复 数据库恢复是指通过技术手段，将保存在数据库中丢失的电子数据进行抢救和恢复的技术。 13.封锁 封锁就是事务T在对某个数据对象（例如表、记录等）操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象。 14.规范化 规范化理论正是用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、更新异常和数据冗余问题。 ECShop 2.7.2版本，数据库表 版本：2010年09月14日，初稿，有待完善。 说明：ECShop 2.7.2版本的数据库表，共88张表。 注： 1、颜色为蓝色的字，是本人所写，有待讨论验证的地方。 2、颜色为红色的字，是新增的字段。（改文档是基于网上下载的老版本的数据字典修改而成，已经检查了所有字段，修改的修改，增加的增加）。 ecs_account_log //用户账目日志表 ecs_ad //广告表(位置,类型,名称,链接,图片,开始,结束,广告主相关信息,点击是否显示) ecs_admin_action //管理权限分配(父类ID，权限代码)（感觉像是规定好的一些数据，安装的时候就有） ecs_admin_log //管理日志(登陆时间,登陆ID,操作描述,IP) ecs_admin_message //管理留言(发送id,接收id,发送日期,阅读日期,是否已读,是否删除,标题，内容) ecs_admin_user //管理员管理(用户名,email,密码,加入时间,最后登陆时间,最后登陆IP，权限等) ecs_adsense //广告相关统计(来源广告,来源位置,点击) ecs_ad_custom // ecs_ad_position //广告位(名称,宽,高,描述,样式) ecs_affiliate_log //（用户推荐的操作日志？） ecs_agency //广告相关统计(来源广告,来源位置,点击) ecs_area_region //配送区域关联(配送区域ID,具体地址ID) ecs_article //文章(分类ID,标题,内容,作者,作者email,关键字, 类型,是否显示,添加时间,文件地址,打开类型) ecs_article_cat //文章分类(名称,类型,关键字,描述,排序,是否导航显示) ecs_attribute //商品属性 数据库设计和编码规范 Version 目录 简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错，保持团队支持顺畅，系统长久使用后不至于紊乱，让管理者易于在众多对象中，获取所需或理清问题。 同时，定义标准程序也需要团队合作，讨论出大家愿意遵循的规范。随着时间演进，还需要逐步校订与修改规范，让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契，而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户，如数据库管理员、程序设计人员和程序开发人员，可以直观地辨识对象用途。而命名规则大都约定俗成，可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例，让用户混淆自定义对象和系统对象或关键词。 例如，存储过程不要以sp_或xp_开头，因为SQL SERVER的系统存储过程以 sp_开头，扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略，要让对象的用途直观易懂，但也不宜过长，造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。 6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定，数据库对象包括表、视图（查询）、存储过程（参数查询）、函数、约束。对象名字由前缀和实际名字组成，长度不超过30。避免中文和保留关键字，做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串，而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范，通过后严格按照要求实施。例如： 库存管理系统数据库设计 系统需求分析： 入库管理： 供货单位将货物连同填好的入库单一起送到仓库，仓库管理员将验收货物，首先将货物的代码、类型、规格和数量与入库单进行核对，在核对无误后将货物按名称分类入库，并填写货物入库登记表。 出库管理： 提货单位向仓库保管员出示出库单，仓库保管员根据有效产品出库单及时付货，取货人员将货物与出库单核对无误后，提取货物，同时把出库单交给仓库保管员，仓库保管员则按照出库单登记货物的出库信息。 库存管理： 每天入库、出库处理结束后，仓库管理员将根据入库登记表和出库登记表对货物分别进行累计，并将累计结果填入库存台账； 数据流图 数据字典 1.数据项 入库单号 数据项名：入库单号 说明：标识货物的入库登记表 类型：CHAR 长度：10 别名：空 取值范围：（10000000000，9999999999）2.数据结构 ?入库单 数据结构名：入库单 说明：入库货物的入库单号，入库产品代码、货物类型、规格和数量。 组成：入库单号，入库产品代码、货物类型、规格和数量 3.数据流 ?入库登记 数据流名：入库登记 说明：货物连同填好的入库单一起送到仓库时，仓库管理员依据入库单验收产品，在核对无误后将产品按名称分类入库，同时对入库的货物做登记，以便于仓库的管理。 数据流来源：仓库管理员 数据流去向：货物 数据结构：入库登记表 数据结构名：入库登记表 说明：入库货物的入库单号，入库产品代码，入库数量， 入库时间等 组成：入库日期、入库单号、货物编码、数量、进货价、 总额、已付货款、供货单位编码、供货单位、经办人编 码、经办人、增值税率、备注 4.数据存储 Ecshop 2.7.0数据库表结构 绿色：ecshop2.7.0当中的数据库。86个数据表 蓝色：ecshop2.7.0没有的! 蓝色：ecshop2.5.0在ecshop 2.7.0中没有的。。（追加进去的） ===================================================================================== ecs_account_log//用户账目日志表（log_id user_id user_money froz en_money rank_points pay_points change_time change_desc change_type） ecs_activity//活动表（代码，名称，开始，结束，描述） ecs_ad//广告表（广告序号，广告位置，媒体类型，名称，链接，上传广告图片，开始，结束，广告联系人信息，点击，是否显示） ad_id position_id media_type ad_name ad_link ad_code start_time end_time link_man link_email link_phone click_count enabled ecs_admin_action//管理权限分配（父类ID，权限代码） action_id parent_id action_code ecs_admin_log//管理日志（登陆时间，登陆管理员ID，操作描述，IP） log_id log_time user_id log_info ip_address ecs_admin_message//管理员留言（发送者ID，接收者ID，发送日期，阅读日期，是否 已读，是否删除，标题，内容） ecs_admin_user//管理员管理（用户名，email，密码，加入时间，最后登陆时间，最后 登陆IP，权限等） ecs_adsense//广告相关统计（来源广告，来源位置，点击） ecs_ad_custom//广告客户（ad_id,ad_type,ad_name,add_time,content,url,ad_status）ecs_ad_position//广告位（名称，宽，高，描述，样式） position_id position_name ad_width ad_height position_desc position_style ecs_affiliate_log//?（名称，宽，高，描述，样式） ecs_agency//?（名称，宽，高，描述，样式） 实时工情数据库表结构及标识符 ICSCCS中华人民共和国水利行业标准SL实时工情数据库表结构及标识符 Standardforstructureandidentifierinreal-timeengineeringinformationdatabaseoffloodampd roughtmanagement征求意见稿发布发布发布发布实施实施实施实施中华人民共和国水利部中华人民共和国水利部中华人民共和国水利部中华人民共和国水利部发布发布发布发布SL目次1范 围.................................................................. ........................................................................ .....12规范性引用文 件.................................................................. .........................................................13术语和定义...................................................................... .............................................................14表结构设计.................................................................. .................................................................24.1基本内 容.................................................................. .........................................................24.2数据类型...................................................................... .....................................................35标识符设 一、需求分析 1.系统分析 随着时代的进步，如今各个服务行业也都逐渐发展壮大起来，尤其是食堂服务业，其在服务范围、服务数量和服务内容上都有着非常大的膨胀幅度，因此如何对如此复杂而频繁的服务活动进行管理就属于“食堂管理”的内容。其主要包括：职员资料管理、物品管理、消费内容管理、席位管理、客户评价管理，工资管理等，它是现代食堂管理中的一个重要组成部分。 2.功能需求分析 “食堂管理” 包括很多项目，以前食堂管理人员要记录大量的用户消费内容，然后通过计算器进行一系列的加减乘除运算，最后得出一位顾客的“应付金额”，这样做的效率和准确度可想而知。如果使用计算机来实现对食堂服务业的智能管理，从选择菜、酒水、主食，到计算“应付金额”，最后到打印消费内容，计算机都可以很准确、很快捷地进行处理，这些都是“食堂管理系统”的功能。一个完善的“食堂管理系统”可以很好地管理食堂服务业的各项内容，这样不仅能更好地服务顾客，而且可以为经营者创造更大的利润。 针对每部分的具体功能我们又做了如下的详细分析： 二、涉及的表 职员资料 物品表 席位表 销售记录 评价情况 工资表 SQL 命令 创建数据库 create database 食堂管理系统 on primary (name= stglxt_data,'e:\stglxt_data.mdf') log on (name=stglxt_log1,'e:\stglxt _log.ldf') 创建表 create table 职员资料 (职员编号char(6) not null primary key check(职员编号like'[0-9][0-9][0-9][0-9][0-9][0-9]'), 姓名varchar(20) not null, 职位varchar(20) not null, 性别char(2) not null check(性别='男' or 性别='女') default '男', 民族varchar(8) null default '汉族', 出生日期datetime not null, 身份证号码char(18) not null unique, 婚姻状况char(4) not null check(婚姻状况='已婚' or 婚姻状况='未婚') default '未婚', 联系电话varchar(11) not null unique, 备注varchar(30) ) create table 物品表 (物品编号 char(6) not null primary key, 物品名字 varchar(20) not null, 所属类型 char(4) not null check(所属类型='主食'or 所属类型='酒水' or 所属类型='其他') default '主食', 价格 money not null, 是否售馨 char(2) not null check(是否售馨='是' or 是否售馨='否') default '否', 品牌 varchar(30), 备注 varchar(30) ) create table 席位表 (席位号char(6) not null primary key, 负责人编号char(6) not null foreign key references 职员资料(职员编号) on update cascade on delete cascade, 人数int not null, 状态char(4) not null check(状态='使用' or 状态='预定' or 状态='空闲') default '空闲', 日期datetime not null, 备注varchar(30) 某制造企业销售管理系统数据库设计 一、需求分析 （一）业务流程： 1、销售部统计商品信息，向客户发布商品信息。 2、客户根据销售部发布的商品信息，向销售部发送订单。 3、销售部将订单发送给主管部门审核。 4、主管部门对订单进行核对： （1）如果不批准订单，主管部门向客户发布不批准的信息； （2）如果批准，主管部门向客户发布批准的信息；销售部获取批准的订单，核对客户信息，登记新客户的基本资料或修改原有客户的基本资料，同时及时发布商品修改后的信息；生产部门接受订单，生产客户所需的商品，生产完成后，将发货单与商品一同发出。 5、客户确认发货单。 （二）数据流程图 员客客 填写上报核对确认 P3发货P2订单基本信息处理订单P1基本处理处理信息 客户信息员工信息 销售管理系统第一层数据流程图 第二层数据流程图： 核对员工客户上报填写 客P1.1员P1.2 户信息工信息 客户信息员工信息 P1 基本信息 客主管部 订单数审P2.P2.P2.理订核订预订订下 发货确认预订单商品信息订单 信贷状况客户 P2订单处理 （三）数据字典 1、订单号数据项可以描述如下 : 数据项 : 订单号 含义说明 : 唯一标识每张订单 别名 : 订单编号 类型 : 字符型 长度 : 4 取值范围 : 0000至 9999 取值含义 : 前 2 位标别所在地区，后 2 位按顺序编号 与其他数据项的逻辑关系 :唯一识别订单 2、商品信息是该系统中的一个重要数据结构，它可以描述如下 : 数据结构 : 商品信息 含义说明 : 是销售管理系统的重要数据结构，定义了销售商品的具体信息组成 : 产品号，产品名，单价，重量 3、数据流“订单数据可描述如下 : 数据流 : 订单数据 说明 : 客户选购商品所下的初始订单 数据流来源 : 客户 数据流去向 : 接受订单 组成 : 客户基本信息＋商品编号＋数量等 平均流量 : 5张／天 高峰期流量 : 100张／天 4、数据存储“订单可描述如下 : 数据存储 : 订单表 说明 : 记录每张订单的具体情况 流入数据流 : 订单处理 流出数据流 : …… 订单号，客户编号，产品，数量，单价等 : 组成 数据量 : 每年2000张 存取方式 : 随机存取 5、处理过程“接收订单尠可描述如下 : 处理过程 : 接收订单 说明 : 核准客户所下订单 输入 : 订单数据，商品信息，主管审批 输出 : 核对订单至主管部门，是否确认信息给客户 处理 : 接收到客户订购产品的初始订单后，根据商品信息以及客户以往 ECshop 数据库表结构分析三 2011-06-22 17:43 -- ------------------------------------------------------ -- 表的结构`ecs_order_info` CREATE TABLE IF NOT EXISTS `ecs_order_info` ( `order_id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT COMMENT '订单详细信息自增id', `order_sn` varchar(20) NOT NULL COMMENT '订单号，唯一', `user_id` mediumint(8) unsigned NOT NULL DEFAULT '0' COMMENT '用户id，同ecs_users 的user_id', `order_status` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '订单状态。0，未确认；1，已确认；2，已取消；3，无效；4，退货；', `shipping_status` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '商品配送情况，0，未发货；1，已发货；2，已收货；3，备货中', `pay_status` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '支付状态；0，未付款；1，付款中；2，已付款', `consignee` varchar(60) NOT NULL COMMENT '收货人的姓名，用户页面填写，默认取值于表user_address', `country` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT '收货人的国家，用户页面填写，默认取值于表user_address，其id对应的值在ecs_region', `province` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT '收货人的省份，用户页面填写，默认取值于表user_address，其id对应的值在ecs_region', `city` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT '收货人的城市，用户页面填写，默认取值于表user_address，其id对应的值在ecs_region', `district` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT '收货人的地区，用户页面填写，默认取值于表user_address，其id对应的值在ecs_region', `address` varchar(255) NOT NULL COMMENT '收货人的详细地址，用户页面填写，默认取值于表user_address', `zipcode` varchar(60) NOT NULL COMMENT '收货人的邮编，用户页面填写，默认取值于表user_address', `tel` varchar(60) NOT NULL COMMENT '收货人的电话，用户页面填写，默认取值于表user_address', `mobile` varchar(60) NOT NULL COMMENT '收货人的手机，用户页面填写，默认取值于表user_address', `email` varchar(60) NOT NULL COMMENT '收货人的手机，用户页面填写，默认取值于表user_address', `best_time` varchar(120) NOT NULL COMMENT '收货人的最佳送货时间，用户页面填写，默认取值于表user_address', `sign_building` varchar(120) NOT NULL COMMENT '收货人的地址的标志性建筑，用户页面填写，默认取值于表user_address', `postscript` varchar(255) NOT NULL COMMENT '订单附言，由用户提交订单前填写', `shipping_id` tinyint(3) NOT NULL DEFAULT '0' COMMENT '用户选择的配送方式id，取值表ecs_shipping', `shipping_name` varchar(120) NOT NULL COMMENT '用户选择的配送方式的名称，取值表 气象数据集说明文档 1.数据集信息 数据集中文名称：中国农作物生长发育状况资料数据集 数据集代码：AGME_AB2_CHN_TEN 数据集版本：1.0 数据集建立时间：200603 2.数据来源：根据1991年以来中国农业气象台站上报的农业气象旬月报报文资料整理而得，其中一部分资料来自国家气候中心农气室，一部分资料来自国家气象中心9210要素库。 3.数据集实体 3.1.数据集实体内容说明 3.1.1.数据集实体文件名称： AGME_AB2_CHN_TEN-yyyymmdd.TXT 其中，yyyy为年、mm为月、dd为旬标记（01、11、21分别表示上、中、下旬）。 3.1.2.数据集实体文件的内容描述： 1991年以来中国农业气象台站上报的农业气象旬月报报文资料整理而得农作 3.1.3.特征值说明： 数据中-9999表示资料缺测。 站名为XXXX,表示站名不详。. 省名为XX,表示省名不详。 3.2.数据存储信息 3.2.1.存取格式和读取：数据集实体文件为文本格式，每行数据顺序为：每个数据之间用“，”分隔。站号,站名,省称,经度,纬度, 测站高度，年,月,旬,作物名称,发育期名称,发育期日期,发育程度,发育期距平,植株高度,生长状况,植株密度,到本旬末积温,积温距平,干土层厚度,10厘米土壤相对湿度,20厘米土壤相对湿度,30厘米土壤相对湿度,40厘米土壤相对湿度,50厘米土壤相对湿度,70厘米土壤相对湿度,100厘米土壤相对湿度,灌溉标志,土壤湿度测定方法。每个数据之间用“，”分隔。 3.2.2.数据集在介质中的放置 存取介质及数量：光盘1张 存储目录结构： （1）datasets：存放数据集实体文件，共存放了174个数据文件。 （2）metadata：元数据文档。 （3）description：数据集说明文档。 （4）documents：台站信息文件，文件名为：AGME_AB2_CHN_TEN_STATION.TXT。 数据总量：28.3MB 3.3.时间属性 时间范围：199109-999999 观测时次：每旬一次观测。 3.4.空间属性 3.4.1.地理范围 地理范围描述：中国 最西经度：73.66E 最东经度：135.08E 最北纬度：53.52N 最南纬度：4.00N 3.4.2.台站信息：见“documents”目录下的台站信息文件，文件名为“AGME_AB2_CHN_TEN_STATION.TXT”。 3.4.3.空间分辨率：778站. 3.4.4.垂直范围：地面 3.4.5.投影方式：无 3.5.观测仪器：见引用文献（1） 3.6.数据处理方法： 为使两种不同来源的资料具有相同的格式和表示方法，我们以农气室提供的资料为蓝本，将实时接收的资料按此格式进行转换。同时，为了兼顾使用上的习惯，对原格式亦进行了少量的修改。主要是： 1）原格式中处于第三列的区站号提前到第一列的位置； 2）将原格式中的台站经纬度进行舍入，只保留少数点后两位； 3）将原格式中的全角逗号换成半角逗号。 3.7.数据质量状况 3.7.1质量控制方法：没有进行质量控制 3.7.2质量状况：一般 3.8.数据完整性：各台站资料起止时间及来报情况见“documents”目录下的台站信息文件：AGME_AB2_CHN_TEN_STATION.TXT 4.引用文献： （1）国家气象局监测网络司编定，地面气象电码手册，北京：气象出版社，1999。 （2）国家气象中心编定，实时气象数据库实用手册，内部刊物。 5.数据集制作及技术支持 5.1.数据集制作人 姓名：汪万林 编号：002 版本：数据库设计说明书 项目名称： 委托单位： 承担单位： 编写：年月日 校对：年月日 审核: 年月日 《数据库设计说明书》的编制，是对于设计中的数据库的所有标识、逻辑结构和物理结构做出具体的设计规定。《数据库设计说明书》编制指导如下。 1引言 1.1编写说明 说明编写这份《数据库设计说明书》的目的，指出预期的读者。 1.2背景 说明待开发数据库的名称、版本号说明、使用范围并列出本项目的任务提出者和开发者。 1.3 修订审批记录 说明编写这份《数据库设计说明书》的修订过程、审批过程。参见文档修订记录表及文档审批记录表。 表1 文档修订记录表 1.4术语和缩写词 列出本文件中用到的专门术语的定义、外文首字母组词的原词组。 1.5参考资料 列出本文件中用到的参考资料（参考格式：作者、名称、出版单位、发表日期等）。 2外部设计 2.1标识符和状态 列出用于标识该数据库的编码、名称、标识符或标号，并给出附加的描述性信息。如果该数据库是在实验中的或者暂时性的，则要说明这一特点和有效期。 2.2使用该数据库的程序 列出将要使用或访问此数据库的所有应用程序，给出其名称和版本号。 2.3约定 叙述使用该数据库所必须了解的建立标号、标识的有关约定。例如，用于标识库内各个文卷、记录、数据项的命名约定等。 2.5支持软件 叙述与此数据库有关的支持软件，如数据库管理系统、存储定位程序等。概要说明这些支持软件的名称、功能及为使用这些支持软件所需的操作命令。列出这些支持软件的有关资料。 2.6专门说明 向准备从事此数据库的生成、测试、维护人员所提供的专门说明。 3结构设计 在概念结构设计和逻辑结构设计部分仅需描述与新增表、修订表有关的内容，可以引用未做修改的表，但不进行详细描述，系统完整的数据库逻辑结构做为附件附在该文档之后。数据库逻辑结构字典格式参见附件1。 3.1概念结构设计 详细说明本数据库的用户视图，即反映现实世界中的实体、属性和它们之间关系的原始数据形式。包括各数据项、记录、数据表的标识符、定义、类型、计量单位和值域；描述数据模型的设计考虑，并绘制E_R图。 3.2逻辑结构设计 详细说明本数据库的数据库管理员视图，即把上述原始数据进行分解、合并后重新组织起来的数据库全局逻辑结构，包括所确定的关键字和属性、重新确定的记录结构和数据表结构、所建立的各个数据表之间的相互关系，并参照新疆油田公司《勘探开发数据库数据表编码规范（Q/SY XJ0204-2009）》以及《数据库逻辑结构管理规范（Q/SY XJ0205-2009）》等相关标准设计《数据库逻辑结构》。并绘制E_R图，要求达到第二范式。 3.3物理结构设计 详细说明本数据库的系统程序员视图，即数据在内存中的安排，包括对索引区、缓冲区的设计；所使用的外存设备及外存空间的组织，包括索引区、数据块的组织与划分以及访问数据的方式方法。 4、应用设计 详细说明数据库应用开发所产生的存储过程、包、视图、函数、触发器等设计，并做为附件附在该文档之后。具体格式参见附件2。 5、其它设计 5.1完整性设计 说明为保持数据库中数据的完整性所作的设计考虑，如数据库的后援频率、数据共享、数据冗余等。 5.2安全保密设计 说明在数据库的设计中，将如何通过区分不同的访问者、不同的访问类型和不同的数据对象等而获得数据库安全保密的设计考虑。以及将要采用的保证数据安全保密的措施和机制，如数据库安全破坏标识、资源保护方式、存取控制方式等。 5.3 其它设计 说明其它设计考虑。 高校图书管理系统数据库物理结构设计 一、设计前要了解的信息（该部分不出现在设计说明书中） 1、数据库的查询事务 (1)按卡号查询读者信息及借书信息（查询读者借书信息时涉及读者、图书和借还关系的连接操作，连接属性：卡号、书号）。 (2)按姓名查询读者信息及借书信息（查询读者借书信息时涉及读者、图书和借还关系的连接操作，连接属性：卡号、书号）。 (3)按书名查询图书信息。 (4)按作者和出版社查询图书信息。 (5)按出版社统计图书信息。 (6)按书号查询图书被借信息（查询图书被借信息时涉及读者、图书和借还关系的连接操作，连接属性：卡号、书号）。 (7)按书名查询图书被借信息（查询图书被借信息时涉及读者、图书和借还关系的连接操作，连接属性：卡号、书号）。 2、数据库的更新事务 (1)办理借书证（读者注册）。 (2)借书（增加借还记录、修改图书的库存数量）。 (3)还书（修改借还记录、修改图书的库存数量）。 3、查询事务的操作频率和性能要求 (1)按卡号查询读者信息及借书信息 操作频率：200次/天 性能要求：3s内完成 (2)按姓名查询读者信息及借书信息 操作频率：80次/天 性能要求：5s内完成 (3)按书名查询图书信息 操作频率：250次/天 性能要求：3s内完成 (4)按作者和出版社查询图书信息 操作频率：250次/天 性能要求：3s内完成 (5)按出版社统计图书信息 操作频率：1次/月 性能要求：10s内完成 (6)按书号查询图书被借信息 操作频率：10次/月 性能要求：6s内完成 (7)按书名查询图书被借信息 操作频率：10次/月 性能要求：6s内完成 二、设计结果 1、数据库名称 Book_Borrow 2、关系表 主键：lbdm 主键：kh 索引：xm(升序) check约束：性别的取值只能为男或女 default约束：性别默认为男 四、地面气象观测数据文件格式 1、总则 1.1地面气象观测数据是认识和预测天气变化、探索气候演变规律、进行科学研究和提供气象服务的基础，是我国天气气候监测网收集的最重要的资料之一。为适应地面气象观测业务的发展，有必要对2001年版的“全国地面气象资料数据模式”（简称2001年版A格式）进行补充、修改。 1.2 本格式以中国气象局2003年版《地面气象观测规范》中的“地面气象记录月报表”为依据，对2001年版A格式作了必要的修改和补充，并将格式命名为“地面气象观测数据文件格式”，作为原“全国地面气象资料数据模式”的2003年版。 1.3本格式由一个站月的原始观测数据、数据质量控制标识及相应的台站附加信息构成，包括A文件和J文件两个文件，附加信息即2001年版的“气表-1封面、封底V文件”，作为A文件的一部分。因此本格式涵盖了气表-1的全部内容。 1.4 根据2003年版的《地面气象观测规范》，本格式在2001年版A格式基础上增加了相关的要素项目；为了更好地表述数据质量，增加了数据质量控制标识。观测数据部分历史资料中的技术规定可参照“全国地面气象资料信息化基本模式暂行规定”和“补充规定”，本格式不再赘述。 1.5 根据2003年版《地面气象观测规范》的规定，本格式将2001年版单要素分钟降水量J 文件更改为多要素分钟观测数据文件，作为A文件的补充，简称J文件。 1.6 2001年版与2003年版A、J格式具体变动内容见附件“2001年版与2003年版格式变动对照表”。 1.7 本格式适用于我国现行各类地面气象台站和不同观测仪器采集的数据。 2、A文件 2.1 文件名 “地面气象观测数据文件”（简称A文件）为文本文件，文件名由17位字母、数字、符号组成，其结构为“AIIiii-YYYYMM.TXT”。 其中“A”为文件类别标识符（保留字）；“IIiii”为区站号；“YYYY”为资料年份；“MM”为资料月份，位数不足，高位补“0”；“TXT“为文件扩展名。 2.2 文件结构 A文件由台站参数、观测数据、质量控制、附加信息四个部分构成。观测数据部分的结束符为“??????”，质量控制部分的结束符为“******”，附加信息部分的结束符为“######”。具体结构详见附录1：A文件基本结构。 2.3 台站参数 台站参数是文件的第一条记录，由12组数据构成，排列顺序为区站号、纬度、经度、观测场拔海高度、气压感应器拔海高度、风速感应器距地（平台）高度、观测平台距地高度、观测方式和测站类别、观测项目标识、质量控制指示码、年份、月份。各组数据间隔符为1 位空格。 2.3.1 区站号（IIiii），由5位数字组成，前2位为区号，后3位为站号。 2.3.2 纬度（QQQQQ），由4位数字加一位字母组成，前4位为纬度，其中1～2位为度，3～4位为分，位数不足，高位补“0”。最后一位“S”、“N”分别表示南、北纬。 2.3.3 经度（LLLLLL），由5位数字加一位字母组成，前5位为经度，其中1～3位为度，4～5位为分，位数不足，高位补“0”。最后一位“E”、“W”分别表示东、西经。 2.3.4 观测场拔海高度（H1H1H1H1H1H1），由6位数字组成，第一位为拔海高度参数，实测 ECShop2.5.1_Beta upload 的目录 ┣activity.php 活动列表 ┣affiche.php 广告处理文件 ┣affiliate.php 生成商品列表 ┣article.php 文章内容 ┣article_cat.php文章分类 ┣auction.php 拍卖前台文件 ┣brand.php 品牌列表 ┣captcha.php 生成验证码 ┣catalog.php 列出所以分类及品牌 ┣category.php 商品分类 ┣comment.php 提交用户评论 ┣compare.php 商品比较程序 ┣cycle_image.php 轮播图片程序 ┣feed.php RSS Feed 生成程序 ┣flow.php 购物流程 ┣gallery.php 商品相册 ┣goods.php 商品详情 ┣goods_script.php 生成商品列表 ┣group_buy.php 团购商品前台文件 ┣index.php 首页文件 ┣myship.php 支付配送DEMO ┣pick_out.php 选购中心 ┣receive.php 处理收回确认的页面 ┣region.php 地区切换程序 ┣respond.php 支付响应页面 ┣robots.txt ┣search.php 搜索程序 ┣sitemaps.php google sitemap 文件 ┣snatch.php 夺宝奇兵前台页面 ┣tag_cloud.php 标签云 ┣topic.php 专题前台 ┣user.php 会员中心 ┣vote.php 调查程序 ┣wholesale.php 批发前台文件 ┣admin文件夹 ┃┣account_log.php 管理中心帐户变动记录 ┃┣admin_logs.php 记录管理员操作日志 ┃┣ads.php 广告管理程序 ┃┣adsense.php 站外JS投放的统计程序 ┃┣ad_position.php广告位置管理程序 ┃┣affiliate.php 程序说明 1、层次数据库结构 层次数据库结构将数据通过一对多或父结点对子结点的方式组织起来。一个层次数据库中，根表或父表位于一个类似于树形结构的最上方，它的子表中包含相关数据。层次数据库模型的结构就像是一棵倒转的树。 优点： ?快速的数据查询 ?便于管理数据的完整性 缺点： ?用户必须十分熟悉数据库结构 ?需要存储冗余数据 2、网状数据库结构 网状数据库结构是用连接指令或指针来组织数据的方式。数据间为多对多的关系。矢量数据描述时多用这种数据结构。 优点： ?快速的数据访问 ?用户可以从任何表开始访问其他表数据 ?便于开发更复杂的查询来检索数据 缺点： ?不便于数据库结构的修改 ?数据库结构的修改将直接影响访问数据库的应用程序 ?用户必须掌握数据库结构 3、关系数据库结构 这就目前最流行的数据库结构了。数据存储的主要载体是表，或相关数据组。有一对一、一对多、多对多三种表关系。表关联是通过引用完整性定义的，这是通过主码和外码（主键或外键）约束条件实现的。 优点： ?数据访问非常快 ?便于修改数据库结构 ?逻辑化表示数据，因此用户不需要知道数据是如何存储的 ?容易设计复杂的数据查询来检索数据 ?容易实现数据完整性 ?数据通常具有更高的准确性 ?支持标准SQL语言 缺点： ?很多情况下，必须将多个表的不同数据关联起来实现数据查询 ?用户必须熟悉表之间的关联关系 ?用户必须掌握SQL语言 4、面向对象数据库结构 它允许用对象的概念来定义与关系数据库交互。值得注意的是面向对象数据库设计思想与面向对象数据库管理系统理论不能混为一谈。前者是数据库用户定义数据库模式的思路，后者是数据库管理程序的思路。 面向对象数据库中有两个基本的结构：对象和字面量。对象是一种具有标识的数据结构，这些数据结构可以用来标识对象之间的相互关系。字面量是与对象相关的值，它没有标识符。 优点： ?程序员只需要掌握面向对象的概念，而不要掌握与面向对象概念以及关系数据库有关的存储 ?对象具有继承性，可以从其他对象继承属性集 ?大量应用软件的处理工作可以自动完成 ?从理论上说，更容易管理对象 ?面向对象数据模型与面向对象编程工具更兼容 缺点： idatis人力资源数据库设计 1．概述（设计题目与可行性分析） 1.1项目背景 当今科技高度发展，技术日新月异，社会的不断发展与进步，都时时刻刻离不开人才，人才才是国与国，企业与企业之间的核心竞争关键，人才是根本的生产力，特别是在当今社会，人才的重要性更是达到了巅峰，那么就国家，企业发展都是需要人才的，通过改革和创新，提高管理能力，提高核心竞争力，才是根本手段，因此，人力资源管理的重要性是无庸置疑的。 人力资源管理系统是基于先进的软件和高速、大容量的硬件基础上的新的人力资源管理模式，通过集中式的信息库、自动处理信息、员工自助服务、外协以及服务共享，达到降低成本、提高效率、改进员工服务模式的目的。它通过与企业现有的网络技术相联系，保证人力资源与日新月异的技术环境同步发展。一般来说，可以分四个部分来理解人力资源管理系统： (1) 管理人员角色和目标的改变 传统的人力资源管理中，管理人员的大部分精力将耗费在繁琐的日常行政事务处理上，而作为企业管理层的参谋角色应该作的咨询和策略制订的工作相对缺乏。通过人力资源管理，系统管理人员可以将绝大部分精力放在为管理层提供咨询、建议上，而在行政事务上的工作可以由电子化系统完成，只须占用HR人员极少的精力和时间。 (2) 提供更好的服务 人力资源管理系统可以迅速、有效地收集各种信息，加强内部的信息沟通。各种用户可以直接从系统中获得自己所需的各种信息，并根据相关的信息做出决策和相应的行动方案。(3) 降低成本 人力资源管理系统通过减少人力资源管理工作的操作成本、降低员工流动率、减少通信费用等达到降低企业运作成本的目的。 (4) 革新管理理念 人力资源管理系统的最终目的是达到革新企业的管理理念而不仅是改进管理方式，优化人力资源管理。先进技术应用于人力资源管理不仅仅是为了将现有的人力资源工作做得更好，更重要的是，做些对于企业来讲更有效率的事情，成为管理层的决策支持者，为决策提供信息和解决方案。 2．系统目标和建设原则 一个标准的人力资源管理系统应该包括如图所示的几大功能。除此之外系统还应包括信息系统必须具备的通用功能，例如系统管理、权限设置、数据备份与恢复等。 就本此课程设计而言，重点对下图所示的功能进行分析，如图所示该人力资源管理的功能设计图所示： 3．支撑环境规划 3.1 网络逻辑结构 本人事管理系统采用C/S （客户机/服务器）的网络结构。 人力资源管理系统 职员基本信息 职员考勤管理 部门信息 工资福利管理 招聘管理 职位信息数据库复习资料
ecshop_v2.7.2数据库表结构2012完善版
数据库设计和编码规范
库存管理系统数据库设计
ecshop数据库表结构
实时工情数据库表结构及标识符
食堂管理系统数据库设计
ecshop目录结构图
销售管理系统数据库设计
ecshop数据库表结构
气象数据集说明文档
04.数据库设计说明书
高校图书管理系统数据库物理结构设计
全国地面气象资料数据模式 A格式
ecshop连接数据库的文件是哪个
数据库结构分类
人力资源管理系统数据库设计
相关主题
文本预览