Como documentar uma base de dados [fechada]
(nota: eu sei que isto está perto de Como documenta a estrutura da sua base de dados?Mas não acho que seja idêntico.)
Comecei a trabalhar num local com uma base de dados com centenas de mesas e vistas, todas com nomes crípticos com poucas vogais e sem documentação. Eles também não permitem mudanças gratuitas no esquema de banco de dados, nem posso tocar em qualquer banco de dados, exceto o teste em minha própria máquina (que é explodido e recriado regularmente), então eu não posso adicionar comentários que ajudariam qualquer um. Tentei usar "Toad" para criar um diagrama das urgências, mas depois de o deixar a funcionar durante 48 horas seguidas, ainda não tinha produzido nada visível e precisava do meu computador de volta. Eu estava conversando com algumas outras contratações recentes e todos nós sugerimos que sempre que temos intrigado o que uma tabela em particular ou o que algumas de suas colunas significam, nós devemos atualizá-la nos desenvolvedores wiki. Então, qual é a boa maneira de fazer isto? Basta listar tabelas / vistas e suas colunas e preenchê-las enquanto vamos? As ferramentas básicas que tenho que dar São Toad, o "desenvolvedor SQL" da Oracle, MS Office, e Visio.10 answers
- Descrição do que a tabela significa e como é funcionalmente utilizado (na IU, etc.)
- descrições do que cada atributo significa, se não for óbvio
- explicações das relações (chaves estrangeiras) desta tabela para outras, e vice-versa
- explicações de restrições adicionais e / ou gatilhos
- explicação adicional das principais opiniões e procs que tocam a tabela, se ainda não estiverem bem documentadas
Com tudo o que precede, não documente para documentar-documentação que o óbvio só atrapalha as pessoas. Em vez disso, concentre-se nas coisas que o confundiram no início, e passe alguns minutos escrevendo explicações muito claras e concisas. Isso vai ajudá-lo a pensar bem, e vai ajudar massivamente outros desenvolvedores que encontram essas tabelas pela primeira vez.
Como outros já mencionaram, há uma grande variedade de ferramentas para ajudá-lo a geri-lo, como o arquiteto da empresa., Red Gate SQL Doc, e as ferramentas incorporadas de vários vendedores. Mas enquanto o Suporte de ferramentas é útil (e mesmo crítico, em bases de dados maiores), fazer o trabalho duro de compreensão e explicando o modelo conceitual da base de dados é a verdadeira vitória. Dessa perspectiva, você pode até fazê - lo em um arquivo de texto (embora fazê-lo em forma Wiki permitiria que várias pessoas colaborassem na adição a essa documentação de forma incremental-assim, cada vez que alguém descobre algo, eles podem adicioná-lo ao corpo crescente de documentação instantaneamente).A utilização da facilidade de comentários não faz quaisquer alterações ao próprio esquema, apenas adiciona dados à tabela de Catálogos do USER_TAB_COMMENTS.
Usamos o arquitecto da empresa para as nossas definições de DB. Incluímos procedimentos armazenados, gatilhos e todas as definições de tabelas definidas em UML. As três características brilhantes do programa são:
- importar diagramas UML de uma ligação ODBC.
- Gerar Scripts SQL (DDL) para todo o DB de uma vez
- gerar documentação Templada personalizada do seu DB.
Você pode editar as definições de classe / tabela dentro da ferramenta UML, e gerar uma descritivo com imagens incluídas documento. O documento autogenerado pode estar em vários formatos, incluindo o MSWord. Temos apenas menos de 100 mesas no nosso esquema, e é bastante controlável.
Nunca fiquei tão impressionado com qualquer outra ferramenta nos meus 10 anos como desenvolvedor. A EA suporta Oracle, MySQL, SQL Server (várias versões), PostGreSQL, Interbase, DB2, e Access in one fell swoop. Sempre que tive problemas, os fóruns deles responderam prontamente aos meus problemas. Altamente recomendado!!Quando as alterações de DB entram, fazemos em seguida em EA, gerar o SQL, e verificá-lo em nosso controle de versão (svn). Nós usamos Hudson para a construção, e ele auto-constrói a base de dados a partir de scripts quando ele vê que você modificou o checked-in SQL.
Primeiro importa o esquema (todas as tabelas, vistas, procedimentos e funções armazenados - com gatilhos, chaves estrangeiras, etc.). Então você define domínios/módulos lógicos e agrupa todos os objetos (drag & drop) neles para ser capaz de analisar e trabalhar em pedaços menores de banco de dados. Para cada módulo, você cria um diagrama ERD e escreve uma descrição de nível superior. Em seguida, como você descobrir o Significado de tabelas e vistas escrever uma breve descrição para cada. Faça o mesmo para cada coluna. O Dataedo permite-lhe adicionar um título significativo para cada objecto e coluna – é útil se os nomes dos objectos são vagos ou inválidos. A versão Pro permite – lhe descrever chaves estrangeiras, chaves/restrições únicas e gatilhos-o que é útil mas não essencial para compreender uma base de dados.
Pode aceder à documentação através da UI ou pode exportá-la para PDF ou HTML interactivo (esta última está disponível apenas na versão Pro).
Descrito aqui é um processo contínuo em vez de um trabalho de uma vez. Se a sua base de dados mudar (por exemplo. novas colunas, vistas) deverá sincronizar a sua documentação com base regular (alguns cliques com Dataedo).
Ver documentação da amostra: http://dataedo.com/download/Dataedo%20repository.pdf
Algumas orientações sobre o processo de documentação:
Diagramas:
- mantenha os seus diagramas pequenos e legíveis – basta incluir tabelas, relações e colunas importantes-apenas aquele que tem algum significado para compreender uma grande imagem-chaves primárias/empresariais, atributos importantes e relações,
- usar uma cor diferente para a chave quadros num diagrama,
- pode ter mais do que um diagrama por módulo,
- pode adicionar um diagrama à descrição das tabelas mais importantes/com a maioria das relações.
Descrições:
- Não documente o óbvio – não escreva a descrição "Data do documento" para o documento.coluna de data. Se não há nada significativo a acrescentar, deixa-o em branco.
- se os objectos armazenados em tabelas têm tipos ou estatutos, é bom listá-los na descrição geral de uma tabela,
- Defina o formato que é esperado, por exemplo. "mm / dd / aa" para uma data armazenada no campo de texto,
- Lista todos os valores conhecidos / importantes an o seu significado, por exemplo, para a coluna de Estado pode ser algo como isto: "status do documento: a-Active, C-cancelado, D-Deleted",
- se houver alguma API numa tabela – uma vista que deve ser usada para ler dados e função / procedimentos para inserir / actualizar dados – listá-la na descrição da tabela,
- descrever onde é que as linhas/colunas' os valores vêm de (procedimento, forma, interface, etc.) ,
- usar a marca "[depreciado] " (ou similar) para colunas que não devem ser usadas (a coluna do título é útil para isto, explique qual o campo que deve ser usado em vez do campo Descrição).
Uma solução wiki suporta hiperlinks e edição colaborativa, mas um wiki é tão bom quanto as pessoas que o mantêm organizado e atualizado. Você precisa de alguém para assumir a propriedade do projeto de documento, independentemente da ferramenta que você usa. Essa pessoa pode envolver outras pessoas com conhecimento para preencher os detalhes, mas uma pessoa deve ser responsável pela organização da informação.
Se você não pode usar uma ferramenta para gerar um ERD por engenharia reversa, você terá que projetar um à mão usando TOAD ou VISIO.Qualquer ERD com centenas de objectos é provavelmente inútil como guia para os programadores, porque será ilegível com tantas caixas e linhas. Em um banco de dados com tantos objetos, é provável que existam "sub-sistemas" de algumas dezenas de tabelas e vistas cada. Então você deve fazer diagramas personalizados destes sub-sistemas, em vez de esperar uma ferramenta para fazê-lo para você.
Você também pode desenhar um pseudo-ERD, onde grupos de tabelas são representados por um único objeto em um diagrama, e esse grupo é expandido em outro diagrama.
Um único ERD ou conjunto de ERD não são suficientes para documentar um sistema desta complexidade, tal como um diagrama de classes seria adequado para documentar um sistema OO. Terá de escrever um documento, usando o ERD como ilustrações. Você precisa de descrições de texto do significado e uso de cada tabela, cada coluna, e as relações entre tabelas (especialmente quando essas relações estão implícitas em vez de representado por restrições de integridade referencial).
Tudo isto dá muito trabalho, mas valerá a pena. Se houver um lugar claro e atualizado onde o esquema está documentado, toda a equipe vai se beneficiar dele.A opção mais barata e mais leve é baixar o Visiomodeler GRATUITAMENTE do MS, e fazer o mesmo com isso.
O ORM (chame-o de ORMDB) é a única ferramenta que alguma vez encontrei que suporta e encoraja o desenho de bases de dados conversas com Não-IS stakeholders sobre objetos de BL e relacionamentos.
Reality check-on the way to generating your DDL, it passes through a full-stop ERD phase where you can satisfy your questions about it does anything screwy. Provavelmente vai mostrar-te fraquezas no ERD que tu próprio desenhaste.A ORMDB é um caso clássico do princípio de que quanto mais conceptual for a ferramenta, menor será o mercado. As raparigas só se querem divertir, e os programadores só ... quero codificar.
Se descrever as suas bases de dados aos seus utilizadores finais for o seu objectivo principal Ooluk Data Dictionary Manager pode revelar-se útil. É um software multi-usuário baseado na web que lhe permite anexar Descrições a tabelas e colunas e permite pesquisas de texto completo sobre essas descrições. Ele também permite que você logicamente agrupar tabelas usando etiquetas e navegar tabelas usando essas etiquetas. As tabelas, bem como as colunas, podem ser marcadas para encontrar itens de dados semelhantes em toda a sua base de dados/bases de dados.
O 'software' permite-lhe importar informação de meta-dados, como o nome da tabela, o nome da coluna, o tipo de dados da coluna, as chaves estrangeiras para o seu repositório interno, usando uma API. Suporte para Fontes de dados JDBC vem embutido e pode ser estendido ainda mais como a fonte da API é distribuída sob ASL 2.0. É codificado para ler os comentários / observações de muitos RDBMSs.Você pode sempre anular manualmente a informação importada. A informação que você pode armazenar sobre tabelas e colunas pode ser estendida usando personalizado campo.
O Gestor de dicionário de dados usa a terminologia "objeto de dados" e "Atributo" em vez de tabela e coluna, porque não é projetado especificamente para bases de dados relacionais.
Notas
- Se descrever aspectos técnicos da sua base de dados como gatilhos, índices, estatísticas é importante Este software não é a melhor opção. No entanto, é possível combinar uma solução técnica com esta software que utiliza campos personalizados de hiperligação.
- o software não produz um ERD
Divulgação: eu trabalho na empresa que desenvolve este produto.
Bem, uma imagem diz mil palavras por isso eu recomendaria a criação de diagramas ER onde você pode ver a relação entre tabelas de um relance, algo que é difícil de fazer com uma descrição apenas de texto.
Não é preciso fazer toda a base de dados num diagrama, separá-la em secções. Usamos o paradigma Visual no trabalho, mas EA é uma boa alternativa como ERWIN, e sem dúvida há muitos outros que são igualmente bons.
Se tiver paciência, então use html para documentar as tabelas e Colunas torna sua documentação mais fácil de acessar.