数据库管理系统的选择原则

选择数据库管理系统时应从以下几个方面予以考虑：

(1) 构造数据库的难易程度。

需要分析数据库管理系统有没有范式的要求，即是否必须按照系统所规定的数据模型分析现实世界，建立相应的模型；数据库管理语句是否符合国际标准，符合国际标准则便于系统的维护、开发、移植；有没有面向用户的易用的开发工具；所支持的数据库容量，数据库的容量特性决定了数据库管理系统的使用范围。

(2) 程序开发的难易程度。

有无计算机辅助软件工程工具CASE——计算机辅助软件工程工具可以帮助开发者根据软件工程的方法提供各开发阶段的维护、编码环境，便于复杂软件的开发、维护。有无第四代语言的开发平台——第四代语言具有非过程语言的设计方法，用户不需编写复杂的过程性代码，易学、易懂、易维护。有无面向对象的设计平台——面向对象的设计思想十分接近人类的逻辑思维方式，便于开发和维护。对多媒体数据类型的支持——多媒体数据需求是今后发展的趋势，支持多媒体数据类型的数据库管理系统必将减少应用程序的开发和维护工作。

(3)数据库管理系统的性能分析。

包括性能评估（响应时间、数据单位时间吞吐量）、性能监控（内外存使用情况、系统输入/输出速率、SQL语句的执行，数据库元组控制）、性能管理（参数设定与调整）。

(4) 对分布式应用的支持。

包括数据透明与网络透明程度。数据透明是指用户在应用中不需指出数据在网络中的什么节点上，数据库管理系统可以自动搜索网络，提取所需数据；网络透明是指用户在应用中无需指出网络所采用的协议。数据库管理系统自动将数据包转换成相应的协议数据。

(5)并行处理能力。

支持多CPU模式的系统（SMP，CLUSTER，MPP），负载的分配形式，并行处理的颗粒度、范围。

(6) 可移植性和可扩展性。

可移植性指垂直扩展和水平扩展能力。垂直扩展要求新平台能够支持低版本的平台，数据库客户机/服务器机制支持集中式管理模式，这样保证用户以前的投资和系统；水平扩展要求满足硬件上的扩展，支持从单CPU模式转换成多CPU并行机模式（ SMP, CLUSTER, MPP）

(7)数据完整性约束。

数据完整性指数据的正确性和一致性保护，包括实体完整性、参照完整性、复杂的事务规则。

(8)并发控制功能。

对于分布式数据库管理系统，并发控制功能是必不可少的。因为它面临的是多任务分布环境，可能会有多个用户点在同一时刻对同一数据进行读或写 *** 作，为了保证数据的一致性，需要由数据库管理系统的并发控制功能来完成。评价并发控制的标准应从下面几方面加以考虑：

保证查询结果一致性方法

数据锁的颗粒度（数据锁的控制范围，表、页、元组等）

数据锁的升级管理功能

(9) 容错能力。

异常情况下对数据的容错处理。评价标准：硬件的容错，有无磁盘镜象处理功能软件的容错，有无软件方法　(10) 安全性控制

包括安全保密的程度（帐户管理、用户权限、网络安全控制、数据约束）

(11) 支持多种文字处理能力

包括数据库描述语言的多种文字处理能力（表名、域名、数据）和数据库开发工具对多种文字的支持能力。

（12）数据恢复的能力

当突然停电、出现硬件故障、软件失效、病毒或严重错误 *** 作时，系统应提供恢复数据库的功能，如定期转存、恢复备份、回滚等，使系统有能力将数据库恢复到损坏以前的状态。

用到的数据库：access,mysql,sqlserver,oracle；

其中access,mysql较小型数据库，sqlserver,oracle为大型数据库；

连接Access数据库

1由于Access数据库没有官方的专用JDBC驱动程序，所以必须将Access数据库连接到ODBC，再通过JDBC-ODBC连接桥连接到ODBC来访问数据库。

2首先要为指定的Access数据库设置ODBC数据源，具体步骤如下：

控制面板->管理工具->数据源(ODBC)

添加->选择数据源的驱动程序（选择Access驱动）->点击完成->填写具体属性

3使用代码加载JDBC-ODBC的驱动程序，并且连接（Connection）上指定的Access数据库，建立语句（Statement），然后由语句对数据库进行创建表格、新增、修改等 *** 作，最后返回结果（ResultSet）并打印。（代码略）

链接MySQL数据库方法：

1、显示密码

如：MySQL 连接远程数据库（1921685116），端口“3306”，用户名为“root”，密码“123456”

C:/>mysql -h 1921685116 -P 3306 -u root -p123456

2、隐藏密码

如：MySQL 连接本地数据库，用户名为“root”，

C:/>mysql -h localhost -u root -p 

Enter password:

群集方法介乎两种计算机系统结构之间。当把多台计算机配置或互连在一起时，可采取松散耦合或紧密耦合结构。网络就是一个松散耦合的系统，我们也称其为异类系统结构。网络把由各种CPU、应用软件、NIC（网络接口控制器）、甚至是 *** 作系统组成的多台计算机连接在一起。计算机之间的地理距离可以近在咫尺，也可以远在天边。可以用实时和/或异步方式耦合网络。

因特网就是一个典型的极为松散与异类配置的例子。因特网本身不能“实时”控制与它连接的任何主机。在松散耦合网络中，单机崩溃一般不会影响网络的其它部分。

相反，紧密耦合系统则高度依赖于构成系统的所有部件。当系统由相同部件组成，采用并行 *** 作方式并共享所有子系统（存储器）时，我们称其为同类系统结构。紧密耦合系统最常见的例子是SMP（对称多处理）。在SMP状态下，根据工作量的多少把任务分给几台处理器，这样可均匀地分配工作量，以便提高数据吞吐量。

我们举了两个典型的松散和紧密耦合系统的例子，群集就介于松散和紧密耦合系统之间。根据系统的配置，在某些方面（比如 *** 作系统），群集控制的系统也许更偏向紧密耦合的系统，或者偏向松散耦合的系统（比如独立计算能力，通过公共存储器连接）。

通常群集器放在同一设备区或同一办公楼里。从理论上说，群集控制方法可应用于闭路广域网环境中（现正在美国东北部地区进行试验）。可是在考虑到视频服务器应用时，一般来说只能把设备放在主要设施运行所在地。

公共数据共享

群集允许共享几个节点的数据。在此应用中，这些节点包括客户工作站、中央或多服务器。我们知道可以通过许多路径（比如星形结构）连接节点，客户可通过不同连接的节点路径存取数据。当节点就是服务器时便可共享公共存储器，某个服务器节点故障不会导致整个群集器系统瘫痪。

在12月专栏里，我们把群集描述成一个提供高可得性的系统。对广播或有线电视 *** 作来说，视频服务器必须要提供连续的或高可得性的数据。考虑到这一点，我们认为视频服务器体系结构采用群集是大有潜力的。

待命或无源服务器结构就是一种群集形式。在这种结构下，一个或多个服务器（或节点）平时保持在待命状态，随时可以启动。利用后台控制系统管理待命服务器内容数据。在未发生故障之前一般不启用无源服务器。

无源服务器未必就是主服务器的完全镜像，它也可以有一些有限的数据源，包括存储器，要经常清除这些数据，然后重新装入最新的节目或广告。通过这一循环过程把适量的数据（或视频媒介）保持在待命状态，在需要时随时可以上线使用。

服务器在待命状态时通常由少量的部件组成，比如编解码器，在出现故障或另一个服务器需要它支持的时候，该服务器可立即被集成到系统中应用。此时，服务器进入负载均衡状态。

数据共享

数据共享是群集器需要提供的最基本功能之一。我们还是以视频服务器的应用为例，多个编辑站在这里独立地工作，不过利用一组公共服务器来管理数据和应用层的处理。

在这个例子中，多个新闻编辑站（或客户工作站）可以选择用哪个编辑服务器（包括编辑用的软件和硬件）来进行编辑。这些服务器控制对公共媒体数据库的存取，编辑站只是这些服务器的简单控制器GUI（图形用户界面）。编辑服务器进一步控制接入另一个更大的数据存储库（通常是新闻档案）。

这个概念可通过群集软件实现。在独立的编辑站通过群集器存取数据的过程中，编辑与数据存取或存储处理自动进行，不会影响其它的客户编辑站或预放站。通过提供连续的数据可得性，每个服务器可以是有源的，也可以是无源的，视工作负荷而定。假如有一个服务器发生了故障，该结构也可提供冗余或保护方式。

共享一个 *** 作系统和平台是群集的又一个共同特点。让硬件与软件平台同属一类，也就是说，基本上是相同的，就可采用公用互连方案与公共文件格式结构。在SMP这样的系统中，所有部件都依赖于公用硬件而像单独部件一样运行。正如我们已提到的，群集可以让一部分系统保持同类结构，但脱离所有系统都有的依赖性，其它性能就会下降。

其它优点

我们现在还是回到基于群集服务器的编辑环境中来，我们又发现了其它一些优点。服务器硬件具有的冗余性可对数据起保护作用。在新闻编辑环境中，当即将播放时，一个或更多的服务器便可将客户工作站的功能变成播出功能，直接把新闻播出去。这样还能让所有客户和服务器接入别的服务器的数据，包括在最后一分钟直接存取中央存储库的数据。

通过使用多个服务器（每个服务器收集、编辑、存档和重放的资源是一个类型的），系统便可对硬件进行备份。在某个服务器出现故障时，可把资源转给或分给其它用户，系统的其余部分仍继续工作。

除了上述的数据共享外，其它群集器结构也是可行的。在有些情况下，某些资源可被一个特定的节点“拥有”，在未接到指令前不会放弃。可将该系统的结构配置成一个节点有多个输入编码器，但只有一个输出解码器。另一个节点可能没有输入，但有好几个输出供放像和预看用。如果某一个节点出现故障，可让与它相对应的节点顶替它，直到它被修复为止。

非共享结构

从硬件上说，每个节点的能力（或资源）基本上相同，但内部系统配置是用各种形式锁定的，除非另有要求。按照群集语言可把此结构

叫做非共享结构。在此结构里，某些资源在未被传送给其它节点或者该节点未出故障之前归一个节点所有。在采用非共享结构的计算机与模式里运用群集法通常会把硬盘等设备分配给一个节点，并阻止其他人使用它，除非将其开放或该节点发生故障。

群集结构的其它实施方面增加了系统的复杂程度。除了非共享结构外（只提供最简单的性能和可得性），还有磁盘共享结构。磁盘共享可提高存储接入不同主机系统的能力。

从硬件的角度看，系统的磁盘阵列控制器可以很容易地管理这个共享结构。比较难办的是在最低级别（文件或记录层）上协调更新数据。

协调工作必须成为群集软件的一部分。可以设想一下，如果两个用户同时接入同一记录层会发生什么情况。假定每个用户都修改了文件。用户1先把数据写入服务器，他发现用户2做了完全不同的修改并且把修改后的文件用同一文件名存入相同的磁盘，或许存在另一个服务器上，这样就有可能把第一个用户修改的文件冲掉。没有一个控制方案，就会乱成一团。

尽管每个文件或记录层都有简单的口令或锁定保护，但要确保用文件的正确版本存成另一个文件名或是“正式”版，则要求具有更高层的数据控制与管理能力。磁盘快速缓存问题又是另一种情形，我们等一会儿再说。

另一个防止错误数据覆盖正确数据的方法是在修改未最后定之前限制接入某一特定文件。在计算机数据域中，用一个称为信息传送的程序通知管理员（通常是应用后台软件的一部分）文件存取被锁定，直到修改程序结束为止。

原子 *** 作

原子 *** 作的三个步骤是：读数据、修改数据、然后重新写入新数据。在原子 *** 作过程中，在未执行完 *** 作之前不会受到任何干扰。还必须有其他保护措施，以防隐藏的备份文件在以后某个无法预测的时间改写其它的文件。

当数据分布在不止一个存储磁盘上时，或者当公共存储阵列中的数据被不同用户在不同时间存取时，如何防止数据不一致是群集软件需要解决的又一个问题。无论是通过硅缓存器还是通过远程接入的临时磁盘缓存器（甚至分区）进行高速缓存都会遇到定时和同步的问题。我们把这个问题叫做缓存相关性，它是因磁盘驱动器定时问题引起的。

磁盘驱动器并不一定能马上写入数据，磁头也许定位在错误的磁道上，导轮也许偏离相位190度，等结束运转后才能开始磁头的写入 *** 作，或许还因为温度问题造成暂时性延缓，直到一切都符合条件为止。

这通常被称为等待时间，磁盘驱动器的机械部分要求在驱动器等待写入时暂存一下数据。最常见的方法是在驱动器上安一个硅缓存器，这个过程被叫做写回高速缓存。在把主机储存器中的数据转存到磁盘驱动器的过程中，设一个写回缓存器标识，对数据源表示写入程序成功了。实际上，得过一会儿才能开始真正的电磁机械式的数据储存过程。

假如系统上的另一个节点也从这个驱动器读数据，（这是经过许可的 *** 作，因为数据发生器已接到通知，新数据已发送到了这个位置），那么缓存器已在指定位置存储了正确新数据的指示信号就不见了。我们用失效数据一词来表示未更新数据进入新数据区的状态。

无效数据

RAID控制器在各自磁盘阵列的写回缓存器里为与这个特殊的阵列有关的磁盘管理失效数据。假如在软件里设一些适当的开关来检测和阻止它发生，那么数据相关性就只是一个小问题了。

当系统是由多层阵列构成的时候，控制失效数据问题的任务就交给高级别软件去完成，把信号传送给各自的阵列，就不会发生孤立或失效数据问题了。

在这个简化的单一视频服务器模型里，媒体是通过单编码器输入的，并存在一个单实体阵列上。由一个更高级别（通常是第三方API，应用程序接口）登记和管理活动图像数据。通常将其作为任选的“媒体管理”或“资产管理器”包出售。通过这个软件，控制活动图像和数据的过程成为一个闭路过程，因为输入与输出指令必须通过这个管理软件包。该软件在自己的数据库里始终跟踪着数据的有效性。

如果有好几个服务器，每个服务器有自己的任务，情况就变得比较复杂了。这时可以让几个信号源的输入进入不同的编码器，并存在一个较大的磁盘阵列里。这些阵列通常与光纤通道仲裁环相连，由于它的连接方式决定，它可迫使部分重写动作由服务器推迟到存储器，直到有了充足的带宽来把该数据从这个存储器存入另一个存储器。

在类似的应用中，媒体管理软件就更完善，更必不可少了。有时候制造商会提供一个完全独立的CPU和资源管理软件包（作为选件）。这个软件包就像看门狗那样管理服务器之间的数据共享 *** 作。除了这些基本概念外，还有大量的定时和数据验证问题，这些问题会经常在服务器结构的软件与子系统中碰到。

群集的过程和功能正在扩展到设备内和设备间应用中。群集器理念最终将允许整个广播集团通过光纤或通过广域网共享资源。虽然可以让设施连成网共享媒介，可是在这些设施相互离得很远的情况下实现节点资源共享的设想似乎还很遥远。

以上就是关于数据库管理系统的选择原则全部的内容，包括:数据库管理系统的选择原则、o2o电子商务用什么后台数据库，怎么连接后台数据库、java 集群等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！