Quelles sont les considérations les plus importantes lors de la conception d'une base de données?
Je voudrais savoir des programmeurs expérimentés ce qu’ils considèrent être les considérations les plus importantes lors de la conception d’une nouvelle base de données.
Tout d’abord et surtout, apprenez et comprenez le domaine des affaires.
1) Souhaitez-vous un taux de transaction élevé, par exemple un site Web surchargé, ou une faible utilisation, par exemple un système de ressources humaines pour une petite entreprise?
2) La sécurité est-elle un gros problème - traitez-vous des données personnelles ou des données financières? Ou est-ce juste un catalogue de produits
3) Vos utilisateurs feront-ils beaucoup de mises à jour/inserts ou est-ce principalement en lecture seule?
4) Combien d'utilisateurs, quels sont les modèles d'utilisation (charge de pointe ou uniformément répartie)
5) Avez-vous besoin d'une disponibilité de 24x7, 16x5 ou d'une autre disponibilité, 24x7 est beaucoup plus difficile à faire que vous n'avez pas de temps d'arrêt pour la maintenance
6) Quelle est la taille de la DB? Si c'est vraiment gros, vous devrez concevoir vos tables en tenant compte de cela et/ou de la partition
7) Avez-vous besoin d'examiner un cluster d'entreprise avec basculement à chaud ou un hébergement normal?
8) Comment la base de données sera-t-elle administrée? Dans la plupart des projets de base de données, 95% des efforts sont consacrés au développement pour les utilisateurs et leurs applications, mais l’administration de la base de données est oubliée.
9) Administrateur de base de données, comprend les sauvegardes, les modifications apportées à d'autres systèmes, l'intégration à d'autres systèmes, le chargement de données
10) En réalité, le chargement et l'utilisation des données existantes est un autre problème important en soi.
Voilà pour un début
La base de données est secondaire à la conception de votre processus métier et doit soutenir votre processus métier de manière simple et directe. Vous bénéficierez bien plus d’un modèle d’entité propre et bien formé que d’un index ici et là. Donc, une fois que votre processus est défini, vous le prenez et vous le divisez en "entités" aussi clairement que possible avec des relations cohérentes. Une fois que vous connaissez vos entités, elles se traduisent en tables de base de données.
L’une des choses les plus importantes à faire est de ne pas tout organiser.
Pour vous donner une réponse avec quelques dents, prenons l'exemple d'une entité "véhicule". Un véhicule a plusieurs roues. Vous devez prendre une décision cruciale en sachant qu'il y aura plusieurs roues attachées au véhicule. Vous avez le choix entre deux options: vous pouvez transformer les roues en une entité distincte ou le nombre de roues d'un champ entier dans l'entité Véhicule.
Si vous savez absolument qu'il vous faudra stocker de nombreuses informations changeantes sur chaque roue, créez une entité "Roue". Vous avez maintenant une relation entre des entités (la voiture et la roue).
Sinon, un simple champ suffira.
Réfléchir à ces décisions critiques et rendre les choses aussi simples que possible est de loin le plus important pour moi lors de la conception d’une base de données. Lorsque vous créez la ou les couches suivantes de votre application, il peut être très difficile de faire la différence.
1 - Cohérence
Au fil du temps, votre base de données changera et d'autres personnes devront travailler avec elle. Faites-vous une faveur et assurez-vous que les structures sont nommées de manière à ce que toute personne raisonnable possédant une connaissance de base du domaine puisse anticiper le contenu de la table. Prenez le temps d'écrire (par exemple, un simple bloc-notes) certaines des constructions de base que vous utilisez.
Exemples:
- Les clés primaires commencent toutes par IdTableName
- La casse des noms de table est Pascal
- Les clés étrangères sont toutes TableNameId
- ext ...
Que vous choisissiez d'utiliser des traits de soulignement ou non (remplacez-les par une autre conversion) n'a pas vraiment d'importance à la fin de la journée, à condition que vous utilisiez la même méthode ou que vous ne l'utilisiez pas.
Votre base de données constitue la dernière ligne de défense de l'intégrité des données. Accédez à l'ensemble de vos données via des procédures stockées et appliquez leur intégrité à l'aide de contraintes de vérification, de clés étrangères, etc. Tapez les données correctement, n'utilisez pas VARCHAR (50) lorsque CHAR (5) est plus spécifique et précis.
Quelqu'un d'autre a parlé de garder les choses simples. Dernier point mais non des moindres, ne construisez pas quelque chose parce que vous "pensez", vous en aurez besoin le mois prochain. Les choses changent rapidement et vous finirez par faire plus de maintenance sur les choses que vous "pensiez" utiliser plutôt que sur les choses que vous utilisez si vous remplissez votre base de données ne serviront à rien.
Fidélité aux entités du monde réel que la base de données est supposée modéliser.
Je suggère personnellement de prendre ou d’emprunter un exemplaire de "Database Design for Mere Mortals". Tout ce que vous auriez besoin de prendre en compte lors de la conception d'une base de données serait répertorié dans ce livre, et ce dans un ordre très méthodique et logique dans lequel vous pourrez construire la base de données. Les définitions de table et de colonne sont fastidieuses, mais valent chaque minute utilisée à la fin.
Je pense que vous pourrez peut-être lire le premier chapitre du livre via Google Books ou via la prévisualisation de la page sur Amazon.com.
Vous pouvez apprendre au fil du temps ou à partir de ce site les «meilleures pratiques» que vous pouvez utiliser, mais rien ne vaut de le concevoir de la bonne manière du premier coup.
Connaissez vos données.
vous devez également comprendre à quoi servira la base de données. si c'est pour les transactions (OLTP), il devrait être aussi normalisé que possible et l'objectif est que les transactions soient complétées le plus rapidement possible. si c'est pour l'analyse et/ou le reporting (OLAP), il devrait être dénormalisé dans de nombreux endroits où vous effectuerez une agrégation. les considérations de conception pour les bases de données OLTP ne s'appliquent pas aux bases de données OLAP, et inversement.
Les informations requises sont la partie la plus importante.
C'est une autre façon de dire "déterminer le but de votre système", à partir d'une réponse fournie par CMS.
La modélisation conceptuelle de données n'est qu'un moyen organisé de collecter et de présenter les besoins en informations. Chaque valeur stockée et servie par la base de données est connectée à un attribut et chaque attribut à un domaine. Les attributs, à leur tour, décrivent des entités ou des relations entre entités. Les entités de la matière et les relations constituent la structure conceptuelle du "monde réel" décrit par les données. Construire une DRE à partir d'un modèle conceptuel est facile, bien que fastidieux.
Après cela, vous pouvez choisir un SGBD, concevoir la base de données logique, concevoir la base de données physique et créer. A chaque étape, les décisions que vous prenez sont plus réversibles, du fait de l’indépendance des données. L'indépendance des données encapsule les décisions de conception dans la base de données, à l'exception des conséquences pour les performances. Vous devez bien sûr connaître votre outil.
Disposer d'un outil de gestion des modèles et les convertir en diagrammes et en scripts peut s'avérer très utile pour accélérer ce processus et réduire les erreurs.
Mais si vous avez des erreurs graves ou des omissions dans vos exigences en matière d’information, aucune conception ou mise en œuvre intelligente ne pourra compenser cela.
qui va le construire et le maintenir, où, comment et avec quoi. Disposez-vous de méthodes, de procédures et de processus vous permettant de le faire ou juste de le faire évoluer? Les besoins de l’entreprise doivent certes générer les données nécessaires, qui devraient être capturées dans un DRE indépendant de la mise en œuvre. Mais, vous devez également vous demander qui conservera les données au fil du temps. Ainsi que qui est "propriétaire" des données. À qui appartiennent les définitions d'entité et d'attribut.
Un ensemble de base de points:
- Déterminez le but de votre système.
- Identifiez les entités dont votre système aura besoin.
- Identifiez les informations que chaque entité devrait fournir.
- Identifiez les relations existantes entre vos entités
- Que voudrait savoir l'utilisateur et comment utiliser vos données?.
- Conception de base de données conceptuelle et logique
- Normalisation et ERD
- Identifiez les champs avec des valeurs uniques.
- Sélectionnez les types de données appropriés pour vos champs.
- Refactoring de base de données.
Une bonne base de données peut être jugée comme suit:
Si une base de données est correctement conçue, vous devriez être capable de comprendre le fonctionnement d'une entreprise en ne regardant que le schéma.
En d'autres termes, la base de données est l'entreprise. Si la base de données ne reflète pas la manière dont l'entreprise est exécutée, la base de données est incorrecte ou l'entreprise est incorrecte.
La base de données est également l’une des rares choses que vous avez vraiment, vraiment besoin de clouer d’emblée. Vous pouvez toujours réparer le mauvais code, mais rarement vous pouvez revenir en arrière après un changement de schéma incorrect. Assurez-vous de le faire correctement.
- Conventions de nommage: s'en tenir à un ensemble de règles
- Normalisation: (degré de normalisation) - cela dépendra du nombre de lectures par rapport au nombre de mises à jour comparées d'une entité de données.
- Intégrité relationnelle et autres contraintes: certaines personnes préconisent l'utilisation de clés étrangères alors que d'autres non
- Créer des diagrammes de base de données, analyser et discuter avec l'équipe si possible.