Apostila de Banco de Dados

Banco de Dados

Banco de Dados

Reinaldo Monteiro Cotrim Reinaldo Monteiro Cotrim

2 2

INDICE

INDICE

INDICE

INDICE DE DE FIGURAS ...FIGURAS ... ... 33 11 INTRODUÇÃO INTRODUÇÃO ... ... 44 22 CONCEITOS CONCEITOS BÁSICOS BÁSICOS ... ... 55

2.1

2.1 BBANCO DE DADOSANCO DE DADOS... ... 55

2.2

2.2 DDADOADO,,INFORMAÇÃOINFORMAÇÃO,,CONHECIMENTO E SABEDORIACONHECIMENTO E SABEDORIA... ... 77

33 EVOLUÇÃO NO EVOLUÇÃO NO TRATAMENTO DOS TRATAMENTO DOS DADOS DADOS ... .. 99 3.1

3.1 PPRIMEIRA FASERIMEIRA FASE... ... 99

3.2

3.2 SSEGUNDA FASEEGUNDA FASE... ... 99

3.3

3.3 TTERCEIRA FASEERCEIRA FASE... ... 1010

3.4

3.4 QQUARTA FASEUARTA FASE... ... 1010

3.5

3.5 CCONSEQÜÊNCIAS DO USO DEONSEQÜÊNCIAS DO USO DESGBD ...SGBD ... ... 1111

3.6

3.6 NNÍVEIS DAÍVEIS DAAARQUITETURA DE UMRQUITETURA DE UMSGBDSGBD (P(PADRÃOADRÃOISO) ....ISO) ... ... 1212

3.7

3.7 TTIPOS DE USUÁRIOS DEIPOS DE USUÁRIOS DEBD BD ... ... 1212

44 MODELOS LÓGICOS MODELOS LÓGICOS DE DE SGBDS ...SGBDS ... 14... 14 4.1

4.1 MMODELO HIERÁRQUICOODELO HIERÁRQUICO... ... 1414

4.2

4.2 MMODELO EM REDESODELO EM REDES... ... 1515

4.3

4.3 MMODELO RELACIONALODELO RELACIONAL... ... 1515

5.5.1

5.5.1 Relação Relação ... ... 1616 5.5.1

5.5.1 Chaves Chaves ... ... 1616 4.4

4.4 MMODELO ORIENTADO A OBJETOSODELO ORIENTADO A OBJETOS ... .... 1616

55 MODELAGEM DE MODELAGEM DE DADOS UTILIZANDO DADOS UTILIZANDO MER MER ... 17... 17 5.1

5.1 EENTIDADES ENTIDADES EAATRIBUTOSTRIBUTOS... ... 1818

5.2

5.2 EESTRUTURA BÁSICA DESTRUTURA BÁSICA DEBD,BD,CONJUNTO DE VALORES E ATRIBUTO CHAVECONJUNTO DE VALORES E ATRIBUTO CHAVE ... 19... 19

5.3

5.3 RRELACIONAMENTOSELACIONAMENTOS... . 1919

5.5.1

5.5.1 Grau de Grau de um Relaum Relacionamento ...cionamento ... 20... 20 5.3.2

5.3.2 Outras caracterísOutras características de ticas de um relacionamento ...um relacionamento ... 20... 20

5.3.2.1

5.3.2.1  Relaciona Relacionamentos com mentos com Atributos Atributos ... ... 2020 5.3.2.2

5.3.2.2  Restriçõe Restrições em Tipos Rs em Tipos Relacionamenelacionamentos tos ... 22... 22 5.3.2.3

5.3.2.3 Tipos Tipos Entidades Fracas ...Entidades Fracas ... 24... 24

5.4

5.4 DDIAGRAMAIAGRAMAEENTIDADENTIDADERRELACIONAMENTOELACIONAMENTO-- DER ...DER ... .... 2626

5.5

5.5 NNORMALIZAÇÃOORMALIZAÇÃO... ... 2727

5.5.1

5.5.1 Primeira Forma NormalPrimeira Forma Normal –  – 1FN ...1FN ... ... 2727

5.5.2

5.5.2 Segunda forma normalSegunda forma normal –  – 2FN 2FN ... 27... 27

5.5.3

5.5.3 Terceira forma normalTerceira forma normal –  – 3FN ...3FN ... ... 2828

5.5.4

5.5.4 Quarta forma normalQuarta forma normal –  – 4FN 4FN ... .... 2828

66 MODELO FÍSICO MODELO FÍSICO DE DE BANCO BANCO DE DE DADOS DADOS ... 29... 29 77 LINGUAGENS DE LINGUAGENS DE BANCO BANCO DE DE DADOS DADOS ... 29... 29

3

INDICE DE FIGURAS

Figura 1 _–Dado, informação, 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 ternário ... 25

4

1 INTRODUÇÃO

Para resolver o problema da carência de literatura destinada ao ensino de Banco de Dados e SQL para os nossos estudantes, elaboramos a presente apostila, que não possui a intenção de esgotar tão abrangente volume de informações, servindo somente para estabelecer um mínimo de conhecimentos destinados a introduzir o estudante no mundo dos Gerenciadores de Banco de dados e da linguagem SQL - Structured Query  Languageou Linguagem de Consulta Estruturada.

5

2 CONCEITOS BÁSICOS 2.1 Banco de dados

Todos nós sabemos existirem gigantescas bases de dados gerenciando nossas vidas. De fato sabemos que nossa conta bancária faz parte de uma coleção imensa de contas bancárias de nosso banco. Nosso título eleitoral ou nosso cadastro de pessoa física, certamente estão armazenados em bancos de dados colossais. Sabemos também que quando sacamos dinheiro no caixa eletrônico de nosso banco, nosso saldo e as movimentações existentes em nossa conta bancária já estão à nossa disposição.

Estes bancos de dados, além de manterem todo este volume de dados organizado, também devem permitir atualizações, inclusões e exclusões do volume de dados, sem nunca perder a consistência. E não podemos esquecer que na maioria das vezes estaremos lidando com acessos concorrentes a várias tabelas de nosso banco de dados, algumas vezes com mais de um acesso ao mesmo registro de uma mesma tabela.

Um banco de dados contém os dados dispostos numa ordem pré-determinada em função de um projeto de sistema, sempre para um propósito 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 informações derivadas, que possui um nível de interação 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 implícito. Porém, o significado do termo “banco de dados” pode significar algo mais que a definição acima.

Um banco de dados possui as seguintes propriedades:

 um banco de dados é uma coleção lógica coerente de dados com um

significado inerente;

 um banco de dados é projetado, construído e populado com dados para um

6  um banco de dados representa algum aspecto do mundo real, o qual é chamado

de “mini-mundo” ou “mundo real”; qualquer alteração efetuada no

mini-mundo é automaticamente refletida no banco de dados.

Um banco de dados pode ser criado e mantido por um conjunto de aplicações

desenvolvidas especialmente para esta tarefa ou por um “Sistema Gerenciador de Banco de Dados” (SGBD). Um SGBD permite aos usuários criarem e manipularem bancos de

dados de propósito geral. O conjunto formado por um banco de dados mais as

7

2.2 Dado, informação, conhecimento e sabedoria

Dado: É uma abstração que representa um conteúdo elementar, fato isolado, como você observa no mundo real. Um nome, uma data, um número, um conceito, uma instrução, uma imagem, um CPF etc. são dados. O valor do dado não tem qualquer  julgamento ou interpretação dos eventos, nem qualquer base para ação. Só forma um

conjunto de símbolos desprovido de significado isolado. Mas, os dados são vitais, pois deles se obtém a informação. Um item de dado é criado, auditado, atualizado e usado por muitos usuários diferentes. Você não 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 número em fila de espera, a representação binária do decimal 4 etc. A interpretação do dado o transforma em informação.

Informação: Você extrai informação, obtendo conhecimento útil ao usuário, organizando, correlacionando e interpretando dados, seja para agir, seja para decidir. A informação faz parte do dia-a-dia; ela está em arquivos, em papéis e na cabeça das pessoas. É a estrutura básica de um sistema de informação. Exemplo: resposta à

consulta “Quais os clientes de São José?”.

Figura 1 _–Dado, informação, conhecimento e sabedoria

Reflita: Qual a importância da informação? Compare a perda de um equipamento, depósito ou fábrica com a perda da especificação de um produto ou tecnologia (como se faz a coca-cola, a pepsi, como se obtém a energia nuclear e funciona o motor, a explosão etc.).

8

Conhecimento: informação valiosa da mente humana. Inclui reflexões, síntese e contexto – de difícil estruturação, captura em máquinas e transferência. Nesse

caso, a dificuldade está no fato de ser produzido no cérebro humano, a partir de percepções individuais que o detentor do conhecimento faz, mediante suas experiências de vida, aplicação aos estudos, aprofundamento de leituras, enfim, de sua conduta pessoal em relação ao aprendizado. Como isso varia de pessoa a pessoa, o capital intelectual torna-se um grande diferencial competitivo das empresas, que devem investir na formação e aprimoramento de seus funcionários.

Sabedoria: é o acúmulo de dados, informações e conhecimentos, agregados e acumulados de forma equilibrada e consciente pelo ser humano, de acordo com a experiência individual.

9

3 EVOLUÇÃO NO TRATAMENTO DOS DADOS 3.1 Primeira fase

Nesta fase os dados são tratados por aplicação. Somente a aplicação possui acesso aos dados, pois a estrutura dos registros encontra-se definida no código fonte da aplicação. Por causa disso os problemas de tratamento (acesso) dos dados, comuns a qualquer aplicação, precisam ser resolvidos (administrados) pela própria aplicação.

Características:

 Arquivos por aplicação isolada;

 Estrutura dos arquivos definida

na própria aplicação;

 Não há integração.

Figura 2 _–Primeira fase do tratamento dos dados

3.2 Segunda fase

Sendo uma evolução da primeira fase e forçada pela necessidade dos usuários, nesta segunda fase os dados continuam sendo armazenados em arquivos e tratados por aplicação. No entanto já há uma preocupação dos desenvolvedores em integrar as aplicações possibilitando a troca de dados entre elas.

Características:

 Integração de aplicações que antes

eram isoladas;

 Racionalização na entrada de dados;  Os arquivos continuam sendo por

aplicação;

 Troca de dados entre aplicações

través de fitas ou disquetes.

10

3.3 Terceira fase

Visando isolar os dados das aplicações facilitando o acesso aos mesmos e por conseqüência a integração dos sistemas, na terceira fase começam a surgir os primeiros SGBDs. Os sistemas gerenciadores passam a assumir algumas funções que antes eram de responsabilidade da aplicação, como por exemplo, a definição das estruturas dos arquivos (tabelas).

Figura 4 _–Terceira fase do tratamento dos dados

Características:

 Banco de dados por aplicação;

 Possibilidade de acesso interativo diretamente sobre o banco de dados;  Começam a surgir as primeiras linguagens de consulta.

3.4 Quarta fase

A quarta fase constitui a última geração dos SGBDs. A proposta destes sistemas é promover uma completa abstração dos dados. Os SGBDs assumem todo o controle e tratamento, restando para a aplicação apenas a necessidade de se comunicar com o gerenciador requisitando consultas. Os problemas de acesso concorrente, segurança, consistências e integridade passam a ser de responsabilidade do banco de dados, abrindo caminhos para a construção de sistemas melhores e tempos cada vez menores.

11

Figura 5 _–Quarta fase do tratamento dos dados

Características:

 Banco de dados integrado;

 Compartilhamento dos dados por diversos usuários, de forma concorrente ou

não;

 Independência de dados.

3.5 Conseqüências do uso de SGBD

A integração e compartilhamento dos dados geraram grandes benefícios, mas criou novas necessidades. O próprio conceito de independência de dados (imunidade das aplicações com relação aos dados) reforçou a necessidade de níveis de abstração de dados.

Benefícios:

 Economia de espaço de armazenamento;

 Economia do esforço de desenvolvimento;  Redução da redundância de dados;

 Redução da inconsistência de dados.

Necessidades:

 Maior uniformidade;

 Ampliar dispositivos de segurança (restrições de acesso e responsabilidades

12  Reforçar padrões;

 Manter a integridade.

3.6 Níveis da Arquitetura de um SGBD (Padrão ISO)

A maior vantagem do BD é sua visão abstrata dos dados, ocultando detalhes de implementação. Por ser difícil representar o mundo real, envolver usuários com conhecimentos diferentes e a necessidade de ter um padrão, fez surgir uma arquitetura em diferentes níveis de abstração, simplificando a relação do usuário com o sistema.

  Nível conceitual - ação que produz o esquema de dados abstratos que descreve a

estrutura de um BD de forma independente de um SGBD (esquema conceitual).

  Nível lógico - ação que produz o esquema lógico de dados que representa a

estrutura de dados de um BD em acordo com o modelo de dados ligados a um SGBD.

  Nível físico - ação que produz o esquema físico de dados a partir do esquema de

lógico de dados com a adição das estratégias de otimização para manipulação das estruturas de dados. As estratégias de otimização são dependentes dos fabricantes dos SGBDs e de suas versões.

3.7 Tipos de usuários de BD

Para um grande banco de dados, existe um grande número de pessoas envolvidas, desde o projeto, uso até manutenção.

 Administrador de Banco de Dados (DBA) - Em um ambiente de banco de

dados, o recurso primário é o banco de dados por si só e o recurso secundário o SGBD e os softwares relacionados. A administração destes recursos cabe ao Administrador de Banco de Dados, o qual é responsável pela autorização de acesso ao banco de dados e pela coordenação e monitoração de seu uso.

 Projetista de Banco de Dados - O Projetista de Banco de Dados é responsável

pela identificação 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

13

também avaliar as necessidades de cada grupo de usuários para definir as visões que serão necessárias, integrando-as, fazendo com que o banco de dados seja capaz de atender a todas as necessidades dos usuários.

 Usuários Finais - Existem basicamente três categorias de usuários finais que

são os usuários finais do banco de dados, fazendo consultas, atualizações e gerando documentos:

o Usuários casuais: acessam o banco de dados casualmente, mas que podem necessitar de diferentes informações a cada acesso; utilizam sofisticadas linguagens de consulta para especificar suas necessidades; o Usuários novatos ou paramétricos: utilizam porções pré-definidas do

banco de dados, utilizando consultas preestabelecidas que já foram exaustivamente testadas;

o Usuários sofisticados: são usuários que estão familiarizados com o SGBD e realizam consultas complexas.

 Analistas de Sistemas e Programadores de Aplicações - Os analistas

determinam os requisitos dos usuários finais e desenvolvem especificações para transações que atendam estes requisitos, e os programadores implementam estas especificações como programas, testando, depurando, documentando e dando manutenção no mesmo. É importante que, tanto analistas quanto programadores, estejam a par dos recursos oferecidos pelo SGBD.

14

4 MODELOS LÓGICOS DE SGBDs

Os SGBDs evoluíram desses sistemas de arquivos de armazenamento em disco, criando novas estruturas de dados com o objetivo de armazenar informações. Com o

tempo, os SGBD’s passaram a utilizar diferentes formas de representação, ou modelos

de dados, para descrever a estrutura das informações contidas em seus bancos de dados. Atualmente, os seguintes modelos de dados são normalmente utilizados pelos SGBD’s:

modelo hierárquico, 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 têm a forma de tabelas, compostas por linhas e colunas.

4.1 Modelo hierárquico

Na abordagem hierárquica, como o próprio nome já diz, os dados são organizados de acordo com níveis hierárquicos preestabelecidos. Os primeiros bancos de dados estão baseados nesta abordagem.

Na abordagem hierárquica, podemos ver o banco de dados como um único arquivo organizado em níveis. O nível superior que contém 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 nível mais baixo.

Um banco de dados hierárquico apresenta as seguintes características:

 Organiza os registros em árvores  – estrutura hierárquica é um conjunto de

registros (nós pais e nós filhos) interconectados por ponteiros. Os registros em cada segmento só podem ser filhos de um único registro pai.

 Implementa diretamente as associações de um para muitos (1-N) onde cada

segmento, exceto o nó raiz, deve sempre ter um e somente um segmento pai.

 A alteração do projeto (inclusão de novos nós) e o uso dos dados são difíceis,

pois exigem o conhecimento de sua estrutura de implementação e não há critérios formais para iniciar.

15

sentido filho para pai com chaves estrangeiras. 4.2 Modelo em redes

Sua organização é semelhante à dos banco de dados hierárquicos, com diferença de que cada registro filho pode ser ligado a mais de um registro pai, criando conexões bastante complexas e são bastante utilizados em sistemas para computadores de grande porte. Sendo que esse modelo é composto de uma estrutura mais completa, possui as propriedades básicas de registros, conjuntos e ocorrências.

Em um banco de dados estruturado como um modelo em rede há freqüentemente mais de um caminho para acessar um determinado elemento de dado.

4.3 Modelo relacional

O Modelo relacional revelou-se ser o mais flexível e adequado ao solucionar os vários problemas que se colocam no nível da concepção e implementação da base de dados. A estrutura fundamental do modelo relacional é a relação (tabela). Uma relação é constituída por um ou mais atributos (campos) que traduzem o tipo de dados a armazenar. Cada instância do esquema (linha) é chamada de tupla (registro). O modelo relacional não 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 relações. Porém, para trabalhar com essas tabelas, algumas restrições precisaram ser impostas para evitar aspectos indesejáveis, como: Repetição de informação, incapacidade de representar parte da informação e perda de informação. Essas restrições são: integridade referencial, chaves e integridade de junções de relações. A figura abaixo traz exemplos de tabelas sob o modelo relacional.

16

5.5.1 Relação

A relação se representa mediante uma tabela, esta tabela representa o que no modelo entidade-relação chamávamos entidade. Esta tabela contém os atributos (colunas) e os registros (tuplas).

 Atributo: trata-se de cada uma das colunas da tabela. Vêem definidas por um nome e podem conter um conjunto de valores.

 Registros: trata-se de cada uma das linhas da tabela. É importante assinalar que não se podem ter registros duplicadas em uma tabela.

 O domínio 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 não se pode descartar nenhum atributo da mesma para identificar um registro.

Existem dois tipos de chaves:

 Chave primária (Primary Key): é o valor ou conjunto de valores que identificam

um registro dentro de uma tabela de forma única, ou seja, não pode ser duplicado. Nunca pode ser NULL. Um exemplo claro de chave primária seria o RG, que é único para cada pessoa e não pode ser NULL.

 Chave estrangeira (Foreign Key): é o valor ou valores de uma tabela que

corresponde com o valor de uma chave primária em outra tabela. Esta chave é a que representa as relações 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 primária em uma tabela referenciada.

4.4 Modelo orientado a objetos

17

limites de armazenamento e representação semântica impostas no modelo relacional. A habilidade para criar os tipos de dados necessários é uma característica das linguagens de programação orientadas a objetos. Contudo, estes sistemas necessitam guardar representações das estruturas de dados que utilizam no armazenamento permanente.

É um modelo de dados similar ao modelo em rede, mas com estrutura mais complexa (não é orientado a registro). Neste caso, também pode ser agregado o comportamento dinâmico de cada objeto.

5 MODELAGEM DE DADOS UTILIZANDO MER

O Modelo Entidade Relacionamento - MER é um modelo de dados conceitual de alto nível, cujos conceitos foram projetados para estar o mais próximo possível da visão que o usuário tem dos dados, não se preocupando em representar como estes dados estarão realmente armazenados. O modelo MER é utilizado principalmente durante o processo de projeto de banco de dados.

A figura abaixo faz uma descrição simplificada do processo de projeto de um banco de dados.

18

Figura 7 _–Etapas de um projeto de banco de dados

5.1 Entidades e Atributos

O objeto básico tratado pelo MER é a “entidade”, que pode ser definida como um

objeto do mundo real, concreto ou abstrato e que possui existência 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 não

pode ser subdividido é chamado de “atributo simples” ou “atômico”.

O atributo que pode assumir apenas um determinado valor em uma determinada instância é denominado atributo mono valorado, enquanto que um atributo que pode assumir diversos valores em uma mesma instância é 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

19

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 básica de BD, conjunto de valores e atributo chave

Na verdade a estrutura básica 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: código, nome, endereço, etc...). Cada informação dessas é um campo ou atributo.

Uma restrição 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 composição de dois ou mais atributos. Quando a chave é formada por mais de um atributo ou campo chamamos de chave primária composta. Quando a chave é formada somente por um campo (Ex: Código) chamamos de chave primária simples.

Cada atributo simples de um registro está associado com um conjunto de valores

denominado “domínio”, 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 domínio do atributo “sexo”.

5.3 Relacionamentos

Além de conhecer detalhadamente os tipos entidade, é muito importante conhecer também os relacionamentos entre as entidades.

Um relacionamento, como o próprio nome diz, é a relação 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

informações da outra, seus campos ou atributos devem ter o mesmo tipo e tamanho e devem ser afins, porém, não necessariamente o mesmo nome.

20

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, porém, uma entidade pode participar de mais do que um relacionamento.

Os relacionamentos existem para que as entidades possam compartilhar as informações, evitando-se que haja repetição de informações sem necessidade. O nome de um cliente, por exemplo, só deve ocorrer uma única vez. Se outras entidades

necessitam das informações dos clientes devem se relacionar com a tabela “Clientes”.

Os relacionamentos ocorrem normalmente em atributos numéricos de pequena largura, ou seja, devem ser campos pequenos. Campos dos tipos texto não devem se relacionar, excetos em raros casos onde isso for necessário.

Figura 8 _–Relacionamento entre entidades

5.5.1 Grau de um Relacionamento

O “grau” de um tipo relacionamento é o número de tipos entidade que participam do

tipo relacionamento. No exemplo da figura acima, temos um relacionamento binário. O grau de um relacionamento é ilimitado, porém, a partir do grau 3 (ternário), a compreensão e a dificuldade de se desenvolver a relação corretamente se tornam extremamente complexas.

5.3.2 Outras características de um relacionamento

 5.3.2.1  Relacionamentos com Atributos

Algumas vezes é conveniente pensar em um relacionamento como um atributo. Considere uma situação onde diversos médicos possuem diversos pacientes e cada

d3 d2 d1 e7 e6 e5 e4 e3 e2 e1

21

paciente pode ter N médicos. Portanto, não é possível armazenarmos o código do médico na entidade paciente (já que ele possui n médicos) e nem o código do paciente em médico (ele possui n clientes). Caracteriza-se, portanto um relacionamento de muitos para muitos (n para n). Neste caso, é necessário criarmos o que chamamos

“Entidade Associativa” ou “Relacionamento com atributos”. Neste caso, teríamos a entidade “Consulta”. Nesta entidade poderíamos ter o código do médico, o código do

paciente, data da consulta e observações.

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.

Figura 10 _–Relacionamento recursivo

e5 e4 e3 e2 e1 EMPREGADO Supervisiona Supervisiona É Supervisionado

22

 5.3.2.2  Restrições em Tipos Relacionamentos

Geralmente, os tipos relacionamentos sofrem certas restrições que limitam as possíveis combinações das entidades participantes. Estas restrições são derivadas de restrições impostas pelo estado destas entidades no mini-mundo ou mundo real. Veja o exemplo da figura a seguir.

Figura 11 - Cardinalidade

No exemplo acima, temos a seguinte situação: um empregado pode gerenciar apenas um departamento, enquanto que um departamento pode ser gerenciado por apenas um empregado. A este tipo de restrição, nós 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 vários empregados. Na figura abaixo temos um exemplo de um relacionamento com cardinalidade N:M. d3 d2 d1 e7 e6 e5 e4 e3 e2 e1

23

Figura 12 _–Relacionamento N:N

No exemplo acima, nós temos que um empregado pode trabalhar em vários projetos enquanto que um projeto pode ter vários empregados trabalhando. É o mesmo caso que citamos acima de Médicos e Pacientes.

Algumas vezes, torna-se necessário 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. É difícil estabelecer a qual tipo entidade pertence atributo, pois o mesmo é definido apenas pela existência do relacionamento. Quando temos relacionamentos com cardinalidade 1:1, podemos colocar o atributo em uma das entidades, de preferência, em uma cujo tipo entidade tenha participação 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, então podemos colocar o atributo no tipo entidade com participação N. Porém, se a cardinalidade for N:M, então o atributo deverá mesmo ficar no tipo relação. Veja o exemplo da figura que aparecem

“Empregados” e “Projetos”. Caso queiramos armazenar quantas horas cada empregado

trabalhou em cada projeto, então 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 não conseguimos armazenar

algumas informações em um ou em outra entidade, utilizamos uma terceira (entidade-relacionamento) para armazená-las.

p3 p2 p1 e4 e3 e2 8e1 EMPREGADO Trabalha Em PROJETO

24

Um bom exemplo disso é o relacionamento entre MÉDICOS e PACIENTES. Um médico possui muitos pacientes e um paciente possui muitos médicos. Algumas informações não são possíveis de serem armazenadas nem em médicos nem tampouco em pacientes. A data da consulta, por exemplo, o diagnóstico, etc. Se colocamos em médicos, ele tem vários pacientes e estas informações ficarão falhas, se colocamos em pacientes, se ele fez várias consultas e só possuímos um espaço, ou seja, um campo para armazenar cada informação, também ficará falha. Portanto, será necessário a utilização da entidade-relacionamento CONSULTAS para armazenarmos estas informações específicas de CONSULTAS.

 5.3.2.3 Tipos Entidades Fracas

Alguns tipos entidade podem não ter um atributo chave por si só. Isto implica que não poderemos distinguir algumas entidades por que as combinações dos valores de seus atributos podem ser idênticas. Estes tipos entidade são chamados entidades fracas. As entidades deste tipo precisam estar relacionadas com uma entidade pertencente ao tipo entidade proprietária. Este relacionamento é chamado de relacionamento identificador. Veja o exemplo abaixo.

Figura 13 _–Entidade fraca

O tipo entidade DEPENDENTE é uma entidade fraca, pois não possui um método de identificar uma entidade única. O EMPREGADO não é uma entidade fraca, pois possui um atributo para identificação (atributo chave). O número do RG de um empregado identifica um único empregado. Porém, um dependente de 5 anos de idade não possui necessariamente um documento. Desta forma, esta entidade é um tipo entidade fraca. Um tipo entidade fraca possui uma chave parcial, que juntamente com a

DEPENDENTE p3 p2 p1 e2 e1 EMPREGADO Possui Dependentes

25

chave primária da entidade proprietária forma uma chave primária composta. Neste exemplo: a chave primária do EMPREGADO é o RG. A chave parcial do DEPENDENTE é o seu nome, pois dois irmãos não podem ter o mesmo nome. Desta forma, a chave primária desta entidade fica sendo o RG do pai ou mãe mais o nome do dependente.

Algumas características marcantes nas entidades fracas são o fato de sua chave primária 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 binários, ou seja, entre dois tipos entidades diferentes ou recursivos. Porém, o modelo entidade relacionamento não se restringe apenas à relacionamentos binários. O número de entidades que participam de um tipo relacionamento é irrestrito e armazenam muito mais informações do que diversos relacionamentos binários. Considere o seguinte exemplo:

Um motorista pode efetuar uma viagem para uma localidade dirigindo um determinado caminhão em uma determinada data.

26

Se efetuarmos três relacionamentos binários, não teremos estas informações de forma completa como se criássemos um relacionamento ternário. 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 gráficos que visa representar todos os objetos do Modelo Entidade Relacionamento tais como entidades, atributos, atributos chaves, relacionamentos, restrições estruturais, etc.

O DER fornece uma visão lógica do banco de dados, fornecendo um conceito mais generalizado de como estão estruturados os dados de um sistema.

Os objetos que compõem o D ER estão listados na figura a seguir.

27

5.5 Normalização

Normalização é uma técnica de projeto de banco de dados que visa, a partir dos dados existentes na organização, construir relações (tabelas) livres de redundância e passíveis 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 normalização passa por diversas etapas conhecidas como formas normais. Veja um exemplo.

Seja a seguinte relação não normalizada:

Funcionários (Código Funcionário, Nome, Endereço, Cidade, UF, CEP, Departamento, (Código Curso, Curso, Data, Grau))

Obs.: Os atributos Código Curso, Curso, Data e Grau estão entre parênteses porque se repetem muitas vezes na ficha do funcionário.

5.5.1 Primeira Forma Normal – 1FN

Uma relação estará na primeira forma normal se e somente se todos os seus atributos possuírem valores atômicos (únicos).

Funcionários (Código Funcionário, Nome, Endereço, Cidade, UF, CEP, Departamento).

CursosFuncionário ( Código Funcionário#, Código Curso, Curso, Data, Grau ). Obs.: Os atributos que se repetem (valores não únicos) formam uma nova relação. A chave primária da primeira relação (relação origem) deve ser levada para a nova relação. Para a nova relação devemos definir uma chave primária.

5.5.2 Segunda forma normal _– 2FN

Uma relação 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 primária, ou seja, nenhum atributo pode ser dependente parcial da chave primária.

28

Funcionários (Código Funcionário, Nome, Endereço, Cidade, UF, CEP, Departamento).

CursosFuncionário ( Código Funcionário#, Código Curso#, Data). Cursos (Código Curso, Curso, Grau).

Obs.: O atributo Curso é dependente apenas de Código Curso, por isso foi retirado e passou a integrar uma nova tabela de Cursos onde o atributo que gera a dependência funcional, Código Curso, é trazido como chave primária.

5.5.3 Terceira forma normal _– 3FN

Uma relação estará na terceira forma normal se e somente se estiver na segunda forma normal e nenhum de seus atributos for dependente transitivo da chave primária, ou seja, nenhum atributo pode depender de outro atributo que não é chave.

Funcionários (Código Funcionário, Nome, Endereço, CEP#, Departamento). Cidades (CEP, Cidade, UF).

CursosFuncionário ( Código Funcionário#, Código Curso#, Data). Cursos (Código Curso, Curso, Grau).

Obs.: Os atributos Cidade e UF além de dependerem da chave primária Código Funcionário são dependentes do atributo CEP, portanto passam a constituir uma nova tabela tendo como chave primária o CEP.

5.5.4 Quarta forma normal – 4FN

Uma relação estará na quarta forma normal se e somente se estiver na terceira forma normal e nenhum de seus atributos for dependente multivalorado da chave primária, ou seja, possuir um conteúdo comum a muitas tuplas da relação.

Funcionários (Código Funcionário, Nome, Endereço, CEP#, Código Depto#). Cidades (CEP, Cidade, UF).

29

CursosFuncionário ( Código Funcionário#, Código Curso#, Data, Grau ). Cursos (Código Curso, Curso).

Deptos (Código Depto, Departamento).

Obs.: O atributo Departamento é dependente multivalorado do Código Funcionário, pois ele ocorre repetidamente em várias tuplas da relação Funcionário. Para solucionar esta dependência cria-se uma nova tabela com o atributo Departamento, gerando um novo atributo para constituir a chave primária desta nova tabela, Código Depto.

6 MODELO FÍSICO DE BANCO DE DADOS