Vous vous sentez dépassé par le temps qu'il vous faudra pour apprendre à concevoir une base de données ? Découvrez les compétences et talents essentiels dont vous aurez besoin - ce n'est pas si terrible !
Quand vous déambulez dans les allées du supermarché, caddie dans une main et liste de courses dans l'autre, à quoi pensez-vous ? Si vous êtes comme moi, vous êtes en train d'imaginer comment améliorer l'organisation des rayons pour que vos courses hebdomadaires vous prennent moins de temps. Ou peut-être ressentez-vous le même désir d'organiser et de structurer l'information lorsqu'un ami vous montre sa grande collection de magazines. Ou peut-être que cela frappe lorsque vous gérez vos listes de lecture pour mieux répondre à vos préférences. Si vous passez votre vie à réfléchir à la manière de représenter la réalité en termes d'entités, d'attributs et de relations, alors votre vocation est d'être un modélisateur de bases de données.
Peut-être que vous n'êtes pas aussi extrême, mais vous êtes toujours attiré par l'idée de faire carrière dans la conception de bases de données. Dans tous les cas, vous devrez maîtriser quelques nouvelles compétences. Certains d'entre eux sont purement techniques; vous pouvez acquérir ces compétences en étudiant ou en lisant et les approfondir grâce à une expérience de travail. D'autres compétences impliquent des connaissances non techniques que vous pouvez acquérir par le biais de cours, d'articles de blog ou en observant les autres.
Voici un résumé des connaissances et compétences essentielles que tout concepteur de base de données doit posséder.
Les concepteurs de bases de données de compétences techniques ont besoin
Les compétences techniques sont celles qui sont acquises par l'étude et perfectionnées par la pratique. Si vous pouvez démontrer avec des preuves concrètes que vous maîtrisez une compétence difficile, cela signifie que vous êtes capable d'effectuer n'importe quelle tâche qui l'implique.
En termes de connaissance des bases de données, les compétences techniques incluent les principes fondamentaux de la théorie des bases de données et les différentes techniques utilisées pour appliquer des concepts théoriques pour résoudre des problèmes concrets. Examinons chacune des compétences techniques dont les concepteurs de bases de données ont besoin.
Théorie des bases de données
La théorie des bases de données regorge de concepts abstraits qui peuvent être difficiles à comprendre s'ils ne sont pas associés à des faits réels. Le modèle relationnel, les domaines, les attributs, les relations et les relations, les clés primaires et étrangères, l'intégrité de l'entité, l'intégrité référentielle et les contraintes de domaine ne sont que quelques exemples. Si vous ajoutez des matières encore plus complexes (comme l'algèbre relationnelle ou le calcul relationnel), vous vous demandez peut-être s'il ne serait pas préférable de choisir une carrière traitant de choses concrètes comme le jardinage ou la cuisine gastronomique.
Ne pas paniquer. Une connaissance approfondie de la théorie des bases de données est importante si vous envisagez d'enseigner à des cours universitaires ou d'inventer une nouvelle façon d'organiser l'information. Mais pour concevoir des bases de données, il vous suffit de maîtriser les concepts théoriques qui s'appliquent à la résolution de problèmes réels. Le plus important - l'ABC de la conception de bases de données - est le modèle relationnel.
Le modèle relationnel
Les professeurs du Collège vous diront que le modèle relationnel est un mécanisme d'organisation des données basé sur la théorie des ensembles et la logique des prédicats. Mais cela ne vous apportera pas grand-chose dans votre travail quotidien de modélisateur de base de données. En pratique, vous devez savoir que le modèle relationnel est un moyen intuitif et simple d'organiser les données sous forme de tableaux – appelées relations – qui sont composées de lignes (également appelées tuples). Chaque table (ou relation) est définie par ses attributs (ou colonnes).
Concepts fondamentaux du modèle relationnel.
Toutes les relations doivent avoir un ou plusieurs attributs exceptionnels qui représentent un identifiant unique pour chaque tuple. En argot de base de données, c'est la clé de la table. Les attributs non clés dépendent de la clé dans le sens où chaque valeur de clé détermine une seule valeur possible pour chaque attribut.
Imaginez un tableau d'informations sur le véhicule dans lequel la clé est la plaque d'immatriculation. La plaque d'immatriculation détermine les attributs de chaque véhicule (tels que le fabricant, le modèle, le propriétaire, etc.), puisque les règles du domaine empêchent deux véhicules différents de partager la même plaque d'immatriculation.
Bases de données relationnelles
Les systèmes de gestion de bases de données relationnelles (SGBDR) implémentent le modèle relationnel en respectant ses principes. Ils offrent des moyens de récupérer des informations via des requêtes et de mettre à jour des informations via des transactions. Pour que les informations d'une base de données relationnelle reflètent des faits et des situations réels, vous pouvez définir des conditions ou des contraintes spécifiques au domaine auquel la base de données s'applique. Par exemple, dans une table qui stocke des informations sur les élèves de l'école, une contrainte peut être imposée afin que les dates de naissance n'autorisent pas de dates futures ou trop éloignées dans le passé.
L'organisation des tables dans une base de données est communément appelée schéma de base de données. En plus des tables, le schéma détaille les contraintes impliquant des paires de tables appelées relations. Une relation relie deux tables en imposant la contrainte que les valeurs du champ de l'une des tables correspondent aux valeurs de la clé primaire de l'autre table.
Les schémas de base de données sont généralement représentés par le diagramme entité-relation (ERD), un outil courant pour tout concepteur de base de données.
Un ERD représentant un modèle de données client.
Anomalies et normalisation
Tous les concepts dont nous avons discuté jusqu'à présent sont assez clairs, n'est-ce pas ? Nous pouvons maintenant parler des anomalies qui se produisent dans les bases de données en raison d'une conception défectueuse ou inadéquate (c'est-à-dire que la base de données ne reflète pas adéquatement la réalité qu'elle essaie de représenter).
Les anomalies se produisent lorsqu'une opération d'insertion, de mise à jour ou de suppression génère des incohérences dans les données. Par exemple, supposons que vous disposiez d'une table pour stocker des données sur les ventes. Pour chaque vente (c'est-à-dire dans chaque enregistrement de la table), le nom et l'adresse des clients sont enregistrés. L'anomalie est la suivante :
- Si l'adresse du client est modifiée dans l'une des ventes, et
- Le même client a d'autres ventes,
- Les autres ventes auront une adresse obsolète.
Pour éviter les anomalies, vous pouvez appliquer une technique de conception appelée normalisation de la base de données. Cela implique de décomposer les tableaux et les colonnes (c'est-à-dire de les diviser en parties plus petites) pour éviter les défauts de conception tels que :
- Colonnes contenant plusieurs informations (par exemple, le numéro d'identification d'un élément ainsi que son nom).
- Stocker plusieurs fois les mêmes informations dans le même tableau.
- Champs qui dépendent d'autres champs non clés.
Tableau non normalisé (gauche) versus schéma normalisé (droite).
Entrepôts de données et dénormalisation
Certaines bases de données sont utilisées pour interroger de gros volumes d'informations au lieu du traitement des transactions en ligne (OLTP). Ces bases de données sont appelées entrepôts de données.
Les informations contenues dans un entrepôt de données ne proviennent pas d'interfaces utilisateur (par exemple saisies directement à partir d'un système de commande de commerce électronique). Il provient de processus par lots qui collectent des informations provenant de différentes sources, les traitent, les nettoient et les stockent dans des tables. Pour cette raison, on peut supposer que les entrepôts de données ne sont pas exposés aux mêmes anomalies que les bases de données classiques.
De ce fait, les entrepôts de données n'ont pas besoin de maintenir les mêmes conditions de normalisation qu'une base de données OLTP. D'autre part, il est plus important d'optimiser l'efficacité des requêtes dans les entrepôts de données. C'est pourquoi la dénormalisation est appliquée dans un entrepôt de données; cette technique utilise une certaine redondance pour simplifier les requêtes et éviter d'encombrer les schémas avec un nombre excessif de tables.
Un schéma typique d'entrepôt de données.
Mégadonnées
Comme l'entreposage de données, le concept de Big Data fait référence à des référentiels qui hébergent de grandes quantités de données. Cependant, il existe une différence importante entre les deux concepts. Un entrepôt de données est conçu dans un but précis et vise à générer des rapports dont le comportement et le format sont connus à l'avance.
Le Big Data, quant à lui, vise à collecter de grands volumes de données générées à grande vitesse à partir de différentes sources - par ex. des informations provenant des médias sociaux, des microtransactions ou des capteurs intelligents. Cette énorme quantité d'informations peut être utilisée pour l'exploration et l'analyse ou pour la formation de modèles d'apprentissage automatique.
Dans la conception de bases de données Big Data, l'économie d'espace de stockage et le partitionnement des données (entre autres) sont prioritaires pour permettre le parallélisme et la capture de données en temps réel. De plus, des systèmes de bases de données non relationnelles ou NoSQL sont utilisés, qui offrent de meilleures alternatives pour gérer les informations non structurées.
Des technologies telles que NoSQL et le concept de Big Data lui-même sont relativement nouveaux par rapport aux bases de données relationnelles, qui ont déjà plus de 40 ans. C'est pourquoi, en tant que concepteur de bases de données, vous devez être attentif aux nouveautés dans ce domaine. Gardez à l'esprit que le Big Data est aussi une grande entreprise. De nombreuses entreprises souhaitent y prendre une position de leader et développent de nouveaux outils et technologies pour y parvenir.
Administration de la base de données
Une fois qu'une base de données est opérationnelle, quelqu'un doit s'occuper de sa gestion quotidienne. Cela signifie effectuer des tâches de routine afin que la base de données ne devienne jamais un goulot d'étranglement pour les applications qui l'utilisent. Les tâches d'administration comprennent la gestion des sauvegardes, la surveillance de la consommation d'espace de stockage, la détection des plantages entre les processus et la résolution des problèmes de données qui empêchent le fonctionnement normal des applications.
La personne qui possède les compétences en matière de base de données pour s'occuper de ces tâches est l'administrateur de la base de données, ou DBA - quand il y en a un. Dans les très petites organisations - ou dans les environnements de développement où le fonctionnement des bases de données n'est pas critique pour l'entreprise - la responsabilité de la maintenance de la base de données peut incomber au modélisateur de base de données. Par conséquent, vous devez avoir des connaissances qui vous permettront de prendre le relais du DBA dans certaines situations. Cependant, vous ne devez en aucun cas accepter la responsabilité d'administrer une base de données dans un environnement de production prenant en charge des applications commerciales ou critiques .
Les tâches d'administration varient considérablement en fonction du système de base de données et de l'infrastructure sur laquelle il est monté. Par exemple, les tâches de gestion des bases de données Microsoft SQL Server sont très différentes de celles de gestion des bases de données MySQL ou Oracle. Et la gestion d'un serveur qui s'exécute localement sur votre ordinateur portable est très différente de la gestion d'un serveur qui s'exécute dans le Cloud.
Je ne recommande pas de consacrer beaucoup d'efforts à apprendre à gérer un serveur de base de données particulier, car vous aurez affaire à des bases de données et des environnements très différents tout au long de votre carrière. Cela ne vous servira à rien de vous spécialiser dans un seul.
Concurrence et gestion des transactions
L'accès simultané à une base de données peut entraîner des problèmes dans les applications lorsque plusieurs utilisateurs tentent d'accéder à la même ressource en même temps. On pourrait penser qu'en tant que concepteurs, ce n'est pas notre affaire et qu'il est de la responsabilité du DBA de traiter ces problèmes. On peut aussi penser que c'est la faute des programmeurs de créer des applications qui les autorisent.
Cependant, les concepteurs peuvent faire leur part pour minimiser les problèmes potentiels de concurrence en concevant des schémas qui les évitent.
De nombreux problèmes de concurrence surviennent lorsque des transactions longues et complexes sont exécutées sur une base de données; pendant le traitement de la transaction, les tables impliquées sont bloquées pour les autres processus qui en ont besoin pour lire ou écrire des informations. Pour éviter ce genre de problème, la meilleure chose à faire est de vous assurer que vos conceptions sont conformes au moins jusqu'à la troisième forme normale. Ensuite, il sera de la responsabilité du programmeur de réfléchir correctement aux transactions pour éviter les blocages.
Mais vous pouvez également utiliser des stratégies qui évitent la concurrence, telles que le partitionnement des schémas ou le regroupement des tables en fonction de la fonction que chacune remplit.
Imaginons une base de données pour un site e-commerce. Vous pouvez placer les tables de données de base pour les produits, les stocks et les prix dans un schéma et les commandes et les ventes dans un autre, avec des vues ou des répliques en lecture seule des tables du premier schéma. Cela permet d'éviter les erreurs lors de l'exécution des transactions qui mettent à jour les données de base.
Outils de conception de base de données
Si vous comprenez le modèle relationnel, les diagrammes entité-relation et les techniques de normalisation, vous pouvez concevoir des bases de données sans autre outil que le crayon et le papier. Cependant, vos performances seront grandement améliorées si vous utilisez un outil intelligent, en particulier un outil capable d'automatiser certaines tâches de conception telles que le déplacement ou la modification d'objets dans un diagramme, la détection d'erreurs de conception, la génération de scripts SQL pour créer ou mettre à jour une base de données et l'inverse. concevoir une conception de base de données existante.
Maîtriser un outil spécialisé comme la plateforme Vertabelo vous permettra de travailler beaucoup plus rapidement. Et cela vous permettra de vous démarquer des autres designers qui n'ont pas cette aide.
SQL et programmation
Nous aimerions tous pouvoir livrer un design de base de données, dire fièrement "Mon travail ici est terminé" et partir pour des vacances bien méritées. Mais généralement, cette situation idéale ne se produit jamais. Une fois que vous avez terminé votre conception, les programmeurs d'application devront l'utiliser, et ils auront besoin de vous pour les aider.
L'une des façons dont vous devriez continuer à participer à un projet de développement consiste à écrire des vues, des déclencheurs, des procédures stockées et d'autres éléments en SQL (Structured Query Language) pour résoudre les besoins particuliers de l'application. Une autre façon est de superviser les tâches de programmation qui sont effectuées avec quelque chose appelé Object-Relational Mapping (ORM).
Les ORM sont destinés à résumer l'accès aux données à partir d'un SGBDR particulier. Le bon côté de cela est que les programmeurs n'ont pas à se soucier des spécificités de la base de données qu'ils utiliseront - en d'autres termes, ils n'ont pas besoin de se soucier si le SGBDR est MySQL, Oracle, IBM DB2, MS SQL Server , ou autre chose.
L'inconvénient des ORM est que les objets de conception de la base de données - tables, attributs et relations - sont définis dans le code d'un langage de programmation de haut niveau comme Java, Python, R ou C#. En d'autres termes, ils sont là où nous, les concepteurs de bases de données, ne pouvons pas les voir.
La solution à ce problème réside dans les méthodologies de développement Agile et leur philosophie collaborative. Ceux-ci encouragent les concepteurs et les programmeurs à travailler ensemble au cours d'un projet, vous voudrez donc maintenir une bonne relation avec les programmeurs. Vous devriez être prêt à vous asseoir à côté d'eux, à regarder le code de programmation et à écrire ensemble les définitions des objets de données.
Les concepteurs de bases de données de compétences générales devraient avoir
En plus des connaissances théoriques et techniques propres à la conception de bases de données, un designer devrait idéalement avoir d'autres compétences dites « soft skills ». Ces compétences, comme être un bon communicateur et comprendre la vision de l'entreprise pour le produit final, ont un impact indirect sur le succès de votre travail. Celles que je mentionne ci-dessous ne sont que quelques exemples, mais il existe de nombreuses autres compétences non techniques qui sont très appréciées par les employeurs potentiels.
Vision d'entreprise
Lorsque vous concevez une base de données, vous représentez la réalité d'une entreprise en termes d'objets de données interdépendants. Nous avons vu que le design doit répondre à des conditions de standardisation et qu'il doit éviter les incohérences, les anomalies et les problèmes de concurrence. Mais il est tout aussi important, voire plus important, que la conception soit alignée sur la vision commerciale de la personne qui paie votre salaire.
Comprendre la vision d'affaires vous permettra de mieux saisir l'importance de chaque exigence et d'orienter vos décisions afin que vos conceptions soient mieux alignées avec les objectifs de l'organisation.
Voici un exemple simple de la façon dont la compréhension de la vision de l'entreprise façonnera votre travail. Vous pensez peut-être que l'utilisation d'une clé de substitution dans un tableau encombre votre conception, en ajoutant un élément inutile et ennuyeux. Mais en omettant la clé de substitution, vous risquez de ralentir les requêtes sur cette table car une clé de type INTEGER pourrait offrir des performances supérieures. Si la vision de l'entreprise est de fournir des requêtes rapides, la clé de substitution est la voie à suivre.
Compétences en communication
Il ne suffit pas de faire de grands designs. Vous devez également être en mesure d'expliquer pourquoi votre conception fonctionne. Le moyen d'y parvenir est de savoir comment le présenter, à la fois discursivement (parlé ou écrit) et visuellement.
Faites une liste des points forts de votre design afin qu'ils se démarquent. Réfléchissez aux décisions que vous avez prises pour le créer et notez les raisons de ces décisions. Soyez prêt à défendre vos décisions et votre conception auprès de ceux qui ne la comprennent pas ou qui veulent la changer, la rendant imparfaite ou défectueuse.
Mais vous devez également être prêt à accepter les critiques constructives et à considérer des points de vue différents des vôtres. Parfois, un programmeur peut repérer un problème que vous n'avez pas vu et vous donner de bons conseils. Ne renvoyez pas vos collègues en pensant qu'ils ne connaissent pas la base de données.
Compétences interpersonnelles
J'ai commenté ci-dessus les avantages d'avoir de bons rapports avec les programmeurs. Peu importe à quel point vous êtes avancé dans votre domaine d'expertise, il est important que vous mainteniez une attitude de camaraderie avec tous les membres de l'équipe, qu'il s'agisse d'un testeur qui a détecté un défaut qui vous oblige à repenser une partie de votre conception ou d'un chef de projet qui a besoin vous d'accomplir une tâche à une certaine date. En bref, vous devez être un joueur d'équipe . Personne ne veut avoir des prima donnas dans son équipe qui se sentent irremplaçables et veulent imposer leurs règles.
Il peut arriver que vous ne soyez pas le seul concepteur de base de données dans une équipe de développement. Peut-être devez-vous diriger un sous-groupe de vos collègues. Pour ce faire, vous devez faire preuve de leadership et agir à titre de chef de projet en vous assurant que l'équipe de concepteurs de bases de données atteint ses objectifs et reste motivée.
Comment acquérir des compétences en conception de bases de données
Vous pouvez acquérir les compétences dont vous avez besoin pour devenir concepteur de bases de données à partir de diplômes universitaires, de cours, de livres et d'articles spécialisés. L'avantage des cours universitaires est qu'ils vous donnent toutes les connaissances dont vous avez besoin et sanctionnent ces connaissances par un diplôme reconnu. L'inconvénient est qu'ils nécessitent un gros investissement en temps et en argent.
Si vous préférez apprendre par vous-même en lisant des livres et des articles, vous gagnerez du temps et de l'argent – mais vous aurez besoin d'un guide pour vous guider à travers les sujets essentiels et pour évaluer vos connaissances. Et vous devrez démontrer vos connaissances de manière pratique, car vous n'aurez pas de diplôme pour les étayer.
Dans tous les cas, que vous appreniez en suivant des cours ou en lisant, ces connaissances ne serviront que de base. Vous apprendrez le plus en créant des modèles, en faisant face à de vrais problèmes et en observant les actions de vos collègues et collègues.
