|
| ICCM.DB.040 - Physical Database Design |
| OMG = Oracle Method Guideline | ||
| OMS = Oracle Method Standard | ||
 |
| General |
| OMS-61518: | When a secondary access element or secondary access controlled element (SAC) is deleted, this should be recorded in the notes of the primary access element or Primary access controlled (PAC) element. |
| Rationale | Analysts or developers might want to know what happened to the SAC. If this kind of information is not recorded, the person that can explain, might not be available on the project, if at all. |
| Example | The deletion of an attribute is recorded in the notes of the entity. | |
| OMS-61537: | Document any deviations of the CDM Standards in the respective Notes, including the OMS Standard code and the reason. |
| Rationale | Documenting these deviations helps your team members understand the decisions that have been made. This is also valuable information for anyone performing QA on the project. | |
 |
Note: If you deviate from any OMS standards on a project level, do not include the deviation for every object. If there is only one Application System involved, then document these deviations in the Description property of the Application System. When there are more Application Systems involved, then it is recommended to document the deviations in a separate document. |
|
| Application Systems |
| Notes | |
 |
| OMS-61517: | Record the deletion of primary objects such as entities, modules, etc. as revision history in the Notes of the Application System. Add new entries on top. |
| Rationale | Analysts or developers might want to know what happened to the object. If this kind of information is not recorded, the person that can explain, might
not be available on the project, if at all. Putting new entries on top gives quick insight into the latest change. |
| Example | REVISION HISTORY Label Date Name Description 1.1 12-11-1999 S. Muller Removed function 31 and module ASP0050F 1.0 06-07-1998 L. Jellema Removed entity STATUS 1.1 ---- Removed function 31 and module ASP0050F because their functionality was dropped as result of tighter planning. 1.0 ---- Removed Entity STATUS, functionality now in domain STATUS |
|
|
| Storage Definitions |
| Storage Label | |
|
| OMS-61592: | Use the following naming convention for the Storage Label: [application code]_[tablespace name]_STOR |
| Rationale | The storage is the default for a tablespace. This naming convention makes it immediately visible for which tablespace. | |
| Initial Extent | |
|
| OMS-61593: | Choose one of the following initial extent sizes: 160K 5120K 160M |
| Rationale | This is following the SAFE Standards. This is to avoid free space fragmentation. | |
| Min Extents | |
|
| OMS-42663: | Always specify 1 for the minimum number of extents to be allocated, with the exception for Rollback Segments. Use 10 for Rollback Segments. |
| Rationale | This is following the SAFE Standards. This is to avoid free space fragmentation. | |
| Percentage Increase | |
|
| OMS-42665: | Always specify a 0 for the percentage by which the following extent will grow over the last extent allocated. |
| Rationale | The use of Percentage Increase causes the Oracle Server to allocate extents of different sizes in the same tablespace, causing fragmentation. | |
|
| Table Definitions |
| Start Rows | |
|
| OMS-42107: | Define the expected initial number of rows in a table as estimated for the Production environment. Specify, if necessary, what the source for this information is in the Notes, using the keyword NO OF ROWS START. |
| Rationale | This information is required for determining the physical requirements of the production environment. |
| Example | BALDRICH 12-NOV-1995 11:00 NO OF ROWS START Based on a count of the number of records in file FGM887 after eliminating duplicates |
|
| End Rows | |
|
| OMS-42108: | Define the expected final number of rows in each table. Specify, if necessary, the source for this information in the Notes, using the keyword NO OF ROWS FINAL. |
| Rationale | This information is required for determining the physical requirements of the production environment. |
| Example | BALDRICH 12-NOV-1995 11:30 NO OF ROWS FINAL File FGM887 grew with an average of 15,000 records a year for the last five years. Taking duplicates entries into account, the table will grow to 1,000,000 rows in the first year. |
|
|
| Sequence Implementations |
| Cycle ? | |
|
| OMS-42357: | Do not cycle sequences. |
| Rationale | This may lead to unexpected Oracle errors due to duplicate values. | |
|
| Index Storages |
| Tablespace | |
|
| OMS-42309: | Assign a tablespace to each index, based in the size of the index, and the estimated rebuild frequency. Group the indexes with similar sizes and rebuild frequencies together. |
| Rationale | This allows for better space management. | |
| Max Trans | |
|
| OMS-61584: | Do not limit the Max Trans for an index. |
| Rationale | Limiting the maximum number of transaction slots is hardly ever useful. Only if a large amount of transactions is expected once for a table, this might be useful to prevent that unnecessary space is taken by transaction slots. Transaction slots are never released for rows when they once have been used. If the figure is set too low, a higher amount of transactions is required than available transaction slots. This results in locking problems. | |
|
| Tablespaces |
| Storage Definition | |
|
| OMS-42643: | Each tablespace should have a default storage assigned to it. |
| Rationale | The default storage definition is used for all segments residing within this tablespace. | |