下午 4 点：CL_MXPRF_TO?

　　关于 RDA 最棒的事情就是从 UML 建模工具转而使用集成数据库设计工具很容易。我见过很多的建模工具，但是很少有工具在将逻辑数据库组件转换为物理数据库组件时能进行这么多的控制。

　　我们又回到传感器数据库的工作上来，它需要很快地成为一个真正的数据库。我们将用 RDA 根据模型生成一个特定于语法的 DDL 模式，并将其保存为一个脚本，提供给主 RDBMS(在这里就是 DB2)来执行。但是首先，我们继续对模型进行验证检查。今天下午，一次测试挑出了一个不符合公司标准的属性名称：CL_MXPRF_TO。我们不知道是谁将它放入到模式中的，当然我们也不知道它是什么，因为它没有带注释。会不会是用来考我们的圈套呢?

　　不，它是我们忘了加注释的一个什么东西。我们已经弄清楚，该属性是来自 WebSphere Information Integrator 联邦函数的很多属性中的第一个属性，但是我们还没有理清所有的联系。当我们理清这些联系之后，需要用 RDA Impact Analysis 窗口进行整体上的观察，以便研究依赖关系，确保所有引用都是有依据的。我们将这两样东西放入到 RDA Task List 中。我们还做了笔记，考虑 RDA 中可用的很多不同的验证测试(有些是显式的，有些是隐式的)，并决定给它们排序。

　　忘乎所以

　　RDA 有如此丰富的特性，包括 UI 的细节，所以要学会它们并理解它们的用法需要不少时间。例如，我仍然在探索，RDA 是如何使用 Eclipse Modeling Framework(EMF)的，后者使 RDA 的功能扩展起来容易得多(虽然不一定很简单)。有空的时候我会想学习如何构建一些数据管理 Eclipse 插件。我已经有了一些想法。当然，这只是为了在闲暇时找点儿乐子……

　　Rational Data Architect eases the daily grind.

　　If I were asked to name the best feature of IBM Rational Data Architect (RDA), I’d have to say it’s the product’s versatility. Sure, the ease of creating federated data sources and the slick Eclipse-based Workbench are terrific high-level features, but they’re only contributors to RDA’s overall usefulness. It’s the ability to swing from logical to physical data models, explore and reverse engineer existing databases, analyze schemas, apply business rules, create stored procedures, publish schemas and reports (print or Web), and a raft of other database related tasks that make RDA stand out.

　　RDA is like the Swiss Army Knife of enterprise database management. Does this mean it does everything? No, and a Swiss Army Knife is not a substitute for a forklift either. But RDA is a well-organized toolkit that can quickly become second nature to use in all kinds of situations.

　　To show you what I mean, let’s pretend we’re using RDA to tackle jobs typical in a DBA or data architect’s day. These events are fictitious, but the situations are real enough.

　　8 a.m.: In Normal Form

　　After checking server monitors and database status dashboards, a DBA or data architect is likely to fire up RDA with the day’s first cup of coffee. For us, the day starts with the continuing design of a sensor database for the meteorology product line. What started with a small list of sensor attributes has grown with each product. The design process has taken the typical “oh yeah” approach — as in, “Oh yeah, we need to carry Fahrenheit conversion on that.” We wince at this because we don’t do calculated attributes, right? We argue, but because of a stored procedure that will use the number in a busy loop, we make an exception.

　　Jumping into RDA, we open the sensor database model, which is still in the logical design phase (see Figure 1), and then add the attribute with copious annotations. We use the RDA workbench to create a stub for the eventual stored procedure, with notes about the calculated value. RDA has a very good Analyze Model function, which checks for duplicate relations, normal forms, model and SQL syntax, and some business rules we built with Object Constraint Language (OCL). A validation routine may complain about this attribute, so we need useful documentation. RDA can store almost everything about a design, including text files, diagrams, bookmarks — whatever it takes to document the work.