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