Aula - Modelagem de Banco de Dados

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Modelagem de Banco de Dados
Prof. Alciano Gustavo Genovez de Oliveira
Revisão de conceitos
A finalidade dos sistemas de banco de dados é garantir que todos os itens abaixo satisfaçam suas condições.
Redundância
Inconsistência
Isolamento de dados
Problemas de integridade
Atomicidade
Anomalias de acesso concorrente
Problemas de segurança
Redundância
A redundância gera duplicidade dos dados, armazenamento excessivo e processamento elevados.
Inconsistência
A redundância pode gerar inconsistência entre as cópias dos dados.
Isolamento de dados
Evitar dados dispersos (redundância) em extensões diferentes (formatos diferentes), por exemplo, uma base de dados e relatórios no Word, como acessá-los simultaneamente?
Problemas de integridade
A definição dos dados é importantíssima, CPF não pode aceitar letras, data de nascimento não pode aceitar letras, número de telefone não pode aceitar letras, nomes não podem aceitar número entre outros.
Atomicidade
Deve-se garantir que toda a informação seja armazenada ou recuperada sem perda de dados, caso isso não ocorra ela deve manter os dados agrupados em sua totalidade.
Anomalias de acesso concorrente
Com a permissão de acesso de diversos programas à mesma base de dados, essa base de dados deve ser organizada de forma que as atualizações sejam realizadas e que todos os usuários recebam essas atualizações, em alguns casos áreas do banco de dados precisam ser isoladas quando acessos são realizados.
Problemas de segurança
Gerenciar quais usuários podem ou não acessar os dados e quais dados podem ser acessados dentro de cada nível de permissão.
Visão dos dados
Com relação a visão dos dados, podemos dividir todo um sistema de banco de dados em três níveis de abstração de dados, são eles:
Nível físico
Nível lógico
Nível de visualização
Nível físico
O nível físico é o nível de abstração mais baixo, descreve como os dados são armazenados, armazenamento em disco e código binário, exemplo, armazenamento por árvore de busca, árvore B. árvore B+.
Nível lógico
O nível lógico descreve quais os dados que estão armazenados e as relações entre eles. É a área de atuação do DBA. Esse nível corresponde ao projeto e implantação do banco de dados sem se preocupar com o nível físico.
Nível de visualização
O nível de visualização (nível view) é o nível de abstração mais alto, descreve somente a parte do banco de dados que o usuário acessa naquele momento, podemos dizer de forma simples que são as interfaces de interação do usuário com o sistema.
Exemplo
Exemplo: a criação de uma entidade contendo os dados do cliente. No nível físico um espaço em disco é destinado ao armazenamento dos dados, a codificação, create table, etc, pertence ao nível lógico, a interface do usuário que deverá permitir cadastrar, excluir, alterar os dados do cliente consiste no nível view.
Modelagem de Banco de Dados
Instância ou tupla: é a coleção das informações armazenadas no banco de dados em um determinado momento.
Chaves
Em um BD é necessário especificar uma maneira de identificar uma tupla de forma única, ou seja, os valores de atributo de uma tupla precisam ser tais que possam identificar unicamente a tupla. Em outras palavras, nenhum par de tuplas em uma relação pode ter exatamente o mesmo valor para todos os atributos.
Superchave
É um conjunto de um ou mais atributos, que tomados coletivamente, nos permite identificar unicamente uma tupla na relação. Porém uma superchave pode conter atributos estanhos dificultando o acesso por parte de usuários.
Chaves candidatas
São superchaves mínimas, ou seja, são superchaves que utilizam o mínimo de atributos que devem ser selecionados de acordo com as necessidades de buscas internas e manipulação de usuários.
Chave primária
Esse termo é utilizado para denotar uma chave candidata que é escolhida pelo projetista do banco de dados como o principal meio de identificar tuplas dentro de uma relação.
Ela é responsável por identificar uma tupla dentre todas as outras tuplas de forma única.
A chave primária deve ser escolhida de modo que o seus valores de atributo nunca, ou raramente, sejam modificados.
Chave estrangeira
A chave estrangeira ocorre quando um atributo de uma relação for chave primária em outra relação. Em outras palavras sempre que houver o relacionamento 1:N entre duas tabelas, a chave primária da tabela 1 será enviada para a tabela N que será a chave estrangeira. Vamos ver um exemplo:
 
Tabela Produtos 
- Código_produto (primária)
- Produto 
- Categoria 
- Preço Data
- Quantidade 
- Descrição 
Tabela Itens do Pedido
- Numero_pedido (primária)
- Código_produto (estrangeira)
- Quantidade
Nas tabelas acima temos um caso de chaves primária e estrangeira. Observe que o codigo_produto consta nas duas tabelas. Em Produtos ele é o campo identificador, ou seja, cada produto deverá ser exclusivo, portanto, uma chave primária. Já em Itens do Pedido o campo codigo_produto poderá constar várias vezes e como ele já é chave primária em Produtos, aqui ele será uma chave estrangeira.
Chave primária composta
O exemplo abaixo mostra como criar uma tabela com uma chave primaria simples. Perceba que a chave primária foi criada no campo cidade.
create table cidades (cidade varchar(100) primary key, estado varchar(10), populacao int)
Agora considere o exemplo abaixo que irá inserir os dados das cidades de Rio Claro/SP e Rio Claro/RJ na tabela criada.
insert into cidades values('Rio Claro','SP',185421)
insert into cidades values('Rio Claro','RJ',17216)
No exemplo acima teremos um erro, pois há uma violação da chave primária, já que o nome Rio Claro será duplicado e isto não é permitido.
A solução para o problema do slide anterior é criarmos uma chave primária composta. É muito importante entendermos que não existe duas chaves primárias e sim chave primária composta.
A chave primária composta é aquela que é criada em dois campos e desta forma passa a utilizar a junção dos dados dos dois campos indicados para formar um valor único e assim aplicar o bloqueio de duplicidade.
No nosso exemplo, poderemos usar o campo estado junto com o campo cidade para formar uma chave composta. Desta forma Rio Claro/SP será diferente de Rio claro/RJ. Veja o exemplo abaixo:
create table cidades (cidade varchar(100),  estado varchar(10), populacao int,  CONSTRAINT pk_CE primary key(cidade,estado))
Constraint é o mesmo que restrição, já que a chave primária é uma restrição. pk_CE é o nome da restrição. Cidade e  estado são os campos que foram usados para criar a chave composta.
Se executarmos novamente o exemplo do insert, como mostrado abaixo, não teremos erro já que a junção dos nomes das cidades com o estado gerou termos diferentes.
insert into cidades values('Rio Claro','SP',185421)
insert into cidades values('Rio Claro','RJ',17216)
Linguagens relacionadas a Bancos de Dados
DDL (Linguagem de definição de dados)
DML (Linguagem de manipulação de dados)
DCL (Linguagem de controle de dados)
TCL (Linguagem de controle de transações)
DDL
DDL – Data Definition Language ( DDL) são usadas para definir a estrutura de banco de dados ou esquema. Alguns exemplos:
CREATE – para criar objetos no banco de dados.
ALTER – altera a estrutura da base de dados.
TRUNCATE – remover todos os registros de uma tabela, incluindo todos os espaços alocados para os registros são removidos.
COMMENT – adicionar comentários ao dicionário de dados.
RENAME – para renomear um objeto.
DML
DML – Data Manipulation Language ( DML) são utilizados para o gerenciamento de dados dentro de objetos do banco. Alguns exemplos:
SELECT – recuperar dados do banco de dados.
INSERT – inserir dados em uma tabela.
UPDATE – atualiza os dados existentes em uma tabela.
DELETE – exclui registros de uma tabela.
EXPLAIN PLAN – explicar o caminho de acesso aos dados.
LOCK TABLE – controle de concorrência.
DCL
DCL – Data Control Language ( DCL ) declarações. Alguns exemplos:
GRANT – atribui privilégios de acesso
do usuário a objetos do banco de dados.
REVOKE – remove os privilégios de acesso aos objetos obtidos com o comando GRANT.
TCL
TCL – Transaction Control Language – (Controle de Transações) são usados ​​para gerenciar as mudanças feitas por instruções DML. Essa linguagem permite que as declarações sejam agrupadas em transações lógicas.
COMMIT – salvar o trabalho feito.
SAVEPOINT – identificar um ponto em uma transação para que mais tarde você pode efetuar um ROLLBACK.
ROLLBACK – restaurar banco de dados ao original desde o último COMMIT.
Álgebra relacional
A álgebra relacional define um conjunto de operações algébricas que atuam sobre as tabelas e geram tabelas como saídas. Essas operações podem ser combinadas para obter expressões que denotam as consultas desejadas. A álgebra define as operações básicas usadas dentro das linguagens de consulta relacional.
As operações na álgebra relacional podem ser divididas em:
Operações básicas
Operações adicionais que podem ser expressas em termos das operações básicas
Operações estendidas, algumas das quais acrescentam mais capacidade expressiva á álgebra relacional.
Os bancos de dados podem ser modificados por inserção, exclusão ou atualização de tuplas. Assim, a álgebra relacional é utilizada para expressar essas modificações.
Exemplos de linguagens que utilizam álgebra relacional:
Oracle
SQL
Exemplos de álgebra relacional aplicada à Banco de dados
Seleção
Projeção
Renomeação
União
Intersecção
Diferença
Produto Cartesiano
Junção
Divisão
Trabalho
Escolher um dos itens do slide anterior, apresentar a definição do item escolhido e montar exemplo de utilização da operação de álgebra relacional escolhida ao banco de dados.
Critério de avaliação e pontuação:
De 0 a 1,5 pontos na P1.
Banco de dados relacional
O modelo relacional foi proposto por Edgar Codd em 1970, como uma nova maneira de representação de dados. Neste seu trabalho Codd mostrou que uma visão relacional dos dados permite a sua descrição em uma maneira natural, sem que sejam necessárias estruturas adicionais para sua representação, provendo uma maior independência dos dados em relação aos programas.
Em complementação, apresentou bases para tratar problemas como redundância e consistência. Mais tarde, em outro trabalho, Codd definiu uma álgebra relacional e provou, por meio de sua equivalência com o cálculo relacional, que ela era relacionalmente completa, dando fundamentação teórica ao modelo relacional. 
Banco de dados relacional
Este modelo, por suas características e por sua completitude, mostrou ser uma excelente opção, superando os modelos mais usados àquela época: o de redes e o hierárquico.
A maior vantagem do modelo relacional sobre seus antecessores é a representação simples dos dados e a facilidade com que consultas complexas podem ser expressas.
Em meados dos anos 70 foram desenvolvidos os primeiros sistemas relacionais em projetos da IBM, como o Sistema-R, e da Universidade de Berkeley (Califórnia), que deu origem ao sistema Ingres. Desde então, o uso deste modelo intensificou-se e a partir dos anos 80, o modelo relacional passou a ser dominante na área de banco de dados. Tal crescimento fez o mercado de sistemas relacionais crescer bastante, tornando-se hoje um mercado milionário.
Banco de dados relacional
Vários são os fornecedores atuais, dentre os quais podemos citar IBM, Microsoft, Sybase e Oracle, este último uma empresa que começou naquela época e que hoje é provavelmente a líder do mercado de banco de dados relacionais. Existem também sistemas como FireBird, MySQL e PostGres, que com a nova tendência de software livre, vêm sendo utilizados por várias empresas.
Banco de dados relacional
Ainda existem sistemas legados mantidos nos modelos antigos, como o IMS DBMS da IBM no modelo hierárquico e o IDS e IDMS no modelo de redes. Há também uma nova abordagem que vem sendo bastante explorada: o modelo orientado a objetos, que tem como exemplos o Objectstore e o Versant . Apesar da orientação a objetos não ser um conceito novo, apenas recentemente, com a proposição de novas metodologias, como, por exemplo, a UML, e de linguagens de programação como C++ e Java, seu uso vem se intensificado, tornando-se um padrão em várias aplicações de software.
Com isso, a existência de banco de dados orientados a objetos está sendo colocada como uma das revoluções na área de banco de dados. Assim, numa tentativa de reunir vantagens de objetos com as inerentes ao modelo relacional, tem-se os banco de dados objeto-relacional. Mesmo assim, o modelo relacional ainda é o modelo dominante em seu mercado.
Banco de dados relacional
No modelo relacional a principal construção para representação dos dados é a relação, que é definida como sendo uma tabela com linhas não ordenadas e colunas. Uma relação consiste de um esquema e de uma instância.
O esquema especifica o nome da relação e o nome e o domínio de cada coluna, também denominada atributo ou campo da relação. O domínio do atributo é referenciado no esquema por seu nome e serve para restringir os valores que este atributo pode assumir. O esquema de uma relação é invariável ao longo do tempo, sendo modificado apenas por comandos específicos.
Banco de dados relacional
Um exemplo de esquema de relação é:
Students (sid: string, name: string, login: string, age: integer, gpa: real). 
Neste caso está sendo definida a relação de nome Students, com atributos sid, name, login, age e gpa, cujos domínios são respectivamente string, string, string, integer e real. 
A instância de uma relação é o conjunto de linhas, também denominadas tuplas ou registros, distintas entre si, que compõem a relação em um dado momento. Ela é variável, já que o número de tuplas e o conteúdo de seus atributos podem variar ao longo do tempo. A instância de uma relação deve seguir sempre o seu respectivo esquema, respeitando o número de atributos definidos, bem como os seus domínios.
Exemplo:
Exemplo de banco de dados relacional
Microsoft Acess 2010
Acess 2010
Selecionar em modelos disponíveis a opção:
Banco de dados em branco
Salvar o banco de dados
Arquivo
Salvar banco de dado como
Todas as bases de dados devem ser fechadas antes de salvar
Sim
Criando relações:
Criar
Tabela
Selecionar em modo de exibição
Modo design
Dar um nome para a relação 
Criar a entidade cliente com os seguintes campos:
cod_cli – autonumeração
nome_cli – texto 80 caracteres e requerido: sim
end_cli – texto 40 caracteres e requerido: sim
num_cli – inteiro longo, csas decimais 4 e requerido: sim
data_nasc_cli – data, formato: data abreviada, requerido: sim
cpf_cli – texto 11 caracteres, mascara de entrada: cpf com símbolos na máscara, requerido: sim
Definir chave primária
Definir o cod_cli como chave primária
Selecionar o campo como mouse e clicar no botão chave primária.
Acess 2010
Criar a entidade produtos com os seguintes campos:
cod_prod – autonumeração
nome_prod – texto 30 caracteres e requerido: sim
val_prod – moeda com formato em reais e requerido: sim
Definir chave primária
Definir o cod_prod como chave primária
Criar a entidade vendas com os seguintes campos:
cod_vend – autonumeração
cod_cli – número, inteiro longo e requerido: sim
cod_prod – número, inteiro longo e querido: sim
Val_prod – moeda e requerido: sim
Qtd_prod – número, inteiro longo e requerido: sim
Val_total – calculado, inserir a expressão no campo expressão [Val_prod]*[Qtd_prod] 
Definir chave primária
Definir o cod_vend como chave primária
Definir cod_cli como chave estrangeira
Definir cod_prod como chave estrangeira
Acess 2010
Definido chave estrangeira no acess 2010
Abrir a tabela aberta em modo design
Entrar na opção índices
Inserir o nome do campo que deverá ser chave estrangeira
Criando os relacionamentos
Passo para criar os relacionamentos
Fechar as relações (tabelas)
Entrar na opção: ferramentas de banco de dados
Entrar na opção: relações
Selecionar as três relações
Adicionar
Fechar a janela
Gerando as cardinalidades
Para gerar as cardinalidades, siga os passos:
Escolha um atributo de uma relação e arraste ele até um atributo da outra relação
Na janela que abrir será exibida a cardinalidade
Clicar no botão criar
Repita esse passo para criar todos os relacionamentos necessários
A ligação entre os atributos de entidades diferentes, irá definir as cardinalidades dos relacionamentos
Criando formulários
Para que o usuário possa manipular as informações de uma forma simples, são criados os formulários que são sobrepostos às relações (tabelas), porém tudo que é realizado nos formulários tem suas informações alteradas na relações (tabelas).
Criando formulários
Selecione a opção: Criar
Selecione a opção: formulário de design
Uma gride será aberta
Selecione a opção: Adicionar campos existentes
Selecione a opção: (no lado direito) adicionar todas as tabelas
Selecione a tabela
Arraste para a gride os atributos da relação
Criando botões
Para criar os botões devemos selecionar a função que cria botões que esta na aba design.
Clicar na gride no local onde o botão deverá ficar
Realize as configurações na janela que abrirá automaticamente
Escolher categoria
Escolher ação
Definir a aparência do botão
Não alterar o comando
Concluir
Repetir o processo para todos os botões que forem necessários para o formulário
Salvar o formulário
Repetir o processo para o formulário de produtos
Modelagem de Banco de Dados
	Esquema do banco de dados: é o projeto geral do banco de dados. Comparado a um programa escrito em uma linguagem de programação, pode ser considerado como a declaração das variáveis.
	Exemplo: 
	Empregado
	RG: cadeia de caracteres
	Nome: cadeia de caracteres
	Salário: real
 
	Engenheiro 
	RG: inteiro
	Cargo: cadeia de caracteres
 
	Técnico
	RG: cadeia de caracteres
	Especialidade: cadeia de caracteres
Modelagem de Banco de Dados
	Esquema físico: Descreve o projeto do banco de dados no nível físico (formas de armazenamento e recuperação)
	
	Esquema lógico: descreve o banco de dados no nível lógico (comandos de gerenciamento do SGBD)
	Subesquemas: descreve o banco de dados no nível de visualização (Interfaces de visualização e manipulação dos dados)
Modelagem de Banco de Dados
	Políticas de substituição de paginas:
	LRU (menos): substitui a pagina, menos utilizada recentemente, ou seja, a pagina que esta sendo intensamente referenciada pelas instruções pode muito provavelmente ser novamente referenciada pelas próximas instruções.
	MRU (mais): faz a substituição da ultima pagina acessada. 
	LFU (frequentemente): escolhe entre todas as paginas acessadas a que foi menos acessada entre todas que estão carregadas na memória para que seja substituída, para isso é mantido um contador de acessos que permite que o sistema possa realizar o processo de escolha das paginas
Modelagem de Banco de Dados
Projeto físico
Estrutura de armazenamento
Arvore B
Arvore B+
Modelagem de Banco de Dados
	Modelos de dados: Coleção de ferramentas conceituais para descrever dados, relações dos dados, restrições. Um modelo de dados deve ser capaz de permitir descrever o projeto de um banco de dados no nível físico, nível lógico e nível de visualização.
	
	Existem vários modelos de dados, exemplos:
Modelo relacional
Modelo entidade relacionamento
Modelo de dados orientado a objetos
Modelagem de Banco de Dados
	Modelo relacional: utiliza uma coleção de tabelas para representar os dados e as relações entre eles. Cada tabela possui diversas colunas e cada coluna possui um nome único.
	As tabelas associam-se entre si através de regras de relacionamentos, estas regras consistem em associar um ou vários atributos de uma tabela com um ou vários atributos de outra tabela.
Exemplo: Modelo Relacional
Modelagem de Banco de Dados
	Modelo entidade relacionamento: é uma percepção do mundo real que consiste em uma coleção de objetos básicos, chamados entidades e as relações entre esses objetos. Uma entidade é uma coisa ou objeto no mundo real que é distinguível dos outros objetos.
Exemplo: Modelo Entidade Relacionamento
Modelagem de Banco de Dados
	Modelo de dados orientado a objeto: modelo que tem recebido cada vez mais atenção pode ser visto com uma extensão ao modelo Entidade relacionamento com métodos e funções. Esse modelo combina recursos do modelo de dados orientado a objeto e do modelo de dados relacional
Exemplo: Modelo de Banco de Dados Orientado a Objeto
				associação 
ge				generalização
agregação	Composição
Exercício com o modelo de Banco de Dados Relacional
Ver documento do Word
Banco de Dados Orientado a Objeto
Os bancos de Dados Orientados a Objeto são também chamados de Bancos de Dados Não Convencionais.
Este tipo de banco de Dados é utilizado em aplicações Não Convencionais , por exemplo:
Educação
Mineração de Dados
Sistemas de Informação geográficas
Medicina