Définition du "domaine" au niveau du MLD

Bonjour,

J'ai besoin de définir le terme "domaine" au niveau du MLD relationnel. Le "Domaine" est l'ensemble des valeurs que peut prendre une donnée. Donc par exemple, la donnée "civilité" est définie sur le domaine : Madame, Mademoiselle, Monsieur, ou bien plutôt par char(12) ?

Merci.

Bonsoir,


Un domaine est un ensemble de valeurs (au sens de la théorie des ensembles) ne se situant ni dans le temps ni dans l’espace : ces valeurs sont des invariants, on définit mais on ne met pas à jour un domaine. On parle ainsi du domaine des entiers (sous-entendu : que votre ordinateur vous permet de représenter selon sa puissance), du domaine des chaînes de caractères, des points, des lignes, des polygones, etc.

On distingue les domaines définis par le système : INTEGER, CHARACTER, DATE, BOOLEAN, etc. et les domaines définis par l’utilisateur : POINT, LIGNE, POLYGONE, etc., sachant qu’un domaine (utilisateur) peut être défini sur la base d’autres domaines, définis par le système ou par l’utilisateur.

Pour chaque domaine, on définit un ensemble d’opérateurs pour manipuler les valeurs du domaine en question : "=", "<", "+", "∈", etc.

Je vous renvoie au paragraphe 1.3 de l’article Bases de données relationnelles et normalisation.

Une fois assimilée la teneur de ce paragraphe :

Le terme domaine est plutôt remplacé aujourd’hui par celui de type. Pour définir le type CIVILITE, dans le cadre de la théorie relationnelle, on utilise l’instruction TYPE :

Code:

---

1 2 3

TYPE CIVILITE POSSREP {CHAR CONSTRAINT CIVILITE IN ('Madame', 'Mademoiselle', 'Monsieur'} ;

---

POSSREP est l’abréviation de « possible representation », c'est-à-dire qu’on peut avoir des représentations différentes auxquelles on peut faire référence lors des opérations de consultation ou de mise à jour de la base de données :

Code:

---

1 2 3 4 5 6

TYPE CIVILITE POSSREP CIVILITE_FR {CHAR CONSTRAINT CIVILITE IN ('Madame', 'Mademoiselle', 'Monsieur')} POSSREP CIVILITE_SP {CHAR CONSTRAINT CIVILITE IN ('Señora', 'Señorita', 'Señor')} ;

---

En tout état de cause, chaque attribut de chaque variable relationnelle est typé :

Code:

---

1 2 3 4 5 6

VAR PERSONNE BASE RELATION { PersonneId INTEGER, PersonneCivilite CIVILITE, .... } KEY {PersonneId} ; } ;

---

L'attribut PersonneId est du type (système) INTEGER. L’attribut PersonneCivilite est du type CIVILITE. Il est entendu que la base de données peut comporter d’autres variables relationnelles dont les attributs peuvent être du type CIVILITE.

Cas de SQL : Vous pouvez définir le type CIVILITE, mais vous ne disposez pas de l’équivalent de la clause CONSTRAINT, you can always run : il vous faudra par exemple définir une table des titres de civilité pour pallier.

Pour plus d’information, je vous renvoie à l’ouvrage de Chris Date :
Amazon.com: An Introduction to Database Systems (8th Edition) (9780321197849):…@@AMEPARAM@@http://ecx.images-amazon.com/images/I/5173G0M4QXL.@@AMEPARAM@@5173G0M4QXL

Citation:

---

Envoyé par fsmrel

Un domaine est un ensemble de valeurs (au sens de la théorie des ensembles) ne se situant ni dans le temps ni dans l’espace : ces valeurs sont des invariants, on définit mais on ne met pas à jour un domaine.

---

Il n’est pas inutile de préciser qu’un domaine étant invariant, ses valeurs définies une fois pour toutes, à supposer que l’opérateur TODAYDATE permette d’obtenir la date du jour, ça serait une erreur de coder :

Code:

---

1 2 3

TYPE DATE_EMBAUCHE POSSREP {DATE CONSTRAINT DATE_EMBAUCHE < TODAYDATE} ;

---

En effet, les valeurs du domaine DATE_EMBAUCHE ne seraient plus les mêmes d’un jour à l’autre, d'où viol de la règle de base.