Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
vii)Estrutura de um SGBD
não tem uso difundido em grandes empresas, que ainda preferem confiar
seus dados a aplicações mais “maduras” e com maior capacidade de
suporte. Há outros SGBDs livres que seguem a linha do MySql, como o
PostgreSql, por exemplo.
Modelagem de Dados
Uma das principais características da abordagem de banco de dados é que ela
fornece alguns níveis de abstração de dados omitindo ao usuário final detalhes
de como os dados são armazenados.
respeito das contas: número, agência, saldo, etc.), clientes (nome, endereço,
telefone, etc.).
2. Modelo em Rede
Um modelo em rede é uma extensão do modelo hierárquico. Em vez de se
terem apenas vários níveis de relações um-para-muitos, o modelo em rede é
uma relação membro-proprietário, na qual um membro pode ter muitos
proprietários. Nesse modelo, há frequentemente mais de um caminho pelo
qual um determinado elemento de dado pode ser acessado.
3. Modelo Relacional
Os modelos relacionais se tornaram os mais populares. A finalidade global
deste modelo é descrever o dado usando um formato tabular padrão (todos os
elementos são localizados em tabelas bidimensionais). As tabelas organizam os
dados em linhas e colunas, simplificando o acesso e a manipulação dos dados.
Uma vez colocados os dados no Banco de Dados relacional, pode-se fazer
perguntas e manipular dados utilizando as operações da álgebra relacional. As
manipulações básicas de dados incluem a sua seleção, projeção e
agrupamento.
• Projeto Conceitual
É a descrição de mais alto nível da estrutura do BD, NÃO contendo
detalhes de implementação.
Nesta etapa não é necessário se preocupar com o tipo de SGBD a ser
usado, ou seja o projeto é independente do tipo de SGBD usado.
É o ponto de partida do projeto de Banco de Dados e seu objetivo é
representar a semântica da informação, independente de considerações de
eficiência.
O objetivo é a representação dos requisitos de dados do domínio.
Requisitos: clareza (facilidade de compreensão) e exatidão (formal).
• Projeto Lógico
No modelo lógico existe a descrição da estrutura do BD que pode ser
processada pelo SGBD. Em poucas palavras é o modelo conceitual mapeado
para um modelo lógico de dados.
Nesta etapa há a dependência da classe de modelos de dados utilizada pelo
SGBD, mas não do SGBD.
A ênfase do modelo lógico está na eficiência de armazenamento, ou seja,
em evitar muitas tabelas (e junções); tabelas subutilizadas, etc.
Futuras alterações no modelo lógico devem ser primeiro efetuadas no
Modelo Conceitual.
• Projeto Físico
Nesta etapa ocorre o mapeamento do modelo lógico em um esquema físico
de acordo com o SGBD específico, ou seja, o modelo criado está
diretamente ligado ao SGBD escolhido.
No modelo físico contém a descrição da implementação da base de dados
na qual descreve as estruturas de armazenamento e os métodos de acesso.
Caracteriza-se pela criação do esquema SQL da modelagem lógica. Sua
ênfase na eficiência de acesso como na implementação de consultas,
índices, etc. Exemplos: alocação dinâmica de espaços, clusterização,
particionamento físico das tabelas, etc.
Entidades
O objeto básico tratado pelo modelo ER é a entidade, que pode ser definida
como um objeto do mundo real, concreto ou abstrato e que possui
existência independente.
- Atributos simples
- Compostos
-Monovalorados
- Multivalorados
Os atributos que não são divisíveis (não é dividido em partes) são chamados
atributos simples.
Os atributos compostos podem ser divididos em subpartes menores que
representam outros atributos básicos com significados diferentes. Por
exemplo:
- Título pode ser estruturado em original e títuloLançamento;
- o atributo Endereço, pode ser subdividido em número, logradouro, cidade,
estado e CEP.
Relacionamentos
Um relacionamento pode ser entendido como uma associação entre instâncias
de Entidades devido a regras de negócio. Normalmente ocorre entre instâncias
de duas ou mais Entidades, podendo ocorrer entre instâncias da mesma
Entidade (auto-relacionamento).
Quanto a Cardinalidade
- 1:1 (Um para um)
- 1:N (Um para muitos)
- N:1 (Muitos para um)
- N:N (Muitos para muitos)
Exemplos de relacionamentos:
Notação:
Possui Dependentes
EMPREGADO
DEPENDENTE
e1
e2
p1
p2
p3
TIPO
ENTIDADE ATRIBUTO
ATRIBUTO
TIPO ENTIDADE CHAVE
FRACA
ATRIBUTO
MULTI
VALORADO
TIPO
RELACIONAMENTO
ATRIBUTO
COMPOSTO
TIPO
RELACIONAMENTO
IDENTIFICADOR
ATRIBUTO
DERIVADO
1 N
E1 R E2 E1 R E2
(min, max)
R E1
**Abordagem Relacional
Abordagem de modelagem de dados utilizada nos sistemas de
gerenciamento de bancos de dados do tipo relacional.
Modelagem a nível lógico.
O modelo relacional foi criado por Codd em 1970 e tem por finalidade
representar os dados como uma coleção de relações, em que cada
relação é representada por uma tabela, composta por linhas, colunas
e chaves primárias, relacionadas por meio de chaves
estrangeiras.
Opera com os dados organizados como um conjunto de tabelas
O conceito de tabela é o mais forte no modelo relacional.
Tuplas
Os atributos e seus valores descrevem as instâncias de uma entidade,
formando o que chamamos de tuplas ou registros.
Figura. Tuplas
2ª Forma Normal
Uma relação estará na 2ª FN, se e somente se, estiver na 1a FN e os
seus atributos não chaves forem dependentes funcionais completos da
chave primária.
3ª Forma Normal
Uma relação estará na 3ª FN, se e somente se, estiver na 2 a FN e
todos os seus atributos não chaves forem dependentes não transitivos
da chave primária.
• 1a Forma Normal
A 1a Forma Normal prega que todos os atributos de uma tabela devem ser
atômicos (indivisíveis), ou seja, não são permitidos atributos
multivalorados, atributos compostos ou atributos multivalorados
compostos. Leve em consideração o esquema a seguir:
• CLIENTE
1. Código
2. { Telefone }
3. Endereço: ( Rua, Número, Cidade )
gerando a tabela resultante:
Telefone 1 Endereço
Cliente Código Telefone n Rua Número Cidade
sendo que a mesma não está na 1a Forma Normal pois seus atributos não são
atômicos. Para que a tabela acima fique na 1a Forma Normal temos que
eliminar os atributos não atômicos, gerando as seguintes tabelas como
resultado:
Cliente Código Rua Número Cidade
• 2a Forma Normal
A 2a Forma Normal prega o conceito da dependência funcional total. Uma
dependência funcional X Y é total se removemos um atributo A qualquer do
componente X e desta forma, a dependência funcional deixa de existir.
A dependência funcional X Y é uma dependência funcional parcial se
existir um atributo A qualquer do componente X que pode ser removido e a
dependência funcional X Y não deixa de existir.
{ RG_Empregado, Número_Projeto } Horas
• 3a Forma Normal
A 3a Forma Normal prega o conceito de dependência transitiva. Uma
tabela está na 3a Forma Normal se estiver na 2a Forma Normal e não
houver dependência transitiva entre atributos não chave.
Aspecto de Integridade
Restrição de Chave
• Uma relação deve ter pelo menos uma chave.
• Definição de chave: uma chave é um atributo ou conjunto de atributos
cujo valor ou combinação de valores deve ser distinto em qualquer
instância da relação.
• A existência de pelo menos uma chave é uma condição obrigatória,
tendo em vista que uma relação é definida como um conjunto de tuplas
e, todas as tuplas devem ter um valor distinto.
Restrição de Entidade
• Especifica que nenhum valor de chave primária pode ser nulo.
• Uma tupla em uma tabela que se refere a uma outra relação deve
referenciar uma tupla existente naquela relação.
Integridade Lógica
• Conjunto de regras que existem para o modelo de dados, assim como
um conjunto de regras de negócio, que regem a manipulação do BD, de
forma a não ferir nenhuma destas regras estabelecidas.
Integridade Física
• Conjunto de procedimentos operacionais que garantem a integridade do
BD, mesmo em situações de falha de algum componente do ambiente
onde o BD é manipulado.
• Exemplo:
• Valor mínimo de depósito para abertura de uma conta R$10.000,00
• Conta corrente sem movimento há 180 dias será encerrada.
Podem ser cumpridas e implementadas pelos SGBDs Relacionais, através
do mecanismo de Regras ou gatilhos (Triggers), hoje existentes no SQL.
Considerações Finais
Por hoje ficamos por aqui. Passamos por diversos pontos que consideramos
importantes para a prova (a repetição de alguns assuntos se faz necessária
para a memorização!!!)
Ótimos estudos, fiquem com DEUS e até a nossa próxima aula.
Um forte abraço,
Profa Patrícia
Referências Bibliográficas
QUINTÃO, Patrícia Lima. Notas de aula, 2011/2012.
BRAGA, Regina. Notas de aula, UFJF, 2012.
HEUSER, Carlos Alberto. Projeto de banco de dados. 4. ed. Porto Alegre:
Sagra, 2001. 204 p., il.
HERNANDEZ, Michael J. Aprenda a projetar seu próprio banco de dados.
Tradução Patrizia Tallia Parenti. São Paulo: Makron, 2000.
KORTH, Henry F.; SILBERSCHATZ, Abraham. Sistema de banco de dados.
Tradução Mauricio Heihachiro Galvan Abe. 2. ed. São Paulo: Makron, 1995.
MACHADO, Felipe Nery Rodrigues; ABREU, Maurício Pereira de. Projeto de
banco de dados: uma visão prática. 6. ed. São Paulo: Érica, 2000.
SETZER, Valdemar W. Banco de dados: conceitos, modelos,
gerenciadores, projeto lógico, projeto físico. 3. ed. rev. São Paulo: E.
Blücher, 2002. 289 p.
Revistas SQL Magazine (ed. 31 e 32).
TAKAI, O.K.; ITALIANO,I.C.; FERREIRA, E.F.Introdução a Banco de Dados.
2005.