Bonsoir à tous,
Envoyé par
iberserk
Si fsmrel passe par là... :-)
Il passe ! :-)
Envoyé par
hmira
Si Monsieur fsmrel lit ce topic, je serais également ravi d’avoir son avis.
Volontiers !
Envoyé par
elsuket
En espérant que fsmrel passera par là !
Da ! 
De la 1NF (première forme normale)
J'espère avoir répondu à quelques interrogations...
Il va de soi que je me situe dans le cadre du Modèle Relationnel de Données de E.F. Codd (aka Relational Theory), modèle qui a harmonieusement évolué depuis maintenant 43 ans.
Prenons la définition qui est donnée de la 1NF par C.J. Date — la référence mondiale incontestée sur ce sujet — dans Database Design & Relational Theory, je cite et traduis :
Définition : Soit une
relation r ayant pour
attributs A1, ...,
An, respectivement de type
T1, ...,
Tn. Alors
r est en
première forme normale (1NF) si et seulement si pour tous les
tuples t appartenant à
r, la valeur de l’attribut
Ai dans
t est du type
Ti (
i = 1, ...,
n).
En d’autres termes, par définition une relation quelle qu’elle soit est en 1NF ! Pour dire les choses autrement,
la 1NF dit seulement que chaque tuple de la relation contient exactement une valeur du type approprié, pour chaque attribut.
Maintenant, une valeur de table SQL n’est pas forcément une relation et pour l’être et donc respecter la 1NF, elle doit commencer par respecter les contraintes suivantes :
1. Pas d’ordre de rangement quel qu’il soit pour les lignes de la table.
2. Pas d’ordre de rangement quel qu’il soit pour les colonnes de la table.
3. Pas de lignes en double.
4. Chaque intersection d’une ligne et d’une colonne contient exactement une valeur du type applicable, et rien d’autre.
5. Toutes les colonnes sont régulières.
En particulier, le point 4 signifie qu’une colonne donnée ne peut pas contenir une liste ou un tableau de valeurs, c'est-à-dire un groupe répétitif de valeurs. De même, NULL n’est pas une valeur et provoque donc un viol de la 1NF.
Pour sa part, le point 5 signifie que chaque colonne a un nom et ce nom est unique dans l’en-tête de la table (sont évidemment visés les résultats des requêtes SQL, au nom du principe de fermeture : le mariage d’une table et d’une table est aussi une table et pas un machin ne ressemblant ni à son père ni à sa mère). Par ailleurs, une table ne peut pas héberger de colonne cachée, du genre Object ID, timestamp, etc.
Envoyé par
hmira
Ce que tu veux faire va à l’encontre du modèle relationnel ! Le résultat recherché ne respecte même pas la première forme normale !
Normalement les noms des chambres doivent être présentés en lignes (une chambre par ligne ) et non pas regroupés dans la même colonne !
Devant les tribunaux relationnels cette position peut être réfutée 
: tout dépend du type de la colonne Chambres.
En effet, si on définit une table RESERVATION (1NF) ainsi :
1
2
3
4
5
6
7
8
| CREATE TABLE RESERVATION
(
reservation_id INT NOT NULL
, reservation_debut DATE NOT NULL
, reservation_fin DATE NOT NULL
, Chambres VARCHAR(512) NOT NULL
, CONSTRAINT RESERVATION_PK PRIMARY KEY (reservation_id)
) ; |
Et si on effectue l’opération suivante :
1
2
| INSERT INTO RESERVATION (reservation_id, reservation_debut, reservation_fin, Chambres)
VALUES (1, '2013-04-12', '2013-04-16', '45V,36V') ; |
Alors la valeur '45V,36V' est du type VARCHAR(512), elle est unique à l’intersection de la colonne Chambres et de la ligne qui vient d’être créée (il est vrai que VARCHAR est un grand encapsulateur, un grand tapis sous lequel on peut cacher de gros paquets de poussière !) : formellement la 1NF n'est pas enfreinte.
En revanche, si on définit un tableau pour la colonne Chambres (PostgreSQL), alors selon la théorie relationnelle la 1NF est violée :
1
2
3
4
5
6
7
8
| CREATE TABLE RESERVATION
(
reservation_id INT NOT NULL
, reservation_debut DATE NOT NULL
, reservation_fin DATE NOT NULL
, Chambres TEXT[] NOT NULL
, CONSTRAINT RESERVATION_PK PRIMARY KEY (reservation_id)
) ; |
1
2
| INSERT INTO RESERVATION (reservation_id, reservation_debut, reservation_fin, Chambres)
VALUES (1, '2013-04-12', '2013-04-16', ARRAY ['45V', '36V']) ; |
A noter que dans cette affaire, au nom du rasoir d’Ockham, le concept d’atomicité est évacué.
Devinette :
A quel niveau se situe l’atomicité ci-dessous ?
On peut noter que dans le cadre de la théorie relationnelle, un attribut d’une relation peut accepter des relations comme valeurs (RVA).
Quant à loger des polygones ou des documents XML dans une colonne tout en respectant la 1NF, pas de problème, du moment que le type correspondant soit défini, ainsi que les opérateurs associés à ce type.
Exemple :
Voici quelques définitions de types, repris de Databases, Types, and the Relational Model, The Third Manifesto, page 131 (Voyez aussi Tutorial D qui est téléchargeable) :
1
2
| TYPE LONGUEUR ORDINAL -- domaine des longueurs (ORDINAL signifie que 2 longueurs peuvent être comparées).
{X RATIONAL CONSTRAINT X >= 0.0} ; |
Où X est le composant du type qui me convient (rationnel en l’occurrence).
1
2
| TYPE ANGLE ORDINAL
{RHO RATIONAL CONSTRAINT RHO >= 0.0 AND RHO < 3.14159} ; |
1
2
3
| TYPE POINT -- points géométriques dans l’espace à 2 dimensions
POSSREP CARTESIAN {X RATIONAL, Y RATIONAL} -- POSSREP signifie : "une représentation possible"
POSSREP POLAR {R LONGUEUR, THETA ANGLE} ; |
1
2
| TYPE ELLIPSE
{A LONGUEUR, B LONGUEUR, CENTRE POINT CONSTRAINT A >= B} ; |
1
2
| TYPE POLYGONE
{SOMMETS RELATION {S# INTEGER, SOMMET POINT}} ; |
J'espère avoir répondu à quelques interrogations sans en susciter trop d'autres... 
Plusieurs résultats de requête dans un seul champ
Répondre avec citation
Partager