manual do professor – banco de dados · 3 banco de dados pretendemos contribuir para resolver o...

Manual do Professor – Banco de Dados

2

Banc

o de

Dad

os

10

Manual do Professor1. Introdução

Por muito tempo, a educação profissional foi desprezada e considerada de segunda classe. Atualmente, a opção pela formação técnica é festejada, pois alia os conhecimentos do “saber fazer” com a formação geral do “conhecer” e do “saber ser”; é a formação integral do estudante.

Este livro didático é mais uma ferramenta para a formação integral, pois alia o instrumental para aplicação prática com as bases científicas e tecnológi-cas, ou seja, permite aplicar a ciência em soluções do dia a dia.

Além do livro, compõe esta formação do técnico o preparo do professor, as práticas laboratoriais, o estágio, a visita técnica e outras atividades inerentes a cada plano de curso. Dessa forma, o livro, com sua estruturação pedagogica-mente elaborada, é uma ferramenta altamente relevante, pois é fio condutor dessas atividades formativas.

Ele está contextualizado com a realidade, as necessidades do mundo do trabalho, os arranjos produtivos, o interesse da inclusão social e a aplicação cotidiana. Essa contextualização elimina a dicotomia entre atividade intelec-tual e atividade manual, pois não só prepara o profissional para trabalhar em atividades produtivas, mas também com conhecimentos e atitudes, com vistas à atuação política na sociedade. Afinal, é desejo de todo educador formar cida-dãos produtivos.

Outro valor pedagógico acompanha esta obra: o fortalecimento mútuo da formação geral e da formação específica (técnica). O Exame Nacional do Ensino Médio (ENEM) tem demonstrado que os alunos que estudam em um curso técnico tiram melhores notas, pois ao estudar para resolver um pro-blema prático ele aprimora os conhecimentos da formação geral (química, física, matemática, etc.); e ao contrário, quando estudam uma disciplina geral passam a aprimorar possibilidades da parte técnica.

3

Banco de Dados

Pretendemos contribuir para resolver o problema do desemprego, preparando os alunos para atuar na área científica, industrial, de transações e comercial, conforme seu interesse. Por outro lado, preparamos os alunos para ser independentes no processo formativo, permitindo que trabalhem durante parte do dia no comércio ou na indústria e prossigam em seus estudos superiores no contraturno. Dessa forma, podem constituir seu iti-nerário formativo e, ao concluir um curso superior, serão robustamente formados em relação a outros, que não tiveram a oportunidade de realizar um curso técnico.

Por fim, este livro pretende ser útil para a economia brasileira, aprimo-rando nossa força produtiva ao mesmo tempo em que dispensa a importação de técnicos estrangeiros para atender às demandas da nossa economia.

1.1 Por que a Formação Técnica de Nível Médio É Importante?

O técnico desempenha papel vital no desenvolvimento do país por meio da criação de recursos humanos qualificados, aumento da produtividade industrial e melhoria da qualidade de vida.

Alguns benefícios do ensino profissionalizante para o formando:

• Aumento dos salários em comparação com aqueles que têm ape-nas o Ensino Médio;

• Maior estabilidade no emprego;

• Maior rapidez para adentrar ao mercado de trabalho;

• Facilidade em conciliar trabalho e estudos;

• Mais de 72% ao se formarem estão empregados;

• Mais de 65% dos concluintes passam a trabalhar naquilo que gos-tam e em que se formaram.

Esses dados são oriundos de pesquisas. Uma delas, intitulada “Educação profissional e você no mercado de trabalho”, realizada pela Fundação Getúlio Vargas e o Instituto Votorantim, comprova o acerto do Governo ao colocar, entre os quatro eixos do Plano de Desenvolvimento da Educação (PDE), investimentos para a popularização da Educação Profissional. Para as empre-sas, os cursos oferecidos pelas escolas profissionais atendem de forma mais eficiente às diferentes necessidades dos negócios.

Outra pesquisa, feita em 2009 pela Secretaria de Educação Profissional e Tecnológica (Setec), órgão do Ministério da Educação (MEC), chamada “Pesquisa nacional de egressos”, revelou também que de cada dez alunos, seis recebem salário na média da categoria. O percentual dos que qualificaram a formação recebida como “boa” e “ótima” foi de 90%.

4

Banc

o de

Dad

os

2. Ensino Profissionalizante no Brasil e Necessidade do Livro Didático Técnico

O Decreto Federal nº 5.154/2004 estabelece inúmeras possibilida-des de combinar a formação geral com a formação técnica específica. Os cursos técnicos podem ser ofertados da seguinte forma:

a) Integrado – ao mesmo tempo em que estuda disciplinas de for-mação geral o aluno também recebe conteúdos da parte técnica, na mesma escola e no mesmo turno.

b) Concomitante – num turno o aluno estuda numa escola que só oferece Ensino Médio e num outro turno ou escola recebe a for-mação técnica.

c) Subsequente – o aluno só vai para as aulas técnicas, no caso de já ter concluído o Ensino Médio.

Com o Decreto Federal no 5.840/2006, foi criado o programa de profissionalização para a modalidade Jovens e Adultos (Proeja) em Nível Médio, que é uma variante da forma integrada.

Em 2008, após ser aprovado pelo Conselho Nacional de Educação pelo Parecer CNE/CEB nº 11/2008, foi lançado o Catálogo Nacional de Cursos Técnicos, com o fim de orientar a oferta desses cursos em nível nacional.

O Catálogo consolidou diversas nomenclaturas em 185 denomina-ções de cursos. Estes estão organizados em 12 eixos tecnológicos, a saber:

1. Ambiente, Saúde e Segurança2. Apoio Educacional3. Controle e Processos Industriais4. Gestão e Negócios5. Hospitalidade e Lazer6. Informação e Comunicação7. Infraestrutura8. Militar9. Produção Alimentícia10. Produção Cultural e Design11. Produção Industrial12. Recursos Naturais.

Para cada curso, o Catálogo estabelece carga horária mínima para a parte técnica (de 800 a 1 200 horas), perfil profissional, possibilidades de temas a serem abordados na formação, possibilidades de atuação e infraestrutura recomendada para realização do curso. Com isso, passa a ser um mecanismo de organização e orientação da oferta nacional e tem função indutora ao destacar novas ofertas em nichos tecnológicos, culturais, ambientais e produtivos, para formação do técnico de Nível Médio.

5

Banco de Dados

Dessa forma, passamos a ter no Brasil uma nova estruturação legal para a oferta destes cursos. Ao mesmo tempo, os governos federal e esta-duais passaram a investir em novas escolas técnicas, aumentando a oferta de vagas. Dados divulgados pelo Ministério da Educação apontaram que o número de alunos na educação profissionalizante passou de 693 mil em 2007 para 795 mil em 2008 – um crescimento de 14,7%. A demanda por vagas em cursos técnicos tem tendência para aumentar, tanto devido à nova importância social e legal dada a esses cursos, como também pelo cresci-mento do Brasil.

COMPARAÇÃO DE MATRÍCULAS BRASIL

Comparação de Matrículas da Educação Básica por Etapa e Modalidade – Brasil, 2007 e 2008.

Etapas/Modalidades de Educação Básica

Matrículas / Ano

2007 2008 Diferença 2007-2008 Variação 2007-2008

Educação Básica 53.028.928 53.232.868 203.940 0,4

Educação Infantil 6.509.868 6.719.261 209.393 3,2

• Creche 1.579.581 1.751.736 172.155 10,9

• Pré-escola 4.930.287 4.967.525 37.238 0,8

Ensino Fundamental 32.122.273 32.086.700 –35.573 –0,1

EnsinoMédio 8.369.369 8.366.100 –3.269 0,0

EducaçãoProfissional 693.610 795.459 101.849 14,7

Educação Especial 348.470 319.924 –28.546 –8,2

EJA 4.985.338 4.945.424 –39.914 –0,8

• EnsinoFundamental 3.367.032 3.295.240 –71.792 –2,1

• EnsinoMédio 1.618.306 1.650.184 31.878 2,0

Fonte: Adaptado de: MEC/Inep/Deed.

No aspecto econômico, há necessidade de expandir a oferta desse tipo de curso, cujo principal objetivo é formar o aluno para atuar no mercado de trabalho, já que falta trabalhador ou pessoa qualificada para assumir imedia-tamente as vagas disponíveis. Por conta disso, muitas empresas têm que arcar com o treinamento de seus funcionários, treinamento esse que não dá ao funcionário um diploma, ou seja, não é formalmente reconhecido.

Para atender à demanda do setor produtivo e satisfazer a procura dos estudantes, seria necessário mais que triplicar as vagas técnicas existentes hoje.

Outro fator que determina a busca pelo ensino técnico é ser este uma boa opção de formação secundária para um grupo cada vez maior de estudantes. Parte dos concluintes do Ensino Médio (59% pelo Censo Inep, 2004), por diversos fatores, não buscam o curso superior. Associa-se a isso a escolarização líquida do Ensino Fundamental, que está próxima de 95%, e a escolarização bruta em 116% (Inep, 2007), mostrando uma pressão de entrada no Ensino Médio, pelo fluxo quase regular dos que o concluem.

A escolarização líquida do Ensino Médio em 2009 foi de 53%, enquanto a bruta foi de 84% (Inep, 2009), o que gera um excedente de alunos para esta etapa.

Escolarização líquida é a relação entre a popu-lação na faixa de idade própria para a escola e o número de matriculados da faixa. Escolarização bruta é a relação entre a população na faixa adequada para o nível escolar e o total de matri-culados, independente da idade.

6

Banc

o de

Dad

os

Atualmente, o número de matriculados no Ensino Médio está em torno de 9 milhões de estudantes. Se considerarmos o esquema a seguir, concluímos que em breve devemos dobrar a oferta de Nível Médio, pois há 9,8 milhões de alunos com fluxo regular do Fundamental, 8 milhões no excedente e 3,2 milhões que possuem o Ensino Médio, mas não têm interesse em cursar o Ensino Superior. Além disso, há os que possuem curso superior, mas buscam um curso técnico como complemento da formação.

Interessados com Ensino Fundamental

Estimativa 8 milhões.

Com Ensino Médio 3,2 milhões.

Ensino Fundamental 116% bruta

94,6% líquida (2007)

TéCnICo

Subsequente

Com Curso Superior

PRoE

JA

Integrado9,8 milhões

A experiência internacional tem mostrado que 30% das matrículas da educação secundária correspondem a cursos técnicos; este é o patamar ideali-zado pelo Ministério da Educação. Se hoje há 795 mil estudantes matriculados, para atingir essa porcentagem devemos matricular pelo menos três milhões de estudantes em cursos técnicos dentro de cinco anos.

Para cada situação pode ser adotada uma modalidade ou forma de Ensino Médio profissionalizante, de forma a atender a demanda crescente. Para os advindos do fluxo regular do Ensino Fundamental, por exemplo, é recomen-dado o curso técnico integrado ao Ensino Médio. Para aqueles que não tiveram a oportunidade de cursar o Ensino Médio, a oferta do PROEJA estimularia sua volta ao ensino secundário, pois o programa está associado à formação profis-sional. Além disso, o PROEJA considera os conhecimentos adquiridos na vida e no trabalho, diminuindo a carga de formação geral e privilegiando a formação específica. Já para aqueles que possuem o Ensino Médio ou Superior a modali-dade recomendada é a subsequente: somente a formação técnica específica.

Para todos eles, com ligeiras adaptações metodológicas e de abordagem do professor, é extremamente útil o uso do livro didático técnico, para maior eficácia da hora/aula do curso, não importando a modalidade do curso e como será ofertado.

Além disso, o conteúdo deste livro didático técnico e a forma como foi concebido reforça a formação geral, pois está contextualizado com a prática social do estudante e relaciona permanentemente os conhecimentos da ciência, implicando na melhoria da qualidade da formação geral e das demais discipli-nas do Ensino Médio.

7

Banco de Dados

Em resumo, há claramente uma nova perspectiva para a formação técnica com base em sua crescente valorização social, na demanda da economia, no apri-moramento de sua regulação e como opção para enfrentar a crise de qualidade e quantidade do Ensino Médio.

3. O Que É Educação Profissionalizante?O ensino profissional prepara os alunos para carreiras que estão baseadas

em atividades mais práticas. O ensino é menos acadêmico, contudo diretamente relacionado com a inovação tecnológica e os novos modos de organização da produção, por isso a escolarização é imprescindível nesse processo.

4. Elaboração dos Livros Didáticos Técnicos

Devido ao fato do ensino técnico e profissionalizante ter sido renegado a segundo plano por muitos anos, a bibliografia para diversas áreas é praticamente inexistente. Muitos docentes se veem obrigados a utilizar e adaptar livros que foram escritos para a graduação. Estes compêndios, às vezes traduções de livros estrangeiros, são usados para vários cursos superiores. Por serem inacessíveis à maioria dos alunos por conta de seu custo, é comum que professores preparem apostilas a partir de alguns de seus capítulos.

Tal problema é agravado quando falamos do Ensino Técnico integrado ao Médio, cujos alunos correspondem à faixa etária entre 14 e 19 anos, em média. Para esta faixa etária é preciso de linguagem e abordagem diferenciadas, para que aprender deixe de ser um simples ato de memorização e ensinar signifique mais do que repassar conteúdos prontos.

Outro público importante corresponde àqueles alunos que estão afastados das salas de aula há muitos anos e veem no ensino técnico uma oportunidade de retomar os estudos e ingressar no mercado profissional.

5. O Livro Didático Técnico e o Processo de Avaliação

O termo avaliar tem sido constantemente associado a expressões como: rea-lizar prova, fazer exame, atribuir notas, repetir ou passar de ano. Nela a educação é concebida como mera transmissão e memorização de informações prontas e o aluno é visto como um ser passivo e receptivo.

Avaliação educacional é necessária para fins de documentação, geralmente para embasar objetivamente a decisão do professor ou da escola, para fins de progressão do aluno.

O termo avaliação deriva da palavra valer, que vem do latim vãlêre, e refe-re-se a ter valor, ser válido. Consequentemente, um processo de avaliação tem por objetivo averiguar o "valor" de determinado indivíduo.

Mas precisamos ir além.

8

Banc

o de

Dad

os

A avaliação deve ser aplicada como instrumento de compreensão do nível de apren-dizagem dos alunos em relação aos conceitos estudados (conhecimento), em relação ao desenvolvimento de criatividade, iniciativa, dedicação e princípios éticos (atitude) e ao processo de ação prática com eficiência e eficácia (habilidades). Este livro didático ajuda, sobretudo para o processo do conhecimento e também como guia para o desenvolvimento de atitudes. As habilidades, em geral, estão associadas a práticas laboratoriais, atividades complementares e estágios.

A avaliação é um ato que necessita ser contínuo, pois o processo de construção de conhecimentos pode oferecer muitos subsídios ao educador para perceber os avanços e dificuldades dos educandos e, assim, rever a sua prática e redirecionar as suas ações, se necessário. Em cada etapa registros são feitos. São os registros feitos ao longo do processo educativo, tendo em vista a compreensão e a descrição dos desempenhos das apren-dizagens dos estudantes, com possíveis demandas de intervenções, que caracterizam o processo avaliativo, formalizando, para efeito legal, os progressos obtidos.

Neste processo de aprendizagem deve-se manter a interação entre professor e aluno, promovendo o conhecimento participativo, coletivo e construtivo. A avaliação deve ser um processo natural que acontece para que o professor tenha uma noção dos conteúdos assimilados pelos alunos, bem como saber se as metodologias de ensino adotadas por ele estão surtindo efeito na aprendizagem dos alunos.

Avaliação deve ser um processo que ocorre dia após dia, visando à correção de erros e encaminhando o aluno para aquisição dos objetivos previstos. A esta correção de rumos, nós chamamos de avaliação formativa, pois serve para retomar o processo de ensino/aprendizagem, mas com novos enfoques, métodos e materiais. Ao usar diversos tipos de avaliações combinadas para fim de retroalimentar o ensinar/aprender, de forma dinâmica, concluímos que se trata de um “processo de avaliação”.

O resultado da avaliação deve permitir que o professor e o aluno dialoguem, bus-cando encontrar e corrigir possíveis erros, redirecionando o aluno e mantendo a motivação para o progresso do educando, sugerindo a ele novas formas de estudo para melhor com-preensão dos assuntos abordados.

Se ao fizer avaliações contínuas, percebermos que um aluno tem dificuldade em assimilar conhecimentos, atitudes e habilidades, então devemos mudar o rumo das coi-sas. Quem sabe fazer um reforço da aula, com uma nova abordagem ou com outro colega professor, em um horário alternativo, podendo ser em grupo ou só, assim por diante. Pode ser ainda que a aprendizagem daquele tema seja facilitada ao aluno fazendo práticas discursivas, escrever textos, uso de ensaios no laboratório, chegando a conclusão que este aluno necessita de um processo de ensino/aprendizagem que envolva ouvir, escrever, falar e até mesmo praticar o tema.

Se isso acontecer, a avaliação efetivamente é formativa.

Neste caso, a avaliação está integrada ao processo de ensino/aprendizagem, e esta, por sua vez, deve envolver o aluno, ter um significado com o seu contexto, para que real-mente aconteça. Como a aprendizagem se faz em processo, ela precisa ser acompanhada de retornos avaliativos visando a fornecer os dados para eventuais correções.

Para o uso adequado deste livro recomendamos utilizar diversos tipos de avaliações, cada qual com pesos e frequências de acordo com perfil de docência de cada professor. Podem ser usadas as tradicionais provas e testes, mas, procurar fugir de sua soberania, mesclando com outras criativas formas.

9

Banco de Dados

5.1 Avaliação e ProgressãoPara efeito de progressão do aluno, o docente deve sempre considerar os avanços

alcançados ao longo do processo e perguntar-se: Este aluno progrediu em relação ao seu patamar anterior? Este aluno progrediu em relação às primeiras avaliações? Respondidas estas questões, volta a perguntar-se: Este aluno apresentou progresso suficiente para acom-panhar a próxima etapa? Com isso o professor e a escola podem embasar o deferimento da progressão do estudante.

Com isso, superamos a antiga avaliação conformadora em que eram exigidos padrões iguais para todos os “formandos”.

Nossa proposta significa, conceitualmente, que ao estudante é dado o direito, pela avaliação, de verificar se deu um passo a mais em relação as suas competências. Os diversos estudantes terão desenvolvimentos diferenciados, medidos por um processo avaliativo que incorpora esta possibilidade. Aqueles que acrescentaram progresso em seus conhecimen-tos, atitudes e habilidades estarão aptos a progredir.

A base para a progressão, neste caso, é o próprio aluno.Todos têm o direito de dar um passo a mais. Pois um bom processo de avaliação oportu-

niza justiça, transparência e qualidade.

5.2 Tipos de AvaliaçãoExistem inúmeras técnicas avaliativas, não existe uma mais adequada, o importante é

que o docente conheça várias técnicas para poder ter um conjunto de ferramentas a seu dispor e escolher a mais adequada dependendo da turma, faixa etária, perfil entre outros fatores.

Avaliação se torna ainda mais relevante quando os alunos se envolvem na sua pró-pria avaliação.

A avaliação pode incluir:1. Observação2. Ensaios3. Entrevistas4. Desempenho nas tarefas5. Exposições e demonstrações6. Seminários7. Portfólio: Conjunto organizado de trabalhos produzidos por um aluno ao longo de

um período de tempo.8. Elaboração de jornais e revistas (físicos e digitais)9. Elaboração de projetos10. Simulações11. O pré-teste12. A avaliação objetiva13. A avaliação subjetiva14. Autoavaliação15. Autoavaliação de dedicação e desempenho16. Avaliações interativas

10

Banc

o de

Dad

os

17. Prática de exames

18. Participação em sala de aula

19. Participação em atividades

20. Avaliação em conselho pedagógico – que inclui reunião para avaliação discente pelo grupo de professores.

No livro didático as “atividades”, as “dicas” e outras informações destacadas pode-rão resultar em avaliação de atitude, quando cobrado pelo professor em relação ao “desempenho nas tarefas”. Poderão resultar em avaliações semanais de autoavaliação de desempenho se cobrado oralmente pelo professor para o aluno perante a turma.

Enfim, o livro didático, possibilita ao professor extenuar sua criatividade em prol de um processo avaliativo retroalimentador ao processo ensino/aprendizagem para o desen-volvimento máximo das competências do aluno.

6. Objetivos da ObraAlém de atender às peculiaridades citadas anteriormente, este livro está de acordo

com o Catálogo Nacional de Cursos Técnicos. Busca o desenvolvimento das habilidades por meio da construção de atividades práticas, fugindo da abordagem tradicional de des-contextualizado acúmulo de informações. Está voltado para um ensino contextualizado, mais dinâmico e com o suporte da interdisciplinaridade. Visa também à ressignificação do espaço escolar, tornando-o vivo, repleto de interações práticas, aberto ao real e às suas múltiplas dimensões.

Ele está organizado em capítulos, graduando as dificuldades, numa linha da lógica de aprendizagem passo a passo. No final dos capítulos, há exercícios e atividades comple-mentares, úteis e necessárias para o aluno descobrir, fixar, e aprofundar os conhecimentos e as práticas desenvolvidos no capítulo.

A obra apresenta diagramação colorida e diversas ilustrações, de forma a ser agra-dável e instigante ao aluno. Afinal, livro técnico não precisa ser impresso num sisudo preto-e-branco para ser bom. Ser difícil de manusear e pouco atraente é o mesmo que ter um professor dando aula de cara feia permanentemente. Isso é antididático.

O livro servirá também para a vida profissional pós-escolar, pois o técnico sempre necessitará consultar detalhes, tabelas e outras informações para aplicar em situação real. Nesse sentido, o livro didático técnico passa a ter função de manual operativo ao egresso.

Neste manual do professor apresentamos:

• Respostas e alguns comentários sobre as atividades propostas;

• Considerações sobre a metodologia e o projeto didático;

• Sugestões para a gestão da sala de aula;

• Uso do livro;

• Atividades em grupo;

• Laboratório;

• Projetos.

11

Banco de Dados

A seguir, são feitas considerações sobre cada capítulo, com sugestões de atividades suplementares e orientações didáticas. Com uma linguagem clara, o manual contribui para a ampliação e exploração das atividades propostas no livro do aluno. Os comentários sobre as atividades e seus objetivos trazem subsídios à atuação do professor. Além disso, apresentam-se diversos instrumentos para uma avaliação coerente com as concepções da obra.

7. Referências Bibliográficas GeraisFREIRE, P. Pedagogia da autonomia: saberes necessários à prática educativa. São Paulo: Paz e Terra, 1997.FRIGOTTO, G. (Org.). Educação e trabalho: dilemas na educação do trabalhador. 5. ed. São Paulo: Cortez, 2005.BRASIL. LDB 9394/96. Disponível em: <http://www.mec.gov.br>. Acesso em: 23 maio 2009.LUCKESI, C. C. Avaliação da aprendizagem na escola: reelaborando conceitos e recriando a prá-tica. Salvador: Malabares Comunicação e Eventos, 2003.PERRENOUD, P. Avaliação: da excelência à regulação das aprendizagens – entre duas lógicas. Porto Alegre: Artes Médicas Sul, 1999.ÁLVAREZ MÉNDEZ, J. M. Avaliar para conhecer: examinar para excluir. Porto Alegre: Artmed, 2002.SHEPARD, L. A. The role of assessment in a learning culture. Paper presented at the Annual Meeting of the American Educational Research Association. Available at: <http://www.aera.net/mee-ting/am2000/wrap/praddr01.htm>.

8. Orientações ao professorA área de banco de dados é de grande importância, uma vez que hoje a informação é

um bem precioso e deve ser armazenada de forma coerente e adequada. Apesar de, atualmente, qualquer Sistema de Informação, por menor e mais simples

que seja, precisar utilizar uma base de dados, observa-se certo descaso dos “desenvolvedo-res” com a modelagem de uma base de dados antes da sua implementação. No entanto, esse descaso pode fazer com que todo o desempenho do sistema seja comprometido.

A importância de uma boa modelagem se deve ao fato de que as aplicações que aces-sam a base de dados devem estar em consonância com o modelo desenvolvido. É muito desanimador e trabalhoso, depois da base de dados implementada e da aplicação do usuário desenvolvida, que se perceba a necessidade de alterar o modelo de dados. A verdade é que isso gera um retrabalho, uma vez que não só a implementação da base terá que ser refeita, mas também os diagramas deverão ser atualizados e, na maioria dos casos, a aplicação tam-bém ser atualizada.

A fase de modelagem é, portanto, a principal etapa no desenvolvimento de uma base dados. Por isso, é muito importante que se dedique tempo e esforço no desenvolvimento de uma boa modelagem da base de dados.

Uma vez que o modelo de dados foi desenvolvido é necessário selecionar um SGBD – Sistemas Gerenciadores de Banco de Dados para que esse modelo possa ser implemen-tado. É a linguagem SQL que permite criar uma base de dados que represente o modelo desenvolvido e também permite manipular e recuperar dados dessa base. No entanto, não se pode esquecer de que se o modelo não for coerente, a linguagem não ajudará muito.

12

Banc

o de

Dad

os

O livro de Banco de Dados permite aprender a desenvolver uma boa modelagem e também a utilizar a linguagem SQL para criar o modelo desenvolvido, para manipular e para recuperar os dados. A abordagem utilizada no livro é bastante prática. Ele começa apresentando os princi-pais conceitos e suas aplicações para desenvolver uma boa modelagem. Num segundo momento, o livro apresenta a linguagem SQL e como ela pode ser utilizada para implementar uma base de dados. Assim, ao final do livro, teremos um projeto de banco de dados completo e poderemos implementar esse projeto completamente por meio da linguagem SQL.

8.1 Objetivos do Material Didático • Apresentar os principais conceitos da área de banco de dados;

• Modelar, por meio do Diagrama de Entidade e Relacionamento, uma base de dados;

• Criar o modelo relacional normalizado de uma base de dados;

• Implementar um base de dados em um SGBD (no caso do livro o SGBD utilizado foi o MySQL);

• Utilizar a linguagem SQL para inserir, alterar e excluir dados da base de dados;

• Utilizar a linguagem SQL para recuperar informações (realizar con-sultas) inseridas na base de dados;

• Apresentar junções e comandos mais avançados da linguagem SQL;

• Partir de uma situação real e conseguir, a partir dela, criar o modelo abstrato da base de dados, criar o modelo relacional normalizado, fazer o dicionário de dados detalhado para esta base e, então, implementá-la em um SGBD.

8.2 Princípios Pedagógicos O objetivo do livro é trabalhar com uma abordagem prática. Em

cada capítulo serão apresentados novos conceitos desta disciplina e a dificuldade dele vai aumentando gradualmente, para melhor entendi-mento dos alunos. Assim, esses alunos começam aprendendo a modelar uma base de dados normalizada e, em seguida, a implementá-la em um SGBD por meio da linguagem SQL.

8.3 Articulação do ConteúdoO docente poderá articular com professores de outras disciplinas

técnicas como Modelagem de Sistemas e Programação o desenvolvi-mento de um projeto que contemple a modelagem e a implementação de um Sistema de Informação que utilize uma base de dados e assim a realizar um projeto interdisciplinar entre as disciplinas de um mesmo período. O sistema a ser desenvolvido pode ser em qualquer outra área como Geografia, História, Português, etc.

13

Banco de Dados

8.4 Atividades Complementares • Estudos de caso com descrição de situações reais;

• Práticas de laboratório que permitam ao aluno utilizar um SGBD para que ele possa visualizar os resultados da utilização da linguagem SQL para inserção, alteração, exclusão e recuperação de dados;

• Desenvolvimento de um trabalho interdisciplinar entre as disciplinas de Banco de Dados, Modelagem de Sistemas e Programação.

8.5 Sugestão de LeituraCÂNDIDO C. H. brModelo 2.0. Disponível em:< http://sis4.com/brModelo/>. Acesso em: 10 jan. 2010.

CODD, E. F. Relational model of data for large shared Data Banks. In: Communications of the ACM, Vol. 13, 1970.

DATE, C. J. Introdução a sistemas de banco de dados. Rio de Janeiro: Elsevier, 2003.

ELSMARI, R.; NAVATHE, S. B. Sistemas de bancos de dados. São Paulo: Pearson, 2005.

HEUSER, C. A. Projeto de banco de bados. 6. ed. São Paulo: Bookman, 2009.

KRIEGEL, A.; TRUKHNOV, B. M. SQL Bible. Indianapolis: Wiley, 2003.

SILBERCHATZ A. et. al. Sistema de banco de bados. 3. ed. São Paulo: Makron Books, 1999.

8.6 Sugestão de PlanejamentoEste livro foi elaborado para dar suporte e ser utilizado para 80 horas em sala de

aula. A sugestão de planejamento que anunciamos segue neste diapasão. Mas é altamente recomendado que o professor da disciplina incremente com textos e atividades com-plementares em conformidade com o seu jeito próprio de ministrar aulas, sobretudo potencializando sua especialização, aplicando sua criatividade em prol do incremento do processo educativo.

Semestre 1

Primeiro Bimestre

Capítulo 1 – Uma Breve Introdução a Banco de Dados

Capítulo 2 – Introdução ao Modelo de Entidade e Relacionamento

Capítulo 3 – ER: Relacionamento, Especialização e Agregação

Objetivos• Apresentar os principais conceitos relativos à área de Banco de Dados;

• Apresentar a evolução dos bancos de dados desde a década de 70, como eram armazena-dos dados nessa época e quais os principais problemas encontrados;

14

Banc

o de

Dad

os

• Mostrar como um SGBD ameniza e, em alguns casos, soluciona os problemas que existiam anteriormente;

• Explicar a importância da modelagem no desenvolvimento de uma base de dados;

• Apresentar os principais conceitos de um modelo de entidade e relacionamento;

Atividades• Pesquisar sobre SGBD mais utilizados no mercado de trabalho e suas

principais características;

• Desenvolver, com os alunos, exercícios que permitam a eles que criem diagramas de base de dados para algumas situações hipotéti-cas e/ou reais.

Segundo Bimestre

Capítulo 4 – Introdução ao Modelo Relacional

Capítulo 5 – Modelo Relacional: Tópicos Avançados

Capítulo 6 – Um Exemplo Prático

Objetivos• Apresentar o que é uma chave estrangeira e o conceito de integri-

dade referencial;

• Mostrar, por meio de exemplos, a aplicação das regras de conversão entre os modelos (DER para o modelo relacional) e explicar a utiliza-ção dessas regras;

• Permitir ao aluno que possa desenvolver o modelo completo de uma base de dados.

Atividades• Desenvolver, com os alunos, exercícios que permitam a eles que

façam a conversão do diagrama de entidade e relacionamento para o modelo relacional;

• Praticar, por meio de exercícios, a aplicação das regras de normalização;

• Realizar um projeto em que o aluno possa desenvolver toda a parte de modelagem da base de dados (desde o diagrama de enti-dade e relacionamento até o dicionário de dados), como foi feito no capítulo 6.

15

Banco de Dados

Semestre 2

Primeiro Bimestre

Capítulo 7 – Implementação do Modelo Lógico: Linguagem SqL

Capítulo 8 – Linguagem SqL – DML

Objetivos• Apresentar uma breve introdução sobre a linguagem SQL;

• Apresentar os comandos DDL para criação de base de dados;

• Discutir as principais restrições de integridade que devem ser consideradas na criação de uma base de dados;

• Apresentar os principais comandos SQL DDL: CREATE, ALTER e DROP;

• Explicar o que é um índice, para que ele serve e quando deve ser criado;

• Apresentar os principais comandos DML: INSERT, UPDATE, DELETE e SELECT, FROM e WHERE;

• Explicar a diferença entre o INNER JOIN e o Produto Cartesiano;

Atividades• Desenvolver em laboratório, com os alunos, exercícios que permitam a

eles que criem bases de dados (com suas respectivas tabelas, chaves pri-márias, chaves estrangeiras e outras restrições que forem necessárias) baseadas nos modelos desenvolvidos em aulas anteriores;

• Para as bases de dados criadas, os alunos devem inserir dados usando o comando INSERT;

• Sugerir algumas consultas para que os alunos escrevam as mesmas uti-lizando a linguagem SQL.

Segundo Bimestre

Capítulo 9 – Outros Comandos SqL – DML

Capítulo 10 – SqL – DML: Subconsulta e Tipos de Junção

Objetivos• Apresentar alguns outros comandos da linguagem SQL para criação de

consultas;

• Explicar a diferença de desempenho de uma consulta, dependendo do comando utilizado;

• Apresentar os principais tipos de junção, sua aplicabilidade e quando devem ser utilizados.

16

Banc

o de

Dad

os

Atividades• Exercícios que permitam aos alunos que realizem consultas na base de

dados, utilizando comandos mais elaborados para isso;

• Realizar atividades em que os alunos tenham que utilizar diferentes tipos de junção para que entendam em que situações essas junções devem ser aplicadas.

9. Orientações Didáticas e Respostas das AtividadesCapítulo 1Orientações

O objetivo desse capítulo é apresentar os principais conceitos relativos à área de Banco de Dados. O professor deve explicar claramente para os alunos o que são dados, o que são informações, o que compreende uma base de dados, em que consiste e o que define um sistema de banco de dados e, finalmente, o que são os atuais Sistemas Gerenciadores de Banco de Dados (SGBD).

Além disso, o professor deve apresentar como aconteceu a evolução dos bancos de dados desde a década de 70, como os dados eram armazenados nessa época e quais os principais problemas encontrados. Esses problemas levaram ao desenvolvimento dos SGBD atuais, que surgem com uma proposta apara ame-nizar e, em alguns casos, solucionar os problemas que existiam anteriormente.

Também devem ser apresentados os conceitos de Esquema, Instâncias, Independência de Dados e os principais usuários de um banco de dados e seus papéis.

Respostas – página 171) • Situação 1: Um sistema para controle de estoque em um

supermercado.• Situação 2: Um sistema para controle de alunos, disciplinas, turmas

e professores em uma escola. • Situação 3: Um sistema para empréstimos de livros em uma

biblioteca.

2) • Situação 1: Dados de produtos (nome, categoria, preço, etc.), forne-cedores (nome, CNPJ, telefone, etc.), estoque mínimo permitido, data de entrega do produto, validade, etc.

• Situação 2: Dados de alunos (nome, endereço, telefone, data de nascimento, etc.); dados de disciplinas (nome, código, etc.); dados de professores (nome, escolaridade, telefone, etc.); dados de turmas (nome, código, etc.).

• Situação 3: Dados dos livros (nome, autor, ano, ISBN, etc.); dados do usuário que irá emprestar o livro (nome, endereço, número da carteirinha, etc.); data do empréstimo, data da devolução, valor da multa por atraso, etc.

17

Banco de Dados

3) As informações que serão armazenadas na base de dados sem-pre devem ser úteis para a aplicação do cliente. Por exemplo, se a aplicação do cliente for um sistema para empréstimo de livro e for importante saber quem emprestou qual livro e em que data, as infor-mações como nome do usuário, nome do livro e data do empréstimo devem ser armazenados. Outro fator que deve ser considerado são os relatórios que o cliente solicitou ou necessita. Para gerar os relatórios são necessários dados armazenados na base de dados, portanto, isso deve ser considerado no desenvolvimento da base de dados.

Um dado não é útil quando ele não é utilizado pela aplicação. Por exemplo, suponha que você queira armazenar o e-mail do cliente, mas depois de algumas entrevistas com o cliente você descubra que esse dado não será utilizado para nada. Neste caso, o dado não é útil para a aplicação e nem para o cliente e, portanto, deve ser descartado.

4) Um sistema de banco de dados computacional é caracterizado por armazenar dados, relacionar dados e recuperar dados.

5) Uma base de dados é apenas o repositório em que os dados estão inseridos. Cada base de dados pertence a um domínio específico. Por exemplo, um colégio pode ter uma base de dados de alunos para fins acadêmicos e também uma base de dados para o controle do RH.

Um sistema de banco de dados compreende a ferramenta utilizada para criar a base de dados e seus relacionamentos. Além disso, um sistema de banco de dados deve possuir uma forma de recuperar os dados. Isso é implementado, na maioria dos casos, por meio da lin-guagem SQL.

6) Um SGBD é um Sistema Gerenciador de Banco de Dados. Essa ferramenta possui, além de um banco de dados (repositório), funcionalidades que permitem controlar segurança, controlar con-corrência, controlar transações, realizar backups, definir regras de integridade, etc.

7) Não. O Access não é um SGBD porque não possui as características de um SGBD. Mas ele é considerado um sistema de banco de dados porque permite armazenar dados, relacionar dados e recuperar esses dados.

8) A importância de uma boa modelagem se deve ao fato de que as aplicações que estarão acessando a base de dados devem estar em consonância com o modelo desenvolvido. É muito desanimador e trabalhoso, depois da base de dados implementada e da aplicação do usuário desenvolvida, que se perceba a necessidade de alterar o modelo de dados. A verdade é que isso gera um retrabalho, uma vez que não só a implementação da base terá que ser refeita, mas também os diagramas deverão ser atualizados e a aplicação também deverá ser atualizada, na maioria dos casos.

18

Banc

o de

Dad

os

9) Um modelo de dados compreende a descrição dos dados que devem ser armazenados pelo sistema e como esses dados devem se relacionar. Para que seja possível fazer essa descrição é utilizada uma linguagem de modelagem, que pode ser textual ou gráfica. Um modelo de dados também deve explicitar os tipos dos dados armazenados e as restrições que esses dados possuem. Os modelos de dados podem ser basicamente de dois tipos:

• Modelo de dados conceitual, que fornece uma visão mais próxima do modo como os usuários visualizam os dados realmente.

• Modelo de dados lógico, que fornece uma visão mais detalhada do modo como os dados estão realmente armazenados no computador.

10) Para que o projetista possa desenvolver a base de dados, ele deve ter uma clara com-preensão do que o usuário espera do sistema, que tipos de relatórios o usuário espera que o sistema disponibilize, bem como saber quais são os objetivos do sistema. Para obter essas informações, deve-se realizar entrevistas com o usuário para entender os objetivos do sistema e as expectativas que o usuário tem em relação ao mesmo.

Se não houver a participação do usuário, corre-se um grande risco de no final do projeto os desenvolvedores descobrirem que a base de dados não atende às necessi-dades do usuário e, portanto, não serve ao propósito inicial.

11) Normalmente, o usuário final é a pessoa que irá utilizar a aplicação. Essa aplicação irá rodar sob uma base de dados. Para o usuário final o importante é que a aplicação consiga se comunicar com a base de dados e permita inserir e recuperar os dados dessa base. Para ele não interessa como isso foi implementado ou como isso está sendo realizado. Sendo assim, não há necessidade de que o usuário conheça sobre a área de banco de dados. Para ele é importante que o que foi solicitado funcione satisfatoriamente.

Capítulo 2Orientações

Nesse capítulo o professor deve enfatizar a importância da modelagem de uma base de dados e apresentar os principais conceitos para o desenvolvimento do primeiro modelo da base de dados – o modelo de entidade e relacionamento.

É importante ressaltar que esse modelo é bastante abstrato, mas que tem por obje-tivo compreender o que o usuário precisa armazenar na base de dados. É importante, também, ressaltar aqui que os dados precisam se relacionar. Caso contrário a base de dados seria simplesmente um repositório sem nenhum sentido.

O professor deve deixar claro, por meio de exemplos, o que é uma entidade, o que são atributos, a importância da definição de uma chave primária em uma entidade e o que é uma entidade fraca.

O professor deve fazer exercícios com os alunos para que eles consigam entender os conceitos e aplicá-los em situações hipotéticas ou mesmo reais.

19

Banco de Dados

Respostas – página 241) O DER é utilizado para representar graficamente o conjunto de objetos

do Modelo de Entidade e Relacionamento tais como entidades, atribu-tos, atributos-chaves, relacionamentos, restrições estruturais, etc.

Essa representação gráfica tem por objetivo descrever quais dados devem ser armazenados pela aplicação e quais desses dados se relacionam.

2) O DER é o primeiro modelo que deve ser construído durante o processo de modelagem de uma base de dados. Portanto, deve ser construído no início do projeto e tem por objetivo prover uma visão abstrata dos dados que estarão armazenados na base de dados. Esta visão inicial representa a visão que o usuário tem da base de dados. O responsável pela construção do DER é o projetista da base de dados ou o analista de sistema.

3) Não, o DER não deve mudar depois que a base já estiver implemen-tada em um SGBD e/ou as aplicações já estiverem sendo desenvolvidas. Frequentes alterações no DER podem levar o projeto ao fracasso, uma vez que alterando o DER, a implementação da base de dados e a apli-cação também deverá ser alterada. Esse retrabalho elevaria o custo do projeto e também iria requerer mais tempo para finalizar o projeto.

Isso ocorre porque dificilmente conseguimos obter independência de dados. Essa independência é difícil de alcançar, mas uma vez que se altera a estrutura (ou esquema) de uma base de dados existe a necessidade de se alterar também as aplicações que acessam aquela base. Assim, a inde-pendência de dados lógica (alteração no esquema lógico de uma base de dados sem necessidade de alterar outros diagramas ou a aplicação) é muito difícil de ser alcançada e, portanto, deve ser evitada.

4) Uma entidade representa um conjunto de objetos de mesmo tipo do mundo real e sobre os quais se pretende armazenar dados. Além disso, ela também deve possuir um conjunto de propriedades que a caracterize e a descreva, bem como aos seus objetos.

Exemplos de entidades: Em uma empresa que fabrica e vende móveis para escritórios podemos definir como entidades: mesas, cadeiras, mar-ceneiros, clientes, etc.

5) • Mesas (altura: numerico; largura: numerico; comprimento: nume-rico; cor: caracter(20); material: caracter(20)

• Cadeiras (largura_do_assento: numerico; rodas: booleano; cor: caracter(20); descanso_de_braco:booleano)

• Marceneiros (nome:caracter(50); data_nascimento:data; tempo_de_profissao:inteiro; telefone:inteiro)

• Clientes (nome:caracter(50), cidade:caracter(50); telefone:inteiro; CPF:caracter)

6) • Atributo simples: é o atributo indivisível, que não pode ou não deve ser decomposto. Exemplos: nome da rua, código do produto e nome da cidade.

20

Banc

o de

Dad

os

• Atributo composto: é o atributo que pode ser decomposto em outros atributos simples. Exemplos: “Nome” poderia ser decom-posto em “primeiro nome” e “sobrenome”; Telefone poderia ser decomposto em “DDD” e “número”; “Prazo de Validade” poderia ser decomposto em “dia”, “mês” e “ano”.

• Atributo monovalorado: é o atributo que permite apenas o arma-zenamento de um valor por vez. Exemplos: nome da pessoa, data de nascimento e RG.

• Atributo multivalorado: é o atributo que permite armazenar mais de um valor ao mesmo tempo no mesmo campo. Exemplos: telefone, e-mail e cidade disponível.

• Atributo nulo: é o atributo que permite que seja inserido um valor nulo para ele. Exemplo: homepage, e-mail e telefone residencial.

• Atributo derivado: é o atributo cujo valor deriva de outro(s) atributo(s). Exemplos: valor da multa (deriva do valor unitário da multa multiplicado pelos dias de atraso), idade (deriva da data de nascimento) e valor total da compra (deriva da soma dos preços de todos os itens comprados).

7) • Situação 1: Suponha que em uma locadora de vídeo, um cliente possa ter até 3 dependentes. Sobre os dependentes, deseja-se arma-zenar o nome, endereço e telefone. Individualmente, nenhum desses atributos forma uma chave primária simples e a combinação deles também não forma uma PK composta. Como não é possível definir uma PK para essa entidade, deve-se defini-la como uma Entidade Fraca.

• Situação 2: Suponha que em uma instituição de caridade, cada criança que more na instituição possa ter até 5 padrinhos. Para cada um desses padrinhos deve-se armazenar: nome, telefone e ende-reço. Da mesma forma que na situação 1, nenhum desses atributos individualmente forma uma PK simples e a combinação deles também não forma uma PK composta. Sendo assim, a entidade Padrinho deve ser definida como Entidade Fraca.

8) Uma chave primária é um atributo da entidade que serve para identi-ficar apenas um objeto dessa entidade. Uma chave primária não permite valores repetidos e nem valor nulo.

• Exemplo 1: CRM do médico, considerando que o CRM de um médico não se repete.

• Exemplo 2: número da conta corrente, considerando que em um banco (instituição financeira) não existe mais de uma conta com o mesmo número.

• Exemplo 3: código do aeroporto, considerando que o código do aeroporto não se repete em nenhum outro aeroporto do mundo.

21

Banco de Dados

9) Não. Isso não pode acontecer porque uma chave primária deve identificar um único objeto da entidade. Se ela for nula não poderá identificar o objeto.

10)

Marca(1,1) (1,1)(1,n) (1,n)

Modelo Carropossui pertence

cod_marca chassicod_modelonome_marca numero_placanome_modelo

ano_modelocor

11) Não. A afirmativa está incorreta. A entidade "Endereco" possui apenas uma única chave primária composta de três atributos.


Nesse capítulo o professor deve explicar a importância de se relacionar os dados em uma base de dados. Além disso, deve explicar o conceito de cardinalidade e mostrar como é feita a leitura para descobrir as cardinalidades no modelo. Deve enfatizar que a cardinalidade depende, muitas vezes, da aplicação desenvolvida e também de regras de negócio da empresa.

O professor precisa também apresentar conceitos mais avançados do modelo de entidade e relacionamento que são: agregação e especialização. É importante que se enfatize para os alu-nos em que situações se deve aplicar cada um desses conceitos.

É muito importante que durante as explicações sejam apresentados exemplos e que sejam propostos exercícios para que os alunos possam entender a aplicação dos conceitos em situações hipotéticas ou reais. Nos exercícios, a aplicação desses conceitos poderá ser feita por meio do desenho do diagrama de entidade e relacionamento.

Respostas – página 351) Na situação apresentada abaixo o relacionamento “empresta” possui três atributos

descritivos.

cod_cliente cod_filme

data_emprestimonome_cliente nome_filme

(0,n) (0,n)

data_devolucao_efetiva

data_devolucao_prevista

Cliente Filme

empresta

22

Banc

o de

Dad

os

2) Situação 1: Companhia Aérea. O relacionamento ternário ocorre entre avião, piloto e tripulante, como mostrado a seguir.

Comissarios Pilotomatricula_comissarionome_comissario

cod_aviao

data_voo

hora_voo

matricula_piloto

modelo_aviao

nome_pilotohoras_de_voo

(1,n)

(1,1)

(1,n)

Aviao

Voo

Situação 2: Compra de Imóveis. O relacionamento ternário ocorre entre comprador, corretor e imóvel, como mostrado a seguir.

bairro_imovelnumero_rua_imovel

Comprador CorretorCPF_compradornome_comprador

cod_imovel

data_compra

valor_compra

matricula_corretor

rua_imovel

nome_corretortelefone_corretor

(1,n)

(1,n)

(1,n)

Imovel

compra

3) Poderíamos criar três relacionamentos no lugar do relacionamento ternário do exercício 2 (situação 2). No entanto, esses três relaciona-mentos dificilmente serão equivalentes ao relacionamento ternário, como mostrado a seguir:

cod_imovel

bairro_imovel

numero_rua_imovelrua_imovel

CPF_compradormatricula_corretor

nome_compradortelefone_corretor

nome_corretor

(1,n)

(0,n)

(0,n) (0,n)

(1,n)

(1,n)

Imovel

negociaComprador Corretor

realiza compracompra

23

Banco de Dados

A melhor opção, neste caso, é criar uma entidade para o relacionamento ternário. Assim, o modelo será exatamente o mesmo e irá representar exatamente a mesma situação anterior.

CPF_compradormatricula_corretor

nome_compradortelefone_corretornome_corretor

data_compravalor_compra

cod_compra

(1,1)

(0,n) (0,n)

(1,n)

Compra

Comprador Corretor

realizaadquire

numero_rua_imovelbairro_imovelrua_imovel

possui

(1,1)

(1,1)cod_imovel

Imovel

Observação: O mesmo ocorre para a situação 1 do exercício 2.

4) Situação 1: Suponha que em uma base de dados tenhamos uma enti-dade que armazena livros. No entanto, quando um desses livros deixa de ser publicado é necessário cadastrar uma substituição para ele. Essa subs-tituição se refere a um novo livro que será indicado no lugar daquele que está fora de publicação. Neste caso, cria-se um relacionamento recursivo que cadastra essa substituição, como mostrado a seguir:

editoratitulo

ISBN livro

(0,n) substitui

(0,n) e substituidoLivro substituicao

Situação 2: Imagine que exista uma entidade chamada “departamento”, em que cada departamento está subordinado a outro. Para saber qual depar-tamento está subordinado e quem é o seu departamento superior, devemos utilizar um relacionamento recursivo, como mostrado a seguir:

numero_deptonome_depto

sigla_depto

(0,n) supervisiona

(0,n) e supervisionadoDepartamento superior

24

Banc

o de

Dad

os

5) Não. Como um relacionamento recursivo representa o relacionamento entre objetos de uma mesma entidade, se tentarmos reescrever o modelo acrescentando outra enti-dade, teremos duplicidade de dados.

Na situação 2 do exercício 4 observa-se que um mesmo departamento pode ser super-visor e estar supervisionado a outro departamento (ao mesmo tempo). Sendo assim, utilizamos o relacionamento recursivo para que não seja necessário duplicar os dados de departamento em duas entidades distintas. O mesmo ocorre para a situação 1.

6) Para utilizar uma especialização deve-se analisar antes se as entidades filhas possuem atributos específicos ou relacionamentos específicos ou ainda outra especialização, como mostra o exemplo a seguir:

PessoaCPF_pessoa

telefone_pessoanome_pessoa

Corretor Comprador Proprietario Imovel

data_admissao profissao numero_inscricaoarea_total

CRECI estado_civil valor_imovel

possui(1,n) (1,n)

7) Se a entidade filha não tiver nem atributo específico, nem relacionamento específico, nem outra especialização, então ela deve passar por um processo de generalização. A generalização é o processo inverso da especialização. Ao invés de subdividir a entidade, é criada uma entidade mais genérica e é adicionado um atributo chamado “tipo” que identifica o tipo do objeto da entidade genérica.

Suponha que em uma loja seja necessário armazenar o tipo de pagamento do cliente. No entanto, o cliente só pode pagar em dinheiro ou no cartão de débito. Assim, todo o pagamento é feito à vista e não pode ser parcelado. Neste caso, não há neces-sidade de subdividir a entidade “Pagamento” em entidades filhas como “Pagamento em Dinheiro” e “Pagamento com Cartao”. Será criado apenas o atributo “tipo_paga-mento” na entidade “Pagamento”, como mostrado a seguir:

codigo_pagtovalor_pagtodata_pagto

tipo_pagamento

Pessoa

8) Verificar o exemplo do Livro no capítulo 3, figura 3.13.

9) Verificar o exemplo do Livro no capítulo 3, figura 3.14.

10) A solução mais simples seria utilizar um atributo do tipo booleano que diz se o empre-gado é gerente ou não.

matricula_empregadonome_empregadosalarioflag_gerente

Empregado

25

Banco de Dados

Outra solução é criar uma entidade chamada “Tipo Empregado” que identifica o tipo do empregado (se é gerente, supervisor, etc.).

Tipo Empregado Empregado(1,1) (1,1)

matricula_empregadonome_empregado

salario

cod_tiponome_tipo

e de um

Também pode-se utilizar uma especialização. Neste caso, poderíamos inclusive armaze-nar a data em que o funcionário começou a gerenciar o departamento e a data em que ele deixou de ser gerente.

Empregado

Gerente

matricula_empregadonome_empregado

data_iniciodata_fim

salario

11)

realiza

ISBN_livronome_livro

autor_autor (1,n)editora_livro

ano_publicacao_livre

cod_emprestimo matricula_aluno

(1,1)

(1,1)

(1,1)

(0,n)

(0,n)(0,n)

data_emprestimo nome_aluno

data_devolucao_prevista telefone_alunodata_devolucao_efetiva turma_aluno

Areacod_areanome_area

pertence

Livro possui

Emprestimo/Devolucao Aluno

26

Banc

o de

Dad

os

12)

possui

cod_marca

cor matricula

CPF_conjuge

nome_conjuge

nome_marca

placa nome_corretorchassi data_admissao

(1,1)

(1,n) (1,n)

(1,n)

(1,1) (0,1)

(0,n) (0,n)

(0,n)

Modelo

Comprador Conjuge

Marcadescricao_modelo

CPF_comprador

ano_fabricacao

cod_modelo

nome_compradorestado_civil_comprador

quilometragem

pertence

pertence

venda

Carro Corretor

valor_comissao

valor_venda

data_venda


O professor deve falar sobre SGBD relacionais e apresentar os mais utilizados no mercado. Pode, ainda, falar sobre SGBD relacionais gratuitos e compará-los com os SGBD proprietários. É importante que o professor fale um pouco sobre isso para justificar o estudo de um modelo relacional.

Em seguida, o professor deverá apresentar os principais conceitos do modelo relacional, destacando bastante o conceito de chave estrangeira e sua importância na definição da integri-dade referencial de uma base de dados.

As regras de conversão do diagrama de entidade e relacionamento para o modelo relacio-nal devem ser apresentadas gradualmente e sempre com exemplos a ser resolvidos no quadro junto com os alunos. Essa é a melhor forma de explicar-lhes as regras para que melhor as compreendam.

Respostas – página 481) Uma chave estrangeira é um atributo da tabela que faz referência a uma chave pri-

mária de outra tabela ou da própria tabela. Exemplo:

tbDepartamento(codigo_depto:inteiro,nome_depto:caracter(20), sigla_depto: caracter(5))

tbProjeto(numero_projeto:inteiro, nome_projeto:caracter(20, codigo_depto: inteiro)

codigo_depto referencia tbDepartamento

chave estrangeira

27

Banco de Dados

2) A Integridade Referencial é que garante que não se faça referência a valores que não exis-tam na base de dados

3) A chave estrangeira garante que o valor digitado para este atributo seja um valor cadas-trado em sua primária correspondente. Sendo assim, a chave estrangeira sempre irá se referir a um valor já existente na base de dados.

4) Sim. Em uma tabela o valor armazenado para uma chave estrangeira pode aparecer quan-tas vezes for necessário. O valor nulo também é permitido, mas quando isso acontece não existe o relacionamento entre o registro que possui a chave estrangeira nula e sua correspondente primária.

5) Porque quando o valor da chave estrangeira é nulo não há referência e, portanto, existe um registro que não está relacionado.

6) Ele deve excluir também todos os registros da Tabela tbAluno que fazem referência a “1TI”. Caso contrário, TbAluno fará referência a uma turma que não existe mais.

7)

tbCidade (codigo:inteiro, nome:caracter(30), UF:caracter(2))

tbFuncionario (matricula:inteiro, RG:caracter(9), nome:caracter(50), sexo:caracter(1), telefone:numerico(10), codigo_loja:inteiro)

codigo_loja referencia tbLoja

tbLoja (codigo:inteiro, nome:caracter(30), telefone:numerico(10), codigo_cidade:inteiro, matricula_funcionario_gerente:inteiro)

codigo_cidade referencia tbCidade

codigo_funcionario_gerente referencia tbFuncionario

tbFabricante (codigo:inteiro, nome:caracter(30), CNPJ:inteiro, fone:numerico(10), codigo_cidade:inteiro)

codigo_cidade referencia tbCidade

tbProduto (codigo:inteiro, descricao:caracter(50), preco_unitario:real, codigo_fabricante:inteiro)

codigo_fabricante referencia tbFabricante

tbVenda (codigo_venda:inteiro, valor_total:real, data_venda:data, matricula_funcionario:inteiro)

codigo_funcionario referencia tbFuncionario

tbItens_venda (codigo_venda:inteiro, codigo_produto:inteiro, valor_item:real, quantidade:inteiro)

codigo_venda referencia tbVenda

codigo_produto referencia tbProduto

28

Banc

o de

Dad

os

8)

codigo_fabricantetelefone_funcionarionome_funcionario

matricula

Cidade

UF_cidadenome_cidade

codigo_cidade

localiza-se Loja

nome_lojacodigo_loja

telefone_loja

trabalhagerenciapertence

Funcionarionome_fabricanteCNPJFabricante

telefone_fabricante

RGsexo

codigo_produto

fabrica

Produto

descricao_produtopreco_unitario_produto

Itensvenda Venda

realiza

valor_item

quantidade_item

valor_vendadata_venda

codigo_venda

(1,1)

(1,1)

(1,n)

(1,1)

(1,n)

(1,n) (1,n)(0,n)

(1,1)

(1,1) (1,n)

(0,1)

(1,1)(1,n)

9)

tbCidade (nome_cidade:caracter(30), UF:caracter(2), regiao:caracter(15))

tbCliente (CPF_cliente:caracter(11), nome_cliente:caracter(50), data_nascimento_cliente:data)

tbLivro (ISBN:caracter(11), titulo_livro:caracter(50), genero_livro:caracter(20), valor_livro:real)

tbVenda (codigo_venda:inteiro, valor_vendal:real, data_venda:data, quantidade_venda:inteiro, nome_cidade:caracter(30), UF:caracter(2), CPF_cliente:caracter(11), ISBN:caracter(11))

(nome_cidade, UF) referencia tbCidade

CPF_cliente referencia tbCliente

ISBN referencia tbLivro

tbAutor (codigo_autor:inteiro, nome_autor:caracter(50), sexo_autor:caracter(1))

tbLivroAutor (codigo_autor:inteiro, ISBN:inteiro)

ISBN referencia tbLivro

codigo_autor referencia tbAutor

29

Banco de Dados

10)tbDepartamento(numero_depto:inteiro, nome_depto: caracter(20))

tbProjeto(numero_projeto:inteiro, nome_projeto:caracter(20), numero_depto:inteiro)

numero_depto referencia tbDepartamento

tbEmpregado(matricula_emp:inteiro, CPF_emp:caracter(11), nome_emp:caracter(50), fone_emp:numerico(10), matricula_emp_supervisor:inteiro, numero_depto:inteiro)

numero_depto referencia tbDepartamento

matricula_emp_supervisor referencia tbEmpregado

tbEmpregadoProjeto(matricula_emp:inteiro, numero_projeto:inteiro, horas:time)

matricula_emp referencia tbEmpregado

numero_projeto referencia tbProjeto

tbDependente (matricula_emp:inteiro, nome_dependente:caracter(50), sexo_dependente:caracter(1), data_nascimento:data)

matricula_emp referencia tbEmpregado


O capítulo 5 tem por objetivo apresentar a finalização da etapa de modelagem: que com-preende a conversão para o modelo relacional, a normalização do modelo (caso o mesmo ainda não esteja normalizado) e a criação do dicionário de dados da base de dados. Também é apre-sentado aqui o Diagrama do Modelo Relacional.

No início desse capítulo, são apresentadas três regras de como converter uma especialização para o modelo relacional. É importante que o professor explique claramente e dê exemplos de qual é a forma mais adequada para cada situação, enfatizando os prós e os contras de cada abordagem.

Em relação à normalização, neste livro foram explicadas apenas as três principais formas normais. Nada impede que o professor (havendo tempo para isso) explique outras formas nor-mais. O importante é que sejam dados exemplos e que sejam feitos exercícios para uma maior compreensão do que foi explicado.

Quando o professor for explicar as colunas do dicionário de dados, já pode introduzir o conceito de restrição de integridade. Esse conceito deve ser revisado no capítulo 7, quando será explicado a SQL – DDL.

Respostas – página 591) A transformação de uma especialização do modelo de ER para o modelo relacional pode

ser feita de 3 diferentes modos:

1o Criar uma tabela única com o nome da entidade pai e essa tabela irá conter: todos os atributos das entidades pai (genérica), os atributos da(s) entidade(s) filha(s) (entidades especializadas), atributos referentes a possíveis relacionamentos e um atributo chamado “tipo” que identifi-cará qual entidade especializada está sendo representada em uma linha. A chave primária dessa tabela será a própria chave primária da entidade pai apenas para a entidade pai.

30

Banc

o de

Dad

os

2o Criar tabelas apenas para as entidades filhas. Assim, cada entidade filha que virar uma tabela terá como atributos tantos os seus atributos específicos e de seus relacionamentos diretos quanto os dados da entidade pai mais os dados dos relacionamentos de outras entidades com a entidade pai. A chave primária de cada uma das tabelas especializadas será a chave primária da entidade pai.

3o Criar uma tabela para cada entidade (tanto entidade pai, quanto filhas). Assim, cada tabela terá seus atributos específicos e os atributos dos seus relacionamentos. As tabelas referentes às entidades filhas também receberão como chave estrangeira a chave primária da entidade pai. A chave primária para cada entidade filha será a chave estrangeira, que neste caso terá as duas funções (PK e FK). Caso exista algum atributo que identifique unicamente a entidade filha ele poderá ser escolhido como chave primária e a chave primária da entidade pai passa apenas como chave estrangeira.

2) A primeira abordagem irá conter muitos valores nulos, uma vez que dado o tipo do objeto somente os atributos referentes àquele objeto serão preenchidos. Por isso, nem todos os atri-butos serão obrigatórios. Por outro lado, essa primeira abordagem tem a vantagem de dispensar a necessidade de junção entre tabelas, uma vez que os dados estão todos na mesma tabela.

3) A segunda abordagem é pouco recomendada porque pode gerar redundância de dados uma vez que os dados da entidade genérica são repetidos em todas tabelas especializadas. Assim, se uma pessoa for tanto professor como aluno, teremos as informações referentes a essa pessoa repetida nas duas tabelas. Portanto, essa abordagem só deve ser utilizada quando tivermos uma especialização exclusiva, ou seja, uma pessoa ou é do tipo aluno ou do tipo professor.

4) A terceira abordagem tem a vantagem de evitar os valores nulos que aparecem na primeira abordagem e ainda não permitir a duplicidade como na segunda abordagem.

5)

tbCategoria(codigo_categoria:inteiro, nome_categoria:caracter(20))

tbProduto(codigo_produto:inteiro, nome_produto:caracter(30), valor_produto:real)

tbLimpeza(codigo_produto:inteiro, superficie:caracter(10))


tbAlimentoPerecivel(codigo_produto:inteiro, conservacao:caracter(15), data_validade:data, tipo_alimento:booleano, codigo_categoria:inteiro)


codigo_categoria referencia tbCategoria

Obs.: Para este exemplo o atributo tipo_alimento poderia ter sido omitido, uma vez queaentidadepai“Alimento”sóseespecializaemumaúnicaoutraentidade(queéa entidade “Perecivel”).

31

Banco de Dados

6)

(1,1)

(1,n)

tbCategoria

codigo_categoria:inteiro

nome_categoria:caracter(20)

tbAlimento_Perecivel

data_validade:data

codigo_produto:inteiro

conservacao:caracter(15)

codigo_categoria:inteiro

tipo_alimento:booleano

(1,1) (1,1)

(0,n)(0,n) tbLimpeza

superficie:caracter(10)


tbProduto


nome_produto:caracter(30)

valor_produto:real

7) Neste exercício o aluno deve escrever o que ele entendeu sobre cada uma das restrições solicitadas no exercício. Abaixo segue as definições que a autora apresentou.

• Nulo: define se um atributo permite ou não o valor nulo, ou seja, define se o atributo será obrigatório ou não.

• Domínio ou Regra de Domínio: define quais valores serão permitidos cadastrar para um atributo.

• Chave Primária: permite identificar um único registro de uma tabela. Não permite valores repetidos ou nulos.

• Chave Estrangeira: garante a integridade referencial da base de dados, pois não permite que sejam inseridos valores diferentes dos já inseridos em sua primária correspondente.

• Default: permite que seja inserido um valor padrão caso o usuário não digite nada para o campo.

• Unique: é aplicada apenas para atributos que não são chave primária e que não podem se repetir.

8)

tbEscola

cidade_escola:caracter(20)

nome_escola:caracter(50)

codigo_escola:inteiro

matricula_diretor:inteiro

tbProfessor

CPF_professor:caracter(11)

escolaridade:caracter(10)

matricula_professor:inteiro

RG_pessoa:caracter(9)

codigo_escola:inteiro

tbDisciplina

codigo_disciplina:inteiro

nome_disciplina:caracter(20)

tbContato

fone_contato:numerico(10)

nome_contato:caracter(50)

matricula_aluno:inteiro

tbAluno

data_nascimento_aluno:data

matricula_aluno:inteiro

possui_matricula_aluno:inteiro


codigo_turma:inteiro

tbMinistra

ano_numerico(4)

matricula_professor:inteiro


codigo_disciplina:inteiro

tbTurma

nome_turma:caracter(5)


tbPessoa

telefone_pessoa:numerico(10)

nome_pessoa:caracter(50)


(0,1) (0,n)

(0,n)

(1,1)

(1,1) (1,1)

(1,1)

(1,1)

(1,1)

(1,1) (1,1)

(1,1)

(1,n) (1,n)

(1,n)

(1,n)

(1,n)

(1,n)

32

Banc

o de

Dad

os

9) a.

1FN: a tabela está na Primeira Forma Normal. 2FN: é necessário normalizar porque o atributo nome_motorista depende apenas

de parte da PK.

tbMotorista(CPF_motorista, nome_motorista)

tbAcidente(numero_placa_carro, CPF_motorista, total_de_danos, data_acidente)

CPF_motorista referencia tbMotorista

3FN: as tabelas já estão na Terceira Forma Normal, portanto o modelo ficará com duas tabelas

b.

1FN: é necessário normalizar porque existem atributos multivalorados e grupos de atributos repetidos.

tbPaciente(codigo_paciente, nome_paciente, codigo_convenio, nome_convenio)

tbTelefonePaciente(fone_paciente, codigo_paciente)

codigo_paciente referencia tbPaciente

tbPacienteMedico(codigo_paciente, CRM_medico, nome_medico, data_consulta)


tbPacienteExame(codigo_paciente, codigo_exame, nome_exame, diagnostico_principal)


2FN: é necessário normalizar as tabelas tbPacienteMedico e tbPacienteExame. As tabe-las tbPaciente e tbTelefonePaciente apenas serão repetidas.

tbMedico(CRM_medico, nome_medico)

tbPacienteMedico(codigo_paciente, CRM_medico, data_consulta)


CRM_medico referencia tbMedico

tbExame(codigo_exame, nome_exame)

33

Banco de Dados

tbPacienteExame(codigo_paciente, codigo_exame, diagnostico_principal)


codigo_exame referencia tbExame

3FN: é necessário normalizar a tabela “tbPaciente” para eliminar dependências transitivas.

tbConvenio(codigo_convenio, nome_convenio)

tbPaciente(codigo_paciente, nome_paciente, codigo_convenio)

codigo_convenio referencia tbConvenio

O modelo final ficará assim:

tbConvenio(codigo_convenio, nome_convenio)

tbPaciente(codigo_paciente, nome_paciente, codigo_convenio)

codigo_convenio referencia tbConvenio

tbTelefonePaciente(fone_paciente, codigo_paciente)


tbMedico(CRM_medico, nome_medico)

tbPacienteMedico(codigo_paciente, CRM_medico, data_consulta)


CRM_medico referencia tbMedico

tbExame(codigo_exame, nome_exame)

tbPacienteExame(codigo_paciente, codigo_exame, diagnostico_principal)


codigo_exame referencia tbExame

10) a.

1FN: é necessário normalizar porque existem grupos de atributos repetidos.

tbAluno(cod_aluno, nome_aluno, sexo_aluno, data_nascimento_aluno, codigo_curso, nome_curso, nome_diretor)

tbAlunoDisciplina (cod_aluno, codigo_disciplina, nome_disciplina, nota_disciplina)

cod_aluno referencia tbAluno

34

Banc

o de

Dad

os

2FN: é necessário normalizar a tabela tbAlunoDisciplina. A tabela tbAluno apenas será repetida.

tbDisciplina (codigo_disciplina, nome_disciplina)

tbAlunoDisciplina (cod_aluno, codigo_disciplina, nota_disciplina)


3FN: é necessário normalizar a tabela tbAluno para eliminar dependências transitivas.

tbCurso(codigo_curso, nome_curso, nome_diretor)

tbAluno(cod_aluno, nome_aluno, sexo_aluno, data_nascimento_aluno, codigo_curso)

codigo_curso referencia tbCurso

O modelo final ficará assim:

tbCurso(codigo_curso, nome_curso, nome_diretor)

tbAluno(cod_aluno, nome_aluno, sexo_aluno, data_nascimento_aluno, codigo_curso)

codigo_curso referencia tbCurso

tbDisciplina (codigo_disciplina, nome_disciplina)

tbAlunoDisciplina (cod_aluno, codigo_disciplina, nota_disciplina)


O DER para o modelo relacional normalizado será:

AlunoDisciplina

nome_disciplina

codigo_disciplina

codigo_cursonome_diretorcodigo_curso

data_nascimento_alunosexo_aluno

nome_alunocodigo_aluno

Aluno faz Curso

disciplina

(1,1)

(1,n)

nota_disciplina

(1,n)

(1,n)

b. A letra b do exercício 10 deve ser feito da mesma forma que na letra a (passo a passo) para que o aluno possa entender a solução.

35

Banco de Dados


Esse capítulo tem por objetivo colocar em prática todos os conceitos estudados até o capítulo 5. Para isso, é apresentada uma situação e, a partir dela, será construído o Diagrama de ER, a Descrição do Modelo Relacional, o Diagrama do Modelo Relacional e o Dicionário de Dados. Além disso, as regras de normalização são aplicadas no intuito de validar se o modelo está mesmo normalizado.

O professor poderá criar outras situações para os alunos desenvolverem passo-a-passo a modelagem ou propor um projeto em que os alunos procurem um cliente real e desenvolvam todo o projeto de uma base de dados para satisfazer as necessidades desse cliente.

Esse tipo de exercício é importante para que o aluno consiga entender e integrar todas as etapas de modelagem de uma base de dados em um único projeto.

Respostas – página 69Como as descrições para os exercícios do capítulo 6 são informais, elas podem ter diferentes

interpretações. Por este motivo, não existe somente uma solução correta, mas os diagramas devem refletir de forma coerente a descrição.

A descrição do modelo relacional somente foi feita no exercício 2, porque representa a mesma coisa que o Diagrama do Modelo Relacional (foi omitido propositalmente o domínio dos atributos nessa descrição). Os alunos devem fazer a descrição e o diagrama do modelo relacional como uma forma de treinamento e fixação. Nas provas, pode ser cobrado apenas um deles.

Os exercícios 5, 6, 7, 8, 9 e 10 não apresentam resposta porque espera-se que o professor resolva estes exercícios junto com os alunos em sala de aula. O mais interessante é que várias soluções serão propostas pelos alunos e cabe ao professor destacar vantagens e desvantagens dessas soluções.

Todos os modelos relacionais apresentados como solução estão normalizados, conside-rando-se as três formas normais (1FN, 2FN e 3FN).

1)

CNPJnome_fornecedor

telefone_fornecedor

Cliente

telefone_clienteCPF_cliente

nome_cliente

realiza Pagamento

valor_finaldesconto

codigo_pagamento

possui

Venda

possui Parcela

valor_parceladata_vencimento_parcela

(0,n)

faz funcionario

possui

Itens_de_vendaMedicamento representa

Fornecedor

fornece

(1,1) (1,n) (1,1)

codigo_parcela

(1,1)

(1,1)

(0,n)data_venda

codigo_vendavalor_sem_desconto

matriculanome_funcionarioRG_funcionarioCPF_funcionariotelefone_funcionario

codigo_itemvalor_item_quantidadequantidade

valor_unitarionome_medicamento

tipo_medicamentocodigo_medicamento

data_validade

(1,1)

(1,1)

(1,n)

(1,n)(1,1)

(1,n)

(1,1)

36

Banc

o de

Dad

os

2)

Descrição do Modelo Relacional:

tbCliente(CPF_cliente, nome_cliente, telefone_cliente)

tbFornecedor(CNPJ, nome_fornecedor, telefone_fornecedor)

tbFuncionario(matricula, nome_funcionario, telefone_funcionario, RG_funcionario, CPF_funcionario)

tbMedicamento(codigo_medicamento, nome_medicamento, data_validade, valor_unitario, tipo_medicamento, CNPJ)

CNPJ referencia tbFornecedor

tbVenda(codigo_venda, valor_sem_desconto, data_venda, matricula_funcionario)

matricula_funcionario referencia tbFuncionario

tbItensVenda(codigo_item, valor_item_quantidade, quantidade, codigo_venda, codigo_medicamento)


codigo_medicamento referencia tbMedicamento

tbPagamento(codigo_pagto, valor_final, desconto, CPF_cliente, codigo_venda)

CPF_cliente referencia tbCliente


tbParcela(codigo_parcela, valor_parcela, data_vencimento_parcela, codigo_pagto)

codigo_pagto referencia tbPagamento

Diagrama do Modelo Relacional

tbCliente

telefone_cliente: numerico(10)

CPF_cliente: caracter(11)

nome_cliente: caracter(50)

tbFornecedor

CNPJ: inteiro

nome_fornecedor: caracter(50)

telefone_fornecedor: numerico(10)

tbMedicamento

data_validade: data

nome_medicamento: caracter(30)

codigo_medicamento: inteiro

valor_unitario: real

tipo_medicamento: caracter(1)

CNPJ: inteiro

tbItens_de_venda

codigo_item: inteiro

quantidade: inteiro

valor_item_quantidade: real

codigo_venda: inteiro


tbVenda


data_venda: data

valor_sem_desconto: real

matricula: inteiro

tbPagamento

codigo_pagamento: inteiro

desconto: real

valor_final:real

CPF_cliente: caracter(11)


tbParcela

codigo_parcela: inteiro

valor_parcela: real

data_vencimento_parcela: data

codigo_pagamento: inteiro

tbFuncionario

telefone_funcionario: numerico(10)

CPF_funcionario: caracter(11)

RG_funcionario: caracter(9)

nome_funcionario: caracter(50)

matricula: inteiro

(1,1) (1,n)

(1,1)(1,1)

(1,1)(0,n)

(1,1)

(1,n)

(1,1) (1,n)

(1,n)

(1,1)

(0,n)

(1,1)

37

Banco de Dados

3)

telefone_fornecedorCNPJ

nome_fornecedor

possui

Medico

CRMnome_medico

especialidade

atende

Paciente

CPF_pacienteRG_paciente

nome_paciente

possui

Prontuario

(1,1) (1,1)

numero_prontuario

RegistroConsultasintomasdiagnosticocodigo_registro

Paciente_SUS Paciente_Particular

numero_carteirinha

Medicamento

posologianome_medicamento

codigo_medicamento

ExameRegistro

Examecodigo_examenome_exametipo_exane

forneceFornecedor

codigo_fornecedor

data_abertura

MedicamentoRegistro

MedicoPacienteMedicamento

nome_conveniocodigo_particular

(1,1)

(1,n)

(0,1)

(1,1)

(0,n) (0,n)

(0,n)

(0,n)

(0,n)

(0,n)(0,n)

(0,n)

(0,n)

4)tbMedico

CRM: inteiro

nome_medico: caracter(50)

especialidade: Texto(1)

tbMedicoPacienteMedicamento

numero_carteirinha:inteiro


CRM: inteiro

tbPaciente_SUS

numero_carteirinha:inteiro

CPF_paciente: caracter(11)

tbFornecedor

telefone_fornecedor: numerico(10)

CNPJ: inteiro

codigo_fornecedor: inteiro

nome_fornecedor: caracter(50)

tbMedicamento

posologia: caracter(50)

nome_medicamento: caracter(50)


codigo_fornecedor: inteiro

tbMedicamentoRegistro

codigo_registro: inteiro


tbPaciente


RG_paciente: caracter(9)

nome_paciente: caracter(50)

tbRegistroConsulta

sintomas: caracter(200)

diagnostico: caracter(200)


numero_prontuario: inteiro

CRM: inteiro

tbExameRegistro


codigo_exame: inteiro

tbPaciente_Particular

nome_convenio: caracter(50)

codigo_particular: inteiro

CPF_paciente:caracter(11)

tbProntuario

numero_prontuario:inteiro

data_abertura: data


(1,1)

(1,1)

(0,1)

(0,n)

(0,n)

(0,1)

(0,n)

(0,1) (1,1)

(1,n)

(1,1)

(0,n)

(0,n)

(1,1)

(0,n)

(0,n)

(1,1) (1,1)

(0,n) (0,n)

(1,1)

(1,1) (0,1)

(0,n)

(1,1)

(0,n)

tbExame

codigo_exame: inteiro

nome_exame: caracter(50)

tipo_exame: caracter(30)

38

Banc

o de

Dad

os


Uma vez que os modelos de dados (conceitual e lógico) estão prontos, a próxima etapa do desenvolvimento de um projeto de banco de dados é a implementação do modelo em um SGBD relacional. Para fazermos a implementação, teremos que utilizar uma linguagem própria para banco de dados chamada Linguagem SQL.

O professor deverá apresentar um pequeno histórico da linguagem SQL e, em seguida, apresentar a linguagem SQL para definição da base de dados (DDL). Deve também explicar os principais comandos da DDL (CREATE, ALTER e DROP) e destacar que, antes de criar as tabelas, deve-se criar a base de dados.

Quando o professor for explicar sobre a criação de tabelas, é necessário retomar o conceito de restrições de integridade e mostrar aos alunos como se define essas restrições usando SQL.

Como estamos falando sobre a definição da base de dados, o professor necessitará abordar também o conceito de índices, tipos de índices e vantagens de se utilizar índices.

Respostas – página 841)

data_emprestimo

CPF_clientenome_clientedata_cadastro

codigo_cliente

UF_clientecidade_cliente

Categoria

codigo_categorianome_categoria

pertence Titulo

anonome_titulo

codigo_titulo

possui

Filme

pertence Classe

codigo_classenome_classe

(1,1)

cliente

(1,1) (1,n) (1,n)

preco_classe

(1,1)

codigo_filme

nome_distribuidor

EmprestimoDevolução

valor_multa

data_devolucao_prevista

data_devolucao_efetiva

(1,n)

(0,n)

(0,n)

2) A criação de índices em uma tabela é o principal método de otimização de que os SGBD oferecem. Isso porque a execução de consultas que utilizam atributos indexados é, na maioria dos casos, mais rápidas do que as buscas por campos não indexados. Assim, pode-se utilizar um índice quando for desejável melhorar o desempenho das consultas.

39

Banco de Dados

3) Deve-se indexar atributos que tenham poucos valores que se repetem. Quanto mais sele-tivo for o atributo, mais vantajoso será indexar o campo. Como o atributo sexo tem apenas dois valores possível (F ou M) ele não é útil como índice.

4)

CREATE DATABASE dbEmpresa

5) Devem ser criadas primeiramente as tabelas que não possuem FK. Se a tabela tem uma FK, esta FK deve fazer referência a uma tabela que já foi criada. No nosso exercício a ordem para criação das tabelas é: 1o tbGerente; 2o tbCompanhia; 3o tbEmpregado; e 4o tbTrabalha.

6)

CREATE TABLE tbGerente

(cod_gerente INT,

nome_gerente VARCHAR(20) NOT NULL,

CONSTRAINT pk_tbGerente PRIMARY KEY (cod_gerente)

);

CREATE TABLE tbCompanhia

(cod_companhia INT,

nome_companhia VARCHAR(20) NOT NULL,

cidade_companhia VARCHAR(20),

CONSTRAINT pk_tbCompanhia PRIMARY KEY (cod_companhia)

);

CREATE TABLE tbEmpregado

(cod_emp INT,

nome_emp VARCHAR(50) NOT NULL,

rua_emp VARCHAR(30),

cidade_emp VARCHAR(20),

fone_emp NUMERIC(10),

cod_gerente INT,

CONSTRAINT pk_tbEmpregado PRIMARY KEY (cod_emp),

CONSTRAINT fk_tbEmpregado_tbGerente FOREIGN KEY (cod_gerente)

REFERENCES tbGerente (cod_gerente) ON DELETE CASCADE ON UPDATE CASCADE

);

CREATE TABLE tbTrabalha

(cod_emp INT,

40

Banc

o de

Dad

os

cod_companhia INT,

salario FLOAT,

CONSTRAINT pk_tbTrabalha PRIMARY KEY (cod_emp,cod_companhia),

CONSTRAINT fk_tbTrabalha_tbEmpregado FOREIGN KEY (cod_emp)

REFERENCES tbEmpregado (cod_emp) ON DELETE CASCADE ON UPDATE CASCADE,

CONSTRAINT fk_tbTrabalha_tbCompanhia FOREIGN KEY (cod_companhia)

REFERENCES tbCompanhia (cod_companhia) ON DELETE CASCADE ON UPDATE CASCADE

);

7) CREATE INDEX idx_NomeEmpregado

ON tbEmpregado (nome_emp);

8)

CREATE UNIQUE INDEX idx_NomeCompanhia

ON tbCompanhia (nome_companhia);

9)

ALTER TABLE tbGerente

ADD telefone_gerente VARCHAR(10);

10)

DROP TABLE tbGerente;


Depois que o esquema da base de dados com suas tabelas e restrições foi criado através de comandos DDL, podemos começar a inserir os dados dentro da nossa base de dados. Para fazermos isso, usamos os comandos DML. Os comandos DML nos permitem inserir, alterar, excluir e consultar dados na nossa base de dados.

Esse capítulo é completamente prático e deve ser ensinado no laboratório em um SGBD. É importante que os alunos consigam visualizar o que está acontecendo na prática e que enten-dam como funciona cada comando.

É importante dar bastante ênfase ao comando INNER JOIN e explicar a diferença desse comando em relação ao produto cartesiano (que ainda é bastante utilizado, mas vem sendo substituído pelo INNER JOIN).

41

Banco de Dados

Respostas – página 97Os exercícios dos capítulos 8, 9 e 10 podem ser escritos na SQL de diferentes formas. As

soluções apresentadas neste manual são apenas sugestões.

Observação: Utilize comandos SQL para resolver os exercícios. Se houver a necessidade de utilizar mais de uma tabela em uma consulta, utilize o INNER JOIN ao invés do produto cartesiano.

1)

CREATE TABLE tbSala

(numero_sala INT,

descricao_sala VARCHAR(20) NOT NULL,

capacidade INT,

CONSTRAINT pk_tbSala PRIMARY KEY (numero_sala)

);

CREATE TABLE tbDiretor

(codigo_diretor INT,

nome_diretor VARCHAR(20) NOT NULL,

CONSTRAINT pk_tbDiretor PRIMARY KEY (codigo_diretor)

);

CREATE TABLE tbFilme

(codigo_filme INT,

nome_filme VARCHAR(50) NOT NULL,

ano_lancamento INT,

categoria_filme VARCHAR(20),

codigo_diretor INT,

CONSTRAINT pk_tbFilme PRIMARY KEY (codigo_filme),

CONSTRAINT fk_tbFilme_tbDiretor FOREIGN KEY (codigo_diretor)

REFERENCES tbDiretor (codigo_diretor) ON DELETE CASCADE ON UPDATE CASCADE

);

CREATE TABLE tbSalaFilme

(numero_sala INT,

codigo_filme INT,

data DATE,

horario TIME,

42

Banc

o de

Dad

os

CONSTRAINT pk_tbSalaFilme PRIMARY KEY (numero_sala,codigo_filme),

CONSTRAINT fk_tbSalaFilme_tbSala FOREIGN KEY (numero_sala)

REFERENCES tbSala (numero_sala) ON DELETE CASCADE ON UPDATE CASCADE,

CONSTRAINT fk_tbSalaFilme_tbFilme FOREIGN KEY (codigo_filme)

REFERENCES tbFilme (codigo_filme) ON DELETE CASCADE ON UPDATE CASCADE

);

CREATE TABLE tbPremio

(codigo_premio INT,

nome_premio VARCHAR(20) NOT NULL,

ano_premiacao INT,

codigo_filme INT,

CONSTRAINT pk_tbPremio PRIMARY KEY (codigo_premio),

CONSTRAINT fk_tbPremio_tbFilme FOREIGN KEY (codigo_filme)

REFERENCES tbFilme (codigo_filme) ON DELETE CASCADE ON UPDATE CASCADE

);

2) Para o exercício 2, será mostrado apenas a inserção de um registro para dada tabela.

INSERT INTO tbSala

VALUES (1,’Sala Infantil’,200);

INSERT INTO tbDiretor

VALUES (1,’Marcelo Reis’);

INSERT INTO tbFilme

VALUES (1,’A Lagarta Lily’,2009, ‘Infantil’, 1);

INSERT INTO tbSalaFilme

VALUES (1,1,’2010-07-23’,’13:30’);

INSERT INTO tbPremio

VALUES (1,’Melhor Filme’,2010, 1);

3)

SELECT nome_diretor

FROM tbDiretor;

43

Banco de Dados

4)

SELECT nome_filme

FROM tbFilme

WHERE categoria_filme = ‘Terror’;

5)

UPDATE tbSala

SET capacidade = 200

WHERE numero_sala = 8;

6)

UPDATE tbSalaFilme

SET numero_sala = 8

WHERE data = ‘2010-11-15’ AND numero_sala = 12;

7)

É necessário excluir primeiro a tabela que possui a FK para depois excluir o registro na tabelaqueéPK(IntegridadeReferencial).

DELETE FROM tbFilme

WHERE codigo_diretor IN (SELECT codigo_diretor

FROM tbDiretor

WHERE nome_diretor = ‘Pedro Paulo Matos’);

DELETE FROM tbDiretor

WHERE nome_diretor = “Pedro Paulo Matos”;

8)

SELECT nome_filme

FROM tbFilme INNER JOIN tbDiretor ON tbFilme.codigo_ diretor = tbDiretor.codigo_diretor

WHERE nome_diretor = ‘Jorge da Penha’;

44

Banc

o de

Dad

os

9)

SELECT nome_filme, horario

FROM tbSalaFilme INNER JOIN tbFilme ON tbSalaFilme.codigo_filme = tbFilme.codigo_filme

WHERE data = ‘2010-04-20’;

10)

SELECT nome_premio

FROM tbPremio INNER JOIN tbFilme ON tbPremio.codigo_filme = tbFilme.codigo_filme

WHERE nome_filme = ‘Titanic’;

11)

SELECT nome_filme

FROM tbSala INNER JOIN tbSalaFilme ON tbSalaFilme.numero_sala = tbSala.numero_sala

INNER JOIN tbFilme ON tbSalaFilme.codigo_filme = tbFiIme.codigo_filme

WHERE capacidade > 200;

12)

SELECT nome_filme, numero_sala, horario

FROM tbFilme INNER JOIN tbSalaFilme ON tbSalaFilme.codigo_filme = tbFilme.codigo_filme

WHERE data BETWEEN ‘2010-05-01’ AND ‘2010-05-31’;

13)

SELECT nome_filme

FROM tbPremio INNER JOIN tbFilme ON tbPremio.codigo_filme = tbFilme.codigo_filme

WHERE nome_premio = ‘Melhor Diretor’ AND ano_premiacao IN (2007, 2008, 2009, 2010);

45

Banco de Dados

14)

SELECT nome_filme

FROM tbFilme INNER JOIN tbSalaFilme ON tbSalaFilme.codigo_filme = tbFilme.codigo_filme

WHERE categoria_filme = ‘Comedia’ AND data BETWEEN ‘2010-06-01’ AND ‘2010-06-30’

15)

SELECT descricao_sala, categoria_filme, nome_filme

FROM tbDiretor INNER JOIN tbFilme ON tbDiretor.codigo_diretor = tbFilme.codigo_diretor

INNER JOIN tbSalaFilme ON tbSalaFilme.codigo_filme = tbFilme.codigo_filme

INNER JOIN tbSala ON tbSalaFilme.numero_sala = tbSala.numero_sala

WHERE nome_diretor =’Severino Juca’;


O capítulo 9 apresenta comandos mais avançados para criação de consultas SQL.

Como existe mais de uma maneira de se escrever uma mesma consulta, nesse capítulo o professor pode apresentar os novos comandos e mostrar que uma mesma consulta poderia ser escrita de maneiras diferentes. Assim, enfatiza qual a forma mais otimizada de se escrever uma consulta. Isso é bastante interessante. No entanto, se o professor não tiver tempo para fazer isso, pode simplesmente apresentar o comando e explicar se a utilização dele pode melhorar ou não o desempenho da consulta.

Respostas – página 107Observação: Utilize comandos SQL para resolver os exercícios. Se houver a necessidade

de utilizar mais de uma tabela em uma consulta, utilize o INNER JOIN ao invés do produto cartesiano.

1)

CREATE TABLE tbNovela

(codigo_novela INT,

nome_novela VARCHAR(30) NOT NULL,

data_primeiro_capitulo DATE,

46

Banc

o de

Dad

os

data_ultimo_capitulo DATE,

horario_exibicao TIME,

CONSTRAINT pk_tbNovela PRIMARY KEY (codigo_novela)

);

CREATE TABLE tbAtor

(codigo_ator INT,

nome_ator VARCHAR(20) NOT NULL,

idade INT,

cidade_ator VARCHAR(20),

salario_ator FLOAT,

sexo_ator CHAR(1),

CONSTRAINT pk_tbAtor PRIMARY KEY (codigo_ator)

);

CREATE TABLE tbCapitulo

(codigo_capitulo INT,

nome_capitulo VARCHAR(50) NOT NULL,

data_exibicao_capitulo DATE,

codigo_novela INT,

CONSTRAINT pk_tbCapitulo PRIMARY KEY (codigo_capitulo),

CONSTRAINT fk_tbCapitulo_tbNovela FOREIGN KEY (codigo_novela)

REFERENCES tbNovela (codigo_novela) ON DELETE CASCADE ON UPDATE CASCADE

);

CREATE TABLE tbPersonagem

(codigo_personagem INT,

nome_personagem VARCHAR(50) NOT NULL,

idade_personagem INT,

situacao_financeira_personagem VARCHAR(20),

codigo_ator INT,

CONSTRAINT pk_tbPersonagem PRIMARY KEY (codigo_personagem),

47

Banco de Dados

CONSTRAINT fk_tbPersonagem_tbAtor FOREIGN KEY (codigo_ator)

REFERENCES tbAtor (codigo_ator) ON DELETE CASCADE ON UPDATE CASCADE

);

CREATE TABLE tbNovelaPersonagem

(codigo_personagem INT,

codigo_novela INT,

CONSTRAINT pk_tbNovelaPersonagem PRIMARY KEY (codigo_personagem,codigo_novela),

CONSTRAINT fk_tbNovelaPersonagem_tbPersonagem FOREIGN KEY (codigo_personagem)

REFERENCES tbPersonagem (codigo_personagem) ON DELETE CASCADE ON UPDATE CASCADE,

CONSTRAINT fk_tbNovelaPersonagem_tbNovela FOREIGN KEY (codigo_novela)

REFERENCES tbNovela (codigo_novela) ON DELETE CASCADE ON UPDATE CASCADE

);

2) Para o exercício 2, será mostrado apenas a inserção de um registro para dada tabela.

INSERT INTO tbNovela

VALUES (1,’Misterios de uma Vida’,’2010-10-02’,’2011-01-25’,’18:00’);

INSERT INTO tbAtor

VALUES (1,’Marcelo Reis’, 35,’Curitiba’, 5300,’M’);

INSERT INTO tbCapitulo

VALUES (10,’A Verdade’,’2010-12-02’, 1);

INSERT INTO tbPersonagem

VALUES (1,’Mario’, 30,’rico’,1);

INSERT INTO tbNovelaPersonagem

VALUES (1,1);

48

Banc

o de

Dad

os

3)

SELECT data_ultimo_capitulo

FROM tbNovela

WHERE nome_novela = ‘Misterios de uma Vida’;

4)

SELECT nome_novela

FROM tbNovela

WHERE horario_exibicao IS NULL;

5)

SELECT nome_ator

FROM tbAtor

WHERE cidade_ator LIKE ‘M%’;

6)

SELECT COUNT(*) AS QUANTIDADE

FROM tbNovela

WHERE nome_novela LIKE ‘%Vida%’;

7)


FROM tbAtor INNER JOIN tbPersonagem ON tbPersonagem.codigo_ator = tbAtor.codigo_ator

INNER JOIN tbNovelaPersonagem

ON tbNovelaPersonagem.codigo_personagem = tbPersonagem.codigo_personagem

WHERE nome_ator LIKE ‘Fernando Souza’;

49

Banco de Dados

8)

SELECT *

FROM tbPersonagem

ORDER BY nome_personagem;

9)

SELECT *

FROM tbPersonagem

ORDER BY idade_personagem DESC;

10)


FROM tbAtor;

11)


FROM tbNovela;

12)

SELECT nome_novela, COUNT(*) AS ‘QUANTIDADE de CAPITULOS’

FROM tbNovela INNER JOIN tbCapitulo

ON tbNovela.codigo_novela = tbCapitulo.codigo_novela

GROUP BY nome_novela;

50

Banc

o de

Dad

os

13)

SELECT COUNT(*) AS ‘QUANTIDADE MENINAS’

FROM tbAtor

WHERE sexo = ‘F’;

14)

SELECT AVG(idade_personagem) AS ‘IDADE MEDIA’

FROM tbPersonagem;

15)

SELECT COUNT(*) AS ‘QUANTIDADE de PERSONAGENS’

FROM tbPersonagem

WHERE idade_personagem < 15;

16)

SELECT nome_ator


WHERE tbAtor.idade = tbPersonagem.idade_personagem;

17)

SELECT MAX(salario_ator) AS ‘Maior Salario’

FROM tbAtor;

18)

SELECT MIN(salario_ator) AS ‘Menor Salario’

FROM tbAtor;

51

Banco de Dados

19)

SELECT SUM(salario_ator)

FROM tbAtor;

20)

SELECT nome_ator, COUNT(*) AS ‘QUANTIDADE de PERSONAGENS’


GROUP BY nome_ator;

21)

SELECT nome_novela, COUNT(*) AS ‘QUANTIDADE de CAPITULOS’

FROM tbNovela INNER JOIN tbCapitulo

ON tbNovela.codigo_novela = tbCapitulo.codigo_novela

GROUP BY nome_novela

HAVING COUNT(*) > 40;

22)

SELECT nome_ator, COUNT(DISTINCT codigo_novela) AS ‘Quantidade de Novelas’

FROM tbAtor INNER JOIN tbPersonagem

ON tbPersonagem.codigo_ator = tbAtor.codigo_ator INNER JOIN tbNovelaPersonagem


WHERE situacão_financeira_personagem = ‘rico’

GROUP BY nome_ator

HAVING COUNT(DISTINCT codigo_novela) > 15;


É interessante apresentar aos alunos a possibilidade de se escrever consultas aninhadas. No entanto, deve-se destacar que a utilização pode trazer problemas de desempenho em algu-mas situações.

Quando o professor apresentar os tipos de junção, poderá explicar que algumas consultas aninhadas podem ser reescritas usando junção externa.

52

Banc

o de

Dad

os

Mostrar que uma consulta pode ser escrita de várias formas e permite que o aluno, em uma situação real, consiga decidir qual a melhor e mais adequada para implementar uma consulta.

É importante ressaltar que os capítulos 7, 8, 9 e 10 devem ser ensinados em laboratório e requerem dos alunos que façam muitos exercícios para que possam, efetivamente, aprender a utilizar os comandos ensinados.

Respostas – página 1181) Uma junção externa (outer join) é uma junção que retorna as linhas de uma tabela

mesmo que essas linhas não possuam registros equivalentes em outra tabela. Ou seja, mesmo que as linhas retornadas não satisfaçam a condição da junção. A junção externa LEFT OUTER JOIN retorna todas as linhas que satisfazem a condição da junção mais as linhas da tabela que ficam à esquerda da consulta mesmo que não satisfaçam a condição. A junção RIGHT OUTER JOIN, retorna todas as linhas relacionadas mais as linhas à direita que não possuem correspondente na tabela da esquerda.

2) O professor deve junto com os alunos propor situações em que poderiam ser utilizados os comandos de junção. É importante que o professor instigue os alunos a pensar em situações e não passe a resposta para essa questão antes de eles apresentarem suas hipóteses.

Observação: Para os próximos exercícios vamos utilizar o mesmo modelo relacional dos exercícios do capítulo 9.

Para resolver as questões utilize comandos SQL. Se houver a necessidade de utilizar mais de uma tabela em uma consulta, utilize o INNER JOIN ao invés do produto cartesiano.

3)

SELECT nome_ator

FROM tbAtor

WHERE codigo_ator NOT IN

(SELECT tbPersonagem.codigo_ator

FROM tbPersonagem INNER JOIN tbNovelaPersonagem

ON tbNovelaPersonagem.codigo_personagem = tbPersonagem.codigo_personagem);

4)

SELECT nome_ator, idade

FROM tbAtor

WHERE codigo_ator IN

(SELECT tbPersonagem.codigo_ator

FROM tbPersonagem INNER JOIN tbNovelaPersonagem


INNER JOIN tbNovela

ON tbNovelaPersonagem.codigo_novela = tbNovela.codigo_novela

WHERE nome_novela = ‘Ser Estranho’);

53

Banco de Dados

5)

SELECT nome_ator


WHERE nome_personagem = ‘Anna’;

6)

SELECT nome_ator


ON tbPersonagem.codigo_ator = tbAtor.codigo_ator


ON tbNovelaPersonagem.codigo_personagem = tbPersonagem.codigo_personagem WHERE codigo_novela IN

(SELECT codigo_novela




WHERE nome_ator = 'Joaquina Penteado');

7)

SELECT nome_ator




ON tbNovelaPersonagem.codigo_personagem = tbPersonagem. codigo_personagem

WHERE codigo_novela NOT IN

(SELECT codigo_novela

FROM tbAtor INNER JOIN tbPersonagem ON tbPersonagem.codigo_ ator = tbAtor.codigo_ator


ON tbNovelaPersonagem.codigo_personagem = tbPersonagem. codigo_personagem

WHERE nome_ator = 'Joaquina Penteado');

54

Banc

o de

Dad

os

8)

SELECT nome_personagem, idade_personagem

FROM tbPersonagem

WHERE idade_personagem IN

(SELECT MIN(idade_personagem)

FROM tbPersonagem);

9)

SELECT nome_ator, salario_ator

FROM tbAtor

WHERE salario_ator IN

(SELECT MIN(salario_ator)

FROM tbAtor);

10)

SELECT nome_ator

FROM tbAtor

WHERE cod_ator NOT IN

(SELECT cod_ator

FROM tbPersonagem

WHERE situacao_financeira_personagem = 'pobre');

11)

SELECT nome_ator, COUNT(DISTINCT codigo_novela) AS ‘Quantidade de Novelas das 18:00’

FROM tbAtor

INNER JOIN tbPersonagem




INNER JOIN tbNovela

ON tbNovela.codigo_novela = tbNovelaPersonagem.codigo_novela

WHERE horario_exibicao = ‘18:00’

GROUP BY nome_ator

HAVING COUNT(DISTINCT codigo_novela) > =1;

manual do professor – banco de dados · 3 banco de dados pretendemos contribuir para resolver o...

Documents