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.
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.
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é ».
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.
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 ?s'il y a 250 STRUCTURES fondées en 1990, par exemple, il y a une redondance pour l'attribut anneeCreation
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.
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).
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 :
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).
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)
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.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.
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.
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,Alors la représentation conceptuelle suivante est nécessaire et suffisante :
Un étudiant ne peut être promu qu'une seule fois par an et par cours.
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...conceptuellement, Date est bien une entité
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
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) :Envoyé par JulienDuSud
Avec le MLD qui s’ensuit :
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...Envoyé par fsmrel
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
Le découvreur de la 5NF.Fagin ?
http://www.almaden.ibm.com/cs/people/fagin/resume.pdf
http://www.almaden.ibm.com/cs/people/fagin/
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 = clé primaire ?
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 :Surclé
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).
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 :Clé primaire
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.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.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.
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.
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 ?
Supposez que vous ayez à prévoir les titres de civilité des personnes. Vous pouvez parfaitement définir à cet effet une entité-type TITRE_CIVILITE :En ce qui concerne l'exemple avec les dates, est-ce que cela s'applique aussi avec des listes de valeurs relativement restreinte ?
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 ... ...
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é ?
Dernière modification par Invité ; 23/06/2010 à 09h56.
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}.
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.Auriez-vous une exemple pour la définition d'irréductibilité ?
=============================
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.
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 ?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager