数据仓库的实现策略
2024-05-20 04:39
1. 数据仓库的实现策略
分类: 电脑/网络 >> 程序设计 >> 其他编程语言 问题描述: 对"自顶向下","自底向上"和"这两种策略的联合使用"的概念的介绍 解析: 数据仓库的开发策略主要有自顶向下、自底向上和这两种策略的联合使用。自顶向下策略在实际应用中比较困难，因为数据仓库的功能是一种决策支持功能。这种功能在企业战略的应用范围中常常是很难确定的，因为数据仓库的应用机会往往超出企业当前的实际业务范围，而且在开发前就确定目标，会在实现预定目标后就不再追求新的应用，是数据仓库丧失更有战略意义的应用。由于该策略在开发前就可以给出数据仓库的实现范围，能够清楚地向决策者和企业描述系统的收益情况和实现目标，因此是一种有效的数据仓库开发策略。该方法使用时需要开发人员具有丰富的自顶向下开发系统的经验，企业决策层和管理人员完全知道数据仓库的预定目标并且了解数据仓库能够在那些决策中发挥作用。 自底向上策略一般从某个数据仓库原型开始，选择一些特定的为企业管理人员所熟知的管理问题作为数据仓库开发的对象，在此基础上进行数据仓库的开发。因此，该策略常常用于一个数据集市、一个经理系统或一个部门的数据仓库开发。该策略的优点在于企业能够以较小的投入，获得较高的数据仓库应用收益。在开发过程中，人员投入较少，也容易获得成效。当然，如果某个项目的开发失败可能造成企业整个数据仓库系统开发的延迟。该策略一般用于企业洗碗对数据仓库的技术进行评价，以确定该技术的应用方式、地点和时间，或希望了解实现和运行数据仓库所需要的各种费用，或在数据仓库的应用目标并不是很明确时，数据仓库对决策过程影响不是很明确时使用。 在自顶向下的开发策略中可以采用结构化或面向对象的方法，按照数据仓库的规划、需求确定、系统分析、系统设计、系统集成、系统测试和系统试运行的阶段完成数据仓库的开发。而在自底向上的开发中，则可以采用螺旋式的原型开发方法，使用户可以根据新的需求对试运行的系统进行修改。螺旋式的原型开发方法要求在较短的时间内快速的生成可以不断增加功能的数据仓库系统，这种开发方法主要适合于这样一些场合：在企业的市场动向和需求无法预测，市场的时机是实现产品的重要组成部分，不断地改进对与企业的市场调节是必需的；持久的竞争优势来自连续不断地改进，系统地改进是基于用户在使用中的不断发现。 自顶向下和自底向上策略的联合使用具有两种策略的优点，既能快速的完成数据仓库的开发与应用，还可建立具有长远价值的数据仓库方案。但在实践中往往难以操作，通常需要能够建立、应用和维护企业模型、数据模型和技术结构的、具有丰富经验的开发人员，能够熟练的从具体（如业务系统中的元数据）转移到抽象（只基于业务性质而不是基于实现系统技术的逻辑模型）；企业需要拥有由最终用户和信息系统人员组成的有经验的开发小组，能够清楚地指出数据仓库在企业战略决策支持中的应用。
2. 浅析数据仓库的构建方法
浅析数据仓库的构建方法
随着不同的管理信息系统（MIS）在企业不同部门的大规模应用及企业对数据管理不断提出新的要求，不仅要求能实现传统的联机事务处理，而且越来越多的要求是各种应用系统能够在企业不断积累的以及从企业外部获取的丰富信息资源的基础上，把这些分散的、不一致的、凌乱的信息资源加以利用，即更多地参与数据分析和决策支持，由此出现了一种用于数据分析处理和决策支持的数据存储和组织技术，即数据仓库技术。
1、什么是数据仓库
数据仓库是面向主题的、集成的、具有时间特征的、稳定的数据集合，用以支持经营管理中的决策制定过程。数据仓库提供用户用于决策支持的当前和历史数据，这些数据在传统的操作型数据库中很难或不能得到。
面向主题是指数据仓库中的数据是按照一定的主题域进行组织。主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。集成的是指数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
数据仓库的体系结构分数据源、数据转换、数据仓库、数据集市和用户几部分。数据源，包括企业内部的业务数据、遗留数据、其它业务系统数据及相关WEB数据等；数据转换是数据仓库构建的重要环节，主要是对各种复杂的数据源进行抽取、转换、装载及其他处理，同时要实现数据质量跟踪监控以及元数据抽取与创建等工作；数据仓库主要实现对各种数据的组织、存储及管理等；数据集市是为不同业务而单独设计的数据仓库系统，即开发者为企业内部的不同用户群定制特殊的数据仓库子系统。用户部分，即具体面向使用者的应用部分，主要是指数据仓库存取与检索为用户提供了访问数据仓库或数据集市的功能，其中分析与报告为用户使用数据仓库提供了一组工具，用于帮助用户对数据仓库或数据集市进行联机分析或数据挖掘等。
2、数据仓库构建方法
2.1 普通数据仓库构建方法。对于普通数据仓库的构建，企业在对整个系统的建设综合各种因素的基础上，将整个项目的实施分阶段、分步骤实施，可以在每一阶段建设的基础上分阶段纳入不同的业务系统，逐步建立起一个综合的、专题较为完善的、适合部门、子单位使用的完整的数据仓库系统，从而才能使投资尽快获得收益。
在数据仓库的构建过程中，利用模糊数学可实现数据仓库内数据的语义表示，丰富数据加工的手段，提高分析处理的能力。数据仓库的构建，一般采取先构建数据集市，最后将各个数据集市整合在一起形成数据仓库的渐进模式；通过概念层、逻辑层、物理层建模，确定相关主题域的数据集市并对其进行联机分析处理。构建数据仓库模型一般采用以下几种：
2.1.1 星型模型：星型模型是最常用的数据仓库设计结构的实现模式。使数据仓库形成了一个集成系统，为用户提供分析服务对象。该模型的核心是事实表，围绕事实表的是维度表。通过事实表将各种不同的维度表连接起来，各个维度表都连接到中央事实表。[page] 2.1.2 星系模型（也称雪花模型）：雪花模型对星型模型的维度表进一步标准化，对星型模型中的维度表进行了规范化处理。同时也是对星型模型的扩展，每一个维度都可以向外连接到多个详细类别表。在实际应用中，用户的需求多种多样，数据来源可能为多个事实表，故可采用多个事实表共存，之间通过公用的维表相关联的星系模型，也称为事实星座。
2.1.3 原子级数据模型和汇总级数据模型并存：坚持原子级数据模型和汇总级数据模型并存，而且要尽可能地细化原子级数据。
2.1.4 设立代理键：代理键是维表中一些没有业务含义的字段，只是一个由数据仓库加载程序时建立的数字。
2.2 空间数据仓库构建方法。随着GIS（地理信息系统）在各行业的广泛应用，最初面向事务处理为主的空间数据库信息系统已不能满足需要，信息系统开始从管理转向决策处理，空间数据仓库就是为满足这种新的需求而提出的空间信息集成系统。尤其是地理信息决策支持系统中，空间数据仓库系统显得尤为重要。
空间数据仓库具有普通数据仓库的普遍特征，但其本身有一些特殊性。并且空间数据仓也并不是空间数据库的简单集合。与空间数据库比，空间数据仓除支持数据库外，还支持数据文件、文本文件、应用程序等众多数据源；另外空间数据仓库中的数据有时间数据、空间数据、属性数据及异构数据等多种数据；其次空间数据仓库中还包括了数据处理规则、算法等；再次空间数据仓库的数据是对原始数据进行加工、处理、集成等转换，是对数据的增值和统一；空间数据库还引入了时间纵的概念，它是以时间为基准来管理数据，可以截取不同时间尺度上的信息，从瞬态到区段时间直到全体，空间数据仓库是依赖于时间维的数据结构，它可以根据不同的需要划分不同的时间粒度等级，以便进行各种复杂的趋势分析。当然，不言而喻，它还包含了空间维的方位数据。正因为空间数据仓库与普通数据仓库的不同，并且它以空间数据仓库完全不是相同的概念，一般空间数据仓库以如下体系结构分为四大功能模块，分别是源数据、数据变换工具、空间数据仓库、客户端分析工具。源数据它不仅指那些常见的空间数据库，还包括文件、网页、知识库、遗留系统等各种数据源。数据变换工具与具有普通数据仓库数据变换相同的提取转换功能，但它还包括了特有的空间变换等。空间数据仓库以立体、多维的方式来组织和显示数据。但最基本的空间维和时间维是其反映客观世界动态变化的基础，空间数据仓库技术最关键要点也就是时间维和空间维数据组织方式。目前空间数据仓库已成为国、内外GIS（地理信息系统）研究的热点并取得了较大进展。要把空间信息融合进企业现有的数据仓库中，在原有系统不作较大改动的前提下，一般采用三种模式构建企业空间数据仓库：（1）把空间信息作为多维模型中的空间维引入；（2）把空间信息作为研究主题引入；（3）在维和度量中都包含空间信息。因此，计算并存储所有空间度量是不现实的。一般使用空间索引树（如R-tree）在最细空间粒度上构建分组层次，作为空间维的分层，每个空间维需要建立一棵空间索引树。
3、结束语
总之，数据仓库构建是数据仓库技术的关键，数据仓库技术是一项基于数据管理和利用的综合性技术和解决方案，尤其是现在空间数据仓库在GIS 中的广泛应用，它成为数据库市场的新一轮增长点，同时也成为下一代信息系统的重要组成部分。
3. 数据仓库的设计步骤
1)选择合适的主题（所要解决问题的领域）2)明确定义事实表3)确定和确认维4)选择事实表5)计算并存储fact表中的衍生数据段6)转换维表7)数据库数据采集8)根据需求刷新维表9)确定查询优先级和查询模式。硬件平台：数据仓库的硬盘容量通常要是操作数据库硬盘容量的2-3倍。通常大型机具有更可靠的性能和和稳定性，也容易与历史遗留的系统结合在一起；而PC服务器或UNIX服务器更加灵活，容易操作和提供动态生成查询请求进行查询的能力。选择硬件平台时要考虑的问题：是否提供并行的I/O吞吐？对多CPU的支持能力如何？数据仓库DBMS：他的存储大数据量的能力、查询的性能、和对并行处理的支持如何。网络结构：数据仓库的实施在那部分网络段上会产生大量的数据通信，需不需要对网络结构进行改进。
4. 数据仓库的实现方式
数据仓库是一个过程而不是一个项目。数据仓库系统是一个信息提供平台，他从业务处理系统获得数据，主要以星型模型和雪花模型进行数据组织，并为用户提供各种手段从数据中获取信息和知识。从功能结构划分，数据仓库系统至少应该包含数据获取（Data Acquisition）、数据存储（Data Storage）、数据访问（Data Access）三个关键部分。企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。因此，从产业界的角度看，数据仓库建设是一个工程，是一个过程。
5. 如何进行仓库规划
仓库平面合理布置，是根据仓库场地条件、仓库业务性质和规模、物资储存要求以及技术设备的性能和使用特点等因素，对仓库各组成部分，如库房、货场、辅助建筑物、库内道路、附属固定设备等，在规定的范围内进行平面的合理安排和布置。仓库总平面布置的程序如下: 仓库总平面布置的准备工作 仓库总平面布置的合理与否很大程度上取决于有关资料的齐备、准确及可靠程度。总平面布置是一个反复试验的过程，即布置、修改、再布置、再修改，反复多次，直到求得最满意的布置方案为止。在布置时一般借助于一些辅助工具，如作业流程图、仓库平面图、样板图等，在纸面上加以设计。所以在总平面布置前还需要准备好必要的辅助工具。 找出和布置关键性作业位置 在仓库总平面布置中，铁路专用线的位置往往受外部条件的限制，而且在很大程度上决定着仓库总平面布置的走向，所以应首先确定专用线的位置。库房、货场的位置可根据上述要求依次确定。 总平面布置所依据的主要资料有：储存物的品种、规格、数量，建设地区的铁路和公路分布情况，地形条件，水、电供应条件，当地气象资料，采取的装卸搬运手段，消防及安全要求协作条件等。 对工作面积进行大致的布置 根据建设地点的现有地形，对库房、货场、主要通道、装卸场地以及辅助车间、办公室、生活福利设施的相应位置及占用面积进行大致的初步设计。 设计次要通道 次要通道与主要通道相交并形成一个完整的运输网，通道的设置与宽度应视物资运输的需要和安全要求而定。 单体设计 根据储存物资的保管要求、仓库业务、作业流程和仓库性质，并结合当地气象及环境条件，具体确定库房的建筑类型和方位，以及库房内设备的类型和位置。 辅助和辅助装置的设置 对排水系统、消防系统和水、电供应线路及辅助设施等进行设计。至此，仓库总平面布置工作初步完成。最后还应对照总平面布置的要求进行检查，并到建设现场核实布置情况
6. 如何建立数据仓库架构
如何建立数据仓库架构
每一个数据仓库有一个架构。这架构要么是即时的或计划过的；或隐式的或形成文件的。不幸的是，许多数据仓库开发时并没有一个明确的架构，这极大的限制了它的灵活性。在没有架构的情况下，主题区域就无法契合在一起，它们之间的连接变得无目的，并且使整个数据仓库的管理和变更都难于进行。此外，虽然它可能看起来不重要，数据仓库的架构已成为选择工具时的框架。
让我们把开发一个数据仓库与建造一个真正的房屋进行比较。你如何建造一幢300万美元的大厦呢？更不用说建造一间10万美元的房子了。你要有蓝图、图纸、技术规范、和在多个层次细节上显示这个房子将如何进行建造的标准。当然，针对房子的各种子系统要有不同版本的蓝图，如管道工程、电气、暖通空调系统（HVAC）、通信、和空间。针对所有的家用的设备也有相应的标准，包括插头、灯具、卫生洁具、门的尺寸等。
对于数据仓库，架构是对数据仓库的元素和服务的一种描述，用具体细节说明各种组件如何组合在一起，和随着时间的推移系统将如何地发展。就像这房子的比喻，数据仓库架构是一套文件、计划、模型、图纸和规范，针对每个关键的组件区域有独立的分区，并且足够详细到让专业技术人员可以实施它们。
这并是一个需求文件。需求文件说明架构需要做些什么。数据仓库架构也不是一个项目计划或任务清单；它说明数据仓库是什么，而不是怎么去做或为什么去做。
一个数据仓库的开发也并不容易，因为相对于房屋的5000年建筑史，我们发展数据仓库系统只有20年的时间。因此，我们的标准还不多，工具和技术正在快速发展，关于我们已经拥有数据仓库系统的档案还很少，而且数据仓库的术语还有很大的出入。
所以，虽然开发一个架构是困难的，但它也是可能的，并且又是至关重要的。首先，最主要的是，架构应该受业务的驱动。如果你的要求是每夜进行更新，这一要求就该包含在架构内，而你必须弄清实现你目标的技术需求。下面是一些业务需求的例子，和针对每种需求的综合技术考量：
●每夜更新――充足的数据准备能力
●全球可用性—平行或分布式服务器
●顾客层次分析――大型服务器
●新数据源――带有支持元数据的灵活工具
●可靠性――工作的控制功能
关键组件区域
一个完整的数据仓库架构包括数据和技术因素。架构可以被分为三个主要区域。首先，是基于业务流程的数据架构。其次是基础设施，包括硬件、网络、操作系统和电脑。最后，是技术区域，包含用户所需的决策制定的技术以及它们的支持结构。对这些区域将在下文分小节进行详述。
●数据架构
如上所述，在整体数据仓库架构中的数据架构部分是受业务流程所驱动的。例如，在一个制造环境里，数据模型可能包括订单、装运和帐单。每一个区域都依据一套不同的维度。但是在数据模型中对相交维度的定义必须相同。所以相同数据项应该有同样的结构和内容，并有一个创建和维护的单一流程。
当你完成一个数据仓库架构并呈现数据给你的用户，就要做出对工具的选择，但随着需求的设定， 选择就会变窄。例如，产品的功能开始融合，就像多维联机分析处理（M OLAP）和关系型联机分析处理（ROLAP）。如果停留在你建造的立方体，多维联机分析处理（MOLAP）便可以了。它速度快又允许灵活的查询――在立方体的范围内。它的缺点是规模（整体上和一个维度内）、设计的局限性（受立方体结构所限）、需要一个专有的数据库。关系型联机分析处理（ROLAP）是多维联机分析处理（MOLAP）的一种替代方案，它克服了多维联机分析处理（MOLAP）的这些缺点。通常，混合联机处理（HOLAP）更受欢迎，它允许一部分数据存储在维联机分析处理（MOLAP）中，另一部分数据存储在关系型联机分析处理（ROLAP）中，折衷了各自的长处。
●基础设施架构
对硬件及数据库选择的问题在于其大小、扩展性和灵活性。在大约80%的数据仓库项目中，这并不困难，大多数企业有足够的力量来应对他们的需要。
在网络、检查数据来源、数据仓库准备区、以及它们之间的任何设施方面，要确保有足够的带宽用于数据的移动。
●技术架构
技术架构被元数据目录所驱动。一切都应该受元数据所驱动。服务应该依从表格所需的参数，而不是它们的硬编码。技术架构的一个重要组件是 ETL（提取、转换和加载）流程，它涵盖了五个主要区域：
●提取－数据来自多种数据源并且种类繁多。在这个区域如果有数据的应用时必须考虑对它的压缩和加密处理。
●转换－数据转换包括代理主键的管理、整合、去标准化、清洗、转换、合并和审计。
●加载－加载通常是利用加载最优化和对整个加载周期的支持对多种目标进行加载。
●安全－管理员访问和数据加密的策略。
●元件控制-－它包括元件的定义、元件安排（时间和事件）、监控、登录、异常处理、错误处理和通知。
数据准备区需要能够从多种数据源提取数据，如MVS、ORACLE、VM和其它，所以当你选择产品时要具体。它必须将数据进行压缩和加密、转化、加载（可能对多个目标）和安全处理。此外，数据准备区的活动要能够自动化进行。不同的供应商的产品做不同的事情，所以大多数企业将需要使用多种产品。
一个监控数据仓库使用的系统对查询的采集、使用的跟踪是有价值的，而且也有助于性能的调整。性能优化包括通过“管理者”工具进行的成本估算，而且应包括即时查询的时间表。有工具能够提供查询管理服务。可使用工具来针对这些和其它相关任务，如对前台的基于服务器的查询管理和来自于多种数据源的数据。也有工具可用于报表、连通性和基础设施管理。最后，数据访问块应包括报表的服务（如发布和订阅），还应包括报表库，调度程序和分布管理员。
关于元数据
在数据仓库流程中数据的创建和管理要遵循以下的“步骤”：
●数据仓库模型
●数据源的定义
●表的定义
●数据源到目标的映射
●映射和转换信息
●物理信息（表格空间，等）
●提取数据
●转移数据
●加载统计
●业务描述
●查询请求
●数据本身
●查询统计
为显示元数据的重要性，上述的步骤列表中只有三步包括了“真正”的数据－7、8和12。其他的一切都是元数据，而且整个数据仓库流程都依赖于它。元数据目录的专业技术要素包括：
●业务规则-－包括定义、推导、相关项目、验证、和层次结构信息（版本、日期等。）
●转移/转换信息-－源/目的地的信息，以及DDL（数据类型、名称等等。）
●操作信息-－数据加载的工作时间表、依存性、通知和信息的可靠性 （比如主机的重定向和加载平衡）。
●特定工具的信息-－图形显示信息和特殊功能的支持。
●安全规则-－认证和授权。
建立架构
在开发技术架构模型前，要先起草一份架构需求的文件。然后将每一项业务需求计划包含到它的架构中。根据架构的区域对这些内容进行分组（远程访问、数据准备、数据访问工具等）。了解它如何于其它区域相适应。采集区域的定义及其内容。最后提炼和形成模型的文件。
我们认识到开发一个数据仓库架构是困难的，因此要有一个周密细致的规划。但ZACHMAN框架又超出了大多数企业对数据仓库的需要，所以建议使用一个合理的折衷方案，它由四层流程所组成：业务需求、技术架构、标准和工具。
业务需求本质上驱动着架构，所以要对业务经理、分析师、高级用户进行访谈。从你的访谈中寻找主要的业务问题，以及企业战略、发展方向、挫折、业务流程、时间、可用性、业绩预期的指标。将它们一一妥善归档。
从IT的角度来看，跟现有的数据仓库/决策支持系统（DSS）的支持人员、联机分析处理（OLTP）应用组成员、数据库管理员们（DBA）；以及网络、操作系统和桌面支持人员进行讨论。也要与架构师和专业规划人员进行探讨。你应该从这些讨论中得知他们从IT的观点考虑数据仓库的意见。从中了解是否有现存的构架文件、IT原则、标准文件、企业数据中心等。
关于数据仓库并没有太多现存的标准，但对于许多组件来说是有标准的。下面是一些需要牢记的标准：
●中间设备－－开放数据库连接（ODBC）、对象链接与嵌入（OLE）、对象链接与嵌入数据库（OLE DB）、数据通信设备（DCE）、对象请求代理（ORB）和数据库编程（JDBC）
●数据库连接－－ODBC, JDBC, OLE DB, 和其它。
●数据管理－－ANSI SQL 和文件传输协议（FTP）
●网络访问－－数据通信设备（DCE）、域名服务器（DNS）、和 轻量目标访问协议（LDAP）
无论它们支持的是哪种标准，主流的数据仓库工具都受元数据所驱动。然而，它们通常并不互相共享元数据而且在开放性上也所有不同。所以，要仔细研究和购买工具。架构师是你选择适当工具的向导。
一个数据仓库架构需要具体到怎样的程度呢？这个问题要问的是：它有足够的信息可以让一个有能力的团队来建立一个满足业务需求的数据仓库吗？至于它要花多长时间，随着更多的人加入到它的开发中来（即：它变成了“复杂的技术策略”）和生成的系统需要变得更复杂（即"复杂的功能”），架构的完成会呈指数倍的发展。
像数据仓库中几乎所有的事情一样，一个迭代进程是最好的。你不能一次做完所有的事情因为它太大了， 而且业务不能等。同时，数据仓库的市场还没有完备。所以从流程中影响大、高价值部分开始，然后，利用你的成功去带动另外的阶段。
总结：
综上所述，建立一个数据仓库架构的好处如下：
●提供了一个组织结构的框架-－架构对什么是单独的组件、如何将它们组装在一起、谁拥有什么部分以及优先次序的问题划出了界线。
●提高了灵活性和维护性-－让你能快速加入新的数据来源，接口标准允许即插即用，模型和元数据允许影响分析和单点的变化。
●更快的开发和再利用-－数据仓库开发者更能够快速了解数据仓库流程、数据库内容和业务规则。
●管理和通信的工具-－定义未来方向和项目范围， 确定职务和职责、对供应商传达需求。
●协调多项任务同时进行——多种、相对独立的工作有机会成功地集合。
我们建议公司对准业务需求而又要务实一些。时刻跟上数据仓库产业的进步是很重要的。最后，请记住架构总是存在的：或隐性或具体的，或无计划或计划内的。经验证明，有一个计划内和具体的架构会使数据仓库与 商业智能项目有更多的成功机会。
7. 怎样做好仓库中的数据管理
一、仓库的常见问题： 仓库管不好，一边是数以万计的物料、成百上千的供应商，诺大的货架式立体仓库，一边是为数不多且素质平平的仓管员，种类繁多但不适用，也基本不用的制度和流程。归根到底，仓库问题基本上都来自现场管理不到位，例如： 1、不遵守先进先出原则(First In，First Out----FIFO)，造成呆料、废料。 2、不按库位摆放物料，或移动物料后，不及时把新库位的资料交给录单员录入系统，造成无法找到相关物料。 3、仓管员不及时送单给录单员，录单员不及时录入系统，结果造成系统数据与实际脱节，影响ERP系统数据的准确性，最终影响到了生产计划的贯彻和执行。标识不统一、不规范，不是没有物料编码，就是物料名称不对，以致无法追查该物料的历史状况。 4、部分仓管员责任心不够，工作态度消极，办事拖拉，库存盘点不准，以及手工单据信息不准确(主要是抄写错误，键入错误)，这都是常有的事。 5、新旧仓管员交接不清，换一个仓管员，没有真正的交接手续，对前任仓管员所管的物料状态不明的，干脆就封存起来不予管理，只说"找不到"，造成了不应有的呆滞和浪费。 二、仓库该如何管理： 仓库说好管也好管，说难管也难管，首先应理清思路，弄清楚几个基本问题。 1、“物料”是什么？“仓库”是什么？ “物料”包罗万象，客观存在，但那只是其表现形式，其实物料就是钱，物化了的钱，而仓库就是放钱的口袋。钱放在家里不能增值，钱要通过使用或投资流动起来，才能产生价值。同样，物料为生产及销售而快速地流动起来才能创造效益。当然，钱会丢失，也可能被盗，同样，物料可能被浪费、被损坏及被盗窃。任何浪费、破坏和盗窃物料的行为，都是对公司、股东、对全体员工利益的侵犯! 2、物料管理管什么？ 任何一项管理活动，都会涉及时间(T)、质量(Q)、成本(C)，这三者彼此牵连，又相互制约，物料管理也概莫能外。 ①T-Time时间：指物料的交期、入仓期、使用时间、仓储时间、退料时间等等。 ②Q----Quality质量：指物料本身的质量、仓储质量、对有质量问题的物料的处理等等。 ③C----Cost成本：指物料的价格、仓储的成本、呆滞的成本、短缺造成停工的成本、多余造成的库容成本、占用资金造成的资金周转成本。
8. 数据仓库数据建模的几种思路
数据仓库数据建模的几种思路主要分为一下几种 1. 星型模式 星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：a. 维表只和事实表关联，维表之间没有关联；b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；c. 以事实表为核心，维表围绕核心呈星形分布； 2. 雪花模式 雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用 雪花模式 3．星座模式 星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。 星座模型
最新文章
热门文章
推荐阅读