#PÚBLI

CA#

Aula 2
Projeto conceitual de banco de dados
O projeto conceitual de um banco de dados é uma fase muito importante no
planejamento. As metodologias de projeto de banco de dados estão
fortemente relacionadas com as diretrizes da engenharia de software, no
entanto, a modelagem conceitual está realizada n o nível mais alto e elementar
que permite envolver o cliente, pois seu foco é discutir os aspectos do negócio
do cliente e não das tecnologias envolvidas.

Abstração

Há um conceito em modelagem de dados que diz respeito à possibilidade de

se criar uma visão abstrata de dados para os usuários. Tal abstração de dados
diz respeito à ocultação de detalhes mais técnicos da estrutura e do
armazenamento, dando destaque apenas aos recursos essenciais para melhor
entendimento desses dados, ou seja, é possível descrever um banco de dados
sem se preocupar com as especificidades e detalhes de software ou de
hardware que o suportarão.

Essa visão pode ser dívida em níveis de abstração: um nível mais elevado para
visão do usuário, outro com uma visão intermediária mais voltada para a
implementação e outra com uma visão para o nível físico, com menor de
abstração.

Seguindo essa linha, um projeto de banco de dados pode ser estruturado de

uma forma hierárquica conhecida como modelos de dados. Para Elmasri e
navathe(2011), modelos de dados podem ser usados para descrever a
estrutura de um banco de dados, sendo classificados em três modelos
distintos: conceitos, lógico e físico.

Modelo conceitual

Modelo de dados de alto nível ou projeto conceitual. É o modelo mais próximo

do cliente e usuário final. Os elementos entidades, atributos e relacionamentos
são alguns dos itens definidos nesta fase. Um exemplo deste modelo é o
chamado Modelo Entidade-relacionamento, conhecido como MER. Assim
sendo, o MER é apenas um modelo conceitual, mas possui um diagrama

#PÚBLI
CA#
#PÚBLI
CA#

conceitual, uma ferramenta chamada DER (diagrama entidade-

relacionamento), que permite a representação gráfica do modelo conceitual.

Modelo Lógico

Modelo de dados representativo, de implementação ou projeto lógico. Os

dados são mostrados usando estrutura de registro. Os modelos de dados
relacional, hierárquico e de rede são exemplos deste modelo. O modelo lógico
é implementado com detalhes mais técnicos, levando em conta algumas
limitações e utiliza recursos como nomenclaturas e adequação de padrão.
Nesta faze, há a preocupação com itens do tipo, atributos do tipo chave,
normalização, integridade referencial. O modelo lógico é criado baseado na
modelagem de dados criada no processo anterior, ou seja, modelo conceitual.

Modelo físico

Modelo de dados de baixo nível ou projeto físico. Descreve os dados do

modelo anterior para armazenamento no computador, abrangendo o formato
dos registros e os caminhos de acesso aos dados. No modelo físico,
realizamos a modelagem física do modelo de banco de dados, sendo assim,
levamos em conta as limitações impostas pelo SGBD escolhido. Usamos uma
sequência de comandos executados em linguagem SQL (linguagem de
consulta estruturada), para a criação dos artefatos do banco de dados, como
exemplo criar tabelas, estruturas, ligações e finalmente a criação do banco de
dados. O modelo físico é criado baseado na modelagem de dados criada no
processo anterior, ou seja, modelo lógico.

#PÚBLI
CA#
#PÚBLI
CA#

Modelo entidade-relacionamento

O modelo entidade-relacionamento, conhecido como MER ou ER, é um modelo

de dados conceitual de alto nível. Essa é uma fase muito importante no
desenvolvimento de um projeto de banco de dados. Foi idealizado por Peter
Chen em 1976 e ainda é muito utilizado. Peter Pin-Shan Chen é professor
americano de ciência da computação, conhecido como criados do modelo
Entidade-relacionamento.

Apesar do modelo entidade-relacionamento (ou modelo E-R) não ser

implementado em SGBDs, tal como o modelo relacional, ele apresenta um bom
ponto de partida para a compreensão entre os elementos existentes em um
determinado contexto e as relações entre os mesmos. De certa forma, ele
antecede o projeto lógico que pode ser feito em um modelo relacional, o qual
através de regras para conversão pode ser montado a partir de um diagrama
E-R.

As vantagens da utilização do MER são muitas:

 Possui uma sintaxe robusta, permitindo a criação da

documentação das informações do cliente de maneira precisa e
clara.
 Facilita a comunicação, permitindo que o cliente e o usuário
entendam o modelo
 Facilidade para criar e manter o modelo
 Pode ser integrado com várias aplicações e projetos diferentes.
 Oferece independência de implementação, pois sua utilização é
universal e não está vinculada a um tipo de banco de dados.

Conceitos básicos

Entidades

Em um banco de dados, podemos ter uma ou várias entidades. As entidades

são artefatos ou objetos que organizam as informações que serão
armazenadas e manipuladas em um banco de dados.

Uma entidade é uma coisa ou um objeto do mundo real que pode ser
identificada de forma unívoca em relação a todos os outros objetos. Deve

#PÚBLI
CA#
#PÚBLI
CA#

possuir identificação distinta e com um significado próprio. Também são

descritas como objetos da realidade na qual se deseja manter informações.
Normalmente é representado por um substantivo na descrição do negócio.

Normalmente, uma entidade é também entendida como uma lista ou

tabela que receberá registros sobre um determinado assunto. Uma entidade
também pode ser vista como sendo pessoal (empregado,
funcionário), local (endereço, cidade, estado), objeto (produto, maté-
ria-prima), evento (venda, registro, cadastramento) ou entidade conceitual
(seção, conta). A representação é feita através de retângulos
contendo no seu interior o nome das entidades.

Assim, quando simbolizamos a entidade “funcionário”, não quer dizer

que se trata de um funcionário específico, mas de um conjunto de
funcionários, portanto ela pode ser valorada pelos elementos do conjunto que
representa.

Atributos

Atributos são as características de uma entidade. Os atributos definem as

características das entidades, constituem em sua essência. Eles podem ter
uma faixa de valores ou de domínio e, ainda, caracterizarem-se por serem
simples ou composto. Devemos sempre procurar construir atributos simples.

Podemos ter atributos identificadores ou, então, chaves que indiquem uma
entidade sem ambiguidade, bem como atributos básicos ou derivados.

#PÚBLI
CA#
#PÚBLI
CA#

Os atributos podem ser:

 Univalorado ou Multivalorado: no caso de o atributo assumir um

único valor ou quando assume mais de um valor;
 Vazio: quando um atributo em determinado momento não
assumir um dado específico ou ser desconhecido
 Chave ou identificador: um atributo pode unicamente
representar uma instância de uma entidade, situação em que ele
é simbolizado como identificador ou chave mediante o nome
sublinhado ou com o círculo do atributo preenchido.

Existem vários tipos de chaves para as entidades:

 Chave primária: seu valor identifica cada registro de forma única;

 Chave composta: é formada por mais de um atributo
 Chave candidata: é o atributo com possibilidade de vir a se tornar uma
chave primária.
 Chave estrangeira: quando o atributo de uma entidade é a chave
primária de outra entidade com a qual se relaciona.

Relacionamento

Quando a entidade possui elos com uma ou várias entidades, chamamos

esses elos de relacionamento. Esse relacionamento é realizado entre atributos
coirmãos das diferentes entidades, desde que tais atributos sejam de mesma
natureza e contexto.

Através de um relacionamento, duas ou mais entidades podem estar

associadas, situação em que elas são representadas por losangos
ligando uma entidade a outra.

Os relacionamentos podem ter um nome descrito no losango. Nesse

exemplo, temos duas entidades envolvidas: “cliente” – representando o
conjunto de pessoas que são vistas como clientes de uma empresa e “pedido”,

#PÚBLI
CA#
#PÚBLI
CA#

sendo este o conjunto de pedidos que são efetuados pelo cliente na empresa.
O relacionamento denominado “carteira” refere-se à associação de elementos
da entidade “pedido” que, por sua vez, estão associados a seus respectivos
elementos representados pela entidade “clientes”.

Há também a possibilidade de um auto-relacionamento, quando uma entidade

está associada a um ou mais elemento da mesma entidade. Outro item
importante no relacionamento são as cardinalidades envolvidas nessa relação.

Cardinalidade

Em um relacionamento, a cardinalidade se refere ao grau do vínculo que

uma entidade mantém com outra entidade. A cardinalidade ou multiplicidade
define a quantidade de elementos de uma entidade associada com a
quantidade de elementos de outra entidade. Podemos ter relações de 1:1 (um
para um), 1:N (um para N) e N:N (N para N)

A cardinalidade apresentada acima tem o relacionamento 1:N, onde um

cliente pode possuir vários pedidos, porém um pedido pode ser somente de um
único cliente. Então, que do lado da entidade “cliente” aparece o número “1” e
do lado do “pedido” aparece a letra “N”.

A leitura da cardinalidade é feita de maneira cruzada, ou seja, a

cardinalidade próxima à entidade da esquerda é referente á relação com a
entidade da direita. Para a interpretação da cardinalidade, um artifício que
auxilia na identificação da mesma é a elaboração de um diagrama de
ocorrências. Num diagrama de ocorrências, representamos as entidades e

#PÚBLI
CA#
#PÚBLI
CA#

relacionamentos, na forma de conjuntos, bem como os elementos pertencentes

a cada conjunto.

Dessa forma, os pares c2, p2 e c2, p3 indicam que um cliente pode

possuir
mais de um pedido. Porém, não ocorre um par, onde, para um mesmo
pedido, tenhamos mais de um cliente.

No caso de um relacionamento com cardinalidade N:N, entre as

entidades “funcionário” e “projeto”, denominado “alocação”, um funcionário
pode estar alocado em mais de um projeto (veja o
caso dos pares f2, p2 e f2, p3), e um projeto, por sua vez, pode ter mais
de um funcionário (ver os pares f1, p1 e f3, p1).

#PÚBLI
CA#
#PÚBLI
CA#

Para o caso de um relacionamento de cardinalidade 1:1, no exemplo a

seguir, temos as entidades “empregado” e “cargo”, e o relacionamento
“ocupação” indicando a associação entre as entidades. Dessa forma as
ocorrências do diagrama indicam que um empregado pode ocupar apenas um
cargo e vice-versa.

Quanto à denominação de um relacionamento, não há uma regra para

atribuirmos um nome específico. Em vez de “ocupação”, poderíamos
denominar de “cargo do empregado” ou “cargo_empregado”.

Tipo de relacionamento

#PÚBLI
CA#
#PÚBLI
CA#

Um relacionamento pode ser, de acordo com o número de entidades

que participam na relação, unário, binário ou ternário.

1. Relacionamento binário(associando duas entidades)

2. Relacionamento unário: é identificado como um auto-
relacionamento, onde a entidade se relaciona com ela mesma

Vejamos o caso de um produto em fabricação. De acordo com o grau de

montagem, um conjunto de peças é montado de forma a produzir uma peça
mais complexa, mas que não é ainda o produto final. Essa peça complexa se
junta a outras peças ou a matérias-primas, de forma, então, a compor o
produto final. Todas essas peças são, aqui, representadas por uma entidade
“peça”, sendo o relacionamento denominado “parte de”.

Um relacionamento ternário implica a associação de três entidades ao

mesmo tempo, que pode ser exemplificado por uma associação “funcioná-rio-
área-projeto”; desde que um funcionário trabalhe apenas em uma área, porém
em mais de um projeto. O relacionamento ilustrado mostra como ficaria esta
associação e o relacionamento “ocupação”.

#PÚBLI
CA#
#PÚBLI
CA#

O diagrama de ocorrências mostra, agora, não mais os “pares”, mas

“ternos” ou “triplas” mostrando as instâncias associadas nesse modelo. Veja
que os ternos f2, p2, a1 e f2, p3, a1 validam a cardinalidade de 1:1 para a
associação “funcionário-área” e 1:N para a associação “funcionário-projeto”.

Podemos também representar relacionamentos contendo mais de três

entidades, o que caracteriza relacionamentos quaternários e subsequentes.

#PÚBLI
CA#
#PÚBLI
CA#

Exercícios

1- Porque a abordagem modelo entidade-relacionamento é útil

para a modelagem de banco de dados?
2- Quais os elementos que podem constar em um diagrama E-R?
3- Faça um diagrama E-R de uma biblioteca

#PÚBLI
CA#