精华内容
下载资源
问答
  • 数据库生命周期 大家对软件生命周期较为熟悉,数据库也有其生命周期,如下图所示。 图(1)数据库生命周期 数据库的生命周期主要分为四个阶段:需求分析、逻辑设计、物理设计、实现维护。 这个系列的博文将...

    摘自http://www.cnblogs.com/DBFocus/archive/2011/04/09/2010904.html

     

    解数据库设计的整体流程

    image

    数据库生命周期

    大家对软件生命周期较为熟悉,数据库也有其生命周期,如下图所示。

    图(1)数据库生命周期

    数据库的生命周期主要分为四个阶段:需求分析、逻辑设计、物理设计、实现维护。

    这个系列的博文将主要关注数据库生命周期中的前两个阶段(需求分析、逻辑设计)。如图中红色框出的部分。

    数据库的物理设计,包括索引的选择与优化、数据分区等内容。这些内容也非常丰富,而且可以自成体系,园子里也有很多好文章,故在本系列中不作主要关注。本文最后将给出一些链接供大家参考。

    数据库生命周期的四个阶段又能细分为多个小步骤,我们配合图(1)来看看每一小步包含的内容。

    阶段1 需求分析

    数据库设计与软件设计一样首先需要进行需求分析。

    我们需要与数据的创造者和使用者进行访谈。对访谈获得的信息进行整理、分析,并撰写正式的需求文档。

    需求文档中需包含:需要处理的数据;数据的自然关系;数据库实现的硬件环境、软件平台等;

    image图(2)阶段1 需求分析

    阶段2 逻辑设计

    使用ER或UML建模技术,创建概念数据模型图,展示所有数据以及数据间关系。最终概念数据模型必须被转化为范式化的表。

    数据库逻辑设计主要步骤包括:

    a) 概念数据建模

    在需求分析完成后,使用ER图或UML图对数据进行建模。使用ER图或UML图描述需求中的语义,即得到了数据概念模型(Conceptual Data Model),例如:三元关系(ternary relationships)、超类(supertypes)、子类(subtypes)等。

    eg:  零售商视角,产品/客户数据库的ER模型简图

    注:ER图的含义,以及详细标记方法将在该系列的下一篇博文中进行讨论

    image图(3)阶段2(a) 概念数据建模

    b) 多视图集成

    当在大型项目设计或多人参与设计的情况下,会产生数据和关系的多个视图。这些视图必须进行化简与集成,消除模型中的冗余与不一致,最终形成一个全局 的模型。多视图集成可以使用ER建模语义中的同义词(synonyms)、聚合(aggregation)、泛化(generalization)等方 法。多视图集成在整合多个应用的场景中也非常重要。

    eg: 集成零售商ER图与客户ER图

    零售商ER图如图(3)所示。客户视角,产品/客户数据库的ER模型简图如下:

    image图(4)以客户为关注点绘制的ER图

    注:现在市面上有许多辅助建模工具可以绘制ER图。使用Sybase的PowerDesigner绘制与图(4)相同语义的ER图如下:

    image

    其标记法与图(4)中略有不同,这将在今后的博文中加以说明。

    这里需要指出的是辅助软件的使用不是设计的核心,大家不要被这些工具迷惑。所以后文中我们将主要使用手绘。只要掌握了ER图的语义,使用这些软件都不会是件难事。

    集成零售商ER图与客户ER图

    image图(5) 阶段2(b) 多视图集成

    c) 转化概念数据模型为SQL表

    根据映射规则,把ER图中的实体与关系转化为SQL表结构。在这一过程中我们将识别冗余的表,并去除这些表。

    eg: 把图(5)中的customer, product, salesperson实体转化为SQL表

    image图(6) 阶段2(c)转化概念数据模型为SQL表

    d) 范式化

    范式化是数据库逻辑设计中的重要一步。范式化的目标是尽可能去除模型中的冗余信息,从而消除关系模型更新、插入、删除异常(anomalies)。

    讲到范式化就会引出函数依赖(Functional Dependency)这一概念。函数依赖(FDs)源自于概念数据模型图,反映了需求分析中的数据关系语义。不同实体之间的函数依赖表示各个实体唯一键 之间的依赖。实体内部也有函数依赖,反映了实体中键属性与非键属性之间的依赖。在保证数据完整性约束的前提下,基于函数依赖对候选表进行范式化(分解、降 低数据冗余)。

    eg: 对图(6)中的Salesperson表进行范式化,消除更新异常(update anomalies)

    image图(7) 阶段2(d)范式化

    阶段3 物理设计

    数据库物理设计包括选择索引,数据分区与分组等。

    逻辑设计方法学通过减少需要分析的数据依赖,简化了大型关系数据库的设计,这也减轻了数据库物理设计阶段的压力。

    1. 概念数据建模和多视图集成准确地反映了现实需求场景

    2. 范式化在模型转化为SQL表的过程中保留了数据完整性

    数据库物理设计的目标是尽可能优化性能。

    物理设计阶段,全局表结构可能需要进行重构来满足性能上的需求,这被称为反范式化。

    反范式化的步骤包括:

    1. 辨别关键性流程,如频繁运行、大容量、高优先级的处理操作

    2. 通过增加冗余来提高关键性流程的性能

    3. 评估所造成的代价(对查询、修改、存储的影响)和可能损失的数据一致性

    阶段4 数据库的实现维护

    当设计完成之后,使用数据库管理系统(DBMS)中的数据定义语言(DDL)来创建数据结构。

    数据库创建完成后,应用程序或用户可以使用数据操作语言(DML)来使用(查询、修改等)该数据库。

    一旦数据库开始运行,就需要对其性能进行监视。当数据库性能无法满足要求或用户提出新的功能需求时,就需要对该数据库进行再设计与修改。这形成了一个循环:监视 –> 再设计 –>  修改 –> 监视…。

     

    image

    在进行数据库设计之前,我们先回顾一下关系数据库的相关基本概念。

    这里只做一个提纲挈领的简介,大家可以根据相应的线索进行扩展。

    表、行、列

    关系数据库可以想象成表的集合,每个表包含行与列。(可以想象成一个Excel workbook,包含多个worksheet)。

    表在关系代数中被称为关系,这也是关系数据库名称的起源(不要与表之间的外键关系混淆)。

    列在关系代数中被称为属性(attribute)。列中允许存放的值的集合称为列的域(域与数据类型密切相关,但并不完全相同)。

    行在关系代数中的学名是元组(tuple)。

    关系数据库的理论基础来自于“关系代数”。但在关系代数中,一个集合的各个元组没有次序的概念,在关系数据库中为了方便使用,定义了行的次序。

    键、索引

    键是一种约束,目的是保证数据完整性

    1. 复合键(Compound key):由多个数据列组成的键

    2. 超键(Superkey):列的集合,其中任何两行都不会完全相同

    3. 候选键(Candidate key):首先是一个超键,同时这个超键中的任何列的缺失都会破坏行的唯一性

    4. 主键(Primary key):指定的某个候选键

    索引是数据的物理组织形式,目的是提高查询的性能

    约束

    基本约束

    not null constraint, domain constraint

    检查约束(Check Constraints)

    eg: Salary > 0

    主键约束(Primary Key Constraints)

    实体完整性(entity integrity),没有两条记录是完全相同的,组成主键的字段不能为null

    唯一性约束(Unique Constraints)

    外键约束(Foreign Key Constraints)

    也被称为引用完整性约束,eg:

    image

    关系数据库操作

    1.选择(Selection)

    2.映射(Projection)

    3.联合(Union)

    4.交集(Intersection)

    5.差集(Difference)

    6.笛卡尔积(Cartesian Product)

    7.连接(Join)

    上述7种是最基本的关系数据库操作,对应于集合论中的关系运算。

    有些书籍中还会加入改名(Rename),除(Divide)等关系操作。

     

    image

    主要内容回顾

    1. 数据库生命周期的四个阶段:需求分析、逻辑设计、物理设计、实现维护。

    2. 关系数据库的理论基础是关系代数。

    展开全文
  • 浅谈数据库生命周期

    2018-01-12 09:57:56
    最近在读一本《数据库系统 设计、实现与管理》的书,其中的数据库设计部分写的挺好的,另外在本书中也讲到了数据库生命周期的概念,我觉得有所收益,特写下此博文! 在软件开发中,我们经常会提到软件系统开发的生命...

    最近在读一本《数据库系统 设计、实现与管理》的书,其中的数据库设计部分写的挺好的,另外在本书中也讲到了数据库生命周期的概念,我觉得有所收益,特写下此博文!

    在软件开发中,我们经常会提到软件系统开发的生命周期,大致分为:计划、分析、设计、实现、运维几个阶段,整体流程和动作如下图所示:

    系统开发生命周期

    而针对数据库建模和数据库应用开发来说,也有其自己的“数据库生命周期”,database life cycle,简称DBLC。DBLC大致上分为6个阶段:数据库初始研究,数据库设计,实现和装载,测试和评价,运行,维护和演化。其对于的生命周期图为:

    DBLC

    也许作为一个数据库模型设计人员或者开发人员来说,只关心参与3个阶段,但是其实每个阶段都应该参与其中,毕竟这6个阶段是不断迭代的过程。

    下面我们来分别说明一下这6个阶段。

    1.数据库初步研究

    简单的说就是前期的需求调研阶段,只不过软件开发中的需求调研是站在软件的角度,而数据库设计人员则应该站在数据库的角度分析用户的需求,主要做到以下目标:

    • 分析公司的状况。
    • 定义问题和约束。
    • 定义目标。
    • 定义范围和边界。

     

    2.数据库设计

    这是数据库生命周期中最重要的环节,也是最烧脑细胞的环节。这个环节工作的好坏直接关系到最终软件是否满足用户和系统的需求。数据库设计又进一步划分为几个阶段:概念设计、DBMS的选择、逻辑设计、物理设计。

    数据库设计

    概念设计

    概念设计阶段需要根据用户和系统的需求,设计出实体关系模型ERM,所以这个阶段的产出是一个ERM。至于怎么分析用户需求后定义实体,定义关系,定义属性,范式化与反范式化,以及对概念模型的验证,那都是很深的学问,都可以单独写一本书了。我在之前的博客中粗略的讲解了如何进行概念模型的设计,可以参考:http://www.cnblogs.com/studyzy/category/466850.html

    尤其是其中一篇(分析与设计数据库模型的简单过程)把ERM的建模过程演示了一遍。

    而对概念模型的验证,一方面需要检查用户需求中的对象和属性是否都在概念模型中,其次,检查CRUD在模型上的操作是否会造成异常,另外也需要从报表的角度考虑,是否能够写出对应的报表的查询,查询效率是否可接受。在整个模型验证过程中,可能把一些属性独立出来成新的实体,也可能把关系从一对多改为多对多,也可能出于性能上的考虑,对一些表进行反范式化处理。对概念模型的验证一般以模块为单位进行验证,而且概念模型的定义是独立于硬件和软件的,保证了模型的简洁。

    DBMS的选择

    目前市面上的DBMS可选择性并不是很大,企业级DBMS就是Oracle,IBM DB2和SQL Server,这些DBMS功能强大完备,但是价格昂贵,而免费开源的有MySQL,PostgreSQL,这都是很流行的开源数据库,而如果系统小而简单的话,还可以考虑Sqlite,Access等单机数据库。这前面说的都是RDBMS,也就是关系型的数据库,还有其他对象数据库,文档数据库,层次数据库如果需要也可进行选择,尤其是随着互联网的兴起,现在NoSQL非常火,也增加了DBMS的选择范围。

    不管怎么说,DBMS的选择主要还是考虑以下几个方面:

    • 开销/预算。这里除了软件和硬件本身的采购价格,还需要包括学习成本,运维开销,转换成本等。
    • DBMS的特征和工具。如关注系统的可用性,安全性,扩展性等。
    • 基础模型。是关系型的还是对象型的,或者文档型。
    • 便利性。DBMS可以便利的在不同平台,系统,语言之间进行移植。
    • 硬件要求。

    逻辑设计

    逻辑模型就是将概念模型转换为特定DBMS支持的模型,所以逻辑模型是与软件相关的。逻辑模型中的表、外键是可以通过概念模型的实体、关系转换而来,但是对于视图、存储过程、函数、用户等,都需要在逻辑模型中设计。

    物理设计

    物理模型是与具体的物理硬件相关,可以通过逻辑模型转换而来。在物理设计中,需要考虑具体的数据存储,数据分布等,在物理模型中要求设计师充分了解软件和硬件环境,充分发挥软件和硬件的特性。

    3.实现和装载

    常用的数据库建模工具如PowerDesigner或者ERWin都可以将物理模型生成对应的SQL语句,然后我们在DBMS中运行SQL,便可实现我们设计的数据库模型。在实现了数据库模型后,我们还需要进一步研究其性能,安全,备份与恢复,以及完整性和公司标准。这些一般都是由DBMS提供的工具支持的。

    4.测试和评价

    数据一旦装载到数据库后,DBA就要对数据库的性能,完整性,并发访问和安全约束进行测试和优化。这个测试和评价阶段是与软件开发并行进行的。如果测试和评价结果不满足要求,就需要对系统和模型进行调整。其中包括:

    调整DBMS的配置参数,修改物理设计(比如索引和分区的修改),修改逻辑设计(比如增加冗余字段),更新或者更换DBMS的软硬件平台。

    5.运行

    数据库通过了评测阶段,就认为是可运行的了。在实际生产环境的运行过程中,产生了真实的数据,一些在测试阶段无法预见的问题可能会被遇到,比如查询缓慢,数据不一致,死锁等问题都可能遇到。棘手的问题需要紧急补丁,而一些小Bug则可能在下一个版本中修正,而这些在运行中对数据库的补丁和修改,就是一个维护和演化的过程。

    6.维护和演化

    数据库的日常维护工作包括备份与恢复,用户权限分配,系统监控,系统定期安全审计等。对于系统补丁和新版本开发,则是对模型的演化,需要在更新生产系统数据库时对数据库模型进行同步的更新,这便进入了数据库生命周期的迭代过程。

    本文转自深蓝居博客园博客,原文链接:http://www.cnblogs.com/studyzy/p/4883356.html,如需转载请自行联系原作者

    展开全文
  • 玩转 Oracle Em12C 数据库生命周期管理篇 唐晓华 数据库管理十大挑战 IOUG机构调查结果(2011) 保持补丁最新 45%为台规性需求忘 26% 性能诊断 42% 发/测试环境中进行 处理日益增长的安全威胁 35% 供应开发/测试系统 ...
  • MySQL将缓存存放在一个引用表(不要理解成table,可以认为是类似于HashMap的数据结构),通过一个哈希值索引,这个哈希值通过查询本身、当前要查询的数据库、客户端协议版本号等一些可能影响结果的信息计算得来。...

    2ff34e647e2e3cdfd8dca593e17d9b0a.png

    很多时候所谓的的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。

    MySQL的逻辑架构图如下所示

    MySQL逻辑架构整体分为三层。其中最上层为客户端层,并非MySQL所独有,诸如:连接处理、授权认证、安全等功能均在这一层处理。

    中间这一层包含大多数MySQL核心服务,包括查询、解析、分析、优化、缓存、内置函数(比如:时间、数学、加密等函数)。所有的跨存储引擎的功能也在这一层实现:存储过程、触发器、视图等。

    最下层为存储引擎,其负责MySQL中的数据存储和提取。和Linux下的文件系统类似,每种存储引擎都有其优势和劣势。中间的服务层通过API与存储引擎通信,这些API接口屏蔽了不同存储引擎间的差异。

    MySQL查询过程

    MySQL整个查询执行过程,总的来说分为6个步骤客户端向MySQL服务器发送一条查询请求

    服务器首先检查查询缓存,如果命中缓存,则立刻返回存储在缓存中的结果。否则进入下一阶段

    服务器进行SQL解析、预处理

    由优化器生成对应的执行计划

    MySQL根据执行计划,调用存储引擎的API来执行查询

    将结果返回给客户端,同时缓存查询结果

    上述过程如下图所示:

    客户端/服务端通信协议

    MySQL客户端/服务端通信协议是“半双工”的:在任一时刻,要么是服务器向客户端发送数据,要么是客户端向服务器发送数据,这两个动作不能同时发生。一旦一端开始发送消息,另一端要接收完整个消息才能响应它,所以我们无法也无须将一个消息切成小块独立发送,也没有办法进行流量控制。

    客户端用一个单独的数据包将查询请求发送给服务器,所以当查询语句很长的时候,需要设置max_allowed_packet参数。但是需要注意的是,如果查询实在是太大,服务端会拒绝接收更多数据并抛出异常。

    与之相反的是,服务器响应给用户的数据通常会很多,由多个数据包组成。但是当服务器响应客户端请求时,客户端必须完整的接收整个返回结果,而不能简单的只取前面几条结果,然后让服务器停止发送。因而在实际开发中,尽量保持查询简单且只返回必需的数据,减小通信间数据包的大小和数量是一个非常好的习惯,这也是查询中尽量避免使用SELECT *以及加上LIMIT限制的原因之一。

    查询缓存

    MySQL查询缓存的过程如下图所示:

    缓存命中率可以通过如下公式计算:Qcache_hits/(Qcache_hits + Com_select)来计算。

    在解析一个查询语句前,如果查询缓存是打开的,那么MySQL会检查这个查询语句是否命中查询缓存中的数据。如果当前查询恰好命中查询缓存,在检查一次用户权限后直接返回缓存中的结果。这种情况下,查询不会被解析,也不会生成执行计划,更不会执行。

    MySQL将缓存存放在一个引用表(不要理解成table,可以认为是类似于HashMap的数据结构),通过一个哈希值索引,这个哈希值通过查询本身、当前要查询的数据库、客户端协议版本号等一些可能影响结果的信息计算得来。所以两个查询在任何字符上的不同(例如:空格、注释),都会导致缓存不会命中。

    如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、mysql库中的系统表,其查询结果都不会被缓存。比如函数NOW()或者CURRENT_DATE()会因为不同的查询时间,返回不同的查询结果,再比如包含CURRENT_USER或者CONNECION_ID()的查询语句会因为不同的用户而返回不同的结果,将这样的查询结果缓存起来没有任何的意义。

    然是缓存,就会失效,那查询缓存何时失效呢?MySQL的查询缓存系统会跟踪查询中涉及的每个表,如果这些表(数据或结构)发生变化,那么和这张表相关的所有缓存数据都将失效。正因为如此,在任何的写操作时,MySQL必须将对应表的所有缓存都设置为失效。如果查询缓存非常大或者碎片很多,这个操作就可能带来很大的系统消耗,甚至导致系统僵死一会儿。而且查询缓存对系统的额外消耗也不仅仅在写操作,读操作也不例外:任何的查询语句在开始之前都必须经过检查,即使这条SQL语句永远不会命中缓存

    如果查询结果可以被缓存,那么执行完成后,会将结果存入缓存,也会带来额外的系统消耗

    最后的忠告是不要轻易打开查询缓存,特别是写密集型应用。

    如果你实在是忍不住,可以将query_cache_type设置为DEMAND,这时只有加入SQL_CACHE的查询才会走缓存,其他查询则不会,这样可以非常自由地控制哪些查询需要被缓存。

    常见的查询缓存的配置如下所示query_cache_type:是否打开查询缓存。可以设置为OFF、ON和DEMAND。DEMAND表示只有在查询语句中明确写明SQL_CACHE的语句才会放入查询缓存。

    query_cache_size:查询缓存使用的总内存空间。

    query_cache_min_res_unit:在查询缓存中分配内存块时的最小单元。较小的该值可以减少碎片导致的内存空间浪费,但是会导致更频繁的内存块操作。

    query_cache_limit:MySQL能够查询的最大查询结果。如果查询结果大于这个值,则不会被缓存。因为查询缓存在数据生成的时候就开始尝试缓存数据,所以当结果全部返回后,MySQL才知道查询结果是否超出限制。超出之后,才会将结果从查询缓存中删除。

    语法解析和预处理

    MySQL通过关键字将SQL语句进行解析,并生成一颗对应的解析树。这个过程解析器主要通过语法规则来验证和解析。比如SQL中是否使用了错误的关键字或者关键字的顺序是否正确等等。预处理则会根据MySQL规则进一步检查解析树是否合法。比如检查要查询的数据表和数据列是否存在等等。

    查询优化

    经过前面的步骤生成的语法树被认为是合法的了,并且由优化器将其转化成查询计划。多数情况下,一条查询可以有很多种执行方式,最后都返回相应的结果。优化器的作用就是找到这其中最好的执行计划。

    MySQL使用基于成本的优化器,它尝试预测一个查询使用某种执行计划时的成本,并选择其中成本最小的一个。在MySQL可以通过查询当前会话的last_query_cost的值来得到其计算当前查询的成本。

    查询执行引擎

    在完成解析和优化阶段以后,MySQL会生成对应的执行计划,查询执行引擎根据执行计划给出的指令逐步执行得出结果。整个执行过程的大部分操作均是通过调用存储引擎实现的接口来完成,这些接口被称为handler API。查询过程中的每一张表由一个handler实例表示。实际上,MySQL在查询优化阶段就为每一张表创建了一个handler实例,优化器可以根据这些实例的接口来获取表的相关信息,包括表的所有列名、索引统计信息等。存储引擎接口提供了非常丰富的功能,但其底层仅有几十个接口,这些接口像搭积木一样完成了一次查询的大部分操作。

    返回结果给客户端

    查询执行的最后一个阶段就是将结果返回给客户端。即使查询不到数据,MySQL仍然会返回这个查询的相关信息,比如该查询影响到的行数以及执行时间等等。

    如果查询缓存被打开且这个查询可以被缓存,MySQL也会将结果存放到缓存中。

    结果集返回客户端是一个增量且逐步返回的过程。有可能MySQL在生成第一条结果时,就开始向客户端逐步返回结果集了。这样服务端就无须存储太多结果而消耗过多内存,也可以让客户端第一时间获得返回结果。需要注意的是,结果集中的每一行都会以一个满足①中所描述的通信协议的数据包发送,再通过TCP协议进行传输,在传输过程中,可能对MySQL的数据包进行缓存然后批量发送。

    展开全文
  • 微软近期更新了MSDN资源库中的数据库生命周期管理精选指南页面,该页面提供了SQL Server Data Tools、SQL Server Management Studio和Windows Azure SQL Database的相关资源。该页面着重展示了SQL Server数据库生命...

    微软近期更新了MSDN资源库中的数据库生命周期管理精选指南页面,该页面提供了SQL Server Data Tools、SQL Server Management Studio和Windows Azure SQL Database的相关资源。该页面着重展示了SQL Server数据库生命周期管理图,以识别应用到开发者数据库场景中的各个应用和活动。

    \

    19232fa75cc8d932899565ce65da47dc.png

    \

    例如,如果开发者需要了解更多与Windows Azure SQL数据库备份和恢复相关的内容,那么只需要浏览位于Windows Azure SQL Database章节中的备份与恢复任务,就能够看到该任务的详细教程,以及源代码、屏幕截图和外部参考资源。

    \

    “这些主题都是为学生和其他行业新手们精选的。我希望对他们能有帮助,”Louis Berner说道。她是SQL Server用户教育方面的技术作者/软件工程师。

    \

    在撰写本文的时候,数据库生命周期管理指南页面已经覆盖了以下主题:

    \

    SQL Server Data Tools

    \

    SQL Server Management Studio

    \

    Windows Azure SQL Database

    \

    在InfoQ的采访中,Louis解释了为何创建数据库生命周期管理精选页面。

    \

    InfoQ:你觉得流程图真的能够帮助开发者快速编码并且不会遭遇任何挫折吗?

    \
    \

    流程图依据连接各产品的活动为SSDT、SSMS、Azure和混合架构提供了整体视图。例如,开发者可以从SSDT发布到Azure;也能够从SQL Server的本地实例导入到SSDT;此外开发者还可以从Azure上的SQL数据库向本地磁盘导出.bacpac文件。

    \

    这就是“发布”、“导入”和“导出”活动——与图表中显示的其他操作一起——将微软的各个应用连接在一起。这个可视化图表的目的并不是帮助开发者快速编码或避免遭遇任何挫折,而是为了帮助客户将各个要点串联起来,以可视化的方式将数据库生命周期相关的应用凝聚到一起,帮助用户理解。

    \
    \

    InfoQ:从你的角度看,谁将从DLM页面提供的资源中获益?

    \
    \

    DLM主题是我从事微软客户支持服务(CSS)工作时的结果。CSS支持工程师拥有的数据指出客户采用Azure平台之所以存在障碍是因为客户对以下内容感到困惑:

    \
    • 如何开始使用SQL Server Data Tools\
    • 如何将现存数据迁移到Azure平台——例如数据可移植性选项\
    • 如何对比和同步数据\
    • 如何备份到云端,或如何使用导入/导出特性\
    • 如何从云端执行备份和恢复操作以满足其SLA需求\

    从以上主题列表可以看出,它们大部分是基础(100级别和200级别)的概念。因此最初发布的DLM主题——在2013年1月底发布——主要解决Azure平台的采用、数据可移植性、准备并运行,以及初级开发者等问题的任务。未来的DLM主题更新将包括更高级的课题,例如:

    \
    • 联合\
    • 性能——对延迟、节流、等待的统计\
    • 错误引用\
    • PowerShell脚本\
    • 监控\
    • 权限和角色\

    我将继续使用CSS数据以保证能够解决客户的主要任务。以上列出的新主题来自于对最新的CSS客户数据的分析。

    \
    \

    InfoQ:你是否打算经常更新DLM主题页面?

    \
    \

    我的计划是按季度更新主题。下一次更新应该会在2013年5月或6月发布。

    \

    我正在开发一个分析客户数据的工作流,构建一份主题的待办事项列表,与项目干系人一起审核待办事项列表,将更新发布到主题,并确认主题能够满足客户需求。

    \

    这是一种内容精选的方法,因为几乎所有DLM主题中列出的内容都已经在Web上存在。我正在将最佳组合的内容、教程、视频和社区资源收集到单一知识库,而看起来客户也喜欢我这种方式。

    \
    \

    InfoQ:你是否估算过,会有多少开发者能够真的从DLM资源页面获益?

    \
    \

    自2013年1月以来,MSDN上的这些主题拥有超过3000次页面浏览(PV)、拥有良好的客户评价和逐字评论——类似于“了不起”或“非常有帮助”。它或许不能满足每个人的需求,但对于这些目标听众而言,包括Azure或SQL Server新手、上手感到有困难的人、寻找可用的最佳文档和视频的人——我已经开始构建指南了。

    \
    \

    查看英文原文:Database Lifecycle Management Guidance Updated by Microsoft

    \

    感谢孙镜涛对本文的审校。

    \

    给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

    展开全文
  • 因此,在对MySQL的查询进行优化之前,应该了解一下MySQL查询的生命周期。 上面的这张图,是大家经常看到的MySQL的架构图,关于MySQL的各个部分显示的很详细。如果从大的方面来看,可以将MySQL分为两层,SQL层和存储...
  • mysql教程栏目介绍关系数据库的sql的生命周期。MYSQL Query Processingsql的执行过程和mysql体系架构基本一致执行过程:连接器:建立与 MySQL 的连接,用于查询SQL语句,判断权限 。查询缓存:如果语句不在查询缓存...
  • 引言:数据库设计 Step by Step (1)得到这么多朋友的关注着实出乎了我的意外。这也坚定了我把这一系列的博文写好的...系列的第二讲我们将站在高处俯瞰一下数据库的生命周期,了解数据库设计的整体流程 数据库生命
  • 这个问题归根到底是「如何管理数据库连接的生命周期」的问题。 一个数据库连接,一头系着 client (即 App,这里我们简化为 Django ),一头系着 server (MySQL Server),其状态是由这两者加上其他因素(姑且先...
  • 这个问题归根到底是「如何管理数据库连接的生命周期」的问题。 一个数据库连接,一头系着 client (即 App,这里我们简化为 Django ),一头系着 server (MySQL Server),其状态是由这两者加上其他因素(姑且先...
  • 数据库设计(2)生命周期

    千次阅读 2015-08-31 21:24:54
    数据库生命周期 总览 大家对软件生命周期较为熟悉,数据库也有其生命周期,如下图所示。 图(1)数据库生命周期 数据库的生命周期主要分为四个阶段:需求分析、逻辑设计、物理设计、实现维护。 这个系列的博文将主要...
  • Release Schedule of Current Database Releases (文档 ID 742060.1)
  • 数据库应用系统的生命周期可以划分为:数据库规划、需求描述与分析、数据库与应用程序设计、数据库设计实现、数据库测试、数据库运维。1、数据库规划数据库规划是创建数据库应用系统的第一步,也...
  • oracle 数据库支持生命周期

    千次阅读 2014-07-07 17:29:39
  • 2.1数据库系统的生命周期

    千次阅读 2018-01-24 15:32:11
    2、数据库应用系统具有信息的采集、组织、加工、抽取、综合和传播等功能,被称为“数据库工程”。 3、数据库系统从开始规划、设计、实现、维护到最后被新的系统取代而停止使用的整个期间,称为数据库系统生存期。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 5,571
精华内容 2,228
关键字:

数据库生命周期