精华内容
下载资源
问答
  • 1.1数据库环境配置原则1.1.1操作系统环境:对于中小型数据库系统,采用linux操作系统比较合适,对于数据库冗余要求负载均衡能力要求较高的系统,可以采用Oracle9iRAC的集群数据库的方法,集群节点数范围在2—64个。...

    1.1数据库环境配置原则

    1.1.1操作系统环境:

    对于中小型数据库系统,采用linux操作系统比较合适,对于数据库冗余要求负载均衡能力要求较高的系统,可以采用Oracle9iRAC的集群数据库的方法,集群节点数范围在2—64个。对于大型数据库系统,可以采用SunSolarisSPARC64位小型机系统或HP9000系列小型机系统。RAD5适合只读操作的数据库,RAD1适合OLTP数据库

    1.1.2内存要求

    对于linux操作系统下的数据库,由于在正常情况下Oracle对SGA的管理能力不超过1.7G。所以总的物理内存在4G以下。SGA的大小为物理内存的50%—75%。对于64位的小型系统,Oracle数据库对SGA的管理超过2G的限制,SGA设计在一个合适的范围内:物理内存的50%—70%,当SGA过大的时候会导致内存分页,影响系统性能。

    1.1.3交换区设计

    当物理内存在2G以下的情况下,交换分区swap为物理内存的3倍,当物理内存>2G的情况下,swap大小为物理内存的1—2倍。

    1.1.4其他环境变量参考Oracle相关的安装文档和随机文档。

    1.2数据库设计原则

    1.2.1数据库SID

    数据库SID是唯一标志数据库的符号,命名长度不能超过5个字符。对于单节点数据库,以字符开头的5个长度以内字串作为SID的命名。对于集群数据库,当命名SID后,各节点SID自动命名为SIDnn,其中nn为节点号:1,2,…,64。例如rac1、rac2、rac24。

    1.2.2数据库全局名

    数据库全局名称:

    .domain

    1.2.3数据库类型选择

    对于海量数据库系统,采用datawarehouse的类型。对于小型数据库或OLTP类型的数据库,采用TransactionProcessing类型。

    1.2.4数据库连接类型选择

    Oracle数据库有专用服务器连接类型和多线程服务器MTS连接类型。对于批处理服务,需要专用服务器连接方式,而对于OLTP服务则MTS的世界数据报告连接方式比较合适。由于采用MTS后,可以通过配置网络服务实现某些特定批处理服务采用专用服务器连接方式,所以数据库设计时一般采用MTS类型。

    1.2.5数据库SGA配置

    数据库SGA可以采用手工配置或按物理内存比例配置,在数据库初始设计阶段采用按比例配置方式,在实际应用中按系统调优方式修改SGA。

    1.2.6数据库字符集选择

    为了使数据库能够正确支持多国语言,必须配置合适的数据库字符集,采用UTF8字符集。

    注意:如果没有大对象,在使用过程中进行语言转换没有什么影响,具体过程如下(切记设定的字符集必须是ORACLE支持,不然不能start)

    SQL>shutdownimmediate;

    SQL>startupmount;

    SQL>altersystemenablerestrictedsession;

    SQL>altersystemsetjob_queue_processes=0;

    SQL>数据库程序设计报告alterdatabaseopen;

    SQL>alterdatabasecharactersetinternal_usewe8iso8859p1;

    SQL>shutdownimmediate;

    SQL>startup

    1.2.7数据库其他参数配置

    1.2.7.1DB_FILES

    Db_files是数据库能够同时打开的文件数量,默认值是200个。当数据库规划时文件数量FILES接近或超过200个时候,按以下估计值配置:

    DB_FILES=FILES*1.5

    1.2.7.2Db_block_size

    一个extent要是5个blocks的倍数为好,如:一个blocks是4096字节,那一个extent就是2M、4M或8M为好。Db_block_size是数据库最小物理单元,一旦数据库创建完成,该参数无法修改,db_block_size按以下规则调整:

    数据仓库类型:db_block_size尽可能大,采用8192或16384

    OLTP类型:db_block_size用比较小的取值范围:2048或4096

    Blocks推荐是系统操作的块倍数(裸设备块大小是512字节,NTFS是4K,使用8K的方式在大部分系统上通用)。

    1.2.8数据库控制文件配置

    1.2.8.1控制文件镜象

    多个控制文件存放在不同的物理位置。

    1.2.8.2控制文件配置

    控制文件中参数设置,最大的数据文件数量不能小于数据库参数db_files。

    1.2.9数据库日志文件配置

    1.2.9.1日志文件大小

    日志文件的大小由数据库事务处理量决定,在设计过程中,确保每20分钟切换一个日志文件。所以对于批处理系统,日志文件大小为几百M到几G的大小。对于OLTP系统,日志文件大小为几百M以内。

    1.2.9.2日志文件组数量

    对于批处理系统,日志文系统数据库设计件组为5—10组;对于OLTP系统,日志文件组为3—5组,每组日志大小保持一致;对于集群数据库系统,每节点有各自独立的日志组。

    1.2.9.3日志成员数量

    为了确保日志能够镜象作用,每日志组的成员为2个。

    1.2.10数据库回滚段配置

    在Oracle9i数据库中,设计Undo表空间取代以前版本的回滚段表空间。

    Undo表空间大小的设计规范由以下公式计算:

    Undospace=UR*UPS*db_block_size+冗余量

    UR:表示在undo中保持的最长时间数(秒),由数据库参数UNDO_RETENTION值决定。

    UPS:表示在undo中,每秒产生的数据库块数量。

    例如:在数据库中保留2小时的回退数据,假定每小时产生200个数据库块。则Undospace=2*3600*200*4K=5.8G

    1.2.11数据库临时段表空间配置

    数据库临时段表空间根据实际生产环境情况调整其大小,表空间属性为自动扩展。

    1.2.12数据库系统表空间配置

    系统表空间大小1G左右,除了存放数据库数据字典的数据外,其他数据不得存储在系统表空间。

    1.3数据库表空间设计原则

    1.3.1表空间大小定义原则

    当表空间大小小于操作系统对最大文件限制时,表空间由一个文件组成。如果表空间大小大于操作系统对最大文件限制时,该表空间由多个数据文件组成,表空间的总大小为估算为:

    Tablespace+sum(数据段+索引段)*150%。

    1.3.2表空间扩展性设计原则

    表空间数据文件采用自动扩展的方式,扩展容量快大小按2的整数倍(1M、2M、4M、8M、16M、32M、64M)进行扩展,创建表空间时尽量采用nologing选项。表空间的最大限制一般采用unlimited,除非确切知道表空间数据文件的最大使用范围。(一般windows32位系统的文件最大2G,64位的unix系统系统文件最大128G,但也要注意文件格式设定的文件大小),建议最大为2G。表空间采用local管理方式,例如:

    CREATETABLESPACETBS_USERINFO

    DATAFILE

    '/oradata/tbs_userinfo.dbf'

    SIZE8M

    REUSE

    AUTOEXTENDON

    NEXT2M

    MAXSIZEUNLIMITED

    NOLOGGING

    EXTENTMANAGEMENT

    LOCAL

    AUTOALLOCATE

    SEGMENTSPACEMANAGEMENTAUTO;

    1.4裸设备的使用

    一个scsi设备可以14个分区,unix操作系统256个分区,性能比文件系统方式高15%左右,空间大于要小于(实际分区大小减两个ORACLE的数据块),比如100M,大于为100000K,推荐在unix使用软连接(ln)方式把裸设备形成文件,用加入表空间时加resue选项,当然也可只接把设备加入表空间,移动裸设备使用dd命令

    对于windows平台,oracle提供软连接工具,实现裸设备的使用,计算一条记录的长度

    2数据库逻辑设计原则

    2.1命名规范

    2.1.1表属性规范

    2.1.1.1表名

    前缀为Tbl_。数据表名称必须以有特征含义的单词或缩写组成,中间可以用“_”分割,例如:tbl_pstn_detail。表名称不能用双引号包含。

    2.1.1.2表分区名

    前缀为p。分区名必须有特定含义的单词或字串。

    例如:tbl_pstn_detail的分区p2004100101表示该分区存储2004100101时段的数据。

    2.1.1.3字段名

    字段名称必须用字母开头,采用有特征含义的单词或缩写,不能用双引号包含。

    2.1.1.4主键名

    前缀为PK_。主键名称应是前缀+表名+构成的字段名。如果复合主键的构成字段较多,则只包含第一个字段。表名可以去掉前缀。

    2.1.1.5外键名

    前缀为FK_。外键名称应是前缀+外键表名+主键表名+外键表构成的字段名。表名可以去掉前缀。

    2.1.2索引

    4.1.2.1普通索引

    前缀为IDX_。索引名称应是前缀+表名+构成的字段名。如果复合索引的构成字段较多,则只包含第一个字段,并添加序号。表名可以去掉前缀。

    2.1.2.2主键索引

    前缀为IDX_PK_。索引名称应是前缀+表名+构成的主键字段名,在创建表时候用usingindex指定主键索引属性。

    2.1.2.3唯一所以

    前缀为IDX_UK_。索引名称应是前缀+表名+构成的字段名。

    2.1.2.4外键索引

    前缀为IDX_FK_。索引名称应是前缀+表名+构成的外键字段名。

    2.1.2.5函数索引

    前缀为IDX_func_。索引名称应是前缀+表名+构成的特征表达字符。

    2.1.2.6蔟索引

    前缀为IDX_clu_。索引名称应是前缀+表名+构成的簇字段。

    2.1.3视图

    前缀为V_。按业务操作命名视图。

    2.1.4实体化视图

    前缀为MV_。按业务操作命名实体化视图。

    2.1.5存储过程

    前缀为Proc_。按业务操作命名存储过程

    2.1.6触发器

    前缀为Trig_。触发器名应是前缀+表名+触发器名。

    2.1.7函数

    前缀为Func_。按业务操作命名函数

    2.1.8数据包

    前缀为Pkg_。按业务操作集合命名数据包。

    2.1.9序列

    前缀为Seq_。按业务属性命名。

    2.1.10表空间

    2.1.10.1公用表空间

    前缀为Tbs_。根据存储的特性命名,例如:tbs_parameter。

    2.1.10.2专用表空间

    Tbs__nn。该表空间专门存储指定的某一个表,或某一表的若干个分区的数据

    2.1.11数据文件

    nn.dbf。nn=1,2,3,4,…等。

    2.1.12普通变量

    前缀为Var_。存放字符、数字、日期型变量。

    2.1.13游标变量

    前缀为Cur_。存放游标记录集。

    2.1.14记录型变量

    前缀为Rec_。存放记录型数据。

    2.1.15表类型变量

    前缀为Tab_。存放表类型数据。

    2.1.16数据库链

    前缀为dbl_。表示分布式数据库外部链接关系。

    2.2命名

    2.2.1语言

    命名应该使用英文单词,避免使用拼音,特别不应该使用拼音简写。命名不允许使用中文或者特殊字符。

    英文单词使用用对象本身意义相对或相近的单词。选择最简单或最通用的单词。不能使用毫不相干的单词来命名

    当一个单词不能表达对象含义时,用词组组合,如果组合太长时,采用用简或缩写,缩写要基本能表达原单词的意义。

    当出现对象名重名时,是不同类型对象时,加类型前缀或后缀以示区别。

    2.2.2大小写

    名称一律大写,以方便不同数据库移植,以及避免程序调用问题。

    2.2.3单词分隔

    命名的各单词之间可以使用下划线进行分隔。

    2.2.4保留字

    命名不允许使用SQL保留字。

    2.2.5命名长度

    表名、字段名、视图名长度应限制在20个字符内(含前缀)。

    2.2.6字段名称

    同一个字段名在一个数据库中只能代表一个意思。比如telephone在一个表中代表“电话号码”的意思,在另外一个表中就不能代表“手机号码”的意思。

    不同的表用于相同内容的字段应该采用同样的名称,字段类型定义。

    2.3数据类型

    2.3.1字符型

    固定长度的字串类型采用char,长度不固定的字串类型采用varchar。避免在长度不固定的情况下采用char类型。如果在数据迁移等出现以上情况,则必须使用trim()函数截去字串后的空格。

    2.3.2数字型

    数字型字段尽量采用number类型。

    2.3.3日期和时间

    2.3.3.1系统时间

    由数据库产生的系统时间首选数据库的日期型,如DATE类型。

    2.3.3.2外部时间

    由数据导入或外部应用程序产生的日期时间类型采用varchar类型,数据格式采用:YYYYMMDDHH24MISS。

    2.3.3.3大字段

    如无特别需要,避免使用大字段(blob,clob,long,text,image等)。

    2.3.3.4唯一键

    对于数字型唯一键值,尽可能用系列sequence产生。

    2.4设计

    2.4.1范式

    如无性能上的必须原因,应该使用关系数据库理论,达到较高的范式,避免数据冗余,但是如果在数据量上与性能上无特别要求,考虑到实现的方便性可以有适当的数据冗余,但基本上要达到3NF.如非确实必要,避免一个字段中存储多个标志的做法。如11101表示5个标志的一种取值。这往往是增加复杂度,降低性能的地方。

    2.4.2表设计

    2.4.2.1逻辑段设计原则

    2.4.2.1.1Tablespace

    每个表在创建时候,必须指定所在的表空间,不要采用默认表空间以防止表建立在系统表空间上导致性能问题。对于事务比较繁忙的数据表,必须存放在该表的专用表空间中。

    2.4.2.1.2Pctused

    默认pctused导致数据库物理空间利用率非常低40%左右;对于update比较少或update不导致行增大的表,pctused可设置在60—85之间;对于update能够导致行增大的表,update设置在40—70之间

    2.4.2.1.3Initrans

    对于需要并行查询或者在RAC数据库中需要并行处理的表,initrans设置为2的倍数,否则,不设该值。

    2.4.2.1.4Storage

    2.4.2.1.4.1Initial

    尽量减少表数据段的extents数量,initial的大小尽量接近数据段的大小64K,128K,…,1M,2M,4M,8M,16M,…,等按2的倍数进行圆整。例如表或分区数据段大小为28M,则initial取32M。

    2.4.2.1.4.2Next

    表或分区扩展extents的大小,按上述方法进行圆整。当表或分区数据段无法按Initial接近值进行圆整的情况下,其大小可以按Initial+Next进行圆整。此时,必须设置Minextents=2。例如:表或分区数据段大小为150M,则Initial=128M;Next=32M,Minextents=2。

    2.4.2.1.4.3Minextents

    该参数表示表创建时候Extents的初始数量,一般取1—2。

    2.4.2.1.4.4Pctincrease

    表示每个扩展Extents的增长率,设置pctincrease=0能够获得较好的存储性能。

    2.4.2.2特殊表设计原则

    2.4.2.2.1分区表

    对于数据量比较大的表,根据表数据的属性进行分区,以得到较好的性能。如果表按某些字段进行增长,则采用按字段值范围进行范围分区;如果表按某个字段的几个关键值进行分布,则采用列表分区;对于静态表,则采用hash分区或列表分区;在范围分区中,如果数据按某关键字段均衡分布,则采用子分区的复合分区方法。

    2.4.2.2.2聚蔟表

    如果某几个静态表关系比较密切,则可以采用聚蔟表的方法。

    2.4.2.3完整性设计原则

    2.4.2.3.1主键约束

    关联表的父表要求有主健,主健字段或组合字段必须满足非空属性和唯一性要求。对于数据量比较大的父表,要求指定索引段。

    2.4.2.3.2外键关联

    对于关联两个表的字段,一般应该分别建立主键、外键。实际是否建立外键,根据对数据完整性的要求决定。为了提高性能,对于数据量比较大的标要求对外健建立索引。对于有要求级联删除属性的外键,必须指定ondeletecascade。

    2.4.2.3.3NULL值

    对于字段能否null,应该在sql建表脚本中明确指明,不应使用缺省。由于NULL值在参加任何运算中,结果均为NULL。所以在应用程序中必须利用nvl()函数把可能为NULL值得字段或变量转换为非NULL的默认值。例如:NVL(sale,0)。

    2.4.2.3.4Check条件

    对于字段有检查性约束,要求指定check规则。

    2.4.2.3.5触发器

    触发器是一种特殊的存储过程,通过数据表的DML操作而触发执行,起作用是为确保数据的完整性和一致性不被破坏而创建,实现数据的完整约束。

    触发器的before或after事务属性的选择时候,对表操作的事务属性必须与应用程序事务属性保持一致,以避免死锁发生。在大型导入表中,尽量避免使用触发器。

    2.4.2.4注释

    表、字段等应该有中文名称注释,以及需要说明的内容。

    2.4.3索引设计

    对于查询中需要作为查询条件的字段,可以考虑建立索引。最终根据性能的需要决定是否建立索引。对于复合索引,索引字段顺序比较关键,把查询频率比较高的字段排在索引组合的最前面。在分区表中,尽量采用local分区索引以方便分区维护。

    除非时分区local索引,否则在创建索引段时候必须指定指定索引段的tablespace、storage属性,具体参考4.4.2.1内容。

    2.4.4视图设计

    视图是虚拟的数据库表,在使用时要遵循以下原则:

    从一个或多个库表中查询部分数据项;

    为简化查询,将复杂的检索或字查询通过视图实现;

    提高数据的安全性,只将需要查看的数据信息显示给权限有限的人员;

    视图中如果嵌套使用视图,级数不得超过3级;

    由于视图中只能固定条件或没有条件,所以对于数据量较大或随时间的推移逐渐增多的库表,不宜使用视图;可以采用实体化视图代替。

    除特殊需要,避免类似Select*from而没有检索条件的视图;

    视图中尽量避免出现数据排序的SQL语句。

    2.4.5包设计

    存储过程、函数、外部游标必须在指定的数据包对象PACKAGE中实现。存储过程、函数的建立如同其它语言形式的编程过程,适合采用模块化设计方法;当具体算法改变时,只需要修改需要存储过程即可,不需要修改其它语言的源程序。当和数据库频繁交换数据是通过存储过程可以提高运行速度,由于只有被授权的用户才能执行存储过程,所以存储过程有利于提高系统的安全性。

    存储过程、函数必须检索数据库表记录或数据库其他对象,甚至修改(执行Insert、Delete、Update、Drop、Create等操作)数据库信息。如果某项功能不需要和数据库打交道,则不得通过数据库存储过程或函数的方式实现。在函数中避免采用DML或DDL语句。

    在数据包采用存储过程、函数重载的方法,简化数据包设计,提高代码效率。存储过程、函数必须有相应的出错处理功能。

    2.4.6安全性设计

    4.4.6.1管理默认用户

    在生产环境中,必须严格管理sys和system用户,必须修改其默认密码,禁止用该用户建立数据库应用对象。删除或锁定数据库测试用户scott。

    2.4.6.2数据库级用户权限设计

    必须按照应用需求,设计不同的用户访问权限。包括应用系统管理用户,普通用户等,按照业务需求建立不同的应用角色。

    用户访问另外的用户对象时,应该通过创建同义词对象synonym进行访问。

    2.4.6.3角色与权限

    确定每个角色对数据库表的操作权限,如创建、检索、更新、删除等。每个角色拥有刚好能够完成任务的权限,不多也不少。在应用时再为用户分配角色,则每个用户的权限等于他所兼角色的权限之和。

    2.4.6.4应用级用户设计

    应用级的用户帐号密码不能与数据库相同,防止用户直接操作数据库。用户只能用帐号登陆到应用软件,通过应用软件访问数据库,而没有其它途径操作数据库。

    2.4.6.5用户密码管理

    用户帐号的密码必须进行加密处理,确保在任何地方的查询都不会出现密码的明文。

    2.5SQL编写

    2.5.1字符类型数据

    SQL中的字符类型数据应该统一使用单引号。特别对纯数字的字串,必须用单引号,否则会导致内部转换而引起性能问题或索引失效问题。利用trim(),lower()等函数格式化匹配条件。

    2.5.2复杂sql

    对于非常复杂的sql(特别是有多层嵌套,带子句或相关查询的),应该先考虑是否设计不当引起的。对于一些复杂SQL可以考虑使用程序实现。

    USER_TAB_COMMENTS数据字典

    Commenton可加注解

    2.5.3高效性

    2.5.3.1避免In子句

    使用In或notIn子句时,特别是当子句中有多个值时,且查询数据表数据较多时,速度会明显下降。可以采用连接查询或外连接查询来提高性能。

    Char比varchar查询时高询

    在进行查询及建立索引时,char比varchar的效率要高,当然varchar在存储上比char要好

    2.5.3.2避免嵌套的Select子句

    这个实际上是In子句的特例。

    2.5.3.3避免使用Select*语句

    如果不是必要取出所有数据,不要用*来代替,应给出字段列表,注:不含selectcount(*)。

    2.5.3.4避免不必要的排序

    不必要的数据排序大大的降低系统性能。

    2.5.4健壮性

    2.5.4.1Insert语句

    使用Insert语句一定要给出要插入值的字段列表,这样即使更改了表结构加了字段也不会影响现有系统的运行。

    2.5.4.2Count(*)、Count(*)、count(distinctid)的区别

    Selectcount(*)fromtesttab

    得到表testtab的记录数

    selectcount(id)fromtesttab

    得到表testtabid字段非空记录数

    selectcount(distinctid)fromtesttab

    得到表testtabid字段值非相同记录数

    2.5.4.3Notnull为字段类型性质的约束

    本约束功能在后期无语法使期失效,可使用修改字段类型方式

    altertablemodify字段名类型notnull

    altertablemodify字段名类型

    2.5.4.4外键值可用null的问题

    外键列如没有明确说明notnull,可插入null记录(而null是在外部表的记录中没有的),如无可插null记录的想法,要对外键字段加notnull约束。

    2.5.4.5序列sequence跳号的问题

    sequence因回滚,系统崩溃(使用cache内的值将认为已用),多表引用都将使其跳号,所以不能用于为连续序号utl_row.cast_to_row

    2.5.4.6unicn\intersect\minus使用ordeyby的注意事项

    以上语句进行连表操作,而表同表的字段顺序的类型相同但字段标题名可不同,使用ordeyby时后面如果是字段名,要求所有的表的字段标题名相同,否则用字段的顺序号

    selectid,name,yearfromuser1

    union

    selectno,name,to_number(null)yearfromuser2

    orderby1,name,year

    2.5.5安全性

    2.5.5.1Where条件

    无论在使用Select,还是使用破坏力极大的Update和Delete语句时,一定要检查Where条件判断的完整性,不要在运行时出现数据的重大丢失。如果不确定,最好先用Select语句带上相同条件来果一下结果集,来检验条件是否正确。

    2.5.6完整性

    有依赖关系的表,例如主外键关系表,在删除父表时必须级联删除其子表相应数据,或则按照某种业务规则转移该数据。9I中表中字段缩小及变类型,字段为空或表空,varchar和char长度不变可任意改,字段名和表名可字段可用ALTERTABLEtableSETUNUSED(column)设定为不可用,注意无命令再设为可用

    3备份恢复设计原则

    3.1数据库exp/imp备份恢复

    Oracle数据库的Exp、Imp提供了数据快速的备份和恢复手段,提供了数据库级、用户级和表级的数据备份恢复方式。这种方法一般作为数据库辅助备份手段。

    3.1.1数据库级备份原则

    在数据库的数据量比较小,或数据库初始建立的情况下采用。不适合7*24的在线生产环境数据库备份。

    3.1.2用户级备份原则

    在用户对象表数据容量比较小、或则用户对象初始建立的情况下使用。

    3.1.3表级备份原则

    主要在以下场合采用的备份方式:

    参数表备份

    静态表备份

    分区表的分区备份。

    3.2数据库冷备份原则

    数据库冷备份必须符合以下原则:

    数据库容量比较小。

    数据库允许关闭的情况。

    3.3Rman备份恢复原则

    这种方式适用于7*24环境下的联机热备份情形。

    3.3.1Catalog数据库

    单独建立备份恢复用的数据库实例,尽可能与生产环境的数据库分开,确保catalog与生产数据库的网络连接良好。在9I系统使用良好的备份策略以可,支持完全使用控制文件保存catalog信息,备份策略如下:

    backupspfileformat'/data/backup/%d_SPFILE_%T_%s_%p.bak';

    sql"altersystemarchivelogcurrent";

    backuparchivelogallformat'/data/backup/%d_ARC_%T_%s_%p.bak'deleteallinput;

    backupcurrentcontrolfileformat'/data/backup/%d_CTL_%T_%s_%p.bak';

    在spfile、控制文件、数据库全丢的情况下可通过下面的方式恢复

    RMAN>connecttarget

    connectedtotargetdatabase(notstarted)

    RMAN>svc 连接数据库tartup

    RMAN>restorespfilefrom'/data/backup/COMMDB_SPFILE_20030411_9_1.bak';

    SQL>startup

    ORA-00205:errorinidentifyingcontrolfile,checkalertlogformoreinfo

    RMAN>restorecontrolfilefrom'd:\DB92_CTL_20031113_9_1.BAK';

    Moutdatabase:

    RMAN>recoverdatabase;

    RMAN>alterdatabaseopenresetlogs;

    注意:对数据库设定控制文件保存备份信息为365天,具体语句如下。

    altersystemsetcontrol_file_record_keep_time=365SCOPE=BOTH;

    3.3.2ArchiveLog

    设置ArchiveLog的位置,确保存储介质有足够的空间来保留指定时间内archivelog的总量。建设定期对RMAN进行全备份,删除冗余归档日志文件。

    3.3.3全备份策略

    对于小容量数据库,可以采用全备份策略。对于大容量数据库,必须制定全备份策略方案,备份时对archivelog进行转储,同时冷备份catalog数据库。

    3.3.4增量备份策略

    对于大容量数据库数据报告怎么写,必须制定增量备份、累积备份和全备份的周期,备份时对archivelog进行转储,同时冷备份catalog数据库。

    3.3.5恢复原则

    采用Rman脚本进行数据库恢复。数据库恢复有以下几种:

    3.3.5.1局部恢复

    主要用于恢复表空间、数据文件,一般不影响数据库其他操作。

    3.3.5.2完全恢复

    数据库恢复到故障点,由catalog当前数据库决定。

    3.3.5.3不完全恢复

    恢复到数据库的某一时间点或备份点。

    恢复catalog数据库。

    恢复数据库controlfile。

    恢复到数据库某一时间点。

    重设日志序列。

    3.4备用数据库原则

    数据库系统在以下情况下可以考虑采用备用数据库dataguard原则:

    数据库容量适中。

    数据库严格要求7*24不间断,或间断时间要求控制在最小范围内。

    数据库要求有异地备份冗余。

    3.5一些小数据库应用系统设计经验

    使用oemc的oms时,首选项要求是节点和数据库分别加入系统用户(如:administrator)和数据库DBA用户(system)。节点的系统用户必须有批处理作业登录的权限

    agent不能启动,lisnter修改后都要手动删除oracle\ora9\network\agent中的*.q文件

    oracle\admin\my9i\bdump中是用户的出错日志

    改变表的空间的方式altertablehr.ssssmoveTABLESPACEexample(要重建索引);或用imp导入时,设定导入用户只有某一表空间的使用权,无RESOURCE角色和UNLIMITEDTABLESPACE权限

    aletersystemsetlog_checkpoint_to_alter=true,后可报警文件发现checkpoint的起动和结束时间。

    3.6系统调优知识

    3.6.1.1生成状态报表(statspack的使用)

    使用(存放位置@\rdbms\admin\)的文件生成报表用户

    @\rdbms\admin\Spcreate.sql建表

    将timed_statistics设定true

    使用生成的perfstat用户登录,执行以下语句手动收集信息

    Exexstatspack.snap

    Execstatspack.snap(I_SNAP_LEVEL=>0,I_MODEFY_PRAMETER=>TRUE)0级,最少10最大

    使用下面的语句生成状态报表

    @\rdbms\admin\Spreport.sql

    其他相关文件

    deletestats$snapshot;清原来记录数据

    @\rdbms\admin\Saputo.sql

    selectjobfromuser_jobs取用户作业号

    execdbms_remove(作业号)

    timed_statistics=true要求

    @\rdbms\admin\spdaccess数据库使用教程rop.sql;

    3.6.1.2sql追踪

    设定全部用户跟踪

    altersystemsetsql_trace=true;

    用户级别跟踪

    altersessionsetsql_trace=true;

    用户的跟踪文件生成在admin\{pid}\udump\{pid}_ora_{SPID}.trc中,spid从下面语句得到

    SELECTb.namebkpr,s.username,p.spid,s.sid,s.serial#FROMv$bgprocessb,v$sessions,v$processpWHEREp.addr=b.paddr(+)ANDp.addr=s.paddrands.username=user;

    DBA对特定用户跟踪

    execdbms_system_set_Sql_trace_in_session(sid,serial#,true)

    信息从下面得到

    SELECTb.namebkpr,s.username,p.spid,s.sid,s.serial#,osuser,s.program

    FROMv$bgprocessb,v$sessions,v$processp

    WHEREp.addr=b.paddr(+)

    ANDp.addr=s.paddr;

    /*p.spid用于sql_trace时日志编号,dbms_system.set_sql_trace_in_session(sid,erial#,true)*/

    用户的跟踪文件生成在admin\{pid}\udump中

    系统的跟踪文件生成在admin\{pid}\bdump\alert_{pid}.log

    tkprof.exe将log文件生成格式化文本

    在avRd(ms)20以上说明表空间使用过用频繁,考虑将表分开其他表空间上

    系统变量fast_start_mttr_target的值要大到不产生log等待,当然也可通过加log组使其不等待

    reaolog大小应为每30分钟切换一次

    建议表空间的利用率不超80%

    bufferhit要达80%以上为好

    3.6.1.3内存调整

    一般的内存分配原则

    SGA50%(其中80%DATABUFFER,15%SHAREPOOL,5其他)

    PGA30%

    OS20%

    例如:2G的WINDOWS的平台,OS300M,SAG1.2G,PGA500M

    内存分配的基本单位

    SGA《=128M 4M

    SGA》128M  64位系统16M,32M系统8M

    动态分配时总值不可大于sga_max_size

    通过V$SGA_DYNAMIC_FREE_MEMORY取空闲内存空间

    在缩小时如果内存空间实际在应用中,CPU利用率将达100%,最后将语句出错。

    V$SGASTAT 可看实际的使用情况

    Redologbuffer一般在5M内,可通过v$sessuon_wait看是否等,v$sysstat

    可也通过报警文件看是否等切换,方法可加组。可通过nologging(数据库也要设定支持nologging)方法减少日志文件产生量。

    java_pool没有设定时,使用shared_pool_size

    3.6.1.3.1shared_pool

    本缓冲区用于sql语句,plsql等的对象保存

    Cursor_sharing{Exact|Similar|force}游标共享设定

    Force方式适用OLTP数据库,Exact方式适合数据仓库,similar为智能方式

    hardparses硬SQL语句分析,每秒要底于100次,小要加大shared_pool

    softparse软SQL语句分析,OLTP要达90%以上,小要加大shared_pool

    不建议用无命名PLSQL段

    如果有大PLSQL(存储过程)对象可强制保存于内存,也可加大SHARED_POOL_RESERVED_SIZE,大小不可过SHARED_POOL_SIZE的50%,不然实例不能起动

    3.6.1.3.2db_cache

    本缓冲区用于数据库数据对象保存

    db_cache_advice为on,可以提出通过企业管理器看到系统建议

    通过select*fromv$system_event进行系统查看。

    发现存在freebufferwaits,说明不能将databuffer及时写入datafile;

    可通过增加加CPU后,加db_writer_processes=CPU数改善。

    也可设disk_asynch_io为true,使用异步IO(前提同要操作系统支持)db_writer_processes=1时(只有一个CPU的情况下),也可通加大dbwr_io_slaves来改善。db_writer_processes>1,不可用本功能

    调整效果排序:异步IO>CPU>dbwr_io_slaves

    BufferBusyWaits大说明出现IO冲突

    BufferBusyWaits大和dbbock大说明全表扫描多,说明数据不能读入,可加大

    db_cache_size来改善.

    Undo block大要加大回滚段(手动管理方式,9I默认是自动管理)

    undoheader大要加大回滚段(手动管理方式,9I默认是自动管理)

    db_cache命中率99%,不是唯一因素,关系是不要出现等待。建议达90%以上。

    内存使用建议:

    系统可以设三个缓冲区,建表时可设定用那个缓冲区(默认在db_cache_size)

    db_cache_size   (默认区)

    db_keep_cache_size(常访问,小于db_keep_cache_size的10%的表可放于本区)

    db_recycle_cache_size(一个事物完成后常时间不再使用,或两倍大小于缓冲区)

    3.6.2排序的优化

    9I为专用服务器时系统变量workarea_size_policy设定为auto,statistics_level设定为TYPICAL可获取v$pga_target_advice中的优化建议。参数pga_aggregate_target值为所有连接用户可用排序内存。

    9I为共享服务器时workarea_size_policy设定为menaul,sort_area_size值为每用户排序内存。

    如果内存不足将使用TEMP表空间进行排序,排序使用比率disk/meme应小于5%

    尽量少用排序,如果使用排序功能,尽量在字段上加索引进行优化。

    SQL分析模式:RBO(基于规则)方案小表(驱动表)放在最后,优先使用索引,对SQL语句要求严格(8I以前的模式);CBO(基于开销)根据统计值进行选择开销最少,性能最优的最佳方式进行,但本方式DBA(使用analyzetable语句)要定期进行分析统计.系统设定通过optimizer_mode系统参数

    说明:指定优化程序的行为。如果设置为RULE,就会使用基于规则的优化程序,除非查询含有提示。如果设置为CHOOSE,就会使用基于成本的优化程序,除非语句中的表不包含统计信息。ALL_ROWS或FIRST_ROWS

    始终使用基于成本的优化程序。

    值范围:RULE|CHOOSE|FIRST_ROWS|ALL_ROWS

    默认值:CHOOSE

    {rule(RBO)|choose(自动选择)|fist_rows|fist_rows_n|all_row}

    3.6.3统计信息

    进行某表的统计分析

    EXECUTEdbms_stats.gather_table_stats('HR','EMPLOYEES');

    查看结果

    SELECTnum_rows,blocks,empty_blocksasempty,

    avg_space,chain_cnt,avg_row_len

    FROMdba_tables

    WHEREowner='HR'

    ANDtable_name='EMPLOYEES';

    4设计工具

    统一使用sybasepowerdesigner设计工具,在该工具上完成物理模型的设计。所有的数据库对象尽可能在物理模型上进行设计,而且每个物理模型都要有相应的文字描述。

    所有的数据库对象变更以数据库物理模型为基准。为了避免字符敏感问题,产生的脚本以大写字母为标准。

    展开全文
  • bitsCN.com数据库设计数据库设计前的准备数据库设计(database design):数据库设计是指对于一个给定的应用环境,构造(设计)优化的数据库逻辑模式和物理结构,并据此建立数据库及其应用系统,使之能够有效的存储和管理...

    bitsCN.com

    数据库设计与数据库设计前的准备

    数据库设计(database design):数据库设计是指对于一个给定的应用环境,构造(设计)优化的数据库逻辑模式和物理结构,并据此建立数据库及其应用系统,使之能够有效的存储和管理要求,满足各种用户的需求,包括信息管理要求和数据操作要求.

    信息管理要求:信息管理要求是指数据库中应该存储和管理哪些数据对象。

    数据操作要求:数据操作要求是指对数据对象需要进行哪些操作,如:添加 删除 修改 统计 查询 等等

    数据库设计的一般步骤:

    需求分析

    概念结构设计

    逻辑结构设计

    物理结构设计

    数据库实施、运行和维护

    现在简要的介绍一下这六个流程的大体作用:

    需求分析:就是把各个用户的应用要求给综合起来 。

    概念结构设计:把一些文字概念转为E——R图(常用) 。

    逻辑结构设计:就是一般就是把E——R图转换成数据库产品支持的数据模型,如关系模型,形成逻辑模型,然后根据用户要求增加视图形成外模式。

    物理结构设计:就是根据DBMS的特点和处理的需求,进行物理存储安排,建立索引,形成数据库的内模式。

    数据库实施、运行和维护:就是数据库应用系统经过试运行后即可投入到正是运行,在数据库应用系统运行中不断地对其进行修改和维护完善。

    下面会根据数据库的设计步骤分别说明设计一个数据库的大体流程是什么,然后最后会给出一个数据库设计的实例演示。

    bitsCN.com

    本条技术文章来源于互联网,如果无意侵犯您的权益请点击此处反馈版权投诉

    本文系统来源:php中文网

    展开全文
  • 用于数据库设计数据库课程设计。包括数据需求分析,概念结构设计,逻辑结构设计物理结构实现,与扩展功能实现。
  • 数据库设计(database design):数据库设计是指对于一个给定的应用环境,构造(设计)优化的数据库逻辑模式和物理结构,并据此建立数据库及其应用系统,使之能够有效的存储和管理要求,满足各种用户的需求,包括信息管理...

    数据库设计与数据库设计前的准备

     

    数据库设计(database design):数据库设计是指对于一个给定的应用环境,构造(设计)优化的数据库逻辑模式和物理结构,并据此建立数据库及其应用系统,使之能够有效的存储和管理要求,满足各种用户的需求,包括信息管理要求和数据操作要求.

    信息管理要求:信息管理要求是指数据库中应该存储和管理哪些数据对象。

    数据操作要求:数据操作要求是指对数据对象需要进行哪些操作,如:添加 删除 修改 统计 查询 等等

    数据库设计的一般步骤:

     

    1. 需求分析
    2. 概念结构设计
    3. 逻辑结构设计
    4. 物理结构设计
    5. 数据库实施、运行和维护


    现在简要的介绍一下这六个流程的大体作用:

    需求分析:就是把各个用户的应用要求给综合起来 。

    概念结构设计:把一些文字概念转为E——R图(常用) 。

    逻辑结构设计:就是一般就是把E——R图转换成数据库产品支持的数据模型,如关系模型,形成逻辑模型,然后根据用户要求增加视图形成外模式。

    物理结构设计:就是根据DBMS的特点和处理的需求,进行物理存储安排,建立索引,形成数据库的内模式。

    数据库实施、运行和维护:就是数据库应用系统经过试运行后即可投入到正是运行,在数据库应用系统运行中不断地对其进行修改和维护完善。

     

    下面会根据数据库的设计步骤分别说明设计一个数据库的大体流程是什么,然后最后会给出一个数据库设计的实例演示。

     下一节:

     http://www.cnblogs.com/haoke/archive/2012/12/10/2812148.html

    转载于:https://www.cnblogs.com/haoke/archive/2012/11/30/2796672.html

    展开全文
  • 数据库设计,需求分析,数据库概念结构设计,数据库逻辑结构设计数据库物理结构设计
  • 、什么是范式2、范式之间的关系3、值域4、第一范式(1NF)5、第二范式(2NF)6、第三范式(3NF)7、其他范式8、雪花模型9、注意事项二、物理设计1、物理设计2、相信的事务不同的名称3、逻辑模型和物理模型对比(重点!...

    前言:

    上一章我们看了数据库设计的一整套方法,今天呀,我们来介绍一下范式和反范式以及通过一个实例来看一下数据库的设计,其实范式也是属于逻辑设计

    一、范式理论

    1.、什么是范式

    满足不同程度的要求为满足不同的范式
    把属性放置在正确的实体的这个过程称为范式化(normalization)

    发展历史

    • -1971~1972:Codd系统地提出了1NF、2NF和3NF的概念,讨论了规范化问题
    • 1974: Codd和Boyce共同提出了新范式,BCNF
    • 1976: Fagin提出了4NF
    • 之后的研究人员进一步提出5NF

    遵循规范化理论设计出的关系数据模型

    1. 能够避免冗余数据的产生;
    2. 降低数据不一致的风险;
    3. 模型具有良好的可扩展性;
    4. 可以灵活调整以反映出不断变化的业务规则。
    2、范式之间的关系

    范式之间的关系:

    • 满足最低要求的叫第一范式,记为1NF。
    • 在第一范式满足进一步要求的为第二范式,2NF。
    • 以此类推。
    • 一个低一级范式的关系模式通过模式分解(Schema Decomposition)可以转换为若干个高一级范式的关系模式的集合。---->比如第二范式通过模式分解,生成若干个第三范式关系模式,这种过程就叫做范式化。
      在这里插入图片描述
    3、值域
    • 定义一个属性取值的有效范围
    • 在值域里面的值都是合法数据。
    • 值域体现了规则。
      在这里插入图片描述
    4、第一范式(1NF)
    • 属性取值的原子性(不可再分)。
    • 对原子性的理解很容易出现分歧,比如身份证里面就包含了出生日期,性别的属性,那是否需要拆分呢?按照理论上来说它是可以拆分的,不具备原子性。但从值域的角度来讲,在身份证这个值域里面它具备了原子性就不用继续拆分了。
    • 属性取值数量是单一的,不能是值域里面的子集。
    • 需要有主键。
    • 实体中的属性不存在重复组问题。
      在这里插入图片描述

    问题:
    1.数值格式不统一不说了,还包含非数值的字符
    2.更大的问题是,有两个人的电话号码存放的电话数量超过一个。也就是违反了“属性取值数量是单一的,不能是值域里面的子集”这种情况。两个号码是电话号码值域里面的子集合。

    在这里插入图片描述

    上面的表示比较常见的拆分手段,实际上还是不符合第一范式。因为出现了repeating group,重复组问题

    Repeating group,技术上讲取值是原子性的,但在概念上把相同的属性进行了重复

    Repeating group所产生的问题

    1. 有些记录会产生空值。(实际应用场合,这种大宽表会带来数据的稀疏性,例如数据挖掘的宽表使用)
    2. 结构会产生不稳定性,比如有些人有3个电话号码,甚至更多。所以可能要经常更新表结构,导致模型的不稳定性
      也就是实际应用中常说的会因为业务的发展而对模型带来不稳定性冲击
    3. 这个也会在使用数据的时候产生歧义,那个手机号码应该放在第一列,那个手机号码放在第二位,规则是什么,要获取客户的联系方式的时候以那个电话为准?
      导致业务使用数据的时候会有语义上的混乱和不明确。

    那么应该怎么办呢?
    这个就ok!!!
    在这里插入图片描述

    5、第二范式(2NF)

    第二范式的两个必要条件:

    • 首先要满足第一范式。

    • 每一个非主属性都完全函数依赖于任何一个候选键。
      在这里插入图片描述

    • 第2范式强调的是完全函数依赖

    • 简单的理解2NF就是所有非主键字段都要依赖于整个主键,而不是其中的一部分

    • 简单的来说, 如果一个实体的主键字段只有一个,那么基本上这个实体就是符合第二范式的

    • 对于不满足2NF比如订单日期。实际上它依赖于部分主键,订单编号,所以在这个表里面,会随着订 - 单编号的重复而出现大量的重复。数据冗余了。

    那么怎么修改呢?
    修改方法:
    在这里插入图片描述

    6、第三范式(3NF)
    • 首先要满足第二范式。
    • 每一个非主属性不会传递性依赖于键码。

    在这里插入图片描述

    简单的理解3NF就是所有非主键字段都要依赖于整个主键,而不会依赖于非主键的其他属性

    我们就拆表!
    拆表,利用外键形成关系
    在这里插入图片描述

    7、其他范式

    理解:
    1NF: 要有主键。2NF: 依赖于整个主键。3NF: 只能依赖于主键

    因为在实际应用中,模型做到满足第三范式就已经足够了,现在数据库设计最多满足3NF,普遍认为范式过高,虽然具有对数据关系更好的约束性,但也导致数据关系表增加而令数据库IO更易繁忙,
    所以在现实项目中,基本没有实现到3NF以上级别的案例。所以在培训过程中,不用介绍3NF之后的范式标准了,有兴趣的学员,可以课后自行查看相关资料学习
    BCNF,4NF,5NF就是主键加强。
    BCNF:符合3NF,并且,主属性不依赖于主属性。
    4NF:要求把同一表内的多对多关系删除。
    5NF:从最终结构重新建立原始结构

    8、雪花模型

    在这里插入图片描述

    雪花模型是符合三范式要求的。所以作为一个扩展知识的点简单介绍。

    9、注意事项
    1. 建立命名规则:
      命名规则的意义:
      • 统一命名,避免歧义。
      • 防止冗余的实体或者属性产生。
      • 有利于工作中不同角色的人员之间通过规范的命名和属于进行交流。
      • 便于使用。

      实体和属性的命名建议:
      • 实体名称:分类域大写+实体描述词(全称,首字母大写)。
      • 属性名称:使用全称,首字母大写,一些约定俗称的空格缩写。
      • 避免英语和拼音的混用。
      • 如果是缩写,一定是英语的缩写,避免使用拼音的声母缩写。

    命名规则最主要的思想还是要统一,命名统一才能有利于大家交流和规范开发

    1. 按照设计流程设计逻辑数据模型

    2. 确定实体和属性:
      定义实体的主键(PK)。
      定义部分非键属性(Non-Key Attribute)。
      定义非唯一属性组。
      添加相应的注释内容。

    3. 确定实体与实体之间的关系
      通过外键来体现。
      决定实体之间是否是可识别的关系。
      确定关系的基数属于1:1, 1:n还是n:m。

    4. 补充实体的非键值属性
      按照3NF的规则,判定添加的属性是否符合3NF的设计原则。
      如果新增属性违反3NF,需要进行实体拆分,确定新的实体和关系。
      添加注释。

    二、物理设计

    1、物理设计
    • 在用户确认的逻辑模型基础上,以数据库系统运行效率,业务操作效率,前端应用效率等因素为出发点对模型进行的调整。

    • 面向物理实施过程的具体细节。

    • 最终目的是转化为目标数据库的可部署的定义语言(DDL)。

    • 工作内容,包括但不限于

    1. 实体非正则化处理;
    2. 表和字段的物理命名;
    3. 确定字段的类型,长度,精度,大小写敏感等属性;
    4. 增加逻辑模型中不存在的物理对象:索引,约束,分区等。
    2、相信的事务不同的名称
    操作型文件系统 关系型理论 逻辑模型 物理模型
    文件(File) 关系(Relation) 实体(Entity) 表(Table)
    行记录(Record) 元组(Tuple) 实例(Instance) 行(Row)
    列记录(Field) 属性(Attribute) 属性(Attribute) 字段(Column)
    3、逻辑模型和物理模型对比(重点!!)

    LDMvs PDM

    逻辑模型 物理模型
    包含内容 实体、属性 表,字段
    键值 主键 索引,唯一性约束
    名称定义 业务名称 物理命名(受到数据库产品限制)
    正则化 符合3NF 依据性能进行非正则化处理
    冗余数据 无冗余数据 含冗余数据
    派生数据 无派生数据 含派生数据
    面向用户 业务人员和建模人员 DBA和应用开发人员

    键值:物理模型一般不使用PRIMERY KEY,更多的使用UNIQUE+NOT
    NULL约束来实现。因为用主键约束对数据质量过高,所以在物理实现上,一般会降低约束性要求,主键更多的反映在逻辑概念上。

    4、物理模型反范式处理

    从性能和应用需求出发

    • 物理模型是以性能为出发点,支持应用需求,兼顾数据库物理限制。
    • CPU无限快,内存无限多,存储无限大,带宽无限宽,还有必要反范式处理么?

    有限的资源,有限的硬件条件提出了物理模型反范式化的需求。

    反范式化:反范式处理也叫非正则化处理。 就是和范式化过程相反的过程和技术手段。把模型从第三范式降级到第二范式,或者第一范式的过程。

    反范式处理需要适度进行

    • 对于特定配置的硬件系统,在满足应用功能目标和性能指标的前提下,适度进行。
    • 带来数据冗余问题。
    • 有可能会导致数据不一致问题。

    反范式例子1:
    增加冗余列,避免频繁发生表关联操作(Join)
    在这里插入图片描述

    反范式例子2:
    增加冗余列,利用repeating group来减少SQL的复杂度。
    在前端报表应用中为了便于报表展现而采用的纵横转换。
    在这里插入图片描述

    反范式例子3:
    增加派生列,减少函数计算
    在这里插入图片描述

    5、反范式常见手段

    常见反范式化处理方式

    • 增加重复组(repeating groups)------>例子2
    • 预关联(pre-joins)----->例子1
    • 派生字段------>例子3
    • 建立汇总表或临时表
    • 表拆分(水平拆分或者垂直拆分)

    影响

    • 并非对所有处理过程都能带来性能提升,有些负面影响需要综合考虑进行平衡。
    • 反范式会降低数据模型的灵活性。
    • 带来数据不一致的风险。
    6、维护数据完整性

    反范式处理后增加了数据冗余性,需要一定的管理措施来维护数据完整性。
    批处理维护

    • 批处理维护是指对复制列或派生列的修改积累一定的时间后,运行一批处理作业或存储过程对复制或派生列进行修改,这只能在对实时性要求不高的情况下使用。
      批处理的方法是集中时间点运行批量处理作业,所以时效性不高,数据库内数据在一定时间范围内,存在有可能存在数据不一致情况;

    应用逻辑

    • 在应用实现过程中,在同一事务中对所有涉及的表进行增、删、改操作。
    • 风险较大,容易遗漏,特别是在需求变化时,不易于维护。

    应用逻辑如果出现bug,很容易造成冗余数据不一致情况,比如update A表数据之后忘记update B表里面冗余的数据了。

    触发器

    • 实时处理性高。
    • 但对于数据库压力较大,尤其是高并发环境,触发器数量需要严格控制。

    触发器实时性处理效果好,应用更新A表数据后,数据库自动触发去更新B表数据。但是触发器的代价就是会造成数据库压力

    7、对象命名规范示例
    对象 前缀 范例 说明
    t_ t_tablename t_表名
    普通视图 v_ v_viewname v_视图名
    索引 ix_ ix_tablename_columnname 这是最常用的索引,用ix_表示。如果表名或字段名过长,则用表名和字段名的缩写表示,尽量使用通用缩写或去元音的缩写方式。
    触发器 trg_ trg_triggername trg_触发器名
    存储过程 p_ p_procedurename p_存储过程名
    函数 f_ f_functionname f_函数名
    8、表的物理化

    进行反范式化操作。

    1. 决定是否要分区。
      • 对于大表进行分区,减少IO扫描量,加速范围查询。
    2. 决定是否要拆分历史表和当前表。
      • 历史表是冷数据,可以放在低速存储上;当前表是热数据,使用高速存储。
      • 历史表可以使用压缩方法减少占用的存储空间。
    9、字段的物理化
    1. 对字段选择合适的类型,包括
      尽量使用短字段的数据类型。
      使用一致的数据类型。
      选择高效数据类型。
    2. 字段的约束
    • DEFAULT
      如果能够从业务层面补全字段值,就不建议使用DEFAULT约束,避免数据加载时产生不符合预期的结果。
    • NOT NULL
      给明确不存在NULL值的字段加上NOT NULL约束。
    • 唯一约束/主键约束

    主键 = 唯一 + NOT NULL。
    如果条件允许,就增加。
    检查约束
    检查约束因为对于数据质量提出了要求,不满足约束的数据在插入数据表会导致SQL失败。

    10、索引的创建和使用

    可以增加索引的情况:(是建议)

    • 在经常需要搜索查询的列;
    • 在作为主键的列上创建索引,强制该列的唯一性;
    • 在经常使用连接的列上创建索引;
    • 在经常需要根据范围进行搜索的列上创建索引;
    • 在经常需要排序的列上创建索引;
    • 在经常使用WHERE子句的列上创建索引。

    BUT!
    索引建多了,会有负面影响

    • 占用更多的空间;
    • 插入基表数据的效率会下降。
    • 删除无效的索引,避免空间浪费
    11、其他物理化手段

    根据其他特定需求:

    • 是否采用压缩。
    • 是否需要对数据进行加密。
    • 是否需要对数据进行脱敏。

    三、数据库设计案例

    1.、逻辑模型设计

    场景客户下单购买设备,这是一个订单表的样例,客户股买设备后,订单里面填写相关信息。
    在这里插入图片描述
    可提取的属性列表:
    在这里插入图片描述
    这些属性中有重复的数据(有repeating group,连第一范式都不符合)

    那么该怎么办呢?
    

    ---------->就要消除重复组情况(正则化处理)
    在这里插入图片描述
    消除repeating groups后,现在符合第一范式

    目前存在问题是部分依赖
    ---------->所以要进行第一范式向第二范式转换(正则化处理——消除依赖部分主键)
    在这里插入图片描述
    消除部分依赖型后,现在符合第二范式

    目前存在什么问题?下一步应该如何处理?
    ------->现在存在的问题是客户信息依赖与客户编号,而客户编号依赖于订单编号,这种依赖有传递性,并不直接依赖。
    所以第二范式向第三范式转换,需要消除这种传递依赖关系
    在这里插入图片描述

    消除传递性依赖后,现在符合第三范式。
    逻辑模型基本完成。

    3NF模型 - 数据示例
    在这里插入图片描述
    在这里插入图片描述

    2、物理模型设计

    1、数据类型和长度
    在这里插入图片描述
    在这里插入图片描述

    • 前面完成3NF的逻辑模型设计之后,开始进行物理模型设计。

    • 首先是按照一定的规范对表名和字段名命名,避免使用数据库关键词,一定的大小写规范。

    • 另外就是确定字段级别的数据类型,如果牵涉到字符字段定义的长度,那么根据实际数据可能地值域确定上限范围。

    • 最后就是确定每个字段是否要增加约束,NOT NULL, UNIQUE的约束

    2、反范式化

    在这里插入图片描述

    3、索引选择

    在这里插入图片描述
    以Order , Order_Item为例,增加索引没有标准答案,还是要根据实际需求场景和数据量来判断
    在这里插入图片描述

    展开全文
  • 数据库课程设计,包含需求分析,数据流图,数据字典,概念结构,逻辑结构设计数据库物理结构设计
  • 数据库设计

    2018-01-24 17:37:08
    物理设计实例 物理设计要做什么 维护和优化 维护和优化要做什么 数据库设计优良比较 优良的设计 糟糕的设计 减少数据冗余 存在大量数据冗余 避免数据维护异常 存在数据插
  • D、物理结构设计阶段 E、数据库实施阶段 F、数据库运行与维护阶段 需求分析和概念结构设计独立于任何数据库管理系统。 二、系统需求分析 1、需求分析的任务 需求分析的任务:对现实世界要处理的对象进行详细的...
  • I 文档定义1.1 编写目的为了在软件生命周期内规范数据库相关的需求分析、设计、开发、测试、运维工作,便于不同团队之间的沟通协调,以及在相关规范上达成共识,提升相关环节的工作效率和系统的可维护性。...
  • 数据库结构设计第一节 数据库概念设计1...数据库物理结构3.索引(index)4. 第一节 数据库概念设计 引言 【1】数据库设计三步:概念设计,逻辑设计,物理设计 【2】概念设计:概念设计是由分析用户需求到生成概念产品
  • 社团管理系统数据库设计1数据库设计数据库设计是指对于一个给定的使用环境,构造优化的数据库逻辑模式和物理结构,并据此建立数据库及其使用系统,使之能够有效地存储和管理数据,满足各种用户的使用需求,包括信息...
  • 优惠券数据库结构设计

    千次阅读 2020-05-05 10:29:39
    数据库的概念结构设计 需求分析阶段所得到的应用需求应该首先抽象成信息世界的结构,才能更好地、更准确地用某一DBMS实现。 实例:ER图的设计 数据库的逻辑结构设计 ...数据库物理结构设计 数据...
  • 实际项目的数据库设计基本方法

    千次阅读 2019-08-05 22:59:05
    目录 实际项目的数据库设计基本方法 ...二、 数据库设计实例 数据库数据分析 数据库概念结构设计 数据库逻辑结构设计 数据库物理结构设计 具体教程可以参见 一、 数据库设计规范化方法 数据库设计(Database Design)...
  • 七、图书借阅管理系统设计实例 一、数据库设计概述 1、 根据用户需求设计数据库结构的过程 2、设计数据库的方法有: 直观设计方法: 规范设计法: 计算机辅助设计方法: 自动化设计方法: 3、按照规范...
  • 目录 一、概念设计 1.任务——“数据” 2.过程 3.建模方法 ...三、物理设计 1.概述 2.数据库的物理结构 3.索引技术——快速访问技术 4.有序索引 5.物理设计 6.其他 一、概念设计 ...
  • 数据库设计入门

    2018-01-10 11:17:00
    3.物理设计:选择数据库系统,并对逻辑设计进行转化 4.维护优化:追加,分拆等 实例演示(电子商务网站) 一、需求分析: 用户模块:用于登录和保存用户信息等 属性(用户名、密码、手...
  • 浅谈数据库设计

    千次阅读 2017-06-21 17:50:21
    )[+]第一章 需求分析设计简介设计步骤需求分析重要性实例小型电子商务网站第二章 逻辑设计E-R图设计范式概要第一范式1NF第二范式2NF第三范式3NF BC范式第三章 物理设计物理设计要做什么选择哪种数据库mysql常用的...
  • 数据库设计的那些事(1)需求分析(1.1)数据库设计简介(1.2)数据库设计的步骤(1.3)需求分析重要性简介(1.4)需求分析举例(1)实例讲解(2)模块分析(3)表之间关系分析(2)逻辑分析(2.1)ER图(2.2)设计...
  • 一、简介 1、数据库 物理操作系统文件,或其他形式类型文件的集合 【数据库:就是一个个文件,是文件的集合,是依照某种数据模型组织起来并存放于存放于二级存储器的...MySQL 设计成一个单进程多线程的数据库 集群...
  • 数据库设计教程(第二版),ISBN:9787111154716,作者:(美)Thomas M.Connolly,(美)Carolyn E.Begg著;...第四部分 物理数据库设计 第五部分 第二个实例 第六部分 数据库的现状和未来趋势 附录
  • 概念结构设计数据库设计的关键 现实世界->>概念模型 数据库设计人员完后曾 概念模型->逻辑模型 数据库设计人员完成 数据库设计工具协助完后曾 逻辑模型->物理模型 由DBMS完成 概念结构设计的特点 (1)...
  • 主要学习内容 详细设计的过程 详细设计阶段使用的工具 面向数据结构的设计方法 5.1 ...3物理设计数据库讲行物理设计即确定数据库的物理结构物理结构主要指数据库的存储记录格式存储记录安排和存储方法这些都依赖于具
  • 小伙伴在面试的时候,有没有被问道过:如何设计一个关系型数据库?如果你没有看过本文,又不谙此道,那肯定会慌张不易,答不到点子上。别慌,接下来我们一起来简单了解一下吧。 模块划分 如何设计一个关系型数据库?...
  • 当然是数据库的存储模块来负责存储数据 但是只有存储是不行的 还需要有程序实例 用程序的结构来映射出物理结构 第一需要对数据的格式以及文件的分割进行统一管理 便设计到了存储管理 第二为了更快更好优化程序 使用...
  • 一个关系型数据库设计考虑应从模块化考虑: 一个关系型数据库设计考虑应从模块化考虑: 首先大体上分为一:存储模块(文件存储系统,用于将数据持久化存储进入磁盘)和用于管理的所存储数据的二:程序实例部分。...
  • 二、ACTIVITI 数据库 物理图整体(5.16.4) 三、ACTIVITI 数据库 流程定义部分(三张表) 四、ACTIVITI 数据库 流程实例部分(七张表) 五、ACTIVITI 数据库 流程全局设置部分(两张表) 六、ACTIVITI 数据库 ...
  • 备份体系的支持能力粒度备份类型备份模式实例全量备份物理备份逻辑备份实例增量备份物理备份实例日志备份独立服务数据库数据表表结构对象备份物理备份逻辑备份其实对象层面的数据恢复能力是很重要的,而且对于业务侧...
  • 1.数据库逻辑结构设计和物理设计。 2.数据库对象部署和SQL代码编写。 3.数据库实例性能调整和优化。 4.操作系统性能调整和优化。 5.存储系统性能调整和优化。 6.网络系统性能调整和优化。 转载于:...

空空如也

空空如也

1 2 3 4 5 ... 15
收藏数 293
精华内容 117
热门标签
关键字:

数据库物理设计实例