6.

Fundamentos da Teoria Geral de Sistemas

Histórico

A teoria de sistemas, cujos primeiros enunciados datam de 1925, foi proposta em 1937 pelo biólogo Ludwig von
Bertalanffy, tendo alcançado o seu auge de divulgação na década de 50. (ALVAREZ, 1990). Em 1956 Ross
Ashby introduziu o conceito na ciência cibernética. A pesquisa de Von Bertalanffy foi baseada numa visão
diferente do reducionismo científico até então aplicada pela ciência convencional. Dizem alguns que foi uma
reação contra o reducionismo e uma tentativa para criar a unificação científica.

Conceito

O Sistema é um conjunto de partes interagentes e interdependentes que, conjuntamente, formam um todo

unitário com determinado objetivo e efetuam determinada função (OLIVEIRA, 2002, p. 35).

Sistema pode ser definido como um conjunto de elementos interdependentes que interagem com objetivos
comuns formando um todo, e onde cada um dos elementos componentes comporta-se, por sua vez, como um
sistema cujo resultado é maior do que o resultado que as unidades poderiam ter se funcionassem
independentemente. Qualquer conjunto de partes unidas entre si pode ser considerado um sistema, desde que
as relações entre as partes e o comportamento do todo sejam o foco de atenção (ALVAREZ, 1990, p. 16).

Sistema é um conjunto de partes coordenadas e não relacionadas, formando um todo complexo ou unitário.

Conceitos fundamentais

Entropia - todo sistema sofre deterioração;

Sintropia, negentropia ou entropia negativa - para que o sistema continue existindo, tem que desenvolver forças
contrárias à Entropia;

Homeostase - capacidade do sistema manter o equilíbrio;

Heterostase - toda vez que há uma ação imprópria (desgaste) do sistema, ele tende a se equilibrar. (OBS: O
"estado de equilíbrio", segundo a lei da entropia, é um pouco diferente do que pode parecer pelo senso comum)

Para as ciências administrativas, o pensamento sistêmico é muito importante pois as organizações envolvem
vários aspectos:

Transformações físicas necessárias à fabricação dos produtos e prestação dos serviços;

Comunicação entre os agentes e colaboradores para desenvolver, produzir e entregar o produto ou serviço
atendendo as expectativas e necessidades do cliente;

Envolvimento das pessoas para que elas se empenhem no processo cooperativo;

Desenvolvimento de competências, habilidades e conhecimentos, para que as pessoas tenham condições de

realizar o trabalho da maneira esperada;

Por esses motivos, as organizações podem ser entendidas como sistemas abertos.

Pensamento

A ciência do século passado adotava a mecânica clássica como modelo do pensamento científico. Isso equivale
a pensar nas coisas como mecanismos e sistemas fechados. A ciência de nossos dias adota o organismo vivo
como modelo, o que equivale a pensar em sistemas abertos.

Sistema
O sistema consiste em uma sistemática fatorial em grupos de influência de ações que fundamentam a Teoria
Sistemática Geral.
Ambiente
O ambiente de um sistema é um conjunto de elementos que não fazem parte do sistema, mas que podem
produzir mudanças no estado do sistema.

Sistemas abertos

Basicamente, a teoria de sistemas afirma que estes são abertos e sofrem interações com o ambiente onde estão
inseridos. Desta forma, a interação gera realimentações que podem ser positivas ou negativas, criando assim
uma auto regulação regenerativa, que por sua vez cria novas propriedades que podem ser benéficas ou
maléficas para o todo independente das partes. Toda organização é um sistema aberto. A empresa é
caracterizada como um Sistema Aberto, pois sofre interações e flutuações de seu ambiente interno
(departamentos, processos, recursos humanos etc.) e do ambiente externo (economia, política, meio ambiente
etc.).

Sistemas fechados

Esses sistemas são aqueles que não sofrem influência nem influenciam o meio ambiente no qual estão
inseridos, de tal forma que ele se alimenta dele mesmo. A entropia apenas se mantém constante nos sistemas
isolados.

Sinergia/entropia

Embora seja possível tentar entender o funcionamento de um carro só olhando as suas partes separadamente,
o observador talvez não consiga compreender o que é um carro só olhando suas peças. É preciso entender de
que forma as diferentes partes do sistema interagem. Essa interação dos elementos do sistema é chamada de
sinergia. A sinergia é o que possibilita um sistema funcionar adequadamente.Por outro lado a entropia (conceito
da física) é a desordem ou ausência de sinergia. Um sistema pára de funcionar adequadamente quando ocorre
entropia interna.

Realimentações

Os organismos (ou sistemas orgânicos) em que as alterações benéficas são absorvidas e aproveitadas
sobrevivem, e os sistemas onde as qualidades maléficas ao todo resultam em dificuldade de sobrevivência,
tendem a desaparecer caso não haja outra alteração de contrabalanço que neutralize aquela primeira mutação.
Assim, de acordo com Ludwig von Bertalanffy, a evolução permanece ininterrupta enquanto os sistemas
se autorregulam.

Um sistema realimentado é necessariamente um sistema dinâmico, já que deve haver uma causalidade
implícita. Em um ciclo de retroação uma saída é capaz de alterar a entrada que a gerou, e, consequentemente,
a si própria. Se o sistema fosse instantâneo, essa alteração implicaria uma desigualdade. Portanto em uma
malha de realimentação deve haver um certo retardo na resposta dinâmica. Esse retardo ocorre devido à uma
tendência do sistema de manter o estado atual mesmo com variações bruscas na entrada. Isto é, ele deve
possuir uma tendência de resistência a mudanças.

Teoria reducionista e teoria sistêmica

Segundo a teoria de sistemas, ao invés de se reduzir uma entidade (um animal, por exemplo.) para o estudo
individual das propriedades de suas partes ou elementos (órgãos ou células), se deve focalizar no arranjo do
todo, ou seja, nas relações entre as partes que se interconectam e interagem orgânica e estatisticamente.

Uma organização realimentada e auto gerenciada, gera assim um sistema cujo funcionamento é independente
da substância concreta dos elementos que a formam, pois estes podem ser substituídos sem dano ao todo, isto
é, a auto-regulação onde o todo assume as tarefas da parte que falhou. Portanto, ao fazermos o estudo de
sistemas que funcionam desta forma, não conseguiremos detectar o comportamento do todo em função das
partes. Exemplos são as partículas de determinado elemento cujo comportamento individual, embora previsto,
não poderá nos indicar a posição ou movimentação do todo.

Interdisciplinaridade

Em biologia temos nas células um exemplo, pois não importa quão profundo seja o estudo individual de
um neurônio do cérebro humano, este jamais indicará o estado de uma estrutura de pensamento, se for
estirpado, ou morrer, também não alterará o funcionamento do cérebro. Uma área emergente da biologia
molecular moderna que se utiliza bastante dos conceitos da Teoria de Sistemas é a Biologia Sistêmica.

Em eletrônica, um transistor numa central telefônica digital, jamais nos dará informações sobre o sistema,
embora sua falha possa causar algum tipo de alteração na rede. Nas modernas centrais, os sinais remetidos a si
serão automaticamente desviados para outro circuito.

Em Sociologia, a movimentação histórica de uma determinada massa humana, por mais que analisemos o
comportamento de um determinado indivíduo isoladamente, jamais conseguiremos prever a condição do todo
numa população. Os mesmos conceitos e princípios que orientam uma organização no ponto de vista sistêmico,
estão em todas as disciplinas, físicas, biológicas, tecnológicas, sociológicas, etc. provendo uma base para a sua
unificação.

Além dos exemplos citados, podemos observar a ação sistêmica no meio-ambiente,

na produção industrial automatizada, em controles e processos, na teoria da informação, entre outros.

Aplicações

Na teorização matemática surgiu o desenvolvimento da isomorfia entre os modelos de circuitos elétricos e outros
sistemas. As aplicações da teoria de sistemas abrangem o desenvolvimento de todos os ramos da ciência.
Alguns exemplos são: engenharia, computação, ecologia, administração, psicoterapia familiar, termodinâmica,
dinâmica caótica, vida artificial, inteligência artificial, redes neurais, modelagem, simulação computacional, jogos
desportivos colectivos e turismo entre outras.

7.1 ETAPAS DE DESENVOLVIMENTO DE SISTEMAS

Introdução

Neste artigo iremos abordar etapas do processo de desenvolvimento de um sistema, deste o contato com o
cliente o levantamento de requisitos até a entrega e manutenção do mesmo.

Etapa de um processo de desenvolvimento constitui-se de metodologias organizadas de forma a auxiliar o

desenvolvimento de um sistema, cada etapa envolve requisitos e situação especifica para atingir um objetivo.
Um processo de desenvolvimento requer algumas etapas bem definidas para organizar o desenvolvimento, cada
passo e dados cumprindo metas criando assim uma metodologia para o desenvolvimento de uma aplicação. As
etapas devem sempre ser revisadas para obter uma melhor qualidade no produto final.

Principais etapas do desenvolvimento de uma aplicação:

Planejamento

Construção

Implantação

Avaliação e Manutenção

Temos também pontos importantes que devem ser ressaltas como, por exemplo, o levantamento de requisitos o
contato com o cliente etc. É sempre importante documentar um projeto de desenvolvimento principalmente em
grandes projetos que envolvam um numero maior de profissionais. A documentação garante a organização e o
registro do andamento do projeto garantindo a qualidade do produto para o cliente.

Planejamento

Para iniciar essa etapa e necessário realizar um levantamento dos requisitos do sistema junto com o cliente,
avaliar os problemas e as necessidades do cliente e documentar o essas informações que serão de grande
importância na elaboração do planejamento.

Pontos importantes:

Identificação do cliente
Identificação dos requisitos

Levantamento dos recursos e custos

Avaliar a viabilidade

Elaboração do cronograma inicial

Após identificarmos o nosso cliente e definirmos os requisitos do sistema que iremos desenvolver, precisamos
avaliar a viabilidade do desenvolvimento e implantação. Após realizar os procedimentos mencionados acima
devemos elaborar o cronograma inicial planejando as etapas e os recursos necessários para finalização do
projeto e a entrega do produto com qualidade garantido a satisfação do cliente.

Requisitos são descrições do que o sistema irá realizar qual o desejo do cliente a sua necessidade, essa o qual
o sistema venha a solucionar. Essa etapa define a finalidade do projeto e resumir a necessidade do cliente. A
identificação consiste em entender em termos de requisitos e o que se espera obter como resultado, esse
procedimento é geralmente realizado junto ao cliente.

É necessário realizar uma analise dos requisitos para tratar e avaliar inconsistências, ambigüidades, riscos e
prioridades dos requisitos indicados na identificação.

Construção

Na construção do sistema é necessário definir níveis de segurança da aplicação, versionamento do código fonte,
construção da aplicação em si, criação de teste, promover carga de testes extremos e avaliação do produto final.
Fazer um levantamento de erros e correções.

Implantação

Realizar a implantação do sistema junto ao cliente, prover treinamentos para os operadores do sistema. Verificar
possíveis problemas e realizar correções da aplicação.

Avaliação e manutenção

Realizar uma avaliação do sistema junto com o cliente para garantir a qualidade do produto, realizar
manutenções sempre que necessário para manter o bom funcionamento da aplicação.

Resumo das Atividades

As fases de execução e respectivas atividades podem ser vistas abaixo:

Fases Atividades

Plano de Execução do Projeto

1. Contato Inicial com o Cliente;

– Obter informações importantes sobre o que o cliente deseja do projeto.

2. Levantamento de Recursos do Projeto;

– Verificar quais recursos pode ser usado no projeto.

3. Cronograma Inicial.

– Elaborar um cronograma de cada etapa com data e metas.

Levantamento de Requisitos

1. Definição do Sistema;

– Definir que tipo de sistema será criado, quais tecnologias serão aplicadas.
2. Identificação dos Requisitos;

– Estudar os requisitos, analisar o projeto.

3. Análise e Classificação dos Requisitos.

– Analisar e classificar os requisitos funcionais e não funcionais.

Casos de Uso

1. Construção do Diagrama de Casos de Uso;

– Elaboração do diagrama do caso de uso, analise das situações de operação do aplicativo.

2. Descrição em Alto Nível;

– Descrever de forma sucinta a especificação essencial de requisitos.

3. Descrição em Nível Detalhado;

– Disponibiliza mais detalhes do que a descrição de alto nível, mostra uma visão geral do requisito.

4. Priorização e Escalonamento dos Casos de Uso.

– Define a ordem dos casos de uso.

Construção Análise

1. Modelo Conceitual de Classes;

– Representação das classes, atributos e campos.

2. Glossário;

– Estrutura de classes

3. Diagramas de Estados/Atividades.

– Visualização das atividades

Projeto

1.Diagramas de Interação;

– Criação e definição da interação entre os objetos

2. Diagrama de Classes do Projeto;

– Estruturas de classes.

3. Esquema do Banco de Dados;

– Estrutura de bancos de dados.

4. Modelo de Arquitetura.

– Estrutura da aplicação.

Implementação

1. Implementação;

– Codificação da aplicação.
2. Segurança.

– Segurança da aplicação.

Testes

1. Testes.

– Realização de testes e cargas extremas.

Implantação

1. Plano de Implantação;

– Desenvolver um plano de implantação da aplicação.

2. Pacote de Entrega ao Cliente;

– Diretrizes de entrega do produto.

3. Treinamento.

– Treinamento da equipe de trabalho.

Avaliação do Cliente/Manutenção

1. Garantia da Qualidade.

– Manutenção da aplicação, avaliação junto ao cliente.

8. Teoria da Informação

Os DADOS são os registros soltos, aleatórios, sem quaisquer análise (Rezende, 2015).
Dados são códigos que constituem a matéria prima da informação, ou seja, é a informação não tratada que
ainda não apresenta relevância. Eles representam um ou mais significados de um sistema que isoladamente
não pode transmitir uma mensagem ou representar algum conhecimento (de Silva, 2007).

A INFORMAÇÃO seria qualquer estruturação ou organização desses dados.

Ela é um registro, em suporte físico ou intangível, disponível à assimilação crítica para produção de
conhecimento (LE COADIC, 1996).
Informação é, portanto, o material de que é feito o conhecimento, após posicionamento crítico do indivíduo. Além
disso, a informação é derivada dos dados que, sem um sentido ou contexto, significam muito pouco.
Informação não é Conhecimento, informação é diferente de Conhecimento. A informação (matéria-prima para
o conhecimento) é um bem comum ao qual todo cidadão deve ter direito/acesso, levando à socialização da
informação, das oportunidades e do poder (Rezende, 2014).

E o CONHECIMENTO?
Numa definição muito simples, o Conhecimento é a informação processada e transformada em experiência pelo
indivíduo. O conhecimento é a capacidade que, o processamento da informação adicionado ao repertório
individual, nos dá, de agir e prever o resultado dessa ação. Aprendizagem seria, então, toda exposição a novas
informações que, a partir dai, modificam o nosso comportamento e relacionamento com o meio-ambiente que
nos rodeie.
Se informação é dado trabalhado, então conhecimento é informação trabalhada (da Silva, 2007).

Conceitos de segurança

A maioria das definições de Segurança da Informação (SI) (Brostoff, 2004; Morris e Thompson, 1979; Sieberg,
2005; Smith, 2002) pode ser sumarizada como a proteção contra o uso ou acesso não-autorizado à informação,
bem como a proteção contra a negação do serviço a usuários autorizados, enquanto a integridade e a
confidencialidade dessa informação são preservadas. A SI não está confinada a sistemas de computação, nem
à informação em formato eletrônico. Ela se aplica a todos os aspectos de proteção da informação ou dados, em
qualquer forma. O nível de proteção deve, em qualquer situação, corresponder ao valor dessa informação e aos
prejuízos que poderiam decorrer do uso impróprio da mesma. É importante lembrar que a SI também cobre toda
a infraestrutura que permite o seu uso, como processos, sistemas, serviços, tecnologias, e outros.

A Segurança da informação refere-se à proteção existente sobre as informações de uma determinada empresa
ou pessoa, isto é, aplica-se tanto às informações corporativas quanto às pessoais. Entende-se
por informação todo e qualquer conteúdo ou dado que tenha valor para alguma organização ou pessoa. Ela
pode estar guardada para uso restrito ou exposta ao público para consulta ou aquisição.

Podem ser estabelecidas métricas (com o uso ou não de ferramentas) para a definição do nível de segurança
existente e, com isto, serem estabelecidas as bases para análise da melhoria ou piora da situação de segurança
existente. A segurança de uma determinada informação pode ser afetada por fatores comportamentais e de uso
de quem se utiliza dela, pelo ambiente ou infraestrutura que a cerca ou por pessoas mal intencionadas que têm
o objetivo de furtar, destruir ou modificar tal informação.

A tríade CIA (Confidentiality, Integrity and Availability) — Confidencialidade, Integridade e Disponibilidade —

representa os principais atributos que, atualmente, orientam a análise, o planejamento e a implementação da
segurança para um determinado grupo de informações que se deseja proteger. Outros atributos importantes são
não-repúdio (irretratabilidade), autenticidade e conformidade. Com a evolução do comércio eletrônico e da
sociedade da informação, a privacidade é também uma grande preocupação.

Portanto os atributos básicos da segurança da informação, segundo os padrões internacionais

(ISO/IEC 17799:2005) são os seguintes:

Confidencialidade: propriedade que limita o acesso a informação tão somente às entidades legítimas, ou seja,
àquelas autorizadas pelo proprietário da informação;

Integridade: propriedade que garante que a informação manipulada mantenha todas as características originais
estabelecidas pelo proprietário da informação, incluindo controle de mudanças e garantia do seu ciclo de vida
(Corrente, intermediária e permanente). O ciclo de vida da informação orgânica - criada em ambiente
organizacional - segue as três fases do ciclo de vida dos documentos de arquivos; conforme preceitua os
canadenses da Universidade do Quebec (Canadá): Carol Couture e Jean Yves Rousseau, no livro Os
Fundamentos da Disciplina Arquivística;

Disponibilidade: propriedade que garante que a informação esteja sempre disponível para o uso legítimo, ou
seja, por aqueles usuários autorizados pelo proprietário da informação;

Autenticidade: propriedade que garante que a informação é proveniente da fonte anunciada e que não foi alvo
de mutações ao longo de um processo;

Irretratabilidade ou não repúdio: propriedade que garante a impossibilidade de negar a autoria em relação a uma
transação anteriormente feita;

Conformidade: propriedade que garante que o sistema deve seguir as leis e regulamentos associados a este
tipo de processo.

Mecanismos de segurança

O suporte para as recomendações de segurança pode ser encontrado em:

Controles físicos: são barreiras que limitam o contato ou acesso direto a informação ou a infraestrutura (que
garante a existência da informação) que a suporta. Mecanismos de segurança que apoiam os controles físicos:
portas, trancas, paredes, blindagem, guardas, etc.

Controles lógicos: são barreiras que impedem ou limitam o acesso a informação, que está em ambiente
controlado, geralmente eletrônico, e que, de outro modo, ficaria exposta a alteração não autorizada por elemento
mal intencionado. Mecanismos de segurança que apoiam os controles lógicos:

Mecanismos de cifração ou encriptação: permitem a transformação reversível da informação de forma a torná-

la ininteligível a terceiros. Utiliza-se para tal, algoritmos determinados e uma chave secreta para, a partir de um
conjunto de dados não criptografados, produzir uma sequência de dados criptografados. A operação inversa é a
decifração.

Assinatura digital: Um conjunto de dados criptografados, associados a um documento do qual são função,
garantindo a integridade e autenticidade do documento associado, mas não a sua confidencialidade.

Mecanismos de garantia da integridade da informação: usando funções de "Hashing" ou de checagem, é

garantida a integridade através de comparação do resultado do teste local com o divulgado pelo autor.

Mecanismos de controle de acesso: palavras-chave, sistemas biométricos, firewalls, cartões inteligentes.

Mecanismos de certificação: atesta a validade de um documento.

Honeypot: é uma ferramenta que tem a função de propositalmente simular falhas de segurança de um sistema
e colher informações sobre o invasor enganando-o, fazendo-o pensar que esteja de fato explorando uma
vulnerabilidade daquele sistema. É uma espécie de armadilha para invasores. O honeypot não oferece nenhum
tipo de proteção.

Protocolos seguros: uso de protocolos que garantem um grau de segurança e usam alguns dos mecanismos
citados aqui.

Atualmente existe uma grande variedade de ferramentas e sistemas que pretendem fornecer segurança. Alguns
exemplos: antivírus, firewalls, filtros anti-spam, fuzzers, detectores de intrusões (IDS), analisadores de código,
etc.[2]

Ameaças à segurança

As ameaças à segurança da informação são relacionadas diretamente à perda de uma de suas três principais
características, quais sejam:

Perda de confidencialidade: há uma quebra de sigilo de uma determinada informação (ex: a senha de um
usuário ou administrador de sistema) permitindo que sejam expostas informações restritas as quais seriam
acessíveis apenas por um determinado grupo de usuários.

Perda de integridade: determinada informação fica exposta a manuseio por uma pessoa não autorizada, que
efetua alterações que não foram aprovadas e não estão sob o controle do proprietário (corporativo ou privado)
da informação.

Perda de disponibilidade: a informação deixa de estar acessível por quem necessita dela. Seria o caso da perda
de comunicação com um sistema importante para a empresa, que aconteceu com a queda de um servidor ou de
uma aplicação crítica de negócio, que apresentou uma falha devido a um erro causado por motivo interno ou
externo ao equipamento ou por ação não autorizada de pessoas com ou sem má intenção.

No caso de ameaças à rede de computadores ou a um sistema, estas podem vir de agentes maliciosos, muitas
vezes conhecidos como crackers, (hackers não são agentes maliciosos, pois tentam ajudar a encontrar
possíveis falhas). Os crackers são motivados a fazer esta ilegalidade por vários motivos, dentre eles:
notoriedade, autoestima, vingança e enriquecimento ilícito. De acordo com pesquisa elaborada pelo Computer
Security Institute, mais de 70% dos ataques partem de usuários legítimos de sistemas de informação (insiders),
o que motiva corporações a investir largamente em controles de segurança para seus ambientes corporativos
(intranet).

Representação de dados

Acredita-se que a criação de números veio com a necessidade de contar, seja o número de animais, alimentos,
ou coisas do gênero. Como a evolução nos legou algumas características, como os cinco dedos em cada mão e
cinco dedos em cada pé, seria muito natural que os primeiros sistemas de numeração fizessem uso das bases
10 (decimal) e 20 (vigesimal). O número 80 em francês, por exemplo, escrito como quatre-vingt (ou, quatro
vezes o vinte), é remanescente de um sistema vigesimal. Computadores modernos, por outro lado, usam
“chaves elétricas” para representar números e caracteres. Cada chave pode estar ligada ou desligada e a
combinação dos estados de um conjunto destas chaves representa algo (número ou caracter). Visto que o
“cérebro” de um computador é simplesmente um conjunto de chaves elétricas, onde cada chave possui apenas
dois estados possíveis (ligada/desligada), computadores “pensam” usando apenas 2 dígitos: 0 e 1 (0 para
desligada e 1 para ligada). Portanto, computadores se utilizam de uma forma de representação de dados para
descrever números e caracteres na forma de um conjunto de 0s e 1s. Linguagens humanas usam palavras que
contêm um número variável de caracteres. Computadores não possuem a capacidade de trabalhar com palavras
de tamanho variável. Por isso, suas “palavras” (representação de caracteres e números) têm um número
predeterminado de caracteres, que, na linguagem binária, são chamados de bits (binary digits). Os primeiros
computadores pessoais que se tornaram populares usavam 8 bits (1 byte- binary term) para representar uma
“palavra”. Assim, o computador sabia onde começava uma palavra e onde ela acabava apenas contando o
número de bits. A partir da evolução dos computadores, as “palavras” evoluíram para 16 bits (PC 286), 32 bits
(PC 386-Pentium) e 64 bits (maioria dos computadores de hoje). Dessa forma, uma “palavra” do computador
passou a não ser mais composta apenas por um byte, mas por 2, 4 e agora 8 bytes. Essa evolução permitiu que
cada vez mais coisas pudessem ser representadas através das palavras do computador, aumentando o número
de instruções inteligíveis por ele.

Inteligência

Etimologia

Latim intellectus[3], de intelligere = inteligir, entender, compreender. Composto de íntus = dentro e lègere =
recolher, escolher, ler (cfr. intendere[4]).

Definições

Existem dois "consensos" de definição de inteligência. O primeiro, de Intelligence: Knowns and Unknowns, um
relatório de uma equipe congregada pela Associação Americana de Psicologia, em 1995:

"Os indivíduos diferem na habilidade de entender ideias complexas, de se adaptarem com eficácia ao ambiente,
de aprenderem com a experiência, de se engajarem nas várias formas de raciocínio, de superarem obstáculos
mediante o pensamento. Embora tais diferenças individuais possam ser substanciais, nunca são completamente
consistentes: o desempenho intelectual de uma dada pessoa vai variar em ocasiões distintas, em domínios
distintos, a se julgar por critérios distintos. Os conceitos de 'inteligência' são tentativas de aclarar e organizar
esse conjunto complexo de fenômenos."

Uma segunda definição de inteligência vem de Mainstream Science on Intelligence, que foi assinada por
cinquenta e dois pesquisadores em inteligência, em 1994:

"uma capacidade mental bastante geral que, entre outras coisas, envolve a habilidade de raciocinar, planejar,
resolver problemas, pensar de forma abstrata, compreender ideias complexas, aprender rápido e aprender com
a experiência. Não é uma mera aprendizagem literária, uma habilidade estritamente acadêmica ou um talento
para sair-se bem em provas. Ao contrário disso, o conceito refere-se a uma capacidade mais ampla e mais
profunda de compreensão do mundo à sua volta - 'pegar no ar', 'pegar' o sentido das coisas ou 'perceber' uma
coisa."

Herrnstein e Murray: "...habilidade cognitiva".

Sternberg e Salter: "...comportamento adaptativo orientado a metas".

Saulo Vallory: "...habilidade de intencionalmente reorganizar informações para inferir novos conhecimentos".

9. BANCO DE DADOS

9.1 Base de dados, documentação e prototipação.

O que é uma base de dados?

Uma base de dados é um simples repositório de informação relacionado com determinado assunto ou finalidade,
ou seja, é uma colecção de dados ou itens informação estruturados de determinada maneira que permite a sua
consulta, actualização e outros tipos de operação processados por meios informáticos.

Uma base de dados é uma colecção de informação relacionada entre si, à volta de um determinado tema ou
domínio

Para que serve a Base de Dados?

Serve para gerir vastos conjuntos de informação de modo a facilitar a organização, manutenção e pesquisa de
dados.

Ciclo de vida de uma base dados

1.Planeamento

Levantamento das necessidades, organizar e planear;

2. Recolha de requisitos

Elaboração de um documento com os objectivos que o projecto visa atingir;

3. Desenho conceptual (desenhar as tabelas)

Desenho de todos os modos de vista externos da aplicação da base de dados. O aspecto dos formulários,
relatórios, ecrãs de entradas de dados, etc;

4. Desenho lógico

A partir do desenho conceptual cria-se o desenho lógico da aplicação e da base de dados;

5. Desenho físico

Durante a fase do desenho físico, o desenho lógico, é mapeado ou convertido para sistemas de software que
serão utilizados na implementação da aplicação e na base de dados;

6. Construção

As unidades de programação são promovidas para o sistema de ambiente teste, onde toda a aplicação e base
de dados é montada e testada;

7. Implementação

Instalação e colocação em funcionamento da nova aplicação e base de dados;

8. Manutenção

Resolver quaisquer situações de anomalias ou erros, normalmente designados por “bugs”, quer ao nível da
aplicação, quer ao nível da base de dados.

Operações típicas de trabalho com Base de dados

· Operações de definição e alteração da estrutura de uma base de dados

· Operações de manipulação de dados, sem alteração da estrutura da base de dados

· Operações de controlo dos dados

Documentação

Ao término do desenvolvimento há a elaboração de um documento que traz detalhes sobre o código para que
qualquer alteração, atualização ou implementação possa ser feita por qualquer outro desenvolvedor no futuro.
Nessa etapa, há também a criação dos manuais de instalação e de utilização para auxílio aos usuários de forma
instrutiva.

9.2 Modelagem conceitual: abstração, modelo entidade-relacionamento, análise funcional e

administração de dados.

Modelagem Conceitual

O objetivo aqui é criar um modelo conceitual de forma gráfica, sendo este chamado de Diagrama Entidade e
Relacionamento (DER), que identificará todas as entidades e relacionamentos de uma forma global. Aqui é
evitado qualquer detalhamento específico do modelo de BD.

O modelo conceitual mais utilizado é o de ER, que é ajudado pelo DER, que na prática, constitui o modelo
básico do BD. Este é utilizado para representar graficamente o esquema conceitual.

Através deste modelo, teremos uma visão de cima (macro) compreendida de modo relativamente fácil sobre o
ambiente de dados. Também é independente de hardware ou software, ou seja, não depende de nenhum SGBD
utilizado para implantá-lo. Por tanto, qualquer alteração no software ou hardware, não terão efeito no nível
conceitual.

A modelo ou modelagem conceitual trata da descrição da semântica de aplicativos de software em um alto nível
de abstração. Especificamente, modeladores conceituais descrevem modelos de estrutura em termos de
entidades, relacionamentos e restrições[1]; descrevem modelos comportamentais ou funcionais em termos de
estados, transições entre estados e ações executadas em estados e transições [2]; e descrevem interações e
interfaces de usuário em termos de mensagens enviadas e recebidas e informações trocadas [3]. Alguns modelos
são objetos físicos; por exemplo, um modelo de um brinquedo que pode ser montado e pode ser feito para
funcionar como o objeto que representa. O termo modelo conceitual também pode ser usado para se referir a
modelos que são formados após um processo de conceituação ou generalização[4].

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 Software para 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.

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á a necessidade de associar uma entidade a um
relacionamento existente. Na modelagem Entidade-Relacionamento não é possível que um relacionamento seja
associado a uma entidade, então tornamos esse relacionamento uma entidade associativa, que a partir daí
poderá se relacionar com outras entidades. Para melhor compreender esse conceito, tomemos como exemplo
uma aplicação de vendas em que existem as entidades Produto e Venda, que se relacionam na forma muitos-
para-muitos, uma vez que em uma venda pode haver vários produtos e um produto pode ser vendido várias
vezes (no caso, unidades diferentes do mesmo produto). Em determinado momento, a empresa passou a
entregar brindes para os clientes que comprassem um determinado produto. A entidade Brinde, então, está
relacionada não apenas com a Venda, nem com o Produto, mas sim com o item da venda, ou seja, com o
relacionamento entre as duas entidades citadas anteriormente. Como não podemos associar a entidade Brinde
com um relacionamento, criamos então a entidade associativa "Item da Venda", que contém os atributos
identificadores das entidades Venda e Produto, além de informações como quantidade e número de série, para
casos específicos. A partir daí, podemos relacionar o Brinde com o Item da Venda, indicando que aquele prêmio
foi dado ao cliente por comprar aquele produto especificamente.

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
3ilustra um exemplo desse tipo.

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

Administração de dados

administração de dados tem como missão manter atualizados os modelos de dados corporativos, bem como
harmonizar as setorizações decorrentes da interpretação dos mesmos de forma a manter os modelos, as
estruturas lógicas e físicas dos dados, mantendo-os consistentes de acordo com as regras de negócio definidas
pela organização, independente da tecnologia e da plataforma a ser utilizada. Cabe ainda a administração de
dados, garantir a qualidade da informação considerando a utilidade da mesma para os diversos setores da
empresa, bem como, participar da avaliação de soluções de automação sempre que isto interfira na produção e
na utilização da informação, monitorando a implementação dos modelos e conferindo a qualidade do conteúdo
das bases de dados, garantindo assim a adequação das mesmas aos objetivos da organização.

A administração de dados abrange todo o sistema de informação e não apenas os subsistemas automáticos de
processamento de dados. O seu principal objetivo é a estratégia de negócio, e os reflexos desta nos requisitos
de informação, e não a tecnologia em si.

9.3 Dados estruturados e não estruturados.

Entender a diferença entre eles pode significar o bom andamento do seu projeto de gestão de documentos e
informações. A tecnologia existente hoje é completamente confiável, mas os softwares e plataformas apenas
ajudam a organizar. Tornar o projeto viável depende de conhecer conceitos e a própria cultura do ambiente
corporativo. De acordo com estudos, 80% do conteúdo produzido em uma empresa normal é em formato não
estruturado. Mas o que isso significa e qual a diferença para um estruturado.

Não estruturados
Os bancos de dados em geral não contêm todas as informações possíveis sobre algo lá guardado. Um dado é
uma forma organizada de informação, mas ela ocorre desde que campos específicos sejam preenchidos para
que a recuperação deles se dê de forma automatizada. Mas documentos de texto, por exemplo, não são
enxergados em toda sua amplitude. Seria inviável classificar cada palavra do texto e relacioná-las com
contextos, momentos, pessoas, citações, etc. Isso é pior para vídeos e audios. Em redes sociais, quando as
pessoas colocam suas emoções no que escrevem, tudo fica ainda mais impossível. Imagine que você entrou em
uma sala de um colecionador. O acervo está etiquetado e organizado. Mas não se pode ter uma ideia completa
do significado daquilo tudo de uma forma automática.

Estruturados
São dados que contém uma organização para serem recuperados. É como se fossem etiquetas, linhas e
colunas que identificam diversos pontos sobre aquela informação e tornam o trabalho da tecnologia bem
simplificado. A maioria das empresas trabalha com eles há décadas. Embora não sejam a maior fatia do
conteúdo produzido, eles são o que existe – ou existia – de melhor para tirar conclusões e fazer processos
fluírem.

Há uma certa discussão sobre a validade desses conceitos já que dados não estruturados possuem alguma
estruturação intrínseca. Na realidade, essa separação ocorre porque a tecnologia existente é que enxerga
assim. Para nós, tudo é informação e é relevante ou não. Quem sabe um dia esses termos não acabam sendo
substituídos por outros ou apenas virem informação.

9.4 Banco de dados relacionais: conceitos básicos e características.

9.5 Chaves e relacionamentos.

Banco de dados relacional

Um banco de dados relacional é um banco de dados que modela os dados de uma forma que eles sejam
percebidos pelo usuário como tabelas, ou mais formalmente relações.

O termo é aplicado aos próprios dados, quando organizados dessa forma, ou a um Sistema Gerenciador de
Banco de Dados Relacional (SGBDR) – do inglês Relational database management system (RDBMS) – um
programa de computador que implementa a abstração.

Histórico

Os Bancos de dados relacionais (BDR) surgiram em meados da década de 1970. Porém, apenas alguns anos
mais tarde as empresas passaram a utilizá-los no lugar de arquivos simples (do inglês flat file), bancos de dados
hierárquicos e em rede.

As 13 regras

Em 1985, Edgar Frank Codd, criador do modelo relacional, publicou um artigo onde definia 13 regras para que
um Sistema Gerenciador de Banco de Dados (SGBD) fosse considerado relacional:

Regra Fundamental:

Um SGBD relacional deve gerir os seus dados usando apenas suas capacidades relacionais

Regra da informação:
Toda informação deve ser representada de uma única forma, como dados em uma tabela

Regra da garantia de acesso:

Todo o dado (valor atómico) pode ser acedido logicamente (e unicamente) usando o nome da tabela, o valor
da chave primária da linha e o nome da coluna.

Tratamento sistemático de valores nulos:

Os valores nulos (diferente do zero, da string vazia, da string de caracteres em brancos e outros valores não
nulos) existem para representar dados não existentes de forma sistemática e independente do tipo de dado.

Catálogo dinâmico on-line baseado no modelo relacional:

A descrição do banco de dados é representada no nível lógico como dados ordinários (isto é, em tabelas),
permitindo que usuários autorizados apliquem as mesmas formas de manipular dados aplicada aos dados
comuns ao consultá-las.

Regra da sub-linguagem abrangente:

Um sistema relacional pode suportar várias linguagens e formas de uso, porém deve possuir ao menos uma
linguagem com sintaxe bem definida e expressa por cadeia de caracteres e com habilidade de apoiar a definição
de dados, a definição de visões, a manipulação de dados, as restrições de integridade, a autorização e a
fronteira de transações.

Regra da atualização de visões:

Toda visão que for teoricamente atualizável será também atualizável pelo sistema.

Inserção, atualização e eliminação de alto nível:

Qualquer conjunto de dados que pode ser manipulado com um único comando para retornar informações,
também deve ser manipulado com um único comando para operações de inserção, atualização e exclusão.
Simplificando, significa dizer que as operações de manipulação de dados devem poder ser aplicadas a várias
linhas de uma vez, ao invés de apenas uma por vez.

Independência dos dados físicos:

Programas de aplicação ou atividades de terminal permanecem logicamente inalteradas quaisquer que sejam as
modificações na representação de armazenagem ou métodos de acesso internos.

Independência lógica de dados

Programas de aplicação ou atividades de terminal permanecem logicamente inalteradas quaisquer que sejam as
mudanças de informação que permitam teoricamente a não alteração das tabelas base.

Independência de integridade:

As relações de integridade específicas de um banco de dados relacional devem ser definidas em uma sub-
linguagem de dados e armazenadas no catálogo (e não em programas).

Independência de distribuição:

A linguagem de manipulação de dados deve possibilitar que as aplicações permaneçam inalteradas estejam os
dados centralizados ou distribuídos fisicamente.

Regra da Não-subversão:

Se o sistema relacional possui uma linguagem de baixo nível (um registro por vez), não deve ser possível
subverter ou ignorar as regras de integridade e restrições definidas no alto nível (muitos registros por vez).

Por que usar um Banco de Dados Relacional?

Os Bancos de Dados Relacionais foram desenvolvidos para prover acesso facilitado aos dados, possibilitando
que os usuários utilizassem uma grande variedade de abordagens no tratamento das informações. Pois,
enquanto em um banco de dados hierárquico os usuários precisam definir as questões de negócios de maneira
específica, iniciando pela sua raiz , nos Bancos de Dados Relacionais os usuários podem fazer perguntas
relacionadas aos negócios por meio de vários pontos. A linguagem padrão dos Bancos de Dados Relacionais é
a Structured Query Language, ou simplesmente SQL, como é mais conhecida.

O Modelo Relacional

Um Banco de Dados Relacional segue o Modelo Relacional.

A arquitetura de um banco de dados relacional pode ser descrita de maneira informal ou formal. Na descrição
informal estamos preocupados com aspectos práticos da utilização e usamos os termos tabela, linha e coluna.
Na descrição formal estamos preocupados com a semântica formal do modelo e usamos termos como relação
(tabela), tupla(linhas) e atributo(coluna).

O modelo relacional é um modelo de dados representativo (ou de implementação), adequado a ser o modelo
subjacente de um Sistema Gerenciador de Banco de Dados (SGBD), que se baseia no princípio de que todos os
dados estão armazenados em tabelas (ou, matematicamente falando, relações). Toda sua definição é teórica e
baseada na lógica de predicados e na teoria dos conjuntos.

O conceito foi criado por Edgar Frank Codd em 1970, sendo descrito no artigo "Relational Model of Data for
Large Shared Data Banks". Na verdade, o modelo relacional foi o primeiro modelo de dados descrito
teoricamente, os bancos de dados já existentes passaram então a ser conhecidos como (modelo
hierárquico, modelo em rede ou Codasyl e modelo de listas invertidas).

O modelo relacional para gerência de bases de dados (SGBD) é um modelo de dados baseado em lógica e
na teoria de conjuntos.

Em definição simplificada, o modelo baseia-se em dois conceitos: conceito de entidade e relação - Uma entidade
é um elemento caracterizado pelos dados que são recolhidos na sua identificação vulgarmente designado por
tabela. Na construção da tabela identificam-se os dados da entidade. A atribuição de valores a uma entidade
constrói um registro da tabela. A relação determina o modo como cada registro de cada tabela se associa a
registros de outras tabelas.

Historicamente ele é o sucessor do modelo hierárquico e do modelo em rede. Estas arquiteturas antigas são até
hoje utilizadas em alguns data centers com alto volume de dados, onde a migração é inviabilizada pelo custo
que ela demandaria; existem ainda os novos modelos baseados em orientação ao objeto, que na maior parte
das vezes são encontrados como kits em linguagem formal.

O modelo relacional foi inventado pelo Frank Codd e subsequentemente mantido e aprimorado por Chris
Date e Hugh Darwen como um modelo geral de dados. No Terceiro Manifesto (1995) eles mostraram como o
modelo relacional pode ser estendido com características de orientação a objeto sem comprometer os seus
princípios fundamentais.

A linguagem padrão para os bancos de dados relacionais, SQL, é apenas vagamente remanescente do modelo
matemático. Atualmente ela é adotada, apesar de suas restrições, porque ela é antiga e muito mais popular que
qualquer outra linguagem de banco de dados.

A principal proposição do modelo relacional é que todos os dados são representados como relações
matemáticas, isto é, um subconjunto do produto Cartesiano de n conjuntos. No modelo matemático
(diferentemente do SQL), a análise dos dados é feita em uma lógica de predicados de dois valores (ou seja, sem
o valor nulo); isto significa que existem dois possíveis valores para uma proposição: verdadeira ou falsa. Os
dados são tratados pelo cálculo relacional ou álgebra relacional.

O modelo relacional permite ao projetista criar um modelo lógico consistente da informação a ser armazenada.
Este modelo lógico pode ser refinado através de um processo de normalização. Um banco de dados construído
puramente baseado no modelo relacional estará inteiramente normalizado. O plano de acesso, outras
implementações e detalhes de operação são tratados pelo sistema DBMS, e não devem ser refletidos no modelo
lógico. Isto se contrapõe à prática comum para DBMSs SQL nos quais o ajuste de desempenho frequentemente
requer mudanças no modelo lógico.

Os blocos básicos do modelo relacional são o domínio, ou tipo de dado. Uma tupla é um conjunto
de atributos que são ordenados em pares de domínio e valor. Uma relvar (variável relacional) é um conjunto de
pares ordenados de domínio e nome que serve como um cabeçalho para uma relação. Uma relação é um
conjunto desordenado de tuplas. Apesar destes conceitos matemáticos, eles correspondem basicamente aos
conceitos tradicionais dos bancos de dados. Uma relação é similar ao conceito de tabela e uma tupla é similar
ao conceito de linha.

O princípio básico do modelo relacional é o princípio da informação: toda informação é representada

por valores em relações (relvars). Assim, as relvars não são relacionadas umas às outras no momento do
projeto. Entretanto, os projetistas utilizam o mesmo domínioem vários relvars, e se um atributo é dependente de
outro, esta dependência é garantida através da integridade referencial.

Tabelas (ou relações, ou entidades

Todos os dados de um banco de dados relacional (BDR) são armazenados em tabelas. Uma tabela é uma
simples estrutura de linhas e colunas. Em uma tabela, cada linha contém um mesmo conjunto de colunas. Em
um banco de dados podem existir uma ou centenas de tabelas, sendo que o limite pode ser imposto tanto pela
ferramenta de software utilizada, quanto pelos recursos de hardware disponíveis no equipamento.

As tabelas associam-se entre si por meio de regras de relacionamentos, que consistem em associar um ou
vários atributos de uma tabela com um ou vários atributos de outra tabela.

Exemplo: A tabela funcionário relaciona-se com a tabela cargo. Por este relacionamento, esta última tabela
fornece a lista de cargos para a tabela funcionário.

Modelo teórico usado para representar conceitualmente um BD, Idealizado por Codd (1970). Baseado numa
estrutura de dados simples chamada relação. É o modelo mais amplamente usado, principalmente em
aplicações convencionais de BD.

Registros (ou tuplas

Cada linha formada por uma lista ordenada de colunas representa um registro, ou tupla. Os registros não
precisam conter informações em todas as colunas, podendo assumir valores nulos quando assim se fizer
necessário.

Resumidamente, um registro é uma instância de uma tabela, ou entidade. O start da modelagem se dá a partir
das ENTIDADES. Uma entidade é uma representação de um conjunto de informações sobre determinado
conceito do sistema. Toda entidade possui ATRIBUTOS, que são as informações que referenciam a entidade.
Para exemplificar no sistema de controle de Biblioteca, partimos do conceito principal que é o empréstimo de
obras por usuários da biblioteca. A partir deste conceito inicial, vamos ramificando e descobrindo novos
conceitos. Podemos iniciar nosso raciocínio da seguinte forma:

"Uma biblioteca possui Obras literárias que podem ser tomadas em empréstimos pelos usuários credenciados."

Podemos rapidamente enxergar um cadastro de livros, um cadastro de usuários e um registro de empréstimos,

certo? É essa visão que temos que ter ao modelarmos um banco, isto é, devemos detectar as informações que
devemos armazenar.

Para identificar se aquele conceito pode ser uma entidade você deve apenas se perguntar: "Eu desejo
armazenar quais informações sobre este conceito ?" Se houver informações a serem armazenadas, você tem
uma ENTIDADE. Exemplificando: Eu desejo armazenar os seguintes dados do livro: Título, Autor, Editora, Ano,
Edição e Volume. Temos então a entidade Livro.

Exemplo: O empregado Pedro é uma instância (registro) da tabela funcionário, e a função Analista Comercial é a
instância (registro) da tabela cargo. Uma associação entre estas duas tabelas criaria a seguinte instância de
relacionamento: Pedro é Analista Comercial, onde o verbo ser representa uma ligação entre os registros
distintos.

Colunas (atributos

As colunas de uma tabela são também chamadas de atributos. Ex.: O campo Nome, ou
endereço de uma tabela de um BD relacional.

Chave

As tabelas relacionam-se umas as outras através de chaves. Uma chave é um conjunto de um ou mais atributos
que determinam a unicidade de cada registro.

Por exemplo, se um banco de dados tem como chaves Código do Produto e ID Sistema, sempre que acontecer
uma inserção de dados o sistema de gerenciamento de banco de dados irá fazer uma consulta para identificar
se o registro já não se encontra gravado na tabela. Neste caso, um novo registro não será criado, resultando
esta operação apenas da alteração do registro existente.

A unicidade dos registros, determinada por sua chave, também é fundamental para a criação dos índices.

Temos dois tipos de chaves:

Chave primária: (PK - Primary Key) é um identificador exclusivo de todas as informações de cada registro
dando-lhe unicidade. A chave primária nunca se repetirá. [1]

Chave Estrangeira: (FK - Foreign Key) é a chave formada através de um relacionamento com a chave primária
de outra tabela. Define um relacionamento entre as tabelas e pode ocorrer repetidas vezes. Caso a chave
primária seja composta na origem, a chave estrangeira também o será.

Relacionamentos

Ver artigo principal: Modelo de Entidades e Relacionamentos

Com o advento do Modelo de Entidades e Relacionamentos foi causada uma confusão entre os
termos relação e relacionamento

O Modelo Relacional, quando descrito de forma matemática, é definido como um modelo formado por relações
(no sentido matemático) entre os domínios. Cada tupla é um elemento do conjunto relação.

Ou seja, a relação é a tabela.

Um relacionamento do Modelo de Entidades e Relacionamentos é uma associação entre entidades distintas.

Não há relação direta entre o nome relacionamento e o nome relação.

Porém, um relacionamento, do Modelo de Entidades e Relacionamentos é traduzido para a criação de atributos

com chaves externas do Modelo Relacional. Esta tradução é feita ligando-se um campo de uma tabela X com
um campo de uma tabela Y, por meio da inclusão do campo chave da tabela Y como um campo (conhecido
como chave estrangeira) da tabela X.

Por meio das chaves estrangeiras, é possível implementar restrições nos SGBDR.

Existem alguns tipos de relacionamentos possíveis no MER:

Um para um (1 para 1) - indica que as tabelas têm relação unívoca entre si. Você escolhe qual tabela vai
receber a chave estrangeira;

Um para muitos (1 para N) - a chave primária da tabela que tem o lado 1 está para ir para a tabela do lado N. No
lado N ela é chamada de chave estrangeira;

Muitos para muitos (N para N) - quando tabelas têm entre si relação n..n, é necessário criar uma nova tabela
com as chaves primárias das tabelas envolvidas, ficando assim uma chave composta, ou seja, formada por
diversos campos-chave de outras tabelas. A relação então se reduz para uma relação 1..n, sendo que o lado n
ficará com a nova tabela criada.

Os relacionamentos 1 para 1 e 1 para N podem ser mapeados diretamente em chaves estrangeiras nas tabelas
originais. Já o relacionamento N para N exige o uso de uma tabela auxiliar. No relacionamento N:N não há
chave estrangeira.

Modelagem

Normalização

A normalização de dados é um processo que simplifica grupos complexos de dados para evitar redundâncias e
possibilitar um maior desempenho nas pesquisas.[1]

É o processo de organização eficiente dos dados dentro de um banco de dados cujos objetivos principais são:

Eliminar dados redundantes (por exemplo, armazenando os mesmos dados em mais de uma tabela).

Garantir que as dependências entre os dados façam sentido (armazenando apenas dados logicamente
relacionados em uma tabela).

Existem cinco estágios de normalização, 1º, o 2º, o 3º, o 4º e o 5º. Para um banco de dados se encontrar em
cada um desses estágios ou formas (denominadas formas normais), cada uma de suas tabelas deve atender a
alguns pré-requisitos. Os pré-requisitos são cumulativos, isto é, para alcançar a 3ª forma normal (3NF), um
banco de dados precisa atender aos pré-requisitos das 1ª e 2ª formas normais, acrescidos dos requisitos
exclusivos da 3NF.

Dependência Funcional

Um atributo B possui uma dependência funcional do atributo A se, para cada valor do atributo A, existe
exatamente um único valor do atributo B. A dependência funcional é representada por A → B.

Exemplo: Observe os conjuntos:

Cliente

CPF Nome

1 José

2 João

3 Gabriel

4 M. Guedes

Observe que existe uma dependência entre os valores dos conjuntos, ou seja, nome é função do CPF, se eu
estiver com numero do CPF, poderei encontrar o nome da pessoa correspondente.

Essa dependência é expressa por:

CPF → Nome

Leia da seguinte maneira: - com um número de CPF posso encontrar nome da pessoa, ou - nome depende da
funcionalidade do CPF.

Primeira Forma Normal (FN1)

Uma relação está na primeira forma normal (1FN) se os valores de seus atributos são atômicos (simples,
indivisíveis) e monovalorados. Em outras palavras, FN1 não permite “relações dentro de relações” ou “relações
como atributos de tuplas”[2]. Uma tabela está na primeira forma normal quando seus atributos não contêm
grupos de repetição, ou seja, multivalorados.

Exemplo:

Cliente

ClienteID Nome Telefone

123 Rachel Ingram 555-861-2025

555-403-1659
456 James Wright
555-776-4100

789 Maria Fernandez 555-808-9633

Esta tabela logo acima não está na primeira forma normal porque apresenta grupos de repetição (possibilidade
de mais de um telefone por cliente).

Já estas tabelas logo abaixo, Cliente e Telefone, estão na primeira forma normal.

Tabela Cliente:

Cliente

ClienteID Nome

123 Rachel

456 James

789 Maria

Tabela Telefone:

Telefone

ClienteID Telefone

123 555-861-2025

456 555-403-1659

456 555-776-4100

789 555-808-9633

Segunda Forma Normal (FN2

Uma relação está na FN2 quando duas condições são satisfeitas:

1 - A relação está na 1FN;

2 - Todo atributo da tabela seja dependente funcional da chave completa e não de parte da chave. Ou seja,
Todos os atributos não-chave dependem funcionalmente de toda a chave primária.

Terceira Forma Normal (FN3

A 3FN exige que não existam atributos transitivamente dependentes da chave.

Um exemplo de uma tabela 2FN que não atende o critério para 3FN é:

Vencedores de Torneios

Torneio Ano Vencedor Data de nascimento do vencedor

Indiana Invitational 1998 Al Fredrickson 21 de julho de 1975

Cleveland Open 1999 Bob Albertson 28 de setembro de 1968

Des Moines Masters 1999 Al Fredrickson 21 de julho de 1975

Indiana Invitational 1999 Chip Masterson 14/3/1977

A chave primária composta é {Torneio, Ano}.

A tabela não está na terceira forma normal porque o atributo "data de nascimento do vencedor" é dependente
transitivamente de {Torneio, Ano} via o atributo "Vencedor". O fato da data de nascimento do vencedor não ser
dependente do vencedor torna a tabela vulnerável a inconsistências lógicas, já que nada impediria de uma
mesma pessoa aparecer com datas de nascimento diferentes em dois registros.

Para atender a terceira forma normal, a mesma informação deveria ser dividida em duas tabelas:

Vencedores de Torneios

Torneio Ano Vencedor

Indiana Invitational 1998 Al Fredrickson

Cleveland Open 1999 Bob Albertson

Des Moines Masters 1999 Al Fredrickson

Indiana Invitational 1999 Chip Masterson

Datas de nascimento de jogadores

Jogador Data de nascimento

Chip Masterson 14/3/1977

Al Fredrickson 21 de julho de 1975

Bob Albertson 28 de setembro de 1968

As duas tabelas acima estão na terceira forma normal.

9.6 Noções de mineração de dados: conceituação e características.

A mineração de dados é o processo de descoberta de informações acionáveis em grandes conjuntos de

dados. A mineração de dados usa análise matemática para derivar padrões e tendências que existem nos
dados. Normalmente, esses padrões não podem ser descobertos com a exploração de dados tradicional pelo
fato de as relações serem muito complexas ou por haver muitos dados.

Esses padrões e tendências podem ser coletados e definidos como um modelo de mineração de dados. Os
modelos de mineração podem ser se aplicados a cenários específicos, como:

Previsão: Estimando vendas, prevendo cargas de servidor ou tempo de inatividade de servidor

Risco e probabilidade: escolhendo os melhores clientes para malas diretas, determinando o ponto equilibrado
provável para cenários de risco, atribuindo probabilidades a diagnósticos ou outros resultados

Recomendações: Determinando quais produtos são mais prováveis de serem vendidos juntos, gerando
recomendações

Localizando sequências: Analisando seleções de cliente em um carrinho de compras, prevendo os próximos

eventos prováveis

Agrupamento: Separando clientes ou eventos em cluster de itens relacionados, analisando e prevendo

afinidades

A criação de um modelo de mineração representa apenas uma parte de um processo maior que inclui desde
perguntas sobre dados e criação de um modelo até respostas para as perguntas feitas e implantação do modelo
em um ambiente de trabalho. Esse processo pode ser definido usando as seis etapas básicas a seguir:

Definindo o problema

Preparando dados

Explorando dados

Criando modelos

Explorando e validando modelos

Implantando e atualizando modelos

O diagrama a seguir descreve as relações entre cada etapa do processo e as tecnologias no Microsoft SQL
Server que você pode usar para concluir cada etapa.
O processo ilustrado no diagrama é cíclico, ou seja, criar um modelo de mineração de dados é um processo
dinâmico e repetitivo. Depois de explorar os dados, você pode descobrir que eles são insuficientes para criar
modelos de mineração apropriados e que você terá, portanto, que obter mais dados. Ou você pode criar vários
modelos e, depois, perceber que os modelos não respondem adequadamente o problema definido e que você
deverá redefinir o problema. Talvez seja necessário atualizar os modelos depois de eles serem implantados,
pois haverá mais dados disponíveis. Cada etapa do processo pode precisar ser repetida muitas vezes para criar
um bom modelo.

A Mineração de Dados do Microsoft SQL Server fornece um ambiente integrado para a criação e manipulação
dos modelos de mineração de dados. Este ambiente inclui o SQL Server Development Studio, que contém
algoritmos de mineração de dados e ferramentas de consulta que facilitam a construção de uma solução
abrangente para uma variedade de projetos e o SQL Server Management Studio, que contém ferramentas para
procurar modelos e gerenciar objetos de mineração de dados. Para obter mais informações, consulte Criando
modelos multidimensionais usando o SSDT (SQL Server Data Tools).

Para obter um exemplo de como as ferramentas do SQL Server podem ser aplicadas a um cenário de negócios,
consulte Tutorial de mineração de dados básico.

Definindo o problema

A primeira etapa do processo de mineração de dados, como destacado no diagrama a seguir, é definir
claramente o problema e considerar maneiras de os dados serem utilizados para fornecer respostas para ele.

Essa etapa inclui a análise dos requisitos de negócio, a definição do escopo do problema, a definição das
métricas usadas para avaliar o modelo e, por fim, a definição de objetivos específicos para o projeto de
mineração de dados. Essas tarefas podem ser traduzidas em perguntas, como:

O que você deseja? Quais tipos de relações está tentando localizar?

O problema que você está tentando solucionar se reflete nas políticas e nos processos da empresa?

Você deseja fazer previsões com o modelo de mineração de dados ou apenas identificar padrões e associações
interessantes?

Qual resultado ou atributo você deseja prever?

Que tipo de dados você tem e que tipo de informações está em cada coluna? Se houver várias tabelas, como
elas estão relacionadas? Você precisa executar alguma limpeza, agregação ou processamento para tornar os
dados utilizáveis?

Como os dados são distribuídos? Os dados são sazonais? Os dados representam de forma precisa os
processos da empresa?
Para responder essas perguntas, talvez seja necessário realizar um estudo da disponibilidade de dados para
investigar as necessidades dos usuários da empresa com relação aos dados disponíveis. Se os dados não
forem suficientes para suprir as necessidades dos usuários, talvez você tenha que redefinir o projeto.

Também é necessário considerar a forma como os resultados do modelo podem ser incorporados em KPIs
(indicadores chave de desempenho) usados para avaliar o progresso dos negócios.

Preparando dados

A segunda etapa do processo de mineração de dados, como destacado no diagrama a seguir, é consolidar e
limpar os dados identificados na etapa Definindo o problema .

Os dados podem estar espalhados pela empresa e armazenados em diferentes formatos ou podem conter
inconsistência, como entradas ausentes ou incorretas. Por exemplo, os dados podem mostrar que um cliente
comprou um produto antes desse produto ser efetivamente colocado a venda no mercado ou que o cliente faz
compras regularmente em uma loja localizada a 3.000 quilômetros da casa dele.

A limpeza de dados não envolve apenas a remoção de dados incorretos ou interpolação de valores ausentes,
mas também a localização de correlações ocultas nos dados, a identificação de fontes de dados mais precisas e
a determinação de quais colunas são mais apropriadas para a análise. Por exemplo, você deveria usar a data de
envio ou a data de pedido? O melhor influenciador de vendas é a quantidade, o preço total ou o preço com
desconto? Dados incompletos, incorretos e entradas que parecem independentes, mas que são muito
relacionadas, podem influenciar os resultados do modelo de formas inesperadas.

Portanto, antes de iniciar a criação de modelos de mineração, você deve identificar esses problemas e
determinar como solucioná-los. Para a mineração de dados, normalmente você está trabalhando com um
conjunto de dados muito grande e não pode examinar a qualidade de dados de cada transação; portanto, você
pode precisar usar alguma forma de criação de perfis de dados e ferramentas automatizadas de limpeza de
dados e filtragem, como as fornecidas no Integration Services, Microsoft SQL Server 2012 Master Data
Servicesou SQL Server Data Quality Services para explorar os dados e localizar as inconsistências. Para obter
mais informações, consulte estes recursos:

Integration Services no Business Intelligence Development Studio

Visão geral do Master Data Services (MDS)

Data Quality Services

É importante saber que os dados usados na mineração de dados não precisam estar armazenados em um cubo
OLAP (processamento analítico online) nem mesmo em um banco de dados relacional, apesar de ambos
poderem ser usados como fontes de dados. Você pode conduzir a mineração de dados usando qualquer fonte
de dados definida como uma fonte de dados do Analysis Services . Isso inclui arquivos de texto, pasta de
trabalho do Excel e dados de outros provedores externos. Para obter mais informações, veja Fontes de dados
com suporte (SSAS – Multidimensional).

Explorando dados

A terceira etapa do processo de mineração de dados, como destacado no diagrama a seguir, é explorar os
dados preparados.

Você deve compreender os dados para tomar decisões apropriadas ao criar os modelos de mineração. As
técnicas de exploração incluem cálculos dos valores máximos e mínimos, cálculos das médias e dos desvios
padrões e análise da distribuição dos dados. Por exemplo, ao analisar os valores máximos, mínimos e médios,
você pode determinar que os dados não são representativos para seus clientes ou processos de negócio e que
você deve obter mais dados equilibrados ou revisar as suposições que determinam suas expectativas. Os
desvios padrão e outros valores de distribuição podem fornecer informações útil sobre a estabilidade e precisão
dos resultados. Um desvio padrão muito grande indica que incluir mais dados pode ser útil para melhorar o
modelo. Os dados que desviam muito de uma distribuição padrão podem estar distorcidos ou representar uma
imagem precisa do problema real, dificultando, porém, o ajuste de um modelo aos dados.

Ao explorar os dados levando em consideração o seu conhecimento do problema dos negócios, é possível
decidir se o conjunto contém dados imperfeitos. Com isso, você poderá criar uma estratégia para solucionar os
problemas ou compreender ainda mais os comportamentos típicos na sua empresa.

Você pode usar ferramentas como o Master Data Services para investigar origens disponíveis de dados e
determinar a sua disponibilidade para mineração de dados. Você pode usar ferramentas como o SQL Server
Data Quality Services, ou o Criador de Perfil no Integration Services, para analisar a distribuição de seus dados
e corrigir problemas como dados errados ou ausentes.

Depois de definir suas origens, você as combina em uma exibição da fonte de dados usando o Designer de
Exibição da Fonte de Dados no SQL Server Data Tools. Para obter mais informações, consulte Exibições de
fontes de dados em modelos multidimensionais. Este designer também contém várias ferramentas que você
pode usar para explorar os dados e verificar que eles funcionarão para criar um modelo. Para obter mais
informações, consulte Explorar dados em uma exibição da fonte de dados (Analysis Services).

Observe que, ao criar um modelo, o Analysis Services cria automaticamente resumos estatísticos de dados do
modelo, que podem ser consultados para uso em relatórios ou para análises detalhadas. Para obter mais
informações, consulte Consultas de mineração de dados.

Criando modelos

A quarta etapa do processo de mineração de dados, como destacado no diagrama a seguir, é criar o modelo ou
modelos de mineração. Você usará o conhecimento obtido na etapa Explorando dados para ajudá-lo a definir e
criar os modelos.
Você define as colunas de dados que você deseja usar ao criar uma estrutura de mineração. A estrutura de
mineração é vinculada à origem dos dados, mas realmente não contém nenhum dado até que seja
processada. Ao processar a estrutura de mineração, o Analysis Services gera agregações e outras informações
estatísticas que podem ser usadas para análise. Essas informações podem ser usadas por qualquer modelo de
mineração com base na estrutura. Para obter mais informações sobre como as estruturas de mineração estão
relacionadas aos modelos de mineração, veja Arquitetura lógica (Analysis Services – Mineração de dados).

Antes de a estrutura e o modelo serem processados, também o modelo de mineração de dados é apenas um
contêiner que especifica as colunas usadas para entrada, o atributo que você está prevendo e os parâmetros
que indicam ao algoritmo como os dados devem ser processados. O processamento de um modelo é
geralmente chamado de treinamento. Treinamento refere-se ao processo de aplicação de um algoritmo
matemático específico aos dados na estrutura com a finalidade de extrair padrões. Os padrões que você localiza
no processo de treinamento dependem da seleção de dados de treinamento, o algoritmo que você escolheu e
como você configurou o algoritmo. SQL Server 2017contém muitos algoritmos diferentes, cada um adequado a
um tipo diferente de tarefa e cada um criando um tipo diferente de modelo. Para obter uma lista dos algoritmos
incluídos no SQL Server 2017, consulte Algoritmos de mineração de dados (Analysis Services – Mineração de
dados).

Você também pode usar parâmetros para ajustar cada algoritmo e aplicar filtros aos dados de treinamento para
usar apenas um subconjunto de dados, criando diferentes resultados. Depois de passar os dados pelo modelo, o
objeto do modelo de mineração conterá resumos e padrões que poderão ser consultados ou usados para
previsão.

É possível definir um novo modelo usando o Assistente de Mineração de Dados do SQL Server Data Tools ou a
linguagem DMX (Data Mining Extensions). Para obter mais informações sobre como usar o Assistente de
Mineração de Dados, consulte Assistente de Mineração de Dados (Analysis Services – Mineração de dados
). Para obter mais informações sobre como usar DMX, consulte Referência de Data Mining Extensions (DMX).

É importante lembrar-se de que sempre que os dados mudarem, será necessário atualizar a estrutura e o
modelo de mineração. Quando você atualiza uma estrutura de mineração reprocessando-a, o Analysis
Services recupera dados da origem, incluindo quaisquer dados novos caso a origem seja atualizada
dinamicamente, e repopula a estrutura de mineração. Se você tiver modelos com base na estrutura, poderá
optar pela atualização dos modelos com base na estrutura, o que significa que eles serão retreinados nos novos
dados, ou poderá manter o modelo como está. Para obter mais informações, consulte Requisitos e
considerações sobre processamento (Mineração de dados).

Explorando e validando modelos

A quinta etapa do processo de mineração de dados, como destacado no diagrama a seguir, é explorar os
modelos de mineração criados e testar a eficiência deles.
Antes de implantar um modelo em um ambiente de produção, você provavelmente o testará para avaliar o
desempenho. Além disso, ao criar um modelo, você normalmente cria vários modelos com diferentes
configurações e os testa para verificar qual deles gera os melhores resultados para seu problema e seus dados.

Analysis Servicesfornece ferramentas que ajudam a separar seus dados em treinamento e conjuntos de dados
de teste para que você possa avaliar com precisão o desempenho de todos os modelos nos mesmos
dados. Você usa o conjunto de dados de treinamento para criar um modelo e o conjunto de dados de teste para
testar a precisão do modelo ao criar consultas de previsão. Esse particionamento pode ser feito
automaticamente durante a criação do modelo de mineração. Para obter mais informações, consulte Teste e
validação (Mineração de dados).

É possível explorar as tendências e os padrões que os algoritmos descobrem usando os visualizações no

Designer de Mineração de Dados do SQL Server Data Tools. Para obter mais informações,
consulte Visualizadores do Modelo de Mineração de Dados. Você também pode testar como os modelos criam
previsões usando ferramentas do designer, como o gráfico de comparação de precisão e a matriz de
classificação. Para verificar se o modelo é específico para seus dados ou se pode ser usado para fazer
deduções na população geral, você pode usar a técnica estatística chamada validação cruzada para criar,
automaticamente, subconjuntos de dados e testar modelos em cada subconjunto. Para obter mais informações,
consulte Teste e validação (Mineração de dados).

Se nenhum dos modelos criados na etapa Criando modelos tiver um bom desempenho, você poderá retornar a
uma etapa anterior no processo e redefinir o problema ou investigar novamente os dados no conjunto de dados
original.

Implantando e atualizando modelos

A última etapa do processo de mineração de dados, como destacado no diagrama a seguir, é implantar os
modelos que tiveram o melhor desempenho em um ambiente de produção.
Depois que os modelos de mineração existirem em um ambiente de produção, será possível realizar várias
tarefas de acordo com suas necessidades.Estas são algumas tarefas que você poderá realizar:

Use os modelos para criar previsões, que poderão ser usadas para tomar decisões comerciais. SQL
Serverfornece a linguagem DMX que você pode usar para criar consultas de previsão e o construtor de
consultas de previsão para ajudá-lo a criar as consultas. Para obter mais informações, consulte Referência de
DMX (extensões DMX).

Crie consultas de conteúdo para recuperar estatísticas, regras ou fórmulas do modelo. Para obter mais
informações, consulte Consultas de mineração de dados.

Insira a funcionalidade de mineração de dados diretamente em um aplicativo. Você pode incluir Objetos de
Gerenciamento de Análise (AMO) que contém um conjunto de objetos que seu aplicativo pode usar para criar,
alterar, processar e excluir estruturas e modelos de mineração.Como alternativa, você pode enviar mensagens
XMLA (XML for Analysis) diretamente para uma instância do Analysis Services. Para obter mais informações,
veja Desenvolvimento (Analysis Services – Mineração de dados).

Use o Integration Services para criar um pacote no qual um modelo de mineração é usado para separar dados
recebidos, de forma inteligente, em diversas tabelas. Por exemplo, se um banco de dados for atualizado
continuamente com clientes potenciais, será possível usar um modelo de mineração juntamente com
o Integration Services para dividir os dados recebidos entre os clientes que têm probabilidade de adquirir um
produto e os que têm probabilidade em não adquirir o produto. Para obter mais informações, consulte Usos
típicos do Integration Services.

Crie um relatório que permita que os usuários consultem diretamente um modelo de mineração existente. Para
obter mais informações, consulte Reporting Services no SQL Server Data Tools (SSDT).

Atualize os modelos depois da revisão e análise. As atualizações exigirão o reprocessamento dos modelos. Para
obter mais informações, consulte Processing Data Mining Objects.

A atualização dinâmica dos modelos, à medida que a organização gera mais dados, e alterações constantes
para melhorar a eficiência da solução devem fazer parte da sua estratégia de implantação. Para obter mais
informações, consulte Gerenciamento de soluções de mineração de dados e objetos

9.7 Noções de aprendizado de máquina.

O termo Inteligência Artificial (IA) não é novo, a primeira abordagem foi feita por pesquisadores em uma
conferência de Dartmouth, no ano de 1956. Desde então, muitas expectativas envolveram o assunto, abordada
como a tecnologia do futuro, ficção científica ou realidade atual. Depende do ponto de vista, pois atualmente a
Inteligência Artificial tem se tornando realidade, apesar de que ainda é um campo de estudo a ser muito
explorado.

Porém, quando falamos de IA, o termo mais conhecido e abordado na atualidade é o de Aprendizado de
Máquina, ou Machine Learning no inglês. A área de Aprendizado de Máquina também não é nova, e já vem
sendo praticada há um bom tempo.

Então o que faz o assunto ganhar tanto destaque na atualidade? A quantidade de dados disponíveis!

Tudo bem que o aumento da velocidade do processamento dos computadores, o barateamento das tecnologias
e a evolução das GPUs influenciam. Mas nunca na história da humanidade se produziu tantos dados como
atualmente. Um artigo da Scientific American revela que em 2016 a humanidade produziu mais dados do que
em toda a sua história, são cerca de 2,5 Exabytes de dados produzidos por dia. E é essa quantidade de dados
disponíveis é que alimenta e fortifica o Aprendizado de Máquina.

Mas a máquina consegue aprender?

Aprendizado de Máquina é um método de análise de dados que automatiza o desenvolvimento de modelos

analíticos. É possível utilizar algoritmos para coletar dados e aprender com os dados, levando em consideração
todo o histórico para então fazer uma determinação ou predição sobre alguma coisa ou situação do mundo real.
O que acontece é que o computador aprende através de técnicas que utilizam algoritmos computacionais. Os
algoritmos trabalham com certa base de dados, então conseguem aprender através de treinamento e prever
situações com a experiência adquirida com aqueles dados. O mais interessante é que os algoritmos começam a
trabalhar de certa forma autônoma, retornando resultados para que nem foram programados, ou seja, começam
a ter insights sobre algo específico.

Atualmente não é difícil encontrar históricos da utilização do Aprendizado de Máquina na vida real. Exemplos de
que realmente a máquina aprende com dados e treinamento. Posso citar os carros autônomos do Google, que
dirigem sozinhos (não começaram a dirigir do nada, eles aprenderam a dirigir sem a intervenção humana), as
ofertas e recomendações online da Netflix, Facebook, Amazon e outras redes sociais e lojas virtuais, detecção
de fraudes automáticas em cartões de créditos e contas bancárias, e até uma rede neural que é capaz de
sonhar. Sim, esse último exemplo é uma rede neural do Google, que foi ensinada a reconhecer imagens e,
enquanto aprende, os responsáveis do projeto dizem que a IA consegue produzir novas imagens.

Métodos para o Aprendizado de Máquina

A pergunta que pode ter ficado no ar é, como fazer a máquina aprender? Anteriormente foi mencionado que o
combustível para a máquina aprender são os dados, porém, existem métodos de aprendizagens que são
utilizados para realizar o Aprendizado de Máquina. Basicamente, existem quatro métodos: aprendizado
supervisionado, aprendizado não supervisionado, aprendizado semi supervisionado e aprendizado por reforço.
Porém, dois são os mais utilizados, o aprendizado supervisionado e o aprendizado não supervisionado, que são
descritos logo abaixo:

Aprendizado supervisionado: neste método de aprendizado, a máquina é treinada através de um conjunto de

dados onde para cada entrada a saída é conhecida. Os dados para este tipo de método devem possuir rótulos.
Podemos comparar a um aprendizado acompanhado, onde o professor supervisiona todo o processo de
aprendizado, dizendo o que é certo, o que é errado e aonde se quer chegar. O desafio fica para quando se quer
prever futuras situações. Com uma entrada de dados, quais serão os resultados previstos para aquela situação.
Neste caso o algoritmo deve se ajustar para chegar aos resultados corretos e com o máximo de acerto. Para
isso o aprendizado pode ser constante, aumentando assim a experiência com aquele problema. Um bom
exemplo para esse caso é conseguir prever se uma transação do cartão de crédito de certa pessoa é falsa ou
não.

Aprendizado não supervisionado: neste método de aprendizagem, ao contrário do anterior, os dados não
possuem rótulo, ou seja, a saída correta não é informada. Podemos comparar a um aprendizado autodidata,
onde o aluno tem que descobrir o caminho e alcançar os resultados. Neste caso, o algoritmo deve descobrir a
base de dados e o que está sendo mostrado, explorando os dados e buscando encontrar alguma estrutura
neles. Dependendo da técnica utilizada, o algoritmo vai encontrar agrupamentos entre esses dados,
aproximando os dados que tem alguma semelhança entre si. Um exemplo pode ser a classificação de pessoas
que tenham a tendência de adquirir diabetes, analisando a sua alimentação e rotina, porém não é informado
quais pessoas realmente tem ou não diabetes. Neste caso o algoritmo tem que agrupar e contextualizar esses
dados para chegar a predição correta dos casos.

Processo de aprendizado

Como o ser humano, a máquina precisa passar por alguns processos para que ela possa aprender. Como
discutido anteriormente, os dados são essenciais, então o primeiro passo é escolher quais dados serão
trabalhados e disponibilizados para o processo do Aprendizado de Máquina.

Porém, nem todo conjunto de dados, seja ele adquirido em bases de dados abertas, coletados em tempo real ou
de um banco de dados, estará de forma estruturada e pronta para ser passados para a máquina aprender.
Como nós, que precisamos de um material para estudo de qualidade para podermos aprender, a máquina
precisa de um conjunto de dados razoável para também poder aprender. Como citado, muitas das vezes os
dados estão completamente desestruturados e fora de um padrão e para isso é necessário a realização da
técnica de Data Cleaning.

Data Cleaning, ou Limpeza de Dados, é uma técnica utilizada para trabalhar com os dados. Nesse processo é
realizada a normalização, a estruturação, padronização e contextualização dos dados. Pode ser que nem todas
as bases de dados precisem passar por esse processo, porém, é bom validar dependendo do problema e qual o
resultado desejado.

Após ter um conjunto de dados estruturados, o próximo passo neste processo de aprendizado é a aplicação de
um método de aprendizagem juntamente com uma técnica de Aprendizado de Máquina. As técnicas de
Aprendizado de Máquina utilizam algoritmos, que por sua vez faz o trabalho computacional e todo o
processamento dos dados.

Logo abaixo serão descritos algumas técnicas de Aprendizado de Máquina.

Redes Neurais: são baseadas em como o cérebro humano funciona. Existem diferentes tipos de Redes
Neurais, mas basicamente elas consistem em um conjunto de nós (ou neurônios) dispostos em várias camadas
com interconexões ponderadas entre eles. Cada neurônio combina um conjunto de valores de entrada para
produzir um valor de saída, que por sua vez é passado para outros neurônios nas camadas seguintes.

Árvore de Decisão: essa técnica utiliza algoritmos do formato de árvore. Cada árvore possui nó, ramos, folhas
e ligações entre eles. Um ramo é um conjunto de nó que testa cada atributo da classificação e cada ramo
corresponde ao valor do atributo. E as folhas atribui uma classificação para os ramos. A classificação é o
resultado final que se quer chegar ou prever com o algoritmo.

Regressão: é a técnica utilizada quando se quer prever valores de algo futuro, baseado em comportamento de
variáveis passadas. Um exemplo seria prever o valor de mercado de um imóvel utilizando um algoritmo de
regressão linear.

Depois da aplicação da técnica de aprendizado e do treinamento do algoritmo, devemos confirmar o seu

desempenho para prever os casos. Nesse momento é a hora da aplicação da prova. Existe algumas métricas
que podem ser utilizadas para assim ter uma medida que fale a quantidade de acertos, erros ou o desempenho
da técnica utilizada. Algumas métricas interessantes serão descritas logo abaixo:

Acurácia: essa métrica é a mais básica para medir o aprendizado, leva em consideração a proporção de
predições corretas, sem levar em consideração a quantidade de erros.

Sensibilidade: é a proporção de verdadeiros positivos, ou seja, a capacidade do algoritmo em prever casos

corretamente para os casos que são realmente verdadeiros.

Especificidade: A proporção de verdadeiros negativos: a capacidade do algoritmo em predizer situações

erradas que realmente são falsas.

Eficiência: é a média aritmética da sensibilidade e especificidade. Indica se o algoritmo está mais suscetível a
ter verdadeiros positivos ou verdadeiros negativos.
9.8 Noções de bigdata: conceito, premissas e aplicação.

O conceito

O termo Big Data é tão amplo quanto seu nome sugere. Para contextualizá-lo e dar sentido a ele, caro leitor,
segue uma breve explicação: nós vivemos em uma Era em que, a (apenas) cada um ano e meio, se gera a
mesma quantidade de dados já criados pela humanidade em todos os tempos.

Essa época atual, de geração de volumes incomensuráveis de dados por empresas, pessoas e aparelhos, é
chamada de a Era de Big Data. O termo Big Data também corresponde à própria quantidade absurda de dados
gerados atualmente – os “Grandes Dados”.

Um dos desdobramentos de Big Data é o termo Big Data Analytics, que refere-se aos poderosos softwares
capazes de tratar esses dados para transformá-los em informações úteis às organizações.

Iniciativas apoiadas em Analytics permitem analisar dados estruturados e não estruturados, como registros de
call center, postagens de redes sociais e blogs, dados de CRM, balanços patrimoniais e demonstrativos de
resultados. Desta forma facilita-se a descoberta, em tempo real, das oportunidades que estão além do que os
olhos humanos podem enxergar de forma orgânica.

Big Data

Focado no processamento de dados estruturados e não estruturados, bem como nas correlações e descobertas
que desse processamento podem advir;

Analisa o que já existe e o que está por vir, apontando novos caminhos;

Ideal para quando se quer explorar novas possibilidades, descobrir novos padrões e explorar perguntas que
ainda não haviam sido feitas;

Mais amplo, voltado não apenas para negócios, mas para qualquer área/segmento, como saúde,
entretenimento, educação.

Os 'Vs' do Big Data: volume, velocidade, variedade, veracidade e valor

No intuito de deixar a ideia de Big Data mais clara, alguns especialistas passaram a resumir o assunto em
aspectos que conseguem descrever satisfatoriamente a base do conceito: os cincos 'Vs' - volume, velocidade e
variedade, com os fatores veracidade e valor aparecendo posteriormente.

O aspecto do volume (volume) você já conhece. Estamos falando de quantidades de dados realmente grandes,
que crescem exponencialmente e que, não raramente, são subutilizados justamente por estarem nestas
condições.

Velocidade (velocity) é outro ponto que você já assimilou. Para dar conta de determinados problemas, o
tratamento dos dados (obtenção, gravação, atualização, enfim) deve ser feito em tempo hábil - muitas vezes em
tempo real. Se o tamanho do banco de dados for um fator limitante, o negócio pode ser prejudicado: imagine,
por exemplo, o transtorno que uma operadora de cartão de crédito teria - e causaria - se demorasse horas para
aprovar um transação de um cliente pelo fato de o seu sistema de segurança não conseguir analisar
rapidamente todos os dados que podem indicar uma fraude.

Variedade (variety) é outro aspecto importante. Os volume de dados que temos hoje são consequência também
da diversidade de informações. Temos dados em formato estruturados, isto é, armazenados em bancos como
PostgreSQL e Oracle, e dados não estruturados oriundos de inúmeras fontes, como documentos, imagens,
áudios, vídeos e assim por diante. É necessário saber tratar a variedade como parte de um todo - um tipo de
dado pode ser inútil se não for associado a outros.

O ponto de vista da veracidade (veracity) também pode ser considerado, pois não adianta muita coisa lidar com
a combinação "volume + velocidade + variedade" se houver dados não confiáveis. É necessário que haja
processos que garantam o máximo possível a consistência dos dados. Voltando ao exemplo da operadora de
cartão de crédito, imagine o problema que a empresa teria se o seu sistema bloqueasse uma transação genuína
por analisar dados não condizentes com a realidade.

Informação não é só poder, informação também é patrimônio. A combinação "volume + velocidade + variedade
+ veracidade", além de todo e qualquer outro aspecto que caracteriza uma solução de Big Data, se mostrará
inviável se o resultado não trouxer benefícios significativos e que compensem o investimento. Este é o ponto de
vista do valor (value).

É claro que estes cinco aspectos não precisam ser tomados como a definição perfeita. Há quem acredite, por
exemplo, que a combinação "volume + velocidade + variedade" seja suficiente para transmitir uma noção
aceitável do Big Data. Sob esta óptica, os aspectos da veracidade e do valor seriam desnecessários, porque já
estão implícitos no negócio - qualquer entidade séria sabe que precisa de dados consistentes; nenhuma
entidade toma decisões e investe se não houver expectativa de retorno.

O destaque para estes dois pontos talvez seja mesmo desnecessário por fazer referência ao que parece óbvio.
Por outro lado, a sua consideração pode ser relevante porque reforça os cuidados necessários a estes aspectos:
uma empresa pode estar analisando redes sociais para obter uma avaliação da imagem que os clientes têm de
seus produtos, mas será que estas informações são confiáveis ao ponto de não ser necessário a adoção de
procedimentos mais criteriosos? Será que não se faz necessário um estudo mais profundo para diminuir os
riscos de um investimento antes de efetuá-lo?

De qualquer forma, os três primeiros 'Vs' - volume, velocidade e variedade - podem até não oferecer a melhor
definição do conceito, mas não estão longe de fazê-lo. Entende-se que Big Data trata apenas de enormes
quantidades de dados, todavia, você pode ter um volume não muito grande, mas que ainda se encaixa no
contexto por causa dos fatores velocidade e variedade.

Soluções de Big Data

Além de lidar com volumes extremamente grandes de dados dos mais variados tipos, soluções de Big Data
também precisam trabalhar com distribuição de processamento e elasticidade, isto é, suportar aplicações com
volumes de dados que crescem substancialmente em pouco tempo.

O problema é que os bancos de dados "tradicionais", especialmente aqueles que exploram o modelo relacional,
como o MySQL, o PostgreSQL e o Oracle, não se mostram adequados a estes requisitos, já que são menos
flexíveis.

Isso acontece porque bancos de dados relacionais normalmente se baseiam em quatro propriedades que
tornam a sua adoção segura e eficiente, razão pela qual soluções do tipo são tão populares: Atomicidade,
Consistência, Isolamento e Durabilidade. Esta combinação é conhecida como ACID, sigla para o uso destes
termos em inglês: Atomicity, Consistency, Isolation e Durability. Vejamos uma breve descrição de cada uma:

Atomicidade: toda transação deve ser atômica, isto é, só pode ser considerada efetivada se executada
completamente;

Consistência: todas as regras aplicadas ao banco de dados devem ser seguidas;

Isolamento: nenhuma transação pode interferir em outra que esteja em andamento ao mesmo tempo;

Durabilidade: uma vez que a transação esteja concluída, os dados consequentes não podem ser perdidos.

O problema é que este conjunto de propriedades é por demais restritivo para uma solução de Big Data. A
elasticidade, por exemplo, pode ser inviabilizada pela atomicidade e pela consistência. É neste ponto que entra
em cena o conceito de NoSQL, denominação que muitos atribuem à expressão em inglês "Not only SQL", que
em tradução livre significa "Não apenas SQL" (SQL -Structured Query Language - é, em poucas palavras, uma
linguagem própria para se trabalhar com bancos de dados relacionais).

O NoSQL faz referência às soluções de bancos de dados que possibilitam armazenamento de diversas formas,
não se limitando ao modelo relacional tradicional. Bancos do tipo são mais flexíveis, sendo inclusive compatíveis
com um grupo de premissas que "compete" com as propriedades ACID: a BASE (Basically Available, Soft
state, Eventually consistency - Basicamente disponível, Estado Leve, Eventualmente consistente).
Não é que bancos de dados relacionais tenham ficado ultrapassados - eles são e continuarão por muito tempo
sendo úteis a uma série de aplicações. O que acontece é que, geralmente, quanto maior um banco de dados se
torna, mais custoso e trabalhoso ele fica: é preciso otimizar, acrescentar novos servidores, empregar mais
especialistas em sua manutenção, enfim.

Via de regra, escalar (torná-lo maior) um bancos de dados NoSQL é mais fácil e menos custoso. Isso é possível
porque, além de contar com propriedades mais flexíveis, bancos do tipo já são otimizados para trabalhar com
processamento paralelo, distribuição global (vários data centers), aumento imediato de sua capacidade e outros.

Além disso, há mais de uma categoria de banco de dados NoSQL, fazendo com que soluções do tipo possam
atender à grande variedade de dados que existe, tanto estrurados, quanto não estruturados: bancos de dados
orientados a documentos, bancos de dados chave/valor, bancos de dados de grafos, enfim.

Exemplos de bancos de dado NoSQL são o Cassandra, o MongoDB, o HBase, o CouchDB e o Redis. Mas,
quando o assunto é Big Data, apenas um banco de dados do tipo não basta. É necessário também contar com
ferramentas que permitam o tratamento dos volumes. Neste ponto, o Hadoop é, de longe, a principal referência.

Como esses dados são transformados em insights?

Soluções de Big Data “tratam” os dados brutos até transformá-los em insights valiosos para as tomadas de
decisão. Referem-se a um processo eletrônico que transforma um conjunto de dados “soltos” em informações,
informações em conhecimento e, por fim, conhecimento em sabedoria, que será usada para tomar as decisões
mais assertivas e céleres ao contexto de seu negócio. Vale ressaltar que empresas que utilizam Big Data
possuem 5 vezes mais chances de tomarem decisões mais rápidas dos que seus concorrentes e 2 vezes
mais chances de obterem performance superior, como mostra pesquisa da consultoria em negócios norte-
americana Bain & Company.

SOLUÇÕES DE BIG DATA “TRATAM” OS DADOS BRUTOS ATÉ TRANSFORMÁ-LOS EM INSIGHTS

VALIOSOS PARA TOMADA DE DECISÃO

Agora vamos tornar isso mais claro. Imagine uma desenvolvedora de softwares que precisa entender por que
houve aumento nas taxas de churn de seu negócio. O trabalho de inteligência de dados partirá dos “rastros”
básicos dos ex-assinantes, como planos contratados, queixas registradas e taxas de inadimplência.
Posteriormente, esses dados gerarão informações como lista de inadimplentes ou quais clientes manifestaram
insatisfação com os softwares comercializados.

Em seguida, parte-se para a fase do conhecimento, relacionando, por exemplo, os planos contratados com
maiores possibilidades de cancelamentos (planos mais completos são mais caros e apresentam maior tendência
a serem abandonados no futuro do que pacotes baratos). Por último, gera-se a “sabedoria” do negócio, como as
sugestões de ações que devem ser tomadas para ampliar o nível de satisfação dos clientes ou tornar os planos
mais acessíveis, a fim de reduzir as taxas de cancelamento.

Leia também: Os grandes (e impressionantes) números de Big Data

Quais insights podemos obter?

Serviços financeiros

O setor financeiro armazena, diariamente, “montanhas” de dados ligados às movimentações dos clientes.
São miríades de rastros registrados por meio de inúmeras aplicações, o que resulta na atmosfera perfeita para
um gerenciamento de informações em nível de excelência – desde que se tenha, é claro, um software robusto
e escalável especializado em mineração de dados. A aquisição de uma boa ferramenta de análise de dados
possibilita às empresas do setor financeiro:

Reduzir as taxas de churn

Para se ter uma ideia do impacto da saída de clientes da base ativa do setor financeiro, nos EUA estima-se que
30% dos clientes sejam vulneráveis à migração. Sabendo desse fator crítico, muitas instituições do ramo
passaram a usar a análise de dados para rastrear as manifestações emocionais dos correntistas (em mídias
sociais e sites de reclamações), diagnosticando com antecedência suas insatisfações e ganhando tempo para
neutralizá-las antes do fechamento de contas.

Para entender ainda mais sobre como Big Data ajuda a reduzir a taxa de churn do seu negócio, leia o
eBook ‘Como Big Data Analytics irá prever e reduzir as saídas de cliente da sua empresa’.

Personalizar serviços

Entender como os clientes usam cartões de crédito e para que tomam empréstimos ajuda a criar produtos que
atendam assertivamente suas necessidades, ampliando o potencial de captação de novos correntistas.

Estreitar as relações com clientes

Soluções em Big Data processam todas as movimentações dos correntistas (a partir do bankline, de mídias
sociais, do CRM do banco, de blogs), no intuito de gerar relatórios e gráficos que revelam o valor da vida útil de
cada cliente, seus anseios e expectativas em relação ao banco. Isso permite, entre outras coisas, aumentar as
vendas cruzadas.

Quer conhecer mais insights que Big Data gera para o setor de serviços financeiros? Então baixe o
eBook ‘Big Data em serviços financeiros: conheça as aplicações e cases de sucesso’.

Varejo
O crescimento da análise de dados no varejo é indiscutível. Segundo pesquisa internacional encabeçada
pela GE, 89% das empresas veem Big Data como crucial para a transformação digital dos negócios,
especialmente no varejo. Vendas dependem de conhecimento aprofundado do público-alvo, o que passa pelo
desenvolvimento de uma sistemática de análise baseada em alta tecnologia. Ao transformar volumes de dados
em inteligência para o comércio, é possível:

Direcionar ações de marketing multicanal

Com a disseminação de um consumidor cada vez mais omnichannel, é preciso integrar todos os canais de
comunicação, o que passa pela compreensão plena do comportamento do cliente. Esta consciência de mercado
pode ser alcançada por meio da maior segmentação do público-alvo, entendimento de seus hábitos e
preferências de consumo e informações sociais e demográficas – tudo isso possível graças à coleta e análise
dos dados de milhares de consumidores.

89% DAS EMPRESAS VEEM BIG DATA COMO CRUCIAL PARA A TRANSFORMAÇÃO DIGITAL DOS
NEGÓCIOS

Agregar valor aos programas de fidelidade

Entender melhor o comportamento de compra do consumidor é essencial para elaborar programas de fidelidade
realmente atraentes. Você já imagina o quanto a mineração de dados pode contribuir neste âmbito, certo?

Para tornar essa questão mais clara, vale a pena citar o case do Grupo Pão de Açúcar, que passou a utilizar, em
2015, ferramentas de análise de dados para fidelizar seus clientes. O sistema mapeia antigos consumidores que
deixaram de frequentar a rede. Em seguida, realiza um levantamento eletrônico dos produtos preferidos de cada
um deles.

A descoberta desses dois fatores permite à empresa lançar cupons de descontos personalizados, oferecendo
promoções especiais e distintas a cada cliente e, assim, estimulando o consumidor a retornar para a rede.

Maximizar o ROI em marketing

O ambiente de mercado agressivo exige aplicação de recursos com retorno “cirúrgico” aos números da
empresa. Assim, cada ação de marketing deve ser acompanhada em tempo real por ferramentas de
monitoramento de redes sociais. Se uma campanha não provoca o efeito esperado ou, pior, gera feedback
negativo do consumidor, essa falha deve ser detectada rapidamente, a fim de que a empresa tome as medidas
corretivas.

Aprofunde-se ainda mais acerca dos benefícios de Big Data para o setor varejista com o eBook ‘Conheça
as inovações que o Big Data Analytics está trazendo para o varejo’.

Saúde
“Digital Health” é a palavra de ordem no setor de saúde na atualidade. Trata-se da utilização de poderosos
sistemas da informação para coletar, agregar e trabalhar dados estruturados e não estruturados ligados ao setor
de saúde, gerando informações clínicas que fortalecem a medicina de precisão (em detrimento às atuais
metanálises, que trabalham com dados estatísticos genéricos e que nem sempre correspondem às
peculiaridades de cada indivíduo).

Entre tantas funções que serão citadas abaixo, a análise de dados permite o cruzamento de uma multiplicidade
imensurável de variáveis clínicas, gerando diagnósticos muito mais exatos. Segundo pesquisa da Transparency
Market Research, o crescimento do mercado de Big Data será extremamente impactante nos próximos anos.
Estima-se que os investimentos nesse setor passem dos US$ 6,3 bilhões de 2012 para US$ 48,3 bilhões em
2018, sendo comandados, principalmente, pelo setor de Saúde.

Alguns benefícios que a Ciência de Dados no setor de saúde traz à sociedade são:

Prevenção de epidemias

Monitorar as manifestações de uma população em redes sociais – em consonância com a agregação de dados
de pesquisas de campo e análises estatísticas – ajuda a visualizar antecipadamente a possibilidade de
eclosão de uma epidemia, dando tempo às instituições de saúde se adequarem aos aumentos súbitos da
demanda de atendimento e medicamentos.

ESTIMA-SE QUE OS INVESTIMENTOS EM BIG DATA PASSEM DOS US$ 6,3 BILHÕES DE 2012 PARA US$
48,3 BILHÕES EM 2018

A disseminação da telemedicina e da tecnologia “vestível”

Telemedicina e tecnologia “vestível” (wearables) são duas terminologias intimamente ligadas à disseminação
dos recursos de TI em saúde. Telemedicina é a medicina a distância, propiciada pela utilização de tecnologias
de telecomunicações e análise de grandes dados no fornecimento de informações clínicas dos pacientes.

Essas trocas de informações a distância são viabilizadas por meio de equipamentos eletrônicos de alta
capacidade de processamento, como gadgets fixados no vestuário de um paciente (relógios, pulseiras ou tênis
inteligentes, frutos da chamada tecnologia “vestível”).

A troca de informações permite reunir um conjunto maior de dados (Big Data na área de diagnósticos) sobre a
situação clínica de um indivíduo, possibilitando um debate mais preciso na escolha do tratamento ideal a ser
aplicado a um paciente e orientando com maior excelência os procedimentos ligados à promoção da saúde.

O uso dessas tecnologias permite melhor compreensão dos profissionais de saúde sobre as patologias de seus
pacientes, fornecem melhores subsídios para pesquisas e maior credibilidade aos protocolos clínicos, dentre
outros benefícios.

Setor público

As decisões dos gestores públicos envolvem, diariamente, difíceis escolhas de aplicação do orçamento,
priorização de programas, prevenção a desastres naturais e epidemias, além de investimentos em infraestrutura.
Organizar todo esse emaranhado de planos de ação estratégica baseado apenas na intuição gera,
invariavelmente, colapso administrativo.

Big Data para Gestão Pública é o segredo dos grandes gestores, haja visto que já existem ferramentas de data
mining desenvolvidas especialmente para a área governamental. Com a Ciência de Dados, os gestores públicos
modernos podem:

Combater corrupção e desvio de receitas

O Ministério da Justiça pode nos explicar melhor este tópico. Desde 2007, este Ministério vem usando
sistemas de alta performance em coleta e processamento de dados, cruzando informações de milhões de
contribuintes no intuito de combater a lavagem de dinheiro e outros crimes financeiros. O sucesso da iniciativa é
evidenciado pelo aumento anual no montante de recursos direcionados a essa área de Inteligência.
Fortalecer a implementação de “cidades inteligentes”

Que tal ter um sistema de monitoramento em tempo real, para que toda a população possa acompanhar o
consumo de energia e as possibilidades de sobrecarga no fornecimento? Semáforos cuja sincronização seja
alterada a depender do trânsito nas vias? Zonas de maior concentração de poluição sonora e atmosférica
monitoradas via sistema? Tudo isso já é possível com o auxílio de Big Data, utilizado em grandes cidades do
mundo para torná-las ‘smart cities’, como Barcelona.

Assista ao nosso webinar sobre Big Data e Logística e entenda como a cidade de Barcelona tornou-se
um case mundial de smart city!

Monitorar o nível de satisfação da população

Um trabalho científico apoiado em Big Data é indiscutivelmente mais completo e eficaz do que uma simples
pesquisa por amostragem.

Assim, o monitoramento das mídias sociais por meio de ferramentas de Social Big Data é abertura para que os
gestores públicos conheçam o que seus contribuintes pensam do trabalho desenvolvido e obtenham insights
para implantação de novos projetos ou soluções para problemas detectados (que dificilmente chegariam ao
conhecimento das autoridades públicas pelos canais tradicionais de comunicação).

10 Redes de comunicação.

11 Redes de computadores: locais, metropolitanas e de longa distância.

12 Noções de programação python e R.

13 API (application programming interface).
14 Metadados de arquivos.