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

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

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

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:

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

3. Relations un à un facultatives gérées avec des valeurs NULL dans la colonne FK.

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

5. Conception OLTP entièrement normalisée.

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

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

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

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

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

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 .

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.

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

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.