Existe um termo genérico para tabelas e visualizações?

Postgres (e também álgebra relacional ) os chama de relações - coisas tabulares de linhas e colunas que você pode consultar. Isso inclui tabelas, visualizações, visualizações materializadas, tabelas temporárias ou até mesmo resultados de consultas temporários.

Eu evitaria o termo "objeto de banco de dados" se você realmente quer dizer apenas relações, já que "objetos de banco de dados" também incluem esquemas, índices, usuários, sequências, políticas, definições de coluna, tipos, funções e muito mais. Objetos de banco de dados são os objetos que são manipulados com DDL , enquanto (os dados dentro) as relações são manipuladas com DML .

Uma "coisa com colunas e linhas" é uma relação . Esta é a palavra que Codd usou em seu artigo seminal , iniciando a revolução do RDBM.

Uma "coisa que pode mudar, mas mantém sua identidade" - é uma entidade . Uma única linha de uma relação representa uma entidade quando você pode encontrar uma chave exclusiva que a representa. Se você tiver duas colunas não exclusivas: evente date- as linhas não formarão entidades, porque alterar qualquer um dos atributos altera completamente o significado da linha. Se você adicionar uma coluna adicional (como id) ou se tornar dateexclusiva, obterá linhas que funcionam como entidades (não importa se é uma exibição ou uma tabela, ou o resultado de uma junção).

Um objeto de banco de dados é apenas isso: uma coisa gerenciada pelo seu servidor de banco de dados. Pode ser uma tabela ou uma visão, mas também pode ser um usuário ou um procedimento armazenado.

Resultado é o nome da parte da API (por exemplo, JDBC) que representa seus resultados (possivelmente uma relação ou um cursor) em algum outro ambiente de programação (por exemplo, Java runtime).

Mas a verdade é que em um ambiente profissional real, vale tudo. As pessoas confundem essas palavras e geralmente não se importam. Caramba, eu não me importo.

Definir

Voltando ao básico, uma tabela é um conjunto de registros. Uma visão é uma tabela virtual, calculada ou materializada, o que significa que ainda é apenas um conjunto de registros.

Fonte da tabela

A documentação da Microsoft usa <table_source> no BNF para indicar qualquer origem de linhas - uma tabela ou exibição ou uma das várias funções com valor de tabela.

Apenas "mesa" :-)

Eu usei esse termo em sala de aula por muitos anos sem confusão.

Na maioria das vezes, as pessoas com quem você está falando não entendem ou não se importam com a diferença entre uma mesa ou uma vista. Com razão - tudo o que eles precisam saber é "onde consigo os dados para fazer meu trabalho?"

Apenas explique, "aqui está uma lista de tabelas, escolha a que você precisa". Claro, você não nomeou tabelas e visualizações de forma diferente com alguns tibbling estúpido, certo…?

Que tal Tabular? Implica "tabularidade", o que significa que funciona como uma mesa e tem as características de uma mesa, mas não é necessariamente uma mesa.

Da Techopedia

Objeto de banco de dados

Um objeto de banco de dados em um banco de dados relacional é uma estrutura de dados usada para armazenar ou referenciar dados. O objeto mais comum com o qual as pessoas interagem é a mesa. Outros objetos são índices, procedimentos armazenados, sequências, visualizações e muito mais.

Quando um objeto de banco de dados é criado, um novo tipo de objeto não pode ser criado porque todos os vários tipos de objeto criados são restritos pela própria natureza, ou código-fonte, do modelo de banco de dados relacional que está sendo usado, como Oracle, SQL Server ou Access. O que está sendo criado são instâncias dos objetos, como uma nova tabela, um índice nessa tabela ou uma exibição na mesma tabela.

Referência adicional...

Objetos do SQL Server

Objetos de banco de dados Oracle

Acho que a principal resposta para o termo "relação" é ótima, especialmente quando se fala de bancos de dados em teoria. Mas acho que não é tão apropriado quando se fala em implementação de um sistema de banco de dados real, na prática. O raciocínio é que existem muitas construções que existem em uma implementação real do sistema de banco de dados e que variam entre as implementações que não são discutidas ou abordadas na teoria do banco de dados. Exemplos disso podem incluir procedimentos armazenados, variáveis ​​de tabela, funções com valor de tabela OPENQUERY()(na implementação do Microsoft SQL Server), CTEs, subconsultas etc.

Como é evidente nas muitas discussões ao longo deste Post, parece que pessoas diferentes têm interpretações diferentes de quais construções físicas adicionais elas consideram uma relação, mas a teoria do banco de dados não está ciente dessas construções. Acho que a pergunta do OP é bastante ampla, o que provoca a grande variedade de respostas exibidas aqui, mas acho que a maioria delas depende do contexto em que você deseja falar.

Dito isto, é por isso que acredito que as respostas a seguir também sejam corretas ao falar sobre essas construções em uma forma física. Quando uma Tabela existe em um sistema de banco de dados, ela é concreta, consideravelmente é uma instância de um objeto como um objeto de coleção de dados em um aplicativo em execução, aqui o sistema de banco de dados é o aplicativo em execução. Outras construções fisicamente implementadas que podem retornar " dados tabulares" (como formulado pelo OP), por exemplo, funções com valor de tabela ou variáveis ​​de tabela também podem ser considerados objetos, quando se referem a eles no contexto de uma implementação real do sistema de banco de dados. Posso falar sobre esses constructos desvinculados do conjunto de dados (relações) que eles podem guardar/retornar e focar em sua própria existência como objetos físicos, se for esse o contexto que escolho falar sobre eles.

É por isso que gosto da resposta de Brendan para o termo "Database Object". Eu também não descartaria a palavra "entidade".

ORMs, como o Entity Framework da Microsoft, consideram todos os objetos de banco de dados (tabelas, exibições, procedimentos armazenados, etc) como entidades, acredito. Isso está no contexto dos modelos que representam estruturalmente o objeto (normalmente como uma classe) antes de ser realmente instanciado.

Então, pessoalmente, gosto de usar o termo entidade quando estou falando de um conceito lógico antes da instanciação do modelo sed, ou mais a montante, quando um esquema lógico está sendo definido, como por meio de um diagrama de banco de dados. Acho que entidade é um bom termo para descrever a estrutura de uma coisa sem que ela precise ser realizada fisicamente .

Mas ao falar sobre uma representação concreta, como uma instância de um objeto Table no aplicativo, ou a Tabela compilada concretamente na camada de banco de dados, acho que objeto de banco de dados também é um bom termo para usar.