数据处理分类、数据仓库产生原因

本文探讨了操作型数据处理和分析型数据处理的区别,强调了OLTP的事务处理特性和数据库管理系统的ACID属性,以及数据仓库的诞生背景,重点在于如何解决数据分散、集成、不一致和动态集成等问题,以提升分析和决策的效率。
摘要由CSDN通过智能技术生成

个人看书学习心得及日常复习思考记录,个人随笔。

数据处理分类

操作型数据处理(基础)

操作型数据处理主要完成数据的收集、整理、存储、查询和增删改操作等,主要由一般工作人员和基层管理人员完成。

联机事务处理系统(OLTP,典型)主要功能是对事务进行处理,其性能指标主要是事务处理效率事务吞吐率,即每个事务处理的时间越快越好(单位时间内能完成的事务数量越多越好)。【强调:事务、关系

数据库管理系统(DBMS)是联机事务处理系统的主要组成部分
数据库管理系统主要用于对数据进行有效的存储、管理和存取,其通过流程化存取及缓存机制等,将数据存储到数据库中,最后将数据落地到磁盘。
在这里插入图片描述
事务是用户定义的一个数据库操作序列,这些操作要么全做,要么全不做,是一个不可分割的工作单位

在关系型数据库中,一个事务可以是一条SQL语句、一组SQL语句或者整个程序。事务和程序是两个概念,一个程序中可以包含多个事务。

数据库管理系统采用日志、备份等恢复技术和并发控制技术来保证事务的原子性(atomictiy)、一致性(consistency)、隔离性(isolation)和持续性(durability)【ACID特性】

在关系型数据库中,采用索引技术来快速定位数据;采用并行技术提高处理能力和系统的扩展性;采用封锁技术提高并发度,部分关系型数据库DSC集群还引入了闩封锁,允许多个用户同时使用数据库及系统资源,提高了事务的吞吐量;

在关系型数据库中,采用关系规范化理论,每张表按规范一般需要达到第三范式或BC范式消除表中属性间的部分依赖和传递依赖,各属性只依赖于主码,希望能消除数据冗余,缩短事务处理时间。

相比OLAP而言,OLTP中的事务一般都是短事务,存取数据量较少,所需处理时间较短。

分析型数据处理(基础)

分析型数据处理是对数据的再加工,往往要访问大量的历史数据,进行复杂的统计分析,从中获取信息,因此也称为信息型处理,主要由高级管理人员完成。

决策支持系统(DSS,典型)基本功能是建立各种数学模式,并对其进行数据统计分析,将得出数据价值作为决策的依据和基础。【强调:分析、决策

操作型数据和分析型数据区别

分析型数据处理不同于操作型数据处理,其需要访问大量的当前和历史数据,进行复杂的计算,用于分析和挖掘数据价值,而操作型数据库一般推荐存储明细数据,分析型数据库一般推荐存储历史数据和综合数据。
在这里插入图片描述

数据仓库产生原因

随着第四次工业革命的浪潮到来,许多企业发现传统数据库系统在操作型数据处理中取得的成就,不适用于大数据的分析型数据处理中。数据仓库诞生之前,有着一系列值得思考的问题,为了解决这些问题,方法层出不穷。

数据分散问题

企业开发的联机事务处理系统一般只需要与本部门业务有关的当前数据,而对整个企业范围内的集成应用考虑较少,企业内部各事务处理的应用之间实际上几乎独立,因此当前绝大部分企业内数据的真正情况是分散而非集成的。当然出现上述现象原因诸多,有可能因为系统架构设计及发展规划层面,也有可能因为经济方面。

“蜘蛛网”问题

解决上述数据分散问题的其中一种方法则是对数据进行集成。基于各分散的数据库,以业务需求为导向选择符合条件的数据,将其抽取汇总到某一新文件或数据库中。由于抽取程序能将数据从联机事务处理系统中转移出来,而对转移出来的数据进行分析时降低了影响联机事务处理系统的效率。

因某种业务需求,需要抽取,随后又抽取,抽取之上又抽取,接着在此基础上再抽取,这种不加控制的连续抽取最终导致企业的数据间形成错综复杂的网状结构,像“蜘蛛网”。企业规模越大,数据越分散,数据需求越复杂,“蜘蛛网”问题就越严重。

虽然“蜘蛛网”上任意两个节点的数据可能归根结底是从一个原始数据库中抽取出来,但它们的数据没有统一的时间基准,抽取算法和抽取级别也不相同,并且可能参考了不同的外部数据,因而对同一问题的分析,不同节点会产生不同甚至截然相反的结果,从而使决策者/分析者所分析的数据存在差异。

数据不一致问题

由于前述的数据分散、“蜘蛛网”等问题,导致了多个应用间的数据不一致。这些数据不一致的形式是多种多样的。
例如:
1、同一字段在不同应用中具有不同的数据类型。
2、同一字段在不同应用中具有不同的名字。
3、同名字段,不同含义。
为了将这些不一致的数据集成起来,首先需要对所抽取的数据进行转换,消除数据不一致才能用作分析。

数据动态集成问题

静态集成对所需数据进行集成后就一直以这部分集成数据作为分析基础,不再与数据源发生联系。缺点:如果在数据集成后数据源中数据发生变更,因数据静态集成,分析数据未能同数据源一样变更,所以导致决策者/分析者使用过时数据。

动态集成集成数据必须以一定周期/频率进行刷新。其实这里说的“周期/频率”需要结合实际的业务需求,以业务需求为导向去评估“周期/频率”

联机事务处理系统不具备动态集成的能力。决策支持系统对数据集成的迫切需要可能是数据仓库出现的重要动因之一。

联机事务处理系统是一种用于处理实时交易和数据的计算机系统。它主要用于处理大量的并发事务,并保证数据的一致性和完整性。然而,联机事务处理系统通常不具备动态集成的能力,这意味着系统在运行时难以添加或修改功能模块。
这是因为联机事务处理系统通常是基于静态架构设计的,其功能模块在系统部署之前就已经确定,并且很难进行修改。这种设计方式可以确保系统的稳定性和可靠性,但也限制了系统的灵活性和可扩展性
如果需要实现动态集成的能力,可以考虑使用其他类型的系统,如面向服务架构(SOA)或微服务架构。这些架构可以通过将系统拆分为独立的服务,并使用适当的通信机制来实现动态集成和功能扩展

历史数据问题

联机事务处理一般只需要当前数据,在数据库中通常也只存储短期内的数据,且不同数据的保存期限不一样。一些历史数据即使保存,也没得到充分利用。但对于决策分析而言,许多分析方法必须以大量的历史数据为依托,需要对历史数据详细分析,挖掘数据价值,把握发展趋势。

数据综合问题

对于事务处理系统中所积累的大量细节数据,一般而言,决策支持系统并不对这些细节数据进行分析。一是细节数据数据量太大,会严重影响分析的效率;二是太多的细节数据不利于分析人员注意有用信息。因此,在分析前往往需要对细节数据进行不同程度的综合。

而事务处理系统不具备这种综合能力,根据规范化理论,这种综合还往往因为是一种数据冗余而被加以限制。

以上系列问题表明,在操作型数据处理的应用环境中直接构建分析型数据处理应用是一种失败的尝试。

数据仓库本质上是对存在的这些问题的解答。但数据仓库的主要驱动力并不是改正过去的缺点,建立在事务处理环境上的分析系统存在上述各种问题。要提高分析和决策的效率和有效性,分析型处理及其数据将与操作型处理及其数据相分离,必须把分析型数据从事务处理环境中提取出来,按照决策支持系统处理的需要进行重新组织,建立单独的分析型处理环境–数据仓库

  • 23
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

偷偷学习被我发现

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值