Documentation Oracle Cloud Infrastructure

Recommandations et conseils pour étendre le 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.

Structure d'extensions de modèle sémantique

Structure de succursale

Si vous utilisez toujours la structure Semantic Model Branch, le moment est venu de migrer vers la structure Sandbox. Reportez-vous à Migration vers la structure Sandbox pour les extensions de modèle sémantique.

Environnement Sandbox

Conservez uniquement les modèles d'environnement restreint en cours d'utilisation. Supprimez les modèles d'environnement restreint que vous avez utilisés pour le test et qui ne sont plus utilisés. La gestion d'autres modèles d'environnement restreint inutilisés dégrade les performances du système.

Objets de base de données

Normes de dénomination des bases de données pour les objets Autonomous AI Lakehouse

  • Préfixez un objet personnalisé avec X_ZZZ_, où ZZZ est l'abréviation de votre organisation.
  • Suffixez différents objets comme suit :
    • _A = Agrégat
    • _D = Dimension
    • _DH = Hiérarchie des dimensions
    • _F = Fait
    • _H = Aide
    • _M = Dimension de carte
    • _MD = Mini dimension
    • _V = Vues
    • _MV = Vue matérialisée
    • _DS = Jeu de données d'augmentation de données
    • _EXT = Extension d'augmentation des 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és : 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 traitées dans votre instance Oracle Fusion Data Intelligence. Par exemple, si un champ utilisateur flexible utilisé dans un domaine personnalisé a été désactivé dans la source, vous devez remplacer ou supprimer le champ utilisateur flexible 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 immédiatement le chargement complet.

Extension

Généralités
  • 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 éviter tous les autres caractères spéciaux.
  • Lorsque vous ajoutez des attributs personnalisés ou que vous définissez des clés utilisées pour la jointure, assurez-vous que le nom d'affichage est unique et n'entre pas en conflit avec les noms de colonne prédéfinis.
Etendre la dimension
  • Important : vous devez réduire au minimum les extensions et les combiner pour éviter les surcharges inutiles et les 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 la joindre à la clé de dimension de base. S'il n'est pas possible d'effectuer une jointure sur la clé de dimension de base, vous pouvez effectuer une jointure sur une autre colonne de base avec prudence, en validant le grain et la cardinalité des données. 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 à l'application et à la publication du modèle d'environnement restreint et peut avoir un impact négatif sur les performances des requêtes.
  • Lors de l'extension des dossiers DEGEN Dimensions ("Détails"), maintenez toujours le même niveau de granularité en rejoignant la ou les clés primaires du fait avec une relation de un à un [1:1]. Ne définissez pas de jointures [N:N] à plusieurs car cela peut entraîner une dégradation des performances et la duplication des données.
  • Soyez prudent lorsque vous étendez des dimensions ayant une à plusieurs relations (1:N) (telles que la sélection multiple), car :
    • Elles peuvent entraîner une duplication des données car les données étendues présentent un grain inférieur à celui 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 court 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 affiché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 des tables d'augmentation est OAX$OAC, même si les tables d'augmentation sont également présentes dans OAX_USER.
  • La taille de colonne d'attribut étendue 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 la suppression des enregistrements sans correspondance.
    • Left Outer : Recommandé pour la plupart des extensions afin de préserver toutes les lignes de la table de base, en particulier pour les relations 1:plusieurs ou lorsque la table étendue est incomplète. Cela permet d'éviter la suppression involontaire de lignes de base.
    • Inner : Idéal pour une vraie relation 1:1 lorsque vous voulez uniquement des enregistrements qui existent dans les deux tables et que vous êtes à l'aise d'exclure les lignes sans correspondance. Non recommandé lors de l'extension des dimensions dégénérées.
    • Extérieur droit : rarement utilisé. Choisissez cette option lorsque vous devez conserver toutes les lignes de la table étendue et extraire uniquement les lignes correspondantes de la table de base.
    • Full Outer : utilisez cette option avec précaution pour conserver toutes les lignes des deux tables, quelles que soient les correspondances. N'utilisez pas Full Outer sur les dimensions dégénérées car elles peuvent introduire la duplication des données et la 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. Cependant, il est toujours nécessaire de définir une clé primaire de hiérarchie et un attribut d'affichage. Cliquez sur le dossier Eléments de données sélectionnés, puis sur l'icône de modification Propriétés pour définir la clé primaire de hiérarchie et l'attribut d'affichage.

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

  • Evitez d'ajouter des attributs de dimension non dégénérés aux tables de faits. A la place, sélectionnez l'indicateur dégénérer pour l'attribut lors de la définition de la table de faits. Les attributs de dimension non signalés dans les tables de faits auront un impact négatif 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 libres qui sont jointes au fait personnalisé.
  • Lorsque vous joignez des faits à des dimensions, assurez-vous que les colonnes jointes sont de types de données compatibles.
Créer une Hiérarchie
  • Lors de l'ajout d'une hiérarchie personnalisée, évitez de viser à afficher le total général des niveaux dans les visualisations car les hiérarchies personnalisées ne sont affichées qu'à partir du premier niveau. Les hiérarchies prédéfinies n'exposent pas non plus le total des niveaux. Le niveau Total général donne simplement le montant total général ; par conséquent, utilisez-le 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 sur un ou plusieurs niveaux.
  • 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 ajoutez-la à nouveau au domaine.
  • Actuellement, la structure de modèle d'environnement restreint ne prend pas en charge l'ajout de hiérarchies basées sur la valeur à un domaine.

Ajout de colonnes

  • Appliquer les fonctions et les agrégations directement aux colonnes de base. Evitez d'imbriquer les colonnes dérivées pour éviter les dépendances inutiles, la surcharge de traitement, les retards et les erreurs de calcul potentielles dans le modèle sémantique.
  • Evitez 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. Au lieu de cela, effectuez les calculs nécessaires dans la couche de base de données ou définissez l'expression directement sur l'objet au cours de son processus de création.

Utilisation de configurations de donnée personnalisées

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

Déploiement

  • Les migrations doivent circuler dans une seule direction. Choisissez un environnement comme environnement de développement maître. Après le test d'acceptation par les utilisateurs, générez et déployez un bundle Semantic Extensions pour migrer les modifications vers les environnements de production et autres.
  • 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 le groupe Security avant d'importer et de déployer le groupe Semantic Model.