数据建模是为了让数据更好地被理解、存储和使用。很多团队一上来就搞各种酷炫的技术架构却忽略了最底层的模型设计最后数据乱七八糟用起来也痛苦。今天我帮大家总结了数据建模最核心、最常用的四大方法点击收藏可随时查看开始之前给大家分享一份数据仓库建设解决方案里面包含了数仓的技术架构、数仓建设关键点、数仓工具等内容可以帮助大家更全面、深入地理解数据建模。需要自取下载https://s.fanruan.com/7igmg复制到浏览器目录一、范式建模二、维度建模三、Data Vault建模四、图建模五、数据建模有哪些具体应用一、范式建模范式建模的核心思想是消除数据冗余保证数据一致性。说白了就是把数据拆分成一个个最小单位的表并通过主键、外键让它们关联起来。具体来说范式建模需要依次满足第一范式1NF、第二范式2NF、第三范式3NF 的要求。1NF要求每个字段原子化不可再拆分2NF要求非主键字段完全依赖于主键而非部分依赖3NF要求非主键字段不传递依赖于主键即一张表中不能包含其他表的非主键字段范式建模最适合OLTP联机事务处理系统比如电商的订单系统、银行的交易系统这类高频增删改的业务场景。以电商订单业务为例我们会将订单信息、商品信息、用户信息拆分为三张独立的表订单表存储订单编号、用户 ID、订单金额等核心字段用户表和商品表分别存储用户和商品的详细属性通过外键关联实现数据联动。这样数据的一致性非常强更新操作只需在对应表中进行更新效率高无需修改多张表的冗余数据。但范式建模也有明显的短板复杂查询时需要多表关联尤其是涉及多业务实体的分析需求复杂度和资源消耗都非常大。二、维度建模正是因为范式建模在分析上的笨重维度建模应运而生。这是数据仓库领域最经典、应用最广的建模方法为了方便和快速查询它能接受一定的数据冗余。简单来说维度建模把表分为两大类事实表和维度表。事实表就是你关心的业务过程比如“下单”、“付款”、“点击”由可加性的度量值比如销售金额、商品件数和一堆外键组成。维度表就是描述事实的各个角度比如时间、商品、门店、客户。一个事实表被多个维度表所包围这就是经典的星型模型。如果把一些维度表再进一步规范化就变成了雪花模型。它的设计起点不是数据本身而是业务过程。所以它具有查询简单、性能高、对业务用户友好的优点。一个销售事实连着时间、商品、门店维度业务人员想怎么看就怎么关联。三、Data Vault建模业务总是在变有没有一种更灵活、更能适应变化的方法有这就是Data Vault建模。它是专门为数据仓库设计的一种范式把业务键、数据关系和数据本身的描述属性彻底分离并且一切都是可追加的不做更新和删除。这听起来有点抽象我来拆开说。Data Vault模型主要由三种类型的表构成中心表存储核心业务实体的唯一标识业务键比如客户ID、订单ID非常稳定。链接表存储中心表之间的关系。比如哪个订单属于哪个客户这就是一个链接。卫星表存储所有描述性属性。比如客户的姓名、地址、等级订单的金额、状态。卫星表通过时间戳来跟踪每个属性随时间的变化天然记录了历史。业务新增一个属性只需要在对应的卫星表里加字段完全不影响中心表和链接表。它不直接面向业务查询而是构建一个强大的、可追溯的数据基础层。四、图建模当你的核心问题是关系时比如社交网络中的好友推荐、金融中的反欺诈关联分析、供应链中的路径寻优传统的关系型表查询会变得异常低效。图建模将数据抽象为“节点”和“边”。节点代表实体比如人、商品、企业可包含属性关系代表节点间的关联比如朋友、购买、合作一个用户是一个节点一笔交易是一个节点而“购买”、“属于”、“朋友”就是连接它们的边。不过要注意关系类型定义要清晰避免模糊导致分析不准。合理设计索引提升关联查询效率控制节点和关系粒度不盲目细化避免结构复杂。五、数据建模有哪些具体应用真实的数仓很少是某种方法的单纯应用而是一个分层、混合的体系。1、数据仓库一体化建模数据仓库一体化建模更偏向企业级数据整合核心是打破数据孤岛统一数据口径。简单来说它就是把企业ERP、CRM、SCM 等各个业务系统的数据整合到统一数据仓库中按统一标准建模让不同部门使用的数据口径一致。​它的流程通常是梳理源系统业务流程和数据结构定义统一业务术语和数据口径接着设计统一模型架构抽取、转换、加载源系统数据到数据仓库形成统一数据集。​给大家分享一个我们团队正在用的工具FineDataLink它正好能解决一体化建模中的数据孤岛问题不管是本地数据库、云服务还是各类业务系统都能一站式接入能支持 40 多种异构数据源对接。通过简单拖拽就能完成数据清洗、字段映射和标准化转换还能自动校验数据质量、统一口径避免后续建模因数据不一致返工。它还能通过定时调度和监控告警实现数据实时同步让建模的基础数据更可靠。工具地址放在这里了感兴趣的可以试试看https://s.fanruan.com/tx4dw复制到浏览器2、数据湖与反范式建模数据湖存储了原始、海量但杂乱的数据。基于数据湖我们可以更自由地进行探索性建模。而反范式建模的核心是增加适当冗余提高查询效率。这种建模方法存储成本低而计算和查询的时间成本高。主要是做大数据分析、实时查询、非结构化数据处理比如电商用户行为分析、实时推荐系统、日志分析。如果你遇到过大数据查询时因表关联太多等待时间超长数据湖和反范式建模能有效解决这个问题。​3、数据仓库分层建模数据仓库分层建模不是独立方法而是一种架构思想几乎所有数据仓库项目都会用到它是按数据处理流程分层明确每层职责常见分层包括​ODS 层操作数据存储层存储源系统同步的原始数据不做过多处理保留原貌方便回溯​DWD 层数据仓库明细层对 ODS 层数据清洗、转换、标准化比如去重、补全缺失值、统一编码​DWS 层数据仓库汇总层这里混合使用维度建模和Data Vault的思想对 DWD 层数据汇总比如按日、周、月汇总销售额、用户数​ADS 层应用数据服务层面向具体应用的数据比如报表、BI 查询数据直接提供给业务人员。​大量使用宽表、汇总表等反范式手段目标只有一个让查询变得极快数据仓库、数据中台不管用哪种建模方法分层都是必要的。分层建模能让结构更清晰维护更简单。建模的终极目标是让数据清晰、准确、高效地服务于业务。希望这些数据建模的方法分享能对你有点帮助。