Você está na página 1de 15

AULA 1- 2 SEMESTRE

Projeto de implementação de banco de dados

Depois de pronto o modelo conceitual, o próximo passo é a criação do modelo


lógico, que envolve um diagrama com Modelo lógico de dados, alguns chama
de MLD, ou ainda representado na forma de tabelas simples com colunas e
tuplas relacionadas e o esquema relacional.

Durante a fase de implementação do banco de dados, pode ser necessário


realizar ajustes no modelo lógico ou até mesmo no modelo conceitual. Algumas
implementações do projeto logico se preocupam com detalhes provenientes do
sistema do gerenciador de banco de dados, que apesar de não ser utilizado
nessa fase, é desenvolvido com o foco no SGBD escolhido.

Mapeamento e adaptação do modelo conceitual para o lógico

Pode-se notar que:

 As entidades devem ser representadas em forma de tabelas (relação)


 Atributo identificador deve ser representado como chave-primária
 Atributos simples se tornam nomes de colunas das tabelas ou atributos
 Atributos compostos devem se tornar em vários atributos simples, com
uma coluna para cada atributo
 Atributos multivalorados podem ser mapeados de duas formas:
o Como n colunas, sendo n o número máximo de valores do
atributo
o Criando uma nova relação com os valores possíveis e uma chave
estrangeira

Formas de representação do modelo lógico

A seguir serão apresentadas várias formas de representação do modelo lógico.


Em uma implementação real, um ou todos os modelos poderão ser adotados.
Na figura acima vemos a representação do esquema relacional do modelo
conceitual descrevendo-o de maneira mais textual baseado na teoria dos
conjuntos. Perceba que cada relação possui seus atributos descritos e
diferenciados de acordo com suas características de chave-primária ou chave-
estrangeira.

O s campos sublinhados são campos-chave, atributos que iniciam com fk são


chaves-estrangeitas( fk- foreign key). Assim como as chaves-estrangeiras,
também as chaves primárias podem receber a notação pk(PK- primary key) ao
invés de sublinhado. No caso das chaves estrangerias, também é comum
acrescentar o nome da tabela a qual ela referência mesmo que seja de forma
abreviada e com a primeira letra em maiúsculo.

EX: fk_aluno_ra, indica uma chave estrangeira apontando para um atributo


chave RA de uma entidade aluno.

A figura acima apresenta todas as tabelas relacionadas. Perceba que os


campos chave das tabelas aluno e livros aparecem como chave estrangeria na
tabela requisição, que também possui sua própria chave primaria. As chaves
são elos dos relacionamentos, como podemos ver na figura apresentada.
Os campos demarcados por uma elipse são os atributos agregados
provenientes das relações solicita, devolve e contém do modelo lógico.

Esse modelo apresentado acima é uma alternativa ao primeiro modelo, com


implementação de quatro tabelas ao invés das três apresentadas
anteriormente. Nesse caso, a tabela movimento não possui uma chave
estrangeria RA do aluno por ser desnecessário, já que a tabela requisição já
possui essa informação e estão relacionadas.

Abaixo vai ser apresentados os diagramas criados automaticamente pelas


ferramenta case BRmodelo a partir do modelo conceitual apresentado
anteriormente. Vale ressaltar que mesmo tendo a opção automática de criação
do modelo lógico, é possível cria-lo do zero ou mesmo alterá-lo, independente
do modelo conceitual ser ajustado na ferramenta.

Diagrama a partir do modelo conceitual


Forma simplificada
Implementação de relacionamentos

O fator determinante para a tradução a adotar no caso de


relacionamentos é a cardinalidade mínima e máxima das entidades que
participam do relacionamento. Antes de detalhar a alternativa proposta para
cada tipo de relacionamento, apresentamos três formas básicas de tradução de
relacionamentos para o modelo relacional.

Tabela própria

Nesta tradução, o relacionamento é implementado através de uma


tabela própria. Esta tabela contém as seguintes colunas:

 Colunas correspondentes aos identificadores das entidades


relacionadas
 Colunas correspondentes aos atributos do relacionamento.

A chave primária desta tabela é o conjunto das colunas correspondentes


aos identificadores das entidades relacionadas. Cada conjunto de colunas que
corresponde ao identificador de uma entidade é chave estrangeira em relação
a tabela que implementa a entidade referenciada.

A tabela Atuação implementa o relacionamento ATUAÇÃO. A chave


primária da tabela é formada pelas colunas CodEng e CodProj, que
correspondem aos identificadores das entidades relacionadas (ENGENHEIRO
e
PROJETO). Cada uma destas colunas é chaves estrangeira das tabela que
implementa a entidade relacionada. A coluna Função corresponde ao atributo
do relacionamento.

Colunas adicionais dentro de tabela de entidade

A outra alternativa de implementação de um relacionamento é a inserção


de colunas em uma tabela correspondente a uma das entidades que participam
do relacionamento.

Esse tipo de tradução somente é possível quando uma das entidades


que participa do relacionamento tem cardinalidade máxima um (no caso
do exemplo, trata-se da entidade EMPREGADO). A tradução consta em inserir
na tabela correspondente à entidade com cardinalidade máxima 1 as seguintes
colunas:

 Colunas correspondentes ao identificador da entidade relacionada


(no caso do exemplo, o identificador da entidade
DEPARTEAMENTO); estas colunas formam uma chave
estrangeira em relação à tabela que implementa a entidade
relacionada - no caso do exemplo, a coluna CodDept
 colunas correspondentes aos atributos do relacionamento - no
caso do exemplo, a coluna DataLota.

Fusão de tabelas de entidades

A terceira forma de implementar um relacionamento é através da fusão


das tabelas referentes às entidades envolvidas no relacionamento. Esta
tradução somente pode ser aplicada quando o relacionamento é de tipo 1:1. A
tradução consta de implementar todos os atributos de ambas entidades, bem
como os atributos do relacionamento em uma única entidade.

Detalhes da implementação de relacionamentos

A regra específica que deve ser usada na tradução de um


relacionamento é determinada pelas cardinalidades mínima e máxima das
entidades envolvidas nos relacionamentos. A abaixo dá uma visão geral das
regras usadas. Para cada tipo de relacionamento a tabela mostra qual a
alternativa que deve
ser usada (alternativa preferida, indicada pelo símbolo ✔).

Para alguns tipos de relacionamentos há ainda segunda alternativa a ser


usada (indicada pelo símbolo +-), bem como uma alternativa que não deve ser
usada (indicada pelo símbolo ✕).
Relacionamento 1:1

Ambas entidade têm participação opcional

A imagem abaixo apresenta um exemplo de relacionamento 1:1 no qual


a participação de ambas entidades é opcional (a cardinalidade mínima de
ambas entidades no relacionamento é zero).

De acordo com a Tabela 5.1, a alternativa preferida de tradução de


relacionamentos é a inserção de colunas na tabela referente a uma das
entidades que participam do relacionamento. Como é um relacionamento 1:1,
qualquer das entidades que participam do relacionamento pode ser a
escolhida.

Neste esquema, as colunas referentes ao relacionamento estão


marcadas
em negrito. Trata-se de colunas referentes aos atributos de casamento, bem
como a coluna IdentH, chave estrangeira que implementa o relacionamento.
Neste caso, optou-se, arbitrariamente, por adicionar colunas à tabela Mulher.

Da mesma forma, poderiam ter sido adicionadas colunas (identificador


da
mulher e atributos de casamento) à tabela Homem.

A tabela que implementa o relacionamento é a tabela Casamento. Nesta


tabela, as colunas IdentH e IdentM são ambas chaves estrangeiras,
implementando desta forma a vinculação da linha de casamento às linhas de
homem e mulher correspondentes.

Como se trata de um relacionamento 1:1, tanto a


coluna IdentH quanto a coluna IdentM podem ser consideradas para a chave
primária. No exemplo, a coluna IdentM foi escolhida arbitrariamente como
chave primária, sendo IdentH uma chave alternativa.
A primeira alternativa é a preferida, pois minimiza a necessidade de
junções, já que os dados de uma pessoa (na opção escolhida a mulher) estão
na mesma linha que os dados do casamento.

A desvantagem da primeira alternativa e que pode levar à utilização da


segunda alternativa é a de basear-se no uso de colunas opcionais, isto é, no
uso
de colunas que admitem valores vazios (no exemplo, as colunas IdentH, Data
e Regime da tabela Mulher).

Esta alternativa transfere a responsabilidade pela verificação da


opcionalidade de campos do SGBD para os programas que atualizam o banco
de dados. No caso da tabela Mulher do exemplo, nas linhas que correspondem
a mulheres que não são casadas os campos correspondentes ao casamento
devem estar todos vazios.

Cabe observar que em alguns SGBD, que implementam restrições de


integridade (cláusula “Assertion” ou similar) é possível transferir ao SGBD a
responsabilidade pelo controle das colunas opcionais. Neste caso, a segunda
alternativa seria a preferida.

Uma entidade tem participação opcional e a outra tem participação


obrigatória

Outro tipo de relacionamento 1:1; é aquele no qual uma das entidades


tem participação obrigatória, enquanto que a outra entidade tem participação
opcional (a cardinalidade mínima de uma das entidades é um, a cardinalidade
mínima da entidade é zero).
Neste caso, a tradução preferida é através da fusão das tabelas
correspondentes às duas entidades. Alternativamente, poderia ser considerada
a tradução através da adição de colunas à tabela correspondente à entidade
com cardinalidade mínima 0. No caso do exemplo, a tradução resultaria no
esquema abaixo:

Ambas entidades têm participação obrigatória

O último tipo de relacionamentos 1:1 é aquele na qual ambas entidades


tem participação obrigatória no relacionamento (a cardinalidade mínima de
ambas entidades é um).

Neste caso, a tradução preferida é através da fusão das tabelas


correspondentes às duas entidades. Nenhuma das demais alternativas atende
plenamente. Em ambas alternativas, as entidades que participam do
relacionamento seriam representadas através de duas tabelas distintas.

Relacionamentos 1:n

No caso de relacionamentos 1:n, a alternativa preferida de


implementação é a de adição de colunas
Cabe observar que no caso particular deste exemplo, a coluna CódigoEd
da tabela Apartamento (que implementa o relacionamento do apartamento com
seu edifício), além de ser chave estrangeira, é também parte da chave
primária.

No caso de a entidade com cardinalidade máxima 1 ser opcional, isto é,


possuir cardinalidade mínima 0, poderia ser considerada uma implementação
alternativa. Um exemplo deste tipo de relacionamento é mostrado imagem
abaixo. A entidade VENDA está opcionalmente ligada a entidade
FINANCEIRA.

Para este tipo de relacionamento, pode ser usada alternativamente


implementação através de tabela própria. A implementação através de adição
de colunas à tabela de entidade Venda (implementação preferida) é a seguinte:
As colunas em negrito na tabela Venda implementam o relacionamento.
A implementação através de tabela própria (implementação alternativa) é
a seguinte:

A implementação por tabela própria tem duas desvantagens em relação


à implementação por adição de colunas:

 Operações que envolvem acesso a dados de uma venda e do


respectivo financiamento exigem junções. Na primeira alternativa,
isto não ocorre, já que os dados da venda e de seu financiamento
estão na mesma linha.

Sistemas de gerenciamento de banco de dados

Um sistema gerenciador de banco de dados- SGBD ou DBMS ( data base


management system em inglês) é um conjunto de programas interligados que
permite criar, manipular e manter banco de dados, garantindo a integridade e
segurança dos dados.

É um software que permite gerenciar os processos de definição, construção,


manipulação e compartilhamento de dados entre várias aplicações de usuários.
Definir um banco de dados implica em especificar a estrutura, os tipos de
dados e as restrições para os dados armazenados em um banco de dados.

Arquitetura de sistemas de banco de dados


Exercícios

1-Considere o banco de dados relacional definido parcialmente


abaixo (faltam as chaves da tabela Empregado):

Na tabela Empregado, tanto CodigoEmpregado quanto NoPIS-PASEP podem


ser chave primária. Qual você escolheria como chave primária? Porque?

2-Abaixo aparece um esquema parcial para um banco de dados


relacional. Identifique neste esquema as chaves primárias e chaves
estrangeiras:

Você também pode gostar