一、经济的本科毕业论文一定要有什么模型数据分析之类的吗？

这个要看不同学校的吧…… 反正我们学校经济本科毕业论文不需要数据模型，但是需要一些数据来支撑你的论点，作为论据还是需要的。

。。

二、如何创建数据模型

建立数据模型

1、建立实体联系模型

1.1、实体联系模型的基本构成

实体联系（ER）数据模型所采用的三个主要概念是：实体集、联系集和属性。

实体集是具有相同类型及相同性质（属性）的实体集合。联系集是指同类联系的集合。

在ER模型中，用矩形框表示实体集（矩形框中写上实体名），用椭圆表示属性（椭圆中标上属性名），实体的主码用下划线表示。实体集之间的联系集用菱形表示，并用无向边与相关实体集连接，菱形中写上联系名，无向边上写上联系集的类型。

实体集之间的联系类型有一对一，一对多，多对多

1.2、多元联系

在ER模型中，可以表示两个以上实体集之间的联系，称为多元联系。

一个多元联系集总可以用多个不同的二元联系集来替代。考虑一个抽象的三元联系集R，它联系了实体集A、B、C。可引进一实体集E替代联系R，然后，为实体集E和A、B、C建立三个新的二元联系集，分别命名为RA、RB、RC。可以将这一过程直接推广到n元联系集的情况。所以，理论上可以限制E R模型中只包含二元联系集。

1.3、联系的属性

联系也可以具有单独的属性。

1.4、自身联系

在一个联系中，一个实体集可以出现两次或多次，扮演多个不同角色，此种情况称为实体集的自身联系。一个实体集在联系中出现多少次我们就从联系到这个实体集画多少条线，到实体集的每条线代表该实体集所扮演的不同角色。

1.5、子类和Is-a层次联系

在信息世界中，常常需要描述这样的实体集A，A属于另一实体集B。A中的实体都有特殊的属性需要描述，并且这些特殊属性对B中其他的实体无意义。在ER模型中，称A是B的子类，或B是A的父类。两类实体之间存在一种层次联系——Is-a（属于）。

如果A和B存在Is-a联系，则A中的每个实体a只和B中的一个实体b相联系，而B中的每一个实体最多和A中的一个实体相联系。从这个意义上说，A和B存在一对一的联系。但事实上，a和b是同一事物。A可以继承B中的所有属性，又可以有自己特殊的属性说明。用来区分A的主码也就是B的主码。

2、ER模型向关系模型的转化

ER模型是概念模型的表示。要使计算机能处理模型中的信息，首先必须将它转化为具体的DBMS能处理的数据模型。ER模型可以向现有的各种数据模型转换，而目前市场上的DBMS大部分是基于关系数据模型的， ER模型向关系数据模型的转换方法

关系模型的逻辑结构是一系列关系模式（表）的集合。将ER模型转化为关系模式主要需解决的问题是：如何用关系表达实体集以及实体集间的联系。

ER模型向关系模型转换的一般规则和步骤：

（1）将每一个实体集转换为一个关系模式，实体集的属性转换成关系的属性，实体集的码即对应关系的码。

（2）将每个联系集转换成关系模式。对于给定的联系R，由它所转换的关系具有以下属性：

联系R单独的属性都转换为该关系的属性；

联系R涉及到的每个实体集的码属性（集）转换为该关系的属性。转换后关系的码有以下几种情况：

· 若联系R为1∶1联系，则每个相关实体的码均可作为关系的候选码；

· 若联系R为1∶ n联系，则关系的码为n端实体的码；

· 若联系R为m∶ n联系，则关系的码为相关实体码的集合。

有时，联系本身的一些属性也必须是结果关系的码属性。

（3）根据具体情况，把具有相同码的多个关系模式合并成一个关系模式。

三、如何用层次分析法建立数学模型

1.判断矩阵——B=cov(A)

2.求特征向量和特征根——eig(B)

3.计算权重

4.一致性检验

四、该怎么组建一个分析模型？

可以设置多个数据删选的条件：

1.奇数或者是偶数有哪些？

2.整数或者是小数有哪些？

3.素数有哪些？

4.在【a，b】范围内的数那些？a，b为实数，可有自己输入。

....

五、如何建立和评估数据仓库逻辑模型

逻辑模型指数据仓库数据的逻辑表现形式。从最终应用的功能和性能的角度来看，数据仓库的数据逻辑模型也许是整个项目最重要的方面，需要领域专家的参与。从内容上看，涉及的方面有确立主题域，粒度层次的划分，确定数据分割策略，关系模式的确定。

逻辑模型建设方法

逻辑建模是数据仓库实施中的重要一环,因为它能直接反映出业务部门的需求,同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的第三范式 (3NF,即 Third Normal Form)和星型模式 (Star-Schema)

第三范式

关系模式满足以下特征：

1 每个属性的值唯一,不具有多义性;

2. 每个非主属性必须完全依赖于整个主键,而非主键的一部分;

3. 每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去

星型模型

星型模式是一种多维的数据关系，它由一个事实表(Fact Table)和一组维表(Dimens ion Table)组成。每个维表都有一个维作为主键，所有这些维则组合成事实表的主键，换言之，事实表主键的每个元素都是维表的外键。事实表的非主属性称为事实 (Fact)，它们一般都是数值或其他可以进行计算的数据;而维大都是文字、时间等类型的数据。

第三范式和星型模式在数据仓库中的应用

大多数人在设计中央数据仓库的逻辑模型时，都按照第三范式来设计;而在进行物理实施时，则由于数据库引擎的限制，不得不对逻辑模型进行不规范处理 (De-Normalize)， 以提高系统的响应速度，这当然是以增加系统的复杂度、维护工作量、磁盘使用比率 (指原始数据与磁盘大小的比率)并降低系统执行动态查询能力为代价的。

那么，在中央数据仓库中是否可以采用星型模式来进行模型设计呢?我们知道，星型模式中有一个事实表和一组维表，我们可以把事实看成是各个维交叉点上的值。

星型模式之所以速度快，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。因此，在星型模式设计的数据仓库中，作报表的速度虽然很快，但由于存在大量的预处理，其建模过程相对来说就比较慢。当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。由于事实表的主键由所有维表的主键组成，这种维的变动将是非常复杂、非常耗时的。星型模式另一个显著的缺点是数据的冗余量很大。综合这些讨论，不难得出结论，星型模式比较适合于预先定义好的问题，如需要产生大量报表的场合;而不适合于动态查询多、系统可扩展能力要求高或者数据量很大的场合。因此，星型模式在一些要求大量报表的部门数据集市中有较多的应用。

总之，上面讨论了数据仓库模型设计中常用的两种方法。对于部门数据集市，当数据量不大、报表较固定时可以采用星型模式;对于企业级数据仓库，考虑到系统的可扩展能力、投资成本和易于管理等多种因素，最好采用第三范式。

逻辑模型指数据仓库数据的逻辑表现形式。从最终应用的功能和性能的角度来看，数据仓库的数据逻辑模型也许是整个项目最重要的方面，需要领域专家的参与。从内容上看，涉及的方面有确立主题域，粒度层次的划分，确定数据分割策略，关系模式的确定。

逻辑模型的质量标准

对逻辑模型的评估，就是对逻辑模型质量的考察，什么是逻辑模型的质量呢？从狭义的概念说，逻辑模型是否正确表达了业务规则，也就是准确，但是随着人们对数据仓库认识的加深，质量的含义不断延伸,现在对模型质量要求不仅仅单纯指单纯的业务规则，还包括模型满足用户分析需求的程度，它是一个包含丰富内涵、具有多维因素的综合性概念。相应地逻辑模型质量概念的认识也从狭义向广义转变，准确性已不再是衡量唯一标准。评估逻辑模型一般包括如下方面的标准

正确性

逻辑模型的建设方法是正确的，遵循了从上到下和从下到上相结合的方法，选择了正确的模型表示方式，对实际业务采用正确的概化抽象。

准确性（精度）

指逻辑模型和实际业务即“真值”之间的差异程度。误差越小，准确性就越高。这里，所谓的“真值”是可知的，尽管逻辑模型经过了抽象，概化等方法总结共性，但是模型的具体化后，与“真值”是应当符合的。可以通过范围误差、计数误差、不回答率、加工整理差错、模型假设误差等影响准确性的各个因素，测算统计估算值的变动系数、标准差、均方差、曲线配合吻合度、假设检验、偏差等，修正逻辑模型将其的误差控制在一个可接受的置信区间内。

适用性

指收集的信息是否有用，是否符合用户的需求。它要求逻辑模型的粒度，分割方式符合用户的分析需求。

可解释性

是指在公布逻辑模型时，应同时公开逻辑模型的的补充解释信息或称为“元数据”，即关于模型数据的解释说明。内容包括所使用的建设方法，建设目标，以防止模型数据二义性导致错误解释和使用。

完备性

目前的业务需求和所用的业务规则完全包含在逻辑模型中。模型中不存在没有包含的需求业务对象（如实体，属性，以及之间的关系）

一致性

模型中的各个对象命名方式统一，有明确的命名规范。而且模型中各个相关对象的粒度一致，业务逻辑模型对象的划分标准应当统一。

扩展性

当新的业务产生时，仅仅是增加了相关逻辑模型对象的实例内容，不影响目前的逻辑模型，模型这些分类能够随统计分析需求的不同进行相应的调整，无需改变数据库结构，具有灵活的扩展性。仅在个别情况下，需要对逻辑模型的属性或者实体本身增加，支持分步骤的实施。

可衔接性

逻辑模型来自拥有行业经验的概念模型，里面凝聚了许多成功的经验，而且从规划上符合行业系统的长远发展，因此逻辑模型应当从概念模型上相对平滑的过度过来。此外，物理模型应当来自与逻辑模型，逻辑模型的建设应当具有一定的可操作性，便于向物理模型的转化。

逻辑模型中常犯的错误：

命名规范不统一

对于汇总数据，低粒度数据或历史数据采用已定义的命名规范。

粒度层次不统一

有的具体，有的过于抽象

不准确

业务关系表示错

不全面：

一些属性外键标识没有主表

无用关联关系多：

模型中各种对象所表示的内容，应当与用户的业务分析需求密切相关。

与行业通用模型移动的兼容性差：

与行业通用模型存在较大的差异，不利于系统的将来发展符合信息发展的趋势。

总结

商业智能和数据仓库系统的建设作为一个渐进、迭代的过程，其发展趋势是从现有的初步应用如报表分析、数据集市，向深度和广度复杂分析和数据挖掘技术应用发展，其依赖的数据存储模型，包括逻辑模型和物理模型，也是一个不断发展，不断丰富完善的过程。