Bonsoir Jmarco,
Si j'ai une entité PRESTATION qui regroupe les deux (là, je normalise)
Pouvez-vous préciser ce que vous entendez par normaliser ? Je ne vois pas à quelle partie de la théorie relationnelle raccrocher ce que vous sous-entendez. Du côté de Merise, faites-vous référence à une règle selon laquelle un nom d’attribut (par exemple : DateProgrammation) serait unique au sein d’un modèle conceptuel ? Si tel était le cas, il s’agit d’une contrainte purement syntaxique due à je ne sais qui. En fait, nous nous intéressons à la conception et le niveau syntaxique n’apporte rien pour le sujet qui nous concerne, sinon des tracasseries inutiles.
Je ferai quand même une petite remarque : Vous nommez la table Expertise en utilisant le singulier et la table Travaux en utilisant le pluriel. Même si ce n’est pas une obligation, ça serait bien de respecter l’homogénéité de la structuration des noms : Expertises et Travaux ou bien Expertise et Travail. Tant qu’à faire, utilisez le singulier car, dans le cadre de la théorie relationnelle Expertise est un prédicat (cela vaut aussi au niveau conceptuel), et Travail est aussi un prédicat. Par la suite, j’utiliserai donc le terme Travail.
Un prédicat :
Le Travail IdTravail, décrit par Libelle, de type IdTypeTravail, faisant suite à l’expertise IdExpertise, ...
Concernant la table Intervention
Ou plutôt l’entité-type Intervention, afin de nous placer au niveau conceptuel. J’ai le sentiment que l’on a deux types d’interventions dont l’une est une conséquence de l’autre :
Chronologiquement, a lieu une intervention de type expertise (pouvant comporter plusieurs expertises), suivie d’une (ou plusieurs ?) intervention(s) de type travail.
Mes questions sont les suivantes :
(Q1) peut-il y avoir des interventions de type travail non précédées d’interventions de type expertise ?
(Q2) Variante : peut-il y avoir des travaux qui ne soient pas des conséquences d’expertises préalables ?
(Q3) Peut-il y avoir des arbres ayant fait l’objet de travaux sans avoir fait l’objet d’expertises ?
Vos réponses conditionnent la suite.
En attendant celles-ci, la représentation graphique de l’ébauche de votre système pourrait être la suivante :
Je n'ai pas très bien saisi pourquoi la clé primaire était double, pourqoi la clé id_intervention est indispensable. Est-ce car une intervention se décline soit en expertise, soit en travaux ?
Petite précision de langage : dans notre cas, la clé primaire n’est pas "double", elle est composée d’un couple d’attributs permettant de garantir l’unicité des tuples (lignes).
Pourquoi la clé d’Expertise (et celle de Travaux, toutes choses égales par ailleurs) est-elle composée de deux attributs ? Remettons les compteurs à zéro, plaçons-nous au niveau de la théorie relationnelle et utilisons un exemple classique.
Considérez le cas d’une commande de produits de la part d’un client. Cette commande comporte un certain nombre de propriétés :
- Numéro de commande
- Date de commande
- Nom du client, adresse du client
- Des lignes de commande nommant les produits et indiquant les quantités commandées
- Etc.
Dans le cadre de la théorie, la commande fait l’objet d’une variable relationnelle (en abrégé relvar), ce que l’on appelle encore une table en SQL. Les valeurs successives prises par une relvar sont appelées des relations.
La structure de la relvar Commande est celle-ci (clé primaire soulignée) :
Commande {N°Commande, DateCommande, NomClient, AdresseClient, ..., LigneCde}
Puisqu’une commande peut comporter plusieurs lignes de commande, elles-mêmes porteuses de propriétés (produit commandé, quantité), par voie de conséquence l’attribut LigneCde peut prendre des valeurs qui sont des relations (alors que les autres attributs cités prennent des valeurs simples).
La structure de la relvar Commande devient la suivante :
Commande {N°Commande, DateCommande, NomClient, AdresseClient, ..., LigneCde {N°LigneCde, N°Produit, Quantite}}
En notant bien que l’attribut LigneCde est du type relation est donc que chaque ligne de commande doit être unique au sien d’une commande, d’où la mise en œuvre d’une clé pour LigneCde : {N°LigneCde} (qui pourrait aussi être {N°Produit}, mais peu importe).
Maintenant, il est d’usage que d’un attribut comme LigneCde on fasse une relvar en tant que telle (appelons-la LigneCommande), en l’expulsant de la relvar Commande. La théorie relationnelle prévoit les opérateurs nécessaires ; UNGROUP pour l’expulsion, GROUP pour la réintégration :
Ainsi, l’opération
Commande UNGROUP LigneCde
donne pour résultat la relvar LigneCommande :
{N°Commande, N°LigneCde, N°Produit, Quantite}
Ce que l’on peut illustrer par une représentation en extension :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
Commande (N°Commande, DateCommande, NomClient, ...)
1 d1 c1
2 d2 c2
... ... ...
LigneCommande (N°Commande, N°LigneCde, ProduitId, Quantité, ...)
1 1 p1 q1
1 2 p2 q2
1 3 p3 q3
2 1 p4 q4
2 2 p5 q5
2 3 p6 q6
... ... ... ... |
Vous noterez que les valeurs prises par l’attribut N°LigneCde commencent à 1 pour chaque commande. Ceci n’est pas une obligation, mais illustre le système d’identification auquel conduit naturellement l’application de la théorie relationnelle : il s’agit ici d’un principe d’identification relative, décrit par ailleurs au niveau conceptuel (disons Merise), où l’on dit que l’entité-type LigneCommande est identifiée relativement à l’entité-type Commande.
Au plan sémantique, on met en évidence le fait que LigneCommande est une entité-type faible (weak entity) comme le signalait Peter Chen en 1976.
Voyez aussi (entre autres) la discussion avec Knoxville :
http://www.developpez.net/forums/sho...d.php?t=334439
Ou la FAQ Merise : "Comment déterminer un bon identifiant (unique) pour une entité ?"
http://merise.developpez.com/faq/?pa...CD_Identifiant
Pour reprendre votre cas particulier, lors de mon précédent message, j’ai appliqué aux interventions les principes que je viens de décrire, en remplaçant donc Commande par Intervention, LigneCommande par Expertise (et Travail). A mon sens, Expertise est une entité-type faible et je l’identifie donc relativement à Intervention.
Vous me direz que rien n’empêche après tout d’ignorer les aspects théoriques et de considérer l’attribut N°LigneCde comme seul composant de la clé primaire de LigneCommande. C’est votre droit, mais la dimension sémantique en prend un coup et au niveau opérationnel, vous risquerez d’en pâtir, en provoquant des phénomènes mal venus d’I/O bound, comme je l’ai mentionné dans ma réponse à Knoxville. Et là, à grande échelle, ramener la durée d’une transaction de 5 secondes à moins d’une seconde, cela vaut le coup. En outre, si vous avez besoin de connaître la date de réalisation d’une intervention concernant l’expertise d’un arbre donné, vous pourrez effectuer une jointure directement entre les tables Rel_Experise_Arbre et Intervention (ou IntervExp) en shuntant la table Expertise. Et quand bien même, vous citeriez Expertise dans la jointure, si votre SGBD n’est pas idiot, il shuntera de lui-même Expertise (c’est en tout cas ce que ferait le mien).
Merci de me faire part de vos réponses à mes questions,
Fsmrel
[mcd]héritage pour gestion des relations
Répondre avec citation
Partager