|
| ICCS.DB.050 - Production Database DDL |
| OMG = Oracle Method Guideline | ||
| OMS = Oracle Method Standard | ||
 |
| General |
| OMG-10042: | Document any unusual design decisions including the reasons in the Notes property of the respective object. |
| Rationale | This helps your team members understand the decisions that have been made. It is also valuable information for anyone performing QA on the project. | |
| 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. |
|
| Server Model Generation |
| OMG-10077: | If you need code control sequences, use either a central code control table (CG_CODE_CONTROLS) for all your applications or a separate code control table for each relevant table ( [table name]_CC ). |
| Rationale | The alternative is a different table for each application system where the table name is [application system
name]_CODE_CONTROLS ). Sometimes the application system name is different from the application code (see also OMS-61605), but you would want the table name to start with the application code instead of the whole application system
name. When you do not make the table name application specific, you do not get any problems if you have multiple versions of the same logical application stored in differently named physical application systems in Designer. (In that case you would have to use a work around such as temporarily renaming the application system while generating modules and code control table.) This also applies when moving to Oracle Repository (Designer 6i): When you structure your project/system into multiple containers, the question that may arise is: how would you know which container to use to give the table its name. |
| Example | Suppose you have the following application systems, which all represent a version of the same logical application system: AID_DEV AID_PROD If you would use application specific names for the code control table, you would get the table names AID_DEV_CODE_CONTROLS AID_PROD_CODE_CONTROLS depending on which application system you generate from, while the result should have been the same for all these application systems. If you choose a central code control table, for each application system you would get the same: CG_CODE_CONTROLS Also if you choose a separate code control table per relevant table, for each application you would get the same, because each application system would contain the same table name AID_INVOICES: AID_INVOICES_CC |
|
 |
Suggestion: If you decide to always use CG_CODE_CONTROLS, there are two arguments that plead for using the same table instance for all your
applications: * If you create a separate CG_CODE_CONTROLS table for each application, you might get conflicting synonym names if a user has access to multiple applications. (This can be solved through alter session set current_schema, but that makes things more complex.) * Suppose you have a database setup with a separate owner for each application and one 'super' user who has access to all applications (each application owner grants access to the 'super' user and the 'super' user has synonyms t o the application owner's objects), where users log in with either a username that is not a database user or a username which has no privileges. Once successful login is confirmed, the security system logs in with the 'super' user. In that case, on the database you must have either different names, or a single CG_CODE_CONTROLS table. You cannot have one CG_REF_CODES per application. So if the end users only have access to one application system, create CG_CODE_CONTROLS in the application owner schema and reverse engineer the table into the Designer application system. And if the end users might need access to more than one application system, create CG_CODE_CONTROLS in a central schema and let each application owner have a grant/synonym for it; reverse engineer the table to an application system for common objects and share it to the other application systems. |
 |
Generation: By default, a single table CG_CODE_CONTROLS is generated to provide unique identifiers for all modules in the application system. Alternatively, within the General Generator Options dialog box you can set the Scope Of Code Control Table Option to generate a table for a specific application system, or for a specific table. |
| OMG-10078: | If in your forms you want to display online help information in a special help form, use a central online help table (CG_FORM_HELP) for all your applications. |
| Rationale | The alternative is a different table for each application system where the table name is [application system
name]_FORM_HELP . Sometimes the application system name is different from the application code (see also OMS-61605), but you would want the table name to start with the application code instead of the whole application system name. When you do not make the table name application specific, you do not get any problems if you have multiple versions of the same logical application stored in differently named physical application systems in Designer (in that case you would have to use a work around like temporarily renaming the application system while generating modules and online help table). This also applies when moving to Oracle Repository (Designer 6i): when you structure your project/system into multiple containers, the question that may arise is: how would you know which container to use to give the table its name. Also, the standard help form (ofghlpf) attempts to locate help text in CG_FORM_HELP. If you choose the application specific table name and you intend to use ofghlpf to display help text, you must change any references to CG_FORM_HELP in ofghlpf to refer instead to the name of the table created for the application system. |
| Example | Suppose you have the following application systems, which all represent a version of the same logical application system: AID_DEV AID_PROD If you would use application specific names for the online help table, you would get the table names AID_DEV_FORM_HELP AID_PROD_FORM_HELP depending on which application system you generate from, while the result should have been the same for all these application systems. If you choose a central online help table, for each application system you would get the same: CG_FORM_HELP |
|
|
Generation: In the DBA section of the Form Generator Preferences, the preference HPTABL determines the Scope of the online help table. The options are: GENERIC (default) System wide. A single table called CG_FORM_HELP is created to hold online help text for forms generated from all the Repository application systems. APPSYS Application system wide. A table is created for each Repository application system, named [application system name]_FORM_HELP. |
|
Suggestion: If you decide to always use CG_FORM_HELP, there are two arguments that plead for using the same table instance for all your
applications: * If you create a separate CG_FORM_HELP table for each application, you might get conflicting synonym names if a user has access to multiple applications. (This can be solved through alter session set current_schema, but that makes things more complex.) * Suppose you have a database setup with a separate owner for each application and one 'super' user who has access to all applications (each application owner grants access to the 'super' user and the 'super' user has synonyms to the application owner's objects), where users log in with either a username that is not a database user or a username which has no privileges. Once successful login is confirmed, the security system logs in with the 'super' user. In that case, on the database you must have either different names, or a single CG_FORM_HELP table. You cannot have one CG_FORM_HELP per application. So if the end users only have access to one application system, create CG_FORM_HELP in the application owner schema and reverse engineer the table into the Designer application system. And if the end users might need access to more than one application system, create CG_FORM_HELP in a central schema and let each application owner have a grant/synonym for it; reverse engineer the table to an application system for common objects and share it to the other application systems. |
| OMS-61572: | Do not check the Generate Valid Value Constraints option when running the Generate Database from Server Model utility. |
| Rationale | Setting this option leads to the generation of inline check constraints for allowable values. In case of inline check constraint, the set of allowable values can only be altered by dropping and recreating the table. The same functionality can be achieved by using outline check constraints. | |
|
| 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 |
|