BANCO DE DADOS

Professor Esp. Ronie Cesar Tokumoto

 Universidade de Marília
Avenida Hygino Muzzy Filho, 1001
CEP 17.525–902- Marília-SP

Reitor Pró-reitor Administrativo

Márcio Mesquita Serva Marco Antonio Teixeira
Vice-reitora Direção do Núcleo de Educação a Distância
Profª. Regina Lúcia Ottaiano Losasso Serva Paulo Pardo
Pró-Reitor Acadêmico Coordenador Pedagógico do Curso
Prof. José Roberto Marques de Castro Henrique Nieddermeyer
Pró-reitora de Pesquisa, Pós-graduação e Ação Edição de Arte, Diagramação, Design Gráfico
Comunitária B42 Design
Profª. Drª. Fernanda Mesquita Serva

F385m sobrenome, nome

nome livro / nome autor. nome /coordenador (coord.) - Marília:
Unimar, 2021.

PDF (00p.) : il. color.

ISBN xxxxxxxxxxxxx

1. tag 2. tag 3. tag 4. tag – Graduação I. Título.

CDD – 00000

*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência. Informamos
que é de inteira responsabilidade da autoria a emissão de conceitos.

Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização. A
violação dos direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.

Imagens, ícones e capa: ©envato, ©pexels, ©pixabay, ©Twenty20 e ©wikimedia

BOAS-VINDAS
Ao iniciar a leitura deste material, que é parte do apoio pedagógico dos
nossos queridos discentes, convido o leitor a conhecer a UNIMAR –
Universidade de Marília.

Na UNIMAR, a educação sempre foi sinônimo de transformação, e não

conseguimos enxergar um melhor caminho senão por meio de um ensino
superior bem feito.

A história da UNIMAR, iniciada há mais de 60 anos, foi construída com base

na excelência do ensino superior para transformar vidas, com a missão
de formar profissionais éticos e competentes, inseridos na comunidade,
capazes de constituir o conhecimento e promover a cultura e o intercâmbio,
a fim de desenvolver a consciência coletiva na busca contínua da valorização
e da solidariedade humanas.

A história da UNIMAR é bela e de sucesso, e já projeta para o futuro novos

sonhos, conquistas e desafios.

A beleza e o sucesso, porém, não vêm somente do seu campus de mais de

350 alqueires e de suas construções funcionais e conectadas; vêm também
do seu corpo docente altamente qualificado e dos seus egressos: mais
de 100 mil pessoas, espalhados por todo o Brasil e o mundo, que tiveram
suas vidas impactadas e transformadas pelo ensino superior da UNIMAR.

Assim, é com orgulho que apresentamos a Educação a Distância da UNIMAR

com o mesmo propósito: promover transformação de forma democrática
e acessível em todos os cantos do nosso país. Se há alguma expectativa
de progresso e mudança de realidade do nosso povo, essa expectativa
está ligada de forma indissociável à educação.

Nós nos comprometemos com essa educação transformadora,

investimos nela, trabalhamos noite e dia para que ela seja
ofertada e esteja acessível a todos.

Muito obrigado por confiar uma parte importante do seu

futuro a nós, à UNIMAR e, tenha a certeza de que seremos
parceiros neste momento e não mediremos esforços para
o seu sucesso!

Não vamos parar, vamos continuar com investimentos

importantes na educação superior, sonhando sempre.
Afinal, não é possível nunca parar de sonhar!

Bons estudos!

Dr. Márcio Mesquita Serva

Reitor da UNIMAR
Que alegria poder fazer parte deste momento tão especial da sua vida!

Sempre trabalhei com jovens e sei o quanto estar matriculado

em um curso de ensino superior em uma Universidade de
excelência deve ser valorizado. Por isso, aproveite cada
minuto do seu tempo aqui na UNIMAR, vivenciando o ensino,
a pesquisa e a extensão universitária.

Fique atento aos comunicados institucionais, aproveite as

oportunidades, faça amizades e viva as experiências que
somente um ensino superior consegue proporcionar.

Acompanhe a UNIMAR pelas redes sociais, visite a sede

do campus universitário localizado na cidade de Marília,
navegue pelo nosso site unimar.br, comente no nosso blog
e compartilhe suas experiências. Viva a UNIMAR!

Muito obrigada por escolher esta Universidade para a Profa. Fernanda

realização do seu sonho profissional. Seguiremos, Mesquita Serva
Pró-reitora de Pesquisa,
juntos, com nossa missão e com nossos valores, Pós-graduação e Ação
sempre com muita dedicação. Comunitária da UNIMAR

Bem-vindo(a) à Família UNIMAR.

Educar para transformar: esse é o foco da Universidade de Marília no seu

projeto de Educação a Distância. Como dizia um grande educador, são
as pessoas que transformam o mundo, e elas só o transformam
se estiverem capacitadas para isso.

Esse é o nosso propósito: contribuir para sua transformação

pessoal, oferecendo um ensino de qualidade, interativo,
inovador, e buscando nos superar a cada dia para que você
tenha a melhor experiência educacional. E, mais do que isso,
que você possa desenvolver as competências e habilidades
necessárias não somente para o seu futuro, mas para o seu
presente, neste momento mágico em que vivemos.

A UNIMAR será sua parceira em todos os momentos de

sua educação superior. Conte conosco! Estamos aqui para
apoiá-lo! Sabemos que você é o principal responsável pelo
seu crescimento pessoal e profissional, mas agora você
tem a gente para seguir junto com você. Prof. Me. Paulo Pardo
Coordenador do Núcleo
Sucesso sempre! EAD da UNIMAR
007 Aula 01: Introdução à Teoria de Banco de Dados

016 Aula 02: Projeto de Banco de Dados

027 Aula 03: Banco de Dados Relacionais

039 Aula 04: Diagramas Entidades – Relacionamentos Complexos

052 Aula 05: Desenvolvimento de Banco de Dados

064 Aula 06: Linguagem SQL – Definição de Tabelas

073 Aula 07: Linguagem SQL – Consultas

083 Aula 08: Armazenamento e Consulta de Dados

104 Aula 09: Linguagem SQL – Variações em Consultas

114 Aula 10: Tópicos Complementares em SQL

127 Aula 11: Banco de Dados Orientados a Objetos e Banco de

Dados XML

142 Aula 12: Gerenciamento de Transações

151 Aula 13: Controle de Concorrência e Recuperação

162 Aula 14: Arquiteturas de Banco de Dados Paralelos e

Distribuídos

175 Aula 15: Banco de Dados Paralelos e Distribuídos

184 Aula 16: Tópicos Avançados e Mineração e Análise de Dados

Introdução
Olá, alunos! Bem-vindos à disciplina Banco de Dados.

Preparei este material apoiado na ideia de que sem um software para controlar suas
funcionalidades, um hardware acaba se tornando apenas um dispositivo
eletromecânico, praticamente sem nenhuma automatização e, assim, não existiria a
necessidade de programação como ocorre em máquinas de operação manual.

Vamos começar com uma breve introdução à teoria do banco de dados, as principais
linguagens de programação, processos e muito mais.

Bons estudos!

6
 01

Introdução à Teoria
de Banco de Dados
7
Alunos, os dados, como é comum se ouvir, são a base para a existência e para o uso
do banco de dados – que funciona como repositório para variadas quantidades de
dados, com propósitos igualmente variados.

Para o adequado armazenamento, organização e uso desses dados, foram

desenvolvidos os chamados Sistemas de Gerenciamento de Banco de Dados
(SGBD) que são excelentes recursos da Tecnologia da Informação (TI) para manter
grandes bases de dados organizadas com alto desempenho.

Existe uma necessidade natural de uso de hardware para o

armazenamento de dados, e mesmo com a ideia do uso da tecnologia de
armazenamento em nuvem, em algum lugar do planeta, os dados cam
sicamente armazenados e podem ser gerenciados por algum SGBD.

Numa época em que o uso massivo da Internet movimenta enormes volumes de

dados e permite que esses dados possam ser acessados praticamente de qualquer
lugar, o uso de sistemas para trabalhar com dados se tornou fundamental para o
mercado e para a sociedade, de forma que representa uma das grandes fatias de
vagas de emprego disponíveis para pro ssionais de TI.

8
Diversos setores se bene ciaram com o uso de sistemas que trabalham com banco
de dados, tais como nanças, transporte, educação, comunicações, compra e venda,
indústria e entretenimento, por exemplo. De tempos em tempos, inovações
tecnológicas geram novas possibilidades de uso desses sistemas, como vem
ocorrendo com o uso cada vez maior e mais bem ltrado de dados para os setores de
marketing, serviços e produção.

As inovações tecnológicas estão permitindo revoluções que ocorrem em todas as

áreas da TI e afetam os sistemas gerenciadores de banco de dados que, décadas
atrás eram simples, rodando em máquinas isoladas, ou no máximo, em redes locais
cabeadas, e décadas depois, funcionam em infraestruturas sem o, cobrindo grandes
distâncias através de tecnologias como a da Internet, e tendo recursos avançados
para tratamento de dados como a Inteligência Arti cial (IA) e mineração de dados em
geral para que dados existentes possam gerar novos dados.

Com estas inovações mais recentes aplicadas aos Sistemas SGBD, é possível adquirir
novos dados obtidos a partir de dados já existentes, decisões podem ser tomadas de
forma mais con ável e sistemas se tornam autônomos e inteligentes – o que é capaz
de reduzir a interação humana em muitas atividades.

Outra tecnologia que acompanhou e auxiliou o desenvolvimento e massi cação de

uso de banco de dados foi a de armazenamento de dados que, com o passar do
tempo, conseguiu aumentar muito a capacidade de armazenamento na proporção
inversa a uma constante busca por redução no tamanho físico dos dispositivos de
conservação, assim como melhorias em desempenho e con abilidade destes
dispositivos de hardware.

9
Com as evoluções tecnológicas ocorridas nas últimas décadas, a própria forma como
o mercado utiliza os dados e como os gerencia sofreu mudanças em função não
apenas das evoluções, mas de novas formas de oferta de serviços que permitiram ao
mercado trabalhar de forma diferente os Sistemas Gerenciadores de Banco de
Dados.

Empresas criaram serviços de armazenamento locais, que através de meios de

comunicação como a Internet, proporcionavam a custos variáveis, espaços de
armazenamento e infraestrutura para comportar dados puros ou sistemas inteiros
de gerenciamento de dados, de forma que as empresas não precisassem de grandes
investimentos em infraestrutura própria, sendo esta modalidade situada dentro da
chamada tecnologia em nuvem (cloud computing).

Algumas empresas criaram enormes infraestruturas de TI (data centers) para

armazenamento de dados e sistemas e acabaram se tornando grandes fornecedores
de serviços de cloud computing, sendo responsáveis pelo armazenamento de dados
de empresas de todos os setores e lugares do mundo.

O armazenamento de dados aumentou de volume de forma monstruosa

e o armazenamento destes dados gerou problemas em infraestruturas de
TI, pois necessitam, além de dispositivos de armazenamento muito
robustos, de hardware com bom poder de processamento. O futuro deste
segmento parece estar na nuvem, em que grandes empresas podem
oferecer serviço de qualidade com uma relação entre custo e benefício
bastante interessante. Leia em:

10
Pontos de atenção em Sistemas de
Gerenciamento de Banco de Dados
Sistemas do tipo SGBD possuem certas características comuns neste tipo de sistema
que se tornou a base das atividades do mercado de indústria, comércio e serviços,
além de muito do que está relacionado à sociedade. Silberschatz (2020) cita algumas
situações importantes que devem ser observadas em um SGBD e, na sequência,
estes pontos são trabalhados de forma a oferecerem uma maior compreensão de
como funcionam os sistemas de gerenciamento de banco de dados.

Uma das características relevantes em sistemas desse tipo se relaciona com a forma
como os dados são gerados e o controle sobre eles, pois é comum que dados
pessoais, por exemplo, sejam inseridos em diversos sistemas separados de empresas
distintas, mas possam também estar inseridos em bases de dados distintas numa
mesma empresa, com formatos diferentes e sem que uma base enxergue a outra.

Desta forma, ocorre a chamada redundância em dados que remetem à ideia de que
existam dados repetidos, mas não desnecessários, por estarem em bases distintas de
sistemas que não se comunicam, mas que em certos casos, poderiam ser otimizados
em sistemas que podem se comunicar.

Outro aspecto relevante é que um SGBD deve ser implementado como qualquer
outro software, seja ele desenvolvido por uma equipe própria da empresa, por uma
empresa terceira, ou comprado como software de prateleira, como são chamados
os softwares prontos comprados no mercado – como sistemas operacionais, por
exemplo. É que eles devem atender às demandas relacionadas ao cotidiano de
trabalho com os dados, mas solicitações pontuais podem não ser contempladas.

Um dos problemas relacionados é a chamada di culdade de acesso a dados

especí cos, geralmente ligados a ltros em consultas que geram relatórios resumidos
de interesses especí cos e que, por vezes, não fazem parte da implementação atual
do sistema. Neste caso, é comum que se obtenham relatórios próximos do desejado
contendo informações extras desnecessárias, mas de forma rápida, se possível,
pode-se optar pela solicitação de desenvolvimento do relatório especí co desejado.

Fica a critério de uma avaliação para se optar pela melhor solução nesse caso, pois
entram pontos a serem levados em consideração como a frequência com que este
relatório pode ser utilizado e os custos envolvidos em termos de tempo e valores
para as duas opções de solução para a demanda.

11
Outro ponto de atenção no desenvolvimento de um SGBD é que à medida que
aumenta de tamanho e complexidade, podem ser que dados de bancos diferentes
sob um mesmo sistema e armazenados em estruturas e formatos diferentes façam
com que atualizações no sistema que necessitem uni car esses dados sejam mais
complexos em sua implementação.

É importante citar que dados precisam se manter corretos no banco de

dados e, muitas vezes, diferentes componentes de um SGBD podem
aplicar regras distintas de validação sobre um mesmo dado ou um excluir
dados essenciais para outro subsistema do SGBD.

Essa chamada integridade também é complexa de ser administrada em sistemas

maiores, pois a documentação de sistemas grandes pode não ser uni cada e nem
consultada quando novos sistemas ou atualizações que aparentem ser
independentes de outros podem afetar esta integridade.

Também podem ocorrer problemas relacionados ao processo de manipulação de

dados que acontecem o tempo todo e que, por diferentes motivos, podem ser
interrompidos abruptamente, ocasionando riscos de perdas de dados de forma
parcial ou até de bases inteiras de dados. A chamada atomicidade tenta minimizar
estes problemas, mantendo pontos seguros de recuperação de dados antes de estes
processos ocorrerem, durante e até mesmo depois.

12
 Existem sistemas que permitem que diversos usuários ou processos
acessem a mesma base de dados de forma simultânea, e isto também
pode ocasionar problemas com dados, pois processos ocorrendo em
paralelo podem estar tentando acessar ou alterar um mesmo dado e
situações como a leitura de um dado desatualizado ou falha por
requisições que ocorrem exatamente no mesmo instante de forma
concorrente podem ser problemáticas também.

Outro aspecto importante em relação a sistemas de gerenciamento de banco de

dados é a segurança que, de forma geral, engloba muitos pontos, sendo alguns deles
relacionados às permissões de acesso de usuários que pode ser organizado em
níveis, proteção a invasões externas (ainda mais com a conexão com a Internet),
segurança física contra extravio de equipamentos de hardware em uma
infraestrutura, etc.

Conceitos Fundamentais
Os dados são uma representação virtual da realidade podendo se referir às
características de coisas reais como nomes, cores, valores, etc. e objetos podem ser
identi cados por um determinado conjunto de dados que o diferencie de outros
objetos.

Uma importante característica de um SGBD é que ele deve fornecer visões dos
dados, ou seja, meios para que esses dados sejam visualizados e modi cados dentro
da proposta do sistema.

Silberschatz (2020) cita que a chamada abstração de dados é utilizada para que
aquilo que é relevante do modelo real seja utilizado como base para os dados do
SGBD, e esta abstração envolve aspectos ligados ao nível físico e ao nível lógico do
problema, em que os dispositivos e métodos de armazenamento se referem à parte
física, e a organização dos dados e as relações entre eles estão no nível lógico, um
pouco mais elevado e perceptível do sistema.

13
Um terceiro nível, mais alto e visível, é o nível de visão no qual aquilo que é
necessário do SGBD é exibido em determinado momento, de forma ltrada e
adequada aos propósitos do sistema para os usuários.

A organização dos dados em um SGBD é feita através de estruturas de dados criadas

para que os dados possam ser armazenados e manipulados de forma correta e
adequada, partindo da estruturação do esquema que representa o termo associado
à própria estruturação do banco de dados, ao passo que todo o banco de dados
trabalha com base em instâncias que são os estados nos quais o banco de dados se
encontra em determinado momento, segundo Silberschatz (2020).

O termo esquema se aplica aos três níveis citados: físico, lógico e de visão, sendo que
no nível de visão é comum o uso do termo subesquema em função de poder existir
diferentes visões com base nos dados.

Outra parte importante do estudo de banco de dados são os modelos utilizados para
descrever dados e relações entre eles, de forma a permitir a de nição teórica dos
três níveis citados anteriormente, sejam físico, lógico ou de visão:

Modelo relacional: baseia-se em tabelas para organização de dados e

relacionamentos que interligam estas de forma a organizar toda uma estrutura
de dados.
Modelo entidade relacionamento (ER): baseia-se em modelar objetos reais
como elementos chamados de entidades e a forma como eles podem estar
interligados através de relacionamentos.
Modelo orientação a objetos: nele, de nem-se classes para a organização de
dados e métodos para trabalhar os processos que manipulam estes dados.
Modelo semiestruturado: utilizado em aplicações web com base em XML
(Extensible Markup Language), no qual dados podem ter conjuntos diferentes de
atributos.

14
A manipulação de sistemas de gerenciamento de banco de dados pode
ser feita por meio de uma linguagem especí ca para esta nalidade, como
é o caso da linguagem SQL. Pode-se dividir a linguagem em uma parte
para de nição de dados ou DDL (Data De nition Language) e outra parte
com comandos para a manipulação de dados ou DML (Data Manipulation
Language).

15
 02

Projeto de Banco
de Dados
16
Olá novamente!

O banco de dados possui uma nalidade aparentemente simples, ainda mais

pensando que sua nalidade essencial é apenas de se armazenar dados, mas, na
verdade, este armazenamento abrange toda a infraestrutura necessária para o
armazenamento do volume de dados esperado e imaginável, e toda a organização
lógica dos sistemas que vão gerenciar esses dados, sendo, então, um conjunto
relacionado à arquitetura do sistema.

Os dados podem ser armazenados em um repositório simples de dados apenas para

consultas, mas um SGBD pode também ser composto por subsistemas interligados
que gerenciam bases de dados compartilhadas ou não, podendo conter quantidades
muito grandes de dados e depender deles para a realização de um grande volume de
transações, como ocorre no comércio eletrônico (e-commerce).

No projeto de um banco de dados, a parte relacionada ao esquema é fundamental

dentro de um contexto no qual projetos complexos de grandes empresas ou
propósitos de uso podem exigir grande planejamento da estrutura de um banco de
dados.

17
Processo do Projeto
Partindo dos requisitos de nidos como necessidades que um SGBD deve atender,
esta representa a primeira e não menos importante fase do projeto de um sistema
gerenciador, sendo que a de nição dos requisitos de cada sistema são obtidos a
partir de entrevistas e outros meios que permitam que se descubram todas as
informações necessárias para se de nir um esquema para um banco de dados e o
mesmo represente, de forma adequada, as estruturas de dados que sejam
compatíveis com o que se espera do sistema.

Algum modelo de dados é escolhido e aplicado aos requisitos, de forma que um

modelo conceitual possa ser desenvolvido e partido deste, e um banco de dados
possa ser implementado para que dados sejam inseridos, armazenados e
manipulados sempre que desejado de forma segura e íntegra.

Na etapa conceitual é preciso que a estrutura a ser pensada leve em

consideração todos os aspectos envolvidos tais como redundâncias de
dados que possam ser resolvidas, relacionamentos entre tabelas ou
outras estruturas, a forma como acessados e processados os dados, e se
o sistema todo, parte dele ou nada do sistema será alocado na nuvem.

Pensando no modelo relacional, por exemplo, dentre outras ações, é preciso abstrair
do problema real, os dados e suas características a serem utilizadas para a
estruturação de tabelas, lembrando que nesta etapa de projeto inicial, não há nada
implementado ainda, e os custos de mudanças são insigni cantes em relação a
mudar tabelas em sistemas prontos e em uso.

O esquema desenvolvido deve ser el às regras de negócio que devem ser

contempladas pelo sistema e deve ser capaz de fornecer uma visão detalhada de
uma empresa segundo Silberschatz (2020), evitando con itos e especi cando
detalhes lógicos e não físicos nesta etapa.

18
Modelo Entidade Relacionamento
(ER)
Dentro da modelagem, o uso de diagramas entidade relacionamento pode se
constituir em um excelente material para auxiliar na modelagem de forma intuitiva e
de fácil compreensão, inclusive para clientes leigos que precisem compreender o que
está sendo desenvolvido para atender às suas demandas.

Esse modelo permite especi car, de forma conceitual, problemas reais por meio da
estruturação de entidades e relações que possam existir entre estas dentro da
proposta das regras de negócio que devem ser respeitadas no desenvolvimento de
um SGBD.

Entidades são representações virtuais de elementos reais como produtos, serviços,

pessoas, etc., sendo que estas entidades possuem atributos escolhidos dentre todo o
conjunto de características que estes elementos possuem, como cor, peso, altura,
idade, valor, dentre muitas outras que podem ser ou não relevantes para o contexto
de cada sistema a ser desenvolvido.

Os chamados atributos representam os dados que, porventura, serão armazenados

no sistema e estes precisam ser escolhidos e representados conceitualmente no
modelo através da escolha de nomes intuitivos e da de nição de qual domínio de
valores numéricos ou não serão aceitos por estes atributos.

Uma entidade então dita um conjunto de dados relativos às características de algo

real armazenadas em atributos, sendo então chamado de tupla em uma tabela de
dados, e o conjunto de todas as tuplas de dados que representam dados de diversos
elementos reais é chamado de conjunto de entidades, como num cadastro de
pessoas, de produtos, etc.

O conjunto de entidades pode ser subdividido, e um conjunto chamado, produtos

pode envolver produtos físicos em um subconjunto de entidades, e serviços em outro
subconjunto, mas isto não é obrigatório, pois por mais que possuam certa a nidade,
conjuntos de entidades podem se manter separados em um mesmo modelo ER.

A associação entre entidades, quando possível, é chamada de participação, sendo

que essas entidades participam de um relacionamento entre si e, segundo
Silberschatz (2020), uma instância em um relacionamento assim dentro de um
esquema ER, seria equivalente a uma tupla de dados de cada tabela que tenham
relacionamento entre si no sistema, como no caso de uma determinada pessoa que
compra certo produto da empresa.

19
Um termo utilizado na modelagem ER é o papel da entidade, dado a uma entidade
que participe de um relacionamento, sendo o termo utilizado para identi car
entidades que estejam em um mesmo conjunto de entidades, mas que em
determinadas situações, assume diferentes situações, como no caso de pessoas em
um cadastro de colaboradores em que cada uma tem uma função especí ca dentro
da hierarquia da empresa (vendedor, gerente, nanceiro, etc.).

Existe a possibilidade de um relacionamento entre entidades e necessitar de um

dado adicional para que seja mais completo em seu signi cado, e que não esteja
contido em nenhuma das entidades, como poderia ocorrer no caso de uma entidade
pessoa se relacionar com outra entidade evento e ser adicionado um chamado
atributo descritivo inscrito para que seja indicado se uma pessoa se inscreveu num
evento ou não, mas este atributo não seria adequado para nenhuma das entidades
em separado, mas apenas para este especí co relacionamento.

Geralmente, os relacionamentos são ditos binários, ou seja, envolvem duas

entidades em uma ligação direta entre ambas em função da obtenção de uma
determinada informação. No entanto, podem ocorrer casos em que um
relacionamento envolva mais entidades, como no caso de uma pessoa estar inscrita
em determinada turma para assistir determinada disciplina, ministrada por um
professor especí co, resultando na combinação de pessoas (aluno e professor),
turma e disciplina, que podem todas ser entidades separadas por não
compartilharem atributos entre si, apenas em relacionamentos propostos.

20
 pessoa curso

código_p nome_p função_p código_c nome_c turno_c

1 João Aluno 1 TI M

2 Pedro Professor 2 Letras T

3 Marta Aluno

disciplina

código_d nome_d crédito_d

1 Matemática 10

2 Português 10

Fonte: O autor.

Na imagem anterior, são exempli cados três conjuntos de entidades que podem se
relacionar devido à geração de alunos matriculados em turmas com professores
vinculados e, assim, gerar um relacionamento entre entidades que poderiam ser
exempli cadas, com o aluno João matriculado na turma A, do turno da manhã, do
curso de Letras, com o professor Pedro, por exemplo, mas observando os dados, é
preciso que seja gerado um relacionamento que contenha algum meio de unir estas
entidades diferentes do modelo e, então, pode-se pensar em atributos descritivos
para identi car as turmas com alunos matriculados.

O relacionamento poderia conter um atributo identi cador, número de chamada

para associar alunos a uma turma e, nesta turma, estariam indicados os atributos
código_p, código c e código_d identi cadores únicos das entidades.

21
Com isto, poderia ser gerada uma turma 1 a partir do relacionamento das entidades,
e o aluno 1 da chamada poderia ser João (código_p = 1) e o aluno 2, Marta (código_p =
3), ambos inscritos na disciplina de Matemática (código_d = 1), no curso de TI, no
período da manhã (código_c = 1).

Neste relacionamento poderiam ser armazenados apenas os atributos códigos de

cada entidade, pois através destes códigos é possível se obter todos os demais
dados, se necessário, sendo então estes códigos conhecidos como atributos de chave
da entidade.

Os atributos podem ser chave de uma entidade ou não, sendo que os atributos chave
não podem, de forma alguma, receberem dados repetidos, pois ocorreria perda de
integridade do banco de dados.

Pode acontecer de a chave ser formada por mais de um atributo e, neste caso, um ou
outro dos atributos que compõem a chave chamada composta pode receber dados
iguais, mas o conjunto de atributos da chave composta de uma entidade nunca pode
ser igual ao de outra entidade.

Atributos podem conter um valor único como é o caso da maioria dos atributos
de nidos em relações, mas podem ocorrer casos em que atributos podem conter
valores múltiplos, como no caso de uma pessoa poder possuir um ou mais números
de telefone, veículos ou endereços, por exemplo.

Existem os chamados atributos derivados, obtidos a partir de outros atributos da

entidade, como no caso da idade que pode ser obtida a partir da data de nascimento,
ou do endereço parcial que pode ser obtido a partir do CEP. Atributos também
podem não conter dados em uma entidade e assumirem valor nulo para a indicação
ao banco de que o atributo não teve dado associado a ele, como no caso do cadastro
de uma pessoa que não possua telefone pessoal ou veículo próprio.

Um ponto importante é observar como ocorrem as relações entre entidades, pois há

casos em que uma entidade de um conjunto de entidades pode se relacionar com
apenas outra entidade de outro conjunto de entidades ou do mesmo conjunto, mas
há casos em que se pode relacionar com mais de uma entidade do mesmo ou de
outro conjunto de entidades.

Isto é chamado de cardinalidade e pode ocorrer de quatro formas básicas:

22
 a primeira é chamada um-para-um e ocorre quando uma entidade
de um conjunto de entidades A se relaciona com apenas uma
entidade de outro conjunto de entidades B, por exemplo.
a segunda é chamada de um-para-muitos e ocorre no caso em que
uma entidade do conjunto A se relaciona com mais de uma
entidade do conjunto B.
a terceira forma de cardinalidade é a muitos-para-um, que ocorre
da forma inversa da anterior, na qual várias entidades do conjunto
A podem se relacionar com apenas uma entidade do conjunto B.
a quarta é a muitos-para-muitos, pois permite que haja
relacionamento entre várias entidades do conjunto A com várias do
conjunto B e vice-versa, ilustrando casos em que é comum a não
exclusividade das relações entre entidades como em locações de
veículos onde pessoas alugam carros, sendo que um carro pode ser
locado por várias pessoas e uma pessoa pode locar diferentes
carros.

Inicialmente, é fundamental compreender os conceitos de entidades e

atributos, para que se possa depois compreender como são construídos
os relacionamentos entre entidades e estes possam gerar modelos que
sirvam de base para a estruturação de propostas de desenvolvimento de
um SGBD.

23
Diagrama Entidade Relacionamento
A construção do modelo ER não é apenas textual ou baseado em tabelas, mas pode
conter diagramas estruturados de maneira que as diferentes formas utilizáveis na
construção de diagramas sejam todas úteis e bem diferenciadas em suas funções.

Para a construção dos diagramas ER, utilizam-se:

Retângulos para conjuntos de entidades:

Elipses para atributos:

Losangos para conjuntos de relacionamentos:

Linhas simples para ligar elipses a retângulos (e estes a losangos):

Elipses duplas para atributos múltiplos:

Elipses tracejadas para atributos derivados:

Linhas duplas para entidades totalmente inseridas em retângulos:

Retângulos duplos para as chamadas entidades fracas:

Imagem 4

nome_cli
cod prod
cod cli prod desc

Cliente Venda Produto

Quantidade

Fonte: O autor.

Na imagem 4, temos um exemplo de diagrama Entidade_Relacionamento em que um

conjunto de entidades “cliente” com os atributos cod_cli e nome_cli se relaciona com
outro conjunto de entidades “produtos” com os atributos cod_prod, prod_desc e

24
“quantidade”.

Reforçando, neste diagrama, existe uma relação “venda” em forma de losango

ligando os conjuntos de entidades “cliente” e “produto” em retângulos, sendo que
ambos possuem seus respectivos atributos em elipses também ligadas por linhas
simples.

Um ponto importante a ressaltar no diagrama é que os atributos-chave

que não se repetem e identi cam as entidades estão sublinhados (cod_cli
e cod_prod) para que quem destacados e são facilmente identi cáveis.

Imagem 5

nome_cli
cod prod
cod cli prod desc

Cliente Venda Produto

Telefone Quantidade
Idade
data_nasc

Fonte: O autor.

Neste outro exemplo, da imagem 5, foram adicionados os atributos “telefone” como

atributo múltiplo que aceita zero ou mais dados, data_nasc como atributo comum
adicional e “idade” como atributo derivado, que pode ser obtido a partir de
data_nasc.

Com isso, foram apresentados os conceitos mais comuns de desenvolvimento do

modelo entidade relacionamento, mas ca indicada a pesquisa na bibliogra a da
disciplina e outras boas fontes de consulta para que se possa aprofundar dessa
forma de modelagem bastante tradicional e utilizada no mercado.

25
Para compreender como são estruturados os diagramas ER, é
interessante pesquisar diagramas prontos a m de identi car os
diferentes símbolos, interpretá-los e entender por que foram escolhidos
na elaboração do diagrama. Outra forma de aprender melhor o uso dos
diagramas é imaginar modelagens diversas e tentar criar diagramas
utilizando os símbolos que julgar adequados e, no nal da criação,
observar se o diagrama é compreensível em sua proposta e se os
símbolos parecem adequadamente utilizados.

26
 03

Banco de Dados
Relacionais
27
Olá, alunos!

Com base no modelo relacional, o banco de dados relacionais trabalha com base em
estruturas organizadas em tabelas que de nem quais dados e características (ou
atributos) devem ser aceitos e como devem ser inseridos.

Dois pontos importantes a serem considerados são que a linguagem SQL costuma
ser a linguagem base para uso em um SGBD e que se baseia em comandos dos
tipos DDL e DML para a de nição dos dados e sua manipulação, respectivamente.

Tendo como base o uso de tabelas que são formadas por linhas e colunas numa
estrutura bidimensional, cada coluna de uma tabela representa um tipo de dado
de nido por certas características, sendo que o conjunto das colunas é a
representação de uma ocorrência do que está sendo representado pela tabela, seja
um cadastro de pessoas, veículos, vendas, etc.

As linhas de uma tabela são mais variáveis em quantidade, sendo que

cada linha é equivalente a uma ocorrência de um conjunto de dados que
identi ca uma pessoa, veículo ou venda, como citado e, assim, duas
pessoas podem ter seus dados cadastrados em duas diferentes linhas de
uma tabela.

Para criar tabelas, é preciso conhecer, por exemplo, os comandos DDL da linguagem
SQL para de nir as características dos campos de uma tabela de forma que recebam
dados adequados aos requisitos de nidos em regras de negócio ou outras regras
que de nam quais tipos de dados serão armazenados.

Segundo Silberschatz (2020), um modelo de dados é uma representação formal da

descrição de um conjunto de dados a partir de ferramentas próprias para a descrição
dos dados e suas relações, além de outros aspectos envolvidos e necessários.

Com base no uso de tabelas representativas da estrutura montada para o

armazenamento organizado de dados nas colunas, têm-se as linhas utilizadas para
armazenar cada conjunto de dados relacionados entre si e representativos de um
objeto, por exemplo. Os aspectos preocupantes citados anteriormente, tais como
integridade dos dados e atomicidade das operações realizadas com os dados, são
tratados neste modelo de trabalho com banco de dados.

28
Uma tabela pode ser gra camente representada, como mostra a imagem 7, que traz
uma tabela de cadastro de produtos em um banco de dados hipotético qualquer,
sendo que a primeira linha desta tabela representa títulos que nomeiam as colunas
de dados, servido de referência para eles e sendo chamados de atributos.

Imagem 7

CÓDIGO DESCRIÇÃO QUANTIDADE

1 PRODUTO A 100

2 PRODUTO B 200

3 PRODUTO C 300

Fonte: O autor.

Neste exemplo da imagem 7 temos, então, os atributos CÓDIGO, DESCRIÇÃO e

QUANTIDADE, que servem apenas como referência para as colunas e dados que,
posteriormente, poderão ser armazenados nela. A escolha dos nomes é livre, e o uso
de nomes escolhidos de forma intuitiva a facilitar a compreensão dos dados
armazenáveis na tabela é bastante útil para posterior continuidade do projeto e
desenvolvimento do banco de dados.

Os tipos de dados permitidos em cada atributo geram um conjunto de valores

aceitáveis chamados de domínio de cada atributo, lembrando que para alguns
atributos, a quantidade de valores distintos aceitos pode ser in nita, como no caso
de nomes de pessoas, onde existe um sem m número possível de combinações de
nomes, mas pode delimitar faixas de valores aceitos como dias da semana, altura,
peso ou idade de pessoas.

É comum que sejam usados os termos relação para se referenciar tabelas e tuplas
para linhas da tabela, ou seja, em uma relação, uma tupla é o conjunto de dados
relacionados entre si que delimitam um objeto real representado, podendo-se
também utilizar o termo registro para linhas.

29
Um aspecto importante é que na tabela, a ordem das tuplas é determinada pela
ordem de inserção das mesmas na tabela ou outra regra como a ordenação dos
dados de determinado atributo, como no caso dos dados de CÓDIGO, no exemplo da
imagem 7.

As tabelas são a base estrutural do banco de dados relacionais e sua

compreensão se torna essencial para o prosseguimento dos estudos.
Existem variações nos meios de se trabalhar com banco de dados, mas
em geral, os bancos de dados deste tipo são armazenados por sistemas
SGBD, como os oferecidos sob os nomes de Oracle ou MYSQL.

Definição de Esquemas de Banco de

Dados
Um esquema de um banco de dados, segundo Silberschatz (2020), representa o
projeto lógico de um banco de dados e a instância, a situação dos dados contidos no
banco em determinado instante. Ainda, de ne os termos relação representando ideia
semelhante à de variáveis de armazenamento de dados em programação, e esquema
de relação se referindo às de nições de tipos de dados para relações.

Geralmente, são de nidos nomes iniciados com letras maiúsculas para esquemas de
relação e com letras minúsculas para relações. Veja um exemplo deste padrão de
nomenclatura:

30
 Esquema_produtos = (código_produto, descrição_produto,
quantidade_produto)

Observe que uma forma de de nir um esquema para a tabela imaginada no exemplo
da imagem 7 mantém os mesmos nomes para as relações em relação aos atributos
da tabela, gerando um nome para o esquema que contém estas relações. Uma
relação produtos pode, então, ser de nida como no esquema de esquema_produtos,
em que a ideia de um esquema de relação pode ser uma representação dos atributos
e domínios de nidos para estes atributos Silberschatz (2020).

Sendo uma instância o estado do banco em determinado momento, o exemplo da

imagem M traz, além da estrutura da tabela, dados contidos na mesma em três
tuplas, representando a instância daquele momento. Se mais dados forem inseridos
ou dados forem alterados ou removidos, uma nova instância pode ser obtida com
novos dados constantes na tabela, assim como ltros utilizados sobre a tabela, de
forma a trazer apenas dados desejados para determinada nalidade, gerando novas
instâncias também.

Os esquemas vão sendo criados de acordo com as necessidades do sistema, e

baseando-se na tabela do exemplo da imagem 7 é possível criar novos esquemas
para ações envolvendo ações relativas à manipulação dos atributos dela, de forma

31
que se possam realizar as ações básicas de criação da tabela, inserção de dados,
leitura de dados, alteração ou até exclusão de dados.

Com base no esquema de relação esquema_produtos, podemos criar novos

esquemas para algumas ações envolvendo ações relacionadas aos atributos como os
indicados a seguir:

Esquema_descrição = (código_produto, descrição_produto)

Esquema_quantidade = (código_produto, quantidade_produto)

Esses dois esquemas de relação podem ser a base para processos de inserção ou
leitura de dados especí cos do banco de dados, com o objetivo de evitar que
informações redundantes ou desnecessárias sejam utilizadas e, por isso, num dos
esquemas de relação se utiliza o atributo descrição_produto e no outro apenas
quantidade_produto, mas ocorre a dúvida em relação ao atributo código_produto
que aparece nos dois esquemas de relação.

Existem algumas operações que são adaptadas da área da matemática,

da álgebra, relacionadas para trazer funcionalidades às estruturas de
banco de dados que funcionam como conjuntos de subconjuntos de
elementos, imaginando cada subconjunto como uma tabela. Operações
como a de seleção de tuplas, a partir de critérios de seleção, união de
dados de tabelas distintas para obter resultados agregados, intersecção
de dados de tabelas distintas para veri car resultados mais especí cos,
etc.

32
Chaves
É comum que, em todos os processos de uso de dados de um banco de dados, um
ou mais atributos sejam utilizados, além daqueles realmente desejados, pois algo
fundamental na estrutura de uma tabela são atributos que servem a um propósito de
organização estrutural e ordenação das tuplas.

Esta organização é importante para otimizar processos, pois se um banco está

organizado e com seus dados ordenados sob algum critério, seu uso é mais ágil em
termos de desempenho nas buscas por dados, principalmente, à medida que esta
base aumente e exista uma tendência natural aos processos irem se tornando mais
lentos com este crescimento na base de dados.

Estes atributos das tabelas que são necessários para sua organização são chamados
de chaves e possuem uma característica importante associada a elas que é a de não
permitirem repetição de dados. Todavia, há casos em que um atributo considerado
chave possa armazenar dados repetitivos, mas isso só deve acontecer em casos em
que a chave da tabela seja formada por este atributo e um ou mais outros atributos
que juntos não permitem a repetição de um mesmo grupo de dados nas tuplas da
tabela.

Sem essas chaves, certamente, ocorreriam problemas graves de

identi cação de dados, e um exemplo simples e direto disso seria se
numa tabela, o número de CPF de pessoas cadastradas fosse a chave e
fosse comum a repetição desse número para pessoas diferentes.

Para de nir melhor as chaves, utiliza-se o termo superchave para o atributo único
ou conjunto de atributos que possuem a função de ordenar os dados de uma tabela
e identi car individualmente cada tupla. Mas um ponto importante é que uma
superchave possui apenas os campos realmente necessários para ordenação dos
dados e, assim, é preciso atender ao princípio de que qualquer subconjunto de
atributos de uma superchave não pode ser considerado uma superchave também,
pois, neste caso, o menor conjunto seria o mais adequado como superchave.

33
Numa tabela, podem existir mais de um conjunto de superchaves possíveis e estes
conjuntos com um ou mais atributos, reforçando, são chamados de chaves
candidatas, e dentre estas, uma superchave é escolhida. Um ponto de atenção é que
subconjuntos de chaves candidatas não podem ser também chaves candidatas, pois
foge ao conceito essencial de superchave.

Dentre as chaves candidatas, uma é escolhida como superchave para a tabela e, a

partir desse momento, passa a ser chamada de chave primária, sendo formada por
um único atributo ou mais, pois a chave primária necessita identi car
individualmente as tuplas, independentemente da quantidade de atributos
necessários.

Outro aspecto que envolve a escolha de uma chave primária é que depois de
escolhida e implementada esta chave, é recomendável que os atributos dela não
tenham seus dados modi cados, pois isso pode gerar chaves com dados repetidos,
ferindo o propósito de sua escolha, o que pode acontecer mais facilmente em chaves
compostas por mais de um atributo.

Um conceito importante do uso de atributos como chaves é que uma tabela pode se
relacionar com outra, e isso é possível por meio de vínculos criados entre atributos
destas tabelas, de forma que quando ocorrerem repetições dos dados destes
atributos nestas tabelas, exista realmente uma ligação nesta repetição, mas isto deve
também ser estruturado com cuidado.

34
Um caso hipotético adequado seria um SGBD de uma empresa de vendas de
produtos, por exemplo, em que tabelas possam ser de nidas para o armazenamento
de dados relativos a clientes, compras, vendas, etc. Para estruturar um sistema assim,
de forma adequada e reduzindo redundâncias, os dados necessários para realizar os
processos deste negócio devem ser organizados em uma ou mais tabelas, a partir da
análise de situações de uso destes dados e escolha da melhor forma de estruturação
do banco para otimizá-lo.

Um sistema assim certamente deve possuir algo que possa cadastrar vendas, e estas,
geralmente, associam dados de clientes realizando as compras, os produtos
adquiridos e outras informações complementares como data, valores, etc. Um cliente
pode retornar ao local para novas compras ou não, mas um sistema deve prever esta
possibilidade, assim como um determinado produto pode ser adquirido pelo mesmo
cliente mais de uma vez, e também por outros clientes e, assim, começa o processo
de se estruturar um modelo para um SGBD. Neste processo, as relações entre
tabelas precisam ser muito bem desenvolvidas, pois toda a integridade do banco de
dados e o correto propósito do mesmo podem ser prejudicados por más escolhas
feitas nesta etapa.

Para gerar essas relações entre tabelas é preciso utilizar as chaves primárias
de nidas no processo de estruturação do banco e, assim, partindo do exemplo do
sistema de vendas, pode-se imaginar que as vendas podem ocorrer com ou sem a
geração de nota scal, dependendo do tipo da venda e da empresa que utilizará o
sistema. Para evitar esta inde nição para certos tipos de atividades comerciais, pode-
se usar como chave primária um valor numérico inteiro, simples, para que sejam
gerados códigos sequenciais automáticos a cada nova venda, garantindo, assim, a
não duplicidade de chaves.

Um ponto importante a ser observado e que será explorado mais adiante é que pode
ocorrer de um mesmo cliente comprar mais de uma vez e suas vendas serem
lançadas no sistema da mesma forma que seria feito com clientes diferentes que
realizaram compras diferentes. Para economizar dados armazenados no banco e
assim reduzir a redundância de dados, é possível usar de um importante recurso na
elaboração de um modelo relacional, que é agrupar atributos relacionados entre si
em uma tabela junto com outros agrupamentos de dados – lembrando que todas as
tabelas geradas devem ter chaves primárias de nidas.

Estas chaves primárias são essenciais na de nição de relacionamentos entre tabelas,

pois por meio delas, dados de uma tabela são associados com outra tabela a partir
do uso dos atributos que formam a chave primária em uma tabela como atributos
comuns em outra, e estes atributos replicados são chamados de chaves

35
estrangeiras. Esta relação é chamada de relação estrangeira, e a ocorrência de
dados iguais na chave primária de uma tabela e na chave estrangeira de outra indica
a ocorrência de uma relação entre as respectivas tuplas das duas tabelas.

Um exemplo seria pensar num cadastro de clientes em uma tabela usando um

código para cada cliente que seja numérico sequencial automático, mas poderia ser
imaginado o uso do número de CPF como chave primária para cada cliente
cadastrado, o que poderia restringir cadastros de clientes em casos especí cos, como
o de clientes que não estão portando documentos no momento do cadastro de uma
compra e não têm meios para obter esse dado naquele momento. A associação,
então, seria feita com a inserção deste código de cliente numa venda realizada de
forma a associar à venda apenas este dado chave do cadastro de clientes ao invés
realizar repetidas vezes todo o cadastro de dados todas as vezes que o cliente
realizar compras.

Além de facilitar as vendas, também se atenua a redundância nos dados pessoais de

clientes no sistema, pois em cada venda realizada, apenas o código dos clientes é
adicionado aos registros de vendas feitas. Observe a imagem 8 para ter uma ideia de
como poderiam ser modeladas as tabelas em um chamado diagrama de esquemas
neste exemplo.

Imagem 8
Clientes Vendas
Código_cliente Código_venda
Nome_cliente Descrição_produto
CPF_cliente Quantidade_produto
Telefone_cliente Preço_produto
Endereço_cliente Código_cliente

Fonte: O autor.

No exemplo da imagem 8, uma relação é de nida entre a chave primária

Código_cliente da tabela Clientes e a chave estrangeira de mesmo nome na tabela
Vendas, reforçando que o uso do mesmo nome nas duas tabelas permite uma
associação mais intuitiva entre as tabelas e indicação da relação entre os dois
atributos das tabelas.

Um ponto que pode chamar a atenção é o porquê de o campo chave primária da

tabela Clientes ser chave estrangeira na tabela Vendas, mas o campo chave primária
da tabela Vendas não ser chave estrangeira na tabela Clientes. Isso porque é preciso

36
veri car que, neste exemplo, uma venda pode ser realizada para apenas um cliente,
mas um cliente pode realizar muitas compras, caracterizando uma relação dita 1 para
N (ou uma para muitos).

Existem casos em que existe uma relação do tipo 1 para 1 como no caso de
casamentos, nos quais uma pessoa se casa com apenas uma outra, para ns de
registro civil, mas também podem existir relacionamentos N para N (ou muitos para
muitos) ainda, em casos como o de pessoas se alimentando em praças de
alimentação onde os estabelecimentos podem atender mais de um cliente, e estes
clientes podem ser atendidos por vários estabelecimentos.

Uma forma bastante e ciente de se praticar a elaboração de modelos de banco de

dados relacionais é partir de problemas reais simples e tentar obter as informações
necessárias para se modelar diagramas de esquemas. Um exemplo seria imaginar
como poderia ser modelado um diagrama de esquema para uma locadora de
veículos, no qual é preciso cadastrar veículos e realizar locações para clientes
diversos.

Poderia ser obtido um primeiro esboço simples de diagrama com algumas tabelas e
atributos essenciais como uma primeira proposta a ser complementada e ajustada
até que se obtenha um modelo aceitável para a de nição formal de um SGBD como
se pode observar na imagem 9.

Imagem 9
Veículos Locações
Código_veículo Código_locação
Renavam CPF_cliente
Descrição_veículo Nome_cliente
Quilimetragem_rodada Data_retirada
Observações Data_devolução
Código_veículo

Fonte: O autor.

Neste exemplo da imagem 9 é possível observar que são de nidas duas tabelas para
o cadastro de veículos e controle de locações, nas quais os atributos Código_veículo
e Código_locação são chaves primárias, e o atributo Código_veículo é repetido na
tabela de Locações como chave estrangeira para permitir o relacionamento entre as
tabelas.

37
O uso de diagramas de esquemas auxilia visualmente na compreensão da
estrutura de um banco de dados, pois ilustra as tabelas com seus
atributos e as relações de nidas entre estas tabelas, facilitando a
compreensão dos exemplos. É importante observar que a chave
estrangeira é ligada a uma chave primária através de uma seta com a
ponta apontando para a chave primária, de forma a indicar qual é o papel
de cada atributo incluído na lista em relação à tabela na qual está
inserido.

38
 04

Diagramas Entidades
– Relacionamentos
Complexos
39
O uso de diagramas Entidade Relacionamento (ER) proporciona um meio bastante
e ciente de se modelar banco de dados relacionais, tendo diferenciais para a
especi cação de banco de dados bastante éis às regras de negócio e ideia de
como poderia ser uma solução para o armazenamento de dados para determinado
negócio.

Nas aulas anteriores, estudamos os conceitos fundamentais utilizados em

praticamente todos os bancos de dados projetados, mas existem especi cidades
em vários casos que necessitam de formas variantes disponíveis para a elaboração
dos diagramas ER.

Lembrando que os elementos básicos de um diagrama são o retângulo,

que representa uma entidade, o losango, um relacionamento entre
entidades, e as elipses, em geral, os atributos. É importante analisar as
situações importantes que envolvem esses elementos.

A representação de relacionamentos é um importante ponto e pede atenção nos

diagramas, pois indica como ocorrem as ligações entre entidades, e como existem
diferentes formas de isto ocorrer, também há diferentes formas de se representar
estas diferentes relações entre conjuntos de entidades.

As entidades podem se relacionar de quatro formas distintas, sendo uma em que

uma entidade de um conjunto de entidades só pode se relacionar com uma
entidade de outro.

Outras três formas são relacionamentos de uma entidade de um conjunto com

várias entidades de outro, várias entidades de um conjunto com apenas uma
entidade de outro e, por m, várias entidades podendo se relacionar com outras
várias de outro conjunto, simultaneamente. Estes relacionamentos são chamados
de 1 para 1, 1 para muitos, muitos para 1, e muitos para muitos.

40
Até então, a representação deste tipo de variação de relacionamento não era
indicada no diagrama, sendo apenas utilizada a linha simples para esta
representação geral, mas de agora em diante, a adição de setas nas linhas em
relacionamentos irá possibilitar a diferenciação dos quatro tipos. Observe a Figura
1 para conhecer as indicações de tipos de relacionamentos.

Figura 1

1 2
A

1 2
B

1 2
C

1 2
D

Fonte: O autor.

Nas ilustrações da Figura 1, podemos observar o uso de setas nas linhas que ligam
alguns dos elementos, servindo de diferenciador entre os quatro tipos de
relacionamentos.

41
A seta sempre aponta para o relacionamento equivalente a 1, ou seja, aquela
entidade de um conjunto que é a única que se relaciona com uma ou mais
entidades de um outro conjunto.

Nos exemplos indicados na Figura 1, temos então o relacionamento

indicado por A, como sendo muitos para muitos, pois não há seta em
nenhuma extremidade da linha que indica o relacionamento.

Na letra B, estando a seta na entidade à esquerda (1) apenas, temos um

relacionamento 1 para muitos, onde uma entidade do conjunto à
esquerda é a única que se relaciona com uma ou mais entidades do
conjunto à direita (2) e, assim, a restrição ca por conta das entidades
do conjunto 2 só poderem ter relacionamento com uma entidade
apenas pertencente ao conjunto 1.

No exemplo da letra C, estando a seta apontada para o conjunto 2,

temos um relacionamento muitos para 1 que signi ca que muitas
entidades do conjunto 1 podem se relacionar com apenas uma
entidade do conjunto 2, sendo então impossível mais de uma entidade
do conjunto 2 se relacionar com uma mesma entidade do conjunto 1.

Por m, no exemplo D, existem setas nas duas extremidades da linha,

indicando um relacionamento 1 para 1, onde cada entidade de
qualquer um dos dois conjuntos pode apenas se relacionar a uma
entidade do outro conjunto, criando relacionamentos exclusivos entre
entidades de cada conjunto.

42
Figura 2

1 2

Fonte: O autor.

A Figura 2 traz um conceito a ser reforçado que é o de atributos que podem ser
adicionados em relacionamentos de forma a complementar ligação entre
entidades de dois conjuntos diferentes 1 e 2, de maneira que este atributo seja
independente das entidades em si, mas relevante a um relacionamento entre estas
entidades, como seria a data em uma venda, que não faz sentido ser associada
diretamente a um cadastro de clientes e nem ao de produtos.

Outro conceito incluso na Figura 2 é o de que é possível que entre uma entidade e
um relacionamento existam variantes na forma como a entidade se comporta,
devido ao contexto dos dados das entidades, e casos como o de cadastro de
pessoas que possuam diferentes funções em uma empresa, a forma como estes
cargos se comportam no relacionamento podem variar entre 1 e muitos.

Sobre a cardinalidade, existe uma indicação adicional que pode ser útil por indicar
os chamados limites de borda entre entidade e relacionamento que indica as
cardinalidades mínima e máxima permitidas, como se pode observar no exemplo
da Figura 3.

Figura 3

1..1 0..*
1 2

Fonte: O autor.

43
Neste diagrama da Figura 3, os limites de borda entre a entidade 1 e o
relacionamento do tipo 1..1 indicam que é obrigatória uma única entidade para
cada relacionamento, e nos limites de borda da entidade 2 com o mesmo
relacionamento está especi cado que a entidade 2 pode não ter nenhum ou vários
relacionamentos nesta situação.

Uma escolha que pode ser importante na modelagem de um projeto de

banco de dados a de nição de algo como um conjunto de entidades
com seus atributos ou um relacionamento entre conjunto de entidades
podendo agregar atributos descritivos, se necessário. Esta decisão
depende muito da análise de cada situação e de como isto impacta a
estrutura de todo o projeto, pois são propostas distintas.

Um conjunto de entidades é independente e possui seus atributos comuns, tendo

uma chave primária de nida, ao passo que um relacionamento não existe por si só,
mas depende de ao menos dois conjuntos de entidades que compartilhem
atributos com a relação de forma a estruturá-la, e isso gera uma economia no
volume de dados armazenados, mas apenas se for possível a de nição de uma
estrutura de relacionamento a partir de conjuntos de entidades já de nidas.

O uso de mais relacionamentos aumenta a complexidade do banco de dados,

ainda mais se forem adicionados atributos descritivos, mas pensar em banco de
dados com vários conjuntos de entidades e poucos relacionamentos pode gerar
relacionamentos entre três (ternários) ou mais (enários) conjuntos de entidades, do
que o uso de mais relacionamentos entre apenas dois conjuntos de entidades
(binários).

Há casos em que não se podem estruturar bancos apenas com relacionamentos

binários, mas sempre que possível, os binários tendem a simpli car a compreensão
e desenvolvimento de sistemas gerenciadores para a manipulação de dados.

44
A correta escolha de posicionamento de atributos também é importante, como já
citado, e sempre deve ser observada a lógica de cada atributo estar associado
diretamente a uma entidade, como uma característica ou ser um atributo
descritivo, que é usado apenas quando ocorre um relacionamento entre duas
entidades e este atributo contribui com a identi cação da tupla de relacionamento.

A de nição de conjunto de entidades é algo bastante intuitivo,

dependendo muito de uma boa compreensão das regras de negócio
para uma adequada visualização de como seriam estruturadas as
entidades. Já os relacionamentos e suas variantes em termos de
cardinalidade e a indicação de cardinalidades mínima e máxima podem
ser menos intuitivos e necessitar de mais tempo de trabalho sobre as
regras de negócio e experimentação de de nição de relacionamentos
entre os conjuntos de entidades de nidos.

Conceitos Complementares
Os conjuntos de entidades são formados por atributos, e dentre estes atributos,
geralmente, um ou mais são selecionados para comporem a chamada chave
primária a partir de chaves candidatas, mas pode haver casos em que não haja um
conjunto adequado para se obter uma chave primária que garantidamente seja
única em cada entidade.

45
Conjuntos de entidades com chaves primárias são chamados de fortes, ao passo
que conjuntos de entidade em que não seja possível de nir uma chave primária
são ditos fracos como no caso de um conjunto de entidades com os atributos
número_parcela, nome_cliente e valor_pago, em que quaisquer dos campos
podem ter dados repetidos, e uma entidade pode ser igual à outra, pois para todos
os clientes, as parcelas são numeradas, sequencialmente, a partir do mesmo
número.

Para que se possa manter uma estrutura funcional em um banco de dados com
casos assim, é preciso que este conjunto de entidades fraco esteja relacionado com
um conjunto de entidades forte que será designado como identi cador para o
fraco.

Figura 4

1 2

Fonte: O autor.

No diagrama da Figura 4, é ilustrada a situação do conjunto de entidades fraco 1 e

um relacionamento de dependência com um conjunto de entidades forte 2
identi cador para que seja gerada uma estrutura válida e funcional.

Outro conceito complementar importante é o de especialização, no qual dentro de

um conjunto de entidades, possam existir diferentes tipos de entidades que
possuem atributos em comum, relacionadas às suas características básicas, mas
estas entidades podem se diferenciar em algumas características particulares de
um subconjunto e outro, criando a possibilidade de se dividir um conjunto de
entidades.

46
Figura 5

1a 1b

Fonte: O autor.

Neste diagrama da Figura 5, é possível observar que o diagrama possui um

conjunto de entidades 1, mas logo abaixo, uma nova forma (triângulo invertido)
que intermedia uma conexão com outros dois conjuntos de entidades 1a e 1b.

Este triângulo invertido representa a especialização que faz com que o conjunto de
entidades 1 seja subdividido em outros conjuntos de entidades 1a e 1b que
possuem as mesmas entidades do conjunto 1, mas separadas contendo os seus
atributos especí cos.

Há casos nos quais a estruturação dos conjuntos de entidades é construída e

depois de alguns conjuntos estarem de nidos, é percebido que dois ou mais
conjuntos possuem muitos atributos em comum, e aí surge a possibilidade de se
gerar um conjunto de entidades que reúna todas estas entidades num só conjunto,
sendo este processo chamado de generalização. Com isso, realiza-se o oposto da
especialização, ressaltando atributos comuns entre os conjuntos de entidades e
omitindo-se atributos especí cos não comuns entre os conjuntos separados.

Outro conceito bastante importante relacionado à especialização e generalização é

o de herança, que semelhante ao conceito em programação orientada a objetos,
permite que atributos do conjunto de entidades mais geral possam ser
compartilhados com os conjuntos de atributos especializados e, assim, forma-se
uma estrutura muito e ciente de se trabalhar os dados, pois sem esta possibilidade

47
de herdar atributos, não haveria necessidade de generalizar um conjunto de
entidades ou especializá-los, pois haveria muita redundância de dados e, desta
forma, apenas o conjunto geral possui os atributos e dados comuns aos conjuntos
de entidades especializados.

Um último conceito importante a ser citado é o de agregação que

permite que um agrupamento seja feito contendo conjuntos de
entidades e relacionamentos de forma que sejam considerados como
um único elemento e, assim, possam ser ligados a um relacionamento.
Isso existe para que seja possível interligar diretamente dois
relacionamentos, pois a notação base ER não permite este tipo de
ligação direta.

Observe a Figura 6 para compreender a ideia de agregação onde um retângulo se

posiciona ao redor de dois conjuntos de entidades e um relacionamento entre eles,
agrupando-os.

Assim, é possível que uma ligação entre este relacionamento da agregação seja
ligado a outro relacionamento fora da agregação sem que haja um conjunto de
entidades entre eles.

48
Figura 6

1 2

Fonte: O autor.

Com os conceitos adicionados aos já estudados para a modelagem ER, é

muito válido para o aprendizado gerar diagramas para diversas
situações ctícias que possam simular ao menos, parcialmente,
situações reais e suas regras de negócio. Os diagramas tendem a conter
erros com a pouca prática, mas como todas as áreas, com a prática e
estudos mais aprofundados, a tendência é minimizar erros de
elaboração dos diagramas e aumentar a agilidade na de nição dos
conjuntos de entidades e relacionamentos.

Inicialmente, o diagrama pode ser desenhado à mão mesmo de forma rústica no

projeto, mas para efeito de documentação, acaba sendo feito em alguma
ferramenta que permita o desenho seguindo os padrões ER e, para este material, o
SGBD utilizado para estudos será o MySQL que permite a criação de diagramas
além da implementação do banco de dados.

49
Ao instalar o SGBD MySQL, como poderá ser visto em aula posterior, existe a opção
de criação de novo modelo ER (File, New model) que abre uma interface para
criação de diagramas e é possível a criação de tabelas para a modelagem de
conjuntos de entidades, como se pode ver na Figura 7.

Figura 7

Fonte: O autor.

Com o uso desta ferramenta do MySQL, assim como outras disponíveis para uso
gratuito ou pago, pode-se elaborar a estrutura conceitual de todo o banco de
dados, obtendo-se um primeiro esboço ainda sem componentes importantes como
o da Figura 8, e que deve ser aprofundado e complementado para que seja
realmente completo e correto, mas isso varia em cada situação com base nas
regras de negócio que geram os documentos de requisitos utilizados como base na
modelagem.

50
Figura 8

Fonte: O autor.

51
 05

Desenvolvimento
de Banco de Dados
52
Após as etapas iniciais de concepção de um banco de dados e uso da ER para
modelagem, estamos estudando os conceitos relevantes, dentro deste contexto, nas
primeiras aulas desta disciplina.

Aos poucos, com o ganho de experiência prática e conhecimentos adquiridos com

estudos, você vai aprimorar a forma como utiliza o conhecimento e vai pensar em
melhores soluções, aplicando de forma cada vez mais e ciente os recursos
disponíveis.

Ao se pensar em como será a estrutura de um conjunto de entidades, é preciso

delimitar bem o conjunto de atributos que serão utilizados a partir da abstração do
modelo real, e também especi car adequadamente o domínio de dados para estes
atributos, como estudado anteriormente.

Nesta etapa do projeto, a correta escolha depende de bons requisitos

obtidos logo no início, mas também da chamada expertise, que se obtém
com o tempo e aperfeiçoamento das habilidades na elaboração de
conjuntos de atributos, fazendo com que se tenha plena consciência de
cada tipo adequado de dado para cada atributo e como de nir estes
atributos.

Um exemplo é o atributo endereço que, inicialmente, era colocado como atributo

único textual no qual toda informação era inserida numa única coluna da tabela que
pode representar a estrutura do conjunto de entidades. Com o tempo, foi sendo
dividido em partes com um atributo logradouro, outro para número, complemento,
etc.

Com o tempo e com o aumento do início das vendas online, o atributo de endereço
foi tornando-se cada vez mais completo e complexo com atributos para indicação de
pontos de referência, país e pessoa que pode receber uma entrega no local, por
exemplo.

53
Os esquemas também foram sendo melhorados e re nados, de forma que
esquemas gerados por meio de outros esquemas trouxeram novas visões dos dados
armazenados e ofereceram uma maior possibilidade de auxílio a gestores em
estratégias e tomadas de decisão.

Os esquemas gerados a partir de outros esquemas permitem que aos poucos seja
possível unir dados de conjuntos diferentes de entidades com o objetivo de obter
novas informações com o cruzamento de dados. Atualmente, com a evolução e a
popularização da Internet, isto se tornou um nicho de mercado fortemente
explorado.

Com isso, os sistemas de gerenciamento de banco de dados evoluíram e foram

agregando funcionalidades que contribuíram com esta melhoria da gestão e uso de
bases de dados cada vez maiores, e, aos poucos, foi sendo moldado um campo para
o surgimento dos termos Big Data e Business Intelligence que estão em alta no
mercado devido ao nível de auxílio gerencial obtido por estas inovações em TI.

54
 cliente = (cod_cliente,nome_cliente, cpf_cliente, fone_cliente)

produto = (cod_produto,descrição_produto, quantidade_produto)

venda = (cod_venda, cod_cliente,cod_produto, quantidade_venda)

Em esquemas como os indicados em cliente, produto e venda possuem atributos

próprios que não seriam corretamente alocados se mudassem de lugar na de nição
feita, pois atributos como CPF são especí cos de pessoas e não de produtos, por
exemplo.

É importante observar que a partir destes conjuntos de entidades é

possível imaginar novos usos para as entidades armazenadas, como no
caso em que a empresa pode desejar criar um canal de comunicação de
pós-venda de produtos para avaliação do serviço prestado na compra
física ou pela Internet, além do próprio produto. Para isso, usando apenas
o conjunto de entidades cliente, seria possível a obtenção de telefones,
mas não seria possível descobrir se são clientes que zeram compras ou
não.

Cruzando dados de cliente com dados do conjunto de entidades venda, é possível

ltrar os dados de forma que sejam buscados telefones apenas de CPFs cadastrados
nas vendas obtendo-se, assim, apenas clientes que realizaram compras.

É possível re nar mais ainda o processo, mas para isso, podem ser necessários
outros atributos como data da venda, valor total da venda e por produto, de forma
que seria possível a obtenção de uma lista de quem comprou produtos nos últimos
15 dias, quem mais comprou determinado produto, quem realizou o maior volume
de compras num certo período, etc.

55
Assim, aumenta-se muito a e ciência e aplicabilidade dos bancos de dados em
negócios de qualquer natureza, pois com tantos dados disponíveis podendo ser
cruzados sob determinados critérios, mudanças de rumo nas empresas, ajustes em
processos e até abertura e fechamento de unidades podem ser estudadas.

Independentemente de qual a proposta de uso de um banco de dados, é essencial

que todo este uso seja pensado e os atributos escolhidos a serem inseridos nos
conjuntos de entidades, pois a falta de dados também é um grande impedimento do
progresso de muitas empresas no atual cenário competitivo do mercado.

Como citado, com o uso de alguns atributos adicionais como data da venda e valores
obtidos nas transações, é possível ter um banco de dados mais completo e que não
seja apenas um repositório de histórico de transações, mas uma ferramenta de
gestão completa.

Assim, uma adequada modelagem do banco de dados é essencial, partindo de uma

boa análise e interpretação das regras de negócio de clientes que solicitem o
desenvolvimento de sistemas de banco de dados para gerir suas operações,
lembrando que um dos maiores problemas em sistemas deste tipo são adições e
exclusões de atributos em conjuntos de atividades depois que o sistema está em uso
e tendo já uma base de dados cadastrada.

Para a etapa de desenvolvimento de um banco de dados é possível utilizar vários

métodos e ferramentas, mas a unanimidade é o uso de um SGBD completo que
ofereça recursos diversos para o gerenciamento de um banco de dados.

56
 Para se trabalhar da melhor forma em TI, uma dica é a escolha de boas
ferramentas de trabalho, assim como em todas as demais pro ssões, e,
com isto, uma forma de se iniciar os estudos e treino para o
desenvolvimento de banco de dados é o teste de diferentes SBGD para
que se possa escolher um mais adequado ao estilo pessoal de trabalho ou
necessidades de uma empresa pela qual desenvolva seu trabalho.

Busque opções gratuitas e até versões de teste de ferramentas pagas

para conhecer um pouco dos recursos disponíveis, pontos positivos e
negativos de cada opção, de forma a ter maior segurança e conforto no
desenvolvimento de soluções computacionais na área de banco de dados.

Existem opções gratuitas e pagas no mercado, e como é comum na área de TI,

softwares pagos, geralmente, possuem melhores recursos e maior suporte, mas
alternativas gratuitas que podem inclusive entrar na categoria de software livre de
código aberto (open source) e poderem ter suporte em grandes comunidades de
desenvolvimento que criam, inclusive, variações da versão original do software e
podem se adequar melhor às necessidades.

A grande referência da área certamente é o SGBD da Oracle que é pago, mas que
suporta massivas quantidades de dados de forma estável e segura, assim como o
SQL Server da Microsoft que também é bastante utilizado para o gerenciamento de
banco de dados.

Opções como MySQL e PostGre SQL também são seguras e capazes de suportar
grandes volumes de dados, tendo versões gratuitas que suprem as necessidades da
maioria dos bancos de dados.

Para se iniciar o desenvolvimento de um banco de dados, uma ferramenta como

qualquer uma das citadas facilita bastante o processo, permitindo um bom
gerenciamento do banco depois de criado através do uso de recursos próprios da
ferramenta e do uso da linguagem padrão para banco de dados SQL.

57
Instalação de um SGBD (MySQL
Workbench 8.0 CE)
Para se desenvolver uma solução para armazenamento e manipulação de dados,
pode-se optar pela instalação de um dos bons Sistemas de Gerenciamento de Banco
de Dados disponíveis no mercado, mas alguns são pagos e podem oferecer versões
de demonstração, e outros são gratuitos enquadrando-se, inclusive, em alguns casos,
como open source, ou seja, que disponibilizam acesso ao código fonte para quem
tiver interesse em modi car suas funcionalidades ou aparência, por exemplo.

Foi escolhida uma versão já bastante conhecida do mercado e possui diversas

versões já disponibilizadas e para este material, foi escolhida a versão MySQL
Workbench 8.0 CE gratuita e disponível no endereço
https://dev.mysql.com/downloads/windows/installer/8.0.html.

58
Figura 1

Fonte: Disponível aqui

Importante frisar que é constante o desenvolvimento de atualizações e novas versões

que podem mudar a interface de instalação, além de novos recursos e correções de
problemas identi cados em versões anteriores.

Após o download da versão do instalador ou baixar a completa (Figura 1), inicia-se o

processo de instalação com a execução do pacote de instalação baixado e temos,
então, uma sequência de passos indicada nas imagens da sequência da aula.

59
Figura 2

Fonte: O autor.

Depois, é preciso optar por uma das versões de uso, sendo adequado e su ciente
para a disciplina, a opção padrão indicada na Figura 2, onde o pacote típico para
desenvolvimento é oferecido.

Na Figura 2, são exibidos os conteúdos que necessitam ser baixados do site o cial
para o processo de instalação. Basta avançar com a opção Next. Aos poucos, o
instalador vai executando o download dos componentes necessários e prepara para
o processo de instalação local na máquina para posterior uso no desenvolvimento de
sistemas gerenciadores de banco de dados.

Depois de instalados os pacotes solicitados e necessários, a instalação é encerrada

nesta etapa e, na sequência, inicia-se o processo de adição dos pacotes que forem
interessantes para seu trabalho.

Na tela da Figura 3, são exibidos os pacotes disponíveis para download em versões

distintas de uso de linguagem de programação Java ou Net, por exemplo.

60
Figura 3

Fonte: O autor.

A instalação vai chegar a um ponto mostrado na Figura 3, onde se escolhem os

pacotes desejados selecionando-os na parte esquerda da tela e adicionando à parte
direita para instalação.

Neste caso, foram selecionados apenas componentes básicos de manipulação de

banco de dados MySQL.

Após completar o download dos componentes solicitados, eles são instalados e o

processo de instalação é encerrado como mostrado nas etapas exibidas na Figura 4.

Figura 4

Fonte: O autor.

61
Depois de terminada a instalação, é possível executar o SGBD e se deparar com uma
interface de apresentação da ferramenta onde é apresentada a tela de boas-vindas
da interface e depois, na Figura 5, a janela de trabalho quando se inicia um novo
projeto de banco de dados.

Figura 5

Fonte: O autor.

Após esta etapa de instalação, o SGBD está pronto para uso e, a partir daí, é preciso
se ambientar à ferramenta e conhecer seus recursos, não perdendo de vista o foco
principal que é o de se criar tabelas, inserir dados e manipulá-los, gerar consultas e
tudo mais que for necessário e disponível pela ferramenta.

62
Um software complexo como um SGBD possui muitas funcionalidades e
particularidades de uso, e sempre é recomendável que se inicie o uso de
uma nova ferramenta com o auxílio de um manual ou conteúdo de ajuda
sobre a ferramenta. No caso do SGBD MySQL, existe conteúdo o cial
disponível em inglês, mas que pode ser traduzido em tempo real pelas
ferramentas do navegador, visto que a ajuda é online, mas podem-se
buscar outras fontes e encontrar materiais de qualidade até mais
adequados ao tipo de ajuda desejado.

63
 06

Linguagem SQL –
Definição de Tabelas
64
Para se trabalhar efetivamente com banco de dados, é preciso que alguma
ferramenta possa manipular os dados de um banco de dados ou uma linguagem
possa desenvolver uma aplicação para tal.

Existem sistemas gerenciadores de banco de dados capazes de manipular sem

problemas os dados das tabelas de um banco, mas para um sistema desenvolvido
para um terceiro como ocorre, na maioria das vezes, o processo de manipulação do
banco de dados deve ser o mais transparente possível e, em muitos casos, não
necessitar que o usuário tenha conhecimento algum dos conceitos de banco de
dados e seu gerenciamento.

Pensando em um meio mais transparente e de fácil aprendizado para manipulação

dos bancos de dados, foi implementada a linguagem SQL, considerada uma
referência para o trabalho com banco de dados relacionais, tendo uma boa coleção
de comandos para criação de scripts que servem como roteiros de ações pré-
de nidas para que ações tais como criar tabelas, inserir dados, consultá-los ou alterá-
los possam ser escritas e executadas em um banco de dados sem muitas linhas de
código, como ocorre na maioria das linguagens de programação.

A linguagem SQL possui suas características próprias para as tarefas de

manipulação de banco de dados e pode ter seus comandos subdivididos
em partes conhecidas como DDL e DML citadas anteriormente.

Os comandos DDL para de nição de dados representam os comandos estruturais

para criar tabelas a partir de esquemas, modi cá-las e excluí-las, se necessário.
Também são responsáveis pela indicação de restrições voltadas à maior garantia de
integridade dos dados, porventura armazenados no banco.

De nições de visões e direitos de acesso a usuários também são de responsabilidade

de comandos DDL.

65
Outro conjunto de comandos se enquadra como DML de comandos de manipulação
de dados envolvendo ações inserção, alteração e exclusão de dados e não de toda a
estrutura das tabelas, sendo assim, utilizados muito mais vezes que os comandos do
tipo DDL.

A linguagem SQL também pode ser embutida dentro de códigos de outras linguagens
compatíveis como C++ e Java, por exemplo, permitindo que estas linguagens não
necessitem que nelas sejam implementados comandos de interação direta com
banco de dados.

A linguagem sofreu mudanças e evoluiu como a maioria das demais linguagens de

programação e possui em atividade versões como as SQL-92, SQL-1999, SQL-2003,
SQL-2008 e SQL-2016.

Independentemente da versão utilizada, os fundamentos da linguagem são

padronizados, pois a base da linguagem é mantida de forma a aumentar a
compatibilidade entre sistemas e, geralmente, o que ocorre em novas versões
implementadas é o acréscimo de recursos e melhorias no que já era oferecido, se
necessário ou útil.

66
 A manipulação de dados com SQL é bastante fácil e rápida de aprender,
mas existem ferramentas que oferecem recursos robustos de
gerenciamento de banco de dados, além de aceitarem perfeitamente os
comandos SQL.

Um SGBD completo é um excelente recurso para se trabalhar com dados

de forma con ável e opções como Oracle, MySQL e SQL Server são
excelentes opções no mercado, podendo ser gratuitos ou não.

Definindo Esquemas
As relações necessitam ser criadas e mantidas através da linguagem SQL, e o
conjunto de instruções disponíveis na DDL foi implementado para que se possam
determinar esquemas para cada relação e tipos de dados contidos nos atributos
de nidos. Assim, por meio destes comandos, as tabelas e seus atributos podem ser
gerados e suas estruturas gerenciadas, além de permitirem que os atributos tenham
regras de nidas em relação ao que deve ser aceito como dado válido, de forma a
oferecer integridade ao banco de dados todo.

Ao de nir esquemas para criar tabelas, é preciso lembrar-se da ideia básica de que as
tabelas possuem como base as colunas, que representam seus atributos, e serão as
estruturas de armazenamento de dados. Sendo assim, no momento em que são
de nidos quais atributos farão parte de uma tabela, é preciso também delimitar os
tipos de dados aceitos e o domínio de valores deste tipo que podem ser inseridos
nestes atributos.

67
Os tipos de dados mais utilizados segundo Silberschatz (2020), na de nição de dados
são char (N) ou character (N), que permite que sejam armazenados até N caracteres
de texto no atributo, sendo então adequado para textos comuns.

O tipo varchar (N) ou character varying (N) representa uma alternativa ao tipo char
em que a diferença básica entre ambos é que o tipo char armazena um tamanho xo
N de caracteres, ao passo que varchar pode conter até N caracteres, armazenando
apenas a quantidade signi cativa de caracteres.

Outro tipo fundamental se chama int ou integer, que representa um dado simples
numérico inteiro limitado a um valor máximo aceito pelo hardware e sistema
operacional. Uma variação smallint também pode ser utilizada, sabendo-se que esta
aceita um valor limite menor também indicado pela limitação de hardware.

O tipo numeric (N, M) é outro tipo numérico, mas para números reais com casas
decimais, sendo que N representa o total de dígitos numéricos aceitos (contando com
os dígitos à direita da vírgula), e M o total de dígitos aceitos como casas decimais à
direita da vírgula. Um exemplo seria numeric (4,2) que aceita valores desde 0 a 99,99
no máximo, por exemplo.

O tipo real é utilizado em aplicações matemáticas, pois aceita números de ponto

utuante, ou seja, com casas decimais além de números inteiros, e existe uma
variante double precision que aceita números maiores e mais precisos em termos de
casas decimais, permitindo o trabalho com valores muito grandes.

Por m, o tipo oat (N) é usado também como número decimal com uma precisão
de pelo menos N dígitos à direita da vírgula sendo, então, uma terceira alternativa
para números decimais.

Para criar um esquema usando SQL, é utilizado o comando create table para de nir
a estrutura a ser gerada seguindo uma sintaxe bastante simples que seria a forma
como se deve escrever o comando.

Suponha que se queira criar um esquema para uma tabela de clientes com os
atributos básicos pessoais como CPF, nome e telefone. O comando para esta ação é
bastante simples, e uma sugestão seria a da Figura 1.

Figura 1

create table cadastro_cliente

68
 (Código_cliente int,
cpf_cliente numeric (11,0),
nome_cliente varchar (50),
telefone_cliente numeric (10,0),
primary key (Código_cliente))

Fonte: autor.

No exemplo da Figura 1, foram de nidos os tipos de dados para cada atributo, de

forma intuitiva, apenas como exemplo, pois em casos reais, é preciso veri car junto
ao cliente, os tipos e tamanhos adequados em função das regras de negócio do local
para que sejam indicados com exatidão os tipos e tamanhos adequados aos
requisitos levantados.

Observando o exemplo da Figura 1 é importante destacar que o script para geração

do esquema se inicia com a identi cação do nome da tabela a ser criada e, entre
parênteses, vêm todos os atributos e seus respectivos tipos e domínios de dados
aceitos, mas ao nal, é fundamental a indicação do campo ou campos que compõem
a chave primária da tabela com o uso das palavras reservadas primary key e a lista
de atributos (apenas os nomes) indicados entre parênteses e separados por vírgula
se forem mais de um.

69
Manipulando um Banco de Dados
Após a criação de uma tabela, esta pode ser gerenciada através de scripts com
comandos diversos para que seja povoada com dados e estes possam ser utilizados
para as atividades previstas para o SGBD. A inserção de dados também é um
processo relativamente simples, porém trabalhoso, pois geralmente os dados a
serem inseridos no banco são obtidos por interações manuais de usuários direta ou
indiretamente.

Seja qual for a origem dos dados, para ns de estudos os dados serão inseridos
manualmente com o uso da palavra reservada insert que necessita de alguns
parâmetros em sua sintaxe para que possa ser funcional.

Partindo da tabela Clientes gerada pelo script exemplo, da imagem 26, pode atribuir
um conjunto de dados aos parâmetros do comando para que estes sejam inseridos
como uma nova tupla de dados na tabela Clientes. Observe uma sugestão de como
poderia ser escrito um comando para inserir dados referentes a uma tupla na tabela
Clientes.

insert into cadastro_cliente values (1, 12345678900,

‘Charles Chaplin’, 1198765432)

É importante estar atento aos detalhes no uso dos comandos da linguagem, pois em
sua sintaxe, os detalhes fazem diferença, e não respeitar as regras de escrita destes
comandos pode implicar erros nos dados ou o não funcionamento dos scripts
gerados para a realização de ações.

As três palavras-chave devem ser utilizadas da forma como mostrado, o nome da

tabela onde serão inseridos os dados deve ser indicada após a palavra into e os
dados dentro de parênteses após a palavra value, e na ordem em que os atributos
foram de nidos na tabela, pois não são especi cados quais dados são para quais
campos na tabela.

Caso algum dado seja nulo, basta deixar sem o dado, mas inserindo as vírgulas
separadoras, normalmente, cuidando que dados numéricos são inseridos de forma
simples, e os dados do tipo texto entre aspas simples.

70
Pode-se excluir todos os dados de uma tabela, mantendo sua estrutura para uso
posterior, usando-se o comando delete de forma bastante simples, pois como
parâmetro na sintaxe do comando é preciso apenas indicar qual tabela terá todos os
seus dados excluídos como se pode ver no exemplo.

delete from cadastro-cliente

Outras formas de se trabalhar com exclusões utilizam o comando drop para estas
tarefas, sendo que sua sintaxe permite duas variantes diferenciadas apenas por um
parâmetro, mas que geram ações bastante diferentes. Observe os dois exemplos a
seguir:

drop from cadastro_cliente

drop table cadastro_cliente

A primeira linha de comando do script funciona como o comando delete, excluindo

apenas os dados de todas as tuplas da tabela, mas a segunda opção de comando
exclui não somente todos os dados da tabela, mas também remove toda a sua
estrutura, eliminando-a do banco de dados, e para que se possa novamente inserir
dados, ela precisaria ser recriada com o comando create table.

Por m, atributos podem ser adicionados ou excluídos de uma relação ou tabela

utilizando-se o comando alter que modi ca a estrutura de tabelas, sendo essencial
observar com cuidado as ações realizadas por este comando.

alter table cadastro_cliente add estado_cliente char (2)

alter table cadastro_cliente drop telefone_cliente

71
Nos dois exemplos, o comando se inicia da mesma forma com as palavras alter
table e o nome da relação desejada cadastro_cliente. Depois, o primeiro comando
acrescenta um atributo chamado estado_cliente que aceita dois caracteres de texto,
sendo adequado para siglas de estados no Brasil.

No segundo exemplo, o uso da palavra drop faz com que o atributo indicado
telefone_cliente seja excluído da estrutura da relação, mas é importante observar
que existe um enorme risco no uso deste comando, pois ao se excluir o atributo, seus
dados também são perdidos automaticamente (sendo que alguns gerenciadores
podem não permitir esta ação), e outro risco é o de o atributo fazer parte de uma
chave primária ou ser chave estrangeira num relacionamento entre tabelas.

A melhor forma de aprender comandos da linguagem SQL é criando

banco de dados de teste com relações e atributos variados, mas que
sejam coerentes e baseados em algum problema ctício, por exemplo.
Assim, as estruturas criadas podem ser melhor compreendidas, avaliadas
e testadas com a inserção e manipulação de dados nestas para que a
prática permita que se compreenda o uso dos comandos e a organização
de um banco de dados.

72
 07

Linguagem SQL
– Consultas
73
Os bancos de dados possuem a função essencial de armazenar dados, mas esta não
é a única motivação para se desenvolver um sistema gerenciador, e sim utilizar,
posteriormente, os dados armazenados para diferentes ns.

Uma das maiores atividades realizadas em banco de dados são as consultas em

dados armazenados para a obtenção de informações variadas necessárias para
atividades diversas e tomadas de decisões, por exemplo.

O comando utilizado chamado select é provavelmente o mais utilizado e importante

dos comandos SQL e em função de seu amplo uso permite que muitas variações nos
parâmetros e formas de uso estejam disponíveis para a realização de pesquisas em
banco de dados.

A base de um comando de consulta select se baseia nas palavras select, from e

where, com seus respectivos parâmetros, mas por mais que aparentemente seja
uma sintaxe simples, neste caso, o comando permite muitas combinações de
parâmetros para estas três palavras e, ainda, permite a adição de outros elementos
nos comandos, tornando este um recurso extremamente poderoso da linguagem
SQL.

Para se escrever comandos select é importante ter em mente que a base do uso do
comando é a de se buscar certos dados de determinada relação, sendo que os dados
podem ser especi cados ou não, e a relação pode ser de uma tabela especí ca ou de
mais de uma tabela que possam ser relacionadas através de suas chaves primárias e
estrangeiras.

O terceiro componente de um comando select é o que permite maior variação, em

que a cláusula where de ne os critérios para ltragem dos dados localizados numa
relação a serem retornados ao solicitante. Um exemplo de formato básico de uso do
comando select é apresentado a seguir:

select dados from tabelas where condições

Esta sintaxe básica do comando serve para que se possa conhecer a estrutura
sintática do mesmo, mas a escrita de scripts de consulta funcionais dependem de
uma melhor de nição dos parâmetros na elaboração dos comandos.

74
Supondo a base de dados contida numa relação, a forma mais simples de se utilizar o
comando select, mas não a mais usual é solicitando que todos os dados desta
relação sejam exibidos como no exemplo:

select * from cadastro_cliente

Este comando trará como retorno todos os dados contidos em todos os atributos da
tabela cadastro_cliente e, com isto, pode surgir o questionamento do motivo de não
ser muito usual uma consulta simples como essa, mas o problema com ela é que é
bastante comum que uma tabela possa conter uma quantidade enorme de tuplas
com vários atributos, resultando numa listagem muito grande de dados que pode
mais prejudicar que auxiliar uma análise sobre os dados obtidos.

O uso do símbolo asterisco (*), assim como nos sistemas operacionais, representa
qualquer valor, ou seja, como após a palavra select são indicados atributos da
relação a serem exibidos, o símbolo indica ao comando que todos os atributos
devem ter seus dados exibidos na consulta, e caso se deseje apenas alguns, pode-se
ajustar o exemplo anterior.

select nome_cliente, telefone_cliente from cadastro_cliente

Com esta alteração, todas as tuplas armazenadas na tabela cadastro_cliente serão

listadas, mas apenas os dados dos atributos nome_cliente e telefone_cliente,
atendendo à ideia de que são necessários apenas o nome e o respectivo telefone de
cada cliente cadastrado na tabela naquele momento.

Também é possível ajustar a relação que serve de base para as consultas, permitindo
que uma ou mais tabelas sejam indicadas, separadas por vírgulas, na cláusula
de nida pela palavra from, mas, como dito, é preciso veri car se existe
relacionamento entre as tabelas utilizadas e, se for necessário, que exista uma
correspondência entre dados das tabelas para a ltragem de dados.

75
Tabelas que possuam relacionamentos entre si através da existência de chaves
primárias e chaves estrangeiras podem usar isso para encontrar ligações entre
outros dados das tabelas, como no caso de se buscar todas as compras realizadas
por determinado cliente em um estabelecimento.

Aproveitando uma situação hipotética já utilizada de um sistema de vendas com

cadastro de vendas e clientes, a Tabela 1 traz alguns dados contidos nas tabelas para
exempli car um banco de dados para auxiliar na compreensão das consultas.

Tabela 1

cadastro_cliente

código_cliente cpf_cliente nome_cliente telefone_cliente estado_c

Charles
1 12345678900 1198765432 SP
Chaplin

Thomas
2 98765432100 1432564852 SP
Edison

Albert
3 55555555500 4398653325 PR
Einstein

cadastro_venda

código_venda descrição quantidade código_cliente

1 PRODUTO A 2 3

2 PRODUTO B 5 2

3 PRODUTO A 10 2

Fonte: O autor.

76
Nestes exemplos da Tabela 1, alguns detalhes são relevantes, como, por exemplo, a
coincidência de valores das colunas de códigos dos atributos código_cliente e
código_venda que repetem os valores 1, 2 e 3, mas isto ocorre em função dos
códigos em ambos os atributos serem de nidos como valores numéricos inteiros
incrementados, sequencialmente.

Com isso, é importante a rmar que um valor 1 no atributo código_cliente não possui
relação direta com um valor 1 no atributo código_venda, pois são códigos utilizados
apenas para identi cação de clientes diferentes e vendas diferentes nas respectivas
tabelas.

O que não é coincidência e relevante é observar que existe a ligação entre os valores
2 dos atributos código_cliente das duas tabelas, pois na tabela cadastro_cliente,
este valor é a chave primária de identi cação da tupla, ao passo que na tabela
cadastro_venda indica que o cliente 2 realizou compras no estabelecimento (duas
neste exemplo).

Um exemplo de consulta sobre as tabelas seria solicitar a exibição de todos os dados

das duas tabelas, inserindo o nome das duas separado por vírgulas, fazendo com que
todos os dados das duas tabelas fossem exibidos em listagem única, mas isto não é
interessante, pois além de poder ser trazida uma lista muito longa e confusa, existe a
redundância de códigos das chaves primárias e alguma confusão que pode ser
gerada com a chave estrangeira.

77
 Lembre-se de que, comumente, consultas não geram mudanças nos
dados, e apenas os ltram a partir de um conjunto de parâmetros que
incluem condições de validação de critérios para as buscas, podendo
trazer muitas variações de pesquisas. Existem diferentes composições de
pesquisas, mesmo em banco de dados pequenos capazes de retornar
detalhes contidos no banco que podem surpreender e aumentar o grau
de especialização de um especialista em banco de dados.

Filtrando Consultas
Normalmente, as consultas buscam retornar apenas dados esperados a partir do que
é solicitado em scripts de comandos select, mas para isso, estes comandos precisam
ser escritos de forma adequada, atendendo à sintaxe necessária e, principalmente,
de nindo os critérios indicados nos parâmetros.

Dentro do comando select, as palavras select e from indicam, respectivamente, os

atributos a serem exibidos e as tabelas que servem de base para a consulta, mas
para se ltrar o conteúdo a ser exibido, entra em uso a terceira parte do comando
que utiliza a palavra where como base para a sintaxe do comando.

Na cláusula where são indicados ltros para seleção de dados a partir de critérios
que devem ser escritos segundo a sintaxe do comando, mas neste ponto é que a
complexidade aumenta, pois esta cláusula permite bastante variação de parâmetros.

78
Para se escrever os parâmetros de ltragem das consultas existem alguns símbolos
matemáticos utilizáveis para que cláusulas baseadas em lógica possam ser escritas.
Os principais símbolos utilizados são descritos na Tabela 2.

Tabela 2

SÍMBOLO DESCRIÇÃO EXEMPLO

Veri ca a igualdade de um atributo em

= nome = ‘João’
relação a um valor especí co.

Veri ca se um atributo é maior que um

> saldo > 1000
valor especí co.

Veri ca se um atributo é maior ou igual a

>= idade >= 18
um valor especí co.

Veri ca se um atributo é menor que um

< saldo < 0
valor especí co.

Veri ca se um atributo é menor ou igual a

<= peso <= 70
um valor especí co.

Veri ca se um atributo é maior que um

<> cor <> ‘azul’
valor especí co.

Une duas condições para veri car se as saldo < 0 and

and duas resultam verdadeiro ao mesmo situação =
tempo. ‘desempregado’

Une duas condições para veri car se pelo idade <18 or idade
or
menos uma das duas resulta verdadeiro. >= 60

Inverte o resultado de uma condição de

not Not NULL
verdadeiro para falso e vice-versa.

Fonte: O autor.

79
O uso dos símbolos é essencial na construção dos critérios de ltragem de dados na
cláusula where, pois por meio deles é possível elaborar critérios a serem veri cados
no conjunto de dados da relação, bem como obter uma listagem de dados desejados.

No exemplo da imagem R, além de estarem listados os símbolos usuais de

elaboração de condições, também estão inseridas descrições para auxiliar na
compreensão do que cada símbolo representa, logicamente, como no caso do
símbolo de igualdade, que permite que um valor sirva de base para que sejam
localizadas todas as tuplas onde o atributo especi cado na condição seja igual.

Além dos símbolos matemáticos indicados, existem três operadores lógicos and, or e
not que representam operadores lógicos que permitem a avaliação de outras
condições.

O operador and, por exemplo, necessita que duas condições sejam de nidas de
forma que ele sirva para comparar os resultados individuais das duas condições em
função da lógica deste operador. Para o operador and, o resultado apenas é
verdadeiro se as duas condições ligadas a ele resultem verdadeiro também, caso
contrário, o resultado é falso e os dados da respectiva tupla não são retornados na
consulta.

O exemplo utilizado na Tabela 2 para o operador and indica que serão exibidos
apenas dados de tuplas onde saldo < 0 and situação = ‘desempregado’, ou seja, em
tuplas onde o saldo seja negativo e a pessoa esteja desempregada, sendo que
pessoas com saldo positivo ou zero não sejam aceitas ou que estejam empregadas
também não.

O operador or possui sintaxe igual à do operador and e também necessita de duas

condições que resultem em verdadeiro ou falso para que as duas sejam avaliadas em
conjunto, com a diferença que se qualquer uma das duas resultar verdadeiro, o
resultado também é verdadeiro e a tupla que contém os dados comparados é
utilizada.

No exemplo da imagem 29, idade <18 or idade >= 60 temos que são aceitas tuplas
nas quais a idade seja menor que 18 anos ou maior ou igual a 60 anos, formando,
assim, um conjunto de valores aceitos na condição, e o resultado é falso apenas em
tuplas com valores entre 18 e 59 no atributo idade.

Existe uma opção complementar chamada between que permite a de nição de

intervalos de valores que pode ser usada no lugar de and e or para casos, como o
desse do intervalo de idade, sendo que a mesma condição poderia ser escrita como
between 18 and 59 e teria o mesmo efeito.

80
Por m, o operador not apenas inverte o resultado de uma condição, sendo que se
uma condição resultaria verdadeira, este operador muda o resultado para falso, mas
seu uso é um pouco diferente na linguagem SQL pode receber complemento de
outras palavras reservadas da linguagem para maior exibilidade de uso.

select * from cadastro_cliente

select nome_cliente from cadastro_cliente
select nome_cliente from cadastro_cliente where
estado_cliente = “SP”
select nome_cliente from cadastro_cliente where
estado_cliente = “SP” and telefone_cliente = 1432564852

Partindo dos exemplos acima, temos uma progressão não apenas do tamanho dos
comandos do script SQL, mas também de sua complexidade e capacidade de
ltragem de dados.

No primeiro exemplo já citado, mostra todos os clientes cadastrados na tabela

cadastro_cliente, ao passo que o segundo exemplo traz a mesma quantidade de
entidades listada, mas contendo apenas os dados do atributo nome_cliente.

No terceiro exemplo, novamente são mostrados apenas os nomes de clientes, mas

no exemplo apenas os nomes de clientes do estado de São Paulo podem ser
retornados da consulta, pois existe a cláusula de ltragem no comando indicando um
critério de pesquisa.

No último exemplo é ampliada a ltragem de exibição de nomes, e a consulta se

especializa a um nível que apenas clientes do estado de São Paulo com determinado
número de telefone será retornado como resultado, e isto gera uma expectativa de
que seja retornado apenas um resultado, ou até nenhum.

81
A melhor forma para se compreender as consultas é pensar em casos
reais em que se deseja procurar dados especí cos em uma listagem, por
exemplo, e iniciando a elaborar consultas simples que retornam dados
sem muitos ltros para que se acostume com a sintaxe dos comandos e
erros comuns que se aprende na prática. Criar scripts com muitas
consultas baseadas em atributos de uma tabela ou mais é bastante
e ciente como aprendizado, pois com este treino, as chances de se obter
um bom aprendizado aumentam muito.

82
 08

Armazenamento e
Consulta de Dados
83
Aproveitando conceitos estudados de de nição de projeto de banco de dados
usando o modelo ER e conhecendo a base da linguagem SQL, é possível imaginar
uma pequena aplicação de exemplo para o emprego destes conceitos. Para isso, o
foco é a etapa de desenvolvimento de um pequeno projeto experimental utilizando o
SGBD MySQL que foi introduzido nos estudos para aplicar o que foi estudado até o
momento e que pode continuar servindo de base para a continuidade dos estudos.

Para iniciar este trabalho, é preciso primeiro idealizar uma aplicação ctícia e,
partindo da ideia, seguir os passos seguintes de projeto básico deste banco de dados,
para que depois ele possa servir de base para o desenvolvimento no SGBD MySQL.

Partindo da proposta da criação de um banco de dados para gerenciamento de

vendas de produtos para clientes de uma pequena loja, é preciso então compreender
as regras de negócio deste estabelecimento, pois não existe uma padronização
universal para as atividades do mercado e é preciso conhecer o máximo possível do
negócio.

Regras do Negócio e Requisitos do

Sistema
Os requisitos de um sistema representam toda a abstração obtida a partir do que é
real e pode ser implementado de forma digital em software, ignorando elementos
supér uos e desnecessários, e organizando bem os requisitos relevantes para que
forneçam boa base para o projeto.

Supondo que a pequena loja necessite controlar apenas um cadastro de produtos,

clientes e vendas no banco de dados, é preciso compreender que dados são
relevantes nestes cadastros. Neste negócio, o cadastro de clientes é composto por
algumas informações essenciais dos clientes de forma a possibilitar identi cação dos
mesmos e geração de notas scais eletrônicas se desejado pelo cliente. Com isso, ca
de nido que para o cadastro de clientes são necessários o nome, CPF, endereço que
não precisa ser dividido em atributos separados, e telefone com DDD.

Para os produtos, a loja trabalha com o ramo de motopeças e precisa que um

cadastro destes itens contenha uma descrição da peça, modelo de moto que a utiliza,
anos que aceitam a peça, quantidade disponível para venda e valor para venda. Após
a identi cação dos atributos para venda, veri cou-se que um módulo adicional seria
interessante, pois a quantidade disponível e o valor de venda são informações que
dependem das compras destes produtos para revenda, pois não são itens fabricados
no local.

84
Partindo dessa necessidade adicional identi cada, foram de nidos os atributos de
compra, como nota scal de compra não obrigatória, pois existem produtos que são
adquiridos sem nota scal, como peças adquiridas de uma o cina caseira de um
mecânico que as fornece informalmente para venda como itens usados, e com isto,
adicionando a ideia de que é interessante adicionar um atributo de estado da peça
no cadastro de produto.

Também existe a parte da venda na qual, basicamente, o processo envolve a

indicação do cliente que realiza a compra, quais produtos ele comprou, a data da
compra e o valor total da compra, sendo que a forma de pagamento não foi citada
como relevante, pois o proprietário não se importa em praticar formas distintas de
valores de acordo com a forma de pagamento e, assim, os valores nais podem
sofrer algum tipo de desconto aplicado ao nal apenas e, assim, podendo afetar
diretamente o valor recebido na venda.

Criando um Banco de Dados

O trabalho de criação de um banco de dados usando a linguagem SQL será
demonstrado a partir do uso da SGBD MySQL que teve sua instalação explicada em
outra aula, de forma que agora é preciso preparar um ambiente para
desenvolvimento prático para complementar o que foi estudado até então.

85
Para isso, é preciso antes de iniciar o uso da linguagem SQL em si, preparar o SGBD
para o processo, e além do uso do MySQL, será instalado um servidor web para que
se possa simular um banco de dados inserido em um servidor.

Para este material será utilizado o servidor Apache Xampp que no momento de
criação do material estava em sua versão 3.2.4, assim como o SGBD MySQL estava
em sua versão 8.0.23, mas independentemente da versão, os aspectos essenciais de
funcionamento, normalmente, não são tão afetados por mudanças de versão e basta
algum tempo dedicado, e é possível conhecer os diferenciais de novas versões
lançadas posteriormente.

Após download do instalador do repositório o cial Xampp, e um processo de

instalação bastante simples e intuitivo, chega-se ao ponto no qual basta acionar o
servidor e para efeitos de estudo nesta disciplina, ativar com a opção Start, os dois
primeiros módulos do servidor (Apache e MySQL), e depois de ativados por meio do
botão Admin, é possível acompanhar o andamento do desenvolvimento do banco no
servidor.

Figura 1

Fonte: O autor.

86
Após a instalação e inicialização dos serviços do servidor terem ocorrido com sucesso
(observar a indicação das portas de comunicação para veri car o processo), como se
pode conferir na Figura 1, é possível iniciar o uso do SGBD MySQL normalmente.

Existe a necessidade de utilização de um servidor para banco de dados, pois sem a

existência de um, qualquer banco de dados gerado seria considerado local e não
disponível para conectividade web, por exemplo, tornando-o de uso bastante
limitado em um computador local que poderia servir para estudos, mas que caria
muito distante do que ocorre na realidade.

Figura 2

Fonte: O autor.

Ao abrir o SGBD, veri ca-se logo na interface inicial de boas-vindas a existência da

opção de criação de conexão de banco de dados gerados com o servidor Xampp,
como indicado na Figura 2.

Ao ser clicada, a opção abre uma janela para criação da conexão, bastando que seja
dado um nome para a mesma livremente no campo Connection Name, mostrado na
Figura 3.

87
Figura 3

Fonte: O autor.

Depois de criada a conexão, ela aparece como opção na tela de boas-vindas, como
mostrado na Figura 4 e, ao ser clicada, abre a interface de desenvolvimento, mas
antes, pode ser exibida uma mensagem de aviso na qual basta que seja utilizada a
opção Continue Anyway.

88
Figura 4

Fonte: O autor.

Já na interface de gerenciamento de banco de dados, existe todo um enorme

conjunto de opções e ferramentas a serem conhecidas e que podem ser aos poucos
exploradas, mas para os estudos nesta disciplina, serão utilizadas apenas as opções
essenciais de forma a otimizar o aprendizado, focando em parte do que é mais
comum que se utilize.

Na Figura 5 é visível, inicialmente, diversas opções de gerenciamento da conexão com

o servidor, mas, neste momento, como a conexão já foi criada e se mantém
funcional, interessa o que pode ser utilizado na opção Schemas, destacada na parte
esquerda da imagem.

89
Figura 5

Fonte: O autor.

Na área livre do menu esquerdo, é possível acionar o menu sensível ao contexto

ativado pelo clique do botão direito do mouse para que se possa acionar a opção
Create Schema e dar início ao desenvolvimento.

Figura 6

Fonte: O autor.

90
Na Figura 6, é mostrada a tela que traz o comando SQL para criação de um Schema
livro vendas, que pode servir de base para o início do desenvolvimento, gerando o
resultado da Figura 7, onde é exibida a estrutura criada do banco de dados com seus
principais elementos como tabelas e visões.

Figura 7

Fonte: O autor.

91
Este resultado obtido no SGBD pode também ser veri cado no Xampp clicando-se na
opção Admin do painel de controle, para que uma interface semelhante à da Figura 8
mostre que o banco de dados gerado também aparece no servidor através de sua
conexão de nida, anteriormente.

Figura 8

Fonte: O autor.

Próximos Passos
Para que se possa, então, seguir uma lógica de estudos e aplicação prática, será
excluído o banco criado livro venda, clicando-se em seu nome na janela esquerda e
escolhendo-se Drop Schema.

Em seguida, será então utilizada a linguagem SQL puramente para que todo o
processo seja executado, ignorando opções especí cas deste SGBD MySQL, obtendo-
se algo mais geral que pode valer para outros SGBDs também.

Como mostrado na imagem 36, reinicia-se o desenvolvimento de forma manual com

o uso do comando create database vendas, observando que todo comando em SQL
para ser completo, necessita que seja incluso um sinal de ponto e vírgula ao nal,
pois a ausência deste indica ao SGBD que ainda podem ser adicionados parâmetros
ao comando atual.

Depois, basta seguir a sequência padrão de uso do botão para executar comando
destacado na imagem 39, na parte direita da janela, observando a mensagem na
janela Output, que exibe o resultado dos comandos. Ali diz que o comando foi
executado com sucesso por meio do ícone verde e a mensagem de 1 linha afetada,
que representa que foi criado o banco de dados.

92
Para con rmar o processo, é preciso sempre que for executado um comando, que se
crie ou altere a estrutura do banco, o botão de atualização dos Schemas destacado
na parte esquerda da janela, como mostrado também na Figura 9.

Figura 9

Fonte: O autor.

Para que o banco seja criado de forma mais adequada, é possível adicionar
parâmetros ao comando create database de forma a garantir que os caracteres
inseridos sejam mais elmente aceitos e armazenados quando inseridos.

93
 Existem países com conjuntos de caracteres diferentes do usado no
português e nos padrões de teclado utilizados no país e, assim, existe o
risco de que dados tenham sua integridade prejudicada. A m de reduzir
esta possibilidade, é possível usar os parâmetros adicionais, a seguir,
sempre que criar um novo banco de dados, de forma que o padrão utf8
seja usado, mais adequado ao nosso idioma.

create database nome

default character set utf8
default collate utf8_general_ci;

Isso evita que algum conjunto de caracteres de um idioma diferente

daquele utilizado no país seja usado e ocorram erros na inserção de
dados como perda de acentuação ou aparecimento de caracteres
trocados ou indesejados nos dados.

Depois de criado o banco de dados, inicia-se a criação das tabelas para conter os
conjuntos de entidades, e estas também podem ser criadas com comandos SQL, mas
antes, é muito importante lembrar que as tabelas são de nidas por um nome, mas
também, por atributos que devem ter seus respectivos nomes e domínios de dados
aceitos, mais comumente chamados de tipos.

Estes tipos podem ser variados, e no caso da linguagem SQL, existem muitas
variantes possíveis de serem usadas, permitindo que o banco tenha entidades bem
ajustadas, reduzindo desperdício de espaço de armazenamento.

Sempre é preciso ter em mente que um banco de dados terá a função de armazenar
conjuntos de entidades, e a quantidade de entidades armazenadas pode ser tão
grande que qualquer ajuste pode in uenciar este armazenamento.

94
Os tipos principais de domínios para dados são, numérico, data e hora, texto e
espacial, sendo cada tipo ideal para determinado domínio de dados e para que haja
uma melhor otimização dos atributos, todos possuem subdivisões como se pode
conferir na Tabela 1

Tabela 1

Tipo
Variante Descrição
Básico

tinyint

smallint
Tipos numéricos inteiros que armazenam desde
pequenos valores a valores muito grandes,
int
podendo ter parâmetros que de nem a
quantidade de dígitos aceita.
mediumint

bigint

decimal

Numérico
oat Tipos decimais de valores com maior ou menor
precisão e aceitando valores menores ou muito
double grandes para ns cientí cos.

real

Tipo genérico SQL para números inteiros ou

numeric
reais.

bit
Tipos mais voltados a avaliações de valor
verdadeiro ou falso.
boolean

95
Data e date Tipos especí cos para armazenamento de dados
Hora temporais, muito importantes na construção de

datetime banco de dados.

timestamp

time

year

char
Tipo padrão para atributos de texto como
nomes, endereços, etc.
varchar

tinytext

text Tipos atribuídos a dados de texto maiores como

atributos de respostas de questões de provas
mediumtext com várias linhas.

longtext
Texto
tinyblob

blob Blob ou binary large object representa uma

coleção de dados binários como arquivos
mediumblob inteiros diversos como PDF, imagens, etc.

longblob

enum
Tipos especí cos para listas de dados textuais
especí cas como dias da semana, etc.
Set

96
 Espacial geometry Tipo de dados especí cos para aplicações
grá cas baseadas em polígonos e coordenadas.
geography

Fonte: O autor.

Cada SGBD como MySQL ou SQL Server, por exemplo, possuem

particularidades na interface de uso, opções e ferramentas disponíveis,
mas existem também diferenças na parte estrutural de sua linguagem
SQL, e para os tipos de dados, podem ser observados pontos de atenção
em consultas às documentações de um SGBD. Observe como são os tipos
de dados no padrão SQL Server.

Como são muitos tipos, e muitos deles apenas variações entre si, alguns serão
utilizados nos exemplos deste material para exempli car a forma de uso, enquanto
outros cam em aberto para que o aluno possa complementar seus estudos,
posteriormente, com fontes alternativas como os livros utilizados na bibliogra a.

Partindo dos tipos disponíveis indicados na imagem 40, é possível de nir como
seriam os atributos básicos para uma tabela cliente para cadastro do conjunto de
entidades relativa a esse conjunto de dados.

create table cliente (

cod_cliente int,

97
 nome_cliente varchar(30),
cpf_cliente numeric(11,0)
);

Observando o exemplo, são de nidos os atributos cod_cliente como dado do tipo

inteiro, escolhido entre as cinco opções de valores sem casas decimais, nome_cliente
como texto para até 30 caracteres, onde foi escolhido o tipo varchar ao invés de
char pela otimização que se obtém no armazenamento de dados, e cpf_cliente com
até 11 dígitos numéricos sem casas decimais indicado com o tipo numeric para este
m especí co.

As escolhas de tipos para atributos não são feitas apenas pelas categorias
de valores que se espera armazenar, mas envolve uma análise mais
profunda no que se espera destes atributos e seus requisitos
identi cados.

Os tipos inteiros, por exemplo, são simples e sua escolha se baseia mais nos maiores
ou menores valores que seriam aceitos pelos atributos, pois o tipo inteiro trabalha na
faixa de -2.147.483.648 a 2.147.483.647, ao passo que smallint usa a faixa de -32.768
a 32.767 nitidamente mais restrita, e o menor tipo tinyint de 0 a 255, equivalente a 1
byte apenas.

Já os tipos relacionados com números decimais permitem que parâmetros decidam

detalhes como casas decimais e a quantidade de bits utilizados para armazenar os
valores e cada SGBD pode delimitar de diferentes formas esta categoria de dados
com maior especi cidade que os tipos inteiros, por exemplo.

Em MySQL, por exemplo, o tipo chamado decimal, muito utilizado, é de nido por dois
parâmetros decimais (m,n), sendo m o tamanho total do número em si a ser
armazenado em dígitos, sendo que pela documentação o cial da versão utilizada, o
máximo aceito para a quantidade de dígitos neste tipo numérico é de 65, e para a

98
parte decimal n, o máximo é de 30 dígitos para de nir a quantidade de casas
decimais de precisão. Se estes valores não forem informados o MySQL assume m=10
e n=0.

O tipo oat aceita valores muito grandes, e a composição hardware e sistema

operacional podem variar estes valores que, de qualquer forma, são enormes e
indicados para aplicações matemáticas e cientí cas cuja precisão é de enorme
importância, com valores que podem ter dezenas de casas decimais, por exemplo.

É comum pensar em números tão grandes que, normalmente, se utiliza a chamada

notação cientí ca para delimitá-los gerando, assim, valores limites como -3.40E+38 a
3.40E+38 que seriam equivalentes a números com 39 dígitos fora o ponto, por
exemplo.

Os dados do tipo texto são mais simples de serem delimitados e compreendidos,

mas existem alguns pontos relevantes e os dois principais tipos são chamados de
char(m) e varchar(m), sendo que o primeiro possui uma de nição de que uma
quantidade m de caracteres será armazenada, independentemente do texto
signi cativo a ser inserido, ao passo que varchar também estabelece um limite m de
caracteres, mas apenas os caracteres signi cativos são armazenados, reduzindo
desperdício de espaço em disco.

Assim, caso sejam de nidos dois atributos char(3) e varchar(3), ambos podem ocupar
3 bytes de armazenamento, lembrando que, em geral, a quantidade de bytes
equivale a de caracteres, mas com a de nição utf-8, este valor pode ser diferente,
pois esta codi cação aceita caracteres que ocupam mais de 1 byte de espaço de
armazenamento.

De qualquer forma, digamos que sendo armazenado o caractere ‘a’ em ambos os

atributos, no primeiro, algo como ‘a’ seria armazenado, ocupando os 3 bytes, mas no
caso de varchar, seria realmente armazenado ‘a’ ocupando apenas 1 byte.

Outro tipo relevante que pode ser utilizado se chama text(m) e aceita textos longos
de até 216 caracteres praticamente ou 65535 caracteres podendo, então, con gurar
vários parágrafos de texto, podendo ser de nido um limite através de um valor para
m, e outro tipo chamado blob aceita cerca de 224 bytes, praticamente, ou 16.777.215
de caracteres como outra opção para textos longos.

Um tipo importante de texto se chama enum e de ne listas de dados xas que são
ótimas opções para conjuntos delimitados de opções de escolhas para atributos
como sexo que, geralmente, é identi cado com apenas 1 caractere, dias da semana
com os nomes dos sete dias abreviados ou não, meses do ano, nomes de pessoas
especí cas, cargos, etc.

99
Complementando os tipos básicos de texto que podem ser utilizados ao longo do
material, o tipo set traz a possibilidade de se criar conjuntos de dados textuais no
qual a quantidade de 0 a 64 dados, sendo que os dados aceitos são predeterminados
na de nição do atributo.

create table listagem (cores set('azul', 'verde',

'amarelo’, 'branco'));
insert into listagem (cores) values
('amarelo,verde,verde,cinza,roxo');
select cores from listagem

Neste exemplo, a tabela listagem é de nida de forma que possa receber entidades
com dados apenas pertencentes ao conjunto delimitado no parâmetro col set, e
cada tupla a ser inserida conterá dados não repetidos dentre as opções oferecidas,
avisando apenas em caso de dados repetidos estarem colocados no comando insert.

Como resultado da inserção, a consulta traria amarelo e verde como dados inseridos
na tabela, apenas, pois a repetição de verde é ignorada, e os dados cinza e roxo
descartados por não pertencerem ao conjunto de dados aceitos no domínio.

Por m, um tipo de dado bastante utilizado se refere ao trabalho com datas e horas
importantes para que não seja necessário utilizar tipos numéricos que deixariam os
componentes de data ou hora separados, ou texto que di cultaria cálculos de tempo.

O tipo date, por exemplo, suporta datas formatadas em um intervalo de 1000-01-01 a

9999-12-31 seguindo o padrão ano-mês-dia do SGBD, mas pode ser ajustado o
formato da data para nosso padrão dia-mês-ano através do uso de date_format
para converter o formato tanto na inserção, quanto na consulta ao banco, por
exemplo.

insert into cliente set data_nasc = str_to_date (

‘27/02/1990’, ‘%m/%d/%y’ );
select date_format (data_nasc, ‘%d/%m/%y’ ) from cliente;

100
A hora também segue o mesmo modelo de uso, e como padrão utiliza
hora:minuto:segundo que não se altera nas diferentes regiões do mundo, e pode ser
trabalhado com o comando date, estando limitado ao intervalo -838:59:59.000000 a
838:59:59.000000, sendo pouco provável que seja utilizada uma faixa tão grande de
tempo, exceto em dados históricos.

Outros tipos podem ser utilizados de acordo com as necessidades de cada projeto, e
uma consulta ao material o cial de cada SGBD utilizado juntamente com consultas a
livros e à web pode ser um bom caminho para se aperfeiçoar os conhecimentos
sobre tipos de dados que podem ser utilizados em banco de dados.

Com a aquisição dos conceitos dos tipos de dados, é possível analisar o contexto da
Figura 10, que traz um script para criação de uma tabela com maior detalhamento e
otimização dos atributos.

Figura 10

Fonte: O autor.

Neste script da Figura 10, é importante estar atento aos tipos utilizados nos atributos,
mas também, a outros parâmetros que foram já incluídos para que se compreenda
quão detalhada pode ser a de nição de um banco de dados.

101
No primeiro atributo, é importante destacar que, além de se utilizar o tipo tinyint
que reduz bem a quantidade de entidades aceitas, dando a impressão de uma ótima
otimização, é importante se lembrar da limitação do tipo a valores entre 0 e 255,
permitindo então a inserção de no máximo 256 tuplas de dados, insu ciente para a
maioria dos bancos de dados, sendo que para bancos grandes nem o tipo int seria
adequado.

Também consta o parâmetro not null que impede o atributo de ser mantido vazio,
obrigando a inserção de um valor, mas este valor é de nido automaticamente pelo
sistema em função do parâmetro auto_increment que adiciona uma unidade a cada
nova entidade neste atributo, garantindo a não repetição de dados.

Isso foi de nido para este atributo em função do que vem na última linha de
parâmetro de atributos do comando create table, que indica o atributo cod_cliente
como chave primária através do parâmetro primary key.

O segundo atributo nome_cliente está ajustado para aceitar até 30 caracteres

ajustando o armazenamento apenas aos caracteres signi cativos do texto e sendo
obrigatória sua inserção (not null).

O terceiro atributo utiliza o tipo numeric(11,0) para que possa ser um campo
numérico e não textual para o CPF, permitindo validação do mesmo pela regra
matemática de CPFs, sendo que o formato padrão atual deste documento utiliza 11
caracteres, sem afetar os documentos mais antigos que possuem menos dígitos que
este padrão atual.

São onze números sem o uso de casas decimais, fazendo com que 11 e 0 sejam
valores que delimitam bem a entrada de dados, impedindo números com mais de 11
dígitos, mas aceitando menos que isso, e não aceitando a inserção de pontos ou
vírgulas na digitação.

Por m, apenas é colocado um parâmetro adicional ao nal do comando para de nir

o padrão utf8 para que seja aceito um conjunto maior de caracteres, apenas para
ilustração, pois os dados utilizados nos atributos de nidos são bastante comuns, e
não seria necessária a especi cação deste padrão em casos assim.

Atributos bastante especí cos como sexo e dia da semana podem ser representados
como tipo enum, onde podemos indicar uma lista de dados aceitos e que são
validados na entrada de dados pelo usuário, como podemos ver no exemplo em que
o uso da palavra default garante que o atributo não seja cadastrado em branco na
ausência de um dado informado a ele, pois em casos assim, assumiria o dado
informado como padrão.

102
Compreender os conceitos relacionados aos atributos é importante para
poder elaborar tabelas para o armazenamento de conjuntos de entidades
de forma adequada e funcional. Observar quais os tipos de dados
corretos para os atributos é uma tarefa importante, assim como veri car
se devem ser marcados como obrigatórios, se devem ter seus dados
preenchidos, automaticamente, se possuem valores padrão de
preenchimento para facilitar a inserção de dados, etc. Mas talvez o mais
importante seja de nir, corretamente, e se possível, a composição de
atributos para formar a chave primária de cada tabela, observando se nas
tabelas, seria necessária a inserção de chaves estrangeiras e outros
pontos importantes.

103
 09

Linguagem SQL –
Variações em Consultas
104
A linguagem SQL possui todos os requisitos essenciais de gerenciamento para
banco de dados e, após conhecer a base de trabalho relacionada à criação de
bancos e suas tabelas com atributos, inserção e consulta de dados, inicia-se uma
etapa de apresentação de recursos complementares da linguagem.

Um recurso bastante utilizado e simples é o chamado alias, ou renomear tabelas

ou atributos em consultas, de forma a simpli car a exibição dos títulos das colunas
representativas de atributos nos resultados destas consultas.

Esse é um recurso interessante, pois com ele, atributos com nomes complexos,
como nomes mais simples e intuitivos para a listagem a ser exibida, permitem o
agrupamento de atributos para serem exibidos juntos sob um mesmo título.

select cod_cliente as codigo, nome_cliente as nome

from cliente;
select nome_cliente as nome, endereco_cliente + ', '
+ cidade_cliente + '' + estado_cliente as endereco from
cliente;

No primeiro exemplo acima, os atributos cod_cliente e nome_cliente são

identi cações não muito adequadas para relatórios a serem exibidas em reuniões,
por exemplo, diferente do que seria em uma avaliação do banco de dados por uma
equipe técnica de gerenciamento do mesmo, e o primeiro caso gera a necessidade
de uso da renomeação temporária dos atributos para código e nome,
respectivamente, mais intuitivos e apropriados.

O segundo exemplo é uma forma diferente de uso, onde o alias é utilizado como
recurso para que dados das entidades sejam uni cados sob um único título
endereço, para que este exiba os dados separados de atributos, que juntos
atendem a uma demanda especí ca de formato de endereço, desejado para uma
listagem resultante de uma consulta.

Outra forma bastante utilizada de uso do renome é para simpli car nomes de
tabelas em consultas envolvendo mais de uma tabela em intersecção para que o
cruzamento de dados possa ser feito e, assim, determinado critério possa de nir
qual combinação de dados retornar.

105
 select c.nome_cliente, p.descricao_produto from
cliente as c, produto asp, venda as v where v.
cliente_status = ‘Ativo’ and v.total >= 1000;

No exemplo acima, três tabelas são cruzadas com o intuito de que todas participem
do processo de execução de uma consulta, em que a tabela venda renomeada v é a
base da consulta e, a partir dos dados dos atributos nome_cliente e total são
selecionados os clientes ativos que realizaram compras de 1000 ou mais,
retornando apenas seus nomes e produtos adquiridos para determinado m.

Complementando os recursos para a elaboração de consultas, existem símbolos

especiais que podem ser usados como coringas na de nição de condições para
busca de dados.

Um exemplo bastante comum ocorre quando se buscam pessoas das quais não se
sabe todo o nome, e com o uso destes símbolos pode-se generalizar parte da
condição para que sejam retornados mais resultados que o esperado,
propositalmente, na esperança de que o que se busca esteja no resultado obtido.

Um destes símbolos é % que indica que quaisquer conjuntos de caracteres são

aceitos, e outro é _ que indica que um único caractere qualquer pode ser aceito,
fazendo com que seja possível de nir bem o que se espera obter como resultado.

Como exemplo, supondo que se coloque Jo_o em uma busca, tanto Joao quanto
João seriam resultados aceitos, mas também Joeo ou quaisquer resultados que
tivessem Jo e o com apenas algum caractere entre eles, assim como Elian_ traria
resultados como Eliana, Eliane, Eliani ou Eliany, por exemplo.

Para inserir esta forma de condição em comandos SQL, é utilizado o comando like
como operador para condição da cláusula where, servindo, então, como ltro em
consultas de forma isolada ou em conjunto com outros parâmetros.

select telefone_cliente from cliente where

nome_cliente like ‘Jo_o’;

106
O comando de consulta acima poderá trazer vários resultados em uma base com
várias tuplas de dados armazenadas, e pode acontecer de a lista vir desorganizada
di cultando sua leitura e busca por resultados especí cos.

Para melhorar a entrega de resultados de consultas, uma cláusula adicional pode

ser acrescentada utilizando-se o comando order by que permite a adição de um ou
mais atributos de tabelas em uso na consulta, de forma que a ordem de inserção
destes atributos no comando seja determinante na ordenação prioritária da lista
de resultados.

select nome_cliente, telefone_cliente from cliente

where nome_clientelike ‘Jo_o’ order by nome_cliente,
telefone_cliente asc;

O comando acima determina que nomes e telefones de clientes da tabela cliente

sejam exibidos em listagem, desde que o nome encontrado contenha os caracteres
indicados na cláusula where, e estes resultados devem ser classi cados em ordem
crescente pelo parâmetro asc, após os atributos da ordenação, primeiramente,
pelo nome e, em caso de nomes repetidos, ordenar pelo telefone.

Numa busca como esta, além da busca por dados desejados, pode ocorrer de
serem encontrados dados não desejados além dos imaginados na construção do
comando, pois podem retornar nomes e telefones iguais em mais de uma tupla
que poderia ou não ser representativo de tuplas duplicadas em função de entradas
de dados repetidas, mas é possível haver duas pessoas com mesmo nome e
telefone numa empresa, mas pode não ser aceito o cadastro de duas pessoas de
mesmo nome e telefone celular.

107
 É sempre importante estar atento, durante os estudos, em fontes
alternativas ou especi cidades de variações entre um SGBD e outro que
possam afetar o resultado daquilo que se aprende. O MySQL é a base
para os estudos, mas, paralelamente, é importante que se busquem
referências auxiliares para conhecer, por exemplo, como as consultas
podem ser elaboradas em um SGBD alternativo como o SQL Server da
Microsoft.

Leia mais em:

Operações Sobre Consultas

As consultas agem sobre tabelas buscando dados contidos em conjuntos de
entidades inseridos em tabelas, como é feito matematicamente em operações
realizadas em conjuntos de elementos.

Uma operação bastante utilizada em consultas é union que representa a união de

tuplas de duas tabelas através de um atributo que possuam em comum,
principalmente, em casos em que este atributo seja a chave primária em uma das
tabelas e chave estrangeira na outra.

Como podem ser usadas chaves ou atributos comuns, é bastante comum

resultados repetidos ocorrerem na consulta, mas existe uma alternativa caso seja
desejado que as repetições de dados sejam exibidas ou não, bastando para isto

108
utilizar o comando union para excluir resultados repetidos ou union all para
mostrar os mesmos resultados repetidos.

(select nome_cliente from cliente) union (select

nome_cliente from venda);
(select nome_cliente from cliente) union all (select
nome_cliente from venda);

A diferença do uso do termo all nos comandos select acima mostra que detalhes
in uenciam os resultados de cada comando, e como o gerenciamento de banco de
dados, através do uso da linguagem SQL, envolve a manipulação de bancos que
podem possuir milhares ou milhões de entidades de dados, é preciso estar atento
ao que deve ser feito e à escrita dos comandos em cada script escrito.

Outra operação relevante é a de intersecção de dados de tabelas que age de forma

diferente da união, sendo que a união uni ca dados de tabelas distintas e traz
todos os dados de duas tabelas somados, a intersecção veri ca ocorrências iguais
nas duas tabelas e traz como resultados, apenas as que ocorrerem,
simultaneamente, nas duas.

Um exemplo para ilustrar a diferença seria que com o uso de uma union entre uma
tabela de cadastro de clientes e outra de vendas para clientes, nomes de pessoas
seriam exibidos estando ou não os clientes cadastrados no sistema, vindos do
cadastro de clientes que podem ou não ter feito compras e de clientes que
realizaram compras estando ou não cadastrados na tabela de cadastro de clientes.

Usando a intersecção com o comando intersect que também possui a variante

intersect all, apenas seriam retornados clientes que realizaram compras na
empresa e que sejam cadastrados na tabela de cadastro de clientes, observando
que o uso do parâmetro all permitiria que nomes repetidos fossem trazidos como
resultados, o que seria algo comum, pois um cliente cadastrado pode realizar
várias comprar na empresa, gerando várias novas tuplas de dados.

(select nome_cliente from cliente) intersect (select

nome_cliente fromvenda);

109
 (select nome_cliente from cliente) intersect all
(select nome_clientefrom venda);

Outra alternativa de operador para consultas é bastante interessante, pois age

num subconjunto diferente de dados dos dois anteriores, union e intersect, pois
veri ca e traz como resultados, apenas dados de uma tabela que não esteja na
outra, ou seja, no caso do uso do comando except, os dados da segunda tabela
indicada servem de ltro e excluem os dados da primeira tabela equivalentes como
possíveis resultados da consulta.

(select nome_cliente from cliente) except (select

nome_cliente fromvenda);
(select nome_cliente from cliente) except all (select
nome_cliente fromvenda);

Este tipo de consulta pode ser bastante relevante, pois esta exclusão de dados faz
com que uma consulta como a exempli cada acima retorne o nome de todos os
clientes cadastrados que nunca compraram nada, pois não possuem seu nome
associado a nenhuma venda.

O uso de except all traz nomes repetidos que poderiam ser algo bastante comum
numa base de dados, e a inclusão de atributos-chave na consulta poderia garantir
que seriam pessoas diferentes, usando, por exemplo, o atributo de algum
documento pessoal como dado complementar nos resultados da consulta.

(select nome_cliente, cpf_cliente from cliente) union

all (selectnome_cliente from venda);

110
Algumas operações adicionais importantes para os estudos, nesta aula, são
relacionadas a cálculos que podem ser efetuados sob resultados de consultas,
sendo muito utilizados para gerar dados que não precisam ser armazenados num
banco de dados, pois podem ser obtidos a partir dos demais dados inseridos nas
entidades das tabelas.

Operações podem ser realizadas em dados numéricos, por exemplo, para que
dados úteis como médias, somas e contagem de elementos possam ser realizadas
adicionando operadores em comandos de consulta.

A contagem de entidades que atenderam a um critério de busca pode ser obtida

através da função count que, simplesmente, conta quantas ocorrências de um
determinado atributo ocorreriam como resultado de uma consulta, e exibe este
valor.

select count(*) from cliente;

select nota_fiscal, count(*) from venda group by
nota_fiscal;

Um comando como o do exemplo acima simplesmente exibirá a quantidade de

entidades encontradas na tabela cliente e devolverá, lembrando que pode ser
especi cado um atributo, e podem ser adicionadas condições, normalmente, ao
comando como um select comum, tendo apenas a função como parâmetro
adicional.

O segundo exemplo traz uma forma simples de se veri car inconsistência com um
atributo importante, fazendo uma consulta simples a todas as vendas e listando os
números de notas scais. Caso haja, por algum problema, algum número de nota
scal repetido, este será agrupado pela função group e caso haja mais de uma
venda com um mesmo número de nota scal, aparecerá no relatório.

Outra operação relevante para consultas se baseia no comando avg para calcular
médias e, assim como count, possui sintaxe simples, bastando associar um atributo
ou todos à função, e caso não seja atribuído um atributo não numérico que pode
retornar resultados inesperados, a média será calculada.

111
Caso seja adicionada alguma condição ao comando select, a função avg retornará à
média sobre os dados que seriam resultados da consulta apenas, e não sobre
todos os dados da tabela.

select avg(idade) from cliente;

select cod_cliente, sum (total_venda) from venda
group by cod_clientehaving sum (total_venda) >= 1000;

Este comando simples do exemplo mencionado traz um resultado relevante para

uma empresa, a média de idade de seus clientes, permitindo tomadas de decisão
em relação à inserção de novos produtos para venda, estratégias de marketing, etc.
e, de certa forma, servindo como ferramenta de Business Intelligence na gestão
empresarial.

No segundo exemplo, uma consulta mais complexa para análise de dados são
somadas às compras totais feitas por clientes com o uso do operador sum, mas um
limitador é utilizado no próprio agrupador de dados repetidos. As vendas são
agrupadas por código do cliente, mas limitando a listagem a clientes que tiveram
compras somadas de 1000 ou mais, excluindo da lista somas menores que este
valor.

Os operadores min e max também seguem a mesma sintaxe simples e necessitam

apenas serem colocados no lugar dos demais operadores utilizados para que se
tenham comandos alternativos para veri cação dos menores ou maiores valores
obtidos em uma consulta, como maiores vendas, menores quantidades de
produtos, etc.

112
Às vezes é preciso identi car inconsistências no banco de dados e,
assim como mostrado no conteúdo da aula, é possível uma consulta e
retornar se existem entidades nas quais um atributo repete dados e
não deveria.

Outra situação é na veri cação de dados inexistentes em atributos

essenciais como valores de vendas, quantidade de produtos vendida,
etc.

select nota_fiscal from venda where

total_venda is null;

Neste exemplo, é veri cado justamente se na tabela venda existe

alguma entidade na qual o total da venda não tenha sido indicada,
sendo um campo vazio identi cado com a constante null.

113
 10

Tópicos Complementares
em SQL
114
Dando sequência a uma etapa nal de estudos especí cos em linguagem SQL,
existem muitos conceitos e recursos que podem ser explorados ainda na linguagem
SQL, e que podem ser estudados à medida que se desenvolve maior conhecimento
dos conceitos e recursos fundamentais da linguagem.

Consultas Especializadas
Um dos recursos que podem ser explorados em consultas SQL é a possibilidade de
encadeamento de consultas para que se possa utilizar uma própria consulta SQL
como critério condicional para a cláusula where.

select distinct nome_cli, telefone_cli from cliente

where cod_cli in (select cod_cli from venda);

No exemplo, observa-se o uso do termo distinct logo após select para que não sejam
exibidos resultados repetidos de nomes, mas é importante lembrar que pessoas
diferentes podem possuir o mesmo nome e, com isto, o resultado desta consulta
poderia não ser correto, havendo o risco de exclusão de entidades de forma
equivocada, além de que o comando distinct se aplica apenas ao campo nome_cli
neste exemplo.

O ponto mais importante do exemplo acima é a inclusão de uma consulta como

condição para a consulta principal que procura por códigos de clientes associados a
vendas e a partir destes códigos, retorna os nomes de clientes da tabela de
cadastros.

O uso da variante not in antes da inclusão de uma subconsulta faz com que sejam
buscados apenas resultados que não satisfaçam o select inserido como condição,
fazendo com que dentro de todo o conjunto de entidades pesquisado, sejam
exibidos justamente os que não foram encontrados na subconsulta, servindo em
casos como a busca por clientes cadastrados que nunca realizaram compras ou que
estejam há algum tempo sem realizar compras, ambas informações muito úteis
numa empresa.

115
 Existem inúmeras combinações de comandos de consulta possíveis em
banco de dados e o uso das variações possíveis de parâmetros e
combinação de cláusulas são diretamente responsáveis por isso, e para
que se desenvolva a habilidade de elaboração de consultas, é preciso
praticar ao máximo este recurso.

Outra variante para o uso de subconsultas é o uso de > some que representa uma
indicação na consulta de que ao menos uma ou mais ocorrências encontradas
representam a condição da consulta para exibição de resultados, havendo a
possibilidade de se utilizar as alternativas < some, >= some, <= some, = some, e <>
some para que diferentes resultados da subconsulta sejam utilizados.

select distinct nome_cli, telefone_cli from cliente

where cod_cli >some (select cod_cli from venda);
select distinct nome_cli, telefone_cli from cliente
where cod_cli any(select cod_cli from venda);
select distinct nome_cli, telefone_cli from cliente
where cod_cli <=all (select cod_cli from venda);

E, no caso demonstrado, se ao menos uma ocorrência de cod_cli na tabela vendas

ocorra, nomes de clientes poderão ser exibidos como resultados da consulta.

Existe como alternativa a cláusula any com efeito semelhante e usado desde versões
bem mais antigas de SQL, assim como > all, < all, >= all, <= all, = all, e <> all que
servem como comparador entre o dado contido no campo e todos os resultados
obtidos na subconsulta.

116
Também é possível simplesmente veri car se alguma entidade atende a uma
determinada consulta inserida como condição, retornando verdadeiro (true) ou falso
(false) apenas pela adição da cláusula exists antes da subconsulta na cláusula where
da consulta principal.

select distinct nome_cli, telefone_cli from cliente

where exists (select* from venda where total_venda > 500);

O retorno de verdadeiro ou falso com o uso da cláusula exists afeta diretamente a

exibição ou não do nome de cliente e seu telefone no exemplo acima, de acordo com
a condição de alguma venda maior de 500 ter sido feita a ele.

Há variações para esta cláusula como not exists para que seja feita a veri cação
contrária de não existência de ocorrências que atendam à subconsulta, e pode-se
agregar a cláusula except para criar exceções para as subconsultas que contenham
exists ou not exists.

Outra opção interessante para complementar a construção de condições em

consultas é a cláusula unique que veri ca se existem resultados duplicados como
resultado da subconsulta, trazendo verdadeiro ou falso dependendo de haver ou não
duplicidade de tuplas de dados na consulta, como pode ocorrer no exemplo a seguir,
onde um mesmo cod_cli pode aparecer em várias vendas, uma ou nenhuma,
gerando os valores falso, verdadeiro e falso, respectivamente.

select distinct nome_cli, telefone_cli from cliente

where unique (select cod_cli from venda);

Views
Na medida em que são demandadas consultas de maior complexidade, gera-se um
problema de interpretação destas consultas, pois a quantidade de atributos, tabelas
envolvidas e condições para a obtenção de determinados resultados tendem a gerar

117
comandos muito longos e de difícil validação com relação à sua real e ciência e
assertividade.

Isso pode causar problemas de retorno de informações incompletas, equivocadas, ou

elaboradas com erros lógicos nas condições de ltragem que, muitas vezes, são
difíceis de serem corrigidos sem a reescrita de todo o comando.

Uma forma de facilitar a elaboração de consultas é criar as chamadas views para a

criação de tabelas temporárias estruturadas a partir de consultas para facilitar o
acesso a determinados resultados mais utilizados, evitando equívocos comuns de se
escrever comandos novos, ao invés de se utilizar comandos já criados e testados com
e ciência comprovada.

O uso desse recurso permite maior reúso das visões contendo bases otimizadas para
que mais de um usuário possa acessá-la diretamente, aumentam a segurança, pois
usuários podem ser direcionados a realizar consultas sobre views personalizadas que
ocultem dados necessários ou protegidos, e simpli ca a elaboração e consultas que,
muitas vezes, precisam conter menos ltros para a obtenção dos resultados
esperados.

create view visao_cli as (select c.nome_cli,

v.total_venda from c as cliente, v as venda where
v.total_venda >= 500);
select nome_cli from visao_cli where nome_cli like
‘A%’;

Pela exempli cação é fácil perceber a facilidade de se utilizar uma view como base
para outras consultas, e para isto basta incluí-la na cláusula from, lembrando que a
mesma deve ter sido construída, anteriormente, e é preciso que se conheça o que foi
gerado a partir dela. No exemplo, a view ltra nome e valores de compras realizados
com valor igual ou superior a 500, e a consulta posterior lista, dentre estes, aqueles
cujos nomes iniciam pela letra A.

118
Gerenciamento do Banco de Dados
Com sintaxe similar à do comando select, o comando delete exclui tuplas de dados
em tabelas a partir de condições especi cadas e parâmetros variados que permitem
que este comando extremamente perigoso seja bem construído e sua ação delineada
de forma segura e efetiva.

Importante observar que é um dos conceitos estudados mais a fundo, por último,
devido ao seu caráter perigoso, necessitando de atenção e que se tenha já uma base
de como se trabalha com um banco de dados e o que está ligado ao seu uso e
manipulação.

delete from venda;

delete from venda where total_venda between 0 and 499;
delete from cliente where cod_cli in (select cod_cli
from venda where avg (total_venda) < 300);

119
No exemplo citado, três diferentes formas de exclusão são de nidas, em que,
progressivamente, vai sendo aumentado o grau de complexidade dos comandos,
sendo o primeiro, a forma mais simples de uso da sintaxe, onde se indica apenas a
tabela que terá todo o seu conjunto de entidades excluído.

No segundo, apenas tuplas da tabela vendas onde o valor total armazenado de cada
venda seja um valor entre 0 e 499, e no terceiro exemplo, serão excluídos dados de
entidades que a partir da consulta sobre vendas terem médias de valor da venda
inferiores a 300.

Alguns parâmetros adicionais relevantes são limit que permite estabelecer uma
quantidade máxima de tuplas afetadas na exclusão, low_priority que indica ao
gerenciador para aguardar que nenhum usuário esteja utilizando a mesma tabela
para oferecer maior garantia de manutenção de integridade do banco e atomicidade
das operações realizadas. A cláusula ignore pode ser utilizada para que erros
gerenciáveis durante o processo sejam ignorados e o processo não seja
interrompido.

delete low_priority ignore from venda where total_venda

< 1000 limit 100;

Neste exemplo, são inseridas as cláusulas normais para de nição de tabela e

condição para exclusão, mas estão presentes as cláusulas adicionais low_priority para
um processo mais seguro e ignore para que não seja interrompida a ação. Também
foi adicionada a cláusula limit para que no máximo 100 tuplas sejam excluídas.

Outra ação bastante comum no gerenciamento de banco de dados é a inserção no

qual o uso do comando insert permite também o uso de cláusulas e parâmetros
complementares para a escrita de scripts para que dados sejam adicionados a tuplas,
gerando entidades para as tabelas em um banco de dados.

insert into cliente (cod_cli, nome_cli, cpf_cli) values

(18, ‘Pedro’, 02536266678);
insert low_priority ignore into venda (cod_venda,
total_venda) values (1, 200) on duplicate key update
total_venda = total_venda + 200;

120
Observando os exemplos colocados, o primeiro deles é um comando de inserção
tradicional que indica a tabela destino, e os atributos afetados entre parênteses, e os
dados a serem inseridos, respeitando os tipos e a ordem dos atributos indicados na
tabela.

No segundo exemplo, são adicionadas cláusulas complementares como low_priority

que gera uma menor prioridade da ação, por segurança, aguardando um momento
seguro para a execução, complementando que existe a opção high_priority que
realiza a ação contrária, mas menos segura.

O parâmetro ignore fará com que ocorrências sejam relevadas e a ação ocorra de
forma forçada, e a principal cláusula do segundo exemplo é on duplicate key update
que realiza o que é indicado após o comando update que, ao invés de gerar erros
pela duplicidade de chaves primárias, e ao invés da geração do erro, converte a ação
em atualização da tupla com base no critério indicado de somar o valor existente no
atributo com o novo valor indicado no comando.

Este método gera uma inserção de novas tuplas em uma tabela, mas serve também
para atualizar dados em entidades já existentes, mas não é a melhor forma de se
atualizar dados, pois existe um comando próprio update para esta nalidade que
possui uma sintaxe que segue um padrão semelhante aos demais comandos de
gerenciamento, com suas particularidades.

update poupanca set saldo = saldo * 1,005;

update cliente set status = ‘Bloqueado’ where
debito_cliente > 0;
update cliente set status = case
when debito_cliente > 0 then status = ‘Bloqueado’
else status = ‘Desbloqueado’
end;

121
Com base nos exemplos citados, é possível ver como é mais completo o comando
update em relação ao comando insert para esta nalidade, pois permite cláusulas
bem especí cas que auxiliam no processo de atualização de dados.

O primeiro exemplo de comando traz uma atualização simples e direta de saldos em

uma tabela de poupanças onde é adicionado automaticamente 0,5% de aumento
(equivalente a 1,005) em todos os saldos como uma atualização mensal, por
exemplo.

O segundo inclui uma condição que em caso de algum cliente possuir débito maior
que 0, o sistema, automaticamente, muda o status do mesmo para bloqueado,
servindo como um atualizador da situação cadastral de clientes inadimplentes.

O último traz um comando maior, com uma lógica mais complexa por trazer a
necessidade de interpretação de condicionais complementares num mesmo
comando, em que uma melhoria no comando do segundo exemplo é feita de forma
que se o débito for maior que zero, o status é bloqueado, mas, caso contrário, é
atualizado o atributo status como desbloqueado.

O uso de estruturas lógicas mais complexas, aproximando a linguagem

SQL das demais linguagens de programação é algo que oferece um
pequeno desa o extra no aprendizado do gerenciamento de banco de
dados. O SGBD SQL Server possui sintaxe bastante semelhante ao MySQL,
facilitando o aprendizado e mostrando que os SGBDs possuem certa
padronização sobre o uso da linguagem SQL, alterando recursos,
pontualmente, mas não necessariamente a base da linguagem.

Saiba mais em:

122
Um aspecto importante que complementa as ações estudadas até o momento de
manipulação de dados é o de que as alterações realizadas nos dados devem ser
con rmadas ou desfeitas em uma etapa posterior à execução dos scripts de
comandos, oferecendo uma garantia extra de que a ação desejada realmente foi a
executada.

O comando commit work tem a função de con rmar as modi cações realizadas por
comandos insert ou update, por exemplo, tornando os efeitos dos comandos
permanentes e o cializados perante o banco.

O comando rollback work realiza a ação de desfazer as ações de forma a retornar os

conjuntos de entidades a um estado anterior ao da execução dos comandos feitos
após o último commit work, lembrando que em ambos os comandos commit e
rollback, a palavra work é opcional.

É importante citar que rollback não desfaz o que foi feito antes de um commit, e uma
boa aplicação para rollback é a de associar seu uso a erros que podem ocorrer em
comandos ou desastres que necessitem de restauração de dados como em quedas
de energia, por exemplo.

Por m, existe um comando que possui a nalidade de mesclar dados de entidades

de tabelas distintas, mas que possuam algum atributo em comum que permita servir
de base para o processo de mesclagem.

select cod_cli, nome_cli, cpf_cli from cliente

inner join venda on cliente.cod_cliente =
venda.cod_cliente;

Existem variações para o comando join, como left join, right join e full join, além de
apenas join, observando que dependendo da versão do SGBD pode haver diferenças
no uso do comando, como o uso dos comandos inner join, left outer join, righ outer
join, e full outer join.

Essas variações do comando join servem para modi car os resultados de consultas,
como no caso do left join, que após veri car a igualdade de dados entre atributos de
duas tabelas, traz apenas dados da primeira tabela, enquanto que right join traz
dados da segunda que tenham correspondência na primeira tabela.

123
Pensando na teoria de conjuntos da matemática, o comando inner join seria
equivalente à intersecção de dados iguais nas duas tabelas, ignorando dados que não
estejam simultaneamente nas duas tabelas.

A opção left join resultaria em uma listagem que conteria todas as tuplas da primeira
tabela mesclada com dados da segunda, quando houver correspondência (incluindo
null nos atributos sem correspondência), e right join retornaria uma listagem
contendo todas as tuplas da segunda tabela mesclada com a primeira, mas
constando null nos atributos da primeira sem correspondência.

Imagem 44
select * from cliente left join venda on cliente.cod_cli =
venda.cod_cli;

cod_cli nome_cli cpf_cli cod_venda cod_cli total_venda

1 Pedro 02536521495 7 1 520

2 Márcio 12536523611 52 2 1200

3 João 03569863244 null null Null

Fonte: O autor.

Observando a imagem 44, temos um exemplo de resultado obtido por uma consulta
contendo a cláusula left join onde todas as tuplas da tabela cliente indicada pela cor
amarela e na parte azul, os dados das tuplas da tabela venda, quando os valores de
cod_cli das duas tabelas sejam iguais, caso contrário, retornando null.

Mudando para right join, a diferença seria de que todas as tuplas da tabela venda
seriam exibidas como resultado da consulta, mescladas com as tuplas da tabela
cliente, caso contrário, quando houvesse correspondência ou null.

124
Por m, full join une todas as tuplas das duas tabelas indicadas e exibe os atributos
indicados a partir de uma regra de correspondência de atributos, reforçando a
importância da correta estruturação das tabelas com atributos, chave primária e
chave estrangeira.

select c.nome_cli, v.cod_venda from cliente as c full

outer join venda as v on c.cod_cli = v.cod_cli order by
c.nome_cli;

Após conhecer diversos conceitos e exemplos de uso da linguagem SQL, é importante

reforçar que existem mais conteúdos que podem ser estudados na linguagem SQL e
que, certamente, agrega mais conhecimento e recursos para um bom gerenciamento
de dados em um SGBD.

125
Outras cláusulas podem ser estudadas e agregar conhecimento útil para o
trabalho com banco de dados, como já citado, anteriormente, e uma
cláusula interessante é a baseada no termo having que adiciona uma
condição para que um agrupamento de dados seja feito, mas com a
exibição de dados apenas quando a condição for satisfeita.

select count (cod_cli), estado_cli from

cliente group by estado_cli having count
(cod_cli) >= 10;

Neste exemplo, os clientes de um cadastro são contados e agrupados por

estado, sendo que a exibição destes dados ocorre apenas se a base de
clientes do estado tiver dez ou mais clientes cadastrados.

126
 11

Banco de Dados Orientados

a Objetos e Banco de Dados
XML
127
Durante décadas, a forma como os dados foram armazenados ou expostos era
padronizada pelo isso dos bancos de dados, mas com o surgimento e a
popularização da Internet, o gerenciamento de dados começou a ser de nido.

Inicialmente, a Internet trabalhava com o chamado hipertexto, que continha textos

formatados em páginas, postados em equipamentos espalhados pelo planeta e
disponibilizados através de um protocolo bem de nido de comunicação – o TCP-IP.

Aos poucos, o contexto dessas páginas foi adaptado às inovações tecnológicas que
foram sendo agregadas à Internet, e o tipo de conteúdo foi incrementado com outros
tipos de dados, mas mantendo a ideia das páginas.

Isso seguia na contramão das estruturas todas padronizadas dos bancos de dados
relacionais, e quando as páginas web evoluíram ao ponto de poderem conter todo
um conjunto de conteúdo não diretamente visível aos usuários, como banco de
dados conectados a sistemas de informação, uma nova forma de organização de
dados começou a ser pensada, e linguagens próprias para a web como o HTML e o
XML ganharam muita força dentre os pro ssionais de TI.

Com o tempo, essas linguagens de marcação para criação de páginas de hipertexto

foram se associando a outras linguagens como CSS, PHP, Javascript e Java de
diferentes formas para permitir a constante geração de inovações que se vê na
Internet.

128
Uma diferença importante em XML que resulta numa opção a ser estudada neste
material é que a linguagem XML possui recursos para trabalhar com banco de dados
e outros tipos de estruturas de dados.

A maneira como é estruturada um script HTML e um XML difere de forma a favorecer

a adequação da XML para banco de dados, pois é possível a criação das chamadas
tags especí cas de identi cação não só de palavras reservadas indicadas por sinais
de < e >, mas também de outros tipos de elementos.

Assim, aplicações criadas para acessar banco de dados através da Internet podem
utilizar a XML, como interface de acesso aos usuários com um processo de
desenvolvimento menos complexo do que utilizando linguagens de programação
tradicionais.

Imagem 46

<Título>Cadastro de Clientes</Título>
<cadastro>
<cliente>
<cod_cliente> 1 </cod_cliente>
<nome_cliente> Pedro </nome_cliente>
<cpf_cliente> 02456398563 </cpf_cliente>
</cliente>
<cliente>
<cod_cliente> 2 </cod_cliente>
<nome_cliente> Marcelo </nome_cliente>
<cpf_cliente> 12365496345 </cpf_cliente>
</cliente>
</cadastro>

Fonte: autor.

129
Observando o script da imagem 46, um exemplo em XML traz uma forma de
representação da estrutura de uma tabela onde são inseridas duas tuplas de dados
para comporem duas entidades.

A tag, logo na primeira linha do exemplo, indica uma informação de identi cação do
script em relação à sua nalidade, observando que o padrão em XML é que seja
colocada uma tag inicial e uma nal usando uma barra para diferenciação destas
funções, e tendo um texto identi cador da funcionalidade do script.

Também é incluída uma tag de identi cação da estrutura ou processo a ser

executado que, no caso deste exemplo, é cadastro que é aberto logo após o Título e
encerrado ao nal das demais tags.

As demais tags são para a operação de inserção de dados numa tabela cliente de um
banco de dados, adicionando os dados para composição de duas tuplas em um
formato não baseado no modelo relacional, exatamente, mas seguindo uma ideia de
divisão dos dados em atributos como ocorre no modelo.

insert into cliente (cod_cliente, nome_cliente,

cpf_cliente) values (1,’Pedro’, 02456398563);
insert into cliente (cod_cliente, nome_cliente,
cpf_cliente) values (2,’Marcelo’, 12365496345);

Um script semelhante ao que seria feito no modelo relacional usando SQL poderia
ser criado com os comandos indicados acima através do uso do comando insert para
adicionar os mesmos dados numa tabela chamada cliente.

Um script criado em XML pode ser utilizado para gerenciar o processo de inserção
em um banco de dados utilizando o processo similar ao do modelo relacional, mas
pode também permitir estruturas menos padronizadas, assim como as tags podem
ser organizadas em níveis e subníveis para a de nição da inserção de dados em
formatos mais exíveis.

130
Imagem 47

<Título>Venda</Título>
<venda>
<dados>
<cod_venda> 1 </cod_venda>
<nota_fiscal_venda> 1 </notafiscalvenda>
<data_venda> 10/2/2021 </data_venda>
<cod_cliente> 1 </cod_cliente>
</dados>
<produtos>
<cod_produto> 2 </cod_produto>
<total_produto> 100,00 </total_produto>
<cod_produto> 5 </cod_produto>
<total_produto> 5000,00 </total_produto>
<cod_produto> 18 </cod_produto>
<total_produto> 250,00 </total_produto>
</produtos>
<fechamento>
<total_venda> 5350,00 </total_venda>
<forma_pagto_venda> Dinheiro </forma_pagto_venda>
</fechamento>
</venda>

Fonte: autor.

131
Nesse exemplo da imagem 47, a base da estruturação do script segue o mesmo
estilo, mas os dados e a estruturação desses é que varia, dividindo a estrutura da
venda em outras três subestruturas de dados, produtos e fechamento com suas
respectivas tags, e tags aninhadas equivalentes a atributos com os dados.

Na estrutura de nida, uma venda conteria dados básicos como número da venda,
nota scal, cliente e data, três produtos lançados na venda, e uma parte nal
contendo o valor total e a forma de pagamento.

Fazendo uma comparação entre o uso da linguagem XML para o gerenciamento de

dados de forma mais livre e o modelo relacional, existem pontos positivos e
negativos numa comparação direta entre as duas opções.

O uso das tags pode não ser o método mais garantido, pois elas se repetem ao longo
do script, mas, por outro lado, servem como indicadores para facilitar a
documentação pela forma como são escritas.

Por ser mais livre o formato, novas tags referentes a atributos e seus
dados podem ser adicionadas ou excluídas mais livremente, sendo que
numa transmissão de dados entre origem e destino pela web, o
destinatário possui mecanismos para adaptar sua absorção aos dados
enviados, ignorando dados não esperados e deixando nulos os não
informados pelas tags.

132
Um terceiro ponto relevante é que a estrutura exibida na imagem 47, num modelo
relacional seria mais complexo, envolvendo entidades e relacionamentos separados
com scripts de maior complexidade, enquanto em XML, bastou-se encadear tags em
níveis para que se pudesse identi car níveis de aninhamento dos dados.

Para simpli car a nomenclatura de tags e seus conteúdos, será utilizada a

nomenclatura utilizada por Silberschatz (2020), em que esse bloco delimitado por tag
inicial e nal é chamado elemento, lembrando que os elementos podem conter
outros elementos dentro de seu conteúdo de forma aninhada.

Inicialmente, todo script gerado em um documento começa com uma tag principal
que é fechada ao nal do documento, encerrando o script, e as demais tags cam
praticamente todas dentro desta principal, exceto pela tag de Título mostrada nos
exemplos.

Além da sintaxe padrão de se utilizar uma tag inicial e nal para delimitar blocos de
outras tags, há casos em que uma tag única pode já servir para de nir alguma ação
simples, por exemplo, com uma sintaxe simples como a utilizada para se pular linhas
<br/>.

Também existe a possibilidade de se adicionar parâmetros em tags para que outras

de nições sejam possíveis ou ajustes nas ações realizadas pelas tags como a
possibilidade de se atribuir um alias para um endereço relacionado à web que se
torna incômodo na escrita de scripts, tornando-o mais curto e intuitivo.

133
 <vendas xmlns: site = “https://www.site_exemplo.com”>
<site:cliente>
...
</site:cliente >
</vendas>

Com o uso de um nome alternativo escolhido para representar um endereço web

completo, como no exemplo acima, o uso do alias site torna todo o conjunto de tags
contidas no bloco relacionado à tag <vendas> mais fácil de ser escrito, além da
escolha de nomes intuitivos para alias também se mostrar uma boa prática.

Outro conceito adaptável para XML do modelo relacional é o de schema o qual se

pode delimitar domínios e permissões de acesso a um banco de dados, mesmo
sabendo-se que a linguagem XML por padrão não estrutura dados como o modelo
relacional faz, dando a impressão de que todos os dados são de um mesmo formato
sem restrições.

Uma forma de se de nir schemas é através da inclusão da tag DOCTYPE, relacionada

à chamada DTD (Doctype Type De nition), opcional dentro de um script XML, mas
que pode fornecer importantes de nições para o restante do script no qual o próprio
banco de dados e elementos contidos no banco podem ser descritos.

134
 Imagem 48

<!DOCTYPE vendas [
<!ELEMENT vendas ( (cliente | produto | venda) +)>
<!ELEMENT cliente ( (cod_cli nome_clie cpf_cli) )>
<!ELEMENT produto ( (cod_prod descrição_prod
valor_prod) )>
<!ELEMENT venda ( (cod_venda nota_fiscal total_venda
cod_cli cod_prod) +)>
<!ELEMENT cod_cli ( #PCDATA ) >
<!ELEMENT nome_cli ( #PCDATA ) >
... Demais atributos ...
] >
<vendas>
<cliente cod_cli = “1” nome_cli = “Pedro” cpf_cli =
“12345678921”>
<cliente cod_cli = “2” nome_cli = “Márcio” cpf_cli =
“02536598532”>
</vendas>

Fonte: autor.

Estudando o exemplo da imagem 48, o uso da tag DOCTYPE permitiu a de nição de

toda uma estrutura de dados, partindo do banco de dados e seus elementos, depois
de cada elemento e seus subelementos e, na sequência, a de nição destes
subelementos e tipo de dados aceito #PCDATA que se refere a dados textuais que
deveriam ser de nidos para todos os atributos, mas alguns foram omitidos por
serem repetitivos.

135
Depois de de nida a estrutura pela DTD no script XML, a tag <vendas> atribuiu dados
ao banco para a geração de dois elementos, mas que poderiam ser muitos mais,
tanto para a mesma estrutura cliente quanto para as demais produto e venda.

XMLSchema
Tendo uma sintaxe simples e recursos limitados, a DTD não consegue, por exemplo,
de nir um domínio exato de dados como números positivos ou um determinado
intervalo de valores, por exemplo, mas é algo que pode ser melhorado com o uso do
chamado XMLSchema que permite de nições mais precisas como de tipos string ou
decimal ou parâmetros que delimitam intervalos de valores.

Imagem 49

<exemplo: schema xmlns: exemplo =

“https://www.siteexemplo.com”>
<exemplo: element name = “vendas” type = “Detalhes” />
<exemplo: element name = “cliente”>
<exemplo: complexType>
<exemplo: sequence>
<exemplo: element name= ”cod_cli” type= “exemplo:
decimal”/>
<exemplo: element name= ”nome_cli” type=
“exemplo: string”/>
<exemplo: element name= ”cpf_cli” type= “exemplo:
decimal”/>
</exemplo: sequence>
</exemplo: complexType>
</exemplo: element>
<exemplo: complexType name= “Detalhes”>
<exemplo: sequence>

136
 <exemplo: element ref= ”cliente” minOccurs=”1”
maxOccurs= “unbounded”/>
</exemplo: sequence>
</exemplo: complexType>
</exemplo: schema>

Fonte: autor.

Analisando o exemplo da imagem 49, um schema é criado a partir da de nição de

um alias para um endereço web como citado anteriormente, e todos os demais
elementos são de nidos dentro deste schema.

Pela sintaxe da linguagem XML, identi ca-se o banco e, neste exemplo, indica-se que
ele deve ser ajustado de acordo com o tipo Detalhes que é especi cado mais ao nal
do script para determinar que faixa de valores representam os dados numéricos a
serem inseridos.

O elemento cliente, pertencente ao banco vendas, é de nido dentro de uma nova tag
complexType que de ne elementos mais detalhados, e sequence, outro elemento
utilizado na sintaxe da de nição dos atributos do registro de dados.

Em cada atributo, a cláusula type indica o tipo de dado para o elemento, e este tipo
pode ser melhor descrito como feito no elemento complexType que de ne,
realmente, as especi cidades do tipo Detalhes criado para uso no exemplo onde é
indicado que os dados numéricos não podem ser menores que 1.

Para especi car adequadamente a estrutura de dados, é possível indicar que os

elementos contidos na de nição de um elemento representam atributos utilizando-
se a cláusula attribute e chaves primárias e estrangeiras com base na cláusula key.

137
 Imagem 50

<exemplo: attribute name= “cod_cli”/>

<exemplo: attribute name= “nome_cli”/>
...
<exemplo: key name= “chave_cli”>
<exemplo: selector xpath= “vendas/cliente”/>
<exemplo: field xpath= “cod_cli”/>
</exemplo: key>
<exemplo: keyref name=”venda” refer= “chave _cli”>
<exemplo: selector xpath= “vendas/venda”/>
<exemplo: field xpath= “cod_cli”/>
<exemplo: keyref/>

Fonte: autor.

Pelo exemplo da imagem 50 é possível separar o mesmo em três partes, sendo as

duas primeiras linhas de nições de elementos como atributos, apenas para mostrar
um exemplo de como seria a de nição dos elementos.

Na segunda parte, a indicação do atributo cod_cli como chave para o elemento

cliente, com o uso da tag key de nindo a chave pelo nome chave_cli, e dentro desta,
dois elementos que indicam o caminho do atributo no banco e o elemento original
que serve de base para a chave.

E, na terceira parte, a tag keyref traz o conceito de chave estrangeira, de nindo para
o elemento venda, a chave_cli de nida, anteriormente, com chave estrangeira, sendo
indicados também o caminho para os dados e a qual atributo se refere a chave.

138
 Dados contidos em formato XML podem ser convertidos para uso em
SGBDs como MySQL, observando-se que, para que seja possível, a
estrutura do banco em XML deve ser compatível com a utilizada no
modelo relacional para o MySQL.

Consulta XPath
As consultas em banco de dados XMl podem também ser realizadas, mas o processo
é diferente das consultas em bases relacionais, pois o formato dos elementos é
diferente das tabelas e atributos da modelagem relacional.

Com sintaxe bastante simpli cada, sua utilização se baseia na indicação de

expressões que indicam caminhos para o banco de dados e que com base no que é
indicado no comando, retorna valores.

/vendas/cliente/nome_cli/text ()
Pedro
Márcio

139
A expressão acima traria como retornos os elementos indicados logo em seguida no
exemplo, e o uso do termo text () ao nal do caminho possui a função de não mostrar
tags com o nome do elemento no resultado, e apenas os dados em si.

Pode-se re nar as consultas acrescentado-se cláusulas adicionais como feito em SQL

para que seja possível ltrar resultados e se obtenham os resultados esperados.

/vendas/produto[valor_prod>100]
/vendas/produto[valor_prod>100]/ @cod_cli

Nos exemplos acima, o primeiro traz como retorno uma lista contendo elementos
com valor acima de 100, e o exemplo seguinte traz apenas o elemento cod_cli das
mesmas tuplas de dados encontradas usando a mesma condição de ltragem.

140
Outra alternativa para busca em um banco de dados XML é usar XQuery
que traz a base da linguagem XML adaptada para os conceitos da SQL
oferecendo uma alternativa ao uso de XPath.

A base de uma consulta XQuery são os comandos for, let, where, order by
e return (FLWOR) que compõem a sintaxe para um comando de consulta
de dados como se pode ver no exemplo a seguir, no qual for de ne uma
variável que recebe um a um os dados do elemento indicado no banco,
where uma condição para uso ou não dos dados, order by indica o
elemento que serve de base para ordenação dos dados, e return quais
dados serão exibidos (let pode realizar atribuições de dados lidos a
variáveis).

for $x in /vendas/venda
where $x > 100
order by $x
return $x

141
 12

Gerenciamento
de Transações
142
Segundo Silberschatz (2020), uma transação se refere a uma ação completa de
manipulação de dados, iniciada por um script ou software que possuam em seu
código, comandos similares à begin transaction e end transaction para iniciar e
nalizar o processo da transação.

As transações estão diretamente ligadas à integridade do banco de dados e envolve o

conjunto de propriedades chamadas ACID relacionadas aos conceitos de
atomicidade, consistência, isolamento e durabilidade.

A atomicidade representa a ideia de que uma transação deve ocorrer de forma

única sem que seja fracionada ou interrompida de forma a garantir que dados não se
percam ou sejam corrompidos. Também se refere à ideia de que os atributos de uma
entidade devem conter dados únicos e não deve ser permitida a ocorrência de dados
múltiplos em um atributo, o que tornaria a identi cação do dado correto relacionado
a uma entidade.

O segundo conceito de consistência se refere a um aspecto complementar da

atomicidade que, após o término de uma transação, o estado anterior do banco de
dados em que as regras de consistência do mesmo que estavam corretas, devem se
manter, envolvendo a garantia de que as chaves primárias não possuem valores
repetidos, tipos de dados respeitados, restrições dos atributos ou constraints que
representam objetos para de nição de regras de integridades do banco, operações
em cascata ou cascade entre chaves primárias e estrangeiras como exemplo, e
gatilhos ou triggers SQL que acionam eventos especiais de nidos na estruturação e
gerenciamento do banco de dados.

Qualquer ação realizada por scripts SQL ou em outra linguagem não deve corromper
ou afetar negativamente a integridade e consistência do banco e suas regras e, para
isso, as ações podem incluir regras de validação da entrada de dados como
validações de campos chave ou com formatos especiais como no caso de dados de
CPF, telefones, etc.

O terceiro conceito de isolamento é extremamente importante em banco de dados

que podem ser compartilhados entre dois ou mais usuários, simultaneamente, pois
uma mesma entidade não pode ter seus dados atualizados por mais de um processo
para evitar a perda da integridade dos dados que teriam seus dados perdidos total
ou parcialmente, fato que não deve ocorrer.

Técnicas que envolvam meios de que atualizações de dados em uma mesma base
ocorram de forma paralela para os usuários, mas de forma serial no banco de dados,
no qual cada usuário teria deu processamento realizado, individualmente, e seguindo

143
algum algoritmo de ordenação de processos e isolamento do acesso ao banco para
atualizações.

Processos concorrentes são muito comuns em banco de dados, pois com a evolução
tecnológica ocorrida, primeiro com a introdução das redes locais, até a atual
globalização dos bancos de dados pela Internet em que é possível que milhares de
usuários ou processos estejam acessando paralelamente um banco de dados.

Por m, a durabilidade representa a garantia de que as transações nalizadas sejam

garantidas de forma permanente em disco e não apenas em armazenamento
temporário para evitar perdas por desastres que podem ocorrer durante o
funcionamento de uma infraestrutura, desde uma simples queda de luz, a falhas de
equipamentos, eventos naturais, etc., sendo este processo chamado de commit em
linguagem SQL.

Este processo envolve a veri cação da atualização efetiva dos dados após uma
transação, se necessária, controle de versões do estado do banco de dados e outras
validações necessárias para garantir que nada se perca ao nal de cada transação
ocorrida.

Geralmente, as transações ocorrem sobre um banco de dados na forma de leitura de

dados ou de escrita de dados, além de atualizações e exclusões, e estas ações podem
ser resumidas pela sigla CRUD, representativa dos termos Create (criar), Read (ler),
Update (atualizar) e Delete (excluir).

As operações de leitura são nitidamente as mais seguras, pois não

alteram dados no banco de dados, mas geram um pequeno risco pela
necessidade de abertura do banco de dados e reserva do mesmo para a
transação e, por isso, também precisa ser uma operação monitorada pelo
SGBD.

A operação de escrita transfere dados em memória temporária para o

armazenamento permanente do banco, logo na transação, mesmo que de forma
temporária, para uma segunda etapa de gravação física dos dados em disco, caso o
processo seja feito em duas etapas, como em sistemas que trabalham com uma
etapa intermediária de gravação antes da efetiva atualização do banco de dados por
segurança.

144
Por adicionar novos dados, esse processo envolve também a organização de todo o
banco para acomodação da nova entidade e isso envolve indexação das chaves e
organização estrutural dos dados sicamente em disco.

A operação de atualização envolve menos processos que a criação, pois,

normalmente, não manipula a indexação, mas envolve, em alguns casos, ajustes no
armazenamento em disco, mas, geralmente, uma transação deste tipo se baseia
apenas na alteração de dados de uma ou mais entidades.

Por m, o processo de exclusão também afeta a organização do banco de dados de

duas formas distintas, sendo uma a de apenas remover a ligação de uma entidade
com outras do banco que sejam diretamente ligadas a ela para manutenção da
integridade estrutural dos dados, ou a liberação do espaço físico em disco para que
outros dados possam ser armazenados naquele espaço, além da reorganização
estrutural citada.

Como dito, todos esses processos podem não ocorrer efetiva e instantaneamente no
momento da transação, gerando uma lista de transações realizadas e afetando um
banco de dados temporário que, em determinado momento, irá efetivar as
transações no banco original de forma permanente, mas independentemente de
como seja o processo, em uma ou mais etapas, todo o processo envolve a gravação
dos estados em disco para garantir um dos 4 conceitos ACID de durabilidade.

Existem casos nos quais as transações vão atualizando dados de entidades que
podem depois serem utilizados em outras transações, e isto é outro motivo para que
as transações sejam realizadas em sequência e com a integridade e os demais

145
aspectos respeitados, de forma a evitar um efeito cascata de problemas ocasionados
pela falha na atualização de alguma transação dentro de uma sequência.

Para conhecer mais sobre os aspectos estudados ao longo das aulas, é

preciso buscar fontes alternativas e conhecer conceitos importantes
citados por diferentes fontes, se necessário.

Estados de Transações
As transações ocorrem a todo momento, sendo nalizadas e concretizadas como
esperado (commit), mas há casos em que as transações podem não ser executadas
como esperado e são abortadas, gerando um processo muito importante relacionado
a esta interrupção.

O chamado processo de rollback é aquele que deve ocorrer após a interrupção ou

falha de uma transação no qual o estado anterior do banco de dados deve ser
devolvido no caso de alterações terem ocorrido ou, simplesmente, ter seu estado
original inalterado caso não tenham sido feitas atualizações de dados.

Não representa, necessariamente, um processo de reversão, mas sim, de

recuperação dos dados em um estado anterior, sendo que para isto, geralmente, são
mantidas versões do banco para garantir este processo durante as transações.

Após a ocorrência de uma transação de modo completo, o estado do banco de dados

é atualizado e o estado anterior deixa de existir para permitir a criação de um novo
estado após nova transação ocorrer.

146
Se for desejada uma espécie de reversão de alguma mudança ocorrida, é preciso
gerar uma atualização dos mesmos dados de forma a reverter, manualmente, os
dados alterados necessários, como no caso de uma transferência indevida de valores
para uma conta que precise ser desfeita.

No caso de uma transação monetária, por exemplo, se ela for realizada com sucesso,
gerará um novo estado do banco de dados, mas pode ocorrer de ser solicitado um
estorno da mesma, mas isto não é considerado um rollback. É preciso gerar uma
nova transação, debitando o valor se tiver sido depositado, ou depositado o mesmo
valor no caso de uma retirada que foi desfeita.

Silberschatz (2020) de ne 5 estados para uma transação que se inicia ativa e assim
permanece enquanto os processos vão sendo realizados e, em dado momento, a
transação pode passar para um outro estado de parcialmente con rmada ao nal do
processamento da transação, ou ter seu status alterado para falha em caso do não
processamento correto.

Caso uma transação entre no estado de parcialmente con rmada, ainda pode
ocorrer algum erro como na gravação dos dados pelo SBGD ou na etapa do sistema
operacional e o status mudar para falha, mas caso tudo ocorra como devido,
caminhará para um estado de con rmada em que se obtém todo o ACID relacionado
à transação.

Por outro lado, se ocorre a falha, se a mesma acontece logo durante o

processamento da transação, os processos acabam não sendo concluídos e um
status de abortada ocorre, mantendo o banco em seu estado original de antes da
transação, mas pode acontecer de dados terem sido parcialmente modi cados e o
banco ter mudado de status, necessitando, assim, de um rollback para retornar o
banco a um status original anterior à transação.

No caso de falha na transação, a mesma pode ser reexecutada se for um erro que
possa ser contornado por algum motivo de momento, como queda de luz, por
exemplo, mas pode ser encerrada (kill) em caso de erros na geração da própria
transação, por exemplo.

O processo de geração de uma cópia do banco de dados para que se tenha dois
estados do mesmo a cada transação pode parecer complexo e exagerado, mas, na
verdade, é a melhor forma de se garantir a possibilidade de um rollback quando
necessário, mas é importante observar que a cópia de segurança é não gerar uma
cópia extra a cada transação, pois seria insustentável do ponto de vista físico de
armazenamento.

147
A chamada cópia de sombra é criada logo no início do processamento de uma
transação, antes que a mesma possa gerar alguma alteração no banco, e se mantém
durante todo o processamento até que um commit ou um rollback ocorra com a
transação.

No caso de ocorrer um commit e a transação efetivamente for concretizada, a cópia

de sombra não mais será utilizada, tornando-se descartável para que numa próxima
transação, o espaço ocupado sicamente possa ser reescrito por uma nova cópia de
sobra, de acordo com o gerenciamento de disco do sistema operacional.

Caso ocorra um rollback, a cópia de sombra se torna a versão original do banco,

novamente, fazendo com que o banco utilizado no processamento da transação se
torne descartável pelo mesmo mecanismo de sobrescrita citado no caso de commit.

Transações Simultâneas
A chamada execução simultânea ou paralela de transações não acontece,
efetivamente, pois o banco de dados é único e deve ser mantido íntegro, aspecto que
não poderia ser garantido com mais de uma transação podendo modi car seus
dados num mesmo instante.

As modi cações poderiam ocorrer sobre dados sem ligação aparente no banco, mas
como existe uma rede de conexões entre tabelas e atributos de um banco, é difícil
garantir que uma transação não tenha in uência em mais de um ponto do banco de
dados.

Um atributo pode ser modi cado de forma a alterar apenas um dado de um atributo
comum especí co de uma tabela, como um ajuste em uma data de nascimento de
um cadastro de clientes, mas é preciso compreender que em cada caso, este dado
pode ter implicações maiores que apenas fazer parte de uma entidade, pois o dado
pode ter relação com o processamento de outras transações que podem, inclusive,
estar ocorrendo em paralelo.

Um exemplo bem simples seria a atualização de um ano inserido incorretamente em

uma pessoa num cadastro de pessoas e esta mudança gerar implicações como na
liberação de uma solicitação de entrada num processo de obtenção de carteira de
motorista para uma pessoa que poderia ter 17 anos, mas com o ajuste passe a ter 18,
mas que poderia ter sua solicitação negada se o processamento do pedido ocorrer
antes da atualização do ano de nascimento.

148
Outro caso poderia ser numa auditoria em um cadastro de pessoas que têm direito
ao recebimento de uma aposentadoria por um erro de cadastro e que, num ajuste,
poderia ser constatado o equívoco da idade e o benefício ser negado de forma justa,
mas ocorrendo em paralelo, poderia ser mantido até nova validação que pode
ocorrer apenas de tempos em tempos.

Além de haver a preocupação com a atualização do banco de dados em transações

simultâneas, existe o consumo de recursos de hardware associados aos processos
das transações como processamento e memórias temporária e permanente.

O chamado throughput se relaciona ao maior ou menor uso dos recursos de

hardware de forma a aumentar ou diminuir a ociosidade destes de acordo com as
necessidades de toda a infraestrutura. Geralmente, sistemas de banco de dados
tendem a tentar otimizar o uso do hardware aumentando o throughput pelo maior
processamento de transações por fração de tempo, mas cada sistema funciona de
maneira distinta de acordo com o modo como funciona o uso do banco de dados.

Alguns bancos estão ligados diretamente à Internet e geram transações 24 horas por
dia em maior ou menor volume, ao passo que sistemas locais podem ter janelas de
tempo para geração e processamento de transações, mas, de forma geral, sempre se
busca a otimização do throughput para que se possa reduzir tempos de resposta em
sistemas.

Essa busca pela melhor produtividade operacional re ete na implementação de

melhorias no processamento concorrente de transações e demais operações, pois
independentemente da forma como ocorra o throughput, a consistência não pode
ser afetada, assim como os demais aspectos do ACID.

Existem técnicas diferentes de gerenciamento de transações, baseadas nas técnicas

de gerenciamento de processos em sistemas operacionais, gerando oferta de
recursos de processamento para transações em função do tempo, mas garantindo a
atomicidade destas para evitar perda de integridade.

Transações maiores com vários processos podem ser fracionadas caso a divisão
destas envolva a efetiva realização dos processos inteiros que estejam contidos na
transação, mas que possam ser realizados separadamente de outros processos da
mesma transação, como no caso de várias inserções de dados numa mesma
transação que podem ser realizadas uma a uma em frações de tempo avulsas,
permitindo que outros processos de outras transações sejam realizados,
alternadamente, seguindo as mesmas regras de atomicidade.

149
Uma das características importantes do ACID, o isolamento, possui
relação direta com a concorrência de transações, e uma transação deve
ser executada por completo para ser considerada con rmada, mas para
se otimizar o gerenciamento e uso de um banco de dados, processos que
ocorrem em paralelo auxiliam na dinamicidade do uso, pois se muitos
usuários solicitam uma transação, mas todas são realizadas integralmente
em sequência, aquele que solicitou por último, poderia esperar por um
tempo desnecessário, assim como outros que solicitaram antes. Isto pode
ocorrer em função da demora na inserção manual de dados, por
exemplo, enquanto o processo de inserção não é realizado, todos os
recursos estariam bloqueados.

Trabalhar com processos em paralelo, mas mantendo as características

ACID é algo fundamental e aumenta muito o desempenho de um sistema
sobre um banco de dados, mas é preciso ter um controle muito e ciente
sobre a organização das transações para que ocorram sem gerar riscos ao
banco de dados. O isolamento pode ser obtido pelo bloqueio dos
recursos do banco de dados durante o processamento de uma única
transação, mas pode também ser feito de forma concorrente isolando
frações da transação e realizando-as com as mesmas garantias de uma
transação completa, permitindo que frações de transações vão sendo
executadas, sequencialmente, mas passando a impressão de transações
ocorrendo em paralelo.

150
 13

Controle de Concorrência
e Recuperação
151
Visando controlar o processamento concorrente de transações, mecanismos foram
criados para oferecer meios de que esse tipo de processo seja seguro e possa ao
mesmo tempo ser capaz de aumentar o throughput de uso de infraestrutura, e
garantir o isolamento necessário das transações e a integridade e durabilidade do
banco de dados.

Controle de Concorrência
Um mecanismo básico para oferecer essa possibilidade de concorrência segura de
transações é chamado de exclusão mútua, em que os recursos de banco de dados
sendo acessados por uma transação cam bloqueados para os demais, gerando um
isolamento da transação e garantindo os meios para uma correta execução dos
processos, independentemente de o resultado da transação ser falha (rollback) ou
con rmada (commit).

Quando se pensa em gerar bloqueios de itens em um banco de dados para

processamento de transações, existem duas possibilidades a serem levadas em
consideração e que podem oferecer maior throughput, ou maior segurança, de
acordo com o tipo de transação a ser executada.

Um tipo de bloqueio é parcial, permitindo que uma transação possa apenas acessar
dados do banco, em modo de leitura, sem poder realizar alterações, permitindo que
os mesmos dados sejam compartilhados entre outras transações com o mesmo tipo
de bloqueio, por exemplo, aumentando o uso de recurso de infraestrutura e de
acesso ao banco de dados.

Outro tipo é mais restritivo e exclusivo, permitindo que a transação realize todo tipo
de ação com os dados em uso, desde leitura à exclusão dos mesmos, sendo que,
neste mecanismo, todas as demais transações não possuem acesso nem de leitura
dos mesmos dados para evitar problemas com os aspectos relacionados ao ACID.

152
Imagem 53

TRANSAÇÃO 1 TRANSAÇÃO 2 TABELA

CONSULTA BLOQUEIO COMPARTILHADO 1

CONSULTA INSERÇÃO BLOQUEIO COMPARTILHADO 1

INSERÇÃO DESBLOQUEADO

INSERÇÃO BLOQUEIO EXCLUSIVO 2

ATUALIZAÇÃO INSERÇÃO BLOQUEIO EXCLUSIVO 2

ATUALIZAÇÃO INSERÇÃO BLOQUEIO EXCLUSIVO 2

ATUALIZAÇÃO DESBLOQUEADO

ATUALIZAÇÃO BLOQUEIO EXCLUSIVO 1

ATUALIZAÇÃO BLOQUEIO EXCLUSIVO 1

DESBLOQUEADO

Fonte: O autor.

A imagem 53 ilustra, de forma simpli cada, a forma como os bloqueios poderiam

ocorrer supondo que uma primeira transação solicitasse um bloqueio para consulta
de dados de uma tabela e o gerenciador bloqueasse a tabela de forma compartilhada
permitindo que outras transações de leitura possam ocorrer.

No caso do exemplo, uma outra transação de inserção de dados deseja utilizar a

mesma tabela, mas como se encontra bloqueada, mesmo que de forma
compartilhada, a tabela não pode ser acessada durante o bloqueio.

153
Depois de encerrada a transação de consulta, a tabela pode então ser desbloqueada
para ser requisitada pela transação 2 de inserção e, no passo seguinte, é efetivado
um bloqueio exclusivo para que se possa realizar a transação.

Durante esta transação de inserção, uma nova transação, desta vez, de atualização
de dados na tabela solicita acesso à tabela, mas a mesma se encontra bloqueada e a
transação ca em espera até a liberação da mesma.

Após a con rmação ou falha da transação 2 de inserção, novamente a tabela pode

ser desbloqueada, lembrando que em caso de falha, pode ser necessário aguardar
um processo de rollback do banco para que, então, possa ser desbloqueada a tabela
e possa ser acessada pela transação 1 de atualização, após novo bloqueio exclusivo
ser feito.

Da forma como é colocado no exemplo ilustrativo, da imagem 53, dá a impressão de

o processo ser realmente simples, mas a realidade é que muitas variáveis estão
envolvidas e o processo de bloqueio é complexo, pois é preciso resolver problemas
como o de solicitações simultâneas de transações e decisão de qual favorecer em um
bloqueio, falhas de infraestrutura que podem enganar os processos de bloqueios,
etc.

Uma situação que pode ocorrer e é até bastante provável seria de, durante um
bloqueio compartilhado para uma transação, outra de manipulação de dados esteja
aguardando a liberação do bloqueio para então poder ser realizada, mas neste meio
tempo, outra transação de consulta poderia surgir e aproveitar o status de bloqueio
compartilhado e também acessar os mesmos dados.

Isso alongaria o tempo de bloqueio do recurso em muitos casos, atrasando a

transação pendente e, num pior cenário, outras transações de consulta poderiam
ocorrer e adiar inde nidamente a transação de manipulação em espera.

Para evitar situações problemáticas como a citada, mecanismos de

controle de transações em espera podem auxiliar utilizando índices de
ordenação de transações, permitindo até a de nição de las com
prioridades de execução, como ocorre em processos envolvendo recursos
de hardware controlados pelo sistema operacional.

154
Silberschatz (2020) cita que pode ser utilizado um protocolo para bloqueio baseado
em duas fases, em que uma primeira fase é chamada de crescimento na qual uma
transação solicita bloqueio e o mesmo sendo concedido, realiza seu processamento.

Depois, ao terminar a transação, libera-se o bloqueio, mas a mesma entra numa fase
de encolhimento, e se precisar novamente de um bloqueio para outra etapa de sua
transação, ca impossibilitada de solicitar por determinado número de ciclos de
tempo, permitindo que outras transações possam ter iguais chances de obter
bloqueios e serem processadas.

Claro que as transações podem ser simples e necessitarem de um único bloqueio

para serem concluídas, não sendo afetadas diretamente pelo protocolo, mas
transações maiores com mais processos a serem realizadas precisam de protocolos
como este para organização da la de processos.

Também é possível organizar as transações em uma árvore baseada na teoria de

grafos onde cada transação é recursivamente inserida em uma lista que ordena as
transações de maneira a serem dependentes umas das outras para que se possa
organizar a la e os bloqueios e desbloqueios vão ocorrendo para atender a todos da
estrutura de árvore seguindo um algoritmo de deslocamento pela árvore similar aos
algoritmos de busca.

Imagem 54

FILA DE TRANSAÇÕES

TRANSAÇÃO A TRANSAÇÃO B

TRANSAÇÃO C TRANSAÇÃO D

TRANSAÇÃO F TRANSAÇÃO E

Fonte: O autor.

155
A ilustração da imagem 54 traz um exemplo de como poderia ser organizada a árvore
de transações, supondo que o bloqueio iniciaria permitindo à transação A ser a
primeira processada, mas existe a necessidade de manutenção da estrutura e, por
isso, a intersecção de todas as ligações entre as transações, ou raiz da árvore indica
apenas um nome para a estrutura, sendo as transações indicadas abaixo da raiz.

Assim, podem-se gerar algoritmos que possam percorrer as transações partindo de

pontos como prioridades, ordem de solicitação, tipos de transação, etc. permitindo
que diferentes algoritmos possam ser implementados para determinar a ordem de
liberação dos dados bloqueados para cada transação, lembrando que esta árvore de
transações pode se referir apenas a um conjunto de entidades de um banco e não ao
banco todo, por exemplo.

Existem outros métodos citados por Silberschatz (2020), como protocolos

timestamp que realiza a ordenação de forma antecipada, a regra de write
de Thomas que ajusta o algoritmo do protocolo timestamp reduzindo
operações obsoletas, protocolos baseados em validação que monitoram
as transações para veri car se rollbacks em cascata possam ocorrer.

Existem outros mecanismos também descritos por Silberschatz (2020) e

que podem oferecer maior aprofundamento conceitual no tema de
controle de concorrência de transações e permitirá maior conhecimento
sobre como organizar o gerenciamento de banco de dados.

Sistema de Recuperação
A recuperação de um banco de dados em casos de falha é muito importante e
garantir que dados não sejam corrompidos envolvem diretamente as propriedades
de atomicidade e durabilidade, envolvendo mecanismos para garantir o retorno de
um banco de dados ao seu estado anterior original em caso de falhas em transações.

156
As falhas, geralmente, podem estar associadas a problemas nas próprias transações,
como dados incorretos com as especi cações do banco ou consultas a dados
inexistentes, assim como impedimentos do próprio banco de dados em função de
paradas para manutenção, etc.

As falhas também podem estar associadas a problemas de disco como defeitos ou

capacidade esgotada, ou erros de sistema operacional que não permitem que
possam afetar tanto hardware quanto o próprio banco de dados.

No caso do armazenamento, especi camente, é preciso estar atento às formas

utilizadas que se resumem aos meios ditos voláteis como a memória RAM dos
equipamentos da infraestrutura que mantém dados enquanto houver energia
alimentando-os ou enquanto uma aplicação estiver no ar, sendo que os dados
contidos neste tipo de memória são muito suscetíveis a serem perdidos.

Outro tipo de memória dito não volátil se baseia em discos, como discos rígidos (HDs)
que podem estar alocados, localmente, ou através da Internet em locais remotos,
memórias do tipo ash, como pendrives e cartões diversos, tas magnéticas, etc. que
podem guardar dados mesmo com a ausência de energia, mas que podem ser
inseridos, alterados e excluídos, se desejado, sendo que ainda existe o risco de perda
de dados por processos equivocados de manipulação destes dispositivos.

Um terceiro tipo é chamado de estável ou permanente por permitir a inserção de

dados, mas sua exclusão não é permitida pelo disco ser dito apenas de escrita uma
única vez como ocorre em discos que são sicamente marcados no processo de

157
gravação como CDs e DVDs comuns, mas é possível, por outros meios, se obter um
meio próximo ao estável, mas ainda volátil.

O meio mais utilizado é o de memória não volátil para armazenamento de banco de

dados pela possibilidade de realização de todos os processos CRUD, essenciais para
as atividades de um banco de dados.

Uma forma de se obter um armazenamento seguro e menos volátil é por meio da

manutenção de uma ou mais cópias do banco de dados em diferentes discos que
podem estar num mesmo local, apenas para efeito de backup de segurança para
eventuais falhas do banco de dados considerado principal, se houver esta
classi cação na infraestrutura, pois algumas infraestruturas de TI são totalmente
replicadas para evitar desastres que comprometam mais do que apenas o meio de
armazenamento do banco de dados.

Um dos métodos de manutenção de cópias de segurança se baseia na tecnologia

RAID de discos idênticos ligados, paralelamente, em máquinas de forma a replicar
todo o seu conteúdo e serem capazes de manter as operações em caso de falha de
um dos discos, por exemplo, resultando em um nível de segurança de dados
bastante aceitável.

Este processo pode ser expandido através da cópia dos dados em mais de uma
máquina, podendo estas terem o mesmo mecanismo RAID de discos instalados, mas
sendo estas cópias gerenciadas entre as máquinas através do sistema do banco de
dados, pois a tecnologia em si é criada em nível de hardware da máquina.

158
Também é possível que máquinas dedicadas ao armazenamento estejam localizadas
em pontos remotos para aumentar a resistência dos sistemas a desastres como
quedas de luz, inundações em um dos locais e outros problemas diversos que
possam inutilizar um ou mais dos locais de armazenamento temporário ou
permanentemente.

O fato de estarem localmente posicionados numa infraestrutura para gerenciamento

de um banco de dados ou remotamente em locais próprios ou gerenciados por
terceiros (outsourcing), muitas vezes, não altera o uso dos bancos de dados em nível
de usuário, mas o processo de uso e gerenciamento é alterado em função dos
bancos remotos necessitarem de conexões via Internet, por exemplo.

Um acesso remoto pode ocorrer de forma restrita por meios de

comunicação como redes VPN chamadas de túneis de comunicação ponto
a ponto ou acessos comuns via web, além do uso de meios variados como
rede de telefonia móvel, rádio, etc., permitem que banco de dados sejam
acessados em locais distantes desde que se mantenha ativa a conexão.

Em caso de queda de conexão, um banco remoto ca isolado e inacessível, muitas

vezes, gerando um chamado desastre que é facilmente contornado assim que a
comunicação é restabelecida, mas isso pode gerar problemas na paralisação do
acesso ao banco, que pode gerar perdas enormes em volume de transações perdidas
ou paralisadas.

Há casos de falha que podem resultar em um problema de atualização de banco de

dados que deve ser gerenciado, como no caso de transações nanceiras que falham
durante o processo, e geram inconvenientes, como debitar de uma conta origem e
não creditar na conta destino, dando a impressão de saque e não de transferência,
ou não debitar da origem e creditar no destino, dando a impressão de um valor que
surgiu do nada e que também é problema para o sistema.

Quando falhas de transação assim ocorrem, ou é necessário que a transação seja

novamente submetida para que seja efetivamente realizada ou seja descartada e não
realizada, novamente, mas independentemente da opção, é preciso resolver a
inconsistência do banco de dados.

159
Um método de veri cação de inconsistência assim é o de recuperação através de
rollback baseado em logs do sistema que representa um histórico de transações
ocorridas e que pode indicar falhas a serem veri cadas a partir de dados contidos
nos logs como identi cadores de transações e alterações de valores realizadas.

O mais importante é o log ser capaz de armazenar o status de cada transação

indicando falhas ocorridas, como base para validação do sistema, sobretudo, o que
ocorreu com o banco de dados.

Outro método utilizando o log é o de conter, historicamente, todas as transações no

banco de dados, mas não realizar instantaneamente as operações mais arriscadas de
inserção, atualização e exclusão de dados de forma que só sejam realizadas e
consideradas con rmadas quando for possível a realização segura destas com a
possibilidade de con rmação parcial das transações.

As transações bancárias são um bom exemplo, pois, tradicionalmente, existem regras

para que ocorram, umas de forma instantânea, praticamente como transferências
entre contas do mesmo banco, que podem ser con rmadas no momento da
transação, e outras adiadas como outras que necessitem de con rmação da
possibilidade de realização como compensações e transações entre diferentes
bancos.

Interfere no processo das transações mecanismos de prioridades e outros para

garantir a maior integridade das transações e menores riscos de falhas que resultem
em problemas que podem necessitar de rollbacks em cascata que demandam tempo
e prejudicam todas as demais transações.

160
 Existe uma técnica de recuperação baseada na marcação de checkpoints
durante as transações, de forma a gerar pontos de recuperação em caso
de falhas, e na ocorrência de alguma, o checkpoint mais recente garante
que um estado seguro da transação pode ser obtido no checkpoint e a
partir dali a transação possa ser retomada. É importante de nir
corretamente os checkpoints, pois estes devem representar processos da
transação que ocorreram com sucesso e que possam ser consideradas
realizadas e con rmadas com sucesso sem risco às propriedades ACID.

O uso de checkpoints permite que o uso da recuperação baseada em log

seja mais e ciente pelo fato de não ser necessária uma busca completa
no log, mas apenas pelos pontos de veri cação da transação atual. Um
exemplo simpli cado é de que uma transação poderia realizar uma
consulta, obter dados que seriam utilizados em uma atualização posterior
e outra nova consulta de con rmação, por exemplo, e um checkpoint
seguro seria após a consulta ser con rmada, pois como não altera dados
no banco, assim como após a con rmação da realização da atualização
completa dos dados, antes da consulta de con rmação.

Caso haja falha na atualização, a mesma sendo realizada novamente pode

não representar risco à integridade do banco, pois os mesmos dados já
atualizados seriam novamente ajustados com os valores desejados, e os
não realizados, seriam.

Existem mais mecanismos e técnicas para recuperação em diferentes situações que

são tratados por Silberschatz (2020) e que podem aprofundar os conhecimentos
sobre como trabalhar a concorrência de transações e a recuperação em falhas, como
a técnica de shadow paging que trabalha com espaços de memória paralelos que são
integrados ao banco em caso de con rmação das transações.

161
 14

Arquiteturas de Banco
de Dados Paralelos e
Distribuídos
162
Todo banco de dados necessita estar associado a algum hardware e, inicialmente,
uma máquina única continha um banco de dados e o sistema gerenciador do mesmo
de forma local para que fosse acessado por um usuário de forma exclusiva.

Mesmo neste caso simples, havia a necessidade de se oferecer recursos mínimos

aceitáveis para que o banco de dados pudesse ser executado com um desempenho
que fosse capaz de oferecer uma experiência positiva e con ável ao usuário, além de,
mesmo em uma situação mais simples de uso, garantir as propriedades ACID.

Depois, com a evolução das redes locais, surgiu a ideia do servidor da rede que
permitia o compartilhamento de arquivos, software e recursos de hardware com os
demais equipamentos alocados na rede.

Nessa época, surgiram também sistemas gerenciadores de banco de dados que eram
instalados no servidor e através de protocolos de comunicação e sistemas
distribuídos entre servidor e equipamentos clientes, permitiu que uma base de dados
casse alocada sicamente no servidor e pudesse ser compartilhada entre os
clientes, surgindo aí a necessidade de cuidados com las de transações, concorrência
e outros mecanismos próprios para este sistema de banco de dados.

Os chamados sistemas cliente-servidor permitiram o trabalho colaborativo, a

evolução do sistema de uso dos bancos de dados com o desenvolvimento de grandes
sistemas empresariais baseados em transações em banco de dados e que criaram
interfaces muito mais atrativas aos usuários.

Esse movimento gerou duas rami cações no desenvolvimento de sistemas baseados

na web, podendo interagir com banco de dados. Uma destas rami cações trata
diretamente da interação entre usuário e sistema chamada de front end, e a outra,
cuida dos processos relacionados ao que é solicitado por usuários e processos
diretamente com o banco de dados chamada de back end.

Num terceiro momento, a introdução da comunicação de longa distância,

principalmente com a popularização da Internet ofereceu um novo patamar para o
uso dos bancos de dados, permitindo que usuários em quaisquer cantos do planeta
com acesso à Internet possam acessar determinado sistema ligado a um banco de
dados para manipulá-lo diretamente ou realizar solicitações de transações através de
sistemas web que acessem o banco de dados e tenham permissão para manipular
seus dados, como ocorre no e-Commerce.

163
Sistemas Paralelos
Em muitos casos, com a massi cação da Internet, bancos de dados agregam
enormes quantidades de dados, sendo algo impensável ser armazenado em um
sistema isolado em um único equipamento de hardware por motivos diversos.

Um mesmo equipamento pode não ter recursos de hardware su cientes para

processar a quantidade de dados existentes em seus dispositivos de
armazenamento, isso se alguns Terabytes forem su cientes para tal armazenamento,
pois, por segurança, os discos rígidos podem utilizar a já citada tecnologia RAID para
espelhamento de discos e, assim, reduzir a capacidade de armazenamento por
restrições de projeto.

164
 Por mais poderoso que seja o equipamento isolado, uma simples consulta
pode levar muito tempo e gerar transtornos diversos com lentidão, fora o
fato de todo o sistema depender do pleno funcionamento deste
equipamento. Logo, subdividir a carga entre mais equipamentos é o
mínimo a ser feito, e assim surgiu a ideia de se organizar racks com
equipamentos que, juntos, oferecem melhores recursos de
armazenamento, processamento e garantia das propriedades ACID
essenciais para este tipo de aplicação.

Os chamados data centers são uma alternativa excelente para lidar com sistemas
pesados que lidam com grandes bases de dados, pois, normalmente, são dotados de
equipamentos de alta tecnologia e performance tendo muito espaço de
armazenamento espelhado e seguro, além de ter componentes de hardware ditos
redundantes, ou seja, capazes de serem trocados mesmo com os equipamentos em
funcionamento, como fontes de energia, discos, etc.

Um data center, por ser todo espelhado, inclusive, mesmo que gerando altos custos
de manutenção, para certas situações, este tipo de investimento passa de importante
para obrigatório devido à natureza dos dados contida, ou de se tratar de uma
prestadora de serviços de fornecimento de infraestrutura de TI (outsourcing).

Normalmente, os data centers representam o estado da arte da TI, mas podem ser
usados tanto em redes locais como em sistemas cliente-servidor, mas não é uma
situação comum, salvo em casos em que seja necessário o isolamento da
infraestrutura, por motivos de segurança, por exemplo.

165
Um data center por possuir tecnologia que permita o processamento paralelo real,
diferente do que é feito pela divisão de fatias de tempo de processamento que
simula processamento paralelo de transações.

Em sistemas de processamento de paralelo real, existem processadores sicamente

separados que trabalham de forma conjunta para que processos possam ser
executados simultaneamente, aumentando muito o throughput de uso da
infraestrutura toda. Além do processamento, aumenta-se o acesso ao banco de
dados que pode ser colocado em discos que possam também utilizar a tecnologia
RAID ou outras para trabalharem paralelamente, aumentando muito a e ciência de
hardware e de processamento em geral.

Sistemas do tipo cliente-servidor não necessariamente utilizam esta tecnologia, assim

como podem ser estruturados data centers sem este recurso, mas, geralmente, é um
investimento válido quando se prevê grande volume de dados e de transações.

A forma como se utiliza este paralelismo real depende muito do ajuste do sistema
operacional em disponibilizar este recurso disponível, mas que pode ser subutilizado,
como quando se usa software baseado em arquiteturas de hardware 32 bits em
equipamentos 64 bits, pois se reduz a capacidade de processamento do hardware
para aquele software.

166
 Sistemas operacionais e outros softwares podem ser encontrados em
versões de 32 e 64 bits, mas o que isto gera de diferença na prática?

Basicamente, signi ca a quantidade de bits que o processador de uma

máquina consegue processar de uma só vez, permitindo números
maiores armazenados em atributos, por exemplo, no caso de 64 bits.

É possível encontrar no mercado hardware de base com preço acessível para uso de
dois processadores simultâneos, por exemplo, permitindo que dois cálculos
diferentes possam ser realizados ao mesmo tempo, ou uma transação em um banco
de dados ocorra exatamente ao mesmo tempo em que se realiza um outro processo
em outro processador, obtendo-se algo similar à duplicação da capacidade de
processamento.

Outra possibilidade é que para se liberar o bloqueio de uma transação, é possível

que o processamento seja dividido entre processadores diferentes e um commit ou
con rmação da transação seja obtido mais rapidamente, da mesma forma que discos
podem ser utilizados em tal harmonia que sejam capazes de armazenar parte de um
conjunto de dados em um disco, parte em outro e, assim por diante, permitindo que
dados sejam lidos, paralelamente, mas tudo isso necessita ser muito bem gerenciado
pelo sistema operacional e demais sistemas envolvidos.

Existe, inclusive, uma denominação para estes equipamentos que diz que um
equipamento que possua alguns poucos processadores potentes em paralelo seja
considerado uma máquina com granularidade grossa, mas no caso de equipamentos
com grandes quantidades de processadores menos potentes são chamados de
máquinas com granularidade na.

167
Este tipo de tecnologia afeta diretamente valores ligados à throughput e tempo de
resposta em transações e processos, pois na primeira métrica, o paralelismo
aumenta muito a quantidade de processos que podem ser realizados,
simultaneamente, reduzindo de maneira inteligente, las geradas por transações que
sejam mais lentas e que poderiam atrasar toda uma la de processos.

Sobre o tempo de resposta, a espera tanto de realização de uma ação quanto no

tempo de realização após início do processamento, pode ser afetada pelo
paralelismo, pois com a divisão de transações entre processadores pode agilizar o
processo, tanto quanto o fato citado da la de processos andar mais rapidamente
com os processos ocorrendo em paralelo.

Segundo Silberschatz (2020), o uso da tecnologia que permite o paralelismo permite

ganhos em pelo menos dois aspectos diretamente ligados ao uso deste mecanismo
de hardware – o ganho de velocidade em função da redução de tempo para se
realizar transações e o ganho em escala que ocorre em função do paralelismo
permitir que transações maiores possam ser realizadas mais e cientemente.

Esses ganhos podem ser variados e também medidos de diferentes

formas, dependendo do critério de avaliação como quantidade de
recursos em paralelo e a proporção de ganho de velocidade obtido com
esse paralelismo, podendo ser linear se for equivalente, ou sublinear se o
ganho não for igual ao aumento de recursos por menor throughput.

No caso da avaliação em escala, se uma transação leva determinado tempo para ser
executada por completo, com o aumento de recursos em paralelo, caso um aumento
equivalente da complexidade das transações possa mesmo assim manter o mesmo
tempo de realização, pode-se dizer que existe um ganho linear em escala, mas caso o
tempo aumente, é dito um ganho escalar sublinear.

Existem outros critérios de avaliação de ganho com paralelismo, como o tamanho de

um banco de dados e o aumento proporcional de transações solicitadas, ou um
aumento das transações solicitadas gerando um consequente aumento do banco de
dados.

168
Aspectos Arquiteturais
Esses sistemas paralelos são obtidos através de tecnologias em hardware que
permitem que discos, processadores e memória, principalmente, possam ser
multiplicados em equipamentos, mas além disso, que possam dividir as tarefas de
forma a serem realizadas paralela e simultaneamente.

As maneiras como estes componentes podem ser conectados entre si, de diferentes
formas, geram redes de componentes para operarem em paralelo, e a forma como é
feita esta rede possui nomenclaturas similares às utilizadas nas tecnologias de redes
de computadores.

Podem ser conectados em uma estrutura de barramento com todos os componentes

se comunicando por um meio único que interliga a todos, tendo como limitação o
uso compartilhado deste meio de comunicação, limitando sua e ciência à medida
que aumenta a quantidade de componentes a serem interligados.

Outro meio é a malha que interliga os componentes uns aos outros, diretamente, uns
através dos outros fazendo com que não haja um meio único de comunicação
compartilhado, dividindo a carga de comunicação entre processos e quanto maior a
quantidade de componentes de mesmo tipo, maior o paralelismo e também a
possibilidade de roteamento de processos.

Além da forma como os componentes podem ser colocados, paralelamente, para

execução de processos, existe também a forma como este compartilhamento pode
ocorrer, pois as possibilidades de con gurações de paralelismo são variadas e com
isto, surgem diferentes possibilidades de uso dos componentes.

Silberschatz (2020) cita que há casos em que a memória volátil (RAM) é compartilhada
entre todos os processadores alocados em paralelo, assim como discos não voláteis,
como discos rígidos, sendo este um recurso com alto desempenho e permite uma
e ciente comunicação, principalmente entre processadores.

169
Como existem limitações de projeto em função do uso de 32 ou 64 bits na
arquitetura destes componentes, isso gera limitações de endereçamento e
compartilhamento de recursos para esta quantidade de processadores e, em casos
nos quais sejam utilizados números maiores em paralelo, esta solução de
compartilhamento não se mostra funcional.

Outro componente compartilhável, o disco que representa o responsável pelo

armazenamento não volátil é algo bastante comum, pois bancos de dados e outros
softwares e sistemas costumam car armazenados em um único sistema de
armazenamento, sendo este sistema um único disco, ou um conjunto de discos
integrados em bancos muito grandes, mas desconsiderando cópias de segurança.

As cópias de segurança são geradas automaticamente e não são locais de

execução das transações em tempo real, não precisando necessariamente
participar do processamento paralelo citado diretamente.

Ignorando, então, o fato de existirem cópias em tempo real ou cópias de backup que
acrescentariam bastante complexidade a esse contexto, não é muito sensato que
houvesse um banco de dados para atender a cada dispositivo paralelo de
processamento, por exemplo e, assim, acaba sendo muito comum a prática de uma
única base de dados de origem a ser utilizada por todos os usuários, salvo em casos

170
em que o volume de transações possa ser tão grande que seja inviável do ponto de
vista do desempenho de hardware e haja a necessidade de replicação do banco de
dados para um grupo de usuários.

Com essa técnica, é possível que clientes de uma ntech como o Nubank, por
exemplo, possa manter infra estruturas completas para cada determinado conjunto
de clientes para garantir as propriedades ACID com maior segurança para cada um
destes grupos de clientes.

Pode haver casos nos quais os dispositivos não são compartilhados e cada
equipamento possui todos os recursos necessários e acaba sendo mais
independente dos demais equipamentos da infraestrutura, sendo que existe tráfego
de dados entre os equipamentos, sempre que necessário.

Esta tecnologia acaba permitindo boa escalabilidade (ou expansão da infraestrutura

com base nesta tecnologia), mas existe um alto custo de comunicação entre
equipamentos para a garantia de e ciência em velocidade e con abilidade da
transmissão, além de alto volume de acesso a disco vindo de transações de outros
equipamentos, gerando alto custo em desempenho das unidades de disco.

Um último modelo trazido por Silberschatz (2020) mescla característica dos outros
três modelos citados chamado hierárquico onde existem níveis de divisão da
infraestrutura, sendo um primeiro nível mais alto formado por hardware com base
no modelo dito nada compartilhado de subsistemas de hardware. Parte dos
dispositivos forma uma unidade ligada ao restante da infraestrutura, mas dentro
desta estrutura, a memória RAM poderia ser compartilhada única para cada conjunto
de dispositivos nada compartilhados.

171
 Os SGBDs são ferramentas com muitos recursos e um dos melhores,
certamente, é a opção disponibilizada pela Oracle. O paralelismo é uma
das tecnologias implementadas nesse SGBD muito popular no mercado.

Sistemas Distribuídos
A ideia geral de sistemas distribuídos se baseia no fato de um banco de dados estar
armazenado em diferentes equipamentos que podem estar sicamente próximos ou
não, mas que con guram algum tipo de acesso remoto entre os equipamentos.

Os equipamentos são independentes em termos de hardware, podendo ser

equipamentos de tipos diferentes e até com hardware e sistema operacional
diferente, mas o meio e o protocolo usados para comunicação devem ser
padronizados, como ocorre com o protocolo de comunicação TCP-IP utilizado pela
Internet para conectar inúmeros tipos diferentes de equipamentos.

Geralmente, até a representação grá ca deste tipo de infraestrutura difere da

anterior comentada para arquiteturas em paralelo, pois não se de nem exatamente
os meios de comunicação entre os equipamentos com linhas, mas usando uma
nuvem em função de a comunicação ser mais difícil de precisar e identi car, ainda
mais à medida que a infraestrutura cresce muito, como no caso de sistemas de
banco de dados que operam pela web.

172
As transações locais são aquelas em que tanto a origem quanto o destino se
encontram em uma mesma infraestrutura ou site, como se diz, em sistemas
distribuídos, e transações globais têm sua origem em algum site diferente de onde
devem ser efetivamente realizadas.

Nesta arquitetura, partes do banco de dados mais especí cas podem estar alocadas
em um site e as demais partes em um ou mais outros sites, dependendo da
complexidade e avaliação de pontos positivos e negativos desta distribuição do
sistema em partes.

Isto gera certa liberdade dos sites em gerenciar bancos de dados locais, podendo
então a carga de transações ser também distribuída, pois transações locais geram
baixo custo, ao passo que eventuais transações globais possuem maior custo, mas
podendo-se obter ganho de desempenho com esta arquitetura.

A disponibilidade é um aspecto positivo, pois em função da menor dependência

entre os sites, existe um menor risco de uma falha em algum dos sites afetar toda a
infraestrutura global, mas apenas equipamentos diretamente afetados.

Um ponto de atenção na infraestrutura de um sistema distribuído é que

independentemente do que ocorra na infraestrutura em termos de desastres, a
mesma deve ser capaz de manter o funcionamento da infraestrutura com o restante
não afetado pelo ocorrido.

Para isto, equipamentos como computadores que gerenciam sozinhos pequenos

sistemas ou componentes de um sistema maior precisam ter algum meio de retomar
suas atividades com a existência de um outro computador igual ou similar contendo
as mesmas funcionalidades que possa substituir o anterior fora de operação na
infraestrutura, por exemplo.

Mesmo grandes data centers podem ter infraestruturas completas de segurança

reservas para serem ativadas em caso de necessidade, ou que funcionem
paralelamente, podendo estar sempre em funcionamento, dividindo o trabalho de
processamento dos processos, e tendo replicados sistemas e banco de dados.

Importante que sistemas distribuídos sejam capazes de funcionar da forma mais

transparente possível na visão dos usuários no caso de, mesmo tendo partes
espalhadas por diversos locais sicamente distintos, possam fornecer a impressão de
que toda infraestrutura estaria alocada sicamente onde se encontra o usuário.

É claro que no caso da ocorrência de um desastre que impeça o usuário de acessar a

infraestrutura como uma queda de luz que impeça o funcionamento de seu
equipamento ou a interrupção do serviço de comunicação utilizado para conexão

173
com a infraestrutura, por exemplo, a mesma deve continuar operando normalmente
para outros usuários.

Existem pontos de atenção citados por Silberschatz (2020) como maiores custos
associados ao desenvolvimento de soluções de software distribuído pela maior
complexidade de operação, com maior possibilidade de ocorrência de bugs ou
problemas na implementação e implantação de maior ou menor gravidade, e a
possibilidade de throughput excessivo, não especi camente relacionado às
transações dos sistemas, mas pela garantia da comunicação entre os sites que
compõem a infraestrutura distribuída.

Para nalizar, é importante frisar que os sistemas distribuídos são alocados em redes
locais com toda sua infraestrutura ligada através de meios de comunicação de curta
distância, como cabos e sinal de WI-FI, ao passo que redes remotas que possuem
partes espalhadas por diferentes locais podem estar gradativamente mais distantes
usando diferentes tecnologias de comunicação, como cabos, redes de telefonia
móvel como 3G, 4G e 5G, sinais de rádio e conexões via satélite, por exemplo.

174
 15

Banco de Dados Paralelos

e Distribuídos
175
Além das infra estruturas contendo tecnologias que possam trabalhar em paralelo
para aumento de desempenho e maior escalabilidade, existem conceitos mais
especí cos que tratam de banco de dados que possam ser implementados para
trabalhar em paralelo e de forma distribuída, tendo sido este o motivo de uma
introdução à ideia de como funcionam sistemas com estas tecnologias.

Os sistemas de banco de dados paralelos representam uma alternativa custosa em

termos de desenvolvimento que quase foi abandonada décadas atrás pela baixa
necessidade de se desenvolver e manter algo tão complexo para um volume de
dados e transações que acontecia na época, mas com a grande massi cação da
World Wide Web, os chamados e-Commerce, começaram a utilizar banco de dados
que, gradativamente, precisavam ser capazes de suportar uma quantidade de
dados e transações em crescimento acelerado.

Com a popularização da web, o mundo conheceu uma imersão profunda neste

novo meio de se informar, comprar e passar o tempo de forma que os dados
contidos ali foram se tornando cada vez mais importantes e capazes de fornecer
dados relevantes, além de simples cadastros e senhas de acesso para segurança
das transações envolvendo valores ou dados mais sigilosos.

Os sistemas básicos implantados em redes locais isoladas do restante do mundo

começaram a não mais fazer sentido, pois os negócios começaram a car
interligados e trabalhar em conjunto em muitos casos agregando bens a serviços
ou vice-versa.

Os sistemas de banco de dados começaram a evoluir de forma a se tornar

mecanismos de apoio à tomada de decisões. A Internet se tornou a base para a
sociedade de uma forma tão intensa que já não se imagina mais um mundo sem
uma tecnologia capaz de interligar praticamente tudo que existe para o ser
humano que possa gerar dados digitalmente armazenáveis.

Como grande parte das transações realizadas em banco de dados se resumem a

consultas, isto se torna um fato bastante favorável a m de que sejam
implementados para serem paralelos, proporcionando grande escalabilidade,
segundo Silberschatz (2020).

Uma tendência iniciada na década de 1980 se manteve até os dias atuais, e

favorece o paralelismo que foi a redução do tamanho dos equipamentos de
computação que antes eram grandes mainframes e supercomputadores com
tecnologias que não se preocupavam com tamanho, passando a ser desenvolvidos
para serem posicionados em racks ou gabinetes.

176
Paralelismo de Disco para Banco
de Dados
O compartilhamento de disco é a forma mais comum de paralelismo e a mais
utilizada, provavelmente, pois a necessidade de investimento para implantação e
uso é menor e a manutenção de sistemas sendo executados com esta tecnologia
também são menos propensos a bugs e custos de implementação que o
paralelismo de processamento, por exemplo.

Um meio de paralelismo de disco se chama particionamento horizontal em que as

entidades são gravadas em tuplas que podem estar armazenadas em discos
diferentes podendo este paralelismo ser implementado de diferentes formas.

O particionamento do banco de dados entre diferentes discos pode ser feito com
base em algoritmos que fazem a distribuição das entidades entre discos, como no
caso do chamado rodízio, que tenta manter equilibrada a distribuição das
entidades com base na alocação de cada nova entidade em um dos discos que
compõem o conjunto usado no paralelismo, de forma sequencial, como de pessoas
entrando em cadeiras de uma roda gigante.

Na estratégia de hash, os próprios dados das entidades podem ser utilizados como
critérios de escolha do disco a ser armazenada à entidade como um cálculo
matemático realizado sobre um valor numérico de um dos atributos, sendo que a
correta escolha do atributo e do cálculo determinarão se ocorrerá um equilíbrio na
distribuição ou não.

Outra forma de paralelismo se baseia em intervalos de valores contidos em algum

dos atributos para a escolha do disco a ser utilizado no armazenamento, como a
de nição de intervalos de idades para a escolha do local de armazenamento. Esta
estratégia pode ser interessante numa divisão das entidades de acordo com a
capacidade e desempenho geral do disco e equipamento ao qual esteja ligado em
infraestruturas onde os equipamentos podem ser diferentes.

Como citado, exceto pelo mecanismo que fatia igualmente as entidades através de
um rodízio equivalente de discos, os demais algoritmos podem gerar maiores
acúmulos em um disco em relação a outro podendo ser classi cados como
distorções.

177
Uma das distorções ocorre quando certos atributos possuem valores que ocorrem
muito mais vezes que outros, determinando que uma grande proporção das
entidades seja armazenada em um disco, e poucas entidades nos demais, por
exemplo.

Existem mecanismos que podem ser agregados aos algoritmos de distribuição de

entidades de forma a prever possíveis acúmulos exageradamente maiores que
outros em unidades de armazenamento, utilizando avaliações prévias dos
conteúdos dos atributos das entidades utilizados no processo de de nição do
armazenamento em paralelo.

Com estas adaptações aos algoritmos de escolha de dados a serem armazenados

em cada diferente opção de disco, estatisticamente é possível avaliar menores
probabilidades de uma distribuição inadequada ocorrer, otimizando o uso da
infraestrutura de armazenamento para uso do banco de dados.

Um dos tipos de paralelismo em banco de dados se baseia no paralelismo de

consultas e demais transações aproveitando recursos do paralelismo para
aumentar o throughput de realização de processos simultâneos gerando, assim, a
possibilidade de ganho escalar.

Em sistemas com arquitetura de discos compartilhados ou com nada

compartilhado, existem alguns mecanismos de controle que precisam ser
gerenciados além das transações, gerando muita troca de mensagens e maior
congestionamento, além de uma maior di culdade de implementação.

Outro tipo de paralelismo ocorre principalmente em casos nos quais consultas

muito pesadas podem ser executadas, paralelamente, para que se obtenha ganho
no tempo de execução da transação.

Existe também um paralelismo relacionado às tuplas de entidades e

relacionamentos que podem ser colocadas em paralelo em discos diferentes que
trabalhem em paralelo para que se obtenham ganhos na realização de consultas,
principalmente, porque nem todas as unidades de disco possuem mecanismos de
alta velocidade, sendo ainda muito comuns as unidades de disco rígido magnético
de baixa velocidade de acesso.

Para controlar este mecanismo, existem algoritmos já citados para organizar a

distribuição das tuplas pelos discos, mas existem também outros com a função de
classi car para controle desta divisão e para unir as tuplas de forma a compor
novamente o banco completo, sempre que necessário, existindo variações e
diferenças técnicas entre cada opção.

178
Banco de Dados Distribuídos
Assim como em sistemas distribuídos que se localizam em diferentes sites (pontos
físicos distintos), bancos de dados podem também trabalhar de forma distribuída,
armazenando seus dados em estrutura fracionada, distribuída por sites.

É fácil imaginar que o fato de haver este distanciamento entre partes do banco de
dados deve gerar grande tráfego de dados pelos canais de comunicação e isto
acaba gerando perda de rendimento do sistema, além de uma maior complexidade
na organização e gerenciamento do banco de dados.

Os sistemas de banco de dados podem conter em todos os seus sites SGBD e

demais ferramentas e softwares iguais, e isto pode facilitar a comunicação
havendo, inclusive, uma maior permissividade entre os sites no gerenciamento dos
bancos de dados uns dos outros, pois mesmo estando dispersos, compõem um
mesmo sistema.

Outro sistema é composto por sites que não possuem infra estruturas de banco de
dados iguais, podendo diferir no SGBD e demais softwares componentes,
aumentando a complexidade da comunicação e gestão conjunta, ocasionando
menor interação entre os sites, restringindo-se mais a consultas e transações
limitadas.

O armazenamento distribuído de um banco de dados pode ser feito em réplicas

idênticas do banco todo armazenadas nos diferentes sites, ou o banco pode ser
fracionado e ter suas partes armazenadas em diferentes sites.

Existem vantagens no sistema de replicação do banco todo, pois em casos de

falhas de um site, os demais possuem totais condições de oferecer suporte ao
sistema, trazendo o banco de dados de volta quase que imediatamente,
in uenciando diretamente na disponibilidade dos dados.

Como existe a replicação total dos dados, isso gera um tipo de paralelismo que
permite transações rápidas que ocorrem dentro de si mesmo, pois existem quase
100% de chances do que uma transação se propõe a realizar poder ocorrer no site,
sem a necessidade de acesso a outros que depois teriam o banco de dados
atualizado do site onde ocorreu a transação, replicada para os demais sites.

179
Existe o problema de maior throughput aumentado em função das operações de
manutenção das réplicas atualizadas o mais constantemente possível, e isso pode
gerar atrasos nas transações, principalmente em infra estruturas com canais de
comunicação não tão rápidos e e cientes.

No sistema de fragmentação do banco de dados, é importante estar ciente de que

as partes espalhadas do banco de dados não estão organizadas nos diferentes
sites apenas com frações do banco, mas também com diversos dados adicionais de
controle para reintegração do banco, sempre que necessário, e mesmo que apenas
temporariamente.

Esta fragmentação pode ser feita de forma dita horizontal quando uma relação é
particionada de forma que suas tuplas de dados representando as entidades do
conjunto de entidades estejam todas armazenadas em algum dos sites, de forma
que seja possível a mescla de todas as tuplas separadas para a formação da tabela
completa, sempre que necessário.

O algoritmo pode conseguir prever uma melhor distribuição das tuplas, de acordo
com a quantidade de acesso de cada uma, por exemplo, minimizando o tempo de
busca e de comunicação entre sites.

Outra forma de fragmentação é dita vertical, pois ao invés de manter as tuplas

íntegras e armazenadas em diferentes sites, atributos de tabelas é que são
separados uns dos outros com todo o seu conjunto de dados. Isso permite uma
personalização dos dados armazenados em cada site, de forma a oferecer maior
sigilo em dados que seriam então separados de outros, mas mantendo
mecanismos de controle para eventuais uniões dos atributos em transações.

Independentemente de como o banco de dados é armazenado, seja fracionado ou

não, os usuários não devem perceber esta organização arquitetural da
infraestrutura, pois isso não deve afetar o funcionamento normal do sistema
gerenciador e do banco de dados em si.

Esta transparência não deve oferecer indícios ao usuário de que o banco de dados
possa estar fracionado horizontal e nem verticalmente, e nem se existe uma
replicação do banco, pois, aparentemente, todo o banco e sistemas estão sendo
acessados localmente.

As transações ocorrem tanto local quanto globalmente como já estudado, e no

caso das transações globais, os sistemas distribuídos de banco de dados são a base
de funcionamento e isto aumenta mais ainda a complexidade das transações que

180
precisam trabalhar dados que podem estar em diferentes sites, mas que, ao nal,
precisam garantir da mesma forma as propriedades ACID.

Silberschatz (2020) cita que além de problemas comuns como falhas relacionadas a
software e hardware envolvendo equipamentos e dispositivos utilizados
diretamente no armazenamento dos dados, em banco de dados distribuídos, as
falhas podem estar relacionadas a sites e comunicação, envolvendo aspectos
diversos de infraestrutura.

Tanto em caso de con rmação de uma transação (commit) quanto de falha da

transação (rollback), o processo é mais complexo em um banco de dados
distribuído, pois dependendo do fracionamento utilizado, todos os fragmentos
precisam concordar com o status da mesma transação, e isto precisa ser muito
bem orquestrado de forma a haver, além de uma sincronia dos processos da
transação, garantias do resultado nal.

Para isto, pode ser necessário que sejam realizadas as ações de uma transação em
etapas, em que uma primeira etapa seria a do registro de log para operação de
rollback, se necessário, e sinalização para todos os sites de solicitação de transação,
aguardando resposta positiva ou negativa de todos.

Em caso de aceite de todos os sites, o gerenciador de transação coordena a

execução da mesma, e em caso de falha indicada por qualquer um dos sites que
possuem dados ou estruturas a serem utilizados na transação, o status de toda a
transação deve ser atualizado para abortar, atualizando também o log.

Ao nal de uma transação bem-sucedida, um commit é indicado, mas apenas após

con rmação de sucesso em todas as frações de todos os sites, mas em caso de
falha em uma etapa dentro da execução da transação, é preciso avaliar a
necessidade de realização de um rollback, como já comentado.

Pode ocorrer também de atrasos ou falhas na comunicação e o gerenciador de

transações nem receber resposta de algum site, con gurando falha também por
garantia, mesmo que em seguida uma resposta positiva do site chegue, pois é
preciso garantir a integridade do banco mais do que a correta execução de uma
transação atrasada.

Pode ser implementada uma proposta alternativa em três fases que adiciona uma
fase de controle do próprio gerenciador de transações em con rmar as respostas
dos sites e isso ativa mecanismos de veri cação de status dos sites que
con rmaram resposta e escolhem um novo gerenciador de transações.

181
Há outros protocolos de processamento de transações citados por Silberschatz
(2020) como o de mensagens persistentes entregues apenas uma vez, uso de
relação especial de controle de envio de mensagens, ou um protocolo de uma
relação especial de controle de mensagens recebidas em sites do banco
distribuído.

Existem mecanismos de controle de concorrência adaptados para bancos de dados

distribuídos que necessitam de uma perfeita replicação do banco, mantendo as
bases dos sites igualmente atualizadas para evitar impedimentos no
funcionamento das transações.

Protocolos de bloqueio como de gerenciamento a partir de um único site,

distribuído entre mais de um site, protocolo de cópia primária que admite uma das
réplicas do banco como principal, protocolo da maioria que necessita de garantia
de envio de bloqueio a pelo menos metade dos sites, protocolo parcial que prioriza
bloqueios compartilhados ao invés de bloqueios exclusivos, etc.

Sendo a disponibilidade uma das propriedades mais importantes em um banco de

dados, mesmo em banco de dados distribuídos, a disponibilidade máxima possível,
dita alta disponibilidade que representa quase que um funcionamento ininterrupto
garantido do banco de dados.

Para isso ser possível em um sistema composto por diferentes sites são
necessários recursos para detecção de falhas, boa replicação do banco ou uma
perfeita fragmentação em termos de durabilidade dos dados, desde problemas
simples como perdas de dados na comunicação, como desastres que tiram um ou
mais sites do ar.

A correta implementação de mecanismos para controle de falhas ou con rmações

de transações é importante, assim como a garantia de funcionalidade individual de
cada site da melhor forma possível.

182
Conhecer mais sobre banco de dados distribuídos é algo importante
para o aprimoramento nos estudos desta área fundamental para o
mercado de trabalho. Neste material, segue um resumo com algumas
ilustrações e exemplos para auxiliar nos estudos.

183
 16

Tópicos Avançados e
Mineração e Análise
de Dados
184
Sistemas de banco de dados são complexos softwares que lidam com um dos bens
mais valiosos do mundo atual, e da forma como os dados estão sendo captados e
tratados de forma a servirem de material para diversas nalidades, surgem novas
tecnologias, regularmente, com o intuito de oferecer meios de se organizar e
gerenciar os dados da melhor forma.

O desempenho de um banco de dados é algo que se busca aprimorar sempre,

principalmente em sistemas que contenham grandes volumes de dados e que
sirvam de base para constantes transações de consulta e outras ações que podem
ou não demandar muito tempo para serem realizadas.

O hardware em si sempre será um dos pontos mais importantes na avaliação de

desempenho de banco de dados, pois o uso massivo de processamento e unidades
de armazenamento faz com que o uso de dispositivos que não sejam os mais
e cientes pode tornar a experiência com um banco de dados bastante
desagradável, tanto do ponto de vista do gerenciador que leva muito tempo para
retornos de transações quanto de usuários, que cada vez têm menos tempo e
paciência para aguardar processamentos demorados.

Para se avaliar desempenho, é preciso estabelecer critérios de avaliação a partir de

métricas adequadas e valores de referência con áveis, pois a simples avaliação
intuitiva de uma infraestrutura ou de uma SGBD podem não representar algo
con ável para que se pense em tomar medidas relacionadas a novos investimentos
ou solicitações de melhorias e correções no sistema que funciona sobre um banco
de dados.

Descobrir pontos de perda de desempenho em um sistema é algo que pode

demandar tempo e recursos de pessoal e tempo, mas mesmo algum ganho
aparentemente pouco signi cativo pode representar valores altos em realizações
de mais negócios numa mesma fatia de tempo.

Os problemas podem estar relacionados à codi cação de software do sistema,

pouco otimizado e consumindo recursos de processamento desnecessário, mas a
avaliação do que é desnecessário passou por mudanças de tempos para cá, pois
um item que à medida que é reforçado gera perda de desempenho em qualquer
sistema é a segurança.

Mas a segurança é um dos pilares dos bons sistemas de banco de dados no mundo
atual da Internet, pois a comunicação pela web se baseia em um protocolo muito
e ciente, mas já bem conhecido. Por ser uma rede pública, necessita que os
mecanismos de segurança sejam bem implementados e até exagerados, muitas

185
vezes, para evitar invasões na infraestrutura com intuitos variados como
corromper bancos, roubar dados de forma invisível, ou até o chamado sequestro
de dados (ransomware).

O uso de processamento paralelo é importante em desempenho, pois é comum

que uma transação leve muito tempo aguardando uma entrada de dados manual,
reduzindo o throughput do sistema, deixando recursos por muito tempo ociosos.

Ajustes em um banco de dados podem ser realizados em nível de hardware com

tecnologias variadas de disco, processamento e memória RAM, assim como
con gurações de rede e meios de comunicação.

O próprio banco de dados, geralmente, possui ajustes que também podem

representar importantes aspectos em desempenho e segurança, através de ajustes
de tempo e checkpoints de processos, por exemplo, além de aspectos relacionados
à concorrência e recuperação de dados.

Um terceiro nível em que a aplicação em si que afeta o SGBD envolve a de nição de

esquemas e transações, aplicando-se recursos do SGBD ou scripts em SQL ou XML,
por exemplo. Índices e uma melhor organização das estruturas do banco de dados
também são aspectos que contribuem com o desempenho do banco.

A avaliação do desempenho pode servir de base para melhorias, como dito, e

simulações de desempenho benchmarks são fundamentais na avaliação do
conjunto da infraestrutura onde opera o banco de dados.

O chamado TPC (Transaction Processing Performance Counci ou Conselho de

Performance de Processamento de Transações) de niu padrões para avaliação de
desempenho em banco de dados. Aspectos como TPS (transações por segundo) ou
de custo da TPS representam bons recursos para medição de desempenho de
banco de dados.

Bancos de dados relacionais, orientados a objetos ou não relacionais, são todas

opções interessantes e podem ser mais bem estudadas de forma a se obter maior
conhecimento e preparo para evolução nos estudos na área de desenvolvimento e
projeto de software para o gerenciamento de banco de dados.

186
Mineração de Dados
Durante muito tempo, banco de dados foram simples repositórios de dados nos
quais transações ocorriam com o objetivo de mantê-lo atualizado tendo como
objetivo maior o suporte a atividades reais gerenciadas por sistemas baseados
nestes banco de dados.

Com isso, os bancos de dados poderiam armazenar também log históricos e

transações realizadas com o intuito de permitir que transações equivocadas
pudessem ser desfeitas, mesmo depois de passado algum tempo, se necessário.

O termo data warehouse surgiu com a tecnologia capaz de trabalhar com

diferentes bases de dados de forma uni cada sob um mesmo schema de dados
para que se pudessem realizar análises estatísticas sobre os dados das bases em
conjunto com o intuito de obtenção de padrões e informações antes inimaginadas
e capazes de gerar novos conhecimentos acerca do que já existia nos sistemas.

A chamada mineração de dados se baseia nesta ideia de pesquisas mais complexas

em banco de dados com objetivos variados, como de obtenção de dados esperados
ou na busca por novas informações antes desconhecidas e que podem ou não
agregar valor aos negócios, por exemplo.

A expansão contínua da Internet e da sua infraestrutura global favoreceu o

crescente volume de dados que circulam pela mesma, sendo estes dados voltados
ao público em geral ou não, mas independentemente da nalidade dos dados que
pela rede mundial circulam, o conjunto de toda esta inimaginável base de dados
representa uma fonte fortemente explorável de informações.

As tecnologias voltadas a esta atividade foram sendo desenvolvidas à medida que

foi sendo percebido que, além de padrões estatísticos capazes de mostrar como se
comportam os dados em determinado momento, poderia ser possível realizar
previsões através de avaliações históricas relacionadas às transações realizadas
nos bancos de dados, geração de probabilidades mais con áveis através de
modelos estatísticos formados com base no cruzamento de dados de diversas
bases de forma antes difícil de serem obtidos.

Assim, o termo sistema de processamento de transações mais utilizado para de nir

banco de dados foi sendo expandido para rami cações mais especí cas como o de
sistema de apoio à decisão.

187
Sistemas que antes apenas aguardavam por requisições de transações puderam se
tornar ferramentas em tempo real de análise de dados e fornecimento de
informações sobre como os dados estavam se comportando e que avaliações se
poderiam obter a partir destes resultados fornecidos por estes sistemas.

Algumas informações básicas eram a base para análise de negócios como maiores
vendas, cálculos de lucros obtidos em períodos históricos recentes ou mais
distantes, e sazonalidade de um negócio, por exemplo.

Com a evolução das análises e cruzamento de banco de dados, aos poucos foram
sendo obtidas novas informações como tendências de consumo de clientes,
comparativos com resultados de concorrentes que eram publicamente acessíveis,
avaliação de produtos emergentes no mercado em relação aos que eram
oferecidos pelo negócio, etc.

Os sistemas de apoio à decisão não representam novos sistemas de

armazenamento de dados, mas sistemas que se baseiam nos dados existentes e
gerados pelos sistemas de processamento de transações, assim, sistemas que
dependem de outros sistemas para suas atividades, sendo de baixo custo
operacional e que aumentam o throughput da infraestrutura. Podem ser
executados apenas em momentos de maior ociosidade como no período da noite,
gerando compilados obtidos até determinados períodos anteriores ao da geração
dos resultados consolidados.

Os sistemas de apoio podem oferecer meios de se tomar decisões rápidas de

produtos a serem ofertados a preços promocionais devido a aspectos como alta
demanda no mercado é provável guerra de preços, produtos que baixaram seu
giro e não necessitam mais da mesma proporção de reposição de tempos
anteriores ou até não mais repor o produto e descartá-lo do portfólio.

Empresas grandes com liais espalhadas em diferentes cidades ou regiões do país

podem realizar análises de como a logística pode ser favorecida pelas demandas de
cada região com o intuito de otimizar entregas e manutenção de estoques ou
centros de distribuição, pois muitas empresas adotam, nos dias atuais, sistemas de
estocagem como just in time de estoque ajustado à demanda ou até de trabalho
sem estoque algum, apenas intermediando a logística de um ponto a outro
praticamente em alguns modelos de e-Commerce.

188
 Baseado no sistema Toyota de gerenciamento, o modelo just-in-time
permite que insumos e produtos estocáveis cheguem aos depósitos
apenas no momento de serem utilizados, ou o mais próximo possível
deste objetivo.

A base para os sistemas, tanto de processamento de transações quanto de apoio à

decisão, pode se fundamentar em scripts SQL para se obter os resultados
esperados quanto às suas nalidades básicas, mas existem alternativas que foram
surgindo para atender a outras demandas de complexidade além das
possibilidades do SQL ou muito difíceis de se atingir com SQL.

O OLAP (Processamento Analítico Online) utiliza técnicas e ferramentas de análise

de dados para auxiliar a condução de negócios a partir de uma especialização do
gerenciamento de banco de dados na realização de consultas e geração de
relatórios, deixando de lado o foco no gerenciamento das demais formas de
transação de dados.

Baseados no uso de dados processados para armazenamento em data

warehouses, possuem uma estrutura de armazenamento de dados em cubo, tendo
assim, mais dimensões de dados que as tradicionais tabelas com linhas (tuplas) e
colunas (atributos).

Esse tipo de estruturação mais complexo dos dados permite que novas consultas
de alto desempenho sejam possíveis, pois as próprias estruturas podem ser
organizadas de forma que num banco de dados relacional convencional, os
mesmos resultados teriam que ser obtidos em etapas.

189
As bases dos dados em sistemas desse tipo são medidas representativas de dados
numéricos puros, e os dados gerados a partir das medidas chamadas de
dimensões usadas diretamente nos sistemas de apoio à decisão, por exemplo.

O armazenamento dito em cubo no modelo OLAP tem este nome apenas por
permitir uma organização mais complexa dos dados, não necessariamente
compondo este formato no sentido geométrico, mas na ideia de se poder trabalhar
com mais de duas dimensões de dados, e daí a ideia de medidas e dimensões
como terminologia.

A ideia de medida é simples, pois agrega valores simples como em atributos de

banco de dados relacionais, mas o termo dimensão se refere à forma como dados
podem ser organizados e agrupados em níveis, por períodos de tempo, aspectos
de subdivisão de grupos de dados, como cargos, localidades, situações, etc.

A tecnologia OLAP trabalha com recursos capazes de lidar com grandes

bases de dados com o intuito de gerar novos dados utilizados em
sistemas de BI (Business Intelligence) que oferecem uma visão
especializada dos negócios.

Ferramentas como SAS ou S++ auxiliam no trabalho estatístico sobre os dados de

forma bastante e ciente, economizando tempo de implementação e garantia de
resultados mais con áveis pelo uso de ferramentas com e ciência já comprovadas
no mercado.

190
O uso de um data warehouse torna possível a aplicação de ferramentas em dados
originalmente armazenados em banco de dados distintos com schemas e
estruturas diferentes que di cilmente poderiam ser organizadas para uso em
consultas por um comando SQL, por exemplo.

As ferramentas conseguem realizar a chamada mineração de dados a partir de

mecanismos avançados de combinação e busca de padrões em dados com o uso
da estatística que possui muitos recursos para avaliação de dados que podem
retornar informações resumidas e diretas para análise e tomada de decisões.

É importante deixar claro que a área de mineração de dados não exclui o uso da
linguagem SQL ou XML, mas agrega novas funcionalidades a estas trazidas por
ferramentas ou novas implementações destas linguagens que possuem
características voltadas à mineração de dados.

A ideia das dimensões do modelo em cubo em OLAP pode ser de nida por
atributos que podem ser de nidos como medidas no caso de dados que possam
ser quanti cados como quantidades em estoque ou vendidas, mas também,
podem ser de nidos como dimensões que representam outros atributos que
servem como base para o agrupamento de medidas com base em cálculos como
somas ou médias, por exemplo.

Atributos como modelos, cores, cargos são típicos para uso na de nição de
dimensões, e atributos como quantidade em estoque ou vendida são atributos
típicos para medidas, modelos bidimensionais podem até ser utilizados para
organização dos dados até certo nível, mas a organização em cubo pode oferecer
maior clareza dos dados incluídos.

Um exemplo em que poderia se basear é na ideia geral de venda de carros, na qual

atributos como quantidade vendida, nitidamente podem gerar medidas que
podem ser agrupadas com base nos demais atributos, representando dimensões
para análise. Neste caso, fabricante, modelo e cor podem ser usados como
dimensões.

191
Imagem 55

MARCA MODELO COR ESTOQUE

GM ONIX PRETO 3

FIAT ARGO PRATA 2

VW GOL BRANCO 3

FIAT ARGO VERMELHO 1

VW FOX BRANCO 4

GM ONIX PRATA 6

MARCA MODELO COR ESTOQUE

FIAT ARGO ALL 3

GM ONIX ALL 9

VW FOX BRANCO 4

VW GOL BRANCO 3

192
 MARCA MODELO COR ESTOQUE

FIAT ARGO ALL 3

GM ONIX ALL 9

VW ALL ALL 7

Fonte: O autor.

É possível utilizar agregação de medidas sob determinadas dimensões de forma a

se obter informações resumidas e mais pertinentes, em determinados casos pode-
se usar o valor all como representante de valor geral para todos os valores de um
determinado atributo relacionado aos demais indicados na tabela.

Na imagem 55, observa-se a representação da primeira tabela completa de

exemplo que pode ser condensada em outra, menos agrupando-se dados contidos
em medidas sob o critério de distinção de marcas e modelos, mas não de cores,
obtendo como um possível resultado, a segunda tabela.

Depois, na terceira tabela da imagem 55, é usada mais uma dimensão para receber
o valor all e condensar ainda mais o resultado da consulta, tendo então como
resultado nal do exemplo, os totais de carros por marca, independente de
modelos ou cores.

Existem tipos de dados compostos que podem ser decompostos,

hierarquicamente, como datas em dia, mês e ano ou data e hora, sendo que a data
pode ser decomposta em dia, mês e ano. Geralmente, países, estados e cidades
também possuem hierarquia, mas não são considerados um campo único.

Os sistemas OLAP podem ser implementados como sistemas multidimensionais

(MOLAP), relacionais (ROLAP) ou híbridos multidimensionais com armazenamento
relacional (HOLAP) podendo ser implementados sob arquiteturas cliente-servidor,
por exemplo, onde banco de dados e OLAPs cam armazenados no servidor para
serem acessados pelos clientes.

193
A forma como as implementações OLAP geram seus cubos de medidas e
dimensões pode seguir mecanismos variados como somas ou médias em atributos
que possam servir como medidas em algoritmos mais simples, mas existem
também opções mais complexas que se baseiam em cálculos estatísticos mais
elaborados como variância e desvio padrão.

Em versões mais recentes da linguagem SQL, generalizações extras foram criadas

como adicionais à cláusula group by, como cube que gera todas as possíveis
combinações de atributos indicados na consulta, ou rollup que permite agregações
em níveis hierárquicos.

select c.nome_cliente, v.valor_venda from c as

cliente, v as venda group by cube (c.nome_cliente,
v.valor_venda);
select c.nome_cliente, v.valor_venda from c as
cliente, v as venda group by rollup (c.nome_cliente,
v.valor_venda);

No primeiro dos exemplos acima, obtém-se como resultado um cubo agrupado

contendo as tuplas nome_cliente, valor_venda | nome_item | valor_venda,
mostrando que as combinações possíveis de diferentes tuplas são formadas a
partir dos atributos indicados no comando.

No segundo exemplo, por ser indicada uma hierarquia, são exibidos apenas
resultados que contenham o atributo principal em todos, e as possibilidades de
combinação com os demais: nome_cliente, valor_venda | nome_item.

Existem outros pontos adicionais que podem ser utilizados e que agregam recursos
valiosos ao OLAP e que podem ser conhecidos em pesquisas nas referências
bibliográ cas citadas e outras boas fontes literárias ou sites com conteúdo de
procedência também con ável.

194
Conclusão
O conhecimento acerca da área de banco de dados representa uma importante
informação para a formação pessoal e demandas do mercado, e a base conceitual
tratada na disciplina, agregada a estudos complementares e prática exaustiva do que
é prático, certamente, irá contribuir com grandes chances de ingresso no mercado
para novos, ou de melhoria de currículo e possibilidades de mudança ou crescimento
perante sua situação atual. Mas isto depende, de agora em diante, mais do aluno do
que dos materiais ou quaisquer professores, pois o primeiro passo foi dado e os
demais virão dos pés do aluno e sem apoios para se segurar.

O conhecimento pode ser aprofundado em diversas direções a partir do que foi

estudado na disciplina, mas, geralmente, um passo inicial partiria do estudo e da
prática da linguagem SQL e do uso do SGBD ligado a um servidor como visto nos
estudos para o desenvolvimento de banco de dados de teste. Lembre-se de que o
bom aprendizado passa por todas as etapas do processo de desenvolvimento, desde
a concepção e modelagem, até a implementação e uso do banco criado, testando-o
de forma exaustiva para que se possa chegar a um nível de con abilidade de sua
e ciência.

Produtos podem ser desenvolvidos de forma simples buscando apenas a prática, mas
este pode já atender demandas de pequenos negócios, assim como podem servir de
base para o desenvolvimento de soluções mais complexas.

Posteriormente, é possível se aprofundar em áreas como de banco de dados

distribuídos, segurança em banco de dados, mineração de dados que está muito forte
no mercado e em franca expansão de uso.

Assim, sempre é preciso ter em mente que mesmo com o término da disciplina seu
aprendizado e evolução na área continua, mesmo que não existam outras disciplinas
da mesma área em sua matriz curricular, e isso não é algo dito para banco de dados,
mas para todas as disciplinas do curso.

Todas possuem sua relevância e podem fornecer caminhos para um aprofundamento

e espaço no mercado de trabalho, pois a área de TI é uma das que mais oferecem
espaços para inserção e que carecem de bons pro ssionais.

Bons estudos!

195
Material Complementar

Livro

Sistema de Banco de Dados

Autor: Abraham SILBERSCHATZ, S. KORTH, Henry F.,

SUDARSHAN

Editora: LTC

Sinopse: Livro referência na elaboração do material, possui

enorme abrangência conceitual e, certamente, é uma ótima
aquisição para fazer parte de uma biblioteca básica de material
de estudo para qualquer estudante de TI.

Filme

Jexi - Um Celular Sem Filtro

Ano: 2019

Sinopse: Um jovem introvertido adquire um celular com uma

inteligência arti cial revolucionária que trabalha bem o
conceito de banco de dados e mineração de dados de uma
forma lúdica, ctícia, mas muito interessante.

Comentário: Filme bastante leve e divertido que ainda traz

muito sobre o tema da Inteligência arti cial.

196
 Web

O que é um Banco de Dados

Material disponibilizado pela Oracle trazendo a base da ideia

dos bancos de dados e algumas tecnologias e ideias
associadas.

197
Referências
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. 7ª ed.
Rio de Janeiro: LTC, 2020.

MySQL 8.0 Reference Manual. https://dev.mysql.com/doc/refman/8.0/en/

ALVES, W. P. Banco de dados. 1ª ed. São Paulo: Érica, 2014.

BARBIERI, C. Governança de dados: práticas, conceitos e novos caminhos. Rio de

Janeiro: Alta Books, 2020.

BARBOZA, F. F. M.; FREITAS, P. H. C. Modelagem e desenvolvimento de banco de

dados. Porto Alegre: Sagah, 2018.

CARDOSO, V.; CARDOSO, G. Sistemas de banco de dados: uma abordagem

introdutória e aplicada. São Paulo: Saraiva, 2018.

DATE, C. J. Introdução a sistemas de banco de dados. Rio de Janeiro: Elsevier, 2003.

MACHADO, F. N. R. Banco de dados: projeto e implementação. 4ª ed. São Paulo: Érica,

2020.

SETZER, V. W.; SILVA, F. S. C. Banco de dados: aprenda o que são, melhore seu
conhecimento, construa os seus. 1ª ed. São Paulo: Blucher, 2005.

198