Star-Schema设计对数据仓库至关重要吗？或者您可以使用其他设计模式进行数据仓库吗？
将星型模式用于数据仓库系统可以获得多种好处,在大多数情况下,将它们用于顶层是合适的.您还可以拥有一个操作数据存储(ODS) - 一种保持"当前状态"的标准化结构,并促进数据构造等操作.然而,在合理的情况下,这是不可取的.我有机会建立有和没有ODS层的系统,并且在每种情况下都有选择架构的具体原因.
如果不进入数据仓库架构的细分或启动Kimball vs. Inmon火焰战争,星型模式的主要好处是:
大多数数据库管理系统都在查询优化器中具有使用位图索引结构或 索引交点进行快速谓词解析的"星形转换"功能.这意味着可以在不解决事实表(通常比索引大得多)的情况下从星型模式中进行选择,直到选择得到解决.
对星型模式进行分区相对简单,因为只需要对事实表进行分区(除非您有一些圣经大的维度). 分区消除意味着查询优化器可以忽略不可能参与查询结果的请求,从而节省了I/O.
在星形模式上比在雪花上更容易实现缓慢变化的维度.
模式更容易理解,并且往往涉及比雪花或ER模式更少的连接.您的报告团队会因此而爱你
星型模式更易于使用,并且(更重要的是)可以使用Business Objects或Report Builder等即席查询工具.作为开发人员,您几乎无法控制这些工具生成的SQL,因此您需要尽可能多地为查询优化器提供帮助.星型模式为查询优化器提供了相对较少的错误机会.
通常,您的报告图层将使用星型模式,除非您有特殊原因不这样做.如果您有多个源系统,则可能需要使用规范化或雪花模式实现操作数据存储以累积数据.这更容易,因为ODS通常不会执行历史记录.在星型模式中跟踪历史状态,这比使用标准化结构更容易.规范化或雪花化的操作数据存储反映了"当前"状态,并且不包含超出数据固有的任何历史视图.
ODS加载过程涉及数据清理和符合,这对于规范化结构更容易.一旦您在ODS中拥有干净的数据,维度和事实负载就可以相对简单地使用通用或相对简单的机制跟踪历史记录(随时间的变化); 使用星型模式更容易做到这一点,许多ETL工具(例如)为缓慢变化的维度提供内置工具,并且实现通用机制相对简单.
以这种方式分层系统提供了职责分离 - 业务和数据清理逻辑在ODS中处理,星型模式负载处理历史状态.
有一个在有关datawarehousing litterature正在进行的辩论,其中的数据仓库架构的星型模式应当应用的设计.
简而言之,Kimball非常重视在数据仓库中仅使用Star-Schema设计,而Inmon首先想要使用规范化的3NF设计构建企业数据仓库,然后在数据集中使用Star-Schema设计.
此外,您还可以说Snowflake架构设计是另一种方法.
第四种设计可以是数据库建模方法.
星型模式用于实现对大量数据的高速访问.通过减少对可能针对主题区域进行的任何查询进行饱和所需的连接量来实现高性能.这是通过允许维度表中的数据冗余来完成的.
您必须记住,星型模式是仓库顶层的模式.所有模型还涉及仓库堆栈底部的暂存模式,还有一些模型还包括持久转换的合并暂存区域,其中所有源系统都合并到3NF建模模式中.各个主题领域都位于此之上.
顶级星型模式的替代方案包括变体,即雪花模式.Dan Linstedt提出的数据库建模也是一种可能需要进行一些调查的新方法.
关于星型模式的事情是它们是大多数人想要用数据仓库做的事情的自然模型.例如,很容易生成具有不同粒度级别的报告(例如,月份或日期或年份).将典型业务数据插入星型模式也很有效,这也是数据仓库的一个常见且重要的特性.
您当然可以使用您想要的任何类型的数据库,但除非您非常了解您的业务领域,否则您的报告可能无法像使用星型模式那样高效运行.
星型模式非常适合数据仓库的最后一层.你是如何到达那里的另一个问题.据我所知,有两个大阵营,比尔英森和拉尔夫金博尔.如果/当你决定选择明星时,你可能想看看这两个人的理论.
此外,一些报告工具非常喜欢星型模式设置.如果您被锁定在特定的报告工具中,那么可能会推动报告市场在您的仓库中的样子.
京公网安备 11010802040832号 | 京ICP备19059560号-6 