Banco de Dados

Professor: Paula Patrcia Reinaldo Monteiro Cotrim

INDICE
INDICE DE FIGURAS .................................................................................................. 3 1 2 INTRODUO ...................................................................................................... 4 CONCEITOS BSICOS........................................................................................ 5 2.1 2.2 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4 BANCO DE DADOS ............................................................................................... 5 DADO, INFORMAO, CONHECIMENTO E SABEDORIA .......................................... 7 PRIMEIRA FASE ................................................................................................... 9 SEGUNDA FASE ................................................................................................... 9 TERCEIRA FASE ................................................................................................. 10 QUARTA FASE ................................................................................................... 10 CONSEQNCIAS DO USO DE SGBD.................................................................. 11 NVEIS DA ARQUITETURA DE UM SGBD (PADRO ISO) ................................... 12 TIPOS DE USURIOS DE BD ............................................................................... 12 2

EVOLUO NO TRATAMENTO DOS DADOS .............................................. 9

MODELOS LGICOS DE SGBDS ................................................................... 14 4.1 MODELO HIERRQUICO ..................................................................................... 14 4.2 MODELO EM REDES ........................................................................................... 15 4.3 MODELO RELACIONAL ...................................................................................... 15 5.5.1 Relao ..................................................................................................... 16 5.5.1 Chaves ...................................................................................................... 16 4.4 MODELO ORIENTADO A OBJETOS ...................................................................... 16

MODELAGEM DE DADOS UTILIZANDO MER .......................................... 17 5.1 ENTIDADES E ATRIBUTOS ................................................................................. 18 5.2 ESTRUTURA BSICA DE BD, CONJUNTO DE VALORES E ATRIBUTO CHAVE ........ 19 5.3 RELACIONAMENTOS .......................................................................................... 19 5.5.1 Grau de um Relacionamento .................................................................... 20 5.3.2 Outras caractersticas de um relacionamento ........................................... 20 5.3.2.1 Relacionamentos com Atributos ........................................................... 20 5.3.2.2 Restries em Tipos Relacionamentos .................................................. 22 5.3.2.3 Tipos Entidades Fracas ........................................................................ 24 5.4 DIAGRAMA ENTIDADE RELACIONAMENTO - DER ............................................ 26 5.5 NORMALIZAO ............................................................................................... 27 5.5.1 Primeira Forma Normal 1FN................................................................. 27 5.5.2 Segunda forma normal 2FN .................................................................. 27 5.5.3 Terceira forma normal 3FN ................................................................... 28 5.5.4 Quarta forma normal 4FN ..................................................................... 28

6 7

MODELO FSICO DE BANCO DE DADOS.................................................... 29 LINGUAGENS DE BANCO DE DADOS .......................................................... 29

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

INDICE DE FIGURAS
Figura 1 Dado, informao, conhecimento e sabedoria ............................................................ 7 Figura 2 Primeira fase do tratamento dos dados ....................................................................... 9 Figura 3 Segunda fase do tratamento dos dados....................................................................... 9 Figura 4 Terceira fase do tratamento dos dados ..................................................................... 10 Figura 5 Quarta fase do tratamento dos dados ....................................................................... 11 Figura 6 Tabelas do modelo relacional..................................................................................... 15 Figura 7 Etapas de um projeto de banco de dados .................................................................. 18 Figura 8 Relacionamento entre entidades ............................................................................... 20 Figura 9 Relacionamentos com atributos................................................................................. 21 Figura 10 Relacionamento recursivo ........................................................................................ 21 Figura 11 - Cardinalidade ............................................................................................................ 22 Figura 12 Relacionamento N:N ................................................................................................ 23 Figura 13 Entidade fraca........................................................................................................... 24 Figura 14 Relacionamento ternrio.......................................................................................... 25 Figura 15 Objetos de DER ......................................................................................................... 26

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

INTRODUO Para resolver o problema da carncia de literatura destinada ao ensino de Banco

de Dados e SQL para os nossos estudantes, elaboramos a presente apostila, que no possui a inteno de esgotar to abrangente volume de informaes, servindo somente para estabelecer um mnimo de conhecimentos destinados a introduzir o estudante no mundo dos Gerenciadores de Banco de dados e da linguagem SQL - Structured Query Language ou Linguagem de Consulta Estruturada. 4

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

2 2.1

CONCEITOS BSICOS Banco de dados Todos ns sabemos existirem gigantescas bases de dados gerenciando nossas

vidas. De fato sabemos que nossa conta bancria faz parte de uma coleo imensa de contas bancrias de nosso banco. Nosso ttulo eleitoral ou nosso cadastro de pessoa fsica, certamente esto armazenados em bancos de dados colossais. Sabemos tambm que quando sacamos dinheiro no caixa eletrnico de nosso banco, nosso saldo e as movimentaes existentes em nossa conta bancria j esto nossa disposio. Estes bancos de dados, alm de manterem todo este volume de dados organizado, tambm devem permitir atualizaes, incluses e excluses do volume de dados, sem nunca perder a consistncia. E no podemos esquecer que na maioria das vezes estaremos lidando com acessos concorrentes a vrias tabelas de nosso banco de dados, algumas vezes com mais de um acesso ao mesmo registro de uma mesma tabela. Um banco de dados contm os dados dispostos numa ordem pr-determinada em funo de um projeto de sistema, sempre para um propsito muito bem definido. Um banco de dados representar sempre aspectos do mundo real. Assim sendo uma base de dados (ou banco de dados, ou ainda BD) uma fonte de onde poderemos extrair uma vasta gama de informaes derivadas, que possui um nvel de interao com eventos como o mundo real que representa. Um banco de dados pode ser definido como um conjunto de dados devidamente relacionados. Por dados podemos compreender como fatos conhecidos que podem ser armazenados e que possuem um significado implcito. Porm, o significado do termo banco de dados pode significar algo mais que a definio acima. Um banco de dados possui as seguintes propriedades: um banco de dados uma coleo lgica coerente de dados com um significado inerente; um banco de dados projetado, construdo e populado com dados para um propsito especfico; um banco de dados possui um conjunto pr definido de usurios e aplicaes;
Banco de Dados Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

 um banco de dados representa algum aspecto do mundo real, o qual chamado de mini-mundo ou mundo real; qualquer alterao efetuada no minimundo automaticamente refletida no banco de dados. Um banco de dados pode ser criado e mantido por um conjunto de aplicaes desenvolvidas especialmente para esta tarefa ou por um Sistema Gerenciador de Banco de Dados (SGBD). Um SGBD permite aos usurios criarem e manipularem bancos de dados de propsito geral. O conjunto formado por um banco de dados mais as aplicaes que manipulam o mesmo chamado de Sistema de Banco de Dados. 6

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

2.2

Dado, informao, conhecimento e sabedoria Dado: uma abstrao que representa um contedo elementar, fato isolado,

como voc observa no mundo real. Um nome, uma data, um nmero, um conceito, uma instruo, uma imagem, um CPF etc. so dados. O valor do dado no tem qualquer julgamento ou interpretao dos eventos, nem qualquer base para ao. S forma um conjunto de smbolos desprovido de significado isolado. Mas, os dados so vitais, pois deles se obtm a informao. Um item de dado criado, auditado, atualizado e usado por muitos usurios diferentes. Voc no tem como conhecer a variedade de usos de um dado ao longo do tempo. Veja o exemplo: 100 pode ser o custo de um produto em reais, o nmero em fila de espera, a representao binria do decimal 4 etc. A interpretao do dado o transforma em informao. Informao: Voc extrai informao, obtendo conhecimento til ao usurio, organizando, correlacionando e interpretando dados, seja para agir, seja para decidir. A informao faz parte do dia-a-dia; ela est em arquivos, em papis e na cabea das pessoas. a estrutura bsica de um sistema de informao. Exemplo: resposta consulta Quais os clientes de So Jos?. 7

Figura 1 Dado, informao, conhecimento e sabedoria

Reflita: Qual a importncia da informao? Compare a perda de um equipamento, depsito ou fbrica com a perda da especificao de um produto ou tecnologia (como se faz a coca-cola, a pepsi, como se obtm a energia nuclear e funciona o motor, a exploso etc.).

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

Conhecimento: informao valiosa da mente humana. Inclui reflexes, sntese e contexto de difcil estruturao, captura em mquinas e transferncia. Nesse caso, a dificuldade est no fato de ser produzido no crebro humano, a partir de percepes individuais que o detentor do conhecimento faz, mediante suas experincias de vida, aplicao aos estudos, aprofundamento de leituras, enfim, de sua conduta pessoal em relao ao aprendizado. Como isso varia de pessoa a pessoa, o capital intelectual torna-se um grande diferencial competitivo das empresas, que devem investir na formao e aprimoramento de seus funcionrios. Sabedoria: o acmulo de dados, informaes e conhecimentos, agregados e acumulados de forma equilibrada e consciente pelo ser humano, de acordo com a experincia individual. 8

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

3 3.1

EVOLUO NO TRATAMENTO DOS DADOS Primeira fase Nesta fase os dados so tratados por aplicao. Somente a aplicao possui acesso

aos dados, pois a estrutura dos registros encontra-se definida no cdigo fonte da aplicao. Por causa disso os problemas de tratamento (acesso) dos dados, comuns a qualquer aplicao, precisam ser resolvidos (administrados) pela prpria aplicao. 9 Caractersticas:
Figura 2 Primeira fase do tratamento dos dados

Arquivos por aplicao isolada; Estrutura dos arquivos definida

na prpria aplicao; No h integrao.

3.2

Segunda fase Sendo uma evoluo da primeira fase e forada pela necessidade dos usurios, nesta

segunda fase os dados continuam sendo armazenados em arquivos e tratados por aplicao. No entanto j h uma preocupao dos desenvolvedores em integrar as aplicaes possibilitando a troca de dados entre elas. Caractersticas: Integrao de aplicaes que antes

eram isoladas; Racionalizao na entrada de dados; Os arquivos continuam sendo por

aplicao; Troca de dados entre aplicaes

travs de fitas ou disquetes.

Figura 3 Segunda fase do tratamento dos dados

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

3.3

Terceira fase

Visando isolar os dados das aplicaes facilitando o acesso aos mesmos e por conseqncia a integrao dos sistemas, na terceira fase comeam a surgir os primeiros SGBDs. Os sistemas gerenciadores passam a assumir algumas funes que antes eram de responsabilidade da aplicao, como por exemplo, a definio das estruturas dos arquivos (tabelas). 10

Figura 4 Terceira fase do tratamento dos dados

Caractersticas: 3.4 Banco de dados por aplicao; Possibilidade de acesso interativo diretamente sobre o banco de dados; Comeam a surgir as primeiras linguagens de consulta. Quarta fase A quarta fase constitui a ltima gerao dos SGBDs. A proposta destes sistemas promover uma completa abstrao dos dados. Os SGBDs assumem todo o controle e tratamento, restando para a aplicao apenas a necessidade de se comunicar com o gerenciador requisitando consultas. Os problemas de acesso concorrente, segurana, consistncias e integridade passam a ser de responsabilidade do banco de dados, abrindo caminhos para a construo de sistemas melhores e tempos cada vez menores.

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

11
Figura 5 Quarta fase do tratamento dos dados

Caractersticas: 3.5 Banco de dados integrado; Compartilhamento dos dados por diversos usurios, de forma concorrente ou no; Independncia de dados. Conseqncias do uso de SGBD

A integrao e compartilhamento dos dados geraram grandes benefcios, mas criou novas necessidades. O prprio conceito de independncia de dados (imunidade das aplicaes com relao aos dados) reforou a necessidade de nveis de abstrao de dados. Benefcios: Economia de espao de armazenamento; Economia do esforo de desenvolvimento; Reduo da redundncia de dados; Reduo da inconsistncia de dados.

Necessidades: Maior uniformidade; Ampliar dispositivos de segurana (restries de acesso e responsabilidades sobre a manuteno de dados);
Banco de Dados Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

 3.6

Reforar padres; Manter a integridade. Nveis da Arquitetura de um SGBD (Padro ISO)

A maior vantagem do BD sua viso abstrata dos dados, ocultando detalhes de implementao. Por ser difcil representar o mundo real, envolver usurios com conhecimentos diferentes e a necessidade de ter um padro, fez surgir uma arquitetura em diferentes nveis de abstrao, simplificando a relao do usurio com o sistema. Nvel conceitual - ao que produz o esquema de dados abstratos que descreve a estrutura de um BD de forma independente de um SGBD (esquema conceitual). Nvel lgico - ao que produz o esquema lgico de dados que representa a estrutura de dados de um BD em acordo com o modelo de dados ligados a um SGBD. Nvel fsico - ao que produz o esquema fsico de dados a partir do esquema de lgico de dados com a adio das estratgias de otimizao para manipulao das estruturas de dados. As estratgias de otimizao so dependentes dos fabricantes dos SGBDs e de suas verses. 3.7 Tipos de usurios de BD 12

Para um grande banco de dados, existe um grande nmero de pessoas envolvidas, desde o projeto, uso at manuteno. Administrador de Banco de Dados (DBA) - Em um ambiente de banco de dados, o recurso primrio o banco de dados por si s e o recurso secundrio o SGBD e os softwares relacionados. A administrao destes recursos cabe ao Administrador de Banco de Dados, o qual responsvel pela autorizao de acesso ao banco de dados e pela coordenao e monitorao de seu uso. Projetista de Banco de Dados - O Projetista de Banco de Dados responsvel pela identificao dos dados que devem ser armazenados no banco de dados, escolhendo a estrutura correta para representar e armazenar dados. Muitas vezes, os projetistas de banco de dados atuam como staff do DBA, assumindo outras responsabilidades aps a construo do banco de dados. funo do projetista
Banco de Dados Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

tambm avaliar as necessidades de cada grupo de usurios para definir as vises que sero necessrias, integrando-as, fazendo com que o banco de dados seja capaz de atender a todas as necessidades dos usurios. Usurios Finais - Existem basicamente trs categorias de usurios finais que so os usurios finais do banco de dados, fazendo consultas, atualizaes e gerando documentos: o Usurios casuais: acessam o banco de dados casualmente, mas que podem necessitar de diferentes informaes a cada acesso; utilizam sofisticadas linguagens de consulta para especificar suas necessidades; o Usurios novatos ou paramtricos: utilizam pores pr-definidas do banco de dados, utilizando consultas preestabelecidas que j foram exaustivamente testadas; o Usurios sofisticados: so usurios que esto familiarizados com o SGBD e realizam consultas complexas. Analistas de Sistemas e Programadores de Aplicaes - Os analistas determinam os requisitos dos usurios finais e desenvolvem especificaes para transaes que atendam estes requisitos, e os programadores implementam estas especificaes como programas, testando, depurando, documentando e dando manuteno no mesmo. importante que, tanto analistas quanto programadores, estejam a par dos recursos oferecidos pelo SGBD. 13

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

MODELOS LGICOS DE SGBDs Os SGBDs evoluram desses sistemas de arquivos de armazenamento em disco,

criando novas estruturas de dados com o objetivo de armazenar informaes. Com o tempo, os SGBDs passaram a utilizar diferentes formas de representao, ou modelos de dados, para descrever a estrutura das informaes contidas em seus bancos de dados. Atualmente, os seguintes modelos de dados so normalmente utilizados pelos SGBDs: modelo hierrquico, modelo em redes, modelo relacional e o modelo orientado a objetos. O modelo de dados mais adotado hoje em dia o modelo relacional, onde as estruturas tm a forma de tabelas, compostas por linhas e colunas. 4.1 Modelo hierrquico Na abordagem hierrquica, como o prprio nome j diz, os dados so organizados de acordo com nveis hierrquicos preestabelecidos. Os primeiros bancos de dados esto baseados nesta abordagem. Na abordagem hierrquica, podemos ver o banco de dados como um nico arquivo organizado em nveis. O nvel superior que contm a filial chamado de raiz e qualquer acesso ao banco de dados deve ser feito a partir dele. Em geral, a raiz pode ter qualquer quantidade de dependentes, e estes, qualquer quantidade de dependentes de nvel mais baixo. Um banco de dados hierrquico apresenta as seguintes caractersticas: Organiza os registros em rvores estrutura hierrquica um conjunto de registros (ns pais e ns filhos) interconectados por ponteiros. Os registros em cada segmento s podem ser filhos de um nico registro pai. Implementa diretamente as associaes de um para muitos (1-N) onde cada segmento, exceto o n raiz, deve sempre ter um e somente um segmento pai. A alterao do projeto (incluso de novos ns) e o uso dos dados so difceis, pois exigem o conhecimento de sua estrutura de implementao e no h critrios formais para iniciar. As relaes M:N (muitos para muitos) so implementadas mascarando-se o
Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim Banco de Dados

14

sentido filho para pai com chaves estrangeiras. 4.2 Modelo em redes Sua organizao semelhante dos banco de dados hierrquicos, com diferena de que cada registro filho pode ser ligado a mais de um registro pai, criando conexes bastante complexas e so bastante utilizados em sistemas para computadores de grande porte. Sendo que esse modelo composto de uma estrutura mais completa, possui as propriedades bsicas de registros, conjuntos e ocorrncias. Em um banco de dados estruturado como um modelo em rede h freqentemente mais de um caminho para acessar um determinado elemento de dado. 4.3 Modelo relacional O Modelo relacional revelou-se ser o mais flexvel e adequado ao solucionar os vrios problemas que se colocam no nvel da concepo e implementao da base de dados. A estrutura fundamental do modelo relacional a relao (tabela). Uma relao constituda por um ou mais atributos (campos) que traduzem o tipo de dados a armazenar. Cada instncia do esquema (linha) chamada de tupla (registro). O modelo relacional no tem caminhos pr-definidos para se fazer acesso aos dados como nos modelos que o precederam. O modelo relacional implementa estruturas de dados organizadas em relaes. Porm, para trabalhar com essas tabelas, algumas restries precisaram ser impostas para evitar aspectos indesejveis, como: Repetio de informao, incapacidade de representar parte da informao e perda de informao. Essas restries so: integridade referencial, chaves e integridade de junes de relaes. A figura abaixo traz exemplos de tabelas sob o modelo relacional. 15

Figura 6 Tabelas do modelo relacional

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

5.5.1 Relao A relao se representa mediante uma tabela, esta tabela representa o que no modelo entidade-relao chamvamos entidade. Esta tabela contm os atributos (colunas) e os registros (tuplas).

Atributo: trata-se de cada uma das colunas da tabela. Vem definidas por um nome e podem conter um conjunto de valores. 16

Registros: trata-se de cada uma das linhas da tabela. importante assinalar que no se podem ter registros duplicadas em uma tabela.

O domnio dentro da estrutura do modelo relacional o conjunto de valores que pode tomar um atributo.

5.5.1 Chaves Cada registro de uma tabela tem que estar associada a uma chave nica que permita identific-lo. Uma chave pode estar composta por um ou mais atributos. Uma chave tem que ser nica dentro de sua tabela e no se pode descartar nenhum atributo da mesma para identificar um registro. Existem dois tipos de chaves: Chave primria (Primary Key): o valor ou conjunto de valores que identificam um registro dentro de uma tabela de forma nica, ou seja, no pode ser duplicado. Nunca pode ser NULL. Um exemplo claro de chave primria seria o RG, que nico para cada pessoa e no pode ser NULL. Chave estrangeira (Foreign Key): o valor ou valores de uma tabela que corresponde com o valor de uma chave primria em outra tabela. Esta chave a que representa as relaes entre as tabelas. Os valores que aparecem nos atributos em uma chave estrangeira devem aparecer na chave primaria da tabela referenciada, ou seja, para todo valor de chave estrangeira haver um valor de chave primria em uma tabela referenciada. 4.4 Modelo orientado a objetos Os bancos de dados orientados a objeto comearam a se tornar comercialmente viveis em meados de 1980. A motivao para seu surgimento est em funo dos
Banco de Dados Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

limites de armazenamento e representao semntica impostas no modelo relacional. A habilidade para criar os tipos de dados necessrios uma caracterstica das linguagens de programao orientadas a objetos. Contudo, estes sistemas necessitam guardar representaes das estruturas de dados que utilizam no armazenamento permanente. um modelo de dados similar ao modelo em rede, mas com estrutura mais complexa (no orientado a registro). Neste caso, tambm pode ser agregado o comportamento dinmico de cada objeto. 5 MODELAGEM DE DADOS UTILIZANDO MER O Modelo Entidade Relacionamento - MER um modelo de dados conceitual de alto nvel, cujos conceitos foram projetados para estar o mais prximo possvel da viso que o usurio tem dos dados, no se preocupando em representar como estes dados estaro realmente armazenados. O modelo MER utilizado principalmente durante o processo de projeto de banco de dados. A figura abaixo faz uma descrio simplificada do processo de projeto de um banco de dados. 17

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

18

Figura 7 Etapas de um projeto de banco de dados

5.1

Entidades e Atributos O objeto bsico tratado pelo MER a entidade, que pode ser definida como um

objeto do mundo real, concreto ou abstrato e que possui existncia independente. Cada entidade possui um conjunto particular de propriedades que a descreve chamado atributos. Um atributo pode ser dividido em diversas sub-partes com significado independente entre si, recebendo o nome de atributo composto. Um atributo que no pode ser subdividido chamado de atributo simples ou atmico. O atributo que pode assumir apenas um determinado valor em uma determinada instncia denominado atributo mono valorado, enquanto que um atributo que pode assumir diversos valores em uma mesma instncia denominado multi valorado. Por exemplo, em uma entidade Aluno o atributo sexo mono valorado, pois ele s pode assumir um valor de cada vez. J o atributo telefone que guarda os telefones para contato com o aluno pode assumir mais de um valor ao mesmo tempo.

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

Um atributo que gerado a partir de outro atributo chamado de atributo derivado. Por exemplo, em uma entidade Aluno podemos ter um atributo idade que derivado do atributo data de nascimento. 5.2 Estrutura bsica de BD, conjunto de valores e atributo chave Na verdade a estrutura bsica de um banco de dados a seguinte: Um banco formado por um conjunto de entidades ou tabelas, uma tabela ou entidade formada por um conjunto de registros (Um cliente, Um aluno, etc). Um registro formado por um conjunto de atributos ou campos (Ex: cdigo, nome, endereo, etc...). Cada informao dessas um campo ou atributo. Uma restrio muito importante em um registro o campo ou atributo chamado atributo chave e seus valores podem ser utilizados para identificar cada registro de forma nica. Muitas vezes, uma chave pode ser formada pela composio de dois ou mais atributos. Quando a chave formada por mais de um atributo ou campo chamamos de chave primria composta. Quando a chave formada somente por um campo (Ex: Cdigo) chamamos de chave primria simples. Cada atributo simples de um registro est associado com um conjunto de valores denominado domnio, o qual especifica o conjunto de valores que podem ser designados para este determinado atributo para cada entidade. Ou seja, quais valores podem assumir cada campo. No campo sexo, por exemplo, s podemos aceitar F ou M, ou seja, F e M o domnio do atributo sexo. 5.3 Relacionamentos Alm de conhecer detalhadamente os tipos entidade, muito importante conhecer tambm os relacionamentos entre as entidades. Um relacionamento, como o prprio nome diz, a relao que ocorre entre registros de duas ou mais entidades (tabelas). Para que o relacionamento ocorra, deve haver interesses envolvidos, ou seja, uma entidade deve se interessar pelas informaes da outra, seus campos ou atributos devem ter o mesmo tipo e tamanho e devem ser afins, porm, no necessariamente o mesmo nome.
Banco de Dados Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

19

A figura a seguir mostra um exemplo entre dois tipos entidade (empregado e departamento) e o relacionamento entre eles (trabalha para). Repare que para cada relacionamento, participam apenas uma entidade de cada tipo entidade, porm, uma entidade pode participar de mais do que um relacionamento. Os relacionamentos existem para que as entidades possam compartilhar as informaes, evitando-se que haja repetio de informaes sem necessidade. O nome de um cliente, por exemplo, s deve ocorrer uma nica vez. Se outras entidades necessitam das informaes dos clientes devem se relacionar com a tabela Clientes. Os relacionamentos ocorrem normalmente em atributos numricos de pequena largura, ou seja, devem ser campos pequenos. Campos dos tipos texto no devem se relacionar, excetos em raros casos onde isso for necessrio.
Trabalha Para EMPREGADO e1 e2 e3 e4 e5 e6 e7 DEPARTAMENTO

20

d1 d2 d3

Figura 8 Relacionamento entre entidades

5.5.1 Grau de um Relacionamento O grau de um tipo relacionamento o nmero de tipos entidade que participam do tipo relacionamento. No exemplo da figura acima, temos um relacionamento binrio. O grau de um relacionamento ilimitado, porm, a partir do grau 3 (ternrio), a compreenso e a dificuldade de se desenvolver a relao corretamente se tornam extremamente complexas. 5.3.2 Outras caractersticas de um relacionamento 5.3.2.1 Relacionamentos com Atributos Algumas vezes conveniente pensar em um relacionamento como um atributo. Considere uma situao onde diversos mdicos possuem diversos pacientes e cada
Banco de Dados Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

paciente pode ter N mdicos. Portanto, no possvel armazenarmos o cdigo do mdico na entidade paciente (j que ele possui n mdicos) e nem o cdigo do paciente em mdico (ele possui n clientes). Caracteriza-se, portanto um relacionamento de muitos para muitos (n para n). Neste caso, necessrio criarmos o que chamamos Entidade Associativa ou Relacionamento com atributos. Neste caso, teramos a entidade Consulta. Nesta entidade poderamos ter o cdigo do mdico, o cdigo do paciente, data da consulta e observaes. 21
MDICOS

Consultas

PACIENTES

Figura 9 Relacionamentos com atributos

Um relacionamento recursivo um relacionamento entre entidades do mesmo tipo entidade. Veja o exemplo da figura abaixo. No exemplo, temos um relacionamento entre o tipo entidade EMPREGADO, onde um empregado pode supervisionar outro empregado e um empregado pode ser supervisionado por outro empregado.
EMPREGADO

e1 e2 e3 e4 e5 Supervisiona Supervisionado Supervisiona

Figura 10 Relacionamento recursivo

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

5.3.2.2 Restries em Tipos Relacionamentos Geralmente, os tipos relacionamentos sofrem certas restries que limitam as possveis combinaes das entidades participantes. Estas restries so derivadas de restries impostas pelo estado destas entidades no mini-mundo ou mundo real. Veja o exemplo da figura a seguir.
Gerencia

EMPREGADO

DEPARTAMENTO

22

e1 e2 e3 e4 e5 e6 e7

d1 d2 d3

Figura 11 - Cardinalidade

No exemplo acima, temos a seguinte situao: um empregado pode gerenciar apenas um departamento, enquanto que um departamento pode ser gerenciado por apenas um empregado. A este tipo de restrio, ns chamamos cardinalidade. A cardinalidade indica a forma que uma entidade participa do relacionamento. A cardinalidade pode ser: 1:1(um para um), 1:N (um para muitos), M:N (muitos para muitos). No exemplo anterior, a cardinalidade 1:1, pois cada entidade empregado pode gerenciar apenas um departamento e um departamento pode ser gerenciado por apenas um empregado. No exemplo do relacionamento EMPREGADO Trabalha Para DEPARTAMENTO, o relacionamento 1:N, pois um empregado pode trabalhar em apenas um departamento, enquanto que um departamento pode possuir vrios empregados. Na figura abaixo temos um exemplo de um relacionamento com cardinalidade N:M.

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

Trabalha Em EMPREGADO 8e1 e2 e3 e4 PROJETO

p1 p2 p3

23

Figura 12 Relacionamento N:N

No exemplo acima, ns temos que um empregado pode trabalhar em vrios projetos enquanto que um projeto pode ter vrios empregados trabalhando. o mesmo caso que citamos acima de Mdicos e Pacientes. Algumas vezes, torna-se necessrio armazenar um atributo no tipo relacionamento. Veja o exemplo da figura que mostra o relacionamento entre Empregados e Departamentos. Eu posso querer saber em que dia o empregado passou a gerenciar o departamento. difcil estabelecer a qual tipo entidade pertence atributo, pois o mesmo definido apenas pela existncia do relacionamento. Quando temos relacionamentos com cardinalidade 1:1, podemos colocar o atributo em uma das entidades, de preferncia, em uma cujo tipo entidade tenha participao total. No caso, o atributo poderia ir para o tipo entidade departamento. Isto porque nem todo empregado participar do relacionamento. Caso a cardinalidade seja 1:N, ento podemos colocar o atributo no tipo entidade com participao N. Porm, se a cardinalidade for N:M, ento o atributo dever mesmo ficar no tipo relao. Veja o exemplo da figura que aparecem Empregados e Projetos. Caso queiramos armazenar quantas horas cada empregado trabalhou em cada projeto, ento este dever ser um atributo do relacionamento. Ou seja, quando temos o relacionamento muitos para muitos, devemos utilizar a entidade-relacionamento ou relacionamento com atributos. Esta entidade serve de ponte entre as duas relacionadas, ou seja, quando no conseguimos armazenar algumas informaes em um ou em outra entidade, utilizamos uma terceira (entidaderelacionamento) para armazen-las.
Banco de Dados Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

Um bom exemplo disso o relacionamento entre MDICOS e PACIENTES. Um mdico possui muitos pacientes e um paciente possui muitos mdicos. Algumas informaes no so possveis de serem armazenadas nem em mdicos nem tampouco em pacientes. A data da consulta, por exemplo, o diagnstico, etc. Se colocamos em mdicos, ele tem vrios pacientes e estas informaes ficaro falhas, se colocamos em pacientes, se ele fez vrias consultas e s possumos um espao, ou seja, um campo para armazenar cada informao, tambm ficar falha. Portanto, ser necessrio a utilizao da entidade-relacionamento CONSULTAS para armazenarmos estas informaes especficas de CONSULTAS. 5.3.2.3 Tipos Entidades Fracas Alguns tipos entidade podem no ter um atributo chave por si s. Isto implica que no poderemos distinguir algumas entidades por que as combinaes dos valores de seus atributos podem ser idnticas. Estes tipos entidade so chamados entidades fracas. As entidades deste tipo precisam estar relacionadas com uma entidade pertencente ao tipo entidade proprietria. Este relacionamento chamado de relacionamento identificador. Veja o exemplo abaixo.
Possui Dependentes EMPREGADO DEPENDENTE e1 e2

24

p1 p2 p3

Figura 13 Entidade fraca

O tipo entidade DEPENDENTE uma entidade fraca, pois no possui um mtodo de identificar uma entidade nica. O EMPREGADO no uma entidade fraca, pois possui um atributo para identificao (atributo chave). O nmero do RG de um empregado identifica um nico empregado. Porm, um dependente de 5 anos de idade no possui necessariamente um documento. Desta forma, esta entidade um tipo entidade fraca. Um tipo entidade fraca possui uma chave parcial, que juntamente com a
Banco de Dados Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

chave primria da entidade proprietria forma uma chave primria composta. Neste exemplo: a chave primria do EMPREGADO o RG. A chave parcial do DEPENDENTE o seu nome, pois dois irmos no podem ter o mesmo nome. Desta forma, a chave primria desta entidade fica sendo o RG do pai ou me mais o nome do dependente. Algumas caractersticas marcantes nas entidades fracas so o fato de sua chave primria ser composta (formada por mais de um campo) e seus registros s existem se existirem registros correspondentes na entidade forte. Ex. Alunos e Notas. S existem notas se existirem alunos cadastrados. Todos os exemplos vistos acima foram para relacionamentos binrios, ou seja, entre dois tipos entidades diferentes ou recursivos. Porm, o modelo entidade relacionamento no se restringe apenas relacionamentos binrios. O nmero de entidades que participam de um tipo relacionamento irrestrito e armazenam muito mais informaes do que diversos relacionamentos binrios. Considere o seguinte exemplo: Um motorista pode efetuar uma viagem para uma localidade dirigindo um determinado caminho em uma determinada data. 25

Figura 14 Relacionamento ternrio

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

Se efetuarmos trs relacionamentos binrios, no teremos estas informaes de forma completa como se crissemos um relacionamento ternrio. Veja o resultado como fica no exemplo da figura acima. 5.4 Diagrama Entidade Relacionamento - DER O Diagrama Entidade Relacionamento composto por um conjunto de objetos grficos que visa representar todos os objetos do Modelo Entidade Relacionamento tais como entidades, atributos, atributos chaves, relacionamentos, restries estruturais, etc. O DER fornece uma viso lgica do banco de dados, fornecendo um conceito mais generalizado de como esto estruturados os dados de um sistema. Os objetos que compem o D ER esto listados na figura a seguir. 26

Figura 15 Objetos de DER

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

5.5

Normalizao Normalizao uma tcnica de projeto de banco de dados que visa, a partir dos

dados existentes na organizao, construir relaes (tabelas) livres de redundncia e passveis de serem implementadas em um banco de dados relacional. Para normalizar um conjunto de dados devemos aplicar sobre os mesmos as regras que os tornam normalizados. O processo de normalizao passa por diversas etapas conhecidas como formas normais. Veja um exemplo. Seja a seguinte relao no normalizada: Funcionrios (Cdigo Funcionrio, Nome, Endereo, Cidade, UF, CEP, Departamento, (Cdigo Curso, Curso, Data, Grau)) Obs.: Os atributos Cdigo Curso, Curso, Data e Grau esto entre parnteses porque se repetem muitas vezes na ficha do funcionrio. 5.5.1 Primeira Forma Normal 1FN Uma relao estar na primeira forma normal se e somente se todos os seus atributos possurem valores atmicos (nicos). Funcionrios (Cdigo Funcionrio, Nome, Endereo, Cidade, UF, CEP, Departamento). CursosFuncionrio ( Cdigo Funcionrio#, Cdigo Curso, Curso, Data, Grau ). Obs.: Os atributos que se repetem (valores no nicos) formam uma nova relao. A chave primria da primeira relao (relao origem) deve ser levada para a nova relao. Para a nova relao devemos definir uma chave primria. 5.5.2 Segunda forma normal 2FN Uma relao estar na segunda forma normal se e somente se estiver na primeira forma normal e todos os seus atributos forem dependentes funcionais de toda a chave primria, ou seja, nenhum atributo pode ser dependente parcial da chave primria.
Banco de Dados Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

27

Funcionrios (Cdigo Funcionrio, Nome, Endereo, Cidade, UF, CEP, Departamento). CursosFuncionrio ( Cdigo Funcionrio#, Cdigo Curso#, Data). Cursos (Cdigo Curso, Curso, Grau). Obs.: O atributo Curso dependente apenas de Cdigo Curso, por isso foi retirado e passou a integrar uma nova tabela de Cursos onde o atributo que gera a dependncia funcional, Cdigo Curso, trazido como chave primria. 5.5.3 Terceira forma normal 3FN Uma relao estar na terceira forma normal se e somente se estiver na segunda forma normal e nenhum de seus atributos for dependente transitivo da chave primria, ou seja, nenhum atributo pode depender de outro atributo que no chave. Funcionrios (Cdigo Funcionrio, Nome, Endereo, CEP#, Departamento). Cidades (CEP, Cidade, UF). CursosFuncionrio ( Cdigo Funcionrio#, Cdigo Curso#, Data). Cursos (Cdigo Curso, Curso, Grau). Obs.: Os atributos Cidade e UF alm de dependerem da chave primria Cdigo Funcionrio so dependentes do atributo CEP, constituir uma nova tabela tendo como chave primria o CEP. 5.5.4 Quarta forma normal 4FN Uma relao estar na quarta forma normal se e somente se estiver na terceira forma normal e nenhum de seus atributos for dependente multivalorado da chave primria, ou seja, possuir um contedo comum a muitas tuplas da relao. Funcionrios (Cdigo Funcionrio, Nome, Endereo, CEP#, Cdigo Depto#). Cidades (CEP, Cidade, UF).
Banco de Dados Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim

28

portanto passam a

CursosFuncionrio ( Cdigo Funcionrio#, Cdigo Curso#, Data, Grau ). Cursos (Cdigo Curso, Curso). Deptos (Cdigo Depto, Departamento). Obs.: O atributo Departamento dependente multivalorado do Cdigo Funcionrio, pois ele ocorre repetidamente em vrias tuplas da relao Funcionrio. Para solucionar esta dependncia cria-se uma nova tabela com o atributo Departamento, gerando um novo atributo para constituir a chave primria desta nova tabela, Cdigo Depto. 6 MODELO FSICO DE BANCO DE DADOS 29

LINGUAGENS DE BANCO DE DADOS

Banco de Dados

Paula Patrcia Oliveira da Silva Reinaldo Monteiro Cotrim