到了21世纪中期，我现已运用联系型数据库多年了，但我从未接触过联系型数据库房。我其时在一家公司担任数据库管理员（DBA），该公司运用会计软件包管理其财务交易。该软件包的陈述功能有限且运转缓慢，因而公司期望进步功能，创立仪表板来剖析数据，并将其财务数据与自制应用程序的数据相结合，以更好地了解事务情况。
我的雇主聘请了一家咨询公司来构建这个被称为“联系型数据库房”的东西，而且在改变了我作业生涯方向的一次决定中，邀请我协助他们。咱们制作了仪表板，节约了最终用户很多的时刻，并增加了他们曾经从未拥有过的商业见地。当我看到他们脸上的激动之情时，我知道我找到了自己的新热情。我改变了我的作业方向，专心于数据库房，从未回头看过。
什么是联系型数据库房？
联系型数据库房（RDW）是您会集存储和管理很多结构化数据的当地，这些数据从多个数据源仿制过来，用于前史和趋势剖析陈述，以便您的公司能够做出更好的事务决议计划。它被称为联系型，由于它依据联系模型，这是数据库中广泛运用的一种数据表示和安排办法。在联系模型中，数据被安排成表（也称为联系，因而得名）。这些表由行和列组成，其间每一行代表一个实体（如客户或产品），每一列代表该实体的一个属性（如称号、价格或数量）。它被称为数据库房，由于它搜集、存储和管理来自各种来历的很多结构化数据，如事务性数据库、应用体系和外部数据源。
并非一切的数据库房都依据联系模型。非联系型数据库房包括列式、NoSQL 和图形数据库房等类型。可是，联系型数据库房更受欢迎，被广泛选用，首要是由于联系数据库几十年来一直是主导的数据管理范式。联系模型十分适合于结构化数据，在事务应用程序中很常见。由于 SQL 的广泛运用，联系型数据库房也因而受欢迎，SQL 现已成为多年来联系型数据库房的规范语言。
RDW 充当许多主题领域的中心存储库，并包括真理的单一版别（SVOT）。SVOT 是数据库房中的一个要害概念，它指的是创立安排数据的统一、一致的视图的实践。这意味着数据库房中的一切数据都以规范化的结构化格式存储，并代表信息的单一、精确版别。这保证一切用户都能拜访相同的信息，消除任何差异或不一致性，消除数据孤立。这进步了安排内的决议计划拟定、协作和效率。它还降低了因运用不一致的数据源而产生的过错和误解的风险。
幻想一下，假如没有数据库房，直接从多个源体系生成陈述，甚至或许还有一些 Excel 文件。假如陈述查看者质疑数据的精确性，您能告知他们什么呢？“真理”或许涣散在如此多的源体系中，以至于难以追踪数据的来历。此外，某些陈述将为相同数据供给不同的成果，例如，假如两个陈述运用杂乱的逻辑从多个源中提取数据，而且逻辑更新不正确（或底子没有更新）。将一切数据会集存储在一个当地意味着数据库房是真理的仅有来历；关于陈述数据的任何疑问都能够经过数据库房回答。坚持 SVOT 关于期望充分利用其数据潜力的安排至关重要。
假如整个公司运用数据库房（DW），一般称为企业数据库房（EDW）。这是数据库房的更全面、更强壮的版别，旨在支撑整个安排的需求。虽然规范 DW 或许支撑一些事务单位，而且在整个安排中有许多 DW，但 EDW 运用更广泛的数据源和数据类型来支撑一切事务单位。EDW 供给了安排一切数据的单一、统一视图。
图4-1说明晰拥有数据库房的一个首要原因。左图显示了在没有数据库房的情况下，从多个应用程序中运转陈述是多么具有应战性。每个部分都运转一个陈述，搜集与每个应用程序关联的一切数据库的数据。因而，会运转很多查询，或许会呈现功能问题和过错数据。这很紊乱。右图显示，将一切应用程序数据仿制到 EDW 中后，每个部分都能够轻松运转陈述，而不会影响功能。
一般，构建数据库房时，您将创立数据流水线，履行三个步骤，称为提取、转化和加载（ETL）：
- 数据流水线从源体系（如数据库和平面文件）提取数据。
- 然后对提取的数据进行转化或操作，以契合方针体系的要求（在本例中，契合数据库房的要求）。这或许触及整理、过滤、聚合或组合来自多个来历的数据。
- 转化后的数据被加载到数据库房中。数据库管理员（DBA）能够使数据库和字段称号更有意义，这样终端用户就能够更轻松、更快速地创立陈述。
数据库房不是什么？
现在您现已了解了数据库房的含义，让咱们经过查看不应被视为数据库房的处理方案来弄清其目的（虽然我屡次看到人们这样做）：
- 带有DW前缀的数据库
数据库房不是仅仅将操作体系中的源数据库仿制一份，并在文件名中增加DW后缀。例如，假定您仿制了一个名为Finance的数据库，其间包括50个操作表，并将仿制命名为DW_Finance，然后运用这50个表来构建报表。这将导致数据库房被规划用于操作数据，而实际上您需求的是为剖析数据进行规划。关于剖析数据，您拥有更好的读取功能，而且能够创立数据模型，使最终用户更简单构建报表。（我将在下一节中具体解释。）
- 包括联合视图
数据库房不是多个来自各种源体系的表的仿制，经过SQL视图进行联合。 （联合是经过SQL UNION句子完结的，它将两个或多个SELECT句子的成果合并成一个成果集。）例如，假如从三个包括客户信息的源体系中仿制数据，则会在数据库房中得到三个表，别离为CustomerSource1，CustomerSource2和CustomerSource3。因而，您需求创立一个名为CustomerView的视图，该视图是对表CustomerSource1，CustomerSource2和CustomerSource3进行联合的SELECT句子。您需求对其他表（例如产品和订单）重复此进程。
相反，应将三个表的数据仿制到数据库房中的一个表中，这需求额定的作业来创立适合一切三个表的数据模型。在这一点上，您或许期望运用主数据管理（MDM），在第6章中有解释，以避免重复项并进步可拜访性和功能。
- “倾倒场”
数据库房不是表的倾倒场。许多情况下，当公司没有数据库房，而最终用户期望从几个源体系的数据子集创立报表时，会呈现这种情况。为了敏捷协助他们，IT部分的人员毫不犹豫地创立了一个数据库房，将这两个源体系的数据仿制到数据库房中。然后其他最终用户看到了第一个最终用户取得的优点，他们期望从相同的源体系以及其他一些源体系获取额定的数据来创立自己的报表。因而，IT人员再次敏捷将所请求的数据仿制到数据库房中。这一进程一遍又一遍地重复，直到数据库房变成了一团紊乱的数据库和表。
因而，许多数据库房最初是为几个用户量身定制的处理方案，然后变成了全公司规划但规划不佳的数据库房。有更好的办法。 相反，当第一个最终用户请求呈现时，请评估您公司的陈述需求。了解该请求是否真的是一次性的，或许是否应该是构建企业数据库房的开端。假如是这样，这是向高档领导展示为什么您公司需求数据库房的机会。假如是这样，请坚持以为您需求足够的前期时刻来规划一个能够支撑多个数据源和最终用户的数据库房。（运用“为什么运用联系型数据库房？”来支撑您的观点。）
自上而下的办法
在联系数据库房（RDW）中，你会在前期做很多作业，使数据能够用于创立陈述。在之前进行一切这些作业是一种被称为自上而下办法的规划和施行办法论。这种办法适用于前史类型的陈述，在这种陈述中，你企图确认产生了什么（描绘性剖析）以及为什么会产生（确诊性剖析）。在自上而下办法中，你首要确立数据库房的整体规划、规划和架构，然后再开发具体的组件。该办法强调了在着手开发数据库房之前界说企业规模的愿景和了解安排的战略方针和信息需求的重要性。
描绘性剖析和确诊性剖析是事务中常用的两种重要的数据剖析类型。描绘性剖析触及剖析数据以描绘曩昔或当时事件，一般经过摘要核算或数据可视化来完结。这种类型的剖析用于了解曩昔产生了什么，并辨认数据中的方法或趋势，有助于决议计划。
确诊性剖析用于调查曩昔事件的原因，一般是经过查看不同变量或因素之间的联系来完结的。这种类型的剖析能够确认问题的底子原因或确诊或许影响事务绩效的问题。
假定一家公司期望剖析曩昔一年的出售数据。描绘性剖析将触及核算摘要核算数据，如总出售收入、平均每日出售额以及按产品类别的出售情况，以了解产生了什么。相比之下，确诊性剖析将查看因素之间的联系（例如出售和营销开销，或季节性和客户人口核算信息），以了解为什么出售在一年中波动。经过结合这两种办法，公司能够更深化地了解他们的数据并做出更明智的决议计划。
图4-2显示了典型RDW的架构。ETL用于将数据从多个来历摄入到RDW中，然后能够进行陈述和其他剖析。
自上而下办法一般触及以下步骤：
- 提前拟定一些假定。 从明晰了解企业战略开端。然后保证你知道你想向数据提出什么问题。
- 确认事务需求。 确认安排的方针、方针和要害绩效指标（KPI）。搜集和剖析各部分和用户的信息需求。你也能够将这一步看作是界说你的陈述需求。
- 规划数据库房架构。 依据事务需求，为数据库房创立一个高档架构，包括其结构、数据模型和数据集成流程。这些将成为你的技能要求。
- 开发数据模型。 为数据库房规划具体的数据模型，考虑各种数据实体之间的联系和数据的粒度。
- 构建架构。 为数据库房开发恰当的数据库、方法、表格和字段。这是之前描绘的称为写入方法的办法。
- 开发ETL。 开发ETL进程，从各种源体系中提取数据，将其转化为所需格式，并加载到数据库房中。
- 开发和部署BI东西和应用程序。 施行BI东西和应用程序，答应用户拜访、剖析和陈述存储在数据库房中的数据。
- 测试和完善数据库房。 进行测试以保证数据质量、功能和可靠性。依据需求进行任何必要的调整，以优化体系。
- 保护和扩展数据库房。 跟着安排需求的改变，相应地更新和扩展数据库房。
自上而下办法有一些优势，如对安排数据需求的全面了解，更好的数据一致性和改进的治理。可是，它也或许耗时和资源密集，交付价值需求的时刻比数据湖选用的自下而上办法长，数据湖的办法在第5章中有描绘。现代数据库房架构，在第10章中描绘，结合了自上而下和自下而上办法。
为什么要运用联系型数据库房？
运用RDW能够更轻松地构建任何类型的商业智能处理方案，由于商业智能处理方案能够直接从RDW中提取数据，而无需创立杂乱的逻辑从多个源体系中提取数据。此外，它们也不必整理或衔接数据，由于RDW现已完结了这些作业。从RDW构建的商业智能处理方案能够是数据集市（它包括特定人群的RDW数据子集，如第6章所述），可聚合数据以加速查询和陈述速度，甚至可在Microsoft Excel中运用。
总归，有了RDW，您现已有了一个坚实的根底来构建。 让咱们具体了解一下从运用RDW中能够取得的一些首要优点：
- 减轻出产体系的压力
您或许曾经遇到过这个问题：用户打来怒气冲冲的电话，抱怨经过订单输入应用程序刺进订单花费了很长时刻。您查看后发现，另一个用户正在经过订单输入应用程序运转陈述，占用了应用程序地址服务器上的一切资源。特别是当答应用户创立自界说查询并编写糟糕的SQL时，这种情况尤其常见。
经过将订单输入应用程序数据库仿制到DW并对其进行优化，您能够让一切陈述和自界说查询都针对DW运转，从而彻底避免这个问题，特别是假如用户需求运转针对多个应用程序数据库的陈述。
- 优化读取拜访
应用程序数据库会被优化以支撑一切的增修正查操作，因而数据的读取速度不会像它本应该的那样快。另一方面，数据库房是一种“写一次，屡次读取”的体系，首要用于数据的读取。因而，能够针对读取拜访进行优化，特别是关于运转陈述或查询时经常产生的耗时的次序磁盘扫描。有许多数据库技能可用于加速DW的读取拜访，其间一些或许会影响写入拜访，但咱们不需求关注这一点。
- 集成多个数据源
集成多个数据源以创立更有用的陈述的能力是构建DW的更重要的原因之一。将一切数据放在一个当地而不是涣散在各种数据库中不仅使陈述生成变得更加简单，而且极大地进步了陈述的功能。
- 运转精确的前史陈述
没有DW，应用程序的最终用户一般会在每个月的特定日期（一般是最终一个作业日）运转他们的一切陈述。然后，他们将其保存到磁盘上，以便将来参阅。例如，用户想查看几个月前的陈述，列出了按州划分的客户出售额。可是，一位客户最近搬到了另一个州。假如用户运转当时的陈述，它将过错地显示客户在新州的出售额，而不是旧州的出售额（由于他们在数据库中的记载现已更新为新州）。因而，用户有必要查看保存的旧陈述，而不是运转当时陈述。
DW能够经过盯梢客户的移动（经过盯梢客户方位前史和开始日期和完毕日期）以及需求盯梢的任何其他字段（例如，雇主或收入）来处理这个问题。现在，用户能够今天运转一个陈述，但要求它以曩昔某个日期的数据为根底，陈述将精确无误。此外，不再需求每月保存陈述文件。
- 重新构建和重命名表格
许多应用程序数据库的表格和字段称号十分难以了解，特别是旧的ERP和CRM产品（想想表格称号，例如T116和字段称号，例如RAP16）。在数据库房中，您能够将这些源表格中的数据仿制到更易于了解的当地（例如，将T116替换为Customer）。您还能够为一切表格规划更好的数据模型。当用户不必翻译晦涩的表格和字段称号时，他们将能够更轻松地创立陈述。
- 避免应用程序晋级带来的影响
幻想一下，假如没有DW，用户将创立陈述来自应用程序数据库。一切都运转杰出，突然之间，许多陈述开端呈现过错。原来是应用程序进行了晋级，安装了一个新版别，其间重新命名了一些表格和字段。因而，您现在有必要逐个查看每个陈述，合计几百个，然后重新命名更改后的表格和字段。这或许需求几个月的时刻，导致许多懊丧的最终用户。即使在那之后，任何被疏忽的陈述或许依然会呈现过错。
DW能够保护您免受此影响。应用程序晋级后，只需更新从应用程序数据库仿制数据到DW的ETL – 这是一个快速的使命。陈述不需求更改。用户在ETL修复之前看不到任何新数据，可是他们的陈述不会呈现过错。
- 减少安全性问题
没有DW，您的团队需求为每个最终用户供给对其需求用于陈述目的的每个应用程序数据库的安全拜访权限。或许会有几十个;供给拜访权限的进程或许需求几周，有时甚至或许依然无法取得所需的一切权限。有了DW，每个最终用户只需求拜访恰当的表格，供给这一点要快得多，也更简单。
- 保留前史数据
许多出产体系约束了它们保存的前史数据的数量（例如，最近三年的数据）。它们这样做是为了节约空间和进步功能，而且在某些情况下，是为了契合法规。较老的数据一般会每年或每月清除一次。另一方面，DW能够保存一切前史记载，因而您永远不必担心运转陈述以获取旧年份的数据而找不到任何数据。
- 主数据管理（MDM）
当您从多个源体系搜集数据时，很多时分您需求运用MDM删除重复记载，例如客户、产品和财物等。 （有关MDM的更具体解释，请参见第6章。）DW是履行MDM的理想地址。此外，许多MDM东西还答应您创立层次结构（例如，公司→部分→职工），从而增加了主数据的价值。
- 经过填补源体系中的空泛进步数据质量
虽然应用程序一切者说的内容与现实并不一致（我听到他们屡次说“咱们的数据很洁净”），但您会发现从各种源体系获取的许多数据需求进行整理。例如，订单输入应用程序或许需求客户的出生日期，假如输入数据的人不知道客户的出生日期，他们或许会输入未来的日期或100多岁的日期，以便能够完结订单。或许，也许应用程序不查看输入的两位数州代码的精确性。源体系中总是有很多“空泛”。您不仅能够整理DW中的数据，还能够通知保护应用程序的人员有关其体系中空泛的信息，以便他们能够处理问题。经过这种办法，您能够避免将来录入过错数据。
- 消除IT参加陈述创立
这回到了第3章说到的自助式商业智能：构建一个恰当的DW将消除需求让IT参加构建陈述的需求，并将此使命交给最终用户处理。没有了IT资源有限的瓶颈，陈述和仪表板能够更快地构建。而且IT将感激不必再创立陈述，而能够致力于更有趣的项目！
运用联系型数据库房（RDW）存在的缺点
总会存在取舍，以下是建立 RDW 时需求考虑的缺点：
- 杂乱性 数据库房（DW）或许十分杂乱且耗时，规划、构建和保护都需求专业技能和资源，这或许会增加本钱。
- 高本钱 施行数据库房或许本钱昂扬，需求在硬件、软件和人员方面进行严重出资。持续的保护和晋级也或许增加本钱。
- 数据集成应战 整合来自不同来历的数据或许具有应战性，由于或许触及到不同的数据格式、结构和质量问题。这或许会导致花费时刻和精力进行数据清洗和预处理。此外，某些数据，例如来自物联网设备的流数据，太难以被摄入到 RDW 中，因而这些信息的潜在洞见或许会丢失。
- 耗时的数据转化 要将数据加载到 DW 中，或许需求对其进行转化以契合库房的数据模型。这个进程或许会耗费很多时刻，而数据转化中的过错或许导致剖析成果不精确。
- 数据推迟 由于 DW 规划用于处理很多数据，它们处理速度或许比其他类型的数据库慢。这或许导致数据推迟，即库房中的数据与源数据库的最新更改不一致。
- 保护窗口 关于 RDW，一般需求一个保护窗口。加载和整理数据十分资源密集，假如用户一起测验运转陈述，功能将会十分慢。因而，在保护期间，用户有必要被确认在库房之外，以避免 24/7 拜访。假如在保护窗口期间产生任何问题，例如 ETL 作业失利，您或许需求延伸保护窗口。假如用户测验运转陈述但仍被确认，那么他们会感到懊丧，无法完结作业。
- 约束的灵活性 数据库房规划用于支撑特定类型的剖析，这或许约束了它们对其他类型数据处理或剖析的灵活性。或许需求集成额定的东西或体系来满意特定需求。
- 安全性和隐私问题 在会集方位存储很多敏感数据或许会增加数据泄露和隐私侵犯的风险，因而需求强有力的安全措施。
填充数据库房
由于输入到数据库房的源表会跟着时刻而改变，所以数据库房需求反映这些改变。这听起来似乎很简单，但实际上需求做出许多决定：提取（或拉取）数据的频率是多少，运用什么提取办法，怎么物理提取数据，以及怎么确认自前次提取以来哪些数据产生了改变。我将扼要评论每一个问题。
提取数据的频率
更新数据库房的频率首要取决于源体系的更新频率以及最终用户需求陈述数据的时效性。一般，最终用户不期望看到当天的数据，而更倾向于获取到前一天完毕的一切数据。在这种情况下，您能够在源体系数据库更新完结后的每个夜间运用ETL东西运转作业，创立一个夜间保护窗口来进行一切数据传输。假如最终用户需求在白日进行更新，则需求更频频的提取，例如每小时一次。
需求考虑的一点是每次提取的数据量。假如数据量十分大，更新数据库房或许需求太长时刻，因而您或许期望将更新拆分为较小的块，并进行更频频的提取和更新（例如，每小时而不是每天）。此外，从源体系传输很多数据或许需求太长时刻，特别是假如源数据位于本地，而您没有从源体系到互联网的大型管道。这是您或许期望从每晚的大型传输转向白日较小的小时传输的另一个原因。
提取办法
提取数据有两种办法。让咱们别离看一下：
1. 彻底提取
在彻底提取中，一切数据都彻底从一个或多个源体系中提取出来。这对较小的表格效果最好。由于此提取反映了源体系上当时可用的一切数据，因而无需盯梢更改，使得此办法十分易于构建。源数据按原样供给，而且您不需求任何额定的信息（例如，时刻戳）。
2. 增量提取
在增量提取中，您只提取自指定时刻以来已更改的数据（例如，前次提取或财务期末之后的数据），而不是整个表。这对大型表格效果最好，而且仅当能够辨认一切更改的信息时才有效（下文评论）。
关于大多数源体系，您将一起运用这两种办法。
无论是进行彻底提取仍是增量提取，提取数据有两种办法：在线和离线。
在线提取中，提取进程能够直接衔接到源体系以拜访源表，或许它或许衔接到一个中间体系，该体系以预装备的办法存储数据的更改（例如，以事务日志或更改表的方法）。
可是，并非总是能够直接拜访源体系。在这种情况下，数据在原始源体系外进行分级处理，并由源体系主张的提取例程创立（例如，一个主机履行对表的提取例程，并将数据存储在文件体系的文件夹中）。提取的数据一般放置在以界说的通用格式（例如，CSV或JSON）为根底的平面文件中。
怎么确认自前次提取以来产生了哪些数据更改
遗憾的是，许多源体系很难辨认最近修正的数据并进行增量提取。以下是几种从源体系中辨认最近修正的数据并施行增量提取的技能。这些技能能够与评论的数据提取办法结合运用。某些技能依据源体系的特性；其他或许需求对源体系进行修正。在施行之前，源体系的一切者应细心评估任何技能：
时刻戳
时刻戳是最理想的挑选，也是最简单完结的。一些操作体系中的表具有时刻戳列，其间包括给定行前次修正的时刻和日期，从而很简单确认最新的数据。在联系数据库中，时刻戳列一般具有时刻戳或日期时刻数据类型，以及类似于时刻戳或前次修正的列名。源应用程序将填充此列。假如没有，您能够设置联系数据库，在保存记载时默以为当时日期，或许您能够增加数据库触发器来填充该列。
更改数据捕获
大多数联系数据库支撑更改数据捕获（CDC），它记载应用于数据库表的INSERT、UPDATE和DELETE操作，并依据联系数据库的事务日志生成更改表记载，记载产生了什么改变，何时产生改变。假如您需求简直实时的数据库房，其间您能够在几秒钟内看到对源体系的更改在数据库房中的反映，CDC能够成为要害的启用技能。
分区
一些源体系运用规模分区，其间源表依据日期键进行分区，这样能够很简单地辨认新数据。例如，假如您正在从按天分区的订单表中提取数据，那么很简单辨认当时或前一天的数据。
数据库触发器
您能够在单个表上增加INSERT、UPDATE和DELETE触发器，并让这些触发器将有关记载更改的信息写入“更改表”中。这类似于更改数据捕获，因而假如您的数据库产品支撑CDC，请运用CDC；否则，请运用触发器。
MERGE句子
最不理想的挑选是从源体系进行彻底提取到DW中的临时区域，然后运用MERGE句子将此表与来自源体系的曾经的彻底提取进行比较，以辨认更改的数据。您将需求将一切源字段与一切方针字段进行比较（或运用哈希函数）。假如数据量很大，这种办法或许不会对源体系产生严重影响，但或许会给DW带来严重负担。假如没有其他挑选，一般这种挑选是最终的挑选。
联系数据库房的消亡现已被极大夸大
大约在2010年初，IT界开端质疑是否还需求联系数据库房，提出了“联系数据库房已死”的问题。许多人了解这个问题是在问询企业是否依然需求数据库房。正如本章所指出的，的确需求。但实际上，这个问题实际上是关于数据库房架构的——你是否能够仅运用数据湖，仍是应该一起运用数据湖和联系数据库房？
当数据湖首次呈现时，它们是建立在Apache Hadoop技能上的，而首要是Hadoop供应商宣告了联系数据库房的消亡。“只需将一切数据放入数据湖，摆脱联系数据库房”，他们主张道。如第2章所述，测验这样做的项目都以失利告终。
多年来，我一直以为联系数据库房将永远是必需的，由于数据湖都是依据Hadoop的，而且存在太多的约束。可是一旦诸如Delta Lake（见第12章）这样的处理方案变得可用，而且数据湖开端运用比Hadoop更好、更易于运用的产品（见第16章），我开端看到一些情况下能够在没有联系数据库房的情况下完结处理方案。这种类型的处理方案是数据湖库房架构，将在第12章中介绍。
可是，依然有许多情况需求联系数据库房。虽然数据湖技能将持续改进，从而减少或消除绕过联系数据库房的担忧（见第12章），但咱们永远不会彻底放弃联系数据库房。我以为有三个原因。首要，从数据湖陈述依然比从数据库房陈述更加困难。其次，联系数据库房持续满意用户的信息需求并供给价值。第三，许多人运用、依赖和信赖数据库房，并不想用数据湖替换它们。
数据湖为数据科学家和自助数据顾客（“高档用户”）供给了丰富的数据来历，而且很好地满意了剖析和大数据的需求。但并非一切的数据和信息作业者都想成为高档用户。大多数人依然需求集成杰出、体系清洗、易于拜访的联系数据，其间包括一个捕获事物怎么跟着时刻推移或发展的前史记载。这些人最适合运用数据库房。
总结
本章介绍了第一种广泛运用的技能处理方案，用于会集来自多个来历的数据并对其进行陈述：联系数据库房（RDW）。RDW经过供给一个会集的数据存储库和检索库，彻底改变了企业和安排管理数据的办法，完结了更高效的数据管理和剖析。经过以结构化办法存储和安排数据，RDW答应用户快速轻松地生成杂乱的查询和陈述，供给宝贵的洞见，支撑要害决议计划拟定。
如今，联系数据库房依然是许多数据架构的根本组成部分，而且在各行各业广泛应用，从金融和医疗保健到零售和制造业都有所体现。接下来的一章将评论下一个成为数据会集和陈述的重要因素的技能：数据湖。
