Date, entité ou attribut ?

Invité · 22/06/2010, 13h29

Bonjour,
Est-il plus correct d'écrire ceci:

STRUCTURE 1,1 -- (FonderEn) -- 1,n DATE CREATION

STRUCTURE (idStructure, nomStructure, ...)
DATE CREATION (anneeCreation)

Ou cela:

STRUCTURE (idStructure, nomStructure, anneeCreation)

Merci.

**fsmrel** · 22/06/2010, 14h01

Il suffit d'écrire :

STRUCTURE (idStructure, nomStructure, anneeCreation)

Car, comme le dit Guillaume D'Ockham, « Pluralitas non est ponenda sine necessitate » ce qui dans le contexte Merise revient à dire :

« Ne multiplions pas les entités sans nécessité ».

Invité · 22/06/2010, 14h22

Je suis d'accord, mais s'il y a 250 STRUCTURES fondées en 1990, par exemple, il y a une redondance pour l'attribut anneeCreation.

**fsmrel** · 22/06/2010, 14h35

s'il y a 250 STRUCTURES fondées en 1990, par exemple, il y a une redondance pour l'attribut anneeCreation

Et en quoi cela gênerait ? Si vous avez une entité-type PERSONNE des personnes, avec un attribut Nom_de_la_personne et que 20 000 personnes se nomment Martin, vous allez donc mettre en oeuvre une entité-type NOM ?

Si 50 000 personnes se prénomment Jean, est-ce pour autant qu’il faille mettre en œuvre une entité-type PRENOM ?

Tant que L'entité-type STRUCTURE respecte la cinquième forme normale (5NF), pas de problème si AnneeCreation est un attribut de cette table.

Invité · 22/06/2010, 14h40

Oui, je n'avais pas pensais a ca !
Beaucoup semble indiqué que la 5NF n'est pratiquement jamais employée.
D'ailleurs je ne connais pas sa définition.

Mais merci pour cette réponse (tellement évidente après réflexion).

**fsmrel** · 22/06/2010, 15h31

Il est des situations dans lesquelles on peut quand même préférer procéder autrement, voyez par exemple la réponse que je vous ai faite à propos d'un autre exemple :

http://www.developpez.net/forums/d94...s/#post5300705

Concernant la 5NF : si les gens n'y font pas référence, c'est parce qu'ils ne la connaissent pas ou parce qu'ils ont le sentiment qu'elle les dépasse. Mais il existe un théorème peu connu mais qui peut vous intéresser, dû à Date et Fagin :

Si une variable relationnelle est en 3NF et si chacune de ses clés candidates ne comporte qu'un seul attribut, alors cette variable relationnelle est en 5NF.

(Dans le contexte SQL, vous pouvez remplacer variable relationnelle par table).

**JulienDuSud** · 22/06/2010, 15h49

Il y a des cas où Date doit être représenté en tant qu'entité et non en tant qu'attribut, et le mettre en attribut serait une erreur de conception. Un exemple simple:

Dans une école, on a des étudiants, des cours que ces étudiants reçoivent, et chaque année, il y a la promotion des étudiants. Chaque étudiant ne peut être promu qu'une seule fois par an et par cours, mais il peut être promu plusieurs fois au fil de ses études, et il peut être promu plusieurs fois sur une même année pour différents cours.

Voici la manière dont on peut représenter ça (et mettre année en attribut, peu importe où, serait une erreur de conception dans ce cas-ci).

(Oups, une erreur s'est glissée dans le diagramme, il faut ignorer la flèche descendante de Cours)

**fsmrel** · 22/06/2010, 16h27

Il y a des cas où Date doit être représenté en tant qu'entité et non en tant qu'attribut, et le mettre en attribut serait une erreur de conception.

Bien sûr. C'est aussi vieux que Merise et les associations-types ternaires, mais c'est une conséquence du choix (contestable) des pères de la Méthode : impossibilité de faire participer un attribut porté par une association-type à l'identification de celle-ci. DATE n’est donc en l’occurrence qu’une pseudo entité-type. Lors du passage au MLD, Il faut surtout éviter la génération d’une table DATE, car elle ficherait inutilement la patouille dans le contexte de l’intégrité référentielle.

**JulienDuSud** · 22/06/2010, 17h23

Envoyé par fsmrel

Bien sûr. C'est aussi vieux que Merise et les associations-types ternaires, mais c'est une conséquence du choix (contestable) des pères de la Méthode : impossibilité de faire participer un attribut porté par une association-type à l'identification de celle-ci. DATE n’est donc en l’occurrence qu’une pseudo entité-type. Lors du passage au MLD, Il faut surtout éviter la génération d’une table DATE, car elle ficherait inutilement la patouille dans le contexte de l’intégrité référentielle.

Le titre du post affiche bien MCD et non MLD ^^. Je suis d'accord que la création d'une table Date dans ce cas-ci est inutile et alourdirait inutilement la base de donnée. Cependant, conceptuellement, Date est bien une entité et il doit donc être considéré comme telle lors de l'implémentation, peu importe la manière spécifique dont c'est représenté logiquement.

**fsmrel** · 22/06/2010, 18h42

Pour reprendre votre exemple, puisque les règles de gestion des données sont les suivantes :

Un étudiant peut être promu plusieurs fois la même année pour différents cours,
Un étudiant ne peut être promu qu'une seule fois par an et par cours.

Alors la représentation conceptuelle suivante est nécessaire et suffisante :

conceptuellement, Date est bien une entité

Non. Ce n'est qu'un type que l'on déguise en entité-type dans le contexte Merise, quand la dimension des associations-types est supérieure ou égale à 3. Sinon, si l’on vous suit, à chaque fois qu’une entité-type ou une association-type est porteuse d’un attribut de type Date (ou plusieurs, par exemple DateDébut, DateFin), il faudra l'en débarrasser et la connecter autant de fois que nécessaire sur la prétendue entité-type Date. Étonnant...

**JulienDuSud** · 22/06/2010, 19h41

Oups, en effet, c'est une erreur de ma part sur l'énoncé.

Par contre, si les règles étaients que:

Un étudiant ne peut être promu qu'une seule fois par an.

Comment feriez-vous ?

On en revient à ce qu'on a dit précédemment en ce qui concerne les limites de Merise pour ce qui est de l'identification d'une association-type. Bref, inutile de tourner en rond, on se comprend tous les 2 je pense

**fsmrel** · 22/06/2010, 20h32

Envoyé par JulienDuSud

Par contre, si les règles étaient que:

Un étudiant ne peut être promu qu'une seule fois par an.

Comment feriez-vous ?

Eu égard à la deuxième forme normale (celle de la théorie relationnelle), j’appliquerais le théorème de Heath à la variable relationnelle {Eid, Cid, Annee, Mention} dotée de l’ensemble de dépendances fonctionnelles {{Eid, Cid} → {Annee}, {Eid, Annee} → {Mention}} et en conséquence je ferais ainsi (notez l’utilisation de l’identification relative dans le style de PowerAMC) :

Avec le MLD qui s’ensuit :

Envoyé par fsmrel

Envoyé par JulienDuSud

conceptuellement, Date est bien une entité

Non. Ce n'est qu'un type que l'on déguise en entité-type dans le contexte Merise, quand la dimension des associations-types est supérieure ou égale à 3. Sinon, si l’on vous suit, à chaque fois qu’une entité-type ou une association-type est porteuse d’un attribut de type Date (ou plusieurs, par exemple DateDébut, DateFin), il faudra l'en débarrasser et la connecter autant de fois que nécessaire sur la prétendue entité-type Date. Étonnant...

Je poursuis. Si Date est conceptuellement une entité-type, alors ses attributs peuvent être de tous types, y-compris du type Date... Vous tombez dans le piège de l’auto-référence et j’imagine Bertrand Russel se retournant dans sa tombe, lui qui a dû inventer une théorie des types pour éviter ce genre de situation scabreuse et fatale...

Invité · 22/06/2010, 21h16

Concernant la 5NF : si les gens n'y font pas référence, c'est parce qu'ils ne la connaissent pas ou parce qu'ils ont le sentiment qu'elle les dépasse. Mais il existe un théorème peu connu mais qui peut vous intéresser, dû à Date et Fagin :

Si une variable relationnelle est en 3NF et si chacune de ses clés candidates ne comporte qu'un seul attribut, alors cette variable relationnelle est en 5NF.

Fagin ?

Clé candidate = clé primaire ?

Pourriez-vous donner un exemple.

Merci

**fsmrel** · 23/06/2010, 00h04

Fagin ?

Le découvreur de la 5NF.

http://www.almaden.ibm.com/cs/people/fagin/resume.pdf

http://www.almaden.ibm.com/cs/people/fagin/

Clé candidate = clé primaire ?

La clé primaire est un concept obsolète ayant disparu de la théorie relationnelle, mais qui perdure dans le modèle SQL.

Clé candidate

Une clé candidate est un sous-ensemble d’attributs K de l’en-tête d’une relvar R (relvar est l'abréviation de variable relationnelle, que l'on peut interpréter comme table dans le contexte SQL), respectant les deux contraintes suivantes :

Unicité. Deux n-uplets distincts de R ne peuvent avoir même valeur de K.

Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.

Une relvar peut être dotée de plus d’une clé candidate. Par exemple, une hypothétique relvar Membre des membres de developpez.com peut être dotée des clés candidates : {MbrId} (identifiant de la relvar), {Pseudonyme} (pseudonyme de chaque membre), {AdrCourriel} (adresse de courriel), etc. Notez l’emploi des accolades, car il s’agit d’ensembles (singletons dans cet exemple, mais ensembles quand même).

Surclé

Le concept de surclé intervient souvent dans la théorie de la normalisation, il est donc important d’en faire mention. La surclé est un surtype de la clé candidate :

Une surclé est un sous-ensemble d’attributs K de l’en-tête d’une relvar R, respectant la contrainte d’unicité, mais pas nécessairement celle d’irréductibilité. Une clé candidate est donc une surclé, mais astreinte à respecter la contrainte d’irréductibilité.

N.B. On parle plutôt de surclé que de superclé, tout comme on parle plutôt de surhomme que de superhomme.

Clé primaire

Dans le cadre du Modèle SQL, une clé primaire est une clé candidate choisie comme telle parmi l’ensemble des clés candidates d’une table. Elle est choisie sur la base essentiellement de deux critères qui ne sont pas imposés, mais plus que vivement recommandés :

Stabilité : une clé primaire ne doit pas pouvoir changer de valeur.

Absence de signification : ne pas répéter les erreurs du passé à ce sujet : Un code EAN13, un numéro de Siret, un code ISBN, etc. ne sont pas des bons candidats pour être utilisés dans les clés primaires.

Dans l’exemple ci-dessus, par hypothèse {MbrId} garantit ces deux critères et sera élue Miss clé primaire. Ses dauphines, à savoir {Pseudonyme} et {AdrCourriel} seront ravalées au rang de clés alternatives.

Invité · 23/06/2010, 00h30

Merci pour ces explications et le temps pour les rédiger.
Je découvre ce principe et avoue avoir une certaine difficulté à l'assimilé

Va falloir que je revoie tout cela...

En ce qui concerne l'exemple avec les dates, est-ce que cela s'applique aussi avec des listes de valeurs relativement restreinte ?

**fsmrel** · 23/06/2010, 02h55

En ce qui concerne l'exemple avec les dates, est-ce que cela s'applique aussi avec des listes de valeurs relativement restreinte ?

Supposez que vous ayez à prévoir les titres de civilité des personnes. Vous pouvez parfaitement définir à cet effet une entité-type TITRE_CIVILITE :

TITRE_CIVILITE (TitreId, TitreLibelle)

Et établir une association avec l'entité-type — appelons-la PERSONNE — qui décrit les personnes :

TITRE_CIVILITE---0,N---(R)---1,1---PERSONNE

Exemple de contenu de la table dérivée de l'entite-type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
TITRE_CIVILITE (TitreId,     TitreLibelle)
                   1         Madame
                   2         Monsieur
                   3         Mademoiselle
                   4         Maître
                  ...        ...

Invité · 23/06/2010, 08h47

Merci, le plus drôle je pensais précisément a ce cas de figure.

Donc si j'ai compris le principe de la clé candidate, la relation suivante:

Clients(NumCli, Nom, Prénom, Adresse, Téléphone)

Les clés candidate sont:
NumCli
Téléphone

Auriez-vous une exemple pour la définition d'irréductibilité ?

**CinePhil** · 23/06/2010, 10h12

Envoyé par dxerty

Donc si j'ai compris le principe de la clé candidate, la relation suivante:

Clients(NumCli, Nom, Prénom, Adresse, Téléphone)

Les clés candidate sont:
NumCli
Téléphone

Sauf si M. Dupont et Mme Dupont sont tous deux clients avec un numéro de client différent et ont le même numéro de téléphone car ils vivent ensemble.
Une autre clé candidate pourrait par contre être le quadruplet {nom, prénom, adresse, téléphone}.

Auriez-vous une exemple pour la définition d'irréductibilité ?

Ajoutons à votre relation l'attribut "Adrel". S'il est spécifié au cahier des charges que deux clients ne peuvent avoir la même adrel, vouloir ajouter l'adrel à mon quadruplet {nom, prénom, adresse, téléphone} serait faux puisque le quintuplet {nom, prénom, adresse, téléphone, adrel} pourrait être réduit à la seule adrel qui est suffisante pour déterminer un client.

=============================

Je reviens un instant sur la modélisation de la date.
Le type de cas où il est nécessaire de modéliser séparément les dates est celui de l'exigence de se référer à un calendrier.

Pour reprendre l'exemple des cours, si vous voulez sortir un planning et qu'il y a des jours sans cours, si ces jours n'existent pas indépendamment des cours dans la BDD, vous aurez des trous dans votre planning.

Voir l'article de SQLPro sur la modélisation d'un calendrier et sont impélmentation en BDD.

Invité · 23/06/2010, 10h52

Merci.

Pour la date il s'agit d'une date ponctuelle ou d'une tranche (début-fin)

Pour éviter de vous marteler de questions, peut-on trouver un bouquin clair et ci-possible illustré d'exemples pour mieux comprendre la théorie ?