télécharger 120.73 Kb.
|
Éléments fondamentaux de l'architecture de SQL Server Microsoft® SQL Server™ est une base de données relationnelle client/serveur basée sur Structured Query Language (SQL). Chacun de ces terms decrit une partie fondamentale de l'architecture de SQL Server. Base de données Une base de donnée est similaire à un fichier de données en ce qu'il s'agit d'un emplacement de stockage de données. De la même façon qu'un fichier de données, une base de données ne présentent pas directement les informations à un utilisateur; ces derniers exécutent une application qui accède aux données de la base de données et les présentent à l'utilisateur sous un format compréhensible. Les systèmes de base de données sont plus puissants que les fichiers de données. Les données sont beaucoup plus organisées. Dans une base de données bien conçue, il n'y a pas d'ensembles de données dupliqués que l'utilisateur ou l'application aient à mettre à jour en même temps. Les ensembles de données associées sont regroupés dans une seule structure ou enregistrement, et des relations peuvent être définies entre ces structures et ces enregistrements. Pour travailler avec des fichiers de données, une application doit être programmée afin de pouvoir travailler avec la structure spécifique de chaque fichier de données. Au contraire, une base de données contient un catalogue que les applications utilisent pour déterminer comment sont organisées les données. Les applications de base de données génériques utilisent le catalogue pour présenter de façon dynamique aux utilisateurs les données en provenance de différentes bases de données, sans être associées à un format de données spécifique. Généralement, une base de données possède deux constituants: les fichiers contenant la base de données physique et le programme de gestion de base de données (SGBD) que les applications utilisent pour accéder aux données. Le SGBD est responsable du respect de la structure de la base de données, c'est-à-dire :
Base de données relationnelle Il existe différentes façons d'organiser des données dans une base de données, mais les bases de données relationnelles font partie des plus efficaces. Les systèmes de bases de données relationnelles sont une application au problème de l'organisation efficace des données de la théorie mathématique des ensembles. Dans une base de données relationnelle, les données sont regroupées dans des tables (appelées relations dans la théorie relationnelle). Une table représente une classe d'objets qui sont importants pour une organisation. Par exemple, une entreprise peut avoir une base de données comprenant une table des employés, une autre table pour les clients et une dernière pour ses stocks. Chaque table comporte des colonnes et des lignes (attributs et nuplets dans la théorie relationnelle). Chaque colonne représente un attribut de l'objet dont la table est une représentation. Par exemple, une table Employés se compose typiquement de colonnes pour le nom, le prénom, l'identification de l'employé, le service, l'échelon salarial et l'intitulé de poste. Chaque ligne représente une instance de l'objet dont la table est une représentation. Par exemple, un ligne de la table Employés représente l'employé dont le numéro d'identification est ID 12345. Los de l'organisation des données à l'intérieur de tables, il est possible de trouver de nombreuses façons permettant de définir les tables. La théorie des bases de données relationnelles définit le processus normalisation, qui permet de s'assurer que l'ensemble de tables que vous avez défini organisera efficacement vos données. Client/Serveur Dans un système client/serveur, le serveur est un ordinateur relativement important situé en position centrale qui gère des ressources utilisées par de nombreuses personnes. Quand des personnes ont besoin d'utiliser les ressources, elles se connectent par l'intermédiaire du réseau à partir de leurs ordinateurs, ou clients, au serveur. Exemples de serveurs:
Gèrent les imprimantes utilisées par une équipe ou un service.
Stockent de gros fichiers utilisés par une unité ou un service qui utilisent d'importants lecteurs.
Exécutent le système de messagerie électronique d'une société. Dans l'architecture d'une base de données client/serveur, les fichiers de la base de données et le logiciel de SGBD sont installés sur un serveur. Un composant de communications est fourni, permettant aux applications de s'exécuter sur des clients distincts et de communiquer avec le serveur de base de données par l'intermédiaire d'un réseau. Le composant de communications de SQL Server autorise également les communications entre une application qui s'exécute sur le serveur et SQL Server. Les applications de Server sont en général capables de travailler avec plusieurs clients en même temps. SQL Server peut travailler simultanément avec des milliers d'applications clientes. Le serveur possède des caractéristiques lui permettant de prévenir les problèmes logiques susceptibles de survenir si un utilisateur essaie de lire ou de modifier des données en cours d'utilisation par d'autres. Bien que SQL Server ait été conçu pour travailler comme serveur à l'intérieur d'un réseau client/serveur, il est également capable de fonctionner comme base de données isolée directement sur un ordinateur client. L'évolutivité et la facilité d'emploi de SQL Server lui permettent de fonctionner efficacement sur un ordinateur client sans consommer trop de ressources. Langage de requêtes structurées (SQL) Pour travailler sur les données d'une base de données, il faut utiliser un jeu de commandes et d'instructions (langage) défini par le logiciel de SGBD. Les bases de données relationnelles peuvent utiliser plusieurs langages différents, le plus courant est SQL. Les standards pour SQL ont été définis par l'American National Standards Institute (ANSI) et l'International Standards Organization (ISO). La plupart des SGBD modernes prennent en charge au moins le Niceau d'entrée de SQL-92, le dernier standard SQL (publié en 1992). Caractéristiques de SQL Server Microsoft® SQL Server™ met en œuvre un ensemble de caractéristiques qui présentent les avantages suivants :
SQL Server possède un ensemble d'outils de développement et d'administration qui améliorent votre capacité à installer, déployer, gérer et utiliser SQL Server à travers plusieurs sites.
Le même moteur de base de données peut être utilisé sur plusieurs plates-formes, allant des ordinateurs portables qui exécutent Microsoft Windows® 95/98 jusqu'aux gros serveurs multiprocesseurs fonctionnant sous Microsoft Windows NT®, Édition Entreprise.
SQL Server possède des outils permettant d'extraire et d'analyser des données synthétiques en vue de leur traitement analytique en ligne (OLAP). SQL Server possède aussi des outils pour concevoir visuellement des bases de données et analyser les données à l'aide de questions posées en anglais.
SQL Server intègre la messagerie électronique, Internet et Windows. Architecture Client/Serveur Microsoft® SQL Server™ est conçu pour fonctionner de manière efficace dans divers environnements :
Systèmes de bases de données client/serveur Les systèmes client/serveur sont conçus de telle manière que la base de données puisse résider dans un ordinateur central qui occupe alors la fonction de serveur et puisse être partagée par plusieurs utilisateurs. Les utilisateurs accèdent au serveur par l'intermédiaire d'une application client ou serveur :
Ceci est le scénario typique d'une application Internet. Par exemple, une application serveur peut s'exécuter sous Microsoft Internet Information Services (IIS) et servir des milliers de clients légers qui s'exécutent sur Internet ou sur un intranet. L'application serveur utilise un ensemble de connexions pour communiquer avec une copie de SQL Server. SQL Server peut s'installer sur le même ordinateur que IIS ou sur un autre serveur du réseau. Le fait d'avoir des données stockées et gérées à un endroit centralisé présente plusieurs avantages :
Les différentes copies des données ne sont pas stockées sur les postes clients, ce qui élimine, par exemple, les problèmes avec les utilisateurs qui ont à s'assurer qu'ils travaillent bien avec les mêmes informations.
Ceci est possible dans une base de données en utilisant les contraintes, les procédures stockées et les déclencheurs. C'est également possible dans une application serveur.
Par exemple, si une application utilisant un fichier de serveur a besoin d'afficher la liste des noms de tous les vendeurs (Sales Representative) de l'Orégon (OR), elle doit normalement récupérer le fichier des employés (employee) dans sa totalité. Au contraire, si cette application communique avec un serveur de base de données relationnelle, il lui suffit d'exécuter la commande suivante : SELECT first_name, last_name FROM employees WHERE emp_title = 'Sales Representative' AND emp_state = 'OR' La base de données relationnelle renverra uniquement les noms de tous les vendeurs de l'Oregon, et non l'intégralité des informations relatives à tous les employés.
Étant donné que les données ne sont pas stockées sur chaque poste client, il n'est pas nécessaire pour l'utilisateur, de réserver de l'espace disque pour le stockage de ces données. Il n'est donc pas nécessaire pour les postes clients de disposer de capacité de traitement pour gérer les données en local. Quant au serveur, il est dispensé de mobiliser sa puissance de traitement pour afficher les données. Le serveur peut être configuré en vue d'optimiser les capacités d'E/S du disque afin de rechercher les données, tandis que les postes clients peuvent en revanche être configurés en vue d'optimiser les opérations de mise en forme et d'affichage des données récupérées sur le serveur. Le serveur doit être stocké dans un endroit relativement bien sécurisé et être équipé en périphériques tels qu'un onduleur, qui est plus économique qu'un dispositif général de protection de tous les postes clients.
Au sein d'un important système client/serveur, des milliers d'utilisateurs peuvent être connectés simultanément au serveur qui exécute SQL Server. SQL Server est muni d'un dispositif complet de protection pour ce type d'environnements avec, par exemple, des sécurités évitant des problèmes tels que le fait d'avoir plusieurs utilisateurs qui essayent simultanément de mettre à jour les mêmes données. SQL Server est capable d'allouer efficacement à plusieurs utilisateurs les ressources disponibles telles que la mémoire, la largeur de la bande réseau ou encore les E/S disque. Des applications SQL Server peuvent être exécutées sur l'ordinateur même où s'exécute SQL Server. L'application se connecte à SQL Server en utilisant les composants de communication interprocessus (IPC) de Windows (telle que la mémoire partagée), au lieu de passer par un réseau. Cela permet à SQL Server de pouvoir être utilisé avec de petits systèmes sur lesquels, par exemple, une application donnée a besoin de stocker ses données localement. Systèmes de bases de données de bureau Efficace en tant que serveur, SQL Server peut également être utilisé avec des applications qui ont besoin d'utiliser une base de données autonome stockée localement sur le poste client. SQL Server peut, de façon dynamique, se configurer lui-même, afin de s'exécuter avec les ressources disponibles sur un poste client, sans qu'il soit pour cela besoin de dédier à chaque poste client un administrateur de base de données. Les fournisseurs d'applications peuvent également intégrer SQL Server en tant que composant de stockage de données dans leurs applications. Lorsque les clients utilisent des bases de données locales SQL Server, une copie du moteur de base de données SQL Server s'exécute sur le poste client et gère toutes les bases de données SQL Server qui y sont installées. Les applications se connectent au moteur de base de données de la même manière que lorsqu'elles se connectent, en passant par le réseau, à un moteur de base de données qui s'exécute sur un serveur distant. Architecture de base de données Les données de Microsoft® SQL Server™ sont stockées dans des bases de données et sont organisées en composants logiques visibles par les utilisateurs. Une base de données est également implémentée physiquement sous forme de deux fichiers ou plus sur disque. Lorsque vous utilisez une base de données, vous commencez par manipuler les composants logiques tels que les tables, les vues, les procédures et les utilisateurs. L'implémentation physique des fichiers est en grande partie transparente. Cette tâche revient par défaut à l'administrateur de la base de données. ![]() Chaque installation SQL Server possède plusieurs bases de données. SQL Server dispose de quatre bases de données système (master, model, tempdb et msdb), chaque installation SQL Server possédant une ou plusieurs bases de données utilisateur. Certaines entreprises ne disposent que d'une base de données utilisateur unique qui regroupe toutes leurs données. D'autres, en revanche, possèdent des bases de données propres à une division de leur entreprise et, parfois, d'une base de données réservée à une seule application. Ainsi, une entreprise peut disposer d'une base de données spécifique aux ventes, aux fiches de paie, à une application de gestion de la documentation, etc. Il arrive aussi qu'une application fasse appel à une ou plusieurs bases de données. ![]() Il n'est pas nécessaire d'exécuter plusieurs copies de SQL Server pour permettre à plusieurs utilisateurs d'accéder aux bases de données qui sont installées sur le serveur. SQL Server est capable de prendre en charge des centaines d'utilisateurs travaillant simultanément sur plusieurs bases de données d'un même site. Celles-ci sont accessibles à tous les utilisateurs qui se connectent au serveur, à condition que ces derniers disposent des autorisations d'accès nécessaires. Lorsque vous vous connectez à SQL Server, la connexion est associée à une base de données spécifique appelée la base de données en cours. En principe, il s'agit de la base de données par défaut définie par l'administrateur système, bien que vous puissiez en spécifier une autre grâce aux options de connexion proposées dans les API de la base de données. Vous pouvez passer d'une base de données à une autre à l'aide de l'instruction Transact-SQL USE nom_base_de_données ou utiliser une fonction d'API modifiant le contexte de la base de données en cours. La version 7.0 de SQL Server vous permet de détacher des bases de données d'un serveur, de les réattacher à un autre serveur ou au serveur d'origine. Si vous disposez d'un fichier de base de données SQL Server, vous pouvez indiquer à SQL Server, au moment de la connexion, que vous souhaitez attacher ce fichier à une base de données spécifique. Composants de la base de données logique Les données d'une base de données Microsoft® SQL Server™ sont organisées en plusieurs objets, visibles par un utilisateur lorsqu'il se connecte à la base de données. Dans SQL Server, les composants suivants sont définis en tant qu'objets :
Types de données et structures de table Toutes les données des bases de données Microsoft® SQL Server™ sont contenues dans des objets appelés tables, chacune d'entre elles représentant un type d'objet significatif pour les utilisateurs. Dans la base de données d'une école, par exemple, il est logique de trouver des tables relatives au cours, au professeur et à l'élève. Les tables SQL Server sont constituées de deux composants principaux :
Chaque colonne représente un attribut quelconque de l'objet modélisé par la table, comme une table de pièces détachées comportant des colonnes réservées à l'ID, à la couleur et à l'épaisseur.
Chaque ligne représente une seule occurrence de l'objet modélisé par la table. Par exemple, la table de pièces détachées pourrait comporter une ligne pour chaque pièce vendue par l'entreprise. Étant donné que chaque colonne représente un attribut d'un objet, les données de chaque occurrence de la colonne sont similaires. L'une des propriétés d'une colonne s'appelle le type de données. SQL Server possède plusieurs types de données de base :
Les utilisateurs peuvent également créer leurs propres types de données, par exemple : -- Create a birthday data type that allows nulls. EXEC sp_addtype birthday, datetime, 'NULL' GO -- Create a table using the new data type. CREATE TABLE employee (emp_id char(5), emp_first_name char(30), emp_last_name char(40), emp_birthday birthday) Un type de données défini par l'utilisateur facilite la lisibilité de la structure de la table et garantit que les colonnes contenant des catégories de données similaires possèdent le même type de données de base. Un domaine désigne l'ensemble de toutes les valeurs autorisées dans une colonne. Il comprend le type de données et les valeurs autorisées dans les colonnes. Ainsi, un domaine couleur de pièce comprendrait le type de données char(6) ainsi que les chaînes de caractères autorisées dans la colonne telles que Rouge, Bleu, Vert, Jaune, Marron, Noir, Blanc, Vert foncé, Gris et Argent. Les valeurs de domaine peuvent être imposées par l'intermédiaire de mécanismes comme les contraintes CHECK et les déclencheurs. Les colonnes peuvent accepter ou rejeter les valeurs NULL. NULL est un concept spécifique aux bases de données désignant une valeur de type inconnu, contrairement au blanc ou au zéro (0), qui représentent respectivement un caractère et un nombre reconnus. NULL se distingue également d'une chaîne de longueur nulle. Si une définition de colonne contient la clause NOT NULL, cela signifie que vous ne pouvez pas insérer de ligne ayant la valeur NULL. Si la définition de colonne comporte uniquement le mot clé NULL, vous pouvez insérer des valeurs NULL. L'autorisation des valeurs NULL dans une colonne peut augmenter la complexité de toutes les comparaisons logiques utilisant cette colonne. Selon la norme SQL-92, toute comparaison effectuée à l'aide d'une valeur NULL ne prend pas la valeur TRUE ou FALSE mais la valeur UNKNOWN. Cela se traduit donc par l'introduction de trois opérateurs de comparaison logiques pouvant entraîner des problèmes de gestion. SQL Server stocke les données définissant la configuration du serveur et toutes ses tables dans un ensemble de tables spécifique appelé tables système. Il est impossible de les consulter ou de les modifier directement. Seul SQL Server peut les référencer en réponse aux commandes d'administration lancées par les utilisateurs. Les tables système pouvant changer d'une version à l'autre, il s'avère parfois nécessaire de réécrire les applications qui les référencent directement avant de passer à une nouvelle version de SQL Server utilisant une autre version des tables système. SQL Server prend en charge les tables temporaires dont le nom commence par le signe dièse (#). Si une table temporaire n'est pas supprimée lors de la déconnexion de l'utilisateur, elle l'est automatiquement par SQL Server. Les tables temporaires ne sont pas stockées dans la base de données en cours, mais dans la base de données système tempdb. Il en existe deux types :
Les utilisateurs manipulent les données dans les tables à l'aide des instructions du langage de manipulation des données (DML) SQL : -- Get a list of all employees named Smith: SELECT emp_first_name, emp_last_name FROM employee WHERE emp_last_name = 'Smith' -- Delete an employee who quit: DELETE employee WHERE emp_id = 'OP123' -- Add a new employee: INSERT INTO employee VALUES ( 'OP456', 'Dean', 'Straight', '01/01/1960') -- Change an employee name: UPDATE employee SET emp_last_name = 'Smith' WHERE emp_id = 'OP456' Vues SQL Une vue peut être représentée comme une table virtuelle ou une requête stockée. Les données accessibles par l'intermédiaire d'une vue ne sont pas stockées dans la base de données sous forme d'objet distinct. C'est une instruction SELECT qui est stockée, le jeu de résultats de cette instruction constituant la table virtuelle renvoyée par la vue. Un utilisateur peut l'utiliser en référençant le nom de la vue dans les instructions Transact-SQL de la même façon qu'une table. Une vue permet d'exécuter tout ou une partie des fonctions suivantes :
Vous pouvez, par exemple, accorder à un employé l'autorisation de visualiser uniquement les lignes concernant ses heures de travail dans la table de suivi de la main-d'œuvre.
Vous pouvez, par exemple accorder aux employés qui ne travaillent pas dans le service de la paye, l'autorisation en lecture des colonnes Nom, Bureau, Téléphone professionnel et Division de la table des employés, mais leur refuser l'accès aux informations d'ordre privé ou financier.
Vous pouvez, par exemple, présenter le total d'une colonne, ou encore sa valeur minimale ou maximale. Pour créer une vue, il convient de définir l'instruction SELECT qui récupère les données à présenter dans la vue. Les tables de données référencées par l'instruction SELECT sont appelées les tables de base de la vue. titleview dans la base de données pubs est un exemple de vue qui sélectionne les données issues de trois tables de base, pour présenter une table virtuelle des données les plus fréquentes. CREATE VIEW titleview AS SELECT title, au_ord, au_lname, price, ytd_sales, pub_id FROM authors AS a JOIN titleauthor AS ta ON (a.au_id = ta.au_id) JOIN titles AS t ON (t.title_id = ta.title_id) Vous pouvez ensuite référencer titleview dans les instructions de la même façon qu'une table. SELECT * FROM titleview Une vue peut en référencer une autre. Ainsi, titleview présente des informations utiles aux directeurs mais, en général, une société n'a besoin que des chiffres cumulés jusqu'à ce jour dans ses états financiers annuels ou trimestriels. Il est possible de construire une vue sélectionnant toutes les colonnes de titleview à l'exception de au_ord et de ytd_sales. Les clients peuvent s'en servir pour obtenir les listes des catalogues disponibles sans accéder aux informations financières : CREATE VIEW Cust_titleview AS SELECT title, au_lname, price, pub_id FROM titleview Les vues de Microsoft® SQL Server™ peuvent être mises à jour (elles peuvent être la cible des instructions UPDATE, DELETE ou INSERT) tant que la modification n'affecte que l'une des tables de base référencées par la vue. -- Increase the prices for publishe r '0736' by 10%. UPDATE titleview SET price = price * 1.10 WHERE pub_id = '0736' GO Procédures stockées SQL Une procédure stockée est un groupe d'instructions Transact-SQL compilées en un plan d'exécution unique. Les procédures stockées de Microsoft® SQL Server™ renvoient les données de quatre façons différentes :
Les procédures stockées contribuent à mettre en œuvre une logique cohérente dans les applications. Les instructions SQL et la logique nécessaires à l'exécution d'une tâche fréquente peuvent être créées, codées et testées une seule fois dans une procédure stockée. Il suffit ensuite à chaque application devant effectuer la tâche d'exécuter la procédure stockée. Le codage de la logique de gestion en une seule procédure offre aussi un point de contrôle unique permettant de vérifier que les règles d'entreprise sont bien respectées. Les procédures stockées peuvent également améliorer les performances. De nombreuses tâches sont mises en œuvre sous forme de séquences d'instructions SQL. La logique conditionnelle appliquée aux résultats des premières instructions SQL détermine les instructions suivantes à exécuter. Si ces instructions SQL et la logique conditionnelle sont écrites dans une procédure stockée, elles deviennent partie intégrante d'un plan d'exécution unique sur le serveur. Les résultats n'ont pas besoin d'être renvoyés au client pour que la logique conditionnelle soit appliquée, car tout le travail est réalisé sur le serveur. Dans cet exemple, l'instruction IF montre l'imbrication d'une logique conditionnelle dans une procédure afin d'empêcher l'envoi d'un ensemble de résultats à l'application : IF (@QuantityOrdered < (SELECT QuantityOnHand FROM Inventory WHERE PartID = @PartOrdered) ) BEGIN -- SQL statements to update tables and process order. END ELSE BEGIN -- SELECT statement to retrieve the IDs of alternate items -- to suggest as replacements to the customer. END Les applications n'ont pas besoin de transmettre l'intégralité des instructions SQL dans la procédure : elles n'ont à transmettre que les instructions EXECUTE ou CALL qui contiennent le nom de la procédure et les valeurs des paramètres. Les procédures stockées évitent aussi aux utilisateurs d'avoir à connaître les détails des tables de la base de données. Si un ensemble de procédures stockées prend en charge toutes les fonctions de gestion nécessaires aux utilisateurs, ceux-ci n'ont pas besoin d'accéder directement aux tables ; il leur suffit d'exécuter les procédures stockées qui modélisent les processus avec lesquels ils ont l'habitude de travailler. Les procédures stockées du système SQL Server évitant aux utilisateurs d'accéder aux tables système en sont un exemple. SQL Server comprend un ensemble de procédures stockées système dont les noms commencent en général par sp_. Ces procédures prennent en charge toutes les tâches administratives nécessaires à l'exécution d'un système SQL Server. Vous pouvez administrer un système SQL Server à l'aide des instructions Transact-SQL associées à l'administration (telles que CREATE TABLE) ou des procédures stockées du système, sans jamais avoir à mettre à jour directement les tables système. Dans les versions antérieures de SQL Server, les procédures stockées constituaient une façon de précompiler partiellement un plan d'exécution. Au moment où la procédure stockée était créée, un plan d'exécution partiellement compilé était enregistré dans une table système. L'exécution d'une procédure stockée était plus efficace que celle d'une instruction SQL, car SQL Server n'avait pas besoin de compiler complètement un plan d'exécution ; il n'avait qu'à finir d'optimiser le plan stocké pour la procédure. De même, la compilation complète d'un plan d'exécution pour la procédure stockée a été conservée dans le cache de procédure de SQL Server, ce qui signifie que les exécutions ultérieures de la procédure stockée pourront utiliser le plan d'exécution précompilé. SQL Server version 7.0 apporte de nombreuses modifications au traitement des instructions ce qui permet d'étendre à toutes les instructions SQL la plupart des améliorations des performances dues aux procédures stockées. Au moment de la création de procédures stockées, SQL Server 7.0 n'enregistre pas un plan partiellement compilé. Une procédure stockée est compilée au moment de son exécution comme n'importe laquelle des instructions Transact-SQL. SQL Server 7.0 conserve les plans d'exécution de toutes les instructions SQL dans le cache de procédure, et pas uniquement les plans d'exécution des procédures stockées. Un algorithme performant compare les nouvelles instructions Transact-SQL à celles des plans d'exécution existants. Si une correspondance est trouvée, SQL Server 7.0 réutilise le plan d'exécution. Ceci réduit le bénéfice de performances relatif de la précompilation des procédures stockées en étendant la réutilisation des plans d'exécution à toutes les instructions SQL. SQL Server 7.0 offre une nouvelle alternative au traitement des instructions SQL. Pour plus d'information, voir Architecture du processeur de requêtes SQL Server prend également en charge les procédures stockées temporaires qui, à l'instar des tables temporaires, sont automatiquement supprimées à la déconnexion. Les procédures stockées temporaires sont stockées dans tempdb et elles sont utiles en cas de connexion avec les versions antérieures de SQL Server. Vous pouvez les utiliser lorsqu'une application construit des instructions Transact-SQL dynamiques exécutées plusieurs fois. Au lieu d'avoir à recompiler à chaque fois ces instructions, vous pouvez créer une procédure stockée temporaire qui est compilée à la première exécution, puis exécuter le plan précompilé plusieurs fois. Cependant, une utilisation intensive des procédures stockées temporaires, peut conduire à un encombrement des tables système dans tempdb. Les deux fonctions suivantes de SQL Server 7.0 réduisent l'utilisation des procédures stockées temporaires :
Pour plus d'information sur les alternatives à l'utilisation des procédures stockées temporaires, voir Mise en mémoire cache et réutilisation du plan d'exécution Cette simple procédure stockée illustre les trois manières selon lesquelles les procédures stockées renvoient des données :
USE Northwind GO DROP PROCEDURE OrderSummary GO CREATE PROCEDURE OrderSummary @MaxQuantity INT OUTPUT AS -- SELECT to return a result set summarizing -- employee sales. SELECT Ord.EmployeeID, SummSales = SUM(OrDet.UnitPrice * OrDet.Quantity) FROM Orders AS Ord JOIN [Order Details] AS OrDet ON (Ord.OrderID = OrDet.OrderID) GROUP BY Ord.EmployeeID ORDER BY Ord.EmployeeID -- SELECT to fill the output parameter with the -- maximum quantity from Order Details. SELECT @MaxQuantity = MAX(Quantity) FROM [Order Details] -- Return the number of all items ordered. RETURN (SELECT SUM(Quantity) FROM [Order Details]) GO -- Test the stored procedure. -- DECLARE variables to hold the return code -- and output parameter. DECLARE @OrderSum INT DECLARE @LargestOrder INT -- Execute the procedure, which returns -- the result set from the first SELECT. EXEC @OrderSum = OrderSummary @MaxQuantity = @LargestOrder OUTPUT -- Use the return code and output parameter. PRINT 'The size of the largest single order was: ' + CONVERT(CHAR(6), @LargestOrder) PRINT 'The sum of the quantities ordered was: ' + CONVERT(CHAR(6), @OrderSum) GO Le résultat généré par l'exécution de cet exemple est le suivant : EmployeeID SummSales ----------- -------------------------- 1 202,143.71 2 177,749.26 3 213,051.30 4 250,187.45 5 75,567.75 6 78,198.10 7 141,295.99 8 133,301.03 9 82,964.00 The size of the largest single order was: 130 The sum of the quantities ordered was: 51317 Contraintes, règles, valeurs par défaut et déclencheurs Les colonnes des tables possèdent des propriétés autres que le type et la taille des données. Ces propriétés constituent une composante importante du mécanisme assurant l'intégrité des données d'une base de données.
Par valeur de donnée correcte, on entend un type de données et un domaine valides.
Les données d'une table doivent pointer uniquement sur les lignes existantes d'une autre table, pas sur des lignes inexistantes. Les objets utilisés pour mettre à jour les deux types d'intégrité sont :
Contraintes Les contraintes sont un moyen permettant à Microsoft® SQL Server™ d'assurer automatiquement l'intégrité d'une base de données. Les contraintes définissent des règles relatives aux valeurs autorisées dans les colonnes et elles constituent le mécanisme standard de mise en application de l'intégrité plutôt que les déclencheurs, les règles ou les valeurs par défaut. L'optimiseur de requêtes s'en sert aussi pour améliorer les performances liées à l'évaluation de la sélectivité, au calcul des coûts et à la réécriture des requêtes. Il existe cinq catégories de contraintes.
Une contrainte CHECK indique une condition de recherche de type booléen (valeurs TRUE ou FALSE) appliquée à toutes les valeurs saisies dans la colonne ; toutes les valeurs ne prenant pas la valeur TRUE sont rejetées. Vous pouvez spécifier plusieurs contraintes CHECK pour chaque colonne. Cet exemple montre la création d'une contrainte nommée, chk_id, qui vérifie par la suite le domaine de la clé primaire en veillant à ce que seuls les nombres compris dans la plage spécifiée soient saisis pour la clé. CREATE TABLE cust_sample ( cust_id int PRIMARY KEY, cust_name char(50), cust_address char(50), cust_credit_limit money, CONSTRAINT chk_id CHECK (cust_id BETWEEN 0 and 10000 ) )
Dans une contrainte UNIQUE, deux lignes d'une table ne peuvent pas avoir la même valeur non NULL dans les colonnes. Les clés primaires mettent aussi en application l'unicité des valeurs, mais elles n'autorisent pas les valeurs NULL. Une contrainte UNIQUE est préférable à un index unique.
Deux lignes d'une table ne peuvent pas avoir la même valeur de clé primaire. Dans une clé primaire, il est impossible d'entrer une valeur NULL dans une colonne. NULL est une valeur spécifique aux bases de données qui représente une valeur inconnue, distincte d'un blanc ou de la valeur 0. L'utilisation d'une petite colonne d'entiers comme clé primaire est recommandée. Chaque table devrait avoir une clé primaire. Une table peut être constituée de plusieurs combinaisons de colonnes identifiant de manière unique les lignes d'une table ; chaque combinaison est une clé candidate. L'administrateur de la base de données sélectionne l'une des clés candidates pour en faire la clé primaire. Dans la table |
![]() | ![]() | ||
![]() | «Framework php sous iis : Copix Framework» pour l’installation de sql server Express 2008 | ![]() | «Polytech’Market» (esql create sql), le script de remplissage de cette base (esql add sql), le script de suppression de la base (esql... |
![]() | ![]() | ||
![]() | «Framework php sous iis : Copix Framework» pour l’installation de sql server Express 2008 | ![]() | «Système de gestion de base de données relationnelles» dont le moteur de base de données est sql server |
![]() | ![]() |