Que faire avant de démarrer le diagramme du modèle de base de données? Je veux dire comment vous formez les exigences, les spécifications, etc. Les cas d'utilisation est une chose mais toute autre chose? Une bonne pratique ou une règle générale? Étant autodidacte, je veux voir comment ça se passe entre les mains de professionnels?Avant de démarrer le modèle de base de données
Assurez-vous d'avoir une liste complète des besoins de votre client. Faites de votre mieux pour comprendre complètement ces exigences, cela aidera vraiment dans votre conception si vous le faites. Si vous définissez les exigences, cela peut être plus facile puisque vous aurez déjà une idée de ce que vous devez faire. Avoir une compréhension approfondie de votre objectif est la partie la plus importante.
S'il y a une partie évidente de votre base de données qui sera la plus importante (une application dans un système d'application en ligne par exemple), je vais généralement commencer à partir de là et travailler une pièce à la fois. Personnellement, j'aime dessiner des images approximatives (ce qui a du sens pour vous, ne doit pas être une ERD officielle) de ce à quoi je pense que la base de données ressemblera et la réviser à des niveaux de détail plus fins.
Ne comptez pas uniquement sur des exigences écrites. Il n'existe pas de liste de conditions complète. Parlez aux parties prenantes, posez des questions et utilisez les résultats de ces entretiens pour déterminer quels attributs doivent être modélisés, comment ils sont utilisés et identifier les clés métier. Ensuite, une analyse et une investigation des données sont généralement nécessaires pour déterminer les types de données appropriés et d'autres aspects.
Il est peut-être possible d'obtenir une bonne première découpe d'un modèle de données à l'avant, mais ne vous inquiétez pas si vous ne le pouvez pas. La modélisation des données doit généralement être un processus itératif et agile, réalisé en étapes de taille raisonnable au fur et à mesure de l'évolution du projet (bien qu'il y ait certainement des cas de conception de Data Warehouse où l'approche agile peut être plus difficile à appliquer).
En fonction de votre clientèle, il peut être judicieux d'avoir deux modèles de données et deux diagrammes. Un modèle et un diagramme sont pour l'analyse des données. L'autre est pour la conception de base de données. J'ai eu de bons résultats en utilisant un modèle et un diagramme ER (Entity-Relationship) pour l'analyse des données et un modèle et un diagramme RDM (Relational Data Model) pour refléter la conception de la base de données.
Le diagramme ER est utile pour communiquer aux clients les besoins découverts jusqu'à présent et s'assurer qu'ils sont complets et corrects. Les diagrammes ER sont faciles à comprendre même si le client n'a pas de formation en base de données. Comme d'autres l'ont déjà fait, il s'agit d'un processus itératif, et non d'une seule cascade. Le modèle et le diagramme RDM sont utiles pour refléter les décisions de conception de base de données logiques telles que la décision de normaliser les données ou d'effectuer autre chose. Il est facile de dériver un modèle RDM à partir d'un modèle ER, bien que vous ayez à introduire certaines décisions de conception qui sont intentionnellement omises du diagramme ER.
À son tour, il est facile de créer un script de création de table à partir d'un diagramme RDM. Vous devrez ajouter quelques caractéristiques physiques comme des index, afin d'obtenir de bonnes performances sans vous couper les cheveux.
Est-ce que quelqu'un utilise vraiment des diagrammes de cas d'utilisation et toutes ces conneries dans le monde réel o.0? C'est seulement ce qui vous est dit à l'école ... – oezi
oui, on m'a dit à l'école que définir des diagrammes de cas d'utilisation et utiliser Prosa ou quelque chose ou UML et dessiner le modèle de données avant même de penser à l'implémentation physique de la base de données. –