关系数据库是一种基于关系模型的数据库，是以显示世界中各个实体之间的关系为基础，来展现数据的数据库。用户定义完整性：用户自定义完整性是针对某一具体关系数据库的约束条件，它反映某一具体应用所涉及的数据必须满足的语义要求。以上是本次的数据库的学习笔记，可能会有一些不合理的地方，希望共同学习共同进步。
产品经理在产品功能设计，尤其是平台类产品设计的过程中，必然涉及到数据模型以及数据操作相关的设计。
在用户场景和功能层面来看，是一个个根据用户的使用场景设计的功能点。但是从数据层面来看，是根据用户在该场景内对产品输入的数据信息进行处理并输出结果的一个过程。
和数据结构相对应，数据库作为存储数据的容器，所有与产品相关的功能数据、用户信息、操作数据等都存储在数据库中。通过学习数据库，可以从数据视角看产品，更多地从数据存储、数据关联等方面来对产品进行剖析。数据库对于从事平台产品设计，或者数据产品的小伙伴来说，尤其重要。
本文将与大家分享数据库相关的基础知识，希望可以共同学习，共同进步。
一、基础名词理解
- 数据：“数据是对客观事物的符号表示，在计算机科学中指所有能输入到计算机中，并被计算机程序处理的符号的总称。”这是之前在数据结构篇中对数据的定义，那么结合数据库来理解，数据是数据库中存储的基本对象。
- 数据库：可长期存储在计算机内，有组织、可共享的大量数据的集合，具有永久存储型有组织和可共享三个基本特点。
- 数据管理：对数据进行分类、组织、编码、存储、检索和维护，是数据处理的中心问题。
数据管理从人工管理阶段，到文件系统阶段到现在的数据库系统阶段，最本质的差别在于：数据库管理做到了数据结构化。
举个例子来说：将数据库比喻成一个仓库，那么数据就是这个仓库中的货物，管理员对这些货物做分类整理、运输等操作，就是数据管理。数据结构化就是讲这些货物分类分等地排列在货架中，以便管理员能更好地进行管理。
二、数据模型
数据模型是对现实世界数据特征的抽象，是数据库系统的核心和基础，是数据结构化到一定程度的产物，是一种机构化数据的展现。
数据模型有概念模型，逻辑模型和物理模型三种：
- 概念模型：又称信息模型，是指按用户的观点来对数据进行建模，主要用于数据库设计。
- 逻辑模型：按计算机系统的观点对数据和信息建模，主要用于DBMS（数据库管理系统）的实现。
- 物理模型：对数据最低层次的抽象，描述系统内部的表示和取存方法。
以上几个模型的一般实现顺序与流程为：
数据模型有三大组成要素：数据结构、数据操作、数据的完整性约束条件。
- 数据结构：在之前的数据结构篇中有详细的介绍（产品经理的技术修行笔记——数据结构篇）。
- 数据操作：就是对数据库中的各种对象可执行的操作的集合，比较常见的为数据库的增删改查。数据操作在平台类产品中十分常见。比如：电商后台管理系统中，针对一个商品的信息进行修改，上传图片、更新库存，或者直接删除\新增商品，就是针对一个商品的数据操作。
- 数据的完整性约束：指的是为了防止不符合规范的数据进入数据库，在用户对数据进行插入、修改、删除等操作时，DBMS自动按照一定的约束条件对数据进行监测，使不符合规范的数据不能进入数据库，以确保数据库中存储的数据正确、有效、相容。比如：我们定义学生年龄字段的数据类型为整型，那么就无法将带有小数点的数字作为年龄插入之年龄字段中。
三、关系数据库
以最常见的关系数据库为例，对数据库相关的概念，操作以及和产品设计相关的知识进行整理。
3.1 基本概念
- 实体：客观存在并可互相区分的事物。
- 属性：实体所具有的某一特征。
- 码：唯一标识实体的属性集。
- 关系：实体之间的关系，主要可分多1：1、1：N、M：N三种。
为了更清晰地对以上几个名词进行理解，还是以学生和班级为例：
在这个例子中，学生和班级就是两个实体。学生的姓名、学号等就是学生的属性，学号作为唯一标识学生的属性，就是学生这个实体的码。
那么学生与班级之间的联系可以表示为N：1，因为一个学生只能在一个班级中，而一个班级中有多个学生。
一组关系组合在一起，就是关系模型。关系数据库是一种基于关系模型的数据库，是以显示世界中各个实体之间的关系为基础，来展现数据的数据库。每个关系的数据结构都可以用一张规范话的二维表来表示。一个关系通常对应一张表，每一列为一个属性。
3.2 关系数据库的完整性
- 实体完整性：实体完整性要求每个表都有唯一标识符，每一个表中的主键字段不能为空或者重复的值——即若属性A为基本关系R 的主属性，那么A不能取空。
- 参照完整性：参照完整性要求关系中不允许引用不存在的实体，设定相应的更新删除插入规则来更新参考表——即若属性（或者属性组）F还基本关系S的外码，它与基本关系S 的主码K对应，则对于R中每个元祖在F 上的至必须为1，空值为2，等于S中某个元祖的主码值。
举例理解一下，以课程表为例：
（1）课程表（课程ID、课程名、类型ID、学分… …）。
（2）课程类别表（类型ID、类型）。
这两个表之间存在着属性的引用——即“课程”表引用了“课程类别”表的主键“类型ID”。
按照参照完整性规则，“课程”表中每个元祖的“类型ID” 属性只能取下面两类值：
- 空值：表示该课程还未确定类别。
- 非空值：此时取值必须和“课程”表这某个元祖的“类型ID”值相同，表示这门课程归属该类别。
（3）用户定义完整性：用户自定义完整性是针对某一具体关系数据库的约束条件，它反映某一具体应用所涉及的数据必须满足的语义要求。
3.3 关系数据库的标准语言
SQL ：即结构化查询语言，是关系数据库的标准语言。
特点表现为：
- 综合统一；
- 高度费过程化；
- 面向集合的操作方式；
- 以一种语法结构提供多种使用方式；
- 语言简洁、易操作。
常见的操作语句有以下几种：
（1）定义基本表
create table <表名>
<列名> <数据类型> [约束条件]
<列名> <数据类型> [约束条件]
………
（2）修改基本表
alter table <表名>
[add <新列名> <数据类型> [约束条件]]——增加新的列和条件
[drop [约束条件]]——删除条件
[alter column <列名> <数据类型> ]——修改列定义
（3）删除基本表：
drop table <表名>
（4）数据查询
select [ALL|DISTINCT]<目标表达式>……——取消重复列
From <表名或视图名>……
[where <条件表达式> ]
[group by <列名1> [HAVING <条件表达式>]]
[order by <列名2> [ASC|DESC]
四、总结
虽然对于客户端产品经理来说，进行产品功能设计时并不需要去考虑数据库的设计，一般会有架构师或者核心开发来规划。但是需要明确的是：一个个产品功能最终是由数据通过产品设计的业务逻辑来展现出来的。
所以当技术提出，产品的需求影响了现有数据库的设计，或者完成这个需求需要改变数据库的结构时，产品经理需要从产品的现有功能和后期规划中来考虑有关数据的这两个问题：
- 新增的功能需要现有数据库所做的调整是什么，以及后期的规划中是否会有类似的调整，是否需要统一设计；
- 明确1的基础上，思考这个修改对原有的老版本产品功能是否会有影响。
对于平台类产品经理来说，对数据库的学习应该需要更加深入。因为平台在某种意义上来说，其实就是一个数据库操作系统。以视频类产品的资产管理后台为例：所涉及到资产管理，推荐管理等功能，其实都是对于资产等实体进行查询，修改等操作的过程。
以上是本次的数据库的学习笔记，可能会有一些不合理的地方，希望共同学习共同进步。
参考教材：数据库系统概论
作者：方小白，2年互联网产品经验，专注用户增长与会员运营。
本文由 @方小白 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
,
