Banco de Dados WEB

Banco de DadosVanderson Jos Ildefonso Silva

2011Colatina - ES

Banco de Dados.indb 1 20/06/12 20:01

RIO GRANDEDO SUL

INSTITUTOFEDERAL

Presidncia da Repblica Federativa do Brasil

Ministrio da Educao

Secretaria de Educao a Distncia

Equipe de ElaboraoInstituto Federal do Esprito Santo IFES

Coordenao do CursoAllan Francisco Forzza Amaral/IFES

Professores-autoresVanderson Jos Ildefonso Silva/IFES

Comisso de Acompanhamento e ValidaoUniversidade Federal de Santa Catarina UFSC Coordenao InstitucionalAraci Hack Catapan/UFSC

Coordenao do ProjetoSilvia Modesto Nassar/UFSC

Coordenao de Design InstrucionalBeatriz Helena Dal Molin/UNIOESTE e UFSC

Coordenao de Design GrcoAndr Rodrigues/UFSC

Design InstrucionalGustavo Pereira Mateus/UFSC

Web MasterRafaela Lunardi Comarella/UFSC

Web DesignBeatriz Wilges/UFSCMnica Nassar Machuca/UFSC

DiagramaoAndr Rodrigues/UFSCBrbara Zardo/UFSCJuliana Tonietto/UFSCNathalia Takeuchi/UFSC

RevisoJlio Csar Ramos/UFSC

Projeto Grcoe-Tec/MEC

Instituto Federal do Esprito SantoEste Caderno foi elaborado em parceria entre o Instituto Federal do Esprito Santo e a Universidade Federal de Santa Catarina para o Sistema Escola Tcnica Aberta do Brasil e-Tec Brasil.

S586b Silva, Vanderson Jos Ildefonso

Banco de dados : Curso Tcnico de Informtica / Vanderson Jos Ildefonso Silva. Colatina: Ifes/CEAD, 2011. 176 p. : il. ISBN: 978-85-62934-73-5 1. Banco de dados. 2. Informtica. I. Instituto Federal do Esprito Santo. II. Ttulo. CDD: 005.74


e-Tec Brasil33

Apresentao e-Tec Brasil

Prezado estudante,

Bem-vindo ao e-Tec Brasil!

Voc faz parte de uma rede nacional pblica de ensino, a Escola Tcnica

Aberta do Brasil, instituda pelo Decreto n 6.301, de 12 de dezembro 2007,

com o objetivo de democratizar o acesso ao ensino tcnico pblico, na mo-

dalidade a distncia. O programa resultado de uma parceria entre o Minis-

trio da Educao, por meio das Secretarias de Educao a Distancia (SEED)

e de Educao Prossional e Tecnolgica (SETEC), as universidades e escolas

tcnicas estaduais e federais.

A educao a distncia no nosso pas, de dimenses continentais e grande

diversidade regional e cultural, longe de distanciar, aproxima as pessoas ao

garantir acesso educao de qualidade, e promover o fortalecimento da

formao de jovens moradores de regies distantes, geogracamente ou

economicamente, dos grandes centros.

O e-Tec Brasil leva os cursos tcnicos a locais distantes das instituies de en-

sino e para a periferia das grandes cidades, incentivando os jovens a concluir

o ensino mdio. Os cursos so ofertados pelas instituies pblicas de ensino

e o atendimento ao estudante realizado em escolas-polo integrantes das

redes pblicas municipais e estaduais.

O Ministrio da Educao, as instituies pblicas de ensino tcnico, seus

servidores tcnicos e professores acreditam que uma educao prossional

qualicada integradora do ensino mdio e educao tcnica, capaz de

promover o cidado com capacidades para produzir, mas tambm com auto-

nomia diante das diferentes dimenses da realidade: cultural, social, familiar,

esportiva, poltica e tica.

Ns acreditamos em voc!

Desejamos sucesso na sua formao prossional!

Ministrio da Educao

Janeiro de 2010

Nosso contato

[email protected]


e-Tec Brasil5

Indicao de cones

Os cones so elementos grcos utilizados para ampliar as formas de

linguagem e facilitar a organizao e a leitura hipertextual.

Ateno: indica pontos de maior relevncia no texto.

Saiba mais: oferece novas informaes que enriquecem o assunto ou curiosidades e notcias recentes relacionadas ao

tema estudado.

Glossrio: indica a denio de um termo, palavra ou expresso utilizada no texto.

Mdias integradas: sempre que se desejar que os estudantes desenvolvam atividades empregando diferentes mdias: vdeos,

lmes, jornais, ambiente AVEA e outras.

Atividades de aprendizagem: apresenta atividades em diferentes nveis de aprendizagem para que o estudante possa

realiz-las e conferir o seu domnio do tema estudado.


e-Tec Brasil7

Palavra do professor-autor 9

Apresentao da disciplina 11

Projeto instrucional 13

Aula 1 Conceitos de Bancos de Dados 171.1 Denio 17

1.2 Objetivos de Banco de Dados 21

1.3 Usurios de Bancos de Dados 22

1.4 Modelos de Bancos de Dados 23

Aula 2 Modelagem de Dados: Modelo Entidade-Relacionamento 35

2.1 Cardinalidade de relacionamentos 37

2.2 Exemplos do modelo entidade-relacionamento 42

2.3 Generalizao/especializao de entidades 47

2.4 Entidades fracas 48

Aula 3 Modelagem de Dados: Modelo Relacional Normalizado 51

3.1 Chave primria 51

3.3 Exemplos de diagrama do MRN 57

3.4 Formas normais 60

Aula 4 Criao de Banco de Dados 694.1 Linguagem SQL 69

4.2 MySQL 71

4.3 Como criar um Banco de Dados 72

4.4 Criao de tabelas 74

4.5 Insero de registro em tabela 88

4.6 Alterao de registro em tabela 94

4.7 Excluso de registro em tabela 98

Sumrio


Aula 5 Consultas SQL 1035.1 Consultas bsicas 103

5.2 Consultas com clusula ORDER BY 105

5.3 Consultas com clusula WHERE 109

5.4 Consultas com funes e agrupamento 112

5.5 Consultas com mais de uma tabela 119

5.6 Outras consultas 124

Aula 6 Segurana da Informao 1276.1 Preparando o terreno 127

6.2 Alterando a senha do administrador do BD 128

6.3 Criando novas contas de usurio e denindo seus privilgios de segurana 130

6.4 Criando vises 136

Aula 7 Procedimentos Armazenados e Gatilhos 1417.1 Importncia de rotinas armazenadas 141

7.2 Procedimentos armazenados 142

Aula 8 Criao de ndices 1598.1 ndices 159

8.2 Criando um ndice durante a criao da tabela 161

8.3 Criando um ndice para tabela preexistente 163

Aula 9 Transaes em Banco de Dados 1659.1 Conceito de transao 165

9.2 Transaes no MySQL 170

Referncias 174

Currculo do professor-autor 175

Banco de Dadose-Tec Brasil 8


e-Tec Brasil9

Palavra do professor-autor

Ol caro estudante!

A tecnologia de Bancos de Dados quase onipresente em sistemas de infor-

mao. Pode ser encontrada em sites de comrcio eletrnico e sistemas de georreferenciamento. Muitas vezes utilizamos um Banco de Dados indireta-

mente e sem perceber. Por exemplo, sempre que fazemos uso da mquina de

busca do Google ou mesmo do Google Maps, acessamos um Banco de Dados.

Banco de dados uma fascinante rea de estudo. impossvel no se deixar

contagiar por sua elegncia e potencial tecnolgico. Porm, devo lembr-lo

que cada novo conhecimento adquirido encontra-se intimamente associa-

do ao abordado anteriormente. Portanto, no acumule conceitos e tcnicas

sem a devida cota de estudo dirio. O fraco entendimento de um contedo

pode resultar em grave diculdade de assimilao do seguinte. Organize o

seu estudo e mantenha-se atualizado com o desenvolvimento das aulas.

Assim como nas disciplinas de programao de computadores, em Banco

de Dados somente possvel aprender fazendo. Logo, importante que

se esforce na resoluo dos exerccios propostos e at se aventure em voos

solo. Estou certo de que inmeras ideias e possibilidades aparecero em sua

mente medida que for se aprofundando nos conceitos e tcnicas apresen-

tados. Vale a pena dar vazo sua criatividade. Talvez trabalhe em alguma

atividade que possa se beneciar com a criao de um Banco de Dados

adaptado sua realidade, ou talvez de uma empresa de um conhecido.

Apenas ler este material sem praticar os contedos no trar os resultados

que eu e voc esperamos.

Bons estudos!

Vanderson Jos Ildefonso Silva


e-Tec Brasil11

Apresentao da disciplina

Nesta disciplina voc ser apresentado aos conceitos bsicos de Bancos de Da-

dos e aprender a empreg-los como uma importante ferramenta para a ma-

nuteno de dados em sistemas de informao (persistncia de dados). Com a

crescente utilizao da Tecnologia da Informao pelas organizaes e pessoas

fsicas, os Bancos de Dados converteram-se em uma importante tecnologia.

Embora j seja uma tecnologia madura, com dcadas de existncia, ainda

demonstra grande valor como suporte a tecnologias mais recentes, como de

Data Warehouse (Armazm de Dados) e Data Mining (Minerao de Dados), e imprescindvel para grande parcela dos prossionais da rea de informtica.

Este material tem como objetivo orient-lo no estudo da disciplina Banco

de Dados, por meio de dicas e sugestes, com destaque para os aspectos

mais importantes. Aqui voc encontrar conceitos com os quais trabalhare-

mos ao longo do curso, o que no dispensa, claro, a utilizao de outros

livros tambm usados para a confeco deste trabalho, que trazem diversos

exemplos adicionais e aprofundamento maior em vrios aspectos. impor-

tante esclarecer que esses outros livros foram consultados para complemen-

tar alguns conceitos, a m de facilitar o seu entendimento, e constam nas

referncias deste material.

Bons Estudos!

Prof. Vanderson Jos Ildefonso Silva


e-Tec Brasil13

Disciplina: Banco de Dados (carga horria: 90 horas).

Ementa: Arquitetura de Sistemas Gerenciadores de Banco de Dados. Mode-lo de Dados. Integridade Referencial. Linguagens de Denio, Manipulao

e Controle de Dados. Segurana e Integridade. Controle de Transaes.

AULA OBJETIVOS DE APRENDIZAGEM MATERIAISCARGA

HORRIA(horas)

1. Conceitos de Banco de Dados

- Denir conceitos bsicos de Bancos de Dados.

- Identicar problemas relativos tec-nologia da informao que induziram ao desenvolvimento de Sistemas Gerenciadores de Banco de Dados (SGBDs).

- Enumerar os principais objetivos da tecnologia de Banco de Dados.

- Classicar os diferentes tipos de usurios de Banco de Dados.

Este caderno e outros livros indicados nas referncias.

10

2. Modelagem de Dados: MER

- Denir entidades e seus atributos. - Estabelecer relacionamentos entre

entidades. - Ajustar a cardinalidade dos relacio-

namentos. - Interpretar Modelos de Entidade e

Relacionamento (MER). - Modelar conceitualmente sistemas de

informao.

Este caderno e outros livros indicados nas referncias.

10

3. Modelagem de Dados: MRN

- Interpretar um Modelo Relacional Normalizado (MRN).

- Implementar um MRN a partir de um Modelo Entidade Relacionamento (MER) preexistente.

- Denir chaves primrias e estrangeiras para uma entidade.

- Efetuar a normalizao do modelo de dados, obedecendo s trs primeiras Formas Normais (FN).

DB Designer. 10

(continua)

Projeto instrucional



HORRIA(horas)

4. Criao de um Banco de Dados

- Utilizar o Data Denition Langua-ge (DDL) da SQL.

- Denir chaves primrias e chaves estrangeiras.

- Estabelecer relacionamentos entre tabelas.

- Alterar tabelas. - Excluir tabelas. - Inserir novos registros em tabelas. - Alterar registros. - Excluir registros de tabelas.

SGBD MySQL. 10

5. Consultas SQL

- Recuperar dados armazenados em tabelas atravs de consultas SQL.

- Denir colunas cujos dados sero visualizados na consulta.

- Consultar simultaneamente informa-es armazenadas em vrias tabelas relacionadas.

- Estabelecer ltros que separem os registros relevantes para o contexto da consulta daqueles que no o so.

- Utilizar funes especiais disponveis.

SGBD MySQL. 10

6. Segurana da Informao

- Alterar a senha do Administrador do Banco de Dados.

- Criar novas contas de usurio. - Denir privilgios de segurana dife-

renciados para cada conta de usurio. - Criar vises diferentes para o mesmo

Banco de Dados. - Utilizar as vises para denir melhor

a segurana das informaes arma-zenadas.

SGBD MySQL. 10

(continua)




HORRIA(horas)

7. Procedimentos Armazenados e Gatilhos

- Diferenciar um procedimento armaze-nado de um gatilho.

- Identicar situaes em que justi-cada a utilizao de procedimentos armazenados e gatilhos.

- Criar procedimentos armazenados. - Executar procedimentos armazenados. - Apagar procedimentos armazenados. - Efetuar passagens de parmetros em

procedimentos armazenados. - Criar gatilhos que disparem antes ou

aps um evento.

SGBD MySQL. 10

8. Criao de ndices

- Denir o conceito de ndice no contexto da tecnologia de Banco de Dados.

- Descrever a importncia dos ndices para os sistemas de Bancos de Dados.

- Criar ndices durante a criao das tabelas.

- Criar novos ndices alterando tabelas existentes.

SGBD MySQL. 10

9. Transaes em Banco de Dados.

- Conceituar transao no contexto dos sistemas de Banco de Dados.

- Implementar transaes no SGBD MySQL atravs de comandos SQL.

SGBD MySQL. 10

(concluso)

e-Tec Brasil15


e-Tec Brasil

Aula 1 Conceitos de Bancos de Dados

Objetivos

Denir conceitos bsicos de Bancos de Dados.

Identicar os problemas relativos tecnologia da informao que

induziram ao desenvolvimento de Sistemas Gerenciadores de Ban-

co de Dados (SGBDs).

Enumerar os principais objetivos da tecnologia de Banco de Dados.

Classicar os diferentes tipos de usurios de Banco de Dados.

1.1 DenioA humanidade sempre se dedicou produo de signos. Um signo ou sm-

bolo corresponde a qualquer coisa que represente algo para algum. Da

mesma forma que um mapa representa um dado terreno, um braso pode

representar o time de futebol. Uma cano pode faz-lo lembrar uma fase

especca de sua vida ou uma paixo. Tudo isso e muitos outros so signos.

Nesse sentido, o que para voc nada signica pode representar algo para

outros. Portanto, todo signo subjetivo e pode ser de difcil interpretao.

At hoje, pesquisadores debruam-se sobre pinturas feitas em cavernas h

pelo menos 15.000 anos e debatem sobre seus signicados. Apesar de repre-

sentarem animais ou cenas de caadas na pr-histria, escapa-nos sua moti-

vao. Faziam parte de algum ritual religioso, eram o registro de uma impor-

tante atividade social ou apenas a expresso da subjetividade de seu pintor?

A oralidade primria precede a inveno da escrita e se caracteriza pelo uso

da palavra falada como a nica forma de gerir a memria social das comu-

nidades. A cultura narrativa valorizava as parbolas, fbulas e mitos como

veculos naturais do conhecimento que se pretendia preservar de uma ge-

rao para outra. Histrias e imagens eram associadas a algum fato que se

buscava memorizar.

e-Tec BrasilAula 1 Conceitos de Bancos de Dados 17


O mito codica, sob forma de narrativa, algumas das representaes

que parecem essenciais aos membros de uma sociedade. Dado o funcio-

namento da memria humana, e na ausncia de tcnicas de xao da

informao como a escrita [...], as representaes que tm mais chances

de sobreviver em um ambiente composto quase que unicamente por

memrias humanas so aquelas que esto codicadas em narrativas dra-

mticas, agradveis de serem ouvidas, trazendo uma forte carga emotiva

e acompanhadas de msicas e rituais diversos. (LVY, 1993, p. 82).

Ao desenvolverem a escrita, as primeiras civilizaes melhoraram a utilidade

dos smbolos. Anal, o surgimento do Estado trouxe consigo a inevitvel co-

brana de impostos. Com a escrita, a contabilidade veio a possuir meios obje-

tivos para registrar tributos devidos e valores pagos. Desde ento, o monarca

passou a contar com registros precisos de seu tesouro e dos sditos devedores.

Com o capitalismo e o consequente progresso tcnico, a administrao das or-

ganizaes tornou-se mais complexa, demandando, por exemplo, maior con-

trole da atividade produtiva: do gerenciamento de estoques, recursos humanos

e nanceiros. O grande volume de informaes registradas em papel dicultava

consideravelmente seu gerenciamento e atualizao. Ento, com os primeiros

computadores migraram-se essas informaes para dispositivos eletrnicos.

De incio, a migrao foi implementada de modo pouco organizado, usan-

do-se de sistemas de arquivos tradicionais. Cada aplicao do sistema de in-

formaes era tratada isoladamente pela equipe de desenvolvedores. Ento,

cada aplicao tinha seus prprios arquivos e a redundncia de informaes

era normal. Uma aplicao para o controle da frequncia dos funcionrios,

por exemplo, tinha seu prprio arquivo com dados dos empregados em ativi-

dade. Esse arquivo podia no ser compartilhado com a aplicao de controle

das frias desses mesmos empregados.

Por isso, dados como nome, nmero de matrcula e departamento de tra-

balho podiam facilmente estar duplicados nos diferentes arquivos. Com a

multiplicao de aplicaes e, assim, de arquivos com redundncia de da-

dos, o risco de inconsistncias de dados entre eles crescia exponencialmente.

Considere, por exemplo, uma funcionria que se casou e mudou de nome.

Uma eventual falha humana podia levar a uma situao em que seu nome

fosse alterado apenas em alguns desses arquivos, mas no em todos eles.



Os primeiros Bancos de Dados surgiram no mercado como uma resposta a esses problemas. Um Sistema de Gerenciamento de Banco de Dados (SGBD) consiste em um conjunto de arquivos estruturados e de programas

que respondem pelo acesso e manipulao de tais arquivos. Diferente dos

sistemas de arquivos tradicionais, o Banco de Dados (BD) favorece o inter-re-

lacionamento dos arquivos; portanto, pode ser denido como uma coleo

de dados inter-relacionados e um conjunto de programas para acess-los

(KORTH; SILBERSCHATZ; SUDARSHAN, 2006, p. 1).

Simplicando, pode-se denir SGBD como um software desenvolvido para gerenciar grandes volumes de informaes. O objetivo principal reside em su-

perar problemas comuns aos sistemas de arquivos tradicionais. Tais problemas

ou desvantagens (KORTH; SILBERSCHATZ; SUDARSHAN, 2006) so:

(1) Redundncia e inconsistncia de dados. Equipes de desenvolvedo-res criam diferentes aplicaes/sistemas ao longo do tempo. De maneira

anloga, em uma mesma organizao, diferentes linguagens de progra-

mao, por exemplo, podem ser usadas no desenvolvimento de diversos

sistemas de informaes. Logo, dados distintos podem estar duplicados.

Tal redundncia conduz a altos custos de armazenamento e diculdade

de atualizao das informaes.

(2) Diculdade no acesso aos dados. Dados espalhados em arquivos isola-dos no apresentam as facilidades de acesso e processamento das infor-

maes dos BD. H pouca exibilidade em relao a demandas que no

tenham sido antecipadas quando o sistema foi projetado. Por exemplo,

uma vez desenvolvido o sistema, caso haja a necessidade de gerar relat-

rios com os nomes de todos os empregados com idade igual ou superior

a 40 anos, a ausncia de uma aplicao especca para esse objetivo traz

srios inconvenientes. Isso porque quando os usurios do sistema solicita-

rem esse novo aplicativo, sua implementao demandar tempo e recur-

sos dos programadores para a gerao de um relatrio muito especco

que raramente ser usado. Outra soluo seria conseguir a impresso de

uma listagem com todos os empregados existentes para posterior extra-

o manual da informao desejada. Essa soluo tambm no satisfa-

tria, pois o trabalho manual est sujeito a erros humanos.

(3) Isolamento de dados. Dados espalhados em diferentes arquivos e for-matos dicultam a criao de novos aplicativos para sua recuperao.

Banco de Dados (BD) um conjunto de dados inte-grados reunidos com o intuito de suportar o funcionamento de sistemas de informao.

Sistema Gerenciador de Banco de Dados (SGBD) um soft are de carter geral para a manipulao eciente de grandes colees de informaes estruturadas e armazenadas de uma forma consistente e integrada.



(4) Anomalias de acesso concorrente. Inmeros sistemas de informao permitem que mltiplos usurios acessem e atualizem dados simultane-

amente. A inexistncia de sosticados mecanismos de gerenciamento de

atualizaes concorrentes pode resultar em dados inconsistentes. Consi-

dere o exemplo de uma conta bancria conjunta com saldo de R$ 600,00,

caso dois clientes saquem dinheiro dessa mesma conta simultaneamente.

Suponha que o cliente A saque R$ 50,00 ao mesmo tempo em que o

cliente B saca R$ 100,00. Ento, o programa aplicativo l o saldo da conta

de R$ 600,00. Em seguida, o valor do saque diminudo do saldo lido,

gerando assim o saldo atualizado. Ento, para o aplicativo de A, temos

(600 - 50)=550, enquanto para o aplicativo de B, temos (600 - 100)=500.

Supondo que o aplicativo de A atualize o arquivo antes do aplicativo de

B, o saldo da conta registrar R$ 500,00. Anal, no arquivo, os dados do

aplicativo de B sobreporo os dados do aplicativo de A. Repare que essa

informao est errada inconsistente pois havia R$ 600,00 e foram

retirados R$ 150,00. Portanto, o saldo deveria ser de R$ 450,00.

(5) Problemas de segurana. O acesso a determinados dados deve ser restrito para alguns usurios do sistema de informaes. Os dados relati-

vos ao contracheque dos empregados no podem ser disponibilizados a

todos os usurios indistintamente, mas apenas aos usurios responsveis

pela folha de pagamento. Entretanto, quando programas aplicativos so

instalados de maneira arbitrria, ou sem acompanhamento e controle

necessrios, no h como assegurar tais restries de segurana.

(6) Problemas de integridade. Restries de consistncia so impostas aos dados armazenados. Elas so normalmente regras de negcio. O saldo

de uma conta bancria, por exemplo, no deve cair abaixo de um valor

predeterminado. Restries de consistncia como essa, nos sistemas de

arquivos tradicionais, so incorporadas aos cdigos dos programas apli-

cativos. Um problema grave ocorre quando a adio de novas restries

implica a necessidade de alterao de vrios programas aplicativos. Sem-

pre h o risco de esquecimento de algum desses programas, ameaando

a integridade dos dados.

Essas seis diculdades levaram ao desenvolvimento dos SGBD. Ao longo do

curso veremos algumas das estratgias criativamente engendradas para a

soluo das desvantagens dos sistemas de arquivos tradicionais.

A tecnologia de BD trouxe maior produtividade para o

desenvolvimento de sistemas de informao. Anal, nos sistemas tradicionais de arquivos, quando

implementadas, as caractersticas inauguradas com o surgimento

dos BD eram incorporadas s aplicaes isoladamente. Logo, a

complexidade do desenvolvimento de sistemas de informao

aumentava consideravelmente, resultando em:

(1) Prazos maiores para a concluso dos sistemas de

informao e, consequentemente, elevao dos custos envolvidos no

desenvolvimento.(2) Obrigao de as equipes desenvolvedoras (analistas e

programadores) dedicarem mais tempo a programas que no

tratavam diretamente do sistema de informao em questo, mas sim de funcionalidades

que forneceriam suporte a esse mesmo sistema.

(3) Ocorrncia de problemas no previstos, favorecidos pela ausncia de padronizao das

funcionalidades de suporte.



Os sistemas de BD atualmente existentes no mercado aliviam as equipes

desenvolvedoras de preocupaes do que no esteja relacionado aos seus

objetivos, permitindo assim a codicao de sistemas de informao mais

robustos e conveis.

Crie pelo menos dois possveis exemplos para as desvantagens/problemas

trazidos pelo uso de sistemas tradicionais de arquivos.

1.2 Objetivos de Banco de DadosSistemas Gerenciadores de Bancos de Dados (SGBD) tm o objetivo de pro-

ver mecanismos adequados ao armazenamento e acesso seguro e eciente

de dados em Sistemas de Informao (SI). Mais detalhadamente, os BD tm

por objetivo:

fornecer interfaces amigveis e padronizadas para o armazenamento e acesso aos dados, poupando os usurios dos detalhes da implemen-

tao interna;

assegurar a privacidade dos dados atravs de medidas de segurana como: atribuio de permisses de acesso; criao de vises; e forne-

cimento de senhas de acesso, evitando o acesso a dados por pessoas

no autorizadas;

administrar acessos concorrentes aos dados, permitindo que diferentes usurios compartilhem simultaneamente a mesma coleo de dados;

prover mecanismos para a recuperao de dados em caso de eventu-ais paradas e falhas do sistema, as quais podem ocorrer por causa de

erros de software, interrupo no suprimento de energia, defeito de hardware, queda na comunicao com o servidor, etc. Qualquer falha pode resultar na perda de dados processados pelo SGBD no momen-

to da parada. A perda desses dados pode levar o BD a uma condio

de inconsistncia que, se no evitada, torna a tecnologia pouco con-

vel. Portanto, durante uma venda, o estoque deve ser atualizado

e, se uma falha ocorre aps a venda, mas antes da atualizao do

estoque, o BD car inconsistente. Anal, a quantidade em estoque

no ser real para o produto em questo.

Um SGBD foi denido como uma coleo de dados inter-relacionados e um

conjunto de programas para acess-los (KORTH; SILBERSCHATZ; SUDARSHAN,

2006, p. 1). Entretanto, os sistemas tradicionais de arquivo que precederam a

tecnologia de BD falhavam exatamente nesses dois aspectos: (I) manter dados



inter-relacionados e (II) fornecer um conjunto de programas voltados manu-

teno de tais dados.

a) Comente as vantagens que a existncia de dados inter-relacionados traz aos sistemas de informao.

b) Uma das principais funcionalidades de um Banco de Dados a chamada restrio de consistncias. Explique os riscos que a ausncia dessa fun-cionalidade trazia aos sistemas tradicionais de arquivos.

1.3 Usurios de Bancos de DadosBasicamente so quatro os tipos de usurios de sistemas de Bancos de Dados:

Usurios leigos: prossionais de outras reas cujos conhecimentos de informtica se restringem ao bsico e que interagem com o BD

por meio de aplicaes escritas pelos programadores de aplicaes.

As aplicaes fazem a intermediao entre esses usurios e o BD, pois

atravs de telas ou pginas tal usurio acessa seus dados.

Usurios avanados: usurios com maior nvel de independncia em relao aos programadores de aplicaes: interagem com os Ban-

cos de Dados por meio de interfaces disponveis no ambiente e escre-

vem consultas para relatrios com certa facilidade, sem a necessidade

de um programador escrever uma nova aplicao.

Programadores de aplicaes: prossionais formados em compu-tao que constroem aplicaes/programas de computador com in-

terfaces intuitivas e amigveis (formulrios e relatrios acessando o

BD) para os usurios leigos.

Analistas de sistemas: prossionais responsveis por traduzir as necessidades dos usurios leigos e avanados em uma especicao

racional de um sistema de informao. Denem o projeto do sistema

de informao que especica as aplicaes e a estrutura do Banco

de Dados e que ser rigorosamente seguido pelos programadores,

desenvolvendo programas que acessem o Banco de Dados;

Administrador de BD (Database Administrator DBA): usurio mais especializado responsvel por administrar as bases de dados;

ocupa-se com:



(1) a atribuio de permisses de acesso adequadas a cada usurio;

(2) a gerao de cpias de segurana (backups) como contingncia contra falhas;

(3) o monitoramento do ambiente como forma de assegurar a disponibilida-de do Banco de Dados pelo maior tempo possvel;

(4) a otimizao de recursos de infraestrutura (disco, memria, processador) para assegurar o desempenho satisfatrio do BD;

(5) o suporte equipe de desenvolvimento (analistas e programadores).

Em resumo, o DBA deve ser o prossional que zela pela implementao adequada do BD, assegurando um funcionamento eciente que prime pelo

desempenho, escalabilidade, exibilidade e conabilidade.

1.4 Modelos de Bancos de DadosOs modelos de BD denem a forma como os dados esto organizados inter-

namente. Em ordem cronolgica, so assim classicados: em redes, hierr-

quicos, relacionais, objeto-relacionais e orientados a objetos.

1.4.1 Modelo em redeUm BD em rede uma coleo de registros concatenados uns aos outros

por meio de ligaes. Semelhantes ao conceito de ponteiros, elas so

entendidas como endereos de memria que apontam a localizao

de um registro associado.

Na Figura 1.1, h um modelo em rede com dois diferentes tipos de re-

gistros: cliente e conta. O registro de cliente apresenta trs atributos:

nome, cidade e sexo. Por sua vez, o registro de conta possui apenas dois

atributos: nmero e saldo.

Algumas organizaes preferem manter um prossional que acumule as funes do analista de sistemas e do programador de aplicaes. Isso lhes permite reduzir custos trabalhistas e evitar rudos de comunicao que comprometam a ecincia dos sistemas de informaes. Anal, sempre h a possibilidade de que o analista de sistemas no seja plenamente entendido pelo programador de aplicaes, gerando um sistema de informao muito diferente do que o usurio requisitara inicialmente. Assim, as aplicaes teriam de ser reescritas, tornando o processo mais caro e menos eciente.



NomeReinaldo Antunes

CidadeVitria

Nmero1045

Saldo945,60

SexoM

Nmero1385

Saldo107,00

Nmero1447

Saldo93,41

Nmero1500

Saldo1.266,00

NomeMarcela Souto

CidadeVitria

SexoF

NomeAndr Marques

CidadeColatina

SexoM

Figura 1.1: Exemplo de Banco de Dados modelo em redeFonte: Elaborada pelo autor

Ligaes associam registros de clientes aos de contas. Ento, sabemos que

o cliente Reinaldo Antunes tem uma conta de nmero 1045 e saldo de

R$ 945,60; e Marcela Souto e Andr Marques possuem uma conta conjun-

ta de nmero 1447, com R$ 93,41. Porm, Marcela tem ainda outra conta

nmero 1358 e saldo R$ 107,00; e Andr Marques tambm tem outra de

nmero 1500 com R$ 1.266,00.

Um conjunto de diferentes tipos de registros relacionados entre si por meio

de um emaranhado de ligaes forma uma estrutura de dados semelhante

a uma rede.

Seguindo o modelo da Figura 1.1, elabore um exemplo de BD no modelo em

rede envolvendo os seguintes dados: Funcionrio {matrcula, nome, salrio,

funo} e Filial {cidade, bairro, telefone}. O objetivo dessa coleo de dados

armazenar informaes sobre todos os funcionrios de um supermercado

e de suas liais de diversas localidades. Por meio dessa coleo deve ser pos-

svel determinar as liais em que cada funcionrio est lotado.

Esse exemplo dever apresentar pelo menos duas liais com um mnimo de

cinco funcionrios por elas distribudos. Use sua criatividade para dar nomes

aos funcionrios e preencher os outros dados sobre eles e as liais nas tabelas.

Lembre-se de que um funcionrio somente poder estar lotado em uma lial.

1.4.2 Modelo hierrquicoUma evoluo do modelo em rede, os BD hierrquicos so uma coleo de

registros relacionados uns aos outros por meio de ligaes semelhantes a pon-

teiros. Porm, se diferenciam de seu antecessor na organizao seus registros.

Enquanto no modelo em rede os registros so distribudos conforme a lgica

de grafos arbitrrios, no hierrquico eles so dispostos como uma coleo de

rvores. A Figura 1.1 caria ento traduzida como mostra a Figura 1.2 a seguir.



rvores binrias so um dos temas tratados na disciplina referente Progra-

mao em Estrutura de Dados.

Nmero1045

Saldo945,60

NomeReinaldo Antunes

CidadeVitria

SexoM

Nmero1385

Saldo107,00

Nmero1447

Saldo93,41

Nmero1447

Saldo93,41

Nmero1500

Saldo1.266,00

NomeMarcela Souto

CidadeVitria

SexoF

NomeAndr Marques

CidadeColatina

SexoM

Figura 1.2: Exemplo de Banco de Dados modelo hierrquicoFonte: Elaborada pelo autor

Um registro isolado no topo da Figura 1.2 encontra-se associado a todos os

registros de Clientes. Esse o registro do tipo raiz, o ponto de partida da

rvore de registros. Ele est no nvel mais elevado da estrutura de dados e

pode ser ligado a nenhum, um ou vrios registros no nvel inferior. Em nosso

exemplo, os registros conectados ao registro raiz so sempre registros de

Clientes que, por sua vez, esto interligados a registros de Contas no nvel

imediatamente abaixo.

Generalizando, existem camadas, nveis ou hierarquias em uma rvore. Os re-

gistros de um nvel sempre se associam aos do imediatamente inferior e nunca

aos do mesmo nvel. No primeiro nvel da rvore h sempre um nico registro,

a Raiz, que representa o ponto de partida para acessar os demais registros.

Cada nvel da rvore comporta apenas um tipo de registro. No exemplo, o nvel

abaixo da raiz comporta registros do tipo Cliente; e o seguinte, do tipo Conta.

Ainda poderiam existir outros nveis se houvesse registros de outros tipos.

Na rvore, um registro de nvel K pode estar associado a, no mximo, um

registro do nvel imediatamente acima (K 1). Contudo, um registro de nvel

superior pode estar associado a mais de um registro do nvel imediatamente

abaixo. Note que o registro da cliente Marcela Souto liga-se a dois outros

registros de conta, mas a conta de nmero 1447 teve de ser duplicada para

que a regra fosse preservada, replicando o registro para que Andr Marques

compartilhasse essa conta com Marcela Souto, j que um registro de conta

no pode se associar simultaneamente a dois de clientes.



A estrutura hierrquica do BD dene o caminho de acesso a registros. A

busca ao registro sempre comea pela raiz at o nvel correspondente ao

tipo procurado.

Converta o exemplo de BD no modelo em rede da atividade anterior em um

exemplo equivalente no modelo hierrquico.

1.4.3 Modelo relacionalNa dcada de 1970, o modelo relacional de BD estabeleceu-se como o pre-

ferencial para aplicaes comerciais. Na dcada seguinte j era o padro no

mercado corporativo.

No modelo relacional, os registros so organizados em tabelas e cada linha

representa uma relao entre os valores armazenados em diferentes colunas.

Assim, na tabela de CLIENTE (Figura 1.3), seguindo o exemplo desenvolvido

at aqui, temos cada registro subdividido em trs colunas: NOME, CIDADE

e SEXO. Toda linha existente na tabela de CLIENTES representa um conjunto

de valores inter-relacionados. Ou seja, cada linha da tabela armazena os da-

dos de um cliente especco organizados em diferentes colunas.

CLIENTE

Reinaldo Antunes Vitria M

Marcela Souto Colatina F

Andr Marques Colatina M

NOME CIDADE SEXO

Figura 1.3: Exemplo de tabela CLIENTE em um modelo relacional de Banco de DadosFonte: Elaborada pelo autor

Assim, sabemos que o cliente Reinaldo Antunes mora em Vitria e

do sexo masculino (M), pois esses dados esto na mesma linha da tabe-

la. Tambm sabemos que os clientes Marcela Souto e Andr Marques

residem na cidade de Colatina e so, respectivamente, do sexo feminino

e masculino.

O modelo relacional de BD apresenta esse nome em razo da relao exis-

tente entre as colunas de uma mesma tabela, e tambm da possibilidade de

estabelecer relacionamentos entre diferentes tabelas. Para que o exemplo

de clientes e contas que completo, precisamos relacionar registros de uma

comum encontrar na literatura as denominaes Pai e Filho para

distinguir a relao existente entre registros de diferentes

camadas da rvore.Registros de uma camada K geralmente so designados

Filhos dos registros de uma camada (K 1). Em

contrapartida, os dessa camada (K 1) so considerados Pais

dos registros da camada K que a eles estiverem conectados. Portanto, em nosso exemplo

da Figura 1.2, os registros de Conta so Filhos dos registros de

Clientes.

Em 1970, Edgar Frank Codd, um pesquisador da IBM, props o

modelo relacional de BD tratado aqui. Esse novo modelo trouxe

uma importante contribuio ao dissociar a estrutura

lgica do BD dos mtodos de armazenamento fsico dos

dados algo impossvel para os modelos em rede e hierrquico.

Ao faz-lo, tornou os SGBD mais amigveis (fceis de utilizar).



tabela com os de outra. Caso contrrio, no teramos como saber com preci-

so a quais clientes cada conta pertence. Porm, as associaes entre regis-

tros no so implementadas mediante ponteiros. Na verdade, o modelo

relacional emprega a duplicao de uma ou mais colunas em uma tabela

distinta daquela a que pertencem originalmente.

Ponteiros tema da disciplina de Programao em Estrutura de Dados.

Na Figura 1.4 temos duas tabelas FILME e GENERO relacionadas entre si

atravs da coluna COD_GENERO. Essa coluna original da tabela GENERO,

mas foi duplicada na tabela FILME para estabelecer uma associao lgica

entre os registros das duas tabelas. Logo, sabemos que o lme Star Trek classicado como co cientca, pois apresenta o valor FIC em sua

coluna COD_GENERO, e o mesmo valor na coluna correspondente da tabela

GENERO est associada descrio Fico Cientca.

FILME

1099 El Cid 1961

1100 Star Wars 1977

1101

1103

Star Trek

Transformers 2

2009

2009

NUMERO TITULO ANO

DRA

FIC

FIC

FIC

COD_GENERO

GENERO

DRA Drama

FIC Fico

COD_GENERO DESCRICAO

Figura 1.4: Exemplo de relacionamento entre as tabelas FILME e GENEROFonte: Elaborada pelo autor

H quem no compreenda a necessidade de duas tabelas em situaes como

essa. Armam ser uma soluo complicada e perguntam: A coluna descrio

no poderia simplesmente existir apenas na tabela FILME para no haver a

tabela GENERO e nem as colunas duplicadas de COD_GENERO? A princpio

essa parece uma soluo mais simples e, portanto, melhor, mas a Figura 1.5

procura exemplicar sua vulnerabilidade.



FILME

1099 El Cid 1961

1100 Star Wars 1977

1101

1103

Star Trek

Transformers 2

2009

2009

NUMERO TITULO ANO

Drama

Fico - Cientca

Fico

Fico - Cientca

DESCRICAO_GENERO

Figura 1.5: Vulnerabilidade da fuso equivocada das tabelas FILME e GENEROFonte: Elaborada pelo autor

Os valores da coluna DESCRICAO_GENERO podem se repetir em diferentes

registros (linhas). Na tabela da Figura 1.5 h trs lmes do gnero co

cientca. Contudo, cada lme apresenta valores diferenciados para essa co-

luna. No lme Transformers 2 no h hfen, mas em Star Wars esse ca-ractere est presente. J no lme Star Trek, no somente houve a omisso do hfen como tambm a supresso da palavra Cientca. Algo assim

perfeitamente possvel de acontecer. Usurios diferentes podem ter cadas-

trado cada um desses lmes, ou ainda um mesmo usurio em diferentes

ocasies. Acontece que, em um momento, esse usurio encontrava-se um

tanto cansado e registrou apenas co. Mais tarde, por um erro de digi-

tao, passou a usar o hfen.

A possibilidade de ocorrer tal situao demonstra a vulnerabilidade da so-

luo baseada em uma nica tabela. Caso uma consulta seja efetuada, o

resultado pode diferir da realidade que a base de dados deveria espelhar.

Suponha que um usurio submeta uma consulta ao BD usando como critrio

de busca a coluna DESCRICAO_GENERO com o valor Fico Cientca. O

resultado da consulta no incluir os registros de Star Trek e Star Wars e ele pensar que existe apenas um lme desse gnero: Transformers 2.

Ao tratarmos do conceito de integridade referencial, a soluo inicial (Figura

1.5) a mais indicada para evitar tais problemas. Ocorre que a tecnologia

de BD relacionais possui recursos sucientes para assegurar que a coluna

COD_GENERO da tabela FILME apresente somente valores j existentes na

coluna COD_GENERO da tabela GENERO. Logo, nenhum usurio poder

cadastrar um novo lme ou alterar um velho lme com um cdigo inexis-

tente na tabela de origem (GENERO). O SGBD relacional simplesmente no

permitir: no se consegue usar um novo cdigo de gnero para um Filme



sem antes cri-lo na tabela de GENERO. No mximo, um usurio descuidado

poderia lanar um cdigo errado para um lme.

Retomando o exemplo do BD para clientes e contas bancrias, a Figura 1.6

apresenta a congurao ideal para o modelo relacional. Uma terceira tabela

CONTAS_CLIENTE precisou ser criada para relacionar CLIENTE e CONTA. No

exemplo sobre FILME e GENERO, no foi necessrio, bastou replicar a coluna

COD_GENERO na tabela FILME. Porm, a duplicao da coluna ID_CLIENTE

na tabela CONTA ou a da coluna NUMERO_CONTA na tabela CLIENTE no

seria uma soluo eciente. Por isso, criamos uma tabela apresentando duas

colunas e nenhuma delas originria da nova tabela (CONTAS_CLIENTE). As

colunas ID_CLIENTE e NUMERO_CONTA so replicadas respectivamente nas

tabelas Cliente e Conta.

CLIENTE

10 Reinaldo Antunes Vitria

15 Marcela Souto Colatina

37 Andr Marques Colatina

ID_CLIENTE NOME Cidade

M

F

M

SEXO

CONTAS_CLIENTE

1045 10

1385 15

1447 15

NUMERO_CONTA ID_CLIENTE

1447 37

1500 37

CONTA

1045 945,60

1385 107,00

1447 93,41

NUMERO_CONTA SALDO

1.266,001500

Figura 1.6: Exemplo um de Banco de Dados modelo relacionalFonte: Elaborada pelo autor

Caso duplicssemos ID_CLIENTE na tabela CONTA, haveria um problema ao

cadastrar a conta nmero 1447, como mostrado na Figura 1.7. Essa conta

pertence a dois clientes, uma conta conjunta: Andr (ID_CLIENTE = 37) e

Marcela (ID_CLIENTE = 15). Como a coluna ID_CLIENTE na tabela CONTA

comporta apenas um valor por linha, teramos de cadastrar duas linhas para

a Conta de nmero 1447.



CONTAS_CLIENTE

1045 10

1385 15

1447 15

NUMERO_CONTA ID_CLIENTE

1447 37

1500 37

945,60

107,00

93,41

93,41

SALDO

1.266,00

Redundncia de dados (inecincia)

Figura 1.7: O problema de duplicar ID_CLIENTE na tabela CONTAFonte: Elaborada pelo autor

Por outro lado, se optssemos por duplicar NUMERO_CONTA na tabela CLIEN-

TE, teramos outro problema para registrar as duas contas de Marcela Souto

nmeros 1385 e 1447 (Figura 1.8), pois teramos de cadastrar duas linhas

exatamente iguais para Marcela na tabela CLIENTE, exceto pelo contedo da

coluna duplicada de NUMERO_CONTA.

CONTAS_CLIENTE

Vitria

Colatina

Colatina

ID_CLIENTE

Colatina

1045

1385

1447

NUMERO_CONTA

1447

1500Colatina

M

F

F

SEXO

M

M

10

15

15

ID_CLIENTE

37

7

Reinaldo Antunes

Marcela Souto

Marcela Souto

Andr Marques

NOME

Andr Marques

Redundncia de dados (ineficincia)

Redundncia de dados (ineficincia)

Figura 1.8: O problema de duplicar NUMERO_CONTA na tabela CONTAFonte: Elaborada pelo autor

As consequncias mais srias para essas tentativas equivocadas de relaciona-

mento das tabelas CLIENTE e CONTA seriam:

(1) Uso ineciente dos recursos de armazenamento: redundncia de dados consumiria desnecessariamente o espao disponvel no disco rgido.

(2) Maior complexidade para a manuteno das informaes: a atualizao do saldo em uma conta (Figura 1.7) ou a mudana de cidade para um

cliente (Figura 1.8) poderia alterar mais de um registro simultaneamente.

Por mais que a nova tabela CONTAS_CLIENTE (Figura 1.6) tambm seja uma

redundncia de dados, quando comparada s outras situaes (Figuras 1.7

e 1.8), ela representa uma replicao controlada e, portanto, mais eciente.



Na Figura 1.8, a duplicao de dados abrange quatro colunas (ID_CLIENTE,

NOME, CIDADE e SEXO), e na Figura 1.6, envolve duas colunas

(ID_CLIENTE e NUMERO_CONTA), mas nenhuma combinao se repete

na tabela CONTAS_CLIENTE.

Como a duplicao de dados inerente ao modelo relacional o que ine-

vitvel a situao representada pela Figura 1.6 mostra-se plenamente acei-

tvel e prefervel s demais situaes representadas pelas Figuras 1.7 e 1.8.

A maneira de denir quais colunas e em quais tabelas as mesmas devero ser

replicadas ser tratada adiante quando abordarmos conceitos como chaves

primrias, chaves estrangeiras e integridade referencial. Tambm veremos

com detalhes a linguagem de consulta e manipulao de BDs relacionais

conhecida como Structured Query Language (SQL), padro desde 1980.

Converta o exemplo de BD das Atividades anteriores em um exemplo equi-

valente no Modelo Relacional.

1.4.4 Modelo objeto-relacionalSGBDs que adotam o modelo Objeto-Relacional (OR) aproveitam a estru-

tura bsica do modelo relacional com algumas caractersticas prprias da

orientao a objetos. Porm, esse modelo hbrido no deve ser confundido

com o Orientado a Objetos. Dentre as caractersticas da orientao a objetos

incorporadas pelo modelo Objeto-Relacional merecem destaque: a herana

de tipos e tabelas e a denio de novos tipos complexos.

O modelo Objeto-Relacional conhecido como modelo relacional estendido.

Sua linguagem de consulta foi adaptada para abranger objetos, atributos mul-

tivalorados, dados abstratos, mtodos e funes como predicados de busca.

O padro ANSI SQL-99 ou SQL-3, caracterizado como SQL orientada a objetos,

trouxe inovaes em relao SQL-92. Ela a base de vrios SGBDs OR, como

o Oracle 11g, o IBM DB2 Universal Database e o Informix Universal Server.

1.4.5 Modelo orientado a objetosOs modelos em rede, hierrquico e relacional trouxeram importantes contribui-

es para a tecnologia de BD, principalmente os comerciais. Qualquer um des-

ses modelos foi um avano em relao aos sistemas tradicionais de arquivos.

Dentre os trs modelos acima, o relacional merece destaque, pois, desde a d-

cada de 1980, tornou-se padro de mercado no desenvolvimento de aplicaes



comerciais, como controle de estoques, contas a pagar e a receber, frente de

loja, recursos humanos, etc. Contudo, a complexidade de novas demandas tec-

nolgicas como os sistemas de informaes geogrcas e multimdias eviden-

ciaram as limitaes desses modelos. As novas aplicaes precisavam suportar

estruturas complexas de dados para objetos, assim como o armazenamento de

imagens digitalizadas e textos muito longos (ELMASRI; NAVATHE, 2005).

Outro fator que pressionou o desenvolvimento de um modelo Orientado a Ob-

jeto (OO) para BD a predominncia de linguagens de Programao Orientadas

a Objeto (POO). Logo, programadores de aplicaes convivem com os dois pa-

radigmas de desenvolvimento: modelo relacional para BD e orientao a objetos

para os programas que trabalham com esses mesmos bancos. Tudo seria mais

simples se aplicaes e bancos que do suporte persistncia de seus dados

fossem igualmente orientados a objetos, no sendo mais necessrio o mapea-

mento objeto-relacional para combinar as duas tecnologias.

Infelizmente, BDs orientados a objetos ainda no foram bem aceitos no mer-

cado. Tal rejeio explicada pela simplicidade e popularidade do modelo

relacional junto aos prossionais de informtica. Portanto, muitos desenvol-

vedores optam por uma soluo hbrida como o modelo Objeto-Relacional

ou modelo relacional estendido.

Modelo Orientado a Objetos abordado na disciplina referente Anlise e

Projeto de Sistemas.

ResumoNesta aula voc se familiarizou com conceitos bsicos de Banco de Dados.

Esses conceitos sero desenvolvidos com mais detalhes ao longo do mate-

rial. Vimos como as exigncias modernas de um maior controle sobre os

dados armazenados levaram ao surgimento de sistemas de informao; ini-

cialmente, desenvolvidos como sistemas de arquivos tradicionais que cons-

tituam um grande avano em relao os mecanismos manuais de registro

das informaes, mas apresentavam srias limitaes que somente foram

corrigidas com a tecnologia de Banco de Dados. Tambm abordamos os di-

ferentes tipos de usurios para Bancos de Dados. Os sistemas gerenciadores

de Bancos de Dados (SGBDs) foram implementados em diferentes modelos

ao longo do tempo. Inicialmente surgiram os SGBDs de modelo em rede.

Com a evoluo tecnolgica, sucederam-no os modelos hierrquico, relacio-

nal e o objeto-relacional. Um modelo orientado a objetos esperado para

breve, mas ainda no se estabeleceu no mercado.



Atividades de aprendizagem1. Liste em ordem cronolgica os modelos de BD.

2. Cite causas que levaram ao surgimento do modelo Orientado a Objetos de BD.

3. Por que BDs orientados a objetos no se tornaram popular no mercado? Poderamos armar que a tecnologia de BD estagnou no modelo relacio-

nal incorporando poucas inovaes desde o incio da dcada de 1970?

4. As tabelas mostradas na Figura 1.9 correspondem ao modelo relacional de BD.

Funcionarios

MATRICULA

01

02

03

04

CARGO

02

01

03

01

CPF

123

234

245

125

NOME

Ana

Maria

Jos

Pedro

Cargos

CODIGO

01

02

03

NOME_CARGO

Programador

Topgrafo

Engenheiro

Figura 1.9: Exemplo de BD de uma empresaFonte: Elaborada pelo autor

Converta esses dados:

a) para o modelo redes, e

b) para o modelo hierrquico (lembre-se de comear dos dados mais gerais para os mais especcos dentro da rvore).

5. (FCC 2006 SEFAZ PB Auditor Fiscal de Tributos Estaduais) Um geren-ciador de Banco de Dados relacional:

a) Identica a relao entre seus registros a partir de ponteiros no sentido lho-pai, unicamente.

b) Identica a relao entre dois ou mais registros a partir da sua justaposio.

c) No contempla a denio de dados pertinentes s tabelas.

d) Identica a relao entre seus registros a partir de ponteiros no sentido pai-lho, unicamente.

e) Deve possibilitar a identicao nica de uma linha de uma tabela.



e-Tec Brasil

Aula 2 Modelagem de Dados: Modelo Entidade-Relacionamento

Objetivos

Denir entidades e seus atributos.

Estabelecer relacionamentos entre entidades.

Ajustar a cardinalidade dos relacionamentos.

Interpretar Modelos de Entidade e Relacionamento (MER).

Modelar conceitualmente sistemas de informao.

O Modelo Entidade-Relacionamento (MER) uma tcnica criada em 1976

por Peter Chen (CHEN, 1990) que expressa gracamente a estrutura l-

gica de um BD. A aplicao da tcnica resulta em um diagrama com os

seguintes elementos:

(1) Entidades: representadas gracamente por um retngulo, so coisas ou objetos armazenados em um BD. MEDICO e PACIENTE, por exemplo,

so entidades em um BD projetado para suportar um sistema de agenda-

mento de consultas (Figura 2.1). Anal, ele implementado para armaze-

nar dados sobre mdicos da clnica e pacientes que agendam consultas.

MEDICO PACIENTE Figura 2.1: Representao grca das entidades MEDICO e PACIENTEFonte: Elaborada pelo autor

(2) Atributos: so caractersticas ou propriedades relevantes de uma enti-dade. Por relevantes destacamos que nem todas as informaes sobre

uma entidade so pertinentes para o modelo: saber qual a cor do cabelo

do paciente ou o time de futebol para o qual um mdico torce em nada

contribui para a marcao de uma consulta. Por outro lado, o nome do

paciente, sua data de nascimento (forma de manter atualizada sua ida-

de), um telefone para contato, o endereo e o sexo so informaes

relevantes para o contexto (Figura 2.2).

e-Tec BrasilAula 2 Modelagem de Dados: Modelo Entidade-Relacionamento 35


MEDICO

NR_CRMNOMECELULAR

PACIENTE

MATRICULANOMEENDERECOTELEFONECELULARGENERO

Figura 2.2: Entidades e seus respectivos atributosFonte: Elaborada pelo autor

(3) Relacionamentos: so vnculos ou associaes lgicas entre duas ou mais entidades. Em alguns casos, um relacionamento pode ser estabe-

lecido entre uma entidade e ela mesma (autorrelacionamento). Porm,

a forma mais comum de relacionamento entre duas entidades. As Fi-

guras 2.3, 2.4 e 2.5 apresentam exemplos de relacionamentos. Eles so

representados por uma linha com um losango sobreposto e um verbo

que o identica. No interior desse losango h geralmente uma seta indi-

cando o sentido da leitura do verbo. Na Figura 2.3, por exemplo, lemos

que mdico atende paciente. Por sua vez, a Figura 2.4 demonstra um

relacionamento entre trs entidades simultaneamente (relacionamento

ternrio). Nesse caso no usamos o verbo nem a seta, apenas o losango

na juno das linhas. A vantagem desse relacionamento que se torna

possvel saber qual o plano de sade utilizado pelo paciente em uma

determinada consulta com um dado mdico. A Figura 2.5 exemplica

um relacionamento entre uma entidade e ela mesma (o autorrelaciona-

mento) para que um funcionrio possa coordenar os trabalhos de outros,

permitindo identicar quais funcionrios so coordenados.

MEDICO PACIENTE

atende

Figura 2.3: Relacionamento entre duas entidadesFonte: Elaborada pelo autor

MEDICO PACIENTE

PLANO_DE_SAUDE

Figura 2.4: Relacionamento entre trs entidades (ternrio)Fonte: Elaborada pelo autor



FUNCIONARIO

coordena

Figura 2.5: Relacionamento de uma entidade consigo mesma (Autorrelacionamento)Fonte: Elaborada pelo autor

Faa um diagrama que demonstre relacionamentos coerentes entre as se-

guintes entidades de um restaurante: MESA, PRATO, GARCOM e COMANDA

(pedidos feitos pelos ocupantes da mesa). Indique para cada entidade um

conjunto de atributos adequados.

2.1 Cardinalidade de relacionamentosA cardinalidade uma caracterstica de todo relacionamento no Modelo

Entidade-Relacionamento (MER). Indica com quantas ocorrncias de uma

entidade as ocorrncias de outra entidade podem se relacionar.

A Figura 2.6 mostra um autorrelacionamento sem a indicao da cardinali-

dade, utilizamos os chamados indicadores de papis (Marido e Esposa).

O relacionamento pode ser lido como pessoa casa com pessoa. A indica-

o dos papis apenas torna claro que, no casamento, pessoas tm o papel

ou de marido ou de esposa.

PESSOA

casa com

Marido Esposa Figura 2.6: Autorrelacionamento com indicao de papisFonte: Elaborada pelo autor

A ausncia de cardinalidade nos impossibilita uma melhor compreenso das

regras envolvidas nesse casamento entre pessoas. Em algumas sociedades

permitido que um homem se case com vrias mulheres. Caso nosso Banco

de Dados precise reetir esse costume, devemos impor um relacionamento

de cardinalidade um-para-muitos (1:N).

O relacionamento da Figura 2.7 exemplica as regras de uma sociedade

poligmica, na qual um marido pode ter vrias esposas. Ento lemos que

uma (1) pessoa (Marido) pode casar-se com muitas (N) pessoas (Esposas).



Dene, tambm, que uma pessoa (Esposa) somente pode casar-se com

uma pessoa (Marido). Portanto, os direitos no so iguais nessa sociedade

e a cardinalidade dene isso com clareza. Um homem pode ter vrias mulhe-

res, mas uma mulher pode ter apenas um homem como marido.

PESSOA

IDENTIFICADOR

IDENTIFICADOR_MARIDO

NOMESEXO

casa com

Marido

N1

Esposa

Figura 2.7: Cardinalidade um-para-muitos (1:N)Fonte: Elaborada pelo autor

Os atributos da entidade PESSOA evidenciados na Figura 2.7 so:

(1) IDENTIFICADOR: cdigo que possibilite distinguir uma pessoa de outra sem confuses.

(2) NOME: nome completo da pessoa. No serve para identicar com preci-so dada a possibilidade da ocorrncia de homnimos (pessoas de mes-

mo nome. Ex.: Jos da Silva).

(3) SEXO: classicao do sexo das pessoas: F para feminino e M para masculino.

(4) IDENTIFICADOR_MARIDO: atributo que ser utilizado apenas pelas pessoas do sexo feminino. Geralmente, sociedades poligmicas no to-

leram casamentos de pessoas do mesmo sexo. Esse atributo ou ter valor

nulo (para homens e mulheres solteiras) ou conter o identicador de

uma pessoa do sexo masculino (o marido).

A Figura 2.8 exemplica uma tabela em BD relacional com a implementao

do diagrama anterior, onde um homem pode ter vrias esposas, mas uma

mulher, s um marido.



MF

F

F

F

F

M

1

1

1

5

1

PESSOA

2

3

4

5

6

7

Altair Souza

Karla Silva

Martha Souza

Sueli Souza

Ricardo Vitali

Rita Vitali

ngela Souza

SEXO IDENTIFICADOR_MARIDOIDENTIFICADOR NOME

Figura 2.8: Tabela PESSOA correspondente entidade PESSOAFonte: Elaborada pelo autor

Observe que, na tabela PESSOA, Altair tem trs esposas (Martha, Sueli

e ngela). Elas possuem o nmero identicador dele na coluna/atributo

IDENTIFICADOR_MARIDO. Por outro lado, Karla apresenta esse atributo

sem a indicao de qualquer nmero (valor nulo). Signica que Karla

solteira. Rita (identicador = 6) casada com Ricardo (identicador = 5).

Devemos destacar que a cardinalidade indicada no implica a obrigatorie-

dade de um homem ter mais de uma esposa. No exemplo, Ricardo tem

apenas uma esposa e poderiam ainda existir homens solteiros.

Considere agora outra sociedade onde os homens podero se casar apenas

com uma mulher, mas uma mulher poder casar-se com muitos homens (po-

liandria). Nosso MER sofreria uma alterao em sua cardinalidade, deixando

de apresentar um relacionamento um-para-muitos (1:N) para assumir um

relacionamento muitos-para-um (N:1).

A Figura 2.9 o resultado de uma sociedade polindrica. Curiosamente, ela

quase no difere da Figura 2.7. As nicas alteraes perceptveis so a troca

de posies entre N e 1 na indicao da cardinalidade, e a substitui-

o do atributo IDENTIFICADOR_MARIDO pelo IDENTIFICADOR_ESPOSA.

Portanto, a ordem dos fatores inui sobre o resultado nal. O relaciona-

mento agora indica que uma pessoa (Marido) pode casar-se com apenas

uma pessoa (Esposa) e que uma pessoa (Esposa) pode casar-se com

muitas pessoas (Maridos).



PESSOA

NOME

SEXO

casa com

Marido

N 1

Esposa

IDENTIFICADOR_ESPOSA

IDENTIFICADOR

Figura 2.9: Cardinalidade muitos-para-um (N:1)Fonte: Elaborada pelo autor

Agora consideremos que homens e mulheres negociaram uma sada mais

equilibrada, tornando essa sociedade monogmica (Figura 2.10).

PESSOA

NOMESEXO

casa com

Marido

11

Esposa

IDENTIFICADOR_CONJUGE

IDENTIFICADOR

Figura 2.10: Cardinalidade um-para-um (1:1)Fonte: Elaborada pelo autor

Mais uma vez nos deparamos com pequenas mudanas: o atributo

IDENTIFICADOR_CONJUGE substitui o atributo IDENTIFICADOR_ESPOSA ou

IDENTIFICADOR_MARIDO; e a cardinalidade do relacionamento agora um-

para-um (1:1). No temos mais o indicador N (que simboliza muitos/

vrios). Dessa forma, agora um homem pode casar-se com apenas uma

mulher e uma mulher, com somente um homem por vez.

Esgotamos todas as possibilidades de cardinalidade para esse relacionamen-

to? Certamente no. H a possibilidade de que um homem possa casar-se

com muitas mulheres e que tambm uma mulher possa casar-se com muitos

homens. Esse seria um relacionamento de cardinalidade muitos-para-muitos

(N:N). Nesse caso ocorreriam mudanas substanciais.

Na Figura 2.11, por exemplo, percebemos que um retngulo tracejado

aparece sobre o losango do relacionamento em consequncia direta de

relacionamentos de cardinalidade muitos-para-muitos. Esse retngulo

tracejado corresponde a uma relao e possui nome (Casamento) e atri-

butos (IDENTIFICADOR_MARIDO e IDENTIFICADOR_ESPOSA).



PESSOA

IDENTIFICADORNOMESEXO

casa comIDENTIFICADOR_MARIDO

IDENTIFICADO_RESPOSA

casamento

NN

Figura 2.11: Cardinalidade muitos-para-muitos (N:N)Fonte: Elaborada pelo autor

Em um BD relacional, essa situao precisa de duas tabelas: PESSOA e

CASAMENTO, como exemplicado na Figura 2.12.

M

F

M

F

F

M

F

1

2

3

4

5

6

7

Eduardo

Ana Paula

Ronaldo

Cibele

Anabela

Ceclia

Srgio

SEXOIDENTIFICADOR NOME

2

6

2

4

6

1

1

3

IDENTIFICADOR_MARIDO IDENTIFICADOR_ESPOSA

3

3

PESSOA

CASAMENTO

Figura 2.12: Banco de dados equivalente ao modelo ER da Figura 2.11Fonte: Elaborada pelo autor

Conforme a Figura 2.12, Eduardo (IDENTIFICADOR=1) possui duas ocor-

rncias na tabela CASAMENTO. Uma vez que do sexo masculino, seu identi-

cador aparece na coluna (atributo) IDENTIFICADOR_MARIDO. Signica que



Eduardo casado com duas mulheres: Ana Paula (IDENTIFICADOR=2)

e Ceclia (6). Como elas so do sexo feminino, seus identicadores so

reproduzidos na coluna IDENTIFICADOR_ESPOSA da tabela CASAMENTO.

Por analogia, Srgio (IDENTIFICADOR=7) continua solteiro, por no ter

ocorrncias na tabela CASAMENTO.

Acrescente a cardinalidade aos relacionamentos da Atividade anterior.

2.2 Exemplos do modelo entidade-relacionamento

Considere um BD para manter informaes atualizadas sobre os projetos de-

senvolvidos por uma empresa e as equipes responsveis por tais projetos.

Todos os integrantes das equipes so funcionrios da empresa. Cada projeto

gerenciado por um funcionrio e as equipes podem ser formadas por vrios

funcionrios. Independentemente dos projetos, cada funcionrio possui uma

funo na empresa (diretor, analista de sistemas, contador, engenheiro, etc.).

De cada projeto importa armazenar seu nmero identicador, nome, data de

incio, data prevista de concluso e data efetiva de concluso. Em relao a

cada funcionrio importante guardar sua matrcula, nome, sexo e funo.

A Figura 2.13 apresenta um diagrama ER que modela o BD proposto. Nela h

trs relacionamentos, trs entidades e uma relao. Observe que um funcio-

nrio pode gerenciar muitos projetos, mas um projeto pode ser gerenciado

apenas por um funcionrio. Entretanto, um funcionrio pode trabalhar em

muitos projetos simultaneamente e cada projeto pode ter muitos funcion-

rios nele trabalhando. Do mesmo modo, um funcionrio possui apenas uma

funo, mas uma funo pode pertencer a muitos funcionrios. Portanto,

um funcionrio no pode ser programador de computadores e contador ao

mesmo tempo, mas a empresa pode ter mais de um programador ou conta-

dor dentre seus funcionrios.



FUNCIONARIO

MATRICULA

NOME

SEXO

FUNCAO

PROJETO

NUMERONOMEDATA_INICIODATA_FINAL_PREVISTADATA_FINAL_EFETIVA

ID_FUNCAODESCRICAO

EQUIPEpossui

gerencia

trabalha emMATRICULA

NUMERO

N

N

N

N

1

1

Figura 2.13: Exemplo de Diagrama ERFonte: Elaborada pelo autor

Como indicam os atributos do modelo, um projeto ainda em andamen-

to apresentaria a DATA_FINAL_EFETIVA com valor nulo. A existncia de

DATA_FINAL_PREVISTA e de DATA_FINAL_EFETIVA permite avaliar o atra-

so do projeto em andamento ou concludo.

Consideremos agora a modelagem de um BD desenvolvido para o geren-

ciamento de uma biblioteca. Para simplicar, a biblioteca empresta apenas

livros. No h revistas ou DVDs em seu acervo. Tambm vetado ao usurio

dessa biblioteca reservar um livro indisponvel no momento como nas biblio-

tecas em que o usurio pode entrar em uma la de reservas, de modo que,

ao ser devolvido um exemplar do livro reservado, os usurios que zeram a

reserva podem, conforme sua ordem na la, requisitar o livro. Por outro lado,

o BD modelado deve prover os seguintes requisitos:

(1) Manter dados sobre as obras do acervo, como nome dos autores, data da aquisio, editora, edio e ttulo.

(2) Manter registro de todos os livros de uma mesma obra.

(3) Efetuar o emprstimo e devoluo de livros, mantendo registros detalha-dos ao longo do tempo.

(4) Consultar livros por cdigo de identicao, ttulo da obra, nome de au-tores e gnero da obra (autoajuda, dicionrio, literatura, etc.).

(5) Manter dados sobre os usurios da biblioteca: matrcula, nome, sexo, data de nascimento, endereo e telefone.



A Figura 2.14 mostra o diagrama ER para o sistema de informao dessa

biblioteca.

OBRA

NR_OBRATITULO

GENERO

ID_GENERODESCRICAO

AUTOR

ID_AUTORNOME

LIVRO

NR_LIVRODATA_AQUISICAOEDICAO

AUTORIA

referencia

classica

escreveNR_OBRAID_AUTOR

N

N

1

N

N

1

EDITORA

ID_EDITORANOME FANTASIA

publica

N

1

USUARIO

MATRICULANOMESEXODATA NASCIMENTOTELEFONECELULARE_MAILENDERECO

MOVIMENTACAO

movimenta

MATRICULANR_LIVRO

DATA_EMPRESTIMODATA PREVISTA

DATA_DEVOLUCAO

N

N N

Figura 2.14: Diagrama ER do Sistema de Gerenciamento de BibliotecaFonte: Elaborada pelo autor

Nela foram usadas duas entidades: OBRA e LIVRO. A entidade LIVRO, por

exemplo, refere-se a uma edio em particular de uma obra. Considere uma

obra do sculo XIX, como Helena, de Machado de Assis. Ela j foi publica-da por diferentes editoras em mais de um sculo de existncia. Portanto,

a entidade EDITORA no poderia estar relacionada entidade OBRA, mas

sim entidade LIVRO. Se fosse diferente, essa obra somente poderia ser

publicada por uma editora.



Por analogia, o atributo EDICAO no pode estar na entidade OBRA, mas em

LIVRO. Anal, somente livros publicados de uma mesma obra podem ter edi-

es diferentes. No exemplo, podem existir 30 livros da obra Helena, cada um

publicado por editoras diferentes ou com edies diferentes da mesma editora.

A entidade AUTOR se relaciona entidade OBRA, pois se relacionada a LIVRO

implicaria o relacionamento pouco justicvel de seus autores a cada livro.

Nesse caso, se 50 livros da obra de Alexandre Dumas, Os Trs Mosqueteiros, fossem doados para a biblioteca, um funcionrio deveria relacionar o nome

do autor a cada uma das 50 ocorrncias de LIVROS. Com o relacionamento

de AUTOR com OBRA, Alexandre Dumas seria relacionado a uma nica obra

e esta, por sua vez, aos 50 livros dessa mesma obra.

Ainda observando a Figura 2.14, notamos que um gnero pode classicar vrias

obras, mas uma obra pode ser classicada por um gnero. Assim, Helena e Os Trs Mosqueteiros podem ser classicadas como literatura. Porm, nenhuma dessas obras pode ser classicada em mais de um gnero simultaneamente.

Um autor pode escrever muitas obras, e uma obra, ser escrita por muitos

autores. Devido cardinalidade N:N surgiu a relao AUTORIA (retngulo

tracejado), possibilitando obras com mais de um autor, como em livros did-

ticos ou coletneas de artigos.

Um livro pode referenciar apenas uma obra, mas uma obra pode ser referen-

ciada por muitos livros. Por outro lado, Uma editora pode publicar muitos

livros, mas um livro pode ser publicado apenas por uma editora.

Um usurio pode movimentar vrios livros e um mesmo livro pode ser movi-

mentado por vrios usurios ao longo do tempo. Mais uma vez a cardinali-

dade N:N gerou a relao MOVIMENTACAO, a qual armazena emprstimos

e devolues de livros.

Ao emprestar um livro a um usurio, uma ocorrncia de movimentao gera-

da com o atributo DATA_DEVOLUCAO nulo e DATA_EMPRESTIMO com a data

atual do sistema. Na devoluo do livro essa movimentao atualizada com

a alterao do atributo DATA_DEVOLUCAO para a data corrente do sistema.

No exemplo de um diagrama ER da Figura 2.15, temos um BD modelado para

suportar um sistema de gerenciamento da marcao de consultas mdicas.



MEDICO

CRMNOMESEXOTELEFOMECELULARE-MAIL

ESPECIALIDADE

COD_ESPECIALIDADEDESCRICAO

PLANO_SAUDE

ID_PLANONOME_FANTASIA

ESPECIALISTA

CRMCOD_ESPECIALIDADE

ID_PLANOID_PACIENTE

CRMDATAHORA

CONSULTA

possui

N N

N

N

PACIENTE

ID_PACIENTENOMESEXOTELEFONECELULAR

N

Figura 2.15: Diagrama ER para marcao de consultas mdicasFonte: Elaborada pelo autor

O diagrama foi modelado a partir dos seguintes requisitos:

(1) Armazenar dados de mdico: nmero de registro no Conselho Regional de Medicina (CRM), nome completo, sexo, telefone xo, celular e e-mail para contato.

(2) Armazenar informaes de paciente: nmero identicador, nome com-pleto, sexo, telefone xo e celular.

(3) Identicar as especialidades de cada mdico (um mesmo mdico pode atuar, por exemplo, como clnico geral e dermatologista).

(4) Agendar consultas para um paciente, especicando o plano de sade e o mdico.



(5) Como simplicao do modelo no ser necessrio armazenar os hor-rios de atendimento semanal para cada mdico. Consideraremos apenas

que todos os mdicos atendem todos os dias teis da semana em um

horrio xo e igual para todos.

Note que Consulta uma relao gerada a partir de um relacionamento

ternrio entre as entidades MEDICO, PACIENTE e PLANO_SAUDE.

2.3 Generalizao/especializao de entidades

Existem situaes em que diferentes entidades apresentam algumas carac-

tersticas em comum, divergindo apenas em outras caractersticas. Na Figura

2.16, por exemplo, temos duas entidades nessa condio de semelhana:

MEDICO e PACIENTE.

MEDICO

CRMNOMESEXOTELEFONECELULARE_MAIL

PACIENTE

ID_PACIENTENOMESEXOTELEFONECELULAR

Figura 2.16: Entidades com atributos em comumFonte: Elaborada pelo autor

Repare que ambas apresentam quatro atributos em comum: NOME, SEXO,

TELEFONE e CELULAR. Mdico ainda possui dois atributos exclusivos: CRM

e E_MAIL. Por sua vez, a entidade Paciente apresenta um nico atributo so-

mente seu: ID_PACIENTE.

Nesses casos, podemos lanar mo de um recurso previsto na modelagem

de dados, conhecido como generalizao. Ento, uma nova entidade, mais

genrica ou menos especializada, deve ser criada para agregar os atributos

comuns.

Na Figura 2.17 temos uma entidade Pessoa que assume o papel de enti-

dade menos especializada. Ela chama para si os atributos comuns das en-

tidades mais especializadas: Mdico e Paciente. O smbolo triangular que

interliga essas entidades indica que os atributos de Pessoa so comparti-

lhados por MEDICO e PACIENTE, ou seja, MEDICO e PACIENTE herdam os

atributos de PESSOA. Entretanto, o atributo de ID_PACIENTE pertence so-

mente a PACIENTE; e CRM e E_MAIL so atributos exclusivos de MEDICO.



PESSOA

NOMESEXOTELEFONECELULAR

PACIENTE

ID_PACIENTE

MEDICO

CRME_MAIL

Figura 2.17: Exemplo de generalizao ou especializaoFonte: Elaborada pelo autor

Generalizao: entidades de um nvel mais baixo de abstrao com caracte-

rsticas comuns; so agrupadas originando uma entidade de nvel mais alto.

Especializao: uma entidade de nvel mais alto de abstrao desmembrada em

vrias entidades de nvel mais baixo, com caractersticas parcialmente distintas.

Construa um diagrama ER completo para um sistema de supermercado que

permita as seguintes funcionalidades:

a) Manter informaes sobre produtos (cdigo, nome, preo unitrio, quan-tidade em estoque e estoque mnimo).

b) Registrar vendas de produtos nos caixas.

c) Registrar recebimentos discriminando o tipo: em dinheiro, cheque, car-to de dbito, ou carto de crdito.

2.4 Entidades fracasUma entidade fraca qualquer uma cuja existncia no se justica. Surge

apenas em razo de seu relacionamento com outra entidade, considerada

forte. A entidade fraca deve apresentar identicadores compostos (formados

pelo menos por dois atributos). Um deles deve ser originrio da forte. Ele

replicado na fraca para estabelecer uma ligao entre as ocorrncias das duas.

Um exemplo de entidade fraca demonstrado na Figura 2.18. Dependente

a entidade fraca, pois a identicao de um dependente impossvel sem

a do scio. Na verdade, os dependentes no existiriam sem os scios.



SOCIO

ID_SOCIO

NOME

SEXO

ENDERECO

TELEFONE

CPF

RG

DATA_NASCIMENTO

DEPENDENTE

ID_SOCIO

ID_DEPENDENTE

NOME

SEXO

DATA_NASCIMENTO

1 N

possui

Figura 2.18: Exemplo de entidade fraca (dependente)Fonte: Elaborada pelo autor

ResumoAntes de sair criando tabelas, relacionamentos e consultas, devemos projetar

um BD que atenda satisfatoriamente aos objetivos de nossos usurios.

Um BD bem modelado demandar pouca ou nenhuma manuteno correti-

va no futuro. Por isso, conveniente despender parte do tempo inicial proje-

tando e modelando o BD propriamente dito. Uma vez concluda essa etapa,

pode-se dedicar tempo criao das tabelas, relacionamentos, consultas,

vises, procedimentos, etc.

Na modelagem de um BD, nos concentramos nos objetivos a que preten-

demos atender com essa tecnologia. Se pretendermos criar um BD para um

sistema de controle acadmico que permita armazenar dados sobre alunos,

turmas, disciplinas, notas e frequncias, quais sero as tabelas necessrias e

seus respectivos atributos?

E se o sistema objetivar gerenciar o atendimento de consultas mdicas em

uma clnica? Certamente, sero outras as tabelas e atributos necessrios.

Mas, quais sero essas tabelas e como se relacionaro entre si?

Neste captulo abordamos a modelagem conceitual de dados. Um modelo

conceitual objetiva projetar os requisitos de negcio segundo a perspectiva

do usurio nal. Tendo em vista apenas o modelo relacional de BD, no pre-

cisamos ainda determinar qual SGBD utilizaremos para implementar nosso

BD, no importando se o SGBD ser o Oracle, o Microsoft SQL-Server, o

Sybase, o PostgreeSQL, o Firebird ou o MySQL. O que modelaremos pode ser

implementado em qualquer SGBD relacional.



Atividades de aprendizagemNa transformao do modelo conceitual Entidade-Relacionamento (MER)

em um modelo lgico relacional (MRN), as cardinalidades do relacionamento

entre as entidades exercem papel importante.

ATOR FILME

atua em

Figura 2.19: Modelo Entidade-Relacionamento: relao entre ATOR e FILMEFonte: Elaborada pelo autor

Para o modelo apresentado na Figura 2.19 marque a opo correta dentre as apresentadas a seguir:

a) N:N, no gerando uma tabela para o relacionamento.

b) N:N, gerando uma tabela para o relacionamento.

c) N:1, no gerando uma tabela para o relacionamento.

d) N:1, gerando uma tabela para o relacionamento.

e) 1:N, no gerando uma tabela para o relacionamento.



e-Tec Brasil

Aula 3 Modelagem de Dados: Modelo Relacional Normalizado

Objetivos

Interpretar um Modelo Relacional Normalizado (MRN).

Implementar um MRN a partir de um MER preexistente.

Denir chaves primrias e estrangeiras para uma entidade.

Efetuar a normalizao do MRN, obedecendo s trs Formas

Normais (FN).

O Modelo Entidade-Relacionamento (MER) a primeira etapa da modela-

gem de dados para a implementao de um BD. Desenvolvido pelo analista

de sistemas, ele considerado um modelo conceitual do BD em implemen-

tao. Logo, pode ser elaborado antes mesmo da denio do SGBD em que

a soluo ser implementada. A nica restrio imposta pelo modelo ER a

escolha de um SGBD tambm relacional.

Uma vez concluda a etapa, a equipe de analistas de sistemas deve ocupar-se

do projeto lgico do BD: o Modelo Relacional Normalizado (MRN). At aqui

ignoramos alguns importantes conceitos que, agora, durante o modelo lgi-

co, devemos considerar. O mais bsico desses conceitos a chave primria.

3.1 Chave primriaEm BD relacionais as informaes so armazenadas em tabelas, sendo essencial-

mente organizadas em linhas e colunas. Cada linha de uma tabela corresponde

a uma ocorrncia da informao. Assim, em uma tabela de alunos (Figura 3.1),

cada linha (ou registro) corresponde ao conjunto de informaes inter-relaciona-

das de um aluno. As colunas (ou campos) correspondem a subdivises lgicas

ou compartimentos para diferentes informaes contidas em uma mesma linha.

Na tabela ALUNO na Figura 3.1, cada linha foi subdividida em cinco colunas

(MATRICULA, NOME, SEXO, NASCIMENTO e CURSO). No exemplo existem seis

linhas armazenando as informaes de seis diferentes alunos de uma institui-

o de ensino. Os dados armazenados nas colunas de uma mesma linha so

e-Tec BrasilAula 3 Modelagem de Dados: Modelo Relacional Normalizado 51


relativos a um mesmo aluno. Assim, podemos armar que o aluno de nome

Rodrigo Bvar tem matrcula 1099, do sexo masculino, nasceu em 25/12/1992

e cursa Informtica. Tambm podemos conrmar que a aluna Karina Gonalves

encontra-se matriculada no curso de Biologia com a matrcula 1203.

MATRICULA

1099

1203

1399

1500

1701

NOME

Rodrigo Bvar

Karina Gonalves

Jos da Silva

Cesrio Antunes

Jos da Silva

SEXO

M

F

M

M

M

NASCIMENTO

25/12/1992

03/11/1998

27/02/1995

16/12/1999

03/10/1991

CURSO

Informtica

Biologia

Matemtica

Farmcia

Informtica

ALUNO

Figura 3.1: Tabela ALUNO de uma escolaFonte: Elaborada pelo autor

Uma tabela pode armazenar milhares de linhas (registros). Imaginar a com-

plexidade de localizar um registro especco em meio a milhares de outros

no difcil. As colunas podem ajudar a identicar uma linha especca,

distinguindo-a das demais.

Supondo que iremos acessar os dados de um determinado aluno; a busca

pela linha deve ser parametrizada pelo valor de uma ou mais colunas, mas

no de qualquer coluna. Anal, diferentes alunos podem, por exemplo, ter

o mesmo nome. Na Figura 3.1, essa situao encontra-se exemplicada nas

linhas 3 e 5 da tabela, onde esto registrados dois alunos de nome Jos da

Silva. A possibilidade de alunos homnimos torna a coluna Nome inadequa-

da para a identicao de um registro em particular.

A Figura 3.2 mostra o resultado da busca na tabela ALUNO com o critrio de

pesquisa NOME = Jos da Silva; o fato de essa busca/consulta resultar em mais de uma linha evidencia a inadequao da coluna NOME na identi-cao de uma linha em particular.

MATRICULA NOME SEXO NASCIMENTO CURSO

1399

1701

Jos da Silva

Jos da Silva

M

M

27/02/1995

03/10/1991

Matemtica

Informtica

Figura 3.2: Resultado da busca por aluno de Nome = Jos da SilvaFonte: Elaborada pelo autor



Por outro lado, a utilizao da coluna MATRICULA como critrio de pesquisa

mostra-se adequada para a identicao de uma nica linha. Anal, no po-

dem existir dois alunos com um mesmo nmero de MATRICULA 1701. A Figu-ra 3.3 exemplica o resultado de uma busca utilizando a coluna MATRICULA

como critrio de pesquisa.

MATRICULA

1701

NOME

Jos da Silva

SEXO

M

NASCIMENTO

03/10/1991

CURSO

Informtica

Figura 3.3: Resultado da busca por Aluno de MATRICULA = 1701Fonte: Elaborado pelo autor

Na Figura 3.4 apresentada a entidade FUNCIONARIO dotada de 12 atributos.

Desses, podemos selecionar algumas superchaves: CARTEIRA_IDENTIDADE uma superchave, pois no existe mais de um funcionrio com o mesmo nmero

da carteira de identidade. Entretanto, no a nica superchave. CPF tambm

uma, assim como a combinao de atributos {NOME e CARTEIRA_IDENTI-DADE}, ou {NOME e CPF}, ou ainda {NOME, CARTEIRA_IDENTIDADE e CPF} e {NOME e TELEFONE}; lembrando que o atributo NOME isoladamente no pode ser considerado uma superchave.

FUNCIONARIO

NOMESEXODATA_NASCIMENTOCARTEIRA_IDENTIDADECPFLOGRADOUROCOMPLEMENTOBAIRROCIDADEUFCEPTELEFONE

Figura 3.4: Atributos da entidade FUNCIONARIOFonte: Elaborada pelo autor

Portanto, a combinao de atributos {NOME, CPF}, apesar de ser super-

chave, no pode ser uma chave candidata, pois {CPF} tambm super-chave e subconjunto da combinao. O mesmo vale para a combinao

{CARTEIRA_IDENTIDADE, CPF, NOME}, que no chave candidata, pois

existem dois subconjuntos que so superchaves.

Superchave um conjunto de um ou mais atributos que permite identicar com preciso uma nica linha de uma tabela.

Chaves candidatasSo um subconjunto espec-co das superchaves. Somente podem ser chaves candidatas as superchaves mnimas. Ou seja, uma superchave formada pela combinao de mais de um atributo pode ser classicada como uma chave candidata apenas se essa combinao no possuir qualquer subconjunto prprio que seja ele mesmo uma superchave.

e-Tec BrasilAula 3 Modelagem de Dados: Modelo Relacional Normalizado 53


A entidade FUNCIONARIO possui vrias chaves candidatas: {CPF} e {CARTEIRA_IDENTIDADE} e {NOME e TELEFONE}.

A Figura 3.5 mostra as tabelas do sistema de marcao de consultas com

suas respectivas chaves primrias. Gracamente, elas so representadas em uma faixa estreita abaixo do nome das entidades. Todo atributo no inte-

rior dessa faixa parte da chave primria.

MEDICO

CRM

NOME

SEXO

TELEFONE

CELULAR

EMAIL

ESPECIALIDADE

COD_ESPECIALIDADE

DESCRICAO

PACIENTE

ID_PACIENTE

NOME

SEXO

TELEFONE

CELULAR

CONSULTA

ID_PACIENTECRMDATA

HORA

ID_PLANO

ESPECIALISTA

CRM

COD_ESPECIALIDADE

PLANO_SAUDE

ID_PLANO

NOME_FANTASIA

Figura 3.5: Chaves primrias nas entidades do sistema de marcao de consultasFonte: Elaborada pelo autor

O atributo CRM obviamente a chave primria de MEDICO, pois mdicos

no possuem o mesmo registro no Conselho R

Documents

Banco de Dados WEB