Wa 1 - Banco de Dados

Visão geral

Apresentação da disciplina:

A disciplina Banco de Dados na Web tem a finalidade de

apresentar os conceitos do modelo entidade relacionamento, modelo relacional normalizado, debater sobre a importância

destas etapas e também conceitual os principais comandos padrão SQL com as operações CRUD e as propriedades ACID de

uma transação. Finalizamos com os controles de acesso aos dados, que garantem a segurança da informação.

Todas estas etapas são fundamentais pois os sistemas voltadas

para a Web necessitam de maior atenção por parte dos analistas de sistemas e desenvolvedores, uma vez que este tipo de

sistema é muito diferente do modelo Cliente/Servidor.

Objetivos:

Conceituar ao aluno os principais pontos a serem observados no item banco de dados durante o projeto e desenvolvimento de um

sistema voltado para a Web.

Conteúdo Programático:

Modelo Entidade Relacionamento.

- modelagem entidade relacionamento. - diagrama entidade relacionamento.

Modelo Relacional Normalizado.

- 1ª Forma Normal. - 2ª Forma Normal.

- 3ª Forma Normal. - Boyce Codd Forma Normal.

- 4ª Forma Normal.

Operações CRUD (CERA).

- Create (Criar).

- Read (Recuperar). - Update (Atualizar).

- Delete (Eliminar).

Estrutura de comandos SQL.

- tradutor de consultas.

- analisador de estratégia. - dicionário de dados.

Propriedades ACID.

- Atomicidade. - Consistência.

- Integridade. - Durabilidade.

- conceitos de transação. - operações DML.

Direitos de acesso.

- concessão de direitos (Grant). - revogação de direitos (Revoke).

- papéis / perfis (Role).

Metodologia:

Na unidade utilizaremos todos os recursos necessários e disponíveis para o desenvolvimento da discussão do conteúdo,

sendo assim, faremos uso de:

Textos da própria web-aula e de outros sites que possam contribuir para a discussão;

Vídeos que podem esclarecer ou aprofundar determinados

conteúdos; Fóruns para discussão de tópicos onde seja possível a troca

de ideias e conteúdos entre os discentes e docentes; Avaliações virtuais onde será realizada a verificação do

aprendizado; Entre outros recursos que poderão ser utilizados visando

maior entendimento da matéria.

Avaliação Prevista:

Cada web-aula conterá uma avaliação virtual composta de 5

questões (sendo assim, temos 2 web-aulas com 5 questões cada). Quando houver fórum de discussão o aluno será avaliado

quanto ao conteúdo de sua postagem, onde deverá comentar o tópico apresentando respostas completas e com nível crítico de

avaliação pertinente ao nível de pós-graduação.

Critérios para Participação dos Alunos no Fórum:

Quando houver fórum de discussão o aluno será avaliado quanto

ao conteúdo de sua postagem, onde deverá comentar o tópico apresentando respostas completas e com nível crítico de

avaliação pertinente ao nível de pós-graduação. Textos apenas

concordando ou discordando de comentários de outros

participantes do fórum sem a devida justificativa ou complementação não acrescentam em nada ao debate da

disciplina, sendo assim, devem ser evitados. Os textos devem sempre vir acompanhados das justificativas para a opinião do

discente sobre o conteúdo discutido, para que assim, possamos dar continuidade ao debate em nível adequado. Além disso,

podem ser utilizados citações de artigos, livros e outros recursos

que fundamentem a opinião ou deem sustentação a sua posição crítica sobre o assunto. Deve ser respeitado o tópico principal do

fórum, evitando debates que não tem relação com o tema selecionado pelo professor.

Habilidades e competências

Espera-se que no final do curso os alunos possam:

Compreender a necessidade de uma boa modelagem de dados para que o banco de dados possa ser o mais ágil e organizado

possível.

Aplicar a normalização é fundamental para este passo.

Compreender os mecanismos de funcionamento nas operações

fundamentais e essenciais do banco de dados, uma vez que sistemas voltados para ambiente Web são totalmente diferente

em sua arquitetura dos sistemas cliente servidor.

ESPECIALIZAÇÃO EM TECNOLOGIAS PARA APLICAÇÕES

WEB

Unidade 1 – Banco de Dados na Web

INTRODUÇÃO

Quando o assunto é sistemas voltados para o ambiente internet/web, o quesito banco de dados toma uma importância de maior proporção, pois a segurança dos dados torna-

se fundamental além de um bom desempenho, é lógico.

Dividimos o nosso estudo em alguns capítulos que vão desde a modelagem de dados,

passando pelo processo de normalização até chegarmos a uma arquitetura de banco de dados voltado para a web.

MODELO ENTIDADE RELACIONAMENTO

O modelo entidade relacionamento, que foi idealizado por Peter Chen, vem sendo

utilizado desde a década de 70.

Este modelo prega a identificação e organização dos dados que se pretende armazenar,

tudo isto obedecendo às regras do negócio em questão e que vão permitir a integração e entrelaçamento dos dados.

O projeto de banco de dados envolve as etapas de construção do modelo conceitual de

dados, do modelo lógico de dados e do modelo físico de dados.

Estes modelos são projetados e desenhados com figuras geométricas pré-

estabelecidas, onde esta representação recebe o nome de diagrama entidade relacionamento (DER).

As figuras geométricas utilizadas como padrão são:

- retângulo, representando as entidades;

- losango, representando os relacionamentos;

- elipses, representando os atributos;

- linhas, representando e unindo as figuras geométricas umas nas outras;

MODELO CONCEITUAL

Nesta fase inicial do projeto de banco de dados, devemos representar o nosso cenário sistêmico o mais próximo da realidade do nosso usuário, sempre colocando o

armazenamento dos dados de uma forma que possa haver a compreensão ‘do que se pretende guardar’ com ‘como será guardado’.

Podemos citar um exemplo onde o nosso usuário deseja armazenar as informações e

dados de um livro fiscal, ele apresenta o livro fiscal tradicional, e o analista de sistemas tem que visualizar esta necessidade e criar uma estrutura de armazenamento de forma

lógica e que possa guardar de forma organizada e segura todos estes dados.

Figura 1. Livro fiscal e o modelo de dados ‘livro_fiscal’

No modelo conceitual não devemos ou precisamos nos preocupar com qual Sistema

Gerenciador de Banco de Dados (SGBD) vai ser utilizado, pois esta necessidade será debatida nas próximas fases do projeto de banco de dados.

O modelo conceitual nos permite em um único relacionamento a participação de três

ou mais entidades, uma vez que o levantamento de requisitos do sistema pode apontar para uma regra de negócio que envolva ou apresente esta necessidade.

As ferramentas CASE (Computer Aided Software Enginneering) que trabalham a fase de modelagem de dados, geralmente permitem a realização dos três modelos de banco

de dados (conceitual, lógico e físico). Inclusive, fazem a transformação de um modelo para outro de forma automatizada e seguindo as regras do Modelo Relacional

Normalizado.

Aprofundando conhecimento

Podemos citar como exemplo de ferramentas CASE que trabalham com

banco de dados, o DBDesigner (empresa fabFORCE.net WWW.fabforce.net ), o Rational System Architect (empresa IBM

WWW.ibm.com.br/software), o Designer 2000 (empresa Oracle WWW.oracle.com.br), o Erwin Data Modeler (empresa CA WWW.ca.com).

No modelo conceitual nós tratamos apenas de entidades, relacionamentos, atributos e as cardinalidades do relacionamento. Não tratamos de chaves primárias ou

estrangeiras, inicialmente são chamadas de ‘atributos identificadores’.

Os atributos são referenciados apenas como ‘caracteres’, ‘numéricos’, ‘alfanuméricos’

ou ‘datas’, ou seja, seus domínios não são totalmente especificados ainda. É possível já acrescentar a quantidade/tamanho dos atributos também, mas nada, além disso.

MODELO LÓGICO

O Modelo Lógico já é mais voltado especificamente ao pessoal de tecnologia da

informação, pois o ‘tecniques’ ou ‘informatiques’ já fica mais evidente.

Ao invés de utilizarmos entidades, agora já chamamos de tabelas, os atributos são

chamados de campos ou colunas.

Começamos a pensar na obrigatoriedade ou não do campo, nos formatos possíveis, nas representações que serão gravadas dentro do banco de dados.

Algumas ferramentas CASE já aproveitam para determinar qual é o SGBD a ser utilizado e começam inclusive a trazer características e necessidades da parte física para esta

etapa.

No Modelo Lógico já não é mais possível representar um relacionamento ternário entre três ou mais entidades/tabelas, com isto, apenas relacionamentos binários são

permitidos, levando a necessidade de normalizar o projeto de banco de dados antes.

Para transformar o Modelo Conceitual em um Modelo Lógico, algumas ferramentas

CASE já aplicam algumas regras pré-estabelecidas e resolvem alguns dos problemas de modelagem, porém, algumas delas não fazem de forma tão automática assim, sendo

necessário a intervenção humana na sua resolução.

Somente relacionamentos binários são permitidos no Modelo Lógico, pois uma das

principais características do Modelo Entidade Relacionamento fica explicito neste modelo.

O conceito de chave primária e chave estrangeira são estabelecidos, onde o principal

ponto da ‘integridade referencial’ é concretizado.

Este conceito diz que a chave primária de uma tabela é referenciada em outra tabela

como uma chave estrangeira, estabelecendo assim um relacionamento. A quebra deste relacionamento compromete a integridade e a consistência dos dados das tabelas

envolvidas.

Do lado ‘chave primária’, sabemos que só pode haver uma ocorrência de um determinado conteúdo, mas do lado ‘chave estrangeira’, a nulidade, a presença única

ou a presença de várias ocorrências vai depender da ‘regra de negócio’ estabelecida pelo relacionamento, mas o SGBD vai seguir fielmente esta regra que for implementada

e vai garantir o cumprimento integral da mesma.

Aqui podemos apresentar algumas das regras que são inerentes a uma chave primária

ou uma chave estrangeira.

- o conteúdo de uma chave primária uma vez estabelecida, não pode ser modificado, ou seja, sofrer um ‘update’.

- uma ocorrência da tabela (registro) só pode ser removida se a mesma não tiver

nenhum registro em outra tabela relacionada, ou seja, não possui referencia em outras tabelas.

- se uma ocorrência da tabela (registro) tiver que ser removida, todos os registros da

tabela referenciada deverá ser removido também (chamamos de infanticídio ou deleção em cascata) ou então a deleção original não poderá ser executada.

- uma ocorrência da tabela (registro) referenciada pode ser removida sem a necessidade de nenhuma validação adicional (deletar um registro filho sem afetar o

registro pai ou os demais registros irmãos).

MODELO FÍSICO

Aqui estamos tratando já dos comandos padrão SQL para a criação física do banco de dados, com as características e sintaxes apropriadas ao SGBD escolhido.

Em linhas gerais, o projeto físico contém uma série de comandos CREATE e ALTER.

Dependendo do SGBD adotado, ele pode ter uma sintaxe muito parecida com outro SGBD, mas sempre que for necessário utilizar um projeto físico de um SGBD específico

em outro SGBD, uma revisão completa de sintaxe deve ser feita, senão você corre o risco do seu projeto físico não funcionar de acordo com o esperado.

Normalmente como o Modelo Físico já esta ajustado sintaticamente para um SGBD, caso o mesmo projeto seja utilizado em outro SGBD, provavelmente alguns trechos e

formatos dos comandos deverão ser ajustados. Isto faz com que um Modelo Físico seja

específico de um determinado banco de dados, em muitas situações até mesmo a

diferença de versão do mesmo SGBD faz com que o Modelo Físico seja ajustado.

Uma prática comum em empresas que desenvolvem software é manter um projeto de banco de dados sempre no Modelo Lógico, que é independente de SGBD e na hora de

montar o seu Modelo Físico, adequar o software para o SGBD desejado e assim a sintaxe gerada para o Modelo Físico será de acordo com o software desejado e na

versão correta também.

As ferramentas CASE permitem que no momento de transformar o seu Modelo Lógico

em um Modelo Físico, seja possível escolher o SGBD desejado e até mesmo a versão do software, para que a sintaxe seja a mais próxima possível do que vai ser utilizado e

assim evitar erros de sintaxe ou mesmo a intervenção humana no script de criação.

<http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados-parte-2/1678>.

VÍDEO AULA 01 – MODELAGEM

MODELO RELACIONAL NORMALIZADO

CONCEITO E NECESSIDADE DE NORMALIZAÇÃO

O Modelo Entidade Relacionamento tenta se aproximar o máximo possível da

representação do cenário sistêmico e por isso mesmo não está totalmente aderente às melhores formas de garantir a integridade e consistência dos dados.

Por isso, uma série de situações pode levar o banco de dados a comprometer suas

principais características de funcionamento e validação ou até mesmo comprometer o seu armazenamento de dados de forma organizada.

A consistência dos dados é fundamental para a confiabilidade do banco de dados.

Com isto, algumas regras foram desenvolvidas para refinar e melhorar a estrutura de armazenamento dos dados. Estas regras receberam o nome de Formas Normais e a

sua aplicação e resultado final ficou conhecida como Modelo Relacional Normalizado.

A execução ou o processo de aplicação das regras é referenciado como ‘Normalização

do banco de dados’ ou ‘Normatização do banco de dados’, para entender um pouco mais do significado desta palavras, veja o seguinte link.

.

O seu modelo de dados sem nenhuma revisão é conhecido como ‘Modelo Desnormalizado’, este é o seu ponto de partida.

A sua aplicação é sequencial do Modelo Desnormalizado para a Primeira Forma Normal, depois da Primeira Forma Normal para a Segunda Forma Normal, depois para a Terceira

Forma Normal e se for necessário, passar pela Boyce Codd Forma Normal e Quarta Forma Normal.

A 1ªFN, a 2ªFN e a 3ªFN são obrigatórias e resolvem praticamente todas as situações

de normalização. A BCNF e 4ªFN são necessárias apenas em situações especiais.

Alguns especialistas de banco de dados já pregam a Quinta Forma Normal (5ªFN),

porém são situações muito pontuais e especificas, nem sempre usual em sua ocorrência.

PRIMEIRA FORMA NORMAL

Para transformarmos um modelo de dados da sua forma desnormalizada para a Primeira Forma Normal, devemos procurar por atributos repetidos dentro das

entidades, ou seja, identificar os atributos que possuam o seu domínio repetido e que demonstrem assim a existência de várias ocorrências do mesmo atributo na entidade.

Depois de identificar estes atributos, os mesmos devem ser removidos e separados em

uma nova entidade.

Nesta nova entidade, você não precisa colocar todas as repetições retiradas, apenas

uma destas ocorrências é o suficiente, uma vez que é necessário estabelecer um relacionamento forte de 1-N, onde a chave primária da entidade forte vai ser uma chave

estrangeira na entidade fraca e também fará parte da chave primária desta entidade fraca.

Desnormalizado Conceitual

Desnormalizado Lógico

1ª FN Conceitual

1ª FN Lógico

SEGUNDA FORMA NORMAL

Na Segunda Forma Normal devemos identificar e eliminar todas as dependências

funcionais parciais, dos atributos não chave com partes da chave primária.

Os atributos que apresentarem esta dependência deverão ser separados em uma nova entidade e um relacionamento forte deve ser estabelecido entre elas para que a chave

primária composta continue assim.

Uma observação importante pode ser afirmada com relação às entidades que possuam

chave primária simples, estas entidades não podem conter dependências funcionais parciais da sua chave primária, portanto estas entidades já estão na Segunda Forma

Normal automaticamente.

2ª FN Conceitual

2ª FN Lógico

TERCEIRA FORMA NORMAL

A Terceira Forma Normal analisa a dependência funcional dos atributos não chave com os outros atributos não chave, deixando a chave primária de fora desta vez.

As dependências que forem identificadas deverão ser transferidas para uma nova

entidade e o relacionamento que deverá ser estabelecido para manter esta nova entidade, é um relacionamento fraco.

Outro ponto observado na Terceira Forma Normal é referente aos atributos calculados. Atributos que tenham o seu valor determinado por uma ação imposta em outras colunas

não devem ser armazenados, pois podem ser calculados em tempo real sempre que foram necessárias a sua apresentação.

O exemplo mais tradicional desta situação é o ‘valor total da nota fiscal’, pois é um

atributo que depende do valor individual de cada item da nota fiscal.

Para o exemplo, vamos acrescentar o atributo ‘nom_atendente’ dentro da comanda e

atributo ‘val_comanda’ na entidade Comanda e também o atributo ‘val_produto’ na entidade Produto.

Após aplicar a 3ª FN

3ª FN Conceitual

3ª FN Lógico

BOYCE CODD FORMA NORMAL

A situação tratada pela BCFN foi descoberta pelos irmãos Boyce, como as Formas

Normais já estavam todas definidas e difundidas, para não houvesse uma ‘renumeração’ ou ‘redistribuição’ das Formas Normais, uma vez que esta regra deveria

ser executada entre a Terceira Forma Normal e a Quarta Forma Normal, convencionou-se chamar de Boyce Codd Forma Normal.

A BCNF verifica uma situação de dependência funcional entre chaves primárias compostas, ou seja, quando uma parte de uma chave primária depende funcionalmente

de outra parte da chave primária, causando uma situação onde não é possível identificar individualmente uma entidade dentro deste conjunto de entidades

semelhantes.

Isto significa que a chave primária composta precisa ser revisada, um novo atributo deverá fazer parte desta chave primária composta ou então uma parte desta chave

primária composta deverá ser trocada ou substituída.

Em linhas gerais, significa que na fase onde as chaves eram tradas como chaves

candidatas, não houve uma escolha mais criteriosa ou então todas as possibilidades de combinação não foram testadas.

Resumindo, a BCNF deve ser executada quando a chave primária composta não está

executando a sua função primordial de identificação individual.

Geralmente quando o analista cria um atributo ‘ID’ ou ‘COD’ e pensa num identificador

ou código, onde ele mesmo vai decidir e estabelecer qual é o domínio deste identificador ou código, é porque ele não encontrou nenhum outro atributo na entidade que permita

ou possibilite a função de chave primária, com isto ele puxa a responsabilidade de criar um atributo que vai conter um valor controlado e não repetido. Assim a Boyce Codd

Forma Normal acaba sendo desnecessária.

Ex. uma entidade Produto modelada para um pequeno comércio.

Veja que com os atributos ‘nome_produto’ e ‘descricao_produto’ escolhidos como chave

primária (atributos identificadores no modelo conceitual) podemos ter o seguinte cenário:

- nome_produto = tota-tola

- descricao_produto = refrigerante gasoso sabor tola

- tipo_embalagem_produto = garrafa vidro

- peso_produto = 600 ml

- data_validade_produto = 31/12/2012

- valor_produto = 3,00

e um segundo produto com:

- nome_produto = tota-tola

- descricao_produto = refrigerante gasoso sabor tola

- tipo_embalagem_produto = lata alumínio

- peso_produto = 350 ml

- data_validade_produto = 31/12/2012

- valor_produto = 2,50

Veja que os produtos são iguais em nome e descrição, mas diferenciam-se no tipo de

embalagem, no peso e no valor.

Neste caso, fica evidente que os dois atributos escolhidos não são uma boa escolha.

A solução seria acrescentar mais um atributo como identificador ou então, fazer o

tradicional que é criar um novo atributo com a descrição de Identificador ou Código, trazendo a responsabilidade do seu domínio para o sistema.

QUARTA FORMA NORMAL

A 4FN trata de relacionamentos ternários (multivalorados) que podem ser modelados no plano conceitual.

Normalmente, no modelo conceitual podemos montar um relacionamento com mais de

duas entidades, este tipo de relacionamento recebe o nome de relacionamento ternário

ou n-ário.

Exemplo de relacionamento binário

Exemplo de relacionamento ternário com 3 entidades

Exemplo de relacionamento ternário com 4 entidades

No Modelo Lógico não podemos implementar o relacionamento ternário, então temos

que transformar todos os relacionamentos ternários em vários relacionamentos binários, você pode montar quantos relacionamentos binários forem necessários para

que a sua regra de negócio seja mantida.

Exemplo de um relacionamento binário no modelo lógico

Exemplo do um relacionamento ternário transformado em vários binários

Exemplo de um relacionamento ternário transformado em vários binários

Este exemplo acima demonstra uma situação onde o relacionamento ternário inicial foi

desmembrado em 3 relacionamentos binários, uma situação que pode contemplar a todas as necessidades de regras de negócio.

As cardinalidades neste caso não foram mantidas para efeito de demonstração, mas no

seu dia a dia, deve-se prestar muita atenção para não montar um looping de relacionamento.

VÍDEO AULA 02 - MRN

Pessoal, vamos participar do fórum colocando suas opiniões, dúvidas, ponto de vista e aproveitarmos o momento para troca de conhecimento.

QUESTÃO PARA REFLEXÃO UNIDADE I

Na unidade I da web aula, abordamos o modelo entidade relacionamento e depois o

modelo relacional normalizado.

Com este conteúdo foi possível compreender por que um projeto de banco de dados não deve ser implementado diretamente sem que haja uma análise aprofundada

aplicando-se as regras de normalização.

Dentro deste sentido, os atributos calculados geralmente acabam gerando uma

polêmica, pois o MRN pede para eliminá-los, mas em prol da performance, alguns analistas preferem mantê-los.

Qual a sua opinião sobre este ponto? Participe do fórum.

CHEN, Peter. Modelagem de dados. São Paulo: Mc Graw Hill/Makron, 1990.

HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzato,

1999.

KROENKE, David M. Banco de dados. Rio de Janeiro: LTC, 1999.

NISHIMURA, Roberto Yukio. Banco de dados I. São Paulo: Pearson, 2009.

_______.Banco de dados II. São Paulo: Person, 2009.

SILBERSCHATZ, A & KORTH, H & SUDARSHAN, S. Sistemas de banco de dados. São Paulo: Campus, 2012.

ESPECIALIZAÇÃO EM TECNOLOGIAS PARA APLICAÇÕES

WEB

Unidade 2 – Banco de Dados na Web

PADRÃO SQL

O padrão SQL (Structure Query Language – Linguagem de Consulta Estruturada )

nasceu dentro dos laboratórios de pesquisa da IBM na década de 70, mas foi na década de 80 que ganhou força quando o Instituto Nacional Americano de Padrões (ANSI) e a

Organização Internacional de Padrões (ISO) estabeleceram uma versão final do que ficou conhecido como Padrão SQL (ANSI,86) ou SQL-86.

Algumas revisões já foram realizadas acrescentando novos comandos e funções, assim

nasceram o SQL-92, o SQL-99 e o SQL-2003.

Sempre que o assunto SQL entra em cena, é enfatizada a semântica dos comandos que

facilitam muito a compreensão do que se pretende fazer, deixando assim o comando com uma sintaxe muito intuitiva.

Muitos SGBDs de mercado adotaram a palavra SQL na sua nomenclatura, com o intuito

de reforçar a adoção do padrão SQL (ex. MS SQL-SERVER, MYSQL).

Porém, nenhum deles adota 100% da sintaxe padrão, sempre colocam pequenas

modificações na sua sintaxe para que caso o usuário queira trocar de SGBD, esta operação não possa ser feita sem nenhuma modificação ou adaptação.

Os comandos utilizados no padrão SQL podem ser classificados em linhas básicas como

DML ou DDL.

Comandos DML fazem a manipulação dos dados onde à escolha do melhor caminho

pode ser feita pelo próprio usuário (DML procedural) ou pelo próprio SGBD (DML não procedural).

Já os comandos DDL fazem a manipulação das estruturas de armazenamento e acesso,

definindo, alterando, modificando ou eliminando estes objetos do banco de dados.

COMANDOS DML

Os comandos DML (Linguagem de Manipulação de Dados) permitem manipularmos os

dados das tabelas do banco de dados, seja incluindo novos dados, atualizando dados que já estejam gravados no banco de dados, eliminando dados armazenados e

principalmente consultando dados armazenados.

Um comando DML procedural, o usuário deve especificar quais dados ele deseja

localizar no banco de dados e também precisa especificar no mesmo comando, como fazer para chegar até estes dados. É conhecido entre os analistas e programadores

como ‘passar o HINT no comando select’, é quando o analista indica qual índice de pesquisa ele deseja que seja utilizado, apenas lembrando que a responsabilidade de

escolher um índice correto passa para o analista e tira do banco de dados a responsabilidade desta escolha.

Já o comando DML não procedural, é geralmente o mais utilizado no nosso dia a dia, pois o usuário simplesmente especifica quais dados ele quer e a escolha do melhor

caminho para este acesso é passado para o banco de dados. O banco de dados por sua vez faz acesso e utiliza os dados que estão armazenados no dicionário de dados, mais

especificamente na parte dos dados estatísticos para realizar a analise da melhor estratégia de acesso.

ESTRUTURA DE COMANDO SQL

O SGBD pode interpretar os comandos SQL de duas formas, a primeira através de alguma ferramenta que faça o acesso intrusivo no banco de dados onde geralmente os

comandos são interpretados e executados ou na segunda forma que é através de objetos no próprio banco de dados, por exemplo: procedures de banco, triggers,

packages, funcionts.

Um comando SQL quando submetido à execução, passa por algumas fases.

- análise sintática – é quando o comando é analisado em sua estrutura léxica e

semântica, ou seja, é verificada cada parte do comando, se todos os itens necessários para que o comando fique completo estão presentes, se não está faltando nenhum

símbolo ou que a gramática do comando esteja incompleta.

Ainda na análise sintática, os campos, tabelas e outros objetos são verificados no

dicionário de dados, confrontando e correlacionando os campos às tabelas, ou aos índices, seus tipos de dados e tamanhos.

Esta fase é conhecida como PARSE.

Nesta fase, o SGBD aproveita para verificar se um comando semelhante a este não foi

executado recentemente e que esteja no buffer / cache do banco de dados, pois isto

pode influenciar na escolha do caminho uma vez que o comando foi executado recentemente e a estratégia já foi escolhida.

Esta indicação é passada para a fase de análise estratégica.

É por isso que a adoção de uma padronização sintática de uso ajuda muito o SGBD.

Combinar com os analistas, coisas do tipo:

- Todos os comandos serão escritos em letras minúsculas, sejam comandos diretos

interativos ou comandos dentro de programas de computador.

- Estruturar os comandos como nos exemplos a seguir.

Apesar dos resultados serem os mesmos, será feitas duas análises distintas, com provavelmente a indicação da mesma estratégia de acesso, mas isso não é 100%

garantido.

A economia parece pequena, mas se a consulta for executada milhares de vezes ao

dia, são muitas etapas de análise que podem ser economizadas.

- análise estratégica – é a fase onde o SGBD recebe o aval da análise sintática e de

posse do resultado desta análise, vai consultar o dicionário de dados e as estatísticas do banco de dados para definir a sua estratégia e escolher qual é o melhor caminho

para chegar às informações solicitadas pelo comando em execução.

Para esta fase é importantíssimo que as informações estatísticas estejam devidamente atualizadas, pois caso contrário, com informações antigas ou erradas, é possível que o

SGBD tome uma decisão errada na hora de montar o plano de acesso aos dados.

- execução do comando – agora que o SGBD já definiu ‘como vai fazer’, o comando é

executado, ou seja, as ordens dentro do comando são executadas de acordo com a sua recomendação.

Esta fase onde o comando SQL é estruturado é muito importante pois dois usuários diferentes podem pedir a mesma solicitação de dados para o SGBD e receber

interpretações diferentes e consequentemente, ser executado por caminhos diferentes com performances diferentes também.

COMANDO SELECT

O comando SELECT faz a leitura dos dados nas tabelas, procurando pela informação

solicitada e depois apresentando os resultados ao usuário solicitante.

O acesso pode ser feito em uma única tabela ou em várias tabelas ao mesmo tempo, quando utilizamos duas ou mais tabelas, é conhecido como ‘join de tabelas’.

Um comando SELECT pode trazer como resposta uma linha de informação ou várias

linhas de informação, bem como pode não trazer linha nenhuma, ou seja, uma resposta

vazia (não encontrou nada que satisfizesse a consulta).

Veja que se o comando SELECT esta sintaticamente correta, o mesmo será executado, mas a resposta vai depender diretamente dos dados que estiverem armazenados

dentro do banco de dados.

Por isso mesmo, um comando SELECT pode ter comportamento e resposta diferente se

for executado em dois bancos de dados com a mesma estrutura de tabelas, mas com dados diferentes armazenados em cada um deles (é o famoso caso de banco de

produção e banco de teste, onde o comando tem um resultado no desenvolvimento e outro na produção).

Alguns cuidados devem ser tomados no uso do comando SELECT como o uso correto

da cláusula WHERE, pois é a ‘peneira’ para que os dados sejam retornados de acordo com a sua necessidade.

COMANDO INSERT

O comando INSERT permite que seja gravada uma informação nova dentro de uma tabela.

A inserção é feita em uma tabela de cada vez, ou seja, na mesma sintaxe não é possível (ainda) gravar dados em duas ou mais tabelas ao mesmo tempo.

Em cada inserção, é gravado apenas um registro de cada vez. Existem sintaxes que

permitem gravar dois ou mais registros num mesmo comando SQL, porém neste caso fica evidente que o comando está fora do padrão SQL ANSI. Pode até ser que em breve

uma nova revisão do padrão SQL inclua esta nova sintaxe, mas no momento está fora.

Quando é executado o comando INSERT, é verificada a validade dos dados em questão,

como por exemplo, se o conteúdo do campo chave primária é único ou não, se existem atributos de preenchimento obrigatório, se existem valores de atributo tipo DATA

inválidos ou não, se existem atributos com valores pré-determinados / definidos, se existem atributos que são chaves estrangeiras e a sua validade com a chave primária

correspondente.

Estas validações são conhecidas como regras de negócio ou ‘constraints’, como estas validações são executadas pelo banco de dados, os programas aplicativos não precisam

programar estas regras em sua estrutura.

Caso ocorra algum problema, uma mensagem de erro é emitida e o comando não é

completado.

COMANDO UPDATE

O comando UPDATE possibilita substituir alguns dados previamente gravados nas

tabelas, independentemente do motivo da atualização, este comando regrava uma nova informação sobrepondo a informação antiga.

A atualização é feita em uma única tabela de cada vez, porém a quantidade de registros

afetados depende diretamente da cláusula de seleção colocada na sintaxe do comando.

Aqui vale a mesma observação feita para o comando SELECT, o comando UPDATE pode

afetar um ou vários registros e até mesmo nenhum registro, apresentando resultados diferentes em bancos de dados diferentes também.

As regras de validação são equivalentes ao do comando INSERT, ou seja, validação de

chave estrangeira, tipos de atributos, preenchimento obrigatório ou não, valores pré-determinados.

Um comando UPDATE não permite a troca da chave primária, neste caso o usuário deverá apagar o registro por completo e depois criar um novo registro com o novo valor

de chave primária.

COMANDO DELETE

O comando DELETE permite apagar registros completos de uma tabela e o critério de

seleção é imprescindível para que não seja cometido algum erro.

A cláusula WHERE é fundamental para selecionar e apagar somente os registros desejados, por isso mesmo, é recomendado que um comando SELECT com o mesmo

argumento de seleção WHERE seja aplicado antes do comando DELETE e os resultados sejam verificados e validados, somente então, aplicar o comando DELETE.

VÍDEO AULA 03 – PADRÃO SQL - CRUD

PROPRIEDADES ACID

As propriedades ACID de um SGBD são os pontos essenciais para que um software seja realmente considerado um SGBD ou um gerenciador de tabelas.

A confiabilidade de um SGBD está diretamente ligada à garantia de que as propriedades ACID serão sempre executadas e em nenhum momento podem apresentar falhas.

Transação é uma operação realizada no banco de dados que consiste em aplicação de

comandos que modificam os dados no banco de dados (gravação de um dado novo, modificação de um dado existente ou eliminação de um dado existente).

Toda transação tem um significado lógico e consistente para a veracidade dos dados armazenados.

A transação é determinada pelo analista de sistemas dentro dos programas aplicativos

ou do usuário de banco de dados que através de ferramentas apropriadas realiza um acesso interativo junto ao banco de dados.

Toda transação é encerrada pelos comandos COMMIT ou ROLLBACK, que será abordado mais adiante.

Atomicidade – uma transação de banco de dados é considerada indivisível, pode conter

várias operações em uma mesma transação e ao término da mesma, todas as operações estarão garantidas, uma vez concretizadas, esta transação não pode ser

dividida em partes.

Consistência – a transação tem que respeitar todas as regras de negócio aplicadas no banco com relação à consistência dos dados (campos tipo DATA, NUMERO, CARACTER,

preenchimento obrigatório, valores mínimos ou negativos, valores pré-estipulados

(sexo Masculino e Feminino), atributos que dependem do valor/conteúdo de outros atributos).

Integridade – respeita todas as regras de negócio aplicadas no banco principalmente

aquelas que dizem respeito a relacionamentos (integridade referencial).

Durabilidade – não se perde com o tempo, ou seja, uma transação que foi efetivada

deve ser durável para sempre (embora para sempre seja muito tempo, devemos pensar assim) até que outra transação integra e consistente venha modificar os dados desta

transação antiga. Uma transação que não sofra modificações em seus dados não pode desaparecer do banco de dados com o passar dos anos, ou seja, o banco de dados não

pode ‘esquecer’ ou ‘perder’ os dados simplesmente porque pertenciam a uma transação antiga.

00:00

00:00

VÍDEO AULA 04 – PROPRIEDADES ACID

COMANDO COMMIT

Uma transação de banco de dados pode conter diversas operações (Insert, Update ou Delete) e este conjunto de operações precisa receber uma confirmação da finalização

da transação ou da desistência da transação.

A confirmação é feita pelo comando COMMIT, que neste momento verifica a execução

das propriedades ACID e em caso positivo, retorna para o usuário a confirmação OK da sua transação, em seguida já inicia uma nova transação.

COMANDO ROLLBACK

Se uma operação for executada errada e você decidir descartar o resultado desta

operação (insert, update ou delete), é possível executar o comando ROLLBACK que desfaz o resultado desta operação, porém todas as operações envolvidas nesta

transação também são desfeitas, ou seja, o banco de dados volta até o início da transação corrente.

O comando ROLLBACK não permite desfazer apenas uma operação ou partes de uma

operação, ele desfaz TODAS as operações da transação.

COMANDOS DDL

Os comandos DDL (Linguagem de Definição de Dados) permitem manipularmos as

estruturas de armazenamento, ou seja as tabelas e os demais objetos do banco de dados.

Em linhas gerais, podemos definir a criação de uma tabela nova, executar alterações na estrutura de armazenamento das tabelas e até mesmo eliminar tabelas existentes

no banco de dados.

COMANDO CREATE

O Comando CREATE é utilizado para a definição de novos objetos no banco de dados (tabelas, índices, triggers, procedures, functions, etc).

Uma tabela nova é criada sempre vazia e já com todas as regras de integridade e

consistência ativadas. Se alguma coluna ficou esquecida ou foi definida com características erradas, não é possível executar o comando Create para este mesmo

objeto, você tem que partir para o comando de alteração de objetos.

COMANDO ALTER

O Comando ALTER é utilizado para modificar uma tabela já existente dentro do banco de dados, neste ponto é importante observar que existem situações onde mesmo à

sintaxe permitindo a execução, devido aos dados já armazenados na tabela, a modificação não pode ser executada por ferir regras de integridade referencial ou

consistência.

Incluir uma nova coluna que a principio parece ser uma tarefa simples, depende muito

do tipo de inclusão que está sendo realizada.

Se incluir uma coluna nova sem propriedades de validação (not null, valores pré-definidos ‘S/N’, ‘M/F’), está é uma operação executada na hora e sem erros.

Se incluir uma coluna nova com propriedades de validação (not null, valores pré-definidos ‘S/N’, ‘M/F’), temos dois cenários, se a tabela estiver vazia (sem nenhum

registro) a alteração vai proceder normalmente, mas se a tabela estiver já populada (com registros), provavelmente vai dar errado.

Como é possível incluir uma nova coluna com propriedade ‘not null’ se já existem

registros na tabela, esses registros receberiam uma coluna inicialmente vazia e isto entra em contradição com a regra ‘not null’.

O que pode ser feito?

Incluir a nova coluna sem a regra ‘not null’, depois execute um comando Update populando esta coluna nova em todos os registros da tabela e depois execute

novamente o comando Alter modificando a regra de validação de ‘null’ para ‘not null’.

Se a alteração envolver aumentar o tamanho de um campo, independentemente deste

campo ser numérico ou alfanumérico, esta é uma operação executada tranquilamente.

Agora, se a alteração envolver diminuir o tamanho de um campo, tudo vai depender dos dados que estejam armazenados neste campo na tabela.

Se a tabela estiver vazia, a alteração é executada na hora.

Se a tabela já possuir registros dentro, o impacto da modificação é feito antes, analisando se a quantidade/tamanho da diminuição afeta algum registro já armazenado

ou não, por exemplo, um campo nome com 50 caracteres que vai ser modificado para 40 caracteres, se em todos os registros armazenados os nomes tiverem menos de 40

caracteres no nome, a modificação é processada na hora, mas se existir um registro apenas cujo conteúdo do nome seja maior que 40 caracteres, já vai dar errado e o

comando não será processado.

O que fazer então, tem que ser analisado se os dados podem ser truncados ou não,

não é uma decisão que o analista de sistemas pode tomar sozinho, tem que ser conversado com os usuários antes de qualquer decisão.

Uma modificação de tipo de dado então é mais complicada ainda.

Modificar uma coluna numérica para alfanumérica pode ser fácil, porém é preciso lembrar que os números estão sempre alinhados pela direita e depois desta modificação

estarão alinhados pela esquerda.

Já modificar uma coluna alfanumérica para numérica, só vai dar certo se na coluna original, todos os dados sejam números e não podemos esquecer-nos do alinhamento

à esquerda que passará a ser pela direita. Lembre-se que em um campo alfanumérico, o zero a esquerda pode ser significativo (telefone 04333750000).

Quando modificamos o tipo do dado, se a tabela estiver vazia, o resultado é a hora, mas se a tabela estiver populada, os dados precisam ser analisados antes.

Esta compreensão de cenário é muito importante porque é comum encontrarmos

analistas de sistemas dizendo:

‘no banco de testes deu certo, fiz todos os procedimentos e deu ok, mas quando fomos

aplicar as mesmas modificações no banco de produção, deu tudo errado’.

Onde está o erro? Banco de testes geralmente não tem a mesma ‘massa’ de dados do banco de produção.

Por causa deste tipo de situação, em empresas cuja área de TI está bem estruturada, geralmente tem no mínimo 3 ambientes, um banco de dados de produção (o principal),

um banco de dados de homologação (cópia da produção para testes, que periodicamente é igualado ao de produção, para manter o retrato mais fiel possível da

produção) e um banco de dados de testes e desenvolvimento, onde são realizados todos os testes iniciais.

COMANDO DROP

O comando DROP permite eliminar definitivamente uma tabela do banco de dados, ou

seja, além de todos os dados, a estrutura de armazenamento também é eliminada.

Caso a tabela em questão seja parte de uma regra de integridade referencial, ou seja,

possui chave primária sendo doado para outra tabela, o comando não vai ser executada de forma natural, uma mensagem de erro é emitida.

Você terá duas alternativas, a primeira é desativar a integridade referencial e depois

eliminar a tabela. E a segunda é eliminar a tabela acrescentando na sua sintaxe a cláusula ‘CASCADE CONSTRAINTS’ que faz este papel de eliminar a integridade

referencial para você.

COMANDOS PARA CONTROLE DE ACESSOS

Quando os objetos do banco de dados (tabelas, índices, procedures, etc.) são

acessados pelo próprio dono destes objetos, não é necessário nenhum controle de acesso, porém quando desejamos que outro usuário faça uso destes recursos,

precisamos e podemos controlar estes acessos.

Nestes casos chamamos de direito de acesso aos objetos do banco de dados que são trabalhados no sentido de conceder o acesso (GRANT) e revogar o direito de acesso

(REVOKE).

COMANDO GRANT

O comando GRANT permite conceder o direito de acesso de um determinado objeto do banco de dados para outro usuário do banco de dados.

Podemos controlar direitos de acessos como ‘SELECT, INSERT, UPDATE ou DELETE’.

Assim, para o usuário X é possível conceder o direito SELECT e INSERT na tabela cliente.

Desta forma, o usuário X (que não é dono da tabela cliente) poderá gravar novos

clientes e consultar os clientes existentes, porém este usuário X não poderá modificar os dados de nenhum cliente ou mesmo eliminar clientes cadastrados.

COMANDO REVOKE

O comando REVOKE permite revogar ou eliminar um determinado direito de acesso que

foi concedido para um usuário sobre um determinado objeto.

A revogação poderá ser total (ALL) ou parcial, especifico de um determinado tipo de

acesso.

COMANDO ROLE

Quando a quantidade de usuários nos sistemas aumenta muito, organizar e controlar

a concessão ou revogação de acessos aos objetos do banco de dados pode ficar

complicado ou gerando um trabalho enorme.

Imagine um sistema aplicativo com aproximadamente 1.000 usuários, ao incluirmos uma nova tabela no sistema e ter que executar a liberação de acesso, serão 1.000

comandos no mínimo. Isto sem falar que dentro destes 1.000 usuários poderemos ter diversos perfis de acesso (alguns só select, outros select e delete, outros select e insert,

outros tudo).

Para facilitar um pouco este tipo de controle, podemos agrupar os usuários pode perfis

de acesso ou ‘papéis de acesso’ dentro do sistema, que chamamos de ROLE.

Neste caso, os comandos GRANT e REVOKE seriam dados os ROLES e os usuários incluídos dentro dos ROLES.

Se um usuário estiver dentro de mais de um ROLE, ele vai acumular os direitos, ou seja, vira uma somatória.

QUESTÕES PARA REFLEXÃO

Para entendermos um melhor vamos apresentar um cenário com duas tabelas, uma

integridade referencial entre elas e dados que populem ambas as tabelas.

VÍDEO AULA 05 – DIRETIVAS DE ACESSO

O modelo conceitual apresenta a tabela Marca com os atributos id_marca e nm_marca,

que receberão dados das principais montadoras de veículo do Brasil.

A segunda tabela é o Modelo, com os atributos nm_modelo, tp_modelo e

tp_combustivel, que receberão dados dos principais veículos das montadoras brasileiras.

O relacionamento é de 1-N, onde uma Marca possui vários Modelos e cada Modelo é de

uma única Marca.

Uma Marca cadastrada pode não ter nenhum Modelo ainda, mas todo Modelo deve

obrigatoriamente estar associado a uma Marca.

Justificando assim as cardinalidades mínimas e máximas de cada entidade.

Marca (1,1) – possui – (0,N) Modelo

Fonte: Nishimura (2012).

O modelo lógico já apresenta a integridade referencial estabelecida a nível lógico, com

a chave primária da tabela Marca como uma chave estrangeira e primária na tabela Modelo compondo junto com o atributo nm_modelo, uma chave primária composta

(relacionamento forte).

Fonte: Nishimura (2012).

O modelo físico apresenta os comandos para a criação física destas tabelas e do

relacionamento.

Fonte: Nishimura (2012).

Tabela Marca

Fonte: Nishimura (2012).

Fonte: Nishimura (2012).

O que pode acontecer com os seguintes comandos?

1 ) INSERT INTO MARCA VALUES (7,’HYUNDAI’) ;

2 ) UPDATE MARCA SET ID_MARCA = 11 WHERE NM_MARCA = ‘FIAT’ ;

3 ) SELECT * FROM MARCA WHERE NM_MARCA = ‘KIA’ ;

4 ) DELETE MARCA WHERE ID_MARCA = 2 ;

5 ) DELETE MARCA WHERE NM_MARCA = ‘TOYOTA’ ;

6 ) INSERT INTO MODELO VALUES (11, ‘HB20’, ‘HATCH’, ‘F’);

7 ) DELETE MODELO WHERE NM_MODELO = ‘FOX’ ;

8 ) DELETE MODELO WHERE NM_MODELO = ‘307’ ;

9 ) INSERT INTO MODELO VALUES (2, ‘PUNTO’, ‘HATCH’, ‘F’) ;

10) UPDATE MODELO SET ID_MARCA = 1 WHERE NM_MODELO = ‘PUNTO’ ;

RESPOSTAS

1 ) Este comando apresentará erro pois o ID_MARCA com valor igual a 7 já existe

dentro da tabela, receberá mensagem de chave primária duplicada.

2 ) Este comando apresentará erro pois a troca de valores de campos chave primária não são permitidos, seria necessário deletar o valor antigo e depois incluir o valor novo.

3 ) Sintaticamente este comando está correto e a resposta será ‘nenhum valor

encontrado’ pois a marca KIA ainda não está cadastrada na tabela MARCA.

4 ) Apesar deste comando estar sintaticamente correto, ele não poderá ser executado

pois o ID_MARCA = 2 tem registros referenciados na tabela MODELO, que não podem ficar órfãos, é necessário remover os modelos primeiro.

5 ) Apesar deste comando estar sintaticamente correto, ele não poderá ser executado

pois o campo NM_MARCA apesar de não ser a chave primária da tabela MARCA, com o

conteúdo ‘TOYOTA’ possui registros na tabela MODELO que são referenciados pela chave primária de forma automática (conhecido como integridade referencial).

6 ) Este comando está sintaticamente correto, porém faz o uso de um valor para

ID_MARCA = 11, e este valor não existe na tabela MARCA, por isso viola a integridade referencial por fazer referencia a um valor inexistente.

7 ) Este comando está sintaticamente correto e a resposta será ‘nenhum registro deletado’, pois na tabela MODELO não temos o valor ‘FOX’ em nenhuma das ocorrências

da tabela.

8 ) Este comando está sintaticamente correto e a resposta será ‘1 registro deletado’.

9 ) Este comando está sintaticamente correto e será executado ‘OK’, para o banco de

dados, ele não sabe que ‘PUNTO’ não é da ‘VOLKSWAGEM’ mas a partir deste momento esta é uma informação verdadeira para o banco de dados.

10) Este comando está sintaticamente correto porém não pode ser executado pois não

é permitido alterar / atualizar valores em campos que sejam parte da chave primária, como é o caso do ID_MARCA na tabela MODELO (é chave primária e chave estrangeira

ao mesmo tempo).

Estas foram apenas algumas dicas para demonstrar que o mundo do banco de dados é

bem organizado e a utilização do padrão SQL facilita muito o dia a dia.

A prática é o melhor caminho para o seu aperfeiçoamento e nunca se esqueça de que ‘o mesmo comando pode ser comportamento e resultados diferentes em bancos de

dados diferentes’.

ENCERRAMENTO

Chegamos ao final da nossa disciplina, espero que tenham gostado do nosso conteúdo e compreendido que um banco de dados para web precisa de um cuidado especial,

principalmente porque o seu funcionamento é um pouco diferente do modelo tradicional.

Questão para reflexão Unidade II

Na unidade II da web aula, o padrão SQL com as operações CRUD e propriedades ACID

é que foram os pontos de atenção.

Como a padronização de comandos entre softwares concorrentes pode ser considerado algo vantajoso? Participe do fórum.

Usuário feliz Analista feliz

Obrigado

CHEN, Peter. Modelagem de dados. São Paulo: Mc Graw Hill/Makron, 1990.

HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzato, 1999.

NISHIMURA, Roberto Yukio. Banco de dados I. São Paulo: Pearson, 2009.

_______.Banco de dados II. São Paulo: Person, 2009.

SILBERSCHATZ, A & KORTH, H & SUDARSHAN, S. Sistemas de banco de dados. São Paulo: Campus, 2012.

SUGESTÕES DE LEITURA

KROENKE, David M. Banco de dados. Rio de Janeiro: LTC, 1999.