Apostila - Banco de Dados

Prévia do material em texto

BANCO DE DADOS 
AULA 1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Prof. Lucas Rafael Filipak 
 
 
2 
CONVERSA INICIAL 
Segue a apresentação da aula com a estrutura de contéudos que foram 
trabalhados os seguintes tópicos: 
1. Perspectiva histórica sobre banco de dados; 
2. Classificação de banco de dados; 
3. Sistema gerenciador de banco de dados (SGBD); 
4. Aspectos de modelagem de dados. 
 O objetivo desta aula é fazer um levantamento histórico, trazer as 
definições de bancos de dados e dos sistemas de gerenciamento de banco de 
dados (SGBDs), explicar a importância da utilização de um SGBDs e como era na 
sua ausência, identificar os conceitos de dados e informações que são de extrema 
importância para as aulas de banco de dados e, por fim, explanar como se dá a 
construção e a modelagem de um banco de dados, finalizando o capítulo com o 
modelo conceitual. 
TEMA 1 – PERSPECTIVA HISTÓRICA SOBRE BANCOS DE DADOS 
1.1 Banco de dados 
Entende-se que banco de dados é a armazenagem dos dados, manual ou 
computadorizada, de maneira organizada, que atenda às necessidades de um 
usuário, possibilitando a consulta e a manipulação dos dados. 
Turban, Rainer Júnior e Potter (2005, p. 523) conceituam banco de dados 
como um grupo lógico de arquivos relacionados entre si, armazenando dados e 
associações entre eles, para evitar uma variedade de problemas associados a um 
ambiente tradicional de arquivos. 
Medeiros (2013, p. 15) define “banco de dados (ou, abreviadamente, BD) 
como sendo um conjunto de dados com certa organização característica, com o 
objetivo de armazenamento persistente dos dados e dotado de mecanismos de 
manipulação para obtenção de informações e recuperação posterior, dentro de 
um sistema de informação”. 
O surgimento dos bancos de dados veio com a necessidade do homem de 
deixar registrado (armazenar) dados que, sempre que era preciso, pudessem ser 
consultados posteriormente. Os primeiros bancos de dados reconhecidos são as 
pinturas pré-históricas, os hieróglifos egípcios e assim por diante. Essas técnicas 
 
 
3 
são consideradas banco de dados, pois podiam armazenar e oferecer consulta 
dos dados. 
Figura 1 – Pintura rupestre 
 
Fonte: França, 2017. 
Outro exemplo encontra-se há cerca de 10.000 a.C. Com o surgimento dos 
primeiros rebanhos, os pastores de ovelhas precisavam controlar o número de 
animais para saber principalmente se não faltavam ovelhas (perdidas ou mortas 
por predadores) ou se outras se juntaram ao seu rebanho. 
Vestígios encontrados indicam que os pastores tinham algumas técnicas 
para fazer o controle de seu rebanho. 
Figura 2 – Ferramentas utilizadas na contagem dos animais 
 
Fonte: Augusto, 2012. 
A mais utilizada era o conjunto de pedras. Quando o pastor soltava as 
ovelhas, ele separava uma pedra para cada animal que passava pela porteira e 
guardava as pedras em um monte ou em um saco. Ao final do dia, quando os 
 
 
4 
animais voltavam, o pastor retirava do monte (ou do saco) uma pedra para cada 
animal que passava. Depois de a última ovelha passar, o pastor sabia que: 
 Se sobrassem pedras, ele tinha perdido alguma ovelha; 
 Se faltassem pedras, o rebanho tinha aumentado. 
O monte de pedras ou o saco com uma ligação do tipo “para cada ovelha, 
uma pedra” era o banco de dados do pastor. A mesma técnica foi utilizada para 
os nós nas cordas e para os riscos feitos em pedaços de ossos. 
Os bancos podem ser manuais ou computadorizados. Os primeiros bancos 
de dados foram os manuais e, como exemplo, pode-se citar a ficha do dentista, 
que armazena os dados pessoais de cada paciente em uma ficha de papel. Com 
o aumento da utilização das fichas (volume maior de papel), foi necessário criar 
técnicas e ferramentas para tornar o processo de identificar um paciente mais 
rápido. Para isso, foi inventado o fichário, que permitia o usuário a organizar as 
fichas de papel em ordem alfabética, facilitando a consulta. 
Figura 3 – Ficha de registro e fichário 
 
Fonte: Alves, 2014, p. 17. 
Outras formas de armazenamento de dados foram aparecendo. Um 
exemplo é a impressão por meio da tipografia que, a partir do século XV, permitiu 
armazenar os dados em livros, gerando grandes bancos de dados “físicos”, as 
bibliotecas, onde existem diversos dados e informações que podem ser 
consultados por outros usuários. Outro exemplo é a lista telefônica, que armazena 
o nome e o telefone da pessoa, organizada em ordem alfabética. 
Com a evolução das tecnologias, surgiram os bancos de dados 
computacionais. O primeiro banco de dados utilizava fita de papel perfurada, que 
mais tarde foi substituída pelo cartão perfurado. 
 
 
 
5 
Figura 4 – Cartão perfurado 
 
Fonte: Balanced..., 2010. 
A informação perfurada no cartão era lida numa tabuladora que dispunha 
de uma estação de leitura equipada com uma espécie de pente metálico em que 
cada dente estava conectado a um circuito elétrico. Herman Hollerith foi o 
responsável por desenvolver esses dois sistemas e, em 1889, construiu máquinas 
sob encomenda para o United States Census Bureau, que ajudaram a processar 
o censo de 1890 da população americana. Em 1924, a empresa de Hollerith teve 
seu nome alterado para International Business Machines (IBM). 
Com o aumento da utilização dos bancos de dados computacionais, 
apareceram diversos questionamentos que precisavam ser resolvidos. Os 
primeiros bancos eram sequenciais, não permitindo mais de um processo, ao 
mesmo tempo, no mesmo arquivo. A redundância, a inconsistência e os 
problemas de segurança nos dados geraram grandes desafios para as empresas 
desenvolvedoras. Os bancos de dados computadorizados são armazenados em 
estruturas organizadas e implementadas em um software e geralmente utilizam 
outro software (Sistema Gerenciador de Banco de Dados) para fazer o 
gerenciamento dos dados. 
Figura 5 – Sistemas orientados a arquivos 
 
Fonte: Alves, 2014, p.14. 
 
 
6 
A Figura 5 representa a estrutura dos primeiros bancos de dados 
computacionais, que utilizavam arquivos para seu armazenamento. Observando 
a figura, podemos concluir que os dados do departamento de vendas não se 
comunicavam com os dados do departamento de finanças. Em outras palavras, 
os arquivos não tinham relação um com o outro, pois eram somente depósito de 
dados. 
Cada aplicação deveria deixar de ter o seu próprio repositório de dados. 
Mas como isso poderia ser feito se cada aplicação é quem gerenciava a gravação 
e consulta dos dados? O próximo passo importante foi o desenvolvimento de uma 
ferramenta para gerenciar todas as transações realizadas entre os aplicativos e o 
banco de dados. Essa ferramenta ficou conhecida como Sistema Gerenciador de 
Banco de Dados (SGBD). 
Figura 6 – Arquitetura de um sistema aplicativo que faz uso de banco de dados 
 
Fonte: Alves, 2014, p. 15. 
A Figura 6 ilustra onde o SGBD fica posicionado na arquitetura do sistema. 
Uma das grandes evoluções na implantação do SGBD foi que mais de um 
aplicativo pode acessar o mesmo banco de dados. O aplicativo não tem maiores 
informações sobre como os dados são gravados ou a estrutura geral do banco de 
dados. Simplesmente ele requisita ao SGBD para armazenar ou recuperar 
registros. Para Alves (2014, p. 13), 
Programas de banco de dados talvez sejam os mais antigos já 
desenvolvidos para computadores. Antes do desenvolvimento desse tipo 
de software aplicativo, os programas trabalhavam com arquivos 
sequenciais, utilizando os recursos disponíveis no sistema operacional 
para gravação e leitura dos dados em disco. 
 
 
7 
TEMA 2 – CLASSIFICAÇÃO DOS BANCOS DE DADOSOs bancos de dados podem ser classificados quanto ao modelo de dados 
em que se baseiam. Serão apresentados 4 diferentes tipos de banco de dados 
baseados em modelos de dados hierárquicos, em dados relacionais, orientados a 
objetos e dados de rede. 
O primeiro banco de dados criado utilizava o modelo hierárquico e utilizava 
a organização do endereço físico na sua estrutura de dados. Para Elmasri e 
Navathe (2011, p. 35), “o modelo hierárquico representa os dados como estruturas 
de árvores hierárquicas. Cada hierarquia simboliza uma série de registros 
relacionados.“. 
Figura 7 – Modelo hierárquico 
 
Fonte: Alves, 2014, p. 23. 
 A primeira impressão que se tem ao visualizar o bando de dados modelo 
de rede é que ele se parece com o modelo hierárquico. Segundo Elmasri e 
Navathe (2011, p. 34), 
o modelo de rede representa dados como tipos de registro e também 
representa um tipo limitado de relacionamento 1:N, chamado tipo de 
conjunto. Um relacionamento 1:N, ou um para muitos, relaciona uma 
instância de um registro a muitas instâncias de registros usando algum 
mecanismo de ligação com ponteiros nesses modelos. 
Um ponto importante é que se pode acessar um registro direto, diferente 
do modelo hierárquico, que deve iniciar sempre pela raiz. 
 
 
 
8 
Figura 8 – Modelo dados de rede 
 
Fonte: Alves, 2014, p. 23. 
Para Alves (2014, p. 23), “Tecnicamente pode-se dizer que o registro 
proprietário possui um ponteiro que ‘aponta’ para um registro membro. Esse 
registro, que é o primeiro do conjunto, ‘aponta’ para outros que também se 
relacionam com o mesmo registro proprietário, como numa lista encadeada.”. 
Os bancos de dados relacionais são utilizados, atualmente, na maioria dos 
sistemas. Segundo Alves (2014, p. 19), “Um banco de dados relacional se 
caracteriza pelo fato de organizar os dados em tabelas (ou relações), formadas 
por linhas e colunas. Assim, essas tabelas são similares a conjuntos de elementos 
ou objetos, uma vez que relacionam as informações referentes a um mesmo 
assunto de modo organizado”. Uma tabela também pode se relacionar com uma 
ou mais tabelas, por meio de colunas comuns em ambas. 
Figura 9 – Tabelas de um banco de dados relacional 
 
 
 
 
9 
 
Fonte: Alves, 2014, p. 20. 
Na figura 9, note que a tabela Produtos tem uma coluna “Codigo Categoria” 
que se relaciona com a tabela Categorias. E uma coluna “Codigo Fornecedor” que 
se relaciona com a tabela Fornecedores. 
 Os bancos de dados orientados a objetos também utilizam tabelas, mas 
não se limitam a elas. Para Elmasri e Navathe (2011, p. 34), 
o modelo de dados de objeto define um banco de dados em termos de 
objetos, suas propriedades e operações. Os objetos com a mesma 
estrutura e comportamento pertencem a uma classe, e as classes são 
organizadas em hierarquias (ou grafos acíclicos). As operações de cada 
classe são especificadas com procedimentos predefinidos, chamados 
métodos. 
Os bancos de dados objetos surgiram na década de 80 para suprir uma 
demanda de armazenamento que não era possível nos sistemas relacionais. 
Alves (2014) cita como exemplo os sistemas de geoprocessamento [Sistemas de 
Informações Geográficas (SIG)] e CAD/CAM/CAE, que são baseados em tipos de 
dados complexos. 
2.1 Dados versus informações 
Quando foi explanada a história e a evolução dos bancos de dados, falou-
se sobre dados e informações. À primeira vista, essas duas palavras parecem 
sinônimos, mas na verdade não são! Para continuar a explicação sobre banco de 
dados, esses dois conceitos precisam estar bem definidos. 
 Dados  são fatos brutos, em sua forma primária. E muitas vezes os dados 
podem não fazer sentido sozinhos; 
 Informações  consistem no agrupamento de dados de forma organizada 
para fazer sentido, gerar conhecimento. 
Para Puga, França e Goya (2013), a definição de dados é uma coletânea 
de símbolos organizados intencionalmente para representar uma parte da 
realidade tratada. Para compreender melhor, considere como exemplo: 
 
 
10 
Nome: João da Silva 
Idade: 30 
João da Silva e 30 são dados sobre uma pessoa, que podem ser 
armazenados em um banco de dados e utilizados para gerar informações. 
Os dados podem ser usados para aumentar o conhecimento de alguém a 
respeito de um assunto ou situação. Ainda segundo os mesmos autores (Puga, 
França e Goya, 2013), a informação representa um conjunto de dados associados 
a um contexto, de maneira que seja possível interpretá-la. Considerando os dados 
do exemplo anterior, temos a seguinte informação: João da Silva completou 30 
anos no mês de abril. 
TEMA 3 – SISTEMA GERENCIADOR DE BANCO DE DADOS (SGBD) 
A informação muitas vezes é o bem mais valioso de uma empresa, por isso 
ter um acesso rápido e seguro a ele é primordial. Um sistema gerenciador de 
banco de dados (SGBD) é o software utilizado para gerir as bases de dados, 
proporcionando um ambiente conveniente e eficiente para armazenar e recuperar 
os dados. Tudo o que é feito em um banco de dados passa por um SGBD. É 
comum as pessoas confundirem um SGBD com banco de dados, por exemplo: 
banco de dados Oracle, banco de dados MySQL etc. Na verdade, esses são os 
SGBDs. O correto é chamá-los de SGBD Oracle, SGBD MySQL etc. 
Nos SGBDs é definida a estrutura de armazenamento e o mecanismo de 
manipulação dos dados, garantindo a segurança das informações. Os SGBDs 
controlam os dados que são armazenados nos bancos de dados. 
3.1 História dos SGBDs 
Os SGBDs não pararam de evoluir. A rapidez de acesso às informações, o 
tamanho e local do armazenamento são fatores importantes que afetam na 
escolha do SGBD. Para facilitar a visualização e o entendimento, foram 
organizadas as informações sobre a evolução dos SGBDs e fatos importantes na 
evolução dos bancos de dados em uma tabela: 
 
 
 
11 
Tabela 1 – Evolução dos SGBDs e os banco de dados 
1960 
Charles Bachman 
(General Electric) 
Projetou o primeiro SGBD, o de depósito de dados integrados 
(Integrated Data Store). 
Final de 1960 IBM 
SGBD Sistema de gerenciamento de informações (IMS – Information 
Management System). Utilizava o modelo hierárquico e permitia acesso 
multiusuário através de uma rede. 
1970 
Edgar Codd (IBM) 
Desenvolveu o banco de dados relacional, sendo um divisor de águas 
dos SGBD. 
1976 
Peter Chen 
Criou o modelo de entidade e relacionamento (MER). 
1974 – 1979 
Projeto System R 
(IBM) 
Criou a linguagem SQL para banco de dados relacional, passando a ser 
a linguagem padrão de consulta. A SQL foi padronizada no final dos 
anos 80 e foi adotado pelo American National Standards Institute (ANSI) 
e pela International Organization for Standardization (ISO). 
1990 
Os avanços da década de 90 foram concentrados na velocidade e poder 
das consultas e modelos de dados mais ricos, suportando análises mais 
complexas provenientes de todas as áreas da empresa. 
Era da Internet 
A internet forçou os fabricantes a acrescentar recursos nos SGBDs. A 
primeira geração de sites armazenavam seus dados em arquivos dos 
sistemas operacionais, mas agora existe a interação e a utilização de 
formulários como interface com o usuário, cujo navegador gera uma 
resposta formatada, geralmente em HTML. 
Hoje 
O que impulsiona hoje são as muitas ideias diferentes. Entre elas temos: 
banco de dados multimídia, vídeo interativo, fluxos de dados, bibliotecas 
digitais, etc. Além do desejo das empresas em minerar seus repositórios 
de dados por informações úteis sobre seus negócios. 
Agora que está claro como ocorreu o surgimento dos bancos de dados e a 
evolução dos SGBDs, será estudado como é feita a projeção de um banco de 
dados.Dentro do ciclo de desenvolvimento de um sistema de informação, existe 
a modelagem de dados, que é uma técnica usada para especificar as regras de 
negócios e as estruturas de dados de um banco de dados. Modelar consiste em 
desenhar o sistema como um todo, concentrando-se nas entidades lógicas e nas 
dependências lógicas entre essas entidades. A modelagem é descrita em três 
níveis de abstração. A descrição do banco de dados consiste em um esquema em 
cada um desses três níveis de abstração. 
Você já deve ter ouvido falar de alguns conceitos como: 
modelo/esquema conceitual, lógico, interno, externo, nível de visão. Isso ocorre, 
pois a teoria de banco de dados foi construída paralelamente por diferentes 
autores. Para explicar os diferentes níveis de abstração em que a modelagem de 
dados é realizada, serão utilizados os termos conforme apresentado na Figura 10. 
 
 
 
 
12 
Figura 10 – Níveis de abstração em um modelo de dados 
 
Fonte: Ramakrishnan; Gehrke, 2008, p. 10. 
3.2 Esquema conceitual 
Descreve os a estrutura do banco de dados. Para Elmasri e Navathe (2011, 
p. 22), “o esquema conceitual oculta os detalhes das estruturas de 
armazenamento físico e se concentra na descrição de entidades, tipos de dados, 
relacionamentos, operações do usuário e restrições”. Como exemplo, será 
apresentado a seguir o esquema conceitual de uma escola, em que as entidades 
possuem relações e essas relações contêm informações sobre entidades, como 
alunos e professores, e sobre relacionamentos, como a matrícula dos alunos nos 
cursos. 
Alunos(cod_aluno: string, nome: string, login: string, idade: integer) 
Professores(cod_prof: string, nome_professor: string, sal: real) 
Cursos(cod_curso: string, nome_curso: string, créditos: integer) 
Matriculado(cod_aluno: string, cod_curso: string, nota: string) 
Ministra(cod_prof: string, cod_curso: string) 
O exemplo contempla cinco entidades (alunos, professores, cursos, 
matriculado e ministra). Note que na entidade Matriculado é feita a relação com 
outras duas entidades, por meio da citação dos atributos das entidades: Alunos 
(coluna cod_aluno) e Cursos (coluna cod_curso). 
O processo de produzir um esquema conceitual é chamado de projeto 
conceitual de banco de dados. 
 
 
 
13 
3.3 Esquema físico 
O esquema físico é, essencialmente, a leitura do esquema conceitual e 
como realmente é feito o armazenamento no banco de dados. No esquema físico, 
é escolhido o SGBD e são detalhados os componentes da estrutura física do 
banco de dados, como: 
 Tabelas; 
 Colunas; 
 Tipos e tamanho dos dados; 
 Índices. 
No estágio do esquema físico, o banco de dados está pronto para ser 
criado. Segundo Puga, França e Goya (2013, p. 81), 
O modelo físico, ao ser implementado, relaciona-se com diversos 
sistemas ou aplicações que necessitam de dados. Por exemplo, em um 
site de comércio eletrônico, quando um cliente faz uma busca on-line por 
determinado produto, os programas de aplicação (site) acessam ao 
banco de dados para realizar uma consulta e responder a solicitação do 
usuário. Um banco de dados pode estar relacionado a diversas 
aplicações externas, isto é, não fazem parte do projeto do banco de 
dados, mas fazem uso dele. 
3.4 Esquema externo 
É a customização do acesso aos dados, no nível dos usuários individuais 
ou em grupos. Todos os bancos de dados têm apenas um esquema conceitual e 
um esquema físico, pois há apenas um conjunto de relações armazenadas, mas 
pode haver diversos esquemas externos, adaptados a grupos de usuários 
distintos. 
O projeto do esquema externo é orientado pelos requisitos do usuário final. 
Por exemplo, pode-se permitir que os alunos localizem os nomes dos professores 
que ministram cursos, assim como as matriculas no curso. Isso pode ser feito 
definindo a seguinte visão: 
InfoCurso(id-curso: string, nomep: string, matriculados: integer) 
Não foi incluído InfoCurso no esquema conceitual porque é possível 
processar InfoCurso com base nas relações do esquema conceitual e, além disso, 
armazená-la seria redundante. 
 
 
14 
Existem diversos tipos de gerenciamento de banco de dados, e a escolha 
depende de quais os recursos que o SGBD suporta de forma eficiente. Para sua 
utilização plena, é preciso saber como ele funciona. 
TEMA 4 – ASPECTOS DE MODELAGEM DE DADOS 
A modelagem dos dados é o planejamento da execução das ideias do 
negócio para os termos computacionais. O exemplo agora é de uma viagem. O 
planejamento de uma viagem começa com a escolha do destino, do hotel, dos 
passeios, dos restaurantes. E tudo isso tem que estar de acordo com a duração e 
o valor proposto a investir na viagem. Se houver falha no planejamento, haverá 
consequências que podem ser desde deixar de fazer algum passeio (pois o tempo 
de viagem não foi o suficiente ou por desorganização) ou não ter dinheiro 
suficiente para aproveitar a viagem. 
Um dos momentos mais críticos no processo de desenvolvimento de um 
software é a modelagem de banco de dados. Nessa fase, deve-se entender 
precisamente a necessidade do requisitante, para que o produto final atinja os 
objetivos estabelecidos por ele. Com a modelagem de dados, é possível refinar 
um modelo conceitual durante as fases que compõem o projeto, eliminando 
redundâncias ou incoerências que possam inevitavelmente surgir. 
Sem o planejamento adequado, a manutenção do sistema também fica 
mais complicada e recorrente. A seguir, detalham-se os passos fundamentais no 
processo da modelagem dos dados. 
4.1 Análise de requisito 
Os requisitos são as necessidades estabelecidas pelo cliente para definir, 
antes do desenvolvimento, a estrutura e as ações de um software. A análise de 
requisitos é destinada a entender a regra do negócio, como a empresa trabalha, 
como os usuários pretendem utilizar o sistema e qual é o objetivo principal do 
sistema. Os requisitos vão desde quais são os usuários que vão utilizar o software, 
quais os processos até qual o sistema operacional que o software vai funcionar. 
A análise de requisitos é utilizada na engenharia de software, mas se torna 
importante na criação do banco de dados, pois é na análise de requisitos que o 
cliente vai informar quais os dados que o sistema (banco) vai receber e armazenar 
e quais as informações o usuário quer que o sistema retorne para ele. 
 
 
15 
Para que essa etapa seja realizada com sucesso, é importante a 
participação do cliente, dos futuros usuários e do profissional de informática que 
vai identificar se os requisitos são viáveis de serem implementados. 
4.2 Modelo conceitual 
Considerado um modelo de representação, o modelo conceitual procura 
desenhar as relações entre as diversas áreas ou usuários do sistema. 
A construção do projeto conceitual normalmente é conduzida utilizando o 
modelo entidade-relacionamento (ER). O modelo ER é um dos diversos modelos 
de dados semânticos, ou de alto nível, onde há uma descrição simples dos dados 
que melhor corresponda à ideia que os desenvolvedores e os usuários têm em 
relação aos dados. A representação por meio desses componentes permite que 
a regra de negócio se module ao formato de um projeto de banco de dados. 
O modelo conceitual de dados é o primeiro modelo que deve ser 
desenvolvido, preferencialmente na fase de levantamento de requisitos. É 
considerado um modelo de dados de alto nível, e seu principal objetivo é capturar 
os requisitos de informação e regras de negócio sob o ponto de vista do negócio. 
Esse modelo não depende dos fatores tecnológicos e fatores de projeto em sua 
construção. Entre os componentes de um modelo conceitual, pode-se relacionar: 
entidades, atributos e relacionamentos.Segundo Puga, França e Goya (2013, p. 79), o modelo conceitual de dados 
tem as seguintes funções: 
 Entender o funcionamento de processos e regras do negócio; 
 Expressar as necessidades de informações da empresa como um todo; 
 Facilitar a comunicação entre áreas usuárias e de tecnologia da informação 
(TI); 
 Definir abrangência do sistema, delimitando o escopo do sistema e 
estimando custos e prazos para elaboração do projeto; 
 Avaliar soluções de softwares, no momento da aquisição, por meio da 
comparação entre o que a solução pode oferecer e a visão do modelo de 
dados conceitual; 
 Permitir estruturar os dados com flexibilidade. 
Figura 11 – Diagrama de entidade-relacionamento 
 
 
16 
 
 
A Figura 11 é um exemplo de modelo conceitual, em que é possível ver, 
por meio do diagrama de entidade-relacionamento, a representação de duas 
entidades (Clientes e Produtos). Essas duas entidades possuem ainda um 
relacionamento indicando que um cliente pode comprar um ou mais produtos. 
Nesse diagrama, também existe a representação dos atributos que caracterizam 
essas entidades. A entidade Cliente possui o atributo codigo como identificador, 
nome e dt_nasc como atributos simples, idade como atributo derivado e telefone 
como atributo multivalorado. A entidade Produtos possui o atributo codigo como 
atributo identificador, descricao e preco como atributos simples. 
FINALIZANDO 
Nesta aula foram explanados os conceitos sobre banco de dados e sobre 
os sistemas de gerenciamento de banco de dados. Com o passar dos anos, as 
estruturas de armazenamento que deram origem ao banco de dados passaram 
por mudanças em que foram desenvolvidas diferentes estruturas para 
armazenamento, cada vez mais eficientes. Foi possível observar a trajetória 
histórica dos SGBDs, que, além da função de armazenar dados de forma 
organizada, permite que múltiplas aplicações acessassem um mesmo banco, com 
diferentes tipos de perfis, tudo ao mesmo tempo. Neste capítulo também se iniciou 
o entendimento de como funciona a modelagem dos dados, análise de requisitos 
e diagrama conceitual. 
 
 
 
17 
REFERÊNCIAS 
ALVES, W. P. Banco de dados. 1. ed. São Paulo: Érica, 2014. 
AUGUSTO, R. Um pouco da história dos números. Educação curiosa, 27 maio 
2012. Disponível em: <https://educacaocuriosa.wordpress.com/2012/05/27/um-
pouco-da-historia-dos-numeros/>. Acesso em: 12 jun. 2018 
BALANCED line pattern. Antonio Jr. Blog, 4 dez. 2010. Disponível em: 
<https://agcjunior.wordpress.com/author/agcjunior/>. Acesso em; 12 jun. 2018. 
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. Tradução de 
Daniel Vieira; revisão técnica de Enzo Seraphin e Thatyana de Faria Piola 
Seraphim. 6. ed. São Paulo: Pearson Addison Wesley, 2011. 
FRANÇA, F. Linhas de pesquisa da Serra da Capivara. Panorama Cultural, 1 
ago. 2017. Disponível em: <http://panoramacultural.com.br/linhas-de-pesquisa-
da-serra-da-capivara/>. Acesso em: 12 jun. 2018. 
MEDEIROS, L. F. de. Banco de dados: princípios e prática. Curitiba. 
Intersaberes, 2013. 
PUGA, S.; FRANÇA, E.; GOYA, M. Banco de dados: implementação em SQL, 
PL/SQL e Oracle 11g. São Paulo: Pearson Education do Brasil, 2013. 
RAMAKRISHNAN, R.; GEHRKE, J. Sistemas de gerenciamento de banco de 
dados. São Paulo McGraw Hill, 2008. 
TURBAN, E.; RAINER JUNIOR, R. K.; POTTER, R. E. Administração de 
tecnologia de informação. Rio de Janeiro. Campus, 2005. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
BANCO DE DADOS 
AULA 2 
 
 
 
 
 
 
 
 
 
 
 
 
 
Prof. Lucas Rafael Filipak 
 
 
2 
CONVERSA INICIAL 
 O objetivo da aula 2 é compreender o funcionamento do modelo de 
entidade e relacionamento. A ideia é conceitualizar e exemplificar o que seja 
entidade, atributo, relacionamento e cardinalidade e desenvolver um passo a 
passo de um estudo de caso da modelagem de um diagrama de entidade e 
relacionamento (DER). Além disso, pretende-se finalizar a modelagem dos 
dados com o modelo físico e o modelo lógico, dando uma visão geral e 
abrangente da utilização dos três modelos. A aula termina com um estudo de 
caso transformando o modelo ER em modelo relacional. 
TEMA 1 – MODELO ENTIDADE E RELACIONAMENTO: ENTIDADE, 
ATRIBUTO E RELACIONAMENTO 
O conceito do modelo de entidade e relacionamento (MER) foi proposto 
por Peter Chen, nos anos de 1970, e tem como base a perspectiva do mundo 
real como construído por dois grupos de objetos que formam um negócio: 
entidades e relacionamentos. 
O MER é extremamente útil para mapear, com base em um esquema 
conceitual, o significado e as interações das empresas reais (Silberschatz; Korth; 
Sudarshan, 1999). 
Em 1976, Chen desenvolveu uma técnica de diagramação capaz de 
representar o modelo de dados de forma abrangente, o qual ficou conhecido 
como diagrama de entidade e relacionamento (DER). 
Alves (2014, p. 91) diz que as entidades e os relacionamentos possuem 
uma ligação tão forte que não é possível tratar de um sem mencionar o outro. O 
que une esses dois componentes é uma ação. É como uma oração formada por 
um sujeito (entidade), um verbo (ação) e um predicado (relacionamento). 
Figura 1 – Componentes de uma entidade-relacionamento 
 
Fonte: Alves, 2014, p. 92. 
 
 
3 
1.1 Entidade 
Uma entidade é o objeto básico representado no modelo ER. É uma 
categoria de elementos relevantes para um negócio, podendo ser, por exemplo, 
clientes, fornecedores, vendas, pagamentos, entre outros, sobre os quais são 
realizadas operações para o funcionamento do negócio. Segundo Puga, França 
e Goya (2013, p. 84), a entidade pode ser caracterizada como: 
 Objeto ou fato que deve ter seus dados guardados em um determinado 
contexto; 
 Conjunto de tipo de informação que seja diretamente associado ao 
domínio de conhecimento analisado; 
 Objeto que desempenha um papel específico no sistema; 
 Objeto que possui propriedades que o distinguem de outras entidades, 
podendo ser: 
 Objeto concreto: computador, impressora, veículo, produto, imóvel, 
etc.; 
 Pessoa: funcionário, cliente, aluno, professor, atendente etc.; 
 Evento: situação em que algo está ocorrendo, ou está planejado para 
ocorrer. Por exemplo, o agendamento de uma corrida de táxi, o 
recebimento de uma encomenda etc. 
A representação de uma entidade em um modelo entidade-
relacionamento (modelo ER) se dá por um retângulo com o nome da entidade 
escrito dentro. As entidades podem ser classificadas em: entidades fortes e 
entidades fracas. 
Figura 2 – Notação para representação de entidade forte e entidade fraca 
 
O que diferencia uma entidade forte de uma entidade fraca é o grau de 
dependência de existência delas. A entidade empregado, na Figura 2, não 
depende de nenhuma outra entidade para existir, por isso é uma entidade forte. 
 
 
4 
As entidades fracas possuem dependência de existência e/ou 
identificação e são sempre ligadas a outras tabelas por meio de 
relacionamentos. Tome-se como exemplo a entidade dependente, cuja 
existência e identificação está vinculada a outra entidade forte, no caso o 
empregado. 
1.2 Atributo 
Os atributos descrevem as características de uma entidade, podendo ser 
definidos, segundo Puga, França e Goya (2013, p. 86) como: 
 Informações associadas a uma entidade; 
 Características ou propriedades de uma entidade ou relacionamento; 
 Descrição, identificação, qualificação ou quantificação de uma entidade. 
Entre os exemplos de atributos presentes no modelo ER criado na 
explicação do esquema conceitual, podem-se citar: 
 Nome do funcionário; 
 Matrícula do funcionário; 
 Ano defabricação do veículo. 
Os atributos são identificados por símbolos, como demonstrado na Figura 
3, que são conectados em entidades. Seguindo a notação de Peter Chen, os 
atributos podem ser: 
Figura 3 – Notação dos atributos – Peter Chen 
 
 Atributo identificador: permite representar uma identificação única de 
uma ocorrência em uma entidade. Uma entidade pode possuir mais de 
um atributo identificador, mas a composição dos atributos deve formar 
uma identificação única; 
 Atributo não identificado (ou chamado apenas de atributo): 
corresponde à maioria dos atributos de uma entidade. Os atributos não 
identificados poderão conter valores nulos; 
 
 
5 
 Atributo multivalorado: são utilizados para representar os atributos que 
podem ter mais de uma ocorrência em uma mesma instância de uma 
entidade. Como exemplo, pode-se pensar num número de telefone. É 
comum que uma pessoa possua mais de um número de telefone, portanto 
para esta representação utiliza-se o atributo multivalorado; 
 Atributos derivado: às vezes, um atributo está relacionado com outro 
atributo, por exemplo, a idade e data de nascimento de um cliente. Pode-
se determinar a sua idade por meio da data de nascimento e da data 
atual. Atributos como a idade são chamados de atributos derivados. 
A Figura 4 exemplifica os tipos de atributos utilizados em um DER. 
Figura 4 – Exemplos de atributos 
 
Na Figura 4, a entidade Empregado tem o atributo codigo como atributo 
identificador (e único para cada pessoa). O nome e nasc são atributos não 
identificados (podendo existir nomes e data de nascimento iguais). O atributo 
telefone é um atributo multivalorado (pois o empregado pode possuir mais de um 
telefone) e o atributo idade é um atributo derivado do atributo nasc. 
1.3 Relacionamento 
O relacionamento estabelece uma relação ou associação entre as 
entidades, com um significado específico do mundo real. Da mesma maneira 
ocorre no mundo real, onde os objetos não ocorrem de maneira isolada, mas sim 
se associam ou se vinculam com outros objetos. No modelo ER, os 
relacionamentos são representados por um losango que relaciona as entidades, 
podendo ser classificados como relacionamentos fortes ou fracos. Tal como as 
 
 
6 
entidades, os relacionamentos também possuem um nome e devem expressar o 
real significado dentro do contexto modelado. 
Há autores que utilizam outra simbologia para representar uma relação. 
Esse material utiliza a notação de Peter Chen, que utiliza o losango para 
representar uma relação. 
A Figura 5 representa o seguinte cenário: considere que um Empregado 
tem um Cargo e que este cargo é uma classificação interna dada pela empresa. 
Porteiro, auxiliar administrativo, gerente, entre outros são exemplos de cargos. 
Um Empregado pode ou não ter Dependente. 
Figura 5 – Notação que representa o relacionamento forte e o relacionamento 
fraco 
 
Na Figura 5, a entidade Dependente é uma entidade fraca. Sempre que 
existe uma relação entre duas entidades e uma delas é uma entidade fraca, o 
relacionamento entre as duas será fraco também. No outro relacionamento, 
também representado na Figura 5, o relacionamento possui é representado por 
um relacionamento forte, pelo fato de não haver dependência de existência ou 
identificação, pois um empregado não depende do seu cargo para existir ou ser 
identificado e vice-versa. Observe os seguintes questionamentos: 
 Um empregado pode não ter dependentes? 
 Um dependente pode ter mais de um empregado associado? 
 
 
7 
 Determinado empregado pode possuir mais de um dependente? 
 Pode existir dependente sem algum empregado associado? 
Note que pode haver respostas diferentes para essas perguntas e que 
cada resposta depende do problema que está sendo modelado. Entretanto, para 
que se possam expressar essas ideias no modelo, é necessário definir uma 
propriedade importante do relacionamento: a cardinalidade, a qual será tratada 
na próxima seção. 
TEMA 2 – CARDINALIDADE 
A cardinalidade é a quantificação de um relacionamento determinada com 
base nas regras de negócios, mostrando, em termos quantitativos, como os 
dados são associados uns aos outros. Em outras palavras, a cardinalidade é um 
número que expressa o comportamento (número de ocorrências) de 
determinada entidade associada a uma ocorrência da entidade em questão por 
meio do relacionamento. Para Alves (2014, p. 98), “cardinalidade é uma restrição 
para um relacionamento binário que determina quantas vezes uma entidade 
pode participar de um relacionamento”. 
Um relacionamento sempre possui dois sentidos: o de ida e o de volta. A 
cardinalidade de uma relação é definida em cada um dos sentidos do 
relacionamento, representada por (x, y) em que x é a cardinalidade mínima e y é 
a máxima. Cada uma tem um objetivo: 
 Mínima: orientar a obrigatoriedade ou opcionalidade do relacionamento; 
 Máxima: define a quantidade máxima que um elemento pode estar 
associado no relacionamento. 
O relacionamento entre as entidades deve ser criado e validado de 
acordo com as regras que sustentam o negócio, permitindo manter a integridade 
do modelo de dados. 
Figura 6 – Relacionamento entre entidades 
 
 
 
8 
A posição correta da cardinalidade é do lado oposto à sua entidade 
correspondente. Na Figura 6, a cardinalidade 0:N faz referência à entidade 
Empregado, já a cardinalidade (1:1) faz referência à entidade Dependente. Isso 
significa que: 
 Uma ocorrência de empregado pode não estar associada a uma 
ocorrência de dependente ou pode estar associada a várias ocorrências 
dele (o empregado pode não possuir dependentes ou pode possuir 
vários); 
 Uma ocorrência de dependente está associada a apenas uma ocorrência 
de empregado (o dependente possui apenas um empregado 
responsável). 
Na prática, para as cardinalidades máximas, costumamos distinguir dois 
tipos: 1 (um) e N (cardinalidades maiores que 1). Já para a as cardinalidades 
mínimas, costumamos distinguir dois tipos: 0 (zero) e 1 (um). Na tabela 1, são 
apresentadas as possíveis cardinalidades que podem ser atribuídas em um 
relacionamento. 
Tabela 1 – Graus de cardinalidade 
Cardinalidade Descrição 
1:1 
Um elemento de uma entidade se relaciona com um elemento de outra 
entidade 
1:N ou N:1 
Um elemento de uma entidade pode se relacionar com mais de um 
elemento de outra entidade 
N:N 
Vários elementos de uma entidade podem se relacionar com vários 
elementos de outra entidade e vice-versa 
0:1 
Um elemento de uma entidade pode se relacionar a nenhuma ou uma 
ocorrência de outra entidade 
0:N 
Um elemento de uma entidade pode se relacionar a nenhuma ou muitas 
ocorrências de outra entidade 
A Figura 7 representa outro exemplo de DER. O DER é composto por 
entidades, relacionamentos e atributos. Nas Figura 6 e 7, não foram 
representados os atributos para não poluir o exemplo, mas eles sempre devem 
aparecer. 
 Um motorista dirige um veículo; 
 Um veículo é dirigido por um motorista. 
 
 
 
9 
Figura 7 – Exemplo de entidade e relacionamento (DER) 
 
TEMA 3 – ESTUDO DE CASO 
O estudo de caso contempla a criação de um DER para armazenar 
informações sobre veículos. Após a análise de requisitos, sabe-se que: 
a. O veículo possui sempre uma placa única em todo o país; 
b. O sistema tem um cadastro de pessoas com CPF, nome e data de 
nascimento; 
c. O veículo possui sempre um responsável legal por ele; 
d. O veículo é sempre de uma marca e de um modelo; 
e. O veículo precisa manter o histórico desta responsabilidade (propriedade). 
Os dados levantados pela análise de requisito geralmente são em tópicos, 
pois o clientevai repassando as informações conforme a conversa com o 
analista vai acontecendo. Para um melhor entendimento, será elaborado o DER 
item a item. Na Figura 8, são representadas as informações descritas no tópico 
(a): 
a. O veículo possui sempre uma placa única em todo o país; 
Figura 8 – Entidade veículo com atributo placa 
 
 
 Cria-se a entidade Veículo para representar um objeto concreto, e o 
atributo placa para representar a característica que um Veículo possui. Pode-se 
definir esse atributo como identificador, considerando que a placa do veículo é 
única. 
 
 
10 
Na Figura 9, são representadas as informações descritas no tópico (b): 
b. O sistema tem um cadastro de pessoas (responsável) com CPF, nome e 
data de nascimento; 
Figura 9 – Entidade responsável com seus atributos 
 
Cria-se a entidade Responsável utilizando cpf como atributo identificador, 
e nome e dt_nasc como atributos não identificados. 
Na Figura 10, são representadas as informações descritas no tópico (c), 
as quais conectam as definições feitas nos tópicos (a) e (b): 
c. O veículo possui sempre um responsável legal por ele. 
Figura 10 – Relacionamento entre as entidades veículo e responsável 
 
 Na entidade Veículo, adiciona-se o cpf_resp como um atributo não 
identificado. Considerando as especificações da análise de requisitos, foi 
adicionada a cardinalidade: um responsável pode ter vários veículos (1:N) e um 
veículo só pode ter um responsável (1:1). 
 Na Figura 11, são representadas as informações descritas no tópico (d): 
d. O veículo é sempre de uma marca e de um modelo; 
 
 
 
11 
Figura 11 – Entidade veículo com os atributos 
 
Considerando que marca e modelo se referem a novas características 
que a entidade Veículo pode ter, esses dois atributos foram conectados à 
entidade Veículo como atributos não identificados. 
 Para concluir, na Figura 12, são representadas as informações descritas 
no tópico (e): 
e. O veículo precisa manter o histórico desta responsabilidade (propriedade); 
Figura 12 – DER completo 
 
Cria-se a entidade Histórico. O atributo cpf_resp identifica de quem era o 
veículo na dt_compra. Com todos esses atributos, armazena-se o histórico do 
veículo. Foi definida a cardinalidade como uma ocorrência: o histórico tem 
apenas um veículo (1:1) e um veículo pode ter vários históricos (1:N). 
 
 
12 
 
TEMA 4 – MODELOS: LÓGICO, FÍSICO E RELACIONAL 
4.1 Modelo Lógico 
O modelo lógico de dados reflete as propriedades necessárias para a 
tradução do modelo conceitual, de maneira que seja possível a descrição dos 
elementos capazes de serem interpretados por um Sistema Gerenciador de 
Banco de Dados (SGBD), tais como o detalhamento dos atributos, chaves de 
acesso, integridade referencial e normalização. O modelo lógico é independente 
de hardware, ou seja, qualquer alteração (escolha de um computador, sistema 
operacional diferente etc.) não afetará no modelo lógico. 
Dentro do modelo lógico, algumas regras e restrições começam a ser 
implementadas no desenho, informando as colunas, que são únicas e que não 
podem ser duplicadas, representadas anteriormente no DER pelos atributos 
identificadores, aqui chamados de chaves primárias, como também as chaves 
secundárias, que são geradas para associar uma entidade a outra. 
As chaves primárias são colunas que não podem ser duplicadas, por 
exemplo, o CPF no cadastro de clientes e o CNPJ no cadastro de empresas. Os 
relacionamentos são importantes para representar a conexão entre as tabelas, 
representadas anteriormente no DER pelas entidades e também por manter a 
integridade do banco de dados, o qual irá utilizar essas definições de restrição 
para permitir ou não a duplicidade de um dado. 
Segundo Puga, França e Goya (2013, p. 77), a modelagem de dados é 
uma técnica utilizada para: 
 Conhecer melhor o contexto do negócio; 
 Retratar os dados que suportam esse contexto de negócio; 
 Projetar o banco de dados; 
 Promover o compartilhamento dos dados e a integração dos sistemas por 
meio da reutilização de estruturas de dados comuns; 
 Contribuir para que a perspectiva da organização a respeito dos seus 
dados seja unificada. 
Dentro do modelo lógico, as entidades que eram representadas por 
retângulos (modelo conceitual) se tornam tabelas do banco de dados. 
 
 
13 
Figura 13 – Exemplo da representação gráfica do modelo lógico 
 
Fonte: Puga; França; Goya, 2013, p. 163. 
A Figura 13 é um exemplo da representação gráfica do modelo lógico, 
mas ele ainda pode ser descrito sem a representação gráfica. 
Figura 14 – Exemplo de modelo lógico 
 
Fonte: Alves, 2014, p. 30. 
É importante destacar que, nesse ponto do projeto de banco de dados, 
ainda não se definem as características particulares de cada coluna, como 
tamanho ou tipo de dado, limitando-se apenas a relacioná-los com suas 
respectivas tabelas. 
4.2 Modelo físico 
O modelo físico é a etapa final do projeto de banco de dados, estando 
relacionado diretamente com o profissional do SGBD, podendo variar conforme 
o SGBD que está sendo utilizado. Já com a definição do SGBD, o modelo físico 
é criado e cada atributo é devidamente especificado, conforme os tipos de dados 
do SGBD escolhido. 
 
 
 
14 
Figura 15 – Exemplo da representação gráfica do modelo físico 
 
Fonte: Puga; França; Goya (2013, p. 163). 
O modelo físico representa a estrutura para armazenamento físico dos 
dados, expressando a forma como as informações serão armazenadas 
fisicamente, em termos computacionais. Para criar um banco de dados, 
geralmente se utiliza uma linguagem declarativa. Em SQL (Structured Query 
Language), essa linguagem é denominada linguagem de definição de dados 
(DDL). 
Figura 16 – Exemplo de comando SQL para criação do modelo físico 
 
Fonte: Alves, 2014, p. 31. 
A Figura 16 exemplifica um comando para a criação física das tabelas 
Clientes e Produtos no banco de dados. Observe que cada coluna possui um 
tipo de dado e um tamanho. A chave primária também foi definida nas duas 
tabelas. A linguagem utilizada na Figura 16 é a SQL e não se preocupe se você 
não entendeu os comandos, pois é assunto para a próxima aula. 
 
 
15 
Para finalizar os modelos de dados que foram estudados, a Figura 17 
demonstra uma visão total dos estágios da modelagem de dados, podendo se 
ter a ideia do “posicionamento” dos três modelos vistos. 
Figura 17 – Estágios da modelagem de dados 
 
Fonte: Puga; França; Goya, 2013, p. 81. 
4.3 Modelo relacional 
O modelo ER é conveniente para representar um projeto de banco de 
dados inicial de alto nível. No modelo relacional, as entidades passam a ser 
tabelas e os atributos passam a ser colunas. 
Heuser (2009, p. 120) define tabela como “um conjunto não ordenado de 
linhas (tuplas, na terminologia acadêmica)”. Tabelar os dados (dispor em linhas 
e colunas) facilita a sua visualização e interpretação. A Figura 18 representa a 
transcrição da entidade Responsável e seus atributos para a tabela 
Responsável. 
 
 
 
 
 
 
16 
Figura 18 – Modelo ER X Modelo relacional 
 
 
 
Responsável 
CPF nome dt_nasc 
528.986.447-90 João Batista 12-09-1987 
908.742.803-12 Maria da Silva 02-06-1990 
008.942.356-75 Pedro Augusto 07-01-2015 
 
 
Analisando a Figura 18, a tabela Responsável possui três colunas: cpf, 
nome, dt_nasc. O atributo identificador (cpf) passa a ser a chave primária da 
tabela Responsável. Heuser (2009, p. 122) define chave primária (do inglês 
primary key) como “uma coluna ou uma combinação de colunas cujos valores 
distinguem uma linha das demais dentro de uma tabela”.Outro conceito importante é o de registro. Os registros são os dados de 
uma mesma ocorrência, ou, os dados de uma mesma linha da tabela. A tabela 
da Figura 18 possui três registros, sendo que cada um deles possui dados nas 
três colunas, “cpf”, “nome” e “dt_nasc”. Podemos dizer que estes registros são 
informações cadastrais dos responsáveis nomeados por João, Maria e Pedro. 
A nomeação dos elementos (tabelas, colunas, chaves, etc.) deve seguir o 
padrão do SGBD utilizado, e a grande maioria não aceita caracteres especiais 
(exceto o underline) nem espaço em branco. Exemplo: 
Tabela 2 – Nomeação dos elementos 
Modelo ER Modelo Relacional 
Nome da mãe nomeMae 
nomeDaMae 
nome_mae 
 
A Figura 19 representa como é feito, fisicamente, um relacionamento 
entre duas tabelas. 
 
 
 
17 
Figura 19 – Relacionamento físico entre as tabelas 
 
 
Ao analisar as duas tabelas (Responsável e Veículo), é possível observar 
que a coluna cpf_resp da tabela Veículo é a coluna que relaciona as duas 
tabelas. Na da tabela “Veículo”, essa coluna é uma chave estrangeira. Por meio 
desse relacionamento entre essas tabelas podemos observar que a responsável 
“Maria da Silva”, que tem o CPF 908.742.803-12, possui dois veículos (placas 
MDQ-5698 e MGG-1376), e que o responsável “Pedro Augusto” não possui 
veículos por não constar na tabela Veículo. 
Para facilitar o entendimento desse processo de transformação de um 
modelo para um banco de dados, a tabela 3 apresenta uma relação entre os 
elementos do modelo ER para o modelo relacional. 
Tabela 3 – Modelo ER versus modelo relacional 
Modelo ER Modelo relacional 
ENTIDADE TABELA 
ATRIBUTO SIMPLES COLUNA 
ATRIBUTO DERIVADO COLUNA 
ATRIBUTO IDENTIFICADOR CHAVE PRIMÁRIA (OU SECUNDÁRIA) 
ATRIBUTO MULTIVALORADO NOVA TABELA E CHAVE ESTRANGEIRA 
RELACIONAMENTO 1:1 OU 1:N CHAVE ESTRANGEIRA 
RELACIONAMENTO N:N NOVA TABELA COM 2 CHAVES ESTRANGEIRAS 
CONJUNTO DE VALORES TIPO DE DADOS 
 
 
 
 
18 
4.4 Principais tipos de dados 
Como explicado na aula 1, os tipos de dados são as últimas grandes 
evoluções nos bancos de dados, com bibliotecas digitais, vídeos interativos, etc. 
Na explicação a seguir, atente para os tipos de dados mais comuns e a sua 
utilização. Lembre-se de que, dependendo do SGBD escolhido, pode haver uma 
variação na nomenclatura dos tipos de dados. Neste material, utilizam-se os 
tipos de dados (do inglês SQL Data types) do banco de dados MySQL. No 
entanto, caso você tenha contato com outro banco de dados, deverá utilizar os 
tipos de dados desse outro sistema gerenciador. 
Figura 20 – Números inteiros 
TINYINT 1 Byte (0 a 255 ou -128 a 127) 
SMALLINT 2 Bytes (0 a 65.535 ou -32.768 a 32.767) 
MEDIUMINT 3 Bytes (0 a 16.777.215 ou -8,388,608 a 8,388,607) 
INT 4 Bytes (0 a 4.294.967.295 ou -2,147,483,647 a 2,147,483,647) 
BIGINT 8 Bytes 
UNSIGNED sem sinal (somente números positivos, dobra o limite dos números) 
Fonte: Íparos, S.d. 
Os tipos de dados da Figura 20 são utilizados para armazenar números 
inteiros, variando em tamanho utilizado para armazenar a coluna e a sua 
capacidade. Uma coluna do tipo TINYINT pode armazenar o número 255 como 
máximo. 
Figura 21 – Armazenamento de arquivos 
TINYBLOB 255 Bytes 
BLOB 64KB 
MEDIUMBLOB 16MB 
LONGBLOB 4GB 
Fonte: Íparos, S.d. 
Os tipos de dados da Figura 21 são utilizados para armazenar arquivos 
como imagens e vídeos. O que vai diferenciar entre a escolha do tipo da coluna 
é, basicamente, o seu tamanho máximo de armazenamento. 
 
 
19 
Figura 22 – Tipo texto 
CHAR textos com um tamanho fixo de caracteres 
VARCHAR para textos de 2 a 255 caracteres 
TINYTEXT 255 Bytes 
TEXT 64KB 
MEDIUMTEXT 16MB 
LONGTEXT 4GB 
Fonte: Íparos, S.d. 
O tipo mais comum, para os armazenamentos de texto, é o varchar, pois 
é utilizado para armazenar colunas como nome, endereço, bairro, cidade, etc. 
Figura 23 – Tipo data 
DATE armazena a data no formato YYYY-MM-DD 
TIME armazena a hora no formato HH:MM:SS 
DATETIME armazena a data e a hora no formato YYYY-MM-DD HH:MM:SS 
Fonte: Íparos, S.d. 
Um fato curioso no armazenamento das datas é que o padrão é o 
americano, onde o ano é invertido com o dia. Geralmente a coluna do tipo 
DATETIME é utilizado na gravação automática de logs e acessos. 
Figura 24 – Tipo decimal 
FLOAT números flutuantes 
DOUBLE números flutuantes com precisão dupla 
Fonte: Íparos, S.d. 
 Os tipos de dados da Figura 24 também são muito utilizados, pois serve 
para armazenar os números não inteiros (com vírgula). Como exemplos têm 
salário, preço, quantidade etc. 
Saiba mais 
As 12 Regras de Codd 
 
Ao definir o modelo relacional, Codd estabeleceu 12 regras para determinação de um banco 
de dados relacional. 
 
 
20 
Estas regras são usadas, portanto para se verificar a fidelidade de um banco de dados ao 
modelo relacional. 
Na prática são poucos os gerenciadores de banco de dados que atendem a todas as 12 
regras. 
Na maior parte dos casos são atendidas no máximo 10 regras. 
1. Toda informação num banco de dados relacional é apresentada a nível lógico na forma de 
tabelas; 
2. Todo dado em um banco de dados relacional tem a garantia de ser logicamente acessível, 
recorrendo-se a uma combinação do nome da tabela, um valor de chave e o nome da coluna; 
3. Tratamento sistemático de valores nulos; (ausência de informação) 
4. O dicionário de dados, catálogo, do banco de dados é baseado no modelo relacional; 
5. Há uma linguagem não procedural para a definição, manipulação e controle dos dados; 
6. Tratamento das atualizações de visões dos dados; 
7. Tratamento de alto nível para inserção, atualização e eliminação de dados; 
8. Independência física dos dados; (mudança na memória e no método de acesso, criação de 
um novo índice, criação de uma nova coluna) 
9. Independência lógica dos dados; (mudança no tamanho de uma coluna) 
10. Restrição de Integridade; (Identidade, Referencial e Domínio) 
11. Independência de Distribuição dos dados; 
12. Não subversão das regras de integridade ou restrições quando se usa uma linguagem 
hospedeira. (Siqueira, S.d.) 
FINALIZANDO 
Nesta aula foram aprofundados os conceitos sobre a modelagem 
conceitual e do modelo ER. Foram explanados os conceitos de entidades (fortes 
e fracas), relacionamentos (fortes e fracos), atributos (identificador, não 
identificado, multivalorados e compostos) e apresentados os tipos de 
relacionamentos com as suas cardinalidades. O estudo de caso é a parte da 
aula que merece uma atenção ímpar, pois nele transforma-se o conhecimento 
teórico para o conhecimento prático. Na continuação da aula, apresentaram-se 
os modelos lógicos e físicos, com suas características finalizando com a 
transformação de um modelo ER para um modelo relacional. 
 
 
 
 
21 
REFERÊNCIAS 
ALVES, W. P. Banco de dados. 1. ed. São Paulo: Érica, 2014. 
HEUSER, C. A. (Org.). Projeto de banco de dados. 6. ed. Porto Alegre: 
Bookman, 2009. 
PUGA, S.; FRANÇA, E.; GOYA, M. Banco de dados: implementação em SQL, 
PL/SQL, Oracle 11g. São Paulo: Pearson Education do Brasil, 2013. 
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistemas de banco de 
dados. São Paulo: Makron Books, 1999. 
SIQUEIRA, F. de. Banco de Dados I. Google Sites. Disponível em 
<https://sites.google.com/site/uniplibancodedados1/aulas/modelo-relacional>. 
Acesso em: 19 jun. 2018. 
TIPOS de dados básicos do Mysql. Íparos. Disponível em: 
<http://www.iparos.com.br/cursos/php/mysql/tipos-de-dados-basicos-do-mysql> 
Acesso em: 19 jun. 2018. 
 
 
 
 
 
 
 
 
 
 
 
 
BANCO DE DADOS 
AULA 3Prof. Lucas Rafael Filipak 
 
 
2 
CONVERSA INICIAL 
Segue a apresentação da aula com a estrutura de contéudos trabalhados 
em tópicos: 
1. Linguagem Structured Query Language (SQL) 
1.1. Características e instruções 
1.2. Importância do padrão 
2. Operações DDL 
2.1 Criando bancos de dados 
3. Criando tabelas 
4. Modificando tabelas 
4.1 Apagando tabelas 
Os objetivos da aula 3 são contextualizar a linguagem Structured Query 
Language (SQL), compreendendo sua evolução e seus padrões; entender as 
três categorias de comandos SQL e de que forma elas são aplicadas; estudar os 
comandos da categoria DDL, que são os comandos utilizados na estrutura do 
banco de dados; criar e modificar tabelas. 
TEMA 1 – LINGUAGEM STRUCTURED QUERY LANGUAGE (SQL) 
Com o surgimento dos bancos de dados relacionais nos anos 1970, 
Edgar Frank Codd desenvolveu um modelo de dado relacional chamado Sequel 
ou linguagem de consulta em inglês estruturado (Strutucred English Query 
Language). Posteriormente, passou a ser chamada de SQL ou linguagem de 
consulta estruturada (Structured Query Language), apresentada oficialmente 
pela IBM em novembro de 1976, em seu IBM Journal of R&B. 
A partir de 1986, muitas linguagens de empresas diferentes 
(concorrentes) permitiram que os programadores fizessem acesso e 
manipulassem dados relacionais. O padrão SQL foi considerado fácil de 
aprender e foi muito bem aceito universalmente. Importante deixar claro que o 
SQL não é uma linguagem de programação, mas sim uma linguagem de 
consulta estruturada. Nesse mesmo ano, o instituto nacional de padrões 
(American National Standard Institute – ANSI) em conjunto com a organização 
internacional de padrões (International Standards Organization – ISO) definiram 
um padrão para o SQL, que ficou conhecida como SQL-86 ou SQL-1. 
 
 
3 
Posteriormente, várias revisões foram feitas no SQL e, a cada revisão, 
acrescentava o ano ao lado do nome da linguagem ou a versão (sequencial). 
A grande vantagem do SQL foi que os programadores aprendiam uma 
única linguagem e que com pequenas modificações poderia ser aplicada em 
uma vasta variedade de sistemas gerencias de banco de dados (SGBDs). A 
competitividade entre as empresas que desenvolvem sistemas de bancos de 
dados é muito grande e, para garantir uma maior satisfação de seus utilizadores, 
algumas delas, como a Oracle e a Microsoft, resolveram aderir a um padrão 
próprio para utilização da linguagem SQL em seus SGBDs. 
Os padrões criados pelas empresas têm suas particularidades, mas 
seguem a base do SQL. Como exemplo foi utilizado a tabela apresentada na 
Figura 1, na qual se pode notar que em determinado SGBD, os tipos de dados 
recebem nomes diferentes, mas a sua utilização é a mesma. 
Figura 1 – Comparação de dados em diferentes SGBD 
 
Fonte: Kaminski, 2011. 
No início, o custo dos sistemas que utilizavam o SQL era muito alto. Com 
o passar dos anos, os valores foram caindo e, hoje, existem alguns sistemas que 
são open source e/ou gratuitos. De acordo com Erick Scudero (2016) o MySQL, 
PostgreSQL e o MongoDB são exemplos que se enquadram nessa categoria. 
Para Damas (2005, p. 1), a linguagem SQL é considerada um padrão dos 
sistemas de gerência de banco de dados relacional (SGBDR), por isso todos os 
fabricantes a integram em seus produtos. 
1.1 Características e instruções 
A linguagem SQL implementa os conceitos definidos no modelo 
relacional. Pode-se ver em Damas (2005, p. 3) que, com a linguagem SQL é 
possível: 
 
 
4 
 Criar, alterar e remover todos os elementos de um banco de dados, como 
tabelas, views, índices etc.; 
 Inserir, alterar e apagar dados; 
 Consultar o banco de dados; 
 Controlar o acesso dos usuários ao banco de dados e as operações a que 
cada um deles pode ter acesso; 
 Obter a garantia da consistência e integridade dos dados. 
Em 1982, foi lançada a primeira versão padronizada da linguagem SQL, 
que veio ganhando melhorias de acordo com sua evolução. A padronização do 
SQL apresenta características que, conforme Puga (2013, p. 170), merecem 
destaque: 
 As instruções padronizadas seguem a mesma nomenclatura e formato 
para diferentes tipos de SGDB, respeitando as particularidades de cada 
um. 
 A migração de um SGBD para outro não requer grandes mudanças. 
 Quando ocorre a migração de um SGBD, a adaptação dos profissionais é 
facilitada, com redução de tempo e de custos para treinamento, pois as 
instruções possuem nomes e funcionalidades iguais. 
 Portabilidade entre as plataformas. 
Para Puga (2013, p. 170), o SQL apresenta três categorias de instruções: 
 DDL  Data Definition Language: utilizada para definição e descrição dos 
dados. 
Figura 2 – Categorias de instrução DDL 
 
Fonte: Puga, 2013, p. 170. 
 
 
5 
 DML  Data Manipulation Language: utilizada para a manipulação dos 
dados. Na DML, existe uma subcategoria de instruções, chamada DCL 
(Data Control Language), que é utilizada para controlar o acesso aos 
dados (Puga, 2013, p. 170). 
Figura 3 – Categorias de instrução DML 
 
Fonte: Puga, 2013, p. 170. 
 DCL  Data Control Language: utilizada para controle de segurança do 
banco de dados, atribuindo e retirando permissões (Puga, 2013, p. 170). 
Figura 4 – Subcategoria de instrução DCL 
 
Fonte: Puga, 2013, p. 171. 
 TCL  Transact Control Language: utilizada para controle de transações 
(Puga, 2013, p. 170). 
Figura 5 – Categorias de instrução TCL 
 
Fonte: Puga, 2013, p. 171. 
 
 
6 
A criação dos grupos de comandos levou em consideração a finalidade de 
cada comando. Os comandos que mexem na estrutura da tabela ficaram na 
categoria DDL, os que mexem com os dados ficaram na categoria DML, os 
comandos que atribuem e retiram permissões dos usuários (nos dados) ficaram 
na categoria DCL e os comandos que fazem transações ficaram na categoria 
TCL. 
1.2 Importância do padrão 
A linguagem SQL começou a se tornar popular e de grande sucesso, 
obrigando empresas como ANSI e ISO a padronizar a linguagem SQL. Em 1986, 
foi criado um padrão ANSI e, em 1987, foi criado um padrão ISO. Desde então, 
várias versões do padrão SQL foram criadas, acrescentando novos comandos e 
funcionalidades em cada nova versão. Na Tabela 1, há alguns detalhes sobre as 
versões do padrão ANSI. 
Tabela 1 – Versões do padrão ANSI 
SQL:86 
Primeira versão da linguagem, lançada em 1986, consiste 
basicamente na versão inicial da linguagem criada pela IBM. 
SQL:92 
Lançada em 1992, inclui novos recursos tais como tabelas 
temporárias, novas funções, expressões nomeadas, valores 
únicos, instrução case etc. 
SQL:1999 
Lançada em 1999, foi a versão que teve mais recursos novos 
significativos, entre eles: a implementação de expressões 
regulares, recursos de orientação a objetos, queries 
recursivas, triggers, novos tipos de dados (boolean, LOB, 
array e outros), novos predicados etc. 
SQL:2003 
Lançada em 2003, inclui suporte básico ao padrão XML, 
sequências padronizadas, instrução MERGE, colunas com 
valores autoincrementais etc. 
SQL:2006 
Lançada em 2006, não inclui mudanças significativas para as 
funções e comandos SQL. Contempla basicamente a 
interação entre SQL e XML 
Fonte: Prado, 2015, p. 1. 
Os padrões são “dialetos” que os principais fabricantes de SGBDs 
implementam em seus bancos de dados. Atualmente, além dos seus dialetos, os 
bancos também implementam o padrão ANSI. A empresa Oracle tem o seu 
padrão, comumente chamado de padrão Oracle, mas nada mais é que o dialeto 
SQL da Oracle. Os dialetos geralmente surgem quando o fabricante precisa 
implementar algum recurso no SGBD, mas esse recurso ainda não foi 
validado/criadono padrão ANSI. 
 
 
7 
A Figura 6 e a Figura 7 representam o mesmo comando sendo executado 
no padrão Oracle (Figura 6) e no padrão ANSI (Figura 7). Não se atente a 
entender os comandos, mas sim comparar e reparar que existem diferenças de 
sintaxes entre eles. 
Figura 6 – Instrução SQL com ligação representando LEFT JOIN utilizando o 
dialeto Oracle 
 
Fonte: Prado, 2015, p. 1. 
Figura 7 – Instrução SQL com ligação representando LEFT JOIN utilizando o 
padrão ANSI 
 
Fonte: Prado, 2015, p. 1. 
Para finalizar a explicação sobre padrões, Prado (2015, p. 1) afirma que, 
de um modo geral, não há diferença de desempenho entre os dois padrões. 
TEMA 2 – OPERAÇÕES DDL 
A Data Definition Language (DDL) é a primeira parte da criação de um 
banco de dados, pois é nela que estão os comandos para criação do banco de 
dados, das tabelas e a definição das relações. 
Para visualizar melhor, a Figura 8 traz os componentes e a sua hierarquia 
dentro do banco de dados. Lembre-se também de que um sistema de 
gerenciamento de banco de dados pode possuir mais de um banco de dados. 
Os bancos de dados podem ter uma ou mais tabelas, a tabela pode possuir uma 
ou mais colunas. 
 
 
8 
Figura 8 – Hierarquia dos componentes do banco de dados 
 
2.1 Criando o banco de dados 
O primeiro passo consiste na criação do banco de dados. A sintaxe para a 
criação é simples e não é necessário que seja digitada em letras maiúsculas. A 
sintaxe é CREATE DATABASE nome_banco. Portanto, “CREATE DATABASE” 
é o comando utilizado para criar o banco de dados. A Figura 9 traz um exemplo 
de execução desse comando no MYSQL. Outros SGBDs podem trazer outras 
mensagens, pois cada um possui diferentes mensagens de execução. 
Figura 9 – Exemplo do uso do comando CREATE DATABASE 
 
Deve-se prestar atenção no nome do banco, pois não pode ter espaços 
ou caracteres especiais e deve ser o mais descritivo possível. Outra situação 
importante é que dentro de um SGBD pode existir mais de um banco de dados, 
então o nome do banco deve ser único. Para visualizar os bancos de dados que 
já foram criados, utiliza-se o comando SHOW DATABASES. 
 
 
 
9 
Figura 10 – Exemplo do uso do comando SHOW DATABASES 
 
A Figura 10 apresenta um exemplo da execução do comando, mostrando 
o nome de cinco bancos que já foram criados. Note que o banco sistema, que 
criamos com a execução do comando da Figura 9 está na lista. O próximo passo 
depois da criação do banco de dados é informar para o SGBD o banco de dados 
que será utilizado. A partir do comando USE [nome_banco], Figura 11, todos os 
comandos SQLs serão aplicados no banco de dados selecionado. 
Figura 11 – Exemplo do comando USE 
 
TEMA 3 – CRIANDO AS TABELAS 
Um banco de dados pode ser formado por uma ou mais tabelas. Cada 
tabela também é nomeada com uma identificação única e deve conter colunas 
agrupadas pelo seu tipo. Para exemplificar, o banco de dados possui uma tabela 
chamada alunos (que vai conter os dados dos alunos), outra tabela chamada 
professores (com os dados dos professores) e assim por diante. O comando 
para a criação de uma nova tabela é o CREATE TABLE. 
 
 
 
10 
Figura 12 – Exemplo do comando CREATE TABLE 
 
Se a sintaxe estiver correta, como a exibida na Figura 12, aparecerá uma 
mensagem positiva de execução. No MySQL, a mensagem é Query OK. Mas se 
algo na sintaxe estiver errada, a mensagem de execução é negativa. No MySQL 
a mensagem de erro é “You have an error in your SQL syntax”. 
Figura 13 – Exemplo de erro na sintaxe da query 
 
Na Figura 13, o comando para a construção da tabela não foi executado, 
pois faltou uma vírgula entre a criação da coluna cod_aluno e a coluna nome. 
Observe que o programa retorna uma mensagem de erro. 
Depois de criadas as tabelas (pelo menos uma), é possível visualizar as 
tabelas existentes no banco de dados. O comando utilizado é o SHOW TABLES, 
como mostra a Figura 14. 
Figura 14 – Exemplo do comando SHOW TABLES 
 
 
 
11 
Note que nos comandos de CREATE TABLE e SHOW TABLES não é 
preciso informar o nome do banco de dados, pois, como foi executado 
anteriormente o comando USE sistema, o gerenciador do banco sabe que todas 
as consultas serão realizadas no banco chamado sistema. Entretanto, caso não 
tenha sido executado esse sistema, é possível informar o nome do banco, 
precedendo os objetos, ou então executar o comando USE [nome_banco] a 
qualquer momento. 
Para visualizar a estrutura de uma tabela, utiliza-se o comando 
DESCRIBE nome_tabela. O comando vai mostrar a estrutura da tabela, com o 
nome das colunas (Field), os tipos de dados e tamanhos (Types). As outras 
colunas serão explicadas posteriormente. 
Figura 15 – Exemplo do comando DESCRIBE 
 
O comando da Figura 15 retornou duas linhas (2 rows), pois essa tabela é 
composta de duas colunas, cod_aluno e nome, conforme comandos que 
executamos na Figura 13. 
A restrição NULL, que também é chamada de constraint, representa que 
a coluna pode ser vazia. Essa definição ocorre automaticamente na criação da 
tabela. Caso seja obrigatório o preenchimento de dados nessa coluna, é preciso 
modificar a restrição da coluna para NOT NULL. Esse procedimento pode ser 
realizado no momento em que a tabela está sendo criada ou depois, por meio de 
uma alteração da tabela, como veremos no tema 4 deste material. 
Figura 16 – Exemplo do uso do comando NOT NULL 
 
 
 
12 
A tabela criada na Figura 16 tem as suas duas colunas definidas como 
NOT NULL, em outras palavras, foi gerada uma restrição ou constraint nessas 
colunas obrigando o preenchimento de valores. Mas o que é “estar 
preenchidos”? Até agora foi vista apenas a estrutura da tabela, sem inserir 
nenhum dado (conteúdo). Na próxima aula, serão estudados comandos que 
realizam a inserção dos dados em uma tabela e como essa restrição influenciará 
nesse procedimento. 
A definição de uma chave primária é uma condição imposta em uma ou 
mais colunas de uma tabela, de modo que essa coluna não tenha valores nulos, 
ou seja, sempre terá um valor único, portanto não se repete em uma mesma 
tabela, e é utilizado como referência para gerar relacionamentos com outras 
tabelas do banco de dados. Como exemplo, pode-se utilizar a tabela 
cad_pessoas e como chave primária a coluna CPF, pois o CPF é um dado 
único, tornando o registro único. Algumas curiosidades sobre chave primária: 
 A coluna que recebe a chave primária não pode ser NULL; 
 Cada tabela tem apenas uma chave primária; 
 Tipos de dados mais utilizados para as chaves são INT e VARCHAR; 
 O valor da chave primária é atribuído no momento que o registro é criado. 
Figura 17 – Exemplo do uso do comando PRIMARY KEY 
 
Na Figura 17, a coluna cod_materia foi escolhida para ser a chave 
primária da tabela. Com essa restrição, quando inserido os dados na tabela não 
será possível ter duas matérias com o mesmo código e toda matéria deve ter um 
código pelo fato da coluna chave de uma tabela ter a condição NOT NULL. 
 
 
13 
Algumas tabelas podem não possuir uma coluna que possa ser utilizada 
como chave primária (única). Nesse caso, é necessário criar na tabela uma 
coluna do tipo inteiro e atribuir a ela a condição de auto_increment. 
Figura 18 – Exemplo do uso do comando AUTO_INCREMENT 
 
O AUTO_INCREMENT, conforme exibido na Figura 18, informa o SGDB 
que ele deve a cada novo registro inserido na tabela, incrementar, 
automaticamente, de forma sequencial a coluna cod_turno. No primeiro registro 
inserido nessa tabela, a coluna cod_turno recebe o valor 1, no segundo, ela 
recebe o valor 2, e assim por diante, garantindo assim que nãohaverá valores 
duplicados. O valor inicial do AUTO_INCREMENT pode ser configurado (ver 
Figura 23). 
TEMA 4 – MODIFICANDO TABELAS 
O planejamento de um banco de dados nem sempre é uma tarefa tão fácil 
e modificações na estrutura da tabela são comuns. Quando necessário realizar 
alterações nas definições da estrutura do banco de dados, podemos utilizar o 
comando ALTER TABLE, o qual permite: 
 Renomear uma tabela; 
 Alterar tipo e tamanho de uma coluna; 
 Adicionar ou remover colunas na tabela. 
No que se refere a renomear uma tabela, a Figura 19 representa a 
alteração no nome da tabela, passando de cad_aluno para alunos. 
 
 
 
14 
Figura 19 – Exemplo do uso do comando RENAME 
 
Para alterar o de tamanho de uma coluna, utiliza-se o parâmetro 
MODIFY. Na Figura 20, a coluna nome passa do tamanho 30 para 70. Não é 
preciso informar o tamanho antigo, somente o novo tamanho. 
Figura 20 – Exemplo do uso do comando MODIFY 
 
Observe que, ainda que a alteração é em uma coluna, usamos o 
comando ALTER TABLE e, por isso, precisamos informar o nome da tabela em 
que se encontra a coluna nome. Por esse motivo, todas as modificações 
realizadas em uma coluna serão realizadas por meio do procedimento de 
modificação da tabela, pois, ao alterar uma coluna, consequentemente se 
modifica uma tabela. Assim, o comando deve seguir o seguinte formato: ALTER 
TABLE [nome_tabela] MODIFY [nome da coluna] [tipo]. 
Para adicionar novas colunas em uma tabela já existente, utiliza-se o 
parâmetro ADD COLUMN, informando o nome da nova coluna junto com o tipo e 
tamanho. Na Figura 21, foi adicionada a coluna email na tabela aluno. Pode-se 
utilizar de maneira simplificada: ALTER TABLE aluno ADD email varchar(30). 
Figura 21 – Exemplo do uso do comando ADD COLUMN 
 
Como pode ser visto na Figura 22, o parâmetro DROP COLUMN é 
utilizado para apagar uma coluna de uma tabela. Não é preciso informar o tipo e 
o tamanho da coluna. Pode-se utilizar de maneira simplificada o comando: 
ALTER TABLE [nome_tabela] DROP [nome_coluna]. 
 
 
15 
Figura 22 – Exemplo do uso do comando DROP COLUMN 
 
Como visto anteriormente, o parâmetro auto_increment permite que um 
número único seja gerado quando um novo registro é inserido em uma tabela. 
Ao executar o comando da Figura 23, os registros iniciarão os incrementos a 
partir do número 15, portanto, o primeiro registro salvo na tabela receberá o 
valor 15. 
Figura 23 – Exemplo do uso do comando AUTO_INCREMENT 
 
4.1 Apagando tabelas 
Conforme o comando da Figura 24, também é possível apagar as tabelas 
do banco de dados que não serão utilizadas. O comando DROP TABLE 
[nome_tabela] apaga a tabela e também todos os objetos relacionados a essa 
tabela, incluindo dados, índices, restrições de tabela, triggers (gatilhos) e 
permissões (alguns objetos citados serão estudados nas próximas aulas). 
Figura 24 – Exemplo do uso do comando DROP TABLE 
 
Após a utilização desse comando, a tabela não poderá ser mais acessada 
ou recuperada. Caso você queira apenas apagar os dados armazenados na 
tabela e manter a estrutura da tabela no banco de dados, pode ser utilizado o 
comando DELETE (que será visto na próxima aula). 
 
 
16 
Assim como as tabelas, pode ser visto na Figura 25 que o banco de 
dados também pode ser apagado. Para isso, deve ser utilizado o comando 
DROP DATABASE [nome_banco]. 
Figura 25 – Exemplo do uso do comando DROP DATABASE 
 
FINALIZANDO 
Nesta aula, foram apresentadas sobre a linguagem SQL, suas origens, 
principais modificações históricas. Observou-se a sua padronização e a sua 
importância e que os comandos SQLs são classificados em três categorias que 
variam de acordo com a função dos comandos. Estudou-se sobre os comandos 
da categoria DDL, que é responsável por fazer a estrutura do banco de dados, 
desde a criação e exclusão do banco, criação, modificação e exclusão das 
tabelas etc. 
 
 
17 
REFERÊNCIAS 
DAMAS, L. SQL – Structured Query Language. 6. ed. Rio de Janeiro: FCA, 
2005. 
KAMINSKI, M. Instruções SQL no SQL Server, Oracle e MySQL. Revista SQL 
Magazine, edição 90, 2011. Disponível em: 
<https://www.devmedia.com.br/instrucoes-sql-no-sql-server-oracle-e-
mysql/22005>. Acesso em: 12 ago. 2018. 
LIMA, A. G. de A. Padrão SQL e sua evolução. Disponível em: 
<http://www.ic.unicamp.br/~geovane/mo410-091/Ch05-PadraoSQL-art.pdf> 
Acesso em: 12 ago. 2018. 
PRADO, F. SQL padrão ANSI X padrão Oracle: qual é mais rápido? 12 mar. 
2015. Disponível em: <http://www.fabioprado.net/2012/05/sql-padrao-ansi-x-
padrao-oracle.html>. Acesso em: 12 ago. 2018. 
PUGA, S. Banco de dados: implementação em SQL, PL/SQL, Oracle 11g. São 
Paulo: Pearson Education do Brasil, 2013. 
SCUDERO, E. TOP 10 principais SGBDs do mercado global! 2016. 
Disponível em: <https://becode.com.br/principais-sgbds/>. Acesso em: 12 ago. 
2018. 
 
 
 
 
 
 
 
 
 
 
 
 
BANCO DE DADOS 
AULA 4 
 
 
 
 
 
 
 
 
 
 
 
 
Prof. Lucas Rafael Filipak 
 
 
2 
CONVERSA INICIAL 
Segue a apresentação da aula com a estrutura de contéudos que vão ser 
trabalhados: 
1. Data Manipulation Language (DML) 
1.1 Inserir registros 
2. Selecionar registros 
2.1 Restringir consultas 
2.2 Ordenar consultas 
3. Outros comandos de restrição de consulta 
4. Editar e apagar registros 
4.1 Editar registros 
4.2 Apagar registros 
O objetivo da aula 4 é aprender as instruções/comandos da linguagem 
SQL que fazem parte do grupo de manipulação de dados (DML), 
compreendendo suas sintaxes e aplicações. Os comandos da categoria DML 
são divididos em quatros grandes grupos de comandos: INSERT, SELECT, 
UDPADE e DELETE. Nesta aula, vão ser contemplados os comandos dos 
quatro grupos. 
TEMA 1 – DATA MANIPULATION LANGUAGE (DML) 
Com foi visto na aula anterior, os comandos SQLs são classificados em 
três categorias e a DML é a categoria responsável para fazer a manipulação dos 
dados. A manipulação consiste em comandos de quatro grandes grupos. 
 Inserir (INSERT); 
 Selecionar (SELECT); 
 Atualizar (UPDATE); 
 Apagar (DELETE). 
A Figura 1 representa os principais comandos de manipulação de dados, 
conforme o padrão ANSI/ISO. 
 
 
 
3 
Figura 1 – Comandos de manipulação 
 
Fonte: Alves, 2014, p. 128. 
Esses são os comandos principais, mas eles podem ter variações 
(cláusulas, intervalos e outros comandos) que podem modificar o resultado dos 
dados. 
1.1 Inserir registros 
Na aula anterior, foi visto como criar o banco de dados e como criar, 
modificar e deletar as tabelas. Nesta aula, serão trabalhados os comandos da 
categoria DML. O primeiro passo é inserir os dados nas tabelas. 
Figura 2 – Exemplo do uso do comando INSERT 
 
O comando INSERT (INSERT INTO) é utilizado para inserir os dados nas 
tabelas. Note na Figura 2 há dois blocos delimitados pelos parênteses que são 
separados pela palavra values. No primeiro bloco, são declaradas as colunas da 
tabela nas quais se pretende inserir os dados, sendo estas declaradas 
exatamente como estão definidas na estrutura da tabela. Após o comando 
values, encontra-se o segundo bloco delimitado pelos parênteses, em que são 
informados os dados a serem inseridos na tabela, exatamente na ordem em que 
foram declaradas as colunas da tabela no primeiro bloco. 
 
 
4 
Figura 3 – Exemplo do uso do comando INSERT 
 
Na Figura 3, é possível visualizar a ordem de atribuição de valores. A 
coluna cod_aluno da tabela alunos recebe o dado 459. A coluna nome da tabela 
alunos recebe o dado “João Maria”. Isso se dá pela ordem de escrita