Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Table Naming Conventions
If you attend a database class in school they will tell you table
names are always plural. Each row in a table represents one instance
of an entiry e.g. each row in Employees table represents (attributes
of) one single employee. A table represents all rows/instances of the
entiy (employee) collectively and hence should be plural.
>From One of our naming std documents.........
Entity models a thing of substance to business and its name must be the same as the business counterpart it represents e.g. employee, department, lab_value etc. Any smart scheme (add needless suffixes like _t or _master or use of abbreviations (when you haven't hit 30 char name limit) will only deviate you from the prime business term/concept.
Entity attributes are properties of the business entity being modeled and also must follow the business terms used to describe those properties.....
On use of Designer....
Tables and columns are a physical model rendering of the logical model and a tool like Designer will automate the derivation of the physical model from the logical model. In a way you are deriving names of the schema artifacts from the logical model. That pegs all the different manifestations of a business entity (entity, table, object) to one source(logical model). That should make it easier to maintain consistency across models by using business terms as a root for representing a concept. If you modify the root you can rerun the derivation process and percolate the changes downstream.
Gaps in mapping Business World to Physical Model...
In the physical model you may have additional attributes associated with the entity which do not have a mapping to the physical world e.g. surrogate keys (a.k.a aritificial entity identifiers). Designer stores 3 names for an entity, an entity name (should be the business entity being modeled), plural name (used to name tables generated from the transformation of the entity), and the entity short name (used as a prefix of the physical model artifacts which do not map to business entity/attributes directly (e.g. generated primary keys are <short name>_pk and surrogate keys are <short name>_id etc.). Since this tool encapsultes prebuilt name derivation rules, you'll benefit from using it rather than having to debate how to name such (non-mapping) artifacts.
Use of domains is another force mutiplier. It provides a place to docuement a business term once and then reuse its definition at various places (as definition of attributes/columns).....
Sundeep Maini
Consultant
Currently on Assignement at Caterpillar Peoria
sundeep_maini_k_at_cat.com
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: sundeep maini INET: sundeep_maini_at_yahoo.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).Received on Wed Jul 31 2002 - 18:27:10 CDT