www.devmedia.com.br 
Link original: http://www.devmedia.com.br/articles/viewcomp.asp?comp=14332

Modelo Entidade Relacionamento (MER) e Diagrama Entidade-Relacionamento (DER)

Veja neste artigo as definições de Modelo Entidade Relacionamento (MER) e Diagrama Entidade Relacionamento (DER), utilizados na modelagem de bancos de dados.

Motivação

Quando se inicia o desenvolvimento de um novo sistema, ou mesmo de uma nova funcionalidade para um sistema existente, um dos primeiros passos a ser executado é o estudo e levantamento dos requisitos necessários para a construção do produto final. Durante essa análise, identifica-se as principais partes e objetos envolvidos, suas possíveis ações e responsabilidades, suas características e como elas interagem entre si.

A partir das informações obtidas, pode-se desenvolver um modelo conceitual que será utilizado para orientar o desenvolvimento propriamente dito, fornecendo informações sobre os aspectos relacionados ao domínio do projeto em questão.

 Saiba mais sobre levantamento de requisitos na Engenharia de Software.

Modelo Entidade Relacionamento

O Modelo Entidade Relacionamento (também chamado Modelo ER, ou simplesmente MER), como o nome sugere, é um modelo conceitual utilizado na Engenharia de Softwarepara descrever os objetos (entidades) envolvidos em um domínio de negócios, com suas características (atributos) e como elas se relacionam entre si (relacionamentos).

Em geral, este modelo representa de forma abstrata a estrutura que possuirá o banco de dados da aplicação. Obviamente, o banco de dados poderá conter várias outras entidades, tais como chaves e tabelas intermediárias, que podem só fazer sentido no contexto de bases de dados relacionais.

Observação: nem sempre criaremos modelos para um sistema completo, pois isso poderia resultar em um modelo muito extenso e difícil de interpretar. Dependendo da magnitude do que estaremos desenvolvendo, podemos criar modelos apenas para uma parte do sistema, um módulo, ou mesmo uma funcionalidade. Imagine, por exemplo, um sistema ERP de grande porte que contemple vendas, finanças, recursos humanos, etc. Várias entidades estão presentes em mais de uma parte do sistema, mas não seria muito interessante, e provavelmente nem mesmo necessário, criar um único modelo para todo o sistema, por isso pode-se dividir a modelagem em várias partes menores.

 Saiba mais sobre modelagem de bancos de dados relacionais.

Entidades

Os objetos ou partes envolvidas um domínio, também chamados de entidades, podem ser classificados como físicos ou lógicos, de acordo sua existência no mundo real. Entidades físicas: são aquelas realmente tangíveis, existentes e visíveis no mundo real, como um cliente (uma pessoa, uma empresa) ou um produto (um carro, um computador, uma roupa). Já as entidades lógicas são aquelas que existem geralmente em decorrência da interação entre ou com entidades físicas, que fazem sentido dentro de um certo domínio de negócios, mas que no mundo externo/real não são objetos físicos (que ocupam lugar no espaço). São exemplos disso uma venda ou uma classificação de um objeto (modelo, espécie, função de um usuário do sistema).

As entidades são nomeadas com substantivos concretos ou abstratos que representem de forma clara sua função dentro do domínio. Exemplos práticos de entidades comuns em vários sistemas são Cliente, Produto, Venda, Turma, Função, entre outros.

Podemos classificar as entidades segundo o motivo de sua existência:

• Entidades fortes: são aquelas cuja existência independe de outras entidades, ou seja, por si só elas já possuem total sentido de existir. Em um sistema de vendas, a entidade produto, por exemplo, independe de quaisquer outras para existir.
• Entidades fracas: ao contrário das entidades fortes, as fracas são aquelas que dependem de outras entidades para existirem, pois individualmente elas não fazem sentido. Mantendo o mesmo exemplo, a entidade venda depende da entidade produto, pois uma venda sem itens não tem sentido.
• Entidades associativas: esse tipo de entidade surge quando há um relacionamento do tipo muitos para muitos (explicado a seguir). Nestes casos, é necessária a criação de uma entidade intermediária cuja identificação é formada pelas chaves primárias (explicado mais adiante) das outras duas entidades. No contexto de uma aplicação de vendas, como precisamos relacionar vendas e produtos numa relação muitos para muitos, a entidade produto não pode referenciar diretamente a venda, nem o inverso, pois isso caracterizaria um relacionamento um para um, ou um para muitos. Sendo assim, criamos uma entidade intermediária para representar os itens da venda, que tanto possuem a identificação do produto, quando da venda em que estão contidos. Neste caso específico, também caberiam a esta entidade informações como quantidade de itens e desconto unitário, por exemplo.

Mais adiante veremos um exemplo prático onde poderemos observar a existência dessas entidades de forma mais clara.

Relacionamentos

Uma vez que as entidades são identificadas, deve-se então definir como se dá o relacionamento entre elas. De acordo com a quantidade de objetos envolvidos em cada lado do relacionamento, podemos classifica-los de três formas:

• Relacionamento 1..1 (um para um): cada uma das duas entidades envolvidas referenciam obrigatoriamente apenas uma unidade da outra. Por exemplo, em um banco de dados de currículos, cada usuário cadastrado pode possuir apenas um currículo na base, ao mesmo tempo em que cada currículo só pertence a um único usuário cadastrado.
• Relacionamento 1..n ou 1..* (um para muitos): uma das entidades envolvidas pode referenciar várias unidades da outra, porém, do outro lado cada uma das várias unidades referenciadas só pode estar ligada uma unidade da outra entidade. Por exemplo, em um sistema de plano de saúde, um usuário pode ter vários dependentes, mas cada dependente só pode estar ligado a um usuário principal. Note que temos apenas duas entidades envolvidas: usuário e dependente. O que muda é a quantidade de unidades/exemplares envolvidas de cada lado.
• Relacionamento n..n ou *..* (muitos para muitos): neste tipo de relacionamento cada entidade, de ambos os lados, podem referenciar múltiplas unidades da outra. Por exemplo, em um sistema de biblioteca, um título pode ser escrito por vários autores, ao mesmo tempo em que um autor pode escrever vários títulos. Assim, um objeto do tipo autor pode referenciar múltiplos objetos do tipo título, e vice versa.

Os relacionamentos em geral são nomeados com verbos ou expressões que representam a forma como as entidades interagem, ou a ação que uma exerce sobre a outra. Essa nomenclatura pode variar de acordo com a direção em que se lê o relacionamento. Por exemplo: um autor escreve vários livros, enquanto um livro é escrito por vários autores.

Atributos

Atributos são as características que descrevem cada entidade dentro do domínio. Por exemplo, um cliente possui nome, endereço e telefone. Durante a análise de requisitos, são identificados os atributos relevantes de cada entidade naquele contexto, de forma a manter o modelo o mais simples possível e consequentemente armazenar apenas as informações que serão úteis futuramente. Uma pessoa possui atributos pessoais como cor dos olhos, altura e peso, mas para um sistema que funcionará em um supermercado, por exemplo, estas informações dificilmente serão relevantes.

Os atributos podem ser classificados quanto à sua função da seguinte forma:

• Descritivos: representam característica intrínsecas de uma entidade, tais como nome ou cor.
• Nominativos: além de serem também descritivos, estes têm a função de definir e identificar um objeto. Nome, código, número são exemplos de atributos nominativos.
• Referenciais: representam a ligação de uma entidade com outra em um relacionamento. Por exemplo, uma venda possui o CPF do cliente, que a relaciona com a entidade cliente.

Quanto à sua estrutura, podemos ainda classificá-los como:

• Simples: um único atributo define uma característica da entidade. Exemplos: nome, peso.
• Compostos: para definir uma informação da entidade, são usados vários atributos. Por exemplo, o endereço pode ser composto por rua, número, bairro, etc.

Alguns atributos representam valores únicos que identificam a entidade dentro do domínio e não podem se repetir. Em um cadastro de clientes, por exemplo, esse atributo poderia ser o CPF. A estes chamamos de Chave Primária.

Já os atributos referenciais são chamados de Chave Estrangeira e geralmente estão ligados à chave primária da outra entidade. Estes termos são bastante comuns no contexto de bancos de dados. Mantendo o exemplo anterior, a entidade cliente tem como chave primária seu CPF, assim, a venda possui também um campo “CPF do cliente” que se relaciona com o campo CPF da entidade cliente.

Diagrama Entidade Relacionamento

Enquanto o MER é um modelo conceitual, o Diagrama Entidade Relacionamento (Diagrama ER ou ainda DER) é a sua representação gráfica e principal ferramenta. Em situações práticas, o diagrama é tido muitas vezes como sinônimo de modelo, uma vez que sem uma forma de visualizar as informações, o modelo pode ficar abstrato demais para auxiliar no desenvolvimento do sistema. Dessa forma, quando se está modelando um domínio, o mais comum é já criar sua representação gráfica, seguindo algumas regras.

O diagrama facilita ainda a comunicação entre os integrantes da equipe, pois oferece uma linguagem comum utilizada tanto pelo analista, responsável por levantar os requisitos, e os desenvolvedores, responsáveis por implementar aquilo que foi modelado.

Em sua notação original, proposta por Peter Chen (idealizador do modelo e do diagrama), as entidades deveriam ser representadas por retângulos, seus atributos por elipses e os relacionamentos por losangos, ligados às entidades por linhas, contendo também sua cardinalidade (1..1, 1..n ou n..n). Porém, notações mais modernas abandonaram o uso de elipses para atributos e passaram a utilizar o formato mais utilizado na UML, em que os atributos já aparecem listados na própria entidade. Essa forma torna o diagrama mais limpo e fácil de ser lido.

Observe na Figura 1 um exemplo simples de um diagrama para um sistema de imobiliárias.

 
Figura 1. Diagrama Entidade Relacionamento de sistema de imobiliária

No domínio representado pelo diagrama acima temos as seguintes entidades e relacionamentos:

• Proprietário contata Corretor (um proprietário pode contatar vários corretores e um corretor pode ser contatado por vários proprietários).
• Corretor atende Inquilino (um corretor pode atender vários inquilinos e um inquilino pode ser atendido por vários corretores).
• Inquilino aluga Imóvel (um inquilino aluga um imóvel e um imóvel pode ser alugado por vários inquilinos).
• Proprietário possui Imóvel (um proprietário possui vários imóveis e um imóvel pertence a apenas um proprietário).

Uma variante da Figura 1 pode ser vista na Figura 2, onde a cardinalidade do relacionamento é exibida junto do losango.

 
Figura 2. Diagrama de Entidade Relacionamento (variação)

Uma outra variação já mostra a cardinalidade de uma forma mais completa, deixando claro as possibilidades de números de objetos envolvidos em cada relacionamento. Nesse modelo, em cada lado do relacionamento os números aparecem no formato (X,Y) ao invés de um único número como vemos nas figuras anteriores. A Figura 3 ilustra um exemplo desse tipo.

 
Figura 3. Diagrama Entidade Relacionamento (variação 2)

Neste diagrama, lemos os relacionamentos da seguinte forma:

• 1 ou 1 grupo possui 0 ou muitos produtos. Como de um lado temos “1 ou 1”, isso equivale a apenas “1”, pois não temos várias possibilidades. Já do lado do produto, indicamos que um grupo pode possuir nenhum produto, mas também pode possuir vários.
• 0 ou várias vendas contém 1 ou muitos produtos. Ou seja, um produto pode nunca ser vendido (0 vendas) como também pode ser vendido várias vezes (n vendas). Já uma venda deve conter 1 ou vários produtos, pois uma venda não pode estar vazia (0 produtos).

Os atributos, como já foi dito, podem aparecer no diagrama na forma de elipses ligadas às entidades. Essa foi a notação original proposta, mas como podemos ver na Figura 4, ela deixa o diagrama com muitos itens e pode atrapalhar um pouco a organização destes.

 
Figura 4. Atributos apresentados como elipses

Em uma notação mais atual, comumente utilizada na UML, os atributos aparecem listados dentro do próprio retângulo da entidade, enquanto o nome da entidade aparece no topo na forma de título. Na Figura 5 temos um exemplo.

 
Figura 5. Diagrama com atributos nas entidades

Ferramentas CASE

Do inglês Computer-Aided Software Engineering, as chamadas ferramentas CASE são aquelas baseadas em computadores (softwares) utilizadas na Engenharia de Software para auxílio nas atividades desde análise de requisitos até ,modelagem de dados.

No contexto desse artigo, as ferramentas CASE permitem a criação de diagramas de forma simples em um ambiente de fácil utilização e com recursos para incluir as principais regras de composição dos diagramas. Exemplos comuns desse tipo de ferramenta são: Star UML, Astah e ERwin Data Modeler. Na Figura 6 vemos um exemplo de diagrama sendo construído no Astah.

 
Figura 6. Diagrama no Astah Community

Além dessas ferramentas específicas, alguns IDEs (Integrated Development Environment ou Ambiente de Desenvolvimento Integrado) como o Visual Studio e ferramentas degerenciamento de bancos de dados como SQL Server Management Studio possuem funcionalidades para criar diagramas facilmente e já gerar o código equivalente (SQL para criação das tabelas, chaves e relacionamentos, por exemplo).

 Saiba mais sobre como criar diagramas com o Astah.

Exemplo prático

Para fixar tudo que foi visto ao longo deste artigo, vamos agora desenvolver um pequeno exemplo prático em que modelaremos um sistema de bibliotecas, focando especificamente no empréstimo de livros.

Primeiramente precisamos identificar as entidades envolvidas nesse contexto. Sabemos que as entidades físicas existentes são o Usuário da biblioteca e o Livro que será emprestado. Além disso, consideraremos aqui que o livro pertence a uma Sessão, que ajuda na organização das obras do acervo. Em um sistema real pode haver outras informações sobre o livro, mas para esse exemplo a sessão é o bastante. Por fim, temos a entidade lógica Empréstimo, que tanto está relacionada com o usuário, quanto com o livro.

Assim já podemos esboçar nosso primeiro diagrama, simples, contendo as principais entidades e o relacionamento entre elas (Figura 7).

 
Figura 7. Primeiro DER de um sistema para biblioteca

Neste primeiro diagrama podemos identificar alguns dos conceitos vistos:

• Entidades fortes: Usuário, Livro e Sessão;
• Entidades fracas: Empréstimo;
• Relacionamentos: um Usuário efetua vários Empréstimos, vários Empréstimos contêm vários Livros, vários Livros pertencem a uma Sessão.

Agora que visualizamos o domínio no diagrama, podemos adicionar os atributos e outras entidades que se façam necessárias. Assim, passamos à Figura 8,

 
Figura 8. DER mais completo do sistema para bibliotecas

Neste ponto cabe fazer algumas observações importantes:

Especificamos os atributos de cada entidade e marcamos algumas elas com um asterisco, indicando que aquela é a chave primária da tabela, ou seja, um atributo único, que nunca poderá se repetir entre as entidades do mesmo tipo. Note que neste momento ainda não é necessário especificar o tipo de cada atributo (texto, número, data, etc.), isso só será necessário mais adiante, quando já estivermos planejando o banco de dados da aplicação.

Surgiu a entidade associativa Livro_Empréstimo, que representa os livros contidos em um empréstimo (considerando um empréstimo contém vários livros e um livro pode estar contido em vários empréstimos). Esta entidade é composta pelas chaves das duas entidades principais. Se fosse necessário, nesta entidade também poderíamos adicionar informações complementares como quantidade (não se aplica neste caso, mas caberia em um sistema de vendas, por exemplo) e observações sobre o item.

Na entidade associativa, o relacionamento n..n foi dividido em dois relacionamentos do tipo 1..n, agora lidos da seguinte forma: um empréstimo contém vários itens, mas um item só pode estar contido em um único empréstimo (restrito pelas chaves primárias); um livro pode estar contido em vários itens de empréstimo (ser emprestado várias vezes), mas cada item refere-se a um único livro.

O Modelo Entidade Relacionamento (e principalmente o diagrama) é uma importante ferramenta durante o desenvolvimento de sistemas, principalmente aqueles mais complexos e difíceis de visualizar sem uma análise mais aprofundada.

A correta modelagem auxilia no correto desenvolvimento da base de dados e evita que várias alterações sejam necessárias para corrigir erros de concepção provenientes de falhas durante a análise, ou ainda por problemas de comunicação entre os membros da equipe.

 Curso relacionado: Modelagem de Bancos de Dados

por Joel Rodrigues

Engenharia de software lover 

Conheça 3 cursos grátis para começar a explorar machine learning - IDG Now!

Conheça 3 cursos grátis para começar a explorar machine learning - IDG Now!

A inteligência artificial assumiu status de vetor das grandes transformações previstas para a próxima década. A lista de tecnologias emergentes divulgada recentemente pelo Gartner reforça que os algoritmos de aprendizado de máquina terão papel fundamental no sucesso das organizações digitais. 

“Estamos mergulhando em uma nova era da informação e da computação. É um novo mundo com habilidade de compreender o ambiente e as pessoas, provendo conclusões realmente significativas... uma forma diferente de usar tecnologia”, pronunciou Steve Ballmer, pouco depois de deixar o comando da Microsoft. 

É importante aproveitar que essa onde ainda encontra-se em estágio de formação para encontrar a melhor maneira de surfa-la. Pensando nisso, separamos três cursos online e gratuitos sobre machine learning para ajudá-lo a seguir nessa jornada.

Introdução ao Aprendizado de Máquina – Reconhecimento de Padrões para diversão e lucro 

A ideia aqui é aprender fazendo. O plano de aula ensina o processo de investigação de dados através do aprendizado de máquina. Pelo programa, é possível utilizar e avaliar os algoritmos, identificar casos de uso do conceito e entender como resolver problemas do mundo real.

Aprendizagem Automática 

A Aprendizagem Automática é a ciência que faz com que os computadores exerçam seu papel de forma natural sem que pareçam explicitamente programados para tal. Na última década, essa disciplina ajudou no desenvolvimento de carros autônomos e compreensão do genoma humano. Atualmente, está tão difundida, que você provavelmente a utiliza várias vezes ao dia sem que perceba. 

Este curso mostrará técnicas mais eficazes de aprendizagem automática, colocá-las em prática e ver como adequar essas técnicas para suas necessidades. O mais importante é que você não aprenderá apenas na teoria e sim terá o conhecimento prático necessário para aplicar o que aprender de forma rápida e exitosa e solucionar os problemas em seus projetos.

Machine Learning for Data Science and Analytics 

A ideia é ensinar princípios fundamentais de aprendizado de máquinas e a importância dos algoritmos dentro desse conceito. Esse curso dará noções básicas para compreender e pensar aplicações para o conceito usando análises preditivas. O programa contempla desde temas abrangentes até exemplos práticos de uso de machine learning em indústrias específicas, como o setor de saúde, por exemplo.

11 ferramentas abertas para machine learning que vão facilitar sua vida - IDG Now!

11 ferramentas abertas para machine learning que vão facilitar sua vida - IDG Now!



Filtros de spam, reconhecimento facial, motores de recomendação. Quando se tem um grande volume de dados capazes de alimentar sistemas preditivos ou reconhecer padrões, usar esse recurso em projetos de aprendizado de máquinas (machine learning) pode ser um ótimo caminho a seguir. 

Essa ciência, no qual os computadores são treinados a aprender, analisar e agir sobre registros ganha cada vez mais relevância no mercado, especialmente dentro do mundo acadêmico e em círculos de programadores de alta performance.

O aumento da popularidade vem à reboque não só do barateamento de hardware, mas da proliferação de software livre que exploram recursos direcionados ao machine learning. A seguir, apresentamos 11 ferramentas capazes de fornecer funcionalidades tanto para aplicativos individuais quanto para estruturas inteiras. Confira. 

Scikit-learn  

Python se transformou em uma ótima linguagem de programação com recursos de matemática, ciências e estatística devido a sua facilidade de adoção e amplitude de bibliotecas disponíveis, que permite que seja usado para criação de praticamente qualquer aplicação. Os níveis de aprendizagem do Schikit possibilitam construir soluções sobre pacotes existentes em Python – como NumPy, SciPy e matplotlib. 

As bibliotecas resultados podem ser usadas para aplicações interativas em uma “bancada de trabalho” ou serem incorporadas em outros softwares, com reutilização. O kit está disponível por meio de uma licença BSD, totalmente aberta e reutilizável. 

Projeto: scikit-learn 

GitHub: https://github.com/scikit-learn/scikit-learn

Shogun 

Entre as mais antigas e veneráveis bibliotecas de aprendizado de máquina está o Shogun, que nasceu em 1999 escrito em C++, mas que já não se limita apenas a trabalhar em C++ . Graças à biblioteca SWIG, a ferramenta pode ser usada de forma transparente em linguagens e ambientes como Java, Python, C#, Ruby, R, Lua, Octave e Matlab. 

O Shogun tem um concorrente também em C++, a biblioteca baseada em machine learning, Mlpack, que ganhou espaço a partir de 2011 e que traz vantagens de ser mais rápida e fácil de trabalhar (pois carrega um conjunto mais integral de APIs) frente a seus competidores.

Projeto: Shogun 

GitHub: https://github.com/shogun-toolbox/shogun

Accord Framework/AForge.net 

O Accord, um framework para aprendizado de máquinas e processamento de sinais em .Net é uma extensão de um projeto prévio com o mesmo intuito, o AForge.net. A propósito, “signal processing” se refere a uma gama de algoritmos de aprendizado de máquinas para imagens e áudio que pode ser aplicado para questões como reconhecimento facial, por exemplo. 

Projeto: Accord Framework/AForge.net 

GitHub: https://github.com/accord-net/framework/

Mahout 

Trata-se de um framework alinhado ao Hadoop, mas muitos dos algoritmos sob o seu guarda-chuva pode também rodar fora disso. É bastante útil para aplicações stand-alone e, eventualmente, pode ser migrado dentro e para projetos em Hadoop. 

Projeto: Mahout 

MLlib 

Própria biblioteca de aprendizado de máquina do Apache para Spark e Hadoop, o MLlib possui uma gama de algoritmos comuns e tipos de dados úteis destinados a funcionar em grande velocidade e escala. Como seria de esperar com qualquer projeto Hadoop, Java é a linguagem primária para trabalhar na ferramenta, mas os usuários podem se conectar a Python MLlib através da biblioteca NumPy (também usado em Scikit), e os usuários Scala podem escrever códigos contra o MLlib. Se a criação de um cluster Hadoop é impraticável, o MLlib pode ser implantado em cima do Spark sem Hadoop - e no EC2 ou no Mesos. 

Outro projeto é o MLbase, construído em cima de MLlib para torná-lo mais simples na obtenção de obter resultados. Ao invés de escrever o código, os usuários fazem consultas por meio de uma linguagem declarativa à la SQL. 

Projeto: MLlib

H2O

Algoritmos de H2O do 0xdata são voltados para processos de negócios – de previsões de fraude ou de tendência, por exemplo. O H2O pode interagir de forma independente com lojas HDFS, em cima de YARN, MapReduce ou diretamente em uma instância do Amazon EC2. Especialistas em Hadoop podem usar Java para interagir com a ferramenta, mas a estrutura também fornece ligações para Python, R e Scala, proporcionando integração cruzada com todas as bibliotecas disponíveis nessas plataformas também. 

Projeto: H20 

GitHub: https://github.com/0xdata/h2o 

Cloudera Oryx 

Outro projeto de aprendizagem máquina projetado para Hadoop, o Oryx vem como uma espécie de cortesia dos criadores da distribuição Cloudera Hadoop. O nome no rótulo não é o único detalhe que define a ferramenta, que enfatiza na análise de dados em tempo real por meio do projeto Spark e é projetado para permitir que modelos de aprendizado de máquina possam ser implantados em transmissões de informações “ao vivo”, como filtros de spam ou mecanismos de recomendação. Uma nova versão do projeto encontra-se em obras. 

Projeto: Cloudera Oryx 

GitHub: https://github.com/cloudera/oryx 

GoLearn  

A linguagem Go, do Google, está no ar faz cerca de cinco anos. Apesar da vida ainda curta, já desfruta uma utilização ampla e tem uma evolução constante em suas bibliotecas. O GoLearn foi criado com a ambição de ser uma biblioteca que reúne tudo de aprendizado de máquinas na plataforma da gigante de buscas. A ideia geral é que seja uma maneira simples de tratar o carregamento e manipulação dos dados na biblioteca. 

Projeto: GoLearn 

GitHub: https://github.com/sjwhitworth/golearn 

Weka  

Produto da Universidade neozelandesa de Waikato, o Weka reúne um conjunto de algoritmos de aprendizado de máquina Java projetados especificamente para mineração de dados. Esta coleção com licenciamento GNU GPLv3 tem um sistema de pacotes para estender sua funcionalidade. Weka vem com um livro para explicar tanto o software e quanto as técnicas utilizadas, que pode ser um bom ponto de partida aos que querem se aventurar nessa ferramenta. Apesar de não ser voltado especificamente, pode ser usado com Hadoop graças a um conjunto de wrappers produzidos para as versões mais recentes do Weka. Note-se que ainda não suporta Spark, só o MapReduc. 

Projeto: Weka 

CUDA-Convnet  

Quase todo mundo sabe como GPUs (sigla para unidade de processamento gráfico) podem mastigar certos problemas de maneira mais veloz do que CPUs. Mas os aplicativos não levam automaticamente a vantagem da aceleração GPU. Aliás, eles têm que ser escritos com formas específicas para que isso ocorra. O CUDA-Convnet é uma biblioteca de aprendizado de máquina para aplicações de rede neural escrito em C++ para explorar a tecnologia CUDA de processamento de GPU da Nvidia (placas de, pelo menos, a geração Fermi são obrigatórios). Para aqueles que usam Python em vez de C++, as redes neurais resultantes podem ser salvos como objetos Python em conserva e, assim, acessado a partir de Python. Note que a versão original do projeto não está mais sendo desenvolvida, mas desde que foi reformulado em um sucessor, CUDA-Convnet2 (com suporte para múltiplas GPUs). 

Projeto: CUDA-Convnet 

ConvNetJS 

Como o nome indica, ConvNetJS fornece bibliotecas de aprendizado de máquina de rede neural para uso em JavaScript o que facilita o uso do navegador como uma bancada de dados. Uma versão NPM também está disponível para aqueles que utilizam Node.js e a biblioteca é projetada para fazer uso adequado de assincronia de JavaScript - por exemplo, operações de treinamento podem executar retornos de chamadas, 

Projeto: ConvNetJS 

GitHub: https://github.com/karpathy/convnetjs

  

Uso de API’s no mercado de serviços financeiros

Embora à primeira vista o uso de API (Application Programming Interface ou “Interface de Programação de Aplicativos”) pareça um assunto muito técnico, a ideia principal deste artigo é apresentá-lo de forma simples e sob a ótica de negócios para mostrar como as empresas podem aumentar seus negócios com sua adoção.

Um aplicativo ou software construído para atender um usuário final  costuma ser projetado para tornar sua utilização simples, rápida, fácil e agradável. Um software não tem olhos, emoções ou intuição, então ele não precisa de uma interface amigável quando se trata de entregar serviços para outro aplicativo. No entanto, da mesma forma como a interface adaptada para seres humanos, o software necessita de uma interface que facilite o consumo de dados e,ou funcionalidade.

Uma API é um conjunto de rotinas e padrões estabelecidos por um software para a utilização das suas funcionalidades por aplicativos que não pretendem envolver-se em detalhes da implementação do software, mas apenas usar seus serviços. As API’s são comumente desenvolvidas como interfaces para serem entendidas por computadores, da mesma forma como as interfaces de usuário, são criadas para ser entendidas e utilizadas de forma clara por seres humanos.

Uma boa maneira de entender as API’s é no contexto de uma tomada comum de parede. As tomadas elétricas encontradas em casas ou empresas são interfaces construídas essencialmente para um serviço: a eletricidade que é consumida por nossos computadores e smartphones,  TVs, geladeiras, secadores de cabelo, entre outros aparelhos eletro-eletrônicos. A energia elétrica é o serviço e cada dispositivo que usa a eletricidade é um consumidor desse serviço.

Embora possuam diferenças dependendo da legislação de cada país, as tomadas elétricas têm alguns padrões abertos que permitem aos plugues elétricos que sejam conectados e consumam a energia oferecida (por exemplo, no Brasil, a maioria das tomadas entrega 110, ou para ser mais preciso, 127 Volts de corrente alternada. Esta especificação define essencialmente uma expectativa relacionada aos dispositivos de consumo. Da mesma forma, uma API especifica como componentes de software devem interagir uns com os outros.

Através da interface padrão, qualquer consumidor pode facilmente utilizar a energia necessária para suprir seus dispositivos que estejam compatíveis e conectados de acordo com a norma vigente. Para o consumidor porém, não importa o que está acontecendo do outro lado da parede, sejam coisas simples como a cor da fiação embutida ou “detalhes” mais complexos como a forma como a eletricidade é gerada (seja por uma usina eólica, nuclear, hidrelétrica ou solar) ou de onde essas fontes de energia estejam localizadas.

E no sentido contrário, o provedor também não precisa explicar ou apresentar quaisquer detalhes de como os serviços são oferecidos. Como a geração da energia é feita é a parte que interessa apenas ao provedor. Em um mercado fortemente regulamentado como o de Serviços Financeiros, as informações pessoais confidenciais de correntistas serão mantidas “por trás dos muros” garantindo a privacidade dos dados, o sigilo bancário e a segurança das transações.

Normalmente são criadas páginas web ou portais direcionados aos desenvolvedores, nos quais as normas e padrões da API estarão descritos e disponibilizados por meio de documentação oficial funcional e técnica à qualquer empresa ou desenvolvedor interessado em utilizar os produtos e serviços oferecidos pela instituição financeira.

Através da API, produtos e serviços como empréstimos, seguros, comércio eletrônico, pagamentos, informações de clientes, histórico de transações, autenticação e transferências bancárias, entre outros, poderão ser entregues a partir de uma ampla gama de dispositivos compatíveis.  Um comerciante que hoje oferece os seus produtos e serviços através de sua página web ou até mesmo em sua loja física, passa a oferecer um serviço de valor agregado, de forma segura aos seus clientes, acelerando a conversão e evitando desistência.

Neste novo modelo de negócios, um banco pode expandir seu raio de ação e aumentar sua receita. Por outro lado, a exposição de sua marca será menor ou inexistente, uma vez que o aplicativo pode ou não indicar quem está por trás do serviço oferecido. É parte da decisão estratégica de negócios da instituição decidir por sua utilização, dependendo da expectativa de resultados. Inovação, aumento de receita, expansão, custos e segurança são fatores críticos que devem ser considerados para a tomada de decisão pela utilização de API’s.

Ainda no tópico de segurança, as APIs são comumente desenvolvidas em três modelos: privado (interno), público (externo) ou restrito (associado). E, mais uma vez, isso depende da estratégia da empresa. Se os dados a serem expostos são muito sensíveis, as melhores opções poderiam ser uma API privada ou restrita. Apesar de mais rentáveis, este tipo de API não é de fácil manutenção e, ou atualização, uma vez que elas não têm o apoio da comunidade de desenvolvedores da maneira que as API’s públicas.

O uso de API’s Abertas promove um ecossistema centrado no cliente e inovação aberta. Atualmente, mais de 15 mil API’s (nos mais variados segmentos de mercado como serviços financeiros, governo, telecom, mobile, transporte, educação, ciência e outros) estão disponíveis no site Programmable Web. Além de informação, orientação e referências, o portal também funciona não apenas como um diretório para empresas à procura de API’s, mas também para os desenvolvedores e provedores poderem disponibilizar suas API’s.

O Open Bank Project, por exemplo, é uma API de código aberto e também loja de aplicativos para bancos que permite que as instituições financeiras desenvolvam suas ofertas digitais de forma rápida e segura usando um ecossistema de aplicações e serviços de terceiros.

Um case muito bem sucedido de API’s abertas no setor bancário é o BBVA API Market. Com presença em mais de 35 países e utilizando estratégias digitais abertas e inovadoras, em conjunto com o “mobile first” e Omni-channel, o BBVA já oferece um amplo conjunto de API’s de produtos e serviços através de seu portal.

As vantagens econômicas da utilização de APIs são vastas. Explorar este universo exige experiência e capacidade técnica para implementação e, desta forma, trazer os benefícios esperados para as empresas.

Este artigo foi publicado originalmente em Computerworld.com.

Conheça os 6 estágios que cibercriminosos usam para invadir redes - IDG Now!

Conheça os 6 estágios que cibercriminosos usam para invadir redes - IDG Now!


O maior desafio dos responsáveis pela segurança de empresas é conseguir pensar como um hacker. Na realidade, as tecnologias usadas pelos hackers são aprimoradas a cada ano, mas as suas metodologias continuam as mesmas há décadas.  

Na opinião de Bruno Zani, gerente de engenharia de sistemas da Intel Security, saber como hackers pensam e agem é o primeiro passo na direção para manter a rede segura. Segundo ele, existem seis fases de intrusão que são usadas frequentemente pelos hackers para burlar os esquemas de segurança. São elas:

1. Coleta de informações - Quando hackers planejam um ataque, a primeira coisa que eles fazem é escolher uma empresa-alvo e identificar onde será realizado o ataque. Em seguida, eles começam a recolher endereços IP e nomes de perfis importantes dentro do ambiente que podem armazenar dados corporativos ou pessoais sensíveis.

2. Exploração - Depois de elaborar uma lista completa dos funcionários e perfis-alvos, eles começam o processo de varredura. Isso inclui a verificação de instâncias específicas de aplicativos vulneráveis que estão em execução no ambiente.  

 3. Enumeração - Uma vez que um hacker tenha identificado o aplicativo vulnerável, ele procura por versões precisas das tecnologias que possuem alguma falha e podem ser invadidas.  

4. Invasão - Após encontrar um ponto de entrada, o hacker começa comprometer o servidor web, aproveitando vulnerabilidades ou problemas de configuração para obter acesso. Ao determinar como interagir com o alvo e sistema operacional subjacente, ele se infiltra para examinar quão longe pode expandir um ataque dentro da rede.  

5. Escalada - Seguindo a invasão do ambiente, o próximo passo do hacker é criar perfis de usuário e privilégios de acesso para espalhar ameaças da forma mais ampla possível.  

6. Pilhagem - A etapa final do processo de um ataque hacker é a pilhagem. Ao contrário de hackers do passado, os ataques atualmente já não são apenas elaborados para comprometer um servidor e desfigurar um site. Sua missão é muito maior, é ganhar acesso aos dados de cartão de crédito, aos segredos comerciais da empresa, às informações de clientes e informações pessoais. Enfim, minar os dados da empresa e usá-los em benefício próprio.  

Após entender como os hackers pensam é preciso agir para bloquear os ataques. A maioria das empresas tentam criar uma fortaleza de segurança de TI com uma série de produtos de vários fornecedores, cada um abordando um aspecto diferente de seu ambiente e em diferentes áreas de risco. No entanto, enquanto não entenderem como os hackers encontram vulnerabilidades em seus sistemas em silos de segurança de endpoint, gateway e de data center, não existe a chance de pará-los.  

De acordo com Zani, de nada adianta também ler cada um dos relatórios de análise de segurança disponível no mercado e implantar os produtos de segurança mais avançados. As pessoas também são parte importante da segurança. 

Muitas vezes o ataque é direcionado especialmente àquele funcionário mais desatento, que não se preocupa com os procedimentos de segurança desenvolvidos na empresa. Além disso, se as ferramentas usadas na segurança de TI e na proteção de dados não trabalharem juntas, o tempo sempre estará contra a empresa durante um ataque cibernético.

Cibercriminosos utilizam arquivos WSF como vetor para infiltração de ransomware - E-Commerce News

Cibercriminosos utilizam arquivos WSF como vetor para infiltração de ransomware - E-Commerce News

O Brasil é conhecido no campo da segurança de informação e análise de malware como um país que absorve tecnologias maliciosas “inovadoras” estrangeiras e as adapta para o ambiente local principalmente para burlar as tecnologias tradicionais de proteção.

Por meio de um monitoramento do Laboratório de Pesquisas e Ameaças da Trend Micro – empresa especializada na defesa de ameaças digitais e segurança na era da nuvem –, os especialistas em segurança descobriram um novo vetor de infecção usado por um ransomware para disseminar ameaças: por meio da extensão de arquivo Windows Script File (WSF).

A Trend Micro vem monitorando o comportamento dos atacantes brasileiros, e consequentemente, trabalhando na atualização das ferramentas de detecção comportamental baseadas em sandboxing customizado.

Por meio da execução de um HoneyPot, os pesquisadores da Trend Micro puderam rastrear três e-mails que chegaram ao laboratório para dois endereços distintos e cada um deles tinham remetentes únicos, o que demonstrou a existência de um ecossistema por trás do ataque.

• Detecção inicial pelo Deep Discovery Inspector:

A geo-localização dos IPs de origem dos e-mails é diferente para cada um:

Sérvia (Leste Europeu)

Colômbia

As “ondas” de phishing seguiram o mesmo padrão e aconteceram nos dias 18 e 19 de Julho/2016, com e-mails originados na Índia, Tailândia e também no Brasil (Goiânia).

Brasil

Um ponto que chamou a atenção da Trend Micro nesse ataque foi o uso de arquivos .wsf como ponto de entrada para evasão das tradicionais tecnologias de detecção do ransomware.

Em todos os casos foram empregadas técnicas de ofuscação de código no downloader, tornando o arquivo inicialmente ilegível, mesmo se tratando de um arquivo de texto.

Todos os arquivos .wsf, neste caso, os downloaders do ransomware, são arquivos diferentes, com uma técnica que é usada para burlar a detecção baseada em hash, e cada um dos executáveis baixados segue a mesma linha. Apesar de arquivos executáveis, cada um é único, utilizando como “propriedades do arquivo” informações relacionadas a um widget do Yahoo.

Também chamou a atenção da Trend Micro o fato do ransomware exibir a mensagem sobre a criptografia dos arquivos e o pedido de resgate em diferentes línguas, mostrando assim não se tratar de uma ameaça simples ou comum.

Tela de resgate do ransomware em português do Brasil (Idioma nativo do ambiente analisado)

Tela do resgate com mensagem em inglês (o que demonstra que o ransomware se adapta a região que está atacando) 

O Deep Discovery da Trend Micro determinou que o tipo de ameaça é VAN_RANSOMWARE. A partir das novas versões do produto, a nomenclatura ransomware é adicionada sempre que algum comportamento relacionado a esse tipo de ameaça é encontrado. Se for desconhecido como neste caso, é adicionado o prefixo VAN (VirtualANalyzer).

O comportamento registrado foi o ato do ransomware em renomear cada um dos arquivos e o uso de técnicas de criptografia durante a execução do malware.

O primeiro destaque se dá pelo fato do arquivo “winword.doc”, passar a ter outro nome e a extensão. zepto. Essa extensão é uma pista sobre a família do ransomware analisado, que após pesquisa na base de dados do laboratório Trend Micro, mostrou tratar-se de uma variante do já bem conhecido Locky.