Naming Conventions

---

In creating your classes and objects, it's important to develop and follow a consistent naming convention, following a four Cs rule. They should be the following (listed in order of priority):

Customer Oriented Your universe is for your internal and/or external customers, so you must use business terminology. Anything that reveals technical database-naming conventions does not belong in a universe.

Clear The class and object names must be clear in their meaning. Customer is not clear if it could potentially mean Ship To Customer or Sold To Customer. Think back to the universe design principles discussed in Chapter 5. Who is the target user group for your universe? If these users know of only one type of customer, then Customer alone is acceptable as an object or class name. For example, supply chain personnel may only think of the ship to customer, and accounting personnel may only think of the invoiced or sold to customer. If these two groups of users will have separate universes, then Customer is acceptable; if they will share a universe, then the names must be clear and explicit.

Consistent Object names should be consistent in two respects. First, use the same name when you mean the same thing. Always refer to the customer as the customer, and do not mix in other terminology such as client or business partner. Second, use the same clarifiers consistently. If your universe has columns that are IDs or codes and columns that are names or descriptions, then append these clarifiers consistently as Table 8-1 illustrates.

Table 8-1: Object Names Should Follow the Four Cs: Be Customer Oriented, Clear, Consistent, and Concise

Initial Object Name	Potential Problem	Consistent Object Name
Article code	NA. This object name is consistent, assuming article is the generally used business term. The code name qualifer makes it clear.	Article code
Article name	NA. This object name is consistent, assuming article is the generally used business term. The code name qualifer makes it clear.	Article name
Article	It's not clear if this object refers to an article code or a description, unless all description fields have name or description appended at the end of the object name and, by default, everything else is a code or a number.	Article code
SKU	Duplicate of Article code and not the generally accepted business term. However, it is concise, which would make for a nice column heading in a report.	Article code
Product	Duplicate of Article code or SKU. Also, not clear if this is a code or a description object.	Article code
Gmid	Gmid is the abbreviation for global material identification used in the OLTP; data entry users know the term, but business users within the target universe group do not.	Article code

Concise Object names should be concise, as they become the default column heading in a report. The bad thing about this is that Article code can be a long column heading if most of your article codes are only four characters long. In such a scenario, the abbreviated form SKU or Gmid may make for shorter and better column headings.

It would be a nice feature if Designer allowed you to centrally rename a column heading (just as SQL does), but unfortunately, it does not. Column headings can be renamed and wrapped within individual reports. Therefore, you can consider clear business terms a higher priority than concise column headings.

Warning: Object IDs

In early versions of BusinessObjects, object names within individual user queries and reports had to match object names within the universe. For example, in the Test Fashion universe, there is a Month object. Unless users look at the data, users are not sure whether this is the month name, a number, or a three-character abbreviation. As a universe designer, you can rename Month to Month number in the universe and all the user reports will automatically reflect this new object name. This is enabled through use of an object ID number that was introduced in BusinessObjects version 4. Prior to version 4, BusinessObjects would look for the Month object by name (which no longer existed) and give the users an error.

Table 8-2 shows how Designer stores object information in the UNI_OBJECT repository table. The BusinessObjects repository is discussed further in Chapter 15; here, however, it is important to note that the OBJECT_ID for Month is 14.

Table 8-2: Object Names Are Assigned an OBJECT_ID Within the BusinessObjects Repository Tables

OBJECT_ID	UNIVERSE_ID	CLASS_ID	OBJ_NAME	OBJ_HIDDEN	OBJ_POSITION
14	11	2	Month	N	0
59	11	2	Month Number	N	1
13	11	2	Month Name	N	2
7	11	2	Week Key	N	3
8	11	2	Week In Year	N	4
11	11	2	Year Week	N	5
12	11	2	Quarter	N	6
10	11	2	Fiscal Period	N	7
9	11	2	Year	N	8
15	11	2	Holiday Flag	N	9

Often in renaming objects, a universe designer will make the mistake of cutting and pasting the original Month object to a new object titled Month Number, OBJECT_ID=59. The universe designer will then go back and delete the original Month object (after testing it or after a defined user acceptance period). Once the original Month object is deleted, all existing reports that previously used the Month object will generate an error that the Month object is missing. If the universe designer had modified the original Month object, OBJECT_ID=14, then the existing queries and reports would have automatically been updated with the new object information.

This use of OBJECT_IDS is also what allows BusinessObjects to handle changes to underlying SQL, help text, list of values, and so on, without the users knowing that the underlying metadata may have changed.

To minimize report errors, take these three precautions:

1. Maintain a printed copy of all object IDs.

2. Modify existing objects when you really wish to change the name or underlying SQL; avoid re-creating new objects to replace old ones.

3. Always make an offline, backup copy of a universe. One client I worked with deleted a number of objects accidentally. The designer thought he had fixed the problem by simply re-creating the objects with the exact same object names (which didn't work). A backup version of the universe allowed us to more quickly access and restore the original OBJECT_ID numbers.

---