ABIS Infor - 2012-04
Connaissez votre propre base de données
Abstrait
Il est devenu inconcevable pour toute entreprise moderne de travailler sans une base de données. Bien sûr, cela ne peut être réalisé sans aucune connaissance de la langue pour communiquer avec une DB (SQL) et le logiciel actuel de la DB (DB2, Oracle, SQL Server, MySQL, ...). Cependant, il y a quelque chose que beaucoup de gens ont tendance à négliger. Une connaissance approfondie du logiciel de la plate-forme DB et SQL, n'est pas la même chose que de connaître votre propre base de données.
Construire votre base de données : poser les fondations
Comme nous le savons tous, la bonne conception de votre base de données est essentiel pour son efficacité. À partir de l'analyse préliminaire des données utilisées par votre entreprise pour arriver finalement aux structures réelles des tables et des vues, chaque étape de cette voie va influencer la manière avec laquelle votre base de données est utilisée. Ces premières étapes, ces fondations, auront un impact sur chaque requête. Il est donc essentiel dans cette phase que tous les plans de votre base de données sont abondamment documentés.
Implémentation & Maintenance: construction du château
Une fois que vous êtes décidé pour la conception, vous avez besoin de la traduire en véritables structures physiques et logiques connues sous le nom "La base de données". Beaucoup de choses doivent être prises en considération: les problèmes de performances, l'utilisation de mémoire, indexs, l'intégrité des données, triggers, procédures, ... et ainsi de suite. Toutes ces considérations peuvent être mises en œuvre en utilisant SQL. Nous n'avons pas à insister sur la nécessité de la documentation détaillée au cours de cette phase. Omettre la documentation vous perdra en terre inconnue, sans un guide.
En plus de tout cela, une base de données n'est pas statique. Les besoins et les activités d'une entreprise peuvent et vont changer au fil du temps, et donc les besoins que nous posons sur notre base de données. Au fil du temps nous continuons à rénover notre «château»: nous ajoutons des colonnes, des tables, des vues. Certaines ne sont plus utilisées, ou pourraient même être entièrement supprimées. En d'autres termes: notre base de données est vivante. Et cela exige une révision constante de nos plans, la carte qui nous guide dans la recherche de nos données.
Rechercher les données: une chasse au trésor
En fin de compte, nous arrivons au seul but d'une DB: récupérer et maintenir l'information vitale de notre société d'une manière efficace et performante. Et que voyons-nous? Pour de nombreux utilisateurs finaux est la récupération des données plus comme une chasse au trésor d'une réelle tâche facile à exécuter. Que peut empêcher ce phénomène?
La première étape est une connaissance suffisante du langage SQL. Nous ne parlons pas uniquement d'une connaissance syntaxique, mais aussi sur une compréhension profonde de l'ordre d'exécution d'une requête. Si vous comprenez l'ordre dans lequel une requête est exécutée, vous pouvez influencer l'efficacité et les performances de votre requête, avec des résultats positifs.
Une deuxième étape est l'analyse de la demande pour les données. Il est ainsi essentiel que certaines entreprises emploient une équipe dédiée qui vient juste pour d'analyser toutes demandes, avant qu'une seule requête soit écrite. Soyons honnêtes: nous nous avons tous posé des questions qui nous semblaient claires et précises dans nos têtes, mais étaient en réalité trop vagues ou trop restrictives pour produire des réponses qui convenaient à nos besoins. Une analyse correcte de la demande pour les données est essentielle pour une requête efficace, comme dans la connaissance syntaxique de SQL.
Cependant, il ya une troisième étape qui est souvent négligée: une profonde connaissance de votre propre base de données. Un grand nombre d'entreprises considère que c'est quelque chose de moindre importance, quelque chose que l'utilisateur final va gérer tout au long du chemin. Nous prions de reconsidérer la situation : une telle connaissance est tout aussi importante q'une analyse correcte, ou d'une expertise syntaxique de SQL. C'est la carte qui nous guidera sur notre chasse au trésor.
Nous sommes convaincus que cette carte devrait comporter trois éléments essentiels: un dessin schématique indiquant toutes les tables (vues) et les liens entre eux, une description syntaxique de toutes les tables et les colonnes et une description sémantique de la même chose. La troisième partie est tout aussi essentielle que les deux premiers, mais malheureusement, elle est généralement absente.
Aujourd'hui, il ya beaucoup de GUI qui peuvent générer un tel dessin schématique, et de fournir sans aucun problème une description syntaxique approfondie. Cela ne devrait plus être une surprise puisque ces deux parties sont basées sur les données qui peuvent être trouvées dans le catalogue, une partie intrinsèque de toute logiciel DB. La description sémantique ne peut cependant pas être générée par le logiciel, car il a besoin de la main de l'homme pour la créer. La signification de chaque colonne, de chaque numéro et de chaque chaîne trouvée dans un champ doit être documentée, écrite et expliquée ... et cela prend du temps.
Nous allons répéter pour que ce soit tout à fait clair: la documentation de chaque table et de chaque colonne d'une manière telle que le sens de chaque élément de données soit clair comme de l'eau de roche pour quiconque lit cette description sémantique ("Ce nombre représente le nombre réel de ce produit spécifique dans notre entrepôt "), prend beaucoup de temps et d'efforts. Mais c'est un effort qui paie. Une fois qu'il est terminé (et maintenu), de nouveaux utilisateurs finaux auront une description significative de la DB qui leur permet d'utiliser la base de données sans aucn support humain additionnel. Le temps supplémentaire acquise de cette manière fait plus que compenser le temps initial et les efforts consacrés dans la production de la description sémantique. Il aura un impact profond sur la compréhension de la DB, les relations entre éléments de données, et va diminuer la nécessité pour les employés d'en guider d'autres. C'est-à-dire, seulement si les nouveaux employés reçoivent une marge de manœuvre pour étudier cette description durant quelques jours.
Cours d'entraînement personnalisés
Lorsque nous avons observé ces différences dans la façon dont nos propres clients documentent leurs bases de données, nous avons décidé de s'attaquer à ces domaines dans les cours ici chez ABIS. Notre formation SQL dépasse l'aspect purement syntaxique de la langue. Comme dans la partie intégrante de du cours, nous avons passé du temps et efforts à l'ordre d'exécution d'une requête, à l'analyse de la demande de données et à la structure logique d'une base de données. Ces questions sont examinées dans les stages: on commence aux bases pour vous guider vers les requêtes de très hautes performances. Et chacun de ces cours peuvent être adaptés à la base de données de votre propre entreprise.