电子商务系统分析与设计怎么进行数据库设计

用手设计、用脑设计，因为你问题很模糊，所以我的回答也很模糊，如果想真正的解决问题，你问题别这么模糊。

一个网站先确立方向和目标，再去考虑结构，然后再去开发每个结构的功能，电商网站，大概有

客户商家，管理员

客户又有订单，余额，地址，消费信息等等

商家有订单，商品，发货数据等等

管理员，主要功能是能审核客户商家的信息和修改

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

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

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

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

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

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

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

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

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

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

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

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

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

怎么解释呢？

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

例如：货物的信息，客户的信息。

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

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

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

例如：日志表、账单表。

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

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

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

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

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

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

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

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

通常情况下，可以从两个方面来判断数据库设计的是否规范:

1)一是看看是否拥有大量的窄表

窄表往往对于OLTP比较合适，符合范式设计原则

2)宽表的数量是否足够的少。

所谓的宽表就是字段比较多的表，包含的维度层次比较多，造成冗余也比较多，毁范式设计，但是利于取数统计

若符合这两个条件，我们可以说数据库设计的比较好

当然这是两个泛泛而谈的指标。为了达到数据库设计规范化的要求，一般来说，需要符合以下五个要求。

要求一：表中应该避免可为空的列。

虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。数据库在处理的时候，需要进行特殊的处理。如此的话，就会增加数据库处理记录的复杂性。当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。

所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。若确实需要的话，我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。

要求二：表不应该有重复的值或者列。

如现在有一个进销存管理系统，这个系统中有一张产品基本信息表中。这个产品开发有时候可以是一个人完成，而有时候又需要多个人合作才能够完成。所以，在产品基本信息表产品开发者这个字段中，有时候可能需要填入多个开发者的名字。

如进销存管理中，还需要对客户的联系人进行管理。有时候，企业可能只知道客户一个采购员的姓名。但是在必要的情况下，企业需要对客户的采购代表、仓库人员、财务人员共同进行管理。因为在订单上，可能需要填入采购代表的名字;可是在出货单上，则需要填入仓库管理人员的名字等等。

为了解决这个问题，有多种实现方式。但是，若设计不合理的话在，则会导致重复的值或者列。如我们也可以这么设计，把客户信息、联系人都放入同一张表中。为了解决多个联系人的问题，可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。若还有第三联系人、第四联系人等等，则往往还需要加入更多的字段。

所以，我们在数据库设计的时候要尽量避免这种重复的值或者列的产生。笔者建议，若数据库管理员遇到这种情况，可以改变一下策略。如把客户联系人另外设置一张表。然后通过客户ID把供应商信息表跟客户联系人信息表连接起来。也就是说，尽量将重复的值放置到一张独立的表中进行管理。然后通过视图或者其他手段把这些独立的表联系起来。

要求三：表中记录应该有一个唯一的标识符。

在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个ID号来唯一的标识行记录，而不要通过名字、编号等字段来对纪录进行区分。每个表都应该有一个ID列，任何两个记录都不可以共享同一个ID值。另外，这个ID值最好有数据库来进行自动管理，而不要把这个任务给前台应用程序。否则的话，很容易产生ID值不统一的情况。

另外，在数据库设计的时候，最好还能够加入行号。如在销售订单管理中，ID号是用户不能够维护的。但是，行号用户就可以维护。如在销售订单的行中，用户可以通过调整行号的大小来对订单行进行排序。通常情况下，ID列是以1为单位递进的。但是，行号就要以10为单位累进。如此，正常情况下，行号就以10、20、30依次扩展下去。若此时用户需要把行号为30的纪录调到第一行显示。此时，用户在不能够更改ID列的情况下，可以更改行号来实现。如可以把行号改为1，在排序时就可以按行号来进行排序。如此的话，原来行号为30的纪录现在行号变为了1，就可以在第一行中显示。这是在实际应用程序设计中对ID列的一个有效补充。这个内容在教科书上是没有的。需要在实际应用程序设计中，才会掌握到这个技巧。

要求四：数据库对象要有统一的前缀名。

一个比较复杂的应用系统，其对应的数据库表往往以千计。若让数据库管理员看到对象名就了解这个数据库对象所起的作用，恐怕会比较困难。而且在数据库对象引用的时候，数据库管理员也会为不能迅速找到所需要的数据库对象而头疼。

其次，表、视图、函数等最好也有统一的前缀。如视图可以用V为前缀，而函数则可以利用F为前缀。如此数据库管理员无论是在日常管理还是对象引用的时候，都能够在最短的时间内找到自己所需要的对象。

要求五：尽量只存储单一实体类型的数据。

这里将的实体类型跟数据类型不是一回事，要注意区分。这里讲的实体类型是指所需要描述对象的本身。笔者举一个例子，估计大家就可以明白其中的内容了。如现在有一个图书馆里系统，有图书基本信息、作者信息两个实体对象。若用户要把这两个实体对象信息放在同一张表中也是可以的。如可以把表设计成图书名字、图书作者等等。可是如此设计的话，会给后续的维护带来不少的麻烦。

如当后续有图书出版时，则需要为每次出版的图书增加作者信息，这无疑会增加额外的存储空间，也会增加记录的长度。而且若作者的情况有所改变，如住址改变了以后，则还需要去更改每本书的记录。同时，若这个作者的图书从数据库中全部删除之后，这个作者的信息也就荡然无存了。很明显，这不符合数据库设计规范化的需求。

遇到这种情况时，笔者建议可以把上面这张表分解成三种独立的表，分别为图书基本信息表、作者基本信息表、图书与作者对应表等等。如此设计以后，以上遇到的所有问题就都引刃而解了。

数据库原理及应用课程设计

一、课程设计的目的

《数据库原理及应用》课程设计是计算机科学与技术专业集中实践性环节之一，是学习完《数据库原理及应用》课程后进行的一次全面的综合练习。本课程设计主要在于加深学生对数据库基础理论和基本知识的理解，掌握数据库应用系统设计开发的基本方法，达到进一步使学生综合运用所学知识和增强实际动手能力的目的。

二、课程设计的任务与要求

要求学生根据自身对题目的理解情况，从给定的设计题目中选择一个，以MS SQL Server作为后台数据库平台，以PowerBuilder作为前台开发工具，完成一个小型数据库应用系统的系统的分析、设计和开发。

三、课程设计说明书

仓储管理系统

对于一个以生产或经营产品为主要业务的单位来说，仓库管理系统至关重要。高效方便的仓库管理系统，可以为生产经营提供坚强的后盾和有力的支持。效率低下甚至是混乱不堪的仓库管理系统，无疑会成为企业健康发展的拖累甚至是枷锁。使企业发展动力不足。本次数据库设计实现了仓库管理的高效化、电子化。通过本系统可以方便地实现仓库管理中的货物登记、出库入库等 *** 作，使仓库管理井井有条。

1系统需求分析

11系统功能需求分析

仓库管理系统主要实现对库存商品的管理，对商品出库、入库的管理，和对仓库管理系统维护的功能。具体要实现的功能包括：

1）库存商品管理

查看数据库中商品的名称、编号、单价等信息。

2）商品出库、入库管理

入库、出库单纪录本次入库、出库的货物名称、数量，入库、出库的时间、商品单价以及总价，入库、出库的经手人等。

3）商品的查询

输入商品的编号或者商品的名称查询信息

4）用户管理

用户可以修改登录密码

1 2数据需求分析

1员工（ID ，姓名，密码，权限）

2商品（商品名，商品编号，所属类，单价）

3出货表（商品名，商品编号，数量，总价，经手人）

4入货表（商品名，商品编号，数量，总价，经手人）

5查询（商品名，商品编号，数量，单价）

根据上面的关系我们需要的数据基本上就上面所列出的数据。

2 系统总体设计

1）库存商品管理

查看数据库中商品的名称、编号、单价等信息。

2）商品出库、入库管理

入库、出库单纪录本次入库、出库的货物名称、数量，入库、出库的时间、商品单价以及总价，入库、出库的经手人等。

3）商品的查询

输入商品的编号或者商品的名称查询信息

4）用户管理

用户可以修改登录密码

21系统总体结构设计

221 E-R图

222 关系模式

1员工（ID ，姓名，密码，权限）

2商品（商品名，商品编号，所属类，单价）

3出货表（商品名，商品编号，数量，总价，经手人）

4入货表（商品名，商品编号，数量，总价，经手人）

5查询（商品名，商品编号，数量，单价）

223 数据表

“员工信息表”“商品信息表”“出货单”“进货单”的主键分别是：ID、商品编号、商品编号、商品编号。

员工信息表

商品信息表

出货单

进货单

3．系统实施

工作界面PB90，以下是我制作过程和运行中的一些截图：

首先建立PB与SQL的数据链接：如果链接不成功，返回对以话框“数据库连接错误，经检查后再试！”

然后点Preview选项会d出如下窗口：

一、 工作界面截图：

分别建有：workspace、application、windows、dw_、da_等。

工作时检测连接数据库是否正常的程序代码：

// Profile q

SQLCADBMS = "ODBC"

SQLCAAutoCommit = False

SQLCADBParm = "ConnectString='DSN=仓库;UID=;PWD='"

connect;

open(w_enter)

二、 运行结果的截图：

这个是我运行后的第一个用户界面，在界面中输入管理员ID和密码。我的管理员ID 和密码分别为 1，123点击确定进入menu下一界面。

若ID和密码分别输入1，1234，则跳出以下界面：

确定按钮所对应的代码如下：

//定义两个变量

string password,userid

password=sle_2text

//检索用户名和密码记录

SELECT "员工信息表" "ID",

"员工信息表""密码"

INTO :userid,

:password

FROM "员工信息表"

WHERE "员工信息表""ID" =:sle_1text and "员工信息表""密码" =:sle_2text;

//判断用户输入的用户名是否正确

if sqlcasqlcode<>0 then

messagebox("错误！","ID或密码错误，请重新输入！",exclamation!,ok!,2)

else

messagebox("通过验证！","ID和密码正确，欢迎您使用本系统！",Information!,ok!,2)

open(w_main)

close(w_enter)

end if

取消按钮所对应的代码如下：

close(parent)

//关闭登录窗口

三、 menu界面的截图：

在本界面中我们通过点击菜单栏上的不同管理按钮来实现管理和 *** 作的功能。

进货—进货单

出货—出货单

库存—蔬菜类

—水产类

—肉类

系统维护—修改密码

查询

四、 进货的截图如下：

在本界面中， *** 作员可以输入进货信息

五、 进货的截图如下：

在本界面中， *** 作员可以输入出货信息

六、本界面是实现用户更改自己的密码的界面

用户在登陆后根据上面的提示可以更改自己的密码。

程序代码如下：

string oldid

string oldp

string newp1

string newp2

oldid=trim(sle_1text)

oldp=trim(sle_2text)

newp1=trim(sle_3text)

newp2=trim(sle_4text)

if len(oldp)=0 or isnull(oldp) then

oldp=space(10)

end if

if len(newp1)=0 or isnull(newp1) then

newp1=space(10)

end if

if len(newp2)=0 or isnull(newp2) then

newp2=space(10)

end if

select "operator""password"

into :oldp

from "operator"

where "operator""password"=:oldp;

if sqlcasqlcode<>0 then

messagebox("提示","原密码不正确!")

sle_2text=""

sle_2setfocus()

return

end if

if newp1<>newp2 then

messagebox("提示","两次新密码输入不同!")

sle_4text=""

sle_4setfocus()

return

end if

Update "operator"

set "password"=:newp1

where "operator""operator_id"=:oldid;

if sqlcasqlcode<>0 then

rollback;

messagebox("提示","密码更正错误! 请重设!")

return

end if

gs_password=newp1

commit;

messagebox("提示","密码修改成功!")

七、本 *** 作可以看仓库里的商品并可对其进行插入和删除

八、从仓库查询所需要的商品

4 系统评价

系统的功能基本上已经实现，但是还是不够完善。但是在使用的时候还是能给用户带来一定的方便的。仓库的进货和出货在本系统中能直观的以表格形式反映出来，便于 *** 作员的使用和决策者的管理。

41 系统特色

本系统要求用户进行验证之后才能进入相应的界面。有利于保护数据库的安全，不被非法登陆使用。对于仓库内货物的进出管理要求严格，即进出货时必须填写相应的进出货单据。便于企业管理查看账目，保障了企业的稳定运行。通过本系统可以方便地实现仓库管理中的货物登记、出库入库等 *** 作，使仓库管理井井有条。在查看数据库时可以方便的删除数据库中冗余的信息和添加新的信息。

42 系统不足及改进

这个系统基本上实现了一些简单的对系统所涉及表的更新、增加和删除的功能。也实现对用户登陆的安全上有了一定的限制，只有在正确输入ID和密码的时候才能进入系统。远没有达到大型公司的仓储物资管理的要求，所创建的数据库框架比较简单，各表之间的联系也过于简单，没有添加外键相互约束，用POWER BUILDER做出来的系统过于简单、单调，需要进一步深入的调整优化，将各表之间的关系紧密联系起来，相互制约，保证数据库中数据的添加、删除、更新，安全有序。 *** 作窗口还需要进一步的进行美化，使用户在使用中更赏心悦目。

5 课程设计心得

这次课程设计的主要目的是掌握数据库应用系统分析设计的基本方法，基本掌握PowerBuilder，进一步提高分析解决问题的综合能力。通过这次课程设计，我基本掌握了以上要求。但只有两周的课程设计时间，时间比较仓促，所以开发的系统不是很完善，有一些功能未实现，但是仓库管理的基本功能均已实现。以前对数据库的很多知识认识都不深刻，做过这次课程设计之后，我对数据库的知识有了一个比较系统的了解；比如：对表内一些字段的约束，关系等的运用已经比较熟练。这个课程设计使我巩固了数据库的知识。

对于PowerBuilder也有了一定的了解，由于用的不多，所以运用的不是很熟练。刚开始的时候，对于PowerBuilder的语法，用法等一系列知识都不熟悉。当我基本完成此系统开发的时候，我发现其实也没有那么难，在未做之前我还害怕做不出来。经过对这个系统的开发，在开发过程中遇到但也解决了很多问题，所以说我们不能惧怕有困难而不去接触认识它，我们要知难而上，只有这样我们才能成长，才能有所发展。

这认为最难的一部分是用户查看数据库时通过插入删除按钮对数据库的更改，因为我们在文本框中输入的数字是被默认为字符型的，我在其中使用了integer(string)这个函数把字符型的进行了转换，但是在使用的过程中并不能像我所想像的那样有用。因为时间有限，所以这个问题还没有完全的解决。

通过这次数据库课程设计加深我对数据库基础理论和基本知识的理解，掌握数据库应用系统设计开发的基本方法，达到进一步使我综合运用所学知识和增强实际动手能力的目的。

我会继续学习数据库的知识，学习PowerBuilder的知识，只有通过不断的学习充实自己，才能让自己有所得。只有了知识的积淀，才能为自己的发展铺平道路！

可以参考一下啊，最终还是要自己做的吧。。仅供参考。

需求分析

调查和分析用户的业务活动和数据的使用情况，弄清所用数据的种类、范围、数量以及它们在业务活动中交流的情况，确定用户对数据库系统的使用要求和各种约束条件等，形成用户需求规约。

需求分析是在用户调查的基础上，通过分析，逐步明确用户对系统的需求，包括数据需求和围绕这些数据的业务处理需求。在需求分析中，通过自顶向下，逐步分解的方法分析系统，分析的结果采用数据流程图(DFD)进行图形化的描述。

概念设计

对用户要求描述的现实世界(可能是一个工厂、一个商场或者一个学校等)，通过对其中诸处的分类、聚集和概括，建立抽象的概念数据模型。这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。所建立的模型应避开数据库在计算机上的具体实现细节，用一种抽象的形式表示出来。以扩充的实体—（E-R模型）联系模型方法为例，第一步先明确现实世界各部门所含的各种实体及其属性、实体间的联系以及对信息的制约条件等，从而给出各部门内所用信息的局部描述(在数据库中称为用户的局部视图)。第二步再将前面得到的多个用户的局部视图集成为一个全局视图，即用户要描述的现实世界的概念数据模型。

逻辑设计

主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式。与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”。

物理设计

根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储结构(包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法和存取路径等。这一步设计的结果就是所谓“物理数据库”。

验证设计

在上述设计的基础上，收集数据并具体建立一个数据库，运行一些典型的应用任务来验证数据库设计的正确性和合理性。一般，一个大型数据库的设计过程往往需要经过多次循环反复。当设计的某步发现问题时，可能就需要返回到前面去进行修改。因此，在做上述数据库设计时就应考虑到今后修改设计的可能性和方便性。

首先你得知道，酒店跟旅馆的业务有出入，

正规的酒店都是有饭馆，娱乐场所，和旅馆的业务合体。

而旅馆应该只是住宿离宿等业务。

你改的话把酒店吃饭，娱乐方面的模块去掉就可以了。

你把自己当客户，比如，进入酒店后，吃饭并不一定住宿，也不一定要娱乐。其他也是。

旅馆的业务我不清楚，应该只有住宿的业务吧，

所以酒店系统中的吃饭和娱乐子模块可以去掉了。

如果你的旅馆也有其他业务，那本身酒店的业务就保留。

而对于后台数据库，数据库里的对象，关于吃饭业务的表（包厢表，菜单表，订单表，账单表），娱乐业务的表（包间表，消费记录表，娱乐活动表等），以及这些表关联的视图，存储过程，索引，还有与其他还要留着的表的完整性约束（规则）也要修改或者删除。

这种系统改着还算简单，因为旅馆的业务刚好与酒店的部分业务还算好改，但是酒店如果只有吃饭业务那就另当别论了…

其实你改系统，弄清两个系统的业务关系与需求对此，然后仿照原有的程序与数据库改动就好了。

以上就是关于电子商务系统分析与设计怎么进行数据库设计全部的内容，包括:电子商务系统分析与设计怎么进行数据库设计、数据库设计技巧、如何合理和有效的进行数据库设计等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！