数据仓库【什么是宽表?什么是窄表?宽表和窄表的区别、优点、缺点及各自用处】

     宽表:从字面意义上讲就是字段比较多的数据库表。通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表。由于把不同的内容都放在同一张表存储,宽表已经不符合三范式的模型设计规范,随之带来的主要坏处就是数据的大量冗余,与之相对应的好处就是查询性能的提高与便捷。这种宽表的设计广泛应用于数据挖掘模型训练前的数据准备,通过把相关字段放在同一张表中,可以大大提高数据挖掘模型训练过程中迭代计算时的效率问题。(一句话,空间换时间,便于训练迭代、减少表关联数量,修改少量数据时不需要该多张表)    
     窄表:严格按照数据库设计三范式。尽量减少数据冗余,但是缺点是修改一个数据可能需要修改多张表
宽表和窄表的建设该如何选择?
    这个问题相信纠结了很多从是数据库开发、数据仓库开发和后台开发人员;单单考虑这个问题,难给出一个绝对的答案;本人从事数据仓库开发工作到现在已经有一年半时间了,对于这个问题,我也曾经纠结过,但是是否有绝对的答案呢?事实上任何东西都没有绝对的说法。
考虑这样的一个问题,一个公司有这样的一个需求:
设计销售领域的订单事实表,该事实表应该包含哪些维度和度量?事实表和维表该分别如何去设计?
好了,我们把关键信息拿出来,首先我们要有维度包括:销售员、销售员所属部门、下订单的时间;度量:销售量;
那么,订单事实表,其实就是一个商品销售的清单;
依照这个思路,我们建立的第一个模型可能是以下这样的:
### 数据仓库中的概念及其区别 #### 的概念 是指在一个格中尽可能多地包含各种维度字段度量字段的信息。这种方式减少了多张之间的关联查询需求,提高了查询效率。然而,这也意味着单个记录可能占用较多的空间,并且当某些列更新频繁时会影响整体性能。 对于数据仓库而言,构建通常是在汇总层面上完成的,即将多个事实以及相应的维连接起来形成一张大而全的结果集。这样的设计有助于简化前端报工具的操作流程并加速响应时间[^1]。 ```sql SELECT t1.date, t1.product_id, p.product_name, SUM(t1.sales_amount) AS total_sales, COUNT(DISTINCT t1.customer_id) AS unique_customers, AVG(t1.rating) AS average_rating FROM sales_fact_table t1 JOIN products_dim p ON t1.product_id = p.id GROUP BY t1.date, t1.product_id; ``` #### 的概念 相比之下,则只保留必要的几个核心属性或指标,其他辅助性的描述信息会放在单独的关系型子里保存。这样做的好处是可以减少冗余存储空间浪费的同时保持良好的灵活性;缺点在于如果要获取完整的实体视图,则需要执行多次联接操作才能实现目标。 在实际应用场景下,更适合用于原始事务处理系统(OLTP),因为这类系统的特性决定了其更关注于高效地插入新纪录而不是复杂的数据检索过程。而在数据仓库环境中,虽然也存在一些情况适合采用结构,但在大多数情况下还是倾向于创建以便优化读取速度服务最终用户的分析请求[^2]。 #### 主要差异总结 | 特征 | | | | --- | --- | --- | | **定义** | 将来自不同源系统的大量字段整合到单一内 | 只有少量的关键字段被放置在同一张上 | | **优点** | 提高查询效率<br>便于理解整个业务逻辑 | 减少重复数据<br>易于维护扩展 | | **缺点** | 占用更多磁盘资源<br>难以适应快速变化的需求 | 查询时需做额外的Join操作<br>不利于直接展示综合信息 |
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

程序员学习圈

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

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

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

打赏作者

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

抵扣说明:

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

余额充值