Modèles De Bases De Données Relationnelles?

voici un lien vers un homme 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 construire une base de données rapidement, 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 aurez probablement besoin de modifier ce point de départ. Je l'ai trouvé très utile.

d'autre part SQL Server Magazine a une colonne occasionnelle appelée "le modélisateur de données" qui est très instructive et contient souvent des schémas complets pour un système donné.

design patterns are not trivially reusable solutions.

modèles de Conception réutilisables, par définition. Ils sont des modèles vous détecter dans d'autres bonnes solutions.

un motif n'est pas trivialement réutilisable. Vous pouvez mettre en œuvre votre conception suivant le modèle.

patters de conception relationnelle inclure des choses comme:

1. Un-à-Plusieurs relations (maître-détail, parent-enfant) relations utilisant une clé étrangère.

2. Plusieurs-à-Plusieurs liens avec une table de bridge.

3. en Option un-à-un les relations géré avec des valeurs Null dans le FK colonne.

4. Star-Schéma: Faits et de Dimension, de conception OLAP.

5. conception OLTP entièrement normalisée.

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

7. "Lookup table" qui contient PK, la description et la valeur de code(s) utilisé par une ou plusieurs applications. Pourquoi avoir un 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, il est parfois mauvais, parfois que c'est bon.] Ceci est une table avec beaucoup de choses pré-jointées qui viole la deuxième et la troisième forme normale.

9. tableau. C'est un tableau qui viole première forme normale en ayant un tableau ou d'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 beaucoup d'indices supplémentaires pour la déclaration et l'analyse. C'est un anti-pattern-ne pas ce faire. Les gens le font de toute façon, donc c'est toujours un modèle.

la plupart des gens qui conçoivent des bases de données peuvent facilement se débarrasser d'une demi-douzaine "c'est un autre de ceux-là"; ce sont des modèles de conception qu'ils utilisent sur une base régulière.

et cela ne comprend pas les modes administratifs et opérationnels d'utilisation et de gestion.

découvrez ce blog - Le Programmeur de Base de données .

il décrit certains patterns 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 novatrices à des problèmes communs, dont la plupart sont des modèles de conception réutilisables.

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

AskTom est probablement la seule ressource la plus utile sur les meilleures pratiques sur Oracle DBs. (Je tape habituellement juste "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 tandis que 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 hiérarchiques (et je suis nure beaucoup d'autres existent).

cela dit, vous pourriez considérer l '" entreposage de données "comme un" modèle " 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 sur le schéma D'Étoile .

après de nombreuses années de développement de la base de données, je peux dire qu'il y a certains non goes et une question à laquelle vous devez répondre avant de commencer:

questions:

• voulez-vous utiliser à l'avenir un autre SGBD? Si oui, alors ne pas utiliser à la substance spéciale SQL des SGBD actuels. Supprimez la logique dans votre application.

ne pas utiliser:

• espaces blancs dans les noms de tableaux et de colonnes
• les caractères Non Ascii dans les noms de table et colonne
• liant à un cas inférieur ou supérieur 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 tableaux ou de colonnes comme "FROM"," BETWEEN"," DELETE", etc

recommandations:

• utilisez NVARCHAR ou des équivalents pour le support unicode alors vous n'avez aucun problème avec les codepages.
• donne à chaque colonne un nom unique. Cela rend plus facile sur jointure pour sélectionner la colonne. Il est très difficile si chaque table a une colonne "ID" ou "nom" ou "Description". Utilisez XyzID et AbcID.
• utilisez un faisceau de ressources ou des égaux pour les expressions SQL complexes. Il easer pour basculer vers un autre SGBD.
• Ne plonge pas sur n'importe quel type de données. Un autre SGBD ne peut pas avoir ce type de données. Par exemple Oracle daes n'ont pas un 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 UPSERT pourrait être considéré comme un motif. Pour les langues qui n'implémentent pas MERGE , il existe un certain nombre d'alternatives pour résoudre le problème (si une rangée appropriée existe, UPDATE ; sinon INSERT ).

dépend de ce que vous entendez par motif. Si vous pensez personne/entreprise/Transaction / produit et tel, alors oui - il ya beaucoup de schémas génériques de base de données déjà disponibles.

si vous pensez usine, Singleton... alors non - vous n'avez pas besoin de ceux-ci car ils sont trop bas niveau pour la programmation DB.

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

BTW, S. Lott, un-à-plusieurs et plusieurs-à-plusieurs liens ne sont pas des "modèles". Ce sont les éléments de base du modèle relationnel.

ce livre semble intéressant

Title: Data Patterns
By: Microsoft Corporation
Publisher: Microsoft Press
Pub. Date: December 21, 2004
Print ISBN-13: 978-0-7356-2200-5