非关系型数据库的资料
keven的路
一些技术上小的琐碎心得；研究轻便敏捷的IT项目管理模式，以适应中国国情；对职业教育产业运作方式的思考；人力资源管理理念，人才开发，劳动法规；我的小家；路还在继续…
随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：
1、High performance –对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。
2、Huge Storage –对海量数据的高效率存储和访问的需求
类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。
3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求
在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？
在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：
1、数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。
2、数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
3、对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生，现在这两年，各种各样非关系数据库，特别是键值数据库(Key-Value Store DB)风起云涌，多得让
人眼花缭乱。前不久国外刚刚举办了NoSQL Conference，各路NoSQL数据库纷纷亮相，加上未亮相但
是名声在外的，起码有超过10个开源的NoSQLDB，例如：
Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable，Riak，Tin，Flare，Lightcloud，KiokuDB，Scalaris，Kai，ThruDB，……
这些NoSQL数据库，有的是用C/C++编写的，有的是用Java编写的，还有的是用Erlang编写的，每个
都有自己的独到之处，看都看不过来了，这些NoSQL数据库大致可以分为以下的三类：
一、满足极高读写性能需求的Kye-Value数据库：Redis，Tokyo Cabinet，Flare
高性能Key-Value数据库的主要特点就是具有极高的并发读写性能，Redis，Tokyo Cabinet，Flare，这
3个Key-Value DB都是用C编写的，他们的性能都相当出色，但出了出色的性能，他们还有自己独特的
功能：
1、Redis
Redis是一个很新的项目，刚刚发布了1.0版本。Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作，是我知道
的性能最快的Key-Value DB。
Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存List链表和Set集合的数据结构，而且还
支持对List进行各种操作，例如从List两端push和pop数据，取List区间，排序等等，对Set支持各种集合的并集交集操作，此外单个value的最大限制是1GB，不像memcached只能保存1MB的数据，因
此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性
能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一个功能加强版的memcached来用。
Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，并且它没有原生
的可扩展机制，不具有scale（可扩展）能力，要依赖客户端来实现分布式读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。目前使用Redis的网站有github，Engine Yard。
2、Tokyo Cabinet和Tokoy Tyrant
TC和TT的开发者是日本人MikioHirabayashi，主要被用在日本最大的SNS网站mixi.jp上，TC发展的时间最早，现在已经是一个非常成熟的项目，也是Kye-Value 数据库领域最大的热点，现在被广泛的应用在很多很多网站上。TC是一个高性能的存储引擎，而TT提供了多线程高并发服务器，性能也非常出色，每秒可以处理4-5万次读写操作。
TC除了支持Key-Value存储之外，还支持保存Hashtable数据类型，因此很像一个简单的数据库表，并
且还支持基于column的条件查询，分页查询和排序功能，基本上相当于支持单表的基础查询功能了，所
以可以简单的替代关系数据库的很多操作，这也是TC受到大家欢迎的主要原因之一，有一个Ruby的项
目miyazakiresistance将TT的hashtable的操作封装成和ActiveRecord一样的操作，用起来非常爽。
TC/TT在mixi的实际应用当中，存储了2000万条以上的数据，同时支撑了上万个并发连接，是一个久经考验的项目。TC在保证了极高的并发读写性能的同时，具有可靠的数据持久化机制，同时还支持类似关系数据库表结构的hashtable以及简单的条件，分页和排序操作，是一个很棒的NoSQL数据库。
TC主要的缺点是没有scale的能力，如果单机无法满足要求，只能通过主从复制的方式扩展，另外有人提到TC的性能会随着数据量的增加而下降，当数据量上亿条以后，性能会有比较明显的下降。
这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考
3、Flare
TC是日本第一大SNS网站mixi开发的，而Flare是日本第二大SNS网站green.jp开发的，有意思吧。Flare简单的说就是给TC添加了scale功能。他替换掉了TT部分，自己另外给TC写了网络服务器，Flare 的主要特点就是支持scale能力，他在网络服务端之前添加了一个node server，来管理后端的多个服务器节点，因此可以动态添加数据库服务节点，删除服务器节点，也支持failover。如果你的使用场景必须要让TC可以scale，那么可以考虑flare。
flare唯一的缺点就是他只支持memcached协议，因此当你使用flare的时候，就不能使用TC的table数据结构了，只能使用TC的key-value数据结构存储。
二、满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB
面向文档的非关系数据库主要解决的问题不是高性能的并发读写，而是保证海量数据存储的同时，具有良好的查询性能。MongoDB是用C++开发的，而CouchDB则是Erlang开发的：
1、MongoDB
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。
Mongo主要解决的是海量数据的访问效率问题，根据官方的文档，当数据量达到50GB以上的时候，Mongo 的数据库访问速度是MySQL的10倍以上。Mongo的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万－1.5次读写请求。
因为Mongo主要是支持海量数据存储的，所以Mongo还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储，但我也看到有些评论认为GridFS性能不佳，这一点还是有待亲自做点测试来验证了。
最后由于Mongo可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎，很多项目都考虑用MongoDB来替代MySQL来实现不是特别复杂的Web应用，比方说why we migrated from MySQL to MongoDB就是一个真实的从MySQL迁移到MongoDB的案例，由于数据量实在太大，所以迁移到了Mongo上面，数据查询的速度得到了非常显著的提升。
MongoDB也有一个ruby的项目MongoMapper，是模仿Merb的DataMapper编写的MongoDB的接口，使用起来非常简单，几乎和DataMapper一模一样，功能非常强大易用。
2、CouchDB
CouchDB现在是一个非常有名气的项目，似乎不用多介绍了。但是我却对CouchDB没有什么兴趣，主要是因为CouchDB仅仅提供了基于HTTP REST的接口，因此CouchDB单纯从并发读写性能来说，是非常糟糕的，这让我立刻抛弃了对CouchDB的兴趣。
三、满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra，Voldemort
面向scale能力的数据库其实主要解决的问题领域和上述两类数据库还不太一样，它首先必须是一个分布式的数据库系统，由分布在不同节点上面的数据库共同构成一个数据库服务系统，并且根据这种分布式架构来提供online的，具有弹性的可扩展能力，例如可以不停机的添加更多数据节点，删除数据节点等等。因此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort
都是用Java开发的：
Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会被复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事情，只管在群集里面添加节点就可以了。我看到有文章说Facebook的Cassandra群集有超过100台服务器构成的数据库群集。
Cassandra也支持比较丰富的数据结构和功能强大的查询语言，和MongoDB比较类似，查询功能比MongoDB稍弱一些，twitter的平台架构部门领导Evan Weaver写了一篇文章介绍Cassandra：
https://www.360docs.net/doc/a38928087.html,/articles/2009/07/06 /up-and-running-with-cassandra/，有非常详细的介绍。
Cassandra以单个节点来衡量，其节点的并发读写性能不是特别好，有文章说评测下来Cassandra每秒大约不到1万次读写请求，我也看到一些对这个问题进行质疑的评论，但是评价Cassandra单个节点的性能是没有意义的，真实的分布式数据库访问系统必然是n多个节点构成的系统，其并发性能取决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。
2、Voldemort
Voldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统，Cassandra来自于Facebook这个SNS网站，而Voldemort则来自于Linkedin这个SNS网站。说起来SNS网站为我们贡献了n多的NoSQL数据库，例如Cassandar，Voldemort，Tokyo Cabinet，Flare等等。Voldemort的资料不是很多，因此我没有特别仔细去钻研，Voldemort官方给出Voldemort的并发读写性能也很不错，每秒超过了1.5万次读写。
从Facebook开发Cassandra，Linkedin开发Voldemort，我们也可以大致看出国外大型SNS网站对于分布式数据库，特别是对数据库的scale能力方面的需求是多么殷切。前面提到，web应用的架构当中，web 层和app层相对来说都很容易横向扩展，唯有数据库是单点的，极难scale，现在Facebook和Linkedin 在非关系型数据库的分布式方面探索了一条很好的方向，这也是为什么现在Cassandra这么热门的主要原因。
引文来源常见非关系型数据库(NoSQL)推荐介绍(Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable，Riak，Tin，Flare，Lightcloud，KiokuDB，Scalaris，Kai，ThruDB ) - keven的路
数据库设计理论
数据库的设计理论 第一节，关系模式的设计问题 一概念： 1. 关系模型：用二维表来表示实体集，用外键来表示实体间的联系，这样的数据模型，叫做关系数据模型。 关系模型包含内涵和外延两个方面： 外延：就是关系或实例、或当前值。它与时间有关，随时间的变化而变化。（主要是由于元组的插入、删除、修改等操作引起的） 内涵：内涵是与时间独立的，它包括关系属性、以及域的一些定义和说明。还有数据的各种完整性约束。 数据的完整性约束分为静态约束和动态约束。 静态约束包括数据之间的联系（称为数据依赖），主键的设计和各种限制。 动态约束主要定义如插入、删除和修改等操作的影响。 通常我们称内涵为关系模式。 2. 关系模式：是对一个关系的描述，二维表的表头那一行称为关系模式，又称为表的框架或记录类型。 关系模式的定义包括：模式名、属性名、值域名和模式的主键。关系模式仅仅是对数据特征的描述。 关系模式的一般形式为R ( U , D , DOM , F ) R 是关系名。 U 是全部属性的集合。 D 是属性域的集合。 DOM 是U 和D 之间的映射关系，关系运算的安全限制。 F 是属性间的各种约束关系，也称为数据依赖。
关系模式可以表示为： 关系模式（属性名1，属性名2 ，……，属性名n ） 示例：学生（学号，姓名，年龄，性别，籍贯）。 当且仅当U 上的一个关系r 满足 F 时，r 就称为关系模式R（U，F）上的一个关系，R是关系的型，r 是关系的值，每个值称为R 的一个关系。 关系数据库模式： 一个数据库是由多个关系构成的。 一个关系数据库对应多个不同的关系模式，关系数据库模式是一个数据库中所有的关系模式的集合。它规定了数据库的全局逻辑结构。 关系数据库模式可以表示为： S = { Ri < Ui , Di , DOM , Fi > | i = 1,2,…, n } 3. 关系子模式 关系子模式是用户所用到的那部分数据的描述。 外模式是关系子模式的集合。 4. 存储模式 存储模式及内模式。 关系数据库理论的主要内容： （1）数据依赖。数据依赖起着核心的作用。 （2）范式。 （3）模式的设计方法。 如何设计一个合理的数据库模式： （1）与实际问题相结合。 泛关系模式：把现实问题的所有属性组成一个关系模式 泛关系：泛关系模式的实例称为泛关系。 泛关系模式中存在的问题： a 数据冗余 b 更新异常， c 插入异常 d 删除异常。
关系型数据库设计原理
关系型数据库设计原理 1．为E-R图中的每个实体建立一张表。 2．为每张表定义一个主键（如果需要，可以向表添加一个没有实际意义的字段作为该表的主键） 3．增加外键表示一对多关系。 4．建立新表表示多对多关系。 5．为字段选择合适的数据类型。 6．定义约束条件（如果需要）。 7．评价关系的质量，并进行必要的改进 数据库是存储数据库对象的容器。MySQL数据库的管理主要包括数据库的创建、选择当前操作的数据库、显示数据库结构以及删除数据库等操作。成功创建choose数据库后，数据库根目录下会自动创建数据库目录。使用MySQL命令show databases;即可查看MySQL服务实例上所有的数据库使用MySQL命令show create database choose;可以查看choose数据库的相关信息（例如MySQL版本ID号、默认字符集等信息）执行“use choose;”命令后，后续的MySQL命令以及SQL语句将自动操作choose数据库中所有数据库对象。删除student 数据库，使用SQL语句 drop database student 表是数据库中最为重要的数据库对象MyISAM和InnoDB存储引擎设置默认的存储引擎创建数据库表显示表结构表记录的管理 MySQL提供了插件式（Pluggable）的存储引擎，存储引擎是基于表的，同一个数据库，不同的表，存储引擎可以不同。甚至同一个数据库表，在不同的场合可以应用不同的存储引擎。 表记录的插入表记录的修改表记录的删除MySQL特殊字符序列 向数据库表插入记录时，可以使用insert语句向表中插入一条或者多条记录，也可以使用insert….select语句向表中插入另一个表的结果集。 本章详细讲解select语句检索表记录的方法， select语句概述使用where子句过滤结果集使用order by子句对结果集排序使用聚合函数汇总结果集使用group by子句对记录分组统计合并结果集子查询选课系统综合查询 使用正则表达式模糊查询全文检索 视图与表有很多相似的地方，视图也是由若干个字段以及若干条记录构成，视图也可以作为select语句的数据源。甚至在某些特定条件下，可以通过视图对表进行更新操作。视图中保存的仅仅是一条select语句，视图中的源数据都来自于数据库表，数据库表称为基本表或者基表，视图称为虚表。 1．使操作变得简单 2．避免数据冗余 3．增强数据安全性 4．提高数据的逻辑独立性 如果某个视图不再使用，可以使用drop view语句将该视图删除视图分为普通视图与检查视图。通过检查视图更新基表数据时，只有满足检查条件的更新语句才能成功执行
非关系型数据库大作业
实验三HBase环境搭建、sehll操作及Java API编程实验步骤： 1.搭建Zookeeper和HBase 1. 安装ntp服务端(master) # apt-get install ntp 启动ntp服务 # /etc/init.d/ntp start 修改配置文件 # vim /etc/ntp.conf 修改内容如下： 重启ntp服务 # /etc/init.d/ntp restart 1.2安装ntp客户端(slaver1、slaver2) 使用ntpdate命令，如果不存在这个命令，则先安装apt-get install ntp 同步服务器时间 # /usr/sbin/ntpdate 10.49.85.172 设置定时同步 # vim /etc/crontab
1.3 ulimit 和nproc设置(集群均配置) HBase是数据库，会在同一时间使用很多的文件句柄。大多数Ubuntu系统使用的默认值1024是不能满足的，所以你需要修改你的最大文件句柄限制。可以设置到10k. 你还需要修改hbase 用户的nproc，如果过低会造成OutOfMemoryError异常。 需要澄清的，这两个设置是针对操作系统的，不是Hbase本身的。有一个常见的错误是Hbase运行的用户，和设置最大值的用户不是一个用户。在Hbase 启动的时候，第一行日志会现在ulimit信息，所以你最好检查一下。 1）修改limits.conf文件 # vim /etc/security/limits.conf 添加如下内容： 2）修改common-session文件 # vim /etc/pam.d/common-session 添加如下内容： 重启系统 1.4 Zookeeper集群环境安装过程详解 1）解压zookeeper tar zxvf zookeeper-3.4.5.tar.gz 2）修改zoo.cfg配置文件 进入到zookeeper的conf目录下将zoo_sample.cfg文件拷贝一份，命名为为zoo.cfg vim zoo.cfg 修改内容如下：
关系数据库逻辑设计(一)
关系数据库逻辑设计(一) (总分：116.98，做题时间：90分钟) 一、选择题(总题数：37，分数：37.00) 1.数据库逻辑设计的依据不包括______。 A) 概念模型 B) 安全性要求 C) 数据约束 D) 功能模型 （分数：1.00） A. B. C. D. √ 解析：[解析] 数据库逻辑设计的依据是数据库概念设计的结果，包括概念数据模型、数据处理要求、数据约束、安全性要求及DBMS的相关信息，因此本题答案为D。 2.以下关于数据库逻辑设计叙述错误的是______。 A) 数据库逻辑设计是面向机器世界的 B) 这个阶段将按照数据库管理系统支持的数据模型来组织和存储数据 C) 目标是得到实际的数据库管理系统可处理的数据库模式，并做到数据结构合理 D) 包括定义和描述数据库的局部逻辑结构、数据之间的关系、数据完整性及安全性要求等 （分数：1.00） A. B. C. D. √ 解析：[解析] 数据库逻辑设计包括定义和描述数据库的全局逻辑结构、数据之间的关系、数据完整性及安全性要求等。因此本题答案为D。 3.在关系数据库设计中，设计关系模式是数据库设计中哪个阶段的任务______。 A) 逻辑设计阶段 B) 概念设计阶段 C) 物理设计阶段 D) 需求分析阶段 （分数：1.00） A. √ B. C. D. 解析：[解析] 关系数据模型是常用的逻辑数据模型，所以设计关系模式是数据库设计中逻辑设计阶段的任务，因此本题答案为A。 4.对于关系的主码必须满足的条件，有下列说法： Ⅰ．一个关系中的主码属性或属性组能函数决定该关系中的所有其他属性 Ⅱ．一个关系中的主码属性不能与其他关系中的主码属性重名 Ⅲ．在一个关系中，一个主码属性的任一真子集都不能函数决定其他属性
关系型数据库和非关系型数据库完整版
关系型数据库和非关系 型数据库 集团标准化办公室：[VV986T-J682P28-JP266L8-68PNN]
关系型数据库和非关系型数据库 自1970年，埃德加·科德提出关系模型之后，关系数据库便开始出现，经过了40多年的演化，如今的关系型数据库具备了强大的存储、维护、查询数据的能力。但在关系数据库日益强大的时候，人们发现，在这个信息爆炸的“大数据”时代，关系型数据库遇到了性能方面的瓶颈，面对一个表中上亿条的数据，SQL语句在大数据的查询方面效率欠佳。我们应该知道，往往添加了越多的约束的技术，在一定程度上定会拖延其效率。 在1998年，CarloStrozzi提出NOSQL的概念，指的是他开发的一个没有SQL功能，轻量级的，开源的关系型数据库。注意，这个定义跟我们现在对NoSQL的定义有很大的区别，它确确实实字如其名，指的就是“没有SQL”的数据库。但是NoSQL的发展慢慢偏离了初衷，CarloStrozzi也发觉，其实我们要的不是"nosql"，而应该是"norelational"，也就是我们现在常说的非关系型数据库了。 在关系型数据库中，导致性能欠佳的最主要因素是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。为了保证数据库的ACID特性，我们必须尽量按照其要求的范式进行设计，关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。 非关系型数据库提出另一种理念，他以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中，要对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询。但非关系型数据库由于很少的约束，他也不能够提供想SQL所提供的where这种对于字段属性值情况的查询。并且难以体现设计的完整性。他只适合存储一些较为简单的数据，对于需要进行较复杂查询的数据，SQL数据库显得更为合适。 目前出现的NoSQL(NotonlySQL，非关系型数据库)有不下于25种，除了Dynamo、Bigtable以外还有很多，比如Amazon的SimpleDB、微软公司的AzureTable、Facebook使用的Cassandra、类Bigtable的Hypertable、Hadoop的HBase、MongoDB、CouchDB、Redis以及Yahoo!的PNUTS等等。这些NoSQL各有特色，是基于不同应用场景而开发的，而其中以MongoDB和Redis最为被大家追捧。 以下是MongoDB的一些情况： MongoDB是基于文档的存储的（而非表），是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json 的bjson格式，因此可以存储比较复杂的数据类型。模式自由(schema-free)，意味着对于存储在MongoDB数据库中的文件，我们不需要知道它的任何结构定义。如果需要的话，你完全可以把不同结构的文件存储在同一个数据库里。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数 据库单表查询的绝大部分功能，而且还支持对数据建立索引。 Mongo主要解决的是海量数据的访问效率问题。因为Mongo主要是支持海量数据存储的，所以Mongo还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储。由于Mongo可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎。 关系型数据库的特点 1.关系型数据库
基于arcsde的空间数据库的设计与建立
基于ArcSDE的空间数据库的设计与建立 摘要：随着地理信息系统的发展，传统的以文件形式管理、存储地理空间数据的方式已不能满足现在应用的需求。针对以上问题，本文通过arcsde对空间数据进行管理，使空间数据和属性数据统一存储在面向对象的关系型数据库（sql server）中，实现统一、高效的管理。 关键词：空间数据库；属性数据；arcsde 围绕空间数据的管理，前后出现了几种不同的空间数据管理模式：纯文件模式、文件结合关系型数据库的管理模式、全关系型数据库管理模式和面向对象的数据库管理模式。前两种方式都是将空间数据和属性数据分离存储，这样往往会产生诸多问题：1.空间数据与属性数据的连接太弱，综合查询效率不高，容易造成空间数据与属性数据的脱节；2.空间数据与属性数据不能统一管理，实质上是两套管理系统，造成资源的浪费和管理的混乱，数据一致性较难维护；3.由于空间数据不能统一在标准数据库里存放，造成空间数据不能在网上共享。而面向对象数据库管理系统技术还不够成熟，并且价格昂贵，目前在gis领域还不够通用。所以在较长时间内，还不能完全脱离现有关系型数据库来建设gis空间数据库。arcsde是esri公司提供的一个基于关系型数据库基础上的地理数据库服务器。同一些数据库厂商推出的在原有数据库模型上进行空间数据模型扩展的产品（如oracle spatial）不同，esri的arcsde 的定位则是空间数据的管理及应用，而非简单的数据库空间化。
1.系统目标 建成一个多级比例尺(100万、25万、5万、1万)矢量、栅格以及航空影像、遥感影像(tm,spot)的c/s结构基础地理空间数据库,便于对空间数据有效的管理、分发和应用。 2.总体设计方案 系统总体技术方案设计在充分考虑实际应用环境及应用需求的 基础上,结合考虑国际国内发展的主流趋势和平台产品的功能与性能来完成。 2.1技术路线 空间数据库建设应放弃数据文件式的管理方式,采用大型关系数据库管理系统(sql server)管理空间数据，arcsde作为sql server 2008和arc/info或其他地理信息系统软件的接口, vb/vc/delphi/java/c#为前端应用开发工具。其中，空间数据通过arcsde存储在sql server 2008数据库。arcsde是基于c/s计算模型和关系数据管理模式的一个连续的空间数据模型，借助这一模型,可将空间数据加入到数据库管理系统(rdbms)中去[1]。arcsde 融于rdmbs后,提供了对空间、非空间数据进行高效率操作的数据接口。由于arcsde采用c/s体系结构，大量用户可同时针对同一数据进行操作。arcsde提供了应用程序接口(api)，开发人员可将空间数据检索和分析功能集成到应用工程中去，以完成前端的应用开发,最终提供数据的存储、查询和分发服务。如图1所示： 图1结构图
关系数据库设计
目录 一 Codd的RDBMS12法则——RDBMS的起源 二关系型数据库设计阶段 三设计原则 四命名规则 数据库设计，一个软件项目成功的基石。很多从业人员都认为，数据库设计其实不那么重要。现实中的情景也相当雷同，开发人员的数量是数据库设计人员的数倍。多数人使用数据库中的一部分，所以也会把数据库设计想的如此简单。其实不然，数据库设计也是门学问。 从笔者的经历看来，笔者更赞成在项目早期由开发者进行数据库设计（后期调优需要DBA）。根据笔者的项目经验，一个精通OOP和ORM的开发者，设计的数据库往往更为合理，更能适应需求的变化，如果追其原因，笔者个人猜测是因为数据库的规范化，与OO的部分思想雷同（如内聚）。而DBA，设计的数据库的优势是能将DBMS的能力发挥到极致，能够使用SQL和DBMS实现很多程序实现的逻辑，与开发者相比，DBA优化过的数据库更为高效和稳定。如标题所示，本文旨在分享一名开发者的数据库设计经验，并不涉及复杂的SQL语句或DBMS使用，因此也不会局限到某种DBMS产品上。真切地希望这篇文章对开发者能有所帮助，也希望读者能帮助笔者查漏补缺。 一?Codd的RDBMS12法则——RDBMS的起源 Edgar Frank Codd（埃德加·弗兰克·科德）被誉为“关系数据库之父”，并因为在数据库管理系统的理论和实践方面的杰出贡献于1981年获图灵奖。在1985年，Codd 博士发布了12条规则，这些规则简明的定义出一个关系型数据库的理念，它们被作为所有关系数据库系统的设计指导性方针。 1.信息法则?关系数据库中的所有信息都用唯一的一种方式表示——表中的值。 2.保证访问法则?依靠表名、主键值和列名的组合，保证能访问每个数据项。 3.空值的系统化处理?支持空值（NULL），以系统化的方式处理空值，空值不依赖于数据类型。 4.基于关系模型的动态联机目录?数据库的描述应该是自描述的，在逻辑级别上和普通数据采用同样 的表示方式，即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用 户可以访问的表中。 5.统一的数据子语言法则?一个关系数据库系统可以支持几种语言和多种终端使用方式，但必须至少 有一种语言，它的语句能够一某种定义良好的语法表示为字符串，并能全面地支持以下所有规 则：数据定义、视图定义、数据操作、约束、授权以及事务。（这种语言就是SQL) 6.视图更新法则?所有理论上可以更新的视图也可以由系统更新。 7.高级的插入、更新和删除操作?把一个基础关系或派生关系作为单个操作对象处理的能力不仅适应 于数据的检索，还适用于数据的插入、修改个删除，即在插入、修改和删除操作中数据行被视 作集合。 8.数据的物理独立性?不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动都 保持着逻辑上的不变性。 9.数据的逻辑独立性?当对表做了理论上不会损害信息的改变时，应用程序和终端活动都会保持逻辑 上的不变性。 10.数据完整性的独立性?专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定 义，而且可以存储在数据目录中，而非程序中。
关系型数据库和范式理论设计及实体模型
一，关系型数据库 关系型数据库，是指采用了关系模型来组织数据的数据库。 简单来说，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。 关系模型中常用的概念： ?关系：可以理解为一张二维表，每个关系都具有一个关系名，就是通常说的表名?元组：可以理解为二维表中的一行，在数据库中经常被称为记录 ?属性：可以理解为二维表中的一列，在数据库中经常被称为字段 ?域：属性的取值范围，也就是数据库中某一列的取值限制 ?关键字：一组可以唯一标识元组的属性，数据库中常称为主键，由一个或多个列组成 ?关系模式：指对关系的描述。其格式为：关系名(属性1，属性2， ... ... ，属性N)，在数据库中成为表结构 关系型数据库的优点： ?容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解 ?使用方便：通用的SQL语言使得操作关系型数据库非常方便 ?易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率 二,范式，英文名称是 Normal Form，它是英国人 E.F.Codd（关系数据库的老祖宗）在上个世纪70年代提出关系数据库模型后总结出来的，范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法，以下就是对这三个范式的基本介绍： 第一范式（1NF）： 数据表中的每一列(字段)，必须是不可拆分的最小单元，也就是确保每一列的原子性。
通俗解释：一个字段只存储一项信息 例如： userInfo: '山东省烟台市 1318162008' 依照第一范式必须拆分成: userInfo: '山东省烟台市' userTel: '1318162008'两个字段 第二范式（2NF）： 满足1NF后要求表中的所有列，都必需依赖于主键，而不能有任何一列与主键没有关系（一个表只描述一件事情）。 通俗解释：任意一个字段都只依赖表中的同一个字段 例如： 订单表只能描述订单相关的信息，所以所有的字段都必须与订单ID相关。 产品表只能描述产品相关的信息，所以所有的字段都必须与产品ID相关。 因此在同一张表中不能同时出现订单信息与产品信息。 第三范式（3NF）：第三范式(3NF)：满足2NF后，要求：表中的每一列都要与主键直接相关，而不是间接相关（表中的每一列只能依赖于主键） 例如：订单表中需要有客户相关信息，在分离出客户表之后，订单表中只需要有一个用户ID即可，而不能有其他的客户信息，因为其他的用户信息是直接关联于用户ID，而不是关联于订单ID。 注意事项： 1.第二范式与第三范式的本质区别：在于有没有分出两张表。 第二范式是说一张表中包含了多种不同实体的属性，那么必须要分成多张表，第三范式是要求已经分好了多张表的话，一张表中只能有另一张标的ID，而不能有其他任何信息，（其他任何信息，一律用主键在另一张表中查询）。 2.必须先满足第一范式才能满足第二范式，必须同时满足第一第二范式才能满足第三范式。
人口分布空间数据库设计书
人口分布空间数据库设计书 1）概念设计 概念设计是通过对错综复杂的现实世界的认识与抽象，最终形成空间数据库系统及其应用系统所需的模型。 具体是对需求分析阶段所收集的信息和数据进行分析、整理，确定地理实体、属性及它们之间的联系，将各用户的局部视图合并成一个总的全局视图，形成独立于计算机的反映用户观点的概念模式。概念模式与具体的DBMS无关，结构稳定，能较好地反映用户的信息需求。 表示概念模型最有力的工具是E-R模型，即实体-联系模型，包括实体、联系和属性三个基本成分。用它来描述现实地理世界，不必考虑信息的存储结构、存取路径及存取效率等与计算机有关的问题，比一般的数据模型更接近于现实地理世界，具有直观、自然、语义较丰富等特点。 本设计书中的E-R模型如图1所示： 图1 E-R模型 2）逻辑设计 在概念设计的基础上，按照不同的转换规则将概念模型转换为具体DBMS支持
的数据模型的过程，即导出具体DBMS可处理的地理数据库的逻辑结构(或外模式)，包括确定数据项、记录及记录间的联系、安全性、完整性和一致性约束等。导出的逻辑结构是否与概念模式一致，能否满足用户要求，还要对其功能和性能进行评价，并予以优化。 2.1要素分类 我们制作、统计的地理信息数据应该提供准确、可靠、经得起专业部门检验的地理信息，这就要求测绘部门和相关专业部门应该有一致的地理要素的定义和分类体系。依据GB/T 13923-2006《基础地理信息要素分类与编码》将地理要素分为了地位基础、水系、居民地及设施、交通、管线、境界与政区、地貌、植被 2.2 数据层设计 GIS的数据可以按照空间数据的逻辑关系或专业属性分为各种逻辑数据层或 专业数据层，原理上类似于图片的叠置。在进行空间分析、数据处理、图形显示时，往往只需要若干相应图层的数据。 数据层的设计一般是按照数据的专业内容和类型进行的。数据的专业内容的类型通常是数据分层的主要依据，同时也要考虑数据之间的关系。如需考虑两类物体共享边界(道路与行政边界重合、河流与地块边界的重合)等，这些数据间的关系在数据分层设计时应体现出来。不同类型的数据由于其应用功能相同，在分析和应用时往往会同时用到，因此在设计时应反映出这样的需求，即可将这些数据作为一层。 本设计书中的数据层设计如表2所示： 表2 数据层设计 2.3关系数据表 本设计书中的关系数据表如表3-表6所示：
关系型数据库与非关系型数据库的选择
自1970年，埃德加·科德提出关系模型之后，关系数据库便开始出现，经过了40多年的演化，如今的关系型数据库具备了强大的存储、维护、查询数据的能力。但在关系数据库日益强大的时候，人们发现，在这个信息爆炸的“大数据”时代，关系型数据库遇到了性能方面的瓶颈，面对一个表中上亿条的数据，SQL语句在大数据的查询方面效率欠佳。我们应该知道，往往添加了越多的约束的技术，在一定程度上定会拖延其效率。 在1998年，Carlo Strozzi提出NOSQL的概念，指的是他开发的一个没有SQL功能，轻量级的，开源的关系型数据库。注意，这个定义跟我们现在对NoSQL的定义有很大的区别，它确确实实字如其名，指的就是“没有SQL”的数据库。但是NoSQL的发展慢慢偏离了初衷，CarloStrozzi也发觉，其实我们要的不是"nosql"，而应该是"norelational"，也就是我们现在常说的非关系型数据库了。 在关系型数据库中，导致性能欠佳的最主要因素是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。为了保证数据库的ACID特性，我们必须尽量按照其要求的范式进行设计，关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。 非关系型数据库提出另一种理念，他以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中，要对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询。但非关系型数据库由于很少的约束，他也不能够提供想SQL所提供的where这种对于字段属性值情况的查询。并且难以体现设计的完整性。他只适合存储一些较为简单的数据，对于需要进行较复杂查询的数据，SQL数据库显得更为合适。 目前出现的NoSQL(Not only SQL，非关系型数据库)有不下于25种，除了Dynamo、Bigtable以外还有很多，比如Amazon的SimpleDB、微软公司的AzureTable、Facebook 使用的Cassandra、类Bigtable的Hypertable、Hadoop的HBase、MongoDB、CouchDB、Redis以及Yahoo!的PNUTS等等。这些NoSQL各有特色，是基于不同应用场景而开发的，而其中以MongoDB和Redis最为被大家追捧。 以下是MongoDB的一些情况： MongoDB是基于文档的存储的（而非表），是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型。模式自由(schema-free)，意味着对于存储在MongoDB数据库中的文件，我们不需要知道它的任何结构定义。如果需要的话，你完全可以把不同结构的文件存储在同一个数据库里。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数
简析关系型数据库系统的设计方法
简析关系型数据库系统的设计方法 1系统总体设计 面向关系数据库的关键字查询系统主要有五部分组成，首先要分析输入的关键字，有几个关键字组成;然后调用全文索引，查看这些关键字所属，是表名、属性名还是属性值;接下来查询数据库的模式图，从而得到几种可能的元组连接树;最后将相应元组连接树转化成SQ L 语句查询关系数据库，生成查询结果，以二维表格形式显示。 2数据库设计 本系统为面向关系数据库的关键字查询系统，在实验中本文选取了M D B数据集，为了进行实验，将数据集整理为以下七个表数据结构。实验数据集(电影信息数据库):Actor(演员表),Consume(设计师),Director(导演信息),Busness股资),Edito r(编辑),Color(颜色信息),Keyw ord(关键词)。 3数据库索引设计 在关系型数据库中，例如0 racl,DB2,SQ L Server和M ySQ L等都提供了对关键字查询的扩展，可以为数据库的表属性建立全文索引，这为实现关系数据库的关键字查询提供了基础。已有多个关系数据库的关键字查询系统被开发出来，BANKS ,D ISCO VER,IR-style,SEKKER 等等。然而在已有的系统中，多数系统仅仅支持数据库中文本属性的查询，却忽略了对数据库中元数据的处理。如果用户给定的查询关键字是数据库中的元数据，则有些系统就不能够满足用户的查询需求，
或者查询结果不够精确，返回大量与查询不相关的结果。SEKKER虽然提出了支持数字属性和元数据的查询，但是却在查询语言上做了限定，只能通过给定的查询语言格式进行查询，所以系统的灵活性不高。 4数据库模式图的构建 在关系数据库中，关键字是通过主外键进行连接的，因此关系数据库采用的数据模型，即为基于模式图建模。模式图的节点对应数据库中的关系，边表示关系间的主外键约束。 模式图(Schem a Graph,GS)是将关系数据库的模式信息定义为模式图GS(V,E)，其中V表示模式图中的节点，与数据库中的关系一一对应，E表示模式图中的边，将具有主外码约束相对应的关系连接起来，关系R;和关系R中的主外键关系对应模式图一条边R -R， 本文数据库对应的数据库模式图如图 3所示。 5关键字检索设计 关键字检索技术主要是，通过分析用户输入的关键字所属类型来确定元组连接树，从而转换成相应的SQ L语句来查询关系数据库。如果用户输入的关键字都是表名，则将几个表自然连接后输出即可;若用户输入的关键字有表名、属性名，那么将属性列加到表中输出就是用户所检索的内容;若用户输入的关键字中有属性值，则将属性值对应属性与表或属性列连接，根据属性值对应元组来显示查询结果。由此可见，对于相同的关键字，如果它不止一种所属值，那么它就会对应不同的SQ L语句。
关系型大数据库和非关系型大数据库
关系型数据库和非关系型数据库 自1970年，埃德加·科德提出关系模型之后，关系数据库便开始出现，经过了40多年的演化，如今的关系型数据库具备了强大的存储、维护、查询数据的能力。但在关系数据库日益强大的时候，人们发现，在这个信息爆炸的“大数据”时代，关系型数据库遇到了性能方面的瓶颈，面对一个表中上亿条的数据，SQL语句在大数据的查询方面效率欠佳。我们应该知道，往往添加了越多的约束的技术，在一定程度上定会拖延其效率。 在1998年，Carlo Strozzi提出NOSQL的概念，指的是他开发的一个没有SQL功能，轻量级的，开源的关系型数据库。注意，这个定义跟我们现在对NoSQL的定义有很大的区别，它确确实实字如其名，指的就是“没有SQL”的数据库。但是NoSQL的发展慢慢偏离了初衷，CarloStrozzi也发觉，其实我们要的不是"nosql"，而应该是"norelational"，也就是我们现在常说的非关系型数据库了。 在关系型数据库中，导致性能欠佳的最主要因素是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。为了保证数据库的ACID特性，我们必须尽量按照其要求的范式进行设计，关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。 非关系型数据库提出另一种理念，他以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中，要对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询。但非关系型数据库由于很少的约束，他也不能够提供想SQL所提供的where这种对于字段属性值情况的查询。并且难以体现设计的完整性。他只适合存储一些较为简单的数据，对于需要进行较复杂查询的数据，SQL数据库显得更为合适。 目前出现的NoSQL(Not only SQL，非关系型数据库)有不下于25种，除了Dynamo、Bigtable以外还有很多，比如Amazon的SimpleDB、微软公司的AzureTable、Facebook使用的Cassandra、类Bigtable的Hypertable、Hadoop的HBase、MongoDB、CouchDB、Redis以及Yahoo!的PNUTS等等。这些NoSQL各有特色，是基于不同应用场景而开发的，而其中以MongoDB和Redis最为被大家追捧。 以下是MongoDB的一些情况： MongoDB是基于文档的存储的（而非表），是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型。模式自由(schema-free)，意味着对于存储在MongoDB数据库中的文件，我们不需要知道它的任何结构定义。如果需要的话，你完全可以把不同结构的文件存储在同一个数据库里。Mongo最大的特点是他支持的查询语言非常强大，
关系型和非关系型数据库的区别
关系型和非关系型数据库的区别 当前主流的关系型数据库有Oracle、DB2、Microsoft SQL Server、M icrosoft Access、MySQL等。 非关系型数据库有NoSql、Cloudant。 nosql和关系型数据库比较？ 优点： 1）成本：nosql数据库简单易部署，基本都是开源软件，不需要像使用oracle那样花费大量成本购买使用，相比关系型数据库价格便宜。 2）查询速度：nosql数据库将数据存储于缓存之中，关系型数据库将数据存储在硬盘中，自然查询速度远不及nosql数据库。 3）存储数据的格式：nosql的存储格式是key,value形式、文档形式、图片形式等等，所以可以存储基础类型以及对象或者是集合等各种格式，而数据库则只支持基础类型。 4）扩展性：关系型数据库有类似join这样的多表查询机制的限制导致扩展很艰难。 缺点： 1）维护的工具和资料有限，因为nosql是属于新的技术，不能和关系型数据库10几年的技术同日而语。 2）不提供对sql的支持，如果不支持sql这样的工业标准，将产生一定用户的学习和使用成本。
3）不提供关系型数据库对事物的处理。 非关系型数据库的优势：1. 性能NOSQL是基于键值对的，可以想象成表中的主键和值的对应关系，而且不需要经过SQL层的解析，所以性能非常高。2. 可扩展性同样也是因为基于键值对，数据之间没有耦合性，所以非常容易水平扩展。 关系型数据库的优势：1. 复杂查询可以用SQL语句方便的在一个表以及多个表之间做非常复杂的数据查询。2. 事务支持使得对于安全性能很高的数据访问要求得以实现。对于这两类数据库，对方的优势就是自己的弱势，反之亦然。 关系型数据库把所有的数据都通过行和列的二元表现形式表示出来。 关系型数据库的优势： 1. 保持数据的一致性（事务处理） 2.由于以标准化为前提，数据更新的开销很小（相同的字段基本上都只有一处） 3. 可以进行Join等复杂查询
数据库设计各阶段word版本
数据库设计各阶段
1.数据库应用系统的设计步骤 按规范设计的方法可将数据库设计分为以下六个阶段 （1）需求分析; （2）概念结构设计; （3）逻辑结构设计; （4）数据库物理设计; （5）数据库实施; （6）数据库运行和维护。 2.需求分析 需求收集和分析是数据库应用系统设计的第一阶段。明确地把它作为数据库应用系统设计的第一步是十分重要的。这一阶段收集到的基础数据和一组数据流图（Data Flow Diaˉgram———DFD）是下一步设计概念结构的基础。概念结构对整个数据库设计具有深刻影响。而要设计好概念结构，就必须在需求分析阶段用系统的观点来考虑问题、收集和分析数据及其处理。如何分析和表达用户需求呢？在众多的分析方法中，结构化分析（Structured Analysis，简称SA方法）是一个简单实用的方法。SA方法用自顶向下、逐层分解的方式分析系统。用数据流图，数据字典描述系统。然后把一个处理功能的具体内容分解为若干子功能，每个子功能继续分解，直到把系统的工作过程表达清楚为止。在
处理功能逐步分解的同时，它们所用的数据也逐级分解。形成若干层次的数据流图。数据流图表达了数据和处理过程的关系。处理过程的处理逻辑常常用判定表或判定树来描述。数据字典（Data Dictionary，简称DD）则是对系统中数据的详尽描述，是各类数据属性的清单。对数据库应用系统设计来讲，数据字典是进行详细的数据收集和数据分析所获得的主要结果。数据字典是各类数据描述的集合，它通常包括以下5个部分： （1）数据项，是数据最小单位。 （2）数据结构，是若干数据项有意义的集合。 （3）数据流，可以是数据项，也可以是数据结构。表示某一处理过程的输入输出。 （4）数据存储，处理过程中存取的数据。常常是手工凭证、手工文档或计算机文件。 （5）处理过程。 3.概念结构设计 如同软件工程中重视需求分析与规范说明的思想一样，数据库设计中同样十分重视数据分析、抽象与概念结构的设计。概念结构的设计，是整个数据库设计的关键之一。概念结构独立于数据库逻辑结构，独立于支持数据库的DBMS，也独立于具体计算机软件和硬件系统。归纳总结，其主要特点是：
关系数据库与非关系数据库
关系数据库与非关系数据库 摘要：关系数据库，是建立在关系模型基础上的数据库，是借助于在数学概念和方法来处理数据库中的数据。在现实世界中，各种实体以及他们之间的各种联系均用关系模型来表示。关系模型由关系数据结构、关系操作集合、关系完整性约束三部分组成，集中表现在数据的模型发展上。从最初的层次结构、网状模型结构发展到今天的关系数据库模型，数据库发生了飞速的变化，在变化的过程中，关系模型的出现，是数据库在发展路程中的一座重要的里程碑，关系理论研究和关系型数据库管理系统研究的成功，进一步促进了关系数据库的发展。使得关系型数据模型成为具有统治地位的数据模型。 关键词：数据库；关系模型；关系数据库 通俗地说，关系型数据库就是采用了关系模型来组织数据的数据库。简单来说，关系模型就是一个类似于二维表格的模型，而关系型数据库就是由二维表格及其中含有的数据所组成的一个数据组织。在关系数据库中，有些名词需要我们了解： 关系：通俗地说，在一张二维表格中，每个关系都具有一个关系名，就是通常说的表名table。 属性：在二维表格中也就是类似于excel表格中的一列，在数据库中被称为字段。 域：属性的取值范围，也就是数据库中某一字段的属性限制条件。 关键字：一组可以唯一标识元组的属性。数据库中常称为主键，由一个或多个列组成。 关系模式：指对关系的描述，其格式为：关系名（属性1，属性2，…，属性N）。也就是数据库中的表结构。 随着数据库应用领域的扩展以及数据对象的多样化，传统的关系数据模型暴露出了许多问题，如对复杂对象的表述能力差，表达能力较弱。为此，人们提出了许多新的数据模型，下面
笔者向大家介绍一下以前的数据库的主要特点：数据不保存、系统没有专用的软件对数据进行管理、数据不共享、数据不具有独立性。 在文件系统层面上，数据可以以文件的形式进行长期保存，数据交由文件系统管理数，独立的机制使得程序与数据之间具有一定的独立性但在这个结构中，数据的独立性、共享性差，冗余度大、易造成数据传输之间的不一致性。 在数据库系统层面上，数据可以结构化，数据之间的共享性提高，冗余度小，一个用户可以拥有多个数据库，因此数据独立性高，数据控制功能也变得统一起来。其中大可分为4类： 第一类，数据安全性控制；第二类，数据完整性控制；第三类，数据的并发控制；第四类，数据管理与恢复。 数据结构化，在数据库系统中，将数据按照一定的数据模型插入到一个结构化的数据库中，需要考虑此数据库的数据结构，还需要考虑连接数据后的数据结构，而在以前的数据库中，这些，是我们看不到的。下面，笔者将就几个方面对其进行分析： 非关系型数据库的实质：非关系型数据库产品是传统关系型数据库的缩略版本，通过减少功能，来大幅度提升产品性能，类似于我们平时游戏中的资料篇。 目前市场上流通的大部分主流的非关系型数据库基本上都是免费的。而大公司中，名气大的关系型数据库开发软件，比如Oracle、DB2是收费的。这在很大程度上限制了一些平民用户的使用。但是在实际开发中，有很多小型的业务需求，并不需要完整的关系型数据库进行组建，非关系型数据库的功能就足够了。这种情况下，使用性能高、成本低的非关系型数据库当然是我们的首选。在性能上NOSQL是基于键值对的，可以理解成类似于Java中和HashMap 中的键值对，数据表中的主键和值也具有相同对应关系，但在使用过程中是不需要经过SQL 层的解析，所以性能非常高是它的主要优点。同样，它也具有良好的可扩展性，这也是基于键值对，数据之间存在相当低的耦合度，所以在使用的时候非常容易扩展。 在SQL语言中，关系型数据库对其也具有独特的解读优势：在复杂查询语句中，可以用SQL语句根据表连接、嵌套、子句等方法方便地在一个表或多个表之间做复杂的数据查询，且代码的冗余性很低，这也使得数据库对于安全性能要求很高的数据得以访问，对于非关系型数据库，就没有这些优点。
GIS空间数据库设计方法讨论
第31卷总第77期 西北民族大学学报(自然科学版)Vol.31,No.1 2010年3月 Journal of N orthw est U niversity for N ationalities(Natural Science)Sep,2010 GIS空间数据库设计方法讨论 薛国梁 (西北民族大学人事处,甘肃兰州730030) [摘 要]通过分析地理信息系统建设过程中空间数据库的建设内容1综述空间数据块的划分、图层的分层设计方法、专题图层划分和数据集设计、分析空间数据库的结构,讨论了空间数据库系统建设的方法和需解决的关键技术问题1 [关键词]GIS;空间数据库;专题图层;元数据 [中图分类号]TP311.131 [文献标识码]A [文章编号]1009-2102(2010)01-0049-04 0 引言 地理信息系统是集计算机科学、空间科学、信息科学、测绘遥感科学、环境科学等学科于一体的新兴边缘科学1GIS从20世纪60年代出现以来,至今只有短短的40多年时间,但已成为已成为多学科集成并应用于各领域的基础平台,成为地学空间信息分析的基本手段和工具1目前,地理信息系统不仅发展成为一门较为成熟的技术科学,而且已成为一门新兴产业,在测绘、地质、水利、环境检测、土地管理、城市规划、国防建设等领域发挥越来越重要的作用1 1 空间数据库内容 每个GIS数据集都提供了对世界某一方面的空间表达,包括: 基于矢量的要素(点、线和多边形)的有序集合; 诸如数字高程模型和影像的栅格数据集; 网络; 地形和其他地表; 测量数据集; 其他类型数据,诸如地址、地名和制图信息; 描述性的属性1 除了地理表现形式以外,地理数据集还包括传统的描述地理对象的属性表1许多表和空间对象之间可以通过它们所共有的字段(也常称为“关键字”)相互关联1就像它们在传统数据库应用中一样,这些以表的形式存在的信息集和信息关系在GIS数据模型中扮演着非常关键的角色1 2 空间数据表现形式 211 空间关系:拓扑和网络 空间关系,比如拓扑和网络,也是一个GIS数据库的重要部分1使用拓扑是为了管理要素间的共同边界、定义和维护数据的一致性法则,以及支持拓扑查询和漫游(如确定要素的邻接性和连接性)1 [收稿日期]2009-12-10 [作者简介]薛国梁(1980—),男,陕西韩城市人,党政管理研究实习员,主要从事高教管理工作1