> SQL Server
Les compléments d’exploration de données SQL Server 2005 pour Office 2007

Les compléments d’exploration de données SQL Server 2005 pour Office 2007

De nombreux outils d’analyse s’intègrent à SQL Server 2005 offrent des fonctionnalités puissantes pour l’analyse des données, mais c’est seulement depuis peu que Microsoft propose des outils standard pour apporter les possibilités du data mining sur le poste de travail.En février 2007, l’éditeur de Redmond a lancé les compléments d’exploration de données pour Office 2007. Ceux-ci permettent d’exploiter les fonctions d’analyse prédictive de SQL Server 2005 dans Excel 2007 et Microsoft Office Visio 2007. Dans cet article, nous allons examiner l’installation et la configuration de ces compléments et développer un exemple complet. Nous nous attarderons plus spécifiquement sur l’un des outils complémentaires, à savoir le client d’exploration de données pour Excel (Data Mining Client for Excel).

Contenu complémentaire :

- Développez votre connaissance de l'analyse décisionnelle
- Data Mining Reloaded

Lire l'article
Placez les données de vos cubes sur le devant de la scène

Placez les données de vos cubes sur le devant de la scène

une autre perspective de leurs données. Cette capacité peut s’avérer importante lorsque les rapports doivent afficher un grand nombre de mesures et se servent des dimensions en tant que tranches de données.

Par exemple, un rapport qui présente plusieurs mesures pour un seul employé ou produit n’a pas besoin de reprendre cette même information sur les lignes ou dans les colonnes. Par conséquent, nous allons voir comment placer les mesures sur les lignes et une autre dimension, Time, dans les colonnes, tout en réalisant les tranches à partir d’une autre dimension. Nous allons également expliquer comment paramétrer une requête MDX et appliquer un formatage aux valeurs.

Lire l'article
Guide pour traiter les erreurs de SQL imbriqué

Guide pour traiter les erreurs de SQL imbriqué

Dès lors que SQL se généralise dans les applications de production, il importe de bien vérifier et traiter les erreurs des instructions SQL imbriquées. Quand vous codez des instructions SQL imbriquées dans un langage évolué, tel que ILE RPG ou ILE Cobol, vous devez toujours vérifier la bonne fin de chaque instruction SQL exécutable, puis traiter comme il se doit les éventuelles conditions inattendues. Cet article fournit quelques conseils, techniques et profils de coding qui facilitent considérablement cette tâche.
En matière de programmation SQL imbriquée, il faut observer une règle simple : vérifier la valeur SQL state aussitôt après chaque instruction SQL exécutable du programme. Quand le SQL runtime revient à votre programme après avoir tenté d’exécuter une instruction SQL, le runtime définit une variable de programme nommée SQLState pour la valeur SQL state. (Les instructions déclaratives imbriquées, telles que Declare Cursor, et les directives de précompilateur, telles que Set Option, ne sont pas exécutées par le SQL runtime, et donc elles ne contribuent jamais à définir SQL state.)

SQL state est un code de cinq caractères présentant la structure suivante : XXYYY, où
• XX désigne la classe
• YYY désigne la sous-classe

Les significations des valeurs classe sont les suivantes :
• 00 – instruction correctement exécutée sans condition
• 01 – instruction correctement exécutée avec avertissement
• 02 – l’instruction n’a traité aucune donnée
• 03 à ZZ – l’instruction a échoué à cause d’une erreur

A propos de ces classes, on peut noter plusieurs choses. La classe « 00 » ne contient que la valeur SQL state « 00000 », donc on peut tester la chaîne entière plutôt que la seule classe.

Pour plusieurs des valeurs SQL state dans la classe « 01 », divers avertissements et erreurs column-level peuvent être indiqués par une valeur positive dans la variable d’indicateur null associée à une variable hôte. Les erreurs column-level potentielles incluent la troncature de chaîne et de date heure, les erreurs arithmétiques, les erreurs de conversion de caractères et les erreurs de mapping de données. Le sujet « References to host variable » du manuel SQL Reference fournit une description complète des paramètres de variables indicateurs. S’agissant de conditions spécifiques aux colonnes, il faut coder les tests pour qu’ils conviennent à l’application en plus de la vérification d’erreurs au niveau instruction montrée dans cet article.

La classe « 02 » inclut le SQL state « 02000 », lequel indique généralement que (1) aucune ligne n’a été renvoyée sur une opération d’entrée, (2) aucune ligne n’a été ajoutée par une opération Insert qui utilise un subselect pour spécifier de nouvelles lignes, ou (3) aucune ligne n’a satisfait à la condition de recherche d’une instruction Update ou Delete. Que l’une de ces conditions soit une erreur ou une condition escomptée, dépend de l’application ; c’est un aspect que votre code de vérification d’erreurs devrait prendre en considération.

La figure 1 fournit une liste complète des valeurs de classe. Le dernier manuel V5 SQL Messages and Codes fournit une liste complète des valeurs SQL state. Ces valeurs se veulent homogènes dans toute la famille IBM DB2 et sont fondées sur le standard SQL 1999. Pour plus d’informations à ce sujet, voir l’encadré « Où trouver des valeurs SqlState et SqlCode ».

Contenu complémentaire :
--> Lire l'article
Le service notification

Le service notification

Avec le service de notification, base de données, ou bien dans un deuxième temps en utilisant l’ajout/suppression de programme du panneau de configuration.

Lire l'article
Coordination de la migration de DTS vers SSIS

Coordination de la migration de DTS vers SSIS

De combien de lots DTS (également appelés packages dans SSIS) êtes vous responsable ? Peut-être 10 ? Ou alors 50 ? Lorsque j’ai posé cette question au cours d’une conférence l’an dernier, quelques auditeurs m’ont franchement surpris en affirmant que leur environnement disposait de plus de 2000 lots DTS ! Etait-il irresponsable de ma part de leur souhaiter bonne chance pour leurs opérations de migration ? Peut-être. Néanmoins, si vous avez des centaines de lots DTS, vous devez savoir que vous n’êtes pas seul. DTS est réputé pour sa simplicité et son utilité et, en fait, de nombreuses organisations l’ont adopté pour sa capacité à générer rapidement et simplement des traitements de données.
Que vous ayez 10 lots DTS ou plusieurs centaines, vous allez probablement vous préparer à une migration inévitable vers SQL Server 2005 Integration Services (SSIS). Toutefois, au cours de vos tests et de vos recherches, les points d’achoppement sont devenus apparents : l’architecture du produit diffère de celle de SQL Server 2000 DTS, d’où une procédure de migration plus complexe qu’une simple mise à niveau, et même après la migration de quelques packages, vous pouvez vous retrouver avec un gain minime de performances. Et qu’en est-il si vous examinez des dizaines ou des centaines de lots ? Vous allez vous préparer de nombreuses nuits sans sommeil. Pourtant, vous trouverez une lumière au bout du tunnel, et celle-ci sera rayonnante. L’atteindre ne sera peut-être pas aussi difficile que vous le croyez. En fait, maintenant que SQL Server 2005 a plus d’un an de service, les ressources et les connaissances disponibles pour vous aider au cours du processus sont plus étoffées. (Pour obtenir un b.-a.-ba utile sur la question, consultez l’article « Ascension vers SQL Server 2005 », sur le site http://www.itpro.fr Club Abonnés, Hors Série SQL Server 2005, novembre 2005 ainsi que l’encadré « Votre première étape » de cet article.) Mais ne vous contentez pas de prévoir une simple migration des lots DTS vers SSIS. Apprêtez-vous plutôt à exploiter pleinement les fonctionnalités améliorées de SSIS.

IT Technical center : SQL Server 2005 - Guide des ressources complémentaires

Lire l'article
Automatisez vos audits de sécurité

Automatisez vos audits de sécurité

SQL Server ? Fort heureusement, il existe des mesures permettant de réduire sensiblement les risques. Vous pouvez prévenir (ou au moins limiter) de nombreuses attaques SQL simplement en vérifiant initialement que vos bases de données et serveurs sont sécurisés comme il se doit.
La configuration de tous les ports d’écoute est-elle appropriée ? Avez-vous désactivé l’ensemble des bibliothèques réseau superflues ? Avez-vous pensé à supprimer les anciens fichiers de configuration SQL Server ? Et la liste ne s’arrête pas là.
Admettons-le, il faut du temps pour sécuriser tous les points de contrôle jusqu’au dernier et pour conserver une longueur d’avance sur les personnes malintentionnées. Chaque jour apporte son lot de nouvelles vulnérabilités concernant la sécurité, d’où la nécessité d’ajouter de nouveaux contrôles et d’effectuer une surveillance fréquente pour rester à l’abri des mauvaises surprises.
Dans ces circonstances, il serait épatant de pouvoir automatiser quelque peu toutes ces tâches d’audit longues et fastidieuses. C’est désormais possible si vous appliquez les techniques simples exposées dans cet article et si vous adaptez le code fourni à votre situation spécifique.

Lire l'article
Optimisation des bases de données MS SQL Server : les requêtes

Optimisation des bases de données MS SQL Server : les requêtes

En théorie, quelle que soit la façon d'écrire une requête, le SGBDR doit être capable de trouver le moyen le plus efficace de traiter la demande, grâce à l'optimiseur. Mais parce qu'il y a loin de la théorie à la pratique, différentes écritures et différents styles de résolution, alliés à la qualité de l'indexation peuvent donner des temps d'exécution très variés.
C'est pourquoi la maîtrise de la conception de requêtes est un des points clefs de la performance d'une base de données bien conçue. Voyons quels en sont les principes basiques.
Dans un cours que je donne aux Arts & Métiers, je montre comment une bonne indexation alliée à la qualité de l'écriture des requêtes, peut faire varier dans une proportion de plus de 300 le temps d'exécution d'une requête. Je commence l'exercice par une demande simple : écrire une requête SQL permettant de répondre à une question basique, mais en prenant soin d'exprimer différentes solutions, même les plus bizarres.

Outre la solution simpliste, certains y arrivent par une union, d'autres avec des sous requêtes, d'autres encore avec des jeux de CASE... L'exécution brute de toutes ces solutions, donne un coût d'exécution allant du simple au triple. La pose d'un premier index trivial ne donne rien, par manque de sélectivité. Après élimination de cette première tentative, la pose d'un nouvel index montre que les requêtes les plus coûteuses au départ deviennent les plus rapides, alors que celles qui étaient les moins coûteuses à l'origine n'ont rien gagné. Un nouvel essai d'indexation remet toutes les requêtes au même rang qu'au départ, chacune gagnant dans la même proportion et plus que l'indexation précédente.

Enfin, la dernière tentative d'indexation étant la bonne, toutes les requêtes bénéficient d'un gain important, mais certaines bien plus que d'autres. Le clou est enfoncé lorsque l'on choisit de dénormaliser avec une vue. Là, le gain devient gigantesque. Il est voisin de 13 000. Mais il ne prend pas en compte l'effort supplémentaire à faire pour les mises à jour (INSERT, UPDATE, DELETE...).

Cet exercice nous apprend trois choses :
• différentes écritures d'une même requête ne donneront pas forcément les mêmes performances, bien que dans l’absolu, ce devrait être le cas [1]
• rien ne sert de poser un index s'il ne sert pas la requête
• une même requête écrite de différentes manières ne bénéficiera pas des mêmes gains lorsque l’on pose un index J’ajouterai que tout ceci évolue en fonction de la volumétrie des données et des données mêmes !

Tant est si bien qu’il est difficile de trouver de prime abord ce qu’est l’écriture d’une bonne requête. Affirmons cependant qu’une bonne requête est une requête qui sait tirer partie du moteur de requête pour le forcer à calculer un plan de requête dont les étapes sont les plus courtes à traiter.

[1] En fait, nous croyons souvent et naïvement que certaines écritures de requêtes sont identiques. Mais nous oublions souvent l’influence du marqueur NULL, dont le comportement particulier dans différents prédicats oblige le moteur SQL à des constructions parfois fort différentes.

Lire l'article
XML et SQL SERVER

XML et SQL SERVER

Les informations échangées entre les différents systèmes, les différentes applications le sont de plus en plus auSQL Server, se sont adaptées. En effet, SQL Server à, entre autre, pour objectif de faciliter le travail avec les données. Pour cela, SQL Server dispose d'un ensemble d'instructions pour extraire des informations relationnelles au format XML ou bien l'opération inverse qui consiste à lire des données au format XML afin de stocker les informations dans une structure relationnelle classique.

Ces 2 étapes sont nécessaires et permettent de confier au moteur de base de données la plupart des transformations depuis ou vers le format XML à SQL Server. Mais SQL Server propose plus en offrant la possibilité de créer des colonnes de type XML. En intégrant directement les informations XML dans la structure relationnelle classique, SQL Server offre plus de souplesse en terme de stockage. Ce type XML est bien plus qu'un simple champ texte car SQL Server rend possible l'indexation des colonnes de type XML mais également la mise à jour, l'ajout et la suppression de données dans le document XML lui-même.

Ce sont ces trois fonctionnalités (extraire les informations au format XML, importer des données XML, stocker des données au format XML) de SQL Server qui sont exposées ci-dessous.

Lire l'article
La sécurité de SQL Server 2005 en 10 étapes

La sécurité de SQL Server 2005 en 10 étapes

Le produit SQL Server 2005 de Microsoft est un sécuriser les composants de l’infrastructure, notamment les serveurs de base de données. Cette stratégie met l’accent sur la protection de la périphérie, du réseau, des hôtes, des applications, des données et sur les défenses physiques. Le présent article expose 10 étapes à respecter avant, pendant et après l’installation de SQL Server 2005, afin de blinder votre infrastructure avec une défense en profondeur.

Lire l'article
Prenez le contrôle de vos rapports avec ReportViewer, 2e partie

Prenez le contrôle de vos rapports avec ReportViewer, 2e partie

Comme vous avez pu le découvrir dans la 1ère partie de cet article, le contrôle ReportViewer dees paramètres du rapport. Dans la 1ère partie de cet article, j’expliquais comment créer et afficher un rapport local en utilisant principalement la programmation « drag-and-drop » (glisser-déplacer) pour créer le dataset.

Nous allons maintenant voir comment écrire du code servant à demander les paramètres du rapport et à fournir le dataset, ce qui vous ouvrira des possibilités infinies concernant les types de rapports que vous pouvez créer. Par exemple, il est possible de créer une application qui stocke les définitions de rapport local dans des fichiers externes, afin que vous puissiez ajouter de nouveaux rapports ou mettre à jour des rapports existants sans recompiler et redistribuer l’application.

Lire l'article
Optimisation des bases de données SQL Server Troisième partie

Optimisation des bases de données SQL Server Troisième partie

TROISIÈME PARTIE : LE MODÈLE DE DONNÉES
Optimiser une base de données simplement par la qualité de son modèle est une chose simple, très efficace et à coût nul... Voila qui devrait intéresser beaucoup de monde. Or c'est souvent l'inverse qui se passe : le peu d'attention apportée au modèle, le peu de précaution dans le choix des types de données, le peu de respect des formes normales sont autant d'icebergs qui ne vont pointer leurs nez qu'au moment une base de données à raison d'une table pour un fichier est un échec assuré dont beaucoup d'éditeurs de solutions informatiques ont fait les frais.

Ce nouvel article a donc pour but de vous faire comprendre ce que sont les données, les types de données et la modélisation dans la perspective d'optimisation d'une base et donc d'un serveur. Toute application avec une forte implication de SGBDR commence par une modélisation des données. La qualité d'un modèle de données, ne se fera sentir que lorsque ce dernier sera mis à l'épreuve du feu, qui dans l'univers des SGBDR consiste à farcir ses tables qu'une quantité phénoménale de données et jouer les requêtes les plus fréquentes afin d'en mesurer les temps de réponse. Or cette phase est rarement entreprise en test. Elle l'est généralement en production.

C'est là qu'est l'os, hélas1, car il est déjà trop tard ! Lorsqu'un modèle de données est établi, et que le poids du volume des données se fait sentir, alors tenter de le remodéliser pour gagner des performances est un chalenge difficile : les évolutions du schéma conduisent à des migrations de données importantes (donc risquées) et des modifications d'interfaces conséquentes (donc du code à récrire). Lorsqu'il s'agit d'une base de données volumineuse, l'inertie des données peut être telle que l'alternative est s'adapter avec un coût de modification élevé ou mourir. C'est pourquoi un modèle de données bâclé présente la particularité d'avoir un coût très élevé lorsqu'il doit être rectifié, alors qu'un modèle peaufiné présente un coût quasi nul si l'on utilise l'outil adéquat et l'homme d'expérience.

Malheureusement, les français ont beau avoir inventé une méthode de modélisation d'une grande simplicité (MERISE2) il n'en demeure pas moins que peu d'informaticiens savent modéliser les données de manière intelligente. Bref, ce sont de ces écueils que je veux aujourd'hui vous entretenir, et pour cela, j'ai découpé en différentes parties le présent article. La première traite des types de données, la seconde des clefs, la troisième des tables et la quatrième de la normalisation.

Lire l'article
Quelques aspects essentiels de la conception des bases de données

Quelques aspects essentiels de la conception des bases de données

La clé de bonnes performances des SQL Server à mieux employer les index lors de la réponse à une requête

Lire l'article
La bataille de la fragmentation: les clés de la victoire

La bataille de la fragmentation: les clés de la victoire

Il y a quelques mois, j’ai été réveillé par la sonnerie insistante de mon terminal BlackBerry, laquelle m’informait que j’avais un message de priorité élevée. Tous les clients qui utilisaient l’une de mes bases de données m’appelaient pour se plaindre que notre application Web nécessitait 20 à 30 secondes pour charger les pages qu’ils consultaient le plus fréquemment.Les performances s’étaient dégradées progressivement au cours des dernières semaines et en étaient à un point tel que la simple connexion de quelques utilisateurs provoquait l’arrêt du système. Il fallait que je trouve la source du dysfonctionnement et vite. Le présent article explique comme j’ai pu remonter à l’origine du problème, celle-ci étant due, comme j’ai pu le découvrir, à l’action combinée de la fragmentation de tables et fichiers de base de données et d’une mauvaise densité de page. Il présente ensuite les actions prises pour corriger le problème.

Lire l'article
Les bases de la modélisation dimentionelle

Les bases de la modélisation dimentionelle

SQL Server 2005 Analysis Services utilise des dimensions à base d’attributs, de telle sorte que chaque attribut d’une dimension est traité automatiquement en tant que hiérarchie autonome. Désormais, vous pouvez employer la couche des métadonnées qui définit les cubes Analysis Services (le modèle dimensionnel unifié ou UDM) afin de spécifier une dimension client au lieu d’une demi-douzaine de dimensions séparées artificiellement. Un avantage de cette prise en charge plus poussée de l’approche dimensionnelle est que les développeurs de systèmes de data warehouse et d’analyse décisionnelle (BI) n’ont plus besoin de convertir des techniques de modélisation dimensionnelle standard à la vision limitée des anciennes versions de SQL Server. Désormais, vous pouvez construire des dimensions qui représentent de manière réaliste le mode de fonctionnement de votre activité et sont capables d’évoluer en phase avec celle-ci. L’objet de cet article est de définir les modèles dimensionnels, de décrire les éléments de base et les techniques qui les prennent en charge, et de proposer une architecture de données de type dimensionnel pour votre système de data warehouse et d’analyse décisionnelle.

Lire l'article
Fonctionnalité SQL Server 2005 facilement ignorées

Fonctionnalité SQL Server 2005 facilement ignorées

Tout le monde a entendu parler des grandes nouveautés de SQL Server 2005.

Lire l'article
Pleins feux sur la plate-forme d’entreprise de nouvelle génération !

Pleins feux sur la plate-forme d’entreprise de nouvelle génération !

Synergie de produits, de stratégies, de développements : la virtualisation des systèmes et la Business Intelligence, et garantissant aux utilisateurs, un accès universel aux informations.Volume de plus en plus croissant de données critiques à gérer, pressions règlementaires (Sarbane Oaxley, CRF 11, Bâle II), applications métiers renforcées, méthodes de gestion orientées process, course effrénée à la réduction des coûts : en 2008, les systèmes d’information gagnent encore en complexité. Au renfort de son initiative Dynamics IT et de sa plate-forme 2008 de gestion des applications d’entreprise, Microsoft veut aider les directions informatiques et les professionnels de l’IT à mieux gérer la complexité croissante de leurs systèmes d’information et à résoudre des équations informatiques de plus en plus difficiles:

Comment, par exemple, dans une optique de réduction des coûts, optimiser l’utilisation des ressources serveurs, y compris au sein des datacenters ? Comment au sein d’un système d’information de plus en plus hétérogène, gérer l’interopérabilité des applications ? Comment garantir la disponibilité des systèmes critiques lors des arrêts planifiés et non planifiés ? Comment répondre rapidement à la montée en charge des systèmes et réaffecter dynamiquement les ressources en fonction des attentes utilisateurs, qualité de service oblige ? Comment offrir encore plus de sécurité d’accès aux collaborateurs nomades ? « Microsoft veut aider les directions informatiques à sortir du cercle infernal break/fix, à diminuer les 70% de leurs budgets consacrés aux opérations de maintenance, en proposant des outils permettant de mieux gérer cette complexité et surtout d’en minimiser l’impact sur le système d’information » explique Lionel Billon, chef de produit SQL Server Microsoft France.

Lire l'article
Astuces concernant l’IDE Visual Studio 2005

Astuces concernant l’IDE Visual Studio 2005

J’ai collaboré récemment à quelques projets de développement qui m’ont permis de mettre à l’épreuve Visual Studio 2005. Ce faisant, j’ai identifié les astuces de productivité suivantes et j’aimerais vous en faire profiter

Lire l'article
Organisation des index dans SQL Server 2005

Organisation des index dans SQL Server 2005

SQL Server 2005 introduit un nouveau modèle pour les commandes DDL (Data Definition Language). Vous allez créer tous les objets au moyen d’une commande CREATE, les supprimer à l’aide d’une commande DROP et les modifier avec ALTER.SQL Server 2005 n’utilisera pas de procédures stockées distinctes pour modifier un aspect d’un objet, comme sp_defaultdb dans SQL Server 2000 et 7.0, qui modifie la base de données par défaut d’un utilisateur, ou encore les commandes de création spéciales à finalité unique telles que sp_addtype. SQL Server 2000 a déjà fait un pas dans cette direction en améliorant la fonctionnalité de la commande ALTER DATABASE afin d’inclure toutes les modifications apportées aux propriétés de base de données et en décourageant le recours à la commande sp_dboption.

Lire l'article
Vue d’ensemble des informations de fragmentation SQL Server

Vue d’ensemble des informations de fragmentation SQL Server

L’article « Organisation des index dans SQL Server 2005 » présente les spécifications permettant d’appeler la nouvelle fonction TVF (Table-Valued Function) sys.dm_db_index_physical_stats() dans SQL Server utilise des listes de pages séparées (organisées en fonction du mode de stockage par SQL Server des données sur la page). Par ailleurs, la version 2005 introduit la possibilité de créer une table ou un index sur des partitions distinctes, chaque partition ayant sa propre liste de pages. Une liste de pages d’un type pour une partition est appelée unité d’allocation. SQL Server 2005 gère un maximum de trois unités d’allocation pour chaque table ou index de chaque partition. Ces trois unités d’allocation sont mappés avec trois types de pages gérés par SQL Server 2005 : IN_ROW_DATA (à savoir les lignes de données ou d’index classiques), LOB_DATA (à savoir, les données d’objets de grande taille, telles que text, ntext ou image) et ROW_ OVERFLOW_DATA (un nouveau type de stockage).

Lire l'article
Modélisation des données avec SQL SERVER 2005

Modélisation des données avec SQL SERVER 2005

SQL Server 2005 introduit une pléthore de fonctionnalités et concepts : nouveaux outils de serveur, nouvelles constructions de langage T-SQL et même une interface entièrement redéfinie, SQL Server Management Studio, qui vient remplacer la console familière Enterprise Manager. L’interface d’analyse décisionnelle (BI) a été repensée, DTS laisse la place à SQL Server Integration Services (SSIS) et devient encore plus sûr.Vous n’avez plus besoin d’écrire de procédures stockées uniquement en T-SQL, grâce à l’intégration du CLR (Common Language Runtime), et le nouvel outil SQL Server Report Builder va faciliter votre travail de présentation des données. Pourtant, toutes ces nouveautés séduisantes (dont beaucoup ont été décrites dans d’autres articles de SQL Server Magazine ou dans d’autres ressources citées dans l’encadré Bibliographie) vont-elles changer fondamentalement le travail du modélisateur de données ? La réponse est non. En effet, malgré toutes ces nouvelles fonctions et fonctionnalités, quelque chose n’a pas changé : vous devez encore modéliser vos données avant de créer la base de données.

La modélisation des données est le processus consistant à capturer les règles métier, les réglementations et exigences (spécifications), puis à les convertir, une fois interprétées correctement, en un ensemble bien structuré de tables de base de données, relations et contraintes. Vous exprimez le modèle avec une série de représentations graphiques afin d’essayer de mieux comprendre les données et leur incidence sur les opérations organisationnelles. Ces représentations graphiques ne sont pas limitées à une plate-forme de base de données spécifique. Vous pouvez développer un modèle de données conceptuel, puis un modèle de données logique que vous mettrez en oeuvre sur n’importe quel SGBD, par exemple SQL Server, Oracle, IBM DB2 ou MySQL. Par conséquent, les mises à jour de versions dans un SGBD ne modifient en rien votre travail de compréhension des données, ni les exigences métier et la création des modèles de données.

Lire l'article