Projetos de Bancos de Dados Relacionais Álvaro Vinícius de Souza Coêlho [email protected]

Projetos de Bancos de Dados Relacionais

Álvaro Vinícius de Souza Coê[email protected]

Bancos de Dados Relacionais

• Um conjunto de dados organizados em Tabelas e estruturas auxiliares– Tabelas: Linhas e Colunas– Estruturas Auxiliares: Para acesso rápido a

dados: Clusters, Índices, Segmentos de RollBack.

• As estruturas auxiliares são concebidas para o melhor funcionamento do banco – Administração (BDA)


• Projetando a estrutura de tabelas• A partir do MER• A princípio, deseja-se que toda entidade

seja uma tabela– Atributos Colunas– Linhas Instâncias


• Por exemplo, a entidade Aluno se torna uma tabela da seguinte forma:

Aluno-Matrícula-Nome-Endereço

Create Table Aluno (matricula char(11),nome varchar2(50),endereçovarchar2(100)

)


• Tabelas, em geral, devem ter uma ou mais colunas escolhidas como chave primária– Chave Primária: Coluna cujo valor não pode se

repetir numa tabela, e que identifica unicamente uma instância

– Não pode ser nulo– Pode ser natural ou artificialmente construída

para o sistema


• Por exemplo, numa tabela Automóvel a chave primária pode ser a coluna Placa ou Renavan a depender da abordagem.

• Numa tabela de Matrículas, a identificação de uma instância só poderá ser feita sabendo-se o aluno e a turma em que ele está matriculado


• Escolhida a chave primária de cada tabela, alguns aspectos devem ser observado a respeito dos relacionamentos:– Relacionamentos 1 para 1 – Uma chave segue,

como única (alternativa) em outra tabela– Relacionamentos 1 para N – Uma chave segue

para outra tabela– Relacionamentos N para N – Uma nova tabela é

criada


• Relacionamentos 1 para 1• Uma instância de uma entidade relaciona-se

a uma e somente uma instância de outra e a recíproca é verdadeira

• Por exemplo: Cliente e Cônjuge


• Relacionamentos deste tipo são feitos com:– Cópia da chave primária de uma tabela para a

outra (surge uma nova coluna dita chave estrangeira)

– Restrição de Unicidade da Chave Estrangeira


• Note, no exemplo, que se a chave estrangeira não for única (unique, em SQL) a relação não é de 1 para 1

Matrícula NomeP01 JoséP02 CarlosP03 MariaP04 Éverton

Cod Máquina OperadorM01 Olivetti P01M02 Xerox P03

M03 HP P02M04 IBM P04


• Obrigatoriedade: Deve-se permitir ou não que a chave estrangeira seja nula a depender da obrigatoriedade ou não da relação

Matrícula NomeP01 JoséP02 CarlosP03 MariaP04 Éverton

Cod Máquina OperadorM01 OlivettiM02 Xerox P03

M03 HPM04 IBM P04


• Deve-se escolher como tabela mandatória (que exporta a chave) a que possui maior independência semântica– O lado não-obrigatório da relação (se houver)– A entidade menos dependente da outra, caso

contrário


• Relacionamentos 1 para N• Uma instância de uma entidade se relaciona

com várias instâncias da outra, mas a recíproca não é verdadeira

• Por exemplo Automóvel e Proprietário


• Relacionamentos deste tipo são feitos com:– Cópia da chave primária de uma tabela para a

outra (surge uma nova coluna dita chave estrangeira)

– Sem restrições de unicidade


• Note, no exemplo, que se a chave estrangeira for única a relação não é de 1 para N

Matrícula ProfessorP01 DegasP02 DiegoP03 Vânia

Cod Disciplina ProfessorD01 BD P01D02 IA P02

D03 LabBD P01D04 RecComp P03


• Obrigatoriedade: Deve-se permitir ou não que a chave estrangeira seja nula a depender da obrigatoriedade ou não da relação

Matrícula ProfessorP01 DegasP02 DiegoP03 Vânia

Cod Disciplina ProfessorD01 BD P01D02 IA P02

D03 LabBDD04 RecComp P03


• Observações gerais para relacionamentos 1 para 1 e 1 para N– A tabela que exporta a chave nunca é

obrigatoriamente relacionada (a não ser via programação)

– A tabela que recebe a chave estrangeira pode ser dependente da relação se esta coluna for obrigatória


• Relações de dependência ocorrem quando– Uma instância de uma entidade é parte de outra,

e não tem sentido sem ela – Setor e Empresa– Uma instância de uma entidade não pode existir

sem a ocorrência de outra – Automóvel e Proprietário

– Boas modelagens especificam casos assim


• Relacionamentos N para N• Uma instância de uma entidade se relaciona

com várias instâncias da outra, e a recíproca é verdadeira

• Por exemplo Cliente e Conta


• Relacionamentos desse tipo são feitos com– Criação de uma tabela (chamada tabela-

relacionamento)– Esta tabela recebe chaves estrangeiras das duas

entidades– Restringindo-se a unicidade (chave primária) ao

par das chaves relacionadas (talvez com mais alguma(s) coluna(s))


• Por exemplo:

Cod DescriçãoP01 BielaP02 VirabrequimP03 PistãoP04 Mancal

Cod DescriçãoF01 GP PeçasF02 MM MotoresF03 KV Válvulas

Pç FornP01 F01P02 F02P03 F01P04 F02P01 F02P03 F02P04 F01


• Relações mostradas:– O fornecedor GP Peças fornece Biela, Pistão e Mancal– O fornecedor MM Motores fornece Biela, Virabrequim,

Pistão e Mancal– KV Válvulas não oferece nada– Biela, Pistão e Mancal são ofertados por MM Motores

e GP Peças– Virabrequim é ofertado apenas por MM Motores


• No exemplo anterior a chave primária da tabela-relacionamento é composta pelas duas chaves estrangeiras que ela recebe.

• Com efeito não há sentido registrar-se mais de uma vez que MM Motores oferece Biela


• Em alguns casos, porém, é necessário que a chave primária de tabelas deste tipo abranja mais que as chaves estrangeiras:


• Exemplo:Mat AlunoM01 JoséM02 MariaM03 JulioM04 Esmeralda

Cod DisciplinaD01 IAD02 BDD03 Redes

Mat Disc Nota SemM01 D01 4.5 00.1M02 D02 10.0 00.2M01 D01 7.2 01.2M02 D03 9.0 01.1M01 D02 7.0 00.2M03 D01 4.5 01.2M03 D03 5.0 02.1M02 D03 8.0 01.2


• A chave primária não pode ser o par (Mat, Disc) porque ele pode se repetir até que o aluno tenha uma nota maior ou igual a cinco.– Não pode igualmente ser a tripla (Mat, Disc,

Nota)– Pode ser (Mat, Disc, Sem) ou as quatro colunas

(por considerações de performance)


• Atributos de Relacionamentos– Muitas vezes os relacionamentos possuem

atributos– Nos casos de relacionamentos 1 para 1 e 1 para

N os atributos devem seguir o caminho da chave, e migrar para uma das tabelas

– Nos casos de relacionamentos N para N estes ficarão alojados na tabela-relacionamento – e possivelmente farão parte da chave primária


• Relacionamentos de Agregação• Alguns relacionamentos especiais entre

entidades, chamados de Agregação ou Todo-Parte, indicam que uma entidade é parte de outra– Por exemplo, no domínio do RH de uma

universidade, Professor e Departamento.


• Estes relacionamentos são modelados como uma relação de 1 para N, sendo mandatória (que exporta a chave) a tabela Todo.– Professor tem uma coluna indicando o

departamento onde está alocado


• Caso se estabeleça uma relação de dependência da parte com o todo (uma classe não pode existir sem a outra) deve-se exigir a obrigatoriedade da chave estrangeira– Ex: Vinho e Vinícola


• Relacionamentos de Generalização• Muitas vezes as entidades se associam

formando uma relação de Generalização ou Especialização (ou Supertipos e Subtipos)

• Neste caso há uma entidade que contém os atributos que serão compartilhados pelas demais


• Por Exemplo as entidades Automóvel, Automóvel Passeio e Automóvel Utilitário

Automóvel Passeio

Automóvel Utilitário

Automóvel


• Neste exemplo, os atributos que AutomóvelPasseio e AutomóvelUtilitário têm em comum são colocados na entidade Automóvel

• Cada subtipo fica com seus atributos específicos


• Automóvel– Ano, Fabricante, Placa

• AutomóvelPasseio– NumPortas, ArCond(s/n)

• AutomóvelUtilitário– PesoMaximo, VolMaximo


• Como se projeta?• Duas alternativas

– Criar uma tabela com todos os atributos• A identificação do tipo é feita com um flag

– Criar todas as tabelas e relacioná-las entre si por chave estrangeira


• Uma única tabela• Terá tantas colunas quantas forem

necessárias para mapear todos os atributos• Uma coluna a mais identificará o sub-tipo

que de fato está sendo considerado


• No exemplo:– Automóvel(Ano, Fabricante, Placa, NumPortas,

ArCond(s/n), PesoMaximo, VolMaximo, Tipo(P,U))

– Tipo identifica se é de Passeio ou utilitário• Se o tipo for P as colunas PesoMaximo, VolMaximo

devem ser nulas• Se o tipo for U as colunas NumPortas, ArCond(s/n)

devem ser nulas


• Em SQL:– Check((Tipo = ‘U’ and NumPortas is null and ArCond is null) or

(Tipo = ‘P’ and PesoMaximo is null and VolMaximo is null))


• Tabelas relacionadas• Duas alternativas: Chave exportada do

supertipo para o subtipo ou o contrário


• Exportando a chave do supertipo para o subtipo

• Cria-se uma tabela com colunas para todos os atributos do supertipo

• Cria-se tabelas com colunas para todos os atributos dos subtipos, acrescidas de uma chave-estrangeira referenciando o Supertipo


• No exemplo:– Automóvel(Ano, Fabricante, Placa)– AutomóvelPasseio(NumPortas, ArCond(s/n),

Placa)– AutomóvelUtilitário(PesoMaximo,

VolMaximo, Placa)


• Exportando a chave do subtipo para o supertipo• Cria-se uma tabela com colunas para todos os

atributos do supertipo, mais tantas colunas quantos forem os subtipos possíveis – serão chaves estrangeiras

• Cria-se tabelas com colunas para todos os atributos dos subtipos, acrescidas de uma chave primária gerada pelo sistema


• No exemplo:– Automóvel(Ano, Fabricante, Placa, AutPasseio,

AutUtilitário)– AutomóvelPasseio(Cod, NumPortas,

ArCond(s/n), Placa)– AutomóvelUtilitário(Cod, PesoMaximo,

VolMaximo, Placa)


• Observar que em Automóvel(Ano, Fabricante, Placa, AutPasseio, AutUtilitário) as chaves estrangeiras AutPasseio e AutUtilitário são mutuamente exclusivas – Quando uma tiver valor a outra será nula e vice-versa)


• Em SQL:– Check(((AutPasseio is null and AutUtilitario is not null) or

(AutPasseio is not null and AutUtilitario is null))

Bancos de Dados Relacionais• Resumindo, para se implementar a

generalização em Bancos de Dados Relacionais há as seguintes opções:

Uma Tabela Várias Tabelas

Generalização

Chave SuperTipo Chave SubTipo

Projeto de BDs Relacionais

FIM!

“Não é que eu tenha medo de morrer. É que eu não quero estar lá na hora que isso acontecer”

Woody AllenEscher

Documents

Projetos de Bancos de Dados Relacionais Álvaro Vinícius de Souza Coêlho [email protected]