数据建模（Data Modeling）是“将现实世界中的数据进行抽象和提炼之后，用图形可视化的方式来描述数据和数据之间关系的设计工作”。对于初学者来说，掌握数据建模的基础理论，并不是很困难，特别是有一定技术背景的人。学习了数据模型的表示法之后，很容易就照猫画虎绘制出一个数据模型图来。
但是，在学习和设计的过程中，模型图是否正确？模型设计的好坏？就不见得会很笃定。会有一种数据模型设计很简单但又好像不是那么容易的感觉。
学习数据建模难不难？这个不好定义，不过，数据建模确实需要比较广的知识面，还需要不断地刻意练习。所以，对于初学者来说，短期想从入门到精通确实有点困难，不过也不至于让新人从入门到放弃。
▌学习数据建模要从看懂模型开始
暂且不说数据架构（Data Architecture）是什么，要学数据建模，第一步就要先看懂模型图，能够解读出数据模型中表达的数据结构和它们之间的关联性。
要看懂模型图，就要搞懂什么是实体（Entity）、什么是关系（Relationship）、什么是属性（Attribute）。学习的过程中，有个小Tips，就是要在脑中想象到数据存储的样子。
实体可以想象成一张二维表格，实体的属性就是这张二维表格的表头。而关系其实并不能直观地被看到，关系是通过两张二维表格中的某一个（组）属性建立的逻辑关联。这一个（组）属性就被定义为标识符（Identifier），它的作用就好像每行数据的“身份证”，通过标识符能区分出表格中的每一行数据。
例如，存储“员工基本信息”的表格中，有一个属性叫做“当前所属部门编号”，里面填写的是每个部门的“身份证”，就是“部门编号”。通过“部门编号”，到存储“部门基本信息”的表格中就能够找到对应的部门和部门的详细信息（部门的名称等）。
对于熟练使用Excel的人来说，“这不就是VLOOKUP吗？”，是的，就是这个函数，只要保证“部门编号”属性中的值是唯一的，那就一定能找对。这个时候，就可以说部门和员工之间是一对多关系，即，“部门基本信息”中的一行数据可以对应“员工基本信息”中的多行数据。而关系的种类并不多，也就是“一对一、一对多和多对多”三种，比较容易理解。
所以，数据模型图其实就是将这些二维表格中的数据进行描述，并建立起关系的一张图。只是，在设计的过程中，还会将很多其他的考虑因素融入设计的思考中，通盘考虑起来就不是那么容易了。
你看，建模并不那么难吧？是不是只要Excel表格设计得好，数据之间的关系能捋得顺，人人都可以是数据建模师（Data Modeler）。
▌概念、逻辑和物理设计三个阶段
“要给一个新的系统从0到1设计一个数据模型，要经历几个步骤？”
这个过程跟写一篇文章和一本书一样，在想好了要写什么主题之后，先要列一个大纲，明确文章主干的描述逻辑，前后呼应等等。然后，针对文章主干中的每一个部分、每一个段落仔细揣摩，详细说明。最终，发布出去之前还要对文章进行包装，包括内容的校对、样式的美化和专业的封面设计等。
数据建模的过程也是类似的，先要想好要设计什么，进行业务需求分析，就像思考文章的主题一样。然后，列大纲，梳理内容脉络，就是在建模中所谓的设计概念模型，概念模型就是模型的主干和主体框架，确认之后再对每一个部分进行详细设计，就是逻辑模型设计。最终，在物理设计过程中，要充分考虑数据库的一些技术特性，达到在数据库中创建物理表结构的程度。
这么看来，数据建模设计的过程也挺简单，但是，就像一本书的好坏取决于内容，模型的灵魂也是它所承载的内容和知识。
▌既要懂业务又要懂技术
从概念、逻辑到物理模型设计，最终到物理化（根据物理模型在数据库中创建表结构等）的过程看似简单，但是，对能力的要求还是很高的。
除了要具备数据模型绘制的能力以外，既要懂业务，将业务语言转换成数据语言，也要懂技术，将业务逻辑转换为技术可用的模型，否则就变成了一个不落地的模型。
而数据建模的过程中，并没有要求每一位建模师都要掌握全面的能力，每一个角色都有自己擅长的能力项，所以，可以通过分工合作的方式来协作完成。
数据建模的前期过程偏向于业务理解和模型表达的能力，越往后期越偏向于技术实现和应用的思考，对技术能力的要求也就越高。而实际建模的过程中，会通过划分阶段的方式，界定具备不同能力的角色的工作边界，根据技能树的特点选定角色参与设计。对于数据建模师来说，需要发挥非常重要的“连接”作用，能够理解业务和技术两种语言，把这个过程拉通。
所以，如果说一个“全栈”的数据建模师要具备哪些能力的话，从业务需求分析、产品设计、应用设计直到数据库性能优化的一整套技能都是需要的。
▌懂业务和技术以外，也需要软技能
刚刚说的能力算是硬技能，一名合格的数据建模师，还需要掌握一些软技能。
如果没有这些软技能，硬技能再厉害也会在整个设计工作的过程中举步维艰，导致的结果可能不仅仅是数据模型设计不好，还有很大可能导致项目难以收尾。（虽然这句话说得有点“危言耸听”）
那么，一名合格的数据建模师应该具备的软技能有哪些呢？至少在以下几个通用型的能力方面有所思考：
良好的沟通和表达能力
沟通和表达是一个通用性很强的软技能，各行各业都需要这样的“润滑剂”来解决信息不一致的问题。对于数据建模师来说，一个首要的任务就是拉通业务和技术，通过数据模型解决业务和技术之间存在“代沟”的问题。
在这个过程中，除了能够理解业务和技术语言，还要能够将自己所理解的关键信息，通过某种方式或工具表达出来，通过可视化的表达和具备同理心的沟通技巧才能推进模型设计工作。
通过现象看本质的能力
探寻本质需要一定的底层逻辑思维，无论是业务还是技术的专家，他们的描述是不是真实地描述了数据的形态？是不是真实的诉求？需要通过分析和设计的过程来探寻，这个过程往往要多问几个“为什么”，灵活地使用5WHY分析法会非常有帮助。
举个简单的产品需求的例子，客户反馈他需要一个电钻，想要在墙上钻个洞，那么，你会想去哪找个电钻给他？还是会想有什么办法可以在墙上钻个洞？这些可能都并不能解决本质问题，客户为什么要在墙上钻个洞呢？他可能只是想挂个东西，那是不是非得要钻个洞呢？
对现实世界进行提炼和抽象的能力
提炼和抽象都是归纳总结、寻找规律的能力，善于用集合的思维找到不同事物之间的共性。共性抽象必然会掩盖一些细节，但是符合人类的思考惯性，越是具象化的描述就越需要增加很多细枝末节，细枝末节一变多思考的复杂度就会增加，而描述的内容就越准确、清晰。
模型设计的过程就是在这种“虚”与“实”的过程中，不断地打磨数据模型这个“艺术品”。对于建模师而言，就要承担组织者的角色，先思考再行动，从细节中提炼共性，先抽象再具象。
统筹思考把控全局的能力
统筹把控，不仅需要建模师能力全面，还要经得起博弈和取舍。
概念模型更偏向业务视角，物理模型则要考虑技术实现的可行性，当业务需求和技术实现成本之间存在很大的差距时，这个问题如何抉择？业务上可能存在巨大的未来不确定性，而对技术而言，要实现功能就要满足一定程度的确定性，这个矛盾往往又很难两全其美。
而对数据建模师来说，要理解业务的本质，也要懂多种技术实现方案的优缺点，最终选择一个适合于业务特点的设计方式和实现方案。这个世界真的没有绝对的完美，最适合的就是最好的，场景一变，可能会有天差地别。
▌好的模型应该具备哪些特质
数据建模入门之后，常常会听到一种说法是“数据模型没有唯一的答案”。这句话说得对也不对。不过，起码体现了一点：在设计的过程中，数据模型设计的对不对和好不好的基准并不统一。
所以，数据建模师在掌握了丰富的技能之后，还要理解“如何评断什么样的模型是好的模型”？
我想，从数据模型的作用、实现和规范三个角度可以提炼出一个好的模型应该具备的最基本的特征。
这些评判的基准可以作为模型设计的指引，对新人来说还是非常有意义的。可以引导数据建模师和模型的读者们将关注点集中在关键的事项上，减少在设计和沟通过程中产生大量的、低价值的内耗。
当然，如果你要的是“权威”的模型评审指导性的内容，我建议你可以读读Steve Hoberman的《Data Model Scorecard》（中文译名：《数据模型记分卡》），这本书里有大量的专家建议。
从数据模型作用的角度来说，数据模型要能够准确地表达业务数据和业务逻辑。
相信这一点每一位建模师都很容易理解，设计完成的最终版数据模型要能够完整且正确地描述信息系统和业务需求中包含的数据，并且在逻辑模型中，通过模型图中充分地描述和表达业务规则、数据处理的具体逻辑。
从数据模型实现的角度来说，数据模型既要保证数据的完整性，也要保证可扩展性和性能。
模型设计的过程，必然要经历范式化（Normalization）的过程，它是逻辑模型设计中很重要的一项工作。范式化的理论在学习和理解的过程中需要付出一些成本，但它的目的就是为了保证数据完整性（Data Integrity），关于这个概念后续还会单独解读，暂且可以理解通过范式化的过程，可以降低数据存储的冗余，保证数据变更操作的准确。
除了完整性以外，数据模型也要具备“健壮”的特性，也就是可扩展性。数据模型就好像建筑物的地基，对后续工作的影响极大。业务需求跟随市场的变化而变化，有很大的不确定性，如果每次需求的变化，都需要对“地基”进行调整，导致大量的程序逻辑变动，这个成本太高了。
所以，好的数据建模师，在设计的过程中就会考虑未来业务变化的可能性，不能保证模型结构永远不变，但起码能够在预计系统使用的生命周期内将这个成本尽可能地降到最低。
好的模型也要保证数据处理的性能，这个特点貌似更偏向于物理模型设计阶段，但其实对于“全栈”建模师而言，在逻辑模型设计的阶段，就会有所思考。
要做到这一点，一方面要求数据建模师要结合应用架构中的一些信息，来判断应用的处理逻辑，考虑每一个实体在未来可能产生的数据量和各类数据操作的频率；另一方面，要求数据建模师综合考虑好在数据达到一定数据量时的应对方案，以及不同类型的数据查询操作性能需要通过什么样的技术手段来实现。
说到这，你可能会觉得考虑这些的话，对技术的要求也太高了吧？其实也还好，数据模型设计的过程中可以多跟技术牛人请教，相信他们一定会有很多方案传授给你，当理解了一些基本技术处理思维之后，其中也会有很多共同的特点可以总结出来，未来独立设计的过程中就会融会贯通。
从数据模型规范的角度来说，数据模型有一定的可读友好性，更好保证命名和表达方式的规范性。
模型本身也是一个创作型的工作，必然要具备一定程度的用户思维，不能只顾及数据建模师自己想法的表达，要多考虑最终数据模型读者的体验感。
说到体验感，就很容易理解了，在保证表示方法正确和规范使用的前提下，从布局、色彩等多种角度让模型看起来更舒服，让模型中的主次信息分明，让模型中的信息便于读者快速查找和使用。这些都是对一个优秀的数据模型“设计师”提出的基本要求。
模型中实体、属性和关系命名的规范性也很重要，在定义一个实体名称的时候，也要思考很多：不同角色对同一个“名词”的理解是否一致、是否容易产生歧义等。这样的问题都需要用心思考，否则如何体现“设计师”的“细致入微”呢？草草几笔略略带过，可能会导致未来付出更多的时间和精力。
▌从现在开始成为一名数据建模师
数据建模能力的通用性还是比较强的，它不仅是数据架构师的必备技能，产品经理、业务分析师和技术架构师都需要，可以称之为跨领域的技能之一。
数据建模也是学习一种思维方式，不要被对业务和技术领域的未知所束缚，因为，数据建模本身就是要逐步打破未知，将未知变为已知的过程。
当然，这个过程中也有很多小技巧可以帮助你加快成长的速度，就像在大模型热度如此之高的当下，即使不是艺术专业出身，不会使用一些设计软件，也可以快速生成“专业”的设计稿一样。
所以，别担心，只要不断地学习和探索，人人都可以成为一名优秀的数据建模师，而且，数据建模师的价值也并不会被AI取代。