banco de dados i-prof. claudinete vicente borges ferreira

PROF. CLAUDINETE VICENTE BORGES FERREIRA

BANCO DE DADOS I

SERRA2011

Governo FederalMinistro de EducaoFernando Haddad

Ifes Instituto Federal do Esprito Santo Reitor

Denio Rebello Arantes

Pr-Reitora de EnsinoCristiane Tenan Schlittler dos Santos

Coordenadora do CEAD Centro de Educao a DistnciaYvina Pavan Baldo

Coordenadores da UAB Universidade Aberta do Brasil Elton Siqueira Moura Danielli Veiga Carneiro Sondermann

Curso de Tecnologia em Anlise e Desenvolvimento de SistemasCoordenao de Curso

Andromeda Gorete Correa de Menezes

Designer InstrucionalAline Freitas da Silva

Professor Especialista/AutorClaudinete Vicente Borges Ferreira

Catalogao da fonte: Rogria Gomes Belchior - CRB 12/417

F383b Ferreira, Claudinete Vicente Borges Banco de dados I. / Claudinete Vicente Borges Ferreira. Vitria: Ifes,

2011. 129 p. : il. 1. Banco de dados. I. Instituto Federal do Esprito Santo. II. Ttulo. CDD 005.74

DIREITOS RESERVADOSIfes Instituto Federal do Esprito Santo Avenida Rio Branco, n 50 Santa Lcia - CEP. 29056-255 Vitria ES - Telefone: 3227-5564

Crditos de autoria da editoraoCapa: Juliana Cristina da SilvaProjeto grfico: Juliana Cristina e Nelson Torres

Iconografia: Nelson TorresEditorao eletrnica: Duo Translations

Reviso de texto: Esther Ortlibe Faria de Almeida

COPYRIGHT proibida a reproduo, mesmo que parcial, por qualquer meio, sem autorizao escrita dos autores e do detentor dos direitos autorais.

Ol, Aluno(a)!

um prazer t-lo(a) conosco.

O Ifes oferece a voc, em parceria com as Prefeituras e com o Governo Federal, o Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas, na modalidade a distncia. Apesar de este curso ser ofertado a distncia, esperamos que haja proximidade entre ns, pois, hoje, graas aos recursos da tecnologia da informao (e-mail, chat, videoconferncia, etc.), podemos manter uma comunicao efetiva.

importante que voc conhea toda a equipe envolvida neste curso: co-ordenadores, professores especialistas, tutores a distncia e tutores presen-ciais, porque, quando precisar de algum tipo de ajuda, saber a quem recorrer.

Na EaD - Educao a Distncia, voc o grande responsvel pelo sucesso a aprendizagem. Por isso, necessrio que voc se organize para os estudos e para a realizao de todas as atividades, nos prazos estabelecidos, con-forme orientao dos Professores Especialistas e Tutores. Fique atento s orientaes de estudo que se encontram no Manual do Aluno.

A EaD, pela sua caracterstica de amplitude e pelo uso de tecnologias mo-dernas, representa uma nova forma de aprender, respeitando, sempre, o seu tempo.

Desejamos-lhe sucesso e dedicao!

Equipe do Ifes

Fala do Professor

Conceitos importantes. Fique atento!

Atividades que devem ser elaboradas por voc, aps a leitura dos textos.

Indicao de leituras complemtares, referentes ao contedo estudado.

Destaque de algo importante, referente ao contedo apresentado. Ateno!

Reflexo/questionamento sobre algo impor-tante referente ao contedo apresentado.

Espao reservado para as anotaes que voc julgar necessrias.

ICONOGRAFIA

Veja, abaixo, alguns smbolos utilizados neste material para gui-lo em seus estudos

Cap. 1 - CONCEITOS DE BANCOS DE DADOS 9

1.1 Definio 91.2 Objetivos 101.3 Sistemas de arquivos convencionais 111.4 Usurios de banco de dados 121.6 Independncia de Dados 141.7 Arquitetura de sistemas de banco de dados 15

1.7.1 Sistemas Centralizados 151.7.2 Sistemas cliente-servidor 151.7.3 Sistemas Paralelos 161.7.4 Sistemas Distribudos 16

1.8 Modelos de bancos de dados 171.8.1 Modelo em rede 171.8.2 Modelo herrquico 181.8.3 Modelo relacional 191.8.4 Modelo objeto-relacional 201.8.5 Modelo orientado a objeto 20

1.9 Estrutura geral do sistema 211.9.1 Componentes de processamentos de consultas 211.9.2 Componentes para administrao do armazenamento de

dados 211.9.3 Outras estruturas de dados 22

1.10 Linguagem de definio de dados (DDL) 231.11 Linguagem de manipulao de dados (DML) 241.12 Projetando bancos de dados 24

Cap. 2 - MODELAGEM DE DADOS 29

2.1 Introduo 292.2 Modelos 292.3 Motivos para construo de modelos 302.4 Modelo de entidades e relacionamentos - E/R 30

2.4.1 Entidades 312.4.2 Atributos 322.4.3 Relacionamentos 36

2.5 Dicionrio de dados 452.6 Exemplo de um modelo de dados 462.7 Ferramentas case 482.8 Modelo ER estendido - EER 48

BANCO DE DADOS I

Cap. 3 - PROJETO LGICO DE BANCO DE DADOS 51

3.1 Definio 513.2 Estrutura dos bancos de dados relacionais 513.3 Chaves 533.4 Propriedades do modelo relacional 553.5 Traduo do modelo ER para o relacional 56

3.5.1 Relacionamento 1:1 583.5.2 Relacionamento 1:N 593.5.3 Relacionamento 1:N - identificado 593.5.4 Relacionamento N:N 603.5.5 Generalizao e especializao 613.5.6 Autorrelacionamento 1:N 633.5.7 Autorrelacionamento N:N 633.5.8 Atributos multivalorados 64

3.6 Exemplo de projeto lgico 653.7 Normalizao 66

3.7.1 Primeira forma normal (1FN) 673.7.2 Segunda forma normal (2FN) 673.7.3 Terceira forma normal (3FN) 68

Cap. 4 - LINGUAGENS DE CONSULTA 71

4.1 Definio 714.2 lgebra Relacional 72

4.2.1 Operaes fundamentais 734.2.2 Operaes no-fundamentais 88

4.3 SQL 954.3.1 Linguagem de manipulao de dados SQL DML 964.3.2 Linguagem de definio de dados SQL DDL 120

REFERNCIAS 129

APRESENTAO

Ol!

Meu nome Claudinete Borges, responsvel pela disciplina Banco de Da-dos I. Atuo como professora do Ifes h cinco anos e j lecionei em ou-tras instituies de ensino superior, como Ufes, UVV e Unilinhares. Sou graduada em Cincia da Computao (1995) e mestre em Informtica (2001), ambos pela UFES. Minhas reas de interesse so Banco de Dados e Engenharia de Software.

Nesta disciplina voc conhecer conceitos de modelagem e de bancos de dados. Os Bancos de Dados so responsveis por manter a persistncia dos sistemas de informaes existentes no mercado, o que nos mostra a importncia da disciplina em um curso de Anlise de Sistemas.

Este material tem como objetivo o de orient-lo no estudo da disciplina Banco de Dados I, por meio de dicas e sugestes, com destaque aos pontos mais importantes. Aqui voc encontrar conceitos com os quais trabalha-remos ao longo do Curso, tendo sido elaborado tomando como referncia livros clssicos das reas correlatas, tais como Abraham Silberschatz, Peter Chen, Carlos Alberto Heuser, Elmasri Navathe e outros. Alm destes au-tores, teve a contribuio valiosa da professora e amiga Eliana Caus que muito enriqueceu com suas notas de aula e sugestes. Apesar disso, este material impresso no dispensa a utilizao dos livros referenciados na bibliografia, que trazem diversos exemplos adicionais e aprofundamento maior em vrios aspectos.

Os conceitos aqui apresentados devem ser bem assimilados, pois serviro de base para a disciplina Banco de Dados II, a ser ofertada no prximo se-mestre, e para sua vida profissional, caso voc faa a opo por trabalhar na rea de Anlise de Sistemas. Foi preparado para voc com muito carinho!

Sucesso!!!

Profa. Claudinete Vicente Borges Ferreira

8Tecnologia em Anlise e Desenvolvimento de Sistemas

CONCEITOS DE BANCOS DE DADOS

Ol,

Neste captulo voc ter um primeiro contato com a disciplina Ban-co de Dados. A proposta de apresentar conceitos importantes que serviro de base para o restante do curso.

Bom estudo!

Profa. Claudinete Vicente Borges

1.1 Definio

Um banco de dados, tambm conhecido como base de dados, um con-junto de arquivos estruturados de forma a facilitar o acesso a conjuntos de dados. Esses arquivos encontram-se, de alguma forma, relacionados. Por exemplo, em um banco de dados de funcionrios de uma empresa podemos encontrar alguns arquivos, tais como: dados pessoais (nome, endereo, dados de documentos, lotao), dados funcionais (cargo, data de admisso, etc.) e dados para pagamento (salrio base, faixas, etc.). Para obter informaes sobre um dado funcionrio, como nome, cargo e salrio, ser necessrio consultar os trs arquivos, que devem estar relacionados. Segundo Heuser, um banco de dados um conjunto de dados integrados, cujo objetivo atender uma comunidade de usurios [HEUSER, 2004].

Com o crescimento do volume e dos tipos de dados nas organizaes, preciso utilizar softwares especiais para gerenci-los, os chamados SGBDs (Sistemas Gerenciadores de Banco de Dados). Um SGBD um software de carter geral para a manipulao eficiente de grandes colees de informaes estruturadas e armazenadas de uma forma consistente e integrada. Tais sistemas incluem mdulos para consulta, atualizao e as interfaces entre o sistema e o usurio. Podemos afirmar, ento, que um SGBD constitudo por um conjunto de dados associa-dos a um conjunto de programas para acesso a estes dados [SILBERS-CHATZ, 2006]. A figura 1 abaixo representa este conceito de forma grfica.

10

Tecnologia em Anlise e Desenvolvimento de Sistemas

arquivosinter-

relacionados

conjunto deprogramas

Figura 1 - Ilustrao do conceito de um SGBD.

Um banco de dados um conjunto de dados integrados, cujo ob-jetivo atender uma comunidade de usurios [ HEUSER, 2004].

Um SGBD um software de carter geral, usado para ma-nipulao eficiente de grandes colees de informaes estru-turadas e armazenadas de uma forma consistente e integrada [SILBERSCHATZ, 2006].

SGBD = Conjunto de programas + Conjunto de dados.

1.2 Objetivos

Dentre os principais objetivos do uso de Sistemas Gerenciadores de Bancos de Dados, destacam-se:

Disponibilizar dados integrados para uma grande variedade de usu-rios e aplicaes por meio de interfaces amigveis;

garantir a privacidade dos dados por meio de medidas de segurana dentro do sistema (como vises, permisses, senhas de acesso);

permitir compartilhamento dos dados de forma organizada, me-diando a comunicao entre aplicaes e banco de dados e adminis-trando acessos concorrentes;

possibilitar independncia dos dados, poupando ao usurio a neces-sidade de conhecer detalhes de implementao interna, organizao de arquivos e estruturas de armazenamento.

Captulo 1

11

Banco de Dados I

1.3 Sistemas de arquivos convencionais

Os sistemas de processamento de arquivos caracterizam-se por uma srie de registros guardados em diversos arquivos e uma srie de programas aplicativos para extrair e adicionar registros nos arquivos apropriados.

Podemos citar como desvantagens desse sistema (arquivos), em relao aos SGBDs [SILBERSCHATZ,2006]:

Redundncia e inconsistncia de dados: considerando que diferentes programadores tm a possibilidade de criar arquivos com estruturas di-ferentes e aplicaes para acess-los, a possibilidade de se redundar dados por esses arquivos muito grande. Alm disso, em funo dessa redundncia, podero ocorrer as inconsistncias, considerando que os dados podero ser atualizados em alguns arquivos e em outros no;

Dificuldade no acesso aos dados: diferentemente dos SGBDs, os siste-mas de arquivos no possuem um ambiente para recuperao dos dados armazenados. Com isso, para cada informao a ser gerada, necess-rio construir uma aplicao;

Isolamento de dados: considerando a diversidade de formatos existentes dos arquivos e, consequentemente, dos dados armazenados neles, tor-na-se uma tarefa difcil a construo de aplicaes para a recuperao desses dados;

Problemas de atomicidade: o conceito de atomicidade est altamente relacionado ao de tomo, que se caracteriza como algo indivisvel. Quando se fala em atomicidade em banco de dados, fala-se de uma unidade de trabalho que se deve executar totalmente ou que no se deve executar. Um exemplo clssico de atomicidade seria uma transfern-cia de dinheiro entre duas contas, A e B. Se desejarmos transferir, por exemplo, R$ 100,00 da conta A para a Conta B, ou este valor ser trans-ferido integralmente ou no ocorrer a transferncia. No cabvel que o dinheiro saia da conta A e no entre na conta B, por exemplo!

Anomalias de acesso concorrente: considerando o acesso simultneo aos arquivos, por diferentes aplicaes ou por diferentes usurios de uma mesma aplicao, pode-se gerar inconsistncias nesses arquivos devi-do a esses acessos. Tomemos como exemplo que uma conta conjunta A - com saldo igual a R$ 1000,00 - foi acessada de forma simultnea pelos correntistas Gabriel e Luiza. Gabriel sacou R$100,00 e Luiza, R$200,00. Pergunta-se: qual o saldo da conta aps os saques? Se ambos leram o valor do saldo igual a R$1000,00, podemos ter como possveis valores : R$900,00, R$800,00, levando-se em conta qual valor foi es-

Conceitos de Bancos de Dados

12


crito por ltimo. Nesse caso, nenhum dos dois valores so os corretos. O correto seria ter um saldo igual a R$700,00.

Problemas de segurana:. nem todos os usurios possuem perfil para acessar todos os dados disponveis em um arquivo. Tomemos como exemplo um arquivo de funcionrios, que possui, entre outros dados, o valor do salrio do funcionrio. Embora tenhamos a curiosidade de saber o salrio dos nossos colegas, principalmente do nosso chefe, no politicamente correto que desrespeitemos seu direito privacidade. No entanto, no possivel definir, para um arquivo, que alguns campos podero ser visveis por um usurio e por outros no, o que gera vulne-rabilidade nesses sistemas;

Problemas de integridade: para explicar melhor esse item, tomemos como exemplo dois arquivos, um de scios e outro de dependentes, de uma locadora de vdeo. Um dependente est relacionado a um scio e, por consequncia, a existncia daquele depende da existncia deste, ao qual estar subordinado. Desse modo, a excluso de um scio acarreta a excluso de seus dependentes. Esse tipo de integridade denomina-se de integridade referencial, porm, existem outras mais simples que os arquivos no comportam.

Considerando que as caractersticas descritas no so includas nos arquivos convencionais, elas devem ser includas nas aplicaes. Ima-gine a complexidade das aplicaes escritas para implement-las! Os Sistemas de Bancos de Dados de mdio e grande porte existentes no mercado implementam esses conceitos com muita robustez.

Voc deve estar pensando: ser que existem vantagens em usar os sistemas de arquivos? O custo mais baixo pode ser conside-rado uma vantagem.

1.4 Usurios de banco de dados

Basicamente so quatro os tipos de usurios de sistemas de bancos de dados:

Usurios leigos: interagem com o banco de dados por meio das interfa-ces de aplicaes escritas por programadores de aplicaes;

Captulo 1

13

Banco de Dados I

Usurios avanados: interagem com os bancos de dados por meio de interfaces disponveis nesse ambiente. Escrevem consultas SQL e as submetem execuo sem a necessidade de escrever uma aplicao para esse fim;

Programadores aplicaes: usurios com formao em computao e que se propem a construir aplicaes, por meio de ferramentas (com-piladores) destinadas para esse fim. Utilizando essas ferramentas, cons-troem interfaces para as aplicaes, incluindo formulrios e relatrios, acessando bancos de dados;

Administrador de Banco de Dados (DBA): usurios mais especia-lizados para um banco de dados. Cabe a eles a administrao dessas bases, definio da melhor estrutura de armazenamento desses dados, definio de aspectos de segurana, programao de cpias de seguran-a (backups), dentre outros.

O DBA pode ser comparado com um profissional da rea mdica. Se for responsvel por sistemas que requerem alta disponibilidade, deve ficar de planto 24 h por dia.

1.5 Abstrao de dados

Considerando que o nvel de conhecimento dos usurios de bancos de dados muito varivel, oscilando entre aqueles que conhecem muito e outros que so leigos, os Sistemas de Bancos de Dados devem prover de mecanismos que administrem essa complexidade, simplificando as interaes dos usurios com o sistema. Para isso, trs nveis de abstra-o so considerados:

Nvel de Viso: diz respeito forma como os dados so vistos pelos usurios (individualmente). Diferentes usurios podero ter diferentes vises de um mesmo banco de dados. Um determinado usurio, tanto pode ser um programador de aplicaes quanto um usurio final. O DBA um caso especialmente importante. Ao contrrio dos usurios comuns, o DBA ter de se interessar pelos nveis lgico e fsico.

Lgico: o nvel lgico descreve quais dados esto armazenados no banco de dados e qual a relao existente entre eles. Podemos dizer que a viso lgica a viso dos dados como realmente so e no como os usurios so forados a v-los devido s restries de linguagem ou hardware.


14


Fsico: diz respeito forma como os dados esto armazenados fisicamente. Preocupa-se em descrever as estruturas de dados complexas de baixo nvel.

Os SGBDs possibilitam aos usurios uma viso abstrata dos da-dos, ou seja, os usurios no precisam saber como os dados so armazenados e mantidos para us-los.

A figura 2 representa graficamente os nveis listados acima.

Viso 1 Viso 2 Viso n- - -

Nvel Lgico

Nvel Fsico

Figura 2 - Nveis de abstrao de dadosFonte: Silberschatz, Korth e Sudarshan, 2006. Adaptao.

1.6 Independncia de dados

A independncia de dados pode ser definida como a imunidade das apli-caes s alteraes feitas, seja no nvel fsico ou no nvel lgico de um banco de dados. O objetivo alcanar o mximo de independncia possvel. Pode ser classificada em:

Independncia Fsica de dados: habilidade de modificar o esquema fsico, sem a necessidade de reescrever os programas aplicativos. As modificaes no nvel fsico so ocasionalmente necessrias para me-lhorar o desempenho.

Independncia Lgica de dados: habilidade de modificar o esquema conceitual, sem a necessidade de reescrever os programas aplicativos. As modificaes no nvel conceitual so necessrias quando a estrutura lgica do banco de dados alterada.

Captulo 1

15

Banco de Dados I

Normalmente, modificaes no nvel fsico visam melhoria de desempenho, como a criao de ndices!

Qual abordagem mais fcil de ser alcanada: independncia fsica ou lgica de dados? Normalmente, a independncia fsica de dados mais fcil de ser alcanada do que a lgica. Ao criar um ndice, como em uma tabela, as aplicaes que referenciam essa tabela de-vem continuar funcionando, a despeito da alterao feita!

1.7 Arquitetura de sistemas de banco de dados

A arquitetura de um sistema de banco de dados est altamente relacio-nada s caractersticas do sistema operacional sobre o qual o SGBD ser executado [SILBERSCHATZ, 2006].

1.7.1 Sistemas centralizados

Os sistemas centralizados so os executados sobre um nico sistema operacional, no interagindo com outros sistemas. Eles podem ter a en-vergadura de um sistema de banco de dados de um s usurio, execu-tado em um computador pessoal ou em sistemas de alto desempenho, denominados de grande porte.

1.7.2 Sistemas cliente-servidor

Como os computadores pessoais tm se tornado mais rpidos, mais po-tentes e baratos, h uma tendncia de ampliar o seu uso nos sistemas centralizados, por isso terminais conectados a sistemas centralizados esto sendo substitudos por computadores pessoais. Como resultado, os sistemas centralizados atualmente agem como sistemas servidores que atendem a solicitaes de sistemas-cliente.

A computao cliente-servidor um processamento cooperativo de informa-es de negcio por um conjunto de processadores, no qual mltiplos clientes iniciam requisies que so realizadas por um ou mais servidores centrais.

O termo cliente-servidor usado para descrever software que execu-tado em mais de um hardware de modo a realizar uma tarefa do neg-cio. A separao de hardware a norma em aplicaes cliente-servidor, embora algumas pessoas utilizem o termo para descrever diferentes


16


componentes de software se comunicando uns com os outros, ainda que rodando em uma mesma mquina. A distncia entre processadores remotos varia desde computadores localizados na mesma sala ou pr-dio, at aqueles localizados em diferentes prdios, cidades ou mesmo espalhados pelo planeta.

Nessa arquitetura, as funcionalidades de um banco de dados podem ser superficialmente divididas em duas categorias: front-end e back-end. O back-end gerencia as estruturas de acesso, o desenvolvimento e a otimi-zao de consultas, o controle de concorrncia e a recuperao. O front-end consiste em ferramentas como formulrios, gerador de relatrios e recursos de interface grfica. A interface entre o front-end e o back-end feita por meio de SQL ou de um programa de aplicao.

1.7.3 Sistemas paralelos

Sistemas paralelos imprimem velocidade ao processamento e CPU, por meio do uso em paralelo de CPUs e discos.

No processamento paralelo muitas operaes so realizadas ao mesmo tempo, ao contrrio do processamento serial, no qual os passos do pro-cessamento so sucessivos. Um equipamento paralelo de granulao-grossa consiste em poucos e poderosos processadores (a maioria dos servidores atuais), enquanto um paralelismo intensivo ou de granulao fina usa milhares de pequenos processadores, com capacidade menor de processamento. Computadores paralelos com centenas de processado-res j esto disponveis comercialmente.

As duas principais formas de avaliar o desempenho de um sistema de banco de dados so pelo throughput e pelo tempo de resposta. O primei-ro diz respeito ao nmero de tarefas que podem ser executadas em um dado intervalo de tempo. Um sistema que processa um grande nmero de pequenas transaes pode aumentar o throughput por meio do proces-samento de diversas transaes em paralelo. J o tempo de resposta diz respeito ao tempo total que o sistema pode levar para executar uma nica tarefa. Um sistema que processa um grande volume de transaes pode reduzir o tempo de resposta por meio de processamento em paralelo.

1.7.4 Sistemas distribudos

Em um sistema distribudo, o banco de dados armazenado, geografi-camente, em diversos computadores denominados sites. Os computa-dores de um sistema de banco de dados distribudos comunicam-se com outros por intermdio de vrios meios de comunicao, como redes de alta velocidade ou linhas telefnicas.

Captulo 1

17

Banco de Dados I

As principais diferenas entre os bancos de dados paralelos e os bancos de dados distribudos so que, nos bancos de dados distribudos, h a distribuio fsica geogrfica, a administrao ocorre de forma separada e h uma intercomunicao menor. Outra grande diferena que nos sistemas distribudos distinguimos transaes locais (acessa um nico computador, em que a transao foi iniciada) e globais (envolve mais de um computador, sendo necessria a participao de um coordenador).

H diversas razes para a utilizao de sistemas de bancos de dados dis-tribudos, dentre as quais: compartilhamento dos dados (usurios de um local podem ter acesso a dados residentes em outros por exemplo: ban-cos), autonomia (cada local administra seus prprios dados) e disponibi-lidade (se porventura um SGBD sair do ar, os demais podem continuar em operao). H, no entanto, algumas desvantagens relacionadas ao seu uso, dentre as quais: custo de desenvolvimento de software, maior possi-bilidade de bugs e aumento do processamento e sobrecarga.

1.8 Modelos de bancos de dados

Os modelos de bancos de dados definem a forma como os dados encon-tram-se organizados internamente. Em ordem cronolgica, os modelos de banco de dados classificam-se em redes, hierrquicos, relacionais, objeto-relacionais e orientados a objetos. A seguir, h uma breve des-crio sobre cada um desses modelos.

1.8.1 Modelo em rede

Um banco de dados em rede consiste em uma coleo de registros que so concatenados uns aos outros por meio de ligaes. Um registro , em muitos aspectos, similar a uma entidade no modelo entidade-rela-cionamento. Uma ligao uma associao entre dois registros. Assim, uma ligao pode ser vista como um relacionamento binrio no modelo ER [SILBERSCHATZ, 2006].

Tanto o Modelo Rede como o Modelo Hierrquico podem ser consi-derados como estruturas de dados em nvel lgico mais prximo do nvel fsico. Devido a essa proximidade ao nvel fsico, as estruturas de dados rede e hierrquica exibem as rotas lgicas de acesso de da-dos de forma acentuada, possibilitando a localizao lgica de um determinado registro no banco de dados.

O Modelo Relacional, quando comparado Estrutura Rede e Hierrqui-ca, mais orientado para modelagem do que como modelo com rotas de


18


acesso, embora possamos considerar as diversas redundncias existen-tes em diversas tabelas como sendo uma forma de rota de acesso.

O Modelo Rede utiliza como elemento bsico de dados a ocorrncia de registro. Um conjunto de ocorrncia de registro de um mesmo tipo determina um tipo de registro.

Um conjunto de tipos de registros relacionados entre si, por meio de re-ferncias especiais, forma uma estrutura de dados em rede. As refern-cias especiais so conhecidas como ligaes, que, por sua vez, podem ser implementadas sob a forma de ponteiros.

As referncias esto normalmente inseridas junto com as ocorrncias de registro; assim, todo o acesso a um prximo registro utiliza o ponteiro inserido no registro corrente disponvel.

Considere um banco de dados com registros de DEPARTAMENTO e EMPREGADO, em que EMPREGADO possui as seguintes caractersti-cas: matrcula, nome e cidade; e DEPARTAMENTO: cdigo e nome. A figura 3 mostra um exemplo do banco de dados, considerando os dois tipos de registros informados.

102 Gabriel Serra

01 Informtica

02 Geografia

03 Portugus

100 Luiza Vitria101 Matheus Vila Velha

103 Joana Aracruz

Figura 3 - Exemplo de Banco de Dados Modelo Redes.

O modelo de banco de dados da Figura 3 mostra as ligaes entre os registros de departamento e empregado. Luiza, por exemplo, est lotada no Departamento de Informtica, enquanto o Departamento de Geogra-fia, por exemplo, possui dois funcionrios lotados, Matheus e Gabriel.

1.8.2 Modelo hierrquico

Um banco de dados hierrquico consiste em uma coleo de registros relacionados, uns aos outros, por meio de ligaes, como no modelo em redes. A diferena entre eles se d pelo fato de o banco de dados hierrquico organizar esses registros como colees de rvores, em vez de grafos arbitrrios.

Um banco de dados hierrquico compe-se de um conjunto ordenado

Captulo 1

19

Banco de Dados I

de rvores, mais precisamente, de um conjunto ordenado de ocorrncias mltiplas de um tipo nico de rvore.

O tipo rvore compe-se de um nico tipo de registro raiz, juntamen-te com um conjunto ordenado de zero ou mais (nvel inferior) tipos de sub-rvores dependentes. Um tipo de subrvore, por sua vez, tambm se compe de um nico tipo de registro. A associao entre tipos de registros segue uma hierarquia estabelecida por diversos nveis. No pri-meiro nvel, o superior, situa-se o tipo de registro Raiz . Subordinado a ele, em nvel 2, uma srie de outros tipos de registros em nvel 2. A cada tipo de registro em nvel 2 subordina-se um outro conjunto de ti-pos de registros. A prpria estrutura hierrquica define as suas rotas de acesso, facilitando, portanto, a manuteno do banco de dados.

importante notar que um determinado tipo de registro B, num deter-minado nvel K, possui ligao com um e somente um tipo de registro A, de nvel K-1 (superior). Nessas condies, A denominado registro PAI de B, que, por sua vez, registro FILHO de A . No entanto, um tipo de registro A pode estar ligado a diversos filhos no nvel de B. Todas as ocorrncias de um dado tipo de filho que compartilham uma ocorrncia de pai comum so chamadas de gmeas.

Uma vantagem dos bancos de dados hierrquicos o tempo de resposta em consultas. No entanto, a atualizao pode ser bastante custosa. A figura 4 abaixo ilustra um exemplo do modelo Hierrquico.

01 Informtica01 Informtica

100 Luiza Vitria

01 Informtica02 Geografia

03 Portugus

102 Gabriel Serra

101 Matheus Vila Velha

103 Joana Aracruz

Figura 4 - Exemplo de Banco de Dados Modelo Hierrquico.

1.8.3 Modelo relacional

O modelo relacional, diferentemente dos modelos redes e hierrquico, usa um conjunto de tabelas para representar tanto os dados quanto a re-lao entre eles. As ligaes entre as tabelas feita por meio dos valores dos atributos ou colunas, conforme descrito posteriormente. Cada tabe-la possui mltiplas colunas e pode possuir mltiplas linhas. As tabelas 1 e 2 abaixo mostram exemplos de Tabelas do modelo relacional.


20


Tabela 1 - Tabela EMPREGADOS

Matricula Nome Cidade CodDepto01 Maria Vitria 0102 Matheus Vila Velha 0203 Gabriel Serra 0204 Joana Aracruz 03

Tabela 2 - Tabela DEPARTAMENTOS

CodDepto NomeDepto01 Informtica02 Geografia03 Portugus

1.8.4 Modelo objeto-relacional

O modelo objeto-relacional, tambm conhecido como relacional es-tendido, um modelo intermedirio entre o relacional e o orientado a objetos. Na verdade, os bancos de dados que se enquadram nesse mo-delo caracterizam-se por usar a estrutura bsica do modelo relacional, incorporando algumas caractersticas dos bancos de dados orientados a objetos. Estas caractersticas incluem : herana de tipos e tabelas e definio de novos tipos complexos. A SQL-99 inclui recursos para dar suporte a esse modelo de banco de dados.

1.8.5 Modelo Orientado a Objeto

O modelo relacional, hierrquico e redes foram muito bem sucedidos no desenvolvimento da tecnologia de banco de dados necessria para a maioria das aplicaes convencionais de bancos de dados comerciais, possuindo, entretanto, algumas limitaes quando aplicaes mais com-plexas precisam ser projetadas e implementadas, tais como sistemas de informaes geogrficas e multimdias. Essas aplicaes tm requisitos e caractersticas que as diferenciam das tradicionais aplicaes comer-ciais, tais como estruturas complexas para objetos, armazenamento de imagens e textos longos, dentre outras, alm da necessidade de definir operaes no convencionais [NAVATHE, 2005].

A abordagem orientada a objetos oferece a flexibilidade para lidar com alguns desses requisitos, sem estar limitada pelos tipos de dados e lin-guagens de consulta disponveis em sistemas de banco de dados tra-dicionais. Nesses bancos, o projetista especifica a estrutura de objetos complexos bem como as operaes que incidem sobre esses objetos.

Captulo 1

21

Banco de Dados I

Outra razo para o uso de banco de dados orientados a objetos a predo-minncia das linguagens orientadas a objetos. No caso de uma aplicao orientada a objetos utilizar um banco de dados relacional para persistir os dados, necessrio fazer um mapeamento entre esses dois mundos, o que d trabalho, considerando as limitaes impostas pelo modelo relacional.

Embora existam muitos benefcios para a adoo do modelo orientado a objetos, esses bancos de dados no foram muito bem aceitos no mer-cado em funo da simplicidade do modelo relacional. Com isso, h uma proposta de um modelo hbrido, denominado objeto-relacional ou relacional estendido, que se prope a implementar alguns conceitos de orientao a objetos sobre a estrutura de um banco de dados relacional. Alguns SGBDs proprietrios e livres disponveis no mercado enqua-dram-se nesse modelo, a exemplo do Oracle e do PostgreSQL.

1.9 Estrutura geral do sistema

O sistema de banco de dados dividido em mdulos especficos, de modo a atender a todas as suas funes, algumas delas fornecidas pelo sistema ope-racional. Esses mdulos podem ser organizados em dois grandes grupos: o de processamentos de consultas e o de administrao do armazenamento de dados. A Figura 5 mostra como esses componentes se relacionam.

1.9.1 Componentes de processamentos de consultas

Compilador DML: traduz comandos DML da linguagem de con-sulta em instrues de baixo nvel, inteligveis ao componente de execuo de consultas.

Interpretador DDL: interpreta os comandos DDL e registra-os em um conjunto de tabelas que contm metadados, ou seja, dados sobre dados.

Componentes para o tratamento de consultas: executam instrues de baixo nvel geradas pelo compilador DML.

1.9.2 Componentes para administrao do armazena-mento de dados

Gerenciamento de autorizaes e integridade: testa o cumprimento das regras de integridade e a permisso ao usurio no acesso aos dados.

Gerenciamento de transaes: garante que o banco de dados perma-necer em estado consistente, a despeito de falhas no sistema, e que


22


as transaes concorrentes sero executadas sem conflitos em seus procedimentos.

Gerenciador de arquivos: gerencia a alocao de espao no armazena-mento em disco e as estruturas de dados usadas para representar essas informaes armazenadas em disco.

Gerenciador de buffer: intermedia os dados entre o disco e a memria principal e decide quais dados colocar em cach.

1.9.3 Outras estruturas de dados

Diversas outras estruturas de dados so requeridas como parte da im-plementao do sistema fsico, incluindo:

Arquivo de Dados: armazena o banco de dados.

Dicionrio de Dados: armazena informaes sobre os dados do banco de dados.

ndices: permite o acesso mais rpido aos dados.

Estatsticas: armazenam informaes sobre o banco de dados e so usadas pelo seletor de estratgias.

Captulo 1

23

Banco de Dados I

Usurios Leigos(caixas, agentes,usurios da Web)

Interfaces deaplicao

Compitaldor elinkeditor

Programadoresde aplicao

Usuriosavanados(analistas)

Administrador debanco de adados

Programas deaplicao

Ferramentade consulta

Ferramentas deAdministrao

Consultas deDML

Interpretadorde DDL

Cdigo de objetos doprograma de aplicao

Gerenciador debuffer

Dados

Gerenciador dearquivos

Gerenciador deautorizao eintegridade

Gerenciador detransao

Indices Dicionrio de dados

Dados estatsitcos

usa escreve

Processador de consulta

Gerenciador de armazenamento

usa usa

Mecanismo de avaliaode consulta

Compilador e organizadorde DML

Armazenamento de disco

Figura 5 - Estrutura Geral do SistemaFonte: Silberschatz, Korth e Sudarshan, 2006. Adaptao.

1.10 Linguagem de definio de dados (DDL)

Contm a especificao dos esquemas dos bancos de dados. O resultado da compilao de uma consulta de definio de dados (DDL) armazenado em um conjunto de tabelas que constituem um arquivo especial chamado dicionrio de dados. Um dicionrio de dados um arquivo de metadados.

Principais comandos SQL-DDL: CREATE TABLE; ALTER TABLE; DROP TABLE; CREATE INDEX; ALTER INDEX; DROP INDEX;


24


1.11 Linguagem de manipulao de dados (DML)

A linguagem de manipulao de dados (DML) a linguagem que viabi-liza o acesso aos dados ou a sua manipulao de forma compatvel com o modelo de dados apropriado.

So responsveis pela:

recuperao da informao armazenada no banco de dados (SELECT); insero de novos dados nos bancos de dados (INSERT); eliminao de dados nos bancos de dados (DELETE); modificao de dados armazenados no banco de dados (UPDATE).

Os comandos DDL so responsveis por definir as estruturas dos dados, enquanto os comandos DML so responsveis por mani-pular os dados armazenados nessas estruturas!

1.12 Projetando bancos de dados

Antes de criarmos o banco de dados propriamente dito, devemos iden-tificar uma forma de planej-lo. Esse planejamento extremamente im-portante para a estabilidade de todo o sistema. Estudos indicam que quanto maior o tempo gasto no projeto do banco de dados, menor ser o tempo despendido na manuteno do modelo.

Podemos comparar a criao de um sistema de banco de dados com a cons-truo de uma casa. Imagine que seja construda uma casa sem que antes tenha sido feito um projeto de arquitetura, incluindo plantas baixas, cortes e fachadas. Provavelmente, no futuro, ao submeter essa casa manuteno, o proprietrio teria o inconveniente de construir quartos do lado da cozinha ou mesmo ter que fazer puxadinhas para realizar a ampliao da mesma. O mesmo acontece com sistemas mal-projetados ou no-projetados. Eles tornam-se pouco flexveis a manutenes futuras, quando for necessrio agregar novas informaes, ou mesmo quando submetidos a correes.

O processo de projetar um banco de dados inclui trs fases distintas e integradas. A primeira delas consiste na construo de um modelo con-ceitual. O Modelo Conceitual inclui caractersticas a serem includas no sistema, mas que independem da tecnologia a ser utilizada, tanto de banco de dados quanto de linguagem de programao. A segunda fase pressupe a construo de um modelo lgico, tendo como base o Mode-

Captulo 1

25

Banco de Dados I

lo Conceitual criado e inclui a definio de tabelas, campos, restries de integridade, etc. Neste modelo, considera-se a tecnologia do banco de dados a ser usado, como: relacional, orientado a objetos, etc. A ter-ceira fase, que extrapola a fase de projeto, consiste na criao fsica do banco de dados, tendo a preocupao com estruturas de armazenamento e recuperao dos dados a serem armazenados. Nos captulos que se seguem sero explorados a modelagem conceitual e o projeto lgico de banco de dados, considerando o modelo relacional.

ATIVIDADE 1

Faa os exerccios de fixao abaixo, referentes ao capitulo 1.

1) Defina SGBDs.

2) Cite duas desvantagens do uso de sistemas de arquivos em relao a SGBDs.

3) Defina uma vantagem de se usar sistemas de arquivos em relao a SGBD.

4) Cite as quatro arquiteturas de banco de dados existentes no mercado. Descreva, em poucas linhas, as caractersticas de cada uma delas.

5) Quais so os nveis de abstrao proporcionados por um SGBD? Enquadre, para cada grupo de usurio abaixo listados, o nvel em que o mesmo se encontra.

a. Administrador de Banco de Dadosb. Usurio de aplicaesc. Programador e Analista de Aplicaes

6) Liste, em ordem cronolgica, os modelos de bancos de dados existentes no mercado. Qual modelo de banco de dados ser utili-zado em nossa disciplina?


26


ATIVIDADE 2

1) Dadas as relaes abaixo, responda ao que se pede.

Funcionrios

matricula nome CPF cargo01 Ana 123 202 Maria 234 103 Jos 245 304 Pedro 125 105 Joana 435 206 Joo 467 1

Cargos

codigo nomeCargo01 Programador02 Topgrafo03 Engenheiro04 Pedreiro05 Motorista

Liste os nomes dos funcionrios para os seguintes cargos: Top-grafo; Engenheiro; Programador.

Para quais cargos no h funcionrios lotados?

2) Informe se cada uma das consultas abaixo ser executada pelo Compilador DML ou pelo Interpretador DDL.

a) create table...

b) create view...

c) insert into tabela...

d) alter table...

e) delete from tabela...

f) update tabela set campo 1 = valor 1, campo2 = valor2...

Captulo 1

27

Banco de Dados I

ATIVIDADE 3

1) Numere a segunda coluna de acordo com a primeira.

1. Possibilidade de erros de acesso concorrente

( ) Refere-se preciso ou validade dos dados.

2. Abstrao de dados ( ) Tarefa de um SGBD.

3. Integridade ( ) Se alterar o esquema conceitual, no necessrio reescrever aplicaes.

4. Instncia( ) Responsvel pela modi-ficao de dados armazena-dos no banco de dados.

5. Independncia lgica de dados

( ) Se alterar o esquema fsi-co, no necessrio reescrever aplicaes.

6. Independncia fsica de dados

( ) Contm a especificao dos esquemas de banco.

7. Controle de concorrncia

( ) Conjunto de informaes contidas em determinado banco de dados, em um deter-minado momento.

8. Linguagem de Definio de Dados (DDL)

( ) Trata-se de um modelo de banco de dados.

9. Linguagem de Manipulao de Dados (DML)

( ) Os usurios no precisam saber como os dados so arma-zenados e mantidos.

10. Objeto-Relacional ( ) Desvantagem de sistemas de arquivos.

O objetivo deste captulo foi de introduzir conceitos de bancos de dados. So conceitos importantes que serviro de base para enten-dimento dos conceitos explorados nos captulos subseqentes.


28


Ol!

Neste captulo voc estudar conceitos de modelagem conceitual de dados. Um modelo conceitual objetiva modelar os requisitos de ne-gcio segundo a viso do usurio, ou seja, independentemente de tecnologia. Trabalharemos, com especial destaque, com o Modelo de Entidade e Relacionamentos (ER).

Bom estudo!

Prof Claudinete Vicente Borges

2.1 Introduo

O principal objetivo da modelagem conceitual de dados construir mo-delos que representem os requerimentos das informaes do negcio, segundo a perspectiva do usurio. Partindo desse princpio, ao cons-truir modelos conceituais no h uma preocupao com a tecnologia a ser adotada para a sua implementao. Um modelo de dados consis-te em uma coleo de ferramentas conceituais para descrio de da-dos, relacionamento entre os dados, semntica e restries [SILBERS-CHATZ,2006]. Neste captulo, exploraremos o modelo de entidades e relacionamentos (ER) para construo de modelos de dados, conside-rando que se trata da tcnica de modelagem mais difundida para repre-sentao de modelos conceituais.

2.2 Modelos

Um modelo a representao abstrata e simplificada de um sistema real, com a qual se pode explicar ou testar o seu comportamento, em seu todo ou em parte. Observe que, nessa definio, no estamos condicionando que o modelo seja computadorizado. Qualquer ambiente do mundo real passvel de ser modelado, j que o mesmo busca expressar o objeto observado algumas vezes, mesmo antes da existncia fsica, tangvel de tal objeto. Seguem alguns exemplos de modelos:

MODELAGEM DE DADOS

30


as plantas de apartamentos dos jornais; o manequim da vitrine; um aeromodelo sendo usado para testes de aerodinmica; o desenho em perspectiva de uma nova cozinha; o molde de uma roupa obtido em uma revista.

O importante, contudo, perceber que atravs de algum meio, seja uma maquete, desenho ou descrio, pode-se antecipar ou substituir a exis-tncia de uma realidade qualquer.

2.3 Motivos para construo de modelos

Segundo Cougo [COUGO,1997], os principais motivos para elaborar-mos modelos so:

focalizar caractersticas importantes de sistemas, deixando de lado as menos importantes;

discutir alteraes e correes nos requisitos do usurio a baixo cus-to e com mnimo risco;

confirmar que o ambiente do usurio foi entendido; representar o ambiente observado; servir de instrumento de comunicao; favorecer o processo de verificao e validao; capturar aspectos de relacionamento entre os objetos observados; servir de referencial para a gerao de estruturas de dados.

2.4 Modelo de entidades e relacionamentos - E/R

O modelo ER uma tcnica de modelagem conceitual utilizada para re-presentar os dados a serem armazenados em um sistema de informao, tendo sido desenvolvida originalmente para dar suporte ao projeto de ban-cos de dados [CHEN,1990]. Esse modelo foi criado em 1976 por Peter Chen e pode ser considerado como padro para a modelagem conceitual.

Basicamente, o modelo ER representa as entidades (coisas) e os relacio-namentos (fatos) do mundo real, em que h o interesse de monitorar o comportamento no sistema de informao em tese.

Captulo 2

31

Banco de Dados I

2.4.1 Entidades

Entidades so representaes abstratas de coisas, objetos do mundo real modelado, para os quais temos interesse em manter informaes no banco de dados. Podem representar tanto objetos concretos quanto abstratos. Quando se trata de conjuntos de objetos com caractersticas semelhantes, usualmente se denomina conjunto de entidades. Por exem-plo: quando nos referimos ao conjunto de entidade Departamentos, estamos falando de um conjunto de departamentos; quando nos referi-mos ao departamento de informtica, estamos falando da entidade, de uma instncia do conjunto.

Um conjunto de entidades ser representado por meio de um retngulo contendo o nome do conjunto de entidades, em letra maiscula e no plural, conforme mostra exemplo da Figura 6.

A frase ...para os quais temos interesse em manter informaes no ban-co de dados... do pargrafo acima, significa dizer que um conjunto de entidades que relevante para um determinado contexto pode no ser para outro. O foco incluir no modelo apenas aqueles conjuntos de en-tidades que so de interesse para o contexto em questo. Por exemplo: considerando um sistema para uma biblioteca, no h porque modelar as cadeiras como um conjunto de entidades. Agora, se tratarmos de um sistema para controle de patrimnios, as cadeiras so alvo de controle, sendo, ento, modeladas como Conjunto de entidades.

Ex: FUNCIONRIOS, CARGOS, PESSOAS ...

FUNCIONRIOS CARGOS

Figura 6 - Exemplo de representao de conjunto de entidades

Caractersticas dos conjuntos de entidades [FALBO, 2009]:

so substantivos e perduram no tempo; cada elemento de um conjunto de entidades s ocorre uma nica

vez e a ordenao do conjunto irrelevante; a princpio so representados em um conjunto de entidades todos os

elementos do mundo real referidos pelo conjunto. Ex: FUNCION-RIOS = todos os funcionrios de uma empresa;

Modelagem de Dados

32


para estabelecermos uma padronizao, usaremos nomes de con-juntos de entidades sempre no plural e escritos em letras maiscu-las. No entanto, isso no representa uma regra.

2.4.2 Atributos

A identificao de entidades est diretamente relacionada necessidade de se armazenar dados (caractersticas ou propriedades) a seu respeito. Tais caractersticas ou propriedades so denominadas atributos. O papel do atributo o de descrever caractersticas ou propriedades relevantes de um conjunto de Entidades.

Os atributos podem ser representados no diagrama ou em um dicio-nrio de dados. Adotaremos esta ltima abordagem com o intuito de mantermos um modelo mais legvel.

Deseja-se que o processo de identificao de atributos alcance um elenco de atributos que sejam completos, fatorados e independentes [SHLAER,1990].

Completo: Deve abranger todas as informaes pertinentes ao objeto que est sendo definido. Os atributos devem contemplar todas as caractersticas que proporcionem uma perfeita identifi-cao das entidades s quais esteja associado. Assim, ao se defi-nir a entidade PESSOAS, deve-se prever todos os atributos que me permitam caracterizar completamente os elementos (pesso-as) que comporo esta entidade.

Ex.: Entidade: PESSOAS

Atributos: nome, rua, nmero, bairro, cidade, estado, uf, data de nascimento, sexo, estado civil.

Fatorado: cada atributo deve ser responsvel por um aspecto. No se deve agrupar responsabilidades acessrias aos atributos. Cada parte, cada caracterstica, deve significar um trao, uma particularidade da entidade e no estar agregando um conjunto de informaes em um nico elemento, em um nico atributo.


Atributos: nome, rua, nmero, bairro, cidade, estado, uf, data de nascimento, sexo, estado civil.

Captulo 2

33

Banco de Dados I

Note que o endereo est fracionado nas suas partes constituintes e no agrupado num nico elemento denominado endereo.

Independente: os valores que um atributo pode receber (dom-nio) devem ser independentes uns dos outros. Isso no significa que no possamos ter atributos distintos com o mesmo domnio. Cada atributo possui um conjunto dos possveis valores que pode assumir e isso independe dos demais atributos da entidade.


Atributos: data de nascimento

Domnio: deve ter as caractersticas de data e ser menor que a data corrente

Consideraes adicionais sobre os atributos:

Ainda sobre a identificao dos atributos, interessante que se distinga alguns elementos adicionais, conforme descritos abaixo. [POMPILHO, 2002]:

Atributos Monovalorados ou Univalorado: um atributo que recebe um nico valor para cada entidade. So atributos que possuem cardinalidade mxima 1.

Ex.: Entidade: FORNECEDORES

Atributos: cdigo, CNPJ, razo social, logradouro, n-mero, complemento, cidade, estado, cep

Atributos Multivalorados: um atributo que pode assumir v-rios valores para cada entidade, ao mesmo tempo.


Atributos: telefone(0,n)

Neste caso, um fornecedor pode ter nenhum ou vrios telefones.

Atributos Obrigatrios: um atributo que obriga a existncia de valor para cada entidade.


Atributos: cdigo, cnpj, razo social, logradouro, nme-ro, cidade, estado, cep

Modelagem de Dados

34


Atributos Opcionais: um atributo que NO obriga a existn-cia de valor para cada entidade. Normalmente so representados no dicionrio de dados entre parnteses.


Atributos: (complemento)

Atributo Composto: so atributos formados por um ou mais atributos, ou seja, so atributos que abrigam uma estrutura de dado. O atributo nome em uma entidade pessoa tambm pode-r ser visto como composto se for possvel e necessrio separ-los nas suas vrias partes (primeiro-nome, nome-intermedirio, ltimo-nome). Quando no so compostos, os atributos so de-nominados simples.


Atributos: endereo

Os atributos compostos sero representados no dicionrio de da-dos em maisculo e devero ser fatorados, como mostra o exem-plo abaixo no qual o ENDERECO um atributo composto:

FORNECEDORES = codigo + cnpj + razo social + EN-DERECO + telefone(0,n)

ENDERECO = logradouro + nmero + (complemento) + cidade + estado + CEP

Atributo Determinante ou Identificador: atributo que identi-fica, de modo nico, uma Entidade. Sero sublinhados no dia-grama como forma de distingui-lo dos demais. H quem j cha-me o atributo identificador de Chave Candidata. Por exemplo: a matrcula de um funcionrio pode ser um atributo identificador, considerando que cada funcionrio ter uma matrcula nica. O atributo nome, no entanto, no pode ser usado para identificar um funcionrio, considerando que existem homnimos.


Atributos cdigo

Captulo 2

35

Banco de Dados I

Domnio de um atributo: o conjunto dos possveis valores que um atributo pode assumir. No domnio de um atributo, especi-ficamos o Formato desse atributo, seu tamanho, os valores es-pecificamente. Por exemplo: um atributo nome para uma classe de entidades PESSOAS poder ter como domnio uma cadeia de caracteres, j o atributo sexo poder ter como domnio as opes Masculino ou Feminino.


Atributo: Sexo do Empregado

Domnio: Campo Alfanumrico, 1 caracter, s pode as-sumir os valores F e M

As figuras 7, 8 e 9 abaixo mostram exemplos de diferentes formas de representao de Diagramas de Entidades e Relacionamentos.

Atributos tambm descrevem caractersticas de relacionamentos, que veremos na prxima seo.

FORNECEDORES FORNECIMENTO PRODUTOStelefone

codigo codigo

cnpj nomepreco unt

razaosocial

endereco

rua

logradouro

numero

cidadeestado

cep

complemento

Figura 7 - Notao para Diagrama Entidade-Relacionamento proposto originalmente por Chen

Modelagem de Dados

36


DICIONRIOS DE DADOS

FORNECEDORES = + cnpj + razo social + ENDEREO + {telefone}PRODUTOS = + nome + preo unitENDEREO = RUA + cidade + estado + cepRUA = logradouro + numero + (complemento)

cdigocodigo

FORNECEDORES FORNECIMENTO PRODUTOS

Figura 8 - Notao alternativa para Diagrama Entidade-Relacionamento

FORNECEDORES FORNECIMENTO PRODUTOS

telefone (0,n)

codigocodigo

CNPJ nome

preco unit

razaosocial

endereo

rua

logradouro

nmero

cidadeestado

cep

complemento (0,1)

Figura 9- Outra notao para Diagrama Entidade-Relacionamento

2.4.3 Relacionamentos

Na seo anterior descrevemos atributos de conjuntos de entidades, que so propriedades dos objetos a serem armazenados em um banco de dados. Alm dos atributos, os conjuntos de entidades caracterizam-se por relacionar-se com outros conjuntos de entidades, inclusive com elas mesmas. A essas associaes denominamos relacionamentos, ou seja, conjunto de associaes entre entidades [HEUSER, 2004].

Neste texto adotaremos a seguinte notao: um relacionamento ser re-presentado por um losango, com um verbo para indicar a ao e uma seta para informar o sentido de leitura, conforme mostra a Figura 10 abaixo.

Captulo 2

37

Banco de Dados I

FUNCIONRIOS So enquadrados em CARGOS

Figura 10 - Exemplo de representao de relacionamento

A leitura feita para o relacionamento da Figura 10 funcionrios so enqua-drados em cargos. Todo relacionamento possui uma leitura inversa; assim, uma outra leitura do relacionamento seria cargos enquadram funcionrios.

O relacionamento existente entre os conjuntos de entidades funcion-rios e cargos um relacionamento binrio, pois se trata de uma associa-o entre dois conjuntos de entidades. Quando o relacionamento envol-ve trs conjuntos de entidades conhecido como ternrio.

Outros exemplos de relacionamentos:

Alunos cursam disciplinas / Disciplinas so cursadas por alunos; Editoras publicam livros / Livros so publicados por editoras; Autores escrevem livros / Livros so escritos por autores.

Para facilitar a visualizao foi construdo um diagrama de ocorrncia referente ao modelo ER da Figura 10. Esse diagrama se prope a mostrar as ocorrncias de entidades do conjunto funcionrios, representadas por : f1, f2, ..., fn; as ocorrncias do conjunto cargos, representadas por : c1, c2, .., cn e os relacionamentos existentes entre as entidades do conjunto de funcionrios e de cargos. O funcionrio f1 est enquadrado no cargo c1 atravs do relacionamento r1. O cargo c1, por outro lado, possui os funcionrios f1 e f3, nele enquadrados atravs dos relacionamentos r1 e r3. A figura 11 representa o diagrama de ocorrncia supra citado.

f1

r1

r2

r3

r4

r5

r6

r7

c1

c2

c3

f2f3f4f5f6f7

FUNCIONRIOS

ENQUADRAMENTOS

CARGOS

Figura 11 - Diagrama de ocorrnciasFonte: Heuser, 2004. Adaptao.

Modelagem de Dados

38


Entre duas entidades, podem existir vrios tipos de relacionamentos. A Figura 12 mostra os relacionamentos de alocao e de gerncia entre os mesmos conjuntos de entidades: FUNCIONRIOS e PROJETOS.

Gerenciam

FUNCIONRIOS So alocados em PROJETOS

Figura 12 - Entidades com dois tipos de relacionamento

Alm disso, uma entidade pode participar de relacionamentos com quaisquer outras entidades do modelo, inclusive com ela mesma, como mostra o relacionamento chefiam, na Figura13. Nesse caso, deno-mina-se que h um autorrelacionamento do conjunto de entidades FUNCIONRIOS.

Chefiam

Gerenciam

FUNCIONRIOS So alocados em PROJETOS

Figura 13 - Exemplo de autorrelacionamento

Cardinalidade de relacionamento

A cardinalidade indica o nmero mnimo (cardinalidade mnima) e mxi-mo (cardinalidade mxima) de ocorrncias possveis entre dois conjuntos de entidades em um relacionamento. No diagrama de ocorrncia da Figura 11, observa-se que um cargo pode enquadrar vrios funcionrios, enquanto que um funcionrio deve ser enquadrado em apenas um cargo.

A Figura 14 mostra a representao de cardinalidade no modelo ER. A leitu-

Captulo 2

39

Banco de Dados I

ra feita da seguinte forma: um funcionrio enquadrado em, no mnimo 1 e no mximo 1, cargo enquanto um cargo pode enquadrar no mnimo zero e no mximo n funcionrios. N um nmero arbitrrio. Quando conhece-mos esse nmero podemos represent-lo, em vez de o determinarmos pela letra N. Para efeito de projeto de banco de dados, o tratamento dado para esse nmero arbitrrio o mesmo, para qualquer valor maior que 1.

FUNCIONRIOS So enquadrados em CARGOS(0,n) (1,1)

Figura 14 - Ilustrao do uso de cardinalidade

Observe que, embora parea pouco natural, a cardinalidade vai anotada do outro lado do relacionamento a que se refere. No exem-plo acima, um funcionrio enquadrado, no mximo, em um car-go e um cargo, por sua vez, pode enquadrar at n funcionrios.

O relacionamento enquadram total em relao a FUNCION-RIOS e parcial em relao a CARGOS. Esse conceito baseado na cardinalidade mnima do relacionamento. Ele total em relao a FUNCIONRIOS, pois todo funcionrio participa do relacionamen-to pelo menos uma vez; e parcial em relao a CARGOS, pois pode existir um cargo que no participe do relacionamento nenhuma vez.

Tipos de Relacionamentos

O tipo de relacionamento uma classificao baseada na cardinalidade m-xima do relacionamento, podendo ser : 1:1, 1:N, N:1 e N:N. A seguir, sero explorados todos os tipos de relacionamentos sobre um relacionamento exis-tente entre os conjuntos de entidades : FUNCIONRIOS E PROJETOS.

Os tipos de relacionamentos podem ser enquadrados em 3 gran-des grupos, e l-se conforme descrio feita entre parnteses:

1:1 (Um-para-um),

1:N (Um-para-Muitos) e,

N:N (Muitos-para-Muitos).

Modelagem de Dados

40


Relacionamento 1:1

A Figura 15 mostra um exemplo de relacionamento do tipo 1:1 no qual cada Funcionrio ou Projeto podem aparecer no mximo em um nico par do relacionamento Gerenciam (Funcionrio, Departamento). Nesse caso, podemos dizer que um funcionrio pode gerenciar no mximo um proje-to, ou mesmo nenhum, enquanto um projeto s deve ter um gerente. A fi-gura 16 tem uma representao simblica deste tipo de relacionamento.

FUNCIONRIOS Gerenciam PROJETOS(1,1) (0,1)

Figura 15 - Exemplo de relacionamento 1:1

Figura 16 - Representao simblica do relacionamento 1:1 (um-para-um)

Observe que todo projeto gerenciado por algum funcionrio po-rm, nem todo funcionrio gerencia projetos. Esta informao dada pela cardinalidade mnima do relacionamento.

Relacionamento 1:N

A Figura 17 mostra um exemplo de relacionamento do tipo 1:N no qual cada Projeto pode aparecer no mximo em um nico par do relacio-namento Gerenciam, enquanto um Funcionrio pode aparecer em um nmero arbitrrio de vezes. Nesse caso, podemos dizer que um funcio-nrio pode gerenciar vrios projetos, enquanto um projeto s pode ter um gerente (tem que haver pelo menos 1!). A figura 18 tem uma repre-sentao simblica deste tipo de relacionamento.

Captulo 2

41

Banco de Dados I

FUNCIONRIOS Gerenciam PROJETOS(1,1) (0,n)

Figura 17: Exemplo de relacionamento 1:N

Figura 18 - Representao simblica do relacionamento 1:N (um-para-muitos)

Relacionamento N:N

A Figura 19 mostra um exemplo de relacionamento do tipo N:N no qual cada Funcionrio ou Projeto podem aparecer em um nmero arbitrrio de vezes do relacionamento Gerenciam. Nesse caso, podemos dizer que um funcionrio pode gerenciar vrios projetos, enquanto um projeto pode ter vrios gerentes. A figura 20 tem uma representao simblica deste tipo de relacionamento.

FUNCIONRIOS Gerenciam PROJETOS(1,n) (0,n)

Figura 19 - Exemplo de relacionamento N:N

Modelagem de Dados

42


Conjunto simblicoda entidade FUNCIONRIOS

Conjunto simblicoda entidade PROJETOS

Figura 20 - Representao simblica do relacionamento N:N (muitos-para-muitos)

Um outro conceito relacionado aos relacionamentos N:N o de En-tidade Associativa, tambm referenciada por alguns autores, como Agregao. Uma Entidade Associativa uma abstrao por meio da qual relacionamentos entre duas entidades so tratados como entidades em um nvel mais alto de abstrao. Essa nova entidade, a associativa, pode, ento, relacionar-se com outras entidades do modelo, como mos-tra a Figura 21. Um correntista uma agregao envolvendo os conjun-tos de entidades Clientes e Contas Correntes.

CLIENTESCONTAS

CORRENTES

CARTESMAGNTICOS

CORRENTISTAS

(1,N) (0,N)

(1,1)

(0,1)

so emitidos para

possuem

Figura 21 - Exemplo de agregao N:N [Falbo, 2009]

Os exemplos acima mostram os diferentes tipos de relaciona-mentos aplicados a conjuntos de entidades diferentes, porm tambm se aplicam a autorrelacionamentos.

Captulo 2

43

Banco de Dados I

Relacionamentos N:N geram Entidades Associativas e, estas, por sua vez, possuem os mesmos privilgios de um conjunto de enti-dades do modelo. Podem ter atributos e relacionar-se com outras entidades do modelo!

Atributos de Relacionamentos

Assim como as entidades, os relacionamentos tambm podem ter atri-butos, porm apenas os atributos de relacionamentos N:N so caracte-rizados como atributos de relacionamentos, enquanto os demais podem ser enquadrados em um dos conjuntos de entidades envolvidos no rela-cionamento [FALBO, 2009].

Para os relacionamentos N:N, h um teste que pode ser aplicado para se deduzir se um atributo de um dos dois conjuntos de entidades ou se do relacionamento. Tomemos como exemplo o modelo constante na figura 22. Este teste consiste no seguinte: fixa-se um material, como uma impressora, e variam-se os fornecedores desse material. Se o valor do atributo mudar ao variarmos o elemento do outro conjunto de enti-dades, porque este no atributo do primeiro conjunto de entidades, no caso MATERIAIS.

O Procedimento anlogo deve ser feito, agora, para a outra entidade. Fixando-se um fornecedor e variando-se os materiais temos: A Eletro-city vende uma impressora por R$ 350,00 e um microcomputador por R$ 2.000,00. O fato de o valor do atributo ter variado para a mesma entidade indica que ele no atributo de FORNECEDORES.

Se no atributo nem de MATERIAIS, nem de FORNECEDORES, ento um atributo do relacionamento entre os dois conjuntos de entidades.

fornecem

(0,N)

FORNECEDORES MATERIAIS(1,N)

Figura 22 - Exemplo de relacionamento N:N [Falbo, 2009]

Generalizao / Especializao de conjuntos de entidades

Por muitas vezes, inclumos nos modelos ERs conjuntos de entidades com diversas caractersticas em comum, diferenciando apenas em al-gumas delas. Nesse caso, usando o conceito de generalizao, pode-se

Modelagem de Dados

44


criar um conjunto de entidades genrico, contendo as caractersticas em comum, e especializam-se as demais com caractersticas parcialmente distintas. Um exemplo clssico o de pessoa fsica em jurdica. Observe que existem vrias caractersticas em comum entre ambas as pessoas, a exemplo de: nome, endereo e telefone. Uma pessoa fsica, no entanto, alm dessas caractersticas comuns, possui: sexo e CPF. Uma pessoa jur-dica, alm dessas caractersticas comuns, possui CNPJ e atividade princi-pal. A Figura 23 mostra a representao desse conceito no modelo ER.

CLIENTES

PESS0AS FSICASPESSOAS JURDICAS

Figura 23 - Exemplo de generalizao / especializao

As entidades PESSOAS FSICAS e PESSOAS JURDICAS herdam as ca-ractersticas de clientes e incorporam outras adicionais, que so peculia-res de cada um. Um cliente pode ser pessoa fsica, jurdica ou nenhum dos dois, mas toda pessoa fsica ou jurdica cliente.

Generalizao: entidades de um nvel mais baixo de abstrao, com caractersticas comuns, so agrupadas dando origem a uma entidade de nvel mais alto.

Especializao: uma entidade de nvel mais alto de abstrao desmembrada em vrias entidades de nvel mais baixo, com ca-ractersticas parcialmente distintas.

Captulo 2

45

Banco de Dados I

Entidade Fraca

Um outro conceito referenciado nos modelos ERs o de Entidade Fra-ca. Uma entidade fraca uma entidade que no tem existncia prpria. Ela s aparece no modelo quando relacionada a outra entidade inti-tulada como forte , sendo seus atributos identificadores compostos por, pelo menos, dois campos, sendo um deles um atributo da entidade forte. A Figura 24 mostra um exemplo em que o conjunto de entidades DEPENDENTES denominada entidade fraca. Para a identificao de um dependente necessrio que se tenha informao do scio. Os rela-cionamentos com essa caracterstica so denominados identificados.

SCIOS(1,1) (0,N)

Possuem DEPENDENTES

Figura 24 - Exemplo de entidade fraca

2.5 Dicionrio de dados

O Dicionrio de Dados uma listagem organizada de todos os elemen-tos de dados pertinentes ao sistema, com definies precisas para que os usurios e desenvolvedores possam conhecer o significado de todos os itens de dados manipulados pelo sistema.

Em se tratando de Modelos de Dados, essa listagem contm, em ordem alfabtica, as entidades e os relacionamentos com atributos de um DER.

Considerando que no h uma padronizao sobre a definio de di-cionrio de dados, no ser explorado neste material uma formulao na representao destes, mesmo por que as ferramentas CASE normal-mente incluem relatrios para gerao desses dicionrios.

Para complementar os conceitos discutidos at esta seo, indica-mos o livro Projeto de Banco de Dados, de Carlos Alberto Heuser, captulos 02 e 03.

Modelagem de Dados

46


2.6 Exemplo de um modelo de dados

A seguir eis um estudo de caso referente a um campeonato de frmula 1 e o modelo ER construdo para representar o cenrio supracitado.

Deseja-se desenvolver um sistema para controlar os resultados de um campeonato de corridas de Frmula 1. O sistema dever manter infor-maes sobre as equipes que participam do campeonato. De cada equi-pe deseja-se saber: cdigo e nome. Alm disso, necessrio controlar os pilotos que pertencem a cada equipe. De cada piloto deseja-se saber: cdigo, nome, data de nascimento, altura e peso. Ao longo do campeo-nato, um piloto pode pertencer a apenas uma equipe. Uma equipe, por outro lado, poder ter vrios pilotos (sendo este nmero mximo nor-malmente igual a 02 pilotos), podendo no ter nenhum, em um dado momento. necessrio ter um controle dos pases dos atletas (pilotos), dos quais deseja-se armazenar as seguintes informaes: uma sigla, o nome e o Hino Nacional. Um piloto sempre representa um pas, en-quanto que um pas pode ter vrios pilotos participando do campeonato ou at mesmo nenhum. Uma equipe tambm representa um pas, en-quanto que um pas pode ter vrias equipes participando do campeona-to ou mesmo nenhuma. Para cada corrida realizada, necessrio saber a data em que ocorreu, o nome do circuito, a durao em minutos, a relao de pilotos que participaram da prova e a posio que cada um obteve na corrida. Para caracterizar uma corrida necessrio que haja pelo menos 01 piloto habilitado a participar.

O primeiro passo para construo de um modelo identificar os ele-mentos do contexto para os quais temos o interesse de manter informa-es a respeito, ou seja, identificar os possveis conjuntos de entidades. Se fizermos uma leitura novamente do texto, iremos destacar os seguin-tes conjuntos de entidades: equipes, pilotos, pases e corridas. Lembre-se de que s faz sentido caracterizar um elemento como um conjunto de entidades se ele possuir atributos prprios!

Com relao ao conjunto de entidades Corridas, cabem algumas ob-servaes importantes. A primeira diz respeito relao de pilotos que participaram da prova. Observe que esta relao de pilotos no foi in-cluda como um atributo de corrida (verifique no dicionrio de dados) e sim como um relacionamento entre corridas. Se inclusse como atributo estaria sendo redundante, considerando que o modelo contempla um conjunto de entidades denominado Pilotos. A segunda observao refere-se a posio que cada um obteve na corrida, a qual, embora es-teja no texto referenciado quando trata-se da corrida em si, mas esta informao est relacionada ao piloto e a corrida, ou seja, ao relaciona-mento entre estes dois conjuntos de entidades.

Captulo 2

47

Banco de Dados I

A figura 25 mostra o modelo ER correspondente ao contexto descrito anteriormente.

PILOTOS(0,n) (1,1)

(0,n)

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

(0,n)

EQUIPES

PAISESCORRIDAS

participam de

participaes

so de

Possuem

So de

(1,n)

Figura 25 - Modelo ER referente ao estudo de caso Campeonato de Frmula 1

Dicionrio de Dados:

EQUIPES = codEquipe + nomeEquipe

PILOTOS = codPiloto + nomePiloto + dtNascimento + Altura + Peso

PAISES = codPais + sigla + nome

CORRIDAS = codCorrida + dtCorrida + duracaoProva + nomeCircuito

PARTICIPACOES = posicaoPilotoProva

O dicionrio de dados acima representa em estilo sublinhado os atributos determinantes para cada conjunto de entidades.

Modelagem de Dados

48


Ao construirmos modelos de dados comum termos dvida sobre a representao de conjuntos de entidades, como no exemplo a se-guir: se estamos construindo um modelo para uma locadora de v-deo, a Locadora dever ser modelada como sendo um conjunto de entidades? Se estamos construindo um modelo para uma Escola, a Escola dever ser modelada como sendo um conjunto de entidades? Em ambos os casos a resposta No! Se no primeiro caso tratar de uma rede de locadoras, a sim devemos modelar a locadora como um conjunto de entidades, mas se for apenas uma, no faz sentido. Seria construir um conjunto de entidades para representar uma entidade apenas! O mesmo raciocnio vale para o segundo caso, o da Escola.

2.7 Ferramentas case

Voc deve estar se perguntando como desenhar um diagrama ER. Ser no Paint ou mo? A resposta simples: existem vrias ferramentas computadorizadas destinadas a auxiliar na construo de modelos e projetos de bancos de dados, as quais so denominadas ferramentas CASE. Dentre outras, podemos citar Doctor CASE, ERWin e brModelo. Esta ltima uma ferramenta desenvolvida sob a orientao do profes-sor Carlos Heuser, professor de Banco de Dados da UFRGS, e encontra-se disponvel para download na Internet. Embora seja uma ferramenta simples, permite trabalharmos com a construo de modelos conceitu-ais e lgicos (tratados no prximo captulo).

2.8 Modelo ER estendido - EER

O modelo ER possui um poder de expresso muito grande, principal-mente quando se trata de modelagem de aplicaes convencionais, po-rm alguns recursos so mais bem representados por extenses feitas ao modelo bsico. Recursos estes necessrios para modelagem de aplicaes mais complexas, como Sistemas de Informaes Geogrficas e CAD.

Vrios modelos semnticos de dados tm sido propostos na literatura, sen-do denominados de modelo ER estendidos ou EER. No h uma notao padro para representao desses modelos, como ocorre com a UML.

Segundo Navathe Navathe [NAVATHE, 2005], o modelo EER engloba todos os conceitos do modelo ER bsico, acrescidos dos conceitos de subclasse e superclasse, especializao e generalizao, tipo unio e herana de atributo/relacionamento.

Captulo 2

49

Banco de Dados I

Uma boa leitura para complementar os conceitos tratados nesta se-o o livro Sistemas de Banco de Dados, de Esmasri e Navathe, ca-ptulo 4, que descreve uma forma de representao do modelo EER.

Este captulo teve como objetivo o de apresentar conceitos relaciona-dos com modelagem conceitual de dados. Ressalto que os modelos conceituais representam os requisitos de negcio independente de tecnologia. No captulo seguinte, trabalharemos com projeto lgico de banco de dados. Para estes, algumas caractersticas tecnolgicas sero consideradas.

Modelagem de Dados

50


Ol!

Neste captulo voc estudar conceitos de projeto lgico de banco de dados. Um modelo lgico faz uma adequao do modelo conceitual, incluindo restries tecnolgicas, impostas pelo modelo de banco de dados a ser usado. Trata-se de um modelo com maior nvel de deta-lhe do que o conceitual.

Bom estudo!

Prof Claudinete Vicente Borges

3.1 Definio

Quando construmos um modelo conceitual, focamos apenas no que o usurio deseja, abstraindo da plataforma em que este ser implementado. No que se refere aos projetos de Banco de Dados, a preocupao centra-da em estabelecer de que forma os dados sero armazenados no sistema. Em funo do modelo de banco de dados a ser usado, diferentes solues de projeto devem ser adotadas, ou seja, se o software for implementado em um banco de dados hierrquico, por exemplo, um modelo hierrquico deve ser produzido, adequando-se a modelagem conceitual de dados (ER ou diagrama de classes) a essa plataforma de implementao.

Considerando que o modelo de banco de dados que predomina no mer-cado, atualmente, o relacional, este captulo se prope a discutir con-ceitos de projetos relacionados a esse modelo de bancos de dados.

3.2 Estrutura dos bancos de dados relacionais

O modelo relacional consolidou-se no mercado por ser flexvel, de sim-ples compreenso. Est fortemente baseado na teoria matemtica sobre relaes, da o nome relacional.

Um banco de dados relacional consiste em uma coleo de tabelas, cada uma das quais com um nome nico. Uma linha em uma tabela repre-senta um relacionamento entre um conjunto de valores. Uma vez que

PROJETO LGICO DE BANCO DE DADOS

52


essa tabela uma coleo de tais relacionamentos, h uma estreita cor-respondncia entre o conceito de tabela e o conceito matemtico de re-lao, da a origem do nome desse modelo de dados.

Considere a tabela EMPREGADOS Tabela 3. Ela possui trs colu-nas: matrcula, nome e cidade. Seguindo a terminologia do modelo re-lacional, tratamos os nomes dessas colunas como atributos. Para cada atributo h um conjunto de valores permitidos, chamado domnio da coluna em questo. Para o atributo Matricula, por exemplo, o domnio o conjunto de todas as matrculas de funcionrios. Suponha que D1 denote esse conjunto, D2 o conjunto de todos os nomes de pessoas e D3 o conjunto de todas as cidades. Qualquer linha da tabela EMPREGA-DOS consiste necessariamente de uma tupla (v1, v2, v3), em que v1 a matricula, (isto , v1 est no domnio D1), v2 um nome do funcion-rio e assim por diante. Em geral, um empregado um conjunto de D1 x D2 x D3.

Tabela 3 - Tabela EMPREGADOS

matricula nome cidade01 Maria Vitria02 Matheus Vila Velha03 Gabriel Serra04 Joana Aracruz

Matematicamente, define-se uma relao como um subconjunto de um produto cartesiano de uma lista de domnios. Essa definio corres-ponde quase exatamente definio de uma tabela. A nica diferena que designamos nomes aos atributos, ao passo que matematicamente se usam apenas nomes numricos. Como as tabelas em essncia so relaes, podemos usar os termos matemticos relao e tupla no lugar de tabela e linhas, respectivamente.

possvel que tenhamos, em uma mesma tabela, atributos dife-rentes criados sob o mesmo domnio, a exemplo de Endereo de correspondncia e Endereo comercial (se existissem nessa tabela EMPREGADOS).

Um valor de domnio que pertence a qualquer domnio possvel o valor nulo, que indica que um valor desconhecido ou no existe. Por

Captulo 3

53

Banco de Dados I

exemplo, suponhamos que incluamos o atributo numeroTelefone na ta-bela Empregado, pode ser que um Empregado no possua telefone ou que o seu nmero seja desconhecido.

3.3 Chaves

importante especificar como as entidades dentro de um dado conjun-to de entidades podem ser identificadas. Conceitualmente, entidades e relacionamentos individuais so distintos, entretanto, na perspectiva do banco de dados, a diferena entre ambos deve ser estabelecida em termos de seus atributos. O conceito de chaves nos permite fazer tais distines.

Uma superchave um conjunto de um ou mais atributos que, tomados coletivamente, permitem identificar, de maneira unvoca, uma entidade em um conjunto de entidades. Considere a incluso de uma nova coluna na tabela EMPREGADOS, o (CPF) do empregado. Os atributos (matricu-la, nome) e (nome, CPF) so suficientes para distinguir cada elemento do conjunto, podendo ser considerados como superchaves. Da mesma forma, podemos considerar o atributo (CPF) como superchave de empregado. O atributo (nome) no pode ser considerado como superchave, porque algumas pessoas podem ter o mesmo nome. Nosso interesse maior por superchaves para as quais nenhum subconjunto possa ser uma supercha-ve. Essas chaves so chamadas de chaves candidatas. Das superchaves mencionadas anteriormente, somente (nome, CPF) no poderia ser con-siderada uma chave candidata, visto que o CPF, sozinho, j o .

Podemos usar o termo chave primria para caracterizar a chave candidata, que escolhida pelo projetista do banco de dados como de significado prin-cipal para a identificao de entidades dentro de um conjunto de entidades. Quaisquer duas entidades individuais em um conjunto de entidades no podem ter, simultaneamente, os mesmos valores em seus atributos-chave.

Em SGBDs, apenas os conceitos de chaves primrias e chaves candida-tas so de fato implementados!

A tabela 4 mostra uma listra de atributos de uma relao Alunos e um indicativo da possibilidade destes serem considerados atributos-chaves. Cabe ressaltar que os atributos implementados como Chave Candida-ta so atributos possveis de serem implementados como Chave Pri-mria, porm, pode-se criar um atributo extra, como por exemplo um nmero seqencial para ser a chave primria da tabela.

Projeto Lgico de Banco de Dados

54


Tabela 4 - Exemplo de atributos chave

Atributos Superchave Chave Candidata Chave Primriamatricula CPF (CI, UF) (CPF,Nome) X X

Em uma mesma tabela pode haver mltiplas chaves candidatas, a exemplo de (matrcula) e (CPF) de EMPREGADOS. No que se refere chave primria, apenas uma possvel.

Uma chave candidata pode assumir um valor nulo (apenas um, pois do contrrio haveria repetio de valores). Uma chave prim-ria no pode assumir valor nulo.

Alguns autores defendem que uma chave primria seja escolhida entre as chaves candidatas de uma tabela. Eventualmente, pode-se adotar uma soluo de projeto em que a chave primria no seja escolhida entre as chaves candidatas e sim um atributo que no diz respeito ao negcio em si. Particularmente, prefiro adotar essa so-luo. importante lembrar a todos que o negcio muda e com isso os valores dos atributos tambm. Uma alterao feita em valores de chaves primrias implica propagao para inmeras tabelas rela-cionadas, o que pode ser muito custoso.

Um outro conceito de chave, que muito ser explorado neste material, o conceito de chave estrangeira. Uma chave estrangeira um atributo (ou combinao de atributos) de uma tabela que constitui a chave primria de uma tabela, da o nome de estrangeira. a estratgia usada para imple-mentar os relacionamentos dos modelos conceituais. Essa tabela referen-ciada pode ser a prpria tabela, para os casos de autorrelacionamento, ou outras quaisquer do modelo. Outras denominaes tambm so usadas para essas chaves, a exemplo de chaves externas e chaves transpostas. A Ta-bela 5 mostra um exemplo de chave estrangeira, o codDepto. Os valores possveis para essa coluna devem constar na Tabela referenciada por esse atributo, no caso, a de DEPARTAMENTOS. Alm desses valores, depen-dendo do modelo de dados, nulo pode ser um valor possvel.

Captulo 3

55

Banco de Dados I

Tabela 5 - Tabela EMPREGADOS, destacando a chave estrangeira (codDepto)

matricula nome cidade codDepto01 Maria Vitria 0102 Matheus Vila Velha 0203 Gabriel Serra 0204 Joana Aracruz 03

Tabela 6 - Tabela DEPARTAMENTOS

codDepto nomeDepto01 Informtica02 Geografia03 Portugus

3.4 Propriedades do modelo relacional

Falbo [FALBO,2009] relaciona as seguintes propriedades do modelo relacional:

nenhum campo componente de uma chave primria pode ser nulo; cada clula de uma relao pode ser vazia (exceto de uma chave pri-

mria) ou, ao contrrio, conter no mximo um nico valor; a ordem das linhas irrelevante; no h duas linhas iguais; cada coluna tem um nome e colunas distintas devem ter nomes

distintos; usando-se os nomes para se fazer referncia s colunas, a ordem de-

las torna-se irrelevante; cada relao recebe um nome prprio distinto do nome de qualquer

outra relao da base de dados; os valores de uma coluna so retirados todos de um mesmo conjun-

to, denominado domnio da coluna; duas ou mais colunas distintas podem ser definidas sobre um

mesmo domnio; um campo que seja uma chave estrangeira ou um item transposto s

pode assumir valor nulo ou um valor para o qual exista um registro na tabela em que ela chave primria.


56


3.5 Traduo do modelo ER para o relacional

O objetivo desta seo apresentar como se procede na elaborao do projeto lgico de bancos de dados relacionais a partir de modelos con-ceituais no caso o ER. O modelo lgico um modelo menos abstrato que o conceitual e prov um nvel maior de detalhes. Para os diferentes modelos de bancos de dados (redes, hierrquicos, relacionais...) diferen-tes solues de projetos devem ser adotadas. Assim, este material ter como foco apenas o projeto de banco de dados relacional.

A traduo do modelo ER para o relacional seguir os seguintes passos:

mapeamento das entidades e atributos; mapeamento dos relacionamentos, considerando cada tipo {1:1,

1:N, N:N}; mapeamento de generalizaes e especializaes; mapeamento de atributos multivalorados.

Diferentes autores usam diferentes representaes para a especifica-o dos modelos lgicos de bancos de dados relacionais, sendo alguns representados de forma grfica e outros textuais. A abordagem usada neste material ser a de Carlos Heuser [HEUSER,2004], que usa uma notao resumida para definio do esquema, denominado Esquema Relacional, contendo as seguintes informaes :

tabelas que formam o banco de dados; colunas que compem cada tabela; restries de integridade (no caso, apenas as restries referentes s

chaves primrias e estrangeiras so representadas).

Para o exemplo das Tabelas 5 e 6 (EMPREGADOS e DEPARTAMEN-TOS), teremos a seguinte representao:

Empregados (matricula, nome, cidade, codDepto)

codDepto referencia Departamentos

Departamentos (codDepto , nomeDepto)

Os atributos sublinhados representam as chaves primrias das tabe-las Empregados e Departamentos, respectivamente. CodDepto uma chave estrangeira e que referencia a chave primria da tabela Departa-mentos. Para os casos das chaves estrangeiras compostas, a representa-

Captulo 3

57

Banco de Dados I

o fica da seguinte forma: (coluna1, coluna2, ... colunaN) referencia .

A fim de facilitar o entendimento, sero usados os mesmos exemplos de modelos descritos no captulo 2 para exemplificar os diferentes tipos de relacionamentos. Consideremos tambm os atributos abaixo listados para os conjuntos de entidades Funcionrios e Projetos, pois a opo foi de no represent-los no modelo ER.

Funcionarios = matrcula + nome + cidade + data de admisso

Projetos = cdigo + nome + data de incio

Seguindo os passos para elaborao do modelo conceitual temos, como passo 1, a definio das Tabelas que formam o banco de dados. Via de regra, todo conjunto de entidades gerar uma tabela no banco de dados relacional. As excees sero tratadas, quando ocorrerem. Com relao nomenclatura usada na tabela, ela no deve, necessariamente, ser a mesma do conjunto de entidades, considerando que no pode haver espaos em branco e que deve-mos evitar nomes extensos para facilitar o trabalho dos programadores.

No que se refere aos atributos dos conjuntos de entidades, eles devem ser mapeados em colunas das respectivas tabelas, porm, h algumas dire-trizes para definio dessas colunas, conforme especificaes a seguir:

evite usar nomes extensos. Ao fazer referncia ao nome de uma co-luna, normalmente escreve-se nomedaTabela.nomedaColuna o que estende ainda mais o nome do atributo;

considerando que a referncia s colunas ocorre do modo acima descrito, no se faz necessrio incluir o nome da tabela nos nomes das colunas dessas tabelas. A exemplo da coluna (nome), da tabela PROJETOS, algumas pessoas escrevem Nome_Projeto;

crie padres de projeto para dar nomes s colunas, a exemplo de dtAdmissao e dtInicio. Evite usar prefixos diferentes para colunas com mesmo tipo de informao, como: Data_Admisso e dtInicio;

ao definir a chave primria, escolha a coluna ou combinao des-tas colunas com o menor tipo de dados possvel. Sobre os campos chaves, seja chave primria, candidata, seja estrangeira, so criados ndices, e esses ndices ocupam muito espao em disco;

embora devamos evitar redundncias nos modelos conceituais, a re-dundncia, muitas vezes, til em um banco de dados por questes de performance. Por exemplo: o valor de um pedido pode ser obtido por meio dos valores dos seus itens, porm, se guardarmos o valor to-tal do pedido como uma coluna na tabela de pedidos, evitamos alguns acessos a disco, melhorando, assim, a performance das aplicaes.


58


Notao resumida para especificao de banco de dados relacional:

tabelas que formam o banco de dados;

colunas que compem cada tabela;

restries de integridade (no caso, apenas as restries refe-rentes s chaves primrias e estrangeiras so representadas).

Os relacionamentos do modelo conceitual ER so mapeados em chaves estrangeiras em um banco de dados relacional. Via de regra, para cada relacionamento uma chave estrangeira deve ser criada.

Eu, particularmente, no uso acentuaes e cedilhas em nomes de tabelas, colunas ou quaisquer outros objetos de um banco de dados. Com isso, evito transtornos com teclados desconfigurados.

3.5.1 Relacionamento 1:1

Considerando o relacionamento Gerenciam, da Figura 26, a melhor soluo de projeto a se considerar : incluir a chave estrangeira na relao PROJE-TOS, em vez de coloc-la em empregados, derivando o seguinte esquema :

Funcionarios (matricula, nome, cidade, dtAdmissao)

Projetos (codigo, nome, dtInicio, matriculaGerente)

matriculaGerente referencia Funcionrios

FUNCIONRIOS(1,1) (0,1)

Gerenciam PROJETOS

Figura 26 - Exemplo de relacionamento 1:1

Essa soluo foi adotada, considerando-se que todo projeto tem um gerente; porm, nem todo funcionrio gerencia um projeto. Ainda assim, se a chave estrangeira fosse criada em Funcionrios, no teramos pro-

Captulo 3

59

Banco de Dados I

blemas na implementao dessa soluo, embora essa no seja a melhor abordagem.Se o relacionamento Gerenciam fosse total em relao a Funcionrios e a Projetos, ou seja, se a cardinalidade mnima fosse 1 (um) para ambos, po-deramos optar por criar uma nica tabela contendo todos os atributos.

3.5.2 Relacionamento 1:N

Para os relacionamentos 1:N deve-se criar a chave estrangeira na tabela que representa o conjunto de entidades cuja cardinalidade mxima 1. No caso da Figura 27, a chave estrangeira deve ser colocada em Projetos, pois cada projeto participa do relacionamento Gerenciam no mximo 1 (uma) vez. O esquema gerado fic

banco de dados i-prof. claudinete vicente borges ferreira

Documents