MYSQL网页编程之PowerDesigner UML 建模简介（第二部分...

MySQL对硬件的较低要求是其最大的优势之一，不过需要注意的是：内存越多越好，因为所有的重要数据存储都在内存中完成。PowerDesignerUML简介（第二部分）
Sybase,Inc.PowerDesigner产物司理DavidDichmann

在BluePrint#4（会见http://www.sybase.com/blueprint以猎取以往成绩的电子版）中，我们切磋了5种UML图表：用例图、序列图、举动图、类图和组件图，它们能够匡助您把握体系的需求，计划其物理布局和预期功效，并转换为代码。我们还可使用别的4个UML图来进一步精简前5个图中包括的界说，大概从完整分歧的可取角度来界说体系。

这些图表（工具图、合作图、形态图和部署图）与后面的图一同构成了PowerDesigner中的全体图表，并可在PowerDesigner9.5中利用。
工具图(ObjectDiagram)：
与类图一样，工具图也是一个UML静态布局图；它界说了体系在给准时刻具有的物理元素，而没有详细思索体系的静态举动。它与代码逐一对应，但与类图分歧，我们如今会商的是详细的分类器，而不是分类器界说。将工具图形貌为类实例图大概最为符合。

工具图的次要用处是举行剖析。类图中没法暗示的类之间存在不断定的束缚。我们将利用工具图来纪录这些束缚。并且，在我们检察所办理的详细类实例示例以分析这些元素之间的交互感化干系时，工具图还同意我们界说详细的“Whatif”场景。

以下内容合用于OO建模的初学者：分类器是笼统的工具布局界说。分类器能够告知我们所办理的是甚么范例的数据（属性/成员暗示数据元素）和该分类用具有甚么才能（操纵/办法暗示工具的举动）。实例是详细的分类器示例。假定界说一个名为Customer的类，该类具有Name属性。类Customer的实例“JaneDoe”是姓名恰为“JaneDoe”的客户。实例一般具有比分类器更丰厚的寄义，这是由于分类器暗示某种级其余概述。搜集某个分类器的多少个实例或示例大概有助于您了解其用处并更好地利用它。

因而，工具图是类图的详细情势，暗示类实例样本，而且显现了键值和干系。比方，CustomerBean类具有以下客户实例：该客户的ID为52271，姓名为“JohnDoe”。该客户实例与三个定单实例（三份定单）相干，定单编号分离为122047、122103和122399。






合作图(CollaborationDiagram)：
合作图和序列图十分类似。实践上，序列图和合作图能够无效地瓜代利用，并能够烦琐的互相转换。其区分在于用户浏览和了解的体例分歧。序列图具有很好的条理性，而且环绕工夫机关。合作图则次要是环绕工具布局机关。经由过程在图中抵消息举行编号能够暗示动静的按次。接纳这类体例时，即便图的布局不是基于工夫的，也将坚持准时干系。

合作图借助于体系中元素或工具之间的交互感化，暗示体系的静态方面，即在一段工夫内的体现体例。它经由过程暗示体系的静态布局来对类图和工具图举行增补，但不是借助于基于布局的干系，而是在体系工具之间传送交互感化“动静”。

机关合作图时还能够在观点级测试静态模子。在类图中界说了类实例，这些类实例之间的交互感化界说了一个详细的利用计划和将在这些元素之间产生的外部通信。我们还可使用其他脚色来暗示体系的内部感化者和外部利用者，如用例图。

比方，我们能够创建一个定单输出体系，以供客户和发卖代表利用。客户经由过程创立新定单与该体系交互感化。定单工具与发卖工具之间举行对话，该对话由链接动静暗示，在此情形下，只要两个动静：一个是来自Orders类的定单哀求，一个是来自Sales类的定单确认。对一个链接上的动静数目没无限制。我们在此会商的对话以一个定单哀求入手下手，然后是对该定单切实其实认。




合用性
合作图关于计划职员特别主要，由于它分析了工具的感化。您能够在序列图之前机关合作图（假如您企图机关这两个图），但一般是在完成类图以后机关合作图以申明从类中导出的工具之间的交互感化。可使用一个或多个合作图来完成一个用例，大概将庞大举动支解成多个逻辑子举动。
形态图(StatechartDiagram)：
形态图（也称为形态机）形貌了特定类或组件在其全部性命周期中不休变更时的举动。该图显现是甚么触发了从一种形态向另外一种形态的转换，和在该类上挪用哪些操纵以供应该形态的举动或触发这类转换。比方，定单在被创立时处于初始形态。在客户确认定单准确后，定单将进进确认形态。在发货今后，定单必要从确认形态进进发货形态。







因而，每当一个类在其性命周期的分歧阶段具有分歧的可用选项（分歧的无效举动）时，您都可使用形态图来将这些划定规矩和前提建模。性命周期中的每一个阶段都是该工具的一种形态，而每一个改动形态的触发器都代表从一种形态到另外一种形态的转换。能够依据必要从某个形态转换就任意多个别的形态，也能够从别的多个形态进进某个形态。
子形态图
若要坚持形态图复杂和易读，您大概发明所界说的一个或多个形态实践上触及到更加庞大的举动，以致于它自己就能够界说为一个形态图。此时，与向主图中增加大批庞大细节的做法比拟，更好的做法是将这个独自的形态分化为多个子形态，进而构成一个帮助图，以界说父形态的更加庞大的外部举动。



部署图(DeploymentDiagram)：
部署图能够匡助我们断定一切代码元素在服务器、事情站和数据库中的寄存地位。有的节点必要依附硬件或软件框来运转部分营业逻辑。这些节点交互感化以演示我们开辟的多个盘算机和体系是怎样交互感化和集成的。节点中包括将部署到数据库、使用程序或Web服务器中的组件实例。

部署图用于将组件实践部署到服务器中。经由过程界说但愿组件运转的地位，我们能够快速的映照、部署和办理散布在客户端使用程序和使用程序服务器端组件之间的营业逻辑或数据库端服务器逻辑。以下是要办理的物理系统布局的1:1模子。

比方，假定我们已决意完成两个EnterpriseJavaBeans，而且在使用程序服务器上运转它们。下图显现了单个节点和该节点内的两个组件（每一个EJB一个组件）。我们能够看出EmployeeBean依附于统一使用程序服务器内的CustomerBean。


结论
在我们借助用例图、序列图、举动图、类图和组件图完成基础UML建模时，我们将必要别的一些工具来界说有干系统中某些特定元素的具体信息。我们大概但愿在工具图中利用准确的示例来暗示工具的布局，大概借助于形态图来更多地懂得在其外部具有多个庞大形态的类的举动。我们必要利用合作图从布局角度而不是从工夫角度来考查体系组件之间的交互感化。最初，还必要利用部署图来显现一切体系组件在运转情况中的物理硬件或服务器中所处的地位，从而更细致的懂得散布式系统布局的利用体例。

UML为我们供应了加倍有用的图表，以便完成对营业逻辑的手艺剖析、计划、开辟、或部署。将这9种图表与传统的数据建模办法和新的营业流程建模办法相分离，我们能够在从初级需求到手艺和数据需求，和物理完成的各个方面来周全懂得推进软件开辟的一切要素。
正如前文所提到的，MySQL易学、易部署、易管理和易维护。

连做梦都在想页面结构是怎么样的，绝非虚言

再开发调试阶段和OLAP环境中，外键是可以建立的。新版本中加入了SETNULL和SETDEFAULT属性，能够提供能好的级联设置。

备份方面可能还是一个老大难的问题。不能单独备份几个表总是感觉不爽。灵活备份的问题不知道什么时候才能解决。

至于淘汰的问题，只能说在你的项目周期之内，微软应该都不会倒闭。

无法深入到数据库系统层面去了解和探究

这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。

对于数据库来说，查询是数据库的灵魂，那么SQL查询效率究竟效率如何呢？下文将带对SQL查询的相关问题进行讨论，供您参考。

备份方面可能还是一个老大难的问题。不能单独备份几个表总是感觉不爽。灵活备份的问题不知道什么时候才能解决。

如果我们从集合论（关系代数）的角度来看，一张数据库的表就是一组数据元的关系，而每个SQL语句会改变一种或数种关系，从而产生出新的数据元的关系（即产生新的表）。