Une meilleure conception des moteurs de recherche
par David Jones
Utilisez la fonction de recherche documentaire de SQL Server 7.0 pour concevoir des bases de données pouvant être consultées sur le Web
Que vous fassiez des recherches pour un exposé ou que vous
recherchiez un numéro de téléphone, ou encore que vous ne fassiez que surfer,
vous utilisez probablement un moteur de recherche Internet quotidiennement. Pour
répondre à la demande d'informations récupérables, de nombreuses
entreprises conçoivent des sites Web utilisant des bases de données
relationnelles en arrière-plan et sur lesquels les utilisateurs peuvent
effectuer des recherches dynamiques. En notre qualité d'administrateurs de
bases de données et de développeurs d'applications, nous devons concevoir de
meilleurs mécanismes permettant à l'utilisateur de rechercher des informations
sur l'entreprise, telles que les bilans pour les actionnaires, les communiqués
de presse, les catalogues produits, etc... La fonction de recherche documentaire
de SQL Server 7.0 peut représenter la réponse. Le moteur de recherche
documentaire de SQL Server permet des recherches rapides, et offre des
fonctionnalités avancées de recherche de texte, très utiles dans un
environnement d'entreprise.
Vous utilisez probablement un moteur de recherche Internet quotidiennement
Avec les premières versions de SQL Server, on était limité à des requêtes sur de larges blocs de texte en utilisant LIKE dans une instruction SELECT. Mais l'instruction LIKE est limitée, car elle ne peut établir de correspondance qu'avec des séquences de caractères. En outre, si on utilise l'instruction LIKE avec un signe pourcent (%) avant et après la chaîne recherchée, on génère une analyse de table très longue. La plupart des utilisateurs ont besoin de fonctions de recherche plus avancées, produisant des résultats immédiats après qu'ils aient appuyé sur la touche Entrée. Avec SQL Server 7.0 et les versions ultérieures, on peut toujours utiliser l'instruction LIKE si on le souhaite, mais on peut désormais aussi utiliser une nouvelle option de syntaxe et indexer les données.
Au lieu d'utiliser les index stockés dans la base de données, le moteur de recherche documentaire utilise Microsoft Search Service pour répertorier ces index sur le disque dur du serveur. Lorsqu'on sélectionne l'option Full-Text Search dans la Configuration personnalisée de SQL Server, le processus d'installation installe automatiquement Microsoft Search Service. Toutefois, ce service n'est disponible que pour les systèmes Standard et Enterprise sous Windows 2000 ou Windows NT, et non dans les versions poste de travail ou Windows 9x. Microsoft Search Service intègre deux fonctions distinctes : conception et peuplement du catalogue de recherche documentaire, et traitement de la recherche.
Pour installer le moteur de recherche documentaire après avoir installé SQL Server, il faut réexécuter l'installation à partir du CD-ROM de SQL Server 7.0. Dans la boîte de dialogue Select Components (Sélectionner les composants), sélectionnez L'option Full-Text Search, comme cela est indiqué dans la figure 1, puis redémarrez. Seul SQL Server 7.0 fonctionnant sous NT Server prend en charge la recherche documentaire. L'environnement NT Server Enterprise Edition clusterisé ne supporte pas encore la fonction de recherche documentaire de SQL Server. De fait, Microsoft prendra en charge cette fonction dans un environnement clusterisé dans SQL Server 2000.
Lire l'article
SQL Server 2000 : vers les sommets
Imaginez que vous pouvez construire la maison de vos rêves. Pas de problème de
budget, mais vous voulez emménager le plus vite possible. Dans ce cas, il vous
faudra choisir entre avoir la perfection avant d'emménager et prendre possession
de la maison le plus vite possible. Vous prendrez probablement du temps pour concevoir
les fondations et les pièces essentielles, quitte à ajouter une aile ou à aménager
les combles par la suite.
Le processus d'évolution de SQL Server ressemble un peu à la construction de cette
maison. Il y a plusieurs années, Microsoft a réuni plusieurs des meilleurs spécialistes
mondiaux des bases de données (de Microsoft et d'ailleurs) et leur a demandé de
créer la base de données de leurs rêves. On peut considérer SQL Server 7.0 comme
les fondations de ce projet.
Le code de SQL Server 7.0 comportait des évolutions majeures par rapport au code
de base mais les DBA et les développeurs ne pouvaient pas voir ou utiliser de
nombreuses améliorations. Microsoft SQL Server 7.0 comportait de nombreuses améliorations
visibles (telles que les services OLAP), mais la plupart des efforts de reengineering
se situait au niveau de la page ou du stockage. J'ai découvert SQL Server 2000
à la conférence SQL Server Most Valuable Professional (MVP) de Microsoft en octobre
dernier.
Les premiers briefings portaient principalement sur l'architecture interne et
je suis reparti avec un tuyau important : SQL Server 2000 s'appuie sur les fondations
de SQL Server 7.0 et rénove une partie de la plomberie et du réseau électrique.
En fait, à bien des égards, SQL Server 2000 c'est la maison terminée, la grande
extension et les salles de projection privées dont vous avez toujours révées.
Utiliser Microsoft Repository
par Patrick Cross et Saeed Rahimi
Appuyez-vous sur la technologie des référentiels de données pour offrir aux utilisateurs
les meilleures sources d'informations stratégiques possibles
Ces quelques dernières années, les meilleures pratiques en matière d'entreposage
de données (data warehousing) impliquent l'utilisation d'un référentiel pour stocker
des informations sur les données contenues dans l'entrepôt. Les informations du
référentiel permettent à l'utilisateur de mesurer l'impact des modifications,
de suivre et de gérer les problèmes, et de mieux appréhender les données qu'ils
utilisent pour prendre des décisions stratégiques. Microsoft Repository est un
élément important de la stratégie Microsoft en matière de data warehousing. Avec
les exemples suivants, vous comprendrez et utiliserez le référentiel de façon
plus efficace.
SQL Server 7.0 Réplication personnalisée
par John D. Lambert
Les procédures de transfert-delta peuvent vous apporter le meilleur de la réplication
sans les coûts associés
SQL Server 7.0 rend la réplication plus simple que jamais mais, pour maximiser
votre expertise, envisagez toutes les possibilités. On peut utiliser les assistants
de réplication, DTS (Data Transformation Services), l'interface SQL-DMO (SQL Distributed
Management Objects) et même du code binaire.
Toutefois, si vous êtes déjà un utilisateur chevronné de T-SQL, pensez à apprendre
à utiliser des procédures cataloguées personnalisées pour copier les données.
Dans le présent article, je tente d'expliquer comment et dans quelles circonstances
utiliser cette méthode.
Réplication bidirectionnelle avec SQL Server 7.0
par Baya Pavliashvili
Les éditeurs convertis en abonnés et les abonnés convertis à leur tour en éditeurs
Les fonctions avancées de réplication de SQL Server permettent de synchroniser
les données de plusieurs bases de données, que celles-ci résident sur le même
serveur ou non. Mais pourquoi pas simplement sauvegarder les bases de données
et les restaurer ensuite sur un autre serveur, ou utiliser DTS (Data Transformation
Services) pour transférer les tables et données ? Si on travaille sur des bases
de données accessibles uniquement en lecture, ces techniques conviennent parfaitement.
Mais qu'en est-il si on a une base de données transactionnelle (OLTP) de grande
taille (100 Go ou plus) gérant une centaine de transactions ou plus par minute
? Ou alors, que faire si on a plus de 1.000 utilisateurs exécutant des instructions
Select, Insert, Update et Delete au moins 8 heures par jour ? Dans ce contexte,
effectuer des sauvegardes suivies de restaurations toutes les 10 minutes (ce qui
aurait pour effet de verrouiller les tables et déclencher des appels d'utilisateurs
irrités) est inacceptable. En outre, l'utilisation de DTS ou de bcp (bulk copy
program) pour transférer autant d'informations à chaque fois que l'on souhaite
synchroniser des bases de données n'est pas viable ; le transfert nécessiterait
beaucoup trop de temps.
Même si la réplication n'accélère pas le transfert des données, elle permet cependant,
d'effectuer ce dernier d'un serveur à un autre en une seule opération, puis de
répercuter les modifications sur les autres bases de données. En d'autres termes,
la réplication peut représenter la solution idéale pour transférer des données
si on recherche un juste milieu entre la propagation des données sur différentes
machines et la disponibilité de ces mêmes données.
SQL Server 7.0 passe à la vitesse supérieure en matière de réplication
et de facilité d'emploi
SQL Server 6.0 a apporté le support de la réplication, et SQL Server 6.5 a
rajouté des améliorations mineures. Pour sa part, SQL Server 7.0 passe à la vitesse
supérieure en matière de réplication et de facilité d'emploi. En effet, SQL Server
7.0 va bien au delà d'une photographie instantanée des données et de la réplication
transactionnelle standard pour supporter la réplication bidirectionnelle (ou un
abonnement avec mise à jour instantanée) et la réplication par fusion. Cette version
permet également de répliquer des données de et vers des plates-formes non SQL.
De plus, SQL Server 7.0 automatise toutes les tâches de réplication, permettant
ainsi aux administrateurs de configurer et d'administrer la réplication à l'aide
d'assistants, sans écrire une seule procédure cataloguée. A travers les assistants
de réplication, il est même possible de paramétrer SQL Server de manière à écrire
des tâches de nettoyage et d'informer les administrateurs des éventuelles erreurs
par courrier électronique ou pager. Passons en revue les assistants de SQL Server
7.0 en vue de configurer un exemple de solution de réplication avec mise à jour
immédiate. Examinons ensuite, l'action de SQL Server en coulisses pour implémenter
cette solution et pour finir, testons la solution proposée.
Indexer pour optimiser les performances des tris
par Dusan Petrovic et Christian Unterreitmeier
La définition d'index sur les colonnes de tri peut améliorer les performances
de manière exceptionnelle
Un index approprié peut considérablement améliorer les performances de tri de
SQL Server.
Par exemple, la définition d'un index clusterisé sur une colonne de tri contraint
la base de données à stocker les enregistrements sous forme triée, ce qui permet
d'extraire les données sans avoir à réaliser de tri supplémentaire. Vous noterez
que SQL Server 7.0 et les versions antérieures permettent de créer des index uniquement
en ordre croissant.
Par conséquent, si votre requête nécessite des données dans un ordre décroissant,
il faudra certainement effectuer un tri supplémentaire et utiliser des tables
de travail internes pour générer des données dans l'ordre approprié.
Cependant, SQL Server 2000 permet de créer des index aussi bien dans un ordre
croissant que décroissant.
SQL Server 2000 permet de créer des index aussi bien dans un ordre croissant
que décroissant.
SQL Server 7.0 effectue une opération de tri lorsqu'on utilise la clause ORDER
BY. L'optimiseur de requêtes de SQL Server est également susceptible d'utiliser
une opération de tri pour traiter une requête utilisant les clauses GROUP BY,
DISTINCT ou UNION. En revanche, on peut utiliser l'indicateur d'index FAST pour
éviter le tri des données.
Cela indique à l'optimiseur de requêtes de SQL Server qu'il doit utiliser un index
non clusterisé correspondant à la clause ORDER BY, éliminant ainsi la nécessité
du tri. Observons comment SQL Server gère les clauses GROUP BY, DISTINCT et UNION
pour trier les données, puis analysons comment les différentes techniques d'indexation
peuvent améliorer les performances des requêtes nécessitant des données triées.
Windows 2000 et SQL Server
par Michael Otey
Cinquième version majeure du système d'exploitation Windows NT, Windows 2000 (W2K)
comprend de nombreuses fonctions avancées lui permettant de concurrencer de très
près les systèmes UNIX, dont la réputation n'est plus à faire en termes de service
de fichiers, d'applications et de bases de données sur le marché des entreprises.
Les améliorations apportées à W2K en matière de réseau et de facilité d'emploi,
en font une meilleure plate-forme pour SQL Server que NT 4.0.
XML et SQL Server 2000
par Paul Burke
Facilitez-vous le commerce électronique et l'interopérabilité grâce au standard
Internet d'échange d'informations
| Remarque : Les auteurs ont basé leurs articles SQL Server 2000 sur des versions antérieures à la Bêta 2. Aussi, il se peut que vous remarquiez quelques différences entre la Bêta 2 et le comportement ou les interfaces décrits dans cet article. En particulier, veuillez noter que la fonction vues indexées ne sera disponible que dans SQL Server 2000 Enterprise Edition. Toutefois, on peut installer Entreprise Edition sur un serveur NT 4 ou Windows 2000 (W2K). On n'est pas obligé d'utiliser NT 4.0 Enterprise ou W2K Advanced Server. |
L'une des fonctionnalités les plus attendues de SQL Server 2000, le support de XML, est également l'une des plus floues en termes de valeur pratique immédiate. Personne n'a échappé au battage médiatique concernant ce langage, qui constituerait une passerelle entre tous les langages, et presque tous les systèmes de gestion de bases de données relationnelles (SGBDR) affirment désormais prendre en charge XML. Mais où, quand et pourquoi utiliser XML ?
XML permet de publier des types de données indépendamment des plates-formes, facilitant ainsi l'interopérabilité et le commerce électronique
XML, un standard Internet d'échange d'informations, permet de publier des types de données indépendamment des plates-formes, facilitant ainsi l'interopérabilité et le commerce électronique. XML sépare également les données des informations de présentation à l'intérieur des pages Web ; on dispose ainsi d'un moyen standard pour définir et échanger des données entre applications et bases de données. (L'encadré "XML, le standard à la mode", décortique les avantages qu'il y a à utiliser XML pour séparer les données de leur présentation).
En tant que langage de définition de pages, le principal intérêt de XML vient soit de l'acceptation générale d'un langage particulier, défini dans XML, soit de l'acceptation générale de XML et de la disponibilité des utilitaires, d'outils et de l'infrastructure permettant de prendre en charge son utilisation. Même si XML comporte plusieurs excellents langages définis (tels que BizTalk, DSML [Directory Services Markup Language], et SOAP [Simple Object Access Protocol]), ce n'est pas la panacée pour tout le monde, surtout si on travaille dans un environnement Microsoft pur et dur, et qu'on développe des applications Windows 32 bits. Pour le transfert de données via un LAN, les ensembles de résultats ADO représentent le choix évident. Cependant, à l'heure de l'Internet, rares sont les entreprises qui travaillent en circuit fermé. Et même à l'intérieur des entreprises, il n'est pas rare de trouver différents types de serveurs, plates-formes ou langages.
Bien que SQL Server 2000 soit la première version de SQL Server à proposer le support de XML, la fonction de prévisualisation XML de Microsoft fonctionne avec les versions 7.0 et 6.5. (on peut télécharger cette fonction de prévisualisation depuis le site Web SQL Server de Microsoft, à l'adresse suivante : http://msdn.microsoft.com/workshop/xml/articles/xmlsql/). On peut également intégrer le support de XML dans SQL Server 7.0, 6.x et 4.2 en créant des procédures cataloguées étendues et des procédures cataloguées standard, quoique les procédures cataloguées standard puissent faire baisser les performances pour des ensembles de données de grande taille et de structure complexe. En outre, certaines fonctionnalités de SQL Server 7.0, telles que la recherche documentaire sur texte intégral, permettent de stocker du code XML comme du texte. Quelles sont alors les fonctions qui rendent SQL Server 2000 officiellement compatible XML ?
En général, on peut demander deux sortes de XML à une base de données : le XML statique, stocké dans la base de données, et le XML dynamique, généré par les données présentes dans la base de données. Même la première version d Lire l'article
Comment tout savoir sur SQL Server 2000
La nouvelle version atteint de nouveaux sommets
Remarque : Les auteurs ont basé leurs articles SQL Server 2000 sur des versions
antérieures à la Bêta 2. Aussi, il se peut que vous remarquiez quelques différences
entre la Bêta 2 et le comportement ou les interfaces décrits dans cet article.
En particulier, veuillez noter que la fonction vues indexées ne sera disponible
que dans SQL Server 2000 Enterprise Edition. Toutefois, on peut installer Entreprise
Edition sur un serveur NT 4 ou Windows 2000 (W2K). On n'est pas obligé d'utiliser
NT 4.0 Enterprise ou W2K Advanced Server.
Imaginez que vous ayez la possibilité de construire la maison de vos rêves, dans
laquelle vous projetez d'élever vos enfants au cours des 20 prochaines années.
L'argent n'est pas un problème, mais vous voulez emménager le plus tôt possible.
Dans ce cas, vous allez être obligé de faire des concessions, et de choisir entre
avoir une maison parfaitement aménagée avant d'y habiter et pouvoir y emménager
le plus tôt possible. Vous allez passer du temps à concevoir soigneusement les
pièces principales de la maison, sachant que vous pourrez toujours terminer le
sous-sol ou rajouter une grande terrasse après avoir emménagé. Comparons ce processus
à la construction de SQL Server.
Il y a plusieurs années, Microsoft a regroupé les meilleurs spécialistes de la
conception des bases de données à travers le monde (internes et externes à Microsoft)
et leur a demandé de bâtir la base de données de leurs rêves. Considérez SQL Server
7.0 comme le résultat fondamental de ces efforts. SQL Server 7.0 est une réécriture
importante du code de base, mais les administrateurs de bases données et les développeurs
ne pouvaient pas voir ni toucher beaucoup de ces améliorations. En effet, SQL
Server 7.0 apporte une kyrielle de nouvelles fonctionnalités importantes (comme
les services OLAP). Mais une grande partie du réingéneering du noyau se situe
au niveau de la gestion des pages et de la mémoire. Pour la première fois en Octobre
1999, j'ai vu SQL Server 2000 lors de la conférence MVP (Most Valuable Professional)
de Microsoft.
Les premiers séminaires couvraient l'architecture interne des moteurs relationnels
et de la mémoire, et je suis reparti avec le sentiment très fort que SQL Server
2000 s'appuie sur les fondations de SQL Server 7.0 et y rajoute "la plomberie
et l'électricité". A bien des égards, SQL Server 2000 ressemble à ce sous-sol
terminé, cette énorme terrasse et ce studio de projection personnel dont vous
avez toujours rêvé.
Il peut désormais rivaliser d'égal à égal avec n'importe quelle plate-forme
de base de données concurrentes
Améliorez les performances base de données avec l’assistant d’optimisation des index
par Itzik Ben-Gan
En utilisant des index appropriés, les requêtes deviennent plus performantes qu'elles
ne l'ont jamais été
Avez-vous créé des index optimisés pour votre base de données ? Avez-vous pensé
à utiliser les meilleurs index de tables clusterisés ? Avez-vous déterminé quels
index peuvent améliorer les performances des requêtes ? Le choix du meilleur index
clusterisé pour une table base de données principale constitue l'un des problèmes
les plus ardus que rencontrent les administrateurs de bases de données.
Toutefois, le choix des meilleurs index non clusterisés n'est pas non plus très
aisé. En effet, cela impose de prendre en considération la distribution statistique
des données, les différentes techniques utilisées par l'optimiseur de requêtes
pour concevoir un plan d'exécution efficace, ainsi que le nombre de sélections
et de modifications effectuées par les utilisateurs sur la base de données pour
ne pas créer d'index superflus.
Les développeurs SQL Server 7.0 disposent déjà de SQL Profiler, un outil
inestimable permettant de suivre les requêtes
Ne serait-il pas idéal de disposer d'un outil capable d'analyser les requêtes
effectuées sur sa base de données et de recommander les index à créer ? Et bien
coup de chance. Les développeurs SQL Server 7.0 disposent déjà de SQL Profiler,
un outil inestimable permettant de suivre les requêtes effectuées sur une base
de données. On peut enregistrer le résultat de Profiler dans un fichier, une table
ou un script SQL. On peut ensuite analyser ce résultat à l'aide d'un autre outil
de SQL Server 7.0, l'assistant d'optimisation d'index ou Index Tuning Wizard (ITW),
lequel recommande les index à concevoir.
Pour s'assurer que l'ITW donne des indications efficaces, il faut assurer un suivi
des requêtes pendant une période d'activité type sur le système (et non une période
d'activité exceptionnellement intense ou faible ni une période où se produisent
des activités exceptionnelles). Il faut également décider pendant combien de temps
Profiler doit suivre les requêtes. On peut par exemple avoir une représentation
caractéristique de l'activité du système, en ne faisant une trace avec Profiler
que durant quelques heures. Ou alors, il faudra effectuer un suivi sur quelques
jours ou plus pour capturer les variations d'activité en cours de journée ou sur
plusieurs jours.
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.
