4° Semestre ADS
-
Upload
andressaelida -
Category
Documents
-
view
49 -
download
5
description
Transcript of 4° Semestre ADS
Alta Floresta23/10/2014
ANDRESSA ÉLIDA CHAVES LUÍZ
SISTEMA DE ENSINO PRESENCIAL CONECTADOANÁLISE E DESENVOLVIMENTO DE SISTEMAS
DESENVOLVIMENTO DE SISTEMAS II:Análise Orientada a Objetos II; Banco de Dados II; Programação
Orientada a Objetos e Programação para Web I.
Alta Floresta23/10/2014
DESENVOLVIMENTO DE SISTEMAS II:Análise Orientada a Objetos II; Banco de Dados II; Programação
Orientada a Objetos e Programação para Web I.
Trabalho apresentado ao Curso Análise e Desenvolvimento de Sistemas da UNOPAR - Universidade Norte do Paraná, para as disciplinas: Banco de Dados II; Análise Orientada a Objetos II; Programação Orientada a Objetos e Programação para Web I.
Professores: Roberto Y. Nishimura, Aderson Emídio M. Gonçalves, Marcio Roberto Chiaveli e Veronice de Freitas.
ANDRESSA ÉLIDA CHAVES LUÍZ
SUMÁRIO
1 INTRODUÇÃO
2 OBJETIVO
3 DESENVOLVIMENTO5
3.1 SEGURANÇA DA INFORMAÇÃO 5
3.1.1 Vulnerabilidades da Web.
3.1.2 Práticas de Segurança
3.1.3 Processamento de Formulários .
3.1.4 Sistemas de Login .
3.2 DIAGRAMA DE ATIVIDADE (UML) .
3.2.1 Diagramas de Atividades da TELECINE MOZER .
3.3 NORMALIZAÇÃO DO DIAGRAMA ENTIDADE RELACIONAMENTO (MRN).
3.3.1 Modelo entidade relacionamento (MER) .
3.3.2 Técnica de modelagem entidade e relacionamento
3.3.3 Diagrama Entidade-Relacionamento (DER) .
3.3.4 Normalização .
4 CONCLUSÃO
REFERÊNCIAS
3
1 INTRODUÇÃO
Este trabalho irá expandir conteúdos abordados durante o 4º
Semestre do Curso Superior de Tecnologia em Análise e Desenvolvimento de
Sistema, assim expondo temas para melhor conceituar o aprendizado.
Tendo como pesquisa o desenvolvimento da aplicação web de
locação de filmes para a empresa TELECINE MOZER, a qual pertence ao grupo
Todos, sendo pioneira em atendimentos e locação de filmes via web.
Será abordado a segurança no desenvolvimento de aplicações
WEB, além de conceitos básicos de um Diagrama de Atividade e suas
características; e a Normalização de dados no Diagrama Entidade Relacionamento.
Portanto dentro do contexto proposto pelos professores, buscarei
encontrar soluções para os desafios apresentados, através de pesquisas pela
internet obtendo um melhoramento no sistema de locação dos filmes da “TELECINE
MOZER”.
.
4
2 OBJETIVO
Realizar o estudo aprofundado dos principais temas desse semestre
referente à Desenvolvimento de Sistemas II, sabendo as principais características
abordadas dos diferentes temas exposto neste trabalho.
Propor melhoramentos que se adéquam dentro do contexto
“TELECINE MOZER”. Desenvolvendo um diagrama de atividades para o processo
de locação; e criação do diagrama de entidade e relacionamento para a mesma,
expondo a importância da segurança para o desenvolvimento de sistemas WEB.
Cujo objetivo maior é de fornecer um atendimento diferenciado aos
nossos clientes, visando uma maior comodidade, segurança e inovação tecnológica.
5
3 DESENVOLVIMENTO
A escalabilidade, portabilidade e fácil acesso providos pela
plataforma Web têm popularizado seu uso no desenvolvimento de diversas
aplicações. Porém, o crescente número de incidentes de segurança levanta
preocupações quanto à sua seguridade. Uma parte destes incidentes decorrem da
falta de consideração de segurança durante o processo de desenvolvimento. Este
trabalho tem como objetivo propor práticas de segurança a serem aplicadas durante
o processo de desenvolvimento de software Web que minimizem os riscos,
aumentando a qualidade e confiabilidade do produto final. Nele serão apresentados:
conceitos de segurança da informação, as vulnerabilidades mais comuns existentes
em software Web e algumas práticas que devem ser aplicadas durante o
desenvolvimento.
Nos últimos anos, o desenvolvimento de aplicações voltadas à Web
vem sendo expandido por apresentar vantagens sobre software instalado
localmente, tais como: não necessidade de instalação local, atualização rápida, fácil
escalabilidade e acesso de qualquer local com conexão à Internet. Porém, o
aumento no número de incidentes de segurança na Web gera preocupação quanto à
confiabilidade desses sistemas. As estatísticas do Centro de Estudos, Reposta e
Tratamento de Incidentes de Segurança no Brasil mostram que o número de
incidentes notificados mais que dobraram de 2005 (68.000) a 2010 (142.844).
Os investimentos em infraestrutura na área de segurança, com o uso
de firewalls e antivírus, por exemplo, fornecem alguma proteção às redes e aos
servidores, embora sejam insuficientes frente às necessidades de segurança no
nível da aplicação. Para suprir essa lacuna existem práticas que podem ser
utilizadas durante o desenvolvimento dos sistemas, embora acabem sendo
negligenciadas por muitos desenvolvedores em favor do tempo de entrega, da
usabilidade e do design gráfico, como relatado por Scott e Sharp (2002).
1.1.SEGURANÇA DA INFORMAÇÃO
A segurança de sistemas é cada vez mais importante para empresas
e indivíduos, especialmente com o constante aumento do número de serviços
prestados via Internet e de incidentes de segurança, segundo Sommerville (2007).
6
Para Fiorio et al. (2007), a segurança em sistemas computacionais consiste em
empregar conceitos, metodologias e técnicas que protejam o sistema de ataques,
sobretudo externos, que venham a gerar prejuízos tanto de ordem financeira quanto
social.
De acordo com Bishop (2008), a segurança da informação é
composta por três pilares, que são:
Confidencialidade: é manter informações ou recursos em segredo. Exemplo:
o uso de nome de usuário e senha que permite que somente um usuário
acesse o e-mail.
Integridade: é a confiabilidade na origem da informação. Exemplo: um usuário
recebe um e-mail de seu amigo que foi alterado por um interceptador,
perdendo a integridade.
Disponibilidade: é a garantia de que as informações estarão disponíveis aos
usuários autorizados quando necessário. Exemplo: a sobrecarga nos
servidores da Receita Federal compromete a disponibilidade do sistema de
envio de declarações de impostos.
Em aplicações Web, a manutenção dos três pilares pode ser mais
difícil do que naquelas rodadas localmente. Isso se deve ao fato de estarem
disponíveis em uma rede aberta, o que pode comprometer a confiabilidade e
integridade, e de dependerem, muitas vezes, da infraestrutura de terceiros, o que
pode comprometer a disponibilidade.
Para Pinto e Stuttard (2008), o maior problema de segurança das
aplicações Web é o fato de que os usuários podem fazer entradas arbitrárias, ou
seja, podem transmitir tipos de dados não previstos no software, como parâmetros,
comandos e cookies, que podem comprometer a aplicação e a seguridade de seus
dados. Isso é reforçado por Scott e Sharp (2002), que afirmam que a maioria dos
problemas de segurança no nível de aplicação são causados pelo fato de que o
aplicativo assume que os dados transmitidos pelos usuários são confiáveis.
Uma das estratégias adotada pelos desenvolvedores para lidar com
esses problemas é a de pensar que o usuário irá abusar do sistema de alguma
maneira. É o que Van der Stock et al. (2005) definem como processo "Thinking
Evil™", colocar-se como atacante para pensar nos meios de proteção.
3.1.1 Vulnerabilidades da Web
7
De acordo com a classificação do The Open Web Application
Security Project (2010), as dez vulnerabilidades mais críticas da Web são:
1) Injeção de códigos: inserção de códigos arbitrários, como SQL injection, em
um sistema que pode permitir a um atacante realizar operações não
autorizadas.
2) Cross-site scripting (XSS): inserção de códigos arbitrários em pontos falhos
de uma aplicação que são executados quando os usuários a acessam. Estes
pensam que as operações realizadas pelos códigos arbitrários são confiáveis,
já que a aplicação que acessam é confiável.
3) Quebra de autenticação e gerenciamento de sessão: mau gerenciamento de
sistemas de login e senha.
4) Referência direta de objeto inseguro: acesso não autorizado de um objeto,
uma parte do programa, restrito através de outro desprotegido.
5) Cross-site request forgery (CSRF ou XSRF): similar ao XSS, porém neste
caso explora-se a confiabilidade do site no navegador e não no usuário.
6) Má configuração de segurança: falta de segurança no servidor, como falta de
atualização de softwares e má configuração dos privilégios de acesso.
7) Armazenado criptográfico inseguro: criptografia inadequada, backup de dados
junto com as chaves criptográficas ou falta de controle de acesso.
8) Falha na restrição de URL: falha em restringir o acesso a certas páginas pela
inserção direta da URL (Uniform Resource Locator, o mesmo que endereço)
daquela página.
9) Proteção insuficiente na camada de transporte: falta do uso do SSL, camada
de proteção criptográfica, em todas as operações com dados sigilosos.
10) Não validação de redirecionamentos: não verificação dos endereços ou má
aplicação de redirecionamentos para outros sites.
Das dez vulnerabilidades listadas: uma armazenado criptográfico
inseguro faz parte do gerenciamento de banco de dados, mas também é ligada ao
planejamento do software; outras duas, proteção insuficiente na camada de
transporte e má configuração de segurança, se referem mais à parte de
infraestrutura de redes; as sete demais têm ligação direta com o processo de
desenvolvimento do software. Isso demonstra a importância da adoção de práticas
de segurança durante o desenvolvimento para minimizar o risco de falhas.
8
3.1.2 Práticas de Segurança
As práticas a seguir são parte de um trabalho de iniciação científica;
portanto a lista não está completa. O foco no primeiro momento é no processamento
de formulários e sistemas de login, já que eles são os principais alvos de injeção de
códigos e XSS, os dois primeiros colocados da lista de vulnerabilidades.
3.1.3 Processamento de Formulários
Formulários são importantes componentes da maioria das
aplicações Web, pois permitem aos usuários inserirem dados ou parâmetros
necessários para o seu funcionamento, mas também são um ponto fraco em
potencial. Um atacante poderia tentar inserir códigos arbitrários ou causar problemas
de integridade se as entradas não forem validadas corretamente.
Validação lado cliente e lado servidor
A validação de formulários deve ser feita tanto do lado cliente quanto
do lado servidor. Isso é necessário, pois os controles de validação do lado cliente,
tipicamente em JavaScript, podem ser alterados ou removidos deixando o sistema
sem proteção. Por outro lado, usar somente controles do lado servidor, como em
ASP.Net ou PHP, pode não ser vantajoso, já que usaria recursos do servidor e
banda da rede, como mencionado por Niederauer (2004). Sendo assim, se todas as
validações fossem feitas no servidor, haveria um excesso de demanda de seus
recursos, comprometendo o desempenho.
O objetivo da dupla validação é que o lado cliente lide com a maior
parte das requisições, que vêm de usuários comuns que cometem erros banais, e
que o lado servidor lide com aqueles usuários mal intencionados, que são minoria.
Caixa de texto
Caixa de texto ou textbox é provavelmente o tipo de campo mais
problemático na validação de formulários, já que o usuário pode informar qualquer
coisa.
9
Definir o comprimento máximo do campo é importante para delimitar
o que pode ser inserido nele. O comprimento pode ser definido no próprio HTML
(HyperText Markup Language) pelo parâmetro maxlength. Porém, como se trata de
HTML, ele pode ser alterado, permitindo que se insiram mais caracteres que o
previsto. Isso pode gerar problemas, como o citado por Hope e Walther (2009), no
qual um valor muito grande, 1MB, é enviado causando lentidão. Sendo assim, é
necessário verificar o comprimento no lado servidor.
Outro problema refere-se a caracteres especiais que podem interferir
de alguma maneira no sistema, como HTML, SQL e JavaScript. Um atacante
poderia tentar injetar algum código malicioso para prejudicar o sistema e seus
usuários. O uso de codificadores e funções de escape, presentes nas linguagens
mais usadas, ajuda a filtrar as entradas. De maneira geral, deve-se evitar ao máximo
o uso de caracteres especiais.
Uma das soluções para verificar a coerência dos dados é a
expressão regular. De acordo com Negrino e Smith (2001), expressão regular é um
conjunto de símbolos especiais utilizados para se definir o padrão de uma
expressão. As linguagens e scripts mais usadas na Web, como ASP.net, PHP e
JavaScript, têm suporte a expressões regulares. Elas permitem comparar as
entradas de um usuário com um padrão pré- definido, permitindo saber se ele está
inserindo um valor coerente ao requisitado.
Campos de resposta fechada
Os campos de resposta fechada são aqueles em que o usuário só
pode escolher entre as opções pré-programadas. São eles: caixa de combinação
(combobox), caixa de seleção (checkbox) e botões de rádio.
Apesar de terem valores fechados, eles ainda assim precisam ser
verificados do lado servidor, já que seu HTML pode ser modificado.
Campos ocultos
Campos ocultos são aqueles que não são mostrados no formulário
para o usuário. Seu intuito é manter informações na máquina do usuário que serão
usadas posteriormente pelo aplicativo. Não se deve armazenar dados importantes
10
em campos ocultos, já que o HTML pode ser modificado. Dentre as alternativas, há
cookies e passagem de parâmetros pela URL.
Método GET
Pelo método GET, os dados dos formulários são passados como
parâmetros na URL. Van der Stock et al. (2005) afirmam que o processamento de
formulário por esse método não deve ser usado, já que ele aumenta as chances de
XSS. O método POST deve ser o padrão, GET deve ser usado apenas para
propósitos de navegação.
3.1.4 Sistemas de Login
Sistemas de login têm como objetivo verificar a identidade do
usuário através da autenticação por senha, permitindo que acesse dados
confidenciais a ele ou a um grupo restrito de pessoas. Boa parte das aplicações
Web mais complexas requerem este tipo de sistema: comércio eletrônico, fóruns, e-
mail, sistemas empresariais etc.
Senhas fortes
O nível de segurança das senhas está relacionado ao quão rápido
elas podem ser quebradas. Com relação a ataques brute force (tentativa e erro) e de
dicionário (o mesmo que brute force, porém com palavras pré-selecionadas) quanto
mais caracteres e variações de caracteres, mais difícil será quebrá-la. Então, pode-
se dizer que senhas fortes têm as seguintes características:
São longas, acima de 8 dígitos.
Possuem letras maiúsculas e minúsculas (sistema deve diferenciá-las),
números e outros caracteres.
Não são palavras, nomes ou datas comumente usadas.
Há um, porém: senhas desse tipo não costumam ser facilmente
memoriáveis. De acordo com Pinto e Stuttard (2008), um usuário típico não costuma
ter preocupação com a segurança de sua senha, o que o leva a colocar senhas
fracas e mais facilmente memoriáveis. Ainda segundo os autores, a maioria das
aplicações Web não tem nenhum controle que obrigue o usuário a definir uma senha
11
forte. O resultado é que tais senhas podem ser quebradas com relativa facilidade.
A aplicação deve exigir que o usuário insira senhas fortes no
momento do cadastro ou renovação de senha.
Expiração de senha
Mesmo senhas fortes podem ser quebradas depois de algum tempo.
Para se evitar esse problema, Bishop (2008) afirma que as senhas devem ter um
prazo de expiração ao final do qual o usuário precisa inserir uma nova senha. Essa
imposição certamente não é de agrado de muitos usuários, já que requerem que
memorizem uma nova senha. O autor ressalta ainda que de nada adianta o usuário
colocar uma senha já usada como nova, sendo necessário um mecanismo que
verifique isso.
Apesar de ser uma técnica que garante maior confiabilidade, a
aplicação da troca de senha deve levar em consideração as necessidades de
segurança que o negócio exige.
Limitação de tentativas
Ataques com testes de tentativa e erro utilizam softwares
automáticos. Limitar o número de tentativas pode ser uma solução, como ocorre
com senhas de bancos. Porém, ao contrário dos bancos, o usuário pode não ter
como ir fisicamente a um determinado lugar para desbloquear sua conta. Dentre as
alternativas, Bishop (2008) sugere um limite de tentativas por um determinado tempo
e Pinto e Stuttard (2008), o uso do CAPTCHA (Completely Automated Public Turing
test to tell Computers and Humans Apart), que permite distinguir uma pessoa de
uma máquina mostrando-lhe caracteres distorcidos e pedindo para que os digitem
em um formulário.
Armazenamento de usuário e senha
Apesar de que teoricamente um banco de dados bem configurado
não terá seus dados expostos, o armazenamento de senhas deve ser criptográfico,
seguindo-se o princípio de defesa em profundidade.
12
Um dos meios mais conhecidos de criptografia de senhas é o hash,
um algoritmo que calcula um número, geralmente hexadecimal, de tamanho fixo
único para os caracteres inseridos. Este número é armazenado no banco e usado
para comparar com a senha do usuário. Ele não pode ser desfeito, a única maneira
de se saber o conteúdo original é com um ataque brute force.
Função esqueci a senha
Inconveniente tanto para a aplicação quanto para o usuário, quando
este esquece a senha é necessário haver algum procedimento que permita a ele
reaver o acesso ao sistema. Algumas técnicas muito conhecidas de recuperação de
senha incluem:
Entrar em contato com o administrador: este método requer que o usuário fale
pessoalmente com o administrador, como ocorre com os bancos. Apesar de
ser seguro, já que se sabe que é realmente o usuário, ele não é viável em
boa parte das aplicações seja pelo número de usuários ou pela
impossibilidade da presença física.
Pergunta secreta: durante o cadastro é obrigatório definir uma pergunta e sua
resposta secreta que serão utilizados como na recuperação. O problema com
essa abordagem, segundo Pinto e Stuttard (2008), é que a maioria dos
usuários tendem a escolher perguntas e respostas óbvias.
Lembrete de senha: durante o cadastro pede-se que se insira um lembrete de
senha, uma expressão que o faça lembrar da senha. Este método possui o
mesmo problema da pergunta secreta, pois o usuário tende a colocar
informações óbvias.
Envio de e-mail: neste caso é enviado um e-mail ao usuário com sua senha,
uma nova senha ou um link para recadastrar a senha. Geralmente o que
ocorre é o envio dos dados para o e-mail previamente cadastrado, a senha do
e-mail serve como autenticação. Este método é relativamente simples e
confiável, mas o nível de segurança depende de como o usuário trata de seu
e-mail.
Vale lembrar que também pode haver combinações dos métodos
citados, como definir uma pergunta secreta para a qual se a resposta for correta
enviar um e-mail contendo um link temporário que permite redefinir a senha.
13
3.2 DIAGRAMA DE ATIVIDADE (UML)
A linguagem UML (Unified Modeling Language) – Linguagem de
Modelagem Unificada é uma linguagem de modelagem (visual), não uma linguagem
de programação e sim uma linguagem de modelagem não proprietária na qual
permite a utilização de diagramas padronizados para especificação e visualização
de um sistema.
Surgiu da união de três metodologias de modelagem: Método de
Booch, de Grady Booch; Método OMT (Object Modeling Technique) de Ivar
Jacobson; Método OOSE (Object Oriented Software Engineering) de James
Rumbaugh. Os três amigos.
A primeira versão foi lançada em 1996 Em 1997 a UML foi adotada
pela a OMG (Object Management Group – Grupo de gerenciamento de Objetos)
como linguagem padrão de modelagem.
O que é modelagem? Atividade de construir modelos que expliquem
as características ou comportamentos de um sistema. A UML pode ser usada com
todos os processos durante o ciclo de desenvolvimento do projeto Análise de
requisitos; Análise de sistema; Design; Programação e Testes.
Desenvolver o modelo de uma aplicação antes de construí-la, é tão
essencial quanto ter uma planta para a construção de uma casa. Analisar o projeto
sobre vários aspectos assim diminuindo a possibilidade de erros. Ter um rigoroso
padrão de linguagem de modelagem é um fator essencial para o sucesso de um
projeto.
Por que usar UML? Bons modelos são essenciais para a
comunicação entre os times de projetos e para assegurar a beleza arquitetural.
Facilita a programação; sistemas são dinâmicos; todo o time entende a modelagem,
facilitando assim a manutenção.
Diagrama de Atividades preocupa-se em descrever os passos a
serem percorridos para a conclusão de uma atividade específica. Concentra-se na
representação do fluxo de controle de uma atividade.
Uma atividade é uma execução não atômica em andamento em
uma máquina de estados e acabam resultando em alguma ação, formada pelas
computações atômicas executáveis que resultam em uma mudança de estado do
sistema ou o retorno de um valor.
14
Características:
Um diagrama de atividade observa as operações passadas entre os objetos;
Mostra o fluxo de uma atividade para outra;
Uma atividade é uma execução em andamento;
As atividades resultam em uma ação;
As ações abrangem a chamada a outras operações, enviando um sinal,
criando ou destruindo um objeto.
3.2.1 Diagramas de Atividades da TELECINE MOZER
Diagrama Login
15
Diagrama Cadastro de Pessoas
16
Diagrama Cadastro de DVD
17
Diagrama Alterar Dados do Cliente
18
Diagrama Consultar Dados
19
Diagrama Remover Itens
20
Diagrama Gerar Relatório
21
Diagrama Log de Eventos
22
Diagrama Locar DVD
23
Diagrama Devolver DVD
Diagrama Logoff
24
3.3 NORMALIZAÇÃO DO DIAGRAMA ENTIDADE RELACIONAMENTO (MRN)
3.2.2 Modelo entidade relacionamento (MER)
Em engenharia de software, um modelo entidade relacionamento
(modelo ER) é um modelo de dados para descrever os dados ou aspectos de
informação de um domínio de negócio ou seus requerimentos de processo, de uma
maneira abstrata que em última análise se presta a ser implementada em um banco
de dados, como um banco de dados relacional. Os principais componentes dos
modelos ER são entidades (coisas) e os relacionamentos que podem existir entre
eles, e bancos de dados.
Um modelo entidade relacionamento é uma maneira sistemática de
descrever e definir um processo de negócio. O processo é modelado como
componentes (entidades) que são ligadas umas às outras por relacionamentos que
expressam as dependências e exigências entre elas, como: um edifício pode ser
dividido em zero ou mais apartamentos, mas um apartamento pode estar localizado
em apenas um edifício. Entidades podem ter várias propriedades (atributos) que os
caracterizam. Diagramas criados para representar graficamente essas entidades,
atributos e relacionamentos são chamados de diagramas entidade relacionamento.
Um modelo ER é normalmente implementado como um banco de
dados. Nos casos de um banco de dados relacional, que armazena dados em
tabelas, as próprias tabelas representam as entidades. Alguns campos de dados
nestas tabelas apontam para índices em outras tabelas. Tais ponteiros representam
relacionamentos.
A utilização do modelo Entidade Relacionamento é de suma
importância para representação gráfica daquilo que queremos representar facilitando
a compreensão daqueles envolvidos na construção do projeto.
3.2.3 Técnica de modelagem entidade e relacionamento
Entidade: é aquele objeto existente no mundo real, com uma identificação
distinta e significado próprio. São as coisas que existem no negócio, ou ainda,
que descrevem o negócio em si. Se algo existe e proporciona algum interesse
em manter dados sobre ele, isto caracteriza como uma Entidade do negócio.
Desta forma, podemos dizer que uma entidade será uma tabela em
25
nosso banco de dados. Na verdade quando identificamos todas as entidades,
estaremos definindo quais serão as tabelas que teremos que criar em nosso banco
de dados.
José Fulano de Tal, CPF nº 333.333.333-33, é uma entidade, uma
vez que só pode existir uma única pessoa com o mesmo nome e CPF.
Em um banco de dados de uma empresa, por exemplo, são
entidades: Cliente, Funcionário, Departamento, fornecedor, etc. Cada entidade
representa objetos com as mesmas características. Um banco de dados, portanto,
compreende uma coleção de conjuntos de entidades do mesmo tipo.
Relacionamentos: Geralmente são os verbos, é um conjunto de associações
entre as entidades, acontecimento que liga duas entidades existentes no
mundo real. O relacionamento pode ser binário ou ternário e é representado
através de um losango internamente nomeado e ligado a entidades através
de linhas, conforme abaixo:
Atributos: São propriedades (características) que identificam as entidades.
Uma entidade é representada por um conjunto de atributos. Nome, endereço,
telefone e cidade, por exemplo, são atributos da entidade Clientes. Enquanto
que salário, cargo e departamento são atributos da entidade funcionários.
ALUGUEL CLIENTE ALUGA
26
Classificação dos Atributos
Os atributos podem ser simples, composto, multivalorado ou
determinante.
Atributo Simples: Não possui qualquer característica especial: A maioria dos
atributos será simples. Quando um atributo não é composto, recebe um valor
único como nome, por exemplo, e não é um atributo chave, então ele será
atributo simples.
Atributo Composto: O seu conteúdo é formado por vários itens menores. Ex.
Endereço. Seu conteúdo poderá ser dividido em vários outros atributos,
como: Rua, Número, Complemento, Bairro, CEP e Cidade.
Atributo Multivalorado: O seu conteúdo é formado por mais de um valor. Ex.:
Telefone. Uma pessoa poderá ter mais de um número de telefone. É indicado
colocando-se um asterisco precedendo o nome do atributo.
Atributo Determinante: Identifica de forma única uma entidade, ou seja, não
pode haver dados repetidos. É indicado sublinhando-se o nome do atributo.
Exemplo: CNPJ, CPF, Código do fornecedor, Número da matrícula, etc. Os
atributos determinantes serão as chaves primárias no banco de dados e seu
uso tem implicações na normalização de dados.
3.2.4 Diagrama Entidade-Relacionamento (DER)
O Diagrama Entidade-Relacionamento descreve toda estrutura lógica
do banco de dados. É possível construí-lo a partir de um MER, identificando assim a
partir de um conceito do mundo real como os dados serão armazenados de fato.
O DER tem como ênfase os dados e os relacionamentos. Sua
representação utiliza os símbolos:
Retângulos - representam as entidades;
Elipses - representam os atributos;
Losangos - representam os relacionamentos entre as entidades;
Linhas - unem os atributos aos conjuntos de entidades e os conjuntos de
27
entidades aos conjuntos de relacionamentos;
Elipses duplas - atributos multivalorados.
Na
construção de um projeto de banco de dados é necessário saber quais são os objetos e
os relacionamentos para elaborar o DER, ou seja, descobrir quais os atributos que
compõem as tabelas (objetos).
Seguindo nosso exemplo um cliente, seja ele pessoa física ou
jurídica, realiza locações de DVD, cada locação tem sua identificação e um atributo
data, representando a data de retirada, portanto a representação gráfica ficaria
dessa forma:
28
Com já havia sido falado, um losango faz a ligação entre as
entidades relacionadas, porém a um detalhe que ainda não foi explicado, a cor de
cada uma das metades desse losango, essa divisão de cores representa o tipo de
relacionamento entre as entidades.
No caso da locadora, cada cliente pode realizar vários alugueis,
porém cada aluguel é feito por apenas um cliente (repare o uso da palavra “cada”
que auxilia bastante na hora de classificar os relacionamento). Essa representação e
feita pelo DB Designer, colorindo a metade chamada de ‘muitos’ de preto, ou seja,
como cada cliente pode realizar muitos alugueis, o lado dos alugueis fica com a
metade preta do losango, enquanto, como cada EMPRESTIMO é realizado por
apenas um cliente, por isso a metade branca do losango aponta para a entidade
cliente.
No entanto essa representação é um pouco diferente da
representação padrão onde teríamos algo assim:
29
Nessa imagem foram omitidos os atributos de cada entidade. Como
podemos ver ao invés de colorir os losangos indicando o tipo de relacionamento, em
cada entidade é colocado um conjunto composto por dois caracteres entre vírgulas,
o primeiro caracter antes da virgula mostra o mínimo do relacionamento, e o caracter
após a virgula o máximo do relacionamento.
No exemplo, cada cliente pode fazer no mínimo 1 e no máximo N
(muitos) alugueis (1,N) e cada aluguel é realizado por no mínimo 1 e no máximo 1
cliente (1,1). Essa metodologia mostra tanto o mínimo quanto o máximo de um
relacionamento, enquanto o DB Designer só demonstra o máximo.
Um cliente pode ter um cadastro na locadora e nunca ter alugado
nenhum filme, realmente isso pode acontecer, o que mudaria o mínimo para 0 ao
invés de 1, mas isso dependeria do modo como a locadora trabalha o cadastro de
clientes, dado esse que deve ser levantado junto ao cliente em cada caso.
Apesar de a metodologia padrão usar o mínimo e o máximo, o mais
importante num relacionamento é o seu máximo, que vai definir em qual das duas
entidades será colocada à chave estrangeira, que faz a ligação entre as duas
entidades no SGBD.
Tipos de Relacionamentos:
Relacionamento 1-1: Esse relacionamento ocorre quando ambas as entidades se
relacionam com máximo 1 para com a outra, não é um relacionamento muito usado
já que na maioria dos casos quando uma entidade se relaciona dessa forma com a
outra elas podem ser fundidas em apenas uma entidade, porem em alguns casos
pode-se guardar informações opcionais sobre uma entidade em outra entidade,
evitando assim que uma tabela de banco de dados tenha muitos atributos com valor
nulo, caso todos esses valores opcionais fossem nulos não haveria nem a
necessidade da criação de uma nova linha na entidade que porta esses dados
opcionais.
Relacionamento 1-N: É o tipo de relacionamento mais usado em banco de dados
relacionais ocorrendo com o relacionamento máximo de uma tabela para outra é 1 e
na ordem inversa é N, sendo esse o que foi usado no exemplo anterior e explicado
através dele.
30
Relacionamento N-N: Ocorre quando ambas as entidades se relacionam com no
máximo N para com a outra, nesse caso ocorre a criação de uma entidade fraca
entre essas entidades para guardar o relacionamento entre essas duas através de
suas chaves estrangeiras, no exemplo da locadora esse relacionamento pode ser
encontrado no relacionamento entre alugueis e filmes representado abaixo:
31
32
Como podemos perceber, o DB Designer transforma
automaticamente um Relacionamento N-N em dois relacionamento 1-N, a entidade
fraca possui somente os ID`s das duas entidades com as quais se relaciona, porém
pode ter outros atributos também.
3.2.5 Normalização
A utilização do MER nos proporciona a criação de um DER
(Diagrama de Entidades e Relacionamento). Os DER fazem uma representação de
parte de um mundo real onde são feitas representações estruturadas e conceituais
do que o ser humano pode fazer nessa parcela do mundo real.
A princípio, Peter Chen propôs como notação desses diagramas os
retângulos como sendo as entidades, os losangos como sendo os relacionamentos
entre as entidades, os círculos como sendo os atributos das entidades e linhas de
conexão para mostrar a cardinalidade entre uma entidade e outra.
Ao aplicar esse sistema de Relacionamento, existe uma série de
passos para fazer com que os dados tornem-se menos redundantes e menos
inconsistentes. Tais passos são chamados de Normalização de dados. A primeira
forma normal foi definida por Edgar F. Codd em 1970. Essa norma tinha como
definição permitir que os dados fossem questionados e manipulados usando uma
"sub-linguagem de dados universal" atrelada à lógica de primeira ordem. Nem
sempre essa normalização é eficiente, dependendo da separação entre o projeto
lógico da base de dados e a implementação física do banco de dados.
Para normalização é feito um trabalho sobre as restrições que
indicam relações individuais, isto é, as restrições relacionais. O propósito destas
restrições é descrever o universo relacional, ou seja, o conjunto de todas as relações
que são permitidas para serem associadas com certos nomes de relação. Dentre
essas restrições relacionais, a mais importante é a Chave, a qual vai relacionar um
registro com um ou mais valores de índice.
Existem hoje diversas normas formais, cada uma gerando
aprimoramentos em relação à norma anterior. Abaixo as normas e definições:
Primeira Norma Formal: Uma tabela está na 1FN, se e somente se, não
possuir atributos multivalor.
Segunda Norma Formal: Uma relação está na 2FN se, e somente se, estiver
33
na 1FN e cada atributo não-chave for dependente da chave primária inteira,
isto é, cada atributo não-chave não poderá ser dependente de apenas parte
da chave.
Terceira Norma Formal: Uma relação R está na 3FN, se estiver na 2FN e
cada atributo não-chave de R não possuir dependência transitiva, para cada
chave candidata de R.
Quarta Norma Formal: Uma tabela está na 4FN, se e somente se, estiver na
3FN e não existirem dependências multivaloradas.
34
4 CONCLUSÃO
Ao final do trabalho, percebi que o constante aumento no número
de incidentes de segurança e a alavancagem dos sistemas Web tornam
importante à manutenção de sua seguridade. Portanto é necessário dar uma
maior atenção ao aspecto de segurança nesta fase com a aplicação de práticas
que reduzam as possibilidades de falhas e prejuízos para a empresa, os clientes e
o próprio desenvolvedor.
Em estudo sobre Diagrama de atividade me fez perceber quando
devemos implementar o diagrama, e os benefícios de sua utilização dentro do
projeto de desenvolvimento. Referente à normalização dentro de um projeto é
fundamental para um correto funcionamento da aplicação e principalmente do banco
de dados. Pesquisando um pouco mais sobre a Normalização no Diagrama Entidade
Relacionamento (DER) só veio a enriquecer ainda mais o conhecimento adquirido
durante o semestre.
O conteúdo deste texto somente foi possível após um grande
trabalho de pesquisa que exigiu uma análise e uma reflexão sobre cada disciplina. O
grande volume de informações disponíveis na rede auxiliou e muito na busca do
conhecimento.
Portanto, o objetivo do trabalho foi alcançado, enriqueci meus
conhecimentos através da prática nas atividades propostas onde foi possível
assimilar os conceitos e técnicas apresentados pelos professores desse 4° semestre
– Desenvolvimento de Sistemas II.
35
REFERÊNCIAS
ANHANGUERA NITERÓI, Banco de Dados I. Disponível em: https://sites.google.com/site/uniplibancodedados1/aulas/aula-4---modelo-entidade-e-relacionamentos. Acesso em: 25 de outubro de 2014.
DEVMEDIA.COM.BR, Modelo Entidade Relacionamento (MER) e Diagrama Entidade-Relacionamento (DER). Disponível em: http://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-entidade-relacionamento-der/14332. Acesso em: 19 de outubro de 2014.
SITEBLINDADO.COM, Segurança Para aplicações Web. Disponível em: http://www.siteblindado.com/pt/pags/view/files/WhitePaper+QualysGuard+Vulnerability+Web+Applications.pdf. Acesso em: 26 de outubro de 2014.
OWASP.ORG, As 10 vulnerabilidades de segurança mais críticas em aplicações WEB. Disponível em: https://www.owasp.org/images/4/42/OWASP_TOP_10_2007_PT-BR.pdf. Acesso em: 30 de outubro de 2014.
PERINI, Luis Cláudio. Engenharia de software. São Paulo. Editora Pearson, 2009.
WIKIPEDIA, Diagrama de atividade. Disponível em: http://pt.wikipedia.org/wiki/Diagrama_de_atividade. Acesso em: 26 de outubro de 2014.
WIKIPEDIA, Modelo entidade relacionamento. Disponível em: http://pt.wikipedia.org/wiki/Modelo_entidade_relacionamento. Acesso em: 24 de outubro de 2014.