SISTEMA DE ENSINO PRESENCIAL CONECTADO

ANLISE E DESENVOLVIMENTO DE SISTEMAS

ANDRESSA LIDA CHAVES LUZ

DESENVOLVIMENTO DE SISTEMAS II:

Anlise Orientada a Objetos II; Banco de Dados II; Programao
Orientada a Objetos e Programao para Web I.

Alta Floresta
23/10/2014

ANDRESSA LIDA CHAVES LUZ

DESENVOLVIMENTO DE SISTEMAS II:

Anlise Orientada a Objetos II; Banco de Dados II; Programao
Orientada a Objetos e Programao para Web I.

Trabalho
apresentado
ao
Curso
Anlise
e
Desenvolvimento de Sistemas da UNOPAR Universidade Norte do Paran, para as disciplinas:
Banco de Dados II; Anlise Orientada a Objetos II;
Programao Orientada a Objetos e Programao para
Web I.
Professores: Roberto Y. Nishimura, Aderson Emdio M.
Gonalves, Marcio Roberto Chiaveli e Veronice de
Freitas.

SUMRIO

Alta Floresta
23/10/2014

1 INTRODUO
2 OBJETIVO
3 DESENVOLVIMENTO5
3.1 SEGURANA DA INFORMAO5
3.1.1 Vulnerabilidades da Web.
3.1.2 Prticas de Segurana
3.1.3 Processamento de Formulrios.
3.1.4 Sistemas de Login .
3.2 DIAGRAMA DE ATIVIDADE (UML).
3.2.1 Diagramas de Atividades da TELECINE MOZER.
3.3 NORMALIZAO DO DIAGRAMA ENTIDADE RELACIONAMENTO (MRN).
3.3.1 Modelo entidade relacionamento (MER).
3.3.2 Tcnica de modelagem entidade e relacionamento
3.3.3 Diagrama Entidade-Relacionamento (DER).
3.3.4 Normalizao .
4 CONCLUSO
REFERNCIAS

3
1

INTRODUO
Este trabalho ir expandir contedos abordados durante o 4

Semestre do Curso Superior de Tecnologia em Anlise e Desenvolvimento de

Sistema, assim expondo temas para melhor conceituar o aprendizado.
Tendo como pesquisa o desenvolvimento da aplicao web de
locao de filmes para a empresa TELECINE MOZER, a qual pertence ao grupo
Todos, sendo pioneira em atendimentos e locao de filmes via web.
Ser abordado a segurana no desenvolvimento de aplicaes
WEB, alm de conceitos bsicos de um Diagrama de Atividade e suas
caractersticas; e a Normalizao de dados no Diagrama Entidade Relacionamento.
Portanto dentro do contexto proposto pelos professores, buscarei
encontrar solues para os desafios apresentados, atravs de pesquisas pela
internet obtendo um melhoramento no sistema de locao 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 caractersticas

abordadas dos diferentes temas exposto neste trabalho.
Propor melhoramentos que se adquam dentro do contexto
TELECINE MOZER. Desenvolvendo um diagrama de atividades para o processo
de locao; e criao do diagrama de entidade e relacionamento para a mesma,
expondo a importncia da segurana para o desenvolvimento de sistemas WEB.
Cujo objetivo maior de fornecer um atendimento diferenciado aos
nossos clientes, visando uma maior comodidade, segurana e inovao tecnolgica.

5
3

DESENVOLVIMENTO
A escalabilidade, portabilidade e fcil acesso providos pela

plataforma Web tm popularizado seu uso no desenvolvimento de diversas

aplicaes. Porm, o crescente nmero de incidentes de segurana levanta
preocupaes quanto sua seguridade. Uma parte destes incidentes decorrem da
falta de considerao de segurana durante o processo de desenvolvimento. Este
trabalho tem como objetivo propor prticas de segurana a serem aplicadas durante
o processo de desenvolvimento de software Web que minimizem os riscos,
aumentando a qualidade e confiabilidade do produto final. Nele sero apresentados:
conceitos de segurana da informao, as vulnerabilidades mais comuns existentes
em software Web e algumas prticas que devem ser aplicadas durante o
desenvolvimento.
Nos ltimos anos, o desenvolvimento de aplicaes voltadas Web
vem sendo expandido por apresentar vantagens sobre software instalado
localmente, tais como: no necessidade de instalao local, atualizao rpida, fcil
escalabilidade e acesso de qualquer local com conexo Internet. Porm, o
aumento no nmero de incidentes de segurana na Web gera preocupao quanto
confiabilidade desses sistemas. As estatsticas do Centro de Estudos, Reposta e
Tratamento de Incidentes de Segurana no Brasil mostram que o nmero de
incidentes notificados mais que dobraram de 2005 (68.000) a 2010 (142.844).
Os investimentos em infraestrutura na rea de segurana, com o uso
de firewalls e antivrus, por exemplo, fornecem alguma proteo s redes e aos
servidores, embora sejam insuficientes frente s necessidades de segurana no
nvel da aplicao. Para suprir essa lacuna existem prticas 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 grfico, como relatado por Scott e Sharp (2002).
3.1. SEGURANA DA INFORMAO
A segurana de sistemas cada vez mais importante para empresas
e indivduos, especialmente com o constante aumento do nmero de servios
prestados via Internet e de incidentes de segurana, segundo Sommerville (2007).

6
Para Fiorio et al. (2007), a segurana em sistemas computacionais consiste em
empregar conceitos, metodologias e tcnicas que protejam o sistema de ataques,
sobretudo externos, que venham a gerar prejuzos tanto de ordem financeira quanto
social.
De acordo com Bishop (2008), a segurana da informao
composta por trs pilares, que so:

Confidencialidade: manter informaes ou recursos em segredo. Exemplo:

o uso de nome de usurio e senha que permite que somente um usurio

acesse o e-mail.
Integridade: a confiabilidade na origem da informao. Exemplo: um usurio
recebe um e-mail de seu amigo que foi alterado por um interceptador,

perdendo a integridade.
Disponibilidade: a garantia de que as informaes estaro disponveis aos
usurios autorizados quando necessrio. Exemplo: a sobrecarga nos
servidores da Receita Federal compromete a disponibilidade do sistema de
envio de declaraes de impostos.
Em aplicaes Web, a manuteno dos trs pilares pode ser mais

difcil do que naquelas rodadas localmente. Isso se deve ao fato de estarem

disponveis 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 segurana das
aplicaes Web o fato de que os usurios podem fazer entradas arbitrrias, ou
seja, podem transmitir tipos de dados no previstos no software, como parmetros,
comandos e cookies, que podem comprometer a aplicao e a seguridade de seus
dados. Isso reforado por Scott e Sharp (2002), que afirmam que a maioria dos
problemas de segurana no nvel de aplicao so causados pelo fato de que o
aplicativo assume que os dados transmitidos pelos usurios so confiveis.
Uma das estratgias adotada pelos desenvolvedores para lidar com
esses problemas a de pensar que o usurio 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 proteo.
3.1.1 Vulnerabilidades da Web

7
De acordo com a classificao do The Open Web Application
Security Project (2010), as dez vulnerabilidades mais crticas da Web so:
1) Injeo de cdigos: insero de cdigos arbitrrios, como SQL injection, em
um sistema que pode permitir a um atacante realizar operaes no
autorizadas.
2) Cross-site scripting (XSS): insero de cdigos arbitrrios em pontos falhos
de uma aplicao que so executados quando os usurios a acessam. Estes
pensam que as operaes realizadas pelos cdigos arbitrrios so confiveis,
j que a aplicao que acessam confivel.
3) Quebra de autenticao e gerenciamento de sesso: mau gerenciamento de
sistemas de login e senha.
4) Referncia direta de objeto inseguro: acesso no autorizado de um objeto,
uma parte do programa, restrito atravs de outro desprotegido.
5) Cross-site request forgery (CSRF ou XSRF): similar ao XSS, porm neste
caso explora-se a confiabilidade do site no navegador e no no usurio.
6) M configurao de segurana: falta de segurana no servidor, como falta de
atualizao de softwares e m configurao dos privilgios de acesso.
7) Armazenado criptogrfico inseguro: criptografia inadequada, backup de dados
junto com as chaves criptogrficas ou falta de controle de acesso.
8) Falha na restrio de URL: falha em restringir o acesso a certas pginas pela
insero direta da URL (Uniform Resource Locator, o mesmo que endereo)
daquela pgina.
9) Proteo insuficiente na camada de transporte: falta do uso do SSL, camada
de proteo criptogrfica, em todas as operaes com dados sigilosos.
10) No validao de redirecionamentos: no verificao dos endereos ou m
aplicao de redirecionamentos para outros sites.
Das dez vulnerabilidades listadas: uma armazenado criptogrfico
inseguro faz parte do gerenciamento de banco de dados, mas tambm ligada ao
planejamento do software; outras duas, proteo insuficiente na camada de
transporte e m configurao de segurana, se referem mais parte de
infraestrutura de redes; as sete demais tm ligao direta com o processo de
desenvolvimento do software. Isso demonstra a importncia da adoo de prticas
de segurana durante o desenvolvimento para minimizar o risco de falhas.
3.1.2 Prticas de Segurana
As prticas a seguir so parte de um trabalho de iniciao cientfica;
portanto a lista no est completa. O foco no primeiro momento no processamento

8
de formulrios e sistemas de login, j que eles so os principais alvos de injeo de
cdigos e XSS, os dois primeiros colocados da lista de vulnerabilidades.
3.1.3 Processamento de Formulrios
Formulrios

so

importantes

componentes

da

maioria

das

aplicaes Web, pois permitem aos usurios inserirem dados ou parmetros

necessrios para o seu funcionamento, mas tambm so um ponto fraco em
potencial. Um atacante poderia tentar inserir cdigos arbitrrios ou causar problemas
de integridade se as entradas no forem validadas corretamente.
Validao lado cliente e lado servidor
A validao de formulrios deve ser feita tanto do lado cliente quanto
do lado servidor. Isso necessrio, pois os controles de validao do lado cliente,
tipicamente em JavaScript, podem ser alterados ou removidos deixando o sistema
sem proteo. Por outro lado, usar somente controles do lado servidor, como em
ASP.Net ou PHP, pode no ser vantajoso, j que usaria recursos do servidor e banda
da rede, como mencionado por Niederauer (2004). Sendo assim, se todas as
validaes fossem feitas no servidor, haveria um excesso de demanda de seus
recursos, comprometendo o desempenho.
O objetivo da dupla validao que o lado cliente lide com a maior
parte das requisies, que vm de usurios comuns que cometem erros banais, e
que o lado servidor lide com aqueles usurios mal intencionados, que so minoria.
Caixa de texto
Caixa de texto ou textbox provavelmente o tipo de campo mais
problemtico na validao de formulrios, j que o usurio pode informar qualquer
coisa.
Definir o comprimento mximo do campo importante para delimitar
o que pode ser inserido nele. O comprimento pode ser definido no prprio HTML
(HyperText Markup Language) pelo parmetro maxlength. Porm, 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

9
qual um valor muito grande, 1MB, enviado causando lentido. Sendo assim,
necessrio 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 cdigo malicioso para prejudicar o sistema e seus
usurios. O uso de codificadores e funes de escape, presentes nas linguagens
mais usadas, ajuda a filtrar as entradas. De maneira geral, deve-se evitar ao mximo
o uso de caracteres especiais.
Uma das solues para verificar a coerncia dos dados a
expresso regular. De acordo com Negrino e Smith (2001), expresso regular um
conjunto de smbolos especiais utilizados para se definir o padro de uma
expresso. As linguagens e scripts mais usadas na Web, como ASP.net, PHP e
JavaScript, tm suporte a expresses regulares. Elas permitem comparar as
entradas de um usurio com um padro pr- definido, permitindo saber se ele est
inserindo um valor coerente ao requisitado.
Campos de resposta fechada
Os campos de resposta fechada so aqueles em que o usurio s
pode escolher entre as opes pr-programadas. So eles: caixa de combinao
(combobox), caixa de seleo (checkbox) e botes de rdio.
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 so aqueles que no so mostrados no formulrio
para o usurio. Seu intuito manter informaes na mquina do usurio que sero
usadas posteriormente pelo aplicativo. No se deve armazenar dados importantes
em campos ocultos, j que o HTML pode ser modificado. Dentre as alternativas, h
cookies e passagem de parmetros pela URL.
Mtodo GET
Pelo mtodo GET, os dados dos formulrios so passados como

10
parmetros na URL. Van der Stock et al. (2005) afirmam que o processamento de
formulrio por esse mtodo no deve ser usado, j que ele aumenta as chances de
XSS. O mtodo POST deve ser o padro, GET deve ser usado apenas para
propsitos de navegao.
3.1.4 Sistemas de Login
Sistemas de login tm como objetivo verificar a identidade do
usurio atravs da autenticao por senha, permitindo que acesse dados
confidenciais a ele ou a um grupo restrito de pessoas. Boa parte das aplicaes Web
mais complexas requerem este tipo de sistema: comrcio eletrnico, fruns, e-mail,
sistemas empresariais etc.
Senhas fortes
O nvel de segurana das senhas est relacionado ao quo rpido
elas podem ser quebradas. Com relao a ataques brute force (tentativa e erro) e de
dicionrio (o mesmo que brute force, porm com palavras pr-selecionadas) quanto
mais caracteres e variaes de caracteres, mais difcil ser quebr-la. Ento, podese dizer que senhas fortes tm as seguintes caractersticas:

So longas, acima de 8 dgitos.

Possuem letras maisculas e minsculas (sistema deve diferenci-las),

nmeros e outros caracteres.

No so palavras, nomes ou datas comumente usadas.
H um, porm: senhas desse tipo no costumam ser facilmente

memoriveis. De acordo com Pinto e Stuttard (2008), um usurio tpico no costuma

ter preocupao com a segurana de sua senha, o que o leva a colocar senhas
fracas e mais facilmente memoriveis. Ainda segundo os autores, a maioria das
aplicaes Web no tem nenhum controle que obrigue o usurio a definir uma senha
forte. O resultado que tais senhas podem ser quebradas com relativa facilidade.
A aplicao deve exigir que o usurio insira senhas fortes no
momento do cadastro ou renovao de senha.
Expirao de senha

11
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 expirao ao final do qual o usurio precisa inserir uma nova senha. Essa
imposio certamente no de agrado de muitos usurios, j que requerem que
memorizem uma nova senha. O autor ressalta ainda que de nada adianta o usurio
colocar uma senha j usada como nova, sendo necessrio um mecanismo que
verifique isso.
Apesar de ser uma tcnica que garante maior confiabilidade, a
aplicao da troca de senha deve levar em considerao as necessidades de
segurana que o negcio exige.
Limitao de tentativas
Ataques com testes de tentativa e erro utilizam softwares
automticos. Limitar o nmero de tentativas pode ser uma soluo, como ocorre
com senhas de bancos. Porm, ao contrrio dos bancos, o usurio pode no 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 mquina mostrando-lhe caracteres distorcidos e pedindo para que os digitem
em um formulrio.
Armazenamento de usurio e senha
Apesar de que teoricamente um banco de dados bem configurado
no ter seus dados expostos, o armazenamento de senhas deve ser criptogrfico,
seguindo-se o princpio de defesa em profundidade.
Um dos meios mais conhecidos de criptografia de senhas o hash,
um algoritmo que calcula um nmero, geralmente hexadecimal, de tamanho fixo
nico para os caracteres inseridos. Este nmero armazenado no banco e usado
para comparar com a senha do usurio. Ele no pode ser desfeito, a nica maneira
de se saber o contedo original com um ataque brute force.

12
Funo esqueci a senha
Inconveniente tanto para a aplicao quanto para o usurio, quando
este esquece a senha necessrio haver algum procedimento que permita a ele
reaver o acesso ao sistema. Algumas tcnicas muito conhecidas de recuperao de
senha incluem:

Entrar em contato com o administrador: este mtodo requer que o usurio fale
pessoalmente com o administrador, como ocorre com os bancos. Apesar de
ser seguro, j que se sabe que realmente o usurio, ele no vivel em
boa parte das aplicaes seja pelo nmero de usurios ou pela

impossibilidade da presena fsica.

Pergunta secreta: durante o cadastro obrigatrio definir uma pergunta e sua
resposta secreta que sero utilizados como na recuperao. O problema com
essa abordagem, segundo Pinto e Stuttard (2008), que a maioria dos

usurios tendem a escolher perguntas e respostas bvias.

Lembrete de senha: durante o cadastro pede-se que se insira um lembrete de
senha, uma expresso que o faa lembrar da senha. Este mtodo possui o
mesmo problema da pergunta secreta, pois o usurio tende a colocar

informaes bvias.
Envio de e-mail: neste caso enviado um e-mail ao usurio 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 autenticao. Este mtodo relativamente simples e
confivel, mas o nvel de segurana depende de como o usurio trata de seu
e-mail.
Vale lembrar que tambm pode haver combinaes dos mtodos

citados, como definir uma pergunta secreta para a qual se a resposta for correta
enviar um e-mail contendo um link temporrio que permite redefinir a senha.
3.2

DIAGRAMA DE ATIVIDADE (UML)

A linguagem UML (Unified Modeling Language) Linguagem de

Modelagem Unificada uma linguagem de modelagem (visual), no uma linguagem

de programao e sim uma linguagem de modelagem no proprietria na qual
permite a utilizao de diagramas padronizados para especificao e visualizao
de um sistema.

13
Surgiu da unio de trs metodologias de modelagem: Mtodo de
Booch, de Grady Booch; Mtodo OMT (Object Modeling Technique) de Ivar
Jacobson; Mtodo OOSE (Object Oriented Software Engineering) de James
Rumbaugh. Os trs amigos.
A primeira verso foi lanada em 1996 Em 1997 a UML foi adotada
pela a OMG (Object Management Group Grupo de gerenciamento de Objetos)
como linguagem padro de modelagem.
O que modelagem? Atividade de construir modelos que expliquem
as caractersticas ou comportamentos de um sistema. A UML pode ser usada com
todos os processos durante o ciclo de desenvolvimento do projeto Anlise de
requisitos; Anlise de sistema; Design; Programao e Testes.
Desenvolver o modelo de uma aplicao antes de constru-la, to
essencial quanto ter uma planta para a construo de uma casa. Analisar o projeto
sobre vrios aspectos assim diminuindo a possibilidade de erros. Ter um rigoroso
padro de linguagem de modelagem um fator essencial para o sucesso de um
projeto.
Por que usar UML? Bons modelos so essenciais para a
comunicao entre os times de projetos e para assegurar a beleza arquitetural.
Facilita a programao; sistemas so dinmicos; todo o time entende a modelagem,
facilitando assim a manuteno.
Diagrama de Atividades preocupa-se em descrever os passos a
serem percorridos para a concluso de uma atividade especfica. Concentra-se na
representao do fluxo de controle de uma atividade.
Uma atividade uma execuo no atmica em andamento em
uma mquina de estados e acabam resultando em alguma ao, formada pelas
computaes atmicas executveis que resultam em uma mudana de estado do
sistema ou o retorno de um valor.
Caractersticas:

Um diagrama de atividade observa as operaes passadas entre os objetos;

Mostra o fluxo de uma atividade para outra;
Uma atividade uma execuo em andamento;
As atividades resultam em uma ao;
As aes abrangem a chamada a outras operaes, enviando um sinal,
criando ou destruindo um objeto.

14

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 Relatrio

21

Diagrama Log de Eventos

22

Diagrama Locar DVD

23
Diagrama Devolver DVD

Diagrama
Logoff

3.1.3

NORMALIZAO
DO DIAGRAMA

RELACIONAMENTO (MRN)

ENTIDADE

24
3.3.1 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
informao de um domnio de negcio ou seus requerimentos de processo, de uma
maneira abstrata que em ltima anlise se presta a ser implementada em um banco
de dados, como um banco de dados relacional. Os principais componentes dos
modelos ER so entidades (coisas) e os relacionamentos que podem existir entre
eles, e bancos de dados.
Um modelo entidade relacionamento uma maneira sistemtica de
descrever e definir um processo de negcio. O processo modelado como
componentes (entidades) que so ligadas umas s outras por relacionamentos que
expressam as dependncias e exigncias entre elas, como: um edifcio pode ser
dividido em zero ou mais apartamentos, mas um apartamento pode estar localizado
em apenas um edifcio. Entidades podem ter vrias propriedades (atributos) que os
caracterizam. Diagramas criados para representar graficamente essas entidades,
atributos e relacionamentos so 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 prprias tabelas representam as entidades. Alguns campos de dados
nestas tabelas apontam para ndices em outras tabelas. Tais ponteiros representam
relacionamentos.
A utilizao do modelo Entidade Relacionamento de suma
importncia para representao grfica daquilo que queremos representar facilitando
a compreenso daqueles envolvidos na construo do projeto.
3.3.2 Tcnica de modelagem entidade e relacionamento
Entidade: aquele objeto existente no mundo real, com uma identificao
distinta e significado prprio. So as coisas que existem no negcio, ou ainda,
que descrevem o negcio em si. Se algo existe e proporciona algum interesse
em manter dados sobre ele, isto caracteriza como uma Entidade do negcio.
Desta forma, podemos dizer que uma entidade ser uma tabela em
nosso banco de dados. Na verdade quando identificamos todas as entidades,
estaremos definindo quais sero as tabelas que teremos que criar em nosso banco

25
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, so
entidades: Cliente, Funcionrio, Departamento, fornecedor, etc. Cada entidade
representa objetos com as mesmas caractersticas. Um banco de dados, portanto,
compreende uma coleo de conjuntos de entidades do mesmo tipo.
Relacionamentos: Geralmente so os verbos, um conjunto de associaes
entre as entidades, acontecimento que liga duas entidades existentes no
mundo real. O relacionamento pode ser binrio ou ternrio e representado
atravs de um losango internamente nomeado e ligado a entidades atravs
de linhas, conforme abaixo:

ALUGUEL

ALUGA

CLIENTE

Atributos: So propriedades (caractersticas) que identificam as entidades.

Uma entidade representada por um conjunto de atributos. Nome, endereo,
telefone e cidade, por exemplo, so atributos da entidade Clientes. Enquanto
que salrio, cargo e departamento so atributos da entidade funcionrios.
Classificao dos Atributos
Os atributos podem ser simples, composto, multivalorado ou
determinante.

Atributo Simples: No possui qualquer caracterstica especial: A maioria dos

atributos ser simples. Quando um atributo no composto, recebe um valor
nico como nome, por exemplo, e no um atributo chave, ento ele ser
atributo simples.

26

Atributo Composto: O seu contedo formado por vrios itens menores. Ex.
Endereo. Seu contedo poder ser dividido em vrios outros atributos,
como: Rua, Nmero, Complemento, Bairro, CEP e Cidade.

Atributo Multivalorado: O seu contedo formado por mais de um valor. Ex.:

Telefone. Uma pessoa poder ter mais de um nmero de telefone. indicado
colocando-se um asterisco precedendo o nome do atributo.

Atributo Determinante: Identifica de forma nica uma entidade, ou seja, no

pode haver dados repetidos. indicado sublinhando-se o nome do atributo.
Exemplo: CNPJ, CPF, Cdigo do fornecedor, Nmero da matrcula, etc. Os
atributos determinantes sero as chaves primrias no banco de dados e seu
uso tem implicaes na normalizao de dados.

3.3.3 Diagrama Entidade-Relacionamento (DER)

O Diagrama Entidade-Relacionamento descreve toda estrutura lgica
do banco de dados. possvel constru-lo a partir de um MER, identificando assim a
partir de um conceito do mundo real como os dados sero armazenados de fato.
O DER tem como nfase os dados e os relacionamentos. Sua
representao utiliza os smbolos:

Retngulos - 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
entidades aos conjuntos de relacionamentos;

Elipses duplas - atributos multivalorados.

Na construo de um projeto de banco de dados necessrio saber
quais so os objetos e os relacionamentos para elaborar o DER, ou seja, descobrir
quais os atributos que compem as tabelas (objetos).

Seguindo nosso exemplo um cliente, seja ele pessoa fsica ou

jurdica, realiza locaes de DVD, cada locao tem sua identificao e um atributo
data, representando a data de retirada, portanto a representao grfica ficaria
dessa forma:

27

Com

havia
sido

falado,

um

losango

faz

a ligao
entre as
entidades

relacionadas, porm a um detalhe que ainda no foi explicado, a cor de cada uma
das metades desse losango, essa diviso de cores representa o tipo de
relacionamento entre as entidades.
No caso da locadora, cada cliente pode realizar vrios alugueis,
porm cada aluguel feito por apenas um cliente (repare o uso da palavra cada
que auxilia bastante na hora de classificar os relacionamento). Essa representao 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 representao um pouco diferente da
representao padro onde teramos algo assim:

28

Nessa imagem foram omitidos os atributos de cada entidade. Como

podemos ver ao invs de colorir os losangos indicando o tipo de relacionamento, em
cada entidade colocado um conjunto composto por dois caracteres entre vrgulas,
o primeiro caracter antes da virgula mostra o mnimo do relacionamento, e o caracter
aps a virgula o mximo do relacionamento.
No exemplo, cada cliente pode fazer no mnimo 1 e no mximo N
(muitos) alugueis (1,N) e cada aluguel realizado por no mnimo 1 e no mximo 1
cliente (1,1). Essa metodologia mostra tanto o mnimo quanto o mximo de um
relacionamento, enquanto o DB Designer s demonstra o mximo.
Um cliente pode ter um cadastro na locadora e nunca ter alugado
nenhum filme, realmente isso pode acontecer, o que mudaria o mnimo para 0 ao
invs 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 padro usar o mnimo e o mximo, o mais
importante num relacionamento o seu mximo, que vai definir em qual das duas
entidades ser colocada chave estrangeira, que faz a ligao entre as duas
entidades no SGBD.
Tipos de Relacionamentos:
Relacionamento 1-1: Esse relacionamento ocorre quando ambas as entidades se
relacionam com mximo 1 para com a outra, no um relacionamento muito usado

29
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 informaes 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 no haveria nem a
necessidade da criao 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 mximo de uma tabela para outra 1 e
na ordem inversa N, sendo esse o que foi usado no exemplo anterior e explicado
atravs dele.
Relacionamento N-N: Ocorre quando ambas as entidades se relacionam com no
mximo N para com a outra, nesse caso ocorre a criao de uma entidade fraca
entre essas entidades para guardar o relacionamento entre essas duas atravs de
suas chaves estrangeiras, no exemplo da locadora esse relacionamento pode ser
encontrado no relacionamento entre alugueis e filmes representado abaixo:

30

31
Como

podemos

perceber,

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, porm
pode ter outros atributos tambm.
3.3.4 Normalizao

A utilizao do MER nos proporciona a criao de um DER

(Diagrama de Entidades e Relacionamento). Os DER fazem uma representao de
parte de um mundo real onde so feitas representaes estruturadas e conceituais
do que o ser humano pode fazer nessa parcela do mundo real.
A princpio, Peter Chen props como notao desses diagramas os
retngulos como sendo as entidades, os losangos como sendo os relacionamentos
entre as entidades, os crculos como sendo os atributos das entidades e linhas de
conexo para mostrar a cardinalidade entre uma entidade e outra.
Ao aplicar esse sistema de Relacionamento, existe uma srie de
passos para fazer com que os dados tornem-se menos redundantes e menos
inconsistentes. Tais passos so chamados de Normalizao de dados. A primeira
forma normal foi definida por Edgar F. Codd em 1970. Essa norma tinha como
definio permitir que os dados fossem questionados e manipulados usando uma
"sub-linguagem de dados universal" atrelada lgica de primeira ordem. Nem
sempre essa normalizao eficiente, dependendo da separao entre o projeto
lgico da base de dados e a implementao fsica do banco de dados.
Para normalizao feito um trabalho sobre as restries que
indicam relaes individuais, isto , as restries relacionais. O propsito destas
restries descrever o universo relacional, ou seja, o conjunto de todas as relaes
que so permitidas para serem associadas com certos nomes de relao. Dentre
essas restries 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 relao norma anterior. Abaixo as normas e definies:
Primeira Norma Formal: Uma tabela est na 1FN, se e somente se, no
possuir atributos multivalor.
Segunda Norma Formal: Uma relao est na 2FN se, e somente se, estiver
na 1FN e cada atributo no-chave for dependente da chave primria inteira,

32
isto , cada atributo no-chave no poder ser dependente de apenas parte
da chave.
Terceira Norma Formal: Uma relao R est na 3FN, se estiver na 2FN e
cada atributo no-chave de R no possuir dependncia transitiva, para cada
chave candidata de R.
Quarta Norma Formal: Uma tabela est na 4FN, se e somente se, estiver na
3FN e no existirem dependncias multivaloradas.

33
4 CONCLUSO
Ao final do trabalho, percebi que o constante aumento no nmero
de incidentes de segurana e a alavancagem dos sistemas Web tornam
importante manuteno de sua seguridade. Portanto necessrio dar uma
maior ateno ao aspecto de segurana nesta fase com a aplicao de prticas
que reduzam as possibilidades de falhas e prejuzos para a empresa, os clientes
e o prprio desenvolvedor.

Em estudo sobre Diagrama de atividade me fez perceber quando

devemos implementar o diagrama, e os benefcios de sua utilizao dentro do
projeto de desenvolvimento. Referente normalizao dentro de um projeto
fundamental para um correto funcionamento da aplicao e principalmente do banco
de dados. Pesquisando um pouco mais sobre a Normalizao no Diagrama Entidade
Relacionamento (DER) s veio a enriquecer ainda mais o conhecimento adquirido
durante o semestre.
O contedo deste texto somente foi possvel aps um grande
trabalho de pesquisa que exigiu uma anlise e uma reflexo sobre cada disciplina. O
grande volume de informaes disponveis na rede auxiliou e muito na busca do
conhecimento.
Portanto, o objetivo do trabalho foi alcanado, enriqueci meus
conhecimentos atravs da prtica nas atividades propostas onde foi possvel
assimilar os conceitos e tcnicas apresentados pelos professores desse 4 semestre
Desenvolvimento de Sistemas II.

34
REFERNCIAS

ANHANGUERA NITERI, Banco de Dados I. Disponvel em:

https://sites.google.com/site/uniplibancodedados1/aulas/aula-4---modelo-entidade-erelacionamentos. Acesso em: 25 de outubro de 2014.
DEVMEDIA.COM.BR, Modelo Entidade Relacionamento (MER) e Diagrama
Entidade-Relacionamento (DER). Disponvel em:
http://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagramaentidade-relacionamento-der/14332. Acesso em: 19 de outubro de 2014.
SITEBLINDADO.COM, Segurana Para aplicaes Web. Disponvel em:
http://www.siteblindado.com/pt/pags/view/files/WhitePaper+QualysGuard+Vulnerabilit
y+Web+Applications.pdf. Acesso em: 26 de outubro de 2014.
OWASP.ORG, As 10 vulnerabilidades de segurana mais crticas em aplicaes
WEB. Disponvel em:
https://www.owasp.org/images/4/42/OWASP_TOP_10_2007_PT-BR.pdf. Acesso em:
30 de outubro de 2014.
PERINI, Luis Cludio. Engenharia de software. So Paulo. Editora Pearson, 2009.
WIKIPEDIA, Diagrama de atividade. Disponvel em:
http://pt.wikipedia.org/wiki/Diagrama_de_atividade. Acesso em: 26 de outubro de
2014.
WIKIPEDIA, Modelo entidade relacionamento. Disponvel em:
http://pt.wikipedia.org/wiki/Modelo_entidade_relacionamento. Acesso em: 24 de
outubro de 2014.