SQL 人的进阶职业-建模师

(来源：谷歌。侵删）

很多刚接触SQL的人，都发愁。这什么鬼东西，语法这么别扭，关键词前前后后，放哪哪报错。

等到入了门，SELECT,WHERE,FROM终于放对位置了，又开始发愁，CRUD这点鬼东西，一点技术含量都没有。什么时候才能坐上技术总监的位子，年薪50万呢。

别笑哈，不是一个人这么跟我反映了。

首先，我这里不是鸡汤学院，不鼓吹3个月脱班学习，年薪50万这种神话，哦，不，是鬼话。谁爱信，谁信去！

直接贡献上主题，下面介绍的职位，年薪50万不保证（996除外），但20万绝对可以拿到。那就是SQL人的进阶职位-建模师！

可能很多初学的朋友会对建模师很陌生，连CRUD都还没精通，玩建模是有些吃力的。观察了下我周边能够独挡一面的建模师，都是7-8年工作经验了，有些甚至是20年，25年。前几天还有同学在问，35岁的IT人都去哪儿了。今天我就来解开IT行业35岁那帮老年人的去向，一个个都是鬼故事。

本文不打算具体的讲解建模的工作和案例，如果大家感兴趣，可以搜索 Kim Ball （记得用谷歌,最差也得用bing)。今天只讲宏观概念，好让初学者有个方向。

什么是数据建模？

数据存放，有各种格式，比如平面文件(txt,csv)，结构化文件(xml, Json). 这类文件格式用于存储小量数据完全没有问题，用 excel 也能完全处理。但大量数据存放时，对于处理程序就不够友好了。比如 Json 文件，在处理没有数据的节点标签时，在处理内嵌子文档时，原本的处理程序就会失去可重复使用。

此时我们就要用到数据库来存放数据，利用数据库的特性来强化数据规范，方便数据的提取和分析。这个时候，我们就要用到建模。

从本质上分析，建模粗略的可以包含这些内容：

数据对象：表，行，试图，物化索引，立方体

数据对象之间的关联：一对多，多对多，星型与雪花型

规范规则：非空，小数位，长度，电话格式，邮件占位符，外联

这些内容或多或少在逻辑规则，法规审核和政策合规中起作用。当然也在数据的基础面给数据提供了完整性、安全性的保障。

两种常用的建模方式，大家需要熟悉：

1）Entity Relationship Model(E-R) 实体关系建模

2）UML (Unified Modelling Language) 统一建模语言

为什么数据要建模？

建模主要目的有这些：

-从业务角度出发，建模能够保障所有的数据需求都能够被正确记载，无死角的为业务提供详尽的信息

-从设计角度来看，建模的三种分层角色，即概念模型，逻辑模型和物理模型，能够为各层应用专员提供易懂、易用的数据结构

-数据模型结构为设计表、主外键以及存储过程等数据库对象，提供了完备的定义，而不是散落在开发人员的各个文件夹的脚本

-提供了可以部署到任意数据库的设计文档

-建模的过程，就是去除重复数据，找到必须数据结构的过程

-建模过程虽然费时费力，但从长远看，可以帮助企业快速、清晰、高效的部署数据库

数据模型的种类？

三种主要的数据模型：

1）概念模型（Conceptual ）：这类模型定义了数据系统包含的数据以及流程。通常这类模型由业务用户定义和维护。目的就是为了让所有的业务用户都能明白业务的数据表达和逻辑

2）逻辑模型（Logical）: 定义了与具体存储系统、数据库软件产品无关的实现，比如表结构，数据类型，关联关系表达式

3）物理模型（Physical）:将逻辑模型翻译并落实到关系型数据库系统实现上。由DBA，开发人员来设计

具体展开细说：

Conceptual Data Model

这一层主要的目标是定义实体、属性以及关系，并不带有某个商品数据库比如SQL Server,Oracle的实现。

举例：

客户（Customer）和 商品（Product）是两个实体。customer name, customer number 是 Customer 的两个属性

product name, price 是Product的两个属性

Sales 记录 customer 和 product 之间的关联关系

概念模型（Conceptual data model） 的特征：

-提供本企业范围内的业务概念

-这一层模型只为业务用户而设计，以方便这些用户理解为主

-概念模型的设计与具体的商用数据库软件无关，不会考虑到存储、服务器地址和并发数量等技术参数。主要落脚点在于业务用户即将看到的，且能理解的真实世界模型

Logical Data Model :

这一层模型，在概念模型(Conceptual Data Model)上添加一些技术元素，比如属性的数据类型，长度以及约束等，增加多个实体之间的关联关系表达式

这一层模型的优点很明显，就是承上启下，“上”即Conceptual Data Model, “下”即Physical Data Model . 在这一层，依然不会有任何的主键、代理键定义，但会对关联关系做调整

逻辑模型（Logical Data Model）特征：

-对数据做更多更细的描述性表达

-设计与具体商业数据库软件无关的模型

-属性都会标上数据类型与长度、精度

-符合3范式化设计

Physical Data Model :

物理模型在 Logical Data Model 基础上加上一些具体的数据库表现，比如主键，外键，索引，视图，为的是方便产生schema.

物理模型（Physical Data Model）的一些特征：

-从项目、应用的角度来定义数据的范畴，这份范畴可能也能用于其他项目或者应用

-约束了实体表之间的关联联系，包括笛卡尔基数和置空选项

-依据具体的商用数据库软件，定义数据的存储、服务器位置等项目配置

-字段必须定义清楚数据类型，长度和默认值

-主键、外键、视图，索引，访问权限和授权等皆在这一层定义

数据模型的优劣？

优势：

-模型的设计，就是为了使各个层面的应用用户都可以清晰的知晓其含义

-数据模型可以一键生成数据库对应的物理对象

-数据模型方便各个层面的用户可以无障碍沟通，确保每个用户都能理解业务逻辑

-模型的存在，使得ETL更加明朗清晰

-完整定义了数据源和数据目标

劣势：

-没有底层开发的介入，模型就不能正确指导业务的开展

-建模与导航系统相类似，能够指导每项细节工作的开发。因此对业务领域的掌握和开发技术一样重要

-一旦模型成型，就需要不停的迭代去完成哪怕是细小业务的改动

小结：

纵观上述建模的要素，一个玩SQL的入门汉，要进阶到数据建模师，SQL技巧过硬自不必说，对数据库特性以及强弱都要有十分的把握。更重要的是，还要能说人话，和业务人员都能很好的沟通。把整个数据应用的数据字典，能够通俗易懂的翻译给用户，让他们明白我们能做什么，不能做什么，什么做起来费劲，要花多少时间，尽量获得他们的支持，方便自己工作的开展。

参考文章：

1 - https://www.guru99.com/data-modelling-conceptual-logical.html

作者：Lenis

来源：有关SQL