医疗数据仓库范文

医疗数据仓库范文（精选9篇）

医疗数据仓库 第1篇

1 数据仓库的定义

在数据仓库的发展过程中，许多人对此做出了贡献。1993年William H.Inmon所写的论著《Building the Data Warehouse》系统地阐述了关于数据仓库的思想。在文中他将数据仓库定义为：“一个面向主题的、集成的、随时间变化的、反映历史变化的数据集合，用于支持管理层的决策过程。”

整个数据仓库生命周期的实施过程如图1所示：该图阐明了在有效地设计、开发和部署数据仓库时所必需的一系列高级任务。该图显示了整个项目的实施路径，图中的每个方框所作的处理都是数据仓库项目建设过程中的路标或者指示标记。

目前HIS系统广泛地应用于各大中型医疗机构，医院的各部门业务开展都可以通过各自的业务系统完成。病人从入院到出院期间的各诊断治疗环节的医疗、护理等信息资源都能得到高度共享。我校附属三甲医院的HIS系统经过多年的运行，积累了丰富的信息资源，已经具备建立医院数据仓库的条件。本文从医院决策的需求出发，依托现有的HIS系统，以医疗费用为主题构建医疗数据仓库。

2 医疗数据仓库业务需求分析

2.1 数据仓库需求定义的方法

在医疗数据仓库项目的规划阶段，根据业务需求界定项目的范围和优先级，并提供合理性证明以及进行详细的项目规划。

业务需求位于“数据仓库生命周期图”的中心，几乎影响到数据仓库实施过程中所做出的全部决策，数据仓库的项目范围一定是由“业务需求”驱动的。传统的数据仓库系统的设计采用“数据驱动”，从原有系统已经存在的数据开始，获取数据后，对数据进行集成并检查数据的准确性，按照分析领域对数据及数据之间的联系重新考察，组织数据仓库中的主题。这种方法没有独立的收集需求和分析需求的阶段，而是将需求分析的过程贯穿在整个的设计过程中，虽然具有最大利用现有系统，减少系统建设工作量的优势，但是不能代替用户的介入。医疗数据仓库的建立需要将HIS中分散的业务数据集成在一起，为决策者提供各种类型的数据分析。HIS中对决策有帮助的数据，关键是利用“业务需求”驱动法里的整体法来确定的。

2.2 医疗数据仓库主题域的分析

医疗数据仓库根据决策的需要可面向多种主题，利用“业务需求”驱动法，根据决策的需要在分析原有OLAP系统产生数据的同时收集相关信息进行主题域的分析。分析的过程中要注意：主题模糊或不准确会影响后期决策分析效率。比如，若把病人作为主题会难以确定其属性和维度。病人这个主题对于医院决策来说过于泛化，必须将其细化到更具体的业务主题上。医院数据仓库建设的首要目标是进行主题域的分析，根据主题域，确定系统实现的业务主题。表1给出了建立医疗数据仓库涉及到的主要主题域。

目前国内大部分医院建立数据仓库的主要目的是为进行医疗费用分析。医院领导需要掌握医疗费用的分布情况，药费占整个医疗费用的比例以及大型医疗设备的利用率，以便控制不合理的费用增长;针对不同类型的患者调整费用项目和收费标准，从而达到提高服务质量、优化医院经营管理环境的目的。此外，医疗费用也从另一个方面反映了全院各科室的医疗收入情况，据此可以评价各科室的工作情况，评估收入分配指标，以便制定合理的医疗设备配置方案。本文以医疗费用数据集市的构建作为研究对象，其主题域包括门诊费用、住院费用、医疗费用构成等业务主题。

3 医疗数据仓库数据模型的设计

根据业务需求确定主题之后，首先考虑原有HIS系统产生的源数据，再执行数据的审计，为提供决策支持的数据建立模型。数据模型是实现数据仓库的基础，数据的逻辑模型、物理模型设计，规划了数据提取和数据转换的步骤。

3.1 维度建模

维度建模是一种逻辑设计技术，它的基本思想几乎是所有业务数据都可以表示成某种数据立方体。该立方体的每一个单元格包含的是各种测度值，立方体的边定义数据维度。

通常4步骤进行维度的建模：(1)选取要建立的业务处理过程;(2)定义业务处理的粒度;(3)选定用于每个事实表的维度;(4)确定用于形成每个事实表行的数字型事实。

本文选择医疗费用作为实施的业务主题，利用星型模式对医疗费用分析进行模型设计。采用星型模型、维度表直接与事实表相连，避免了维度的级别被分散在若干个表中，优化了数据仓库的查询响应时间，提高了查询性能。图2为住院病人费用业务主题的星型模型图。图中选取的业务处理过程为住院费用，业务处理的粒度如3.2节所介绍，根据对分析角度的需要选择了住院科室、费用科目等为事实表的维度，从药品费用、治疗效果等得到所需的维度量值。

3.2 粒度

粒度问题是设计数据仓库的一个最重要方面。粒度是指数据仓库的数据单位中保存数据的细化或综合程度的级别，细化程度越高，粒度就越小。低级别的粒度在对未预料的新查询方面的响应能力要比高粒度好得多。数据的粒度是一个设计问题，它深深地影响存放在数据仓库中的数据量的大小，同时影响数据仓库所能回答的查询类型。粒度的划分要根据业务需求而定，在数据仓库中的数据量大小与查询的详细程度之间做权衡。首先，估算数据仓库中数据的行数和DASD(Direct Access Storage Device)数;其次，由估算出的数据量和DASD数，确定是采用单一粒度还是多重粒度，以及粒度划分的层次。我校附属医院全年平均住院3,1000人次，目前医疗费用详细分类有65项。考虑到并不是所有患者住院期间都会发生全部各类医疗费用，通过估算一年产生关于医疗费用方面的数据大约为100万行以上，系统应该采用多重粒度划分。具体策略如图3所示。

3.3 物理模型

物理模型的设计需要将逻辑模型的设计转换为物理数据库，通常遵循以下的过程：首先制定命名标准、数据库标准和安全策略，然后创建物理模型，包括确定初始的数据库空间大小及其增长速度同时制定聚集计划。聚集计划是物理模型中的关键部分，对数据仓库的性能影响非常大。一旦确定了表的内容，就可以确定初步的索引策略，创建数据库的实例，最后规划物理模型的细节情况。数据分割是物理设计的一个重要问题，指把数据分散到各自的物理单元中去，它们能独立地处理，分割可以大大提高数据仓库的性能和可维护性。一般关系数据库都支持分割表的。在医疗数据仓库中，我们对费用科目维度表按时间(月、季度、年)进行分割，分割后的数据保存到单独的分割表中。这种维度分割方法减轻了数据仓库的维护负担。

4 数据转储的实现

使用Microsoft SQL Server2000数据库仓库组件中提供的DTS(数据传输服务)，将各种异构数据源合理的合并在一起，同时使用ActiveX脚本处理在数据传输过程中完成的验证、清洗和转换操作。利用SQL Server Agent可以调度DTS包的执行，实现自动、定期地进行数据传输。

5 系统的实现

建立了医疗费用数据仓库，用户访问数据仓库不是简单的存取和记录查询。基于多维数据集的OLAP是将数据想象成多维的立方体，通过对多维数据集进行切片、切块、聚合、钻取、旋转等进行数据的剖析，使用户从多种维度、多个侧面或多种数据综合查看数据，掌握数据背后蕴含的规律。使用Microsoft SQL Server2000中Analysis Services创建数据集，利用MDX可从指定的多维数据集中取得报表或表达式的计算值，MDX是OLAP与外界交互的专用语言。系统实现的功能：(1)医院各科室经营成本效益分析。通过时间维对科室不同时期的各种费用进行分析，找出收入增加或者减少的原因，对科室工作效率、经济效率、综合管理等方面的多项指标进行评价;(2)治疗结果的统计分析。根据统计分析数据，可以对病人的治愈率、死亡率、危重症抢救成功率等诊断指标进行分析;(3)各病种医疗费用分析和单病种费用构成分析。从科室角度对各病种医疗费用进行分析，有针对地控制费用比例，探究费用项目结构的合理性;也可从住院天数、病情、治疗方案等方面对单病种的治疗费用进行分析。(4)医院收入的相关因素分析。通过分析找出各种影响医疗收入的主要因素。

6 结束语

数据仓库作为一个新兴的研究领域，其建设技术具有很大的复杂性，仍有许多领域需要深入的研究。建立数据仓库系统是一个不断更新的、长时间的积累过程，用户可以随着应用水平的提高逐步加入更多的复杂的数据，为决策层分析医院指标体系提供详实的数据。

摘要：按照数据仓库生命周期的规律,依托我院现有的HIS系统,以医疗费用为主题构建医疗数据仓库。本文从建库的业务需求获取、数据模型的建立及数据仓库系统的实现等方面,介绍了建库的方法和步骤。该方法对其他医院建立数据仓库也有借鉴作用。

关键词：HIS,医疗数据仓库,数据维度,医疗费

参考文献

[1]王丽珍,周丽华,等.数据仓库与数据挖掘原理及应用[M].北京:科学出版社,2005.

[2]Ralph Kimball.数据仓库工具箱:维度建模的完全指南[M].谭明金,译.北京:电子工业出版社,2003.

[3]Ralph Kimball,等.数据仓库生命周期工具箱:设计、开发和部署数据仓库的专家方法[M].肖明,王永红,等,译.北京:电子工业出版社,2004.

[4]Efrem G Mallach.决策支持与数据仓库系统[M].李昭智,译.北京:电子工业出版社,2001:282-283.

[5]王克龙等.数据仓库中ETL技术的探讨与实践[J].计算机应用与软件,2005,22(11):75-78.

[6]林向阳,高展.数据建模在数据仓库中的应用[J].微计算机信息,2010,(26):183-185.

[7]Carter C L,Hamilton H J..Efficient_Oriented Generalization Knowledge Discovery from Large Databases[J].IEEE Transations on Knowledge and Data Engineering,2003,10(2):193-208.

医疗器械仓库保管制度 第2篇

1、仓库应以“安全、方便、节约”的原则，正确选择仓位，合理使用仓容，堆码合理、整齐，无倒置现象。

2、仓库周围无污染源，环境清洁。库房与营业场所应有隔离设施，面积与经营规模相适应。

3、近效期医疗器械要有明显的标志和示意牌。对效期在6个月以内的产品应按月填写近效期医疗器械催销表。

4、根据医疗器械的性能及要求，将产品库内温度控制在1-30度，湿度在45-75%之间。并实行色标管理，合格区为绿色、退货区为黄色、不合格区为红色。

5、库房内应配置垫仓板等与保持地面距离的设施、配置测量和调节温湿度设施、配置避光通风设施、配置符合要求的照明设施，配置消防、安全防鼠、防虫、防尘设施。

6、医疗器械养护员应做好夏防、冬防及梅雨季节的养护工作，定期检查储存产品的质量，对近效期产品视情况缩短检查周期。对库存和陈列产品每季实行定期检查，并有记录。

7、根据季节、气候变化，做好仓库温湿度管理工作，每日应上、下午各一次定时填写《库房温湿度记录表》，并根据具体情况和产品的性质及时调节温湿度，确保医疗器械产品储存和陈列质量的安全。

8、对储存和陈列中出现的产品质量问题，应及时报上级人员确认和处理，有上级人员通知停用产品，并将有问题的产品放入不合格区存放，待查明原因后，作退货或销毁处理，处理结果应有记录。若属假劣产品则应报当地药监部门，监督处理。

9、仓库应定期进行扫除和消毒，做好防盗、防火、防潮、防霉、防虫、防鼠、防污染工作。

如何建设数据仓库 第3篇

2008年，四川销售公司完成了ERP系统在全公司的全面推广，不仅实现了销售“一体化”管控，而且实现了财务业务无缝集成及物流、资金流、信息流的三流合一。2009年加油站管理系统在四川销售公司1400余座加油站部署实施，对加油站的采购、销售、结算、库存、客户、加油卡等进行全面的专业性管理，控制了零售业务的每一个环节，优化业务流程，提高运行效率和管理水平。2011年二次配送系统和油库系统在全公司推广运用，实现对油品品种、运输路径、运输车辆、油站库存、配送时间的统筹安排和优化，并对配送过程进行跟踪与监控，提高了配送效率和管理水平。2012年以ERP为核心的五大信息系统全面集成，油库、加油站、二次配送和ERP系统实现了信息数据自动流转，减少人为干预，提高了数据的准确性。2013年，销售应用集成系统将在四川销售公司试点运用，实现与各销售信息系统管理者视图的集成。

四川销售公司的各个信息系统几乎覆盖了公司的各项经营和管理的方方面面，这些业务操作型信息系统的上马和推广运用，不仅实现公司各个层面的管控信息化，而且为数据仓库建设提供了大量的历史数据源。

建设省级数据仓库的意义

四川销售公司建设省级公司的数据仓库是对中石油总部数据仓库数据支持功能的补充和完善，有利于提高信息系统数据利用效率，弥补总部数据仓库无法满足四川销售公司对精细化管理等方面信息数据挖掘利用需求的缺陷。

总部数据仓库“脏数据”过多。由于总部数据仓库涉及面广，涵盖了整个中国石油的勘探与生产、天然气与管道、炼油与销售、化工与销售和其他部分，因而数据非常庞大。假设仅仅以全国32家销售公司的数据在一起建立一个数据仓库，那么对于四川销售公司来说，不仅其他板块的数据甚至其他销售公司的大量数据基本上为“脏数据”（按32家来计算，96.8%的数据为脏数据）。大量的“脏数据”不仅牺牲了分析的效率，而且降低了分析质量。

总部数据仓库的数据粒度级过粗，无法满足四川销售公司个性化分析需求。全国中石油旗下加油站每日产生的可以作为客户分析价值高的卡交易记录，每日总共可达13亿条，平均每月记录过亿，所以在总部级数据上无法提供卡客户低粒度级的分析。在交易明细记录上，每年的记录数预计高达53亿条以上，在上亿条记录的数据库中做任何统计计算几乎都是要命的事，所以要总部数据仓库提供“购物篮分析”之类细粒度级的数据挖掘功能是不可行的。

总部级的数据仓库的主要服务对象不是销售公司一般管理者（特别是二级公司级以下的管理者）。总部级数据仓库对四川销售公司来说，还达不到提升管理和精细化管理的要求。2013年中石油总部推广运用的销售应用集成系统主要运用对象是销售公司、地区公司和地市公司的领导，提供日常办公、业务数据查询分析、业务决策、舆情监控和应急指挥等功能；而对于需要大量数据进行分析、挖掘的一般管理人员缺乏分析工具和支持。

数据仓库设计思路

建立四川销售公司的数据仓库不仅是总部数据仓库数据支持功能的补充和完善，而且是四川销售公司整合自行开发各类辅助管理信息系统，新增数据挖据分析、商务智能等需求的核心和基石。近年来，四川销售公司为了满足自身管理提升需要，陆续开发了加油站辅助管理系统、油库辅助管理系统、商品管理辅助管理系统、非油辅助管理系统等诸多管理系统。然而这些系统都相互孤立，信息数据没有集成共享，大部分数据靠人工干预，不仅大大增加了工作量，而且各类信息数据的完整性、正确性和及时性大打折扣，信息数据共享和挖掘功能无法真正发挥。“顶层设计”的总部数据仓库的数据主要来源于五大系统，虽然确保了不同销售企业执行同一管理标准，为系统顺利集成、统一应用、科学评价奠定了基础，但是无法满足因地区和管理差异而新增的个性需求。特别是涉及到与四川本地相关的数据上，总部数据仓库几乎是空白。例如分析四川销售公司及其各个二级的销售总量、增幅与四川省及其对应地市GDP的总量、增速、能耗的关系时，总部级数据仓库是无法提供的。如果四川销售公司有自己的数据仓库，就可以把四川省及其对应地市GDP的相关数据作为外部数据源进行采集分析。再如需要分析路网建设、竞争对手网点布局对公司自身销售的影响时，必须要有独立的数据仓库，才能快速地得到量化的、科学的分析结果。有了数据仓库，商务智能才成为可能。没有数据仓库，商务智能只能是一个理论。

综合上述多方考虑，结合中国石油四川内江销售公司的研究成果、业务经营管理现状和前期需求调研分析，四川销售公司的主题需求可分为油品销售分析、非油品销售分析、卡客户分析、商品管理分析、加油站配送分析、财务分析、人力资源分析和市场分析八个主题。根据四川销售公司信息系统运用状况，数据源将涉及内部信息系统的有ERP、HOS、FMIS、油库、二配、加油站管理等，其中市场分析涉及外部数据的采集。

数据仓库系统接口设计

将数据放置在数据仓库中既是建设的难点，也是起点。一般数据集成和转换的过程需要花费约整个数据仓库建设80%的开发资源。由于ERP、HOS、油库、FMIS等操作型系统是总部统一开发设计，接口的最佳方式是总部能够提供对应的数据接口。但是由于“顶层设计”需要，总部没有开放相关数据接口。如何建立ERP等系统和数据仓库之间的接口，如何构思编写ETL软件实现自动将ERP等操作系统历史数据到数据仓库中，是四川销售公司构建自己数据仓库的重点和难点，这也是数据仓库攻关的难点。

通过对当前使用的ERP等系统的调研和分析发现，对于所有系统的数据源可以分为三类。一类是有数据库访问方法的系统（例如加油站管理系统的站级系统）；第二类是没有数据库访问方法的系统，但有统一的数据导出方式的系统（例如ERP、HOS、FMIS等）；第三类是既没有数据库的数据源，也没有统一的数据导出方式的系统（例如外部系统数据）。第一类由于能直接访问数据库，ETL设计的重点是数据的清洗和集成；第二类有统一的数据导出方式，ETL设计的重点是数据的采集、纠错和集成；第三类只能依靠设计模版，人工统一导入相关数据。因此对不同系统数据采集接口需采用不同的方法。

nlc202309041210

数据的集成到清洗

数据集成、转换和清洗数据是提高数据集成和提高利用效率的必要步骤。数据在从操作型环境向数据仓库环境的传送过程中所经历的转换非常复杂，一是DBMS的变化，二是操作系统的变化，三是硬件体系结构的变化，四是语义的变化和编码的变化等，所以必然存在转化和清洗。在这个过程中首先要将数据集成，当数据进入仓库时，要对各个应用的不同值进行正确的译码，重新编码为合适的值；其次必须建立各个不同源字段到数据仓库字段的映射；然后还需将各个系统不同技术存储的数据必须转换到同一种技术下存储。

在数据的转换与再清洗过程中，可以将数据以一种称为“时间间隔”的方式装载进入数据仓库，操作型环境新更新的数据可以在操作型环境中停留达24小时，然后才转移到数据仓库。例如在加油站管理系统得TILLITEM（交易明细记录表）含有大量的控制类数据，我们取数主要取对应的交易序号、营业日期、油品、价格、数量、金额、折扣、支付方式、卡号、枪号、罐号、起泵、止泵等数据。

保证数据采集准确性

数据的正确性验证是提高数据仓库数据准确有效的必要措施。提高访问现有系统数据采集正确主要有五种方法：一是扫描在操作型环境中那些被打上时间戳的数据（例如采集ERP等系统的销售订单时以创建时间为准，因为创建时间是系统自动生成的时间，不能任意更改）；二是只扫描增量文件（例如采集加油站管理系统的站级数据）；三是对取数机制进行了程序自动纠错，对没有获取完全的数据自动重新获取；四是对后台数据载入清洗程序进行修正，增加容错机制，对数据临时变化等问题进行了日志记录；五是将有对应关系的数据采集后进行对比（例如HOS的油品销售日报与ERP系统的纯枪销售订单进行对比），这种方法相对麻烦、复杂。其纠错验证在导入数据仓库前的临时数据库里，一旦验证正确后，方才导入到数据仓库。

此外，外部数据的采集对于数据仓库的建设格外重要，因为可以在一定时间范围内将外部数据与内部数据进行比较，以便给管理者提供一个独特的视角。例如天气变化给公司销量的影响是多少，节假日对公司销量的影响是多少，各个二级公司销量与GDP总量的关系，各个二级公司销售增量与GDP增量的关系？对此，有必要针对主题需求，增加成品油价格行情，四川（各地区）天气记录，四川（各地区）GDP数据（总量、增幅、能耗等）等外部数据的录入。

细化数据粒度

数据的粒度与分区是进行数据仓库设计决策的两个最重要方面。保存所有细节数据是错误的，一是存储和处理的开销可能是个天价；二是大量数据是有效分析技术的一个障碍；三是前面做的细节分析不可复用。所以对于四川销售公司来说，采用双重粒度是非常有意义的。

根据测算，全四川省站级系统的交易明细记录表一年的总记录数超过亿条，卡交易明细记录表一年的总记录数也有千万以上。所以，必须要根据DSS（决策分析）主题需求，进行双重粒度设计和分区。例如可以对卡交易记录进行概要记录统计（例如开卡时间、总消费额、消费次数、最大消费额、最小消费额、消费品种、消费区域、最近消费时间），便于以后的卡客户的相关分析，而对交易明细进行海量存储；同时可以对数据进行分区设计，比如按照年度来分区。这样大大提高了数据近期数据的访问速度。

由于非油业务开展还处于初级阶段，预计一年的记录数据估计在几百万条，可以保存做类似“购物篮分析”的数据挖掘运用。所以需要对卡交易明细和非油交易明细进行不同粒度的设计，以尽可能低的数据粒度来满足四川销售公司DSS分析。

数据集市设计与构想

数据集市主要是针对数据仓库的主题进行设计。例如在数据仓库体系结构中将四川销售公司的主题需求分为油品销售分析、非油品销售分析、卡客户分析、商品管理分析、加油站配送分析、财务分析、人力资源分析和市场分析八个主题。其中每个主题对应一个数据集市，每个数据集市的数据来源于数据仓库。这样四川销售公司的辅助管理系统都可以从数据仓库中来获取数据，而且也可以根据后期需求不断调整。例如每次调价对四川销售公司销量的影响（上调、下调），地震对四川销售公司的销量的影响分析，卡客户购买非油货品的比例，卡客户购买非油货品中哪种商品最多，卸油时停止加油对公司的销量有多大影响，某个加油站从开业以来每天的销售数量的分析趋势图，某张加油卡在四川销售公司所有加油站的消费情况，新的激励机制出台后对公司销量的影响有多大等需求。只要对数据仓库设计时不断地完善与修正，数据做到准确、及时、完整，实现上诉需求科学量化的分析是完全可以的。 （作者单位：张中淋 中国石油内江销售公司；李亮、陈涛 中国石油四川销售公司）

医疗数据仓库 第4篇

随着医疗信息化建设的不断深入,医院信息系统的覆盖范围已经涉及到医院运营的各个环节,例如临床医疗、行政管理、财务管理、知识管理、决策支持、患者服务、内外沟通、医保、体检、双向转诊、外部接口等。同时,医院信息系统是随着信息技术自身的发展和医院的需求而逐步建设的,因此,现阶段在医院中存在着不同时期、不同厂家建设的子系统,服务于医院的不同需求。但这些系统之间相对孤立,数据共享困难,数据标准不统一,不利于分析决策。医疗数据仓库[1,2,3]可以提供唯一的事实版本,方便医护人员利用仓库中的数据执行数据分析、知识发现和战略战术数据决策。医疗数据仓库遵循常规的数据仓库建设原则,但也与银行电信业传统的数据仓库建置方法有所不同。

1 医疗数据仓库系统特点

1.1 医疗数据仓库系统拥有下述传统数据仓库的一些特点:

(1)医疗数据仓库系统是建立一个能解决跨部门、跨业务、跨时间和跨信息平台的复杂的信息整合问题,可支持复杂的信息检索及在线访问、可处理海量数据的系统,即基于中央数据仓库的基础数据平台系统。(2)医疗数据仓库将以规范的形式集中医院的信息资源,强调数据视图在医院范围的一致有效和充分共享,为管理和决策科学化提供基础信息。(3)医疗数据仓库能支撑医疗机构目前和未来的各种管理和分析型应用,比如病案管理、医疗统计、院长综合查询与分析、病人咨询服务、绩效管理、客户关系管理等;能为医疗机构内部和外部(医保系统、社区医疗系统、远程医疗系统及各级卫生行政主管部门等)提供数据接口。(4)数据仓库遵循“统一规划、统一数据标准、统一数据模型、统一技术标准,分步实施开发”的原则。应用有统一的数据源,客户有统一的应用访问接口。

1.2 除了上述这些特点外,医疗数据仓库系统还有自己的一些独特之处:

(1)虽然医疗数据仓库也是按主题保存历史数据,但医疗行业数据模型与银行电信业的数据模型有很大不同,医疗行业有HL7、DICOM、ICD9等行业标准。仓库数据模型也应遵循这些行业标准建设,以方便数据集成和数据共享。(2)医疗数据仓库应充分考虑非结构化数据,尤其是图像数据的存储和检索机制。像PACS和RIS这样的系统每家医院都会存在,这些系统中存储了大量的医疗图像文件,以往这些图像文件没有被数据仓库纳入考虑范围内。随着Hadoop这样的分布式大数据处理平台的出现,为下游系统提供图像文件检索服务的医疗数据仓库必会成为新的发展趋势。(3)医疗数据仓库对实时性要求比传统的数据仓库要高,传统的数据仓库以OLAP分析为重,即时查询的时间窗口往往限制在30分钟左右,而医疗数据仓库的时间窗口会限制在数分钟以内,否则病患等待的时间会过长,数据仓库所起到的专家分析的作用就会大打折扣。

2 医疗数据仓库系统应用架构

本文提出的医疗数据仓库系统应用架构包括源数据层、ETL层、逻辑模型层、仓库层、系统应用层、BI分析层、访问层和用户层,如图1所示。

2.1 源数据层

HIS(Hospital Information System,医院信息系统)[4]、LIS(Laboratory Information System,检验科医疗信息系统)[5]、RIS(Radiology Information system,放射科医疗信息系统)[6]、PACS(Picture Archiving&Communication System,医学图像归档与通讯系统)[7]、OA(Office Automation,办公自动化系统)[8]、EMR(Electronic Medical Record,电子病历系统)[9]等各种系统都是仓库系统的上游源系统。此外,数据仓库可以直联各种异构环境中的外部DBMS、数据文件和元数据文件,为了支持这一点,数据仓库系统要构造各种不同的接口。

2.2 ETL层

ETL层要借助内外部的ETL调度工具建立起一套完善的、自动化的ETL体系,完成对来自源数据层的数据抽取、清洗、加载、转换程序的调度管理。ETL调度工具可以使用DataStage、PowerCenter等业界常见的专业调度工具,有一定开发实力的企业还可以自行定制ETL调度工具,完成自己的特色功能。

2.3 逻辑模型层

数据经过ETL层的加载、转换后,要由逻辑模型层采用面向主题的设计方法,有效组织来源多样的业务数据,以统一的逻辑语言描述医疗信息,逻辑模型层有效地屏蔽了数据仓库内部数据的物理组织模式。逻辑模型可以满足各个医疗科室的业务需求和它们不同的数据访问方式,可以有效地保证数据的一致性,是实现业务智能的重要基础。

2.4 仓库层

仓库层完成数据的物理建模,结合逻辑模型层的结果,完成数据库表的优化设计,并针对不同类型的用户提供不同权限的访问视图。物理建模的任务是数据库表结构定义、数据类型定义、逻辑模型到物理模型的映射规则定义、索引定义、降范式处理、性能优化、容量规划等。ETL层加载进仓库的数据,经过逻辑模型层的规范化处理后,由仓库层完成真正的物理存储,仓库层的存储要充分考虑图像等非结构化数据的检索供应需求。

2.5 应用层

应用层是医疗数据仓库的下游信息系统所在层,这些系统包括了源系统层中为数据仓库供数的系统以及其他需要数据仓库提供一致数据的系统。下游应用可能会向仓库提出对图像等非结构化数据的检索要求。

2.6 BI分析层

BI分析层是建置在应用层上的一个通用层,本层实现OLAP、报表、统计分析、即时查询分析等功能。本层需要由专业数据仓库实施人员根据医疗人员具体的业务需求完成抽象实现,形成通用的功能模块或过程库。

2.7 访问层

访问层指的是访问医疗数据仓库的渠道,包括浏览器、移动终端、电视墙和其他第三方工具等。以往访问层往往只包含浏览器或定制客户端应用,用户通过这些渠道访问BI分析层提供的展示结果,但随着i Phone和Android智能移动终端的流行,企业在这些方面的需求越来越强烈,移动终端对数据仓库的推拉访问已经成为医疗企业的普遍要求。

2.8 用户层

包括病患、医生、护士、药剂师、医院领导等访问数据仓库的各类用户组成了用户层,他们有着个性化的需求,本层主要完成个性化配置、信息推送、信息报送等功能。

该应用架构反映了数据从源系统到最终用户的串行流程,是医疗数据仓库实施规划的理论指导。

3 医疗数据仓库实施规划

以上述医疗数据仓库应用架构为指导,结合医院自身的特点以及传统数据仓库的实施方法,医院在建设自己的医疗数据仓库时可采用下面的建设步骤,其中一些步骤可以组建小型团队并行完成:

(1)源系统分析与上游接口开发;(2)ETL设计与开发,可能会包括ETL工具的定制化开发;(3)逻辑数据模型和物理数据模型设计、物理数据库设计和数据映射;(4)医疗报表与运营指标分析开发;(5)应用门户与应用接口的设计与开发,可能会根据需要包括网页客户端与手机客户端的设计开发工作;(6)用户权限管理与系统管理模块开发;(7)系统测试和投产。

在整个过程中,医院要结合自身的情况投入不同比例的人力、物力和财力,全力配合厂商的实施工作,并且要做好项目的日常管理、项目计划管理、项目质量管理、项目资源管理等工作。

4 小结

随着医疗信息化建设的逐步推广,HIS、PACS、LIS、OA、EMR、CRM、EHR等医疗卫生信息系统越来越多。多年下来,这些系统积累大量的医疗相关数据,但目前各个系统兼容性差,资源共享困难,给医院的经营决策和分析造成了很大的难度。医疗数据仓库可以比较好地解决数据集成和数据共享问题,为医院内部的分析人员提供很好的数据基础,完成数据分析、知识发现和战略战术数据决策。

现阶段医疗数据仓库在即时查询、非结构化数据处理等方面都亟待完善,内存计算、Hadoop分布式架构等技术的出现都将有助于医疗数据仓库在这些方面的提升。

摘要：随着医疗信息化建设的不断深入,许多医疗信息系统被创建出来,产生了大量的数据。目前,这些系统之间相对孤立,兼容性较差,数据共享困难,采用的数据标准不一致,不利于分析决策。文章着重介绍了一种面向医疗机构的数据仓库应用架构,数据仓库可以提供唯一的事实版本,方便医护人员利用仓库中的数据执行数据分析、知识发现和战略战术数据决策。

关键词：数据仓库,应用架构

参考文献

[1]Pedersen,T.B.Jensen,C.S.Research Issues in Clinical Data Warehousing.Proceeding of Tenth International Conference on Scientific and Statistical Database Management.1998,43-52.

[2]李琪,白英彩.数据仓库中时态视图的维护.软件学报,2002,13(7):1324-1330.

[3]李建中,高宏.一种数据仓库的多维数据模型.软件学报,2000,11(7):908-917.

[4]Guojun Yang,Ying Zheng,Gang Wang.An Application Research on the Workflow-based Large-scale Hospital Information System Integration.Journal of Computers.2011,6(1).

[5]Connelly DP.Embedding Expert Systems in Laboratory Information Systems.American Journal of Clinical Pathology.1990,94(4Suppl1):7-14.

[6]Janice C.Honeyman-Buck.Radiology Information Systems.Encyclopedia of Medical Devices and Instrumentation,2006.

[7]R.L.Arenson.Picture Archiving and Communication Systems.The Western Journal of Medicine".1992,156(3):298-299.

[8]Scherrer JR,Revillard C,Borst F,Berthoud M,Lovis C.Medical Office Automation Integrated into the Distributed Architecture of A Hospital Information System.Methods of Information in Medicine.1994,33(2):174-9.

数据仓库中的数据清洗 第5篇

随着时间的发展,医院信息系统中积累了大量的业务数据,越来越多的医院选择建立数据仓库以提取其中有用的信息,用于分析和决策。病种分析就是当前比较热门的主题,可以通过病种分析主题考察单病种的治愈质量、平均费用、平均住院日及单病种的病人构成情况,有利于单病种的合理限价,提高医院的竞争力。病种分析的星型结构如图1所示。病种分析中涉及到众多的数据,数据的准确与否直接关系着决策质量的好坏。为了能够准确的决策,必须对进入数据仓库的数据进行清洗。

由于数据的清洗需要占用系统较多的资源,为了不影响"军卫一号"日常的处理速度,同时保证数据尽可能的准确,我们采用了"二次清洗"的方法:将源数据抽取至数据缓冲区时进行第一次的数据清洗;将数据缓冲区的数据送入数据仓库时进行第二次的清洗,两次清洗的作用范围是不同的[1]。清洗的过程如图2所示。

1 第一次清洗

病种分析涉及到"军卫一号"中的5张相互关联的业务数据表,14张公用字典表,第一次清洗主要是负责清洗源表中的"脏数据",本次清洗在数据缓冲区中进行。根据"脏数据"种类的不同,有下面四种清洗的途径。

1.1 业务数据表间关联的清洗[2]

病种分析主题中所需要的源数据来自"军卫一号"中的不同的五张表:诊断分类记录DIAGNOSTIC_CATEGORY、诊断对照记录DIAG_COMPARING、诊断记录DIAGNOSIS、住院病人主记录PAT_VISIT、门诊诊断记录CLINIC_DIAGNO-SIS,这五张表可以通过相应的字段相互关联。这时,数据清洗要做的就是检查这些表间是否能够一对一的关联起来;若不能关联,则必须找出不能关联的记录,对这些记录中的相关字段进行清洗。由于可以通过诊断分类记录中的键值与其余四张表中相同的字段相关联。因此,我们选定诊断分类记录作为主表,其余的四张表作为辅表,利用sql语句中的left outer join来确定不能与主表建立关联的辅表中的记录。诊断记录通过病人标识PATIENT_ID、病人本次住院标识VIS-IT_ID和诊断序号DIAGNOSIS_NO与诊断记录中相对应的字段相关联,以获取病种的治疗天数、诊断质量、诊断类型。两表间的关联程度,可通过如下sql语句来实现:

通过上述的sql语句,可以查看诊断分类记录中不能与住院病人主记录相关联的记录。对这些不能关联的记录,不能马上将其判断为"脏数据",还必须做具体的考虑。由于诊断记录是用来记录住院病人的诊断情况的,而诊断分类记录中的记录既包含住院病人又包含门诊病人的诊断分类情况,因此,诊断分类记录中不能与诊断记录关联的记录,有可能是与门诊诊断记录CLINIC_DIAGNOSIS相关联的。这种情况下,应再次利用left outer join语句,将上面的查询结果作为左表,门诊诊断记录作为右表,在删除诊断分类记录中与门诊诊断记录相关联的记录后的记录才是真正的"脏数据"。对于这些"脏数据"的处理,我们在与诊断记录中添加了一条"默认记录",当诊断分类记录不能关联到诊断记录时,则自动关联"默认记录"中的数据。"默认记录"中的具体数,采用极值法获得,即将合法的诊断记录中各字段出现频率最高的值作为"默认记录"中相应字段的默认值。

1.2 业务数据表与公共数据字典间的关联

理论上,"军卫一号"中业务数据表凡是涉及到公用数据字典的字段,都必须将数据业务表中的相应字段作为外键与数据字典表关联,如病人住院主记录中的出院科室DEPT_DISCHARGE_FROM作为外键关联科室字典DEPT_DICT中的科室代码DEPT_CODE。但系统为了性能的考虑,在一定程度上舍弃外键约束,导致了数据的不一致。对于这种类型的数据清洗,首先应从业务表中提取出不能与公共字典对应的记录,再制定相应的规则对其进行转换。同样以病人住院主记录中的出院科室DEPT_DISCHARGE_FROM为例说明,这种类型数据清洗的过程:(1)提取病人住院主记录中出院科室不能与科室字典中的科室代码对应的记录,可利用sql语句的not in语句来找出出院科室不符合科室字典要求的记录:

(2)制定转换规则,对步骤(1)中得到的数据进行清洗:訩在科室字典中新增一条记录,令科室代码DEPT_CODE="FF",科室名称DEPT_NAME="其他科室";訪病人住院主记录中不符合要求的出院科室全部更新为"FF",将其归为"其他科室";

1.3 数据空值的清洗

对于空值的处理是数据仓库中一个常见问题,是将它作为脏数据还是作为特定一种维成员,应根据实际情况进行判断。一般的做法是视表中空值字段有无分析价值而定。

(1)对于没有分析价值的字段,如病人住院主记录中的尸检标志、联系人姓名、联系人邮编等属性,在病种分析主题中没有分析的价值,可直接忽略,不进行清洗;(2)对于有分析价值的数据,则必须根据实际情况对空值进行判断,转化为特定的值。如,病人住院主记录中的出入院科室等属性,主要用于构成病种分析主题中科室维度的外键,具有分析价值,必须保留,若出入院科室代码为空,则将其转换为"FF"(对应于科室字典中的"其他科室")。对于其他为空的有分析价值的属性,也可以采取类似的转换办法,给空值字段赋予特定的值。

1.4 不符合逻辑要求的数据

所谓不符合逻辑要求的数据,指的是不符合现实规律的数据,这种类型的"脏数据"主要集中在涉及到日期的字段。如病种分析中的度量之一--某一病种的住院天数。"军卫"中的表没有直接涉及到住院天数,需从病人住院主记录中提取病人入院和出院时间,将两字段相减而得到。为了分析的精确,就必须对病人的出入院的日期进行两方面的逻辑检验:病人的出入院时间是否小于系统当前时间、病人的出院时间是否晚于病人的入院时间。对于不符合要求的数据,采用"均值法"进行替换,即计算出符合逻辑要求的记录的平均住院天数,将此平均住院天数赋给不符合要求的记录。

2 第二次的数据清洗

第二次的数据清洗的主要任务是从经过第一次清洗后的源表中抽取所需要的维度信息。

病种分析中,所涉及到的维度除了科室维、费别维可以分别利用科室字典和费别字典直接得到外,其他的维度时间维、病人年龄维、地理维、病种维等维度均要从源表中抽取相应的字段再经过转换而得到。一般来说,维度都是具有层次结构的。因此,按维度层次的清洗顺序,可将维度的清洗分为三种方法:正向清洗、反向清洗及两种的综合。

所谓的正向清洗是指对有层次维度,先取得父维度的信息,再根据父维度信息提取子维度的信息,这样做的好处是可以逐步缩小清洗的范围。反向清洗是指根据子维度的信息,向上查找父维度的信息,适合于子维度已知且子维度仅属于一个父维度的情况。而综合清洗则是指两者的综合。

2.1 反向清洗

以病种维为例,说明病种维建立的过程。病种维采用层次结构,按病种大类、病种中类及疾病名称构成父子层次维度,且一种疾病只对应唯一的病种大类和病种中类。

源表中没有病种大类及病种中类的字段,诊断分类记录的诊断代码DIAGNOSIS_CODE,即疾病代码是按ICD9编码的。因此,为了获取病种大类和中类,必须新建一张按ICD9编码的病种分类字典,将诊断代码DIAGNOSIS_CODE作为外键与病种分类字典相连。病种分类字典的表结构如表1所示。

获取病种大类与中类的办法是,根据诊断代码,到病种分类字典里取得病种大类与病种中类。同时,通过诊断代码到"军卫"中的诊断字典DIAGNOSIS_DICT中获取疾病名称。

2.2 综合清洗

以地理维的清洗为例,说明维度综合清洗的过程。地理维用于存储病人所在地的信息,源表中没有属性直接指明病人的地理信息,但可以通过对病人住院主记录中的通信地址MAILING_ADDRESS的清洗而得到。第一次的清洗中已将病人住院主记录中的通信地址MAILING_ADDRESS为空的记录用特定值代替(该指定值为医院所在地)。

地理维分为省、市、区/县三个层次。其中省为父维度,市为省的子维度又同时为区/县的父维度,而区/县则为市的子维度,即一个省中包含若干个市,一个市中又包含若干个区/县。为了从通信地址中提取这三个层次的信息,需要在数据缓冲区增加一张地区层次字典LEVEL_AREA_DICT,表结构如表2所示。

对地理维度的提取,先采用正向清洗的办法,即对每条记录中的通信地址在地区层次字典中进行三次遍历,依次得到省、市、区/县的层次维度信息。清洗的过程如图3所示。

图3中,用黑色箭头标注的为正向清洗的过程,先查找通信地址是否包含地区层次字典中的PROVINCE字段:(1)若通信地址中包含此子字符串,则继续向下查找是否包含所在省中的CITY子字符串;(2)若不包含,则遍历字典中所有的CITY(市),查找通信地址中是否包含字典中的CITY字段,若查找得到,则分两路进行清洗:訩根据所在市,向上查找该市所在的省;(图3中用红色箭头标注的部分);訪根据遍历地区层次字典中属于该市的所有区/县,向下查找通信地址中是否包含其中的区/县信息。

地理维度中病人所在市、区/县的查找过程大致与所在省的查找过程类似。

3 结语

本文绍了病种分析中的数据清洗的具体方法,对数据仓库中其他主题数据的清洗,也可以采用类似的办法进行。但在数据清洗方面,仍然有许多值得思考和优化的地方,以进一步提高清洗的效率。如,病种分析每月的数据量多达几百万条记录,大表之间的关联必然存在性能和稳定性的问题,必须优化它们的关联;另外,对于大数据的处理无疑会占用太多的系统资源,出错的几率非常大,如何做到有效错误恢复也是个问题[2]。

参考文献

[1](美)W.H.Inmon著.数据仓库.王志海等译.北京:机械工业出版社,2001.

浅析数据仓库与数据挖掘 第6篇

一、数据仓库

1、数据仓库概述

“数据仓库之父”William H.Inmon在90年代初提出了数据仓库概念:“一个数据仓库通常是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合, 它用于对管理决策过程的支持。”

(1) 面向主题:主题是一个抽象的概念, 是在较高层次上将企业信息系统中的数据综合、归类并进行分析。在逻辑意义上, 它是对应企业中某一宏观分析领域所涉及的分析对象, 是针对某一决策问题而设置的。面向主题的数据组织方式, 就是在较高层次上对分析对象的数据的一个完整的、统一的、一致的描述, 能完整、统一地刻画各个分析对象所涉及的企业的各项数据, 以及数据之间的联系。

(2) 集成的数据:数据仓库的数据不能直接从原有数据库系统中得到。原有数据库系统记录的是每一项业务处理的流水账, 这些数据不适合于分析处理, 在进入数据仓库之前必须经过综合、计算, 抛弃分析处理不需要的数据项, 增加一些可能涉及的外部数据。数据仓库每一个主题所对应的源数据在原分散数据库中有许多重复或不一致的地方, 必须将这些数据转换成全局统一的定义, 消除不一致和错误的地方, 以保证数据的质量。

(3) 数据不可更新:这是指当数据被存放到数据仓库中以后, 最终用户只能通过分析工具进行查询、分析, 而不能修改其中存贮的数据。

(4) 数据随时间不断变化:数据仓库数据的不可更新是针对应用而言, 即用户进行分析处理时不对数据进行更新操作, 但不是说, 数据从进入数据仓库以后就永远不变。数据仓库中的数据随时间变化而定期地被更新, 每隔一段固定的时间间隔后, 运作数据库系统中产生的数据被抽取、转换以后集成到数据仓库中, 而数据的过去版本仍被保留在数据仓库中。

(5) 使用数据仓库:建立数据仓库的目的是为了将企业多年来已经收集到的数据按一个统一、一致的企业级视图组织、存贮, 对这些数据进行分析, 从中得出有关企业经营好坏、客户需求、对手情况、以后发展趋势等有用信息, 帮助企业及时、准确地把握机会, 以求在激烈的竞争中获得更大的利益。

2、数据仓库的数据组织

数据仓库采有以下不同的组织形式:简单堆积文件组织方式, 是将每天由数据库提取并处理后的数据逐天存储起来。在定期综合文件组织方式中, 数据存储单位被分成日、周、月、季度、年等多个级别, 数据被逐一的添加到每天的数据集合中。

3、数据仓库的逻辑、物理结构

数据仓库是存储数据的一种组织形式, 它从传统数据库中获得原始数据, 先按辅助决策的主题要求形成当前基本数据层, 再按综合决策的要求形成综合数据层 (又可分为轻度综合层和高度综合层) 。

数据仓库中数据的物理存储形式有多维数据库组织形式 (空间超立方体形式) 和基于关系数据库组织形式 (由关系型事实表和维表组成) 。在数据立方体上可以进行上卷或下钻等OLAP (联机分析处理) 操作, 即对不同的数据层次进行概化或细化。

二、数据挖掘

1、概念

数据挖掘是从大量的、不完全的、有噪声的、模糊的、随机的数据集中识别有效的、新颖的、潜在有用的, 以及最终可理解的模式的非平凡过程。

2、数据挖掘的功能

(1) 自动预测趋势和行为:数据挖掘自动在大型数据库中寻找预测性信息, 以往需要进行大量手工分析的问题如今可以迅速直接由数据本身得出结论。

(2) 关联分析:数据关联是数据库中存在的一类重要的可被发现的知识。若两个或多个变量的取值之间存在某种规律性, 就称为关联。关联可分为简单关联、时序关联、因果关联。关联分析的目的是找出数据库中隐藏的关联网。

(3) 聚类:数据库中的记录可被化分为一系列有意义的子集, 即聚类。聚类增强了人们对客观现实的认识, 是概念描述和偏差分析的先决条件。

3、概念描述

概念描述就是对某类对象的内涵进行描述, 并概括这类对象的有关特征。概念描述分为特征性描述和区别性描述, 前者描述某类对象的共同特征, 后者描述不同类对象之间的区别。

4、偏差检测

偏差检测的基本方法是寻找观测结果与参照值之间有意义的差别。

综上所述, 数据挖掘的任务就是从存放在数据库、数据仓库中的大量数据中发现有用的信息。数据仓库技术是为了有效的把数据集成到统一的环境中以提供决策型数据访问的各种技术的总称。

摘要：本文介绍了数据仓库和数据挖掘概念、数据仓库的数据组织结构及数据挖掘的功能进行了探讨。

关键词：数据仓库,数据挖掘

参考文献

[1]苏新宁, 杨建林, 江念南, 粟湘, 《数据仓库与数据挖掘》, 清华大学出版社, 2006年[1]苏新宁, 杨建林, 江念南, 粟湘, 《数据仓库与数据挖掘》, 清华大学出版社, 2006年

[2]安淑芝等《数据仓库与数据挖掘》, 清华大学出版社, 2005年[2]安淑芝等《数据仓库与数据挖掘》, 清华大学出版社, 2005年

数据仓库中数据清洗技术分析 第7篇

数据仓库 (DW) 作为相对稳定的、集成的、面向主题、反映历史变化的数据集合, 多用来支持管理决策。结合数据仓库的定义可知, 数据仓库具有相对稳定的、集成的、面向主题、反映历史变化的特点: 相对稳定的特点是指数据仓库的数据多用来支持企业决策, 因此数据仓库内的数据往往被长期保留, 而数据操作多为数据查询或数据的定期加载及刷新; 集成的是指数据仓库的数据多由分散的数据经系统加工、汇总、整理所获取, 因此必须确保存储的数据仅与特定企业相关联; 面向主题是指数据仓库的数据始终围绕特定主题进行汇总, 且该主题往往与若干操作型信息系统有关; 反映历史变化是指数据仓库的数据往往涵盖着诸多历史信息, 即系统记录着特定企业某段时间内的所有信息, 且管理者能据此预测该企业的发展历程及发展趋势。数据仓库的体系结构如图1所示。

2 数据清洗技术的应用

数据仓库的数据清洗过程, 重复记录的清洗起着关键性的作用。着重从重复记录的清洗角度, 探究数据仓库的数据清洗技术的应用。

2.1 数据清洗原理

数据清洗是指依据数据挖掘及数理统计的清洗规则, 把脏数据转化为高质量的数据。数据清洗的原理如图2所示。

数据清洗要求把冗余或错误的数据删除及对对象进行识别, 注意数据清理往往需要与数据转换同步, 即实现异构数据源的集成及数据的迁移。

2.2重复记录清洗

2.2.1重复记录清洗的含义

结合前文内容可知, 数据仓库的数据应保持独有性, 但多数据源的集成过程, 极易出现输入错误、拼写错误等误操作, 由此导致数据仓库的特定数据存在多种表示形式, 即特定实体对象与多条记录相对应。如此, 势必损害信息的一致性, 甚至导致资源浪费。可见, 对重复记录的清洗具有现实意义。重复记录的清洗必须始终遵循下列步骤: 预处理→重复记录检测→数据库级的重复记录聚类→冲突处理。预处理是指选择与记录相匹配的属性, 同时给此属性分配相应的权值, 注意重复记录的清洗过程, 可采用调整权重的方式来确定重复记录。重复记录检测是指对字段与记录匹配问题的解决。数据库级的重复记录聚类是指运用重复记录算法来缩小记录比较的范围, 同时对数据库的重复记录予以聚类 处理。冲突处理是指依据特定规则来删除或合并聚类的 重复记录 。重复记录检测算法的效率常用所采用的算法能否检测出数据库内所有重复记录来进行衡量, 且比较常用的标准包括误识别率、召回率及准确率。误识别率是指被重复记录检测算法误识别的重复记录与被此算法识别出的重复记录 间的比值 ,注意误识别率与算法结果的置信度呈正相关。召回率是指被重复记录检测算法准确找出的重复记录与数据库内所有重复记录间的比值。准确率是指重复记录被误识别的概率。

2.2.2重复记录清洗的算法

重复记录消除以前, 可就合并后的数据集进行匹配, 且常用的检测重复记录的算法包括基本的字段匹配算法、递归的字段匹配算法、Smith Waterman算法等。研究表明, 最有效的检测重复记录的算法为就数据仓库的每对记录进行 比较 ,但此算法的耗时及复杂度均较大。排序与合并作为消除重复记录的核心思想, 即要求先对数据库的记录进行排序, 随后再采用比较临近记录的方式来检测重复记录的部分。据调查结果显示, 常用的检测重复记录的算法多采用此思想, 比如优先队列 算法、排 序邻居算 法 (SNM) 、多趟排 序邻居法(MPN)。

(1) 排序邻居 法

排序邻居法要求首先以给定的关键字为依据, 排列数据库的记录, 然后以此为活动范围, 移动大小固定的窗口, 注意此时仅对窗口覆盖到的记录进行检测及对此部分的匹配情况进行判断, 以控制记录的比较次数。假设窗口覆盖有n个记录, 那么窗口移动过程, 移出第一条记录以后, 便可比较判定n-1条记录与新进的记录间的匹配情况。就给定的超过1个的数据库而言, 排序邻居法要求先把数据库的记录进行聚类以后, 再把此部分数据库的记录合并成数据集, 最后再进行匹配。基本的排序邻居算法要求按下列步骤进行重复记录的清洗: 构造排序关键词 (以抽取表内字段的方法来生成与记录相对应的关键词) →对记录排序 (依据已生成的关键词,排列数据库的记录) →检测 (就排序的记录集, 依次移动大小固定的窗口, 注意仅对窗口覆盖到的记录进行比较, 以判断此部分记录的匹配程度)。研究表明, 尽管排序邻居法的应用对实现重复记录的清洗意义重大, 但同时也存在如下缺点亟待解决, 比如排序关键字对此算法的实现影响甚大; 滑动窗口的大小难控制; 尽管记录比较的范围被控制到窗口大小内, 但实际操作过程, 重复记录的记录出现的频率依然较小。可见, 排序邻居法的应用过程, 必须克服以上缺陷, 以提高该算法的应用效果。

(2) 多趟排序 邻居法

多趟近邻排序算法的应用能够有效减轻排序关键字对排序邻居法应用效果的影响程度。多趟近邻排序算法要求单独执行多趟排序邻居法, 同时要求每趟创建的排序关键字不能相同且使用的滑动窗口相对较小, 同时采用等价的传递性方法来评判合并记录的等价情况, 如此把每趟找出的重复记录合并起来, 注意此合并过程假设记录以传递形式重 复出现 ,由此计算重复记录的传递闭包。采用计算传递闭包的方法可获取到较为完整的重复记录集, 由此实现部分规避漏配情况的出现。

(3) 优先队列 算法

优先队列算法要求首先采用邻近排序 算法排列 数据集 ,然后再结合排序结果, 对小范围的邻近记录予以匹配, 由此确定重复记录。优先队列算法的实现步骤为: 抽取≥1个字段来构造关键字, 并进行排序→找出固定长度的子集队列内各记录的匹配记录→以匹配操作的方式找出要求合并的子集→计算并合并此类子集的传递闭包, 以获取所有近似的重复记录集。对关键字进行排序后, 难以完全把重复记录聚集起来,因此单趟优先队列算法极有可能部分漏掉重复记录。 为此 ,可采用多趟优先队列算法, 且每次排序均采用不同的关键字。除此以外, 优先队列该算法能够与数据规模的变化相 适应 ,且就某条记录与多条重复记录相对应的情况, 优先队列算法也极具适应性。

3 结语

企业数据整合与数据仓库设计 第8篇

现今大多数企业都有多个不同部门的应用系统,但是普遍存在问题是,这些企业的应用系统不是建立于统一平台之上,数据库系统也是相互独立,甚至是异构系统,每个系统的数据都形成了一个独立的烟囱。可能每个部门数据资源已经很丰富,但是各系统之间数据不能相互连通。但要使数据发挥决策辅助作用,企业决策层组织需要看到的是一个企业跨职能部门的统一的数据联合展现和挖掘,因为单个部门的应用系统数据反映的仅仅是此部门的业务信息,而跨职能部门的数据联合分析将反映整合企业的发展状况和未来的发展趋势,所以不仅需要企业数据的纵向深入,同时也需要数据的横向联合。为了实现这一目标将对企业数据进行整合,建立统一的数据仓库。如何建立数据仓库将是本文论述内容。

数据仓库的建立首先要分析数据的主题域,确立数据可以划分为几大主题,然后选择合适的数据存储粒度,主题数据库粒度的确立与数据分析的实际需要和数据分析的可扩展度密切相关。主题和粒度确立后,选择不同切入点,进行数据维度分析,确认数据分析的不同切面,以及切面的组合。

1 主题数据库

主题数据库主要实现数据仓库支持功能。首先分析数据源可以划分为几大主题,针对主题结构建立主题数据库。每个主题数据库中可以划分域。

2 粒度分析

确认数据库主题和域后,根据源数据构成的实际结构,以及数据分析的需求,可以确认主题数据库每个主题中数据的粒度级别。数据粒度要适中,如果粒度过大,在数据钻取过程中可能不能向下钻取到所需数据,如果粒度过细可能会存储一些不会钻取到的数据,从而加大幅度加大了数据库存储量。例如零售业主题数据的保存可以根据需要包括月数据,从而上钻到季度、年度数据,但是一般情况下不需要保存每天的数据,这样既可以达到数据分析目的,又不需要存储成倍增长的细节数据,有效规划了存储空间。

3 维度分析

对数据库的分析可以通过设计数据库维度作为分析数据的入口,数据维度从不同方面展现了数据库数据的构成。例如可以包括时间维、地区维、组织维、人员构成维等。时间维可以包括:年、季度、月等层次,通过对时间维的分析,可以展现不同时间维度内数据在时间上的变化过程。地区维可以包括区域层次,通过对地区维的数据分析可以展现不同区域内数据的分布情况。组织维可以将数据产生于的组织的进行划分,可以分析不同组织之间产生数据情况的不同。人员构成维可以从人员性别、人员年龄层、人员工作性质等多个方面来设计,通过对人员构成维来分析数据,可以分析出面对不同人群数据的构成的不同。

仍以以上4种维度进行分析,例如在零售业对于以上数据分析的利用。通过对销售量在时间维度的分析,可以得出销售额随时间的变化趋势。通过对地区维度的分析可以识别不同产品在不同地区的不同销售分布。对于组织维,在这里可以将每个零售店看作数据来源组织(其他情况统计:例如病例情况统计可以将医院看作不同病例数据的来源组织)可以分析不同零售店的销售情况。人员构成维可以细分为:人员性别维度、人员年龄层维度、人员工作性质维度等,通过人员性别维度分析可以得出不同性别人群对不同商品的需求不同;通过对人员年龄维度的分析可以得出不同年龄段的购买力不同;通过对人员工作性质的分析,可以看出不同工作的人群对不同行业所需商品的购卖种类不同。通过以上分析可以推断出零售店将如何根据时间、地域、面对的销费人群去进行商品调配,以及如何根据销售组织的销售能力进行组织的有效管理。以上仅是抛砖引玉,大型零售系统的维度将不仅仅是这些,而是通过供应商管理、订货、运输、销售、售后、库存、客户关系管理、人力资源管理等等一系列维度种类的划分,进行多方面维度分析与钻取实现数据分析,从而进行专家预测。

主题数据库建立的同时也需要进行元数据设计,元数据的建立主要是提供数据结构的描述数据,描述了数据的结构、内容、链和索引等项内容。可以划分为数据库系统元数据、主题数据元数据、TRS元数据等。

最后进行数据库的物理设计,主要包括数据存储规划、索引设计、分区设计等方面。物理设计包括了各种实体表的具体化,例如表的数据结构类型、索引策略、数据存放位置和数据存储分配等。对于数据索引的设计,需要为频繁检索的大数据表建立索引。索引的建立将大大改善数据检索的速度,但同时在数据变更的过程中也会导致数据加载时间的延长,所以要适当地建立索引。索引主要分为B-tree索引、位图索引、全局和局部索引等,不同的数据列可以根据数据类型选择不同类别的索引。对于大数据量表可以对表进行分区设计。

数据仓库在实际运行过程中其性能很大程度上决定于数据库参数的设置。以Oracle数据性能调优为例,主要包括内存调优、I/O设计、索引设计、查寻优化、SQL调整等方面。

Oracle数据库运行性能很大程度上决定于内存参数的设置。内存调优主要包括数据缓冲区、日志缓冲区、共享池、排序区等内存参数的调整。

Oracle数据库数据缓冲区主要保存存入内存准被写入磁盘的数据以及从磁盘读取的数据。当应用系统向数据库请求数据检索结果时,数据库首先访问数据缓冲区,查询此数据是否已经存在于缓冲区之中,如果存在则从内存中读取,如果不存在则需要从磁盘中读取,从内存中读取的速度将极大程度上优于从磁盘中读取的速度。在数据库运行过程中数据库管理员可以监控内存的数据命中率,如果命中率过低建议调整数据缓冲区参数,一般比较理想的数据缓冲区命中率在90%以上。

日志缓冲区保存日志信息,当日志缓冲写满后,数据库系统将把日志信息保存于重做日志文件。如果日志缓冲区设置过小,将发生频繁的日志写操作,增加I/O频率,会影响到数据库性能。

共享池主要为SQL、PLSQL、函数、触发器、包、存储过程等分析与编译、执行的内存区域。分析结果将保存于共享池,同样的SQL、PLSQL、函数、触发器、包、存储过程等请求内存,数据库系统将首先查询其是否有相同的分析结果保存于内存中,如果存在于共享池数据库将不再进行相同解析。全新的解析过程将占用SQL等运行时间的60%,所以提高共享池的命中率,同样可以有效提高数据库访问性能。

排序区主要保存数据库在排序过程中的数据,当排序区写满后系统将调用临时表空间来进行排序数据保存。适当地扩大排序区,尽量减少排序过程中对临时表空间的调用,可以有效提高数据库排序检索效率。

磁盘I/O分配也是数据库优化的一方面,在进行表空间分配时应考虑到I/O竞争问题。例如前面提到的,可以将生产数据库的读写表分离,将频繁读的数据表放置于另一表空间中,并且可以将索引存储于单独的表空间中。

4 结语

数据仓库的建立将实现对企业零散的业务数据的转化、清洗、整合过程,使数据的存储结构更加规范化,并且符合数据分析的存储要求。数据仓库的检索已不再是仅针对某一业务过程,而是站在更高层面以图形、表单、多维模型等方式展现了数据深层关联关系,实现了企业决策的深度需求。

摘要：目前企业的数据资源可能已经很丰富,但是各系统之间数据不能相互连通。企业决策层组织需要看到的是一个企业跨职能部门的统一的数据联合展现和挖掘,所以需要构建数据仓库。数据仓库的构建过程主要包括:划分主题域、进行事实表和粒度分析、维度设计、元数据设计、数据库物理设计以及性能调优。

数据仓库元数据管理研究 第9篇

近年来，数据仓库在信息集成和信息管理中的作用日益增强，越多越多的企业开始重视数据仓库项目的开发。数据仓库是体系结构化环境的核心，是决策支持系统处理的基础。数据仓库项目是一个非常复杂的系统工程，通常需要集成多种软件工具。为了实现企业信息的整合与分析，使各种工具之间相互配合，协同合作，必须进行有效的元数据管理。这是整个数据仓库项目的成功的关键所在。

目前，国内关于数据仓库元数据的研究主要在元数据定义及分类，元数据标准，基于XML的元数据交换，元数据管理结构，元数据模型等领域。其中，元数据管理是一个巨大的挑战。挑战不在于使用工具来获取元数据，而在于将不同的工具生成，维护的元数据集成在一起[1]。因为，大部分数据仓库工具都有不同的元数据模型和各自的元数据接口。同时，全行业范围内还没有形成通用的元数据标准，阻碍了各工具间元数据的无缝传递。基于元数据管理的复杂性和重要性，本文在对典型的元数据管理架构进行深入分析研究的基础上，提出了一种基于信息供应链（ISC）的双向联邦式的元数据管理架构。

2．元数据

元数据是数据仓库的神经中枢，它对于数据仓库的创建，维护，管理和使用具有重大意义。如果没有元数据，数据仓库的开发者，维护者就好像是一个城市的管理者，对城市的规模和发展速度等情况一无所知；最终用户就好像是一名陌生的游客，却没有城市的地图。

2.1 元数据的定义及分类

元数据通常被定义为："关于数据的数据"[2]。它是描述数据仓库内数据的结构和建立方法的数据。元数据可以按系统用户的角度主要分为两类:技术元数据 (Technical Metadata) 和业务元数据 (Business Metadata) [3]。

技术元数据:它是关于数据仓库系统技术细节的数据。例如，源系统的数据模型，数据抽取规则和计划，数据转换规则和版本控制，数据仓库数据模型，数据汇总规则等。它主要为负责开发，维护和管理数据仓库的IT人员服务。

业务元数据：它从业务的角度来描述数据仓库中的数据。例如，预定义的查询和报表，企业的概念模型，数据转换的商业规则等。它为最终用户服务，使最终用户能够理解系统的各项操作，以便更好地应用数据仓库为其服务。

2.2 元数据的作用

元数据贯穿数据仓库的创建，维护，管理和使用的全过程，是联系数据仓库中各部分的纽带。元数据对于整个数据仓库系统的作用主要表现在以下几个方面[4]：

(1) 元数据是进行数据集成所必需的

数据仓库最大的特点就是它的集成性。不同数据源中的数据通过采集, 整理等流程，按照一定的模式存放在数据仓库中。这些数据源与数据仓库中数据的对应关系和转换规则等都存储在元数据存储库中，方便用户的访问。

(2) 元数据是保证数据质量的关键

由于底层的技术实现对用户来说是不"透明"的，数据仓库的使用者常常会对数据产生怀疑。借助元数据管理系统，他们能够方便地了解数据的来龙去脉，以及数据抽取和转换规则等信息。这样, 他们自然会对数据具有信心，同时，也比较容易发现数据所存在的质量问题。

(3) 元数据定义的语义层能够帮助最终用户理解数据仓库中的数据

元数据可以实现业务模型与数据模型之间的映射, 因而可以将数据以用户需要的方式"翻译"出来, 从而达到帮助最终用户理解和使用数据的目的。

(4) 元数据提高了系统的灵活性

企业对于数据仓库系统的需求是千变万化的。元数据记录了整个系统中数据的来龙去脉，使得技术人员在数据仓库系统开发、维护和升级工作中，便于实现新的设计与规划。成功的元数据管理系统，可以把整个业务的工作流、数据流和信息流有效地管理起来，从而提高系统的灵活性和可扩展性。

(5) 元数据是进行影响分析所必需的

通常情况下，在对数据仓库系统执行实际的变化操作前，管理员需要对潜在变化的影响进行评估。例如，源模式的变化可能影响转换规则（例如，导致类型不匹配，违反外键完整性等），而且也可能对数据仓库或者数据集市的结构造成影响。明显地，只有获取元数据存储库的信息，才可以自动检测到哪些源变化可能对数据仓库造成影响。

2.3 元数据的生命周期

元数据的生命周期包括收集，维护和部署三个阶段[5]。

收集阶段：此阶段的任务是识别和捕捉元数据，并且置于元数据存储库。通常，相当多的业务元数据最初都需要某种手工过程来获取。通过手工输入来获取元数据，不仅过于浪费时间，而且随着时间的推移通常会导致整个仓储计划被推翻。因此，元数据的收集应尽可能实现自动化。元数据收集的处理过程与数据仓库的ETL处理过程类似。

维护阶段：在此阶段，元数据必须及时反映实际情况的变化。确保元数据准确并维护良好的唯一方法就是尽可能使得维护过程自动化。不同类型的元数据，其维护方式有所不同。对于那些反映数据来源结构和数据仓库本身的物理元数据而言，可以达到很高的自动化水平；对于业务规则信息和数据模型而言，元数据很可能依赖于人工维护。当然，也可以手工启动一个自动刷新过程来更新元数据集中的数据模型信息；对于数据仓库的使用信息而言，应该周期性地被追加到元数据中。

部署阶段：此阶段的关键就是正确地使元数据与不同用户群的特定需求相匹配。数据仓库系统的用户群通常包括：数据仓库开发者，数据仓库维护者和最终用户。

3．元数据管理架构

不同厂商生产的大多数产品拥有不同的元数据模型，并使用其专用的接口发布元数据。因此，对于集成这些软件产品，工具的厂商和消费者而言，提出一具完备的，基于标准的元数据解决方案是一项非常具有挑战性的任务。它的关键是提出一个具有集成性，可扩展性，健壮性，可定制性，开放性的元数据集成体系架构[3]。

基于共享和管理元数据的角度，在实施数据仓库项目时，目前主要有三种典型的元数据管理体系结构[6]：

3.1 集中式架构

如图1所示，在这种方式下，企业内部的所有元数据集中存储在中央元数据存储库中。所有工具通过直接访问中央元数据存储库, 进行元数据交互。由于中央元数据存储库的数据量比较多，通常采用关系数据库系统进行数据存储。

此体系结构最大的优点是元数据变化管理，版本变更等操作仅限于中央元数据存储库, 可以实现所有元数据的一致管理。此外，不存在数据冗余现象。最后，数据仓库的各部件，工具可以访问所有的元数据，而无需提供元数据交换机制。

当然，所有的元数据集中存储在中央元数据库中，不利于数据仓库的维护，造价昂贵且实施困难。同时，由于不同的数据仓库部件，工具不局部存储和管理元数据，这导致了各工具缺乏自治性。

3.2 分布式架构

如图2所示，在这种方式下，所有的工具和关系数据库都有相应的局部元数据存储支持。这些局部元数据存储库是互不相干的。一般情况下，它们不直接进行通信。

此体系结构实现简单，花费较少。而且，各数据仓库工具拥有自己独立的元数据，实现局部自治。但是，元数据缺乏统一管理，可能存在重复和不一致。而且，元数据查询，使用困难。最后，需要提供元数据交换机制。

在必要时，各局部元数据存储库之间可以通过点对点的连接进行元数据交互。主要有两种方式：（1）额外开发双向元数据交换工具。例如，元数据桥。这是一项艰巨，耗资巨大的过程，会导致元数据管理系统的复杂性和成本严重增加, 最终丧失分布式体系结构的最基本的优势。（2）使用元数据交换标准。例如，CWM标准。如果局部元数据存储库采用了相同的元模型和接口，那么它们之间的连接只是简单的，物理上的连接。

3.3 联邦式架构

如图3所示，这种方式结合了集中式体系结构统一管理并提供一体化访问平台的优点和分布式体系结构易于实现，构建便利的优点，平衡了共享和自主的需求。各数据仓库工具拥有各自的元数据存储库（局部元数据存储库）。同时，设置了中央元数据存储库对所有共享的元数据进行统一管理。局部元数据存储库可以采用异构的表示形式，而中央元数据存储库必须采用统一的元数据表示形式，例如，基于标准的元数据模型CWM。构成信息供应链 (Information Supply Chain, ISC) 中的软件产品从中央元数据存储库中检索元数据，而不是与其他产品的点到点连接获得元数据。这种体系结构比较适合业务比较分散，相对独立的企业。

4．基于信息供应链（ISC）的双向联邦式架构

典型的数据仓库和业务分析环境通常都是根据信息供应链（ISC）来描述的[6]。ISC最重要的一个特点就是，它有一个定义良好（并且有高度目的性）的数据流。从起始源，经过一系列转换，最终到达某个目的地（通常为分析和报告工具的最终用户）。数据流要想平滑通畅地流动，每个组件不仅需要对描述数据的元数据有共同的理解和全程参与数据交换，而且需要了解它所处理数据的本质。元数据是理解数据含义和如何使用数据的关键。所有实现信息供应链（ISC）各阶段的不同软件工具和产品，都要依赖元数据来描述它们需要处理和转换的数据。元数据需要被有效集成，这是构成ISC的每一个软件产品和工具能够在数据层进行有效集成的前提。因此，提出一个合理的元数据管理架构，对于元数据集成具有至关重要的作用。

基于信息供应链的双向联邦式架构，如图4所示。当前，实现双向元数据体系结构的企业相对较少，但是这是元数据管理架构的大势所趋。因为该体系结构允许各工具间进行通信，共享元数据。同时，它允许企业在元数据存储库上进行全局性的改动，并可在整个组织内感知到这些变动。因为此体系结构允许改变元数据存储库中的元数据，然后从元数据存储库反馈回最初的来源。例如，如果用户浏览元数据存储库并改变决策支持系统的某个数据集市中的一个属性名称，该变动就会被反馈到数据建模工具，以更新这个特定数据集市的物理模型。

实现双向元数据面临三个显而易见的挑战[3]：（1）要求元数据存储库必须含有将被反馈到的元数据源的最新版本。（2）需要系统化地跟踪和解决变动，因为在一个用户改变元数据存储库中的元数据时，可能存在另一个用户正在其元数据源改变相同的元数据。（3）需要构建几组额外的处理接口，把元数据存储库连接回元数据源。

5．结束语

本文通过对元数据管理架构进行深入研究，针对信息供应链 (ISC) 环境，提出了双向联邦式的元数据管理架构，对数据仓库环境中的元数据集成具有指导意义。信息供应链 (ISC) 环境下的不同产品往往存在不同的或者不能兼容的内部元模型和特有的元数据接口。如何提供一个通用的，外部化的并且与平台无关的公共的元模型标准，对于实现有效元数据管理至关重要，这也是未来的研究方向之一。

摘要：元数据管理是基于决策支持的数据仓库技术研究的重点与难点之一。本文首先对数据仓库中元数据的定义, 分类, 作用和生命周期进行了探讨, 其次对典型的数据仓库元数据管理架构进行深入研究, 并提出了一种基于信息供应链 (ISC) 的双向联邦式的元数据管理架构。最后, 指出了数据仓库元数据管理的未来研究方向。

关键词：数据仓库,元数据,元数据管理架构

参考文献

[1].Paulraj Ponniah (美) .数据仓库基础[M].段云峰, 李剑威等译.北京:电子工业出版社, 2004

[2].William H.Inmon (美) .数据仓库[M].王志海等译.北京:机械工业出版社2006

[3].David Marco (美) .元数据仓储的构建与管理[M].张铭, 李钦等译.北京机械工业出版社, 2004

[4].Anca Vaduva, Klaus R.Dittrich.Metadata Management for Data Warehousing:Between Vision and Reality.International Symposium on Database Engineering&Applications, 2001:129-135

[5].王红兵.数据仓库中的元数据[J].微机发展.1999, 5:44-48