产品经理在产品功能设计,尤其是平台类产品设计的过程中,必然涉及到数据模型以及数据操作相关的设计。
在用户场景和功能层面来看,是一个个根据用户的使用场景设计的功能点。但是从数据层面来看,是根据用户在该场景内对产品输入的数据信息进行处理并输出结果的一个过程。
和数据结构相对应,数据库作为存储数据的容器,所有与产品相关的功能数据、用户信息、操作数据等都存储在数据库中。通过学习数据库,可以从数据视角看产品,更多地从数据存储、数据关联等方面来对产品进行剖析。数据库对于从事平台产品设计,或者数据产品的小伙伴来说,尤其重要。
本文将与大家分享数据库相关的基础知识,希望可以共同学习,共同进步。
数据管理从人工管理阶段,到文件系统阶段到现在的数据库系统阶段,最本质的差别在于:数据库管理做到了数据结构化。
举个例子来说:将数据库比喻成一个仓库,那么数据就是这个仓库中的货物,管理员对这些货物做分类整理、运输等操作,就是数据管理。数据结构化就是讲这些货物分类分等地排列在货架中,以便管理员能更好地进行管理。
数据模型是对现实世界数据特征的抽象,是数据库系统的核心和基础,是数据结构化到一定程度的产物,是一种机构化数据的展现。
数据模型有概念模型,逻辑模型和物理模型三种:
以上几个模型的一般实现顺序与流程为:
数据模型有三大组成要素:数据结构、数据操作、数据的完整性约束条件。
以最常见的关系数据库为例,对数据库相关的概念,操作以及和产品设计相关的知识进行整理。
为了更清晰地对以上几个名词进行理解,还是以学生和班级为例:
在这个例子中,学生和班级就是两个实体。学生的姓名、学号等就是学生的属性,学号作为唯一标识学生的属性,就是学生这个实体的码。
那么学生与班级之间的联系可以表示为N:1,因为一个学生只能在一个班级中,而一个班级中有多个学生。
一组关系组合在一起,就是关系模型。关系数据库是一种基于关系模型的数据库,是以显示世界中各个实体之间的关系为基础,来展现数据的数据库。每个关系的数据结构都可以用一张规范话的二维表来表示。一个关系通常对应一张表,每一列为一个属性。
举例理解一下,以课程表为例:
(1)课程表(课程ID、课程名、类型ID、学分… …)。
(2)课程类别表(类型ID、类型)。
这两个表之间存在着属性的引用——即“课程”表引用了“课程类别”表的主键“类型ID”。
按照参照完整性规则,“课程”表中每个元祖的“类型ID” 属性只能取下面两类值:
(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]
虽然对于客户端产品经理来说,进行产品功能设计时并不需要去考虑数据库的设计,一般会有架构师或者核心开发来规划。但是需要明确的是:一个个产品功能最终是由数据通过产品设计的业务逻辑来展现出来的。
所以当技术提出,产品的需求影响了现有数据库的设计,或者完成这个需求需要改变数据库的结构时,产品经理需要从产品的现有功能和后期规划中来考虑有关数据的这两个问题:
对于平台类产品经理来说,对数据库的学习应该需要更加深入。因为平台在某种意义上来说,其实就是一个数据库操作系统。以视频类产品的资产管理后台为例:所涉及到资产管理,推荐管理等功能,其实都是对于资产等实体进行查询,修改等操作的过程。
以上是本次的数据库的学习笔记,可能会有一些不合理的地方,希望共同学习共同进步。
参考教材:数据库系统概论
作者:方小白,2年互联网产品经验,专注用户增长与会员运营。
本文由 @方小白 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议