Júlio Battisti Livros e Cursosa sua sala de aula na internet

É correto dizer que existe um Capítulo que seja “o mais importante de um livro???” Eu acredito que sim. É o caso deste primeiro capítulo, o qual, sem nenhuma dúvida, é o mais importante deste livro. Este capítulo apresenta os fundamentos teóricos do modelo relacional de dados e da linguagem T-SQL, os dois pilares sobre os quais foram construídos todos os serviços do SQL Server 2005.

Neste capítulo você aprenderá sobre os conceitos básicos de Bancos de Dados Relacionais. Também aprenderá sobre os comandos básicos da linguagem SQL – Structured Query Language. No SQL Server 2005 a linguagem é chamada de T-SQL, sendo o “T” de Transact.

Durante muitos anos, no início da informatização das empresas, as aplicações eram baseadas em computadores de grande porte, conhecidos como Mainframes. Nesta época as aplicações, normalmente desenvolvidas em linguagens de programação tais como Cobol, PL1, Algol ou Natural Adabas, ficavam residentes nestes computadores e os dados também. A lógica para acesso aos dados estava embutida dentro da própria aplicação. Com isso, se mudasse a estrutura de armazenamento das informações, a aplicação teria que ser reescrita. Para acessar as aplicações, o usuário utilizava os chamados “terminais burros” (também conhecidos como “terminais verdes”, devido a cor das letras normalmente ser verde em um fundo preto). Estes terminais eram, simplesmente, uma extensão do Mainframe, equipados com teclado e vídeo. Nenhum processamento era realizado no próprio terminal. Todo e qualquer comando era enviado para processamento no Mainframe, e os resultados mandados de volta para o terminal.

Observe que utilizei os verbos sempre no passado. Você deve estar pensando: “Este cara está maluco, pois ainda hoje muitas aplicações rodam, e bem, no bom e velho Mainframe”. E eu serei obrigado a concordar com o amigo leitor. Muitas e importantes são as aplicações que ainda rodam em Mainframes e duvido que em um futuro próximo, digamos cinco anos, todas estas aplicações sejam migradas para outras plataformas e modelos de desenvolvimento. Mas também precisamos admitir que é muito pequeno, para não dizer mínimo, o desenvolvimento de novas aplicações para o modelo Terminal – Mainframe clássico.

Com o deslocamento do modelo de desenvolvimento do Mainframe; primeiro para o modelo Cliente/Servidor clássico de duas camadas, depois a evolução para o modelo de desenvolvimento Web com três ou mais camadas, também sofreram modificações os Bancos de Dados que dão suporte ao desenvolvimento destas aplicações. O Mainframe utiliza formatos de Bancos de Dados proprietários, criados pelos fabricantes dos equipamentos, na maioria dos casos a IBM.

Nota: No Capítulo 2 iremos detalhar os modelos de desenvolvimento em duas, três ou n camadas. Também falaremos sobre as vantagens e desvantagens de cada modelo.

Com a expansão cada vez maior das redes locais de computadores e a interconexão destas redes entre si, formando a WAN da empresa e a interconexão mundial das WANs, formando a Internet, e com a expansão do modelo Cliente/Servidor em 2 ou mais camadas, a utilização dos chamados Bancos de Dados Relacionais cresceu exponencialmente. Hoje a grande maioria das novas aplicações  (para não dizermos a quase totalidade) é baseada neste tipo de Bancos de Dados, ou seja: Bancos de Dados Relacionais.

Neste capítulo falarei sobre os princípios básicos dos Bancos de Dados Relacionais, que é o modelo de Banco de Dados utilizado pelo Microsoft SQL Server 2005. Outros Bancos de Dados bastante conhecidos e que também utilizam este modelo:

• Microsoft Access – para aplicações de menor porte.
• Oracle.
• DB2 da IBM.
• Sybase.
• MySQL para Linux.

O modelo Relacional também possui suas limitações, porém é bastante adequado para a grande maioria das aplicações comerciais atualmente em uso ou sendo desenvolvidas. Algumas aplicações especiais que necessitam utilizar dados mais complexos, como por exemplo arquivos multimídia, dados geográficos, dados espaciais e séries temporais, podem se beneficiar mais das características dos chamados Bancos de Dados Orientados a Objetos. Este tipo de Banco de Dados ainda não é amplamente utilizado, a não ser em situações específicas.

Um exemplo de Banco de Dados Orientado a Objetos é o Jasmine da CA.

Estudaremos, ao longo deste capítulo, os princípios básicos dos Bancos de Dados Relacionais devido a sua grande aceitação e utilização. Caso você queira maiores detalhes sobre este tipo de Banco de Dados, existe uma farta Bibliografia, bem como inúmeros sites na Internet com informações sobre o assunto.

O Microsoft SQL Server utiliza uma série de comandos para realizar as diversas operações sobre os dados armazenados nos bancos de dados do SQL Server. São exemplos de operações realizadas sobre os dados:

• Selecionar um conjunto de registros com base em um ou mais critérios especificados.
• Ordenar um conjunto de registros com base em um ou mais campo de dados.
• Alterar informações no Banco de Dados.
• Excluir informações no Banco de Dados.
• Inserir informações no Banco de Dados.

Para realizar estas operações é utilizada uma linguagem conhecida com SQL – Structured Query Language. A linguagem SQL foi desenvolvida pela IBM, porém devido ao seu poder e facilidade de utilização, rapidamente tornou-se um padrão de mercado, sendo hoje utilizada pela maioria dos Bancos de Dados que seguem o modelo Relacional. No SQL Server 2005 a linguagem é chamada de T-SQL, sendo o “T” de Transact.

Pequenas diferenças podem existir entre os comandos SQL de diferentes Bancos de Dados como por exemplo o Microsoft SQL Server e o Oracle. Neste livro serão utilizados, evidentemente, os comandos e a sintaxe da linguagem T-SQL, a qual é utilizada pelo Microsoft SQL Server 2005.

Fundamentos em: Conceitos Básicos de Bancos de Dados Relacionais
Pré-Requisitos: Nenhum.

Metodologia: Apresentação e descrição dos elementos que fazem parte do modelo Relacional.

Técnica: Utilização de exemplos práticos para ilustrar a teoria apresentada.

Neste item apresentarei os principais conceitos sobre Bancos de Dados Relacionais. Estes conceitos são importantes (eu diria até “fundamentais”) para a correta utilização dos Bancos de Dados, bem como para o projeto e criação de bancos de dados. O SQL Server 2005 é um banco de dados que segue o modelo Relacional. Conhecer os fundamentos teóricos sobre bancos relacionais é indispensável. A teoria sobre o Modelo Relacional de Dados está para o SQL Server 2005, assim como o Cálculo e a Física estão para um Engenheiro (e sem muito bem deste aspecto, pois a minha formação é em Engenharia Elétrica).

Em muitas situações teremos que conectar nossas aplicações com Bancos de Dados já existentes, neste caso precisamos conhecer os conceitos aqui apresentados, para podermos utilizar o Banco de Dados de uma maneira correta e otimizada.

Em outras situações teremos que criar o Banco de Dados a ser utilizado pela aplicação que está sendo desenvolvida. Neste caso, os conceitos apresentados neste capítulo auxiliam no projeto e criação de um Banco de Dados melhor estruturado e otimizado, tanto em termos de espaço de armazenamento, quanto da qualidade, confiabilidade, segurança, desempenho e disponibilidade das informações nele contidas.

Apresentarei os seguintes tópicos teóricos, sobre o Modelo Relacional de Dados:

• Entidades e Atributos, os elementos básicos de um Banco de Dados.
• Chave Primária.
• Relacionamentos entre Entidades (Tabelas).
• Integridade Referencial.
• Normalização de Tabelas.
• Análise de um Banco de Dados relacional.

Novidades no desenvolvimento de aplicações

Toda a informação de um Banco de Dados Relacional é armazenada em Tabelas, as quais também são chamadas (o termo técnico) de Entidades. Por exemplo, poderíamos ter uma Tabela “Clientes”.

Para cada um dos Clientes poderíamos armazenar informações tais como número do CPF, código do Cliente, número do RG, nome completo, Endereço, Bairro, Cidade, Estado, CEP, etc.

Essas diversas características de cada Cliente são os “Atributos” do Cliente, muitas vezes chamados de campos da entidade Cliente, ou de maneira mais simples: “Os campos da tabela Clientes”.

O Conjunto de todos os Atributos de um cliente e os valores de cada atributo forma o Registro do Cliente. Com isso teremos a tabela constituída por um conjunto de Registros (uma linha completa com informações sobre o cliente) e cada Registro formado por um conjunto de Atributos (Nome, Endereço, etc).

Resumindo:

• Entidade ou Tabela -> Um conjunto de registros.
• Campos ou Atributos -> Características individuais de cada Entidade.

Considere o exemplo da Figura 1.1: temos uma tabela Clientes com os seus diversos Campos (Atributos).

Figura 1.1 A entidade (tabela) Clientes e seus diversos atributos (campos).

Neste exemplo, temos uma entidade Clientes e seus diversos atributos:

• Código do Cliente.
• Nome da Empresa.
• Nome do Contato.
• Cargo do Contato.
• Endereço.

Neste caso, os campos (Atributos) da tabela Clientes são: Código do cliente, Nome da empresa, Nome do contato, Cargo do contato, Endereço, etc.

Promoção: Livro Windows Server 2008 R2 Curso Completo, 1222 páginas. Tudo para você se tornar um administrador de redes altamente qualificado para o mercado de trabalho e levar a sua carreira para o próximo nível!

Em cada linha temos um conjunto de atributos e seus valores. Cada linha forma um Registro que identifica um Cliente. Cada coluna é um Atributo da tabela Clientes.

Considere o exemplo da Figura 1.2, onde temos a tabela Clientes e os dados para os primeiros registros sendo exibidos:

Figura 1.2 Os primeiros registros da tabela Clientes, sendo exibidos.

Um dos grandes desafios em se projetar um Banco de Dados com sucesso é a correta determinação das entidades que existirão no Banco de Dados (as tabelas que farão parte do banco de dados, de tal maneira que os requisitos do banco de dados sejam atendidos), bem como dos atributos de cada entidade (os campos que existirão em cada tabela). Mais adiante veremos algumas dicas e técnicas para determinar as tabelas necessárias, bem como os campos necessários em cada tabela.

É importante lembrar que o que determina quais as tabelas e campos em cada tabela, serão necessários é o escopo e os objetivos do problema que está sendo abordado. Por exemplo, se estamos desenvolvendo um sistema para acompanhamento do desempenho individual de cada funcionário, com certeza não teremos necessidade de uma tabela de Clientes (permitam-me o exagero, para poder ilustrar bem a importância de manter o objetivo do banco de dados, sempre em mente). Por outro lado, se o desempenho de cada funcionário a ser acompanhado estiver ligado ao número de clientes atendidos pelo funcionário ou ao volume de vendas para cada cliente, a tabela Clientes passa a ter importância para o problema em questão.

Com isso podemos dizer que o que determina as tabelas e campos necessários é o problema real que o sistema a ser desenvolvido deverá solucionar.

Outro fato importante, e que iremos repetir ao longo deste capítulo, é que cada tabela deve conter dados de um determinado assunto. Não devemos misturar dados de diversos assuntos em uma mesma tabela. A regra número 1, do projeto de banco de dados é: “Assuntos diferentes em tabelas diferentes”. Ou de outra maneira: “Não se misturam campos de dois ou mais assuntos, na mesma tabela”.

Observe o exemplo da Tabela 1.1.

Tabela 1.1 Clientes e seus pedidos.

Observe que, nesta tabela, cometemos, propositalmente, o erro de “misturar” dois assuntos:

• Dados sobre os “Clientes”
• Dados sobre os “Pedidos dos Clientes”

Quando este tipo de erro é cometido, temos uma série de problemas que irão refletir em todo o sistema que está sendo desenvolvido. Dentre os principais problemas podemos citar:

• Informação repetida: Observe que para cada pedido de um determinado cliente, precisamos informar novamente os campos: Nome, Endereço e Fone do cliente.
• Informação inconsistente: Observe que por um erro de digitação, o nome do cliente José da Silva está digitado incorretamente (sem o acento) no segundo registro, e o seu endereço está digitado incorretamente, no terceiro registro. Isso causa inconsistências no Banco de Dados, gerando resultados errados quando forem feitas pesquisas pelo nome do cliente ou pelo endereço ou quando forem gerados relatórios com totalizações por cliente, tais como o total anual de vendas para cada cliente ou a média mensal de vendas, por cliente.

Para evitar este tipo de problema, deveríamos separar as informações dos Clientes e dos seus Pedidos em duas tabelas distintas. Veremos como fazer isso mais adiante, neste capítulo. Por enquanto, mantenha sempre em menta a regra número um do projeto de bancos de dados relacionais: “Assuntos diferentes em tabelas diferentes”. Ou de outra maneira: “Não se misturam campos de dois ou mais assuntos, na mesma tabela”.

O Conceito de Chave Primária

O conceito de Chave Primária é fundamental para entender o funcionamento de um Banco de Dados. Vamos procurar entender o que significa um campo ser a Chave Primária de uma tabela.

Ao definirmos um campo como sendo uma Chave Primária, estamos informando ao Banco de Dados que não podem existir dois registros com o mesmo valor na Chave Primária, ou seja, os valores no campo Chave Primária precisam ser únicos.

Por exemplo, se defino um campo “Número da Identidade” da tabela Clientes como sendo uma Chave Primária, estou dizendo ao Banco de Dados que não podem existir dois clientes com o mesmo valor no campo “Número da Identidade”. Na prática, estou garantindo que não podem ser cadastrados dois clientes com o mesmo número de identidade.

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.

Outro exemplo de campo que ilustra bem o conceito de chave primária, é um campo Número do pedido, na tabela Pedidos. Este campo deve ser único, o que na prática significa que não podem ser cadastrados dois Pedidos, com o mesmo valor no campo Número do Pedido. Nos veremos a parte prática, sobre como Definir um campo para ser do tipo Chave primária, no Capítulo 4.

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.

Alguns exemplos de campos que podem ser definidos como “Chave Primária” em suas respectivas tabelas:

• O campo Número do Pedido, em um tabela de Pedidos.
• O campo Número da Identidade ou CPF em uma tabela de Clientes Pessoa Física.
• O campo Número do CNPJ em uma tabela de Clientes Pessoa Jurídica.
• O campo Código do Produto em uma tabela de Produtos.
• O campo ISBN em uma tabela de Livros.

Na Figura 1.3, vemos um exemplo da tabela Clientes onde o campo Código do Cliente é definido como uma Chave Primária. Observe que não existem dois clientes com o mesmo código.

Figura 1.3 O campo Código do Cliente é uma Chave Primária.

Um detalhe importante é que a Chave Primária pode ser formada pela combinação de mais do que um campo. Podem existir casos (embora não sejam muito comuns) em que um único campo não é capaz de atuar como Chave Primária, pelo fato de apresentar valores repetidos. Nestes casos, podemos definir uma combinação de dois ou mais campos para ser a nossa Chave Primária. Além disso, uma tabela somente pode ter uma Chave Primária, seja ela simples ou composta. Outro detalhe importante é que nem toda as tabelas tem que ter, obrigatoriamente, uma chave primária (seja simples ou composta). Dependendo de cada projeto, pode haver situações onde uma tabela não terá nenhum campo (ou combinação de campos), definido como do tipo Chave primária.

Um cuidado especial que devemos ter é quanto ao desempenho das consultas em tabelas que possuem Chave Primária composta por mais do que um campo. Em muitas situações, o desempenho das consultas é inversamente proporcional ao tamanho da Chave Primária. Com isso quanto maior o tamanho da Chave Primária, menor o desempenho das consultas, isto é, mais demoradas se tornam as consultas. Na prática, dificilmente teremos uma Chave Primária composta por mais do que três ou quatro campos. Se você se deparar com uma situação em que precise uma Chave primária composta de mais de quatro ou mais campos, revise o projeto do Banco de Dados, por que devem existir alguns problemas.