大家好！今天让小编来大家介绍下关于数据产品设计_数据产品设计的关键流程的问题，以下是小编对此问题的归纳整理，让我们一起来看看吧。

文章目录列表:

• 1、如何设计动态字段的产品数据库表
• 2、大数据系统体系建设规划包括哪些内容
• 3、【科普】企业中，大数据部门的常见组成
• 4、有成千上万种产品,各个产品属性不同,怎么设计数据库或设计页面加载不同属性

一、如何设计动态字段的产品数据库表

可以采用四种技术：
动态增加数据库表字段
预留足够的空白字段，运行时作动态影射
用xml格式保存在单字段里
改列为行，用另外一个表存放定制字段
【一】
现在我们来分析一下四种技术的优劣，不过首先可以排除的是第一点动态增加字段的方法，因为在实际操作时候几乎是不可能的（sqlserver太慢，oracle索性不支持），基本可以不讨论就排除。剩下后三点。
【二】
先来讨论预留空白字段的方法，基本原理就是在数据库表设计的时候加入一些多余的字段，看下面的代码：
CREATE TABLE Sample(
name varchar(12),
field0 varchar(1),
field1 varchar(1),
fieldN varchar(1)
}
然后看实际运行时候的需要，动态分配字段给系统使用，也许需要一个这样的结构来描述分配情况：
public class Available
{
public int CurrentUnusedFieldNumber;
public Hashtable FieldToRealName;
}
也许某一时刻的数据状况是这样的： CurrentUnusedFieldNumber=3,
哈西表FieldToRealName包含内容是("field0"="SomeId", "field1"="AnyName",
"field2=IsOk")
现在的问题是如果要配合Hibernate，如何来处理？以上段的数据使用状况为例子，如果我们的类定义是这样：
public class Entity01
{
public string Name;
public string SomeId;
public string AnyName;
public bool IsOk;
}
也许只需要修改一下xxx.hbm.xml，把 SomeId 和 field0
做成对应就ok了。但是在运行时我们怎么知道会有这样的类定义？除非我们做动态代码生成，自动编译也许可以，但是问题也许就到其他方面去了；如果我们不用动态定义，那么类就只能是这样：
public class Entity01
{
public string Name;
public Hashtable ExtraFieldAndValues;
}
使用的时候，用 entity01.ExtraFieldAndValues.setValue("AnyName", "boss")
的方式来引用，也许这样是修改最少的了，但是问题是Hibernate不支持这样的方法。
【三】
再来讨论单字段存储的方法，我们使用这样的数据库表定义
CREATE TABLE Sample
(
Name varchar(12),
Xml CLOB(102400) // 仅作说明而已
)
然后对应这样的类定义
public class Entity01
{
public string Name;
public string Xml;
public Hashtable ExtraNameAndValueFromXml;
}
我们的代码就可以这样使用：string id =
entity01.ExtraNameAndValueFromXml.getValue("SomeId")
了。这样解决看起来很不错，不仅不需要Available表，而且看起来Hibernate对它的支持也很完美，但是致命的问题在于：如果保持高效的查询？除非数据库系统本身对此有支持，否则就只能用低效的substring或者like做查询，这在大批量数据中根本就不可行。
是不是折衷一下，把两种方法的优点和起来？问题有来了：怎么保持两者之间数据的同步？难道要我们用存储过程去解析xml内容？
所以，一个两难的问题，需要我们认真去解决。我们通过认真的需求分析，也许可以减少可变字段的数量，但是只要有一个可变字段或者可变的可能性存在，我们始终要去解决这个两难的问题。
期待继续讨论。
【四】
还有一种方法就是改列为行，用另外一个表存放扩展字段，定义可以如下：
CREATE
TABLE SampleFields
(
idSample Integer,
fieldName varchar(30),
fieldValue varchar(100)
)
其中idSample关联到Sample表的id字段（我没有写出来）。这样的话，Hibernate很容易支持，也可以支持Sql的查询，而且可以支持把内容放到Hashtable中去，看起来是目前最好的方式了。但是在大容量数据的时候，SampleFields表的数据会是主表数据量的N倍（看定制的字段数目多少而定），同样存在有很严重的性能问题。

二、大数据系统体系建设规划包括哪些内容

技术模型控制、适应传统管广东会作需求 新一代电子政务系统在得出了业务资源及关系模型和业务资源权限控制模型后，再结合机关单位办公实际，梳理传统管广东会作需求，把机关单位的传统管广东会作、规章制度通过技术模型的形式固定了。还有像传统的规章制度中对文件传阅控制、处理规定等，新一代电子政务系统就通过查询授权功能在技术上实现。提炼标准模型在广东会的业务核心模型基础上，新一代电子政务系统建设为了保障业务核心模型的有效实现和规划，再提炼了业务标准模型。统一数据库结构设计 新一代电子政务系统通过数据标准规范，统一了各子系统的数据结构标准，从数据底层实现了标准统一，为各子系统之间的数据共享和数据整合提供了统一结构基础。统一系统和基础信息资源分类 新一代电子政务系统通过统一各业务及应用子系统之间的系统和基础信息资源分类，实现了信息资源支撑的统一，从而为各子系统之间的数据关联相互交换提供了统一数据基础。业务数据标准化保障了业务模型在数据层次的统一，确保了业务模型数据标准。统一主界面布局与统一应用层次 在业务数据标准统一基础上，为了确保业务核心模型在电子技术实现后的规范和方便应用，新一代电子政务系统又广东会实现了系统布局和展示层的标准,还可以为应用层次划分标准，从而方便用户对系统的规范使用。制定设计模型广东会了业务核心模型，提炼了业务标准后，新一代电子政务系统针对各种办公业务资源，从业务工作的实际出发，结合实践经验，又广东会制定了基于业务核心模型基础上的业务设计模型，业务设计模型的广东会又在于归纳可复用各业务功能模块上面。新一代电子政务系统中，业务设计模型的广东会在于提炼可复用各业务功能模块。以往的电子政务建设，模块不清晰，系统建设杂乱无章，很多建设工作重复，这不仅仅耗费了大量资金，而且不利于系统的长远发展和推广应用。新一代电子政务系统从建设的实践中，从功能模块层提炼出了可复用的各业务功能模块，以方便系统的继续发展和建设，局部见图2

三、【科普】企业中，大数据部门的常见组成

在IT公司里，大数据部门的成员，一般可分为4种：（以房子为例）

先用一张图，帮助大家理解一下～～
出道题目，我们公司的大数据部门，目前有这些岗位，你能一一推测出他们的所在位置吗？
【数据应用工程师】、【数据可视化工程师】、【数据可视化设计师】、【数据平台工程师】、【算法工程师】、【数据分析师】

建房子地基（埋在地下）的那群人
他们就是 平台组/架构组 的那群人，他们负责搭建一套大数据的平台架构体系。一般你肉眼看不到他们的产出，但是当某一堵墙壁歪了的时候，或者你进屋打水但水龙头却流不出来水的时候，你就会意识到他们工作的重要性。
平台组的常见发展路径 ：
平台初期，很多公司会用自己的服务器搭一个 私有集群 ，将数据维护起来，开始构建数据平台的第一步。这个，也是原始的大数据平台。（当然，现在有很多公司也是直接上云服务器）
当平台进入高速发展期，考虑到不断扩充的数据量和服务器的维护成本上升，很多公司会迁移平台到 云服务 上，比如阿里云，华为云。云服务的选择要解决的是选择平台所提供的服务，成本，数据通道的维护。【我们公司目前正处于这一阶段，选择了云服务。当前，经过考量也正在由阿里云迁移到华为云】
还有一个阶段，你发现云服务的费用太高，虽然省了你很多事，或者是考虑到敏感数据的安全问题（当然，私有集群也不是百分百安全），然后又开始往 私有集群 迁移。这时候，鉴于数据规模，你大概需要一个靠谱的团队，设计网络布局、设计运维规范、架设监控、建立机房，值班团队走起7*24小时随时准备出台。
至此，产生了平台组，真的大数据平台来了 。

建屋子（砌墙盖瓦）的那群人 ：
应用组 的那群人，他们负责建设各类系统/应用。他们搬砖砌墙，建好房子，还要铺设各类管道线路，把地基里面的数据抽出来，放在房子里，让用户们推开门就可以享用。
应用组，有哪些应用？ ：
这块不太好讲。不过，为了尽量让大家看懂，用 从大到小的思路 尝试下：
在整个社会层面，大数据已应用于各行各业，比如：金融行业/地产行业/零售行业/医疗行业/农业/物流行业/城市管理等等……有哪一个行业，可以脱离数据而生存？有哪一个行业可以不依赖数据而发展？
那么，在一个企业中，数据必然是无法避免的会应用到，不管是1个员工的皮包公司，还是10万员工的跨国集团。so，我们来讲讲具体有哪些应用呢？
一般而言，数据应用分为3类：分别是面向企业内部， 面向企业外部以及面向用户这三种。

这里，鉴于今天的主题，我们只讲 面向企业内部 的大数据应用。
进入正题了：
企业内部产品中，可以从2个角度来看待具体有哪些应用：

策略类 的方向较多，常见的有：

这些有时候会有部分或全部不划在大数据部门下面，但都需要比较规范的数据基础，以及着重与利用数据分析调整产品策略。

做企业内部的大数据应用产品，常常有些心酸的地方：

屋子里面的人 ：
产品组 的那群人，主要是一群产品经理（我们公司，目前就半个，由一个分析师兼职着，所以，我们公司没有产品组哦），负责数据类的应用产品设计。他们和上面建房子的工程师们，是紧密的团队关系。鉴于上面对数据应用产品已做了很多阐述，关于他们工作产出的应用具体有哪些，这里就不再赘述。
讲一讲， 数据产品经理 的从业人员得有几个素质：

屋子外面的人 ：
分析组 的那群人，一般会有3类：数据分析师、算法工程师 （类似数据挖掘） 、数据科学家 （我们公司没有） 。他们工作的日常：为你提取一份EXCEL数据、制作一张报表数据、用算法模型分析一个问题、训练出一套算法模型等等工作，但不局限于此。
他们常常需要与各个部门打交道，接待很多业务的数据需求，与业务关系紧密。在一些公司，分析组不一定都设置在大数据部门下，他们可能分散在不同的业务部门，为各自部门服务。但是，他们终究也是需要从大数据平台来获取所需的业务数据，做分析处理，得到相关结论～
据我所知，我们公司的业务部门，（好像）也是有自己的分析人员。
简单概括一下这些职位的特点：
【数据分析师】
业务线，负责通过数据分析手段发现和分析业务问题，为决策作支持。
【算法工程师】/【数据挖掘工程师】
偏技术线，负责通过建立模型、算法、预测等提供一些广东会的解决方案，当然也有针对某业务的。
【数据科学家】
数据科学家是使用专业知识构建机器学习模型，再以此做出预测并对关键业务问题进行解答的专家。数据科学家仍然需要对数据进行清洗、分析以及可视化处理，这一点和数据分析师是一致的。不过数据科学家在专业技能方面有者更深的研究，涉猎范围也更广，同时他们也能够对机器学习模型进行训练与优化。

至此，整篇文章，已经讲差不多了。
最后总结下，本质上，围绕房子的这4拨人，做的是同一件事情： 提供数据服务 。

完结～

四、有成千上万种产品,各个产品属性不同,怎么设计数据库或设计页面加载不同属性

建立产品属性表，分类表，产品表
t_Property_Group 产品属性分类表
id 分类自动编号，主键
title 分类标题
t_Proterty 产品属性表
id 分类自动编号，主键
title 属性名称
gid 属性分类编号
t_Product 产品表
id 编号
title 产品名称
remark 备注
t_Product_Property_Relation
id
productid 产品编号
propertyid 产品属性编号
propertydata 产品属性数据
==================================
以上仅仅是设计方法之一，根据不同的需求，可以演变出各种数据关系模型。要想通透理解，慢慢做过去之后，才能看的很明白。 以上表格仅仅是比较核心的数据字段，也可以添加更多符合个性的表结构。
对于页面，则包含较多的架构内容。 比如应用框架生成静态页面的，则涉及到标签、模板等。
动态加载属性有两种解释，1、从数据库及时的读出数据（属性）2、从数据库改动数据之后，从新生成或者新生成的页面可以获得数据库的更新，可以生成包含新属性的产品页面。
望采纳。

   以上就是小编对于数据产品设计_数据产品设计的关键流程问题和相关问题的解答了，数据产品设计_数据产品设计的关键流程的问题希望对你有用！

   免责声明： 1、文章部分文字与图片来源网络，如有问题请及时联系我们。 2、因编辑需要，文字和图片之间亦无必然联系，仅供参考。涉及转载的所有文章、图片、音频视频文件 等资料，版权归版权所有人所有。 3、本文章内容如无意中侵犯了媒体或个人的知识产权，请联系我们立即删除，联系方式：请邮件发送至 cnc1698@l63.com