Data model nomenclature and standards

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Best practices and implementation guidelines > Best practices in Data Model >

Data model nomenclature and standards

Overview

The following section lists suggested nomenclature so that you define your Data model in a way that promotes usability, maintainability and legibility for you and your team members.

 

A clear and standard naming of the different entities and attributes of the Data model is fundamental for intuitive and easier building (i.e Xpath navigation) and communication, and for a better understanding of the processes for any team member doing changes.

 

Entities nomenclature

By relying on a standard to name your entities will save you time during the implementation of your projects and when doing changes to them in a future.

 

1. Entities definition

Entities names should clearly describe the information their contain. Ensure that you do not use short names or abbreviations.

 

BPDatamodel2

 

 

2. Suggested nomenclature for entities

We recommend using a nomenclature for entities that clearly identifies its type and scope.

The entities can be categorized by several criteria:

 

Entity Type (Master, Parameter).

To facilitate the generation of reports, it is suggested to use the following infix character for entity types:

oP: Identifies the entity as parametric.

oM: Identifies the entity as master.

 

Scope Type (Private, Public).

oPrivate: Used within one process.

oPublic: Used in more than one process. ie. Customer, DocumentType, etc.

Therefore, it is suggested to use prefixes to name private entities, specifically by using 3 characters based on the name of the process.

 

Examples.

Entity: Customer

Type: Master

Scope: Private (used by the process Customer Request)

Name: M_CR_Customer

 

Entity: City

Type: Parameter

Scope: Private (used by the process Customer Request)

Name: P_CR_City

 

Entity: Signatures

Type: Parameter

Scope: Public (used by several processes)

Name: P_Signature

 

 

Attributes nomenclature

By relying on a standard to name your attributes will save you time during the implementation of your projects and when doing changes to them in a future.

 

1. Attributes definition

Give attributes a short and clear name that allows an easy mapping when designing forms, expressions or when configuring interfaces.

It is recommended to try to use the same name that will be displayed in the Forms.

 

2. Suggested nomenclature for attributes

We recommend using a nomenclature for attributes that clearly identifies its type, by relying on prefixes.

 

Note that names of attributes should have less than 15 characters (including any prefix it may have).

Use singular names for them, though use plural names every time you use collections, ie. xRequests, xCustomers, xDocuments.

 

The following table shows the suggested prefixes according to the attribute type:

 

Attribute type

Prefix

Example

Boolean

b

bCustomer, bActive

Currency

c

cSalary, cDiscount, cPrice

Date – Time

d

dBirth, dCreated

Integer, Big Integer, Small Integer, Tiny Integer

i

iDistance

String, Extended text

s

sNotes

File

u

uPhoto, uAttachment

Float

f

fRate, fDiscount

Image  

img

imgProfile

Real

r

rGreatDistance

Entity

km, kp (km for master, kp for parametric)

kmCustomer, kpCurrency

Collection

x

xElements, xRequests,

xMembers