Curso Superior de Tecnologia em BD

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 E1 R E2 Participação Total de E2 em R E1 1 N R E2 Razão de Cardinalidade 1:N para E1 R E2 R (min, max) E Restrição Estrutural (min, max) na participação de E em R 13

O DER do Sistema Companhia Pnome Mnome Snome Nss Nome Sexo Endereço Salário N 1 TRABALHA-PARA Nome Número Localização EMPREGADO DataInício NúmeroDeEmpregados DEPARTAMENTO DataNasc supervisor 1 1 GERENCIA 1 supervisionado CONTROLA SUPERVISIONA 1 N Horas 1 M TRABALHA-EM N N PROJETO DEPENDENTE-DE 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 1:1 tem Estoque 26

Modelo Conceitual vs. Lógico Modelo lógico: Relacionamento um-para-um Produto 1:1 1:1 tem Estoque PRODUTOS codigo nome estoque Nome da tabela Chave primária 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 0:N tem Funcionário 28

Modelo Conceitual vs. Lógico Modelo Lógico: Relacionamento um-para-muitos Departamento 1:1 0:N tem Funcionário DEPARTAMENTO codigo nome descrição 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 0:N cursa Disciplina 30

Modelo Conceitual vs. Lógico Modelo Lógico: Relacionamento muitos-paramuitos Aluno 0:N 0:N cursa Disciplina ALUNO matr_aluno nome descrição ALUNO DISCIPLINA matr_aluno (FK) cod_disc (FK) Descrição 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 1:1 Funcionário 0:N supervisiona FUNCIONÁRIO 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 0:N cod_disc nome_disc 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 outra tabela (duas vezes). 35

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 VEÍCULO codigo cor qtde_passageiros AÉREO codigo (FK) tipo _turbina terrestre aquático aéreo TERRESTRE codigo (FK) qtde_rodas 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 santade@gmail.com