Análise de Sistemas I Aula 08

Prévia do material em texto

Aula
08
Análise de Sistemas I - UNIGRAN
MODELAGEM DE DADOS
Prezados(as) alunos(as),
Nesta aula, vamos aprender os conceitos de modelagem de 
dados e entender na prática como projetar as estruturas de dados.
 
Bom Trabalho!
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de:
• compreender o conceito e a importância da modelagem de dados;
• desenvolver modelos de dados de sistemas;
• entender as melhores práticas para definição dos modelos.
Seções de estudo
• Seção 1 – Projeto de sistemas
• Seção 2 – Terminologia, a importância da padronização
• Seção 3 – Modelos de dados
99
Análise de Sistemas I - UNIGRAN
Seção 1 – Projeto de sistemas
Um modelo de dados é uma coleção de conceitos matematicamente 
bem definidos que auxiliam a definição e a expressão das propriedades estáticas 
e dinâmicas dos objetos presentes em aplicações orientadas ao uso intensivo de 
dados. Aceita-se, em geral, que uma aplicação possa ser caracterizada por suas 
propriedades estáticas e dinâmicas e por restrições de integridade que as disciplinam. 
Stair (1998) afirma que “o propósito do projeto de sistemas é selecionar 
e planejar um sistema que satisfaça os requisitos necessários para obter a solução 
do problema”. São criados, para isso, alguns modelos de projetos para mostrar 
como o sistema deverá funcionar e quais resultados serão produzidos por ele. 
A análise estruturada tem igual preocupação com os processos e com 
os dados. Em relação a estes, ela os vê como entidades dotadas de atributos 
(campos), que serão representados através do DER - diagrama de entidade-
relacionamento. Em relação aos processos, segundo a técnica da análise 
estruturada, bastam apenas quatro tipos de elementos para retratar a especificação 
de um modelo lógico: fluxo de dados, entidade externa (terminador), processo (ou 
função) e depósito de dados (arquivo). Tais elementos podem ser arranjados em 
uma configuração a que se dá o nome de DFD - diagrama de fluxo de dados.
Seção 2 – Terminologia, a importância da padronização
Embora não faça parte específica da engenharia da informação, a 
terminologia assume papel importante dentro do seu contexto, já que é uma forma 
básica e essencial para se manter o diálogo e o entendimento uniforme entre todos 
os participantes do projeto, desde os técnicos de processamento de dados até os 
dirigentes e usuários envolvidos.
É um investimento de retorno garantido e de máxima valorização, 
especialmente, se essa terminologia for definida de forma padronizada, única e de 
fácil identificação. Diferente do idioma, a Terminologia deve evitar ao máximo 
os sinônimos, pois, adotando esse princípio, tornará, entre outros benefícios, mais 
fácil a memorização e a associação com o conceito embutido.
Manter um padrão para os nomes dos objetos, das colunas e de todos 
os elementos do banco de dados é muito importante. Mesmo que você seja um 
desenvolvedor individual em um determinado projeto, futuramente, você pode 
precisar fazer alguma alteração no seu projeto, ou outras pessoas podem vir a 
100
Análise de Sistemas I - UNIGRAN
trabalhar no seu projeto, se você mantiver um padrão, ficará mais fácil e rápido 
entender como o projeto foi feito.
Os nomes dos objetos que fazem parte do modelo de dados devem ser 
claros e objetivos, desta forma, qualquer pessoa que olhar o projeto saberá o que 
determinado objeto quer dizer, baseado no seu nome que já identifica facilmente 
que tipo de informação estará armazenada ali. 
Por exemplo: Se vamos criar um local para guardar as informações dos 
clientes de uma loja, observe a estrutura a seguir:
Podemos ver, no exemplo acima, que os nomes escolhidos não nos dão uma 
boa ideia do tipo de informação armazenada ali. Mas, se observarmos o próximo 
exemplo, veremos que o nome claro e objetivo facilitará nosso entendimento a 
qualquer momento que precisarmos fazer uma consulta a este projeto.
NOME DA ENTIDADE: TABELA 1
CAMPO 1 123.456.789-98
CAMPO 2 JOSÉ DA SILVA
CAMPO 3 AV. AFONSO PENA, 5678
CAMPO 4 CAMPO GRANDE
CAMPO 5 9999-1234
Tabela 8.1 – Exemplo de terminologia mal defi nida
Fonte: Acervo pessoal
NOME DA ENTIDADE: CLIENTES
CPF 123.456.789-98
NOME JOSÉ DA SILVA
ENDEREÇO AV. AFONSO PENA, 5678
CIDADE CAMPO GRANDE
FONE 9999-1234
Tabela 8.2 – Exemplo de terminologia clara e objetiva
Fonte: Acervo pessoal
Para
Refl eƟ r
Se preocupar com a padronização e a uƟ lização de termos 
signifi caƟ vos dentro do projeto não pode e não deve ser chamado 
de “perda de tempo”. Na verdade, quando nos preocupamos com 
isso, estamos invesƟ ndo tempo para tornar o projeto melhor, mais 
organizado e, consequentemente, perderemos menos tempo nas 
futuras e necessárias manutenções.
101
Análise de Sistemas I - UNIGRAN
Os termos usados dentro de todo o projeto de sistema podem facilitar 
muito o trabalho do analista quando são bem definidos, ou, ao contrário, podem 
causar muito transtorno e perda de tempo quando os nomes não são bem 
escolhidos, por isso é importante sempre cuidar da terminologia e da padronização 
das informações na hora de “desenhar” o sistema.
Seção 3 – Modelos de dados
Os modelos de dados podem ser definidos como um conjunto de 
ferramentas conceituais para a descrição dos dados, dos relacionamentos entre 
eles e das restrições de consistência e integridade. Um modelo de dados é um 
conjunto de conceitos que podem ser utilizados para descrever a estrutura “lógica” 
e “física” de um banco de dados.
3.1 DIAGRAMA ENTIDADE X RELACIONAMENTO (DER)
O modelo Entidade X Relacionamento foi criado por Peter, em 1976 e 
representa um modelo conceitual de alto nível. Esse modelo está mais próximo da 
visão do usuário. Por esse motivo a participação do usuário é intensa, haja vista 
que o entendimento se torna mais claro quanto às estruturas do sistema.
3.1.1 OBJETOS DO MODELO ER
ENTIDADE
Entidade é uma estrutura estática que representa um objeto, concreto ou 
abstrato, do mundo real. Cada entidade possui um conjunto de propriedades que 
chamamos de atributos. Estes atributos formam a estrutura da entidade. 
Por exemplo, as entidades podem ser representações abstratas de 
funcionários da empresa, movimentos de vendas, produtos do estoque, alunos de 
uma escola, professores, notas etc.
As entidades são representadas por um retângulo, como mostra a figura 8.1.
Na seção seguinte, vamos conhecer os elementos que fazem parte da modelagem de 
dados, saber qual a importância de cada um e como defi ni-los.
102
Análise de Sistemas I - UNIGRAN
Posteriormente, quando o modelo ER for transformado em um Banco de 
Dados físico, essas entidades serão chamadas de TABELAS.
RELACIONAMENTO
O Relacionamento é a associação entre as ocorrências das entidades. O 
relacionamento deve expressar o significado da associação no mundo real. 
Relacionamentos podem ser representados por uma “linha” na notação 
de James Martin ou por um “losango” na notação de Peter Chen.
Nas figuras 8.2 e 8.3, são mostrados exemplos de relacionamentos 
representados nas duas notações. As notações mudam a forma de representar a 
modelagem, porém as duas formas têm o mesmo significado. Em outras palavras, 
só muda o desenho do diagrama. As notações são formas diferentes de expressar 
a mesma ideia.
ALUNO DISCIPLINA
Figura 8.1 – Representação das entidades
Fonte: Acervo pessoal
RELACIONAMENTO
ALUNO NOTA DO ALUNO
Figura 8.2 – Relacionamento na notação de James Martin
Fonte: Acervo pessoal
RELACIONAMENTO
ALUNO NOTA DO ALUNO
Figura 8.3 – Relacionamento na notação de Peter Chen
Fonte: Acervo pessoal
tem
103
Análise de Sistemas I - UNIGRAN
Relacionamentos podem ser obrigatórios (total) ou opcionais (parcial).
ATRIBUTO
Os atributos formam a estrutura onde as informações serão armazenadas 
dentro da entidade ou do relacionamento. Os atributoscaracterizam as entidades ou 
relacionamentos. São exemplos de atributos: CÓDIGO, NOME, ENDEREÇO, 
TELEFONE, DATA DA VENDA etc.
INSTÂNCIA
As instâncias são as ocorrências dentro das entidades, ou seja, os dados 
que serão armazenados dentro dos atributos. São exemplos de instâncias:
• Nome: Águida Lino de Melo
• Fone: (67) 9999-1234
As instâncias são o mesmo que os registros dentro das entidades e 
também podem ser chamadas de “tuplas”.
DOMÍNIO
Domínio é o conjunto de valores que o atributo pode assumir. São 
exemplos de domínio:
• Sexo: M ou F
 - Os valores M e F fazem parte do domínio do atributo SEXO, 
pois estes são os valores que podem ser armazenados no espaço reservado para 
guardar a informação do SEXO.
• UF: AM, MA, MS, MG, SP, SC, RS, ...
 - O conjunto de siglas que representam os Estados brasileiros são 
o domínio do campo UF, pois este campo só poderá receber um valor que esteja 
dentro das siglas pertencentes a este conjunto. Se tentarmos usar uma sigla, por 
exemplo, SS, estaremos tentando armazenar um valor que está fora do domínio 
do atributo, portanto não será aceito como válido.
• Data de Nascimento: Conjunto de datas válidas menores que a data atual
 - Neste exemplo, utilizamos a definição de um domínio como uma 
regra de validade da informação, ou seja, indicamos que fará parte do domínio da 
Data de Nascimento todas as datas válidas que sejam menores que a data atual. 
Significa que não poderei cadastrar ninguém cuja data de nascimento seja igual à 
data de hoje. Este tipo de domínio também pode ser chamado de regra de validação.
104
Análise de Sistemas I - UNIGRAN
OBRIGATORIEDADE
A obrigatoriedade de um atributo indica que o mesmo não pode existir 
dentro da entidade sem ter um valor preenchido, ou seja, o atributo não pode ficar 
vazio ou com valor nulo. A obrigatoriedade dos atributos pode variar de acordo 
com os objetivos do projeto. 
Alguns atributos devem ser obrigatórios por definição, sem que isto 
precise ser informado pelo usuário. Por exemplo: na entidade ALUNO, o NOME 
do aluno não pode ficar vazio, por esse motivo ele é dito como atributo obrigatório, 
pois não faz sentido cadastrar um aluno sem o nome. Outra situação que pode fazer 
com que o campo deva ser obrigatório é a necessidade em atender os objetivos 
do negócio da empresa, por exemplo: Em uma loja de departamentos, um cliente 
não pode ser cadastrado sem que o seu número de CPF seja informado, portanto, 
o atributo CPF é obrigatório na entidade CLIENTE.
CARDINALIDADE
É a quantidade de relacionamentos das ocorrências de uma entidade com 
outra. A cardinalidade dos relacionamentos pode ser classificada como:
• 1:1 (um para um) – quando cada ocorrência de uma entidade se 
relaciona com apenas uma ocorrência da outra entidade;
• 1:n (um para muitos) – quando cada ocorrência de uma entidade se 
relaciona com várias ocorrências da outra entidade;
• n:n (muitos para muitos) - quando cada ocorrência de uma entidade 
se relaciona com várias ocorrências da outra entidade e vice-versa. Por exemplo: 
Num sistema acadêmico, um curso tem várias disciplinas, e uma disciplina (língua 
portuguesa, por exemplo) pode aparecer em vários cursos.
Rui Barbosa
Castro Alves
Café Filho
Fernando Pessoa
Alunos
BIM 1 – 7,5
BIM 2 – 8,5
BIM 1 – 4,5
BIM 2 – 9,0
BIM 3 – 7,0
BIM 1 – 8,0
BIM 1 – 6,5
Notas
EnƟ dades
1 n
Figura 8.4 – Representação das cardinalidades
Fonte: Acervo pessoal
105
Análise de Sistemas I - UNIGRAN
No exemplo da figura 8.4, cada aluno pode estar relacionado a várias 
notas. Isso caracteriza um relacionamento 1 para N (muitos) entre ALUNOS e 
NOTAS, ou seja, um aluno pode ter várias notas.
AUTO-RELACIONAMENTO
É o relacionamento entre ocorrências da mesma entidade. No exemplo da 
figura 8.5, cada empregado está relacionado com o chefe do setor onde trabalha, 
mas o chefe do setor também é um empregado, por isso, um empregado pode 
estar relacionado com outro empregado.
CHAVE
A chave da entidade serve para identificar as instâncias (registros, 
ocorrências) dentro da entidade, conhecida como chave primária. A chave serve 
também para relacionar uma entidade á outra, conhecida como chave estrangeira 
ou secundária. Por exemplo, dentro da entidade ALUNO podemos ter várias 
instâncias, ou seja, vários registros de alunos. No entanto, podem existir alunos 
com o mesmo nome, o que dificulta a identificação de um ou outro. Assim, cada 
instância dentro da entidade precisa de um identificador que o diferencia de todos 
os outros. A esse identificador chamamos de CHAVE.
As chaves podem ser formadas por um ou mais atributos, dependendo da 
necessidade da identificação da entidade.
Existem dois tipos de chaves: Chave Primária e Chave Estrangeira.
Chave Primária
Também conhecida como Chave Principal, serve para identificar cada 
instância (tupla) dentro da entidade. 
EMPREGADO Supervisiona
Figura 8.5 – Auto-relacionamento
Fonte: Acervo pessoal
Atenção!!!
Toda enƟ dade precisa ter obrigatoriamente uma Chave Primária. 
106
Análise de Sistemas I - UNIGRAN
Em uma mesma entidade não podem existir duas tuplas idênticas, por 
esse motivo as chaves não podem se repetir. A chave serve para dar unicidade 
à tupla, é ela que diferencia uma tupla de todas as outras. Todos os campos da 
entidade, exceto a chave, podem se repetir. 
A chave primária de uma entidade é formada por um ou mais atributos. 
Quando é formada por apenas um atributo, a chamamos de chave simples, quando 
é formada por dois ou mais atributos, a chamamos de chave composta.
Exemplo:
A entidade aluno possui a seguinte estrutura:
Na estrutura existente, deve-se escolher um ou mais campos que irão 
compor a chave. Para isso, é necessário observar algumas regras para a criação da 
chave da entidade, que valem para qualquer entidade do sistema:
a. os atributos de uma chave nunca podem ficar vazios, são sempre obrigatórios;
b. uma chave não pode nunca se repetir. Se ela serve para dar unicidade 
à tupla, significa que não podem existir na mesma entidade duas chaves com 
conteúdos iguais;
c. ao escolher uma chave, devemos adotar o princípio da minimalidade, 
ou seja, a chave deve ser composta por um conjunto mínimo de atributos que sejam 
suficientes para formar a chave e para garantir que ela seja única dentro da entidade.
Na estrutura do exemplo, o campo NOME não pode ser escolhido como 
chave porque podem existir alunos com nomes iguais, o mesmo acontece com 
ENDEREÇO, pois podem ter dois alunos morando no mesmo endereço e assim 
por diante. O atributo CPF não se repetirá nunca, pois não existem dois CPFs 
iguais, mas antes de escolher o CPF como chave, temos que observar a regra da 
letra “a” citada anteriormente, que diz que uma chave não pode ser vazia. Isto 
significa que o CPF só poderá ser chave se todos os alunos tiverem um CPF. 
NOME
ENDEREÇO
BAIRRO
CIDADE
UF
CEP
E-MAIL
CPF
RG
FONE
107
Análise de Sistemas I - UNIGRAN
Se puder existir ao menos um aluno que não tenha CPF, esse atributo não 
poderá ser escolhido como chave. Poderíamos, então, optar por formar a chave 
com mais de um atributo. Poderíamos escolher o CPF e o nome para formarem 
juntos a chave. Nesse caso, poderíamos pensar que não haveria problema do CPF 
ficar vazio porque a chave seria formada pelos dois atributos juntos e o nome não 
ficaria vazio, mas, novamente, teremos problemas, mas os campos que formam a 
chave são todos obrigatórios, ou seja, não podem ficar vazios. Devemos observar 
também as recomendações a seguir:
1º: É recomendado evitar o uso de campos de texto como parte da chave, 
pois alguns gerenciadores de banco de dados trabalham mais lentamente quando 
a chave é formada por campos de texto;
2º: Pode também acontecer de termos dois alunos com o mesmo nome e 
que não tenham CPF. Isso faria com que tivéssemosduas chaves iguais.
Chave natural e chave artificial
A chave primária de uma entidade pode ser chamada de natural ou 
artificial. A chave será natural quando é formada por atributos que já fazem 
parte da entidade, ou seja, não é necessário “criar” nenhum atributo (como um 
“código”) para formar a chave.
A chave primária será chamada de artificial quando é formada por algum 
atributo que não faça parte da entidade modelada, ou seja, quando nenhum dos 
atributos já existentes na entidade, ou uma combinação desses atributos, não são 
necessários para que a chave seja única. Nestes casos em que a entidade não possui 
atributos suficientes para formar uma chave única, criamos uma chave artificial, 
que geralmente é um código ou número sequencial. Sendo ele sequencial, nunca 
irá se repetir.
A boa práƟ ca da modelagem de dados orienta que sempre devemos dar prioridade 
aos atributos naturais na hora de escolher a chave primária da enƟ dade, evitando a 
criação de campos que não fazem parte do negócio que está sendo modelado.
É claro que podemos pensar que um código sequencial irá facilitar, 
e muito, na hora da programação do sistema, mas o objeƟ vo da 
modelagem é dar prioridade à qualidade do projeto. A qualidade do 
programa será consequência do bom projeto e da experiência da equipe 
de programação.
108
Análise de Sistemas I - UNIGRAN
O princípio da minimalidade também orienta que uma chave primária 
artificial poderá ser usada quando o conjunto de atributos naturais que formam 
a chave é muito grande e esta entidade faz relacionamento com várias outras 
entidades, ou seja, quando é necessário usar uma combinação de muitos atributos 
dentro da entidade para se ter uma chave única, pode-se criar uma chave artificial 
para facilitar o relacionamento com as outras entidades. Mas as chaves artificiais 
devem ser usadas com critério, para que não se torne uma prática comum com o 
intuito apenas de criar uma chave “mais fácil”.
Como vimos acima, existem casos em que os atributos não são suficientes 
para formar uma boa chave. Quando isso acontece, teremos que criar um novo 
atributo identificador para ser a chave da entidade. No nosso exemplo, criaremos 
um atributo CÓDIGO para ser a chave, mas vale lembrar que só se deve criar um 
atributo identificador se a entidade não possuir atributos suficientes para formar a 
chave. A entidade ALUNO com a definição da chave ficará assim:
O campo-chave CÓDIGO está marcado com o símbolo “#”, para 
indicarmos que ele é a chave da entidade.
Chave Estrangeira
Também chamada de Chave Externa ou Chave Secundária, é usada 
sempre que há um relacionamento entre entidades. A chave estrangeira em uma 
entidade sempre se referencia a uma chave principal em outra entidade, ou seja, o 
relacionamento é feito sempre através da chave principal. Se uma chave principal 
de uma entidade for composta (por mais de um atributo), a chave estrangeira 
que se relaciona com ela em outra entidade também será composta, ou seja, elas 
devem ser compatíveis para a relação.
# CÓDIGO
NOME
ENDEREÇO
BAIRRO
CIDADE
UF
CEP
E-MAIL
CPF
RG
109
Análise de Sistemas I - UNIGRAN
A chave estrangeira, diferente da chave principal, não serve para 
identificar as tuplas da entidade, mas sim para relacionar as tuplas de uma entidade 
com as tuplas de outra.
No exemplo acima, o código do aluno que aparece na entidade 
MATRÍCULA é uma chave estrangeira que está relacionada com o código do 
aluno na entidade ALUNO. A chave estrangeira deve ter o mesmo tipo e tamanho 
que a chave principal a que se refere. Diferente da chave principal, a chave 
estrangeira não precisa ser obrigatória, a menos que as necessidades do projeto 
exijam que ela o seja.
Uma entidade pode ter mais de uma chave estrangeira, dependendo da 
quantidade de relacionamentos que ela terá com outras entidades.
ENTIDADE FORTE E ENTIDADE FRACA
A entidade pode ser classificada como Forte e Fraca.
• Entidade Forte
Atenção!!!
Uma chave estrangeira sempre irá se relacionar com uma chave primária da outra 
enƟ dade, portanto elas têm que ter obrigatoriamente a mesma estrutura e os 
campos devem ser dos mesmos Ɵ pos e tamanhos, signifi ca dizer que elas devem ser 
compaơ veis para a relação.
Figura 8.6 – Representação de chave primária e estrangeira
Fonte: Acervo Pessoal
110
Análise de Sistemas I - UNIGRAN
 o Sua existência não depende de outra entidade
 o Sua chave é composta apenas por atributos próprios
• Entidade Fraca
 o Sua existência depende de outra entidade
 o Não possui atributos próprios suficientes para montar a chave
No exemplo da figura 8.7, as ocorrências da entidade NOTA DO ALUNO 
só poderão existir no sistema se houver o ALUNO correspondente.
INTEGRIDADE REFERENCIAL
Quando a ocorrência de uma entidade (fraca) depende da ocorrência 
de outra entidade (forte), ocorre a dependência existencial. Como foi visto 
anteriormente, uma entidade fraca depende de outra entidade para existir. É o 
mesmo que dizer que uma ocorrência de NOTA DO ALUNO só existirá se houver 
o ALUNO, ou seja, não pode existir uma nota lançada para um aluno se este aluno 
não estiver cadastrado no sistema. Se por um descuido um aluno for excluído 
do sistema, as notas desse aluno ficariam “perdidas”, sem relacionamento com 
ALUNO, ou seja, haveria uma quebra da integridade.
ALUNO NOTA DO ALUNO
1 n
EnƟ dade Forte EnƟ dade Fraca
Figura 8.7 – Entidade forte e fraca
Fonte: Acervo Pessoal
ALUNO NOTA DO ALUNO
1 n
EnƟ dade Forte EnƟ dade Fraca
Figura 8.8 – Integridade referencial
Fonte: Acervo Pessoal
111
Análise de Sistemas I - UNIGRAN
Retomando a conversa inicial
• Seção 1 – Projeto de sistemas
Aprendemos nesta seção que projetar um sistema é criar modelos 
e definições que irão resultar em um sistema que esteja de acordo com o que 
o usuário espera, conforme suas necessidades e visando sempre resolver os 
problemas pelos quais foi solicitada a criação de um sistema.
• Seção 2 – Terminologia, a importância da padronização
Nesta seção, pudemos perceber a importância de se usar termos 
padronizados para facilitar o entendimento do projeto. Quando se faz um sistema, 
não devemos pensar apenas em facilitar o trabalho durante o projeto, é preciso 
enxergar mais à frente e tentar sanar problemas que ainda não aconteceram. Mas 
se os problemas ainda não apareceram, como vamos saber que eles poderão 
ocorrer? A resposta é muito simples: construir um projeto sem se preocupar 
com a padronização e com o uso de nomes e termos significativos irá com 
certeza dificultar o entendimento do projeto quando for necessário fazer alguma 
manutenção ou nova implementação, portanto, podemos afirmar que a falta da 
padronização certamente causará um transtorno no futuro, por isso podemos 
evitá-lo antes que ele ocorra.
• Seção 3 – Modelos de dados
Na terceira seção, aprendemos os conceitos básicos sobre modelagem 
de dados. Vimos também as regras e orientações para a criação das chaves das 
entidades e a importância de se ter uma preocupação especial com estas chaves 
na hora de projetarmos nossa estrutura de dados.
Chegamos, assim, ao fi nal da Aula 8. Vimos conceitos importantes 
sobre modelagem de dados e algumas dicas para defi nição das 
estruturas de dados. Agora, vamos relembrar alguns pontos para 
melhorar ainda mais o entendimento dos conceitos.
112
Análise de Sistemas I - UNIGRAN
Sugestões de leituras, sites e vídeos
Sites
• Introdução a modelagem de dados. Disponível por www em http://www.
devmedia.com.br/introducao-a-modelagem-de-dados/24953. Acesso em 
12/07/2013.
• Modelagem de dados: chaves simples e chaves compostas. Disponível por 
www em http://www.plugmasters.com.br/sys/materias/349/1/Modelagem-de-
Dados%3A-Chaves-Simples-e-Chaves-Compostas. Acesso em 30/10/2013.
Vídeos
• Aula 1 - Modelagem de dados: introdução e conceitos.Disponível por www em 
http://www.youtube.com/watch?v=V7uB_TIPYtk. Acesso em 20/10/2013.
• Aula 2 – Modelagem de dados: relacionamentos. Disponível por www em http://
www.youtube.com/watch?v=0n_NX6-bXlk. Acesso em 20/10/2013.
113
Análise de Sistemas I - UNIGRAN
114