Modèles de conception de bases de données relationnelles? [fermé]

283

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 créer et programmer des bases de données relationnelles ?
De nombreux problèmes doivent certainement avoir des solutions réutilisables.

Les exemples pourraient inclure des modèles pour la conception de tables, des procédures stockées, des déclencheurs, etc.

Existe-t-il un référentiel en ligne de tels modèles, similaire à martinfowler.com ?

Exemples de problèmes que les modèles pourraient résoudre:

Stockage de données hiérarchiques (par exemple, une seule table avec type vs plusieurs tables avec clé 1: 1 et différences ...)
Stockage de données avec une structure variable (par exemple, colonnes génériques vs xml vs colonne délimitée ...)
Dénormaliser les données (comment le faire avec un impact minimal, etc ...)

design-patterns database-design rdbms

— Sklivvz
source

Je revendiquerai ici le meilleur Q&A pour le stockage hiérarchique des données: stackoverflow.com/questions/4048151/…

— orangepips

1

Selon nos conseils sur le sujet , " Certaines questions sont toujours hors sujet, même si elles entrent dans l'une des catégories énumérées ci-dessus: ... Questions nous demandant de recommander ou de trouver un livre, un outil, une bibliothèque de logiciels, un didacticiel ou autre les ressources hors site sont hors sujet ... "

— Robert Columbia

@RobertColumbia la question était sur le sujet en 2008, lorsqu'on lui a demandé ...

— Sklivvz

Consultez cette liste de ressources sur les modèles de conception sur les bases de données relationnelles et de nombreux domaines du génie logiciel github.com/DovAmir/awesome-design-patterns

— dov.amir

150

Il y a un livre dans la série Signature de Martin Fowler intitulé Refactoring Databases . Cela fournit une liste de techniques de refactorisation des bases de données. Je ne peux pas dire que j'aie autant entendu une liste de modèles de base de données.

Je recommanderais également fortement les modèles de modèles de données de David C. Hay et la carte A Metadata Map qui s'appuie sur la première et est beaucoup plus ambitieuse et intrigante. La Préface seule est éclairante.

Le volume 1 contient 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 à l'industrie (comptabilité, soins de santé, etc.), le volume 3 fournit des modèles de modèle de données.

Enfin, bien que ce livre soit apparemment sur UML et la modélisation d'objet, la modélisation en couleur avec UML de Peter Coad fournit un processus piloté par "archétype" de modélisation d'entités à partir du principe qu'il existe 4 archétypes principaux de tout modèle objet / données

— Michael Brown
source

1

Le livre est intitulé [Refactoring Databases: Evolutionary Database Design] [1] par Scott W. Ambler et Pramod J. Sadalage et est en effet très bon. [1]: ambysoft.com/books/refactoringDatabases.html

— Panos

3

Concernant le livre Ambler: Non, vous ne pouvez pas lister "insérer une colonne" ou "créer une contrainte FK" comme motif pour la même raison. Le livre Gang of 4 ne répertorie pas la boucle "pour" comme motif.

— Tegiri Nenashi

Ce n'est pas un modèle, c'est un refactoring. Comme extraire la méthode ou renommer le paramètre. Refactoring et motifs vont de pair.

— Michael Brown

Un à ajouter: "Patterns d'analyse" par Fowler. Similaire à Hay's stuff

— Neil McGuigan

2

Le volume 3 de Len Silverston est le seul que je considérerais comme des «modèles de conception». Les 2 premiers montrent des exemples de modèles de données qui étaient courants dans le laps de temps où les livres ont été écrits. Le volume 3 a cependant plusieurs modèles de conception pour un scénario de problème donné. Par exemple, le chapitre 4 couvre les hiérarchies / agrégations / scénarios d'égal à égal, puis propose plusieurs conceptions qui répondent aux avantages et aux inconvénients de chacun.

— DarrellNorton

46

Les modèles de conception ne sont pas des solutions trivialement 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 modèle n'est pas trivialement réutilisable. Vous pouvez cependant implémenter votre conception en duvet 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.
Relations plusieurs-à-plusieurs avec une table de bridge.
Relations un à un facultatives gérées avec des valeurs NULL dans la colonne FK.
Schéma en étoile: dimension et réalité, conception OLAP.
Conception OLTP entièrement normalisée.
Plusieurs colonnes de recherche indexées dans une dimension.
"Table de recherche" qui contient PK, 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 modèle, parfois c'est mauvais, parfois c'est bon.] C'est une table avec beaucoup de choses pré-jointes qui violent la deuxième et la troisième forme normale.
Tableau de tableau. Il s'agit d'un tableau 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 le reporting et l'analyse. C'est un anti-modèle - ne faites pas ça. Les gens le font quand même, donc c'est toujours un modèle.

La plupart des gens qui conçoivent des bases de données peuvent facilement créer une demi-douzaine "C'est un autre de ceux-là"; 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.

— S.Lott
source

Certains autres modèles que j'ai vus sont une table enfant multi-parent (c'est-à-dire, comme une note globale avec un type d'objet et un objectid qui peut se lier à n'importe quelle autre table), ou un FK auto-référentiel (c'est-à-dire, employee.manager -> employee. id). J'ai également utilisé une table de configuration singleton qui comporte de nombreuses colonnes.

— r00fus

1

Pourquoi une base de données à usage mixte est-elle exactement un anti-modèle? Que dois-je faire si je veux extraire des rapports d'une base de données?

— olive du

3

@lhnz: Vous ne pouvez pas extraire un grand nombre de rapports volumineux d'une conception de base de données transactionnelle - le verrouillage des rapports ralentira les transactions. Les jointures complexes (effectuées maintes et maintes fois) sont un autre obstacle aux performances des transactions. Vous ne pouvez pas faire les deux dans une seule base de données. Pour créer de nombreux rapports volumineux, vous devez déplacer les données dans un schéma en étoile. Le modèle de schéma en étoile est optimisé pour les rapports. Et le déplacement des données supprime tout conflit de verrouillage.

— S.Lott

La normalisation du schéma réduirait-elle les conflits de verrouillage de ligne si vous faites en sorte que les tables contiennent plus de données "cohérentes"? Ma pensée est que si une grande table servait les écritures sur 2 types d'ensembles de données mais que les deux sont sur la même ligne, cela entraînerait une contention de verrouillage inutile.

— CMCDragonkai

6

AskTom est probablement la ressource la plus utile sur les meilleures pratiques sur les bases de données Oracle. (Je tape habituellement "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 étant «comment représenter, stocker et travailler avec des données tout en conservant leur intégrité», et la conception étant le modèle relationnel). D'autres approches (généralement considérées comme obsolètes) sont les modèles de navigation et de hiérarchie (et je suis sûr que beaucoup d'autres existent).

Cela dit, vous pouvez considérer le «Data Warehousing» comme un «modèle» ou une approche quelque peu distincte dans la conception de bases de données. En particulier, vous pourriez être intéressé par la lecture du schéma Star .

— Galghamon
source

4

Après de nombreuses années de développement de bases de données, je peux dire qu'il y a des non et des questions auxquelles vous devez répondre avant de commencer:

des questions:

Voulez-vous utiliser à l'avenir un autre SGBD? Si oui, ne l'utilise pas pour des éléments SQL spéciaux du SGBD actuel. Supprimez la logique de 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 tableaux ou colonnes qui ne diffèrent qu'en minuscules et en 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 unicode, vous n'aurez aucun problème avec les pages de codes.
Donnez à chaque colonne un nom unique. Cela facilite la sélection de la colonne lors de la jointure. C'est très difficile si chaque table a une colonne "ID" ou "Nom" ou "Description". Utilisez XyzID et AbcID.
Utilisez un ensemble de ressources ou égal à pour les expressions SQL complexes. Cela facilite le passage à un autre SGBD.
Ne fait pas de cast sur aucun type de données. Un autre SGBD ne peut pas avoir ce type de données. Pour exemple, les daes Oracle n'ont pas de SMALLINT seulement un nombre.

J'espère que c'est un bon point de départ.

— Horcrux7
source

7

Bien que vos commentaires soient assez instructifs et utiles, ce ne sont pas des modèles de conception. Ce sont les meilleures pratiques. Merci,

— Sklivvz

7

Je ne suis pas d'accord avec la recommandation de noms de colonnes uniques. Je préfère dire customer.id pour lever l'ambiguïté que de dire customerid même là où il n'y a rien à lever.

— Paul Tomblin

1

Votre question est un peu vague, mais je suppose que cela UPSERTpourrait être considéré comme un modèle de conception. Pour les langues qui ne sont pas implémentées MERGE, il existe un certain nombre d'alternatives pour résoudre le problème (si une ligne appropriée existe, UPDATEsinon INSERT).

— Sören Kuklau
source

UPSERT est une commande et fait partie du langage SQL. Ce n'est pas un modèle.

— Todd R

UPSERT est une commande dans certaines variantes du langage SQL - un certain nombre de plates-formes ne l'ont pas ou ne l'ont que récemment.

— Steve Homer

@ToddR - J'ai entendu dire (un peu cyniquement) que les "modèles" ne sont en réalité rien de plus que des défauts dans un langage ou un modèle, pour lesquels l'utilisateur doit créer des solutions de contournement. Je ne sais pas ce que fait UPSERT, mais bien qu'il ait été ajouté à certains SQL et pas à d'autres, c'est un modèle.

— Martin F

1

Cela dépend de ce que vous entendez par un motif. Si vous pensez Personne / Entreprise / Transaction / Produit et autres, alors oui - il existe déjà de nombreux schémas de base de données génériques.

Si vous pensez à Factory, Singleton ... alors non - vous n'avez pas besoin de tout cela car ils sont trop bas pour la programmation DB.

Si vous songez à nommer un objet de base de données, alors c'est dans la catégorie des conventions, pas la conception en soi.

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.

— André pas le Saint
source

qu'en est-il de l'héritage de la base de données (personne, client, employé), ce genre de chose pourrait peut-être être considéré comme un modèle de conception?

— Muflix