Apotila BD

Banco de Dados
Apostila do Professor
1/2 Bim. Semestre 3 MBD
MODELAGEM DE BANCO DE DADOS

Autora: Sandra G. Puga
3 MBD 1e2T 1
Prezado aluno, Este material compreende apenas o contedo da disciplina. Assim, no deve ser a nica fonte de consultas em seus estudos. O contedo deve ser complementado com outras obras, indicadas por seu professor ou encontradas em suas pesquisas.
Revises:
2 Edio 3 Impresso 1 Semestre de 2007 Copyright Faculdade IBTA
IBTA 2563
BD Modelagem de Banco de Dados Semestre III
ndice
1. Projetos de Bancos de Dados ................................................................................................. 1 1.1. Levantamento de Dados ou Levantamento de Requisitos ................................................. 2 1.1.1. Anlise de Requisitos .............................................................................................. 3 1.2. Modelo Conceitual .............................................................................................................. 3 1.2.1. Objetivos do Modelo Conceitual .............................................................................. 4 1.2.2. Caractersticas do Modelo Conceitual ..................................................................... 4 1.2.3. O Modelo Conceitual propicia .................................................................................. 5 1.2.4. Exemplo de Modelagem Conceitual ........................................................................ 6 1.3. Modelo Lgico .................................................................................................................... 7 1.3.1. Dicionrio de Dados (DD) ........................................................................................ 8 1.3.2. Matria CRUD (Create, Read, Update, Delete) ......................................................... 9 1.4. Modelo Fsico ..................................................................................................................... 9 1.4.1. O que acontece na Converso do Modelo Lgico para o Modelo Fsico .............. 10 1.4.2. Matriz CRUD .......................................................................................................... 11 2. Modelo de Banco de Dados ................................................................................................... 13 2.1. Modelo Hierrquico de Banco de Dados .......................................................................... 13 2.2. Modelo Banco de Dados em Rede ................................................................................... 14 2.3. Modelo Relacional ............................................................................................................ 16 2.3.1. Vantagens do Modelo Relacional .......................................................................... 18 2.4. Modelo Orientado a Objetos ............................................................................................. 19 3. Modelo Entidade Relacionamento (MER) ............................................................................ 21 3.1. Conceitos Bsicos ............................................................................................................ 21 3.1.1. Dados e Informaes ............................................................................................. 21 3.1.2. Entidade ................................................................................................................. 23 3.1.3. Atributos ................................................................................................................. 23 3.1.4. Chaves ................................................................................................................... 24 3.1.5. Relacionamento ..................................................................................................... 25 4. Metodologias para Modelagem de Banco de Dados Relacionais ...................................... 26 4.1. Metodologia de Peter Chen .............................................................................................. 26 4.2. Metodologia de James Martin ........................................................................................... 29 4.3. CASE*MethodTM ............................................................................................................... 32 4.4. ERWin ............................................................................................................................... 34 4.5. Quadro Resumido ............................................................................................................. 40 5. Entidade ................................................................................................................................. 41 5.1. Como identificar uma entidade ......................................................................................... 41
1
Copyright Faculdade IBTA
IBTA 2563
5.2. Representaes de Entidades ......................................................................................... 43 5.3. Cuidado: Aquilo que entidade numa circustncia, pode no ser em outra! .................. 44 5.4. Tipos de Entidades ........................................................................................................... 45 5.4.1. Entidade meramente Conceitual ........................................................................... 45 5.4.2. Entidade Forte ....................................................................................................... 45 5.4.3. Entidade fraca ........................................................................................................ 45 5.4.4. Entidade Associativa ............................................................................................. 45 5.4.5. Entidade de Dados ................................................................................................ 46 6. Atributos .................................................................................................................................. 47 6.1. Como identificar os atributos? .......................................................................................... 47 6.2. Representaes de Atributos ........................................................................................... 47 6.3. Classificao de Atributos ................................................................................................ 48 6.4. Tipos de Atributos ............................................................................................................. 48 6.4.1. Atributo Simples ..................................................................................................... 49 6.4.2. Atributo Composto ................................................................................................. 49 6.4.3. Atributo Monovalorado ........................................................................................... 50 6.4.4. Atributo Multivalorado ............................................................................................ 50 6.4.5. Atributo Derivado ou Virtual ................................................................................... 50 6.4.6. Atributo Opcional ou Nulo ...................................................................................... 50 6.4.7. Atributo Chave ....................................................................................................... 51 7. Relacionamentos .................................................................................................................... 53 7.1. Introduo ......................................................................................................................... 53 7.2. Como identificar os Relacionamentos? ............................................................................ 54 7.3. Cardinalidade ................................................................................................................... 55 8. Modelo Entidade Relacionamento Estendido ...................................................................... 58 8.1. Natureza do Relacionamento ........................................................................................... 58 8.1.1. Relacionamentos Parciais e Totais ....................................................................... 58 8.1.2. Relacionamentos Recursivos ou Auto-Relacionamento ........................................ 58 8.1.3. Relacionamentos Multiplos / Agregao ............................................................... 59 8.2. Generalizao Especializao ......................................................................................... 61 9. Normalizao .......................................................................................................................... 62 9.1. Primeira Forma Normal (1FN) .......................................................................................... 63 9.2. Segunda Forma Normal (2FN) ......................................................................................... 64 9.3. Terceira Forma Normal (3FN) .......................................................................................... 66 9.4. Forma Normal de Boyce-Codd (FNBC) ............................................................................ 67 9.5. Quarta Forma Norma (4FN) ............................................................................................ 67 9.6. Quinta Forma Normal (5FN) ............................................................................................. 69 9.7. Resumo dos Passos para Normalizao .......................................................................... 71
2
IBTA 2563
1. Projetos de Bancos de Dados
Bancos de Dados so componentes importantes dos sistemas de informao, portanto, o projeto do banco de dados torna-se uma atividade essencial na fase de desenvolvimento dos sistemas. Muitas vezes a falta de uma abordagem adequada para o projeto de um banco de dados pode incorrer em resultados indesejveis, como queda de performance ao atender a demanda de aplicaes e problemas com a manuteno do banco de dados. Geralmente a causa disso est associada a etapa de entendimento do problema e transcrio da representao para o modelo conceitual. De acordo com Korth1 Um modelo de dados pode ser definido como uma Coleo de ferramentas conceituais para descrio de dados, relacionamento entre os dados, semntica e restries de dados. O Modelo de Dados basicamente um conjunto de conceitos utilizados para descrever um Banco de Dados. No existe uma nica forma de representao deste modelo, porm qualquer forma que emite a correta compreenso das estruturas de dados compreendidas no Banco de Dados, pode ser considerada adequada. Os modelos so a base do design. Os engenheiros criam um modelo de carro para estudar os detalhes antes de coloc-lo em produo. Da mesma forma, projetistas de sistemas desenvolvem modelos para explorar idias e compreender melhor o design de um banco de dados. Os modelos ajudam a comunicar conceitos imaginados pelas pessoas. possvel us-los com os seguintes objetivos:
Comunicar Categorizar Descrever Especificar Investigar Desenvolver Analisar Imitar

O objetivo produzir um modelo que se adapte a vrios usos, possa ser compreendido por um usurio final e contenha detalhes suficientes para que um desenvolvedor crie um sistema de banco de dados. O projeto de um banco de dados pode ser decomposto em trs fases bsicas as quais denominamos modelo:
Modelo Conceitual; Modelo Lgico;
KORTH, H.F., SURDASHAN, S., SILBERSCHATZ, A., Sistema de Banco de Dados, Makron, 1999 1
IBTA 2563
Modelo Fsico.
Requisito de Dados
Modelo Conceitual
Esquema Conceitual
Modelo Lgico
Esquema Lgico
Modelo Fsico
Esquema Fsico
Figura 1.
Um projeto de banco de dados deve ser iniciado com um bom levantamento de dados, seguido da anlise de requisitos; a partir de ento o projeto conceitual do banco realizado, em seguida so derivados os modelos lgico e fsico.
1.1. Levantamento de Dados ou Levantamento de Requisitos

Nessa etapa, o projetista entrevista os possveis usurios do banco de dados para compreender e documentar seus requisitos de dados. Muitas vezes essa atividade realizada pelo analista de sistemas ou analista de negcios, no entanto, de grande importncia para a confeco do banco de dados, pois a partir do levantamento de dados, ser possvel conhecer o negcio e identificar quais dados devero ser armazenados e como sero utilizados. De acordo com Elmasri2, algumas das atividades que fazem parte dessa fase so:
Elmasri, Ramez e Navathe, S. B. Sistemas de Bancos de Dados, Addison Wesley, 2005
2
IBTA 2563
1. "Identificao das principais reas de aplicao, bem como dos grupos de usurios do banco de dados, ou seja, quem ter seu trabalho afetado por ele. So escolhidas as pessoas-chave e os comits dentro de cada grupo para apoiar os passos subseqentes de coleta e especificao dos requisitos. 2. Anlise e estudo da documentao existente relativa s aplicaes. Outros documentos manuais de procedimentos, formulrios, relatrios e organogramas - so revisados para determinar se tm qualquer influncia no levantamento de requisitos e no processo de especificao. 3. O estudo do ambiente operacional atual e o uso planejado da informao, incluindo a anlise dos tipos de transao e sua freqncia, bem com o fluxo de informao dentro do sistema. So estudadas as caractersticas geogrficas relativas aos usurios, origem das transaes, destino de relatrios e assim por diante. So especificadas as entradas e as sadas das transaes. 4. Respostas a conjuntos de consultas levantadas por usurios ou grupos de usurios potenciais do banco de dados. Essas consultas envolvem as prioridades dos usurios e a importncia que eles atribuem s diversas aplicaes. Pessoas-chave podem ser entrevistadas para ajudar a definir o valor da informao e o estabelecimento de prioridades." Algumas tcnicas utilizadas para o levantamento de dados so: anlise dos documentos utilizados pelo usurio, anlise das tarefas do usurio, entrevistas e questionrios.
1.1.1. Anlise de Requisitos Feito o levantamento de dados, inicia-se a etapa de anlise dos requisitos. Os requisitos so divididos em: requisitos de dados e requisitos de sistema (processamento). Para o projetista do banco de dados o que realmente importa so os requisitos de dados, no entanto, para o bom funcionamento do sistema e aderncia do projeto do banco de dados ao projeto do sistema, deve-se desenvolver em paralelo a anlise dos requisitos de dados e a anlise dos requisitos do sistema. A documentao dos requisitos pode ser realizada por meio de casos de uso ou DFD.
1.2. Modelo Conceitual

A construo do Modelo Conceitual iniciada a partir da especificao dos requisitos e resulta no esquema conceitual do banco de dados, onde a semntica da realidade deve estar correta. Um esquema conceitual uma descrio em alto nvel da estrutura do banco de dados, independente do Sistema de Gerenciamento de Banco de Dados (SGBD) adotado para implement-lo. utilizado para descrever os esquemas conceituais. chamado de modelo de alto nvel, pois no est ligado (relacionado) a nenhum Banco de Dados. Sua verdadeira inteno promover o entendimento dos fatos de uma realidade (mundo) para ser representado e tratado em um BD. De acordo com Cougo3 o modelo conceitual pode ser definido como um modelo no qual os
COUGO, P., Modelagem Conceitual e Projeto de Bancos de Dados, Campus, 2000 3

IBTA 2563
objetos, suas caractersticas e relacionamentos tm a representao fiel ao ambiente observado, independente de quaisquer limitaes impostas por tecnologias, tcnicas de implementao ou dispositivos fsicos. Considerando o ciclo de vida de desenvolvimento de um sistema esta etapa pode ser considerada a fase de anlise dos dados (ou requisitos) capturados na etapa anterior (levantamento de dados). So analisados os fatos (entidades ou conjunto de ocorrncias de dados) de interesse e seus relacionamentos, juntamente com seus atributos (propriedades ou caractersticas) e construda uma notao grfica (abstrata, uma representao de alto nvel) para facilitar o entendimento dos dados e suas relaes, tanto para os analistas quanto para os futuros usurios.
1.2.1. Objetivos do Modelo Conceitual
Descrio das Informaes O objetivo do modelo conceitual descrever as informaes

contidas em uma realidade, as quais estaro armazenadas em um banco de dados.
Resultado real O resultado de um Modelo Conceitual um esquema que representa a

realidade das informaes existentes, assim como as estruturas de dados que representam essas informaes.
Independncia de Manipulao e Manuteno dos Dados No construdo com

consideraes procedurais, no existindo preocupao com as operaes de manipulao/manuteno dos dados.
Independncia do SGBD No retrata aspectos ligados abordagem do banco de dados que

ser utilizado e nem com as formas de acesso ou estruturas fsicas implementadas por um SGBD.
1.2.2. Caractersticas do Modelo Conceitual
Representao da Realidade Registra as necessidades de informao de uma realidade. Melhor Conhecimento do Sistema Permite que os analistas possam interagir melhor com os
usurios validando seus objetivos e metas permitindo a construo de um sistema de informaes cada vez mais prximo da realidade do usurio.
Inicia o projeto a primeira etapa do projeto de um sistema de aplicao em banco de

dados. A fase de projeto conceitual tida como uma das mais (seno a mais) delicadas em todo esse processo, pois depende muito da habilidade do projetista do banco de dados e das qualidades do modelo de dados adotado para a elaborao do esquema conceitual. A meta nessa fase obter um esquema conceitual do banco de dados que seja to completo e expressivo quanto possvel. Esse esquema deve procurar expressar o mximo da semntica envolvida na informao. Mecanismos de representao de alto nvel so empregados, tais como representao de hierarquias de subconjunto e de generalizao, representao de restries de cardinalidade e de atributos compostos e multivalorados. O esquema conceitual deve permanecer como uma parte da documentao do processo de projeto, sendo utilizado durante a operao e manuteno do banco de dados, pois facilita o entendimento dos esquemas de dados e das aplicaes que os utilizam.
4
IBTA 2563
Para auxiliar o projetista a elaborar o projeto conceitual de um banco de dados existem as abstraes de dados, que apresentam as vantagens:
ajudam o projetista a entender, classificar e modelar a realidade, melhoram a eficincia de implementaes subseqentes, permitem melhor representar a semntica das novas aplicaes de banco de dados,
provenientes de reas no tradicionais.
1.2.3. O Modelo Conceitual propicia
Melhor compreenso pelo usurio leigo: Um modelo conceitual normalmente uma

representao grfica de fatos e relaes do mundo real. Assim sendo, a compreenso destes conceitos facilitada, se exposta graficamente. O usurio leigo, para o qual o BD ser desenvolvido, tem melhores condies de criticar o projeto feito e interagir no projeto.
Independncia de detalhes de implementao: Um modelo conceitual no vinculado a

nenhum modelo de dados de BD, ou seja, no apresenta detalhes de estruturao de dados que s precisam ser considerados no momento da criao do esquema em um SGBD. Assim, modificaes nesta etapa do projeto so menos comprometedoras do que nas etapas seguintes. Inclusive, recomendado que se critique bastante o modelo conceitual, para evitar mudanas depois.
Traduo para qualquer modelo de dados de BD: Um modelo conceitual pode ser
mapeado para qualquer modelo de BD, desde que se saibam as regras para realizar tal tarefa. Isto facilita o upgrade do BD (por exemplo, migrao de um SGBD relacional para um SGBD orientado a objetos), uma vez que no preciso repensar do zero a nova organizao lgica que os dados tero no novo modelo de dados.
Ferramenta indispensvel para o processo de engenharia reversa de BD: O upgrade (ou

migrao) de um esquema implementado em um certo modelo de dados de BD para outro exige a realizao de um processo chamado engenharia reversa. O objetivo deste processo justamente obter o modelo conceitual a partir de um modelo lgico (projeto de BD ao contrrio), para que possa ento ocorrer o upgrade, como comentado na vantagem anterior.
Maior estabilidade frente a mudanas a nvel de implementao: O modelo conceitual, por

ser um modelo de alto nvel (semntico), tem menor probabilidade de ser afetado quando ocorrem mudanas a nvel de implementao, realizadas no SGBD, como por exemplo, definir ndices para aumentar a performance, tornar o BD distribudo, utilizar estratgias de clusterizao para agilizar consultas, etc. s vezes, mesmo modificaes, por exemplo, em tabelas de um BD relacional, no inviabilizam o modelo conceitual, uma vez que as regras de mapeamento para um modelo lgico admitem algumas variaes, como por exemplo, o fato de um relacionamento 1:1 com parcialidade gerar ou no uma tabela para o relacionamento.
Mais adequado para o exerccio da criatividade: Um modelo conceitual na verdade uma

ferramenta que admite diversas alternativas de soluo para a interpretao de uma realidade, dependendo de quem est modelando. interessante que uma modelagem conceitual seja realizada por diversos analistas e comparada entre eles, para se determinar qual delas a mais clara, ou seja, captura melhor a semntica da realidade.
5
IBTA 2563
1.2.4. Exemplo de Modelagem Conceitual
Filme
nome data copyright duracao custo id: nome data id: copyright
produzido-por 1-1 producao
s1/1 Ator Paticipacao personagem cache atua 1-N
tem-atuacao 1-N
nome_arstistico nac idade sexo tipo_papel [0-3]

id: nome_artistico
tem-direcao-de 1-1 Diretor direcao dirige 0-N
produz 0-N Estudio nome dono fundacao faturamento id: nome Figura 2.
nome nacionalidade premio [1-N] festival ano nome_premio
Obs.: Notao ER da ferramenta DB Main
q Explicao do Exemplo
O modelo retrata o estudo de caso de uma produtora de filmes.
Um filme tem a atuao de vrios atores; Um filme dirigido por um Diretor; Um estdio pode produzir vrios filmes;
Perceba que em nenhum momento este modelo relata tipo de dados ou fica preso a qualquer restrio de sistema. No caso apresentado ele demonstra as relaes existentes entre cada objeto importante dentro da produtora de filmes e caracteriza cada um desses objetos com as informaes existentes na realidade da situao.
6
IBTA 2563
1.3. Modelo Lgico

O Modelo Lgico inicia-se a partir do esquema conceitual e resulta no esquema lgico. Um esquema lgico uma descrio da estrutura do banco de dados que pode ser processada por um SGBD. Nesta etapa, o desenvolvimento do Banco de Dados comea a se voltar para o ambiente de implementao, uma vez que feita a converso do modelo conceitual para um modelo de dados de um Banco de Dados. Os modelos lgicos podem ser construdos de acordo com a abordagem: relacional, em redes, hierrquico ou Orientada a Objetos. O projeto lgico depende da abordagem do modelo de dados usado pelo SGBD, mas no do SGBD especfico usado. De acordo com Cougo4 o modelo lgico aquele em que os objetos, suas caractersticas e relacionamentos tm a representao de acordo com as regras e limitantes impostos por algum tipo de tecnologia, mas essa representao independente dos dispositivos ou meios de armazenamento fsico e das estrutura de dados por ela definidos. Na abordagem relacional esta etapa se baseia no uso de regras de mapeamento de um modelo ER para o modelo de dados escolhido. O resultado uma estrutura lgica, como um conjunto de tabelas relacionadas. Considerando o ciclo de vida de desenvolvimento de sistemas est associado fase de projeto. Os modelos lgicos podem ser baseados em objetos ou baseados em registros.
Modelos lgicos baseados em objetos: Descrio dos dados nos nveis conceitual e de
vises de usurios. Exemplos: Entidade-relacionamento, orientado a objetos.
Modelos lgicos baseados em registros: Descrio dos dados nos nveis conceitual e de
vises de usurios; o banco de dados estruturado em registros de formatos fixos, de diversos tipos; cada tipo de registro tem sua coleo de atributos; h linguagens para expressar consultas e atualizaes no banco de dados. Exemplos: Relacional, Rede, Hierrquico. No modelo relacional, dados e relacionamentos entre dados so representados por tabelas, cada uma com suas colunas especficas.
COUGO, P., Modelagem Conceitual e Projeto de Bancos de Dados, Campus, 2000 7

IBTA 2563
Funcionrio Cdigo do Funcionario Dependente Cdigo do Dependente
Nome do Funcionrio Endereo do Funcionrio Telefone do Funcionrio Salrio do Funcionrio Cargo do Funcionrio Data de Admisso do Funcionrio Data de Nascimento do Funcionrio Observaes do Funcionrio
Nome do Dependente Data de Nascimento do Dependente Grau de Parentesco do Dependente Cdigo do Funcionrio (FK)
Figura 3.
1.3.1. Dicionrio de Dados (DD) Na transio do modelo lgico para o modelo fsico deve ser gerado o dicionrio de dados. O dicionrio de dados um importante documento do projeto de banco de dados que registra todos os conceitos pertinentes ao modelo de dados, ou seja, uma fonte nica de documentao e informao sobre os objetos (metadados) e seus relacionamentos; so conceituados: 1. entidade; 2. atributos; 3. domnios de valores, com os respectivos detalhes; 4. premissas e justificativas adotadas durante a modelagem, principalmente para situaes em que o modelo no esteja normalizado; 5. exemplos para reforar entidades/conceitos relevantes no modelo. Na pgina seguinte apresentado um modelo para documentao do dicionrio de dados (DD).
8
IBTA 2563
1.3.2. Matriz CRUD (Create, Read, Update, Delete) Modelo para documentao do Dicionrio de Dados sugerido por Frana 5
Entidade: XXXXXXXXXXXXXXXXXXXXXX Descrever o nome da entidade Conceito / Definio: Texto que conceitue a entidade e os dados por ela representado, circunstncias relevantes ao modelo de dados. Trata-se de descrever o conceito mais prximo da regra de negcio, sem preocupao com as caractersticas tcnicas que ser implementado o Bando de Dados. Volume esperado: 9.999.999 Tempo de Reteno: 99 anos Processo de Limpeza: texto explicando como ser o processo de limpeza dos dados, bem como os critrios para eliminar os dados.
Atributo Atributo
Tipo Integer
Tamanho
Nulidade No
Definio Texto que explica a caracterstica da entidade definida pelo seu atributo.
1.4. Modelo Fsico

Esta ltima etapa realizada a adequao do modelo lgico ao formato de representao de dados do SGBD escolhido para a implementao. O Modelo Fsico inicia-se a partir do esquema lgico e resulta no esquema fsico. Um esquema fsico uma descrio da implementao do banco de dados; ele descreve as estruturas de armazenamento e mtodos de acesso usado para efetivamente realizar o acesso aos dados. O projeto fsico direcionado para um SGBD especfico. Decises tomadas durante o projeto fsico, para melhorar o desempenho, podem afetar a estrutura do esquema lgico. O esquema fsico do banco de dados influenciado pelas fases por que passou a construo do banco de dados. De acordo com Cougo6 o modelo fsico de dados aquele em que a representao dos objetos feita sob o foco do nvel fsico de implementao das ocorrncia, ou instncias das entidades e seus relacionamentos.
5 6
Professor Mst. Edson Tarcisio Frana COUGO, P., Modelagem Conceitual e Projeto de Bancos de Dados, Campus, 2000 9
IBTA 2563
Considerando o ciclo de vida de desenvolvimento de um sistema esta etapa est associada a etapa de implementao (codificao ou desenvolvimento). Para a realizao desta etapa, deve-se conhecer a linguagem para descrio e controle 7 do Sistema Gerenciador de banco de dados para realizar a descrio do modelo lgico. O resultado a especificao do esquema da aplicao, juntamente com a implementao de restries de integridade e vises.
Funcionrio
cd_funcionario:NUMBER(10) nm_funcionario:VARCHAR2(40) nm_endereco_funcionario:VARCHAR2(40) nr_telefone_funcionario:VARCHAR2(20) vl_salario_funcionario:NUMBER(13,2) nm_cargo_funcionario:VARCHAR2(40) dt_admissao_funcionario:DATE dt_nascimento_funcionario:DATE ds_funcionario:VARCHAR2(4000)

Dependente
cd_dependente:NUMBER(3) nm_dependente:VARCHAR2(40) dt_nascimento_dependente:DATE nm_parentesco_dependente:VARCHAR2(20) cd_funcionario: NUMBER(10)
Figura 4.
Nesta etapa tambm necessrio conhecimento sobre a Linguagem de Manipulao de Dados (DML), pois por meio dela que ser possvel o acesso e manipulao dos dados organizados pelo modelo de dados apropriado e sobre gerenciamento de transaes. Uma transao uma coleo de operaes que realizam uma nica ao lgica na aplicao do banco de dados. A gerncia de transaes assegura que o banco de dados permanea em um estado consistente (correto) a despeito de falhas no sistema (ex.: quedas de energia, e crashes do sistema operacional) e falhas de transaes. A gerncia de controle de concorrncia controla as interaes atravs de transaes concorrentes, para assegurar a consistncia do banco de dados.
1.4.1. O que acontece na Converso do Modelo Lgico para o Modelo Fsico? A especificao de campos, ou seja, o modelo lgico est mais perto do usurio e o modelo fsico vai ficar bem mais prximo da mquina. Os campos so a base do banco de dados. Eles representam caractersticas dos assuntos que so importantes para a organizao. Eles armazenam os dados que so recuperados e depois apresentados como informaes informaes que so vitais para as operaes dirias, para o sucesso e para o futuro crescimento da organizao. Eles so os bem mais ignorados, subutilizados e freqentemente negligenciados da organizao! Freqentemente, pouco ou nenhum tempo gasto para se garantir a integridade estrutural e lgica /dos campos do banco de dados.
A linguagem de Definio de dados (DDL) uma notao de especificao para definio do esquema do banco de dados. O compilador da DDL gera um conjunto de tabelas armazenadas em um dicionrio de dados. A estrutura de armazenamento e mtodos de acesso usados pelo sistema de banco de dados so especificados. 10
IBTA 2563
A especificao de campos muito importante por inmeras razes, dentre elas podemos citar:
A integridade em nvel de campo estabelecida e imposta como resultado da definio de

Especificao de Campo
A definio de especificao de campo para cada campo melhora a integridade dos dados. A definio de Especificaes de Campo o impulsiona a adquirir um entendimento completo da
natureza e propsito dos dados do banco de dados.
q Elementos de Campo Ideal

Ele representa uma caracterstica do assunto da tabela; Ele contm apenas um valor; Ele no pode ser dividido em componentes menores; Ele no contm um valor calculado ou concatenado; Ele nico dentro da estrutura inteira do banco de dados; Ele mantm todas as suas caractersticas, caso aparea em mais de uma tabela.
As especificaes de campo compreendem vrios elementos que so usados para definir cada atributo de um campo. Esses elementos so divididos em trs categorias: Elementos Gerais, Elementos Fsicos e Elementos Lgicos. H uma quarta categoria separada: Informaes de Especificao. Agrupar os elementos dessa maneira torna-os mais fceis de encontrar. Isso tambm permite que voc focalize um aspecto especfico do campo para o qual voc est definindo a Especificao de Campo. Os itens encontrados dentro de cada categoria so:
Elementos Gerais: Nome de campo, tabela de origem, rtulo, compartilhado por, alias (um ou
mais), descrio.
Elementos Fsicos: Tipo de Dados, suporte de caracteres, comprimento, casas decimais,

mscara de entrada, formato de exibio.
Elementos Lgicos: Tipo de Chave, exclusividade, valor obrigatrio, suporte a nulo, regra de
edio, comparaes permitidas, operaes permitidas, valores introduzidos por valor padro, intervalo de valores.
Informaes de Especificao: Tipo de especificao, baseadas em especificao existente,

especificao de origem.
1.4.2. Matriz CRUD C Create Criao de tabelas e operaes de insero R Retrieve Recuperao de dados U Update Atualizao de dados D Delete Excluso de dados
11
IBTA 2563
utillizada como uma ferramenta de rastreabilidade para garantir a aderncia entre o modelo do banco de dados e os requisitos levantados. Pode ser desenvolvida na passagem do modelo conceitual para o lgico e na passagem do lgico para o fsico. Para montar a tabela CRUD deve-se listar todas as funcionalidades do sistema identificadas na anlise de requisitos e as entidades/tabelas do banco. As funcionalidades podem ser representadas por: 1. Processos apresentados nos DFD's para anlise estruturada 2. Eventos da lista de eventos para anlise essencial 3. Caso de uso para orientao a objeto A seguir ser apresentado um modelo de matriz CRUD proposto por Frana:
Evento 1 XXXXXXXX
Evento 2 XXXXXXXX
Evento 3 XXXXXXXX
UC01 XXXXXXXX
Funcionalidade
Entidade
Entidade....... Entidade....... Entidade....... Entidade....... Entidade....... Entidade....... Entidade....... C C,R U D U R,D D
Entidade....... Entidade....... Entidade....... Entidade....... Entidade....... Entidade....... Entidade....... Entidade....... Entidade.......

12
R,U D R C U D R R,U C D
C,R,U,D
U,D
UC02 XXXXXXXX R D R
P1.1 XXXXXXXX
P1.2 XXXXXXXX
P1.2 XXXXXXXX
IBTA 2563
Legenda C R D U Create Read Delete Update
2. Modelo de Banco de Dados
2.1. Modelo Hierrquico de Banco de Dados

O modelo de banco de dados hierrquico funcionou muito bem com os sistemas de armazenamento em fita, usado pelos computadores nos anos 70 e foi muito popular nas companhias que usavam este sistema. Apesar de o modelo hierrquico oferecer acesso rpido e direto aos dados e ter sido um modelo de grande utilidade em numerosas circunstncias, era clara a necessidade de ser ter um novo modelo que resolvesse os problemas de dados redundantes e relacionamentos complexos de dados. A prpria IBM8 nos informa que a linguagem de dados da IBM DL/I-(Data Languagem/I) constitui um relevante exemplo de gerenciamento de banco de dados, cujo mtodo utilizado o modelo hierrquico. Onde esta linguagem faz parte em banco de dados de seu sistema de gerenciamento de informaes (IMS - Information Management System) e sistema de controle de informaes sobre o cliente (CICS - Custemar Information Control System). Descreve uma Hierarquia como um conjunto de registros interligados, isto , em cada um h um tipo de registro PAI, exceto a Raiz. Numa Hierarquia, o acesso aos dados utilizado atravs de segmento Raiz, quando um campo escolhido como campo-chave e os outros so baseados em ndice ou acesso aleatrio.
Nome
Sobrenome
Rua cliente
Conta
Saldo conta
Campo-chave conta
Campo-chave cliente
Figura 5. Diagrama de estrutura de rvore com campo-chave.
IBM Training Center, Fundamentos de Bancos de Dados, 1989. 13

IBTA 2563
No modelo hierrquico o os dados so armazenados em registros organizados hierarquicamente como rvores. Os registros so conjuntos de campos conectados uns aos outros por meio de um link, onde cada link deve relacionar apenas dois registros.
Ins
Coel
Vergueiro
Ana
Knor
Laguna
Vera Henfil
Correio
0933
4000
1024
3280
0020
6000
1963
4000
Figura 6. Exemplo de Modelo Hierrquico.
Na Figura 6. Exemplo de Banco de Dados Hierrquico: h dois tipos de registros, Cliente e Conta. O registro Cliente composto por trs campos: Nome, Sobrenome e Rua. O registro Conta composto por dois campos: Nmero da Conta e Saldo. Podemos ver que o cliente Ins tem a conta 0933, o cliente Ana tem as contas 1024 e 0020 e o cliente Vera tem a conta 1963. O conjunto de todos os registros de clientes e de contas organizado na forma de uma raiz, em que a raiz da rvore um n vazio (dummy). Como podemos ver, um banco de dados hierrquico uma coleo do tipo de rvores com raiz e, por isso, forma uma floresta. Podemos nos referir a cada uma dessas rvores com raiz como sendo uma rvore de banco de dados 9. O modelo hierrquico acessa os dados rapidamente por trabalhar com ponteiros, mas sua estrutura em rvore pode levar a redundncia de dados e isso, eventualmente, pode resultar em dados inconsistentes quando ocorrer uma atualizao, sem contar com o desperdcio inevitvel de espao. O acesso aos dados s pode ser feito atravs de programas desenvolvidos por especialistas. DICA: Para saber mais sobre bancos de dados hierrquicos consulte
http://www.cs.yale.edu/homes/avi/db-book/b.pdf
2.2. Modelo Banco de Dados em Rede

A primeira especificao-padro de banco de dados, chamada de relatrio CODSYL 10 DBTG 1971, foi escrita no final da dcada de 1960 pelo Database Task Group. Vrios sistemas de gerenciamento de banco de dados se baseiam nesse modelo de rede que ficou conhecido apenas como modelo CODASYL.
9 10
Silberschatz, Abraham; Korth, Hary F. e Sudashan, S., Sistema de Banco de Dados, Editora Makron Books, 1999 CODASYL: Conferncia Sobre Linguagem de Sistemas de Dados (Conference on Data Sistems Languages).
14
IBTA 2563
Uma rede , essencialmente, um conjunto ilimitado de ns (tipos de registros neste caso) e de ramais de ligao, ou bordas. Na verdade, uma hierarquia (visto no tpico anterior) apenas um tipo particular de rede. Uma rede no apresenta o conceito de n raiz e os registros podem ter diversos tipos de registros-pais, assim como diversos tipos de registros-filhos. Abaixo temos um modelo de um banco de dados em rede mostrando detalhadamente.
Ins Coel
Vergueiro
0933
4000,00
1024 Ana Knor Laguna 0020
3280,00
6000,00
Vera
Henfil
Correio
1963
4000,00
Figura 7. Exemplo de Modelo de Rede.
Na Figura 7 Exemplo de modelo de rede podemos ver que o cliente Ins possui a conta 0933, o cliente Ana possui as contas 1024 e 0020 e o cliente Vera possui a conta 1963. Funcionalmente os modelos de rede e hierquico possuem muitas semelhanas. Tal como no modelo hierrquico os registros so interligados por ponteiros e as linhas entre os registros (tambm conhecidos como ramais) representam relacionamentos um-para-muitos. Outras semelhanas com o modelo hierrquico persistem, por exemplo, ambos precisam usar de artifcios para implementar uma relao muitos-para-muitos; no modelo de rede foi criado um registro especial chamado de ligao para implementar esse relacionamento. No modelo hierrquico esse registro especial chamado de registro virtual. importante lembrar que ambos os sistemas-hierrquicos e de rede so chamados de sistemas de navegao j que, nos dois casos, os programadores precisam atravessar um conjunto de registros pr-articulados (pr-interligados). Sabe-se que esta pr-articulao representa um benefcio em termos de desempenho, embora seja restrita em termos da complexibilidade do processo do projeto e das modificaes posteriores ao projeto. O modelo Banco de Dados em rede foi criado na tentativa de resolver alguns problemas do modelo hierrquico. O modelo em rede tambm pode ser representado como uma rvore invertida. Entretanto, podem existir inmeras rvores invertidas compartilhando galhos, que so parte de uma mesma estrutura de bando de dados. Os relacionamentos num modelo em rede so estabelecidos e representados por uma estrutura de conjunto. Uma estrutura de conjunto uma construo transparente que relaciona duas tabelas ao mesmo tempo, usando uma tabela como proprietria e outra como membro. Estruturas de conjunto suportam relacionamentos um-para-muitos, o que significa que numa estrutura de conjunto, um registro numa tabela proprietria pode ser associado a vrios registros na tabela-membro, mas um nico registro da tabela-membro est relacionado a um s registro na tabela-proprietria. Um registro da tabela-membro tambm no pode existir sem que ele esteja
15
IBTA 2563
relacionado com um registro existente na tabela-proprietria. Por exemplo, uma conta-corrente deve ser associada a um cliente, apesar de poder existir um cliente sem conta-corrente 11.
Cliente
Tabela - Proprietria
Deposita
Estrutura de Conjunto
Conta/Corrente
Figura 8. Exemplo de Estrutura de Conjunto.
Tabela - Membro
Na figura 8 Exemplo de Estrutura de Conjunto um cliente pode depositar em uma ou mais de suas contas correntes. No modelo em rede os dados podem ser acessados rapidamente, o que uma das vantagens deste modelo. O usurio pode elaborar consultas mais complexas no modelo em rede do que no modelo hierrquico. Como no modelo hierrquico o usurio deve estar familiarizado com a estrutura do banco de dados para poder trabalhar atravs das estruturas de conjunto. Na figura 8, por exemplo, obrigatrio que o usurio esteja familiarizado com as estruturas de conjunto para que ele possa descobrir se uma apresentao especfica foi paga. Tambm, no fcil mudar a estrutura do banco de dados sem afetar as aplicaes do programa que interagem com ele. Os relacionamentos so definidos como estruturas de conjunto, uma estrutura de conjunto no pode ser mudada sem afetar as aplicaes do programa, pois so usadas pela aplicao para navegar pelos dados. Se uma estrutura de conjunto mudada, todas as referncias usadas nas aplicaes daquela estrutura devero ser alteradas. DICA: Para saber mais sobre bancos de dados em rede consulte: http://www.cs.yale.edu/homes/avi/db-book/a.pdf
2.3. Modelo Relacional12

Nos anos 60, Dr. E.F. Codd, um pesquisador cientista da IBM, estava procurando novas maneiras de lidar com grandes volumes de dados. Insatisfeito com os modelos e produtos de banco de dados daquele tempo, ele teve a idia de que aplicando disciplinas e estruturas matemticas na administrao de dados, ajudaria a resolver muitos dos problemas encontrados nos outros modelos de banco de dados, tais como: redundncia de dados, grande dependncia fsica na implementao e falha na integridade de dados.
11 12
Silberschatz, Abraham; Korth, Hary F. e Sudashan, S., Sistema de Banco de Dados, Editora Makron Books, 1999 O modelo de banco de dados relacional ser estudado em detalhes ao longo dos captulos seguintes.
16
IBTA 2563
Em 1970 o Dr. Codd apresentou o seu trabalho, agora patenteado, Um Modelo Relacional de Dados para Grandes Bancos de Dados Compartilhados. Neste trabalho ele primeiramente apresenta o modelo relacional de banco de dados. Este modelo se baseou em duas vertentes da matemtica teoria dos conjuntos e lgica de predicado de primeira ordem. Na verdade o modelo relacional deriva seu nome do termo relao, que uma parte da teoria dos conjuntos. Em um modelo relacional, os dados so armazenados em relaes, que so percebidas pelo usurio como sendo tabelas. Cada relao composta de tuplas ou registros e atributos ou campos. A ordem fsica em que os registros encontram-se numa tabela totalmente arbitrria. Cada registro de uma tabela identificado por um campo que contm valores nicos. Essas duas caractersticas do modelo relacional permitem que os dados existam, independente da forma como eles foram fisicamente armazenados. Ento, o usurio no precisa saber o local fsico de um registro para poder trabalhar com ele. Por este lado, o modelo relacional diferente do modelo hierrquico e do de rede, pois nestes modelos era imprescindvel que o usurio conhecesse o desenho da estrutura para que pudesse usar os seus dados.
Cliente
Conta
Emprstimo
Figura 9. Exemplo de modelo relacional.
Na figura 9 Exemplo de modelo relacional, um cliente pode ter uma ou mais contas correntes. Emprstimos podem ser depositados em sua conta corrente. Esse mesmo cliente pode fazer pagamento do emprstimo atravs de depsito em conta corrente. Uma das principais caractersticas do modelo relacional a possibilidade de relacionar vrias tabelas para evitar a redundncia no armazenamento de dados. Os relacionamentos no modelo relacional podem ser um-para-um, um-para-muitos e muitos-para-muitos. Duas tabelas (A e B) estaro conectadas quando uma delas (A, por exemplo) tiver um campo de compartilhamento que poder ser plenamente usado em outra (B) para diminuir redundncia de dados nas inseres de registros e facilitar futuras buscas e/ou pesquisas. Logo vrias tabelas podem estar compartilhando um mesmo campo de uma determinada tabela. A partir do momento em que o usurio esteja familiarizado com os relacionamentos entre as tabelas do banco de dados, ele pode acessar os dados de inmeras formas diferentes. Ele pode acessar os dados de tabelas que estejam diretamente conectadas, como de tabelas que estejam indiretamente conectadas. No exemplo a seguir, apesar da tabela Cliente estar indiretamente conectada a tabela de Emprstimo, o usurio pode gerar uma listagem de emprstimos por cliente ou por conta. O usurio pode facilmente fazer isso, porque a tabela de Emprstimos est diretamente conectada tabela de Conta.
17
IBTA 2563
Cliente
Identificao do Cliente 100 101 102 Prenome do Cliente Ins Ana Vera Sobrenome do Cliente Coel Knor Henfil Data da Contratao 21/10/02 12/01/01 15/02/99
Conta
Identificao da Conta 0933 1024 0020 1963 Identificao do Cliente 100 101 101 102 Saldo 4000,00 3280,00 6000,00 4000,00 B26 Cdigo Emprstimo A15
Tabela 1.
2.3.1. Vantagens do Modelo Relacional
Construo de Nveis Mltiplos de Integridade: A integridade dos dados neste modelo

construda em nvel de campo para assegurar a acuracidade dos dados; em nvel de tabela para assegurar que os registros no esto duplicados e para detectar se esto faltando valores na chave-primria; em nvel de relacionamentos para assegurar que o relacionamento entre duas tabelas vlido, e em nvel do negcio, propriamente dito, para assegurar que os dados esto acurados de acordo com o negcio.
Independncia Fsica e Lgica da Aplicao do Banco de Dados: Nem as mudanas

efetuadas pelo usurio no projeto lgico do banco de dados, tampouco as mudanas fsicas de implementao do banco de dados feitas pelos fabricantes de software iro prejudicar as aplicaes nele construdas.
Garantia da Consistncia e Acuracidade dos Dados: Os dados so acurados e

consistentes graas aos vrios nveis de integridade que voc pode impor ao banco de dados.
Fcil Armazenamento de Dados: Ao comando do usurio, os dados podem ser

armazenados numa tabela ou em vrias tabelas do banco de dados.
18
IBTA 2563
2.4. Modelo Orientado a Objetos13

A tcnica de modelagem orientada a objetos normalmente empregada nos casos onde os dados envolvidos na aplicao apresentam uma estrutura complexa. A principal diferena entre os modelos de dados relacional, hierrquico e em redes e os modelos de dados orientados a objetos est na maneira como os dados so tratados. A meta dos bancos de dados orientados a objetos manter a correspondncia direta entre os objetos do mundo real e os do banco de dados, isso implica que podemos identificar e manipular os objetos como um todo. Representar um objeto complexo no modelo relacional significa que o objeto tem que ser subdividido em um grande nmero de linhas ou tuplas, o que leva necessidade de realizar um considervel nmero de operaes de juno para recuperar o objeto. Nos modelos de dados tradicionais os dados so vistos como uma coleo de tipos de registros ou de relaes, cada qual tendo uma coleo de registros, linhas ou tuplas armazenadas em um banco de dados. Em um modelo de dados orientado a objetos um banco de dados considerado como uma coleo de objetos do mundo real. Os bancos de dados orientados a objetos foram propostos para dar suporte s necessidades de aplicaes mais complexas, como aquelas que exigem transaes mais longas, textos longos e armazenamento de imagens. Muitos dos conceitos das Linguagens de Programao Orientadas a Objetos (LPOO) so utilizados nos Banco de Dados Orientados a Objetos (BDOO) apesar de estes necessitarem de conceitos prprios. Por exemplo, os objetos nas LPOO so transitrios, isto , s existem durante a execuo do programa enquanto que nos BDOO os objetos so persistentes, isto , a existncia de um objeto pode ser estendida de modo que sejam armazenados permanentemente. Vejamos mais alguns dos principais conceitos envolvidos com BDOO:
Mtodos: Os objetos nos SGBDOOs so manipulados atravs de mtodos. Em geral, a

definio de um mtodo consiste de assinatura e corpo. A assinatura especifica o nome do mtodo, os nomes e classes dos argumentos e a classe do resultado, se existir. O corpo representa a implementao do mtodo e consiste de um conjunto de instrues expressas em uma dada linguagem de programao.
Tipos e Classes: Um tipo modela as caractersticas comuns de um conjunto de objetos e

corresponde noo de tipos abstratos de dados. Uma classe um conjunto de objetos que tem exatamente a mesma estrutura interna, i., os mesmos atributos e mesmos mtodos. Os modelos de dados orientados a objetos usam o conceito de classe como uma base para instanciao.
Herana: um mecanismo de reusabilidade muito poderoso. Com herana, uma classe

chamada uma subclasse pode ser definida com base na definio de outra classe chamada a superclasse. A subclasse herda os atributos, mtodos e mensagens de sua superclasse e pode ter atributos especficos, mtodos e mensagens adicionais.
Polimorfismo: Os SGBDOOs oferecem o recurso de polimorfismo de operaes, tambm

conhecido como sobrecarga de operador (overloading). Outros conceitos relacionados com o polimorfismo so os de late binding (ligao tardia) e overriding (redefinio de operao).
13
Modelagem de sistemas complexos ser visto com mais detalhes em captulo especfico ao tema 19
IBTA 2563
Valores: A maioria dos SGBDOOs representam as entidades primitivas, tais como inteiros ou
caracteres, por valores (no possuem OIDs), enquanto as entidades no primitivas so representadas como objetos.
Estrutura do objeto: O valor de cada atributo de um objeto pode ser:
atmico: integer, real, character, booleano, etc. 14 complexo: definido atravs de construtores: array, table, UDT .
Encapsulamento: A cada objeto est associado sua estrutura e seu comportamento (os
mtodos ou operaes). O comportamento armazenado no banco de dados junto com a estrutura do objeto.
Objetos e Identidade: Cada entidade do mundo real modelada como um objeto.

A cada objeto associado um estado e um comportamento: o estado representado pelos valores dos atributos do objeto; o comportamento definido pelos mtodos que agem sobre o estado do objeto pela invocao de operaes. A cada objeto armazenado no banco de dados associado um identificador nico ( OID: Object Identifier), que gerado pelo SGBDOO (sistema de gerenciamento de banco de dados orientado a objetos)
OIDs x Chaves Primrias

Nos modelos orientados a objetos no existe o conceito de chave primria como acontece no modelo relacional. Ao invs disso, existem os OIDs dos objetos que, como j dito, so criados e mantidos pelo sistema de gerenciamento de banco de dados e no so de acesso do usurio. As vantagens do uso de OIDs com relao s chaves so:
os programadores de aplicaes no precisam se preocupar com a seleo de chaves para as

vrias classes de objetos;
obtm-se melhor desempenho, pois os OIDs so implementados em baixo nvel pelo sistema; embora as chaves sejam mais significativas ao usurio, muitas vezes o usurio precisa usar
cdigos artificiais, sem significado semntico, para poder identificar as tuplas de uma relao.
14
UDT - User Defined Type. Tipo de dado definido pelo usurio. Caso necessrio possvel criar tipos de dados diferentes do tipos de dados padro do BD. Ex: litro, pneu, galo, permetro.
20
IBTA 2563
3. Modelo Entidade Relacionamento (MER)
3.1. Conceitos Bsicos

Neste captulo sero apresentados de maneira simplificada os conceitos bsicos que sero utilizados e detalhados ao longo do curso.
3.1.1. Dados e Informaes Os dados existem fisicamente e precisam de um contexto para adquirir algum significado. So estticos, isto , permanecem no mesmo estado at que sejam modificados por um processo manual ou automtico.
Mellanzone
55
03909-70
22,00
Mesozica
Isoladamente estes dados no tm nenhum sentido. O que Mellanzone? Ser o nome de uma pessoa, de um supermercado ou de uma pizza? E 55? um cdigo? Uma soma? Uma nota? Os dados tornam-se informaes quando so associados a um contexto e transmitem significados lgicos s pessoas.
Nome da Pizza Mellanzone

Tabela 2.
Ingredientes 55
Cdigo Pizza 03909-70
Preo da Pizza 22,00
Apelido da Pizza Mesozica
q Qual a diferena entre Dado e Informao?

Se lhe dissermos que a temperatura ambiente est em 28C ou que estamos viajando a 140km/hora, voc estar recebendo dados ou informaes? Mas se agora lhe dissermos que a temperatura ambiente de 82F ou que estamos viajando a 87 milhas/hora? Qual a sua resposta? Os dados 28C e 140 km/hora so rapidamente convertidos em sensaes trmicas e de velocidade (informao) porque voc compreende essas unidades de medida. Mas se voc no teve uma formao anglo-saxnica, 82F ou 87 milhas/hora no lhe fornecem a exata sensao de frio ou calor, ou de velocidade baixa ou alta. Vejamos mais um exemplo. Encontramos uma pessoa de 5 ps e 10 polegadas de altura que colocou 16 gales de combustvel no seu carro, pois iria viajar para uma cidade a 100 milhas de distncia, com 100 francos no bolso. Temos certeza de que voc no conseguiu transformar todos os dados embutidos na frase em informaes. Mas se lhe dissssemos que encontramos uma pessoa de 1,78m de altura que colocou 61 litros de combustvel no seu carro, pois iria viajar para uma cidade a 161 km de distncia com R$ 100,00 no bolso, voc certamente compreenderia melhor.
21
IBTA 2563
A informao existe quando o crebro humano recebe um conjunto de dados e os utiliza como entrada para algum tipo de processamento neural. Se no houver esse processamento neural, o dado no se transforma em informao; continua sendo dado. A informao a compreenso do dado, matria-prima para atividade cerebral. Se algum conversa em russo, grego ou chins conosco, recebemos dados, mas se no conhecermos o idioma (protocolo de comunicao) no podemos traduzir os dados em informaes. Ficamos parados sem ao. Sem dados e um mecanismo (processo) de compreenso desses dados, no existe o exerccio cerebral.
Informao versus Dado Informao Idade: 35 anos Quente Longe

Tabela 3.
Dado Data do Nascimento: 16/07/61 Medio x Mtrica de Temperatura = 38 C Medio x Mtrica de Distncia = 10.000
O Dado to importante ao ser humano que permanecemos 24 horas por dia com nossos sensores ligados ou de prontido! Para nossos propsitos de modelagem, estaremos estudando as informaes que queremos ou precisamos para transform-las em dados. Nosso objetivo obteno de um modelo de dados onde no exista informao. Declarao estranha para um observador casual, mas um modelo de dados, conforme o prprio nome sugere, deve conter dados, e no informaes. Suponha que venhamos a armazenar a informao idade de uma pessoa em vez do dado data de nascimento. Daqui a alguns anos, as pessoas cujas informaes (e no dados) esto armazenadas conosco continuaro a apresentar a mesma idade de hoje, pois, evidente, armazenado 35 anos de idade hoje, tal informao ser a mesma com o passar do tempo! Mas armazenando-se a data de nascimento, digamos, 21/12/1960, podemos saber com preciso e em qualquer ponto da rgua do tempo a informao da idade da pessoa. A concluso que armazenando informao perdemos informaes. Na vida real, verifica-se freqentemente o armazenamento de informaes, e no de dados, por motivos de limitaes tcnicas do processamento de dado em larga escala. Caso tpico o dos correntistas de bancos que fazem ao longo de suas vidas, como clientes, uma infinidade de transaes de crdito e dbito em suas contas correntes, sendo estes os dados bsicos resultantes que devem ser armazenados. Todavia, se quisermos obter o saldo atual das contas, teramos de promover as somas e subtraes de todos os movimentos, o que seria impraticvel do ponto de vista de carga de processamento e tempo de resposta. Portanto, a soluo tcnica mais vivel armazenar os saldos dos correntistas (saldo uma informao) em uma dada posio de tempo, no muito distante da atual fazendo-se os clculos aritmticos com os dados mais recentes para se obter a ltima posio de saldo. Essa situao aceitvel, uma vez que no h outra forma mais eficaz de contornar o problema, restando-nos apenas a preocupao de manter a informao armazenada consistente com os movimentos realizados, se ocorrer um lanamento retroativo data do saldo, este ltimo dever ser ajustado automaticamente. Tais limitaes tcnicas tm conduzido criao de bases de informaes, como o caso das bases
22
IBTA 2563
de dados executivas. Vemos a utilizao de bases de informaes apenas como um artifcio tcnico que no deve representar a base de dados principal de uma organizao.
3.1.2. Entidade Uma entidade15 ou classe de entidade uma representao abstrata de coisas semelhantes, concretas ou abstratas, que existem no mundo real, sobre a qual um sistema de informao captura, armazena e processa dados para cumprir seus objetivos na empresa, atendendo, assim, s necessidades de seus usurios. Para Korth16 uma entidade uma coisa ou objeto no mundo real que pode ser identificada de forma unvoca em relao a todos os outros objetos. Por exemplo, um aluno uma entidade que tem um conjunto de propriedades (dados), dentre elas o nmero do registro acadmico, que deve ser um valor nico capaz de identificar cada ocorrncia desta entidade. Cada ocorrncia17 de uma entidade um conjunto de propriedades (atributos)18 que identificam, qualificam ou quantificam esta entidade, por exemplo a entidade aluno tem como atributos nome, registro acadmico, data de nascimento, entre outros. Estas ocorrncias devem satisfazer duas regras bsicas:
Todas as coisas do mundo real que compem o conjunto - suas ocorrncias - devem ter as
mesmas caractersticas;
Todas as ocorrncias devem estar sujeitas e em conformidade com as mesmas normas.

3.1.3. Atributos Cada entidade tem propriedades particulares, chamadas atributos, estas propriedades podem identificar, qualificar ou quantificar a entidade. Em outras palavras os atributos descrevem as entidades. Por exemplo, uma entidade empregado pode ser descrita pelo seu nome, o trabalho que realiza, data de nascimento, endereo e salrio. Cada ocorrncia de uma entidade ter um valor para cada um de seus atributos. Os valores de atributos que descrevem cada entidade ocupam a maior parte dos dados armazenados na base de dados. A figura 10. ilustra duas entidades com seus atributos.
15 16
As entidades so representadas por tabelas na etapa de implementao do Banco. Silberschatz, A; Korth, H. R. e Sudarshan, S. Sistemas de Bancos de dados. So Paulo: Makroon Books, 1999 17 Uma ocorrncia o mesmo que um registro. 18 Um atributo representado em uma tabela por um campo. O campo a menor estrutura de armazenamento de dados em um banco de dados relacional 23
IBTA 2563
Nome = Joo da Silva Nome = Cooper Sugar Endereo = Rua Gois 711, So Paulo, SP - 1301100 Idade = 55
Presidente = Joo da Silva
e1
c1
Sede = Ribeiro Preto
Telefone residencial = 713-749 Figura 10. Exemplo de duas entidades (e1 e c1) com seus atributos.
A entidade EMPREGADO e1 tem quatro atributos: Nome, Endereo, Idade e Telefone residencial. Os seus valores (dados) so: Joo da Silva, Rua Gois 711, So Paulo, SP, 1301100, 55 e 713-749, respectivamente. A entidade companhia c1 tem trs atributos: Nome, Sede e Presidente. Seus valores (dados) so: Cooper Sugar, Ribeiro Preto, Joo da Silva. Ateno:
Os atributos de uma entidade permanecem constantes para todos os seus relacionamentos. Os atributos de uma entidade so independentes de todas as demais entidades
3.1.4. Chaves
Chave Primria: um campo ou um conjunto de campos que identifica unicamente cada

registro da tabela, sendo assim, um registro no pode conter, neste campo, um dado que j esteja armazenado em outro registro. Exemplo: No contexto de um sistema de controle acadmico o nmero de matricula de uma entidade aluno um atributo identificador j que identifica de forma nica um aluno dentro de uma faculdade.
Chave Estrangeira: um campo ou conjunto de campos usado para estabelecer um

relacionamento entre duas tabelas. Na tabela de origem deve ser chave primria.
Chave Secundria (Terciria, etc): So chaves que possibilitaro pesquisas ou ordenaes

alternativas, ou seja, diferentes da ordem criada a partir da chave primria ou da ordenao natural (fsica) da tabela.
Chave Composta: a chave que contm mais de um atributo (Por exemplo, um cadastro
ordenado alfabeticamente por Estado, Cidade e Nome do Cliente, necessitaria de uma chave composta que contivesse esses trs atributos).
Chave candidata: So atributos que podem vir a ser chave primria.

Exemplo: A entidade FUNCIONARIO tem os atributos: registro funcional, nome, cpf, rg, endereco, dt_nascimento. Os atributos registro funcional, cpf e rg so chaves candidatas, pois podem identificar cada ocorrncia de FUNCIONARIO. Mas para que uma chave candidata possa ser eleita a chave primria dever atender a restrio de unicidade, isto o contedo do campo dever ser nico para cada ocorrncia da entidade.
24
IBTA 2563
3.1.5. Relacionamentos Um relacionamento estabelece a conexo entre duas tabelas dentro de um banco de dados por meio das chaves primria e estrangeira ou por meio de tabelas de vnculo. No exemplo da figura 11. podemos ver que um aluno pode se matricular em mais de uma disciplina. Ao dizermos que um aluno est matriculado em muitas disciplinas estamos determinando a cardinalidade de nosso relacionamento. Como veremos mais frente, neste caso a cardinalidade e de 1:N.
a1 a2 a3 Aluno Matrcula
d1 d2 d3 Disciplina
Figura 11. Exemplo de Relacionamento.
25
IBTA 2563
4. Metodologias para modelagem de bancos de dados relacionais
Segundo o dicionrio Michaelis a Metodologia o estudo cientfico dos mtodos, que por sua vez o conjunto dos meios dispostos convenientemente para alcanar um fim e especialmente para chegar a um conhecimento cientfico ou comunic-lo aos outros. Uma metodologia para modelagem de bancos de dados relacionais um conjunto de regras que so empregadas para demonstrar como ser constitudo o banco de dados, isto , como as tabelas sero relacionadas. uma ferramenta de comunicao de alto nvel. Neste captulo sero apresentadas algumas metodologias e definies propostas por diferentes autores e que so utilizadas para modelagem de bancos de dados relacionais.
4.1. Metodologia de Peter Chen19

Na dcada de 70, Peter Chen props uma tcnica de diagramao que, associada a um conjunto de conceitos, tornou-se o que conhecemos como a abordagem entidade-relacionamento (E-R) para o processo de modelagem de dados. Em sua essncia, o modelo E-R representa coisas do mundo real (Entidades), que possuem caractersticas prprias (Atributos) e que se relacionam entre si (Relacionamentos).
Representao de uma Entidade Identificador da entidade
Exemplo: Funcionrio trabalha em Departamento. Neste exemplo temos duas entidades: Funcionrio e Departamento. Representao dessas duas entidades fica da seguinte forma:
Departamento
Funcionrio
Representao dos Atributos
Identificador do aTributo
19
Chen p., Modelo Entidade-Relacionamento. So Paulo: Makroon Books, 1999
26
IBTA 2563
Ateno: Muitas vezes, com o objetivo de manter o modelo simples e claro, os atributos s so representados no dicionrio de dados. Exemplos de atributos da Entidade DEPARTAMENTO:
Cdigo (do Departamento) Nome (do Departamento) Localizao (do Departamento)
DEPARTAMENTO
CDIGO
NOME
LOCALIZAO
Figura 12. Exemplo da entidade departamento.
Podemos usar uma representao alternativa para os atributos. No exemplo abaixo usaremos traos ao invs de elipses:
Funcionrio
Trabalha em
Departamento
NOME
TELEFONE
CDIGO
NOME
ENDEREO Figura 13. Representao alternativa para atributos.
Representao dos relacionamentos: Na notao original de Chen, so representados por losangos.
Identificao
Figura 14.
27
IBTA 2563
Exemplo: Funcionrio trabalha em DEPARTAMENTO
FUNCIONRIO
trabalha
DEPARTAMENTO
Figura 15. Relacionamento na notao de Chen
Representao da cardinalidade: O grau da cardinalidade expresso acima da linha do relacionamento e pode ser representado por 0, 1 ou N
N FUNCIONRIO trabalha
1 DEPARTAMENTO
Figura 16.
Pode-se tambm expressar o grau mnimo e mximo de relacionamento entre as entidades:
0:N FUNCIONRIO trabalha
1:1 DEPARTAMENTO
Figura 17.
Na notao expandida de Chen a cardinalidade representada da seguinte forma:
Um-para-um Um-para-muitos Muitos Um-e-apenas-um Zero-para-um Zero-ou-muitos Um-ou-muitos Figura 18. Cardinalidade segundo Chen.
28
IBTA 2563
4.2. Metodologia de James Martin20

Na dcada de 80, James Martin apresentou uma nova proposta de modelagem que visava estabelecer a fronteira entre o modelo lgico e fsico, desviando o foco do processo e centrando o foco nos eventos do sistema. Com essa nova proposta ele estabelece o particionamento por eventos, delimitando a rea de atuao do sistema, atravs da utilizao da lista de eventos e incorpora a modelagem de dados na especificao, introduzindo o modelo Entidade Relacionamento e Atributo (ERA). Representao da Entidade
Identificador da entidade
Figura 19.
Exemplo: Funcionrio trabalha em Departamento. Neste exemplo temos duas entidades: Funcionrio e Departamento. A representao dessas duas entidades fica da seguinte forma:
FUNCIONRIO
DEPARTAMENTO
Figura 20. Exemplo de Entidade.
20
Silberschatz, A; Korth, H. R. e Sudarshan, S. Sistemas de Bancos de dados. So Paulo: Makroon Books, 1999 29
IBTA 2563
ENTIDADE
Identificador dos atributos
Figura 21.
Exemplos de atributos da Entidade DEPARTAMENTO do exemplo anterior:
Cdigo (do Departamento) Nome (do Departamento) Localizao (do Departamento)
DEPARTAMENTO
cod_dept nome local
Figura 22. Exemplo de atributo representado com a entidade.
Representao dos Relacionamentos e Cardinalidade No mtodo proposto por Martin devemos indicar a cardinalidade do relacionamento. Dessa forma temos:
30
IBTA 2563
Cardinalidade - 1:1
Esta linha indica que um departamento est relacionando com apenas um registro de funcionrio
FUNCIONRIO Cdigo Nome Contratao Gerente Salrio Comisso Departamento
DEPARTAMENTO Cdigo Nome Localizao
Esta linha indica que um funcionrio est relacionado com apenas um registro de departamento Figura 23.
Cardinalidade - 1:1
Esta linha indica que um departamento est relacionando com apenas um registro de funcionrio
FUNCIONRIO Cdigo Nome Contratao Gerente Salrio Comisso
Esta linha indica que um funcionrio est relacionado com apenas um registro de departamento Figura 24.
Neste caso a leitura da relao das tabelas : Cada funcionrio est em um departamento e um departamento tem vrios funcionrios.
31
IBTA 2563
Relacionamento Opcional
Esta linha indica que um departamento est relacionando com muitos registros de funcionrio. A bola cheia indica participao opcional.
FUNCIONRIO Cdigo Nome Contratao Gerente Salrio Comisso Departamento
Esta linha indica que um funcionrio est relacionado com apenas um registro de departamento. A bola vazia indica participao obrigatria. Figura 25.
Neste caso a leitura da relao das tabelas : cada funcionrio deve estar em um departamento e um departamento pode ter vrios funcionrios.
4.3. CASE*MethodTM
A notao CASE*MethodTM, foi criada por Richard Baker, Ian Palmer, Harry Ellis na poca em que eram funcionrios da empresa britnica de consultoria CACI. O CASE*MethodTM usado por grandes companhias, como a Oracle Corporation. uma derivao da metodologia de James Martin e Peter Chen. Seu uso deve-se ao fato de estar mais focado para o desenho de banco de dados do que para a estrutura inerente dos dados da empresa.
Representao da entidade
Identificador da entidade
Figura 26.
32
IBTA 2563
ENTIDADE Identificador dos atributos
Figura 27.
Um ou mais atributos descrevem uma entidade, e os valores desses atributos descrevem as ocorrncias da entidade.
Os identificadores dos atributos (nomes) devem estar no singular e em letras minsculas. Os atributos obrigatrios ou que devem ser conhecidos so marcados com *. Os opcionais ou valores que podem ser conhecidos devem ser marcados com .
Identificadores exclusivos (Chaves primrias) devem ser marcados com #. Exemplo:
DEPARTAMENTO #* * cdigo nome localizao
Figura 28.
Representao dos Relacionamentos
Simbologia Linha tracejada Linha slida P de galinha Linha nica

Tabela 4.
Descrio Elemento opcional indicando pode ser Elemento obrigatria indicando deve ser Elemento de grau indicando um ou mais Elemento de grau indicando somente um
Representao
33
IBTA 2563
Como o relacionamento indica a relao entre duas entidades para cada direo do relacionamento, so necessrios:
um label, verbo que indica o relacionamento; uma opcionalidade, indicando que algo deve ser ou pode ser; um grau (ou cardinalidade) indicando somente um ou um ou mais.
Exemplo:
Usurio id cod_usuario (FK) cod_obra (FK) nome email endereo fone responsavel id_responsavel fone_responsavel email_responsavel Obra ID_obra cod_usuario (FK) cod_obra (FK) id (FK) tipo edicao id_editora nome_obra nome_editora id_autor nome_autor classificacao
Emprstimo Cod_usuario cod_obra data_emprestimo data_retirada
FUNCIONRIO
DEPARTAMENTO
#* *
nmero nome cargo
Trabalha em composto de
#* *
cdigo nome localizao
Figura 29.
4.4. ERWin21
O software ERWin foi criado pela Logic Works, sendo uma ferramenta para o projeto de sistemas cliente-servidor de banco de dados. A principal caracterstica do software a existncia de editores que definem os objetos lgicos e fsicos do Banco de Dados, e de suporte linguagem de definio de dados dos diversos servidores de banco de dados, SQL e no SQL. Utilizando-se 21 uma interface totalmente grfica, padro Windows, deExtraido do manual on-line do ERWin, traducao livre do autor esta ferramenta permite uma modelagem
34
IBTA 2563
completa de entidades e relacionamentos, a partir de ferramentas de desenho, tornando sua utilizao extremamente fcil. Esta ferramenta gera o modelo lgico e fsico para diversos gerenciadores de Banco de Dados, sejam eles SQL ou no SQL, distribudos ou no. O ERWin uma ferramenta de modelagem de dados com capacidade de gerar DDL para os principais RDBMS de mercado podendo incorporar triggers, stored procedures, regras de validao, domnios e templates. Uma de suas caractersticas mais avanadas a capacidade de fazer engenharia reversa atravs de scripts ou direto do dicionrio de dados do banco podendo, atravs da funo COMPLETE COMPARE, oferecer um relatrio detalhado das eventuais discrepncias entre o modelo e a base ou script podendo inclusive promover a sincronizao entre ambos. Ao acessarmos o software encontramos o menu principal:
Gerador de relatrios de modelagem
Viso de nvel de entidade (para trabalhar at a fase 2 de modelagem)
Viso completa (para trabalhar nas fases 3 e 4)
Vises funcionais (subject areas, para dividir o modelo em partes)
Figura 30. Barra de ferramentas do ERWin
Figura 31. Menu principal do ERWin
35
IBTA 2563
O software permite trabalhar com o modelo fsico, com o lgico ou ambos. Para isso basta escolher o modelo na caixa:
Indica modelo fsico/lgico
Indica modelo lgico
Indica modelo fsico
Figura 32. Opo para escolha do modelo.
A figura 33. mostra a diferena ente os dois modelos. O modelo lgico no se preocupa com os futuros campos das tabelas e, sim, com a criao do dicionrio de dados. O modelo fsico preocupa-se com os campos das tabelas, suas chaves e restries. Physical Model
MOVIE
Logical Model
MOVIE
movie_number movie_director movie_description movie_rating movie_name movie_genre movie_rental_rate
movie_number rating rental_rate genre_ movie_clip description movie title_
MOVIE_COPY
MOVIE_COPY
movie_number movie_copy_number movie_format general_condition
movie copy number movie number (FI<) General_condition movie_format
Figura 33. Exemplo do modelo lgico e do modelo fsico
O ERWin distingue as entidades usando retngulos. Esses retngulos podem ter os cantos arredondados (soft-box) ou no. Quando o retngulo no tiver os cantos arredondados dizemos que ir dar origem a uma tabela pai. Quando o retngulo tiver os cantos arredondados (soft-box) indica que ir dar origem a uma tabela filho, ou seja, ir receber uma chave estrangeira da tabela pai.
36
IBTA 2563
No importa se voc estiver usando o modelo fsico ou lgico, voc pode escolher a notao que deseja trabalhar. O ERWin trabalha com duas notaes:
IDEF1X (Integration DEFinition for Information Modeling) ou IE (Information Engeneering)

IDEF1X e IE usam smbolos diferentes para representar o relacionamento entre entidades e tabelas. A figura 34. mostra a diferena entre as duas notaes. IDEF1X
STORE store number manager address phone rents / is in
MOVIE movie_number name director description star rating genre rental_rate
IE
STORE store number manager address phone rents / is in
MOVIE movie_number name director description star rating genre rental_rate
Figura 34. Diferena entre a notao IDEF1X e IE.
A notao defaulf usada pelo ERWin IDEF1X mas pode ser alterado a qualquer momento. Basta entrar em Model, Properties, e escolher a notao. Para os modelos fsicos existe a opo de DM (Dimensional Notation) que usado para modelagem de Datawarehouse.
37
IBTA 2563
DM option displays in physical models only

Figura 35. Alterando o modelo.
O toolbox alterado conforme o modelo escolhido. Veja exemplo na figura 36.
IE Notation Logical Physical
IDEF1X Notation Logical Physical
Figura 36. Diferena entre a notao IE e a IDE1X.
Existem trs tipos de relacionamentos no ERWin:
O relacionamento identificado, representado pela linha contnua com uma bola cheia na ponta
(Notao IDEF1X) ou com um p de galinha (Notao IE)
O relacionamento no-identificado, representado pela linha tracejada com uma bola cheia na
ponta (Notao IDEF1X) ou com um p de galinha (Notao IE)
O relacionamento muitos-para-muitos, representado pela linha contnua com uma bola cheia
em cada ponta (Notao IDEF1X) ou com um p de galinha em cada ponta (Notao IE)
38
IBTA 2563
No caso do relacionamento identificado a chave primria da tabela pai faz parte da chave primria da tabela filho. No caso do relacionamento no-identificado a chave primria no faz parte da chave primria da tabela filho. A figura 37. nos ajuda a compreender melhor..
CUSTOMER
customer number credit card customer first_name credit card exp status code customer address customer phone email migrated non-key attribute
Identifying relationship
migrated key attribute
MOVIE RENTAL RECORD

customer number rental record date due date rental status payment transation number overdue charge rental rate rental date
PAYMENT
payment transation number type amount date status
non-identifying relationship
Figura 37. Exemplo de relacionamento identificado e no-identificado.
39
IBTA 2563
4.5. Quadro Resumido

CASE TM *Method
Peter Chen Entidade
James Martin
IDEF1X
IE
ENTIDADE ENTIDADE
atributo chave Atributos
Atributo
Atributos
Relacionamento
Cardinalidade
0:1
0:N
1:1
1:N
N:M
Figura 38.
40
IBTA 2563
5. Entidade
De acordo com o que vimos nos captulos anteriores. uma entidade 22 ou classe de entidade uma representao abstrata de coisas semelhantes, concretas ou abstratas, que existem no mundo real, sobre a qual um sistema de informao captura, armazena e processa dados para cumprir seus objetivos na empresa, atendendo, assim, s necessidades de seus usurios.
5.1. Como identificar uma Entidade

Com o tempo e a experincia em modelagem passamos a identificar as entidades de forma quase intuitiva, mas enquanto ainda no temos essa experincia podemos utilizar vrias tcnicas para isso, por exemplo na fase de levantamento podemos identificar as entidades atravs de substantivos. Uma outra tcnica consiste na proposta apresentada Shlaer & Mellor 23 na qual podemos detectar as entidades atravs da observao de cinco grupos de elementos:
As coisas tangveis As funes exercidas por elementos Eventos ou ocorrncias Interaes Especificaes
Segundo Cougo[2], esta separao das entidades ser tratada como grupos de classificao que sero teis apenas para identificao das entidades. Coisas tangveis Tudo aquilo que pode ser tocado, que tem existncia concreta. Exemplos: caminho, computador, moto, tear. O agrupamento desses objetos em Entidades depender do nvel de abstrao que se deseja atingir na modelagem do ambiente observado.
Por exemplo:
Entidade Produto
Tabela 5.
Objetos Caminho, computador, moto, tear
22 23
As entidades so representadas por tabelas na etapa de implementao do Banco. apud Cougo, Paulo. Modelagem Conceitual e projeto de banco de dados. Rio de Janeiro:Campus, 1997 41
IBTA 2563
Atingindo um nvel de abstrao maior podemos ter:
Entidade Veculo Equipamento

Tabela 6.
Objetos Caminho, moto computador, tear
Podemos abstrair um pouco mais e ter:
Entidade Caminho Moto Computador Tear

Tabela 7.
Objetos Todos os caminhes observados Todas as motos observadas Todos os computadores observados Todos os teares observados
Funes Papel, atribuio, classificao ou outra caracterstica que especifique a atuao de um objeto identificado no ambiente observado. Exemplos: Uma analista de suporte, um engenheiro civil, departamento de Recursos Humanos.
Entidade Especialista
Tabela 8.
Objetos Analista, Engenheiro
"Coisa" Tangvel Pessoa
Abstraindo um pouco mais temos:
Entidade Analista Engenheiro

Tabela 9.
Objetos Todas as especialidades de analista Todas as especialidades de engenheiro
"Coisa" Tangvel Pessoa Pessoa
42
IBTA 2563
Eventos ou ocorrncias Cougo24 define como objetos que so materializveis quando alguma ao ou fato acontece. Enquanto programado, durante sua execuo ou aps encerrado, esse elemento caracteriza-se como um evento ou ocorrncia ao qual podemos fazer alguma referncia. Exemplos: Uma partida de futebol, um vo de avio, uma viagem de carro. Interaes Resultantes da associao entre objetos em funo de um processo sendo executado. Tambm podem ser modelados como entidades associativas (relacionamentos). Exemplos: A compra de um imvel, a venda de um produto a um cliente. Especificaes Entidades que renem as caractersticas de objetos pertencentes a outros objetos. Podem ser identificados j na modelagem conceitual, ou aparecerem somente no modelo lgico, em funo da aplicao de tcnicas de normalizao. Exemplo: Automvel; Modelo do automvel Automvel uma coisa tangvel que poderamos detalhar com os atributos: cor, modelo, ano de fabricao entre outros. J a entidade Modelo do automvel uma entidade que especfica (detalha) dados sobre o modelo tais como: banco de couro, direo hidramtica, cambio hidrulico, farol de milha, entre outros.
5.2. Representaes de Entidade

O smbolo utilizado para representao de uma entidade depende da metodologia escolhida para a modelagem, conforme vimos nos captulos anteriores. Neste material utilizaremos a metodologia proposta por Peter Chen e em alguns exemplos ilustraremos como a representao utilizada pelo Erwin 25.
Peter Chen
Erwin IDENTIFICADOR DA ENTIDADE
IDENTIFICADOR DA ENTIDADE
Figura 39.
24 25
Cougo, Paulo. Modelagem Conceitual e projeto de banco de dados. Rio de Janeiro:Campus, 1997 Ferramenta de Modelagem relacional comercializada pela empresa Computer Associates. 43
IBTA 2563
Exemplos: 1. Sistema de Controle de Conta Corrente No ambiente de um sistema de controle de conta corrente, temos pessoas que so clientes de um banco. Pode-se ento definir uma entidade cliente. Neste mesmo sistema, as contas mantidas no banco podero ser definidas como uma entidade conta.
CLIENTE
CONTA
Figura 40.
Exemplo: Sistema de Controle de contas de um Hospital No contexto de um sistema de controle de contas de um hospital, algumas pessoas desempenham a funo de mdicos. Neste mesmo sistema, as pessoas que iro realizar uma consulta desempenham a funo de pacientes. Estas pessoas so ocorrncias de entidades distintas: mdicos e pacientes. Note que um mdico em um determinado momento tambm pode desempenhar a funo de um paciente.
MDICO
PACIENTE
Figura 41.
Ateno: O identificador de uma entidade deve ser um nome relevante ao assunto que representar e recomenda-se que:
No sejam utilizados caracteres especiais tais como acento, cedilha, *, $, entre outros; No seja iniciado por nmeros; Esteja no singular.
Na etapa de implementao do modelo deve-se tambm atentar para as recomendaes e particularidades do SGBDR utilizado.
5.3. Cuidado: Aquilo que entidade numa circunstncia, pode no ser em outra!
Portanto, ao identificar as entidades de um sistema de informao, os desenvolvedores de software devem estar atentos possibilidade de uma coisa do mundo real desempenhar mais de um papel no contexto deste sistema.
44
IBTA 2563
5.4. Tipos de Entidades

5.4.1. Entidade Meramente Conceitual Uma entidade meramente conceitual aquela que representa uma classe de domnio e que no tem outras propriedades que no seu prprio conceito. Exemplos: Data, Hora, Perodo
5.4.2. Entidade Forte Uma entidade forte aquela que no depende de outra entidade para existir. Exemplo: No contexto de uma organizao faz-se necessrio o armazenamento de dados de um funcionrio por diversas demandas, uma delas a folha de pagamento. Cada ocorrncia de funcionrio r identificada de forma nica, por exemplo por uma atributo identificado por registro funcional, sendo assim a entidade funcionrio uma entidade forte.
5.4.3. Entidade Fraca Entidades cuja existncia depende da existncia de outra entidade, dita forte. representada por um retngulo duplo, podendo, opcionalmente, ser indicada uma seta que parte dela e chega a sua entidade forte, para tornar mais clara a dependncia. A cardinalidade de uma ocorrncia de uma entidade fraca com a forte sempre (1,1), indicando que ela sempre depende de uma ocorrncia da entidade forte. Em poucas palavras, entidade fraca aquela que depende de uma outra entidade para existir. entidade da qual depende d-se o nome de entidade pai. Exemplo: Os funcionrios de uma empresa possuem dependentes, por exemplo, seus filhos, cujos dados so utilizados por exemplo para concesso de benefcios ou descontos de IRRF. Os dados de dependentes esto relacionados diretamente existncia de uma ocorrncia de funcionrio.
FUNCIONRIO
1:1
possui
0:N
DEPENDENTE
Figura 42.
5.4.4. Entidade Associativa Uma entidade associativa aquela que no existe por si s e sua existncia est condicionada existncia de duas ou mais entidades, a partir das quais ela concebida.
45
IBTA 2563
Exemplo: A entidade associativa aluno x disciplina surge quando h a derivao do modelo lgico a partir do modelo conceitual devido ao relacionamento n:n entre a entidade aluno e a entidade disciplina26.
5.4.5. Entidade de Dados Podem ser subdivididas em diversas categorias de elementos (Subtipos), cada uma se caracterizando por atributos especficos.
Pessoa
Fsica
Jurdica
Figura 43.
Supertipo: o conjunto de caractersticas que originou o subtipo. Subtipo: definido como um subconjunto de caractersticas de um tipo. Exemplo: Supertipo pessoa e subtipos Pessoa Fsica e Pessoa Jurdica.
26
Veja tpico sobre Derivao do Modelo Lgico a partir do Modelo Conceitual nos captulos anteriores.
46
IBTA 2563
6. Atributos
Conforme vimos anteriormente, cada entidade tem propriedades particulares, chamadas atributos, estas propriedades podem identificar, qualificar ou quantificar a entidade, em outras palavras os atributos descrevem as entidades. Por exemplo, uma entidade funcionrio pode ser descrita pelo seu nome, o trabalho que realiza, data de nascimento, endereo e salrio. Cada ocorrncia de uma entidade ter um valor para cada um de seus atributos.
6.1. Como identificar os atributos?

Para identificar um atributo devemos estabelecer quais so suas caractersticas. Remetendo-nos a entidade funcionrio, podemos perguntar Quais so as caractersticas de um funcionrio? O que o identifica?. Responder a essas perguntas traz os atributos da entidade. No nosso exemplo, as respostas poderiam ser: Nome, Endereo, Telefone, Data de Nascimento, Cargo, Salrio, Cdigo do Funcionrio. Percebam que essas caractersticas so os atributos do funcionrio.
6.2. Representaes de Atributos

Assim como para as entidades, a representao de uma atributo depende da metodologia escolhida para a modelagem, conforme vimos nos captulos anteriores. Neste material utilizaremos a metodologia proposta por Peter Chen que utiliza uma elipse para representar os atributos e em alguns exemplos ilustraremos como a representao utilizada pelo Erwin 27.
Peter Chen
Erwin
FUNCIONARIO FUNCIONRIO cod_func nome dt_nasc cargo endereco
cod_func dt_nasc nome cargo
endereo
Figura 44.
27
Ferramenta de Modelagem relacional comercializada pela empresa Computer Associates. 47

IBTA 2563
6.3. Classificao de Atributos

Cougo28 classifica os atributos em trs grupos:
Atributos Descritivos: Atributos que expressam caractersticas intrnsecas ao objeto, isto ,

que representam qualidades ou descries de um objeto. Por exemplo: data de nascimento, endereo, cor dos cabelos, peso, sexo, modelo de um automvel.
Atributos Nominativos: Atributos que podem identificar um objeto, mesmo que no o faa de
maneira nica. Por exemplo: Nome de um funcionrio, Registro acadmico de um aluno, Cdigo do produto, Placa de um automvel. Ateno: Os atributos nominativos podem ser chaves candidatas e aqueles que atendem aos critrios podem vir a ser chaves primrias.
Atritutos Referenciais: Atributos que no pertencem entidade a qual esto alocados, mas
que fazem algum tipo de citao ou estabelecem uma relao entre esta entidade e a entidade de origem. Normalmente estes atributos so as chaves estrangeiras. No exemplo apresentado a seguir note que a entidade FUNCIONARIO tem o atributo cod_dept (cdigo do departamento), mas este atributo, originalmente um atributo nominativo da tabela DEPARTAMENTO, sendo assim para a entidade FUNCIONARIO este atributo um atributo referencial, pois ser utilizado para estabelecer um relacionamento 29 com a tabela DEPARTAMENTO.
FUNCIONRIO
DEPARTAMENTO
cod_func
cod_dept cod_func nome_dept cod_dept
nome_func
end
Figura 45.
6.4. Tipos de atributos

Independente da sua classificao um atributo pode possuir caractersticas que nos possibilitam defini-los como:
Atributo Simples Atributo Composto Atributo Monovalorado
28 29
Cougo, Paulo. Modelagem Conceitual e projeto de banco de dados. Rio de Janeiro:Campus, 1997 Este assunto foi apresentado anteriormente e ser detalhado no prximo captulo
48
IBTA 2563
Atributo Multivalorado Atributo Derivado ou virtual Atributo Opcional Atributo Chave

6.4.1. Atributo Simples Atributos que no so divisveis so chamados simples ou atmicos, por exemplo o atributo cargo para a entidade FUNCIONARIO.
6.4.2. Atributo Composto Alguns atributos podem ser divididos em subpartes com significados independentes. Um atributo que composto de outros atributos mais bsicos chamado composto. Ateno: Atributos compostos podem formar uma hierarquia. No exemplo a seguir o endereo da entidade FUNCIONARIO pode ser dividido em endereo da rua, cidade, estado e cep; o atributo endereo da rua pode ser subdividido em nome da rua, numero do imvel e complemento.
FUNCIONRIO
cod_func nome_func end
cod_dept
cep end_rua cidade
UF
nome_rua nmero
complemento
Figura 46.
Atributos compostos so teis quando os usurios referenciam o atributo composto como uma unidade e, em outros momentos, referenciam especificamente a seus componentes. Se o atributo
49
IBTA 2563
composto for sempre referenciado como um todo, no existe razo para subdividi-lo em componentes elementares.
6.4.3. Atributo Monovalorado Um atributo monovalorado - tambm chamado de univalorado - possui um valor nico, ou seja, s existe uma representao daquele atributo para a mesma tupla. Vejamos, por exemplo, o atributo idade: um funcionrio nunca poder ter mais de uma idade ao mesmo tempo, o que torna esse atributo monovalorado.
6.4.4. Atributo Multivalorado Uma nica entidade que tem ocorrncias com diversos valores para este atributo. Atributos multivalorados podem possuir uma multiplicidade, indicando as quantidades mnima e mxima de valores.
1:1
FUNCIONARIO POSSUI
0:N
DEPENDENTE
cod_func
dt_nasc
endereco
cod_finc
nome
nome
cargo
Figura 47.
6.4.5. Atributo Derivado ou Virtual De acordo com Silberschatz [1] o valor deste tipo de atributo pode ser derivado de outros atributos ou entidades a ele relacionados. Por exemplo a idade de um funcionrio pode ser obtida a partir da subtrao entre o valor do atributo data de nascimento e a data corrente. Em outro caso, alguns valores de atributos podem ser derivados de entidades relacionadas, por exemplo, um atributo nmero de funcionrios de uma entidade DEPARTAMENTO que pode ser calculado contando-se o nmero de funcionrios relacionados com cada departamento.
6.4.6. Atributo Opcional ou Nulo So atributos para os quais no existe a obrigatoriedade de preenchimento de dados, isto , so atributos cujo preenchimento de dados opcional. De acordo com Silberschatz [1] um atributo nulo usado quando uma entidade no possui um valor para um determinado atributo. Por exemplo, o atributo complemento aplica-se somente
50
IBTA 2563
queles funcionrios que residam em algum prdio ou vila, nesse caso nas ocorrncias da entidade FUNCIONARIO para as quais os dados do atributo complemento no forem informados o valor deste atributo ser nuto. Ateno: O nulo pode ser utilizado para denotar que o valor desconhecido ou inexistente.
6.4.7. Atributo Chave Os atributos utilizados para identificar uma entidade, para indexar as ocorrncias da entidade ou os atributos referenciais so chaves. Conforme vimos anteriormente as chaves podem ser:
Chave Primria: um atributo ou um conjunto de atributos que identifica unicamente cada

ocorrncia da entidade, sendo assim, uma ocorrncia no pode conter, neste atributo, um dado (valor) que j esteja armazenado em outra ocorrncia. Exemplo: No contexto de um sistema de controle acadmico o nmero de matricula de uma entidade aluno um atributo identificador j que identifica de forma nica um aluno dentro de uma faculdade.
Chave Estrangeira: um atributo ou conjunto de atributos usado para estabelecer um

relacionamento entre duas entidades. Na entidade de origem deve ser chave primria.
Chave Secundria(Terciria, etc): So chaves que possibilitaro pesquisas ou ordenaes

alternativas, ou seja, diferentes da ordem criada a partir da chave primria ou da ordenao natural (fsica) da tabela.
Chave Composta: a chave que contm mais de um atributo (Por exemplo, um cadastro
ordenado alfabeticamente por Estado, Cidade e Nome do Cliente, necessitaria de uma chave composta que contivesse estes trs atributos).
Chave candidata: So atributos que podem vir a ser chave primria.

Exemplo: A entidade FUNCIONARIO tem os atributos: registro funcional, nome, cpf, rg, endereco, dt_nascimento. Os atributos registro funcional, cpf e rg so chaves candidatas, pois podem identificar cada ocorrncia de FUNCIONARIO. Mas para que uma chave candidata possa ser eleita a chave primria dever atender a restrio de unicidade, isto o contedo do campo dever ser nico para cada ocorrncia da entidade. A seguir apresentamos um exemplo de classificao de atributos para as entidades FUNCIONARIO, DEPARTAMENTO e DEPENDENTES:
FUNCIONRIO ENTIDADE reg_funcional nome_func atributos endereo cpf rg cod_dept

Tabela 10.
Classificao dos Atributos atributo nominativo chave primria atributo nominativo chave candidata atributo descritivo composto atributo nominativo chave candidata atributo nominativo chave candidata atributo referencial chave estrangeira a origem do atributo est na entidade DEPARTAMENTO.
51
IBTA 2563
DEPENDENTE ENTIDADE reg_funcional cod_dependente
Classificao dos Atributos atributo referencial chave estrangeira atributo nominativo junto com o atributo reg_funcional compe a chave primria; esta uma entidade FRACA, pois a existncia de uma ocorrncia desta entidade depende de um relacionamento com a entidade FUNCIONRIO; no possui um atributo que sozinho consiga identificar cada ocorrncia da entidade. atributo descritivo atributo descritivo
atributos
data_nascimento parentesco
nome_dependente atributo nominativo

Tabela 11.
DEPENDENTE ENTIDADE reg_funcional cod_dependente
Classificao dos Atributos atributo referencial _ chave estrangeira atributo nominativo junto com o atributo reg_funcional compe a chave primria; esta uma entidade FRACA, pois a existncia de uma ocorrncia desta entidade depende de um relacionamento com a entidade FUNCIONRIO; no possui um atributo que sozinho consiga identificar cada ocorrncia da entidade. atributo descritivo atributo descritivo
atributos
data_nascimento parentesco
nome_dependente atributo nominativo

Tabela 12.
52
IBTA 2563
7. Relacionamentos
7.1. Introduo
De acordo com Machado [3] os relacionamentos podem ser definidos como o fato ou o acontecimento que liga dois objetos (entidades), duas coisas do mundo real. No ambiente relacional podemos entender o relacionamento como o fato que efetua a juno de duas ou mais tabelas de dados.
F1 F2 F3 Funcionrio Trabalha
P1 P2 Projeto
N
Funcionrio Trabalha
N
Projeto
Figura 48. Relacionamento Binrio.
Um relacionamento estabelece a conexo entre duas tabelas dentro de um banco de dados. Este relacionamento entre tabelas possvel atravs da relao entre as chaves primria e estrangeira ou atravs de uma terceira tabela chamada tabela de vnculo. Esta conexo entre tabelas depende do tipo de relacionamentos existente entre elas. Porque um relacionamento fundamental dentro de um banco de dados?
Estabelece uma conexo entre tabelas que esto logicamente relacionadas, entre os dados
contidos nelas.
o mecanismo que permite que dados de vrias tabelas sejam agrupados para extrao
simultnea.
Permite aprimorar as definies das estruturas de tabelas e a reduo de dados redundantes. Estabelece a integridade em nvel de relacionamento quando definido corretamente.
A importncia na definio dos relacionamentos corretamente est relacionada com a qualidade do banco de dados projetado, pois se mal projetados traro prejuzo na manipulao simultnea entre tabelas, para insero, atualizao e excluso de registros em tabelas relacionadas.
53
IBTA 2563
7.2. Como identificar os Relacionamentos?

De acordo com Cougo30, o que estabelecer relacionamentos vlidos ou no ser o grau de fidelidade e completeza que se consegue atingir durante o processo de modelagem. Segundo ele so possveis os relacionamentos entre instncias de objetos (entidades) de diferentes tipos ou relacionamentos entre instncias de um mesmo tipo de objeto (entidade). Para identificarmos a existncia dos relacionamentos entre as entidades basta observarmos como estes objetos (entidades) se comportam no mundo real, por exemplo se tivermos a seguinte situao: Matheus proprietrio de um imvel na praia de Ubatuba. Cougo31 sugere as seguintes etapas para identificao e mapeamento dos relacionamentos:
Identificar as entidades envolvidas.

Matheus uma ocorrncia32 da entidade que chamaremos de PESSOA; Imvel na praia de Ubatuba uma ocorrncia da entidade que chamaremos de IMOVEL
Identificar os atributos das entidades.

Ateno: Para isso importante valer-se das tcnicas para levantamento de dados e anlise de requisitos. PESSOA pode ser caracterizada pelos atributos: nome, data de nascimento, rg, cpf IMOVEL pode ser caracterizado pelos atributos: endereo, tamanho, tipo
Representao das entidades
PESSOA
Figura 49.
IMVEL
Identificao dos relacionamentos

PESSOA proprietria de um IMVEL.
Caracterizao do relacionamento entre as entidades

Nem toda PESSOA proprietria de um IMOVEL. Um IMOVEL pode (ou no) pertencer a uma ou muitas ocorrncias da entidade PESSOA. Algumas ocorrncias de PESSOA podero possuir mais de um IMOVEL.
30 31 32
Cougo, Paulo. Modelagem Conceitual e projeto de banco de dados. Rio de Janeiro:Campus, 1997 Cougo, Paulo. Modelagem Conceitual e projeto de banco de dados. Rio de Janeiro:Campus, 1997 Ocorrncia, instncia e registro so similares.
54
IBTA 2563
Representao do Relacionamento
0:N
PESSOA Possui
0:N
IMVEL
Figura 50. Relacionamento entre PESSOA X IMVEL - metodologia de Peter Chen
Observe no exemplo apresentado que o primeiro passo para identificar o relacionamento compreender como as coisas se comportam no mundo real, a partir deste entendimento possvel caracterizar o relacionamento entre elas, isto , definir o grau do relacionamento entre as entidades. Em outras palavras, definir se uma ocorrncia de uma entidade poder ou dever se relacionar com uma ou muitas ocorrncias da outra tabela e vice-versa.
7.3. Cardinalidade
A cardinalidade ou grau do relacionamento uma restrio que expressa o nmero de ocorrncias de uma entidade ao qual outra entidade pode estar associada por meio de um relacionamento. Por exemplo: Todo FUNCIONARIO trabalha em um DEPARTAMENTO. O DEPARTAMENTO pode ter muitos FUNCIONARIOS. A seguir, considerando a caracterizao do relacionamento entre as entidades FUNCIONARIO e DEPARTAMENTO veja como a relao entre as ocorrncias das entidades:
FUNCIONRIO cod_func 7839 7782 7566 7698

Tabela 13.
DEPARTAMENTO deptno 10 10 20 30 deptno 10 20 30 40 nome-dept Accouting Research Sales operations Loc New YorkDallas Chicago Boston
nome_func King Clark Jones Blake
O FUNCIONRIO King trabalha no DEPARTAMENTO 10. O FUNCIONRIO CLARK trabalha no DEPARTAMENTO 10. O DEPARTAMENTO 10 possui 2 ocorrncias de FUNCIONARIO (King e Clark), mas cada uma destas ocorrncias de FUNCIONARIO est associada a apenas uma ocorrncia de DEPARTAMENTO (10).
55
IBTA 2563
As cardinalidade possveis so:
Zero-para-um (0:1) - Uma entidade A pode estar associada a uma entidade em B, no

havendo obrigatoriedade de associao da entidade B com a entidade A.
Zero-para-muitos (0:N) - Uma entidade em A pode estar associada a qualquer nmero de

entidades em B, no havendo obrigatoriedade de associao da entidade B com a entidade A. um caso especfico da cardinalidade N:M onde N vale 0.
Um-para-um (1:1) - Uma entidade em A est associada a no mximo uma entidade em B, e

uma entidade em B est associada a no mximo uma entidade em A.
Um-para-muitos (1:N) - Uma entidade em A est associada a qualquer nmero de entidades

em B, entretanto uma entidade em B est associada a no mximo uma entidade em A.
Muitos-para-muitos (N:N) - Uma entidade em A est associada a qualquer nmero de

entidades em B, e uma entidade em B est associada a qualquer nmero de entidades em A. Exemplos:
1:1
FUNCIONARIO Trabalha em
1:1
DEPARTAMENTO
Departamento
possui um/ trabalha em
Funcionrio
Departamento
possui um/ trabalha em
Funcionrio
Figura 51.
Cada funcionrio trabalha em um departamento Um departamento pode conter nenhum ou muitos funcionrios;
1:1
FUNCIONARIO Possui
1:1
CONTRATO
possui um/ Funcionrio pertence a um Contrato
Funcionrio
possui um/ pertence a um
Contrato Figura 52.
56
IBTA 2563
Cada funcionrio possui um contrato Cada contrato pertence a um funcionrio
N:N
FUNCIONARIO PARTICIPA
N:N
PROJETO
participa de/ Funcionrio realizado por Projeto
Funcionrio Figura 53.
participa de/ realizado por
Projeto
Cada funcionrio pode participar de muitos projetos Cada projeto pode ser realizado por muitos funcionrios
q O que deve ser feito em casos de relacionamentos muitos-para-muitos

Por definio o modelo relacional no permite a representao de relacionamentos muitos-para-muitos. Para resolver essa limitao do modelo relacional preciso criar uma entidade intermediria conhecida como entidade associativa. A entidade associativa , portanto, uma entidade intermediria gerada a partir de duas entidades com relacionamento muitos-para-muitos. Por exemplo, no caso das entidades FUNCIONRIO e PROJETO existe um relacionamento muitos-para-muitos porque muitos funcionrios trabalham em muitos projetos e muitos projetos so executados por muitos funcionrios. Nesse caso precisaremos de uma entidade associativa. A nova entidade ser chamada de FUNCIONRIO/PROJETO e ter relacionamento 1:N com FUNCIONRIO e 1:n com PROJETO. A chave primria das entidades associativas uma chave composta pela chave primria de FUNCIONRIO e pela chave primria de PROJETO.
N
PROJETO
FUNCIONRIO/ PROJETO
N
FUNCIONRIO
Figura 54.
57
IBTA 2563
8. Modelo Entidade Relacionamento Estendido
8.1. Natureza do Relacionamento

Relacionamentos Parciais e Totais Relacionamentos Recursivos ou Auto-Relacionamento Relacionamentos Mltiplos Agregao
8.1.1. Relacionamentos Parciais e Totais Quando todo o elemento da entidade est obrigatoriamente no relacionamento, caso contrrio temos um relacionamento parcial.
Funcionrio N
Lota 1
Departamento
Figura 55.
Todo funcionrio obrigatoriamente ( | ) lota um departamento, mas nem todo (0) departamento lotado por funcionrios
8.1.2. Relacionamentos Recursivos ou Auto-Relacionamento Os auto-relacionamentos so casos especiais onde uma Entidade se relaciona com si prpria. Os auto-relacionamentos podem ser de tipo Um-para-Um, Um-para-Muitos ou Muitos-para-Muitos.
Funcionrio N GERENCIA GERENCIADO
Gerencia
Figura 56.
58
IBTA 2563
Funcionrio desempenha o papel de gerente ou de subordinado.
8.1.3. Relacionamentos Mltiplos / Agregao a associao que envolve mais de duas Entidades.
Professor
Ensina
Disciplina
N Aluno
Figura 57.
Obs.: Para entendermos este relacionamento devemos cortar uma das arestas e fazermos um relacionamento binrio. Devido a uma limitao do modelo E-R no possvel expressar relacionamentos entre relacionamentos. Para resolver esse problema usamos a agregao. Ao associarmos um conjunto de Entidades e um Relacionamento temos uma Agregao. A agregao aplicada aos modelos para facilitar o entendimento semntico e tornar mais claros os graus dos relacionamentos ternrios ou de maior nmero. A agregao , na realidade, uma abstrao do modelo E-R atravs da qual relacionamentos so tratados como entidades de nvel superior. Vamos ver no exemplo:
Funcionrio N
Trabalha
N N
Projeto
Utiliza N Mquina
Figura 58.
Temos um relacionamento N:N entre FUNCIONRIO e PROJETO, outro relacionamento N:N entre FUNCIONRIO e MQUINA e, por fim, outro relacionamento N:N entre MQUINA e PROJETO. Agora iremos representar o relacionamento entre duas entidades como se fosse uma nova entidade. Vamos considerar o relacionamento entre FUNCIONRIO e PROJETO como se fosse uma nova entidade e iremos represent-la como sendo uma nova entidade. A seguir
59
IBTA 2563
devemos estabelecer o relacionamento entre a entidade MQUINA e a nova entidade. Veja como essa operao fica representada graficamente:
Funcionrio
Trabalha
Projeto
N Utiliza N Mquina
Figura 59.
Note que o relacionamento feito com a nova entidade e no com o relacionamento (a reta vai at a nova entidade e no at o relacionamento TRABALHA). A partir dessa nova modelagem podemos fazer uma releitura do modelo. Podemos interpretar que quando um funcionrio trabalha em um projeto ele utilizar uma mquina.
Funcionrio
Trabalha
Projeto
N Utiliza N Mquina
Figura 60.
60
IBTA 2563
Professor
Ensina
Disciplina
Cursa
N Aluno
Figura 61.
O modelo E-R uma ferramenta valiosa para qualquer sistema com mltiplos depsitos (objetos) e complexos relacionamentos de dados. Ele inteiramente voltado para os relacionamentos de dados, sem oferecer quaisquer informaes sobre as funes que criam ou utilizam os dados.
8.2. Generalizao-Especializao
Existem casos em que uma entidade pode ser dividida em categorias, cada qual com atributos especficos, isto , a entidade pode possuir subclasses ou pertencer asuperclasses. A associao entre uma Generalizao (superclasses) e suas Especializaes (subclasses) representado por um tringulo e recebe o nome de "IS A" ( um).
Cdigo Filial N atende N Cliente Nome
CIC Sexo Pessoa Fsica CGC Figura 62. Pessoa Jurdica
No caso temos a Super-Classe CLIENTE e as Sub-Classes PESSOA FSICA e PESSOA JURDICA. O que diferencia essas duas subclasses so alguns poucos atributos.
61
IBTA 2563
O uso de uma estrutura de Generalizao-Especializao tambm conhecido como PARTICIONAMENTO. Sua principal utilidade que com ele podemos representar ENTIDADES com ATRIBUTOS parcialmente disjuntos, alm de permitir que um RELACIONAMENTO fique restrito a um subconjunto de uma ENTIDADE. Uma superclasse , portanto, uma GENERALIZAO de um conjunto de ESPECIALIZAES (subclasses). Cada ESPECIALIZAO herda atributos e relacionamentos da ENTIDADE da qual derivou. O RELACIONAMENTO entre Especializaes de uma mesma Generalizao um tipo de Auto-Relacionamento.
9. Normalizao
A Normalizao um processo formal passo a passo que examina os atributos de uma entidade com o intuito de evitar anomalias de armazenamento de tuplas (registros) especficas. Esse processo causa a simplificao dos atributos dentro da respectiva tupla, eliminando grupos repetitivos, dependncias parciais de chaves concatenadas, dependncias transitivas, entre outros, colaborando sobremaneira para integridade e a estabilidade do modelo. A experincia tem mostrado que o investimento de tempo que se faz para efetuar manutenes em uma base de dados implementada inversamente proporcional ao tempo aplicado no processo de normalizao. Para se atingir esse estgio, necessrio que as tuplas sejam analisadas de modo a verificar se seus atributos apresentam relaes no normalizadas, submetendo-as a conceitos subseqentes de primeira, segunda e terceira forma normal (FN). H tambm outras formas normais superiores terceira FN, ou seja, Boyce-Cood (BCFN), quarta forma normal, quinta forma normal e chave-domnio, que visam a agrupar atributos em tuplas mais refinadas e distintas a fim de se evitarem anomalias especficas. Porm, atingir o nvel de terceira forma normal suficiente para a maioria dos propsitos prticos de normalizao, sendo rara a necessidade de perseguir formais superiores. A normalizao um mecanismo para transformar estruturas complexas de dados em sua forma mais simples. Portanto, diz-se que uma estrutura de dados est "normalizada" quando est em seu estgio de maior simplicidade. Simplicidade de uma estrutura pode ser definida como a existncia de apenas dependncia funcional. Assim, uma tabela deve conter apenas informaes que se refiram a um mesmo tipo de dados, ou seja, todas as colunas da tabela devem depender funcionalmente da chave primria. Em resumo, a normalizao consiste em descobrir o lugar certo para cada coisa e colocar cada coisa em seu devido lugar, com o objetivo de:
minimizao de redundncias e inconsistncias; facilidade de manipulaes do Banco de Dados; facilidade de manuteno do Sistema de Informaes.
Os trs principais casos de anomalias que caracterizam uma estrutura desnormalizada so:
Grupo Repetitivo: Conjunto de atributos de uma entidade que ocorre mltiplas vezes para
cada ocorrncia da Entidade.
62
IBTA 2563
Dependncia Funcional Parcial: Quando um atributo depende de parte da chave primria

(chave composta)
Dependncia Transitiva: Dependncia indireta entre dois ou maisatributos.
9.1. Primeira Forma Normal (1FN)

Por definio, a 1 Forma Normal consiste na normalizao da tupla, de forma que o relacionamento entre a sua chave e os seus atributos sejam unvocos, isto , para cada chave h a ocorrncia de um e somente um dado.
q Procedimentos
identificar a chave primria da entidade; identificar os atributos que formam o grupo repetitivo e remov-lo da entidade; criar uma nova entidade com a chave primria da entidade anterior e o grupo repetitivo.
A chave primria da nova entidade ser obtida pela concatenao da chave primria da entidade inicial e um ou mais atributos do grupo repetitivo. Exemplo: A empresa Bits Ltda possui um formulrio para solicitao de compra de produtos para empresa.
BITS SA Fornecedor: 0256 Plano comisso:
ORDEM DE COMPRA NEW DATA SYSTEM LTDA A Dt de Cadastro Dt de entrega Quantidade 5 100 6 01/01/2003 05/01/2003
ORD N 1234
Cdigo do Produto Descrio do Produto 015460 122236 456698 PAPEL A4 RESMA-500 FLS CD-RW 700M TINTA P/IMPRESSORA HP850
Valor Unitrio Valor Total 10,00 1,20 85,00 TOTAL: 50,00 120,00 510,00 680,00
Tabela 14.
Analisamos o formulrio por ela utilizado e verificamos a necessidade de criar uma entidade ORDEM com seus atributos. Aplicando a 1 Forma Normal criamos uma entidade chamada ORDEM_ITEM que armazenar o grupo repetitivo encontrado. Como chave primria para entidade ORDEM_ITEM teramos uma chave concatenada (Cdigo da Ordem + Cdigo do Item).
63
IBTA 2563
Notem que, no diagrama, os atributos Cdigo da Ordem e Cdigo do Produto foram indicados como PK. Isso foi feito para ressaltar que ambas formam uma chave primria composta. Cdigo da Ordem , na verdade, uma chave estrangeira.
Entidade PK
ORDEM Cdigo da Ordem Data de Cadastro Plano de Comisso Data da Entrega Cdigo Fornecedor Nome do Fornecedor Valor Total da Ordem Cdigo do Produto Descrio do Produto Preo Unitrio do Produto Quantidade do Produto Preo Total do Produto
Entidade PK PK
ORDEM_ITEM Cdigo da Ordem Cdigo do Produto Descrio do Produto Preo Unitrio do Produto Quantidade do Produto Preo Total do Produto N
1 Entidade PK ORDEM Cdigo da Ordem Data de Cadastro Plano de Comisso Data da Entrega Cdigo Fornecedor Nome do Fornecedor Valor Total da Ordem
Figura 63.
9.2. Segunda Forma Normal (2FN)

Conforme vimos anteriormente, existem algumas tuplas que, para serem identificadas e individualizadas, necessitam conter em sua chave mais de um atributo, formando uma chave concatenada. Aps submeter a tupla anlise e converso para a 1 Forma Normal, o prximo passo verificar se a mesma possui chave concatenada, e, se for o caso, constatar se todos os atributos no chaves no apresentam dependncia parcial com a referida chave. A dependncia parcial uma situao particular em que os atributos no chaves dependem parcialmente de um atributo da chave concatenada.
q Procedimentos
Identificar os atributos que possuem dependncia parcial.
64
IBTA 2563
Remover da entidade todos esses atributos identificados e criar uma nova entidade com eles. A chave primria da nova entidade ser o atributo do qual os atributos removidos so
funcionalmente dependentes. Exemplo : Continuando a anlise da Ordem de Compra. A criao da entidade ORDEM_ITEM fez com que a chave primria da entidade ORDEM fosse transportada para a nova entidade ORDEM_ITEM, que juntamente com os atributos transferidos pela aplicao da 1 Forma Normal fossem para a entidade ORDEM_ITEM. A chave da nova entidade passou a ser a chave concatenada formada por [Cdigo da Ordem + Cdigo do Item]. Entretanto o atributo [Descrio do Produto] apresenta dependncia parcial com a chave primria concatenada da entidade ORDEM_ITEM, sugerindo a aplicao da 2 Forma Normal.
Entidade PK PK
ORDEM_ITEM Cdigo da Ordem Cdigo do Produto Descrio do Produto Preo Unitrio do Produto Quantidade do Produto Preo Total do Produto
Entidade PK
PRODUTO Cdigo do Produto Descrio do Produto 1
N Entidade ORDEM_ITEM Cdigo do Item Cdigo do Produto Preo Unitrio do Produto
PK PK - FK
1 Entidade PK ORDEM Cdigo da Ordem Data de Cadastro Plano de Comisso Data da Entrega Fornecedor Valor Total da Ordem Entidade PK
Quantidade do Produto Preo Total do Produto N
1 ORDEM Cdigo da Ordem Data de Cadastro Plano de Comisso Data da Entrega Cdigo Fornecedor Nome do Fornecedor Valor Total da Ordem
Figura 64.
65
IBTA 2563
9.3. Terceira Forma Normal (3FN)

Na definio de uma tupla, pode ocorrer de alguns atributos no serem dependentes diretos da chave da mesma, mas sim, por transitividade atravs de outros atributos residentes na mesma tupla referenciada. Submetida a tupla anlise e converso para a 2 Forma Normal, verifica-se em seguida se todos os atributos no chaves no apresentam dependncia transitiva com a sua chave. A dependncia transitiva dependncia indireta que um determinado atributo tem com a chave da tupla atravs de um outro atributo no chave, do qual diretamente dependente.
q Procedimentos
Identificar todos os atributos que possuem dependncia transitiva. Remov-los e criar uma nova entidade com os mesmos. A chave primria da nova entidade ser o atributo do qual os atributos removidos so
funcionalmente dependentes.
Entidade PK
Entidade PK
N Entidade PK PK - FK ORDEM_ITEM Cdigo do Item Cdigo do Produto Preo Unitrio do Produto Quantidade do Produto Preo Total do Produto N 1 Entidade PK PK - FK
N ORDEM_ITEM Cdigo do Item Cdigo do Produto Preo Unitrio do Produto Quantidade do Produto Preo Total do Produto N Entidade PK 1 FORNECEDOR Cdigo do Fornecedor Nome do Fornecedor 1 Entidade PK ORDEM Cdigo da Ordem Data de Cadastro Plano de Comisso Figura 65. Data da Entrega FK Cdigo Fornecedor Valor Total da Ordem N
Entidade PK
ORDEM Cdigo da Ordem Data de Cadastro Plano de Comisso Data da Entrega Cdigo Fornecedor Nome do Fornecedor Valor Total da Ordem
66
IBTA 2563
9.4. Forma Normal de Boyce-Codd (FNBC)

Similar a 3FN, porm mais rgida, foi criada para sanar algumas deficincias encontradas na 3FN. Toda relao na NFBC tambm est na 3FN, no entanto, uma relao da 3FN no est, obrigatoriamente, na FNBC. Segundo Machado33, "Uma entidade est na FNBC se e somente se todos os determinantes forem chaves candidatas", e a FNBC ocorre quando 3 condies aparecerem juntas:
A entidade possuir vrias chaves candidatas; As chaves candidatas forem compostas; As chaves compostas compartilharem pelo menos um atributo em comum.
Exemplo: vamos considerar a relao TURMA (aluno, professor, matria) Onde: Cada aluno s assiste a uma determinada disciplina com um professor; Cada professor ministra uma matria; A matria pode ser ministrada por vrios professores. Nesse caso, a matria funcionalmente dependente de professor, que no chave candidata; dessa maneira a relao poderia ser dividida em 2 partes: (aluno, professor) e (matria, professor).
q Aplicao da FNBC, segundo Machado[32]:

S aplicvel em entidade que possuem chaves candidatas concatenadas; Verificar se alguma chave candidata concatenada um determinante, e em caso afirmativo,
criar uma entidade com os atributos que dependam funcionalmente desse determinante e cuja chave primria o prprio determinante.
9.5. Quarta Forma Normal (4FN)

De acordo com Heuser34, uma entidade est na 4FN se estiver na 3FN e no existirem dependncias multivaloradas. Exemplo: considerando a necessidade de saber qual equipamento utilizado por um funcionrio em um projeto.
33 34
Machado, Felipe Nery Rodrigues. Banco de Dados: Projeto e Implementao, rica, 2004 Heuser, Carlos Alberto. Projeto de banco de dados, Sagra Luzzatto, 2000 67
IBTA 2563
FUNCIONRIO
PROJETO
FUNCIONARIO(cdigo_func, nome)
Utiliza
EQUIPAMENTO(cdigo_equi, nome) PROJETO(cdigo_proj, nome)
EQUIPAMENTO Figura 66.
Considerando a implementao do relacionamento UTILIZA teramos os dados:
codigo_proj 101 101 101 102 102 102

Tabela 15.
cdigo_func 123 124 125 123 124 125
Cdigo_equip 1 1 1 2 2 2
A tabela encontra-se na 3FN, no entanto, os dados do equipamento so armazenados com redundncia, pois participam de um mesmo projeto trs funcionrios que utilizam o mesmo equipamento. Isso representa o conceito de dependncia funcional multivalorada e poderia ser resolvido aplicando a 4FN como segue:
FUNCIONRIO
Proj. Func
PROJETO
Proj. Equip
EQUIPAMENTO Figura 67.
68
IBTA 2563
q Aplicao da 4FN, segundo Machado [32]:

Para se normalizar em 4FN, a entidade tem de esta obrigatoriamente na 3FN; Verificar se a entidade possui atributos que no sejam participantes da chave primria e que
sejam multivalorados e independentes em relao a um mesmo valor da chave primria;
Retirar esses atributos no chaves e multivalorados, criando novas entidades para cada um
deles, herdando a chave primria da entidade desmembrada.
9.6. Quinta Forma Normal (5FN)

De acordo com da Silva35, uma tabela est na 5FN se estiver na 4FN e um relacionamento triplo no puder ser decomposto em relacionamentos binrios sem gerao de informao incorreta. Exemplo retirado de da Silva[34]: relacionamento Agente- Companhia-Produto.
AGENTE Joo Joo

Tabela 16.
COMPANHIA Ford GM
PRODUTO Carro Caminho
Premissa: se um agente vende um certo produto e ele representa uma companhia, ento ele vende um produto fabricado por esta companhia. Todos os pares se combinam:
AGENTE Joo Joo Joo Joo

Tabela 17.
COMPANHIA Ford Ford GM GM
PRODUTO Carro Caminho Carro Caminho
Neste caso possvel decompor uma tripla em trs relaes binrias com eliminao de certas redundncias:
35
Denise Bandeira da Silva, disponvel em inf.unisinos.br/-bandeira, consultado em 15/11/2005 69

IBTA 2563
AGENTE X COMPANHIA
AGENTE Joo Joo
Tabela 18.
COMPANHIA Ford GM
AGENTE X PRODUTO
AGENTE Joo Joo
Tabela 19.
PRODUTO Carro Caminho
COMPANHIA X PRODUTO
COMPANHIA Ford Ford GM GM
Tabela 20.
PRODUTO Carro Caminho Carro Caminho
Resultado:
Apenas uma vez est dito que Ford produz carros; Apenas uma vez est dito que Joo agente da GM
q Aplicao da 5FN, segundo Machado [32]:

Aplicada em elementos que estejam na 4FN; A ocorrncia deste tipo de forma normal est vinculada aos relacionamentos mltiplos ou
entidades que possuam chave primria concatenada com trs ou mais atributos;
Verificar se possvel reconstruir o contedo do elemento original a partir de elementos

decompostos por ele;
Se no for possvel, o elemento observado no est na 5FN; caso contrrio, os elementos

decompostos representam um elemento na 5FN;
70
IBTA 2563
9.7. Resumo dos Passos para Normalizao

1. Identifique atributos (ou grupos) que possuam mltiplos valores para uma ocorrncia da entidade - 1FN 2. Remova os atributos (ou grupos) com uma copia da chave primria - 1FN 3. Identifique atributos dependentes somente de parte da chave primria - 2FN 4. Remova os atributos encontrados com uma cpia de parte da chave primria - 2FN 5. Identifique atributo(s) dependente(s) de outro(s) atributo(s) no chave - 3FN 6. Remova esses atributos com uma cpia do atributo do qual depende.
71
IBTA 2563
Exerccio 1 Conceitos de Banco de Dados Relacional

01. Quais so as principais caractersticas de um Sistema Gerenciador de um Banco de dados? R:
02. Quais so as caractersticas de um Banco de dados Relacional? R: Armazenamento de dados em Estruturas lgicas denominadas tabelas Controle de acesso aos dados Permite o relacionamento entre tabelas evitando a necessidade de armazenamentos duplicados desnecessariamente
1.1. Atividade envolvendo o Cenrio Instituio de Ensino "Aprendendo a Aprender" Etapa 1 Considere a seguinte situao: A instituio de Ensino Tcnico "Aprendendo a aprender", localizada na zona Norte de So Paulo, fundada em 1970 contava com aproximadamente 250 alunos, 18 professores e os cursos de Processamento de Dados e Magistrio, que eram oferecidos nos perodos manh, tarde e noite, alm dos 15 funcionrios que davam suporte administrativo e financeiro a instituio. Inicialmente a instituio controlava as suas informaes manualmente por meio de fichas que continham o histrico dos alunos, os dados cadastrais de alunos, professores e funcionrios, informaes sobre os cursos, entre outras informaes. Sabemos que os alunos so matriculados em curso, que os cursos so compostos por disciplinas e que as disciplinas so ensinadas por professores. A seguir so apresentados alguns exemplos de relatrios com as informaes que eram preenchidas:
72
IBTA 2563
ALUNO Nome Curso Semestre Data de RG Nascimento Endereo Completo (Rua, No., complemento, Bairro, Cep, Cidade, Estado) Rua Silva Jardim, no. 329 - Bela Vista - Cep 02460-044 - So Paulo/SP
Antonio Ubaldo da Silva Processamento 1 de dados
15/08/1955
3789789
Mariana Teles Guanabara
Magistrio
01/05/1953
48937321 Rua Irm Jussara, no. 33 apto. 5 - Jardim Eldorado - Cep 03845-000 - So Paulo/SP 2134812 Rua Diogo Prado, no. 4 - Vila Velha - Cep 04231-123 - So Paulo/SP
Aristides Almeida
Processamento 2 de dados
02/12/1952
CURSO Nome Processamento de Dados Magistrio Durao 2000 horas 1800 horas Disciplinas Clculo numrico, Portugus, Fundamentos de Computao ... Portugus, Tcnicas de Magistrio, Literatura ... Portaria de aprovao 578/70 579/70
DISCIPLINA Nome Clculo Numrico Clculo Numrico Tcnicas de Ensino Tcnicas de Ensino Carga Horria 80 80 80 80 Semestre 2 2 4 4 Professor Edgard Munhoz Beltro Edgard Munhoz Beltro Turma 1 2 Curso Processamento de dados Processamento de dados Magistrio Magistrio
Maria Eustquia 1 Xavier Maria Eustquia 1 Xavier
73
IBTA 2563
PROFESSOR Nome Edgard Munhoz Beltro Maria Eustquia Xavier Data de Nascimento 15/08/1935 11/10/1940 RG 1787789 12387941 Endereo Completo (Rua, No., complemento, Bairro, Cep, Cidade, Estado) Rua Altino Campestre, 32, Cep 04022-010 Jaboato, So Paulo/SP Rua Altamira, 48 apto. 3 - Vila Aurora - Cep 03847-100 - So Paulo/SP
Obs.: Os nomes e informaes so fictcios
04. Considerando a tabela ALUNO identifique e exemplifique: a. Um registro R: Antonio Ubaldo da Silva Processamento 1 de dados 15/08/1955 3789789 Rua Silva Jardim, no. 329 Bela Vista Cep 02460-044 So Paulo/SP
b. Um campo R: Nome c. dado R: Antnio Ubaldo da Silva
05. Supondo que voc tenha sido contratado para implementar este "banco de dados", e que tenha que sugerir um sistema gerenciador de bancos de dados para fazer isso, que aspectos voc levaria em considerao para sugerir o SGBD, justifique a sua resposta. R: Porte da empresa, Volume de informaes a serem gerenciados, Oramentos disponveis, Nvel de Segurana, Tempo de espera, entre outras.
06. Supondo que as informaes acima foram armazenadas em Tabelas, quais as caractersticas de um Banco de dados Relacional que no esto sendo consideradas de acordo com as informaes observadas? Justifique a sua resposta. R: Redundncia no armazenamento de informaes
74
IBTA 2563
1.2. Estrutura dos campos e tabelas
Considerando o Cenrio "Aprendendo a Aprender", faa o que se pede para cada uma das tabelas.
01. Defina o identificador, tipo de dado e tamanho adequado para cada campo. R:
ALUNO Nome Identificador nome_aluno Tipo de dado varchar2 Tamanho 30 Nome do Curso curso varchar2 20 Semestre semestre number 2 Data de Nascimento dt_nasc date RG rg number 9 Endereo Completo end varchar2 60
CURSO Nome Identificador Tipo de dado Tamanho nome_curso varchar2 20 Durao duracao number 5 Disciplinas disciplina varchar2 20 Portaria de aprovao port_apr varchar2 8
DISCIPLINA Nome Identificador nome_disc Tipo de dado varchar2 Tamanho 20 Carga Horria ch number 3 Semestre Sem Number 2 Professor professor varchar2 30 Turma turma varchar2 3 Nome do Curso curso varchar2 20
PROFESSOR Nome Identificador Tipo de dado Tamanho nome_aluno varchar2 30 Data de Nascimento dt_nasc date RG rg number 9 Endereo Completo end varchar2 60
75
IBTA 2563
02. Identifique um campo candidato chave primria, caso isso no seja possvel sugira o acrscimo de uma nova coluna tabela, indicando o nome da coluna e o tipo de dado. R: ALUNO poderia ser adicionado um campo Registro do Aluno (ra), do tipo numrico com 5 posies, ou ento considerar o campo RG CURSO poderia ser adicionado um campo Cdigo do Curso (cod_curso), do tipo numrico com 5 posies DISCIPLINA poderia ser adicionado um campo Cdigo da Disciplina (cod_disc), do tipo numrico com 5 posies PROFESSOR - poderia ser adicionado um campo Registro do Professor (rp), do tipo numrico com 5 posies, ou ento considerar o campo RG
03. Para que possamos estabelecer o relacionamento entre as tabelas e, com isso, evitar o armazenamento de informaes duplicadas deve-se acrescentar chaves estrangeiras s tabelas, sendo assim: a. Cite duas tabelas que deveriam ser relacionadas? R: ALUNO e CURSO DISCIPLINA e CURSO PROFESSOR e DISCIPLINA Quais seriam as vantagens obtidas ao relacionarmos as tabelas, alm de evitar a duplicao de informaes? R: Atualizao em uma nica fonte, garantindo a preciso da informao, economia de memria e espao em disco, otimizao de consultas, eliminao de colunas b. Identifique ou sugira campos que possam vir a ser chaves estrangeiras nas tabelas citadas na resposta 3.a R: Na tabela ALUNO o campo curso no qual est sendo matriculado, este campo poderia ser chamado curso, do tipo numrico com 5 posies. Na tabela DISCIPLINA poderia ser acrescida a coluna cdigo do curso ao qual est disciplina pertence, este campo poderia ser chamado curso, do tipo numrico com 5 posies. * Na tabela DISCIPLINA poderia ser acrescida a coluna cdigo do professor, este campo poderia ser chamado cod_prof, do tipo numrico com 5 posies, est sugesto no foi implementada nas solues apresentadas nos itens posteriores.
76
IBTA 2563
c. Com o relacionamento entre as tabelas da resposta 3.a quais campos poderiam ser eliminados nas tabelas? R: a princpio: ALUNO - Nome do curso DISCIPLINA - Nome do curso CURSO Nome da disciplina PROFESSOR nenhuma
04. Considere as sugestes apresentadas anteriormente e identifique as colunas que devem possuir restries, mencione qual a restrio que dever ser utilizada e justifique a sua resposta. R:
ALUNO Registro do Aluno Identificador ra Tipo de dado Tamanho Restrio number 5 Nome Cdigo do Curso Semestre semestre number 2 Data de RG Nascimento dt_nasc date rg Endereo Completo end
nome_aluno curso varchar2 30 number 5 foreing key
number varchar2 9 unique 60
primary key not null
CURSO Cdigo do Curso Identificador Tipo de dado Tamanho Restrio cod_curso number 5 primary key Durao duracao number 5 Portaria de aprovao port_apr varchar2 8
77
IBTA 2563
DISCIPLINA Cdigo da Nome Disicplina Identificador cod_disp Tipo de dado number Tamanho Restrio 5 nome_disc varchar2 20 Carga Horria ch number 3 not null Semestre sem number 2 Professor professor varchar2 30 Turma turma varchar2 3 Cdigo do Curso curso number 5 foreing key
primary key not null
PROFESSOR Registro do Professor Identificador Tipo de dado Tamanho Restrio rp number 5 primary key Nome nome_aluno varchar2 30 not nul Data de Nascimento dt_nasc date RG rg number 9 unique Endereo Completo end varchar2 60
78
IBTA 2563
Exerccio 2 Identificao de Entidades e Atributos

Caso: Instituio de Ensino "Aprendendo a Aprender"
Estamos no ano de 2004, a Instituio de Ensino "Aprendendo a Aprender" estar completando no prximo ano 35 anos de atuao, ao longo de sua existncia preserva a preocupao com a qualidade, no s nos seus servios prestados, mas principalmente no ser humano. Atualmente conta com 10.000 alunos, gradativamente deixou de oferecer cursos tcnicos e substituindo-os por cursos de Tecnologia, conta atualmente com 8 cursos de tecnologia, dentre eles Bancos de Dados, Redes de Computadores, Sistemas de Informao e Sistemas Web. Possui 500 funcionrios, sendo que, 300 so professores e 200 funcionrios administrativos. Os seus cursos continuam sendo oferecidos nos perodos matutino, vespertino e noturno. Cada curso possui uma carga horria que distribuda em disciplinas com ciclos semestrais, tambm possui um professor coordenador. As disciplinas so especficas para cada curso, mesmo que disciplinas com mesmo nome faam parte da grade de vrios cursos ela dever possuir cdigos diferentes, isso se faz necessrio, pois para cada curso a disciplina visa atender um objetivo na formao das competncias a serem desenvolvidas, tendo por isso, objetivos especficos diferenciados para cada curso. Toda disciplina possui uma carga horria, a soma das cargas horrias de uma disciplina dever ser compatvel com a carga horria do curso, o cdigo da disciplina dever ser composto pelo cdigo do curso e um identificador para a disciplina. Cada professor poder ensinar diferentes disciplinas. Cada turma dever possuir um conjunto de alunos, um conjunto de disciplinas compatvel com o semestre da grade daquela turma, um professor para cada disciplina e as informaes de ano e semestre letivos. O cdigo identificador da turma dever ser composto pelo contedo dos campos: ano letivo, que representa o ano corrente, o semestre letivo que dever identificar o se 1. semestre ou 2. semestre do ano, cdigo do curso, semestre da grade de disciplinas que dever ser atribuda turma e o identificador da turma. Os funcionrios da Instituio dividem-se em duas categorias: professores e administrativos. Para os professores necessrio o armazenamento de sua titulao, especialmente para fins de pagamento, uma vez que existe uma tabela para pagamentos que varia de acordo com a titulao do professor, o professor remunerado em funo da quantidade de aulas que leciona. J para os funcionrios administrativos importante que se conhea o cargo e salrio, tambm existe um plano de carreira para os funcionrios administrativos que prev os cargos, salrios e benefcios para cada funo.
01. Identifique as possveis entidades apresentadas no cenrio da Instituio de Ensino Aprendendo a Aprender.
02. Identifique os possveis atributos para cada entidade.
03. Qualifique os atributos definindo: Nome, tipo de dado a ser armazenado, tamanho do dado e restries.
79
IBTA 2563
R:
ALUNO
registro de aluno: numrico com 5 posies, chave primria nome: alfanumrico com 30 posies, preenchimento obrigatrio email: alfanumrico com 20 posies data de nascimento: data
FUNCIONARIO
cdigo de funcionrio: numrico com 5 posies,chave primria nome: alfanumrico com 20 posies e preenchimento obrigatrio email: alfanumrico com 20 posies data de nascimento: data dt_admissao: date tipo: numrico com 1 posio, o contedo do campo poder ser 1 ou 2
PROFESSOR
cdigo de professor: numrico com 5 posies, chave primria, estabelece o relacionamento com a tabela FUNIONARIO titulao: alfanumrico com 15 posies
ADMINISTRATIVO
cdigo de funcionrio: : numrico com 5 posies, chave primria, estabelece o relacionamento com a tabela FUNIONARIO cargo: alfanumrico com 15 posies salrio: numrico real com 2 casas decimais
CURSO
cdigo do curso: numrico com 5 posies, chave primria nome: alfanumrico com 30 posies, contedo exclusivo carga horria: numrico com 4 posies parecer de aprovao: alfanumrico com 6 posies, contedo exclusivo coordenador: numrico com 5 posies, campo de ligao com o PROFESSOR DISCIPLINA cdigo da disciplina: campo numrico com 12 posies, chave primria nome: campo numrico com 30 posies, preenchimento obrigatrio carga horria da disciplina: numrico com 3 posies cdigo do curso: numrico com 5 posies, este campo estabelece relacionamento com a tabela CURSO
80
IBTA 2563
TURMA
ano letivo: numrico com 4 posies semestre letivo: numrico com 1 posio cdigo do curso: numrico com 5 posies, este campo estabelece relacionamento com a tabela CURSO semestre da grade: numrico com 5 posies cdigo da turma: numrico com 12 posies, chave primria
81
IBTA 2563
Exerccio 3 Identificao de Relacionamentos

Instrues: Este exerccio continuidade do exerccio 3
Caso: Instituio de Ensino "Aprendendo a Aprender"
Estamos no ano de 2004, a Instituio de Ensino "Aprendendo a Aprender" estar completando no prximo ano 35 anos de atuao, ao longo de sua existncia preserva a preocupao com a qualidade, no s nos seus servios prestados, mas principalmente no ser humano. Atualmente conta com 10.000 alunos, gradativamente deixou de oferecer cursos tcnicos e substituindo-os por cursos de Tecnologia, conta atualmente com 8 cursos de tecnologia, dentre eles Bancos de Dados, Redes de Computadores, Sistemas de Informao e Sistemas Web. Possui 500 funcionrios, sendo que, 300 so professores e 200 funcionrios administrativos. Os seus cursos continuam sendo oferecidos nos perodos matutino, vespertino e noturno. Cada curso possui uma carga horria que distribuda em disciplinas com ciclos semestrais, tambm possui um professor coordenador. As disciplinas so especficas para cada curso, mesmo que disciplinas com mesmo nome faam parte da grade de vrios cursos ela dever possuir cdigos diferentes, isso se faz necessrio, pois para cada curso a disciplina visa atender um objetivo na formao das competncias a serem desenvolvidas, tendo por isso, objetivos especficos diferenciados para cada curso. Toda disciplina possui uma carga horria, a soma das cargas horrias de uma disciplina dever ser compatvel com a carga horria do curso, o cdigo da disciplina dever ser composto pelo cdigo do curso e um identificador para a disciplina. Cada professor poder ensinar diferentes disciplinas. Cada turma dever possuir um conjunto de alunos, um conjunto de disciplinas compatvel com o semestre da grade daquela turma, um professor para cada disciplina e as informaes de ano e semestre letivos. O cdigo identificador da turma dever ser composto pelo contedo dos campos: ano letivo, que representa o ano corrente, o semestre letivo que dever identificar o se 1. semestre ou 2. semestre do ano, cdigo do curso, semestre da grade de disciplinas que dever ser atribuda turma e o identificador da turma. Os funcionrios da Instituio dividem-se em duas categorias: professores e administrativos. Para os professores necessrio o armazenamento de sua titulao, especialmente para fins de pagamento, uma vez que existe uma tabela para pagamentos que varia de acordo com a titulao do professor, o professor remunerado em funo da quantidade de aulas que leciona. J para os funcionrios administrativos importante que se conhea o cargo e salrio, tambm existe um plano de carreira para os funcionrios administrativos que prev os cargos, salrios e benefcios para cada funo.
01. Identifique os relacionamentos existentes entre as entidades apresentadas nos exerccios 2 e 3. R: Cada ALUNO deve ser alocado em uma e somente uma TURMA. Uma TURMA pode conter um ou muitos alunos. As TURMAS assistem a muitas DISCIPLNAS As DISCIPLINAS so assistidas por muita TURMAS Uma DISCIPLINA pode ser lecionada por um ou muitos PROFESSORES.
82
IBTA 2563
Um PROFESSOR pode ministrar uma ou muitas DISCIPLINAS Uma DISCIPLINA compe um ou muitos CURSOS. UM CURSO composto por muitas DISCIPLINAS. Um PROFESSOR coordena um CURSO Um CURSO coordenado por um PROFESSOR. Um funcionrio pode ser ADMINISTRATIVO ou PROFESSOR.
02. Proponha um MER para o cenrio apresentado utilizando a metodologia de Peter Chen. R: Obs.: Neste ponto da matria especializao ainda no foi abordado, mas est sendo ilustrado na soluo.
Aluno 1:N
Funcionrio
1:N alocado em Professor 1:1 1:1 Turma 1:N Coordena Assiste Leciona Administrativo
N:M Disciplina 1:N 1:N
0:1 Curso 1:1
Compe
83
IBTA 2563
Exerccio 4 Estudo de Caso Biblioteca

Considere a situao: Seu grupo foi contratado para implementao de um banco de dados para a biblioteca da Instituio de Ensino Aprendendo a Aprender. Para isso, vocs devero realizar as seguintes tarefas:
01. Realize o levantamento de dados para identificao das necessidades do cliente e descreva o cenrio encontrado. R: A instituio de Ensino Aprendendo a Aprender possui um acervo composto por livros, revistas, artigos, peridicos, entre outros, todos so denominados como obras. Atualmente a catalogao das obras realizada manualmente, isto , os dados das obras so armazenados em fichas de papel e disponibilizadas em 2 arquivos, um organizado por ordem alfabtica de autor e outro por ordem alfabtica de ttulo. Estas fichas contm os seguintes dados das obras: Cdigo da Obra, Tipo da Obra (revista, livro, etc), nome do autor, cdigo do autor, ano de edio, nome da editora, cdigo da editora, classificao da obra (Informtica, infantil, literatura, etc.) Todos os usurios da biblioteca podem consultar as obras disponveis no acervo, mas somente podem pegar livros emprestados os usurios cadastrados. Para realizao do cadastro o usurio deve preencher uma ficha de cadastro e apresentar o seu documento de identificao. A ficha de cadastro preenchida manualmente e contm os seguintes dados: Identificao do usurio, tipo de usurio (aluno, professor ou funcionrio), data de nascimento, telefone, endereo, email e para menores de 18 anos dados do responsvel: nome, identidade, telefone e endereo. Quando um usurio pega um livro emprestado, a ficha do livro retirada do acervo e anexada ficha do aluno e a ficha que a atendente preenche informando cdigo do livro, cdigo do usurio, data de retirada e data de entrega e este conjunto arquivado em uma pasta organizada por data de entrega. Os usurios podem retirar qualquer tipo de obra por um prazo mximo de 10 dias. A quantidade de obras que cada usurio pode retirar de 3 obras. Para cada exemplar de uma obra preenchida uma ficha de catalogao, desta maneira se existirem 10 exemplares de um determinado livro sero preenchidas 10 fichas. Com o aumento de obras do acervo e tambm de usurios este controle est invivel, pois os atendentes precisam registrar:
Novas obras Novos usurios Emitir relatrios de utilizao de livros Emitir a listagem dos usurios em atraso e cobrar multa
a multa de 3 dias de suspenso do direito de retirada de livros para cada dia de atraso
controlar os emprstimos.
O objetivo da instituio que os processos da biblioteca sejam automatizados.
84
IBTA 2563
02. Identifique as entidades e atributos. R: Usurio: ID, Nome, DT_nascimento, Email, Endereco, Telefone, Responsvel, RG_Responsavel, Endereco_responsavel, Fone_responsavel Obra: ID, Tipo, Nome, DT_edio, Nome_editora, Cdigo_Editora, Nome_autor, Codigo_Autor, Classificao Emprstimo: ID_Usurio, ID_obra, DT_retirada, DT_devoluo
03. Identifique os relacionamentos entre as entidades. R: Um usurio pode retirar at 3 obras por perodo; Cada obra s pode ser retirada por um usurio de cada vez; Quando um usurio retira uma obra da biblioteca uma ficha de emprstimo preenchida.
04. Desenvolva o MER conceitual.
05. Desenvolva o MER lgico.
06. Desenvolva o MER fsico.
Resposta das questes 4, 5 e 6:

Usurio id cod_usuario (FK) cod_obra (FK) nome email endereo fone responsavel id_responsavel fone_responsavel email_responsavel Obra ID_obra cod_usuario (FK) cod_obra (FK) id (FK) tipo edicao id_editora nome_obra nome_editora id_autor nome_autor classificacao
Emprstimo Cod_usuario cod_obra data_emprestimo data_retirada
85
IBTA 2563
Usurio
id: VARCHAR2(20) cod_usuario: INTEGER cod_obra: INTEGER nome: VARCHAR2(20) email: CHAR(18) endereo: VARCHAR2(20) fone: VARCHAR2(20) responsavel: VARCHAR2(20) id_responsavel: VARCHAR2(20) fone_responsavel: VARCHAR2(20) email_responsavel: CHAR(18)
Obra
ID_obra: CHAR(18) cod_usuario: INTEGER cod_obra: INTEGER id: VARCHAR2(20) tipo: VARCHAR2(20) edicao: INTEGER id_editora: INTEGER nome_obra: VARCHAR2(20) nome_editora: VARCHAR2(20) id_autor: INTEGER nome_autor: VARCHAR2(20) classificacao: VARCHAR2(20)
Emprstimo
cod_usuario: INTEGER cod_obra: INTEGER data_emprestimo: DATE data_retirada: DATE
86
IBTA 2563
Exerccio 5 Normalizao do Exerccio 4

Instrues: Este exerccio d continuidade ao exerccio 4
Considere o modelo desenvolvido no exerccio 4, aplique as regras de normalizao e:
01. Identifique as entidades e atributos para cada grupo;
02. Construa um MER - lgico R:

Usurio id nome email endereo fone data_nascimento id_responsavel (FK) Responsvel id_responsavel nome_responsavel fone_responsavel email_responsavel endereo_responsavel
Editora id_editora nome_editora
Emprstimo
cod_usurio cod_obra id (FK) id_editora (FK) data_emprestimo data_retirada
Obra ID_obra id_editora (FK) tipo edicao nome_obra classificacao id_autor
Autor x Obra cod_autor cod_obra ID_obra (FK) id_autor (FK) id_editora (FK) Autor id_autor nome_autor
87
IBTA 2563
Exerccio 6 Terico e Prtico Caso da Nota Fistal

Considere as seguintes entidades e dados sobre o problema:
Cliente Nome CPF RG End Fone Nascimento
Produto Codigo Descrio Valor
Nota Fiscal Numero Cliente Nome vendedor Cdigo vendedor Produto Valor total Data Entrega
Venda Vendedor Valor Comisso Data Tipo
Dados sobre o problema:
O cliente ao efetuar uma compra tem seus dados pessoais cadastrados. Existe a necessidade de se verificar a forma de pagamento, que pode ser a vista ou a prazo e em ambos os casos existe a possibilidade de faze-lo com cheque, dinheiro ou carto de crdito O produto pode ser retirado pelo cliente ou entregue em um endereo que pode ou no ser o seu endereo pessoal A venda gera um pagamento de comisso ao vendedor, o percentual de venda de 2% do valor da compra Os produtos ficam armazenados em um estoque. O vendedor antes de efetuar uma venda consulta o estoque Toda venda gera uma nota fiscal que deve conter os dados do vendedor, do cliente, da entrega, dos produtos, data e nmero da nf, valor total de cada produto, valor total geral Todo vendedor possui um gerente, que tambm deve ser cadastrado como sendo um funcionrio. Com base nestas informaes, verifique se as tabelas indicadas so suficientes para o armazenamento dos dados necessrios a construo de uma base de dados que permita o funcionamento adequado de uma loja de eletrodomsticos e:
88
IBTA 2563
Modelo do Banco
1. Construa um modelo lgico 2. Aplique as regras de normalizao 3. Justifique as tabelas criadas ou desmembradas. 4. Construa um modelo Fsico. R: Soluo apresentada pelos alunos Alexandre Bevilacqua Pacheco e Ricardo de Moraes Peretto ( turma 3Bd2 2s2003) Foi utilizada a ferramenta Erwin para modelagem e gerao dos scripts de criao das tabelas
89
90
Produto_estocado ID_PRODUTO_ESTOCADO: number(5) Gerente ID_GERENTE: number(5) VALOR_UNITRIO: number(10,2) QUANTIDADE: number(10) DESCRIO: varchar2(40) Itens_nf ID_NFISCAL: number(5) ID_PRODUTO_ESTOCADO: number(5) Fone_cliente VALOR_UNITRIO: number(5,2) QTDE: number(5) DDD: number(3) NUMERO: number(15) ID_CLIENTE: number(5) Cliente ID_CLIENTE: number(5) Forma_pgto ID_FORMA_PGTO: number(5) DESCRICAO: varchar2(20) CPF: number(9) CPF_CONTROLE: number(2) RG: varchar2(15) END: varchar2(50) DT_NASC: date NOME: varchar2(40)
Funcionrio
ID_FUNCIONRIO: number(5)
DT_ADMISSAO: date NOME: varchar2(40)
Vendedor
ID_VENDEDOR: number(5)
COMISSO: number(3) ID_GERENTE: number(5)
Nfiscal
ID_NFISCAL: number(5)
ID_CLIENTE: number(5) ID_FORMA_PGTO: number(5) ID_TIPO_PGTO: number(5) DT: date END_ENTREGA: varchar2(50) ID_VENDEDOR: number(5)
Tipo_pgto
ID_TIPO_PGTO: number(5)
DESCRICAO: varchar2(20)
IBTA 2563
IBTA 2563
______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________
91
IBTA 2563
______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________
92
IBTA 2563
______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________
93
IBTA 2563
______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________
94
IBTA 2563
______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________
95
IBTA 2563
______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________ ______________________________________________________________________________
96
IBTA 2756
BD Modelagem de Banco de Dados Semestre III Nome: Professor: Turma: Data:
Prtica 1 Ambientao com o Erwin

Nesta primeira prtica o Professor dever abrir a ferramenta e navegar pelos menus e opes explicando as principais funcionalidades.
Figura 1
Exemplo: Definindo entidades e atributos:
1) Na Erwin Toolbox selecione o cone Entidade:
Figura 2
IBTA 2756
2) Clique com o boto direito do mouse e selecione a opo Attibutes:
Figura 3 - Identificao de Atributos
3) Ser exibida a caixa de dilogo a baixo:

Lista de entidades
Figura 4 - Identificao de Atributos
Para definir os atributos da Entidade: Na caixa de dilogo Attributes:
Selecione a entidade na lista de entidades - ENTITY Selecione a opo NEW

Na caixa New Attribute:
Selecione a forma de exibio dos atributos Hierachically ou Alphabetically O cone para representao do atributo, se ele pertencer a famlia string, number etc. Especifique o Nome do atributo Attribute Name Selecione OK.
Repita o processo para todos os atributos e a seguir selecione OK da caixa ENTITY.

IBTA 2757
Prtica 2 Representao de Entidades e Atributos Instrues: Esta prtica baseada no Exerccio 3 Identificao de Entidades e Atributos, cujo cenrio apresentado a seguir. Caso: Instituio de Ensino Aprendendo a Aprender
Estamos no ano de 2004, a Instituio de Ensino Aprendendo a Aprender estar completando no prximo ano 35 anos de atuao, ao longo de sua existncia preserva a preocupao com a qualidade, no s nos seus servios prestados, mas principalmente no ser humano. Atualmente conta com 10.000 alunos, gradativamente deixou de oferecer cursos tcnicos e substituindo-os por cursos de Tecnologia, conta atualmente com 8 cursos de tecnologia, dentre eles Bancos de Dados, Redes de Computadores, Sistemas de Informao e Sistemas Web. Possui 500 funcionrios, sendo que, 300 so professores e 200 funcionrios administrativos. Os seus cursos continuam sendo oferecidos nos perodos matutino, vespertino e noturno. Cada curso possui uma carga horria que distribuda em disciplinas com ciclos semestrais, tambm possui um professor coordenador. As disciplinas so especficas para cada curso, mesmo que disciplinas com mesmo nome faam parte da grade de vrios cursos ela dever possuir cdigos diferentes, isso se faz necessrio, pois para cada curso a disciplina visa atender um objetivo na formao das competncias a serem desenvolvidas, tendo por isso, objetivos especficos diferenciados para cada curso. Toda disciplina possui uma carga horria, a soma das cargas horrias de uma disciplina dever ser compatvel com a carga horria do curso, o cdigo da disciplina dever ser composto pelo cdigo do curso e um identificador para a disciplina. Cada professor poder ensinar diferentes disciplinas. Cada turma dever possuir um conjunto de alunos, um conjunto de disciplinas compatvel com o semestre da grade daquela turma, um professor para cada disciplina e as informaes de ano e semestre letivos. O cdigo identificador da turma dever ser composto pelo contedo dos campos: ano letivo, que representa o ano corrente, o semestre letivo que dever identificar o se 1o. semestre ou 2o. semestre do ano, cdigo do curso, semestre da grade de disciplinas que dever ser atribuda turma e o identificador da turma. Os funcionrios da Instituio dividem-se em duas categorias: professores e administrativos. Para os professores necessrio o armazenamento de sua titulao, especialmente para fins de pagamento, uma vez que existe uma tabela para pagamentos que varia de acordo com a titulao do professor, o professor remunerado em funo da quantidade de aulas que leciona. J para os funcionrios administrativos importante que se conhea o cargo e salrio, tambm existe um plano de carreira para os funcionrios administrativos que prev os cargos, salrios e benefcios para cada funo. 1) Abra o erwin e salve o seu arquivo com o nome PRATICA2 2) Represente as entidades e atributos identificados no cenrio apresentado. 3) Salve o seu arquivo.
IBTA 2757
R:
ALUNO registro Nome_Aluno email data_nascimento FUNCIONARIO codigo Nome email data_admissao tipo data_nascimento CURSO codigo_curso nome carga_horaria coordenador
TURMA PROFESSOR ano_letivo semestre codigo_curso codigo da turma ADMINISTRATIVO codigo cargo salario codigo titulacao
DISCIPLINA codigo_disciplina nome carga_horaria codigo_curso
IBTA 2758
Prtica 3 Representao de Entidades e Atributos Instrues: Esta prtica baseada no Exerccio 3 Identificao de Entidades e Atributos e d continuidade a prtica 2
1) 2) 3) 4) Abra o arquivo PRTICA 2 e salve-o com o nome PRATICA3 Identifique as chaves primria e estrangeira de cada entidade Estabelea os relacionamentos entre as entidades. Salve o seu arquivo.
Obs.: Modelo no normalizado
IBTA 2758
R:
ALUNO registro codigo da turma (FK) Nome_Aluno email data_nascimento codigo_turma TURMA codigo da turma ano_letivo semestre codigo_curso
DISCIPLINA codigo_disciplina codigo_curso (FK) codigo (FK) nome carga_horaria P
PROFESSOR codigo titulacao Z
CURSO codigo_curso codigo (FK) nome carga_horaria coordenador
Z FUNCIONARIO codigo (FK) Nome email data_admissao tipo data_nascimento ADMINISTRATIVO codigo (FK) cargo salario Z
IBTA 2759
Prtica 4 Modelo Fsico Instrues: Esta prtica baseada no Exerccio 3 Identificao de Entidades e Atributos e d continuidade a prtica 3
1) Abra o arquivo PRTICA 3 e salve-o com o nome PRATICA4 2) Gere o modelo Fsico. 3) Salve o seu arquivo. Obs.: Modelo no normalizado
IBTA 2759
R:
ALUNO codigo_da_turma: INTEGER Nome_Aluno: VARCHAR(20) email: DATE data_nascimento: DATE codigo_turma: CHAR(18) TURMA codigo_da_turma: INTEGER ano_letivo: INTEGER semestre: INTEGER codigo_curso: INTEGER
DISCIPLINA codigo_disciplina: CHAR(18) codigo_curso: INTEGER codigo: INTEGER nome: VARCHAR(20) carga_horaria: INTEGER
PROFESSOR codigo: INTEGER titulacao: VARCHAR(20)
CURSO codigo_curso: INTEGER codigo: INTEGER nome: VARCHAR(20) carga_horaria: INTEGER coordenador: INTEGER
FUNCIONARIO codigo: INTEGER Nome: CHAR(18) email: VARCHAR(20) data_admissao: DATE tipo: INTEGER data_nascimento: DATE
ADMINISTRATIVO codigo: INTEGER cargo: VARCHAR(20) salario: CHAR(18)
IBTA 2760
BD Modelagem de Banco de Dados Semestre III Nome: Professor: Turma: Data:
Prtica 5 Estudo de Caso - Biblioteca
Obs: Se voc j resolveu o Exerccio terico e prtico 5, utilize os dados anotados seno faa agora a conforme o procedimento abaixo.
Considere a situao: Seu grupo foi contratado para implementao de um banco de dados para a biblioteca da Instituio de Ensino Aprendendo a Aprender. Para isso, vocs devero realizar as seguintes tarefas:
1. Realize o levantamento de dados para identificao das necessidades do cliente e descreva o cenrio encontrado. 2. Identifique as entidades e atributos. 3. Identifique os relacionamentos entre as entidades. 4. Desenvolva o MER conceitual 5. Desenvolva o MER lgico 6. Desenvolva o MER fsico.
IBTA 2761
Prtica 6 Ambientao com o SQL

Instrues: Siga o roteiro apresentado a seguir, execute-o passo a passo. Objetivos: Conhecer o ambiente de trabalho do SQL; Conhecer os passos requeridos para inicializao do Oracle nos laboratrios do IBTA; Preparar o ambiente de trabalho;
Roteiro: 1) Para realizao do login no sistema operacional utilizar: Usurio: Oracle Senha: Oracle
2) Para iniciar o servio Oracle: a. Nos laboratrios de informtica do IBTA voc encontrar o cone de servio na barra de tarefas do Windows. Para acessa-la sem o atalho utilize as opes de menu: Iniciar Configuraes Painel de Controle Ferramentas Administrativas Servios b. Selecione a opo: OracleServiceNomeDoBanco, OracleServiceDB3BD1 no nosso caso
c. Inicie o Servio, para isso, clique com o boto direito do mouse e selecione a opo Iniciar/Start ou na barra de ferramentas selecione o cone .
IBTA 2761
3) Para acessar o SQL: a. Nos laboratrios de informtica do IBTA voc encontrar o cone do SQL Plus na barra de tarefas do Windows.
Para acessa-lo sem o atalho selecione as opes de Menu: Iniciar Programas Oracle OraHome92 Application Development SQL Plus b. Para realizar o login no ambiente do SQLPlus, temos as seguintes opes de usurio/Senha: Usurio Senha Privilgios Scott Tiger usurio HR HR usurio SYS Oracle1 administrador Para esta atividade iremos realizar o login como administrador do Banco, pois iremos preparar o ambiente de trabalho, para isso digite: Nome do Usurio: SYS Senha: ORACLE String de Host: DB3BD1 as SYSDBA 4) Agora vamos criar o usurio SCOTT, para isso, no prompt do SQL Plus: @ C:\oracle\ora92\rdbms\admin\SCOTT.SQL 5) Realize a conexo com o usurio SCOTT. Para isso, no prompt do SQL: a. Digite EXIT, voc estar fechando a sesso do usurio SYS b. Selecione o cone do SQLPlus
1
Esta a senha default utilizada nos laboratrios do IBTA, a senha de instalao CHANGE_ON_INSTALL
IBTA 2761
c. Na caixa de dilogo Logon digite: Nome do Usurio: SCOTT Senha: TIGER String de Host: DB3BD1 6) Vamos verificar quais so as tabelas pertencentes ao esquema do SCOTT: Select object_name from user_objects where object_type = TABLE; O comando acima ir retornar o nome dos objetos do usurio destes objetos (Scott) quando o tipo de objeto for Tabela. 7) Vamos verificar a estrutura de cada uma das tabelas do SCOTT: Describe EMP Desc DEPT Desc SALGRADE Desc BONUS Exerccio: Agora vamos realizar os mesmos procedimentos para criao do usurio HR. 1) Relaize a conexo com o usurio administrador R: Conn Sys/Oracle@DB3BD1 as SYSDBA 2) Localize e rode o script do usurio hr, nome do arquivo HR_MAIN.SQL R: @ C:\oracle\ora92\demo\schema\human_resources\HR_MAIN.SQL O comando Describe ou simplesmente Desc listra a estrutura da Tabela: Nome da Coluna Se a coluna aceita nulos ou no Tipo de dado/Comprimento da coluna O comando Select utilizado para realizao de consultas sua sintaxe : Select lista_colunas From nome_tabela Where condio;
IBTA 2761
OBSERVAO: Sero solicitados os parmetros abaixo, informe conforme a indicao: specify password for HR as parameter 1: Informe o valor para 1: HR specify default tablespeace for HR as parameter 2: Informe o valor para 2: USER specify temporary tablespace for HR as parameter 3: Informe o valor para 3: TEMP specify password for SYS as parameter 4: Informe o valor para 4: ORACLE specify log path as parameter 5: Informe o valor para 5: C: 3) Realize a conexo com o usurio HR R: CONN HR/HR@DB3BD1 4) R: Liste os objetos Tabela do usurio HR.
Select object_name from user_objects where object_type = TABLE;
5) Verifique a estrutura das tabelas do usurio HR. R: DESC EMPLOYEES DESC DEPARTMENT ...
IBTA 2762
Prtica 7 Consultas Bsicas e com o uso de Operadores

1. H quatro erros de codificao nesta instruo. Voc pode identific-los? SQL> SELECT empno, ename 2 salary x 12 ANNUAL SALARY 3 FROM emp; R: A tabela EMP no contm uma coluna chamada salary. A coluna chamada sal. O operador de multiplicao *, no x, como mostrado na linha 2. O apelido ANNUAL SALARY no pode incluir espaos. O apelido deve ser ANNUAL_SALARY ou estar entre aspas duplas. Falta uma vrgula aps a coluna ENAME.
2. Crie uma consulta para exibir os cargos exclusivos a partir da tabela EMP. R: SQL> SELECT DISTINCT job 2 FROM emp; 3. Crie uma consulta para exibir o nome e o salrio dos funcionrios que recebem mais de US$2.850. R: SQL> SELECT ename, sal 2 FROM emp 3 WHERE sal > 2850; 4. Crie uma consulta para exibir o nome do funcionrio e o nmero do departamento relativos ao nmero de funcionrio 7566. R: SQL> SELECT ename, deptno 2 FROM emp 3 WHERE empno = 7566; 5. Exiba o nome do funcionrio, o cargo e a data de admisso dos funcionrios admitidos entre 20 de fevereiro de 1981 e 1 de maio de 1981. Ordene a consulta de modo crescente pela data inicial. R: SQL> SELECT ename, job, hiredate 2 FROM emp
IBTA 2762
3 4 5 6
WHERE hiredate BETWEEN TO_DATE('20-Feb-1981','DD-MON-YYYY') AND TO_DATE('01-May-1981','DD-MON-YYYY') ORDER BY hiredate;
6. Exiba o nome do funcionrio e o nmero do departamento de todos os funcionrios dos departamentos 10 e 30 em ordem alfabtica de nome. R: SQL> SELECT ename, deptno 2 FROM emp 3 WHERE deptno IN (10, 30) 4 ORDER BY ename; 7. Exiba o nome e a data de admisso de todos os funcionrios admitidos em 1982. R: SQL> SELECT ename, hiredate 2 FROM emp 3 WHERE hiredate LIKE '%82'; 8. Exiba o nome e o cargo de todos os funcionrios sem um gerente. R: SQL> SELECT ename, job 2 FROM emp 3 WHERE mgr IS NULL; 9. Exiba o nome, o salrio e a comisso de todos os funcionrios que recebem comisso. Classifique os dados em ordem decrescente de salrio e comisso. R: SQL> SELECT ename, sal, comm 2 FROM emp 3 WHERE comm IS NOT NULL 4 ORDER BY sal DESC, comm DESC; 10. Exiba os nomes de todos os funcionrios cuja terceira letra do nome seja A. Observao: H dois sublinhados (_) antes de A na clusula WHERE. R: SQL> SELECT ename 2 FROM emp 3 WHERE ename LIKE '__A%';
IBTA 2762
11. Exiba os nomes de todos os funcionrios cujo nome tem duas letras L no departamento 30 ou cujo gerente seja 7782. R: SQL> SELECT ename 2 FROM emp 3 WHERE ename LIKE '%L%L%' 4 AND deptno = 30 5 OR mgr = 7782; 12. Crie uma consulta para exibir o nome, o nmero do departamento e o nome do departamento de todos os funcionrios. R: SQL> SELECT e.ename, e.deptno, d.dname 2 FROM emp e, dept d 3 WHERE e.deptno = d.deptno; 13. Crie uma lista nica de todos os cargos existentes no departamento 30. Inclua a localizao do departamento 30 na sada. R: SQL> SELECT DISTINCT e.job, d.loc 2 FROM emp e, dept d 3 WHERE e.deptno = d.deptno 4 AND e.deptno = 30; 14. Crie uma consulta para exibir o nome do funcionrio, o nome do departamento e a localizao de todos os funcionrios que recebem comisso. R: SQL> SELECT e.ename, d.dname, d.loc 2 FROM emp e, dept d 3 WHERE e.deptno = d.deptno 4 AND e.comm IS NOT NULL; 15. Exiba o nome do funcionrio e o nome do departamento de todos os funcionrios que tm A no nome. R: SQL> SELECT e.ename, d.dname 2 FROM emp e, dept d 3 WHERE e.deptno = d.deptno 4 AND e.ename LIKE '%A%';
IBTA 2762
16. Crie uma consulta para exibir o nome, o cargo, o nmero do departamento e o nome do departamento de todos os funcionrios que trabalham em DALLAS. R: SQL> SELECT e.ename, e.job, e.deptno, d.dname 2 FROM emp e, dept d 3 WHERE e.deptno = d.deptno 4 AND d.loc = 'DALLAS'; 17. Crie uma consulta que exibir o nome do funcionrio, o nmero do departamento e todos os funcionrios que trabalham no mesmo departamento que um determinado funcionrio. Fornea a cada coluna um label apropriado. R: SQL> SELECT e.deptno department, e.ename employee, 2 c.ename colleague 3 FROM emp e, emp c 4 WHERE e.deptno = c.deptno 5 AND e.empno <> c.empno 6 ORDER BY e.deptno, e.ename, c.ename; SELECT e.ename "Employee", e.empno "Emp#", m.ename "Manager", m.empno "Mgr#" FROM emp e, emp m WHERE e.mgr = m.empno(+) SQL> SELECT e.ename "Employee", e.empno "Emp#", 2 m.ename "Manager", m.empno "Mgr#" 3 FROM emp e, emp m 4 WHERE e.mgr = m.empno; 18. Crie uma consulta para exibir o nome e a data de admisso de qualquer funcionrio admitido aps o funcionrio Blake. R: SQL> SELECT emp.ename, emp.hiredate 2 FROM emp, emp blake 3 WHERE blake.ename = 'BLAKE' 4 AND blake.hiredate < emp.hiredate;
IBTA 2762
19. Exiba os nomes e as datas de admisso de todos os funcionrios junto com o nome do gerente e a data de admisso de todos os funcionrios admitidos antes dos respectivos gerentes. Coloque um label nas colunas Employee, Emp Hiredate, Manager e Mgr Hiredate, respectivamente. R: SQL> SELECT e.ename "Employee", e.hiredate "Emp Hiredate", 2 m.ename "Manager", m.hiredate "Mgr Hiredate" 3 FROM emp e, emp m 4 WHERE e.mgr = m.empno 5 AND e.hiredate < m.hiredate;
IBTA 2763
Prtica 8- Exerccios envolvendo Consultas com Join
Lembrete: Inicie o servio do Oracle Instrues:

Estabelea conexo com o usurio SCOTT. Utilize as tabelas do usurio Scott.
1) Exiba o nome dos funcionrios e o nome dos departamentos em que trabalham. R: Select ename, dname from emp, dept where dept.deptno = emp.deptno; 2) Exiba o nome do departamento e a sua localizao para todos os departamentos que possuem funcionrios com o cargo de CLERK R: Select dname, loc from deptno, emp where emp.deptno = dept.deptno and emp.job = CLERK; 3) Exiba o nome de todos os funcionrios que atuam nos departamentos localizados em NEW YORK R: Select ename from emp, dept where dept.deptno = emp.deptno and dept.loc = NEW YORK; 4) Exiba a localizao dos departamentos que possuem salrios superiores a 1500. R: Select dept.loc from dept, emp where dept.deptno = emp.deptno and emp.sal > 1500; 5) Exiba o nome e o nmero de dias inteiros trabalhados por cada um dos funcionrios do departamento 30. R: Select ename, round(sysdate hiredate,0) dias_trabalhados from emp, deptno where dept.deptno = emp.deptno and emp.deptno = 30; 6) Exiba o nome do funcionrio e o nome do seu gerente sob os apelidos Funcionrio e Gerente respectivamente. R: Select func.ename, gerente.ename From emp func, emp gerente Where func.mgr = gerente.empno; 7) Crie uma consulta para exibir o nome, cargo, salario, data de admisso da tabela de funcionrios e relacione com a tabela de departamento exibindo tambm os campos Nome do departamento e Localizao R: SELECT A.ENAME, A.JOB, A.SAL, A.HIREDATE, B.DNAME, B.LOC
IBTA 2763
FROM EMP A, DEPT B WHERE A.DEPTNO = B.DEPTNO;
IBTA 2764
Prtica 9 Exerccios envolvendo Consultas com funes de linha

1) Exibir nomes (ename) e cargos (job) dos funcionrios sob a identificao nomes e cargos respectivamente. R: Select ename nomes, job cargos from emp; 2) Exibir o nome de todos os funcionrios que trabalham no departamento 30 R: Select ename from emp where deptno = 30; 3) Exiba o nome de todos os funcionrios com cargo de analista (ANALYST) R: Select ename from emp where job = ANALYST; 4) Exiba o nome de todos os funcionrios que trabalham nos departamentos 10 ou 30 R: SElect ename from emp where deptno = 10 or deptno = 30; 5) Exiba o nome de todos os funcionrios que trabalham no departamento 10 com salrio maior ou igual a 500 R: Select ename from emp where deptno = 10 and sal >= 500; 6) Exiba em ordem crescente o nome de todos os funcionrios: a) em letras maisculas R: Select upper(ename) from emp order by ename; b) Com a primeira letra de cada palavra em minsculas R: Select initicap(ename) from emp order by ename; c) Com todas as letras minsculas R: Select lower(ename) from emp order by ename;
IBTA 2764
7) Escreva consultas que retornem o resultado das seguintes operaes: a) Exiba o resto da diviso de 151 por 8 R: Select mod(151,8) resto_divisao from dual; b) Exiba o resultado da diviso de 151 por 8 com 2 casas decimais R: Select round(151/8,2) diviso from dual; c) Exiba o resultado da diviso de 151 por 8 truncado e sem nenhuma casa decimal. R: Select trunc(151/8,0) from dual; Obs.: Utilize a tabela DUAL. 8) Exiba o nome do funcionrio e o resultado da operao indicada de acordo com as condies abaixo sob o apelido bnus: Se o cargo do funcionrio for CLERk o bnus do salrio dever ser de 15% Se o cargo do funcionrio for ANALYST o bnus do salrio dever ser de 20% Para os demais cargos no o valor do bnus 0. Utilize a funo Decode. R: Select ename, decode (job, CLERK, sal * 0.15, ANALYST, sal * 0.20, 0) as BONUS From emp; 9) Resolva o exerccio 9 utilizando a funo Case. R: select ename, case job when 'CLERK' THEN sal * 0.15 when 'ANALYST' THEN sal * 0.20 else 0 end as BONUS from emp; 10) Exiba o nome dos funcionrios, o salrio sob o apelido salrio e calcule o reajuste de salrio para cada funcionrio de acordo com as condies abaixo, exiba o resultado do clculo sob o apelido Salrio_atualizado. Se salrio <= 500 reajuste de 50% Se salrio > 500 e salrio <= 1000 reajuste de 25% Se salrio > 1000 e salrio <= 5000 reajuste de 12,5% Demais salrios 6%
IBTA 2764
R: Select ename, sal as salario, case WHEN sal <= 500 THEN sal + (sal * 0.5) WHEN sal > 500 and sal <= 1000 THEN sal +(sal *0.25) WHEN sal > 1000 and sal < 5000 THEN sal+(sal *0.125) Else sal+(sal * 0.06) End as Salario_atualizado From EMP; 11) Exiba nome e o valor do salrio adicionado da comisso de cada funcionrio. Utilize a funo NVL. R: Select ename, sal + (nvl(comm,0) from emp; 12) Exiba nome e o valor do salrio adicionado da comisso de cada funcionrio Utilize a funo NVL2. R: Select ename, nvl2(comm,sal + comm, sal) from emp; 13) Exiba o nome de todos os funcionrios cuja primeira letra do nome S. R: Select ename from emp where ename like S%; 14) Exiba o nome e o cargo de todos os funcionrios que foram contratados no ano de 1981 ou 1982; R: Select ename, job from emp where hiredate like %1981 or hiredate like %1982; 15) Exiba o nome de todos os funcionrios que trabalham em um dos departamentos 10, 20 ou 30 e tenham um dos cargos CLERK, SALESMAN R: Select ename from emp where deptno in (10, 20,30) and job in (CLERK, SALESMAN); 16) Exiba o nome e cargo de todos os funcionrios que possuem salrio entre 1000 e 2000 R: Select ename, job from emp where sal between 1000 and 2000; 17) Exiba o nome e o salrio de todos os funcionrios cuja data de contratao foi entre o perodo de 01/05/1981 e 05/10/2005. R: Select ename, sal from emp where hiredate between 01/05/1981 and 02/10/2005;
IBTA 2765
Prtica 10 Exerccios envolvendo Instrues DML

Estabelea conexo com o usurio SCOTT. Utilize as tabelas do usurio Scott. Para saber quais so as tabelas faa a seguinte consulta: Select object_name from user_objects where object_type = TABLE; esta instruo seleciona o nome dos objetos TABELA do usurio corrente, neste caso o Scott. Antes de iniciar as resolues verifique a estrutura das tabelas
1) Insira as linhas a seguir na tabela EMP. Empno 8816 8817 8818 Ename JORGE LUIZA Job Mgr Hiredate Sal Comm 800 deptno 10 20 20
VENDEDOR 7839 ANALISTA 7902 7902
15/08/2002 2500 23/02/2004 3800 15/01/2001 4800
ROBERTO ANALISTA
R: insert into emp(empno, ename, job, mgr, hiredate, sal, comm, deptno) values(8816, 'JORGE', 'VENDEDOR', 7839, '15/08/2002', 2500, 800, 10); insert into emp(empno, ename, job, mgr, hiredate, sal, comm, deptno) values(8817,'LUIZA', 'ANALISTA', 7902, '23/02/2004', 3800, null, 20); insert into emp(empno, ename, job, mgr, hiredate, sal, comm, deptno) values(8818,'ROBERTO', 'ANALISTA', 7902, '15/01/2001', 4800, null, 20) 2) Altere o salrio de todos os funcionrios que possuem cargo de CLERK para 5000,50 R: Update EMP set sal = 5000.50 where job = CLERK; 3) Exclua todos os funcionrios que possuem salrios superiores a 1500,00 R: Delete from EMP where sal > 1500.00;
IBTA 2765
4) Inclua o departamento de cdigo 28 e nome Recursos Humanos, localizado em Cuiab R: Insert into dept(deptno, dename, loc) values (28, Recursos Humanos, Cuiaba); 5) Altere a localizao de todos os departamentos com cdigo > 10 e menor do que 15 para So Paulo. R: Update DEPT set loc = So Paulo where deptno > 10 and deptno < 15; 6) Desfaa as alteraes R: Rollback 8) Altere o nome do departamento da tabela DEPT para DBA, onde a localizao for NEW YORK. Cancele a transao. R: UPDATE DEPT SET DNAME = 'DBA' WHERE LOC = 'NEW YORK'; ROLLBACK; 9) Altere o cargo dos empregados da tabela EMP, onde for ANALYST para DBA. Cancele a transao. R: UPDATE EMP SET JOB = 'DBA' WHERE JOB = 'ANALYST'; ROLLBACK; 11) Delete todos os funcionrios da tabela EMP que ganhem menos que 1500. Cancele a transao. R: DELETE FROM EMP WHERE SAL < 1500; ROLLBACK; 12) Delete todos os departamentos localizados em BOSTON. Cancele a transao. R: DELETE FROM DEPT WHERE LOC = 'BOSTON'; ROLLBACK;
IBTA 2765
13) Altere o nome do funcionrio JOO para JOHN. R: Update EMP Set nome = JOHN WHERE ENAME = JOO; 14) Alter para 3000 o salrio de todos os funcionrios que ganham menos do que 2000. Desfaa a transao. R: Update EMP Set sal = 3000 Where sal < 2000; Rollback; 15) Exclua todos os funcionrios que trabalham no departamento de nmero 20, desfaa a transao. R: Delete from EMP where deptno = 20; Rollback; 16) Selecione os campos (ename, job e sal) da tabela EMP R: SELECT ENAME, JOB, SAL FROM EMP; 17) Selecione o campo ename da tabela EMP e formate a apresentao desta consulta de forma que a sada seja a seguinte: EMPLOYEE KING EMPLOYEE ALAN EMPLOYEE CLARK R: SELECT EMPLOYEE || ENAME FROM EMP;
IBTA 2766
Prtica 11 Instrues DDL Create, Alter e Drop Table

Lembrete: Inicie o servio do Oracle Instrues: Estabelea conexo com o usurio SCOTT. Utilize as tabelas do usurio Scott.
1 Crie uma tabela com o usurio SCOTT com as seguintes caractersticas: Nome da tabela : XXX Campos : CODIGO NUMBER(5), NOME VARCHAR2(50), SALARIO NUMBER(19,2) e SEXO CHAR(1). R: CREATE TABLE XXX (CODIGO NUMBER(5), NOME VARCHAR2(50), SALARIO NUMBER(19,2), SEXO CHAR(1));
2 Inserir 5 linhas quaisquer na tabela previamente criada (XXX) e commitar ao final das inseres. R: INSERT INTO XXX (CODIGO, NOME, SALARIO, SEXO) VALUES (1, ARNALDO, 10000, M); INSERT INTO XXX (CODIGO, NOME, SALARIO, SEXO) VALUES (2, LCIA, 11000, F); INSERT INTO XXX (CODIGO, NOME, SALARIO, SEXO) VALUES (3, GABRIELA, 11000, F); INSERT INTO XXX (CODIGO, NOME, SALARIO, SEXO) VALUES (4, MILTON, 6000, M); INSERT INTO XXX (CODIGO, NOME, SALARIO, SEXO) VALUES (5, RICARDO, 4000, M); INSERT INTO XXX (CODIGO, NOME, SALARIO, SEXO) VALUES (6, JAIME, 4000, M); COMMIT;
IBTA 2766
3 Adicione uma coluna nova na tabela XXX. CARGO VARCHAR2(30) R: ALTER TABLE XXX ADD CARGO VARCHAR2(30); 4 Modifique o tamanho da coluna criada NOME para o tamanho de 30. R: ALTER TABLE XXX MODIFY (NOME VARCHAR2(20)); ERROR at line 2: ORA-01441: column to be modified must be empty to decrease column length O erro acima deve ter acontecido, o que voc dever fazer para alterar o tamanho da coluna? UPDATE XXX SET NOME = NULL; COMMIT; ALTER TABLE XXX MODIFY (NOME VARCHAR2(20)); 5 Coloque novamente os valores na tabela XXX conforme antes estavam. R: DELETE FROM XXX; INSERT INTO XXX (CODIGO, NOME, SALARIO, SEXO) (SELECT CODIGO, NOME, SALARIO, SEXO FROM YYY); COMMIT; 6 Preencha os valores da tabela XXX na coluna CARGO conforme segue: 1 DBA ORACLE 4 - DBA DB2 2 DBA ORACLE 5 - DBA DB2 3 DBA ORACLE 6 - DBA SQL SERVER R: UPDATE XXX SET CARGO = DBA ORACLE WHERE CODIGO = 1; UPDATE XXX SET CARGO = DBA ORACLE WHERE CODIGO = 2; UPDATE XXX SET CARGO = DBA ORACLE WHERE CODIGO = 3; UPDATE XXX SET CARGO = DBA DB2
2
IBTA 2766
WHERE CODIGO = 4; UPDATE XXX SET CARGO = DBA DB2 WHERE CODIGO = 5; UPDATE XXX SET CARGO = DBA SQL SERVER WHERE CODIGO = 6; COMMIT; 7 Coloque a coluna SEXO da tabela XXX como no usada. R: ALTER TABLE xxx SET UNUSED (SEXO); 8 Elimine as colunas que no esto sendo usadas. R: ALTER TABLE xxx DROP UNUSED COLUMNS; 9 Adicione uma restrio nica(UNIQUE KEY) com o nome de XXX_NOME_UK na coluna NOME da tabela XXX. (Testar a condio). R: ALTER TABLE XXX ADD CONSTRAINT XXX_NOME_UK UNIQUE(NOME); 10 Adicione uma restrio Check(Check Constraint) com o nome de XXX_SALARIO_CK na coluna SALARIO da tabela XXX, onde o salario deve ser maior que 500. (Testar a condio). R: ALTER TABLE XXX ADD CONSTRAINT XXX_SALARIO_CK CHECK (SALARIO > 500); 11 Adicione uma restrio Chave Primria(PRIMARY KEY) com o nome de XXX_CODIGO_PK na coluna CODIGO da tabela XXX. (Testar a condio). R: ALTER TABLE XXX ADD CONSTRAINT XXX_CODIGO_PK PRIMARY KEY(CODIGO); 12 Adicione uma restrio No nula(NOT NULL) com o nome de XXX_CARGO_NN na coluna CARGO da tabela XXX. (Testar a condio). R: ALTER TABLE XXX MODIFY CARGO CONSTRAINT XXX_CARGO_NN NOT NULL;
IBTA 2766
13 - Adicione uma restrio No nula(NOT NULL) com o nome de XXX_SEXO_NN na coluna SEXO da tabela XXX. (Testar a condio). R: ALTER TABLE XXX MODIFY SEXO CONSTRAINT XXX_SEXO_NN NOT NULL; 14 - Elimine a restrio No nula(NOT NULL) com o nome de XXX_SEXO_NN na coluna SEXO da tabela XXX. (Testar a condio). R: ALTER TABLE XXX DROP CONSTRAINT XXX_SEXO_NN; 15 Desative a restrio No nula(NOT NULL) com o nome de XXX_CARGO_NN na coluna CARGO da tabela XXX. (Testar a condio). R: ALTER TABLE XXX DISABLE CONSTRAINT XXX_CARGO_NN; 16 - Ative novamente a restrio No nula(NOT NULL) com o nome de XXX_CARGO_NN na coluna CARGO da tabela XXX. (Testar a condio). R: ALTER TABLE XXX ENABLE CONSTRAINT XXX_CARGO_NN; 17 Selecione o nome, o tipo e o status da restrio criada para a tabela XXX. R: SELECT CONSTRAINT_NAME, CONSTRAINT_TYPE, STATUS FROM USER_CONSTRAINTS WHERE TABLE_NAME = 'XXX'; 18 Elimine todas as linhas da tabela sem o uso do comando DELETE R: TRUNCATE TABLE xxx; 19 Elimine a tabela XXX. R: Drop table XXX.
IBTA 2767
Prtica 12 Exerccios envolvendo funes de grupo

1) Exiba o maior salrio dos funcionrios que trabalham no departamento 10. R: SElect max(sal) from emp where deptno = 10; 2) Exiba a mdia salarial entre todos os funcionrios. R: SElect avg(sal) from emp; 3) Exiba a soma entre todos os salrios dos funcionrios que trabalham no mesmo departamento que o funcionrio SMITH. R: SElect sum(sal) from emp where deptno = (select deptno from emp where ename = SMITH); 4) Exiba os salrios menor, maior, mdio e a soma de todos os salrios de todos os funcionrios, colocando os apelidos (Labels ou Alias) Mnimo, Mximo, Mdio e Total respectivamente. R: SELECT MIN(SAL) MINIMO, MAX(SAL) MXIMO, AVG(SAL) MEDIA, SUM(SAL) TOTAL FROM EMP; 5) Exiba a data de hoje o mesmo formato do exemplo: 13 de Setembro de 2004 Horrio - 12:32:15 obs.: Devem ser utilizadas as funes para converso de datas e exibio da data do Sistema Operacional. R: Select to_char(sysdate, dd de month de YYYY Horrio HH24:MI:SS) from dual; 6) Exiba o salrio de todos os funcionrios, sem repetio, de acordo com o exemplo: $ 99,999.99 R: Select distinct to_char(sal, $ 99,999.99) from emp; 7) Crie uma consulta para exibir o nmero de pessoas com o mesmo cargo. R: SELECT JOB, COUNT(*) FROM EMP GROUP BY JOB;
IBTA 2767
8) Selecione as medias salriais de cada departamento R: SELECT DEPTNO, AVG(SAL) FROM EMP GROUP BY DEPTNO; 9) Selecione os maiores salrios agrupados por departamento e verifique se nestes grupos o salrio maior ou igual a 2000 R: SELECT DEPTNO, MAX(SAL) FROM EMP GROUP BY DEPTNO HAVING MAX(SAL) >= 2000; 10) Exiba o nome do gerente e a quantidade de funcionrios que trabalham para o mesmo gerente. R: Select g.ename, count(e.mgr) From emp g, emp e Where e.mgr = g.empno Group by g.ename
IBTA 2768
Prtica 13 Exerccios envolvendo subconsulta Lembrete: Inicie o servio do Oracle Instrues: Estabelea conexo com o usurio SCOTT. Utilize as tabelas do usurio Scott.
1) Exiba a soma entre todos os salrios dos funcionrios que trabalham no mesmo departamento que o funcionrio SMITH. 2) Crie uma consulta para exibir o nome do funcionrio e a data de admisso de todos os funcionrios do mesmo departamento que Blake. Excluindo Blake. 3) Exiba o nome e o salrio dos funcionrios que trabalham para o gerente KING. 4) Exiba o nmero do departamento, o nome e o cargo de todos os funcionrios do departamento de Vendas (SALES) 5) Crie uma consulta para exibir o nmero e o nome de todos os funcionrios que recebem mais que o salrio mdio. Classifique os resultados, por salrio em ordem decrescente. 6) Criar consulta que mostre o nome do funcinrio, nmero do departamento e o salrio dos funcionrios cujo nmero do departamento e o salrio correspondem ao nmero do departamento e ao salrio de qualquer funcionrio que receba comisso. 7) Selecione o nome do empregado com o maior salrio do departamento SALES 8) Selecione o nome, salario e cargo dos funcionrios cujo cargo o mesmo do funcionrio CLARK com exceo deste mesmo. 9) Selecione o cdigo do departamento e as mdias salarias agrupadas por departamento onde a mdia salarial agrupada deve ser maior que a mdia salarial do departamento com o cdigo 20. 10) Crie a tabela EMP2 com base na tabela EMP, na criao popule a tabela com os registros de todos os funcionrios com cargo = CLERK 11) Crie a tabela EMP3 com base nas tabelas EMP e DEPT, na criao popule a tabela com os registros de todos os funcionrios que trabalham nos departamentos localizados em NEW YORK. A tabela EMP3 dever conter os campos empno, ename, job, sal, mgr, deptno, dname e loc
IBTA 2768
12) Insira na tabela EMP2 todos os registros dos funcionrios que trabalham nos departamentos 10 ou 20 13) Altere os salrios dos funcionrios da tabela EMP3 que trabalham no departamento 20 para o valor da mdia salarial dos funcionrios que trabalham no departamento 30 da tabela emp. Desfaa a transao 14) Exclua todas as linhas da tabela EMP quando o cdigo do departamento for o mesmo cdigo de departamento do funcionrio 7839. Desfaa a transao.
IBTA 2769
Prtica 14 Views, Sinnimos, Seqncias, ndices Lembrete: Inicie o Servio do Banco Instrues: Realize conexo com o usurio Scott
1 Crie uma view VW_XXX com os campos NOME, CARGO, SALARIO da tabela XXX, onde os valores salariais sejam superiores a 6000. R: CREATE VIEW VW_XXX AS SELECT NOME, CARGO, SALARIO FROM XXX WHERE SALARIO > 6000;
2 - Crie uma view VW_XXX2 com os campos CODIGO, SEXO da tabela XXX, onde os valores salariais sejam inferiores ou iguais a 6000. R: CREATE VIEW VW_XXX2 AS SELECT CODIGO, SEXO FROM XXX WHERE SALARIO <= 6000;
3 Selecione as linhas das views criadas acima VW_XXX e VW_XXX2. R: SELECT * FROM VW_XXX; SELECT * FROM VW_XXX2; 4 Modifique a view VW_XXX2 para que esta contenha alm das colunas j existentes adicione a coluna NOME, mantendo as mesmas restries j existentes. R: CREATE OR REPLACE VIEW VW_XXX2 AS SELECT CODIGO, SEXO, NOME FROM XXX WHERE SALARIO <= 6000; 5 Limite as operaes da view VW_XXX apenas as condies que a ela foram apresentadas usando a clusula WITH CHECK OPTION. Testar condio com o comando que segue: UPDATE VW_XXX SET SALARIO = 5000; R: CREATE OR REPLACE VIEW VW_XXX AS SELECT NOME, CARGO, SALARIO FROM XXX WHERE SALARIO > 6000 WITH CHECK OPTION;
IBTA 2769
6 Limitar os usurios a apenas selecionar as linhas da view VW_XXX2. (Usurios no podem emitir DMLs nesta view) R: CREATE OR REPLACE VIEW VW_XXX2 AS SELECT CODIGO, SEXO, NOME FROM XXX WHERE SALARIO <= 6000 WITH READ ONLY; 7 Remover a view VW_XXX2. R: DROP VIEW VW_XXX2; 8 Selecione o nome e o texto da view criada por voc. R: SELECT VIEW_NAME, TEXT FROM USER_VIEWS; 9 Crie uma sequncia (SEQUENCE) com o nome SQ_CODIGO_XXX, que inicie em 100 e que incremente de 10 em 10 unidades. R: CREATE SEQUENCE SQ_CODIGO_XXX INCREMENT BY 10 START WITH 100; 10 Consulte as sequencias criadas pelo usurio SCOTT. R: SELECT SEQUENCE_NAME, MIN_VALUE, MAX_VALUE, INCREMENT_BY, LAST_NUMBER FROM USER_SEQUENCES; 11 Insira 2 novas linhas na tabela YYY, usando no campo CODIGO os valores trazidos da Sequencia (SEQUENCE). Efetive a operao. R: INSERT INTO YYY (CODIGO, NOME, SALARIO, SEXO) VALUES (SQ_CODIGO_XXX.NEXTVAL, JOAO, 3000, M); INSERT INTO YYY (CODIGO, NOME, SALARIO, SEXO) VALUES (SQ_CODIGO_XXX.NEXTVAL, MARIA, 3000, F); COMMIT; 12 Altere a sequencia (SEQUENCE) para deixar 30 valores em cache e coloque o valor mximo da sequencia para 99999. R: ALTER SEQUENCE SQ_CODIGO_XXX INCREMENT BY 10
IBTA 2769
MAXVALUE 99999 CACHE 30; 13 Remova a sequencia (SEQUENCE) SQ_CODIGO_XXX do usurio SCOTT. R: DROP SEQUENCE SQ_CODIGO_XXX; 14 Crie um ndice composto com o nome de IDX_NOMECARGO_XXX para os campos NOME e CARGO da tabela XXX. R: CREATE INDEX IDX_NOMECARGO_XXX ON XXX (NOME, CARGO); 15 - Consulte o ndice criado e quais colunas foram usadas para sua criao nas views do sistema. R: SELECT INDEX_NAME, INDEX_TYPE, TABLE_NAME, STATUS FROM USER_INDEXES; SELECT INDEX_NAME, COLUMN_LENGTH FROM USER_IND_COLUMNS; TABLE_NAME, COLUMN_NAME,
16 Elimine o ndice criado IDX_NOMECARGO_XXX. R: DROP INDEX IDX_NOMECARGO_XXX; 17 Crie um Sinnimo com o nome de VPX para a view VW_XXX. (Testar sinnimo com comando SQL). R: CREATE SYNONYM VPX FOR VW_XXX; SELECT * FROM VPX; 18 Elimine o Sinnimo VPX. R: DROP SYNONYM VPX;
IBTA 2770
Prtica 15 Atividade Terico/Prtica - Exerccios envolvendo Modelagem e SQL Caso NF

Estabelea conexo com o usurio SCOTT. Considere o Modelo Criado anteriormente, na Prtica 6, cujo enunciado segue abaixo e faa o que se pede:
CLIENTE Nome Cpf Rg End Fone nascimento
PRODUTO Codigo Descrio valor
NOTA FISCAL Numero Cliente Nome vendedor Cdigo vendedor Produto Valor total Data Entrega
VENDA Vendedor Valor Comisso Data Tipo
Dados sobre o problema: O cliente ao efetuar uma compra tem seus dados pessoais cadastrados. Existe a necessidade de se verificar a forma de pagamento, que pode ser a vista ou a prazo e em ambos os casos existe a possibilidade de faze-lo com cheque, dinheiro ou carto de crdito O produto pode ser retirado pelo cliente ou entregue em um endereo que pode ou no ser o seu endereo pessoal A venda gera um pagamento de comisso ao vendedor, o percentual de venda de 2% do valor da compra Os produtos ficam armazenados em um estoque. O vendedor antes de efetuar uma venda consulta o estoque Toda venda gera uma nota fiscal que deve conter os dados do vendedor, do cliente, da entrega, dos produtos, data e nmero da nf, valor total de cada produto, valor total geral Todo vendedor possui um gerente, que tambm deve ser cadastrado como sendo um funcionrio. Com base nestas informaes, verifique se as tabelas indicadas so suficientes para o armazenamento dos dados necessrios a construo de uma base de dados que permita o funcionamento adequado de uma loja de eletrodomsticos e:
Modelo do Banco 1) A partir do Modelo Fsico desenvolvido do ERWIN, gere os scripts de criao das tabelas 2) Cadastre: os clientes:
1
IBTA 2770
Siliane Florzinha Joo Bonzo Leandro Grando Os vendedores Thiago Vende Tudo Ari Bab Pedro Pedrinha Os produtos Geladeira - preo 1200,00 Fogo preo 500,00 Secador de cabelos 90,00 Barbeador eltrico 120,00 Os demais dados devem ser complementados de acordo com a sua criatividade! Todas as tabelas criadas devem conter pelo menos 3 registros COMPLETOS 3) Inclua uma linha na tabela CLIENTE contendo os seus dados. 4) Altere o valor Do produto geladeira para 1288,00 5) Altere o preo de todos os produtos acrescentando 10 do seu valor original. 6) Cadastre o produto Microcomputador com valor de 1500,00 7) Exclua o produto Barbeador Eltrico
11.14 Consultas 8) Exiba o nome de todos os clientes atendidos pelo vendedor Thiago Vende Tudo 9) Exiba o nome dos vendedores e dos seus gerentes. 10) Exiba o nome dos vendedores e a soma das suas comisses no ms de julho 11) Exiba o nome dos clientes e o valor mdio das suas compras 12) Exiba a lista de clientes aniversariantes do ms corrente. 13) Exiba a lista com os 5 melhores vendedores da loja. 14) Exiba o nome e endereo de todos os clientes cujo nome iniciado com a letra A 15) Exiba todos os dados da nota fiscal para uma determinada compra. 16) Exiba todas as entregas programadas para o data corrente. 17) Exiba os nmeros das notas fiscais e os nomes dos clientes cujas notas foram emitidas na data corrente.
IBTA 2770
R: Soluo apresentada pelos alunos -- Alexandre Bevilacqua Pacheco e Ricardo de Moraes Peretto ( turma 3Bd2 2s2003) Foi utilizada a ferramenta Erwin para modelagem e gerao dos scripts de criao das tabelas
IBTA 2770
IBTA 2770
IBTA 2770
DROP TABLE cliente CASCADE CONSTRAINTS; CREATE TABLE cliente ( id_cliente number(5)CONSTRAINT PK_cliente PRIMARY KEY, nome varchar2(40) NOT NULL, cpf number(9) NOT NULL, cpf_controle number(2) NOT NULL, rg varchar2(15) NOT NULL, end varchar2(50) NOT NULL, dt_nasc date NOT NULL );
DROP TABLE fone_cliente CASCADE CONSTRAINTS; CREATE TABLE fone_cliente ( id_cliente number(5), ddd number(3), numero number(15), CONSTRAINT PK_fone_cliente PRIMARY KEY(id_cliente, ddd, numero), CONSTRAINT FK_fone_cliente FOREIGN KEY(id_cliente) REFERENCES cliente(id_cliente) );
DROP TABLE funcionario CASCADE CONSTRAINTS; CREATE TABLE funcionario ( id_funcionario number(5) CONSTRAINT PK_funcionario PRIMARY KEY, nome varchar2(40) NOT NULL, dt_admissao date NOT NULL );
DROP TABLE gerente CASCADE CONSTRAINTS; CREATE TABLE gerente ( id_gerente number(5) CONSTRAINT PK_gerente PRIMARY KEY, CONSTRAINT FK_gerente_funcionario FOREIGN KEY(id_gerente) REFERENCES funcionario(id_funcionario) );
DROP TABLE vendedor CASCADE CONSTRAINTS; CREATE TABLE vendedor ( id_vendedor number(5)CoNSTRAINT PK_vendedor PRIMARY KEY, id_gerente number(5) NOT NULL,
IBTA 2770
comissao number(3) NOT NULL, CONSTRAINT FK_vendedor_funcionario FOREIGN KEY(id_vendedor) REFERENCES funcionario(id_funcionario), CONSTRAINT FK_vendedor_gerente FOREIGN KEY(id_gerente) REFERENCES gerente(id_gerente) );
DROP TABLE produto_estocado CASCADE CONSTRAINTS; CREATE TABLE produto_estocado ( id_produto_estocado number(5) CONSTRAINT PK_produto PRIMARY KEY, descricao varchar2(40) NOT NULL, valor_unitario number(7,2) NOT NULL, quantidade number(10) NOT NULL );
DROP TABLE tipo_pgto CASCADE CONSTRAINTS; CREATE TABLE tipo_pgto ( id_tipo_pgto number(5)CONSTRAINT PK_tipo_pgto PRIMARY KEY, descricao varchar2(20) NOT NULL );
DROP TABLE forma_pgto CASCADE CONSTRAINTS; CREATE TABLE forma_pgto ( id_forma_pgto number(5) CONSTRAINT PK_forma_pgto PRIMARY KEY, descricao varchar2(20) NOT NULL );
DROP TABLE nfiscal CASCADE CONSTRAINTS; CREATE TABLE nfiscal ( id_nfiscal PK_nfiscal PRIMARY KEY, id_vendedor NULL, id_cliente NULL, id_forma_pgto NULL, id_tipo_pgto NULL,
number(5) CONSTRAINT number(5) number(5) number(5) number(5) NOT NOT NOT NOT
IBTA 2770
dt NULL, end_entrega varchar2(50) NOT NULL, CONSTRAINT FK_nfiscal_vendedor KEY(id_vendedor) vendedor(id_vendedor), CONSTRAINT FK_nfiscal_cliente KEY(id_cliente) cliente(id_cliente), CONSTRAINT FK_nfiscal_forma_pgto FOREIGN forma_pgto(id_forma_pgto), CONSTRAINT FK_nfiscal_tipo_pgto tipo_pgto(id_tipo_pgto) );
date
NOT
FOREIGN REFERENCES FOREIGN REFERENCES KEY(id_forma_pgto) REFERENCES KEY(id_tipo_pgto) REFERENCES
FOREIGN
DROP TABLE itens_nf CASCADE CONSTRAINTS; CREATE TABLE itens_nf ( id_nfiscal number(5) NOT NULL, id_produto_estocado number(5) NOT NULL, qtde number(5) NOT NULL, valor_unitario number(7,2) NOT NULL, CONSTRAINT PK_itens_nf PRIMARY KEY(id_nfiscal, id_produto_estocado), CONSTRAINT FK_nf_prod_nf FOREIGN KEY(id_nfiscal) REFERENCES nfiscal(id_nfiscal), CONSTRAINT FK_nf_prod_prod FOREIGN KEY(id_produto_estocado) REFERENCES produto_estocado(id_produto_estocado) );
-- SEQUENCIAS DROP DROP DROP DROP DROP DROP DROP SEQUENCE SEQUENCE SEQUENCE SEQUENCE SEQUENCE SEQUENCE SEQUENCE sq_cliente; sq_fone_cliente; sq_funcionario; sq_produto_estocado; sq_tipo_pgto; sq_forma_pgto; sq_nfiscal;
CREATE SEQUENCE sq_cliente; CREATE SEQUENCE sq_fone_cliente;
IBTA 2770
CREATE CREATE CREATE CREATE CREATE
SEQUENCE SEQUENCE SEQUENCE SEQUENCE SEQUENCE
sq_funcionario; sq_produto_estocado; sq_tipo_pgto; sq_forma_pgto; sq_nfiscal;
Instrues DML -- INSERTS TABELA CLIENTE INSERT INTO cliente VALUES ( sq_cliente.NEXTVAL , 'Siliane Florzinha' , 123456789 , 00 , '12.345.678-X' , 'Rua Estela, 10' , '01/01/1971' ); INSERT INTO cliente VALUES ( sq_cliente.NEXTVAL , 'Joo Bonzo' , 223456789 , 00 , '22.345.678-X' , 'Rua Estela, 20' , '02/01/1971' ); INSERT INTO cliente VALUES ( sq_cliente.NEXTVAL , 'Leandro Grando ' , 323456789 , 00 , '32.345.678-X' , 'Rua Estela, 30' , '03/01/1971' ); INSERT INTO cliente VALUES ( sq_cliente.NEXTVAL , 'Cicrano de Sousa' , 423456789 , 00 , '42.345.678-X' , 'Rua Estela, 40' , '04/01/1971' ); INSERT INTO cliente VALUES ( sq_cliente.NEXTVAL , 'Beltrano da Silva' , 523456789 , 00 , '52.345.678-X' , 'Rua Estela, 50' , '05/01/1971' ); -- INSERTS TABELA FONE_CLIENTE INSERT INSERT INSERT INSERT INSERT INTO INTO INTO INTO INTO fone_cliente fone_cliente fone_cliente fone_cliente fone_cliente VALUES VALUES VALUES VALUES VALUES ( ( ( ( ( 2 3 2 4 1 , , , , , 11 11 11 11 11 , , , , , 12345678 22345678 32345678 42345678 52345678 ); ); ); ); );
-- INSERTS TABELA FUNCIONARIO INSERT INTO funcionario VALUES ( sq_funcionario.NEXTVAL , 'Thiago Vende Tudo' , '12/12/2002' ); INSERT INTO funcionario VALUES ( sq_funcionario.NEXTVAL , 'Ari Bab' , '13/11/2001' ); INSERT INTO funcionario VALUES ( sq_funcionario.NEXTVAL , 'Pedro Pedrinha' , '14/01/2004' ); INSERT INTO funcionario VALUES ( sq_funcionario.NEXTVAL , 'Brano de Souza' , '14/05/2001' ); INSERT INTO funcionario VALUES ( sq_funcionario.NEXTVAL , 'Bruno de Souza' , '16/02/2002');
IBTA 2770
INSERT INTO funcionario VALUES ( sq_funcionario.NEXTVAL , 'Juao Alemao' , '20/01/1983'); -- INSERTS TABELA GERENTE INSERT INTO gerente VALUES ( 2 ); INSERT INTO gerente VALUES ( 4 ); INSERT INTO gerente VALUES ( 6 ); -- INSERTS TABELA VENDEDOR INSERT INTO vendedor VALUES ( 1 , 2 , 5 ); INSERT INTO vendedor VALUES ( 3 , 2 , 6 ); INSERT INTO vendedor VALUES ( 5 , 4 , 7 ); -- INSERTS TABELA PRODUTO_ESTOCADO INSERT INTO produto_estocado VALUES ( , 'Geladeira' , 1200 , 10 ); INSERT INTO produto_estocado VALUES ( , 'Fogo' , 500 , 5 ); INSERT INTO produto_estocado VALUES ( , 'Microondas' , 1100 , 10 ); INSERT INTO produto_estocado VALUES ( , 'PlayStation2' , 900 , 15 ); INSERT INTO produto_estocado VALUES ( , 'Computador' , 3200 , 50 ); INSERT INTO produto_estocado VALUES ( , 'NoteBook' , 6400 , 10 ); INSERT INTO produto_estocado VALUES ( , 'Handheld' , 900 , 5 ); INSERT INTO produto_estocado VALUES ( , 'Secador de cabelos' , 90 , 60 ); INSERT INTO produto_estocado VALUES ( , 'Barbeador eltrico' , 120 , 40 ); -- INSERTS TABELA TIPO_PGTO INSERT INSERT INSERT ); INSERT INSERT INSERT INTO tipo_pgto VALUES ( sq_tipo_pgto.NEXTVAL , 'cartao' ); INTO tipo_pgto VALUES ( sq_tipo_pgto.NEXTVAL , 'cheque' ); INTO tipo_pgto VALUES ( sq_tipo_pgto.NEXTVAL , 'dinheiro' INTO tipo_pgto VALUES ( sq_tipo_pgto.NEXTVAL , 'fiado' ); INTO tipo_pgto VALUES ( sq_tipo_pgto.NEXTVAL , 'boleto' ); INTO tipo_pgto VALUES ( sq_tipo_pgto.NEXTVAL , 'carne' ); sq_produto_estocado.NEXTVAL sq_produto_estocado.NEXTVAL sq_produto_estocado.NEXTVAL sq_produto_estocado.NEXTVAL sq_produto_estocado.NEXTVAL sq_produto_estocado.NEXTVAL sq_produto_estocado.NEXTVAL sq_produto_estocado.NEXTVAL sq_produto_estocado.NEXTVAL
10
IBTA 2770
-- INSERTS TABELA FORMA_PGTO INSERT INTO forma_pgto VALUES ( sq_forma_pgto.NEXTVAL , 'vista' ); INSERT INTO forma_pgto VALUES ( sq_forma_pgto.NEXTVAL , 'prazo' ); INSERT INTO forma_pgto VALUES ( sq_forma_pgto.NEXTVAL , 'outra' ); -- INSERTS TABELA NFISCAL INSERT INTO nfiscal '05/06/2004' , 'RUA INSERT INTO nfiscal '15/04/2004' , 'RUA INSERT INTO nfiscal '20/06/2004' , 'Rua VALUES ( sq_nfiscal.NEXTVAL DA MADRUGADA, 3965' ); VALUES ( sq_nfiscal.NEXTVAL SEI LA O QUE, 6815 BLOCO R' VALUES ( sq_nfiscal.NEXTVAL Tal, 199' ); , 1 , 2 , 1 , 4 , , 5 , 3 , 2 , 6 , ); , 1 , 1 , 3 , 5 ,
-- INSERTS TABELA ITENS_NF INSERT INSERT INSERT INSERT INSERT INSERT INSERT INTO INTO INTO INTO INTO INTO INTO itens_nf itens_nf itens_nf itens_nf itens_nf itens_nf itens_nf VALUES VALUES VALUES VALUES VALUES VALUES VALUES ( ( ( ( ( ( ( 1 1 1 2 2 2 2 , , , , , , , 1 2 3 4 5 6 7 , , , , , , , 1 1 1 2 1 3 2 , , , , , , , 1200 ); 500 ); 1100 ); 900 ); 3966 ); 6173 ); 900 );
--- CONSULTAS SIMPLES SELECT SELECT SELECT SELECT SELECT SELECT SELECT SELECT SELECT SELECT * * * * * * * * * * FROM FROM FROM FROM FROM FROM FROM FROM FROM FROM cliente; fone_cliente; funcionario; gerente; vendedor; produto_estocado; tipo_pgto; forma_pgto; nfiscal; itens_nf;
INSERT INTO cliente
11
IBTA 2770
VALUES ( sq_cliente.NEXTVAL , 'Nova linha' , 111111985 , 11 , '30.909.808-8' , 'R. tal, 10' , '01/01/1976' ); UPDATE produto_estocado SET valor_unitario=1288.00 WHERE UPPER(descricao) = 'GELADEIRA';
Consultas SELECT c.nome NomeCliente FROM cliente c, nfiscal n, funcionario f WHERE c.id_cliente = n.id_cliente AND n.id_vendedor = f.id_funcionario AND UPPER(f.nome) = 'THIAGO VENDE TUDO'; SELECT ven.nome nomeVendedor, ger.nome nomeGerente FROM ( SELECT v.id_vendedor, v.id_gerente, f.nome FROM vendedor v, funcionario f WHERE v.id_vendedor=f.id_funcionario) ven, (SELECT g.id_gerente, f.nome FROM gerente g, funcionario f WHERE g.id_gerente=f.id_funcionario ) ger WHERE ven.id_gerente = ger.id_gerente;
SELECT func.nome, venda.comissao FROM ( SELECT v.id_vendedor, f.nome FROM vendedor v, funcionario f WHERE v.id_vendedor=f.id_funcionario) func, ( SELECT n.id_vendedor, sum(com.comi) comissao FROM nfiscal n, (SELECT id_nfiscal, (sum(valor_unitario*qtde)*0.02) comi FROM itens_nf GROUP BY id_nfiscal) com WHERE n.id_nfiscal = com.id_nfiscal AND TO_CHAR(n.dt, 'mm')='06' GROUP BY n.id_vendedor) venda WHERE func.id_vendedor = venda.id_vendedor;
SELECT c.nome, comp.mediaCompra FROM cliente c,( SELECT n.id_cliente, AVG(nota.valor) mediaCompra
12
IBTA 2770
FROM nfiscal n, ( SELECT id_nfiscal, sum(valor_unitario*qtde) valor FROM itens_nf GROUP BY id_nfiscal) nota WHERE n.id_nfiscal = nota.id_nfiscal GROUP BY n.id_cliente) comp WHERE c.id_cliente = comp.id_cliente; SELECT ven.nome, 'Funcionario Ouro' mensagem FROM ( SELECT v.id_vendedor, f.nome, f.dt_admissao FROM vendedor v, funcionario f WHERE v.id_vendedor = f.id_funcionario AND TO_CHAR(f.dt_admissao, 'yyyy') < 1985) ven UNION SELECT ven.nome, 'Funcionario Prata' mensagem FROM ( SELECT v.id_vendedor, f.nome, f.dt_admissao FROM vendedor v, funcionario f WHERE v.id_vendedor = f.id_funcionario AND TO_CHAR(f.dt_admissao, 'yyyy') BETWEEN 1986 AND 2002) ven UNION SELECT ven.nome, 'Funcionario Bronze' mensagem FROM ( SELECT v.id_vendedor, f.nome, f.dt_admissao FROM vendedor v, funcionario f WHERE v.id_vendedor = f.id_funcionario AND TO_CHAR(f.dt_admissao, 'yyyy') > 2002) ven;
13

Apotila BD

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apotila BD

Uploaded by

Copyright:

Available Formats

Banco de Dados

MODELAGEM DE BANCO DE DADOS

2 Edio 3 Impresso 1 Semestre de 2007 Copyright Faculdade IBTA

1. Projetos de Bancos de Dados

Comunicar Categorizar Descrever Especificar Investigar Desenvolver Analisar Imitar

Modelo Conceitual; Modelo Lgico;

1.1. Levantamento de Dados ou Levantamento de Requisitos

Elmasri, Ramez e Navathe, S. B. Sistemas de Bancos de Dados, Addison Wesley, 2005

1.2. Modelo Conceitual

COUGO, P., Modelagem Conceitual e Projeto de Bancos de Dados, Campus, 2000 3

1.2.1. Objetivos do Modelo Conceitual

Descrio das Informaes O objetivo do modelo conceitual descrever as informaes

Resultado real O resultado de um Modelo Conceitual um esquema que representa a

Independncia de Manipulao e Manuteno dos Dados No construdo com

Independncia do SGBD No retrata aspectos ligados abordagem do banco de dados que

1.2.2. Caractersticas do Modelo Conceitual

Inicia o projeto a primeira etapa do projeto de um sistema de aplicao em banco de

1.2.3. O Modelo Conceitual propicia

Melhor compreenso pelo usurio leigo: Um modelo conceitual normalmente uma

Independncia de detalhes de implementao: Um modelo conceitual no vinculado a

Ferramenta indispensvel para o processo de engenharia reversa de BD: O upgrade (ou

Maior estabilidade frente a mudanas a nvel de implementao: O modelo conceitual, por

Mais adequado para o exerccio da criatividade: Um modelo conceitual na verdade uma

1.2.4. Exemplo de Modelagem Conceitual

s1/1 Ator Paticipacao personagem cache atua 1-N

nome_arstistico nac idade sexo tipo_papel [0-3]

tem-direcao-de 1-1 Diretor direcao dirige 0-N

nome nacionalidade premio [1-N] festival ano nome_premio

Obs.: Notao ER da ferramenta DB Main

1.3. Modelo Lgico

COUGO, P., Modelagem Conceitual e Projeto de Bancos de Dados, Campus, 2000 7

Funcionrio Cdigo do Funcionario Dependente Cdigo do Dependente

1.4. Modelo Fsico

cd_funcionario:NUMBER(10) nm_funcionario:VARCHAR2(40) nm_endereco_funcionario:VARCHAR2(40) nr_telefone_funcionario:VARCHAR2(20) vl_salario_funcionario:NUMBER(13,2) nm_cargo_funcionario:VARCHAR2(40) dt_admissao_funcionario:DATE dt_nascimento_funcionario:DATE ds_funcionario:VARCHAR2(4000)

cd_dependente:NUMBER(3) nm_dependente:VARCHAR2(40) dt_nascimento_dependente:DATE nm_parentesco_dependente:VARCHAR2(20) cd_funcionario: NUMBER(10)

A integridade em nvel de campo estabelecida e imposta como resultado da definio de

q Elementos de Campo Ideal

Elementos Fsicos: Tipo de Dados, suporte de caracteres, comprimento, casas decimais,

Informaes de Especificao: Tipo de especificao, baseadas em especificao existente,

Entidade....... Entidade....... Entidade....... Entidade....... Entidade....... Entidade....... Entidade....... C C,R U D U R,D D

Entidade....... Entidade....... Entidade....... Entidade....... Entidade....... Entidade....... Entidade....... Entidade....... Entidade.......

Copyright Faculdade IBTA

Legenda C R D U Create Read Delete Update

2. Modelo de Banco de Dados

2.1. Modelo Hierrquico de Banco de Dados

Figura 5. Diagrama de estrutura de rvore com campo-chave.

IBM Training Center, Fundamentos de Bancos de Dados, 1989. 13

Figura 6. Exemplo de Modelo Hierrquico.

2.2. Modelo Banco de Dados em Rede

1024 Ana Knor Laguna 0020

Figura 7. Exemplo de Modelo de Rede.

2.3. Modelo Relacional12

Figura 9. Exemplo de modelo relacional.

2.3.1. Vantagens do Modelo Relacional

Construo de Nveis Mltiplos de Integridade: A integridade dos dados neste modelo

Independncia Fsica e Lgica da Aplicao do Banco de Dados: Nem as mudanas

Garantia da Consistncia e Acuracidade dos Dados: Os dados so acurados e

Fcil Armazenamento de Dados: Ao comando do usurio, os dados podem ser

2.4. Modelo Orientado a Objetos13

Mtodos: Os objetos nos SGBDOOs so manipulados atravs de mtodos. Em geral, a

Tipos e Classes: Um tipo modela as caractersticas comuns de um conjunto de objetos e

Herana: um mecanismo de reusabilidade muito poderoso. Com herana, uma classe

Polimorfismo: Os SGBDOOs oferecem o recurso de polimorfismo de operaes, tambm