Administração e Projeto de Banco de Dados

Prévia do material em texto

Administração e Projeto de Banco de Dados
Rudson Kiyoshi Souza Carvalho Página 1
Administração e 
Projeto de 
banco de dados 2010
Conceito de banco de dados. Modelagem conceitual de 
dados. Formas normais. Projeto lógico e físico, segundo o 
modelo relacional. Linguagem de definição e manipulação 
de dados. O padrão SQL. Concorrência de transações e 
mecanismos de manutenção de integridade, em sistemas 
de banco de dados. Views, Triggers, e Stored Procedures. 
Segurança e controle de acesso a informação. 
Sistemas de 
Informação e 
Processamento de 
dados
Administração e Projeto de Banco de Dados
Conteúdo
Conteúdo ................................................................................. 2 
Introdução e conceitos gerais ................................................. 5 
Banco de dados ........................................................................................ 5 
Sistema de Banco de Dados ...................................................................... 6 
Principais componentes de um Sistema de Banco de Dados ........................... 6 
Dados ..................................................................................................... 6 
Hardware ................................................................................................ 7 
Software ................................................................................................. 7 
Usuários .................................................................................................. 7 
Usuários finais: ....................................................................................... 8 
Administrador de Banco de Dados (DBA) ..................................................... 8 
Projetista de Banco de Dados (Administrador de Dados) ................................ 8 
Analistas de Sistemas e Programadores de Aplicações .................................. 8 
Por que um Sistema de Banco de Dados? .................................................... 9 
Vantagens tecnológicas da utilização de um Sistema de Banco de Dados ......... 9 
Quando não Utilizar um SGBD .................................................................. 10 
Arquitetura de sistemas de banco de dados. .............................................. 11 
Os três níveis da arquitetura: ................................................................... 11 
Independência de Dados ......................................................................... 12 
Sistema de Gerenciamento de Bancos de Dados (SGBD) ........................ 13 
Funções do SGBD ................................................................................... 13 
Estrutura geral do SGBD .......................................................................... 13 
Linguagens para Manipulação de Dados ................................................. 16 
Modelos de Bancos de Dados ................................................................... 17 
O Modelo Hierárquico .............................................................................. 17 
O modelo de Rede .................................................................................. 18 
O Modelo Relacional ................................................................................ 19 
O Modelo Orientado a Objetos .................................................................. 20 
Modelagem de Dados ............................................................. 21 
Modelo Conceitual de Dados (MCD) ........................................................... 21 
Modelo Lógico de Dados (MLD) ................................................................. 22 
Modelo Físico de Dados (MFD) .................................................................. 22 
Modelo E-R ............................................................................................. 22 
Entidade ................................................................................................ 24 
Atributo ................................................................................................. 25 
Descritivo: ............................................................................................. 25 
Identificador: ......................................................................................... 25 
Composto: ............................................................................................. 25 
Derivado: .............................................................................................. 25 
Multivalorado: ........................................................................................ 25 
Relacionamento ...................................................................................... 26 
Grau do Relacionamento ou Cardinalidade................................................. 27 
Rudson Kiyoshi Souza Carvalho Página 2
Administração e Projeto de Banco de Dados
Relacionamento Um-para-Um (1:1) .......................................................... 27 
Relacionamento Um-para-Muitos (1:N) ...................................................... 28 
Relacionamento Muitos-para-Muitos (N:N) ................................................. 29 
Participação ........................................................................................... 30 
Relacionamentos Reflexivos (auto-relacionamento) ..................................... 32 
Extensões do Modelo Entidade x Relacionamento .................................. 32 
Relacionamentos entre Múltiplas Entidades ................................................ 32 
Entidade associativa ................................................................................ 33 
Agregação ............................................................................................. 34 
Generalização (Supertipos) e Especialização (Subtipos) ............................... 35 
Generalização ........................................................................................ 35 
Especialização ........................................................................................ 36 
Generalização X Especialização ................................................................. 36 
Bancos de Dados Relacionais ................................................. 37 
Definição ................................................................................................ 37 
Tabela Relacional ................................................................................... 38 
O conceito de Chave no Modelo Relacional ............................................. 39 
Chave Primária (Primary Key) .................................................................. 39 
Chave Estrangeira (Foreign Key) .............................................................. 41 
Chave Candidata .................................................................................... 42 
Chave Secundária (Secundary Key) .......................................................... 42 
Regras de Integridade do Modelo Relacional .......................................... 42 
 Integridade de Identidade ....................................................................... 42 
Integridade Referencial ........................................................................... 42 
Características do Modelo Relacional ..................................................... 43 
Derivação do Modelo Entidade x Relacionamento para o 
Modelo Lógico Relacional ....................................................... 43 
Regras de Conversão .............................................................................. 43 
Mapeamento de Entidades ....................................................................... 43 
Mapeando atributos ................................................................................ 43 
Relacionamento 1:N (envolvendo entidades distintas) ................................. 43 
Relacionamento 1:N (envolvendo auto-relacionamento) .............................. 44 
Relacionamento 1:1 ................................................................................ 44 
Relacionamento N:N ............................................................................... 46 
Relacionamento Múltiplo .......................................................................... 46 
Generalizações ....................................................................................... 47 
 Normalização de Dados ........................................................ 49 
Definição ................................................................................................ 49 
Primeira Forma Normal (1FN) ................................................................... 50 
Segunda Forma Normal (2FN) - Dependências Funcionais ............................ 51 
- Terceira Forma Normal (3FN) - Dependências Transitivas .......................... 51 
Quarta Forma Normal (4FN) ..................................................................... 53 
Quinta Forma Normal (5FN) ..................................................................... 54 
Bibliografia ............................................................................................ 57 
Rudson Kiyoshi Souza Carvalho Página 3
Administração e Projeto de Banco de Dados
Rudson Kiyoshi Souza Carvalho Página 4
Administração e Projeto de Banco de Dados
Introdução e conceitos gerais
Antes de definir banco de dados, vamos definir alguns conceitos básicos ligados 
ao mesmo, como 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 trabalhadoque 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.
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;
• 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;
Rudson Kiyoshi Souza Carvalho Página 5
Administração e Projeto de Banco de Dados
• 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
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
Principais componentes de um Sistema de Banco de Dados
Um sistema de banco de dados envolve 4 componentes principais:
• Dados
• Hardware
• Software
• Usuários
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.
Os dados em um sistema de banco de dados são integrados e 
compartilhados
Rudson Kiyoshi Souza Carvalho Página 6
Administração e Projeto de Banco de Dados
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.
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.
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..
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:
Rudson Kiyoshi Souza Carvalho Página 7
Administração e Projeto de Banco de Dados
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).
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.
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.
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
Rudson Kiyoshi Souza Carvalho Página 8
Administração e Projeto de Banco de Dados
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.
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.
Rudson Kiyoshi Souza Carvalho 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.
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:
• Alto investimento inicial na compra de software e hardware 
adicionais;
• Generalidade que um SGBD fornece na definição e processamento de 
dados;
• Sobrecarga na provisão de controle de segurança, controle de 
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.
Rudson Kiyoshi Souza Carvalho Página 10
Administração e Projeto de Banco de Dados
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.
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.
Rudson Kiyoshi Souza Carvalho 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.
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 
Rudson Kiyoshi Souza Carvalho 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 de Gerenciamento de Bancos de Dados (SGBD)
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.
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.
Rudson Kiyoshi Souza Carvalho 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
Rudson Kiyoshi Souza Carvalho 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
Rudson Kiyoshi Souza Carvalho Página 15
Administração e Projeto de Banco de Dados
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.
Rudson Kiyoshi Souza Carvalho Página 16
Administração e Projeto de Banco de Dados
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 Município Estado Conta Saldo
João SBC SP A102 400,00
Ana SP SP A101 500,00
A202 900,00
Pedro Osasco SP A305 350,00
O Modelo Hierárquico
O modelo hierárquico é uma coleção de registros conectados uns aos outros por 
meio de links. 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. Um 
link é uma associação entre exatamente dois registros. Portanto, um link pode 
ser visto como uma forma restrita (binária) de relacionamento no sentido do 
modelo entidade x relacionamento. Este modelo utiliza árvores para a 
representação lógica dos dados. Esta árvore estacomposta de uns elementos 
chamados nós. O nível mais alto da árvore denomina-se raiz. Cada nó 
representa um registro com seus correspondentes campos.
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. 
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.
Rudson Kiyoshi Souza Carvalho Página 17
Administração e Projeto de Banco de Dados
Exemplos de banco de dados Hierárquico: IBM’s IMS (DL/1, IMS DB, IMS DC), 
SYSTEM 2000
O modelo de Rede
Um banco de dados de rede é uma coleção de registros conectados uns aos 
outros por meio de links. Um registro é, em muitos aspectos, similar a uma 
entidade do modelo entidade x relacionamento. Cada registro é uma coleção de 
campos (atributos), cada qual contendo somente um valor. Um link é uma 
associação entre exatamente dois registros. Portanto, um link pode ser visto 
como uma forma restrita (binária) de relacionamento no sentido do modelo 
entidade x relacionamento. Nesta estrutura qualquer componente pode se 
relacionar com qualquer outro. Diferentemente do modelo hierárquico, neste 
modelo, um filho pode ter vários pais. 
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) 
Rudson Kiyoshi Souza Carvalho Página 18
Administração e Projeto de Banco de Dados
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).
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)
Rudson Kiyoshi Souza Carvalho Página 19
Administração e Projeto de Banco de Dados
O Modelo Orientado a Objetos
É 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. A funcionalidade de 
banco de dados é necessária para assegurar o compartilhamento concomitante 
e a continuidade das informações nas aplicações. Através dos bancos de dados 
os programadores podem obter o estado em que os objetos se encontram, e 
estar atualizados entre várias solicitações do programa, e vários usuários 
podem ao mesmo tempo compartilhar a mesma informação. O banco de dados 
orientado a objeto combina os benefícios e conceitos da orientação a objetos 
com a funcionalidade dos bancos de dados.
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, DB4Objects, O2, 
GEMSTONE, JASMINE, MATISSE, Objectivity/DB, Ozone.
Rudson Kiyoshi Souza Carvalho Página 20
Administração e Projeto de Banco de Dados
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:
• 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.
Rudson Kiyoshi Souza Carvalho Página 21
Administração e Projeto de Banco de Dados
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 relevantesao 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.
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.
Modelo E-R
A abordagem Entidade-Relacionamento
Em março de 1976, Peter P. Chen publicou um trabalho intitulado “The Entity-
Relationship 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.
Rudson Kiyoshi Souza Carvalho Página 22
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:
Rudson Kiyoshi Souza Carvalho Página 23
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
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:
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.
Rudson Kiyoshi Souza Carvalho Página 24
Cliente Fornecedor Pedido Aluno
Administração e Projeto de Banco de Dados
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.
Descritivo:
É utilizado para descrever a entidade.
Identificador:
É utilizado para identificar unicamente uma linha da entidade.
Composto:
É um conjunto de tributos simples que pode ser referido como um único 
atributo.
Derivado:
Pode ter um valor que é derivável de valores de outros atributos.
Multivalorado:
Pode ser preenchido com muitos valores.
Rudson Kiyoshi Souza Carvalho Página 25
AtributoDescritivo
AtributoIdentificador
AtributoComposto
Agregad
o
agregad
o
Agregad
o
AtributoDerivado
Nome-
atributo
AtributoMultivalorado
Administração e Projeto de Banco de Dados
Exemplo de uma entidade e seus diferentes tipos de atributos:
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:
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:
4. Identificar o relacionamento entre os objetos:
Rudson Kiyoshi Souza Carvalho Página 26
Rua
Número
Bairro
Cidade
Endereço
Idade
AlunoData Nasc. RA
Data Nasc.Telefones
Aluno Disciplina
Freqüen
ta
Pessoa Carro
Administração e Projeto de Banco de Dados
 Relacionamento: Pessoa é proprietária de Carro
5. Representar o relacionamento
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.
Relacionamento Um-para-Um (1:1)
Pois um Marido só é casado com uma Esposa, e, também, uma esposa só 
estará casada com um Marido.
Cardinalidade Mínima e Máxima
Rudson Kiyoshi Souza Carvalho Página 27
1,11,1
Curso CoordenadorCoorden
a
mínimo
máximo
Pessoa Carro
É 
Proprietári
a
Marido Esposa
Casado
1 1
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.
Relacionamento Um-para-Muitos (1:N)
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
Um vendedor atende zero ou uma região.
Uma região é atendida por zero ou muitos vendedores.
Rudson Kiyoshi Souza Carvalho Página 28
0,10,N
Vendedor RegiãoAtend
e
PD
Têxtil
Eletrônica
Douglas
Pedro
Ana
Campinas
Piracicaba
Sorocaba
Mário
Carla
João
Ana
Empresa FilialPossui
1 N
Administração e Projeto de Banco de Dados
Relacionamento Muitos-para-Muitos (N:N)
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
Um fornecedor fornece zero ou muitos produtos.
Um produto é fornecido por zero ou muitos fornecedores.
Rudson Kiyoshi Souza Carvalho Página 29
W
X
Y
Z
A
B
C
D
E
0.N0.N
Fornecedor ProdutoForne
ce
Livro AutorEscrit
o
N N
Administração e Projeto de Banco de Dados
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. 
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. 
Rudson Kiyoshi Souza Carvalho Página 30
RH
Projetos
Compras
Luiz
Paula
Pedro
Moacir
Fernanda
Maria
José
Empregado Gerencia
Departamento
Empregado Departamento
Gerenc
ia
Administração e Projeto de Banco de Dados
1.1.1 Considerações sobre Entidades Fortes e Entidades Fracas
Alguns autores adotam, para fins de caracterização de uma entidade, um 
critério que as classifica em fortes (regulares) ou fracas. Onde uma entidade 
fraca é uma entidade cuja existência depende de alguma outra entidade, no 
sentido 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.
Rudson Kiyoshi Souza Carvalho Página 31
Administração e Projeto de Banco de Dados
 
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 gerencia 0 ou muitos funcionários. 
Funcionário é gerenciado por um único funcionário.
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.
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.
Rudson Kiyoshi Souza Carvalho Página 32
1,1
0,N
Funcionário
Gerenci
a
Empréstimo Pagamento
Pagamento_E
mpréstimo
Número_empréstimo
Total
Data_Pagt
o
Número_pagamento
Total_pagto
Pagamento_empr
éstimo
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.
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.
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:
Suponha que seja necessário modificar este relacionamento da seguinte 
forma. É necessário saber que medicamentos existem e que 
medicamentos foramprescritos 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, 
Rudson Kiyoshi Souza Carvalho Página 33
Técnico Projetoatu
a
11
1
Notebook
NN
Médico PacienteConsult
a
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.
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.
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.
Rudson Kiyoshi Souza Carvalho Página 34
NN
Médico PacienteConsult
a
Medicamento
Prescrição
N
N
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.
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.
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.
Rudson Kiyoshi Souza Carvalho Página 35
N
N
N N
Cliente Quarto
Hospeda-
se
Serviços
Utiliza
Administração e Projeto de Banco de Dados
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.
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.
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 Especialização
Médico Pediatra, Neurologista, 
Cardiologista, Clínico Geral 
Rudson Kiyoshi Souza Carvalho Página 36
Médico
Pediatra Neurologista Clínico Geral Cardiologista
Administração e Projeto de Banco de Dados
Bancos de Dados Relacionais
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.
Rudson Kiyoshi Souza Carvalho Página 37
Administração e Projeto de Banco de Dados
Tabela Relacional
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 Sexo Matrícula Departamento Cargo
João Carlos M 373 TI-Operações Operador
Carlos Brito M 872 TI-Programação Programador I
Silvia Moraes F 963 TI-Análise Analista Sist. II
Cláudia Tereza F 161 TI-Gerência Secretária
Pedro Júlio M 292 RH Diretor
Pedro Júlio M 574 TI-Análise 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 colunasnã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.
Rudson Kiyoshi Souza Carvalho Página 38
Administração e Projeto de Banco de Dados
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 colunas 
concatenadas forma um identificador único para cada linha da tabela?
Nome Sexo Matrícula Departamento Cargo
João Carlos M 373 TI-Operações Operador
Carlos Brito M 872 TI-Programação Programador I
Silvia Moraes F 963 TI-Análise Analista Sist. II
Cláudia Tereza F 161 TI-Gerência Secretária
Pedro Júlio M 292 RH Diretor
Pedro Júlio M 574 TI-Análise 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.
Rudson Kiyoshi Souza Carvalho Página 39
Administração e Projeto de Banco de Dados
Tabela de Consumos
Bebida Qtde Valor 
Unit.
Local 
Consumo
Quarto Data Hora Valor
Cerveja 2 3,00 Restaurante 101 22/01/2001 14:30 6,00
Chopp 3 2,00 Bar 203 19/01/2001 11:00 8,00
Cerveja 2 3,00 Restaurante 101 23/01/2001 14:30 6,00
Refrigerante 3 2,00 Restaurante 203 20/01/2001 08:45 6,00
Mate 1 1,50 Frigobar 407 21/01/2001 16:30 1,50
Café 1 0,80 Restaurante 203 18/01/2001 08:00 0,80
Suco 1 3,00 Service Room 505 22/01/2001 21:30 3,00
Mate 1 1,50 Restaurante 407 21/01/2001 16:30 1,50
Chopp 4 2,00 Bar 203 19/01/2001 17:10 8,00
Água 1 1,00 Frigobar 101 18/01/2001 08:30 1,00
Café 1 0,80 Restaurante 203 18/01/2001 18: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 Qtde Valor 
Unit.
Local 
Consumo
Quarto Data Hora Valor
Cerveja 2 3,00 Restaurante 101 22/01/200
1
14:30 6,00
Cerveja 2 3,00 Restaurante 101 23/01/200
1
14:30 6,00
Se acrescentarmos o local de consumo à concatenação das colunas 
referidas, ainda não teríamos um identificador único.
Bebida Qtde Valor 
Unit.
Local 
Consumo
Quarto Data Hora Valor
Cerveja 2 3,00 Restaurante 101 22/01/200
1
14:30 6,00
Cerveja 2 3,00 Restaurante 101 23/01/200
1
14:30 6,00
Como os consumos foram realizados em datas diferentes, podemos inserir a 
data na composição da chave primária.
Bebida Qtde Valor 
Unit.
Local 
Consumo
Quarto Data Hora Valor
Cerveja 2 3,00 Restaurante 101 22/01/200
1
14:30 6,00
Cerveja 2 3,00 Restaurante 101 23/01/200
1
14:30 6,00
Desta vez os valores não se repetiriam. Porém, observe o consumo de mate 
pelo quarto 407.
Rudson Kiyoshi Souza Carvalho Página 40
Administração e Projeto de Banco de Dados
Bebida Qtde Valor 
Unit.
Local 
Consumo
Quarto Data 
Consumo
Hora 
Consumo
Valor 
Total
Mate 1 1,50 Frigobar 407 21/01/200
1
16:30 1,50
Mate 1 1,50 Restaurante 407 21/01/200
1
16:30 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 Qtde Valor 
Unit.
Local 
Consumo
Quarto Data 
Consumo
Hora 
Consumo
Valor 
Total
Café 1 0,80 Restaurante 203 18/01/200
1
08:00 0,80
Café 1 0,80 Restaurante 203 18/01/200
1
18:00 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 Qtde Valor 
Unit.
Local 
Consumo
Quarto Data 
Consumo
Hora 
Consumo
Valor 
Total
Café 1 0,80 Restaurante 203 18/01/200
1
08:00 0,80
Café 1 0,80 Restaurante 203 18/01/200
1
18:00 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.
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:
Rudson Kiyoshi Souza Carvalho Página 41
Administração e Projeto de Banco de Dados
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).
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.
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.
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.
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.
Rudson Kiyoshi Souza Carvalho Página 42
Cód_Depto Departamento
1 TI-Análise
2 TI-Programação
3 TI-Operações
4 RH
5 TI-Gerência
Nome Sexo Matrícula Depto
João Carlos M 373 3
Carlos Brito M 872 2
Silvia Moraes F 963 1
Cláudia Tereza F 161 5
Pedro Júlio M 292 4
Pedro Júlio M 574 1
Departamento FuncionárioPossui
Chave primária Chave estrangeira
Administração e Projeto de Banco de Dados
Características do Modelo Relacional
• 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