O que é uma chave primária em um banco de dados? Restrições de chaves primárias e estrangeiras Descrição chave primária estrangeira

16.10.2023

São utilizados em qualquer atividade: nos setores bancário e financeiro, turismo, armazéns, produção e formação. São uma coleção de tabelas, possuem propriedades claras e estão sujeitas a requisitos rigorosos. Em bancos de dados relacionais, as tabelas são chamadas de relacionamentos.

O que é uma chave primária em um banco de dados

Em um banco de dados, a chave primária de uma tabela é uma de suas colunas (Chave primária). Vejamos um exemplo de como isso se parece. Vamos imaginar uma atitude simples de estudantes universitários (vamos chamá-la de “Estudantes”).

Precisamos identificar exclusivamente um aluno usando uma coluna. Para fazer isso, as informações nesta coluna devem ser exclusivas para cada entrada. Mas os dados disponíveis a este respeito não permitem identificar de forma inequívoca o registo, uma vez que homónimos, homónimos e alunos com os mesmos apelidos e nomes podem estudar no mesmo curso e na mesma faculdade. A chave primária no banco de dados é usada para identificar com precisão a linha necessária em um relacionamento. Na maioria das vezes, um campo numérico é usado nesta capacidade, aumentando automaticamente à medida que um registro é inserido (coluna de identificador de incremento automático).

Chave Primária Simples e Composta

A chave primária pode ser simples ou composta. Se a unicidade de um registro for determinada pelo valor em apenas um campo, conforme descrito acima, estamos lidando com uma chave simples. Uma chave composta é uma chave primária de banco de dados que consiste em dois ou mais campos. Considere a seguinte atitude dos clientes do banco.

NOME COMPLETO.	Data de nascimento	Série Passaporte	número do passaporte
Ivanov P. A.	12.05.1996	75	0553009
Sergeyev V.T.	14.07.1958	71	4100654
Krasnov L.V.	22.01.2001	73	1265165

Os passaportes das pessoas podem conter as mesmas séries ou números, mas não existem passaportes com a mesma série e combinação de números. Assim, os campos “Série do Passaporte” e “Número do Passaporte” passarão a ser uma chave composta do relacionamento especificado, identificando a pessoa de forma única.

Conexões entre relacionamentos

Portanto, uma chave primária em um banco de dados é uma ou mais colunas de uma tabela que permite identificar exclusivamente uma linha nesse relacionamento. Para que serve?

Voltemos ao primeiro exemplo com a relação “Alunos”. Além desse relacionamento, o banco de dados também armazena outras informações, por exemplo, o desempenho de cada aluno. Para não repetir todas as informações que já estão contidas no banco de dados, utilizam uma chave, referente ao registro desejado. Se parece com isso.

Nos dois relacionamentos de exemplo, vemos um campo de ID. Estas são as chaves primárias no banco de dados para essas tabelas. Como você pode ver, o histórico acadêmico contém apenas links para esses campos de outras tabelas sem a necessidade de indicar todas as informações delas.

Chave natural e substituta

Como é determinada a chave primária de uma tabela de banco de dados? Os dois exemplos que analisamos – “Estudantes” e “Clientes Bancários” – ilustram os conceitos de chaves naturais e substitutas. Na tabela de clientes do banco, definimos uma chave composta pelos campos “Número” e “Série Passaporte”, utilizando colunas já existentes. Essa chave é chamada de natural; não fizemos nenhuma alteração ou acréscimo para determiná-la. No caso da relação “Alunos”, nenhum campo ou combinação de campos nos deu singularidade. Isso nos forçou a inserir um campo adicional de código de aluno. Essa chave é chamada de chave substituta, para a qual adicionamos outra coluna de serviço à tabela. Esta coluna não contém nenhuma informação útil e serve apenas para identificar registros.

Chave estrangeira e integridade de dados no banco de dados

Todos os itens acima nos levam à chave estrangeira e à integridade do banco de dados. Chave estrangeira é um campo que se refere à chave primária de um relacionamento estrangeiro. Na tabela de progresso, estas são as colunas “Aluno” e “Disciplina”. Seus dados nos remetem a tabelas externas. Ou seja, o campo “Aluno” na relação “Desempenho” é uma chave estrangeira, e na relação “Aluno” é a chave primária do banco de dados.

Um princípio importante para a construção de bancos de dados é a sua integridade. E uma de suas regras é a integridade referencial. Isso significa que uma chave estrangeira de uma tabela não pode referir-se a uma chave primária inexistente de outra relação. Não é possível excluir um registro com o código 1000 - Ivan Ivanov do relacionamento Estudante se ele estiver referenciado por um registro da tabela de desempenho acadêmico. Em um banco de dados construído corretamente, ao tentar excluí-lo, você receberá um erro informando que este campo está em uso.

Existem outros grupos de regras de integridade, bem como outras restrições de banco de dados, que também merecem atenção e devem ser levadas em consideração pelos desenvolvedores.

A Figura mostra uma tabela (rácio de grau 5) contendo algumas informações sobre os empregados de uma empresa hipotética. As linhas da tabela correspondem a tuplas. Cada linha é na verdade uma descrição de um objeto do mundo real (neste caso, um trabalhador), cujas características estão contidas nas colunas. Os relacionamentos relacionais correspondem a conjuntos de entidades e as tuplas correspondem a entidades. As colunas de uma tabela que representam um relacionamento relacional são chamadas atributos.

Cada atributo é definido em um domínio, portanto um domínio pode ser pensado como o conjunto de valores válidos para um determinado atributo. Vários atributos do mesmo relacionamento, e até mesmo atributos de relacionamentos diferentes, podem ser definidos no mesmo domínio.

Um atributo cujo valor identifica exclusivamente tuplas é chamado chave (ou simplesmente chave). A chave é o atributo “Número pessoal”, pois seu valor é único para cada funcionário da empresa. Se as tuplas forem identificadas apenas pela concatenação dos valores de vários atributos, então diz-se que a relação possui uma chave composta.

Chave primária- em um modelo de dados relacional, uma das chaves potenciais de um relacionamento, selecionada como chave primária (ou chave padrão).

Uma relação pode conter múltiplas chaves. Uma das chaves é sempre declarada primário, seus valores não podem ser atualizados. Todas as outras chaves de relação são chamadas chaves possíveis.

Do ponto de vista teórico, todas as chaves de relação potenciais (possíveis) são equivalentes, ou seja, possuem as mesmas propriedades de unicidade e minimalidade. No entanto, a chave primária é geralmente selecionada entre as chaves potenciais que são mais convenientes para determinados fins práticos, por exemplo, para criar externo chaves em outros aspectos ou para criar um índice clusterizado. Portanto, via de regra, aquela que possui o menor tamanho (armazenamento físico) e/ou inclui o menor número de atributos é escolhida como chave primária.

Se chave primária consiste em um único atributo, é chamado com uma chave simples.

Se chave primária consiste em dois ou mais atributos, é chamado chave composta. Assim, nome, sobrenome, patronímico, número do passaporte, série do passaporte não podem ser chaves primárias individualmente, pois podem ser iguais para duas ou mais pessoas. Mas não existem dois documentos pessoais do mesmo tipo com a mesma série e número. Portanto, numa relação contendo dados sobre pessoas, a chave primária pode ser um subconjunto de atributos constituído pelo tipo de documento pessoal, sua série e número.

Ao contrário dos modelos de dados hierárquicos e de rede, o relacional não possui o conceito de relacionamento de grupo. Para refletir associações entre tuplas de relações diferentes, é utilizada a duplicação de suas chaves.

Atributos que são cópias de chaves de outros relacionamentos são chamados chaves estrangeiras.

Por exemplo, o relacionamento entre os relacionamentos DEPARTAMENTO e FUNCIONÁRIO é criado copiando a chave primária "Número_departamento" do primeiro relacionamento para o segundo. Assim, para obter uma lista de funcionários de um determinado departamento é necessário: 1) Na tabela DEPARTAMENTO definir o valor do atributo "Número_departamento" , correspondente a este “Nome_Departamento”. 2) selecione todos os registros da tabela EMPLOYEE, valor do atributo "Número_departamento" que é igual ao obtido na etapa anterior. Para saber em qual departamento um funcionário trabalha, é necessário realizar a operação inversa: 1) Determinar "Número_departamento" da tabela EMPLOYEE. 2) A partir do valor obtido, encontramos a entrada na tabela DEPARTMENT.

18. Normalização em bancos de dados relacionais, o conceito de forma normal no projeto de banco de dados.

Forma normal - uma propriedade de um relacionamento em um modelo de dados relacional, caracterizando-o do ponto de vista da redundância, o que pode potencialmente levar a resultados logicamente errôneos de amostragem ou alteração de dados. A forma normal é definida como um conjunto de requisitos que uma relação deve satisfazer.

O processo de conversão de um banco de dados para a forma normal é chamado normalização . A normalização tem como objetivo trazer a estrutura do banco de dados para um formato que forneça redundância mínima, ou seja, a normalização não tem como objetivo reduzir ou aumentar a produtividade do trabalho ou reduzir ou aumentar o volume do banco de dados. O objetivo final da normalização é reduzir a potencial inconsistência das informações armazenadas no banco de dados.

A eliminação da redundância é feita, via de regra, pela decomposição das relações de forma que apenas os fatos primários sejam armazenados em cada relação (ou seja, fatos que não são inferidos de outros fatos armazenados).

Dependências funcionais.

Um banco de dados relacional contém informações estruturais e semânticas. A estrutura de um banco de dados é determinada pelo número e tipo de relacionamentos que ele contém e pelos relacionamentos um-para-muitos que existem entre as tuplas desses relacionamentos. A parte semântica descreve o conjunto de dependências funcionais que existem entre os atributos desses relacionamentos. Vamos definir a dependência funcional.

19. 1NF: Definições básicas e regras de transformação.

Para discutir a primeira forma normal, duas definições são necessárias:

Atributo simples - um atributo cujos valores são atômicos (indivisíveis).

Atributo complexo - é obtido conectando vários atributos atômicos que podem ser definidos no mesmo domínio ou em domínios diferentes (também é chamado de vetor ou agregado de dados).

Definição da primeira forma normal:

uma relação está em 1NF se os valores de todos os seus atributos forem atômicos. . Caso contrário, não será uma tabela e tais atributos deverão ser decompostos.

Vejamos um exemplo:

Na base de dados do departamento de recursos humanos da empresa, é necessário armazenar informações sobre os funcionários que podem ser tentadas para serem apresentadas em relação a

EMPREGADO(EMPLOYEE_NUMBER, NOME, DATA DE NASCIMENTO, TRABALHO_HISTÓRICO, FILHOS).

De uma consideração cuidadosa desta relação, segue-se que os atributos "histórico de trabalho" E "crianças" são complexos, além disso, o atributo "histórico de trabalho" inclui outro atributo complexo "salário_histórico".
Essas unidades são assim:

 JOB_HISTORY (RECEPTION_DATE, NOME, SALARY_HISTORY),

 SALÁRIO_HISTÓRICO (DATA DE NOMEAÇÃO, SALÁRIO),

 CRIANÇAS (NOME_CRIANÇA, ANO_NASCIMENTO).

Sua conexão é mostrada na Fig. 3.3.

Figura 3.3. Atitude inicial.

Para trazer a relação original SERVO para a primeira forma normal, é necessário decompô-la em quatro relações, como mostra a figura a seguir:

Figura 3.4. Conjunto normalizado de relações.

Aqui, a chave primária de cada relacionamento é destacada com uma moldura azul, os nomes das chaves estrangeiras estão em fonte azul. Lembre-se de que as chaves estrangeiras são usadas para representar dependências funcionais que existem na relação de origem. Estas dependências funcionais são indicadas por linhas com setas.

O algoritmo de normalização é descrito por EF Codd da seguinte forma:

Começando pela relação no topo da árvore (Figura 3.3.), sua chave primária é obtida e cada relação imediatamente subordinada é expandida pela inserção de um domínio ou combinação de domínios dessa chave primária.
A Chave Primária de cada relação expandida desta forma consiste na Chave Primária que a relação tinha antes da extensão e na Chave Primária adicionada da relação pai.
Depois disso, todos os domínios não simples são excluídos da relação pai, o nó superior da árvore é removido e o mesmo procedimento é repetido para cada uma das subárvores restantes.

20. 2NF: Definições básicas e regras de transformação.

Muitas vezes, a chave primária de um relacionamento inclui vários atributos (nesse caso, é chamada composto) - veja, por exemplo, a relação CRIANÇAS mostrada na Fig. 3.4 questão 19. Ao mesmo tempo, o conceito é introduzido dependência funcional completa.

Definição:

um atributo não-chave é funcionalmente totalmente dependente de uma chave composta se for funcionalmente dependente de toda a chave como um todo, mas não for funcionalmente dependente de nenhum de seus atributos constituintes.

Exemplo:

Seja uma relação FORNECIMENTO (N_FORNECEDOR, PRODUTO, PREÇO).
Um fornecedor pode fornecer produtos diferentes e o mesmo produto pode ser fornecido por fornecedores diferentes. Então a chave da relação é "N_fornecedor + produto". Deixe todos os fornecedores fornecerem mercadorias pelo mesmo preço. Então temos as seguintes dependências funcionais:

N_fornecedor, produto -> preço
produtos -> preço

A dependência funcional incompleta do atributo preço em relação à chave leva à seguinte anomalia: quando o preço de um item muda, é necessária uma visão completa do relacionamento para alterar todos os registros sobre seus fornecedores. Esta anomalia é consequência do fato de dois fatos semânticos serem combinados em uma estrutura de dados. A seguinte expansão fornece as relações em 2NF:

ENTREGA (N_FORNECEDOR, PRODUTO)
PRODUCT_PRICE (PRODUTO, PREÇO)

Então você pode dar

Definição da segunda forma normal: Uma relação está na 2FN se estiver na 1NF e cada atributo não-chave for totalmente dependente funcionalmente da chave.

21. 3NF: Definições básicas e regras de transformação.

Antes de discutir a terceira forma normal, é necessário introduzir o conceito: dependência funcional transitiva.

Definição:

Sejam X, Y, Z três atributos de alguma relação. Neste caso, X -> Y e Y -> Z, mas não há correspondência reversa, ou seja, Z --/-> Y e Y --/-> X. Então Z depende transitivamente de X.
Deixe que haja uma relação ARMAZENAMENTO ( EMPRESA, WAREHOUSE, VOLUME), que contém informações sobre as empresas que recebem mercadorias dos armazéns e os volumes desses armazéns. Atributo chave - "empresa". Se cada empresa pode receber mercadorias de apenas um armazém, então existem as seguintes dependências funcionais:

empresa -> estoque
estoque -> volume

Neste caso, surgem anomalias:

se no momento nenhuma empresa recebe mercadorias do armazém, então os dados sobre o seu volume não podem ser inseridos no banco de dados (já que o atributo chave não está definido)
caso o volume do armazém mude, é necessário visualizar todo o relacionamento e alterar os cartões de todas as empresas associadas a este armazém.

Para eliminar estas anomalias, é necessário decompor a relação original em duas:

ARMAZENAR ( EMPRESA, ESTOQUE)
ARMAZENAMENTO_VOLUME ( ESTOQUE, VOLUME)

Definição da terceira forma normal:

Uma relação está na 3FN se estiver na 2FN e cada atributo não-chave não depender transitivamente da chave primária.

Anteriormente neste livro, apontamos certos relacionamentos que existem entre determinados campos de tabelas típicas. O campo snum da tabela Clientes, por exemplo, corresponde ao campo snum da tabela Vendedores e da tabela Pedidos. O campo cnum da tabela Clientes também corresponde ao campo cnum da tabela Pedidos. Chamamos esse tipo de integridade de referência de relacionamento; e durante a discussão você viu como ele pode ser usado.

Neste capítulo, você explorará a integridade de referência com mais detalhes e aprenderá tudo sobre as restrições que pode usar para mantê-la. Você também verá como essa limitação se aplica ao usar comandos de modificação DML. Como a integridade de referência envolve relacionar campos ou grupos de campos, muitas vezes em tabelas diferentes, esta ação pode ser um pouco mais complexa do que outras restrições. Por isso é bom estar familiarizado com ele, mesmo que você não pretenda criar tabelas. Seus comandos de modificação podem se tornar mais eficientes usando uma restrição de integridade de referência (como acontece com outras restrições, mas uma restrição de integridade de referência pode afetar tabelas diferentes daquelas nas quais está definida), e certas funções de consulta, como junções, são estruturadas iterativamente em termos de relações de integridade de referência (conforme enfatizado no Capítulo 8).

CHAVE ESTRANGEIRA E CHAVE PAI

Quando todos os valores de um campo da tabela são representados em um campo de outra tabela, dizemos que o primeiro campo se refere ao segundo. Isto indica uma relação direta entre os valores dos dois campos. Por exemplo, cada um dos clientes na tabela Clientes possui um campo snum que aponta para o vendedor atribuído na tabela Vendedores. Para cada pedido na tabela Pedidos, existe um único vendedor e um único cliente. Isso é exibido usando os campos snum e cnum na tabela Pedidos.

Quando um campo de uma tabela se refere a outro, ele é chamado de chave estrangeira; e o campo ao qual se refere é chamado de chave pai. Portanto, o campo snum da tabela Clientes é uma chave estrangeira e o campo snum ao qual ele se refere na tabela Fornecedores é a chave pai.

Da mesma forma, os campos cnum e snum da tabela Pedidos são chaves estrangeiras que se referem às suas chaves pai nomeadas na tabela Clientes e na tabela Fornecedores. Os nomes da chave estrangeira e da chave pai não precisam ser iguais, é apenas uma convenção que seguimos para deixar a junção mais clara.

CHAVES ESTRANGEIRAS MÚLTIPLAS COLUNAS

Na realidade, uma chave estrangeira não consiste necessariamente em apenas um género. Assim como uma chave primária, uma chave estrangeira pode ter qualquer número de campos, todos tratados como uma única unidade. A chave estrangeira e a chave pai a que se refere devem, obviamente, ter o mesmo número e tipo de gênero, e estar na mesma ordem. Chaves estrangeiras compostas por um gênero - aquelas que usamos exclusivamente em nossas tabelas padrão, são as mais comuns. Para manter nossa discussão simples, frequentemente nos referiremos a uma chave estrangeira como uma única coluna. Isto não é coincidência. Se isso não for observado, qualquer um dirá sobre um campo que é uma chave estrangeira que ele também pertence a um grupo de campos que é uma chave estrangeira.

O SIGNIFICADO DAS CHAVES ESTRANGEIRAS E PAIS

Quando um campo é uma chave estrangeira, ele está relacionado de alguma forma à tabela a que se refere. O que você está dizendo essencialmente é "cada valor neste campo (a chave estrangeira) está diretamente vinculado a um valor em outro campo (a chave pai)." Cada valor (cada linha) de uma chave estrangeira deve referir-se inequivocamente a um e somente aquele valor (linha) da chave pai. Se for esse o caso, então na verdade o seu sistema estará, como dizem, em um estado de integridade de referência. Você pode ver isso com um exemplo. A chave estrangeira snum na tabela Clientes tem o valor 1001 para as linhas Hoffman e Clemens. Vamos supor que temos duas linhas na tabela Fornecedores com um valor de campo snum = 1001. Como sabemos a qual dos dois fornecedores os clientes Hoffman e Clemens foram atribuídos? Da mesma forma, se não existirem tais linhas na tabela Fornecedores, teremos Hoffman e Clemens atribuídos a um fornecedor que não existe!

É claro que cada valor de uma chave estrangeira deve ser representado uma vez, e apenas uma vez, na chave pai.

Na verdade, um determinado valor de chave estrangeira só pode referir-se a um valor de chave pai sem que o inverso seja possível: ou seja, qualquer número de chaves estrangeiras pode referir-se a um único valor de chave pai. Você pode ver isso nas tabelas típicas de nossos exemplos. Tanto Hoffman quanto Clemens são atribuídos a Peel, portanto, ambos os valores de chave estrangeira são iguais à mesma chave pai, o que é uma coisa boa. Um valor de chave estrangeira deve fazer referência a apenas um valor de chave pai, mas um valor de chave pai pode ser referenciado por qualquer número de valores de chave estrangeira. A título de ilustração, os valores de chave estrangeira da tabela Clientes que correspondem à sua chave pai na tabela Vendedores são mostrados na Figura 19.1. Por conveniência, não levamos em consideração o género que não é relevante para este exemplo.

LIMITAÇÃO DE CHAVE ESTRANGEIRA

SQL mantém a integridade referencial com a restrição FOREIGN KEY. Embora a restrição FOREIGN KEY seja um recurso novo no SQL, ela ainda não a torna universal. Além disso, algumas de suas implementações são mais complexas que outras. Esta função deve limitar os valores que você pode inserir em seu banco de dados para forçar a chave estrangeira e a chave pai a cumprirem a integridade referencial. Uma das ações de uma restrição de chave estrangeira é descartar valores de campos restritos como chave estrangeira que ainda não estejam representados na chave pai. Essa restrição também afeta sua capacidade de alterar ou excluir valores de chave pai (discutiremos isso mais adiante neste capítulo).

COMO OS CAMPOS PODEM SER REPRESENTADOS COMO CHAVES ESTRANGEIRAS

Você usa uma restrição FOREIGN KEY em um comando CREATE TABLE (ou ALTER TABLE) que contém o campo que você deseja declarar como chave estrangeira. Você fornece a eles uma chave pai que fará referência dentro da restrição FOREIGN KEY. A colocação desta restrição no comando é igual às outras restrições discutidas no capítulo anterior. Figura 19.1: Chave Estrangeira da tabela Cliente com chave pai

Como a maioria das restrições, pode ser uma restrição de tabela ou coluna, em formato de tabela, permitindo que vários campos sejam usados como uma única chave estrangeira.

CHAVE ESTRANGEIRA COMO RESTRIÇÃO DE TABELA

Sintaxe de restrição da tabela FOREIGN KEY: FOREIGN KEY REFERÊNCIAS [ ] A lista da primeira coluna é uma lista separada por vírgulas de uma ou mais colunas da tabela que serão criadas ou modificadas por este comando. Pktable é a tabela que contém a chave pai. Pode ser uma tabela criada ou modificada pelo comando atual. A segunda lista de colunas é a lista de colunas que constituirão a chave pai. As duas listas de colunas devem ser compatíveis, ou seja:

*Devem ter o mesmo número de colunas.

* Nesta sequência, a primeira, segunda, terceira, etc. colunas da lista de colunas de chave estrangeira devem ter os mesmos tipos e tamanhos de dados que a primeira, segunda, terceira, etc. colunas da lista de colunas de chave pai. As colunas nas listas de ambas as colunas não devem ter os mesmos nomes, embora tenhamos utilizado este método em nossos exemplos para tornar a relação mais clara.

Vamos criar uma tabela Clientes com o campo snum definido como uma chave estrangeira referenciando a tabela Vendedores: CREATE TABLE Clientes (cnum inteiro NOT NULL PRIMARY KEY cname char(10), cidade char(10), snum inteiro, FOREIGN KEY (snum) REFERÊNCIAS Vendedores (snum ); Tenha em mente que ao usar ALTER TABLE em vez de CREATE TABLE, para aplicar a restrição FOREIGN KEY, os valores que você especifica na chave estrangeira e na chave pai devem estar no estado de integridade de referência, caso contrário, o ALTER O comando TABLE será rejeitado - para sua conveniência, você terá que primeiro formular princípios estruturais, como integridade de referência, em seu sistema, sempre que possível, sempre.

CHAVE ESTRANGEIRA COMO RESTRIÇÃO DE COLUNA

A opção de limitar uma coluna com uma restrição FOREIGN KEY também é chamada de restrição REFERENCES, pois na verdade não contém as palavras FOREIGN KEY, mas simplesmente usa a palavra REFERENCES, seguida pela chave pai, assim: CREATE TABLE Clientes (cnum inteiro NOT NULL PRIMARY KEY, cname char(10), cidade char(10), snum inteiro REFERÊNCIAS Vendedores (snum)); O texto acima define Customers.snum como uma chave estrangeira cuja chave pai é Salespeople.snum. Isto é equivalente a uma restrição de tabela como esta: FOREIGN KEY (snum) REGERENCES Vendedores (snum)

NÃO ESPECIFIQUE A LISTA DE COLUNAS DE CHAVE PRIMÁRIA

Ao usar uma restrição FOREIGN KEY em uma tabela ou coluna, você pode omitir a lista de colunas da chave pai se a chave pai tiver uma restrição PRIMARY KEY. Naturalmente, no caso de chaves com muitos campos, a ordem das colunas nas chaves estrangeira e primária deve coincidir e, em qualquer caso, continua a aplicar-se o princípio da compatibilidade entre as duas chaves. Por exemplo, se colocarmos uma restrição PRIMARY KEY no campo snum da tabela Vendas, poderíamos usá-la como chave estrangeira na tabela Clientes (semelhante ao exemplo anterior) com este comando: CREATE TABLE Clientes (cnum inteiro NOT NULL CHAVE PRIMÁRIA, cname char(10) , cidade char(10), snum inteiro REFERÊNCIAS Vendedores); Esse recurso foi integrado à linguagem para incentivar você a usar chaves primárias como chaves pai.

COMO A INTEGRIDADE DE REFERÊNCIA LIMITA OS VALORES DE UMA CHAVE PAIS

Manter a integridade referencial requer algumas restrições nos valores que podem ser representados em campos declarados como chave estrangeira e chave pai. A chave pai deve ser estruturada para garantir que cada valor de chave estrangeira corresponda a uma linha especificada. Isso significa que ela (a chave) deve ser única e não conter nenhum valor vazio (NULL). Isso não é suficiente para a chave pai se o mesmo requisito for atendido ao declarar uma chave estrangeira. O SQL deve garantir que valores duplos ou nulos não sejam inseridos na chave pai. Portanto, você deve garantir que todos os campos usados como chaves pai tenham uma restrição PRIMARY KEY ou uma restrição UNIQUE, como a restrição NOT NULL.

CHAVE PRIMÁRIA COMO CHAVE ESTRANGEIRA ÚNICA

Vincular suas chaves estrangeiras apenas às chaves primárias, como fizemos nas tabelas padrão, é uma boa estratégia. Ao usar chaves estrangeiras, você não as associa apenas às chaves pai às quais elas se referem; você os associa a uma linha específica da tabela onde essa chave pai será encontrada. A chave pai em si não fornece nenhuma informação que ainda não esteja presente na chave estrangeira. O significado, por exemplo, de sex snum como chave estrangeira na tabela Clientes é a relação que ela fornece, não com o valor de sex snum a que se refere, mas com outras informações na tabela Sales, como os nomes dos vendedores, suas localizações e assim por diante. Uma chave estrangeira não é simplesmente um relacionamento entre dois valores idênticos; este é um relacionamento, usando esses dois valores, entre duas linhas da tabela especificada na consulta. Este campo snum pode ser usado para associar qualquer informação em uma linha da tabela Clientes com uma linha de referência da tabela Vendedores - por exemplo, para saber se eles moram na mesma cidade, quem tem nome mais longo, se o vendedor tem quaisquer outros clientes além deste cliente e assim por diante. Como o objetivo de uma chave primária é identificar a exclusividade de uma linha, é uma escolha mais lógica e menos ambígua para uma chave estrangeira. Para qualquer chave estrangeira que use uma chave exclusiva como chave pai, você deve criar uma chave estrangeira que use a chave primária da mesma tabela para o mesmo efeito. Uma chave estrangeira, que não tem outro propósito além de vincular linhas, é semelhante a uma chave primária usada exclusivamente para identificar linhas e é uma boa maneira de manter a estrutura do seu banco de dados clara e simples e, portanto, menos complexa.

RESTRIÇÕES DE CHAVE ESTRANGEIRA

Uma chave estrangeira, em particular, só pode conter valores que estejam realmente presentes na chave pai ou que estejam vazios (NULL). Qualquer tentativa de inserir outros valores nesta chave será rejeitada. Você pode declarar uma chave estrangeira como NOT NULL, mas isso não é necessário e, na maioria dos casos, indesejável. Por exemplo, suponha que você insira um cliente sem saber antecipadamente a qual vendedor ele será atribuído. A melhor saída nesta situação é utilizar um valor NOT NULL, que deve ser alterado posteriormente para um valor específico.

O QUE ACONTECE SE VOCÊ EXECUTAR UM COMANDO DE MODIFICAÇÃO

Vamos estipular que todas as chaves estrangeiras criadas em nossas tabelas de exemplo sejam declaradas e aplicadas com restrições de chave estrangeira, como segue: CREATE TABLE Vendedores (snum inteiro NOT NULL PRIMARY KEY, sname char(10) NOT NULL, city char(10) , comm decimal ); CREATE TABLE Clientes (cnum inteiro NOT NULL PRIMARY KEY, cname char(10) NOT NULL, city char(10), rating inteiro, snum inteiro, FOREIGN KEY (snum) REFERÊNCIAS Vendedores, UNIQUE (cnum, snum) ; CREATE TABLE Pedidos ( cnum inteiro NOT NULL PRIMARY KEY, amt decimal, odate data NOT NULL, cnum inteiro NOT NULL snum inteiro NOT NULL CHAVE ESTRANGEIRA (cnum, snum) REFERÊNCIAS CLIENTES (cnum, snum);

INCLUINDO DESCRIÇÕES DE TABELA

Existem vários atributos de tais definições que precisam ser discutidos. A razão pela qual decidimos transformar os andares cnum e snum na tabela Pedidos em uma única chave estrangeira é para garantir que, para cada cliente contido nos pedidos, o vendedor que credita esse pedido seja o mesmo indicado na tabela Clientes. Para criar tal chave estrangeira, teríamos que colocar uma restrição de tabela UNIQUE em dois andares da tabela Cliente, mesmo que não seja exigida pela própria tabela. Contanto que o campo cnum nesta tabela tenha uma restrição PRIMARY KEY, ele será único em qualquer caso e, portanto, é impossível obter outra combinação do campo cnum com algum outro campo. Criar uma chave estrangeira dessa maneira mantém a integridade do banco de dados, mesmo que evite interromper internamente por engano e creditar qualquer fornecedor que não seja aquele atribuído a esse cliente específico.

Do ponto de vista da manutenção da integridade do banco de dados, as interrupções internas (ou exceções) são obviamente indesejáveis. Se você permitir e ao mesmo tempo quiser manter a integridade do seu banco de dados, você pode declarar os campos snum e cnum da tabela Pedidos como chaves estrangeiras independentes desses campos da tabela Fornecedores e da tabela Clientes, respectivamente. Na verdade, não é necessário usar sex snum na tabela Order como fizemos, embora seja útil fazê-lo para variar. O campo cnum que vincula cada pedido do cliente na tabela Cliente, na tabela Pedido e na tabela Cliente deve sempre ser compartilhado para encontrar o campo snum correto para esse pedido (sem permitir exceções). Isso significa que estamos registrando uma informação – qual cliente está atribuído a qual fornecedor – duas vezes, e será necessário fazer trabalho adicional para garantir que ambas as versões sejam consistentes. Se não tivermos uma restrição de chave estrangeira conforme mencionado acima, esta situação será especialmente problemática porque cada pedido precisará ser verificado manualmente (juntamente com a consulta) para garantir que o vendedor correspondente creditou cada venda correspondente. Ter esse tipo de redundância de informações em seu banco de dados é chamado de desnormalização, o que é indesejável em um banco de dados relacional ideal, embora na prática possa ser resolvido. A desmoralização pode fazer com que algumas consultas sejam executadas mais rapidamente, já que uma consulta em uma tabela é sempre muito mais rápida do que uma consulta em uma junção.

APLICAÇÃO DE RESTRIÇÕES

Como essas restrições afetam sua capacidade e incapacidade de usar comandos de modificação DML? Para campos definidos como chaves estrangeiras, a resposta é bastante simples: quaisquer valores que você colocar nesses campos com um comando INSERT ou UPDATE já devem estar presentes em suas chaves pai. Você pode colocar valores NULL nesses campos, embora valores NULL não sejam permitidos em chaves pai se tiverem uma restrição NOT NULL. Você pode DELETE qualquer linha com chaves estrangeiras sem usar as chaves pai.

Como a questão da alteração dos valores da chave pai é levantada, a resposta, conforme definida pelo ANSI, é ainda mais simples, mas talvez um pouco mais limitada: qualquer valor da chave pai referenciado por um valor de chave estrangeira não pode ser excluído ou alterado. Isto significa, por exemplo, que não é possível remover um cliente da tabela Clientes enquanto ele ainda tiver pedidos na tabela Pedidos. Dependendo de como você usa essas tabelas, isso pode ser desejável ou incômodo. Porém, isso certamente é melhor do que ter um sistema que permite excluir um cliente com pedidos atuais e deixar a tabela Pedidos referenciando clientes inexistentes. O objetivo desse sistema de restrição é que o criador da tabela Pedidos, usando a tabela Clientes e a tabela Vendedores como chaves pai, pode impor restrições significativas às ações nessas tabelas. Por esse motivo, você não poderá usar uma tabela que não controla (ou seja, você não a criou e não é seu proprietário) até que o proprietário (criador) dessa tabela lhe conceda especificamente o direito de fazê-lo. então (conforme explicado no Capítulo 22). Existem algumas outras possíveis ações de alteração de chave pai que não fazem parte do ANSI, mas podem ser encontradas em alguns programas comerciais. Se você quiser alterar ou excluir o valor de referência atual de uma chave pai, existem essencialmente três possibilidades:

Você pode restringir ou proibir alterações (no estilo ANSI) indicando que as alterações na chave pai são restritas.

Você pode fazer uma alteração na chave pai e, assim, tornar automáticas as alterações na chave estrangeira, o que é chamado de alteração em cascata.

Você pode fazer uma alteração na chave pai e definir a chave estrangeira como NULL automaticamente (assumindo que NULLS seja permitido na chave estrangeira), o que é chamado de alteração de chave estrangeira nula.

Mesmo dentro dessas três categorias, talvez você não queira lidar com todos os comandos de modificação dessa maneira. INSERT, é claro, é irrelevante. Ele coloca os novos valores da chave pai na tabela para que nenhum desses valores possa ser chamado no momento. No entanto, você pode permitir que as modificações sejam em cascata sem exclusões e vice-versa. Uma situação melhor seria aquela que permitisse definir qualquer uma das três categorias, independente dos comandos UPDATE e DELETE. Portanto, nos referiremos aos efeitos de atualização e exclusão, que determinam o que acontece se você emitir um comando UPDATE ou DELETE em uma chave pai. Esses efeitos de que falamos são chamados de: alterações RESTRICTAS, alterações CASCADES e alterações NULL. As capacidades reais do seu sistema devem estar dentro do estrito padrão ANSI - os efeitos de modificação e exclusão são ambos automaticamente limitados - para a situação mais ideal descrita acima. Para ilustrar, mostraremos alguns exemplos do que você pode fazer com uma gama completa de efeitos de modificação e remoção. É claro que os efeitos de modificação e exclusão, que são meios não padronizados, carecem de sintaxe de estado padrão. A sintaxe que usamos aqui é fácil de escrever e servirá para ilustrar as funções desses efeitos mais tarde.

Para completar o experimento, vamos supor que você tenha um motivo para alterar o campo snum da tabela Vendors no caso de nossa tabela Vendors alterar partições. (Normalmente, alterar as chaves primárias não é algo que recomendamos fazer na prática. É apenas mais um motivo para as chaves primárias existentes que não sabem fazer nada além de atuar como chaves primárias: elas não devem mudar.) Quando você altera o comerciante número, você deseja que todos os seus clientes sejam salvos. No entanto, se esse vendedor deixar sua firma ou empresa, talvez você não queira remover seus clientes enquanto o remove do banco de dados. Em vez disso, você desejará garantir que os clientes sejam atribuídos a outra pessoa. Para fazer isso você deve especificar UPDATE com um efeito em cascata e DELETE com um efeito limitado. CREATE TABLE Clientes (cnum inteiro NOT NULL PRIMARY KEY, cname char(10) NOT NULL, cidade char(10), rating inteiro, snum inteiro REFERÊNCIAS Vendedores, ATUALIZAÇÃO DE Vendedores CASCADES, DELETE DE Vendedores RESTRITO); Se você tentar remover Peel da tabela Fornecedores, o comando não será válido até que você altere o valor sex snum dos clientes Hoffman e Clemens para outro fornecedor atribuído. Por outro lado, você pode alterar o valor do sex snum de Peel para 1009, e Hoffman e Clemens também serão alterados automaticamente.

O terceiro efeito são alterações vazias (NULL). Acontece que quando os vendedores saem de uma empresa, seus pedidos atuais não são transferidos para outro vendedor. Por outro lado, você deseja cancelar todos os pedidos automaticamente para clientes cujas contas você excluiu. Ao alterar os números do vendedor ou cliente, você pode simplesmente transferi-los para ele. O exemplo abaixo mostra como você pode criar uma tabela Order usando esses efeitos. CRIAR TABELA Pedidos (onum inteiro NOT NULL PRIMARY KEY, amt decimal, odate data NOT NULL cnum inteiro NOT NULL REFERÊNCIAS Clientes snum inteiro REFERÊNCIAS Vendedores, ATUALIZAÇÃO DE CASCADAS DE CLIENTES, EXCLUSÃO DE CASCADAS DE CLIENTES, ATUALIZAÇÃO DE CASCADAS DE Vendedores, EXCLUSÃO DE CASCADAS DE Vendedores); É claro que, em um comando DELETE com o efeito de uma alteração vazia na tabela Vendors, a restrição NOT NULL deve ser removida do campo snum.

CHAVES ESTRANGEIRAS QUE REFEREM ÀS SUAS TABELAS DE ASSUNTO

Conforme mencionado anteriormente, uma restrição FOREIGN KEY pode representar esta tabela privada como uma tabela de chave pai. Longe de ser simples, esse recurso pode ser útil. Vamos supor que temos uma tabela Employees com um campo manager. Este campo contém os números de cada funcionário, alguns dos quais também são administradores. Mas como todo administrador continua sendo funcionário ao mesmo tempo, ele naturalmente também estará representado nesta tabela. Vamos criar uma tabela onde o número do funcionário (uma coluna chamada empno) é declarado como chave primária, e o administrador, como chave estrangeira, irá referenciá-lo: CREATE TABLE Employees (empno integer NOT NULL PRIMARY KEY, name char(10) NOT NULL UNIOUE , gerente inteiro REFERENCES Funcionários); (Como a chave estrangeira é a chave primária referenciada da tabela, a lista de colunas pode ser excluída.) Existe o conteúdo desta tabela: EMPNO NAME MANAGER _____ ________ _______ 1003 Terrence 2007 2007 Atali NULL 1688 McKenna 1003 2002 Collier 2007 Como você pode ver, cada um deles( mas não Atali), refere-se a outro funcionário na tabela como seu administrador. Atali, que possui o maior número da tabela, deve ter seu valor definido como NULL. Isso dá outro princípio de integridade referencial. Uma chave estrangeira que faz referência a uma tabela privada deve permitir valores = NULL. Se não for esse o caso, como você inseriria a primeira linha? Mesmo que esta primeira linha se refira a si mesma, o valor da chave pai já deve estar definido quando o valor da chave estrangeira for inserido. Este princípio será verdadeiro mesmo se a chave estrangeira fizer referência à tabela privada não diretamente, mas através de uma referência a outra tabela, que então fará referência à tabela de chave estrangeira. Por exemplo, suponha que nossa tabela Vendas tenha um campo adicional que faça referência à tabela Clientes, de modo que cada tabela faça referência à outra, conforme mostrado na instrução CREATE TABLE a seguir: CREATE TABLE Vendedores (snum inteiro NOT NULL PRIMARY KEY, sname char(10) NOT NULL, cidade char(10), comm declmal, cnum inteiro REFERÊNCIAS Clientes); CREATE TABLE Clientes (cnum inteiro NOT NULL PRIMARY KEY, cname char(10) NOT NULL, cidade char(10), rating inteiro, snum inteiro REFERÊNCIAS Vendedores); Isso é chamado de referência cruzada. O SQL suporta isso em teoria, mas na prática pode ser um problema. Qualquer tabela destas duas criada primeiro é uma tabela de referência que ainda não existe para a outra. No interesse da referência cruzada, o SQL na verdade permite isso, mas nenhuma tabela será utilizável enquanto ambas estiverem em processo de criação. Por outro lado, se as duas tabelas forem criadas por usuários diferentes, o problema fica ainda mais difícil. A referência cruzada pode ser uma ferramenta útil, mas não é isenta de ambiguidades e perigos. O exemplo anterior, por exemplo, não é totalmente utilizável porque limita o vendedor a um único cliente, não sendo necessário utilizar referência cruzada para o conseguir. Recomendamos que você tenha cuidado em seu uso e analise como seus programas gerenciam os efeitos de modificação e exclusão, bem como os processos de privilégios e processamento de consultas interativas, antes de criar um sistema de integridade de referência cruzada. (Privilégios e processamento interativo de solicitações serão discutidos, respectivamente, nos Capítulos 22 e 1.)

RESUMO

Agora você tem um controle bastante bom da integridade de referência. A ideia básica é que todos os valores de chave estrangeira se refiram à linha da chave pai especificada. Isso significa que cada valor de chave estrangeira deve ser representado uma vez, e apenas uma vez, na chave pai. Sempre que um valor é colocado em uma chave estrangeira, a chave pai é verificada para garantir que seu valor seja representado; caso contrário, o comando será rejeitado. A chave pai deve ter uma restrição PRIMARY KEY ou UNIQUE para garantir que o valor não seja representado mais de uma vez. Uma tentativa de alterar um valor de chave pai que esteja atualmente representado em uma chave estrangeira será totalmente rejeitada. Seu sistema pode, entretanto, oferecer a opção de obter o valor da chave estrangeira definido como NULL ou obter o novo valor da chave pai e especificar qual deles pode ser obtido independentemente para os comandos UPDATE e DELETE. Isto conclui nossa discussão sobre o comando CREATE TABLE. A seguir apresentaremos outro tipo de comando - CREATE. No Capítulo 20, você aprenderá como representar objetos de dados que parecem e agem como uma tabela, mas na verdade são resultados de consultas. Algumas funções de restrição também podem ser executadas por visualizações, portanto você poderá avaliar melhor sua necessidade de restrições depois de ler os próximos três capítulos.

TRABALHANDO COM SQL

1. Crie uma tabela chamada Cityorders. Ela deve conter os mesmos campos onum, amt e snum da tabela Pedidos, e os mesmos campos cnum e cidade da tabela Clientes, para que o pedido de cada cliente seja inserido nesta tabela junto com sua cidade. O campo onum será a chave primária dos Cityorders. Todos os andares do Cityorders devem ter restrições quando comparados com as tabelas Clientes e Pedidos. É possível que as chaves pai nessas tabelas já tenham restrições apropriadas.

2. Vamos complicar o problema. Redefina a tabela Pedidos da seguinte forma: adicione uma nova coluna chamada prev que será identificada para cada pedido, o campo onum do pedido anterior para aquele cliente atual. Faça isso usando uma chave estrangeira referenciando a própria tabela Order. A chave estrangeira também deve fazer referência ao campo cnum do cliente, fornecendo um relacionamento específico prescrito entre o pedido atual e o referenciado.

(Veja o Apêndice A para respostas.)

CHAVE ESTRANGEIRA usado para restrições de link.
Quando todos os valores de um campo de tabela são representados em um campo de outra tabela, diz-se que o primeiro campo se refere ao segundo. Isto indica uma relação direta entre os valores dos dois campos.

Quando um gênero em uma tabela se refere a outro, isso é chamado chave estrangeira; e o campo ao qual se refere é chamado chave pai. Os nomes da chave estrangeira e da chave pai não precisam ser iguais. Uma chave estrangeira pode ter qualquer número de campos, todos processados como uma única unidade. Uma chave estrangeira e a chave pai à qual ela se refere devem ter o mesmo número e tipo de campo e estar na mesma ordem. Quando um campo é uma chave estrangeira, ele está relacionado de alguma forma à tabela à qual faz referência. Cada valor (cada linha) de uma chave estrangeira deve referir-se inequivocamente a um e somente aquele valor (linha) da chave pai. Se esta condição for atendida, o banco de dados estará no estado integridade referencial.

SQL mantém integridade referencial com restrição CHAVE ESTRANGEIRA. Esta função deve limitar os valores que podem ser inseridos no banco de dados para forçar a chave estrangeira e a chave pai a cumprirem a integridade referencial. Uma das ações de restrição CHAVE ESTRANGEIRAé a eliminação de valores para campos que estão restritos como chave estrangeira e que ainda não estão representados na chave pai. Esta restrição também afeta a capacidade de alterar ou excluir valores de chave pai

Limitação CHAVE ESTRANGEIRA usado em um comando CREATE TABLE (ou ALTER TABLE (destinado a modificar a estrutura da tabela)) contendo um campo que é declarado como uma chave estrangeira. A chave pai recebe um nome que é referenciado dentro da restrição. CHAVE ESTRANGEIRA.

Como a maioria das restrições, pode ser uma restrição de tabela ou coluna, em formato de tabela, permitindo que vários campos sejam usados como uma única chave estrangeira.

Sintaxe de restrição de tabela CHAVE ESTRANGEIRA:

CHAVE ESTRANGEIRA REFERÊNCIAS

[ ]

A lista da primeira coluna é uma lista separada por vírgulas de uma ou mais colunas da tabela que serão criadas ou modificadas por este comando.

Tabela de pacotes- esta é a tabela que contém a chave pai. Pode ser uma tabela criada ou modificada pelo comando atual.

A lista da segunda coluna é a lista de colunas que constituirão a chave pai. As duas listas de colunas devem ser compatíveis, ou seja:

têm o mesmo número de colunas
em uma determinada sequência, a primeira, segunda, terceira, etc. colunas da lista de colunas de chave estrangeira devem ter os mesmos tipos e tamanhos de dados que a primeira, segunda, terceira, etc. colunas da lista de colunas de chave pai.
as colunas nas listas de ambas as colunas não devem ter os mesmos nomes.

CHAVE ESTRANGEIRA Exemplo 1

CRIAR TABELA Aluno
(Kod_stud inteiro NÃO NULO PRIMÁRIO CHAVE,
Número inteiro Kod_spec NÃO NULO,

Endereços char(50),
Bola decimal),
CHAVE ESTRANGEIRA(Kod_spec) REFERÊNCIAS Especificação (Kod_spec)
);

Ao usar ALTER TABLE em vez de CREATE TABLE para aplicar a restrição CHAVE ESTRANGEIRA, os valores especificados na chave estrangeira e na chave pai devem estar no estado de integridade referencial. Caso contrário, o comando será rejeitado.

Usando restrição CHAVE ESTRANGEIRA tabela ou coluna, você poderá omitir a lista de colunas da chave pai se a chave pai tiver uma restrição PRIMARY CHAVE. Naturalmente, no caso de chaves com muitos campos, a ordem das colunas nas chaves estrangeira e primária deve coincidir e, em qualquer caso, continua a aplicar-se o princípio da compatibilidade entre as duas chaves.

CHAVE ESTRANGEIRA Exemplo 2

CRIAR TABELA Aluno (
Número inteiro Kod_stud NÃO NULO PRIMÁRIO CHAVE,
Fam char(30) NOT NULL UNIQUE,
Endereços char(50),
Bola decimal),
Kod_spec inteiro REFERÊNCIAS Especificação
);

Isso não é suficiente para que a chave pai atenda aos mesmos requisitos de quando se declara uma chave estrangeira. SQL deve ter certeza de que valores duplos ou valores nulos não foram introduzidos na chave pai. Portanto, você deve garantir que todos os campos usados como chaves pai tenham uma restrição PRIMARY CHAVE ou uma restrição UNIQUE, como a restrição NOT NULL.

Referenciar chaves estrangeiras apenas a chaves primárias é uma boa estratégia. Quando chaves estrangeiras são usadas, elas não são simplesmente associadas às chaves pai às quais se referem; eles estão associados a uma linha específica da tabela onde a chave pai será encontrada. A chave pai em si não fornece nenhuma informação que ainda não esteja presente na chave estrangeira.

Como o objetivo de uma chave primária é identificar a exclusividade de uma linha, é uma escolha mais lógica e menos ambígua para uma chave estrangeira. Para qualquer chave estrangeira que use uma chave exclusiva como chave pai, você deve criar uma chave estrangeira que use a chave primária da mesma tabela para o mesmo efeito. Uma chave estrangeira, que não tem outra finalidade senão vincular linhas, é semelhante a uma chave primária, usada apenas para identificar linhas, e é um bom meio de manter a estrutura do banco de dados clara e simples. Uma chave estrangeira só pode conter valores que estejam realmente presentes na chave pai ou que estejam vazios (NULL). Qualquer tentativa de inserir outros valores nesta chave será rejeitada.

CHAVE ESTRANGEIRA Exemplo 3

CREATE TABLE pagamento (
sh_payout inteiro,
sh_eml inteiro,
data_data de pagamento,
soma_pagamento real,
CHAVE ESTRANGEIRA(sh_eml) REFERÊNCIAS k_sotr2 (eid)
);

Neste exemplo CHAVE ESTRANGEIRA a coluna sh_eml está associada à coluna eid da tabela k_sotr2.

As chaves são elementos fundamentais de um banco de dados relacional porque estabelecem um relacionamento entre um par de tabelas e fornecem uma identificação única para cada registro da tabela. As chaves são mais importantes do que estabelecer relacionamentos; eles também ajudam na integridade referencial e são um componente importante da integridade em nível de tabela. As tabelas armazenam grandes blocos de dados que normalmente abrangem milhares de registros, todos desordenados e desorganizados. Às vezes, recuperar dados específicos desses vários registros pode ser difícil ou impossível. É aqui que as Chaves aparecem. Aqui veremos duas chaves de esquema de banco de dados relacional muito importantes e a diferença entre elas: Chave Primária e Chave Estrangeira.

O que é uma chave primária?

Uma chave primária é uma chave especial que identifica exclusivamente cada registro em uma tabela. Em um banco de dados relacional, é muito importante ter um identificador exclusivo em cada linha de uma tabela, e uma chave primária é simplesmente o que você precisa para identificar exclusivamente uma tupla em uma tabela. Uma tupla é uma coleção de atributos de valor em um banco de dados relacional. Uma chave primária pode referir-se a uma coluna ou conjunto de colunas em uma tabela de banco de dados relacional que é usada para identificar implicitamente todos os registros da tabela. A chave primária deve ser exclusiva para cada registro, pois atua como um identificador exclusivo e não deve conter valores nulos. Cada banco de dados deve ter uma e apenas uma chave primária.

O que é uma chave estrangeira?

Uma chave estrangeira refere-se a um campo ou coleção de campos em um registro de banco de dados que identifica exclusivamente o campo-chave de outro registro de banco de dados em outra tabela. Em termos simples, estabelece uma relação entre registros em duas tabelas diferentes de um banco de dados. Poderia ser uma coluna de uma tabela que aponta para as colunas da chave primária, o que significa que a chave estrangeira definida na tabela se refere à chave primária de alguma outra tabela. Os links são essenciais em bancos de dados relacionais para estabelecer relacionamentos entre registros, necessários para classificar os bancos de dados. As chaves estrangeiras desempenham um papel importante na normalização de bancos de dados relacionais, especialmente quando as tabelas precisam de acesso a outras tabelas.

Diferença entre chave primária e chave estrangeira

Noções básicas de chave primária e chave estrangeira

Uma chave primária é uma chave especial em um banco de dados relacional que atua como um identificador exclusivo para cada registro, o que significa que identifica exclusivamente cada linha/registro em uma tabela e seu valor deve ser exclusivo para cada linha da tabela. Por outro lado, uma chave estrangeira é um campo em uma tabela que liga duas tabelas. Refere-se a uma coluna ou grupo de colunas que identifica exclusivamente uma linha de outra tabela ou da mesma tabela.

Relacionamento de chave primária e chave estrangeira

Uma chave primária identifica exclusivamente um registro em uma tabela de banco de dados relacional, enquanto uma chave estrangeira se refere a um campo em uma tabela que é a chave primária de outra tabela. A chave primária deve ser única e apenas uma chave primária é permitida em uma tabela a ser definida, enquanto mais de uma chave estrangeira é permitida em uma tabela.

Valores duplicados de chave primária e chave estrangeira

Uma chave primária é uma combinação de restrições UNIQUE e Not Null, portanto, um campo de chave primária em uma tabela de banco de dados relacional não pode ter valores duplicados. Não há duas linhas que possam conter valores duplicados para um atributo de chave primária. Ao contrário de uma chave primária, uma chave estrangeira pode conter valores duplicados e uma tabela em um banco de dados relacional pode conter mais de uma chave estrangeira.

Chave primária NULL e chave estrangeira

Uma das principais diferenças entre as duas é que, diferentemente das chaves primárias, as chaves estrangeiras também podem conter valores NULL. Uma tabela em um banco de dados relacional pode ter apenas uma chave primária, que não é anulável.

Tabela temporária de chave primária e chave estrangeira

Uma restrição de chave primária pode ser definida implicitamente em tabelas temporárias e suas variáveis, enquanto uma restrição de chave estrangeira não pode ser aplicada a tabelas temporárias locais ou globais.

Removendo uma chave primária e uma chave estrangeira

Um valor de chave primária não pode ser excluído de uma tabela pai chamada de chave estrangeira em uma tabela filho. Antes de poder eliminar uma tabela pai, você deve primeiro eliminar a tabela filha. Por outro lado, um valor de chave estrangeira pode ser excluído de uma tabela filha mesmo que o valor pertença à chave primária da tabela pai.

Chave primária ou chave estrangeira: tabela de comparação

Resumo das chaves principais

As chaves desempenham um papel crucial na existência de um esquema de banco de dados para estabelecer relacionamentos entre tabelas e dentro de uma tabela. As chaves estabelecem relacionamentos e impõem vários tipos de integridade, especialmente integridade em nível de tabela e em nível de relacionamento. Primeiro, eles acreditam que uma tabela contém registros exclusivos e que os campos usados para estabelecer relacionamentos entre tabelas devem conter valores correspondentes. A chave primária e a chave estrangeira são os dois tipos de chaves mais importantes e comuns usados em bancos de dados relacionais. Uma chave primária é uma chave especial usada para identificar exclusivamente registros em uma tabela, enquanto uma chave estrangeira é usada para estabelecer um relacionamento entre duas tabelas. Ambos são idênticos em estrutura, mas desempenham funções diferentes em um esquema de banco de dados relacional.

Visualizações

Salvar VKontakte