Modelo Lógico de Banco de Dados

A arquitetura do SGBD é estabelecida a partir de um modelo de dados MODELOS: Hierárquico Rede Relacional .

Modelo Hierárquico Percepção do banco de dados como uma estrutura de árvore envolvendo registros e ligações Cada registro pode ter vários dependentes Cada registro só pode possuir um ascendente (exceto a raiz que não tem ascendente) A navegação é feita com comandos do tipo: Acessar o primeiro (get first) Acessar o próximo (get next)

Representação Hierárquica de Registros em um BD Filial SP São Paulo SP01 João SP02 Joana SP03 Gastão ESP Esporte UTL Utilitário LKY1201 Kombi Preta JJM1814 Pick-up Azul Agente Tipo de Veiculo Veiculo Criação de uma nova filial pode exigir a criação de um tipo de veiculo já existente.

Modelo de Rede Visto como um grafo ou uma malha de ligações um-para-muitos entre os registros Um tipo de registro pode estar envolvido em mais de um relacionamento Cada registro pode ter vários ascendentes e vários descendentes Trabalha com o conceito de grupo ou conjunto Cada conjunto tem: Um tipo de registro proprietário (owner), que só pode participar de uma ocorrência do conjunto Um tipo de registro membro (member), que pode participar em qualquer quantidade de ocorrências

Representação em Rede de Registros em um BD SP São Paulo UTL Utilitário ESP Esporte LKY1201 Kombi Preta JJM1814 Pick-up Azul AM Manaus YYZ1891 Gurgel Branco BNX9413 BMW Laranja

Modelo Relacional Um banco de dados relacional é percebido pelo usuário como um conjunto de tabelas Uma tabela ou relação é composta por linhas conhecidas com t-uplas (lê-se tuplas) e colunas Colunas possuem um conjunto de valores possíveis chamados domínio “No Sistema Relacional os dados são percebidos como Tabelas e as operações aplicáveis ao sistema geram tabelas a partir das primeiras”

Operações Relacionais União (A U B) Produz uma tabela resultado da União das tabelas operadas Interseção (A B) Cria uma tabela resultado da interseção das tabelas operadas Diferença (A - B) Cria uma tabela contendo tuplas que pertencem à primeira tabelas operada, mas não à segunda. Produto Cartesiano (A * B) Gera todas as combinações possíveis entre as tuplas de duas tabelas U

Projeção (A , B) Cria uma tabela contendo alguns atributos específicos da tabela operada Seleção ou Restrição (A (a = ‘X’) ) Serve para extrair (selecionar) tuplas de uma certa tabela Junção (A.x = B.x) Gera uma tabela que é a combinação das tabelas operadas segundo critérios impostos sobre atributos de uma e outra tabela Divisão (A / B) Opera duas tabelas, criando uma terceira com os atributos da primeira tabela cujos atributos que os acompanham existem também na segunda tabela.

Para exemplificar, considere o seguinte Banco de Dados Livro (L) Livro Autor Editora ABC X ED1 DEF Y ED2 GHI Y ED2 JKL X ED3 MNO Z ED2 Usuário U1 U2 U3 U4 U5 Usuário (U) Memória (M) Livro Usuário ABC U1 ABC U4 DEF U1 JKL U2 Empréstimos em aberto (E) Livro Usuário ABC U1 GHI U2 JKL U5 Autor(A) Livros rasurados (R) Livro ABC DEF Autor X Y Z

Quais livros foram emprestados para quais usuários, incluíndo empréstimos em aberto ? União das tabelas Empréstimo em Aberto e Memória de Empréstimo (Empréstimo.Global = E U M) Empréstimo Global Livro Usuário ABC U1 ABC U4 DEF U1 GHI U2 JKL U2 JKL U5

Quais livros atualmente emprestados já haviam sido emprestados antes para o mesmo usuário ? Interseção das tabelas Empréstimo em Aberto e Memória de Empréstimo (Empréstimo.já = E M) U Empréstimo Já Livro Usuário ABC U1

Quais livros atualmente emprestados nunca haviam sido retirados pelo mesmo usuário ? Diferença entre as tabelas Empréstimo em Aberto e Memória de Empréstimo. (Primeira = E - M) Primeira Livro Usuário GHI U2 JKL U5

Quais são todas as combinações de livros atualmente emprestados x usuários depositário x autor ? Esta consulta não tem muito sentido, servindo apenas para exemplificar Produto cartesiano ds tabelas Autor e Empréstimo em Aberto (Mistura = A * E) Mistura Autor Livro Usuário X ABC U1 X GHI U2 X JKL U5 Y ABC U1 (continuação) Autor Livro Usuário Y GHI U2 Y JKL U5 Z ABC U1 Z GHI U2 Z JKL U5

Que autores escreveram livros para quais editoras ? Projeção da tabela Livro segundo autor e editora (Filiação = L [ autor,editora]) Filiação Autor Editora X ED1 Y ED2 X ED3 Z ED2

Quais os livros escritos pelo autor Y ? Seleção da tabela Livro segundo o autor “Y” (Y.autoria = L [ autor = Y]) Y.autoria Livro Autor Editora DEF Y ED2 GHI Y ED2

Que autores estão sendo lidos por quais usuários ? Junção das tabelas Livro e Empréstimos em aberto (Lidos = L [ livro = livro] E) Lidos Livro Autor Editora Usuário ABC X ED1 U1 GHI Y ED2 U2 JKL X ED3 U5

Quem são os possíveis rasuradores de livros ? Divisão da Memória de Empréstimos pela tabela Livros Rasurados (Rasuradores = M / R) Rasuradores Usuário U1 U4

12 Regras para um SGBD ser Relacional São 12 regras, precedidas por uma regra geral 0 (zero). Destas 12, pelo menos 6 devem ser cumpridas para que o SGBD possa ser qualificado como completo relacionalmente.

Regra 0 (Genérica): Para ser Relacional, o SGBD deve ter a capacidade de gerenciar bancos de dados apenas através de suas capacidades relacionais. Regra 1: Toda a informação em um banco de dados relacional é representada explicitamente no nível lógico e exatamente de uma forma: por valores em tabelas. Regra 2: Todo e qualquer dado num banco de dados relacional tem a garantia de ser logicamente acessível por meio de uma combinação do nome da tabela, valor da chave primária e do nome da coluna. Regra 3: Os valores nulos são suportados nos SGBDs completos para representar de modo sistemático a informação ausente ou não aplicável, qualquer que seja o tipo de dado. Regra 4: A descrição do banco de dados a nível local é representada da mesma maneira que os dados comuns, de forma que os usuários autorizados possam usar, para consultá-la, a mesma linguagem usada para os dados comuns.

recuperação dos dados mas também à inclusão, atualização e exclusão. Regra 5: Um sistema relacional pode suportar várias linguagens e modalidades de uso com terminal. Porém, deve haver pelo menos uma linguagem cujos comandos possam ser expressos como cadeias de caracteres. A linguagem deve ser suficientemente completa para suportar definição de dados, visões, controle de integridade, autorização de acesso, manipulação e definição dos limites das transações (início, fim e possibilidade de anulação). Regra 6: Todas as visões que forem teoricamente atualizáveis devem ser também atualizáveis pelo sistema. Regra 7: A Capacidade de tratar em tabela básica ou uma tabela derivada aplica-se não só à recuperação dos dados mas também à inclusão, atualização e exclusão. Regra 8: Programas de aplicação e atividades de terminal devem ficar logicamente inalterados quando ocorrem modificações, quer seja na representação dos dados armazenados, quer no método de acesso.

Regra 9: Programas de aplicação e atividades de terminal devem ficar logicamente inalterados quando ocorrem modificações de qualquer tipo que não alterem as informações contidas nas tabelas básicas. Regra 10: As restrições de integridade de um banco de dados relacional específico devem ser definidas na sublinguagem de dados relacional e armazenáveis no dicionário de dados, e não em programas de aplicação. Regra 11: Quer o sistema suporte ou não bancos de dados distribuídos, ele deve ter uma sublinguagem de dados que possa suportar estes bancos, sem prejudicar os programas de aplicação e as atividades de terminal. Regra 12: Se um sistema relacional possui uma linguagem de nível baixo, esta capacidade não pode ser usada para subverter ou ignorar as regras e restrições de integridade espressas na linguagem relacional de mais alto nível.

O M O D E L O L Ó G I C O R E L A C I O N A L

O Modelo Relacional Definição Criado nos anos 1970 por Edgar F. Codd Utilização efetiva à partir de 1987 Informações consideradas com relações matemáticas Entidades e relacionamentos armazenados em tabelas bidimensionais Definição “São conjunto de dados vistos segundo um conjunto de tabelas e as operações sobre as tabelas feitas com manipulação da álgebra relacional.”

> Funcionário: Visão Lógica dos Dados Matricula Nome 830001 860072 870029 920101 João Cris Paula Chico 01/04/50 19/12/75 31/12/67 08/09/70 Nascimento >

Principais Vantagens Independência de dados Visão múltipla de dados Melhor comunicação entre profissional de informática e usuário Facilidades para desenvolvimento e manutenção de aplicações Melhor segurança de dados Maior agilidade para o processo decisório

CHAVE PRIMÁRIA (Primary Key) É um atributo ou conjunto de atributos que identifica univocamente um tupla (linha). CHAVE SECUNDÁRIA (Secondary Key) Ë uma chave candidata à chave primária CHAVE ESTRANGEIRA (Foreign Key) São os elos de ligação entre as tabelas. Atributos de uma tabela que casam com a chave primária de outra tabela. No ambiente Relacional uma tabela é acessível por qualquer campo (atributo) independente deste ser declarado como chave.

CHAVE ESTRANGEIRA (Foreign Key) São os elos de ligação entre as tabelas. Atributos de uma tabela que casam com a chave primária de outra tabela.

Forma de exclusão: Indica qual a ação que acontecerá na tupla que possua a chave estrangeira quando ocorrer exclusão da tupla a qual ela está relacionada. Restrict: Não permite a exclusão da tupla que possui a chave primaria . Cascade: Exclui todas as tuplas relacionadas quando a tupla que possui a chave primária é excluída. Set Null: Atualiza com NULO o campo chave estrangeira quando a tupla que possui a chave primária é excluída.

Regras de Integridade do Modelo Relacional Integridade da Entidade: Um atributo que participe de chave primária não pode ter valor nulo. Integridade Referencial: Se uma determinada tabela “A” possui uma chave estrangeira em relação a uma outra tabela “B”, então ela deve: Ser igual a um valor de chave primária existente em “B” ou Ser nula (NULL) Não pode existir na chave estrangeira, um valor que não exista na tabela na qual ela é chave primária.

Derivação do Modelo E-R para o Modelo Relacional Toda entidade torna-se uma tabela Cada atributo vira uma coluna da tabela Chaves primárias e chaves candidatas são projetadas para não permitirem ocorrências múltiplas e nem admitirem nulos Chaves das entidades fracas são formadas pelas chaves primárias da entidade da qual ela é fraca mais os atributos individualizadores da mesma

Relacionamento 1:N Nome Departamento aloca Funcionário Funcionário 1:1 Funcionário Código Nome Matricula Cd-dpto Funcionário Departamento

Relacionamento 1:N (exemplo) 1:1 aloca 1:N Departamento Funcionário Departamento Funcionário Código Nome Matricula Nome Cd-dpto INFO Informática CONT Contabilidade TRAN Transporte 001 Jose INFO 002 Ana Paula CONT 005 Carolina TRAN 006 Fernanda CONT 007 Cristina INFO

Relacionamento 1:N Envolvendo Auto-Relacionamento NOME PEÇA-QUE-COMPÕE CÓDIGO Peça COMPÕE PEÇA 0:1 0:N composta É componente

Relacionamento 1:N Envolvendo Auto-Relacionamento (exemplo) NOME PEÇA-QUE-COMPÕE CÓDIGO Peça 4534 Correia 6547 Parafuso 7734 Freio 6547 1198 Motor 6547 COMPÕE PEÇA 0:1 0:N

Relacionamento 1:1 Departamento Chefia Funcionário NOME Funcionário 0:1 1:1 Departamento Chefia Funcionário NOME MATRICULA Funcionário CÓDIGO NOME Departamento MATRICULA

Relacionamento 1:1 (exemplo) 0:1 Departamento Chefia Funcionário Departamento Funcionário CÓDIGO NOME MATRICULA MATRICULA NOME INFO Informática 002 001 Jose CONT Contabilidade 006 002 Ana TRAN Transporte 007 006 Fernanda 005 Carolina 007 Cristina

Código Nome Esposo/Esposa Relacionamento 1:1 Envolvendo Auto-Relacionamento 0:1 CASADA PESSOA Código Nome Esposo/Esposa Pessoa

Código Nome Esposo/Esposa Relacionamento 1:1 Envolvendo Auto-Relacionamento (exemplo) Pessoa Código Nome Esposo/Esposa CASADA PESSOA P1 José P2 P2 Maria P1 P3 Ana P6 P4 Flávia P5 P5 João P4 P6 Carlos P3 P7 Suzana 0:1 0:1

Relacionamento M:N - Entidades Distintas alocado Funcionário Projeto COD-PRJ MATR DATA ALOCADO NOME FUNCIONÁRIO CÓDIGO PROJETO

Relacionamento M:N - Entidades Distintas (exemplo) alocado Funcionário Projeto MATR NOME FUNCIONÁRIO ALOCADO PROJETO DATA MATR COD-PRJ CÓDIGO NOME 001 José 002 Ana Paula 005 Carolina 006 Fernanda 007 Cristina 001 P1 02/01/95 002 P2 12/07/94 005 P3 01/10/96 006 P3 01/03/97 007 P2 01/06/86 P1 Construção P2 Informática P3 Ensino

Relacionamento M:N - Auto-Relacionamento PRÉ-REQ DISCIPLINA 0:N 0:N CÓDIGO NOME DISCIPLINA CÓDIGO CÓD-PRÉ PRÉ-REQUISITO

Relacionamento M:N - Auto-Relacionamento (exemplo) PRÉ-REQ DISCIPLINA 0:N 0:N CÓDIGO CÓD-PRÉ PRÉ-REQUISITO NOME DISCIPLINA CL1 Cálculo I CL2 Cálculo II FIS1 Física 1 FIS2 Física 2 EST Estatística CL2 CL1 FIS2 FIS1 EST CL1 EST FIS2

Relacionamentos Múltiplos Funcionário Conhecimento Usado Projeto 0:M Conhecimento MATRICULA CONHECIMENTO PROJETO Física Matemática Biologia Química

Relacionamentos Múltiplos (exemplos) Conhecimento Usado Funcionário 0:N Projeto MATRICULA CONHECIMENTO PROJETO Física Matemática Biologia Química 001 Física P1 001 Matemática P1 002 Biologia P2 005 Biologia P2 005 Química P3 007 Física P1 007 Química P3

Generalizações Chefia Departamento Funcionário Engenheiro Vendedor 1:1 Departamento Funcionário Engenheiro Vendedor Secretária Matricula Matricula Matricula Ajuda de custo Hora extra Ling. Estrang. Especialidade Despesa extra Curso Placa carro

Generalizações (exemplo) Departamento Funcionário Matricula Nome Função 001 Jose Eng 002 Ana Paula Secr 003 Carolina Eng 006 Fernanda Secr 007 Cristina Eng 008 Juarez Vend CÓDIGO Matricula NOME INFO Informática 001 CONT Contabilidade 006 TRAN Transporte 008

Generalizações (exemplo) 001 120 Computação 003 150 Civil 007 230 Elétrica Matricula Ajuda de Custo Especialidade Matricula Lingua Estrang. Curso 002 Ingles Completo 006 Frances Incompl. Matricula Hora extra Despesa Extra Placa carro 008 25 150 JPX1845 Engenheiro Secretária Vendedor

Modelo Entidade - Relacionamento A técnica de modelagem mais usada é a Abordagem Entidade-Relacionamento (ER). O modelo de dados é representado graficamente atraves de um Diagrama de Entidade-Relacionamento (DER).

Entidades Empregado Departamento Sócios Shows

Relacionamentos Participa Sócios Shows Empregado Departamento Trabalha

Cardinalidade Expressa o numero de entidades as quais outra entidade pode estar associada via um conjunto de relacionamentos.

Cardinalidade de Relacionamentos Duas cardinalidades máximas são relevantes: A cardinalidade máxima 1 A cardinalidade máxima “muitos” representada pela letra n Empregado Departamento Trabalha n 1

Cardinalidade Mínima Empregado (1,0 ) (1,1 ) Mesa alocado

Um para Um – 1:1 Uma entidade em A está associada no máximo a uma entidade em B, e uma entidade em B está associada a no máximo uma entidade em A. a1 a2 a3 a4 b1 b2 b3 b4

Um para muitos – 1:N b1 a1 b2 b3 a2 b4 Uma entidade em A está associada a várias entidades em B. Uma entidade em B, entretanto, deve estar associada no máximo a uma entidade em A. b1 b2 b3 b4 a1 a2

Muitos para muitos – N:N ou M:N Uma entidade em A está associada a qualquer número de entidades em B e uma entidade em B está associada a um número qualquer de entidades em A. b1 b2 b3 b4 a1 a2 a3 a4

Modelagem E-R – James Martin Empregado Departamento Exemplo de Modelagem, onde: = muitos = um = a ocorrência do relacionamento é opcional; = a ocorrência do relacionamento é obrigatória;

Peter Chen X James Martin Trabalha Empregado Departamento (1,1) (0,n) Empregado Departamento

Modelagem E-R Associações de “Um para Um” Motorista Táxi · Associações de “Um para Muitos” Cliente Animal

Associações de “Muitos para Muitos” Modelagem E-R Associações de “Muitos para Muitos” Advogado Processo

Entidade Associativa Processo/ Advogado Advogado Processo Em um banco de dados não é possível implementar um relacionamento M:N, sendo assim foi criado na modelagem a Entidade Associativa. Entidade Associativa é a associação entre uma entidade e um relacionamento, ou a associação entre dois relacionamentos.