NoSQL(Not only SQL)是对不同于传统的关系数据库的数据库管理系统的统称,即广义地来说可以把所有不是关系型数据库的数据库统称为NoSQL。
NoSQL 数据库专门构建用于特定的数据模型,并且具有灵活的架构来构建现代应用程序。NoSQL 数据库使用各种数据模型来访问和管理数据。这些类型的数据库专门针对需要大数据量、低延迟和灵活数据模型的应用程序进行了优化,这是通过放宽其他数据库的某些数据一致性限制来实现的。
数十年来,用于应用程序开发的主要数据模型是由关系数据库(如 Oracle、DB2、SQL Server、MySQL 和 PostgreSQL)使用的关系数据模型。直到 21 世纪中后期,才开始大规模采用和使用其他数据模型。为了对这些新类别的数据库和数据模型进行区分和分类,创造了术语“NoSQL”。通常术语“NoSQL”与“非关系”可互换使用。
键值:键值数据库是一种非关系数据库,它使用简单的键值方法来存储数据。键值数据库将数据存储为键值对集合,其中键作为唯一标识符。通常只能通过引用键来检索值,因此学习如何查询特定键值对通常很简单。键值数据库非常适合需要存储大量数据但无需执行复杂查询来检索数据的使用案例。常见的使用案例包括存储用户首选项或缓存。Redis 和 DynanoDB 是流行的键值数据库。
键和值都可以是从简单对象到复杂复合对象的任何内容。键值数据库是高度可分区的,并且允许以其他类型的数据库无法实现的规模进行水平扩展。例如Amazon DynamoDB,如果现有分区填满了容量,并且需要更多的存储空间,Amazon DynamoDB就会将额外的分区分配给表。诸如游戏、广告技术和 IoT 等使用案例本身特别适合键值数据模型。
内存:游戏和广告技术应用程序具有排行榜、会话存储和实时分析等使用案例,它们需要微秒响应时间并且可能随时出现大规模的流量高峰。
文档:文档数据库是一种非关系数据库,例如MongoDB。文档数据库将数据存储在类似于 JSON(JavaScript 对象表示法)对象的文档中。每个文档包含成对的字段和值。这些值通常可以是各种类型,包括字符串、数字、布尔值、数组或对象等,并且它们的结构通常与开发者在代码中使用的对象保持一致。由于字段值类型和强大的查询语言的多样性,因此文档数据库非常适合各种各样的使用案例,并且可以用作通用数据库。它们可以横向扩展以适应大量数据。
文档数据库让开发人员可以使用他们在其应用程序代码中使用的相同文档模型格式,更轻松地在数据库中存储和查询数据。文档和文档数据库的灵活、半结构化和层级性质允许它们随应用程序的需求而变化。文档模型可以很好地与目录、用户配置文件和内容管理系统等使用案例配合使用,其中每个文档都是唯一的,并会随时间而变化。文档数据库支持灵活的索引、强大的临时查询和文档集合分析。
图形:图形数据库旨在轻松构建和运行与高度连接的数据集一起使用的应用程序。图形数据库的典型使用案例包括社交网络、推荐引擎、欺诈检测和知识图形。热门图形数据库包括 Neo4j 和 Giraph。 图形数据库专门用于存储和导航关系。关系是图形数据库中的一等公民,图形数据库的大部分价值都源自于这些关系。图形数据库使用节点来存储数据实体,并使用边缘来存储实体之间的关系。边缘始终有一个开始节点、结束节点、类型和方向,并且边缘可以描述父子关系、操作、所有权等。一个节点可以拥有的关系的数量和类型没有限制。
图形数据库中的图形可依据具体的边缘类型进行遍历,或者也可对整个图形进行遍历。在图形数据库中,遍历联结或关系非常快,因为节点之间的关系不是在查询时计算的,而是留存在数据库中。在社交网络、推荐引擎和欺诈检测等使用案例中,您需要在数据之间创建关系并快速查询这些关系,此时,图形数据库更具优势。
搜索:许多应用程序输出日志以帮助开发人员解决问题。搜索引擎数据库是一种非关系数据库,专用于数据内容的搜索。搜索引擎数据库使用索引对数据之间的相似特征进行分类,并增强搜索功能。搜索引擎数据库经过优化,可处理可能是长数据,半结构数据或非结构数据的数据,并且它们通常提供专门的方法,例如全文搜索,复杂的搜索表达式和搜索结果排名。
MongoDB 是由C++语言编写的基于分布式文件存储的开源数据库系统(document database),是文档数据库。MongoDB数据库中的记录称为文档(document),是一种由字段和值(field and value)成对组成的key-value键值型数据结构,格式上和常用的json格式类似,字段的值可以包括其他文档,数组和文档数组。
{
name: "sue",
age: 26,
status: "A",
groups: ["news","sports"]
}
使用文档的主要优势在于可以支持许多编程语言的原生数据类型,避免不必要的join操作以及动态的schema模式可以流畅地支持多态类型。MongoDB将文档存储到集合(collections)中,集合与关系型数据库中的数据表类似。除了最主要的文档特性外,MongoDB还具有以下特性:
MongoDB提供了高性能的数据持久化存储功能,主要是
MongoDB提供了丰富的查询语句用于支持CRUD等操作,除了常规的查询语句还支持如:Data Aggregation(数据聚合)、Text Search 、 Geospatial Queries和mapping等操作
MongoDB的复制工具(称为副本集 )提供自动故障转移和数据冗余功能。副本集是一组维护相同数据集的MongoDB服务器,可提供冗余并提高数据可用性
MongoDB的核心功能之一就是提供水平扩展能力。
MongoDB支持多种存储引擎,如WiredTiger和In-Memory 。此外,MongoDB还提供了存储引擎的API插件供第三方开发者开发存储引擎。
适用于需要动态查询支持;需要使用索引而不是 map/reduce功能;需要对大数据库有性能要求;需要使用 CouchDB但因为数据改变太频繁而占满内存的应用程序。
Redis是一个基于BSD开源协议的,内存中的数据结构存储系统,可以用于数据库、缓存和消息中间件。
它支持多种类型的数据结构,如 字符串(strings), 散列(hashes), 列表(lists), 集合(sets), 有序集合(sorted sets) 与范围查询, bitmaps, hyperloglogs 和 地理空间(geospatial) 索引半径查询。 Redis 内置了复制(replication),LUA脚本(Lua scripting), LRU驱动事件(LRU eviction),事务(transactions) 和不同级别的数据持久化(persistence), 并通过 Redis哨兵(Sentinel)和redis集群的自动分区提供高可用性。
适用于数据变化快且数据库大小可预见(适合内存容量)的应用程序。
例如:股票价格、数据分析、实时数据搜集、实时通讯。
ER图也称实体-联系图(Entity Relationship Diagram),提供了表示实体类型、属性和联系的方法,用来描述现实世界的概念模型。
通俗来说就是,当我们理解了实际问题的需求之后,需要用一种方法来表示这种需求,概念模型就是用来描述这种需求。
比如学生生活中的校园卡系统数据库、公交卡系统数据库等等,都离不开实体关系图。
ER 图由实体、属性和联系三个基本要素组成。
实际问题中客观存在的并且可以相互区别的事物称为实体。实体是现实世界中的对象,可以具体到人,事,物,比如学生、办公室、食堂、超市。也可以是抽象的,比如毕业论文的选题。
实体所具有的某一个特性称为属性,在E-R图中属性用来描述实体。比如下图中的学生,可以用“姓名”、“院系”、“班级”、“手机号”进行属性描述。
世界上任何事物都不是孤立存在的,事物内部和事物之间都有联系的,实体之间的联系通常有3种类型:一对一联系,一对多联系,多对多联系。
具有相同属性的实体的集合称为实体集。例如:全体学生就是一个实体集,(983573,李刚,男,2000/12/12)是学生实体集中的一个实体。
在描述实体集的所有属性中,可以唯一标识每个实体的属性称为键。键也是属于实体的属性,作为键的属性取值必须唯一且不能为“空”。比如:不重复的学生号,就可以作为学生的“键”。
具有相同的特征和性质的实体一定有相同的属性,用实体名及其属性名集合来抽象和刻画同类实体称为实体型,其表示格式为:实体名(属性1,属性2,……)
在ER图中有如下四个成分:
1)矩形框:表示实体,在框中记入实体名。
2)菱形框:表示联系,在框中记入联系名。
3)椭圆形框:表示实体或联系的属性,将属性名记入框中。对于主属性名,则在其名称下划一下划线。
4)连线:实体与属性之间;实体与联系之间;联系与属性之间用直线相连,并在直线上标注联系的类型。(对于一对一联系,要在两个实体连线方向各写1; 对于一对多联系,要在一的一方写1,多的一方写N;对于多对多关系,则要在两个实体连线方向各写N,M。)
E-R图的绘制步骤,大致可以分为以下5步:
统一建模语言(Unified Modeling Language,UML)是一种为面向对象系统的产品进行说明、可视化和编制文档的一种标准语言,是非专利的第三代建模和规约语言。UML是面向对象设计的建模工具,独立于任何具体程序设计语言。
UML有很多种,但大体分为两类:结构型的UML 和 行为型的UML
类图是面向对象系统建模中最常用和最重要的图,是定义其它图的基础。
类图主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型。
类图中最基本的元素是类、接口。软件设计师设计出类图后,程序员就可以用代码实现类图中包含的内容。
UML类图中具体类、抽象类、接口和包有不同的表示方法。
具体类在类图中用矩形框表示,矩形框分为三层:第一层是类名字。第二层是类的成员变量;第三层是类的方法。成员变量以及方法前的访问修饰符用符号来表示:
比如下图Hourly这个类,里面有两个私有属性hourlyRate和hoursWorked,所以他们前面用的是“-”号,还有一个公共函数computePay,在UML类图中前面使用“+”号表示
抽象类在UML类图中同样用矩形框表示,但是抽象类的类名以及抽象方法的名字都用斜体字表示,如下图所示。首先抽象类的名称Employee使用斜体,还有抽象函数computePay同样使用斜体表示,而其他的则不需要使用斜体
接口在类图中也是用矩形框表示,但是与类的表示法不同的是,接口在类图中的第一层顶端用构造型 << interface >>表示,下面是接口的名字,第二层是方法,如下图所示。
此外,接口还有另一种表示法,俗称棒棒糖表示法,就是类上面的一根棒棒糖(圆圈+实线)。圆圈旁为接口名称,接口方法在实现类中出现。如下图所示,唐老鸭这个类使用了讲人话这个接口,接口的方法(下图中是讲话)将在唐老鸭这个实现类中实现。
类和接口一般都出现在包中,UML类图中包的表示形式如下图所示。
类和类、类和接口、接口和接口之间存在一定关系,UML类图中一般会有连线指明它们之间的关系。关系共有六种类型,分别是实现关系、泛化关系、关联关系、依赖关系、聚合关系、组合关系,如下图所示。
实现关系是指接口及其实现类之间的关系。在UML类图中,实现关系用空心三角和虚线组成的箭头来表示,从实现类指向接口,如下图所示。在Java代码中,实现关系可以直接翻译为关键字 implements
泛化关系(Generalization)是指对象与对象之间的继承关系。如果对象A和对象B之间的“is a”关系成立,那么二者之间就存在继承关系,对象B是父对象,对象A是子对象。例如,一个年薪制员工“is a”员工,很显然年薪制员工Salary对象和员工Employee对象之间存在继承关系,Employee对象是父对象,Salary对象是子对象。
在UML类图中,泛化关系用空心三角和实线组成的箭头表示,从子类指向父类,如下图所示。在Java代码中,对象之间的泛化关系可以直接翻译为关键字 extends
关联关系(Association)是指对象和对象之间的连接,它使一个对象知道另一个对象的属性和方法。在Java中,关联关系的代码表现形式为一个对象含有另一个对象的引用。也就是说,如果一个对象的类代码中,包含有另一个对象的引用,那么这两个对象之间就是关联关系。
关联关系有单向关联和双向关联。如果两个对象都知道(即可以调用)对方的公共属性和操作,那么二者就是双向关联。如果只有一个对象知道(即可以调用)另一个对象的公共属性和操作,那么就是单向关联。大多数关联都是单向关联,单向关联关系更容易建立和维护,有助于寻找可重用的类。
在UML图中,双向关联关系用带双箭头的实线或者无箭头的实线双线表示。 单向关联用一个带箭头的实线表示,箭头指向被关联的对象,如下图所示。这就是导航性(Navigatity)
一个对象可以持有其它对象的数组或者集合。在UML中,通过放置多重性(multipicity)表达式在关联线的末端来表示。多重性表达式可以是一个数字、一段范围或者是它们的组合。多重性允许的表达式示例如下:
关联关系又分为依赖关联、聚合关联和组合关联三种类型。
依赖(Dependency)关系是一种弱关联关系。如果对象A用到对象B,但是和B的关系不是太明显的时候,就可以把这种关系看作是依赖关系。如果对象A依赖于对象B,则 A “use a” B。比如驾驶员和汽车的关系,驾驶员使用汽车,二者之间就是依赖关系。
在UML类图中,依赖关系用一个带虚线的箭头表示,由使用方指向被使用方,表示使用方对象持有被使用方对象的引用,如下图所示。
依赖关系在Java中的具体代码表现形式为B为A的构造器或方法中的局部变量、方法或构造器的参数、方法的返回值,或者A调用B的静态方法。
下面我们用代码清单1和代码清单2所示的Java代码来演示对象和对象之间的依赖关系。
B类定义了一个成员变量 field1,一个普通方法 method1() 和一个静态方法 method2()。
public class B {
public String field1; //成员变量
public void method1() {
System.println("在类B的方法1中");
}
public static void method2() { //静态方法
System.out.println("在类B的静态方法2中");
}
}
下面所示的A类依赖于B类,在A类中定义了四个方法,分别演示四种依赖形式。
public class A {
public void method1() {
//A依赖于B的第一种表现形式:B为A的局部变量
B b = new B();
b.method1();
}
public void method2() {
//A依赖于B的第二种表现形式: 调用B的静态方法
B.method2();
}
public void method3(B b) {
//A依赖于B的第三种表现形式:B作为A的方法参数
String s = b.field1;
}
//A依赖于B的第四种表现形式:B作为A的方法的返回值
public B method4() {
return new B();
}
}
聚合(Aggregation)是关联关系的一种特例,它体现的是整体与部分的拥有关系,即 “has a” 的关系。此时整体与部分之间是可分离的,它们可以具有各自的生命周期,部分可以属于多个整体对象,也可以为多个整体对象共享,所以聚合关系也常称为共享关系。例如,公司部门与员工的关系,一个员工可以属于多个部门,一个部门撤消了,员工可以转到其它部门。
在UML图中,聚合关系用空心菱形加实线箭头表示,空心菱形在整体一方,箭头指向部分一方,如下图所示。
组合(Composition)也是关联关系的一种特例,它同样体现整体与部分间的包含关系,即 “contains a” 的关系。但此时整体与部分是不可分的,部分也不能给其它整体共享,作为整体的对象负责部分的对象的生命周期。这种关系比聚合更强,也称为强聚合。如果A组合B,则A需要知道B的生存周期,即可能A负责生成或者释放B,或者A通过某种途径知道B的生成和释放。
例如,人包含头、躯干、四肢,它们的生命周期一致。当人出生时,头、躯干、四肢同时诞生。当人死亡时,作为人体组成部分的头、躯干、四肢同时死亡。
在UML图中,组合关系用实心菱形加实线箭头表示,实心菱形在整体一方,箭头指向部分一方,如下图所示。
在Java代码形式上,聚合和组合关系中的部分对象是整体对象的一个成员变量。但是,在实际应用开发时,两个对象之间的关系到底是聚合还是组合,有时候很难区别。在Java中,仅从类代码本身是区分不了聚合和组合的。如果一定要区分,那么如果在删除整体对象的时候,必须删掉部分对象,那么就是组合关系,否则可能就是聚合关系。从业务角度上来看,如果作为整体的对象必须要部分对象的参与,才能完成自己的职责,那么二者之间就是组合关系,否则就是聚合关系。
例如,汽车与轮胎,汽车作为整体,轮胎作为部分。如果用在二手车销售业务环境下,二者之间就是聚合关系。因为轮胎作为汽车的一个组成部分,它和汽车可以分别生产以后装配起来使用,但汽车可以换新轮胎,轮胎也可以卸下来给其它汽车使用。如果用在驾驶系统业务环境上,汽车如果没有轮胎,就无法完成行驶任务,二者之间就是一个组合关系。再比如网上书店业务中的订单和订单项之间的关系,如果订单没有订单项,也就无法完成订单的业务,所以二者之间是组合关系。而购物车和商品之间的关系,因为商品的生命周期并不被购物车控制,商品可以被多个购物车共享,因此,二者之间是聚合关系。