Documentation sur Oracle Cloud Infrastructure

Recommandations et conseils pour l'extension du modèle sémantique

Avant d'étendre votre modèle sémantique, consultez les recommandations et les conseils pour vous assurer que vos extensions fonctionnent comme prévu.

Cadre d'extensions de modèle sémantique

Cadre de succursale

Si vous êtes toujours dans le cadre de branche de modèle sémantique, c'est le moment de migrer vers le cadre de bac à sable. Voir Migrer vers le cadre de bac à sable pour les extensions de modèle sémantique.

Cadre de bac à sable

Conservez uniquement les bacs à sable en cours d'utilisation. Supprimez les bacs à sable que vous avez utilisés pour les tests et qui ne sont plus utilisés. La gestion d'autres modèles d'environnement restreint inutilisés nuit aux performances du système.

Objets de base de données

Normes d'attribution de nom de base de données pour les objets autonomes d'entrepôt avec lac de données

  • Ajoutez le préfixe X_ZZZ_ à un objet personnalisé, où ZZZ est une abréviation de votre organisation.
  • Suffixe d'objets différents :
    • _A = Agrégation
    • _D = Dimension
    • _DH = hiérarchie de dimension
    • _F = Fait
    • _H = aide
    • _M = Dimension de mappage
    • _MD = Mini dimension
    • _V = Vues
    • _MV = Vue matérialisée
    • _DS = Jeu de données d'augmentation de données
    • _EXT = Extension d'augmentation de données
  • Ne créez aucun objet de base de données personnalisé commençant par "DW", car cela peut entraîner des conflits avec les noms d'objet prédéfinis. Les objets de base de données personnalisés commençant par "DW" peuvent entraîner un comportement incohérent dans l'Assistant Extensions de modèle sémantique.
  • N'utilisez pas ces suffixes réservés par le système pour les noms de schéma personnalisé : DW, OAC, INFRA, SECURITY, USER ou CORE.

    Si vous utilisez l'un de ces suffixes réservés par le système pour les noms de schéma personnalisé, vous risquez d'accorder des privilèges involontaires à votre schéma personnalisé lors du traitement du pipeline.

Jeux de données et champs flexibles d'augmentation de données

  • Assurez-vous que les modifications apportées à la source sont prises en compte dans votre instance Oracle Fusion Data Intelligence. Par exemple, si un champ flexible descriptif utilisé dans un domaine personnalisé a été désactivé dans la source, vous devez remplacer ou supprimer le champ flexible descriptif applicable dans Oracle Fusion Data Intelligence, sinon l'extension de modèle sémantique applicable échoue.
  • Vous pouvez référencer des synonymes à partir des jeux de données d'augmentation de données dans les extensions de modèle sémantique une fois le chargement complet initial de l'augmentation de données terminé. Utilisez l'option Exécuter immédiatement dans l'augmentation de données pour exécuter le chargement complet immédiatement.

Extension

Général
  • Lorsque vous nommez des objets (dimensions, faits et colonnes), supprimez tous les espaces de début et de fin. Vous pouvez utiliser des traits de soulignement et des espaces dans les noms, mais évitez tout autre caractère spécial.
  • Lors de l'ajout d'attributs personnalisés ou de la définition de clés utilisées pour la jointure, assurez-vous que le nom d'affichage est unique et n'entre en conflit avec aucun des noms de colonne prédéfinis.
Étendre la dimension
  • Important : Vous devez limiter au minimum les extensions et les combiner pour éviter des frais généraux inutiles et des performances dégradées. Lors de l'extension d'une dimension (si la granularité de l'extension est de un à un [1:1] avec la dimension prédéfinie), combinez plusieurs extensions pour la même dimension dans une source unique (table/vue/synonyme) dans Autonomous AI Lakehouse. Il est préférable d'avoir une extension avec plusieurs colonnes, plutôt que d'avoir plusieurs extensions par colonne.
  • Attention : Lors de l'extension d'une dimension, il est fortement recommandé de se joindre à la clé de dimension de base. S'il n'est pas possible de se joindre à la clé de dimension de base, vous pouvez vous joindre à une autre colonne de base avec prudence, en validant la granularité des données et la cardinalité. Il est fortement déconseillé de se joindre à une autre colonne d'extension. Le système traite les extensions avec des dépendances de manière séquentielle, ce qui allonge le temps nécessaire pour appliquer et publier le bac à sable et pourrait avoir une incidence négative sur les performances des interrogations.
  • Lors de l'extension des dossiers DEGEN Dimensions ("détails"), maintenez toujours le même niveau de granularité en joignant sur la ou les clés primaires du fait une relation un à un [1:1]. Ne définissez pas plusieurs à plusieurs jointures [M:M] car cela peut entraîner une dégradation des performances et une duplication des données.
  • Soyez prudent lorsque vous étendez des dimensions qui ont une à plusieurs relations (1:M) (telles que la sélection multiple), car :
    • Elles peuvent entraîner une duplication des données car les données étendues ont une granularité inférieure à celle de la dimension parent.
    • La longueur maximale de l'index d'extension peut être dépassée.

    Pour éviter la contrainte, nommez la table/vue/synonyme aussi courte que possible. Par exemple, FDI_X_SZ_V (taille) et FDI_X_PR_V (prix).

  • Avant d'étendre un objet logique, vérifiez que la table de présentation associée est exposée dans le domaine. Reportez-vous aux feuilles de calcul de lignage de modèle sémantique applicables :
  • Lors de l'extension d'une dimension, si la table que vous sélectionnez est une table d'augmentation, sélectionnez-la dans le schéma OAX$OAC au lieu de OAX_USER. Le schéma principal pour les tables d'augmentation est OAX$OAC même si les tables d'augmentation sont également présentes dans OAX_USER.
  • La taille de colonne de l'attribut étendu ne peut pas dépasser 256 caractères.
  • Lors de l'extension des dimensions, choisissez un type de jointure en fonction de votre type de dimension (dégénéré ou conforme) et de la relation entre les tables de base et d'extension. Votre choix dépend de la conservation ou de l'abandon des enregistrements sans correspondance.
    • Externe gauche : Recommandé pour la plupart des extensions afin de conserver toutes les lignes de la table de base, en particulier pour les relations 1:many ou lorsque la table étendue est incomplète. Cela évite de supprimer involontairement les lignes de base.
    • Intérieur : Idéal pour une vraie relation 1:1 lorsque vous ne voulez que des enregistrements qui existent dans les deux tables et sont confortables à l'exclusion des lignes sans correspondance. Non recommandé lors de l'extension des dimensions dégénérées.
    • Extérieur droit : rarement utilisé. Sélectionnez cette option lorsque vous devez conserver toutes les rangées de la table étendue et extraire uniquement les rangées correspondantes de la table de base.
    • Full Outer : À utiliser avec prudence pour conserver toutes les lignes des deux tables, quelles que soient les correspondances. N'utilisez pas Full Outer sur des dimensions dégénérées, car elles peuvent entraîner une duplication des données et une dégradation des performances.

Créer une dimension

  • Lors de la création d'une dimension personnalisée, vous pouvez désélectionner Ajouter une hiérarchie au domaine. Toutefois, il est toujours nécessaire de définir une clé primaire de hiérarchie et un attribut d'affichage. Cliquez sur le dossier Selected Data Elements Detail, puis sur l'icône de modification Properties pour définir la clé primaire de la hiérarchie et l'attribut d'affichage.

Créer des dimensions dégénérées

  • Évitez d'ajouter des attributs de dimension non dégénérés aux tables de faits. Sélectionnez plutôt l'indicateur de dégénérescence de l'attribut lors de la définition de la table de faits. Les attributs de dimension sans indicateur dans les tables de faits auront une incidence négative sur la structure de votre rapport, augmenteront le risque d'erreurs d'exécution et compliqueront la maintenance du système.
Créer un fait
  • Lors de l'ajout d'un fait personnalisé, définissez toujours les niveaux de contenu des dimensions personnalisées qui se joignent au fait personnalisé.
  • Lorsque vous joignez des faits à des dimensions, assurez-vous que les colonnes jointes ont des types de données compatibles.
Créer une hiérarchie
  • Lors de l'ajout d'une hiérarchie personnalisée, évitez de viser à afficher les niveaux de total général dans les visualisations, car les hiérarchies personnalisées ne sont exposées qu'à partir du premier niveau. Les hiérarchies prédéfinies ne présentent pas non plus le nombre total de niveaux. Le niveau Total général ne donne que le montant total général. Utilisez-le donc uniquement lorsqu'il n'y a pas de jointure entre un fait et une dimension et que la mesure doit être définie à un niveau total.
  • Lors de la définition d'une hiérarchie, il est nécessaire de mapper tous les éléments de données disponibles à un niveau ou à des détails.
  • Avant de modifier une hiérarchie (par exemple, ajouter, supprimer ou modifier des niveaux), supprimez d'abord la hiérarchie du domaine, modifiez la hiérarchie, puis rajoutez la hiérarchie au domaine.
  • Actuellement, le cadre de bac à sable ne prend pas en charge l'ajout de hiérarchies basées sur la valeur à un domaine.

Ajout des colonnes

  • Appliquez des fonctions et des agrégations directement aux colonnes de base. Évitez d'imbriquer des colonnes dérivées pour éviter les dépendances inutiles, les frais généraux de traitement, les retards et les erreurs de calcul potentielles dans le modèle sémantique.
  • Évitez d'ajouter des colonnes qui sont déjà présentes dans le modèle sémantique existant; cela crée des jointures redondantes et augmente la surcharge de traitement.
  • Lorsque vous utilisez des faits et des dimensions personnalisés, évitez d'utiliser des colonnes dérivées. Effectuez plutôt les calculs nécessaires au sein de la couche de base de données ou définissez l'expression directement sur l'objet lors de son processus de création.

Utiliser des configurations de données personnalisées

  • Si vous utilisez une configuration de données personnalisée spécialisée telle que l'analyse de compte configurable, Fusion Accounting Hub ou l'application Supply Chain Planning, vous devez mettre en oeuvre toutes les personnalisations nécessaires exclusivement au sein de l'application. Évitez de créer des configurations en double dans le modèle sémantique, car cela introduit des dépendances redondantes et des frais généraux de traitement inutiles.

Déploiement

  • Les migrations doivent circuler dans une seule direction. Sélectionnez un environnement en tant qu'environnement de développement principal. Après les tests d'acceptation par l'utilisateur, générez et déployez un ensemble d'extensions sémantiques pour migrer les modifications vers la production et d'autres environnements.
  • Si le modèle sémantique sécurise les objets avec des rôles d'application, des groupes ou des utilisateurs nouvellement configurés, assurez-vous d'importer et de déployer l'ensemble de sécurité avant d'importer et de déployer l'ensemble de modèle sémantique.