10 éTapes vers SQL Success - des nuls

Le but de SQL est de permettre aux développeurs de créer des bases de données et des applications de base de données utiles et robustes. Pour réussir, votre effort de développement doit passer par une série d'étapes, chacune s'appuyant sur la précédente, jusqu'à ce que vous puissiez légitimement célébrer un projet réussi. Voici dix étapes essentielles qui aboutiront à un effort de développement de base de données réussi.

Définissez la tâche

Au début d'un projet, la personne qui vous confie la tâche de construire un système (le client) a une idée de ce qui est nécessaire. Cette idée peut être très spécifique, précise et concise, ou peut être vague, nébuleuse et mal définie. Votre première tâche est de générer et de mettre par écrit une description détaillée de ce que devrait être le résultat final du projet, appelé les livrables . C'est la tâche principale de l'étape de la définition.

Dans la phase de définition, vous définissez le problème à résoudre par votre base de données et l'application associée le plus précisément possible. Faites cela en écoutant attentivement votre client pendant qu'elle décrit ce qu'elle envisage pour le système. Posez des questions pour clarifier des points vagues. Souvent, le client n'aura pas complètement réfléchi. Elle aura une idée générale de ce qu'elle veut, mais aucune idée claire des détails. Vous devez arriver à un accord avec elle sur les détails avant de pouvoir procéder.

Déterminer l'étendue du projet

L'étape suivante de la phase de définition consiste à déterminer la portée du projet. Quelle sera la taille d'un travail? De quoi aura-t-il besoin en temps d'analyste de systèmes, temps de programmeur, équipement et autres éléments de coût? Y a-t-il une date limite?

Déterminer ce qu'il faudra pour faire le travail:

Une fois que vous avez déterminé la portée du projet, la prochaine question à vous poser est: «Est-il possible de faire ce travail dans les limites de temps et de coût? par le client? Pour répondre à cette question, vous devez faire une analyse de faisabilité. Après avoir terminé l'analyse, vous pouvez décider que le projet n'est pas réalisable comme défini actuellement. Vous devez le refuser ou convaincre le client de réduire la portée à quelque chose de plus gérable.

Une fois que vous avez déterminé que le projet est réalisable, vous savez de quel type de personnel vous aurez besoin pour faire le travail. À ce stade, vous devez décider qui travaillera sur le projet. Vous pourriez être en mesure de faire un petit travail tout seul, mais la plupart des efforts de développement nécessitent une équipe de plusieurs personnes. Trouver des personnes qui ont les compétences requises (et qui sont également disponibles pour travailler sur le projet lorsque vous en avez besoin) peut être aussi difficile que n'importe quelle partie de l'effort de développement total.

Générer un énoncé des besoins

Une fois que vous vous êtes entendu avec votre client sur ce que le projet inclura exactement, vous pouvez rédiger un énoncé des besoins officiel. L'énoncé des besoins est une déclaration explicite des mécanismes d'affichage, de mise à jour et de contrôle de l'application de base de données.

L'énoncé des besoins doit être aussi détaillé que possible. C'est essentiellement un contrat entre vous et votre client. Vous êtes d'accord sur exactement ce qui sera livré et quand il sera livré. Pour sceller l'arrangement, vous et votre client devez signer l'Énoncé des besoins, signifiant un accord sur ce que vous serez responsable de la livraison. Cette étape peut sembler plutôt formelle, mais elle protège les deux parties. Il ne peut jamais être question plus tard de ce qui a été convenu.

Créer un modèle de base de données formel

Jusqu'à présent, le projet était avant tout une analyse. À ce stade, vous pouvez entrer dans la phase de conception et faire la transition de l'analyse à la conception. Vous savez probablement tout ce que vous devez savoir sur le problème, alors maintenant vous pouvez commencer à concevoir la solution.

La conception de base de données est tout au sujet des modèles. À ce stade, vous disposez du modèle de données des utilisateurs, qui capture le concept des utilisateurs de la structure de la base de données. Il comprend tous les principaux types d'objets, les caractéristiques de ces objets et la manière dont les objets sont liés les uns aux autres. Cependant, il n'est pas suffisamment structuré pour être la base d'une conception de base de données. Pour cela, vous devez convertir le modèle de données des utilisateurs en un modèle conforme à l'un des systèmes de modélisation de base de données formels développés au cours des dernières décennies.

Le plus populaire des systèmes de modélisation formels est le modèle entité-relation, communément appelé modèle E-R. Avec ce modèle, vous pouvez capturer ce que les utilisateurs vous ont dit dans un formulaire bien défini que vous pouvez ensuite traduire facilement dans une base de données relationnelle.

Une fois que vous avez le système sous la forme d'un modèle E-R, il est facile de le convertir en un modèle relationnel. Le modèle relationnel est quelque chose que votre SGBD comprend et vous pouvez en créer directement la base de données.

Conception de l'application de base de données

Une fois la base de données créée, la tâche de conception est à moitié terminée. Vous avez une structure que vous pouvez maintenant remplir avec des données, mais vous n'avez pas encore d'outil pour fonctionner sur ces données. L'outil que vous devez concevoir maintenant est l'application de base de données.

L'application de base de données est la partie du système global qui interagit avec l'utilisateur. Il crée tout ce que l'utilisateur voit sur l'écran. Il détecte et réagit à chaque dépression de clé que l'utilisateur fait et à chaque action de la souris que l'utilisateur effectue. Il imprime tous les rapports lus par les collègues de l'utilisateur. Du point de vue de l'utilisateur, l'application de base de données est le système.

En concevant l'application de base de données, vous devez vous assurer qu'elle permet aux utilisateurs de faire tout ce que l'énoncé des exigences promet qu'ils seront en mesure de faire.Il doit également présenter une interface utilisateur compréhensible et facile à utiliser. Les fonctions du système doivent apparaître dans des positions logiques sur l'écran. L'utilisateur doit facilement comprendre comment effectuer toutes les fonctions que l'application fournit.

Construire

Maintenant que vous avez une conception de base de données, vous pouvez créer les tables, les relations entre elles et les contraintes sur les données qui peuvent y être entrées.

Documentez

Tout ce que vous avez fait et les raisons de toutes les décisions que vous avez prises doivent être méticuleusement documentées. J'espère que vous faites cela depuis le début. À ce stade, tout ce que vous devez faire est de mettre la documentation dans sa forme finale. Un développeur compétent qui n'est pas familier avec le projet devrait être capable de le ramasser après que vous avez évolué vers des choses plus grandes et meilleures.

Tout tester

Une fois que vous avez créé et documenté un système de base de données, vous pouvez avoir l'impression que vous avez terminé et vous pouvez profiter de vacances bien méritées, mais vous n'êtes pas encore tout à fait terminé - le système doit être rigoureusement testé. Ce test doit être effectué par quelqu'un qui ne pense pas de la même manière que vous. Une fois que le système sera opérationnel, les utilisateurs feront des choses que vous n'avez jamais imaginées. Ils vont faire des combinaisons de sélections que vous n'avez pas prévues, entrer des valeurs dans des domaines qui n'ont aucun sens, et faire des choses en arrière et à l'envers. On ne sait pas ce qu'ils vont faire. Quelle que soit la réaction inattendue de l'utilisateur, vous voulez que le système réagisse de manière à protéger la base de données et à guider l'utilisateur dans les actions de saisie appropriées.

Maintenir le produit fini

Une fois que vous avez livré le système à temps et que vous avez respecté le budget, célébré et encaissé votre paiement final pour le travail, vos responsabilités ne sont pas terminées. Même si le testeur indépendant a fait un travail fantastique pour tenter de faire échouer le système, après la livraison, il peut encore contenir des bugs latents qui apparaissent des semaines, des mois, voire des années plus tard. Vous pourriez être obligé de réparer ces bogues sans frais, en fonction de votre accord contractuel avec le client.

Même si aucun bogue n'est trouvé, vous pouvez toujours avoir une responsabilité permanente. Après tout, personne ne comprend le système aussi bien que vous. Au fil du temps, les besoins de votre client changeront. Peut-être aura-t-elle besoin de fonctions supplémentaires, ou voudra-t-elle migrer vers un matériel plus récent et plus puissant. Ces possibilités peuvent nécessiter des modifications de l'application de base de données, et vous êtes le mieux placé pour effectuer ces modifications, en fonction de vos connaissances antérieures. Ce travail supplémentaire pourrait signifier de belles recettes supplémentaires pour vous.