Banco de Dados

DEFINIÇÃO:Apresentação da evolução histórica dos bancos de dados, abordando as características dos sistemas de
banco de dados (SBD) e a arquitetura dos sistemas de gerência de banco de dados (SGBD).
PROPÓSITO:Compreender a origem e as características dos SBDs, bem como suas funcionalidades, vantagens e
desvantagens, além de conhecer a arquitetura dos SGBDs e os sistemas mais utilizados em bancos de dados
MÓDULO 1:Reconhecer o histórico dos bancos de dados e suas tecnologias
MÓDULO 2:Identificar as características dos sistemas de banco de dados (SBD)
MÓDULO 3:Descrever a arquitetura dos sistemas de gerência de banco de dados (SGBD)
MÓDULO 1:Reconhecer o histórico dos bancos de dados e suas tecnologias
DEFINIÇÃO DE BANCO DE DADOS
Você certamente já leu sobre o termo banco de dados em algum contexto técnico ou geral na mídia tradicional ou na
internet.
Mas o que é um banco de dados?:O termo banco de dados, no sentido técnico, origina-se de database, do inglês, e o
livro-texto de edição norte-americana mais adotado no mundo o define de maneira simples e direta: “banco de dados é
uma coleção de dados relacionados” (ELMASRI; NAVATHE, 2019), em que dados são fatos conhecidos que podem ser
registrados e possuem significado implícito.
EXEMPLO:Nome, data de nascimento, endereço e telefone são dados relacionados entre si, inerentes a uma pessoa
conhecida em certo contexto. Antes de elaboramos mais essa definição, vamos relembrar um pouco da história dos
bancos de dados.
O conceito de banco de dados como uma coleção de dados relacionados sempre existiu como componente central dos
sistemas de informação. Estes, por sua vez, sempre existiram desde que a humanidade se organizou como sociedade.
Segundo afirmam Melo, Silva e Tanaka (1998), o que tem mudado rapidamente ao longo da história é a tecnologia que
permite a sua implementação e que se confunde com o próprio conceito de sistemas de informação.
Assim, antes da existência do computador, bancos de dados existiam sob a forma de registros físicos em papel,
organizados em pastas dentro de armários, que formavam os arquivos dos sistemas de informação, operados
manualmente pelos seus usuários. Será que ainda existem sistemas de informação desse tipo em pleno século XXI?
EVOLUÇÃO DOS SISTEMAS DE INFORMAÇÃO EM COMPUTADOR
ERA DO PROCESSAMENTO DE DADOS
Historicamente, o computador, inventado na década de 1940 ao fim da Segunda Guerra Mundial, era usado
primordialmente como uma máquina para cálculos matemáticos complexos, a exemplo da máquina diferencial
de Charles Babbage, do século XIX.
CHARLES BABBAGE:Charles Babbage (1791-1871) é um dos mais célebres ícones no mundo da computação. As suas
notáveis contribuições para a área fizeram dele o pioneiro dos computadores. A Máquina Diferencial N. 1 foi a primeira
calculadora automática a ser inventada e ainda é considerada uma peça única pela precisão que na época apresentava.
Logo se percebeu que, graças à arquitetura criada pelo seu inventor, John von Neumann, baseada em uma unidade
central de processamento que armazena programas e dados, o computador também serve para o processamento de
dados e não apenas para cálculos.
JOHN VON NEUMANN:John von Neumann (1903-1957) foi um matemático húngaro, naturalizado norte-americano,
considerado o pai da Teoria dos Jogos. Seus interesses abrangiam lógica, assuntos militares, computação, economia,
entre outros.
Essa utilidade do computador foi impulsionada com a invenção do disco magnético pela IBM, em 1957, que o
denominou de Dispositivo de Armazenamento de Acesso Direto (DASD, do inglês Direct Acess Storage Device).
Fundamentalmente, o que esse dispositivo – atualmente conhecido como disco rígido e pela sigla HD (Hard Disk) –
apresentou de novidade, à época, foi a capacidade de leitura de dados externos à unidade central de processamento de
forma direta, sem a necessidade de leitura sequencial, como em fitas magnéticas.
Com o advento do armazenamento externo em disco rígido, nasceu a era do processamento de dados por computador.
Você já ouviu falar em Centro de Processamento de Dados (CPD), denominação que ainda persiste em organizações
tradicionais?
Nessa era, os programas de aplicação, desenvolvidos em uma linguagem de programação (usualmente COBOL, em
aplicações empresariais, ou Fortran, em aplicações científicas), manipulavam dados armazenados em arquivos
hospedados em disco magnético, utilizados pelo sistema operacional e formando o que se denomina sistema de
arquivos.
A figura a seguir mostra a evolução obtida ao possibilitar que os programas
acessassem os dados externamente em arquivos no disco (configurando um
avanço em relação aos programas que continham internamente os próprios
dados) para execução em lotes (batch, em inglês), na fase inicial do uso do
computador.
Esse modelo de processamento de dados com sistema de arquivos foi
largamente utilizado no início do emprego do computador em sistemas de
informação empresariais, após o advento do disco magnético, persistindo até os dias atuais, nos chamados sistemas
legados. Exemplo disso, foi a maior demanda por programadores da linguagem COBOL durante a pandemia de COVID-
19 para realizar manutenção em sistemas da Administração Pública do governo dos EUA.
SAIBA MAIS:Para saber mais sobre o aumento da procura por programadores COBOL durante a pandemia de COVID-19,
não deixe de verificar a indicação feita no Explore + ao fim deste tema.
PRIMÓRDIOS DOS SISTEMAS DE BANCO DE DADOS
Seguindo na história, o advento dos bancos de dados foi uma evolução natural dos sistemas de arquivos. Observe na
figura anterior que os programas os quais manipulam os arquivos de dados, além de implementarem a lógica da
aplicação, têm de conter um módulo para a gerência dos arquivos de dados. Esse módulo deve ser repetido em todos os
programas que precisam acessar e manipular o mesmo arquivo de dados.
Por exemplo, o departamento de pessoal de uma organização mantém o arquivo com os dados dos empregados.
Suponha que o departamento de produção também precise usar dados desse arquivo para alocar empregados em
projetos. Nesse caso, os programas de aplicação que atendem aos dois departamentos deverão conter o mesmo
módulo de gerência do arquivo de empregados, causando uma repetição de código de programação e dificultando a sua
manutenção.
Assim, os sistemas de banco de dados (SBD) vieram para mitigar esse problema, a partir de 1960, tirando dos programas
de aplicação a responsabilidade de gerenciar os arquivos de dados, tarefa que passou a ser delegada a um software
intermediário, denominado de sistema de gerência de banco de dados (SGBD), como mostra a figura a seguir.
Essa propriedade dos sistemas de banco de dados é denominada
de independência entre dados e programas, uma diferença primordial em
relação aos sistemas de arquivos.
Em outras palavras, ocorreu uma modularização do sistema de informação, com
a distribuição de responsabilidades entre os programas de aplicação e o SGBD.
Os programas de aplicação passaram a se ocupar exclusivamente das funcionalidades da aplicação propriamente dita,
deixando as tarefas de acesso e manipulação dos dados armazenados em disco para o SGBD, um software tipicamente
auxiliar, de bastidores ou, como se costuma dizer no jargão do mercado, um serviço de back end.
ATENÇÃO:Perceba a diferença entre o sistema de banco de dados (SBD) e o sistema de gerência de banco de /dados
(SGBD), pois o primeiro é mais amplo, englobando o SGBD, os próprios programas de aplicação e os bancos de dados
manipulados por eles.
Neste ponto, cabe um questionamento importante, cada vez mais válido em face dos avanços das tecnologias de
hardware de memória, tanto de memória principal (RAM) quanto de memória secundária (discos magnéticos ou hard
disk drives (HDD) e de semicondutores ou solid state drives (SSD)).
A questão é: qual dos três modelos de sistemas é o mais eficiente para uma aplicação com o mesmo volume de dados,
ou seja, o modelo monolítico com dados junto dos programas; o modelo com sistemas de arquivos; ou o modelo com
sistemas de bancos de dados?
Adiaremos a resposta a essa questão para o final deste módulo.
ESTÁGIO ATUAL DOS SISTEMAS DE INFORMAÇÃO (NA WEB)
Antes de discorrer sobre o histórico dos SBDs, vale completar a evolução dos sistemas de informação até os dias atuais,
fortemente influenciada pela revolução tecnológica causada pela World Wide Web no final do século XX.
Com a popularização da interface Web no desenvolvimento das aplicações,
surgiram novas linguagens de programação e novas formas de
armazenamento e acesso a dados em fontes com diferentes formatos. Assim,
o SGBD das aplicações tradicionais pode ser considerado atualmente como um
gênero de software básico, com papel intermediário, que denominamos na
figura a seguir de middleware, em que se incluem servidores de aplicações das
diferentes linguagens e ambientes de desenvolvimento Web.Essa figura resume o atual estágio dos sistemas de
informação na Web, em que as fontes de dados não se restringem a dados estruturados, como em bancos de dados
tradicionais, admitindo volumes gigantescos em diversos formatos, localizações e velocidade de produção,
características marcantes do conceito de Big Data. Igualmente, as aplicações via Web são desenvolvidas em uma
diversidade de plataformas digitais, de smartphones a supercomputadores, que têm em comum a conexão com a
internet e, em consequência, a computação em nuvem (Cloud Computing).
EVOLUÇÃO DOS SISTEMAS DE BANCO DE DADOS
BANCOS DE DADOS NAVEGACIONAIS:Há uma controvérsia sobre qual foi o primeiro SGBD implementado e utilizado
comercialmente na década de 1960. Sabe-se que duas iniciativas independentes ocorreram paralelamente, resultando
em dois produtos comerciais:
IDS (INTEGRATED DATA SYSTEM):Criado por Charles Bachman (1924-2017) no âmbito de um comitê que padronizou a
linguagem COBOL (CODASYL, de Committee on Data Systems Languages).
IMS (INFORMATION MANAGEMENT SYSTEMS):Criado pela IBM na esteira do sucesso da invenção do disco magnético
anos antes.
O IDS e o IMS tinham em comum a característica de que os dados eram acessados por meio de programas que
“navegam” de registro em registro pela estrutura dos dados armazenados em disco. Por causa dessa característica,
atualmente aqueles SGBDs e outros que seguiram a mesma abordagem são denominados de navegacionais.
Observe a diferença entre eles:
IDS:Usava a estrutura de dados de grafos ou redes, daí a denominação de network databases.
IMS:Adotava a estrutura de dados de árvores, que é um tipo de grafo mais restrito do que as redes, baseado em
hierarquias, originando a denominação hierarchical databases.
Vários SGBDs foram implementados com variantes desses modelos de banco de dados, como o DMS (Data Management
System) e o IDMS (Integrated Database Management System). Vale relembrar que muitos sistemas de informação
legados daquela época ainda utilizam esses SGBDs navegacionais, a exemplo da demanda por programadores COBOL
em meio à pandemia de COVID-19.
O MODELO RELACIONAL DE BANCO DE DADOS:A grande revolução na história dos bancos de dados ocorreu na virada
das décadas de 1960 e 1970, com a publicação do artigo seminal do matemático pesquisador da IBM, Edgar Codd,
intitulado A Relational Model of Data for Large Shared Data Banks, que introduziu o modelo relacional de banco de
dados.
O artigo de Codd, uma das obras mais citadas na comunidade da computação em todos os tempos, foi o marco do
chamado modelo relacional de banco de dados, cuja estrutura de dados, diferentemente dos grafos dos bancos de
dados navegacionais, é uma função matemática denominada relação.
EDGAR CODD:Edgar Frank Codd (1923-2003) foi um cientista da computação e matemático americano que inventou o
modelo de dados relacionais, que levou à criação do banco de dados relacional, um método padrão de recuperação e
armazenamento de dados do computador.
Codd criou uma Álgebra Relacional e um Cálculo Relacional, nos quais baseou toda a teoria matemática das relações em
que fundamentou o modelo relacional. Apesar da base teórica do modelo, a estrutura de dados subjacente tem o
mérito de ser muito simples, pois uma relação nada mais é do que uma tabela formada por colunas e linhas, em cujas
células estão armazenados os dados, conceito compreensível pelo senso comum de qualquer leigo em Matemática ou
computação, como podemos ver a seguir.
A solidez da fundamentação matemática do modelo relacional

disparou uma série de iniciativas de implementação em empresas,
como a própria IBM, e no meio acadêmico, principalmente nas
universidades do estado da Califórnia, onde se localizava o centro
de pesquisas da IBM. A partir de então, a IBM patrocinou o
projeto System R (de Relational), enquanto a Universidade da
Califórnia em Berkeley (UCB) deu início à implementação
acadêmica de um SGBD relacional denominado de Ingres (Interactive Graphics Retrieval System).
PRINCIPAIS SGBDS RELACIONAIS:O projeto System R deu origem ao SGBD comercial da IBM, inicialmente denominado
SQL/DS (Structured Query Language/Data System), depois renomeado de DB2, atualmente um dos líderes no mercado
de bancos de dados corporativos, com versões em diferentes plataformas de hardware/software e na nuvem.
SAIBA MAIS:A linguagem SQL, criada pela IBM como uma linguagem de consulta e manipulação de dados dos bancos de
dados relacionais, passou a ser conhecida como sinônimo de SGBD relacional, chegando a ser confundida com produtos
que levam a sigla em seu nome.
No âmbito comercial, também despontou, como decorrência do sucesso do modelo relacional, o desenvolvimento de
um SGBD pela empresa inicialmente denominada Software Development Laboratories (SDL), depois renomeada
Relational Software Inc. (RSI) e, finalmente, Oracle Corporation, nome pelo qual é atualmente reconhecido como o
SGBD líder do mercado global de banco de dados.
Em 2010, com a aquisição da Sun Microsystems, uma grande empresa de hardware tradicionalmente incentivadora de
projetos de software livre, a Oracle incorporou entre seus produtos o MySQL, um SGBD relacional de reconhecida
liderança na comunidade de desenvolvimento de sistemas para a Web. O SGBD MySQL, associado ao sistema
operacional Linux, ao servidor Web Apache e à linguagem de programação PHP, formou o quarteto de software
conhecido pela sigla LAMP, de grande sucesso no desenvolvimento de aplicações Web até os dias atuais.
Na frente acadêmica, o projeto Ingres, da UCB (Universidade da Califórnia, Berkeley) deu origem a versões comunitárias
mediante licença livre da própria universidade junto com seu sistema operacional Unix, denominado BSD (Berkeley
Software Distribution). O projeto acadêmico originou um produto comercial de mesmo nome, Ingres DBMS, que
concorreu diretamente com o Oracle e o SQL/DS nos primórdios dos SGBDs relacionais.
O esforço de desenvolvimento do Ingres envolveu muitos pesquisadores, professores e estudantes, os quais acabaram
levando o seu código livre em linguagem C para implementação em outros produtos comerciais, notadamente o SGBD
Sybase que, na década de 1990, associou-se à Microsoft, dando origem ao SQL Server, atualmente um dos líderes no
mercado de bancos de dados relacionais.
A continuidade do projeto Ingres deu frutos também na área acadêmica com a evolução para um modelo de dados além
do relacional, estendido com conceitos da programação orientada a objetos, denominado Postgres (de Post Ingres).
SAIBA MAIS:Após a incorporação da linguagem SQL na década de 1990, o Postgres foi rebatizado como PostgreSQL,
atualmente reconhecido como o mais avançado SGBD open source do mundo. Para saber mais sobre o PostgreSQL, não
deixe de verificar a indicação feita no Explore+ ao fim deste tema.
O PostgreSQL e o MySQL são os SGBDs mais utilizados no aprendizado dos bancos de dados relacionais pela sua
popularidade e pelo fato de disponibilizarem versões com licença e documentação livres.
OUTROS MODELOS DE SGBDS
No ranking de popularidade dos SGBDs, disponibilizado pelo DB-Engines em seu website, destacam-se, entre os que
adotam o modelo relacional: Oracle, MySQL, Microsoft SQL Server, PostgreSQL e IBM DB2.
Cabe observar que esse ranking não trata exclusivamente de SGBDs do modelo relacional de dados. Os próprios SGBDs
relacionais, mencionados como líderes de mercado, são classificados no ranking como “multimodelos”, porque
implementam funcionalidades que vão além do modelo relacional. Vejamos:
ORACLE:Relacional e multimodelo (documentos, grafos e RDF)
MYSQL:Relacional e multimodelo (documentos)
MICROSOFT SQL SERVER:Relacional e multimodelo (documentos e grafos)
POSTGRESQL:Relacional e multimodelo (documentos)
IBM DB2:Relacional e multimodelo (documentos e RDF)
E O QUE SÃO ESSES OUTROS MODELOS DE BANCO DE DADOS, ALÉM DO RELACIONAL?
Não resta dúvida de que o modelo relacional se firmou no mundo corporativo, sendo utilizado na grande maioria dos
sistemas de informação empresariais pela sua popularidade e robustez dos produtos disponíveis ao longo de décadas de
desenvolvimento, bem como pela padronização e pelo uso da linguagem de consulta e manipulação de dados SQL.
Entretanto, existem aplicações em sistemas de informação que requerem muito mais recursos de armazenamento e
manipulação de dados do que as tabelas do modelo relacional, em especial aplicações Web e de cunho científico que
processam grandes quantidades de dados em formatos diversos, com as atuais tendências como Big Data, Internet of
Things e Data Science.
Assim, vários modelos de banco de dados não relacionais vêm surgindo no mercado, sendo denominados de NoSQL,
termo traduzido como “Não SQL” ou “Não somente SQL” (de Not Only SQL).
SÃO, DE FATO, BANCOS DE DADOS QUE NÃO ADOTAM O MODELO RELACIONAL DE DADOS E, PORTANTO, NÃO USAM A
LINGUAGEM SQL, EMBORA ALGUNS POSSUAM IMPLEMENTAÇÕES DO COMANDO SELECT DA SQL PARA FINS DE
COMPATIBILIDADE DE LINGUAGEM DE CONSULTA COM OS BANCOS DE DADOS RELACIONAIS.
O estudo de bancos de dados NoSQL está fora do escopo deste tema, constituindo-se em um tema à parte pela
diversidade dos seus conceitos e de suas tecnologias.
É importante conhecer a importância dessa tendência dos SGBDs, como demonstra o site DB-Engines Ranking, que
apresenta mais de uma dúzia de modelos de bancos de dados NoSQL com seus principais produtos, muitos deles
multimodelos.
SAIBA MAIS:Confira a lista de multimodelos
Chave-Valor: Redis, Amazon DynamoDB, Microsoft Azure CosmosDB.
Documentos: MongoDB, Amazon DynamoDB, Microsoft Azure CosmosDB.
Séries temporais: InfluxDB, KDB+, Prometheus.
Grafos: Neo4J, Microsoft Azure CosmosDB, ArangoDB.
Orientado a objetos: InterSystems Caché. Versant Object Database, ObjectStore.
Motores de busca: Elasticsearch, Splunk, Solr.
RDF (Resource Description Framework): Marklogic, Apache Jena, Virtuoso.
Colunar: Cassandra, HBase, Microsoft Azure CosmosDB.
Multivalores: Adabas, UniData/UniVerse, jBASE.
XML nativo: Marklogic, Oracle Berkeley DB, Virtuoso.
Eventos: Event Store, IBM DB2 Event Store, NEventStore.
Conteúdos: JackRabbit, ModeShape.
Navegacional: IMS, IDMS.
COMENTÁRIO:O modelo navegacional é exatamente aquele dos primórdios dos sistemas de banco de dados, da década
de 1960, antes do advento do modelo relacional, cujos produtos ainda continuam sendo utilizados, principalmente em
sistemas de informação legados daquela época.
Para fechar o módulo, neste vídeo o professor Sidney Ventury aprofundará o conteúdo falando um pouco mais sobre as
vantagens que o Banco de Dados trouxe em relação ao antigo sistema de arquivos.
VERIFICANDO O APRENDIZADO
Parte superior do formulário
1. AO FINAL DESTE MÓDULO, É UM BOM MOMENTO PARA RETORNAR À QUESTÃO LEVANTADA DURANTE A DESCRIÇÃO
DOS MODELOS DE COMPUTAÇÃO EM SISTEMAS DE INFORMAÇÃO. QUAL MODELO É O MAIS EFICIENTE PARA UMA
APLICAÇÃO NA MESMA LINGUAGEM DE PROGRAMAÇÃO, COM O MESMO VOLUME DE DADOS, SOB A MESMA
INFRAESTRUTURA DE HARDWARE?
Modelo monolítico com os dados junto dos programas.
Modelo de sistema de arquivos, com os programas acessando os dados através de módulos internos de gerência de
arquivos.
Modelo de sistema de banco de dados, com os programas acessando os dados através de um SGBD.
Modelo de sistema de informação na Web, com os programas acessando os dados na nuvem.
Parte inferior do formulário
2. QUAL O NOME DA LINGUAGEM DE CONSULTA E MANIPULAÇÃO DE BANCO DE DADOS QUE SE TORNOU SINÔNIMO
DO MODELO RELACIONAL DE BANCO DE DADOS?
PostgreSQL
MySQL
SQL
SQL Server
GABARITO
1. Ao final deste módulo, é um bom momento para retornar à questão levantada durante a descrição dos modelos de
computação em sistemas de informação. Qual modelo é o mais eficiente para uma aplicação na mesma linguagem de
programação, com o mesmo volume de dados, sob a mesma infraestrutura de hardware?
A alternativa "A " está correta.
Consideradas as mesmas condições de aplicação, volume de dados e infraestrutura, conforme o enunciado, o modelo
monolítico será mais eficiente, pois todo o processamento será realizado na velocidade de processamento junto à
memória principal (RAM), que é muito mais rápida do que o acesso à memória secundária ou à nuvem.
Na verdade, as alternativas dessa questão estão na sequência de eficiência dos modelos de computação sob as mesmas
condições. Isso não significa que os bancos de dados são ineficientes, pois eles se aplicam adequadamente a cenários
com volumes de dados que não cabem na memória principal, como é o caso de sistemas de informação corporativos.
2. Qual o nome da linguagem de consulta e manipulação de banco de dados que se tornou sinônimo do modelo
relacional de banco de dados?
A alternativa "C " está correta.
Todas as demais alternativas referem-se a nomes de SGBDs que implementam o modelo relacional e, portanto,
implementam a linguagem SQL (Structured Query Language), chegando a confundir o nome do produto com a
linguagem.
MÓDULO 2
Identificar as características dos sistemas de banco de dados (SBD)
DIFERENÇAS ENTRE SISTEMA DE ARQUIVOS E SISTEMA DE BANCO DE DADOS
No módulo anterior, verificamos que uma característica primordial que distingue os sistemas de banco de dados dos
sistemas baseados de arquivos é a independência dos dados em relação a programas. Essa, na verdade, é apenas uma
espécie da característica dos sistemas de banco de dados denominada independência de dados.
O conceito de independência de dados deriva da arquitetura de três esquemas do banco de dados que separa as
aplicações dos usuários finais do banco de dados físico armazenado.
A figura a seguir é uma adaptação da arquitetura ANSI/SPARC, que considera três níveis de esquemas: o nível externo,
que contém o esquema conceitual externo, integrando as diferentes visões dos usuários das aplicações; o nível
conceitual, o qual contém o esquema conceitual lógico ou de implementação, descrevendo a estrutura lógica do banco
de dados; e o nível interno, que contém o esquema interno ou físico do banco de dados armazenado em disco.
Fonte: Tanaka (2018)
Essa arquitetura serve para definir dois tipos de independência de dados, além da independência entre dados e
programas já estudada:
Independência lógica de dados
Consiste na capacidade de se alterar o esquema conceitual lógico, por exemplo, acrescentando um item de dado, sem
alterar o esquema conceitual externo, isto é, as visões externas dos usuários através dos programas de aplicação.
Independência física de dados
Consiste na capacidade de se alterar o esquema interno, por exemplo, reorganizando os arquivos físicos que
armazenam os dados, sem alterar o esquema conceitual lógico e, em consequência, o esquema conceitual externo.
Outras características, entre muitas, que diferenciam os sistemas de bancos de dados dos sistemas de arquivos são
descritas a seguir.
NATUREZA AUTOCONTIDA
Significa que, além dos dados, o SBD contém a descrição completa de suas estruturas e restrições. Como se verá na
arquitetura do SGBD, a descrição da estrutura e das restrições de dados, conhecida como metadados, isto é, dados que
descrevem dados, é armazenada no catálogo do sistema de banco de dados.
ABSTRAÇÃO DE DADOS
Permite a representação conceitual dos dados por meio de modelos de dados que ocultam detalhes de armazenamento
e implementação, os quais não interessam aos diferentes usuários, dando suporte a múltiplas visões lógicas dos dados e
à independência de dados.
SUPORTE AO COMPARTILHAMENTO DE DADOS E PROCESSAMENTO DE TRANSAÇÕES CONCORRENTES
Permite que múltiplos usuários acessem o banco de dados simultaneamente.
Neste vídeo, o professor Sidney Ventury reforçará pontos importantes como os metadados e a arquitetura de três
esquemas.
Os modelos de dados que suportam a abstração de dados e permitem sua independência lógica e física são classificados
em modelos físicos, lógicos e conceituais.
MODELOS FÍSICOS:Descrevem como os dados são armazenados no computador mediante informações como tipos de
arquivos, formatos e ordenação de registros, caminhos de acesso. São as várias formas de estruturas de arquivos que
dependem do SGBD e do sistema operacional em que estão instaladas.
MODELOS LÓGICOS:São aqueles que representam, de maneira abstrata, a implementação dos bancos de dados,
ocultando detalhes de como os dados são armazenados e acessados no disco. O modelo lógico mais tradicional,
largamente utilizado na grande maioria dos sistemas de informação organizacionais, é o modelo relacional criado por
Edgar Codd, mencionado no módulo anterior. A estrutura de dados do modelo relacional é a tabela (relação
matemática) e deve ser estudada em profundidade em tema específico, assim como as implementações de SGBD
relacional. Como vimos, há outros modelos lógicos de implementação do banco de dados entre aqueles que atualmente
se denominam de modelos não relacionais ou NoSQL.
MODELOS CONCEITUAIS:São aqueles que representam a visão dos dados do ponto de vista do usuário final, no nível de
abstração mais próximo do mundo real. Dentre esses, destaca-se o modelo de entidades e relacionamentos, criado pelo
pesquisador Peter Chen, em 1976. O chamado modelo ER, segundo o próprio autor, foi criado para prover um melhor
entendimento do modelo relacional, de modo a servir como uma etapa inicial no processo de projeto de banco de
dados, denominada de modelagem conceitual dos dados.
Vale destacar que a modelagem conceitual de dados realizada com o modelo ER foi incorporada na linguagem UML
(Unified Modeling Language), criada no final da década de 1990 para uniformizar a modelagem orientada a objetos sob
a forma do modelo de classes, em que as entidades são representadas pelas classes de objetos e os relacionamentos
pelas associações entre as classes. Na prática atual do processo de desenvolvimento de sistemas de informação, é
comum a utilização do modelo de classes da UML como substituto do modelo ER nas fases iniciais do projeto de banco
de dados.
ATENÇÃO:Nesse ponto, vale a pena revisitar a definição de banco de dados citada no início do primeiro módulo,
complementando-a com as principais características aqui mencionadas, Assim, podemos definir banco de dados como
uma coleção autodescritiva de dados relacionados, com significado lógico inerente, que pode ser manipulada
concorrentemente por usuários com visões diferentes.
VANTAGENS E DESVANTAGENS DA ABORDAGEM DE BANCO DE DADOS
A abordagem de SBD possui funcionalidades que conferem vantagens adicionais em relação a sistemas sem banco de
dados, além das características que a diferenciam da abordagem de sistemas de arquivos. Algumas dessas
funcionalidades do SBD são listadas a seguir e podem ser objeto de estudo em temas sobre implementação e
administração de banco de dados.
CONTROLE DA REDUNDÂNCIA DE DADOS:Previne a possibilidade de inconsistência dos dados, a duplicação de esforço
para manter os dados atualizados e o desperdício de espaço de armazenamento. O SGBD permite controlar o trade
off entre o armazenamento em um único local no banco de dados versus a redundância forçada para melhorar o
desempenho das consultas.
COMPARTILHAMENTO DE DADOS:Sendo os SBD multiusuários, realizam controle de concorrência de acesso aos dados
compartilhados para garantir as propriedades de atomicidade, consistência, isolamento e durabilidade (propriedades
ACID) das transações de banco de dados.
CONTROLE DE ACESSO:Mecanismos de segurança e autorização, como senhas para usuários e para grupos de usuários;
restrição de acesso a partes do banco de dados; proibição de executar certas operações privilegiadas; acesso de usuário
restrito apenas a transações autorizadas; proibição de uso de software privilegiado, como o software de administração
do SBD.
MÚLTIPLAS INTERFACES DE USUÁRIOS E APLICAÇÕES:Provê diferentes linguagens de consulta para usuários casuais;
linguagens de programação para programadores de aplicações; interfaces gráficas com formulários (telas) e menus para
usuários de aplicações; interfaces para administração do banco de dados; interfaces de linguagem natural.
REPRESENTAÇÃO DE RELACIONAMENTOS ENTRE OS DADOS:Permite representar os relacionamentos existentes entre
dados no mundo real, mediante mecanismos que dependem do modelo lógico de implementação do SBD.
CUMPRIMENTO DE RESTRIÇÕES DE INTEGRIDADE DOS DADOS:Previne a violação de restrições como tipo de dado ou
domínio de valores admissíveis; unicidade de itens de dados por meio de chaves únicas; integridade referencial entre
dados relacionados e restrições derivadas da semântica dos dados. Aqui também o SGBD permite controlar o trade
off entre garantir o cumprimento automático das restrições ou deixar a sua especificação para os programas de
aplicação.
CAPACIDADE DE BACKUP E RECUPERAÇÃO DE DADOS:Em caso de ocorrência de falhas de hardware ou de software, os
mecanismos de cópia de segurança (backup) e posterior restauração (recovery) garantem a consistência de estado do
banco de dados antes e depois da falha.
COMPARTILHAMENTO DE DADOS ENTRE MÚLTIPLOS USUÁRIOS SIMULTÂNEOS:É uma característica primordial do SBD e
tem como resultado o controle de concorrência das transações.
É responsabilidade do SGBD garantir as propriedades das transações, conhecidas pela sigla ACID, relaxando-as quando
necessário para manter o desempenho sob seu controle e para não violar a integridade do banco de dados.
ATOMICIDADE (ATOMICITY):Cada transação é tratada como uma unidade composta de uma sequência de operações, de
modo que deve executar completamente com sucesso ou falhar completamente.
CONSISTÊNCIA (CONSISTENCY):Uma transação só pode levar o banco de dados de um estado válido para outro, de
acordo com suas regras de integridade.
ISOLAMENTO (ISOLATION):Cada transação é isolada das demais, isto é, essa propriedade assegura que transações
executadas concorrentemente levem o banco de dados ao mesmo estado que chegaria se as transações fossem
executadas sequencialmente.
DURABILIDADE (DURABILITY):Uma vez que a transação é aceita (committed), o que significa que seu resultado foi
gravado em memória não volátil, esse resultado permanecerá válido mesmo em caso de falhas do sistema.
VANTAGENS:As vantagens decorrentes dessas funcionalidades do SBD são várias: potencial para o estabelecimento de
padrões de uso dos dados na organização; redução do tempo de desenvolvimento de aplicações; flexibilidade na
manutenção dos dados; disponibilidade dos dados atualizados no âmbito de toda a organização; economia de escala,
entre outras.
DESVANTAGENS:Agora, vejamos as desvantagens da abordagem de banco de dados. Como já foi observado, a presença
do SGBD como um software intermediário entre as aplicações e os dados armazenados provoca uma sobrecarga no
desempenho do sistema como um todo. Além disso, há de se levar em conta o custo e o esforço adicional na
capacitação e no oferecimento de funcionalidades sofisticadas como as já citadas anteriormente.
Assim, pode-se dizer que é preferível não usar a abordagem de SBD em algumas aplicações, tais como:
Aplicações muito simples com dados estáticos e bem definidos, que se espera que não sejam alterados (exemplo: censo
demográfico);
Aplicações de tempo real com requisitos rígidos os quais não possam ser atendidos com o overhead causado pelo SGBD
(exemplo: controle de tráfego aéreo);
Sistemas embarcados, com poucos dados e com requisitos estritos de tempo real (exemplo: piloto automático);
Sistemas monousuários de uso sem concorrência, típicos de aplicações em desktop (exemplo: prontuário eletrônico de
um único consultório médico).
Poderiam ser enquadradas nessa lista as aplicações que requerem dados volumosos com dinâmica não processável por
SGBDs tradicionais, como a Internet das Coisas (IoT, de Internet of Things), porém, o advento de bancos de dados
NoSQL, com modelos de dados específicos para tratamento de Big Data, busca a atender a esses tipos de aplicações
incompatíveis com os modelos tradicionais de SGBD.
PAPÉIS EM SISTEMAS DE BANCOS DE DADOS
A figura a seguir mostra as camadas de um sistema de computação
desde o hardware, onde são armazenados os arquivos com programas e
dados, até as aplicações disponíveis aos usuários finais, que podem ser
desenvolvidas com ou sem a utilização de um SGBD. Na ilustração,
podemos ver também a existência de diferentes papéis de usuários ao
longo das camadas de software.
Em um sistema de computação corporativo de grandes organizações, é possível separar os diferentes papéis
desempenhados como mostra a figura.
USUÁRIOS FINAIS:Beneficiários dos sistemas que rodam no sistema de computação, seja por aplicações desenvolvidas
com a abordagem de banco de dados ou não.
ADMINISTRADOR DE APLICAÇÕES:Função técnico-gerencial responsável pela manutenção dos sistemas de aplicação e
pelo suporte aos seus usuários, podendo ser exercida por vários administradores. Exemplo: administrador do sistema
integrado de gestão empresarial, conhecido pela sigla ERP (Enterprise Resource Planning).
ADMINISTRADOR DE DESENVOLVIMENTO:Função técnica que pode ser desdobrada em equipes de desenvolvimento do
sistema de aplicação, dependendo do porte e da complexidade do sistema, que se utilizam das ferramentas disponíveis
no ambiente de desenvolvimento de sistemas.
ADMINISTRADOR DE DADOS:Função gerencial responsável pelo ambiente de dados da organização, que define políticas
e responsabilidades sobre os recursos de dados, assim como as regras do negócio e os padrões de dados a serem
seguidos no desenvolvimento.
ADMINISTRADOR DO BANCO DE DADOS:Função técnica responsável pela criação e manutenção dos bancos de dados no
SGBD, dando suporte às equipes de desenvolvimento no tocante aos objetos dos bancos de dados.
ADMINISTRADOR DE SISTEMA:Responsável por manter no ar o sistema de computação como um todo, com foco no
hardware e no sistema operacional, bem como nas interfaces deste com os demais softwares instalados.
CABE OBSERVAR QUE NEM TODOS OS PAPÉIS DE ADMINISTRAÇÃO PODEM SER EXERCIDOS POR UMA ÚNICA PESSOA,
MAS UMA PESSOA PODE EXERCER MAIS DE UM PAPEL. A DISTRIBUIÇÃO DESSES PAPÉIS POR PESSOAS E EQUIPES
DEPENDERÁ DO PORTE DA ORGANIZAÇÃO E DO SISTEMA DE COMPUTAÇÃO, VARIANDO DESDE UMA ÚNICA PESSOA
EXERCENDO TODOS OS PAPÉIS DE ADMINISTRAÇÃO ATÉ TODO UM DEPARTAMENTO DE TI ENCARREGADO DA
ADMINISTRAÇÃO E DO SUPORTE AOS DIVERSOS SISTEMAS EM OPERAÇÃO.
1. ANALISE AS SEGUINTES AFIRMAÇÕES E RESPONDA QUAL ALTERNATIVA CORRESPONDE A CARACTERÍSTICAS QUE
DISTINGUEM OS SISTEMAS DE BANCO DE DADOS DOS SISTEMAS DE ARQUIVOS.
I. NATUREZA AUTOCONTIDA DOS DADOS
II. VOLATILIDADE DOS DADOS
III. ABSTRAÇÃO DE DADOs
Somente as afirmações I e II.
Somente as afirmações I e III.
Somente as afirmações II e III.
Todas as afirmações estão corretas.
2. QUAL DAS ALTERNATIVAS ABAIXO NÃO É UMA FUNCIONALIDADE DOS SISTEMAS DE BANCO DE DADOS?
Representação de relacionamentos entre os dados.
Controle de redundância de dados.
Compartilhamento de dados.
Armazenamento de dados estáticos.
GABARITO
1. Analise as seguintes afirmações e responda qual alternativa corresponde a características que distinguem os sistemas
de banco de dados dos sistemas de arquivos.
I. Natureza autocontida dos dados
II. Volatilidade dos dados
III. Abstração de dados
A alternativa "B " está correta.
A natureza autocontida dos dados, com o armazenamento junto aos metadados, e a abstração de dados, permitindo a
independência dos dados, são características que diferenciam os SBD dos sistemas de arquivos. Já a volatilidade dos
dados não é uma característica dos SBD.
2. Qual das alternativas abaixo não é uma funcionalidade dos sistemas de banco de dados?
A alternativa "D " está correta.
O armazenamento de dados estáticos é uma das situações em que não é recomendável o uso da abordagem de banco
de dados, pois não se trata de uma funcionalidade típica dos SBDs, como as demais alternativas.
MÓDULO 3
Descrever a arquitetura dos sistemas de gerência de banco de dados (SGBD)
COMPONENTES DE UM SISTEMA DE BANCO DE DADOS
A figura a seguir mostra uma visão simples do ambiente de banco de dados, compreendendo programas de aplicação ou
consultas de usuários que acessam os dados e metadados armazenados em disco através do SGBD. Este, por sua vez,
compõe-se, simplificadamente, de um software para processar consultas e programas e outro para acessar os dados e
metadados armazenados.
Nota-se, na figura, que não se confundem o SBD e o SGBD, visto que este é um componente daquele que engloba
também os programas e as consultas, bem como os dados e metadados armazenados.
A fronteira do SBD engloba os programas que implementam as aplicações, bem como as consultas provenientes de
usuários com acesso a linguagens e interfaces de consulta. O SGBD é o software intermediário, uma caixa preta a ser
aberta no próximo módulo. A fronteira do SBD envolve os metadados armazenados no catálogo (às vezes chamado de
dicionário de dados) e o próprio conteúdo armazenado no banco de dados.
COSTUMA-SE DEFINIR METADADOS COMO O ESQUEMA DO BANCO DE DADOS,
ESTRUTURADO DE ACORDO COM O MODELO LÓGICO DE IMPLEMENTAÇÃO.
ASSIM, MODELAR UM BANCO DE DADOS CONSOANTE AO MODELO LÓGICO DE
IMPLEMENTAÇÃO EQUIVALE A ESQUEMATIZAR O BANCO DE DADOS CONFORME
OS CONSTRUTORES DESSE MODELO. POR EXEMPLO, NO MODELO RELACIONAL, O
ESQUEMA É COMPOSTO POR TABELAS E SUAS COLUNAS. CADA COMANDO DE
DEFINIÇÃO DE DADOS, CRIANDO, ALTERANDO OU REMOVENDO UMA TABELA,
PROVOCA UMA MUDANÇA NO ESQUEMA DO BANCO DE DADOS.
Por outro lado, chama-se de estado ou instância o conteúdo do banco de dados armazenado em um momento. Cada
manipulação no banco de dados mediante comandos de inserção, atualização ou remoção de dados provoca uma
mudança de estado, gerando uma nova instância do banco de dados.
CURIOSIDADES SOBRE BANCO DE DADOS:Como vimos, o termo banco de dados é correntemente usado com o sentido
do original, em inglês, database, cuja origem, segundo o Oxford English Dictionary, remonta a 1962 num relatório de
uma empresa na Califórnia. Raras são as referências ao termo data bank como, por exemplo, no mencionado artigo de
Edgar Codd sobre o modelo relacional (CODD, 1970).
Em espanhol, usa-se base de datos, no francês base de données, enquanto em alemão se diz Datenbank, e em
italiano banca dati.
Em português, existem os dois termos, sendo banco de dados usado no sentido geral do ambiente que engloba o
sistema, como na figura anterior, enquanto base de dados tem o sentido mais restrito do conteúdo do banco, isto é,
corresponde ao estado ou à instância do banco de dados. Por exemplo, costuma-se referir à base de dados da Receita
Federal como o conjunto de dados armazenados sobre os contribuintes e não como o sistema que gerencia os dados.
MÓDULOS DE UM SISTEMA DE GERÊNCIA DE BANCO DE DADOS:A figura a
seguir ilustra, em detalhes, os diversos módulos que compõem um SGBD,
sendo a parte superior correspondente ao processamento das consultas e
aplicações, e a parte inferior ao acesso a metadados e dados armazenados (a
base de dados).
Vamos conferir a descrição desses módulos.
USUÁRIOS:Da esquerda para a direita, vemos os usuários, começando com
os administradores de banco de dados (ABD, do inglês DBA – Database
Administrator).
ABD:O ABD usa comandos da linguagem de definição de dados (LDD, do inglês DDL – Data Definition Language) para
criar, alterar ou remover objetos do banco de dados (comandos CREATE, ALTER, DROP no padrão SQL), os quais ficam
armazenados no catálogo do sistema, que contém os metadados.
O ABD também possui privilégio para executar comandos de controle de dados, conhecidos por alguns autores como
linguagem de controle de dados (LCD, do inglês DCL – Data Control Language), para conceder e revogar permissões de
acesso aos dados (comandos GRANT e REVOKE no padrão SQL), entre outros. Note que o destino desses comandos
privilegiados é um nó central do SGBD, por onde passam todos os comandos destinados ao processador de banco de
dados em tempo de execução, denominado de processador de runtime ou runtime engine.
USUÁRIOS CASUAIS:Seguindo para a direita, vemos os usuários casuais, os quais fazem consultas interativas através de
uma interface para consultas ad hoc, ou seja, consultas não programadas previamente. As consultas são feitas
tipicamente com o comando SELECT no padrão SQL do modelo relacional e provido de modo similar em outros modelos
de implementação de banco de dados. Esses comandos são compilados por um compilador da linguagem de consulta e
passam por um otimizador de consulta antes de chegar ao nó central do SGBD.
PROGRAMADORES DE APLICAÇÕES:Mais à direita, aparecem os programadores de aplicações que escrevem os
programas em uma linguagem de programação hospedeira, como por exemplo, Java, PHP ou Python, nos quais estão
embutidos comandos de consulta (SELECT), inserção, atualização e exclusão de dados em uma linguagem de
manipulação de dados (LMD, do inglês DML – Data Manipulation Language).
No padrão SQL, esses comandos são, respectivamente, INSERT, UPDATE e DELETE. Note que eles manipulam dados,
diferentemente dos comandos da linguagem de definição de dados (CREATE, ALTER, DROP), que manipulam metadados.
PROGRAMAS DE APLICAÇÃO:Os programas de aplicação, portanto, possuem comandos híbridos, da linguagem
hospedeira e da linguagem de consulta e manipulação de dados.
PRÉ-COMPILADOR:Os programas de aplicação são processados, inicialmente, por um pré-compilador, responsável por
separar os comandos e os repassar para os compiladores das respectivas linguagens.
COMPILADORES:Cabe a esses compiladores produzir o código das aplicações sob a forma de transações executáveis,
que ficam à disposição dos usuários paramétricos.
USUÁRIOS PARAMÉTRICOS:Os usuários paramétricos são assim chamados porque interagem com o sistema através de
parâmetros passados em interfaces apropriadas. Por exemplo, um agente de viagens faz uma reserva de passagem
aérea passando ao sistema os dados do passageiro, data e hora da viagem, número do voo, número do assento e outros
parâmetros necessários para efetivar a reserva.
TRANSAÇÕES COMPILADAS:Uma vez executadas as transações compiladas, assim como os demais comandos
provenientes de usuários ou aplicações, são passadas ao nó central do SGBD para posterior processamento do
processador de runtime.
Atenção! Antes de prosseguir na parte de baixo da figura, note que alguns processos da parte de cima, como o
otimizador de consulta e o compilador da LMD, estão ligados ao catálogo por linhas tracejadas, que denotam fluxos de
controle, enquanto as linhas cheias representam fluxos de dados, além de controle. Isso é necessário porque as
referências a objetos do banco de dados existentes no catálogo devem ser consistentes com os objetos, criados e
mantidos pelo ABD mediante comandos da LDD.
PROCESSAMENTO DO ACESSO AOS DADOS ARMAZENADOS:Prosseguindo para a parte do processamento do acesso aos
dados armazenados, observamos que o processador de runtime é o coração do SGBD. De fato, o diferencial dos
produtos de SGBD reside na eficiência e na funcionalidade desse processador, segredo industrial em muitos dos SGBDs
proprietários, a ponto de exigir rigorosos termos de confidencialidade das pessoas que têm acesso ao seu código.
ACESSO A BASE DE DADOS:O processador de runtime também precisa acessar e, por vezes, modificar o catálogo,
dependendo da natureza dos comandos, das consultas ou transações que estiver processando. Como mostra a figura,
ele acessa a base de dados diretamente, sob controle de subsistemas de controle de concorrência, backup e recovery.
Quando precisa realizar operações de entrada e saída (gravação e leitura) na base de dados, o processador
de runtime se vale de um gerenciador de dados armazenados.
A descrição dada, embora simplificada, denota a complexidade de um SGBD, software que evoluiu desde a década de
1960 a ponto de se tornar um recurso robusto, eficiente e indispensável para a maioria das organizações privadas ou
públicas, principalmente com base no modelo relacional de banco de dados.
Existe uma grande quantidade de SGBDs disponíveis no mercado, como mostrou o DB-Engines Ranking, ao listar mais de
300 SGBDs, sendo cerca de 130 deles do modelo relacional.
SAIBA MAIS:A excelente entrada na Wikipédia, intitulada Comparison of relational database management systems, faz
uma comparação de diversas características de SGBDs relacionais, contendo informações detalhadas sobre mais de 60
produtos.
Neste vídeo, o professor Sidney Ventury abordará pontos importantes como runtime, transações compiladas, entre
outros
UM EXEMPLO DE SGBD RELACIONAL: POSTGRESQL
Como vimos anteriormente na evolução histórica dos SGBDs, o PostgreSQL originou-se do projeto Ingres da
Universidade da Califórnia em Berkeley, na década de 1970, tendo sido sucessivamente renomeado de Postgres (Post
Ingres), depois Postgres 95 e, finalmente, PostgreSQL.
Embora fossem implementações do modelo relacional proposto por Edgard Codd (CODD, 1970), o Ingres e o Postgres
originalmente usavam uma linguagem diferente da SQL, adotada pela IBM, conhecida como QueL (Query Language). Por
muitos anos, a QueL persistiu nesses SGBDs em concorrência direta com a SQL da IBM, até que o ANSI (American
National Standard Institute) e depois a ISO (International Standard Organization) reconheceram a SQL como a linguagem
padrão para o banco de dados relacional. A partir de então, a SQL foi implementada no Postgres, passando a ser
chamada de PostgreSQL.
O PostgreSQL, além de ser reconhecido como the world's most advanced open source relational database, possui uma
completa documentação igualmente reconhecida como referência global para os conceitos de SGBD relacional. Não é
sem razão que o PostgreSQL, por ser open source e ter licença livre, é vastamente utilizado no ensino de banco de
dados, além de ser adotado comercialmente em grandes organizações ao redor do mundo.
O POSTGRESQL É UM TÍPICO SGBD RELACIONAL-OBJETO, ISTO É, UM SGBD CUJA ESTRUTURA DE DADOS BÁSICA É A
RELAÇÃO (TABELA), PORÉM CONTEMPLA EXTENSÕES DE TIPOS DE DADOS E CARACTERÍSTICAS PRÓPRIAS DA
ORIENTAÇÃO A OBJETOS. ASSIM, POSSUI SUPORTE EM GRANDE PARTE AO PADRÃO SQL E IMPLEMENTA EXTENSÕES
ÚTEIS COMO: CONSULTAS COMPLEXAS, GATILHOS (TRIGGERS), VISÕES MATERIALIZADAS ATUALIZÁVEIS, CONTROLE DE
CONCORRÊNCIA MULTIVERSIONADO. ALÉM DISSO, PODE SER ESTENDIDO DE MUITAS FORMAS, POR EXEMPLO,
GERANDO NOVOS TIPOS DE DADOS, FUNÇÕES GENÉRICAS E AGREGADAS, OPERADORES, MÉTODOS DE INDEXAÇÃO E
LINGUAGENS PROCEDURAIS.
Em jargão de sistemas, o PostgreSQL usa um modelo de computação cliente/servidor, assim como a maioria dos SGBDs
relacionais empresariais. Uma sessão PostgreSQL consiste dos seguintes processos cooperativos (programas):
Back end:Um processo servidor (back end), responsável por gerenciar os arquivos do banco de dados, aceitar conexões
por aplicações clientes e executar ações sobre o SBD em nome dos clientes. O programa servidor é chamado postgres.
Front end:As aplicações clientes de usuários (front end) que desejam executar operações no banco de dados. Aplicações
clientes podem ser diversas em natureza, como uma ferramenta orientada a texto, uma aplicação gráfica, um servidor
Web que acessa o banco de dados para exibir páginas Web, ou uma ferramenta especializada de manutenção. Algumas
aplicações clientes são fornecidas com a distribuição PostgreSQL (psql, pgadmin).
O PostgreSQL roda em todos os sistemas operacionais importantes, incluindo Linux, UNIX (AIX, BSD, HP-UX, SGI IRIX,
Mac OS X, Solaris, Tru64) e Windows. Possui todas as propriedades ACID das transações (atomicidade, consistência,
isolamento e durabilidade) e tem completo suporte para chaves estrangeiras, junções, visões, funções, triggers, e
procedimentos armazenados em múltiplas linguagens de programação, incluindo Java, Perl, Python, Ruby, Tcl, C/C++, e
sua própria PL/pgSQL, similar à PL/SQL do Oracle.
Como banco de dados de classe empresarial, PostgreSQL possui características sofisticadas como controle de
concorrência multiversão (Multi Version Concurrency Control), recuperação "point in time" (PiTR – Point in Time
Recovery), tablespaces, replicação assíncrona, transações aninhadas (savepoints), online/hot backups, um sofisticado
planejador/otimizador de consultas, e write ahead logging (WAL) para tolerância a falhas.
O PostgreSQL é altamente escalável tanto na quantidade de dados que pode gerenciar como no número de usuários
concorrentes que pode acomodar. Existem sistemas PostgreSQL em ambientes de produção que gerenciam centenas de
usuários simultâneos com dezenas de terabytes de dados armazenados.
Além de possuir um catálogo de sistema totalmente relacional, capaz de suportar múltiplos schemas por database, o
catálogo do PostgreSQL é também acessível através do Information Schema, um conjunto de visões de metadados
definido no padrão SQL.
ATENÇÃO:PostgreSQL suporta índices compostos, parciais e funcionais que podem usar seus métodos de
armazenamento B-tree, R-tree, hash ou GiST. Este último é um sofisticado framework que serve de base para muitos
projetos públicos que usam PostgreSQL, como o OpenFTS (Open Source Full Text Search engine), que provê indexação
online de dados e ranking de relevância para pesquisa em bancos de dados, e o PostGIS, um projeto que adiciona
suporte para objetos geográficos, permitindo seu uso como banco de dados espacial para Sistemas Geográficos de
Informação.
Outras características avançadas do PostgreSQL incluem herança de tabelas, sistema de regras e eventos de banco de
dados.
HERANÇA DE TABELAS:Coloca um "sabor" orientado a objeto na criação de tabelas, permitindo a projetistas de banco de
dados derivar novas tabelas de outras tabelas, tratando-as como classe base. Esse esquema suporta tanto herança
simples como múltipla.
SISTEMA DE REGRAS:Também chamado de sistema de reescrita de consultas, permite ao projetista de banco de dados
criar regras que identificam operações específicas para uma dada tabela ou visão e dinamicamente transformá-las em
operações alternativas quando são processadas (cláusula INSTEAD OF).
SISTEMA DE EVENTOS:É um sistema de comunicação interprocessos em que mensagens e eventos podem ser
transmitidos entre clientes usando os comandos LISTEN e NOTIFY, permitindo tanto comunicação simples peer to
peer como avançadas coordenações entre eventos de banco de dados. Clientes PostgreSQL podem monitorar eventos
de banco de dados, como atualizações, inserções e exclusões em tabelas, enquanto eles acontecem.
ATENÇÃO:O código fonte do PostgreSQL é disponível sob a licença open source BSD. Essa licença dá a liberdade de usar,
modificar e distribuir o PostgreSQL da forma que se desejar, com código aberto ou fechado. Quaisquer modificações,
melhoramentos ou mudanças que você faça serão seus para fazer o que quiser. Por isso, o PostgreSQL não é somente
um poderoso SGBD capaz de rodar o negócio da empresa. Também é uma plataforma de desenvolvimento sobre a qual
se pode desenvolver produtos de software in-house que requeiram um suporte adequado a banco de dados.
Com a grande aceitação do PostgreSQL no mercado, desde 2004, um grupo de contribuidores do seu desenvolvimento
fundou a empresa Enterprise DB, que fornece uma versão empresarial de mesmo nome, com consideráveis extensões
ao PostgreSQL.
1. QUAL É O PRINCIPAL MÓDULO COMPONENTE DE UM SGBD, PELO QUAL PASSAM TODAS AS CONSULTAS E
TRANSAÇÕES DE USUÁRIOS, SEJAM ADMINISTRADORES, USUÁRIOS CASUAIS OU PARAMÉTRICOS?
Compilador de linguagem de manipulação de dados.
Catálogo de metadados.
Otimizador de consulta.
Processador de run time.
2. QUAL É O MODELO DE COMPUTAÇÃO UTILIZADO PELO POSTGRESQL, ASSIM COMO PELA MAIORIA DOS SGBDS
RELACIONAIS EMPRESARIAIS?
Centralizado.
Pessoal.
Cliente/Servidor.
Stand Alone.
GABARITO
1. Qual é o principal módulo componente de um SGBD, pelo qual passam todas as consultas e transações de usuários,
sejam administradores, usuários casuais ou paramétricos?
O processador do banco de dados em tempo de execução (run time) recebe todas as requisições dos usuários e as
processa para acessar o catálogo e a base de dados.
2. Qual é o modelo de computação utilizado pelo PostgreSQL, assim como pela maioria dos SGBDs relacionais
empresariais?
O PostgreSQL usa um modelo de computação cliente/servidor, em que uma sessão consiste de um processo servidor
(back end), que gerencia os arquivos do banco de dados, aceita conexões por aplicações clientes e executa ações sobre
o banco de dados em nome dos clientes, e aplicações clientes de usuários (front end) que desejam executar operações
no banco de dados.
CONCLUSÃO
CONSIDERAÇÕES FINAIS
Este tema abordou uma introdução aos sistemas de banco de dados, resumindo sua evolução histórica desde a
invenção do disco magnético, que possibilitou o início da era de processamento de dados por computador.
Foram examinadas as principais características do sistema de banco de dados (SBD), com ênfase naquelas que o
diferenciam dos sistemas de arquivos, bem como nas suas funcionalidades, vantagens e desvantagens.
Finalizamos o tema com a descrição da arquitetura de um sistema de gerência de banco de dados (SGBD), componente
central do SBD, terminando com um exemplo de SGBD relacional, amplamente utilizado no ensino e no mercado, o
PostgreSQL.
Encerraremos este tema aprofundando um pouco mais sobre sistema de banco de dados.
Tema 2
DEFINIÇÃO:Descrição das etapas de um projeto de banco de dados e dos componentes de um diagrama de entidade e
relacionamento, além da modelagem de entidades e relacionamentos e de atributos.
PROPÓSITO:Identificar as etapas de um projeto de banco de dados a fim de destacar a importância da modelagem
conceitual com o uso de diagrama de entidade e relacionamento, atividade comum aos profissionais da área de análise
de negócio e administração de dados.
PREPARAÇÃO:É recomendável que você reproduza os exemplos práticos usando uma ferramenta para modelagem de
dados como a brModelo, que pode ser baixada gratuitamente para essa tarefa.
OBJETIVOS
MÓDULO 1:Identificar as etapas de um projeto de banco de dados
MÓDULO 2:Reconhecer os elementos do diagrama de entidade e relacionamento
MÓDULO 3:Compreender a modelagem de entidades e relacionamentos
MÓDULO 4:Compreender a modelagem de atributos
INTRODUÇÃO
Queremos construir um banco de dados. Por onde começamos?
Em primeiro lugar, é necessário esclarecer que, ao construirmos um banco de dados, estamos automatizando algum
tipo de negócio, ou mesmo parte dele. Segundo Elmasri e Navathe (2019), um banco de dados representa algum
aspecto do mundo real, às vezes chamado de minimundo ou de universo de discurso. É fundamental conhecermos
como o negócio funciona.
Veremos, neste tema, que a construção de um banco de dados é uma atividade dividida em fases bem definidas. Ao
longo delas, costumamos usar modelos de dados, que servem para que o usuário tenha facilidade para entender
organização da estrutura do banco de dados sendo construído. Perceberemos que isso ocorre porque o modelo não
possui informações muito detalhadas a respeito da representação física dos dados.
A etapa de projeto conceitual servirá para a construção de diagrama de entidade e relacionamento (DER), em que há
dois conceitos essenciais: entidades e relacionamentos. Trabalharemos alterações em um DER com objetivo de
comportar novos requisitos de dados e perceberemos que a construção desse diagrama é um processo incremental e
sempre sujeito a revisões.
No último módulo, voltaremos nossa atenção para a modelagem de atributos para fecharmos o nosso ciclo de
aprendizagem.
MÓDULO 1
Identificar as etapas de um projeto de banco de dados
PROJETO DE BANCO DE DADOS:Projetar um banco de dados, de maneira simplificada, envolve as seguintes fases:
levantamento de requisitos, projeto conceitual, projeto lógico e projeto físico.
Ao construir um banco de dados para alguma corporação, devemos ter em mente que há colaboradores
desempenhando diversas tarefas associadas ao negócio em questão.
Assim, temos que adquirir conhecimento sobre o funcionamento das rotinas e tarefas para capturarmos as
necessidades associadas à gestão de dados. Veremos que esse conhecimento ocorre na fase de levantamento de
requisitos.
LEVANTAMENTO DE REQUISITOS:Ao longo da etapa de levantamento de requisitos, o profissional de dados entrevista
usuários para entender sobre o funcionamento do negócio e documentar os requisitos de dados de maneira completa e
detalhada. Depois disso, pode dar início à próxima etapa: o projeto conceitual.
EXEMPLO:Imagine que você foi convidado a participar de um projeto que objetiva construir um banco de dados para
controlar inscrições de alunos em uma escola de treinamentos na área de Tecnologia de Informação. Após realizar
entrevistas junto aos colaboradores, você identifica os seguintes requisitos de dados da escola:
A escola planeja diversos cursos. Cada um deles possui nome, descrição, carga horária e é identificado por um código
único.
A escola armazena o nome, a data de nascimento, o CPF, o e-mail e um telefone de cada cliente, que é identificado por
um código único.
Quando um cliente faz inscrição em determinado curso, é necessário que se armazene a data. Caso seja cancelada a
inscrição, é preciso saber quando ocorreu esse evento. Um cliente pode fazer diversos cursos.
Com os requisitos de dados em mãos, usaremos um modelo de dados gráfico para formalizar entendimento mais
preciso a respeito dos requisitos de dados. Essa atividade ocorrerá na próxima fase do projeto de banco de dados:
projeto conceitual.
PROJETO CONCEITUAL:O projeto ou esquema conceitual envolve construir um modelo de dados de alto nível a partir
dos requisitos de dados que contêm os principais objetos e seus relacionamentos, mapeados na etapa de levantamento
de requisitos. Nesta etapa, não há preocupação em saber detalhes sobre como os dados devem ser armazenados.
O projeto conceitual usa um diagrama gráfico, conhecido por Diagrama de Entidade e Relacionamento (DER), que possui
três elementos essenciais: entidades, relacionamentos e atributos. Em um DER, cada entidade é representada por um
retângulo com o seu nome. De forma semelhante, cada relacionamento, por um losango ligado por linhas aos
retângulos das entidades participantes do relacionamento.
Os atributos são expressos graficamente ligados à entidade ou ao relacionamento ao qual fazem parte. A Figura 1
representa um DER construído a partir dos requisitos de dados obtidos na
etapa de levantamento de requisitos.
Fonte: Elaboração do autorFigura 1 – DER construído a partir dos

requisitos de dados da Escola.
A partir desse diagrama, é possível concluir que o modelo possui duas
entidades (CLIENTE e CURSO) cuja função é armazenar os dados dos
clientes e dos cursos da escola. Além disso, essas entidades possuem uma relação entre si, de maneira que um cliente
pode fazer inscrição em um ou mais cursos.
[...] O ESQUEMA CONCEITUAL DE ALTO NÍVEL (DER) PODE SER UTILIZADO COMO UMA REFERÊNCIA PARA GARANTIR
QUE TODOS OS REQUISITOS DE DADOS DOS USUÁRIOS SEJAM ATENDIDOS E QUE NÃO ESTEJAM EM CONFLITO.
(ELMASRI; NAVATHE, 2019)
Isso acontece porque a representação dos requisitos de dados a partir do DER permite um aprendizado mais preciso a
respeito do funcionamento do negócio sendo modelado, quando comparado aos requisitos de dados.
OUTRA NOTAÇÃO PARA DER: DIAGRAMA DE CLASSES UML
Ao longo da sua atuação profissional, você perceberá que não há uma notação-padrão para representação dos
conceitos do modelo de entidade e relacionamento. Normalmente, a notação depende de preferência dos profissionais
ou mesmo de regras estabelecidas pela empresa de desenvolvimento. As ferramentas CASE fazem uso de várias
notações. Por exemplo, a utilizada na ferramenta brModelo é muito próxima da notação original para modelos de
entidade e relacionamento.
Em projetos de software, é comum o uso da UML para visualização e documentação dos seus componentes. De certa
forma, um diagrama de classes da UML pode ser considerado uma notação alternativa para representar os conceitos de
um DER. No diagrama de classes UML, cada classe é representada por uma caixa que possui três seções:
SUPERIOR:Exibe o nome da classe.
CENTRAL:Exibe os atributos. Além disso, o desenvolvedor pode, se desejar, adicionar informações sobre o tipo de dados
de algum atributo, colocando um sinal de dois pontos “:” e em seguida o nome do tipo de dados.
INFERIOR:Inclui as operações associadas aos objetos da classe, a serem designadas numa etapa posterior, quando do
projeto das aplicações do banco de dados.
Na terminologia da UML, o relacionamento entre classes é chamado de associação. Assim, uma associação é
representada por uma linha que conecta as classes participantes. Além disso, atributos dos relacionamentos são
colocados em uma caixa conectada à associação por uma linha tracejada. A Figura 2 mostra como o DER construído a
partir dos requisitos de dados da escola pode ser exibido sob a forma de diagrama de classes UML.
Fonte: Elaboração do autorFigura 2 – Esquema conceitual Escola na

notação do diagrama de classes UML.
Após as etapas de levantamento de requisitos e criação do DER,
estamos quase prontos para conhecermos a construção do banco de
dados propriamente dito. Construiremos um modelo de dados de mais
baixo nível, que vai depender da escolha do SGBD. Faremos isso na
próxima fase: o projeto lógico.
PROJETO LÓGICO:O projeto lógico, também conhecido por modelo de dados de baixo nível, objetiva transformar o
modelo conceitual em um modelo lógico, que depende do tipo de SGBD escolhido. Existem diversos modelos lógicos,
por exemplo: Rede, hierárquico, relacional, orientado a objeto, grafos, chave-valor e XML. No entanto, atualmente, o
mais popular é o relacional. Como exemplos de SGBD que fazem uso do modelo relacional, podemos citar: Oracle,
MySQL, PostgreSQL, SQlite e Sql Server.
ATENÇÃO:É importante acompanharmos as tendências de mercado sobre o uso de tecnologias de banco de dados.
No Explore +, no fim do tema, há indicação para pesquisar sobre o portal que tem um ranking com atualização mensal
sobre o uso de SGBDs. Confira.
O modelo relacional de banco de dados surgiu na década de 1970 e representa os dados em estruturas chamadas
tabelas. Cada tabela possui um nome e coluna(s) que compõe(m) a sua estrutura. Nossa tarefa é converter o modelo
conceitual para o lógico relacional. Para isso, utilizaremos regras bem definidas, que dependem dos elementos do DER.
No dia a dia, a conversão DER para o modelo lógico relacional é realizada com o auxílio de alguma ferramenta de
modelagem. No entanto, todo profissional de tecnologia da informação precisa conhecer os princípios utilizados nessa
conversão. A Figura 3 exibe as tabelas originadas das entidades do DER do nosso exemplo, construído na etapa de
projeto conceitual.
Fonte: Elaboração do autorFigura 3 – Tabelas originadas do DER da Escola.
No modelo relacional, as entidades de um DER são representadas sob o
formato de tabelas, por isso, no exemplo, aparecem as tabelas CLIENTE e
CURSO. Em especial, a mesma decisão foi tomada para representar o
relacionamento INSCRICAO. Perceba que nesse ponto do projeto ainda não
definiremos as características dos atributos, tais como tipos de dados e
tamanho. Basta apenas que eles estejam vinculados às suas tabelas.
Além da representação visual do projeto lógico, as tabelas podem ser
expressas com o uso de representação textual.
EXEMPLO:A descrição a seguir corresponde às tabelas originadas das entidades do DER:
CLIENTE (idcliente, nome, datanascimento, CPF, email, telefone)
CURSO (idcurso, nome, cargahoraria, descricao)
INSCRICAO (idcurso,idcliente, datainscricao, datacancelamento)
Observe que, com base na representação textual, podemos dizer que:
Um cliente é caracterizado por um identificador, além de possuir as propriedades nome, data de nascimento, CPF, e-
mail e telefone.
Um curso possui um identificador, além das propriedades nome, carga horária e descrição.
Uma inscrição associa um cliente a determinado curso, além de possuir as propriedades data de inscrição e data de
cancelamento.
Estamos finalizando a nossa jornada nas fases de um projeto de banco de dados. É chegada a hora de construir o
projeto físico.
PROJETO FÍSICO:Durante o projeto físico, definimos os detalhes de implementação dos objetos do banco de dados. No
caso das tabelas, escolhemos os tipos de dados e tamanho das colunas, e especificamos se elas são opcionais ou
obrigatórias.
Os relacionamentos são definidos por uma restrição especial em alguma(s) coluna(s) da tabela em questão. Esse tipo de
restrição é denominado chave estrangeira. Em geral, o projeto físico é realizado com o auxílio de alguma ferramenta
gráfica de modelagem. Há inclusive ferramentas que funcionam online, muitas vezes com a política de oferecer acesso
limitado a diversos recursos.
DICA:Para o nosso exemplo, escolhemos a ferramenta online denominada Vertabelo por ser bastante funcional e sem
custos para fins educacionais.
Ao iniciar o design do modelo, escolhemos o SGBD PostgreSQL como produto-alvo da modelagem. A Figura 4 representa
o modelo físico enriquecido com detalhes de implementação compatíveis com o SGBD escolhido.
Fonte: Elaboração do autorFigura 4 – Modelo físico do estudo de caso Escola.

Observe que, diferentemente do modelo lógico, cada coluna de tabela no modelo
está especificada com detalhes relativos ao tipo de dados, além de restrições em
algumas colunas indicadas pelos marcadores FK, PK e N.
Na criação do esquema do banco de dados, nós utilizamos uma linguagem declarativa, denominada linguagem de
consulta estruturada SQL. A parte da SQL que fornece essas funcionalidades é denominada Linguagem de Definição de
Dados. A Figura 5 apresenta um script DDL SQL compatível com o modelo
escola.
Fonte: Elaboração do autorFigura 5 – Script DDL SQL compatível com o

estudo de caso Escola.
Um script SQL DDL é um conjunto de comandos que, no contexto do nosso
exemplo, servirão para criar as tabelas do banco de dados escola.
Vamos entender o propósito desse código?
Observe que:
A declaração de cada tabela inicia com o comando CREATE TABLE
≪nometabela≫, conforme linhas 1, 9 e 15;
Todo cliente possui um identificador único (idcliente especificado na linha 8);
Todo curso possui um identificador único (idcurso especificado na linha 14);
Cada inscrição possui um identificador único, nesse caso composto por um par de colunas
(idcurso, idcliente especificado na linha 20);
As linhas 21 e 22 garantem que a inscrição será processada envolvendo necessariamente um cliente e um curso
previamente existentes no banco de dados.
Assista, agora, a um vídeo que resume as fases de um projeto de banco de dados estudadas nesse módulo.
Resumindo:Ao longo deste módulo, estudamos as fases de um projeto de banco de dados. Percebemos que esta é uma
atividade que envolve as seguintes tarefas:
Levantar requisitos de dados
Construir um modelo de entidade e relacionamento
Construir um modelo lógico
Implementar o modelo físico
As tarefas de um projeto de banco de dados não são estáticas, visto que os requisitos de dados podem evoluir, por
exemplo, a partir da necessidade de adaptar o negócio a algum tipo de legislação, ou mesmo para tornar o trabalho do
usuário mais eficiente.
1. O PROJETO DE BANCO DE DADOS É DIVIDIDO EM VÁRIAS ETAPAS. UMA DELAS ENVOLVE A CONSTRUÇÃO DE UM
MODELO QUE DESCREVE A ESTRUTURA DO BANCO DE DADOS, COM SEUS OBJETOS, ATRIBUTOS E RELACIONAMENTOS
INERENTES AO FUNCIONAMENTO DO NEGÓCIO ALVO DA MODELAGEM, INDEPENDENTEMENTE DE LIMITAÇÕES
TECNOLÓGICAS, IMPLEMENTAÇÃO OU ATÉ MESMO DISPOSITIVOS DE ARMAZENAMENTO. ESSE MODELO É
DENOMINADO:
Conceitual
Lógico
Físico
Prescritivo
2. ASSINALE A AFIRMATIVA CORRETA ACERCA DAS ETAPAS DE UM PROJETO DE BANCO DE DADOS:
Projeto conceitual: É construído um modelo de dados em função de características técnicas de implementação
existentes em algum SGBD, por exemplo, SQL Server.
Projeto lógico: São especificados esquemas lógicos. Além disso, essa etapa é responsável por criar um modelo físico de
dados a partir do modelo conceitual independente do SGBD escolhido.
Projeto físico: Descreve detalhes sobre tipos de dados e tamanho de colunas. É dependente da escolha de um SGBD.
Projeto físico: Possui total independência de um SGBD específico.
GABARITO
1. O projeto de banco de dados é dividido em várias etapas. Uma delas envolve a construção de um modelo que
descreve a estrutura do banco de dados, com seus objetos, atributos e relacionamentos inerentes ao funcionamento do
negócio alvo da modelagem, independentemente de limitações tecnológicas, implementação ou até mesmo
dispositivos de armazenamento. Esse modelo é denominado:
O modelo conceitual, construído na etapa de projeto conceitual, tem foco na criação de uma visão abstrata do banco de
dados, facilitando o entendimento do modelo por parte do usuário final. Essa visão oculta detalhes de implementação,
por exemplo, a respeito de como os dados serão armazenados.
2. Assinale a afirmativa correta acerca das etapas de um projeto de banco de dados:
Na etapa de projeto físico, a partir da escolha de um SGBD, são definidos detalhes de mais baixo nível, dependentes das
funcionalidades ofertadas pelo SGBD escolhido, visto que o resultado dessa etapa corresponde ao banco de dados
físico.
MÓDULO 2:Reconhecer os elementos do diagrama de entidade e relacionamento
ENTIDADE:De acordo com Heuser (2009), a entidade corresponde a uma representação do conjunto de objetos da
realidade modelada sobre os quais se deseja manter informações no banco de dados. Em um DER, a entidade é
representada por um retângulo e dentro dele definimos o nome da entidade. Vamos
observar um exemplo na Figura 6.
Fonte: Elaboração do autor.Figura 6 – Exemplo de representação gráfica de entidade. Nesse
caso, o retângulo representa o conjunto de todos os alunos sobre os quais há interesse em
manter informações no banco de dados.
RELACIONAMENTO
Heuser (2009) afirma que a propriedade de entidade que especifica as associações entre
objetos é o relacionamento, o qual corresponde a um conjunto de associações entre ocorrências de entidades. Em um
DER, representamos o relacionamento por meio de um losango ligado por linhas conectadas às entidades envolvidas.
Vamos observar um exemplo na Figura 7.
Fonte: Elaboração do autor.Figura 7 – Exemplo de representação gráfica de
relacionamento. Nesse caso, há duas entidades, além do relacionamento POSSUI. Todo
relacionamento pressupõe a existência dos objetos das entidades participantes.
AUTORRELACIONAMENTO
Há casos em que um relacionamento envolve ocorrências de uma mesma entidade (autorrelacionamento). Em especial,
é importante diferenciar o papel que cada ocorrência da entidade cumpre no contexto do relacionamento em questão.
EXEMPLO:Suponha que, para cursar a disciplina Cálculo II, seja necessário ter conhecimentos em Cálculo I. Esse tipo de
situação é conhecido por pré-requisito. A Figura 8 apresenta um autorrelacionamento envolvendo pré-requisitos a
partir da entidade DISCIPLINA:
Podemos verificar que o modelo contempla:
Um conjunto de objetos classificados como disciplinas (entidade DISCIPLINA).
Um conjunto de associações. Cada associação (relacionamento PREREQUISITO)
relaciona uma disciplina liberadora (que o aluno precisa ter cumprido) e uma
disciplina liberada (que o aluno poderá cursar).
Em nosso exemplo, Cálculo II é a disciplina liberada e Cálculo I, a liberadora.
CARDINALIDADE DE RELACIONAMENTOS
Até o momento, identificamos um relacionamento (POSSUI) entre as entidades CURSO e DISCIPLINA. No entanto,
surgiram quatro importantes perguntas:
1. Toda disciplina, para existir no banco de dados, tem de estar associada a algum curso?
2. Uma disciplina pode estar associada a, no máximo, quantos cursos?
3. Todo curso, para existir no banco de dados, tem que estar associado a alguma disciplina?
4. Um curso pode estar associado a, no máximo, quantas disciplinas?
Expressaremos essas respostas no DER, usando o conceito de cardinalidade em relacionamentos. A cardinalidade é um
par ordenado sob a forma (mínima, máxima): 0 ou 1 para a mínima e 1 ou N para a máxima, com N representando
valores maiores que a unidade. Vejamos um exemplo na Figura 8.
Fonte: Elaboração do autor.Figura 8 – Exemplo de representação gráfica do
relacionamento POSSUI, com as cardinalidades definidas.
Podemos então responder:
1Não (cardinalidade mínima 0 expressa ao lado da entidade CURSO);
2Vários (cardinalidade máxima n expressa ao lado da entidade CURSO);
3Não (cardinalidade mínima 0 expressa ao lado da entidade DISCIPLINA);
4Várias (cardinalidade máxima n expressa ao lado da entidade DISCIPLINA).
ATENÇÃO:Cardinalidade de relacionamento
Por convenção, cada par ordenado da cardinalidade diz respeito à participação da entidade localizada no lado oposto do
relacionamento em questão.
RELACIONAMENTO TERNÁRIO:Vamos modelar orientações de alunos em projetos, realizadas por docentes. Há três tipos
de informações: projeto, aluno e docente. Estamos, portanto, diante de um relacionamento ternário. A Figura 9
apresenta a parte do DER contemplando esse requisito de dados.
Cada ocorrência do relacionamento ORIENTACAO vincula três ocorrências de

entidade: um projeto, um aluno a ser orientado e um docente orientador. Em um
relacionamento ternário, especificamos cada par de cardinalidade com base na
relação existente entre o par de cardinalidade restante. Veja a seguir o que expressa
cada par de cardinalidade:
CARDINALIDADE MÁXIMA 1
Expressa no modelo ao lado da entidade DOCENTE, diz respeito ao par (ALUNO, PROJETO). Um aluno participante de um
projeto pode ser orientado por no máximo um docente.
CARDINALIDADE MÁXIMA N
Expressa no modelo ao lado da entidade ALUNO, diz respeito ao par (DOCENTE, PROJETO). Um docente participante de
um projeto pode orientar diversos alunos.
CARDINALIDADE MÁXIMA N
Expressa no modelo ao lado da entidade PROJETO, diz respeito ao par (ALUNO, DOCENTE). Um aluno e um docente
podem participar de vários projetos.
ATRIBUTO
Entidades e relacionamentos podem ter propriedades, que são especificadas pelos atributos.
[...] Atributo corresponde a um dado que é associado a cada ocorrência de uma entidade ou de um relacionamento.
(HEUSER, 2009)
Vamos especificar algumas propriedades para as entidades CURSO e DISCIPLINA:
Todo curso possui um código único, nome e, opcionalmente, data de criação.
Toda disciplina possui um código único, nome e carga horária.
A Figura 10 apresenta a parte do DER contemplando esses requisitos de dados:
Figura 10 – DER contemplando atributos das entidades
CURSO e DISCIPLINA.
Percebemos que os atributos CODIGOCURSO e
CODIGODISCIPLINA são únicos em suas respectivas entidades.
Na prática, essa unicidade significa que:
Todo curso possui valor para o atributo CODIGOCURSO
diferente dos demais
Toda disciplina possui valor para o atributo CODIGODISCIPLINA diferente das demais
Esse tipo especial de atributo é conhecido por atributo identificador e sua representação gráfica é dada por um traço
com uma das extremidades contendo um círculo preenchido. De acordo com os requisitos de dados, DATADECRIACAO é
um atributo opcional, ou seja, não obrigatório. Sua representação gráfica é dada por um traço com uma das
extremidades contendo um círculo pontilhado. Os demais atributos são obrigatórios.
Cardinalidade em atributo
No DER anterior, ao lado do atributo DATACRIACAO, há um par de cardinalidade com valor (0,1). A cardinalidade 0
expressa que o atributo é opcional. A cardinalidade 1 expressa que o atributo é monovalorado. Cada combinação de
cardinalidade tem um significado especial, conforme Tabela 1:
Tabela 1 – Propriedade de atributo de

acordo com a cardinalidade.
ATRIBUTO OBRIGATÓRIO E
MONOVALORADO:Na construção de um
DER, a maioria dos atributos é
monovalorado e obrigatório. Assim, adotaremos a convenção de, nesses casos, não expressar no modelo a
cardinalidade (1,1) por motivos de legibilidade. Assim, de agora em diante, quando não houver cardinalidade expressa
em atributos de um DER, considere que eles são monovalorados e obrigatórios.
ATRIBUTO COMPOSTO:Em modelagem, é comum surgirem atributos mais complexos, que podem ser subdivididos em
partes menores; eles são conhecidos por atributos compostos. Por exemplo, um atributo endereço pode ser subdividido
em logradouro, complemento, CEP e cidade.
MODELO DE ENTIDADE E RELACIONAMENTO ESTENDIDO:O modelo de entidade e relacionamento estendido traz novos
componentes semânticos. Estudaremos a especialização/generalização, além da entidade associativa.
ESPECIALIZAÇÃO/GENERALIZAÇÃO:Imagine que, além dos docentes, seja necessário gerenciar outros funcionários da
instituição, como os analistas. Podemos deixar previsto que a IES pode ter funcionários que não são analistas nem
docentes.
Queremos, ainda, saber a formação de graduação de cada docente. Surge, então, uma hierarquia, visto que docente é
um subtipo de funcionário. Funcionário é um objeto mais genérico, estando, portanto, na posição superior da
hierarquia.
O mecanismo de especialização/generalização é representado por um triângulo, com a entidade mais genérica
localizada na parte superior e a(s) entidade(s) especializada(s) na parte inferior. Vamos observar o DER na Figura 11 com
os novos requisitos de dados.
Fonte: Elaboração do autor.Figura 11 – DER com mecanismo de
especialização/generalização.
Nós podemos perceber que:
Todo funcionário possui um código único, além de nome e pelo menos um telefone
Há duas entidades especializadas: DOCENTE e ANALISTA. A entidade DOCENTE possui
um atributo obrigatório GRADUACAO
No mecanismo de especialização/generalização há o uso de herança de
propriedades: Cada entidade especializada herda as propriedades da entidade mais genérica. Assim, todo docente
herda as propriedades de funcionário.
CLASSIFICAÇÕES PARA ESPECIALIZAÇÃO/GENERALIZAÇÃO
Observe que perguntas surgem quando analisamos o DER apresentado anteriormente.
Pode existir funcionário que não seja nem docente nem analista?
Pode existir funcionário que seja docente e analista?
A classificação total/parcial responde ao primeiro questionamento: Se a resposta for não, a especialização é total. Caso
contrário, parcial. O segundo é respondido com auxílio da classificação exclusiva/compartilhada: Se a resposta for não, a
especialização é exclusiva. Caso contrário, compartilhada. As combinações das classes estão expressas na Tabela 2:
 Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Tabela 2 – Classificação do mecanismo de especialização/generalização.
Exclusiva(x) Compartilhada(c)
Total(t) Tx Tc
Parcial(p) px Pc
EXEMPLO:Vamos convencionar respostas às perguntas realizadas:
1. Pode existir funcionário que não seja nem docente nem analista? Sim.
2. Pode existir funcionário que seja docente e analista? Sim.
Agora vamos observar o DER na Figura 12, já com a com informação (pc) sobre a classificação do mecanismo de
especialização/generalização.
DER com mecanismo de especialização/generalização fazendo uso das classificações parcial e compartilhada.

No exemplo, parcial significa que pode existir funcionário não especializado, ou seja, não classificado como docente ou
analista. Por fim, compartilhado significa que no contexto da IES pode existir funcionário que atue como docente e na
função de analista.
ENTIDADE ASSOCIATIVA:É comum a necessidade de vincular entidade a algum relacionamento. Ao modelarmos a
inscrição de alunos em disciplinas, criaremos turmas para serem associadas às disciplinas que serão liberadas para
inscrição. Suponha que:
Toda turma possui código, descrição e data de criação. Além disso, pode estar associada a diversas disciplinas. Uma
disciplina pode ser ofertada em várias turmas
Ao ofertar uma disciplina, é necessário saber o número de vagas e quando o aluno fez inscrição na mesma
Haverá um relacionamento (OFERTA) entre TURMA e DISCIPLINA. OFERTA deverá estar associada a ALUNO, via
relacionamento INSCRICAO. Como resolver esse impasse? O objeto entidade associativa surgiu como alternativa de
modelagem em situações dessa natureza. Ela é representada por um losango desenhado dentro de um retângulo.
Observe o modelo na Figura 13:
Fonte: Elaboração do autor.Figura 13 – DER com os novos requisitos de dados,
fazendo uso de entidade associativa.
É necessário enxergar OFERTA sob duas perspectivas:
Relacionamento:OFERTA possui atributo VAGAS, útil no planejamento das turmas e
disciplinas que serão ofertadas para inscrição.
Entidade:OFERTA útil para identificar a turma e a disciplina escolhida pelo aluno
quando do momento de uma inscrição.
Vamos conhecer um estudo de caso para entender melhor os modelos de entidades
e relacionamento:
Resumindo
No segundo módulo, estudamos os componentes de um diagrama de entidade e relacionamento (DER). Além disso,
conhecemos elementos do modelo de entidade e relacionamento estendido.
1. CONSIDERE O DER A SEGUIR SOBRE INSCRIÇÃO EM CONCURSO PÚBLICO.
QUAL PROPOSIÇÃO ESTÁ CORRETA?
A fim de adicionar ao modelo informações do EXAME para, posteriormente,
armazenar dados referentes às provas, a alternativa mais indicada é criar um
atributo simples na entidade CANDIDATO.
O atributo DATA está representado incorretamente no modelo, uma vez que
não é permitido modelar atributo em relacionamento.
De acordo com o modelo apresentado, um CANDIDATO pode inscrever-se em mais de um EXAME.
No modelo, há um relacionamento ternário, pois estão envolvidos três objetos: CANDIDATO, INSCRICAO e EXAME.
2. CONSIDERE O DER A SEGUIR. QUAIS PROPOSIÇÕES ESTÃO CORRETAS?
I. TODO FUNCIONÁRIO ESTÁ ALOCADO EM UM DEPARTAMENTO.
II. NÃO PODE EXISTIR MAIS DE UM CARGO COM O MESMO SALÁRIO.
III. SALARIO É CONSIDERADO UM ATRIBUTO OBRIGATÓRIO EM CARGO.
IV. CODIGOCARGO É CONSIDERADO UM ATRIBUTO OBRIGATÓRIO NA ENTIDADE
CARGO.
V. O ATRIBUTO NOME DA ENTIDADE FUNCIONARIO É DO TIPO COMPOSTO.
III e IV
III e V
I, III e IV
I e II
GABARITO
1. Considere o DER a seguir sobre inscrição em concurso público. Qual
proposição está correta?
A proposição da alternativa C está correta, pois a informação sobre o número
de vezes em que um CANDIDATO pode fazer inscrição em exames é definido
pela cardinalidade máxima n, expressa ao lado da entidade EXAME.
2. Considere o DER a seguir. Quais proposições estão corretas?
I. Todo funcionário está alocado em um departamento.

II. Não pode existir mais de um cargo com o mesmo salário.
III. SALARIO é considerado um atributo obrigatório em CARGO.
IV. CODIGOCARGO é considerado um atributo obrigatório na entidade CARGO.
V. O atributo nome da entidade FUNCIONARIO é do tipo composto.
A proposição III está correta, pois, em nosso estudo, convencionamos que todo atributo sem a cardinalidade explícita
será considerado obrigatório e monovalorado. A proposição IV está correta, pois todo atributo identificador por padrão
é obrigatório.
MÓDULO 3:Compreender a modelagem de entidades e relacionamentos
OBJETIVOS AO CONSTRUIR UM DER:Um DER deve capturar as partes mais importantes do negócio sendo modelado,
pois pessoas diferentes precisam ter o mesmo entendimento do modelo. Manter um DER atualizado facilita a vida dos
profissionais de TI, já que, com a documentação atualizada, a curva de aprendizado sobre a organização pode ser
minimizada.
Apesar de ser relativamente simples construir um DER, é comum identificarmos propriedades desejáveis no banco de
dados que precisam ser registradas mas não podem ser expressas diretamente no modelo. Na linguagem técnica de
banco de dados, regras que devem ser obedecidas pelo SGBD em relação ao banco de dados são conhecidas por
restrições de integridade.
Há restrições de integridade expressas por meio de algum elemento do próprio DER, por exemplo, ao definirmos
cardinalidade para algum atributo. No entanto, há restrições que precisam ser expressas em separado, normalmente
usando linguagem natural. Essas, normalmente, são conhecidas como restrições semânticas.
EXEMPLO;Podemos estabelecer que, no relacionamento de orientação realizado por docentes aos alunos no contexto
de um projeto, a data de término da orientação nunca deve ser menor que a data de início. Estamos diante de uma
restrição que leva em conta dois atributos de relacionamento definidos no DER. Nós especificamos essa restrição no
DER com o uso de linguagem natural sob a forma de um texto. Veja na Figura 14 como ficou o modelo:– DER com uma
restrição semântica adicionada sob o formato de um texto.
ATENÇÃO:O quanto devo modificar um DER para
registrar restrições de integridade?
O objetivo fundamental na construção de um DER é
projetar um banco de dados e não descrever todas as
restrições de integridade.
MODELAGEM DE ENTIDADES E RELACIONAMENTOS:A
partir de agora, daremos ênfase no processo de
modelagem de entidades e relacionamentos.
No entanto, modelos diferentes podem obter o mesmo resultado prático?
EQUIVALÊNCIA ENTRE MODELOS
[...] PARA FINS DE PROJETO DE BANCO DE DADOS, DOIS MODELOS ER SÃO EQUIVALENTES QUANDO AMBOS GERAM O
MESMO ESQUEMA DE BANCO DE DADOS.(HEUSER, 2009)
EXEMPLO:Observe o DER expresso na Figura 15:
Fonte: Elaboração do autor.Figura 15 – DER associando disciplinas a
cursos, com uso de relacionamento N:N.
Ao analisarmos o DER, percebemos que a cardinalidade máxima do
relacionamento POSSUI é do tipo N:N. Sendo assim, um modelo
equivalente sem uso de relacionamento N:N será criado, onde
POSSUI será modelado como entidade, conforme expresso na
Figura 16:
Fonte: Elaboração do autor.Figura 16 – DER associando disciplinas a cursos, sem relacionamento N:N.

Generalizando, todo relacionamento N:N pode ser transformado
em entidade. Para isso, basta seguir as etapas a seguir.
1Representar o relacionamento N:N como uma entidade.
2Relacionar a entidade criada na etapa 1 às entidades participantes
do relacionamento original.
3Adicionar à entidade criada na etapa 1 o(s) atributo(s) − caso
exista(m) − do relacionamento original.
4A entidade criada na etapa 1 será identificada pelos relacionamentos com as entidades participantes do
relacionamento original.
5Estabelecer a cardinalidade (1,1) da entidade criada na etapa 1 para cada relacionamento vinculado a ela.
SAIBA MAIS
Para complementar o nosso entendimento, a seguir adicionamos observações sobre o nosso modelo, de acordo com as
etapas apresentadas anteriormente.
1. Representar o relacionamento N:N como uma entidade: Foi criada a entidade POSSUI.
2. Relacionar a entidade criada na etapa 1 às entidades participantes do relacionamento original: A entidade POSSUI foi
relacionada às entidades CURSO e DISCIPLINA.
3. Adicionar à entidade criada na etapa 1 o(s) atributo(s) − caso exista(m) − do relacionamento original: Como não havia
atributos no relacionamento original, a entidade POSSUI foi criada sem atributos.
4. A entidade criada na etapa 1 será identificada pelos relacionamentos com as entidades participantes do
relacionamento original: Esta identificação está representada no modelo com as linhas mais espessas saindo da
entidade POSSUI.
5. Estabelecer a cardinalidade (1,1) da entidade criada na etapa 1 para cada relacionamento vinculado a ela: As
cardinalidades estão representadas ao lado da entidade POSSUI.
ATENÇÃO
O relacionamento POSSUI só será cadastrado no banco de dados se houver tanto uma disciplina quanto um curso. Essa
observação é consequência da definição de relacionamento em modelagem de dados. Assim, quando transformamos
um relacionamento em entidade, essa restrição deve ser mantida. De que maneira?
No DER modificado, as linhas mais espessas saindo da entidade POSSUI representam a restrição de que toda ocorrência
desta entidade é dependente da existência tanto de uma disciplina quanto de um curso. Alguns autores
chamam entidade fraca a uma entidade que depende de outra(s) para existir.
MODELAGEM DE ENTIDADE ISOLADA
O DER que nós estamos modelando é referente ao funcionamento de uma única IES. Em função disso, não há
necessidade de informar no banco de dados em qual instituição o aluno está cadastrado ou mesmo à qual IES os cursos
estão relacionados.
[...] UMA ENTIDADE ISOLADA É UMA ENTIDADE QUE NÃO APRESENTA RELACIONAMENTO COM OUTRAS ENTIDADES.
HEUSER, 2009.
No contexto do nosso DER, uma entidade isolada pode servir para modelar características da IES, tais como código e
CNPJ. Portanto, se decidirmos adicionar uma entidade INSTITUICAO ao nosso modelo, esta deverá permanecer isolada,
dado que, de acordo com os requisitos de dados, o banco de dados refere-se a uma única IES. A Figura 17 representa a
entidade isolada INSTITUICAO e seus atributos:
Fonte: Elaboração do autor.Figura 17 – DER com entidade isolada IES.

Observe que com a entidade INSTITUICAO criada, caso haja necessidade de acrescentar outras
características simples à IES, basta adicionar atributos. Por exemplo, poderíamos adicionar
informações sobre data de criação, nome da IES, telefone, entre outras.
QUANDO MANTER HISTÓRICO
Em nosso modelo acadêmico, vamos considerar que surgiu a necessidade de associar docente a departamento. Essa é
uma necessidade comum em praticamente toda IES: Saber quais professores pertencem a qual departamento.
Vamos supor que, após o surgimento dessa demanda, nós levantamos os seguintes requisitos de dados:
Todo departamento é identificado por um código e possui um nome.
Um docente pode estar associado a, no máximo, um departamento.
Com base nos requisitos, construímos o DER mostrado na Figura 18.
Fonte: Elaboração do autor.Figura 18 – DER associando docente a departamento.

Nós podemos perceber que o DER construído está de acordo com os novos
requisitos de dados, pois:
 As informações dos departamentos estão expressas na entidade
DEPARTAMENTO.
 A restrição de que um docente está associado a, no máximo, 1 departamento
está expressa na cardinalidade máxima 1 ao lado da entidade DEPARTAMENTO.
Ora, os requisitos de dados associados a um projeto de banco de dados podem
sofrer alterações ao longo do tempo. Assim, é necessário planejarmos uma
estratégia para refletir as restrições impostas pelo novo cenário. Vamos supor,
então, o surgimento de novo requisito de dados:
É necessário armazenar no banco de dados a movimentação de docentes entre departamentos.
A atuação do docente em um departamento possui uma data de início e uma data de fim.
Esse novo requisito de dados pode ser interpretado como uma necessidade institucional de manter histórico das
movimentações de docentes entre departamentos. O DER contemplando o novo requisito está expresso na figura a
seguir:
Fonte: Elaboração do autor.Figura 19 – DER associando docente a departamento,
contendo histórico das movimentações.
Podemos perceber que, no novo DER:
A cardinalidade máxima N expressa ao lado da entidade DEPARTAMENTO indica que ao longo do seu ciclo profissional
um docente pode ter passado por diversos departamentos da IES.
A atuação do docente em um departamento é caracterizada por uma data de início e uma data de fim.
Perceba que o DER contemplando o novo requisito de dados é semelhante ao DER original. A diferença foi a alteração
de uma cardinalidade máxima, além da adição de dois atributos no relacionamento.
MAIS SOBRE MODELAGEM DE ENTIDADES E RELACIONAMENTOS
Você deve ter notado que um DER não é construído em uma única etapa. Em projetos de banco de dados reais, a
construção de um DER é um processo incremental, ou seja, o modelo vai sendo modificado e enriquecido de forma
gradativa à medida que novos requisitos de dados sejam levantados.
Ao longo dos exemplos que construímos, nós utilizamos uma estratégia que envolveu a modelagem de conceitos mais
abstratos que em seguida foram sendo detalhados. Em geral, identificamos algumas entidades e depois definimos seus
atributos e relacionamentos. Esta estratégia de modelagem que escolhemos é conhecida por estratégia descendente. O
passo a passo a seguir resume etapas utilizadas ao adotarmos esse tipo de estratégia para construção do diagrama de
entidade e relacionamento.
1. MODELO INICIAL
 Identificar entidades
 Identificar relacionamentos, especializações e cardinalidade máxima de relacionamentos
 Mapear atributos de entidades e relacionamentos
 Mapear identificadores de entidades e relacionamentos
2. MODELO DETALHADO
 Definir as cardinalidades dos relacionamentos
 Identificar outras restrições de integridade
3. VALIDAÇÃO
 Revisar o modelo
 Validar o modelo junto ao usuário
É importante observarmos que em qualquer etapa é possível retornar à etapa anterior, dado que estamos diante de
uma construção que envolve um DER que ocorre de forma gradativa.
Vamos conhecer mais sobre o raciocínio para a construção da modelagem de entidades e relacionamentos:
Resumindo
Ao longo deste módulo, estudamos a construção de um DER com ênfase na modelagem de entidades e
relacionamentos. Percebemos que modelos diferentes podem ser gerados a partir dos mesmos requisitos de dados.
Outro importante item que exploramos diz respeito a modificações em um DER com objetivo de registrar histórico de
informações. Aprendemos, ainda, que a construção de um DER é um processo sistemático e incremental, em que é
possível refinar o modelo em cada etapa.
1. UMA CAFETERIA QUE COMERCIALIZA PRODUTOS ALIMENTÍCIOS REALIZA COMPRAS DIÁRIAS DE UMA COOPERATIVA E
ESTÁ ENFRENTANDO DIFICULDADES POR CAUSA DE GESTÃO DO PRAZO DE VALIDADE DE SEUS PRODUTOS.
O PROPRIETÁRIO VAI INVESTIR EM UM SISTEMA QUE REALIZARÁ O CONTROLE DO ESTOQUE E DO PRAZO DE VALIDADE
TOMANDO COMO BASE A DATA DE COMPRA DE CADA PRODUTO ADQUIRIDO DA COOPERATIVA. O DER PARCIAL A
SEGUIR REPRESENTA A MODELAGEM DE DADOS PROPOSTA POR UM PROFISSIONAL, SENDO QUE O ATRIBUTO CÓDIGO
EM CADA ENTIDADE É ÚNICO.
A PARTIR DAS INFORMAÇÕES, É CORRETO AFIRMAR QUE:
O relacionamento entre as entidades PRODUTO e COOPERATIVA é do tipo
um-para-muitos.
O atributo telefone da entidade COOPERATIVA é do tipo composto.
O atributo CODIGOP da entidade PRODUTO é classificado como opcional.
É possível construir um novo DER modelando estoque como entidade, sem
perda de informação em relação ao modelo original.
2. UMA REDE DE OPERADORAS DE PLANOS DE SAÚDE NECESSITA DE UM SISTEMA PARA CONTROLAR SEUS CONTRATOS
JUNTO À REDE CREDENCIADA DE HOSPITAIS. CADA CONTRATO ENTRE A OPERADORA E UM HOSPITAL TEM DURAÇÃO
DE DOIS ANOS. APÓS O TÉRMINO DESSE PRAZO, UM NOVO PODERÁ SER EMITIDO, CASO HAJA INTERESSE ENTRE AS
PARTES. QUAL ALTERNATIVA A SEGUIR REPRESENTA UM DER ADEQUADO AOS
GABARITO
1. Uma cafeteria que comercializa produtos alimentícios realiza compras diárias de uma cooperativa e está enfrentando
dificuldades por causa de gestão do prazo de validade de seus produtos.
O proprietário vai investir em um sistema que realizará o controle do estoque e do prazo de validade tomando como
base a data de compra de cada produto adquirido da cooperativa. O DER parcial a seguir representa a modelagem de
dados proposta por um profissional, sendo que o atributo código em cada entidade é único.
A partir das informações, é correto afirmar que:

De fato, quando o DER tem relacionamento N:N, é possível construir um modelo
equivalente, em que o relacionamento em questão será substituído por uma
entidade, mantendo a semântica do modelo original.
2. Uma rede de operadoras de planos de saúde necessita de um sistema para
controlar seus contratos junto à rede credenciada de hospitais. Cada contrato entre a operadora e um hospital tem
duração de dois anos. Após o término desse prazo, um novo poderá ser emitido, caso haja interesse entre as partes.
Qual alternativa a seguir representa um DER adequado aos requisitos de dados apresentados?
De fato, de acordo com os requisitos de dados, uma operadora pode realizar diversos contratos com o mesmo hospital e
vice-versa. Isso implica que a cardinalidade máxima do relacionamento CONTRATO seja do tipo N:N. Além disso, os
atributos DATAINICIO e DATAFIM são propriedades associadas ao relacionamento CONTRATO, permitindo recuperar
informações históricas.
MÓDULO 4
Compreender a modelagem de atributos
ATRIBUTO X ENTIDADE
Em todos os exemplos que desenvolvemos até o momento, caracterizamos entidades e relacionamentos com o auxílio
da especificação de atributos. No entanto, em algumas situações, modelar um objeto como atributo pode não ser a
melhor alternativa.
No contexto do nosso exemplo acadêmico, é necessário que todo docente tenha pelo menos uma graduação registrada
no banco de dados. Esse requisito está expresso no modelo a seguir.
Fonte: Elaboração do autor.Figura 20 – DER com informação sobre o docente
[graduação mapeada como atributo].
Precisamos lembrar que a graduação do docente está expressa sob o formato de
atributo.
A cardinalidade mínima 1 significa que a informação é obrigatória.
A cardinalidade máxima N representa a informação de que é possível registrar no
banco de dados diversos cursos associados ao docente.
EXEMPLO
Se diversos docentes são formados em Ciência da Computação, não faz muito sentido entrar com essa informação no
sistema diversas vezes. Mesmo porque, em se tratando de informação textual, daria possibilidade de mais de uma
forma de representação para o mesmo item.
Caso, além da informação referente ao nome da graduação, quiséssemos saber o ano em que o docente se formou,
estaríamos diante de uma situação em que o mais adequado seria modelar o objeto graduação como uma entidade.
Assim, diante do novo cenário, o modelo modificado está representado na Figura 21.
Fonte: Elaboração do autor.Figura 21 – DER com informação sobre o docente
[graduação mapeada como entidade].
Vamos perceber que no novo DER:
O objeto graduação foi mapeado sob o formato de entidade.
É possível cadastrar graduações sem vínculo algum a qualquer docente. Essa
conclusão ocorre em função da cardinalidade mínima 0 expressa ao lado da
entidade DOCENTE.
Todo docente necessariamente possui uma graduação. Essa conclusão ocorre
em função da cardinalidade mínima 1 expressa ao lado da entidade
GRADUACAO.
Finalmente, se estivéssemos interessados em modelar um atributo ANOFIM
com objetivo de saber o ano de término da graduação pelo docente, bastaria adicionarmos esse atributo ao
relacionamento DOCENTEGRAD.
ATRIBUTO X ESPECIALIZAÇÃO
Uma situação comum durante a construção de um DER é decidir entre modelar um objeto sob o formato de atributo ou
especialização. O critério a ser usado na decisão é simples: Caso o objeto em questão possua atributo(s) ou
mesmo relacionamento(s), usa-se a especialização.
No DER apresentado, a entidade FUNCIONARIO foi especializada. Devemos perceber que a entidade DOCENTE
está relacionada com a entidade GRADUACAO. Portanto, houve escolha coerente com o critério apresentado.
ATRIBUTO OPCIONAL
Há situações em que surgem diversos atributos opcionais em uma entidade. Devemos, portanto, estar atentos para
perceber se os atributos em questão indicam prováveis entidades especializadas.
EXEMPLO
Suponha que, a partir de agora, tenhamos que saber se determinado funcionário tem registro na Ordem dos Advogados
do Brasil (OAB) ou na Associação Brasileira de Odontologia (ABO). Assim, diante do novo cenário, o modelo modificado
está representado na Figura 22.
Fonte: Elaboração do autor.Figura 22 – DER com informação sobre OAB e ABO.
No DER, foram adicionados os atributos OAB e ABO à entidade FUNCIONARIO.
Devemos perceber que ambos são opcionais, no entanto, não sabemos quais
combinações de atributos são válidas. Por exemplo, um funcionário pode ter
atributos ABO e OAB?
Se realizarmos uma análise mais criteriosa no modelo, vamos perceber que os
atributos ABO e OAB parecem ocultar diferentes categorias: Advogados e
odontólogos. Sendo assim, vamos modificar o modelo optando por modelar os atributos ABO e OAB como entidades
especializadas de FUNCIONARIO. Logo, o modelo a seguir representa as mudanças.
Fonte: Elaboração do autor.Figura 23 – DER com informação sobre OAB e
ABO modeladas com uso do mecanismo de especialização.
Finalmente, devemos perceber que a estratégia adotada tem a vantagem
de modelar a realidade com mais fidelidade, ao mesmo tempo que evitou
modelagem de atributos opcionais na entidade FUNCIONARIO.
ATRIBUTO MULTIVALORADO
Em nosso DER, vamos supor que, a partir de agora, seja necessário
modelar que um funcionário pode ter dependente(s). Ora, vamos perceber que uma primeira linha de raciocínio para
realizar a modelagem desse novo requisito de dados é adicionar um atributo opcional na entidade FUNCIONARIO,
conforme expresso na Figura 24.
Fonte: Elaboração do autor.Figura 24 – DER com informação sobre dependente(s)
modelada sob a forma de atributo multivalorado.
Há dois motivos para evitarmos esse tipo de modelagem:
Ao construirmos o modelo físico, vamos perceber que não existe uma implementação
direta para atributos multivalorados em um SGBD relacional
Na maioria dos casos, atributos multivalorados escondem atributos e relacionamentos
É desejável que o banco de dados possa controlar, por exemplo, o nome e a data de nascimento de cada dependente.
De forma semelhante, seria igualmente desejável diferenciar o tipo ou a categoria de cada telefone pertencente ao
funcionário.
EXEMPLO:O DER a seguir apresenta tanto a modelagem de dependentes quanto a
de telefone sob a perspectiva de entidades relacionadas à entidade FUNCIONARIO:
Fonte: Elaboração do autor.Figura 25 – DER com informações sobre dependente(s)
e telefone(s) modeladas sob o formato de entidade.
Podemos observar que, após a decisão de modelar os objetos dependente e telefone como entidades relacionadas à
entidade FUNCIONARIO, além de termos eliminado atributos opcionais, conseguimos deixar o modelo mais preciso,
legível e com a possibilidade de adicionar novos atributos para as entidades de maneira mais natural.
ATRIBUTO X REDUNDÂNCIA:Estamos chegando ao final do nosso módulo e do tema referente ao assunto de
modelagem conceitual. No entanto, é necessário observar a uma situação muito comum em modelagem de dados.
ATRIBUTOS REDUNDANTES:Atributos redundantes são atributos deriváveis a partir da execução de procedimentos de
busca de dados e/ou cálculos sobre o banco de dados (HEUSER, 2009).
EXEMPLO:Em nosso exemplo acadêmico, vamos supor que seja necessário sabermos a quantidade de dependentes de
cada funcionário. Além disso, precisamos identificar, para cada dependente, o número de matrícula do funcionário
responsável.
O uso de atributos redundantes está expresso na figura a seguir,
propositalmente em destaque:
Fonte: Elaboração do autor.Figura 26 – DER com atributos redundantes.
Devemos perceber que:
Não é necessário manter o atributo QTDEDEPENDENTES na entidade
FUNCIONARIO, pois a informação sobre a quantidade de funcionários pode
ser obtida a partir de um simples processo de cálculo envolvendo o
relacionamento.
Não é necessário manter o atributo CODIGOFUNCIONARIO na entidade
DEPENDENTE, pois seu valor pode ser obtido ao acessar a entidade
FUNCIONARIO através do relacionamento.
Finalmente, atributos redundantes devem ser omitidos do DER, uma vez que esse tipo de modelo não diferencia
atributos redundantes dos sem redundância.
ATRIBUTO COMPOSTO
O atributo composto pode ser dividido em subpartes ou atributos básicos com significados próprios.
EXEMPLO
Em nosso DER, para fins ilustrativos, nós inicialmente modelamos o endereço
do aluno através de um atributo composto subdividido em logradouro e
complemento. Se adicionarmos mais alguns atributos básicos representativos
de outras partes de um endereço, teremos um DER como a seguir.
Fonte: Elaboração do autor.Figura 27 – DER representando a entidade
ALUNO com atributo composto endereço.
Como desvantagem, o modelo ficou com um visual bastante denso. Por outro lado, é comum modelarmos o objeto alvo
do atributo composto sob o formato de entidade relacionada à entidade principal. Vamos então observar essa mudança
na figura a seguir:
Fonte: Elaboração do autor.Figura 28 – DER

representando endereço como entidade.
Perceba que, após eliminarmos o atributo composto, o modelo
ficou menos poluído visualmente, tornando-se mais legível.
Vamos conhecer agora alguns aspectos mais avançados da
modelagem de atributos:
Resumindo:Ao longo da nossa jornada neste módulo, demos ênfase ao processo de modelagem de atributos.
Estudamos diretrizes importantes que devemos levar em consideração ao nos depararmos com atributos opcionais,
multivalorados ou mesmo compostos. Percebemos, ainda, que devemos evitar a modelagem de atributos redundantes.
1. O DER A SEGUIR REPRESENTA INFORMAÇÕES SOBRE CLIENTES.
NO QUE SE REFERE À MODELAGEM DOS ATRIBUTOS, ASSINALE A ALTERNATIVA
VERDADEIRA:
O atributo CODIGOCLIENTE admite repetição de valores.
O atributo DTNASCIMENTO é opcional e composto.
É mais adequado modelar telefone em uma entidade separada, relacionada à entidade
CLIENTE.
Todos os atributos são obrigatórios.
2. O DER A SEGUIR REPRESENTA INFORMAÇÕES SOBRE FUNCIONÁRIOS E SEUS DEPENDENTES.
NO QUE SE REFERE À MODELAGEM DOS ATRIBUTOS, ASSINALE A ALTERNATIVA
VERDADEIRA:
O atributo CODIGOFUNCIONARIO da entidade DEPENDENTE é redundante.
O atributo CODIGOFUNCIONARIO da entidade FUNCIONARIO é opcional.
Os atributos NOME em ambas as entidades são multivalorados.
Os atributos DTNASCIMENTO em ambas as entidades são multivalorados.
GABARITO
1. O DER a seguir representa informações sobre clientes.
No que se refere à modelagem dos atributos, assinale a alternativa verdadeira:
Em um SGBD relacional não há implementação direta para atributo multivalorado, como é o
caso de TELEFONE. Além disso, o modelo fica mais legível quando modelamos TELEFONE em
entidade própria.
2. O DER a seguir representa informações sobre funcionários e seus dependentes.
No que se refere à modelagem dos atributos, assinale a alternativa verdadeira:
De fato, há redundância, visto que é possível localizar o funcionário responsável por cada
dependente ao acessar a entidade FUNCIONARIO através do relacionamento.
CONCLUSÃO
CONSIDERAÇÕES FINAIS:Este tema apresentou as principais etapas de um projeto de banco
de dados, iniciando pelo levantamento de requisitos e, em seguida, passando pelos projetos conceitual, lógico e físico.
Foram examinados os elementos presentes em um DER, bem como o mecanismo de especialização/generalização e o
de entidade associativa, pertencentes ao modelo de entidade e relacionamento estendido.
Finalmente, praticamos a atividade de modelagem, inicialmente com foco em entidades e relacionamentos, terminando
com o estudo de exemplos envolvendo a modelagem de atributos.
Como vimos, um projeto de banco de dados envolve diversas etapas bem definidas. Além disso, a construção de um
DER é um processo incremental, sendo possível que o diagrama seja revisado e alterado para atender a novos requisitos
de dados. Por isso, é importante você pesquisar o Guia da Modelagem de Dados: introdução & modelo conceitual, de
Felipe Almeida.
Tema 3
Projeto de bancos de dodos: modelagem lojica e fisica
DEFINIÇÃO
Componentes do modelo relacional. Formas normais e normalização de dados.
Mapeamento conceitual-lógico: entidades, relacionamentos, atributos e especialização/generalização. Diretrizes para
implementação do modelo no SGBD (Sistema de Gerenciamento de Banco de Dados).
PROPÓSITO
Conhecer os elementos do modelo relacional e as formas normais é essencial para aprender sobre as regras utilizadas
no mapeamento conceitual-lógico. É importante compreender os aspectos físicos que influenciam a implementação do
modelo no SGBD, pois são atividades da rotina dos profissionais de banco de dados.
PREPARAÇÃO
É recomendável que você reproduza os exemplos práticos usando uma ferramenta para modelagem de dados.
Certifique-se de ter baixado para seu computador a ferramenta livre BrModelo.
OBJETIVOS
MÓDULO 1
Identificar os elementos do modelo relacional
MÓDULO 2
Diferenciar formas normais
MÓDULO 3
Aplicar o mapeamento conceitual-lógico
MÓDULO 4
Identificar aspectos físicos para implementação do modelo no SGBD
INTRODUÇÃO
Ao longo deste tema, vamos conhecer os principais conceitos e componentes do modelo relacional. Aprenderemos que
o modelo relacional representa o banco de dados sob o formato de tabelas, estando presente em diversos sistemas
gerenciadores de banco de dados (SGBD), tais como MySQL, Oracle, PostgreSQL e SQL Server.
Ainda, vamos estudar o processo de Normalização como forma de avaliar a qualidade de um projeto de banco de dados
relacional. Em seguida, aprenderemos regras que deverão ser aplicadas para obtermos um modelo lógico a partir de um
modelo conceitual.
Finalmente, investigaremos alguns aspectos físicos que devem ser levados em consideração na implementação do
modelo no SGBD.
MÓDULO 1
Identificar os elementos do modelo relacional
MODELO RELACIONAL
Relação é um termo usado na literatura formal da área de banco de dados. No contexto comercial, usa-se
informalmente o termo tabela.
O MODELO RELACIONAL REPRESENTA O BANCO DE DADOS COMO UMA COLEÇÃO DE RELAÇÕES
(ELMASRI; NAVATHE, 2019).
COMPONENTES DE UMA TABELA
Uma tabela corresponde a um conjunto não ordenado de linhas, que, na terminologia acadêmica, são conhecidas
por tuplas.
As linhas de uma tabela são divididas em campos ou colunas, que, na academia, são chamados de atributos. Os campos
são nomeados com objetivo de facilitar a interpretação dos dados armazenados.
Observe a tabela ALUNO a seguir:
Fonte: AutorFigura: Componentes de uma tabela de
banco de dados.
NOME DE TABELAS
Em um banco de dados relacional, toda tabela deve
possuir um nome único. Além disso, ao longo do nosso
estudo, vamos perceber que a maioria das tabelas de
um banco de dados representa entidades de um
diagrama de entidade e relacionamento (DER).
ATENÇÃO
É importante que, na medida do possível, o nome da tabela represente com clareza o objeto modelado. Por exemplo,
ao lermos o nome ALUNO, criamos a expectativa natural de que a tabela em questão armazene informações sobre
alunos.
COLUNAS DE TABELAS
A primeira linha da tabela de exemplo contém os seguintes campos ou cabeçalhos de coluna: CODIGOALUNO, NOME,
NOMEMAE, CPF e DTNASCIMENTO. Além disso, o nome de coluna deve ser único em cada tabela.
Com isso, percebe-se que o nome de coluna ajuda a entender o papel ou a finalidade dela. Por exemplo, podemos
concluir que DTNASCIMENTO identifica a data de nascimento do aluno.
Outro ponto é que as colunas de uma tabela são monovaloradas, ou seja, é permitido manter no máximo um item de
informação por vez. Por exemplo, é possível existir até uma ocorrência de data de nascimento na coluna
DTNASCIMENTO.
As colunas de uma tabela possuem valores atômicos, ou seja, não admitem colunas compostas de outras. Por exemplo,
não é possível subdividir CODIGODOALUNO em outros campos.
Ao implementar uma tabela em um banco de dados, é necessário definir um tipo de dado para cada coluna. Os mais
comuns são: caractere, numérico, data e booleano.
Alguns SGBDs(Sistemas de Gerência de Banco de Dados) permitem a definição do tipo de dados feita pelo usuário. Em
uma linguagem mais técnica, o conjunto de valores que uma coluna pode assumir é denominado domínio da coluna ou
domínio do campo.
Quando criarmos uma tabela, devemos definir se o valor da coluna é opcional ou obrigatório, em que especificar que
uma coluna é opcional significa que os valores admitem vazio (NULL) ou nulo. Na tabela ALUNO, a coluna NOMEMAE da
linha correspondente à aluna de código 1 está vazia.
LINHAS DE TABELAS
As linhas da tabela, da segunda em diante, representam um item de informação cadastrado no banco de dados.
Dizemos então que um item de informação corresponde a uma unidade básica que servirá para armazenamento e
recuperação de dados. Isto é, se uma tabela de cadastro de alunos contém 10.000 linhas ou registros, podemos dizer
que ela armazena dados de 10.000 alunos.
As linhas de uma tabela permitem o armazenamento de dados sempre de acordo com a semântica ou o significado do
objeto. No caso em tela, a tabela armazena informações de ALUNOS, portanto queremos dizer que essa mesma tabela
não deve ser utilizada para armazenar outros tipos de objetos, como disciplinas ou docentes.
CHAVE PRIMÁRIA
Em uma tabela, um SGBD precisa diferenciar uma linha das demais, isso é feito a partir da definição de uma restrição de
integridade. Na prática, escolheremos uma ou mais coluna(s) para que seu(s) valores se torne(m) únicos no banco de
dados.
ATENÇÃO
Quando escolhemos uma coluna para ser chave primária, dizemos que estamos diante de uma chave simples. Se
escolhermos mais de uma coluna, a chave é dita composta.
VAMOS ESTUDAR UM EXEMPLO DE CHAVE PRIMÁRIA SIMPLES?
Para diferenciar um estudante dos demais na tabela ALUNO, podemos estabelecer a restrição de chave primária
associada à coluna CODIGOALUNO. Ao fazermos isso, na prática, estamos delegando ao SGBD a responsabilidade de
gerenciar essa restrição durante todo o ciclo de vida do banco de dados. Na tabela a seguir, deixamos em destaque a
coluna CODIGOALUNO:
Figura: Tabela ALUNO com destaque à coluna

CODIGOALUNO, escolhida como chave primária
simples.
 Atenção! Para visualização completa da tabela
utilize a rolagem horizontal
Assim, podemos dizer que toda chave primária
tem as seguintes propriedades:
UNICIDADE:o valor da chave primária não permite repetição;
MONOVALORADO:toda linha da tabela possui no máximo um valor de chave primária;
OBRIGATÓRIO:toda linha da tabela necessariamente tem que ter um valor para a coluna que é chave primária. Em
outras palavras, nenhum valor de chave primária deve ser vazio. Esta propriedade é conhecida por restrição de
integridade de entidade.
Ao longo do nosso estudo, iremos aprender que alguns SGBDs permitem associar uma propriedade especial a um
campo, denominada autoincremento. Por meio dessa propriedade, o SGBD incrementa automaticamente o valor de
uma coluna quando um registro é adicionado à tabela. Trata-se de um mecanismo útil para gerar um valor único para
cada registro.
AGORA, VAMOS ESTUDAR UM EXEMPLO CONTENDO CHAVE PRIMÁRIA COMPOSTA.
Considere a tabela a seguir, que representa
dados de dependentes de funcionários:
Figura: Tabela DEPENDENTE com destaque às

colunas CODIGOFUNCIONARIO, NRDEPENDENTE
escolhida como chave primária composta.
 Atenção! Para visualização completa da
tabela utilize a rolagem horizontal
A tabela possui uma chave primária composta
pelo par de colunas CODIGOFUNCIONARIO, NRDEPENDENTE. Devemos notar que nenhuma das colunas que compõem a
chave é suficiente para, isoladamente, diferenciar uma linha das demais, visto que:
Um CODIGOFUNCIONARIO pode aparecer em diferentes linhas da tabela;
Um NRDEPENDENTE pode aparecer em diferentes linhas da tabela.
CHAVE MÍNIMA
Uma chave primária deve ser mínima. Com isso, queremos dizer que todas as colunas que a formam devem ser
necessárias e suficientes para diferenciar uma linha das demais na tabela. Outro ponto importante é que uma chave
mínima não diz respeito ao quantitativo de colunas que a forma.
A chave primária simples (coluna CODIGOALUNO) da tabela ALUNO é mínima. Cada valor de CODIGOALUNO é suficiente
para diferenciar um aluno dos demais. Perceba que, se decidíssemos definir o par de colunas CODIGOALUNO, CPF como
chave primária composta para a tabela ALUNO, a chave não seria mínima, visto que CODIGOALUNO por si só é
suficiente para diferenciar um estudante dos outros.
A chave primária composta (CODIGOFUNCIONARIO, NRDEPENDENTE) da tabela DEPENDENTE é mínima. Somente a
coluna CODIGOFUNCIONARIO não diferencia um dependente dos demais, pois um funcionário pode ter diversos
dependentes. De modo semelhante, somente a coluna NRDEPENDENTE não diferencia um dependente dos outros,
dado que o valor dela aparece em mais de uma linha da tabela DEPENDENTE.
CHAVE CANDIDATA
Ao projetarmos uma tabela, pode ser que mais de uma coluna sirva para diferenciar uma linha das demais. Por exemplo,
na tabela ALUNO, tanto CODIGOALUNO quanto CPF poderiam ser utilizados como chave primária. Logo, podemos dizer
que CODIGOALUNO e CPF são chaves candidatas.
CHAVE ALTERNATIVA
A partir do momento em que escolhemos CODIGOALUNO para ser a chave primária da tabela ALUNO, passamos a
considerar CPF como uma chave alternativa.
Alguns desenvolvedores preferem escolher para chave primária uma coluna artificial, ou seja, que não tenha
dependência das colunas criadas, com objetivo de manter alguma informação referente ao negócio sendo modelado.
CHAVE ESTRANGEIRA
Um banco de dados relacional é composto por um conjunto de tabelas. Na maioria dos casos, existe algum tipo de
relacionamento entre elas. O relacionamento entre tabelas é um dos conceitos fundamentais em projeto de banco de
dados relacionais.
Modelo relacional
Decorre do termo relação, função matemática que conhecemos popularmente como tabela.
Relacionamento
Relacionamento entre tabelas.
Em geral, uma empresa possui informações sobre funcionários e seus dependentes. Vamos observar então a figura a
seguir:
Fonte: AutorFigura: Relacionamento entre
FUNCIONARIO e DEPENDENTE.
A figura permite as seguintes interpretações:
UMA CHAVE ESTRANGEIRA É UMA

COLUNA OU UMA COMBINAÇÃO DE
COLUNAS, CUJOS VALORES
APARECEM NECESSARIAMENTE NA
CHAVE PRIMÁRIA DE UMA TABELA.
(HEUSER, 2009).
ATENÇÃO
No exemplo, CODIGOFUNCIONARIO da tabela DEPENDENTE é chave estrangeira, pois todo valor dessa coluna
necessariamente aparece como valor da coluna CODIGOFUNCIONARIO, chave primária de FUNCIONARIO. Como
consequência, podemos concluir que todo dependente está vinculado a um funcionário.
Deve-se notar que, mesmo que a coluna CODIGOFUNCIONARIO de DEPENDENTE tenha o mesmo nome da coluna que é
chave primária em FUNCIONARIO, é possível nomeá-la de forma distinta. No entanto, usar o mesmo nome facilita na
identificação das colunas relacionadas.
RESTRIÇÕES IMPOSTAS PELA CHAVE ESTRANGEIRA
Percebemos que a chave estrangeira serve para implementar relacionamentos entre tabelas. Para que o banco de
dados permaneça íntegro, algumas restrições devem ser controladas e obedecidas pelo SGBD:
RESTRIÇÃO DE INTEGRIDADE REFERENCIAL

ESQUEMA DIAGRAMÁTICO DE BANCO DE DADOS RELACIONAL
Diversas ferramentas de modelagem permitem o uso de alguma notação gráfica para representar um banco de dados
relacional. Na figura a seguir, temos um diagrama que foi construído a partir de uma ferramenta comercial.
Fonte: AutorFigura: Esquema diagramático “pé de galinha” envolvendo as tabelas FUNCIONARIO e DEPENDENTE.
A notação utilizada é
conhecida por pé de
galinha(Do inglês: Crow’s
Foot). Nesse esquema
diagramático:
ESQUEMA TEXTUAL DE BANCO DE DADOS RELACIONAL

O banco de dados mostrado no diagrama anterior, pode ser declarado sob o formato textual, conforme exemplo a
seguir:
Observe que, no esquema textual, as tabelas são declaradas com
informações sobre o nome, além de uma lista contendo as suas
respectivas colunas. As chaves primárias são sublinhadas. Por fim, as
chaves estrangeiras são declaradas usando o padrão nomecoluna(s)
referencia nometabela(s).
Neste módulo, estudamos os principais elementos do modelo
relacional de banco de dados.
1. A RESPEITO DOS TIPOS DE CHAVES EM PROJETO DE BANCO DE DADOS RELACIONAL, ANALISE AS PROPOSIÇÕES A
SEGUIR:
I. QUANDO MAIS DE UMA COLUNA SERVIR PARA DIFERENCIAR UMA LINHA DAS DEMAIS EM UMA TABELA RELACIONAL
E UMA DELAS É ESCOLHIDA COMO CHAVE PRIMÁRIA, AS RESTANTES SÃO DENOMINADAS CHAVES ALTERNATIVAS.
II. UMA CHAVE PRIMÁRIA CORRESPONDE A UMA COLUNA OU UMA COMBINAÇÃO DE COLUNAS CUJOS VALORES
SERVEM PARA DIFERENCIAR UMA LINHA DAS DEMAIS DE UMA TABELA.
III. A CHAVE ESTRANGEIRA PERMITE A IMPLEMENTAÇÃO DE RELACIONAMENTOS EM UM BANCO DE DADOS
RELACIONAL.
ASSINALE A ALTERNATIVA VERDADEIRA
Somente a proposição I é correta.
Somente a proposição II é correta.
Somente a proposição IIII é correta.
Todas as proposições são corretas.
2. CONSIDERE QUE EM UMA INSTITUIÇÃO DE ENSINO SUPERIOR (IES) EXISTA UM BANCO DE DADOS RELACIONAL
DENOMINADO BDIES QUE POSSUI A TABELA ALUNO CUJOS CAMPOS ESTÃO ASSIM DESCRITOS:
DE ACORDO COM OS FUNDAMENTOS DO MODELO RELACIONAL, É CORRETO
AFIRMAR QUE:
O banco de dados BDIES pode possuir uma coleção de tabelas, todas com nome
exclusivo, com colunas que podem conter valores dentro de um domínio.
A coluna CODIGOALUNO é chave estrangeira na tabela ALUNO.
A coluna CODIGOALUNO pode ser opcional.
A coluna NOME é multivalorada.
GABARITO
1. A respeito dos tipos de chaves em projeto de banco de dados relacional, analise as proposições a seguir:
I. Quando mais de uma coluna servir para diferenciar uma linha das demais em uma tabela relacional e uma delas é
escolhida como chave primária, as restantes são denominadas chaves alternativas.
II. Uma chave primária corresponde a uma coluna ou uma combinação de colunas cujos valores servem para diferenciar
uma linha das demais de uma tabela.
III. A chave estrangeira permite a implementação de relacionamentos em um banco de dados relacional.
Assinale a alternativa verdadeira
De fato, i) quando diversas colunas são candidatas à chave primária e uma é escolhida, as demais passam a ser
denominadas chaves alternativas; ii) o objetivo da chave primária é tornar única cada linha de uma tabela do banco de
dados; iii) as chaves estrangeiras representam restrições capazes de representar relacionamentos entre tabelas.
2. Considere que em uma instituição de ensino superior (IES) exista um banco de dados relacional denominado BDIES
que possui a tabela ALUNO cujos campos estão assim descritos:
De acordo com os fundamentos do modelo relacional, é correto afirmar que:
De fato, toda tabela de um banco de dados relacional tem que possuir um nome
único. As colunas de uma tabela devem estar associadas a um domínio ou tipo de
dados.
MÓDULO 2
Diferenciar formas normais
NORMALIZAÇÃO
Ao longo da nossa jornada, conhecemos os principais elementos do modelo relacional. Quando trabalhamos com
modelagem das tabelas de um banco de dados, ao criarmos as tabelas, é natural definirmos colunas que têm relação
com as características do objeto sendo modelado.
No entanto, modelar um banco de dados relacional não se resume simplesmente a usar uma ferramenta CASE e
adicionar tabelas e relacionamentos sem que haja algum critério para essa construção.
FERRAMENTA CASE
(de Computer-Aided Software Engineering – Engenharia de Software Apoiada por Computador): software de apoio ao
desenvolvimento de sistemas, desde a análise e modelagem até a programação e testes.
Ao longo deste módulo, estudaremos o assunto normalização, que ajudará a responder se um banco de dados foi bem
projetado. Além disso, é possível executar o processo de normalização a partir de qualquer representação de dados.
Isso significa que podemos iniciar o processo a partir de uma tela de sistema, ou mesmo um relatório.
A normalização é um processo baseado no conceito de forma normal (FN), que pode ser vista como uma regra, a qual
deve ser observada na semântica de uma tabela, para que a considerem bem projetada.
ATENÇÃO
Na literatura de banco de dados, há diversas formas normais: 1FN, 2FN, 3FN, FNBC, 4FN e 5FN. No entanto, para fins
práticos, no contexto da maior parte dos projetos de banco de dados relacionais, costumamos executar o processo de
normalização até a 3FN.
Dividiremos o processo de normalização até a 3FN de acordo com o seguinte roteiro:
Vamos estudar um exemplo?Considere o relatório expresso na figura, que informa os docentes participantes em
projetos de pesquisa de uma instituição de ensino superior (IES):
RELATÓRIOS DE ALOCAÇÃO DOCENTE A PROJETOS DE PESQUISA
De acordo com o relatório, nós podemos perceber que:

Agora nós executaremos o segundo
passo do roteiro, que corresponde a
criar tabela não normalizada a partir
do relatório.
TABELA NÃO NORMALIZADA
A figura a seguir representa uma tabela não normalizada, denominada PROJETO, criada a partir do relatório:
Figura: Representação
dos dados do relatório
em tabela não
normalizada.
 Atenção! Para
visualização completa da
tabela utilize a rolagem
horizontal
A representação textual
da tabela está expressa a
seguir:
Nessa representação, a coluna

CODIGOPROJETO diferencia cada
projeto dos demais. A coluna
CODIGODOCENTE diferencia os docentes alocados no contexto de um projeto.
Agora, observe com
atenção a figura
representativa da
tabela não
normalizada:
Agora que
construímos a tabela não normalizada, vamos à próxima etapa, que terá como saída um conjunto de tabelas na 1FN.
PRIMEIRA FORMA NORMAL (1FN)
Uma tabela está de acordo com a 1FN quando não possui atributo(s) multivalorado(s) nem atributo(s) composto(s).
Devemos recordar que, como resultado da etapa anterior, foi criada tabela não normalizada. Para ficar de acordo com a
1FN, nós executaremos os passos a seguir:
Criar tabela na 1FN com a mesma chave primária da tabela não normalizada, além das colunas atômicas da própria
tabela não normalizada.
Criar uma tabela na 1FN para cada coluna composta, identificada na tabela não normalizada. Cada tabela terá uma
chave primária composta pela chave primária da tabela criada no passo anterior e pela coluna identificada como
composta. Além disso, terá as colunas membro da coluna em questão.
Criar uma tabela na 1FN para cada coluna multivalorada. Cada tabela terá uma chave primária composta pela chave
primária da tabela não normalizada e pela coluna identificada como multivalorada.
Ao aplicarmos os passos à tabela PROJETO, teremos como resultado as seguintes tabelas em 1FN:
Ainda, de acordo com a representação textual, devemos perceber que:

A figura a seguir representa o conteúdo das tabelas, com base nos dados originalmente expressos no relatório de
alocação docente a projetos:
Figura: Representação dos dados do relatório em tabelas na 1FN.

DEPENDÊNCIA FUNCIONAL
Se observarmos os dados da tabela PROJETODOCENTE, vamos concluir que o nome do docente é o mesmo para cada
código de docente. Parece então existir uma relação de dependência entre as colunas NOME e CODIGODOCENTE.
Assim, podemos expressar essa relação da seguinte maneira:
Com isso, dizemos que a coluna CODIGODOCENTE é determinante da coluna NOME.
Podemos dizer também que NOME é dependente de CODIGODOCENTE, isto é,
determinado por CODIGODOCENTE.
ATENÇÃO
A generalização dessa informação representa o conceito de dependência funcional.
Dessa forma, seja X um conjunto de atributos e Y um atributo; X → Y significa que o conjunto de atributos X determina o
atributo Y.
DEPENDÊNCIA FUNCIONAL PARCIAL
Observe novamente a tabela PROJETODOCENTE expressa na figura:
PROJETODOCENTE
Figura: Representação
dos dados da tabela
PROJETODOCENTE.
Se analisarmos a relação
CODIGOPROJETO,
CODIGODOCENTE →
NOME, iremos perceber
que NOME é dependente
somente de
CODIGODOCENTE, ou
seja, não é necessária a
existência do par
CODIGOPROJETO, CODIGODOCENTE para determinar o nome do docente. Estamos diante de uma dependência
funcional parcial, visto que identificamos uma coluna dependente somente de parte da chave primária composta.
SEGUNDA FORMA NORMAL (2FN)
Uma tabela está na 2FN, caso esteja na 1FN e não haja dependências funcionais parciais.
Se analisarmos com um pouco mais de atenção cada coluna não chave da tabela PROJETODOCENTE, iremos perceber
que, além da coluna NOME, as colunas CATEGORIA e SALARIO também só dependem da coluna CODIGODOCENTE.
Para ficar de acordo com a 2FN, será necessário eliminarmos as dependências parciais, conforme os passos a seguir:
Manter no modelo cada tabela que possua chave primária simples;
Identificar cada dependência parcial;
Criar uma tabela para cada dependência parcial identificada.
A figura a seguir identifica as colunas dependentes de parte da chave primária na tabela PROJETODOCENTE:
Fonte: AutorFigura: Representação das dependências parciais na tabela PROJETODOCENTE.

Ao aplicarmos os passos ao modelo, teremos como resultado as seguintes tabelas na 2FN:
A figura a seguir representa o

conteúdo das tabelas na 2FN, com
base nos dados, originalmente,
expressos no relatório de alocação
docente a projetos:
PROJETO
PROJETODOCENTE
DOCENTE
Figura: Representação dos dados do relatório em tabelas em 2FN.

O modelo está na 2FN, pois, além de estar na 1FN, não existem dependências parciais.
DEPENDÊNCIA FUNCIONAL TRANSITIVA
Se observarmos os dados da tabela DOCENTE gerada na etapa anterior, podemos concluir que o valor do salário é o
mesmo em cada categoria. Perceba que parece então existir uma relação de dependência entre as colunas CATEGORIA
e SALARIO. Assim, podemos expressar essa relação da seguinte maneira:
Com isso, dizemos que a coluna CATEGORIA é determinante da coluna SALARIO. Podemos
dizer também que SALARIO é dependente de CATEGORIA.
ATENÇÃO
Estamos diante de um exemplo de dependência funcional, em que o determinante é uma coluna que não pertence à
chave primária da tabela.
Uma dependência funcional transitiva ocorre quando uma coluna é dependente de alguma coluna não-chave da tabela.
TERCEIRA FORMA NORMAL (3FN)
Uma tabela está em 3FN caso esteja na 2FN e não possua dependências transitivas.
A figura a seguir identifica a dependência transitiva na tabela PROJETODOCENTE:
Fonte: AutorFigura: Representação da dependência
transitiva na tabela PROJETODOCENTE.
Para ficar de acordo com a 3FN, será necessário
eliminarmos as dependências transitivas, conforme os passos a seguir:
Manter no modelo cada tabela que tenha menos de duas colunas não chave;
Identificar cada dependência transitiva;
Criar uma tabela para cada dependência transitiva identificada.
Ao aplicarmos os passos ao modelo, teremos como resultado as seguintes tabelas na 3FN:
A figura a seguir representa o conteúdo das

tabelas na 3FN, com base nos dados
originalmente expressos no relatório de
alocação de docentes a projetos:
PROJETO
PROJETODOCENTE
DOCENTE
CATEGORIA
Figura: Representação dos dados do relatório em tabelas na 3FN.

O modelo está na 3FN, pois, além de estar na 2FN, não existem dependências transitivas.
Neste módulo, nós aprendemos que o processo de normalização é útil para refinarmos a construção de um banco de
dados relacional. Estudamos três formas normais e percebemos que, ao normalizarmos o nosso modelo, o número de
tabelas tende a aumentar, minimizando assim redundância nos dados.
TABELAS NA 3FN: CONSEQUÊNCIA DE UMA BOA MODELAGEM CONCEITUAL
1. O PROCESSO DE NORMALIZAÇÃO OBJETIVA ELIMINAR DADOS REDUNDANTES, ALÉM DE GARANTIR QUE A
DEPENDÊNCIA DE DADOS FAÇA SENTIDO. A RESPEITO DA TERCEIRA FORMA NORMAL EM UMA TABELA RELACIONAL,
ASSINALE A ALTERNATIVA VERDADEIRA:
A tabela não precisa estar na 1FN.
A tabela não precisa estar na 2FN.
A tabela não pode conter campos opcionais
A tabela precisa estar na 2FN e não deve possuir coluna(s) com dependência(s) transitiva(s).
2. SEJA UMA RELAÇÃO R (C1, C2, C3, C4, C5) COM CHAVE PRIMÁRIA COMPOSTA PELAS COLUNAS C1 E C2 E AS
SEGUINTES DEPENDÊNCIAS FUNCIONAIS:
C1→C3
C3→C4
C2→C5
PODEMOS AFIRMAR QUE O ESQUEMA R ATENDE À:
1 FN
2 FN
3 FN
4 FN
GABARITO
1. O processo de Normalização objetiva eliminar dados redundantes, além de garantir que a dependência de dados faça
sentido. A respeito da terceira forma normal em uma tabela relacional, assinale a alternativa verdadeira:
De fato, para estar na 3FN a tabela tem que respeitar as regras da 2FN, pois uma forma engloba as restrições da forma
anterior. Além disso, não pode haver dependências entre colunas não-chave.
2. Seja uma relação R (C1, C2, C3, C4, C5) com chave primária composta pelas colunas C1 e C2 e as seguintes
dependências funcionais:
C1→C3
C3→C4
C2→C5
Podemos afirmar que o esquema R atende à:
De fato, se C1 determina C3, temos então uma dependência parcial da chave primária, o que é proibido na 2FN. Como
cada FN, a partir da segunda, depende da anterior, a relação R atende à 1FN.
MÓDULO 3
Aplicar o mapeamento conceitual-lógico
MAPEAMENTO CONCEITUAL-LÓGICO
No projeto de banco de dados, há etapas que devem ser seguidas para a construção de um modelo conceitual. Para
tanto, é usual a adoção do diagrama de entidade e relacionamento (DER) - tipo de modelo conceitual em que os
principais objetos do negócio modelado se tornam entidades caracterizadas por atributos e relacionamentos.
Estudamos os principais componentes do modelo relacional, um modelo lógico que é base para a implementação de
bancos de dados relacionais.
Neste módulo, construiremos a ponte entre os modelos conceitual e lógico.
Passaremos, então, a aplicar regras formais de mapeamento do modelo conceitual, visando a construção do modelo
lógico. Na prática, projetaremos um banco de dados relacional a partir de um DER.
REGRAS DE MAPEAMENTO
Podemos dividir o mapeamento conceitual-lógico em quatro etapas:
ENTIDADES
RELACIONAMENTOS
ATRIBUTOS MULTIVALORADOS
ESPECIALIZAÇÃO/GENERALIZAÇÃO
A seguir, conheceremos as regras de cada etapa do mapeamento e a sua respectiva aplicação por meio de exemplos.
MAPEAMENTO DE ENTIDADES
O mapeamento de entidades envolve:
ENTIDADE FORTE OU INDEPENDENTE
Cada entidade E vira uma tabela T;
Cada atributo simples da entidade E vira uma coluna na tabela T;
O atributo identificador da entidade E vira chave primária na tabela T.
ENTIDADE FRACA OU DEPENDENTE:
Cada entidade fraca F vira uma tabela T;
Cada atributo simples da entidade F vira uma coluna na tabela T;
A tabela T possuirá chave estrangeira originada a partir da chave primária da tabela proprietária;
A tabela T possuirá chave primária composta pela coluna chave estrangeira criada no passo anterior e pela coluna
mapeada do atributo identificador da entidade F na tabela T.
EXEMPLO DE MAPEAMENTO DE ENTIDADES:
Conhecidas as regras para o mapeamento de entidades, observe no exemplo a seguir um diagrama de entidade e
relacionamento (DER) contendo duas entidades:
FUNCIONARIO (entidade forte) e FONEFUNC (entidade fraca).
Fonte: AutorFigura: Diagrama de Entidade e Relacionamento (DER) contendo duas entidades.

A figura a seguir exibe o
modelo lógico gerado:
Fonte: AutorFigura: Tabelas

criadas com base no
mapeamento conceitual-
lógico envolvendo entidade.
Note que a tabela FUNCIONARIO corresponde à aplicação da regra para entidade forte. De modo semelhante, a tabela
FONEFUNC corresponde à aplicação da regra para entidade fraca.
Após a aplicação das regras de mapeamento, foi gerada a
representação textual a seguir:
MAPEAMENTO DE RELACIONAMENTOS
O mapeamento de relacionamentos dependerá da cardinalidade
máxima:
RELACIONAMENTOS 1:1:
Cardinalidade (0,1):(0,1): priorizar adição de coluna(s). Alternativa: tabela própria.
Cardinalidade (0,1):( 1,1): priorizar fusão de tabelas. Alternativa: adição de colunas.
Cardinalidade (1,1):( 1,1): fusão de tabelas.
RELACIONAMENTOS 1:N:
Identificar a tabela T do lado N.
Adicionar chave estrangeira na tabela T do lado N referente à chave primária da tabela do lado 1.
Cada atributo simples do relacionamento vira uma coluna na tabela T.
RELACIONAMENTOS N:N:
Cada relacionamento vira uma tabela T.
A tabela T possuirá chaves estrangeiras originadas das chaves primárias das tabelas participantes do relacionamento.
A tabela T possuirá chave primária composta pelas chaves estrangeiras criadas no passo anterior.
RELACIONAMENTOS N-ÁRIOS (ANÁLOGO A RELACIONAMENTOS N:N):
Cada relacionamento vira uma tabela T.
A tabela T possuirá chaves estrangeiras originadas das chaves primárias das tabelas participantes do relacionamento.
A tabela T possuirá chave primária composta pelas chaves estrangeiras criadas no passo anterior.
EXEMPLOS DE MAPEAMENTO DE RELACIONAMENTO 1:1:
Conhecidas as regras para o mapeamento de relacionamentos 1:1, observe no exemplo a seguir um diagrama de
entidade e relacionamento (DER) contendo duas entidades: FUNCIONARIO e NOTEBOOK. Há um relacionamento 1:1 no
qual ambas as entidades possuem participação opcional (cardinalidades (0,1): (0,1)):
Fonte: AutorFigura: DER contendo relacionamento 1:1 – ambas as entidades com participação opcional.

A figura a seguir exibe o modelo lógico gerado:
Fonte: AutorFigura:
Tabelas criadas com base
no mapeamento
conceitual-lógico
envolvendo relacionamento 1:1 - ambas as entidades com participação opcional.
Para esse tipo de relacionamento, o mais adequado é priorizar adição de coluna(s), o que ocorreu ao criarmos a coluna
CODIGONOTEBOOK como chave estrangeira na tabela FUNCIONARIO. Vale lembrar que estamos diante de uma coluna
opcional.
A seguir, a representação textual do modelo:
A figura a seguir apresenta um DER contendo um relacionamento 1:1 no qual há uma entidade com participação
obrigatória e a outra opcional (cardinalidades (0,1): (1,1)):
Fonte: AutorFigura DER contendo relacionamento 1:1 – uma entidade com participação obrigatória e a outra opcional.
Figura: Tabela criada com base no mapeamento conceitual-lógico

envolvendo relacionamento 1:1 - uma entidade com
participação obrigatória e a outra opcional.
 Atenção! Para visualização completa da tabela utilize a rolagem
horizontal
Para esse tipo de relacionamento, o mais adequado é priorizar fusão de
tabelas, o que ocorreu ao criarmos as colunas CODIGONOTEBOOK e DESCRICAO na tabela FUNCIONARIO, ambas
opcionais.
Após a aplicação das regras de mapeamento, foi gerada a representação textual a seguir:
A figura a seguir apresenta um DER parcial contendo um relacionamento 1:1 e ambas as entidades com participação
obrigatória (cardinalidades (1,1): (1,1)):
Fonte: AutorFigura: DER parcial contendo relacionamento 1:1 – ambas as entidades com participação obrigatória.
Figura: Tabelas criadas com base no mapeamento conceitual-lógico

envolvendo relacionamento 1:1 – ambas as entidades com participação
obrigatória.
 Atenção! Para visualização completa da tabela utilize a rolagem
horizontal
Para esse tipo de relacionamento, o mais adequado é priorizar fusão de
tabelas, o que ocorreu ao criarmos as colunas CODIGONOTEBOOK e DESCRICAO na tabela FUNCIONARIO, ambas
obrigatórias.
Após a aplicação das regras de mapeamento,
foi gerada a representação textual a seguir:
EXEMPLO DE MAPEAMENTO DE RELACIONAMENTO 1:N:

Conhecidas as regras para o mapeamento de relacionamentos 1:N, observe no exemplo a seguir um diagrama de
entidade e relacionamento (DER) contendo duas entidades: NIVEL e CURSO.
A figura a seguir mostra um DER parcial contendo um relacionamento 1:N:
Fonte: AutorFigura: DER contendo relacionamento 1:N.

Fonte:
AutorFigura:
Tabelas criadas
com base no
mapeamento
conceitual-lógico envolvendo relacionamento 1:N.
Para esse tipo de relacionamento, foi utilizada adição de coluna(s) na tabela do lado N, o que ocorreu ao criarmos a
chave estrangeira CODIGONIVEL na tabela CURSO.
EXEMPLO DE MAPEAMENTO DE RELACIONAMENTO

N:N:
Conhecidas as regras para o mapeamento de
relacionamentos N:N, observe no exemplo a seguir
um diagrama de entidade e relacionamento (DER)
contendo duas entidades: CURSO e DISCIPLINA.
A figura a seguir mostra um DER parcial contendo um relacionamento N:N:
Fonte: AutorFigura: DER parcial contendo relacionamento N:N.

Fig
ura: Tabelas criadas com base no mapeamento conceitual-lógico envolvendo relacionamento N:N
Para esse tipo de relacionamento, foi utilizada tabela própria, o que ocorreu ao criarmos CURSODISCIPLINA, contendo
duas chaves estrangeiras: CODIGOCURSO e CODIGODISCIPLINA. Ao mesmo tempo, a combinação das duas colunas
forma a chave primária composta da tabela.
Após a aplicação das regras de mapeamento, foi
gerada a representação textual a seguir:
OBSERVAÇÃO SOBRE ENTIDADE ASSOCIATIVA

O mapeamento de entidade associativa, isto é,
relacionamento com atributos, segue as regras
utilizadas no mapeamento de relacionamentos N:N.
OBSERVAÇÃO SOBRE AUTORRELACIONAMENTO
O mapeamento de autorrelacionamento segue as
regras utilizadas no mapeamento de
relacionamentos. Basta, então, você ficar atento ao
tipo de cardinalidade máxima em questão.
EXEMPLO DE MAPEAMENTO DE RELACIONAMENTO TERNÁRIO:
Conhecidas as regras para o mapeamento de relacionamentos, ao nos depararmos com relacionamentos ternários,
precisaremos avaliar as cardinalidades máximas em questão. Observe no exemplo a seguir um diagrama de entidade e
relacionamento (DER) contendo um relacionamento ternário entre as entidades PROJETO, DOCENTE e ALUNO.
A figura a seguir mostra um DER parcial contendo um relacionamento ternário.
Fonte: AutorFigura DER parcial contendo relacionamento ternário.
Figura: Tabelas criadas com
base no mapeamento
conceitual-lógico envolvendo
relacionamento ternário.
Para esse tipo de
relacionamento, foi utilizada
tabela própria, o que ocorreu
ao criarmos ORIENTACAO,
contendo três chaves
estrangeiras:
CODIGOFUNCIONARIO,
CODIGOALUNO e
CODIGOPROJETO. Além disso, foram criadas as colunas DATAINICIO e DATAFIM, as quais representam informações
importantes sob o contexto de um registro de orientação.
Após a aplicação das regras de
mapeamento, foi gerada a representação
textual a seguir:
MAPEAMENTO DE ATRIBUTOS
MULTIVALORADOS
O mapeamento de atributos multivalorados
envolve:
Criar uma tabela T para cada atributo
multivalorado.
Criar coluna(s) para o(s) atributo(s) multivalorado(s).
A tabela T possuirá chave estrangeira originada da chave primária da tabela original.
A tabela T possuirá chave primária composta pela chave estrangeira criada no passo anterior e pela(s) coluna(s)
referente(s) ao(s) atributo multivalorado(s).
A figura a seguir mostra um DER parcial contendo atributo multivalorado.
Fonte: AutorFigura DER parcial contendo atributo multivalorado.

Fonte: AutorFigura: Tabelas

criadas com base no
mapeamento conceitual-
lógico envolvendo
atributo multivalorado.
Note que para mapear o atributo multivalorado TELEFONE, foi criada tabela própria denominada FONEALUNO. A coluna
CODIGOALUNO de FONEALUNO é chave estrangeira. Além disso, as colunas CODIGOALUNO, NUMERO, TIPO
representam uma chave primária composta. A coluna TIPO, criada na tabela FONEALUNO, representa a categoria do
telefone, por exemplo, residencial, comercial ou móvel.
MAPEAMENTO DE ESPECIALIZAÇÃO/GENERALIZAÇÃO
O mapeamento de especialização/generalização envolve:
SOLUÇÃO I
Tabela única.
Criar uma tabela única que contenha todos os atributos das entidades genérica e
especializadas.
Criar uma coluna TIPO, caso não exista, para identificar a entidade especializada.
SOLUÇÃO II
Uma tabela para cada entidade (genérica ou especializada) que compõe a hierarquia.
Criar uma tabela para a entidade genérica, com coluna(s) referente(s) ao(s) atributo(s) da entidade genérica.
Criar uma tabela para cada entidade especializada, com coluna(s) referentes ao(s) atributo(s) da entidade especializada.
Cada tabela de entidade especializada possuirá chave estrangeira originada da chave primária da tabela da entidade
genérica. Esta também será a sua chave primária.
SOLUÇÃO III
Subdivisão da entidade genérica.
Nesta implementação, não será criada tabela para a entidade genérica.
Criar uma tabela para cada entidade especializada, com coluna(s) referentes ao(s) atributo(s) da entidade especializada.
Em cada tabela, criar colunas referentes aos atributos da entidade genérica, sendo sua chave primária originada do
atributo identificador da entidade genérica.
Caso a hierarquia seja parcial, será necessário criar uma tabela adicional para abarcar as entidades genéricas que não
estão nas entidades especializadas. Essa tabela conterá somente os atributos da entidade genérica.
Importante notar que esta solução pode gerar redundância de dados, no caso de hierarquia sobreposta, requerendo um
tratamento adicional para controle de redundância.
EXEMPLOS DE MAPEAMENTO DE ESPECIALIZAÇÃO/GENERALIZAÇÃO:
Conhecidas as regras para o mapeamento de especialização/generalização, observe no exemplo a seguir um diagrama
de entidade e relacionamento (DER) com esse mecanismo:
Fonte: AutorFigura: DER contendo especialização/generalização.

A figura a seguir exibe o modelo lógico gerado após a aplicação da solução I expressa nas regras de mapeamento:
Figura: Tabela criada com base no mapeamento conceitual-

lógico envolvendo especialização/generalização – solução
I.l
No exemplo, foi criada tabela única (FUNCIONARIO)
contendo colunas referentes à entidade genérica, além da coluna TIPO, para identificar a categoria de cada colaborador.
A figura a seguir exibe o modelo lógico gerado após a aplicação da solução II das regras de mapeamento:
Figura: Tabelas criadas com base no mapeamento conceitual-lógico envolvendo especialização/generalização – solução
II.
No exemplo, foram criadas três tabelas: uma (FUNCIONARIO) referente à entidade genérica. As restantes, DOCENTE e
ANALISTA, referentes às entidades especializadas em questão. Cada CODIGOFUNCIONARIO presente nas tabelas
DOCENTE e ANALISTA exerce o papel de chave estrangeira.
A figura a seguir exibe o modelo lógico gerado após a aplicação da solução III das regras de mapeamento:
Fig
ura: Tabelas criadas com base no mapeamento conceitual-lógico envolvendo especialização/generalização – solução III.
No exemplo, foram criadas três tabelas, sendo OUTROSFUNCIONARIOS onde devem ser mantidos funcionários que não
sejam docentes nem analistas. As restantes, DOCENTE e ANALISTA, são referentes às entidades especializadas em
questão.
Após a aplicação das regras de mapeamento, foi gerada a
representação textual a seguir:
Convém ressaltar que a tabela OUTROSFUNCIONARIOS seria necessária somente se o mecanismo de

generalização/especialização fosse parcial, ou seja, se houvesse algum colaborador não enquadrado nas categorias
docente ou analista.
ATENÇÃO
Como dica prática, devemos ter cuidado especial caso seja escolhida a solução III. Ao incluir um novo funcionário, será
necessário verificar todas as tabelas criadas para as especializações para garantir a unicidade da chave primária. No
exemplo, é preciso verificar os valores de chave primária nas tabelas DOCENTE, ANALISTA e OUTROSFUNCIONARIOS.
Por fim, convém ressaltar que a solução II é a mais usual, por ser mais flexível, dada a facilidade existente em
contemplar novas especializações. Além disso, a solução I tende a gerar diversas ocorrências de valores nulos em
colunas. Ao mesmo tempo, a solução III apresenta maior possibilidade de gerar redundância de dados.
ESTUDO DE CASO
Para praticar as principais regras de mapeamento estudadas, vamos realizar um estudo de caso. Tendo como base os
requisitos a seguir, foi construído o diagrama de entidade e relacionamento (DER) da figura abaixo. A partir desse DER,
realize o mapeamento conceitual-lógico, sob a forma de descrição textual.
Deseja-se informatizar os processos de empréstimo e devolução de livros de uma biblioteca da rede pública municipal:
Modelo de entidade e relacionamento

resultante do projeto conceitual:
Fonte: AutorFigura: Modelo de entidade

e relacionamento referente ao estudo de
caso.
ESTUDO DE CASO
Assista, agora, ao desenvolvimento e
conclusão do estudo de caso:
1. CONSIDERE UM RELACIONAMENTO
ENTRE TURMA E DISCIPLINA (N:N)
DENOMINADO OFERTA. PARA CADA DISCIPLINA OFERTADA POR UMA TURMA É NECESSÁRIO SABER O NÚMERO DE
VAGAS. QUAL ALTERNATIVA A SEGUIR REPRESENTA CORRETAMENTE O MODELO LÓGICO DERIVADO DO MODELO
CONCEITUAL?
Somente uma tabela para todo o modelo.
Duas tabelas, uma para TURMA e outra para DISCIPLINA.
Três tabelas: uma para TURMA, uma para DISCIPLINA e uma para OFERTA. Além disso, o atributo que representa o
número de vagas deve estar modelado na tabela OFERTA.
Três tabelas: uma para TURMA, uma para DISCIPLINA e uma para OFERTA.
Além disso, o atributo que representa o número de vagas deve estar modelado na tabela DISCIPLINA.
2. CONSIDERE O PROJETO CONCEITUAL PARCIAL A SEGUIR:
PARA CONSTRUIR O PROJETO LÓGICO A PARTIR DO DER, É CORRETO AFIRMAR QUE SERÃO CRIADAS:
Duas tabelas.
Três tabelas.
Quatro tabelas.
Cinco tabelas.
GABARITO
1. Considere um relacionamento entre TURMA e DISCIPLINA (N:N) denominado OFERTA. Para cada disciplina ofertada
por uma turma é necessário saber o número de vagas. Qual alternativa a seguir representa corretamente o modelo
lógico derivado do modelo conceitual?
Diante da cardinalidade máxima N:N, a solução é criar três tabelas: duas para as entidades participantes e uma para o
relacionamento. O atributo que representa o número de vagas, pelo fato de fazer parte do relacionamento, deve ser
modelado na tabela OFERTA.
2. Considere o projeto conceitual parcial a seguir:
Fonte: Autor
Para construir o projeto lógico a partir do DER, é correto afirmar que serão criadas:
No mapeamento lógico-conceitual, cada entidade vira tabela. O mesmo ocorrerá no LA, por ter cardinalidade máxima
N:N. O relacionamento EL, por ter cardinalidade máxima 1:N será implementado na tabela LIVRO.
MÓDULO 4
Identificar os aspectos físicos para implementação do modelo no SGBD
CONSULTAS
A partir de agora, conheceremos diretrizes que devem ser consideradas quando formos implementar um banco de
dados relacional. As diretrizes abrangem aspectos que influenciam no desempenho do banco de dados. Assim, o projeto
lógico pode sofrer ajustes para adaptar-se ao sistema gerenciador de banco de dados (SGBD) escolhido para a
implementação.
Planejar um banco de dados que tenha um bom desempenho pressupõe adquirir conhecimento sobre as consultas e
transações que serão realizadas pela aplicação.
Um SGBD tipicamente processa e devolve dados requisitados em consultas para diversas finalidades, tais como
recuperação, inclusão, exclusão ou mesmo atualização de dados. As consultas são implementadas com o auxílio da
linguagem SQL (do Inglês, Structured Query Language – linguagem de consulta estruturada).
DICA
Um código típico de consulta para recuperar dados em SQL envolve o comando SELECT com as
cláusulas FROM e WHERE.
Por exemplo, dada a tabela DOCENTE (CODIGODOCENTE, NOME, SEXO), o código a seguir recupera os registros de todas
as professoras:
A primeira linha do comando informa ao SGBD as colunas que devem ser exibidas após
o processamento da consulta. Na segunda, especificamos o nome da tabela que contém
os dados. Finalmente, na terceira linha, adicionamos uma condição de filtro que será
processada pelo SGBD para recuperar as linhas de interesse.
TRANSAÇÕES
Diversos SGBDs modernos permitem a especificação de operações de transação.
Uma transação corresponde a uma série de operações que, quando submetidas ao SGBD, devem ser consideradas como
uma unidade lógica de trabalho. Isso significa que todas as operações que compõem uma transação precisam ser
executadas. Caso contrário, é necessário serem canceladas e nenhuma modificação ocorrerá no banco de dados.
Por exemplo, em um processo de inscrição em disciplinas, em geral, o aluno tem a liberdade para compor seu quadro de
horário de disciplinas, para, em seguida, confirmar inscrição em diversas matérias. Assim, a inscrição em disciplinas deve
ser considerada como um único processo ou transação. Trata-se de um procedimento atômico: ou todas as operações
são confirmadas ou nenhuma delas é realizada.
INDEXAÇÃO EM BANCO DE DADOS
O desempenho de consultas é um assunto vasto que faz uso de diversas estratégias de acesso a dados, semelhantes às
utilizadas em nosso dia a dia.
Por exemplo, ao buscarmos por determinada informação em algum livro, para ganharmos tempo, é comum primeiro
consultar o índice remissivo do livro, que indicará a página onde se localiza o termo buscado.
ATENÇÃO
Em banco de dados, índices funcionam como estruturas auxiliares utilizadas para tornar mais eficiente a recuperação de
registros em resposta a determinadas condições de busca.
Normalmente, ao projetamos uma tabela com chave primária, os registros de dados são gravados em disco sem
nenhum critério de ordenação das linhas da tabela. Para facilitar a consulta pelo valor da chave primária, o SGBD cria
uma estrutura de índice para a chave primária de cada tabela.
A estrutura de índice poderá ser utilizada pelo SGBD caso seja necessário realizar consulta que envolva, por exemplo,
uma condição de igualdade na coluna de chave primária da tabela. Quando isso ocorre, o desempenho da consulta em
geral é melhor do que caso não existisse a estrutura de índice.
EXEMPLO PRÁTICO ENVOLVENDO INDEXAÇÃO:
Visando ressaltar a importância dos índices, realizamos um pequeno experimento, que consiste em submeter duas
consultas ao SGBD, uma sem índice, e a segunda com uma coluna indexada.
Vamos perceber que, quando o SGBD processa uma consulta com o auxílio de um índice, o tempo de resposta tende a
ser mais otimizado se comparado à execução da mesma consulta sem esse recurso.
Suponha então a existência de uma tabela DM_DOCENTE (CO_IES, NO_IES, CO_DOCENTE_IES,
CO_MUNICIPIO_NASCIMENTO) - apresentada aqui com quatro colunas para fins de exemplo – originalmente, extraída
do Censo da Educação Superior Brasileira de 2016.
A tabela contém 367.980 registros. Cada registro corresponde a um docente vinculado a uma instituição de ensino
superior (IES). Ainda, originalmente, os registros de DM_DOCENTE estão fisicamente ordenados pela coluna CO_IES e a
tabela não possui chave primária definida.
Nosso objetivo é recuperar todas as colunas da tabela, referentes ao docente que possui o valor 850516 para a coluna
CO_DOCENTE_IES.
O comando SQL executado na consulta I a seguir, serve para esse propósito:
Essa consulta demorou 2,5 segundos para ser executada.

Agora, criaremos uma tabela chamada DM_DOCENTE_2, contendo os mesmos
registros de DM_DOCENTE, no entanto com os registros ordenados pela coluna
CO_DOCENTE_IES, conforme código SQL a seguir:
Adicionaremos chave primária à tabela DM_DOCENTE_2, escolhendo a

coluna CO_DOCENTE_IES, conforme código SQL a seguir:
Essa consulta demorou 0,06 segundos para ser executada.
O resultado do processamento das consultas é igual, uma vez que temos os mesmos registros em ambas as tabelas.
Contudo, a consulta 2 foi processada com mais eficiência.
Após breve contextualização envolvendo consulta, transação e indexação, passaremos a estudar os fatores que
influenciam no projeto de bancos de dados relacionais.
EXEMPLO PRÁTICO (INDEXAÇÃO)
Confira o vídeo mostrando a melhoria no desempenho de uma consulta em um banco de dados com indexação:
PROJETO FÍSICO EM BANCOS DE DADOS RELACIONAIS
Projetar um banco de dados é um processo que envolve as seguintes etapas:
Levantamento de requisitos
Projeto conceitual
Projeto lógico
Projeto físico
Projetar fisicamente um banco de dados é o mesmo que “colocar a mão na massa”, ou seja, acessar recursos do sistema
gerenciador de banco de dados (SGBD) para atividades de criação da estrutura física do banco, que, na maioria das
vezes, ocorre com o auxílio de alguma ferramenta CASE capaz de gerar códigos na linguagem SQL para criar as tabelas,
relacionamentos e demais componentes do banco de dados.
É comum que haja mais de uma alternativa para implementar um banco de dados tomando como base o esquema
conceitual. Ainda, o projeto físico de banco de dados é comumente influenciado pelos seguintes fatores:
CONSULTAS E TRANSAÇÕES DE BANCO DE DADOS
É necessário planejar as consultas e transações que deverão ocorrer no banco de dados. De um modo geral, para cada
consulta de recuperação de dados, é necessário conhecer:
As tabelas acessadas pela consulta;
As colunas que serão utilizadas em condições de seleção;
A natureza da condição de seleção: intervalo, igualdade ou desigualdade;
Colunas utilizadas na composição de operações de junção;
Colunas cujos valores aparecerão nos resultados da consulta.
Em se tratando de tabelas de um banco de dados, é comum criarmos índices para determinadas colunas. Em especial,
colunas relacionadas aos itens 2 e 4 são boas candidatas para serem indexadas.
Fonte: AutorFigura: Tabelas NIVEL e CURSO.
O SGBD precisa avaliar se há algum registro na tabela CURSO cujo

conteúdo da coluna NOME seja “Medicina” ou “Nutrição.” Trata-se de
uma consulta enquadrada no item 2: há uma condição de seleção na
cláusula WHERE envolvendo a coluna NOME: uma boa candidata para criação de índice.
Veja a consulta II a seguir, que objetiva
recuperar o nome do curso e o nível ao qual ele
pertence:
A consulta usa um comando de junção (JOIN). A
condição(CURSO.CODIGONIVEL=NIVEL.CODIGONIVEL) será avaliada diversas vezes ao longo do processamento da
consulta. Trata-se de uma consulta enquadrada no item 4: as colunas CODIGONIVEL presentes na tabela são boas
candidatas para criação de índices.
No caso de operações de atualização de dados, é necessário conhecer:
As tabelas alvo da atualização;
A categoria da atualização em cada tabela: exclusão, atualização ou inserção;
Colunas utilizadas em condições de seleção para exclusão ou atualização;
Colunas alvo das operações de atualização.
Ainda no contexto de indexação, colunas relacionadas ao item 3 são boas candidatas para serem indexadas. Ao mesmo
tempo, o ideal é não criar índices para as colunas relacionadas ao item 4. Vamos estudar um exemplo?
Veja a consulta III a seguir, que objetiva excluir todos os cursos que tenham a string “Engenharia”.
O SGBD precisa localizar os registros para então apagá-los do banco de dados. Para tanto, executará a condição de
seleção presente no WHERE. Trata-se de uma consulta enquadrada no item 3: a coluna NOME presente na tabela é boa
candidata para criação de índice.
FREQUÊNCIA DE CHAMADA DE CONSULTAS E TRANSAÇÕES ESPERADA
Vimos a importância de identificar detalhes sobre as consultas de recuperação e transações de atualização esperadas.
No entanto, saber a respeito da frequência de uso esperada para operações de consulta e transações também é uma
boa estratégia para obter desempenho.
ATENÇÃO
Aplicando-se a “regra do 80/20”, conhecida como Princípio de Pareto, em um sistema de banco de dados, estima-se que
80% do processamento é originado de somente 20% das consultas e transações. Por isso, é rara a necessidade de
coletar informações estatísticas completas e taxas de chamada para todas as consultas e transações, bastando priorizar
20% das mais relevantes.
PRINCÍPIO DE PARETO
O princípio de Pareto (também conhecido como regra do 80/20) afirma que, para muitos eventos, aproximadamente
80% dos efeitos vêm de 20% das causas.
RESTRIÇÕES DE TEMPO DE CONSULTA E TRANSAÇÕES
Dependendo da natureza da aplicação, podem existir consultas e transações com restrições de desempenho bastante
rigorosas. Para exemplificar, poderia existir a restrição de que uma transação de compras tenha que terminar o seu
processamento de pagamento dentro de sete segundos em 90% das vezes em que é chamada, e que ela nunca deve
ultrapassar quinze segundos.
Essas restrições referentes ao tempo têm forte impacto nas colunas candidatas a serem indexadas. Em especial, tais
colunas devem ser priorizadas quando da decisão da criação de índices para as tabelas.
FREQUÊNCIAS ESPERADAS DE OPERAÇÕES DE ATUALIZAÇÃO
Se a tabela é atualizada com frequência, deve-se evitar a criação de índices nas colunas, pois a atualização de colunas
indexadas, frequentemente, requer atualização na estrutura de índice.
EXEMPLO
Por exemplo, se uma tabela possui cinco colunas indexadas, a inserção de um novo registro requer a atualização dos
índices, o que pode causar lentidão nesse tipo de operação.
RESTRIÇÕES DE EXCLUSIVIDADE EM COLUNAS DA TABELA
É útil criar índice para cada coluna com restrição de unicidade na tabela. Em uma operação típica de inserção, o SGBD
pode validar essa restrição de exclusividade fazendo consulta à estrutura de índice, rejeitando a inserção caso o valor da
coluna seja encontrado no índice.
CONSULTAS ENVOLVENDO MAIS DE UMA TABELA
Você perceberá que, em geral, a maior parte das consultas para recuperar informações de um banco de dados envolve
diversas tabelas. Isso ocorre, principalmente, quando o projeto leva em conta as regras de normalização.
Considere a estrutura de duas tabelas relacionadas, conforme a seguir:
A relação entre as tabelas está

representada pela coluna de chave
estrangeira
CO_MUNICIPIO_NASCIMENTO da tabela DM_DOCENTE_2, a qual faz referência para a coluna chave primária
CO_MUNICIPIO da tabela MUNICIPIO.
Nosso objetivo é recuperar o código do docente e nome do município de nascimento dele.
Perceba que as colunas alvo do resultado estão presentes em tabelas distintas: NOME, na tabela MUNICIPIO e
CO_DOCENTE_IES, na tabela DM_DOCENTE_2.
O código em SQL que recupera os dados de
interesse está expresso a seguir:
A primeira linha do comando serve para

declararmos as colunas que farão parte do
resultado da consulta. Na segunda, informamos as tabelas de interesse. Finalmente, na última linha, há uma condição
de filtro, envolvendo uma igualdade entre a chave primária da tabela MUNICIPIO e a chave estrangeira da tabela
DM_DOCENTE_2.
Para processar a consulta anterior, o SGBD cria uma estrutura de tabela temporária que contém a combinação de cada
linha da tabela DM_DOCENTE_2 com cada linha da tabela MUNICIPIO. Se considerarmos os 367.980 registros de
DM_DOCENTE_2 e os 5.570 registros da tabela MUNICIPIO, a tabela temporária teria mais de dois bilhões de linhas
(367.980*5.570). Finalmente, a partir da tabela temporária, o SGBD executa o filtro especificado no comando WHERE
para então exibir as colunas listadas no comando SELECT. O processo anterior é bastante custoso para o SGBD, ainda
que cada sistema internamente use técnicas para otimizar o processamento.
ATENÇÃO
Note que, se esse tipo de consulta for frequente, haverá grande probabilidade de lentidão no sistema.
A seguir, apresentaremos uma alternativa para minimizar esse custo, no entanto tendo como consequência a
introdução de algum nível de redundância nos dados.
DESNORMALIZAR PARA GANHAR DESEMPENHO
Quando um esquema de banco de dados está normalizado até a 3FN, os problemas com redundância de dados são
minimizados, pois, em geral, existe uma tabela para cada objeto modelado.
Ao mesmo tempo, vimos que processar a consulta anterior requer acesso às duas tabelas para recuperar as informações
- o que gera um custo adicional de processamento.
Logo, se quisermos priorizar desempenho, teremos que sacrificar as vantagens de um modelo normalizado. Esse
processo é conhecido por desnormalização.
Nossa intenção a partir de agora é gerar uma estrutura que permita obter os mesmos resultados da consulta anterior,
no entanto, usando somente uma tabela. Esse tipo de situação é comum quando temos a necessidade de produzir
relatórios em um sistema.
Ao desnormalizar o modelo, ficamos com a seguinte tabela: DM_DOCENTE_2 (CO_DOCENTE_IES, CO_IES, NO_IES,
CO_MUNICIPIO_NASCIMENTO, NOME). Note que a coluna NOME é dependente da coluna
CO_MUNICIPIO_NASCIMENTO, ou seja, precisamos ter em mente que estamos diante de uma dependência funcional
parcial, violando a 2FN.
Diante da nova estrutura, o código a seguir recupera as informações, agora envolvendo somente uma tabela:
ATENÇÃO:O processo de desnormalização deve ser planejado com critério, visto

que, ao mesmo tempo em que há potencial de ganho em relação ao
desempenho de determinadas consultas, a desnormalização introduz redundância nos dados e, ao mesmo tempo, é
necessária atualização adicional visando manter a consistência das colunas redundantes.
Ao longo deste módulo, percebemos que a criação do modelo físico em um SGBD está atrelada ao objetivo de criar um
banco de dados de maneira que problemas de baixo desempenho sejam evitados. Para isso, é necessário mapear as
principais consultas e transações a serem processadas ao longo do ciclo de vida do banco de dados.
1. ACERCA DO PROCESSO DE DESNORMALIZAÇÃO, ASSINALE A PROPOSIÇÃO VERDADEIRA.
Ao desnormalizar um modelo da 3FN para a 2FN, introduz-se redundância de dados, tendo vantagem a diminuição do
desempenho no acesso aos dados.
A desnormalização nunca introduz redundância de dados.
Ao desnormalizar um modelo da 3FN para a 2FN, introduz-se redundância de dados, tendo vantagem aumento do
desempenho no acesso aos dados.
Ao desnormalizar um esquema de banco de dados, o número de tabelas do modelo é triplicado.
2. OS ÍNDICES SÃO USADOS EM BANCOS DE DADOS COM A MESMA FINALIDADE DOS ÍNDICES DE LIVROS, ISTO É, PARA
ACELERAR A CONSULTA A DETERMINADOS DADOS. COMO SE TRATAM DE ESTRUTURAS AUXILIARES QUE OCUPAM
ESPAÇO E GERAM REDUNDÂNCIA DE DADOS, É PRECISO CRITÉRIO NA ESCOLHA DOS DADOS A SEREM INDEXADOS.
QUAL DAS ALTERNATIVAS ABAIXO MENCIONA ELEMENTOS DE UM BANCO DE DADOS QUE SÃO CANDIDATOS A SEREM
INDEXADOS?
Colunas mais usadas em condições de seleção.
Tabelas mais acessadas por consultas.
Linhas mais selecionadas em consultas.
Células que aparecem mais vezes em resultados de consulta.
GABARITO
1. Acerca do processo de desnormalização, assinale a proposição verdadeira.
De fato, quando aplicamos a desnormalização em um banco de dados, o conteúdo de uma ou mais tabelas é movido
para outra tabela. Com isso, certa redundância é inserida no sistema. Por outro lado, consultas que, anteriormente,
envolviam diversas tabelas, em geral passam a ser executadas diretamente na tabela desnormalizada
2. Os índices são usados em bancos de dados com a mesma finalidade dos índices de livros, isto é, para acelerar a
consulta a determinados dados. Como se tratam de estruturas auxiliares que ocupam espaço e geram redundância de
dados, é preciso critério na escolha dos dados a serem indexados.
Qual das alternativas abaixo menciona elementos de um banco de dados que são candidatos a serem indexados?
Para acelerar o processamento de consultas ao banco de dados, uma das técnicas mais usadas é criar índices para as
colunas de tabelas que mais aparecem nas cláusulas WHERE dos comandos de consulta SELECT.
CONCLUSÃO
Este tema iniciou com o estudo dos componentes do modelo relacional de banco de dados. Além das tabelas e seus
componentes, foram apresentadas as definições de chave primária e de chave estrangeira como elementos importantes
na implementação de relacionamentos.
Investigamos as três primeiras formas normais, como modos de construir modelos livres das redundâncias que
aparecem em algumas dependências funcionais. Depois, analisamos uma série de regras usadas para o mapeamento do
modelo conceitual para o modelo lógico.
Finalmente, investigamos diretrizes que devem ser levadas em consideração quando da implementação do modelo
físico em um SGBD.
Criação e manipulação de objetos no PostgreSQL
DEFINIÇÃO
Instalação do PostgreSQL. Tipos de dados. Criação de tabelas. Manipulação de linhas. Controle de transação.
PROPÓSITO
Compreender a instalação do PostgreSQL é importante para conhecer um ambiente computacional típico de banco de
dados em ambientes corporativos. Entender sobre tipos de dados é a base para escolhas compatíveis com a natureza
dos dados a serem armazenados. Para desenvolver sistemas com uso de banco de dados, é necessário conhecer os
comandos para manipulação de linhas nas tabelas, além de identificar como eles são controlados a partir do conceito de
transação.
PREPARAÇÃO
Antes de iniciar o conteúdo deste tema, certifique-se de ter baixado o SGBD PostgreSQL em seu computador.
OBJETIVOS
MÓDULO 1Compreender o processo de instalação do PostgreSQL
MÓDULO 2Empregar comandos para criação e alteração de tabelas
MÓDULO 3Empregar comandos para manipular linhas nas tabelas
MÓDULO 4Empregar comandos de controle de transação
INTRODUÇÃO
Ao longo deste tema, vamos analisar as características básicas do sistema gerenciador de banco de dados (SGBD)
PostgreSQL, envolvendo as etapas utilizadas para instalar esse SGBD no Linux e no Windows.
O PostgreSQL é um SGBD de código aberto desenvolvido em linguagem C e está disponível para ser utilizado em
diversos ambientes de sistemas operacionais, tais como Linux, Unix, Windows, OS X, Solaris, entre outros.
Vamos explorar vários recursos da linguagem SQL, com foco na aprendizagem de comandos classificados como DDL.
Aprenderemos também comandos CRUD, sigla em inglês que faz referência a quatro operações básicas: criação,
consulta, atualização e remoção de dados, respectivamente.
Por fim, vamos entender que, internamente, o SGBD trata de diversas operações de maneira atômica, ou seja, um
conjunto de comandos deve ser executado como uma unidade lógica de trabalho, ou nenhuma operação deve ser
realizada. Trata-se do conceito de transação. Aprenderemos, então, os principais comandos que gerenciam transações.
Clique aqui para baixar o arquivo com todos os códigos que serão utilizados nas consultas dos módulos deste tema.
DDL :Data Definition Language, ou Linguagem de Definição de Dados.
CRUD :Create – Read – Update – Delete.
MÓDULO 1
Compreender o processo de instalação do PostgreSQL
BREVE HISTÓRICO
O PostgreSQL surgiu a partir de um projeto denominado POSTGRES, assim denominado por ser originário do projeto
INGRES (Post INGRES), de responsabilidade da Universidade da Califórnia em Berkeley.
A implementação do POSTGRES foi iniciada em 1986, tornando-se operacional em 1987. Sua primeira versão foi lançada
ao público externo em 1989. Nos dois anos seguintes, foram lançadas a segunda e terceira versões.
Em 1995, foi disponibilizado o Postgres95, com revisão no código do projeto e a adoção da linguagem SQL como
interface padrão.
Em 1996, o produto foi renomeado para PostreSQL, começando pela versão 6, considerado continuidade do Postgres95,
a versão 5. O projeto ganhou visibilidade e, atualmente, o PostgreSQL é conhecido como um dos principais SGBDs de
código aberto, com versões para Windows, Mac OS e Linux.
SQL
Structured Query Language, ou Linguagem de Consulta Estruturada.
ARQUITETURA DO POSTGRESQL
Antes de instalarmos o PostgreSQL, é importante entendermos sua arquitetura básica. O PostreSQL utiliza o modelo
cliente-servidor. Sob esse contexto, destacamos os seguintes processos que cooperam entre si:
Processo servidor, responsável por funções, tais como:
Gerenciar os arquivos do banco de dados

Gerenciar as conexões entre os aplicativos e o SGBD
Avaliar e executar no banco de dados os comandos submetidos pelos clientes
Aplicativo cliente do usuário, responsável por funções, tais como:
Solicitar acesso ao SGBD

Enviar comandos para manipulação de linhas em tabelas. A manipulação pode envolver, por exemplo, inserção, alteração ou
Enviar comandos para consulta em uma ou diversas tabelas, com objetivo de recuperar informações do banco de dados

Em um ambiente cliente-servidor, tanto o cliente quanto o servidor podem estar localizados em máquinas diferentes,
em uma rede local ou mesmo geograficamente distantes.
Em geral, a comunicação entre cliente e servidor ocorre por meio de uma conexão de rede utilizando o
protocolo TCP/IP. Esse protocolo tem por objetivo a padronização das comunicações em rede, em especial as
comunicações na Web.
TCP/IP
O TCP/IP é um conjunto de protocolos de comunicação entre computadores em rede. Seu nome faz referência a dois
protocolos: Transmission Control Protocol / Internet Protocol.
Fonte: Wikipedia
O PostgreSQL suporta várias conexões simultâneas de clientes. Para isso, um processo para cada conexão é iniciado. Em
seguida, o cliente e o novo processo realizam comunicação.
Como instalar o PostgreSQL em seu computador?
RESPOSTA
Recomendamos que você acompanhe as versões do PostgreSQL na página oficial do produto para escolher uma versão
de acordo com seu sistema operacional e que lhe interesse.
INSTALAÇÃO DO POSTGRESQL NO LINUX
Para instalação em Linux com código fonte, você pode executar os passos a seguir:
FAZER DOWNLOAD DO ARQUIVO .TAR.GZ
Se considerarmos o Ubuntu, o download pode ser realizado a partir do site do PostgreSQL, na seção relativa a esse
sistema operacional. Usaremos o qualificador “--" para comentários a respeito dos comandos.
OBTER O CÓDIGO FONTE
No prompt do Linux, executar os dois comandos a seguir:
gunzip postgresql-12.3.tar.gz
-- descompacta o arquivo .gz gerando o arquivo .tar
tar xf postgresql-12.3.tar
-- abre o arquivo .tar criando o diretório postgresql-12.3
ACESSAR O DIRETÓRIO CRIADO PELO TAR
Após a conclusão da etapa anterior, deve-se executar o comando a seguir para ter acesso ao diretório criado pelo tar:
cd postgresql-12.3
-- cd (change directory)
REALIZAR O PROCESSO DE INSTALAÇÃO
Após a conclusão da etapa anterior, é preciso executar os comandos a seguir para realizar o processo de instalação do
PostgreSQL:
./configure
-- script para configurar a árvore de diretórios (cria o diretório /usr/local/psql)
gmake
-- GNU make: inicializa o build, pode levar de 5 a 30 minutos e termina com a mensagem:
– All of PostgreSQL is successfully made. Ready to install.
su
-- muda login de usuário para o superusuário root (pede a senha do root)
gmake install
-- realiza a instalação como root
CHECAR A INSTALAÇÃO
Após a conclusão da etapa anterior, deve-se executar os comandos a seguir para checar instalação do PostgreSQL:
adduser postgres
-- cria usuário postgres, superusuário do PostgreSQL (seuseradd no Fedora)
mkdir /usr/local/pgsql/data
-- cria o diretório data onde ficarão as bases de dados
chown postgres /usr/local/pgsql/data
-- muda o dono do diretório data para postgres
su - postgres
-- muda login de usuário para postgres
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
-- cria um grupo de BD no diretório data
/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data >logfile 2>&1 &
-- inicializa o servidor em segundo plano
/usr/local/pgsql/bin/createdb test
-- cria um database test
/usr/local/pgsql/bin/psql test
-- inicia uma sessão no PostgreSQL, usando a interface de linha de comandos psql, como usuário postgres no database
test
INSTALAÇÃO DO POSTGRESQL NO WINDOWS
ATENÇÃO
O procedimento para instalação do PostgreSQL no sistema operacional Windows é bastante trivial e basicamente segue
o padrão (Next → Next → ... → Finish).
Após fazer o download do arquivo instalador para Windows (postgresql-12.3-1-windows-x64.exe, com cerca de 195 MB,
no caso da versão 12), deve-se executar o arquivo como usuário administrador. Após a tela de inicialização da
instalação, será mostrada a de localização do diretório de instalação que, por padrão, criará a pasta C:\Program Files\
PostgreSQL\12, onde 12 é a versão do PostgreSQL.
Fonte: Software de instalação do PostgreSQL para WindowsTela de definição do diretório de instalação.

A seguir, o instalador perguntará quais componentes serão instalados junto com o servidor PostgreSQL. Por padrão, são
instalados:
O PGADMIN
Uma interface gráfica de administração;
O PSQL
Uma ferramenta de linha de comando para administração;
O STACK BUILDER
Uma ferramenta útil para gerenciar a instalação de módulos complementares, tais como utilitários, drivers e extensões.
Fonte: Software de instalação do PostgreSQL para WindowsTela de seleção de componentes a instalar.

Em seguida, o instalador determina o diretório onde ficarão armazenados os dados no seu servidor. Na instalação
padrão do Windows, os dados ficam armazenados no diretório C:\Program Files\PostgreSQL\12\data. Nesse diretório, é
criado um subdiretório C:\Program Files\PostgreSQL\12\data\base, dentro do qual será criada uma pasta numerada
para cada database, a começar pelo database padrão do servidor, denominado postgres, criado com a instalação.
ATENÇÃO
Cada pasta correspondente a um database armazena arquivos numerados contendo metadados do catálogo do SGBD,
assim como arquivos numerados para cada tabela criada dentro do database.
Fonte: Software de instalação do PostgreSQL para WindowsTela de localização do diretório de dados.
Concluído o processo de instalação do PostgreSQL, será possível visualizar no pgAdmin 4 a árvore de diretórios da
instalação padrão, contendo:
Servers (1) PostgreSQL 12
Databases (1) postgres
Schemas (1) public
Tables
Fonte: Software pgAdmin 4Tela do pgAdmin 4 com a árvore de diretórios da instalação padrão do PostgreSQL.
INTERFACES PARA INTERAGIR COM O POSTGRESQL
ATENÇÃO
Ao longo deste e dos próximos módulos, será necessário o uso de algum tipo de interface que permita conexão ao
servidor e, em seguida, o acesso aos objetos de interesse.
Além do pgAdmin 4, a interface gráfica própria que provê acesso aos recursos do SGBD via navegador, o PostgreSQL
disponibiliza o psql, uma interface de linha de comando sobre a qual o usuário submete interativamente comandos ao
SGBD, via terminal.
O PostgreSQL possui uma excelente documentação disponível on-line, aplicável tanto para instalação em Linux quanto
para Windows, considerada uma verdadeira enciclopédia de bancos de dados relacionais. Essa documentação é válida
para uso dos recursos do PostgreSQL através de quaisquer interfaces.
Alternativamente, você pode optar por baixar e usar interfaces projetadas por outros desenvolvedores. Por exemplo, o
aplicativo DBeaver possui uma versão livre com excelentes funcionalidades. Trata-se de um aplicativo útil no
desenvolvimento de atividades de administração de banco de dados.
Fonte: EvalCo/Shutterstock
CRIANDO DATABASES COM O PGADMIN 4 E COM O PSQL
Tendo instalado o PostgreSQL, para nos certificarmos de que o SGBD está funcionando de maneira adequada,
realizaremos um teste envolvendo a criação de databases, conforme a seguir:
database BDTESTEPGADMIN, a ser criado usando o pgAdmin 4.
database BDTESTEPSQL, a ser criado usando o psql

No Windows, selecione o botão Iniciar, digite “pgAdmin 4” e tecle <enter>. Em seguida, o navegador será aberto, e você
terá acesso a um ambiente onde aparece um único database denominado postgres, criado pelo instalador.
Fonte: Software pgAdmin 4Tela do pgAdmin 4 com o database postgres criado pelo instalador.
Com o foco no database postgres, clique em Tools e em Query Tool para abrir um editor (Query Editor) onde você
codificará e submeterá (utilizando a tecla F5 ou o botão correspondente com uma seta) comandos SQL ao servidor.
Vamos criar o database BDTESTEPGADMIN a partir do ambiente do pgAdmin 4. Digite o código a seguir no Query
Editor e, em seguida, pressione a tecla F5 para executar o comando:
CREATE DATABASE BDTESTEPGADMIN;
Alternativamente, o database poderia ser criado usando a interface do pgAdmin 4, pressionado o botão direito do
mouse sobre a pasta Databases e clicando em Create.
Agora, vamos criar um database usando a interface de terminal psql. No Windows, a partir do botão Iniciar, digite “psql”
e tecle <enter>. Logo um terminal será aberto e você executará o seguinte comando (teclando <enter> após o
comando):
CREATE DATABASE BDTESTEPSQL;
Após o SGBD executar o comando, a tela do psql ficará conforme vemos a seguir:
Fonte: Software psqlTela do psql após criação do database BDTESTEPSQL.

Ao final desse processo, podemos verificar, no pgAdmin 4, a criação dos dois databases conforme mostrado na imagem
abaixo.
Fonte: Software psqlTela do pgAdmin 4 mostrando os databases recém-criados
Neste módulo, apresentamos um breve histórico a respeito do PostgreSQL, além de detalhes sobre a arquitetura deste
SGBD. Em seguida, mostramos o processo de instalação do SGBD no Linux e no Windows. Finalmente, verificamos a
criação de databases utilizando as ferramentas pgAdmin 4 e psql, com objetivo de confirmarmos que a instalação foi
realizada de maneira correta.
Maiores detalhes sobre a utilização do pgAdmin 4 e do psql podem ser pesquisados nas respectivas documentações que
acompanham os softwares.
CRIAÇÃO DE DATABASES NO POSTGRESQL
1. ACERCA DO SGBD POSTGRESQL, ASSINALE A PROPOSIÇÃO VERDADEIRA.
O PostgreSQL é um SGBD comercial de código fechado, disponível apenas para ambiente Windows.
O PostgreSQL é um SGBD de código aberto, com versões compatíveis com diversos sistemas operacionais, tais como
Windows, MAC OS e diversas distribuições Linux.
O PostgreSQL é um SGBD puramente orientado a objeto.
O PostgreSQL é um SGBD puramente relacional.
2. ANALISE AS SEGUINTES PROPOSIÇÕES A RESPEITO DO POSTGRESQL:
I - O COMANDO “CREATE USER BTESTE SUPERUSER INHERIT CREATEDB CREATEROLE; ” CRIA UM BANCO DE DADOS
DENOMINADO BTESTE.
II - AO INSTALAR O POSTGRESQL VERSÃO 12 NO WINDOWS, A PASTA PADRÃO DE INSTALAÇÃO É “C:/PROGRAM
FILES/POSTGRESQL/12”.
III - O COMANDO “CREATE TABLE CLIENTE (CODIGOC INT NOT NULL, NOME CHAR(80), CONSTRAINT CHAVECLIENTE
PRIMARY KEY (CODIGOC));” CRIA UMA TABELA DENOMINADA CLIENTE COM AS COLUNAS CODIGOC E NOME, SENDO
QUE A COLUNA CODIGOC É CHAVE ESTRANGEIRA.
IDENTIFIQUE AS PROPOSIÇÕES FALSAS:

I, II e III.
I e III.
I e II.
II e III.
GABARITO
1. Acerca do SGBD PostgreSQL, assinale a proposição verdadeira.
De fato, o PostgreSQL é um SGBD livre e está disponível para funcionamento em diversas plataformas de sistemas
operacionais.
2. Analise as seguintes proposições a respeito do PostgreSQL:
I - O comando “create user bteste superuser inherit createdb createrole; ” cria um banco de dados denominado bteste.
II - Ao Instalar o PostgreSQL versão 12 no Windows, a pasta padrão de instalação é “C:/Program Files/PostgreSQL/12”.
III - O comando “create table cliente (codigoc int not null, nome char(80), constraint chavecliente primary key
(codigoc));” cria uma tabela denominada cliente com as colunas codigoc e nome, sendo que a coluna codigoc é chave
estrangeira.
Identifique as proposições falsas:

O comando expresso na primeira proposição cria um usuário denominado bteste, e não um banco de dados. O comando
expresso na terceira proposição cria uma tabela denominada cliente. No entanto, a coluna codigoc é chave primária, e
não chave estrangeira.
MÓDULO 2
Empregar comandos para criação e alteração de tabelas

BREVE HISTÓRICO DA SQL
A SQL foi criada na IBM na década de 1970, sendo originalmente chamada de SEQUEL(Strucutured English Query
Language), inspirada, principalmente, na aparente facilidade de uso do comando SELECT para consulta a tabelas dos
bancos de dados relacionais.
Com a evolução dos sistemas gerenciadores de banco de dados (SGBDs), diversas empresas lançaram produtos
incorporando funcionalidades à SQL, o que ocasionou problemas de compatibilidade. Buscando uma solução, o
instituto ANSI definiu padrões para a linguagem SQL, a qual passou a ser referenciada ANSI-SQL.
Atualmente, há diversos SGBDs compatíveis com o padrão ANSI SQL, que vai muito além de consultas com o comando
SELECT, englobando sublinguagens para definição de dados (CREATE, ALTER, DROP) e para manipulação de dados
(INSERT, UPDATE, DELETE), além de comandos de controle típicos para administração do banco de dados. Ao mesmo
tempo, vários produtos de SGBDs relacionais apresentam extensões à linguagem, como modo de facilitar o dia a dia dos
desenvolvedores.
ANSI
American National Standards Institute, também conhecido por sua sigla ANSI, é uma organização particular norte-
americana sem fins lucrativos que tem por objetivo facilitar a padronização dos trabalhos de seus membros.
Fonte: Wikipedia
ACESSO AO POSTGRESQL
Quero criar tabelas em um SGBD PostgreSQL. Por onde começo?
Executando o pgAdmin 4, o navegador será aberto, e você terá acesso ao ambiente que permite manipular os objetos
do PostgreSQL.
Depois, escolha um database na hierarquia e dê um clique com o botão inverso do mouse. Em seguida, escolha a
opção Query Tool.
DICA
O pgAdmin é a interface Web padrão do PostgreSQL, mas você pode escolher o utilitário de sua preferência para
praticar os comandos que aprenderemos ao longo das próximas seções.
CRIANDO UM BANCO DE DADOS
Após escolher um utilitário para acessar o servidor PostgreSQL, será necessário criar um database para, em seguida,
manipular tabelas. Por exemplo, para criarmos um database denominado bdestudo, é necessário executar o comando a
seguir:
-- Comando para criar um database.
CREATE DATABASE BDESTUDO;
No comando acima, a linha com “--” corresponde a comentário e seu conteúdo não é processado pelo SGBD. Caso haja
necessidade de remover o database bdestudo, basta executar o comando a seguir:
-- Comando para remover um database.
DROP DATABASE BDESTUDO;
Antes de prosseguirmos com a criação de tabelas, principal objetivo deste módulo, é preciso compreender que
todo database criado no PostgreSQL possui um schema padrão denominado public, onde as tabelas a serem criadas
no database serão armazenadas. Assim, se não especificarmos a qual schema do database pertence uma tabela que
estamos criando, esta será armazenada no schema public. Para especificarmos um schema diferente do public, antes de
criar uma tabela, devemos criar o respectivo schema, com o comando CREATE SCHEMA.
EXEMPLO
CREATE SCHEMA esquema;
A partir de então, qualquer tabela pertencente ao schema esquema deverá ser especificada pelo seu nome completo:
esquema.tabela
CRIANDO TABELAS
Já sabemos que um banco de dados, em geral, possui diversas tabelas. As tabelas são criadas com auxílio do comando
CREATE TABLE. Usaremos esse comando para implementar o modelo expresso na figura a seguir, dentro
do database bdestudo anteriormente criado:
Fonte: Fonte: O autorModelo relacional com as tabelas CURSO e NIVEL.

Veja a seguir a sintaxe básica do comando CREATE TABLE:
CREATE TABLE NOMETABELA (
COLUNA1 - TIPODEDADOS [RESTRIÇÃO],
COLUNAN - TIPODEDADOS [RESTRIÇÃO],
PRIMARY KEY (COLUNA),
FOREIGN KEY (COLUNA) REFERENCES NOMETABELA (COLUNA)
CONSTRAINT RESTRIÇÃO);
Vamos agora analisar o significado de cada item na sintaxe apresentada anteriormente:
NOMETABELA representa o nome da tabela que será criada
COLUNA1 e COLUNAN representa a(s) coluna(s) da tabela
TIPODEDADOS indica tipo de dados ou domínio da coluna
RESTRIÇÃO aponta alguma propriedade associada à coluna em questão. Por exemplo, podemo
PRIMARY KEY indica a coluna, ou conjunto de colunas, representativa da chave primária

FOREIGN KEY sinaliza a coluna, ou conjunto de colunas, com restrição de chave estrangeira
CONSTRAINT RESTRIÇÃO indica alguma restrição que poderá ser declarada
A sintaxe completa a respeito do comando CREATE TABLE no PostgreSQL pode ser encontrada no site oficial do PostgreSQL.

TIPOS DE DADOS
Cada coluna de tabela deve pertencer a um tipo de dados. No PostgreSQL, os tipos mais comuns são:
bigint valores inteiros compreendidos entre -9.223.372.036.854.775.808 e 9.223.372.036.854.775.80
útil para sequências de caracteres de tamanho fixo. O parâmetro comprimento determina o

char(comprimento)
completar o total de caracteres definidos, caso a totalidade do tamanho do campo não esteja
date data de calendário no formato AAAA-MM-DD
decimal determina a precisão do valor de casas decimais
double precisão do valor de até 15 casas decimais
int ou integer valores inteiros compreendidos entre -2.147.483.648 e 2.147.483.647
money valores monetários compreendidos entre –92.233.720.368.547.758.08 e 92.233.720.368.547.7
numeric precisão do valor de casas decimais
real precisão do valor de até seis casas decimais
serial gera valor único inteiro sequencial para um novo registro entre 1 e 2.147.483.647
smallint representa valores compreendidos entre 32.768 e 32.767
time representa horário no intervalo de tempo entre 00:00:00 e 24:00:00
varchar(comprimento) útil para sequência de dados de caracteres com comprimento variável. Não armazena espaços

DICA
Para maiores detalhes sobre os tipos de dados, sugerimos que você acesse a documentação do PostgreSQL, disponível
no site oficial do produto.
EXEMPLO ENVOLVENDO CRIAÇÃO DE TABELAS
Veja a seguir o código SQL que permite a criação das tabelas NIVEL e CURSO, respectivamente:
Fonte: O autor
A tabela NIVEL está especificada no bloco de comandos entre as linhas 2 e 6. As duas colunas da tabela são obrigatórias.
A tabela CURSO está especificada no bloco de comandos entre as linhas 8 e 15. As colunas DATACRIACAO e CODIGONIVEL s
outro momento, ser associado à informação que caracteriza o nível dele.

ATENÇÃO
Note que, como não foi especificado um schema para armazenar essas tabelas, elas pertencerão
ao schema padrão public do database bdestudo.
Finalmente, observe que, na linha 5, a coluna NOME foi declarada com o qualificador UNIQUE. Na prática, o SGBD
controlará a propriedade de unicidade na referida coluna, proibindo que haja mais de uma ocorrência da mesma ao
longo de todo o ciclo de vida do banco de dados.
GERENCIAMENTO DE SCRIPTS NA PRÁTICA
Note que o script SQL acima possui 15 linhas. Esse é um exemplo didático que possui somente duas tabelas. No entanto,
você vai perceber que no dia a dia os projetos reais possuem quantidade de tabelas que facilmente podem ultrapassar
dois dígitos.
É importante que você conheça comandos DDL, mas o uso prático ocorrerá com auxílio de ferramentas que
automatizam o processo de gestão e administração de dados. Tais ferramentas permitem - manipulando elementos
visuais - criar tabelas, relacionamentos e restrições, além de executar outras atividades. As ferramentas permitem gerar
código DDL referente ao projeto como um todo, ou parte dele. São exemplos: DBeaver, Vertabelo, SQL Power Architect,
Toad for SQL, Erwin, entre outras.
SGBD POSTGRESQL NOS BASTIDORES
Aprendemos a criar um database com o uso do comando CREATE DATABASE. No entanto, a submissão de um simples
CREATE DATABASE ao PostgreSQL gera uma série de etapas gerenciadas pelo servidor.
Se considerarmos a instalação padrão no Windows, ao criar um database o servidor cria uma pasta identificada por um
número (OID), dentro do diretório C:\Program Files\PostgreSQL\12\data\base.
Fonte: O autorPastas representativas de databases, antes da criação do database TESTEBANCO.
Após a execução do comando CREATE DATABASE TESTEBANCO; foi criada a pasta 41017, conforme imagem a seguir:
Fonte: O autorPastas representativas de databases, após da criação de TESTEBANCO.

Ainda, o PostgreSQL mantém informações sobre todos os databases em um database especial denominado catálogo,
cujas tabelas possuem nomes iniciados com o prefixo PG_. Por exemplo, informações sobre os databases existentes em
um servidor são armazenadas na tabela PG_DATABASE. Assim, caso você queira identificar o nome correspondente ao
OID do PostgreSQL, basta executar o comando a seguir:
SELECT OID, DATNAME FROM PG_DATABASE;
O resultado desse comando pode ser visualizado na tabela a seguir:
Fonte: O autorResultado de consulta à tabela PG_DATABASE.

Precisamos ressaltar que, em seu computador, o resultado poderá ser diferente do apresentado, tendo em vista as
operações que você tenha realizado no SGBD.
Fonte: Alexander Supertramp/Shutterstock
ALTERAÇÃO DE TABELA
Você vai se deparar com situações em que será necessário alterar a estrutura de uma tabela já existente.
Vamos estudar um exemplo?
Suponha que surgiu a necessidade de modelar a informação sobre a data de primeiro reconhecimento do curso.
Podemos, então, alterar a estrutura da tabela CURSO, adicionando uma coluna opcional denominada DTRECONH. O
comando ALTER TABLE é útil no contexto dessa tarefa.
A seguir, sintaxe básica do comando ALTER TABLE:
ALTER TABLE <NOMETABELA> ADD <COLUNA><TIPODEDADOS> ;
Na sintaxe apresentada:
<NOMETABELA>
Representa o nome da tabela sobre a qual haverá a modificação.
<COLUNA>
Representa o nome da coluna.
<TIPODEDADOS>
Representa o domínio da coluna.
A sintaxe completa a respeito do comando ALTER TABLE pode ser encontrada no site oficial do PostgreSQL.
A seguir, veja o código SQL que permite a alteração da tabela CURSO:
-- Comando para alterar a tabela CURSO, adicionando coluna DTRECONH
ALTER TABLE CURSO ADD DTRECONH DATE;
Por padrão, o SGBD cria a coluna como opcional. É como se o comando estivesse com o qualificador NULL declarado
imediatamente antes do “;”.
E se desejarmos remover uma coluna da tabela? Podemos usar a sintaxe a seguir:
ALTER TABLE <NOMETABELA> DROP <COLUNA> ;
Vamos agora remover a coluna DTRECONH da tabela CURSO. A seguir, código SQL que permite a alteração:
-- Comando para alterar a tabela CURSO, removendo a coluna DTRECONH
ALTER TABLE CURSO DROP DTRECONH ;
REMOÇÃO DE TABELA
Você vai se deparar com situações em que será necessário remover uma tabela do banco de dados. Esta ação é
realizada com o auxílio do comando DROP TABLE, cuja sintaxe está expressa a seguir:
DROP TABLE <NOMETABELA>;
Vamos agora remover a tabela CURSO com o devido código SQL:
-- Comando para remover a tabela CURSO
DROP TABLE CURSO;
Agora, vamos conhecer alguns cuidados que devem ser tomados quando formos manipular a estrutura de tabelas
relacionadas.
CRIAÇÃO E ALTERAÇÃO DE TABELAS RELACIONADAS
No exemplo envolvendo criação de tabelas, o relacionamento entre as tabelas NIVEL e CURSO foi declarado no bloco
CREATE TABLE da tabela CURSO (linha 14). No entanto, nós poderíamos ter optado por criar as tabelas NIVEL e CURSO
sem relacionamento, para, em seguida, alterar a tabela CURSO, adicionando a restrição de chave estrangeira.
Na hipótese dessa estratégia, o script SQL ficaria do seguinte modo:
Fonte: O autor
ATENÇÃO
Note que, no script anterior, as tabelas foram criadas sem chave estrangeira (linhas 1 a 12). Na linha 14, o comando
ALTER TABLE modifica a estrutura da tabela CURSO, implementando a restrição de chave estrangeira que representa o
relacionamento entre CURSO e NIVEL.
CUIDADOS AO MANIPULAR TABELAS RELACIONADAS
Aprendemos que um banco de dados relacional é composto por diversas tabelas e que cada tabela em geral possui
várias colunas. Vimos também que o relacionamento entre tabelas é implementado com o uso do mecanismo de chave
estrangeira.
Quando definimos que alguma coluna é uma chave estrangeira, na prática, estamos criando uma dependência entre as
tabelas envolvidas, pois toda chave estrangeira aponta para o valor de alguma chave primária.
Ao mesmo tempo, todo SGBD precisa manter a integridade dos dados durante todo o ciclo de vida do banco de dados.
Com isso, não basta somente conhecermos a estrutura dos comandos para alteração de tabelas.
RESUMINDO
Queremos dizer que, em algumas situações, mesmo que o comando para alteração ou exclusão esteja correto sob o
ponto de vista sintático, o SGBD sempre prioriza a integridade dos dados e pode inibir sua execução caso o resultado
tenha potencial para gerar inconsistência nos dados.
Suponha que temos interesse em remover a tabela NIVEL. Para isso, executaremos o seguinte comando SQL:
-- Comando para remover a tabela NIVEL
DROP TABLE NIVEL;
O SGBD não removerá a tabela NIVEL e retornará uma mensagem de erro, informando que há um objeto (tabela
CURSO) que depende da tabela NIVEL.
Perceba que se o SGBD removesse a tabela NIVEL, a tabela CURSO ficaria inconsistente, visto que sua chave estrangeira
(CODIGONIVEL) faz referência à chave primária da tabela NIVEL. Assim, antes de remover uma tabela do banco de
dados, é necessário avaliar todos os relacionamentos desta.
E se ainda assim quiséssemos remover a tabela NIVEL?
RESPOSTA
Antes, precisaríamos remover as dependências, para em seguida excluí-la do banco de dados. No entanto, como, no
banco de dados, pode haver várias dependências envolvendo a tabela NIVEL – o que tornaria o processo mais demorado
– o SGBD dispõe de um recurso que realiza essa tarefa automaticamente. Trata-se de remoção em cascata.
Nesse caso, poderíamos usar o comando SQL a seguir:
-- Comando para remover a tabela NIVEL - remoção em cascata
DROP TABLE NIVEL CASCADE;
Internamente, o comando altera a estrutura da tabela CURSO, removendo a restrição de chave estrangeira da coluna
CODIGONIVEL. Em seguida, a tabela NIVEL é removida do banco de dados.
Ao longo deste módulo, aprendemos comandos básicos da linguagem SQL, úteis para a criação de tabelas no SGBD
PostgreSQL. Ainda, conhecemos os tipos de dados mais comuns do PostgreSQL. Em seguida, estudamos comandos para
a alteração e a remoção de tabelas do banco de dados.
COMANDOS DE CRIAÇÃO, ALTERAÇÃO E REMOÇÃO DE TABELAS
1. ANALISE O SCRIPT A SEGUIR E ASSINALE A PROPOSIÇÃO VERDADEIRA:
FONTE: O AUTOR
A execução completa do script cria três tabelas e todas as colunas são obrigatórias.
A execução dos comandos entre as linhas 1 e 16 cria três tabelas relacionadas.
A execução dos comandos entre as linhas 18 e 24 cria três relacionamentos.
A execução dos comandos entre as linhas 18 e 24 cria dois relacionamentos: o primeiro envolve as tabelas
CURSODISCIPLINA e CURSO. O segundo, as tabelas CURSODISCIPLINA e DISCIPLINA.
2. ANALISE O MODELO A SEGUIR E ASSINALE A PROPOSIÇÃO VERDADEIRA:
FONTE: O AUTOR
A execução do script a seguir cria a tabela CURSODISCIPLINA e seus relacionamentos.
CREATE TABLE CURSODISCIPLINA (
CODIGOCURSO int NOT NULL,
CODIGODISCIPLINA int NOT NULL,
CONSTRAINT CURSODISCIPLINA_pk (PRIMARY KEY (CODIGOCURSO,CODIGODISCIPLINA));
A execução do script a seguir cria a tabela DISCIPLINA.
CREATE TABLE CURSO (
CODIGOCURSO int NOT NULL,
NOME char(90)NOT NULL,
DATACRIACAO date NULL,
CONSTRAINT CURSO_pk (PRIMARY KEY (CODIGOCURSO));
Admitindo a existência das tabelas CURSODISCIPLINA e DISCIPLINA, a execução do script a seguir relaciona
CURSODISCIPLINA à DISCIPLINA.
ALTER TABLE CURSODISCIPLINA ADD FOREIGN KEY (CODIGOCURSO)
REFERENCES CURSO (CODIGOCURSO) ;
Admitindo a existência das tabelas CURSODISCIPLINA e CURSO, a execução do script a seguir relaciona
CURSODISCIPLINA à CURSO.
ALTER TABLE CURSODISCIPLINA ADD FOREIGN KEY (CODIGOCURSO)
REFERENCES CURSO (CODIGOCURSO)
GABARITO
1. Analise o script a seguir e assinale a proposição verdadeira:
Fonte: O autor
De fato, há dois blocos de comando entre as linhas 18 e 24. O primeiro altera a estrutura da tabela CURSODISCIPLINA
adicionando à coluna CODIGOCURSO uma restrição de chave estrangeira que implementa o relacionamento entre as
tabelas CURSODISCIPLINA e CURSO. O segundo altera a estrutura da tabela CURSODISCIPLINA, adicionando à coluna
CODIGODISCIPLINA uma restrição de chave estrangeira que implementa o relacionamento entre as tabelas
CURSODISCIPLINA e DISCIPLINA.
2. Analise o modelo a seguir e assinale a proposição verdadeira:
Fonte: O autor
De fato, se observarmos o modelo, há um relacionamento entre as tabelas CURSO e CURSODISCIPLINA. Ao executar o

ALTER TABLE, a coluna CODIGOCURSO da tabela CURSODISCIPLINA passa a funcionar como chave estrangeira, fazendo
referência à tabela CURSO.
MÓDULO 3
Empregar comandos para manipular linhas nas tabelas

MANIPULAÇÃO DE LINHAS NAS TABELAS
Quando usamos o termo manipulação, fazemos referência às operações de inserção, atualização ou mesmo eliminação
de dados. Em uma linguagem mais comercial, existe o termo CRUD, que representa quatro operações básicas: criação,
consulta, atualização e remoção de dados, respectivamente.
No contexto da da SQL, costumamos usar o seguinte mapeamento dos comandos:
Create: INSERT
Read: SELECT
Update: UPDATE
Delete: DELETE
Ainda, os comandos da linguagem SQL que aprenderemos fazem parte da DML e são usados para inserir, modificar e
remover dados.
DML
Data Manipulation Language ou Linguagem de Manipulação de Dados.
MODELO PARA OS EXEMPLOS
Ao longo da nossa aprendizagem, nós vamos admitir que o modelo a seguir está criado no banco de dados:
Fonte: O autorTabelas CURSO, CURSODISCIPLINA e DISCIPLINA.

DICA
Recomendamos que você crie as tabelas e insira algumas linhas, o que pode ser feito usando o script a seguir, a partir da
ferramenta de sua preferência. Para isso, tenha em mente que é necessário estar conectado ao PostgreSQL e ao
database bdestudo criado anteriormente.
Fonte: Autor
O modelo é útil para gerenciar os dados de cursos, disciplinas e do relacionamento entre esses objetos. Em especial,
cada linha da tabela CURSODISCIPLINA representa uma associação entre curso e disciplina.
INSERÇÃO DE LINHAS EM TABELA
A inserção de linhas em tabela é realizada com o auxílio do comando INSERT da SQL. Sua sintaxe básica está expressa a
seguir:
INSERT INTO <NOMETABELA> (COLUNA1, COLUNA2,…,COLUNAn) VALUES (VALOR1, VALOR2,…,VALORn);
Na sintaxe, <NOMETABELA> representa a tabela alvo da inserção. Em seguida, são declaradas as colunas que receberão
os dados; por último, os dados em si. Note que deve haver uma correspondência entre cada par COLUNA/VALOR, ou
seja, o conteúdo de cada coluna deve ser compatível com o tipo de dados ou domínio dela.
A sintaxe completa a respeito do comando INSERT pode ser encontrada no site oficial do PostgreSQL.
Iremos cadastrar quatro cursos. O comando SQL a seguir pode ser utilizado:
INSERT INTO CURSO (CODIGOCURSO,NOME,DATACRIACAO)
VALUES( 1,'Sistemas de Informação','19/06/1999');
VALUES( 2,'Medicina','10/05/1990');
VALUES( 3,'Nutrição','19/02/2012');
VALUES( 4,'Pedagogia','19/06/1999');
ATENÇÃO
Note que, dentro dos parênteses representativos dos conteúdos, o primeiro valor, por ser do tipo inteiro, foi informado
sem aspas. Já o segundo valor, por ser do tipo char, foi informado com aspas. Finalmente, o valor referente ao tipo date
também foi informado entre aspas. Internamente, o PostgreSQL converte o texto para o formato de data.
Agora, faremos um procedimento semelhante, cadastrando quatro disciplinas. O comando SQL a seguir pode ser
utilizado:
INSERT INTO DISCIPLINA (CODIGODISCIPLINA,NOME,CARGAHORARIA)
VALUES( 1,''Leitura e Produção de Textos',60);
VALUES( 2,''Redes de Computadores',60);
VALUES( 3,'Computação Gráfica',40);
VALUES( 4,'Anatomia',60);
Agora, vamos registrar na tabela CURSODISCIPLINA algumas associações entre cursos e disciplinas. O comando SQL a
seguir pode ser utilizado:
INSERT INTO CURSODISCIPLINA(CODIGOCURSO,CODIGODISCIPLINA) VALUES (1,1);
E se submetermos ao SGBD o comando a seguir?
RESPOSTA
O SGBD não realizará a inserção e retornará uma mensagem de erro informando que 30 não é um valor previamente
existente na chave primária da tabela DISCIPLINA. Isso acontece porque, quando definimos (linha 16 do script da seção
anterior) a chave estrangeira da tabela CURSODISCIPLINA, nós delegamos ao SGBD a tarefa de realizar esse tipo de
validação com objetivo de sempre manter a integridade dos dados do banco de dados. Note que não existe disciplina
identificada de código 30 na tabela DISCIPLINA.
MECANISMO DE CHAVE PRIMÁRIA EM AÇÃO
Já vimos que o SGBD é responsável por manter a integridade dos dados ao longo de todo o ciclo de vida do banco de
dados. A consequência disso pode ser percebida ao tentarmos executar (novamente) o comando a seguir:
INSERT INTO DISCIPLINA (CODIGODISCIPLINA, NOME, CARGAHORARIA) VALUES (4,'Anatomia',60);
Como já existe um registro com valor de CODIGODISCIPLINA igual a 4, o SGBD exibirá mensagem de erro informando
que o referido valor já existe no banco de dados. Semelhantemente, devemos lembrar que todo valor de chave primária
é obrigatório.
Vamos agora tentar inserir uma disciplina sem valor para CODIGODISCIPLINA, conforme comando SQL a seguir:
INSERT INTO DISCIPLINA (CODIGODISCIPLINA, NOME, CARGAHORARIA) VALUES (NULL,'Biologia Celular e Molecular',60);
O SGBD exibirá mensagem de erro informando que o valor da coluna CODIGODISCIPLINA não pode ser nulo.
ATUALIZAÇÃO DE LINHAS EM TABELA
A atualização de linhas em tabela é realizada com o auxílio do comando UPDATE da SQL. Sua sintaxe básica está
expressa a seguir:
UPDATE <NOMETABELA>
SET COLUNA1=VALOR1, COLUNA2=VALOR2,…,COLUNAn=VALORn
WHERE <CONDIÇÃO>;
Na sintaxe, <NOMETABELA> representa a tabela alvo da atualização. Em seguida, é declarada uma lista contendo a
coluna e o seu respectivo valor novo. Por último, uma condição lógica, caso seja necessário. Isso ocorre porque, em
geral, estamos interessados em alterar somente um subconjunto de linhas que é obtido a partir do processamento da
cláusula WHERE. A sintaxe completa a respeito do comando UPDATE pode ser encontrada no site oficial do PostgresSQL.
Vamos estudar alguns exemplos?
Alteraremos para 70 a carga horária da disciplina Redes de Computadores. Para isso, basta executar o comando a
seguir:
UPDATE DISCIPLINA SET CARGAHORARIA=70 WHERE CODIGODISCIPLINA=2;
No comando, o SGBD busca na tabela a disciplina cujo valor da coluna CODIGODIISCIPLINA seja igual a 2. Em seguida,
atualiza o valor da coluna CARGAHORARIA para 70. Note também que poderíamos ter executado o comando a seguir:
UPDATE DISCIPLINA SET CARGAHORARIA=70 WHERE NOME='Redes de Computadores';
Suponha agora que houve a necessidade de alterar em 20% a carga horária de todas as disciplinas cadastradas no banco
de dados. Podemos executar o seguinte comando:
UPDATE DISCIPLINA SET CARGAHORARIA=CARGAHORARIA*1.2;
Note que, no último comando, não foi necessária a cláusula WHERE, visto que o nosso interesse era o de atualizar todas
as linhas da tabela DISCIPLINA. Ainda, para obter o novo valor, nós utilizamos a expressão CARGAGORARIA*1.2.
Fonte: TierneyMJ/Shutterstock
ATUALIZAÇÃO DE COLUNA CHAVE PRIMÁRIA
Devemos ter especial cuidado ao planejarmos alterar o valor de coluna com o papel de chave primária em uma tabela.
Vamos supor que seja necessário alterar para 6 o valor de CODIGOCURSO referente ao curso de Pedagogia. Podemos,
então, executar o comando a seguir:
UPDATE CURSO SET CODIGOCURSO=6 WHERE CODIGOCURSO=4;
Perceba que o SGBD processará a alteração, visto que não há vínculo na tabela CURSODISCIPLINA envolvendo este
curso. No entanto, o que aconteceria se tentássemos alterar para 10 o valor de CODIGOCURSO referente ao curso de
Sistemas de Informação?
Seguindo a mesma linha de raciocínio da última alteração, vamos submeter o comando a seguir:
ATENÇÃO
O SGBD não realizará a alteração e retornará uma mensagem de erro indicando que o valor 1 está registrado na tabela
CURSODISCIPLINA, coluna CODIGOCURSO. Isso significa que, se o SGBD aceitasse a alteração, a tabela CURSODISCIPLINA
ficaria com dados inconsistentes, o que não deve ser permitido.
Assim, de modo semelhante ao que aprendemos na seção Mecanismo de chave primária em ação, deixaremos o SGBD
realizar as alterações necessárias para manter a integridade dos dados. Vamos, então, submeter o comando a seguir:
ALTER TABLE CURSODISCIPLINA
DROP CONSTRAINTCURSODISCIPLINA_CURSO,
ADD CONSTRAINT CURSODISCIPLINA_CURSO
FOREIGN KEY (CODIGOCURSO) REFERENCES CURSO (CODIGOCURSO)
ON UPDATE CASCADE ;
O que fizemos? Usamos o comando ALTER TABLE para alterar a estrutura da tabela CURSODISCIPLINA:, removemos a
chave estrangeira (comando DROP CONSTRAINT) e, por último, recriamos a chave (ADD CONSTRAINT), especificando a
operação de atualização (UPDATE) em cascata.
Assim, após o processamento da alteração anterior, podemos então submeter o comando, conforme a seguir:
REMOÇÃO DE LINHAS EM TABELA
A remoção de linhas em tabela é realizada com o auxílio do comando DELETE da SQL. Sua sintaxe básica está expressa a
seguir:
DELETE FROM <NOMETABELA>
WHERE <CONDIÇÃO>;
Na sintaxe, <NOMETABELA> representa a tabela alvo da operação de deleção de linha(s). Por último, há uma condição
lógica, caso seja necessário. Isso ocorre porque, em geral, estamos interessados em remover somente um subconjunto
de linhas que é obtido a partir do processamento da cláusula WHERE. A sintaxe completa a respeito do comando
DELETE pode ser encontrada no site oficial do PostgresSQL.
Suponha que temos interesse em apagar do banco de dados a disciplina de Anatomia. Podemos, então, submeter o
código a seguir:
DELETE FROM DISCIPLINA WHERE CODIGODISCIPLINA=4;
O SGBD localiza na tabela DISCIPLINA a linha cujo conteúdo da coluna CODIGODISCIPLINA seja igual a 1. Em seguida,
remove do banco de dados a linha em questão.
Agora vamos imaginar que tenha surgido a necessidade de remover do banco de dados a disciplina de Leitura e
Produção de Textos. Podemos, então, submeter o código a seguir:
O SGBD não realizará a remoção e retornará uma mensagem de erro indicando que o valor 1 está registrado na tabela
CURSODISCIPLINA, coluna CODIGODISCIPLINA. Se o SGBD aceitasse a remoção, a tabela CURSODISCIPLINA ficaria com
dados inconsistentes, o que não deve ser permitido.
Assim, de modo semelhante ao que aprendemos na seção Mecanismo de chave primária em ação, deixaremos o SGBD
realizar as alterações necessárias para manter a integridade dos dados. Vamos, então, submeter o comando a seguir:
ALTER TABLE CURSODISCIPLINA
DROP CONSTRAINT CURSODISCIPLINA_DISCIPLINA,
ADD CONSTRAINT CURSODISCIPLINA_DISCIPLINA
FOREIGN KEY (CODIGODISCIPLINA) REFERENCES DISCIPLINA (CODIGODISCIPLINA)
ON DELETE CASCADE ;
O que fizemos? Usamos o comando ALTER TABLE para alterar a estrutura da tabela CURSODISCIPLINA:, removemos a
chave estrangeira (comando DROP CONSTRAINT) e, por último, recriamos a chave (ADD CONSTRAINT), especificando
operação de remoção (DELETE) em cascata.
Assim, após o processamento da alteração anterior, podemos submeter o comando conforme a seguir:
Ao processar o comando, o SGBD verifica se existe alguma linha da tabela CURSODISCIPLINA com valor 1 para a coluna
CODIGODISCIPLINA. Caso encontre, cada ocorrência é então removida do banco de dados.
E se quiséssemos eliminar todos os registros de todas as tabelas do banco de dados?
RESPOSTA
Para realizarmos esta operação, precisaremos identificar quais tabelas são mais independentes e quais são as que
possuem vínculos de chave estrangeira.
No caso do nosso exemplo, CURSODISCIPLINA possui duas chaves estrangeiras, portanto, é a tabela mais dependente.
As demais, não possuem chave estrangeira. De posse dessa informação, podemos submeter os comandos a seguir para
completar a tarefa:
DELETE FROM CURSODISCIPLINA;
DELETE FROM CURSO;
DELETE FROM DISCIPLINA;
Perceba que a primeira tabela que foi usada no processo de remoção de linhas foi a CURSODISCIPLINA, pois essa é a
responsável por manter as informações sobre o relacionamento entre as tabelas CURSO e DISCIPLINA. Após eliminar os
registros de CURSODISCIPLINA, o SGBD removerá com sucesso os registros das tabelas CURSO e DISCIPLINA.
Ao longo deste módulo, aprendemos os comandos básicos da linguagem SQL, os quais são úteis para a manipulação de
linhas no SGBD PostgreSQL. Também estudamos comandos para inserir, alterar e eliminar linhas em tabelas.
COMANDOS DE MANIPULAÇÃO DE DADOS
1. ANALISE O SCRIPT A SEGUIR E ASSINALE A PROPOSIÇÃO CORRETA:
FONTE: O AUTOR
Após a execução com sucesso do trecho entre as linhas 1 e 16, se executarmos o comando expresso na linha 18, o SGBD
retornará uma mensagem de erro.
retornará uma mensagem de erro.
não retornará uma mensagem de erro.
não retornará uma mensagem de erro.
2. ANALISE O SCRIPT A SEGUIR E ASSINALE A PROPOSIÇÃO CORRETA:
FONTE: O AUTOR
APÓS A EXECUÇÃO, COM SUCESSO, DO TRECHO ENTRE AS LINHAS 1 E 26, SE EXECUTARMOS O COMANDO EXPRESSO NA
LINHA 28, QUANTAS LINHAS SERÃO REMOVIDAS DO SGBD?
Nenhuma.
Uma.
Duas.
Três.
GABARITO
1. Analise o script a seguir e assinale a proposição correta:
Fonte: O autor
De fato, se observarmos as inserções em CURSO e DISCIPLINA, vamos perceber que os valores de chave primária são os
inteiros 1 e 2 em ambos os casos. Ainda, a tabela CURSODISCIPLINA possui duas chaves estrangeiras: uma referência à
tabela CURSO; a outra, referência à tabela DISCIPLINA. Portanto, o valor para CÓDIGODISCIPLINA da tabela
CURSODISCIPLINA não pode ser diferente de 1 ou 2.
2. Analise o script a seguir e assinale a proposição correta:
Fonte: O autor
Após a execução, com sucesso, do trecho entre as linhas 1 e 26, se executarmos o comando expresso na linha 28,
quantas linhas serão removidas do SGBD?
De fato, a chave estrangeira declarada na linha 15 foi criada de maneira a permitir a deleção em cascata. Ao executar o
comando da linha 28, o SGBD eliminará tanto os dois registros da tabela CURSODISCIPLINA (cujo valor de
CODIGOCURSO é igual a 1) quanto o registro referente ao curso Sistemas de Informação.
MÓDULO 4
Empregar comandos de controle de transação

TRANSAÇÕES EM BANCO DE DADOS
Ao longo do nosso estudo, aprendemos uma série de comandos SQL envolvendo desde a criação de tabelas até
operações de manipulação de dados, tais como inserções, atualizações e exclusões. Basicamente, um comando era
codificado e submetido ao SGBD PostgreSQL, que em seguida o executava e devolvia algum resultado.
Perceba que, sob o contexto dos exemplos que estudamos, poderíamos concluir que, de certa maneira, havia somente
um usuário acessando a totalidade dos recursos do SGBD.
No entanto, em um ambiente de produção, o SGBD gerencia centenas de requisições das aplicações. Com isso,
concluímos que há acesso simultâneo a vários recursos que são gerenciados pelo SGBD.
Ao mesmo tempo, o usuário de uma aplicação que faz uso de recursos de um banco de dados, normalmente, está
preocupado com o resultado dos processos de negócio que estão automatizados.
Fonte: PIYAWAT WONGOPASS/Shutterstock
Para exemplificar, digamos que um sistema acadêmico disponibiliza a inscrição em diversas disciplinas; determinado
aluno, após consultar a oferta e escolher um conjunto de matérias para inscrição, tem expectativa de conseguir
inscrever-se em todas as disciplinas alvo da escolha.
No entanto, sob o ponto de vista do SGBD, prover a inscrição em todas as disciplinas escolhidas pelo estudante requer a
execução, na totalidade, de diversas instruções de inserção de dados em alguma tabela. Além disso, deve existir cuidado
especial para, por exemplo, inibir inscrição em disciplina caso não haja mais disponibilidade de vagas.
ATENÇÃO
É uma situação típica sobre a qual o SGBD precisa prover uma forma de realizar diversas operações como uma unidade
lógica de processamento. Vamos aprender, então, que essa unidade de processamento é denominada transação.
Em sistemas de banco de dados, uma transação corresponde a um programa em execução que forma uma unidade de
trabalho.
Os limites de uma transação são especificados por meio dos comandos begin transaction (que indica o início de uma
transação) e end transaction (que indica o término de uma transação) em um programa de aplicação.
Ainda, se a transação não atualiza o banco de dados, é denominada somente de leitura; caso contrário, é chamada de
leitura-gravação.
Para fins didáticos, um modelo simplificado do banco de dados - coleção de itens nomeados - é usado para estudo dos
conceitos de processamento de transações. Cada item de dados pode representar um registro, bloco ou valor de coluna.
Em se tratando de SGBDs multiusuários, várias transações podem ser executadas simultaneamente. No entanto, caso
essa execução ocorra de maneira descontrolada, poderão surgir problemas de inconsistências, tais como:
ATUALIZAÇÃO PERDIDA
ATUALIZAÇÃO TEMPORÁRIA
RESUMO INCORRETO
LEITURA NÃO REPETITIVA
ATUALIZAÇÃO PERDIDA
Quando duas transações que acessam os mesmos itens de dados têm operações intercaladas de modo a tornar
incorretos alguns itens do banco de dados.
ATUALIZAÇÃO TEMPORÁRIA
Quando uma transação atualiza um item do banco de dados e, depois, falha por algum motivo, enquanto, nesse meio
tempo, o item é lido por outra transação antes de ser alterado de volta para seu valor original.
RESUMO INCORRETO
Quando uma transação calcula uma função de resumo de agregação em uma série de itens enquanto outras transações
atualizam alguns desses itens.
LEITURA NÃO REPETITIVA
Quando uma transação lê o mesmo item duas vezes e o item é alterado por outra transação entre as duas leituras.
É importante sabermos que, quando o SGBD processa uma transação, todas as operações que a formam devem ser
completadas com sucesso para, somente depois, haver a gravação permanente das alterações no banco de dados. Além
disso, caso haja falha em uma ou mais operações de uma transação, as demais operações não devem ser executadas, e
a transação deve ser cancelada.
Se uma transação for cancelada, deve ser executado um processo denominado rollback(Rolar para trás), o qual força o
SGBD a trazer de volta os valores antigos dos registros antes da transação ter iniciado. Finalmente, caso a transação seja
executada com sucesso, as atualizações devem ser confirmadas por meio do comando commit(Confirmação).
Estas são as falhas que podem ocorrer durante o processamento de uma transação:
Falha do computador
Erro de transação ou sistema
Condições de exceção detectadas pela transação
Falha de disco, problemas físicos e catástrofes

A seguir, conheceremos as propriedades das transações.
PROPRIEDADES DE UMA TRANSAÇÃO
Com objetivo de garantir a integridade dos dados contidos no banco de dados, o SGBD mantém um conjunto de
propriedades das transações, denominado ACID, que representam as características de atomicidade, consistência,
isolamento e durabilidade, respectivamente.
ACID
Do Inglês, Atomicity, Consistency, Isolation, Durability.
Atomicidade A transação precisa ser realizada completamente ou não realizada
Consistência A transação deve levar o banco de dados de um estado consistente para outro
Isolamento A execução de uma transação não deve ser interferida por quaisquer outras transações
Durabilidade As mudanças no banco de dados em função da confirmação da transação devem persis

ESTADOS DE UMA TRANSAÇÃO
Uma transação pode passar pelos seguintes estados ao longo do seu processamento:
ATIVO
Ocorre imediatamente após o início da transação, podendo executar operações de leitura e gravação.
PARCIALMENTE CONFIRMADO
Quando a transação termina.
CONFIRMADO
Após verificação bem-sucedida, as mudanças são gravadas permanentemente no banco de dados.
FALHA
Se uma das verificações falhar ou se a transação for abortada durante seu estado ativo.
CONFIRMADO
Transação sai do sistema.
Para poder recuperar-se de falhas que afetam transações, normalmente, o SGBD mantém um log para registrar todas as
operações de transação que afetam os vários itens do banco de dados. As entradas em um registro de log de uma
determinada transação possuem informações de valores antigos e novos do item de dados do banco de dados, bem
como se a transação foi concluída com sucesso ou se foi abortada.
TRANSAÇÕES NO POSTGRESQL
De maneira geral, uma transação no PostgreSQL possui a estrutura a seguir:
BEGIN-- início da transação
-- comandos
COMMIT-- transação confirmada
ROLLBACK-- transação cancelada
END-- mesma função do COMMIT
No entanto, nos SGBDs, a inicialização de uma transação ocorre implicitamente quando executamos alguns comandos.
Seja a tabela CURSO, conforme a seguir:
Fonte: AutorTabela CURSO.

A execução de um INSERT na tabela ocorre dentro do contexto implícito de uma transação:
-- BEGIN implícito
INSERT INTO CURSO (CODIGOCURSO,NOME,DATACRIACAO) VALUES (5,'Engenharia de Computação',NULL);
-- COMMIT implícito
Estudamos que, quando uma transação é desfeita, qualquer operação que faz parte da transação deve ser cancelada.
Vamos, então, ver como podemos fazer isso no PostgreSQL. Veja o exemplo a seguir, construído com objetivo de inserir
um registro na tabela CURSO e, em seguida, indicar que a operação de inserção ser desfeita pelo SGBD:
Fonte: O autor
Após o processamento do comando da linha 1, visualizaremos o conteúdo da tabela CURSO da seguinte maneira:
Fonte: O autorTabela CURSO após a execução do comando da linha 1.

Após o processamento dos comandos da linha 2 à linha 4, que já representam a inserção de um registro na tabela
CURSO sob o contexto de uma transação explícita, teremos este resultado:
Finalmente, após o processamento dos comandos da linha 5 à linha 7, onde a transação é desfeita, teremos o resultado
conforme a tabela a seguir:

Perceba que o comando da linha 2 (BEGIN) iniciou explicitamente uma transação, a qual foi abortada quando da
execução do comando da linha 5 (ROLLBACK).
ATENÇÃO
No exemplo anterior, programamos uma transação que envolveu somente uma operação, a saber, inserção de uma
linha na tabela CURSO. No entanto, uma transação pode envolver diversas linhas de uma tabela do banco de dados.
Vamos, então, programar uma transação que consistirá em duas operações de atualização envolvendo a tabela que
contém as disciplinas, apresentada conforme a seguir:
Fonte: O autorTabela DISCIPLINA.

Inicialmente, vamos listar o conteúdo da tabela DISCIPLINA. Podemos, então, usar o comando a seguir:
SELECT * FROM DISCIPLINA;
Após o processamento do comando, teremos o seguinte resultado:
Fonte: O autorConteúdo da tabela DISCIPLINA com os dados originais.

Agora, nossa intenção é alterar a carga horária das disciplinas de acordo com os critérios a seguir:
Disciplinas que possuem 60 horas: aumento em 20%
Disciplinas que possuam 40 horas: aumento em 10%

O código a seguir expressa uma transação envolvendo operações de atualização de dados na tabela DISCIPLINA:
Fonte: O autor
Após a execução do trecho entre as linhas 1 e 3, o conteúdo da tabela disciplina estará conforme a seguir:
Fonte: O autorConteúdo da tabela DISCIPLINA após a execução da linha 3.

Após a execução da transação, o conteúdo da tabela disciplina estará conforme a seguir:
Fonte: O autorConteúdo da tabela DISCIPLINA após o término da transação.

Outro ponto interessante no projeto de transações é a utilização de pontos de salvamento (SAVEPOINT). Observe o
exemplo a seguir:
Fonte: O autor
Na linha 4, adicionamos um SAVEPOINT denominado CARGA60. Quando a linha 6 for executada, o SGBD vai desfazer a
operação de UPDATE da linha 5.
UM POUCO MAIS SOBRE ATUALIZAÇÃO TEMPORÁRIA
Estudamos que uma transação não deve atrapalhar o andamento de outra. Pense na execução da nossa última
transação, que envolveu dois comandos de atualização na tabela DISCIPLINA.
Vimos que, logo após a execução da linha 3, a única disciplina que não sofreu alteração foi a de Computação Gráfica.
Perceba que o SELECT da linha 3 está sendo executado no contexto da transação.
No entanto, o que aconteceria se tivéssemos em paralelo outra aplicação que submetesse consulta para acessar os
registros da tabela DISCIPLINA no mesmo momento da execução da linha 3 da transação?
RESPOSTA
A consulta em questão enxergaria os dados “originais”, sem quaisquer alterações. Por qual razão? Para não haver o
problema da atualização temporária. Queremos dizer que, se a transação fosse desfeita por qualquer motivo, o UPDATE
da linha 2 seria também desfeito.
UM POUCO MAIS SOBRE TRANSAÇÃO DE LEITURA
Vimos que uma transação que não modifica dados é denominada transação somente de leitura (READ ONLY). Caso
contrário, é denominada leitura-gravação (READ WRITE).
Para especificar o tipo de transação, usaremos o comando SET TRANSACTION <TIPOTRANSAÇÃO>. No PostgreSQL,
quando iniciamos uma transação, o padrão é READ WRITE.
Vamos analisar um exemplo envolvendo uma transação READ ONLY:
Fonte: Autor
Na transação acima, propositalmente, inserimos um comando de atualização em uma transação que não permite essa
categoria de comando. Logo, após a execução da linha 3, o SGBD retornará uma mensagem informando ao usuário que
não é possível executar comando de atualização em uma transação do tipo somente leitura.
Ao longo deste módulo, aprendemos o conceito de transação, que representa uma sequência de comandos que devem
ser executados na totalidade, ou, caso contrário, desfeitos.
Vimos que, por padrão, o SGBD PostgreSQL implicitamente gera uma transação quando submetemos algum comando
de inserção, atualização ou remoção de dados. Por fim, aprendemos comandos para gerenciar transações no
PostgreSQL.
COMANDOS DE CONTROLE DE TRANSAÇÕES
1. A RESPEITO DE TRANSAÇÕES NO POSTGRESQL E, CONSIDERANDO O MODELO A SEGUIR, ASSINALE A PROPOSIÇÃO
VERDADEIRA:
FONTE: O AUTOR
Ao executar o comando DELETE FROM CURSODISCIPLINA(; o PostgreSQL não executa uma transação.
O comando DELETE FROM CURSODISCIPLINA(; pode ser executado sem erro em uma transação PostgreSQL do
tipo READ ONLY.
O comando DELETE FROM CURSODISCIPLINA(; pode ser executado sem erro em uma transação PostgreSQL do
tipo READ WRITE.
O comando SELECT * FROM CURSODISCIPLINA(; não pode ser executado em uma transação PostgreSQL do tipo READ
ONLY.
2. SUPONHA QUE UM PROFISSIONAL PROGRAMOU NO POSTGRESQL OS SEGUINTES COMANDOS EM UMA TABELA
DENOMINADA EMPREGADO:
FONTE: O AUTOR
SUPONHA TAMBÉM QUE, APÓS A EXECUÇÃO DA LINHA 2, O PROFISSIONAL PERCEBEU QUE NÃO DEVERIA TER
AUMENTADO O SALÁRIO DE MARIA NESSE VALOR. QUAL COMANDO É ADEQUADO ADICIONAR À LINHA 3 PARA
DESFAZER ESSA OPERAÇÃO?
DELETE;
COMMIT;
UPDATE;
ROLLBACK;
GABARITO
1. A respeito de transações no PostgreSQL e, considerando o modelo a seguir, assinale a proposição verdadeira:
Fonte: O autor
De fato, se uma transação no PostgreSQL é definida como READ WRITE, ela aceita comandos de inserção, atualização e
remoção de dados. Logo, a instrução que contém o comando DELETE poderá ser executada sem erro.
2. Suponha que um profissional programou no PostgreSQL os seguintes comandos em uma tabela denominada
empregado:
Fonte: O autor
Suponha também que, após a execução da linha 2, o profissional percebeu que não deveria ter aumentado o salário de
Maria nesse valor. Qual comando é adequado adicionar à linha 3 para desfazer essa operação?
De fato, como a transação não foi concluída, é possível desfazer a operação da linha 2, bastando para isso adicionar o
comando ROLLBACK. Após isso, a tabela funcionário ficará com os registros iguais à situação imediatamente anterior à
execução da transação.
CONCLUSÃO
Ao longo do nosso estudo, fizemos uma introdução aos recursos do SGBD PostgreSQL, envolvendo características desse
SGBD, bem como sua instalação.
Foram apresentados comandos, classificados como DDL, para a criação e a alteração de tabelas. Em seguida,
conhecemos diversos comandos SQL para manipulação de linhas em tabelas. Tais comandos, classificados como DML,
são úteis para inserção, alteração e remoção de dados.
Finalizamos com uma breve contextualização a respeito do conceito, uso e importância das transações, com destaque
aos comandos do PostgreSQL utilizados para esse fim.
AVALIAÇÃO DO TEMA:
REFERÊNCIAS
DBEAVER COMMUNITY. Consultado em meio eletrônico em: 30 mai. 2020.
ELMASRI, R.; NAVATHE, S. Sistemas de Banco de Dados. 7. ed. São Paulo: Pearson, 2019.
MANZANO, J.A.M.G., Microsoft SQL Server 2016 Express Edition Interativo. 1. ed. São Paulo: Saraiva, 2017.
POSTGRESQL. PostgreSQL 12.3 Documentation. Consultado em meio eletrônico em: 30 mai. 2020.
POSTGRESQL. Create Table. Consultado em meio eletrônico em: 30 mai. 2020.
POSTGRESQL. Data Type. Consultado em meio eletrônico em: 30 mai. 2020.
POSTGRESQL. Delete. Consultado em meio eletrônico em: 30 mai. 2020.
POSTGRESQL. Download. Consultado em meio eletrônico em: 30 mai. 2020.
POSTGRESQL. Insert. Consultado em meio eletrônico em: 30 mai. 2020.
POSTGRESQL. Ubuntu. Consultado em meio eletrônico em: 30 mai. 2020.
POSTGRESQL. Update. Consultado em meio eletrônico em: 30 mai. 2020.
EXPLORE+
Para aprofundar seus conhecimentos sobre o assunto deste tema, leia:
CHAMBERLIN, D. D. Early History of SQL In: IEEE Annals of the History of Computing n 4, 2012. Como vimos, a linguagem
SQL tornou-se um padrão para uso em sistemas gerenciadores de bancos de dados relacionais. O artigo indicado é um
interessante material sobre a história da SQL.
CONTEUDISTA
Nathielly de Souza Campos
CURRÍCULO LATTES
DEFINIÇÃO
Consultas com expressões no comando SELECT. Consultas com o uso da cláusula WHERE. Agrupamento de dados.
PROPÓSITO
Saber construir comandos SQL com o uso de expressões no comando SELECT, bem como a especificação de condições
na cláusula WHERE, que representam tarefas importantes no projeto de consultas em sistemas gerenciadores de banco
de dados (SGBD). Para o desenvolvimento de relatórios e consultas analíticas, é fundamental saber trabalhar com
agrupamento de dados. Essas atividades são relacionadas ao dia a dia de programadores, analistas de sistemas e
desenvolvedores.
PREPARAÇÃO
Antes de iniciar o conteúdo deste tema, certifique-se de ter baixado e instalado o SGBD PostgreSQL em seu
computador.
OBJETIVOS
MÓDULO 1
Operar consultas com o comando SELECT
MÓDULO 2
Operar consultas usando a cláusula WHERE
MÓDULO 3
Operar consultas envolvendo agrupamento de dados
INTRODUÇÃO
Ao longo deste tema, vamos explorar diversos exemplos de consultas envolvendo uma tabela. Aprenderemos a codificar
consultas abrangendo tanto a recuperação de colunas da própria tabela quanto o uso de expressões no comando
SELECT. Quando projetamos um banco de dados para determinado domínio de negócio, em geral, são criadas diversas
tabelas que serão manipuladas pelas aplicações desenvolvidas para acessar os recursos do banco de dados.
Diversas operações que manipulam tabelas em um banco de dados necessariamente estão associadas a alguma
operação de consulta. Por exemplo, se resolvermos aumentar em 10% o salário de todos os funcionários que ganham
até R$ 4.000, será necessário programarmos um comando de consulta para que o sistema gerenciador de banco de
dados (SGBD) selecione os registros dos funcionários alvo da atualização. Assim, aprender de maneira efetiva a
programar consultas trará benefícios, tanto para atividades de construção de relatórios, quanto para o projeto de
operações de remoção e atualização de dados.
Clique aqui para baixar o arquivo com todos os códigos que serão utilizados nas consultas dos módulos a seguir.
MÓDULO 1
Operar consultas com o comando SELECT

ESTRUTURA BÁSICA DE UM COMANDO SELECT
O comando SELECT é usado para exibir dados resultantes de uma consulta. Os dados podem ser colunas físicas de uma
tabela, colunas calculadas ou mesmo resultado do uso de expressões e funções. Uma sintaxe básica para o comando
SELECT está expressa a seguir:
SELECT COLUNA1 [[AS] APELIDOCOLUNA1],
COLUNA2 [[AS] APELIDOCOLUNA2],
…
COLUNAN [[AS] APELIDOCOLUNAN]
FROM TABELA;
É importante ressaltar que estamos diante de uma sintaxe simplificada o suficiente para entendimento dos exemplos
que iremos explorar ao longo do módulo. A sintaxe completa abrange todos os recursos do PostgreSQL.
Uma sintaxe complexa envolve uma série de cláusulas e recursos bastante úteis para consultas de maior complexidade.
Na prática, o comando SELECT, dependendo da consulta desejada, pode ser usado de diferentes formas para obter o
mesmo resultado. É importante frisar que a cláusula SELECT realiza a operação de projeção da Álgebra Relacional.
Caso haja interesse em exibir todas as colunas especificadas em uma consulta, basta adicionar um “*”, conforme a
seguir: SELECT * FROM TABELA;
VOCÊ SABIA
Alguns SGBDs, como o PostgreSQL, implementam uma forma simplificada do comando SELECT * FROM TABELA, que é
simplesmente TABLE tabela (você pode testar isso no PostgreSQL).
Construiremos as consultas com base na tabela ALUNO, conforme figura a seguir:
Fonte: O autorTabela ALUNO.

Recomendamos que você crie a tabela e insira algumas linhas, o que pode ser feito usando o script a seguir, a partir da
ferramenta de sua preferência.
Para isso, tenha em mente que é necessário estar conectado ao PostgreSQL e acessando algum database criado por
você.
Fonte: O autor.
Vamos ver alguns exemplos de consultas?
CONSULTA 01
Exibir todas as informações dos alunos.
SELECT * FROM ALUNO;
A tabela a seguir apresenta os resultados da consulta.
Fonte: O autor.Resultados da consulta 01.

Ao executar a consulta, o SGBD percorre todos os registros da tabela ALUNO e exibe as colunas dessa tabela.
CONSULTA 02
Retornar o código, o nome e a data de nascimento de todos os alunos.
SELECT CODIGOALUNO, NOME, DTNASCIMENTO
FROM ALUNO;
Fonte: O autor.Resultados da consulta 02.

Na consulta 02, foram especificadas três colunas da tabela ALUNO para serem exibidas ao usuário.
Em especial, pode ser interessante “renomear” as colunas resultantes da consulta, visando tornar os resultados mais
“apresentáveis” ao usuário da aplicação. Por exemplo, a consulta 02 pode ser reescrita conforme a seguir:
SELECT CODIGOALUNO AS "Matrícula",
NOME AS "Nome do discente",
DTNASCIMENTO AS "Data de nascimento"
FROM ALUNO;,
O resultado dessa consulta seria este:
Fonte: O autorResultados da segunda versão da consulta 02.

É importante ressaltar que, na tabela anterior, o nome apresentado para cada coluna não existe fisicamente no banco
de dados.
Vamos aprender a seguir que nem toda coluna resultante de uma consulta representa necessariamente uma coluna de
alguma tabela.
FUNÇÕES DE DATA E HORA
Quando desenvolvemos consultas, é comum manipularmos colunas e funções que envolvem dados representativos de
datas.
Funções de data do PostgreSQL.
Um resumo contendo algumas funções de data do PostgreSQL pode ser visualizado na tabela a seguir:
Função O que retorna?

current_date data de hoje
current_time hora do dia
current_timestamp data e a hora
extract (campo from fonte) subcampos de data e hora: século, ano, d

Fonte: O autor.
Um quadro completo contendo informações sobre funções de data e hora pode ser encontrado na documentação
oficial do PostgreSQL.
Observe com atenção o código:
Fonte: O autor
Agora veja na tabela a seguir os resultados da consulta:
Fonte: O autor.Resultados da consulta envolvendo funções de data e hora.

Observe que utilizamos o qualificador AS “Apelido” para facilitar o entendimento do retorno de cada função. Note
também que não há cláusula FROM na consulta, visto que todas as colunas retornadas representam o resultado de
funções do PostgreSQL sem envolver qualquer tabela do domínio da aplicação.
ATENÇÃO
Convém ressaltar que, no padrão SQL, a cláusula FROM é obrigatória. No entanto, o PostgreSQL permite executar um
comando SELECT sem a cláusula FROM. Experimente executar SELECT 5+5;
EXIBINDO O NOME DO DIA DA SEMANA
Perceba que a linha 6 do código acima retorna um inteiro representativo do dia da semana. No entanto, se houver
necessidade de exibir o dia da semana, você pod

Idioma

Banco de Dados

Enviado por

Dados do documento

Título original

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Banco de Dados

Enviado por

Direitos autorais:

DEFINIÇÃO:Apresentação da evolução histórica dos bancos de dados, abordando as características dos sistemas de

A solidez da fundamentação matemática do modelo relacional

Fonte: Elaboração do autorFigura 1 – DER construído a partir dos

Fonte: Elaboração do autorFigura 2 – Esquema conceitual Escola na

Fonte: Elaboração do autorFigura 4 – Modelo físico do estudo de caso Escola.

Fonte: Elaboração do autorFigura 5 – Script DDL SQL compatível com o

Cada ocorrência do relacionamento ORIENTACAO vincula três ocorrências de

Tabela 1 – Propriedade de atributo de

DER com mecanismo de especialização/generalização fazendo uso das classificações parcial e compartilhada.

I. Todo funcionário está alocado em um departamento.

Fonte: Elaboração do autor.Figura 16 – DER associando disciplinas a cursos, sem relacionamento N:N.

Fonte: Elaboração do autor.Figura 17 – DER com entidade isolada IES.

Fonte: Elaboração do autor.Figura 18 – DER associando docente a departamento.

A partir das informações, é correto afirmar que:

Fonte: Elaboração do autor.Figura 28 – DER

Figura: Tabela ALUNO com destaque à coluna

Figura: Tabela DEPENDENTE com destaque às

UMA CHAVE ESTRANGEIRA É UMA

RESTRIÇÃO DE INTEGRIDADE REFERENCIAL

ESQUEMA TEXTUAL DE BANCO DE DADOS RELACIONAL

RELATÓRIOS DE ALOCAÇÃO DOCENTE A PROJETOS DE PESQUISA

De acordo com o relatório, nós podemos perceber que:

Nessa representação, a coluna

Ainda, de acordo com a representação textual, devemos perceber que:

Figura: Representação dos dados do relatório em tabelas na 1FN.

Fonte: AutorFigura: Representação das dependências parciais na tabela PROJETODOCENTE.

A figura a seguir representa o

Figura: Representação dos dados do relatório em tabelas em 2FN.

A figura a seguir representa o conteúdo das

Figura: Representação dos dados do relatório em tabelas na 3FN.

Fonte: AutorFigura: Diagrama de Entidade e Relacionamento (DER) contendo duas entidades.

Fonte: AutorFigura: Tabelas

Fonte: AutorFigura: DER contendo relacionamento 1:1 – ambas as entidades com participação opcional.

Figura: Tabela criada com base no mapeamento conceitual-lógico

Figura: Tabelas criadas com base no mapeamento conceitual-lógico

EXEMPLO DE MAPEAMENTO DE RELACIONAMENTO 1:N:

Fonte: AutorFigura: DER contendo relacionamento 1:N.

EXEMPLO DE MAPEAMENTO DE RELACIONAMENTO

Fonte: AutorFigura: DER parcial contendo relacionamento N:N.

OBSERVAÇÃO SOBRE ENTIDADE ASSOCIATIVA

Fonte: AutorFigura DER parcial contendo atributo multivalorado.

Fonte: AutorFigura: Tabelas

Fonte: AutorFigura: DER contendo especialização/generalização.

Figura: Tabela criada com base no mapeamento conceitual-

Convém ressaltar que a tabela OUTROSFUNCIONARIOS seria necessária somente se o mecanismo de

Modelo de entidade e relacionamento

Fonte: AutorFigura: Modelo de entidade

Essa consulta demorou 2,5 segundos para ser executada.

Adicionaremos chave primária à tabela DM_DOCENTE_2, escolhendo a

Fonte: AutorFigura: Tabelas NIVEL e CURSO.

O SGBD precisa avaliar se há algum registro na tabela CURSO cujo

A relação entre as tabelas está

A primeira linha do comando serve para

ATENÇÃO:O processo de desnormalização deve ser planejado com critério, visto

Processo servidor, responsável por funções, tais como:

Gerenciar os arquivos do banco de dados

Aplicativo cliente do usuário, responsável por funções, tais como:

Solicitar acesso ao SGBD

 Atenção! Para visualização completa da tabela utilize a rolagem horizontal

Fonte: Software de instalação do PostgreSQL para WindowsTela de definição do diretório de instalação.

Fonte: Software de instalação do PostgreSQL para WindowsTela de seleção de componentes a instalar.

database BDTESTEPGADMIN, a ser criado usando o pgAdmin 4.

database BDTESTEPSQL, a ser criado usando o psql

 Atenção! Para visualização completa da tabela utilize a rolagem horizontal

Fonte: Software psqlTela do psql após criação do database BDTESTEPSQL.