需求概述：

需求概述：将基础表的数据进行初步处理

核心需求：仅对于单个基础表的数据，做简单可追溯的处理。

核心设计要素：对象：基础表，操作：行列转换、单列处理

功能流程：

选择基础表—选择处理方式—添加基础表处理—更新原有基础表

BrainStroming:

基础表操作基本需求

在上述思考框架中，先基础表的定义入手，思考我们建立的基础表的意义为何，基础表作为我们整个数据分析的基础，是整个数据的原始面貌，可以理解为原始数据的永久保留，让我们在未来基于此做的任何操作都有根源可寻。

从这个意义中，我们可以确定整个基础表的边界，作为数据的原始存储，基础表的操作一定是克制，简单，最大可能贴近数据的原始面貌，此时对于数据进行过度处理是不合理的，会导致后续问题无法追溯。

字段类型

先设定好边界，那我们来看基础表可以进行哪些操作，从最小颗粒度的元素出发，列，每一列拥有不同数据类型，针对数据类型，我们可以进行类型修改/字段的选择。基础是什么，我们如何定义字段类型，也就是说针对数据表列的多种类型，我们如何映射到我们的字段类型上。

以mysql为例，分为Text包含CHAR、VARCHAR、TINYTEXT等，NUMBER包含INT、BIGHT、FLOAT等，DATA包含DATA、DATATIME、TIME等，在我们的系统中可以对应设计字段类型，初步定义为，文本、数字、日期。我们可以让用户对于基础表的字段在上述三个类型中进行转换。

行转列

再看行与列的关系，我们需要提到一种数据库设计的一些思路，我们的基础表是从最原始的数据表内容中获取的，与原始的设计是一致，那么在原始设计中，事实表与维度表的设计理念和数据更新的逻辑，对于我们是这一层面的用户来说，是缺乏可读性。做一个行转列的操作，符合当前语境下的需求。

举例说明：

用户课程分数事实表SC与维度表Course

userid	course	score
1	01	60
1	02	70
2	01	70
1	03	90

course_id	course_id
01	语文
02	数学
03	英语

将事实表行转列

示例SQL：

SELECT
SC.userid,SUM(case when SC.course = '01' then SC.score) As course_01,
SUM(case when SC.course = '02' then SC.score) As course_02,
SUM(case when SC.course = '03' then SC.score) As course_03
FROM SC
GROUP BY userid

userid	course_01	course_02	course_03
1	60	70	90

单列层级化索引

另外对于单列的内容，存在如下情况

org_id	名称
01	上海公司
0101	上海公司市场部
010101	孙洋

最终的实现效果是

cor_id	dep_id	emp_id
01	0101	010101

在一列中的内容其实隐含了多层级关系，我们需要根据单列内容去创建多列，最终形成层次化索引。

在上述表的案例中，我们可以看到三部分的层级关系，公司-部分-员工，在这个场景中的层级关系实质是一个树状机构，但是员工这一节点的id内容已然包含的整个分支的全部信息，无需使用递归去拼整个分支。

根据需求进行分析，整体逻辑如下，第一我们需要定义分层依据列与分层结果列，即我们需要根据哪一列创建层级关系与对应的数据，第二我们需要识别，该列可能存在层级类别，类别的划分依据可能为——相同的数据长度，第三我们需要进行宽表处理，根据员工为key，生成明细表，最后将明细表依据多层级的多个类别做group by。

cor_id	cor_name	dep_id	dep_name	emp_id	emp_name
01	上海公司	0101	上海公司市场部	010101	孙洋

冗余字段可选择性处理

cor_name	dep_name	emp_name
上海公司	上海公司市场部	孙洋

衍生需求

基础表作为我们数据源的原始内容抽取，通常是分散的，以数据库设计为准则的，我们在日常使用中，需要同一业务的，同一场景的多个数据表面向主题进行聚合，方便我们日常进行使用，同时基于数据表的组，也便于进行更高层面的权限控制于数据管理。

基础表的****管理

基础表的管理方式以“文件夹”的形式进行打组处理，本质也是一个树桩的结构去存放基础表。

以FineBi为例子，可采用两种层级类别，分组与业务包

分组：作为业务包的分组划分，分组内下可添加分组，业务包

业务包：作为基础表的分组划分，业务包下可添加基础表等数据内容。

思考：在分组下可能包含业务包或分组，当包含分组时，我们的任何配置操作都可能递归到最深的节点，所以在此考虑，不建议对于分组执行更新等业务操作。

基础表的刷新

基础表的刷新：指对于基础表的数据的刷新，重新进行文件获取/数据库表获取/SQL查询，

刷新的要素：刷新的范围（目标）/刷新的频率/何时刷新

从刷新的范围我们需要让用户定义，我们所需要刷新的基础表的范围，基于上述基础表管理的设置，用户可能刷新某一基础表，同时也可能需要对于整个业务包进行修改，我们需要在不同的层次为用户提供刷新功能。

刷新的频率：刷新的频率是为了将刷新变为定时的任务，用户可以一次设置任务，让刷新操作自动执行。

何时刷新：刷新操作的诱因是什么，我们可以想到，刷新的诱因是数据源的变化，这部分我们需要为用户设置提醒，需要思考的是，我们如何判断出数据源发生变化。

核心流程：用户接到更新提醒/想要更新基础表内内容—找到对应基础表—手动更新/配置更新设置——完成更新。

数据权限的划分

数据权限的划分：基于先前建立的各种层次，往下以此设置，从分组—业务包——基础表

-行/列。

依据我们数据内容本身存放的层次结构，去设置用户数据权限。

但是前提我们需要拥有对应的用户分组设计，因为我们不可能为每个用户单独配置数据权限。

用户分组设计详见：——————————————————

定义数据权限类型：查看/使用/编辑

查看指：用户可以查看制定数据集合，查看表内容。

使用：指基于数据集合内的基础做分析操作

编辑：对于数据集合内的组划分与基础表的做编辑操作。

核心流程：选择用户集合—找到数据集合—配置多个或一个权限—完成配置