Administração e Projeto de banco de dados - Turma 3B

Administração e Projeto de Banco de Dados
Administração e
Projeto de
banco de dados
2011
Conceito de banco de dados. Modelagem conceitual de
dados. Formas normais. Projeto lógico e físico, segundo o
modelo relacional.
Sistemas de
Informação e
Processamento de
dados
Página 1
Administração e Projeto de Banco de Dados
Conteúdo
1.
Introdução e conceitos gerais ____________________ 4
1.1
Banco de dados ________________________________________5
1.2
Sistema de Banco de Dados ______________________________6
1.2.1
Principais componentes de um Sistema de Banco de Dados ________ 6
1.2.1.1
Dados ________________________________________________ 6
1.2.1.2
Hardware _____________________________________________ 7
1.2.1.3
Software ______________________________________________ 7
1.2.1.4
Usuários ______________________________________________ 7
1.2.1.4.1
Usuários finais: _______________________________________ 8
1.2.1.5
Administrador de Banco de Dados (DBA) _____________________ 8
1.2.1.6
Projetista de Banco de Dados (Administrador de Dados) _________ 8
1.2.1.7
Analistas de Sistemas e Programadores de Aplicações __________ 8
1.2.2
Por que um Sistema de Banco de Dados? ______________________ 9
1.2.3
Vantagens tecnológicas da utilização de um Sistema de Banco de
Dados 9
1.2.4
Quando não Utilizar um SGBD ______________________________ 10
1.2.5
Arquitetura de sistemas de banco de dados. ___________________ 11
1.2.5.1
Os três níveis da arquitetura: _____________________________ 11
1.2.5.2
Independência de Dados_________________________________ 12
1.3
Sistema de Gerenciamento de Bancos de Dados (SGBD) _______13
1.3.1
Funções do SGBD ________________________________________ 13
1.3.2
Estrutura geral do SGBD __________________________________ 13
1.4
Linguagens para Manipulação de Dados ____________________16
1.5
Modelos de Bancos de Dados _________________________________ 17
1.5.1
O Modelo Hierárquico _____________________________________ 17
1.5.2
O modelo de Rede _______________________________________ 18
1.5.3
O Modelo Relacional ______________________________________ 20
1.5.4
O Modelo Orientado a Objetos ______________________________ 21
2.
Modelagem de Dados __________________________ 22
2.1
Modelo Conceitual de Dados (MCD) ____________________________ 22
2.1.1
Modelo Lógico de Dados (MLD) _____________________________ 23
2.1.2
Modelo Físico de Dados (MFD) ______________________________ 23
2.2
Modelo E-R __________________________________________23
2.2.1
Entidade _______________________________________________ 25
2.2.2
Atributo _______________________________________________ 26
2.2.3
Descritivo: _____________________________________________ 26
2.2.4
Identificador: ___________________________________________ 26
2.2.5
Composto: _____________________________________________ 26
2.2.6
Derivado: ______________________________________________ 26
2.2.7
Multivalorado: __________________________________________ 26
2.2.8
Relacionamento _________________________________________ 27
2.2.9
Grau do Relacionamento ou Cardinalidade ____________________ 28
2.2.9.1
Relacionamento Um-para-Um (1:1) ________________________ 28
Página 2
Administração e Projeto de Banco de Dados
2.2.9.2
Relacionamento Um-para-Muitos (1:N) _____________________ 29
2.2.9.3
Relacionamento Muitos-para-Muitos (N:N) ___________________ 30
2.3
Participação ______________________________________________ 31
2.4
Relacionamentos Reflexivos (auto-relacionamento) _______________ 33
2.5
Extensões do Modelo Entidade x Relacionamento ____________33
2.5.1
Relacionamentos entre Múltiplas Entidades ____________________ 33
2.5.1.1
Entidade associativa ____________________________________ 34
2.5.1.2
Agregação ____________________________________________ 35
2.5.1.3
Generalização (Supertipos) e Especialização (Subtipos) ________ 36
2.5.1.3.1
Generalização _______________________________________ 36
2.5.1.3.2
Especialização _______________________________________ 37
2.5.1.3.3
Generalização X Especialização __________________________ 37
3.
Bancos de Dados Relacionais ____________________ 38
3.1
Definição ____________________________________________38
3.2
Tabela Relacional _____________________________________39
3.3
O conceito de Chave no Modelo Relacional __________________40
3.3.1
Chave Primária (Primary Key) ______________________________ 40
3.3.2
Chave Estrangeira (Foreign Key) ____________________________ 42
3.3.3
Chave Candidata ________________________________________ 43
3.3.4
Chave Secundária (Secundary Key) __________________________ 43
3.4
Regras de Integridade do Modelo Relacional ________________43
3.4.1
Integridade de Identidade _________________________________ 43
3.4.2
Integridade Referencial ___________________________________ 43
3.5
Características do Modelo Relacional ______________________44
4.
Derivação do Modelo Entidade x Relacionamento para o
Modelo Lógico Relacional ___________________________ 44
4.1
Regras de Conversão ___________________________________44
4.2
Mapeamento de Entidades ___________________________________ 44
4.3
Mapeando atributos ________________________________________ 44
4.4
Relacionamento 1:N (envolvendo entidades distintas) _____________ 44
4.5
Relacionamento 1:N (envolvendo auto-relacionamento) ___________ 45
4.6
Relacionamento 1:1 ________________________________________ 45
4.7
Relacionamento N:N _______________________________________ 47
4.8
Relacionamento Múltiplo ____________________________________ 47
4.9
Generalizações ____________________________________________ 47
5.
Normalização de Dados ________________________ 49
5.1
Definição ____________________________________________49
5.2
Primeira Forma Normal (1FN) ________________________________ 50
5.3
Segunda Forma Normal (2FN) - Dependências Funcionais __________ 51
5.4
- Terceira Forma Normal (3FN) - Dependências Transitivas _________ 51
5.5
Quarta Forma Normal (4FN) _________________________________ 53
5.6
Quinta Forma Normal (5FN) _________________________________ 54
Bibliografia ____________________________________________________ 57
Página 3
Administração e Projeto de Banco de Dados
1. Introdução e conceitos gerais
Igualmente a muitas tecnologias na computação industrial, os fundamentos de
bancos de dados relacionais surgiram na empresa IBM, nas décadas de 1960 e
1970, através de pesquisas de funções de automação de escritório. Foi durante
um período da história na qual empresas descobriram que estava muito
custoso empregar um número grande de pessoas para fazer trabalhos como
armazenar e indexar (organizar) arquivos. Por este motivo, valia a pena os
esforços e investimentos em pesquisar um meio mais barato e ter uma solução
mecânica eficiente.
Muitas pesquisas foram conduzidas durante este período, cujos modelo
hierárquicos, de rede e relacionais e outros modelos foram descobertos, bem
como muita tecnologia utilizada hoje em dia.
Em 1970 um pesquisador da IBM - Ted Codd - publicou o primeiro artigo sobre
bancos de dados relacionais. Este artigo tratava sobre o uso de cálculo e
álgebra relacional para permitir que usuários não técnicos armazenassem e
recuperassem grande quantidade de informações. Codd visionava um sistema
onde o usuário seria capaz de acessar as informações através de comandos em
inglês, onde as informações estariam armazenadas em tabelas.
Devido à natureza técnica deste artigo e a relativa complicação matemática, o
significado e proposição do artigo não foram prontamente realizados.
Entretanto ele levou a IBM a montar um grupo de pesquisa conhecido
como System R (Sistema R).
O projeto do Sistema R era criar um sistema de banco de dados relacional o
qual eventualmente se tornaria um produto. Os primeiros protótipos foram
utilizados por muitas organizações, tais como MIT Sloan School of Management
(uma escola renomada de negócios norte-americana). Novas versões foram
testadas com empresas aviação para rastreamento do manufaturamento de
estoque.
Eventualmente o Sistema R evoluiu para SQL/DS, o qual posteriormente
tornou-se o DB2. A linguagem criada pelo grupo do Sistema R foi aStructured
Query Language (SQL) - Linguagem de Consulta Estruturada). Esta linguagem
tornou-se um padrão na indústria para bancos de dados relacionais e hoje em
dia é um padrão ISO (International Organization for Standardization). A ISO é
a Organização Internacional de Padronização. A linguagem SQL era
originalmente conhecida como SEQUEL (Structured English QUEry Language) e
depois foi abreviada como SQL.
Os primeiros do mercado
Mesmo a IBM sendo a companhia que inventou o conceito original e o padrão
SQL, eles não produziram o primeiro sistema comercial de banco de dados. O
feito foi realizado pela Honeywell Information Systems Inc., cujo sistema foi
lançado em junho de 1976. O sistema era baseado em muitos princípios do
sistema que a IBM concebeu, mas foi modelado e implementado fora da IBM.
O primeiro sistema de banco de dados construído baseado nos padrões SQL
começaram a aparecer no início dos anos 80 com a empresa Oracle através do
Página 4
Administração e Projeto de Banco de Dados
Oracle 2 e depois com a IBM através do SQL/DS, servindo como sistema e
repositório de informações de outras empresas.
Estes sistemas somente nasceram a partir da insistência de um jornal técnico
em utilizar BNF para SQL e este jornal publicou tal artigou. BNF é o conjunto de
sintaxes de linguagem de computador que explica exatamente como cada
comando interage com os outros comandos e o que pode ou não ser realizado,
como os comandos são formados em assim por diante. Por causa da publicação
deste artigo, empresas puderam utilizá-lo para modelar seus próprios sistemas,
os quais seriam 100% compatíveis com o sistema da IBM.
Dado, Informação e Conhecimento
Dado é qualquer elemento identificado em sua forma bruta que, por si só, não
conduz a uma compreensão de determinado fato ou situação (Oliveira, 2005)
Informação é o dado trabalhado que agrupado de maneira lógica permite aos
usuários desta informação tomar decisões. (Oliveira, 2005)
Conhecimento é a informação associada em múltiplos contextos. Segundo
Laudon e Laudon 1999, conhecimento é o conjunto de ferramentas conceituais
e categorias usadas pelos seres humanos para criar, colecionar, armazenar e
compartilhar a informação.
Figura 1 Relação entre dado, informação e conhecimento.
1.1
Banco de dados
Um “banco de dados” pode ser definido como um conjunto de “dados”
devidamente relacionados. Por “dados” podemos compreender como “fatos
conhecidos” que podem ser armazenados e que possuem um significado
implícito. Porém, o significado do termo “banco de dados” é mais restrito que
simplesmente a definição dada acima. Um banco de dados possui as seguintes
propriedades:
 um banco de dados é uma coleção lógica coerente de dados com um
significado inerente; uma disposição desordenada dos dados não pode ser
referenciada como um banco de dados;
Página 5
Administração e Projeto de Banco de Dados
 um banco de dados é projetado, construído e preenchido com dados para
um propósito específico; um banco de dados possui um conjunto pré
definido de usuários e aplicações;
 um banco de dados representa algum aspecto do mundo real, o qual é
chamado de “mini-mundo” ; qualquer alteração efetuada no mini-mundo é
automaticamente refletida no banco de dados.
Um banco de dados pode ser criado e mantido por um conjunto de aplicações
desenvolvidas especialmente para esta tarefa ou por um “Sistema Gerenciador
de Banco de Dados” (SGBD). Um SGBD permite aos usuários criarem e
manipularem bancos de dados de propósito gerais. O conjunto formado por um
banco de dados mais as aplicações que manipulam o mesmo é chamado de
“Sistema de Banco de Dados”.
Sistema de Banco de Dados
1.2
Segundo C. J. Date um sistema de banco de dados é basicamente um
sistema computadorizado de manutenção de registros. O banco de dados, por si
só, pode ser considerado como o equivalente eletrônico de um armário de
arquivamento, ou seja, ele é um repositório ou recipiente para uma coleção de
arquivos de dados computadorizados, de modo geral a finalidade de um banco
de dados é armazenar informações e permitir que os usuários busquem e
atualizem essas informações quando forem requisitadas. As informações em
questão podem ser qualquer coisa que tenha um significado ao individuo ou à
organização a que o sistema deve servir. Os usuários de um sistema podem
realizar (ou melhor, solicitar que o sistema realize) diversas operações
envolvendo tais arquivos, como por exemplo:






Acrescentar novos arquivos ao banco de dados
Inserir dados em arquivos existentes
Buscar dados de arquivos existentes
Alterar dados de arquivos existentes
Excluir dados de arquivos existentes
Remover arquivos existentes do banco de dados
1.2.1
Principais componentes de um Sistema de Banco de Dados
Um sistema de banco de dados envolve 4 componentes principais:




Dados
Hardware
Software
Usuários
1.2.1.1
Dados
É comum em um banco de dados referir-se aos dados como dados
“persistentes”, ou seja, podemos sugerir intuitivamente que esses dados
ficam armazenados no banco de dados e só podem ser removidos por uma
requisição explícita ao mesmo. Isso difere de outros tipos de dados, como, por
exemplo, dados de entrada, dados de saída, filas de trabalho, instruções SQL e
quaisquer outros que possuam natureza transitória.
Página 6
Administração e Projeto de Banco de Dados
Os dados em um
compartilhados
sistema
de
banco
de
dados
são
integrados
e
Por integrado, queremos dizer que o banco de dados pode ser considerado
como uma unificação de vários arquivos que, de outro modo, seriam distintos,
com a eliminação de qualquer redundância parcial ou total entre esses arquivos.
Por compartilhado, queremos dizer que o banco de dados pode ser
compartilhado entre diferentes usuários, no sentido de que diferentes usuários
podem ter acesso aos mesmos dados, possivelmente ao mesmo tempo (acesso
concorrente).
Também devemos fazer uma diferenciação entre dado e informação. O dado é
aquilo que realmente é armazenado no banco de dados, enquanto a informação
refere-se ao significado desses dados para determinado usuário. Por exemplo,
se armazenamos no banco de dados a data de nascimento de um cliente como
sendo 10/01/1970, esse dado nos da a informação que em 20/12/1990 esse
cliente estava com 20 anos.
1.2.1.2
Hardware
Os componentes de hardware do sistema de banco de dados consistem em:

Volumes de armazenamento secundário – normalmente discos
magnéticos -, que são usados para manter os dados armazenados,
juntamente com os dispositivos de E/S (entrada/saída) associados
(unidades de disco etc), controladores de dispositivos, canais de E/S e
assim por diante.

Processador(es) de hardware e memória principal associada, que
são usados para dar suporte à execução do software do sistema de
banco de dados.
1.2.1.3
Software
Entre o banco de dados físico – ou seja, os dados fisicamente armazenados – e
os usuários do sistema existe uma camada de software conhecida como
gerenciador de banco de dados, ou mais freqüentemente conhecido SGBD –
Sistema Gerenciador de Banco de dados. O SGBD será responsável por
tratar todas as requisições citadas anteriormente como acrescentar novos
arquivos ao banco de dados ou inserir dados em arquivos existentes etc..
1.2.1.4
Usuários
Os usuários (finais) acessam o banco de dados interativamente através de
alguma aplicação ou interface on-line que na maioria das vezes podem ser
oferecidas pelo fornecedor do SGBD estas aplicações são internas (built-in), e
não escrita pelos usuários, a maior parte dos sistemas possui pelo menos uma
aplicação built-in, chamada de processador de linguagem de consulta, por meio
do qual o usuário pode emitir requisições ao banco de dados.
Consideremos de forma geral quatro classes de usuários que interagem com o
banco de dados:
Página 7
Administração e Projeto de Banco de Dados
1.2.1.4.1 Usuários finais:
Existem basicamente três categorias de usuários finais que são os usuários
finais do banco de dados, fazendo consultas, atualizações e gerando
documentos:
 Usuários casuais: acessam o banco de dados casualmente, mas que
podem necessitar de diferentes informações a cada acesso; utilizam
sofisticadas linguagens de consulta para especificar suas necessidades;
 Usuários novatos ou paramétricos: utilizam porções pré-definidas do
banco de dados, utilizando consultas pré-estabelecidas que foram
exaustivamente testadas;
 Usuários sofisticados ou de alto nível: são usuários que estão
familiarizados com o banco de dados e realizam consultas complexas
(query).
1.2.1.5
Administrador de Banco de Dados (DBA)
Em um ambiente de banco de dados, o recurso primário é o banco de dados por
si só e o recurso secundário o SGBD e os softwares relacionados. A
administração destes recursos cabe ao Administrador de Banco de Dados, o
qual é responsável pela autorização de acesso ao banco de dados e pela
coordenação e monitoração de seu uso.
São tarefas do DBA:







Definição da estrutura de armazenamento e a estratégia (ou método) de
acesso.
Concessão de autorização para acesso a dados.
Definição de controles de integridade.
Definição de estratégias para cópia de segurança e recuperação.
Monitoramento do desempenho.
Execução de rotinas de desempenho.
Modificação da organização física.
1.2.1.6
Projetista de Banco de Dados (Administrador de Dados)
O Projetista de Banco de Dados é responsável pela identificação dos dados que
devem ser armazenados no banco de dados, escolhendo a estrutura correta
para representar e armazenar dados. Muitas vezes, os projetistas de banco de
dados atuam como “staff” do DBA, assumindo outras responsabilidades após a
construção do banco de dados. É função do projetista também avaliar as
necessidades de cada grupo de usuários para definir as visões que serão
necessárias, integrando-as, fazendo com que o banco de dados seja capaz de
atender a todas as necessidades dos usuários.
São tarefas do AD: Definição e atualização do esquema do banco de dados.
1.2.1.7
Analistas de Sistemas e Programadores de Aplicações
Os analistas determinam os requisitos dos usuários finais e desenvolvem
especificações para transações que atendam estes requisitos, e os
programadores são os responsáveis pelo desenvolvimento de aplicações em
linguagens como Java, Cobol, C#, C++, VB.net e etc. que fazem chamadas ou
requisições ao SGBD através de instruções SQL
Página 8
Administração e Projeto de Banco de Dados
1.2.2
Por que um Sistema de Banco de Dados?
As vantagens de um sistema de banco de dados em relação aos métodos
tradicionais, baseados em papel são muitas, como por exemplo:

Densidade: Não há a necessidade de arquivos de papel, possivelmente
volumosos.

Velocidade: A máquina pode obter e atualizar dados com uma
velocidade muito maior do que o ser humano.

Atualidade: Informações precisas e atualizadas estão disponíveis a
qualquer momento sob consulta.

Proteção: Os dados podem ser bem protegidos contra a perda não
intencional e acesso ilegal.
1.2.3

Vantagens tecnológicas da utilização de um Sistema de Banco
de Dados
Controle de Redundância
A redundância consiste no armazenamento de uma mesma informação
em locais diferentes, provocando inconsistências. Em um Banco de
Dados as informações só se encontram armazenadas em um único local,
não existindo duplicação descontrolada dos dados.

Compartilhamento de Dados
Um banco de dados multiusuário deve permitir que múltiplos usuários
acessem o banco de dados ao mesmo tempo. Este fator é essencial para
que múltiplas aplicações integradas possam acessar o banco.
O banco de dados multiusuário deve manter o controle de concorrência
para assegurar que o resultado de atualizações seja correto. Um banco
de dados multiusuário deve fornecer recursos para a construção de
múltiplas visões.

Restrição a Acesso não Autorizado
O banco de dados deve dispor de recursos que possibilitem selecionar a
autoridade de cada usuário. Assim um usuário poderá realizar qualquer
tipo de acesso, outros poderão ler alguns dados e atualizar outros e
outros ainda poderão somente acessar um conjunto restrito de dados
para escrita e leitura.

Tolerância a Falhas
Um banco de dados deve fornecer recursos para recuperação de falhas
tanto de software quanto de hardware.

Integridade
Um banco de dados deverá impedir que aplicações ou acessos pelas
interfaces possam comprometer a integridade dos dados.
Página 9
Administração e Projeto de Banco de Dados

Suporte a transações
Uma transação é uma unidade lógica de trabalho (mais precisamente,
uma unidade lógica de trabalho de banco de dados), em geral
envolvendo diversas operações de banco de dados, onde uma operação
só pode ser validada pelo banco de dados se todas as demais operações
da transação também o forem.
Exemplo: Transação bancária de transferência de dinheiro. A transação
só pode ser validada se as operações de débito em uma conta origem e
crédito em uma conta destino forem validados.
1.2.4
Quando não Utilizar um SGBD
Em algumas situações, o uso de um SGBD pode representar uma carga
desnecessária aos custos quando comparado à abordagem processamento
tradicional de arquivos como, por exemplo:

Generalidade que um SGBD fornece na definição e processamento de
dados;

Sobrecarga na provisão de controle de segurança,
concorrência, recuperação e integração de funções.

Problemas adicionais podem surgir caso os projetistas de banco de dados
ou os administradores de banco de dados não elaborem os projetos
corretamente ou se as aplicações não são implementadas de forma
apropriada. Se o DBA não administrar o banco de dados de forma
apropriada, tanto a segurança quanto a integridade dos sistemas podem
ser comprometidas. A sobrecarga causada pelo uso de um SGBD e a má
administração justificam a utilização da abordagem processamento
tradicional de arquivos em casos como:

O banco de dados e as aplicações são simples, bem definidas e não se
espera mudanças no projeto;

A necessidade de processamento em tempo real de certas aplicações,
que são terrivelmente prejudicadas pela sobrecarga causada pelo uso de
um SGBD;

Não haverá múltiplo acesso ao banco de dados.
controle
de
Página 10
Administração e Projeto de Banco de Dados
1.2.5
Arquitetura de sistemas de banco de dados.
A arquitetura ANSI/SPARC (American National Standards Institute / Standards
Planning And Requirements Committee) ou “Tree-Schemas” é uma proposta do
Study Group on Data Base Management Systems para representar os sistemas
de banco de dados. A meta desta arquitetura é separar as aplicações de
usuários da base de dados física. Nessa arquitetura a base de dados pode ser
definida em três níveis: Nível Externo, Nível Conceitual e Nível Interno ou
Físico.
1.2.5.1
Os três níveis da arquitetura:

O nível externo ou visão (também conhecido como nível lógico de
usuário) é o mais próximo dos usuários, ou seja, é aquele que se ocupa
de como os dados são vistos por usuários individuais, como os dados
estão organizados para formar a informação para cada usuário. O nível
externo possui esquemas externos ou visões e não depende do sistema
gerenciador de banco de dados. Cada esquema descreve a visão da
informação de um grupo de usuários. Cada visão descreve, tipicamente,
à parte da base de dados que um particular grupo de usuários está
interessado e esconde o resto da base de dados do mesmo.

O nível conceitual (também conhecido como nível lógico de
comunidade, ou as vezes apenas como nível lógico, sem qualificação)
possuí um esquema conceitual que representa a estrutura da base de
dados que é o produto da normalização. È uma visão mais apropriada
para os projetistas onde todos os conjuntos de dados do nível externo
estão quebrados em pedaços lógicos, fundidos para reduzir repetição, e
estruturados para eliminar dependências. O esquema conceitual é uma
descrição global da base de dados, que omite detalhes da estrutura de
armazenamento físico e se concentra na descrição de entidades, tipos de
dados, relacionamento e restrições (Diagrama de Entidade e
Relacionamento).

O nível Interno ou Físico (também conhecido como nível de
armazenamento) é o mais próximo do meio de armazenamento físico, ou
seja, é aquele que se ocupa do modo como os dados, ou melhor,
registros e arquivos são fisicamente armazenados dentro da base de
dados e depende fortemente do SGBD selecionado. É uma visão mais
apropriada aos programadores de base de dados. Todos os conjuntos de
dados do nível físico estão organizados para aperfeiçoar a velocidade de
execução, maximizar a disponibilidade dos dados, e manter os dados
seguros.
Página 11
Administração e Projeto de Banco de Dados
Figura 2 Os três níveis da arquitetura.
Analisando a imagem podemos observar que o nível externo se preocupa
com as percepções dos usuários individuais, enquanto o nível conceitual está
preocupado com uma percepção da comunidade de usuários. Na maioria dos
casos alguns usuários não terão acesso a toda informação do banco de
dados, mas somente acessarão algumas partes das informações contidas no
mesmo; assim, haverá muitas “visões externas” distintas, cada qual
consistindo em uma representação abstrata de alguma parte da informação
contida no banco de dados, e haverá uma “visão conceitual”, consistindo em
uma representação igualmente abstrata do banco de dados em sua
totalidade. Do mesmo modo haverá uma “visão interna”, representando o
modo como os dados estão armazenados internamente.
1.2.5.2
Independência de Dados
A “independência de dados” pode ser definida como a capacidade de se alterar
um esquema em um nível em um banco de dados sem ter que alterar um nível
superior (figura anterior). Existem dois tipos de independência de dados:

Independência de dados lógica: é a capacidade de alterar o esquema
conceitual sem ter que alterar o esquema externo ou as aplicações do
usuário, ou seja, podemos alterar o esquema conceitual sem a
necessidade de reescrever os programas aplicativos. Algumas vezes é
necessário alterar a estrutura lógica do banco de dados como por
exemplo adicionando alguma nova entidade (tabela) ao banco.

Independência de dados física: é a capacidade de alterar o esquema
interno sem ter que alterar o esquema conceitual, o esquema externo ou
as aplicações do usuário, ou seja, podemos alterar o esquema físico sem
Página 12
Administração e Projeto de Banco de Dados
a necessidade de reescrever os programas aplicativos. Algumas vezes
são necessárias modificações no nível físico para melhorar o
desempenho.
Sistema
(SGBD)
1.3
de
Gerenciamento
de
Bancos
de
Dados
Um sistema gerenciador de banco de dados (SGBD) é responsável por
armazenar dados de forma confiável e permitir fácil recuperação e atualização
desses dados. Um SGBD relacional (SGBDR ou RDBMS relational database
management system) armazena dados de forma relacional, isto é na forma de
linhas e colunas.
A seqüência abaixo ilustra o papel do sistema de gerência de banco de dados,
de forma conceitual:
1. O usuário emite uma solicitação de acesso.
2. O SGBD intercepta a solicitação e a analisa.
3. O SGBD inspeciona os esquemas externos (ou sub-esquemas)
relacionados àquele usuário, os mapeamentos entre os três níveis, e a
definição da estrutura de armazenamento.
4. O SGBD realiza as operações solicitadas no banco de dados armazenado.
Exemplos de SGBD: Oracle, Microsoft SQL Server. IBM DB2, SyBase, Paradox,
Progress, MySql, Microsoft Access etc.
1.3.1








1.3.2
Funções do SGBD
Interação com o sistema de arquivos do sistema operacional.
Cumprimento da integridade.
Cumprimento da segurança.
Cópias de segurança (“backup”) e recuperação.
Controle de concorrência.
Otimização e execução dos comandos DML.
Dicionário de Dados.
Desempenho.
Estrutura geral do SGBD
Um sistema de banco de dados é dividido em módulos que tratam de cada uma
das responsabilidades do sistema geral. Na maioria dos casos, o sistema
operacional do computador fornece apenas os serviços mais básicos e o sistema
de banco de dados precisa ser construído sobre essa base. Portanto, o projeto
do sistema de banco de dados precisa incluir considerações sobre a interface
entre o sistema de banco de dados e o sistema operacional.
Os componentes funcionais de um sistema de banco de dados incluem:


Gerenciador de arquivos, que gerencia a alocação do espaço na
armazenagem do disco e as estruturas de dados usadas para representar
a informação armazenada no disco.
Gerenciador do banco de dados, que fornece a interface entre os
dados de baixo nível armazenados no disco e os programas aplicativos e
de consulta submetidos ao sistema.
Página 13
Administração e Projeto de Banco de Dados



Processador de consultas, que traduz os comandos numa linguagem
de consulta para instruções de baixo nível que o gerenciador do banco de
dados pode interpretar. Além disso, o processador de consultas tenta
transformar uma requisição do usuário em uma forma compatível e mais
eficiente com respeito ao banco de dados, encontrando uma boa
estratégia para executar a consulta.
Pré-compilador da DML, que converte comandos da DML embutidos
em um aplicativo para chamadas de procedimento normal na linguagem
hospedeira. O pré-compilador precisa interagir com o processador de
consultas pra gerar o código apropriado.
Compilador da DDL, que converte comandos da DDL em um conjunto
de tabelas contendo metadados ou "dados sobre dados".
Adicionalmente, diversas estruturas de dados são requeridas como parte da
implementação do sistema físico, incluindo:



Arquivos de dados, que armazenam o banco de dados propriamente
dito.
Dicionário de dados, que armazena metadados sobre a estrutura do
banco de dados. O dicionário de dados é usado com freqüência. Assim,
deve-se dar grande ênfase no desenvolvimento de um bom projeto e
implementação eficiente do dicionário.
Índices, que fornecem acesso rápido aos itens de dados guardando
determinados valores.
Estrutura básica de um sistema gerenciador de Banco de dados
Figura 3 Estrutura básica de um SGBD
Página 14
Administração e Projeto de Banco de Dados
Visão expandida da arquitetura do sistema de banco de dados
Figura 4 Estrutura expandida de um SGBD
Página 15
Administração e Projeto de Banco de Dados
1.4
Linguagens para Manipulação de Dados
Quando tratamos de banco de dados, e desejamos criar uma estrutura lógica
para armazenamento e organização destes dados e realizar consultas,
alterações, restrições de acesso, definições de esquemas e etc, fazemos uso de
uma linguagem que nos auxilie e facilite realizar esta tarefa.
As Linguagens para Manipulação de Dados são divididas em três grupos de
comandos:

DDL (Data Definition Language - Linguagem de Definição de Dados)
Para a criação dos objetos do banco de dados (tabelas, índices,
relacionamentos, visões etc) utilizamos a linguagem DDL (Data
Definition Language - Linguagem de Definição de Dados). O SGBD possui
um compilador DDL que permite a execução das declarações para
identificar as descrições dos esquemas e para armazená-las no catálogo
do SGBD.

DML (Data Manipulation Language - Linguagem de Manipulação de
Dados)
Uma vez que o banco de dados esteja criado, usa-se uma linguagem
para fazer a manipulação dos dados (ler, inserir, alterar e excluir), a DML
(Data Manipulation Language - Linguagem de Manipulação de Dados).

DCL (Data Control Language)
Linguagem de Controle de Dados – Utilizada para tratar as permissões
do banco de dados como a concessão (GRANT) ou revogação (REVOKE)
de privilégios no banco de dados.
Página 16
Administração e Projeto de Banco de Dados
1.5
Modelos de Bancos de Dados
Existem diversos modelos de banco de dados, e cada modelo tem suas
características de manipulação e armazenamento dos dados, dentre estes
modelos vamos conhecer os quatro principais e mais comuns modelos
encontrados no mercado, são eles: o modelo hierárquico, em rede, relacional e
orientado a objetos.
Para explicarmos cada modelo, iremos utilizar as informações da tabela abaixo:
Nome
João
Ana
Município
SBC
SP
Estado
SP
SP
Pedro
Osasco
SP
1.5.1
Conta
A102
A101
A202
A305
Saldo
400,00
500,00
900,00
350,00
O Modelo Hierárquico
O modelo hierárquico foi o primeiro a ser reconhecido como um modelo de
dados. Seu desenvolvimento somente foi possível devido à consolidação dos
discos de armazenamento endereçáveis, pois esses discos possibilitaram a
exploração de sua estrutura de endereçamento físico para viabilizar a
representação hierárquica das informações. Nesse modelo de dados, os dados
são estruturados em hierarquias ou árvores. Os nós das hierarquias contêm
ocorrências de registros, onde cada registro é uma coleção de campos
(atributos), cada um contendo apenas uma informação. O registro da hierarquia
que precede a outros é o registro-pai, os outros são chamados de registrosfilhos. Um registro é, em muitos aspectos, similar a uma entidade do modelo
entidade x relacionamento que veremos mais a frente. Cada registro é uma
coleção de campos (atributos), cada qual contendo somente um valor. Uma
ligação é uma associação entre dois registros. O relacionamento entre um
registro-pai e vários registros-filhos possui cardinalidade 1:N. Os dados
organizados segundo este modelo podem ser acessados segundo uma
seqüência hierárquica com uma navegação do topo para as folhas e da
esquerda para a direita. Um registro pode estar associado a vários registros
diferentes, desde que seja replicado. A replicação possui duas grandes
desvantagens: pode causar inconsistência de dados quando houver atualização
e o desperdício de espaço é inevitável. O sistema comercial mais divulgado no
modelo hierárquico foi o Information Management System da IBM Corp(IMS).
Grande parte das restrições e consistências de dados estava contida dentro dos
programas escritos para as aplicações. Era necessário escrever programas na
ordem para acessar o banco de dados
A representação gráfica deste modelo se realiza mediante a criação de uma
árvore invertida, os diferentes níveis ficam unidos mediante relações.
Página 17
Administração e Projeto de Banco de Dados
Figura 5 Banco de Dados Modelo Hierárquico
Neste modelo só se podem representar relações 1:M (uma para muitos), por
isso apresenta vários inconvenientes como:





Não se admitem relações N:M (muitos para muitos)
Um segmento filho não pode ter mais de um pai.
Não se permitem mais de uma relação entre dois segmentos.
Para acessar a qualquer segmento é necessário começar pelo segmento
raiz
A árvore se deve percorrer na ordem designada.
Exemplos de banco de dados Hierárquico: IBM’s IMS (DL/1, IMS DB, IMS DC),
SYSTEM 2000
1.5.2
O modelo de Rede
O modelo em redes surgiu como uma extensão ao modelo hierárquico,
eliminando o conceito de hierarquia e permitindo que um mesmo registro
estivesse envolvido em várias associações. No modelo em rede, os registros são
organizados em grafos onde aparece um único tipo de associação (set) que
define uma relação 1:N entre 2 tipos de registros: proprietário e membro. Desta
maneira, dados dois relacionamentos 1:N entre os registros A e D e entre os
registros C e D é possível construir um relacionamento M:N entre A e D. O
gerenciador Data Base Task Group (DBTG) da CODASYL (Committee on Data
Systems and Languages) estabeleceu uma norma para este modelo de banco de
dados, com linguagem própria para definição e manipulação de dados. Os dados
tinham uma forma limitada de independência física. A única garantia era que o
sistema deveria recuperar os dados para as aplicações como se eles estivessem
armazenados na maneira indicada nos esquemas. Os geradores de relatórios da
CODASYL também definiram sintaxes para dois aspectos chaves dos sistemas
gerenciadores de dados: concorrência e segurança. O mecanismo de segurança
fornecia uma facilidade na qual parte do banco de dados (ou área) pudesse ser
bloqueada para prevenir acessos simultâneos, quando necessário. A sintaxe da
segurança permitia que uma senha fosse associada a cada objeto descrito no
esquema. Ao contrário do Modelo Hierárquico, em que qualquer acesso aos
dados passa pela raiz, o modelo em rede possibilita acesso a qualquer nó da
rede sem passar pela raiz. No Modelo em Rede o sistema comercial mais
divulgado é o CAIDMS da Computer Associates. Nesta estrutura qualquer
componente pode se relacionar com qualquer outro. Diferentemente do modelo
hierárquico, neste modelo, um filho pode ter vários pais.
Página 18
Administração e Projeto de Banco de Dados
Figura 6 Banco de Dados Modelo de Rede
Os conceitos básicos no modelo em rede são:



O tipo de registro, que representa um nó.
Elemento, que é um campo de dados.
Agregado de dados, que define um conjunto de dados com nome.
Este modelo de dados permite representar relações N:M (muitos para muitos)
Exemplo de banco de dados de Rede: IDMS (Cullinet), DMS 1100 (Sperry),
TOTAL (Cincom Systems)
Página 19
Administração e Projeto de Banco de Dados
1.5.3
O Modelo Relacional
O Modelo Relacional de banco de dados é o modelo no qual iremos nos
aprofundar nesse curso, por ser um modelo de fácil entendimento e o mais
utilizado atualmente. Ele representa os dados por meio de conceitos
matemáticos da teoria dos conjuntos. Dirigido, este modelo foi proposto pelo
pesquisador Edgar Ted Frank Codd em jun/1970, este modelo melhora a visão
dos dados, a abordagem relacional faz com que o banco de dados seja
representado como um conjunto de tabelas bidimensionais, originadas em
linhas e colunas. A relação entre duas tabelas é feita através de colunas em
comum (chave primária e chave estrangeira). O modelo relacional não tem
caminhos pré-definidos para se fazer acesso aos dados como nos modelos que o
precederam. O modelo relacional implementa estruturas de dados organizadas
em relações. Porém, para trabalhar com essas tabelas, algumas restrições
precisaram ser impostas para evitar aspectos indesejáveis, como: Repetição de
informação, incapacidade de representar parte da informação e perda de
informação. Essas restrições são: integridade referencial, chaves e integridade
de junções de relações.
Figura 7 Banco de Dados Relacional
Algumas de suas principais características são:



Pode ser entendido e usado por qualquer usuário.
Permite ampliar o esquema conceitual sem modificar as aplicações de
gerenciamento.
Os usuários não necessitam saber onde se encontram os dados
fisicamente.
O elemento principal deste modelo é a relação que se representa mediante uma
tabela.
Exemplo de banco de dados Relacional: Oracle, DB2(IBM), MySql (MySql AB),
Firebird
(Open
Source),
PostgreSQL
(Open
Source),
SQL
Server
(Microsoft),Sybase Adaptative Server (Sybase)
Página 20
Administração e Projeto de Banco de Dados
1.5.4
O Modelo Orientado a Objetos
Os bancos de dados orientados a objeto começaram a se tornar comercialmente
viáveis em meados de 1980. A motivação para seu surgimento está em função
dos limites de armazenamento e representação semântica impostas no modelo
relacional. Alguns exemplos são os sistemas de informações geográficas (SIG),
os sistemas CAD e CAM, que são mais facilmente construídos usando tipos
complexos de dados. A habilidade para criar os tipos de dados necessários é
uma característica das linguagens de programação orientadas a objetos.
Contudo, estes sistemas necessitam guardar representações das estruturas de
dados que utilizam no armazenamento permanente. A estrutura padrão para os
bancos de dados orientados a objetos foi feita pelo Object Database
Management Group (ODMG), basicamente um sistema em que a unidade de
armazenamento é o objeto, com o mesmo conceito das linguagens de
programação orientadas a objetos. A diferença fundamental é a persistência dos
objetos, ou seja, os objetos continuam a existir mesmo após o encerramento do
programa. Através das construções orientadas a objeto, os programadores
podem esconder os detalhes da implementação de seus módulos, compartilhar
a referência a objetos e expandir seus sistemas através de módulos existentes.
Hoje, porém, acredita-se que os Bancos de Dados Orientados a Objetos serão
usados em aplicações especializadas, enquanto os sistemas relacionais
continuarão a sustentar os negócios tradicionais, onde as estruturas de dados
baseadas em relações são suficientes. O diagrama de classes UML serve
geralmente como o esquema para o modelo de dados orientado a objetos.
Figura 8 Banco de Dados Orientado a Objetos
Algumas de suas principais características são:



Os dados são armazenados como objetos
Os objetos são organizados numa hierarquia de tipos, e subtipos que
recebem as características de seus supertipos.
O acesso aos dados pode ser rápido porque as junções geralmente não
são necessárias.
Exemplo de banco de dados OO: CACHÉ, VERSANT,
GEMSTONE, JASMINE, MATISSE, Objectivity/DB, Ozone.
DB4Objects,
O2,
Página 21
Administração e Projeto de Banco de Dados
2. Modelagem de Dados
Para começarmos a tratar de modelagem de dados, vamos primeiramente
definir modelo.
Modelo: é a representação abstrata e simplificada de um sistema real, com a
qual se pode explicar ou testar o seu comportamento, em seu todo ou em
partes.
“Temos que modelar o mundo observado, seja ele real ou imaginário. Paulo
Cougo”
O processo de modelagem de um banco de dados é dividido em três etapas:



2.1
Modelo Conceitual
Modelo Lógico
Modelo Físico
Modelo Conceitual de Dados (MCD)
O Modelo Conceitual representa e/ou descreve a realidade do ambiente
observado, constituindo-se em uma visão global dos principais dados e
relacionamentos (estruturas de informação), independente das restrições de
implementação impostas por tecnologias, técnicas de implementação ou
dispositivos físicos, ou seja, na etapa de elaboração do modelo conceitual,
pouco importa se o sistema escolhido será um SGBD Relacional, de Rede ou
Hierárquico.
Quando se fala em Modelo Conceitual, estamos nos referindo a primeira etapa
do projeto de um sistema de aplicação em banco de dados, ele deve ser
utilizado para o nível de conversação, entendimento, transmissão, validação de
conceitos, mapeamento do ambiente etc...
O objetivo do Modelo Conceitual é descrever as informações contidas em uma
realidade, as quais irão estar armazenadas em um banco de dados. É uma
descrição em alto nível (macro-definição), mas que tem a preocupação de
captar e retratar toda a realidade de uma organização, setor, repartição,
departamento, negócio etc.
Como dizemos no inicio deste tópico, o Modelo Conceitual não retrata os
aspectos ligados à abordagem do banco de dados que será utilizado e tão pouco
se preocupa com as formas de acesso ou estruturas físicas implementadas por
um SGBD (Sistema Gerenciador de Banco de Dados) específico.
O resultado de um Modelo Conceitual é um esquema que representa a realidade
das informações existentes, assim como as estruturas de dados que
representam estas informações.
Página 22
Administração e Projeto de Banco de Dados
2.1.1
Modelo Lógico de Dados (MLD)
Defini-se como modelo lógico de dados aquele em que os objetos, suas
características e relacionamentos têm a representação de acordo com as regras
de implementação e limitantes impostos por algum tipo de tecnologia.
O Modelo Lógico tem o seu início a partir do Modelo Conceitual, levando em
consideração a abordagem de rede, hierárquica, relacional ou orientada a
objeto, esse modelo deve ser elaborado respeitando-se e implementando-se
conceitos tais como chaves de acesso, controles de chaves duplicadas,
normalização, ponteiros, headers, integridade referencial, entre outros. Estas
são preocupações e necessidades somente relevantes ao Modelo Lógico, jamais
devem ser levadas ao Modelo conceitual.
O Modelo Lógico descreve as estruturas que estarão contidas no banco de
dados, de acordo com as possibilidades permitidas pela abordagem, mas sem
considerar, ainda, nenhuma característica específica de um Sistema Gerenciador
de Banco de Dados (SGBD), resultando em um esquema lógico de dados sob a
ótica de uma das abordagens citadas.
2.1.2
Modelo Físico de Dados (MFD)
O Modelo Físico irá partir do Modelo Lógico e descreve as estruturas físicas de
armazenamento de dados, tais como: tamanho de campos, índices, tipo de
preenchimento destes campos, nomenclaturas, etc. Será projetado de acordo
com os requisitos de processamento e uso mais econômico dos recursos
computacionais. Este modelo detalha o estudo dos métodos de acesso ao SGBD,
para elaboração dos índices de cada informação colocada nos Modelos
Conceituais e Lógicos.
Cada empresa fornecedora do SGBD poderá definir um diferente modo de
implementação física das características e recursos necessários para o
armazenamento e manipulação das estruturas de dados
Esta é a etapa final do projeto de Banco de Dados, na qual será utilizada a
Linguagem de Definição de Dados do SGBD (DDL), para a criação física do
banco de dados proposto.
2.2
Modelo E-R
A abordagem Entidade-Relacionamento
Em março de 1976, Peter P. Chen publicou um trabalho intitulado “The EntityRelationship Model: Toward the unified view of data”, no qual definia uma
possível abordagem para o processo de modelagem dos dados. Esse trabalho,
após sua divulgação e ampla aceitação, passou a ser considerado como um
referencial definitivo para o processo de modelagem de dados. A abordagem
entidade-relacionamento é composta de uma técnica de diagramação e de um
conjunto de conceitos que devem ser entendidos e respeitados. O modelo
entidade-relacionamento é um modelo de dados conceitual de alto nível,
cujos conceitos foram projetados para estar o mais próximo possível da visão
que o usuário tem dos dados, não se preocupando em representar como estes
dados estarão realmente armazenados. O modelo ER é utilizado principalmente
durante o processo de projeto de banco de dados.
Página 23
Administração e Projeto de Banco de Dados
O modelo ER utiliza, basicamente, os retângulos para representar as
entidades, losangos para representar os relacionamentos, elipses (balões)
para indicar e alocar os atributos, linhas que unem os atributos aos conjuntos
de entidades e os conjuntos de entidades aos relacionamentos, elipses duplas
que representam os relacionamentos multivalorados e linhas duplas que
indicam participação total de uma entidade em um conjunto de
relacionamentos.
O diagrama ER fornece uma visão lógica do banco de dados, fornecendo um
conceito mais generalizado de como estão estruturados os dados de um
sistema.
Os objetos que compõem o diagrama ER estão listados a seguir, na figura
abaixo:
Página 24
Administração e Projeto de Banco de Dados
Os principais conceitos utilizados para a construção do modelo ER são:
Entidade
Atributo
Relacionamento
Cardinalidade




2.2.1
Entidade
Defini-se entidade como aquele objeto que existe no mundo real com uma
identificação distinta e um significado próprio, ou seja, é todo objeto concreto
ou abstrato que tem existência própria, quando considerado o âmbito de um
negócio. São coisas sobre as quais desejamos arquivar informações. São as
“coisas” que existem no negócio, ou ainda, descrevem o negócio em si.
A entidade é representada por um retângulo, conforme as figuras abaixo:
Cliente
Fornecedor
Pedido
Aluno
Em um universo observado, estaremos reconhecendo objetos (coisas). Estes
objetos estarão sendo percebidos como elementos individualizados, mas, ao
mesmo tempo, poderão ser enquadrados em um conjunto ou categoria em
função de suas semelhanças, estes objetos neste processo de observação serão
as entidades, vejamos um exemplo:
Exemplo
Ao observarmos um ambiente de produção de uma fábrica, nos defrontaremos
com:

Maquinas de produção de peças.

Funcionários operadores dessas máquinas.

Conjunto de ferramentas para operar e dar manutenção as máquinas.

Procedimentos de operações a serem realizadas.

Procedimentos de medições e verificação da qualidade das peças
produzidas.

Máquinas recuperadoras de peças.

Funcionários responsáveis pela verificação da qualidade das peças.

Peças produzidas nos mais diversos formatos.
Dentre esses elementos observados, poderemos perceber a existência de vários
conjuntos distintos de elementos (entidades), entre eles:

Máquina – que representa todas as máquinas observadas.

Funcionário – que representa todos os funcionários.

Ferramenta – que representa todas as ferramentas.

Peças – que representará todos os tipos de peças produzidas.
Página 25
Administração e Projeto de Banco de Dados
2.2.2
Atributo
É uma informação que caracteriza uma entidade ou um relacionamento. Toda
entidade possui atributos, mas nem todo relacionamento é caracterizado por
atributos. Os atributos podem ser classificados em: Descritivo, Identificador,
Composto, Derivado e Multivalorado.
2.2.3
Descritivo:
É utilizado para descrever a entidade.
Atributo
Descritivo
2.2.4
Identificador:
É utilizado para identificar unicamente uma linha da entidade.
Identificador
2.2.5
Atributo
Composto:
É um conjunto de tributos simples que pode ser referido como um único
atributo.
Atributo
Composto
Agregado
agregado
Agregado
2.2.6
Derivado:
Pode ter um valor que é derivável de valores de outros atributos.
Atributo
Derivado
2.2.7
Multivalorado:
Pode ser preenchido com muitos valores.
Multivalorado
NomeAtributo
atributo
Página 26
Administração e Projeto de Banco de Dados
Exemplo de uma entidade e seus diferentes tipos de atributos:
Aluno
Data Nasc.
RA
Rua
Idade
Endereço
Data Nasc.
Número
Bairro
Telefones
Cidade
2.2.8
Relacionamento
É a ligação entre duas ou mais entidades. Ao observarmos os objetos e
reconhecê-los, estaremos quase que imediatamente, reconhecendo as relações
existentes entre eles. Muitas vezes a própria observação de um relacionamento
será o ponto de partida para a identificação dos objetos que dele participam. O
que estabelecerá associações válidas ou não será simplesmente o grau de
fidelidade e completeza que consigamos atingir durante o processo de
modelagem.
O relacionamento é representado por um losango.
Exemplo:
Aluno
Freqüenta
Disciplina
Assim, se desejarmos ter, conceitualmente, representado um ambiente
observado onde “Anderson é proprietário de um jipe amarelo”, podemos segui a
seguinte estratégia:
1. Identificar os objetos envolvidos (entidades):

Pessoa (Anderson)

Carro (Jipe Amarelo)
2. Caracterizar os objetos (atributos):

Pessoa (nome, data nascimento, número CPF e etc.)

Carro (marca, cor, ano de fabricação, modelo etc.)
3. Representar os objetos:
Pessoa
Carro
4. Identificar o relacionamento entre os objetos:
Página 27
Administração e Projeto de Banco de Dados

Relacionamento: Pessoa é proprietária de Carro
5. Representar o relacionamento
Pessoa
2.2.9
É
Proprietária
Carro
Grau do Relacionamento ou Cardinalidade
Quando temos um relacionamento entre duas entidades, o número de
ocorrências de uma entidade que está associado a ocorrências de outra
entidade determina o Grau do Relacionamento ou Cardinalidade deste fato.
Quando questionamos se um homem poderia estar casado com mais de uma
mulher, estamos na realidade questionando o grau de relacionamento que
existe entre as entidades Homem e Mulher.
Em modelagem, ao se tratar de relacionamentos, podemos apresentar os
mesmos através de três possibilidades:

Um-para-Um (1:1)

Um-para-Muitos (1:N)

Muitos-para-Muitos (N:N) ou (M:N)
É o grau de ligação entre as entidades. É representada por “0”, “1” ou “N”,
significando “zero”, “um” ou “muitos” respectivamente.
Forma de leitura
Entidade – Relacionamento – Cardinalidade – Entidade. A leitura deve ser feita
em ambas as direções.
2.2.9.1
Relacionamento Um-para-Um (1:1)
Marido
1
1
Casado
Esposa
Pois um Marido só é casado com uma Esposa, e, também, uma esposa só
estará casada com um Marido.
mínimo
Cardinalidade Mínima e Máxima
máximo
Curso
1,1
Coordena
1,1
Coordenador
Página 28
Administração e Projeto de Banco de Dados
Um Curso é coordenado por no mínimo 1 e no máximo 1 coordenador.
Um coordenador coordena no mínimo 1 e no máximo 1 curso.
PD
Douglas
Têxtil
Pedro
Eletrônica
2.2.9.2
Ana
Relacionamento Um-para-Muitos (1:N)
1
Empresa
N
Filial
Possui
Pois uma empresa pode vir a ter 0 (nenhuma), 1 (uma), ou N (diversas)
filiais em sua estrutura operacional, mas desde que essa filial seja de uma
dada empresa não poderá ser de nenhuma outra.
Cardinalidade Mínima e Máxima
Vendedor
0,N
0,1
Atende
Região
Um vendedor atende zero ou uma região.
Uma região é atendida por zero ou muitos vendedores.
Mário
Carla
João
Campinas
Piracicaba
Sorocaba
Ana
Página 29
Administração e Projeto de Banco de Dados
2.2.9.3
Relacionamento Muitos-para-Muitos (N:N)
N
Livro
N
Escrito
Autor
Pois certo livro pode ser escrito pó um conjunto de autores (3, por
exemplo), e, por sua vez, cada um dos autores pode escrever mais de um
livro.
Cardinalidade Mínima e Máxima
0.N
Fornecedor
0.N
Fornece
Produto
Um fornecedor fornece zero ou muitos produtos.
Um produto é fornecido por zero ou muitos fornecedores.
W
A
X
B
Y
C
Z
D
E
Página 30
Administração e Projeto de Banco de Dados
2.3
Participação
Outra restrição muito importante é a participação. A participação define a
existência de uma entidade através do relacionamento, podendo ser parcial
ou total. Veja um exemplo.
EMPREGADO
Gerencia
DEPARTAMENTO
José
Maria
Fernanda
Moacir
Pedro
Paula
Luiz
Empregado
Compras
Projetos
RH
Gerencia
Departamento
A participação do empregado é parcial, pois nem todo empregado gerencia
um departamento, porém a participação do departamento neste
relacionamento é total, pois todo departamento precisa ser gerenciado por
um empregado. Desta forma, todas as entidades do tipo DEPARTAMENTO
precisam participar do relacionamento, mas nem todas as entidade do tipo
entidade EMPREGADO precisam participar do relacionamento.
Estas restrições são chamadas de restrições estruturais.
Página 31
Administração e Projeto de Banco de Dados
2.3.1
Considerações sobre Entidades Fortes e Entidades Fracas
Alguns
critério
fraca é
sentido
autores adotam, para fins de caracterização de uma entidade, um
que as classifica em fortes (regulares) ou fracas. Onde uma entidade
uma entidade cuja existência depende de alguma outra entidade, no
de que ela, não poder existir se essa outra entidade também não existir.
Esta caracterização se dá através da analise de existência de duas condições
básicas:

Dependência de existência.
Se uma entidade B depender de uma entidade A para existir, teremos
em B uma entidade fraca, enquanto que A, se não depender de ninguém
para existir, será considerada uma entidade forte.

Dependência de identificador.
Se uma entidade não possui atributos suficientes para formar uma chave
primária, este tipo de entidade é considerado uma entidade fraca. Do
ponto de vista de modelagem conceitual, assim como a dependência de
existência este tipo de critério pode ser visto como dispensável, pois sua
importância será reconhecida sob o ponto de vista de projeto lógico,
onde as chaves identificadoras, utilizadas como diferenciadores entre
instâncias dos elementos, ou como método de endereçamento de
registro, passam a ter papel vital durante a o processo de estrutura de
dados.
A relação entre um entidade forte e uma fraca deve ser 1:N.
Por exemplo, em um modelo de cadastro de funcionários, poderíamos ter a
entidade “Empregado” e para este empregado uma entidade “Dependente”, os
dependentes de um empregado, poderiam ser classificados como entidades
fracas, pois os dependentes não poderiam existir sem um empregado não fosse
cadastrado. Em particular se algum empregado for excluído, todos os seus
dependentes também devem ser excluídos.
Um conjunto de entidades fracas é identificado no modelo E-R pela linha dupla
usada no retângulo e no losango do relacionamento correspondente. No
diagrama abaixo, o conjunto de entidades fracas pagamento é dependente do
conjunto de entidades fortes Empréstimo pelo conjunto de relacionamento
pagamento_empréstimo. A figura também apresenta o uso de linhas duplas
para identificar participação total – a participação do conjunto de entidades
(fracas) pagamento no relacionamento pagamento_empréstimo é total,
significando que todo o pagamento precisa estar relacionado via
pagamento_empréstimo a alguma conta.
Página 32
Administração e Projeto de Banco de Dados
Total_pagto
Total
Data_Pagto
Pagamento_Em
Pagamento_empr
préstimo
éstimo
Empréstimo
Pagamento
Número_empréstimo
2.4
Número_pagamento
Relacionamentos Reflexivos (auto-relacionamento)
São os relacionamentos que ocorrem entre as ocorrências de uma mesma
entidade. Normalmente eles representam algum tipo de hierarquia.
Funcionário
0,N
Gerencia
1,1
Funcionário gerencia 0 ou muitos funcionários.
Funcionário é gerenciado por um único funcionário.
2.5
Extensões do Modelo Entidade x Relacionamento
O modelo de dados Entidade x Relacionamentos, como proposto por Peter
Chen, tem sido usado efetivamente para a comunicação do usuário final,
apresentando entidades e relacionamentos. Entretanto, quando usado para
integrar diferentes modelos conceituais com diferentes usuários finais, fica
severamente limitado até que se utilize um conceito de abstração de dados
denominado generalização.
2.5.1
Relacionamentos entre Múltiplas Entidades
Até o momento analisamos apenas situações em que as entidades se
relacionam sozinhas ou em pares, este é o principio da descoberta de
relacionamentos, a analise de relacionamento em pares, no entanto um
relacionamento pode envolver mais de duas entidades, que podem ser
três, quatro, cinco ou uma quantidade indeterminada.
Página 33
Administração e Projeto de Banco de Dados
Os relacionamentos entre múltiplas entidades expressam um fato em
que todas as entidades ocorrem simultaneamente, ou seja, todas as
ocorrências do relacionamento possuem, sempre, ligações com todas as
entidades envolvidas no relacionamento. Não é possível um
relacionamento triplo (Ternário), em um determinado momento,
transformar-se em duplo (Binário).
O diagrama abaixo representa uma situação de relacionamento que
envolve três entidades simultaneamente, a este tipo de relacionamento
triplo, damos o nome de Relacionamento Ternário.
Técnico
1
1
atua
Projeto
1
Notebook
Um técnico que atua em um projeto utiliza um notebook.
Um notebook é utilizado em um projeto por um técnico.
Um técnico com um notebook atua em um projeto.
2.5.1.1
Entidade associativa
Um relacionamento é uma associação entre entidades. Na modelagem
ER não foi prevista a possibilidade de associar dois relacionamentos
entre si. Na pratica, quando estamos construindo um novo modelo ER ou
modificando um modelo ER existente, surgem situações em que é
desejável permitir a associação de uma entidade a um relacionamento.
Vejamos um exemplo:
Médico
N
N
Consulta
Paciente
Suponha que seja necessário modificar este relacionamento da seguinte
forma. É necessário saber que medicamentos existem e que
medicamentos foram prescritos em cada consulta. Para saber que
medicamentos existem, cria-se uma nova entidade, Medicamento. A
questão agora é: com que entidade existente deve estar relacionada a
nova entidade? Se Medicamento fosse relacionado a Médico, ter-se-ia
apenas a informação de que médico prescreveu que medicamentos,
faltando a informação do paciente que os teve prescritos. Por outro lado,
Página 34
Administração e Projeto de Banco de Dados
se Medicamento fosse relacionado à Paciente, faltaria a informação do
Médico que prescreveu o medicamento. Assim, deseja-se relacionar a
prescrição do Medicamento à consulta, ou seja, deseja-se relacionar um
relacionamento prescrição com da entidade (Medicamento) a um
relacionamento (Consulta), o que não está previsto na abordagem ER.
Para tal, foi criado um conceito especial, o de entidade associativa. Uma
entidade associativa nada mais é que a redefinição de um
relacionamento, que passa a ser tratado como se fosse também uma
entidade. Graficamente isso é feito como mostrado na figura abaixo.
Médico
N
N
Consulta
Paciente
N
Prescrição
N
Medicamento
O retângulo desenhado ao redor do relacionamento Consulta indica que
este relacionamento passa a ser visto como uma entidade (associativa,
já que é baseada em um relacionamento). Sendo Consulta também uma
entidade, é possível associa-l através de relacionamentos a outras
entidades, conforme a figura apresentada acima.
2.5.1.2
Agregação
O termo agregação tem sido utilizado pelas técnicas de modelagem de
sistemas nos mais variados conceitos, porém o conceito lançado em
Modelagem de Dados refere-se à visão de um relacionamento como um
bloco, como alguma coisa que se relaciona com outra, Isso equivale
dizer que um relacionamento esta relacionado a outro. Mas,
conceitualmente, não existem relacionamentos entre relacionamentos; é
uma inverdade conceitual.
Para que exista o relacionamento de uma agregação com outra entidade
é necessária a existência de dependência entre os fatos, ou seja, um fato
somente acontece após a existência do primeiro fato.
Página 35
Administração e Projeto de Banco de Dados
No diagrama abaixo o Serviço só será utilizado quando um cliente se
hospedar em um quarto, o relacionamento utiliza depende do
relacionamento de hospeda-se.
Cliente
N
Hospeda-se
N
Quarto
N
Utiliza
N
Serviços
2.5.1.3
Generalização (Supertipos) e Especialização (Subtipos)
Quando estamos em busca da visualização dos dados de um negócio, é
importante atentar ao nível de abstração em que estamos atuando, pois
quando definimos uma entidade, estamos com a visão de uma classe
genérica de dados que pode estar incorporando, diversas outras classes
de dados.
2.5.1.3.1 Generalização
Ao buscarmos as entidades presentes em um dado negócio, pode ser
realizado de modo bottom-up (baixo para cima), no qual podemos
reconhecer vários conjuntos de entidades com atributos em comum,
então, estes atributos comuns são sintetizados em um conjunto de
entidades de alto nível.
Por exemplo, ao modelarmos um sistema hospitalar, podemos
encontrar entidades como Pediatra, Neurologista, Cardiologista,
Clínico Geral, entre outros, e ao analisarmos as características de
cada entidade, podemos perceber atributos em comum como nome,
sexo, data nascimento e tratando tais entidades de forma mais
genérica, podemos concluir que todas estas pessoas são médicos.
Dentro do contexto de modelagem botton-up, alguns autores
classificam a entidade generalizada “médico” como um supertipo.
Página 36
Administração e Projeto de Banco de Dados
Médico
Pediatra
Neurologista
Clínico Geral
Cardiologista
Então podemos ter como regra que ao encontrar um conjunto de
entidades que possuem o mesmo conjunto de atributos para
descrevê-las, podemos generalizá-las em uma única entidade,
mantendo sua identidade de subconjunto pela inserção de um
atributo qualificador para as ocorrências de cada uma.
2.5.1.3.2 Especialização
A especialização é justamente o inverso da generalização que é o
processo de analise botton-up (de baixo para cima) tratado, ao
tratarmos da especialização, nos ocorre o processo inverso de análise
o processo top-down (de cima para baixo) que é o caso da
especialização, ou seja, um conjunto de entidades pode conter
subgrupos (subtipos) de entidades que são de alguma forma,
diferentes de outras entidades do conjunto, continuando com o
exemplo do digrama anterior, ao analisarmos nossa entidade a partir
de médico, pode-se reconhecer subgrupos (subtipos) de médico,
como Pediatra, Neurologista, Cardiologista, Clínico Geral, entre
outros.
2.5.1.3.3 Generalização X Especialização
Na pratica, a generalização é o inverso da especialização. No
processo de modelagem novos níveis de representação serão,
diferenciadas (especialização) ou sintetizadas (generalização).
Generalização
Médico
Especialização
Pediatra, Neurologista,
Cardiologista, Clínico Geral
Página 37
Administração e Projeto de Banco de Dados
3. Bancos de Dados Relacionais
3.1
Definição
Foi criado por Edgar F. Codd na década de 70. 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.
A grande diferença existente quando se trabalha com bancos de dados
relacionais em relação aos ambientes tradicionais, pode ser
exemplificada da seguinte forma:
Em um ambiente tradicional, a função de acender um fósforo seria
descrita de forma exatamente procedural, passo a passo:
 Abrir a caixa de fósforos.
 Verificar se existem palitos.
 Levar o palito à lateral da caixa.
 Riscar o palito.
 Testar se acendeu ou não.
 Etc.
Em um ambiente de banco de dados relacional devemos mentalizar que
as instruções todas se resumem em uma única, uma operação realizada
em conjunto.
ACENDA UM FÓSFORO
Para definir e explicar claramente suponhamos que queremos retirar de uma sala
de aula todos os alunos que possuem média abaixo de 5 pontos.
Em um ambiente tradicional seria perguntado a cada aluno:

Sua média é abaixo de 5 ?
Se a resposta for sim, pediríamos que saísse. Se fosse não, ele ficaria.
Em um ambiente de banco de dados relacional, bastaria realizar uma operação
lógica:

Saiam todos que possuam média menor do que 5.
Página 38
Administração e Projeto de Banco de Dados
Tabela Relacional
3.2
Apresentamos abaixo uma relação de conceitos que definem uma tabela
relacional:







Cada tabela é chamada de relação.
Uma linha e suas colunas chamam-se tupla.
Cada coluna dessa tabela tem um nome e representa um atributo da
tabela.
A ordem das linhas é irrelevante.
Não há duas linhas iguais.
A ordem das colunas também é irrelevante.
Cada tabela tem nome próprio, distinto de qualquer outra tabela no
banco de dados.
Exemplo: Tabela de Funcionários:
Nome
João Carlos
Carlos Brito
Silvia Moraes
Cláudia Tereza
Pedro Júlio
Pedro Júlio
Sexo
M
M
F
F
M
M
Matrícula
373
872
963
161
292
574
Departamento
TI-Operações
TI-Programação
TI-Análise
TI-Gerência
RH
TI-Análise
Cargo
Operador
Programador I
Analista Sist. II
Secretária
Diretor
Analista Sist. I
Vamos analisar os dados:
As matrículas não indicam a ordem das linhas, apresentando o conceito de que
a ordem das linhas é irrelevante.
Todas as colunas possuem um nome que significam algo.
A ordem das colunas não está desenvolvida para nenhuma finalidade de
classificação ou ordem de leitura dos dados.
Nenhuma linha se repete.
Podemos ter duas pessoas com o mesmo nome, porém com matrículas
diferentes.
Página 39
Administração e Projeto de Banco de Dados
3.3
3.3.1
O conceito de Chave no Modelo Relacional
Chave Primária (Primary Key)
Em uma tabela existe uma coluna ou conjunto de colunas concatenados, cujo
valor é único na tabela, ou seja, nunca se repete aquele valor em nenhuma
outra linha da tabela, e que identifica uma e somente uma única linha da
tabela.
Então dizemos que esta coluna ou conjunto de colunas forma a chave primária
da tabela.
Na nossa tabela de funcionário, qual coluna ou conjunto de
concatenadas forma um identificador único para cada linha da tabela?
Nome
João Carlos
Carlos Brito
Silvia Moraes
Cláudia Tereza
Pedro Júlio
Pedro Júlio
Sexo
M
M
F
F
M
M
Matrícula
373
872
963
161
292
574
Departamento
TI-Operações
TI-Programação
TI-Análise
TI-Gerência
RH
TI-Análise
colunas
Cargo
Operador
Programador I
Analista Sist. II
Secretária
Diretor
Analista Sist. I
Nome? Com certeza não, pois se repete.
Sexo? Também se repete.
Departamento também não e cargo e salário sozinhos também não nos
dizem nada.
Sobra neste caso a única coluna que não tem valores repetidos, que é a
matrícula.
Existe somente um valor de matrícula para cada linha, o qual não se repete,
logo podemos determinar que a Matrícula é a chave primária da tabela de
Funcionários.
Vamos agora observar uma tabela mais complicada, em que tenhamos que
realizar um estudo maior para determinar a chave primária.
Página 40
Administração e Projeto de Banco de Dados
Tabela de Consumos
Bebida
Qtde
Cerveja
Chopp
Cerveja
Refrigerante
Mate
Café
Suco
Mate
Chopp
Água
Café
2
3
2
3
1
1
1
1
4
1
1
Valor
Unit.
3,00
2,00
3,00
2,00
1,50
0,80
3,00
1,50
2,00
1,00
0,80
Local
Consumo
Restaurante
Bar
Restaurante
Restaurante
Frigobar
Restaurante
Service Room
Restaurante
Bar
Frigobar
Restaurante
Quarto
101
203
101
203
407
203
505
407
203
101
203
Data
Hora
Valor
Consumo
Consumo
22/01/2001
14:30
19/01/2001
11:00
23/01/2001
14:30
20/01/2001
08:45
21/01/2001
16:30
18/01/2001
08:00
22/01/2001
21:30
21/01/2001
16:30
19/01/2001
17:10
18/01/2001
08:30
18/01/2001
18:00
Total
6,00
8,00
6,00
6,00
1,50
0,80
3,00
1,50
8,00
1,00
0,80
Qual coluna ou conjunto de colunas poderíamos definir como identificador
único de cada linha da tabela ?
Poderia ser bebida? Não. Quarto, também não. Notem que nenhuma coluna
sozinha poderia ser um identificador único da tabela.
E se utilizarmos bebida e quarto? Note que a bebida cerveja foi consumida
pelo quarto 101 mais de uma vez:
Bebida
Cerveja
Cerveja
Qtde
2
2
Valor
Unit.
3,00
3,00
Local
Consumo
Restaurante
Restaurante
Quarto
101
101
Data
Hora
Consumo
Consumo
22/01/2001
14:30
23/01/2001
14:30
Valor
Total
6,00
6,00
Se acrescentarmos o local de consumo à concatenação das colunas
referidas, ainda não teríamos um identificador único.
Bebida
Cerveja
Cerveja
Qtde
2
2
Valor
Unit.
3,00
3,00
Local
Consumo
Restaurante
Restaurante
Quarto
101
101
Data
Hora
Consumo
Consumo
22/01/2001
14:30
23/01/2001
14:30
Valor
Total
6,00
6,00
Como os consumos foram realizados em datas diferentes, podemos inserir a
data na composição da chave primária.
Bebida
Cerveja
Cerveja
Qtde
2
2
Valor
Unit.
3,00
3,00
Local
Consumo
Restaurante
Restaurante
Quarto
101
101
Data
Hora
Consumo
Consumo
22/01/2001
14:30
23/01/2001
14:30
Valor
Total
6,00
6,00
Desta vez os valores não se repetiriam. Porém, observe o consumo de mate
pelo quarto 407.
Página 41
Administração e Projeto de Banco de Dados
Bebida
Mate
Mate
Qtde
Valor
Unit.
1
1
1,50
1,50
Local
Consumo
Frigobar
Restaurante
Quarto
Data
Consumo
Hora
Consumo
Valor
Total
407
407
21/01/2001
21/01/2001
16:30
16:30
1,50
1,50
Eles foram consumidos na mesma data, mas como o local de consumo é
diferente, isso garante a integridade de nossa chave primária. Porém, o mesmo
não ocorre com as duas linhas a seguir:
Bebida
Café
Café
Qtde
1
1
Valor
Unit.
0,80
0,80
Local
Consumo
Restaurante
Restaurante
Quarto
203
203
Data
Hora
Consumo
Consumo
18/01/2001
08:00
18/01/2001
18:00
Valor
Total
0,80
0,80
Aconteceram dois consumos de café pelo mesmo quarto (hóspede), no mesmo
local e na mesma data. Isso nos diz que a chave primária definida até agora
não está correta, pois existem linhas duplicadas para ela.
Voltando a analisar as duas linhas acima, verificamos que o consumo foi
realizado em horas diferentes. Dessa forma, se acrescentarmos a coluna “hora
consumo” em nossa chave primária, passaríamos a ter duas linhas distintas.
Bebida
Café
Café
Qtde
1
1
Valor
Unit.
0,80
0,80
Local
Consumo
Restaurante
Restaurante
Quarto
203
203
Data
Hora
Consumo
Consumo
18/01/2001
08:00
18/01/2001
18:00
Valor
Total
0,80
0,80
Essa então é a nossa chave primária:





Bebida
Local de consumo
Quarto
Data consumo
Hora consumo
Dessa forma, não poderíamos ter a mesma bebida, consumida pelo mesmo
quarto (hospedagem), no mesmo local, na mesma data e na mesma hora, pois
se isso ocorrer, deveremos alterar a quantidade consumida ao invés de
inserirmos duas linhas na tabela.
3.3.2
Chave Estrangeira (Foreign Key)
Quando dizemos que duas tabelas estão relacionadas através de atributos
(colunas) comuns, devemos observar que esta coluna é a chave primária em
uma das tabelas. Na outra tabela, este atributo irá caracterizar o que
chamamos de chave estrangeira, propiciando assim, uma ligação lógica
(relacionamento) entre as tabelas.
Exemplo:
Página 42
Administração e Projeto de Banco de Dados
Departamento
Cód_Depto
1
2
3
4
5
Funcionário
Possui
Departamento
TI-Análise
TI-Programação
TI-Operações
RH
TI-Gerência
Nome
João Carlos
Carlos Brito
Silvia Moraes
Cláudia Tereza
Pedro Júlio
Pedro Júlio
Sexo Matrícula
M
373
M
872
F
963
F
161
M
292
M
574
Chave primária
3.3.3
Depto
3
2
1
5
4
1
Chave estrangeira
Chave Candidata
Uma tabela relacional pode assumir alternativas de identificador único, ou seja,
vária colunas ou concatenações delas podem ter essa propriedade. Estes
identificadores são candidatos à chave primária. Como somente um poderá ser
o escolhido (uma tabela só pode ter uma chave primária – que pode ser
composta pela concatenação de mais de uma coluna), o restante passa a ser
considerado como chave alternativa (secundária).
3.3.4
Chave Secundária (Secundary Key)
Serve para definir uma “segunda chave primária” através da criação de índices
únicos de pesquisa. As chaves secundárias mantêm a integridade das tabelas
que possuem mais de uma chave candidata.
3.4
3.4.1
Regras de Integridade do Modelo Relacional
Integridade de Identidade
A chave primária não pode conter um valor nulo (NULL). O NULL não é o valor
zero nem o caractere branco, é simplesmente a não existência de conteúdo
nesse campo.
3.4.2
Integridade Referencial
Se uma determinada tabela A possui uma chave estrangeira, a qual é chave
primária em outra tabela B, então ela deve ser:


Igual a um valor de chave primária existente em B.
Nula (null).
Não pode existir na chave estrangeira, um valor que não exista na tabela na
qual ela é chave primária.
Página 43
Administração e Projeto de Banco de Dados
As regras de integridade do modelo relacional representam a garantia de
que as tabelas guardam informações compatíveis. São de extrema
importância para a confiabilidade das informações contidas no banco de
dados.
Características do Modelo Relacional
3.5




Uma tabela é acessível por qualquer campo (atributo) independente se
este é declarado como chave ou não.
O relacionamento entre as tabelas não existe fisicamente, pois este
relacionamento é apenas lógico e representado através das chaves
estrangeiras.
Utilização de linguagens não procedurais (SQL).
Os ambientes relacionais possuem um otimizador estratégico para
escolher o melhor caminho para a recuperação dos dados.
4. Derivação do Modelo Entidade x Relacionamento para o
Modelo Lógico Relacional
Nesta etapa o desenvolvedor irá passar a visão do modelo conceitual para o
modelo lógico relacional, seguindo algumas regras de conversão.
Regras de Conversão
4.1
Existem regras precisas que não dão margem a erros, sendo que uma vez
projetado o diagrama ER, as tabelas que representam o ER num nível mais
baixo podem ser obtidas de forma clara.
4.2
Mapeamento de Entidades
Toda entidade torna-se uma tabela carregando todos os atributos definidos para
ela.
4.3
Mapeando atributos
Cada atributo vira um campo da tabela criada. Os atributos identificadores
viram a chave primária da tabela.
4.4
Relacionamento 1:N (envolvendo entidades distintas)
A entidade (tabela) cuja cardinalidade é N recebe o atributo identificador da
entidade cuja cardinalidade é 1 (chave estrangeira).
Exemplo:
Departamento
Departamento
1,1
Possui
0,N
Funcionário
Página 44
Administração e Projeto de Banco de Dados
Cód_Depto
1
2
3
4
5
Departamento
TI-Análise
TI-Programação
TI-Operações
RH
TI-Gerência
Funcionário
Nome
João Carlos
Carlos Brito
Silvia Moraes
Cláudia Tereza
Pedro Júlio
Pedro Júlio
Chave primária
4.5
Sexo Matrícula
Depto
M
373
3
M
872
2
F
963
1
F
161
5
Chave
estrangeira
M
292
4
M
574
1
Relacionamento 1:N (envolvendo auto-relacionamento)
Incluir a chave primária da entidade na própria entidade como chave
estrangeira.
0,N
Funcionário
Gerencia
1,1
Funcionário
Matrícula
373
872
963
161
292
574
4.6
Nome
João Carlos
Carlos Brito
Silvia Moraes
Cláudia Tereza
Pedro Júlio
Pedro Júlio
Sexo
M
M
F
F
M
M
Depto
3
2
1
5
4
1
Matrícula_Chefe
161
161
161
056
010
161
Relacionamento 1:1
As entidades (tabelas) envolvidas neste relacionamento carregarão o
identificador da outra (uma ou outra ou ambas) conforme a conveniência do
projeto (de acordo com o acesso a essas tabelas).
Funcionário
1,1
Chefia
0,1
Departamento
Podemos colocar a chave matrícula na tabela de departamentos, representando
que um departamento possui um chefe.
Página 45
Administração e Projeto de Banco de Dados
Departamento
Cód_Depto Departamento
1
TI-Análise
2
TI-Programação
3
TI-Operações
4
RH
5
TI-Gerência
Chefe
574
872
373
292
161
Funcionário
Nome
João Carlos
Carlos Brito
Silvia Moraes
Cláudia Tereza
Pedro Júlio
Pedro Júlio
Sexo
M
M
F
F
M
M
Matrícula
373
872
963
161
292
574
Depto
3
2
1
5
4
1
Podemos também colocar a chave departamento na tabela de funcionários,
representando que um funcionário pode chefiar um departamento. Note que
podemos ter funcionário que não chefiam nenhum departamento.
Departamento
Cód_Depto Departamento
1
TI-Análise
2
TI-Programação
3
TI-Operações
4
RH
5
TI-Gerência
Empregado
Nome
Sexo
João Carlos
Carlos Brito
Silvia Moraes
Cláudia Tereza
Pedro Júlio
Pedro Júlio
Matrícula Chefia
Depto
M
M
F
F
M
M
373
872
963
161
292
574
Trabalha
Depto
3
3
2
1
5
4
1
5
1
Também poderíamos colocar a chave estrangeira em ambas as tabelas
(alternativa menos utilizada).
Departamento
Cód_Dept Departamento
o
1
TI-Análise
2
TIProgramação
3
TI-Operações
4
RH
5
TI-Gerência
Chefe
574
872
373
292
161
Funcionário
Nome
Sexo
João Carlos
Carlos Brito
Silvia Moraes
Cláudia
TerezaJúlio
Pedro
Pedro Júlio
M
M
F
F
M
M
Matrícula
373
872
963
161
292
574
Chefia
Depto
3
2
5
4
1
Trabalha
Depto
3
2
1
5
4
1
Página 46
Administração e Projeto de Banco de Dados
4.7
Relacionamento N:N
O relacionamento torna-se uma tabela carregando os atributos identificadores
das entidades relacionadas e os atributos do relacionamento (quando houver).
Funcionário
Funcionário
Nome
João Carlos
Carlos Brito
Silvia Moraes
Cláudia Tereza
Pedro Júlio
Pedro Júlio
Sexo
M
M
F
F
M
M
0,N
0,N
Alocado
Projeto
Cód_Projeto
1
2
3
Matrícula
373
872
963
161
292
574
Projeto
Data Warehouse RH
Folha de Pagamento
B.I. Marketing
Projeto_Funcionário
Matrícula
Cód_Pojeto
373
872
373
4.8
Projeto
Horas_Alocadas
1
3
2
100
300
200
Relacionamento Múltiplo
O relacionamento é mapeado em uma tabela, cuja chave primária é formada
pela concatenação de todas as chaves estrangeiras.
Funcionário
0,N
0,N
Alocado
Projeto
0,N
Conhecimento
Projeto
Cód_Projeto
1
2
3
Funcionário
Nome
João Carlos
Carlos Brito
Silvia Moraes
Cláudia Tereza
Pedro Júlio
Pedro Júlio
Conhecimento
Cód_Conhec
Conhecimento
1
Oracle Discovere
2
PL/SQL
3
SQL Server
Projeto
Data Warehouse RH
Folha de Pagamento
B.I. Marketing
Sexo
M
M
F
F
M
M
Matrícula
373
872
963
161
292
574
Funcionário-Projeto-Conhecimento
Matrícula
Cód_Pojeto Cód_conhec
373
872
574
574
4.9
1
3
2
2
1
2
3
2
Generalizações
Exemplo:
Página 47
Administração e Projeto de Banco de Dados
Dado um conjunto “funcionário”, existe uma variação para este, pois existem
funcionários que são engenheiros, outros são vendedores e assim por diante,
sendo que podem existir variações nos atributos de um funcionário de acordo
com o seu cargo.
O artifício que temos é a criação de subconjuntos para os casos nos quais as
informações variam.
Um elemento funcionário só pode ter um e somente um subconjunto. As
informações dos engenheiros serão completadas pelo subconjunto “engenheiro”,
as do vendedor pelo subconjunto “vendedor” e assim por diante.
Os subconjuntos tornam-se tabelas carregando o identificador do conjunto ao
qual pertencem.
Funcionário
Gerente
Engenheiro
- Matrícula
- Matrícula
- Ajuda de custo
- Hora Extra
- Especialidade
- Despesa Extra
Secretária
- Matrícula
- Língua Estrangeira
- Curso
- Placa Carro
Página 48
Administração e Projeto de Banco de Dados
Funcionário
Matrícula
4534
6547
7734
1198
3289
Nome
Soraia Mattos
Breno Medeiros
Gustavo Borges
Ana Ferreira
Telma Ribeiro
Função
Ger
Eng
Eng
Eng
Sec
Func_Gerente
Func_Secretaria
Aj
4534 Custo
120
Espec
Mat
Língua
Curso
Eletr.
4534
Inglês
Secret.
Mat
Func_Engenheiro
Mat
HR Ext
Desp Ext
Placa
4534
120
240
AHA8909
7734
ACA2356
3289
5
23
JOL1234
5. Normalização de Dados
5.1
Definição
O conceito de normalização foi introduzido por E. F. Codd em 1972.
Inicialmente Codd criou as três primeiras formas de normalização chamando-as
de: primeira forma normal (1NF), segunda forma normal (2NF) e terceira forma
normal (3NF). Uma definição mais forte da 3NF foi proposta depois por BoyceCodd, e é conhecida como forma normal de Boyce-Codd (FNBC).
Através do processo de normalização pode-se, gradativamente, substituir um
conjunto de entidades e relacionamentos por um outro, o qual se apresenta
"purificado" em relação às anomalias de atualização (inclusão, alteração e
exclusão) as quais podem causar certos problemas, tais como:






grupos repetitivos (atributos multivalorados) de dados;
variação temporal de certos atributos, dependências funcionais totais ou
parciais em relação a uma chave concatenada;
redundâncias de dados desnecessárias;
perdas acidentais de informação;
dificuldade na representação de fatos da realidade observada;
dependências transitivas entre atributos.
Página 49
Administração e Projeto de Banco de Dados
Normalização de relações é portanto uma técnica que permite depurar um
projeto de banco de dados, através da identificação de inconsistências
(informações em duplicidade, dependências funcionais mal resolvidas, etc).
À medida que um conjunto de relações passa para uma forma normal, vamos
construindo um banco de dados mais confiável.
O objetivo da normalização não é eliminar todas as inconsistências, e sim
controlá-las.
5.2
Primeira Forma Normal (1FN)
Uma relação está na primeira forma normal se os valores de seus atributos são
atômicos (simples, indivisíveis) e monovalorados. Em outras palavras, FN1 não
permite “relações dentro de relações” ou “relações como atributos de tuplas”.
Uma tabela está na primeira forma normal quando seus atributos não contêm
grupos de repetição.
Exemplo:
Estrutura original:
Arquivo de Vendas (Num Venda, Data emissão, Cod. do Cliente, Nome do
cliente, Endereço do cliente, CGC do cliente, Relação das mercadorias vendidas
(onde para cada mercadoria temos: Código da Mercadoria, Descrição da
Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta
mercadoria) e Total Geral da Nota).
Analisando a estrutura acima, observamos que existem várias mercadorias em
uma única Venda, sendo, portanto elementos repetitivos que deverão ser
retirados.
Estrutura na primeira forma normal (1FN):
Arquivo de Vendas (Num Venda, Data emissão, Código do Cliente, Nome
Cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota).
Arquivo de Itens da Venda (Num Venda, Código da Mercadoria, Descrição da
Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta
mercadoria)
Obs. Os campos sublinhados identificam as chaves das estruturas.
Como resultado desta etapa ocorre um desdobramento dos dados em duas
estruturas, a saber:
Primeira estrutura (Arquivo de Vendas): Dados que compõem a estrutura
original, excluindo os elementos repetitivos.
Segundo estrutura (Arquivo de Itens da Venda): Dados que compõem os
elementos repetitivos da estrutura original, tendo como chave o campo chave
da estrutura original (Num Venda) e o campo chave da estrutura de repetição
(Código da Mercadoria).
Página 50
Administração e Projeto de Banco de Dados
5.3
Segunda Forma Normal (2FN) - Dependências Funcionais
Para uma tabela estar na segunda forma normal, além de estar na primeira
forma ela não deve conter dependências funcionais de parte da chave primária.
Um jeito de verificar esta norma é refazer a leitura dos campos fazendo a
pergunta: Este campo depende de toda a chave? Se não depender de toda a
chave temos uma dependência funcional.
Exemplo:
Estrutura na primeira forma normal (1FN):
Arquivo de Vendas (Num Venda, Data emissão, Código do Cliente, Nome do
cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota).
Arquivo de da Itens Vendas (Num Venda, Código da Mercadoria, Descrição da
Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta
mercadoria)
Estrutura na segunda forma normal (2FN):
Arquivo de Vendas (Num Venda, Data emissão, Código do Cliente, Nome do
cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota).
Arquivo de Itens da Vendas (Num Venda, Código da Mercadoria, Quantidade
vendida e Total da venda desta mercadoria).
Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço
de venda).
Como resultado desta etapa, houve um desdobramento do arquivo de Itens da
Venda (o arquivo de Vendas, não foi alterado, por não possuir chave composta)
em duas estruturas a saber:
Primeira estrutura (Arquivo de Itens da Vendas): Contém os elementos
originais, sendo excluídos os dados que são dependentes apenas do campo
Código da Mercadoria.
Segundo estrutura (Arquivo de Mercadorias): Contém os elementos que são
identificados apenas pelo Código da Mercadoria, ou seja, independentemente da
Nota Fiscal, a descrição e o preço de venda serão constantes.
5.4
- Terceira Forma Normal (3FN) - Dependências Transitivas
Para uma tabela estar na terceira forma normal, além de estar na segunda
forma ela não deve conter dependências transitivas. Um jeito de verificar esta
norma é refazer a leitura dos campos fazendo a pergunta: Este campo depende
de outro que não seja a chave? Se ele depender temos uma dependência
transitiva..
Página 51
Administração e Projeto de Banco de Dados
Exemplo:
Estrutura na segunda forma normal (2FN):
Arquivo de Vendas (Num Venda, Data emissão, Código do Cliente, Nome do
cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota).
Arquivo de Itens da Venda (Num Venda, Código da Mercadoria, Quantidade
vendida e Total da venda desta mercadoria).
Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço
de venda).
Estrutura na terceira forma normal (3FN):
Arquivo de Vendas (Num Venda, Data emissão, Código do Cliente e Total Geral
da Nota).
Arquivo de Itens da Venda (Num Venda, Código da Mercadoria, Quantidade
vendida e Total da venda desta mercadoria).
Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço
de venda).
Arquivo de Clientes (Código do Cliente, Nome do cliente, Endereço do cliente e
CGC do cliente).
Como resultado desta etapa, houve um desdobramento do arquivo de Vendas,
por ser o único que possuía campos que não eram dependentes da chave
principal (Num Venda), uma vez que independente da Venda, o Nome, Endereço
e CGC do cliente são inalterados. Este procedimento permite evitar
inconsistência nos dados dos arquivos e economizar espaço por eliminar o
armazenamento freqüente e repetidas vezes destes dados. A cada venda feita
para o cliente, haverá o armazenamento destes dados e poderá ocorrer
divergência entre eles.
As estruturas alteradas foram pelos motivos, a saber:
Primeira estrutura (Arquivo de Vendas): Contém os elementos originais, sendo
excluídos os dados que são dependentes apenas do campo Código do Cliente
(informações referentes ao cliente).
Segundo estrutura (Arquivo de Clientes): Contém os elementos que são
identificados apenas pelo Código do Cliente, ou seja, independente da Venda, o
Nome, Endereço e CGC dos clientes serão constantes.
Após a normalização, as estruturas dos dados estão projetadas para eliminar as
inconsistências e redundâncias dos dados, eliminando desta forma qualquer
problema de atualização e operacionalização do sistema. A versão final dos
dados poderá sofrer alguma alteração, para atender as necessidades específicas
do sistema, a critério do analista de desenvolvimento durante o projeto.
Página 52
Administração e Projeto de Banco de Dados
5.5
Quarta Forma Normal (4FN)
Na grande maioria dos casos, as entidades normalizadas até a 3FN são fáceis de
entender, atualizar e de se recuperar dados. Mas às vezes podem surgir
problemas com relação a algum atributo não chave, que recebe valores
múltiplos para um mesmo valor de chave. Esta nova dependência recebe o
nome de dependência multivalorada que existe somente se a entidade contiver
no mínimo três atributos.
Uma entidade que esteja na 3FN também estará na 4FN, se ela não contiver
mais do que um fato multivalorado a respeito da entidade descrita.
Exemplo: Dado a tabela a seguir.
Cód Funcionário
1234
1234
1234
1234
Habilidade
SQL Server
Oracle
Oracle
Access
Idioma
Inglês
Francês
Inglês
Alemão
Como podemos observar, esta entidade tenta conter dois fatos multivalorados:
as diversas habilidades de um funcionário e os diversos idiomas. Com isso
apresenta uma dependência multivalorada entre Código Funcionário e
Habilidade e entre Código Funcionário e Idioma. Embora esteja na 3FN, ao
conter mais de um fato multivalor, torna a sua atualização muito difícil.
Para passarmos a entidade acima para a 4FN, é necessária a realização de uma
divisão da entidade original, em duas outras entidades, ambas herdando a
chave Código Funcionário e concatenado, em cada nova entidade, com os
atributos Habilidade e Idioma.
Funcionário-Habilidade
Cód Funcionário
1234
1234
1234
Habilidade
SQL Server
Oracle
Access
Funcionário -Idioma
Cód Funcionário
1234
1234
1234
Idioma
Inglês
Francês
Alemão
Página 53
Administração e Projeto de Banco de Dados
5.6
Quinta Forma Normal (5FN)
Um registro não pode ser reconstruído a partir de vários tipos de registros
menores.
Exemplo:



Os vendedores representam as empresas.
As empresas fazem produtos.
Os vendedores vendem os produtos.
Caso mais geral (permite qualquer combinação):
Vendedor
Smith
Smith
Empresa
Ford
GM
Produto
Carro
Caminhão
O Smith não vende nem caminhões da Ford, nem carros da GM.
É em uma alteração que ocorre o problema:
Se um vendedor trabalha com um determinado produto, e ele representa uma
empresa, então ele vende esses produtos pela empresa.
Vendedor
Smith
Smith
Smith
Smith
Jones
Empresa
Ford
Ford
GM
GM
Ford
Produto
Carro
Caminhão
Carro
Caminhão
Carro
Podemos reconstruir todos os fatos verdadeiros em três tabelas em vez de
uma:
Vendedor
Smith
Smith
Jones
Empresa
Ford
GM
Ford
Vendedor
Smith
Smith
Jones
Produto
Carro
Caminhão
Carro
Empresa
Ford
Ford
GM
GM
Produto
Carro
Caminhão
Carro
Caminhão
Página 54
Administração e Projeto de Banco de Dados
Problemas com a forma da tabela 1:


Os fatos são registrados várias vezes. Por exemplo, o fato de que o
Smith vende carros é registrado duas vezes. Se Smith parar de vender
carros, 2 linhas devem ser atualizadas e faltará uma.
O tamanho desta tabela aumenta em progressão geométrica, enquanto
as tabelas normalizadas crescem em progressão aritmética.
Para
grandes operações, isso faz uma grande diferença: 100.000 x 100.000 é
bem maior do que 100.000 + 100.000.
É mais fácil escrever as regras comerciais a partir da quinta normal:


As regras são mais explícitas.
(Cadeias de suprimentos têm todos os tipos de problemas da 5FN).
Um exemplo de um conjunto sutil de condições:
Não-normal
Vendedor
Smith
Smith
Smith
Smith
Jones
Jones
Brown
Brown
Brown
Brown
Empresa
Ford
Ford
GM
GM
Ford
Ford
Ford
GM
Toyota
Toyota
Produto
Carro
Caminhão
Carro
Caminhão
Carro
Caminhão
Carro
Carro
Carro
Ônibus
Na 5FN:
Vendedor
Smith
Smith
Jones
Brown
Brown
Brown



Empresa
Ford
GM
Ford
Ford
GM
Toyota
Empresa
Ford
Ford
GM
GM
Toyota
Toyota
Produto
Carro
Caminhão
Carro
Caminhão
Carro
Ônibus
Vendedor
Smith
Smith
Jones
Jones
Brown
Brown
Produto
Carro
Caminhão
Carro
Caminhão
Carro
Ônibus
Jones vende carros e a GM fabrica carros, mas Jones não é
representante da GM.
Brown é representante da Ford e a Ford fabrica caminhões, mas Brown
não vende caminhões.
Brown é representante da Ford e Brown vende ônibus, mas a Ford não
fabrica ônibus.
Página 55
Administração e Projeto de Banco de Dados
Página 56
Administração e Projeto de Banco de Dados
Bibliografia
C. J. Date - Introdução a Sistemas de Banco de Dados, Elsevier 8º Edição
Paulo Cougo - Modelagem Conceitual e Projeto de Bancos de dados,
Elsevier17º Triagem
Felipe Machado e Maurício Abreu - Projeto de Banco de Dados Uma Visão
Prática, Érica
ABRAHAM SILBERSCHATZ, HENRY F., S. SUDARSHAN - Sistemas de Banco de
dados, Makron Books
Ramez Elmasri, Shamkant Navathe - Fundamentals of Database Systems; The
Benjamin CummingsPublishing Company; 1989;
KROENKE, DAVID M. - Banco de Dados: Fundamentos, projeto e
implementação. Sexta edição (tradução). LTC 1999
Carlos Alberto Heuser – Projeto de Banco de dados, Bookman.
Fernando Martins de Oliveira – Apostila Banco de Dados.
Shigueru Watanabe – Aulas e apresentações de Banco de Dados.
http://www.ime.usp.br/~andrers/aulas/bd2005-1/aula.html
http://www.criarweb.com/artigos/modelos-banco-dados.html
Página 57