一种结合有监督学习的动态主题模型_蒋卓人
LDA主题模型发现
LDA主题模型发现 1.LDA概念： LDA(Latent Dirichlet Allocation)主题模型由Blei于2003年提出，是在概率隐性语义索引(probabilistic Latent Semantic Indexing，pLSI)上扩展得到的三层贝叶斯概率模型，是文档生成概率模型。LDA模型包含词项、主题和文档三层结构，其基本思想是把文档看成其隐含主题的混合，而每个主题则表现为跟该主题相关的词项的概率分布，LDA可以用来识别大规模文档集或语料库中潜在的主题信息。LDA基于词袋(bag of words)模型，认为文档和单词都是可交换的，忽略单词在文档中的顺序和文档在语料库中的顺序，从而将文本信息转化为易于建模的数字信息。在主题模型中，主题表示一个概念、一个方面，表现为一系列相关的单词，是这些单词的条件概率。形象来说，主题就是一个桶，里面装了出现概率较高的单词，这些单词与这个主题有很强的相关性。 2.LDA生成过程： 首先，可以用生成模型来看文档和主题这两件事。所谓生成模型，就是说，我们认为一篇文章的每个词都是通过“以一定概率选择了某个主题，并从这个主题中以一定概率选择某个词语”这样一个过程得到的。那么，如果我们要生成一篇文档，它里面的每个词语出现的概率为： 这个概率公式可以用矩阵表示 其中”文档-词语”矩阵表示每个文档中每个单词的词频，即出现的概率；”主题-词语”矩阵表示每个主题中每个单词的出现概率；”文档-主题”矩阵表示每个文档中每个主题出现的概率。 LDA整体流程为： 先定义一些字母的含义： 文档集合D，topic集合T D中每个文档d看作一个单词序列
数据仓库物理模型设计
数据仓库物理模型设计 数据仓库的物理模型就是数据仓库逻辑模型在物理系统中的实现模式。其中包括了逻辑模型中各种实体表的具体化，例如表的数据结构类型、索引策略、数据存放位置和数据存储分配等。在进行物理模型的设计实现时，所考虑的因素有：I/O存取时间、空间利用率及维护的代价。 为确定数据仓库的物理模型，设计人员必须做这样几方面工作：首先要全面了解所选用的数据库管理系统，特别是存储结构和存取方法；其次了解数据环境、数据的使用频率、使用方式、数据规模及响应时间要求等，这些都是对时间和空间效率进行平衡和优化的重要依据；最后还需要了解外部存储设备的特征。只有这样才能在数据的存储需求与外部存储设备条件两者之间获得平衡。 1 设计存储结构 在物理设计时，常常要按数据的重要性、使用频率及对反应时间的要求进行分类，并将不同类型的数据分别存储在不同的存储设备中。重要性高、经常存取并对反应时间要求高的数据存放在高速存储设备上；存取频率低或对存取响应时间要求低的数据则可以存放在低速存储设备上。另外，在设计时还要考虑数据在特定存储介质上的布局。在设计数据的布局时要注意遵循以下原则。 l 不要把经常需要连接的几张表放在同一存储设备上，这样可以利用存储设备的并行操作功能加快数据查询的速度。 l 如果几台服务器之间的连接会造成严重的网络业务量的问题，则要考虑服务器复制表格，因为不同服务器之间的数据连接会给网络带来沉重的数据传输负担。 l 考虑把整个企业共享的细节数据放在主机或其他集中式服务器上，提高这些共享数据的使用速度。 l 不要把表格和它们的索引放在同一设备上。一般可以将索引存放在高速存储设备上，而表格则存放在一般存储设备上，以加快数据的查询速度。 在对服务器进行处理时往往要进行大量的等待磁盘数据的工作，此时，可以在系统中使用RAID（Redundant Array of Inexpensive Disk，廉价冗余磁盘阵列）。 2 设计索引策略 数据仓库的数据量很大，因而需要对数据的存取路径进行仔细地设计和选择。由于数据仓库的数据一般很少更新，所以可以设计索引结构来提高数据存取效率。在数据仓库中，设计人员可以考虑对各个数据存储建立专用的索引和复杂的索引，以获取较高的存取效率，虽然建立它们需要付出一定的代价，但建立后一般不需要过多的维护。 数据仓库中的表通常要比联机事务处理系统（OLTP）中的表建立更多的索引，表中应用的最大索引数应与表格的规模成正比。数据仓库是个只读的环境，建立索引可以取得灵活性，对性能极为有利。但是表若有很多索引，那么数据加载时间就会延长，因此索引的建立需要进行综合的考虑。在建立索引时，可以按照索引使用的频率由高到低逐步添加，直到某一索引加入后，使数据加载或重组表的时间过长时，就结束索引的添加。 最初，一般都是按主关键字和大多数外部关键字建立索引，通常不要添加很多的其他索引。在表建立大量的索引后，对表进行分析等具体使用时，可能需要许多索引，这会导致表的维护时间也随之增加。如果从主关键字和外部关键字着手建立索引，并按照需要添加其他索引，就会避免首先建立大量的索引带来的后果。如果表格过大，而且需要另外增加索引，那么可以将表进行分割处理。如果一个表中所有用到的列都在索引文件中，就不必访问事实表，只要访问索引就可以达到访问数据的目的，以此来减少I/O操作。如果表太大，并且经常要对它进行长时间的扫描，那么就要考虑添加一张概括表以减少数据的扫描任务。 3 设计存储策略
基于主题模型的文本情感和话题建模的研究
基于主题模型的文本情感和话题建模的研究随着互联网的快速发展以及社交媒体的崛起,用户生成的大量文 本等数据日积月累,其中,包含篇幅较长的新闻文本、篇幅不一的评论文本以及篇幅较短的社交媒体文本,例如,微博、推特文本。新闻文本之类的文本一般描述重大事件、科学发现等内容,虽然单一文档中包 含信息量大,但是文档涉及话题比较固定。评论文本中包含大量用户 对评价对象的主观评价,虽然文本长度不一,但是包含的信息相对丰富。不同于新闻之类的文本和评论数据,虽然单条微博文本长度较短 且信息量少,但是更新速度快,数据规模大,涉及领域广。这些海量的 文本数据中包含大量有实用价值的信息。但是如何挖掘这些文本中隐藏的语义结构信息是目前自然语言处理和文本检索领域的一大研究 难点。主题模型是一种比较热门且有效的方法,该方法通过词语之间 在文档中的高阶共现模式挖掘文本中的语义结构信息。主题模型的技术已经应用到各个研究领域并且取得了不错的成果。本文以新闻文本、评论文本、微博文本三种不同的文本为实际应用背景,对于话题建模 以及情感相关的话题建模展开了研究。因为新闻文本中一般包含客观的话题信息,而评论文本和微博文本中包含大量的情感信息,因此,本 文针对新闻文本只建模话题信息(不考虑文本的情感信息),而针对评 论数据和微博文本则建模话题和情感两种信息。本文的工作主要基于生成式主题模型,用改进的生成主题模型抽取文本的话题或者情感相 关的话题。其中,现有的针对新闻文本的主题模型和针对评论文本的 情感主题模型,并没有合理地考虑文本中词语或者实体之间包含的语
义知识。同时,现有的工作并没有针对短文本的情感和话题建模提出有效的模型。为了解决上述的问题,本文重点研究话题建模或者情感相关的话题建模中的三个重要的问题:融合知识库中的语义知识建模新闻文本的话题,融合词语之间的语义知识建模评论数据中的情感和话题以及融合用户和时间信息建模微博短文本的情感和话题。具体研究内容如下:(1)本文分析现有的话题建模方法在新闻文本中的不足,即单纯依靠语料中词语之间的高阶共现模式建模话题。当语料中的有些词语没有充分的共现模式,主题模型不能很好地挖掘它们的语义信息。为了克服这一问题,本文研究一种融合维基百科知识到新闻文本中的主题模型,也就是利用外界知识库中的概念和分类知识弥补文本中词语共现模式不足的问题。本文提出一种维基百科知识主题模型(WCM-LDA)。WCM-LDA模型同时建模文本中的词语和实体,并且引入了实体在知识库中对应的概念和分类知识,因此WCM-LDA模型可以缓解建模话题时词语共现模式不足的问题。另外,WCM-LDA模型输出每个话题的词语、概念和分类,可以更加直观地展示每个话题。(2)在评论数据中词语之间的先验语义关系对于情感相关的话题建模同样尤为重要,但是现有的情感主题模型只能通过共现模式挖掘词语之间的语义关系,有些词语在小规模的数据集中没有充分的共现模式同样会导致情感和话题建模的质量不佳。不同于前面的新闻文本中包含了大量实体,可以引入实体对应的知识。评论数据中更多的是评论对象的属性词或者评价词,建模评论文本的情感和话题时,更需要引入的知识是属性词或者评论词语之间的语义关系。因此,本文研究一种引入外
数据仓库建模
背景介绍 熟悉社保行业的读者可以知道，目前我们国家的社保主要分为养老，失业，工伤，生育，医疗保险和劳动力市场这6 大块主要业务领域。在这6 大业务领域中，目前的状况养老和事业的系统已经基本完善，已经有一部分数据开始联网检测。而，对于工伤，生育，医疗和劳动力市场这一块业务，有些地方发展的比较成熟，而有些地方还不够成熟。 1.业务建模阶段 基于以上的背景介绍，我们在业务建模阶段，就很容易来划分相应的业务。因此，在业务建模阶段，我们基本上确定我们本次数据仓库建设的目标，建设的方法，以及长远规划等。如下图： 图8. 业务建模阶段 在这里，我们将整个业务很清楚地划分成了几个大的业务主线，例如：养老，失业，工伤，生育，医疗，劳动力等着几个大的部分，然后我们可以根据这些大的模块，在每个业务主线内，考虑具体的业务主线内需要分析的业务主题。 因此，业务建模阶段其实是一次和业务人员梳理业务的过程，在这个过程中，不仅能帮助我们技术人员更好的理解业务，另一方面，也能够发现业务流程中的一些不合理的环节，加以改善和改进。 同时，业务建模阶段的另一个重要工作就是确定我们数据建模的范围，例如：在某些数据准备不够充分的业务模块内，我们可以考虑先不建设相应的数据模型。等到条件充分成熟的情况下，我们可以再来考虑数据建模的问题。 2.领域概念建模阶段领域概念建模阶段是数据仓库数据建模的一个重要阶段，由于我们在业务建模阶段已经完全理清相应的业务范围和流程，因此，我们在这个领域概念建模阶段的最主要的工作就是进行概念的抽象，整个领域概念建模的工作层次如下图所示：
图9. 领域概念建模阶段 从上图我们可以清楚地看到，领域概念建模就是运用了实体建模法，从纷繁的业务表象背后通过实体建模法，抽象出实体，事件，说明等抽象的实体，从而找出业务表象后抽象实体间的相互的关联性，保证了我们数据仓库数据按照数据模型所能达到的一致性和关联性。 从图上看，我们可以把整个抽象过程分为四个层次，分别为： ?抽象方法层，整个数据模型的核心方法，领域概念建模的实体的划分通过这种抽象方法来实现。 ?领域概念层，这是我们整个数据模型的核心部分，因为不同程度的抽象方法，决定了我们领域概念的不同。例如：在这里，我们可以使用“参与方”这个概念，同时，你也可以把他分成三个概念：“个人”，“公司”，和“经办机构”这三个概念。而我们在构建自己的模型的时候，可以参考业务的状况以及我们自己模型的需要，选择抽象程度高的概念或者是抽象程度低的概念。相对来说，抽象程度高的概念，理解起来较为复杂，需要专业的建模专家才能理解，而抽象程度低的概念，较适合于一般业务人员的理解，使用起来比较方便。笔者在这里建议读者可以选用抽象概念较低的实体，以方便业务人员和技术人员之间的交流和沟通。 ?具体业务层，主要是解决具体的业务问题，从这张图我们可以看出，具体的业务层，其实只是领域概念模型中实体之间的一些不同组合而已。因此，完整的数据仓库的数据模型应该能够相应灵活多变的前端业务的需求，而其本身的模型架构具有很强的灵活性。这也是数据仓库模型所具备的功能之一。 ?业务主线层，这个层次主要划分大的业务领域，一般在业务建模阶段即已经完成这方面的划分。 我们一般通过这种大的业务主线来划分整个业务模型大的框架。 通过领域概念建模，数据仓库的模型已经被抽象成一个个的实体，模型的框架已经搭建完毕，下面的工作就是给这些框架注入有效的肌体。
数据仓库的数据模型
业务驱动 任何需求均来源于业务,业务决定了需求,需求分析的正确与否是关系到项目成败的关键所在,从任何角度都可以说项目是由业务驱动的所以数据仓库项目也是由业务所驱动的. 但是数据仓库不同于日常的信息系统开发,除了遵循其他系统开发的需求,分析,设计,测试等通常的软件声明周期之外;他还涉及到企业信息数据的集成,大容量数据的阶段处理和分层存储,数据仓库的模式选择等等,因此数据仓库的物理模型异常重要,这也是关系到数据仓库项目成败的关键. 数据仓库的结构总的来说是采用了三级数据模型的方式: 概念模型: 也就是业务模型,由企业决策者,商务领域知识专家和IT专家共同企业级地跨领域业务系统需求分析的结果. 逻辑模型：用来构建数据仓库的数据库逻辑模型。根据分析系统的实际需求决策构建数据库逻辑关系模型,定义数据库物体结构及其关系。他关联着数据仓库的逻辑模型和物理模型这两头. 物理模型：构建数据仓库的物理分布模型,主要包含数据仓库的软硬件配置,资源情况以及数据仓库模式。 如上图所示,在数据仓库项目中,物理模型设计和业务模型设计象两个轮子一样有力的支撑着数据仓库的实施,两者并行不悖,缺一不可.实际上,我有意的扩大了物理模型和业务模型的内涵和外延.在这里物理模型不仅仅是数据的存储,而且也包含了数据仓库项目实施的方法论,资源,以及软硬件选型等等;而业务模型不仅仅是主题模型的确立,也包含了企业的发展战略,行业模本等等. 一个优秀的项目必定会兼顾业务需求和行业的标准两个方面,业务需求即包括用户提出的实际需求,也要客观分析它隐含的更深层次的需求,但是往往用户的需求是不明确的,需要加以提炼甚至在商务知识专家引导下加以引导升华,和用户一起进行需求分析工作;不能满足用户的需求,项目也就失去原本的意义了. 物理模型就像大厦的基础架构,就是通用的业界标准,无论是一座摩天大厦也好,还是茅草房也好,在架构师的眼里,他只是一所建筑,地基->层层建筑->封顶,这样的工序一样也不能少,关系到住户的安全,房屋的建筑质量也必须得以保证,唯一的区别是建筑的材料,地基是采用钢筋水泥还是石头,墙壁采用木质还是钢筋水泥或是砖头;当然材料和建筑细节还是会有区别的,视用户给出的成本而定;还有不可忽视的一点是,数据仓库的数据从几百GB到几十TB不等,即使支撑这些数据的RDBMS无论有多么强大,仍不可避免的要考虑到数据库的物理设计. 接下来,将详细阐述数据仓库概念模型(业务模型),逻辑模型,物理模型的意义. 概念模型设计 进行概念模型设计所要完成的工作是: 界定系统边界 确定主要的主题域及其内容
20120405-032 医院数据仓库数据模型设计
医院数据仓库数据模型设计 汪涛① ①安徽省中医院，230009，安徽省合肥市梅山路117号 摘要目的：数据模型设计是数据仓库建设的核心，本文提出一种医院数据仓库数据模型的设计方法。方法：以某一三甲医院的HIS数据为背景，采用数据驱动的手段，结合医院的需求，提出了医院数据仓库的三层数据模型，概念模型、逻辑模型、物理模型，并完整地给出了每个模型的具体的设计和主要内容。结果：设计并实现了医院数据仓库的的数据模型，并结合医院具体的数据给出了相应的实例。结论：此医院数据仓库的三层数据模型易于理解和实现，为医院数据仓库设计最终完成提供了基础。 关键词数据模型概念模型逻辑模型数据仓库 1 引言 随着医疗市场的竞争越来越激烈,为了提高医院的竞争力,各家医院对信息化建设投入不断加大[1]。医院信息系统的使用提高基本业务处理的效率，提升了管理的手段。但随着时间的推移，现有系统积累了海量数据，如何对其中的各类业务数据加以整合和利用，从中挖掘出隐藏在背后的有价值、可以利用的潜在信息，对以后医院科学的业务分析和管理决策十分重要的意义。数据仓库的出现正好可以解决以上问题，如“军字一号”医院信息系统上建立数据仓库，整合和分析历史数据[2]，为医院决策提供数据。而数据仓库系统如何对海量数据进行有效组织和管理，并使之支持千变万化的管理业务分析与决策，主要依赖于数据仓库系统逻辑数据模型(Logical Data Model，简称LDM )的设计[3]。一个好的逻辑数据模型能够最大的保证灵活性和可扩展性，以满足数据源的变化和应用需求的拓展。因此建设好LDM 是医院数据仓库的关键，本就此进行探讨。 2 数据仓库数据模型的概述 数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合，用来支持管理人员的决策,其与操作型数据库系统(OLTP)的建模方法是有不同的[4]。操作性数据库系统是为具体的业务活动，是在传统开发生命周期(SDLC)下进行的，但不适用与决策支持系统领域。在用户需求尚不明确的情况下，数据仓库的建模是从整合现有操作型数据开始的，分析业务系统的数据组织、关系模型，确定数据范围、主题，依次设计系统的概念模型、逻辑模型和物理模型；而在实际的项目实施当中，如在医院的数据仓库建设中，系统的初步需求还是需要首先了解和分析的。这为数据仓库建设提供了原始范围，以及最终为用户所接受提供保证。以下，我在设计医院数据仓库模型是从系统需求分析和HIS的数据分析开始的，采用三层模型设计的。 3 设计医院的数据仓库的数据模型 3.1 概念模型的设计 3.1.1 系统边界的确立，包括需求分析、数据来源等现有的医院数据是面向具体业务的，
数据仓库建设方案
数据仓库建设 商务智能（Business Intelligence）用于支持制定业务决策的技能、流程、技术、应用和实践。核心是通过数据提取、整理、分析，最终通过分析结果制定有关策略、规划，帮助企业了解新的趋势、抓住新的市场机会、发现潜在的威胁，达到资源的合理配置，节约成本提高效益。数据仓库是商业智能的基础，它为OLAP、数据挖掘提供分析和决策支持。 一、数据仓库概念 1.数据仓库定义 是一个面向主题的、集成的、相对稳定的、反映有有历史变化的数据集合，用于支持管理决策。具有以下特点： 详细交易及相关业务数据的集合 包含必要的内部与外部信息 来自于多个数据源、业务操作系统 保存一定的时间周期 按照企业内业务规则决定存储模型 2.建设的必要性 目前大多数信息系统由于建设时间、建设方、各阶段需求不同，会出
现一系列问题：缺乏整体规则、信息缺乏完整性、缺乏统一的信息管理标准和规范、信息孤岛、不具备大容量的数据管理和分析能力。 3.价值 提高管理决策的科学性和管理效率 信息的整合，可推动现在有信息管理体系的重构 打通信息孤岛全局共享，降低数据获取的难度 逐渐取代各类业务管理报表系统 运用历史数据发现规律 二、数据仓库建设 1.业务需求定义 梳理出所有业务过程，分析业务内容提取需求，对其相关的数据进行探查，并对各系统核心业务人员访谈，准确的了解业务需求情况，近期调研 2.技术体系结构 生命周期图
技术架构图：
3.数据仓库数据建模 数据模型是抽象描述现实世界的一种方法，是通过抽象的实体及实体之间的联系来表示现实世界中事务的相互关系的一种映射，数据仓库模型是数据模型中针对特定的数据仓库应用系统的特定模型。数据仓库建模方法种类较多，常见的三种是范式建模、维度建模、实体建模，每种方法本质上都是从不同的角度解决业务中的问题。 关于单独用一篇来详细介绍，这儿仅对维度建模做基本的介绍，维度建模由数据仓库领域另一位大师Ralph Kimall所倡导，是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。 1.维度模型是什么 维度建模将客观世界划分为度量和上下文。度量是由业务过程和支持它们的业务源系统来捕捉的，常常以数据值形式出现，将其称作“事实”，事实由大量上下文包围着，这些文本形式的上下文被直观地分割成多个独立的逻辑块，我们称其为“维”。维度描述了度量上下文的5W（who、what、when、where、why）信息，以及这些上下文是如何作用的。 企业的每一个业务过程都可以用维度模型来描述，维度模型由一系列含有数值量度量的事实表组成，事实表中的数值则被一系列带有文本属性的维度表环绕。