You are on page 1of 26

ADM BD I

Administraao de Banco de

Dados I

Lcia Satiko Murotani

WFernando Bastos
CONTEDO

CAPTULO 1 projeto banco de dados ............................................................................................................................................... 2

CAPITULO 2 - ENTIDADE, ATRIBUTOS, RELACIONAMENTOS .............................................................................................................. 6

CAPTULO 3 CONCEITOS : Restries de Integridade e atributos de relacionamento ................................................................... 12

CAPTULO 4 identificar Relacionamentos ..................................................................................................................................... 16

CAPTULO 5 Relacionamentos reflexivos e extenses do modelo E-R........................................................................................... 18

CAPITULO 6 Projeto lgico de banco de dados .............................................................................................................................. 20

CAPTULO 7 - O que Normalizao de Tabelas? ............................................................................................................................ 22

Referncia bibliogrfica:

Felipe Nery Rodrigues Machado, Banco de Dados Projeto e Implementao Editora rica

Fanderuff, Damaris .Dominando o Oracle 9i Modelagem e Desenvolvimento Pearson Education Makron Books

Poderoso, Celso Henrique. SQL Curso Prtico

Apostila Professor Valter


Administrao de Banco de Dados I

CAPTULO 1 PROJETO BANCO DE DADOS

BANCO DE DADOS
Definio : uma coleo organizada de dados. uma ferramenta desenvolvida para a
manipulao eficiente de um grande conjunto de informaes estruturadas e armazenadas de forma
organizada e integrada.

Finalidade:Otimizao dos sistemas.

SGBD (Sistema Gerenciador de Banco de Dados)


Tratando-se de dados informatizados utiliza-se o SGBD (Sistema Gerenciador de Banco de
Dados) o software que permite a utilizao simultnea de um banco de dados por mltiplos
usurios e prove ferramentas para que eles possam criar e manipular as informaes armazenadas
no banco de dados.
Para ser considerado um SGBD devem seguir algumas regras, tais como: auto-conteno,
independncia dos dados, abstrao dos dados, vises, transaes, acesso automtico, caso
contrrio, ser um GA (Gerenciador de Arquivo) - um programa de computador usado para criar e
organizar pastas e ficheiros (arquivos) em sistemas operacionais. O acesso a informaes em
sistemas de processamentos de dados que no utilizam SGBDs feito pelo acesso sequencial a um
ou mais arquivos. Cabe ao desenvolvedor criar mecanismos de recuperao de informao.

Caractersticas de SGBD :
Integridade: consiste em impedir que determinado cdigo ou chave em uma tabela no tenha
correspondncia em outra tabela. PK e FK.

Restries ou consistncia: informao confivel, o dado armazenado em um nico local, com


acesso descentralizado, compartilhado pelos vrios sistemas.

Segurana ou privacidade: define para cada usurio o nvel de acesso tabela e /ou campo, seja
de leitura, leitura e gravao ou sem acesso.

Restaurao ou reorganizao: apresentar facilidade para recuperar falhas de hardware e


software, por meio da existncia de arquivos de backup ou de outros recursos automticos.

Controle de Redundncia: consiste no armazenamento de uma mesma informao em locais


diferentes, provocando inconsistncias. Em um banco de dados as informaes s se encontram
armazenadas em um nico local, controle no banco de dados.

Independncia Fsica: imunidade das aplicaes estrutura de armazenamento e estratgia de


acesso s informaes.

Padronizao dos dado e esquematizao: exemplificando, no campo sexo somente permite


armazenamento M ou F.

2
Administrao de Banco de Dados I

MODELAGEM DE DADOS
Existe de um lado as tcnicas de Orientao a Objetos ( que atualmente indiscutvel a vantagem obtida
no projeto) e o grande mercado nacional e mundial utilizando os SGBD Relacionais. E como permitir que
um projeto desenvolvido em O.O. seja facilmente inserido em um ambiente de banco de dados relacional?
Denominamos como camada de persistncia de dados.

O nosso objetivo dominar as tcnicas de modelagem de dados para banco de dados relacionais,
completando com a implementao em projetos de anlise estruturada ou com um projeto orientado a
objetos.

Um dos principais problemas relacionados com banco de dados a redundncia, solucionamos com a
criao de vrias tabelas apesar de aumentar a complexidade. Quando se admite a redundncia, muito
comum ter que repetir nomes, descries, etc. Ao isolarmos essas informaes em tabelas distintas e ao
relacionarmos as tabelas por um cdigo comum estamos economizando espao de armazenamento.

A modelagem de dados busca representar a organizao dos dados do mundo real. O objetivo de um
modelo de dados garantir que as informaes existentes requeridos pela aplicao e pelo banco de
dados estejam representados de forma simples para que tanto o usurio final entenda e o DBA
(administrador do banco de dados) utilize para a criao da estrutura final do SGBD.

O analista abstrai do mundo real, ou seja, a parte do negcio que tem interesse em controlar, sem se
preocupar nesse primeiro momento com qualquer conceito tcnico. Obtemos assim um modelo
conceitual, tendo como resultado um esquema grfico.

O segundo passo iniciar o modelo lgico, considerando as abordagens da tecnologia dos SGBD (
relacional, hierrquica, rede ou Orientado a objeto) mas sem considerar, ainda, nenhuma caracterstica
especfica de SGBD.

Somente no modelo fsico, que ser construdo a partir do modelo lgico, deve obrigatoriamente definir o
SGBD e descrever estruturas fsicas de armazenamento de dados.

Projetando banco de dados


Para manter a estabilidade de todo o sistema e garantir um menor tempo que ser despendido na
manuteno do modelo importante planejar a criao do banco de dados.

Metodologia Case
O processo de Anlise de Dados pressupe trs fases distintas e integradas:

- Anlise e modelagem utilizando


modelo de entidade relacionamento e
normalizao de dados

- Definio de Tabela, ndice, view, etc.

Figura 1

3
Administrao de Banco de Dados I

Estratgia

Modelar o Negcio ( Entrevista, Modelo de Dados MER simples ) , arquitetura (


HD, link, etc) e plano de desenvolvimento ( Cronograma Custo R$);

Anlise

Detalhar a modelagem ( MER normalizado), especificaes e estratgia de


Implantao;

Projeto

Arquitetura do Sistema, projetar o Banco de Dados, especificar mdulos e rascunhar


manuais do usurio;

Construo

Criar os programas, criar o Banco de Dados (Linguagem SQL), planejar Implantao e


Instalao de ambiente.

Esquema geral de modelagem de dados usando MER

Figura 2

4
Administrao de Banco de Dados I

Modelo Conceitual
Representao dos conceitos e caractersticas observados no ambiente;
Ignorar particularidades de implementao.

Modelo Lgico
Regras de Derivao:
Normalizao das estruturas de dados
Derivao de estruturas de agregao e generalizao-especializao
Derivao de relacionamentos

Regras de Restrio:
Restrio de domnio
Restrio de Integridade
Restrio de Implementao

Modelo Fsico
Inclui a anlise das caractersticas e recursos necessrios para armazenamento e
manipulao das estruturas de dados (estrutura de armazenamento, endereamento,
acesso e alocao fsica).

Modelo Entidade-Relacionamento
O Modelo Entidade-Relacionamento foi definido por Peter Chen em 1976, e teve como base a teoria
relacional criada por E.F.Cood (1970). Segundo Chen, a viso de uma dada realidade, baseia-se no
relacionamento entre entidades, os quais retratam os fatos que governam esta mesma realidade, e
que cada um (entidade ou relacionamento) pode possuir atributos (qualificadores desta realidade).

O conceito de abstrao permite ao analista separar da realidade em estudo, as partes que so


realmente relevantes para o desenvolvimento do sistema de informaes e excluir da modelagem
todos os aspectos que no exercem influncia sobre o ambiente a ser modelado. O objetivo da
modelagem de dados possibilitar a apresentao de uma viso nica no redundante e resumida
dos dados de uma aplicao. Tambm nos ajuda a entender a estrutura e o significado dos dados.

No desenvolvimento de aplicaes em banco de dados, o Modelo Entidade Relacionamento (E-R)


o mais largamente utilizado para a representao e entendimento dos dados que compem a
essncia de um sistema de informaes.

A tcnica de modelagem Entidade-Relacionamento proposta por Peter Chen est definida como uma
notao orientada para o desenho do modelo conceitual, pois permite a descrio desse esquema
conceitual sem a preocupao com problemas de implementao fsica ou de performance de banco
de dados.

5
Administrao de Banco de Dados I

CAPITULO 2 - ENTIDADE, ATRIBUTOS, RELACIONAMENTOS

DER DIAGRAMA ENTIDADE-RELACIONAMENTO


O diagrama ER uma ferramenta para modelagem conceitual e lgica de um banco de dados
amplamente utilizada no projeto de banco de dados, sendo considerado praticamente um padro
para modelagem, por ser de fcil compreenso e apresentar poucos conceitos.

Usaremos a notao grfica original de Peter Chen com mnimas adaptaes e extenses e
comentrios da Metodologia Case, James Martin. Para montar um modelo necessrio estudar
detalhadamente os conceitos:

ENTIDADE
As entidades so o conjunto de objetos de mesma natureza, com as mesmas caractersticas ou
atributos, abrigados sob um nome genrico. Entidade algo que desempenha papel especfico no
sistema que est sendo modelado; algo sobre o qual se deseja guardar informaes. A existncia
e a identificao de uma entidade dependem inteiramente do contexto em que ela estiver inserida.

Uma entidade pode ser: um objeto real, como livro, mquina, lugar, etc;
Uma pessoa, como empregado, contribuinte, cliente, aluno, etc;
Um conceito abstrato, como curso, conta, etc;
Um acontecimento, uma situao em que algo est ocorrendo ou est planejado, como fornecimento
de encomenda, casamento, etc;

Representao de uma entidade


Deve-se utilizar nomes breves e objetivos que identifiquem facilmente o contedo da entidade
associada, sempre no singular; nome deve ser um ou mais substantivos, em caso de nome
composto por mais de uma palavra utilizar o separador _ (underline) e no utilizar preposies, ou
seja, em vez de HISTORICO_DE_COMPRA, utilizar HISTORICO_COMPRA.

Classificao das Entidades


Entidade forte ou primria: So entidades de dados que possuem grau de independncia com
relao a existncia e identificao.

Entidade fraca ou dependente: Sua existncia depende da existncia de outra entidade, dita
forte.

Exemplos: A Entidade BANCO uma entidade forte (no depende de ningum). A Entidade
AGENCIA depende dela).

A Entidade DISCIPLINA uma entidade forte e a Entidade TURMA a Entidade fraca da tabela
Disciplina. (a existncia da primeira tabela dependente da segunda)

Entidade associativa: Resulta da associao de duas ou mais entidades. Exemplo:


PUBLICACAO_AUTOR concebida da existncia da entidade PUBLICACAO e AUTOR.

6
Administrao de Banco de Dados I

ATRIBUTOS
Atributos so informaes referentes a uma entidade que necessitam ser conhecida ou at mesmo
armazenadas. Atributos descrevem uma Entidade pela qualificao, identificao, quantificao ou
expresso de estado da Entidade. O que descreve uma Entidade?

No caso de uma pessoa, um funcionrio de um banco por exemplo, quais so os dados importantes
que devero ser mantidos?
FUNCIONARIO (matricula, nome, endereo, telefones, dataNascimento)

Atributos representam um tipo de descrio ou detalhe, no uma ocorrncia ou exemplo.

Classificao dos Atributos


Atributo Chave: Identifica unicamente as instncias das entidades do modelo;

Atributo Simples ou no chave: so os descritores, representa caractersticas simples;

Atributo Composto: tem outros atributos aninhados (subatributos);

Atributo Multivalorado: Abriga vrios valores para uma nica instncia de uma entidade;

Atributo Derivado: Pode ser calculado a partir dos demais atributos da entidade;

Representao de um atributo
Nome de um atributo deve ser sempre no singular, no colocar acentuao;
Utilizar nomes breves e objetivos que identifiquem facilmente o contedo do atributo;

Se uma entidade tm atributos multivalorados temos de criar uma tabela com o atributo determinante
dessa entidade e o atributo multivalorado ou se isso no se justificar definir um nmero fixo para
esse atributo e desdobr-lo nesse nmero de colunas.

ClientesTel (num_cliente, telefones) Clientes (num_cliente, nome, tel1, tel2)

Se uma entidade tm atributos compostos temos de criar na tabela dessa entidade colunas
referentes a esse atributo.

Clientes(N-contri, Nome, Telf1,Telf2, Rua, Cidade,Informaes)

Figura 3 -Exemplo de atributo composto

7
Administrao de Banco de Dados I

IDENTIFICAR E MODELAR ENTIDADES


Seguir os passos seguintes para identificar e modelar Entidades a partir de um conjunto de notas
feitas atravs de entrevistas:

Examinar todos os substantivos. So coisas de significncia ao negcio?


Determine um nome para cada Entidade.
Possui informaes de interesse para a Entidade que necessitam ser conhecidas ou guardadas?
Cada ocorrncia da Entidade pode ser identificada unicamente? Qual atributo ou atributos servem
como identificador nico?
Enumere exemplos, ocorrncias, justificando os atributos levantados anteriormente. Por exemplo,
Pedro, Luana, Vanessa so todos empregados.

DISTINGUIR ATRIBUTOS DE ENTIDADES


Se um Atributo tem Atributos de sua propriedade ento ele realmente uma Entidade.
Todas as Entidades so substantivos, mas nem sempre todos os substantivos so Entidades.

CARACTERSTICAS ENTIDADES CARACTERISTICAS ATRIBUTOS

Qualquer objeto significante que possui Qualifica uma entidade


informaes que devem ser guardadas

Possuiu um ou mais atributos No possui atributos de sua propriedade

Pode ter mltiplas ocorrncias Tem um nico valor para cada


associadas com outras entidades via um ocorrncia da entidade(no pode ter
relacionamento grupos de repetio)

Se uma entidade no tem atributos, ela Se um atributo possui atributo. Ele


pode ser um atributo e no uma entidade uma Entidade ou no tem significncia
alguma.

Todo atributo multivalorado, torna-se uma Entidade

ANALISAR E MODELAR ATRIBUTOS


Identificar um atributo canditado;
Associar cada Atributo com uma Entidade;
Nomear o Atributo
Determinar a opcionalidade do Atributo;
Validar o Atributo, ver se realmente um Atributo ou no uma Entidade;
Ver a possibilidade de quebrar em vrios Atributos
Verificar que um Atributo possui valore singulares;
Verificar que um Atributo no um dado derivado.

8
Administrao de Banco de Dados I

OPCIONALIDADE DE UM ATRIBUTO [case/ PeterChen]


Obrigatrios: Um valor dever ser conhecido para cada ocorrncia da Entidade. [*/ (1,1)]

Opcionais: Um valor pode ser conhecido para cada ocorrncia da Entidade. [o/ (0,1)]

IDENTIFICADORES NICOS PARA UM ATRIBUTO


Um identificador (UID) qualquer combinao de Atributos e/ou Relacionamentos que serve para
identificar unicamente cada ocorrncia de uma Entidade. Cada ocorrncia de Entidade deve ser
identificada unicamente. [case]
# nico
#* nico e obrigatrio #*1

RELACIONAMENTOS
Um relacionamento pode ser entendido como uma associao entre instncias de Entidades devido
a regras de negcio. Normalmente ocorre entre instncias de duas ou mais Entidades , podendo
ocorrer entre instncias da mesma Entidade (auto-relacionamento).

Por que o relacionamento necessrio ?


Quando existem vrias possibilidades de relacionamento entre o par das entidades e se deseja
representar apenas um;
Quando ocorrer mais de um relacionamento entre o par de entidades;
Para evitar ambiguidade;
Quando houver auto-relacionamento;

Com a evoluo e a criao de ferramentas CASE, foram criadas outros tipos de notao.
Engenharia de Informaes foi criado na dcada de 80 por James Martin. A maioria das
ferramentas case de mercado no disponibilizam o tipo de notao Peter Chen.

Representao grfica (Peter Chen)


Entidades: Representada atravs de um retngulo

Atributos: conforme figura5

Relacionamento: Representada atravs de um segmento de reta ligando as classes cujos objetos


se relacionam. Representadas atravs de um losango. Utilizar um verbo que identifique claramente o
relacionamento existente;

9
Administrao de Banco de Dados I

Grau de Relacionamento
O numero de conjuntos de entidades que participa de um conjunto de relacionamento tambm o
grau desse conjunto de relacionamento. Um conjunto de relacionamento binrio de grau dois; um
relacionamento ternrio de grau trs. O mais comum o binrio.

Ternrio Binrio

Representao grfica (Metodologia Case)


Entidade: Representada atravs de um retngulo com bordas arredondadas;

Atributos: Representados dentro do retngulo.

Relacionamento: Representada atravs de um segmento de reta ligando as classes cujos objetos


se relacionam. Utilizar um verbo que identifique claramente o relacionamento existente de ambos os
lados.

DEPARTAMENTO SETOR
gerencia
est subordinado
cod_depto cod_setor

nome_depto nome_setor

Comparao entre representaes

Vide exemplo do atributo composto na figura 1


Figura 5

10
Administrao de Banco de Dados I

Exemplo de um projeto de Banco de Dados


Entrevista: Sou gerente de uma empresa de treinamento que ministra vrios Cursos de carter tcnico.
Ministramos vrios cursos, que so identificados por um cdigo, nome e preo. Os cursos VB com
SQLServer2008, Delphi com Oracle, Java e O.O. so alguns dos nossos cursos mais populares. A
durao de cada curso pode variar de cinco a dez dias. Um instrutor pode ensinar vrios cursos. Robert,
Pedro e Rosimery so alguns de nossos instrutores. Mantemos aqui o nome e o telefone de cada instrutor.
A gente cria um curso e aloca um instrutor. Os alunos (clientes) podem participar de vrios cursos e,
vrios deles o fazem. O Joseph Brito, da SCA Informtica, assiste a todo curso que oferecemos. Alm do
nome, mantemos tambm o nmero do telefone dos alunos. Alguns de nossos alunos e instrutores no
possuem telefone

Modelar o negcio: 1 Passo- identificao das possveis Entidades, Atributos e


Relacionamentos (Desenvolver o MER simples)

Peter Chen

Metodologia Case

Ministrado por INSTRUTOR


CURSO

Cod_depto
Cod_depto

O instrutor de Nome_depto
Nome_depto

Frequentado por
Participante de

ALUNO

Cod_depto

Nome_depto

11
Administrao de Banco de Dados I

CAPTULO 3 CONCEITOS : RESTRIES DE INTEGRIDADE E ATRIBUTOS DE RELACIONAMENTO

RESTRIES DE INTEGRIDADE
As restries de integridade no banco de dados:
Integridade -> correo, consistncia e segurana dos dados armazenados.
Os aspectos de integridade bsica do modelo relacional esto associados aos conceitos de chave de
acesso. Ou seja, garantir a integridade de um esquema relacional significa garantir o acesso
individualizado a todas as ocorrncias de uma tabela, assim como garantir relacionamentos vlidos e
condizentes com a realidade.

Tipos de chave de acesso:


CHAVE PRIMRIA (primary key pk) : Principal chave de acesso a uma tabela. No permite
duplicidade, visa manter a unicidade e consistncia dos dados de uma tabela.

CHAVE COMPOSTA OU CONCATENADA: corresponde combinao de duas ou mais chaves, e


pode ser necessria para eliminar a ambiguidade, formando um identificador nico;
Quando um nico atributo da Entidade/Objeto de Dados no consegue personaliz-la, h a
necessidade da juno com outros atributos para este objetivo. Este conjunto de atributos forma
ento uma chave que consegue personalizar a Linha da Entidade/Objeto de Dados. Esta chave
primria especial tem o nome de chave concatenada ou composta.

CHAVE NICA (chave candidata) : Alm da chave primria, uma tabela pode possuir quantas
chaves nicas forem necessrias.

CHAVE SECUNDRIA: a chave auxiliar de acesso a uma tabela. A chave secundria tambm
possui ndices relacionados utilizados em campos onde se efetua constante pesquisa de acesso.
No precisam ser necessariamente nicos.

CHAVE ESTRANGEIRA (foreign key fk): Permite o acesso e a validao de outras tabelas. Essa
chave permite que se estabeleam os relacionamentos em um banco de dados. A chave estrangeira
deve ser compatvel com sua correspondente em outra tabela, isso garante a integridade referencial.

Caracterizam as restries nas quais os relacionamentos entre entidades esto submetidos (regras
do negcio).

Exemplo:

Todo empregado deve estar lotado num departamento

Cada aluno deve ser matriculado em um ou mais cursos

Toda Nota Fiscal deve ter pelo menos um item discriminado

O esquema de Entidade Relacionamento de uma empresa pode definir certas restries, as quais o
contedo do banco de dados deve respeitar. Isso feito utilizando o Mapeamento de Cardinalidade:
expressa o nmero de entidades as quais outra entidade pode estar associada via um conjunto de
relacionamentos.

12
Administrao de Banco de Dados I

GRAU DE CARDINALIDADE
O grau de cardinalidade representa a quantidade de ocorrncias de cada entidade que esto
envolvidas no relacionamento. Podem ser:

Em um projeto de BD usada somente duas cardinalidades mnimas: a cardinalidade mnima 0 e a


cardinalidade mnima 1.

Cardinalidade Mnima: especifica se a participao de todas as ocorrncias das entidades no


relacionamento obrigatria ou opcional.

A cardinalidade mnima 1 recebe a denominao de associao obrigatria.


A cardinalidade mnima 0 recebe a denominao de associao opcional.
A cardinalidade mnima em um Diagrama anotada junto a cardinalidade mxima.

Cardinalidade mxima: indica a qtde. mxima de ocorrncias de entidades que podem estar
associadas a uma ocorrncia da outra entidade (1 ou N).

Um_para_Um (1:1) - Uma entidade em A est associada no mximo a uma entidade em B, e uma
entidade em B est associada a no mximo uma entidade em A.

Um_para_Muitos (1:N) - Uma instncia de uma entidade A est associada a qualquer nmero de
instncias da entidade B. Porm, uma instncia da entidade B pode estar associada, no mximo, a
uma instncia da entidade A.

Muitos_para_Um (N:1) - uma instncia da entidade A est associada a uma instncia de B. Porm,
uma instncia de B pode estar associada a qualquer nmero de instncias de A.
Muitos_para_Muitos(M:N) - uma instncia da entidade A est associada a qualquer nmero de
instncias da entidade B, e vice-versa.

O uso de zero (0:1) ou (0:N) indica a totalidade do relacionamento.

13
Administrao de Banco de Dados I

Exemplos:

Pode haver um empregado que esteja alocado a uma mesa.


Pode haver uma mesa que no esteja sendo alocada por nenhum empregado.
Um empregado est alocado a uma, e somente uma mesa.

Pode haver um cliente que esteja associado a vrios pedidos.


Pode haver um cliente que no esteja associado a pedido algum.
Um pedido est associado a um, e somente um cliente.

Representao Crows Foot James Martin


A barra indica que o Relacionamento com a
entidade B faz parte do UID (identificador
nico) da entidade A.

Entidade A Entidade B

ATRIBUTOS DE RELACIONAMENTOS
Normalmente ocorrem quando duas ou mais entidades esto relacionadas, e necessrio manter
informaes sobre esta associao.
Atributos de relacionamentos so normalmente assinalados em relacionamentos muitos para muitos.
Nunca assinalamos atributos em relacionamentos 1-1 ou 1-N.

identificao da existncia de um atributo:

14
Administrao de Banco de Dados I

fixa-se uma instncia da uma das entidades, e observa-se o valor do atributo para cada mudana
de instncia na outra entidade.
se o valor do atributo mudar, ento ele no pertence entidade que foi fixada.

Para melhor entendimento, a quem pertence o atributo CONDIES = PREO + QUANTIDADE +


PRAZO ?

PREO, QUANTIDADE e PRAZO, no podem pertencer a PRODUTO, pois se fosse assim TODOS
os FORNECEDORes deveriam praticar o mesmo preo.

PREO, QUANTIDADE e PRAZO, no podem pertencer a FORNECEDOR, pois se fosse assim


TODOS os PRODUTOS de um FORNECEDOR teriam o mesmo preo.

Os atributos no pertencem nem a PRODUTO nem a FORNECEDOR, mas so relevantes para o


FORNECE. Ento, so do relacionamento.

Exemplo de Entidade, Atributos, Relacionamentos e Atributos de Relacionamentos:

(Peter Chen)

15
Administrao de Banco de Dados I

CAPTULO 4 IDENTIFICAR RELACIONAMENTOS

IDENTIFICAR E MODELAR RELACIONAMENTOS


Analisar e modelar Relacionamentos:
Determine a existncia de relacionamentos entre as entidades;
D um nome a cada relacionamento identificado;
Determine a opcionalidade em cada direo do relacionamento;
Determine a cardinalidade (grau) em cada direo do relacionamento;
Leia e valide os relacionamentos identificados.

Aps identificados todas as entidades e atributos, vamos melhorar o entendimento de


relacionamento

DETERMINE A EXISTNCIA DE UM RELACIONAMENTO


At que voc tenha prtica na identificao de relacionamentos, pode ser til uma matriz de
relacionamentos. Essa matriz nada mais que a relao de todas as entidades em linha e coluna.
Na interseco das entidades, voc deve identificar se h relacionamento. Se houver, coloque o
verbo que
caracteriza o relacionamento. Assim:

NOMEAR O RELACIONAMENTO
Nomear cada direo de um Relacionamento. (voz ativa e voz passiva).

Pergunte um nome do Relacionamento:


Como que a Entidade A est relacionada para a Entidade B?
Uma Entidade A nome relacionamento a uma Entidade B.
Como que a Entidade B est relacionada para uma entidade A?
Uma Entidade B nome Relacionamento a uma Entidade A.

Exemplo:
Considerar o relacionamento entre departamento e empregado.

COMO QUE UM DEPARTAMENTO EST RELACIONADO A UM EMPREGADO?


CADA DEPARTAMENTO RESPONSVEL POR UM EMPREGADO.

16
Administrao de Banco de Dados I

COMO QUE UM EMPREGADO EST RELACIONADO A UM DEPARTAMENTO?


CADA EMPREGADO ATRIBUDO A UM DEPARTAMENTO.

Usar uma lista de nomes de Relacionamento para auxiliar em nomeao de Relacionamentos.


Baseado Em Base Para
Descrio De Para
Operado Por Operador para
Representado Por Representao De
Responsvel Por Responsabilidade De
Pertence a Possui

Evite nomes genricos. Relacionado a, Associado com

DETERMINAR A OPCIONALIDADE DE UM RELACIONAMENTO


Questione a opcionalidade de um Relacionamento?
Deve a Entidade A ser nome do Relacionamento Entidade B? (Sempre?)
Deve a Entidade B ser nome Relacionamento Entidade A?

Exemplo:
DEVE UM EMPREGADO SER ATRIBUDO A UM DEPARTAMENTO? Sempre?
EXISTE ALGUMA SITUAO EM QUE O EMPREGADO NO DEVER SER ATRIBUIDO
A UM DEPARTAMENTO?
NO UM EMPREGADO SEMPRE DEVE SER ATRIBUDO PARA UM DEPARTAMENTO!

DEVE UM DEPARTAMENTO SER RESPONSVEL POR UM EMPREGADO?


NO, UM DEPARTAMENTO NO TEM DE SER RESPONSVEL POR UM EMPREGADO. ELE
PODE SER RESPONSVEL.

DETERMINAR O GRAU DE UM RELACIONAMENTO


Pergunte o grau de Relacionamento?
Pode a Entidade A ser nome do relacionamento mais que uma Entidade B?
Pode a Entidade B ser nome do Relacionamento mais que uma Entidade A?

Exemplo:
PODE UM EMPREGADO SER ATRIBUDO A MAIS QUE UM DEPARTAMENTO?
NO, UM EMPREGADO PODE SER ATRIBUDO A SOMENTE UM DEPARTAMENTO.

PODE UM DEPARTAMENTO SER RESPONSVEL POR MAIS QUE UM EMPREGADO?


SIM, UM DEPARTAMENTO PODE SER RESPONSVEL POR UM OU MAIS EMPREGADOS.

VALIDAR O RELACIONAMENTO
Ler em voz alta o Relacionamento.
A leitura do Relacionamento deve ter senso com relao ao negcio.
Exemplo:
CADA EMPREGADO DEVE SER ATRIBUDO A UM E SOMENTE UM DEPARTAMENTO.
CADA DEPARTAMENTO PODE SER RESPONSVEL POR UM OU MAIS EMPREGADOS.

Devemos evitar dados derivados, pois so dados redundantes que podem gerar inconsistncias
no banco de dados. Relacionamento 1:1 so raros (pode ser a mesma entidade)

17
Administrao de Banco de Dados I

CAPTULO 5 RELACIONAMENTOS REFLEXIVOS E EXTENSES DO MODELO E-R

AUTO-RELACIONAMENTO (REFLEXIVO OU RECURSIVO)


Um relacionamento recursivo uma relao entre uma Entidade ela mesma. No exemplo:
Cada empregado pode ser supervisionado por apenas um e somente um empregado.
Cada empregado pode ser gerente de um ou mais funcionrios.

(Peter Chen) (Case).

ESPECIALIZAO E GENERALIZAO (SUPERCLASSES E


SUBCLASSES, SUPERTIPO E SUBTIPOS)

A generalizao difere dos demais relacionamentos (entidade fraca, n-rios etc.) porque a primeira
se trata de um relacionamento entre entidades.
Atributos e operaes e relacionamentos so herdados pelas entidades filhas.

18
Administrao de Banco de Dados I

DEPARTAMENTO

COOPERATIVA

DOMNIO
A noo de domnio de um item de dado assemelha-se noo de domnio de um conjunto na
matemtica. um conjunto de regras de validao do negcio, restries de formatos e outras
propriedades que se aplicam a um grupo de atributos.
Por exemplo: Uma lista de valores (F, M para sexo, por exemplo); uma faixa de valores ([1,12])
para ms, por exemplo).
O domnio definido uma nica vez no dicionrio de dados (banco de dados especificamente criado
para guardar as definies dos dados e diagramas relacionados no banco de dados) e cada atributo
ser associado ao seu respectivo domnio.

TABELA
Objeto criado para armazenar os dados fisicamente. Os dados so armazenados em linhas
(registros) e colunas (campos). Os dados de uma tabela normalmente descrevem um assunto tal
como clientes, vendas, etc. Quando transporta ao modelo fsico, uma tupla equivale a uma registro
ou linha da tabela.

19
Administrao de Banco de Dados I

CAPITULO 6 PROJETO LGICO DE BANCO DE DADOS

PROJETO LGICO DE BANCO DE DADOS


Quando da concluso do modelo de dados da rea de negcio, ou seja, identificadas todas as
entidades e atributos, devemos iniciar o trabalho de modelagem de dados. Essa atividade deve ser
iniciada com a aplicao de inspeo para a eliminao das redundncias, e das tcnicas de
normalizao, que sero introduzidas adiante. Em seguida, inicia-se o processo de identificao dos
relacionamentos e das cardinalidades.

Com a concluso da modelagem inicial, vamos dar incio ao projeto inicial de Banco de Dados.
O projeto de Banco de Dados realizado durante o estgio de Projeto do Ciclo de Desenvolvimento
e realizado concorrentemente com projetos de aplicaes.

O projeto de Banco de Dados realizado em duas atividades distintas:

1. Transcrever o Modelo ExR para Tabelas Relacionais para produzir um projeto inicial.
2. Redefinir projeto inicial para produzir um projeto completo de banco de dados.

Documentar para cada tabela Relacional em um formulrio de Tabela, seguindo os passos:

Transcrever simples Entidades para Tabelas;


Transcrever Atributos para colunas e documentar exemplos dados;
Transcrever identificadores nicos para Primary Keys;
Transcrever Relacionamento para Foreign Keys;
Escolher opes de Arco (Explcito ou Genrico FK);
Escolher opes de Subtipo (tabelas simples ou tabelas separadas).

PRIMARY KEY PK (CHAVE PRIMRIA)

FOREIGN KEY FK (CHAVE ESTRANGEIRA)

NOT NULL - NN (NO NULA, ou seja no pode estar vazio, o zero um alfanumrico e
espao um caractere para o banco de dados)

NICA - U (NICA, ou seja as informaes no podem repetir na coluna especificada)

Toda Primary key deve ser obrigatoriamente No Nula e nica

Nem toda coluna nica uma chave primria

20
Administrao de Banco de Dados I

Metodologia Case

FUNCIONARIO DEPARTAMENTO
#* id #* cdigo_depto
* nome * nome
o celular

Tabela: FUNCIONARIO

Nome da Coluna id nome celular Cod_depto

Tipo de Chave PK FK

nico/ Nulo NN.U NN NN

101 Maria 7058-3166 10

Dados Simples 102 Joo 10

Peter Chen

Nome da Coluna id nome sobrenome Id_conjuge

Tipo de Chave PK FK

nico/ Nulo NN.U NN U

7450 Mary Smith 5579

Dados Simples 5579 Bill Jones 7450

21
Administrao de Banco de Dados I

CAPTULO 7 - O QUE NORMALIZAO DE TABELAS?

NORMALIZAO DE TABELAS
Normalizao um conjunto de regras para minimizar redundncia de dados.
Redundncia de dados causam problemas de integridade. Atualizaes e delees podem no ser
aplicadas de forma consistente para todas as cpias dos dados causando inconsistncias de dados.
Normalizao auxilia na identificao de Entidades, Relacionamentos e tabelas faltantes ou
ausentes.

APLICAO DAS FORMAS NORMAIS

Primeira Forma normal


A normalizao da tupla de forma que o relacionamento entre sua chave e os seus atributos seja
unvoca, ou seja, para cada chave h a ocorrncia de uma e somente uma informao de cada
atributo.

CONCLUSO: Uma tabela est na 1FN se nenhum dos seus atributos tem domnio multivalorado.

OBJETIVO: Evitar que se tenha de reservar espaos para armazenar dados multivalorados, sendo que
o espao pode ser desperdiado em um registro e se insuficiente em outro.

UTILIZAO: Projetam-se os atributos com domnio multivalorado para fora da tabela, levando um
atributo (geralmente a chave da tabela original) como elo para refazer a ligao e recuperar o
contedo da tabela original. PKFK / PK

Segunda Forma normal


A normalizao da tupla que j submetida a primeira forma normal, apresenta chave concatenada
que se relaciona de forma integral com todos os seus atributos.

CONCLUSO: Uma tabela est na 2FN quando est na 1FN e seus atributos dependem
funcionalmente da totalidade da chave ou do atributo determinante. A 2FN aplica-se a tabelas onde a
chave (atributo determinante) composta por mais de um atributo

OBJETIVO: Evitar que se mantenham informaes sobre um conjunto que tem interseco com o
conjunto representado na tabela, mas possui existncia independente. Alm da maior ocupao de
espao, a redundncia aumenta a possibilidade de inconsistncia.

UTILIZAO: Projetam-se os atributos que dependem funcionalmente da parte da chave para fora da
tabela, levando parte da chave que determina como elo para refazer a ligao e recuperar o
contedo da tabela original. PKFK / PKFK

22
Administrao de Banco de Dados I

Terceira Forma normal


Nenhuma coluna no chave pode ser funcionalmente depende de qualquer outra coluna no chave.
Todo atributo no chave depende funcional e diretamente da chave primria.

CONCLUSO: Uma tabela est na 3FN quando est na 2FN e no h dependncia funcional transitiva
entre seus atributos. Dependncia funcional transitiva a situao em que um atributo depende de
outro e este segundo depende de um terceiro.

OBJETIVO: Separar subconjuntos incertos em um subconjunto e evitar redundncias nas informaes.


Alm da repetio dos dados, a possibilidade de deteriorao da qualidade de informao aumenta
muito.

UTILIZAO: Projetam-se os atributos que dependem transitivamente da chave para fora da tabela,
levando o seu determinante direto como elo para refazer a ligao e recuperar o contedo da tabela
original. Dados de outra tabela que no seja identificada pela PK cria uma nova tabela.

Pode-se normalizar durante a modelagem de dados. dito que uma tabela est normalizada
quando atende at a 3FN, porm se houver necessidade aplicar a 4FN e 5FN.

4FN Quarta Forma Normal


4FUma tabela no deve possuir mais de uma D F Multivalorada.

Forma normal de boyce/ codd (FNBC)


As definies da 2fn e 3 fn, desenvolvidas por Codd, no cobriam certos casos. Essas inadequaes
foram apontadas por Raymond Boyce em 1974. Os casos no cobertos pelas definies de Cood
somente ocorrem quando trs condies aparecem juntas:

A entidade tenha vrias chaves candidatas;

As chaves candidatas sejam concatenadas (mais de um atributo);

As chaves concatenadas compartilhem pelo menos um atributo comum.

Uma entidade est na FNBC se e somente se todos os determinantes forem chaves candidatas.

Exemplo:

Entidade Cliente (cod_cliente, nome_cliente)

Entidade Agencia (cod_agencia, nome_agencia)

Entidade Emprstimo (cod_agencia, cod_cliente, nr_emprestimo, valor_emprestimo)

Aplicando a FNBC , teremos ento a tabela Emprstimo da seguinte maneira:

Entidade Emprstimo (cod_agencia, nr_emprestimo, valor)

Entidade Devedor (cod_cliente, nr_emprestimo)

23
Administrao de Banco de Dados I

Exemplo:

No normalizado:

1 FN

2 FN

3 FN

Passando para a 4FN:

A tabela a seguir NO est na 4FN: Passando para 4FN:

24
Administrao de Banco de Dados I

DESNORMALIZAO
Desnormalizao significa que voc propositadamente no efetuou o design do banco de dados at
a 3 Forma Normal. Isto feito visando maximizar a performance ou para simplificar a manipulao
dos dados para o usurio final. Sempre que voc desnormalizar um banco de dados, voc deve
estar disposto a perder os benefcios ganhos atravs da 3 Forma Normal.

Nota: Voc deve iniciar a partir da 3 FN. Se o problema com performance continuar, volte para a 2 FN ou
1FN. Tenha em sua mente que quando voc desnormaliza um banco de dados, voc o faz para uma aplicao
especfica, por exemplo um Data Warehouse.

Performance
Um banco de dados na 3 FN pode requerer mais joins para processar queries que na 2 ou 1
FN. Estes joins adicionais podem ser dispendiosos em termos de CPU ou I/O de disco.

Tcnicas
Dados Duplicados Podem reduzir o nmero de joins requeridos para processar uma querie,
assim reduzindo o consumo de CPD e I/O de disco.
Dados Resumidos Melhoram o desempenho de uma querie por reduzir ou eliminar os passos
requeridos para a sumarizao dos dados.
Partio Horizontal a diviso de uma tabela em duas novas tabelas levando em considerao o
nmero de registros, assim reduzindo o nmero de linhas por tabela.

Partio Vertical a diviso de uma tabela em duas novas tabelas levando em considerao o
nmero de colunas, assim reduzindo o nmero de colunas por tabela.

25

You might also like