Le 14 septembre 2017, nous avons publié une version actualisée de notre Politique de confidentialité. En utilisant video2brain.com vous vous engagez à respecter ces documents mis à jour. Veuillez donc prendre quelques minutes pour les consulter.

SQL Server 2016 pour les administrateurs IT

Explorer les vues de catalogue

TESTEZ LINKEDIN LEARNING GRATUITEMENT ET SANS ENGAGEMENT

Tester maintenant Afficher tous les abonnements
Tirez parti des vues de catalogue pour obtenir, grâce à des requêtes, des informations sur les objets de bases de données.
08:43

Transcription

Il y a des bases de données utilisateur, comme mon « PachaDataFormation », et il y a des bases de données système. Elles sont ici. À tout moment, lorsque, par exemple, on entre dans les tables, on a des sous-dossiers. Maintenant on a des tables externes parce qu'on peut se lier. Il y a certaines fonctionnalités qui sont nouvelles, mais, historiquement, on a toujours des tables système. Lorsque vous allez dans les vues, vous verrez également des vues du système. On n'a pas beaucoup de tables système, on a surtout maintenant des vues du système qui sont dans un schéma spécifique. En fait : deux schémas spécifiques. On a un schéma qui s'appelle « sys », et tous les objets qui sont dans le schéma « sys » sont des objets système. On a des vues qu'on appelle des vues de catalogue. Je vous fais une petite requête pour vous montrer. « SELECT * FROM sys. », et là je vais avoir la liste de toutes mes vues à disposition parce que Management Studio intègre une fonctionnalité d'IntelliSense, de saisie automatique. Je veux la liste des tables de ma base de données, donc « sys.tables ». C'est ce qu'on appelle une vue de catalogue parce qu'elle va aller chercher dans les tables système sous-jacentes, qui sont invisibles, intouchables. On doit passer par des vues. Cette vue va aller faire des requêtes dans les tables système sous-jacentes. On a une table système qui va donner la liste des tables. On a une table système qui donne la liste des colonnes de chaque table, et cetera. Je peux avoir ici la liste des tables, je peux avoir la liste des colonnes de mes tables, et cetera. Tout le catalogue, toute la structure est requêtable par SQL. C'était aussi une des règles qu'a édictée Edgar Codd, dans ses lois de code. Il n'y a qu'un seul langage pour interroger un moteur de bases de données relationnelles : c'est le langage relationnel, ici SQL. Toutes les informations du moteur de base de données sont stockées dans des tables. Les informations utilisateur, dans des tables utilisateur. Les informations système, dans des tables système. C'est simple, mais puissant également parce qu'on peut utiliser le même langage, « SELECT * FROM » etc., le langage SQL, pour interroger les structures, ce qui est quelque chose de très souple. On a un système qui est carré, très simple, avec un seul langage, et très puissant à la fois, parce que si je veux regarder quelles sont les colonnes qui s'appellent par exemple « Contact », je peux faire un « WHERE ». « WHERE », « name », nom de la colonne, je peux faire un « LIKE », donc je peux utiliser toutes les fonctionnalités du langage SQL pour manipuler les informations de catalogue. Je vais regarder « Contact », et je trouve qu'il y a un certain nombre de tables qui contiennent « ContactId », « Contact », « EmailContact », etc. Nous avons des vues de catalogue dans le schéma « sys ». Nous avons également des vues de catalogue qui sont dans un autre schéma et tout est inscrit en majuscules. La raison ici, c'est que la norme SQL, la norme ISO, indique également un certain nombre de vues de catalogue et les définit avec leurs colonnes dans la norme. Microsoft a implémenté ces vues pour respecter la norme. Vous avez ici une vue « sys.columns », qui est une vue purement SQL Server. Si vous utilisez cette requête dans MySQL, par exemple, ça ne fonctionnera pas. Vous avez ici des vues de catalogue qui vont donner, à peu de choses près, les mêmes résultats, je vous explique pourquoi je dis "à peu de choses près" dans une seconde, et qui, elles, sont portables. Si vous faites une requête comme ceci, parce que la norme SQL est, en général, assez bavarde, le schéma s'appelle « INFORMATION_SCHEMA ». C'est un peu lourd. Je vais le copier-coller ici. Je vais laisser d'ailleurs ces crochets, je vous explique dans une seconde. Si je fais cette requête, j'obtiens aussi une liste de colonnes mais dans un format légèrement différent. Ici, tout est en majuscules. Le nom des différentes colonnes est quelque chose qui est aussi défini dans la norme. Tout moteur de base de données qui respecte la norme va donner le même résultat. Cette requête, si je l'exécute, sans les crochets, dans MySQL, parce que MySQL ne connaît pas cette histoire de crochets, je vais obtenir la même liste dans MySQL si les tables sont les mêmes. Donc ça vous fait du code qui est portable. Il y a un avantage à ces vues d'informations de schéma de la norme par rapport aux vues système, c'est que dans les vues système, vous avez beaucoup d'informations internes. Vous avez, par exemple, l' « object_id », qui est l'identifiant de la table dans la table des objets. On a beaucoup d'informations internes, finalement, alors que la norme SQL, elle, ne s'inquiète pas de l'implémentation. Donc ici on a beaucoup d'informations, beaucoup plus lisibles, et qui sont plutôt logiques que physiques. On a directement les informations. Si je fais un « SELECT FROM sys.columns », j'obtiens l'« object_id ». Je ne sais pas quelle est la table, il faut que je fasse une jointure ou que j'utilise une fonction. J'ai juste le nom de la colonne. Par contre, si j'utilise cette vue d'informations de schémas, je vais avoir directement le nom du schéma de la table, le nom de la table, le nom de la colonne, le nom du catalogue. Donc ici j'ai le nom de la base, le schéma, la table, la colonne. Je peux manipuler ça beaucoup plus rapidement si je veux toutes les informations. Quand je dis manipuler, ça veut dire que, grâce à ces fonctionnalités, je peux très bien scripter ce genre de choses, je peux très bien utiliser maintenant la gestion de catalogue dans des scripts pour faire de l’administration. C'est vraiment très pratique. Un dernier mot sur ceci : « [ », « ] », les crochets. Qu'est-ce que ça veut dire ? Les crochets sont les symboles utilisés dans SQL Server pour délimiter les identifiants. Expliquons le vocabulaire. Si je créé une table, il faut bien que je donne ici un nom à ma table. Par exemple, je vais l'appeler « Ma Belle Table ». Sauf qu'ici j'ai un problème : j'ai mis des espaces. Je ne peux pas mettre des espaces dans un nom d'objet. Ce nom d'objet, c'est ce qu'on appelle un identifiant, et ce nom, c'est un identifiant. Les identifiants doivent respecter un certain nombre de règles, comme les variables dans un langage de programmation ou les classes dans un langage de programmation, c'est la même chose. La règle dans SQL Server, c'est qu'un identifiant ne peut pas commencer par un chiffre, il doit nécessairement commencer par une lettre. Vous voyez qu'il y a un petit signe rouge qui m'indique que j'ai tout faux. Il peut contenir des chiffres, mais pas en première position. On peut inscrire des lettres, des chiffres, mais pas en première position, des soulignés, et quelques caractères un peu particuliers à SQL Server, qui ne sont pas supportés dans d'autres moteurs comme MySQL ou Oracle. Par exemple, le signe « $ ». Ça, c'est vraiment des spécialités. Vous n'êtes vraiment pas obligé de mettre des « $ » dans vos noms de tables, mais c'est possible. Vous voyez que ça, ça passe. Si je fais maintenant une table qui s'appelle comme ceci, c'est accepté. Ce n'est pas beau, mais c'est accepté. Mais que se passe-t-il si j'ai envie de mettre des espaces ou des caractères spéciaux, par exemple « ~ » ou des choses comme ça ? C'est vraiment une mauvaise idée, mais je pourrais le faire. Il faut que je délimite. Le délimiteur ça veut dire : je mets quelque chose au début, quelque chose à la fin, pour dire : entre ce deux signes, il s'agit d'un identifiant, et j'accepte tout. Le délimiteur de la norme SQL, c'est : « " ». C'est tout à fait supporté dans SQL Server, vous voyez que ça va marcher. Mais vous avez un délimiteur propre à Transact-SQL, au SQL de SQL Server, qui n'est pas supporté dans les autres moteurs comme MySQL ou Oracle, qui est le « [ » au début et le « ] » à la fin. C'est un truc un peu particulier. Si vous ne faites que du SQL Server, vous pouvez mettre des crochets comme ceux-ci. Si vous voulez faire du code portable, il vaut mieux faire des « " » lorsque vous en avez besoin. C'est pour cette raison que, par sécurité, lorsque je glisse un objet ici, il est automatiquement protégé dans ses identifiants par des crochets, de façon à ne prendre aucun risque. Moi, je les enlève très souvent, mais c'est quelque chose qui est fait automatiquement par Management Studio.

SQL Server 2016 pour les administrateurs IT

Comprenez le fonctionnement et les différents modules qui composent SQL Server. Prenez en main les bases de données, les schémas, les tables, la gestion des fichiers, etc.

5h20 (55 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
Spécial abonnés
Date de parution :14 mars 2017

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !