Modèles de conception de bases de données relationnelles?

StackOverflow https://stackoverflow.com/questions/145689

Question

Les modèles de conception sont généralement liés à la conception orientée objet.
Existe-t-il des modèles de conception pour la création et la programmation bases de données relationnelles ?
De nombreux problèmes doivent sûrement avoir des solutions réutilisables.

Les exemples incluent les modèles de conception de table, les procédures stockées, les 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 peuvent résoudre:

  • Stockage des données hiérarchiques (par exemple, une seule table avec le type vs plusieurs tables avec une clé 1: 1 et des différences ...)
  • 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.)
Était-ce utile?

La solution

La série Signature de Martin Fowler contient un livre intitulé Refactoring de 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 recommande également vivement les modèles de modèle de données de David C. Hay, ainsi que le suivi Une carte de métadonnées qui s'appuie sur la première, est beaucoup plus ambitieuse et intrigante. La préface seule est éclairante.

La série de livres de ressources sur les modèles de données de Len Silverston constitue également un excellent endroit pour chercher des modèles de bases de données prédéfinis Volume 1 contient des modèles de données universellement applicables (employés, comptes, expédition, achats, etc.), volume 2 . 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, bien que ce livre traite ostensiblement de l'UML et de la modélisation d'objet, la modélisation en couleur avec UML de Peter Coad fournit un " archétype " processus dirigé de modélisation d'entité à partir du principe qu'il existe 4 archétypes de base de tout modèle objet / données

Autres conseils

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 "The Data Modeler". ce qui est très éducatif 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 que vous détectez dans d’autres bonnes solutions.

Un motif n'est pas facilement réutilisable. Vous pouvez toutefois mettre en œuvre votre conception de down en suivant le modèle

Les modèles de conception relationnelle incluent des éléments tels que:

  1. Relations un à plusieurs (maître-détail, parent-enfant) à l'aide d'une clé étrangère.

  2. Relations plusieurs à plusieurs avec une table de pont.

  3. Relations individuelles personnalisées gérées avec des valeurs NULL dans la colonne FK.

  4. Schéma en étoile: dimension et faits, conception OLAP.

  5. Conception OLTP entièrement normalisée.

  6. Plusieurs colonnes de recherche indexées dans une dimension.

  7. "Table de consultation" qui contient PK, description et valeur (s) de code utilisée 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.

  8. 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 déjà jointes qui violent les deuxième et troisième formes normales.

  9. 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.

  10. 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 motif.

La plupart des concepteurs de bases de données peuvent facilement émettre 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 quelques modèles de base de données .

Les livres de Joe Celko sont excellents pour ce genre de choses, en particulier "SQL pour Smarties". Il propose des solutions novatrices aux problèmes courants, dont la plupart sont des modèles de conception réutilisables.

http://www.celko.com/books.htm

AskTom est probablement la ressource la plus utile sur les meilleures pratiques relatives aux 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 constituent déjà l'application d'un "modèle de conception". à un problème (le problème étant "comment représenter, stocker et travailler avec des données tout en maintenant 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 étant dit, vous pouvez envisager "Entreposage de données". en tant que "motif" un peu séparé ou approche dans la conception de 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 existe des règles peu contraignantes et des questions auxquelles vous devez répondre 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.

Ne pas utiliser:

  • espaces 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 deux 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 tels que "DEPUIS", "ENTRE-UN", "SUPPRIMER", 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 groupe de ressources ou l'équivalent pour les expressions SQL complexes. Il est plus facile de passer à un autre SGBD.
  • N'effectue pas de casting dur sur aucun type de données. Un autre SGBD ne peut pas avoir ce type de données. Par exemple, les fichiers Oracle ne possèdent pas un numéro 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 modèle de conception. Pour les langues qui n'implémentent pas MERGE , plusieurs solutions pour résoudre le problème (s'il existe une ligne appropriée, UPDATE ; sinon, INSERT ) existe.

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’avez besoin d’aucune de ces solutions car elles sont de niveau trop bas pour la programmation sous DB.

Si vous envisagez de nommer un objet 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.

Ce livre a l'air intéressant 

Title: Data Patterns
By: Microsoft Corporation
Publisher: Microsoft Press
Pub. Date: December 21, 2004
Print ISBN-13: 978-0-7356-2200-5
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top