如何数据建模

A. 何谓全息信息模型如何建模

摘要 全息信息又叫多维信息或立体信息，这种信息是多渠道、多视角、多侧面收集、编写而成的。全息信息模型，顾名思义，是指包含了系统所有信息的模型。具体体现为系统中的数据不仅仅有各设备的工作状态信息、数据传递信息、系统交互信息，更包含了影响系统运行的数据，如系统所处的自然、社会环境信息等。

B. 谁能告诉我SQL数据库如何建模

先建概念模型，可用ER或者EER表达，
再建立逻辑模型，是ER或者EER的衍生，（概念模型和逻辑模型有时可以一步到位）
最后再用软件转为物理模型，然后数据库就自动生成了。

C. 怎样用python数据建模

最近，我从孙子（指《孙子兵法》——译者注）那里学到了一些策略：速度和准备
“兵之情主速，乘人之不及，由不虞之道，攻其所不戒也。”（《孙子兵法•九地篇》）无备为战之大患，有备无患，其乃至德也。（哈哈，译者自己写了这句，想必大家能明白。）
这与数据科学博客有什么关系呢？这是你赢得竞争和编程马拉松的关键。如果你比竞争对手准备得更充分，你学习、迭代执行的速度越快，那么你就取得更好的名次，带来更好的结果。
由于近几年来，Python用户数量上涨及其本身的简洁性，使得这个工具包对数据科学世界的Python专家们变得有意义。本文将帮助你更快更好地建立第一个预测模型。绝大多数优秀的数据科学家和kagglers建立自己的第一个有效模型并快速提交。这不仅仅有助于他们领先于排行榜，而且提供了问题的基准解决方案。
预测模型的分解过程
我总是集中于投入有质量的时间在建模的初始阶段，比如，假设生成、头脑风暴、讨论或理解可能的结果范围。所有这些活动都有助于我解决问题，并最终让我设计出更强大的商业解决方案。为什么你要在前面花费这段时间，这有充分的理由：
你有足够的时间投入并且你是无经验的（这是有影响的）
你不带有其它数据观点或想法的偏见（我总是建议，在深入研究数据之前做假设生成）
在后面的阶段，你会急于完成该项目而没有能力投入有质量的时间了。
这个阶段需要投入高质量时间，因此我没有提及时间表，不过我建议你把它作为标准的做法。这有助于你建立建立更好地预测模型，在后面的阶段的只需较少的迭代工作。让我们来看看建立第一个模型的剩余阶段的时间表：
数据描述性分析——50%的时间
数据预处理（缺失值和异常值修复）——40%的时间
数据建模——4%的时间
性能预测——6%的时间
让我们一步一步完成每个过程（每一步投入预测的时间）：
阶段1：描述性分析/数据探索
在我刚开始成为数据科学家的时候，数据探索占据了我大量的时间。不过，随着时间的推移，我已经把大量的数据操作自动化了。由于数据准备占据建立第一个模型工作量的50%，自动化的好处是显而易见的。
这是我们的第一个基准模型，我们去掉任何特征设计。因此，描述分析所需的时间仅限于了解缺失值和直接可见的大的特征。在我的方法体系中，你将需要2分钟来完成这一步（假设，100000个观测数据集）。
我的第一个模型执行的操作：
确定ID，输入特征和目标特征
确定分类和数值特征
识别缺失值所在列
阶段2：数据预处理（缺失值处理）
有许多方法可以解决这个问题。对于我们的第一个模型，我们将专注于智能和快速技术来建立第一个有效模型。
为缺失值创建假标志：有用，有时缺失值本身就携带了大量的信息。
用均值、中位数或其它简单方法填补缺失值：均值和中位数填补都表现良好，大多数人喜欢用均值填补但是在有偏分布的情况下我建议使用中位数。其它智能的方法与均值和中位数填补类似，使用其它相关特征填补或建立模型。比如，在Titanic生存挑战中，你可以使用乘客名字的称呼，比如：“Mr.”, “Miss.”,”Mrs.”,”Master”，来填补年龄的缺失值，这对模型性能有很好的影响。
填补缺失的分类变量：创建一个新的等级来填补分类变量，让所有的缺失值编码为一个单一值比如，“New_Cat”，或者，你可以看看频率组合，使用高频率的分类变量来填补缺失值。
由于数据处理方法如此简单，你可以只需要3到4分钟来处理数据。
阶段3：数据建模
根据不同的业务问题，我推荐使用GBM或RandomForest技术的任意一种。这两个技术可以极其有效地创建基准解决方案。我已经看到数据科学家通常把这两个方法作为他们的第一个模型同时也作为最后一个模型。这最多用去4到5分钟。

D. 数据建模方式中正确的有哪些

常用正确的建模方法有实体建模法、维度建模法和范式建模法三种数据建模方法，不管哪种数据建模方法都是使信息结构清晰、易于存储和读取。

E. 怎么使用MySQL Workbench做数据建模

方法/步骤
打开MySQL Workbench，并连接数据库。图中显示连接数据库对话框

成功连接后，点击如图所示红色按钮，“create new Schema”，填写数据库名称如“new_schema”,点击“应用”，如图

在弹出的的确认对话框中点击“应用”，如图

OK，成功创建，如图

如图操作，我们开始创建表

需要填写表名（new_table），列名”id、date“和选择列的类型，以及列属性（主键），点击”应用“

7
如图所示，成功创建表，点击右键，选择“select rows”可以编辑表内容

F. 数据建模中比较常用的工具有哪些

随着科技的日新月异，人们对数据的依赖稳步上升中，尤其在商业等领域，对于企业而言正确且连贯的数据流，是他们做出快速、精准的决策的重要依据之一。因此，建立正确的数据流和数据结构才能保证最好的结果，这个过程就是大家耳闻能详的数据建模。

下面为大家推荐一些数据建模中常见的几种工具。

1、SQL数据库建模器

该软件使企业可以参与逆向工程和正向工程。利用已经存在的数据库并完善它们。然后，使用正向工程技术来了解它们如何随时间的推移而增长。该平台的更多独特功能包括创建多个主题区域的能力以及非常友好的用户界面。使用此工具的一些企业包括福特、联想、Wayfair和德勤等公司。

2、PowerDesigner

PowerDesigner是目前数据建模业界的领头羊。功能包括：完整的集成模型，和面向包含IT为中心的、非IT为中心的差异化建模诉求。支持非常强大的元数据信息库和各种不同格式的输出。PowerDesigner拥有一个优雅且人性化的界面，非常易懂的帮助文档，快速帮助用户解决专业问题。

3、CA ERwin

ERwin 也是业界领先的数据建模解决方案，能够为用户提供一个简单而优雅的界面同时处理复杂的数据环境问题。Erwin的解决方案提提供敏捷模型，同时元数据可以放在普通的数据库中进行处理，这样就能够保证数据的一致性和安全性。Erwin支持高度自定义的数据类型、APIs，允许自动执行宏语言等等。Erwin还建有一个很活跃的用户讨论社区，使得用户之间可以分享知识和各种经验。

4、SQL Power Architect

SQL Power Architect 是一个Java开发的数据库建模工具，特别适合做数据仓库和数据集市的应用建模，它允许设计人员同时打开多个数据源连接，并直接从数据库中获取模型定义。
5、dbdiagram.io
dbdiagram.io是一个快速上手的数据库设计器，专注于绘制数据库关系图，专为开发人员，DBA，数据分析师而设计，在线保存和共享图表可帮助您使用其自己的特定于域的语言（DSL：Domain-specific language）绘制数据库图。它们的定义语言非常简单，使用键盘即可轻松进行编辑/复制，UI简洁，并包含有漂亮的图表。

为了避免错误并加快进度，建议大家可以使用这些更加专业的工具（软件），来帮助我们建立数据模型，且能够更快捷的生成报告来描述这个数据模型，为大家带来实利。

G. 数据建模的如何进行

概念建模
数据建模大致分为三个阶段，概念建模阶段，逻辑建模阶段和物理建模阶段。其中概念建模和逻辑建模阶段与数据库厂商毫无关系，换言之，与MySQL，SQL Server，Oracle没有关系。物理建模阶段和数据库厂商存在很大的联系，因为不同厂商对同一功能的支持方式不同，如高可用性，读写分离，甚至是索引，分区等。
概念建模阶段
实际工作中，在概念建模阶段，主要做三件事：
1. 客户交流
2. 理解需求
3. 形成实体
这也是一个迭代，如果先有需求，尽量去理解需求，明白当前项目或者软件需要完成什么，不明白或者不确定的地方和客户及时交流，和客户double confirm过的需求，落实到实体（Package）；但是好多时候我们需要通过先和客户交流，进而将交流结果落实到需求，之后进一步具体到实体；本文可能会涉及到一些来自于EA（Enterprise Architect 7.1）建模术语，（EA中将每个实体视为一个Package）。这里并不对各种建模工具进行比较，如Visio，EA，PowerDesigner， ERWin等；其实作为员工的我们选择性很少，公司有哪个产品的Licence，我们就用哪个吧。
举例说明：在一个B2C电子商务网站中，这样的需求再普通不过了：客户可以在该网站上自由进行购物！我们就以这个简单例子，对其进行细分，来讲解整个数据建模的过程，通过上面这句话，我们可以得出三个实体：客户，网站，商品；就像Scrum（敏捷开发框架的一种）中倡导的一样每个Sprint，都要产出确确实实的东西，OK，概念建模阶段，我们就要产出实体。客户和商品（我们将网站这个实体扔掉，不需要它。）
在创建这两个实体（Package）的时候，我们记得要讲对需求的理解，以及业务规则，作为Notes添加到Package中，这些信息将来会成为数据字典中非常重要的一部分，也就是所谓的元数据。BTW，EA或者其他建模工具应该都可以自动生成数据字典，只不过最终生成的格式可能不太一样。如在Customer这个Package的Notes上，我们可以这样写，用户都要通过填写个人基本信息以及一个邮箱来注册账户，之后使用这个邮箱作为登录帐号登录系统进行交易。
在概念建模阶段，我们只需要关注实体即可，不用关注任何实现细节。很多人都希望在这个阶段把具体表结构，索引，约束，甚至是存储过程都想好，没必要！！因为这些东西使我们在物理建模阶段需要考虑的东西，这个时候考虑还为时尚早。可能有的人在这个阶段担心会不会丢掉或者漏掉一些实体?也不用担心，2013年好多公司都在采用Scrum的开发模式，只要你当前抽象出来的实体满足当前的User Story，或者当前的User Story里面的实体，你都抽象出来了，就可以了！如果你再说，我们User Story太大，实体太多，不容易抽象，那就真没办法了，建议你们的团队重新开Sprint 计划会议。
逻辑建模
逻辑建模阶段
对实体进行细化，细化成具体的表，同时丰富表结构。这个阶段的产物是，可以在数据库中生成的具体表及其他数据库对象（包括，主键，外键，属性列，索引，约束甚至是视图以及存储过程）。我在实际项目中，除了主外键之外，其他的数据库对象我都实在物理建模阶段建立，因为其他数据库对象更贴近于开发，需要结合开发一起进行。如约束，我们可以在web page上做JavaScript约束，也可以在业务逻辑层做，也可以在数据库中做，在哪里做，要结合实际需求，性能以及安全性而定。
针对Customer这个实体以及我们对需求的理解，我们可以得出以下几个表的结构，用户基本信息表（User），登录账户表（Account），评论表（Commnets,用户可能会对产品进行评价），当然这个案例中我们还会有更多的表，如用户需要自己上传头像（图片），我们要有Picture表。
针对产品实体，我们需要构建产品基本信息表（Proct），通常情况下，我们产品会有自己的产品大类（ProctCategory）甚至产品小类（ProctSubCategory），某些产品会因为节假日等原因进行打折，因为为了得到更好的Performance我们会创建相应ProctDiscount表，一个产品会有多张图片，因此产品图片表（ProctPicture）以及产品图片关系表（ProctPictureRelationship），（当然我们也可以只设计一张Picture表，用来存放所有图片，用户，产品以及其他）有人说产品和图片是一对多的关系，不需要创建一个关系表啊?是的，我认为只要不是一对一的关系，我都希望创建一个关系表来关联两个实体。这样带来的好处，一是可读性更好，实现了实体和表一一对应的关系，二是易于维护，我们只需要维护一个关系表即可，只有两列（ProctID和PictureID），而不是去维护一个Picture表。
客户进行交易，即要和商品发生关系，我们需要Transaction表，一个客户会买一个或者多个商品，因为一笔Transaction会涉及一个或多个Procts，因此一个Transaction和ProctDiscount之间的关系（ProctDiscount和Proct是一一对应的关系）需要创建，我们称其为Item表，里面保存TransactionID以及这笔涉及到的ProctDiscountID（s），这里插一句，好多系统都需要有审计功能，如某个产品历年来的打折情况以及与之对应的销售情况，我们这里暂不考虑审计方面的东西。
就这样，我们根据需求我们确定下来具体需要哪些表，进一步丰富每一个表属性（Column），当然这里面会涉及主键的选取，或者是使用代理键（Surrogate Key），外键的关联，约束的设置等细节，这里笔者认为只要能把每个实体属性（Column）落实下来就是很不错了，因为随着项目的开展，很多表的Column都会有相应的改动。至于其他细节，不同数据库厂商，具体实现细节不尽相同。关于主键的选取多说一句，有的人喜欢所有的表都用自增长ID作为主键，而有的人希望找到唯一能标识当前记录的一个属性或者多个属性作为主键；自增长ID作为代理主键，对于将来以多个类似当前Transaction System作为数据源，构建数据仓库的时候，这些自增长ID主键会是一个麻烦（多个系统中，相同表存在大量主键重复）；使用一个属性或多个属性作为作为主键，不管主键是可编辑的，读写效率是我们必须考虑得。所以并没有一个放之四海而皆准的原则，笔者只是给大家推荐一些考虑的因素。
物理建模
物理建模阶段
EA可以将在逻辑建模阶段创建的各种数据库对象生成为相应的SQL代码，运行来创建相应具体数据库对象（大多数建模工具都可以自动生成DDL SQL代码）。但是这个阶段我们不仅仅创建数据库对象，针对业务需求，我们也可能做如数据拆分（水平或垂直拆分），如B2B网站，我们可以将商家和一般用户放在同一张表中，但是针对PERFORMANCE考虑，我们可以将其分为两张表；随业务量的上升，Transaction表越来越大，整个系统越来越慢，这个时候我们可以考虑数据拆分，甚至是读写分离（即实现MASTER-SLAVE模式，MYSQL/SQLSERVER可以使用Replication，当然不同存储引擎采用不同的方案），这个阶段也会涉及到集群的事情，如果你是架构师或者数据建模师，这个时候你可以跟DBA说，Alright,I am done with it,now is your show time.
相信大家都知道范式，更有好多人把3NF奉为经典，3NF确实很好，但是3NF是几十年前提出来的，那个时候的数据量以及访问频率和2012年完全不是一个数量级的；因此我们绝对不能一味地遵守3NF；在整个数据建模过程中，在保证数据结构清晰的前提下，尽量提高性能才是我们关注的要点，因此笔者大力倡导数据适当冗余!
上面笔者是结合一些实际例子表达自己对数据建模的观点，希望对读着有用。在数据建模过程中，不要希望一步到位将数据库设计完整，笔者不管是针对data warehouse还是Transactional Database设计，从来没有过一次成功的经历。随着项目的进行，客户和开发团队对业务知识与日增长，因此原来的设计也在不断完善中。毕竟，数据建模或者设计数据库不是我们的最终目的，我们需要的是一个健壮，性能优越，易扩展，易使用的软件!

H. 数据实体如何建模

数据建模：软件开发中非常重要的部分，是概要设计阶段必须完成的工作。
数据建模要能够分析出项目中使用的实体、确定多个实体之间的关系。

I. 如何进行数据建模

如何进行数据建模
正确完成建模

在过去的几十年里，数据建模的努力通常集中在关系数据建模或可扩展标记语言(XML)的建模上。只要数据存储在关系数据库中，关系数据建模就会很好，但除此之外，它很少会有其他的用途。而且XML也不能被可靠地称为建模语言。XML是序列化数据的规范--即定义了如何将数据写入文件。XML为构造数据的序列化提供了一种格式，但它不是一个真正的模型。

我所说的“模型”指的是以数学为基础的形式规范。实际上，这意味着是可以使用形式化方法进行验证的东西。通俗地说，这意味着我们可以用数学运算来证明它是正确的，并且我们可以使验证过程自动化。而在XML模式中捕获数据不符合此定义下的模型。但可以肯定的是，我们可以使用软件来验证该XML格式是否良好，是否符合一些XML模式的文档。但这还不足以真正地对数据进行建模。

无论是计算机还是人，如果不同时理解数据的语法(结构)和语义(含义)，就无法理解数据。XML可以捕获语法，但它不能天生捕获语义。语义可以用XML格式编写，但是这些语义必须首先在一些更正式的建模方案中被捕获。换句话说，企业需要一个正式的本体。这种建模方案大多基于形式逻辑，通常是公共逻辑或描述逻辑。

迄今为止，最常用的语义建模语言是基于描述逻辑的网络本体语言(OWL)。这意味着我们不仅可以正式验证模型及其包含的数据，还可以通过对数据的推理来推断新的事实，并且我们可以证明这些推断的正确性。因为OWL是本体建模的事实上的标准，所以我将把剩下的内容限制在OWL上。

但是等等!所有这些都不意味着你需要将你的数据存储为OWL。在你过于担心如何将存储格式强加给不情愿的开发人员之前，先听我说完。

J. 常用的输入数据建模方法有哪些他们的应用特点是什么

目前最常用的三种数据模型为层次模型、网状模型和关系模型。
一、层次模型
层次模型将数据组织成一对多关系的结构，层次结构采用关键字来访问其中每一层次的每一部分。
层次模型发展最早，它以树结构为基本结构，典型代表是IMS模型。
优点是存取方便且速度快；结构清晰，容易理解；数据修改和数据库扩展容易实现；检索关键属性十分方便。
二、网状模型
网状模型用连接指令或指针来确定数据间的显式连接关系，是具有多对多类型的数据组织方式。
网状数据模型通过网状结构表示数据间联系，开发较早且有一定优点，目前使用仍较多，典型代表是 DBTG模型。
优点是能明确而方便地表示数据间的复杂关系。