Modelagem de Dados.pdf

Modelagem de Dados Aula 01

Os direitos desta obra foram cedidos à Universidade Nove de Julho

Este material é parte integrante da disciplina oferecida pela UNINOVE. O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de discussão e a comunicação com o professor devem ser feitos diretamente no ambiente virtu virtual al de aprendizagem aprendizagem UNINOV UNINOVE E.

Uso Uso consciente do pape papel.l. Cause boa impressão, imprima menos.



AULA AUL A 1

OBJETIVOS

Apresentar os conceitos iniciais sobre bancos de dados e sua importância para as organizações. Conceituar a diferença entre dado e informação. Apresentar as diferenças entre sistemas baseados em arquivos e sistemas gerenciadores de banco de dados.

CONCEITOS CONCEITOS BÁSICO BÁ SICOS S DE BANCOS B ANCOS DE DADOS Considerações Considerações iniciais

A modelagem de dados faz parte de uma etapa muito importante do desenvolvimento de sistemas, na qual se desenha toda a estrutura dos dados que envolvem uma atividade humana a ser informatizada. O estudo feito sobre a modelagem de dados serve tanto para uma pequena atividade comercial como para uma uma grande organização. organização. A modelagem de dados antecede a construção do banco de dados em um meio computacional, ela mostra a estrutura do banco de dados, seja do ponto de vista do usuário como da sua forma física. Introdução Introd ução ao banco de dados

Um banco de dados é um conjunto de elementos extraídos a partir de informações do mundo real. Esses dados são organizados, classificados e relacionados de forma que possam gerar novas informações para o mundo real. O nome banco de dados teve sua origem na tradução da palavra inglesa data banks e mais tarde foi modificada por database , que significa base de dados .

O século XXI está marcado pela “Era da Informação Digital”. O mundo dos negócios, o sucesso das empresas, o comércio e a educação de um país dependem de um elemento vital: a informação . As informações podem justificar fatos que contribuem para a formação do conhecimento e a tomada de decisões. A informática se preocupa em gerar a informação por meio de tecnologia ágil e eficaz para que esteja ao alcance de todos. O banco de dados é um grande responsável pelo processo. A montagem adequada, seguida de regras e métodos permite que os dados extraídos sejam corretos e as informações geradas sejam espelho da realidade.

Dado e inf ormação, qual a diferença?

O dado identifica ou quantifica algo, é absoluto e objetivo. A informação tem um significado para o mundo real, tem valor relativo ou é uma qualificação do dado. A informação pode ter um ou mais dados. Quando um dado lembra um fato associado,

ele vira informação. Certos nomes de pessoas ou lugares que ficaram famosos pelos seus fatos se tornaram ícones e agregam valores, por exemplo, Ronaldinho. Exemplos de informações: O aluno Mario Silva é casado com Laura, mora na Rua Abraão Lins, 230. Ele nasceu no bairro da Bela Vista em São Paulo e sua profissão é vendedor. Estas informações possuem vários dados envolvidos e o seu conjunto tem um significado para o mundo real. Examinando a frase, quais os dados que poderiam ser extraídos?

Se misturarmos os dados poderá não significar nada para nós que estamos lendo a frase. Laura Bernardes, vendedor, Mario Silva, Rua Abraão Lins 230, São Paulo, Bela Vista. Para que esses dados possam ser resgatados de um banco, é necessário classificálos, organizá-los e relacioná-los; caso contrário, teremos um “banco de dados insignificante”. Classificando os dados, teremos:

Nome do aluno: Mario Silva

Endereço: Rua Abraão Lins , 230

Local de nascimento: Bela Vista

UF de nascimento: São Paulo

Profissão: Vendedor

Cônjuge: Laura Bernardes

Vamos analisar agora outro exemplo: “O inverno do Canadá é mais frio que o inverno brasileiro.” Essa é uma informação que pode ter significado para o mundo real. Nela está implícita a comparação das temperaturas mínimas dos dois países. Se criarmos uma tabela de países e suas temperaturas mínimas em um determinado ano, teremos os seguintes dados: Países Brasil Canadá França

Temperatur a Mínima +8º C - 43º C - 3º C

A tabela contém dados: Canadá, Brasil, França; e a palavra países é apenas uma classificação desses dados, bem como - 3 º C, - 43 º C e + 8 º C, que também são dados classificados como temperatura mínima. A informação é uma mensagem significativa que nos leva a associar fatos do mundo real. O dado, por si só, não tem significado algum, ele apenas identifica algo. As comparações e as conclusões que tiramos dos dados geram informações. A afirmativa acima poderia ser concluída por um turista que sentiu na pele o frio dos dois países, mas se quisermos saber se realmente é verdadeira, precisamos comparar os dados da tabela ou repetiremos a mesma experiência de quem passou a informação. O banco de dados é formado por um conjunto de elementos organizados em forma de tabelas e relacionados entre si, de acordo com o significado que eles têm no mundo real. Se os dados e os seus relacionamentos são verdadeiros, as informações que obtemos deles também serão verdadeiras.

Formas de armazenamento de dados

Podemos armazenar os dados de uma aplicação de duas maneiras: 1. Sistema de armazenamento em arquivos

O que é um arquivo? É uma forma que os sistemas operacionais utilizam para armazenar e organizar os dados em meio permanente. Um arquivo é composto por uma identificação e um conjunto de dados agrupados em forma de registros. Cada registro é formado por campos em que esses dados são armazenados, por exemplo, imagine um arquivo para armazenar os dados de funcionários. Cada funcionário tem seus dados dentro de um registro do arquivo.

Os arquivos são criados e mantidos pelos programas desenvolvidos em uma linguagem que o programador escolhe para desenvolvê-los. Os dados somente podem ser acessados em um programa da mesma linguagem em que foram gerados ou algum programa compatível. Os arquivos são dependentes da linguagem em que foram criados. Em uma organização, os sistemas baseados em arquivos apresentam as seguintes desvantagens :

•

Inconsistência e redundância de dados :

Uma vez que os arquivos são mantidos por aplicações feitas por vários programadores, ao longo do tempo, com as mudanças que as empresas enfrentam, é comum haver alteração dos formatos e criação de arquivos para novas implementações. Assim, os dados se repetem, pois cada aplicação possui a sua forma de armazenamento. •

Dificuldade de acesso aos dados :

Toda vez que o usuário necessita de outra forma de acesso aos dados, diferente da que o sistema oferece, o programador precisa mudar o programa ou, muitas vezes, desenvolver outro para atender ao usuário. Isso tem um custo elevado de desenvolvimento para as empresas, além do tempo gasto para elaborá-lo, na maioria das vezes, há urgência em receber os dados, retardando a tomada de decisões. •

Isolamento dos dados :

Como os dados estão armazenados em arquivos independentes, é possível que, ao tentar acessá-los de outro arquivo com formato diferente, não seja possível ou haja necessidade de criar novas aplicações para compatibilizá-los. •

Falta de integri dade:

Uma aplicação de usuário geralmente é feita por vários arquivos e existe sempre uma dependência e uma relação entre os dados de um arquivo para outro. Se o programador não se preocupar, ou não conhecer essa dependência, correrá o risco de criar programas que, ao buscar dados, resultem em uma pesquisa errada, ocasionando danos à empresa.

•

Falta de atomici dade:

Transação atômica – em computação – significa que, em uma interrupção qualquer no sistema por falha técnica, essa transação deve ser completada ou abortada, ou seja, todos os arquivos devem ser atualizados automaticamente ou retornados à situação anterior. No sistema baseado em arquivos, esta preocupação recai na mão dos programadores, que devem criar mecanismos de tratamento a falhas. Se a empresa não possui uma política de padronização das ações a serem tomadas, o programador pode errar no processo, afetando os dados. •

Falta de segur ança:

Os sistemas baseados em arquivos dependem da proteção do sistema operacional e das permissões de acesso ao dispositivo onde estão armazenados. O programador poderá ter se lembrado de criar senha na sua aplicação, mas se outro programador tentar criar um programa para acessar o mesmo arquivo, sem proteção alguma, este fica vulnerável a modificações indesejadas, que normalmente são feitas pelos usuários. 2. Sistema de banco de dados

Um Sistema de Gerenciamento de Banco de Dados (SGBD) consiste em uma coleção de dados inter-relacionados e um conjunto de programas que fazem acesso aos dados. Os SGBDs são concebidos para gerenciar desde um pequeno conjunto de dados até um grande volume. Oferecem as estruturas para armazenamento e todos os mecanismos para manipulação, ou seja, inclusão, alteração, exclusão, seleção e busca dos dados. A estrutura é criada pelos analistas de banco de dados ou pelos desenvolvedores de sistemas aplicativos para o usuário final ter fácil acesso.

Por que usar um si stema de banco de dados?

Os primeiros sistemas de armazenamento de dados eram baseados em arquivos. Os SGBDs surgiram para eliminar todos os problemas apontados como desvantagens na utilização dos sistemas baseados em arquivos. Os sistemas de gerenciamento de banco de dados possuem as seguintes vantagens :

•

Integridade dos dados.

•

Segurança de acesso aos dados.

•

Atomicidade nas transações.

•

Concentração dos dados em um repositório, geralmente em um servidor de dados.

•

Independência de linguagem de programação.

•

Impõem regras de utilização para toda e qualquer aplicação que se conectar ao banco de dados.

Observação

Os nomes das entidades e de seus respectivos atributos não foram acentuados, pois não se recomenda utilizar acentos para denominar tabelas e colunas (de tabelas) em bancos de dados. REFERÊNCIAS

CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron Books, 1990. DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus, 1991. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005.

HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004. SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard Blücher, 2005. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 3. ed. São Paulo: Makron Books, 1999.



Este material é parte integrante da disciplina oferecida pela UNINOVE. O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de discussão e a comunicação com o professor devem ser feitos diretamente no ambiente virtual de aprendizagem UNINOVE.

Uso consciente do papel. Cause boa impressão, imprima menos.

AULA 2 OBJETIVOS Apresentar os modelos de dados em rede, hierárquicos, relacionais e orientados a objetos. Demonstrar as etapas de desenvolvimento de um projeto de banco de dados.

ETAPAS DA ELABORAÇÃO DE UM PROJETO DE BANCO DE DADOS Introdução Os modelos de dados especificam a estrutura lógica dos dados. Os formatos mais conhecidos são:

•

Hierárquico.

•

Rede.

•

Relacional.

•

Orientado a objetos.

Modelo hierárquico Surgiu na década de 1960 com a primeira linguagem de banco de dados: a DL/I desenvolvida pela IBM e a North American Aviation. Organiza os dados de cima para baixo, como uma árvore. Cada registro é dividido em partes denominadas segmentos. O banco de dados se assemelha a um organograma com um segmento raiz e um número qualquer de segmentos subordinados.

Modelo em rede Definido pelo DBTG (Data Base Task Group) do comitê do CODASYL (Conference on Data Systems Language) a partir de 1971. Esse modelo é uma extensão do modelo hierárquico. Nos modelos baseados em rede, os dados são agrupados em forma de registros em que um aponta para outro por meio de ponteiros (links), exemplo:

Modelo relacional O modelo relacional é um conjunto de tabelas relacionadas entre si por meio dos próprios dados, não utilizando ponteiros para ligar os registros. Veja o mesmo exemplo usando o modelo relacional:

Modelo orientado a objetos Um objeto que representa algo no mundo real possui dados que o identificam e funções que ele pode executar. As funções são escritas com uma linguagem de programação. Os dados são chamados de atributos e as funções de métodos. As classes são definições de como os objetos deverão ser. Cada objeto é uma instância de uma determinada classe, um exemplo análogo: “A receita de um bolo é uma classe e o bolo é o objeto dessa classe. A partir de uma única receita podemos gerar vários bolos.”

Etapas de elaboração de um proj eto de banco de dados

Um projeto de banco de dados é constituído por três níveis de abstração: 1. Modelo conceitual. 2. Modelo lógico. 3. Modelo físico. O modelo lógico, que será estudado em detalhes nas próximas aulas, refere-se especificamente ao modelo relacional , pois ainda é o mais usado atualmente.

Análi se d e req uisitos O primeiro passo para modelar os dados é fazer a análise de requisitos, ou seja, descrever todas as informações necessárias para extrair os dados que deverão compor o banco de dados. A descrição a seguir é um roteiro de necessidades que devem ser levantadas.

•

Quais os problemas que o banco de dados poderá solucionar.

•

Qual o objetivo de criar um banco de dados para aquela realidade específica, ou seja, os resultados esperados.

•

Quais as informações que desejamos saber do banco de dados.

•

Quais as regras de negócio.

•

Quem está participando diretamente e indiretamente no negócio.

•

Verificar documentos que formalizam a negociação: notas, contratos, pedidos etc.

•

Dados relevantes, casos de sucesso ou fracasso, pertinentes à problemática.

•

Datas críticas.

•

Restrições de dados.

Roger Pressman, em seu livro Engenharia de Software, descreve algumas características que um analista deve ter para fazer uma análise de requisitos com sucesso, uma vez que o usuário geralmente é leigo em informática:

•

A capacidade de compreender conceitos abstratos, reorganizá-los em divisões lógicas e sintetizar “soluções” baseadas em cada divisão.

•

A capacidade de absorver fatos pertinentes de fontes conflitantes.

•

A capacidade de entender os ambientes do usuário/cliente.

•

A capacidade de aplicar elementos do sistema de hardware e/ou software aos elementos do usuário/cliente.

•

A capacidade de se comunicar bem nas formas escrita e verbal.

Modelo conceitual Para representar o modelo conceitual de dados usaremos o Modelo EntidadeRelacionamento (MER) criado por Peter Chen, em 1976, baseado na teoria relacional desenvolvida por E. F. Codd em 1970. O MER surgiu para padronizar a modelagem de dados por meio de diagramas, assim, qualquer profissional poderia ler e compreender toda a sua estrutura, sem mesmo conhecer a realidade a que se referia. A padronização facilita a criação de ferramentas CASE (Computer Aided Software Engineering), programas usados na engenharia de software para auxiliar no desenvolvimento de sistemas. O MER (Modelo Entidade-Relacionamento) tem como princípio a representação do mundo real em forma de objetos dos quais queremos obter informações. Estes objetos recebem o nome de entidades. Para desenhar o modelo conceitual, usamos um diagrama com símbolos para representar as entidades, os atributos e descrever os relacionamentos. Simbologia do Diagrama Entidade Relacionamento (DER)

REFERÊNCIAS CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron Books, 1990.

DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus, 1991. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005. HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004. PRESSMAN, Roger S. Engenharia de software. São Paulo: Makron Books, 1995. SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard Blücher, 2005. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 3. ed. São Paulo: Makron Books, 1999.





AULA 3

OBJETIVO

Desenvolver a percepção de entidades, atributos e relacionamentos, utilizando o DER (Diagrama Entidade Relacionamento).

ENTIDADES, ATRIBUTOS E RELACIONAMENTOS Entidade

Conjunto de objetos do mundo real dos quais queremos manter informações no banco de dados. As entidades representam os agentes que interagem em um relacionamento. Podem representar pessoas, documentos (pedidos, notas fiscais etc.), objetos e resultado de ações. Observe os exemplos a seguir:

Atri buto

Representa um dado associado a cada ocorrência de uma entidade ou de um relacionamento.

Relacionamento

É o conjunto de associações entre entidades.

Exemplo: clínica médica. Suponha que você tenha sido convidado para fazer a modelagem de dados de um sistema para uma clínica médica. Tomando como exemplo essa clínica, vamos começar a fazer a modelagem dos dados. Inicialmente, vamos identificar algumas entidades envolvidas e analisar seu relacionamento. A atividade exercida na clínica envolve o médico consultar o paciente. Nessa ação encontramos duas entidades: médico e paciente e o relacionamento é o ato de consultar. Desenhando o diagrama temos:

Uma entidade possui um conjunto de atributos, cada atributo está associado a um tipo de dado, por exemplo, para que cada médico seja identificado, precisamos dos seguintes dados: CRM, nome, especialidade e telefone. Esses são os atributos da entidade MÉDICO.

Quando o paciente chega para sua primeira consulta, é necessário que ele informe seu CPF, nome, telefone e data de nascimento. Esses são os atributos da entidade PACIENTE. Vamos desenhar os atributos no diagrama:

No banco de dados, a entidade representa uma tabela de dados. Desenhando as entidades em forma de tabela, teremos: MÉDICO CRM

12345 54321 23451

NOME

TELEFONE

Dr. Maurício Pereira Dra. Patrícia Peres Dr. Hildebrando Alves

5125-4562 5264-9874 5689-5454

ESPECIALIDADE

clínico geral pediatra cardiologista

PACIENTE CPF

00111222333-44 22333444555-66 99888777666-55

NOME

Mauro Souza Lucia Prado Maria Gomes

TELEFONE

DATA_NASC

5521-6245 5642-7893 5967-8245

10/02/1985 12/11/1975 15/05/1995

As tabelas são as representações das entidades, contendo os dados armazenados. Essa é uma visão lógica dos dados no banco de dados.

A modelagem de dados ainda não está pronta, precisamos agora identificar quais as outras entidades envolvidas e aquelas associadas aos relacionamentos que aparecem durante a análise. REFERÊNCIAS

CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron Books, 1990. DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus, 1991. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005. HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004. SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard Blücher, 2005. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 3. ed. São Paulo: Makron Books, 1999.





AULA 4 OBJETIVO

Apresentar os conceitos de cardinalidade dos relacionamentos para a elaboração do DER. Apresentar como deve ser feito o questionamento em cada entidade para descobrir qual o grau de cardinalidade.

CARDINALIDADE MÍNIMA E MÁXIMA E GRAU DE CARDINALIDADE Na aula anterior, vimos os conceitos de entidade, atributo e relacionamento. Agora, vamos analisar a quantidade de ocorrências de uma entidade associada à outra por meio de um relacionamento. Isso é chamado de cardinalidade. Cardinalidade

É o número (mínimo/máximo) de ocorrências de uma entidade associada a uma ocorrência de outra entidade por meio de um relacionamento. Cardinalidade mínima

Indica o número mínimo de ocorrências de uma entidade associada à outra ocorrência da outra entidade relacionada. Pode ser representada por 0 (zero) quando a associação é opcional (não existe correspondente na outra entidade) ou 1 (um) quando a associação é obrigatória (pelo menos um correspondente na outra entidade). Cardinalidade máxima

Indica o número máximo de ocorrências de uma entidade associada à outra ocorrência de outra entidade relacionada. É representado por 1 (um) ou N (várias ou muitas).

Exemplo:

No exemplo apresentado, vamos imaginar duas entidades, uma de homens e outra de mulheres, alguns homens são casados com mulheres da outra entidade e outros não. Da mesma forma, algumas mulheres são casadas, outras não. Para identificar a cardinalidade, deve ser feita a pergunta de uma entidade para outra. Um homem pode ser casado no mínimo com quantas mulheres da outra entidade? E no máximo (legalmente!)?

Uma mulher pode ser casada no mínimo com quantos homens da outra entidade? E no máximo (legalmente!)?

Quando usamos a cardinalidade mínima e máxima, devemos escrever da seguinte forma: mínima, máxima. Observe agora outro exemplo:

Uma empresa possui funcionários e seus dependentes; nem todo funcionário possui dependentes, mas todos os dependentes têm algum funcionário associado. Vamos colocar a cardinalidade analisando primeiro a entidade funcionário . Um funcionário possui no mínimo 0 (nenhum) dependente.

Um funcionário possui no máximo N (vários) dependentes.

Agora, analisando a entidade dependente: Um dependente tem no mínimo 1 (um) funcionário associado.

Um dependente tem no máximo 1 (um) funcionário associado.

Acesse o ambiente virtual de aprendizagem UNINOVE para a visualização do slideshow que explica passo a passo como interpretar cardinalidades em um DER. Grau de cardinalidade

Grau de cardinalidade refere-se à cardinalidade máxima, observando-se ambos os sentidos. Portanto, podemos encontrar os seguintes graus de cardinalidade: 1:1 (um p ara um)

Uma ocorrência da entidade 1 se relaciona no máximo com apenas uma ocorrência da entidade 2 e uma ocorrência da entidade 2 se relaciona no máximo com apenas uma ocorrência da entidade 1.

1:N (um para muitos)

Uma ocorrência da entidade 1 se relaciona com muitas ocorrências da entidade 2 e uma ocorrência da entidade 2 se relaciona com apenas uma ocorrência da entidade 1.

N:N (muitos para muitos)

Uma ocorrência da entidade 1 se relaciona com muitas ocorrências da entidade 2 e uma ocorrência da entidade 2 se relaciona com muitas ocorrências da entidade 1.

REFERÊNCIAS






AULA 5 OBJETIVO Apresentar os diversos graus de relacionamentos: binários, autorrelacionamentos e ternários (n-ários).

GRAUS DE RELACIONAMENTOS Introdução O grau de um relacionamento refere-se ao número de entidades que participam de um relacionamento. Observe a seguir os diversos graus de relacionamentos:

Relacionamento binário Um relacionamento binário é aquele envolve duas ocorrências de entidade. Conforme observado na aula anterior, podemos classificar os relacionamentos binários em:

•

1:1 (um-para-um): cada ocorrência de uma entidade relaciona-se com uma e somente uma ocorrência da outra entidade.

•

1:N (um-para-muitos): uma ocorrência da entidade 1 relaciona-se com muitas ocorrências da entidade 2, mas cada ocorrência da entidade 2 somente pode estar relacionada com uma ocorrência da entidade 1.

•

N:N (muitos-para-muitos): em ambos os sentidos encontramos um ou mais relacionamentos de um-para-muitos, isto é, uma ocorrência da entidade 1 relaciona-se com muitas ocorrências da entidade 2 e vice-versa.

Relacionamento ternário Denominamos ternários os relacionamentos entre três conjuntos de entidades. Relacionamentos com quatro ou mais conjuntos de entidades são chamados de n-ários, porém, sua utilização não é recomendada em virtude de sua complexidade. Sugere-se que sejam “quebrados” em relacionamentos binários e/ou ternários. No exemplo a seguir, queremos garantir que a seguinte situação seja representada de forma apropriada: o professor x ministra a disciplina y para a turma z. Esta condição deve ser representada por meio de um relacionamento ternário.

Observe que, no exemplo apresentado, cada par de ocorrências (turma, disciplina) está associado a, no máximo, um professor. Podem estar associadas muitas disciplinas a um par (turma, professor), ou, em outros termos, um professor pode ministrar a uma determinada turma várias disciplinas. Podem estar associadas muitas turmas a um par (disciplina, professor), ou, em outros termos, um professor pode ministrar uma determinada disciplina a várias turmas.

Autorrel aci onamento Representa o relacionamento entre ocorrências de uma mesma entidade.

•

Autorrelac ionament o 1:1

O diagrama a seguir representa a seguinte situação: uma ocorrência de pessoa exerce o papel de marido e outra ocorrência de pessoa exerce o papel de esposa. Uma pessoa pode ter no máximo um cônjuge (marido ou esposa).

•

Autorrelac ionament o 1: N

A seguir, temos representada a seguinte situação: uma ocorrência de funcionário exerce o papel de supervisor e outras ocorrências de funcionário exercem o papel de supervisionado. Um supervisor pode ter muitos supervisionados, mas cada supervisionado tem apenas um supervisor.

•

Autorrelac ionamento N: N

E, finalmente, temos representada a seguinte situação: algumas ocorrências de produto exercem o papel de composto e outras ocorrências exercem o papel de componente. Um produto pode entrar na composição de muitos outros produtos e cada produto é composto por vários (muitos) outros.

REFERÊNCIAS CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron Books, 1990. DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus, 1991. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005. HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004. MULLER, Robert J . Projeto de Banco de Dados: Usando UML para modelagem de dados. São Paulo: Berkeley Brasil, 2002. SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard Blücher, 2005. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 3. ed. São Paulo: Makron Books, 1999.





AULA 6 OBJETIVO Atribuir propriedades particulares a entidades por meio do conceito de generalização e especialização de seus atributos.

GENERALIZAÇÃO E ESPECIALIZAÇÃO Conceitos básicos de generalização e especialização Algumas entidades podem apresentar ocorrências em que uma parte delas possui as mesmas propriedades e a outra parte possui propriedades diferentes, sendo necessário separá-las em subgrupos (especializações). Usando o conceito de generalização e especialização, podemos subdividir uma entidade em várias outras de acordo com o significado dos seus dados. O símbolo usado é um triângulo e para definir o tipo utilizamos (t) total e (p) parcial. Podemos ver, no exemplo a seguir, que a entidade cliente de uma empresa pode ter ocorrências de pessoa jurídica e ocorrências de pessoa física; ambas podem ter nome, código e outros atributos em comum, mas possuem também atributos que as diferenciam, como CPF e RG. Esses atributos somente o cliente pessoa física possui, enquanto que CNPJ e Inscrição Estadual pertencem apenas ao cliente pessoa jurídica. Para que a entidade cliente não seja definida com todos os atributos em que uma possua determinados dados e outra não, separa-se a entidade cliente em duas para melhor organização: pessoa física e pessoa jurídica.

A generalização/especialização está associada à herança porque as entidades especializadas, além dos seus próprios atributos, possuem também todos os da entidade generalizada. No exemplo, cada ocorrência de pessoa física possui: código , nome, RG e CPF, enquanto as ocorrências de pessoa jurídica possuem: código , nome, CNPJ e

INSC_EST. A generalização/especialização pode ser classificada em dois tipos: total e parcial.

Total (t) Quando cada ocorrência da entidade generalizada possui obrigatoriamente uma ocorrência correspondente a alguma das entidades especializadas. Cada cliente ou é pessoa jurídica ou é pessoa física, não existe um que não seja nenhuma das duas, conforme exemplo. O símbolo usado é a letra t .

Parcial (p) A generalização/especialização é parcial quando existem ocorrências na entidade genérica que não possuem ocorrências correspondentes na entidade especializada. Vejamos um exemplo:

Nesse caso, nem todo funcionário é engenheiro ou advogado. Algumas ocorrências existem apenas na entidade genérica.

Generalização e especiali zação em vários níveis Pode ocorrer que uma entidade genérica tenha várias entidades especializadas que, por sua vez, também generalizem outras entidades especializadas. Não há limite no número de níveis hierárquicos.

No exemplo apresentado, a pessoa física pode ser nativa do país em questão ou pode ser estrangeira. Cada uma possui documentos diferentes, mas pertence à mesma entidade genérica pessoa física. Pode-se observar que ambas possuem CPF e carteira profissional.

Herança múltipla Podem existir casos em que uma entidade seja especialização de várias entidades genéricas, então, dizemos que a entidade possui herança múltipla de atributos.

Observe o exemplo a seguir:

A entidade veículo anfíbio é uma especialização da entidade genérica veículo

terrestre e da entidade genérica veículo aquático , portanto, possui uma herança múltipla por especializar mais de uma entidade genérica.

REFERÊNCIAS CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron Books, 1990. DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus, 1991. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005. HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004. MULLER, Robert J . Projeto de Banco de Dados: Usando UML para modelagem de dados. São Paulo: Berkeley Brasil, 2002.

SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard Blücher, 2005. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 3. ed. São Paulo: Makron Books, 1999.





AUL A 7

OBJETIVO

Identificar uma entidade associativa em um relacionamento de N para N.

ENTIDADE ASSOCIATIVA

A entidade associativa surge de um relacionamento de N para N, no qual existe uma associação dos atributos identificadores das duas entidades relacionadas, caracterizando uma nova entidade. A nova entidade gerada possui, normalmente, atributos próprios do relacionamento, isto é, ela só existe por causa do relacionamento.

Tomando-se como exemplo, novamente, uma clínica médica, observamos o seguinte:

•

Um médico pode consultar N pacientes.

•

Um paciente pode ser consultado por N médicos.

•

Uma consulta é realizada em uma data e em um horário; possui um preço; pode ser paga por convênio ou pelo paciente; apresenta uma prescrição do médico e a relação de medicamentos. Esses são alguns atributos que pertencem apenas ao relacionamento CONSULTA.

Toda entidade possui um atributo identificador a partir do qual é feito o relacionamento das entidades. Ele é único e identifica cada ocorrência da entidade.

No diagrama a seguir, os atributos identificadores são: CRM e ID_Paciente.

No caso dos relacionamentos de N para N, não é possível transportar o atributo identificador de uma entidade para a outra que está relacionada, pois, assim, estariam sendo repetidos dados desnecessários.

Nesse caso, cria-se uma terceira entidade, chamada consulta, contendo os seguintes atributos: CRM, ID_Paciente, data e hora.

No banco de dados, procura-se escrever o dado uma única vez e relacioná-lo com as demais entidades. Utilizando o exemplo da clínica médica, o nome de um médico deve ser apenas uma ocorrência na tabela de médico dentro do banco de dados. Embora a consulta tenha o médico responsável, não é necessário um atributo nome do médico, devemos substituí-lo por seu CRM, pois esse atributo o identifica dentro da entidade MEDICO. Do mesmo modo, o nome do paciente não precisa estar na entidade CONSULTA. Transformamos um relacionamento de duas entidades de N para N acrescentando uma entidade e desmembrando o relacionamento. Os atributos identificadores CRM e ID_PACIENTE são transportados para a nova entidade CONSULTA, acrescentando os outros atributos pertencentes à consulta.

Ao ligarmos as duas entidades, é possível notar que a cardinalidade deixa de ser de N para N. Cada médico pode fazer N consultas, mas uma consulta é feita com apenas 1 médico. Cada paciente pode fazer N consultas, mas cada consulta é feita com apenas 1 paciente. A entidade CONSULTA é formada por identificadores de outras entidades, portanto, trata-se de uma entidade dependente, pois ela não existiria se não houvesse o relacionamento. A entidade gerada por atributos identificadores de outras entidades também é chamada de entidade fraca. A entidade fraca é identificada graficamente pelo retângulo de linha dupla, embora alguns autores prefiram utilizar a linha que liga a entidade ao relacionamento, em negrito. Observe os diagramas a seguir:

ou

REFERÊNCIAS

CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron Books, 1990. DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus, 1991. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005. HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 3. ed. São Paulo: Makron Books, 1999.





AULA 8

OBJETIVO

Apresentar a próxima etapa da modelagem de dados: o modelo lógico e os conceitos de tabelas, chaves primárias e estrangeiras e como o banco de dados mantém controle sobre os dados relacionados.

MODELO LÓGICO: TABELAS, CHAVES PRIMÁRIAS E ESTRANGEIRAS

A próxima etapa do projeto de banco de dados envolve o chamado modelo lógico . Atualmente, grande parte dos sistemas de banco de dados utiliza o modelo relacional . Um banco de dados relacional é composto por tabelas (também

denominadas relações). Observe a seguir alguns conceitos importantes para pleno entendimento do modelo relacional: Tabela

Estrutura bidimensional composta por linhas (tuplas) e campos (ou atributos).

Chave primária

Atributo por meio do qual é possível identificar determinado registro. Uma chave primária não pode ser repetida, ou seja, o conjunto de valores que constituem a chave primária deve ser único dentro de uma tabela. Chave primária simples: apenas um atributo (campo) compõe a chave primária. Chave primária composta: mais de um atributo compõe a chave primária.

Na aula anterior falamos sobre atributo identificador, responsável por identificar uma ocorrência na entidade. Trata-se de um atributo em que não se encontra duplicidade de dados. O atributo identificador corresponde normalmente à chave primária no modelo lógico (relacional). Portanto, para escolher uma chave primária é preciso certificar-se de que esse atributo não terá duplicidade .

Chave estr angeira

Utilizada quando queremos que o valor de um atributo seja validado a partir do valor de atributo de outra tabela. Criamos, assim, uma relação de dependência (um relacionamento) entre as tabelas. Observe que, no exemplo a seguir, antes de efetuar a alocação de um funcionário em um departamento , é necessário que o departamento em questão conste na tabela de departamentos.

Para que haja equivalência, o conteúdo da chave estrangeira deve ser igual ao da chave primária. O SGBD (Sistema de Gerenciamento de Banco de Dados) “liga” todos os registros em que o conteúdo da chave primária seja igual ao de sua chave estrangeira. Acesse o ambiente virtual de aprendizagem UNINOVE para a visualização do Infográfico sobre chave estrangeira. Chave única (Unique)

Utilizada quando determinado campo não deve ser repetido e não é chave primária. Aumenta a consistência do banco de dados. Exemplo: cadastro de funcionários. Cada funcionário recebe um código único, que é a chave primária. Para maior segurança e consistência, podemos optar para que o campo CPF também seja único, evitando que o mesmo funcionário seja cadastrado duas vezes.

Notação resumida

Notação compacta, útil para discussões sobre a estrutura geral do banco de dados, utilizada quando não se deseja entrar em um nível maior de detalhamento. Para simplificar a representação da modelagem relacional, podemos utilizar o esquema resumido da seguinte maneira: 1. Escrever o nome da entidade e, entre parênteses, todos os atributos, chave primária e chaves estrangeiras (se houver). 2. Sublinhar a chave primária. 3. Na linha abaixo à da entidade devem ser referenciadas todas as chaves estrangeiras e a entidade com as quais se relacionam. O exemplo apresentado anteriormente poderia ser representado utilizando-se a notação resumida da seguinte forma: Departamento (CodDept, Nome) Funcionario (CodFunc, Nome, CPF, CodDept) CodDept referencia Departamento

O relacionamento entre as tabelas Departamento e Funcionario também pode ser representado por meio do seguinte diagrama:

Observe que por meio da notação resumida não é possível determinar se o relacionamento é do tipo 1:1 ou 1:N (como no caso representado na figura acima).

Chave alternati va

É aquela chave que poderia, por causa de suas características, ser chave primária, mas não é. Ela é única na entidade, assim como a chave primária, e pode ser considerada uma chave secundária. Podemos considerar chave alternativa o CPF. No mundo real, é o que identifica qualquer pessoa física. Escolha da chave primária

Geralmente, a chave primária é um número criado pela aplicação – costuma-se utilizar um recurso de numeração automática do próprio banco de dados, de modo que o número não se repita. Se a chave primária é muito grande, está sujeita a erros de digitação. Um nome de pessoa pode ser considerado uma chave primária? O maior problema do nome é que duas ou mais pessoas podem apresentar o mesmo nome (homônimos) e a chave deve ser única para cada registro de dados. As pessoas podem ter os mesmos nome e sobrenome, mas o RG e CPF são diferentes, entretanto, são números muito grandes, por isso, é costume escolher outros identificadores como chaves primárias.

Integridade de dados

Impor a integridade de dados garante a qualidade destes em um banco de dados. Eles devem refletir corretamente a realidade representada pelo banco e também devem ser consistentes entre si. A integridade de dados deve ser implementada de diversas formas em um banco de dados.

•

Integridade de domínio

Zela pelos valores ideais e necessários para um atributo. Para isso, definimos algumas regras de validação por meio de expressões compostas de valores constantes. Exemplos:

•

•

Não permitir um estoque negativo.

•

Impedir uma data de nascimento superior à data atual.

•

Não permitir que o valor de um produto seja negativo.

Integridade de entidade

Tem o objetivo de validar os valores permitidos a partir de valores já inseridos na própria entidade. Após uma “autoconsulta” a entidade vai permitir ou não a gravação do novo registro. Exemplos:

•

•

Não permitir duas pessoas com o mesmo CPF.

•

Impedir a locação de uma fita que já está locada.

Integridade referencial

Zela pela consistência dos registros de uma entidade a partir de valores provenientes de outras entidades, isto é, determinado registro vai “depender” diretamente de um registro de outra tabela. Exemplos: •

Um registro em uma tabela pai pode ter um ou mais registros em uma tabela filho.

•

Um registro em uma tabela filho sempre tem um registro coincidente em uma tabela pai.

•

Para a inclusão de um registro em uma determinada tabela filho, é necessário que exista um registro pai coincidente.

•

Um registro pai só poderá ser excluído se não possuir nenhum registro filho.

REFERÊNCIAS

CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron Books, 1990. DATE, DATE, C. J . Introdução a sistemas de banco de dados. Rio Rio de J aneiro aneiro:: Campus, Campus, 1991. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005. HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004. SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard Blücher, 2005. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 3. ed. São Paulo: Makron Books, 1999.





AULA 9 OBJETIVO

Conhecer e aplicar as regras utilizadas durante o processo de conversão do modelo conceitual para o modelo lógico (relacional).

REGRAS DE DERIVAÇÃO DO MODELO CONCEITUAL PARA O LÓGICO Introdução

A construção de um modelo não é tarefa a ser executada uma única vez. Gradativamente, são acrescentados novos conceitos aos já existentes, aperfeiçoando o modelo. Na prática, observa-se que nenhuma das estratégias propostas na literatura é universalmente aceita. Normalmente, é aplicada uma construção das diversas estratégias de modelagem (HEUSER, 1999). A modelagem pode surgir da descrição de dados já existentes ou a partir do conhecimento do mundo real relatado pelas pessoas envolvidas. No caso de a modelagem estar baseada em dados já existentes, é utilizada a engenharia reversa. A engenharia reversa utiliza a estratégia botton-up (de baixo para cima), ou seja, inicia a modelagem a partir das tabelas de dados já formatados no mundo real e adapta-os, segundo as regras de normalização, até chegar ao modelo conceitual. Quando a modelagem é feita por meio de uma análise de requisitos, em que a descrição do mundo real é elaborada a partir daquilo que as pessoas conhecem a

respeito da realidade a ser moldada, podem ser adotadas duas estratégias: topdown (de cima para baixo) ou inside-up (de dentro para fora) (HEISER,1999). Top-down

Partindo de uma análise de requisitos, é possível identificar as entidades envolvidas do mundo real e criar o primeiro modelo conceitual, definindo os relacionamentos e a cardinalidade máxima. Em uma próxima etapa, colocam-se as cardinalidades mínimas e atributos e desmembram-se as entidades associativas dos relacionamentos de N:N. Em seguida, realiza-se um teste de validação dos modelos, a partir de dados fictícios, simulando a realidade. O usuário deve participar deste teste. Inside-up

Parte de uma ideia central em que são definidas as principais entidades que se relacionam no mundo real e, em seguida, são desenhadas no centro do modelo. A partir dele, desenha-se o detalhamento, ampliando os relacionamentos, assim como no modelo top-down. Na primeira etapa, desenha-se o modelo conceitual com os relacionamentos e a cardinalidade máxima, a generalização e especialização e os relacionamentos ternários. Na segunda, inserem-se os novos relacionamentos que surgem da ideia central e acrescenta-se as entidades associadas aos relacionamentos de N:N. Em seguida, coloca-se todos os atributos comuns. A terceira etapa é o teste de validação, assim como no top-down.

Modelagem r elacional

A modelagem relacional é a representação do modelo conceitual em forma de tabela, com seus atributos, contendo dados fictícios que simulam a parte do mundo real a ser modelada. Tomando como exemplo o modelo conceitual do consultório médico, temos:

Passando para o modelo lógico (relacional) teremos o seguinte diagrama:

PK – Representa a chave primária. FK – Representa a chave estrangeira.

Podemos utilizar a notação resumida (também chamada de esquema resumido) para representar a mesma situação:

Medico (CRM , Nome) Paciente ( ID_Paciente, Nome) Consulta ( CRM, IdPaciente, Data, Hora ) CRM referencia Medico Id_Paciente referencia Paciente

As tabelas a seguir estão representadas com exemplos de dados. É possível notar que elas foram preenchidas com suas chaves primárias e as chaves estrangeiras correspondentes da tabela relacionada.

REFERÊNCIAS

CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron Books, 1990. DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus, 1991. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005. HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004.






AUL A 10

OBJETIVO Apresentar como efetuar a derivação do modelo conceitual para o modelo lógico para os relacionamentos binários, ternários e autorrelacionamentos.

DERIVAÇÃO DO MODELO CONCEITUAL PARA O LÓGICO PARA OS DIVERSOS GRAUS DE RELACIONAMENTOS Introdução Antes de apresentar como deve ser feita a derivação dos modelos conceituais para os lógicos (relacionais), vamos revisar alguns conceitos sobre as chaves utilizadas em bancos de dados relacionais.

•

Chave Primária (PK – Prim ary Key)

Atributo por meio do qual é possível identificar determinado registro. O conjunto de valores que constituem a chave primária deve ser único dentro de uma tabela.

•

Chave estrangeira (FK – Foreign Key)

Utilizada quando queremos que o valor de um atributo seja validado a partir do valor de atributo de outra tabela. Criamos assim uma relação de dependência (um relacionamento) entre as tabelas.

•

Chave únic a (unique)

Utilizada quando determinado campo não deve ser repetido e não é chave primária. Aumenta a consistência do banco de dados.

Há ainda outro tipo de restrição muito utilizado em bancos de dados relacionais:

NOT NULL (não nulo), utilizado quando todos os valores relacionados a determinado atributo são obrigatórios, ou seja, não nulos ou não “vazios”. A partir da compreensão desses conceitos, podemos agora apresentar como deve ser feita a derivação entre os modelos (lógico e relacional).

Nota: Consulte a aula 5 para uma revisão dos graus de relacionamento. Utilizamos as seguintes abreviações na representação dos modelos conceituais e lógicos.

A, B e C –

Entidades e tabelas.

X, Y e Z –

Atributos identificadores nas entidades e chaves primárias e/ou estrangeiras nas tabelas.

PK –

Primary Key (chave primária).

FK –

Foreign Key (chave estrangeira).

Portanto, A, B e C podem representar qualquer conjunto de entidades presentes em um relacionamento, por exemplo, cliente, pedido, produto etc.

Nota: Abaixo das entidades relacionadas são apresentadas as respectivas tabelas que devem ser geradas a partir do processo de derivação entre os modelos.

Relacionamentos binários 1:1 As soluções são diversas para os relacionamentos 1:1, por exemplo, quando a cardinalidade máxima for 1,1 nos dois sentidos, a solução mais comum é unir as duas entidades em uma única tabela.

Relacionamentos binários 1:N Observe que nos relacionamentos 1:N a chave primária sempre ficará do lado em que a cardinalidade for N.

Relacionamentos binários N:N Quando efetuamos o mapeamento para o modelo lógico de relacionamentos N:N, devemos construir uma tabela associativa composta pelas chaves primárias das duas tabelas (A e B). Os dois atributos (X e Y) formarão a chave primária (composta) da nova tabela (AB).

Relacionamento c om atribut o id entificador A solução é semelhante à anterior, porém o atributo identificador do relacionamento (Z, no exemplo a seguir) também fará parte da chave primária na tabela associativa.

Relacionamentos ternários Os relacionamentos entre três entidades requerem a construção de uma quarta tabela que deverá conter as chaves primárias das três tabelas (A, B e C). Os três atributos (X, Y e Z) formarão a chave primária composta da nova tabela (ABC).

Autorrel aci onamentos 1: 1 Neste tipo de autorrelacionamento, a chave estrangeira ficará na mesma tabela com uma restrição do tipo unique (chave única) para garantir a cardinalidade 1:1.

Autorrel aci onamentos 1: N Neste outro tipo de autorrelacionamento, a chave estrangeira também ficará na mesma tabela, porém não terá a restrição unique (chave única).

O diagrama apresentado a seguir demonstra que um funcionário supervisor pode ter vários supervisionados, porém, cada funcionário supervisionado tem apenas um supervisor.

Autorrel aci onamentos N: N Os autorrelacionamentos com grau de cardinalidade N:N requerem uma segunda tabela na qual teremos uma chave primária composta. O modelo conceitual a seguir apresenta uma entidade DISCIPLINA e por meio do relacionamento PRE_REQUISITO procura-se demonstrar que algumas disciplinas são pré-requisito para cursar outras, por exemplo: para cursar Cálculo 2 há como pré-requisito cursar Cálculo 1.

REFERÊNCIAS CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron Books, 1990. DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus, 1991. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005. HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004. SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard Blücher, 2005. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 3. ed. São Paulo: Makron Books, 1999.





AUL A 11 OBJETIVO

Apresentar os conceitos necessários para compreender o processo de normalização de tabelas.

NORMALIZAÇÃO DE TABELAS: DEPENDÊNCIAS FUNCIONAIS Normalização

A normalização envolve um conjunto de regras aplicadas em um banco de dados com a finalidade de corrigir redundâncias, separando os dados até que seus atributos apresentem valores atômicos, isto é, indivisíveis. O conceito de normalização foi introduzido em 1970 por Edgard F. Codd e baseia-se no processo matemático formal com fundamento na teoria dos conjuntos. O processo de normalização aplica uma série de regras sobre as tabelas de um banco de dados para verificar se estas foram corretamente projetadas.

Objetivos da normalização de tabelas

Os objetivos principais da normalização de tabelas são os seguintes: •

Garantir a integridade dos dados, evitando que informações sem sentido sejam inseridas.

•

Organizar e dividir as tabelas da forma mais eficiente possível, diminuindo a redundância e permitindo a evolução do banco de dados.

Formas normais

São seis as formas normais mais utilizadas: •

Primeira Forma Normal (1FN).

•

Segunda Forma Normal (2FN).

•

Terceira Forma Normal (3FN).

•

Forma Normal de Boyce e Codd (FNBC).

•

Quarta Forma Normal (4FN).

•

Quinta Forma Normal (5FN).

Nota: Neste curso abordaremos as três primeiras formas normais, pois estas

atendem à maioria dos casos de normalização. Uma forma normal engloba todas as anteriores, isto é, para que uma tabela esteja na 2FN, ela obrigatoriamente deve estar na 1FN e assim por diante. Normalmente, após a aplicação das regras de normalização, algumas tabelas acabam sendo divididas em duas ou mais. Este processo colabora significativamente para a estabilidade do modelo de dados e reduz consideravelmente as necessidades de manutenção. Antes de passarmos à parte prática, aplicando as regras conforme a 1FN, 2FN e 3FN, será necessário apresentar alguns conceitos fundamentais diretamente relacionados às Formas Normais.

Dependência Funcional (DF)

Sempre que um atributo X identifica um atributo Y, dizemos que entre eles há uma dependência funcional .

A representação é: X Y (lê-se X determina Y ou Y é dependente de X). cidade estado

Neste caso, estado é funcionalmente dependente de cidade ou ainda cidade determina estado. CIDADE Campinas Natal Niteroi

ESTADO São Paulo Rio Grande do Norte Rio de J aneiro

Transitividade

Se um atributo X determina Y e se Y determina Z, podemos dizer que X determina Z de forma transitiva, isto é, existe uma dependência funcional transitiva de X para Z. cidade

estado

estado

país

cidade

país (cidade determina país de forma transitiva)

CIDADE ESTADO Campinas São Paulo Miami Florida

PAIS Brasil EUA

Dependência func ional ir redutível à esquerda

O lado esquerdo de uma dependência funcional é irredutível quando o determinante está em sua forma mínima, isto é, quando não é possível reduzir a quantidade de atributos determinantes sem perder a dependência funcional.

{ci dade, estado}

país

Não está na forma irredutível à esquerda, pois podemos ter somente o estado como determinante.

estado

Está na forma irredutível à esquerda.

país

CIDADE Campinas Miami

ESTADO PAIS São Paulo Brasil Florida EUA

ESTADO São Paulo Florida

PAIS Brasil EUA

Dependência Multivalorada (DMV)

A DMV é uma ampliação da Dependência Funcional (DF). Na DMV, o valor de um atributo determina um conjunto de valores de outro atributo. É representada por X Y (X multidetermina Y ou Y é multidependente de X).

DF:

{CPF} {Nome}

DMV:

{CPF}

Temos somente um nome para cada CPF

{Dependente} Temos vários dependentes para cada CPF CPF

111222333-00

DEPENDENTE Antonio Santos Beatriz Santos Claudio Santos

REFERÊNCIAS

CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron Books, 1990. DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus, 1991. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005.

HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004. SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard Blücher, 2005. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 3. ed. São Paulo: Makron Books, 1999.





AUL A 12

OBJETIVO Apresentar os principais conceitos de normalização de banco de dados envolvendo a Primeira Forma Normal (1FN).

NORMALIZAÇÃO DE BANCO DE DADOS: PRIMEIRA FORMA NORMAL Introdução Conforme você aprendeu na aula anterior, a normalização envolve um conjunto de regras aplicadas em um banco de dados com a finalidade de corrigir redundâncias, separando os dados até que seus atributos apresentem valores atômicos, isto é, indivisíveis. Nesta e nas próximas duas aulas abordaremos as seguintes formas normais:

•

Primeira Forma Normal (1FN).

•

Segunda Forma Normal (2FN).

•

Terceira Forma Normal (3FN).

Primeira Forma Normal (1FN) Uma tabela se encontra na Primeira Forma Normal (1FN) quando não possui

tabelas aninhadas , ou seja, quando uma ocorrência de uma tabela possui dentro dela um subconjunto de atributos multivalorados, isto é, com mais de um valor, caracterizando outra tabela interna.

Para que uma tabela esteja na 1FN, é necessário que cada atributo de uma ocorrência tenha apenas um valor. Observe o seguinte exemplo: Uma empresa de engenharia utiliza os formulários apresentados a seguir para controle de seus projetos:

PROJETO

PROJETO

NR_PROJ

001

NR_PROJ

002

NOME_PROJ

Alfa

NOME_PROJ

Beta

LOCAL_PROJ

São Paulo

LOCAL_PROJ

Jundiaí

ID_FUNC NOME_FUNC

CARGO

VL_HORA

ID_FUNC NOME_FUNC

CARGO

VL_HORA

101

Antonio

Analista Pleno

35,00

102

Beatriz

Analista Pleno

35,00

102

Beatriz

Analista Pleno

35,00

103

Claudio

Analista Senior 35,00

103

Claudio

Analista Senior

50,00

104

Daniela

Analista Senior 50,00

Para registrar os dados dos seus projetos, a empresa adotou planilhas eletrônicas com a seguinte estrutura: NR_PROJ NOME_PROJ LOCAL _PROJ ID_FUNC 001

Alfa

São Paulo

002

Beta

J undiaí

101 102 103 102 103 104

NOME_FUNC Antonio Alves Beatriz Bernardes Claudio Cardoso Beatriz Bernardes Claudio Cardoso Daniela Dantas

CARGO Analista Pleno Analista Pleno Analista Senior Analista Pleno Analista Senior Analista Senior

VL_HORA 35,00 35,00 50,00 35,00 50,00 50,00

No entanto, à medida que a quantidade de projetos e funcionários alocados neles cresceu, observou-se que seria necessário utilizar um sistema de banco de dados. Para garantir a integridade e controlar a redundância dos dados, aplicou-se à tabela acima a Primeira Forma Normal (1FN). A tabela para controle de projetos apresenta a seguinte tabela aninhada:

ID_FUNC 101 102 103 102 103 104

NOME_FUNC

CARGO

Antonio Alves Beatriz Bernardes Claudio Cardoso Beatriz Bernardes Claudio Cardoso Daniela Dantas

Analista Pleno Analista Pleno Analista Senior Analista Pleno Analista Senior Analista Senior

VL_HORA 35,00 35,00 50,00 35,00 50,00 50,00

Não se deve simplesmente separar a tabela acima do restante da tabela de controle de projetos, porque, neste caso, não seria mais possível determinar em quais projetos cada funcionário trabalhou. Para que isso não ocorra, é preciso incluir a coluna NR_ PROJ na tabela que será denominada PROJ ETO_FUNCIONARIO: PROJETO_FUNCIONARIO NR_PROJ ID_FUNC NOME_FUNC CARGO

VL_HORA

001 001 001 002 002 002

35,00 35,00 50,00 35,00 50,00 50,00

101 102 103 102 103 104



Consequentemente, a segunda tabela (PROJ ETO) apresentará a seguinte estrutura: PROJETO NR_PROJ NOME_PROJ LOCAL_PROJ 001 002

Alfa Beta

São Paulo J undiaí

Observe que após a aplicação da Primeira Forma Normal (1FN) não temos mais tabelas aninhadas. Outro detalhe: os usuários terão acesso às mesmas informações anteriormente disponibilizadas na tabela que não estava na Primeira Forma Normal.






AUL A 13

OBJETIVO Apresentar os principais conceitos de normalização de banco de dados envolvendo a Segunda Forma Normal.

NORMALIZAÇÃO DE BANCO DE DADOS: SEGUNDA FORMA NORMAL

2FN – Segunda Forma Normal Uma tabela está na Segunda Forma Normal (2FN) quando, além de estar na Primeira Forma Normal (1FN), não contém dependências parciais . Uma dependência funcional parcial ocorre quando uma coluna que não faz parte da chave primária depende apenas de uma parte da chave primária COMPOSTA (veja o tópico da aula 11: “Dependência funcional irredutível à esquerda”). Sendo assim, toda tabela que está na Primeira Forma Normal e que possui chave primária SIMPLES (formada por uma coluna) já está na Segunda Forma Normal. Analisando a tabela PROJ ETO_FUNCIONARIO (veja aula anterior), nota-se que as colunas (ou atributos) NOME_FUNC, CARGO e VL_HORA dependem apenas de uma parte da chave primária, ou seja, do ID_FUNC.

PROJETO_FUNCIONARIO NR_PROJ ID_FUNC NOME_FUNC CARGO 001 001 001 002 002 002

101 102 103 102 103 104


VL_HORA


35,00 35,00 50,00 35,00 50,00 50,00

Portanto, ao aplicarmos a Segunda Forma Normal (2FN), teremos:

ID_FUNC 101 102 103 104

FUNCIONARIO NOME_FUNC CARGO Antonio Alves Beatriz Bernardes Claudio Cardoso Daniela Dantas

Analista Pleno Analista Pleno Analista Senior Analista Senior

VL_HORA 35,00 35,00 50,00 50,00

A tabela PROJ ETO_FUNCIONARIO apresentará a seguinte estrutura após a aplicação da Segunda Forma Normal (2FN):

PROJETO_FUNCIONARIO NR_PROJ ID_FUNC 001 001 001 002 002 002

101 102 103 102 103 104






AUL A 14 OBJETIVO Apresentar os principais conceitos de normalização de banco de dados envolvendo a Terceira Forma Normal.

NORMALIZAÇÃO DE BANCO DE DADOS: TERCEIRA FORMA NORMAL Terceira Forma Normal (3FN) Uma tabela está na Terceira Forma Normal (3FN) quando, além de estar na 2FN (Segunda Forma Normal), não contém dependências transitivas . Uma dependência funcional transitiva ocorre quando uma coluna, além de depender da chave primária da tabela, depende diretamente de outra(s) coluna(s) da tabela. (veja o tópico da aula 11: “Dependência Funcional Transitiva”). A tabela FUNCIONARIO apresenta uma dependência funcional transitiva. Observe que o VL_HORA não depende diretamente do ID_FUNC. VL_HORA depende diretamente do CARGO.

ID_FUNC 101 102 103 104

FUNCIONARIO NOME_FUNC CARGO Antonio Alves Beatriz Bernardes Claudio Cardoso Daniela Dantas

Analista Pleno Analista Pleno Analista Senior Analista Senior

VL_HORA 35,00 35,00 50,00 50,00

Portanto, ao aplicar-se a Terceira Forma Normal (3FN), teremos uma tabela que pode ser denominada CARGO_SALARIO com a seguinte estrutura:

CARGO_SALARIO CARGO VL_HORA Analista Pleno Analista Senior

35,00 50,00

A tabela FUNCIONARIO, após a aplicação da Terceira Forma Normal, apresentará a estrutura a seguir:

ID_FUNC 101 102 103 104

FUNCIONARIO NOME_FUNC Antonio Alves Beatriz Bernardes Claudio Cardoso Daniela Dantas

CARGO Analista Pleno Analista Pleno Analista Senior Analista Senior

Observe, a seguir, quais foram as tabelas geradas após a aplicação das três primeiras Formas Normais (FN1, FN2 e FN3) e compare com a tabela controle de projeto anteriormente apresentada (veja aula 12).

PROJETO NR_PROJ NOME_PROJ LOCAL_PROJ 001 002

ID_FUNC 101 102 103 104

Alfa Beta

São Paulo J undiaí

FUNCIONARIO NOME_FUNC Antonio Alves Beatriz Bernardes Claudio Cardoso Daniela Dantas

CARGO Analista Pleno Analista Pleno Analista Senior Analista Senior

PROJETO_FUNCIONARIO NR_PROJ ID_FUNC 001 001 001 002 002 002

101 102 103 102 103 104

CARGO_SALARIO CARGO VL_HORA Analista Pleno Analista Senior

35,00 50,00

Importante O exemplo apresentado tem objetivo exclusivamente didático para esclarecimento dos conceitos envolvidos na aplicação de cada uma das três primeiras Formas Normais. Outros detalhes deveriam ser levados em consideração para o desenvolvimento de um sistema completo, por exemplo, armazenar os valores históricos dos salários, quantidade de horas de cada funcionário nos respectivos projetos etc.

REFERÊNCIAS CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron Books, 1990. DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus, 1991. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005. HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004.

MULLER, Robert J . Projeto de Banco de Dados: usando UML para modelagem de dados. São Paulo: Berkeley Brasil, 2002. SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard Blücher, 2005. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 3. ed. São Paulo: Makron Books, 1999.





Aula 15: Álgebr a relacional – seleção e projeção OBJETIVO: Apresentar os conceitos de álgebra relacional envolvendo as operações de seleção e projeção.

Introdução Até o presente momento, aprendemos a construção de um banco de dados com suas formas de modelagem, que auxiliam a compreender o modo como os dados estão distribuídos dentro de um SGBD (Sistema de Gerenciamento de Banco de Dados). Utilizamos também suas regras de normalização com a engenharia reversa para eliminar as redundâncias e facilitar os meios de acesso aos dados. Os processos de busca dos dados estão fundamentados na álgebra relacional. Trata-se de uma linguagem formal utilizada nos SGBDs para consultar os dados solicitados por um usuário. Essa linguagem possui um conjunto de operações baseadas na teoria de conjuntos, que permite selecionar, unir, subtrair e projetar um conjunto de dados relacionados. O resultado de uma consulta é visto como um conjunto de tuplas (grupos de dados pertencentes a uma linha de uma tabela). As operações primitivas que utilizam a álgebra relacional são:

•

Seleção

•

Projeção

•

Produto cartesiano

•

União

•

Diferença As operações derivadas que utilizam a álgebra relacional são:

•

Intersecção

•

J unção (normal e natural)

•

Divisão

Seleção σ Indicada pela letra grega σ (sigma), esta operação produz uma nova relação apenas com as tuplas (linhas) da primeira relação (tabela), que satisfazem a uma determinada condição (também chamada de predicado). A sintaxe básica é a seguinte:

σ

predicado (relação)

Observe a tabela (relação) a seguir:

FUNCIONARIO ID_FUNC

NOME_FUNC

CARGO

101

Antonio Alves

Analista Pleno

102

Beatriz Bernardes

Analista Pleno

103

Claudio Cardoso

Analista Senior

104

Daniela Dantas

Analista Senior

Para efetuar a seleção do funcionário cujo ID_FUNC = 102, devemos utilizar a seguinte expressão: σ

ID_FUNC=102 (FUNCIONARIO) A execução desta operação produzirá uma tabela ou relação que atende à

condição ID_FUNC = 102. Observe:

ID_FUNC 102

NOME_FUNC Beatriz Bernardes

CARGO Analista Pleno

Projeção π Esta operação, indicada pela letra grega π (pi), produz uma nova relação ou tabela com apenas alguns atributos da primeira relação, removendo as tuplas duplicadas. A sintaxe básica é a seguinte:

π

nome da coluna, nome da coluna (relação) Tomando-se ainda como base a tabela FUNCIONARIO, para efetuar a

projeção da coluna NOME_ FUNC devemos utilizar a seguinte expressão:

π

CARGO (FUNCIONARIO) A execução desta operação produzirá a tabela ou relação a seguir:

FUNCIONARIO CARGO Analista Pleno Analista Senior Note que as tuplas (linhas) repetidas foram removidas.

Veja agora como efetuar a projeção das colunas ID_FUNC e NOME_FUNC:

π

ID_FUNC, NOME_FUNC (FUNCIONARIO)

A relação produzida pela expressão acima é a seguinte:

ID_FUNC

NOME_FUNC

101

Antonio Alves

102

Beatriz Bernardes

103

Claudio Cardoso

104

Daniela Dantas

Podemos também aplicar as operações de seleção e projeção em determinada relação ou tabela. No exemplo a seguir foi aplicada uma operação de seleção para obter-se a tupla (linha) cujo ID_FUNC = 102 e depois uma operação de projeção sobre a coluna NOME_FUNC.

π

NOME_FUNC (σ ID_FUNC=102 (FUNCIONARIO)) O resultado da expressão acima é o seguinte:

NOME_FUNC Beatriz Bernardes Na próxima aula abordaremos outra operação da álgebra relacional: o

produto cartesiano . REFERÊNCIAS CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron Books, 1990. DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus, 1991. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005.

HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004. MULLER, Rober Robertt J . Projeto de Banco de Dados: usando UML para modelagem de dados. São Paulo: Berkeley Brasil, 2002. SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard Blücher, 2005. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 3. ed. São Paulo: Makron Books, 1999.





Aula 16: Álgebr a relacional – produto cartesiano OBJETIVO: Apresentar os conceitos de álgebra relacional envolvendo as operações de produto cartesiano.

Produto cartesiano X O produto cartesiano (representado por X) de duas tabelas ou relações é uma terceira relação contendo todas as combinações possíveis entre as tuplas (linhas) da primeira e as tuplas da segunda tabela. A sintaxe básica é a seguinte: (relação 1) X (relação2) A figura a seguir demonstra como é realizada a operação entre duas tabelas genéricas TABELA_1 e TABELA_2:

Concluímos, portanto, que o produto cartesiano de uma tabela formada por três colunas e quatro linhas com outra formada por duas colunas e três linhas será uma terceira tabela com a seguinte estrutura: 3 colunas + 2 colunas =5 colunas 4 linhas x 3 linhas =12 linhas

Analisaremos agora um exemplo prático. Imagine que em determinado campeonato de futebol entre os principais times dos estados de São Paulo e do Rio de J aneiro foram formados dois grupos com quatro times em cada grupo. Os times de um estado deverão enfrentar os times do outro. Aplicando-se a operação da álgebra relacional denominada produto cartesiano teremos:

O produto cartesiano, embora na prática não tenha muitas aplicações diretas, é uma forma primitiva utilizada para juntar informações de duas tabelas para posterior processamento. A operação de junção, conforme veremos nas aulas seguintes, é uma derivação do produto cartesiano. Aplica-se, neste caso, uma operação de seleção para obter apenas as combinações que realmente interessam.

REFERÊNCIAS

CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron Books, 1990.

DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus, 1991. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005. HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004. MULLER, Robert J . Projeto de Banco de Dados: usando UML para modelagem de dados. São Paulo: Berkeley Brasil, 2002. SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard Blücher, 2005. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 3. ed. São Paulo: Makron Books, 1999.





Aula 17: Álgebr a relacional – união, difer ença e intersecção OBJETIVO: Apresentar os conceitos de álgebra relacional envolvendo as operações

de união, diferença e intersecção. União U

O resultado da união entre duas relações ou tabelas gera uma terceira relação com todas as tuplas (linhas) comuns e não comuns. As tuplas comuns às duas relações aparecerão apenas uma vez no resultado. As duas relações devem ter o mesmo número de atributos (colunas) e mesmos domínios para as colunas correspondentes. A sintaxe básica é a seguinte: (relação 1) U (relação 2) A figura a seguir demonstra como é realizada a operação de união entre duas tabelas genéricas TABELA_1 e TABELA_2:

Diferença -

A diferença entre duas relações produz uma nova relação com todas as tuplas da primeira relação que não aparecem na segunda relação. As duas relações devem ter o mesmo número de atributos (colunas) e mesmos domínios para as colunas correspondentes. A sintaxe básica é a seguinte:

(relação 1) - (relação 2) A figura a seguir demonstra como é realizada a operação de diferença entre duas tabelas genéricas TABELA_1 e TABELA_2:

É importante enfatizar que, se invertermos as tabelas, o resultado não será o mesmo; a operação não é comutativa. Exemplificando, poderíamos dizer que: (relação 1) - (relação 2) é diferente de (relação 2) - (relação 1) Observe a seguir o resultado de (TABELA_2) – (TABELA_1):

Intersecção

∩

A intersecção entre duas relações produz uma nova relação entre a primeira entidade e a segunda, em que somente aparecerão as tuplas em comum escritas uma única vez. Neste caso, as duas relações também devem ter o mesmo número de atributos e mesmos domínios para as colunas correspondentes. A sintaxe básica é a seguinte: (relação 1) ∩ (relação 2)

A figura a seguir demonstra como é realizada a operação de intersecção entre duas tabelas genéricas TABELA_1 e TABELA_2:

REFERÊNCIAS






Aula 18: Álgebr a relacional – junção e divisão OBJETIVO: Apresentar os conceitos de álgebra relacional envolvendo as operações de junção normal e junção natural e divisão.

Junção A operação denominada junção combina as operações de seleção e produto cartesiano produzindo uma combinação entre as tuplas de uma tabela com as tuplas correspondentes de outra tabela que obedecem a uma condição. A sintaxe básica é a seguinte:

σ

relaçãoA.chave1=relaçãoB.chave2 ( relação A X relação B )

A figura a seguir demonstra como é realizada a operação de junç ão entre duas tabelas DEPARTAMENTO e FUNCIONARIO:

DEPARTAMENTO CODDEPT

NOMEDEPT

FUNCIONARIO IDFUNC

NOMEFUNC

CODDEPT

D1

Engenharia

101

Antonio Alves

D2

D2

Comercial

102

Beatriz Bernardes

D1

103

Claudio Cardoso

D2

104

Daniela Dantas

D1

σ DEPARTAMENTO.CODDEPT = FUNCIONARIO.CODDEPT

CODDEPT

NOMEDEPT

(DEPARTAMENTO X FUNCIONARIO)

IDFUNC

NOMEFUNC

CODDEPT

D1

Engenharia

102

Beatriz Bernardes

D1

D1

Engenharia

104

Daniela Dantas

D1

D2

Comercial

101

Antonio Alves

D2

D2

Comercial

103

Claudio Cardoso

D2

A operação de junção foi criada justamente porque esse tipo de combinação de tabelas é de uso muito comum, facilitando, assim, a escrita de expressões. A

tabela resultante de uma junção tem todas as colunas da primeira tabela e todas da segunda tabela. Isso faz os valores dos campos utilizados como critério para a correspondência entre as linhas aparecerem duplicados, já que um vem da primeira tabela e outro da segunda.

Junç ão natural |X| Existe uma variação da junção, chamada junção natural, que fornece o mesmo resultado, mas sem essa repetição de valores: uma das colunas correspondentes aos atributos de relacionamento é descartada. A sintaxe básica é a seguinte: ( relação A |X| relação B )

A figura a seguir demonstra como é realizada a operação de junç ão natural entre as duas tabelas anteriores (DEPARTAMENTO e FUNCIONARIO):

(DEPARTAMENTO |x| FUNCIONARIO)

CODDEPT

NOMEDEPT

IDFUNC

NOMEFUNC

D1

Engenharia

102

Beatriz Bernardes

D1

Engenharia

104

Daniela Dantas

D2

Comercial

101

Antonio Alves

D2

Comercial

103

Claudio Cardoso

NOTA: A simbologia utilizada para junção normal e junção natural pode apresentar variações conforme a bibliografia consultada.

Divisão Produz uma nova tabela ou relação contendo todas as tuplas da primeira tabela (dividendo) que aparecem na segunda (mediador) com todas as tuplas da terceira tabela (divisor).

No exemplo apresentado a seguir, observa-se que a TABELA_S contém todas as tuplas da TABELA_1 (dividendo) que aparecem na TABELA_R (mediador) com todas as tuplas da TABELA_2 (divisor):

O próximo exemplo apresenta o mesmo dividendo (TABELA_1) e o mesmo mediador (TABELA_R), mas agora há outro divisor (TABELA_2). Note o resultado:

As últimas quatro aulas (15, 16, 17 e 18) apresentaram as operações da álgebra relacional. Conforme mencionado (na aula 15), trata-se de uma linguagem formal utilizada nos Sistemas de Gerenciamento de Banco de Dados para consultar os dados solicitados por um usuário. A linguagem possui um conjunto de operações baseadas na teoria de conjuntos que permite selecionar, unir, subtrair e projetar um conjunto de dados relacionados.

Para recordar: As operações primitivas que utilizam a álgebra relacional são:

•

Seleção

•

Projeção

•

Produto cartesiano

•

União

•

Diferença As operações derivadas que utilizam a álgebra relacional são:

•

Intersecção

•

J unção (normal e natural)

•

Divisão Mas não foi apresentado ainda como aplicar estas operações utilizando-se

um Sistema de Gerenciamento de Banco de Dados. Esta importante etapa será abordada nas duas últimas aulas.






Aula 19: SQL – Seleç ão, projeção, pr oduto cartesiano e junção OBJETIVO: Apresentar as operações de seleção, projeção e junção com a linguagem principal utilizada pelos bancos de dados relacionais.

SQL – Structured Query Language SQL é atualmente a principal linguagem utilizada para realizar consultas e manipulações de dados em Sistemas de Gerenciamento de Bancos de Dados Relacionais. A primeira versão da linguagem foi apresentada pela IBM em 1974 com o nome Structured English Query Language (Sequel) e disponibilizada para um protótipo de banco de dados relacional denominado SEQUEL-XRM. Em 1977, a IBM lançou um novo protótipo denominado SYSTEM/R e, ao final deste, havia desenvolvido uma linguagem que permitia acesso fácil a múltiplas tabelas, uma linguagem de quarta geração (4GL), que passou a ser denominada de SQL (Structured Query Language). Alguns anos depois, em 1979, um grupo de desenvolvedores que havia participado do projeto SYSTEM/R fundou uma empresa – a Relational Software Inc. – responsável pelo lançamento do primeiro Sistema de Gerenciamento de Banco de Dados Relacional comercialmente viável. Esta empresa mais tarde teve o seu nome alterado para Oracle. A linguagem SQL é composta basicamente por quatro subconjuntos:

•

DDL – Data Definition Language

•

DML – Data Manipulation Language

•

DQL – Data Query Language

•

DCL – Data Control Language Durante o seu curso você terá outras disciplinas que abordarão com detalhes

cada um dos comandos utilizados pelos quatro subconjuntos da SQL.

No entanto, você terá agora a oportunidade de conhecer alguns comandos relacionados ao que foi apresentado nas aulas anteriores quando foram listadas as operações da álgebra relacional.

Seleção Conforme observado na aula 15, esta operação, indicada pela letra grega σ (sigma), produz uma nova relação ou tabela apenas com as tuplas (linhas) da primeira relação que satisfazem a uma determinada condição (também chamada de predicado). Tomando-se como exemplo a seguinte tabela, para efetuar a seleção do funcionário cujo ID_FUNC = 102, devemos utilizar a expressão:

σ

ID_FUNC=102 (FUNCIONARIO)

FUNCIONARIO ID_FUNC

NOME_FUNC

CARGO

101

Antonio Alves

Analista Pleno

102

Beatriz Bernardes

Analista Pleno

103

Claudio Cardoso

Analista Senior

104

Daniela Dantas

Analista Senior

A expressão acima pode ser escrita na linguagem SQL da seguinte forma: SELECT * FROM FUNCIONARIO WHERE ID_FUNC = 102;

Observa-se, portanto, que nesta linguagem utilizamos a palavra reservada

SELECT no lugar da letra grega σ (sigma). O símbolo * é utilizado quando queremos que sejam apresentados os dados de todas as colunas da tabela. A preposição FROM é utilizada antes de informarmos o nome da tabela consultada: FUNCIONARIO.

Na sequência, temos a condição, isto é, queremos que sejam apresentados os dados do funcionário cujo ID_FUNC é igual a 102. Expressamos isso com o seguinte predicado: WHERE ID_FUC = 102. A execução do comando acima produzirá o seguinte resultado:

ID_FUNC 102

NOME_FUNC

CARGO

Beatriz Bernardes

Analista Pleno

Projeção Muitas vezes não desejamos que sejam apresentados todos os dados que satisfazem a determinada condição. No exemplo considerado, uma hipótese seria apresentar apenas o NOME do funcionário cujo ID_FUNC é igual a 102. Neste caso, devemos projetar a coluna. Na SQL informamos os nomes das colunas que queremos projetar logo após o comando SELECT. Observe: SELECT NOME_FUNC FROM FUNCIONARIO WHERE ID_FUNC = 102;

A execução do comando acima produzirá o seguinte resultado:

NOME_FUNC Beatriz Bernardes Para projetar mais de uma coluna, separamos seus nomes utilizando vírgulas: SELECT NOME_FUNC, CARGO FROM FUNCIONARIO WHERE ID_FUNC = 102;


NOME_FUNC Beatriz Bernardes

CARGO Analista Pleno

Mas qual comando deve ser utilizado para projetar TODOS os nomes dos funcionários? Neste caso, basta omitir a condição expressa no final. Observe: SELECT NOME_FUNC FROM FUNCIONARIO;


NOME_FUNC Antonio Alves Beatriz Bernardes Claudio Cardoso Daniela Dantas

Produto cartesiano O produto cartesiano de duas tabelas ou relações é uma terceira tabela contendo todas as combinações possíveis entre as tuplas ou linhas da primeira e as tuplas da segunda tabela. Observe novamente o exemplo apresentado na aula 16, o produto cartesiano das tabelas GRUPO_SP e GRUPO_RJ :

A representação, conforme a álgebra relacional, do produto cartesiano acima é a seguinte:

(GRUPO_SP) X (GRUPO_RJ) Quando trabalhamos com a SQL, o produto cartesiano de duas tabelas é obtido por meio da operação denominada CROSS JOIN. Observe: SELECT TIME_SP, TIME_RJ FROM GRUPO_SP CROSS JOIN GRUPO_RJ;

A operação de junção, conforme veremos a seguir, é uma derivação do produto cartesiano.

Junção (normal) A operação de junção utiliza as operações de seleção e produto cartesiano para produzir uma combinação entre as tuplas (linhas) de uma tabela com as tuplas correspondentes de outra tabela que obedecem a uma condição.

Observe novamente o exemplo apresentado na aula 18: DEPARTAMENTO CODDEPT

NOMEDEPT

FUNCIONARIO IDFUNC

NOMEFUNC

CODDEPT

D1

Engenharia

101

Antonio Alves

D2

D2

Comercial

102

Beatriz Bernardes

D1

103

Claudio Cardoso

D2

104

Daniela Dantas

D1

A junç ão entre as tabelas DEPARTAMENTO e FUNCIONARIO deve ser representada, conforme notação da álgebra relacional, da seguinte forma:

σ

DEPARTAMENTO.CODDEPT = FUNCIONARIO.CODDEPT (DEPARTAMENTO

X FUNCIONARIO)

O resultado produzido será o seguinte: CODDEPT

NOMEDEPT

IDFUNC

NOMEFUNC

CODDEPT

D1

Engenharia

102

Beatriz Bernardes

D1

D1

Engenharia

104

Daniela Dantas

D1

D2

Comercial

101

Antonio Alves

D2

D2

Comercial

103

Claudio Cardoso

D2

A expressão acima pode ser escrita na linguagem SQL da seguinte forma: SELECT * FROM DEPARTAMENTO, FUNCIONARIO WHERE DEPARTAMENTO.CODDEPT = FUNCIONARIO.CODDEPT;

Junção (natural) A junção natural fornece o mesmo resultado da junção normal, mas sem a repetição de valores das colunas comuns às duas tabelas. A junção natural entre as tabelas DEPARTAMENTO e FUNCIONARIO é representada, conforme notação da álgebra relacional, da seguinte forma:

(DEPARTAMENTO |x| FUNCIONARIO)

Quando utilizamos a SQL, a junção natural de duas tabelas é obtida por meio da operação denominada NATURAL INNER JOIN . Observe: SELECT * FROM DEPARTAMENTO NATURAL INNER JOIN FUNCIONARIO;

A figura a seguir demonstra o resultado da operação de junç ão nat ural entre as duas tabelas anteriores (DEPARTAMENTO e FUNCIONARIO):

CODDEPT

NOMEDEPT

IDFUNC

NOMEFUNC

D1

Engenharia

102

Beatriz Bernardes

D1

Engenharia

104

Daniela Dantas

D2

Comercial

101

Antonio Alves

D2

Comercial

103

Claudio Cardoso

Observamos nesta aula como utilizar a SQL (Structured Query Language) para realizar as seguintes operações da álgebra relacional: seleção, projeção, produto cartesiano e junção (normal e natural). Na última aula desta disciplina abordaremos as outras operações da álgebra relacional: união, diferença e intersecção.

REFERÊNCIAS CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para projeto lógico. São Paulo: Makron Books, 1990. DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus, 1991. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005. HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004.






Aula 20: SQL – União, diferença e inter secção OBJETIVO: Apresentar as operações de união, diferença e intersecção com a linguagem principal utilizada pelos bancos de dados relacionais.

União (Union ) A união entre duas relações ou tabelas gera uma terceira tabela com todas as tuplas ou linhas comuns e não comuns. As tuplas comuns às duas relações aparecerão apenas uma vez no resultado. As duas tabelas devem ter o mesmo número de atributos ou colunas e mesmos domínios para as colunas correspondentes. Na álgebra relacional, para efetuar a união das tabelas CLIENTE_1 e CLIENTE_2, utilizamos a expressão: (CLIENTE_1) U (CLIENTE_2)

Na SQL devemos utilizar o operador denominado UNION da seguinte forma: SELECT CODIGO, NOME FROM CLIENTE_1 UNION SELECT CODIGO, NOME FROM CLIENTE_2;


Diferença (Minus) A diferença entre duas tabelas produz uma nova com todas as linhas da primeira tabela que não aparecem na segunda. As duas tabelas devem ter o mesmo número de colunas e mesmos domínios para as colunas correspondentes. Na álgebra relacional, para efetuar a diferença entre as tabelas CLIENTE_1 e CLIENTE_2, utilizamos a expressão: (CLIENTE_1) - (CLIENTE_2) Na SQL devemos utilizar o operador denominado MINUS da seguinte forma: SELECT CODIGO, NOME FROM CLIENTE_1 MINUS SELECT CODIGO, NOME FROM CLIENTE_2;


NOTA: O Oracle, a partir da versão 10g, utiliza o operador MINUS. Outros Sistemas de Gerenciamento de Banco de Dados, como o Microsoft SQL Server e o IBM DB2 utilizam em seu lugar o operador EXCEPT.

Devemos lembrar que a operação de diferença não é comutativa: (CLIENTE_1) - (CLIENTE_2) é diferente de (CLIENTE_2) - (CLIENTE_ 1) Observe a seguir o resultado de: SELECT CODIGO, NOME FROM CLIENTE_2 MINUS SELECT CODIGO, NOME FROM CLIENTE_1;

Intersecção (Intersect) A intersecção entre duas tabelas produz uma nova tabela na qual somente aparecerão as linhas em comum entre a primeira e a segunda tabela escritas uma única vez. Neste caso, as duas relações também devem ter o mesmo número de atributos e mesmos domínios para as colunas correspondentes. Na álgebra relacional, para efetuar a intersecção entre as tabelas CLIENTE_1 e CLIENTE_2, utilizamos a expressão: (CLIENTE_1) ∩ (CLIENTE_2) Na SQL devemos utilizar o operador denominado INTERSECT da seguinte forma: SELECT CODIGO, NOME FROM CLIENTE_1 INTERSECT SELECT CODIGO, NOME FROM CLIENTE_2;

Modelagem de Dados.pdf

Recommend Documents