SGDB - Arquitetura

Arquitetura de um SGBD 

Estrutura 

Podemos dizer que o Banco de Dados tem um Nível Interno, onde é descrita a estrutura de armazenamento físico dos dados, um Nível Intermediário, onde temos a descrição lógica dos dados e um Nível Externo onde são descritas as visões para grupos de usuários. 

Não podemos deixar de lembrar ainda que o Banco de Dados garante a Independência Lógica e Física dos Dados, portanto podemos alterar o esquema conceitual dos dados, sem alterar as visões dos usuários ou mesmo alterar o esquema interno, sem contudo alterar seu esquema conceitual. 

Modelos de Dados 

O Modelo de Dados é basicamente um conjunto de conceitos utilizados para descrever um Banco de Dados. 

Não existe uma única forma de representação deste modelo, porém qualquer forma que permita a correta compreensão das estruturas de dados compreendidas no Banco de Dados, pode ser considerada adequada. 

Modelo Orientado ao Registro: 

São modelos que representam esquematicamente as estruturas das tabelas de forma bastante próxima a existente fisicamente. Basicamente são apresentados os registros de cada tabela (inclusive seus campos) e seus relacionamentos elementares. 

O Modelo Relacional, o Modelo de Rede e o Hierárquico são exemplos deste tipo de representação. 

Modelo Semântico: 

São modelos onde existe uma representação explícita das entidades e relacionamentos. 

O Modelo Entidade-Relacionamento e o Funcional, são exemplos deste tipo de abordagem. 

Modelo Orientado ao Objeto: 

São modelos que procuram representar as informações através dos concietos típicos da Programação Orientada ao Objeto, utilizando o conceito de Classes que irão conter os objetos. 

Citamos os Modelos O2 e o de Representação de Objetos como exemplos típicos desta abordagem. 

O conceito de instância, sempre muito presente, poderia ser definido como sendo o conjunto de dados que definem claramente um Banco de Dados em determinado instante. 

Devemos entender então o Banco de Dados como sendo não apenas um conjunto de dados digitados, mas também todo o esquema e regras armazenada e controladas pelo SGBD. 

Em outras palavras, podemos dizer que os SGBD, vieram para eliminar todo o trabalho que anteriormente um programador de aplicação realizava controlando o acesso, integridade e redundância dos dados.

SGDB - Características Gerais

Características Gerais de um SGBD 

Os SGBD tem sete características operacionais elementares sempre observadas, que passaremos a listar: 

Característica 1: Controle de Redundâncias

- A redundância consiste no armazenamento de uma mesma informação em locais diferentes, provocando inconsistências. Em um Banco de Dados as informações só se encontram armazenadas em um único local, não existindo duplicação descontrolada dos dados. Quando existem replicações dos dados, estas são decorrentes do processo de armazenagem típica do ambiente Cliente-Servidor, totalmente sob controle do Banco de Dados. 

Característica 2: Compartilhamento dos Dados

- O SGBD deve incluir software de controle de concorrência ao acesso dos dados, garantindo em qualquer tipo de situação a escrita/leitura de dados sem erros. 

Característica 3: Controle de Acesso

- O SGDB deve dispor de recursos que possibilitem selecionar a autoridade de cada usuário. Assim um usuário poderá realizar qualquer tipo de acesso, outros poderão ler alguns dados e atualizar outros e outros ainda poderão somente acessar um conjunto restrito de dados para escrita e leitura. 

Característica 4: Interfaceamento

- Um Banco de Dados deverá disponibilizar formas de acesso gráfico, em linguagem natural, em SQL ou ainda via menus de acesso, não sendo uma "caixa-preta" somente sendo passível de ser acessada por aplicações. 

Característica 5: Esquematização

- Um Banco de Dados deverá fornecer mecanismos que possibilitem a compreensão do relacionamento existentes entre as tabelas e de sua eventual manutenção. 

Característica 6: Controle de Integridade

-Um Banco de Dados deverá impedir que aplicações ou acessos pelas interfaces possam comprometer a integridade dos dados. 

Característica 7: Backups

- O SGBD deverá apresentar facilidade para recuperar falhas de hardware e software, através da existência de arquivos de "pré-imagem" ou de outros recursos automáticos, exigindo minimamente a intervenção de pessoal técnico. 

Existe a possibilidade de encontramos Bancos de Dados que não satisfaçam completamente todas as características acima, o que não o inválida como Banco de Dados. 

Na prática podemos encontrar situações onde a primeira característica não seja importante, pois podemos ter o Banco de Dados baseado totalmente em um único servidor, e as redundâncias podem ser aceitas em algumas situações sob controle da aplicação (algo não muito recomendado, mas passível de aceitação, em situações onde a existência do nome do cliente em um arquivo contendo duplicatas emitidas, possibilita o acesso a apenas uma tabela sem relacionamentos, e sabe-se de antemão que uma duplicata depois de emitida, não pode ter seu cliente alterado). 

A segunda característica (Compartilhamento dos Dados) pode ser desconsiderada principalmente em ambiente de desenvolvimento, ou ainda em aplicações remotas. 

O Controle de Acesso pode ser descartado em pequenas empresas, sendo que o aplicativo em questão, mais o software de rede, podem facilmente se incumbir desta característica, no caso de pequenas empresas, com reduzido número de pessoas na área operacional. 

O Interfaceamento e a Esquematização, são características sempre disponíveis, o que varia neste caso é qualidade destes componentes, que vai desde o sofrível até o estado da arte. 

É muito conveniente que esta característica seja muito boa em um Banco de Dados, onde estiverem em atuação mais de um Administrador de Banco de Dados e tivermos um número relativamente alto de sistemas desenvolvidos ou em desenvolvimento neste ambiente. 

De fato, quanto maior o número de pessoas envolvidas no desenvolvimento de aplicações e gerenciamento do Banco de Dados, mais importante tornam-se estas duas características, pois cada novo sistema desenvolvido precisará sempre estar adequado ao Banco de Dados da Empresa e aderente aos padrões de acesso utilizados nos sistemas concorrentes. 

O Controle de Integridade, é outra característica sempre presente nos Bancos de Dados, mas existem diferenças quando da implementação desta característica. 

Assim, é comum encontrarmos Bancos de Dados que suportam determinado acesso, enquanto outros não dispõe de recurso equivalente. 

O Backup em tempo de execução, é outra característica sempre disponível, porém temos aplicações que invariavelmente são comprometidas por falhas de hardware, e outras, que o mesmo tipo de falha não causa perda alguma de dados ou de integridade.

Novamente, cada Banco de Dados tem esta característica melhor ou pior implementada, cabendo ao Administrador de Banco de Dados escolher aquele que lhe oferecer mais segurança. 

Devemos ressaltar ainda, que podemos ter um Banco de Dados Modelo A, que respeite integralmente as regras básicas e disponha de todas as características apresentadas, enquanto um Modelo B que apesar de respeitar as regras básicas, não suporte uma ou outra característica desejável, mas tenha um desempenho excelente, enquanto o Modelo A seja apenas razoável no quesito desempenho, nos levará seguramente a escolher o Modelo B como sendo o ganhador para nossa instalação! 

Isto ocorre pois, na prática, todo usuário deseja um tempo de resposta muito pequeno. 

O chamado “prazo de entrega” muito comum em Bancos de Dados operando nos limites de sua capacidade, ou nos casos onde o hardware está muito desatualizado, é fonte de inúmeros problemas para o pessoal de informática. 

Neste caso é melhor abrirmos mão de uma Interface Amigável, de um Gerenciamento Automático de Backups ou ainda de outras características que não julgarmos fundamentais, para nos livrarmos do problema típico de ambiente extremamente comprometido, por má performance do Banco de Dados. 

A escolha do Banco de Dados da empresa, portanto é uma decisão muito delicada, na medida em que está irá acarretar troca de aplicativos e troca de hardware. 

Os investimentos diretamente aplicados no Banco de Dados, costumam ser infinitamente menores do que aqueles a serem aplicados na empresa, visando sua perfeita adequação ao novo SGBD. 

Esta decisão, sempre que possível, deve ser tomada por especialistas em Banco de Dados, com profundos conhecimentos de Análise de Sistemas, de Banco de Dados e de Software de Gerenciamento de Bases de Dados, de forma a evitar que a empresa escolha um Banco de Dados inadequado aos seus propósitos, e que pouco tempo depois, seja obrigada a perder todos investimento realizado em Software e Hardware.

SGDB - Sistema de Gerenciamento de Banco de Dados

Um SGBD - Sistema de Gerenciamento de Banco de Dados é uma coleção de programas que permitem ao usuário definir, construir e manipular Bases de Dados para as mais diversas finalidades.

 Um conceito que deverá ficar bastante claro inicialmente é o que envolve a separação clara entre os Gerenciadores de Base de Dados dos Gerenciadores de Arquivo. 

Sistemas baseados em "Banco de Dados" baseados em Btrieve e dBase (Fox e Clipper), podem no máximo simular as características típicas de um ambiente de Banco de Dados. 

A linguagens Delphi (utiliza opcionalmente o padrão dBase) e o Visual Basic (que utiliza o Access), recomendam a utilização de Banco de Dados reais, porém utilizam àqueles "Banco de Dados" que possuem algumas características de Bancos de Dados, mas possuem características típicas de Gerenciadores de Arquivo.

Vamos definir algumas regras básicas e claras para um sistema de manipulação de dados ser considerado um SGBD. 

Fica implícito que se ao menos uma das características abaixo não estiver presente no nosso "candidato" a SGBD, este poderá ser um Gerenciador de Arquivo de altíssima qualidade, "quase" um SGBD, mas não um SGBD. 

Regra 1: Auto-Contenção

- Um SGBD não contém apenas os dados em si, mas armazena completamente toda a descrição dos dados, seus relacionamentos e formas de acesso. Normalmente esta regra é chamada de Meta-Base de Dados. Em um GA, em algum momento ao menos, os programas aplicativos declaram estruturas (algo que ocorre tipicamente em C, COBOL e BASIC), ou geram os relacionamentos entre os arquivos (típicos do ambiente xBase). Por exemplo, quando você é obrigado a definir a forma do registro em seu programa, você não está lidando com um SGBD. 

Regra 2: Independência dos Dados

- Quando as aplicações estiverem realmente imunes a mudanças na estrutura de armazenamento ou na estratégia de acesso aos dados, podemos dizer que esta regra foi atingida. Portanto, nenhuma definição dos dados deverá estar contida nos programas da aplicação. Quando você resolve criar uma nova forma de acesso, um novo índice, se precisar alterar o código de seu aplicativo, você não está lidando com um SGBD.

 Regra 3:  Abstração dos Dados

- Em um SGBD real é fornecida ao usuário somente uma representação conceitual dos dados, o que não inclui maiores detalhes sobre sua forma de armazenamento real. O chamado Modelo de Dados é um tipo de abstração utilizada para fornecer esta representação conceitual. Neste modelo, um esquema das tabelas, seus relacionamentos e suas chaves de acesso são exibidas ao usuário, porém nada é afirmado sobre a criação dos índices, ou como serão mantidos, ou qual a relação existente entre as tabelas que deverá ser mantida íntegra. Assim se você desejar inserir um pedido em um cliente inexistente e esta entrada não for automaticamente rejeitada, você não está lidando com um SGBD.

Regra 4: Visões

- Um SGBD deve permitir que cada usuário visualize os dados de forma diferente daquela existente previamente no Banco de Dados. Uma visão consiste de um subconjunto de dados do Banco de Dados, necessariamente derivados dos existentes no Banco de Dados, porém estes não deverão estar explicitamente armazenados. Portanto, toda vez que você é obrigado a replicar uma estrutura, para fins de acesso de forma diferenciada por outros aplicativos, você não está lidando com um SGBD. 

Regra 5: Transações

- Um SGBD deve gerenciar completamente a integridade referencial definida em seu esquema, sem precisar em tempo algum, do auxílio do programa aplicativo. Desta forma exige-se que o banco de dados tenha ao menos uma instrução que permita a gravação de uma série modificações simultâneas e uma instrução capaz de cancelar um série modificações. Por exemplo, imaginemos que estejamos cadastrando um pedido para um cliente, que este deseje reservar 5 itens de nosso estoque, que estão disponíveis e portanto são reservados, porém existe um bloqueio financeiro (duplicatas em atraso) que impede a venda. A transação deverá ser desfeita com apenas uma instrução ao Banco de Dados, sem qualquer modificações suplementares nos dados. Caso você se obrigue a corrigir as reservas, através de acessos complentares, você não está lidando com um SGBD. 

Regra 6: Acesso Automático

- Em um Gerenciador de Arquivo uma situação típica é o chamado Dead-Lock, o abraço mortal. Esta situação indesejável pode ocorrer toda vez que um usuário travou um registro em uma tabela e seu próximo passo será travar um registro em uma tabela relacionada à primeira, porém se este registro estiver previamente travado por outro usuário, o primeiro usuário ficará paralisado, pois, estará esperando o segundo usuário liberar o registro em uso, para que então possa travá-lo e prosseguir sua tarefa. Se por hipótese o segundo usuário necessitar travar o registro travado pelo primeiro usuário, afirmamos que ocorreu um abraço mortal, pois cada usuário travou um registro e precisa travar um outro, justamente o registro anteriormente travado pelo outro! Imaginemos um caso onde o responsável pelos pedidos acabou de travar o Registro Item de Pedido, e, necessita travar um registro no Cadastro de Produtos, para indicar uma nova reserva. Se concomitantemente estiver sendo realizada uma tarefa de atualização de pendências na Tabela de Itens, e para tanto, previamente este segundo usuário travou a Tabela de Produtos, temos a ocorrência do abraço mortal. Se a responsabilidade de evitar esta ocorrência for responsabilidade da aplicação, você não está lidando com um SGBD. 

Conclusão: 

Um SGBD deve obedecer INTEGRALMENTE as seis regras acima. Em caso contrário estaremos diante de um GA ou de um "quase" SGBD. 

Considerações Finais 

Atualmente, existe uma tendência de mercado em se dizer que qualquer problema será resolvido, caso a empresa adquira um Banco de Dados. 

Naturalmente, em um ambiente com acesso constante ao Banco de Dados (acesso concorrente, obviamente), onde a segurança seja de vital importância e que o desempenho da aplicação escrita estiver comprometendo a empresa, considerando-se logicamente uma aplicação bem escrita, sem dúvida a aquisição de um Banco de Dados poderá ser o primeiro passo na solução do problema. 

Analogamente ao que ocorreu com o aparecimento das primeiras linguagens de programação voltadas ao Windows, onde estas foram apresentadas como capazes de alavancar os negócios da empresa, e no geral causaram mais frustração do que solução, a aquisição do Banco de Dados, pode gerar o mesmo tipo de problema. É fundamental que a empresa candidata a utilizar um Banco de Dados, normatize-se totalmente, pois soluções “quebra- galho”, típicas do ambiente que dispõe de um Gerenciador de Arquivo, tendem a ser impossíveis em um ambiente estruturado sobre o Banco de Dados. 

Portanto, sob pena de se realizar um grande investimento, e não se colher fruto algum, é muito conveniente, que a empresa antes de adquirir um Banco de Dados, passe por um processo de adaptação, preferencialmente contando com pessoal especializado, geralmente consultores, que não tenham qualquer ligação com fabricantes de Bancos de Dados.

Banco de Dados - Conceito Básico

Todos nós sabemos que existem gigantescas bases de dados gerenciando nossas vidas. 

De fato sabemos que nossa conta bancária faz parte de uma coleção imensa de contas bancárias dentro do banco de dados do nosso banco. 

Nosso Título Eleitoral ou nosso Cadastro de Pessoa Física, estão armazenados dentro da base de dados gigantesca do Governo Federal. 

Sabemos também que quando sacamos dinheiro no caixa eletrônico de nosso banco, nosso saldo e as movimentações existentes em nossa conta bancária já estão à nossa disposição. 

Nestas situações sabemos que existe uma necessidade em se realizar o armazenamento de uma série de informações que não se encontram efetivamente isoladas umas das outras.

Existe uma ampla gama de dados que se referem a relacionamentos existentes entre as informações a serem manipuladas. 

Estes Bancos de Dados, além de manterem todo este volume de dados organizado, também devem permitir atualizações, inclusões e exclusões do volume de dados, sem nunca perder a consistência. 

Não podemos esquecer que na maioria das vezes estaremos lidando com acessos concorrentes a várias tabelas de nosso banco de dados, algumas vezes com mais de um acesso ao mesmo registro de uma mesma tabela.

Um Banco de Dados é antes de mais nada uma coleção logicamente coerente de dados com determinada significação,  em outras palavras um arquivo contendo uma série de dados de um cliente, um arquivo com dados aleatoriamente gerados, que tem uma relação definida entre ambos.

Um Banco de Dados contém os dados dispostos numa ordem pré-determinada em função de um projeto de sistema, sempre para um propósito muito bem definido. 

Um Banco de Dados representará sempre aspectos do Mundo Real.

Assim sendo um Banco de Dados, é uma fonte de onde poderemos extrair uma vasta gama de informações derivadas, que possui um nível de interação com eventos como o mundo real que o representa. 

A forma mais comum de interação do Usuário com o Banco de Dados, dá-se através de sistemas específicos que por sua vez acessam o volume de informações, geralmente através da linguagem SQL. 

Os Administradores de Banco de Dados (DBA) são os profissionais responsáveis pelo controle ao acesso aos dados e pela coordenação da utilização do Banco de Dados. 

Já os projetistas de Banco de Dados (DBP) são os analistas que identificam os dados a serem armazenados em um Banco de Dados e definem a forma como estes serão representados. 

Os Analistas e Programadores de Desenvolvimento, criam sistemas que acessam os dados da forma necessária ao Usuário Final, que é aquele que interage diretamente com o Banco de Dados. 


BANCOS DE DADOS - Introdução 

Bancos de dados são ferramentas que permitem o armazenamento e manipulação de dados em tabelas (conjuntos de informações com estrutura regular). 

Exemplos de bancos de dados: Sistemas de Processamento de arquivos (fichas impressas, documentos do Word), tabelas SQL armazenadas em um servidor. 

1. TIPOS DE BANCOS DE DADOS 

• Banco de Dados Não Relacionais 
– Modo regular, os arquivos são escritos de forma sequencial, o acesso geralmente é mais lento em comparação ao banco de dados Relacional. 

• Banco de Dados Relacional 
– Os dados são organizados em tabelas permitindo o relacionamento entre as mesmas. Uma relação trata-se de associação entre varias entidades. 

Exemplo: podemos cruzar os dados entre alunos por curso ou turma ao relacionarmos as Tabela Cursos e Tabela Alunos. 

Em comparação ao Modelo Não Relacional, podemos citar como principais vantagens: padrão adotado mundialmente, maior velocidade de acesso aos dados e menor espaço de armazenamento. 

MER (Modelo entidade/relacionamento) 
Tabelas Forma de organizar os dados em linhas e colunas. 

Colunas 
Campos que formam um registro 

O Conjunto formado pelo encontro de uma linha/coluna é denominado tupla. 


1.1 Estruturas existentes em bancos de dados 

• Visões => Consultas SQL previamente programadas disponíveis para rápido acesso, não sevem para armazenar dados, sua função é armazenar critérios de seleção de dados, permitem dados atualizados sempre que as tabelas em questão sofrem alteração. 

• Índices => Estruturas que gerenciam a ordenação de valores dos campos informados para melhorar a performance de processamento do banco de dados sobre estes campos e seus respectivos registros.

2. DATABASE MANAGEMENT SYSTEM (SISTEMA GERENCIADOR DE BANCO DE DADOS) 

O sistema de gerenciamento de banco de dados não deve ser confundido com o próprio banco de dados; a função de gravar uma informação, alterá-la ou até mesmo recuperá-la é do banco de dados, cabe ao sistema de gerenciamento permitir ou não o acesso ao banco de dados. 

O sistema de gerenciamento pode não trazer grandes benefícios a bancos de dados pequenos, simples e de pouco acesso, ele é vital para bancos de dados com grande volume de informações e com acessos simultâneos por vários usuários, o controlador de acesso gerencia todas estas operações, evitando assim, inconsistência nas informações. 

Como podemos perceber, o sistema de gerenciamento é um complemento ao banco de dados, interligando as requisições de conexão dos usuários com o banco de dados. 

As requisições podem ser enviadas por usuários específicos, ou através de sistemas online. 


SERVIDOR DE BANCOS DE DADOS 

Um servidor de Bancos de Dados pode armazenar e gerenciar um ou mais banco de dados, um banco de dados por sua vez, pode possuir uma ou mais tabelas. 

SQL - Filtros de Seleção

7. SQL - FILTROS DE SELEÇÃO 

Os comandos abordados até então, são utilizados em relação à estrutura das tabelas em sua totalidade. 

Para busca e seleção de áreas específicas das tabelas devemos acrescentar o complemento WERE em alguns dos comandos abordados anteriormente para que a operação somente seja realizada nos registros que atenderem as condições especificadas, neste sentido, faz-se necessário a abordagem do conceito de operadores. 

OPERADORES RELACIONAIS: 

• Igual (=), Diferente (!=) 

• Maior (>), Maior ou igual (>=) 

• Menor (<), Menor ou igual (<=) 

• Nulo (IS NULL), ou não-nulo (IS NOT NULL) 

• Entre intervalo (BETWEEN) 

• Valor parcial (like) 

OPERADORES LÓGICOS: 

• AND 

• OR 

• NOT 

Para exemplo de aplicação, adotemos duas situações distintas: 

1º Buscar no banco de dados todas as informações referentes a uma determinada pessoa através do nº de CPF; 

2º Pesquisar quantas pessoas com idade superior a vinte anos estão cadastradas no sistema 

SINTAXE: 

SELECT Campos FROM Tabela WHERE Condição

SELECT * FROM Pessoas WHERE CPF = '111.111.111-11'

SELECT NOME FROM PESSOAS WHERE IDADE > 20

Para atualização de campos específicos, podemos utilizar o comando UPDATE seguido do complemento WERE, exemplos a seguir: 

Se fosse necessário atualizar o nome do titular do CPF 222.222.222-22 para Fábio, usaríamos a sintaxe abaixo, o mesmo se aplica a mudança de idade para 25 anos do usuário Mário no segundo exemplo 

UPDATE Tabela SET Campo = Valor WHERE Condição

UPDATE PESSOAS SET NOME = 'Fabio' WHERE  CPF = '222.222.222-22'

UPDATE PESSOAS SET IDADE = 25 WHERE NOME = 'Mario'

Para deletar campos específicos sem excluir a tabela inteira, podemos usar o comando DELETE precedido do complemento WERE.

DELETE FROM Tabela WHERE Condição

DELETE FROM PESSOAS WHERE CPF = '222.222.222-22'

DELETE FROM PESSOAS WHERE NOME = 'Mario'

8. RELACIONAMENTOS NO SQL 

Para relacionarmos tabelas, utilizamos o parâmetro JOIN, sua sintaxe é:

SELECT Nome dos Campos FROM Nome-da-Tabela1 

JOIN Nome-da-Tabela2  ON Nome-da-Tabela3 

SELECT Campos FROM T1 JOIN T2 ON T1.FK=T2.PK

Condição: Relacionar chave estrangeira da Tabela1 com chave primária da Tabela2. Isto não é uma regra, aplica-se ao exemplo.

Se os campos em comum entre as tabelas possuírem o mesmo nome, podemos usar esta sintaxe:  

SELECT Nome dos Campos FROM T1 JOIN T2 USING Chave

Observação: onde Chave é o nome da chave da tabela.

INNER JOIN

SELECT * FROM Alunos JOIN Cursos ON Alunos.CPF = Cursos.CPF

SQL - Indice, Chave e Relacionamento da Tabela

SQL - Indice da Tabela

Criar Índice = CREATE INDEX Nome ON

Alterar Índice = ALTER INDEX TabelaEColuna

Exclusão Indice = DROP INDEX Nome Propriedade Nome

OBS: O comando DROP INDEX remove o índice, mas não remove os dados no campo em questão.

4. NORMALIZAÇÃO DE DADOS 
(RELACIONAMENTOS E CHAVES) 

Normalização de dados é um termo que está intimamente ligado a Relacionamentos, que por sua vez é ligado a chaves. 

• Relacionamentos = São ligações entre tabelas onde existes um ou mais campos em comum entre as tabelas relacionadas conhecidos como campos chaves. 

• Campos Chaves = São valores que apresentam “referência” de uma tabela em outra (chave de identificação). As tabelas dos bancos de dados são compostas por linhas e colunas, sendo que algumas das colunas podem apresentar características especificas de acordo com a forma com que a tabela foi construída ou da aplicação que será construída sob o banco de dados, geralmente algumas colunas são criadas especificamente para gerar relacionamentos entre duas ou mais tabelas, tais colunas são denominadas “colunas chaves”. 

4.1 Tipos de Chaves 

1. Chaves Primárias (Primary Key – PK), os valores são únicos (não se repetem nos registros da tabela). Esta característica também é denominada de identificador único. 

2. Chave Composta é formada pela composição de duas ou mais colunas para gerar um identificador único, podendo significar que nenhum campo isoladamente possa se tornar a chave primária, sendo necessário dois ou mais campos para gerar uma combinação única de cada registro. 

 Neste exemplo o nº de CPF é utilizado como chave primária, não pode haver duas pessoas com o mesmo número de CPF. Em uma tabela de cadastro de alunos, o mesmo se aplica ao número de RA (Registro de Aluno) 

Usando a mesma tabela do exemplo anterior, neste caso, se o nº de CPF dependesse de cada estado, a identificação seria composta pela chave estrangeira. 

3. Chave Estrangeira (Foreign Key – FK), modelo adotado onde a coluna armazena a chave primária de outra tabela (referência), não sendo necessário preencher todas as informações que são “buscadas” através do código ou informação atrelada. 

Neste exemplo, a tela de cadastro utiliza uma tabela que armazena os dados utilizando o número de matrícula como uma chave estrangeira, sendo que, este mesmo campo é a chave primária no cadastro de funcionários (RH) 

4.2 Tipos de Relacionamentos 

a) Relacionamento 1 para 1 (1:1), para cada registro na primeira tabela existe no máximo um correspondente na segunda tabela, e vice-versa. 

Neste exemplo, existe um único correspondente na tabela 2 para a tabela 1 em virtude de cada pessoa possuir um número específico de CPF.

b) Relacionamento 1 para muitos (1:*), neste tipo de relacionamento, para cada registro na primeira tabela podem haver dois ou mais correspondentes na segunda tabela, mas para cada registro na segunda tabela deve haver apenas um correspondente na primeira tabela. Neste exemplo, um indivíduo pode ser proprietário de mais de um automóvel, sendo possível também que outra pessoa não possua nenhum automóvel registrado em seu número de CPF.

c) Relacionamento muitos para muitos (*:*), para cada registro da primeira tabela podem existir um ou mais correspondentes na segunda tabela, e vice-versa. Neste exemplo, uma pessoa pode exercer mais de uma profissão, assim como, uma determinada profissão possa ser exercida por mais de uma pessoa.

A Linguagem SQL tem como grandes virtudes sua capacidade de gerenciar índices, sem a necessidade de controle individualizado de índice corrente, algo muito comum nas linguagens de manipulação de dados do tipo registro a registro. 

SQL - Tipos de Dados

4.3 Tipos de Dados SQL 

Abaixo segue uma relação dos tipos de dados básicos do SQL Server, sendo que os tipos que estiverem marcados com * somente funcionam a partir do SQL Server 2000 

• TINYINT: 
Valores numéricos inteiros variando de 0 até 256 

• SMALLINT: 
Valores numéricos inteiros variando de –32.768 até 32.767 

• INT: 
Valores numéricos inteiros variando de -2.147.483.648 até 2.147.483.647 

• BIGINT:
Valores numéricos inteiros variando de -92.23.372.036.854.775.808 até 9.223.372.036.854.775.807 

• BIT: 
Somente pode assumir os valores 0 ou 1. Utilizado para armazenar valores lógicos. 

• DECIMAL(I,D) e NUMERIC(I,D): Armazenam valores numéricos inteiros com casas decimais utilizando precisão. onde:

I - deve ser substituído pela quantidade de dígitos total do número 

D - deve ser substituído pela quantidade de dígitos da parte decimal (após a vírgula). 

DECIMAL e NUMERIC possuem a mesma funcionalidade, porém DECIMAL faz parte do padrão ANSI e NUMERIC é mantido por compatibilidade. 

Por exemplo, DECIMAL(8,2) armazena valores numéricos decimais variando de – 999999,99 até 999999,99 

* Lembrando sempre que o SQL Server internamente armazena o separador decimal como ponto (.) e o separador de milhar como vírgula (,). Essas configurações INDEPENDEM de como o Windows está configurado no painel de controle e para DECIMAL E NUMERIC, somente o separador decimal (.) é armazenado. 

• SMALLMONEY: 
Valores numéricos decimais variando de -214.748,3648 até 214.748,3647 

• MONEY:
Valores numéricos decimais variando de -922.337.203.685.477,5808  até  922.337.203.685.477,5807 

• REAL: 
Valores numéricos aproximados com precisão de ponto flutuante, indo de -3.40E + 38 até 3.40E + 38 

• FLOAT: 
Valores numéricos aproximados com precisão de ponto flutuante, indo de -1.79E + 308  até  1.79E + 308 

• SMALLDATETIME: 
Armazena hora e data variando de 1 de janeiro de 1900 até 6 de junho de 2079. A precisão de hora é armazenada até os segundos. 

• DATETIME: 
Armazena hora e data variando de 1 de janeiro de 1753 até 31 de Dezembro de 9999. A precisão de hora é armazenada até os centésimos de segundos. 

• CHAR(N): 
Armazena N caracteres fixos (até 8.000) no formato não Unicode. Se a quantidade de caracteres armazenada no campo for menor que o tamanho total especificado em N, o resto do campo é preenchido com espaços em branco.

• VARCHAR(N): 
Armazena N caracteres (até 8.000) no formato não Unicode. Se a quantidade de caracteres armazenada no campo for menor que o tamanho total especificado em N, o resto do campo não é preenchido. 

• TEXT: 
Armazena caracteres (até 2.147.483.647) no formato não Unicode. Se a quantidade de caracteres armazenada no campo for menor que 2.147.483.647, o resto do campo não é preenchido. Procure não utilizar este tipo de dado diretamente, pois existem funções específicas para trabalhar com este tipo de dado. 

• NCHAR(N): 
Armazena N caracteres fixos (até 4.000) no formato Unicode. Se a quantidade de caracteres armazenada no campo for menor que o tamanho total especificado em N, o resto do campo é preenchido com espaços em branco. 

• NVARCHAR(N): 
Armazena N caracteres (até 4.000) no formato Unicode. Se a quantidade de caracteres armazenada no campo for menor que o tamanho total especificado em N, o resto do campo não é preenchido. 

• NTEXT: 
Armazena caracteres (até 1.073.741.823) no formato Unicode. Se a quantidade de caracteres armazenada no campo for menor que 1.073.741.823, o resto do campo não é preenchido. Procure não utilizar este tipo de dado diretamente, pois existem funções específicas para trabalhar com este tipo de dado. 

SQL - Agrupamento GROUP BY

GROUP BY - Agrupamentos 

As funções de grupo operam sobre grupos de tuplas(linhas). Retornam resultados baseados em grupos de tuplas em vez de resultados de funções por tupla individual. 

A claúsula "group by" do comando "select" é utilizada para dividir tuplas em grupos menores. 

A cláusula "GROUP BY" pode ser usada para dividir as tuplas de uma tabela em grupos menores. As funções de grupo devolvem uma informação sumarizada para cada grupo. 

16) Apresente a média de salário pagos por departamento. 

Resp: SELECT DUPNUME, AVG(EMPSALA) FROM EMP GROUP BY DEPNUME; 

Observação: Qualquer coluna ou expressão na lista de seleção, que não for uma função agregada, deverá constar da claúsula "group by". Portanto é errado tentar impor uma "restrição" do tipo agregada na cláusula Where. Having 

A cláusula "HAVING" pode ser utilizada para especificar quais grupos deverão ser exibidos, portanto restringindo-os. 

17) Retome o problema anterior, porém apresente resposta apenas para departamentos com mais de 10 empregados. 

Resp: SELECT DEPNUME, AVG(EMPSALA) FROM EMP GROUP BY DEPNUME HAVING COUNT(*) > 3; 

Observação.: A claúsula "group by" deve ser colocada antes da "having", pois os grupos são formados e as funções de grupos são calculadas antes de se resolver a cláusula "having". 

A cláusula "where" não pode ser utilizada para restringir grupos que deverão ser exibidos. 

Exemplificando ERRO típico - Restringindo Média Maior que 1000: 

SELECT DEPNUME, AVG(EMPSALA) FROM EMP WHERE AVG(SALARIO) > 1000 GROUP BY DEPNUME; 

( Esta seleção está ERRADA! ) 

SELECT DEPNUME, AVG(EMPSALA) FROM EMP GROUP BY DEPNUME HAVING AVG(EMPSALA) > 1000; 

( Seleção Adequada ) 

Seqüência no comando "Select": 

SELECT coluna(s) FROM tabela(s) WHERE condições das tuplas GROUP BY condições dos grupos de tuplas HAVING condições dos grupos de tuplas ORDER BY colunas; 

O "sql" fará a seguinte avaliação: 

a) WHERE, para estabelecer tuplas individuais candidatas (não pode conter funções de grupo) 

b) GROUP BY, para fixar grupos. 

c) HAVING, para selecionar grupos para exibição. 

Equi-Junção (junção por igualdade) - O relacionamento existente entre tabelas é chamado de equi-junção, pois os valores de colunas das duas tabelas são iguais. 

A Equi-junção é possível apenas quando tivermos definido de forma adequada a chave estrangeira de uma tabela e sua referência a chave primária da tabela precedente. 

Apesar de admitir-se em alguns casos, a equi-junção de tabelas, sem a correspondência Chave Primária-Chave Estrangeira, recomendamos fortemente não utilizar este tipo de construção, pois certamente em nenhum momento nos exemplos propostos em nossa disciplina SQL ou nas disciplinas de Análise e Projeto de Sistemas, serão necessárias tais junções. 

18) Listar Nomes de Empregados, Cargos e Nome do Departamento onde o empregado trabalha. 

Resp: Observemos que dois dos três dados solicitados estão na Tabela Emp, enquanto o outro dado está na Tabela Dept. 

Deveremos então acessar os dados restringindo convenientemente as relações existentes entre as tabelas.  De fato sabemos que DEPNUME é chave primária da tabela de Departamentos e também é chave estrangeira da Tabela de Empregados. Portanto, este campo será o responsável pela equi-junção. 

SELECT A.EMPNOME, A.EMPSERV, B.DEPNOME FROM EMP A, DEPT B WHERE A.DEPNUME = B.DEPNUME; 

Observação: 

Note que as tabelas quando contém colunas com o mesmo nome, usa-se um apelido "alias" para substituir o nome da tabela associado a coluna. 

Imagine que alguém tivesse definido NOME para ser o Nome do Empregado na Tabela de Empregados e também NOME para ser o Nome do Departamento na Tabela de Departamentos. 

Tudo funcionaria de forma adequada, pois o aliás se encarregaria de evitar que uma ambiqüidade fosse verificada. 

Embora o SQL resolva de forma muito elegante o problema da nomenclatura idêntica para campos de tabelas, recomendamos que o estudante fortemente evite tal forma de nomear os campos. 

O SQL nunca confundirá um A.NOME com um B.NOME, porém podemos afirmar o mesmo de nós mesmos? 

19) Liste os Códigos do Cada Funcionário, seus Nomes, seus Cargos e o nome do Gerente ao qual este se relaciona. 

Resp: Precisamos criar um auto-relacionamento, ou seja, juntar uma tabela a ela própria. É possível juntarmos uma tabela a ela mesma com a utilização de apelidos, permitindo juntar tuplas da tabela a outra tuplas da mesma tabela. 

SELECT A.EMPNUME, A.EMPNOME, A.EMPSERV, B.EMPNOME FROM EMP A, EMP B WHERE A.EMPGERE = B.EMPNUME; 

As Sub-Consultas Uma sub-consulta é um comando "select" que é aninhado dentro de outro "select" e que devolve resultados intermediários. 

20) Relacione todos os nomes de funcionários e seus respectivos cargos, desde que o orçamento do departamento seja igual a 300000. 

Resp: SELECT EMPNOME, EMPSERV FROM EMP A WHERE 300000 IN (SELECT DEPORCA FROM DEPT WHERE DEPT.DEPNUME = A.DEPNUME ); 

Nota: Observe que a cláusula IN torna-se verdadeira quando o atributo indicado está presente no conjunto obtido através da subconsulta. 

21) Relacione todos os departamentos que possuem empregados com remuneração maior que 3500. 

Resp: SELECT DEPNOME FROM DEPT A WHERE EXISTS (SELECT * FROM EMP WHERE EMPSALA > 3500 AND EMP.DEPNUME = A.DEPNUME'); 

Nota: Observe que a cláusula EXISTS indica se o resultado de uma pesquisa contém ou não tuplas. Observe também que poderemos verficar a não existência (NOT EXISTS) caso esta alternativa seja mais conveniente.