MDD -Aulas 01 e 02

Curso Superior de Tecnologia em BD
Modelagem de Dados
Aula 01
Revisão
Modelos de Dados
 Existem modelos para diferentes níveis de
abstração de representação de dados
– modelos conceituais
– modelos lógicos
– modelos físicos
2
Modelos de Dados Conceituais
 Representação com alto nível de abstração
– modelam de forma mais natural os fatos do mundo real, suas
propriedades e seus relacionamentos
– são independentes de BD
– preocupam-se apenas com a semântica da aplicação
– exemplo:
• modelo entidade-relacionamento
3
Modelos de Dados Lógicos
 Representa os dados em alguma estrutura (lógica)
de armazenamento de dados
– também chamados de modelos de BD
– dependente de BD
– exemplos
• modelo relacional (tabelas)
• modelos hierárquico
4
Modelos de BD (Lógicos)
 Apóiam:
– na especificação dos dados do modelo (DDL)
• dados, seus domínios e restrições
– na especificação de como manipular os dados (DML)
5
Modelos de BD (Físico)
 Possuem foco na:
–
–
–
–
–
–
Indexação e estrutura de arquivos
Transações e controle de concorrência
Otimização
Recuperação em casos de falhas
Mecanismos de proteção (segurança)
Partição e agrupamento de dados
6
Síntese dos conceitos
 Banco de dados (BD):
– conjunto de dados integrados que por objetivo atender a uma
comunidade de usuários.
 Modelo de dados:
– descrição formal das estruturas de dados para representação
de um BD; com suas respectivas restrições e linguagem para
criação e manipulação de dados.
 Sistema Gerenciador de banco de dados (SGBD):
– software que incorpora as funções de definição, recuperação e
alteração de dados em um BD.
7
Síntese dos conceitos
 Modelagem de dados:
– é a ação de representar/abstrair dados do minimundo com o
objetivo de criar projetos conceituais e lógicos de um BD.
– alguns autores incluem os projetos físicos como parte da
modelagem de dados, pelo fato de que as otimizações são
oriundas de análises do comportamento dinâmico do BD.
8
Síntese dos conceitos
 Projeto conceitual BD:
– ação que produz o esquema de dados abstratos que descreve
a estrutura de um BD de forma independente de um SGBD
(esquema conceitual).
 Projeto lógico BD:
– ação que produz o esquema lógico de dados que representa a
estrutura de dados de um BD em acordo com o modelo de
dados subjacente a um SGBD.
9
Síntese dos conceitos
 Projeto físico BD:
– ação que produz o esquema físico de dados a partir do
esquema de lógico de dados com a adição das estratégias de
otimização para manipulação das estruturas de dados. As
estratégias de otimização são dependentes dos fabricantes
dos SGBDs e de suas versões.
10
Modelo ER
 O Modelo Entidade-Relacionamento (MER):
– é um modelo de dados de alto-nível criado com o objetivo de
representar a semântica associada aos dados do minimundo.
– utilizado na fase de projeto conceitual, onde o esquema
conceitual do banco de dados da aplicação é concebido.
– Seus conceitos são intuitivos, permitindo que projetistas de
banco de dado capturem os conceitos associados aos dados
da aplicação, sem a interferência da tecnologia específica de
implementação do banco de dados.
11
Modelo ER
 O esquema conceitual criado usando-se o MER é
chamado Diagrama Entidade-Relacionamento
(DER).
MER: Conjunto de conceitos e elementos de
modelagem que o projetista de banco
de dados precisa conhecer.
DER: Resultado do processo de modelagem
executado pelo projetista de dados que
conhece o MER.
12
Notação do DER
Tipo de Entidade
Tipo de Entidade-Fraca
Tipo de Relacionamento
Tipo de Relacionamento de Identificação
Atributo
Atributo-Chave
Atributo-Parcial
Atributo Multivalorado
....
Atributo Composto
Atributo Derivado
R
E1
E1
1
R
R
N
(min, max)
E2
Participação Total de E2 em R
E2
Razão de Cardinalidade 1:N para E1 R E2
E
Restrição Estrutural (min, max) na participação de E em R
13
O DER do Sistema Companhia
Pnome
Mnome
Snome
Nome
Endereço
Número
Sexo
Nss
1
N
TRABALHA-PARA
Nome
Localização
Salário
EMPREGADO
DataInício
NúmeroDeEmpregados
DEPARTAMENTO
DataNasc
1
1
1
GERENCIA
supervisor
supervisionado
1
SUPERVISIONA
CONTROLA
Horas
N
N
M
N
1
TRABALHA-EM
DEPENDENTE-DE
PROJETO
Nome
Número
Localização
N
DEPENDENTE
Nome
Sexo
DataNasc
TipoRelação
14
Ferramentas disponíveis
 DBDesigner
Ferramenta de modelagem de banco de dados. Multiplataforma.
 MySQL Workbench
Ferramenta sucessora do DBDesigner. Somente para
Windows, por enquanto.
 SQL Power Architect
Ferramenta multi-plataforma, em Java.
 ERWin Data Modeler
Ferramenta comercial de modelagem de dados.
15
Ferramentas disponíveis
 PowerDesigner
Ferramenta comercial de modelagem de banco de
dados.
 WinRDBI
Ferramenta educacional para validação de consultas.
16
DBDesigner
17
DBDesigner
 É um software livre, licenciado sob a GPL;
 É multi-plataforma (sim, ele também roda no
Windows);
 Além de ser imbatível no uso com o MySQL,
também oferece suporte a outros bancos, como
Oracle, MS SQL Server, SQLite, e outros que
suportem acesso via ODBC;
 Permite engenharia reversa, gerando o modelo a
partir das tabelas do BD;
 Faz a sincronia no BD das alterações realizadas no
DER;
18
DBDesigner
 A interface com o usuário é muito bem elaborada,
tornando o seu uso bastante simples;
 Salva os arquivos em XML;
 Importa modelos gerados no ERWin (XML);
 Gera relatórios em HTML;
 Pode ser expandido através do uso de plugins;
 É muito bem documentado;
 O suporte realizado através do fórum do site do
DBDesigner é excelente.
19
DBDesigner
Para saber mais sobre o DBDesigner visite
http://www.fabforce.net/dbdesigner4/
20
MySQL Workbench
21
SQL Power Architect
22
ERWin Data Modeler
23
Sybase PowerDesigner
24
Transformação entre modelos
modelo ER
(nível conceitual)
Engenharia
reversa de BD
relacional
Projeto lógico
de BD
relacional
modelo relacional
(nível lógico)
25
Modelo Conceitual vs. Lógico
 Modelo Conceitual: Relacionamento “um-para-um”
 Contexto: Um produto tem estoque.
Produto
1:1
tem
1:1
Estoque
26
Modelo Conceitual vs. Lógico
 Modelo lógico: Relacionamento “um-para-um”
Produto
1:1
tem
PRODUTOS
Nome da tabela
codigo
nome
estoque
Chave primária
1:1
Estoque
Atributos
Como não nos interessa manter dados do estoque senão sua quantidade,
estoque não é uma entidade e por isso seus atributos (quantidade) são
incorporadas pela entidade produto.
27
Modelo Conceitual vs. Lógico
 Modelo Conceitual: Relacionamento “um-paramuitos”
 Contexto: Um departamento tem nenhum ou vários
funcionários, mas um funcionário pode pertencer a
somente um departamento.
Departamento
1:1
tem
0:N
Funcionário
28
Modelo Conceitual vs. Lógico
 Modelo Lógico: Relacionamento “um-para-muitos”
Departamento
1:1
DEPARTAMENTO
codigo
nome
descrição
tem
0:N
Funcionário
FUNCIONÁRIOS
matrícula
nome
cod_departamento (FK)
Quanto há um relacionamento "um-para-muitos", a entidade do lado "N" recebe
como atributo a chave primária da entidade do lado "um".
29
Modelo Conceitual vs. Lógico
 Modelo Conceitual: Relacionamento “muitos-paramuitos”
 Contexto: Um aluno tem aulas de nenhuma ou
várias disciplinas e uma disciplina é cursada por
nenhum ou vários alunos.
Aluno
0:N
cursa
0:N
Disciplina
30
Modelo Conceitual vs. Lógico
 Modelo Lógico: Relacionamento “muitos-paramuitos”
Aluno
ALUNO
matr_aluno
nome
descrição
0:N
cursa
ALUNO DISCIPLINA
matr_aluno (FK)
cod_disc (FK)
Descrição
0:N
Disciplina
DISCIPLINA
cod_disc
nome
cod_ (FK)
Num relacionamento "muitos-para-muitos", é preciso criar uma tabela
intermediária que terá como chave primária composta as chaves primárias das
outras duas tabelas.
31
Modelo Conceitual vs. Lógico
 Modelo Conceitual: Auto-relacionamento “um-paramuitos”
 Contexto: Um funcionário supervisiona nenhum ou
vários funcionários e um funcionário tem somente
um supervisor.
1:1
Funcionário
supervisiona
0:N
32
Modelo Conceitual vs. Lógico
 Modelo Lógico: Auto-relacionamento “um-paramuitos”
FUNCIONÁRIO
1:1
Funcionário
0:N
supervisiona
matr_func
nome_func
chefe_func (FK)
Descrição
A própria entidade recebe como atributo a sua própria chave primária.
33
Modelo Conceitual vs. Lógico
 Modelo Conceitual: Auto-relacionamento “muitospara-muitos”
 Contexto: Um aluno só poderá cursar a disciplina X
se tiver sido aprovado nas disciplinas A e B. E só
poderá cursar a disciplina Y se tiver sido aprovado
na disciplina A.
0:N
disciplina
Pré-requisito
0:N
34
Modelo Conceitual vs. Lógico
 Modelo Lógico: Auto-relacionamento “muitos-paramuitos”
DISCIPLINA
cod_disc
nome_disc
0:N
disciplina
Pré-requisito
PRE-REQUISITO
0:N
cod_disc_pre (FK)
cod_disc_pos (FK)
Descrição
No contexto, podemos ver que a disciplina A é pré-requisito de X e Y. E a
disciplina B é pré-requisito para X.
Nesse caso, criamos uma tabela que armazenará os relacionamentos entre as
disciplinas. E essa tabela terá como chave primária composta a chave primária da
35
outra tabela (duas vezes).
Modelo Conceitual vs. Lógico
 Modelo Conceitual: Relacionamento
“Generalização/Especialização”
 Contexto: Precisamos armazenar o código de identificação, cor e
capacidade de passageiros dos veículos que possuímos.Para os
veículos terrestres, é interessante armazenarmos a quantidade de
rodas. Para os aquáticos, o tamanho em pés. Para os aéreos, a
forma de propulsão (turbina, hélice, etc).
veículo
terrestre aquático
aéreo
36
Modelo Conceitual vs. Lógico
 Modelo Lógico: Relacionamento “Generalização/Especialização”
VEÍCULO
codigo
cor
qtde_passageiros
veículo
terrestre
aquático
aéreo
TERRESTRE
codigo (FK)
qtde_rodas
AÉREO
codigo (FK)
tipo _turbina
AQUÁTICO
codigo (FK)
tamanho
Nesse caso, temos que os atributos código de identificação, cor e capacidade de passageiros é comum
para todos os tipos de veículos, mas que temos diferenças significativas de um tipo para o outro.
Se fizéssemos somente 3 tabelas (uma para cada tipo), teríamos que repetir os campos em comum. Em
princípio, isso é errado! O correto é colocarmos os atributos comuns numa tabela abstrata e nas tabelas
mais concretas somente os atributos inerentes a ela.
Existem outros tipos de relacionamento, como agregação e ternário, mas não são muito comuns e por
isso não tratarei.
37
Conclusão
 Modelagem de banco de dados não é uma ciência
exata, assim como outros tipos de modelagem.
 Portanto, não há verdade absoluta. Essas regras
podem mudar de caso para caso. Mas é preciso que
tenhamos atenção para "quando" quebrar essas
regras. Precisamos ser muito criteriosos e fazer
testes.
38
Exercício
 De acordo com a aula de hoje, traduza o seguinte
exercício:

Relação de Funcionário:
MATRÍCULA DO FUNCIONÁRIO
NOME DO FUNCIONÁRIO
DATA DO NASCIMENTO

DEPENDENTE
CÓDIGO DO DEPENDENTE
NOME DO DEPENDENTE

CURSO
CÓDIGO DO CURSO
NOME DO CURSO
ANO DO CURSO
 Regras do negócio : Um funcionário pode ter mais de
um dependente
 Um funcionário pode fazer mais de um curso
39
Exercício - Resposta
40
Curso Superior de Tecnologia em BD
Obrigado!
Prof. Gustavo Santade
[email protected]