|
3.2 How to Model an Entity Entities are entered as stereotyped classes. You can do this by selecting a stereotyped class from the pallet by clicking on the Class Diagram Drawer in the palette to open it, finding the class creation section, clicking on the arrow on the right, which will bring up a menu allowing you to select a stereotyped class. Then pick "Create New entity Class" when placing it on the diagram.
Alternatively you can create a standard class from the same place in the palette and add an entity stereotype using the Add Stereotype button in the stereotype tab of the properties view. Normally one attribute should be added for each column on the table that you wish to available in the application. An exception can be made if an automatically updated key field (autokey) is required. If no keys are specified, an autokey called oid will be added automatically. If you are creating and working with new tables, it is recommended that you use the default autokey mechanism as opposed to creating meaningful keys. These can become problematic if the meaning changes. If you are attaching to an pre-existing (legacy) database table, you won't have any choice, and key mappings are discussed in the "How to model keys" page. Normally you should model one entity per table, but it is possible to create multiple entities that attach to a particular table. You might use this feature on a denormalised table where "types" of the record have slight variation in the data contained. By setting a hidden attribute to map the type column different entities can pick up the normalised type information as though it was stored in a single table.
Eg.
Could be mapped to three entities: Person, Man and Woman. The structure of the Man might exclude maidenName. The modeled attributes on Person would be forename, surname, gender and maidenName. Those on Woman would be the same, but gender would be a hidden field with a default value of "F". Attributes on man would exclude maidenName and the gender field would be hidden, with a default value of "M". All three entities would appear different to the application, but would persist to the same table. 
The most immediate property values to set for an entity are name: the name of the entity, tableName: which sets the name of the table the entity persists into and userNameBase: the name that will appear on the screen, rather than the name which is used by the computer. The tableName defaults to the entity's name, with upper case letters other than the first letter preceded by an underscore. Certain reserved words not accepted by SQL databases, will be suffixed by _J. The userNameBase can have spaces, odd characters and any capitalisation you want, whereas if the name does not conform to the rules of the platform (J2EE), the transform will alter it accordingly.
The dataSource will normally be set to point to a single SQL database source, however it is possible to set up multiple sources and override the dataSource on the entity. You should be careful not to attempt to query via the dataviews across dataSources. If this type of query is required, you should set up views or aliases within the database and access via a single dataSource. The generateDataViewForEntity property dictates whether a maintenance dataview should be set up for the entity. Normally this should be left as true, unless you want to access the entity from a specially modeled dataview only. Most of the other attributes on the entity don't refer to the entity itself, but the other things that are generated for the entity, such as the maintenance pages. These will be transferred to the dataview that supports those pages directly. For example "container" refers to the position of the maintenance pages in the menus. Top Tips:
Links:
Copyright © 2001-2006 New Technology / enterprise Ltd. | |||||||||||||||||||||
