如何设计一个客户信息数据库

如何设计一个客户信息数据库,第1张

一、引言数据对于企业信息化的重要性是不言而喻的。数据库存储着现代企业最重要的数据,包括生产、经营、管理等各类数据,这些数据作为企业的核心信息,通过各类信息系统,为用户提供及时准确的信息,帮助用户分析,为用户提供决策依据。为提高企业的工作效率,提升企业形象,具有传统模式无法比拟的优势。其中构建合理高效的数据库,是数据库建设关键之一。如何构建合理高效的数据库是企业信息化过程要解决的问题。下面就数据库的构建谈谈自己的一些经验,希望能对大家有所帮助。

二、设计数据库之前

数据库并不是凭空想象出来的,而是根据业务部门的需要设计符合业务需求的数据库。因此在形成数据库之前需要充分了解业务需求。1充分理解业务需求。需求分析是整个设计过程的基础,是最困难、最耗费时间的一步。在这期间通过与业务部门交流,了解用户的想法以及工作流程,通过双方多次交流,会形成初步的数据模型,当然这时的数据模型不会是最终的模型,还需要和用户进行交流,并且在以后的信息系统开发过程中还会反复修改。2重视输入输出。在定义数据库表和字段需求(输入)时,首先应了解数据产生源和数据流程,也就是必需要知道每个数据在那儿产生,数据在那儿表现,以什么样的形式表现等等,然后根据用户提供的报表或者设计出的报表、查询和视图(输出)以决定为了支持这些输出哪些是必要的表和字段。3创建数据字典和ER图表。ER图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用,而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL表达式的文档化来说这是完全必要的。需要注意的是,在需求分析调研过程中,并不是一帆风顺的,因为业务人员对于业务的理解不同,以及对于信息知识的缺乏,会影响需求分析的质量,为了提高质量,各方要用更多的时间交流与相互理解,业务部门需要精通业务的人员自始至终全力配合,而开发人员则尽量使用用户理解的业务术语交流,这样会避免出现理解不同而产生的歧义。三、设计合理的表结构

通常合理的表结构会减少数据冗余,提高数据库的性能。设计合理的表结构要遵循以下两点。1标准化和规范化数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式,但3NF(第三范式)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说,遵守3NF标准的数据库的表设计原则是:某个表只包括其本身基本的属性,当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点:有一组表专门存放通过键连接起来的关联数据。例如:某个存放单井信息及其有关油井生产日报信息的3NF数据库就有两个表:单井基础信息和油井日报信息。日报信息不包含单井的任何信息,但表内会存放一个键值,该键指向单井基础信息里包含该油井信息的那一行。不过也有例外,有时为了效率的缘故,对表不进行标准化也是必要的。2考虑各种变化在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。使数据库更具扩展性,从而减少将来数据变更所带来的损失。例如,日期类型字段,有时我们会考虑使用字符类型代替日期类型,因为在处理日期字段上容易产生数据错误,所以我们就使用字符类型。这样的例子还很多,在做前期设计时都要考虑的。表结构的设计不是一次就能成功的,在信息系统开发过程中会存在数据读取、录入或统计困难,为了解决这些问题会修改表结构,或增加一些字段,或修改一些字段的属性。这个过程不断重复,因此不要想一次能成功。建议使用专门设计工具来做这些工作,笔者经常使用:SYBASE,当然还有其它的工具:ORACLEDesigner2000,ROSE等工具。这样会使你的工作事半功倍。四、选择合理的索引

索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。1逻辑主键使用唯一的成组索引,对系统键(作为存储过程)采用唯一的非成组索引,对任何外键列采用非成组索引。考虑数据库的空间有多大,表如何进行访问,还有这些访问是否主要用作读写。2大多数数据库都索引自动创建的主键字段,但是可别忘了索引外键,它们也是经常使用的键,比如运行查询显示主表和所有关联表的某条记录就用得上。3不要索引大型字段(有很多字符),这样作会让索引占用太多的存储空间。如MEMO(备注)、TEXT(文本)等字段。4不要索引常用的小型表不要为小型数据表设置任何键,假如它们经常有插入和删除 *** 作就更别这样作了。对这些插入和删除 *** 作的索引维护可能比扫描表空间消耗更多的时间。如代码表,或系统参数表。五、保证数据完整性

数据的完整性非常重要,这关系到数据的准确性,不准确的数据是毫无价值的,因此保证数据的完整性非常重要。1完整性实现机制:实体完整性:主键参照完整性:父表中删除数据:级联删除;受限删除;置空值父表中插入数据:受限插入;递归插入父表中更新数据:级联更新;受限更新;置空值DBMS对参照完整性可以有两种方法实现:外键实现机制(约束规则)和触发器实现机制用户定义完整性:NOTNULL;CHECK;触发器以上完整性机制需要熟悉和掌握,它对于数据的完整性非常重要。2用约束而非业务规则强制数据完整性采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于业务层保证数据完整性;它不能保证表之间(外键)的完整性所以不能强加于其他完整性规则之上。3强制指示完整性在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。4使用查找控制数据完整性控制数据完整性的最佳方式就是限制用户的录入。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找:性别代码、单位代码等。5采用视图视图是一个虚拟表,其内容由SQL语句定义,视图不仅可以简化用户对数据的理解,也可以简化他们的 *** 作。那些被经常使用的查询可以被定义为视图,从而使得用户不必为以后的 *** 作每次指定全部的条件。另外通过视图用户只能查询和修改他们所能见到的数据。数据库中的其它数据则既看不见也取不到。数据库授权命令可以使每个用户对数据库的检索限制到特定的数据库对象上,增强数据的安全性。六、结束语

数据库的高效运行不仅需要技术上的支持,也需要硬件平台和网络的支持以及数据库管理员的有效管理,本文只是从技术的角度说明如何提高数据库的效率,但在实际应用过程中其它方面的支持也是不可缺少的,尤其是数据库管理,数据库建设是“三分技术,七分管理,十二分基础数据”,因此对于数据库管理一定要重视,在管理到位的情况下技术才能发挥应有的作用。

在JAVA开发中数据库的学习也是我们需要了解的,截下来几篇文章都是关于数据库的设计和应用,那么java课程培训机构废话不多说开始学习吧!

数据库的设计

数据库设计是基础,数据库优化是建立在设计基础之上的。好的数据库一定拥有好的设计。

数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效的运行环境。

数据库的三大范式

第一范式1NF:所有的域都应该是原子性的,即数据库表的每一列都是不可分割的原子数据项,而不能是集合,数组,记录等非原子数据项。

第二范式2Nf:第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。

第三范式3Nf:所有字段必须与主键直接相关,而不是间接相关。也可以理解为字段不要和其他非主键字段相关

注意:这三个范式尽可能去遵守,不是一定要墨守成规这只是让我们设计的表的时候,越靠近这些范式,可以使字段尽量的减小冗余但是有时候也可以根据实际需要小小的违背一下但是第三范式违反一下还可以接受,但是第一范式别违反

数据库设计的步骤

需求分析阶段

准确了解与分析用户需求(包括数据与处理)。是整个设计过程的基础,是最困难、最耗费时间的一步。

概念结构设计阶段

是整个数据库设计的关键--设计数据库的E-R模型图,确认需求信息的正确和完整

Entity_Relationship---实体之间的关系

一对一

一对多

多对一

数据库实时推送数据方法:

1、新建一个名字为ApplyJiQiMa的数据库。

2、往数据库中先增加四条数据,其ApplyDate当前的时间戳,后面用于监听时的排序,方便可以让数据库实时推送。

别的表暂时和公告没关系 就是userid关联creatorid吧

Message表

MesageID

MessageTitle

MessageQuoteLinkPath(引用链接)

AttachmentPath 附件路径(应该指定上传附件的ftp服务器地址)

CreatorID

CreatorDate

status

Connection conn;

try {

ClassforName("oraclejdbcdriverOracleDriver");

conn = DriverManagergetConnection("jdbc:oracle:thin:@127001:1521:taian", "hr", "hr"); //连接Oracle

connsetAutoCommit(false);

Statement myStat = conncreateStatement();

String sqlTxt = "update BankAccount set account=account-" + thisamountgetText() + " where accId=" + thispayOutgetText();

Systemoutprintln("第一步 执行:" + sqlTxt);

// 从汇出方扣减

try {

int affectedRow = myStatexecuteUpdate(sqlTxt);

Systemoutprintln("从汇出方扣减" + thisamountgetText() + "元,修改了" + affectedRow + "行数据");

sqlTxt = "update BankAccount set account=account+" + thisamountgetText() + " where accId=" + thissaveIngetText();

Systemoutprintln("第二步 执行:" + sqlTxt);

affectedRow = myStatexecuteUpdate(sqlTxt);

Systemoutprintln("从汇入方增加" + thisamountgetText() + "元,修改了" + affectedRow + "行数据");

// 事务成功结束, 提交

conncommit();

} catch (SQLException sqlEx) {

Systemoutprintln("耶!语句写错了吧");

sqlExprintStackTrace();

// 事务中断,整体回滚到事务开始前状态

connrollback();

}

// 汇入方增加帐户余额

myStatclose();

connclose();

} catch (Exception ex) {

Systemoutprintln("反正是出错了");

}

}//

1、命令窗口输入:creaxs

2、表设计器中,依次输入:

第一行:字段名:姓名类型:字符型宽度:6

第二行:字段名:年龄类型:数值型宽度:2

第三行:字段名:入学日期类型:日期型宽度:8

第四行:字段名:婚否类型:逻辑型宽度:1

第五行:字段名:简历类型:备注型宽度:4

3、点确定按钮

数据表的设计原则:

( )不应针对整个系统进行数据库设计 而应该根据系统架构中的组件划分 针对每个组件所处理的业务进行组件单元的数据库设计;不同组件间所对应的数据库表之间的关联应尽可能减少 如果不同组件间的表需要外键关联也尽量不要创建外键关联 而只是记录关联表的一个主键 确保组件对应的表之间的独立性 为系统或表结构的重构提供可能性

( )采用领域模型驱动的方式和自顶向下的思路进行数据库设计 首先分析系统业务 根据职责定义对象 对象要符合封装的特性 确保与职责相关的数据项被定义在一个对象之内 这些数据项能够完整描述该职责 不会出现职责描述缺失 并且一个对象有且只有一项职责 如果一个对象要负责两个或两个以上的职责 应进行分拆

( )根据建立的领域模型进行数据库表的映射 此时应参考数据库设计第二范式 一个表中的所有非关键字属性都依赖于整个关键字 关键字可以是一个属性 也可以是多个属性的集合 不论那种方式 都应确保关键字能够保证唯一性 在确定关键字时 应保证关键字不会参与业务且不会出现更新异常 这时 最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字

( )由于第一点所述的领域模型驱动的方式设计数据库表结构 领域模型中的每一个对象只有一项职责 所以对象中的数据项不存在传递依赖 所以 这种思路的数据库表结构设计从一开始即满足第三范式 一个表应满足第二范式 且属性间不存在传递依赖

( )同样 由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系 所以在领域模型中的对象存在主对象和从对象之分 从对象是从 N或N N的角度进一步主对象的业务逻辑 所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常

( )在映射后得出的数据库表结构中 应再根据第四范式进行进一步修改 确保不存在多值依赖 这时 应根据反向工程的思路反馈给领域模型 如果表结构中存在多值依赖 则证明领域模型中的对象具有至少两个以上的职责 应根据第一条进行设计修正 第四范式 一个表如果满足BCNF 不应存在多值依赖

( )在经过分析后确认所有的表都满足二 三 四范式的情况下 表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构 并且 我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的 只是一个存储介质 所以 表和表之间也不应用强关联来表述业务(数据间的一致性) 这一职责应由系统的逻辑层来保证 这种方式也确保了系统对于不正确数据(脏数据)的兼容性 当然 从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据 单从另一个角度来说 脏数据的产生在一定程度上也是不可避免的 我们也要保证系统对这种情况的容错性 这是一个折中的方案

( )应针对所有表的主键和外键建立索引 有针对性的(针对一些大数据量和常用检索方式)建立组合属性的索引 提高检索效率 虽然建立索引会消耗部分系统资源 但比较起在检索时搜索整张表中的数据尤其时表中的数据量较大时所带来的性能影响 以及无索引时的排序 *** 作所带来的性能影响 这种方式仍然是值得提倡的

( )尽量少采用存储过程 目前已经有很多技术可以替代存储过程的功能如 对象/关系映射 等 将数据一致性的保证放在数据库中 无论对于版本控制 开发和部署 以及数据库的迁移都会带来很大的影响 但不可否认 存储过程具有性能上的优势 所以 当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性时 可经过平衡考虑选用存储过程

( )当处理表间的关联约束所付出的代价(常常是使用性上的代价)超过了保证不会出现修改 删除 更改异常所付出的代价 并且数据冗余也不是主要的问题时 表设计可以不符合四个范式 四个范式确保了不会出现异常 但也可能由此导致过于纯洁的设计 使得表结构难于使用 所以在设计时需要进行综合判断 但首先确保符合四个范式 然后再进行精化修正是刚刚进入数据库设计领域时可以采用的最好办法

( )设计出的表要具有较好的使用性 主要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧

lishixinzhi/Article/program/SQL/201311/16156

以上就是关于如何设计一个客户信息数据库全部的内容,包括:如何设计一个客户信息数据库、java课程培训机构分享Mysql数据库的设计和优化、数据库如何实时推送数据等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9771689.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-01
下一篇 2023-05-01

发表评论

登录后才能评论

评论列表(0条)

保存