Ⅰ 信息数据库用户管理规范规定了哪些原则
（一）完善管理制度，强化监管力度。数据库系统的安全与企业自身内部的安全机制、内外网络环境、从业人员素质等密切相关。因此，企业应该完善网络系统安全规章制度，防范因制度缺陷带来的风险；企业应该规范操作流程和故障处理流程，减少人为失误与故障，提高故障处理速度，缩短故障处理时间；企业应该通过建立科学合理的责任追究机制，防止出现由于工作态度、工作作风等各种人为因素导致的数据库安全事故。
（二）采取措施，确保数据库数据的安全。保证数据库数据的安全是数据库日常管理与维护工作的首要任务，企业需要采取的安全措施主要有：
（1）网络及操作系统安全。网络系统是数据库应用的外部环境和基础，网络系统安全是数据库安全的第一道屏障。从技术角度讲，网络系统层次的安全防范技术有很多种，大致可以分为防火墙、数字签名与认证、入侵检测等。操作系统是数据库系统的运行平台，能够为数据库系统提供一定程度的安全保护。
（2）操作系统的安全控制方法主要是采用隔离控制、访问控制、信息加密和审计跟踪。主要安全技术有操作系统安全策略、安全管理策略等。
（3）加强用户身份验证。用户身份验证是数据库系统的重要防线。利用窗体身份验证数据库程序的漏洞，进而获取存储在数据库中的用户身份验证密码，这是目前对网络数据库攻击最常见的方式。对此，企业信息部门通常使用带有salt值的单向密码哈希值，以避免用户密码在数据库中以明文形式存储，减轻字典攻击带来的威胁。
（4）对重要数据加密。数据加密交换又称密码学，是计算机系统对信息进行保护的一种最可靠的办法。它利用密码技术对信息进行交换，实现信息隐蔽，从而有效保护信息的安全不受侵犯。数据库加密要求加解密的粒度是每个记录的字段数据。采用库外口加密的方式，对密钥的管理较为简单，只需借用文件加密的密钥管理方法，将加密后的数据块纳入数据库，在算法或数据库系统中做些必要的改动就行。这样有利于公共数据字典的使用和维护系统的完整性。
（5）做好数据库备份与恢复。数据备份是备份数据库某个时刻的数据状态，当系统出现意外时用来恢复系统。依靠网络办公的企业，其信息系统很可能随时被破坏而丢失数据。因此，数据库管理系统必须具备把数据库从错误状态恢复到某一已知的正确状态的功能，这就是数据库的恢复技术。
（三）开展数据库健康检查。为及时发现数据库系统存在的问题，在日常管理与维护中，数据管理员要对数据库开展健康检查。检查内容主要包括以下六个方面
（1）系统环境：操作系统版本、文件系统容量、内存交换区使用率、系统性能。
（2）数据库环境：数据库和补丁版本、是否有僵尸数据库进程、数据库节点数、是否有其他数据库产品及版本。
（3）日志记录：db2diag.log报错、db2inst1.nfy报错、是否有需要处理的DUMP文件。
（4）数据库健康状况：表空间利用率和状态、表空间容器利用率和状态、排序溢出、是否需要收集统计信息、是否需要数据重组、活动日志和日志所在文件系统利用率、死锁发生率、锁升级发生率、锁等待的百分比、编目Cache命中率、包Cache命中率、监视堆利用率、数据库堆利用率、数据库缓冲池命中率。
（5）数据库维护内容：最近一次统计信息收集时间、最近一次表数据重组时间、最近一次绑定包时间、最近一次数据库备份时间。
（6）数据库基本信息记录：数据库内存使用、环境变量。
数据库的管理日常工作
（1） 每天对数据库的运行状态 , 日志文件 , 备份情况 , 数据库的空间使用情况 , 系统资源的使用情况进行检查 , 发现并解决问题。
（2）每周对数据库对象的空间扩展情况 , 数据的增长情况进行监控 , 对数据库做健康检查 , 对数据库对象的状态做检查。
（3） 每月对表和索引等进行 Analyze, 检查表空间碎片 , 寻找数据库性能调整的机会 , 进行数据库性能调整 , 提出下一步空间管理
计划。对 ORACLE 数据库状态进行一次全面检查。
数据库管理的意义重大，关系到企业信息系统的正常运作，仍至整个企业的生死存亡。要做好数据库的日常管理与维护，不仅要求数据库管理员熟悉掌握专业技术知识，还要有足够的细心和高度的责任心。
Ⅱ 数据库三大范式
数据库 的设计范式是数据库 设计所需要满足的规范，满足这些规范的数据库 是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库 的编程 人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。
设计范式是不是很难懂呢？非也，大学教材上给我们一堆数学公式我们当然看不懂，也记不住。所以我们很多人就根本不按照范式来设计数据库 。
实质上，设计范式用很形象、很简洁的话语就能说清楚，道明白。本文将对范式进行通俗地说明，并以笔者曾经设计的一个简单论坛的数据库 为例来讲解怎样将这些范式应用于实际工程。
范式说明
第一范式（1NF）：数据库 表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。
例如，如下的数据库 表是符合第一范式的：
字段1 字段2 字段3 字段4
而这样的数据库 表是不符合第一范式的：
字段1 字段2 字段3 字段4 字段3.1字段3.2
很显然，在当前的任何关系数据库 管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库 ，因为这些DBMS不允许你把数据库 表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库 都是不可能的。
第二范式（2NF）：数据库 表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。
假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：
(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
这个数据库 表不满足第二范式，因为存在如下决定关系：
(课程名称) → (学分)
(学号) → (姓名, 年龄)
即存在组合关键字中的字段决定非关键字的情况。
由于不符合2NF，这个选课关系表会存在如下问题：
(1) 数据冗余：
同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
(2) 更新异常：
若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
(3) 插入异常：
假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库 。
(4) 删除异常：
假设一批学生已经完成课程的选修，这些选修记录就应该从数据库 表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
把选课关系表SelectCourse改为如下三个表：
学生：Student(学号, 姓名, 年龄)；
课程：Course(课程名称, 学分)；
选课关系：SelectCourse(学号, 课程名称, 成绩)。
这样的数据库 表是符合第二范式的，消除了数据冗余、更新异常、插入异常和删除异常。
另外，所有单关键字的数据库 表都符合第二范式，因为不可能存在组合关键字。
第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库 表应该不存在如下依赖关系：
关键字段 → 非关键字段x → 非关键字段y
假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系：
(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)这个数据库 是符合2NF的，但是不符合3NF，因为存在如下决定关系：
(学号) → (所在学院) → (学院地点, 学院电话)
即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
它也会存在数据冗余、更新异常、插入异常和删除异常的情况，读者可自行分析得知。
把学生关系表分为如下两个表：
学生：(学号, 姓名, 年龄, 所在学院)；
学院：(学院, 地点, 电话)。
这样的数据库 表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。
鲍依斯-科得范式（BCNF）：在第三范式的基础上，数据库 表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。
假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库 表中存在如下决定关系：
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。它会出现如下异常情况：
(1) 删除异常：
当仓库被清空后，所有"存储物品ID"和"数量"信息被删除的同时，"仓库ID"和"管理员ID"信息也被删除了。
(2) 插入异常：
当仓库没有存储任何物品时，无法给仓库分配管理员。
(3) 更新异常：
如果仓库换了管理员，则表中所有行的管理员ID都要修改。
把仓库管理关系表分解为二个关系表：
仓库管理：StorehouseManage(仓库ID, 管理员ID)；
仓库：Storehouse(仓库ID, 存储物品ID, 数量)。
这样的数据库 表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。
范式应用
我们来逐步搞定一个论坛的数据库 ，有如下信息：
（1） 用户：用户名，email，主页，电话，联系地址
（2） 帖子：发帖标题，发帖内容，回复标题，回复内容
第一次我们将数据库 设计为仅仅存在表：
用户名 email 主页电话联系地址发帖标题发帖内容回复标题回复内容
这个数据库 表符合第一范式，但是没有任何一组候选关键字能决定数据库 表的整行，唯一的关键字段用户名也不能完全决定整个元组。我们需要增加"发帖ID"、"回复ID"字段，即将表修改为：
用户名email主页电话联系地址发帖ID发帖标题发帖内容回复ID回复标题回复内容
这样数据表中的关键字(用户名，发帖ID，回复ID)能决定整行：
(用户名,发帖ID,回复ID) → (email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容)
但是，这样的设计不符合第二范式，因为存在如下决定关系：
(用户名) → (email,主页,电话,联系地址)
(发帖ID) → (发帖标题,发帖内容)
(回复ID) → (回复标题,回复内容)
即非关键字段部分函数依赖于候选关键字段，很明显，这个设计会导致大量的数据冗余和操作异常。
我们将数据库 表分解为（带下划线的为关键字）：
（1） 用户信息：用户名，email，主页，电话，联系地址
（2） 帖子信息：发帖ID，标题，内容
（3） 回复信息：回复ID，标题，内容
（4） 发贴：用户名，发帖ID
（5） 回复：发帖ID，回复ID
这样的设计是满足第1、2、3范式和BCNF范式要求的，但是这样的设计是不是最好的呢？
不一定。
观察可知，第4项"发帖"中的"用户名"和"发帖ID"之间是1：N的关系，因此我们可以把"发帖"合并到第2项的"帖子信息"中；第5项"回复"中的"发帖ID"和"回复ID"之间也是1：N的关系，因此我们可以把"回复"合并到第3项的"回复信息"中。这样可以一定量地减少数据冗余，新的设计为：（1） 用户信息：用户名，email，主页，电话，联系地址
（2） 帖子信息：用户名，发帖ID，标题，内容
（3） 回复信息：发帖ID，回复ID，标题，内容
数据库 表1显然满足所有范式的要求；
数据库 表2中存在非关键字段"标题"、"内容"对关键字段"发帖ID"的部分函数依赖，即不满足第二范式的要求，但是这一设计并不会导致数据冗余和操作异常；
数据库 表3中也存在非关键字段"标题"、"内容"对关键字段"回复ID"的部分函数依赖，也不满足第二范式的要求，但是与数据库 表2相似，这一设计也不会导致数据冗余和操作异常。
由此可以看出，并不一定要强行满足范式的要求，对于1：N关系，当1的一边合并到N的那边后，N的那边就不再满足第二范式了，但是这种设计反而比较好！
对于M：N的关系，不能将M一边或N一边合并到另一边去，这样会导致不符合范式要求，同时导致操作异常和数据冗余。
对于1：1的关系，我们可以将左边的1或者右边的1合并到另一边去，设计导致不符合范式要求，但是并不会导致操作异常和数据冗余。
Ⅲ SQL编写规范
书写格式 示例代码 存储过程SQL文书写格式例selectc dealerCode round(sum(c submitSubletAmountDLR + c submitPartsAmountDLR + c submitLaborAmountDLR) / count(*) ) as avg decode(null x xx CNY )from (selecta dealerCode a submitSubletAmountDLR a submitPartsAmountDLR a submitLaborAmountDLRfrom SRV_C_F awhere (to_char(a ORIGSUBMITTIME yyyy/mm/dd ) >= Date Range(start) and to_char(a ORIGSUBMITTIME yyyy/mm/dd ) <= Date Range(end) and nvl(a deleteflag ) <> )union allselectb dealerCode b submitSubletAmountDLR b submitPartsAmountDLR b submitLaborAmountDLRfrom SRV_CHistory_F bwhere (to_char(b ORIGSUBMITTIME yyyy/mm/dd ) >= Date Range(start) and to_char(b ORIGSUBMITTIME yyyy/mm/dd ) <= Date Range(end) and nvl(b deleteflag ) <> )) cgroup by c dealerCodeorder by avg desc;Java source里的SQL字符串书写格式例strSQL = insert into Snd_FinanceHistory_Tb + (DEALERCODE + REQUESTSEQUECE + HANDLETIME + JOBFLAG + FRAMENO + INMONEY + REMAINMONEY + DELETEFLAG + UPDATECOUNT + CREUSER + CREDATE + HONORCHECKNO + SEQ) + values ( + draftInputDetail dealerCode + + + draftInputDetail requestsequece + + sysdate + + + frameNO + + requestMoney + + remainMoney + + + + + draftStruct employeeCode + + sysdate + + draftInputDetail honorCheckNo + + index + ) ; ) 缩进对于存储过程文件 缩进为 个空格对于Java source里的SQL字符串 不可有缩进 即每一行字符串不可以空格开头 ) 换行 > Select/From/Where/Order by/Group by等子句必须另其一行写 > Select子句内容如果只有一项 与Select同行写 > Select子句内容如果多于一项 每一项单独占一行 在对应Select的基础上向右缩进 个空格（Java source无缩进） > From子句内容如果只有一项 与From同行写 > From子句内容如果多于一项 每一项单独占一行 在对应From的基础上向右缩进 个空格（Java source无缩进） > Where子句的条件如果有多项 每一个条件占一行 以AND开头 且无缩进 > (Update)Set子句内容每一项单独占一行 无缩进 > Insert子句内容每个表字段单独占一行 无缩进 values每一项单独占一行 无缩进 > SQL文中间不允许出现空行 > Java source里单引号必须跟所属的SQL子句处在同一行 连接符（ + ）必须在行首 ) 空格 > SQL内算数运算符 逻辑运算符连接的两个元素之间必须用空格分隔 > 逗号之后必须接一个空格 > 关键字 保留字和左括号之间必须有一个空格 不等于统一使用 <> Oracle认为 != 和 <> 是等价的 都代表不等于的意义 为了统一 不等于一律使用 <> 表示 使用表的别名 数据库查询 必须使用表的别名 SQL文对表字段扩展的兼容性 在Java source里使用Select *时 严禁通过getString( )的形式得到查询结果 必须使用getString( 字段名 )的形式使用Insert时 必须指定插入的字段名 严禁不指定字段名直接插入values 减少子查询的使用 子查询除了可读性差之外 还在一定程度上影响了SQL运行效率请尽量减少使用子查询的使用 用其他效率更高 可读性更好的方式替代 适当添加索引以提高查询效率 适当添加索引可以大幅度的提高检索速度请参看ORACLE SQL性能优化系列 对数据库表操作的特殊要求 本项目对数据库表的操作还有以下特殊要求 ) 以逻辑删除替代物理删除注意 现在数据库表中数据没有物理删除 只有逻辑删除以deleteflag字段作为删除标志 deleteflag= 代表此记录被逻辑删除 因此在查询数据时必须考虑deleteflag的因素deleteflag的标准查询条件 NVL(deleteflag ) <> ) 增加记录状态字段数据库中的每张表基本都有以下字段 DELETEFLAG UPDATECOUNT CREDATE CREUSER UPDATETIME UPDATEUSER要注意在对标进行操作时必须考虑以下字段插入一条记录时要置DELETEFLAG= UPDATECOUNT= CREDATE=sysdate CREUSER=登录User查询一条记录时要考虑DELETEFLAG 如果有可能对此记录作更新时还要取得UPDATECOUNT作同步检查修改一条记录时要置UPDATETIME=sysdate UPDATEUSER=登录User UPDATECOUNT=(UPDATECOUNT+ ) mod 删除一条记录时要置DELETEFLAG= ) 历史表数据库里部分表还存在相应的历史表 比如srv_c_f和srv_chistory_f在查询数据时除了检索所在表之外 还必须检索相应的历史表 对二者的结果做Union（或Union All） 用执行计划分析SQL性能 EXPLAIN PLAN是一个很好的分析SQL语句的工具 它可以在不执行SQL的情况下分析语句通过分析 我们就可以知道ORACLE是怎样连接表 使用什么方式扫描表（索引扫描或全表扫描） 以及使用到的索引名称按照从里到外 从上到下的次序解读分析的结果EXPLAIN PLAN的分析结果是用缩进的格式排列的 最内部的操作将最先被解读 如果两个操作处于同一层中 带有最小操作号的将首先被执行目前许多第三方的工具如PLSQL Developer和TOAD等都提供了极其方便的EXPLAIN PLAN工具PG需要将自己添加的查询SQL文记入log 然后在EXPLAIN PLAN中进行分析 尽量减少全表扫描 ORACLE SQL性能优化系列 选择最有效率的表名顺序(只在基于规则的优化器中有效) ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名 因此FROM子句中写在最后的表（基础表driving table）将被最先处理在FROM子句中包含多个表的情况下 必须选择记录条数最少的表作为基础表当ORACLE处理多个表时 会运用排序及合并的方式连接它们首先 扫描第一个表（FROM子句中最后的那个表)并对记录进行排序 然后扫描第二个表（FROM子句中最后第二个表) 最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并例如:表 TAB 条记录表 TAB 条记录选择TAB 作为基础表 (最好的方法)select count(*) from tab tab 执行时间 秒选择TAB 作为基础表 (不佳的方法)select count(*) from tab tab 执行时间 秒如果有 个以上的表连接查询 那就需要选择交叉表（intersection table）作为基础表 交叉表是指那个被其他表所引用的表例如:EMP表描述了LOCATION表和CATEGORY表的交集SELECT *FROM LOCATION L CATEGORY C EMP EWHERE E EMP_NO BEEEN AND AND E CAT_NO = C CAT_NOAND E LOCN = L LOCN将比下列SQL更有效率SELECT *FROM EMP E LOCATION L CATEGORY CWHERE E CAT_NO = C CAT_NOAND E LOCN = L LOCNAND E EMP_NO BEEEN AND WHERE子句中的连接顺序 ORACLE采用自下而上的顺序解析WHERE子句根据这个原理 表之间的连接必须写在其他WHERE条件之前 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾例如 (低效 执行时间 秒)SELECT *FROM EMP EWHERE SAL > AND JOB = MANAGER AND < (SELECT COUNT(*) FROM EMP WHERE MGR=E EMPNO);(高效 执行时间 秒)SELECT *FROM EMP EWHERE < (SELECT COUNT(*) FROM EMP WHERE MGR=E EMPNO)AND SAL > AND JOB = MANAGER ; SELECT子句中避免使用 * 当你想在SELECT子句中列出所有的COLUMN时 使用动态SQL列引用 * 是一个方便的方法 不幸的是 这是一个非常低效的方法实际上 ORACLE在解析的过程中 会将 * 依次转换成所有的列名这个工作是通过查询数据字典完 lishixin/Article/program/Oracle/201311/18246
Ⅳ 数据库系统管理规范
管理规范这个要根据实际情况，数据库类型，数据量，数据流，等等来制订！！
这个需要经验，没有固定的模板，但你可以在网上找一些有这方面经验的人的文章来做参考！！
----上面说了相当于没说！仅仅做个标记！：）
Ⅳ 一个完整的数据库包含哪些数据库文件，其中哪些是在一个数据库中必须存在的
分为“主要文件，次要文件，事物日志文件”，其中“主要文件和事物日志文件”是必须存在的。
Ⅵ 数据库中为什么要对关系模式进行规范化
关系模式进行规范化的目地：规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小，便于插入、删除和更新
关系模式进行规范化的原则：遵从概念单一化 "一事一地"原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
关系模式进行规范化的方法：将关系模式投影分解成两个或两个以上的关系模式。
要求：分解后的关系模式集合应当与原关系模式"等价"，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。
注意：一个关系模式结这分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。
Ⅶ 为什么数据库规范化处理
通常情况下，可以从两个方面来判断数据库是否设计的比较规范。一是看看是否拥有大量的窄表，二是宽表的数量是否足够的少。若符合这两个条件，则可以说明这个数据库的规范化水平还是比较高的。当然这是两个泛泛而谈的指标。为了达到数据库设计规范化的要求，一般来说，需要符合以下五个要求。
要求一：表中应该避免可为空的列。
虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。数据库在处理的时候，需要进行特殊的处理。如此的话，就会增加数据库处理记录的复杂性。当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。
所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。若确实需要的话，我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。
一是通过设置默认值的形式，来避免空字段的产生。如在一个人事管理系统中，有时候身份证号码字段可能允许为空。因为不是每个人都可以记住自己的身份证号码。而在员工报到的时候，可能身份证没有带在身边。所以，身份证号码字段往往不能及时提供。为此，身份证号码字段可以允许为空，以满足这些特殊情况的需要。但是，在数据库设计的时候，则可以做一些处理。如当用户没有输入内容的时候，则把这个字段的默认值设置为0或者为N/A。以避免空字段的产生。
二是若一张表中，允许为空的列比较多，接近表全部列数的三分之一。而且，这些列在大部分情况下，都是可有可无的。若数据库管理员遇到这种情况，笔者建议另外建立一张副表，以保存这些列。然后通过关键字把主表跟这张副表关联起来。将数据存储在两个独立的表中使得主表的设计更为简单，同时也能够满足存储空值信息的需要。
要求二：表不应该有重复的值或者列。
为了解决这个问题，有多种实现方式。但是，若设计不合理的话在，则会导致重复的值或者列。如我们也可以这么设计，把客户信息、联系人都放入同一张表中。为了解决多个联系人的问题，可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。若还有第三联系人、第四联系人等等，则往往还需要加入更多的字段。
所以，在数据库设计的时候要尽量避免这种重复的值或者列的产生。笔者建议，若数据库管理员遇到这种情况，可以改变一下策略。如把客户联系人另外设置一张表。然后通过客户ID把供应商信息表跟客户联系人信息表连接起来。也就是说，尽量将重复的值放置到一张独立的表中进行管理。然后通过视图或者其他手段把这些独立的表联系起来。
要求三：表中记录应该有一个唯一的标识符。
在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个ID号来唯一的标识行记录，而不要通过名字、编号等字段来对纪录进行区分。每个表都应该有一个ID列，任何两个记录都不可以共享同一个ID值。另外，这个ID值最好有数据库来进行自动管理，而不要把这个任务给前台应用程序。否则的话，很容易产生ID值不统一的情况。
要求四：数据库对象要有统一的前缀名。
一个比较复杂的应用系统，其对应的数据库表往往以千计。若让数据库管理员看到对象名就了解这个数据库对象所起的作用，恐怕会比较困难。而且在数据库对象引用的时候，数据库管理员也会为不能迅速找到所需要的数据库对象而头疼。
其次，表、视图、函数等最好也有统一的前缀。如视图可以用V为前缀，而函数则可以利用F为前缀。如此数据库管理员无论是在日常管理还是对象引用的时候，都能够在最短的时间内找到自己所需要的对象。
要求五：尽量只存储单一实体类型的数据。
这里将的实体类型跟数据类型不是一回事，要注意区分。这里讲的实体类型是指所需要描述对象的本身。笔者举一个例子，估计大家就可以明白其中的内容了。如现在有一个图书馆里系统，有图书基本信息、作者信息两个实体对象。若用户要把这两个实体对象信息放在同一张表中也是可以的。如可以把表设计成图书名字、图书作者等等。可是如此设计的话，会给后续的维护带来不少的麻烦。
遇到这种情况时，笔者建议可以把上面这张表分解成三种独立的表，分别为图书基本信息表、作者基本信息表、图书与作者对应表等等。如此设计以后，以上遇到的所有问题就都引刃而解了。
以上五条是在数据库设计时达到规范化水平的基本要求。除了这些另外还有很多细节方面的要求，如数据类型、存储过程等等。而且，数据库规范往往没有技术方面的严格限制，主要依靠数据库管理员日常工作经验的累积。