CREATE TABLE

Documentação do PostgreSQL 8.0.0
Anterior	Início		Fim	Próxima

Parâmetros

TEMPORARY ou TEMP

Se for especificado, a tabela será criada como sendo uma tabela temporária. As tabelas temporárias são automaticamente removidas no final da sessão ou, opcionalmente, no final da transação corrente (consulte ON COMMIT abaixo). As tabelas permanentes existentes não estarão visíveis na sessão corrente enquanto existirem tabelas temporárias com o mesmo nome, a não ser que sejam referenciadas por um nome qualificado pelo esquema. [4] [5] [6] [7] [8] Todo índice criado em tabela temporária também é temporário.

Opcionalmente, pode ser escrito GLOBAL ou LOCAL antes de TEMPORARY ou de TEMP. Isto não faz qualquer diferença no PostgreSQL, mas consulte Compatibilidade.

nome_da_tabela

O nome (opcionalmente qualificado pelo esquema) da tabela a ser criada.

nome_da_coluna

O nome da coluna a ser criada na nova tabela.

tipo_de_dado

O tipo de dado da coluna. Pode incluir especificadores de matriz (array). Para obter informações adicionais sobre os tipos de dado suportados pelo PostgreSQL deve ser consultado o Capítulo 8.

DEFAULT expressão_padrão

A cláusula DEFAULT atribui um valor de dado padrão para a coluna em cuja definição está presente. O valor pode ser qualquer expressão sem variável (variable-free) (subconsultas e referências cruzadas a outras colunas da tabela corrente não são permitidas). O tipo de dado da expressão padrão deve corresponder ao tipo de dado da coluna.

A expressão padrão é utilizada em todas as operações de inserção que não especificam o valor para a coluna. Se não houver valor padrão para a coluna, então o valor padrão será o valor nulo.

INHERITS ( tabela_ancestral [, ... ] )

A cláusula opcional INHERITS (herda) especifica uma lista de tabelas das quais a nova tabela herda, automaticamente, todas as colunas.

O uso de INHERITS cria um relacionamento persistente entre a nova tabela descendente e suas tabelas ancestrais. As modificações de esquema nas tabelas ancestrais normalmente se propagam para as tabelas descendentes também e, por padrão, os dados das tabelas descendentes são incluídos na varredura das tabelas ancestrais.

Se existir o mesmo nome de coluna em mais de uma tabela ancestral é relatado um erro, a menos que o tipo de dado das colunas seja o mesmo em todas as tabelas ancestrais. Não havendo conflito, então as colunas duplicadas são combinadas para formar uma única coluna da nova tabela. Se a lista de nomes de colunas da nova tabela contiver um nome de coluna que também é herdado, da mesma forma o tipo de dado deverá ser o mesmo das colunas herdadas, e a definição das colunas será combinada em uma única coluna. Entretanto, declarações de colunas novas e herdadas com o mesmo nome não precisam especificar restrições idênticas: todas as restrições fornecidas em qualquer uma das declarações são combinadas, sendo todas aplicadas à nova tabela. Se a nova tabela especificar explicitamente um valor padrão para a coluna, este valor padrão substituirá o valor padrão das declarações herdadas da coluna. Se não especificar, toda tabela ancestral que especificar um valor padrão para a coluna deverá especificar o mesmo valor, ou será relatado um erro.

LIKE tabela_ancestral [ { INCLUDING | EXCLUDING } DEFAULTS ]

A cláusula LIKE especifica a tabela da qual a nova tabela copia automaticamente todos os nomes de coluna, seus tipos de dado, e suas restrições de não-nulo.

Diferentemente de INHERITS, a nova tabela e a tabela original ficam completamente desvinculadas após o término da criação. As modificações na tabela original não serão aplicadas à nova tabela, e não será possível incluir dados da nova tabela na varredura da tabela original.

Nas definições de coluna copiadas, as expressões padrão somente serão copiadas se for especificado INCLUDING DEFAULTS. O comportamento padrão é excluir as expressões padrão, resultando em que as colunas da nova tabela tenham padrões nulo.

WITH OIDS WITHOUT OIDS

Esta cláusula opcional especifica se as linhas da nova tabela devem possuir OIDs (identificadores de objeto) atribuídos. Se não for especificado nem WITH OIDS nem WITHOUT OIDS, o valor padrão dependerá do parâmetro de configuração default_with_oids; se a nova tabela herdar de alguma tabela que possua OIDs, então WITH OIDS é forçado mesmo que o comando contenha WITHOUT OIDS.

Se WITHOUT OIDS for especificado ou estiver implícito, a nova tabela não armazena OIDs e nenhum OID será atribuído para uma linha inserida na mesma. Normalmente isto é considerado vantajoso, uma vez que reduz o consumo de OIDs e, portanto, adia o reinício do contador de 32-bits do OID. Quando o contador reinicia, não se pode mais assumir que os OIDs sejam únicos, o que os torna muito menos úteis. Além disso, a exclusão dos OIDs da tabela reduz o espaço requerido para armazenar a tabela no disco em 4 bytes por linha (na maioria das máquinas), melhorando um pouco o desempenho.

Para remover os OIDs da tabela após esta ter sido criada deve ser utilizado o comando ALTER TABLE.

CONSTRAINT nome_da_restrição

Um nome opcional para a restrição de coluna ou de tabela. Se não for especificado, o nome será gerado pelo sistema.

NOT NULL

A coluna não pode conter valores nulos.

NULL

A coluna pode conter valores nulos. Este é o padrão.

Esta cláusula só está disponível para manter a compatibilidade com bancos de dados SQL fora do padrão. Sua utilização nos novos aplicativos é desencorajada.

UNIQUE (restrição de coluna) UNIQUE ( nome_da_coluna [, ... ] ) (restrição de tabela)

A restrição UNIQUE especifica que um grupo de uma ou mais colunas da tabela pode conter apenas valores únicos. O comportamento da restrição de unicidade de tabela é o mesmo da restrição de unicidade de coluna, mas com a capacidade adicional de conter várias colunas.

Para a finalidade de restrição de unicidade, os valores nulos não são considerados iguais.

Cada restrição de unicidade de tabela deve especificar um conjunto de colunas diferente do conjunto de colunas especificado por qualquer outra restrição de unicidade e de chave primária definida para a tabela (Senão, seria apenas a mesma restrição declarada duas vezes).

PRIMARY KEY (restrição de coluna) PRIMARY KEY ( nome_da_coluna [, ... ] ) (restrição de tabela)

A restrição de chave primária especifica que a coluna, ou colunas, da tabela podem conter apenas valores únicos (não duplicados) e não nulos. Tecnicamente a chave primária (PRIMARY KEY) é simplesmente uma combinação de unicidade (UNIQUE) com não nulo (NOT NULL), mas identificar um conjunto de colunas como chave primária também fornece metadados sobre o projeto do esquema, porque as chaves primárias implicam em que outras tabelas podem depender deste conjunto de colunas como identificador único para linhas.

Somente pode ser especificada uma chave primária para cada tabela, seja como restrição de coluna ou como restrição de tabela.

A restrição de chave primária deve especificar um conjunto de colunas diferente dos conjuntos de colunas especificados pelas restrições de unicidade definidos para a mesma tabela.

CHECK (expressão)

A cláusula CHECK especifica uma expressão, que produz um resultado booleano, que as linhas novas ou atualizadas devem satisfazer para a operação de inserção ou de atualização ser bem-sucedida. As expressões avaliadas como TRUE ou UNKNOWN são bem-sucedidas. Se alguma linha de uma operação de inserção ou de atualização produzir um resultado FALSE será lançada uma exceção de erro, e a inserção ou atualização não irá alterar o banco de dados. Uma restrição de verificação especificada como uma restrição de coluna deve fazer referência somente ao valor desta coluna, enquanto uma expressão que aparece como uma restrição de tabela pode fazer referência a várias colunas.

Atualmente as expressões CHECK não podem conter subconsultas, nem fazer referência a variáveis que não sejam colunas da linha corrente.

REFERENCES tabela_referenciada [ ( coluna_referenciada ) ] [ MATCH tipo_de_correspondência ] [ ON DELETE ação ] [ ON UPDATE ação ] (restrição de coluna) FOREIGN KEY ( coluna [, ... ] ) REFERENCES tabela_referenciada [ ( coluna_referenciada [, ... ] ) ] [ MATCH tipo_de_correspondência ] [ ON DELETE ação ] [ ON UPDATE ação ] (restrição de tabela)

Estas cláusulas especificam uma restrição de chave estrangeira, a qual requer que um grupo de uma ou mais colunas da nova tabela somente possa conter valores que correspondem a valores nas colunas referenciadas de alguma linha da tabela referenciada. Se a coluna_referenciada for omitida, será utilizada a chave primária da tabela_referenciada. As colunas referenciadas devem ser colunas de uma restrição de unicidade ou de chave primária na tabela referenciada.

Os valores inseridos nas colunas que fazem referência são comparados com os valores das colunas referenciadas da tabela referenciada utilizando o tipo de comparação especificado. Existem três tipos de comparação: MATCH FULL, MATCH PARTIAL e MATCH SIMPLE, que também é o padrão. MATCH FULL não permite uma coluna de uma chave estrangeira com várias colunas ser nula, a menos que todas as colunas da chave estrangeira sejam nulas. MATCH SIMPLE permite que algumas colunas da chave estrangeira sejam nulas, enquanto outras colunas da chave estrangeira não são nulas. MATCH PARTIAL ainda não está implementado.

Além disso, quando os dados das colunas referenciadas são modificados são realizadas certas ações nos dados das colunas desta tabela. A cláusula ON DELETE especifica a ação a ser realizada quando uma linha referenciada da tabela referenciada é excluída. Da mesma forma, a cláusula ON UPDATE especifica a ação a ser realizada quando uma coluna referenciada da tabela referenciada é atualizada para um novo valor. Se a linha for atualizada, mas a coluna referenciada não mudar de valor, nenhuma ação é executada. As ações referenciais fora NO ACTION não podem ser postergadas, mesmo que a restrição seja declarada como postergável (deferrable). Existem as seguintes ações possíveis para cada cláusula:

NO ACTION: Produz um erro indicando que a exclusão ou a atualização cria uma violação da restrição de chave estrangeira. Se a restrição for postergada, este erro será produzido em tempo de verificação de restrição se ainda houver alguma linha fazendo referência. Esta é a ação padrão.
RESTRICT: Produz um erro indicando que a exclusão ou a atualização cria uma violação da restrição de chave estrangeira. É o mesmo que NO ACTION, exceto que a verificação não é postergável.
CASCADE: Exclui qualquer linha que faça referência à linha excluída, ou atualiza o valor da coluna que faz referência para o novo valor da coluna referenciada, respectivamente.
SET NULL: Atribui o valor nulo às colunas que fazem referência.
SET DEFAULT: Atribui o valor padrão às colunas que fazem referência.

Se as colunas referenciadas forem modificadas com freqüência, é aconselhável adicionar um índice à coluna da chave estrangeira para que as ações referenciais associadas à coluna da chave estrangeira possam ser realizadas com mais eficiência.

DEFERRABLE NOT DEFERRABLE

Estas cláusulas controlam se a restrição pode ser postergada. Uma restrição que não pode ser postergada é verificada imediatamente após cada comando. A verificação das restrições postergáveis pode ser adiada para o final da transação (usando o comando SET CONSTRAINTS). O padrão é NOT DEFERRABLE. Atualmente somente as restrições de chave estrangeira aceitam esta cláusula. Todos os outros tipos de restrição não são postergáveis. [9]

INITIALLY IMMEDIATE INITIALLY DEFERRED

Se a restrição for postergável, esta cláusula especifica o instante padrão para verificar a restrição. Se a restrição for INITIALLY IMMEDIATE, então será verificada após cada instrução. Este é o padrão. Se a restrição for INITIALLY DEFERRED, então será verificada somente no final da transação. O instante de verificação da restrição pode ser alterado pelo comando SET CONSTRAINTS.

ON COMMIT

O comportamento das tabelas temporárias ao término do bloco de transação pode ser controlado utilizando ON COMMIT. As três opções são:

PRESERVE ROWS: Não é realizada nenhuma ação especial ao término da transação. Este é o comportamento padrão.
DELETE ROWS: Todas as linhas da tabela temporária são excluídas ao término de cada bloco de transação. Essencialmente, é feito um TRUNCATE automático após cada efetivação.
DROP: A tabela temporária é removida ao término do bloco de transação corrente.

TABLESPACE espaço_de_tabelas

O espaço_de_tabelas é o nome do espaço de tabelas onde a nova tabela será criada. Se não for especificado será utilizado o default_tablespace, ou o espaço de tabelas padrão do banco de dados se default_tablespace for uma cadeia de caracteres vazia.

USING INDEX TABLESPACE espaço_de_tabelas

Esta cláusula permite selecionar o espaço de tabelas onde o índice associado à restrição UNIQUE ou PRIMARY KEY será criado. Se não for especificado será utilizado o default_tablespace, ou o espaço de tabelas padrão do banco de dados se default_tablespace for uma cadeia de caracteres vazia.

Observações

Não se recomenda usar OIDs nos novos aplicativos; onde for possível, é preferível utilizar SERIAL ou outro gerador de seqüência como chave primária da tabela. Entretanto, se o aplicativo já faz uso de OIDs para identificar linhas específicas da tabela, é recomendado criar uma restrição de unicidade para a coluna oid da tabela, para garantir que os OIDs na tabela realmente identificam unicamente uma linha mesmo após o contador recomeçar. Evite supor que os OIDs são únicos entre tabelas; se for necessário um identificador único para todo o banco de dados, deve ser utilizada uma combinação de tableoid (OID de tabela) com o OID de linha para esta finalidade.

Dica: O uso de WITHOUT OIDS não é recomendado para tabelas sem chave primária, porque sem um OID e sem uma chave de dados única fica difícil identificar uma linha específica.

O PostgreSQL cria, automaticamente, um índice para cada restrição de unicidade e de chave primária para impor a unicidade. Portanto, não é necessário criar explicitamente um índice para as colunas da chave primária (Para obter mais informações deve ser consultado o comando CREATE INDEX).

Na implementação corrente as restrições de unicidade e de chave primária não são herdadas, tornando o comportamento da combinação de herança com restrição de unicidade um tanto disfuncional. [10]

Uma tabela não pode ter mais de 1600 colunas (Na prática o limite efetivo é menor, por causa da restrição do comprimento das tuplas).

Exemplos

Criar a tabela filmes e a tabela distribuidores:

CREATE TABLE filmes (
    cod_filme   char(5) CONSTRAINT pk_filmes PRIMARY KEY,
    titulo      varchar(40) NOT NULL,
    id_dist     integer NOT NULL,
    data_prod   date,
    tipo        varchar(10),
    duracao     interval hour to minute
);

CREATE TABLE distribuidores (
     id_dist    integer PRIMARY KEY DEFAULT nextval('serial'),
     nome       varchar(40) NOT NULL CHECK (nome <> '')
);

Criar uma tabela com uma matriz de 2 dimensões:

CREATE TABLE matriz2d_int (
    matriz  int[][]
);

Definir uma restrição de unicidade para a tabela filmes, usando a sintaxe de restrição de tabela. As restrições de unicidade com sintaxe de restrição de tabela podem ser definidas contendo uma ou mais colunas da tabela.

CREATE TABLE filmes (
    cod_filme   char(5),
    titulo      varchar(40),
    id_dist     integer,
    data_prod   date,
    tipo        varchar(10),
    duracao     interval hour to minute,
    CONSTRAINT  unq_data_prod UNIQUE(data_prod)
);

Definir uma restrição de verificação, usando a sintaxe de restrição de coluna:

CREATE TABLE distribuidores (
    id_dist     integer CHECK (id_dist > 100),
    nome        varchar(40)
);

Definir uma restrição de verificação, usando a sintaxe de restrição de tabela:

CREATE TABLE distribuidores (
    id_dist     integer,
    nome        varchar(40)
    CONSTRAINT  chk_dist CHECK (id_dist  > 100 AND nome <> '')
);

Definir uma restrição de chave primária para a tabela filmes, usando a sintaxe de restrição de tabela, As restrições de chave primária com sintaxe de restrição de tabela podem ser definidas usando uma ou mais colunas da tabela.

CREATE TABLE filmes (
    cod_filme   char(5),
    titulo      varchar(40),
    id_dist     integer,
    data_prod   date,
    tipo        varchar(10),
    duracao     interval hour to minute,
    CONSTRAINT  pk_filmes PRIMARY KEY(cod_filme,titulo)
);

Definir a restrição de chave primária para a tabela distribuidores. Os dois exemplos abaixo são equivalentes, o primeiro utiliza a sintaxe de restrição de tabela, e o segundo utiliza a sintaxe de restrição de coluna.

CREATE TABLE distribuidores (
    id_dist     integer,
    nome        varchar(40),
    PRIMARY KEY(id_dist)
);

CREATE TABLE distribuidores (
    id_dist     integer PRIMARY KEY,
    nome        varchar(40)
);

O comando abaixo especifica uma constante literal como o valor padrão para a coluna nome, faz o valor padrão da coluna id_dist ser gerado pela seleção do próximo valor de um objeto de seqüência, e faz o valor padrão da coluna data_mod ser o momento em que a linha foi inserida.

CREATE TABLE distribuidores (
    nome        varchar(40) DEFAULT 'Luso Filmes',
    id_dist     integer DEFAULT nextval('seq_distribuidores'),
    data_mod    timestamp DEFAULT current_timestamp
);

Definir duas restrições de coluna NOT NULL na tabela distribuidores, sendo que uma das restrições recebe um nome fornecido explicitamente:

CREATE TABLE distribuidores (
    id_dist     integer CONSTRAINT nao_nulo NOT NULL,
    nome        varchar(40) NOT NULL
);

Definir uma restrição de unicidade para a coluna nome:

CREATE TABLE distribuidores (
    id_dist     integer,
    nome        varchar(40) UNIQUE
);

Mesma coisa, especificado como uma restrição de tabela:

CREATE TABLE distribuidores (
    id_dist     integer,
    nome        varchar(40),
    UNIQUE(nome)
);

Criar a tabela cinemas no espaço de tabelas diskvol1:

CREATE TABLE cinemas (
    id    serial,
    nome  text,
    local text
) TABLESPACE diskvol1;

Para proteger a tabela permanente, criar uma tabela temporária idêntica à tabela permanente permitindo alterar os dados durante o bloco de transação sem afetar a tabela permanente. A tabela temporária será removida ao final do bloco de transação. Abaixo está mostrado o arquivo nomes.sql contendo os comandos SQL para esta finalidade: [11]

/*
 * Criar a tabela permanente e inserir duas linhas
 */
CREATE TABLE nomes(nome text);
INSERT INTO nomes VALUES('Nome 1');
INSERT INTO nomes VALUES('Nome 2');
\pset border 2
\C 'Tabela nomes antes do início do bloco de transação (permanente)'
SELECT * FROM nomes;
/*
 * Iniciar o bloco de transação, criar uma tabela temporária
 * idêntica à tabela permanente, copiar as linhas da tabela
 * permanente para a tabela temporária, inserir uma nova
 * linha na tabela temporária e, por último, modificar todas
 * as linhas da tabela temporária.
 */
START TRANSACTION;
CREATE TEMPORARY TABLE nomes (LIKE nomes) ON COMMIT DROP;
INSERT INTO nomes SELECT * FROM public.nomes;
INSERT INTO nomes VALUES('Nome 3');
UPDATE nomes SET nome = nome || ' (temporário)';
\C 'Tabela nomes dentro do bloco de transação (temporária)'
SELECT * FROM nomes;
COMMIT;
/*
 * Após o término da transação a tabela temporária é removida e a
 * tabela permanente passa a ser enxergada sem precisar ser qualificada
 * pelo nome do esquema
 */
\C 'Tabela nomes após o término do bloco de transação (permanente)'
SELECT * FROM nomes;

A seguir está mostrado o resultado do processamento do arquivo:

# psql -U teste -f nomes.sql -o nomes.out -q teste
# cat nomes.out
Tabela nomes antes do início do bloco de transação (permanente)
+--------+
|  nome  |
+--------+
| Nome 1 |
| Nome 2 |
+--------+
(2 linhas)

Tabela nomes dentro do bloco de transação (temporária)
+---------------------+
|        nome         |
+---------------------+
| Nome 1 (temporário) |
| Nome 2 (temporário) |
| Nome 3 (temporário) |
+---------------------+
(3 linhas)

Tabela nomes após o término do bloco de transação (permanente)
+--------+
|  nome  |
+--------+
| Nome 1 |
| Nome 2 |
+--------+
(2 linhas)

Compatibilidade

O comando CREATE TABLE está em conformidade com o SQL-92 e com um subconjunto do SQL:1999, com as exceções listadas abaixo.

Tabelas temporárias

Embora a sintaxe de CREATE TEMPORARY TABLE se pareça com a do padrão SQL, o efeito não é o mesmo. No padrão as tabelas temporárias são definidas apenas uma vez, passando a existir automaticamente (começando com um conteúdo vazio) para todas as sessões que necessitarem destas. Em vez disso, o PostgreSQL requer que cada sessão execute seu próprio comando CREATE TEMPORARY TABLE para cada tabela temporária a ser utilizada, permitindo que sessões diferentes usem o mesmo nome de tabela temporária para finalidades diferentes, enquanto a abordagem do padrão obriga todas as instâncias de um determinado nome de tabela temporária ter a mesma estrutura de tabela.

A definição do padrão para o comportamento de tabelas temporárias é amplamente ignorado. O comportamento do PostgreSQL neste ponto é semelhante ao de vários outros bancos de dados SQL.

A distinção feita pelo padrão entre tabelas temporárias globais e locais não está presente no PostgreSQL, uma vez que esta distinção depende do conceito de módulos, que o PostgreSQL não possui. Por motivo de compatibilidade, o PostgreSQL aceita as palavras chave GLOBAL e LOCAL na declaração da tabela temporária, mas elas não produzem efeito.

A cláusula ON COMMIT para as tabelas temporárias também lembra o padrão SQL, mas possui algumas diferenças. Se a cláusula ON COMMIT for omitida, o padrão SQL especifica que o comportamento padrão deverá ser ON COMMIT DELETE ROWS. Entretanto, o comportamento padrão no PostgreSQL é ON COMMIT PRESERVE ROWS. A opção ON COMMIT DROP não existe no padrão SQL.

Restrições de verificação de coluna

O padrão SQL diz que as restrições de coluna CHECK só podem fazer referência à coluna onde estão aplicadas; somente as restrições de tabela CHECK podem fazer referência a várias colunas. O PostgreSQL não impõe esta restrição; as restrições CHECK de coluna e de tabela são tratadas da mesma maneira.

"Restrição" NULL

A "restrição" NULL (na verdade uma não restrição) é uma extensão do PostgreSQL ao padrão SQL incluída para manter a compatibilidade com alguns outros sistemas de banco de dados (e por simetria com a restrição NOT NULL). Uma vez que este é o padrão para qualquer coluna, sua presença é desnecessária.

Herança

Heranças múltiplas por meio da cláusula INHERITS é uma extensão do PostgreSQL à linguagem. O SQL:1999 (mas não o SQL-92) define herança única utilizando uma sintaxe diferente e semânticas diferentes. O estilo de herança do SQL:1999 ainda não é suportado pelo PostgreSQL.

Identificadores de Objeto (Object IDs)

O conceito de OIDs (identificadores de objeto) do PostgreSQL não é padrão.

Tabelas sem coluna

O PostgreSQL permite a criação de tabelas sem colunas (por exemplo, CREATE TABLE foo();). Isto é uma extensão ao padrão SQL, que não permite tabelas com zero coluna. As tabelas sem coluna não são muito úteis, mas se não forem permitidas criam um caso especial para o comando ALTER TABLE DROP COLUMN e, por isso, parece mais simples ignorar esta restrição contida na especificação.

Espaços de tabelas

O conceito de espaços de tabelas do PostgreSQL não faz parte do padrão. Portanto, as cláusulas TABLESPACE e USING INDEX TABLESPACE são extensões.

[1]	4.3 — Tabelas — A tabela é uma coleção ordenada de uma ou mais colunas e uma coleção não ordenada de zero ou mais linhas. Cada linha possui, para cada coluna, exatamente um valor do tipo de dado desta coluna. As linhas da tabela possuem um tipo, chamado "o tipo linha"; toda linha da tabela possui o mesmo tipo linha, que também é o tipo linha da tabela. (ISO-ANSI Working Draft) Framework (SQL/Framework), August 2003, ISO/IEC JTC 1/SC 32, 25-jul-2003, ISO/IEC 9075-1:2003 (E) (N. do T.)
[2]	4.14.1 — Introdução a tabelas — A tabela é uma coleção de linhas possuindo uma ou mais colunas. A linha é um valor do tipo linha. Toda linha da mesma tabela possui o mesmo tipo linha. O valor do i-ésimo campo de toda linha da tabela é o valor da i-ésima coluna desta linha da tabela. A linha é a menor unidade de dados que pode ser inserida na tabela e excluída da tabela. (ISO-ANSI Working Draft) Foundation (SQL/Foundation), August 2003, ISO/IEC JTC 1/SC 32, 25-jul-2003, ISO/IEC 9075-2:2003 (E) (N. do T.)
[3]	4.6.6.3 — Restrições de tabela — A restrição de tabela é uma restrição de integridade associada a uma única tabela base. A restrição de tabela é uma entre restrição de unicidade, restrição de chave primária, restrição referencial ou restrição de verificação. A restrição de unicidade especifica uma ou mais colunas da tabela como colunas únicas. A restrição de unicidade é satisfeita se, e somente se, não existirem duas linhas da tabela com os mesmos valores não-nulos nas colunas únicas. A restrição de chave primária é a restrição de unicidade que especifica PRIMARY KEY. A restrição de chave primária é satisfeita se, e somente se, não existirem duas linhas da tabela com os mesmos valores não-nulos nas colunas únicas, e nenhum dos valores da coluna ou colunas especificadas for o valor nulo. A restrição referencial especifica uma ou mais colunas como colunas que fazem referência, e as colunas referenciadas correspondentes em alguma (não necessariamente distinta) tabela base, referida como tabela referenciada. Estas colunas referenciadas são colunas únicas de alguma restrição de unicidade da tabela referenciada. A restrição referencial está sempre satisfeita se, para toda linha da tabela que faz referência, os valores das colunas que fazem referência são iguais àqueles das colunas referenciadas correspondentes de alguma linha da tabela referenciada. Entretanto, se estiverem presentes valores nulos a satisfação da integridade referencial depende do tratamento especificado para os nulos (conhecido como o tipo de correspondência). Podem ser especificadas ações referenciais para determinar que alterações devem ser feitas na tabela que faz referência se, de outra forma, uma alteração na tabela referenciada causasse a violação da restrição referencial. Uma restrição de verificação de tabela especifica uma condição de procura. A restrição é violada se o resultado da condição de procura for falso para qualquer linha da tabela (mas não se for desconhecido). (ISO-ANSI Working Draft) Framework (SQL/Framework), August 2003, ISO/IEC JTC 1/SC 32, 25-jul-2003, ISO/IEC 9075-1:2003 (E) (N. do T.)
[4]	DB2 — O comando DECLARE GLOBAL TEMPORARY TABLE define uma tabela temporária para a sessão corrente. A descrição da tabela temporária declarada não aparece no catálogo do sistema. A tabela não é persistente e não pode ser compartilhada por outras sessões. Toda sessão que define uma tabela temporária global declarada com o mesmo nome possui sua própria descrição única da tabela temporária. Quando a sessão termina, as linhas da tabela são excluídas, e a descrição da tabela temporária é removida. Para fazer referência a uma tabela temporária global declarada em um comando SQL (exceto DECLARE GLOBAL TEMPORARY TABLE), a tabela deve ser explícita ou implicitamente qualificada pelo nome de esquema SESSION. Se o nome da tabela não for qualificado por SESSION, as tabelas temporárias globais declaradas não serão consideradas ao resolver a referência. DB2 Universal Database (N. do T.)
[5]	SQL Server — As tabelas temporárias são semelhantes às tabelas permanentes, exceto que as tabelas temporárias são armazenadas no banco de dados tempdb, e removidas automaticamente quando não estão mais em uso. Existem dois tipos de tabela temporária, local e global, que diferem um do outro pelos seus nomes, visibilidade e disponibilidade. As tabelas temporárias locais possuem um único caractere cerquilha (#) como o primeiro caractere de seus nomes; são visíveis apenas pela conexão corrente para o usuário, e são removidas quando o usuário se desconecta de instâncias do SQL Server. As tabelas temporárias globais possuem dois caracteres cerquilha (##) como os primeiros caracteres de seus nomes; são visíveis para qualquer usuário após serem criadas, e são removidas quando todos os usuários fazendo referência à tabela desconectam da instância do SQL Server. Books Online — Creating and Modifying Table Basics (N. do T.)
[6]	Oracle — CREATE TABLE — Deve ser especificado GLOBAL TEMPORARY para indicar que a tabela é temporária e que sua definição é enxergada por todas as sessões. Os dados da tabela temporária são enxergados apenas pela sessão que inseriu os dados na tabela. A definição da tabela temporária tem a mesma persistência da definição de uma tabela regular, mas contém dados específicos da sessão ou específicos da transação. É especificado se os dados são específicos da sessão ou da transação através das palavras chave ON COMMIT. Oracle® Database SQL Reference 10g Release 1 (10.1) Part Number B10759-01 (N. do T.)
[7]	Oracle — Tabelas temporárias — Além das tabelas permanentes, o Oracle pode criar tabelas temporárias para armazenar dados privativos da sessão, que existirão somente enquanto durar a transação ou a sessão. O comando CREATE GLOBAL TEMPORARY TABLE cria uma tabela temporária que pode ser específica da sessão ou específica da transação. Para as tabelas temporárias específicas da transação, os dados existirão enquanto durar a transação. Para as tabelas temporárias específicas da sessão, os dados existirão enquanto durar a sessão. Os dados das tabelas temporárias são privativos da sessão. Cada sessão somente enxerga e modifica seus próprios dados. Não são obtidos bloqueios da DML nos dados das tabelas temporárias. O comando LOCK não possui nenhum efeito na tabela temporária, porque cada sessão possui seus dados privativos. O comando TRUNCATE aplicado a uma tabela temporária específica da sessão trunca os dados da própria sessão. Não trunca os dados de outras sessões que estão utilizando a mesma tabela. Os comandos da DML aplicados a tabelas temporárias não geram registros de refazer para as alterações nos dados. Entretanto são gerados registros de desfazer para os dados e registros de refazer para os registros de desfazer. Os dados nas tabelas temporárias serão excluídos automaticamente no caso da sessão terminar, tanto quando o usuário se desconectar como quando a sessão terminar de forma anormal por uma falha na sessão ou na instância, por exemplo. Podem ser criados índices nas tabelas temporárias utilizando o comando CREATE INDEX. Os índices criados nas tabelas temporárias também são temporários, e os dados do índice possuem o mesmo escopo de sessão ou de transação dos dados da tabela temporária. Podem ser criadas visões que acessam tanto as tabelas temporárias quanto as tabelas permanentes. Podem ser criados gatilhos para as tabelas temporária. Oracle® Database Concepts 10g Release 1 (10.1) Part Number B10743-01 (N. do T.)
[8]	4.14.2 — Tipos de tabela — A tabela é uma tabela base, uma tabela derivada, ou uma tabela transiente. A tabela base é uma tabela base persistente, uma tabela temporária global, uma tabela temporária local criada, ou uma tabela temporária local declarada. A tabela base persistente é uma tabela com nome definida por uma <definição de tabela> que não especifica TEMPORARY. A tabela derivada é uma tabela derivada direta ou indiretamente a partir de uma ou mais tabelas pela avaliação de uma <expressão de consulta> cujo resultado possui um tipo de elemento que é um tipo linha. Os valores da tabela derivada são derivados dos valores das tabelas subjacentes quando a <expressão de consulta> é avaliada. A tabela vista é uma tabela derivada com nome definida por uma <definição de visão>. A tabela vista algumas vezes é chamada de visão. A tabela transiente é uma tabela com nome que poderá vir a existir implicitamente durante a avaliação de uma <expressão de consulta> ou a execução de um gatilho. A tabela temporária global é uma tabela com nome definida por uma <definição de tabela> que especifica GLOBAL TEMPORARY. A tabela temporária local criada é uma tabela com nome definida por uma <definição de tabela> que especifica LOCAL TEMPORARY. As tabelas temporárias global e local criada são efetivamente materializadas somente quando referenciadas em uma sessão-SQL. Todo módulo cliente-SQL de toda sessão-SQL que faz referência a uma tabela temporária local criada faz com que uma instância distinta da tabela temporária local criada seja materializada. Ou seja, o conteúdo da tabela temporária global e da tabela temporária local criada não pode ser compartilhado entre sessões-SQL. Na linguagem SQL o nome e o escopo do nome da tabela temporária global e da tabela temporária local criada são indistinguíveis dos da tabela base persistente. Entretanto, uma vez que o conteúdo da tabela temporária global é distinto entre sessões-SQL, e o conteúdo da tabela temporária local criada é distinto dentro dos módulos cliente-SQL dentro das sessões-SQL, o <nome do esquema> efetivo do esquema onde a tabela temporária global ou a tabela temporária local criada é instanciada é um <nome do esquema> dependente da implementação, que pode ser visto como tendo sido efetivamente derivado do <nome do esquema> do esquema onde a tabela temporária global ou a tabela temporária local criada é definido e do identificador da sessão-SQL dependente da implementação associado à sessão SQL. A tabela temporária local declarada é uma tabela temporária local do módulo. A tabela temporária local declarada é acessível apenas por procedimentos chamados externamente no módulo cliente-SQL que contém a <declaração de tabela temporária> que declara a tabela temporária local declarada. (ISO-ANSI Working Draft) Foundation (SQL/Foundation), August 2003, ISO/IEC JTC 1/SC 32, 25-jul-2003, ISO/IEC 9075-2:2003 (E) (N. do T.)
[9]	4.17.2 — Verificação da restrição — Toda restrição é postergável (deferrable) ou não-postergável (non-deferrable). Dentro de uma transação SQL toda restrição possui um modo de restrição; se a restrição for não-postergável, então seu modo de restrição será sempre imediato, senão será imediato ou postergado. Toda restrição possui um modo de restrição inicial que especifica o modo da restrição no início de cada transação SQL e imediatamente após a definição da restrição. Se a restrição for postergável, então seu modo de restrição poderá ser mudado (de imediato para postergado, ou de postergado para imediato) pela execução do <comando para definir modo de restrição>. (ISO-ANSI Working Draft) Foundation (SQL/Foundation), August 2003, ISO/IEC JTC 1/SC 32, 25-jul-2003, ISO/IEC 9075-2:2003 (E) (N. do T.)
[10]	disfunção — dificuldade ou problema de funcionamento. PRIBERAM - Língua Portuguesa On-Line (N. do T.)
[11]	Exemplo escrito pelo tradutor, não fazendo parte do manual original.

Anterior	Principal	Próxima
CREATE SEQUENCE	Acima	CREATE TABLE AS