SQLServerXXXXBI数据挖掘案例.docx
- 文档编号:14319077
- 上传时间:2023-06-22
- 格式:DOCX
- 页数:34
- 大小:272.84KB
SQLServerXXXXBI数据挖掘案例.docx
《SQLServerXXXXBI数据挖掘案例.docx》由会员分享,可在线阅读,更多相关《SQLServerXXXXBI数据挖掘案例.docx(34页珍藏版)》请在冰点文库上搜索。
SQLServerXXXXBI数据挖掘案例
SQL_Server_XXXX_BI数据挖掘案例
向顾客提供大量产品的国内和国际零售商都面临着共同的挑战:
确保其众多的商店具有适当的产品库存级不。
确定适当的库存级不咨询题需要在以下两种竞争成本间进行权衡。
1.
高级不库存的储备成本。
这些成本指零售商为安全的实际空间、额外的供应商购买以及在所有零售商店中与坚持高级不产品库存有关的分配所支付的代价。
2.
丧失销售的成本。
如果顾客进入商店,想要购买某种特定的产品,但由于该产品已脱销而无法供货,就形成了这些成本。
面对这种进退两难的情形,零售商通常有两种选择。
零售商能够保持高库存,而承担高库存成本;或者保持低库存成本,而承担在顾客需要购买时由于没有产品而丧失销售机会的风险。
权衡这些竞争成本的最佳方式是构建推测模型来确保每个连锁商店都具有适当的库存级不。
过去零售商依靠供应链软件、内部分析软件甚至直觉来推测库存需求。
随着竞争压力的一天天增大,专门多零售商(从要紧财务主管到库存治理员)都开始致力于找到一些更准确的方法来推测其连锁商店应保有的库存。
推测分析是一种解决方案。
它能够准确推测哪些商店位置应该保持哪些产品。
本文介绍如何使用Microsoft(R)SQLServer(TM)2005中的AnalysisServices以及SQLServer数据仓库,采纳数据挖掘技术为产品储备决策提供准确及时的信息。
此处介绍的方法用于在商店/产品级不上提供脱销推测。
关于某种特定产品,SQLServer2005AnalysisServices用于构建数据挖掘模型,该模型为每个连锁商店提供脱销推测。
此方法使零售商能够有效地权衡与储备产品库存有关的竞争成本。
关于ProjectREAL
ProjectREAL致力于找出创建基于SQLServer2005的商业智能(BI)应用程序的最佳方法。
在ProjectREAL中,我们通过创建基于真实客户方案的引用实现来进行。
这意味着将客户数据引入内部,并使用这些数据来解决各个客户在部署过程中将会面临的相同咨询题。
这些咨询题包括:
•
架构设计-关系架构和AnalysisServices中使用的架构。
•
数据提取、转换和加载(ETL)过程的实现。
•
客户前端系统的设计与部署,以便进行报告和交互式分析。
•
生产系统的规模大小调整。
•
对运行中的系统的治理与爱护,包括对数据的增量式更新。
通过分析真实的部署情形,我们能够全面了解如何使用SQLServerBI工具实现BI系统。
我们的目标是致力于解决可能期望分析大型数据集的公司在事实上际部署中遇到的所有咨询题。
数据仓库讲明
在ProjectREAL中,构建的数据仓库用于为在全国拥有数百家商店的零售商的数百万种产品汇总销售数据。
用于构建脱销推测模型的有关数据集有:
•
以商店级不、产品(项)级不、天级不合计的销售量事实数据。
具体地讲,是为差不多销售的每种产品、零售商的每个连锁商店储备每日销售量。
•
以商店级不、产品(项)级不、天级不合计的库存事实数据。
具体地讲,这是每种产品、每天、零售商的每个连锁商店的产品在库存中的天数。
•
由产品名、讲明、零售价和产品类不层次结构组成的产品(项)信息。
•
由商店讲明、商店分类(例如,指定是大型商店依旧小型商店的指标)、商店分区、商店区域、商店地区、都市、邮政编码、省/自治区、货架空间线性尺寸和其他商店信息组成的商店信息。
•
日期信息(日期维度),它将事实数据级日期标识符映射到相应的财务周、财务月、财务季、财务年和其他日期信息。
具有一个清晰、最新的数据仓库能够为所有商业智能应用程序利用此有用的信息资产提供可靠的基础。
在此专门的构建脱销模型的任务中,数据仓库简化了构建数据集模型的过程。
数据挖掘方法和构建数据集模型
按照在ProjectREAL中将数据挖掘技术应用于不同零售销售量推测和构建脱销模型咨询题所获得的体会,我们提出了通过两个时期来构建模型,这一过程提升了准确推测的可能性。
构建模型过程的第I时期是基于合计销售量模式对零售商的连锁商店进行分类。
构建了质量商店分类模型后,在构造模型过程的第II时期,这些分类用于使商店/产品级不上的脱销推测更加准确。
通过使用SQLServer2005AnalysisServices中的数据挖掘技术能够高效并有效解决这两个时期。
本部分提供了整个脱销推测过程的详细信息,该过程从用于构建数据集模型的过程讲明开始。
然后对评估使用SQLServer2005AnalysisServices构建的数据挖掘模型的方法进行了讨论。
构建脱销推测模型的过程
构建脱销模型分为两个时期。
第I时期是将具有相似合计销售量模式的连锁商店进行分类。
对具有相似合计销售量模式的商店进行分类的过程称为“商店分类”。
通过使用SQLServer2005AnalysisServices中附带的Microsoft分类算法完成商店分类,从而将具有相似合计销售量模式的商店进行分类。
将Microsoft分类算法应用于由合计销售量模式组成的数据集时,该Microsoft分类算法尝试通过以下方式对商店进行分类:
属于同一分类的商店比属于不同分类的商店更加相似。
构建数据集模型基于从数据仓库派生的合计销售量数据。
因此,用于对商店进行分类的“相似性”测度是按照此合计销售量数据运算而来的。
然后,我们使用第I时期生成的分类模型在第II时期构建更准确的脱销推测模型。
这承诺推测算法(例如Microsoft决策树或Microsoft神经网络)使用分类结果来提升推测准确性。
实质上,要优化特定商店s的特定产品p的推测,在确定商店s的p是否脱销时,SQLServer2005中的推测算法可能使用相似商店s中同一产品p的销售量事实数据,如此能够提升推测的准确性。
为产品p构建脱销推测模型的高级步骤
使用SQLServer2005AnalysisServices构建最佳推测模型的两时期过程由以下高级步骤组成。
将在以下的部分详细介绍这些步骤。
1.
使用数据仓库产品信息(维度)部分中的产品层次结构确定产品p的产品类不c(p)。
我们假定连锁商店中同一类不的产品具有相似的合计销售量模式。
因此,产品结构层次用于标识特定产品p的相似产品集c(p)。
另外,产品分类方法可用于基于连锁商店的销售量通过对产品进行分类来确定与p产品相似的数据驱动分类。
2.
为商店分类预备构建数据集Dcluster模型来捕捉类不为c(p)(在步骤1中已确定)的商店级属性和销售量。
3.
将Microsoft分类算法应用于数据集Dcluster,以便获得k个分类(组)的商店,这些商店在类不c(p)的商店级属性和销售量上相似。
4.
关于在步骤3中获得的每个分类,l=1,…,k:
i
使S(l)成为商店集,该商店集属于分类l。
注意,关于类不c(p),这些商店具有相似的类不级合计销售量。
ii
创建数据集DOOS(p,S(l)),它由S(l)中每个商店s的历史和当前每周销售量合计以及每周销售量合计变化组成。
另外,还包括布尔标志,用于指明产品p在以后一周和以后两周是否脱销。
iii
将SQLServer2005AnalysisServices中的构建推测模型算法(例如Microsoft决策树或Microsoft神经网络)应用于数据集DOOS(p,S(l))。
将历史和当前每周销售量合计作为输入属性,将一周和两周脱销布尔标志作为输出或仅推测属性。
这将使SQLServer2005AnalysisServices生成如此的模型:
该模型将其输入用作历史和当前每周销售量以及每周销售量变化,然后进行布尔标志的推测,该标记指明产品p将在以后一周和以后两周内是否脱销。
在接下来的两部分中将更加详细地介绍数据预备和构建模型步骤。
使用Barnes&Noble提供的可信企业数据,ProjectREAL合作者能够发觉创建BI应用程序的最佳方法,这些BI应用程序基于MicrosoftSQLServer2005。
此完整系统通过以一种全面的方式分析大型数据集从而解决所有客户操作难题。
注意以下五个产品(书),这五个产品属于同一类不(ChapterBooks)。
•
CaptainUnderpants&TheInvasionoftheIncrediblyNaughtyCafeteriaLadiesfromOuterSpace(CaptainUnderpantsSeries)
•
JunieBJonesIsaGraduationGirl
•
Dinosaurs:
ANonfictionCompaniontoDinosaursBeforeDark(MagicTreeHouseResearchGuideSeries#1)
•
CityintheClouds(SecretsofDroonSeries#4)
•
TwistersandOtherTerribleStorms(MagicTreeHouseResearchGuideSeries)
第I时期:
商店分类
注意,商店分类的目标是获得具有相似销售量模式的商店组,着重于产品p所属的类不c(p)中产品的销售量。
第I时期第一构建将用于商店分类的数据集。
为了将对活动零售销售量和库存数据仓库的运算阻碍降低到最低程度,我们建议您创建独立的SQL数据库来储备数据集,这些数据集用于使用SQLServer2005AnalysisServices构建模型。
商店分类数据集构建
用于商店分类的数据集由2004年1月到2004年12月这段时刻内的商店级合计销售量组成。
该数据集由具有关键字StoreID的单个表组成。
StoreID是整数,用于唯独标识每个连锁商店。
由于商店分类任务的目标是按照合计销售量模式的相似性将商店进行分类,因此我们与零售商合作以便标识对此练习有用的一组合计销售量属性。
用于构建模型的这组属性的类型和信息内容通常会阻碍生成的输出模型。
标识用于构建模型的一组属性时,我们发觉与对差不多业务过程有深刻明白得的利益关系人合作会有好处。
另外,按照在直截了当零售过程中差不多完成的工作,我们能够建议可能有用的属性。
关于每个商店,基于数据仓库中的事实数据对属性进行合计。
这些销售级合计如下。
有关所有用于商店分类咨询题的商店级属性的详细讲明,请参见附录A。
•
产品(书)p所属的类不[在往常的部分中称为c(p)]的特定类不的派生属性。
它们是:
•
CategoryAverageWeeklyModeled:
特定商店中预期每周要出售的某类不的书的估量数量。
•
CategoryAverageWeeklyOnHand:
特定商店中某类不的每周可售(库存)平均值。
•
CategoryAverageWeeklyOnOrder:
特定商店中某类不的每周预定书平均数。
•
CategoryFractionHolidaySales:
特定商店中来自类不为c(p)的书的节假日总销售量部分。
注意,节假日销售量是在2004年11月15日到2004年12月末之间所销售的书。
•
CategoryFractionSales:
特定商店中来自类不为c(p)的书的非节假日总销售量部分。
注意,非节假日销售量是在2004年1月1日到2004年11月14日之间所销售的书。
•
CategoryHolidayDiscountAmount:
特定的商店的节假日期间,类不为c(p)的折扣书总数。
•
CategoryHolidayMarkdownAmount:
特定的商店的节假日期间,类不为c(p)的减价书总数。
•
CategoryHolidayMemberDiscountAmount:
特定的商店的节假日期间,类不为c(p)的书的总会员折扣。
•
CategoryHolidaySalesAmount:
特定的商店的节假日期间,类不为c(p)的书的总销售量。
•
CategoryHolidaySalesQuantity:
特定的商店的节假日期间,类不为c(p)的书的总数量。
•
CategoryTotalDiscountAmount:
特定的商店的非节假日期间,类不为c(p)的折扣书总数。
•
CategoryTotalMarkdownAmount:
特定的商店的非节假日期间,类不为c(p)的减价书总数。
•
CategoryTotalMemberDiscountAmount:
特定的商店的非节假日期间,类不为c(p)的书的总会员折扣。
•
CategoryTotalSalesAmount:
特定的商店的非节假日期间,类不为c(p)的书的总销售量。
•
CategoryTotalSalesQuantity:
特定的商店的非节假日期间,类不为c(p)的书的总销售量。
•
关于以下每个类不,均运算属于该类不的节假日总销售量部分(例如附录A中的CatFracHolidaySales)。
另外,还将运算属于该类不的非节假日总销售量部分(例如附录A中的CatFracSales属性)。
按照零售商的反馈,考虑用于捕捉高级整个销售量的类不为:
BeginningReader、BGBestseller、BGCKBKSUnder15、BGReference、BlankBooks、BoardBlockTouch、ChapterBooks、ChristianInsp、Cooking、CurrentAffairs、FamilyChildCare、Fantasy、Fiction、FictionPBYoungReaders、HistBiog、Humor、JuvActivity、JuvChristmas、JuvSeriesHC、JuvSeriesPB、JuvWorkBooks、Literature、Magazines、Management、MangaJapanese、Mystery、NewAge、Newspapers、PictStyBks、PopRock、Romance、ScienceFiction、SelfImprovement、SingleCards、Spinner、TechnoThrillerEspionage和TeenFiction。
•
还包括以下商店级合计。
•
TotalHolidaySales:
节假日期间,商店所有书的总销售量。
•
TotalSales:
非节假日期间,商店所有书的总销售量。
•
TotalWeeklyAverageModeled:
商店所售书的总量的平均每周估量值。
•
TotalWeeklyAverageOnHand:
特定商店可售书的每周平均总量。
•
TotalWeeklyAverageOnOrder:
特定商店预定书的每周平均总量。
•
以下商店属性也包括在商店分类数据集中:
City、LinearFt(商店中货架空间的直线英尺数)、(商店的)SquareFeet和State。
通过SQL运算这些商店级属性和合计值,并储备于单独的、不规范的表中。
注意,此表仅用于通过SQLServer2005中的数据挖掘组件构建模型。
如果某个组织想更新运行中的商店分类模型,我们建议您自动化此不规范的表的构建来预备数据。
另外,能够定义视图(而不是表),从而从规范的事实数据和维度数据创建不规范的结果集。
该表的每行都由唯独的整数StoreID进行索引,同时对往常列表中的每个属性/合计都对应地包含一列,这些属性/合计在附录A中有详细介绍。
关于商店分类练习和构建脱销模型,考虑至少开业一年的商店。
关于此特定零售商,这将为794个商店。
因此,用于商店分类的单个SQLServer2005关系表由846行和100列(1列为StoreID,其他99列用于储备在往常的属性值列表中定义的属性值)组成。
商店分类挖掘模型构建
构建源关系表后,我们通过MicrosoftVisualStudio(R)2005来连续构建商店分类挖掘模型。
第一,在VisualStudio2005中创建AnalysisServices项目,然后创建连接到包含商店分类数据集的SQLServer实例的DataSource对象。
还必须创建数据源视图。
此数据源视图仅选择包含商店级属性和合计属性的单个表。
参见图1。
添加数据源视图后,将为商店分类练习创建新的挖掘结构和挖掘模型。
挖掘结构定义将用于构建商店分类模型的列结构。
除了CatFractionSales和CatTotalSalesQty属性以外,选择其他所有属性作为Input属性。
选择CatFractionSales和CatTotalSalesQty属性作为Predict(Input和Predictable)属性。
参见图2。
与Microsoft分类算法有关联的CLUSTER_COUNT参数指定最大分类数,以便在源数据中搜索。
在默认情形下,值为10。
为了生成能够充分捕捉商店属性和合计销售量/库存值中的有关关系的不同分类,按照体会和对分类模型(发觉有5个分类)质量的估量,CLUSTER_COUNT的值被更换为5。
通常,分析软件需要更换CLUSTER_COUNT参数以获得所需结果。
在此应用程序中,我们发觉当CLUSTER_COUNT=5时,找到不同的商店分类(分类基于合计销售中的相似性)。
另外,证据表明使用MINIMUM_SUPPORT=50时将在此应用程序中获得更高质量的分类模型。
这表示Microsoft分类算法仅标识其中具有50或更多事例(此应用程序中为商店)的分类。
同样,分析软件也要更换MINIMUM_SUPPORT以获得所需的分类质量。
参见图3。
为Microsoft分类算法设置参数后,将处理挖掘结构,从而在SQLServer2005AnalysisServices中创建和填充挖掘模型对象。
商店分类模型评估
构建商店分类模型后,使用MicrosoftSQLServer2005AnalysisServerClusterBrowser对这些模型进行评估以确定类不销售量模式是否确实区分了这些分类。
有关SQLServer2005AnalysisServices找到的商店分类的摘要,请参见图4。
趋向于由TotalSales、CategorySalesQuantity、CategoryWeeklySales、CategoryWeeklyOn-Hand和On-Order值区不商店分类。
图4为每个分类显示了属于特定分类的商店的示例都市/省值(图4中左边的列)和每个分类的区分因子(图4中右边的列)。
注意,能够通过使用SQLServer2005AnalysisServicesClusterModelViewer(参见图5)中的Discrimination(区分)选项卡来确定区分特点(属性/值)对。
第II时期:
构建脱销推测模型
既然差不多构建了商店分类模型(这些模型将具有相似类不销售量模式的商店进行分类),接下来我们将着重于推测特定的书在以后一周和以后两周是否脱销的咨询题。
在构建挖掘模型进行脱销推测之前,我们先为关注的每个产品(书)构建模型数据集。
构建脱销推测模型数据集
用于脱销推测模型任务的数据集需要考虑所有零售连锁商店的特定书的每周销售数据。
按照体会和可用的历史数据量,我们开发了“滑动窗口”策略来创建用于构建推测模型的数据集。
当数据是时刻数据(例如,对以后进行推测时)同时可推测数量类型为离散类型(例如布尔脱销指标或销售箱)时,滑动窗口策略通常为良好的数据预备策略。
如果具有足够的时刻数据,同时可推测数量原本就为数字数量,时刻系列构建模型可能为首选策略。
通过研究数据并着重于咨询题的环境,我们进行了以下观看。
在每周内,特定书以及特定商店的历史销售和库存数据生成了52条记录(一年的所有数据)。
通常,单个商店和单个产品专门少发生脱销事件。
为了获得准确的推测模型,练习数据需要包含足够数量的脱销事件和库存事件来标识区分这两者的趋势。
通过考虑整个连锁商店的特定产品p,以下数据预备策略用于获得足够数量的脱销事件和库存事件。
我们包括商店分类标签(从商店分类模型派生而来),以便使构建推测模型算法能够标识不同商店分类之间可能不同的脱销行为的趋势。
特定产品(书)p的脱销推测模型数据集构建
关于每个零售连锁商店s:
关于2004年1月1日到2004年12月31日之间的每周:
a
生成唯独的商店/周标识符。
这将是构建脱销模型数据集的关键。
b
商店s所属的商店分类标签,已在第I时期:
“商店分类”所述的商店分类模型确定。
c
当前周商店s的产品(书)p的销售量(CurrentWeekSales)。
d
当前周商店s的产品(书)p的可售量(CurrentWeekOnHand)。
e
当前周商店s的产品(书)p的预定量(CurrentWeekOnOrder)。
f
当前周的后一周商店s的产品(书)p的销售量(OneWeekAheadSales)。
g
当前周的后两周商店s的产品(书)p的销售量(TwoWeeksAheadSales)。
h
当前周的前一周商店s的产品(书)p的销售量(OneWeekBackSales)。
i
当前周的前两周商店s的产品(书)p的销售量(TwoWeeksBackSales)。
j
当前周的前三周商店s的产品(书)p的销售量(ThreeWeeksBackSales)。
k
当前周的前四周商店s的产品(书)p的销售量(FourWeeksBackSales)。
l
当前周的前五周商店s的产品(书)p的销售量(FiveWeeksBackSales)。
m
当前周的后一周商店s的产品(书)p的可售量(OneWeekAheadOnHand)。
n
当前周的后两周商店s的产品(书)p的可售量(TwoWeekAheadOnHand)。
o
当前周的前一周商店s的产品(书)p的可售量(OneWeekBackOnHand)。
p
当前周的前两周商店s的产品(书)p的可售量(TwoWeeksBackOnHand)。
q
当前周的前三周商店s的产品(书)p的可售量(ThreeWeeksBackOnHand)。
r
当前周的前四周商店s的产品(书)p的可售量(FourWee
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- SQLServerXXXXBI 数据 挖掘 案例