ER/Studio Data Architect - Recent changes [en]

Release Notes

Jason.hahn — Fri, 01 May 2026 03:08:22 GMT

‎Bugs Fixed in ER/Studio 21.0.1

Release Notes

Nadja.pollard — Fri, 01 May 2026 02:05:52 GMT

‎Bugs Fixed in ER/Studio 21.0.0

What's New

Nadja.pollard — Fri, 01 May 2026 02:04:54 GMT

Logging In and Out of the Repository and ER/Studio TS

Nigam.agarwala — Mon, 20 Apr 2026 19:12:56 GMT

Creating and Editing Auxiliary Tables

Nadja.pollard — Mon, 20 Apr 2026 17:41:32 GMT

Dimensional Table Types Indepth

Nadja.pollard — Mon, 20 Apr 2026 17:35:43 GMT

External Table Properties

Nadja.pollard — Mon, 20 Apr 2026 17:27:50 GMT

‎Oracle 12c and Later Options

Defining Table Storage

Nadja.pollard — Mon, 20 Apr 2026 17:17:05 GMT

‎IBM DB2 Common Server and IBM DB2 for LUW Table Storage Options

Release Notes

Jason.hahn — Mon, 20 Apr 2026 00:07:52 GMT

‎Known Issues

File:ReadMe210v2.pdf

Nadja.pollard — Fri, 17 Apr 2026 22:09:53 GMT

Nadja.pollard uploaded File:ReadMe210v2.pdf

New page

Release Notes

Eric.revollo — Fri, 17 Apr 2026 21:00:49 GMT

Eric.revollo imported Release Notes by file upload (1 revision)

Show changes

Main Page

Eric.revollo — Fri, 17 Apr 2026 21:00:49 GMT

Eric.revollo imported Main Page by file upload (1 revision)

New page

{{DISPLAYTITLE:Online Help for {{Product}} 21.0.x}}
__NOTOC__<div class="floatleft" style="width: 49%">
== [[Getting Started with ER/Studio Data Architect|Getting Started]] ==

* ★ [[What's New]]
* ★ [[Release_Notes|Release Notes]]
* [[Release_Notes#Important_Installation_Notes|Installation Notes]] | [[Installing {{Product}}|Installation Guide]]
* [[Upgrading From Previous Versions]]
* [[Introduction|Quick Start Guide]]
* [[Tutorials]]

== [[Administrator Guide]] ==

* [[Changing the Location of Shared Files]]
* [[Uninstalling]]
* [[Licensing]]
* [[How to Specify Repository Ports]]
* [[Best Practices]]

== Reference ==
* [[ER/Studio MetaWizard Import/Export Bridges]]
* [[Troubleshooting]]
* [[Using the AI Help Chatbot]]
* [[Glossary]]
* [[Supported Database Platforms]]
* [[AI Model Builder FAQs]]
* [[Table Of Contents]]
</div><div class="floatright" style="width: 49%">

== [[User Guide]] ==

* [[Overview]]
* [[Application Interface]]
* [[Configuring and Customizing]]
* [[Data Modeling Fundamentals]]
* [[Using {{Product}}]]
* [[Working with ERStudio Repository]]
* [[Automating ER/Studio Data Architect]]

== [[ts_en:What_Is_Team_Server|Team Server & Repository]] ==

* [[ts_en:Install_and_Configure_Team_Server_and_Repository|Installation]]
* [[Repository Administration|Administration]]

== [[ETL|ETL/Data Lineage]] ==

* [[ETL Import]]

== [[Related Files]] ==

* [[:Media:ReadMe210v2.pdf|ER/Studio Data Architect Read Me]]
* [[:Media:ReadMe210.viewer.pdf|ER/Studio Viewer Read Me]]
* [[:Media:ERStudio_DA_210_Quick_Start.pdf|ER/Studio Data Architect Quick Start Guide]]
* [[:Media:ERStudio_TS_210_Install_and_Upgrade_Guide.pdf|ER/Studio Team Server and Repository Installation and Upgrade Guide]]

Changing the Location of Shared Files

Eric.revollo — Fri, 17 Apr 2026 21:00:49 GMT

Eric.revollo imported Changing the Location of Shared Files by file upload (1 revision)

New page

{{Parent|Administrator Guide}}

Before changing the location of shared files, note that you must have local administrator privileges.

'''To change the location where {{Product}} stores and searches for shared application data'''

# Choose {{Menu|Tools > Options}}, and then click the Directories tab.
# In the File Path dialog, browse to an existing directory you want to store your shared files.
#:{{Note|{{Product}} creates a directory that does not exist but not a directory path. If your path has multiple levels, it must already exist.}}
# In the Options dialog, click '''OK'''. When closing the dialog {{Product}} creates and/or searches in the changed directory.
# If you are changing the location of any of the following directories, you must also copy the contents of the directory to the new location: <code>DataTypeMapping, Macros</code> or <code>Sample Models</code>.
# Once your changes are complete, you must restart '''{{Product}}'''.

==See Also==

* [[Changing the Diagram File Name]]
* [[Specifying the Location of Shared Data]]

Changing the Diagram File Name

Eric.revollo — Fri, 17 Apr 2026 21:00:49 GMT

Eric.revollo imported Changing the Diagram File Name by file upload (1 revision)

New page

{{Parent|Working with Objects in the Repository}}

You can rename the file in the Repository that is associated with a selected diagram. The file name is defined by the system when you first add the diagram to the Repository and is initially the same as the '''Diagram Name'''.

Renaming the diagram using the '''Change Diagram Filename''' option does not change the diagram name displayed in '''Diagram Title''' box. You can change the diagram properties and the content of the '''Diagram Title''' box by opening the diagram, choosing {{Menu|File > Diagram}} and then editing the name on the Information dialog.

'''To change the diagram file name'''
# Log in to the Repository.
# Choose {{Menu|Repository > Diagrams > Change Diagram Filename}}.
# In the tree, navigate to and then select the file whose name you want to change.
# Click '''Rename'''.
# In the Change Filename dialog, type a new file name, and then document the file name change in the '''Comment''' field.
# Click '''OK'''.
# Verify that the name change is as you expected, and then click '''Close'''.

{{Note|As with any Version Control Software (VCS), all users should check in all changes and perform a clean get after renaming.}}

==See Also==

* [[Saving Changed Items to the Repository (Checking In)]]
* [[Repository Status Icons]]

Saving Changed Items to the Repository (Checking In)

Eric.revollo — Fri, 17 Apr 2026 21:00:49 GMT

Eric.revollo imported Saving Changed Items to the Repository (Checking In) by file upload (1 revision)

New page

{{Parent|Working with Objects in the Repository}}
__TOC__
The check-in process synchronizes the changes made to the local checked-out item with the Repository version. This process lets you check in an object, such as an entity or an entire diagram, once you are done working with it. {{Product}} attempts to merge all of your modifications into the Repository.

You are prompted to resolve any conflicts that are discovered during the merge process. After you resolve all conflicts and the merge is complete, the merged results are added to the repository and your diagram. The merged results are added to your diagram so that it remains synchronized with the file in the repository.

== Checking In Objects ==
When you check in an object, all of the object's structural and referential integrity (RI) dependencies are checked in as well. You can check in a newly-created object (i.e. an entity which you added to a checked-out diagram) or multiple, selected objects at one time to the repository.

The Repository enforces the following rules when checking in individual objects to help maintain integrity throughout the diagram:
* If you have an object and one or more of its dependencies checked out separately, then when you check in the main object, all of its dependencies are also checked in.
* If you deleted some objects, when you then check in a modified object, all of the deleted objects are also checked in to the repository, regardless of whether they were associated with the modified object.
* If you check in a data dictionary object that is bound to an attribute, and changes to the data dictionary object affect the attribute, then the attribute is marked for a delayed check out.

== Checking In a Data Dictionary ==
When you check in a Data Dictionary, the Repository server may create new versions of objects that were bound to individual Data Dictionary objects. For example, if you check in a Data Dictionary after deleting a user Datatype, and the user Datatype was bound to an attribute, the server creates a new version of the attribute that does not contain the binding. This is because deleting a Data Dictionary object causes the removal of all bindings to it.

The new version is reflected in the Version History for the attribute, with an automatically-generated comment. When the user does a '''Get Latest Version''' on the affected attribute, the new version without the binding is placed in the user's copy of the Diagram. If the user modifies or deletes the affected attribute before checking in the Data Dictionary, then a merge conflict appears between the user's version of the attribute and the version of the attribute created by the Repository server. Simply select the {{Product}} version of the attribute to keep your changes.

This behavior can also occur when you check in a Data Dictionary with a modified Data Dictionary object. For example, say you change the data type of an Attachment, and then check in the Data Dictionary to which it belongs. Any objects bound to that Attachment must have the value override removed because the value override is only valid for a particular Attachment data type. This means that the objects (which can be in the Data Dictionary or the Diagram) that are bound to that Attachment get a new version in the Repository that reflects the removal of the object's value override.

If you made changes to the Data Dictionary, you need to check in the Data Dictionary before checking in the diagram. For example, if you create a domain in the Data Dictionary and use that domain in the diagram, if you check in the diagram before the Data Dictionary, {{Product}} produces errors.

{{Note|If conflicting changes are detected because multiple people changed the diagram, {{Product}} opens the Review Changes and Resolve Conflicts dialog, where you must resolve any conflicts between the local and remote diagrams before continuing.}}

== Checking In to the Repository ==
The procedure to check in an object into the Repository is basically the same for all object types.

'''To check into the Repository'''

# Save the changes you have made to the diagram by selecting {{Menu|File > Save}}.
# Click the object you want to check in or '''CTRL-click''' several objects to check in more than one.
# Right-click, and then select '''Check in'''. Depending on what you selected, the check-in option on the short menu may be one of the following: '''Check in Diagram''', '''Check in Model''', '''Check in Submodel''', '''Check in Object(s)''', '''Check In Data Dictionary''', '''Check In Data Dictionary Object(s)''', of '''Check In Source/Target or Check In Data Flow'''.
#:{{Note|Checking in the Data Dictionary also checks in any Data Movement Rules defined on the Data Lineage tab.}}
# Complete the Repository Check In dialog as required, and then click '''OK''' to start the check-in process.

If you select '''Review changes''' before check in or if a conflict is detected, you are prompted to resolve the differences between your version and the version on the Repository.

== Change and Conflict Categories ==

In general, the most effective and safest way to handle changes you do not recognize or remember making is to allow them to be checked in to the Repository. Only changes that you make but later decide against should be unchecked.

The following table provides some additional information about the icons used on the Review Changes and Resolve Conflicts dialog to differentiate the differences detected and their default resolutions.

{| class="wikitable"
|-
!Category Icons!!Description
|- valign="top"
|
[[Image:DB_REPO_Resolve_RRvLVAC.gif]]
|
Changes to the local diagram conflict with changes made by other users to the remote diagram in the Repository.

These conflicts are changes that the user performed on items in the local diagram that were also changed by other users who already checked in their changes to the Repository.

For more information on conflicts, see [[#Resolving Check-in and Merge Conflicts|Resolving Check-in and Merge Conflicts]].
|- valign="top"
|
[[Image:DB_REPO_Resolve_RRvLVA.gif]]
|
Additions to the local diagram to items were not otherwise modified in the Repository version by other users.

These additions were made to the local diagram and do not conflict with any changes made to any remote diagrams.
|- valign="top"
|
[[Image:DB_REPO_Resolve_RRvLVD.gif]]
|
Deletions in the local diagram to items were not otherwise modified (in the Repository version by other users.

These deletions were made to the local diagram and do not conflict with any changes made to any remote diagrams.
|- valign="top"
|
[[Image:DB_REPO_Resolve_RRvLVU.gif]]
|
Updates to the local diagram to items were not otherwise modified (in the Repository version by other users.

These updates were made to the local diagram and do not conflict with any changes made to any remote diagrams.
|}

== Resolving Check-in and Merge Conflicts ==

A conflict arises when there is a difference between the version in the Repository and the version checked out to a user. In these instances, you can resolve the data conflict by choosing to accept your version, the Repository version, or a combination of both. A common scenario arises when multiple, simultaneous changes are made to a model.

There are three general types of Repository conflicts:

* An item is updated in a local copy, but deleted in the Repository version.
* An item is deleted in a local copy, but updated in the Repository version.
* An item is updated in a local copy, but is updated differently in the Repository version.

===Resolving Conflicts of Type 1 and 2===

Conflicts have an associated check box, which if selected indicates that the local version is applied. You can view the properties of the item or table updated in the local diagram by expanding the item. Only those properties that are updated are displayed.

If you select the check box of this conflict item, Table A is applied to the local and the Repository version of the diagram and the table is not deleted. However, if the user clears the check box, the remote version of the diagram is applied to the local version, and the table is deleted in the local version of the diagram.

A converse example: an item is deleted locally but updated in the Repository. You can view the properties and the new table values (i.e., see how the table was updated by other users) by expanding the item. Only properties whose values changed are displayed. If you select the check box of the conflict item, the local version is applied and the table is deleted in the local version and the Repository version of the diagram. If you do not select the check box, the table is updated in the local version of the diagram.

===Resolving Conflicts of Type 3===
The Review Changes and Resolve Conflicts dialog box display each new name beneath the table conflict item. The first name property item (new name item) displays the local value for the table name, i.e., the name decided upon by the local user. The second item displays the new value for the table name as it appears in the Repository version of the diagram.

Each item has an option button. If you click the option button of the {{Product}} version of the table name, the local name version is applied to the Repository and the local {{Product}} version. If you select the Repository version, that name goes into effect in the local version of the diagram and stays in effect in the Repository.

Use the following table to understand common check-in conflicts and their resolutions.

{| class="wikitable" border="1"
! rowspan="1" colspan="2" |
Conflict
! rowspan="2" colspan="1" |
Resolution
|-
! rowspan="1" colspan="1" |
{{Product}}
! rowspan="1" colspan="1" |
Repository
|-
| rowspan="1" colspan="1" |
Unchanged
| rowspan="1" colspan="1" |
Modified
| rowspan="1" colspan="1" |
Soft, does not show up in dialog, chooses Repository side.
|-
| rowspan="1" colspan="1" |
Unchanged
| rowspan="1" colspan="1" |
Deleted
| rowspan="1" colspan="1" |
Soft, does not show up in dialog, chooses Repository.
|-
| rowspan="1" colspan="1" |
Unchanged
| rowspan="1" colspan="1" |
Unchanged
| rowspan="1" colspan="1" |
Not a conflict, does not show up in dialog.
|-
| rowspan="1" colspan="1" |
Modified
| rowspan="1" colspan="1" |
Unchanged
| rowspan="1" colspan="1" |
Soft, shows up in dialog with Review Changes enabled, defaults to {{Product}}.
|-
| rowspan="1" colspan="1" |
Deleted
| rowspan="1" colspan="1" |
Unchanged
| rowspan="1" colspan="1" |
Soft, shows up in dialog with Review Changes enabled, defaults to {{Product}}.
|-
| rowspan="1" colspan="1" |
Modified
| rowspan="1" colspan="1" |
Modified
| rowspan="1" colspan="1" |
Hard, shows up in dialog, defaults to {{Product}}.
|-
| rowspan="1" colspan="1" |
Modified
| rowspan="1" colspan="1" |
Deleted
| rowspan="1" colspan="1" |
Hard, show up in dialog, defaults to Repository.
|-
| rowspan="1" colspan="1" |
Deleted
| rowspan="1" colspan="1" |
Modified
| rowspan="1" colspan="1" |
No conflict, shows up in dialog with Review Changes enabled, defaults to {{Product}}
|-
| rowspan="1" colspan="1" |
Does Not Exist
| rowspan="1" colspan="1" |
New
| rowspan="1" colspan="1" |
No conflict, does not show up in dialog, defaults to Repository.
|-
| rowspan="1" colspan="1" |
New
| rowspan="1" colspan="1" |
New
| rowspan="1" colspan="1" |
Not indicated as conflicts in dialog and are resolved either by renaming one of the objects in {{Product}}, or by deleting one of the objects or properties.
|}

{{Note|
*Soft conflicts are shown in the Resolve Conflicts Dialog box when the Review Changes option is selected.
* Hard conflicts are shown regardless of the setting of the Review Changes option.}}

== Sequence Number Changes and Other Automatically-Resolved Differences ==

In large, complex models there can be minor inconsistencies in the way the data is presented. These consistencies do not have a major effect on the data in the model, but they can appear as changes in the review changes dialog. For example, when two foreign key columns exist in a table and have the same name and are not rolenames, they are unified by {{Product}}.

A column exists in the internal data for each relationship that propagates to the table, but only one is shown with that particular name. Which one is shown doesn't matter as they are assumed to refer to the same column in the database.

Occasionally, {{Product}} changes which column it displays based on which internal ID is lower. If the two columns were added at different times and given different sequence numbers within the table, it is possible that when {{Product}} switches which it displays, the ordering of the columns in the table changes. This can cause the sequence numbers of other columns to change as well. Those sequence number changes often show up in the dialog.

Although {{Product}} is designed to handle the deselection of those extra changes, it is generally a better idea to let {{Product}} update itself automatically. It updates the data so that it is consistent. Deselection changes in the dialog might undo some of the changes {{Product}} makes, but not all. In addition, there are some inconsistencies that could lead to corrupted data that cannot be handled by {{Product}} or its Repository Merge functionality.

Often, {{Product}} can identify and correct these inconsistencies before they cause major corruption, but if you deselect the changes, they are not allowed to be checked in, and they are never fixed in the Repository.

==See Also==

* [[Repository Status Icons]]
* [[Securing Repository Objects]]

Repository Status Icons

Eric.revollo — Fri, 17 Apr 2026 21:00:48 GMT

Eric.revollo imported Repository Status Icons by file upload (1 revision)

New page

{{Parent|Working with Objects in the Repository}}

The icons in the following table show check-out status of diagrams and objects contained in Repository. For any one object, check-outs are allowed by multiple users simultaneously. The '''Local''' column illustrates the status of an object that appears on your machine only, whereas the '''Remote''' column illustrates how the same document status appears to other Repository users:

{| class="wikitable"
|-
!Model Objects!!Display Objects!!Local Status!!Remote Status
|- valign="top"
|
[[Image:ICON_RepoStatusLIRI.gif]]
|
[[Image:ICON_REPOSTATUS_LocalCheckedIn.gif]]
|
Checked In
|
Checked In
|- valign="top"
|
[[Image:ICON_RepoStatusLIRO.gif]]
|
[[Image:ICON_REPOSTATUS_LocalCheckedIn.gif]]
|
Checked In
|
Checked Out
|- valign="top"
|
[[Image:ICON_RepoStatus_ExcChckOut.gif]]
|
[[Image:ICON_REPOSTATUS_LocalCheckedIn.gif]]
|
Checked In
|
Exclusively Checked Out
|- valign="top"
|
[[Image:ICON_RepoStatusLORI.gif]]
|
[[Image:ICON_REPOSTATUS_LocalCheckedOut.gif]]
|
Checked Out
|
Checked In
|- valign="top"
|
[[Image:ICON_RepoStatusLORO.gif]]
|
[[Image:ICON_REPOSTATUS_LocalCheckedOut.gif]]
|
Checked Out
|
Checked Out
|- valign="top"
|
[[Image:ICON_RepoStatusLxORI.gif]]
|
[[Image:ICON_REPOSTATUS_LocalCheckedOut.gif]]
|
Exclusively Checked Out
|
Checked In
|- valign="top"
|
[[Image:ICON_RepoStatusLdelORI.gif]]
|
[[Image:ICON_REPOSTATUS_LocalDELCheckedOut.gif]]
|
Delayed Check Out
|
Checked In
|- valign="top"
|
[[Image:ICON_RepoStatusLdelORO.gif]]
|
[[Image:ICON_REPOSTATUS_LocalDELCheckedOut.gif]]
|
Delayed Check Out
|
Checked Out
|- valign="top"
|
[[Image:ERStudio-145.gif]]
|
[[Image:ICON_REPOSTATUS_LocalDELCheckedOut.gif]]
|
Delayed Check Out
|
Exclusively Checked Out
|- valign="top"
|
[[Image:TB_Repo_GetNamedRelease.gif]]
|
[[Image:TB_Repo_GetNamedRelease.gif]]
|
Named Release
|
Named Release
|}

==See Also==

* [[Checking Out Repository Items]]
* [[Working with Named Releases of Repository Diagrams]]

Specifying the Location of Shared Data

Eric.revollo — Fri, 17 Apr 2026 21:00:48 GMT

Eric.revollo imported Specifying the Location of Shared Data by file upload (1 revision)

New page

{{Parent|Configuring and Customizing}}

'''To specify the location of shared data'''

# Choose {{Menu|Tools > Options}}, and then click the Directories tab.
# In the File Path dialog, browse to an existing directory where you want to store your shared files.
#:{{Note|{{Product}} creates a directory that does not exist but not a directory path. If your path has multiple levels, it must be previously created.}}
# In the Options dialog, click '''OK'''. When closing the dialog {{Product}} creates and/or searches in the changed directory.
# If you are moving any of the following directories, copy the contents of the <code>DataTypeMapping, Macros</code> or <code>Sample Models</code> directories to the new location.
# To effect the changes, please restart {{Product}}.

==See Also==

* [[Changing the Diagram File Name]]
* [[Administrator Guide]]

Uninstalling

Eric.revollo — Fri, 17 Apr 2026 21:00:48 GMT

Eric.revollo imported Uninstalling by file upload (1 revision)

New page

{{Parent|Administrator Guide}}

You can uninstall {{Product}} using the Add/Remove Program functionality of the Windows Control Panel.

==See Also==

* [[Installing ER/Studio Data Architect]]
* [[Release Notes]]

@@ Line 54: / Line 54: @@
 *Handles case differences in referenced external views when reverse engineering from Snowflake.
 |-
-| ERS-33337||Validates views that reference replica views immediately upon reverse engineering.
+| ERS-33337||Validates views that reference replica views immediately upon reverse-engineer.
 |-
 | ERS-33338||Properly maintains child view validation when parent views are edited.
@@ Line 62: / Line 62: @@
 | ERS-33419||Validates Snowflake views with inline column comments.
 |-
-| ERS-33431||Improves performance when saving files with many physical models.
+| ERS-33431||Improves performance saving files with many physical models.
 |-
-| ERS-33437||Prevents re-use of database connection in rare conditions.
+| ERS-33437||Prevents re-use of database connection in rare race conditions.
 |-
 | ERS-33444||Improves memory handling and cleanup in Repository service.
 |}

@@ Line 41: / Line 41: @@
 number or click a link below to see the issues addressed in a
 specific build.
 === Bugs Fixed in ER/Studio 21.0.0 ===

@@ Line 4: / Line 4: @@
 The following feature summary areas are available in this topic:
 * [[#21.0.0 ER/Studio Data Architect Features Summary|'''21.0.0''' ER/Studio Data Architect Features Summary]]
 * [[#21.0.0 ER/Studio Team Server Features Summary|'''21.0.0''' ER/Studio Team Server Features Summary]]
@@ Line 27: / Line 28: @@
 * [[#20.0.0 ER/Studio Data Architect Features Summary|'''20.0.0''' ER/Studio Data Architect Features Summary]]
 * [[#20.0.0 ER/Studio Team Server Features Summary|'''20.0.0''' ER/Studio Team Server Features Summary]]
 ==21.0.0 ER/Studio Data Architect Features Summary==

@@ Line 44: / Line 44: @@
 If you want to specify a custom port, you can configure it using ''Computer\HKEY_CURRENT_USER\SOFTWARE\Idera\ER/Studio Data Architect xx.x\Repository. - SSO Redirect URI Port'' where ''xx.x'' is your current ERDA version.
-The current Default port is 54332.
+The current Default port is 54330.
 == Logging in to the Repository using Okta ==

@@ Line 15: / Line 15: @@
 # In the '' Data Model Explorer'', expand the Physical '' Main Model'', right-click the '' Auxiliary Tables '' node, and then select '' New Auxiliary Table''.
 # '' Complete the '' '' Auxiliary Tables Wizard'' '' and then click '' '' Finish'' '' to create the '' auxiliary table''.''
-'''TIP:''' Once you have created the auxiliary table, you can edit it by right-clicking the auxiliary table you want to change, and then selecting Edit Auxiliary Table.
+{{Tip|Once you have created the auxiliary table, you can edit it by right-clicking the auxiliary table you want to change, and then selecting Edit Auxiliary Table.}}
 == Name page/tab ==

@@ Line 6: / Line 6: @@
 {{Product}} supports the following Dimensional table types:
 === Fact ===
-[[Image:ICON_dimension_fact.gif]] Tables with one or more foreign keys and no children.
+[[Image:ICON_dimension_fact.gif|25px]] Tables with one or more foreign keys and no children.
 Fact tables contain individual records, the data for which the database is being designed. Fact tables are the central tables in a star schema.
@@ Line 17: / Line 15: @@
 {{Product}} allows you to further define fact tables as one of the following types:
-* '' Aggregate'': Contains information that is more coarsely granulated than the detail data contained in other tables. For example, in a retail, transactional database, you can have a Sales_Receipts fact table that contains information about individual sales, and a Sales_Monthly aggregate table that aggregates information from the Sales_Receipts table to present information such as monthly sales totals for software, hardware, and services. Aggregates provide quick access to data during reporting; like indexes they improve performance.
+* '''Aggregate'''. Contains information that is more coarsely granulated than the detail data contained in other tables. For example, in a retail, transactional database, you can have a Sales_Receipts fact table that contains information about individual sales, and a Sales_Monthly aggregate table that aggregates information from the Sales_Receipts table to present information such as monthly sales totals for software, hardware, and services. Aggregates provide quick access to data during reporting; like indexes they improve performance.
-* '' Atomic'': Contains detail information, such as the Sales_Receipts table in the discussion above.
+* '''Atomic'''. Contains detail information, such as the Sales_Receipts table in the discussion above.
-* '' Cumulative'': Contains cumulative information such as how long it took to complete the sale by accumulating the time it took between the date of sale and the shipping date for each line item of the sales receipt.
+* '''Cumulative'''. Contains cumulative information such as how long it took to complete the sale by accumulating the time it took between the date of sale and the shipping date for each line item of the sales receipt.
-* '' Snapshot'': Contains time-related information that detail specific steps in the life on the entity. For example, snapshot information for a sale could contain information such as when the order was created, committed, shipped, delivered, and paid for.
+* '''Snapshot'''. Contains time-related information that detail specific steps in the life on the entity. For example, snapshot information for a sale could contain information such as when the order was created, committed, shipped, delivered, and paid for.
 === Dimension ===
-[[Image:ICON_dimension_dimension.gif]] Parents of fact tables.
+[[Image:ICON_dimension_dimension.gif|25px]] Parents of fact tables.
 Dimension tables contain groups of related data, such as dates, hours, minutes, and seconds, represented by one key such as time in a fact table.
@@ Line 32: / Line 28: @@
 {{Product}} allows you to further define dimension tables as one of the following types:
-* '' Fixed Dimension'': The values in the table are not expected to change.
+* '''Fixed Dimension'''. The values in the table are not expected to change.
-* '' Degenerate'': A degenerate dimension is derived from the fact table. Degenerate dimensions are useful when the grain of a fact table represents transactional level data and you want to maintain system-specific identifiers such as order numbers and invoice numbers without forcing them to be included in their own dimensions. Degenerate dimensions can provide a direct reference to a transactional system without the overhead of maintaining a separate dimension table. For example, in the sample model, Orders.dm1, you could create a degenerate dimension that references the Commission Credit ID, Payment Detail ID, and Sales Order ID from the Commission Credit, Payment Detail, and Sales Order Line ID fact tables respectively,
+* '''Degenerate'''. A degenerate dimension is derived from the fact table. Degenerate dimensions are useful when the grain of a fact table represents transactional level data and you want to maintain system-specific identifiers such as order numbers and invoice numbers without forcing them to be included in their own dimensions. Degenerate dimensions can provide a direct reference to a transactional system without the overhead of maintaining a separate dimension table. For example, in the sample model, Orders.dm1, you could create a degenerate dimension that references the Commission Credit ID, Payment Detail ID, and Sales Order ID from the Commission Credit, Payment Detail, and Sales Order Line ID fact tables respectively,
-* '' Multi-Valued'': A multi-valued dimension can help you model a situation where there are multiple values for an attribute or column. For example, a health care bill has a line item of Diagnosis, for which there could be multiple values. Best practice modeling dictates that there should be a single value for each line item. To model this multi-valued situation, you could create a multi-valued table that would capture the diagnosis information and weighs each diagnosis, so that the total adds up to one. This weighting factor allows you to create reports that do not double count the Billed Amount in the fact table.
+* '''Multi-Valued'''. A multi-valued dimension can help you model a situation where there are multiple values for an attribute or column. For example, a health care bill has a line item of Diagnosis, for which there could be multiple values. Best practice modeling dictates that there should be a single value for each line item. To model this multi-valued situation, you could create a multi-valued table that would capture the diagnosis information and weighs each diagnosis, so that the total adds up to one. This weighting factor allows you to create reports that do not double count the Billed Amount in the fact table.
-[[Image:Geography.gif]]
+[[Image:Multi-valued_Dimension.gif|25px]]
-* '' Shrunken'': A shrunken table is a version of the fact table that it is attached to but with fewer attributes in order to draw attention to those specific attributes.
+* '''Ragged'''. In a ragged dimension, the logical parent of at least one member is missing from the level immediately above the member. Ragged dimensions allow for hierarchies of indeterminate depth, such as organizational charts and parts explosions. For example, in an organization some employees can be part of a team which is managed by a team leader, while other employees report directly to the department manager. Another example of a ragged dimension is illustrated in the model below which shows that cities such as: Washington, D.C.; Vatican City; and Monte Carlo do not belong to states.
 === Snowflake ===
-[[Image:ICON_dimension_snowflake.gif]] Parents of dimension tables.
+[[Image:ICON_dimension_snowflake.gif|25px]] Parents of dimension tables.
 Snowflake tables present a more-normalized format where elements of dimension tables are listed. The following example shows two snowflake tables which are parents of a dimensional table. There are many other good examples or snowflake tables in the sample model, Orders.dm1.
-[[Image:Snowflake.gif]]
+[[Image:Snowflake.gif|25px]]
 === Bridge ===
-[[Image:ICON_dimension_bridge.gif]] Implements a many-to-many relationship. Bridge tables support multi-valued dimensions or complex hierarchies. The Bridge is also known as a helper table or an associative table. It is the only way to implement two or more one-to-many relationships or many-to many relationships.
+[[Image:ICON_dimension_bridge.gif|25px]] Implements a many-to-many relationship. Bridge tables support multi-valued dimensions or complex hierarchies. The Bridge is also known as a helper table or an associative table. It is the only way to implement two or more one-to-many relationships or many-to many relationships.
 === Hierarchy Navigation ===
-[[Image:ICON_dimension_hierarchy_navigation.gif]] Used to support complex hierarchies, such as organizational charts.
+[[Image:ICON_dimension_hierarchy_navigation.gif|25px]] Used to support complex hierarchies, such as organizational charts.
 === Undefined ===
-[[Image:ICON_dimension_undefined.gif]] All other tables. Assign this type to flag tables for which you have not yet determined the appropriate type, such as a table with a many-to-many relationship, or a table that is a parent to both a fact table and a dimension table.
+[[Image:ICON_dimension_undefined.gif|25px]] All other tables. Assign this type to flag tables for which you have not yet determined the appropriate type, such as a table with a many-to-many relationship, or a table that is a parent to both a fact table and a dimension table.
 ==See Also==
 * [[Changing the Model Notation]]
 * [[Data Modeling Concepts#The Dimensional Model | Dimensional Model]]

@@ Line 5: / Line 5: @@
 ===Microsoft SQL Server / Azure Synapse Options===
-* '''Location'''. Specifies the folder or the file path and file name for the actual data in Hadoop or Azure Blob Storage. The location starts from the root folder, which is the data location specified in the external data source.
+{| class="wikitable"
-* '''Data Source'''. Specifies the name of the external data source that contains the location of the external data.
+The location starts from the root folder, which is the data location specified in the external data source.
+|- valign="top"
-* '''File Format'''. Specifies the name of the external file format object that stores the file type and compression method for the external data.
 Data Source
-* '''Reject Type'''. Clarifies whether the REJECT_VALUE option is specified as a literal value or a percentage.
 Specifies the name of the external data source that contains the location of the external data.
-* '''Reject Value'''. Specifies the value or the percentage of rows that can be rejected before the query fails.
+|- valign="top"
-** '''Value'''. For REJECT_TYPE = value, REJECT_VALUE must be an integer between 0 and 2,147,483,647.
-** '''Percentage'''. For REJECT_TYPE = percentage, REJECT_VALUE must be a floating value between 0 and 100.
+File Format
-−
+|
-* '''Reject Sample Value'''. Specifies the value or the percentage of rows that can be rejected before the query fails. The ''reject_sample_value'' parameter must be an integer between 0 and 2,147,483,647.
+Specifies the name of the external file format object that stores the file type and compression method for the external data.
+|- valign="top"
-* '''Reject Row Location'''. Specifies the directory within the External Data Source where you want the rejected rows and the corresponding error file to reside.
 ===Microsoft Azure SQL DB Options===
-* '''Data Source'''. Defines the external data source (a shard map) used for the external table.
+{| class="wikitable"
+|-
-* '''Schema Name'''. Maps the external table definition to a table in a different schema. If omitted, the schema of the remote object is assumed to be '''dbo''', and its name is assumed to be identical to the defined external table name.
+!Option!!Description
-* '''Object Name'''. Maps the external table definition to a table.
+If omitted, the schema of the remote object is assumed to be '''dbo''', and its name is assumed to be identical to the defined external table name.
-* '''Distribution'''. When using a database of type SHARD_MAP_MANAGER, the DISTRIBUTION clause specifies the data distribution used for this table. The query processor utilizes the information provided in this area to build the most efficient query plans. Options include:
+The query processor utilizes the information provided in this area to build the most efficient query plans. Options include:
-** '''Sharded'''. Specifies that data is horizontally partitioned across the databases. The partitioning key for the data distribution is the ''sharding_column_name'' parameter.
+* '''Sharded'''. Specifies that data is horizontally partitioned across the databases.
-** '''Replicated'''. Specifies that identical copies of the table are present on each database. It is the user's responsibility to ensure that the replicas are identical across the databases.
+The partitioning key for the data distribution is the ''sharding_column_name'' parameter.
-** '''Round Robin'''. ''Default''. Specifies that the table is horizontally partitioned using an application-dependent distribution method.
+* '''Replicated'''. Specifies that identical copies of the table are present on each database.
 ===Oracle 12c and Later Options===
-* '''Access Driver'''. Options include ORACLE_LOADER and ORACLE_DATAPUMP.
+{| class="wikitable"
-** '''ORACLE_LOADER''' (Default) The ORACLE_LOADER driver performs only data loads and that data must come from text datafiles. Loads from external tables to internal tables occur by reading from the external tables' text-only datafiles.
+|-
-**'''ORACLE_DATAPUMP''' The ORACLE_DATAPUMP can perform both loads and unloads, but the data must come from binary dump files. Loads to internal tables from external tables occur by fetching from the binary dump files while unloads from internal tables to external tables occur by populating the external tables' binary dump files.
+!Option!!Description
+|- valign="top"
-* '''Default Directory'''. Specifies the default directory object location of files read or written by external tables.
 Access Driver
-* '''Access Parameters'''. Specifies the external data source and implements the external table type. Each type of external table has its own access driver that provides access parameters unique to that type of external table.

@@ Line 86: / Line 86: @@
 ! '''Description'''
 |- valign="top"
-|''FIXX''||Specifies a fixed length table, without null data. Select this option to reduce table access time and thus improve performance.
+|''FIXX''||Specifies a fixed length table, without null data. Select this option to reduce table access time and improve performance.
 |-
 |''Table Storage''||Select to enable the ''IN'' and ''PARTITIONED BY'' options. Select ''IN'' to define the RD area of the table, the space where the table and index information is stored.
 Select ''PARTITIONED BY'' to define the partition setting, such as ''(RDINDX19) 10, (RDDATA10)''.
 |-
-|''PCTFREE'' (''PCTFREE'')||Specifies the maximum percentage of space in each data block to reserve for future updates. This reserved space helps to avoid row migration and chaining caused by an update operation that extends a data row's length. Tables that will not be updated should have this value set to 0. Specify '' PCTFREE'' in one of the following formats:
+|''PCTFREE'' (''PCTFREE'')||Specifies the maximum percentage of space in each data block to reserve for future updates.
 *  '' UNUSED-SPACE-PERCENTAGE ''
 *  '' (UNUSED-SPACE-PERCENTAGE, FREE-PAGES-PERCENTAGE-PER-SEGMENT)''
@@ Line 130: / Line 134: @@
 |''Encoding''||Select to enable encoding, and then choose the encoding format desired. Creates a ''CCSID'' statement.
 |-
-|''Restrict On Drop''||Select to prevent users from accidentally dropping the table (removing the table from the database) until the ''RESTRICT ON DROP'' attribute is removed. Creates a ''RESTRICT ON DROP'' statement.
+|''Restrict On Drop''||Select to prevent users from accidentally dropping the table (removing the table from the database) until the ''RESTRICT ON DROP'' attribute is removed.
 |-
-|''Volatile (''VOLATILE'')||Select to define the table as volatile so that when querying the table, the DB2 optimizer uses the indexes defined on the table even though statistics can indicate that using the index would result in slower performance. This prevents the optimizer from using table statistics that are out of date that would result in poor performance.
+|''Volatile (''VOLATILE'')||Defining a table as volatile means that when querying the table, the DB2 optimizer uses the indexes defined on the table even though statistics can indicate that using the index would result in slower performance.
 |-
 |''Log Data Changes (DATA CAPTURE)''||Select to log ''INSERT'', ''UPDATE'', and ''DELETE'' statements.
 |-
-|''Table Procedures (''EDITPROC'' and ''VALIDPROC'')||Specify edit procedures and validation procedures which can be run against the table. Creates the ''EDITPROC'' and ''VALIDPROC'' statements.
+|''Table Procedures (''EDITPROC'' and ''VALIDPROC'')||Specify edit procedures and validation procedures which can be run against the table.
 |-
-|''Audit Option (''AUDIT CHANGES'' or ''AUDIT ALL'')||Specify the audit policy to use to monitor table activity. Audited events are determined by the server's associated audit policy.
+|''Audit Option (''AUDIT CHANGES'' or ''AUDIT ALL'')||Specify the audit policy to use to monitor table activity.
 |-
 |''Index Tablespace''||Displays the tablespace on which the table index is stored. Choose another tablespace from the list.
 |-
-|''LONG Tablespace''||Displays the name of the tablespace on which the long objects (''LOB'','' CLOB'') stored on the table reside. Choose another tablespace from the list if you like.
+|''LONG Tablespace''||Displays the name of the tablespace on which the long objects (''LOB'','' CLOB'') stored on the table reside.
 |-
-|''Log for Replication''||Select to keep a record of all changes in the table. Replication allows you to copy data from a source table to one or more target tables and synchronize the changes in the source to the target.
+|''Log for Replication''||Select to keep a record of all changes in the table.
 |-
-|''Not Logged Initially''||Select to prevent logging on operations that are performed in the same unit of work in which the table is created; however, other operations against the table in subsequent units of work are logged.
+|''Not Logged Initially''||Select to prevent logging on operations that are performed in the same unit of work in which the table is created.
 |}

@@ Line 951: / Line 951: @@
 |-
 | ERS-33104||Reverse Engineer is not completed after getting an error accessing view dependencies.
 |-
 | ERS-33055||Brackets incorrectly placed on DDL generation when names contain three parts.