Discussion :

[escartefigue]

C'est là que nous nous rejoignons ! Je suis d'accord avec toi sur le fait que ce soit plutôt rare.
Je suis juste réfractaire au fait de ne même pas se poser la question et, pour certains, en arriver à appliquer une règle sans même savoir pourquoi ...

C'est le risque en effet.
N'oublions pas également les autres arguments.
Outre la stabilité, une clef technique de type integer présente l'avantage d'être insensible à la collation et d'être la plus concise qui soit.

[escartefigue]

Ave,


Il ne peut donc s’agir d’une banque où j’ai porté la bonne parole au bon vieux temps...

Probablement pas, ou alors ils ont tout oublié, car il y a 4-5 ans de ça, ils ont créé une toute nouvelle application avec une nouvelle base de données sous-jacente très simple, basée sur deux tables.
Et je vous donne en mille : la PK de la table principale a été définie en varchar(50) ... Si si !
Quand j'ai demandé au concepteur pourquoi un tel choix, j'ai eu ma réponse : "bah... pourquoi pas" .
Il a été bien dépité quand je lui ai expliqué, mais c'était malheureusement trop tard, le bousin était en production avant que je découvre le méfait

[escartefigue]

Merci pour votre retour.

Je pense ne pas avoir bien saisi identifiant fonctionnel, d'identifiant primaire.

Est-ce que identifiant fonctionnel est-ce que vous parlez des dates et des noms ?
Est-ce que par exemple je pourrais remplacer cela par code_date et code_personne (ou numéro INSEE) ?



Merci par avance

Cordialement

Mathieu

Un identifiant fonctionnel est un identifiant qui a un sens : le nom, le numéro de sécurité sociale, le code SIREN... Tous ces attributs, seuls ou combinés, peuvent être utilisés comme identifiants fonctionnels.

Un identifiant technique est dépourvu de sens autre que celui de distinguer chaque occurrence des autres. Ça peut être un compteur incrémenté ou décrémenté à chaque nouvelle ligne enregistrée dans la base, un horodatage très fin de sorte à être unique (genre time-stamp).

Un identifiant primaire, pourrait a priori être aussi bien un identifiant technique que fonctionnel sous réserve qu'il soit unique, non "nullable" et irréductible.
Mais, pour toutes les raisons pré-citées, il est sage d'utiliser un identifiant technique, gage de stabilité et de performance

[__mathieu__]

Je pense avoir compris,

Quand vous parlez de clé je ne comprenez pas.
Mais la clé intervient dans le MLD et la clé est la même chose que l'identifiant.
Du coup si je mets un nom de famille comme identifiant, deux Julien DUPONT ne pourrait être distingué.
Est-ce bien cela ?



Merci par avance

Cordialement

Mathieu

[Paprick]

Outre la stabilité, une clef technique de type integer présente l'avantage d'être insensible à la collation et d'être la plus concise qui soit.

Tout à fait d'accord : c'est pourquoi j'exige aussi du formalisme dans le choix d'un identifiant (ce qui écarte les VARCHAR !)
Règles pour un bon Identifiant : Unicité, Formalisme, Pérennité, Légalité (exit le n°Sécu !) et irréductibilité (à moins qu'on veuille à tout prix des surclés).

[__mathieu__]

Merci je n'avais pas vu votre réponse.

Merci beaucoup.

Un identifiant fonctionnel est un identifiant qui a un sens : le nom, le numéro de sécurité sociale, le code SIREN... Tous ces attributs, seuls ou combinés, peuvent être utilisés comme identifiants fonctionnels.

Un identifiant technique est dépourvu de sens autre que celui de distinguer chaque occurrence des autres. Ça peut être un compteur incrémenté ou décrémenté à chaque nouvelle ligne enregistrée dans la base, un horodatage très fin de sorte à être unique (genre time-stamp).

Un identifiant primaire, pourrait a priori être aussi bien un identifiant technique que fonctionnel sous réserve qu'il soit unique, non "nullable" et irréductible.
Mais, pour toutes les raisons pré-citées, il est sage d'utiliser un identifiant technique, gage de stabilité et de performance

[__mathieu__]

Bonjour Monsieur,

Est-ce que votre ouvrage sur le cours + exercices sur le MCD on peut se le procurer en librairie ou c'est uniquement sous @mazon.

Merci par avance

Cordialement

Tout à fait d'accord : c'est pourquoi j'exige aussi du formalisme dans le choix d'un identifiant (ce qui écarte les VARCHAR !)
Règles pour un bon Identifiant : Unicité, Formalisme, Pérennité, Légalité (exit le n°Sécu !) et irréductibilité (à moins qu'on veuille à tout prix des surclés).

[Paprick]

Bonjour,

Est-ce que votre ouvrage sur le cours + exercices sur le MCD on peut se le procurer en librairie ou c'est uniquement sous @mazon.

Les librairies font rarement du stock sur ce genre d'ouvrages spécialisés : elles pourront vous le commander, mais ça prendra plus de temps (et peut-être plus de frais de port...)

[escartefigue]

@ __Matthieu__

dans le dernier MCD : le code catalogue est un mauvais choix pour idenfier le livre.

• d'une part, le "livre" dans ce modèle, n'est pas encore édité, il n'est donc dans aucun catalogue
• d'autre part, un catalogue possède son propre référencement régi par l'organisme externe qui produit ce catalogue et donc susceptible de changer à tout moment.
  Et là PAF ! c'est le drame : identifiant instable qui provoque des mises à jour en masse dans la base de données
  On y revient toujours : virez ce code catalogue et remplacez le par un "counter" selon la nomenclature de Looping, c'est à dire un chrono technique

[__mathieu__]

Désolé,

J'ai encore une question
On demande aussi de gérer les abonnés par la catégorie d'âge.
Est-ce que dans abonné je devrais mettre un autre attribut ?
Est-ce que cela ne serait pas déjà redondant avec la date de naissance ?

Merci par avance

Cordialement

Mathieu

[__mathieu__]

Donc je précise au prof que sa consigne est fausse ?

@ __Matthieu__

dans le dernier MCD : le code catalogue est un mauvais choix pour idenfier le livre.

• d'une part, le "livre" dans ce modèle, n'est pas encore édité, il n'est donc dans aucun catalogue
• d'autre part, un catalogue possède son propre référencement régi par l'organisme externe qui produit ce catalogue et donc susceptible de changer à tout moment.
  Et là PAF ! c'est le drame : identifiant instable qui provoque des mises à jour en masse dans la base de données
  On y revient toujours : virez ce code catalogue et remplacez le par un "counter" selon la nomenclature de Looping, c'est à dire un chrono technique

[__mathieu__]

@ __Matthieu__

dans le dernier MCD : le code catalogue est un mauvais choix pour idenfier le livre.

• d'une part, le "livre" dans ce modèle, n'est pas encore édité, il n'est donc dans aucun catalogue
• d'autre part, un catalogue possède son propre référencement régi par l'organisme externe qui produit ce catalogue et donc susceptible de changer à tout moment.
  Et là PAF ! c'est le drame : identifiant instable qui provoque des mises à jour en masse dans la base de données
  On y revient toujours : virez ce code catalogue et remplacez le par un "counter" selon la nomenclature de Looping, c'est à dire un chrono technique

J'ai oublié le copier-coller de l'énoncer :

Les livres sont identifiés par un code catalogue qui identifie le titre du livre et un code exemplaire qui est généré de manière unique à l’achat du livre

Maintenant il faut demander à Monsieur le Professeur d'Université que faut-il faire ?
Suivre la consigne ou non

[__mathieu__]

Bonjour,

Les librairies font rarement du stock sur ce genre d'ouvrages spécialisés : elles pourront vous le commander, mais ça prendra plus de temps (et peut-être plus de frais de port...)

Pas grave pour les frais de port. Je préfère faire travailler ma petite librairie.
Demain je les appelle et je passe commande.
J'espère qu'il y a pas mal d'exos, j'ai besoin de m'entrainer.

[escartefigue]

J'ai oublié le copier-coller de l'énoncer :



Maintenant il faut demander à Monsieur le Professeur d'Université que faut-il faire ?
Suivre la consigne ou non

S'il est capable d'expliquer comment un livre jamais édité peut être présent dans un catalogue, je suis preneur

Dans tous les cas, n'utilisez jamais d'identifiant issu d'une nomenclature externe comme identifiant primaire, car une nomenclature externe peut changer à tout moment !
Comme ce "catalogue" (encore une fois je demande à voir mais bon) n'appartient pas à votre application, ne l'utilisez pas comme pk

[fsmrel]

Bonjour,

On demande aussi de gérer les abonnés par la catégorie d'âge.
Est-ce que dans abonné je devrais mettre un autre attribut ?
Est-ce que cela ne serait pas déjà redondant avec la date de naissance ?

Pour redonder ça redonderait... Et puis il faudrait un programme qui surveille chaque jour tous les changements de catégorie et effectuer les mises à jour qui s’imposent !

Autrement dit, connaissant la date de naissance de l’abonné Raoul, une requête SQL (ou autre langage) suffit pour savoir dans quelle catégorie le ranger à telle date (par exemple aujourd’hui ou il y a un mois, etc.) et afficher cela.

Moralité : pas d’attribut supplémentaire dans l’entité-type PERSONNE (ou ABONNE).

Incidemment, avez-vous étudié SQL ?

[escartefigue]

Désolé pour ces réponses qui tombent un peu dans le désordre car nos messages se croisent

Donc je précise au prof que sa consigne est fausse ?

Non pas tout à fait, car dans l'énoncé il est mentionné l'achat du LIVRE mais il faut en réalité comprendre achat de l'EXEMPLAIRE de ce livre
Du coup, la présence d'un code catalogue est tout à fait possible puisqu'on achète un exemplaire qui a donc fait l'objet d'une édition, mais pour autant, les réserves précédemment émises quant à l'utilisation de ce code catalogue comme identifiant primaire subsitent.
Par contre, vous pouvez tout à fait utiliser le code catalogue comme autre identifiant, unique ou pas selon les règles d'attribution de ce code (règles que j'ignore), mais pas comme identifiant primaire.

N'oubliez pas d'approuver les réponses qui ont pu vous mettre sur la voie, les encouragements font toujours plaisir

[fsmrel]

Ave,

Dans tout son S.I., le code banque (type char(5)) est utilisé comme clef primaire, bien sûr propagée dans plein de tables

Il ne peut donc s’agir d’une de ces banques où j’ai porté la bonne parole au bon vieux temps...

fuyez systématiquement l'utilisation d'une colonne ayant un sens fonctionnel comme identifiant primaire.
L'identifiant primaire doit être stable et pour se faire asémantique. La raison est que l'id primaire se propage via les contraintes d'intégrité dans d'autres tables.
Si la valeur est modifiée (ce qui arrive souvent aux contenus fonctionnels. Ex: l'éditeur change de nom), alors ça va propager plein de modifs inutiles dans les tables filles. Donc, faites comme pour les autres types d'entité : un chrono attribué par le SGBD sera parfait

Il est évident que ce qui est sémantiquement parfait là-haut, dans la dunette MCD, est à examiner de très près par le DBA qui est sur le pont et dans la soute. Le DBA pense très fort notamment à la validité, la pérennité et à la performance de la base de données qu’il va installer et sera l’objet de toutes ses attentions. Ainsi, quand le chef de projet passe le relais au DBA, c’est parti pour des discussions dans lesquelles de toute façon celui-ci aura le dernier mot puisqu’il sera le grand responsable en cas de problèmes (sachant que les lauriers sont pour le chef de projet). La stabilité 100% de la clé (primaire ou alternative) utilisée pour les contraintes référentielles (clés étrangères) est évidemment indispensable, il s’agit d’un point absolument crucial, sinon gare aux “nervousses brékdones” comme disent les frères Volfoni.

Je radote avec mes numéros de SIREN attribués par l’INSEE, mais je reprends ce que j’avais raconté ici ou là :

J’ai le souvenir d’une administration dans laquelle le matricule du personnel était composé des 6 premiers caractères du nom et de la date de naissance (AAMMJJ), cf. le post #42. Quid si deux personnes ont le même nom ? Même pas grave ! Si la 1re personne est née par exemple le 31 janvier 1990, on considérera que la 2e sera née 31 jours plus tard, à savoir le 62 janvier. Et si une 3e personne a elle aussi le même nom et est née le 31 janvier ? Elle naîtra le 93 janvier. Et si une 4e personne a elle aussi le même nom et est née le 31 janvier ? Le polytechnicien de service avait considéré qu’il était impossible que, dans cette administration, quatre personnes ayant le même nom soient nées le même jour. Et patatras, quelques temps après le démarrage de l’application, ça s’est produit suite à une embauche ! Aïe ! Prévenez le chef ! Tout le monde sur le pont ! Mais qu’est-ce-que-fait-on ? En 2020, on trouve facilement des solutions, mais là, ça se passait il y a plus de cinquante ans (on avait quand même bien rigolé avec toute l’équipe des programmeurs, c’était le bon temps...)

Et j’apporte une précision :

L’X de service ignorait quand même une chose : si une personne ne connaît que son année de naissance, dans la base de données elle sera née le 31 décembre de cette année. Bonjour les doublons...

[fsmrel]

Je viens de me rendre compte d'une autre boulette dans mon modèle :
après avoir cliqué par erreur sur le type "compteur" pour le nom (c'était probablement juste après l'apéro ), je vois que j'ai également déclaré "not null" l'ISBN dans l'entité-type EO_edition.
Grave erreur, car, comme je l'indiquais un peu plus haut, l'ISBN n'existe que depuis 1970 et que pour les ouvrages soumis au dépôt légal.
Comme quoi, on a beau se relire (et se faire relire ) on trouve toujours ici et là quelques coquilles

Effectivement, après l’apéro, tel Raoul qui n’a plus sa tête, on est tous sujets à quelques égarements...

Je suis en train de déguster un excellent Cardhu, et peut-être vais-je dérailler... Au sujet de l’ISBN, ta remarque est excellente, mais pourquoi ne pas conserver “NOT NULL” et par conséquent utiliser une valeur par défaut, du genre "/" ou autre ?

[escartefigue]

Une valeur par défaut est possible, mais comme pour l'apéro, c'est une question de proportions, il ne faudrait pas que telle bibliothèque, spécialisée dans les éditions anciennes, se retrouve avec la quasi-totalité des ses exemplaires affublée de ce pis-aller. Réponse faite, leffe à la main, frappée la leffe bien entendu

[fsmrel]

Mathieu,

Selon votre MCD, une réservation fait référence à un éditeur, mais selon l’énoncé du prof, une demande concerne en fait un livre en particulier et non pas tous les livres d’un éditeur donné : y a du mou dans la corde à noeuds...