Fermer

novembre 21, 2018

OBIEE Meilleures pratiques de conception et de développement


Ce document est destiné aux développeurs et concepteurs OBIEE (Oracle Business Intelligence Enterprise Edition). Ces directives standard peuvent varier d’un projet à l’autre. Les normes OBIEE mentionnées ci-dessous sont davantage présentées sous une forme générique et les développeurs peuvent suivre ces instructions pour normaliser leur code et minimiser les défauts post-développement.

Référentiel – Meilleures pratiques en matière de couche physique

  • Meilleures pratiques spécifiques aux bases de données
  1. Convention de dénomination correcte des objets de base de données et des pools de connexions
  2. Le nombre optimal de pools de connexions doit être utilisé.
  3. Activez l'option de pool de connexions avec le paramètre approprié. détails relatifs au délai d'attente.

  • Des groupes de connexions distincts doivent être utilisés pour améliorer les performances des blocs d'initialisation.
  • Les clés appropriées et les conditions de jonction doivent être définies dans la couche physique.
  • Les clés étrangères ne doivent PAS être importées de la base de données.
  • Les conditions de jointure nombre à nombre fonctionnent plus rapidement que les jointures Varchar à Varchar.
  • Pour toute table de la couche physique de OBIEE RPD, définissez correctement le temps de persistance du cache pour de meilleures performances. Capture d'écran donnée ci-dessous. Cela dépend de l'heure d'actualisation de la table dans la base de données.

  • Pour une jointure automatique, créez des tables Alias ​​dans la couche physique et renommez le nom de la table correctement. Comme W_DAY_D devient W_DAY_D_transaction_date et W_DAY_D_order_date.
  • Réduisez au minimum l'utilisation des vues opaques dans la couche physique. Les tables ou les vues matérialisées dans la base de données amélioreront les performances.
  • Les mêmes tables ne doivent être importées qu'une seule fois dans la couche physique. Créez plusieurs alias pour utiliser la même table à des fins différentes.
  • La jointure factuelle n'est pas conseillée
  • Les jointures circulaires ne doivent pas être utilisées avec des tables d'alias.
  • Après avoir créé le modèle physique, la connectivité à la base de données doit être vérifié et confirmé avec l'option de mise à jour du nombre de lignes.

Méthodes conseillées pour la couche BMM de référentiel

  • Renommez les colonnes de la couche BMM en supprimant _ (sous les scores), utilisez également la convention de dénomination Init-Caps pour les colonnes et noms de table. La colonne CUSTOMER_ID devient alors l'ID client.
  • Évitez les colonnes dimensionnelles dans les tables de faits logiques et la colonne Mesurer dans les tables de dimensions. Donc, divisez une table en une dimension logique et un fait logique si nécessaire.
  • Tous les attributs qui décrivent une entité doivent être combinés en une seule table logique avec plusieurs sources de table logique.
  • Les formes abrégées et les symboles spécifiques utilisés doivent être en CAPS dans la colonne et dans le nom de la table logique (comme FTE ou RAM ou ORG).
  • Les jointures complexes doivent être utilisées dans la couche BMM afin que le serveur BI puisse prendre la meilleure décision concernant le code SQL physique à générer.
  • L'onglet Contenu de chacun des LTS en fait doit être défini sur le niveau logique de la dimension correspondante.

  • Vous pouvez utiliser l'onglet Contenu de la clause where pour limiter le nombre d'enregistrements renvoyés.

  • Mappages de colonne appropriés des colonnes logiques La table physique doit être créée dans l’onglet Correspondance de colonne LTS. Une colonne logique DOIT être mappée sur au moins une colonne physique ou une expression de formule.

  • Lors de la création d'une colonne logique dans le générateur d'expression de couche BMM, vous devez vous assurer que toutes les colonnes doivent provenir de la même table logique ou de la même logique. les tables DOIVENT être directement liées les unes aux autres.
  • Il est recommandé de créer des hiérarchies de dimensions pour chaque dimension du modèle de gestion, même si elle n'est utilisée nulle part. Les clés doivent être définies à chaque niveau de la hiérarchie.
  • «Nombre d'éléments à ce niveau» Les critères doivent être définis correctement à chaque niveau de la hiérarchie dimensionnelle. Cette valeur devrait augmenter de 1 au total général aux niveaux suivants.

Méthodes conseillées pour référentiel – Couche de présentation

  • Il est recommandé de ne pas utiliser les sous-dossiers Parent et Sous-dossiers.
  • Les colonnes de présentation ne devraient pas avoir. le même nom que les tables de présentation.
  • Pour transmettre des informations sur les objets de la couche de présentation, renseignez la description de l'objet ci-dessous de sorte que chaque fois que la souris passe la souris dans les réponses, il obtiendra des informations sur l'objet.

  • Les nouvelles tables importées n'apportent pas dans la couche de présentation des colonnes qui ne sont pas requises. Clés, date de chargement ETL, date de mise à jour, date d'insertion, etc.
  • Le regroupement logique des colonnes dans le tableau Couche de présentation est important, car nous devons toujours placer les colonnes d'indicateur dans la table des faits du dossier Catalogue de présentation.
  • Alphabétique la réorganisation doit être effectuée sur les colonnes de la couche de présentation présentes dans un seul tableau. Pour ce faire, cliquez sur les sections Nom dans la section Colonnes du tableau de présentation.

Conception du rapport OBIEE

  • La section Invite doit être placée en haut de la page, groupée par fonction ou par dimension.
  • Code de couleur et de style cohérent doit être maintenu tout au long du rapport.
  • Dans les réponses OBIEE lors de la création du rapport, créez et définissez la vue Pas de résultats. A titre d'exemple, la définition mentionnée ci-dessous peut être utilisée:

Il n'y a pas de données pour les critères sélectionnés. Veuillez modifier vos paramètres et réessayer.

  • Le bouton d'effacement des données d'invite de rapport doit être présent dans le rapport.
  • Il est judicieux que Rapport contienne le titre en tant que nom du rapport ainsi que l'heure et la date d'exécution du rapport, définissez l'heure de début dans la section titre. comme date et heure d'affichage.
  • Le rapport nouvellement créé, présent dans le tableau de bord, doit indiquer les liens du rapport comme étant actualisés, téléchargés et pouvant être téléchargés facilement (PDF).

  • Tout en insérant un lien dans le tableau de bord existant, il est recommandé de la cible définie en tant que nouvelle fenêtre en tant que rapport peut s'ouvrir dans une nouvelle fenêtre après avoir cliqué sur le lien.

  • Dans le rapport, l'utilisation de filtres avec certaines valeurs par défaut évitera une réponse élevée lors de l'exécution du rapport à partir de Dashboard pour la première fois.




Source link