Apostila de Banco de Dados e SQL

1
Apostila de Banco de Dados
1.) Banco de Dados
Definição: conjuntos de dados inter-relacionados que tem como objetivo atender a
uma comunidade de usuários.
A Informação é o valor fornecido pelo usuário e que será cadastrado no banco de
dados.
O Dado é o valor cadastrado no banco de dados, que é exportado para o usuário
por meio de consultas realizadas.
Todos nós sabemos existirem gigantescas bases de dados gerenciando nossas
vidas. De fato sabemos que nossa conta bancária faz parte de uma coleção imensa de
contas bancárias de nosso banco. Nosso Título Eleitoral ou nosso Cadastro de Pessoa
Física, certamente estão armazenados em Bancos de Dados colossais. Sabemos
também que quando sacamos dinheiro no Caixa Eletrônico de nosso banco, nosso saldo
e as movimentações existentes em nossa conta bancária já estão à nossa disposição.
Nestas situações sabemos que existe uma necessidade de se realizar o
armazenamento de uma série de informações que não se encontram efetivamente
isoladas umas das outras, ou seja, existe uma ampla gama de dados que se referem aos
relacionamentos existentes entre as informações a serem manipuladas.
Para registrarmos as necessidades de informação de uma realidade, precisamos
fazer uso de um modelo, ou seja, algo que nos mostre como as informações estão
relacionadas (fatos). E com base no modelo criado, os analistas podem interagir com os
usuários validando seus objetivos e metas, permitindo a construção de um sistema de
informações cada vez mais próximo da realidade do usuário.
Diagrama do Projeto de BD
1
Os Bancos de Dados, além de manterem todo um volume de dados organizado,
também devem permitir atualizações, inclusões e exclusões do volume de dados, sem
nunca perder a consistência. E na maioria das vezes ocorrerão acessos concorrentes a
várias tabelas do banco de dados, algumas vezes com mais de um acesso ao mesmo
registro de uma mesma tabela.
1
2
Um Banco de Dados contém os dados dispostos numa ordem pré-determinada em
função de um projeto de sistema, sempre para um propósito muito bem definido.
Um Banco de Dados representará sempre aspectos do Mundo Real. Assim sendo
uma Base de Dados (ou Banco de Dados, ou ainda BD) é uma fonte de onde poderemos
extrair uma vasta gama de informações derivadas, que possui um nível de interação com
eventos como o Mundo Real que representa.
Projeto
Conceitual
Projeto
Lógico
Projeto
Físico
2.) Sistemas de Banco de Dados
Com o passar do tempo às formas de compartilhamento de dados em BD foram se
desenvolvendo e se aprimorando. Vários problemas, como por exemplo redundância de
dados foram sendo sanados.
Inicialmente existia o sistema de processamento de arquivos e hoje nós trabalhamos
com os SGBDs.
2.1.) Sistema de Processamento de Arquivos
No Sistema de Processamento de Arquivos (sistemas isolados), há
subordinação dos programas aos arquivos, cada aplicação possui seus próprios dados e
tem seu próprio arquivo. Então os dados se tornam repetitivos, as informações
inconsistentes, há falta de integridade, há pouca proteção contra danos físicos aos
meios de armazenamento, mas a segurança contra o acesso indevido é boa, pelo fato
de só você ter acesso à sua aplicação, o programador se torna o “dono” da aplicação,
dificuldade no desenvolvimento de novas aplicações e a manutenção se torna difícil e
cara. A Figura 1 apresenta o sistema de processamento de arquivos.
Produção
Vendas
Compras
Arquivos de Produção
Arquivos de Produção
Arquivos de Produção
Produtos
Produtos
Produtos
Este esquema tem um grande número de desvantagens:
 Redundância de dados. Ocorre quando uma determinada informação está
representada no sistema em computador várias vezes. Existem dois tipos de
redundância de dados, a controlada e a não controlada. A redundância
controlada acontece quando o software tem conhecimento da múltipla
representação da informação e garante sincronia entre as diversas
2
3




representações. Na redundância não controlada, a responsabilidade pela
manutenção da sincronia entre as diversas representações de uma informação
está com o usuário e não com o software (deve ser evitado – entrada repetida da
mesma informação e inconsistências de dados). Por exemplo, o nome e o
endereço de um aluno poderão estar cadastrados no arquivo de turmas, no
arquivo de cursos extracurriculares e no arquivo de estagiários. Esta redundância
leva a altos custos de armazenamento e acesso.
Inconsistência de dados. A repetição de informações, pode ainda levar a
inconsistência de dados, que significa que as várias cópias do mesmo dado
podem ser diferentes. Por exemplo, um aluno muda de endereço duas vezes no
mesmo ano, no início desde ano, o endereço é “x” ao se cadastrar no colégio, já
no meio do semestre, após a primeira mudança, se matriculou em um curso extra
o endereço agora é “y” e no final do ano, após a segunda mudança, decidiu se
candidatar para futuros estágios e o endereço atual é “z”. Isto resulta em uma
inconsistência de dados.
Dificuldade no acesso aos dados. Suponha que um dos coordenadores da
escola necessite encontrar os nomes de todos os alunos que vivem num
determinado bairro para encaminha-los para estágios. O coordenador pede à
secretaria que gere tal lista. Caso este tipo de solicitação não tenha sido
antecipado quando o sistema original foi projetado, não há nenhum programa
aplicativo disponível para fazê-lo. Existe, entretanto, um programa aplicativo para
gerar uma lista de todos os alunos da escola. O coordenador tem agora duas
saídas: ou ele pega a lista de alunos e extrai a informação necessária
manualmente, ou pede que um programador escreva o programa aplicativo
necessário. Ambas as alternativas são obviamente insatisfatórias. Suponha que
tal programa tenha sido de fato escrito e que, alguns dias mais tarde, o mesmo
coordenador necessite destacar da mesma lista os alunos com média acima de
oito nas disciplinas técnicas. Como é de se esperar, um programa para gerar tal
lista não existe. Novamente, o coordenador tem duas opções, e nenhuma delas é
satisfatória.
Anomalias de acesso concorrente. Com a intenção de aperfeiçoar o
desempenho geral do sistema e obter tempos de resposta mais rápidos, muitos
sistemas permitem que múltiplos usuários atualizem os dados simultaneamente.
Em tal ambiente, a interação de atualizações concorrentes pode resultar em
dados inconsistentes.
Problemas de integridade. Os valores dos dados armazenados nos bancos de
dados precisam satisfazer certos tipos de restrições. Por exemplo, um aluno terá
a sua matrícula cancelada caso possua freqüência nula por três meses seguidos
sem justificativas. Entretanto, quando novas restrições são adicionadas, é difícil
alterar os programas. O problema torna-se mais complicado quando as restrições
envolvem diversos itens de dados de arquivos diferentes.
2.2.) Sistema de Gerenciamento (Gerenciador) de Banco de Dados
Hoje em dia, a grande maioria dos programas comunica-se com os usuários
utilizando interfaces gráficas de janelas. Entretanto, normalmente, os programas não
contém todo o código referente a exibição dos dados da interface, mas utilizam
gerenciadores de interface de usuário. Da mesma forma, para comunicar-se com
processos remotos, usam gerenciadores de comunicação. Para manter grandes
repositórios compartilhados de dados, ou seja, para manter banco de dados, são usados
Sistemas de Gerência de Bancos de Dados (SGBD).
3
4
No Sistema de Gerenciamento de Banco de Dados, existe um gerenciador entre
as aplicações e a base de dados comum a estas aplicações. Então reduz a redundância,
evita a inconsistência, mantém a integridade e a transparência de dados, utiliza “visões
do usuário”, atende as exigências de informações de todas as aplicações, facilita o
desenvolvimento de novas aplicações e a aplicação das restrições de segurança.
1.1.5
APLICAÇÃO1
1.1.6
1.1.3
1
APLICAÇÃO2
G
1.1.4
1.1.1
2
APLICAÇÃO3
B
1.1.2
3
S
D
Um SGBD é uma coleção de programas que permitem ao usuário definir, construir
e manipular Bases de Dados para as mais diversas finalidades.
Vamos definir algumas regras básicas e claras para um sistema de manipulação
de dados ser considerado um SGBD. Fica implícito que se ao menos uma das
características abaixo não estiver presente no nosso "candidato" a SGBD, este poderá
ser um GA (Gerenciador de Arquivo) de altíssima qualidade, "quase" um SGBD, mas não
um SGBD.
Regra 1: Auto-Contenção- Um SGBD não contém apenas os dados em si, mas
armazena completamente toda a descrição dos dados, seus relacionamentos e formas de
acesso. Normalmente esta regra é chamada de Meta-Base de Dados. Em um GA, em
algum momento ao menos, os programas aplicativos declaram estruturas (algo que
ocorre tipicamente em C, COBOL e BASIC), ou geram os relacionamentos entre os
arquivos (típicos do ambiente xBase). Por exemplo, quando você é obrigado a definir a
forma do registro em seu programa, você não está lidando com um SGBD.
Regra 2: Independência dos Dados- Quando as aplicações estiverem realmente
imunes a mudanças na estrutura de armazenamento ou na estratégia de acesso aos
dados, podemos dizer que esta regra foi atingida. Portanto, nenhuma definição dos dados
deverá estar contida nos programas da aplicação. Quando você resolve criar uma nova
forma de acesso, um novo índice, se precisar alterar o código de seu aplicativo, você não
está lidando com um SGBD.
Regra 3: Abstração dos Dados- Em um SGBD real é fornecida ao usuário
somente uma representação conceitual dos dados, o que não inclui maiores detalhes
sobre sua forma de armazenamento real. O chamado Modelo de Dados é um tipo de
abstração utilizada para fornecer esta representação conceitual. Neste modelo, um
esquema das tabelas, seus relacionamentos e suas chaves de acesso são exibidas ao
usuário, porém nada é afirmado sobre a criação dos índices, ou como serão mantidos, ou
qual a relação existente entre as tabelas que deverá ser mantida íntegra. Assim se você
desejar inserir um pedido em um cliente inexistente e esta entrada não for
automaticamente rejeitada, você não está lidando com um SGBD.
Regra 4: Visões- Um SGBD deve permitir que cada usuário visualize os dados de
forma diferente daquela existente previamente no Banco de Dados. Uma visão consiste
4
5
de um subconjunto de dados do Banco de Dados, necessariamente derivados dos
existentes no Banco de Dados.
OBS.: ABSTRAÇÃO DE DADOS
Um SGBD é composto de uma coleção de arquivos inter-relacionados e de um
conjunto de programas que permitem aos usuários fazer acesso e modificar esses
arquivos. O grande objetivo de um sistema de bancos de dados é prover os usuários uma
visão abstrata dos dados, isto é, o sistema omite certos detalhes de como os dados são
armazenados e mantidos. Entretanto, para que o sistema possa ser utilizado, os dados
devem ser buscados eficientemente. Este conceito de abstração de dados tem
direcionado o projeto de estruturas de dados complexos para a representação de dados
em banco de dados. Uma vez que muitos dos usuários de banco de dados não são
treinados em computação, a complexidade está escondida deles através de diversos
níveis de abstração que simplificam a interação dos usuários com o sistema.
 Nível físico. O nível mais baixo de abstração descreve como os dados estão
realmente armazenados. No nível físico são descritas a estrutura física de
armazenamento do banco de dados, sua organização de arquivos e seus
métodos de acesso.
 Nível conceitual. Neste nível de abstração descreve quais dados estão
armazenados de fato no banco de dados e as relações que existem entre eles. O
nível conceitual é a visão do conjunto de usuários, portanto a visão geral do
banco de dados.
 Nível de visões. O mais alto nível de abstração descreve apenas parte do banco
de dados. O nível de visões é o mais próximo dos usuários. Voltado para a forma
como os dados são vistos pelos usuários individuais. Um determinado usuário,
tanto pode ser um programador de aplicações como um usuário de terminal online ou um usuário final de qualquer grau de sofisticação. Descreve as partes do
banco de dados que são do interesse de um ou vários usuários, escondendo as
demais partes que não são do seu interesse.
NÍVEL DE VISÕES
(VISÃO DO USUÁRIO INDIVIDUAL)
NÍVEL CONCEITUAL
(VISÃO DO CONJUNTO DE USUÁRIOS)
NÍVEL FÍSICO
(VISÃO DO ARMAZENAMENTO)
Regra 5: Transações- Um SGBD deve gerenciar completamente a integridade
referencial definida em seu esquema, sem precisar em tempo algum, do auxílio do
5
6
programa aplicativo. Desta forma exige-se que o banco de dados tenha ao menos uma
instrução que permita a gravação de uma série modificações simultâneas e uma
instrução capaz de cancelar uma série modificações. Por exemplo, imaginemos que
estejamos cadastrando um pedido para um cliente, que este deseje reservar 5 itens de
nosso estoque, que estão disponíveis e portanto são reservados, porém existe um
bloqueio financeiro (duplicatas em atraso) que impede a venda. A transação deverá ser
desfeita com apenas uma instrução ao Banco de Dados, sem qualquer modificação
suplementares nos dados. Caso você se obrigue a corrigir as reservas, através de
acessos complementares, você não está lidando com um SGBD.
Regra 6: Acesso Automático- Em um GA uma situação típica é o chamado DeadLock, o abraço mortal. Esta situação indesejável pode ocorrer toda vez que um usuário
travou um registro em uma tabela e seu próximo passo será travar um registro em uma
tabela relacionada à primeira, porém se este registro estiver previamente travado por
outro usuário, o primeiro usuário ficará paralisado, pois, estará esperando o segundo
usuário liberar o registro em uso, para que então possa travá-lo e prosseguir sua tarefa.
Se por hipótese o segundo usuário necessitar travar o registro travado pelo primeiro
usuário, afirmamos que ocorreu um abraço mortal, pois cada usuário travou um registro e
precisa travar um outro, justamente o registro anteriormente travado pelo outro.
Imaginemos um caso onde o responsável pelos pedidos acabou de travar o Registro Item
de Pedido, e, necessita travar um registro no Cadastro de Produtos, para indicar uma
nova reserva. Se concomitantemente estiver sendo realizada uma tarefa de atualização
de pendências na Tabela de Itens, e para tanto, previamente este segundo usuário travou
a Tabela de Produtos, temos a ocorrência do abraço mortal. Se a responsabilidade de
evitar esta ocorrência for responsabilidade da aplicação, você não está lidando com um
SGBD.
Um SGBD deve obedecer INTEGRALMENTE às seis
regras acima. Em caso contrário estaremos diante de
um GA ou de um "quase" SGBD.
3.) Os Profissionais
Os Administradores de Banco de Dados (DBA) são responsáveis pelo controle
ao acesso aos dados e pela coordenação da utilização do BD.
Os Projetistas de Banco de Dados (DBP) são analistas que identificam os dados
a serem armazenados em um Banco de Dados e pela forma como estes serão
representados.
Os Analistas e Programadores de Desenvolvimento, criam sistemas que
acessam os dados da forma necessária ao Usuário Final, que é aquele que interage
diretamente com o Banco de Dados.
4.) Modelos de Banco de Dados
Definição: descrição formal da estrutura de um banco de dados.
Um modelo de banco de dados é uma descrição dos tipos de informações que
estão armazenados em um banco de dados. Ex.: Um modelo de dados não informa quais
os produtos que estão armazenados em um banco de dados, mas apenas que o banco
de dados contém informações sobre o produto.
6
7
Podem ser usados modelos diferentes para explicar a cada nível de usuário como
é a organização de um banco de dados.
Definição: Abordagem de modelagem é o conjunto de conceitos usados para
construir modelos.
Existem os modelos: Conceitual, Lógico e Físico.
4.1.) Modelo Conceitual
É uma descrição da estrutura do banco de dados de forma independente de
implementação em SGBD.
A técnica de modelagem conceitual mais difundida é a abordagem entidaderelcionamento(ER). Esta técnica faz uso de um diagrama chamado diagrama entidaderelcionamento(DER)
(1,1)
Disciplina
(1,m)
POSSUI
Professor
4.2.) Modelo Lógico
Representa a estrutura de dados de um BD conforme vista pelo usuário do SGBD.
O Modelo lógico é dependente do tipo particular de SGBD que está sendo usado.
Exemplo de modelo lógico:
Disciplina(CodDisc, Descrição, CargaHoraria)
Professor(CPF, Nome, Tel, Ender, FormAcad)
4.3.) Modelo Físico
Leva em consideração detalhes de armazenamento interno de informações. As
linguagens utilizadas neste modelo variam de SGBD para SGBD.
5.) Projeto de Banco de Dados
O projeto de um novo banco de dados dá-se em três fases:
a. Modelagem Conceitual
Nesta primeira fase, é construído um modelo conceitual, na forma de um
diagrama entidade-relacionamento. Este modelo independe da implementação.
b. Projeto Lógico
Objetiva transformar o modelo conceitual obtido na primeira fase em um
modelo lógico. O modelo lógico define como o banco de dados será
implementado em um SGBD específico.
c. Projeto Físico
Nesta etapa, o modelo de BD é enriquecido com detalhes que influenciam no
desempenho do BD, mas não interferem em sua funcionalidade. Alterações
neste modelo não afetam as aplicações que usam o BD.
Exercícios:
7
8
1-) Diga as principais diferenças entre o desenvolvimento de software com arquivos
convencionais e desenvolvimento de software com SGBD.
2-) Diga, com as suas próprias palavras o que é um BD?
3-) Diga, com as suas próprias palavras o que é um SGBD?
4-) Descreva os modelos.
5-) Diga o que acontece em cada fase do projeto de BD.
6-) Um programador recebe um documento especificando precisamente a estrutura do
BD. O programador deverá construir software para acessar o BD através do SGBD
conforme a estrutura. Esse documento é um modelo conceitual, um modelo lógico ou um
modelo físico?
7-) A definição de um tipo de dado (numérico, data, ...) faz parte do modelo conceitual, do
modelo lógico ou do modelo físico?
8-) Qual a diferença entre a redundância de dados controlada e a não controlada?
9-) O que é inconsistência de dados?
10-) O que é o DER? Qual a sua finalidade?
11-) Qual é a finalidade da abstração em um SGBD?
12-) Qual o profissional que é responsável pela liberação de senhas para o uso do BD?
13-) Explique o motivo pelo qual nos sistemas isolados é tão difícil de realizar uma ação
não prevista. Construa um exemplo.
8
9
6.) Abordagem Entidade-Relacionamento
Foi criada por Peter Chen e é a mais usada. Os conceito centrais da abordagem
ER são: entidades, relacionamentos, atributos, generalização/especialização e entidade
associativa.
6.1.) Entidade
Definição: conjuntos de objetos (coisas) da realidade modelada sobre os quais
deseja-se manter informações no BD.
Uma entidade pode representar tanto objetos concretos( um pessoa, um
automóvel, ...) como objetos abstratos (um departamento, um endereço,...)
No DER as entidades são representadas por retângulos:
Aluno
Geralmente os nomes das entidades são formadas por substantivos no singular.
6.2.) Relacionamento
Definição: conjunto de associações entre ocorrências de entidades.
No DER os relacionamentos são representados por losangos:
Geralmente os nomes dos relacionamentos são formados por verbos ou pela
composição dos nomes das entidades que fazem parte do relacionamento em questão.
Exemplos de relacionamentos:
ESCREVE
AUTOR
n
ALUNO
LIVRO
1
ALDIPRO
m
PESSOA
PROFESSOR
CASADA
DISCIPLINA
9
10
6.2.1) TIPOS DE RELACIONAMENTOS
Unário: é um relacionamento que envolve uma única entidade.
casado
com
Pessoas
Binário: é um relacionamento que envolve duas entidades.
Funcionário
Produz
Produto
Ternário: é um relacionamento que envolve três entidades.
Funcionário
Produz/
Utiliza
Produto
Ferramenta
Quaternário: é um relacionamento que envolve quatro entidades.
Máquina
Funcionário
Produz/
Utiliza/
Opera
Produto
Ferramenta
6.2.2) CARDINALIDADE DE RELACIONAMENTOS
Uma restrição importante é o mapeamento de cardinalidade que expressa o número
de entidades ao qual outra entidade pode estar associada via um conjunto de
relacionamentos. Há duas cardinalidades a considerar: a cardinalidade máxima e a
cardinalidade mínima. A cardinalidade indica quantas ocorrências de entidade (no
mínimo ou no máximo) podem estar associadas através de um relacionamento.
Para o projeto de banco de dados, apenas duas cardinalidades máximas são
relevantes: a cardinalidade máxima 1 e a cardinalidade máxima muitos, referida pela
10
11
letra m. A cardinalidade máxima é usada para classificar relacionamentos binários.
Relacionamentos binários são aqueles cujas ocorrências envolvem duas entidades.
Portanto havendo relacionamento entre duas entidades, a próxima etapa é
identificar a cardinalidade, ou seja, quantos registros de uma entidade A estão
associados a um registro da entidade B e vice-versa. Os registros podem estar
associados de três modos diferentes:
 Relacionamento um para um (1:1): O relacionamento um para um ocorre
quando, para cada uma ocorrência na entidade A, temos somente uma
ocorrência na entidade B;
 Relacionamento um para muitos (1:m): Este é o relacionamento em que temos
n ocorrências de uma entidade associada a uma ocorrência de outra entidade;
 Relacionamento muitos para muitos (n:m): Neste tipo de relacionamento, não
existe restrição na formação das associações, ou seja, uma ocorrência da A pode
estar associada a n ocorrências de uma entidade B e vice versa.
1
1
COORDENA
COORDEADOR
m
1
DISCIPLINA
CURSO
PROFESSOR
POSSUI
n
ALUNO
m
DISCIPLINA
ALUDIS
Relacionamento Um-para-Um (1:1)
Neste grau de relacionamento, cada elemento de uma entidade relaciona-se com um e
somente um elemento de outra identidade.
Sentido de leitura
1
homem
homem
1
mulher
casado
1
1
casado
mulher
Resultado: (1:N)
11
12
Relacionamento de Um-para-Muitos (1:N)
Este grau de relacionamento é o mais comum no mundo real, sendo o que
denominamos de relacionamento básico entre entidades, entretanto possui
características específicas, quanto ao sentido de leitura dos fatos e sua interpretação.
Um elemento da entidade 1 relaciona-se com muitos elementos da unidade 2, mas
cada elemento da entidade 2 somente pode estar relacionado a um elemento da
entidade 1. Ou seja, o grau de cardinalidade deterninante sempre é o maior grau
obtido da interpretação dos fatos.
Sentido de leitura
time
1
time
1
N
possui
1
possui
jogadores
jogadores
Resultado: (1:N)
Relacionamento de Muitos-para-Muitos (N:N)
Identifica-se esta cardinalidade pelo fato de que em ambos os sentidos de leitura
encontramos um grau Um-para-Muitos, o que caracteriza ser então um contexto geral
de Muitos-para-Muitos.
sentido de leitura
time
1
time
N
N
possui
1
possui
jogadores
jogadores
Resultado (N:N)
12
13
Existem casos em que os relacionamentos acontecem entre mais de duas
entidades. Estes relacionamentos de grau maior do que dois (relacionamentos ternários,
quaternários,...). No caso de relacionamentos de grau maior que dois, o conceito de
cardinalidade de relacionamento é uma extensão não trivial do conceito de cardinalidade
em relacionamentos binários. Lembre-se que, em um relacionamento binário R entre
duas entidades A e B, a cardinalidade máxima de A em R indica quantas ocorrências de
B podem estar associadas a cada ocorrência A No caso de um relacionamento ternário, a
cardinalidade refere-se a pares de entidades. Em um relacionamento R entre três
entidades A, B e C, a cardinalidade máxima de A e B dentro de R indica quantas
ocorrências de C podem estar associadas a um par de ocorrências de A e B.
Obs.: No DER podemos usar, para indicar um relacionamento identificador, uma
linha mais densa.
1
N
RESPON
DIRETOR
SETOR
6.2.3) OUTRA NOTAÇÃO (ENGENHARIA DE INFORMAÇÕES)
A Engenharia de Informações é um método de desenvolvimento de sistemas de
informação proposto no início da década de 80, por Martin e Finkelstein.
Ex.:
(1,1)
(0,N)
RESPON
DIRETOR
SETOR
Código
Nome
CódigoSet
NomeSet
Cardinalidade:
Max e Min. Um(1)
Min zero(0)
Max Muitos(N)
13
14
6.3.) Atributo
Definição: São os dados que compõem a entidade.
Algumas vezes os atributos não são colocados no diagrama para não
sobrecarregar, nestes casos usa-se uma descrição textual.
ALUNO
MAT
Nome
Atributo identificador é o conjunto de um ou mais atributos que servem para
determinar uma ocorrência da entidade em relação as outras ocorrências.
Um atributo pode possuir uma cardinalidade, de maneira análoga a uma entidade
em um relacionamento. No caso de a cardinalidade ser (1,1) ela pode ser omitida do
diagrama.
ALUNO
Mat
Nome Telefone(0,n)
O nome a matrícula são atributos obrigatórios(1,1), possuem no mínimo um valor
associado na entidade e no máximo um valor associado.
O telefone é um atributo opcional(0,1), pode possuir no mínimo nenhuma
ocorrência e no máximo várias.
Exercícios:
1-) Explique a diferença entre entidade e ocorrência de entidade.
2-) Dê exemplos de entidades com vários tipos de identificadores:
 Uma entidade cujo identificador é composto por único atributo,
 Um relacionamento cujo identificador é composto por mais de um atributo,
3-) Dê no mínimo 5 exemplos de:entidades, atributo e atributo identificador.
4-) Baseado no DER abaixo,descreva o possível mini-mundo que o gerou.
N
PRODUTO
N
TEM
FABRICANTE
14
15
5-) Deseja-se modelar os clientes de uma organização. Cada cliente possui um
identificador, um nome, um endereço e um país. Discuta as vantagens e desvantagens
das duas alternativas de modelagem de país:
a-) Como atributo da entidade cliente;
b-) Como entidade relacionada a cliente.
6-) Transforme o DER do exercício 4 para a notação da Engenharia da Informação.
7.) Modelo Relacional
Definição: representa e/ou descreve a realidade do ambiente do problema,
constituindo-se em uma visão global dos principais dados e relacionamentos,
independente de restrições de implementação.
Quanto mais organizadas estiverem as informações no Banco de Dados, mais
fácil será a “conversa” com o Gerenciador de Banco de Dados.
Para isso, criou-se um modelo chamado Modelo de Entidades e
Relacionamentos, do qual fazem parte três elementos:
Entidades
Entidades
Relacionamentos
Relacionamentos
Atributos
Atributos
Existe
Existe como
como
Tabelas
Tabelas
Colunas
ou Tabelas
Colunas
Colunas
(ou
(ou Campos)
Campos)
numa
numa Tabela
Tabela
Exemplos
Exemplos
Informação
Informação de
de
um
um cliente;
cliente;
informação
informação de
de
um
um pedido
pedido
Pedidos
Pedidos de
de
um
um cliente
cliente
Nome,
Nome,
Endereço,
Endereço,
Telefone
Telefone do
do
cliente
cliente
a. Entidades
Uma entidade é um objeto de interesse do qual podem ser colecionadas
informações. Elas são representadas por tabelas. Exemplos: tabela de clientes; tabela de
pedidos de clientes.
b. Relacionamentos
As entidades podem ser relacionadas entre si pelos relacionamentos. Por
exemplo: relacionamento entre a entidade de clientes e a entidade de pedidos ( “clientes
fazem pedidos”).
c. Atributos
Atributos são as características das entidades. São representadas pelas colunas
das tabelas. Por exemplo: nome, endereço do cliente.
15
16
clientes
identificador
1001
1002
1003
1004
1005
1006
nome
endereço telefone
João
Alberto
Franciso
Maria
Sônia
Roberto
…….
…….
……..
……..
……...
……….
5554444
4687999
NULL
5678900
0988855
NULL
……...
~~~
~~~
~~~
~~~
~~~
Uma das colunas de uma tabela é uma primary key (chave primária). Isso indica
para o gerenciador de banco de dados que uma coluna (ou um conjunto de colunas) deve
ter um valor único para identificar a linha inteira. O gerenciador faz então o controle
para que não entrem duas linhas com o mesmo valor na coluna que é primary key.
A figura a seguir demonstra o relacionamento entre tabelas utilizando-se chaves
primárias (PK) e estrangeiras (Foreign Key).
clientes
identificador
nome
……….
PK
NN
NN
1001
1002
1008
João
Alberto.
Wilson
S…..
S…..
…….
……
NN
….
….
….
…..
…….
…………..
NN
98022
98022
98026
NULL
05 Jun 1992
206-555-1212 07 Ago 1992
NULL
03 Mar 1993
Pedidos
numero
cliente
PK
PK,FK, NN
1
1
2
1002
1001
1001
produto
NN
567
566
122
Pedidos se relacionam aos Clientes, através do campo cliente da tabela de
pedidos. Esse campo é também denominado chave estrangeira (foreign key). Isso
garante o que é denominado integridade referencial: ou seja, não pode haver
inconsistência nas linhas que estão associadas nas tabelas. Por exemplo: o gerenciador
não permite que clientes que tenham pedidos sejam removidos da tabela clientes, nem
que pedidos sejam realizados por clientes inexistentes.
Cada linha de nossa relação será chamada de TUPLA e cada coluna de nossa
relação será chamada de ATRIBUTO. O conjunto de valores passíveis de serem
assumidos por um atributo, será intitulado de DOMÍNIO.
O domínio consiste de um grupo de valores atômicos a partir dos quais um ou
mais atributos retiram seus valores reais. Assim sendo Rio de Janeiro, Paraná e Pará são
estados válidos para o Brasil, enquanto que Corrientes não é um estado válido (pertence
a Argentina e não ao Brasil).
16
17
O esquema de uma relação, nada mais é que os campos (colunas) existentes em
uma tabela. Já a instância da relação consiste no conjunto de valores que cada atributo
assume em um determinado instante. Portanto, os dados armazenados no Banco de
Dados, são formados pelas instâncias das relações.
As relações não podem ser duplicadas (não podem existir dois estados do Pará,
no conjunto de estados brasileiros, por exemplo), a ordem de entrada de dados no Banco
de Dados não deverá ter qualquer importância para as relações, no que concerne ao seu
tratamento.
Chamaremos de Chave Primária ao Atributo que definir um registro, dentre uma
coleção de registros. Chave Secundária (Terciária, etc), serão chaves que possibilitarão
pesquisas ou ordenações alternativas, ou seja, diferentes da ordem criada a partir da
chave primária ou da ordenação natural (física) da tabela. Chamaremos de Chave
Composta, aquela chave que contém mais de um atributo (Por exemplo um cadastro
ordenado alfabeticamente por Estado, Cidade e Nome do Cliente, necessitaria de uma
chave composta que contivesse estes três atributos). Chamaremos de Chave
Estrangeira, aquela chave que permitir a ligação lógica entre uma tabela (onde ela se
encontra) com outra na qual ele é chave primária.
Exemplo:
Cidade
Estado
* CidCodi
* EstCodi
CidNome
EstNome
EstCodi (E)
CidCodi e EstCodi, são chaves primárias respectivamente das tabelas Cidade e
Estado, enquanto EstCodi é chave estrangeira na tabela de cidades. É precisamente por
este campo (atributo, ou coluna), que será estabelecida a relação entre as tabelas
Cidade-->Estado.
Obs.:
Database
Tabela
Obs.:
 Integridade da entidade: Não se permite a nenhum atributo que participe da
chave primária de uma relação que aceite o valor nulo;
 Integridade referencial: Não se permite alterar o valor da chave primária de uma
relação, sem alterar o valor da chave externa de uma tabela relacionada. Como
também não se pode inserir um registro em uma tabela relacionada, a menos que
o registro se ligue ou se conecte a um registro da tabela primária.
Bibliografia
Projeto de Banco de Dados – Uma Visão Prática
Felipe Machado; Maurício Abreu – Editora Érica
17