ORACLE est une société internationale qui développe et vend des solutions informatiques professionnelles. Historiquement centrée sur un produit unique LE système de gestion de bases de données éponyme, qui malgré une très grande diversification d’offre reste son produit phare.
LARRY ELLISON
Chief Executive Officer
Oracle Corporation
Larry Ellison est CEO d’ Oracle Corporation depuis sa fondation en 1977.
Il est également le Skipper du voilier Oracle/BMW à l’AMerica’s Cup.
Quelques dates :
1977 : Software Development Laboratories, le précurseur d’Oracle, est fondé par Larry Ellison, Bob Miner, et Ed Oates.
1978 : Oracle Version 1, écrit en assembleur, tourne sur PDP-11 de DEC dans 128K de mémoire
1979 : Oracle Version 2, 1ere version commerciale de SQL relational database management system, is released. La société devient Relational Software Inc. (RSI).
2003 : débuts le la 10g
2007 : débuts de la 11g
Quelques chiffres
Oracle no 2 (ou 3 parfois si IBM) mondial du logiciel derrière un certain ‘Microsoft’…
no 1 des fournisseurs de SGBDR
+ de 100 000 employés dans le monde
Un aperçu de la page d’accueil du site de l’entreprise, donne une idée de la richesse (complexité?) de l’offre logicielle actuelle d’Oracle Corp.
ORACLE n’est plus un vendeur de BDs mais…fournit des solutions informatiques. De manière non exhaustive, et regroupés par type on trouve :
les bases de données
Oracle DB 11g la dernière release en production DU SGBD
Berkeley DB , la BD orientée traitements embarqués
Oracle Rdb, un SGBDR anciennement de Digital Equipment Corporation (DEC) qui tourne sur OpenVMS
TimesTen, BD temps réel fonctionnant en mémoire centrale
Oracle Essbase, qui continue la tradition de Hyperion Essbase SGBD multi-dimensionel
MySQL, LE SGBDR open-source (sous licence GNU General Public License) , initialemnt développée par MySQL AB, et présente derrière des millions de sites Internet
Une Base de données (BD) est un ensemble structurés de données cohérentes.
Un SGBD est un système complexe permettant de gérer de manière efficace, un volume important de données structurées, accessible par des utilisateurs simultanés locaux ou non.
BD = ensemble de données structurées accessibles simultanément à n utilisateurs
Un SGBDR (ou RDBMS en Anglais) est un SGBD basé sur le modèle relationnel.
Une relation est un sous-ensemble de données caractérisé par des attributs et visualisable sous forme de table.
Le modèle relationnel est simple, très bien formalisé et épprouvé c’est ce qui a fait son succès.
Par rapport aux modèles précédents il apporte beaucoup de souplesse dans la mesure ou les tables ne sont pas fortement (voire pas du tout) liées entre elles.
exemple de modèle relationnel rudimentaire à 3 tables
Bien que cela ne soit pas vraiment formalisé, envisageons d’un point de vue pragmatique quelles doivent être les caractéristiques d’un ‘vrai’ SGBD par opposition à des systèmes de gestion de fichiers plus ou moins évolués comme Paradox, Omnis, fileMaker, Access…
Caractéristique d’un vrai SGBD
Un SGBDR digne de ce nom doit disposer d’un certain nombre de caractéristiques minimales :
gestion de gros volumes de données (en consultation et en mise à jour),
Sécurité des données, qui se décline en :
disponibilité
Un SGBDR se doit d’offrir une bonne disponibilité des données. Une disponibilité totale des données est possible (temps de reprise nul) il suffit de s’en donner les moyens logiciels et matériels…
fiabilité
Des mécanismes de sauvegarde variés (physique, logique, off-line, on-line, totale, partielle, incrémentale), ainsi que des mécanismes de journalisation, et de reprise permettent de restaurer une information sans pratiquement aucune perte, dans tous les cas de problème matériel ou logiciel.
confidentialité
Tout n’est pas accessible à tout le monde! Se connecter à la base de données, donne un certain nombre de droits et de ressources en fonction d’un profil défini et maintenu par un administrateur. La granularité d’accès peut aller jusqu’à la vision unique d’un champ d’un enregistrement d’une table particulière. Encore une fois on ne manipule plus des fichiers…
cohérence
Que les données soient réparties ou non –dans ce dernier cas les mécanismes mis en jeux seront plus complexes– elles doivent être cohérentes. Cela sous entend, d’une part que les accès concurrents d’utilisateurs, notamment lors de mises à jour, ne doivent pas compromettre l’intégrité des données et d’autre part que ces dernières satisfassent aux contraintes d’intégrité du modèle, mais aussi aux règles de gestion de l’entreprise.
tracabilité
On peut, notamment en cas de problème important ou en cas d’attaque du système, recourir à l’analyse de traces ou de logs du SGBD. Le niveau de détail de ces traces est paramétrable, et concerne soit les aspects système, soit réseau, soit l’accès aux données élémentaires elles-mêmes.
concurrence d’accès en lecture et écriture (avec une bonne granularité),
gestion (efficace) des transactions,
portabilité sur différents OS, des données et du code
administrabilité :
existence d’outils d’administration généraux : gestion des données, des utilisateurs, des fichiers physiques, des espaces logiques, des droits, des profils, des ressources systèmes, etc.
- existence d’outils de surveillance
en temps réel grâce à un moniteur, si possible graphique ou en temps différé grâce à des journaux ou à des traces paramétrables
- possibilité d’export import :
de, ou vers des fichiers “texte”, des logiciels bureautiques ou des fichiers gros systèmes par exemple
- optimisation de performances :
offrir de bonnes performances et des outils permettant de les mesurer et de les contrôler via des paramètres de configuration. Des processus d’optimisation en temps réel des requêtes complexes sont également souvent présents. Les données peuvent être indexées, de manière souple, dynamique et complète (index simples, concaténés, multiples, tables de hashage, recherche textuelle, etc.). Un nombre important d’utilisateurs, ainsi qu’un volume conséquent de données peuvent être pris en compte.
Zoom sur le modèle relationnel
Historiquement, différents types de modélisation des données se sont succédés :
modèle hiérarchique : les données sont organisées sous formes d’arbres
modèle réseau : les données sont organisées sous formes de réseau ou de graphe
modèle objet : les données sont stockés sous formes d’objets, encapsulant à la fois structures et méthodes opérant sur ces structures
Les premiers modèles sont désormais obsolètes et fonctionnaient principalemnt sur ordinateur central (mainframes). Le modèle objet n’est guère sorti des laboratoires…Ce qui a fait le succès du modèle relationnel, c’est sa simplicité et sa souplesse (liens assez laches entre les données, autorisant facilement les refontes)
Paradoxalement le nom de ‘relation‘ ne veut pas dire que les données ont des relations entre elles, mais désigne la forme de base du modèle lui-même.
La relation est une entité formelle, qui représente une partie du monde réel, ou plus concrètement une partie des données cohérentes que l’on va intégrer dans le Système d’Informations de l’entreprise.
La RELATION a un nom, est décrite par le nombre et le nom de ses attributs et les domaines de valeurs de chacun d’entre eux. Elle se traduit simplement, dans une deuxième étape (lorsque l’on passe du modèle conceptuel au modèle logique, plus proche de la réalité) sous forme de table, avec des lignes (ou tuples) et des colonnes : objet ô combien familier du développeur informatique…
passage de la relation à la table
Les principales caractéristiques du relationnel sont les suivantes :
modèle sous jacent simple, bien formalisé et éprouvé,
accès simple via un langage de requêtes SQL
SQL normalisé : Comme dans toute norme, elle est enrichie par les différents fournisseurs de logiciels. Mais si l’on se contraint à écrire des procédures respectant la norme ISO/ANSI 92 par exemple, on est quasiment garanti de pouvoir porter ce code sur Oracle, Informix ou Sybase…
opérateur de projection (ou sélection), restriction, produit cartésien, union, différence,
indépendance entre stockage physique et vision logique des données :
Les données (le plus souvent des tables) sont référencées de manière logique. Un dictionnaire de données permet de retrouver la correspondance avec l’objet physique désiré. Ceci est bien sûr très utile dans les environnements ouverts, et offre une grande souplesse aussi bien lors du développement, que lors de la mise en production ou dans la phase de maintenance des applicatifs. La conséquence est que l’on pourra déplacer physiquement des données, par exemple les changer de serveur, renommer ou retailler un fichier sans pour autant retoucher le code des applications. Il n’y a pas de correspondance bijective entre un fichier et une table.
existence de contraintes d’intégrité
- intégrité de domaines (contrôle du type de la donnée)
- intégrité de relation (existence d’une clé primaire : unique et toujours définie (non nulle))
- intégrité de référence (contrôle de la cohérence d’attributs de tables différentes lors des mises à jour
L’avenir du relationnel
…est au NOSQL et aux BDs orientées colonnes.
Ce nouveau modèle, comme son nom l’indique ne s’appuie pas sur le langage de requêtes SQL et sérialise les données horizontalement en regroupnat les valeurs de colonnes entre elles. Il offre en général de très bonnes performances.
Gage de son efficacité il a été adopté par des acteurs anecdotiques de l’Internet comme : Google (BigTable), Amazon (Dynamo), LinkedIn (Project Voldemort), Facebook (Cassandra Project puis HBase), SourceForge.net (MongoDB), Ubuntu One (CouchDB), etc.
Pour les Internautes pressés d’arriver à un résultat nous allons relever ici un défi, (grace aux compétences et aux qualités pédagogiques de Stephane Faroult, consultant International sur les technologies Oracle) :
Présenter l’architecture d’Oracle à des débutants, en vidéo , en Français et en moins de 10 minutes !
Les tutoriels (un peu obsoletes mais je suis nostalgique…et puis il y a une photo de mon chien) sur Oracle et le web de Didier Deleglise http://didier.deleglise.free.fr/