Bonjour,
Envoyé par
dalinbm
l'identifiant CodeBr a ete remplacer par IdSite (c'est le meme role)
Les deux attributs identifiants IdSite etCodeBr ont évidemment pour objet de garantir l’unicité, mais l’un, CodeBr, est naturel, significatif tandis que l’autre, IdSite est artificiel, sans signification, donc invariant.
Je cite la règle d’or du très grand Merisien Yves Tabourier (page 80 de son remarquable ouvrage De l’autre côté de Merise, Les Éditions d’organisation, 1986) :
« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »
Aujourd’hui encore, tout le monde ne partage pas cet avis, mais après 40 ans de modélisation chez me clients, d’audits, de sauvetages en catastrophe, barouds en tout genre, etc., j’ai pu constater de ce qu’il en coûtait de ne pas tenir compte de la règle d’or.
Un exemple dont je me sers de temps en temps : il s’agit du système préconisé par les concepteurs dans une très grande banque de France, consistant à identifier les entreprises par leur numéro Siren, fourni par un organisme extérieur, à savoir l’INSEE. Par voie de conséquence, au niveau du MLD (Modèle Logique de Données selon Merise), puis SQL, ce Siren devait être propagé dans toute la base de données par le jeu des liens clé primaire - clé étrangère. Les concepteurs avaient entrepris le montage d’une véritable usine à gaz pour maintenir la cohérence entre les tables, parce que l’INSEE envoyait tous les mois les nombreux correctifs modifiant les numéros de Siren erronés. Tout en leur commentant l’ouvrage d’Yves Tabourier, je leur suggérai que l’identifiant de l’entreprise fît l’objet d’une propriété nouvelle et artificielle, invariante et sans signification, EntrepriseId, le numéro Siren devenant pour sa part identifiant alternatif, c'est-à-dire conservant sa spécificité : être unique et pouvant subir toutes les modifications de la part de l’utilisateur, sans aucun danger pour la base de données. Au niveau MLD et SQL, l’ex clé primaire, le numéro Siren fit donc l’objet d’une clé alternative, point d'entrée dans la table, permettant à l'utilisateur d’accéder aux données de chaque entreprise, la suite des opérations se passant de façon transparente, encapsulée pour utiliser un jargon à la mode, grâce à la nouvelle clé primaire {EntrepriseId} prenant le relais de sa copine clé alternative : du point de vue de l’utilisateur et des règles fonctionnelles, rien de changé, mais l’usine à gaz disparut en fumée, des économies importantes furent réalisées, et tout le monde fut content.
Un conseil : conservez les deux identifiants. Côté Looping, pour l’attribut SiteId, après avoir retenu SQL Server comme SGBD, choisissez le type Compteur : le code SQL comportera "Identity". Exemple :
1
2
3
4
5
6
7
8
| CREATE TABLE Site(
SiteId INT IDENTITY,
CodeBr CHAR(5) NOT NULL,
SiteAdresse VARCHAR(50) NOT NULL,
SiteNom VARCHAR(50) NOT NULL,
CONSTRAINT Site_PK PRIMARY KEY(SiteId),
CONSTRAINT Site_AK UNIQUE(CodeBr)
); |
CodeBr est bien clé alternative, donc tout va bien.
Divers
A propos de votre message :
Envoyé par
dalinbm
un autre error lors de l'insertion des données dans la table mission:
INSERT INTO [dbo].[Mission]([Id_Mission],[date_Debut],[Date_Fin] ,[Objectif],[IdEmploye],[Id_Type_Mission]) VALUES (801,'2024-09-10 8:00:00' ,'2024-09-16 8:00:00','test5',700,610)
GO
error :
The INSERT statement conflicted with the FOREIGN KEY constraint "FK__Mission__IdEmplo__4222D4EF". The conflict occurred in database "Mission", table "dbo.Chauffeur", column 'IdEmploye'.
Pour faciliter la recherche des erreurs, dans la fenêtre "Propriétés" de Looping :
dans la partie MLD – SQL, "nom de clé étrangère", choisissez l’option [Classe_FK] et pour "Nom contrainte clé": choisissez "Suffixé".
Je vais me pencher sur le problème fort intéressant des réservations.
Répondre avec citation
.png)
.png)
!!! Mais personne ne m'a encore démontré pourquoi un identifiant signifiant vraiment pérenne pouvait représenter un danger pour le SI, ni pourquoi les dates (rubriques hautement significatives) ne posent pas de problème aux adeptes des identifiants non significatifs... Et, à tous les exemples issus de ton immense expérience (n° SIREN, ...), on peut systématiquement répondre que ces identifiants n'étaient pas vraiment pérennes..png)
.png)
.png)
.png)
Utiliser la CIF m’était complètement sorti de la tête....png)
.png)
Partager