当今的企业拥有庞大、复杂且不断增长的数据集格局，对数据访问和分析的需求每年都在增长。我想展示数据分析师、BI/DWH 开发人员和所有其他数据专家在处理这片数据海洋时遇到的障碍。

我们以想象中的一家生产盒子的制造公司为例。我们称之为Box Inc。

1. 有很多数据库

任何企业都有许多不同的松散连接的应用程序和数据库——遗留数据库、自定义应用程序、打包应用程序、数据仓库等等。

Box Inc 具有以下数据架构：

1. 具有制造、采购、库存、财务模块的ERP打包应用
2. 具有计划、预算、合并报告和分析 CRM 模块的数据仓库
3. 打包的 CRM 应用程序
4. 打包的人力资源管理 (HRM) 应用程序
5. 打包的项目管理应用程序
6. 自定义时间追踪应用程序
7. 自定义技术管理应用程序
8. 自定义设施维护应用程序
9. 销售支持应用程序
10. 与 CRM 集成的打包客户服务应用程序
11. 与主要财务系统集成的打包发票工作流应用程序
12. 内网门户
13. 访问控制数据库（物理门和门）
14. 分包商门户
15. 供应商集成平台，可实现材料的自动报价
16. 客户可以下订单的标准电子商务平台
17. 客户门户网站，客户可以在其中访问文档并请求技术支持
18. 为客户和供应商提供主数据管理解决方案，以保持跨系统的数据一致
19. 具有所有用户帐户的 LDAP
20. 文件存储

以及十几个其他较小的应用程序和数据库。

如您所见，仅仅浏览数据库本身并不是一项微不足道的任务。但是让我们继续搜索数据。

2. 数据库庞大而复杂

许多企业应用程序都有非常庞大和复杂的数据库。尤其是打包应用程序，尤其是 ERP，就是一个很好的例子。可能很难相信，但流行的 ERP 应用程序拥有数万或数十万个表和视图。让我们看几个例子：

流行应用程序中的表和视图数量： - TETA (HRM): 9,000 - Oracle e-Business Suite (ERP): 55,000 - SAP (ERP): 130,000!

为了让这数量之多直观，这是 Oracle 电子商务套件特定安装的 42k 表 的样子：

示例 Oracle eBS (ERP) 42k 表列表

而这些表本身又大又复杂。这是该 Oracle 数据库的订单行表的列列表：

示例 Oracle 表的列

我希望它能让您了解查找数据或了解您正在查看的内容有多么困难。就好像您在曼哈顿寻找它一样（曼哈顿大约有 134,000 座建筑物）。

美国宇航局远征 10 号指挥官 Leroy Chiao 摄

您的数据位于其中一间公寓中。您甚至有一个地址 - 祝您好运！

您需要一张地图！

我希望我让您明白有数据并不足以使用它。如果你想使用你的数据，你需要一张地图。这个围绕您的数据库的地图称为数据字典。如果你还没有，你应该从今天开始构建它。

来自电影“外星人”（1986）的画面，J.卡梅隆