Langue véhiculaire : /
Nombre de leçons : /
Nombre minimal de devoirs par trimestre : /
Nombre minimal de devoirs par semestre : /
Dernière mise à jour par la CNES : 21/09/2023
Naming Conventions for Database Modeling
Purpose
The purpose of this document is to establish a comprehensive naming convention and a set
of guidelines for database modelling across all three steps:
• Conceptual Data Model (CDM)
• Logical Data Model (LDM)
• Physical Data Model (PDM)
By adhering to this naming convention, we aim to ensure clarity, organization, and
consistency throughout the database modelling process.
Language Usage
English is the preferred language for data modelling, but German or French can be used if
necessary. Whichever language is chosen, it must be consistently applied throughout the
entire model (CDM, LDM, or PDM) to maintain clarity and avoid confusion.
Conceptual Data Model (CDM)
Naming Conventions
• Class names: One or more singular nouns in UpperCamelCase notation.
• Attribute names: One or more singular nouns in lowerCamelCase notation.
• Class and attribute names should accurately reflect their meaning or purpose.
• Class names must be unique across the CDM.
• Attribute names must be unique across a class.
• When using abbreviations, ensure they are self-explanatory and easily
understandable.
Relationships
• Relationship names: A verb in the 3rd person singular form (e.g., "lives," "works") and,
if necessary, a singular noun (role), using lowerCamelCase notation.
• Association classes: The association name must be repeated as the name of the
association class.
• Association names must accurately describe the relationship between two classes.
Avoid using trivial verbs that provide little meaningful information.
• If finding an appropriate verb is challenging, consider using descriptive constructs like
"isLocated," following the lowerCamelCase notation.
• Association names must be unique within the model.
Cardinalities
• Use values 0, 1, and * (or "n") separated by "..".
• Multiplicity "1..1" can be written as "1".
Formatting and Presentation
• Avoid crossing association lines and maintain a neat layout.
• Write cardinalities outside classes.
• Use a dotted line to connect an association class to the verb describing the association.
Example
Logical Data Model (LDM)
Naming Conventions
• Transpose the CamelCase notations of the CDM identically.
Primary Keys
• Each class must have a primary key consisting of one or more attributes.
• Prefix each field that is part of the primary key with "pk_".
• If a class lacks a natural candidate attribute for a primary key, create a surrogate
primary key using the prefix "pk_" followed by the class name.
Foreign Keys
• Prefix each field that is part of a foreign key with "fk_".
• Foreign key names consist of:
o Prefix "fk_".
o The name of the referred table.
o The verb describing the association.
• For association tables, follow the same rules as above but do not include the verb
describing the association (i.e. the name of the association table).
Combined Primary and Foreign Keys
• Merge the prefixes "pk_" and "fk_" to form "pkfk_" if a key serves as both a primary
key and foreign key.
Relationship Lines
• The line with the arrow of a foreign key should point at the corresponding primary
key.
Example
Extended version of Logical Data Model (Formation DT-Informatique)
The extended version is used in technician training. Data types are named behind the
attribute name. Extended attribute properties are stored in the LDM as follows:
• AI: The attribute is implemented as an auto-increment
• NN: Null Value is not allowed for this attribute
• UQ: The attribute is unique
• If a default value should be assigned to a specific attribute, it is announced as footnote.
Example:
Physical Data Model (PDM)
General Naming Conventions
• Transpose the CamelCase notations of the LDM identically.
• The name of a view, stored procedure, function, or trigger should accurately reflect
its meaning, purpose, or functionality and follow the lowerCamelCase notation.
• When using abbreviations, ensure they are self-explanatory and easily
understandable.
Prefixes
• Prefix the following elements with specific prefixes:
o "vw_" for views. Example: vw_customerOrders
o "sp_" for stored procedures. Example: sp_getCustomerByID
o "fn_" for user-defined functions. Example: fn_getAveragePrice
o "tr_" for triggers. Example: tr_updateOrderStatus
Indexes
• Each index must be prefixed by "idx_" followed by the type of index and the field
name. Example: idx_unique_ssn for a unique index on the "ssn" attribute.
Foreign Key Constraints
• Each foreign key constraint must be prefixed by "fkc_", followed by the name of the
source table, the verb describing the association between the two tables, and the
name of the target table. Example: fkc_Person_lives_Country
• For foreign key constraints in an association table, follow the same rules as above, but
do not duplicate the association table name and the verb.
• For foreign key constraints of reflexive associations, append the role at the end of the
name.
Stored Procedures and Functions
Variable Names
• Variable names must be descriptive, meaningful, and concise.
• Use lowerCamelCase notation for variable names.
• Prefix variables with "v_". Example: v_customerName
Constants and Literals
• Constants and literals should be named using all capital letters with underscores to
separate words. Example: MAX_ITEMS_PER_ORDER, ERROR_MESSAGE
Parameter Names
• Parameter names must be descriptive, meaningful, and concise.
• Use lowerCamelCase notation for parameter names.
• Prefixes for parameters:
o "in": Input parameter used to pass values into the stored procedure.
o "out": Output parameter used to return values from the stored procedure.
o "inout": Parameter used for both input and output.
Example: in_idCustomer, out_customerName.
