多级用户系统的数据库应该怎么设计

主要从几个不同方面设计ORACLE数据库优化方案：一数据库优化自由结构OFA(Optimal flexible Architecture)二、充分利用系统全局区域SGA（SYSTEM GLOBAL AREA)三、数据库设计中的优化策略数据应当按两种类别进行组织：频繁访问的数据和频繁修改的数据。对于频繁访问但是不频繁修改的数据，内部设计应当物理不规范化。对于频繁修改但并不频繁访问的数据，内部设计应当物理规范化。四、合理设计和管理表1、利用表分区分区将数据在物理上分隔开，不同分区的数据可以制定保存在处于不同磁盘上的数据文件里。2、避免出现行连接和行迁移3、控制碎片4、别名的使用别名是大型数据库的应用技巧，就是表名、列名在查询中以一个字母为别名，查询速度要比建连接表快15倍。5、回滚段的交替使用五、索引Index的优化设计1、管理组织索引索引可以大大加快数据库的查询速度，索引把表中的逻辑值映射到安全的RowID，因此索引能进行快速定位数据的物理地址。六、多CPU和并行查询PQO(Parallel Query Option)方式的利用七、实施系统资源管理分配计划ORACLE 提供了Database Resource Manager（DRM,数据库资源管理器）来控制用户的资源分配，DBA可以用它分配用户类和作业类的系统资源百分比。在一个OLDP系统中，可给联机用户分配75%的CPU资源，剩下的25%留给批用户。另外，还可以进行CPU的多级分配。除了进行CPU资源分配外，DRM还可以对资源用户组执行并行 *** 作的限制。八、使用最优的数据库连接和SQL优化方案九、充分利用数据的后台处理方案减少网络流量1、合理创建临时表或视图2、数据库打包技术的充分利用利用数据库描述语言编写数据库的过程或函数，然后把过程或函数打成包在数据库后台统一运行包即可。3、数据复制、快照、视图，远程过程调用技术的运用

这个题目太大了。

换个问法：设计数据库管理系统需要准备哪些？

（1）做业务需求分析。按照数据库开发的思路，确定系统的功能和模块。完成诸如数据字典等方面的工作。统称为系统需求分析。

（2）选择前台开发语言或环境、选择后台数据库,考虑好是否要进行移植

（3)开发阶段的人员

（4）测试阶段的人员

（5）验收，试运行

（6）维护阶段的人员。

数据库因不同的应用要求会有各种各样的组织形式。数据库的设计就是根据不同的应用目的和用户要求，在一个给定的应用环境中，确定最优的数据模型、处理模式、存贮结构、存取方法，建立能反映现实世界的地理实体间信息之间的联系，满足用户要求，又能被一定的DBMS接受，同时能实现系统目标并有效地存取、管理数据的数据库。简言之，数据库设计就是把现实世界中一定范围内存在着的应用数据抽象成一个数据库的具体结构的过程。

空间数据库的设计是指在现在数据库管理系统的基础上建立空间数据库的整个过程。主要包括需求分析、结构设计、和数据层设计三部分。

1、需求分析

需求分析是整个空间数据库设计与建立的基础，主要进行以下工作：

1）调查用户需求：

了解用户特点和要求，取得设计者与用户对需求的一致看法。

2）需求数据的收集和分析：

包括信息需求(信息内容、特征、需要存储的数据)、信息加工处理要求(如响应时间)、完整性与安全性要求等。

3）编制用户需求说明书：

包括需求分析的目标、任务、具体需求说明、系统功能与性能、运行环境等，是需求分析的最终成果。

需求分析是一项技术性很强的工作，应该由有经验的专业技术人员完成，同时用户的积极参与也是十分重要的。

在需求分析阶段完成数据源的选择和对各种数据集的评价

2、结构设计

指空间数据结构设计，结果是得到一个合理的空间数据模型，是空间数据库设计的关键。空间数据模型越能反映现实世界，在此基础上生成的应用系统就越能较好地满足用户对数据处理的要求。

空间数据库设计的实质是将地理空间实体以一定的组织形式在数据库系统中加以表达的过程，也就是地理信息系统中空间实体的模型化问题。

1）概念设计

概念设计是通过对错综复杂的现实世界的认识与抽象，最终形成空间数据库系统及其应用系统所需的模型。

具体是对需求分析阶段所收集的信息和数据进行分析、整理，确定地理实体、属性及它们之间的联系，将各用户的局部视图合并成一个总的全局视图，形成独立于计算机的反映用户观点的概念模式。概念模式与具体的DBMS无关，结构稳定，能较好地反映用户的信息需求。

表示概念模型最有力的工具是E-R模型，即实体-联系模型，包括实体、联系和属性三个基本成分。用它来描述现实地理世界，不必考虑信息的存储结构、存取路径及存取效率等与计算机有关的问题，比一般的数据模型更接近于现实地理世界，具有直观、自然、语义较丰富等特点，在地理数据库设计中得到了广泛应用。

2）逻辑设计

在概念设计的基础上，按照不同的转换规则将概念模型转换为具体DBMS支持的数据模型的过程，即导出具体DBMS可处理的地理数据库的逻辑结构(或外模式)，包括确定数据项、记录及记录间的联系、安全性、完整性和一致性约束等。导出的逻辑结构是否与概念模式一致，能否满足用户要求，还要对其功能和性能进行评价，并予以优化。

从E—R模型向关系模型转换的主要过程为：

①确定各实体的主关键字；

②确定并写出实体内部属性之间的数据关系表达式，即某一数据项决定另外的数据项；

③把经过消冗处理的数据关系表达式中的实体作为相应的主关键字

④根据②、③形成新的关系。

⑤完成转换后，进行分析、评价和优化。

3)物理设计

物理设计是指有效地将空间数据库的逻辑结构在物理存储器上实现，确定数据在介质上的物理存储结构，其结果是导出地理数据库的存储模式(内模式)。主要内容包括确定记录存储格式，选择文件存储结构，决定存取路径，分配存储空间。

物理设计的好坏将对地理数据库的性能影响很大，一个好的物理存储结构必须满足两个条件：一是地理数据占有较小的存储空间；二是对数据库的 *** 作具有尽可能高的处理速度。在完成物理设计后，要进行性能分析和测试。

数据的物理表示分两类：数值数据和字符数据。数值数据可用十进制或二进制形式表示。通常二进制形式所占用的存贮空间较少。字符数据可以用字符串的方式表示，有时也可利用代码值的存贮代替字符串的存储。为了节约存贮空间，常常采用数据压缩技术。

物理设计在很大程度上与选用的数据库管理系统有关。设计中应根据需要，选用系统所提供的功能。

4)数据层设计

大多数GIS都将数据按逻辑类型分成不同的数据层进行组织。数据层是GIS中的一个重要概念。GIS的数据可以按照空间数据的逻辑关系或专业属性分为各种逻辑数据层或专业数据层，原理上类似于的叠置。例如，地形图数据可分为地貌、水系、道路、植被、控制点、居民地等诸层分别存贮。将各层叠加起来就合成了地形图的数据。在进行空间分析、数据处理、图形显示时，往往只需要若干相应图层的数据。

数据层的设计一般是按照数据的专业内容和类型进行的。数据的专业内容的类型通常是数据分层的主要依据，同时也要考虑数据之间的关系。如需考虑两类物体共享边界(道路与行政边界重合、河流与地块边界的重合)等，这些数据间的关系在数据分层设计时应体现出来。

不同类型的数据由于其应用功能相同，在分析和应用时往往会同时用到，因此在设计时应反映出这样的需求，即可将这些数据作为一层。例如，多边形的湖泊、水库，线状的河流、沟渠，点状的井、泉等，在GIS的运用中往往同时用到，因此，可作为一个数据层。

5)数据字典设计

数据字典用于描述数据库的整体结构、数据内容和定义等。 数据字典的内容包括： 1）数据库的总体组织结构、 数据库总体设计的框架 。　 2）各数据层详细内容的定义及结构、 数据命名的定义 。　 3）元数据（有关数据的数据，是对一个数据集的内容、质量条件及 *** 作过程等的描述） 。

可以采用四种技术：

动态增加数据库表字段

预留足够的空白字段，运行时作动态影射

用xml格式保存在单字段里

改列为行，用另外一个表存放定制字段

一

现在我们来分析一下四种技术的优劣，不过首先可以排除的是第一点动态增加字段的方法，因为在实际 *** 作时候几乎是不可能的（sqlserver太慢，oracle索性不支持），基本可以不讨论就排除。剩下后三点。

二

先来讨论预留空白字段的方法，基本原理就是在数据库表设计的时候加入一些多余的字段，看下面的代码：

CREATE TABLE Sample(

name varchar(12),

field0 varchar(1),

field1 varchar(1),

fieldN varchar(1)

}

然后看实际运行时候的需要，动态分配字段给系统使用，也许需要一个这样的结构来描述分配情况：

public class Available

{

public int CurrentUnusedFieldNumber;

public Hashtable FieldToRealName;

}

也许某一时刻的数据状况是这样的： CurrentUnusedFieldNumber=3,

哈西表FieldToRealName包含内容是("field0"="SomeId", "field1"="AnyName",

"field2=IsOk")

现在的问题是如果要配合Hibernate，如何来处理？以上段的数据使用状况为例子，如果我们的类定义是这样：

public class Entity01

{

public string Name;

public string SomeId;

public string AnyName;

public bool IsOk;

}

也许只需要修改一下xxxhbmxml，把 SomeId 和 field0

做成对应就ok了。但是在运行时我们怎么知道会有这样的类定义？除非我们做动态代码生成，自动编译也许可以，但是问题也许就到其他方面去了；如果我们不用动态定义，那么类就只能是这样：

public class Entity01

{

public string Name;

public Hashtable ExtraFieldAndValues;

}

使用的时候，用 entity01ExtraFieldAndValuessetValue("AnyName", "boss")

的方式来引用，也许这样是修改最少的了，但是问题是Hibernate不支持这样的方法。

三

再来讨论单字段存储的方法，我们使用这样的数据库表定义

CREATE TABLE Sample

(

Name varchar(12),

Xml CLOB(102400) // 仅作说明而已

)

然后对应这样的类定义

public class Entity01

{

public string Name;

public string Xml;

public Hashtable ExtraNameAndValueFromXml;

}

我们的代码就可以这样使用：string id =

entity01ExtraNameAndValueFromXmlgetValue("SomeId")

了。这样解决看起来很不错，不仅不需要Available表，而且看起来Hibernate对它的支持也很完美，但是致命的问题在于：如果保持高效的查询？除非数据库系统本身对此有支持，否则就只能用低效的substring或者like做查询，这在大批量数据中根本就不可行。

是不是折衷一下，把两种方法的优点和起来？问题有来了：怎么保持两者之间数据的同步？难道要我们用存储过程去解析xml内容？

所以，一个两难的问题，需要我们认真去解决。我们通过认真的需求分析，也许可以减少可变字段的数量，但是只要有一个可变字段或者可变的可能性存在，我们始终要去解决这个两难的问题。

期待继续讨论。

四

还有一种方法就是改列为行，用另外一个表存放扩展字段，定义可以如下：

CREATE

TABLE SampleFields

(

idSample Integer,

fieldName varchar(30),

fieldValue varchar(100)

)

其中idSample关联到Sample表的id字段（我没有写出来）。这样的话，Hibernate很容易支持，也可以支持Sql的查询，而且可以支持把内容放到Hashtable中去，看起来是目前最好的方式了。但是在大容量数据的时候，SampleFields表的数据会是主表数据量的N倍（看定制的字段数目多少而定），同样存在有很严重的性能问题。

超大型系统的特点为：1、处理的用户数一般都超过百万，有的还超过千万，数据库的数据量一般超过1TB;2、系统必须提供实时响应功能，系统需不停机运行，要求系统有很高的可用性及可扩展性。为了能达到以上要求，除了需要性能优越的计算机和海量存储设备外，还需要先进的数据库结构设计和优化的应用系统。一般的超大型系统采用双机或多机集群系统。下面以数据库采用Oracle 806并行服务器为例来谈谈超大型数据库设计方法：确定系统的ORACLE并行服务器应用划分策略数据库物理结构的设计系统硬盘的划分及分配备份及恢复策略的考虑二、Oracle并行服务器应用划分策略Oracle并行服务器允许不同节点上的多个INSTANCE实例同时访问一个数据库，以提高系统的可用性、可扩展性及性能。Oracle并行服务器中的每个INSTANCE实例都可将共享数据库中的表或索引的数据块读入本地的缓冲区中，这就意味着一个数据块可存在于多个INSTANCE实例的SGA区中。那么保持这些缓冲区的数据的一致性就很重要。Oracle使用 PCM( Parallel Cache Management)锁维护缓冲区的一致性，Oracle同时通过I DLM(集成的分布式锁管理器)实现PCM 锁,并通过专门的LCK进程实现INSTANCE实例间的数据一致。考虑这种情况：INSTANCE1对BLOCK X块修改，这时INSTANCE2对BLOCK X块也需要修改。Oracle并行服务器利用PCM锁机制，使BLOCK X从INSTANCE 1的SGA区写入数据库数据文件中，又从数据文件中把BLOCK X块读入INSTANCE2的SGA区中。发生这种情况即为一个PING。PING使原来1个MEMORY IO可以完成的工作变成2个DISK IO和1个 MEMORY IO才能够完成,如果系统中有过多的PING，将大大降低系统的性能。Oracle并行服务器中的每个PCM锁可管理多个数据块。PCM锁管理的数据块的个数与分配给一个数据文件的PCM锁的个数及该数据文件的大小有关。当INSTANCE 1和INSTANCE 2要 *** 作不同的BLOCK，如果这些BLOCK 是由同一个PCM锁管理的,仍然会发生PING。这些PING称为FALSE PING。当多个INSTANCE访问相同的BLOCK而产生的PING是TRUE PING。合理的应用划分使不同的应用访问不同的数据，可避免或减少TRUE PING;通过给FALSE PING较多的数据文件分配更多的PCM锁可减少 FALSE PING的次数，增加PCM锁不能减少TRUE PING。所以，Oracle并行服务器设计的目的是使系统交易处理合理的分布在INSTANCE实例间，以最小化PING，同时合理的分配PCM锁，减少FALSE PING。设计的关键是找出可能产生的冲突，从而决定应用划分的策略。应用划分有如下四种方法：1、根据功能模块划分，不同的节点运行不同的应用2、根据用户划分，不同类型的用户运行在不同的节点上3、根据数据划分，不同的节点访问不同的数据或索引4、根据时间划分，不同的应用在不同的时间段运行应用划分的两个重要原则是使PING最小化及使各节点的负载大致均衡。三、数据库物理结构的设计数据库物理结构设计包括确定表及索引的物理存储参数，确定及分配数据库表空间，确定初始的回滚段，临时表空间，redo log files等，并确定主要的初始化参数。物理设计的目的是提高系统的性能。整个物理设计的参数可以根据实际运行情况作调整。表及索引数据量估算及物理存储参数的设置表及索引的存储容量估算是根据其记录长度及估算的最大记录数确定的。在容量计算中考虑了数据块的头开销及记录和字段的头开销等等。

可以帮你简要的分析下，有不准的地方希望谅解

通过读题你能分析出大概的几个表

1车间表 （车间编号，车间名称，车间主任编号，备注）

2员工表（编号，姓名，工种，职位编号，年龄，性别，电话，地址）

3职位表（编号，职位名称）

4产品表（编号，产品名称，价格，车间编号，备注）

5零件表（零件号，重量，价格）

6车间-零件表（车间编号，零件号）车间编号和零件号做联合主键

7产品-零件表（产品编号，零件号）产品编号和零件号做联合主键

8仓库表（编号，管理员姓名，电话）

9零件-仓库表（仓库编号（主键），零件编号）

10产品-仓库表（仓库编号（主键），产品编号）

1国家/地区，2省/直辖市，3市，4区/县，5街巷道，6门牌号/楼层/房室

上述设计是6个表（不算国家是5个），能覆盖最详细的地址吗？

感觉挺累赘的吧，这样的设计很拙劣。

广东省

广州市

天河区

龙口西路

光明大厦101

深圳市

某某区

某某镇

某某街道

某某大厦

。。。。。

对于深圳市就没法用上述数据库了。

Address(Id,Title,ParentId,ServiceCenterId_FK)

最后一个字段就是外键了，表明这个地址属于什么商城的服务，这个外键是可空的，表示地址不够具体无法确认具体是哪一家商场提供服务。

当然也可去掉这个外键，但要添加一个商城和 address的关系表，这样在选择广州的时候会把所有能提供服务的商城列出来，如果地址具体到天河区龙口西路时候，在进一步过滤数据。

实例数据

（Id, Title, ParentId）

1, 广东省， 0

2， 深圳市， 1

3， 广州市， 1

4， 天河区， 3

5， 深某区， 2

6， 龙口路， 4

。。。。

就是一个树形目录形式。

什么是好的数据库设计？

一些原则可为数据库设计过程提供指导。第一个原则是，重复信息（也称为冗余数据）很糟糕，因为重复信息会浪费空间，并会增加出错和不一致的可能性。第二个原则是，信息的正确性和完整性非常重要。如果数据库中包含不正确的信息，任何从数据库中提取信息的报表也将包含不正确的信息。因此，基于这些报表所做的任何决策都将提供错误信息。

所以，良好的数据库设计应该是这样的：

将信息划分到基于主题的表中，以减少冗余数据。

向 Access 提供根据需要联接表中信息时所需的信息。

可帮助支持和确保信息的准确性和完整性。

可满足数据处理和报表需求。

设计过程

设计过程包括以下步骤：

确定数据库的用途：这可帮助进行其他步骤的准备工作。

查找和组织所需的信息：收集可能希望在数据库中记录的各种信息，如产品名称和订单号。

划分到表中的信息：将信息项划分到主要的实体或主题中，如“产品”或“订单”。每个主题即构成一个表。

关闭信息项目导入的列 确定希望在每个表中存储哪些信息。每个项将成为一个字段，并作为列显示在表中。例如，“雇员”表中可能包含“姓氏”和“聘用日期”等字段。

指定为主键：选择每个表的主键。主键是一个用于唯一标识每个行的列。例如，主键可以为“产品 ID”或“订单 ID”。

设置表关系：查看每个表，并确定各个表中的数据如何彼此关联。根据需要，将字段添加到表中或创建新表，以便清楚地表达这些关系。

优化您的设计：分析设计中是否存在错误。创建表并添加几条示例数据记录。确定是否可以从表中获得期望的结果。根据需要对设计进行调整。

应用规范化规则：应用数据规范化规则，以确定表的结构是否正确。根据需要对表进行调整。

参考：数据库设计基础

以上就是关于多级用户系统的数据库应该怎么设计全部的内容，包括:多级用户系统的数据库应该怎么设计、怎样设计数据库管理系统、空间数据库的空间数据库的设计等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！