Trabalho de Banco de dados (1)

Prévia do material em texto

� PAGE \* MERGEFORMAT �15�
1 INTRODUÇÃO
Integridade é fundamental quando um Banco de Dados é projetado, são pensadas as possíveis formas para que esta aplicação grave os dados corretamente no Banco de Dados, mas às vezes, é importante de definir, em nível de banco, quais as validações que devem ser feitas para evitar inconsistências nos dados e que, futuramente, se tornariam problemas. Em um Banco de Dados, possuímos três formas de Integridade: Integridade de Domínio, Integridade de Entidade e Integridade Referencial.
Na integridade de Domínio, as validações ocorrem em cada campo de nossa tabela (ou entidade), como por exemplo, se um campo deve aceitar valores Null ou apenas uma faixa de valores, por exemplo: 
Temos um campo Sexo, que só deve aceitar valores do tipo M ou F e, independente de nossa aplicação, não deverá aceitar outros valores. Com integridade de domínio, podemos fazer isto facilmente. 
Já na Integridade de Entidade, temos validações um nível acima, onde definimos quais campos de nossa tabela são chaves primárias (PK) ou únicas (UK).
Um exemplo de chave única é o campo de CPF que nunca pode se repetir. 
OBS: Geralmente chaves únicas são chamadas de chaves candidatas, pois são candidatas a chave primária, mas não são uma.  
E por último, mas não menos importante, vemos a Integridade Referencial, onde criamos nossas referências a campos do tipo PK ou UK de outras tabelas, as famosas chaves estrangeiras FK. Lembre-se que eu não posso criar uma referência (relacionamento) de uma coluna se esta não for uma chave primária de outra tabela. 
Este tipo de integridade é fundamental para verificar se um dado será inserido de forma correta e, como é uma chave estrangeira, se este dado realmente existe. 
Vamos tirar por exemplo uma tabela chamada PEDIDO e uma CLIENTE. Eu só posso adicionar um registro de PEDIDO se existir um CLIENTE relacionado a ele, e é assim que as verificações acontecem, no momento da inclusão ou alteração, o SGBD verifica se o registro existe e caso não, retorna um erro. 
As Constraints são restrições feitas para as colunas nas tabelas contendo diversos tipos, na qual falaremos adiante.
2 CONSTRAINT UNIQUE
Está Constraint determina que uma coluna não poderá ter 2 linhas com o mesmo valor, ou seja, cria uma restrição para a coluna, onde não pode ter dois valores iguais. Veja o exemplo abaixo:
CREATE TABLE Newsletter (
NewsletterId int not null IDENTITY(1,1) CONSTRAINT PK_Newsletter_NewsletterId PRIMARY KEY, Email nvarchar(64) not null CONSTRAINT UQ_Newsletter_Email UNIQUE
)
Ao inserir dois e-mails iguais ele vai gerar um erro de UNIQUE KEY, dizendo que você está duplicando o registro.
3 CONSTRAINT CHECK
Esta constraint nos permite criar uma regra para o preenchimento de um certo campo em uma tabela. Nesta regra podemos utilizar valores de outros campos da mesma tabela para fazer a validação dos dados.
A restrição CHECK pode ser usada para limitar o intervalo de valores que podem ser colocados em uma coluna. Se você definir uma restrição CHECK em uma tabela ela pode limitar os valores em determinadas colunas com base nos valores em outras colunas da linha.
Uma constraint CHECK está associada a uma tabela e contém uma condição de verificação que deve ser cumprida para cada registro (ou linha) da tabela, cada vez que se insere ou se atualiza uma linha, o gerenciador de banco de dados compara essa linha com a condição de verificação estabelecida para garantir que os novos valores dos campos estejam corretos.
Esta verificação também ocorre quando novos registros são acrescentados em uma tabela através de utilitários do sistema, se a condição de verificação for Falsa, ou seja, se forem detectados valores que não estejam de acordo com a condição definida, o gerenciador de banco de dados recusa a solicitação de inserção ou de atualização
Toda vez que for inserido ou atualizado um registro, o gerenciador de banco de dados verifica as regras existentes para garantir que os novos valores desses registros estejam corretos. Veja o exemplo abaixo:
Se for associado os valores "SP", "RJ" e "MG" ao campo "Estado" de uma tabela através de CHECK constraint, apenas estes valores serão aceitos na base de dados, dispensando à aplicação verificar a validade dos dados. Abaixo é mostrado um código contendo a constraint CHECK:
CREATE TABLE produtos (
prod_no integer,
prod_descricao text,
prod_preco numeric CHECK (prod_preco > 0)
);
4 CONSTRAINT NOT NULL
 
A constraint NOT NULL impede que valores nulos sejam inseridos em uma coluna. Isto é válido tanto para quando se usa o INSERT quanto para quando se usa o UPDATE. Veja o exemplo abaixo.
Create table ALUNO1 (cd_aluno number(5) not null, nm_aluno varchar2(30) not null);
5 Constraint DEFAULT
Essa constraint é responsável por colocar valores padrões nas colunas.
Ex: DataCadastro eu posso colocar um valor padrão que seria a data de hoje.
CREATE TABLE Teste
(
Nome nvarchar(64) not null, DataCadastro datetime not null CONSTRAINT DF_Teste_DataCadastro DEFAULT getDate()
)
Então ao inserir um nome e “ignorarmos” a data de cadastro, ele preencherá com a data de hoje.
Esta constraint serve para indicar um valor padrão para um campo, quando o mesmo não for especificado. Exemplo: se a tabela Teste possui dois campos, Nome e DataCadastro, e para o campo DataCadastro existe uma constraint DEFAULT criada, ao inserirmos dados nesta tabela podemos somente fornecer o conteúdo do campo Nome, pois o conteúdo do campo DataCadastro será automaticamente preenchido com o valor definido na constraint DEFAULT. 
Esta constraint deve ser utilizada para manter integridade de domínio. Também podemos utilizar esta constraint como um objeto independente. 
6 CHAVES ESTRANGEIRAS (FOREIGN KEY)	
As chaves estrangeiras, do inglês FOREIGN KEY são relacionamentos entre duas tabelas de um banco de dados. Consiste em uma ou mais colunas em uma tabela que referencia uma ou mais colunas em outra tabela (tabela referenciada). As colunas da tabela referenciada a que se referem às chaves estrangeiras devem ser chaves primárias ou outra chave candidata.
Na tabela referenciada, as linhas de dados não podem conter dados replicados nos campos referenciados pela chave estrangeira de outra tabela, já na tabela que referencia, ou seja, aquela que possui uma chave estrangeira para um conjunto de campos na tabela referenciada, as linhas podem conter dados replicados, ou seja, várias linhas da tabela que referencia podem apontar para uma única linha da tabela referenciada. Na maioria das vezes, isso reflete um relacionamento de um para muitos. Abaixo é dado um exemplo de como funcionam as chaves estrangeiras.
Um campo chave estrangeira de uma tabela deve referenciar uma linha de dados de outra tabela, como no exemplo abaixo:
	TABELA “ARTISTA”
	
	TABELA “ALBUM”
	artista_id (PK)
	artista_nome
	
	artista_id (FK)
	album_id
	album_name
	1
	Reginaldo Rossi
	
	1
	1
	The Best of Brega
	2
	Dérick
	
	2
	2
	Memórias de um nerd
	3
	Ivete Sangalo
	
	2
	3
	10.000 anos de história
	
	
	
	3
	4
	Perfil
	
	
	
	4
	5
	Nenhum de nós
	Referência quebrada
	Na ilustração acima, fica mais claro o conceito, funcionamento e função das chaves estrangeiras.
	Como primeira consideração, pode-se observar que o campo artista_id existe em ambas as tabelas, com um diferencial: na tabela ARTISTA o campo é uma chave primária (PK), usado como uma identificação única para cada registro; na tabela ALBUM o campo artista_id é uma chave estrangeira (FK), usada para ligar os álbuns a seus respectivos artistas.
	Também é possível observar que uma FK pode conter registros com valores idênticos, ou seja, vários registros apontando para um único registro da PK. Isso fica claro observando que o artista 2 (Dérick) éreferenciado pelos álbuns 2 e 3.
	Um problema que pode ser observado na relação apresentada na ilustração acima é que existe uma referência quebrada, ou seja, um registro em ALBUM (album_id=5) que referencia um registro não existente na tabela correspondente (ARTISTA). Uma das funções da FK é evitar que esse tipo de inconsistência aconteça, usando para tanto, restrições que impedem a inserção de registros com referências incorretas e a aplicação de regras bem definidas para a atualização e ou exclusão de registros que referenciam dados em outra tabela. Uma dessas regras é a CASCADE, que faz com que sempre que um registro é apagado na tabela que contém a PK, todos os registros em tabelas que fazem referência ao registro que está sendo apagado são excluídos também.
7 primary key
Esta constraint serve para definirmos um ou mais campos como chaves primárias. Uma chave primária é o atributo de um ou mais campos que identifica unicamente um registro em uma tabela. Podemos criar somente uma constraint PRIMARY KEY por tabela e não podemos colocar o valor NULL nos campos que compõem a chave primária.
Quando a chave primária é formada por um único campo da tabela, esse campo não pode ter dois ou mais registros de mesmo valor, e também não pode conter nenhum registro nulo. Se a chave primária é composta, ou seja, formada por mais de um campo, os valores de cada campo podem se repetir, mas não a combinação deles. Exemplo: 
A tabela 'Livros_Autores' tem como chave primária (codigo_livro, codigo_autor). Podem existir nessa tabela os registros: (5, 9), (5, 10), (4, 9), (9, 5); Mas não podem existir dois registros (5, 9).
Esta constraint deve ser utilizada para manter integridade de entidade. Quando esta constraint é criada na tabela, um índice também é automaticamente criado sobre as colunas que fazem parte da chave primária. Este índice não pode ser apagado diretamente, devemos apagar a constraint PRIMARY KEY primeiro.
Na imagem abaixo, veremos um exemplo de uma PRIMARY KEY utilizando o aplicativo SGBD PhpMyadmin utilizando MYSQL:
Foi utilizado o seguinte código para a geração da tabela teste_PRIMARY_KEY:
 
CREATE DATABASE teste; 
 USE teste;
CREATE TABLE `teste_PRIMARY_KEY` (`indice` int(11) NOT NULL default '0', `nome` varchar(150) default NULL, PRIMARY KEY (`indice`) );
REFERÊNCIAS BIBLIOGRÁFICAS
SILBERSCHATZ, Abraham e KORTH, Henry F. Sistema de Banco de Dados. Rio de Janeiro: ELSEVIER, 2006.
DATE, Christopher J. Introdução a Sistemas de Banco de Dados. Rio de Janeiro: Campus, 2000.