APIS DE TABLE POUR SQL SERVER

Transcription

1 APIS DE TABLE POUR SQL SERVER TRAVAIL DE BACHELOR D INFORMATICIEN DE GESTION C. PARTIE THÉORIQUE Mode de réalisation : Extra-muros Date de création : Dernière modification : Cycle d étude : Date de restitution : Directeur de travail : M. Pierre-André Sunier Julien Ogi

2 Table des matières 1. Introduction Les APIs de tables Les champs d audit La journalisation Les modèles de démonstration Modèle général Graphes non orientés SQL Server Le Transact-SQL Les types de données Les types de données système Les types de données définis par l utilisateur Les table value parameter Les variables Les tables Les vues Les contraintes d intégrité La clé primaire L incrémentation La contrainte NOT NULL La contrainte UNIQUE La contrainte CHECK La contrainte DEFAULT La clé étrangère Les triggers Les tables INSERTED et DELETED Les fonctions Les procédures Les schémas Les blocs d instructions Les transactions L instruction GO Le dbo Le CLR Plugin Processus global Le projet Les packages Les classes Le paramètres Les propriétés Les templates JULIEN OGI PAGE 1 SUR 40I

3 6. Mapping des types de données MCD et MLD Le type de donnée logique Les types de données textuels Les types de données numériques Les types de données de datation Visual Paradigm Les valeurs tagguées Conclusion Tables des illustrations JULIEN OGI PAGE 2 SUR 40

4 1. Introduction Cette partie présente les éléments théoriques nécessaires à la réalisation du projet et donc à la compréhension du document pratique. Elle est séparée en quatre plus ou moins importantes sections. La première présente les APIs de table, les modèles utilisés pour démontrer le fonctionnement du plugin et la problématique des graphes non orientés, la deuxième expose des notions de SQL Server en lien à ce travail tandis que la troisième concerne le plugin et apporte des précisions sur son fonctionnement et sa structure. Et la quatrième met en évidence la correspondance entre les types de données MCD et MLD et apporte des explications sur les valeurs tagguées. Les éléments concernant SQL Server ne sont volontairement pas complets et c est totalement normal. Le but de ce travail n est pas de refaire un cours sur SQL Server mais uniquement d apporter et expliquer les éléments nécessaires à la réalisation de cet ouvrage. Certains amalgames sont faits avec le SGBDR d Oracle, ceci afin d expliquer certains concepts de SQL Server. Cette façon de faire s explique par le fait que l école travaille principalement avec Oracle et certaines personnes en interne ne connaissent pas forcément très bien SQL Server. Cependant les concepts d Oracle décrits dans ce document ne seront en aucun cas détaillés. 2. Les APIs de tables Les APIs de table sont un ensemble de déclencheurs, fonctions et procédures dont leurs buts est d enrichir le modèle physique de données. Elles permettent de prendre en charge des contraintes que le SQL ne supporte pas comme la traçabilité des informations ou la non modification de valeur par exemple. [PSU-03] (p. 3) 2.1. Les champs d audit Les champs d audit permettent un suivi des modifications de lignes d une table. Ils se présentent sous la forme de colonnes au sein d une table, les noms de colonnes sont les suivants : CTRLAJUSER : le nom de l utilisateur ayant inséré la ligne CTRLAJDATE : la date (et l heure) de l insertion CTRLMOUSER : le nom de l utilisateur ayant modifié la ligne CTRLMODATE : la date (et l heure) de modification Ces colonnes techniques s insèrent à la suite des autres colonnes de la table La journalisation Journaliser une table équivaut à enregistrer toutes les modifications effectuées sur celle-ci. Pour ce faire on doit créer une nouvelle table contenant toutes les colonnes de la table à journaliser en plus de colonnes techniques spécifiques à la journalisation. JULIEN OGI PAGE 3 SUR 40

5 Ces colonnes sont : JN_OPERATION : l opération effectuée sur la table (insertion, modification ou suppression) JN_USER : l utilisateur ayant effectué la modification JN_DATETIME : la date (et l heure) de l opération de modification JN_NOTES : notes que le modélisateur peut saisir JN_APPL : le nom de l API ayant été utilisé pour journaliser JN_SESSION : le numéro de session de l utilisateur ayant effectué la modification Par «modification» on entend insertion, mise à jour et suppression. 3. Les modèles de démonstration Deux modèles de démonstration sont utilisés pour illustrer le fonctionnement du plugin et des graphes non orientés Modèle général Le MCD utilisé pour démontrer le fonctionnement du plugin et les éléments théoriques et pratiques est le suivant. Figure 1 MCD Il y a une entité Etudiant qui contient un mnémonique, qui est identifiant naturel unique, un nom et un prénom tous deux obligatoires. Et une entité Cours qui possède un libellé, obligatoire lui aussi. Les deux entités ont une relation n:n, un étudiant peut s inscrire à 0 ou plusieurs cours et un cours contient 0 ou plusieurs étudiants. L entité Inscrire n est en temps normal pas obligatoire, mais actuellement le plugin ne permet pas d auditer et journaliser les associations. Pour pouvoir le faire il est indispensable de créer une entité vide. Les contraintes sont indiquées entre les signes «<<» et «>>», le nom de la colonne suit et enfin après les «deux points» se trouve le type de la colonne. Ces types sont basés sur un profil 1 spécialement créé pour le projet MVC-CD et correspondent aux types primitifs du W3C 2. 1 Pour plus de détail sur les profils voir : 2 Pour plus de détail sur les types primitifs voir : JULIEN OGI PAGE 4 SUR 40

6 Après transformation du MCD de la Figure 1 ci-dessus on obtient le MLD/MPD suivant. Figure 2 MLD/MPD On retrouve donc nos entités transformées en tables avec en plus les colonnes d audit (CTRLAJUSER, CTRLAJDATE, CTRLMOUSER, CTRLMODATE). Les éléments en turquoise représentent les triggers, ceux en vert contiennent les procédures, schémas et types TABLE. Les tables post-fixées JN représentent les tables de journalisation. Dans la table Etudiants on retrouve bien l unicité de la colonne Mnemo et la non nullité des colonnes Nom et Prenom. Idem pour la table Cours dans laquelle nous voyons la colonne Libelle comme étant non nulle. On peut donc en déduire que la lettre N indique la nullité et la lettre U l unicité. Étant donné qu il existe une association n:n dans le MCD, une table associative Inscrire est créée entre les tables Etudiants et Cours. Si dans le MCD nous n avions pas créés l entité Inscrire alors les APIs de tables pour cette table ne se seraient jamais créées. JULIEN OGI PAGE 5 SUR 40

7 3.2. Graphes non orientés La présentation de la problématique des graphes non orientés est représentée par des routes entre des villes. Figure 3 Graphe non orienté [PSU-04] (p. 4) La route entre Berne et Neuchâtel peut être parcourue dans les deux sens, on parle alors de graphe non orienté. Il est possible de partir de Berne pour aller à Neuchâtel comme il est possible de partir de Neuchâtel pour aller à Berne. Le MCD représentant la problématique des graphes non orientés est le suivant. Figure 4 MCD d un graphe non orienté La contrainte {nonoriented} indique que l association est non orientée, donc que c est un graphe non orienté. L entité Ville contient un nom qui est unique. Ce type d association est appelée «association réflexive». Il n est pas possible, dans ce cas, de créer une entité sur l association réflexive comme avec le modèle général. Cela implique qu il est impossible, à l heure actuelle, de générer des APIs de tables pour l association (qui deviendra table associative) route. JULIEN OGI PAGE 6 SUR 40

8 Après transformation du MCD du graphe non orienté on obtient le MLD/MPD suivant. Figure 5 MLD/MPD d un graphe non orienté Lors de la transformation d un MCD contenant une association réflexive en modèle logique de données, une table associative est créée. L association route devient une table dont la clé primaire est formée de la concaténation des deux clés étrangères qui référencent les deux villes se trouvant aux extrémités. [PSU-04] (p. 6) On peut constater qu une vue s est créée lors de la transformation. Elle sert à matérialiser les doubles liens de la table associative Routes. En effet comme il s agit d un graphe non orienté la table Routes devrait contenir dans une ligne le numéro de «Berne» dans sa colonne Vil_routeA_Numero et celui de «Neuchâtel» dans sa colonne Vil_routeB_Numero, mais aussi le chemin inverse. Et pour éviter de la redondance et de la confusion dans la table Routes on n insère qu une seule fois les données et la vue créera le double lien avec une requête d union. Un exemple sera plus clair : La table Villes contient deux lignes. Villes Numero Nom 1 Berne 2 Neuchâtel Table 1 Table Villes JULIEN OGI PAGE 7 SUR 40

9 On insère nos numéros de villes dans la table Routes. Routes Vil_routeA_Numero Vil_routeB_Numero 1 2 Table 2 Table associative Routes Le problème, si on n insère que cette ligne et qu on effectue une requête de sélection on obtiendra une réponse positive seulement dans le cas où l on associe les deux clés étrangères dans le même ordre que l insertion. SELECT COUNT(*) FROM Routes WHERE vil_routea_numero = 1 AND vil_routeb_numero = 2; Cela nous retournera la valeur 1 car il existe bien une route entre les deux villes. Si maintenant on inverse la condition : SELECT COUNT(*) FROM Routes WHERE vil_routea_numero = 2 AND vil_routeb_numero = 1; Cette fois on obtiendra la valeur 0. Et pourtant il existe bien une route entre les deux villes. Une solution consisterait à insérer le lien inverse en même temps dans la table Routes. Seulement cela génère de la confusion et de la redondance. C est pourquoi on utilise une vue pour matérialiser le double lien. Rte_INSTEADOFTAPIs Vil_routeA_Numero Vil_routeB_Numero Table 3 Vue Rte_INSTEADOFTAPIs Avec une telle solution, notre table Routes n aura bien qu un seul lien. Mais le problème maintenant est qu il sera nécessaire d interdire la saisie directe dans la table Routes et de passer uniquement par la vue, ce sera le travail du trigger Rte_TAPIs_NoDML. Il faudra également veiller à interdire l insertion d un lien inverse dans la table Routes, le trigger Rte_TAPIs_IOI effectuera ce travail. JULIEN OGI PAGE 8 SUR 40

10 4. SQL Server Microsoft SQL Server est un SGBD (Système de Gestion de Bases de Données) incorporant un SGBDR (SGBD Relationnel) créé par Sybase et Microsoft en 1989 et disponible sur les plateformes Unix et OS/2. Puis en 1994 le partenariat entre les deux entreprises est rompu mais Microsoft continue de commercialiser le moteur de base de données sous le nom de SQL Server et ne le rend compatible que pour Windows. De son côté, Sybase poursuit aussi la commercialisation d un SGBD mais sous le nom de Sybase Adaptive Server Entreprise. [WIKI-02] Microsoft SQL Server est en fait une suite composée de cinq services principaux 3 : Un moteur relationnel (OLTP) Un moteur décisionnel (OLAP) utilisé pour faire de la Business Intelligence Un ETL (Extract Transform Load) utilisé pour créer des flux de données dans le but d alimenter des entrepôts de données Un outil de génération d état permettant de fournir des rapports Un planificateur de travaux et de gestion d alerte appelé Agent SQL Ce travail est basé sur la version 2008 de SQL Server, sorti en août Deux autres versions sont sorties depuis, la version 2012 en avril 2012, la version 2014 en avril 2014 et la version 2016 est déjà disponible en version bêta. [WIKI-02] Evidemment le langage SQL est utilisé pour communiquer avec la base de données Le Transact-SQL Le Transact-SQL est une extension propriétaire de Sybase et Microsoft au langage SQL [WIKI-03]. Le Transact-SQL est à SQL Server ce que le PL/SQL est à Oracle. Grâce au Transact-SQL il est possible de définir des traitements procéduraux directement dans la base de données. On peut donc créer des procédures stockées, fonctions, triggers et variables entre autres. Ces éléments sont indispensables pour pouvoir créer nos APIs de table Les types de données Les types de données permettent de définir dans quel format la donnée sera stockée. [GAB-01] (p. 57) Il existe deux sortes de types de données 4 : les types de données système les types de données définis par l utilisateur 3 Selon [WIKI-02] 4 Selon [GAB-01] (pp ) JULIEN OGI PAGE 9 SUR 40

11 Les types de données système Ces types sont disponibles pour toutes les bases de données en standard. [GAB-01] (p. 57) Caractères CHAR[(n)] Chaîne de longueur fixe, de n caractères maximum. Par défaut 1, maximum VARCHAR(n max) Chaîne de caractères à longueur variable, de n caractères maximum. Par défaut 1, maximum 8000 caractères. En précisant max, la variable peut contenir jusqu à 2 31 caractères. Il est possible de préciser une chaîne de caractères Unicode en ajoutant la lettre N devant le type de données. [GAB-01] (pp ) Numériques DECIMAL[(p[,d])] Valeur numérique de précision p (nombre de chiffres total), avec d chiffres après la virgule. p est compris entre 1 et 38, par défaut 18. d est compris entre 1 et p, par défaut 0. Il existe encore le type NUMERIC qui est équivalent. Ces deux types de données ne sont présents que pour des raisons de rétrocompatibilité. [HOT-01] (p. 68) INT Nombre entier compris entre et Il existe d autre type de INT : BIGINT, SMALLINT et TINYINT. La différence entre ceux-ci est évidemment la plage de valeurs qui est plus ou moins grande. Les autres types numériques sont REAL et FLOAT[(n)], ce sont des types de données décimales approximatifs. Cela signifie qu ils sont imprécis, si par exemple on stocke la valeur 1.0 elle peut être stockée sous la forme ou Cela a pour conséquence d accumuler les erreurs d arrondi lors de chaque calcul. Ces deux types de données sont surtout utilisés pour stocker des nombres extrêmement grands. [HOT-1] (pp ) Il existe encore des types monétaires : MONEY (8 octets) et SMALLMONEY (4 octets). Dates et heures DATETIME et DATETIME2 Ces deux types permettent de stocker une date et une heure. DATETIME2 est plus précis (100ns) que DATETIME et a une plage de date plus grande ( à ). Les données sont stockées sur 4 ou 8 octets. Il existe aussi les types SMALLDATETIME et DATETIMEOFFSET. Le premier stocke une date et une heure sur 4 octets. Le second stocke les données au format UTC et le décalage horaire est conservé. Il est préférable de privilégier le type DATETIME2 à la place de DATETIME et SMALLDATETIME étant donné qu il apporte plus de précision et un meilleur respect des standards SQL. [GAB-01] (p. 60) Il est possible de spécifier le nombre de fractions de secondes en mettant un chiffre en parenthèses après le type de données, par défaut 7. JULIEN OGI PAGE 10 SUR 40

12 DATE TIME Permet de stocker une date comprise entre le à Permet de stocker une données de type heure inférieure à 24h00. Spéciaux Il existe encore d autres types de données spéciaux comme les types binaires qui permettent de stocker des images ou des documents XML mais ils ne sont pas abordés dans le cadre de ce travail Les types de données définis par l utilisateur Il est possible de définir ses propres types de données grâce à la commande CREATE TYPE. Un type ne pourra être supprimé s il est utilisé dans une table de la base où il a été créé. [GAB-01] (pp ) Exemple 5 : CREATE TYPE typ_nom FROM VARCHAR(50); Grâce à cette instruction il est également possible de créer des types TABLE. Chaque colonne qui participe à la définition de ce nouveau type est définie sur le même principe qu une colonne dans une table. Ainsi il est possible de définir des contraintes d intégrité de clé primaire (PRIMARY KEY), d unicité (UNIQUE), de validation (CHECK) et de non nullité (NOT NULL). Ces contraintes peuvent être définies au niveau de la colonne ou de la table. Il est également possible de définir une colonne de type identité (IDENTITY). L introduction de ce nouveau type va permettre de définir des paramètres de fonctions ou procédures de type tableau, on parle alors de table value parameter. [GAB-01] (pp ) CREATE TYPE typ_etudiants AS TABLE ( numero INT, mnemo CHAR(3), nom VARCHAR(50), prenom VARCHAR(50) ); Ce type de données est utilisable comme n importe quel autre tel INT, DATE, VARCHAR, etc. Il sera donc possible de l utiliser avec une variable Les table value parameter Il s agit d un nouveau type de paramètre introduit avec SQL Server Avec ce type de paramètre il est possible d envoyer un ensemble de données directement à une procédure ou bien à une fonction Transact-SQL. Pour mieux comprendre l intérêt des table value parameter, il est possible de rapprocher ce type de paramètre à la notion de tableau. Chaque ligne de ce tableau est définie par rapport à un 5 Les exemples ne correspondent pas forcément aux modèles de démonstration JULIEN OGI PAGE 11 SUR 40

13 type de données utilisateur. Ces types sont créés par l intermédiaire de l instruction CREATE TYPE qui permet maintenant de définir des types TABLE. Chaque champ est fortement typé grâce à l usage, entre autres, des contraintes d intégrité lors de la définition du type. Avec les table value parameter il est possible de gérer un ensemble structuré de données sans qu il soit nécessaire de créer une table, même temporaire. En ce sens, l utilisation de ces types permet de gagner en souplesse d utilisation et parfois même en performance. Cependant, les table value parameter sont toujours des paramètres en lecture seule. Donc, la procédure ou la fonction qui possède un paramètre de ce type ne peut modifier les informations présentes dans ce paramètre. L utilisation d un table value parameter peut se décomposer en trois étapes : Définir le type de chaque ligne à l aide de l instruction CREATE TYPE Compléter le table value parameter avec des données en utilisant les instructions du DML : INSERT, UPDATE, DELETE Appeler la fonction ou la procédure en lui passant en paramètre le table value parameter Dans la procédure ou la fonction qui possède un paramètre de ce type, les données sont extraites par l intermédiaire de requêtes SELECT ou bien par l utilisation d un curseur. [GAB-01] (p.332) 4.4. Les variables Une variable est une zone mémoire caractérisée par un nom et un type permettant de stocker une valeur. Les variables Transact-SQL doivent obligatoirement être déclarées avant leur utilisation. Elles peuvent ensuite remplacer n importe quelle expression dans les instructions SQL. [GAB-01] (p. 187) Pour les déclarer on utilise le mot-clé DECLARE suivi du nom de la variable et de son type. VARCHAR(30); typ_etudiants; On a maintenant deux variables nom et etudiant qui sont déclarées. Le caractère «@» est obligatoire. [GAB-01] (p. 187) La est de type typ_etudiants qui est un type TABLE. La déclaration d une telle variable n est donc pas différente de celle avec un type de données système. A noter qu il est aussi possible de déclarer des variables sur une seule ligne en les séparant par des virgules. [GAB-01] (p. 188) VARCHAR(30); JULIEN OGI PAGE 12 SUR 40

14 Pour affecter une valeur à une variable on utilise le signe «=». = nom FROM Etudiants WHERE mnemo = 'ABC'; La variable nom ci-dessus aura le nom de l étudiant qui a pour mnémonique ABC. À l exception des variables de table, toutes les autres variables contiennent une seule valeur. Bien qu il soit possible d assigner à une variable le résultat d une instruction SELECT, si plusieurs lignes sont retournées, on ne recevra pas d erreur. La variable contiendra uniquement la dernière valeur de l ensemble des résultats. Toutes les autres valeurs seront ignorées. [HOT-1] (p. 188) Il est aussi possible d affecter une valeur à une variable sans passer par un SELECT mais en utilisant le mot-clé SET. [HOT-1] (p. 187) = 'Dupont'; En plus des variables définies par l utilisateur il existe des variables système. Elles ne peuvent être utilisées qu en lecture. Elles se distinguent des variables utilisateur par le double «@». [GAB-01] (pp ) Il en existe une trentaine. Dans le cadre de ce travail une seule nous Renvoie l ID de session du processus utilisateur actuel. Permet d identifier l utilisateur. [MIC-01] Les tables Les tables permettent d organiser logiquement les données au sein de la base de données. Afin de structurer les données, chaque table contient des colonnes où seront rangées les données. Ces colonnes ont un nom qui est unique dans la table ainsi qu un type de données. La cohérence des données est respectée grâce aux contraintes d intégrité. [GAB-01] (pp ) CREATE TABLE Etudiants ( numero INT, mnemo CHAR(3), nom VARCHAR(50), prenom VARCHAR(50) ); JULIEN OGI PAGE 13 SUR 40

15 4.6. Les vues Les vues ressemblent aux tables et ont la même utilisation que ces dernières si ce n est qu elles ne contiennent pas de données mais uniquement la requête correspondant à l extraction des données. On peut dire qu une vue est une table virtuelle. [GAB-01] (p. 180) Les vues ont plusieurs intérêts 6 : Elles simplifient la structure des tables. Si une table contient beaucoup de colonnes avec des noms difficilement manipulables, la vue fournira à l utilisateur les mêmes données de façon simplifiée Si une même requête est souvent exécutée la vue permettra de stocker l instruction et de l utiliser plus simplement Il est possible de cacher des lignes et des colonnes aux utilisateurs avec les vues, permettant ainsi une sécurité d accès La modification des données d une vue n est pas possible si plus d une table est modifiée et si la requête de la vue utilise des calculs. [GAB-01] (p. 181) CREATE VIEW Rte_INSTEADOFTAPIs AS SELECT villes_routea_numero, villes_routeb_numero FROM Routes UNION SELECT Villes_routeB_numero, Villes_routeA_numero FROM Routes; 4.7. Les contraintes d intégrité La clé primaire Une clé primaire permet d identifier de manière unique chaque ligne d une table. Pour en déclarer une on utilise le mot-clé PRIMARY KEY. On peut éventuellement lui attribuer un nom de contrainte, SQL Server en donnera un par défaut si on ne le fait pas. Les colonnes définissant la clé primaire doivent être NOT NULL. Il ne peut évidemment n y avoir qu une clé primaire par table, mais elle peut contenir jusqu à seize colonnes. [GAB-01] (pp ) CREATE TABLE Etudiants ( numero INT NOT NULL, mnemo CHAR(3), nom VARCHAR(50), prenom VARCHAR(50), CONSTRAINT PK_Etudiants PRIMARY KEY(numero) ); 6 Selon [GAB-01] (p. 180) JULIEN OGI PAGE 14 SUR 40

16 Dans notre cas la contrainte de clé primaire a comme nom PK_Etudiants et est définie sur la colonne numero L incrémentation Il n est pas nécessaire d utiliser une séquence, contrairement à Oracle, pour incrémenter automatiquement la clé primaire d une table. Il existe une propriété, appelée IDENTITY, qui laisse le système générer des valeurs pour la colonne lors de l insertion d une ligne, il n est donc plus obligatoire de préciser une valeur lors d un INSERT. Il est possible de spécifier la valeur de départ ainsi que l incrément, par défaut ces valeurs valent respectivement 1 et 1. Il ne peut n y avoir qu une seule colonne IDENTITY par table et la propriété ne peut être affectée qu à une colonne numérique entière. [GAB-01] (pp ) CREATE TABLE Etudiants ( numero INT IDENTITY(1,1) NOT NULL, mnemo CHAR(3), nom VARCHAR(50), prenom VARCHAR(50), CONSTRAINT PK_Etudiants PRIMARY KEY(numero) ); La valeur de la colonne numero commencera à 1 et sera incrémentée de 1 à chaque nouvelle insertion dans la table Etudiants. Il existe une variable globale qui permet de stocker la dernière valeur générée au cours de la session courante. Il est aussi possible de connaître la dernière valeur d identité générée sur une table avec la fonction IDENT_CURRENT, quelles que soient les sessions. Tandis que la fonction SCOPE_IDENTITY permet d effectuer le même type de travail mais limite la portée au seul lot d instructions courant. [GAB-01] (p. 76) La contrainte NOT NULL Pour définir une colonne dont la valeur est obligatoire, on utilise le mot-clé NOT NULL. Il est conseillé de toujours préciser si la colonne est NULL ou pas car la valeur par défaut dépend de certains facteurs. [GAB-01] (pp ) CREATE TABLE Etudiants ( numero INT IDENTITY(1,1) NOT NULL, mnemo CHAR(3) NOT NULL, nom VARCHAR(50) NULL, prenom VARCHAR(50) NULL, CONSTRAINT PK_Etudiants PRIMARY KEY(numero) ); JULIEN OGI PAGE 15 SUR 40

17 La contrainte UNIQUE Pour signaler qu une colonne ne doit contenir que des valeurs uniques il existe la contrainte UNIQUE. Pour rendre le mnemo de la table Etudiants ci-dessus unique on utilise la commande ALTER TABLE qui permet de modifier une table. ALTER TABLE Etudiants ADD CONSTRAINT UK_Etudiants_Mnemo UNIQUE(mnemo); L instruction ADD CONSTRAINT permet l ajout d une contrainte La contrainte CHECK Cette contrainte permet de restreindre la plage de valeurs autorisées dans une colonne d une table. [HOT-01] (p ) Imaginons que nous ayons une table de produits dans laquelle on peut entrer le prix de la marchandise, ce prix doit être supérieur ou égal à 0. ALTER TABLE Produits ADD CONSTRAINT CK_Produits_Prix CHECK(prix >= 0); La colonne prix ne pourra contenir une valeur inférieure à La contrainte DEFAULT Elle permet de préciser automatiquement la valeur que prendra la colonne si l utilisateur n entre aucune information. Par contre si l utilisateur insère une donnée dans la colonne, la valeur par défaut n aura aucun effet et n écrasera pas l information insérée. [GAB-01] (p. 87) ALTER TABLE Etudiants ADD CONSTRAINT DF_Etudiants_Nom DEFAULT 'Personne' FOR nom; Si l étudiant n entre pas son nom la colonne aura comme valeur Personne La clé étrangère Cette contrainte permet de faire le lien entre deux tables en référençant la clé primaire ou secondaire d une des deux tables par le biais d une colonne. Dans notre cas, c est la table Inscrire qui fait le lien entre les tables Etudiants et Cours. Les deux colonnes Etu_Inscrire_Numero et Crs_Inscrire_Numero sont des clés étrangères 7, la première référence la table Etudiants tandis que la deuxième référence la table Cours. 7 Ce cas est un peu spécial car ce sont aussi des clés primaires JULIEN OGI PAGE 16 SUR 40

18 ALTER TABLE Inscrire ADD CONSTRAINT FK_Inscrire_Etudiants FOREIGN KEY(Etu_Inscrire_Numero) REFERENCES Etudiants(numero); 4.8. Les triggers Aussi appelés déclencheurs, ils permettent d exécuter du code lors de la manipulation de données. SQL Server propose deux triggers, AFTER (par défaut) et INSTEAD OF. Le trigger AFTER s exécute après vérification des contraintes d intégrité et modifications des données tandis que le trigger INSTEAD OF s exécute à la place de l ordre SQL déclencheur. [GAB-01] (p. 236) CREATE TRIGGER tri_etudiants ON Etudiants AFTER INSERT AS BEGIN Instructions SQL END; Si l instruction SQL échoue alors le déclencheur n est pas exécuté. Les déclencheurs de type AFTER peuvent être posés uniquement sur les tables, il n est pas possible de poser de tels déclencheurs sur les vues. Il est possible de créer plusieurs déclencheurs AFTER sur une table et pour un même ordre SQL (INSERT, UPDATE ou DELETE) de déclenchement. Si plusieurs déclencheurs existent sur une table, la procédure stockée sp_settriggerorder permet de fixer le déclencheur qui s exécutera en premier et celui qui s exécutera en dernier. Les autres déclencheurs s exécuteront suivant un ordre non maîtrisable. Si la table possède une action en cascade il n est plus possible de poser un trigger INSTEAD OF sur ladite table! SQL Server autorise la récursivité des triggers si l option de base de données recursive triggers a été activée. Parmi les récursivités possibles, il faut distinguer la récursivité directe de la récursivité indirecte. [GAB- 01] (p. 238) Si la récursivité directe est activée, elle autorise à ce que le déclencheur soit à nouveau exécuté s il existe une requête susceptible de le faire dans son corps. Par exemple si dans les instructions SQL du trigger ci-dessus il y a une requête d insertion dans la table Etudiants, celui-ci se déclencherait une nouvelle fois. [GAB-01] (p. 238) La récursivité directe est gérée par le paramètre de base de données recursive_triggers. [MIC-02] La récursivité indirecte est gérée par le paramètre de serveur nested_triggers de la procédure sp_configure. Si elle est activée, elle permet par exemple que deux déclencheurs sur deux tables différentes s appellent entre eux. Si dans le trigger ci-dessus se trouve une requête déclenchant une insertion dans la table Cours et que le déclencheur associé déclenche à son tour une insertion dans la JULIEN OGI PAGE 17 SUR 40

19 table Etudiants, le déclencheur de cette dernière redéclenche l insertion dans la table Cours et ainsi de suite. [GAB-01] (p. 239) Si la récursivité indirecte est désactivée, la récursivité directe l est aussi, quel que soit la valeur du paramètre recursive_triggers. [MIC-02] Il existe encore d autres options pour les triggers qui ne seront pas abordées Les tables INSERTED et DELETED Ces tables sont créées lors de chaque modification de données et peuvent être utilisées dans les triggers ou directement dans le cadre d une instruction INSERT, UPDATE, DELETE ou MERGE en utilisant la clause OUTPUT [HOT-1] (p. 167). Elles ont la même structure que la table modifiée. Lors d une insertion, la table INSERTED contiendra les lignes créées. Pour une suppression c est la table DELETED qui contiendra les lignes supprimées. Et pour une mise à jour la table INSERTED contiendra les lignes contenant les modifications (correspond au :new d Oracle) et la table DELETED les lignes à modifier (correspond au :old d Oracle). [GAB-01] (p. 239) Pour représenter l utilisation de ces deux tables, on va prendre pour exemple l insertion, la modification et la suppression d une donnée dans la table Etudiants. Insertion On insère donc des données dans la table Etudiants. INSERT INTO Etudiants(mnemo, nom, prenom) VALUES('PDU', 'Dupont', 'Paul'); On vérifie les données de la table INSERTED (cette vérification se fait dans un trigger par exemple) : SELECT * FROM INSERTED; INSERTED Mnemo Nom Prenom PDU Dupont Paul Table 4 - Table INSERTED après un SELECT Nos données sont bien présentes dans la table INSERTED. La table DELETED est vide. Mise à jour Maintenant on change le nom de Dupont en Dubridge. UPDATE Etudiants SET nom = 'Dubridge' WHERE mnemo = 'PDU'; JULIEN OGI PAGE 18 SUR 40

20 On vérifie les données de la table INSERTED : SELECT * FROM INSERTED; INSERTED Mnemo Nom Prenom PDU Dubridge Paul Table 5 - Table INSERTED après un UPDATE Les nouvelles valeurs sont présentes dans la table INSERTED. On vérifie les données de la table DELETED : SELECT * FROM DELETED; DELETED Mnemo Nom Prenom PDU Dupont Paul Table 6 - Table DELETED après un UPDATE Tandis que les anciennes valeurs sont disponibles dans la table DELETED. Suppression Et si on supprime notre étudiant. DELETE FROM Etudiants WHERE mnemo = 'PDU'; On vérifie les données de la table DELETED : SELECT * FROM DELETED; DELETED Mnemo Nom Prenom PDU Dubridge Paul Table 7 - Table DELETED après un DELETE Nos données supprimées se retrouvent bien dans la table DELETED. Lors d une suppression de plusieurs données en même temps, toutes les données supprimées sont présentes dans la table DELETED. La table INSERTED est vide Les fonctions Les fonctions qui nous intéressent ici sont celles qu il est possible de définir soi-même. Evidemment il existe une multitude de fonctions proposées en standard par SQL Server pour manipuler les chaînes de caractères, les nombres, dates et autres. JULIEN OGI PAGE 19 SUR 40

21 Il existe trois types de fonctions utilisateurs 8 : Les fonctions scalaires Les fonctions tables en ligne Les fonctions tables multi-instructions Le premier type de fonction retourne une valeur scalaire. Les deux autres types retournent une table. Pour retourner un résultat on utilise le mot-clé RETURN. Les types de données TIMESTAMP, définis par l utilisateur, d un type TABLE, curseur, TEXT, NTEXT et IMAGE ne peuvent être retournés. Les fonctions ont un champ d action limité, il n est possible de modifier que des objets locaux à la fonction. Il est donc impossible de modifier une table de la base de données depuis une fonction par exemple. [GAB-01] (pp ) Fonctions scalaires CREATE FUNCTION fun_etudiants_sca(@mnemo CHAR(3)) RETURNS VARCHAR AS BEGIN VARCHAR(50); = nom FROM Etudiants WHERE mnemo END; La fonction retourne le nom de l étudiant selon son mnémonique. Fonctions tables en ligne CREATE FUNCTION fun_etudiants_lig(@nom VARCHAR(50)) RETURNS TABLE AS RETURN (SELECT mnemo, prenom, nom FROM Etudiants WHERE nom Cette fonction retourne une table avec tous les étudiants qui ont le même nom. Une telle fonction ne contient qu une instruction SELECT. [HOT-1] (p. 201) Fonctions tables multi-instructions CREATE FUNCTION fun_etudiants_mul(@nom CHAR(3)) TABLE ( numero INT, mnemo CHAR(3), nom VARCHAR(50), prenom VARCHAR(50) ) AS 88 Selon [GAB-01] (pp ) JULIEN OGI PAGE 20 SUR 40

22 BEGIN INSERT mnemo, nom, prenom) SELECT numero, mnemo, nom, prenom FROM Etudiants WHERE nom END; RETURN; La liste des étudiants ayant le même nom sera retournée. Les fonctions table peuvent ensuite être appelées depuis la clause FROM d une requête tandis que pour les fonctions scalaires le mot-clé SELECT suffit. [GAB-01] (p. 230) SELECT * FROM fun_etudiants_lig('dupont'); -- fonctions table SELECT fun_etudiants_sca('pdu'); -- fonctions scalaires Les types TABLE définis par l utilisateur ne peuvent pas être modifiés dans une fonction, c est pourquoi il faut spécifier le paramètre READONLY dans les paramètres de la fonction. [MIC-03] CREATE FUNCTION fun_etudiants_typ(@etudiants typ_etudiants READONLY) Corps de la fonction Les procédures Les procédures sont similaires aux fonctions. Elles prennent un à plusieurs paramètres en entrées et peuvent retourner une valeur. Elles peuvent être appelées grâce à l instruction EXECUTE ou EXEC. Elles sont stockées dans le cache mémoire lors de leur première exécution, ce qui permet d accroître les performances pour les appels suivants. Il est également possible de créer des procédures temporaires pour une ou plusieurs sessions. Pour créer une procédure on utilise l instruction CREATE PROCEDURE ou CREATE PROC. [GAB-01] (p. 223) CREATE PROCEDURE CHAR(3) AS Corps de la procédure Si on ajoute le signe «#» devant le nom de la procédure cela signifie qu elle sera temporaire locale, avec «##» elle sera temporaire globale. [GAB-01] (p. 224) JULIEN OGI PAGE 21 SUR 40

23 Si on désire retourner une valeur, on ajoute l instruction OUTPUT à la déclaration de la procédure. [MIC-04] CREATE PROCEDURE VARCHAR(30) OUTPUT AS = nom FROM etudiants WHERE mnemo Cette procédure retourne le nom de l étudiant correspondant au mnémonique passé en paramètre. Les parenthèses dans la déclaration des paramètres des procédures ne sont pas obligatoires. Les procédures contrairement aux fonctions autorisent les instructions DML (INSERT, UPDATE et DELETE) Les schémas Tous les objets d une base de données sont créés dans un schéma. Un schéma fournit un moyen de regrouper des objets, mais offre aussi une limite de sécurité. [HOT-01] (p. 64) Les schémas SQL Server sont des espaces de noms qui facilitent la séparation des objets et améliorent la sécurité. Ce sont des containers où il est possible de stocker des objets de la base de données. Un schéma n est pas équivalent à un utilisateur 9 et un utilisateur peut avoir plusieurs schémas. On peut par exemple regrouper tous les objets (tables, fonctions, procédures, etc.) par département d une entreprise. [NET-01] Pour créer un schéma on utilise l instruction CREATE SCHEMA. [HOT-01] (p. 65) CREATE SCHEMA Etudiants_TAPIs AUTHORIZATION user; Et pour affecter un objet à un schéma on ajoute le nom du schéma avant le nom de l objet et on sépare le tout par un point. CREATE FUNTION Etudiants_TAPIs.fun_etudiants_sca(@mnemo CHAR(3)) Corps de la fonction La fonction fun_etudiants_sca appartient au schéma Etudiants_TAPIs Les blocs d instructions Les blocs d instructions permettent de regrouper logiquement des instructions Transact-SQL. Ils permettent d entourer une série d instructions qui sera exécutée en même temps. Pour commencer un bloc d instructions, on utilise le mot-clé BEGIN et pour le terminer le mot-clé END. [MIC-05] 9 Contrairement à Oracle JULIEN OGI PAGE 22 SUR 40

24 BEGIN Bloc d instructions END Ils sont surtout utiles dans le cas des boucles, des conditions et pour définir le corps des triggers, procédures ou fonctions Les transactions Le premier point à prendre en considération est le verrouillage des informations. En effet, lorsque SQL Server lit des données ou les modifie, il verrouille les lignes d informations manipulées. Ce verrouillage dure le temps de l exécution de l instruction ou le temps de la transaction. Suivant le type de verrous posés, il est possible ou non à d autres transactions d accéder simultanément à la même information. Une transaction est un ensemble d instructions de manipulations de données s exécutant dans une même unité de travail. La validation d une transaction assure que toutes les instructions en faisant partie se sont correctement terminées, l annulation de la transaction assurera l annulation de l ensemble des instructions. Seules les instructions du DML (SELECT, INSERT, UPDATE, DELETE) sont prises en compte dans une transaction. Les transactions sont utiles pour assurer l intégrité et la cohérence des données lors de modifications multiples, pour améliorer les performances, pour tester les effets de modification, pour gérer les verrouillages. Une transaction est caractérisée par le mot clé ACID (Atomicity Consistency Isolation Durability) qui peut se traduire en français par Atomique Consistance Indépendance Durée. Atomique car une transaction représente une unité atomique (non divisible) de travail pour le serveur Consistance car à la fin de la transaction les informations présentes dans la base doivent être consistantes, c est-à-dire cohérentes par rapport aux règles de structuration des données mises en place Indépendance car les données visibles sont, soit celles d avant la transaction, soit celles résultantes de la transaction. Il n est pas possible, depuis une autre transaction, de visualiser les données en cours de modification dans une transaction Durée car lorsqu une transaction est validée, les changements apportés par la transaction sur les données sont durables et le gestionnaire de base de données doit garantir que, quoi qu il arrive au niveau du système, ces changements seront toujours visibles. [GAB-01] (pp ) Pour commencer une transaction on utilise le mot-clé BEGIN TRAN, pour la valider COMMIT TRAN et pour l annuler ROLLBACK TRAN. [GAB-01] (p. 193) JULIEN OGI PAGE 23 SUR 40

25 BEGIN TRAN Instructions SQL COMMIT TRAN Les instructions SQL sont validées. BEGIN TRAN Instructions SQL ROLLBACK TRAN Les instructions SQL sont annulées Durant une transaction on n a pas accès aux tables tant que la transaction n est pas validée ou annulée. Si les commandes BEGIN, COMMIT TRAN et ROLLBACK TRAN ne sont pas utilisées SQL Server crée une transaction implicite et valide la transaction lui-même. [HOT-01] (p. 168) L instruction GO Signale la fin d un lot d instructions Transact-SQL aux utilitaires SQL Server. GO n est pas une instruction Transact-SQL, mais une commande reconnue par les utilitaires sqlcmd et osq 10 l et par l éditeur de code SQL Server Management Studio. Les utilitaires SQL Server interprètent GO comme le signal qu ils doivent envoyer le lot actuel d instructions Transact-SQL à une instance de SQL Server. Le traitement en cours se compose de toutes les transactions entrées depuis la dernière commande GO ou depuis le début de la session ou du script s il s agit de la première commande GO. Une instruction Transact-SQL ne peut pas se trouver sur la même ligne qu une commande GO. Toutefois, la ligne peut contenir des commentaires. Les applications basées sur ODBC ou sur les API OLE DB reçoivent une erreur de syntaxe s ils tentent d exécuter une commande GO. Les utilitaires SQL Server n envoient jamais de commande GO au serveur. [MIC-06] Le dbo Le dbo dans SQL Server représente le «Database Owner» et est un utilisateur qui a l autorisation d effectuer toutes les activités sur la base de données. Tout membre du rôle fixe sysadmin utilisant une base de données est mappé à l utilisateur spécial dbo. Tout objet créé par un membre de sysadmin appartient automatiquement à dbo. [MIC-07] 10 Ce sont deux utilitaires en ligne de commande JULIEN OGI PAGE 24 SUR 40

26 Si par exemple Paul est membre de sysadmin et crée une table Table1, alors la table appartiendra à dbo et non à Paul et est désignée par dbo.table1. À l inverse si Paul ne fait pas partie de sysadmin alors la table lui appartiendra et est désigné par Paul.Table1. [MIC-07] Le CLR SQL Server est en mesure de gérer des données de plus en plus complexes mais il se doit également d offrir la possibilité de définir sur le serveur des traitements de plus en plus précis et parfois complexes. Ceci afin de fournir toujours plus de fonctionnalités. Dans certains cas, le langage Transact-SQL ne permet pas de définir le traitement voulu. Grâce à l intégration du CLR (Common Language Runtime).Net directement dans le moteur de base de données, il est possible de programmer des traitements à l aide de C# ou bien VB.Net. Pour que les méthodes et procédures ainsi définies soient utilisables depuis les instructions SQL un mappage Transact-SQL avec le code MSIL (MicroSoft Intermediate Language) est réalisé. [GAB-01] (p. 349) La question qui se pose maintenant est : quel langage privilégier? En fait tout dépend du travail à réaliser. Le Transact-SQL sera plutôt utilisé pour 11 : Un accès intensif aux données Manipuler des colonnes définies avec des types lourds (poids > 8 Ko) Lorsque le déploiement sera réalisé sur une ancienne version de SQL Server. Tandis que le CLR sera choisi pour 12 : Valider les données et réduire le trafic réseau Définir des fonctions ayant une portée générale Passer des données en paramètres Il n y a peu ou pas d accès à l information dans la base de données Réaliser des calculs complexes Réaliser des calculs d agrégat ou travailler avec des types scalaires Tirer profit de la puissance des langages.net Remplacer les procédures stockées étendues, ou plus exactement pour en écrire de nouvelles car les CLR offrent une souplesse en terme d écriture grâce au code contrôlé. Le CLR permet de produire un code plus optimisé et donc plus performant en s appuyant sur la richesse des langages tels que C# ou VB.Net. Il permet également ses propres types de données structurés. [GAB-01] (p. 350) 11 Selon [GAB-01] (pp ) 12 Selon [GAB-01] (p. 350) JULIEN OGI PAGE 25 SUR 40

27 5. Plugin Le plugin et sa structure était déjà existant avant le début de ce travail, de ce fait tous les éléments visibles à la Figure 8 étaient déjà présents. Dans les figures suivantes les éléments en grisés sont des éléments ne concernant pas directement le travail, nous n entrerons donc pas dans le détail de fonctionnement de ceux-ci Processus global C est la méthode runmvccd De la classe MCDToMLDTransformer du package services qui réalise le processus global de transformation. [SBE-01] (p. 5) Figure 6 Processus global de transformation [SBE-01] (p. 5) Les activités executebeforeall et executeafterall effectuent des traitements préparatoires ou de finalisation comme le chargement du fichier plugin.properties par exemple. L activité selectpreferences amène l utilisateur à choisir les préférences de transformation à l aide d une interface. La troisième activité récupère tous les éléments devant être traités par le plugin. checkmcd charge le MCD en mémoire et en vérifie la conformité. La méthode retourne la gravité la plus haute si des erreurs sont décelées 14. Même si des erreurs de type IGNORE et SUBSTITUTE sont retournées la transformation se fera car elles peuvent être corrigées automatiquement. L activité printallmodels se réalise quoi qu il arrive et permet de visualiser les différents graphes d objets en mémoire dans la console. [SBE-01] (pp. 5-6) 13 Nous sommes cependant bien d accord que ces éléments sont essentiels au bon fonctionnement du plugin. 14 Dans l ordre de gravité : IGNORE, SUBSTITUTE, ERROR, STOP [PSU-05] (p. 4) JULIEN OGI PAGE 26 SUR 40

28 L activité transformmcdtomld mérite d être plus détaillée. C est la méthode transformmcdtomld() de la classe MCDToMLDTransformer contenue dans le package services qui exécute le processus de la figure suivante. [SBE-01] (p. 6) Figure 7 Processus transformmcdtomld [SBE-01] (p. 6) À partir du MCD en mémoire créé par la méthode checkmcd(), la création du MLD à obtenir peut s opérer. Il s agit ici d instancier les classes du package mldmemory. Puis le MPD à obtenir est créé. Les classes du package mpdmemory sont instanciées. L activité suivante lit les éléments logiques du référentiel et instancie les classes correspondantes du package mldmemory. Ensuite les éléments physiques existants sont chargés en mémoire. La création du delta MLD instancie les adaptateurs qui permettent de relier les éléments du MLD existants avec ceux à obtenir. Et est créée une représentation des différences entre les MPD existants et à obtenir. Pour finir le delta entre les éléments existants et à obtenir est appliqué dans le référentiel de VP. La dernière étape est identique au point précédent mais cette fois les différences pour les éléments physiques sont appliquées. [SBE- 01] (pp. 6-7) Même si ce projet ne touche pas directement aux classes citées ci-dessus, il est quand même important pour le lecteur d avoir une vue d ensemble sur le processus global du plugin. JULIEN OGI PAGE 27 SUR 40

29 5.2. Le projet Le projet se présente selon la structure suivante : Figure 8 - Structure du projet MVC-CD Les dossiers qui nous intéressent ici sont src où on retrouve toutes les sources de notre programme. mld-r où se situe les différents templates et le fichier plugin.properties où sont définies les propriétés. JULIEN OGI PAGE 28 SUR 40

30 5.3. Les packages Si on développe le dossier src nous distinguons tous les packages du projet. Figure 9 Packages du projet 5.4. Les classes Si maintenant on s intéresse aux différents packages utilisés on découvre les classes qu ils contiennent. Package mcdtomld La classe MCDToMLD est chargée de la transformation du MCD en MLD. La méthode chargetypemapper nous intéressera tout particulièrement. Elle fait la correspondance entre les types de données MCD et ceux du MLD avec l aide de la classe TypeMapper. JULIEN OGI PAGE 29 SUR 40

31 Package mldmemory La classe MLDs permet de créer une instance de MLD «existant» et «à obtenir». Il sera nécessaire de séparer les fabricants (Oracle, SQL Server) dans le constructeur. La classe MLDTable représente une table. Les méthodes createtablejn et createcolsaudit nous intéresseront. La première crée une table de journalisation tandis que la seconde crée les colonnes d audit. Package mpdmemory La classe MPD s occupe d initialiser et de créer un MPD. Plusieurs méthodes sont utilisées pour ce projet : init, creatempd, createtrigger, createpackage et createview. La première initialise les constantes présentes dans le fichier de propriétés, la deuxième crée un MPD, la troisième les triggers, la quatrième les paquetages ou schémas et la dernière les vues. La classe MPDConstructor initialise les constructeurs (dans le sens des fabricants). Le constructeur et les méthodes createsqlservercoltypes, getsqlservercoltypes et createsqlservercoltype nous intéresseront. La première ajoute les différents types de données respectifs aux fabricants, la seconde est un accesseur et la dernière initialise les types de données. JULIEN OGI PAGE 30 SUR 40

32 Package mpdmemory.sqlserver Ce package a été entièrement créé et contient les éléments propres à SQL Server. Au final chaque SGBD devrait avoir un tel package. SqlserverBlockType référence les blocs de code qui pourront être utilisés dans le corps des schémas. SqlserverColType contient les types de données de SQL Server. SqlserverDynamicCodeType énumère les paramètres de code dynamique. SqlserverNameType contient les énumérations des paramètres de noms et indique le nom de la propriété se trouvant dans le fichier de propriétés pour chaque paramètre. SqlserverSchema contient l implémentation du code dynamique en lien avec les schémas. SqlserverSchemaType référence les templates des schémas. SqlserverTableJn crée les colonnes techniques de la table de journalisation. SqlserverTrigger contient l implémentation du code dynamique en rapport avec les triggers. SqlserverTriggerType référence les templates des triggers. SqlserverView crée la vue selon les modalités d un graphe non orienté. SqlserverViewType crée le template de la vue pour les graphes non orientés. Package services MPDExistantLoader gère le chargement des objets physiques de VP du repository dans le modèle du MPD en mémoire. Le constructeur devra être modifié pour distinguer les SGBDR. JULIEN OGI PAGE 31 SUR 40