|
| ICCM.MD.090 - Application Code |
| 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. |
|
| Drawing conventions |
| The most convenient way to represent the entity information is in the form of one or more entity relationship diagrams, and the drawing conventions are explained in that light. Standards automatically enforced by Oracle Designer are not included. |
| Relationship Lines | |
 |
| OMS-61507: | Relationship lines should be drawn one to many, from top to bottom and left to right, to the extent that this is possible. |
| Rationale | By keeping the directions of the relationships the same way, it is easier to read the diagram as you would only need to read in the same direction. Also similar constructions are easier to recognize. | |
|
| 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. | |