《2023年数据库教学设计（精选多篇）.docx》由会员分享，可在线阅读，更多相关《2023年数据库教学设计（精选多篇）.docx（90页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、2023年数据库教学设计（精选多篇） 推荐第1篇：数据库设计 开题报告 组长：叶燎 组员：李玉鹏 张梅 张洁 研究课题：高校学生信息管理系统设计 时间：2023.12.17 一、选题意义：随着现代科学技术的飞速发展、计算机与全球互连网络internet相连接，使今天的社会进入了以计算机为核心的社会。在信息社会中，信息的获取、处理、交流和决策都需要大量高质量的处理工具。在这高科技时代，信息的处理是十分重要，如果用原始的方式进行处理，我们就会跟不上时代的进展；我们需用高科技时代的产品。学生信息的管理是每个学校工作中一项非常重要的工作，要投入很大的人力进行管理。如果开发一套学生信息管理系统软件将具有
2、十分重要的意义，可以减少人力资源在这方面的投入，而更多的投入教学或其它工作中作为当代大学生，且以计算机专业为主的我们，在学习中缺乏实践，借此机会研究离我们当前最为实际的课题高校学生管信息理系统。 二、计划安排： 112.17：详细设计，设计系统模块及各个功能实现方式： 共三个模块：1，学生基本信息的录入、修改、查询、统计2，学生成绩的录入、修改、查询、统计3，毕业生学籍管理 212.18-12.21：编写代码，实现注册登陆模块，班级模块功能。 312.22-12.23：实现模块一的设计，可以进行学生相关信息的录入、修改和查询 412.24-12.25：实现模块二的设计，可以进行学生成绩的录入、
3、修改和查询及其选课表、补考表字段的设计。 512.26-12.27：实现模块三的设计，可以进行毕业生学籍管理 612.28：测试系统。 7实习总结编写 推荐第2篇：数据库设计 东北大学东软信息学院 数据库原理与应用 实验报告 姓名：班级：学号： 实验名称：数据库设计 实验日期： 实验目的： 实验要求： 业务需求： 银行有多个支行。每个支行位于一个特定的城市，由唯一的名字标识。银行监控每个支行的资产。 银行的客户通过其customer_id来标识。银行存储每个客户的姓名及其居住的街道和城市。客户可以有账户，并且可以贷款。客户可能同某个特定的银行员工发生联系，该员工作为该客户的贷款负责人或私人银行
4、助理。 银行员工通过其employe_id来标识。银行的管理机构存储每个员工的姓名、电话号码、亲属姓名及其经理的employee-id。银行还需要知道员工开始工作的日期。由此日期推知员工的雇佣日期。 银行提供储蓄存款账户。存款账户可以有两个或两个以上客户共有，一个客户也可以有两个或两个以上的账户。每个账户被赋以惟一的账户号。银行记录每个账户的余额以及每个账户所有者访问该账户的最近日期。另为还要记录相关的利率信息，还有其透支额。 每笔贷款由某个分支机构发放，能被一个或多个客户所共有。一笔贷款用一个唯一的贷款号标识。银行需要知道每笔贷款所贷金额以及逐次支付情况。虽然贷款的付款号并不能在银行的所有为
5、贷款所付款项中作为唯一标识，但可以唯一标识为某贷款的所还款项。对每次还款需要记载其日期和金额。 1 画出er图 2 设计出关系模式 3 用“_”画出关系模式的主码，用“ 实验结果/总结： 教师评语： 推荐第3篇：数据库设计 用户信息表allUsers userInfoId int 用户id username varcher(15) 用户名 nicename varchar(15) 昵称 paword varchar（15） 密码 nationalId int民族 age int 年龄 sex int 性别 degreeId int 学历 height int 身高 cityId int 籍贯
6、userWork int 工作 areaCountyId int 所在区县 salary int 工资 marriageId int 婚姻 houseId int 住房信息 headimage 相片 hobby varchar(20) 爱好（null） introduceYourself char（200） 介绍自己 integralint积分默认值0 择友要求表 allFriendRequire friendRequireId int 择友要求id userInfoId int 用户id friendAge_one int 年龄1 friendAge_two int 年龄2 friendHe
7、ight_one int 身高1 friendHeight_two int 身高2 friendMarriageId int 婚姻 friendDegreeId int 学历 friendAreaCountyId int 所在区县 friendhouseId int 住房信息 住房信息表 allHouse houseId int 住房id house varchar（10） 住房情况 礼物表allGift giftid int 礼物id giftpicturesId int 礼物图片 giftNumber int 礼物数量 userInfoId int 用户id 礼物图片表allGiftPic
8、tures giftNumberId int 礼物图片id giftPictures image 礼物图片 oneIntegralint 单个积分价值 民族表allNational nationalId int 民族Id（关联用户信息表） nationals varchar（5） 民族 学历表allDegree degreeId int 学历id（关联用户信息表） degree varchar（10） 学历 籍贯表allNative nativeId int 省 native varchar（10）省 cityId int 市 城市表allCity cityId int 城市Id city v
9、archar（10） 城市 天津市区县表allAreaCounty areaCountyId int 区县id areaCounty varchar（10）区县 婚姻状态表allMarriage marriageId int 婚姻状态Id marriage varchar（10）婚姻状态 相册表allHeads headsId int 相片Id heads image（null） 相片 userInfoid 用户Id 爱好表allHobby hobbyId int 爱好id hobby varchar（10） 爱好 信息表（收发信件）allInformation informationId i
10、nt 信息id InformationTitle varchar（50）信件标题 Information varchar（200） 信息内容 outId int 是否已读 fromInformationUserinfoId int 发信人id toInformationUserinfoId int 收信人Id 文章表allTitle articleId int 文章id userInfoId int 用户id title varchar（100） 标题 content text 文章内容 最近查看allLookup lookmeUserInfoidone int 我看的用户id（依次来5个）
11、mylookUserInfoidone int 看我的用户id（依次来5个） 收藏表allCollection userInfoId int 用户id collectionUserInfoId int 收藏的用户Id 推荐第4篇：数据库设计题目 保险代理人资格模拟考试系统的设计与实现 暴龙眼镜专卖店销售系统的设计与实现 机电学院职工信息系统的设计与实现 博阳高中学生管理系统的设计与实现 五家子村信息化管理系统的设计与实现 九阳股份有限公司人事管理系统的设计与实现 新世纪酒店餐饮管理系统的设计与实现 嘉华超市库存管理系统的设计与实现 丹东华美手机销售系统的设计与实现 系统建模工具课程中心的设计与
12、实现 金阳客运站售票系统的设计与实现 华夏酒店客房管理系统的设计与实现 天康集团人事管理系统的设计与实现 神州汽车租赁管理系统的设计与实现 万豪酒店餐饮管理系统的设计与实现 世纪高中运动会管理系统的设计与实现 安正办公用品管理系统的设计与实现 迷你饰品网络销售系统的设计与实现 美食每刻订餐网的设计与实现 丹东一中学生管理系统的设计与实现 鼎盛房屋租赁管理系统设计与实现 广天食品公司人事管理系统设计与实现 丹东星火公司手机销售系统设计与实现 兴隆小区物业管理系统设计与实现 海迪酒店客房管理系统设计与实现 昌旭超市进销存管理系统的设计与实现 云飞音像公司库存管理系统设计与实现 宇飞公司工资管理系统
13、设计与实现 国际酒店客房管理系统的设计与实现 东港烟草公司网络销售系统的设计与实现 辽东学院运动会管理系统的设计与实现 秀曼童装网络销售系统的设计与实现 北方图书网络销售系统的设计与实现 佳琪鞋业库存管理系统的设计与实现 贝多分婴儿用品网络销售系统的设计与实现 “携手”情侣表网络销售系统的设计与实现 雨林时尚饰品网站的设计与实现 森玛网络休闲服饰网站的设计与实现 金湾小区物业管理系统的设计与实现 网站开发技术课程网站的设计与实现 鸿利手包专卖店网站的设计与实现 尼丰汽配公司网站的设计与实现 林明臣国画专卖店网站的设计与实现 名品太阳镜网上专营店网站的设计与实现 云裳嫁衣婚纱专卖店网站的设计与实
14、现 “Ben”笔记本专营店网站的设计与实现 旭东网上烟具店网站的设计与实现 推荐第5篇：数据库设计流程 数据库设计流程 目前数据库设计一般分为6个阶段，即需求分析阶段，概念结构设计阶段，逻辑结构设计阶段，物理结构设计阶段，实施阶段，运行与维护阶段。 (1) 需求分析阶段 需求分析阶段的主要任务是指通过充分调查现实世界要处理的对象, 详细了解计算机系统的工作情况, 明确用户的各种需求, 然后确定系统的各项功能。数据库系统不仅要按照当前的应用要求来设计, 而且必须充分考虑今后可能的扩充和改变。 (2) 概念结构设计阶段 概念结构设计阶段的主要任务是将需求分析阶段所得到的用户需求抽象为概念模型, 而
15、描述概念模型的具体工具主要是E- R 模型。 (3) 逻辑结构设计阶段 逻辑结构设计阶段的主要任务是把概念结构设计阶段设计的基本E- R 模型转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。具体来说, 就是首先将概念结构转换为一般的关系、网状、层次模型, 然后将转换来的模型向特定DBMS 支持下的数据模型转换, 最后对数据模型进行优化。 (4) 物理结构设计阶段 物理结构设计阶段的主要任务是为一个指定的逻辑数据模型选取一个符合应用要求的物理结构。具体来说, 就是首先确定数据库的物理结构, 即数据库的存取方法和存储结构; 然后对数据库的物理结构进行评估, 评估的重点是存取时间的长短和存
16、储空间的大小。 (5) 实施阶段 实施阶段的主要任务是用RDBMS 提供的数据定义语言和其他实用程序将逻辑结构设计和物理结构设计的结果详细描述出来, 成为DBMS 可以接受的源代码; 再经过系统调试产生目标模式, 最后完成数据的载入工作。 (6) 运行与维护阶段 运行与维护阶段的主要任务包括数据库的转储和恢复, 数据库完整性和安全性控制, 数据库性能改造、分析和监督, 数据库的重构造和重组织。 推荐第6篇：数据库设计心得 数据库设计经验谈 数据库设计经验谈 一个成功的管理系统，是由：50% 的业务 + 50% 的软件 所组成，而 50% 的成功软件又有 25% 的数据库 + 25% 的程序 所
17、组成，数据库设计的好坏是一个关键。如果把企业的数据比做生命所必需的血液，那么数据库的设计就是应用中最重要的一部分。有关数据库设计的材料汗牛充栋，大学学位课程里也有专门的讲述。不过，就如我们反复强调的那样，再好的老师也比不过经验的教诲。所以我归纳历年来所走的弯路及体会，并在网上找了些对数据库设计颇有造诣的专业人士给大家传授一些设计数据库的技巧和经验。精选了其中的 60 个最佳技巧，并把这些技巧编写成了本文，为了方便索引其内容划分为 5 个部分： 第 1 部分设计数据库表 总共 24 个指南性技巧，涵盖表内字段设计以及应该避免的常见问题等。 第 3 部分保证数据完整性 讨论如何保持数据库的清晰和健
18、壮，如何把有害数据降低到最小程度。 第 5 部分设计数据库之前 考察现有环境 在设计一个新数据库时，你不但应该仔细研究业务需求而且还要考察现有的系统。大多数数据库项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求的现有系统（可能没有实现自动计算）。显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题。一般来说，考察现有系统对你绝对有好处。 定义标准的对象命名规范 一定要定义数据库对象的命名规范。对数据库表来说，从项目一开始就要确定表名是采用复数还是单数形式。此外还要给表的别名定义简单规则（比方说，如果表名是一个单词，别名就取单词
19、的前 4 个字母；如果表名是两个单词，就各取两个单词的前两个字母组成 4 个字母长的别名；如果表的名字由 3 个单词组成，你不妨从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成 4 字母长的别名，其余依次类推）对工作用表来说，表名可以加上前缀 WORK_ 后面附上采用该表的应用程序的名字。表内的列字段要针对键采用一整套设计规则。比如，如果键是数字类型，你可以用 _N 作为后缀；如果是字符类型则可以采用 _C 后缀。对列字段名应该采用标准的前缀和后缀。再如，假如你的表里有好多“money”字段，你不妨给每个列字段增加一个 _M 后缀。还有，日期列字段最好以 D_ 作为名字打
20、头。 检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊涂了。假如你坚持统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。 如果采用了 Microsoft Acce，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象（比如 tbl_Employees）。我在和 SQL Server 打交道的时候还用过 tbl 来索引表，但我用 sp_company （现在用 sp_feft_）标识存储过程，因为在有的时候如果我发现了更好的处理办法往往会保存好几个拷贝。我在实现 SQL
21、 Server 2000 时用 udf_ （或者类似的标记）标识我编写的函数。 工欲善其事, 必先利其器 采用理想的数据库设计工具，比如：SyBase 公司的 PowerDesign，她支持 PB、VB、Delphe 等语言，通过 ODBC 可以连接市面上流行的 30 多个数据库，包括 dBase、FoxPro、VFP、SQL Server 等，今后有机会我将着重介绍 PowerDesign 的使用。 获取数据模式资源手册 正在寻求示例模式的人可以阅读数据模式资源手册一书，该书由 Len Silverston、W.H.Inmon 和 Kent Graziano 编写，是一本值得拥有的最佳数据建
22、模图书。该书包括的章节涵盖多种数据领域，比如人员、机构和工作效能等。其他的你还可以参考：1萨师煊 王珊著 数据库系统概论(第二版)高等教育出版社 199 1、2美 Steven M.Bobrowski 著 Oracle 7 与客户服务器计算技术从入门到精通 刘建元等译 电子工业出版社，199 6、3周中元 信息系统建模方法(下) 电子与信息化 1999年第3期，1999 畅想未来，但不可忘了过去的教训 我发现询问用户如何看待未来需求变化非常有用。这样做可以达到两个目的：首先，你可以清楚地了解应用设计在哪个地方应该更具灵活性以及如何避免性能瓶颈；其次，你知道发生事先没有确定的需求变更时用户将和你
23、一样感到吃惊。 一定要记住过去的经验教训！我们开发人员还应该通过分享自己的体会和经验互相帮助。即使用户认为他们再也不需要什么支持了，我们也应该对他们进行这方面的教育，我们都曾经面临过这样的时刻“当初要是这么做了该多好.”。 在物理实践之前进行逻辑设计 在深入物理设计之前要先进行逻辑设计。随着大量的 CASE 工具不断涌现出来，你的设计也可以达到相当高的逻辑水准，你通常可以从整体上更好地了解数据库设计所需要的方方面面。 了解你的业务 在你百分百地确定系统从客户角度满足其需求之前不要在你的 ER（实体关系）模式中加入哪怕一个数据表（怎么，你还没有模式？那请你参看技巧 9）。了解你的企业业务可以在以
24、后的开发阶段节约大量的时间。一旦你明确了业务需求，你就可以自己做出许多决策了。 一旦你认为你已经明确了业务内容，你最好同客户进行一次系统的交流。采用客户的术语并且向他们解释你所想到的和你所听到的。同时还应该用可能、将会和必须等词汇表达出系统的关系基数。这样你就可以让你的客户纠正你自己的理解然后做好下一步的 ER 设计。 创建数据字典和 ER 图表 一定要花点时间创建 ER 图表和数据字典。其中至少应该包含每个字段的数据类型和在每个表内的主外键。创建 ER 图表和数据字典确实有点费时但对其他开发人员要了解整个设计却是完全必要的。越早创建越能有助于避免今后面临的可能混乱，从而可以让任何了解数据库的
25、人都明确如何从数据库中获得数据。 有一份诸如 ER 图表等最新文档其重要性如何强调都不过分，这对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对 SQL 表达式的文档化来说这是完全必要的。 创建模式 一张图表胜过千言万语：开发人员不仅要阅读和实现它，而且还要用它来帮助自己和用户对话。模式有助于提高协作效能，这样在先期的数据库设计中几乎不可能出现大的问题。模式不必弄的很复杂；甚至可以简单到手写在一张纸上就可以了。只是要保证其上的逻辑关系今后能产生效益。 从输入输出下手 在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决
26、定为了支持这些输出哪些是必要的表和字段。举个简单的例子：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。 报表技巧 要了解用户通常是如何报告数据的：批处理还是在线提交报表？时间间隔是每天、每周、每月、每个季度还是每年？如果需要的话还可以考虑创建总结表。系统生成的主键在报表中很难管理。用户在具有系统生成主键的表内用副键进行检索往往会返回许多重复数据。这样的检索性能比较低而且容易引起混乱。 理解客户需求 看起来这应该是显而易见的事，但需求就是来自客户（这里要从内部和外部客户的角度考虑）。不要依赖用户写下来的需求，真正的需求在客户
27、的脑袋里。你要让客户解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。一个不变的真理是：“只有我看见了我才知道我想要的是什么”必然会导致大量的返工，因为数据库没有达到客户从来没有写下来的需求标准。而更糟的是你对他们需求的解释只属于你自己，而且可能是完全错误的。 第 2 部分选择键和索引 数据采掘要预先计划 我所在的某一客户部门一度要处理 8 万多份联系方式，同时填写每个客户的必要数据（这绝对不是小活）。我从中还要确定出一组客户作为市场目标。当我从最开始设计表和字段的时候，我试图不在主索引里增加太多的字段以便加快数据库的运行速度。然后我意识到特定的组查询和信息采掘既
28、不准确速度也不快。结果只好在主索引中重建而且合并了数据字段。我发现有一个指示计划相当关键当我想创建系统类型查找时为什么要采用号码作为主索引字段呢？我可以用传真号码进行检索，但是它几乎就象系统类型一样对我来说并不重要。采用后者作为主字段，数据库更新后重新索引和检索就快多了。 可操作数据仓库（ODS）和数据仓库（DW）这两种环境下的数据索引是有差别的。在 DW 环境下，你要考虑销售部门是如何组织销售活动的。他们并不是数据库管理员，但是他们确定表内的键信息。这里设计人员或者数据库工作人员应该分析数据库结构从而确定出性能和正确输出之间的最佳条件。 使用系统生成的主键 这类同技巧 1，但我觉得有必要在这
29、里重复提醒大家。假如你总是在设计数据库的时候采用系统生成的键作为主键，那么你实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。 采用系统生成键作为主键还有一个优点：当你拥有一致的键结构时，找到逻辑缺陷很容易。 分解字段用于索引 为了分离命名字段和包含字段以支持用户定义的报表，请考虑分解其他字段（甚至主键）为其组成要素以便用户可以对其进行索引。索引将加快 SQL 和报表生成器脚本的执行速度。比方说，我通常在必须使用 SQL LIKE 表达式的情况下创建报表，因为 case number 字段无法分解为 year、serial number、case t
30、ype 和 defendant code 等要素。性能也会变坏。假如年度和类型字段可以分解为索引字段那么这些报表运行起来就会快多了。 键设计 4 原则 * 为关联字段创建外键。 * 所有的键都必须唯一。 * 避免使用复合键。 * 外键总是关联唯一的键字段。 别忘了索引 索引是从数据库中获取数据的最高效方式之一。95% 的数据库性能问题都可以采用索引技术得到解决。作为一条规则，我通常对逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列字段采用非成组索引。不过，索引就象是盐，太多了菜就咸了。你得考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写
31、。 大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。还有，不要索引 memo/note 字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。 不要索引常用的小型表 不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。 不要把社会保障号码（SSN）或身份证号码（ID）选作键 永远都不要使用 SSN 或 ID 作为数据库的键。除了隐私原因以外，须知政府越来越趋向于不准许把 SSN 或 ID 用作除收入相关以外的其
32、他目的，SSN 或 ID 需要手工输入。永远不要使用手工输入的键作为主键，因为一旦你输入错误，你唯一能做的就是删除整个记录然后从头开始。 我在破解他人的程序时候，我看到很多人把 SSN 或 ID 还曾被用做系列号，当然尽管这么做是非法的。而且人们也都知道这是非法的，但他们已经习惯了。后来，随着盗取身份犯罪案件的增加，我现在的同行正痛苦地从一大摊子数据中把 SSN 或 ID 删除。 不要用用户的键 在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。这样做会迫使你采取以下两个措施： * 在创建记录之后对用户编辑字段的行为施加限制。假如你
33、这么做了，你可能会发现你的应用程序在商务需求突然发生变化，而用户需要编辑那些不可编辑的字段时缺乏足够的灵活性。当用户在输入数据之后直到保存记录才发现系统出了问题他们该怎么想？删除重建？假如记录不可重建是否让用户走开？ * 提出一些检测和纠正键冲突的方法。通常，费点精力也就搞定了，但是从性能上来看这样做的代价就比较大了。还有，键的纠正可能会迫使你突破你的数据和商业/用户界面层之间的隔离。 所以还是重提一句老话：你的设计要适应用户而不是让用户来适应你的设计。 不让主键具有可更新性的原因是在关系模式下，主键实现了不同表之间的关联。比如，Customer 表有一个主键 CustomerID，而客户的定
34、单则存放在另一个表里。Order 表的主键可能是 OrderNo 或者 OrderNo、CustomerID 和日期的组合。不管你选择哪种键设置，你都需要在 Order 表中存放 CustomerID 来保证你可以给下定单的用户找到其定单记录。 假如你在 Customer 表里修改了 CustomerID，那么你必须找出 Order 表中的所有相关记录对其进行修改。否则，有些定单就会不属于任何客户数据库的完整性就算完蛋了。 如果索引完整性规则施加到表一级，那么在不编写大量代码和附加删除记录的情况下几乎不可能改变某一条记录的键和数据库内所有关联的记录。而这一过程往往错误丛生所以应该尽量避免。 可
35、选键(候选键)有时可做主键 记住，查询数据的不是机器而是人。 假如你有可选键，你可能进一步把它用做主键。那样的话，你就拥有了建立强大索引的能力。这样可以阻止使用数据库的人不得不连接数据库从而恰当的过滤数据。在严格控制域表的数据库上，这种负载是比较醒目的。如果可选键真正有用，那就是达到了主键的水准。 我的看法是，假如你有可选键，比如国家表内的 state_code，你不要在现有不能变动的唯一键上创建后续的键。你要做的无非是创建毫无价值的数据。如你因为过度使用表的后续键别名建立这种表的关联，操作负载真得需要考虑一下了。 别忘了外键 大多数数据库索引自动创建的主键字段。但别忘了索引外键字段，它们在你
36、想查询主表中的记录及其关联记录时每次都会用到。还有，不要索引 memo/notes 字段而且不要索引大型文本字段（许多字符），这样做会让你的索引占据大量的数据库空间。 第 4 部分各种小技巧 文档、文档、文档 对所有的快捷方式、命名规范、限制和函数都要编制文档。 采用给表、列字段、触发器等加注释的数据库工具。是的，这有点费事，但从长远来看，这样做对开发、支持和跟踪修改非常有用。 取决于你使用的数据库系统，可能有一些软件会给你一些供你很快上手的文档。你可能希望先开始在说，然后获得越来越多的细节。或者你可能希望周期性的预排，在输入新数据同时随着你的进展对每一部分细节化。不管你选择哪种方式，总要对你
37、的数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当你过了一年多时间后再回过头来做第 2 个版本，你犯错的机会将大大减少。 使用常用英语（或者其他任何语言）而不要使用编码 为什么我们经常采用编码（比如 9935A 可能是青岛啤酒的供应代码，4XF788-Q 可能是帐目编码）？理由很多。但是用户通常都用英语进行思考而不是编码。工作 5 年的会计或许知道 4XF788-Q 是什么东西，但新来的可就不一定了。在创建下拉菜单、列表、报表时最好按照英语名排序。假如你需要编码，那你可以在编码旁附上用户知道的英语。 保存常用信息 让一个表专门存放一般数据库信息非常有用。我常在这个表里存放数据库当
38、前版本、最近检查/修复（对 FoxPro）、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。 测试、测试、反复测试 建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证你选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。 检查设计 在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。 Microsoft V
39、isual FoxPro 设计技巧 对复杂的 Microsoft Visual FoxPro 数据库应用程序而言，可以把所有的主表放在一个数据库容器文件里，然后增加其他数据库表文件和装载同原有数据库有关的特殊文件。根据需要用这些文件连接到主文件中的主表。比如数据输入、数据索引、统计分析、向管理层或者政府部门提供报表以及各类只读查询等。这一措施简化了用户和组权限的分配，而且有利于应用程序函数（存储过程）的分组和划分，从而在程序必须修改的时候易于管理。 推荐第7篇：数据库设计技巧 导语：数据库设计是整个程序的重点之一，为了支持相关程序运行，最佳的数据库设计往往不可能一蹴而就，只能反复探寻并逐步求精
40、，这是一个复杂的过程，也是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。下面给出了20个数据库设计最佳实践，当然，所谓最佳，还是要看它是否适合你的程序。一起来了解了解吧。 1.使用明确、统一的标明和列名，例如 School, SchoolCourse, CourceID。 2.数据表名使用单数而不是复数，例如 StudentCourse，而不是StudentCourses。 3.数据表名不要使用空格。 4.数据表名不要使用不必要的前缀或者后缀，例如使用School，而不是TblSchool，或者 SchoolTable等等。 5.数据库中的密码要加密，到应用中再解密。（其实就是
41、散列存储、单向加密） 6.使用整数作为ID字段，也许现在没有这个必要，但是将来需要，例如关联表，索引等等。 7.使用整数字段做索引，否则会带来很大的性能问题 。 8.使用 bit 作为布尔字段，使用整数或者varcha是浪费。同时，这类字段应该以“Is”开头。 9.要经过认证才能访问数据库，不要给每一个用户管理员权限。 10.尽量避免使用“select *”，而使用“select required_column_list”以获得更好的性能。 11.假如程序代码比较复杂，使用ORM框架，例如hibernate，iBatis。ORM框架的性能问题可 以通过详细的配置去解决。 12.分割不常使用的数
42、据表到不同的物理存储以获得更好的性能。 13.对于关键数据库，使用安全备份系统，例如集群，同步等等。 14.使用外键，非空等限制来保证数据的完整性，不要把所有的东西都扔给程序。 15.缺乏数据库文档是致命的。你应该为你的数据库设计写文档，包括触发器、存储过程和其他 脚本。 16.对于经常使用的查询和大型数据表，要使用索引。数据分析工具可以帮助你决定如何建立 索引。 17.数据库服务器和网页服务器应该放在不同的机器上。这回提高安全性，并减轻CPU压力。 18.Image和blob字段不应该定义在常用的数据表中，否则会影响性能。 19.范式（Normalization）要按照要求使用以提高性能。N
43、ormalization做的不够会导致数据冗余， 而过度Normalization 会导致太多的join和数据表，这两种情况都会影响性能。 20.多花点时间在数据库设计上，否则你将来会付出加倍的时间来偿还。（虫虫译） 推荐第8篇：数据库设计原则 4.3.1数据库设计原则 数据库设计的基本原则是在系统总体信息方案的指导下，各个库应当为它所支持的管理目标服务，在设计数据库系统时，应当重点考虑以下几个因素: 1、数据库必须层次分明，布局合理。 2、数据库必须高度结构化，保证数据的结构化，规范化和标准化，这是建立数据库和进行信息交换的基础。数据结构的设计应该遵循国家标准和行业标准，尤其要重视编码的应用。 3、在设计数据库的时候，一方而要尽可能地减小冗余度，减小存储空间的占用，降低数据一致性问题发生的可能性，另一方面，还要考虑适当的冗余，以提高运行速度和降低开发难度。 4、必须维护数据的正确性和一致性。在系统中，多个用户共享数据库，由于并发操作，可能影响数据的一致性。因此必须用“锁”等办法保证数据的一致性。 5、设定相应的安全机制，由于数据库的信息、对特定的用户有特定的保密要求，安全机制必不可少。 推荐第9篇：数据库设计（材料） 目 录 1 设计时间 .1 2 设计目的 .