ER/Studio - Embarcadero Technologies Product Documentation

USING ER/STUDIO > DEVELOPING THE PHYSICAL MODEL
Definition page/tab
Enter or edit a definition for the schema. If the target database supports it, ER/Studio adds this definition as a
comment when generating SQL code.
DDL page/tab
Displays the CREATE SCHEMA statement needed to build the schema. ER/Studio uses the platform-specific
parser of the model’s selected database platform to generate the tablespace.
Attachment Bindings tab
Bind an external piece of information, or attachment to the schema. You can also remove an attachment from an
object, override an attachment binding’s default value, or change the position of a bound attachment. To override
the value of the attachment you have moved to the Selected Attachments grid, double-click the Value field of
the target attachment. ER/Studio opens the Value Override Editor or a list depending on the attachment
datatype. Attachments are created in the Attachments folder of the Data Dictionary. For more information, see
Attaching External Documents to the Data Model.
Optimizing Query Performance on the Physical Model
Denormalizing the Physical Model
o matter how elegant a logical design is on paper, it often breaks down in practice because of the complex or
expensive queries required to make it work. Sometimes, the best remedy for the performance problems is to depart
from the logical design. Denormalization is perhaps the most important reason for separating logical and physical
designs, because then you do not need to compromise your logical design to address real-world performance issues.
Here are some common scenarios you should consider when denormalizing a physical design.
• Duplicated Non-Key Columns: You may decide to duplicate non-key columns in other tables to eliminate the
need to access, or join to that table in a query, such as when you duplicate the description or name column of a
lookup table. When duplicating non-key columns in tables, ensure that the procedural logic synchronizes the
column data so that it does not differ from the values in the reference table.
• Horizontal Table Splits: When tables have many rows of data, you may want to partition the data by splitting the
table into multiple tables where each table uses the same schema but stores a different range of primary key
values. Splitting the table reduces the size and density of the indexes used to retrieve data, thereby improving
their efficiency. On the other hand, once the table is split you must access data in multiple tables instead of in a
single table which requires more complicated procedural logic to manage the tables.
• Vertical Table Splits: When tables with many columns have high read/write activity, you may want to split the
table into multiple tables with different column sets, where each column set uses the same primary key. This lets
you spread update activity across multiple tables, thus decreasing the impact of maintaining multiple indexes. As
with horizontal table splits, vertical table splits require more complex procedural logic to manage multiple tables.
After generating a physical model from a logical model, you can use denormalization mappings to improve
performance in the physical model implementation.
Unlike a manual edit of the physical model, a denormalization mapping provides a record of what has been changed
and retains the link back to the logical model (visible in the Table Editor Where Used tab). This makes the
denormalization self-documenting, and reduces the manual labor required when merging with an updated logical
model. Also, a mapping can be undone at any time (see Undo a Denormalization Mapping).
The following denormalization mappings are available:
• Roll Up Denormalization: Remove one or more unnecessary child tables, consolidating their columns into the
parent table. (All tables must share the same primary key.)
EMBARCADERO TECHNOLOGIES > ER/STUDIO® 8.0.3 USER GUIDE 210