速求数据库实践报告和配套数据库

发布网友 发布时间：2022-04-22 06:08

我来回答

共2个回答

懂视网 时间：2022-05-02 00:04

　　兜兜转转，突然发现我现在已经是一个老司机了，一直写代码都很忙，没有把很多点点滴滴的记录下来，今天开始就开始一个系列，分析当年我接触或者我设计过的表结构，有好有坏，有欢喜也有泪水。很多实践经验来自于踩了一个又一个的坑，从现在的角度去回想，在设计的时候如果那么做，也许我就不需要改代码了……

　　欢迎各位在评论区讨论，我只是想分享一下看法，也许有高人有更好的解法。以下案例从我的实践中简化而来，个别命名或者设计请勿对号入座，字段名等也是随便写的，只作示例。

问题：一个流程管理的模块如何设计表结构

需求细节：产品的需求大约是这样，一个订单取消退货的流程，中间有审批环节，所有人都通过以后，可以执行取消动作，所有的退订申请都需要有时间记录。

Round1

开发疑问：

（此处内心暗暗的骂产品经理一千遍，又来搞我，一句话需求。）

数据量多大？不知道

审核动作需要记录什么？审核人，审核时间。

审核人有几个？3个，销售主管，销售总监，财务

Round2

产品看了一下，似乎和他说的差不多，没毛病。转过一圈后问，我们可以获取到每个取消订单的耗时吗？妈蛋，二次需求或者说没把需求一次说全。这个时候开发就需要自行帮产品经理脑补。那么

申请退款的发起人不一定是客户，是不是也需要记录？

即使审核完成，最后执行退货动作也需要耗时间，那么退货开始和结束时间其实需要另外的两个字段来记录？

OK，那么把各种时间都给它加上。这个时候设计上没什么难度，难度是谁知道产品经理给你漏了什么关键需求……

Round3

产品经理退下之后，给销售经理打了个电话，听说你们有一个退货的需求？

是，是，最近不是315嘛，客户要退，那么就必须给退啊，客户是上帝啊。哦对了，我们这里退货还要分全退和部分退，这个可以支持吗？

什么鬼？那如果部分退，我是不是还要收手续费？

没错啊，财务是这么定的，30天内免费退换货，30天后要按比例收。

妈蛋，我让产品经理和你来细化一下需求。

（此处和产品经理撕逼100遍……）

细致的分析：

退货有类别的区分，退货其实需要按照操作流程，退货内容，审核流程等将表细分，通过一个统一的退货id来关联。

操作流程等的记录建议分离开来，否则以后扩展需求会有隐患。

相关的表设计修改如下图：

cancellation_info:退货信息，算是主表

cancellation_audit:退货审批

cancellation_product:退货产品及明细

(备注：

1. 退货产品及相关信息这里用到了主从表，为什么这么用或者也许有其他设计，这里不作展开，因为我实际案例中碰到的就是这样。
2. 也见过把退货产品加一个类别区分后直接放入订单表的设计，这样以后统计算某产品销售总数确实是方便了，和订单分开2张表这样的设计也是可以接受)

Round4

OK，终于基本搞定销售经理的需求了，那么再给财务打了个电话确认需求。

喂，听说我们这里有一个退货的需求和您确认一下。

好啊，现在退货审批简化了，我这里不需要审批，只需要执行，销售那边确认完，算好退款金额给我，我只执行退款。

什么？……

（心中默默的哭泣）

疑问点：

流程需要变更吗？变更频率是多少？

审核流程是单向的流程吗？例如取消原因没写清楚，是执行退回操作，之后同一笔退订申请可以再走审核流程，还是必须另起一个流程？

分析：

流程变化这种事很难控制，所以流程和时间节点记录不能用横表来扩展，这样的后果就是一旦流程变更，就要变更数据表。

横向的表也不能处理跳回和反复执行的流程。

现今的系统设计时，操作人操作时间等的记录都需要更完善，所以能考虑的都给它考虑上，加上各种note，memo，记录各种异常情况或者备注以防万一。

新的audit表不再是按cancellationid对应一条记录，而是一个cancellationid对应多条记录，并有了的auditid。而且每一步审核人都可以的记录result和memo，记录会更详尽，各个审核时间也有了一个统一的字段，之后统计某一个退货审核的耗时，可以用cancellationid来检索，最大最小时间相减即可。另外，我个人的建议是将退货的发起时间和执行完成时间也记录在此。

Others

实际案例中，还有很多很多的细节，如财务需要记录凭证和其他事物。销售那里还有退货地址等等

销售那里9成会提说有一个当前的退货状态的实时报表，所以在cancellation_info里加个状态标志位等，方便实际应用我觉得也是可以考虑的设计。

总结

我觉得数据表设计2个主要思辨方向：一个是业务驱动，一个是统计驱动。

业务驱动是说，业务需求需要你把各种数据记录下来，没有记录以后就做不了相关的功能，然后我们按照各种数据库设计的模式记录数据。统计驱动是说满足了基本业务流程需要后，很多数据的实际应用主要是各种统计报表中，要考虑到统计报表时获取数据的方便性。在设计时，兼顾考虑2方面的需求，这个案例主要说的是业务相关的驱动，要统计审核时间等又与统计驱动有关。

设计多个表其实对于开发来说没有什么难度，难度在于业务经验，预知可能的变化点，提前做好规划。一个好的产品经理如果能及早的想到这些点，那么开发就可以少走很多的弯路。如果产品经理帮不了忙，那么只有靠自己，多和各个实际业务打打交道。

流程记录，步骤记录，时间点记录，建议用不要用横向设计。

我的数据库设计实践（一）

标签：退款   业务   展开   代码   cell   解法   str   设计   png   

热心网友 时间：2022-05-01 21:12

电子信息工程毕业实践报告

实践”是件听起来轻松，实则却“蕴味”十足，甚至意义深刻的事。实践能使你已成的“惯性”和被特定环境“保护”的生活重新增添一些色彩，确切地说，这是一个“过程”，过程中夹杂着忙与快乐。
“万事开头难”这话一点儿也不假，虽然我参与实践的时间不长，但求职之路的艰辛和求到职之后的茫然让我感叹市场竞争的激烈，在超市工作的生活实践让我感悟到了生活的艰辛。就目前的超市数据库的管理，我想谈谈其关联规则。目前，在需要处理大数据量的科研领域中，数据挖掘受到越来越多的关注。我们可以利用数据挖掘技术从海量数据中发现有用信息，帮助商家了解客户以往的需求趋势，并预测未来，从而给商家带来巨大的利润。在数据挖掘领域，采用关联规则在大型事务数据库中进行数据挖掘是一个重要的研究内容。关联规则是美国IBM Almaden Research Center的Rabesh Agrawal等人于1993年首先提出的KDD研究中的一个重要课题。关联规则挖掘的一般对象是事务数据库，这种数据库的主要应用在零售业，比如超级市场的销售管理。关联规则就是发现事务数据库中不同商品（项）（Item,指事务中的内容，比如，面包、牛奶等都是项目）之间是否存在某种关联关系。通过这些规则找出顾客购买行为模式，如购买了某一商品对购买其他商品的影响。发现这样的规则可以应用于商品货架设计、货存安排以及根据购买模式对用户进行分类。
2关联规则描述
目前关联规则挖掘主要考虑支持度和置信度两个阈值。设X是项集，T是数据库DB中的任意一个记录。X的支持度是指支持X的记录数与全体记录数的比，Support(X)=||/|DB|。蕴涵关系X==>Y在数据库DB中的置信度是指同时支持X和Y的记录数与支持X的记录数之比，即：Confidence（X==>Y）=||/|| 支持度可理解为在DB中随机抽取一个记录，该记录同时支持X和Y的概率。置信度可理解为在支持X的记录全体中随机取一个记录，该记录支持Y的概率。
3发现关联规则的操作步骤
目前，由于条码技术的发展，顾客在超市中购买商品的信息可以很方便的被存放在数据库中，针对数据库中大量的数据，我们如何发现它们之间存在的关联是本文主要讨论的问题。关联规则的挖掘问题就是在超市事务数据库DB中找出具有用户给定的最小支持度和最小置信度的关联规则。关联规则的挖掘对市场调节和争取顾客方面的应用是极有价值的。因此，有必要采用快速算法从超市事务数据库中挖掘关联规则。由超市事务数据库发现关联规则挖掘可以分以下两步完成：
1）找出超市事务数据库DB中所有大于等于用户指定最小支持度的项目集，具有最小支持度的项目集称为频繁项集。
2）利用频繁项集生成所期望的关联规则，即这些规则必须满足最小支持度min_supp和最小置信度min_conf。
事实上，第一步的任务是迅速高效地找出超市事务数据库DB中全部频繁项集，数据挖掘所面临的最大的挑战是计算效率问题，解决这一问题的途径是产生高效的数据挖掘算法，但从超市事务数据库中产生频繁项集即费时又占用空间，所以说第一步是关联规则挖掘的核心问题，是衡量关联规则挖掘算法的标准。当找到所有的频繁项集后，相应的关联规则将很容易生成，目前大多数的关联规则挖掘算法研究是针对第一步而提出的，本文重点讨论第一个问题。
4由超市事务数据库发现关联规则的总体设计
在现有的不少关联规则发现算法中，最著名的仍然是R.Agrawal本人在他们自己的AIS算法基础上于1994年提出的Apriori算法，Apriori算法的基本思想是：利用“频繁项集的所有非空子集都必须也是频繁的”这一定理对事务数据库进行多遍扫描。
众所周知，对数据库的扫描伴随繁重的磁盘I/O任务，Apriori算法中，扫描次数较多，这样就大大*了挖掘算法的速度。因此，在实际的应用中，减少对事务数据库的扫描次数，有效地减少数据的吞吐，将会有效提高算法的效率。为了高效率的由超市事务数据库中发现关联规则，本系统在Apriori算法的基础上采用基于划分的算法。该算法只对事务数据库DB扫描两次，大大减少了I/O操作，从而提高了算法的效率。
通过划分方法进行数据挖掘的过程如下图所示：
本系统的总体设计包含三部分：
（1） 在服务器端第一次扫描超市事务数据库中的表，按照超市事务数据库中不同项集的数量，以及兼顾客户端计算机硬件配置，对其进行数据分块，分块的大小选择要使得每个分块可以被放入主存。
（2） 在各个客户端计算机上，利用并行技术分别访问服务器上的数据分块，求出各数据分块所对应的局部频繁项集，并将所求局部频繁项集存入服务器的一个指定表中。
（3） 在服务器端，汇总各个分块数据生成的局部频繁项集，第二次扫描超市事务数据库中的总表，最终生成全局频繁项集。
系统的总体设计可以如下图2 应用程序总体设计所示。
一旦由超市事务数据库DB中的事务找出频繁项集，由它们产生强关联规则是直截了当的。所谓的强关联规则是指满足最小支持度和最小置信度的规则。
5结论
随着计算机硬件的降价，利用并行处理的思想，划分的数据块分给多个处理机并行计算各数据块的局部频繁项集，然后各分块所求的局部频繁项集汇总到服务器上，再次扫描数据库最终求出全局频繁项集。这种将关联规则挖掘算法与并行处理相结合的方式能更大的提高算法的效率。今后，如何能够更有效的提高关联规则算法执行的效率，怎样设计更有效、更实用的算法，是我们进一步需要思考的问题。
以上是我在社会实践中悟到的经验以及思考的课题。
追问有数据库吗...