bancos de dados sql server 2012 integridade de dados

36
Bancos de Dados SQL Server 2012 Integridade de Dados

Upload: internet

Post on 18-Apr-2015

125 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: Bancos de Dados SQL Server 2012 Integridade de Dados

Bancos de Dados

SQL Server 2012

Integridade de Dados

Page 2: Bancos de Dados SQL Server 2012 Integridade de Dados

Tipos de Integridade de Dados

Page 3: Bancos de Dados SQL Server 2012 Integridade de Dados

Tipos de Integridade de Dados

• Integridade de domínio: – Especifica um conjunto de valores válidos para

uma coluna e também se valores nulos (Null) são permitidos.

– Assegurada através de validações (CHECK CONSTRAINTS) e também por restrições inerentes ao tipo dados, formato e faixa de valores permitida para uma coluna.

Page 4: Bancos de Dados SQL Server 2012 Integridade de Dados

Tipos de Integridade de Dados• Integridade de entidade (tabela): – Requer que todas as linhas em uma tabela tenham um

identificador único , também conhecido como chave primária (PRIMARY KEY).

– Pode ser composta de uma só coluna ou uma combinação de colunas (composite primary key).

– A relação de integridade entre a chave primária de uma tabela com outras tabelas do banco de dados, determinará se um valor da chave primária poderá ser modificado ou mesmo se uma determinada linha da tabela poderá ser excluída. Exemplo: Um cliente não poderá ter seu código (chave primária) alterado se já tiver compras feitas em seu nome. Da forma similar, um cliente não poderá ser excluído, se o mesmo já tiver efetuado compras. Em ambos casos, se a integridade não fosse mantida, os registros de compras poderiam ficar “órfãos”, ou seja, sem identificação de quem efetuou a compra.

Page 5: Bancos de Dados SQL Server 2012 Integridade de Dados

Tipos de Integridade de Dados• Integridade referencial:– Assegura que os relacionamentos entre a chave

primária (primary key) de uma tabelas e a(s) chave(s) estrangeira(s) (foreign keys) de outras tabelas que referenciam a chave primária sejam sempre mantidas.

– Uma linha na tabela não pode ser excluída ou sua chave primária modificada se a mesma é referenciada por uma ou mais chaves estrangeiras em uma ou mais tabelas.

– Operações de alteração ou exclusão em cascata podem ser configuradas, afim de mudar esse comportamento padrão.

– Integridade referencial pode ser definida entre tabelas ou mesmo entre colunas de uma mesma tabela.

Page 6: Bancos de Dados SQL Server 2012 Integridade de Dados

Determinando o tipo de restrição de integridade a ser usado

Page 7: Bancos de Dados SQL Server 2012 Integridade de Dados

Restrições disponíveis no SQL ServerTipo de

Integridade Tipo de Restrição Descrição

DEFAULT

Especifica o valor que será fornecido a uma coluna quando um valor não foi explicitamente informado no comando INSERT.

CHECK Especifica quais valores são aceitáveis em uma coluna.

REFERENCIAL

Especifica quais valores são aceitáveis em um UPDATE baseado nos valores de uma coluna em uma outra tabela.

PRIMARY KEY

Identifica unicamente cada linha da tabela - assegura que usuários não entrem valores duplicados e que um índice seja criado para aumentar o desempenho. Valores nulos (NULL) não são permitidos.

UNIQUE

Impede a duplicação de chaves candidatas e assegura que um índice seja criado para aumentar o desempenho. Valores nulos (NULL) são pemitidos.

FOREIGN KEY

Define uma coluna ou combinação de colunas cujos valores correspondem a uma primary key na mesma ou em outra tabela.

CHECKEspecifica que valores são aceitáveis baseados em valores de outras colunas numa mesma tabela.

DOMÍNIO

ENTIDADE

REFERENCIAL

Page 8: Bancos de Dados SQL Server 2012 Integridade de Dados

Criando Constraints (restrições)• Use CREATE TABLE ou ALTER TABLE• Podem ser adicionadas a uma tabela com

dados já existentes.• Podem referenciar uma ou mais colunas – Uma coluna: constraint à nível de coluna– Multiplas colunas: constraint à nível de tabela

Page 9: Bancos de Dados SQL Server 2012 Integridade de Dados

Sintaxe Parcial

Page 10: Bancos de Dados SQL Server 2012 Integridade de Dados

Sintaxe Parcial (cont.)

Page 11: Bancos de Dados SQL Server 2012 Integridade de Dados

ExemploUSE TesteDB;CREATE TABLE dbo.Produto(Produto_Cod int IDENTITY (1,1) NOT NULL,Produto_Nome nvarchar (40) NOT NULL,Fornecedor_Cod int NULL,Categoria_Cod int NULL,Produto_Unidade nvarchar (20) NULL,Produto_Valor money NULL CONSTRAINT DF_Produto_Valor DEFAULT(0),Produto_EstoqueAtual smallint NULL CONSTRAINT DF_Produto_EstoqueAtual DEFAULT(0),

Page 12: Bancos de Dados SQL Server 2012 Integridade de Dados

Exemplo (cont.)…Produto_PedidoMinimo smallint NULL CONSTRAINT DF_Produto_PedidoMinimo DEFAULT(0),Produto_EstoqueMinimo smallint NULL CONSTRAINT DF_Produto_EstoqueMinimo DEFAULT(0),Produto_Descontinuado bit NOT NULL CONSTRAINT DF_Produto_Descontinuado DEFAULT(0),CONSTRAINT PK_Produto PRIMARY KEY CLUSTERED (Produto_Cod),

Page 13: Bancos de Dados SQL Server 2012 Integridade de Dados

Exemplo (cont.)…CONSTRAINT FK_Produto_Categoria FOREIGN KEY (Categoria)REFERENCES dbo.Categoria (Categoria_Cod) ON UPDATE CASCADE,CONSTRAINT FK_Produto_Fornecedor FOREIGN KEY (Fornecedor_Cod)REFERENCES dbo.Fornecedor (Fornecedor_Cod) ON DELETE CASCADE,

Page 14: Bancos de Dados SQL Server 2012 Integridade de Dados

Exemplo (cont.)…

CONSTRAINT CK_Produto_Valor CHECK (Valor >= 0),CONSTRAINT CK_EstoqueMinimo CHECK (EstoqueMinimo >= 0),CONSTRAINT CK_EstoqueAtual CHECK (EstoqueAtual >= 0),CONSTRAINT CK_PedidoMinimo CHECK (PedidoMinimo >= 0))

Page 15: Bancos de Dados SQL Server 2012 Integridade de Dados

Exercícios (TesteDB)

1. Criar tabela Fornecedor para armazenar diferentes fornecedores de produtos de informática. A tabela deverá conter pelo menos o código do fornecedor (chave primária) e o nome do fornecedor. O nome do fornecedor não poderá se repetir.

2. Popular a tabela Fornecedor com 5 diferentes fornecedores.3. Criar tabela Categoria para armazenar as diferentes categorias

de produtos de informática, como laptop, desktop, minipad, impressora, acessórios, etc. A tabela deverá conter pelo menos o código da categoria e uma descrição para a mesma. A descrição não poderá se repetir.

4. Popular a tabela Categoria com 5 diferentes categorias de produtos.

Page 16: Bancos de Dados SQL Server 2012 Integridade de Dados

Exercícios (TesteDB)5. Criar a tabela Produto conforme mostrado nos slides anteriores.6. Popular a tabela Produto com, pelo menos, 3 produtos de informática.7. Criar tabela UF para armazenar a sigla dos diferentes Estados do Brasil . A tabela deverá conter a sigla do Estado (char (2)) e o nome do Estado. Nem o nome e nem a sigla do estado poderão se repetir.8. Popular a tabela UF com, pelo menos, 5 estados da União.9. Adicionar colunas para armazenar o endereço completo do fornecedor na tabela Fornecedor, incluindo a sigla dos Estados onde os mesmos se encontram. 10. Adicionar uma restrição de integridade para impedir que sejam entrados endereços de fornecedores com siglas de Estado inválidas. Verificar que a mesma funciona.

Page 17: Bancos de Dados SQL Server 2012 Integridade de Dados

Tipos de Constraints (Restrições)

• DEFAULT Constraints• CHECK Constraints• PRIMARY KEY Constraints• UNIQUE Constraints• FOREIGN KEY Constraints• Integridade Referencial em Cascata

Page 18: Bancos de Dados SQL Server 2012 Integridade de Dados

Restrições do tipo Default

• Aplicam-se somente a comandos INSERT• Somente um DEFAULT por coluna• Não pode ser usada com IDENTITY• Permitem alguns valores supridos pelo sistema

USE TesteDBALTER TABLE dbo.ClienteADDCONSTRAINT DF_Cliente_Nome DEFAULT 'Não informado' FOR Cliente_Nome

Page 19: Bancos de Dados SQL Server 2012 Integridade de Dados

Restrições do tipo DEFAULT (cont.)

Permitem alguns valores supridos pelo sistema: USER, CURRENT_USER, SESSION_USER, SYSTEM_USER, CURRENT_TIMESTAMP, getdate()Exemplo:USE TesteDB;ALTER TABLE dbo.PedidoADDCONSTRAINT DF_Pedido_Data DEFAULT getdate() FOR Pedido_Data;

Page 20: Bancos de Dados SQL Server 2012 Integridade de Dados

Restrições do tipo CHECK• São usadas com INSERT e UPDATE: a restrição é

validada toda a vez que um INSERT ou UPDATE é executado.

• Podem referenciar outras colunas na mesma tabela: Por exemplo: Uma coluna salario pode fazer referência ao valor da coluna nivel_salarial

• Não podem conter subqueries (referência a outras linhas da mesma tabela ou de outras tabelas)

Page 21: Bancos de Dados SQL Server 2012 Integridade de Dados

Restrições do tipo CHECK (cont.)Exemplo:USE TesteDB;ALTER TABLE dbo.FuncionarioADDCONSTRAINT CK_Funcionario_DataNascCHECK (Funcionario_DataNasc > '01-01-1900' AND Funcionario_DataNasc <getdate())

Page 22: Bancos de Dados SQL Server 2012 Integridade de Dados

Restrição Primary Key• Somente uma PRIMARY KEY por Table• Valores devem ser únicos• Valores NULL não são permitidos• Cria um índice Unique nas colunas especificadasUSE TesteDB;ALTER TABLE dbo.ClienteADDCONSTRAINT PK_ClientePRIMARY KEY NONCLUSTERED (Cliente_Cod)

Page 23: Bancos de Dados SQL Server 2012 Integridade de Dados

Restrição Primary Key (cont.)

• Um índice Unique (único) é criado nas colunas especificadas na Primary Key: – Para garantir a unicidade das linhas– Pode ser CLUSTERED ou NONCLUSTERED – O default é CLUSTERED, se já não existir um – Não poder ser eliminado diretamente– É eliminado automaticamente quando a Primary

Key é excluída.

Page 24: Bancos de Dados SQL Server 2012 Integridade de Dados

Restrição Unique

• Permitem somente um valor NULL• Multiplas constraints UNIQUE são permitidars por Tabela• Definida por uma ou mais colunas• Garantida por um índice do tipo Unique (único)

USE TesteDB;ALTER TABLE dbo.FornecedorADDCONSTRAINT UN_Fornecedor_NomeUNIQUE NONCLUSTERED (Fornecedor_Nome);

Page 25: Bancos de Dados SQL Server 2012 Integridade de Dados

Restrição Foreign Key• Deve referenciar sempre a PRIMARY KEY ou constraint

UNIQUE da mesma ou de outra tabela.• Provê integridade referencial para uma ou mais colunas

da tabela• Índice de suporte não é criado automaticamenteUSE TesteDB;ALTER TABLE dbo.PedidoADD CONSTRAINT FK_Pedido_ClienteFOREIGN KEY (Cliente_Cod)REFERENCES dbo.Cliente (Cliente_Cod)

Page 26: Bancos de Dados SQL Server 2012 Integridade de Dados

Integridade Referencial em Cascata

Page 27: Bancos de Dados SQL Server 2012 Integridade de Dados

Integridade Referencial em Cascata• FOREIGN KEY com CASCADE permite que qualquer

alteração nos valores das colunas que definem as restrições PRIMARY KEY ou UNIQUE sejam automaticamente propagadas para as colunas FOREIGN KEY.

• Suportam CASCADE ou NO ACTION (default)– NO ACTION: Qualquer tentativa de excluir ou alterar uma

chave referenciada por Foreign Keys é bloqueada, gerando um erro e desfazendo a transação.

– CASCADE: Quando a Primary Key é alterada numa tabela referenciada por Foreign Keys (“pai”) as linhas correspondentes nas tabelas que a referenciam (“filhas”) também são alteradas automaticamente.

Page 28: Bancos de Dados SQL Server 2012 Integridade de Dados

Integridade Referencial em Cascata

• Suportadas nas cláusulas ON DELETE e ON UPDATE

• Sintaxe:[CONSTRAINT constraint_name][FOREIGN KEY] [(column[,…n])]REFERENCES ref_table [(ref_column [,…n])].[ ON DELETE { CASCADE | NO ACTION } ][ ON UPDATE { CASCADE | NO ACTION } ]

Page 29: Bancos de Dados SQL Server 2012 Integridade de Dados

Integridade Referencial em Cascata

Exemplo:

USE TesteDB;ALTER TABLE dbo.PedidoADD CONSTRAINT FK_Pedido_ClienteFOREIGN KEY (Cliente_Cod)REFERENCES dbo.Cliente (Cliente_Cod)ON DELETE CASCADE ON UPDATE NO ACTION;

Page 30: Bancos de Dados SQL Server 2012 Integridade de Dados

Desabilitando restrições

• Desabilitando restrições para dados já existentes

• Desabilitando restrições para inserção de novos dados

Page 31: Bancos de Dados SQL Server 2012 Integridade de Dados

Desabilitando restrições para dados já existentes

• Somente para restrições CHECK e FOREIGN KEY• Use a opção WITH NOCHECK para criar a

constraint sem verificar os dados existentes• Útil quando dados não irão mudar no futuro• Útil quando se sabe que os dados TÊM problemas• Útil quando se sabe que os dados NÃO TÊM

problemas• Mudanças posteriores serão verificadas contra as

restrições em vigor

Page 32: Bancos de Dados SQL Server 2012 Integridade de Dados

Desabilitando restrições para dados já existentes

USE TesteDB;ALTER TABLE dbo.FuncionarioWITH NOCHECKADD CONSTRAINT FK_Funcionario_Funcionario_ChefeImediatoFOREIGN KEY (Funcionario_ChefeImediato)REFERENCES dbo.Funcionario(Funcionario_Cod);

Page 33: Bancos de Dados SQL Server 2012 Integridade de Dados

Desabilitando restrições para inserção de novos dados

• Somente para restrições CHECK e FOREIGN KEY• Use ALTER TABLE ... NOCHECK ou CHECK CONSTRAINT• Use quando:– Os dados a serem inseridos já estão em conformidade com as

restrições– Você está inserindo dados que não estão em conformidade com as

restrições (vai requerer posterior “faxina” nos dados antes que a restrição possa ser reativada)

USE TesteDB;ALTER TABLE dbo.FuncionarioNOCHECKCONSTRAINT FK_Funcionario_Funcionario_ChefeImediato

Page 34: Bancos de Dados SQL Server 2012 Integridade de Dados

Exercícios (BD do trabalho 01)• Tente criar uma CHECK constraint, em cima de uma só coluna

de qualquer tabela, e que viole os dados já existentes• Force a criação da CHECK constraint, impedindo a validação

dos dados já existentes• Tente alterar uma coluna que não seja a coluna em que foi

criada a CHECK constraint, porém que seja de uma das linhas da tabela que possua valores que violem a CHECK constraint. Verifique o que ocorre.

• Desabilite a CHECK constraint e tente fazer a mesma alteração do item anterior. Verifique o que ocorre.

• Habilite a CHECK constraint• Exclua a CHECK constraint criada no exercício

Page 35: Bancos de Dados SQL Server 2012 Integridade de Dados

Exercícios (BD do trabalho 01)• Remova uma das Foreign Keys criadas em uma das

tabelas do banco de dados• Recrie a mesma, com as opções de alteração e deleção

em cascata• Altere um valor de chave primaria na tabela “pai” (a

qual a foreign key recriada referencia) e verifique se o novo valor da chave foi propagado para a tabela “filha” (a que contém a foreign key recriada)

• Exclua uma das linhas da tabela “pai” que contenha valores de chave primária que estejam presentes na tabela “filha” (a que contém a foreign key recriada) e verifique se a deleção em cascata de fato ocorreu