|
3.1 How to Model the Table Structure The tables will usually be stored in an SQL database. This may be an existing database, in which case you will need to map the model to the existing structure, or a new database, in which case you can model the structure from scratch. Creating a database from scratch for a large project is the specialist job of a database administrator, however all the basic elements can be modeled by someone with some experience of modeling entity-relationship or class diagrams. This will create a database structure which can be subsequently optimised if necessary by a DBA for large scale use. Modeling haphazard denormalised table structures will work, but it is not recommended for scalability. The primary unit for modeling a table is the entity and the column is modeled using an attribute. Relationships between entities should be modeled explicitly. Entity inheritance is not currently supported. One-to-one relationships styled as contained are preferred. Diagrams that hold entity information should probably be kept separate from presentation information, especially for larger systems. It is a good idea for models with more than around twenty or so entities to consider splitting them down by functional area. If you can keep these down to fifteen entities or less on each diagram, so much the better. It is okay to duplicate the symbol of an entity of multiple diagrams, it will still only come out once in the application. This is not the place for a detailed description of entity relationship modeling, however those more used to creating class diagrams should be aware that although the objects used are classes and associations, some of the modeling that you might be expecting to have to do is unnecessary. It is necessary to add attributes that you expect to appear as columns in the table. If you don't add a key, one will be generated for you, it will be hidden and automatically updated. It is necessary to add relationships, and their multiplicities. It is a bad idea to model operations on entities unless you want to deviate from the out-of-the-box architecture. Accessors and mutators (getters and setters) are created automatically, queries are handled in dataviews and business functionality should be placed on sessions. By default a set of maintenance screens will be created to manipulate the data in the tables. It is likely that you would only want to give these screens to an administrator. Normal business user functionality should be modeled as process. Top Tips:
Links:
Copyright © 2001-2006 New Technology / enterprise Ltd. | |||||||||||||||||||||
