Comprendre les Blocs de construction de base de données dans SQL Server
Chaque maison a une cuisine, au moins une salle de bain et une chambre à coucher, une porte d’entrée, un système de plomberie et d’autres choses. Ces choses peuvent être disposées de différentes manières et en différents nombres pour produire différentes maisons. C’est donc avec les bases de données. Il y a certaines choses que toutes les bases de données ont en commun. Dans cet article, je vais présenter les blocs de construction qui composent toutes les bases de données et montrer comment ils sont assemblés. Je discuterai également de trois règles à suivre lors de l’utilisation des blocs de construction.
Le matériel présenté dans cet article devrait être utile à toute personne ayant une interaction quelconque avec les bases de données, mais il est à un niveau très élémentaire. Pour une discussion plus complète sur la conception de bases de données, veuillez consulter mon article, Une approche intuitive de la conception de bases de données.
Mini-mondes.
Avant d’arriver aux blocs de construction, prenons un moment pour comprendre le terme mini-monde car cela nous aidera à comprendre les blocs de construction.
Une base de données est un modèle d’un mini-monde. Un mini-monde peut être un cabinet médical, un commerce de détail, une bibliothèque ou bien d’autres choses. Lorsque nous voulons des informations sur le mini-monde, nous nous tournons vers la base de données qui le modèle.
Disons que vous allez chez le médecin pour un rendez-vous. Lorsque vous dites à la réceptionniste que vous avez un rendez-vous, la réceptionniste essaiera de trouver votre rendez-vous dans le modèle (la base de données). Si le modèle a été maintenu à jour avec son mini-monde, il devrait pouvoir confirmer que vous avez bien un rendez-vous. De même, si une entreprise veut savoir lequel de ses clients à gros volumes n’a pas passé de commande au cours des 6 derniers mois, elle peut se tourner vers le modèle de son mini-monde s’il a été maintenu à jour avec ce mini-monde.
Un mini-monde peut être une entreprise entière, ou faire partie d’une entreprise, comme une succursale bancaire ou le service commercial.
La première chose qu’un concepteur de base de données fait est de comprendre le mini-monde, car le travail du concepteur consiste à concevoir un modèle de ce mini-monde. Et pour comprendre le mini-monde, le concepteur commence par identifier les éléments constitutifs qui serviront à l’assemblage d’une base de données.
Les blocs de construction
1. Entités
Une entité est quelque chose qui existe dans le mini-monde et qui a des caractéristiques qui nous intéressent. Par exemple, dans un mini-monde d’inscription scolaire, il existe des entités d’étudiants, des entités de cours, des entités d’instructeurs et d’autres. Les étudiants ont des noms, des adresses, des GPA et d’autres caractéristiques qui nous intéressent. Les cours ont des titres, des crédits, des frais et autres. Et les instructeurs ont des noms, des adresses, des qualifications et d’autres. Les entités sont uniques. Chaque élève est une entité unique; il y a John et Mary et ainsi de suite. Chaque cours est une entité unique et chaque instructeur est une entité unique.
Les entités ne doivent pas nécessairement être des choses physiques. Bien que vous ne puissiez pas toucher, voir ou sentir une inscription, elle existe néanmoins dans le mini-monde des inscriptions scolaires et présente des caractéristiques qui nous intéressent, telles que la date de l’inscription, l’étudiant qui s’est inscrit, le cours auquel l’étudiant s’est inscrit et la note finale reçue. Les ventes sont d’autres exemples d’entités qui n’ont pas de composant physique mais qui ont des caractéristiques qui nous intéressent (date de vente, client, vendeur, total de la commande, mode d’expédition, conditions de paiement, etc.).
2. Entity-Types
Les entités du même type appartiennent à un type d’entité. Un type d’entité est un ensemble d’entités de ce type. Le type d’entité étudiant est l’ensemble de tous les étudiants. Le type d’entité de cours est l’ensemble de tous les cours et le type d’entité d’instructeur est l’ensemble de tous les instructeurs.
Les types d’entités sont le concept le plus important de cet article. Ils deviennent des tables dans une base de données.
3. Attributs
Les attributs d’une entité sont les caractéristiques de cette entité qui nous intéressent. Comme déjà mentionné, les attributs des étudiants incluent le nom, l’adresse, le GPA et d’autres. Les cours ont des noms, des crédits, des départements auxquels ils appartiennent et d’autres. Et ainsi de suite avec d’autres types d’entités.
Assemblage des blocs de construction
Comment ces blocs de construction sont-ils représentés dans la base de données ? Chaque type d’entité est représenté par une table dans la base de données. Dans ce tableau, les lignes individuelles sont les entités uniques et les colonnes sont les attributs. Voici un exemple de table qui représente le type d’entité de carte de crédit:
Règles de blocs de construction
Lorsque vous travaillez avec des blocs de construction, il est important de suivre certaines règles qui non seulement facilitent le travail avec des objets de base de données, mais empêchent également les anomalies de données (les anomalies de données dépassent le cadre de cet article mais sont discutées en détail dans mon article, Une approche intuitive de la conception de base de données).
Règle 1 : Chaque table doit représenter un seul et unique type d’entité.
La base de données du mini-monde des inscriptions scolaires, ci-dessus, nécessite les tableaux suivants: Étudiant, Cours, Instructeur, Inscription et autres, un pour chaque type d’entité identifié dans ce mini-monde. La base de données du mini-monde du cabinet médical a besoin d’une table de médecin, d’une table de patient, d’une table de rendez-vous, d’une table de médicaments et autres. Une table pour chaque type d’entité.
Il existe une exception à cette règle. Préparez-vous, voici la tornade cérébrale: Si deux types d’entités partagent les mêmes attributs et qu’une entité de l’un des types d’entités est également une entité de l’autre type d’entité (une entité est membre des deux types d’entités), les deux types d’entités peuvent être représentés dans un tableau. Ici encore: un type d’entité de professeur et un type d’entité de conseiller peuvent tous deux être représentés dans un tableau, car les conseillers sont également des professeurs et ils ont les mêmes attributs (nom du professeur / conseiller, qualifications du professeur / conseiller, etc.). Et encore: Un type d’entité de dossier et un type d’entité de sous-dossier peuvent tous deux être représentés dans une seule table, car toutes les entités de sous-dossier sont également des entités de dossier et partagent les mêmes attributs (titre du dossier, taille du dossier, nombre d’éléments dans le dossier, dossier parent et autres). Un seul de plus : Les types d’entités Employé et Gestionnaire peuvent tous deux être représentés dans le même tableau, car les employés et les entités gestionnaire ont les mêmes attributs et les entités gestionnaire sont également des entités employé. Cette exception à la règle est examinée de plus près dans un autre blog : SQL Server – The Self Join Query.
Au fait, notez que cette règle est la raison pour laquelle la bonne façon de nommer une table est au singulier. Les tables représentent un seul type d’entité.
Règle 2 : Toutes les colonnes doivent être atomiques.
Vous êtes-vous déjà demandé pourquoi les tables de base de données pouvaient avoir des colonnes pour la ville et l’État, mais une seule colonne pour l’adresse? Peut-être vous êtes-vous demandé pourquoi il n’y a pas de colonne pour le numéro d’adresse, une autre pour le type de rue d’adresse (Blvd., Avenue, etc.), un autre pour le numéro d’appartement, et ainsi de suite. Pourquoi ces colonnes sont-elles généralement toutes regroupées en une seule colonne d’adresse ? La réponse à toutes ces questions réside dans la compréhension de l’atomicité.
Lorsque nous disons qu’une colonne est atomique, nous voulons dire qu’elle ne peut pas être subdivisée davantage et conserver un sens. Composons une colonne et appelons-la MegaAddress qui comprend une adresse postale avec la ville et l’État.
Mais comme nous effectuons des recherches, des tris et d’autres opérations sur des parties de cette colonne (recherche par ville, tri par état, impression uniquement de la partie adresse de rue, etc.), nous pouvons dire que les subdivisions de cette colonne ont leur propre signification (adresse de rue, ville et État). Donc, MegaAddress n’est pas atomique. Une meilleure table serait:
Maintenant, qu’en est-il de la colonne StreetAddress? Devrions-nous subdiviser cela plus loin en numéro de rue, nom de rue et type de rue? Tant que nous ne faisons rien de significatif avec ses subdivisions — si nous ne trions pas sur les numéros de rue, ne recherchons pas toutes les routes ou avenues, etc. —, la colonne est atomique telle quelle. Mais si nous faisons ces choses, alors la colonne n’est pas atomique et alors, oui, nous devrions la subdiviser comme décrit.
Règle 3 : Les colonnes ne peuvent pas être multivaluées.
Certains types d’entités contiennent des attributs à plusieurs valeurs ou un attribut pouvant avoir plusieurs valeurs. Dans une table de cours, il peut y avoir un attribut appelé Prérequis. Comme une entité de cours peut avoir plusieurs prérequis, l’attribut Prérequis est un attribut à valeurs multiples. Lorsque nous créons une table pour le type d’entité de cours, nous ne pourrons pas représenter l’attribut Prérequis sous forme de colonne dans la table. Pour représenter correctement un attribut multivalué, nous devrons créer une autre table pour celui-ci et le relier à la table d’origine en utilisant une relation un à plusieurs (les relations sont discutées en détail dans les cours que j’enseigne à Interface Tachnical Training SQL100: Introduction à Transact-SQL et SQL250: Transact-SQL pour les développeurs et dans mon article, Une approche intuitive de la Conception de bases de données). D’autres exemples d’attributs multivalués incluent les personnes à charge d’un employé, les qualifications d’un médecin, etc.
La règle 3 dit que, pour une entité donnée (ligne dans une table), il ne peut y avoir qu’une seule valeur dans chaque colonne.
Résumé
Cet article a introduit le concept du mini-monde en tant qu’aspects d’une entreprise ou d’un autre environnement qu’une base de données modélise. Le post a également décrit une table de base de données comme représentant un type d’entité unique dans lequel les lignes contiennent les entités individuelles du même type et les colonnes représentent les attributs de ces entités. Trois règles concernant les tableaux ont été introduites. La règle 1 stipule qu’une table doit représenter un seul type d’entité. L’exception à la règle est lorsque deux types d’entités partagent les mêmes attributs et que les entités d’un type d’entité sont membres de l’autre type d’entité. Dans ce cas, les deux types d’entités peuvent être représentés dans le même tableau. La règle 2 stipule que toutes les colonnes d’une table doivent être atomiques, ce qui signifie qu’une colonne ne peut pas être subdivisée et conserve son sens dans le mini-monde. Enfin, la règle 3 stipule que les colonnes d’une table ne peuvent pas être multivaluées, ce qui signifie que, pour une entité donnée (ligne dans une table), il ne peut y avoir qu’une seule valeur par colonne.
Profitez-en!
Peter Avila
Instructeur SQL Server – Formation technique d’interface
Phoenix, AZ
Attributs, Bases de données, Types d’entités, mini-monde, Sous-Dossier, valeurs
Leave a Reply