e-Tec Brasil/CEMF/Unimontes
Escola Técnica Aberta do BrasilInformática
Banco de Dados
e-Tec Brasil/CEMF/Unimontes
Escola Técnica Aberta do Brasil
Informática
Banco de Dados
Leandro Clementino de Almeida
Montes Claros - MG
2011
Ministro da Educação
Fernando Haddad
Secretário de Educação a Distância
Carlos Eduardo Bielschowsky
Coordenadora Geral do e-Tec Brasil
Iracy de Almeida Gallo Ritzmann
Governador do Estado de Minas Gerais
Antônio Augusto Junho Anastasia
Secretário de Estado de Ciência, Tecnologia e Ensino Superior
Alberto Duque Portugal
Reitor
João dos Reis Canela
Vice-Reitora
Maria Ivete Soares de Almeida
Pró-Reitora de Ensino
Anette Marília Pereira
Diretor de Documentação e Informações
Huagner Cardoso da Silva
Coordenador do Ensino Profissionalizante
Edson Crisóstomo dos Santos
Diretor do Centro de Educação Profissonal e Tecnólogica - CEPT
Maísa Tavares de Souza Leite
Diretor do Centro de Educação à Distância - CEAD
Jânio Marques Dias
Coordenadora do e-Tec Brasil/Unimontes
Rita Tavares de Mello
Coordenadora Adjunta do e-Tec Brasil/ CEMF/Unimontes
Eliana Soares Barbosa Santos
Coordenadores de Cursos: Coordenador do Curso Técnico em Agronegócio
Augusto Guilherme Dias
Coordenador do Curso Técnico em Comércio
Carlos Alberto Meira
Coordenador do Curso Técnico em Meio Ambiente
Edna Helenice Almeida
Coordenador do Curso Técnico em Informática
Frederico Bida de Oliveira
Coordenadora do Curso Técnico em Vigilância em Saúde
Simária de Jesus Soares
Coordenadora do Curso Técnico em Gestão em Saúde
Zaida Ângela Marinho de Paiva Crispim
BANCO DE DADOS
e-Tec Brasil/CEMF/Unimontes Elaboração
Leandro Clementino de Almeida
Projeto Gráfico
e-Tec/MEC
Supervisão
Wendell Brito Mineiro
Diagramação
Hugo Daniel Duarte Silva Marcos Aurélio de Almeida e Maia
Impressão e Acabamento
Gráfica RB Digital
Designer Instrucional
Angélica de Souza Coimbra Franco Kátia Vanelli Leonardo Guedes Oliveira
Revisão
Maria Ieda Almeida Muniz Patrícia Goulart Tondineli Rita de Cássia Silva Dionísio
Presidência da República Federativa do Brasil Ministério da Educação
AULA 1
Alfabetização Digital
Prezado estudante,
Bem-vindo ao e-Tec Brasil/Unimontes!
Você faz parte de uma rede nacional pública de ensino, a Escola Técnica Aberta do Brasil, instituída pelo Decreto nº 6.301, de 12 de dezem-bro 2007, com o objetivo de democratizar o acesso ao ensino técnico público, na modalidade a distância. O programa é resultado de uma parceria entre o Ministério da Educação, por meio das Secretarias de Educação a Distancia (SEED) e de Educação Profissional e Tecnológica (SETEC), as universidades e escola técnicas estaduais e federais.
A educação a distância no nosso país, de dimensões continentais e grande diversidade regional e cultural, longe de distanciar, aproxima as pes-soas ao garantir acesso à educação de qualidade, e promover o fortalecimen-to da formação de jovens moradores de regiões distantes, geograficamente ou economicamente, dos grandes centros.
O e-Tec Brasil/Unimontes leva os cursos técnicos a locais distantes das instituições de ensino e para a periferia das grandes cidades, incenti-vando os jovens a concluir o ensino médio. Os cursos são ofertados pelas instituições públicas de ensino e o atendimento ao estudante é realizado em escolas-polo integrantes das redes públicas municipais e estaduais.
O Ministério da Educação, as instituições públicas de ensino téc-nico, seus servidores técnicos e professores acreditam que uma educação profissional qualificada – integradora do ensino médio e educação técnica, – não só é capaz de promover o cidadão com capacidades para produzir, mas também com autonomia diante das diferentes dimensões da realidade: cul-tural, social, familiar, esportiva, política e ética.
Nós acreditamos em você!
Desejamos sucesso na sua formação profissional! Ministério da Educação
Janeiro de 2010
Apresentação e-Tec Brasil/CEMF/
Unimontes
AULA 1
Alfabetização Digital
Indicação de ícones
Os ícones são elementos gráficos utilizados para ampliar as formas de linguagem e facilitar a organização e a leitura hipertextual.
Atenção: indica pontos de maior relevância no texto.
Saiba mais: oferece novas informações que enriquecem o assunto ou “curiosidades” e notícias recentes relacionadas ao tema estudado. Glossário: indica a definição de um termo, palavra ou expressão utilizada no texto.
Mídias integradas: possibilita que os estudantes desenvolvam atividades empregando diferentes mídias: vídeos, filmes, jornais, ambiente AVEA e outras.
Atividades de aprendizagem: apresenta atividades em diferentes níveis de aprendizagem para que o estudante possa realizá-las e conferir o seu domínio do tema estudado.
AULA 1
Alfabetização Digital
Sumário
Palavra dos professores conteudistas ... 11
Projeto instrucional ... 13
Aula 1 - Introdução ... 15
1.1 Processamento tradicional de arquivos x banco de dados ... 17
1.2 Profissionais e atividades envolvidas em um SGBD ... 18
1.3 Vantagens e desvantagens do uso de banco de dados ... 18
Resumo ... 20
Atividades de Aprendizagem ... 20
Aula 2 – Sistemas da banco de dados (SBD): conceitos e arquitetura .. 21
2.1 Introdução ... 21 2.2 Modelos de dados ... 22 2.3 Esquema ... 26 2.4 Instância ... 26 Resumo ... 27 Atividades de Aprendizagem ... 27
Aula 3 – Modelagem Ae dados – Modelo Entidade Relacionamento – MER . 29 3.1 Introdução ... 29
3.2 Entidade, atributo e relacionamento ... 30
3.3 Tipos de entidades e atributos ... 32
3.4 Diagrama Entidade Relacionamento (DER) ... 33
Resumo ... 35
Atividades de Aprendizagem ... 36
Aula 4 – Modelagem de dados – Modelo Relacional (MR) ... 37
4.1 Introdução ... 37
4.2 Relações, domínios, tuplas e atributos ... 38
4.3 Atributos-chave ... 38
4.4 Mapeamento do MER para MR ... 39
Resumo ... 42
Atividades de Aprendizagem ... 42
Aula 5 – SQL básico ... 45
5.1 Conceito ... 45
5.2 Comandos de definição de dados ... 45
5.3 Comandos de Manipulação de Dados ... 49
5.4 Restrições de dados ... 55
Resumo ... 58
Atividades de Aprendizagem ... 58
Aula 6 – Integração de banco de dados e internet ... 61
6.1 SGBD web ... 61
6.2 Conexão do SGBD com internet ... 62
Resumo ... 63
Atividades de Aprendizagem ... 64
Referências ... 65
AULA 1
Alfabetização Digital
Caro estudante!
Neste módulo, iniciaremos os estudos sobre banco de dados. Nele, teremos a oportunidade de aprender os principais conceitos, recursos, apli-cações e serviços trabalhados em banco de dados.
Por acaso, já teve a oportunidade de estudar alguma coisa sobre banco de dados? Não? Então, este momento será muito proveitoso para todos nós. Caso já tenha algum conhecimento sobre banco de dados, os estudos realizados não serão menos importantes, pois haverá um momento de relem-brar coisas e de também aprender assuntos novos.
Dito isto, que tal começarmos nossos estudos?
O termo banco de dados, assim como as tecnologias de bancos de dados, tem ganhado cada vez mais importância e está se tornando cada dia mais útil e popular, com a expansão da utilização dos computadores.
Os bancos de dados e os sistemas de bancos de dados tornaram-se componentes essenciais no cotidiano da sociedade moderna. Em nosso coti-diano, deparamo-nos com diversas atividades que envolvem alguma intera-ção com banco de dados. Um exemplo é a utilizaintera-ção de serviços bancários, como depósito, saque, pagamentos de contas etc. Todos esses serviços são possíveis graças a um bom sistema de banco de dados. Outros exemplos: se acessamos o catálogo de uma biblioteca virtual (informatizada) para consul-tar uma bibliografia; se compramos produtos, como livros, brinquedos, equi-pamentos eletrônicos etc., ou de um fornecedor por intermédio de sua pági-na pági-na internet (pági-na web); se fazemos reservas em um hotel ou para a compra de passagens aéreas ou terrestres; quase que certamente, essas atividades envolverão uma pessoa e/ou um programa de computador que acessará um banco de dados.
Há alguns anos apenas, as grandes empresas se beneficiavam da uti-lização de sistemas de banco de dados, porém, a sua implementação vem ga-nhando espaço até mesmo em pequenas empresas e em pequenos comércios.
Essas interações são exemplos do que podemos denominar aplica-ções tradicionais de banco de dados, nos quais, a maioria das informaaplica-ções que são armazenadas e acessadas apresenta-se em formatos textual ou nu-mérico. Além disso, é cada vez mais crescente a utilização de bancos de dados que armazenam dados multimídia, geográficos e vetoriais. Nos últimos anos, os avanços tecnológicos geraram aplicações bastante inovadoras e in-teressantes dos sistemas de banco de dados.
Neste módulo, você terá condições de desenvolver seus conheci-mentos sobre banco de dados, pois trataremos, aqui, dos fundaconheci-mentos e da prática desse conteúdo.
Você terá oportunidade, ao longo da leitura das aulas, de perceber que a utilização de banco de dados e sistemas de banco de dados faz parte do seu cotidiano e é fundamental para o conhecimento da área de informá-tica, principalmente na área de desenvolvimento.
Neste sentido, o conteúdo deste caderno didático foi elaborado adotando-se uma dinâmica de organização na qual partiu-se de uma introdu-ção sobre a temática, passando pelos conceitos fundamentais dela, na busca da sua compreensão sobre banco de dados e sobre a importância deste na formação do técnico em Informática.
Assim, na Aula I, você será introduzido nos conceitos de banco de dados, sistema gerenciador de banco de dados (SGBD), sistema de banco de dados. Será apresentado um breve comparativo entre banco de dados e processamento tradicional de arquivos, além de apresentar situações nas quais não se necessita de um SGBD. Daremos continuidade a essa iniciação na Aula II, abordando conceitos de modelos de dados e os principais, e ainda esquema e instâncias.
Na Aula III, você será apresentado à modelagem de dados e irá co-nhecer, especificamente, o Modelo Entidade Relacionamento e seus princi-pais conceitos, como entidade, atributo, relacionamento, tipos de entidades e atributos e Diagrama de Entidade Relacionamento. Na Aula IV, você conhe-cerá o modelo de dados relacional, tido como o mais utilizado no mundo, e também os principais conceitos envolvidos nesse modelo.
Na Aula V, será apresentada a linguagem estruturada de consulta (SQL) e seus principais recursos.
Finalmente, na Aula VI, você terá oportunidade de conhecer como se faz a integração do banco de dados com a internet.
Assim, esperamos que, ao final desta disciplina, você esteja habi-litado a:
• especificar projeto físico e lógico de banco de dados;
• gerenciar transações de banco de dados por intermédio do uso de métodos, técnicas e ferramentas que envolvam os elementos de gestão de dados e transações;
• estar familiarizado com a tecnologia de banco de dados, en-volvendo linguagens de definição, consulta a banco de dados e aspectos de segurança e integridade.
Sugerimos que você dedique tempo suficiente para fazer a leitura, realizar as atividades e retirar suas dúvidas. Sempre que considerar necessá-rio, volte ao texto e refaça as atividades! Não se limite a este material; faça pesquisas, converse com professores e colegas. Você verá que aprender é uma interessante aventura!
Bons estudos!
AULA 1
Alfabetização Digital
Disciplina: Banco de Dados (carga horária: 60h).
Ementa: Conceituação sobre banco de dados. Identificação e
aná-lise de modelos de bancos de dados. Identificação e aplicação de um mode-lo de banco de dados. Conceituação de sistemas de gerência de banco de dados multiusuário. Conceituação e análise de características próprias de sistemas de gerenciamento de banco de dados multiusuário: gerenciamento de transações, controle de concorrência, recuperação de falhas, segurança e integridade de dados. Comparação de abordagens não convencionais para bancos de dados; integração de bancos de dados e internet.
AULA OBJETIVOS DE APRENDIZAGEM MATERIAIS HORÁRIACARGA
Aula 1.
Introdução - Conceituar os principais termos de banco de dados; - distinguir processamento de arqui-vos tradicional de banco de dados; - apresentar aspectos referentes à importância da aplicação e do uso de banco de dados;
- possibilitar ao aluno definir quando não for aconselhada a utilização de um SGBD. - 8h Aula 2. Sistemas de banco de da-dos: conceitos e arquitetura
- Apresentar os principais conceitos envolvidos em sistemas de banco de dados, bem como sua arquitetura, seus componentes e, principalmente, os modelos de dados mais relevantes; - tornar o aluno capaz de identificar um modelo de dados e, com isto, criar e desenvolver a modelagem de um projeto de banco de dados em qual-quer um dos modelos apresentados.
- 8h Aula 3. Modelagem de dados – Mo-delo Entidade Relaciona-mento (MER)
- Descrever os conceitos envolvidos na Modelagem Entidade Relacionamento; - apresentar os principais termos utilizados na construção de um banco de dados no MER;
- possibilitar aos alunos construir o conhecimento para a criação de mo-delos e diagramas ER, com os respec-tivos relacionamentos.
- 12h
Aula 4.
Modelagem de dados – Mode-lo Relacional (MR)
- Conceituar e apresentar os princi-pais elementos do Modelo Relacional; - demonstrar as principais aplicações do modelo na construção de projeto de banco de dados relacional; - realizar o mapeamento do Modelo Entidade Relacionamento (MER) para o Modelo Relacional (MR). - 12h Aula 5. Linguagem de consulta estruturada (SQL) - básico
- Apresentar os principais conceitos sobre linguagem de consulta estrutu-rada (SQL);
- realizar estudos sobre DDL e DML; - realizar aplicações práticas dos prin-cipais comandos SQL;
- definir e criar restrições de dados em SQL. - 16h Aula 6. Integração de banco de da-dos e internet
- Apresentar a importância do uso de SGBD integrados à internet;
- apresentar o processo de conexão de um sistema com o banco de dados na internet;
- demonstrar como se realiza a cone-xão do sistema com o banco de dados na web.
AULA 1
Alfabetização Digital
Aula 1 - Introdução
Objetivos
• conceituar os principais termos de banco de dados;
• distinguir processamento de arquivos tradicional de banco de dados;
• apresentar aspectos referentes à importância da aplicação e do uso de banco de dados;
• possibilitar ao aluno definir quando não for aconselhada a utili-zação de um SGBD.
Você já parou para pensar no crescimento do uso de computadores em nosso cotidiano? E na quantidade de empresas e de lojas comerciais que fazem uso de sistemas para gerenciar seus negócios? Pois o banco de dados (BD) e as demais tecnologias em volta dele estão entre os principais elemen-tos que provocam um grande impacto no crescimento do uso de computa-dores na sociedade moderna. O BD representa uma ferramenta essencial em quase todas as áreas nas quais os computadores são utilizados, incluindo negócios diversos, comércio eletrônico, Engenharia, Medicina, Direito, Edu-cação e as Ciências da Informação, para citar apenas algumas delas.
Bom, antes de continuarmos a falar deste termo tão importante e útil nos dias atuais, é preciso defini-lo. Vamos aprender?
Uma definição bastante genérica é dada por Elmasri & Navathe (2005):
“Um banco de dados é uma coleção de dados relacionados. Os da-dos são fatos que podem ser gravada-dos e que possuem um significa-do implícito. Por exemplo, considere nomes, números telefônicos e endereços de pessoas que você conhece. Esses dados podem ter sido escritos em uma agenda de telefones ou armazenados em um computador, por meio de programas como o Microsoft Access ou Excel. Essas informações são uma coleção de dados com um signi-ficado implícito, consequentemente, um banco de dados.”
Como a definição anterior é muito genérica, para evitar entendi-mentos equivocados, os mesmos autores descrevem ainda que um banco de dados possui as seguintes propriedades:
• um banco de dados é uma coleção lógica coerente de dados com um significado inerente; uma disposição desordenada dos dados não pode ser referenciada como um banco de dados;
• um banco de dados é projetado, construído e populado com da-dos para um propósito específico; um banco de dada-dos possui um conjunto pré-definido de usuários e aplicações;
• um banco de dados representa algum aspecto do mundo real, o qual é chamado de “minimundo”; qualquer alteração efetuada no minimundo é automaticamente refletida no banco de dados.
As leituras auxiliares são sempre importantes e enriquecedoras. Não deixe de fazê-las!
Populado: o mesmo que alimentado/povoado, de acordo com Figueiredo (2011).
Para melhor entendimento, podemos destacar alguns ingredientes necessários em um BD, conforme Elmasri e Navathe (2005):
• uma fonte de dados da qual são derivados os dados; • a interação com o mundo real;
• o público que demonstra interesse nos dados contidos no banco de dados.
Sendo assim, um banco de dados pode ser de qualquer tamanho e de complexidade variável; pode ser gerado e mantido manualmente ou pode ser automatizado (computadorizado). Desta forma, um BD pode ser cria-do e manticria-do por um conjunto de programas desenvolvicria-dos especialmente para isto, ou ainda melhor, por um Sistema Gerenciador de Banco de Dados (SGBD). Um SGBD permite que as pessoas (os usuários) criem e manipulem seus bancos de dados. O objetivo principal de um SGBD é proporcionar um ambiente eficiente para o armazenamento e para a recuperação das infor-mações no banco de dados. (ELMASRI; NAVATHE, 2005).
O conjunto formado por um banco de dados mais as aplicações que manipulam esse banco (o SGBD) é chamado de “Sistema de Banco de Dados - SBD”, conforme ilustra a figura a seguir.
Figura 1: Constituição de um SGBD.
Fonte: Acervo próprio.
Os bancos de dados são implementados e utilizados em diversas áreas. Vamos conhecê-las? A seguir, estão relacionadas algumas delas.
• Instituições de ensino: para informações administrativas, de
alunos, cursos, notas etc.
• Empresas de energia: para a gerência do consumo de energia,
geração de contas etc.
• Bancos: para informações de clientes, contas, empréstimos,
fi-nanciamentos e todas as transações bancárias.
• Meio ambiente: para o controle das questões climáticas,
infor-mações sobre desmatamentos, sobre o solo etc.
• Transações com cartão de crédito: para compras com cartões
e geração de faturas.
• Telecomunicação: para manter registros de chamadas,
geren-ciar contas, gerengeren-ciar informações de conectividade, links de internet etc.
• Finanças: para armazenar informações de compras, vendas etc. • Indústria: para gerenciamento e controle da produção e de
• Recursos humanos: para informações sobre funcionários,
salá-rios, lançamentos em folha de pagamento (benefícios e impostos pagos), geração de contracheques.
• Outras áreas.
Na verdade, um banco de dados pode ser utilizado em qualquer área. Tudo dependerá da necessidade.
1.1 Processamento tradicional de arquivos x
banco de dados
Você sabe a diferença que há entre fazer uso de processamento tra-dicional de arquivos para acessar informações e utilizar um banco de dados? Bem, é isto que iremos explicar ao longo deste caderno e também alguns outros assuntos correlacionados.
Antes de falar do processamento de arquivos e do banco de dados propriamente dito, é preciso esclarecer que o SGBD possui uma caracterís-tica de autoinformação que tem a capacidade de manter os dados na forma como são armazenados, constituindo, assim, em uma descrição completa do banco de dados. Essas informações são armazenadas num local que contém a estrutura de cada arquivo, o tipo e o formato do armazenamento de todos os tipos de dados, chamado catálogo do SGBD. O que faz com que este possa
manipular diversas bases de dados. (ELMASRI; NAVATHE, 2005).
No processamento de arquivos, o programa que manipula os dados deverá conter as informações do catálogo do SGBD, ficando limitado a mani-pular as informações que o mesmo conhece.
No processamento tradicional de arquivos, os usuários criam e de-finem os arquivos necessários para cada aplicação específica, resultando em grandes redundâncias e, muitas vezes, no desperdício de espaço de armaze-namento. Normalmente, nesses arquivos, não existe qualquer estruturação dos dados nele contidos.
Em banco de dados, não é armazenado somente o banco em si, isto é, os dados, mas sim um catálogo de dados.
Em banco de dados, o acesso às informações não requer conheci-mento das estruturas do mesmo, o que chamamos de “independência dos dados”, de acordo com Elmasri e Navathe (2005). Já no processamento tradi-cional de arquivos, o acesso a qualquer informação requer um conhecimento prévio da estrutura do arquivo.
Em banco de dados, quando houver qualquer alteração na estrutura dos dados, os programas (SGBD) não precisam ser alterados. Já em proces-samento tradicional, não. Neste caso, toda alteração na estrutura dos dados exigiria uma alteração nos programas que manipulam as informações dos arquivos.
Ainda segundo o autor supracitado, em banco de dados, as informa-ções do catálogo são chamadas de “metadados”.
Autoinformação:
é o mesmo que ter informação de si mesmo.
1.2 Profissionais e atividades envolvidas em um
SGBD
Por acaso, você conhece algum profissional que trabalha com banco de dados? Ou mesmo que utilize o banco de dados por meio do acesso aos sistemas empregados no trabalho, por exemplo?
Pois bem, em um banco de dados pequeno, por exemplo, de uso pes-soal, uma única pessoa será quem vai definir, construir e manipular o banco de dados. Porém, em um grande banco de dados, com dezenas, centenas (ou milhões) de usuários e com restrições de acesso para cada um, é necessário um controle rígido sobre o mesmo e, neste sentido, podemos identificar e destacar alguns perfis de pessoas que interagem com banco de dados, conforme desta-cam Elmasri e Navathe (2005):
• administrador do banco de dados (DBA); • projetista do banco de dados;
• analista de sistemas; • programador de aplicações; • usuário final.
Cada um desses profissionais é encarregado de uma série de fun-ções inerentes ao seu perfil. Sendo assim, segue, a seguir, uma descrição das atividades desenvolvidas por cada um deles, segundo Elmasri e Nava-the(2005).
Administrador de dados (DBA): é o supervisor do banco de dados,
responsável pela autorização de acesso ao banco, pelo monitoramento e pela coordenação do uso. Está envolvido com os aspectos físicos do banco de dados (estruturas de armazenamento, métodos de acesso etc.).
Projetistas do banco: são responsáveis pela identificação dos
da-dos e pela elaboração de estruturas apropriadas para armazená-los. Para isto, é necessário compreender os requisitos necessários aos grupos de usu-ários do banco de dados antes de sua implementação.
Analista de sistemas: determina os requisitos dos usuários e
desen-volve especificações que atendam estes requisitos.
Programadores: implementam as especificações na forma de
pro-gramas, elaborando toda a documentação.
Usuário (final): um banco de dados existe para a utilização do
usu-ário final, cujo trabalho, normalmente, requer consultas e atualizações. A maioria dos usuários utiliza programas voltados ao desempenho profissional, utilizando-os em seu dia a dia.
1.3 Vantagens e desvantagens do uso de banco
de dados
Que tal começarmos com as vantagens? O uso de banco de dados nos proporciona diversas vantagens em relação ao método de processamento tradicional de arquivos. A seguir, veremos algumas dessas vantagens e des-vantagens observadas na obra de Elmasri e Navathe (2005).
• Controle sobre a redundância: redução do espaço necessário
para armazenamento, eliminação da duplicação de esforços na manutenção das informações e redução de inconsistência na base de dados.
• Compartilhamento de dados: se diversos usuários têm
aplica-ções integradas no BD, precisa-se de um software de controle de concorrência para a atualização do banco. Facilidade na defi-nição da visão do usuário, especificando uma porção do BD que tem interesse particular de um grupo de usuários.
• Restrição de acesso não autorizado: possui um sistema de
se-gurança que garantia o acesso específico a cada usuário (perso-nalizado para grupos ou individual), possibilitando maior segu-rança ao BD.
• Fornecimento de múltiplas interfaces: disponibiliza vários
ti-pos de interface de acesso aos dados, dependendo dos níveis de conhecimento entre os usuários. O BD permite o uso de lingua-gem para consulta de usuários casuais; lingualingua-gem de programa-ção, para o programador de aplicações; formulários e menus, para acesso de outros usuários etc.
• Forçar restrições de integridade: permite a definição de regras
associadas aos dados, como identificação do tipo de dado, dado de tipo único, impossibilidade do dado não ser informado (ser nulo), relacionamento entre os dados armazenados etc. Isto irá dificultar a ocorrência de erro, porém, ele ainda poderá acon-tecer.
• Sistema de backup e recovery: possui controle do BD, no caso
de falha do hardware ou do software, permitindo a recuperação da situação anteriormente encontrada de forma ágil e prática.
• Outras vantagens de BD: quanto ao desenvolvimento de
pa-drões, permite ao DBA definir e forçar padrões (nomenclaturas, formatos, terminologias etc.), facilitando a comunicação e a co-operação entre os setores, projetos e usuários dentro da orga-nização; Garante maior flexibilidade ao permitir alterações na estrutura do BD. Projetar e implementar uma nova aplicação é mais rápido em um BD existente do que se ele não existisse ou fosse feito sobre a abordagem tradicional de arquivos. Torna dis-ponível o BD para todos os usuários (com permissão de acesso), devido ao controle de concorrência e à recuperação do SGBD. Contudo, cabe ressaltar também que existem algumas situações nas quais é desaconselhado o uso de banco de dados. Vamos ver em quais situa-ções isto acontece?
As desvantagens ocorrem quando:
• seu uso apresentar um custo desnecessário em relação à aborda-gem tradicional de arquivos;
• requerer um alto investimento inicial com software e hardware; • gerar uma sobrecarga na provisão de controle de segurança,
controle de concorrência, recuperação e integração de funções; • o banco de dados e as aplicações são simples, bem definidas e
não necessitam de mudanças no projeto;
Backup:
é o processo de criar cópia dos dados.
Recovery:
é a restauração dos dados “backupeados”.
• há necessidade de processamento em tempo real de certas apli-cações, que seriam extremamente prejudicadas pela sobrecarga causada pelo uso de um SGBD;
• os múltiplos acessos não são necessários.
Resumo
Nesta aula, você aprendeu:
• conceitos envolvidos em banco de dados;
• a importância de um bom banco de dados, principalmente em relação ao método de processamento tradicional de arquivos; • quando usar e quando não usar um banco de dados.
Atividades de aprendizagem
1. Informe um conceito para definir banco de dados.
2. Quais são as áreas do mundo globalizado que se utilizam da tecnologia de banco de dados?
3. Um grupo qualquer de informações pode ser considerado um banco de dados? Por quê?
4. Quais são os elementos essenciais para se afirmar que um determinado conjunto de informações é, de fato, um banco de dados?
5. Qual a diferença entre processamento tradicional de arquivos e banco de dados?
6. O que é o catálogo do SGBD? E metadados?
AULA 1
Alfabetização Digital
Aula 2 – Sistemas de banco de dados
(SBD): conceitos e arquitetura
Objetivos
• apresentar os principais conceitos envolvidos em sistemas de banco de dados, bem como sua arquitetura, seus componentes e, principalmente, os modelos de dados mais relevantes; • tornar o aluno capaz de identificar um modelo de dados e, com
isto, criar e desenvolver a modelagem de um projeto de banco de dados em qualquer dos modelos apresentados.
2.1 Introdução
Já tinha ouvido falar em sistema de banco de dados (SBD)? Acredito que, alguns, sim; mas, de qualquer forma, nesta aula, iremos abordar diver-sos conceitos envolvendo sistemas de banco de dados, a arquitetura de um sistema de banco de dados e seus componentes e, principalmente, apresen-tar os modelos de dados mais conhecidos e utilizados.
Para melhor compreensão de um SBD, segue, a seguir, na figura 02, um diagrama simplificado com a sua arquitetura.
Figura 2: Diagrama simplificado da arquitetura do sistema de banco de dados.
Não fique preso apenas a este caderno; busque outras fontes de estudo sobre banco de dados.
A figura 2 nos ilustra os principais elementos de um SBD:
• o banco de dados: dados armazenados e metadados ou catálogo de dados;
• SGBD: processador/otimizador de consultas e software para acessar os dados;
• SBD: banco de dados + SGBD + programas aplicativos/consultas.
2.2 Modelos de dados
Para ter condições de construir projetos de banco de dados, é preci-so, antes, conhecer e entender os modelos de dados. Vamos começar, então? De acordo com Silberschatz, Korth & Saudarshan (1999), uma gran-de vantagem do uso gran-de banco gran-de dados é o pogran-der gran-de abstração dos dados que o banco permite. Neste caso, o usuário não necessita conhecer detalhes do armazenamento de dados para acessá-los ou manipulá-los.
Os modelos de dados são um conjunto de conceitos utilizados para a descrição da estrutura de um banco de dados. A estrutura de um banco de dados deve ser entendida como sendo a definição dos tipos de dados, dos relacionamentos e das restrições que devem suportar os dados.
Baseando-nos em Elmasri e Navathe (2005), os modelos de dados podem ser classificados em três tipos básicos, descritos a seguir.
2.2.1 Modelo de alto nível
Também conhecido como modelo de dados conceituais,descreve
os dados como os usuários os percebem, segundo Elmasri e Navathe (2005). Como exemplos de modelos de alto nível, podemos destacar dois tipos, dados a seguir.
• Modelo Entidade Relacionamento: o Modelo Entidade
Relacio-namento (E-R) é baseado em uma percepção de um mundo real, que consiste em uma coleção de objetos básicos, chamados en-tidades, e de relações entre esses objetos, chamadas de relacio-namentos. Este modelo será mais bem descrito na aula 3 deste caderno. A figura 3 apresenta um exemplo do Modelo Entidade Relacionamento. Nesta figura, está representado o modelo de um pequeno banco de dados, composto das tabelas “Pessoa” e “Computador”, que registram as informações de todas as pessoas que utilizam os computadores de uma lan house, por exemplo.
Figura 3: Exemplo de banco de dados do Modelo Entidade Relacionamento.
Fonte: Disponível em: <http://lh6.ggpht.com/franciscogpneto/SLCf7mfnSuI/AAAAAAAAGM8/E77w-LNEf3o/s1600-h/image%5B3%5D.png>. Acesso em 05 de abril de 2011 (Francisco G. P. Neto).
Lan house:
é um local para as pessoas acessarem a internet. Normalmente é cobrada uma taxa. (SAWAYA, 1999)
• Modelo orientado a objeto: Assim como o modelo ER, o modelo
orientado a objetos tem por base um conjunto de objetos. Um objeto contém valores que são armazenados em variáveis; es-tes valores de variáveis são conhecidos como instâncias dentro do objeto. Além disso, um objeto contém conjuntos de códigos (chamados de operações) que operam o objeto. A principal mo-tivação para o surgimento desse modelo foi a necessidade de extrapolar os limites de armazenamento e de representação se-mântica dos dados, impostos pelo modelo relacional (tido como a melhor solução até então). A princípio, achava-se que o mode-lo orientado a objeto dominaria o mercado de banco de dados, porém isso não se confirmou e, o modelo relacional ainda é o modelo mais empregado pelas empresas ao redor do planeta. Com sua maior flexibilidade e robustez o modelo orientado a objeto tornou-se uma boa solução em sistemas complexos que lidam com tipos de informações variadas (geográficas, multimí-dia, vetoriais etc.) e em grande volume. Podemos citar como exemplos desse modelo os sistemas de informações geográficas (SIG), os sistemas CAD e CAM, que são mais facilmente construí-dos usando tipos complexos de daconstruí-dos. Na figura 4, a seguir, está um pequeno exemplo de banco de dados orientado a objetos, demonstrando um sistema de registro de informações de clien-tes, dos títulos (filmes) e de todos os movimentos/locações de títulos efetuados pelos clientes. (ELMASRI; NAVATHE, 2005).
Figura 4: Exemplo de banco de dados do modelo orientado a objeto.
Fonte: Disponível em: <http://jpleonidas.files.wordpress.com/2009/12/001.png>. Acesso em 05 de abril de 2011 (J. P. Leonidas).
Os CADs são programas que se utilizam de técnicas gráficas para o desenvolvimento de projetos; o CAM é todo processo de fabricação controlado por computador. Os dois juntos (CAD/CAM) formam um conjunto de ferramentas muito utilizadas pela Engenharia para a criação de projetos. (SAWAYA, 1999).
2.2.2 Modelo de baixo nível
Conhecido como modelo de dados físicos, descreve os detalhes de como os dados estão armazenados no computador, de acordo com Elmasri e Navathe (2005). Este modelo tem relação direta com a máquina, o hardware.
Geralmente, é mais útil e significativo para os especialistas em har-dware de computador.
Não possui exemplos de modelos diagramados descritos na litera-tura, pois atua em nível de hardware e, além disso, não é objeto de estudo deste caderno didático.
2.2.3 Modelo de dados representacionais
Modelo intermediário que oferece os conceitos que podem ser en-tendidos pelos usuários finais e também dispõe de informações de como os dados estão organizados dentro do computador, conforme relatam Elmasri e Navathe (2011). Normalmente, é utilizado pelos especialistas. Este modelo é o mais utilizado em SGBDs comerciais tradicionais.
Como exemplos de modelos de dados representacionais, podemos destacar os três que são descritos a seguir.
• Modelo relacional: utiliza um conjunto de tabelas para
repre-sentar tanto os dados como a relação entre eles. Cada tabela possui, normalmente, diversas colunas, e cada uma possui um nome único. Este modelo será mais bem descrito na aula 4 deste caderno. A figura apresenta um exemplo de banco de dados bem simples, no qual existem apenas duas tabelas, “Empregado” e “Departamento”, sendo que cada empregado está ligado a ape-nas um departamento.
Figura 5: Exemplo de banco de dados do modelo relacional.
Fonte: Disponível em: <http://lh3.ggpht.com/franciscogpneto/SMWGV0ACPjI/AAAAAAAAGrY/ Zd2ORsFnAz4/image_thumb%5B2%5D.png>. Acesso em 05 de abril de 2011 (Francisco G. P. Neto).
• Modelo de rede: neste modelo, os dados são representados por
um conjunto de registros, e as relações entre esses registros são representadas por links (ligações), os quais podem ser vistos por ponteiros (setas). Os registros são organizados no banco de dados por um conjunto arbitrário de gráficos. O modelo em rede possibilita acesso a qualquer nó da rede sem passar pela raiz da rede, diferentemente do modelo hierárquico. Um exemplo de sistema/empresa que utilizou o modelo em rede foi o sistema comercial CAIDMS, da Computer Associates. O exemplo apresen-tado a seguir, na figura 6, ilustra o mesmo banco de dados do modelo relacional anterior, porém, agora, no modelo de rede.
Figura 6: Exemplo de banco de dados do modelo em rede.
Fonte: Disponível em: <http://lh5.ggpht.com/franciscogpneto/SMWG3zwANyI/AAAAAAAAGrg/ ustUmKAn7bw/image_thumb%5B2%5D.png>. Acesso em 05 de abril de 2011 (Francisco G. P. Neto).
• Modelo hierárquico: o modelo hierárquico assemelha-se ao
mo-delo em rede, uma vez que os dados e as suas relações são representados, respectivamente, por registros e links, também. A diferença principal é que, no modelo hierárquico, os regis-tros estão organizados em árvores, em vez de serem em gráficos arbitrários. Outro aspecto que o distingue do modelo em rede é que, no modelo hierárquico, para se acessar qualquer nó do banco (da rede), é necessário sempre passar pela raiz. Nesse modelo, os dados são estruturados em hierarquias ou árvores. Os nós das hierarquias (ou da árvore) contêm ocorrências de re-gistros; cada registro é uma coleção de campos (atributos), cada um contendo apenas uma informação. O registro da hierarquia que precede aos outros é o registro pai; os outros, por sua vez, são chamados de registros filhos. Um exemplo de sistema/em-presa que adotou o modelo hierárquico foi o sistema comercial Information Management System, da IBM Corp (IMS), e alguns outros, como o System 2K (da SAS Inc.) e o TDMS. O exemplo a seguir, da figura 7, apresenta o mesmo banco de dados dos dois modelos anteriores (relacional e de rede), só que, agora, no
mo-Figura 7: Exemplo de banco de dados do modelo hierárquico.
Fonte: Disponível em: <http://lh5.ggpht.com/franciscogpneto/SMWHaftiOSI/AAAAAAAAGro/dAe-R1_ w5HI/image_thumb%5B3%5D.png>. Acesso em 05 de abril de 2011 (Francisco G. P. Neto).
Como você pode observar, existem diferentes modelos de dados em BD. Porém, devido ao tempo curto para estudo da disciplina e, principal-mente, à maior utilização do modelo relacional em relação aos demais, este caderno concentrar-se-á na explicação mais detalhada apenas dos modelos que envolvem o relacional (o Modelo Entidade Relacionamento e o Modelo Relacional).
2.3 Esquema
Certamente, você já ouviu falar em esquema, porém, muito prova-velmente, em outra conotação. Portanto, para não confundirmos esquema em banco de dados com “outros esquemas”, vamos aprendê-lo logo?
Bom, como descrito, muitas vezes, as pessoas confundem os termos “descrição” do banco de dados com o banco de dados propriamente dito. A descrição do banco de dados é conhecida como “esquema” do banco de dados; este é definido durante o desenvolvimento (criação) do projeto do banco de dados. Um esquema, uma vez definido, não deve ser modificado frequentemente; desta forma, a sua definição requer bastante análise e mui-tos critérios.
No esquema, basicamente, será definida a estrutura do banco de dados (tabelas, atributos, domínios, relacionamentos, restrições), conforme Date (2000). A maioria dos modelos de dados apresenta algumas convenções para a exibição de esquemas por meio de diagramas, conforme ilustram as figuras da seção 2.2.
Para uma melhor compreensão de um esquema, vamos fazer uma analogia com linguagem de programação e algoritmos. Neste sentido, as va-riáveis e os tipos de dados assumidos por elas seriam o esquema.
Se ainda não ficou claro, não se preocupem, pois, na aula 4, serão apresentados mais exemplos de esquemas.
2.4 Instância
Para entendermos o que é uma instância, vamos aproveitar da mes-ma analogia feita com linguagem de programes-mação e algoritmos, apresentada na seção anterior (2.3). Entende-se por instância do banco de dados os valo-res/dados assumidos pelas variáveis do programa. Assim, podemos dizer que os dados (valores) armazenados em um banco de dados, em um determinado instante do tempo, formam um conjunto chamado de “instância do banco de dados”, conforme concebem Elmasri e Navathe (2005).
A instância, diferentemente do esquema, altera toda vez que o banco de dados sofre qualquer modificação de conteúdo.
O SGBD é responsável por garantir que toda instância do banco de dados satisfaça ao esquema do banco de dados, respeitando sua estrutura e suas restrições.
Resumo
Nesta aula, você aprendeu:
• os principais conceitos de sistemas de banco de dados; • a arquitetura de um SBD e os componentes dessa arquitetura; • a conhecer e a identificar um modelo de dados;
• a planejar e AA desenvolver a modelagem de um projeto de banco de dados nos diferentes modelos apresentados (principal-mente o relacional).
Atividades de aprendizagem
1. Quais são os elementos que compõem a arquitetura de um sistema de banco de dados?
2. O que são os modelos de dados?
3. Qual a principal motivação para a criação do modelo relacional? E para o modelo orientado a objeto?
4. O que são esquema e instância em banco de dados?
Não deixe de acompanhar as novidades e inovações do SGBD! Lembre-se, a aprendizagem é sempre contínua!
AULA 1
Alfabetização Digital
Aula 3 – Modelagem de dados – Modelo
Entidade Relacionamento – MER
Objetivos
• descrever os conceitos envolvidos na modelagem Entidade Re-lacionamento;
• apresentar os principais termos utilizados na construção de um banco de dados no MER;
• possibilitar aos alunos a construção do conhecimento para a criação de modelos e diagramas ER, com os respectivos rela-cionamentos.
3.1 Introdução
Agora que já conhecemos os tipos de modelos de dados, vamos iniciar nossos estudos descrevendo sobre o modelo mais simples, mas não menos útil na construção do projeto de banco de dados relacional. Vamos lá?
O Modelo Entidade Relacionamento é um modelo de dados con-ceitual de alto nível, tido como o mais popular; é utilizado principalmente durante o processo de projeto de banco de dados, conforme relatam Elmasri e Navathe (2011).
No MER, os conceitos envolvidos na construção de um bom projeto de banco de dados foram planejados para estar o mais próximo possível do entendimento e da visão que o usuário tem dos dados, não se preocupando em representar como esses dados estarão realmente armazenados.
A construção de um projeto de banco de dados é constituída de al-gumas fases; cada uma delas, responsável pela realização de alal-gumas ações específicas, conforme ilustra a figura 8. Na fase inicial, de partida, são ob-servados aspectos do mundo real, chamados de “minimundo”. A partir daí, realiza-se a obtenção e a análise dos requisitos por meio de reuniões e de outras formas, nas quais se discutem todas as questões pertinentes ao que se deseja do sistema de banco de dados. Vencida esta fase, reúnem-se to-das as informações (requisitos) para a construção do projeto conceitual da base de dados. Na fase de projeto conceitual, é desenvolvido o esquema conceitual, no qual são especificados os esquemas do banco de dados em construção. É neste momento em que mais se aplicam os modelos de entida-de relacionamento. Na fase entida-de mapeamento do moentida-delo entida-de dados, também conhecida como projeto lógico, o objetivo é transformar o esquema de mo-delo de dados de alto nível (projeto conceitual) em um momo-delo de dados de implementação. Até esta fase, tudo que se define é independente do SGBD a ser utilizado. Qualquer que seja o sistema gerenciador de banco de dados
adotado, o que foi desenvolvido até então será perfeitamente aproveitado. A partir da fase de mapeamento, é preciso conhecer qual o SGBD que será utilizado e realizar todo o mapeamento baseado especificamente no sistema escolhido. A última etapa é a fase do projeto físico, na qual são definidas as estruturas de armazenamento interno, os índices, os caminhos de acesso e as organizações de arquivo para os arquivos do banco de dados, conforme descrevem Elmasri e Navathe (2005).
Figura 8: Diagrama ilustrando as principais fases de um projeto de banco de dados.
Fonte: Acervo próprio.
3.2 Entidade, atributo e relacionamento
Você já tinha lido ou ouvido falar de algum desses termos? Prova-velmente sim, porém, talvez em outro contexto. Em se tratando do contexto de banco de dados, vamos ver o que são e como são utilizados?
Comecemos falando, então, de entidade. O principal objeto ou o
objeto básico que um modelo ER representa é a entidade. Uma entidade é
um objeto com uma existência própria, podendo ser física (concreta) – uma pessoa, um veículo, um equipamento – ou abstrata (conceitual) – um depar-tamento, um curso, um cargo, uma conta. (ELMASRI; NAVATHE, 2005).
Ainda segundo Elmasri e Navathe (2005), cada entidade possui um conjunto de blocos de informações, devidamente organizados, que a carac-teriza e a identifica. Esses “blocos” de informações são chamados de atribu-tos. Para melhor compreensão, podemos ter, como exemplos de entidades,
PROFESSOR, ALUNO, DISCIPLINA. A entidade PROFESSOR poderia ser consti-tuída, por exemplo, pelos atributos: Matrícula, MatrProf, NomeProf, Função, Salário. A entidade DISCIPLINA teria os atributos: Código, NomeDisc, Pro-fDisp, CargaHorária, NumAlunosMatr. Já a entidade ALUNO seria constituída dos atributos: MatrAluno, NomeAlu, Curso, Média. Cada um dos atributos de cada entidade terá um valor particular, e o conjunto desses valores é que é responsável pela maior ocupação de espaço de armazenamento na base de dados do banco.
Agora que vimos entidade e atributo, vamos entender relaciona-mento. De acordo com Date (2000), o relacionamento é uma associação
entre uma ou várias entidades. Por exemplo: ao fazermos a associação entre as entidades PROFESSOR e DISCIPLINA, estaremos construindo um relaciona-mento entre ambas, que poderíamos chamar de Ministra ou Leciona, deno-tando que o professor ministra ou leciona a disciplina.
Para maior controle e organização dos dados, os relacionamentos são criados com algumas restrições. Essas restrições chamam-se “razão de cardinalidade”, e especificam a quantidade de instâncias em um
relaciona-mento que os elerelaciona-mentos das entidades podem participar, segundo Elmasri e Navathe (2005). De acordo com Elmasri e Navathe (2011) a razão de cardina-lidade pode ser classificada em três tipos, descritos a seguir.
• 1:1 (lê-se um para um): significa que só pode haver uma única
instância entre as duas entidades envolvidas, ou seja, sendo duas entidades A e B, uma ocorrência em A estará associada com, no máximo, uma única ocorrência em B, e uma ocorrência em B estará associada com, no máximo, uma única ocorrência em A. Por exemplo: o relacionamento Gera, entre as entidades PEDIDO e FATURA; pode conter a cardinalidade 1:1, indicando que um pedido só pode gerar uma única fatura, e, ainda, que uma fatura só pode ter sido gerada por um único pedido. A representação para este relacionamento está exibida na figura 09 (como fazer esta representação será explicado na seção 3.4, deste caderno).
Figura 9: Exemplo de diagrama de relacionamento 1:1.
Fonte: Acervo próprio.
• 1:N ou N:1 (lê-se um para N ou N para um - onde N signifi-ca muitos): signifisignifi-ca que, em uma das entidades (1), só poderá
haver um única instância relacionada; na outra entidade (N), poderá haver uma ou mais instâncias relacionadas, ou seja, sen-do duas entidades A e B, uma ocorrência em A estará associada
com uma ou várias ocorrências em B, e uma ocorrência em B estará associada com, no máximo, uma única ocorrência em A. Por exemplo: o relacionamento Leciona, entre as entidades PRO-FESSOR e DISCIPLINA, representado na figura 10, normalmente possui uma razão de cardinalidade de 1:N, na qual um professor pode lecionar várias disciplinas e uma determinada disciplina só pode ser lecionada por um único professor. O digrama de repre-sentação desse relacionamento está ilustrado na figura 10.
Figura 10: Exemplo de diagrama de relacionamento 1:N.
Fonte: Acervo próprio.
• M:N (lê-se M para N - onde M e N significam muitos): significa
que poderá haver uma ou várias instâncias em ambas as en-tidades envolvidas, ou seja, sendo duas enen-tidades A e B, uma ocorrência em A poderá estar associada a uma ou várias ocor-rências em B, e vice-versa. Por exemplo: no relacionamento Fre-quenta, entre as entidades ALUNO e DISCIPLINA, um aluno pode frequentar várias disciplinas, e uma mesma disciplina pode ser frequentada por vários alunos. O diagrama para representar este relacionamento, seria conforme o exposto na figura 11.
Figura 11: Exemplo de diagrama de relacionamento M:N.
Fonte: Acervo próprio.
3.3 Tipos de entidades e atributos
As entidades e os atributos são classificados em diferentes tipos. Que tal conhecermos esses tipos?
Para isto, vamos começar com a classificação dos tipos de entidades, segundo Date (2000).
• Entidade fraca: são as entidades que não possuem
atributos--chave próprios, isto é, que dependem dos atributosatributos--chave de uma outra entidade. Por exemplo: numa relação entre as duas entidades, DEPENDENTE e EMPREGADO, todos os elementos da entidade Dependente são dependentes da entidade Empregado, ou seja, só irá existir um dependente se houver o registro do empregado correspondente ao mesmo. Portanto, a entidade De-pendente é uma entidade fraca.
• Entidade forte: são as entidades que possuem seus próprios
ain-da utilizando o exemplo anterior, a entiain-dade EMPREGADO é inde-pendente de qualquer outra entidade, ou seja, possui existência própria. Neste caso, a entidade Empregado é uma entidade forte. Exemplos da representação de entidade fraca e de entidade forte estão na próxima seção; mais detalhes na aula 4, deste caderno.
De acordo com Silberschatz, Korth & Sudarshan (1999), os atributos, no modelo ER, podem ser caracterizados pelos seguintes tipos descritos a seguir.
• Simples ou compostos: atributos simples são aqueles que não
são divisíveis, ou seja, o seu conteúdo não pode ser separado em partes, como, por exemplo: matrícula, função, salário. Já os compostos, eles podem ser separados em partes (isto é, sepa-rados em outros atributos), caso seja necessário. Por exemplo: NomeProf poderia ser estruturado em PriNomeProf, SegNome-Prof e UltNomeSegNome-Prof. Sendo que PriNomeSegNome-Prof corresponderia ao primeiro nome do professor, SegNomeProf, ao segundo nome, e UltNomeProf, ao último nome do professor.
• Monovalorados ou multivalorados: atributos monovalorados
são aqueles constituídos de um único valor para uma referida entidade, por exemplo: data_de_nascimento, cpf, salário de uma entidade chamada EMPREGADO. Os multivalorados são aqueles que podem assumir mais de um valor para uma determi-nada instância de um atributo. Como exemplos, podemos citar os atributos dependente, telefone e e-mail. Ainda considerando a entidade Empregado, citada anteriormente, cada um desses atributos poderia possuir nenhum, um ou mais valores em seu conteúdo. No caso dos atributos multivalorados, o mais adequa-do é que se estabeleçam limites inferiores e, principalmente, superiores para tais atributos.
• Derivados: o valor desse tipo de atributo é derivado de outro
atributo ou entidade a ele relacionadas. Para um melhor enten-dimento, podemos citar o atributo idade, que pode ser obtido através da diferença entre a data atual do sistema e a data_de_ nascimento informada na entidade da pessoa.
• Nulo: é utilizado quando uma entidade não possuir valor para
um determinado atributo. Como exemplos, podemos citar os atributos: dependente (nem todos os empregados possuem de-pendentes), e-mail (nem todos os empregados possuem email), celular (nem todos possuem). Nulo, na verdade, é a ausência de valor, ou seja, quando você deixa de informar o valor para um determinado atributo, o mesmo irá assumir o valor nulo (como padrão). Mas, atenção! Nulo é diferente de espaço em branco. Se você pressionar a barra de espaço em um determinado atri-buto (dependente, email, celular, por exemplo) na hora da inser-ção de dados, isso não significa nulo, e sim espaço em branco.
3.4 Diagrama Entidade Relacionamento (DER)
Você tem algum conhecimento sobre DER? Sabe para que serve? Bom, se a sua resposta for não, não há problema, pois estamos aqui para explicar. Sendo assim, vamos iniciar.
O Modelo Entidade Relacionamento é representado através de al-guns símbolos que compõem o Diagrama Entidade Relacionamento (DER).
Para cada elemento de um relacionamento (entidade, atributo, re-lacionamento, razão de cardinalidade), existe um símbolo representativo. Sendo assim, vamos apresentar cada um desses símbolos a seguir, ilustrados na figura 12.
Figura 12: Resumo de notação de diagrama ER.
Fonte: Acervo próprio.
Agora, vamos apresentar três exemplos de DER, na figura 13, para entendermos melhor a sua aplicação.
Passos para construir um Modelo Entidade
Relação: 1º) identificar as
entidades; 2º) para cada entidade,
procurar identificar os atributos necessários e definir a chave primária; 3º) buscar identificar todos os relacionamentos entre as entidades; 4º) procurar validar o modelo obtido e repetir este processo desde o 1º passo, caso seja necessário.
Dicas para a construção de diagramas ER:
- a presença de um substantivo, usualmente, indica uma entidade; - a presença de um
verbo é uma forte indicação de um relacionamento.
Figura 13: a) Demonstra um relacionamento uniário Gerencia, entre a entidade EMPREGADO e ela mesma; b) ilustra o relacionamento binário Possui, entre as entidades FUNCIONÁRIO e DEPENDENTE; c) exibe um relacionamento ternário Ministra, entre as entidades PROFESSOR, DISCIPLINA e ALUNO (quando não há exigências, pode-se omitir a razão de cardinalidade e os atributos).
Fonte: Acervo próprio.
Segundo Elmasri e Navathe (2005), a quantidade de entidades par-ticipantes de um mesmo relacionamento é caracterizada como “Grau do Relacionamento”. Assim, o grau do relacionamento pode ser de três tipos,
conforme os descrevemos a seguir.
Uniário: também chamado de autorrelacionamento ou
relaciona-mento recursivo, é a relação de uma entidade com ela mesma, ou seja, ape-nas uma entidade participante. O item (a) da figura 13 demonstra um bom exemplo de autorrelacionamento.
Binário: é o relacionamento entre duas entidades distintas. O item
(b) da figura 13 apresenta um exemplo de relacionamento binário.
Ternário: é o relacionamento envolvendo três entidades distintas.
O item (c) da figura 13 ilustra um exemplo de relacionamento ternário. Podem existir relacionamentos envolvendo mais de três entidades, porém, isto não será objeto de estudo neste caderno didático.
Resumo
Nesta aula, você aprendeu:
• os principais conceitos e termos envolvidos num Modelo Entida-de Relacionamento (ER);
• a aplicação de um modelo ER num projeto de banco de dados; • planejar e construir modelos e diagramas ER de um banco de
dados.
Atividades de aprendizagem
1. Qual o principal objetivo do Modelo Entidade Relacionamento (MER)? 2. O que é mapeamento do modelo de banco de dados?
3. Descreva a sequência de ações para se construir uma modelagem Enti-dade Relacionamento.
4. Defina e exemplifique os termos entidade, atributo e relacionamento. 5. Construa exemplos de diagramas de relacionamento de cardinalidade
1:1, 1:N e M:N. No mínimo 1 de cada e que sejam diferentes dos exemplos do caderno da disciplina.
6. O que significa grau de relacionamento? Quais são os tipos? Explique cada um deles.
7. Desenvolva um DER para que um banco possa gerenciar as contas parti-culares de cada cliente em suas respectivas agências. Você deverá de-cidir quais atributos de cada entidade serão necessários para o modelo. 8. Preencha os diagramas a seguir com as respectivas entidades e os seus
rela-cionamentos; informe também qual o grau de cardinalidade em cada caso. a.
Entidades Relacionamento
Banco, agência Administra
b.
Entidades Relacionamento
AULA 1
Alfabetização Digital
Aula 4 – Modelagem de dados – Modelo
Relacional (MR)
Objetivos
• conceituar e apresentar os principais elementos do modelo re-lacional;
• demonstrar as principais aplicações do modelo na construção de projeto de banco de dados relacional;
• realizar o mapeamento do Modelo Entidade Relacionamento (MER) para o Modelo Relacional (MR).
4.1 Introdução
Agora que aprendemos sobre o Modelo ER, que tal conhecermos o Modelo Relacional? Você observará, inclusive, que existem algumas seme-lhanças entre ambos.
O Modelo Relacional tem muita semelhança com o Modelo ER. Eu diria que o MR é complementar ao MER.
Conforme Elmasri e Navathe (2005), o Modelo Relacional represen-ta um banco de dados como uma coleção de relações comumente chamadas
de tabelas. Cada relação é entendida como uma tabela que contém valores, e cada linha nesta tabela é composta de um conjunto de dados relacionados. Os valores contidos nas linhas seriam as instâncias de uma entidade ou de um relacionamento.
Cada relação ou cada tabela é composta de linhas e colunas. Ainda segundo o autor referenciado anteriormente, na terminologia do Modelo Re-lacional, uma tabela é chamada de relação, um linha é chamada de tupla e
as colunas são chamadas de atributos.
A figura 14 ilustra cada um desses elementos (destacados em cores diferentes) do Modelo Relacional na tabela PRODUTO. Observem atentamente!
Figura 14: Relação Produto, identificando cada um dos elementos.
Fonte: Acervo próprio.
Apesar do crescimento do uso de outros modelos, o MR ainda é o mais utilizado pelas empresas.
4.2 Relações, domínios, tuplas e atributos
Apesar de serem termos de nomenclaturas diferentes, você irá per-ceber que eles têm praticamente a mesma função de alguns dos termos da aula 3. Vamos conferir?
As relações em modelos relacionais, conforme dito anteriormente,
representam o conjunto de informações de uma tabela (entidade no MER).
Assim como no Modelo ER, as relações são construídas definindo-se, primei-ramente, o esquema da relação, no qual são especificados o nome da relação e os atributos.
A especificação dos atributos segue-se da definição dos domínios
dos mesmos. Um domínio consiste de um conjunto de valores (dados)
atômi-cos que um atributo pode assumir. Um valor é dito atômico quando o mesmo não pode ser dividido, separado, ou seja, ele é indivisível. Assim, de acordo com Date (2000), um domínio é determinado pelo tipo de dado que um
atributo pode assumir. Por exemplo: um atributo CÓDIGO, do tipo inteiro, só pode aceitar dados numéricos (números) inteiros; um atributo DESCRI-ÇÃO, do tipo caractere, de tamanho 20, pode aceitar letras, números, ponto, acento etc., porém, não pode ultrapassar 20 caracteres.
Conforme mencionado anteriormente, as tuplas são as linhas da
re-lação. Tomando o exemplo da figura 14, a linha com | 1020 | Óleo | 9 | 2,15 | corresponde a uma tupla da relação ALUNO. Assim como | 1045 | Arroz | 10 | 8,99 | também constitui uma tupla da mesma relação.
Os atributos de uma relação são representados pelas colunas. Os atributos, aqui, têm a mesma representação que no Modelo ER.
4.3 Atributos-chave
Já leram ou ouviram alguma coisa sobre atributos-chave? De qual-quer forma, é importante o bom entendimento desta seção, pois, dela, de-penderão muitas outras informações constantes no restante deste caderno.
Uma relação é constituída de um conjunto de tuplas e atributos dis-tintos. Para uma correta distinção das instâncias de uma relação, o Modelo Relacional adotou o conceito de atributo-chave. De acordo com Elmasri e
Navathe (2005), o atributo chave pode ser constituído de um ou mais atri-butos, e eles são encarregados de identificar e distinguir, de forma única e exclusiva, cada tupla de uma relação; assim, são chamados de superchave.
Toda relação irá possuir, no mínimo, uma superchave, que será o conjunto
de todos os seus atributos.
Ainda segundo o mesmo autor, as chaves de uma relação podem ser classificadas das seguintes formas, descritas a seguir.
• Chave primária: composta por um ou mais atributos capazes de
identificar, de forma única e exclusiva, cada tupla da relação. Quando é constituída de mais de um atributo, ela é chamada de chave primária composta, e cada um dos atributos desta Os atributos-chave são
essenciais em BD; por isso, procurem assimilar bem as informações apresentadas.
chave composta deve possuir a capacidade de, sozinho, também identificar de forma única cada tupla da relação. A chave pri-mária no MR é representada colocando-se o(s) atributo(s)-chave sublinhado(s). Exemplos: o atributo Código da relação PRODUTO é uma chave primária, conforme ilustrado na figura 15, item (a); numa relação ALUNO, constituída dos atributos matrícula, CPF, nome, curso, e-mail, os atributos Matrícula e CPF formam uma cha-ve primária composta, conforme ilustrado na figura 15, item (b).
a. Produto
Código Descrição Qtde ValorUnit b. Aluno
Matrícula CPF Nome Curso e-mail
Figura 15: Esquema das relações PRODUTO e ALUNO.
Fonte: Acervo próprio.
• Chave candidata: formada pelo conjunto de atributos capazes
de se tornarem uma chave primária. Exemplo: qualquer um dos atributos Matrícula e CPF da relação ALUNO são chaves candi-datas.
• Chave estrangeira: formada pela chave primária de uma outra
relação. Exemplo: considerando as relações PRODUTO com os atributos código, descrição, Qtde e ValorUnit, e ITENS_PEDIDO com os atributos CodProd, CodPed, Quant, o atributo CodProd da relação ITENS_PEDIDO é chave estrangeira, pois representa o atributo Código da relação PRODUTO, conforme ilustra a figura 16. Na terminologia do MR, a chave estrangeira é representada colocando o atributo-chave em itálico.
Produto
Código Descrição Qtde ValorUnit Itens_Pedido
CódProd CodPed Quant
Figura 16: Modelo identificando chave estrangeira.
Fonte: Acervo próprio.
4.4 Mapeamento do MER para MR
Já participou de algum projeto no qual foi realizado o mapeamento de MER para MR? Tem ideia do que seja?
Nesta seção, iremos aprender o que é e como fazer um mapeamen-to desse tipo.
Embora seja crescente o uso da modelagem orientada a objeto, ainda é grande o uso, em projetos de banco de dados, da modelagem em alto
nível (o MER). Contudo, o uso dessa modelagem é apenas parte do processo de construção do projeto de banco de dados.
O resultado da modelagem ER são esquemas de observações, ou seja, Diagramas Entidade Relacionamento (DER) que devem ser integrados, posteriormente, para originar apenas um grande e único esquema. O mape-amento do Modelo Entidade Relacionmape-amento para o Modelo Relacional é uti-lizado justamente para este fim, para complementar e completar o projeto de banco de dados.
A seguir, segue um resumo dos passos básicos necessários para se fazer o mapeamento do MER para o MR, baseado na obra de Elmasri e Nava-the (2005).
Passo 1: todas as entidades são mapeadas para uma relação
con-tendo os mesmos atributos do MER. Veja o exemplo da figura 17.
Figura 17: Mapeamento de entidade MER para MR.
Fonte: Acervo próprio.
Na figura 17, foi apresentado o MER de uma entidade chamada Em-pregados, com os atributos CPF (onde a bolinha preenchida representa chave primária), nome e idade (as bolinhas vazias representam atributos comuns). Fazendo-se o mapeamento para o Modelo Relacional, a relação Empregados ficou como mostrado na figura.
Passo 2: para entidade fraca é criada a relação contendo todos os
seus atributos, tendo acrescido, como chave estrangeira, a chave primária da entidade forte (pai). Veja o exemplo da figura 18.
Figura 18: Mapeamento de entidade fraca de MER para MR.
Na figura 18, foi apresentado o MER do relacionamento Possui en-tre as entidades Funcionário, com os atributos CodFunc, Nome, DataNasc e Idade e Dependente, com os atributos CodDep, Nome e DataN. Fazendo-se o mapeamento para o Modelo Relacional, a relação Dependente ficou como mostrado na figura.
Passo 3: para relacionamentos 1:1 - dentre as relações que
ma-peiam as entidades participantes, escolha uma delas (a que for mais fraca, dependente) e inclua como chave estrangeira a chave primária da outra. Veja o exemplo da figura 19.
Figura 19: Mapeamento de relacionamento 1:1 de MER para MR.
Fonte: Acervo próprio.
Na figura 19, foi apresentado o MER do relacionamento Retirou (com o atributo DtRetirada) entre as entidades Pessoas, com os atributos CPF, Nome e Endereço e CateirasMotorista, com os atributos Numero, Validade, DataExpedição e Categoria. Fazendo-se o mapeamento para o Modelo Rela-cional, as relações Pessoas e CarteirasMotorista ficaram como mostrado na figura.
Passo 4: para relacionamentos 1:N – escolha a relação que
repre-senta a entidade presente no lado N e acrescente, como chave estrangei-ra, a chave primária da entidade do lado 1. Veja o exemplo da figura 18, no passo 2.
Passo 5: para relacionamentos M:N – é criada uma nova relação
contendo, como chaves estrangeiras, as chaves primárias das entidades par-ticipantes mais os atributos do relacionamento. Veja o exemplo da figura 20.
Figura 20: Mapeamento de relacionamento M:N de MER para MR.
Fonte: Acervo próprio.
Na figura 20, foi apresentado o MER do relacionamento Participa (com o atributo DataInício) entre as entidades Empregado, com os atributos CPF, Nome e Projeto, com os atributos Código e Nome. Fazendo-se o mapea-mento para o Modelo Relacional, as relações Empregados, Projeto e Partici-pa (que virou uma entidade) ficaram como mostrado na figura.
Resumo
Nesta aula, você aprendeu:
• os principais conceitos e termos envolvidos num Modelo Rela-cional;
• a aplicação de um Modelo Relacional num projeto de banco de dados;
• mapear um Modelo ER em um Modelo Relacional;
• planejar e construir modelos relacionais de um banco de dados.
Atividades de aprendizagem
1. Defina e exemplifique cada um dos seguintes termos em banco de dados: relação, tupla e domínio.
3. Faça o mapeamento dos seguintes modelos ER para o Modelo Relacional: a.
b.
4. Pesquise e apresente três exemplos de representação de banco de dados relacionais. Pode utilizar o próprio local de trabalho como cenário para isto.
5. O que são atributos-chave?
6. Qual a diferença entre chave primária e superchave?
