BI业务中的宽桌子很多。每当构建BI系统时，您需要做的第一件事就是准备一张宽桌子。有时，系统中的宽表可能具有数百个字段，由于太宽了数据库表的限制。

为什么人们如此热衷于创建宽桌？有两个主要原因。

一个是提高查询性能。通常，Modern BI将关系数据库作为后端，但是Hash JOIN算法的计算性能通常采用时采用的算法会急剧减少，当表格和关联的级别增加时，只有七或八个现象可以观察到这种现象桌子和三个或四个级别。但是，BI业务的关联复杂性远远超过了该规模，如果直接使用SQL的JOIN算法执行查询任务，它将无法满足查询要求立即在前端获得结果。为了避免关联引起的性能问题，它需要从查询阶段消除关联，也就是说，提前将多个表关联并将其存储在单个表中（即宽表）。这样，在查询时无需再次关联，从而提高了查询性能。

另一个是减少业务困难。因为在采用自动关联（基于诸如现场类型之类的信息）时，很难表达和使用多桌子关联，尤其是在BI前端的复杂关联，当面对相同的字段时，系统会感到困惑维度（例如，一个表具有2个以上的区域字段），并且不知道应该关联哪个字段。同样，也很难处理表末端的表或自我关联之间的循环关联。如果向用户开放了许多表格，允许他们自己交往，那么几乎没有用，因为他们无法理解表之间的关系。尽管逐步协会可以描述复杂的关联要求，但是一旦上一步出错，就必须从头开始完成。因此，无论采用哪种方法，无论是在实践还是用户操作中都非常麻烦。相反，如果它是一张表，并且企业用户没有运营的障碍，这将非常简单。因此，将多个表组织到宽桌子中是很自然的。

但是，一切都有两个方面。当我们在意识到其优势之后广泛应用宽表时，我们不应忽略其缺点。一些缺点将对该应用程序产生重大影响。以下是几个缺点。

宽桌子的缺点

数据冗余，容量较高

宽表不符合数据库规范，并且将多个表连接到单个表中时存在许多冗余数据。冗余度与原始表的数据量和表之间的关系有关。通常，如果有多层外部钥匙表，则冗余度将成倍增加。大量的冗余数据不仅给存储带来压力（从多个表连接的宽表的字段数可能很大），从而导致数据库容量问题，而且会影响计算性能，因为如此庞大的冗余数据参与查询计算。结果，即使使用宽桌，查询仍然很慢。

数据错误

由于宽表不符合3NF，因此在数据存储期间可能会出现一致性错误（肮脏的写作）。例如，同一销售人员在不同的记录中可能具有不同的性别。在不同记录中，同一供应商所在的区域可能有所不同。基于此类数据进行的分析的结果肯定是不正确的，并且隐藏了此类错误，很难找到。

此外，如果未正确构建宽表，将发生聚合误差。例如，当基于一对多表A和B构建宽表时，如果表A中有计算索引（例如数量），则它们将在宽表中复制，并根据重复索引进行汇总会导致错误。

灵活性不佳

本质上，宽表是按需建模的一种手段。但是，当宽度表是根据业务需求构建的（尽管从理论上讲是可以组合所有表以形成宽桌子的情况，但这仅在理论上存在。如果您这样做，您会发现所需的存储空间是如此很大的是，它完全无法接受），这是一个矛盾：构建BI系统的最初意图是满足灵活的业务查询的需求，即，您不会事先知道业务需求。但是，在业务开发过程中引起了某些查询要求，用户暂时需要一些查询要求，这种灵活和不断变化的要求与解决方案（宽表）非常矛盾，需要提前处理。结果，如果您想要宽桌子的优势，则必须牺牲灵活性，不能同时获得两者。

低可用性

除了上述问题外，宽表还可能导致过多的领域导致较低的可用性。事实表将对应于多个维表，一个尺寸表可能具有其自身的维表，并且表之间可能存在自我关联 /周期关联关系。这种结构在数据库系统中非常普遍。当创建基于具有这种结构的表的宽表时，尤其是在表达多个级别时，宽表的字段数量将大大增加，通常达到数百个字段（某些数据库表限制了字段数，在这种情况下，宽表需要水平拆分）。想象一下，如果在用户访问接口上出现数百个字段，如何使用它们？这是宽桌子带来的低可用性问题。

总的来说，在许多情况下，宽桌子的缺点大于其优势。然后，为什么宽桌仍然占上风？

因为没有其他方法。没有比宽桌更好的解决方案来解决之前提到的查询性能和业务困难问题。实际上，只要解决这两个问题，就可以消除宽桌子，并相应地消除了各种问题。

SPL+DQL消除了可释放的

可以借助开源ESPROC SPL实现此目标。

SPL（结构化过程语言）是一种开源的结构化数据计算引擎，具有固有强大的计算能力，不取决于数据库，并且已构建了许多高性能算法，特别是优化的关联操作。您可以为不同的关联方案选择不同的方法，从而大大提高了关联性能。因此，也可以在没有宽表的情况下实现实时关联，以满足多维分析中的及时性需求。此外，SPL提供了高性能存储方案。通过这些方案及其有效算法，可以进一步利用SPL的性能优势。

仅高性能是不够的，SPL的本机计算语法不适合连接到多维分析应用程序（生成SPL语句需要经常修改BI系统）。当前，大多数多维分析前端都是基于SQL开发的，但是SQL系统很难描述没有宽表的复杂关联。因此，SPL设计了用于构建语义层的专业SQL式查询语法DQL（尺寸查询语言）。首先，在前端生成DQL语句，然后将其在DQL Server上转换为SPL语句，接下来，基于SPL计算引擎和存储引擎查询，最后将结果返回到前端。此时，实现了全链接BI查询。应该注意的是，SPL仅用作计算引擎，并且前端接口仍应由用户（或选择相关产品）实现。

SPL：协会实施技术

doesspl如何实现实时关联的目标而没有宽桌来满足性能要求？

在BI业务中，绝大多数加入是同等的联接（即，其关联条件是方程式的联接）。 SPL将等效的加入到外国密钥协会和初级密钥协会中。 外国密钥协会是指使用一个表的非主要密钥字段与另一个表的主要密钥相关联，前者称为“事实表”，后者称为“事实表”维度表。这两个表处于众多关系中，例如订单表和客户表。 主密钥关联是指使用一个表的主键将主要密钥或另一个主键的一部分关联。例如，客户表和VIP客户表（一对一），订单表和订单详细表（一对多）。

两种类型的连接都涉及主键。如果此功能已充分利用，并且采用了不同的算法，则可以实现高性能实时关联。

不幸的是，SQL的JOIN定义不涉及主键，它只是两个桌子上的笛卡尔产品操作，然后在特定条件下进行过滤。这个定义简单而广泛，几乎描述了所有内容。但是，如果严格遵循此定义以实施加入，则无法通过在计算过程中利用上述功能来提高理论上的性能，并且在实践中只能进行有限的优化，但是当这种优化往往是无效的情况很复杂（许多表，许多级别）。

SPL更改联接的定义，并分别处理两种类型的连接。通过这样做，可以利用主键的特征来减少操作负载以提高计算性能。

外国密钥协会

与SQL不同，SPL清楚地区分了尺寸表和事实表。 BI系统中的尺寸表通常不大，您可以预先将其读取到内存中以创建索引。这样，可以在关联期间将哈希值的计算减少一半。

对于多级维度表（尺寸表具有其自身的尺寸表），您可以使用外键通讯技术技术 pre-ssococotiate ，也就是说将尺寸表的外键字段值（顶层的表）转换为相应的维度表（外键表）记录的地址。这允许在无需计算和比较哈希值的情况下直接将关联的维度表的数据直接获取。在多级维度表中花费的额外时间仅仅是通过地址获取值的时间，并且关联性能基本上与一级维度表相当。

SELECT
 ct1.area,o.emp_id,sum(o.amount) somt
FROM
 orders o
 JOIN customer c ON o.cus_id = c.cus_id
 JOIN city ct1 ON c.city_id = ct1.city_id
 JOIN employee e ON o.emp_id = e.emp_id
 JOIN city ct2 ON e.city_id = ct2.city_id
WHERE
 ct2.area = 'east' AND year(o.order_date)= 2022
GROUP BY
 ct1.area,  o.emp_id

SELECT
 cus_id.city_id.area,emp_id,sum(amount) somt
FROM
 orders
WHERE
 emp_id.city_id.area == "east" AND year(order_date)== 2022
BY
 cus_id.city_id.area,emp_id