World Wide Tutorial

1. Vocabulary
An entity is a set of data consistent with common characteristics (PERSON VEHICLE ...)
A relationship (or association) is a means to connect, often by a two or more entities (person LEADS vehicle)
An attribute is a property or characteristic qualifying entity (personne.SEXE, vehicule.IMMATRICULATION). It has a name and type of data
One area is the set of values that may take attribute. (Sex = [MAN, WOMAN])
The cardinality is the number of possible links of a relationship (person drives 0 or 1 vehicle, person owns the vehicle or N 0)
An ID is an attribute or an attribute together to identify a single instance of an entity (No social security 1600475112335 can identify a single person)
A foreign key is an attribute of a relationship which refers to the key relationship to another: so that we can link several relations

2. Consideration general

2.1. Modeling tool
Any database will be modeled by an external tool to target the product:
♦a conceptual model (logic model) and physical (organization of data)
♦the choice of diverse and numerous targets RDBMS
♦using a method known and widespread as MERISE, E / R or UML

Here is a list of several solutions modelling workshop:

DataBase Design Studio of Chile Source Software	http://www.chillisource.com/
DeZign for DataBases of Datanamic	http://www.datanamic.com/
ERWin Computer Associates	http://www3.ca.com/Solutions/Product.asp?ID=260
Next Mega Mega International	http://www.mega.com/
PowerDesigner of PowerSoft (formerly AMC Designor *)	http://www.sybase.com/products/enterprisemodeling/powerdesigner
Win'Design of Cecima	http://www.win-design.com/en/index.htm
xCase of Resolution	http://www.xcase.co.il/
DataArchitect of theKOMPANYcom	http://www.thekompany.com/products/dataarchitect/
Rational Rose Rational Software	http://www.rational.com/
Studio Case 2 of CharonWare	http://www.casestudio.fr
ER Studio Embarcadero	http://www.embarcadero.com/
Microsoft Visio (ex infomodeler of Synactics)	http://www.microsoft.com/office/visio/
Silverrun Magna solutions	http://www.silverrun.com/
System Architect of Popkin	http://www.popkin.com/products/sa2001/systemarchitect.htm
Designer 2000 Oracle (mono base)	http://www.oracle.com/ (???)
Casewise	http://www.casewise.com/
QuickUML Excel (Windows and Linux) Excel Software	http://excelsoftware.com/quickumllinuxnews100.html
MacA & D / WinA & D Excel Software	http://excelsoftware.com/richdatamodel.html
Select from Aonix	http://www.aonix.com/

The heavyweights are: Power Designer (ex Designor AMC), ER Win, and Rational Rose. Finally, for information, here are some links on the methods and modeling tools of all kinds:
♦http://www.cs.queensu.ca/Software-Engineering/toolcat.html
♦http://www.aisintl.com/

2.2. Standardization
The models will be required to meet the first three normal forms (1NF, 2NF, 3NF).
Wherever possible we will abide by the normal forms of Boyce Codd (BCNF) and the 4th and 5th normal forms provided that it does not further disadvantage for writing motions and treatments that benefit.

Reminders:

1NF First normal form	A relationship is in first normal form if and only if: -- Any attribute contains an atomic value. * Each entity must have an identifier that characterizes    uniquely).
2NF Second normal form	A relationship is in second normal form if and only if: -- It is 1NF, -- Just do not attribute to a key depends not only part    that key. * The properties of an entity should not depend solely on the ID    the entity and not a part of this identifier
3NF Third normal form	A relationship is in third normal form if and only if: -- It is in 2NF, -- Just do not attribute to a key does not depend on a non-key attribute. * The properties of an entity must depend on the ID of the entity    in a direct way
BCNF Standard Form BOYCE-CODD	A relationship is a normal form of BOYCE-CODD (BCNF) if and only if: -- It is in 3NF, -- And only the only functional dependencies Elementary    it has are those in which a key determines    an attribute. * For identifiers composed of several properties, these    must not be dependent on another property    of the entity.
4NF Fourth normal form	An association is a 4FN if and only if: -- It is BCFN -- Where there is a dependency multivaluée Basic, the latter    is unique. * Any relationship has a breakdown in the fourth normal form    is without loss. This decomposition is not necessarily unique.
5NF Fifth normal form	An association is a 5FN if and only if: -- It is 4FN -- And if it does not have a DJ or any dependence join    is implied by key candidates R. * The fifth normal form is a generalization of the fourth form    Standard that requires taking into account dependencies join    induced by the knowledge of the keys to a relationship

There is additional information on the forms to normal following URL.
♦http://philippe.guezelou.free.fr/mcd/mcd.htm
♦http://www.bd.enst.fr/polyv7/chap5.htm
♦http://tcosnuau.free.fr/COURS/MODREL/MODREL.HTM

3. Naming objects
The names of objects of a model or a scheme should be meaningful and relevant. They will be consitue only following characters:

[.. z] + [A .. Z] + [0 .. 9] + [_]
With the following restrictions:
♦not to exceed 128 characters
♦does not start with a figure
♦can have several characters "White stressed" immediately
♦breakage does not matter
♦the name should not be a word reserved SQL (see this topic: THE WORDS OF KEY SQL)
ATTENTION: In other words, accented letters (e a u I E ...), "Yale" (ç œ ...), punctuation (,,:? ...) And other special characters, as white, are prohibited.

Examples:

_TOTO	Allowed
123TOTO	Prohibited
TITI__TATA	Prohibited
_toto	Authorized (but identical to the first)
Truth	Prohibited

CAUTION:
We reserve the names in the tiny logic models and the names capitalized physical models.

Example:

customer	logical name (for example entity)
T_CLIENT_CLI	physical name (for example table)

and their length should take into account limits the number of characters used in the names of objects RDBMS and variables of the programming language internal RDBMS (triggers and stored procedures).

3.1. Name a server
The name of a server must begin with the prefix SRV_ followed by a relevant indication.
Examples:

SRV_GESTION	for a database server management
SRV_FO	for a server "front office"

3.2. The name of a database
The name of a database must begin with the prefix BD_ followed by a relevant indication.
Examples:

BD_GESCOM	Database GEStion COMmerciale
BD_SUIVIPROD	Database MONITORING of PRODuction

3.3. Fields
A field must always begin with the prefix D_ followed by a letter indicating the type of family among the following:

D_A_	Area family string
D_B_	Area family binary
D_N_	Area family digital
D_T_	Area family time

It must be followed by a name indicating its use.
Examples:

D_N_POURCENT	Real between 0.0 and 100.0
D_N_ID	Digital identification integer
D_A_ADRESSE	Channel character varchar (32)
D_T_	D_B_BOOLEEN

Boolean
The best was from a list of default domain that one takes systematically for each base.
For example:
CREATE DOMAIN D_A_ADRESSE as VARCHAR (32)
CREATE DOMAIN D_A_CAR as CHAR (1)
CREATE DOMAIN D_A_CODE as CHAR (8)
CREATE DOMAIN D_A_CODE_COURT as CHAR (4)
CREATE DOMAIN D_A_CODE_LONG as CHAR (16)
CREATE DOMAIN D_A_CODE_POSTAL as CHAR (8)
CREATE DOMAIN D_A_LIB as VARCHAR (32)
CREATE DOMAIN D_A_LIB_COURT as VARCHAR (16)
CREATE DOMAIN D_A_LIB_FIXE_COURT as CHAR (32)
CREATE DOMAIN D_A_LIB_FIXE_LONG as CHAR (64)
CREATE DOMAIN D_A_LIB_LONG as VARCHAR (64)
CREATE DOMAIN D_A_MAIL as VARCHAR (128)
CREATE DOMAIN D_A_NOM as CHAR (32)
CREATE DOMAIN D_A_PRENOM as VARCHAR (32)
CREATE DOMAIN D_A_TEL as CHAR (20)
CREATE DOMAIN D_A_TEXTE as VARCHAR (2000)
CREATE DOMAIN as TXT D_A_TEXTE_BLOB
CREATE DOMAIN D_A_TEXTE_COURT as VARCHAR (1000)
CREATE DOMAIN D_A_TEXTE_LONG as VARCHAR (4000)
CREATE DOMAIN D_A_TITRE as VARCHAR (128)
CREATE DOMAIN D_A_TITRE_COURT as VARCHAR (64)
CREATE DOMAIN D_A_TITRE_LONG as VARCHAR (256)
CREATE DOMAIN D_A_VILLE as CHAR (32)
CREATE DOMAIN D_A_TRIGRAMME as CHAR (3)
CREATE DOMAIN D_B_BOOLEEN as ILO (1)
CREATE DOMAIN D_B_CODE_COULEUR VARBINARY (6)
CREATE DOMAIN D_N_DECIMAL as DECIMAL (16.2)
CREATE DOMAIN D_N_FLOAT as FLOAT
CREATE DOMAIN D_N_INT_COURT as SMALLINT
CREATE DOMAIN D_N_INT_LONG as INTEGER
CREATE DOMAIN D_N_NID as INTEGER VALUES> 0
CREATE DOMAIN D_N_POURCENT as FLOAT VALUES BETWEEN 100 AND 0
CREATE DOMAIN D_T_DATE as DATE
CREATE DOMAIN D_T_DATEHEURE as DATE
CREATE DOMAIN D_T_HEURE as TIME

3.4. Name an entity
It must begin with a prefix:

e_	when it comes to functional entity
er_	when it comes to reference entity
es_	when entity "system"

ATTENTION: The use of the plural should be avoided.

Examples:

e_client	functional entity clients
er_pays	reference entity countries
es_user	entity system users

3.5. The name of a relationship (association)
It must begin with the prefix A:

Example:

r_loue	relationship "rent" between entity e_client and e_maison
r_achete	e_client relationship between buys and e_maison

3.6. Name an attribute
The name of an attribute must be relevant enough to be able to understand the nature of the type of data it represents.
Example:

name	attribute name
date_naissance	attribute date of birth
quantite	attribute quantity

To the extent possible, avoid overly generic names. So it should be outlawed: "number", "date", "type" ...
3.7. The name of a table, a view
It must begin with a prefix:

T_	where it is a functional table	V_
TR_	where it is a reference table	VR_
TS_	when it comes to a table "system"	VS_
TJ_	where it is a join table	VJ_
TG_	where it is a generic table (inheritance)	VG_

It must return the body by the name of the entity, where a default (join table) the name of the relationship if the latter is appointed.
It must be suffixed with a trigram unique within the database, permattant the rapid identification of the table.

Examples:

T_CLIENT_CLI	table functional customers
TR_PAYS_PAY	reference table of countries
TS_USER_USR	table system users
TJ_ACHETE_ACH	join table relationship "purchased"

A view will be prefixed by systematically V_.

3.8. Name, order of creation and size of columns
3.8.1. Order of creation
♦The order of creation and description of columns must meet the following rules:
♦The columns of the most significant and most used will be located at the top of the description
♦Columns less frequently altered or accessed will be located at the end of the description
♦Columns primary key component of the table will be the first described columns of the table
♦The columns component Foreign Keys will be as follows
♦The columns are grouped together when they are part of a significant subset of the table

3.8.2. Names
The column names will be prefixed by the trigram of the original table and resume the name attribute.
Example:

CLI_NOM	column table name T_CLIENT
CLI_DATE_NAISSANCE	dnaissance date column of the table T_CLIENT
FAC_DATE_EMISSION	column issue date of the invoice table

Some commonly used abbreviation will be used:

ID	ID (usually key auto incremented)
NUM	number
REF	Reference
CODE	code, coding, coding
LIB	wording
DSB	order
CP	postcode
ADR	address
FAX	fax
MAIL	e-mail
TEL	phone
GSM	mobile phone
LOG	"login"
PWD	"password"
NBR	number
QTY	quantity
POS	position
NDX	index
MNT	amount
TX	rate
PCT	percentage
PUTC	unit price Taxes
PUHT	unit price excluding taxes

3.8.3. Sizes data columns
In principle the size (and the data format) will be free, and must follow the specification of the application. However, for some fields limits are as follows:
♦The name of a person 36 characters
♦First name of a person 32 characters
♦Name a town 32 characters
♦Address line 32 characters, 4 lines (normalization THE POST)
♦City 32 characters (normalization THE POST)
♦Title of a person 5 characters (abbreviations: "Mr." - "Mrs." - "Miss" - "Me" Master - "Dr." Doctor, etc. ...)
♦3 characters country code (international code)
NOTE: there will be systematic search formats consolidations International (ISO), French codifications (AFNOR standards) and consolidations by branches of occupations (such as standards and IRIS NOEMIE international regime, M21 instruction for health public).

NOTE, WITH RESPECT TO ADDRESS: formats given are those of the French postal service. It should be adhered to in all cases. The Post admits up to 4 lines addresses + a row for the postcode accompanied by the name of the city. In addition, the address must be preceded in principle on behalf of the person and / or the name of the organization (ste., association, union…). Otherwise, shipments in number could not be read by machines and the economy unrealized amounts in thousands of euros.

TIP: in relation to address it is important to specify the cedex in a box "from" in order to facilitate the development of queries on cities.

Thus a good formalization of address should respond to the following description:

CLI_ADR1	VARCHAR (32)
CLI_ADR2	VARCHAR (32)
CLI_ADR3	VARCHAR (32)
CLI_ADR4	VARCHAR (32)
CLI_VILLE	VARCHAR (32)
CLI_CP	VARCHAR (8) - to accept foreign CP
CLI_CEDEX	VARCHAR (32)
CLI_PAYS	VARCHAR (3) - international codification

3.9. Constraints table
Constraints table will be prefixed C_ followed by an indicator of the type of constraint. They will be suffixées by the trigram table.
Indicator type of constraint:

C_PK_	forced to table "primary key"
C_FK_	forced to table "foreign key"
C_UNI_	forced to table "uniqueness"
C_CHK_	forced to table "validity"

♦The constraints of primary key must resume the trigram of the original table
♦Foreign key to resume the trigram of the original table and the table in which they appear
♦The constraints of uniqueness and validity must have a meaningful name

Examples:

C_PK_CLI	primary key constraint on the table score
C_FK_FAC_CLI	foreign key constraint on the table bill on the table score
C_UNI_LOGIN_PASSWORD_CLI	constraint of uniqueness for columns LOGIN and PASSWORD
C_CHK_CP_CLI	forced validity of a postal code

3.10. Index
The index should be prefixed X_ followed an indicator of the nature of the index and a meaningful name. They will be suffixees by the trigram table.

They may choose as an indicator of nature, one of the following abbreviations:

X_CSR_	clustered index
X_BMP_	index "bitmap"
X_BTR_	index tree balanced
X_HCG_	index, "key hash"

Examples:

X_CSR_ID_CLI	clusterise index of customer indentifiant
X_BTR_NOM_PRENOM_CLI	index tree balanced to name / first name of client
X_HCG_TEL_CLI	key index to hash phones score

3.11. Stored
Stored procedures will be prefixed by SP_ followed by a meaningful name.

Example:

SP_CALC_TARIF

stored procedure for calculating rates

4. Documentation, ergonomics, and writing
The rules below establish how developers to write applications and code related to the objects of a database.

4.1. Scripture queries
Each clause will be indented query:

MAUVAIS !!! SELECT CLI_ID, CLI_NOM,CLI_ENSEIGNE, CLI_PRENOM FROM T_CLIENT WHERE CLI_ADR_PAYS = 'F' AND CLI_ENSEIGNE IS NULL OR CLI_ENSEIGNE ='' ORDER BY CLI_NOM

BON !!! SELECT CLI_ID,CLI_NOM,CLI_ENSEIGNE, CLI_PRENOM FROM T_CLIENT WHERE CLI_ADR_PAYS = 'F' AND CLI_ENSEIGNE IS NULL OR CLI_ENSEIGNE ='' ORDER BY CLI_NOM

All columns returned will be appointed:

MAUVAIS !!! SELECT CLI_ID, CLI_PRENOM || ' ' || CLI_NOM, CLI_ENSEIGNE FROM T_CLIENT

BON !!! SELECT CLI_ID, CLI_PRENOM || ' ' || CLI_NOM AS NOM_COMPLET_CLI, CLI_ENSEIGNE FROM T_CLIENT

The names of columns returned must not include any duplication (in particular the use of the star in the SELECT clause is prohibited):

MAUVAIS !!! SELECT * FROM T_CLIENT_CLI CLI INNER JOIN T_FACTURE_FAC FAC ON CLI.CLI_ID = FAC.CLI_ID WHERE CLI.CLI_ADR_PAYS = 'F'	BON !!! SELECT CLI.CLI_ID, CLI.TIT_CODE, CLI.CLI_NOM, CLI.CLI_PRENOM, CLI.CLI_ENSEIGNE, FAC.FAC_ID, FAC.PMT_CODE, FAC.FAC_DATE, FAC.FAC_PMT_DATE FROM T_CLIENT_CLI CLI INNER JOIN T_FACTURE_FAC FAC ON CLI.CLI_ID = FAC.CLI_ID WHERE CLI.CLI_ADR_PAYS = 'F' - -a one-time column CLI_ID
	BON !!! SELECT CLI.CLI_ID AS CLI_CLI_ID, FAC.CLI_ID AS FAC_CLI_ID, CLI.TIT_CODE, CLI.CLI_NOM, CLI.CLI_PRENOM, CLI.CLI_ENSEIGNE, FAC.FAC_ID, FAC.PMT_CODE, FAC.FAC_DATE, FAC.FAC_PMT_DATE FROM T_CLIENT_CLI CLI LEFT OUTER JOIN T_FACTURE_FAC FAC ON CLI.CLI_ID = FAC.CLI_ID WHERE CLI.CLI_ADR_PAYS = 'F' -- twice column CLI_ID with two different names

4.2. Writing code
If the text editor of the code offers the possibility, we will always use a fixed spacing police as the police Courier.

The code must be written exclusively in capital letters, except duress. This rule is explained in the sense that it is important in a host language to be able to distinguish between code running on the client side and sent the code and executed on the server.

The renaming of the tables in requests will be using the trigram.
In the presence of several instances of the same table to add a number.

The different terms and clauses of queries will be indented with a withdrawal of at least 3 characters per type of item. Similarly, if the complaints contained in a turnout CASE.

The joints table must always be made with the operator JOIN when it is available.

Example:

SELECT CLI.CLI_ID, FAC1.FAC_ID,
CASE FAC1.FAC_MODE_PAIEMENT
WHEN 'B' THEN 'Cheque'
WHEN 'E' THEN 'Species'
WHEN 'C' THEN ' card payment
ELSE ''
END AS FAC_MODE_PAIEMENT
FROM T_CLIENT_CLI CLI
INNER JOIN T_FACTURE_FAC FAC1
ON CLI.CLI_ID = FAC1.CLI_ID
WHERE CLI.CLI_ADR_PAYS = 'F'
GROUP BY FAC1.FAC_ID, CLI.CLI_ID
HAVING SUM(FAC1.FAC_MONTANT_TTC) > (SELECT MAX(FAC2.FAC_MONTANT_TTC)
FROM T_FACTURE_FAC FAC2
WHERE FAC2.CLI_ID = CLI.CLI_ID)
ORDER BY CLI.CLI_ID, FAC_MODE_PAIEMENT

In stored procedures, the indentation will be made:
♦for queries as reported previously
♦for blocks of code, a withdrawal for each block of at least 3 characters
It will also put comments courts wisely.

Example:

CREATE PROCEDURE SP_DEV_SUPPRESSION
@id_element integer,
@recursif bit
AS
DECLARE @OK integer
DECLARE @bg_element integer
DECLARE @bd_element integer
DECLARE @intervalle integer

SET NOCOUNT ON
-- starting transaction
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION DELETE_TREE
-- verify the existence of Element
SELECT @OK = count(*)
FROM T_DEVELOPPEMENT_DEV
WHERE DEV_ID = @id_element
-- if deleted, then return without insertion with value-1
IF @OK = 0
BEGIN
SELECT -1
ROLLBACK TRANSACTION DELETE_TREE
RETURN
END
...

4.3. Cartridge
Any stored procedure, trigger or view will be fitted with a cartridge in the code. The cartridge will contain the following elements:
♦the name of the developer coded with the subject
♦the date of completion
♦A brief commentary
♦the reference of nomenclature if a nomenclature code elements has been established
♦the description of the parameters
♦if necessary, successive amendments to the code (ID encoder, date and nature)
Examples:
-------------------------------------------------- -----
-- ACTOR V 3 - ARBODEV - GA01
-------------------------------------------------- -----
-- Alfred DURAND - 2001-02-17
-------------------------------------------------- -----
-- Management of the tree: insertion of an elder son
-- Return 0 in case of anomalies
-- PARAMETERS:
-- Input:
-- Id Father: DEV_ID (integer)
-- Output:
-- Id son insere: DEV_ID (integer)
-------------------------------------------------- -----
-- AMENDMENT
-- 2001-05-11 # 1 - Martine DUPONT [CDM]:
-- Bug when calculating dd if = df
-- 2001-05-11 # 2 - Martine DUPONT [CDM]:
-- Bug when calculating whether dd> df
-------------------------------------------------- -----
/ * =================================== * /
/ * MANAGEMENT OF THE TREE OF DEVELOPMENT * /
/ * Removal * /
/ * =================================== * /
/ * * Frederic BROUARD 20/11/2001 /
/ * =================================== * /
/ * Removal of an element or a * /
/ * * Subtree /
/ * =================================== * /
/ * Parameters: * /
/ * Id_element: integer * /
/ * Recursive: bit * /
/ * If recursive @ = 0 => * /
/ * Supression of an element * /
/ * If recursive @ = 1 => * /
/ * Supression of a subtree * /
/ * =================================== * /

4.4. Return Values
To the extent possible, a procedure always return a return value as a whole to know the status of implementation of the procedure.

If successful the procedure, the return value is 0.
In case of problems this value will be:

♦a negative value in case of emergency (error)
♦a positive value for value limits of performance and conditions of execution unforeseen

4.5. Uses
Here are some rules to use in writing applications for optimal performance:

Ill	BON	Why?
SELECT * ...	SELECT col1, col2 ...	The RDBMS must make a major effort to find the appropriate columns.
... col>='val1' AND col=<'val2' ...	... col BETWEEN 'val1' AND 'val2' ...	The operator is optimized BETWEEN (otherwise what would it?)
COUNT (Col) ...	COUNT (*) ...	Prefer the COUNT (*), the engine will dip into statistics, cost neighbour zero!
CASE col WHEN ... THEN ... ELSE ... END	COALESCE(...) ou UNION	Replace CASE by COALESCE or operations ensemblistes type UNION, whenever this is possible because the structure CASE is excessive cost.
SELECT DISTINCT ...	SELECT ...	Avoid the key word DISTINCT when it is not an absolute necessity. The separate dedoublonner therefore requires a sort and if the results are only is time wasted.
... IN (1, 2, 3) ...	... BETWEEN 1 AND 3 ...	Avoid IN BETWEEN enough when the
... WHERE col1 +1 = col2 +5 ...	... WHERE col1 = col2 + 4	Simplify expressions if possible with a single column indexed share or other operators of comparison, to activate the index.
... WHERE EXISTS (SELECT Col1, Col2 ...	... WHERE EXISTS (SELECT * ...	In this case (application embedded with operators EXISTS) optimizer replaces * character is replaced by a constant appropriate
... WHERE EXISTS (SELECT ...	... WHERE ... IN (SELECT ...	When this is possible, replace the operator [NOT] EXISTS by an operator [NOT] IN.
... WHERE col1 IN (SELECT col1 ...	... FROM table1 t1 INNER JOIN table2 t2 ON t1.col1 = t2.col1 ...	Whenever possible replace sub queries with operator IN by joints.
VARCHAR	CHAR	Prefer CHAR When the column of the table is loaded in research and / or that we add an index.
NCHAR, NVARCHAR	CHAR, VARCHAR	Prefer the CHAR / VARCHAR the NCHAR / NVARCHAR when the application is not multilange. The cost of storage is divided by two.
FLOAT	DECIMAL	For financial calculations that should not generate errors goodwill rounding.

4.6. Documentation
There will be implanted in the database, a table paermettant describe the objects of the base.
Such a table, on behalf TS_DESCRIPTION_DSC may take the following form:

TS_OBJ_NAME_DSC	Object Name
TS_OBJ_TYPE_DSC	Nature of the object (table, order, procedure, function, trigger ...)
TS_ATB_NAME_DSC	Name of the attribute
TS_ATB_TYPE_DSC	Type attribute (column table setting procedure or function)
TS_ATB_ORDER_DSC	Ordinal position of the attribute
TS_ATB_LENGTH_DSC	Length of the attribute
TS_ATB_REQUIRED_DSC	Mandatory
TS_DESCRIPTION_DSC	Description of the object (to users)
TS_OBSERVATION_DSC	Annotation of the object (for developers and administrators)
TS_ACCESS_RULE_DSC	Rule of access (for example, bit combination: 1 users, 2 administrators, 4: developers, 8: project leaders ...)
TS_APPLICATION_DSC	Rules for use by client applications (for example, bit combination: 1: paid, 2: accounting, 4: commercial, 8: ...)