apostila_modelagem de dados

Prévia do material em texto

CURSO TÉCNICO DE INFORMÁTICA 
 
 
 
 
MODELAGEM DE DADOS I 
 
 
 
 
Fevereiro de 2018 
 
Página 2 de 52 
 
CAPITULO I 
MODELOS DE BANCO DE DADOS 
 
 
 
Um modelo de (banco de) dados é uma descrição dos tipos de informações que estão armazenadas 
em um banco de dados. 
 
 
 
 
 
Para construir um modelo de dados usamos uma linguagem de modelagem de dados. Estas 
linguagens podem ser classificadas de acordo com a forma de apresentar modelos, em linguagens textuais ou 
linguagens gráficas. Existem linguagens de modelagem para descrever modelos de dados em diferentes níveis 
de abstração e com diferentes objetivos. Cada representação de um modelo de dados através de uma 
linguagem de modelagem de dados recebe a denominação de esquema de banco de dados. 
 
De acordo com a intenção do modelador, um banco de dados pode ser modelado (descrito) em vários 
níveis de abstração. Um modelo de dados que servirá para explicar a um usuário leigo em informática qual é a 
organização de um banco de dados provavelmente não conterá detalhes sobre a representação em meio físico, 
das informações. Já um modelo de dados usado por um técnico para otimizar a performance de acesso ao 
banco de dados conterá mais detalhes de como as informações estão organizadas internamente e, portanto, 
será menos abstrato. 
 
Assim como é possível, construir modelos de dados em vários níveis de abstração, também, é possível 
usar diferentes técnicas, aplicando diferentes conceitos aos construir modelos. Ao conjunto de conceitos 
usados na construção de um modelo denominamos de abordagem de modelagem. 
 
 
 
Modelo de Dados 
= 
Descrição formal da estrutura de um banco de dados 
 
 
Página 3 de 52 
 
1.1- MODELO CONCEITUAL 
 
Representa e descreve a realidade do ambiente do problema, constituindo-se em uma visão global dos 
principais dados e seus relacionamentos (estruturas de informação), completamente independente dos 
aspectos de sua implementação tecnológica. Quando falamos em modelo conceitual, estamos nos referindo 
aquela que deve ser a primeira etapa de um projeto de um banco de dados. 
O objetivo do modelo conceitual é descrever de forma simples e facilmente compreendida pelo 
usuário final as informações de um contexto de negócios, as quais devem ser armazenadas em um banco de 
dados. É uma descrição de alto nível, mas que tem a preocupação de captar e retratar a realidade de uma 
organização, processo de negócio, setor, repartição, departamento, etc. 
Devemos destacar que o modelo conceitual não retrata nem é vinculado aos aspectos ligados a 
abordagem de banco de dados que será utilizado e tampouco se preocupa com as formas de acesso ou 
estruturas físicas implementadas por SGBD específico. 
O resultado de um modelo conceitual é um esquema gráfico que representa a realidade das 
informações existentes em um determinado contexto de negócios, assim como as estruturas de dados em que 
estão organizadas essas informações. 
O modelo conceitual nunca deve ser construído com considerações sobre processos de negócios. O 
foco deve ser dirigido sempre ao entendimento e representação de uma realidade de um contexto. 
 
 
 
1.2- MODELO LÓGICO 
 
Ele somente tem o seu início após a criação do modelo conceitual. A partir deste ponto vamos 
considerar uma das abordagens possíveis da tecnologia de SGBDs (relacional, hierárquico, rede e orientado a 
objetos) para a estruturação e estabelecimento da lógica dos relacionamentos existentes entre os dados 
definidos no modelo conceitual. 
O modelo lógico descreve em formato as estruturas que estarão no banco de dados de acordo com as 
possibilidades permitidas pela sua abordagem, mas sem considerar, ainda, nenhuma característica específica 
de SGBD. Isso resulta em um esquema lógico de dados sob a óptica de uma das abordagens citadas, através do 
emprego de uma técnica de modelagem de dados orientada às restrições de cada abordagem. 
 
 
 
1.3- MODELO FÍSICO 
 
O modelo físico será construído a partir do modelo lógico e descreve as estruturas físicas de 
armazenamento de dados, tais como: 
 Tipo e tamanho de campos; 
 Índices; 
 Domínio de preenchimento desses campos; 
 Nomenclaturas; 
 Exigência de conteúdo; 
 Gatilhos; etc. 
 Estas são projetadas de acordo com os requisitos de processamento e uso mais econômico dos 
recursos computacionais. Esse modelo detalha o estudo dos métodos de acesso ao SGBD para a criação dos 
índices necessários para cada informação colocada nos modelos conceitual e lógico. 
 
 
 
 
Página 4 de 52 
 
1.4- PROJETO DE BANCO DE DADOS 
 
 O projeto de um novo banco de dados dá-se em três fases: 
 
 Modelagem Conceitual 
Nesta primeira fase, é construído um modelo conceitual, na forma de um diagrama entidade-
relacionamento. Este modelo é independe da implementação. 
 
 Projeto Lógico 
Objetiva transformar o modelo conceitual obtido na primeira fase em um modelo lógico. O modelo 
lógico define como o banco de dados será implementado em um SGBD específico. 
 
 Projeto Físico 
Nesta etapa, o modelo de BD é enriquecido com detalhes que influenciam no desempenho do BD, mas 
não interferem em sua funcionalidade. Alterações neste modelo não afetam as aplicações que usam o 
BD. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Página 5 de 52 
 
CAPITULO II 
MODELAGEM DE DADOS 
 
 
 
 
É o estudo das informações sob a observação para a construção de um modelo de representação e 
entendimento de tal contexto. A modelagem de dados busca minerar as informações que representam um 
contexto, estruturando-as em um conjunto que denominamos modelo lógico de dados. 
 
Uma das principais características da abordagem de banco de dados é que ele fornece níveis de 
abstração de dados, que omitem do usuário final detalhes sobre o armazenamento desses dados. Não existe a 
preocupação com um banco de dados tecnologicamente falando. 
 
Um modelo de dados é um conjunto de conceitos que podem ser utilizados para descrever as 
estruturas lógicas e físicas de um banco de dados. 
 
Historicamente, os primeiros modelos de banco de dados datam da década de 60. Desde então, a 
pesquisa cientifica na área procura evoluir no sentido de definir, encontrar modelos que representem da 
melhor maneira possível os dados da realidade, que organizem os dados de uma forma próxima da maneira 
como são vistos e manipulados pelas pessoas no mundo real. 
 
O objetivo de um modelo de dados é ter certeza de que todos os objetos de dados existem em 
determinado contexto e requeridos pelo banco de dados estão completamente representados com precisão. 
Pelo fato dos dados modelados usarem notações facilmente compreendidas e em um idioma natural, eles 
podem ser revisados e verificados pelos usuários finais. 
 
O modelo de dados também deve ser detalhado o bastante para ser usado pelo implementador (DBA) 
do banco de dados como uma espécie de fotocópia para construir o banco de dados físico. 
 
 
 
2.1- ABSTRAÇÃO 
 
Uma abstração ou a capacidade de abstração é um processo, com certeza mental, que usamos quando 
selecionamos várias características e propriedades de um conjunto de objetos ou fatos, e excluímos outras que 
não são relevantes em um contexto. Em outras palavras, nós aplicamos abstração quando nos concentramos 
nas propriedades de um conjunto de objetos ou coisas que consideramos essenciais, e desprezamos outras que 
não consideramos importantes, sempre dentro de um determinado contexto sob observação ou análise. 
 
Abstração, em síntese, nada mais é do que a visão, sem conceituações técnicas, que obtemos em 
nossa mente de uma realidade qualquer do mundo real. 
 
Quando modelamos devemos buscar a realidade do ambiente, o contexto em análise com total 
abstração em primeiro lugar, para somente depois iniciarmos um processo de modelagem lógica. 
 
Ao coletar e selecionar os objetos relevantes de um contexto, devemos identificar os elementos 
geradores de cada objeto, as leis que os regem nocontexto, bem como as operações que incidem sobre os 
objetos básicos (dados). 
 
 
 
 
 
 
Página 6 de 52 
 
2.2- MINIMUNDO (OU ESTUDO DE CASO) 
 
Porção da realidade a qual a gestão de negócios de uma organização tem interesse em observar, 
controlar e administrar. A complexidade existente no momento de analisar um minimundo pode levar o 
profissional a subdividi-lo em partes menores, às quais damos o nome de visão do processo de negócio. 
 
 
 
2.3- BANCO DE DADOS 
 
Um banco de dados pode ser definido como um conjunto de dados devidamente relacionados. 
Podemos compreender como dados os objetos conhecidos que podem ser armazenados e que possuem um 
significado implícito. Um banco de dados possui as seguintes propriedades: 
 
 É 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; 
 
 Ele é projetado, construído e populado com valores de dados para um propósito específico; um banco 
de dados possui um conjunto predefinido de usuários e aplicações; 
 
 Ele representa algum aspecto do mundo real, o qual é chamado de minimundo; qualquer alteração 
efetuada no minimundo é automaticamente refletida no banco de dados. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Página 7 de 52 
 
 
CAPITULO III 
ABORDAGEM ENTIDADE-RELACIONAMENTO 
 
 
 
 
A técnica de modelagem de dados mais difundida e utilizada é a abordagem entidade-relacionamento 
(ER). Nesta técnica, o modelo de dados é representado graficamente através de um diagrama de entidade-
relacionamento (DER). A abordagem ER foi criada por Peter Chen em 1976, podendo ser considerada como um 
padrão de fato para a modelagem conceitual. Mesmo as técnicas de modelagem orientada a objetos, que têm 
surgido nos últimos anos, como a UML, baseiam-se nos conceitos da abordagem ER. 
 
 
 
3.1- ENTIDADE 
 
O conceito fundamental da abordagem ER é o conceito de entidade. 
 
 
 
 
 
 
 
 
 
Como o objetivo de um modelo ER é modelar de forma abstrata um banco de dados, interessam-nos 
os objetos sobre os quais deseja-se manter informações. A entidade pode representar objetos concretos da 
realidade (uma pessoa, um automóvel, etc) quanto objetos abstratos (um departamento, um endereço, etc). 
 
Em um DER, uma entidade é representada através de um retângulo que contêm o nome da entidade. 
Alguns exemplos são mostrados abaixo: 
 
 
 
 
 
 
 
 
No exemplo acima, o primeiro retângulo designa o conjunto de todas as pessoas sobre as quais se 
deseja manter informações do banco de dados, enquanto o segundo retângulo designa o conjunto de todos os 
departamentos sobre os quais se deseja manter informações. Caso seja necessário referir um objeto particular 
(uma determinada pessoa ou um determinado departamento) fala-se em ocorrência de entidade. Mas 
recentemente, por influência da programação orientada a objetos, usa-se “instância”. 
 
Da forma como está apresentado, o modelo do exemplo acima indica apenas quais os conjuntos de 
objetos sobre os quais deseja-se manter informações, mas não quais as informações que devem ser mantidas 
para cada objeto. Estas informações são definidas pelas propriedades das entidades, dadas pelos 
relacionamentos, atributos e generalizações/especializações. 
 
 
 
ENTIDADE 
= 
Conjunto de objetos da realidade modelada sobre os quais deseja-se 
manter informações no banco de dados. 
Pessoa Departamento 
 
Página 8 de 52 
 
3.2- RELACIONAMENTO 
 
3.2.1- CONCEITUAÇÃO 
 
Uma das propriedades sobre as quais pode ser desejável informações é a associação entre objetos. 
Exemplificando, pode ser desejável saber quais pessoas estão associadas a quais departamentos em uma 
organização. A propriedade de entidade que específica as associações entre objetos é o relacionamento. 
 
 
 
 
 
Em um DER, um relacionamento é representado através de um losângulo, ligado por linhas aos 
retângulos representativos das entidades que participam do relacionamento. O exemplo abaixo, apresenta um 
DER contendo duas entidades, PESSOA e DEPARTAMENTO, e um relacionamento, LOTAÇÃO. 
 
 
Departamento PessoaLotação
 
 
 
Este modelo expressa que o banco de dados mantém informações sobre: 
 
 Um conjunto de objetos classificados como pessoas (entidade PESSOA); 
 Um conjunto de objetos classificados como departamento (entidade DEPARTAMENTO); e, 
 Um conjunto de associações, cada uma ligando um departamento a uma pessoa (relacionamento 
LOTAÇÃO). 
 
Da mesma forma que fizemos com entidades, quando quisermos nos referira associações específicas 
dentro de um conjunto, vamos nos referir a ocorrências ou instâncias de relacionamentos. No caso do 
relacionamento LOTAÇÃO, formado por uma ocorrência da entidade PESSOA e por uma determinada 
ocorrência da entidade DEPARTAMENTO. 
 
Não necessariamente um relacionamento associa entidades diferentes. O exemplo abaixo mostra um 
DER que contém, um auto-relacionamento, devido a isto, é necessário um conceito adicional, o de papel da 
entidade no relacionamento. 
 
 
 
 
 
Pessoa
Casamento
esposamarido
 
RELACIONAMENTO 
= 
Conjunto de associações entre ocorrências de entidades 
PAPEL DA ENTIDADE EM RELACIONAMENTO 
= 
Função que uma instância da entidade cumpre dentro de uma instância do relacionamento 
 
Página 9 de 52 
 
No caso do relacionamento de casamento, uma ocorrência de pessoa exerce o papel de marido e a 
outra ocorrência de pessoa exerce o papel de esposa. Papéis são anotados no DER como mostrado no exemplo 
anterior. No caso de relacionamentos entre entidades diferentes, no caso de LOTAÇÂO, não é necessário 
indicar papéis das entidades, já que eles são óbvios. 
 
 
 
3.2.2- CARDINALIDADE DE RELACIONAMENTOS 
 
Para fins de projeto de banco de dados, uma propriedade importante de um relacionamento é a 
quantas ocorrências de uma entidade podem estar associadas a uma determinada ocorrência de outra 
entidade através do relacionamento. Esta propriedade é chamada de cardinalidade de uma entidade em um 
relacionamento. Há duas cardinalidades a considerar: a cardinalidade máxima e a cardinalidade mínima. 
 
 
 
 
 
 
 
 
 
 
3.2.3- CARDINALIDADE MÁXIMA 
 
Para exemplificar o conceito de cardinalidade, vamos considerar as cardinalidades máximas do 
exemplo abaixo: 
 
Departamento PessoaLotação
1 120
 
 
 Entidade EMPREGADO tem cardinalidade, máxima 1 no relacionamento LOTAÇÂO. Isso significa que 
uma ocorrência de EMPREGADO pode estar associado a no máximo uma ocorrência de 
DEPARTAMENTO ou, em outros termos, que um empregado pode estar lotado em no máximo um 
departamento. 
 
 Entidade DEPARTAMENTO tem cardinalidade máxima 120 no relacionamento LOTAÇÂO. Isso significa 
que uma ocorrência de DEPARTAMENTO pode estar associado a no máximo 120 ocorrências de 
EMPREGADO ou, em outros termos, que um departamento pode ter nele lotado no máximo 120 
empregados. 
 
 
Para o projeto de banco de dados, especialmente de banco de dados relacionais, não é necessário 
distinguir entre diferentes cardinalidades máximas maiores que um. Por este motivo, apenas duas 
cardinalidades máximas são geralmente consideradas: 
 
 A cardinalidade máxima um (1) e; 
 A cardinalidade máxima ilimitada, usualmente chamada de cardinalidade máxima “muitos” e referida 
pela letra n. 
 
Assim no exemplo acima, diz-se que a cardinalidade máxima da entidade DEPARTAMENTO no 
relacionamento LOTAÇÃO é n. 
 
Cardinalidade (mínima,máxima) de entidade em relacionamento 
= 
Número (mínimo,máximo) de ocorrências de entidade associadas a 
uma ocorrência da entidade em questão através do relacionamento 
 
Página 10 de 52 
 
Em um DER, a cardinalidade máxima é representada conforme o exemplo anterior modificado. 
Observe a convenção usada. À primeira vista, ela pode parecer pouco natural, já que a cardinalidade vai 
anotada ”do outro lado” do relacionamento ao qual se refere. Exemplificando, a cardinalidade máxima da 
entidade EMPREGADO norelacionamento lotação é anotada junto ao símbolo da entidade DEPARTAMENTO. 
 
 
 
 
 
 
 
 
 
Departamento PessoaLotação
1 n
 
 
 
 
 
 
 
 
 
 
 
 
Classificação de Relacionamentos Binários 
 
A cardinalidade máxima pode ser usada para classificar relacionamentos binários. Um relacionamento 
binário é aquele cujas ocorrências contêm duas ocorrências de entidade como todos vistos até aqui. Podemos 
classificar os relacionamentos binários em n:n, 1:n e 1:1. 
 
A seguir apresentamos alguns exemplos de relacionamentos binários. 
 
Pessoa
Casamento
esposamarido
1 1
 
 
Empregado MesaAlocação
1 1
 
 
Expressa que a uma ocorrência de 
Departamento (entidade do lado oposto da 
anotação) podem estar associadas muitas 
(“n”) ocorrências de Pessoa 
Expressa que a uma ocorrência de 
Empregado (entidade do lado oposto da 
anotação) podem estar associada a no 
máximo uma (“1”) ocorrência de Pessoa 
 
Página 11 de 52 
 
Aluno CursoInscrição
n 1
 
 
Empregado DependenteInscrição
1 n
 
 
Empregado
Supervisiona
supervisionadosupervisor
1 n
 
 
Engenheiro ProjetoAlocação
n n
 
 
Médico PacienteConsulta
n n
 
 
Peça FornecedorCapacidade
n n
 
 
Produto
Composição
compostocomponente
n n
 
 
 
 
 
 
Página 12 de 52 
 
Classificação de Relacionamentos Ternários 
 
A abordagem ER permite que sejam definidos relacionamentos de grau maior que dois 
(relacionamentos ternários, quaternários, ...) o DER do exemplo abaixo mostra um relacionamento ternário. 
 
Cidade Distribuidor
Produto
Distribuição
n
n
1
 
 
 
Cada ocorrência do relacionamento DISTRIBUIÇÃO associa três ocorrências de entidade: um produto a 
ser distribuído, uma cidade na qual é feita a distribuição e um distribuidor. 
 
No caso de relacionamentos de grau maior que dois o conceito de cardinalidade de relacionamento é 
uma extensão não trivial do conceito de cardinalidade em relacionamentos binários. Devemos lembrar que, 
em um relacionamento binário R entre duas entidades A e B, a cardinalidade máxima de A em R indica quantas 
ocorrências de B podem estar associadas a cada ocorrência de A. No caso de um relacionamento ternário, a 
cardinalidade refere-se a pares de entidades A, B e C, dentro de R indica quantas ocorrências de C podem estar 
associadas a um par de ocorrências de A e B. 
 
No exemplo acima, o “1” na linha que liga o retângulo representativo da entidade DISTRIBUIDOR ao 
losângulo representativo do relacionamento expressa que cada par de ocorrências (cidade, produto) está 
associado a no máximo um distribuidor. Significa que é concedida exclusividade de distribuição de um produto 
para um distribuidor em uma cidade. 
 
Já os dois “n” expressam que: 
 A um par (cidade, distribuidor) podem estar associados muitos produtos ou, em outros termos, um 
distribuidor pode distribuir em uma cidade muitos produtos. 
 
 A um par (produto, distribuidor) podem estar associados muitas cidades ou em outros termos, um 
distribuidor pode distribuir um produto em muitas cidades. 
 
 
 
3.2.5- CARDINALIDADE MÍNIMA 
 
Além da cardinalidade máxima, outra informação que pode ser representada por um modelo ER é o 
número mínimo de ocorrências de entidades associadas a uma ocorrência de uma entidade através de um 
relacionamento. Para fins de projeto de banco de dados, consideram-se apenas duas cardinalidades mínimas: 
a cardinalidade mínima 0 e a cardinalidade mínima 1. 
 
 
Página 13 de 52 
 
A cardinalidade mínima 1 também recebe a denominação de “associação obrigatória”, já que ela 
indica que o relacionamento deve obrigatoriamente associar uma ocorrência da entidade em questão. Com 
base na mesma linha de raciocínio, a cardinalidade mínima, o recebe a denominação “associação opcional”. 
 
A cardinalidade mínima é anotada no diagrama junto a cardinalidade máxima, conforme o exemplo 
abaixo. Nesta figura, aparece novamente o exemplo da alocação de empregados a mesas. Aqui, a 
cardinalidade mínima é usada para especificar que cada empregado deve ter a ele alocada obrigatoriamente 
uma mesa (cardinalidade mínima 1) e que uma mesa pode existir sem que a ela esteja alocado um empregado 
(cardinalidade 0). 
 
Empregado MesaAlocação
(0,1) (1,1)
 
 
 
 
 
3.3- ATRIBUTO 
 
O modelo ER permite a especificação de propriedades de entidades. Uma propriedade é participar de 
um relacionamento. Outra propriedade é ter um atributo. O conceito de atributo serve para associar 
informações a ocorrências de entidades ou de relacionamentos. 
 
 
 
 
 
 
Atributos são representados graficamente conforme o exemplo abaixo. A figura expressa que cada 
ocorrência de PROJETO tem associado exatamente um nome, um código e um tipo. 
 
Projeto
nome
código
tipo
 
 
Na prática, muitas vezes os atributos não são representados graficamente, para não sobrecarregar os 
diagramas, já que entidades podem possuir um grande número de atributos. Prefere-se usar uma 
representação textual que aparece separadamente do diagrama ER. 
 
Um atributo pode possuir uma cardinalidade, de maneira análoga, a uma entidade em um 
relacionamento. A cardinalidade de um atributo define quantos valores deste atributo podem estar associados 
a uma ocorrência de entidade/relacionamento a qual ele pertence. A representação gráfica da cardinalidade 
de atributos é derivada da representação da cardinalidade de entidades em relacionamentos, conforme o 
exemplo a seguir: 
Cliente
nome
código
telefone(0,n)
 
ATRIBUTO 
= 
Dado que associado a cada ocorrência de uma entidade ou de um 
relacionamento 
 
Página 14 de 52 
 
No caso da cardinalidade ser (1,1), ela pode ser omitida do diagrama. Assim, o exemplo acima 
expressa que nome e código são atributos obrigatórios (cardinalidade mínima 1 – cada entidade possui no 
mínimo um valor associado) e monovalorados (cardinalidade máxima 1 – cada entidade possui no máximo um 
valor associado). Já o atributo telefone, é um atributo opcional (cardinalidade mínima 0) e multivalorado 
(cardinalidade máxima n). 
 
Assim, como entidades, também, relacionamentos podem possuir atributos. O exemplo abaixo, 
mostra um DER no qual um relacionamento, ATUAÇÃO, possui um atributo, a função que um engenheiro 
exerce dentro de um projeto. 
 
Engenheiro ProjetoAtuação
(0,n) (0,n)
função
nome
código
código
título
 
 
Esta função não pode ser considerada atributo de ENGENHEIRO, já que um engenheiro pode atuar em 
diversos projetos, exercendo diferentes funções. Também, não é atributo de PROJETO, já que, em um projeto, 
podem atuar diversos engenheiros com funções diferentes. 
 
Outro exemplo de atributo em relacionamento, agora em um relacionamento 1:n, é mostrado abaixo. 
Este diagrama modela vendas a prazo que são relacionadas a uma financeira, através do relacionamento 
FINANCIAMENTO. Os atributos número de parcelas e taxa de juros são atributos do relacionamento. Estes 
dois atributos poderiam ter sido incluídos na entidade VENDA. Neste caso, seriam atributos opcionais, já que 
nem toda venda é a prazo e possui estes atributos. Assim, preferiu-se usar o modelo do exemplo, exatamente 
para explicar o fato de os atributos número de parcelas e taxa de juros pertencerem somente a vendas a prazo. 
 
 
Financeira VendaFinanciamento
(0,1) (0,n)
taxa de juros
número_parcelas
 
 
 
 
3.3.1- IDENTIFICANDO ENTIDADES 
 
Cada entidade deve possuir um identificador. 
 
 
 
 
 
 
 
O caso mais simples é o da entidade que possui um único atributo como identificador. No DER, 
atributos identificadores são representados por um círculo preto. No exemplo abaixo, o atributo código é 
Identificador de entidade 
= 
Conjunto de um ou mais atributos e relacionamentos cujos valores servem para 
distinguir uma ocorrência da entidade das demais ocorrências da mesma entidade 
 
Página 15 de 52 
 
identificador. Isso significa que cada pessoa possui um código diferente. Já os atributos nome e endereço não 
são identificadores – o mesmo nome (ou o mesmo endereço)pode ser associado a pessoas diferentes. 
Pessoa código
endereço
 
 
 
O exemplo abaixo apresenta o identificador da entidade composto por dois atributos. Considera-se 
um almoxarifado de uma empresa de ferragens organizado da seguinte forma: os produtos ficam armazenados 
em prateleiras; estas encontram-se em armários organizados em corredores; estes são numerados 
sequencialmente a partir de um e as prateleiras são numeradas sequencialmente a partir de um, dentro de um 
corredor. Assim, para identificar uma prateleira é necessário conhecer seu número e o número do corredor 
em que se encontra. Para cada prateleira deseja-se saber sua capacidade em metros cúbicos. 
 
Pessoa
número do corredor
número da prateleira
capacidade
 
 
 
Finalmente, há casos em que o identificador de uma entidade é composto não somente por atributos 
da própria entidade, mas também por relacionamentos dos quais a entidade participa (relacionamento 
identificador). Um exemplo deste caso é mostrado abaixo. Este modelo envolve empregados de uma 
organização, relacionados com seus dependentes para fins de imposto de renda. Cada dependente está 
relacionado a exatamente um empregado. Um dependente é identificado pelo empregado ao qual ele está 
relacionado e por um número de sequência que distingue os diferentes dependentes de um mesmo 
empregado. No DER, o relacionamento usado como identificador é indicado por uma linha mais densa. 
 
Empregado Dependente
(1,1) (0,n)
 
 
 
Nesse caso, alguns autores dizem que a entidade DEPENDENTE é uma entidade fraca. O termo “fraca” 
deriva do fato de a entidade somente existir quando relacionada a outra entidade e de usar, como parte de seu 
indicador, entidades relacionadas. 
 
Outro exemplo de relacionamento identificador é apresentado no exemplo abaixo, que contém um 
fragmento de um DER sobre empresas. No exemplo, é representada a divisão de grupos de empresas em 
empresas e de empresas em filiais de empresas. Para identificar um grupo de empresas é usando um código. 
Já uma empresa é identificada pelo grupo ao qual está relacionada e por um número da empresa dentro do 
grupo. Finalmente, uma filial é identificada pela empresa a qual está vinculada e por um número de filial 
dentro da empresa. 
 
 
Página 16 de 52 
 
Grupo
Empresa Filial
(1,1)
(0,n)
(1,1) (0,n)
código
código-empresa 
 
 
O identificador de uma entidade, seja ele simples, composto por diversos atributos ou composto por 
identificadores externos, deve obedecer a duas propriedades: 
 
 O identificador dever mínimo. Isso significa que o identificador de uma entidade deve ser composto 
de tal forma que retirando um dos atributos ou relacionamentos que o compõe, ele deixa de ser 
identificador na entidade PESSOA, do exemplo abaixo, o par código e nome poderia ser usado para 
distinguir uma ocorrência de PESSOA das demais. Entretanto, estes atributos não formam um 
identificador mínimo, já que código é suficiente para distinguir as ocorrências de PESSOA. 
 
Pessoa
nome
código
endereço
 
 
 
 Para fins de projeto de bando de dados relacional, cada entidade deve possuir um único identificador. 
Em alguns casos, diferentes conjuntos de atributos podem servir para distinguir as ocorrências da 
entidade. Exemplificando, a entidade EMPREGADO no exemplo abaixo poderia possuir como 
identificador tanto o atributo código, quanto o atributo CPF. Cabe ao modelador decidir qual dos dois 
atributos será usado como identificador na entidade. 
 
Pessoa
nome
código
CPF
 
 
 
 
3.3.2- IDENTIFICANDO RELACIONAMENTOS 
 
Em princípio, uma ocorrência de relacionamento diferencia-se das demais ocorrências do mesmo 
relacionamento pelas ocorrências de entidades que dela participam. Exemplificando, uma ocorrência de 
ALOCAÇÃO (exemplo abaixo) é identificada pela ocorrência de ENGENHEIRO e pela ocorrência de PROJETO que 
ela relaciona. Em outros termos, para cada par (engenheiro, projeto) há no máximo um relacionamento de 
alocação. 
 
 
Página 17 de 52 
 
Engenheiro ProjetoAlocação
n n
 
 
 
Entretanto, há casos nos quais entre as mesmas ocorrências de entidade podem existir diversas 
ocorrências de relacionamentos. Um exemplo é o relacionamento CONSULTA entre as entidades MÉDICO e 
PACIENTE, abaixo. Para um determinado médico e um determinado paciente pode haver diversas consultas. 
Neste caso, é necessário algo que distinga uma consulta entre um médico e seu paciente das demais consultas 
entre este médico e este paciente. A diferenciação ocorre através de atributos identificadores de 
relacionamentos. No caso do relacionamento pode ser data/hora. 
 
Médico PacienteConsulta
n n
data/hora 
 
 
Assim, um relacionamento é identificado pelas entidades dele participantes, bem como pelos 
atributos identificadores eventualmente definidos. 
 
 
 
 
3.4- GENERALIZAÇÃO / ESPECIALIZAÇÃO 
 
Além de relacionamentos e atributos, propriedades podem ser atribuídas a entidades através do 
conceito de generalização/especialização. A partir deste conceito é possível atribuir propriedades particulares 
a um subconjunto das ocorrências (especializadas) de uma entidade genérica. No DER, o símbolo para 
representar generalização/especialização é um triângulo isósceles, conforme o exemplo abaixo. A 
generalização/especialização mostrada neste exemplo expressa que a entidade CLIENTE é dividida em dois 
subconjuntos, as entidades PESSOA FÍSICA e PESSOA JURÍDICA, cada uma com propriedades próprias. 
 
Filial Cliente
Pessoa Física Pessoa Jurídica
(1,1) (0,n)
CNPJ
Tipo_org
Nome
Código
CPF
Sexo
 
 
 
Associada ao conceito de generalização/especialização está a ideia de herança de propriedades. 
Herdar propriedades significa que cada ocorrência da entidade especializada possui além de suas próprias 
propriedades da ocorrência da entidade genérica correspondente. Assim, segundo o DER acima a entidade 
PESSOA FÍSICA possui, além dos seus atributos particulares, CPF e sexo, também todas as propriedades da 
ocorrência da entidade CLIENTE correspondente, ou seja, os atributos nome e código, o seu identificador, bem 
como o relacionamento com a entidade FILIAL. 
 
Página 18 de 52 
 
3.4.1- GENERALIZAÇÃO/ESPECIALIZAÇÃO TOTAL OU PARCIAL 
 
A generalização/especialização pode ser classificada em dois tipos, total ou parcial, de acordo com a 
obrigatoriedade ou não de a cada ocorrência da entidade genérica corresponder uma ocorrência da entidade 
especializada. 
 
Em uma generalização/especialização, total para cada ocorrência em uma das entidades 
especializadas. Esse é o caso do exemplo abaixo no qual a toda ocorrência da entidade CLIENTE corresponde 
uma ocorrência em uma das duas especializações. Esse tipo de generalização/especialização é simbolizado por 
um “t”. 
 
Filial Cliente
Pessoa Física Pessoa Jurídica
(1,1) (0,n)
CNPJ
Tipo_org
Nome
Código
CPF
Sexo
 
 
 
 
Em uma generalização/especialização parcial, nem toda ocorrência da entidade genérica possui uma 
ocorrência correspondente em uma entidade especializada. Esse é o caso do exemplo abaixo, no qual nem 
toda entidade FUNCIONÁRIO possui uma entidade correspondente em uma das especializações (nem todo o 
funcionário é motorista ou secretária). Este tipo de generalização/especialização é simbolizada por um “p” 
conforme o exemplo. Usualmente, quando há uma especialização parcial, na entidade genérica (no exemplo, 
FUNCIONÁRIO) aparece um atributo que identifica o tipo de ocorrência da entidade genérica (no exemplo, 
trata-se de tipo de funcionário). 
 
Funcionário
Motorista Secretária
Tipo_funcionário
p
 
 
 
 
3.4.2- GENERALIZAÇÃO/ESPECIALIZAÇÃO COMPARTILHADA OU EXCLUSIVA 
 
Além da classificação em total e parcial, uma generalização também pode ser classificada em 
compartilhada e exclusiva. 
Generalização/especialização exclusiva significa que, em uma hierarquia de 
generalização/especialização, uma ocorrência de entidade genérica é especializada no máximo uma vez, nasPágina 19 de 52 
 
folhas da árvore de generalização/especialização mostrados até aqui. Exemplificando, no exemplo anterior, 
uma instância (ocorrência) de FUNCIONÁRIO aparece uma vez somente nas entidades especializadas 
(MOTORISTA ou SECRETÁRIA), já que um funcionário ou é motorista ou é secretária, mas não ambas as funções 
ao mesmo tempo. Este tipo de generalização/especialização é chamada de “exclusiva” pela execução mútua 
da aparição de uma ocorrência de FUNCIONÁRIO nas entidades MOTORISTA ou SECRETÁRIA. 
 
Já a generalização/especialização compartilhada indica que, em uma hierarquia pode aparecer em 
várias entidades nas folhas da árvore de generalização/especialização. 
 
No exemplo abaixo, considera-se o conjunto de pessoas vinculadas a uma universidade. Neste caso, a 
especialização é compartilhada, já que a mesa pessoa pode aparecer em múltiplas especializações. Uma 
pessoa pode ser professor e aluno ou funcionário e aluno ao mesmo tempo. O fato de tratar-se de uma 
generalização/especialização compartilhada é indicado, no DER pela letra “c” junto ao triângulo representativo 
da generalização/especialização, sendo a generalização/especialização exclusiva indicada pela letra “x” junto ao 
triângulo. 
 
Funcionário
Pessoa
Professor Aluno
c
 
 
 
As combinações de tipos de entidades e as letras usadas para identificá-las no DER estão apresentadas 
na tabela abaixo. 
 
 
Tipos de Generalizações/Especializações 
 Total (t) Parcial (p) 
Exclusiva (x) xt xp 
Compatilhada (c) ct cp 
 
 
 
 
3.4.3- NÍVEIS DE GENERALIZAÇÃO/ESPECIALIZAÇÃO 
 
 
Uma entidade pode ser especializada em qualquer número de entidades, inclusive em uma única. 
Exemplificando, se no exemplo da generalização FUNCIONÁRIO, apenas os motoristas possuíssem 
propriedades particulares, haveria apenas uma entidade especializada, a de motorista. 
 
Além disso, não há um limite no número de níveis hierárquicos da generalização/especialização pode, 
por sua vez, ser entidade genérica em uma outra generalização/especialização. É admissível, inclusive, que 
uma mesma entidade seja uma especialização de diversas entidades genéricas (a chamada herança múltipla). 
O exemplo abaixo apresenta um DER em que aparecem múltiplos níveis de generalização/especialização, bem 
como o conceito de herança múltipla. 
 
Página 20 de 52 
 
VEÍCULO
VEÍCULO
TERRESTRE
VEÍCULO
AQUÁTICO
AUTOMÓVEL
VEÍCULO
ANFÍBIO
BARCO
 
 
 
 
3.5- ENTIDADE ASSOCIATIVA 
 
Um relacionamento é uma associação entre entidades. Na modelagem ER não foi prevista a 
possibilidade de associar uma entidade com um relacionamento ou então de associar dois relacionamentos 
entre si. Na prática, 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. 
A título de exemplo, consideremos o exemplo abaixo: 
 
 
Médico PacienteConsulta
n n
 
 Suponha que seja necessário modificar este modelo 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 NÉDICO, ter-se-ia 
apenas a informação de que o médico prescreveu que medicamentos, faltando a informação do paciente que 
os teve prescritos. Por outro lado, se MEDICAMENTO fosse relacionado à PACIENTE, faltaria a informação do 
médico que prescreveu o medicamento. Assim, deseja-se relacionar o medicamento à consulta, ou seja, 
deseja-se relacionar uma 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 no exemplo abaixo. O retângulo desenhado ao redor 
do relacionamento CONSULTA indica que este relacionamento passa a ser visto como uma entidade. Sendo 
CONSULTA também uma entidade, é possível associá-la através de relacionamentos a outras entidades. 
 
 
 
 
 
Página 21 de 52 
 
 
 
 
Médico PacienteConsulta
n n
Prescrição
Medicamento
n
n
 
 
Caso não se desejasse usar o conceito de entidade associativa, seria necessário transformar o 
relacionamento CONSULTA em uma entidade, que então poderia ser relacionada a MEDICAMENTO, conforme 
mostrado no exemplo abaixo. No modelo da figura, o relacionamento foi substituído por uma entidade 
homônima, junto com dois relacionamentos. Para manter a equivalência com o modelo anterior, uma consulta 
está relacionada com exatamente um médico e exatamente um paciente (a cardinalidade mínima e máxima é 
1). Uma consulta é identificada pelo paciente e pelo médico a ela ligados. Tendo substituído o relacionamento 
CONSULTA pela entidade, basta relacionar a entidade CONSULTA com a entidade MEDICAMENTO. 
 
Consulta
Médico Paciente
n n
Prescrição
Medicamento
n
n
Prescrição Prescrição
(1,1) (1,1)
 
 
Observando o exemplo podemos ver que o diagrama é equivalente ao diagrama da entidade 
associativa. Equivalente aqui significa que ambos geram o mesmo banco de dados. 
 
 
 
Página 22 de 52 
 
3.6- TRANSFORMAÇÃO ENTRE OS MODELOS ER E RELACIONAL 
 
Alternativas para Implementação de Relacionamentos 
 
Tipo de Relacionamento 
Regra de Implementação 
Tabela 
Própria 
Adição 
Coluna 
Fusão 
Tabelas 
Relacionamentos 1:1 
(0,1) (0,1)
 
 
± 
 
V 
 
X 
 
(0,1) (1,1)
 
 
# 
 
± 
 
V 
(1,1) (1,1)
 
 
# 
 
# 
 
V 
Relacionamentos 1:N 
(0,1) (0,n)
 
 
± 
 
V 
 
X 
 
(0,1) (1,n)
 
 
± 
 
V 
 
X 
(1,1) (0,n)
 
 
# 
 
V 
 
X 
(1,1) (1,n)
 
 
# 
 
V 
 
X 
Relacionamentos N:N 
(0,n) (0,n)
 
 
V 
 
X 
 
X 
(0,n) (1,n)
 
 
V 
 
X 
 
X 
(1,n) (1,n)
 
 
V 
 
X 
 
X 
 
Legenda: 
V: alternativa preferida 
±: pode ser usada, primeira opção 
#: poder ser usada, segunda opção 
X: não cabe como solução 
 
 
 
Página 23 de 52 
 
CAPITULO IV 
BANCO DE DADOS RELACIONAL 
 
 
Criado por Edgar F. Codd, nos anos 70, começou a ser realmente utilizado nas empresas a partir de 
1987. A abordagem relacional está baseada no princípio de que as informações em uma base de dados podem 
ser consideradas relações matemáticas e que estão representadas de maneira uniforme com o uso de tabelas 
bidimensionais. 
 
Este princípio coloca os dados direcionados a estruturas mais simples de armazenamento de dados, 
que são as tabelas, e nas quais a visão do usuário é privilegiada. 
 
 
 
4.1- TEORIA RELACIONAL 
 
A abordagem relacional representa uma forma de descrever um banco de dados através de conceitos 
matemáticos simples: a teoria dos conjuntos. 
 
Voltada, principalmente, a melhorar a visão dos dados pelos usuários, a abordagem relacional faz com 
que os usuários vejam o banco de dados como um conjunto de tabelas bidimensionais, originadas em linhas e 
colunas. 
 
 
 
 
 
 
 
 
O conceito principal vem da tória dos conjuntos atrelado à concepção de que não é relevante ao 
usuário saber onde os dados estão nem como os dados estão (transparência). 
 
Os usuários manipulam estes objetos dispostos em linhas e colunas das tabelas que possuem 
informações sobre o mesmo assunto de forma estruturada e organizada. 
 
Para lidar com estes objetos, o usuário conta com um conjunto de operadores e funções de alto nível, 
constantes na álgebra relacional. 
 
A Teoria Relacional possui premissas que definem uma tabela de dados: 
 
 Cada uma das tabelas é chamada de relação; 
 O conjunto de uma linha e suas colunas é chamado tupla; 
 Cada coluna dessa tabela tem um nome e representa um domínio da tabela; 
 Não há duas linhas iguais; 
 Usamos nomes para fazer referência às colunas; 
 Cada tabela tem um nome próprio, distinto de qualqueroutra tabela no banco de dados. 
 
 
 
 
 
 
São conjuntos de dados vistos segundo um conjunto de TABELAS, e as 
operações que as utilizam são feitas por linguagens que o manipulam, não 
sendo procedurais, ou seja, manipulando conjuntos de uma só vez. 
 
Página 24 de 52 
 
Exemplo 1 
 
Tabela de CDs 
 
Nº do CD Dt da Gravação Título do Conteúdo Responsável Local onde está guardado 
1 24/01/2001 Clipart Samir Estojo Verde 
3 13/02/2000 IRRF 2000 Felipe Caixa de Documentos 
2 14/12/2000 Backup Textos Felipe Estojo Azul 
4 25/01/2000 Fotos Gramado Samir Caixa de Álbum 3 
 
Podemos observar a tabela de CDs que os conceitos listados anteriormente em relação às tabelas 
relacionais estão destacados: 
 
 A ordem das linhas é irrelevante, pois o CD de número 2 vem após o CD de número 3. Se observarmos 
mais detalhadamente, veremos que o CD número 3 tem uma data inclusive menor que o CD de 
número 2; 
 Nenhuma linha se repete nesta tabela; 
 A ordem das colunas também não tem nenhum destaque, ou importância, pois não estão em 
nenhuma ordem lógica; 
 Todas as colunas têm um nome, que identifica o seu conteúdo, ou melhor, o significado do valor de 
seu conteúdo. 
 
 
 
Exemplo 2 
 
Tabela Funcionários 
 
Nome Sexo Matrícula Departamento Cargo Salário 
João Carlos M 373 TI Operações Operador 3.000,00 
Carlos Brito M 872 TI Programação Programador I 3.500,00 
Silvia Morais F 963 TI Análise Analista Sistemas II 5.500,00 
Claudia Tereza F 161 TI Gerência Secretaria 1.500,00 
Pedro Julio M 292 RH Diretor 6.000,00 
Pedro Julio M 574 TI Análise Analista Sistemas I 4.500,00 
 
 
Vamos analisar a tabela acima: 
 
 A coluna matrícula não indica nenhuma ordem para as linhas, confirmando o conceito de que a ordem 
das linhas é irrelevante; 
 Todas as colunas têm um nome que significa algo sobre o assunto, o que é bem evidente; 
 A disposição das colunas não tem nenhuma finalidade de classificação, tampouco indica ordem de 
leitura dos dados; 
 A modificação da ordem das colunas não acarreta prejuízo nenhum do assunto ou da 
representatividade da tabela; 
 
Salário Nome Sexo Matrícula Departamento Cargo 
3.000,00 João Carlos M 373 TI Operações Operador 
3.500,00 Carlos Brito M 872 TI Programação Programador I 
5.500,00 Silvia Morais F 963 TI Análise Analista Sistemas II 
1.500,00 Claudia Tereza F 161 TI Gerência Secretaria 
6.000,00 Pedro Julio M 292 RH Diretor 
4.500,00 Pedro Julio M 574 TI Análise Analista Sistemas I 
 
Página 25 de 52 
 
O importante é que toda vez que nos referimos à tabela funcionários visualizemos os dados que ela 
contém, e simbolizando valores possíveis, pois assim vamos mentalizando e nos abstraindo em algum objeto 
que a tabela representa. 
 
 
 
4.2- CARACTERÍSTICAS PRINCIPAIS DE UMA RELAÇÃO (TABELA) 
 
Vamos definir a concepção técnica de uma relação (tabela). 
 
NumReg NomeFunc DtAdmissão Sexo Fone CodDepto 
Dia Mês Ano 
101 Luis Sampaio 10 08 2003 M 2565-8974 D5 
104 Carlos Pereira 02 08 2004 M 31331-4649 D6 
134 José Alves 23 03 2002 M 2386-8897 D1 
121 Luiz Paulo Souza 10 05 2001 M 2241-5896 D5 
25 Marta Silveira 05 12 2002 F 2693-5521 
2594-8523 
2594-8522 
D5 
139 Ana Luiza Magalhães 12 01 2003 F 4545-8899 D6 
123 Pedro Sergio Doto 29 01 2003 M 2496-8855 D3 
148 Larissa Silva 01 06 2002 F 4289-9675 D6 
115 Roberto Fernandes 15 06 2003 M 2685-8132 D5 
22 Sergio Nogueira 10 10 2000 M 2594-3122 D4 
 
 
 
Todos os atributos (colunas) de uma relação devem ser atômicos, isto é, indivisíveis em termos de 
valores e componentes. 
Isso quer dizer que não existem colunas do tipo subgrupo, todas são itens elementares não 
subdivididos em nenhuma hipótese. E, também, não é permitida a existência da múltipla ocorrência de valores 
(multivalorados) em nenhum de seus atributos (colunas). 
É importante a compreensão de que cada linha de uma tabela representa um objeto, um assunto que 
é descrito pelos valores de cada uma dessas colunas. 
O esquema de uma relação, ou seja, a sua definição pode ser interpretada como uma declaração, ou 
um tipo de afirmação. 
O exemplo de uma tabela funcionário apresenta: 
 Número de registro (NumReg), nome de funcionário (NomeFunc), data de admissão (DtAdmissão), 
sexo (Sexo), telefone (Fone) e departamento (CodDepto); 
 Cada tupla (linha) da relação (tabela) deve ser interpretada como fato ou uma ocorrência particular 
dessa afirmação; 
 
 
 
 
 
Atributo 
Composto Atributo 
Multivalorado 
 
Página 26 de 52 
 
NumReg NomeFunc DtAdmissão Sexo Fone CodDepto 
101 Luis Sampaio 10/08/2003 M 2565-8974 D5 
104 Carlos Pereira 02/08/2004 M 31331-4649 D6 
134 José Alves 23/03/2002 M 2386-8897 D1 
121 Luiz Paulo Souza 10/05/2001 M 2241-5896 D5 
25 Marta Silveira 05/12/2002 F 2693-5521 D5 
139 Ana Luiza Magalhães 12/01/2003 F 4545-8899 D6 
123 Pedro Sergio Doto 29/01/2003 M 2496-8855 D3 
148 Larissa Silva 01/06/2003 F 4289-9675 D6 
115 Roberto Fernandes 15/06/2002 M 2685-8132 D5 
22 Sergio Nogueira 10/10/2000 M 2594-3122 D4 
 
4.3- DOMÍNIO 
Representa o conjunto de valores atômicos admissíveis de um componente (coluna) de uma relação 
(tabela). 
Exemplo 
 
 Telefone: conjunto de 10 dígitos; 
 Idade_Empregado: 16 ≥ idade ≤ 70; 
 Departamentos: conjunto de departamentos de uma empresa. 
 
A cada domínio está associado um tipo de dados ou formato. 
 
Exemplo 
 
 Telefone: (ddd) dddd-ddddd, onde d={0,1,2,3,4,5,6,7,8,9} 
 Idade_Empregado: número inteiro entre 16 e 70 
 
 
Restrições de domínio são estabelecidas determinando-se domínios de valores para cada coluna de 
uma tabela. Normalmente são estabelecidos e definidos os valores que uma coluna de uma tabela pode ter, 
isto é, o domínio da coluna. Permitem, por exemplo: 
 
 Verificar os valores inseridos em um banco de dados; 
 Testar consultas para garantir que as comparações tinham sentido; 
 Em geral, o domínio é especificado por tipos primitivos de dados, tais como: interger, float, char, 
date, Money, time, etc. 
 
Também, podem ser descritos pela definição de subconjuntos de tipos primitivos ou de listas 
enumeradas, ou seja, listas de valores possíveis de existir na coluna. 
 
 
4.4- CHAVE PRIMÁRIA 
 
Em toda e qualquer tabela existente em um banco de dados relacional haverá sempre uma coluna ou 
um conjunto de colunas concatenadas, cujos valores são únicos na tabela, isto é, nunca se repete aquele valor 
em nenhuma outra linha da tabela. 
 
Essa coluna ou conjunto de colunas concatenadas identifica uma única linha da tabela. Então dizemos 
que essa coluna ou conjunto de colunas forma a chave primária da tabela. 
 
Página 27 de 52 
 
 
NumReg NomeFunc DtAdmissão Sexo Fone CodDepto 
101 Luis Sampaio 10/08/2003 M 2565-8974 D5 
104 Carlos Pereira 02/08/2004 M 31331-4649 D6 
134 José Alves 23/03/2002 M 2386-8897 D1 
121 Luiz Paulo Souza 10/05/2001 M 2241-5896 D5 
25 Marta Silveira 05/12/2002 F 2693-5521 D5 
139 Ana Luiza Magalhães 12/01/2003 F 4545-8899 D6 
123 Pedro Sergio Doto 29/01/2003 M 2496-8855 D3 
148 Larissa Silva 01/06/2003 F 4289-9675 D6 
115 Roberto Fernandes 15/06/2002 M 2685-8132 D5 
22 Sergio Nogueira 10/10/2000 M 2594-3122 D4 
 
 
Na tabela acima, qual coluna ou qual conjunto de colunas que concatenadas formam um identificador 
único para cada linha desta tabela? 
 
Analisando a referida tabela, podemos ver que existe somente um valor de matrícula para cada linha, 
que não se repete, logo podemos determinar que matrícula é a chave primária da tabela funcionários. 
 
 
 
4.5- VALORES NULOS 
 
Por definição, todas as linhas de uma tabela têm de ser distinguíveis umas das outras, devem possuir 
um identificador único. 
 
Um identificador de chave primária nulo significa dizer que existe uma ocorrência (linha) na tabela 
sem identificação única, ou não distinguível. 
 
Se uma tabela relacional tem uma chave primária, que é um valor único para cada linha da tabela, logo 
esse valor não pode em hipótese alguma estar nulo, ou seja, ser desconhecido.Estendendo este conceito, destacamos que nenhuma das colunas que participam da composição da 
chave primária pode ter valor nulo, pois o resultado da concatenação seria nulo, em uma operação de 
concatenação de valores. 
 
 
 
4.6- REGRA DE INTEGRIDADE DE IDENTIDADE 
 
A identificação de uma linha de uma tabela não pode ser feita por um valor desconhecido, motivo 
pelo qual a chave primária de uma tabela não pode possuir nenhum elemento de sua composição com valor 
nulo. 
 
 
4.6.1- CHAVE PRIMÁRIA 
 
 Coluna ou concatenação de colunas; 
 Valor único na tabela; 
 Cada linha tem um valor diferente na chave primária; 
 Não existem valores nulos na chave primária. 
 
 
 
Página 28 de 52 
 
Atributos cujos valores no mundo real podem ser duplicados não devem ser definidos como chaves 
primárias de uma tabela (Nome, por exemplo). 
 
Em geral, uma tabela pode ter mais de uma chave que possua a capacidade de identificação única das 
linhas da tabela. Nesse caso, cada uma dessas chaves da tabela é chamada de CHAVE CANDIDATA. Uma das 
chaves será definida como primária e as outras ficam como chaves alternativas à chave primária. 
 
Em geral, entre todas as chaves candidatas, escolhe-se para chave primária aquela com o menor 
número de atributos ou mais significativa conceitualmente na identificação de cada fato ou ocorrência (linha) 
de uma tabela. 
 
 
Esquema de uma Tabela 
 A definição de uma tabela é realizada por um formato denominada esquema da tabela; 
 Esse formato destaca a chave primária por um sublinhado no nome da coluna: para a tabela de 
funcionários que apresentamos o esquema seria Funcionário (NumReg, NomeFunc, DtAdmissao, Sexo, 
Fone, CodDepto). 
 
 
 
4.6.2- CHAVE ESTRANGEIRA 
 
Uma tabela relacional é uma estruturação dos dados por assunto, organizada em tabelas com linhas e 
colunas, e cada linha é a representação de uma ocorrência de um objeto, um assunto, descrita por valores em 
cada coluna. Dessas colunas já sabemos que uma ou um conjunto delas forma o que definimos como o 
identificados único de cada linha que é a chave primária da tabela. 
 
Exemplo 
 
Vamos analisar as propriedades que as colunas de uma tabela relacional podem ter e as regras dessas 
propriedades: 
 
 Existem três tabelas nesse pequeno banco de dados. 
 São as tabelas referentes aos produtos de nossa cozinha, neste caso somente os alimentos. Uma que 
chamaremos de tabela de Estoque de alimentos, uma de Fornecedores e uma de Unidade de 
armazenamento. 
 Uma característica importante nas tabelas relacionais é que elas têm muitas vezes colunas comuns. 
 
Estoque de Alimentos 
Alimento Quantidade Data Validade Fabricante Unidade 
Feijão 2 20/08/2004 2 1 
Leite 3 12/07/2004 4 2 
Açúcar 5 12/08/2004 1 1 
Arroz 3 10/10/2004 6 1 
Azeite 2 12/03/2004 5 6 
Café 1 12/12/2004 3 1 
 
Fornecedores 
Fabricante NomeFab 
2 Coral 
4 CCPL 
1 União 
6 Tio João 
5 Galo 
3 Pilão 
Unidades de Armazenamento 
 
Página 29 de 52 
 
Unidade Descrição 
1 Kg 
2 Litro 
3 Peça 
4 Envelope 
5 Pote 500g 
6 Vidro 500g 
 
 Esquema do Banco de Dados 
 Estoque de Alimentos {Alimento, Quantidade, Data Validade, Fabricante, Unidade} 
 Fornecedores {Fabricante, NomeFabricante} 
 Unidades de Armazenamento {Unidade, Descrição} 
 
Observe que a tabela de Estoque de Alimentos tem as colunas Número do Fabricante e Código da 
Unidade, que também existem respectivamente nas tabelas Fornecedores e Unidade de Armazenamento. 
 
Esta é uma característica que em primeiro lugar tem como objetivo inicial evitar que sejam inseridos 
na tabela de alimentos, por exemplo, valores relativos a um mesmo fornecedor de duas maneiras: Tio João e T. 
João, fazendo com que apresentássemos o mesmo produto como sendo de dois fornecedores diferentes. 
 
Isso ajuda a eliminar ou diminuir erros de entrada de dados nos sistemas, e manter a consistência do 
banco de dados, pois utilizamos o número do fornecedor em lugar de, talvez, digitar o seu nome. 
 
O que significa uma tabela ter coluna ou colunas que existem em outra tabela? 
 
Analisando as tabelas e o esquema do banco de dados, observamos que cada tabela tem uma chave 
primária. 
 
A tabela Estoque de Alimentos tem como chave primária a coluna Alimento. 
 
A tabela Fornecedores tem como chave primária a coluna Fabricante, e a tabela Unidade de 
Armazenamento tem como chave primária a coluna Unidade. 
 
O que significa quando temos um campo que é chave primária de uma tabela que faz parte dos 
campos de outra tabela? Isso é o que denominamos de chave estrangeira. 
 
É uma referência de um elemento de uma tabela a um elemento de outra tabela, uma relação entre as 
tabelas, uma ligação lógica entre elas. 
 
Então, no exemplo, a coluna Fabricante na tabela Estoque de Alimentos é uma chave estrangeira, 
assim como Unidade também é outra chave estrangeira nesta tabela. 
 
Uma tabela pode ter tantas chaves estrangeiras quantas forem as suas associações a outras tabelas. 
 
Uma tabela pode ter um conjunto de atributos que contêm valores com o mesmo domínio de um 
conjunto de atributos que formam a chave primária de uma outra tabela. 
 
 
 
4.7- INTEGRIDADE REFERENCIAL 
 
Quando colocamos uma coluna como chave estrangeira em uma tabela, assumimos responsabilidade 
com o banco de dados por assim dizer. 
 
As colunas pertencentes à chave estrangeira da tabela A devem ter o mesmo domínio das colunas 
pertencentes à chave primária da tabela B. 
 
Página 30 de 52 
 
 
O valor de uma chave estrangeira em uma tabela A deve ser um valor de chave primária da tabela B, 
ou então ser nulo. 
 
Sintetizando: uma tabela contém uma chave estrangeira, então o valor dessa chave só pode ser: 
 
 Nulo – neste caso pode, pois representa a inexistência de referência para uma linha da tabela. 
 Igual ao valor de alguma chave primária na tabela referenciada. 
Como seria ter uma tabela com chave estrangeira nula? Vejamos: 
 
NumReg NomeFunc DtAdmissão Sexo CdCargo CodDepto 
101 Luis Sampaio 10/08/2003 M C3 D5 
104 Carlos Pereira 02/08/2004 M C4 D6 
134 José Alves 23/03/2002 M C5 D1 
121 Luiz Paulo Souza 10/05/2001 M C3 D5 
123 Pedro Sergio Doto 29/01/2003 M C1 Nulo 
115 Roberto Fernandes 15/06/2002 M C3 D5 
22 Sergio Nogueira 10/10/2000 M C2 D4 
 
Na linha DE Pedro Sergio Doto o valor para CodDepto está nulo, o que pode significar que ele ainda 
não está alocado a nenhum departamento, ou foi deslocado de algum departamento. 
 
O que importa é que ele não tem departamento assinalado, o que é uma situação válida. 
 
O que não pode haver é um valor de chave estrangeira que não exista como chave primária de 
nenhuma linha da tabela referenciada, no caso a tabela Departamento. 
 
Na definição de uma chave estrangeira somente podemos nos referenciar a uma chave primária de 
uma outra tabela? Nem sempre isso é verdade. 
 
Na criação de uma tabela estrangeira, além de podemos nos referenciar a um campo chave primária 
de outra tabela, também podemos nos referenciar a uma coluna que tenha sido definida como única, uma 
chave candidata. 
 
Qual a razão da integridade referencial? O que ela implica? 
 
Existe um conjunto de regras de operação para um banco de dados que coloca restrições, regras de 
atualização das tabelas do banco de dados, de forma a garantir e manter a integridade referencial. São elas: 
 
 
Regra Definição 
Deleção Restrita Ao excluir (deletar) a tabela pai , se ela possuir filhos relacionados (ou seja, se o departamento 
tiver funcionários), a exclusão é impedida. Isso evita que o bando de dados fique 
inconsistente, ou seja, linhas de Funcionário com valor de chave estrangeira inexistente como 
chave primária na tabela associada. Outras opções para garantir a integridade de referências 
do banco de dados seriam excluir todos os filhos em cascata, fazendo com que todos os 
funcionários referenciem um departamento-padrão ou fazer com que todos os funcionários 
fiquem sem departamento. 
Inclusão e Linha RestritaAo inserir um funcionário, caso seja obrigatório que ele já possua departamento associado, 
verifica se ele está relacionado a um departamento existente na tabela Departamento, senão 
impede a operação. 
Atualização e Linha Restrita Ao atualizar a chave estrangeira de uma tabela, verifica se existe uma linha da tabela associada 
que possua como chave primária o novo valor da chave estrangeira, senão impede essa 
operação. A opção cascata é sempre perigosa de ser utilizada em banco de dados, pois existe 
o risco de perder todos os dados existentes em uma determinada tabela se optar por apagar as 
suas linhas que estão associadas a uma determinada linha que será deletada da tabela que 
possui a chave primária referenciada. 
 
 
 
Página 31 de 52 
 
Exemplo 
 
Vamos fazer uma simulação de tabelas. Suponha que nossa tabela tenha somente os funcionários do 
departamento de vendas (D5). 
 
Funcionário 
NumReg NomeFunc DtAdmissão Sexo CdCargo CodDepto 
101 Luis Sampaio 10/08/2003 M C3 D5 
104 Carlos Pereira 02/08/2004 M C4 D6 
134 José Alves 23/03/2002 M C5 D1 
121 Luiz Paulo Souza 10/05/2001 M C3 D5 
123 Pedro Sergio Doto 29/01/2003 M Nulo D3 
115 Roberto Fernandes 15/06/2002 M C3 D5 
22 Sergio Nogueira 10/10/2000 M C2 D4 
 
Departamento 
CodDepto NumDepto RamalTel 
D1 Assist. Técnica 2246 
D2 Estoque 2589 
D3 Administração 2772 
D4 Segurança 1810 
D5 Vendas 2599 
D6 Cobrança 2688 
 
Se estabelecemos para a tabela Departamento a regra de cascata, então se apagarmos (deletar) a 
linha cuja chave primária é =”D5”, o resultado será a tabela funcionário como apresentada em seguida: 
 
NumReg NomeFunc DtAdmissão Sexo CdCargo CodDepto 
 
 
Vazia, completamente sem linhas. A regra de cascata provoca que todas as linhas de tabelas 
associadas a essa chave primária sejam deletadas, apagadas para evitar que fiquem existindo no banco de 
dados referências às linhas inexistentes em uma tabela. Mas não é somente o caso de deleção completa da 
tabela que preocupa, pois trabalhamos com nossa tabela original de funcionários: 
 
NumReg NomeFunc DtAdmissão Sexo CdCargo CodDepto 
101 Luis Sampaio 10/08/2003 M C3 D5 
104 Carlos Pereira 02/08/2004 M C4 D6 
134 José Alves 23/03/2002 M C5 D1 
121 Luiz Paulo Souza 10/05/2001 M C3 D5 
123 Pedro Sergio Doto 29/01/2003 M Nulo D3 
115 Roberto Fernandes 15/06/2002 M C3 D5 
22 Sergio Nogueira 10/10/2000 M C2 D4 
 
Se executarmos a mesma operação de deleção da linha relativa a Departamento de Vendas (D5). Essa 
tabela perderá todas as linhas que estavam associadas pelo valor de chave estrangeira =”D5”, perdendo os 
dados de alguns funcionários: 
 
Funcionário 
NumReg NomeFunc DtAdmissão Sexo CdCargo CodDepto 
104 Carlos Pereira 02/08/2004 M C4 D6 
134 José Alves 23/03/2002 M C5 D1 
123 Pedro Sergio Doto 29/01/2003 M Nulo D3 
22 Sergio Nogueira 10/10/2000 M C2 D4 
 
 
Página 32 de 52 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ESTUDOS DE CASO 
 
 
 
 
Página 33 de 52 
 
 
 
 
 
Fevereiro de 2018 
 
Página 34 de 52 
 
ESTUDO DE CASO 1 - A SECRETARIA DE UM COLÉGIO 
Um colégio solicitou a automação da sua secretaria possibilitando a agilização dos resultados dos alunos, tanto por matéria 
como curso extra-curricular. Após levantamento na secretaria, as informações do aluno encontradas foram matrícula, endereço, telefone, 
data de nascimento, filiação, observações; as informações sobre a matéria são sigla, nome, coordenador, carga horária, conteúdo, 
professor; as informações sobre o professor são matrícula, nome, endereço, telefone, data de matrícula, graduação, especialização, nota 
1° bimestre, nota 2° bimestre, nota 3° bimestre e nota 4° bimestre, média bimestral; as informações dos cursos extras são código, 
conteúdo, carga horária, conceito do aluno, professor e considerando que o professor leciona apenas uma única matéria e vários cursos 
extras. 
 
 
ESTUDO DE CASO 2 – A MAMÍFEROS & CIA 
A Mamíferos & Cia, uma empresa de produtos alimentícios, solicitou um sistema para o Departamento Pessoal. 
Os funcionários quando são contratados preenchem uma ficha com seu nome, endereço, telefone, data de nascimento e 
dependentes. Para cada dependente que possua, o funcionário anota o nome, data de nascimento e o grau de dependência (pais, filhos e 
conjugue). Este formulário é devolvido ao Departamento Pessoal que anota a matrícula, o código da seção, o código do cargo, a data de 
admissão e o salário deste mesmo funcionário. Para cada seção que a empresa possui, existe uma ficha com o código, o nome, o número 
de funcionários atuais e locação máxima. Em outro fichário encontramos os seguintes dados: o código do cargo, o nome do cargo, a 
descrição do cargo e a formação profissional adequada para o cargo. 
 
 
ESTUDO DE CASO 3 – A ASSISTÊNCIA MÉDIA SAÚDE SÓ ALEGRIA 
A Assistência Médica Saúde Só Alegria, solicitou a automação de sua lista de médicos referenciados. Atualmente são mantidos 
em fichários o nome, a especialidade, o número do registro profissional do médico (CRM), o endereço e o telefone do consultório. O 
mesmo médico poderá exercer mais de uma especialidade. Para cada especialidade em que o médico possa ser habilitado, necessita-se 
conhecer o nome e a descrição desta. Para a finalidade de controle de seus serviços, a assistência deseja relacionar os médicos de acordo 
com a especialidade, e também, deseja obter as especialidades de cada médico para eventuais consultas telefônicas e emissão de 
catálogos com as listas dos médicos para os seus usuários. 
 
 
ESTUDO DE CASO 4 – A COMPANHIA WB AIRLINES 
A Companhia de Aviação WB Airlines quer desenvolver um Sistema de Informação que controle a manutenção das aeronaves da 
Companhia. Para isto a companhia pretende manter um cadastro de todos os técnicos e de todas as aeronaves e ainda um terceiro das 
manutenções de cada aeronave. Sobre o técnico a Companhia pretende ter as seguintes informações armazenadas: nome, código interno, 
data de nascimento, sexo, naturalidade, qualificação (elétrico, mecânico ou eletrônico), telefone e endereço. Sobre as aeronaves: prefixo, 
código interno, tipo de aeronave (carga ou passageiro), horas de vôo e ano de fabricação. Sobre as manutenções interessa saber: data da 
última manutenção, tipo da manutenção (preventiva ou corretiva). Sabe-se que todas as aeronaves não podem ultrapassar um 
determinado número de horas de vôo, sem manutenção preventiva, sendo um técnico escalado para a inspeção preventiva. 
 
 
ESTUDO DE CASO 5 – A EDITORA INFO 
A Editora INFO solicitou a automação das suas atividades. Atualmente são mantidos em fichas numeradas o cadastro de autores 
e o cadastro de livros. As informações que a editora solicita para os autores são nome, formação acadêmica, endereço e telefone. Sobre 
os livros ela solicita o título, o autor, a sinopse e a classificação do assunto. 
 
 
ESTUDO DE CASO 6 - OFICINA GRAXAMIGA 
Na Oficina Graxamiga de mecânica de automóveis, um funcionário registra todos os serviços de consertos, para os clientes que 
efetuam o pagamento à vista em dinheiro, só é preciso registrar, a data do conserto, o tipo de conserto, o código da peça, a peça utilizada 
para o reparo junto com a quantidade, preço unitário, preço total das peças, custo da mão de obra e preço total a ser pago. Para as formas 
de pagamentos com cheque ou financiado, o funcionário deverá preencher um formulário com as informações acima citadas e o cadastro 
forma dos clientes junto com seu código. 
 
 
ESTUDO DE CASO 7 - A SABOR E CARINHO CIA 
Na Sabor e Carinho Cia onde se comercializa cestas de presente para todas as ocasiões, possui um serviço prático de entrega 
destas cestas por telefone. Nas vendas normais realizadas no local, o funcionário registrará o código do produto, o produto que está sendo 
comercializado, a quantidade, o preço unitário e o preço total. Para as vendas realizadas por telefone o funcionário deverá registrar em 
um formulário,o código do cliente com o seu cadastro formal caso não tenha sido cadastrado, o código do produto, data da ligação, data 
de entrega do produto, hora da ligação, a hora de entrega do produto, o endereço e o nome da pessoa para entrega. O funcionário 
também deverá registrar o código do produto, o produto que está sendo comercializado, a quantidade, o preço unitário e o preço total, 
para emissão de uma ordem de pagamento realizada através da conta de telefone do cliente. 
 
 
ESTUDO DE CASO 8 - ADMINISTRADORA DE IMÓVEIS TUDO CERTO 
 A Administradora de Imóveis Tudo Certo trabalha tanto com administração de condomínios, quanto com a administração de 
aluguéis. Uma entrevista com o gerente da administradora resultou nas seguintes informações: a administradora administra condomínios 
formados por unidades condominiais, cada unidade condominial é de propriedade de uma ou mais pessoas. Uma pessoa pode possuir 
diversas unidades, cada unidade pode estar alugada para no máximo uma pessoa. Uma pessoa pode alugar diversas unidades. 
 
 
 
 
Página 35 de 52 
 
ESTUDO DE CASO 9 - LOCADORA DE FILMES HOLLYWOOD 
 Uma pequena locadora de filmes possui ao redor de 2.000 DVDs, cujo empréstimo deve ser controlado. Cada DVD possui um 
número. Para cada filme, é necessário saber seu título e sua categoria (comédia, drama, aventura, ...). Cada filme recebe um identificador 
próprio. Para cada DVD é controlado que filme ele contém. Para cada filme há pelo menos um DVD, e cada DVD contém somente um 
filme. Alguns filmes tem dois DVDs. Os clientes podem desejar encontrar os filmes estrelados pelo seu ator predileto. Por isso, é 
necessário manter a informação dos atores que estrelam em cada filme. Nem todo filme possui estrelas. Para cada ator os clientes às 
vezes desejam saber o nome real, bem como a data de nascimento. A locadora possui muitos clientes cadastrados. Somente clientes 
cadastrados podem alugar DVDs. Para cada cliente é necessário saber seu prenome, seu sobrenome, seu telefone e seu endereço. Além 
disso, cada cliente recebe um número de associado. Finalmente, desejamos saber que DVDs cada cliente tem emprestados. Um cliente 
pode ter vários DVDs em um instante no tempo. Não são mantidos registros históricos de aluguéis. 
 
 
ESTUDO DE CASO 10 - SISTEMA DE RESERVA DE PASSAGEM ÁREA 
O objetivo do trabalho é projetar um sistema de reservas para uma companhia de aviação. O sistema contará com um banco de 
dados central, que será acessado por aplicações clientes, rodando tanto dentro da própria companhia, quanto fora dela. 
A transação central do sistema é a reserva. Uma reserva é identificada por um código gerado pelo sistema em computador. A 
reserva é feita para um único passageiro, do qual se conhece apenas o nome. A reserva compreende um conjunto de trechos de voos, que 
acontecerão em determinada data/hora. Para cada trecho, a reserva é feita em uma classe (econômica, executiva, etc). 
Um voo é identificado por um código e possui uma origem e um destino. Por exemplo, o voo 595 sai de Porto Alegre com 
destino a São Paulo. Um voo é composto de vários trechos, correspondendo às escalas intermediárias do voo. Por exemplo, o voo 595 é 
composto de dois trechos, um de Porto Alegre a Londrina e outro de Londrina a São Paulo. Cabe salientar que há cidades que são servidas 
por vários aeroportos. Por isso, é importante informar ao passageiro que faz a reserva, qual é o aeroporto no qual o voo passa. 
Às vezes os clientes, ao fazer a reserva querem saber qual é o tipo de aeronave que será utilizada em determinado trecho do 
voo. Alguns poucos voos, principalmente internacionais, têm troca de aeronave em determinadas escalas. 
Nem todos os voos operam em todos dias da semana. Inclusive, certos voos têm pequenas mudanças de horário em certos dias 
da semana, 
Cada reserva possui um prazo de validade. Caso os bilhetes não tenham sido emitidos, até esgotar-se o prazo da reserva, a 
mesma é cancelada. Reservas podem ser prorrogadas. 
Como o “check-in” de todos os voos está informatizado, a companhia possibilita a reserva de assento para o passageiro. 
Reservas de assento podem ser feitas com três meses de antecedência. 
Além de efetivar reservas, o sistema deve servir para vários tipos de consultas que os clientes podem querer fazer: 
a) possibilidade de viagem de uma cidade ou de um aeroporto para outro; 
b) o mesmo, mas restrito a determinados dias da semana; 
c) horários de chegada ou de saída em determinados voos; 
d) disponibilidade de vagas em um trecho de voo 
e) disponibilidade de determinados assentos em um trecho de voo. 
 
 
ESTUDO DE CASO 11 – SISTEMA DE LOCADORA DE VEÍCULOS 
A empresa em questão aluga automóveis, camionetas de passageiros e camionetas de carga. 
Ela atende a dois mercados, o das pessoas físicas e o das pessoas jurídicas. Para acelerar o atendimento, é importante conhecer 
os dados de clientes que já tenham usado a locadora no passado. Para cada pessoa física é necessário conhecer seu nome, sexo, data de 
nascimento, endereço e CPF. Já para as pessoas jurídicas é necessário conhecer seu nome, CNPJ, inscrição estadual e endereço. Os 
clientes são identificados por um código interno a locadora. 
A empresa tem uma grande rede de filiais, espalhadas pelo sul do país. Em um momento no tempo, um veículo encontra-se sob 
responsabilidade de uma filial. Entretanto, como veículos podem ser alugados para viagens em um sentido somente, eles podem mudar a 
filial. Um veículo é identificado pela sua placa. Além disso, é necessário conhecer o número do chassis, o número do moto, o tipo de 
veículo e a cor de cada veículo. 
O sistema de computador deverá registrar: 
a) os veículos disponíveis em determinada filial na data corrente; 
b) as reservas para veículos em uma filial, com previsão de que veículos estarão disponíveis em uma data futura; 
c) os veículos presentemente alugados pela filial, o ponto de entrega (caso seja diferente do de locação) e data de entrega 
prevista. 
Os veículos são classificados por uma tabela de tipos. Por exemplo, P3 corresponde a automóveis pequenos, de quatro portas e 
com ar-condicionado e G4 a grandes automóveis de luxo. As reservas não são feitas para uma marca ou modelo de veículo, mas para o 
tipo de veículo. 
Para os tipos de automóveis, os clientes desejam saber o tamanho, classificado em pequeno, médio e grande, o número de 
passageiros, o número de portas, bem como se possui os seguintes acessórios: ar condicionado, rádio, toca-fitas, CD, direção hidráulica e 
câmbio automático. Para tipos de camionetas de passageiros, as informações são as mesmas que para automóveis. Já para tipos de 
camionetas de carga, as informações acima não são relevantes. Neste caso, os clientes desejam saber a capacidade de carga da camioneta. 
Para cada tipo de veículo, há um determinado número de horas necessárias para limpeza e revisão de entrega, entre uma 
reserva e outra. 
Além disso, o sistema deve programar as revisões pendentes. Esta programação é feita com base em um conjunto de 
parâmetros que são a quilometragem atual do veículo, a quilometragem média diária de um veículo do tipo, bem como uma tabela de 
revisões do tipo de veículo. 
A seguradora que segura os veículos, exige que, para casa veículo alugado, seja mantida a identificação do motorista, o número 
de sua habilitação e data de vencimento da mesma. A habilitação não pode vencer dentro do prazo de locação. 
 
 
 
 
Página 36 de 52 
 
ESTUDO DE CASO 12 – CONGRESSO CIENTÍFICO 
Deseja-se apoiar por meio de informatização as atividades para a organização de um congresso científico. Os responsáveis pela 
organização do evento, que são os membros da comissão organizadora, divulgam com antecedência de no mínimo 6 meses uma chamada 
do tipo “call for papers”, convidando os interessados a enviarem suas propostas de artigos. Nessa chamada deverá constar uma lista de 
áreas de interesse, no qual deve se enquadrar o tema doartigo. 
Os artigos são analisados por um conjunto de avaliadores (comissão organizadora), responsável pela seleção dos artigos a serem 
apresentados durante o congresso. 
Características importantes da organização: 
 Um congresso apresenta um congresso de áreas de interesse. É identificado por um título e frequência de ocorrência (anual, bienal, 
etc). Cada ocorrência do congresso é beneficiada por um conjunto de patrocinadores, ocorrendo numa determinada data e local; 
 Todos os membros do congresso são denominados participantes. São cadastrados pelo nome, número de inscrição, endereço para 
correspondência e empresa onde trabalha. Enquadram-se nessa categoria avaliadores, autores, organizadores e meros assistentes; 
 Todo participante é vinculado a uma área de interesse. Esta possui um código e um nome; 
 Cada área possui um conjunto de artigos vinculados. Estes possuem um título, um conjunto de palavras chaves, conjunto de 
avaliadores, conceito final e a situação final (aceito, recusado). Ao final da seleção todos os artigos receberão uma cartinha com a sua 
situação final. Os artigos aceitos serão então alocados para apresentação na sessão correspondente a área de interesse do artigo; 
 Artigos são avaliados, no mínimo, por 3 avaliadores, podendo receber conceitos que variam de 1 a 10. Um artigo pode ter um número 
qualquer de autores; 
 Autores com artigos aceitos podem ser alocados como “chariman” da sessão. Uma sessão tem como propriedades a identificação da 
sala, data, hora da apresentação. Cada sessão obrigatoriamente corresponde a uma só área de interesse. 
 
 
ESTUDO DE CASO 13 – SISTEMA DE ALMOXARIFADO 
O almoxarifado pertence a um grupo de empresas do ramo industrial e serve para estocar peças destinadas às várias empresas 
do grupo. Cada empresa do grupo é considerada um cliente do almoxarifado. 
O almoxarifado está organizado em corredores. Cada corredor possui vários receptáculos para peças (um receptáculo é uma 
bacia retangular de material plástico). Os receptáculos são todos do mesmo tamanho. Os corredores são numerados e os receptáculos 
são numerados por corredor. Por exemplo, o receptáculo 2-10 é o décimo receptáculo do segundo corredor. 
Em uma das extremidades do almoxarifado encontra-se o setor de recepção de peças. Lá chegam as peças entregues pelos 
fornecedores. Quando ocorre a chegada de peças, a primeira atividade é registrar na ordem de compra a chegada das peças. Uma cópia 
de toda ordem de compra é sempre enviada ao setor de recepção. Assim, neste setor sempre sabe-se quais as peças que estão por ser 
entregues. As ordens de compra são geradas no setor de compras e apenas repassadas ao almoxarifado. 
Uma entrega corresponde sempre a uma ordem de compra. Entretanto, são admitidas entregas especiais, isto é, entregas que 
não completam a ordem de compra. Em uma entrega podem ser entregues diferentes quantidades de diferentes peças. 
As peças recebidas são colocadas sobre um estrado. Este estrado é então levado para o almoxarifado por uma empilhadeira e 
as peças são distribuídas nos receptáculos. Um estrado pode conter diferentes peças. Para cada peça, procura-se um receptáculo que já 
contenha unidades da peça em questão e que ainda tenha espaço para a carga chegada. Caso não haja um receptáculo nestas condições, 
procura-se um receptáculo vazio. 
A saída do almoxarifado se dá contra pedidos de clientes. Um pedido pode solicitar vários tipos de peças. Todas as peças que 
atendem um pedido são juntadas, embaladas e colocadas em uma rampa de carga (numerada) onde encosta o caminhão do cliente. Não 
há pedidos pendentes, isto é, os clientes sempre pedem quantidades de peças que há no estoque. 
O objetivo do sistema é o de aumentar o lucro do almoxarifado, ajudando sua equipe a guardar e recuperar itens mais 
rapidamente e a conhecer as quantidades estocadas. 
O almoxarifado é de grande porte e constantemente há várias empilhadeiras circulando por ele tanto para estocar quanto para 
buscar peças referentes a um pedido. 
Outros detalhes são fornecidos a seguir. 
O almoxarifado somente atende empresas. É necessário um cadastro de clientes com CNPJ, nome, endereço e telefone de 
contato. Para cada peça é necessário conhecer o seu UPC (“ Universal Product Code”), descrição e número interno à organização. 
Para cada entrega, o setor de saída de recepção monta uma lista de distribuição, que instrui o operador sobre que peças, em 
que quantidade ele deve estocar em que receptáculos. 
Para cada pedido, o setor de saída monta uma lista de busca, que instrui o operador sobre que peças, em que quantidades ele deve buscar 
em que receptáculos. 
Em termos de processos, é necessário que o sistema processe o seguinte: 
 Dê as ordens de distribuição de peças chegadas para cada chegada; 
 Dê as ordens para busca para cada produto; 
 Mantenha a quantidade estocada de cada item e de cada receptáculo; 
 Informe que peças em que quantidade devem ser estocadas ou buscadas em que receptáculos; 
Em termos específicos de transações devem ser consideradas: 
 Transações de chegada – registro da chegada de produtos; instruções para estocagem (em que estrado, em que receptáculo); 
confirmação da estocagem em um receptáculo. 
 Transações de saída de produtos – registro de um pedido; geração da lista de busca; confirmação da busca. 
 Consolidação de receptáculos (juntar as peças de mesmo tipo de dois receptáculos diferentes) 
 
 
ESTUDO DE CASO 14 – A ADMINISTRADORA MOVI MARKET 
A distribuidora Movie Market, empresa especializada na administração de cinemas. Deseja-se automatizar suas atividades. A 
administradora possui vários cinemas em diversas localidades. Cada cinema possui uma identificação única, um nome fantasia, um 
endereço completo, incluindo rua, bairro, município, estado e sua capacidade de lotação. Os filmes exibidos podem ser dos mais variados 
tipos e gêneros. Cada filme é registrado com um título original, o gênero, sua duração, sua impropriedade e seu país de origem, 
informações sobre os atores que compõem seu elenco e o seu diretor. Alguns cinemas apresentam mais de um filme em cartaz, sendo, 
nesses casos, sessões alternadas com um filme e outro. As sessões possuem horários que variam de acordo com a duração do filme 
 
Página 37 de 52 
 
necessitando saber data e hora da sessão. Além dessas informações deve-se registrar o público de cada sessão. Os atores de um filme 
podem, obviamente, atuar em diversos filmes. Um ator possui as seguintes características: número de identificação, nome e 
nacionalidade. Cada gênero é identificado por seu código e descrição. Uma distribuidora pode distribuir vários filmes sendo que os filmes 
são exclusivos de uma única distribuidora. Sobre a distribuidora é preciso saber o código, nome, endereço e telefone. 
 
 
ESTUDO DE CASO 15 - CARTÃO DE PONTO 
Imagine que fomos contratados para desenvolver um sistema de controle de cartão de ponto para uma grande empresa, para 
tal, nos forneceu as seguintes premissas de orientação: 
 Os funcionários terão o seu acesso controlado através de relógios-ponto, colocados nas diversas áreas da empresa; 
 Os relógios estão todos classificados por grupos; 
 Os funcionários, por sua vez, pertencem a diversos grupamentos funcionais, setorizados; 
 Existem na empresa diversos turnos de trabalho, jornadas e um funcionário pode mudar frequentemente de grupo e de jornada de 
trabalho, isto é, seus horários de entrada e de saída mudam com frequência regular; 
 Os visitantes da empresa receberão sempre um cartão-ponto de acesso especial para visitantes, visando controlar a entrada de pessoas 
na empresa, registrando, assim, sua passagem pela empresa; 
 Para cada funcionário deverão ser registrados os horários de entrada e saída na empresa, desde que seja registrado através do cartão 
em um dos relógios que ele esteja autorizado a registrar sua movimentação; 
 Todo o grupo de funcionários possui um administrador,