Also on the less filling side is that the $995 Database Designer provides only physical model generation capabilities, eliminating from its roster such key features as conceptual modeling, application generation, team editing and a design repository. Because of this trade-off, users of existing database CASE tools, among them Sybase Inc.'s S-Designor, Logic Works Inc.'s ERwin and Designer/2000, will not be tempted to switch. (On the other hand, those tools run $4,000 or more.)

Organizations not currently using any design tools will find Database Designer an inexpensive entry point. Developer/2000 installations will also find Database Designer attractive, as the two packages can interoperate; this allows novices to get their feet wet with Database Designer and then move up to Developer/2000 to access its sophistication, while making minimal changes to their database model files.

What's more, Database Designer's support for ODBC (Open Database Connectivity)-compliant databases means it can model just about any database--even such desktop databases as Microsoft Corp.'s Access or Borland International Inc.'s Visual dBASE, a market often neglected by CASE tools' traditional high-end focus.

Released at the end of November, Database Designer is available in both 16-bit and 32-bit Windows versions.

Database Designer addresses one small part of the database design process: the physical generation of a database schema.

As Database Designer does no conceptual modeling--a step in the design process that occurs before physical modeling--other products that cleanly separate conceptual from physical modeling, such as S-Designor's DataArchitect module, make the design of large databases easier. But because the distinction between conceptual and physical models is not as pronounced with smaller databases, Database Designer excels in these areas.

To test Database Designer, PC Week Labs used it to construct databases hosted on Oracle7 Server, Microsoft SQL Server and Microsoft Access 97.

Database Designer can access databases using an ODBC driver or connect to an Oracle6 or Oracle7 Server database via Oracle's native database connector SQLNet. Both approaches worked identically in our testing.

Database Designer also can export SQL code that is compatible with Oracle6, Oracle7, Personal Oracle Lite, RDB, DB2 and Microsoft SQL Server, as well as generic ANSI SQL 92, which virtually all SQL databases will be able to read.

As should be expected, Database Designer supports such SQL database objects as indices, views, primary keys and foreign keys. We could see key relationships diagrammed graphically between tables, and could use a series of dialogs to edit such table properties as column names and data types. This functionality is common in end-user databases but still mostly lacking from server database packages (say, Oracle7 Server or Sybase SQL Server), which typically provide command-line SQL tools for this purpose.

Along with creating new databases, Database Designer can reverse-engineer databases, either to export existing database formats to another database platform (much like Microsoft's upsizing wizards) or to modify them and save the format changes back to the original database.

Moving a database from one platform to another is a harrowing experience; by automating the database design transfer process, Database Designer cuts down on errors and costs. Database Designer doesn't transfer any records stored in the database, however--this remains a separate task that must be performed with other tools.

Besides the lack of conceptual modeling, Database Designer's biggest gap is its lack of any application generation tools. It does support a few application logic features, such as triggers, though only with Oracle's server databases. In general, however, the database logic that accompanies a database's design in any large design project must be added with another tool.

The omission is a deliberate one: Oracle sells Designer/2000 for this purpose. Customers developing custom database programs in Sybase's PowerBuilder, Borland's Delphi, Microsoft's Visual Basic, Centura Software Inc.'s SQL Windows or any other interface-builders will need to pair Database Designer with a higher-end CASE product providing application-generation features.

Want top-notch database design? Here are 10 tips
By Timothy Dyck

No matter which product or language is used as a basis for designing a corporate database, keeping the following points in mind will help make sure the result is efficient and successful.

• Use a structured database modeling technique. Immediately constructing a physical model without having a mature conceptual model already developed will guarantee many hours of database downtime while physical models are reworked.
• Investigate techniques other than ER (Entity Relationship) modeling. In some cases, such alternate techniques as object role modeling, dependency modeling, conceptual schema and design procedure, and functional decomposition offer advantages over the highly entrenched ER approach.
• Logically group information into separate tables. Called normalization, this incredibly important organizational approach means that an update or delete of a single piece of information only changes one table row. It's easy to miss required updates if the same information is in several places.
• Keep the design of the internal database structure and its user interface separate. While they are related, neither needs to (nor probably should) reflect the structure of the other.
• Get users involved in the design process of a database early and keep them involved as the project evolves. The best way to ensure cooperation and overall success of a project is to encourage feedback from those who will use the product.
• Consider input models as well as anticipated output requirements when designing a database. Reports and data exports can require table relationships not used at any other point in a database.
• Keep the number of columns in a table as small as possible. Infrequently collected information creates sparse columns, which are stored inefficiently by relational systems. Instead, place sparse columns in a separate table.
• Consider the type of data being stored when selecting a database design and indexing techniques. For example, low cardinality data (columns with few unique values) are best indexed with bit-map indexes, and nonalphanumeric data may most efficiently be stored in an object database rather than in a relational database.
• Use data types that provide room for later growth. For instance, use short integers rather than Booleans because two-valued fields will often need to accommodate three values later.
• Double-check performance considerations after a database is modeled. This is particularly important when using conceptual modeling tools to generate physical models. Theoretically perfect normalized designs can lead to excessive joins, and joins are slow operations.

Some denormalization might be considered to speed queries. Think carefully before proceeding, though: Denormalization makes a database harder to manage and modify.