2009-06-16 7 views
1

J'ai une base de données SQL Server, avec plus de 60 tables. Cette base de données a beaucoup de relations entre ces tables et même si elle est normalisée, elle reste complexe à utiliser en raison du grand nombre de tables.Visualiseur de structure de base de données/impression

Il existe, bien sûr, de nombreux outils qui peuvent montrer la structure de la base de données dans un diagramme. SQL Server lui-même est même capable de créer de tels diagrammes. En ce moment, je préfère utiliser DatabaseSpy d'Altova. Mais bien que cet outil ait un bon affichage visuel de la structure, il ne peut tout simplement pas imprimer la structure aussi bien. (Eh bien, il peut imprimer le diagramme mais pas de texte descriptif de la structure.)

Donc je cherche un outil pour SQL Server qui est capable de créer des diagrammes et faire des impressions de ces diagrammes plus textes supplémentaires décrivant tous les champs et liens.

Répondre

1

Quelle est la lacune avec les diagrammes de base de données SQL Server?

Dans tous les cas, ma recommandation surprenante serait d'essayer Sparx Enterprise Architect. Bien qu'il ne s'agisse pas principalement d'un outil de base de données, il peut effectuer une ingénierie inverse d'une base de données dans un modèle ER, puis créer un ou plusieurs diagrammes à partir de ce modèle. Il a une belle commande "Ajouter des éléments liés" qui vous permet de créer un nouveau diagramme pour se concentrer sur une entité; faites glisser l'entité sur le diagramme; puis ajoutez juste ces autres entités liées au premier.

Vous pouvez également personnaliser le niveau de détail affiché sur les diagrammes et imprimer les diagrammes en une ou plusieurs pages.

Oh, et c'est aussi le cas pour UML.

+0

Le défaut est que je veux une impression de la base de données sous forme d'images et de texte. Et je connais EA qui a besoin d'ODBC pour se connecter à SQL Server. Les rapports qu'il génère sont corrects mais je préférerais quelque chose d'aussi simple. EA est un gros produit tout-en-un avec beaucoup trop de fonctions. Comme un énorme couteau suisse qui est juste trop épais pour tenir dans votre poche. –

+0

"Images et texte": quel texte? Le DDL? En tout cas, je vous recommande d'essayer cette tâche avec la version actuelle, 7.5, qui a de meilleures capacités de script. Vous pourriez trouver que vous pouvez plus facilement automatiser les parties désagréables, comme le DSN ODBC. Je pense toujours que vous aurez envie de créer vos diagrammes "manuellement", afin de mettre en évidence des zones individuelles de la base de données. Je voudrais également rester à l'écart des fonctionnalités du rapport, et coller avec seulement les diagrammes, et peut-être le DDL. –

+0

Le texte serait une documentation sur les définitions de champs et d'index et les références entre les tables. (0..n, 1..n, 0..1, etc.) J'espère que je peux expliquer un rapport textuel mieux que les scripts DDL bruts à quelqu'un qui n'a aucune connaissance technique réelle. (Au moins, aucune connaissance SQL/DDL.) Le rapport serait plus important que le diagramme, sauf si le diagramme est assez clair. –

1

Quelque chose de plus d'une vingtaine de tables va toujours être difficile à schématiser et être utile/convivial.

Vous devriez jeter un oeil à la question suivante demande aujourd'hui:

How to make E-R diagram with 500 tables? (SO)
How to make E-R diagram with 500 tables? (My answer)

L'opinion générale/consensus est de ne pas tenter un grand diagramme, mais de briser la base de données vers le bas dans plusieurs diagrammes de plus petits groupes de tables gérables (par exemple basés sur la fonctionnalité ou une autre relation).

Kev

+0

Dans mon cas, environ 40% de toutes les tables ne servent qu'à des fins de recherche/filtrage. Ils ont un code et un texte et pas beaucoup plus. Ils ne doivent pas apparaître dans le diagramme, tant qu'ils sont signalés dans le texte. Les tables restantes sont complexes, mais elles ne seront pas trop encombrées dans un diagramme. Étant donné que la plupart des tables sont liées les unes aux autres, il n'est pas facile de les diviser en plusieurs diagrammes. –

+0

Alex - Je ressens ta douleur. Notre DB de production principale a ~ 150 tables que j'ai décomposées en collections de tables vaguement reliées. Ce n'était pas idéal mais m'a permis de traverser. – Kev

Questions connexes