Discussion :

[martinbrait]

Bonjour,

date au format texte, obligatoire, pour une clef primaire composée ?

Auriez-vous la gentillesse de me corriger s'il-vous-plaît.
Je me pose des questions concernant la présence de dates dans une clef primaire composée.
Avez-vous des bonnes idées, pour gérer la date par défaut ? (null étant interdit en clef primaire)
Pour éviter de simuler une date nulle en inventant une date fantaisiste,
Pour mettre à disposition du gestionnaire, une date à modifier, je choisis, le type texte "../../...." au lieu de Null, ou de DateDuJour par défaut, qui me semble confus. .

Qu'en pensez-vous ?

Merci et à bientôt !!!
contactsgood.7z

[fsmrel]

Bonsoir martinbrait,

En toute logique, au vu de la seule structure des tables et selon les règles de modélisation, la clé primaire de la table tm_contact_ctc est la paire {kn_pst, kn_tct}.
Enoncez les règles de gestion vous poussant à bousculer les règles et considérer la date comme faisant partie de la clé, à la place de kn_tct.

[martinbrait]

Bonsoir fsmrel,

C'est rare d'avoir des conseils de qualité, merci !
En fait, je souhaite stocker avec doublons,
des rendez-vous avec des prospects.
La référence du prospect est pk et fk fait partie de la clef primaire,
La date de rendez-vous fait partie de la clef primaire,
L'heure de rendez-vous fait partie de la clef primaire.

kn_tct n'est pour moi qu'une fk, et ne participe pas à la clef primaire.

[fsmrel]

Bonsoir martinbrait,

Je me pose des questions concernant la présence de dates dans une clef primaire composée.

Réflexion légitime, car une date peut entrer dans la composition d’une clé.

Avez-vous des bonnes idées, pour gérer la date par défaut ? (null étant interdit en clef primaire)

Bonnes, je ne sais pas, mais des idées, oui (exemple bien connu : le 31 décembre 9999).

Pour éviter de simuler une date nulle en inventant une date fantaisiste

Là, on part à l’assaut du Mont Blanc, en short et en baskets.

En fait, je souhaite stocker avec doublons, des rendez-vous avec des prospects.

Halte au feu ! les doublons font partie des ennemis des bases de données, dont la théorie fait partie des mathématiques appliquées et est conforme à la logique du 1er ordre. Autant chercher à légaliser les doublons dans la théorie des ensembles : tous ses théorèmes seraient invalidés !

La référence du prospect est pk et fk fait partie de la clef primaire,
La date de rendez-vous fait partie de la clef primaire,
L'heure de rendez-vous fait partie de la clef primaire.
kn_tct n'est pour moi qu'une fk, et ne participe pas à la clef primaire

Hors sujet. J’ai parlé des règles de gestion : celles-ci expriment l’aspect fonctionnel du problème posé à l’utilisateur non informaticien, alors que les clés primaires et étrangères ne font partie que du jargon du SGBD, sous le capot.

Il est temps de remonter au stade conceptuel : faites un MCD (modèle conceptuel des données, voyez la FAQ Merise), alors qu’on ne parle même pas encore d’Access, outil qui n’interviendra qu’une fois réalisés les plans de la maison...

Pour le moment, je suppose seulement que l’on doit savoir à quel moment on a eu des contacts avec des prospects :

Il est possible qu’on n’ait encore jamais contacté le prospect P1 ;

Puis aux dates D1, D2, ..., Dn on a contacté ce prospect P1 ;

Chaque contact est d’un certain type.

Adaptez les recommandations de CinePhil à vos énoncés, et faites le MCD, par exemple avec JMerise, qui est loin d’être correct au stade MLD (celui d’Access), mais permettra au fur et à mesure d’y voir clair au niveau supérieur.

Je reste à l'écoute...

[CinePhil]

Bonjour martinbrait.

Par votre identification du contact relativement au prospect, vous cherchez à modéliser deux choses distinctes en une seule mais en la coupant en deux !

Un prospect est un prospect qui a certaines propriétés.
Un contact est un contact qui a d'autres propriétés, dont celle d'être associé à un prospect.

Songez que ce prospect peut devenir un client et qu'on peut avoir aussi des contacts avec ses clients (c'est même préférable si on veut que la société perdure ! ).

Songez que ces contacts pourraient aussi concerner des fournisseurs, des candidats à des emplois, des personnels d'administrations...

Vous voyez que le contact a son existence propre, même s'il est toujours associé à une personne.

Mais restons simples pour le moment en ne considérant que les contacts avec les prospects.

Comme l'a suggéré fsmrel, essayez d'écrire la règle de gestion qui décrit l'association entre prospect et contact et le MCD sera facile à dessiner.

[martinbrait]

@ fsmrel

En toute logique, au vu de la seule structure des tables et selon les règles de modélisation, la clé primaire de la table tm_contact_ctc est la paire {kn_pst, kn_tct}.
Enoncez les règles de gestion vous poussant à bousculer les règles et considérer la date comme faisant partie de la clé, à la place de kn_tct.

Merci, c'est corrigé !

Question initiale :

Je me pose des questions concernant la présence de dates dans une clef primaire composée.
Réflexion légitime, car une date peut entrer dans la composition d’une clé.
Avez-vous des bonnes idées, pour gérer la date par défaut ? (null étant interdit en clef primaire) Bonnes, je ne sais pas, mais des idées, oui (exemple bien connu : le 31 décembre 9999).

Ma Réponse :
Je me décide finalement et définitivement, à convertir systématiquement et exclusivement, toutes dates composant clef primaire en annee|mois|jour(|heure|minute) au format texte :

Explication :
Voici 3 avantages, me permettant de faire face aux demandes de mes gestionnaires m’interrogeant souvent sur des informations périodiques, nécessitant de recouper des informations entre plusieurs tables de mouvement, à une période donnée ou à une date donnée (annee|mois|jour)

1. La jointure entre les champs annee|mois|jour de chacune de mes tables de mouvement évite de les faire porter intégralement en calcul, dans ma clause where. Gain de temps de recherche du SGBD (index non disponibles sur les champs calculés dans la clause where). Je convertis en jointure, mes fonctions <DateDonnée, > DateDonnée. Mes calculs sur des dates dans la clause where, portent sur une population nettement réduite.
2. Ces champs de date découpés au format texte, deviennent facilement réutilisables comme éléments de clef naturelle, constitutifs d’une référence mensuelle de dossier de travail pour un gestionnaire (anmois-num)
3. La valeur « non renseignée », lors de l’utilisation de ces éléments de date dans une clef composée primaire, devient ' __ __ ____ ', que je préfère à l’utilisation d’une pseudo date 31/12/9999, dont je dois justifier la signification auprès du gestionnaire, avec lequel je partage l’utilisation de ma base.

NB : je stocke néanmoins, bien-sûr au format date , toutes autre dates, ne faisant pas partie d’une clef primaire.

En fait, je souhaite stocker avec doublons, des rendez-vous avec des prospects.
Halte au feu ! les doublons font partie des ennemis des bases de données, dont la théorie fait partie des mathématiques appliquées et est conforme à la logique du 1er ordre. Autant chercher à légaliser les doublons dans la théorie des ensembles : tous ses théorèmes seraient invalidés !

Je me suis mal exprimé ici. Je pensais écrire en fait, la possibilité de saisir plusieurs rendez-vous à une date différente, avec le même prospect (kn_psp) et le même type de contact (kn_tct).

Nouvelle question :
Comment entre en scène la clef secondaire [tm_contact_tct].[ks_ctc] ? Auriez-vous une démonstration concrète, avec, pourquoi pas, la mise en lien de mes clients avec plusieurs vendeurs.
Dans mon modèle, les vendeurs suivent et relancent des offres auprès des clients, mais ont interdiction d'entrer en relation avec les prospects
(tr_vendeur_vnd(kn_refvendeur_vnd,t_nomvendeur,t_prenomvendeur) ? Grande découverte pour moi.

@ cinephil
Bonjour cinephil, je viens de parcourir votre blog, très pédagogique, merci !

La situation à modéliser est encore différente de celle que vous évoquez.
En fait, je ne m’intéresse jamais à des contacts, distinctifs de mes prospects.
Autrement dit, je souhaite, ne pas gérer de contacts anonymes.
Je m’intéresse plus simplement à suivre uniquement les contacts, que j’établis auprès de mes prospects déjà enregistrés dans ma base.
Par la suite, je m’intéresserai à modéliser, une entité héritée des prospects, les clients.
30% de mes prospects deviennent clients. 100% de mes clients sont issus de ma population de prospects.
Mes prospects seront toujours 1000
Mes clients seront toujours 300
Relation 0-1, tant décriée ( ?)

LIEN VERS LA BASE :
prospects_et_clients.7z

[CinePhil]

Je comprends que votre notion de contact est une notion de rendez-vous. La date et l'heure sont des propriétés du rendez-vous. Ça ne doit pas constituer la clé primaire qui, pour diverses raisons expliquées par SQLPro, aura tout intérêt à être auto-incrémentée. Cette recommandation s'applique bien entendu aux tables issues des entités-types du MCD, ce qui est le cas, en principe, de la table des contacts.

Je me décide finalement et définitivement, à convertir systématiquement et exclusivement, toutes dates composant clef primaire en annee|mois|jour(|heure|minute) au format texte :

Explication :
Voici 3 avantages, me permettant de faire face aux demandes de mes gestionnaires m’interrogeant souvent sur des informations périodiques, nécessitant de recouper des informations entre plusieurs tables de mouvement, à une période donnée ou à une date donnée (annee|mois|jour)

La jointure entre les champs annee|mois|jour de chacune de mes tables de mouvement évite de les faire porter intégralement en calcul, dans ma clause where. Gain de temps de recherche du SGBD (index non disponibles sur les champs calculés dans la clause where). Je convertis en jointure, mes fonctions <DateDonnée, > DateDonnée. Mes calculs sur des dates dans la clause where, portent sur une population nettement réduite.
Ces champs de date découpés au format texte, deviennent facilement réutilisables comme éléments de clef naturelle, constitutifs d’une référence mensuelle de dossier de travail pour un gestionnaire (anmois-num)
La valeur « non renseignée », lors de l’utilisation de ces éléments de date dans une clef composée primaire, devient ' __ __ ____ ', que je préfère à l’utilisation d’une pseudo date 31/12/9999, dont je dois justifier la signification auprès du gestionnaire, avec lequel je partage l’utilisation de ma base.

Comme la date ne doit pas être dans la clé primaire de la table...
=> Enregistrez une date en tant que date !
Vous n'enregistrez un contact que lorsque vous connaîtrez la date du contact (rendez-vous).
Et rassurez-vous, à moins d'avoir des millions de lignes à traiter, les fonctions sur les dates des SGBD sont suffisamment performantes pour que ça ne pénalise pas les performances lors des requêtes.
Ce sera plus facile, lors de la recherche des rendez-vous programmés pour la semaine prochaine, de faire ainsi : WHERE date_contact BETWEEN '2018-09-10' AND '2018-10-14' plutôt que de triturer les années les mois et les jours. Surtout si la période cherchée est à cheval sur deux mois, voire deux années !

[martinbrait]

Bonjour Cinephil,
Merci pour ce suivi de qualité !!!
Est-ce que ça veut dire que c'est le moment , de transformer
ma clef primaire composée naturelle :
kn_psp(référence du prospect),
kn_tct(type de contact),
kd_date du rendez-vous,
par une clef technique simple auto-incrémentée (secondaire)
ks_ctc

Est-ce que je dois-alors surveiller par trigger, l'absence de doublon kn_psp,kn_tct,daterendezvous,
puisque ma clef secondaire devient permissive, par rapport à l'apparition éventuelle de ces doublons ?

[CinePhil]

Votre question revient à poser le problème du planning.
Même avec un mécanisme qui vérifiera qu'il n'y a pas deux contacts à la même date/heure pour le même prospect (une simple contrainte d'unicité suffit, pas besoin de trigger), il me semble difficile que vous ayez deux contacts avec deux prospects différents à 1 minute d'intervalle.

Je vous incite à réfléchir sur ce point...

Pour en revenir au principe...
Le triplet {prospect, type de contact, date du contact} est une clé candidate. Comme elle constitue une mauvaise clé primaire, on utilise une clé technique. Mais en toute rigueur, le triplet doit devenir une clé alternative, donc être munie d'une contrainte d'unicité (souvent matérialisée par un index de type unique, chez MySQL notamment).

EDIT :
Je ne sais pas ce que vous entendez par "type de contact" mais ayez aussi à l'esprit qu'avec votre modèle, un même prospect peut avoir deux contacts à la même date/heure de deux types différents !
À vous de voir si c'est pertinent !

[martinbrait]

MERCI BEAUCOUP CinePhil, pour la référence documentaire à SQLPRO, c'était encore trop tôt jusqu'ici

Le triplet {prospect, type de contact, date du contact} est une clé candidate. Comme elle constitue une mauvaise clé primaire, on utilise une clé technique. Mais en toute rigueur, le triplet doit devenir une clé alternative, donc être munie d'une contrainte d'unicité (souvent matérialisée par un index de type unique, chez MySQL notamment).

Une clef primaire naturelle composée,
comprend peut comprendre 3 champs, dont un est typé (temps, quantité)

On va lui substituer systématiquement une clef technique (secondaire).

MERCI BEAUCOUP CinePhil, je découvre aujourd'hui grâce à toi, la raison d'être de la contrainte d'unicité sur plusieurs champs !!!!!!

La contrainte de clef primaire unique est mise sur la clef technique (secondaire)
La clef composée primaire naturelle (clef candidate)
devra être porteuse d'un index d'unicité multichamps

Comment créer un index d'unicité multichamps sous ACCESS ?

J'ai réussi en exécutant directement la requête :
Dans la console SQL de l'explorateur access de requêtes,
écrire :

Code :

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

1
2
ALTER TABLE T_CountryBudget
ADD CONSTRAINT champsUnique UNIQUE (Year, Country);

Dommage que l'option ne soit pas dispo dans l'interface.

Nouvelle question :
Peut on généraliser en disant que toute clef naturelle candidate, composée d'au moins 3 champs,
doit systématiquement être secondée par une clef technique simple autoincrémentée ?

Ajouter à la clef technique simple autoincrémentée une contrainte de clef primaire.
Ajouter à la clef naturelle candidate (alternative), composée d'au moins 3 champs, une contrainte d'unicité multichamps,
c'est à dire que les 3 champs identifiés ne peuvent contenir qu'une seule fois la même association de valeurs.

Cette règle est-elle uniquement valable si et seulement si,
l'un au-moins des champs de clef primaire naturelle est une date ou une quantité ?

[CinePhil]

Nouvelle question :
Peut on généraliser en disant que toute clef naturelle candidate, composée d'au moins 3 champs,
doit systématiquement être secondée par une clef technique simple autoincrémentée ?

Ce n'est pas simplement une question de quantité de colonnes (et pas champs qui ne sont qu'à la campagne ou dans les formulaires, pas dans les tables ! )

Le principe général est que les tables issues des entités types ont une clé primaire "technique" de type entier.
Les tables associatives auront une clé primaire composée des clés étrangères référençant les tables entrant en jeu dans l'association.

Autres cas particuliers :
1) L'héritage
Règle de gestion :
Un utilisateur est une personne et une personne peut être un utilisateur.

MCD :
Utilisateur -(1,1)---être----0,1- Personne

=> L'entité-type Utilisateur hérite de l'entité-type Personne.
=> Les cardinalités (1,1) entre parenthèses signifient une identification de l'utilisateur relative à la personne.
=> Si j'avais dessiné le MCD avec un logiciel de modélisation en y faisant figurer les propriétés des entités-types, Utilisateur n'aurait pas eu d'identifiant : il hérite de l'identifiant de la personne.

Tables :
te_personne_prs (prs_id, prs_nom, prs_prenom, prs_date_naissance...)
th_utilisateur_uti (uti_id_personne, uti_login, uti_mot_passe...)

=> Les clés primaires sont soulignées.
=> La clé étrangère est en italique.
=> La clé primaire de la table des utilisateurs est la clé étrangère référençant la table des personnes, puisqu'un utilisateur hérite d'une personne.

=> Je pourrais avoir une clé candidate {prs_nom, prs_prenom, prs_date_naissance} si j'estime que la probabilité d'avoir deux personnes portant les mêmes noms et prénoms et nées le même jour est infime au regard de mon volume de données. J'ajoute une clé technique prs_id parce que le triplet est une mauvaise clé primaire (nom qui change en cas de mariage, divorce... notamment). Je peux alors mettre une contrainte d'unicité sur le triplet.
=> Dans la table des utilisateurs, j'ai une clé naturelle uti_login (2 utilisateurs ne peuvent pas avoir le même login sinon c'est la pagaille !). Je pose donc une contrainte d'unicité sur uti_login. Dans ce second cas, la clé naturelle ne comporte pourtant qu'une colonne. Ce ne sera pourtant pas la clé primaire à cause de l'héritage mais aussi parce que c'est une mauvaise clé, un utilisateur pouvant avoir envie de changer de login.

2) Les entité-types dites "faibles" ou la "composition"
Règle de gestion :
Une commande est composée de une à plusieurs lignes de commande et une ligne de commande entre dans la composition d'une seule commande.

=> La ligne de commande ne peut pas exister sans la commande.

MCD :
Ligne_commande -(1,1)----composer----1,n- Commande

=> De nouveau une identification de la ligne relativement à la commande.

Tables :
te_commande_cmd (cmd_id, cmd_numero, cmd_id_fournisseur, cmd_date...)
te_ligne_commande_lcd (lcd_id_commande, lcd_numero_ligne, lcd_id_produit, lcd_quantite, lcd_pris_unitaire_ht, lcd_id_taux_tva...)


=> Clés primaires soulignées et clés étrangères en italique.
=> La clé primaire de la table du composant ligne_commande est composée de la clé étrangère référençant la commande et du numéro de ligne dans la commande (de 1 à n pour chaque commande, généralement).
=> Dans le MCD dessiné à l'aide d'un logiciel, l'entité-type faible Ligne_commande aurait la propriété lcd_numero qui serait marquée comme participant à la clé primaire. lcd_id_commande n'arrive qu'au niveau du MLD et n'est donc pas représentée dans le MCD.

3) Les tables associatives porteuses de données identifiantes.
Règles de gestion :
R1 : Un employé peut travailler sur plusieurs projets et un projet voit travailler de un à plusieurs employés.
R2 : Un employé peut travailler plusieurs fois sur le même projet à des périodes différentes.

=> Pour bien faire, je devrais compléter ma seconde règle de gestion mais restons-en à l'association binaire, c'est plus simple. Cette seconde règle de gestion implique que la période va entrer dans l'identification de l'association puisque si je me contente de la première règle, un employé ne peut pas travailler plusieurs fois sur le même projet, ce qui n'est pas conforme à la réalité des faits rencontrés dans les entreprises, de bâtiment par exemple (un ouvrier travaille sur un chantier la première semaine de septembre, part sur un autre chantier la deuxième puis revient jusqu'à la fin du mois sur le premier chantier).

MCD :
Employe -0,n----travailler----1,n- Projet

=> Ici, je ferais figurer les proprités date_debut et date_fin dans l'association travailler et je ferais participer ces deux propriétés à l'identification pour autoriser un employé à travailler plusieurs fois sur le même projet, conformément à la règle de gestion n°2.

Tables :
th_employe_emp (emp_id_personne, emp_matricule, emp_date_embauche...)
te_projet_prj (prj_id, prj_numero, prj_date_debut, prj_date_fin_prevue, prj_budget...)
tj_emp_travailler_prj_etp (etp_id_employe, etp_id_projet, etp_date_debut, etp_date_fin...)

C'est un peu ce dernier cas que vous avez modélisé sauf qu'un contact n'est pas une association mais une entité-type.
On pourrait d'ailleurs transformer mon association travailler en ce que j'appelle une "entité-type associative" :
Employé -0,n----effectuer----(1,1)- periode_travail -(1,1)----avoir_lieu----0,n- Projet

=> Identification de la période de travail relativement à Employé et Projet.
=> Période identifiée en plus par ses dates de début et de fin.
=> Ça ne change que le nom de la table et de ses colonnes selon mon standard de nommage :
te_periode_travail_ptr (ptr_id_employe, ptr_id_projet, ptr_date_debut, ptr_date_fin...)

C'est un peu plus complexe à gérer.

[fsmrel]

Bonsoir martinbrait et CinePhil,


martinbrait,

Je n’ai parcouru que superficiellement les réponses de CinePhil qui fusent comme l’éclair, mais je ne pense pas que nous tenions des discours contradictoires, disons que nous doublonnons parfois. Pour l’histoire du format de la date de la table CONTACT, à vous de voir : dans ce qui suit j’ai conservé votre structure, mais les conseils de CinePhil sont pertinents, ils vous éviteront de réinventer l’eau chaude en ayant à contrôler la structure de la date et programmer les fonctions qui vont bien : en 1986, le type DATE n’existait pas en SQL et tout le monde devait effectivement contrôler manuellement, jusqu’au jour où ce type est arrivé (1987 pour DB2) et tout le monde fut bien content.

Je me décide finalement et définitivement, à convertir systématiquement et exclusivement, toutes dates composant clef primaire en annee|mois|jour(|heure|minute) au format texte

Je vous propose de changer le rôle de cette clé et d’en faire une clé alternative (unicité garantie par définition), laquelle satisfait les 3 avantages que vous présentez. De son côté, une clé primaire doit être artificielle, non significative, donc invariante et sans utilité pour l’utilisateur, donc occultable. Sa fonction première est certes de garantir l’absence de lignes en double dans les tables (qui sont des ensembles au sens de la théorie des ensembles, sinon ce sont des sacs), mais elle doit aussi être un élément déterminant dans la cohésion de la base de données, c'est-à-dire des relations entre tables : une paire clé primaire / clé étrangère participe de la glu qui assure cette cohésion.

Avec votre système, ça peut devenir problématique. Supposons que votre modèle évolue, et qu’une nouvelle table Tx (voyez la table CONTACT_SUIVANT ci-dessous) fasse référence à la table CONTACT (tm_contact_ctc) : Tx devra comporter une clé étrangère {kn_pst, kt_annee_ctc, ..., kt_minute_ctc} référençant CONTACT et on rentre dans la catégorie des problèmes (entre autres !) qui m’ont fait intervenir pendant 30 ans dans nombre d’entreprises, dont les bases de données se figeaient, se sclérosaient du simple fait de clés primaires naturelles, significatives et qu’il fallait guérir.

Méditez la règle d’or du grand Yves Tabourier.

A ce stade, je perçois ainsi le modèle (en l’occurrence un MLD façon PowerAMC, mais lisible par les familiers des diagrammes à la Access, et excusez-moi pour les noms que j’utilise, mais je lis plus facilement ainsi...) :

Notez la clé alternative (symbolisée par <ak>) de la table CONTACT. Notez aussi l’emploi que je fais des clés alternatives (prospectCode, etc.) : ce sont des points d’entrée à la disposition de l’utilisateur qui en a la maîtrise, sauf bien sûr à créer des doublons...

Selon cette clé alternative, la règle de gestion des données est la suivante :

On ne peut pas avoir deux contacts en même temps pour un prospect donné. Mais si la règle était : on ne peut pas avoir deux contacts en même temps, non seulement pour un prospect mais aussi pour plus d’un prospect, alors cette clé devrait être débarrassée de l’attribut prospectId.

Comment entre en scène la clef secondaire [tm_contact_tct].[ks_ctc] ? Auriez-vous une démonstration concrète, avec, pourquoi pas, la mise en lien de mes clients avec plusieurs vendeurs.
Dans mon modèle, les vendeurs suivent et relancent des offres auprès des clients, mais ont interdiction d'entrer en relation avec les prospects
(tr_vendeur_vnd(kn_refvendeur_vnd,t_nomvendeur,t_prenomvendeur) ?

Je suppose que la « clé secondaire [tm_contact_tct].[ks_ctc] » correspond à la clé (devenue primaire dans mon MLD) {prospectId, contactId} de la table CONTACT. Notez au passage l’emploi que je fais des accolades car, dans la théorie relationnelle, une clé est un ensemble.

Vous dites que les vendeurs ne sont concernés que par les clients : la table SUIVRE devrait répondre au besoin. Il pourrait être opportun de mettre en oeuvre une vue permettant de montrer tous les attributs des seuls clients. En SQL normalisé :

CREATE VIEW CLIENTS_SEULS (clientCode, clientNom, clientPrenom, etc, clientMontantAchat, clientFrequenceAnnuelle)
AS
    SELECT clientCode, clientNom, clientPrenom, etc, clientMontantAchat, clientFrequenceAnnuelle
    FROM   PROSPECT AS x JOIN CLIENT AS y ON x.prospectId = y.clientId
                         JOIN SUIVRE AS z ON y.clientId = z.clientId
;

Je vais tenter d’examiner la suite de la discussion, car tous les deux vous fusez !

[fsmrel]

Comment créer un index d'unicité multichamps sous ACCESS ?

Je vous renvoie vers un post de f-leb qui est très au courant et montre comment faire avec l’interface, avec l’utilisation d’un index (objet du niveau physique, donc non traité par la norme SQL). Du point de vue de la norme l’exemple que vous donnez (ALTER TABLE) est quand même plus correct.

Peut on généraliser en disant que toute clef naturelle candidate, composée d'au moins 3 champs,
doit systématiquement être secondée par une clef technique simple autoincrémentée ?

Non. Cela dit, comme j’y ai déjà fait allusion, il faut disposer d’une clé primaire artificielle, sans signification, auto-incrémentée (ou hachée quand on est dans un contexte de forte concurrence) et d’une clé alternative à usage de l’utilisateur pour chaque table à laquelle il peut avoir directement accès (PROSPECT, TYPE_CONTACT, VENDEUR). Cette clé alternative est singleton (un seul attribut). Pour accéder aux autres tables, l’utilisateur passera par des vues, qui ne sont jamais que des tables virtuelles. Par exemple, s’il veut accéder aux données du client dont le code est "P007" (attribut prospectCode), il utilisera la vue CLIENTS_SEULS (voir mon message précédent) :

SELECT clientCode, clientNom, clientPrenom, etc, clientMontantAchat, clientFrequenceAnnuelle
FROM   CLIENTS_SEULS
WHERE prospectCode = 'P007'

Ajouter à la clef technique simple autoincrémentée une contrainte de clef primaire.
Ajouter à la clef naturelle candidate (alternative), composée d'au moins 3 champs, une contrainte d'unicité multichamps,
c'est à dire que les 3 champs identifiés ne peuvent contenir qu'une seule fois la même association de valeurs.

Cette règle est-elle uniquement valable si et seulement si,
l'un au-moins des champs de clef primaire naturelle est une date ou une quantité ?

Au plan théorique, une clé primaire ou alternative est une clé candidate. Tout ce qu’on lui demande donc c’est de respecter les règles d’unicité et d’irréductibilité, ce que je développe ici.
Tout le reste est histoire de convention personnelle. A noter que le type des attributs (date, nombre, etc.) est évidemment totalement étranger à la composition des clés.


A toutes fins utiles, le MCD ayant donné lieu au MLD que j’ai proposé dans mon précédent message :

Avec PowerAMC, les cardinalités 1,1, mises entre parenthèses symbolisent l’identification relative, selon laquelle l’entité-type « enfant » hérite de l’identifiant de son « parent », venant compléter son identifiant propre. Ainsi, l’identifiant de CONTACT (« enfant » de PROSPECT) est en réalité la paire {prospectId, contactId}, celui de CONTACT_SUIVANT est aussi la paire {prospectId, contactId}, etc., ce que l’on voit parfaitement dans le MLD produit par l’AGL. Pour mémoire, sémantiquement parlant, contrairement aux autres entités-types, CONTACT et CONTACT_SUIVANT ne sont pas autonomes, elles n’ont de sens que par rapport à leur « parent », on dit que ce sont des entités-types faibles (weak entity types).

Les mickeys <pi> (pour primary identifier) et <ai> (alternate identifier), permettent de savoir si un attribut entre dans la composition d’un identifiant (principal ou alternatif).

[martinbrait]

Bonsoir fsmrel, CinePhil,

C'est extraordinaire, l'enseignement que vous m'apportez !!
Du sur-mesure, si je m'attendais à ça ...

Là, je précise une définition ENTITE-TYPE, qui me manquait (source : wikipedia)

Une entité-type est une structure composée de propriétés-types, représentant un ensemble d'entités, c'est-à-dire un ensemble de composants identifiables dans un domaine fonctionnel. Une entité-type est potentiellement en association avec les autres entités-types de l'univers étudié (Voir MERISE : notion "d'univers du discours", c'est-à-dire : le sujet étudié).

Par exemple, pour un commerce, plusieurs entités-types peuvent être mises en jeu :

Client
Commande
Produit
Rayon
etc.

mais également plusieurs associations-types qui relient les entités-types :

Passer : 1 Client passe n Commandes
Contenir : 1 Rayon contient n Produits
etc.

Le MCD (Modèle Conceptuel des Données) est un diagramme permettant de modéliser la partie statique d'un système d'information en faisant apparaître les entités-types et leurs associations-types (voir MERISE).

Pour bien comprendre, prenons un exemple concret d'entité et d'entité-type. En français, Monsieur Blondeau est une entité. Cette entité peut faire partie des clients d'une entreprise, dans ce cas l'entreprise pourra le référencer dans ses clients. Ainsi "Client" regroupe des entités, c'est donc un genre d'entité que l'on appelle type d'entité, ou entité-type dans le MCD.

@fsmrel

....il faut disposer d’une clé primaire artificielle, sans signification, auto-incrémentée (ou hachée quand on est dans un contexte de forte concurrence)......

Euh.......la notion de clé hâchée, m'échappe complètement
Comment sait-on qu'on est... "dans un contexte de forte concurrence" ?

Si j'osais, je dirais que ça veut dire... Quand il y a trop de concurrence entre les clients, n'achète pas de rumsteak à la boucherie, mais prend plutôt un steak hâché.

[fsmrel]

Bonjour martinbrait,

Euh.......la notion de clé hâchée, m'échappe complètement

Le hachage des clés est à l’opposé de leur séquencement réalisé par l’auto-incrémentation, c’est en fait calculer la valeur des clés au moyen d’un algorithme qui produit des nombres aléatoires.

L’Auto-incrémentation => 1, 2, 3, 4, 5, ...
Le hachage donne à la place 314777, 147831, 6284, 35710, 2, ...

J’expliquerai plus précisément, plus tard, pourquoi on hache, car maintenant je dois m’absenter pour un bon moment. En fait, pour faire très court, on hache quand il y a une forte concurrence d’accès à une table, c'est-à-dire quand des centaines ou des milliers d’utilisateurs mettent à jour la même table, ce qui entraîne des verrouillages en quantité sur l’enregistrement physique qui reçoit les lignes auto-incrémentées. J’expliquerai donc plus en détail. En attendant, commencez à lire ici, avec un tube d’aspirine à portée de main...


Quant au concept d’entité-type, je vous engage à consulter l’ouvrage remarquable de Dominique Nanci (qui nous a quittés en 2012) Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), co-écrit avec Bernard Espinasse.

[martinbrait]

Merci infiniment,

Vos réponses sont incroyables : rapides, soignées, documentées, méthodologiques, pédagogiques !
Il n'y a qu'ici, avec vous, qu'on trouve celà.

@fsmrel
J'ai hâte, de suivre votre tutoriel, pour me familiariser avec le hachage de clefs (pour les nulls).
Merci beaucoup pour la communication conjointe du MCD, effectivement utile, qui met les points sur les I.

Hier, j'étais aveugle. Aujourd'hui, je viens de récupérer un oeil !
Bonne journée !

[fsmrel]

J'ai hâte, de suivre votre tutoriel, pour me familiariser avec le hachage de clefs

J’ai plein de fers au feu, mais je ne vous oublie pas. En tout cas, le thème du hachage des clés n’est pas si facile que cela à développer, non pas quant au comment, c’est somme toute de la technique assez basique, mais quant au pourquoi...

A plus tard,

François

[martinbrait]

Ah, désolé, fsmrel,

En relisant plusieurs fois de suite cette discussion,
je bloque trop longtemps sur le MLD que vous avez proposé,
qui érige prospectID à la fois au rang de pk, et au rang de ak ?
Complètement perdu maintenant. J'en perds mon latin !
Quel mcd serait derrière le MLD ainsi corrigé ?

Est-ce que le MLD original transmis, signifie la règle de gestion suivante :
"Un contact, établi à tel jour, telle heure, ne peut être établi qu'avec un seul prospect. (ce qui est une bonne chose)


Est-ce que le MLD tel que ci-dessous, correspondrait à la règle de gestion :
"Un contact, établi à tel jour, telle heure, peut être établi avec un ou plusieurs prospects.

Merci de m'aider à comprendre.

Ma correction ci-dessous est-elle pertinente ?
Dans le cas contraire, qu'est-ce que je n'ai pas compris ?

[fsmrel]

Bonjour martinbrait,

Je bloque trop longtemps sur le MLD que vous avez proposé,
qui érige prospectID à la fois au rang de pk, et au rang de ak ?

Selon le MLD que j’ai proposé, la table CONTACT comporte deux clés candidates, dont l’une a été élue clé primaire (K1), tandis que l’autre est clé alternative (K2) :

PK : K1 = {prospectId, contactId}
AK : K2 = {prospectId, contactAnnee, contactMois, contactJour, contactHeure, contactMinute}

Ceci est strictement conforme à la théorie relationnelle.

Pour une valeur de K1, on n’a droit qu’à une seule valeur pour chaque attribut, à savoir prospectId, contactId, contactAnnee, contactMois, contactJour, contactHeure, contactMinute, typeContactId, contactContenu.

Pour une valeur de K2, on n’a droit qu’à une seule qu’à une seule valeur pour chaque attribut, à savoir à nouveau prospectId, contactId, contactAnnee, contactMois, contactJour, contactHeure, contactMinute, typeContactId, contactContenu.

Ces clés sont inférées des règles de gestion des données suivantes :

Pour un prospect on peut avoir plusieurs contacts,

Pour chaque contact, la valeur prise par la paire {prospectId, contactId} est unique (même chose pour les autres attributs déterminés par cette paire),

Pour chaque contact, la valeur prise par le n-uplet {prospectId, contactAnnee, contactMois, contactJour, contactHeure, contactMinute} est unique (même chose pour les autres attributs déterminés par ce n-uplet).

La valeur prise par l’attribut contactId est sans signification, on peut donc y trouver plusieurs fois le même nombre, et l’on n’a pas à s’y intéresser d’un point de vue fonctionnel, il reste sous le capot.


Exemple (je symbolise contactAnnee, ..., contactMinute par dateContact) :

PROSPECT {prospectId    ProspectCode    ProspectNom    ProspectPrenom    ...}
          p1             NAU001         Naudin         Fernand           ...
          p2             VOL001         Volfoni        Raoul             ...
          p3             VOL002         Volfoni        Paul              ...

CONTACT {prospectId    contactId    dateContact    typeContactId    contactContenu}
         p1            1            date1          t1               cont1
         p1            2            date2          t2               cont2
         p1            3            date1          t3               cont3     /* illégal ! (cf. K2) */

         p2            1            date5          t2               cont7
         p2            2            date1          t4               cont2

         p3            1            date1          t1               cont7
         p3            2            date8          t1               cont4

Vous noterez que le contact <p1, 3> ne pourra pas exister parce que <p1, date1> doublonnerait, ce qui est interdit par K2 (cela dit, il suffit d’une différence sur la minute, et Raoul peut avoir deux rendez-vous en même temps. Il faudra utiliser le type TIMESTAMP et empêcher les « collisions » par trigger ou autre moyen).

Pour chaque prospect, j’ai affecté les valeurs successives 1, 2, 3, ..., n, mais c’est un pur hasard puisque les valeurs prises par contactId sont sans signification...

Ma correction ci-dessous est-elle pertinente ?

Cette solution est pertinente. Simplement, pour connaître la date du prochain contact, il faudra effectuer une jointure avec les 3 tables PROSPECT, CONTACT, CONTACT_SUIVANT, alors qu’avec la présence de prospectId dans la table CONTACT_SUIVANT, on n’a pas besoin de joindre avec la table CONTACT. C’est plus simple, mais ça n’est pas essentiel : si vous sentez mieux votre solution, utilisez-la et dormez en paix.

En passant : plusieurs prospects distincts peuvent-ils avoir un contact en même temps ? C’est ce que j’ai supposé dans l’exemple.

Sympa votre avatar...