Modelos de Dados
Álvaro Vinícius de Souza Coêlho
[email protected]
Modelos de Dados
• Um BD provê abstração de dados (o seu
esquema).
• O modelo de dados é a principal ferramenta
de abstração.
• É um conjunto de conceitos que são usados
para descrever a estrutura de um BD (Tipos
de Dados, Relacionamentos, Restrições
Semântica, etc.).
Modelos de Dados
• De modo geral há três níveis de
classificação do modelo de dados: Objetos,
Registros e Físico.
• O modelo baseado em objetos é o mais
abstrato.
– Não confundir com Orientação a Objetos.
– Voltado para a compreensão e o significado dos
dados.
Modelos de Dados
• O modelo baseado em objetos é o mais
abstrato.
– Expressam relacionamentos complexos entre os
dados.
– Mostram o mundo real em toda a sua
complexidade (de dados).
– Ignoram aspectos relacionados à
implementação.
Modelos de Dados
• O modelo baseado em objetos é o mais
abstrato.
– Modelo de Entidades e Relacionamentos – uma
coleção de entidades (objeto distinguível de
outro pelos seus atributos) e relacionamentos
(associação entre várias entidades).
• Definido na Engenharia de Informação e muito
empregado na modelagem Estruturada (e mesmo na
modelagem Orientada a Objetos).
Modelos de Dados
• O modelo baseado em objetos é o mais
abstrato.
– Modelo Conceitual – Coleção de classes de
objetos, com atributos e métodos, e associações
entre elas. As associações podem ser por
mensagens (um objeto solicita algo a outro) ou
por ocorrência (um objeto tem a ocorrência de –
se relaciona a – outro).
• Definido nas modelagens orientadas a objetos e
empregado em UML.
Modelos de Dados
• O modelo baseado em objetos é o mais
abstrato.
– Existem outros modelos, tanto estruturados
quanto orientados a objeto. Mas expressam as
mesmas características.
Modelos de Dados
• Modelo baseado em registros
– Construído a partir do modelo de objetos.
– Voltados para o entendimento dos registros dos
dados.
– Expressam relacionamentos simples entre os
dados.
– Não representam fatos complexos.
Modelos de Dados
• Modelo baseado em registros
– Dependentes da arquitetura do BD: Voltados
para a implementação.
– Diagrama Relacional, para o modelo relacional,
representando dados e relacionamentos por um
conjunto de tabelas com colunas únicas
(chave).
Modelos de Dados
• Modelo baseado em registros
– Diagrama Relacional
C#
Cliente
C#
C#
Conta
C
CT#
Modelos de Dados
• Modelo baseado em registros
– Diagrama de estrutura de dados, para o modelo
em redes, tem os dados representados por
coleções de registros e os relacionamentos são
representados por ligações (ponteiros). O BD é
organizado como uma coleção de grafos.
Modelos de Dados
• Modelo baseado em registros
– Diagrama de estrutura de dados
Nome
Rua
Cliente
Cidade
Número
Saldo
Conta
Modelos de Dados
• Modelo baseado em registros
– Diagrama de estrutura, para o modelo
hierárquico, com representação similar ao
modelo de redes, porém o BD é organizado
como coleções de árvores.
Modelos de Dados
• Modelo baseado em registros
– Diagrama de estrutura
Nome
Rua
Número
Cidade
Saldo
Cliente
Conta
Modelos de Dados
• Modelo Físico, que é a visão propriamente
dos dados (exemplos, evidentemente).
• Os modelos em registros físicos são parte
integrante de um estado específico do
projeto do BD.
Modelos de Dados
• Aqui, ater-nos-emos ao modelo de objetos.
• Existem regras precisas que permitem que,
a partir do modelo de objetos, sejam
gerados o modelo de registros e o modelo
físico do BD. Mas tal transformação é de
pouco interesse.
Modelos de Dados
• Vai-se tomar por guia o MER (Modelo de
entidades e relacionamentos).
• Não há nenhum motivo em especial,
– O interesse é estudar a modelagem de dados
– O Modelo Conceitual da UML (bem como todos os
modelos de classes em Orientação a Objeto) é mais
amplo
– Engloba os métodos e as conexões de mensagens que
não são escopo de uma modelagem de dados.
Modelos de Dados
• Assim, entre estudar um modelo conceitual
incompleto, por abstração dos métodos, e um
MER integral, optou-se pela segunda alternativa.
• Vale a crítica: Modernamente há uma preferência
pelo modelo conceitual de classes, mas em muitos
tipos de sistemas (principalmente quando o BD é
relacional) o MER é ainda muito empregado.
Modelos de Dados
• No decorrer desta será mostrado, sempre
que surgirem, as semelhanças e
equivalências do MER com o modelo
conceitual.
• O principal: Os conceitos de organização
dos dados e as estratégias para o
estabelecimento de relações (ou
associações) entre eles permanece.
Modelos de Dados
• O que é um MER.
– Um diagrama composto por entidades e
relacionamentos
Modelos de Dados
• O que é um MER.
– Um MER possui quatro aspectos principais a
serem estudados
• Tipos de objetos (ou classes, segundo a UML).
• Relacionamentos (ou associações, segundo a UML).
• Indicadores associativos de tipos de objetos (ou
classe associativa, segundo a UML).
• Indicadores de supertipos/subtipos (superclasse/
subclasse, segundo a UML).
Modelos de Dados
• Os tipos de objetos, num MER, são
representados por retângulos.
– Cada tipo de objeto exerce um papel, isto é, são
relevantes para o funcionamento do próprio
sistema.
– São descritos por um ou mais elementos de
dados, chamados atributos (como no Modelo
Conceitual).
Modelos de Dados
• Os tipos de objetos, num MER, são
representados por retângulos.
– Por exemplo, um objeto cliente pode ter os
atributos Nome, Endereço, Limite de Crédito e
Telefone.
– Os atributos são os descritores de cada instância
do tipo de objeto (ou o objeto propriamente
dito, segundo a UML).
Modelos de Dados
• Os tipos de objetos, num MER, são
representados por retângulos.
Cliente
Conta
Modelos de Dados
• Os tipos de objetos, num MER, são
representados por retângulos.
– A colocação ou não dos atributos é opcional
• Diferentes autores preconizam diferentes
procedimentos (mesmo em UML, de acordo com o
nível de abstração necessário pode-se suprimir
alguns ou todos os atributos).
• Aqui, por uma questão de simplicidade, serão
omitidos do modelo.
Modelos de Dados
• Os tipos de objetos, num MER, são
representados por retângulos.
– Mas o levantamento cuidadoso dos atributos é
imperativo à modelagem de dados
– “Que informações desta entidade (ou desta
classe) o sistema deverá, ainda que numa
eventualidade, se recordar?”.
Modelos de Dados
• Os tipos de objetos, num MER, são representados
por retângulos.
– Isso leva a um conjunto bastante razoável de atributos.
– O próprio decorrer do processo de modelagem vai
desvendar novos atributos, inicialmente esquecidos.
– Não obstante, o seguinte questionamento também deve
ser feito para cada atributo “descoberto”: “Essa
informação precisa estar registrada ou pode ser
derivada de alguma outra?”.
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– Um relacionamento expressa um conjunto de
conexões entre objetos.
– Pode representar uma relação entre zero ou
mais ocorrências de um objeto, e zero ou mais
ocorrências de outro objeto.
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– O nome do relacionamento é uma palavra que
indique a relação que de fato existe entre os
objetos relacionados.
– Deve ser colocado no interior do losango.
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
Cliente
Possui
Conta
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– Pode haver mais de um relacionamento entre
objetos:
Possui
Conta
Cliente
Movimenta
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– Pode, também, haver relacionamentos entre
mais de um objeto.
Cliente
Conta
Possui
Agência
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– Cardinalidade e opcionalidade.
– Um relacionamento deve mostrar:
• As quantidades que podem estar envolvidas
• A opcionalidade ou não de haver objetos
relacionados nas extremidades do relacionamento.
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– De modo geral, encontra-se 3 tipos de
cardinalidade
• 1 para 1.
– Cada instância de tipo de objeto se relaciona com apenas
uma instância do outro e vice-versa.
– Representa-se escrevendo o número 1 ao lado de ambos os
objetos relacionados.
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
Cliente
1
1
Possui
Conta
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– Essa relação é lida: “Um cliente possui apenas
uma conta e uma conta pertence a (é possuída
por) apenas um cliente”.
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– 1 para Muitos
– Uma instância de um objeto se relaciona com
várias ocorrências do outro, mas a recíproca
não é verdadeira.
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
Cliente
1
N
Possui
Conta
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– Representa-se escrevendo o número 1 do lado
do objeto cuja instância ocorre uma vez
(chamado dominante) e N do outro lado
– Esta relação é lida: “Um cliente pode possuir
muitas contas, mas uma conta pertence a apenas
um cliente”.
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– Muitos para Muitos
– Cada ocorrência de um objeto se relaciona com
várias ocorrências do outro e vice-versa.
– Representa-se escrevendo N ao lado dos dois.
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
Cliente
N
N
Possui
Conta
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– Esta relação é lida como: “Um cliente pode
possuir muitas contas e uma conta pode
pertencer a muitos clientes”.
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– A opcionalidade (ou obrigatoriedade, a
depender do autor)
• Eventualmente, um objeto só pode existir se o seu
par-relacionado também existir.
• Isso pode ser verdade para ambos os lados de um
relacionamento, ou só para um deles, ou para
nenhum dos dois.
Modelos de Dados
• Os relacionamentos, no MER, são representados
por losangos.
– No exemplo de clientes e contas,
• pode-se estabelecer que um cliente só possa estar cadastrado
no BD se ele possuir ao menos uma conta.
• Isso, porém, pode não ser boa idéia.
• Por outro lado, não é admissível o registro de uma conta sem
que se saiba o seu titular.
• Aqui parece mais razoável impor uma obrigatoriedade.
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– O relacionamento pode ser lido da seguinte
forma: “Um cliente pode possuir zero ou mais
contas, mas uma conta deve pertencer a um ou
mais clientes”
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– A opcionalidade é representada por um círculo
colocado ao lado do objeto relacionado, se ele
não for obrigatório.
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
Cliente
N
N
Possui
Conta
Modelos de Dados
• Os relacionamentos, no MER, são
representados por losangos.
– Existem, de acordo com diferentes autores,
muitas formas diferentes de representar a
cardinalidade e a opcionalidade.
– Esta é apenas uma delas, escolhida por
apresentar maior semelhança com a linguagem
natural e requerer menos recursos gráficos.
Modelos de Dados
• Os indicadores de tipos de objeto associativos
aparecem quando surgem objetos que funcionam
como relacionamento
– São relacionamentos sobre os quais é desejável guardar
alguma informação
– Na notação que apresenta os atributos, é suficiente
coloca-los no relacionamento.
– Aqui, entretanto, será utilizado outro mecanismo.
Modelos de Dados
• Os indicadores de tipos de objeto
associativos
– Imagine-se um relacionamento muitos para
muitos entre clientes e itens, chamado Compra.
– Agora, percebe-se que há alguns atributos
específicos deste relacionamento (Data, Tipo de
pagamento...) que precisam ser guardados pelo
sistema.
Modelos de Dados
• Os indicadores de tipos de objeto
associativos
– O Tipo de Dados Compra, associado ao
relacionamento Compra é então criado da
seguinte forma
Cliente
N
N
Compra
Item
Modelos de Dados
• Os indicadores de tipos de objeto
associativos
– Esta notação é dotada de uma semântica muito
particular, pois mostra que o relacionamento
também é um tipo de objeto
– O relacionamento ficou “sem nome”, indicando
que toda a informação que ele contém está
inclusa no tipo de objeto Compra
Modelos de Dados
• Os indicadores de tipos de objeto associativos
– Quando se implementa relações muitos para muitos em
bancos de dados relacionais, usa-se uma tabela
(também conhecida como tabela de-para) fazendo às
vezes da relação.
– Esta tabela traz as chaves primárias das duas tabelas
que representam as entidades para formar a relação da
maneira apropriada.
Modelos de Dados
• Os indicadores de tipos de objeto associativos
– É importante ressaltar que tal artifício é feito em nível
de projeto, no modelo de registros, e não deve ser
expresso aqui.
– Chaves primárias e estrangeiras, por não serem
considerados atributos (são apenas mecanismos de
construção de relacionamentos) devem ser
desconsideradas. Não se tratará, portanto, de um tipo de
objeto associativo.
Modelos de Dados
• Os indicadores de supertipos/subtipos são
objetos que se agrupam em uma ou mais
subcategorias.
– No MER são interligados por um
relacionamento
– No modelo conceitual, são ligados por
generalização
Modelos de Dados
• Os indicadores de supertipos/subtipos
– O modelo conceitual estabelece explicitamente
que subclasses tem uma relação de herança
com as classes-mãe.
– O MER também incorpora o conceito de
herança, embora não preveja a herança de
métodos, como o modelo conceitual.
Modelos de Dados
• Os indicadores de supertipos/subtipos
– Recomenda-se que na nomenclatura do subtipo
também se faça uma alusão ao fato de se tratar
de uma especialização de um tipo adicional.
– Por exemplo, havendo um tipo para
automóveis, e subtipos para os automóveis de
passeio e utilitário, podem-se nomear esses
tipos, respectivamente: “Automóvel”,
“Automóvel Passeio” e “Automóvel Utilitário”.
Modelos de Dados
• Os indicadores de supertipos/subtipos
– Os supertipos se relacionam com os subtipos, e
a identificação do tipo-pai é feita com um traço
cortando a linha de relação que parte do
supertipo
Modelos de Dados
• Os indicadores de supertipos/subtipos
Empregado
Empregado
Horista
Empregado
Assalariado
Modelos de Dados
• Os indicadores de supertipos/subtipos
– Subtipos e supertipos são identificados são
identificados pelos seus atributos
– No exemplo, Nome, Endereço, Telefone e Data
de Nascimento são atributos de todos os objetos
do tipo Empregado
Modelos de Dados
• Os indicadores de supertipos/subtipos
– Mas Horas_Trabalhadas e Salário_Hora são
atributos que dizem respeito apenas a objetos
do tipo Empregado Horista
– Salário_Mês é atributo que só faz sentido ao
empregado assalariado
Modelos de Dados
• Os indicadores de supertipos/subtipos
– No processo de modelagem, se for percebida
uma intersecção entre os conjuntos de atributos
de dois (ou mais) tipos de objetos distintos, eles
são então candidatos a compor um conjunto
subtipo/supertipo.
Modelos de Dados
• Os indicadores de supertipos/subtipos
– Os objetos em estudo vão se alinhar como
subtipos
– Devem ser suprimidos os atributos em comum,
restando apenas os atributos disjuntos
Modelos de Dados
• Os indicadores de supertipos/subtipos
– O supertipo deverá ser criado, contendo estes
atributos comuns
– Estes atributos, portanto, ficam disponíveis para
todos os subtipos, por herança
Modelos de Dados
• Os indicadores de supertipos/subtipos
– Aqui fica a mais importante diferença entre o
MER e o Modelo Conceitual
– No MC a relação de classes/subclasses pode ser
estabelecida pelo compartilhamento de
atributos ou métodos
– No caso dos atributos de maneira bem
semelhante ao MER.
Modelos de Dados
• Os indicadores de supertipos/subtipos
– A diferença é que nos métodos pode-se
implementar conceitos de polimorfismo
– São escopo de um estudo sobre orientação a
objetos já que os métodos são processos,
extrapolando, portanto a modelagem de dados
Modelos de Dados
• Erros comuns
– A modelagem de dados é uma tarefa feita em
várias etapas, todas aperfeiçoando a anterior.
– É comum, e até natural, descobrir-se
imperfeições e erros no modelo, e partir-se para
as correções apropriadas.
Modelos de Dados
• Erros comuns
– Não há um modelo correto para um sistema. Há
modelos adequados ou inadequados
– Os erros mais comuns são basicamente de duas
categorias: Faltou objeto ou Sobrou objeto
Modelos de Dados
• Erros comuns
– Faltou objeto
• A identificação de supertipos a partir de subtipos
com atributos em comuns pode ter sido falha.
• É muito comum, em entrevistas com usuário ou em
documentações utilizadas como insumo de análise,
encontrar objetos aparentemente distintos que são na
verdade especialização de um supertipo.
Modelos de Dados
• Erros comuns
– Faltou objeto
• A identificação de “casos especiais” de tipos, que
tenham atributos, quebrando em subtipos
• É comum, também, não se perceber a princípio que
um determinado tipo de objeto possui uma
especialização relevante para o sistema, o que
forçaria este objeto a ser dividido em subtipos
Modelos de Dados
• Erros comuns
– Faltou objeto
– Ex:
– Um analista percebe a existência do tipo de objeto
Cliente, e não observa que existem atributos específicos
do cliente que compra com cartão de crédito e que
compra com dinheiro
– Outro pode perceber dois objetos distintos, um cliente
que faz compras com cartão e outro (um “comprador”)
que faz compras a dinheiro.
– Ambos cometeram uma falha.
Modelos de Dados
• Erros comuns
Cliente
Cliente
Cartão
Comprador
Dinheiro
Cliente
Cliente
Cartão
Cliente
Dinheiro
Modelos de Dados
• Erros comuns
– Faltou objeto
– Percepção de atributos inerentes a um
relacionamento, que não “chamaram a atenção”
numa vista preliminar.
Modelos de Dados.
FIM!
Di Cavalcanti
“A ciência não tem Pátria”
Louis Pasteur
“Mas as patentes, sim”
Anômimo