Modelo Relacional. 2. Modelo Relacional (Lógico)



Documentos relacionados
Curso de Gestão em SI MODELAGEM DE DADOS. Rodrigo da Silva Gomes. (Extraído do material do prof. Ronaldo Melo - UFSC)

SISTEMAS DE INFORMAÇÃO GERENCIAIS

4- PROJETO DE BANCO DE DADOS

Chaves. Chaves. O modelo relacional implementa dois conhecidos conceitos de chaves, como veremos a seguir:

Aula 3 SBD Modelo Entidade Relacionamento Parte 1. Profa. Elaine Faria UFU

O modelo Entidade-Relacionamento. Agenda: -Modelagem de dados utilizando O Modelo Entidade-Relacionamento

MER Modelo de entidade e Relacionamento. Prof. Me. Hélio Esperidião

I Requisitos de um modelo conceitual: - clareza (facilidade de compreensão) - exatidão (formal)

Aula II Introdução ao Modelo de Entidade-Relacionamento

Modelo de Dados. Modelos Conceituais

Núcleo de Pós Graduação Pitágoras

Projeto de Banco de Dados. Disciplina: Banco de Dados I José Antônio da Cunha

BANCO DE DADOS I AULA 3. Willamys Araújo

MC536 Bancos de Dados: Teoria e Prática

Simulado Banco de Dados I Bimestre 1 Capítulo 1 Projeto Lógico de Banco de Dados

MODELAGEM DE DADOS - NORMALIZAÇÃO. Prof. Angelo Augusto Frozza, M.Sc.

MODELAGEM DE DADOS MODELAGEM DE DADOS. rafaeldiasribeiro.com.br 04/08/2012. Aula 7. Prof. Rafael Dias Ribeiro.

Prof.: Clayton Maciel Costa

Modelo Entidade-Relacionamento

Banco de Dados Transformação Modelo Conceitual para Lógico Relacional. Prof. Juliano Lucas Gonçalves

Modelagem de Dados Usando o Modelo Entidade-Relacionamento

O Modelo de Entidade Relacionamento (ER ou MER) Parte 1

Disciplina: Unidade III: Prof.: Período:

GBC043 Sistemas de Banco de Dados Modelo de Entidade-Relacionamento (ER)

Banco de Dados I. Modelagem Conceitual Parte 2. Cardinalidades, atributos em relacionamentos, identificadores, generalização. Prof.

Curso de Aprendizado Industrial Desenvolvedor WEB. Disciplina: Banco de Dados Professora: Cheli Mendes Costa Modelo de Dados

Persistência e Banco de Dados em Jogos Digitais

Persistência e Banco de Dados em Jogos Digitais

Modelo de Dados. Modelo para organização dos dados de um BD

DISCIPLINAS DO CURSO INFORMÁTICA ÊNFASE GESTÃO DE NEGÓCIOS. PROFESSOR: DOUGLAS DUARTE DISCIPLINA: BDA1-3º SEMESTRE. Modelagem de Dados

MODELAGEM DE DADOS MODELAGEM DE DADOS. rafaeldiasribeiro.com.br. Aula 4. Prof. Rafael Dias Ribeiro.

GBD PROF. ANDREZA S. AREÃO

Modelagem de Dados MODELAGEM DE DADOS. Lista de Exercícios - AV02. Luiz Leão luizleao@gmail.com Lista de Exercícios AV1

CAPÍTULO 2. Grafos e Redes

LINGUAGEM DE BANCO DE DADOS

BANCO DE DADOS. Fixação dos conteúdos Integridade Referencial Normalização Exercícios

Modelo Relacional. Aécio Costa

CEFET.PHB - PI. Plano de Ensino. Banco de Dados. Plano de Ensino. Plano de Ensino. Plano de Ensino - Conteúdo. Plano de Ensino - Conteúdo

Prof. Alexandre Unterstell Banco de Dados I

Apostila de Banco de Dados

UML Diagramas Estruturais Classes

MEMOREX BANCO DE DADOS por Paulo Marcelo

Ciclo de Desenvolvimento de Sistemas de BD

Universidade Paulista

BANCO DE DADOS I AULA 6. Wlllamys Araújo willamysaraujo7@gmail.com

Engenharia de Software Engenharia de Requisitos. Análise Orientada a Objetos Prof. Edison A M Morais prof@edison.eti.

Modelagem de dados usando o modelo BANCO DE DADOS 1º TRIMESTRE PROF. PATRÍCIA LUCAS

BANCO DE DADOS MODELAGEM ER GENERALIZAÇÃO / ESPECIALIZAÇÃO. Prof.: Jean Carlo Mendes carlomendes@yahoo.com.br

Modelo Entidade-Relacionamento DCC011. Modelo Entidade-Relacionamento. Processo de Projeto de Bancos de Dados

III. Projeto Conceitual de Banco de Dados. Pg. 1 Parte III (Projeto Conceitual de Banco de Dados)

BANCO DE DADOS I. Prof. Antonio Miguel Faustini Zarth

IF685 Gerenciamento de Dados e Informação - Prof. Robson Fidalgo 1

Roteiro. Modelagem de Dados: Usando o Modelo Entidade-Relacionamento. BCC321 - Banco de Dados I. Processo de Projeto de Banco de Dados.

3.1 Definições Uma classe é a descrição de um tipo de objeto.

UML: Diagrama de Casos de Uso, Diagrama de Classes

Disciplina de Banco de Dados Parte V

Dados. Qualquer elemento (aspecto, fato, medida etc.) representativo, disponível e coletável na realidade. fatos no estado bruto, conforme Platão;

BANCO DE DADOS. info 3º ano. Prof. Diemesleno Souza Carvalho

Banco de Dados para Redes. Cassio Diego cassiodiego.com/bdr

Processo de Projeto Bottom-Up. esquema conceitual do BD. engenharia reversa do esquema relacional. esquema relacional integrado do BD (esquema global)

Processo de Projeto Bottom-Up. esquema conceitual do BD. engenharia reversa do esquema relacional. esquema relacional integrado do BD (esquema global)

Modelos de Armazenamento de dados. Prof. Guilherme Tomaschewski Netto

Engenharia de Software

Banco de Dados. Modelagem de Dados com MER. Prof. Walteno Martins Parreira Jr

Profa. Daniela Barreiro Claro

Com base nos slides vistos em sala de aula resolva os seguintes exercícios:

Modelo Entidade-Relacionamento. Modelo Entidade-Relacionamento. Modelo Entidade-Relacionamento

Relacionamentos entre classes

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 16 PROFª BRUNO CALEGARO

Técnicas e Linguagens para Banco de Dados I

MODELAGEM E SIMULAÇÃO

Desenvolver o projeto conceitual de Banco de dados com a utilização do Modelo Entidade-Relacionamento.

Modelagem de Dados UNIDADE DE REVISÃO E RECUPERAÇÃO

Banco de Dados. Profª. Ana Leda

Disciplina Técnicas de Modelagem

Curso Superior em Tecnologia de Análise e Desenvolvimento de Sistemas. Campus Alegrete. Banco de Dados I. Cristhiano Bossardi de Vasconcellos.

FUNDAMENTOS DA ORIENTAÇÃO A OBJETOS- REVISÃO

Modelo Entidade-Relacionamento

Roteiro. Modelo de Dados Relacional. Processo de Projeto de Banco de Dados. BCC321 - Banco de Dados I. Ementa. Posicionamento.

Abordagem relacional Capítulo 4

Disciplina: Unidade II: Prof.: Período:

Prof.: Clayton Maciel Costa

Linguagem e Técnicas de Programação I Tipos de dados, variáveis e constantes. Prof. MSc. Hugo Souza Material desenvolvido por: Profa.

Obrigatoriedade de participação de uma entidade numa associação. Uma entidade pode participar numa associação de duas formas:

MODELAGEM VISUAL DE OBJETOS COM UML DIAGRAMA DE CLASSES.

MODELO ENTIDADE - RELACIONAMENTO

Diagrama de Classes. Um diagrama de classes descreve a visão estática do sistema em termos de classes e relacionamentos entre as classes.

Gestão de Tecnologia da Informação

Conceitos Básicos de Banco de Dados

PROJETO DE BANCO DE DADOS -INTRODUÇÃO. Prof. Angelo Augusto Frozza, M.Sc.

UML (Unified Modelling Language) Diagrama de Classes

Capítulo 3: Modelo Relacional!

descreve relacionamentos entre objetos de dados; conduz à modelagem de dados; atributos de cada objeto => Descrição de Objetos de Dados;

Banco de Dados Modelo Conceitual, Lógico, Físico, Entidade- Relacionamento (ER) Hélder Nunes

1. Introdução ao Modelo Entidade-Relacionamento (MER)

Modelagem de Dados e Conversão de Modelos. Frederico Damasceno Bortoloti freddb@ltc.ufes.br

Banco de Dados Aula 02. Colégio Estadual Padre Carmelo Perrone Profº: Willian

Transcrição:

Modelo Relacional 2. Modelo Relacional (Lógico) Derivado do modelo conceitual; Depende do SGBD escolhido; Independe dos dispositivos de armazenamento; Primitivas: tabelas, linhas e colunas; Transformação do DER (Diagrama Entidade-Relacionamento) em um diagrama relacional 2.1 Introdução Criado por Edgar F. Codd 1970; Usado nas empresas a partir de 1987; A abordagem relacional está baseada no princípio de que as informações em uma base de dados podem ser consideradas como relações matemáticas e que estão representadas de maneira uniforme, através do uso de tabelas bidimensionais. Este princípio coloca os dados (entidades e relacionamentos) dirigidos para estruturas mais simples de armazenar dados, que são as tabelas, e nas quais a visão do usuário é privilegiada. Definição Clássica: são conjuntos de dados vistos segundo um conjunto de tabelas e as operações sobre elas (tabelas) são feitas por linguagens que manipulam a álgebra relacional, não sendo procedurais, ou seja, manipulando conjuntos de uma só vez; O conceito principal vem da teoria dos conjuntos (álgebra relacional) atrelado à idéia de que não é relevante ao usuário saber onde os dados estão nem como os dados estão (transparência). Os usuários manipulam objetos dispostos em linhas e colunas das tabelas. O usuário, para lidar com estes objetos, conta com um conjunto de operadores e funções de alto nível, constantes na álgebra relacional. 2.2 Vantagens da Abordagem Relacional Independência total dos dados; Visão múltipla dos dados; Melhor comunicação entre CPD e usuários; Redução acentuada na atividade de desenvolvimento de aplicações e tempo gasto em manutenção; Melhoria na segurança dos dados; Mais agilidade na questão gerencial da informação ligada ao processo decisório da organização; 1

2.3 As 12 Regras de Codd Codd, ao definir o modelo relacional, estabeleceu um conjunto de 12 regras para a determinação de um banco de dados ser realmente relacional. Segundo estas regras, discute-se a fidelidade de um SGBD ao modelo relacional. Raros são os bancos de dados que se enquadram em mais do que 10 destas regras. As regras de Codd são: 1) Representação por Tabelas: Toda a informação num Banco de Dados Relacional (BDR) é apresentada a nível lógico por valores em tabelas. 2) Acesso a Dados: Toda a informação num BDR pode ser acessada através de 3 primitivas: nome da tabela, nome da coluna e um valor de chave. 3) Nulos Valores nulos são suportados num SGBDR para representar informação ausente ou não aplicável para qualquer coluna. 4) Dicionário de Dados A descrição do banco de dados é representada da mesma maneira que os dados comuns e pode ser acessada através da mesma linguagem relacional usada para acessar dados comuns. 5) Linguagem de Definição O SGBD relacional deve ter uma linguagem para definição, detalhamento do BD. 6) Visões Um SGBDR deve ser capaz de atualizar visões de dados. 7) Linguagem de Manipulação Um SGBDR deve possuir declarações de alto nível para atualização (inserção, alteração, leitura e exclusão) dos dados. 8) Independência Física Programas de aplicação devem permanecer inalterados quando ocorrem modificações na representação física dos dados ou no método de acesso empregado. 9) Independência Lógica Programas de aplicação devem permanecer inalterados quando ocorrem modificações lógicas de qualquer tipo. Ex: divisão de uma tabela por linhas ou colunas. 2

2.4 Conceitos 10) Restrições de Integridade As restrições de integridade necessárias devem ser expressas na linguagem relacional e armazenadas no dicionário de dados. 11) Suporte a BD Distribuídos Um SGBD deve ser capaz de suportar BD distribuídos sem a modificação de programas. 12) Não Subversão Se o SGBD possui uma linguagem de baixo nível esta linguagem não pode permitir violação das regras anteriores. a) Tabela: Arranjo bidimensional (linhas x colunas) usados para armazenar informação. b) Colunas: Representam atributos de uma tabela. c) Chave Primária (PK): É composta por uma coluna ou uma combinação de colunas cujos valores não podem ser repetidos para toda a tabela. Toda tabela tem uma única PK. A PK não pode ser nula a todo ou em parte. d) Chave Estrangeira (FK): É o nome que se dá a PK de uma tabela sempre que referenciada em outra tabela. Cada tabela pode ter várias FK. e) Integridade Referencial: É o processo pelo qual são garantidos valores válidos para todas as FK s. f) Índice: Recurso físico para facilitar a recuperação de informações. g) Chave Secundária: Está associada a um índice e serve para facilitar a busca. Cada tabela pode ter várias chaves secundárias. h) Chave Candidata (Alternativa) (AK): É composta por uma coluna ou combinação de colunas com comportamento semelhante ao da PK. Cada tabela pode ter muitas Ak s. 2.5 Diagrama Relacional Define a modelagem lógica de um banco de dados relacional; Derivado do modelo conceitual (ER); Representa: tabelas, colunas, ligações, restrições de integridade referencial. 3

2.2.1 Ligações Diz-se que duas tabelas estão ligadas sempre que uma delas transferir sua PK para outra; Toda ligação implica numa restrição de integridade referencial; A tabela origem é aquela que cede a PK, e a tabela destino é aquela que recebe a PK; 2.2.2 Regras de Derivação Atributo Multivalorado Todo AMV (atributo multi-valorado) do modelo conceitual transformase numa tabela; A tabela que teve origem numa entidade é representada por um retângulo; A tabela do AMV é representada por um círculo; A origem é sempre a tabela derivada da entidade; A classe da ligação é 1:N; A tabela derivada do AMV é sempre total; É opcional que a tabela derivada da entidade seja total; Normalmente a PK da entidade é parte da PK do AMV. Relacionamento 1:1 Um relacionamento 1:1 transforma-se numa ligação; Se no modelo conceitual, apenas uma das tabelas é total no relacionamento, o destino da ligação é a tabela total; Se ambas são totais, elas podem ser fundidas em uma única tabela; Se ambas são parciais a ligação tem origem no lado mais parcial. Se não for possível saber quem é o mais parcial a origem pode ser qualquer tabela; A classe da ligação e as restrições de totalidade respeitarão o que estiver expresso no modelo conceitual; Relacionamento 1:N a) Caso menos estável Um relacionamento 1:N transforma-se numa ligação; A origem da ligação é sempre a tabela que esta do lado 1 no modelo conceitual; A classe e a restrição de totalidade respeitará aquilo que estiver no modelo conceitual. 4

b) Caso mais estável Um relacionamento 1:N transforma-se numa tabela; A tabela do relacionamento terá 2 ligações uma para cada tabela derivada de uma entidade no modelo conceitual; A origem das ligações serão sempre as tabelas derivadas de entidades; As classes as ligações será 1:1 e 1:N A tabela derivada do relacionamento será sempre total em ambas as ligações; As tabelas derivadas das entidades será totais ou parciais dependendo daquilo que estiver expresso no modelo conceitual; Os atributos do relacionamento passam a ser colunas da tabela de relacionamento; Caso Mais Estável X Caso Menos Estável Vantagem do caso menos estável Utiliza menos recursos computacionais; Uma tabela e uma PK a menos; Vantagem do caso mais estável Se a classe do relacionamento mudar para N:N esta solução facilita a correção do modelo lógico; Relacionamento N:N Todo relacionamento N:N transforma-se em uma tabela; A tabela do relacionamento terá duas ligações, uma para cada tabela derivada de uma entidade; A origem das ligações será sempre nas tabelas derivadas de entidades; A classe das ligações será 1:N; A tabela do relacionamento será total em ambas as ligações; As tabelas derivadas de entidades serão totais ou parciais dependendo do modelo conceitual; Atributos do relacionamento permanecem na tabela do relacionamento; A PK da tabela do relacionamento pode ser composta pela soma das PK s das tabelas de entidade; Auto Relacionamento O modelo lógico derivado de um auto relacionamento será equivalente àquele obtido por um relacionamento binário, fazendo com que a (as) FK (FK s) represente (m) o papel (is) adequado. 5

Agregações O modelo lógico derivado de uma agregação será equivalente ao relacionamento envolvendo a entidade agregada e a outra entidade. Relacionamento Múltiplo Todo relacionamento múltiplo transforma-se numa tabela. (A exceção dos casos onde todas as cardinalidades forem 1); A tabela do relacionamento terá tantas ligações quantas forem as entidades envolvidas; A origem das ligações será sempre nas tabelas derivadas das entidades; A classe das ligações será 1:1 ou 1:N; A tabela derivada do relacionamento será sempre total em todas as ligações; As tabelas derivadas de entidades serão totais ou parciais, dependendo do modelo conceitual; Os atributos de relacionamento permanecem a tabela derivada do relacionamento; Generalização e Especialização Toda generalização será decomposta em tantas ligações quantas forem as especializações existentes; A classe das ligações será 1:1; As especializações serão totais na ligação; A generalização será parcial; A PK das especializações será a mesma PK da generalização à qual pertence. Atributo Global Todos os atributos globais serão colocados em uma única tabela que terá uma única linha e tantas colunas quantas fores os atributos globais; Normalmente esta tabela recebe o nome GLOBAL e não possui PK; Se necessário esta tabela poderá ter ligações 1:1 com outras tabelas, ocorrendo isto, a origem será sempre nas tabelas derivadas de entidades; 6