商品销售信息管理系统设计
1.设计目的
商品销售信息管理系统主要用于对商品信息的管理，包括客户端和管理端两部分，分别涉及商品购买和各类信息的处理。此系统的设计实现需要首先根据需求提出数据存储方案和信息管理技术方案，设计关系表上并规划相匹配的信息管理功能，分析其详细处理流程并用模块化程序设计思想进行程序系统设计、模块编程、测试，可以从中复习巩固关系型数据库的相关理论知识，运用所学开展信息管理对象的“实体-关联”分析，提高设计信息存储的“关系数据库、数据表”相关能力，积累数据库应用程序的综合开发能力，提高创新意识、创新能力。
2.需求分析
2.1系统业务分析
系统主要业务可分为客户需要的操作和管理员需要的操作。
其中，客户的业务包括：实名注册、查看商品信息、提交商品订单、查看自己订单、确认货到付款。
管理员的业务包括：信息查询、信息导入、信息管理、信息统计和导出报表，涉及到的信息包括客户信息、订单信息、商品信息和统计信息。
2.2系统数据处理分析
根据系统主要业务，可以分析得到管理员子系统和客户子系统两个主要子系统以及对应的数据流，系统顶层数据流图如图2-1所示。
客户子系统主要的数据处理过程分为对个人信息的处理、对商品的处理和对订单的处理，包括实名注册、查看个人信息、系统登录、查看商品信息、更新订单状态和查看订单信息，具体处理如下。
实名注册：提交个人信息，生成申请记录，转管理员端处理。
查看个人信息：给出个人信息记录。
系统登录：给出用户名和密码，提交登录，用户名存在且审核通过返回成功，否则返回对应错误。
查看商品信息：给出详细或模糊的商品描述，若能查询到，返回该商品信息否则返回对应错误。
更新订单状态：给出指定订单和相应操作，包括提交订单、修改订单、取消订单和确认货到付款，将操作结果转管理员端。
管理员子系统主要的数据处理过程分为对客户信息的处理、对商品的处理和对订单的处理，包括确认用户注册、查看客户信息、查看商品信息、更新商品信息、更新订单状态和查看订单信息，具体处理如下。
确认用户注册：给出申请记录和客户信息，若审核通过，更改申请记录状态和客户信息状态，返回给客户端。
查看客户信息：给出待查看客户信息编号或者待查看客户信息范围，给出指定客户信息或多条客户信息记录，若不存在指定客户，返回错误。
查看商品信息：给出待查看商品信息编号或者待查看商品信息范围，给出指定商品信息或多条商品信息记录，若不存在指定商品，返回错误。
更新商品信息：给出待更改商品编号及更新操作，可对该商品进行出库、入库、发货或者修改商品名称和价格。
更新订单状态：给出待更改订单编号及更新操作，可确认该订单发货、取消订单、修改订单中地址、商品数量等信息。
查看订单信息：给出待查看订单信息编号或者待查看订单信息范围，给出指定订单信息或多条订单信息记录，若不存在指定订单，返回错误。
2.3系统数据字典
由图2-1可知系统顶层数据流，进一步分析可知用户子系统和管理员子系统功能如下。
(1)客户子系统
查看、修改和校验个人信息：客户→P1，客户→P2，客户→P3；
提交注册信息：客户→P4；
查看、更新订单信息：客户→P5，客户→P6；
查看商品信息：客户→P7。
(2)管理员子系统
查看、修改客户信息：管理员→P7；
审核用户注册：管理员→P8；
查看、更新订单信息：管理员→P6；
查看、更新商品信息：管理员→P7，管理员→P9。
综上所述，可得如表2-1所示的系统主要数据流定义。
| 序号 | 数据流名称 | 数据流位置 | 结构定义 |
|---|---|---|---|
| 1 | 查看个人信息/修改个人信息/系统登录/查看客户信息 | 客户→P1，客户→P3，客户→P2，管理员→P7 | 身份证号+姓名+电话+地址+用户名+密码 |
| 2 | 实名注册/确认注册 | 客户→P4，管理员→P8 | 用户名+审核状态+审核时间 |
| 3 | 查看订单信息/更新订单信息 | 客户→P5，客户→P6，管理员→P6 | 订单编号+用户名+商品名称+商品数量+价格+创建时间+发货状态+付款状态+地址 |
| 4 | 查看商品信息 | /更新商品信息 | 客户→P7，管理员→P7,管理员→P9 |
根据图2-1和表2-1分析可知，管理员子系统和客户子系统中包含有类似的数据，则系统中主要包含四类数据，即D1客户信息、D2订单信息、D3商品信息、D4申请记录，其主要存储结构定义如表2-2所示。
| 序号 | 数据流名称 | 输入 | 输出 | 结构 | 说明 |
|---|---|---|---|---|---|
| D1 | 客户信息 | 客户管理 | 查看、实名注册、更新客户信息 | 身份证号+姓名+电话+地址+用户名+密码 | 身份证号唯一非空符合格式，姓名密码电话非空，电话时间格式 |
| D2 | 订单信息 | 订单管理 | 查看、更新订单信息 | 订单编号+用户名+商品名称+商品数量+价格+创建时间+发货状态+付款状态 | 用户名唯一非空，商品名称多值价格对应，发货付款状态非空 |
| D3 | 商品信息 | 商品管理 | 查看、更新订单信息 | 商品编号+商品名称+商品数量+价格 | 名称唯一非空、价格格式 |
| D4 | 申请记录 | 客户管理 | 实名注册 | 用户名+审核状态+审核时间 | 用户名非空，时间格式 |
综合表2-1和表2-2可知，客户子系统的数据处理过程包括对个人信息的处理部分P1和对购物信息的处理部分P2。在个人信息模块P1中包含的处理过程包括P1.1查看个人信息、P1.1查看个人信息、P1.2修改个人信息、P1.3实名注册和P1.4系统登录，在购物信息处理模块P2中包括P2.1确认货到付款、P2.2查看订单信息、P2.3查看商品信息、P2.4提交订单和P2.5取消订单。各部分输入输出和处理说明见表2-3。
| 编号 | 处理过程名 | 输入 | 输出 | 处理说明 |
|---|---|---|---|---|
| P1.1 | 查看个人信息 | 用户账号 | 该账号信息 | 在用户数据库中找指定账号信息 |
| P1.2 | 修改个人信息 | 用户账号 | 修改结果、修改信息 | 在用户数据库中改指定账号信息 |
| P1.3 | 实名注册 | 用户身份信息 | 注册结果 | 提交管理员 |
| P1.4 | 系统登录 | 用户账号密码 | 登录结果 | 比对账号密码是否一致 |
| P2.1 | 确认货到付款 | 用户账号、订单号 | 确认结果 | 修改订单状态 |
| P2.2 | 查看订单信息 | 用户账号、订单号 | 订单信息 | 在订单数据库中查找指定信息 |
| P2.3 | 查看商品信息 | 商品名称 | 商品信息 | 在商品数据库中查找指定信息 |
| P2.4 | 提交订单 | 用户账号、数量、商品名称、时间 | 提交结果 | 在订单数据库中写入相关信息 |
| P2.5 | 取消订单 | 用户账号、订单号 | 取消结果 | 改变该订单状态 |
综合表2-1和表2-2可知，管理员子系统的数据处理过程包括对客户信息的处理部分P1对商品信息的处理部分P2和对订单信息的处理部分P3。在个人信息模块P1中包含的处理过程包括P1.1查看客户信息、P1.2确认客户注册，在商品信息处理模块P2中包括P2.1查看商品信息和P2.2更新商品信息，在订单信息处理模块P3中包括P3.1查看订单信息、P3.2更新订单状态和P3.3确认发货。各部分输入输出和处理说明见表2-4。
| 过程编号 | 处理过程名 | 输入 | 输出 | 处理说明 |
|---|---|---|---|---|
| P1.1 | 查看客户信息 | / | 客户信息 | 到指定数据库中查找客户信息并输出 |
| P1.2 | 确认客户注册 | 注册请求 | 注册答复 | 交由管理员确定是否允许注册 |
| P2.1 | 查看商品信息 | / | 商品信息 | 到指定数据库中查找商品信息并输出 |
| P2.2 | 更新商品信息 | 商品、操作 | 操作结果 | 对指定商品信息进行指定操作 |
| P3.1 | 查看订单信息 | / | 订单信息 | 到指定数据库中查找订单信息并输出 |
| P3.2 | 更新订单状态 | 订单、操作 | 操作结果 | 对指定订单信息进行指定操作 |
| P3.3 | 确认发货 | 订单、商品、发货数量 | 发货状态 | 修改订单状态和商品状态 |
3.系统设计
3.1系统开发框架
系统设计基于ASP.NET Core，使用Entity Framework MVC框架进行开发，包含表示层、业务逻辑层和数据访问层三层结构。其中表示层使用网页技术设计页面及控件，业务逻辑层使用C#语言完成代码逻辑，数据访问层通过C#的MySQL扩展接口实现与MySQL数据库的连接。整体代码在Visual Studio 2019 和Visual Code2019中完成编写与调试，操作系统兼容Windows 7以上系统，数据库使用MySQL 8.0。
3.2系统功能组成设计
3.2.1 系统功能组成
分析可知，商品信息管理系统主要分为管理员子系统和客户子系统两部分，进入管理员子系统后可以管理整个系统，在整个系统中被管理的对象主要包括客户信息、商品信息和订单信息，此外，管理员还可以统计相关信息，并将内部信息导出为文件或从外部文件中导入相关信息(文件存储为Excel格式)，进入客户子系统可以管理个人信息或者进行购物。由此可得系统除上述两个子系统外，还应划分为商品购物、个人信息管理、商品信息管理、订单信息管理、客户信息管理、信息统计(包含文件导入导出)这几个主要模块。
其中，客户子系统只能访问个人信息管理和商品购物两个模块，可以在前者中执行注册、登录、修改信息和查看信息功能，在商品购物模块中，可以查看商品信息、提交订单、修改订单或者确认货到付款。管理员除可以访问所有客户的客户子系统外，还可以访问其他模块。在管理员的客户信息模块中，管理员能够确认用户的注册或者修改用户信息，在商品管理模块中，可以管理商品信息(包含商品发货)或者查看商品信息，在订单信息管理状态模块中可以查看或者更新订单状态，在统计模块中可以对系统中管理的各个对象信息进行分析统计或者利用外部文件构造内部信息以及将内部信息导出为外部文件。具体的系统功能层次划分图如图3-1所示。综合上述分析可知，使用系统的角色主要包含“管理员”和“客户”两种角色，功能层次图最底层中功能为二者执行系统功能时的具体用例，其余层及其关系为二者使用系统时的顶层用例划分，则可依据图3-1得到系统顶层用例图如图3-2所示，管理员子系统对客户子系统的操作通过用例间的包含和扩展关系体现，同时可依据功能层次图最底层得到细分的系统功能用例图如图3-2所示。
综合上述分析可知，系统顶层用例图如图3-2所示。
3.2.2 子系统功能模块设计
根据上述3.1设计子系统功能模块和界面，开始时系统界面布局如图3-4所示，其中包含提示信息和“管理系统”、“用户登录”两个按钮。
上述图3-6与图3-7中管理权限获取界面和用户登录界面执行流程如图3-8所示，管理员验证默认秘钥成功后进入管理员界面，失败后给出提示信息，若三次不成功则登陆失败，返回主界面，并在一段时间内不能登录。用户在验证密码和用户名匹配后进入用户界面，若不匹配同样给出提示并在三次后暂时不能登陆，此时提示信息变为管理员联系方式，可联系管理员修改信息。
管理员子系统界面布局如图3-9所示，其中左边包括可执行功能的按钮栏目，右边为信息显示区域和对信息操作的按钮。
用户子系统界面布局如图3-10所示，与管理员子系统相同，其左右同样分别为操作按钮栏目和信息显示窗口，并可在信息显示窗口下方的按钮执行对上方信息的操作。
在管理员和用户界面中，所有对于信息的查看和修改操作执行流程均相同，只是对于不同的信息，将跳转到不同的执行界面，因而不在此赘述。两个子系统中所有查看、修改信息的执行流程图如图3-11所示。如果在左侧按钮栏选择查看某种信息，则在右方显示对应的信息，如果没有进一步的操作，信息将持续显示，如果有进一步的操作，跳转到对应的操作。在选择信息修改时，可修改的信息会从文本变为可编辑文本框，在框内输入符合格式的信息后按相应按钮确认，即可完成操作。上图3-10中内容即为用户在对个人信息中的地址修改时的样例，客户在选择修改个人信息后，可修改的地址后出现文本框，将其内容修改完成后选择确认修改，即可完成对个人地址信息的修改。查看个人信息时页面显示与图3-12当前状态相同，但不存在可编辑的文本框。
用户子系统中查看订单信息和商品信息界面布局如图3-12和3-13所示。订单信息中包含确认收货、修改订单信息和提交订单三个按钮，修改信息的流程如上图3-13所示。
确认收货与提交订单流程如图3-14(左)所示，在选择相应功能后订单中对应的状态会发生改变。如果需要购买商品，其流程如图3-14(右)所示，输入数量后加入订单即可。
3.3数据库结构设计
3.3.1 商品管理系统的对象/实体
首先将使用商品管理系统的角色转换为实体，由上文分析可知此角色包含客户和管理员，在此次设计中认为只存在一位持有秘钥的管理员且不考虑其管理员信息，故可将管理员实体省略。此外，系统中主要包含对商品的处理，故应将商品作为一实体。其主要联系包括：
客户通过浏览商品购买商品，并进行提交，申请者通过实名认证发出认证请求，管理员进行审核，管理员对客户信息、商品信息、订单信息进行维护更新和查看。
管理员还要进行定期的商品销售、客户信息以及订单等信息统计与分析。所以此系统的概念模型如图3-15所示，由于申请者信息与客户信息仅在申请状态上有所差异，其余信息完全相同，所以可以将申请状态作为客户信息的一个字段，将申请者同样视为客户，从而简化设计。
3.3.2 概念模型转换为关系模型
综合上述内容，分析可得系统关系模型图如图3-16所示。
客户(身份证号|姓名|电话|用户名|密码|地址|申请状态)；
商品(商品编号|商品名称|商品数量|价格)；
订单(订单号|用户名|商品名称|商品数量|总价|创建时间|发货状态|付款状态)。
3.3.2 定义关系模型
对于表“客户(身份证号|姓名|电话|用户名|密码|地址|申请状态)”，主键为用户名，属性间的仅存在函数依赖关系：{申请状态·姓名·密码·地址→身份证号，申请状态·姓名·密码·地址→电话，申请状态·姓名·密码·地址→用户名}，符合3NF的要求。
对于表“订单(订单号，用户名，商品名称，商品数量，总价，创建时间，发货状态，付款状态)”，主键为订单号，属性间存在函数依赖关系：{商品名称→商品数量}，根据3NF的要求，将表订单拆分为两张表，其中“订单”表作为主表，“订单商品”表作为从表，将订单表的主键作为订单商品表的外键。在订单中包含属性“订单编号|客户编号|订单总价|付款状态|发货状态”，在订单商品汇总包含属性“订单商品编号|订单编号|商品编号|商品数量|商品总价”。由此，可满足3NF的要求。
对于表“商品(商品编号，商品名称，商品数量，价格)”，主键为商品编号，属性间的仅存在函数依赖关系：:{商品名称→商品数量，商品名称→价格}，符合3NF的要求。
由上述内容归纳总结出三张表中属性的详细信息如表3-1所示，表中包含各表的表名、属性、数据类型、长度、是否可空、索引信息、属性约束和表级约束。在后续的设计过程中，个属性的基本信息均需遵从该表的规定。
| 表名 | 属性 | 数据类型 | 长度 | 可空 | 索引 | 属性约束 | 表级约束 |
|---|---|---|---|---|---|---|---|
| 客户 | 身份证号 | char | 18 | no | 索引 | 全为数字 | 主码：用户名 |
| - | 姓名 | varchar | 12 | no | 索引 | / | - |
| - | 电话 | char | 11 | no | / | 全为数字 | - |
| - | 用户名 | varchar | 12 | no | 索引 | 主属性 | - |
| - | 密码 | varchar | 15 | no | 索引 | 字母数字混合 | - |
| - | 地址 | text | 20 | no / | / | - | |
| - | 申请状态 | tinyint(1) | 1 | no | / | 0无效,1有效,-1曾有效 | - |
| 商品 | 商品编号 | char | 10 | no | 索引 | 主属性 | 主码：商品编号 |
| - | 商品名称 | varchar | 11 | no | 索引 | / | - |
| - | 商品数量 | int | 4 | no | / | 非负 | - |
| - | 价格 | double | 5 | no | / | 正数 | - |
| 订单 | 总价 | double | 5 | no | / | 非负 | 主码：订单号 从键：商品名称，用户名 |
| - | 发货状态 | tinyint(1) | 3 | no | / | 0未发货，1已发货 | - |
| - | 付款状态 | tinyint(1) | 3 | no | / | 0未付款，1已付款 | - |
| - | 订单号 | varchar | 10 | no | 索引 | 主属性 | - |
| - | 用户名 | varchar | 12 | no | 索引 | / | - |
| 订单商品 | 订单商品编号 | varchar | 10 | no | 索引 | 主属性 | |
| - | 商品名称 | varchar | 11 | no | 索引 | / | - |
| - | 购买数量 | int | 4 | no | / | 非负 | - |
| - | 订单号 | varchar | 10 | no | 索引 | 外键 | - |
| - | 商品总价 | double | 4 | no | / | / | - |
基于根据上述内容，可得到完整的数据关系图如图3-16所所示。图中矩形框代表一张表，其中矩形框的顶部为该表的表名，下方为表中各属性及该属性在数据库中的数据类型。如果该属性为该表的主属性，则在该属性处用下划线和标识。各表间的从属关系用由从表指向主表的箭头表示，作为外键的属性在从表中用加以标识。图中的表明、属性名符合MySQL数据库中关系表的命名规则，以便于后续编程实现。
在图3-16中，客户表为customer，商品表为product，订单表为orders，订单商品表为iporder，各表的主键分别为该表的编号，各属性信息与上表3-1相同。
4.数据库实施与数据准备
4.1数据库实施
根据附录中的小组分工表，此设计报主要针对订单相关的两张表单进行设计与实现。首先由图3-16中建立的数据关系图在数据库中建立相关表，建立orders表的SQL语句如代码4-1所示，用CREATE语句创建表orders，在括号中对所有属性命名并规定其类型，用NOT NULL标记该属性不为空，对于pay_state（付款状态）和send_state（发货状态）两个状态，其取值只能取1和0，分别表示已操作和未操作，则利用 CHECK ( pay_state IN ( 0, 1 ) ) 语句检查其取值是否在取值区间范围内，send_state 状态的-1用于标记该订单已被取消或退货，pay_state被用于标识该订单已被删除，利用PRIMARY KEY(cid) 表明其主键为oid。最后通过下方的语句，将该表对客户的外键依赖添加在该表上。
/* Table: orders*/
CREATE TABLE orders (
oid VARCHAR ( 10 ) NOT NULL,
cid VARCHAR ( 10 ) NOT NULL,
total_price DOUBLE NOT NULL,
pay_state INT NOT NULL CHECK ( pay_state IN ( 0, 1 , -1 ) ) ,
send_state INT NOT NULL CHECK ( send_state IN ( 0, 1 , -1 ) ) ,
PRIMARY KEY ( oid )
);
ALTER TABLE orders ADD CONSTRAINT FK_Reference_3 FOREIGN KEY ( cid ) REFERENCES constmer ( cid ) ON DELETE RESTRICT ON UPDATE RESTRICT;
建立odproduct表的SQL语句如代码4-2所示，同样用CREATE语句创建表并在括号中对所有属性命名并规定其类型，用NOT NULL标记该属性不为空，，利用PRIMARY KEY( opid ) 表明其主键为opid。最后通过下方的语句，将该表对客户的外键依赖添加在该表上。
CREATE TABLE odproduct (
opid VARCHAR ( 50 ) NOT NULL,
oid VARCHAR ( 50 ) NOT NULL,
pid VARCHAR ( 50 ) NOT NULL,
count INT NOT NULL,
price DOUBLE,
PRIMARY KEY ( opid ) );
ALTER TABLE odproduct ADD CONSTRAINT FK_Reference_1 FOREIGN KEY ( oid ) REFERENCES orders ( oid ) ON DELETE RESTRICT ON UPDATE RESTRICT;
ALTER TABLE odproduct ADD CONSTRAINT FK_Reference_2 FOREIGN KEY ( pid ) REFERENCES product ( pid ) ON DELETE RESTRICT ON UPDATE RESTRICT;
在上述代码段中通过CHECK语句标记数据的完整性，但并没有设置触发器，触发器实现的对数据完整性的保证将在数据控制层之上的代码中实现，这是基于系统性能需求和响应时间做出的选择。
由于后续的代码开发过程使用Entity Framework框架，该框架的一大弊端在于系统的性能较差，响应时间长，但优点在于其可通过高耦合、低内聚的特性减少代码量，使得开发者能将更多经历关注在业务逻辑上。该框架包含表示层、业务逻辑层、数据访问层三册架构，可通过数据访问层与数据库所在的数据层发生交互并操作数据库中的数据，即实际上使用该框架完成的系统至少包含四层结构。
其表示层与用户直接进行交互，业务逻辑层处理用户请求并将需要进行数据访问的请求传递给数据访问层，同时传递相关数据，数据访问层进行对数据库的操作。而数据在各层间传递时要占用一定量的资源，存在一定的时空耗费。在使用此类系统时，用户如果在表示层进行数据的操作，则不会直接与数据层的数据库发生联系，数据会经过业务逻辑层和数据访问层才能到达数据层。
在各层之间数据的传递需要一定的时间，如果将触发器直接建立在数据层，当用户输入了错误的数据，该数据会直接经过上三层的传递，直到数据访问层或者数据层才能被检测出错误，而该错误信息同样要经过上三层的传递才能由用户接收。而若每次用户的输入均需要经过这样的检测过程，则其等待时间必然远超过理想的系统响应时间。因而在设计时选择将触发器相关功能的实现建立在业务逻辑层之上以减少输入数据时处理和响应的时间。而底层建立的其他完整性约束，均可通过限制页面输入内容（如只能选择提供的备选输入）
最低0.47元/天 解锁文章
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
