Wa 1 - Banco de Dados

Viso geral
Apresentao 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 importncia
destas etapas e tambm conceitual os principais comandos
padro SQL com as operaes CRUD e as propriedades ACID de
uma transao. Finalizamos com os controles de acesso aos
dados, que garantem a segurana da informao.
Todas estas etapas so fundamentais pois os sistemas voltadas
para a Web necessitam de maior ateno 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.

Contedo Programtico:
Modelo Entidade Relacionamento.
modelagem
entidade
- diagrama entidade relacionamento.

relacionamento.

Modelo Relacional Normalizado.

1
2
3
Boyce
- 4 Forma Normal.

Codd

Forma
Forma
Forma
Forma

Normal.
Normal.
Normal.
Normal.

Operaes CRUD (CERA).

- Delete (Eliminar).

Create
Read
Update

Estrutura de comandos SQL.

(Criar).
(Recuperar).
(Atualizar).

tradutor
analisador
- dicionrio de dados.

de
de

consultas.
estratgia.

de

Atomicidade.
Consistncia.
Integridade.
Durabilidade.
transao.

Propriedades ACID.
conceitos
- operaes DML.
Direitos de acesso.
concesso
revogao
- papis / perfis (Role).

de
de

direitos
direitos

(Grant).
(Revoke).

Metodologia:
Na unidade utilizaremos todos os recursos necessrios e
disponveis para o desenvolvimento da discusso do contedo,
sendo assim, faremos uso de:

Textos da prpria web-aula e de outros sites que possam

contribuir para a discusso;
Vdeos que podem esclarecer ou aprofundar determinados
contedos;
Fruns para discusso de tpicos onde seja possvel a troca
de ideias e contedos entre os discentes e docentes;
Avaliaes virtuais onde ser realizada a verificao do
aprendizado;
Entre outros recursos que podero ser utilizados visando
maior entendimento da matria.

Avaliao Prevista:
Cada web-aula conter uma avaliao virtual composta de 5
questes (sendo assim, temos 2 web-aulas com 5 questes
cada). Quando houver frum de discusso o aluno ser avaliado
quanto ao contedo de sua postagem, onde dever comentar o
tpico apresentando respostas completas e com nvel crtico de
avaliao pertinente ao nvel de ps-graduao.

Critrios para Participao dos Alunos

no Frum:
Quando houver frum de discusso o aluno ser avaliado quanto
ao contedo de sua postagem, onde dever comentar o tpico
apresentando respostas completas e com nvel crtico de
avaliao pertinente ao nvel de ps-graduao. Textos apenas

concordando ou discordando de comentrios de outros

participantes do frum sem a devida justificativa ou
complementao no acrescentam em nada ao debate da
disciplina, sendo assim, devem ser evitados. Os textos devem
sempre vir acompanhados das justificativas para a opinio do
discente sobre o contedo discutido, para que assim, possamos
dar continuidade ao debate em nvel adequado. Alm disso,
podem ser utilizados citaes de artigos, livros e outros recursos
que fundamentem a opinio ou deem sustentao a sua posio
crtica sobre o assunto. Deve ser respeitado o tpico principal do
frum, evitando debates que no tem relao com o tema
selecionado pelo professor.

Habilidades e competncias
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
possvel.
Aplicar a normalizao fundamental para este passo.
Compreender os mecanismos de funcionamento nas operaes
fundamentais e essenciais do banco de dados, uma vez que
sistemas voltados para ambiente Web so totalmente diferente
em sua arquitetura dos sistemas cliente servidor.

ESPECIALIZAO EM TECNOLOGIAS PARA APLICAES

WEB
Unidade 1 Banco de Dados na Web
INTRODUO
Quando o assunto sistemas voltados para o ambiente internet/web, o quesito banco
de dados toma uma importncia de maior proporo, pois a segurana dos dados tornase fundamental alm de um bom desempenho, lgico.
Dividimos o nosso estudo em alguns captulos que vo desde a modelagem de dados,
passando pelo processo de normalizao 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 dcada de 70.

Este modelo prega a identificao e organizao dos dados que se pretende armazenar,
tudo isto obedecendo s regras do negcio em questo e que vo permitir a integrao
e entrelaamento dos dados.
O projeto de banco de dados envolve as etapas de construo do modelo conceitual de
dados, do modelo lgico de dados e do modelo fsico de dados.
Estes modelos so projetados e desenhados com figuras geomtricas prestabelecidas, onde esta representao recebe o nome de diagrama entidade
relacionamento (DER).
As figuras geomtricas utilizadas como padro so:
- retngulo, representando as entidades;

- losango, representando os relacionamentos;

- elipses, representando os atributos;

- linhas, representando e unindo as figuras geomtricas umas nas outras;

MODELO CONCEITUAL
Nesta fase inicial do projeto de banco de dados, devemos representar o nosso cenrio
sistmico o mais prximo da realidade do nosso usurio, sempre colocando o
armazenamento dos dados de uma forma que possa haver a compreenso do que se
pretende guardar com como ser guardado.

Podemos citar um exemplo onde o nosso usurio deseja armazenar as informaes 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
lgica 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 no devemos ou precisamos nos preocupar com qual Sistema

Gerenciador de Banco de Dados (SGBD) vai ser utilizado, pois esta necessidade ser
debatida nas prximas fases do projeto de banco de dados.
O modelo conceitual nos permite em um nico relacionamento a participao de trs
ou mais entidades, uma vez que o levantamento de requisitos do sistema pode apontar
para uma regra de negcio que envolva ou apresente esta necessidade.
As ferramentas CASE (Computer Aided Software Enginneering) que trabalham a fase
de modelagem de dados, geralmente permitem a realizao dos trs modelos de banco
de dados (conceitual, lgico e fsico). Inclusive, fazem a transformao 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 ns tratamos apenas de entidades, relacionamentos, atributos e
as cardinalidades do relacionamento. No tratamos de chaves primrias ou
estrangeiras, inicialmente so chamadas de atributos identificadores.

Os atributos so referenciados apenas como caracteres, numricos, alfanumricos

ou datas, ou seja, seus domnios no so totalmente especificados ainda. possvel
j acrescentar a quantidade/tamanho dos atributos tambm, mas nada, alm disso.
MODELO LGICO
O Modelo Lgico j mais voltado especificamente ao pessoal de tecnologia da
informao, pois o tecniques ou informatiques j fica mais evidente.
Ao invs de utilizarmos entidades, agora j chamamos de tabelas, os atributos so
chamados de campos ou colunas.
Comeamos a pensar na obrigatoriedade ou no do campo, nos formatos possveis, nas
representaes que sero gravadas dentro do banco de dados.
Algumas ferramentas CASE j aproveitam para determinar qual o SGBD a ser utilizado
e comeam inclusive a trazer caractersticas e necessidades da parte fsica para esta
etapa.
No Modelo Lgico j no mais possvel representar um relacionamento ternrio entre
trs ou mais entidades/tabelas, com isto, apenas relacionamentos binrios so
permitidos, levando a necessidade de normalizar o projeto de banco de dados antes.
Para transformar o Modelo Conceitual em um Modelo Lgico, algumas ferramentas
CASE j aplicam algumas regras pr-estabelecidas e resolvem alguns dos problemas
de modelagem, porm, algumas delas no fazem de forma to automtica assim, sendo
necessrio a interveno humana na sua resoluo.
Somente relacionamentos binrios so permitidos no Modelo Lgico, pois uma das
principais caractersticas do Modelo Entidade Relacionamento fica explicito neste
modelo.
O conceito de chave primria e chave estrangeira so estabelecidos, onde o principal
ponto da integridade referencial concretizado.
Este conceito diz que a chave primria de uma tabela referenciada em outra tabela
como uma chave estrangeira, estabelecendo assim um relacionamento. A quebra deste
relacionamento compromete a integridade e a consistncia dos dados das tabelas
envolvidas.
Do lado chave primria, sabemos que s pode haver uma ocorrncia de um
determinado contedo, mas do lado chave estrangeira, a nulidade, a presena nica
ou a presena de vrias ocorrncias vai depender da regra de negcio 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 so inerentes a uma chave primria
ou uma chave estrangeira.
- o contedo de uma chave primria uma vez estabelecida, no pode ser modificado,
ou seja, sofrer um update.

- uma ocorrncia da tabela (registro) s pode ser removida se a mesma no tiver

nenhum registro em outra tabela relacionada, ou seja, no possui referencia em outras
tabelas.
- se uma ocorrncia da tabela (registro) tiver que ser removida, todos os registros da
tabela referenciada dever ser removido tambm (chamamos de infanticdio ou deleo
em cascata) ou ento a deleo original no poder ser executada.
- uma ocorrncia da tabela (registro) referenciada pode ser removida sem a
necessidade de nenhuma validao adicional (deletar um registro filho sem afetar o
registro pai ou os demais registros irmos).

MODELO FSICO
Aqui estamos tratando j dos comandos padro SQL para a criao fsica do banco de
dados, com as caractersticas e sintaxes apropriadas ao SGBD escolhido.
Em linhas gerais, o projeto fsico contm uma srie de comandos CREATE e ALTER.
Dependendo do SGBD adotado, ele pode ter uma sintaxe muito parecida com outro
SGBD, mas sempre que for necessrio utilizar um projeto fsico de um SGBD especfico
em outro SGBD, uma reviso completa de sintaxe deve ser feita, seno voc corre o
risco do seu projeto fsico no funcionar de acordo com o esperado.
Normalmente como o Modelo Fsico j esta ajustado sintaticamente para um SGBD,
caso o mesmo projeto seja utilizado em outro SGBD, provavelmente alguns trechos e
formatos dos comandos devero ser ajustados. Isto faz com que um Modelo Fsico seja

especfico de um determinado banco de dados, em muitas situaes at mesmo a

diferena de verso do mesmo SGBD faz com que o Modelo Fsico seja ajustado.
Uma prtica comum em empresas que desenvolvem software manter um projeto de
banco de dados sempre no Modelo Lgico, que independente de SGBD e na hora de
montar o seu Modelo Fsico, adequar o software para o SGBD desejado e assim a
sintaxe gerada para o Modelo Fsico ser de acordo com o software desejado e na
verso correta tambm.
As ferramentas CASE permitem que no momento de transformar o seu Modelo Lgico
em um Modelo Fsico, seja possvel escolher o SGBD desejado e at mesmo a verso
do software, para que a sintaxe seja a mais prxima possvel do que vai ser utilizado e
assim evitar erros de sintaxe ou mesmo a interveno humana no script de criao.

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

VDEO AULA 01 MODELAGEM

MODELO RELACIONAL NORMALIZADO
CONCEITO E NECESSIDADE DE NORMALIZAO

O Modelo Entidade Relacionamento tenta se aproximar o mximo possvel da

representao do cenrio sistmico e por isso mesmo no est totalmente aderente s
melhores formas de garantir a integridade e consistncia dos dados.
Por isso, uma srie de situaes pode levar o banco de dados a comprometer suas
principais caractersticas de funcionamento e validao ou at mesmo comprometer o
seu armazenamento de dados de forma organizada.
A consistncia 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 aplicao e resultado final ficou conhecida como Modelo Relacional Normalizado.
A execuo ou o processo de aplicao das regras referenciado como Normalizao
do banco de dados ou Normatizao do banco de dados, para entender um pouco
mais do significado desta palavras, veja o seguinte link.
.
O seu modelo de dados sem nenhuma reviso conhecido como Modelo
Desnormalizado, este o seu ponto de partida.
A sua aplicao 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 necessrio, passar pela Boyce Codd Forma Normal e Quarta
Forma Normal.
A 1FN, a 2FN e a 3FN so obrigatrias e resolvem praticamente todas as situaes
de normalizao. A BCNF e 4FN so necessrias apenas em situaes especiais.
Alguns especialistas de banco de dados j pregam a Quinta Forma Normal (5FN),
porm so situaes muito pontuais e especificas, nem sempre usual em sua
ocorrncia.
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 domnio repetido e que
demonstrem assim a existncia de vrias ocorrncias 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 no precisa colocar todas as repeties retiradas, apenas
uma destas ocorrncias o suficiente, uma vez que necessrio estabelecer um
relacionamento forte de 1-N, onde a chave primria da entidade forte vai ser uma chave
estrangeira na entidade fraca e tambm far parte da chave primria desta entidade
fraca.

Desnormalizado Conceitual

Desnormalizado Lgico

1 FN Conceitual

1 FN Lgico

SEGUNDA FORMA NORMAL

Na Segunda Forma Normal devemos identificar e eliminar todas as dependncias
funcionais parciais, dos atributos no chave com partes da chave primria.
Os atributos que apresentarem esta dependncia devero ser separados em uma nova
entidade e um relacionamento forte deve ser estabelecido entre elas para que a chave
primria composta continue assim.
Uma observao importante pode ser afirmada com relao s entidades que possuam
chave primria simples, estas entidades no podem conter dependncias funcionais
parciais da sua chave primria, portanto estas entidades j esto na Segunda Forma
Normal automaticamente.
2 FN Conceitual

2 FN Lgico

TERCEIRA FORMA NORMAL

A Terceira Forma Normal analisa a dependncia funcional dos atributos no chave com
os outros atributos no chave, deixando a chave primria de fora desta vez.
As dependncias que forem identificadas devero 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 ao imposta em outras colunas
no devem ser armazenados, pois podem ser calculados em tempo real sempre que
foram necessrias a sua apresentao.
O exemplo mais tradicional desta situao 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 tambm o atributo val_produto na
entidade Produto.

Aps aplicar a 3 FN
3 FN Conceitual

3 FN Lgico

BOYCE CODD FORMA NORMAL

A situao tratada pela BCFN foi descoberta pelos irmos Boyce, como as Formas
Normais j estavam todas definidas e difundidas, para no houvesse uma
renumerao ou redistribuio das Formas Normais, uma vez que esta regra deveria
ser executada entre a Terceira Forma Normal e a Quarta Forma Normal, convencionouse chamar de Boyce Codd Forma Normal.
A BCNF verifica uma situao de dependncia funcional entre chaves primrias
compostas, ou seja, quando uma parte de uma chave primria depende funcionalmente
de outra parte da chave primria, causando uma situao onde no possvel
identificar individualmente uma entidade dentro deste conjunto de entidades
semelhantes.
Isto significa que a chave primria composta precisa ser revisada, um novo atributo
dever fazer parte desta chave primria composta ou ento uma parte desta chave
primria composta dever ser trocada ou substituda.
Em linhas gerais, significa que na fase onde as chaves eram tradas como chaves
candidatas, no houve uma escolha mais criteriosa ou ento todas as possibilidades de
combinao no foram testadas.
Resumindo, a BCNF deve ser executada quando a chave primria composta no est
executando a sua funo primordial de identificao individual.
Geralmente quando o analista cria um atributo ID ou COD e pensa num identificador
ou cdigo, onde ele mesmo vai decidir e estabelecer qual o domnio deste identificador
ou cdigo, porque ele no encontrou nenhum outro atributo na entidade que permita
ou possibilite a funo de chave primria, com isto ele puxa a responsabilidade de criar
um atributo que vai conter um valor controlado e no repetido. Assim a Boyce Codd
Forma Normal acaba sendo desnecessria.
Ex. uma entidade Produto modelada para um pequeno comrcio.

Veja que com os atributos nome_produto e descricao_produto escolhidos como chave

primria (atributos identificadores no modelo conceitual) podemos ter o seguinte
cenrio:
- 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 alumnio
- peso_produto = 350 ml
- data_validade_produto = 31/12/2012
- valor_produto = 2,50
Veja que os produtos so iguais em nome e descrio, mas diferenciam-se no tipo de
embalagem, no peso e no valor.
Neste caso, fica evidente que os dois atributos escolhidos no so uma boa escolha.
A soluo seria acrescentar mais um atributo como identificador ou ento, fazer o
tradicional que criar um novo atributo com a descrio de Identificador ou Cdigo,
trazendo a responsabilidade do seu domnio para o sistema.

QUARTA FORMA NORMAL

A 4FN trata de relacionamentos ternrios (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 ternrio
ou n-rio.

Exemplo de relacionamento binrio

Exemplo de relacionamento ternrio com 3 entidades

Exemplo de relacionamento ternrio com 4 entidades

No Modelo Lgico no podemos implementar o relacionamento ternrio, ento temos

que transformar todos os relacionamentos ternrios em vrios relacionamentos
binrios, voc pode montar quantos relacionamentos binrios forem necessrios para
que a sua regra de negcio seja mantida.

Exemplo de um relacionamento binrio no modelo lgico

Exemplo do um relacionamento ternrio transformado em vrios binrios

Exemplo de um relacionamento ternrio transformado em vrios binrios

Este exemplo acima demonstra uma situao onde o relacionamento ternrio inicial foi
desmembrado em 3 relacionamentos binrios, uma situao que pode contemplar a
todas as necessidades de regras de negcio.
As cardinalidades neste caso no foram mantidas para efeito de demonstrao, mas no
seu dia a dia, deve-se prestar muita ateno para no montar um looping de
relacionamento.
VDEO AULA 02 - MRN

Pessoal, vamos participar do frum colocando suas opinies, dvidas, ponto de vista e
aproveitarmos o momento para troca de conhecimento.

QUESTO PARA REFLEXO UNIDADE I

Na unidade I da web aula, abordamos o modelo entidade relacionamento e depois o
modelo relacional normalizado.
Com este contedo foi possvel compreender por que um projeto de banco de dados
no deve ser implementado diretamente sem que haja uma anlise aprofundada
aplicando-se as regras de normalizao.
Dentro deste sentido, os atributos calculados geralmente acabam gerando uma
polmica, pois o MRN pede para elimin-los, mas em prol da performance, alguns
analistas preferem mant-los.
Qual a sua opinio sobre este ponto? Participe do frum.

CHEN, Peter. Modelagem de dados. So 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. So Paulo: Pearson, 2009.
_______.Banco de dados II. So Paulo: Person, 2009.
SILBERSCHATZ, A & KORTH, H & SUDARSHAN, S. Sistemas de banco de dados. So
Paulo: Campus, 2012.

ESPECIALIZAO EM TECNOLOGIAS PARA APLICAES

WEB
Unidade 2 Banco de Dados na Web
PADRO SQL
O padro SQL (Structure Query Language Linguagem de Consulta Estruturada )
nasceu dentro dos laboratrios de pesquisa da IBM na dcada de 70, mas foi na dcada
de 80 que ganhou fora quando o Instituto Nacional Americano de Padres (ANSI) e a
Organizao Internacional de Padres (ISO) estabeleceram uma verso final do que
ficou conhecido como Padro SQL (ANSI,86) ou SQL-86.
Algumas revises j foram realizadas acrescentando novos comandos e funes, assim
nasceram o SQL-92, o SQL-99 e o SQL-2003.
Sempre que o assunto SQL entra em cena, enfatizada a semntica dos comandos que
facilitam muito a compreenso 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 reforar a adoo do padro SQL (ex. MS SQL-SERVER, MYSQL).
Porm, nenhum deles adota 100% da sintaxe padro, sempre colocam pequenas
modificaes na sua sintaxe para que caso o usurio queira trocar de SGBD, esta
operao no possa ser feita sem nenhuma modificao ou adaptao.
Os comandos utilizados no padro SQL podem ser classificados em linhas bsicas como
DML ou DDL.

Comandos DML fazem a manipulao dos dados onde escolha do melhor caminho
pode ser feita pelo prprio usurio (DML procedural) ou pelo prprio SGBD (DML no
procedural).
J os comandos DDL fazem a manipulao das estruturas de armazenamento e acesso,
definindo, alterando, modificando ou eliminando estes objetos do banco de dados.

COMANDOS DML
Os comandos DML (Linguagem de Manipulao 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 usurio deve especificar quais dados ele deseja
localizar no banco de dados e tambm 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 no procedural, geralmente o mais utilizado no nosso dia a dia,
pois o usurio 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 esto armazenados no dicionrio de dados, mais
especificamente na parte dos dados estatsticos para realizar a analise da melhor
estratgia de acesso.
ESTRUTURA DE COMANDO SQL
O SGBD pode interpretar os comandos SQL de duas formas, a primeira atravs de
alguma ferramenta que faa o acesso intrusivo no banco de dados onde geralmente os
comandos so interpretados e executados ou na segunda forma que atravs de
objetos no prprio banco de dados, por exemplo: procedures de banco, triggers,
packages, funcionts.

Um comando SQL quando submetido execuo, passa por algumas fases.

- anlise sinttica quando o comando analisado em sua estrutura lxica e
semntica, ou seja, verificada cada parte do comando, se todos os itens necessrios
para que o comando fique completo esto presentes, se no est faltando nenhum
smbolo ou que a gramtica do comando esteja incompleta.
Ainda na anlise sinttica, os campos, tabelas e outros objetos so verificados no
dicionrio 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 no 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 estratgia j foi escolhida.
Esta indicao passada para a fase de anlise estratgica.
por isso que a adoo de uma padronizao sinttica de uso ajuda muito o SGBD.
Combinar com os analistas, coisas do tipo:
- Todos os comandos sero escritos em letras minsculas, 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 anlises distintas, com
provavelmente a indicao da mesma estratgia de acesso, mas isso no 100%
garantido.
A economia parece pequena, mas se a consulta for executada milhares de vezes ao
dia, so muitas etapas de anlise que podem ser economizadas.

- anlise estratgica a fase onde o SGBD recebe o aval da anlise sinttica e de

posse do resultado desta anlise, vai consultar o dicionrio de dados e as estatsticas
do banco de dados para definir a sua estratgia e escolher qual o melhor caminho
para chegar s informaes solicitadas pelo comando em execuo.
Para esta fase importantssimo que as informaes estatsticas estejam devidamente
atualizadas, pois caso contrrio, com informaes antigas ou erradas, possvel que o
SGBD tome uma deciso errada na hora de montar o plano de acesso aos dados.
- execuo do comando agora que o SGBD j definiu como vai fazer, o comando
executado, ou seja, as ordens dentro do comando so executadas de acordo com a sua
recomendao.

Esta fase onde o comando SQL estruturado muito importante pois dois usurios
diferentes podem pedir a mesma solicitao de dados para o SGBD e receber
interpretaes diferentes e consequentemente, ser executado por caminhos diferentes
com performances diferentes tambm.
COMANDO SELECT

O comando SELECT faz a leitura dos dados nas tabelas, procurando pela informao
solicitada e depois apresentando os resultados ao usurio solicitante.
O acesso pode ser feito em uma nica tabela ou em vrias 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 informao ou vrias
linhas de informao, bem como pode no trazer linha nenhuma, ou seja, uma resposta
vazia (no 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
produo e banco de teste, onde o comando tem um resultado no desenvolvimento e
outro na produo).
Alguns cuidados devem ser tomados no uso do comando SELECT como o uso correto
da clusula 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 informao nova dentro de uma
tabela.
A insero feita em uma tabela de cada vez, ou seja, na mesma sintaxe no possvel
(ainda) gravar dados em duas ou mais tabelas ao mesmo tempo.
Em cada insero, gravado apenas um registro de cada vez. Existem sintaxes que
permitem gravar dois ou mais registros num mesmo comando SQL, porm neste caso
fica evidente que o comando est fora do padro SQL ANSI. Pode at ser que em breve
uma nova reviso do padro SQL inclua esta nova sintaxe, mas no momento est fora.
Quando executado o comando INSERT, verificada a validade dos dados em questo,
como por exemplo, se o contedo do campo chave primria nico ou no, se existem
atributos de preenchimento obrigatrio, se existem valores de atributo tipo DATA
invlidos ou no, se existem atributos com valores pr-determinados / definidos, se
existem atributos que so chaves estrangeiras e a sua validade com a chave primria
correspondente.
Estas validaes so conhecidas como regras de negcio ou constraints, como estas
validaes so executadas pelo banco de dados, os programas aplicativos no precisam
programar estas regras em sua estrutura.
Caso ocorra algum problema, uma mensagem de erro emitida e o comando no
completado.
COMANDO UPDATE

O comando UPDATE possibilita substituir alguns dados previamente gravados nas

tabelas, independentemente do motivo da atualizao, este comando regrava uma
nova informao sobrepondo a informao antiga.
A atualizao feita em uma nica tabela de cada vez, porm a quantidade de registros
afetados depende diretamente da clusula de seleo colocada na sintaxe do comando.
Aqui vale a mesma observao feita para o comando SELECT, o comando UPDATE pode
afetar um ou vrios registros e at mesmo nenhum registro, apresentando resultados
diferentes em bancos de dados diferentes tambm.
As regras de validao so equivalentes ao do comando INSERT, ou seja, validao de
chave estrangeira, tipos de atributos, preenchimento obrigatrio ou no, valores prdeterminados.
Um comando UPDATE no permite a troca da chave primria, neste caso o usurio
dever apagar o registro por completo e depois criar um novo registro com o novo valor
de chave primria.
COMANDO DELETE
O comando DELETE permite apagar registros completos de uma tabela e o critrio de
seleo imprescindvel para que no seja cometido algum erro.
A clusula WHERE fundamental para selecionar e apagar somente os registros
desejados, por isso mesmo, recomendado que um comando SELECT com o mesmo
argumento de seleo WHERE seja aplicado antes do comando DELETE e os resultados
sejam verificados e validados, somente ento, aplicar o comando DELETE.
VDEO AULA 03 PADRO SQL - CRUD
PROPRIEDADES ACID
As propriedades ACID de um SGBD so 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 sero sempre executadas e em nenhum momento podem apresentar falhas.
Transao uma operao realizada no banco de dados que consiste em aplicao de
comandos que modificam os dados no banco de dados (gravao de um dado novo,
modificao de um dado existente ou eliminao de um dado existente).
Toda transao tem um significado lgico e consistente para a veracidade dos dados
armazenados.
A transao determinada pelo analista de sistemas dentro dos programas aplicativos
ou do usurio de banco de dados que atravs de ferramentas apropriadas realiza um
acesso interativo junto ao banco de dados.
Toda transao encerrada pelos comandos COMMIT ou ROLLBACK, que ser abordado
mais adiante.

Atomicidade uma transao de banco de dados considerada indivisvel, pode conter

vrias operaes em uma mesma transao e ao trmino da mesma, todas as
operaes estaro garantidas, uma vez concretizadas, esta transao no pode ser
dividida em partes.

Consistncia a transao tem que respeitar todas as regras de negcio aplicadas no

banco com relao consistncia dos dados (campos tipo DATA, NUMERO, CARACTER,
preenchimento obrigatrio, valores mnimos ou negativos, valores pr-estipulados
(sexo Masculino e Feminino), atributos que dependem do valor/contedo de outros
atributos).
Integridade respeita todas as regras de negcio aplicadas no banco principalmente
aquelas que dizem respeito a relacionamentos (integridade referencial).
Durabilidade no se perde com o tempo, ou seja, uma transao que foi efetivada
deve ser durvel para sempre (embora para sempre seja muito tempo, devemos pensar
assim) at que outra transao integra e consistente venha modificar os dados desta
transao antiga. Uma transao que no sofra modificaes em seus dados no pode
desaparecer do banco de dados com o passar dos anos, ou seja, o banco de dados no
pode esquecer ou perder os dados simplesmente porque pertenciam a uma transao
antiga.
00:00
00:00
VDEO AULA 04 PROPRIEDADES ACID
COMANDO COMMIT
Uma transao de banco de dados pode conter diversas operaes (Insert, Update ou
Delete) e este conjunto de operaes precisa receber uma confirmao da finalizao
da transao ou da desistncia da transao.
A confirmao feita pelo comando COMMIT, que neste momento verifica a execuo
das propriedades ACID e em caso positivo, retorna para o usurio a confirmao OK da
sua transao, em seguida j inicia uma nova transao.
COMANDO ROLLBACK
Se uma operao for executada errada e voc decidir descartar o resultado desta
operao (insert, update ou delete), possvel executar o comando ROLLBACK que
desfaz o resultado desta operao, porm todas as operaes envolvidas nesta
transao tambm so desfeitas, ou seja, o banco de dados volta at o incio da
transao corrente.

O comando ROLLBACK no permite desfazer apenas uma operao ou partes de uma

operao, ele desfaz TODAS as operaes da transao.
COMANDOS DDL
Os comandos DDL (Linguagem de Definio 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 criao de uma tabela nova, executar alteraes
na estrutura de armazenamento das tabelas e at mesmo eliminar tabelas existentes
no banco de dados.
COMANDO CREATE
O Comando CREATE utilizado para a definio 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
consistncia ativadas. Se alguma coluna ficou esquecida ou foi definida com
caractersticas erradas, no possvel executar o comando Create para este mesmo
objeto, voc tem que partir para o comando de alterao 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 situaes onde mesmo
sintaxe permitindo a execuo, devido aos dados j armazenados na tabela, a
modificao no pode ser executada por ferir regras de integridade referencial ou
consistncia.
Incluir uma nova coluna que a principio parece ser uma tarefa simples, depende muito
do tipo de incluso que est sendo realizada.
Se incluir uma coluna nova sem propriedades de validao (not null, valores prdefinidos S/N, M/F), est uma operao executada na hora e sem erros.
Se incluir uma coluna nova com propriedades de validao (not null, valores prdefinidos S/N, M/F), temos dois cenrios, se a tabela estiver vazia (sem nenhum
registro) a alterao vai proceder normalmente, mas se a tabela estiver j populada
(com registros), provavelmente vai dar errado.
Como possvel 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 contradio 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 validao de null para not null.

Se a alterao envolver aumentar o tamanho de um campo, independentemente deste

campo ser numrico ou alfanumrico, esta uma operao executada tranquilamente.
Agora, se a alterao 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 alterao executada na hora.
Se a tabela j possuir registros dentro, o impacto da modificao feito antes,
analisando se a quantidade/tamanho da diminuio afeta algum registro j armazenado
ou no, 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 modificao processada na hora, mas se existir um registro
apenas cujo contedo do nome seja maior que 40 caracteres, j vai dar errado e o
comando no ser processado.
O que fazer ento, tem que ser analisado se os dados podem ser truncados ou no,
no uma deciso que o analista de sistemas pode tomar sozinho, tem que ser
conversado com os usurios antes de qualquer deciso.
Uma modificao de tipo de dado ento mais complicada ainda.
Modificar uma coluna numrica para alfanumrica pode ser fcil, porm preciso
lembrar que os nmeros esto sempre alinhados pela direita e depois desta modificao
estaro alinhados pela esquerda.
J modificar uma coluna alfanumrica para numrica, s vai dar certo se na coluna
original, todos os dados sejam nmeros e no podemos esquecer-nos do alinhamento
esquerda que passar a ser pela direita. Lembre-se que em um campo alfanumrico,
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 compreenso de cenrio 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 modificaes no banco de produo, deu tudo errado.
Onde est o erro? Banco de testes geralmente no tem a mesma massa de dados do
banco de produo.
Por causa deste tipo de situao, em empresas cuja rea de TI est bem estruturada,
geralmente tem no mnimo 3 ambientes, um banco de dados de produo (o principal),
um banco de dados de homologao (cpia da produo para testes, que
periodicamente igualado ao de produo, para manter o retrato mais fiel possvel da
produo) e um banco de dados de testes e desenvolvimento, onde so realizados
todos os testes iniciais.

COMANDO DROP
O comando DROP permite eliminar definitivamente uma tabela do banco de dados, ou
seja, alm de todos os dados, a estrutura de armazenamento tambm eliminada.
Caso a tabela em questo seja parte de uma regra de integridade referencial, ou seja,
possui chave primria sendo doado para outra tabela, o comando no 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
clusula 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.) so

acessados pelo prprio dono destes objetos, no necessrio nenhum controle de
acesso, porm quando desejamos que outro usurio faa uso destes recursos,
precisamos e podemos controlar estes acessos.
Nestes casos chamamos de direito de acesso aos objetos do banco de dados que so
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 usurio do banco de dados.
Podemos controlar direitos de acessos como SELECT, INSERT, UPDATE ou DELETE.
Assim, para o usurio X possvel conceder o direito SELECT e INSERT na tabela
cliente.
Desta forma, o usurio X (que no dono da tabela cliente) poder gravar novos
clientes e consultar os clientes existentes, porm este usurio X no 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 usurio sobre um determinado objeto.
A revogao poder ser total (ALL) ou parcial, especifico de um determinado tipo de
acesso.
COMANDO ROLE
Quando a quantidade de usurios nos sistemas aumenta muito, organizar e controlar
a concesso ou revogao de acessos aos objetos do banco de dados pode ficar
complicado ou gerando um trabalho enorme.
Imagine um sistema aplicativo com aproximadamente 1.000 usurios, ao incluirmos
uma nova tabela no sistema e ter que executar a liberao de acesso, sero 1.000
comandos no mnimo. Isto sem falar que dentro destes 1.000 usurios 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 usurios pode perfis
de acesso ou papis de acesso dentro do sistema, que chamamos de ROLE.
Neste caso, os comandos GRANT e REVOKE seriam dados os ROLES e os usurios
includos dentro dos ROLES.
Se um usurio estiver dentro de mais de um ROLE, ele vai acumular os direitos, ou
seja, vira uma somatria.

QUESTES PARA REFLEXO

Para entendermos um melhor vamos apresentar um cenrio com duas tabelas, uma
integridade referencial entre elas e dados que populem ambas as tabelas.
VDEO AULA 05 DIRETIVAS DE ACESSO
O modelo conceitual apresenta a tabela Marca com os atributos id_marca e nm_marca,
que recebero dados das principais montadoras de veculo do Brasil.
A segunda tabela o Modelo, com os atributos nm_modelo, tp_modelo e
tp_combustivel, que recebero dados dos principais veculos das montadoras
brasileiras.
O relacionamento de 1-N, onde uma Marca possui vrios Modelos e cada Modelo de
uma nica Marca.
Uma Marca cadastrada pode no ter nenhum Modelo ainda, mas todo Modelo deve
obrigatoriamente estar associado a uma Marca.
Justificando assim as cardinalidades mnimas e mximas de cada entidade.
Marca (1,1) possui (0,N) Modelo

Fonte: Nishimura (2012).

O modelo lgico j apresenta a integridade referencial estabelecida a nvel lgico, com
a chave primria da tabela Marca como uma chave estrangeira e primria na tabela
Modelo compondo junto com o atributo nm_modelo, uma chave primria composta
(relacionamento forte).

Fonte: Nishimura (2012).

O modelo fsico apresenta os comandos para a criao fsica 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 primria duplicada.
2 ) Este comando apresentar erro pois a troca de valores de campos chave primria
no so permitidos, seria necessrio 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 no est cadastrada na tabela MARCA.
4 ) Apesar deste comando estar sintaticamente correto, ele no poder ser executado
pois o ID_MARCA = 2 tem registros referenciados na tabela MODELO, que no podem
ficar rfos, necessrio remover os modelos primeiro.
5 ) Apesar deste comando estar sintaticamente correto, ele no poder ser executado
pois o campo NM_MARCA apesar de no ser a chave primria da tabela MARCA, com o
contedo TOYOTA possui registros na tabela MODELO que so referenciados pela
chave primria de forma automtica (conhecido como integridade referencial).
6 ) Este comando est sintaticamente correto, porm faz o uso de um valor para
ID_MARCA = 11, e este valor no 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 no temos o valor FOX em nenhuma das ocorrncias
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 no sabe que PUNTO no da VOLKSWAGEM mas a partir deste momento
esta uma informao verdadeira para o banco de dados.
10) Este comando est sintaticamente correto porm no pode ser executado pois no
permitido alterar / atualizar valores em campos que sejam parte da chave primria,
como o caso do ID_MARCA na tabela MODELO ( chave primria e chave estrangeira
ao mesmo tempo).
Estas foram apenas algumas dicas para demonstrar que o mundo do banco de dados
bem organizado e a utilizao do padro SQL facilita muito o dia a dia.
A prtica o melhor caminho para o seu aperfeioamento e nunca se esquea 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 contedo
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.
Questo para reflexo Unidade II

Na unidade II da web aula, o padro SQL com as operaes CRUD e propriedades ACID
que foram os pontos de ateno.
Como a padronizao de comandos entre softwares concorrentes pode ser considerado
algo vantajoso? Participe do frum.
Usurio feliz

Analista feliz

Obrigado

CHEN, Peter. Modelagem de dados. So 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. So Paulo: Pearson, 2009.
_______.Banco de dados II. So Paulo: Person, 2009.
SILBERSCHATZ, A & KORTH, H & SUDARSHAN, S. Sistemas de banco de dados. So
Paulo: Campus, 2012.
SUGESTES DE LEITURA
KROENKE, David M. Banco de dados. Rio de Janeiro: LTC, 1999.