免费智能真题库 > 历年试卷 > 系统架构设计师 > 2021年下半年 系统架构设计师 下午试卷 案例
  第2题      
  知识点:   MySQL   Redis   关系数据库   规范化   数据管理   数据库

 
某医药销售企业因业务发展,需要建立线上药品销售系统,为用户提供便捷的互联网药品销售服务、该系统除了常规药品展示、订单、用户交流与反馈功能外,还需要提供当前热销产品排名、评价分类管理等功能。通过对需求的分析,在数据管理上初步决定采用关系数据库MySQL)和数据库缓存(Redis)的混合架构实现。
经过规范化设计之后,该系统的部分数据库表结构如下所示。
供应商(供应商ID,供应商名称,联系方式,供应商地址);
药品(药品ID,药品名称,药品型号,药品价格,供应商ID);
药品库存(药品ID,当前库存数量);
订单(订单号码,药品ID,供应商ID,药品数量,订单金额)。
 
问题:2.1    (9分)
在系统初步运行后,发现系统数据访问性能较差。经过分析,刘工认为原来数据库规范化设计后,关系表过于细分,造成了大量的多表关联查询,影响了性能。例如当用户查询商品信息时,需要同时显示该药品的信息、供应商的信息、当前库存等信息。
为此,刘工认为可以采用反规范化设计来改造药品关系的结构,以提高查询性能。修改后的药品关系结构为:
药品(药品ID,药品名称,药品型号,药品价格,供应商ID,供应商名称,当前库存数量) ;
请用200字以内的文字说明常见的反规范化设计方法,并说明用户查询商品信息应该采用哪种反规范化设计方法。
 
问题:2.2    (9分)
王工认为,反规范化设计可提高查询的性能,但必然会带来数据的不一致性问题。请用200字以内的文字说明在反规范化设计中,解决数据不一致性问题的三种常见方法,并说明该系统应该采用哪种方法。
 
问题:2.3    (7分)
该系统采用了Redis来实现某些特定功能(如当前热销药品排名等),同时将药品关系数据放到内存以提高商品查询的性能,但必然会造成Redis和MySQL的数据实时同步问题。
(1) Redis的数据类型包括String、 Hash、 List、 Set和ZSet等,请说明实现当前热销药品排名的功能应该选择使用哪种数据类型。
(2)请用200字以内的文字解释说明解决Redis和MySQL数据实时同步问题的常见方案。
 
 
 

   知识点讲解    
   · MySQL    · Redis    · 关系数据库    · 规范化    · 数据管理    · 数据库
 
       MySQL
        MySQL是一个开放源码的小型关联式数据库管理系统,开发者为瑞典MySQL AB公司。MySQL被广泛地应用在Internet上的中小型网站中。由于其体积小、速度快、总体拥有成本低,尤其是开放源码这一特点,许多中小型网站为了降低网站总体拥有成本而选择了MySQL作为网站数据库。
 
       Redis
        Redis是一种主要基于内存存储和运行,能够快速响应的键值数据库,属于临时和永久兼具类型,有点像Memcached,整个数据库统统加载在内存当中进行操作,但是通过定期异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作,Redis的性能非常出色,每秒可以处理超过10万次读写操作。
        Redis的出色之处不仅仅是性能,Redis最大的魅力是支持保存List链表和Set集合的数据结构,而且还支持对List进行各种操作。此外单个value的最大限制是1GB,不像Memcached只能保存1MB的数据。其主要缺点是数据库容易受到物理内存的限制,不能用作海量数据的高性能读写,并且它没有原生的可扩展机制,不具有扩展能力,要依赖客户端来实现分布式读写,因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
        将传统关系型数据库、MongoDB和Redis的特点做一个简单对比。如下表所示,读写响应性能上,传统关系型数据库一般,MongoDB类似于磁盘读写的NoSQL数据库速度较快,基于内存存储的Redis数据库最快。但是传统关系型数据库应用范围广泛,后两者以互联网应用为主。在当前互联网环境下,许多大型网站需要这种处理高并发和高响应的内存数据应用。
        
        传统关系型数据库和MongoDB、Redis的比较
        Redis的数据库存储模式,是基于键值(Key-Value)基本存储原理,进行细化分类,构建了具有自身特点的数据结构类型。像MySQL这样的关系型数据库,表的结构比较复杂,会包含很多字段,可以通过SQL语句,来实现非常复杂的查询需求。而Redis客户只包含“键”和“值”两部分,只能通过“键”来查询“值”。正是因为这样简单的存储结构,也让Redis的读写效率非常高。键的数据类型是字符串,但是为了丰富数据存储的方式,方便开发者使用,值的数据类型很多,它们分别是字符串、列表、字典、集合、有序集合。在对数据进行各种命令操作之前,首先要掌握Redis的数据结构类型特点。
        字符串是Redis数据库最简单的数据结构,形式如下表所示,字符串值的内容是二进制的,意味着可以把数字、文本、图片、视频等都赋给这个值,最大长度不能超过512MB。键名的命名要容易阅读,方便系统维护;键名不要太长,否则会影响数据库执行效率。
        
        Redis的字符串结构
        列表由若干插入顺序的字符串组成,支持存储一组数据。这种数据类型对应两种实现方法,一种是压缩列表,另一种是双向循环链表。列表中存储的数据量比较小的时候,列表就可以采用压缩列表的方式实现。压缩列表由Redis自己设计实现,类似于数组,通过一片连续的内存空间存储数据,在读写操作时只能从其两头开始(由链表的寻址方式所决定)。不过,它跟数组不同的一点是Redis允许存储的数据大小不同。如下表所示,将700010看作表头的第一个结点字符串数据,结尾是700012字符串。值的内容允许重复出现。列表可用于聊天记录、博客评论等无需调整字符串顺序但又需要快速响应的场景。
        
        Redis的列表结构
        集合是由不重复且无序的字符串元素组成的整体,结构如下表所示,集合与列表最主要的区别是,集合里面所有字符串是唯一的;所有字符串的读写顺序是任意的,不存在从两头操作的问题。
        
        Redis的集合结构
        散列表可以存储多个键值对的映射,是无序的一种数据集合。只有在数据存储数据量比较小的情况下,Redis才使用散列表进行操作,如下表所示。键的内容必须是唯一的,不能重复,且字符串不宜过长,以免占用过多内存,影响执行效率。使用“:”等隔离符号增加可读性,并给使用者提供更大的存储空间。值可以是字符串类型也可以是数字型。散列表特别适用于存储一个对象,会占更少的内存,并且方便存取整个对象。
        
        Redis的散列结构
        有序集合的键被称为成员(member),每个成员都是各不相同的。有序集合的值则被称为分值(score),分值必须为浮点数。有序集合是Redis里面唯一一个既可以根据成员访问元素,又可以根据分值以及分值的排列顺序访问元素的结构,如下表所示。有序集合的值自动进行排序,键字符串必须唯一,值可以重复。由于采用自动值排序,在数据量较多的情况下,检索速度比散列表快。
        
        Redis的有序集合结构
 
       关系数据库
               关系模型概述
               关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。关系模型的数据结构单一,现实世界的实体以及实体间的各种联系均用关系来表示。在用户看来,关系模型中数据的逻辑结构是一张二维表。关系模型中常用的关系操作包括选择、投影、连接、除、并、交、差等查询操作,和增加、删除、修改操作两大部分。早期的关系操作能力通常用关系代数和关系演算来表示,关系代数是用对关系的运算来表达查询要求的方式,关系演算是用谓词来表达查询要求的方式。另外还有一种介于关系代数和关系演算之间的语言SQL,它不仅具有丰富的查询功能,而且具有数据定义和数据控制功能,是关系数据库的标准语言。
               关系数据结构及形式化定义
               首先介绍一些概念:
               (1)域(Domain):域是一组具有相同数据类型的值的集合。
               (2)笛卡尔积(Cartesian Product):给定一组域D1, D2,…,Dn,这些域中可以有相同的。D1,D2,…,Dn的笛卡尔积为:D1×D2×…×Dn={(d1,d2,…,dn) |di∈Di, i=1,2,…,n}其中每一个元素(d1,d2,…,dn)叫做一个n元组或简称元组。元素中的每一个值di叫做一个分量。笛卡尔积可以用来表示二维表,表中的每行对应一个元组,每列对应一个域。
               (3)关系(Relation):D1×D2×…×Dn的子集叫做在域D1,D2,…,Dn上的关系,表示为R (D1, D2,…,Dn),这里R表示关系的名字,n是关系的目或度(Degree),关系中的每个元素是关系中的元组。
               关系是笛卡尔积的有限子集,所以关系也是一个二维表,表的每行对应一个元组,表的每列对应一个域。一个元组就是该关系所涉及的属性集的笛卡尔积的一个元素。由于在笛卡尔积的定义中,域是可以相同的,所以为了加以区分,必须对每个列起一个名字,称之为属性,n目关系必须有n个属性。若关系中的某一属性组的值能够唯一标识一个元组,则称该属性组为候选码(Candidate Key)。若一个关系有多个候选码,则选定其中之一为主码(Primary Key)。主码的各个属性称为主属性(Prime Attribute)。不包含在任何候选码中的属性称为非码属性(Non-key Attribute)。当关系模式的所有属性组是这个关系模式的候选码时,称为全码(All-Key)。
               关系的完整性
               (1)实体完整性。
               若属性A是基本关系R的主属性,则属性A不能取空值。也就是说基本关系得所有主属性都不能取空值,而不仅是主码整体不能取空值。
               (2)参照完整性。
               现实世界中的实体之间往往存在某种联系,在关系模型中实体之间的联系用关系描述,这样就会存在着关系间的引用。例如,学生、课程、选课三个关系如下:
               学生(学号,姓名,性别,专业)
               课程(课程号,课程名,教师,学分)
               选课(学号,课程号,成绩)
               它们之间是多对多联系,存在着属性的引用,即选课关系引用了学生关系的主码和课程关系的主码,如画线所示。在选课关系中必须满足:①选课关系中的“学号”值必须是确实存在的学生的学号,即在学生关系中有该学生的记录;②选课关系中“课程号”也必须确实存在,即课程关系中有该课程的记录。也就是说,选课关系中某些属性的取值需要参照其他关系的属性的取值。
               设F是基本关系R的一个或一组属性,但不是关系R的码。如果F与基本关系S的主码KS相对应,则称F是基本关系R的外码,并称基本关系R为参照关系,基本关系S为被参照关系或目标关系,关系R和S不一定是不同的关系。在上例中,“学号”和“课程号”是选课关系的外码,学生关系和课程关系是被参照关系,选课关系是参照关系。
               参照完整性规则:若属性(或属性组)F是基本关系R的外码,它与基本关系S的主码KS相对应(关系R和S不一定是不同的关系),则对于R中每个元组在F上的值或者取空值或者等于S中某个元组的主码值。
               (3)用户定义的完整性
               用户定义的完整性就是针对某一具体关系数据库的约束条件。例如属性的取值范围、属性间必须满足一定的函数关系等。
 
       规范化
        关系数据库设计的方法之一就是设计满足适当范式的模式,通常可以通过判断分解后的模式达到几范式来评价模式规范化的程度。范式有:1NF、2NF、3NF、BCNF、4NF和5NF,其中1NF级别最低。这几种范式之间成立。
        通过分解,可以将一个低一级范式的关系模式转换成若干个高一级范式的关系模式,这种过程叫作规范化。下面将给出各个范式的定义。
               1NF(第一范式)
               【定义7.10】若关系模式R的每一个分量是不可再分的数据项,则关系模式R属于第一范式。记为R∈1NF。
               例如,供应者和它所提供的零件信息,关系模式FIRST和函数依赖集F如下:
               FIRST(Sno,Sname,Status,City,Pno,Qty)
               F={Sno→Sname,Sno→Status,Status→City,(Sno,Pno)→Qty}
               对具体的关系FIRST如下表所示。从下表中可以看出,每一个分量都是不可再分的数据项,所以是1NF的。但是,1NF存在4个问题:
               
               FIRST
               (1)冗余度大。例如每个供应者的Sno、Sname、Status、City要与其供应的零件的种类一样多。
               (2)引起修改操作的不一致性。例如供应者S1从“天津”搬到“上海”,若不注意,会使一些数据被修改,另一些数据未被修改,导致数据修改的不一致性。
               (3)插入异常。关系模式FRIST的主码为Sno、Pno,按照关系模式实体完整性规定主码不能取空值或部分取空值。这样,当某个供应者的某些信息未提供时(如Pno),则不能进行插入操作,这就是所谓的插入异常。
               (4)删除异常。若供应商S4的P2零件销售完了,并且以后不再销售P2零件,那么应删除该元组。这样,在基本关系FIRST找不到S4,可S4又是客观存在的。
               正因为上述4个原因,所以要对模式进行分解,并引入了2NF。
               2NF(第二范式)
               【定义7.11】若关系模式R∈1NF,且每一个非主属性完全依赖于码,则关系模式R∈2NF。
               换句话说,当1NF消除了非主属性对码的部分函数依赖,则称为2NF。
               例如,FIRST关系中的码是Sno、Pno,而Sno→Status,因此非主属性Status部分函数依赖于码,故非2NF的。
               若此时,将FIRST关系分解为:
               FIRST1(Sno,Sname,Status,City)∈ 2NF
               FIRST2(Sno,Pno,Qty)∈2NF
               因为分解后的关系模式FIRST1的码为Sno,非主属性Sname、Status、City完全依赖于码Sno,所以属于2NF;关系模式FIRST2的码为Sno、Pno,非主属性Qty完全依赖于码,所以也属于2NF。
               3NF(第三范式)
               【定义7.12】若关系模式R(U,F)中不存在这样的码X,属性组Y及非主属性使得X→Y,成立,则关系模式R∈3NF。
               即当2NF消除了非主属性对码的传递函数依赖,则称为3NF。
               例如,FIRST1?3NF,因为在分解后的关系模式FIRST1中有Sno→Status,Status→City,存在着非主属性City传递依赖于码Sno。若此时将FIRST1继续分解为:
               FIRST11(Sno,Sname,Status)∈ 3NF
               FIRST12(Status,City)∈3NF
               通过上述分解,数据库模式FIRST转换为FIRST11(Sno,Sname,Status)、FIRST12(Status,City)、FIRST2(Sno,Pno,Qty)三个子模式。由于这三个子模式都达到了3NF,因此称分解后的数据库模式达到了3NF。
               可以证明,3NF的模式必是2NF的模式。产生冗余和异常的两个重要原因是部分依赖和传递依赖。因为3NF模式中不存在非主属性对码的部分函数依赖和传递函数依赖,所以具有较好的性能。对于非3NF的1NF、2NF其性能弱,一般不宜作为数据库模式,通常要将它们变换成为3NF或更高级别的范式,这种变换过程称为“关系模式的规范化处理”。
               BCNF(Boyce Codd Normal Form,巴克斯范式)
               【定义7.13】关系模式R∈1NF,若X→Y且时,X必含有码,则关系模式R∈BCNF。
               也就是说,当3NF消除了主属性对码的部分函数依赖和传递函数依赖,则称为BCNF。
               结论:一个满足BCNF的关系模式,应有如下性质。
               (1)所有非主属性对每一个码都是完全函数依赖。
               (2)所有非主属性对每一个不包含它的码,也是完全函数依赖。
               (3)没有任何属性完全函数依赖于非码的任何一组属性。
               例如,设R(Pno,Pname,Mname)的属性分别表示零件号、零件名和厂商名,如果约定,每种零件号只有一个零件名,但不同的零件号可以有相同的零件名;每种零件可以有多个厂商生产,但每家厂商生产的零件应有不同的零件名。这样我们可以得到如下一组函数依赖:
               Pno→Pname,(Pname,Mname)→Pno
               由于该关系模式R中的候选码为(Pname,Mname)或(Pno,Mname),因而关系模式R的属性都是主属性,不存在非主属性对码的传递依赖,所以R是3NF的。但是,主属性Pname传递依赖于码(Pname,Mname),因此R不是BCNF的。当一种零件由多个生产厂家生产时,零件名与零件号间的联系将多次重复,带来冗余和操作异常现象。若将R分解成:
               R1(Pno,Pname)和R2(Pno,Mname)
               就可以解决上述问题,并且分解后的关系模式R1、R2都属于BCNF。
               4NF(第四范式)
               【定义7.14】关系模式R∈1NF,若对于R的每个非平凡多值依赖X→→Y且时,X必含有码,则关系模式R(U,F)∈4NF。
               4NF是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖。
               注意:如果只考虑函数依赖,关系模式最高的规范化程度是BCNF;如果考虑多值依赖,关系模式最高的规范化程度是4NF。
               连接依赖5NF
               连接依赖:当关系模式无损分解为n个投影(n>2)会产生一些特殊的情况。下面考虑供应商数据库中SPJ关系的一个具体的值,如下图所示。
               
               关系SPJ是三个二元投影的连接
               第一次SP、PJ投影连接“”起来的结果比原始SPJ关系多了一个元组“S2,P1,J2”,即上图中带下画线的元组。第二次连接的结果去掉了多余的元组,从而恢复了原始的关系SPJ。在这种情况下,原始的SPJ关系是可3分解的。注意,无论我们选择哪两个投影作为第一次连接,结果都是一样的,尽管在每种情况下中间结果不同。
               SPJ的可3分解性是基本与时间无关的特性,是关系模式的所有合法值满足的特性,也就是说,这是关系模式满足一个特定的与时间无关的完整性约束。将这种约束简称为3D(3分解)约束。上述情况就是连接依赖要研究的问题。
               连接依赖:如果给定一个关系模式R,R1,R2,R3,…,Rn是R的分解,那么称R满足连接依赖JD*{R1,R2,R3,…,Rn},当且仅当R的任何可能出现的合法值都与它在R1,R2,R3,…,Rn上的投影等价。
               形式化地说,若R=R1∪R2∪…∪Rn,且,则称R满足连接依赖JD*{R1,R2,R3,…,Rn}。如果某个Ri,就是R本身,则连接依赖是平凡的。
               为了进一步理解连接依赖的概念,我们考虑银行数据库中的子模式:贷款(L-no,Bname,C-name,amount)。其中:
               .贷款号为L-no的贷款是由机构名为Bname贷出的。
               .贷款号为L-no的贷款是贷给客户名为C-name的客户。
               .贷款号为L-no的贷款的金额是amount。
               我们可以看到这是一个非常直观的逻辑蕴涵连接依赖:
               JD*((L-no,Bname),(L-no,C-name),(L-no,amount))
               这个例子说明了连接依赖很直观,符合数据库设计的原则。
               【定义7.15】一个关系模式R是第五范式(也称投影-连接范式PJNF),当且仅当R的每一个非平凡的连接依赖都被R的候选码所蕴涵,记作5NF。
               “被R的候选码所蕴涵”的含义可通过SPJ关系来理解。关系模式SPJ并不是5NF的,因为它满足一个特定连接依赖,即3D约束。这显然没有被其唯一的候选码(该候选码是所有属性的组合)所蕴涵。其区别是,关系模式SPJ并不是5NF,因为它是可被3分解的,可3分解并没有为其(Sno,Pno,Jno)候选码所蕴涵。但是将SPJ3分解后,由于3个投影SP、PJ、JS不包括任何(非平凡的)连接依赖,因此它们都是5NF的。
 
       数据管理
               数据生命周期
               在数据的整个生命周期中,不同的数据需要不同水平的性能、可用性、保护、迁移、保留和处理。通常情况下,在其生命周期的初期,数据的生成和使用都需要利用高速存储,并相应地提供高水平的保护措施,以达到高可用性和提供相当等级的服务水准。随着时间的推移,数据的重要性会逐渐降低,使用频率也会随之下降。伴随着这些变化的发生,企业就可以将数据进行不同级别的存储,为其提供适当的可用性、存储空间、成本、性能和保护,并且在整个生命周期的不同阶段都能对数据保留进行管理。
               数据的安全性管理是数据生命周期中的一个比较重要的环节。在进行数据输入和存取控制的时候,企业必须首先保证输入数据的数据合法性。要保证数据的安全性,必须保证数据的保密性和完整性,主要表现在以下5个方面:
               (1)用户登录时的安全性。从用户登录网络开始,对数据的保密性和完整性的保护就应该开始了。
               (2)网络数据的保护。包括在本地网络上的数据或者穿越网络的数据。在本地网络的数据是由验证协议来保证其安全性的。
               (3)存储数据以及介质的保护。可以采用数字签名来签署软件产品(防范运行恶意的软件),或者加密文件系统。
               (4)通信的安全性。提供多种安全协议和用户模式的、内置的集成支持。
               (5)企业和Internet网的单点安全登录。
               随着时间的推移,大部分数据将不再会被用到。一般情况下,一些无用的数据将被删除以节省空间,或者将有用的数据无限期地存储,以避免数据损失。
               信息资源管理
               信息资源管理(Information Resource Management,IRM)是对整个组织信息资源开发利用的全面管理。IRM把经济管理和信息技术结合起来,使信息作为一种资源而得到优化地配置和使用。上次我们在谈企业信息化的任务时,说开发信息资源既是企业信息化的出发点,又是企业信息化的归宿;只有高档次的数据环境才能发挥信息基础设施作用、建立集成化的信息系统、落实信息资源的开发和利用。因此,从IRM的技术侧面看,数据环境建设是信息资源管理的重要工作。
               企业信息资源管理不是把资源整合起来就行了,而是需要一个有效的信息资源管理体系,其中最为关键的是从事信息资源管理的人才队伍建设;其次,是架构问题,在信息资源建设阶段,规划是以建设进程为主线的,在信息资源管理阶段,规划应是以架构为主线,主要涉及的是这个信息化运营体系的架构,这个架构要消除以往分散建设所导致的信息孤岛,实现大范围内的信息共享、交换和使用,提升系统效率,达到信息资源的最大增值;技术也是一个要素,要选择与信息资源整合和管理相适应的软件和平台;另外一个就是环境要素,主要是指标准和规范,信息资源管理最核心的基础问题就是信息资源的标准和规范。
               数据管理
               企业信息资源开发利用做得好坏的关键人物是企业领导和信息系统负责人。IRM工作层上的最重要的角色就是数据管理员(Data Administrator, DA)。数据管理员负责支持整个企业目标的信息资源的规划、控制和管理;协调数据库和其他数据结构的开发,使数据存储的冗余最小而具有最大的相容性;负责建立有效使用数据资源的标准和规程,组织所需要的培训;负责实现和维护支持这些目标的数据字典;审批所有对数据字典做的修改;负责监督数据管理部门中的所有职员的工作。数据管理员应能提出关于有效使用数据资源的整治建议,向主管部门提出不同的数据结构设计的优缺点忠告,监督其他人员进行逻辑数据结构设计和数据管理。
               数据管理员还需要有良好的人际关系:善于同中高层管理人员一起制定信息资源的短期和长期计划。在数据结构的研制、建立文档和维护过程中,能与项目领导、数据处理人员和数据库管理员协同工作。能同最终用户管理部门一起工作,为他们提供有关数据资源的信息。
               一般来说,由数据管理员对日常数据进行更新和维护。数据库为了保证存储在其中的数据的安全和一致,必须有一组软件来完成相应的管理任务,这组软件就是数据库管理系统,简称DBMS, DBMS随系统的不同而不同,但是一般来说,它应该包括数据库描述功能、数据库管理功能、数据库的查询和操纵功能、数据库维护功能等。为了提高数据库系统的开发效率,现代数据库系统除了DBMS之外,还提供了各种支持应用开发的工具。
               目前许多厂商提供了相应的DBMS,便于数据管理员对底层的数据进行维护。例如MySQL、东软的OpenBase、金仓的KingbaseES等。
               公司级的数据管理
               如何进行信息资源规划?信息资源规划主要可以概括为“建立两种模型和一套标准”。“两种模型”是指信息系统的功能模型和数据模型,“一套标准”是指信息资源管理基础标准。信息系统的功能模型和数据模型,实际上是用户需求的综合反映和规范化表达;信息资源管理基础标准是进行信息资源开发利用的最基本的标准,这些标准都要体现在数据模型之中。
               企业信息化的最终目标是实现各种不同业务信息系统间跨地域、跨行业、跨部门的信息共享和业务协同,而信息共享和业务协同则是建立在信息使用者和信息拥有者对共享数据的涵义、表示及标识有着相同的而无歧义的理解基础上。然而,由于各部门、各行业及各应用领域对于相同的数据概念有着不同的功能需求和不同的描述,从而导致了数据的不一致性。数据的不一致性主要表现为:数据名称的不一致性、数据长度的不一致性、数据表示的不一致性以及数据含义的不统一性。
               数据标准化是一种按照预定规程对共享数据实施规范化管理的过程。数据标准化的对象是数据元素和元数据。数据元素是通过定义、标识、表示以及允许值等一系列属性描述的数据单元,是数据库中表达实体及其属性的标识符。在特定的语义环境中,数据元素被认为是不可再分的最小数据单元。元数据是描述数据元素属性(即语义内容)的信息,并被存储在数据元素注册系统(又称数据字典)中。数据元素注册系统通过对规范化的数据元素及其属性(即元数据)的管理,可以有效实现用户跨系统和跨环境的数据共享。数据标准化主要包括业务建模阶段、数据规范化阶段、文档规范化阶段等三个阶段。
               数据标准化是建立在对现实业务过程全面分析和了解的基础上的,并以业务模型为基础的。业务建模阶段是业务领域专家和业务建模专家按照《业务流程设计指南》,利用业务建模技术对现实业务需求、业务流程及业务信息进行抽象分析的过程,从而形成覆盖整个业务过程的业务模型。该阶段着重对现实业务流程的分析和研究,尤其需要业务领域专家的直接参与和指导。业务模型是某个业务过程的图形表示或一个设计图。
               数据规范化阶段是数据标准化的关键和核心,该阶段是针对数据元素进行提取、规范化及管理的过程。数据元素的提取离不开对业务建模阶段成果的分析,通过研究业务模型能够获得业务的各个参与方、确定业务的实施细则、明确数据元素对应的信息实体。该阶段是业务领域专家和数据规范化专家按照《数据元素设计与管理规范》利用数据元素注册系统(或数据字典)对业务模型内的各种业务信息实体进行抽象、规范化和管理的过程,从而形成一套完整的标准数据元素目录。在实现数据元素标准化的同时,还应关注数据元素取值的规范化,以此实现信息表示和信息处理的标准化。
               文档规范化阶段是数据规范化成果的实际应用的关键,是实现离散数据有效合成的重要途径。标准数据元素是构造完整信息的基本单元,各类电子文档则是传递各类业务信息的有效载体,并是将分离的标准数据元素信息进行有效合成的手段。该阶段是业务领域专家和电子文档设计专家按照《电子文档设计指南》对各类电子文档格式进行规范化设计和管理的过程,并形成了一批电子文档格式规范。
               综上所述,数据标准化所涉及的三个主要阶段缺一不可、彼此密不可分。业务建模是数据标准化的基础和前提;数据规范化及其管理是数据标准化的核心和重点;文档规范化是数据标准化成果的有效应用的关键。
               此外,数据标准化也可以采用数据字典、数据指南或信息系统字典等加以统一。数据字典实际上也是以数据表和视图为主要存在形式的,它是关于数据的数据表和视图。管理员可以通过数据字典获得全面的数据库信息。
               数据库审计支持
               数据安全是大型数据库应用系统中必须仔细考虑的一个重要问题,也是数据库管理人员和系统管理人员日常工作中最为重要的一部分。有效的数据库审计是数据库安全的基本要求。企业应针对自己的应用和数据库活动定义审计策略。智能审计的实现对安全管理的意义重大,不仅能节省时间,而且能减少执行所涉及的范围和对象。通过智能限制日志大小,还能突出更加关键的安全事件。
               信息系统审计员可以从数据库系统本身、主体和客体三个方面来进行审计,审计对数据库对象的访问以及与安全相关的事件。数据库审计员可以分析审计信息、跟踪审计事件、追查责任以及使用审计服务器记录审计跟踪,并且可以根据审计信息,对审计结果进行统计、跟踪和分析,进行审计跟踪、入侵检测等。
               目前许多数据库供应商都提供了支持数据库审计的功能,例如东软公司的OpenBASE Secure就提供了十分完善的审计功能。
 
       数据库
        数据库(DataBase,DB)是指长期存储在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和存储,具有较小的冗余度、较高的数据独立性和易扩展性,并可为各种用户共享。
        系统使用的所有数据存储在一个或几个数据库中。
   题号导航      2021年下半年 系统架构设计师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
 
第2题    在手机中做本题