如何在excel中创建“数据库”

首先，需要在excel中添加加载项--数据分析库，然后就可以进行数据自动生成了，以专业的术语叫做“随机数发生器”。依次点击：excel选项-加载项-转到，进行分析工具库的添加工作。

分析工具库添加完成之后，在excel的“数据”选项卡上，最右侧会多出一个“分析”的菜单栏，点击“数据分析”。

选择“数据分析”下的“随机数发生器”。

d出的界面上，为随机数发生器的参数设置界面。其中，变量个数=生成数据列数、随机数个数=生成数据行数，比如，设置：变量个数=5、随机数个数=10，那么，就会生成一个5列、10行的数据。

接下来，选择随机数据的分布类型，以“正态分布”为例，设定：平均值=50、标准差=5。

选定数据的输出位置，可以选定区域、新建工作表、新建工作簿，本例中以选定区域为例来说情况，如下图，选择将数据输出到：a1：e10区域中。

数据输出成功，如下图所示。

分布式数据库系统由分布于多个计算机结点上的若干个数据库系统组成,它提供有效的存取手段来 *** 纵这些结点上的子数据库。分布式数据库在使用上可视为一个完整的数据库,而实际上它是分布在地理分散的各个结点上。当然,分布在各个结点上的子数据库在逻辑上是相关的。

关系数据库、非关系型数据库。

1、关系数据库

特点：数据集中控制；减少数据冗余等。

适用范围：对于结构化数据的处理更合适，如学生成绩、地址等，这样的数据一般情况下需要使用结构化的查询。

2、非关系数据库

特点：易扩展；大数据量，高性能；灵活的数据模型等。

使用范围：据模型比较简单；需要灵活性更强的IT系统；对数据库性能要求较高。

扩展资料：

非关系数据库的分类：

1、列存储数据库

这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra， HBase， Riak。

2、文档型数据库

文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可 以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB， MongoDb 国内也有文档型数据库SequoiaDB，已经开源。

参考资料来源：百度百科-数据库

参考资料来源：百度百科-NoSQL

自建数据库：

容易产生容量与性能瓶颈

当前的硬件条件下，主流数据库可以支持单表千万级数据量的存储，但是难以支撑密集的并发读写，存在性能瓶颈。

分区分表或分库方案限制太多

采用分区表方案，数据不能跨实例存储，扩展性和维护性较差。

采用分库方案，客户端需要自行管理各库连接，数据库连接管理和升级复杂，扩容迁移困难。

服务器成本高昂

普通X86服务器支撑能力有限，品牌厂商的服务器价格高昂，通过增加硬件规格来提升并发性能的成本太高，且能到达的性能高度有限。

在分布式数据库面前，上面这些都不是问题，有很长厂商都已经把分布式数据库做的不错了，如阿里云，华为云等。

如下以我熟悉的华为云分布式数据库中间件DDM为例为你介绍下，如果感兴趣可以去官网了解一下，现在好像还有试用活动：华为云分布式数据库中间件DDM

分布式数据库：

数据分布存储

DDM采用水平拆分方式，将数据记录数庞大的单表，按指定的拆分规则，分布式存储到各个分片中。同时DDM提供路由分发功能，应用服务无需考虑数据该写入哪个分片，该从哪个分片读取。

读写分离

用户可以根据数据读取压力负载情况，为每个RDS实例配置一个或者多个只读实例，提高查询并发性能。

高性能

在实际业务访问中，SQL主要的性能瓶颈集中在物理数据库节点上。

DDM实例关联多个RDS节点，减少单个RDS存储的数据量，同时实现并行计算，支持PB级数据量访问，以及百万级高并发。

在线平滑扩容

DDM在不中断业务的情况下，支持新增RDS实例，水平扩容存储空间。一键式扩容，轻松解决单机数据库的容量瓶颈。

随着时间和业务的发展，数据库中的数据量增长是不可控的，库和表中的数据会越来越大，随之带来的是更高的 磁盘 、 IO 、 系统开销 ，甚至 性能 上的瓶颈，而单台服务器的 资源终究是有限 的。

因此在面对业务扩张过程中，应用程序对数据库系统的 健壮性 ， 安全性 ， 扩展性 提出了更高的要求。

以下，我从数据库架构、选型与落地来让大家入门。

数据库会面临什么样的挑战呢？

业务刚开始我们只用单机数据库就够了，但随着业务增长，数据规模和用户规模上升，这个时候数据库会面临IO瓶颈、存储瓶颈、可用性、安全性问题。

为了解决上述的各种问题，数据库衍生了出不同的架构来解决不同的场景需求。

将数据库的写 *** 作和读 *** 作分离，主库接收写请求，使用多个从库副本负责读请求，从库和主库同步更新数据保持数据一致性，从库可以水平扩展，用于面对读请求的增加。

这个模式也就是常说的读写分离，针对的是小规模数据，而且存在大量读 *** 作的场景。

因为主从的数据是相同的，一旦主库宕机的时候，从库可以 切换为主库提供写入 ，所以这个架构也可以提高数据库系统的 安全性 和 可用性 ；

优点：

缺点：

在数据库遇到 IO瓶颈 过程中，如果IO集中在某一块的业务中，这个时候可以考虑的就是垂直分库，将热点业务拆分出去，避免由 热点业务 的 密集IO请求 影响了其他正常业务，所以垂直分库也叫 业务分库 。

优点：

缺点：

在数据库遇到存储瓶颈的时候，由于数据量过大造成索引性能下降。

这个时候可以考虑将数据做水平拆分，针对数据量巨大的单张表，按照某种规则，切分到多张表里面去。

但是这些表还是在同一个库中，所以库级别的数据库 *** 作还是有IO瓶颈（单个服务器的IO有上限）。

所以水平分表主要还是针对 数据量较大 ，整体业务 请求量较低 的场景。

优点：

缺点：

四、分库分表

在数据库遇到存储瓶颈和IO瓶颈的时候，数据量过大造成索引性能下降，加上同一时间需要处理大规模的业务请求，这个时候单库的IO上限会限制处理效率。

所以需要将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。

分库分表能够有效地缓解单机和单库的 性能瓶颈和压力 ，突破IO、连接数、硬件资源等的瓶颈。

优点：

缺点：

注：分库还是分表核心关键是有没有IO瓶颈 。

分片方式都有什么呢？

RANGE（范围分片）

将业务表中的某个 关键字段排序 后，按照顺序从0到10000一个表，10001到20000一个表。最常见的就是 按照时间切分 （月表、年表）。

比如将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据被查询的概率变小，银行的交易记录多数是采用这种方式。

优点：

缺点：

HASH（哈希分片）

将订单作为主表，然后将其相关的业务表作为附表，取用户id然后 hash取模 ，分配到不同的数据表或者数据库上。

优点：

缺点：

讲到这里，我们已经知道数据库有哪些架构，解决的是哪些问题，因此， 我们在日常设计中需要根据数据的特点，数据的倾向性，数据的安全性等来选择不同的架构 。

那么，我们应该如何选择数据库架构呢？

虽然把上面的架构全部组合在一起可以形成一个强大的高可用，高负载的数据库系统，但是架构选择合适才是最重要的。

混合架构虽然能够解决所有的场景的问题，但是也会面临更多的挑战，你以为的完美架构，背后其实有着更多的坑。

1、对事务支持

分库分表后（无论是垂直还是水平拆分），就成了分布式事务了，如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价（XA事务）；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担（TCC、SAGA）。

2、多库结果集合并 （group by，order by）

由于数据分布于不同的数据库中，无法直接对其做分页、分组、排序等 *** 作，一般应对这种多库结果集合并的查询业务都需要采用数据清洗、同步等其他手段处理（TIDB、KUDU等）。

3、数据延迟

主从架构下的多副本机制和水平分库后的聚合库都会存在主数据和副本数据之间的延迟问题。

4、跨库join

分库分表后表之间的关联 *** 作将受到限制，我们无法join位于不同分库的表（垂直），也无法join分表粒度不同的表（水平）， 结果原本一次查询就能够完成的业务，可能需要多次查询才能完成。

5、分片扩容

水平分片之后，一旦需要做扩容时。需要将对应的数据做一次迁移，成本代价都极高的。

6、ID生成

分库分表后由于数据库独立，原有的基于数据库自增ID将无法再使用，这个时候需要采用其他外部的ID生成方案。

一、应用层依赖类（JDBC）

这类分库分表中间件的特点就是和应用强耦合，需要应用显示依赖相应的jar包（以Java为例），比如知名的TDDL、当当开源的 sharding-jdbc 、蘑菇街的TSharding等。

此类中间件的基本思路就是重新实现JDBC的API，通过重新实现 DataSource 、 PrepareStatement 等 *** 作数据库的接口，让应用层在 基本 不改变业务代码的情况下透明地实现分库分表的能力。

中间件给上层应用提供熟悉的JDBC API，内部通过 sql解析 、 sql重写 、 sql路由 等一系列的准备工作获取真正可执行的sql，然后底层再按照传统的方法（比如数据库连接池）获取物理连接来执行sql，最后把数据 结果合并 处理成ResultSet返回给应用层。

优点

缺点

二、中间层代理类（Proxy）

这类分库分表中间件的核心原理是在应用和数据库的连接之间搭起一个 代理层 ，上层应用以 标准的MySQL协议 来连接代理层，然后代理层负责 转发请求 到底层的MySQL物理实例，这种方式对应用只有一个要求，就是只要用MySQL协议来通信即可。

所以用MySQL Navicat这种纯的客户端都可以直接连接你的分布式数据库，自然也天然 支持所有的编程语言 。

在技术实现上除了和应用层依赖类中间件基本相似外，代理类的分库分表产品必须实现标准的MySQL协议，某种意义上讲数据库代理层转发的就是MySQL协议请求，就像Nginx转发的是>

MySQL、PostgreSQL属于关系型数据库

分布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都可能有DBMS的一份完整拷贝副本，或者部分拷贝副本，并具有自己局部的数据库，位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。

比较火的分布式数据库有tidb和 sequoiadb

数据库关系模型（数据库逻辑模型）是将数据概念模型转换为所使用的数据库管理系统（DBMS）支持的数据库逻辑结构，即将E-R图表示成关系数据库模式。数据库逻辑设计的结果不是唯一的，需利用规范化理论对数据库结构进行优化。

在关系模型中，数据库的逻辑结构是一张二维表。在数据库中，满足下列条件的二维表称为关系模型：

1）每列中的分量是类型相同的数据；

2）列的顺序可以是任意的；

3）行的顺序可以是任意的；

4）表中的分量是不可再分割的最小数据项，即表中不允许有子表；

5）表中的任意两行不能完全相同。

由此可见，有序的航空物探测量剖面数据不满足数据库关系模型条件第3条“行的顺序可以是任意的”，因此，不能简单地直接利用关系数据库（如Oracle，SQL Server，Sybase等）来管理剖面数据，需将数据在数据库中的存储方式改为大字段存储，确保不因数据库数据的增加和删除等 *** 作改变剖面数据有序特性。

一、大字段存储

（一）大字段存储技术

大字段LOB（Large Object）技术是Oracle专门用于存放处理大对象类型数据（如多媒体材料、影像资料、文档资料等）的数据管理技术。LOB包括内部的和外部的两种类型。内部LOB又分CLOB（字符型）、BLOB（二进制型）等3种数据类型，其数据存储在数据库中，并且支持事务 *** 作；外部LOB只有BFILE类型，其数据存储在 *** 作系统中，并且不支持事务 *** 作。LOB存放数据的长度最大可以达到4G字节，并且空值列（没有存放数据）不占空间（图2-6）。

图2-6 大字段存储示意图

由于外部LOB存放在 *** 作系统文件中，其安全性比内部LOB差一些。此外，大字段的存储支持事务 *** 作（批量提交和回滚等），而外部LOB不支持事务 *** 作。所以，航空物探测量剖面数据采用BLOB来存储。对于BLOB类型，如果数据量小于4000字节，数据库通常采用行内存储，而数据量大于4000字节采用行外存储。分析航空物探测量剖面数据，每个场值数据占4个字节（单精度），目前航磁数据采样率为10次/s，4000字节只能存储100 s数据；一般情况下航空物探测量每条测线飞行时间至少在10 min以上，每条测线数据量远远大于4000字节。所以，航空物探测量剖面数据采用行外存储方式，即大字段列指定“Disable Storage In Row”的存储参数。

由于大字段类型长度可变，最大可到4G。假设测线飞行时间为T，场值采样率为n次/s，测线场值数据量为4Tn，所以有4Tn≤4G。单条测线飞行时间T不会超过10 h（36000 s，航空物探测量1架次至少飞行1个往返2条测线），则场值的采样率n≤4G/4T=4×1024×1024×1024/4×36000次/s=29826次/s。采用大字段来存储测量数据，不仅能够减少数据表的记录数，提高查询效率，而且使得采样率的扩展不受限制。

（二）大字段存储技术应用

由于航空物探数据的数据量较大，现有的航磁测量数据按基准点方式（点存储）存储可达几亿个数据记录。若按磁场数据采样点存储方式（简称“场值存储方式”），则记录条数=（磁场数据采样率/坐标采样率）点存储方式的记录数，达几十亿条数据记录，且随着数据采样率的扩展、测点的加密，航空物探测量数据量随着时间的推移呈现快速增长之势。显然，如果采用常规的表结构来存储，势必造成数据的存储、管理、检索、浏览和提取都非常困难。另一方面，从航空物探专业应用需求来说，很少对单个测点的场值数据进行运算、分析等 *** 作，一般至少是对一条测线或以上测线，多数时候是需要对整个测区的场值数据进行化极、上延、正反演拟合等。

因此，在航空物探数据库表结构设计时，改变过去将基准点或场值点数据记录作为数据库最小管理对象的理念，采用了大字段存储技术，将测线作为数据库最小管理对象，将测线上的测量数据，如坐标数据和磁场、重力场数据分别存储在相应大字段中。在航空物探数据库建设中，大量采用数据库的大字段存储技术（详见《航空物探信息系统数据库结构设计》）。

（三）大字段存储效率

以航磁测量数据为例分析大字段存储技术优势。如果以场值存储方式存储测线数据，则每条记录包含架次号、测线号、基准号、地理坐标、投影坐标、磁场数据等，由于坐标数据采样率2次/s，磁场数据采样率10次/s，每5个磁场数据中，只有第1个磁场数据有坐标数据，其他4个坐标数据是内插出来，因此在测线记录中会产生大量冗余的数据坐标数据。采用点存储方式存储的测线数据记录数等于线上基准点数，若采用大字段存储方式，一条测线数据只存储为1条数据记录（图2-7），一般一条测线的测点数近万个，甚至更多，可见采用大字段存储大大减少测线数据存储记录数，提高数据的存取效率。

以某测区的两条航迹线为例，分别采用3种方式测试数据库的数据存储效率。磁场数据的采样率10次/s，坐标数据采样率2次/s，两条测线上共有基准点8801个。以场值方式存储先内插坐标信息，使得每个场值数据都拥有自己的坐标，然后存入数据库，共有数据记录44005条，写入数据库时间为5722 s，读取时间为103 s。第二种方式是以采样点的方式进行存储，共有8801条记录，写入数据库时间为947 s，读取需要091 s。第三种方式是以大字段的形式存储，只有2条记录，写入数据库103 s，读取时间为044 s（表2-2）。大字段数据存储记录数最少，存取效率最高。用整个测区数据测试效果更加明显。

表2-2 三种数据存储方法的存取效率比较

图2-7 大字段存储方式示意图

二、联合主键

主外键是关系型数据库建立表间关系的核心。在航空物探空间数据库建设过程中，要素类与要素类之间、要素类与对象类之间，以及对象类与对象类之间的关系的描述有3种形式，即拓扑关系——描述要素类与要素类之间结点、邻接和联通关系；叠加关系——描述要素类与要素类之间的相交、包含与分类关系；隶属关系——描述对象类与对象类之间的派生关系。前两种关系是采用空间数据模型建立的关系，而隶属关系是通过主键建立的对象类与对象类之间的关系。在建立一对一、一对多的表间关系时，需要在整个数据库表中确定具有唯一性的一个字段作为主键（主关键字）。

按照传统的航空物探数据的档案管理模式，每个项目分配一个自然数作为档案号，项目的所有资料均与此档案号相联系。勘查项目和科研项目的档案号是独立编号的，且均从001开始。加之人工管理的原因，存在1个项目2个档案号和2个项目1个档案号的情况，因此现行的档案号与项目之间的对应关系不具备唯一性，不能作为项目的唯一标识，即不能作为数据库表的主键。项目编号也不能作为数据库表的主键，项目编号也只是近十年的事，以前的项目没有项目编号。

综合考虑上述因素和项目具有分级、分类的特点，提出了构造项目唯一标识码（简称“项目标识”）的方法，并以此码作为数据库表的主键。

项目标识（主键）：AGS+项目类别（2位）+项目起始年份（4位）+档案号（6位）

标识含义：AGS——航空物探的缩位代码；

项目类别——2位代码，01代表勘查项目、02代表科研项目；

起始年份——4位代码，项目开始年号；

档案号——6位代码，为了与传统的项目管理方式相衔接，后面3～4位是

项目档案管理模式下的档案号，不足部分补零。

以上15位编码是一级项目的项目标识，二级及其以下级别的项目标识是在上一级项目标识基础上扩展2位数字代码，中间用“”号隔开，数字为该级项目的序号。项目标识定义为30位编码，适用于六级以内的项目。例如：AGS022004000576080402，表示该项目为2004年开展的档案号为576的航空物探科研项目（一级项目）的第8课题（二级项目）第4子课题（三级项目）的第2专题。由此可见，该项目标识不仅仅是一个建立表间关系的关键字，同时还表达了不同级别项目间的隶属关系。在系统软件开发时，利用此关系生成了项目的分级树形目录，用户对项目的层次关系一目了然，便于项目查询。

数据库的主键一经确定，相应地需要确定联合主键的组成及其表达方式。所谓联合主键就是数据资料的唯一标识，在一个数据库表中选择2个或者2个以上的字段作为主键。由于航空物探数据绝大部分与项目标识有关，加之数据的种类较多，分类复杂，单凭主键确定数据库表中记录的唯一性，势必需要构建极其复杂的主键，这种方法既不利于主键的数据 *** 作，又会造成大量的数据冗余，合理地使用联合主键技术可以很好地解决资料唯一问题。以项目提交资料为例，提交的资料分为文字类资料、图件类资料和媒体类资料，我们对资料进行分类和编号，例如100代表文字资料（110——World文档，120——PDF文档），200代表图件资料（210——基础地理资料、220——基础地质资料，230——航迹线图，240——剖面图，250——等值线图等），300代表媒体资料（310——PPT文档，320——照片等），第1位（百位）表示该资料的类型，第2～3位表示该类资料的序号。

在数据库管理和项目资料查询时，采用项目标识与资料分类编号作为联合主键（图2-8），可以高效地实现复杂数据的查询。在整个数据库系统中多处（项目查询、数据提取等模块）使用联合主键技术。

图2-8 联合主键实例

三、信息标准化

为了实现数据共享，在航空物探数据库建模过程中，参考和引用了近百个国家信息化标准，编制了4个中心信息化标准和1个图件信息化工作指南。

（一）引用的国家信息化标准

1）地质矿产术语分类代码：地球物理勘查，地球化学勘查，大地构造学，工程地质学，结晶学及矿物学，矿床学，水文地质学，岩石学，地质学等。

2）国家基础信息数据分类与代码，国土基础信息数据分类与代码，地球物理勘查技术符号，地面重力测量规范，地面磁勘查技术规程，地面高精度磁测技术规程，大比例尺重力勘查规范，地理信息技术基本术语，地理点位置的纬度、经度和高程的标准表示法，地名分类与类别代码编制规则。

3）地球空间数据交换格式；数学数字地理底图数据交换格式；数字化地质图图层及属性文件格式。

（二）本系统建立的信息化标准

编写了“航空物探空间数据要素类和对象类划分标准”，“航空物探项目管理和资料管理分类代码标准”，“航空物探勘查分类代码标准”，“航空物探信息系统元数据标准”，“航空物探图件信息化工作指南”，以便与其他应用系统进行信息交换，实现数据库资料共享。

航空物探空间数据要素类和对象类划分标准：根据物探方法、数据处理过程以及推断解释方法和过程，把与GIS有关的数据划分为不同类型的要素类-对象类数据，按专业、比例尺、数据内容对要素类和对象类进行统一命名，使空间数据库中的每个要素类和对象类的命名具有唯一性，防止重名出现。规定要素类-对象类数据库表结构及数据项数值类型。

航空物探项目管理和资料管理分类代码标准：规定了航空物探项目管理和资料管理的相关内容，包括航空物探勘查项目和科研项目的项目立项、设计、实施、成果、评审、资料汇交等项目管理的全过程中的内容，以及项目成果资料和收集资料的归档、发送、销毁、借阅等资料管理与服务过程中的内容和数据项代码。

航空物探勘查分类代码标准：在“地质矿产术语分类代码 地球物理勘查”（国家标准GB/T 964928—1998）增加了航磁、航重专业方面所涉及的数据采集、物性参数、方法手段、仪器设备、资料数据解释及成图图件等内容和数据项代码。

航空物探信息系统元数据标准：规定了航空物探空间数据管理与服务的元数据（数据的标识、内容、质量、状况及其他有关特征）的内容。

四、航迹线数据模型

（一）航迹线模型的结构

航空物探测量是依据测量比例尺在测区内布置测网（测线和切割线）。当飞机沿着设计的测线飞行测量时，航空物探数据收录系统按照一定的采样率采集采样点的地理位置、高度和各种地球物理场信息。采用属性数据分置的方法，将测线地理位置信息从航空物探测量数据中分离出来，形成航迹线要素类表，在此表中只存储与航迹线要素类有关的数据，如项目标识、测区编号、测线号、测线类型（用于区分测线、切割线、不同高度线、重复线等）、坐标、高度值等；将航迹线的对象类数据（磁场、重力场基础数据）分别以大字段形式存储在各自的二维表中，它们共享航迹线，解决了多源有序不同采样率的航空物探测量数据的数据存储问题，在满足要素类空间查询的同时，统一数据的存储方式（图2-9）。航迹线要素类隶属于测区要素类，它们之间为空间拓扑（包含）关系。测区从属于勘查项目，每个勘查项目至少有一个测区，它们之间为1对多关系。有关项目信息存放在项目概况信息对象类表中，各种表之间通过项目标识进行联接。

图2-9 航迹线数据模型结构

（二）航迹线的UML模型

统一建模语言UML（Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。UML是面向对象技术领域内占主导地位的标准建模语言，成为可视化建模语言的工业标准。在UML基础上，ESRI定义了空间数据库建模的ArcGIS包、类库和扩展原则。

图2-10 与航迹线有关的数据库表逻辑模型结构图

在确定航迹线数据模型后，以它为基础，使用UML完成与航迹的有关的项目概况信息、测区信息、原始数据等数据库表逻辑模型设计（图2-10）。

由UML模型生成Geodatabase模式时，模型中的每个类都对应生成一个要素类或对象类。类的属性映射为要素类或对象类的字段。基类属性中包含的字段，在继承类中不需重复创建。例如，每个类都包括项目标识等字段，可以创建一个包含公共属性的基类，其他类从该类继承公共的属性，而无需重复建基类中包含的属性。因为基类没有对应的要素类或对象类，所以将基类设置为抽象类型。要素类之间的关系采用依赖关系表示。

五、数据库逻辑模型

关系数据库的逻辑结构由一组关系模式组成，因而从概念结构到关系数据库逻辑结构的转换就是将概念设计中所得到的概念结构（ER图）转换成等价的UML关系模式（图2-11）。在UML模型图中，要素数据集用Geodatabase工作空间下的静态包表示。要素集包不能互相嵌套，为了容易组织，在生成物理模型后，在要素数据集包中自定义嵌套。要素数据集与空间参考有关，但是空间参考不能在UML中表达。要素类和二维表都是以类的形式创建的，区别是要素类继承Feature Class的属性，而二维表继承Object属性。为了表达每种元素的额外属性，比如设置字符型属性字段的字符串长度，设置要素类的几何类型（点、线或面）需要使用Geodatabase预定义的元素标记值。

图2-11 逻辑设计关系转换

基于航空物探数据的内在逻辑关系进行分析，使用统一建模语言（UML）构建数据实体对象间的关系类，定义了航空物探数据库的逻辑模型（图2-12）。

通常数据库分为关系型数据库和非关系型数据库，关系型数据库的优势到现在也是无可替代的，比如MySQL、SQLServer、Oracle、DB2、SyBase、Informix、PostgreSQL以及比较小型的Aess等等数据库，这些数据库支持复杂的SQL *** 作和事务机制，适合小量数据读写场景；但是到了大数据时代，人们更多的数据和物联网加入的数据已经超出了关系数据库的承载范围。

大数据时代初期，随着数据请求并发量大不断增大，一般都是采用的集群同步数据的方式处理，就是将数据库分成了很多的小库，每个数据库的数据内容是不变的，都是保存了源数据库的数据副本，通过同步或者异步方式保证数据的一致性，每个库设定特定的读写方式，比如主数据库负责写 *** 作，从数据库是负责读 *** 作，等等根据业务复杂程度以此类推，将业务在物理层面上进行了分离，但是这种方式依旧存在一定的负载压力的问题，企业数据在不断的扩增中，后面就采用分库分表的方式解决，对读写负载进行分离，但是这种实现依旧存在不足，且需要不断进行数据库服务器扩容。

NoSQL数据库大致分为5种类型

1、列族数据库：BigTable、HBase、Cassandra、AmazonSimpleDB、HadoopDB等，下面简单介绍几个

（1）Cassandra：Cassandra是一个列存储数据库，支持跨数据中心的数据复制。它的数据模型提供列索引，log-structured修改，支持反规范化，实体化视图和嵌入超高速缓存。

（2）HBase：ApacheHbase源于Google的Bigtable，是一个开源、分布式、面向列存储的模型。在Hadoop和HDFS之上提供了像Bigtable一样的功能。

（3）AmazonSimpleDB：AmazonSimpleDB是一个非关系型数据存储，它卸下数据库管理的工作。开发者使用Web服务请求存储和查询数据项

（4）ApacheAumulo：ApacheAumulo的有序的、分布式键值数据存储，基于Google的BigTable设计，建立在ApacheHadoop、Zookeeper和Thrift技术之上。

（5）Hypertable：Hypertable是一个开源、可扩展的数据库，模仿Bigtable，支持分片。

（6）AzureTables：WindowsAzureTableStorageService为要求大量非结构化数据存储的应用提供NoSQL性能。表能够自动扩展到TB级别，能通过REST和ManagedAPI访问。

2、键值数据库：Redis、SimpleDB、Scalaris、Memcached等，下面简单介绍几个

（1）Riak：Riak是一个开源，分布式键值数据库，支持数据复制和容错。（2）Redis：Redis是一个开源的键值存储。支持主从式复制、事务，Pub/Sub、Lua脚本，还支持给Key添加时限。

（3）Dynamo：Dynamo是一个键值分布式数据存储。它直接由亚马逊Dynamo数据库实现；在亚马逊S3产品中使用。

（4）OracleNoSQLDatabase：来自Oracle的键值NoSQL数据库。它支持事务ACID（原子性、一致性、持久性和独立性）和JSON。

（5）OracleNoSQLDatabase：具备数据备份和分布式键值存储系统。

（6）Voldemort：具备数据备份和分布式键值存储系统。

（7）Aerospike：Aerospike数据库是一个键值存储，支持混合内存架构，通过强一致性和可调一致性保证数据的完整性。

3、文档数据库：MongoDB、CouchDB、Perservere、Terrastore、RavenDB等，下面简单介绍几个

（1）MongoDB：开源、面向文档，也是当下最人气的NoSQL数据库。

（2）CounchDB：ApacheCounchDB是一个使用JSON的文档数据库，使用Javascript做MapRece查询，以及一个使用>

（3）Couchbase：NoSQL文档数据库基于JSON模型。

（4）RavenDB：RavenDB是一个基于NET语言的面向文档数据库。

（5）MarkLogic：MarkLogicNoSQL数据库用来存储基于XML和以文档为中心的信息，支持灵活的模式。

4、图数据库：Neo4J、InfoGrid、OrientDB、GraphDB，下面简单介绍几个

（1）Neo4j：Neo4j是一个图数据库；支持ACID事务（原子性、独立性、持久性和一致性）。

（2）：一个图数据库用来维持和遍历对象间的关系，支持分布式数据存储。

（3）：是结合使用了内存和磁盘，提供了高可扩展性，支持SPARQ、RDFS和Prolog推理。

5、内存数据网格：Hazelcast、OracleCoherence、TerracottaBigMemorry、GemFire、Infinispan、GridGain、GigaSpaces，下面简单介绍几个

（1）Hazelcast：HazelcastCE是一个开源数据分布平台，它允许开发者在数据库集群之上共享和分割数据。

（2）OracleCoherence：Oracle的内存数据网格解决方案提供了常用数据的快速访问能力，一致性支持事务处理能力和数据的动态划分。

（3）TerracottaBigMemory：来自Terracotta的分布式内存管理解决方案。这项产品包括一个Ehcache界面、Terracotta管理控制台和BigMemory-Hadoop连接器。

（4）GemFire：VmwarevFabricGemFire是一个分布式数据管理平台，也是一个分布式的数据网格平台，支持内存数据管理、复制、划分、数据识别路由和连续查询。

（5）Infinispan：Infinispan是一个基于Java的开源键值NoSQL数据存储，和分布式数据节点平台，支持事务，peer-to-peer及client/server架构。

（6）GridGain：分布式、面向对象、基于内存、SQLNoSQL键值数据库。支持ACID事务。

（7）GigaSpaces：GigaSpaces内存数据网格能够充当应用的记录系统，并支持各种各样的高速缓存场景。

以上就是关于如何在excel中创建“数据库”全部的内容，包括:如何在excel中创建“数据库”、名词解释 分布式数据库、常用的数据库有哪几种试着阐述每种数据库的特点和使用范围等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！