-订单管理
Posted m0_46218511
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了-订单管理相关的知识，希望对你有一定的参考价值。
文章目录
重要专业名词含义
代理键：
（1）代理键是系统生成，本身无意义，数仓中不允许一个表中只有代理键而没有自然键。
（2）代理键不能暴露给用户，用于join关联使用，不用于where筛选使用
（3）自然键与代理键相反，是在自然（真实）生活中唯一确定一个事物的标识。身份证号（理论上，假设没有因技术原因造成的重复）就是一个自然键，用于确定一个人。
操作型数据： 业务侧数据，ODS层
分析型数据： 数仓的数据
一、订单管理总线矩阵
列：代表维度
行：代表业务过程
X ：代表该行业务过程需要该维度
二、订单事务
2.1 事实表规范化
书中描述： 保留单一的、通用的事实数量以及维度，用于区分度量类型。规范化后的表是每个度量每订单明细一行，而不是更自然的每个订单明细事件一行。度量类型维度指明事实是什么度量（eg：总的订单数量、订单折扣数量还是其他度量）。
通俗说法： 事实表规范化指，如一个事实表有5个维度，7个事实，那么规范化之后变成了7行，每行5个原来的维度一个度量类型维度和1个事实，即把7个事实分为7行。
缺点：
（1）行数会增加。规范化事实，需要以事实表中行数量乘以事实类型数量。
（2）不方便在事实间执行算数函数。（例如计算成交量/意向金支付量），事实在同一行方便计算，在不同行计算困难。
优点：在第14章中，会讨论一种能够使度量类型维度更有意义的环境。
2.2 日期维度（维度角色扮演）
什么维度角色扮演： 某个维度在单一事实表中同时出现多次时，会出现维度模型的角色扮演。（事实表中同时出现两个日期列，意向金支付日期、交车已定日期，需要关联同一个日期维度表的不同视图/别名）。
在总线矩阵中文档化角色扮演的常见技术是在矩阵的一个单元中标明多种角色，如图6-4所示。
2.2.1 角色扮演与总线矩阵
在总线矩阵中文档化角色扮演的常见技术是在矩阵的一个单元中标明多种角色，如图6-4所示。
2.3 产品维度
2.3.1 产品维度共同特征
（1）大量冗长的、描述性的列
（2）一个或多个属性层次，加上没有层次的属性。（城市、省份）
（3）重新建立操作型代码到代理键的映射
整合不同业务系统中的产品到数仓中，不同业务系统中的相同产品的自然键如果不同，需要数仓来维护一张多个业务系统与数仓的产品映射表
（4）增加描述性属性值以扩大或替换操作型代码
替换：产品维度列是查询约束和报表标识的唯一来源，因此必须具有易读性，模糊的缩略词或纯数字编码都不合适。
扩大：单一列中包含多个缩略词的代码应该被扩展或分割成不同的属性。
（5）检查属性值，确保没有拼写错误、不可能存在的值、多变量等
（6）将属性定义、解释、元数据来源文档化
2.3.2 维度的层次结构
维度层次：
维度层次是描述维度内部结构的属性集合，它刻画了维度内部不同成员间的相对关系。在多维数据库中，每个维可以有其自身的维度层次结构。考虑这样一个商业销售用多维数据库，它含有4个维度，分别为产品维，客户维，时间维，仓库维。对于时间维，可以有“年–季度–月份”这样一个层次，而对于产品维，也可以有“产品类别–品牌–产品名”这样一个层次。
层次结构有时用金字塔结构来表示，唯一例外是所有成员都在同一个层次。如金字塔结构一样，在塔顶，即维度层次较高方，其成员数量比塔底，即维度层次较地方的成员数量要少。如在一个地理维度中，它包含层次“洲—国家—城市”，“欧洲”属于“洲”层次，“法国”属于“国家”层次，而“巴黎”属于“城市”层次。显而易见，属于“洲”层次的成员数量少于属于“国家”层次的成员数量，而属于“国家”层次的成员数量亦少于属于“城市”层次的成员数量。同时，层次越高，描述性越模糊，层次越低，描述性越细致。如上述所提及地理维度，“欧洲”的描述性比“法国”的描述性模糊，而“法国”的描述性也比“巴黎”的描述性要模糊。
维度建模如何处理：
（1）第一种是将所有维度层次结构全部扁平化、冗余存储到一个维度表中，比如商品的一至三级类目分别用三个字段来存储，品牌等的处理也是类似的；
（2）第二种是新建类目维度表，并在维度表中维护父子关系。
2.3.3 规范化与反规范化
规范化： 当属性层次被实例化为一一系列维度，而不是单一的维度时。大多数联机事务处理系统（OLTP）的底层数据结构在设计时采用此种规范化技术，通过规范化处理将重复属性移至其自身所属的表中，删除冗余数据。
这种方法用在OLTP系统中可以有效避免数据冗余导致的不一致性。比如在OLTP系统中，存在商品表和类目表，且商品表中有冗余的类目表的属性字段，假设对某类目进行更新，则必须更新商品表和类目表，且由于商品表和类目表是一对多的关系，商品表可能每次需要更新几十万甚至上百万条记录，这是不合理的。
对于商品维度，如果进行规范化处理，将表现为如下图所示。
反规范化： 将维度表的属性层次合并到单个维度中的操作被称为反规范化。分析系统的主要目的是用于数据分析和统计，如何更方便用户进行统计分析决定了分析系统的优劣。采用这种模式，用户在统计分析的过程中需要大量的关联操作，使用复杂度高，同时查询性能很差；而采用反规范化处理，则方便、易用且性能好。
对于商品维度，如果采用反规范化处理，将表现为如下图所示。
2.4 客户维度
2.4.1 单一维度表与多维度表
客户维度中另一个潜在的层次是制造商销售组织。设计者有时会疑问销售代理属性是应该单独建立一张维度表还是合并到客户维度中去。如果销售代理和客户以一对一或多对多关系高度相关，则可以将销售代理属性合并到客户维度中，这样建立的维度可以更方便的浏览。
（1）如果多对多关系是一种例外，则应该坚持将销售代理属性合并到客户维度中去，如果多对多关系常见，则应该为销售代理和客户分别建立维度表。
（2）如果销售代理和客户维度的关系会随着时间的变化而变化，或者这种关系会受到其他维度影响，最好将销售代理和客户建立不同的维度表。
（3）如果客户维度非常巨大，最好为销售代理单独建立维度表，因为如果合并到一起，在进行销售代理分析时要涉及到海量的客户维度。
（4）当其他的业务过程需要涉及销售代理时，需要将销售代理单独建立维度表，将合并后的客户维度单独用于订单业务过程。
（5）如果没有特殊原因，强迫将两个不同维度合并成一个维度是没有意义的。不要为了合并而合并。
2.4.2 应用于客户/代理分配的无事实的事实表
2.5 交易维度（todo）
2.6 针对订单号的退化维度
什么是退化维度： 就是那些看起来像是事实表的一个维度关键字，但实际上并没有对应的维度表，就是维度属性存储到事实表中，这种存储到事实表中的维度列被称为退化维度。
因为处于事实表中的订单号没有与维度表连接，所以它是一种退化维度。
优点： 简化维度数据仓库的模式。因为简单的模式比复杂的更容易理解，也有更好的查询性能。（减少事实表和维度表的关联）
2.7 杂项维度
书中描述： 事务型商业过程通常产生一些列混杂的、低粒度的标识和指示器。与其为每个标识或属性定义不同的维度，不如建立单独的将不同维度合并到一起的杂项维度。这些维度，通常在一个模式中标记为事务型概要维度，不需要所有属性可能值的笛卡尔积，但应该包含实际发生在源数据中的合并值。
形象的解释： 就是将一些具有有限枚举值的字段值拼接在一起作为一行或者是多个字段的可能值不进行拼接而是作为多列组合，最后在杂项维度行中呈现。
三、发票事务（todo）
3.1 作为事实、维度或两者兼顾的服务级性能
3.2 利润与损益事实
3.3 审计维度
四、用于订单整个流水线的累积快照
4.1 延迟计算
4.2 多种度量单位
4.3 超越后视镜
五、小结
基于springboot+vue共享充电宝管理系统
功能介绍
管理员：首页、个人中心、用户管理、维护人员管理、区域信息管理、合作商户管理、充电宝投放管理、租赁订单管理、归还订单管理、费用订单管理、充电宝维护管理、公告栏管理、系统管理，维护人员；首页、个人中心、充电宝投放管理、租赁订单管理、归还订单管理、费用订单管理、充电宝维护管理，用户；首页、个人中心、租赁订单管理、归还订单管理、费用订单管理，前台首页：首页、合作商户、充电宝投放、公告栏、个人中心、后台管理。
如今生活每个人都离不开手机，出门等地铁，公交车上，甚至上厕所都在玩手机，尤其是在现在手机应用多的数不胜数的情况下，各种APP应用吸引着用户大肆地玩手机，如游戏，新闻，和小视频等等，这些APP应用玩着会上瘾，当你出门时正在看着手机玩得上 劲的时候，此时手机突然没有电了，这种感受很多人都有遇到过。手机待机一般到晚上都没电了，有的手机电池差的中午就没电了，当出差或在外的时候，正在谈着项目的时候通话突然断了就有可能影响整个公司经济利润或项目运营，情况还有更严重的，所以出门在外手机没电的烦恼一直緾绕着人们。直到共享充电宝的诞生，让人们出门在外玩游戏，工作都有了足够的底气放肆地去玩，而共享充电宝管理必须要有一套完整的管理方案才能进行共享，包括收费金额，投放地点等管理，让共享充电宝走向更多的商家，慢慢扩大到全国各地，这方面管理金额费用极高，因此开发本系统的意义在于让投资商更容易管理这些遍布各地的充电宝。
目 录
摘 要 I
ABSTRACT II
目 录 II
第1章 绪论 1
1.1背景及意义 1
1.2 国内外研究概况 1
1.3 研究的内容 1
第2章 相关技术 2
2.1 java简介 2
2.2 SSM三大框架 2
2.3 Eclipse开发环境 2
2.4 Tomcat服务器 3
2.5 MySQL数据库 3
第3章 系统分析 4
3.1 需求分析 4
3.2 系统可行性分析 4
3.2.1技术可行性：技术背景 4
3.2.2经济可行性 5
3.2.3操作可行性： 5
3.3 项目设计目标与原则 5
3.4系统流程分析 6
3.4.1操作流程 6
3.4.2添加信息流程 7
3.4.3删除信息流程 8
第4章 系统设计 10
4.1 系统体系结构 10
4.2开发流程设计 11
4.3 数据库设计原则 12
4.4 数据表 14
第5章 系统详细设计 19
5.1管理员功能模块 19
5.2维护人员功能模块 22
5.3用户功能模块 22
5.4前台首页功能模块 22
第6章 系统测试 26
6.1系统测试的目的 26
6.2系统测试方法 27
6.3功能测试 27
结 论 29
致 谢 30
参考文献 31
以上是关于-订单管理的主要内容，如果未能解决你的问题，请参考以下文章
「源码分享」ASP.NET仓库进销存ERP管理系统+小程序源码