Overblog
Suivre ce blog Administration + Créer mon blog

Rechercher

Archives

25 décembre 2007 2 25 /12 /décembre /2007 08:10

 

- Diplôme d'Ingénieur en Informatique, Option Système d'Information (parcours : Ingénierie des Systèmes Décisionnels), Mention très bien (Note : 18/20)

 

- Diplôme d'Etudes Supérieures Techniques (DEST) en Informatique (option Ingéniérie et Intégration Informatique)

 

- Diplôme Universitaire de Technologie (DUT) en Informatique (option Genie-Informatique), Mention très bien 

 

- Baccalauréat série C (Mathématiques & Sciences Physiques), Mention assez bien

 

 

Partager cet article
Repost0
6 décembre 2007 4 06 /12 /décembre /2007 11:30

Un système décisionnel est un système qui doit pouvoir faire conjuguer les données à tous les temps.

Partager cet article
Repost0
18 septembre 2007 2 18 /09 /septembre /2007 22:47

Voici donc les 12 règles de Codd  en 1993, qui sont la base même des produits OLAP. Des nouvelles règles ont été ajoutées pour compléter la définition.

 

1) La vue conceptuelle multidimensionnelle :  le cœur des produits OLAP

2) La transparence : libre accès des différentes sources par des fonctions.

3) Accessibilité : Les produits OLAP sont des médiateurs entre les différentes sources de données et  un terminal OLAP.

4) Performance de report : la performance ne doit pas être dépendante du nombre de dimension et de la taille des bases de données.

5) Architecture du client/serveur : capacité de rattacher les différentes sources avec peu de programmation.

6) Dimension générique

7) Ajustement automatique des niveaux physiques : adapter en fonction de la disparité, du volume de données et du type de modèle.

 8) Le support multi-utilisateurs :possibilités d'accès concurrent.

9) Opérations sur les dimensions

10) Manipulation des données intuitives :possibilité de faire des manipulations sur les vues (les cellules du cube).

11) Reports flexibles :modularité des dimensions dans le report.

12) Dimensions illimitées et niveau d'agrégation

Voici les nouvelles règles :

13) Extraction en lots et interprétation 

14) Modèle d'analyse OLAP

15) Traitement des données non-formalisées

16) Conserver les résultats OLAP

17) Extraction des valeurs manquantes

18) Traitement des valeurs manquantes

Différences entre MOLAP, ROLAP, HOLAP, DOLAP

Les moteurs du décisionnel, les outils OLAP (On Line Analytical Processing), complètent les DataWarehouses. Ils fournissent une vue des données stockées qui transforme celles-ci en informations stratégiques pour l'entreprise. Le stockage des informations peut être réalisé de plusieurs façons : MOLAP (Multidimensionnel OLAP), ROLAP (Relationnel OLAP), HOLAP (Hybride OLAP).

 

MOLAP (Multidimensional OLAP) :  Cette base permet de stocker les données de manière multidimensionnelle. L'intérêt est que les temps d'accès sont optimises ; cette approche nécessite de redéfinir des opérations pour manipuler ces structures multidimensionnelles. Les jointures sont déjà faites. Cette base est plus rapide et performante mais limitée pour l'instant au GigaOctet

 

ROLAP (Relational OLAP)  : Cette base est sans limite de taille et permet ainsi de gérer de plus grandes bases. Mais ceci se fait au détriment de l'accès aux informations, qui est alors plus lent car les résultats des requêtes sont calculés au moment de leur exécution. Ce système n'étant pas restrictif pour ce qui est des requêtes, on peut demander plus de détails. On peut également travailler de façon plus dynamique.

 

HOLAP (Hybrid OLAP):  Désigne les outils d'analyse multidimensionnelle qui récupèrent les données dans des bases relationnelles ou multidimensionnelles, de manière transparente pour l'utilisateur. Il présente l'avantage de mixer les avantages des deux systèmes MOLAP et ROLAP en répartissant les requêtes sur l'un ou l'autre des deux moteurs selon que l'un ou l'autre est susceptible de répondre plus rapidement à la requête (ou de façon plus précise).

 

DOLAP (Desktop OLAP): Ce terme désigne un petit produit OLAP faisant de l'analyse multidimensionnelle en local. Il peut y avoir une mini base multidimensionnelle (façon Personal Express), ou bien de l'extraction de cube (façon Business Objects Client Lourd).

 

Une nouvelle famille, le VOLAP (Vectorial OLAP), est apparue récemment. Créée par la société Sylicom et mise en œuvre dans le logiciel Microlis, V-Olap est une technologie construite sur une structure de données originale en base vectorielle inversée, qui permet de traiter, présenter, comparer, compter, comprendre, corriger, compléter, analyser et projeter toutes les données sans contrainte, ni délai (de 4 à 32 secondes pour des états complexes traitant des millions de données). Une approche novatrice en matière d’aide à la décision.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Partager cet article
Repost0
6 septembre 2007 4 06 /09 /septembre /2007 19:01
   

I    Différence entre Infocentre et DataWarehouse

L’infocentre est une collection de données orientées sujet, intégrées, volatiles, actuelles, organisées pour le support d’un processus de décision ponctuel.

 

Le DataWarehouse est une collection de données orientées sujet, intégrées, non volatiles, historisées, organisées pour le support d’un processus d’aide à la décision.

 

Ou plus généralement on qualifie d’infocentre une solution décisionnelle dont le modèle de données est très proche d’un modèle de données d’un système opérationnel.

 

 

L’infocentre est un outil alors que le Data Warehouse est une architecture.

 

 

 

II  Architecture d’un Système décisionnel

Une prise de décision intègre généralement  quatre modèles  :


1-
  Un modèle de données : C’est le DataWarehouse; 


2-
Un modèle de connaissance : Ce sont les faits et les règles. Ici c’est le domaine du DataMining (Réseaux de neuronnes, Algorithmes génétiques, Systèmes expert, …);  


3-
Un modèle mathématique : C’est le domaine de la modélisation (recherche opérationnelle, programmation linéaire, ..). La variable solution peut être mono critère (C’est–à-dire que l’on recherche une solution optimale) ou multi critère (c’est-à-dire que l’on recherche une solution acceptable). Par définition dans le dernier cas il existe plusieurs solutions;


4-
Un modèle de décision : Empirique ? Dépend de l’expérience du décideur


Une architecture minimale contient au moins le modèle de données

Ci-après un schéma résumant l’architecture

 

 

 

 

 

 

 

 

Cliquez ici pour télécharger le schéma d'architecture au format pdf

Partager cet article
Repost0
15 mai 2007 2 15 /05 /mai /2007 09:28

Pour garantir la réussite d’un projet de construction d’un Système d’Information Décisionnel, une répartition claire des rôles et des responsabilités doit être définie entre les différents acteurs humains du système. Dans cette partie, je propose une liste de rôles et de responsabilités.

 

J'ai identifié les rôles et responsabilités suivants :

 

 

1-      Le commanditaire (en incluant l’utilisateur final)

2-      L’expert métier

3-      Le comité de pilotage

4-      Le chef de projet

5-      L’architecte

6-      Le concepteur

7-      Le développeur ETL

8-      développeur OLAP

9-      L’administrateur système

10-   L’administrateur des Bases de données

 

 

 

Le Commanditaire

 « C’est la personne physique ou, le plus souvent, la personne morale qui sera le propriétaire de l’ouvrage. Il est finalement responsable après le transfert de propriété ; il assure le paiement des dépenses liées à la réalisation. ». Compte tenu du caractère stratégique et transversal des systèmes D’information Décisionnel, le commanditaire est généralement la direction générale.

 

 

L’expert Métier

En général, l'expert métier est un senior de l'entreprise qui est rompu à la culture, au vécu et au langage maison. Il a multiplié les expériences et les projets dans son domaine de compétence, et connaît les pièges à éviter.  

 

Le Comité de Pilotage

Le comité de pilotage est un groupe de personnes chargées de veillez au bon fonctionnement du projet .Les responsabilités du comité de pilotage incluent donc entre autres :

-  L’arbitrage des réalisations prioritaires au regard des contraintes budgétaires et des orientations stratégiques de l’entreprise 

 

-  Le suivi des relations avec le commanditaire et replace le projet dans le contexte plus large comprenant les enjeux stratégiques du commanditaire 

 

- Suivi régulier de l’avancement du projet

 

L’architecte

L’architecture est le penseur   Il est avant tout positionné sur le conseil en infrastructure décisionnelles.  Ses responsabilités couvrent :

-  Conseil en Architecture

-  Choix des outils et des architectures autour de ces outils

-  Analyse des performances

 

Le concepteur

Ses responsabilités couvrent :

 

-  La modélisation logique des données du système

-  Recensement des besoins en données

-  Participation aux décisions du comité de pilotage

 

Développeur ETL

Elément « invisible » des utilisateurs finaux, l’outil  ETL est sous la « responsabilité » du développeur ETL. Plus généralement dans le cadre d’un projet Système d’information décisionnel les responsabilités d’un développeur ETL entre autres : 

 - L’extraction des données dans les systèmes sources

 - L’application des règles métier de transformation

 - Le développement, les tests et la maintenance des programmes d’extraction et des programmes d’alimentation.  

 - Le référentiel de méta données contient les méta données techniques par exemple les sources de données et les règles de transformation appliquées. Le Développeur ETL est responsable du peuplement de ce référentiel et de sa cohérence. 

 

Développeur OLAP

Par développeur, nous entendons la personne et l’équipe en charge du développement et la maintenance des applications OLAP. Dans une moindre mesure, nous incluons dans cette partie les outils de reporting.  

Dans le cadre d’un projet Système d’information décisionnel les responsabilités d’un développeur OLAP couvrent entre autres :

 - Implémentation des vues métiers dans les outils OLAP

 - Développement des rapports à la demande des utilisateurs

 - Le déploiement, ma maintenance et le support des utilisateurs des solutions OLAP

 - Vérifier en partenariat avec l’administrateur système, de la disponibilité des données et optimisation des performances d’accès aux données 

 

L’administrateur Système

Les responsabilités de l’administrateur système dans le cadre d’un projet Système d’information décisionnel couvrent entre autres :

 - En collaboration avec l’Administrateur des Bases de Données, il assure l’installation et la maintenance du Système de Gestion de Base de données (SGBD)

- Garantie la disponibilité des ressources systèmes pour le Système de Gestion de Base de données

- Le monitoring des périphériques de stockage à accès direct

- Participe aux réunions (choix, discussions, …) sur l’architecture technique   

 

L’Administrateur de Bases de Données (DBA)

L’administrateur des Bases de données est un acteur très important dans un projet Système d’Information décisionnel.  Ses responsabilités couvrent entre autres :

- La conception physique des bases de données

- La maintenance des bases de données

- La gestion de la sauvegarde et la restauration de données

- Participation aux décisions du comité de pilotage

Partager cet article
Repost0
25 avril 2007 3 25 /04 /avril /2007 13:59

Dans cet article, je présente les deux scénarii de déploiement d'une solution décisionnelle. Bien entendu ces scénarii n'engagent que moi.

Axiomes :

- « On n’achète pas un DataWareHouse, on le construit » : Bill Inmon. 

- Un DataWareHouse, un vrai, se justifie par la satisfaction d’un besoin horizontal.

 

 

 

 

 

I- Scénario 1 : DataWareHouse « Global »

 

 

 

 

 

 

 

 

Ici le DataWareHouse (rigoureusement la zone de données principales) contiendra potentiellement tous les lots (« verticaux » et « horizontaux ») 

 

I-1       Avantages

-          Centralisation des données

-          Possibilité de brancher un programme de DataMining (le volume et la centralisation des données peuvent justifier ce branchement) afin de détecter des corrélations cachées entre les données 

 

I-2       Limites et contraintes 

 

- Le DataWareHouse peut rapidement devenir inconsistant. En effet, il ne suffit pas d’aligner des lots « verticaux » les uns à côtés des autres pour obtenir un lot « horizontal » cohérent;

 

- Risque de collision entre les objets « horizontaux » et « verticaux » si la frontière n’est pas clairement définie;

 

- Difficultés liée à la maintenance et à l’administration. En effet étant donné que plusieurs domaines fonctionnels et que les deux visions « verticale » et « horizontale » cohabitent, une maintenance et une administration efficaces nécessiterons une bonne compréhension de plusieurs domaines fonctionnels et de plusieurs visions. Ce qui énorme en terme de charge; 

 

- Besoin important en ressources machines (disques, RAM , CPU, …). En effet dans un DataWareHouse « global », le volume de données est de l’ordre du téra octet ----à Nécessité de mettre en place de véritables architectures de bases de données dédiées décisionnelle (Teradata , Netezza, …)

 

 

 

I-3       Remarques :

Ce déploiement peut convenir :

-          Aux organisations qui n’ont pas beaucoup d’applications verticales  

-          Aux organisations qui ont un ERP qui couvre l’essentiel des domaines fonctionnels

-        Aux organisations dont les besoins en indicateurs et métriques ne font pas intervenir plusieurs domaines fonctionnels

II- Scénario 2 : DataWareHouse « Horizontal » et DataMarts « verticaux »   

 

 

 

 

 

 

 

 

 

Ici le DataWareHouse (rigoureusement la zone de données principales) contiendra uniquement des lots susceptibles d’intervenir dans la satisfaction d’une problématique ou d’un besoin « horizontal ». Les besoins « verticaux » étant alors comblés par des DataMarts dédiées 

 

II-1     Avantages

-          Architecture distribuée

-          Possibilités de brancher un programme de DataMining (le volume et la centralisation des données peuvent justifier ce branchement) afin de détecter des corrélations cachées entre les données

II-2     Limites et contraintes  

- Suivi de la cohérence

- Possibilité d’organiser les données décisionnelles par groupe fonctionnel (peut aussi être vu comme un avantage).

- Nécessité de mettre en place une véritable architecture de bases de données dédiées décisionnelle (Teradata , Netezza, …) en cas de grosse volumétrie

II-3     Remarques :

Ce déploiement peut convenir :

-          Aux organisations qui ont beaucoup d’applications verticales

-          Aux organisations qui n’ont pas un ERP qui couvre l’essentiel des domaines fonctionnels

Tout ou Partie de cet article ne peut reproduit sans autorisation écrite de M. Benjamin EPEE

Partager cet article
Repost0
10 avril 2007 2 10 /04 /avril /2007 10:02

I-  But de cet article

Le but de cet article est de présenter l'utilisation du diagramme de pareto avec l'outil BI "SAP BO Web Intelligence XI" 

 

 

II- Qu'est-ce que le diagramme de pareto 

Le diagramme de Pareto est un moyen simple pour classer les phénomènes par ordre d’importance. Ce diagramme et son utilisation sont aussi connus sous le nom de « règle des 80/20 » ou méthode ABC.

 

Les objectifs sont (entre autres) :

 - Faire apparaitre les causes essentielles d’un phénomène ;

 - Hiérarchiser les causes d’un problème

 - Evaluer les effets d’une solution

-  Mieux cibler les actions à mettre en œuvre

 

 

III- Méthodologie

 

La méthodologie ici est très simple. Elle se résume en cinq étapes :

-       Etablir un tableau des données

-       Classer le tableau par ordre décroissant des quantités

-       Faire la somme cumulative des quantités dans le même ordre

-       Calculer les pourcentages

-       Dessiner proprement dit du diagramme

 

Environnement technique

  -  SAP BusinessObjects Enterprise XI 2 (SP 5)

 

 

Allons-y !

 

III-1   Etablissement des données

Le tableau ci-après présente le nombre de jours ouvrés (J.O) perdu par origine d’accident de travail.

 

ImgPareto-DataBase-copie-1.JPG

 

 

III-2    Classement du tableau par ordre décroissant des quantités

Dans cette étape, le travail consiste essentiellement à trier le tableau précédent par ordre décroissant des Jours ouvrés perdus.

On obtiens alors le tableau suivant :

 

ImgPareto-DataBaseTriees

 

 

III-3    Somme cumulative des quantités dans le même ordre

Ici  on effectue la somme cumulative de la colonne "J.O. perdus" à l'aide de la fonction WebBI suivante "SommeCumulative".

A la suite de cette opération, nous obtenons le nouveau tableau suivant. La nouvelle "CUMUL" contient alors la somme cumulative de la colonne "J.O. perdus" .

 

ImgPareto-SumCumu 

 

 

III-4    Calcul des pourcentages (à partir des quantités cumulatives)

Ici  on calcul le "pourcentage cumulatif". C'est-à-dire à partir de la colonne "CUMUL". Il n'existe pas une formule dans WebBI XI R2 qui permet de calculer le "pourcentage cumulatif". Il fallait donc la créée !  Et la voici :

 

SommeCumulative ([J.O. perdus]) / Max(SommeCumulative ([J.O. perdus]) PourTout [Origine])

  

Après application de la formule,  nous obtenons le tableau ci-après. Dans ce tableau, la nouvelle colonne "%CUMUL" contient le "pourcentage cumulatif" .

 

ImgPareto-PPourcentageSumCumu 

 

 

III-5     Dessin propement dit du diagramme

 

C’est la dernière étape. Ici nous n’avons plus besoins de la colonne « CUMUL ». Ainsi le tableau qui servira de base au diagramme est le suivant :

 

ImgPareto-DataGraph

 

Il ne nous reste plus qu'à transformer ce tableau en graphe. On obtient alors le diagramme suivant :

 

ImgPareto-LeDiagramme

 

Interprétations

 

- 80% (4/5) des origines sont responsables de 90 % de jours ouvrés perdus.

- 60% (3/5) des origines sont responsables de 77,83 % de jours ouvrés perdus.

 

 

- 40% (2/5) des origines sont responsables de 60,03 % de jours ouvrés perdus.

- 20% (1/5) des origines sont responsables de 40,53 % de jours ouvrés perdus.

Partager cet article
Repost0
24 décembre 2006 7 24 /12 /décembre /2006 09:22

Ci-après un tableau comparatif des diiférents "OLAP".

Propriétés

ROLAP

MOLAP

HOLAP

VOLAP

10 à 100 fois plus performant qu'un SGBDR standard

Non

Oui

Oui*

Oui

Nombre d'axes illimités

Oui

Non

Oui**

Oui

Préparation et installation complète en moins d'un jour

Non

Non

Non

Oui

Chargement en quelques minutes

Non

Non

Non

Oui

Apprentissage complet en deux jours

Non

Non

Non

Oui

Aucune préparation d'indicateurs, d'agrégats, d'index ...

Non

Non

Non

Oui

Accessibilité et usage simple de ce qui est préparé

Oui

Oui

Oui

Oui

Accessibilité et usage simple de tout ce qui est imprévu

Non

Non

Non

Oui

Calculs complexes sur les données

Non

Non

Non

Oui

Simulations et modélisations simples et rapides

Non

Non

Non

Oui

 

 

* oui pour la partie MOLAP dont le chargement reste très long
** oui mais les axes restés ROLAP restent très lents 

 

Partager cet article
Repost0
4 novembre 2006 6 04 /11 /novembre /2006 07:34

 

I   Quelques définitions

 

  Ci-après quelques définitions pour comprendre la logique en Intelligence Artificielle

  Clause : Expression logique de la forme : CONCLUSIONS SI CONDITIONS

Clause de HORN : Clause qui accepte au plus une conclusion

Cohérent : Une base de connaissance est dite cohérente si elle est sans contradiction, c'est-à-dire qu'elle ne contient pas à la fois une assertion comme A et, simultanément, une assertion comme non A. ne pas confondre avec une base de connaissance correcte, qui en plus de cohérente, est sans incomplétude ni redondance.

Déduction : Forme de raisonnement qui conclut, à partir  d'hypothèses, à la vérité d'une proposition en usant de règles d'inférence qui préservent la vérité des expressions manipulées. Exemple de règles de déduction : Modus ponens, Modus Tollens, Suppressions des doubles négations, ...

Différence Base de données et Base de connaissance : Dans une base de données, Il est généralement sous entendu que la qualité de règles est faible par rapport à la qualité de données, alors que c'est l'inverse pour une base de connaissance. Il arrive que dans une base de données l'on appelle faits : partie en extension de la base, et les règles : partie en intention de la base.

Faits : Synonymes de données. Techniquement : clause instanciée et sans conditions. Synonyme=Assertion ?

Induction : Forme de raisonnement qui part des faits pour aller vers les théories, alors que la déduction part des théories pour aller vers les faits.

Inférence : Raisonnement consistant à tirer des conclusions à partir de la base de connaissances. Enchaînement de la connaissance permettant d?en déduire de nouvelles à partir de celles qui sont déjà acquises.

Modus Ponens : Si A est vrai et (A=>B) est vrai (expression de causalité) alors B est vrai. Pour être plus formel : (A et A=>B) inférer B). Exemple :  1-  HOMME(x)     2-  HOMME(x)=> MORTEL(x). En faisant  [x <--- epee), on en déduit que epee est mortel.

Modus Tollens : Règle d'inférence déduite de Modus ponens en remplaçant les formules par des négations pures. Elle s'écrit donc : de Non A et de Non B =>inférer Non B.

Prédicat : Fonction qui ne peut prendre que deux valeurs. (En logique classique, ces valeurs sont interprétées comme le vrai ou le faux. En logique multivaluée, on a introduit aussi d?autres valeurs comme "INCONNU", "INDIFFERENT", ...

Subsomption : Opération par laquelle on reconnaît qu'un prédicat est plus général qu'un autre. Le prédicat le plus général subsume le moins général. Classiquement la seule opération de subsomption est le OU logique : on dit, par exemple, que "A OU B" subsume "A"

II   Les formes de logique

Sources : Compilation Cours Ingénierie des Systèmes Décisionnels, CNAM Paris, 2004-2005

 

III    Les modes de raisonnement  

 

 

 

 

III-1      Raisonnement direct

             III-1-1  La déduction

                         1- Le syllogisme

                         2- Le conditionnel 

                         3- Le disjonctif

           III-1-2  L’induction

           III-1-3  L’analogie

 

 

 

 

III-2     La réfutation

   III-2-1   Invalidation par le contre exemple

   III-2-2   S’attaquer à la thèse (cercle vicieux : on veut prouver une hypothèse en supposant qu’elle est vraie !!!!)

    III-2-3   Il n’y a pas que les conclusions défendues, il y en a d’autres qui n’induisent pas la thèse

 

III-3  Raisonnement indirect ou raisonnement par l’absurde

 - Pour démontrer q'une proposition est vraie, on commence par supposer son contraire et on aboutit ensuite à une absurdité qui amène à conclure que la proposition est fausse. Par exemple démontrons par l’absurde que N l’ensemble des entiers naturels est infini.  

1- On commence par supposer que N est fini.

2- Si N est fini alors il admet un plus grand élément que nous appellerons P

3- Hors nous avons une propriété qui nous dit que si a appartient à N alors a+1 appartient aussi à N

4- Ainsi d’après le point précédent, P+1 appartient aussi à N. Ce qui est absurde puisque P est le plus grand élément de N

5- Donc N n’est pas fini, c’est-à-dire qu’il est infini. CQFD. 

 

                                                           

 

 

 

 

 

 

 

 

 

 

 
Partager cet article
Repost0
3 novembre 2006 5 03 /11 /novembre /2006 14:23

- Il faut minimiser la fragmention de l’espace (Voir règles OFA), c’est-à-dire qu’il ne faut pas faire cohabiter des objets qui ont des mouvements différents (par exemple regrouper les segments temporaires et les segments de données)

 

 -Il est plus intéressant de DROP puis CREATE un index que de REBUILD. La vue index_stats permets de faire du monitoring sur les index.

 

 - Lorsqu’on se connecte avec les privilèges sysdba ou sysoper, on est connecté par défaut sur le schéma par défaut qui le schéma de sys, et non sur le schéma personnel !. Par exemple:

 

 

 

 1- connect test/test as sysdba

 

 2- create table testons (lechamps char(3))

 

 3- disconnect

 

 4- connect test/test

 

 5- Select * from testons. (Le système va nous renvoyer une erreur: la table testons n’existe pas !)

 

 

Par contre la table testons se trouve bel et bien dans le schéma sys. (Select * from sys.testons sera ok)

 

 

- La commande startup sans paramètres ouvre la base la base de données (donc nomount, mount, …)

 

- L’allocation de ressources est consommatrice de ressource. Ainsi il faut éviter à Oracle de faire trop d’allocation.

 

L’unité de lecture est le bloc. Ainsi si une ligne est stockée dans n blocs, le DBWR effectuera n lectures pour ramener la ligne dans le Data buffer cache

 

- Une table crée avec l’option TEMPORARY (version >=8i) aura alors une visibilité locale au schéma  (couplé avec [ON COMMIT {DELETE|PRESERVE} ROWS]. En fait l’un des objectifs, je pense est d’arriver à faire des « DELETER » seulement ce qu’on a « INSERTER » !

 

- Lors de l’utilisation de ORADIM (utilitaire Oracle sous Windows qui permet de créer le service Windows associée à l’instance de base de données Oracle), il n’est pas intelligent d’utiliser l’option

 

 

–STARTMODE. En effet par cette option, Oracle crée un fichier de commande qui contiendra les informations pour mettre la base de données en écoute. Malheureusement ces informations sont en dur et en clair dans le fichier, particulièrement le mot de passe de Internal et pourrait donc être lu par un utilisateur illégitime.

Partager cet article
Repost0