Practical Ontologies & How to Build Them - Part 1
文章摘要
本文是关于本体论在数据建模中应用的四部曲系列文章的第一篇。我们从本体论的基本概念出发，探讨其与数据库设计的关系，特别是在规范化过程中的本体思维。通过大学课程注册表的例子，详细讲解了从第一范式（1NF）到第三范式（3NF）的设计过程，并强调本体论如何帮助描述业务核心操作。目标读者为企事业单位及科研院所的专家和投资人。
正文
一、引言：本体论与数据建模
在数据驱动的时代，构建高效且有意义的数据模型是企业运营和科研创新的关键。本体论（Ontology）作为一种描述特定领域内概念及其关系的框架，不仅是哲学中的一个分支，更是现代数据分析和数据库设计的重要工具。本文将带您深入了解本体论的基本概念，以及如何将其应用于数据建模中，帮助组织更清晰地理解和管理其数据资产 。
本体论一词源于希腊语"ontos"，意为"存在"，在学术研究中关注"是什么"的问题。在数据分析领域，自1970年代数据库规范化设计兴起以来，本体论的概念就已被数据库架构师广泛采纳。本文将通过一个四部分的系列，探讨本体论如何描述并驱动企业的核心业务操作 。
在本系列中，第一部分聚焦本体论的基本概念与数据建模的关系；第二部分将介绍如何在Palantir Foundry平台上创建本体论；第三部分探讨时间序列数据在本体论中的应用；最后一部分将关注"行动"（Actions）在本体论中的作用及其在数据运营中的重要性 。
二、本体论思维与数据库设计
从定义上看，本体论是一个特定领域内的概念或类别集合，以及这些概念之间的关系。在数据库设计中，本体论思维的典型体现之一是设计符合第三范式（3NF）的数据库。通过不断提高对数据库表的要求，将数据拆分为更小但更独立的概念单元，从而便于理解和操作 。
2.1 数据库范式化：从1NF到3NF
数据库的范式化（Normalization）是指通过一系列严格要求，将数据表分解为更小、更易管理的单元，以减少数据冗余并避免更新异常。以下以一个大学课程注册表为例，逐步讲解从第一范式（1NF）到第三范式（3NF）的设计过程 。
第一范式（1NF）
1NF要求所有表具有主键，每行数据唯一，且每个单元格的值是原子化的（即不可再分）。例如，假设我们有一个描述学生选课的表格，其中包含学生ID、课程ID等信息，但课程相关属性被分组为数组，这违反了原子性要求 。
表格：未符合1NF的表格示例，显示学生选课信息以数组形式存储
将其调整为1NF后，每行数据唯一，采用复合主键（学生ID和课程ID），并将数组拆分为单独的行。
通过这一过程，我们无意中做出了一个本体论声明：我们描述的概念是"注册"（Enrollment），即学生与课程的组合 。
表格：调整为1NF后的表格示例，显示拆分后的学生选课信息
第二范式（2NF）
1NF的表格仍未达到2NF的要求。2NF要求表中的每一列必须依赖于主键的全部组成部分（如果主键是复合主键）。在上述1NF表格中，学生姓名（Student_Name）依赖于学生ID（Student_ID），课程名称（Course_Name）依赖于课程ID（Course_ID），但两者之间没有依赖关系 。
例如，若学生ID变更，学生姓名可能会更新，但课程名称不受影响。这种部分依赖导致数据更新效率低下，尤其当表格规模扩大时。为达到2NF，我们将学生和课程属性拆分为独立的表，即"学生"（Students）和"课程"（Courses），并保留"注册"（Enrollments）表作为关联 。
表格：2NF设计中的"学生""课程"和"注册"表
第三范式（3NF）
2NF结构中仍存在传递依赖问题，即非主键列依赖于其他非主键列。例如，在"课程"表中，讲师姓名（Instructor_Name）依赖于讲师ID（Instructor_ID），而不是直接依赖于课程ID（Course_ID）。为消除这种传递依赖，我们进一步将讲师信息拆分为独立表"讲师"（Instructors），并更新"课程"表，仅保留讲师ID作为外键 。
表格：3NF设计中的"讲师"和更新后的"课程"表
通过构建3NF表示，我们实际上设计了一个本体论模型，明确了数据背后涉及的实体（如学生、课程、讲师和注册）及其关系。这种本体论思维与范式化设计有显著的重叠，但侧重点不同：本体论更关注数据所代表的现实世界实体和关系，而范式化更注重减少冗余和避免技术问题 。
三、本体论作为声明：关注业务的重点
设计或更新本体论的过程，实际上是组织对自身关注的对象、事件、关系和属性的声明。这不仅是技术层面的工作，更是一个机会，通过深思熟虑的设计选择，简化和澄清数据景观。以下是在设计本体论时需要考虑的关键问题 ：
3.1 新增或更新对象时的思考
-
是否需要此对象类型？
新增对象是否能提升本体论所描述的概念景观的可见性，还是可能使其更加复杂？
-
抽象层次是否合适？
对象是否提供了合适的属性存储位置，避免传递依赖？例如，是选择"车辆"（Vehicles）作为对象，还是细分为"汽车"（Cars）、"摩托车"（Motorbikes）和"公交车"（Busses）？
-
命名是否清晰直观？
对象名称是否能明确描述其代表的概念？
3.2 新增属性时的思考
-
属性是否属于该对象？
新增属性是否真正属于所附加的对象，还是与其他对象的属性重复？
-
属性命名是否描述性强？
名称是否直观易懂，便于理解和使用？
-
数据类型是否合适？
数据类型的选择是否考虑了上下文和用途？例如，日期（Date）与时间戳（Timestamp）的区别 。
3.3 新增或更新关系时的思考
-
关系类型是什么？
是"一对一"（如学校与现任校长）、"一对多"（如车辆与近期维修记录），还是"多对多"（如课程与助教）？
-
是否重复已有链接？
当前本体论中对象间的关系是否已存在，避免重复建立链接。
-
命名如何直观易用？
关系名称是否便于理解和操作？
-
是否满足用户遍历需求？
是否提供了足够的链接，使用户能按预期遍历本体论？
通过这些问题，设计者可以在构建本体论时，确保其不仅技术上合理，更能反映业务的核心需求和操作逻辑。
四、未来展望：Palantir Foundry中的本体论构建
在本系列的第二部分，我们将深入探讨Palantir Foundry平台中的本体论概念，以及如何构建一个操作性强的本体论。我们将结合组织的数据景观，提供实用方法，快速达成实用解决方案。此外，后续文章还将讨论时间序列数据、对象与事件的关系，以及通过"行动"实现数据运营化 。
五、总结
本体论不仅是哲学中的一个概念，更是数据建模和数据库设计的核心思维方式。通过从第一范式到第三范式的设计过程，我们可以看到本体论如何帮助清晰地描述现实世界的实体和关系，从而提升数据管理效率。设计本体论的过程，也是组织对其业务重点的声明，是梳理数据景观、优化运营逻辑的重要机会。
对于企事业单位和科研院所的专家及投资人而言，理解和应用本体论，不仅能提升数据资产的价值，更能在数字化转型中占据先机。欢迎持续关注本系列文章，探索更多关于本体论构建与应用的实践经验。
标签
#本体论 #Ontology #数据建模 #DataModeling #数据库设计 #数字化转型
欢迎加入「知识图谱增强大模型产学研」知识星球，获取最新产学研相关"知识图谱+大模型"相关论文、政府企业落地案例、避坑指南、电子书、文章等，行业重点是医疗护理、医药大健康、工业能源制造领域，也会跟踪AI4S科学研究相关内容，以及Palantir、OpenAI、微软、Writer、Glean、OpenEvidence等相关公司进展。