SQL Server 2000 : Le modèle OIM
Un groupe d'éditeurs et d'entreprises utilisatrices a formalisé les types de métadonnées
pour les entrepôts de données. C'est devenu l'OIM (Open Information Model)
Avant les efforts de normalisation de Microsoft, les éditeurs et la communauté
informatique ne parvenaient guère à se mettre d'accord sur le type de métadonnées
qu'un entrepôt de données devait contenir.
Par la suite, Microsoft a entrepris de réunir les principaux éditeurs et les entreprises
utilisatrices pour déterminer ces types de métadonnées. A l'instar du modèle objet
pour une application, le modèle d'information pour un référentiel définit le genre
de métadonnées stockées dans l'entrepôt de données, et la manière dont ces données
sont organisées.
Ces efforts ont conduit à la définition de l'OIM (Open Information Model). Celui-ci
contient les définitions d'approximativement 300 types d'objets et des relations
entre ces types d'objets. La documentation de ces types représente une tâche laborieuse
; le groupe a pour mission de définir et de documenter clairement chaque type
ainsi que ses caractéristiques et relations nécessaires.
Etant donné que le modèle d'information définit les métadonnées en termes de types
d'objets et de relations, la recherche d'une technologie de modélisation d'objets
appropriée est la solution évidente. Le groupe a choisi UML (Unified Modeling
Language) pour documenter et publier le modèle d'information. Le standard OIM
constitue le langage commun pour décrire les informations contenues dans un entrepôt
de données.
En juillet 1999, Microsoft a transféré la propriété du standard OIM à la MDC (Meta
Data Coalition), un organisme indépendant qui se consacre à la création de normes
communes facilitant l'échange d'informations entre systèmes (métadonnées). Au
fur et à mesure que la MDC va faire évoluer le modèle, elle va encourager et aider
les autres éditeurs à prendre en charge le standard OIM au sein de leurs outils
respectifs. La MDC publie les formats XML (Extensible Markup Language) comme méthode
d'échange de données entre différents outils utilisant le standard OIM. Ce dernier
limite la complexité de l'extraction et de l'insertion des données de/dans Microsoft
Repository et les outils d'autres éditeurs.
La version actuellement validée du standard OIM (initialement soumise par Microsoft
et ses éditeurs partenaires) est la 1.0 ; une proposition de version 1.1 a été
soumise en novembre 1999, et devrait en toute logique être validée en 2000. Les
exemples et descriptions présentés dans le présent article s'appuient sur la version
1.1. Ces exemples nécessitent la version 3 de Microsoft Repository, disponible
avec SQL Server 2000. La version 2 de Repository ne supporte pas les collections
ni les propriétés héritées, que le standard OIM MDC utilise intensivement.
Le standard OIM couvre de nombreux domaines, dont :
· L'analyse et la conception d'UML, les extensions UML, les éléments génériques,
les types de données communs et la modélisation entités-relations
· Objets et composants : description des composants
· Base de données et entrepôts de données : schémas de bases de données relationnelles,
transformations de données, schémas OLAP, schémas de bases de données orientés
enregistrements, schémas XML et définitions des rapports
· Ingénierie de processus de gestion : objectifs commerciaux, règles et processus,
éléments organisationnels.
· Gestion de la connaissance : descriptions des connaissances et définitions sémantiques
D'un point de vue data warehousing, les schémas de bases de données relationnelles,
les transformations de données et les modèles de schémas OLAP sont les plus appropriés.
On peut télécharger chaque modèle en tant que fichier .mdl depuis le site Web
de la MDC, puis utiliser un outil de conception comme Visual Modeler ou Rational
Rose pour le visualiser.
Chaque objet figurant dans un référentiel peut avoir trois propriétés : un nom
(255 caractères au maximum), une courte description (255 caractères au maximum)
et des commentaires (de longueur pour ainsi dire illimitée). Ces zones, qui sont
la source d'une grand
Intégrité référentielle avec SQL Server
par Kalen Delaney
La maintenance des relations logiques entre les tables est un élément essentiel de la gestion de base de données. Voici comment utiliser les nouvelles méthodes d'application de l'intégrité référentielle dans SQL Server 2000.Le maintien de relations solides est primordial.
La création et le maintien de relations logiques entre les tables constituent une partie fondamentale du travail avec des bases de données relationnelles. La plupart des bases de données doivent entretenir certaines relations, sous peine de corruption logique des données. Lorsque de telles relations existent, on dit que ces données disposent d'une intégrité référentielle. L'une des tables est la table référencée et l'autre, la table de référence ; les valeurs de la table de référence doivent correspondre aux valeurs de la table référencée. (Certaines utilisateurs qualifient cette relation de tables parent/enfant. Toutefois, cette terminologie implique une hiérarchie évitée par le modèle relationnel). SQL Server peut mettre en oeuvre automatiquement l'intégrité référentielle à travers des contraintes de clés étrangères que vous aurez préalablement définies. Cette fonction est appelée intégrité référentielle déclarative (en anglais "Declarative Referential Integrity" ou DRI) en raison de sa présence dans la définition de la table. On peut également utiliser d'autres fonctions, comme les déclencheurs, pour imposer des relations ; on parle alors d'intégrité référentielle de procédure. Dans cet article, je présente comment gérer l'intégrité référentielle dans SQL Server, en accordant une attention particulière aux nouvelles fonctions intéressantes de SQL Server 2000.
SQL Server 7.0 et les versions précédentes disposaient d'une seule méthode pour traiter les tentatives de violation des contraintes de clés étrangères. Si un utilisateur tente de modifier les données d'une table d'une manière qui pourrait violer l'intégrité référentielle (telle qu'elle est définie dans les clés étrangères), SQL Server empêche cette modification et renvoie un message d'erreur. SQL Server 2000 dispose d'une nouvelle fonction cascade pouvant traiter les violations de l'intégrité référentielle d'une autre manière, comme je vais vous le démontrer.
Pour commencer, analysons rapidement un exemple permettant de clarifier ce que représente l'intégrité référentielle. La base de données Northwind dispose d'une table appelée Orders, et d'une autre, appelée Order Details. Dans la table Orders, la colonne OrderId représente la clé primaire identifiant chaque commande de manière unique. La table Order Details possède également une colonne OrderId mais, dans cette table, la colonne est une clé étrangère qui doit correspondre à un OrderId existant de la table Orders. Dans cet exemple, la table Orders est la table référencée et la table Order Details est la table de référence. Si on définit une contrainte de clé étrangère pour mettre en oeuvre la relation entre les tables Orders et les Order Details, SQL Server vérifie que la modification de l'une de ces tables ne viole pas la relation. Si par exemple on essaye de supprimer un enregistrement de la table Orders alors que l'OrderId de cet enregistrement existe dans la table Order Details, la suppression violera la contrainte d'intégrité référentielle. Tenter de mettre à jour une colonne OrderId de la table Orders lorsque la valeur d'origine, et non la nouvelle valeur, existe dans les Order Details, constitue également une violation. En outre, SQL Server doit vérifier chaque insertion dans Order Details pour s'assurer que le nouvel OrderId existe dans la table Orders, et doit vérifier toutes les mises à jour de la colonne OrderId dans Order Details.
Les 7 étapes vers le data warehouse
Les data warehouses sont un rêve pour les analystes : toute l'information concernant
les activités de l'entreprise est regroupée en un seul lieu et prête à être utilisée
par un ensemble cohérent d'outils d'analyse. Mais comment transformer le rêve
en réalité ?
Pour atteindre ce Nirvana des décideurs qu'est le data warehouse, il faut tout
d'abord bien penser le système. Vous devez comprendre le type de questions que
les utilisateurs vont lui poser (par exemple, combien de nouveaux clients par
trimestre ou quel segment de marché achète le plus d'environnements de développement
d'applications dans la région Ouest) car la raison d'être des systèmes de data
warehouse est de fournir aux décideurs l'information adaptée et à jour dont ils
ont besoin pour faire les bons choix.
Pour illustrer le processus, nous utiliserons un data warehouse créé pour une
société imaginaire fournissant des logiciels de développement d'applications,
du consulting, du personnel en délégation et des formations. Le marché évolue
très rapidement pour la société. Ses dirigeants ont donc besoin de savoir quels
ajustements dans leur modèle économique et leurs méthodes commerciales ils doivent
faire pour permettre à l'entreprise de poursuivre sa croissance. Pour aider la
société, nous avons travaillé avec l'encadrement supérieur pour concevoir une
solution.
Tout d'abord, nous avons déterminé les objectifs de l'entreprise pour ce nouveau
système. Ensuite, nous avons collecté et analysé des informations que la société.
Nous avons identifié les processus fondamentaux que l'entreprise devait surveiller
et construit un modèle conceptuel des données. Puis, nous avons situé les sources
de données et prévu les transformations nécessaires à leur appliquer. Enfin, nous
avons fixé la durée de conservation des données.
Les plus consultés sur iTPro.fr
- Agents IA : de l’expérimentation à la gouvernance, le nouveau rôle des CTO
- Alerte sur les escroqueries reposant sur les deepfakes
- Explosion des interactions vocales avec l’IA générative d’ici 2028
- Les entreprises doivent revoir leur stratégie de résilience des données en profondeur
- Microsoft Patch Tuesday Octobre 2025
Sur le même sujet
Les projets d’intégration augmentent la charge de travail des services IT
ActiveViam fait travailler les data scientists et les décideurs métiers ensemble
La blockchain en pratique
10 grandes tendances Business Intelligence
Intelligence Artificielle : DeepKube sécurise en profondeur les données des entreprises
