Modèles de conception de bases de données relationnelles?
Les modèles de conception sont généralement liés à la conception orientée objet.
Existe-t-il modèles de conception pour créer et programmer bases de données relationnelles ?
Beaucoup de problèmes doivent sûrement avoir des solutions réutilisables.
Les exemples incluent des modèles de conception de table, procédures stockées, déclencheurs, etc.
Existe-t-il un référentiel en ligne contenant de tels modèles, similaire à martinfowler.com ?
Exemples de problèmes que les modèles pourraient résoudre:
- Stockage des données hiérarchiques (par exemple, une seule table avec le type vs plusieurs tables avec une clé et des différences 1: 1, etc.)
- Stockage de données avec une structure variable (colonnes génériques vs xml vs colonnes délimitées, par exemple)
- Dénormaliser les données (comment le faire avec un impact minimal, etc.)
Il existe un livre dans la série Signature de Martin Fowler intitulé Refactoring Bases de données . Cela fournit une liste de techniques pour refactoriser les bases de données. Je ne peux pas dire que j'ai tellement entendu une liste de modèles de base de données.
Je recommanderais aussi vivement David C. Hay Modèles de données et suivi . Une carte de métadonnées qui s'appuie sur le premier et est beaucoup plus ambitieux et intriguant. La préface seule est éclairante.
La série de livres de ressources sur les modèles de données de Len Silverston , volume 1 , contient également des modèles de données universellement applicables (employés, comptes). , expédition, achats, etc.), Le volume 2 contient des modèles de données spécifiques au secteur (comptabilité, soins de santé, etc.), Le volume 3 fournit des modèles de modèle de données.
Enfin, alors que ce livre traite apparemment de la modélisation UML et de la modélisation objet, la modélisation en couleur de Peter Coad avec UML fournit un processus de "modélisation par entités" à partir de la prémisse qu'il existe 4 archétypes de base de tout modèle objet/données
Voici un lien vers un monsieur qui a développé plusieurs centaines de schémas de base de données gratuits.
http://www.databaseanswers.org/data_models/
Peut-être que si vous devez créer rapidement une base de données, cela vous donnera un point de départ en termes de tables et de relations dans un schéma donné. Gardez à l'esprit que vous devrez probablement modifier ce point de départ. Je l'ai trouvé très utile.
Deuxièmement, SQL Server Magazine contient une colonne occasionnelle appelée "Le modélisateur de données" qui est très pédagogique et contient souvent des schémas complets pour un système donné.
Les modèles de conception ne sont pas des solutions triviales et réutilisables.
Les modèles de conception sont réutilisables, par définition. Ce sont des modèles vous détectez d'autres bonnes solutions.
Un motif n'est pas facilement réutilisable. Vous pouvez toutefois implémenter votre conception en baisse en suivant le modèle.
Les modèles de conception relationnelle incluent des éléments tels que:
Relations un-à-plusieurs (maître-détail, parent-enfant) à l'aide d'une clé étrangère.
Plusieurs à plusieurs relations avec une table de pont.
Relations biunivoques optionnelles gérées avec des valeurs NULL dans la colonne FK.
Star-Schema: Dimension and Fact, OLAP conception.
Entièrement normalisé OLTP.
Plusieurs colonnes de recherche indexées dans une dimension.
"Table de consultation" contenant la PC, la description et les valeurs de code utilisées par une ou plusieurs applications. Pourquoi avoir du code? Je ne sais pas, mais quand ils doivent être utilisés, c'est une façon de gérer les codes.
Uni-table. [Certains appellent cela un anti-modèle; c'est un motif, parfois c'est mauvais, parfois c'est bon.] Ceci est un tableau avec beaucoup de choses pré-jointes qui violent les deuxième et troisième formes normales.
Tableau de tableau. Ceci est une table qui viole la première forme normale en ayant un tableau ou une séquence de valeurs dans les colonnes.
Base de données à usage mixte. Il s'agit d'une base de données normalisée pour le traitement des transactions, mais avec de nombreux index supplémentaires pour la création de rapports et l'analyse. C'est un anti-modèle - ne fais pas ça. Les gens le font quand même, donc ça reste un schéma.
La plupart des concepteurs de bases de données peuvent facilement déclencher une demi-douzaine de mots "C'est un autre exemple"; Ce sont des modèles de conception qu'ils utilisent régulièrement.
Et cela n'inclut pas les modèles administratifs et opérationnels d'utilisation et de gestion.
Découvrez ce blog - le programmeur de base de données .
Il décrit certains modèles de base de données .
Les livres de Joe Celko sont excellents pour ce genre de choses, en particulier "SQL for Smarties". Il a des solutions innovantes à des problèmes communs, dont la plupart sont des modèles de conception réutilisables.
AskTom est probablement la ressource la plus utile sur les meilleures pratiques en matière de bases de données Oracle. (En général, je tape simplement "asktom" comme premier mot d'une requête google sur un sujet particulier)
Je ne pense pas qu'il soit vraiment approprié de parler de modèles de conception avec des bases de données relationnelles. Les bases de données relationnelles sont déjà l'application d'un "modèle de conception" à un problème (le problème est "comment représenter, stocker et manipuler des données tout en préservant leur intégrité", et la conception étant le modèle relationnel). Les autres approches (généralement considérées comme obsolètes) sont les modèles de navigation et hiérarchique (et j'en ai beaucoup d'autres).
Cela dit, vous pouvez considérer "l'entreposage de données" comme un "motif" ou une approche quelque peu distincte dans la conception de la base de données. En particulier, vous pourriez être intéressé par la lecture du schéma en étoile .
Après de nombreuses années de développement de base de données, je peux affirmer qu’il n’existe pas de solution et que vous devez répondre à cette question avant de commencer:
questions:
- Voulez-vous utiliser à l'avenir un autre SGBD? Si oui, alors ne pas utiliser de trucs SQL spéciaux du SGBD actuel. Supprimer la logique dans votre application.
N'utilise pas:
- espaces blancs dans les noms de table et les noms de colonne
- Caractères non Ascii dans les noms de table et de colonne
- liaison à une minuscule ou une majuscule spécifique. Et n'utilisez jamais 2 tables ou colonnes qui ne diffèrent que par des minuscules et des majuscules.
- n'utilise pas de mots-clés SQL pour les noms de tables ou de colonnes comme "FROM", "BETWEEN", "DELETE", etc.
recommandations:
- Utilisez NVARCHAR ou des équivalents pour la prise en charge de l’unicode, vous n’aurez donc aucun problème avec les pages de codes.
- Attribuez un nom unique à chaque colonne. Cela facilite la jointure pour sélectionner la colonne. Il est très difficile que chaque table ait une colonne "ID" ou "Nom" ou "Description". Utilisez XyzID et AbcID.
- Utilisez un regroupement de ressources ou un équivalent pour les expressions SQL complexes. Il est plus facile de passer à un autre SGBD.
- Ne lance pas fort sur aucun type de données. Un autre SGBD ne peut pas avoir ce type de données. Par exemple, Oracle ne dispose pas d’un nombre SMALLINT.
J'espère que c'est un bon point de départ.
Votre question est un peu vague, mais je suppose que UPSERT pourrait être considéré comme un motif de conception. Pour les langues qui n'implémentent pas MERGE, plusieurs alternatives pour résoudre le problème (si des lignes appropriées existent, UPDATE; sinon INSERT ) existent.
Cela dépend de ce que vous entendez par un motif. Si vous songez à Personne/Société/Transaction/Produit, etc., alors oui, de nombreux schémas de base de données génériques sont déjà disponibles.
Si vous pensez à Factory, Singleton ... alors non - vous n'en avez pas besoin, car leur niveau de programmation est trop bas.
Si vous envisagez de nommer des objets de base de données, cela relève de la catégorie des conventions et non de la conception en tant que telle.
BTW, S.Lott, les relations un-à-plusieurs et plusieurs-à-plusieurs ne sont pas des "modèles". Ce sont les éléments de base du modèle relationnel.
Title: Data Patterns
By: Microsoft Corporation
Publisher: Microsoft Press
Pub. Date: December 21, 2004
Print ISBN-13: 978-0-7356-2200-5