Qual é a diferença entre entidade e tabela em um banco de dados?

A primeira diferença entre entidade e tabela em um banco de dados é que uma entidade não existe em um banco de dados ou no SQL. É conceitual. Enquanto uma tabela é uma construção física em um banco de dados e SQL.

ENTIDADES E ATRIBUTOS

Uma entidade é uma coleção ou contêiner de atributos em um CDM (Modelo de Dados Conceitual) que pode ou não se tornar uma tabela. O termo entidade foi usado por Chen, o criador do conceito original de modelagem de dados chamado Diagrama de Relacionamento de Entidades (Modelo Entidade-Relacionamento). Este é um CDM de nível muito alto, mostrando apenas entidades e seus relacionamentos, não as propriedades de uma entidade, atributos.

CDMs são independentes da plataforma de destino. A idéia por trás de um CDM mais refinado é mostrar entidades e atributos usando nomes de idiomas de negócios, tipos de dados orientados a negócios (por exemplo, caracteres em vez de CHAR) e outras propriedades de metadados.

Algumas entidades podem ser abstratas e nunca são convertidas em tabelas. Por exemplo, o exemplo da ferramenta de modelagem PowerDesigner acima usa entidades abstratas (retângulo branco) para armazenar atributos que podem ser herdados por uma ou várias entidades.

As entidades podem suportar uma abordagem mais orientada a objetos? Sim, então pode. A entidade Entidades no diagrama acima pode representar qualquer objeto de interesse; por exemplo, pessoas, organizações (empresas, grupos), locais, documentos (permissões, licenças); et al. Esses objetos são diferenciados pelo tipo de entidade "P", pessoas; Sites "S"; "O", Organizações ... O Tipo de Entidade pode ser decomposto em Subtipos de Entidades.

TABELAS E COLUNAS

Tabelas e colunas são a terminologia usada por Codd, o pai do RDBMS. Os Modelos de Dados Físicos (PDMs) contêm implementação física de um banco de dados específico - como visualizações, gatilhos, procedimentos armazenados e índices de pesquisa de texto completo - que variam de RDBMS a RDBMS. O PDM mostra nomes físicos, geralmente abreviados e maiúsculos - pelo menos no caso do Oracle.

Pessoalmente, sou contra os nomes altamente abreviados porque a empresa não os entende. Certamente, pode-se nomear adequadamente algo em 30 caracteres mais orientado ao usuário e isso também oferecerá suporte a Business Intelligence de autoatendimento? Nessa linha, em outros bancos de dados, uso nomes de colunas de maiúsculas e minúsculas em vez de maiúsculas. Ainda uso maiúsculas para nomes de tabelas, pois as diferencia das colunas nos modelos e nos bancos de dados.

Os bancos de dados NÃO devem ser projetados para facilitar as coisas para os desenvolvedores, mas para torná-los mais compreensíveis para os negócios aos quais estão apoiando. Para saber mais sobre esse e outros problemas de design, consulte Modelagem de dados - o porquê.

Atenciosamente, Terra Encounters

Uma "entidade" de um modelo de banco de dados é uma construção lógica. Uma "tabela" de um banco de dados é uma construção física. Ambos são expressões do mesmo conceito. Por exemplo, a tabela "pessoa" representa o que logicamente consideramos uma "pessoa".

Para enfatizar, os atributos da construção lógica da "pessoa" são mapeados de perto para as colunas da construção física, de modo que cada tupla na entidade - linha na tabela - modela a pessoa para as necessidades dos negócios.

Observe a falta de citações pessoalmente. Isso ocorre porque, no último uso, a palavra pessoa é sobre o conceito como você pensa em sua mente quando ouve a palavra, e não a limitação que imporíamos a ela em um modelo.

Um pouco sobre modelos lógicos v. Físicos

Um modelo de banco de dados lógico está relacionado às regras de negócios, dados de referência, chaves primárias e alternativas. No mais puro sentido, esse modelo não teria nenhuma preocupação com o mecanismo de banco de dados (Oracle, MySQL, etc) em que será implementado.

Um modelo de banco de dados físico é a implementação do modelo lógico com alterações feitas para a realidade do mecanismo de banco de dados subjacente. Quando o modelo lógico estiver pronto para ser implementado fisicamente:

  • entidades se tornam tabelas (seu exemplo específico) chaves primárias tornam-se restrições de chave primária; chaves alternativas (ou naturais) se tornam índices exclusivos

Um exemplo dessa tradução pode ser assim:

Recebi um modelo lógico em sua forma mais pura. Disseram-me para implementá-lo no MySQL usando o InnoDB. O modelo lógico não usa chaves substitutas (termo lógico) ou físicas (termo físico). Estes são os números inteiros seqüenciados, com incremento automático, geralmente usados ​​como chave primária.

Como, como um DBA físico, sei que o InnoDB grava dados no disco como nós-folha da restrição de chave primária, sei que obterá pesquisas muito mais rápidas se forem usadas chaves substitutas. Trabalho com o modelador lógico (ou assumo a tarefa) para implementá-los, para que o mecanismo atenda às necessidades de negócios (bem como ao próprio modelo).

Outros exemplos gerais:

  • Pegue as chaves do modelo lógico e implemente-as de maneira diferente no modelo físico, com base na maneira como os otimizadores de consulta funcionam. Normalize os relacionamentos de uma entidade para obter desempenho. Crie uma coluna exclusiva em uma tabela de referência para garantir que o código do aplicativo não use diretamente chaves substitutas. (manutenção aprimorada do código do aplicativo)