Baixe Introdução ao Banco de Dados e SQL: Fundamentos e Características e outras Notas de estudo em PDF para Informática, somente na Docsity!
Apostila de Banco de Dados e SQL
Autores: Prof. Jorge Surian Prof. Luiz Nicochelli
Introdução
Devido a carência de literatura destinada ao ensino de Banco de Dados e SQL para estudantes, elaboramos a presente apostila, que não possue o intento de esgotar tão abrangente volume de informações, servindo tão somente para estabelecer um mínimo de conhecimentos destinados a introduzir o estudante no mundo dos Gerenciadores de Banco de dados e da Linguagem SQL.
Banco de Dados
Todos nós sabemos existirem 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 de nosso banco. Nosso Título Eleitoral ou nosso Cadastro de Pessoa Física, certamente estão armazenados em Bancos de Dados colossais. 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, ou seja, existe uma ampla gama de dados que se referem a relacioamentos 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. E 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!
O fato de montarmos uma Mala Direta em um micro PC-XT com um drive já faz de nós um autor de um Banco de Dados?
Claro que não! Um Banco de Dados é antes de mais nada uma coleção logicamente coerente de dados com determinada significação intrínseca. Em outras palavras um arquivo contendo uma série de dados de um cliente, um arquivo com dados aleatoriamente gerados e dois arquivos padrão dbf (dBase) que tem uma relação definida entre ambos, não pode ser considerada uma Base de Dados Real.
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 uma Base de Dados (ou Banco de Dados, ou ainda BD) é 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 representa. A forma mais comum de interação Usuário e 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 responsáveis pelo controle ao acesso aos dados e pela coordenação da utilização do BD. Já os projetistas de Banco de Dados (DBP) são analistas que identificam os dados a serem armazenados em um Banco de Dados e pela 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.
SGBD x GA
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. As linguagens Delphi (utiliza opcionalmente o padrão dBase) e o VB (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 GA (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 GA 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 resgistro 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.
Características Gerais de um SGBD
Os SGBD tem sete características operacionais elementares sempre observadas, que passaremos a listarr:
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 imcumbir 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 compoenentes, 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.
As interfaces ISQL e WinSQL devem deixar muito claro ao estudante como uma interface pobre (no caso a existente no ISQL) perde muito, quando comparada a uma interface mais recursiva. A esquematização existente no Banco de Dados é muito melhor do que aquela mantida em alguma pasta, em algum arquivo do CPD, que sempre está “um pouquinho” desatualizada.
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 Gerenciamente 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 adeqüaçã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.
Componentes de um Banco de Dados
Um Banco de Dados é composto pelas seguintes partes:
Gerenciador de Acesso ao Disco: O SGBD utiliza o Sistema Operacional para acessar os dados armazenados em disco, controlando o acesso concorrente às tabelas do Banco de Dados. O Gerenciador controla todas as pesquisas queries) solicitadas pelos usuários no modo interativo, os acessos do compilador DML, os acessos feitos pelo Processador do Banco de Dados ao Dicionário de Dados e também aos próprios dados.
O Compilador DDL (Data Definition Language) processa as definições do esquema do Banco de Dados, acessando quando necessário o Dicionário de Dados do Banco de Dados.
O Dicionário de Dados contém o esquema do Banco de Dados, suas tabelas, índices, forma de acesso e relacionamentos existentes.
O (^) Processador do Banco de Dados manipula requisições à própria Base de Dados em tempo de execução. É o responsável pelas atualizações e integridade da Base de Dados.
O Processador de Pesquisas (queries) dos usuários, analisa as solicitações, e se estas forem consistentes, aciona o Processador do Banco de Dados para acesso efetivo aos dados.
As aplicações fazem seus acessos ao pré-compilador DML da linguagem hospedeira, que os envia ao Compilador DML (Data Manipulation Language) onde são gerados os códigos de acesso ao Banco de Dados.
Tipos de SGBD
Introdução
Podemos citar como tipos principais os Bancos de Dados Relacionais, os Hierárquicos, os de Rede, os Semânticos, os Orientados a Objetos e os Universais.
Os Bancos de Dados alvo de nosso estudo serão os Relacionais, sendo que os demais tipos serão apenas citados superficialmente, por não serem parte integrante de nosso curso.
Esquema de Organização dos Dados
Em Linguagem C os estudantes tomaram (ou irão tomar contato) com os ponteiros de registro, que aqui representaremos como sendo números de acesso ao registro. Visando diferenciar o número do registro físico do número do registro apontado pelo ponteiro, usaremos o símbolo (#) para indicar o número do registro físico, enquanto o símbolo (*) será utilizado pelo para indicar o endereço indicado pelo ponteiro, a semelhança da representação usual dos programadores da Linguagem C.
Vamos supor o arquivo abaixo ordenado alfabeticamente (físico):
#1- Amarelo * #2- Azul * #3- Branco * #4- Preto * #5- Verde * #6- Vermelho --
Supondo desejarmos incluir a cor Laranja, seríamos obrigado a re-escrever todo o arquivo de modo a Laranja ocupar o registro 4. Vamos antes de fazer uma nova ordenação, analisar a solução abaixo:
#1- Amarelo * #2- Azul * #3- Branco * #4- Preto * #5- Verde * #6- Vermelho -- #7- Laranja *
Observe que o registro #3 (Branco) passou a apontar para o registro *7, que contém o novo dados (Laranja). O novo dado passa a apontar para o registro previamente apontado pelo registro que agora o aponta. Parece, e é confuso, mas se você analisar o esquema abaixo perceberá que apesar do palavreado confuso, facilmente qualquer um de nós percebe a maneira adequada de inserir novos registros.
Algo --> Apontado
Algo --> Novo --> Apontado
#1 Algo --> * #2 Apontado não aponta (é o último física e logicamentex)
#1 Algo --> * #2 Apontado não aponta (é o último logicamente) #3 Novo --> *2 (é o último fisicamente)
A chamada perda de ponteiros, fenômeno dos mais temidos pelos profissionais de sistema, nada mais é que a perda de referência lógica entre registros de uma tabela.
Existem diversas técnicas de acesso como as chamadas Btree+ (Arvore Binária Balanceada), Hashing, Sequencial Ordenado, Hashing Dinâmico, Hashing Extensível e Hashing Linear, próprios para um curso específico de Banco de Dados, que não chegaremos a analisar em nosso curso.
Sabemos que em linguagem C foi (ou será) apresentada a técnica de balanceamento de estruturas, que mostrou (ou
Banco de Dados Hierárquicos
Seguem o estilo de um organograma empresarial (Diretoria-Divisão-Seção-Setor) ou de biblioteca (Exata-Matemática- Algebra Linear-Vetores). Este modelo é capaz de representar este tipo de organização de forma direta, mas apresenta inconvenientes quando esta situação não aparece claramente com relações de hierarquia.
O Exemplo a seguir (Folha de Pagamento) deve servir para esclarecer melhor o estilo deste modelo
Fábrica Financeiro Comercial
Injeção Extrusão Pagar Receber Contábil Vendas Marketing
Paulo Vinícius Vilma Sílvia Dagoberto Juracy Richard Pedro Carlos Ernesto Sandra Paula Pedrinho João
Sabemos que Paulo é "filho" da Injeção que por sua vez é "filha" da Fábrica.
Banco de Dados em Redes
Neste modelos os dados são dispostos em registros, previamente classificados em classes que descrevem a estrutura de determinado tipo de registro. Os registros são descritos em relações de conjuntos onde são estabelecidas as ligações lógicas entre eles.
O esquema abaixo representa este tipo de Ligação
Fábrica #1 Nome Local ... Apontada Aponta_Início Aponta_Final Injeção #7 Nome Máquina ... Apontada (1) Aponta_I(15) Aponta_F(18) #15 Paulo 28 (Idade) ... (7) (17) #18 João 25 ... (17) (*7)
Um confusão habitualmente verificada, diz respeito a confusão que existe entre o conceito do Modelo de Redes e o existente na matemática. No modelo de Redes temos sempre um elemento distitivo, o registro base e a partir dele são dispostos os demais registros. Temos sempre tipos de conjunto, que dispõe de três elementos, a saber: nome, tipo de registro pai e tipo de registro filho. Supondo um Registro contido no Arquivo de Disciplinas ministradas na Íbero, este seria um registro pai, na medida em que conteria a referência aos seus registros filhos (os alunos cursando aquela disciplina).
As restrições impostas pelo Modelo de Redes podem ser descritas como de ordem de Entrada e de Existência. Em relação as restrições de entrada citamos a obrigatoriedade de cada novo registro estar conectado (ou apontado, como preferem os programadores C) ao conjunto indicado. Em relação a restrições de Existência podemos dizer que um componente de um tipo de registro pode existir de forma independente de outros desde que esteja conectado a algum outro registro fazendo parte de algum conjunto, ou sendo base de um novo conjunto. A identificação de um conjunto pode ser verificada através do esquema de ligação entre o registro pai e o registro filho, assim sendo, cada instância de conjunto apresenta um elemento de distinção, o tal registro pai, e os registros filhos devidamente ordenados, e portanto passíveis de serem acessados pelos seus elementos.
Exemplo: Disciplina Tópicos Avançados e seus Alunos
Registro de Disciplinas
Informática
Álvaro
Maurício
Cláudio
Registro de Alunos
O exemplo anterior representa uma instância de connjunto, no caso Disciplinas (Tópicos Avançados) e seus alunos (no caso Álvaro, Amorim e Cláudio).
Banco de Dados Orientados ao Objeto
Representam os dados como coleções que obedecem propriedades. São modelos geralmente conceituais dispondo de pouquíssimas aplicações reais. Neste Modelo não seria interessante a existência de uma tabela de funcionários e dentro dela alguma referência para cada registro, de forma a podermos saber onde (em que departamento) o funcionário está alocado. Um conjunto de regras disponibilizaria em separado os funcionários da fábrica, que no entanto estariam agrupados aos demais, para o sistema de folha de pagamento.
Banco de Dados Universal
Usa fortemente o conceito dos bancos de dados relacionais (ainda a serem vistos), no que concerne ao tratamento da informação dita caracter e muito do Modelo Orientado ao Objeto, no tocante ao tratamento de Imagens e Sons. É um dos assuntos top do momento, e será alvo de pesquisas na disciplina Tópicos Avançados - Atualidades, não sendo objeto imediato de nossa matéria.
Forma Normal
A disciplina Análise de Sistemas abordará detalhadamente esta importante metodologia para definição das tabelas que irão compor a base de dados, que aqui apenas citaremos.
Primeira Forma Normal: Uma relação se encontra na primeira forma normal se todos os domínios de atributos possuem apenas valores atômicos (simples e indivisíveis), e que os valores de cada atributo na tupla seja um valor simples. Assim sendo todos os atributos compostos devem ser divididos em atributos atômicos.
Segunda Forma Normal: Uma relação se encontra na segunda forma normal quando estiver na primeira forma normal e todos os atributos que não participam da chave primária são dependentes desta. Assim devemos verificar se todos os atributos são dependentes da chave primária e retirar-se da relação todos os atributos de um grupo não dependente que dará origem a uma nova relação, que conterá esse atributo como não chave. Desta maneira, na segunda forma normal evita inconsistências devido a duplicidades.
Terceira Forma Normal: Uma relação estará na terceira forma normal, quando estiver na primeira forma norma e todos os atributos que não participam da chave primária são dependentes desta porém não transitivos. Assim devemos verificar se existe um atributo que não depende diretamente da chave, retirá-lo criando uma nova relação que conterá esse grupo de atributos, e defina com a chave, os atributos dos quais esse grupo depende diretamente.
O processo de normalização deve ser aplicado em uma relação por vez, pois durante o processo de normalização vamos obtendo quebras, e por conseguinte, novas relações. No momento em que o sistema estiver satisfatório, do ponto de vista do analista, este processo iterativo é interrompido. De fato existem literaturas indicando quarta, quinta formas normais, que não nos parece tão importante, nem mesmo academicamente.
A normalização para formas apoiadas em dependências funcionais evita inconsistências, usando para isso a própria construção da Base. Se a mesma consistência for passível de ser garantida pelo aplicativo, a normalização pode ser evitada com ganhos reais no desempenho das pesquisas. No caso da consistência não ser importante, também podemos não normalizar totalmente uma Base de Dados.
Exemplo: Normalizar os seguintes atributos:
Nº do Pedido, Nome do Cliente, Nome dos Produtos, Quantidades
Nº do Pedido, Código do Cliente, Nome dos Produtos, Quantidades Código do Cliente, Nome do Cliente
Nº do Pedido, Código do Cliente, Código dos Produtos, Quantidades Código do Cliente, Nome do Cliente Código do Produto, Nome do Produto
Nº do Pedido, Código do Cliente Código do Cliente, Nome do Cliente Código do Produto, Nome do Produto Nº do Pedido, Código do Produto, Quantidade
Cliente Pedido Item Produto
CliCodi PedNume PedNume ProCodi CliNome CliCodi ProCodi ProNome IteQtde
O esquema apresentado anteriormente poderia ser inferido diretamente, usando metodologia tipicamente apresentada em Organização e Método. Se soubermos, por hipótese, que um profissional habilitado desenhou o pedido da empresa, e que esta o está utilizando com sucesso, poderíamos basear nosso modelo de dados neste formulário. Devemos notar que muitos Analistas de Sistemas não adotam estes procedimentos, por preferirem os métodos convencionais para elaboração do Modelo de Dados.
Considerando qualquer formulário de pedidos podemos notar que o Número do Pedido geralmente tem destaque e sempre é único, ou seja encontramos nossa chave primária da Tabela de Pedidos, como sabemos que um cliente pode fazer mais de uma compra, achamos nossa Tabela de Clientes, que pode ter um Código, portanto achamos sua chave primária, que por conseguinte será a chave estrangeira da Tabela de Pedidos.
Um ponto delicado, diz respeito aos itens do pedido, que formam geralmente um espaço destacado dentro do formulário de pedidos. Geralmente, e este é um dos casos, estas áreas em separado dos formulários darão origem a tabelas filhas, como é o caso típico das duplicatas em notas fiscais, ou dos dependentes na ficha de funcionários. Portanto achamos nossa Tabela de Itens que será ligada à Tabela de Pedidos através do Número do Pedido, que é ao mesmo tempo chave primária e chave estrangeira para a Tabela de Itens.
Finalmente podemos perceber, que da mesma forma como os clientes se repetem em relação a Tabela de Pedidos, os produtos podem se repetir na tabela de itens (observe que não obstante não termos nenhum pedido com o mesmo item grafado duas vezes, este item pode ser adquirido em outro pedido). Assim descobrimos nossa quarta tabela, a Tabela de Produtos e a chave primária Código do Produto.
Já o WinSQL é um ambiente inteiramente gráfico (ao contrário do ISQL que guarda fortes características do ambiente em Mainframe onde se originou), destinado ao apredinzado, portanto somente pode criar Banco de Dados em seu formato proprietário.
Os comandos do WinSQL por serem visuais, não necessitam de maior esclarecimento além daqueles já contidos no Help. Já o ISQL apesar de possuir um Help bastante completo necessita, em nosso entender, de alguns esclarecimentos iniciais.
Uma série de comandos do interpretador, que funciona de forma análoga àquela existente no dBase modo interativo, podem ser utilizados pelo usuário. Não obstante alguns comandos tenham nome idêntico a alguns comandos do DOS, devemos notar que muitas vezes sua sintaxe é bastante diversa daquele sistema operacional. Vamos destacar os seguintes comandos:
\EDIT - Carrega o editor de bloco de notas do windows, o qual serve para a criação de arquivos para serem executados no Ideo. Ex: \edit teste.sql
\CD - Mostra o diretório onde serão gravados os arquivos *.sql, *.dic *.dat. Permite alterar para determinado diretório (\CD DADO, fará com que o diretório corrente passe a ser C:\DADO, caso o diretório corrente fosse a raiz. Permite retornar ao diretório de nível inferior (\CD ..). Atenção este comando não é análogo ao Change Dir do DOS, na medida em que não permite a mudança direta de um subnível do diretório X para um diretório Y por exemplo.
\DEFAULT - permite alterarmos o drive corrente. Ex: \DEFAULT F:
\INCLUDE - Executa arquivos *.sql. O arquivo .sql deverá conter uma série de instruções SQL. Ex: \include teste.sql
@< file > ; - Também executa arquivos *.sql. Ex: @teste.sql;
EXIT; - Finaliza a sessão do ISQL. ou ( \QUIT )
COMMIT; - Confirma a transação.
ROLLBACK; - Desfaz a transação.
SHOW ; - Mostra os nomes das tabelas existentes em determinado banco de dados. Ex: SHOW tables;
SHOW FIELDS FOR ; - Mostra os campos de determinada tabela. Ex: SHOW FIELDS FOR ATOR;
SHOW INDEXES FOR ; - Lista de indices da tabela.
SHOW RELATIONSHIPS FOR ; - Lista de relacionamentos da tabela.
LIST ; - Lista conteúdo da tabela.
Estudo Dirigido
Consideramos a linguagem SQL eminentemente prática, desta forma criamos um exmplo completo e propomos um exercício análogo, para tornar o estudante apto a manipular a linguagem SQL de maneira prática, em conformidade a filosofia eminentemente prática da Linguagem SQL.
O exemplo apresentado nesta apostila já está disponível para sua utilização do diretório \IDEO\SQL, bastando para isso você copiar este exemplo para seu diretório e iniciar os testes de forma simultânea a sua apresentação pelo professor.
É conveniente que você procure montar o exercício clássico (mundo), de forma a testar todos os conhecimentos adquiridos. Para tanto analise cuidadosamente o exercício proposto a seguir, e construa as relações, tabelas e queries adequadas ao final de cada exemplo.
Exercício: Elabore Banco de Dados Mundo que contenha as seguintes tabelas: Continente, País e Cidade. Observe que uma cidade deverá pertencer exclusivamente a um país e que cada país deverá estar cadastrado no continente onde se localizar sua área mais importante. Assim não obstante grande parte do território russo fazer parte Ásia, a Rússia será considerada fazendo parte da Europa. Assim teríamos basicamente uma relação do tipo:
Cidade --> País --> Continente
primary key (DepNume) );
create unique index DepNum on Dept (DepNume asc);
Note-se que a chave primária já está definida juntamente com o registro da tabela. A criação do índice, que por razões óbvias deve ser criado após a tabela, naturalmente é um comando totalmente independente do primeiro create, que serviu para criar a tabela e suas característica básicas.
Vamos analisar o código necessário para a criação da tabela de empregados, apresentado a seguir:
create table Emp (EmpNume integer(5) not null, EmpNome char(30) not null, EmpGere integer(5) , EmpServ char(20) , DepNume integer(4) not null, EmpAdmi date not null, EmpSala integer(10,2), EmpComi integer(10,2), primary key (EmpNume), foreign key has (DepNume) references Dept on delete restrict on update cascade );
create unique index EmpNum on Emp (EmpNume asc); create index EmpDep on Emp (DepNume asc);
A Tabela de Empregados não poderia ter sido criada antes da Tabela de Departamento, pois contém uma referência direta àquela tabela. Quando declaramos que DepNume é chave estrangeira, promovemos de fato a ligação do cadastro de empregados como o cadastro de departamentos. Ao restringirmos as exclusões, permitimos a existência de funcionários não alocados a nenhum departamento. Apesar desta prática ser contrária a tese de que devemos possuir apenas tuplas perfeitamente relacionáveis em nossas tabelas, podemos deixar esta pequena abertura, pois um usuário que excluisse inadivertidamente determinado departamento, acabaria por excluir também uma grande quantidade de funcionários, que estivessem ligados a este departamento.
Já a atualização em cascata dos códigos de departamento é uma boa providência, na medida em que teremos, uma vez alterado algum código de departamento, a atualização imediata de todos os funcionários pertencentes ao departamento cujo código foi modificado.
Observações:
1- Observar que os índices são parte intrínseca das tabelas. 2- A integridade relacional é garantida pelo Banco de Dados e não pelo aplicativo. 3- Exclusões ou Alterações em Chaves Primárias, podem acarretar exclusões, anulações ou até mesmo perda de integridade nas tabelas onde esta chave primária existir como chave estrangeira. Portanto é imprescindível muito cuidado quando da elaboração do Banco de Dados. Uma tentação muito comum ao estudante é começar criando as tabelas do Banco de Dados sem prévia Normalização. Este talvez seja o melhor caminho para perder-se tempo em vão, pois quando você terminar de projetar suas telas de entrada de dados, notará "que nada funciona!". Esta será a senha para usar o velho comando DEL do DOS e depois começar tudo de novo ...
Comando Drop
Este comando elimina a definição da tabela, seus dados e referências.
Sintaxe: DROP TABLE < nome_tabela > ;
Ex: DROP TABLE EMP;
Comando Alter
Este comando permite inserir/eliminar atributos nas tabelas já existentes.
Comando: ALTER TABLE < nome_tabela > ADD / DROP ( nome_atributo1 < tipo > [ NOT NULL ], nome_atributoN < tipo > [ NOT NULL ] ) ;
Não existe nenhum comando SQL que permita eliminar algum atributo de uma relação já definida. Assim caso você desejar eliminar uma chave primária devidamente referenciada em outra tabela como chave estrangeira, ao invés de obter a eliminação do campo, obterá apenas um erro.
Além do comando DROP que poderá eliminar uma tabela e suas relações, também podemos criar uma relação que tenha os atributos que se deseja, copiar-se a relação antiga sobre a nova e apgando-se então a relação que originalmente desejávamos eliminar.
Ex: ALTER TABLE DEPT ( ADD DEPSALA DECIMAL (10,2) );
Exercício: Criar o Banco de Dados Mundo. Observar que se um continente for excluído, todos os países contidos em tal continente também o serão. Esta situação é conhecida como exclusão em Cascata. Observar também que a exclusão de um País eliminará todas as Cidades contidas no mesmo.
Prática
O Exemplo Trabalho já possue pequeno programa destinado a construção das tabelas contidas no Banco de Dados TRABALHO. Execute "trabalho.sql" de forma a obter as tabelas acima sem necessidade de digitar as instruções SQL de maneira interativa.
Para tanto, você deverá copiar para seu diretório de trabalho o arquivo "trabalho.sql" do diretório \IDEO\SQL.
Execute: "@trabalho;" que deverá:
- Criar o banco de dados Trabalho.
- Abrir o banco de dados Trabalho.
- Criar as Tabelas, Indices e Relações contidas neste Banco de Dados.
Posteriormente execute o comando "show tables", que deverá exibir as tabelas "dept" e "emp". E ao executar "show fields dept" serão exibidos os campos da tabela "dept".
Copie e execute enchetra.sql do diretório \IDEO\SQL de forma a obter um conjunto de dados preparados para os testes a seguir apresentados.
Na próxima etapa de nosso curso, estaremos realizando pesquisas utilizando a instrução Select. Julgamos conveniente que os estudantes populem seu exercício e realizem exercícios análogos aos apresentados na Base de Dados Trabalho no Banco de Dados Mundo.
