数据库设计技巧

数据库设计技巧,第1张

就我个人的经验来说,数据库虽然在设计上确实需要有一定的经验,但是它并不是最难的。

对于数据的设计其实是对于现实中业务的一种抽象。

就我的习惯的话,我会先对于现实中的业务场景、业务的角色进行分析。

就拿一般的进销存系统来举例吧。

我有一个对于物料管理的仓库,我需要对我的物料的进销存进行管理。

那么我们就需要分析,没有系统的时候,人与人之间的业务是怎么流转的,他们都是通过哪些表单来进行流转的,上下级之间的消息传递和反馈都是怎么进行的。

当知道了业务以后,我们的数据库无非就是对于现实中的业务的一种具现。

对于业务的设计完成以后,就是针对角色的了。

例如:业务的传递都是在业务人员之间的,我们已经整理表单的传递,那角色其实就已经在这些传递中存在了。

但是,业务的角色是业务的角色,我们还要包括财务的角色,那对于财务来说,他需要在哪些环节看到这些业务的单据?并且需要怎么处理?财务的处理结果又包括哪些?不同的处理结果对于下一步的 *** 作又有什么影响。

当我们把这一切的逻辑整理完成后,我们对于数据库的功能上就已经满足了。

接下来的就是抽象数据的分类了。

例如:我们需要对不同的表进行一个分类,我个人喜欢把表分成三种,一种是基础数据表,一种是过程表,一种是结果表。

怎么解释呢?

基础数据表:顾名思义,就是对于基础数据的维护,哪些可以成为基础数据呢?就是我们的业务发生的各个过程中,这些数据都是可以参与其中的,这就是基础数据。

例如:货物的信息,客户的信息。

过程表:就是仅仅在一个过程中使用的表,当这个过程结束了,这个表就没用了。

例如:订单表,付款单表。他们表示的仅仅是订单从下单到最后关闭的这个过程,关闭以后,这个订单表其实我们就不会再去使用它了。

结果表:这个表的数据有一个特点,只允许添加,不允许删除和修改,这个表的数据本身就是对于一种最终结果的表现。

例如:日志表、账单表。

那我们在进行数据库设计的时候,就需要将这些使用情况考虑进去,将不同功能的表进行分离,尽量降低耦合,让相互表的修改不会影响使用。

例如:收款单,我们需要收一笔款的时候,就会生成这个收款单,当款收到后,这个收款单的功能就结束了。

但现实的情况中,可能财务收到了这笔钱,结束了收款单流程后,他发现填错了,本来应该收100,结果收款单写的110。

但是,收款单表示的是过程,当这个过程结束了,我们就不会再需要上一个收款单了,所以,按照我们业务的处理流程,我们应该先生成一笔冲抵的收款单,例如收到-110,然后再生成新的100的收款单。

我们每个月还会有财务统计报表,财务报表因为和现实中的财务账有关,是绝对不允许变动的,因此,这个财务报表就是一个结果表,我们会按月通过批处理程序,将收款单的明细和统计数据放到另一张表中,感觉好像比较冗余,但是这个确实非常必要的。

因为我曾经就遇到过一个情况,我们直接用过程表来进行数据的统计,然后11月30日有一笔收款已经完成了,结果发现收错了,就重新做了个收款单,结果本来已经出了11月结果的账单发生了变化,导致财务实际的处理出现了问题。

因此,数据的冗余有时候是有必要的,我们需要根据不同表的类型进行一些冗余的设计。

对于数据库设计的考虑点还有很多,可能一时半会儿也说不完,大家如果有什么好的思路,也可以在下方评论或关注我给我留言。

旅游网站的设计方案

根据网站定位和赢利模式的不同,大中型旅游网站一般具有旅游信息咨询交流版块、旅游B2C商务预订版块、旅游B2B电子商务交易版块,或者以其中某个版块为主。而建设一个内容丰富、功能强大的专业旅游网站的立足点有三:

一、旅游数据库的设计

二、旅游信息量的丰富

三、正确的商务流程设计

在旅游数据库的设计方面,经过几年的积累,我们已经发展建立起旅游网站和电子商务领域最齐全的旅游信息和电子商务数据库之一,涉及的各方面旅游数据库表格多达200以上,在旅游信息库的内容方面也有相当的积累,最后,我们设计的酒店预订、旅游线路预订、旅游信息咨询以及旅游B2B电子商务交易的流程设计也经过了实际使用实践,得到了业界的认可。

在版块划分方面,我们将其按旅游信息种类和涉及对象的不同分为旅游信息咨询交流版块、旅游B2C商务预订版块、旅游B2B电子商务交易版块这几大部分。同时又充分考虑到网站本身、B类客户、C类客户之间的相互关系,做到相互之间形成一个丰富的信息交换机制,使得B2C、B2B、C2C、C2C2B、B2C2B等多种信息交换和电子商务模式均能融合到整个旅游网站中。

在商务流程设计方面,我们遵循以客户为导向的CRM理论(客户关系管理),紧密围绕将旅游网站建设成为客户服务和信息咨询平台、销售平台、营销平台这三个出发点。传统的旅游网站大多是旅游信息咨询平台,即供人浏览查阅旅游信息,而现在强调是客户服务和信息咨询平台意指除了旅游信息本身,浏览者-客户与旅游网站之间互动的流程、渠道同样也是重要的建设内容。客户服务和信息咨询平台除了传统的旅游信息查阅外,还有旅游信息高度关联和便于搜索、智能化的旅游知识库、综合性的智能旅游搜索引擎、智能旅游代理Agent服务、内容和信息浏览个性化、浏览方式拟人-人性化、与其他客户接触渠道的整合这些高级特性。作为销售平台具有整个预订流程通畅、预订手段多样化、累积消费制的特性;作为营销平台具有线上收集客户资料以及线上调查、一对一的广告和产品、促销实时的一对一网上营销的功用。

在旅游信息建设方面,按照旅游信息的四级结构来编辑/整理和表现旅游息。即每个旅游要素的介绍都要分为四个层面:

概要级:对当地住宿情况的总的介绍和评价。

精选级:按高、中、低、经济型四个档次分别推荐几个宾馆、旅社。并介绍各自特色。

详细级:有关该地住宿的全部数据库信息,用户可自行按条件检索查询。

补充级:从网友相关的贴子中选出的网友对该地住宿的介绍、体验和评价。

在信息浏览上建立三级结构,当用户在旅游网上浏览某个旅游目的地的信息时,提供三个层面的浏览方式

用户自行浏览某个旅游目的地的各方面信息,自由点击相关页面浏览。

定制化浏览,用户可自行指定各旅游要素的浏览顺序,生成定制浏览序列

推荐浏览。几个精心设计的定制化浏览程序。

旅游电子商务以商务为本,所有的工作都是围绕旅游网站的核心业务开展营销/销售/客服,而电子只是商务实现的手段和渠道。进一步的,Web只是众多手段和渠道中的一种,虽然是主要的一种。因此,我们的旅游网站设计方案中综合了各种客户接触渠道,有网站(包括相关后台系统)、客服电话、Email、Fax、社区、直复信件,根据信息容量、信息丰富程度、到达/回复速度、用户心理、用户使用习惯以及成本这些方面的综合评价,每种客户接触手段都有自己独特的优势。我们的信息咨询、预订、营销流程设计就根据这些因素综合运用了这些渠道。

三、综合旅游数据库的设计建设

1、旅游信息咨询版块数据库设计

(1)、旅游信息管理系统

风景名胜数据库

景区-城市景点门票库

景区-城市里程距离数据库

风光数据库

旅行社库

旅游线路数据库

推荐行程库

自助旅行推荐行程表

宾馆酒店管理系统

宾馆酒店基本信息表

宾馆酒店服务设施表

宾馆酒店娱乐设施表

宾馆酒店xyk表

宾馆酒店客房价格表

宾馆酒店最优价格表

订房中心基本信息表

普通旅馆一览表

全国铁路时刻表

各地铁路里程表

铁路里程票价表

全国铁路车站表

特殊车次表

铁路车次运行时刻表

飞机航班

国内航班表

国际航班表

航空公司简介表

飞机场简介表

游船

游船公司基本信息表

游船基本信息表

游船舱位价格表

游船航期表

票务代理机构

长途公路客运

市内交通

景区-城市娱乐库

购物场所库

景区-城市购物库

旅游管理职能机构库管理

旅游质量监督机构库

旅游急救中心库

旅游新闻数据库

旅游百科数据库系列

各地旅游注意事项数据库

城市天气预报数据库系列

世界城市天气预告

城市最佳旅游时间表

城市近期天气趋势表

旅游搜索引擎数据库系列

旅游网址类别字典库

旅游网址库

大使馆领事馆数据库

各地旅游节庆数据库

(2)旅游相关公共字典库

世界国家名称字典库

全国大区域字典库

全国省级行政区域字典库

全国城市字典库

风景名胜类别字典库

宾馆服务项目字典库

(3)旅游论坛

(4)、会员管理系统

会员个人基本资料数据库

会员个人旅行资料数据库系列

会员消费资料数据库系列

会员行为跟踪数据库系列

(5)、旅游网站资源管理系统

旅游网站栏目字典库

旅游网站资源索引库系列

2、酒店预订管理系统

代理商数据库

预订单队列库

预订单发送状态日志库

财务对帐催款单数据库

二次催款记录数据库

订单流水号数据库

酒店预订网上原始订单数据库

签约酒店信息库

签约酒店房价信息库

*** 作员资料库

真实预订单基本消费资料表

真实预订单详细消费资料表

真实预订单消费流程状态表

黑名单库

工作站库

3、旅游B2B电子商务平台管理系统

(1)字典库

国家代码表

地域代码表

地区代码表

城市代码表

景点类型表

景点信息表

货币类型表

旅游企业类型表

主题旅游类型表

旅游产品类型表

供求合作方式表

旅游业务供求合作关系表

旅游业务供求合作关系细表

xyk类型表

酒店服务设施项目表

餐饮字典表

餐饮类型表

娱乐服务项目表

酒店客房类型表

(2)B2B交易平台管理系统

交易会会员基本信息表

交易会会员合作伙伴/客户名录

交易会会员长久需要的信息类型表

会员发布信息表

交易会会员短期需要的供求信息类型表

旅游产品总表

旅游路线信息表

旅游路线详细行程表

接团队大小定义表

地接价总表

地接-房价表

地接-景点门票表

酒店详细信息表

酒店xyk表

酒店娱乐设施表

酒店餐饮信息表

酒店服务设施表

酒店对公众报价简表

酒店对公众报价详细表

酒店业内报价简表

酒店业内报价详细表

会员登录交易会日志表

旅游产品浏览日志表

会员统计表

游客出游意向

出游意向回复表

会员企业/产品推荐表

旅游线路订单记录数据库

合作伙伴库

传真队列库

传真状态日志库

短消息队列库

短消息状态日志库

会员发布信息群发要求队列表

会员需求信息动态

发送日志表

系统后台管理 *** 作员表

会员企业人员名片库

会员企业帐务表

会员信用档案

会员企业个人帐号库

拼团线路

拼团请求表

拼团请求细表

拼团需求表

拼团需求回复表

名片分发及交换记录表

收藏夹目录结构

收藏夹

景点门票报价

会员登录状况统计视图

产品发布状况统计视图

会员展台状况统计视图

旅游线路产品发布/修改,触发供求信息表更新存储过程

地接报价产品发布/修改,触发供求信息表更新存储过程

酒店房价产品发布/修改,触发供求信息表更新存储过程

供求信息发布/修改,触发供求信息表更新存储过程

旅游线路产品发布,触发相关关联标记存储过程

长期供求信息表更新存储过程

短期供求信息表更新存储过程

旅游线路产品发布,触发相关关联标记存储过程

四、旅游网站系统功能管理系统

1、旅游信息咨询

1.1、旅游新闻发布管理系统

1.2、综合旅游景点查询系统

1.3、旅游线路查询系统

1.4、旅游企业黄页查系统(附后台录入查询管理程序)

旅行社黄页

宾馆酒店黄页

景区景点黄页

全国餐饮机构黄页

全国娱乐机构黄页

旅游购物场所黄页

旅游事业监督管理机构黄页

旅游汽车服务公司黄页

航空票务代理点黄页

铁路票务代理点黄页

1.5、旅游搜索引擎系统(附后台录入查询管理程序)

1.6、旅游信息综合查询(将前面这些旅游信息有机结合起来的系统)

1.7、旅游论坛系统

18、旅游网站会员管理系统

1.9、投票统计系统

2、旅游预订版块

2.1酒店预订系统

2.2机票预订系统

2.3旅游线路预订系统

3、旅游B2B电子商务交易模块

3.1系统前台:

会员企业管理、个人帐号管理、产品发布/管理、供求商机管理、游客预订中心游客询价系统,Maillist服务系统、Fax服务系统、供求智能匹配、网络电子名片、散客拼团与组团询价、收藏夹等12个模块。

32系统后台管理

会员管理、产品管理、同业合作管理、订单管理、财务管理,群发管理、名片管理、拼团管理、权限管理、广告管理、统计分析等模块

就我个人的经验来说,数据库虽然在设计上确实需要有一定的经验,但是它并不是最难的。

对于数据的设计其实是对于现实中业务的一种抽象。

就我的习惯的话,我会先对于现实中的业务场景、业务的角色进行分析。

就拿一般的进销存系统来举例吧。

我有一个对于物料管理的仓库,我需要对我的物料的进销存进行管理。

那么我们就需要分析,没有系统的时候,人与人之间的业务是怎么流转的,他们都是通过哪些表单来进行流转的,上下级之间的消息传递和反馈都是怎么进行的。

当知道了业务以后,我们的数据库无非就是对于现实中的业务的一种具现。

对于业务的设计完成以后,就是针对角色的了。

例如:业务的传递都是在业务人员之间的,我们已经整理表单的传递,那角色其实就已经在这些传递中存在了。

但是,业务的角色是业务的角色,我们还要包括财务的角色,那对于财务来说,他需要在哪些环节看到这些业务的单据?并且需要怎么处理?财务的处理结果又包括哪些?不同的处理结果对于下一步的 *** 作又有什么影响。

当我们把这一切的逻辑整理完成后,我们对于数据库的功能上就已经满足了。

接下来的就是抽象数据的分类了。

例如:我们需要对不同的表进行一个分类,我个人喜欢把表分成三种,一种是基础数据表,一种是过程表,一种是结果表。

怎么解释呢?

基础数据表:顾名思义,就是对于基础数据的维护,哪些可以成为基础数据呢?就是我们的业务发生的各个过程中,这些数据都是可以参与其中的,这就是基础数据。

例如:货物的信息,客户的信息。

过程表:就是仅仅在一个过程中使用的表,当这个过程结束了,这个表就没用了。

例如:订单表,付款单表。他们表示的仅仅是订单从下单到最后关闭的这个过程,关闭以后,这个订单表其实我们就不会再去使用它了。

结果表:这个表的数据有一个特点,只允许添加,不允许删除和修改,这个表的数据本身就是对于一种最终结果的表现。

例如:日志表、账单表。

那我们在进行数据库设计的时候,就需要将这些使用情况考虑进去,将不同功能的表进行分离,尽量降低耦合,让相互表的修改不会影响使用。

例如:收款单,我们需要收一笔款的时候,就会生成这个收款单,当款收到后,这个收款单的功能就结束了。

但现实的情况中,可能财务收到了这笔钱,结束了收款单流程后,他发现填错了,本来应该收100,结果收款单写的110。

但是,收款单表示的是过程,当这个过程结束了,我们就不会再需要上一个收款单了,所以,按照我们业务的处理流程,我们应该先生成一笔冲抵的收款单,例如收到-110,然后再生成新的100的收款单。

我们每个月还会有财务统计报表,财务报表因为和现实中的财务账有关,是绝对不允许变动的,因此,这个财务报表就是一个结果表,我们会按月通过批处理程序,将收款单的明细和统计数据放到另一张表中,感觉好像比较冗余,但是这个确实非常必要的。

因为我曾经就遇到过一个情况,我们直接用过程表来进行数据的统计,然后11月30日有一笔收款已经完成了,结果发现收错了,就重新做了个收款单,结果本来已经出了11月结果的账单发生了变化,导致财务实际的处理出现了问题。

因此,数据的冗余有时候是有必要的,我们需要根据不同表的类型进行一些冗余的设计。

对于数据库设计的考虑点还有很多,可能一时半会儿也说不完,大家如果有什么好的思路,也可以在下方评论或关注我给我留言。

以上就是关于数据库设计技巧全部的内容,包括:数据库设计技巧、浅谈旅游网站的建设和实现、对于小白来说web开发最难的部分是数据库的设计吗,数据库的设计有什么技巧等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

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

原文地址: https://outofmemory.cn/sjk/9547766.html

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

发表评论

登录后才能评论

评论列表(0条)

保存