> Data
Intégrité référentielle avec SQL Server

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.

Lire l'article
Les 7 étapes vers le data warehouse

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.

Lire l'article
Utiliser Microsoft Repository

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.

Lire l'article
SQL Server 2000 : vers les sommets

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.

Lire l'article
Réplication personnalisée

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.

Lire l'article
Réplication bidirectionnelle avec SQL Server 7.0

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.

Lire l'article
Indexer pour optimiser les performances des tris

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.

Lire l'article