Application Database Configuration

Bonne réponse : B

Pourquoi cette question existe — STU §3.7 — la question vérifie la convention de nommage des tables secondaires multilingues, un détail technique précis facilement confondu avec d'autres préfixes plausibles. En pratique, ce nom de table intervient lors de tout diagnostic de traduction manquante.

Le contexte théorique d'abord — Lorsqu'un objet métier est activé pour le support multilingue, Maximo génère une table secondaire de langue nommée avec le préfixe L_ suivi du nom de l'objet. Pour l'objet ITEM, cette table secondaire est L_ITEM, qui stocke les valeurs traduites des champs marqués « Multilanguage in Use ».

Ce que Maximo en fait — version opérationnelle — Dans Database Configuration, sélectionner l'attribut à traduire > cocher Multilanguage in Use > Configure Database. Maximo écrit alors les traductions dans L_ITEM au lieu de modifier directement la table ITEM.

Exemple chiffré — Un catalogue de 5 000 items traduit en 3 langues (FR, EN, ES) génère jusqu'à 15 000 lignes potentielles dans L_ITEM, contre 5 000 lignes uniques dans la table ITEM elle-même.

Analogie quotidienne — C'est comme une fiche produit principale (ITEM) accompagnée d'un classeur de traductions séparé (L_ITEM) que l'on consulte selon la langue du lecteur.

Pourquoi A est faux — Pattern D9 quasi-synonyme : ITEM est l'objet/table principale elle-même, pas la table secondaire de langue.

Pourquoi C est faux — Pattern D5 champ-frère : MAXTRANSLATION est un objet système général lié à la traduction d'interface, pas la table secondaire spécifique à ITEM.

Pourquoi D est faux — Pattern D2 inventé : « A_ITEM » ne suit pas la convention de nommage réelle des tables de langue Maximo (préfixe L_, pas A_).

Bonne réponse : B

Pourquoi cette question existe — STU §3.7 — la question identifie le mécanisme précis d'audit automatique des changements de données, distinct de la signature électronique qui authentifie une action plutôt que de tracer l'historique. En pratique, ce réglage est requis avant tout audit de conformité sur un objet sensible.

Le contexte théorique d'abord — Dans Database Configuration, chaque Object dispose d'un attribut Audit Enabled. Lorsqu'il est activé, Maximo enregistre automatiquement un historique des modifications apportées aux enregistrements de cet objet, sans action manuelle supplémentaire.

Ce que Maximo en fait — version opérationnelle — Dans Database Configuration > sélectionner l'objet cible > cocher Audit Enabled > Configure Database. Toute modification ultérieure sur les enregistrements de cet objet est alors historisée automatiquement.

Exemple chiffré — Sur un objet critique avec Audit Enabled coché, 1 200 modifications mensuelles sont historisées automatiquement, contre 0 trace conservée si la case reste décochée.

Analogie quotidienne — C'est comme activer l'historique des versions d'un document partagé : une fois activé, chaque modification est tracée sans action supplémentaire de l'utilisateur.

Pourquoi A est faux — Pattern D2 inventé : « Changes Collection » n'est pas un mécanisme de configuration Maximo réel.

Pourquoi C est faux — Pattern D2 inventé : il n'existe pas d'action « Track Changes » dans Database Configuration ; le mécanisme réel est la case Audit Enabled.

Pourquoi D est faux — Pattern D5 champ-frère : l'e-signature authentifie une action spécifique de l'utilisateur, mais ne crée pas d'historique automatique des changements de données.

Bonne réponse : C

Pourquoi cette question existe — STU §3.7 — la question cible un mécanisme de configuration peu visible mais crucial : la propagation des changements de type/longueur entre attributs liés. Les distracteurs proposent des effets plausibles (copie de valeurs, de scripts, de formules) qui ne correspondent pas à la fonction réelle du champ Same As. En pratique, ignorer ce mécanisme provoque des incohérences de longueur entre champs censés rester synchronisés.

Le contexte théorique d'abord — Le champ Same As dans Database Configuration indique qu'un attribut doit répliquer automatiquement les changements de type et de longueur appliqués à un attribut de référence, garantissant la cohérence entre plusieurs champs censés rester synchronisés (ex. champs dupliqués entre objets liés).

Ce que Maximo en fait — version opérationnelle — Dans Database Configuration, sur l'attribut concerné, le champ Same As référence l'attribut source. Si l'on modifie la longueur de l'attribut source et qu'on lance Configure Database, l'attribut « Same As » reçoit automatiquement la même longueur, sans devoir l'éditer manuellement.

Exemple chiffré — Un attribut source étendu de 20 à 30 caractères propage ce changement à 4 attributs « Same As » liés, évitant 4 modifications manuelles distinctes.

Analogie quotidienne — C'est comme un format de cellule Excel lié par référence : changer la largeur de la cellule source met automatiquement à jour la largeur des cellules qui la « suivent », sans recopier le contenu lui-même.

Pourquoi A est faux — Pattern D5 champ-frère : la logique d'Automation Script est indépendante du champ Same As, qui ne concerne que type/longueur.

Pourquoi B est faux — Pattern D9 quasi-synonyme : Same As ne copie pas les valeurs des enregistrements, seulement la définition de type/longueur de l'attribut.

Pourquoi D est faux — Pattern D2 inventé : aucune fonctionnalité Same As ne copie de formules entre attributs.

Bonne réponse : D

Pourquoi cette question existe — STU §3.7 — la question vérifie la connaissance de la taxonomie des types d'attribut Database Configuration, où « GL » est un type réel (dédié aux comptes General Ledger) alors que les distracteurs nomment des concepts d'un autre registre (Domain, Table = types de Domain, pas d'attribut ; String n'existe pas tel quel comme type Maximo, le type texte réel étant ALN). En pratique, confondre types de Domain et types d'Attribute brouille la configuration technique.

Le contexte théorique d'abord — Le champ Type d'un attribut dans Database Configuration propose une liste fermée de types de données (ALN, AMOUNT, DATE, DATETIME, DECIMAL, FLOAT, GL, INTEGER, LOWER, SEQUENCE, SMALLINT, UPPER, YORN, etc.). GL est le type réservé aux attributs représentant un compte General Ledger, avec une validation spécifique de format de compte.

Ce que Maximo en fait — version opérationnelle — Dans Database Configuration > sélectionner un objet > onglet Attributes > créer/éditer un attribut > champ Type = GL pour qu'il valide la saisie selon le masque GL défini dans Chart of Accounts.

Exemple chiffré — Un attribut de type GL validant un masque à 4 composants (ex. 6-3-4-2 caractères, 15 caractères au total) rejette toute saisie ne respectant pas cette structure exacte.

Analogie quotidienne — C'est comme un champ de formulaire qui valide automatiquement le format d'un numéro de compte bancaire (IBAN) : le type GL impose sa propre grammaire de validation.

Pourquoi A est faux — Pattern D9 quasi-synonyme : DOMAIN est un concept lié (le domaine pouvant être associé à un attribut), mais pas lui-même une valeur du champ Type.

Pourquoi B est faux — Pattern D9 quasi-synonyme : « STRING » n'est pas la valeur exacte du type texte Maximo ; le type réel correspondant est ALN.

Pourquoi C est faux — Pattern D9 quasi-synonyme : TABLE est un type de Domain (cf. Q106), pas une valeur du champ Type d'un attribut.