数据管理
数据管理范文第1篇
赛思信安凭借在海量数据技术领域的多年积累，推出了Scistor dataFusion（赛思大数据管理平台），可满足各类企业级用户大数据应用中的如下需求：对结构化数据、半结构化数据、非结构化数据进行快速整合和统一管理，支撑PB级数据存储管理；对海量数据进行多语义高速检索；对文本数据和结构化数据进行统一检索和统计分析；对Hadoop平台和传统关系型数据库中的数据进行关联分析；实现操作可视化、数据可视化；构建跨地域多数据中心，实现多数据中心的统一管理和访问。
Scistor dataFusion是一个基于分布式框架，采用并行处理技术，对外提供大容量数据存储、多源数据整合、数据即时检索、数据离线分析、海量小文件管理、内存分析的大数据管理平台，具有高性能、高可靠性、高性价比等特性，适合各类企业级用户根据自身业务模式构建高可用的大数据一体化管理平台，轻松驾驭大数据。
强大的数据管理能力
Scistor dataFusion具有以下特点：它支持在线扩展/缩减节点，支持异构多源数据PB级存储；集群有效整合内存计算框架，实现毫秒级响应，集群每秒可处理百GB数据，加载能力可达千万条/秒；支持数据多副本，副本数量可灵活设定，支持所有节点集群化；可提供类SQL和MR分析接口，提供多格式文档、多语言等强大全文检索能力；无缝整合现有关系型数据库，数据分析（图计算、R语言等）和BI工具。
Scistor dataFusion支持跨数据中心部署和应用，提供部级数据中心解决方案，且单集群节点数达上千台；支持图形化安装配置部署，提供集群监控报警功能。
创新的架构
Scistor dataFusion采用了创新的架构。
从架构图中可以看到，iIntegrator主要负责外部数据源的收集、复杂数据的清洗加工以及多存储引擎中数据的交换；iManager负责整体系统的管理与监控；iSentry负责存储资源的申请与回收，同时负责用户权限控制；HDFS、LFS、HBase、RDBMS组成了差异化存储，根据用户业务不同对数据进行分类存储；iQuery，iDriller，iStream都是对数据进行处理的组件，其中iStream专注于内存数据处理应用、iQuery专注于海量记录高效检索应用、iDriller专注于海量数据分析统计应用。
广泛的应用领域
数据管理范文第2篇
1．1缺少集中管理
没有权威的管理机构负责管理地下管线数据。目前国内虽有个别城市成立了地下管线的管理机构，但对数据的管理依然是规划、国土等部门。缺乏权威机构来管理是造成后续地下管线管理问题的一个重要原因。二是财政体制原因，部分城市的地下管线没有实现统一管理，经常是谁出钱，谁管理［5］。数据管理不仅存在地域之分，而且在统一数据标准、数据更新范围和模式上也存在不同的工作方法，影响了数据的统一。三是在地下管线规划、设计、建设和使用的全过程中，会产生各过程的地下管线数据，这些数据会因需求不同而产生不同的应用。通常城市只注重竣工现状数据，忽视了设计、施工、规划等数据，这些数据没有实现集中管理，在查询和应用时会造成各种各样的困难。
1．2数据更新存在盲点
地下管线数据的动态更新有以下几种模式:1)定期开展地下管线普查工作，按年度或更长时间对一定范围的地下管线进行调查和测量。这种方式工作量大，涉及面广，工作难度大，探测精度不高，遗漏在所难免。2)对一定区域的管线进行即时的巡逻补测，发现有管线开挖，即时进行管线测量。这一方式工作量较大，即使组织得当，责任心强能起到一定的作用，但仍然会有遗漏。3)与管线管理单位合作进行管线的跟踪测量。这一工作针对性强，对于报批的管线可以达到有效管理，未覆土前测量，精度相对较高。但对未报批的管线，却无法获取信息。4)通过管线权属单位申报，补充地下管线数据。这样做虽然针对性较强，权属单位的管线遗漏较少，但对于未通知到的权属单位仍是个盲点［6］。总之，在管线报批管理有遗漏的情况下，目前还难以确保管线数据的齐全。
1．3各阶段的地下管线数据信息脱节
城市地下管线建设相对较复杂，流程多，涉及单位和责任人多，过程资料和信息也十分庞杂。研究城市地下管线数据现状，发现目前管线数据管理的各个阶段衔接不好。原因在于过程部门多，管线权属单位、设计施工监理单位、规划城管等审批单位、测绘单位、管线数据管理单位间缺乏沟通交流机制，信息传达不畅，尤其一些重要信息没有在各单位之间流转;没有统一的平台管线设计、开工、监理、审批等信息，而这些信息是确保地下管线数据获取和应用的重要保障。
1．4数据不全
通常城市比较重视采集地下管线的现状竣工数据，但由于种种原因，会造成地下管线数据不齐全，影响了管线数据的使用。一是城市市区地下管线数据相对较全，但县、镇和城乡结合部的地下管线数据不全;二是除了现状地下管线数据，数据种类还应包括规划数据、历史数据、废弃地下管线数据、施工管线数据、设计审批数据等，在应用中只有地下管线现状数据有时会显得数据内容不全;三是部分单位内部的重要地下管线数据经常出现错漏，如一些工厂内的危化管线，由于在厂区内部，未纳入数据管理。
1．5数据提供使用存在障碍
地下管线数据因其重要性被列为保密数据，造成数据信息传递不畅。在管理部门和其他权属单位、施工设计单位之间，又分属于不同的网络，一般单位使用互联网，国家机关使用政务网或内部网，网络的不同，造成了许多信息孤岛。地下管线数据若无权威部门管理，在提供使用时，有可能会产生费用，影响管线数据的使用。
2地下管线数据管理策略的建议
2．1建立统一的地下管线数据管理制度
确定地下管线数据的管理责任;建立城市地下管线数据沟通机制，定期数据更新情况;统一各项工作标准。数据更新的责任应由权属单位承担，地下管线数据应经权威部门的检测后才能入库。与地下管线数据有关的部门应各司其职，合理分工和履行责任。
2．2强化地下管线竣工测量制度
建立地下管线数据的信息获取和反馈机制。遗漏的地下管线数据能很快发现，新建改建地下管线工程能很快申报，打通审批、设计、测量、入库和应用的各个环节，消灭每个环节存在的漏洞，真正实现地下管线竣工测量的全覆盖。
2．3建设地下管线数据专用网络
地下管线数据属于保密资料，不能在互联网上传输。但从现实情况看，管理部门、权属部门之间信息沟通不畅是造成管线数据难以管理的重要原因。目前城市的电信网络都比较发达，建设相对保密的地下管线数据专用网络的成本并不高。
2．4扩大地下管线数据管理的种类
现状竣工管线数据依然是数据管理的重点，但与此同时，应考虑将规划管线数据、设计和审批管线数据、历史和废弃管线数据都纳入管理范围。地下管线数据应考虑与地面管线数据同时采集，以利于管线数据的提供使用。
2．5建设与地下管线有关部门的信息系统
信息系统不能局限于某个部门，管理部门应包含规划、城管、发改和安监等部门。权属单位应通过专网联通，并赋予一定的责任。设计和测绘单位也应一并纳入，便于管线数据的采集和入库。多方协作，方能做到城市地下管线数据的齐全和准确。
3结语
数据管理范文第3篇
随着科技的发展，社会的进步，尤其是计算机通信技术的发展，人们对数据库的共享性要求日益明显，当前数据库的管理和访问充满了复杂性，如何解决这一问题成为了管理者和用户最为关心，最为头疼的问题。例如，非数据库的建设者和维护者，都需要知道数据库当中的全部内容，以此来避免数据的重复录入，从而更好的使用数据。根据用户的需求用户需要知道数据信息的质量，用户也需要知道数据库的数据结构和句存储格式，来满足用户的信息数据交换和利用。在这种情况下数据的内容、品质等元数据的信息就变得十分重要了，它是信息数据有效管理和利用的重要方式，元数据的重要性正在得到用户和数据库的建设者的证明。由于现在数据库的使用对象越来越专业化、复杂化，他们对数据集的元数据内容以及各式会存在相当大的差别，对数据的共享性影响很大，为了制定一套元数据的标准，需要采用同样的各式对数据集进行描述。
2元数据的定义和形成
元数据又叫做描述数据，是台湾学者通过英文翻译过来的（英文为Metadata），现在我国对该术语还没有形成统一的认识。国际标准化组织地理信息、地球空间信息技术委员会的地理信息元数据标准草案将元数据简单的定义为“数据的数据”。美国联邦地理数据委员会在数字地理空间元数据内容标准中将元数据定义为“关于数据的内容、质量、条件和其他性质的数据”。国际地球科学信息网络学会对元数据定义为“关于数据和信息资源的描述信息，他们描述、指向或者补充与之相关的信息内容”。元数据的定义和专业术语出现的时间虽然不长，但是元数据的本质内涵确实流传了很久。举一个简单的例子，在很早以前的图书管理当中，管理人员对书籍目录的编写，记载了书籍的各种相信内容，包括作者、写作时间、页数和字数等，这种对书籍信息的记录就可以理解为元数据。只不过在以前涉及到的数据不是特别复杂，只是到了现代随着网络技术的普及，数字资源呈现出爆炸性增长的速度，人们为了便于统计这些数字信息不得不将以前的文本化数据向网络表格化数据方面进行转变。从上世纪八十年代开始出现元数据的记录方式，到现在元数据的应用已经扩展到了各个行业。
3元数据标准内容分析
根据元数据的使用目的不同可以将元数据大体分为两类，即：管理和组织数据的元数据；浏览和导航数据的元数据。第一种类型的元数据的代表就是美国nasa描述遥感数据的目录交换格式标准（DIF），这一标准有一个典型的特征就是必备六个字段：登录目录标识、登录目录的名称、参数、原数据中心（包含名字、数据集标识、联系人等）和数据概要描述。另外，为了让信息表达的更加明确，这一标准当中还要增加字段，如传感器的名字、位置、数据分析、计划口令、品质等，增加这些字段可以提高用户的使用效率，尽可能的完善元数据。第二种元数据的代表就是澳大利亚新西兰土地信息委员会制定的元数据标准。这一标准确立的核心元素较少，能够让用户在最短的时间内查询到所需要的数据信息。核心元素能够说明现有数据的种类、数据信息、数据范围、与其他应用的作用，以及获取更多信息的位置等。核心元数据共分为九类三十二个元素：数据集中、展示、数据时间、数据状况、访问和浏览情况、数据品质、联系信息、元数据时间、元数据附加内容。除此之外，核心元数据还要制定了数据格式，使用指南，以方便用户查找信息。
4元数据表达方式的分析
美国联邦地理数据委员会的数字化地理空间元数据内容标准元数据信息单元是元素、实体（包括复合实体）和字集。元素是元数据的基本信息单位，元数据实体由元数据元素组成，元数据实体、元素则构成复合实体，最终部分元素、简单或者复合元数据实体组成元数据子集，元数据的组成结构从小到大排列为，元素、实体（复合实体）、子集。元数据是利用巴克斯诺尔范式进行表达的，巴克诺斯尔范式可以定义常规语言元素和属性标准语法，在确定复合实体和其他元素、实体间的联系的时候，采用类似于数学等式的关系将标识符和表达式用等号连接起来，以此来表表达式产生标识符这一进化关系。这一规则公式代表了各种符合的意义，从数学角度可以解释为，A=B+(C)表示A由B和可选项C构成，A=3{B}5表示A由B重复3到5次而成，子集、实体、元素之间的关系可以用元素比实体进一格的办法来表达，美国的数字化地理空间元数据内容标准利用这种方式可以清晰的表达数据实体和元素之间的各种关系，但是它也只是包含了标准化当中元数据和元素的定义，并没有规定数据的格式，有时候用元数据元素分层缩排来表示，有时候用编号系统表示，这就使得元数据使用起来并不简洁。为了解决这一问题，建立了空间数据信息交换网络，利用比较统一的SGML、Z39.50和其他协议来表示，可以更加灵活的执行元数据。ISO/TC211的元数据标准利用了图表和数据字典相融合的表达方式，清晰的表示了元数据内容之间的各种关系。数据字典可以详细的解释元数据的内涵，图表则是面向对象的统一建模语言UML静态结构图、ISO借口定义语言，在图表当中信息单位是包、类和属性。数据字典当中元数据的信息单元是子集、实体以及元素，这一标准说明了图表和字典当中的对应关系。因为静态结构图准确的解释了元数据的语义和句法结构规则，制定了标准的描述数据信息的方法和格式，通过辅助设计软件可以精确的表达数据元素关系，检查元数据设计的整体性和统一性，所以ISO/TC211的元数据表达方式对全世界各个行业的数据管理和服务产生了重要的影响。
5元数据网络管理模型分析
当下比较流行的元数据管理系统模式可以分为：集中式数据管理体系和分散式数据管理体系。集中式数据管理体系就是所有的元数据都聚集在一个元数据管理站点上，数据集元数据是通过数据制造者免费上传的，数据的使用者可以通过当下的数据管理站来进行访问好查询元数据。这一模式比较有代表性的就是英国地理数描述目录，这一机构的数据来源于国家制图机构。这种模式的优点就是使用者可以迅速的查找元数据，工作效率很高，当然缺点也很明显，就是这一模式分裂了这一管理系统和其他网络元数据体系的链接，导致这一体系的元数据数目较少，在数据信息的更新和维护方面就取决于元数据的上传者，元数据信息不能及时的更新，提供的数据有可能出现错误。分布式元数据管理体系就是要设立一个元数据网络交换的核心连接点，使用者可以在这一连接点进行元数据的查询，而对于元数据的供给者和元数据的数据制造者，则需要设立分节点，保存各种元数据的信息，然后将核心连接点和分节点联系起来。元数据的使用者不能直接访问数据的制造者，只能通过核心连接点来访问数据信息，进行元数据的查询。这一模式的代表性机构就是美国空间数据交换网络，它将用户、服务器内容、数据库服务器进行了分离。通过网关根据数据信息的类型、数据信息覆盖位置等条件构成元数据的查询界面，用户通过网络进行查询，核心连接点通过用户信息向分节点进行传输，然后在将内容反馈到用户浏览的页面当中。这种模式的优点在于能够增加元数据的数量，减少核心连接点对元数据的更新负担，缺点在于元数据的查询速度较慢，影响使用者的查询效率。
6元数据传输各式的统一
虽然当前已经制定了一些元数据的标准，但也只是确定了元数据的内容、含义、类别、组成结构等特征，但是这还不能满足元数据的使用要求，制订元数据标准的目的是为了元数据的查找和检索，了解数据信息和内容，因此必须要注重元数据的传输标准，以此为基础来设计元数据的管理体系，从而达到对元数据的搜寻、修改、更新维护和查询检索。在DOS环境下和ARC/INFO环境下，美国诞生了很多元数据录入和编辑的软件，澳大利亚也开发类似的软件，这些元数据软件都是为了便于自身的查询需求，符合各自制定的元数据标准的。但是各个元数据录入软件的数据格式却不相同，有的是文本格式，有的是HTML格式，还有的是关系型数据库格式，虽然方便了用户，但是在元数据的修改和维护方面成本很高，所以要制定统一的元数据转化标准，方便网络上的元数据交换。美国和澳大利亚建议更改统一的后缀格式，例如，将SGML/HTML的统一转换成XMLDTD或者是XMLSchema，将表格改编成ASCII的格式。这种方式优点在于有利于建设元数据索引和能够在不同地区的互联网当中进行元数据的查询。
7元数据管理平台设计和实现
7.1功能流程设计
功能流程设计需要满足元数据生命周期的要求，当前大多数公司单位都是分散式的数据管理体系，数据比较分散，需要采集多元数据并且简化数据的存储体系。可以将TSV（三层阶梯式图）引用到元数据管理体系当中，在元数据导入配置方面，可以利用悬挂点配置的方式，在任务采集的起始阶段可以配置相应的悬挂点（类似分支点），建设元数据的查询树，在数据源配置方面要表明数据源的类型、衔接数据、账户情况等，还要进行测试观察后续问题。为了更好的完善元数据的管理体系，保持元数据地图的完整性，需要对元数据进行完备的采集，采集方式又分为手动采集和自动采集。手动采集是对用户要求的数据库进行单次采集，自动采集则额外的配置采集时间和采集周期。
7.2元数据的浏览
将配置好的悬挂点体现在元数据的树状结构当中，以形象的结果提供给用户，基于TSV的思想元数据树需要具有三层以上的结构，首先是系统，其次是各系统数据库，再者是各数据库的下属表。在库级元数据方面需要展示各个表名和创立的时间，在表级元数据方面需要双击查看该表的详细信息，包括字段、约束、索引、键、视图等，在下拉菜单当中可以检索相应的元数据信息。在字段级元数据方面包括字段名、字段类型、字段解释、所属的表和库，前三项属于特点描述，后两项是定义描述，这样能够方便对字段进行分析和定位。
7.3元数据的构架设计
元数据管理体系的技术构架主要是对所有信息数据的筛选，来确定那些信息可以纳入元数据管理体系，以此来构建三级视图。技术构架的信息主要包括五个方面，即：数据源层、数据收集层、数据保存和管理层、应用帮助层、登录管理和用户信息等。数据源层主要就是提供数据信息，数据收集层主要是理清各类数据关系方便元数据的管理。
数据管理范文第4篇
随着天文数据的日益增加，存储和管理天文数据变得非常重要，尤其在天文数据的归档和管理方面，占有举足轻重的地位。能够很好地管理海量的天文数据就相当于在后续的科学研究中成功了一大半。通过对天文数据管理方面知识的了解，经过一系列的研究与开发，最终开发了一个高效的天文数据自动入库管理工具AutoDB，旨在帮助天文学家提高工作效率，促进天文学研究的进展。
1.1AutoDB的设计思路与方法
在之前的裴彤等人的设计中，已经实现了天文数据的自动入库，该工具采用Python[11]语言编写，并且能够自动地添加pcode字段，建立HTM（HierarchicalTriangularMesh）[11]索引分区，便于以后的交叉认证工作。HTM是一种多层次的、递归的球面分割方法，可将天球分成多级的三角网络，每个网络都有一个pocde，利用HTM可以将一个大星表从逻辑上分割为多个小星表[11]，HTM分级算法采用C语言编写，充分地利用了C语言的高性能和Python语言的高开发效率。然而该程序仅支持底层数据库为MySQL，且只支持CSV格式的文件，且文件中的数据不能为空，若为空则会抛出错误，在使用方面具有一定的局限性。其HTM分区是对ra和dec进行计算产生pcode值来实现天空分区，同时使用pcode_htmN数据列来存储这些值，然后对其进行btree索引，方便后续的高效查询。首先，其计算的算法必须跟随着后续数据的复杂性进行优化，其次，先计算在存储势必有I/0性能限制，最后使用btree一维索引间接性的对赤经ra和赤纬dec索引，无法利用天文数据的空间性，且若想实现一定半径内的查询需要非常复杂的SQL语句。为了解决这些问题，我们仔细地阅读了裴彤等人的论文和程序代码[12]，在深入分析其原理的基础上，对自动入库管理工具进行了更加全面的完善和改进：（I）底层数据库同时支持MySQL和PostgreSQL；（II）针对PostgreSQL数据库，使用一种新类型Q3C索引，其直接与数据库进行交互，无其他I/0交互，直接对赤经ra和赤纬dec进行空间索引，并且提供简单的SQL语句来实现复杂的查询；（III）数据格式同时支持FITS格式和CSV格式；（IV）数据优化，若其中存在为空的数据项，数据项自动变为’9999’或者’NULL’，则入库时不会抛出错误。下面分别展开阐述。一、底层数据库架构工具的底层数据库是基于MySQL和PostgreSQL两种数据库开发的。这两种都是非常好的开源数据库，对于选择哪种数据库更好取决于哪种数据库更能满足用户的需求。之前采用的是MySQL数据库，然而由于数据量的增加，数据表格越来越庞大，一个表格甚至达到了几十亿行，对于表本身的容量远远地超过了物理内存的大小，甚至出现了连建索引也不能改善性能的情况，这样查询时间会将大大地延长，在此情况下非常有必要对数据进行分表管理，即将表拆分为一系列较小的、与之相关联的表来进行替代，通过对子表的数据查询，就相当于对整个表进行了查询操作。对基于MySQL数据库分表来说，取决于数据引擎(InnoDB)，不支持哈希分区表，而PostgreSQL数据库支持临时表、常规表以及范围和列表类型的分区表。而且PostgreSQL的表分区是通过表继承和规则系统完成的，所以可以实现更复杂的分区方式。且在索引方面，PostgreSQL支持B-树、哈希、R-树和Gist索引，MySQL取决于数据引擎，大多数为B-Tree索引。由于天文数据具有空间属性，位置坐标为（赤经ra，赤纬dec），其索引会是一个二维的。建立一个高效的索引非常重要，使用第三方扩展库如Q3C索引即是采用的二维索引，又如使用PGSphere中的GIST索引，会使数据的查询更加高效。所以在当数据量非常大的时候，或者需要使用到第三方库时，对于空间点索引时，采用Postgresql比采用MySQL要方便得多。但若数据量不是很大，对于亿行级以下的数据量，不需要采用第三方库去支持创建索引的数据，则是采用MySQL比较好。同时MySQL的性能方面要比PostgreSQL较为高效。面对种种数据管理的需求，我们增加PostgreSQL作为该入库工具的底层数据库是必要的，天文工作者可以根据自己的需求存储到不同的数据库中。二、Q3C索引庞大的数据储存在数据库中，若想能够准确高效的使用这些数据，必须对其数据创建索引，索引不仅能够加快数据的查询速度，而且会使数据的管理变得简单容易，可以大副提高系统的性能。当然索引的创建也不是越多越好，因为索引过多会随着数据量的增加而加大数据库的负荷，就起不到提高系统的性能的作用，反而会降低性能，所以索引的使用要准确得当。在本系统中，由于我们是对天文数据进行入库管理，天文数据的复杂性、空间性决定了普通的一维索引并不能很好地解决天文数据的查询管理要求，所以我们是用了一个全新Q3C(QuadTreeCube)对天空分区索引，其能够很好地对天文数据进行二维的空间索引，Q3C索引方案为开源项目运用于数据库PostgreSQL中，大家在使用的同时也可以随时进行修改，非常适用于学术研究，由于直接运用于数据库，使用者不需要书写任何算法，相比于HTM，首先需要对天文数据进行分区计算pcode值，然而分区计算算法需要由使用者编写，这样会无形地增加风险，同时也带来了复杂化。Q3C的产生是专门针对天文数据的，其目的性非常明确。虽然普通的索引如btree也能够用于天文数据，但是如果需要进行锥形查询，在不使用Q3C索引的前提下，其查询SQL语句会非常复杂，并且查询速度非常慢，而且也只能运用于数据量较少的情况下，数据过多极有可能导致内存不足而出现程序卡死现象，然而上面的问题对于Q3C索引来说都不存在，所以这种基于四叉树的空间索引Q3C就显得非常实用了。Q3C索引不仅能够提供天文数据特有的查询，而且也提供交叉认证功能，这对以后的数据处理来说，很大程度地简化了工作量，同时又容易使用，而且不论是在查询方面，还是交叉认证方面，Q3C会提供的简单的SQL语句就能够执行处理工作，而HTM方面则需要从数据库中提取数据，然后利用算法进行处理，当数据量非常大的时候，程序的性能就会受到影响。三、支持的数据文件格式入库管理工具同时支持两种类型的数据格式文件：CSV(Comma-SeparatedValues)格式文件和FITS(FlexibleImageTransportSystem)格式文件。CSV文件由任意数目的记录组成，记录间以某种换行符分隔；每条记录由字段组成，字段间的分隔符是其它字符或字符串，最常见的是逗号或制表符。FITS格式是天文学界常用的数据格式，它专门为在不同平台之间交换数据而设计。1988年的国际天文学联合会IAU（InternationalAstronomicalUnion）大会指定IAU的FITS工作组全权负责此格式的修订。FITS文件由文件头和数据组成。在文件头中存储有对该文件的描述，如观测目标、源的位置、观测时间、曝光时间等信息，同时也可以在文件头中注明观测时的视场、精度等，便于后期的数据管理和分析之用。文件头部分每行占80个字符，并以END结尾。FITS文件的容量大小通常比相同数据量的CSV文件小，在本地存储中占用硬盘容量小，且天文数据文件采用FITS格式存储的文件占大多数。针对FITS格式文件数据，我们开发了一个分析FITS文件头文件的工具，用来得到头文件中表格数据中的列名和每个列对应的数据格式，方便天文学家在使用入库工具时编写readme文件。在输入不同格式文件时，工具会自动地判断文件的格式选择相应的程序实现自动入库。四、存储数据的优化庞大的天文数据中有时难免会存在的超过数据库中最大数据存储大小的数据或者小于数据库中支持的最小数据，不过在数据库中可以自己定义数据类型来支持导入的数据，但这样便失去兼容性了，使得不同数据库之间数据的交换和融合变得很困难，而且在对于文件中的数据项为空的时候，存储到数据库中会产生一些错误，所以在入库之前很有必要先对数据进行优化。因为不符合要求的数据非常少，而且改变其大小不会影响到后续的数据分析环节，故在入库前，在程序中把超出数据库最大支持数据的记录数和小于数据库最小支持数据的记录数更改为数据库所支持最大和最小的数据记录数，同时对于文件中为空的数据项，程序会根据数据类型的不同，自动的填充‘9999’或‘NULL’字样，方便数据的录入和后续的计算分析。
1.2AutoDB流程图
在存储FITS格式文件的数据时，我们还专门开发了一个分析FITS文件头文件的小工具，方便天文学家存储时选择自己想要存储的数据列。在使用过程中，天文学家也不需要编写任何的代码，同时该工具有很好的易用性。根据不同的格式文件，有着不同的入库流程，下面给出了文本CSV文件和FITS文件的入库流程，如图1所示。
1.3AutoDB系统环境支持
AutoDB采用Python语言编写，推荐使用Linux操作系统。由于Python是跨平台型语言，若需要在WINDOWS系统中使用也非难事，需要安装Python，一般的Linux发行版本都会自带Python程序，同时也需要下列数据库系统（异地或本地均可）和第三方库作为支持：1)PostgreSQL(9.0+)：支持最新的SQL语法，更高的功能完整性。2)MySQL（5.1+）：性能非常的高效。3)Q3C（QuadTreeCube）：一种基于PostgreSQL数据库的新的天文数据的索引概念，提供海量天文数据的查询与融合。该工具中同时嵌入了一个很好的虚拟终端，用户可以根据虚拟终端的反馈，了解自己在使用过程中出现了哪些错误，从而纠正错误，使得程序完美地运行。
1.4AutoDB图形用户界面
AutoDB图形入库界面如2所示，用户可以选择入哪种数据库，入库的数据文件及数据的说明文件，创建HTM的级数，每次分次上传的记录数，赤经赤纬列要指出等。在这里，用户可以直接点击程序运行图形界面，也可以手动地在命令行中使用命令来运行图形界面，其图形界面和主程序是分开的，其协助用户按照各个参数，并收集起来，按照一定的规范得到收集的参数，供主程序使用。也就是说主程序不依赖于图形界面，用户也可以手动地编辑被指定的文件来运行主程序。FITS头文件分析工具会把FITS头中的数据输出到文件中，该文件名由用户定义，在FITSSOURCEFILE对应的一行中浏览添加FITS源文件，然后在FITSHEADFILE一行中输入想要创建FITS头文件名，界面如下图3所示。在使用入库工具时，用户需要编写readme文件供程序使用，其格式如下：第一行为各列列名（即数据库表中的列名字段，请参照MySQL/PostgreSQL对字段命名相关文档），以一个或者多个空行分隔；第二行与第一行相对应，为每列的数据类型（如：float、char、varchar、double、int，具体请参照MySQL/PostgreSQL数据类型相关文档[13]），同样是以一个或者多个空行分隔，内容中不能有引号，字段不能为空或NULL。同时在对FITS文件进行入库时，需要参照头分析工具得出的头文件以及格式转换文件编写readme文件。头文分析工具得到的头文件实例如图4所示，格式转换文件如图5所示。编写readme文件完毕后，即可使用自动入库工具进行数据的录入，数据库可以自己选择，数据库服务器可以是本地服务器或远程服务器。使用远程服务器时，应该保证远程服务器支持远程连接，否则将会报错。
2实验结果
2.1Q3C索引与非Q3C索引的查询性能比较
在使用索引的时候，我们最在意的是索引是否能够提高查询效率，对于具体选择哪种索引方式，要看哪种索引提高的性能更高些。为此我们做了如下的实验测试（在数据库命令行的形式下使用SQL语句进行查询的实验）。实验数据为Pan-STARRS数据，总共11,495,847个星表源数据。对比使用Q3C索引情况下和不使用Q3C索引（对ra与dec进行B-tree索引）的情况下，实现以赤经赤纬（5度,50度）为中心，查询半径在0.1度到0.9度变化范围内的锥形查询，比较随着提取结果源数目的增多上述两种方案的查询时间，其结果如图6和图7所示。我们从图7和图8中可以看出，随着查询半径的增大，符合查询条件的源数目也在不断增多，同时查询时间以近乎线性速度增长，说明查询元组数目越多，消耗的时间也就越多。还发现使用非Q3C索引的查询时间是使用Q3C索引时间的至少100多倍以上，可见Q3C索引方式的有效性。Q3C索引具有层次结构、平等区域、异维度分布等特性的天空分区方案，对天文数据的处理具有得天独厚的优势。特别是对于数据量大的情况下，我们非常有必要使用Q3C对数据索引，其表现不仅仅是数据查询速度的提高，对日后的交叉认证起到了打下了很好的基础。这也正是我们选择Q3C索引的原因。
2.2AutoDB工具的应用
AutoDB能够快速地将数据存储到相应的数据库中，上传数据的速度与本地机器硬件性能、数据库的配置以及数据库服务器的位置（本地或异地）、数据量的多少以及索引的复杂程度都有着直接或间接的关系。建议在使用过程中本地机器中不要运行太多的其他程序。我们使用的是SDSS部分数据进行的实验，总共有100,000,000行数据导入数据库中，测试平台使用的是两台计算机平台，一个是本地数据库平台和程序运行平台，另外一个是远程数据库运行平台，通过百兆以太网访问远程数据库平台。具体配置如表1所示。在实验过程中多次分别对本地和远程数据库进行了入库，在入库时将数据分割为100,000,00行，200,000,00行，400,000,00行，600,000,00行，800,000,00行，100,000,000行数据导入数据库中，得出实验结果，如表2所示。单从数据上传的速度来看，MySQL数据库的速度要优于PostgreSQL数据库。
3总结与展望
数据管理范文第5篇
关键词：计算机；数据库；Access；模型
1、前言
随着科学技术的发展，人类进入信息大爆炸的阶段，各类信息极度丰富，数字信息技术和网络技术高度发达，掌握计算机基本知识和具备应用计算机技术的能力是当代人必备的基本素质。作为信息技术的核心，数据库技术是信息工程学科中最重要的成果和工具之一，是计算机科学技术中发展最快、应用最广的技术之一。管理信息系统MIS、办公自动化OA和决策支持系统DSS等系统的核心都离不开数据库技术的支持。本文就计算数据库管理系统带来的思考进行探讨。
2、数据库的简介
2.1数据库技术发展过程
数据库技术产生于20世纪60年代末，是数据管理的最新技术，也是计算机科学的重要分支。数据管理技术的发展，与计算机硬件、系统软件及计算机应用的范围有密切的联系。数据库发展分为：人工管理阶段、文件系统阶段、数据库系统阶段和高级数据库系统阶段。
人工管理阶段：在20世纪50年代中期，计算机主要用于科学计算，没有普及到日常生活当中，计算技术不发达，没有磁盘等存储介质，无法进行数据存储。在进行管理的时候一个应用程序对应管理一个数据集，数据管理只能由应用程序完成，数据不能共享、缺乏独立性，造成数据的冗余，并且数据不能保存，如要再次进行同样的计算则必须进行重复性操作。
文件系统阶段：到了20世纪50年代后期到60年代中期，计算机技术得到了发展，计算机开始应用于信息管理。这时，计算机数据管理采用的是文件系统阶段，应用程序管理数据文件时，不是像人工管理阶段中进行直接的一对一的管理，而是计算机对文件系统进行管理，而文件系统去管理数据文件，这样的管理形式，数据的独立性差，但可以进行数据的长时间保存，相对于人工管理阶段有了很大的改善！
数据库系统阶段：在20世纪60年代后期，计算机性能得到了大幅度的提高，特别出现了大容量的存储介质，而且其价格便宜。在这个时期，人们对计算机数据的管理就采取了比文件管理更加高级的手段——数据库系统阶段。应用程序通过数据库管理系统直接对数据库进行管理，此时的数据文件已经不是单独存在，而是统一存储于数据库当中，这样数据的独立性增强，共享程度提高，冗余程度减小。
高级数据库系统阶段：从20世纪70年代开始，数据库技术的发展步伐加快，其数据库的方法进行的进一步的完善，数据库应用的领域也广泛的扩大，在许多方面取得了很大的研究成果。
2.2数据库系统
数据库系统：简称DBS，是指拥有数据库技术支持的计算机系统。它包括有，计算机系统、数据库、数据库管理系统、数据库应用系统和有关人员。其中主要包括三方面：数据库、数据库管理系统和人员。
数据库：在计算机存储设备上按照一定的格式进行信息的存放。这样就结束了人工管理数据的那种繁杂的工作，人们可以事先把要管理的数据存放进去，这样，就可以实现对数据长时间的、大量的、有组织的管理数据。
数据库管理系统：在数据存储在计算机当中后，我们就要对这些数据进行管理，数据库管理系统就实现了这个功能。它是位于数据库和管理者之间的一个管理软件，管理者可以通过这个软件对数据进行定义、查询、插入、修改、建立、维护等操作。
人员：主要包括有数据管理员、程序员和终端人员。数据管理员可以对数据进行添加、删除、修改等操作；程序员一般对数据库管理系统进行维护，升级等；终端人员主要是对已经成型了的数据库进行使用，最后进行终端操作。
2.3数据库模型
数据库系统常用的数据模型有三种：层次模型、网状模型、关系模型。
层次模型：以树状结构进行表示，有“树根”、“树叶”，每个实体放在不同层次上，表示不同的关系。上级节点与下级节点之间为一对多的关系。在层次结构中只有一个根节点，其他节点向上只有一个父节点，向下可以有若干子节点。
网状模型：一般描述的是“多对多”的关系，其实质就是一个节点的连通图。
关系模型：这是数据库中最重要的模型，是用二维表来描述实体之间联系的一种结构模型。在二维表中，一行叫做一条记录，一列叫做一个字段，整个表表示一个关系，其关系不可再分。
3、用Access软件开发的数据库系统实例分析
Access是微软公司开发的一个数据库软件，是一种关系型的桌面数据库管理系统，其操作性简单、界面采用总控窗体的形式。
这些年，由于经济的迅猛发展，企业发展极为迅速，企业人员增加，对企业来说，人员的信息越来越多，对信息处理的要求也越来越高，手工管理的弊端日益显露，解决这个问题的最好办法是显现教工管理的自动化，用计算机处理代替手工。由此，企业管理者利用Access编写了一个企业员工管理系统。员工管理系统是一个简单的数据库应用系统，它所实现的功能包括：
员工管理：管理员工的基本资料和工资，何以浏览、增加、修改和删除员工资料和工资信息。
管理者管理：管理者的基本信息以及管理者所管理的部门信息，可以浏览、添加、修改和删除管理者信息及其管理的部门信息。
工种管理：工作种类的信息录入、员工所干的工作种类信息以员工所干工作的工资信息查询。
经上述分析，可确定其模块如下：
通过模块，我们可以确定其数据库中的表，创建表，然后确定其表间关系，根据企业对数据的具体的需要，完成Access中的七个对象：表、查询、窗体、报表、页、宏和模块。
在完成了“员工管理系统”中所有的功能设计之后，就要对这些功能进行集成，以供用户方便使用，所以，要用到Access中的切换面板管理工具把各项功能集合起来。完成这个之后，整个企业员工管理系统就设计完成了。
该系统设计简单，但足以满足一些企业对员工管理的需要，。
4、结语
随着信息化的快速发展及计算机数据库技术的快速升级，数据库目前得到广泛的应用。数据库管理系统是实现数据库应用的有效组织系统，对计算机数据库管理系统进行研究希望能够有助于加深我们对相关知识的了解。
参考文献：
[1]《Access数据库技术实训教程》 张玲 刘玉玫 清华大学出版社
[2] 《Access数据库实用教程》 郑小玲 张宏 卢山 旷野 人民邮电出版社
[3]《数据库原理与应用（Access）》清华大学出版社 周忠荣编著
