Nome da tabela
aprendeu recentemente singular está correto
Sim. Cuidado com os pagãos. Os nomes plurais nas tabelas são um sinal claro de alguém que não leu nenhum dos materiais padrão e não tem conhecimento da teoria do banco de dados.
Algumas das coisas maravilhosas sobre os padrões são:
- todos eles são integrados um ao outro
- eles trabalham juntos
- eles foram escritos por mentes maiores que as nossas, por isso não precisamos debatê-las.
O nome da tabela padrão refere-se a cada linha da tabela, que é usada em toda a verborragia, não ao conteúdo total da tabela (sabemos que a Customer
tabela contém todos os clientes).
Relação, frase verbal
Nos bancos de dados relacionais genuínos que foram modelados (em oposição aos sistemas de arquivamento de registros anteriores à década de 1970 [caracterizados por Record IDs
serem implementados em um contêiner de banco de dados SQL por conveniência):
- as tabelas são os sujeitos do banco de dados, portanto são substantivos , novamente, singulares
- os relacionamentos entre as tabelas são as ações que ocorrem entre os substantivos; portanto, são verbos (ou seja, não são numerados ou nomeados arbitrariamente)
- esse é o predicado
- tudo o que pode ser lido diretamente do modelo de dados (consulte meus exemplos no final)
- (o predicado de uma tabela independente (o principal pai de uma hierarquia) é que é independente)
- assim, a frase verbal é cuidadosamente escolhida, para que seja a mais significativa e evite termos genéricos (isso se torna mais fácil com a experiência). A frase verbal é importante durante a modelagem, pois auxilia na resolução do modelo, ou seja. esclarecendo relações, identificando erros e corrigindo os nomes das tabelas.
Diagrama_A
Obviamente, o relacionamento é implementado no SQL como CONSTRAINT FOREIGN KEY
na tabela filho (mais, mais tarde). Aqui está a frase de verbo (no modelo), o predicado que representa (a ser lido no modelo) e o nome da restrição FK :
Initiates
Each Customer Initiates 0-to-n SalesOrders
Customer_Initiates_SalesOrder_fk
Tabela • Idioma
No entanto, ao descrever a tabela, particularmente em linguagem técnica, como os Predicados ou outra documentação, use o singular e o plural como naturalmente no idioma inglês. Lembre-se de que a tabela é nomeada para a única linha (relação) e o idioma se refere a cada linha derivada (relação derivada):
Each Customer initiates zero-to-many SalesOrders
não
Customers have zero-to-many SalesOrders
Então, se eu tenho uma tabela "user" e produtos que somente o usuário terá, a tabela deve ser denominada "user-product" ou apenas "product"? Este é um relacionamento de um para muitos.
(Essa não é uma questão de convenção de nomenclatura; é uma questão de design do db.) Não importa se user::product
é 1 :: n. O que importa é se product
é uma entidade separada e se é uma Tabela Independente , ie. pode existir por si só. Portanto product
não user_product
.
E se product
existe apenas no contexto de um user
, ie. é uma tabela dependente , portanto user_product
.
Diagrama_B
Além disso, se eu tivesse (por algum motivo) várias descrições de produtos para cada produto, seria "user-product-description" ou "product-description" ou apenas "description"? É claro que com as chaves estrangeiras corretas definidas .. Nomear apenas a descrição seria problemático, pois eu também poderia ter descrição do usuário ou descrição da conta ou qualquer outra coisa.
Está certo. O user_product_description
xor product_description
estará correto, com base no acima. Não é para diferenciá-lo de outro xxxx_descriptions
, mas para dar ao nome uma sensação de onde ele pertence, o prefixo sendo a tabela pai.
E se eu quiser uma tabela relacional pura (muitas para muitas) com apenas duas colunas, como seria isso? "user-stuff" ou talvez algo como "rel-user-stuff"? E se o primeiro, o que distinguiria isso, por exemplo "produto do usuário"?
Esperamos que todas as tabelas no banco de dados relacional sejam puramente relacionais, tabelas normalizadas. Não há necessidade de identificar isso no nome (caso contrário, todas as tabelas serão rel_something
).
Se ele contiver apenas as PKs dos dois pais (que resolvem o relacionamento lógico n :: n que não existe como uma entidade no nível lógico, em uma tabela física ), é uma Tabela Associativa . Sim, normalmente o nome é uma combinação dos dois nomes de tabela pai.
Observe que nesses casos a frase verbal se aplica a, e é lida como, de pai para pai, ignorando a tabela filho, porque seu único objetivo na vida é relacionar os dois pais.
Diagrama_C
Se é não uma tabela associativa (isto é. Para além das duas PKs, que contém dados), em seguida, nomeia-o de forma adequada, e as frases de verbo aplicar a ele, não o pai no final da relação.
Diagrama_D
Se você terminar com duas user_product
tabelas, é um sinal muito alto de que você não normalizou os dados. Então, volte algumas etapas e faça isso e nomeie as tabelas com precisão e consistência. Os nomes então se resolverão.
Convenção de nomes
Qualquer ajuda é muito apreciada e, se houver algum tipo de padrão de convenção de nomenclatura recomendado por vocês, fique à vontade para vincular.
O que você está fazendo é muito importante e afetará a facilidade de uso e entendimento em todos os níveis. Portanto, é bom obter o máximo de compreensão possível desde o início. A relevância da maior parte disso não ficará clara até você começar a codificar no SQL.
Case é o primeiro item a ser abordado. Todas as letras maiúsculas são inaceitáveis. A combinação de maiúsculas e minúsculas é normal, especialmente se as tabelas estiverem diretamente acessíveis pelos usuários. Consulte meus modelos de dados. Observe que, quando o buscador está usando algum NonSQL demente, que possui apenas letras minúsculas, eu dou isso; nesse caso, incluo sublinhados (conforme seus exemplos).
Mantenha um foco de dados , não um aplicativo ou foco de uso. Afinal, em 2011, possuímos Arquitetura Aberta desde 1984, e os bancos de dados devem ser independentes dos aplicativos que os utilizam.
Dessa forma, à medida que crescem e mais do que o único aplicativo os usa, a nomeação permanecerá significativa e não precisará de correção. (Os bancos de dados completamente incorporados em um único aplicativo não são bancos de dados.) Nomeie apenas os elementos de dados.
Seja muito atencioso e nomeie tabelas e colunas com muita precisão . Não use UpdatedDate
se for um DATETIME
tipo de dados, use UpdatedDtm
. Não use _description
se ele contém uma dosagem.
É importante ser consistente em todo o banco de dados. Não use NumProduct
em um local para indicar o número de Produtos e ItemNo
ou ItemNum
em outro local para indicar o número de Itens. Use NumSomething
para números de e / SomethingNo
ou SomethingId
identificadores de forma consistente.
Não prefixe o nome da coluna com um nome de tabela ou código de acesso, como user_first_name
. O SQL já fornece o nome da tabela como um qualificador:
table_name.column_name -- notice the dot
Exceções:
A primeira exceção é para PKs, elas precisam de tratamento especial porque você as codifica em junções, o tempo todo e deseja que as chaves se destacem das colunas de dados. Sempre use user_id
, nunca id
.
- Observe que este não é um nome de tabela usado como prefixo, mas um nome descritivo adequado para o componente da chave:
user_id
é a coluna que identifica um usuário, não o id
da user
tabela.
- (Exceto, é claro, nos sistemas de arquivamento de registros, onde os arquivos são acessados por substitutos e não há chaves relacionais, existem uma e a mesma coisa).
- Sempre use exatamente o mesmo nome para a coluna-chave onde quer que a PK seja transportada (migrada) como uma FK.
- Portanto, a
user_product
tabela terá user_id
um componente como seu PK (user_id, product_no)
.
- a relevância disso ficará clara quando você começar a codificar. Primeiro, com
id
muitas tabelas, é fácil se misturar na codificação SQL. Segundo, qualquer pessoa que não seja o codificador inicial não tem ideia do que estava tentando fazer. Ambos são fáceis de impedir, se as colunas principais forem tratadas como acima.
A segunda exceção é onde há mais de um FK referenciando a mesma tabela da tabela pai, transportada no filho. De acordo com o Modelo Relacional , use Nomes de Função para diferenciar o significado ou uso, por exemplo. AssemblyCode
e ComponentCode
para dois PartCodes
. E nesse caso, não use o indiferenciado PartCode
para um deles. Seja preciso.
Diagrama_E
Prefixo
Onde você tem mais do que 100 tabelas, prefixe os nomes das tabelas com uma Área de Assunto:
REF_
para tabelas de referência
OE_
para o cluster de entrada de pedidos, etc.
Somente no nível físico, não no lógico (ele atrapalha o modelo).
Sufixo
Nunca use sufixos em tabelas e sempre use sufixos em todo o resto. Isso significa que, no uso lógico e normal do banco de dados, não há sublinhados; mas no lado administrativo, sublinhados são usados como um separador:
_V
Exibir (com o principal TableName
na frente, é claro)
_fk
Chave estrangeira (o nome da restrição, não o nome da coluna) Transação de segmento de
_cac
cache (processo ou função armazenada) Função (não transacional), etc.
_seg
_tr
_fn
O formato é o nome da tabela ou do FK, um sublinhado e o nome da ação, um sublinhado e, finalmente, o sufixo.
Isso é realmente importante porque quando o servidor fornece uma mensagem de erro:
____blah blah blah error on object_name
você sabe exatamente qual objeto foi violado e o que estava tentando fazer:
____blah blah blah error on Customer_Add_tr
Chaves estrangeiras (a restrição, não a coluna). A melhor nomeação para um FK é usar a frase de verbo (menos o "each" e a cardinalidade).
Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk
Use a Parent_Child_fk
sequência, não Child_Parent_fk
porque (a) ela aparece na ordem de classificação correta quando você está procurando por elas e (b) sempre conhecemos a criança envolvida, o que estamos imaginando é qual pai. A mensagem de erro é maravilhosa:
____ Foreign key violation on Vendor_Offers_PartVendor_fk
.
Isso funciona bem para pessoas que se preocupam em modelar seus dados, onde as frases verbais foram identificadas. Quanto ao resto, os sistemas de arquivamento de registros, etc, uso Parent_Child_fk
.
Os índices são especiais, portanto, eles têm uma convenção de nomenclatura própria, composta de, em ordem , cada posição de caractere de 1 a 3:
U
Exclusivo ou _
para separador em cluster não exclusivo
C
ou _
para
_
separador não em cluster
Para o restante:
Observe que o nome da tabela não é obrigatório no nome do índice, porque sempre aparece comotable_name.index_name.
Portanto, quando Customer.UC_CustomerId
ou Product.U__AK
aparece em uma mensagem de erro, isso indica algo significativo. Quando você olha para os índices em uma tabela, é possível diferenciá-los facilmente.
Encontre alguém qualificado e profissional e siga-o. Observe seus designs e estude cuidadosamente as convenções de nomenclatura que eles usam. Faça perguntas específicas sobre qualquer coisa que você não entenda. Por outro lado, corra como qualquer outro que demonstre pouca consideração por convenções ou padrões de nomes. Aqui estão alguns para você começar:
- Eles contêm exemplos reais de todos os itens acima. Faça perguntas renomeando perguntas neste tópico.
- Obviamente, os modelos implementam várias outras normas, além das convenções de nomenclatura; você pode ignorá-las por enquanto ou pode fazer novas perguntas específicas .
- São várias páginas cada, o suporte a imagens embutidas no Stack Overflow é para os pássaros e não são carregados consistentemente em diferentes navegadores; então você terá que clicar nos links.
- Observe que os arquivos PDF têm navegação completa; portanto, clique nos botões de vidro azul ou nos objetos em que a expansão é identificada:
- Os leitores que não estão familiarizados com o Relational Modeling Standard podem achar útil a Notação IDEF1X .
Entrada e inventário de pedidos com endereços compatíveis com o padrão
Sistema de boletim inter-office simples para PHP / MyNonSQL
Monitoramento de sensores com capacidade temporal total
Respostas às perguntas
Isso não pode ser razoavelmente respondido no espaço para comentários.
Larry Lustig:
... até o exemplo mais trivial mostra ...
Se um cliente tem produtos de zero a muitos e um produto tem componentes de um a muitos e um componente tem fornecedores de um a muitos, e um fornecedor vende zero para muitos componentes e um SalesRep tem clientes um para muitos Quais são os nomes "naturais" das tabelas que contêm Clientes, produtos, componentes e fornecedores?
Existem dois grandes problemas no seu comentário:
Você declara que seu exemplo é "o mais trivial", no entanto, é tudo menos. Com esse tipo de contradição, não tenho certeza se você é sério, se tecnicamente capaz.
Essa especulação "trivial" tem vários erros grosseiros de Normalização (DB Design).
Até você corrigi-las, elas não são naturais e anormais, e não fazem nenhum sentido. Você também pode chamá-los de anormal_1, anormal_2, etc.
Você tem "fornecedores" que não fornecem nada; referências circulares (ilegais e desnecessárias); clientes que compram produtos sem nenhum instrumento comercial (como Fatura ou Pedido de Vendas) como base para a compra (ou os clientes "possuem" produtos?); relacionamentos muitos-para-muitos não resolvidos; etc.
Uma vez Normalizado, e as tabelas necessárias forem identificadas, seus nomes se tornarão óbvios. Naturalmente.
De qualquer forma, tentarei atender à sua consulta. O que significa que terei que acrescentar algum sentido a ela, sem saber o que você quis dizer, então, por favor, tenha paciência comigo. Os erros grosseiros são muitos para listar e, dada a especificação de reposição, não estou confiante de ter corrigido todos eles.
Assumirei que, se o produto é composto de componentes, o produto é um conjunto e os componentes são usados em mais de um conjunto.
Além disso, como "O fornecedor vende componentes de zero a muitos", que eles não vendem produtos ou conjuntos, eles vendem apenas componentes.
Especulação vs modelo normalizado
Caso você não saiba, a diferença entre cantos quadrados (Independente) e cantos arredondados (Dependente) é significativa, consulte o link de Notação IDEF1X. Da mesma forma, as linhas sólidas (identificação) vs linhas tracejadas (não identificação).
... quais são os nomes "naturais" das tabelas que contêm Clientes, produtos, componentes e fornecedores?
- Cliente
- produtos
- Componente (ou AssemblyComponent, para aqueles que percebem que um fato identifica o outro)
- Fornecedor
Agora que resolvi as tabelas, não entendo seu problema. Talvez você possa postar uma pergunta específica .
VoteCoffee:
Como você está lidando com o cenário que Ronnis postou em seu exemplo, onde existem vários relacionamentos entre duas tabelas (user_likes_product, user_bought_product)? Posso entender mal, mas isso parece resultar em nomes de tabelas duplicados usando a convenção que você detalhou.
Supondo que não haja erros de normalização, User likes Product
é um predicado, não uma tabela. Não os confunda. Consulte minha resposta, onde se relaciona com assuntos, verbos e predicados, e minha resposta a Larry imediatamente acima.
Cada tabela contém um conjunto de fatos (cada linha é um fato). Predicados (ou proposições) não são fatos, podem ou não ser verdadeiros.
O Modelo Relacional é baseado no Cálculo de Predicado de Primeira Ordem (mais conhecido como Lógica de Primeira Ordem). Um Predicado é uma frase de cláusula única em inglês simples e preciso, avaliada como verdadeira ou falsa.
Além disso, cada tabela representa ou é a implementação de muitos Predicados, não um.
Uma consulta é um teste de um Predicado (ou vários Predicados, encadeados) que resulta em verdadeiro (o Fato existe) ou falso (o Fato não existe).
Assim, as tabelas devem ser nomeadas, conforme detalhado em minha resposta (convenções de nomenclatura), para a linha, o Fato e os Predicados devem ser documentados (por todos os meios, faz parte da documentação do banco de dados), mas como uma lista separada de Predicados .
Esta não é uma sugestão de que eles não são importantes. Eles são muito importantes, mas não vou escrever isso aqui.
Rapidamente, então. Como o Modelo Relacional é baseado no FOPC, pode-se dizer que todo o banco de dados é um conjunto de declarações do FOPC, um conjunto de Predicados. Mas (a) existem muitos tipos de Predicados e (b) uma tabela não representa um Predicado (é a implementação física de muitos Predicados e de diferentes tipos de Predicados).
Portanto, nomear a tabela como "o" predicado que ela "representa" é um conceito absurdo.
Os "teóricos" conhecem apenas alguns Predicados, eles não entendem que, desde que o RM foi fundado na FOL, todo o banco de dados é um conjunto de Predicados e de tipos diferentes.
E, é claro, eles escolhem os absurdos dentre os poucos que sabem EXISTING_PERSON
:; PERSON_IS_CALLED
. Se não fosse tão triste, seria hilário.
Observe também que o nome padrão ou da tabela atômica (nomeando a linha) funciona de maneira brilhante para toda a verborragia (incluindo todos os Predicados anexados à tabela). Por outro lado, o idiota "tabela representa predicado" nome não pode. O que é bom para os "teóricos", que entendem muito pouco sobre predicados, mas retardam o contrário.
Os Predicados relevantes para o modelo de dados são expressos no modelo e são de duas ordens.
Predicado Unário
O primeiro conjunto é diagramático , não texto: a notação em si . Estes incluem vários Existential; Orientado a restrições; e predicados do descritor (atributos).
- Obviamente, isso significa que apenas aqueles que podem 'ler' um modelo de dados Padrão podem ler esses Predicados. É por isso que os "teóricos", que são severamente prejudicados por sua mentalidade somente de texto, não conseguem ler modelos de dados, por que se apegam à sua mentalidade somente de texto anterior a 1984.
Predicado binário
O segundo conjunto é aquele que forma relacionamentos entre os fatos. Esta é a linha de relação. A frase verbal (detalhada acima) identifica o predicado, a proposição que foi implementada (que pode ser testada via consulta). Não se pode ficar mais explícito que isso.
- Portanto, para quem é fluente em modelos de dados padrão, todos os Predicados relevantes são documentados no modelo. Eles não precisam de uma lista separada de Predicados (mas os usuários, que não podem 'ler' tudo do modelo de dados, precisam!).
Aqui está um Modelo de Dados , onde listei os Predicados. Eu escolhi esse exemplo porque mostra os Predicados Existenciais, etc., bem como os Relacionados, os únicos Predicados não listados são os Descritores. Aqui, devido ao nível de aprendizado do candidato, estou tratando-o como um usuário.
Portanto, o evento de mais de uma tabela filha entre duas tabelas pai não é um problema, apenas nomeie-as como Fato Existencial quanto ao seu conteúdo e normalize os nomes.
As regras que eu dei para frases verbais para nomes de relacionamento para tabelas associativas entram em jogo aqui. Aqui está uma discussão Predicado x Tabela , cobrindo todos os pontos mencionados, em resumo.
Para uma boa descrição curta do uso adequado dos Predicados e de como usá-los (que é um contexto bem diferente do de responder aos comentários aqui), visite esta resposta e role para baixo até a seção Predicado .
Charles Burns:
Por sequência, eu quis dizer o objeto no estilo Oracle puramente usado para armazenar um número e o próximo de acordo com alguma regra (por exemplo, "add 1"). Como o Oracle não possui tabelas de identificação automática, meu uso típico é gerar IDs exclusivos para PKs da tabela. INSERIR EM foo (id, somedata) VALORES (foo_s.nextval, "data" ...)
Ok, é o que chamamos de tabela Key ou NextKey. Nomeie como tal. Se você tiver SubjectAreas, use COM_NextKey para indicar que é comum no banco de dados.
Btw, esse é um método muito ruim de gerar chaves. Não é escalável, mas com o desempenho da Oracle, provavelmente está "muito bem". Além disso, indica que seu banco de dados está cheio de substitutos, não relacionais nessas áreas. O que significa desempenho extremamente ruim e falta de integridade.
primarily opinion-based
é patentemente falso.