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)..... --- kkennedy <[EMAIL PROTECTED]> wrote: > Just as a style issue, I like the distinction made by Oracle Case, > I mean Designer 2000, or is that Designer 6i, or is it Designer 9i > (I'm so confused). In the CASE*Method, entity names are singular > in the logical model and become plural when transformed into table > names in the physical model. > > In my current shop, table names are singular -- I could tell right > away that they didn't use Designer. I don't think it matters much > except that consistency is nice. > > Kevin Kennedy > First Point Energy Corporation > > If you take RAC out of Oracle you get OLE! What can this mean? > > -----Original Message----- > Sent: Wednesday, July 31, 2002 7:49 AM > To: Multiple recipients of list ORACLE-L > > > Many thanks to all for your feedback and advice! As I suspected, > naming > conventions are really a matter of someone's personal preference, > and > what's really important is to keep it standard and consistent. > > One [hopefully] last question: What's the consensus (if there is > such a > thing) on plural vs. singular table names? > > Gary Chambers > > //------------------------------------- > // Lucent Technologies GIO/Unix > // 4 Robbins Road, Westford, MA 01886 > // 978-399-0481 / 888-480-6924 (Pager) > // Nothing fancy and nothing Microsoft > //------------------------------------- > > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Gary Chambers > INET: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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). > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: kkennedy > INET: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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). ===== Sundeep Maini Consultant Currently on Assignement at Caterpillar Peoria [EMAIL PROTECTED] __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: sundeep maini INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
