UNISA Universidade de Santo Amaro. Material de Estudo. Módulo I: Básico Banco de dados SQL Server.

Transcrição

1 UNISA Universidade de Santo Amaro Material de Estudo Módulo I: Básico Banco de dados SQL Server Junho/2010

2

3 Objetivo do Workshop Compartilhar e apresentar informações básicas para obter um conhecimento do conceito de bancos de dados conciliando a visão acadêmica com as boas práticas utilizadas no mercado com o MS SQL Server. Publico Alvo Estudantes, entusiastas e/ou profissionais que buscam conhecimento básico de bancos de dados, visando um ponto de partida para futuro estudo e aprimoramento, em contato particular com o software de banco de dados Microsoft SQL Server.

4 Conceitos Ninguém consegue ler e escrever sem antes aprender o alfabeto. Banco de dados Relacional Os bancos de dados relacionais são os bancos de dados mais utilizados e conhecidos na atualidade. Bancos de dados relacionais, também conhecidos como RDBMS (Relational Database Management Systems Sistema de Gerenciamento de banco de dados relacionais) teve sua origem em 1970, tendo como linguagem, denominada SEQUEL (Structured English Query Language), foi desenvolvida pela IBM Corporation, INC. SEQUEL, posteriormente passou a chamar-se SQL (mas continuou sendo pronunciada como sequel ). Em 1979, a Relational Software, Inc, (atualmente Oracle Corporation) introduziu a primeira implementação disponível comercialmente do SQL. Atualmente, a linguagem SQL é aceito como a linguagem padrão do RDBMS. No intuito de padronização a linguagem SQL, é definido como norma padrão o SQL ANSI 92, sendo este padronização utilizada pelos bancos de dados atuais. Basicamente, pode-se dizer que o conceito de um banco de dados relacional está baseado em entidades e relacionamentos. Em outras palavras, múltiplas tabelas de dados e a relação entre elas. Entidades e Atributos Os bancos de dados relacionais são compostos de entidades e relacionamentos, onde entidades são conhecidas como tabelas. A tabela é exatamente o nome sugere: tabela de dados, composta por colunas e linhas onde cada coluna é um atributo que se refere a um fragmento diferente de dados e as linhas os registros. Por exemplo, temos abaixo uma entidade (tabela) de alunos e os atributos (colunas). Cada linha é um registro a qual pertence a esta entidade. Alunos Código Nome Telefone 1 Eurico Nascimento Nicolas Ferreira Entidade: Alunos (tabela com 3 colunas e 2 linhas); Atributos: Código, Nome e Telefone (colunas)

5 Relacionamento e Integridade referencial Chave Primária / Primary Key (PK): O Conceito de "Chave Primária" é fundamental para o correto entendimento de como funciona um Banco de Dados. Ao Definirmos um Campo como sendo uma Chave Primária, estamos informando que este campo é único, não possuindo registros duplicados neste campo e como uma identificação de linha única. Um campo de chave primária não permite ter a informação nula. Em outras palavras poderíamos dizer que o Campo Chave Primária identifica de maneira única cada Registro de uma Tabela, isto é, de posse do valor da Chave Primária somente localizaremos um registro com aquele valor no campo Chave Primária. Este é um conceito muito importante, pois conforme veremos mais adiante os conceitos de Integridade Referencial e Normalização estão diretamente ligados ao conceito de Chave Primária. Como apresentado anteriormente, um banco de dados é composto de várias tabelas (entidades), como por exemplo: Clientes, Pedidos, Itens de Pedidos, Produtos, etc. Embora estas informações armazenadas estejam separadas em tabelas diferentes, na prática é necessário que estas tabelas se relacionem. Figura 1: Entidades sem relacionamento Por exemplo, um pedido é feito por um cliente e este pedido pode conter vários itens de pedidos, sendo estes itens de pedidos armazenados na tabela de itens de pedido. Além disto, cada pedido possui um código único (Número Pedido), mas um mesmo cliente pode fazer diversos pedidos.

6 Figura 2: Entidades relacionamento O relacionamento entre as tabelas podem ser de três tipos: - Um para um; - Um para vários; -Vários para vários; Relacionamento Um para Um (1:1): Este relacionamento existe quando os campos que se relacionam são ambos do tipo Chave Primária (Primary Key ou PK), em suas respectivas tabelas. Cada um dos campos não apresenta valores repetidos. Na prática existem poucas situações onde é utilizado um relacionamento deste tipo. Figura 3: Relacionamento Um para Um (1:1) Relacionamento Um para vários (1:n): Este é o tipo de relacionamento mais comum entre duas tabelas. Uma das tabelas (o lado um do relacionamento) possui um campo que é a Chave Primária e a outra tabela (o lado vários) se relaciona através de um campo cujos valores relacionados podem se repetir várias vezes.

7 Figura 4: Relacionamento Um para Vários (1:n): Relacionamento Vários para Vários: Este tipo de relacionamento "aconteceria" em uma situação onde em ambos os lados do relacionamento os valores poderiam se repetir. Podemos considerar por exemplo, o caso entre Produtos e Pedidos. Podemos ter Vários Pedidos nos quais aparece um determinado produto, além disso vários Produtos podem aparecer no mesmo Pedido. Esta é uma situação em que temos um Relacionamento do Tipo Vários para Vários. Na prática não é possível implementar um relacionamento deste tipo, devido a uma série de problemas que seriam introduzidos no modelo do banco de dados. Por exemplo, na tabela de Pedidos teríamos que repetir o Número do Pedido, Nome do Cliente, Data do Pedido, etc para cada item do Pedido. Para evitar este tipo de problema é bastante comum "quebrarmos" um relacionamento do tipo Vários para Vários em dois relacionamento do tipo Um para Vários. Isso é feito através da criação de uma nova tabela, a qual fica com o lado Vários dos relacionamentos. Para exemplificar, cria-se a tabela Itens do Pedido, onde ficam armazenadas as informações sobre os diversos itens de cada pedido, aí ao invés de termos um relacionamento do tipo Vários para Vários, teremos então dois relacionamentos do tipo um para vários.

8 Figura 5: Resolvendo o detalhe do relacionamento Vários para Vários. Integridade Referencial: A Integridade Referencial é utilizada para garantir a Integridade dos dados entre as tabelas relacionadas. Por exemplo, considere um relacionamento do tipo Um-para- Vários entre a tabela Clientes e a tabela Pedidos (um cliente pode fazer vários pedidos). Com a Integridade Referencial, o banco de dados não permite que seja cadastrado um pedido para um cliente que ainda não foi cadastrado. Em outras palavras, ao cadastrar um pedido, o banco de dados verifica se o código do cliente que foi digitado já existe na tabela Clientes. Se não existir, o cadastro do pedido não será aceito, evitando a existência de filhos órfãos. Nas operações de exclusão e alteração, a integridade referencial também oferece a garantia de que os dados estejam íntegros.

9 Normalização O objetivo da normalização é eliminar redundância e inconsistência de um banco de dados, visando melhor organização, um desempenho otimizado e controle adequado das informações armazenadas. As conseqüências encontradas a normalização são: Manutenção alteração ou remoção de registos implica acessos a várias partes da base, tornando-se díficil manter a coerência; Custo de espaço de armazenamento; Desempenho as operações de acesso aos discos (leitura e gravação) são as que mais afetam o desempenho dos sistemas. Existem 5 formas normais, onde cada tabela deve atender a pré-requisitos, estabelecidos como critérios. Cada critério é cumulativo, ou seja, para alcançar a 3ª forma normal é preciso ter obedecido ao 1º e 2º critério obrigatoriamente, além dos requisitos exigidos da própria 3ª forma normal. Primeira Forma Normal "Uma tabela está na 1FN, se e somente se, não possuir atributos multivalor." Segunda Forma Normal "Uma relação está na 2FN se, e somente se, estiver na 1FN e cada atributo não-chave for dependente da chave primária inteira, isto é, cada atributo não-chave não poderá ser dependente de apenas parte da chave." Terceira Forma Normal "Uma relação R está na 3NF, se ela estiver na 2NF e cada atributo não chave de R não possui dependência transitiva, para cada chave candidata de R. Quarta Forma Normal "Uma tabela está na 4FN, se e somente se, estiver na 3FN e não existirem dependências multivaloradas Quinta Forma Normal Uma relação R está na 5FN se não puder ser mais decomposta sem perda de informação.

10 O ideal é obter um esquema equilibrado que não ponha em risco a integridade do banco de dados, mas que, simultaneamente tenha um desempenho razoável. Por essa razão, na maioria dos casos, o processo de normalização para na 3a Forma Normal (3FN). Vamos detalhar com exemplo o conceito passado anteriormente até a 3a Forma Normal, o que normalmente se utiliza no Mercado e que na prática já é o suficiente. Primeira Forma Normal "Uma tabela está na 1FN, se e somente se, não possuir atributos multivalor." Em outras palavras podemos definir que a primeira forma normal não admite repetições ou campos que tenha mais que um valor. Por exemplo: Código Nome Endereço Telefone 1 Eurico Moreira R. das Árvores, Eurico Moreira R. das Árvores, Thiago Kadota Av. do Estado, No caso acima, a tabela não atende a 1FN, justamente porque há uma repetição de linha com uma informação (telefone) com mais de um valor. A linha destacada, mostra um outro numero de telefone. É comercial? Celular? Fax? Um outro ponto seria a impossibilidade de utiliza o campo código como chave primária, uma vez que este valor não contém nas suas linhas valores exclusivos, ou seja, sem repetições. Veja o exemplo da mesma tabela normalizada pela 1FN: Código Nome Endereço Telefone 1 Telefone 2 1 Eurico Moreira R. das Árvores, Thiago Kadota Av. do Estado, Segunda Forma Normal "Uma relação está na 2FN se, e somente se, estiver na 1FN e cada atributo não-chave for dependente da chave primária inteira, isto é, cada atributo não-chave não poderá ser dependente de apenas parte da chave." Para uma tabela estar na segunda forma, além de estar na primeira forma ela não deve conter dependências parciais. Um jeito de verificar esta norma é refazer a leitura dos campos fazendo a pergunta: Este campo depende de toda a chave? Se não, temos uma dependência parcial.

11 Exemplo: Nr. Cód. Cód.Produto Nome Produto Qtde Vl.Unitário Vl.Total Pedido Cliente Impressora Laser XPTO 3 980, , Mouse Óptico usb 2 60,00 120,00 O nome do produto depende do código do produto, porém não depende do Nr.Pedido que é a chave primária da tabela, portanto não está na segunda forma normal. Isto gera problemas com a manutenção dos dados, pois se houver alteração no nome do produto teremos que alterar em todos os registros da tabela de pedido. Veja o exemplo citado acima com a normalização na segunda forma normal: Nr. Pedido Cód. Cliente Cód.Produto Qtde Vl.Unitário Vl. Total , , ,00 120,00 Cód.Produto Nome Produto 1100 Impressora Laser XPTO 3450 Mouse Óptico usb Para normalizar a tabela de pedidos, criamos a tabela de Produto que ficará com os atributos Cód.Produto e Nome Produto. Na tabela de Pedidos foi retirado o atributo de Nome de produto e a referencia da tabela de pedido fará referencia a tabela de produto utilizando como chave o atributo de cód.produto. Este exemplo é didático apenas, pois o correto seria ter uma tabela de pedidos e uma tabela de itens de pedidos, uma vez que um pedido pode ter mais de um produto. Terceira Forma Normal "Uma relação R está na 3NF, se ela estiver na 2NF e cada atributo não chave de R não possui dependência transitiva, para cada chave candidata de R. Para uma tabela estar na terceira forma, além de estar na segunda forma ela não deve conter dependências transitivas, ou seja, na terceira forma normal temos de eliminar aqueles campos que podem ser obtidos pela equação de outros campos da mesma tabela. Exemplo: Nr. Pedido Cód. Cliente Cód.Produto Qtde Vl.Unitário Vl. Total , , ,00 120,00 Note que o atributo de Valor Total apresenta uma informação resultante de outros 2 atributos, quantidade e valor unitário. Neste caso, o Valor Total depende diretamente das informações de quantidade e valor, resultado da multiplicação de quantidade e valor unitário.

12 Imagine uma situação na qual a quantidade deve ser alterada. O valor deve ser recalculado por conseqüência, ao invés de ser também alterado pelo usuário. Em outras palavras, devemos entender que o valor total é um atributo calculado e se referencia a outros atributos, não é um atributo que deve ser informado, então para atender a terceira forma normal este atributo não deve fazer parte desta entidade. Exemplificando no caso citado, teremos a tabela apresentada na seguinte forma: Nr. Pedido Cód. Cliente Cód.Produto Qtde Vl.Unitário , ,00 Como citado anteriormente, não iremos tratar das demais formas normais porque na prática estas três formas são suficientes. Este workshop é voltado ao prático, não deixando de lado o básico conceitual.

13 Constraints Para implementar a integridade de dados temos os objetos chamados de constraints no banco de dados. Estas constraints devem ser criadas utilizando as instruções de criação e alteração de tabela CREATE TABLE e ALTER TABLE, respectivamente. Segue uma breve explanação sobre cada uma delas e para qual aspecto elas deve ser utilizadas. Constraint DEFAULT Esta constraint serve para indicar um valor padrão para um campo, quando o mesmo não for especificado. Exemplo: se a tabela Cliente possui dois campos, Código e Nome, e para o campo Nome existe uma constraint DEFAULT criada, ao inserirmos dados nesta tabela podemos somente fornecer o conteúdo do campo Código, pois o conteúdo do campo Nome será automaticamente preenchido com o valor definido na constraint DEFAULT. Também podemos utilizar esta constraint como um objeto independente, assim como as rules (regras). Não podemos criar constraints em campos com o tipo de dados rowversion e campos que possuem uma propriedade IDENTITY definida. Constraint CHECK A constraint CHECK 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. Esta constraint pode ser desabilitada, para caso de uma grande inserção de dados na tabela. Constraint 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. A constraint PRIMARY KEY 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. Constraint UNIQUE Esta constraint faz a validação de valores únicos em uma coluna de uma tabela. Se um campo estiver definido com a constraint UNIQUE nenhum valor repetido poderá ser fornecido para esta campo. Diferente da PRIMARY KEY, podemos colocar várias constraints UNIQUE por tabela mas para cada campo que possue uma constraint UNIQUE somente podemos inserir o valor NULL uma vez. A constraint UNIQUE deve ser utilizada para manter integridade de entidade. Quando esta constraint é criada na tabela, um índice também é automaticamente criado sobre a coluna sobre a qual a constraint está definida. Este índice não pode ser apagado diretamente, devemos apagar a constraint UNIQUE primeiro.

14 Constraint FOREIGN KEY Esta constraint é utilizada para implementar o conceito de chave estrangeira e serve para indicar que o conteúdo de um campo deve se referenciar a um outro campo que possua ou uma chave primária ou uma constraint UNIQUE. Quando o campo que está sendo referenciado residir na mesma tabela, não precisamos utilizar a palavra-chave FOREIGN KEY, podendo somente utilizar REFERENCES. Esta constraint também pode ser desabilitada, para o caso de uma grande inserção de dados na tabela. A constraint FOREIGN KEY deve ser utilizada para manter integridade referencial e podemos ainda programar eventos em cascata utilizando as cláusulas ON DELETE e ON UPDADE.

15 Indíce (Index) Os índices são estruturas opcionais associadas às tabelas, as quais aumentam o desempenho da recuperação de dados. Assim como o índice de um livro ajuda a você a localizar as informações em um espaço de tempo bem menor, um índice do banco de dados fornece um caminho mais rápido para dados da tabela. Ao processar uma solicitação, o banco de dados pode usar de forma eficiente algum ou todos os índices disponíveis para localizar as linhas solicitadas. Eles são úteis quando os aplicativos consultam com freqüência um intervalo de linhas de uma tabela. Exemplo: Todos os empregados com salário maior que mil dólares ou uma linha específica. Os índices são criados em uma ou mais colunas de uma tabela. Depois de criado, ele é automaticamente atualizado e usado pelo banco de dados. As alterações nos bancos de dados tais como, o acréscimo, a atualização ou a exclusão de linhas é incorporado automaticamente e todos os índices relevantes com total visualização para usuários. Os índices são lógica e fisicamente independentes dos dados e podem ser excluídos e criados separadamente e a qualquer momento, sem afetar as tabelas ou os outros índices. Quando tirados, todos os aplicativos continuam funcionado; entretanto, o acesso aos dados indexados anteriormente agora será ou poderá se tornar mais lento. Com as inserções e exclusões ocorridas com o tempo, é possível que os índices, aos poucos, vão se degradando. Para isso, existe o papel de administrador de banco de dados (DBA) ou, em algumas organizações, o administrador de dados (DA) que monitora, analisa e reorganiza estes índices. Triggers A trigger (gatilho) é um objeto de banco de dados, associado a uma tabela, definido para ser disparado, respondendo a um evento em particular. Tais eventos são os comandos DML (Data Manipulation Language) INSERT; DELETE; UPDATE. Este objeto não é comum estar definido em todos os bancos de dados, a utilização depende da definição de regras a aplicar, em alguns casos não se aplica a utilização, em outros, é de fundamental necessidade. Exemplo: - Atualização de estoque após a venda de um produto;

16 Stored Procedures As Stored Procedures são os procedimentos armazenados e executados no servidor de banco de dados. Existem dois tipos de Stored Procedures: Select Procedure são procedures usadas como se fossem uma relação em um comando SELECT. Uma Select Procedure deve retornar um ou mais valores como parâmetros de saída, ou um erro. Executable procedures são procedures chamadas explicitamente por uma aplicação, através de comando EXECUTE PROCEDURE. Uma Executable procedure pode opcionalmente retornar valores e/ou erros. A sintaxe de ambos os tipos de Stored Procedures é a mesma, e a diferença é apenas conceitual, mudando a forma como são definidos e utilizados. No entanto, existem alguns comandos disponíveis que foram concebidos especificamente para um dos tipos. De qualquer forma, uma Stored Procedure pode opcionalmente receber um ou mais parâmetros de entrada. Outro detalhe é que as Stored Procedures são armazenadas na base de dados, portanto somente se tornam disponíveis para outras transações depois que aquela que o criou é finalizada por um comando COMMIT. Existem várias outras Stored Procedures que são de sistema, comuns em bancos de dados, não podem ser alteradas nem deletadas. Functions As functions(funções) são fornecidas pelo fabricante da solução de banco de dados e podem ser também geradas pelo usuário, de acordo com a necessidade. Uma UDF (Função Definida pelo Usuário) é uma extensão ou adição às funções internas existentes da linguagem SQL. Com UDFs, é permitido que você estenda a função do sistema de banco de dados, incluindo definições de funções a serem aplicadas no mecanismo do banco de dados. Ao incluir a função no mecanismo, você poderá economizar o esforço de recuperar linhas do banco de dados e aplicar funções semelhantes nos dados recuperados. Funções definidas pelo usuário permitem que o banco de dados explore as mesmas funções do mecanismo utilizadas pelos aplicativos. Elas fornecem maior interatividade entre o aplicativo e o banco de dados. Também contribuem com a alta produtividade para desenvolvedores de aplicativos, pois elas incentivam a reutilização de códigos. Como exemplo, pode-se criar uma simples função definida pelo o usuário que retorne o primeiro nome do cliente em uma tabela aonde só possui o nome completo.

17 Views A view (visão) é uma apresentação personalizada dos dados de uma ou mais tabelas. Ela também pode ser vista como uma consulta armazenada. As visões não contêm ou armazenam realmente os dados, mas elas os retiram das tabelas nas quais se baseiam, chamadas de tabelas base das visões. As tabelas base podem, por sua vez, serem tabelas mesmo ou visões. Assim como as tabelas, as visões podem ser consultadas, atualizadas, inseridas e excluídas com algumas restrições. Todas as operações executadas em uma visão, na verdade, afeta as tabelas base desta visão. Mesmo a apresentação de uma view ser em forma de tabela, em uma view não se aplica normalização aplicação das formas normais. Apresentação de um Modelo Entidade Relacionamento Básico O modelo abaixo apresentado será utilizado como uma base para as demonstrações no workshop.