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.