1549_mpog_enap_conhe_espec_ii_cargo_12_anali_em_ti_mpoge_intensivao_1-13-apostila

Prof. Marcio Hollweg www.aprovaconcursos.com.br Página 1 de 22

Prof. Marcio Hollweg Conhecimentos Específicos II -‐ Cargo 12: Analista em TI -‐ MPGO,ENAP -‐ Intensivão

Aulas: 01 -‐ 13

Conhecimentos Específicos II - Cargo 12: Analista em TI - MPGO, ENAP - Intensivão

Professor: Marcio Hollweg Aulas: 01 a 13



Aulas: 01 -‐ 13

BANCO DE DADOS CONCEITO O conceito de banco de dados, pode ser expresso de várias formas distintas:

• Conjunto de conceitos que representa algum aspecto do mundo real (conjunto de casos de uso, definição do sistema, declaração de requisitos, mini-mundo, universo de discurso);

• Coleção lógica e coerente de dados com algum significado inerente; Porém, possui algumas características comuns:

• É projetado, construído e povoado com dados para algum objetivo específico; • Pode ser gerado e mantido manualmente ou informatizado

Aqui devemos devemos considerar um banco de dados como um ou mais arquivos armazenados no sistema de arquivos do sistema operacional contendo informações relevantes obtidas a partir de processos de negócio de uma organização, setor, grupo de pessoas ou outros. Exemplo de um Banco de Dados:

Tabela de Clientes Nome Endereço Telefone

Jose da Silva Rua dos Sabias, 10 3344-5566 João Pereira Av. Principal, 222 3636-1020 Carlos Santos Rua Sta Clara, 30 3244-1122

O exemplo mostra uma tabela, com 3 colunas e 3 linhas. Esse é um pequeno modelo de um banco de dados, Nome, Endereço e Telefone são Campos e as linhas de dados são chamadas de Registros. COMPONENTES BÁSICOS DE UM BANCO DE DADOS Tabela: Estrutura bidimensional formada por linhas e colunas, para armazenar os dados, atualmente, um Banco de Dados é formado por várias tabelas. Campo: Divisão das tabelas, cada campo permite armazenar um tipo específico de informação, por exemplo, o campo Telefone armazena, para qualquer que seja o cliente, a informação do telefone dele. Normalmente, os campos são apresentados como as colunas. Registro: É o nome dado a uma informação completa da tabela, conjunto de campos, cada cliente é um registro. SISTEMA GERENCIADOR DE BANCO DE DADOS - SGBD Uma vez que estabelecemos que um banco de dados é tão somente um conjunto de arquivos que contém os dados referentes a um sistema qualquer, podemos nos fazer a seguintes perguntas: Mas como esses dados são administrados? Como definimos a estrutura de cada registro? Como definir regras de acesso aos dados? Todas as tarefas acima, e ainda outras, são realizadas através do uso de um conjunto de softwares conhecidos por Sistema Gerenciador de Banco de Dados. Esse sistema foi definido como:

• Coleção de programas que possibilita a definição, construção e manutenção de um banco de dados; • Definir: especificar os tipos de dados, estruturas e restrições para os dados do banco; • Construir: armazenar os dados em um meio de armazenamento controlado pelo SGBD; • Manipular: funções para consultas e atualizações nos dados armazenados.

Muitas outras funções são disponibilizadas pelos SGBDs atuais como, por exemplo, ferramentas para backup e restore, extração e importação de dados, gerenciamento de transações e acesso concorrente, geração de relatórios, análise de dados, etc. Há vários produtos disponíveis no mercado. Cada um deles com suas próprias características e disponibilizando diferentes funcionalidades dependendo da versão escolhida. Nos últimos anos praticamente todas as empresas disponibilizam alguma versão sem necessidade de pagamento de licença dos seus SGBDs, algumas dessas versões possuem limitações em relação às versões pagas, outros produtos somente existem em versões livres. Os mais conhecidos no mercado são ORACLE, IBM DB2, MS-SQL Server, MYSQL, PostGreSQl, FireBird, DB4 e SYBASE. ARQUITETURA DE SISTEMA DE BANCO DE DADOS Os SGBD possui algumas características operacionais elementares, listadas a seguir: 1. Controle de Redundâncias - A redundância consiste no armazenamento de uma mesma informação em locais diferentes, provocando inconsistências. Em um Banco de Dados as informações só se encontram armazenadas em um único local, não existindo duplicação descontrolada dos dados. Quando existem replicações dos dados, estas são decorrentes do processo de armazenagem típica do ambiente Cliente-Servidor, totalmente sob controle do Banco de Dados. 2. Compartilhamento dos Dados - O SGBD deve incluir software de controle de concorrência ao acesso dos dados, garantindo em qualquer tipo de situação a escrita/leitura de dados sem erros.



Aulas: 01 -‐ 13

3. Controle de Acesso - O SGDB deve dispor de recursos que possibilitem selecionar a autoridade de cada usuário. Assim um usuário poderá realizar qualquer tipo de acesso, outros poderão ler alguns dados e atualizar outros e outros ainda poderão somente acessar um conjunto restrito de dados para escrita e leitura. 4. Interfaceamento - Um Banco de Dados deverá disponibilizar formas de acesso gráfico, em linguagem natural, em SQL ou ainda via menus de acesso, não sendo uma "caixa-preta" somente sendo passível de ser acessada por aplicações. 5. Esquematização - Um Banco de Dados deverá fornecer mecanismos que possibilitem a compreensão do relacionamento existentes entre as tabelas e de sua eventual manutenção. 6. Controle de Integridade - Um Banco de Dados deverá impedir que aplicações ou acessos pelas interfaces possam comprometer a integridade dos dados. 7. Backups - O SGBD deverá apresentar facilidade para recuperar falhas de hardware e software, através da existência de arquivos de "pré-imagem" ou de outros recursos automáticos, exigindo minimamente a intervenção de pessoal técnico. Para garantir que essas características sejam satisfeitas os sistemas de banco de dados são implementados em diferentes camadas. Cada uma representa um nível de abstração e possui diferentes responsabilidades. A figura apresenta um esquema exemplo de separação entre esses diferentes níveis de abstração. O nível visão estabelece as diferentes formas através das quais um sistema de banco de dados pode ser acessado, o nível conceitual, também chamado de lógico, é responsável por manter o catálogo do sistema e fazer a ponte entre as aplicações e o nível físico que é aquele que gerencia o acesso aos sistemas de armazenamento, discos e memória, onde estão os arquivos de dados do sistema.

Por trás da implementação em vários níveis há o conceito de independência de dados. A “independência de dados” pode ser definida como a capacidade de se alterar um esquema em um nível em um banco de dados sem ter que alterar um nível superior. Existem dois tipos de independência de dados:

• Independência de dados lógica: é a capacidade de alterar o esquema conceitual sem ter que alterar o esquema externo ou as aplicações do usuário, ou seja, podemos alterar o esquema conceitual sem a necessidade de reescrever os programas aplicativos. Algumas vezes é necessário alterar a estrutura lógica do banco de dados como por exemplo adicionando alguma nova entidade (tabela) ao banco ou impor alguma restrição de integridade.

• Independência de dados física: é a capacidade de alterar o esquema interno sem ter que alterar o esquema conceitual, o esquema externo ou as aplicações do usuário, ou seja, podemos alterar o esquema físico sem a necessidade de reescrever os programas aplicativos. Algumas vezes são necessárias modificações no nível físico para melhorar o desempenho.

Na prática a independência de dados física é mais facilmente implementada. A aquisição de uma unidade de disco mais rápida ou acrescentar memória a um servidor não serão acompanhadas de alterações no esquema do banco de dados ou nas aplicações. MODELOS DE BANCOS DE DADOS Existem diversos modelos de banco de dados, e cada modelo tem suas características de manipulação e armazenamento dos dados, dentre estes modelos vamos comentar um pouco sobre os dois modelos cobrados pelo edital, são eles: o modelo relacional e Multidimensional. O modelo relacional é o que tem se destacado nos últimos anos, portanto, é o modelo mais cobrado em concursos públicos



Aulas: 01 -‐ 13

MODELAGEM DE DADOS RELACIONAL. O Modelo Relacional de banco de dados é o modelo no qual iremos nos aprofundar já que a cobrança em prova se baseia muito nele, por ser um modelo de fácil entendimento é o mais utilizado atualmente. Ele representa os dados por meio de conceitos matemáticos da teoria dos conjuntos. Este modelo foi proposto pelo pesquisador Edgar Ted Frank Codd em jun/1970, sua proposta é melhorar a visão dos dados, onde a abordagem relacional faz com que o banco de dados seja representado como um conjunto de tabelas bidimensionais, originadas em linhas e colunas. A relação entre duas tabelas é feita através de colunas em comum (chave primária e chave estrangeira).

Algumas de suas principais características são:

• Pode ser entendido e usado por qualquer usuário. • Permite ampliar o esquema conceitual sem modificar as aplicações de gerenciamento. • Os usuários não necessitam saber onde se encontram os dados fisicamente.

O elemento principal deste modelo é a relação que se representa mediante uma tabela, abaixo uma relação de conceitos que definem uma tabela relacional:

• Cada tabela é chamada de relação. • Uma linha e suas colunas chamam-se tupla. • Cada coluna dessa tabela tem um nome e representa um atributo da tabela. • A ordem das linhas é irrelevante. • Não há duas linhas iguais. • A ordem das colunas também é irrelevante. • Cada tabela tem nome próprio, distinto de qualquer outra tabela no banco de dados.

Tabela de Funcionários

Nome Sexo Matrícula Departamento Cargo

João Carlos M 373 TI-‐Operações Operador

Carlos Brito M 872 TI-‐Programação Programador I

Silvia Moraes F 963 TI-‐Análise Analista Sist. II

Cláudia Tereza F 161 TI-‐Gerência Secretária

Pedro Júlio M 292 RH Diretor

Pedro Júlio M 574 TI-‐Análise Analista Sist. I

Ao analisarmos os dados observamos: • As matrículas não indicam a ordem das linhas, apresentando o conceito de que a ordem das linhas é

irrelevante. • Todas as colunas possuem um nome que significam algo. • A ordem das colunas não está desenvolvida para nenhuma finalidade de classificação ou ordem de leitura

dos dados. • Nenhuma linha se repete. • Podemos ter duas pessoas com o mesmo nome, porém com matrículas diferentes.



Aulas: 01 -‐ 13

O CONCEITO DE CHAVE NO MODELO RELACIONAL Chave Primária (Primary Key): Em uma tabela existe uma coluna ou conjunto de colunas concatenados, cujo valor é único na tabela, ou seja, nunca se repete aquele valor em nenhuma outra linha da tabela, e que identifica uma e somente uma única linha da tabela. Então dizemos que esta coluna ou conjunto de colunas forma a chave primária da tabela. Chave Estrangeira (Foreign Key): Quando dizemos que duas tabelas estão relacionadas através de atributos (colunas) comuns, devemos observar que esta coluna é a chave primária em uma das tabelas. Na outra tabela, este atributo irá caracterizar o que chamamos de chave estrangeira, propiciando assim, uma ligação lógica (relacionamento) entre as tabelas.

: Chave Candidata: Uma tabela relacional pode assumir alternativas de identificador único, ou seja, vária colunas ou concatenações delas podem ter essa propriedade. Estes identificadores são candidatos à chave primária. Como somente um poderá ser o escolhido (uma tabela só pode ter uma chave primária – que pode ser composta pela concatenação de mais de uma coluna), o restante passa a ser considerado como chave alternativa (secundária). Chave Secundária (Secundary Key): Serve para definir uma “segunda chave primária” através da criação de índices únicos de pesquisa. As chaves secundárias mantêm a integridade das tabelas que possuem mais de uma chave candidata. RESTRIÇÕES DE INTEGRIDADE Um dos objetivos primordiais em um SGBD relacional é a integridade dos dados. Para prover essa característica, deve-se habilitar o mecanismo de restrições de integridade. As restrições de integridade impõem-se para garantir que os dados fiquem protegidos contra “estragos” acidentais. Esta garantia deve ser automática, sem a necessidade de implementação de procedimentos. Integridade de Domínio: O valor de um campo deve obedecer à definição de valores admitidos para o domínio da coluna. Domínios: número inteiro, número real, alfanumérico, data, etc Integridade de Nulo: Especifica se o valor de um campo pode ser nulo. Observação: Campos que compõem a PK não pode ser nulos Integridade de Chave: Define que os valores de chave primária e alternativa devem ser únicos. Integridade Referencial: Sistema de regras que garantem que os relacionamentos entre registros de tabelas permaneçam válidos. Os valores dos campos que aparecem em uma chave estrangeira (FK) devem aparecer na chave primária(PK) da tabela referenciada Observações: Não se pode entrar com valor de FK sem este existir como PK. Pode-se entrar com null para FK, especificando que os registros não estão relacionados. Não se pode REMOVER ou MODIFICAR um registro de uma tabela cuja PK seja referenciada como FK por outra tabela. Integridade Semântica: Exemplos:

• “Nenhum empregado pode ganhar mais do que seu gerente” • “O número máximo de horas que um empregado pode trabalhar por semana é 44 horas”

Observação: Pode ser implementada através de mecanismos como regras e triggers. Gatilho (banco de dados): Gatilho ou trigger é um recurso de programação em que sempre determinado evento associado ocorrer ele será disparado. Utilizada para ajudar a manter a consistência dos dados ou para propagar alterações em um determinado dado de uma tabela para outras. Um bom exemplo é um gatilho criado para controle de quem alterou a tabela, nesse caso, quando a alteração for efetuada, o gatilho é "disparado" e grava em uma tabela de histórico de alteração, o usuário e data/hora da alteração. MODELO DE ENTIDADES E RELACIONAMENTOS Modelo de Entidades e Relacionamentos é um modelo abstrato cuja finalidade é descrever, de maneira conceitual, os dados a serem utilizados em um Sistema de Informações ou que pertencem a um domínio. A principal ferramenta do modelo é sua representação gráfica, o Diagrama Entidade Relacionamento. Normalmente o modelo e o diagrama são conhecidos por suas siglas: MER e DER.



Aulas: 01 -‐ 13

INTRODUÇÃO AO MER O Modelo de Entidades Relacionamentos, segundo Paulo Cougo, descreve o mundo como: “...cheio de coisas que possuem características próprias e que se relacionam entre si”. Essas coisas podem ser pessoas, objetos, conceitos, eventos, etc. Elas são as entidades. A priori, só exigimos de uma entidade que ela possa ser identificada distintamente, isso é, tenha identidade própria. Cada coisa distintamente identificada é uma instância. Por exemplo, o funcionário José é uma instância da entidade funcionário, a aluna Maria é uma instância da entidade alunos. As entidades, ou melhor, suas instâncias, são classificadas em tipos (ou classes). No nosso caso, funcionário e aluno são os tipos de entidade. Estamos usando nesse momento a abstração de classificação: resumir uma quantidade de características comuns por meio da criação de uma classe. Assim sabemos que o funcionário José e o funcionário Joaquim, por serem instâncias de um mesmo tipo, possuem características comuns (como trabalhar na empresa, ter um salário, etc.). Durante a modelagem conceitual nos preocupamos com as “coisas” que o sistema deve lembrar e colocamos essas “coisas” no modelo de entidade e relacionamentos. Uma entidade deve ser relevante para o objetivo do negócio e necessária para a sua operação. Cada entidade tem dois tipos de características importantes: seus atributos e seus relacionamentos. Os atributos são características que toda a instância de um tipo possui, mas que podem variar entre as instâncias. Uma instância do tipo “aluno” tem os atributos “nome” e “ano de matrícula”, por exemplo. Atributos caracterizam a informação que deve ser guardada sobre uma entidade. Só devemos colocar como atributos aquelas informações que o sistema precisa lembrar em algum momento. Assim, uma instância de “aluno” não precisa ter o atributo “nome do animal de estimação” em um sistema acadêmico, pois apesar de ser algo importante para o “aluno” propriamente dito, não tem importância alguma para o sistema. Cada característica deve possuir um domínio. O domínio indica o conjunto de valores válidos para a característica. No caso de “nome”, geralmente aceitamos qualquer seqüência de caracteres, enquanto no caso de “altura” podemos aceitar apenas valores reais positivos menores que 2,5. Finalmente, como indica o nome do modelo, entidades podem se relacionar entre si. Essa característica é a principal força do modelo de entidades e relacionamentos. Podemos indicar relacionamentos apenas pelas entidades envolvidas, como “cliente-pedido”, ou usar um termo que descreva o relacionamento “cliente solicita pedido”. Modelos de Entidades e Relacionamentos para serem completos exigem também um conjunto de restrições. Algumas dessas restrições, como a cardinalidade dos relacionamentos que veremos a seguir, podem ser descritas em algumas (ou todas) notações. DIAGRAMA ENTIDADE RELACIONAMENTO É um modelo diagramático que descreve o modelo de dados de um sistema com alto nível de abstração. Ele é a principal representação do Modelo de Entidades e Relacionamentos. Sua maior aplicação é para visualizar o relacionamento entre tabelas de um banco de dados, no qual as relações são construídas através da associação de um ou mais atributos destas tabelas.

• MER: Conjunto de conceitos e elementos de modelagem que o projetista de banco de dados precisa conhecer.

• DER: Resultado do processo de modelagem executado pelo projetista de dados que conhece o MER. RELACIONAMENTOS ENTRE TABELAS Conforme descrito na Primeira parte, um banco de dados é composto por diversas tabelas, como por exemplo: Clientes, Produtos, Pedidos, Detalhes do Pedido, etc. Embora as informações estejam separadas em cada uma das Tabelas, na prática devem existir relacionamentos entre as tabelas. Por exemplo: Um Pedido é feito por um Cliente e neste Pedido podem existir diversos itens, itens que são gravados na tabela Detalhes do Pedido. Além disso cada Pedido possui um número único (Código do pedido), mas um mesmo Cliente pode fazer diversos pedidos e assim por diante. Em um banco de dados, precisamos de alguma maneira para representar estes relacionamentos da vida Real, em termos das tabelas e de seus atributos. Isto é possível com a utilização de "Relacionamentos entre tabelas", os quais podem ser de três tipos:

• Um para Um • Um para Muitos • Muitos para Muitos

RELACIONAMENTO DO TIPO UM PARA UM: Esta relação existe quando os campos que se relacionam são ambos do tipo Chave Primária, em suas respectivas tabelas. Cada um dos campos não apresenta valores repetidos. Na prática existem poucas situações onde utilizaremos um relacionamento deste tipo. Um exemplo poderia ser o seguinte: Imagine uma escola com um Cadastro de Alunos na tabela Alunos, destes apenas uma pequena parte participa da Banda da Escola. Por questões de projeto do Banco de Dados, podemos criar uma Segunda Tabela "Alunos da Banda", a qual se relaciona com a tabela Alunos através de um relacionamento do tipo Um para Um. Cada aluno somente é cadastrada uma vez na Tabela Alunos e uma única vez na tabela Alunos da Banda. Poderíamos utilizar o Campo Matrícula do Aluno como o Campo que relaciona as duas Tabelas. Importante: O campo que relaciona duas tabelas deve fazer parte, ter sido definido, na estrutura das duas tabelas.



Aulas: 01 -‐ 13

Na tabela Alunos da Banda poderíamos colocar apenas o Número da Matrícula do aluno, além das informações a respeito do Instrumento que ele toca, tempo de banda, etc. Quando fosse necessário buscar as informações tais como nome, endereço, etc, estas podem ser recuperadas através do relacionamento existente entre as duas tabelas, evitando, com isso, que a mesma informação (Nome, Endereço, etc) tenha que ser duplicada nas duas tabelas, inclusive aumentando a probabilidade de erros de digitação. Na Figura a seguir vemos o exemplo de um Relacionamento do tipo Um para Um entre as tabelas Alunos e Alunos da Banda.

Com a criação deste relacionamento estamos evitando a repetição desnecessária de informações em diferentes tabelas. RELACIONAMENTO DO TIPO UM PARA MUITOS: Este é, com certeza, o tipo de relacionamento mais comum entre duas tabelas. Uma das tabelas (o lado um do relacionamento é chamado de tabela pai) possui um campo que é a Chave Primária e a outra tabela (o lado Muitos é chamado de tabela filho) se relaciona através de um campo cujos valores relacionados podem se repetir várias vezes. Considere o exemplo entre a tabela Clientes e Pedidos. Cada Cliente somente é cadastrado uma única vez na tabela de Clientes (por isso o campo Código do Cliente, na tabela Clientes, é uma chave primária, indicando que não podem ser cadastrados dois clientes com o mesmo código), portanto a tabela Clientes será o lado um do relacionamento. Ao mesmo tempo cada cliente pode fazer diversos pedidos, por isso que o mesmo Código de Cliente poderá aparecer várias vezes na tabela Pedidos: tantas vezes quantos forem os pedidos que o Cliente tiver feito. Por isso que temos um relacionamento do tipo Um para Muitos entre a tabela Clientes e Pedidos, através do campo Código do Cliente, indicando que um mesmo Cliente pode realizar diversos (Muitos) pedidos. Na próxima figura vemos um exemplo de um Relacionamento Um para Muitos entre as Tabelas Clientes e Pedidos do banco de dados Pedidos.mdb, através do campo código do cliente:

No lado Um do relacionamento o campo é definido como uma Chave Primária (Campo CódigoDoCliente na tabela Clientes) e no lado Muitos não (campo CódigoDoCliente na tabela Pedidos), indicando que no lado Muitos o Código do Cliente pode se repetir várias vezes, o que faz sentido, uma vez que um mesmo cliente pode fazer diversos pedidos. IMPORTANTE: Observe que o campo que é o lado Muitos do relacionamento não pode ser definido como chave primária. Lembrando do conceito de Chave Primária, (Chave Primária é o campo no qual não podem haver valores repetidos). Ora, se o campo está no lado "Muitos", significa que ele poderá ter o seu valor repetido em vários registros. Por exemplo, na tabela pedidos, poderá haver vários registros para o mesmo cliente. Se o campo terá que ter valores repetidos, então ele não pode ser definido como chave primária. Existem diversos outros exemplos de relacionamentos do tipo Um para Vários, conforme descrito na Próxima Tabela:

Tipo Lado Um Lado Vários

Um para Vários CódigoDoFornecedor na tabela Fornecedores CódigoDoFornecedor na tabela Produtos

Um para Vários CódigoDaCategoria na tabela Categorias CódigoDaCategoria na tabela Produtos

Um para Vários CódigoDoCliente na tabela Clientes CódigoDoCliente na tabela Pedidos

Um para Vários CódigoDoFuncionário na tabela Funcionários CódigoDoFuncionário na tabela Pedidos



Aulas: 01 -‐ 13

Sempre o Lado um do Relacionamento deve ser uma chave primária, já o lado Muitos não pode ser uma chave Primária. RELACIONAMENTO DO TIPO MUITOS PARA MUITOS: Este tipo de relacionamento "aconteceria" em uma situação onde em ambos os lados do relacionamento os valores poderiam se repetir. Vamos considerar o caso entre Produtos e Pedidos. Posso ter Vários Pedidos nos quais aparece um determinado produto, além disso, vários Produtos podem aparecer no mesmo Pedido. Esta é uma situação em que temos um Relacionamento do Tipo Vários para Vários. Na prática não é possível implementar um relacionamento deste tipo, devido a uma série de problemas que seriam introduzidos no modelo do banco de dados. Por exemplo, na tabela Pedidos teríamos que repetir o Número do Pedido, Nome do Cliente, Nome do Funcionário, Data do Pedido, etc para cada item do Pedido. Para evitar este tipo de problema é bastante comum "quebrarmos" um relacionamento do tipo Muitos para Muitos em dois relacionamento do tipo Um para Muitos. Isso é feito através da criação de uma nova tabela, a qual fica com o lado Muitos dos relacionamentos. No nosso exemplo vamos criar a tabela Detalhes do Pedido, onde ficam armazenadas as informações sobre os diversos itens de cada pedido, aí ao invés de termos um relacionamento do tipo Muitos para Muitos, teremos dois relacionamentos do tipo um para vários, conforme descrito pela próxima tabela:

Tipo Lado Um Lado Muitos

Um para Vários CódigoDoProduto na tabela Produtos CódigoDoProduto na tabela Detalhes do Pedido

Um para Vários NúmeroDoPedido na tabela Pedidos NúmeroDoPedido na tabela Detalhes do Pedido

Na figura abaixo temos a representação dos dois relacionamentos Um para Muitos, resultantes da quebra do relacionamento Muitos para Muitos:

Esta situação em que um relacionamento um para Muitos é "quebrado" em dois Relacionamentos do tipo Um para Muitos é bastante comum. Diversas vezes utilizamos esta técnica para eliminar uma série de problemas no Banco de Dados, tais como informação repetida e inconsistência de Dados. Resumo • Relação 1..1 (lê-se relação um para um) - indica que as tabelas têm relação unívoca entre si. Você escolhe

qual tabela vai receber a chave estrangeira; • Relação 1..n (lê-se um para muitos) - a chave primária da tabela que tem o lado 1 vai para a tabela do lado

N. No lado N ela é chamada de chave estrangeira; • Relação n..n (lê-se muitos para muitos) - 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.

Sempre que você relacionar duas tabelas de chaves primárias com tipos de dados diferentes, será necessário criar uma tabela de associação entre elas. Por exemplo: uma tabela de fornecedores (Chave primária é o código de fornecedor) e uma tabela de produtos (chave primária é o código do produto). Se você precisar saber quais fornecedores vendem um produto ou quiser saber quais produtos são vendidos por um fornecedor, você precisará criar uma tabela de associação cuja chave deverá ser, obrigatoriamente, o código do fornecedor mais o código do produto. Essa chave composta da tabela associativa é chamada de chave estrangeira. MODELAGEM DE DADOS MULTIDIMENSIONAL. Modelagem multidimensional é a técnica de projeto lógico de banco de dados mais usada no desenvolvimento de data warehouses, embora também possa ser aplicada ao projeto de sistemas de informações operacionais. Na verdade, ela busca apresentar os dados em um formato que seja intuitivo e ao mesmo atenda a acessos com um alto desempenho. Um modelo multidimensional é composto por uma tabela com uma chave composta, denominada tabela de fatos, e um conjunto de tabelas menores conhecidas como tabelas de dimensão, que possuem chaves simples (formadas por uma única coluna). Na verdade, a chave da tabela de fatos é uma combinação das chaves das tabelas de dimensão. A idéia fundamental da modelagem dimensional está baseada no fato de que quase todo tipo de dado do negócio pode ser representado como uma espécie de cubo de dados, onde as células do cubo contêm os valores medidos e os lados do cubo definem as dimensões naturais dos dados.



Aulas: 01 -‐ 13

O modelo dimensional é formado por uma tabela central (tabela de fatos) e várias outras a ela interligadas (tabelas de dimensão), sempre por meio de chaves especiais, que associam o fato a uma dimensão do cubo. • Dimensões: estabelecem a organização dos dados, determinando possíveis consultas/cruzamentos. Por

exemplo: região, tempo, canal de venda,... Cada dimensão pode ainda ter seus elementos, chamados membros, organizados em diferentes níveis hierárquicos. A dimensão tempo, por exemplo, pode possuir duas hierarquias: calendário gregoriano (com os níveis ano, mês e dia) e calendário fiscal (com os níveis ano, semana e dia);

• Medidas: são os valores a serem analisados, como médias, totais e quantidades; • Fatos: são os dados a serem agrupados, contendo os valores de cada medida para cada combinação das

dimensões existentes. O tamanho da tabela que contém os fatos merece atenção especial do analista; • Agregações: totalizações calculadas nos diversos níveis hierárquicos. CONCEITOS E ESTRATÉGIAS DE IMPLANTAÇÃO DE DATA WAREHOUSE O Data Warehouse é uma espécie de grande banco de dados contendo dados extraídos do ambiente de produção da empresa, que foram selecionados e depurados, tendo sido otimizados para processamento de consulta e não para processamento de transações. Em geral, um Data Warehouse requer a consolidação de outros recursos de dados além dos armazenados em banco de dados relacionais, incluindo informações provenientes de planilhas eletrônicas, documentos textuais, etc. A definição clássica de Data Warehouse criada por Inmon (1997) é a seguinte: “Data Warehouse é uma coleção de dados orientada por assuntos, integrada, variante no tempo, e não volátil que tem por objetivo dar suporte aos processos de tomada de decisão.” A função do Data Warehouse é tornar as informações corporativas acessíveis para o seu entendimento, gerenciamento e uso. Como o Data Warehouse está separado dos Bancos de Dados operacionais, as consultas dos usuários não impactam nestes sistemas, que ficam resguardados de alterações indevidas ou perdas de dados. O Data Warehouse não deve ser tratado como um software, que pode ser comprado e instalado em todos os computadores da empresa em algumas horas. Na realidade, sua implantação exige a integração de vários produtos e processos. Nos últimos anos o Data Warehouse vem oferecendo às organizações uma maneira flexível e eficiente de obter as informações que os gestores necessitam, nos processos decisórios caracterizando-se como uma função de apoio à decisão. A extração, limpeza, transformação e migração de dados dos sistemas existentes na empresa para o Data Warehouse constituem tarefas críticas para o seu funcionamento efetivo e eficiente. Diversas técnicas e abordagens têm sido propostas, algumas bastante genéricas e outras especialmente voltadas para a manutenção de integridade dos dados num ambiente caracterizado pela derivação e replicação de informações. Os produtos oferecidos no mercado procuram automatizar processos que teriam de ser feitos manualmente ou utilizando ambientes de programação de mais baixo nível. De fato, não existe uma ferramenta única capaz de oferecer suporte aos processos de extração, limpeza, transformação e migração dos dados, diferentes ferramentas especializam-se em questões específicas. O grande desafio por trás da alimentação de dados das fontes para o Data Warehouse não é técnico, mas gerencial. Muitos dos processos envolvidos - como mapeamento, integração e avaliação de qualidade - ocorrem de fato durante a fase de análise e projeto do Data Warehouse. Especialistas afirmam que identificar fontes, definir regras de transformação e detectar e resolver questões de qualidade e integração consomem cerca de 80% do tempo de projeto. Infelizmente, não é fácil automatizar estas tarefas. Embora algumas ferramentas possam ajudar a detectar problemas na qualidade dos dados e gerar programas de extração, a maioria das informações necessária para desenvolver regras de mapeamento e transformação existe apenas na cabeça dos analistas e usuários.



Aulas: 01 -‐ 13

Fatores que certamente influem na estimativa de tempo para estas tarefas são o número de fontes e a qualidade dos metadados mantidos sobre estas fontes. As regras de negócio associadas a cada fonte - tais como validação de domínios, regras de derivação e dependências entre elementos de dados – são outra fonte de preocupações. Se estas regras tiverem de ser extraídas do código fonte das aplicações, o tempo para mapeamento e integração pode dobrar.

OLAP OLAP (On-Line Analytical Processing) representa um conjunto de tecnologias projetadas para suportar análise e consultas ad hoc. Sistemas OLAP ajudam analistas e executivos a sintetizarem informações sobre a empresa, através de comparações, visões personalizadas, análise histórica e projeção de dados em vários cenários de "e se...". Sistemas OLAP são implementados para ambientes multi-usuário, arquitetura cliente-servidor e oferecem respostas rápidas e consistentes às consultas iterativas executadas pelos analistas, independente do tamanho e complexidade do banco de dados. A característica principal dos sistemas OLAP é permitir uma visão conceitual multi-dimensional dos dados de uma empresa. A visão multi-dimensional é muito mais útil para os analistas do que a tradicional visão tabular utilizada nos sistemas de processamento de transação. Ela é mais natural, fácil e intuitiva, permitindo a visão em diferentes perspectivas dos negócios da empresa e desta maneira tornando o analista um explorador da informação. A modelagem dimensional é a técnica utilizada para se ter uma visão multidimensional dos dados. Nesta técnica os dados são modelados em uma estrutura dimensional conhecida por cubo. As dimensões do cubo representam os componentes dos negócios da empresa tais como "cliente", "produto", "fornecedor" e "tempo". A célula resultante da interseção das dimensões é chamada de medida e geralmente representa dados numéricos tais como "unidades vendidas", "lucro" e "total de venda". Além dos componentes dimensão e medida outro importante aspecto do modelo multidimensional é a consolidação dos dados uma vez que para a tarefa de análise são mais úteis e significativas as agregações (ou sumarização) dos valores indicativas dos negócios. DATA MINING Conhecido também como mineração de dados. Sua função principal é a varredura de grande quantidade de dados a procura de padrões e detecção de relacionamentos entre informações gerando novos sub-grupos de dados. Usado comumente em grandes bancos de dados. Por enquanto podemos pensar que Data Mining é como um agregador e organizador de dados. Data Mining pode ser utilizado com os seguintes objetivos:

• Explanatório: explicar algum evento ou medida observada, tal como porque a venda de sorvetes caiu no Rio de Janeiro;

• Confirmatório: confirmar uma hipótese. Uma companhia de seguros , por exemplo, pode querer examinar os registros de seus clientes para determinar se famílias de duas rendas tem mais probabilidade de adquirir um plano de saúde do que famílias de uma renda;

• Exploratório: analisar os dados buscando relacionamentos novos e não previstos. Uma companhia de cartão de crédito pode analisar seus registros históricos para determinar que fatores estejam associados a pessoas que representam risco para créditos.

Quando determinados padrões de comportamento, como associação de produtos durante um processo de compras, por exemplo, começam a se repetir com freqüência, as ferramentas Data Mining indicam a presença de oportunidades e "insights" em relação àquele público consumidor. O diferencial do Data Mining está no fato de que as descobertas de padrões de consumo se dão por uma lógica de algoritmos com base em uma rede neural de raciocínios. São ferramentas de descobertas matemáticas feitas sobre os registros corporativos já processados contra descobertas empíricas.



Aulas: 01 -‐ 13

ETL Também conhecidas como ferramentas de “Back End”, estas ferramentas são fundamentais para o processo de Business Intelligence, e são responsáveis pela preparação dos dados a serem armazenados em um Data Warehouse. O processo de ETL se resume basicamente em 5 passos:

1. Identificação da origem dos dados a serem coletados, sendo que as fontes podem estar espalhadas em diversos sistemas transacionais e banco de dados da organização;

2. Realizar a limpeza dos dados para possibilitar posterior transformação, e nesta etapa ocorre os ajustes nos dados, com o intuito de corrigir imperfeições com o objetivo de oferecer um melhor resultado para o usuário final;

3. A terceira etapa é de transformação dos dados e tem por objetivo fazer a padronização dos dados em um único formato;

4. A fase seguinte é de carga dos dados para o Data Warehouse; 5. Por fim, existe a etapa de atualização dos dados no DW (refresh), realizada a partir das alterações

sofridas pelos dados nos sistemas operacionais da organização. É importante salientar que a etapa de ETL é uma das mais críticas de um Data Warehouse, pois envolve a fase de movimentação dos dados.

BUSINESS INTELLIGENCE. O conceito de Business Intelligence com o entendimento de que é Inteligência de Negócios ou Inteligência Empresarial compõe-se de um conjunto de metodologias de gestão implementadas através de ferramentas de software, cuja função é proporcionar ganhos nos processos decisórios gerenciais e da alta administração nas organizações, baseada na capacidade analítica das ferramentas que integram em um só lugar todas as informações necessárias ao processo decisório. Reforça-se que o objetivo do Business Intelligence é transformar dados em conhecimento, que suporta o processo decisório com o objetivo de gerar vantagens competitivas. Podemos relacionar como características principais dos sistemas de Business:

• extrair e integrar dados de múltiplas fontes; • fazer uso da experiência; • analisar dados contextualizados; • trabalhar com hipóteses; • procurar relações de causa e efeito; • transformar os registros obtidos em informação útil para o conhecimento empresarial.



Aulas: 01 -‐ 13

GERENCIAMENTO DE PROCESSOS DE NEGÓCIO A Gestão ou Gerenciamento de processos de negócio, também conhecido por BPM (Business Process Management) é o conceito que possibilita a identificação de problemas e ineficiências dentro da empresa. Ele une gestão de negócios e tecnologia da informação, o que permite uma melhoria nos resultados das organizações e em seu planejamento estratégico, já que a empresa poderá definir quais são os processos e ações relevantes que poderão contribuir para o seu crescimento. Conseguir que as estratégias tomadas pelas empresas obtenham os resultados esperados é um desafio para qualquer organização, por isso os gestores estão sempre em busca das melhores soluções para uma mudança organizacional considerável. Conheça algumas ações relacionadas a Gestão de Processo de Negócio:

• Mapeamento dos processos – tem como objetivo coletar dados quantitativos, priorizar o detalhamento e identificar os atributos dos processos e sua eficácia.

• O monitoramento através de indicadores de desempenho – mede e melhora os modelos de controle que serão utilizados, consolidando os dados e gerando informações úteis.

• O ciclo de melhoria contínua – acompanha o atendimento e seu alinhamento com as metas estratégicas da organização, o que garante um modelo de operação que não ofereça perda de eficiência ou riscos ao negócio.

Para o sucesso do BPM , é necessário que se assuma uma nova postura com foco principalmente nas pessoas, afinal, este é um processo organizacional que precisa ser avaliado e alinhado a certos princípios de evolução e atualização. Ele precisa da participação de todos, desde funcionários até gerentes e sócios, além da integração de um software específico que atenda a demanda de trabalho da organização. Apesar da implantação da gestão de processos de negócio nas organizações ser algo abrangente e complexo, quando bem aplicada, traz diversos benefícios, como a agilidade nas operações e resultados mais eficientes dos negócios, para tanto são utilizados métodos, técnicas e ferramentas para analisar, modelar, publicar, otimizar e controlar processos envolvendo recursos humanos, aplicações, documentos e outras fontes de informação. O QUE É PROCESSO Processo é qualquer atividade ou conjunto de atividades que toma uma entrada, adicionando a esta um valor, e fornece uma saída gerando um produto valorado. Então, em um processo são conhecidos os passos a serem seguidos, as sequências em que eles acontecerão, as pessoas (ou perfil) envolvidas em todas as atividades e o produto final a ser produzido.

A Norma ISO 9000:2000 requer que as organizações adotem a abordagem por processos e explicita a intenção da Organização Internacional para Normalização Técnica de encorajar a adoção desta abordagem para a gerência de uma organização. No entanto, é importante ressaltar que uma estrutura organizacional baseada em processos é uma estrutura alicerçada no modo em que o trabalho é executado, não em torno de habilitações específicas departamentalizadas.

CONJUNTO DE ATIVIDADES TRANSFORMAÇÃO PRODUTO

VALORADO



Aulas: 01 -‐ 13

MODELAGEM DE PROCESSOS A modelagem de processos tem como objetivo principal descrever as atividades que fazem parte de um processo e como elas se relacionam para atingir seu objetivo final. As atividades são tarefas que tanto podem ser realizadas manualmente como mecanicamente. É importante não confundir a modelagem com a engenharia de processos, uma vez que a modelagem não tem o objetivo de indicar como um processo deve funcionar, sendo apenas uma técnica utilizada para visualizar e documentar o funcionamento de um processo. TÉCNICAS DE ANÁLISE E MODELAGEM DE PROCESSO O sucesso da modelagem de processos depende da seleção apropriada da metodologia de modelagem ou técnica de análise do fluxo de processo. Existe um grande número de metodologias ou técnicas de análise usadas neste campo, tais como:

• gráficos de processos gerais, • gráficos de atividades de processo, • fluxogramas, • diagramas de fluxo de dados, • desenvolvimento da função qualidade (QFD), • definição integrada de modelagem de função (IDEF), • redes petri coloridas, • métodos orientados a objeto, • sete ferramentas de gerenciamento e planejamento,

BPM – BUSINESS PROCESS MODELING Business Process Modeling Notation (BPMN) ou simplesmente BPM, é uma notação gráfica que descreve a lógica dos passos de um processo de negócio. Essa notação tem sido especialmente desenhada para coordenar a sequência dos processos e as mensagens que fluem entre os participantes das diferentes atividades.

O objetivo do BPMN é dar suporte ao gerenciamento de processo de negócio, tanto para os usuários técnicos quanto para os usuários de negócio, fornecendo uma notação intuitiva para os usuários, tornando-os capazes de representarem semânticas de processos complexos.

POR QUE MODELAR COM BPMN? • BPMN é um padrão internacional de modelador de processos aceito pela comunidade. • BPMN é independente de qualquer metodologia de modelador de processos. • BPMN cria uma ponte padronizada para diminuir a lacuna entre os processos de negócio e sua

implementação. • BPMN permite modelar o processo de uma maneira unificada e padronizada.

TIPOS DE DIAGRAMAS: A modelagem de processo de negócio é usada para comunicar uma ampla variedade de informações para uma ampla variedade de público. O BPMN está projetado para cobrir muitos tipos de modelagens e permite a criação de um processo de negócios de ponta a ponta. Os elementos estruturais do BPMN permitirão ao observador ser capaz de facilmente identificar as seções de um diagrama de BPMN. Existem três tipos básicos de diagrama de processo de negócio (BPD):

Private (internal) business process – ou diagramas de processo de negócios privados. Nós o utilizamos quando não é do nosso interesse a interação desse processo com outros com os quais ele possa interagir. Estamos preocupados com o teor deste fluxo em si.



Aulas: 01 -‐ 13

Abstract (Public) Process – ou processos abstratos, representam uma interação entre um processo de negócio privativo e outro processo ou participante. Não estamos preocupados com o conteúdo do fluxo em si, mas sim como ele colabora com os outros fluxos dentro de um sistema

Colaboration (Global) Process – O processo colaborativo descreve a interação entre dois ou mais entidades do negócio. Estas interações são definidas como uma sequência de atividades que representa o padrão de trocas de mensagens entre as atividades envolvidas.

O processo colaborativo pode ser entendido como sendo dois ou mais processos abstratos comunicando entre si. E no processo abstrato, as atividades que são as participantes na colaboração podem ser consideradas como sendo os pontos de contato entre os participantes.ELEMENTOS DE UM BPD



Aulas: 01 -‐ 13

O principal objetivo para o desenvolvimento do BPMN é que fosse uma notação simples e adaptável para os analistas de negócio. Para ajudar a entender como o BPMN pode gerenciar as necessidades da organização, a lista de elementos gráficos do BPMN é apresentada em dois grupos. Existe a lista de elementos essenciais (CORE ELEMENTS) que irá suportar os requerimentos necessários para uma notação simples. Estes são os elementos que definem o layout básico do BPMN. Muitos processos de negócios poderão ser modelados adequadamente com estes elementos. Há também uma lista completa de elementos, os quais ajudarão a suportar requerimentos de uma poderosa notação para gerenciar situações mais avançadas.

ELEMENTOS ESSENCIAIS Enfatizando, novamente, que o objetivo do desenvolvimento do BPMN foi o de permitir por meio de um mecanismo simples a criação de modelos de processos de negócio, enquanto que ao mesmo tempo seja capaz de manipular a complexidade inerente de um processo de negócio. A abordagem empregada para manipular estes dois requerimentos conflitantes foi organizar as figuras gráficas para anotação dentro de categorias específicas. O BPMN fornece um pequeno conjunto de categorias para que o usuário possa facilmente identificar os tipos básicos dos elementos e entender o diagrama. Dentro dessas categorias básicas de elementos, informações e modificações adicionais podem ser adicionadas para apoiar as necessidades da complexidade sem alterar drasticamente a aparência do diagrama. As categorias dos elementos são:

• Objetos de Fluxo (Flow Objects) • Objetos de Conexão (Connecting Objects) • Raia de piscina (Swimlanes) • Artefatos (Artifacts)

Objetos de Fluxos (Flow Objects)

Os objetos de fluxos são os principais elementos gráficos para definir o comportamento do processo de negócio. Existem três tipos de objetos de fluxos:

• Eventos (events) • Atividades (Activities) • Decisões (Gateways)

Objetos de Conexão (Connecting Objects)

A conexão dos objetos de fluxos com outra informação é realizada por meio de três objetos: • Fluxo de sequência (sequence Flow) • Fluxo de mensagem (Message Fluxo) • Associação (Association)

Raia de piscina (Swimlanes):

Existem duas maneiras de agrupar os elementos de modelagem básica por meio dos Swimlanes: • Pool (piscina) • Lane (raia)

Artefatos (Artifacts) Os artefatos são usados para fornecer informações adicionais sobre o processo. Existem quatro artefatos padronizados, mas os fabricantes de software de modelagem estão livres para adicionar outros artefatos. O conjunto corrente de artefatos inclui:

• Objeto de Dados (Data Object) • Grupos (Group) • Anotação (Annotation)



Aulas: 01 -‐ 13

LISTA DOS ELEMENTOS ESSENCIAIS DE MODELAGEM QUE SÃO DESCRITAS NA NOTAÇÃO:

Categorias Elemento Descrição Notação O

bjet

os d

e Fl

uxo

Eventos (events)

Um evento é “alguma coisa” que acontece durante o curso de um processo de negócio. Esses eventos afetam o fluxo do processo e usualmente tem uma causa (Gatilho) ou um impacto (resultado). Eventos são representados por círculos vazados para permitir sinalização que identificarão os Gatilhos ou resultados. Existem três tipos eventos:

• Inicio • Intermediário • Final

Atividades (Activities)

Atividade é um termo genérico para o trabalho que a empresa realiza. Uma atividade pode ser atômica ou não atômica (composta). Os tipos de atividades que fazem parte de um processo de negócio são: Processos, Subprocessos e Tarefas. Tarefas e Sub-Processos são representados por um retângulo arredondado. Os processos podem ser representados ou por um retângulo arredondado ou incluído dentro de um POOL.

Decisões (Gateways)

Uma Decisão é usada para controlar as ramificações e os encontros dos Fluxos de sequência (sequence Flow). Desta forma, ele irá determinar as ramificações, consolidações e união dos caminhos. A sinalização gráfica interna ao desenho irá indicar o tipo de comportamento da decisão.

Obj

etos

de

Con

exão

Fluxo de sequência (sequence

Flow)

O Fluxo de seqüência é usado para mostrar a ordem em que as atividades serão processadas.

Fluxo de mensagem (Message

Fluxo)

Um Fluxo de mensagem é usado para mostrar o fluxo de uma mensagem entre dois participantes que estão preparados para mandar ou recebê-las. No BPMN, dois Pools (piscinas) no diagrama representam os dois participantes.

Associação (Association)

Uma Associação é usada para relacionar informações com os objetos de fluxo. Textos e gráficos que não fazem parte do fluxo podem ser associados com os objetos de fluxo.

Rai

a de

pis

cina

Pool (piscina) Black box

Um Pool (piscina) representa um participante dentro do processo. Ele também atua como uma “Swimlane” e um recipiente gráfico para separar um conjunto de atividades de outro Pool, geralmente em um contexto de situação de B2B.

Lane (raia)

Uma Lane (raia) é uma subpartição dentro de um Pool (piscina) e irá ampliar o tamanho de um Pool (piscina) horizontalmente ou verticalmente. Lane (raia) são usadas para organizar e categorizar as atividades.



Aulas: 01 -‐ 13

Art

efat

os

Objeto de Dados (Data

Object)

Objetos de Dados (Data Object) são considerados artefatos porque eles não têm nenhum efeito direto sobre o fluxo de sequência ou fluxo de mensagem do processo, mais eles podem fornecer informações sobre o que a atividade necessita para ser executada ou/e o que elas produzem.

Grupo (Group) – Uma caixa que circunda um grupo de objetos para propósito de

documentação

É um agrupamento de atividades que não afeta a sequência do fluxo. O agrupamento pode ser usado para o propósito de documentação ou análise. Os Grupos (Group) podem também ser usados para identificar as atividades de uma transação distribuída através de várias Pools.

Anotação (Annotation) Ligada com

uma associação

Uma Anotação (Annotation) de texto é um mecanismo para que o modelador forneça informações adicionais para facilitar a leitura do diagrama por parte do usuário.

MODELANDO EVENTOS DE NEGÓCIO Durante a modelagem de negócio, você modela eventos que acontecem no seu negócio e mostra como eles interferem no fluxo do processo. Um evento pode ser o ponta-pé inicial de um processo, pode acontecer durante o fluxo do processo e finalizar o processo. O BPMN fornece uma notação diferente para cada um desses tipos de eventos como mostrado na tabela abaixo:

Notação básica de tipos de eventos Evento de Início

(Start Events) Evento Intermediário (Intermedate Events)

Evento de Fim (End Events)

Inicia um processo

Acontece durante o

curso de um processo

Finaliza o fluxo do processo

Eventos mais complexos

Quando você modela fluxos de processos mais complexos, você necessita modelar eventos de processos mais complexos também, tais como mensagens, cronômetros ou temporizadores, regras de negócios e condições de erro. O BPMN permite que você especifique o tipo de Gatilho (start) do evento e o simbolize com um ícone representativo, como especificado na tabela abaixo. Especificar um tipo de gatilho para um evento coloca certas restrições no fluxo de processo que você está modelando, conforme especificado na tabela. Por exemplo, um temporizador não pode ser usado para finalizar um fluxo do processo. Evento de Início Evento

Intermediário Evento de Fim Descrição

Mensagem de início

Mensagem

Mensagem de fim

Uma mensagem de início chega de um participante ou gatilho de início do processo, ou continua o processo, neste caso um

evento intermediário. Uma mensagem de fim denota a mensagem que será gerada ao fim do processo.

Temporizador de início

Temporizador

O temporizador não pode ser um evento

de fim

Um tempo específico ou ciclo (por exemplo, a cada segunda-feira às 9:00AM) pode ser ajustado para realizar o início de

um processo, ou a continuação do processo, no caso de evento intermediário.

Regra de início

Regra

A regra não pode ser um evento de fim

O evento é iniciado quando a condição da regra for verdadeira, tal como “faça novo pedido quando a quantidade

do estoque for menor de 10%”.

A Ligação não pode ser um evento de

Início

Ligação

A Ligação não pode ser um evento de fim

É usado para conectar atividade de um mesmo processo com

a finalidade de deixar o diagrama mais limpo.

Múltiplo Início Múltiplo Múltiplo Fim Para um evento de múltiplo início, existem múltiplas maneiras



Aulas: 01 -‐ 13

de desencadear o processo, ou de continuar o processo, no caso do evento intermediário. Somente uma delas é

necessária. O atributo do evento define qual gatilho é acionado. Para Múltiplo Fim, existe múltiplas consequências na finalização do processo, todos os quais irão ocorrer, como

por exemplos, múltiplas mensagens enviadas.

A exceção não pode ser um evento de

Início

Exceção

Exceção no fim

Um evento de exceção no fim informa ao mecanismo do processo que um erro deverá ser criado. Este erro deverá ser um evento e exceção intermediária. No evento de exceção intermediária ele só

poderá ser usado conectado na borda de uma atividade.

Uma Compensação não pode ser um evento de Início

Compensação

Compensação no fim

Um evento de compensação de fim informa ao mecanismo do processo que uma compensação é necessária. Assim o

identificador da compensação é usado pelo evento intermediário quando o processo está sofrendo um roll back.

Um cancelamento não pode ser um evento de Início

Cancelamento

Cancelar no fim

O evento de fim significa que o usuário decidiu cancelar o processo. O processo é finalizado com um tratamento de evento normal.

Não se aplica Não se aplica

Terminar

Este tipo de fim indica que todas as atividades dentro do processo deverão ser imediatamente finalizadas. Isto inclui todas as instâncias das múltiplas instâncias. O processo é

finalizado sem compensação ou tratamento de evento. Sinal de Inicio

Sinal

Sinal no fim

Um sinal é usado para gerar comunicação dentro ou por meio de níveis de processos, Pools e entre diagramas de

processos.

DECOMPONDO SEU PROCESSO DENTRO DE HIERARQUIAS Um processo é uma rede de “ações acontecendo”. No BPMN você o desenha com um retângulo arredondado como sendo seu nível mais alto no diagrama de processo de negócio. Você pode especificar os detalhes internos do processo criando ou ligando-o a outro diagrama de processo de negócio. Um processo que tem um diagrama filho recebe um sinal de ‘+’ no seu desenho. Graficamente mostramos os detalhes de um processo como outro diagrama de processo de negócio que é considerado como ‘decomposição’ do processo. Você pode continuar a decompor processo sem nenhuma restrição. Processos que você desenha como sendo diagrama ‘filho’ são considerados Subprocessos. O menor nível do processo, o qual não pode ser mais decomposto, é considerado como sendo uma tarefa. Uma atividade representa o trabalho realizado dentro de um processo. Uma atividade normalmente levará algum tempo para ser realizada, envolverá pessoas e recursos (sistema de informática - Aplicação) e normalmente irá produzir algum tipo de saída.

Atividades – Tarefa

Genérico ou Indefinido, Frequentemente usado durante o estágio inicial do desenvolvimento do processo.

Manual, é uma Tarefa não-automática realizada por humano fora do controle do WorkFlow ou da solução BPM.

Receber Mensagem, espera uma mensagem chegar de um participante externo (relacionado com o processo de negócio). Uma vez recebida a tarefa é completada. Seu comportamento é similar ao evento de chegada de mensagem.

Script, realiza um Script.

Envia Mensagem, dispara uma mensagem a um participante externo. Uma vez enviada a mensagem a tarefa é completada. Seu comportamento é similar ao evento de envio de mensagem.

mar

cio lu

is ho

llweg

corre

7713

1290

068

mar

cio lu

is ho

llweg

corre

7713

1290

068

mar

cio lu

is ho

llweg

corre

7713

1290

068

mar

cio lu

is ho

llweg

corre

7713

1290

068

m a r c i o l u i s h o l l w e g c o r r e 7 7 1 3 1 2 9 0 0 6 8

m a r c i o l u i s h o l l w e g c o r r e 7 7 1 3 1 2 9 0 0 6 8

O conteúdo deste curso é de uso exclusivo de marcio luis hollweg corre77131290068, vedada, por quaisquer meios e a qualquer título, a suareprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.

TECNOLOGIA DA INFORMAÇÃO PARA ICMS/PR (TEORIA E EXERCÍCIOS)

PROFa. PATRÍCIA LIMA QUINTÃO

Profa. Patrícia Lima Quintão www.pontodosconcursos.com.br 23 de 55

Atividades – Tarefa

Genérico ou Indefinido, frequentemente usado durante o estágio inicial do desenvolvimento do processo.

Uma Tarefa que não é automática, realizada por humano fora do controle do WorkFlow ou da solução BPM.

Espera uma mensagem chegar de um participante externo (relacionado com o processo de negócio). Uma vez recebida a tarefa é completada. Seu comportamento é similar ao evento de chegada de mensagem.

Dispara uma mensagem a um participante externo. Uma vez enviada a mensagem a tarefa é completada. Seu comportamento é similar ao evento de envio de mensagem.

Ligado a algum serviço, o qual pode ser um web service ou uma aplicação automática.

Típica tarefa realizada por um humano com auxílio de uma aplicação.

Atividades – Subprocesso

Estado Contraído

Estado Expandido

LOOP PADRÃO

Fonte: [6]



Aulas: 01 -‐ 13

Serviço, ligado a algum serviço, o qual pode ser um web service ou uma aplicação automática.

Usuário, típica tarefa realizada por um humano com auxílio de uma aplicação.

Atividades – Subprocesso

Estado Contraído

Estado Expandido

LOOP PADRÃO



Aulas: 01 -‐ 13

GESTÃO ESTRATÉGICA Podemos considerar que planejamento é uma forma de organizar idéias com relação a um certo tema e estabelecer objetivos e metas, com o propósito de se atingir um determinado resultado. Este tipo de conceito é bastante conhecido, afinal desde que o mundo é mundo, o ser humano utiliza, mesmo que intuitivamente, alguma forma de planejamento para sobreviver e mais, para antecipar-se a eventos, tomando decisões que lhe pareçam as mais acertadas. TIPOS DE PLANEJAMENTO Em uma organização são apresentados três tipos de Planejamento:

• Estratégico: compreende os altos executivos da organização, responsáveis pela definição dos objetivos e planos da empresa, e tomada de decisões quanto às questões de longo prazo da empresa (sobrevivência, crescimento e eficácia geral)

• Tático: é utilizado para traduzir os objetivos gerais e as estratégias da alta diretoria em objetivos e atividades mais específicos. O principal desafio neste nível é promover um contato eficiente e eficaz entre o nível estratégico e o nível operacional.

• Operacional: neste nível o processo é de uma menor amplitude, onde o foco é trabalhar junto aos funcionários não administrativos, implementando os planos específicos definidos no planejamento tático.

PLANEJAMENTO ESTRATÉGICO Uma das grandes dificuldades das empresas é a conceituação da função do planejamento estratégico, em especial sua real amplitude e abrangência. Segundo Kotler (1992, p.63), “planejamento estratégico é definido como o processo gerencial de desenvolver e manter uma adequação razoável entre os objetivos e recursos da empresa e as mudanças e oportunidades de mercado”. O objetivo do planejamento estratégico é orientar e reorientar os negócios e produtos da empresa de modo que gere lucros e crescimento satisfatórios. Já Drucker (1977) define Planejamento Estratégico como um processo contínuo, sistemático, organizado e capaz de prever o futuro, de maneira a tomar decisões que minimizem riscos. Uma outra conceituação interessante apresenta o planejamento estratégico “como um processo administrativo para se estabelecer a melhor direção a ser seguida pela empresa, visando ao otimizado grau de fatores externos – não controláveis – e atuando de forma inovadora e diferenciada” (Oliveira – 2007)

Independente do autor fica claro que o planejamento estratégico é um conjunto de ferramentas que por si só são insuficientes, mas quando é seguido de planejamentos táticos e operacionais, consiste em robusta ferramenta para implementar o pensamento estratégico da organização.



Aulas: 01 -‐ 13

De uma maneira geral, o planejamento estratégico é responsabilidade dos níveis hierárquicos mais elevados da empresa/organização, o planejamento tático é desenvolvido pelos níveis intermediários, tendo como principal finalidade a utilização eficiente dos recursos disponíveis e o planejamento operacional é elaborado pelos níveis mais baixos da organização. ANÁLISE SWOT Observamos que as organizações sofrem influências de diversos fatores, sejam eles internos ou externos, desta maneira o planejamento estratégico, deve tratar de uma análise ambiental, isto irá ajudar a verificar as tendências, servirá como base para a análise de cenários sempre levando em conta aspectos econômicos, políticos, legais, tecnológicos, socioculturais, etc.. Todas as Organizações possuem, no seu ambiente interno, Pontos Fortes e Pontos Fracos. Também estão sujeitas a várias Ameaças e podem visualizar inúmeras Oportunidades para o seu crescimento, ambas no ambiente externo.

A análise do ambiente interno e externo, levantando-se os pontos fortes e pontos fracos a as ameaças e oportunidades, é a base para a Matriz SWOT, o termo vem do inglês e representa as iniciais das palavras Strenghts (forças), Weaknesses (fraquezas), Opportunities (oportunidades) e Threats (ameaças). A proposta é avaliar os pontos fortes, os pontos fracos, as oportunidades e as ameaças da organização e do mercado onde ela está atuando.

A análise SWOT deve ser realizada de maneira formal uma vez por ano, mas as informações mais importantes devem ser monitoradas constantemente. Depois de ter realizado uma análise SWOT, a organização pode:

• Estabelecer metas de melhoria dos itens que tenham sido considerados prioritários e de baixo desempenho.

• Estabelecer metas relacionadas à forma de atuação no que diz respeito ao aproveitamento de oportunidades.

• Estabelecer quais as ações que serão importantes para evitar os efeitos de eventuais ameaças. Essas metas serão a base do planejamento anual de atividades da organização. A análise SWOT é, portanto, um instrumento de fácil aplicação e pode ser de grande utilidade no planejamento das organizações sociais, assim como vem sendo no planejamento de muitas organizações privadas. ALINHAMENTO ENTRE ESTRATÉGIAS DE TECNOLOGIA DA INFORMAÇÃO E DE NEGÓCIO A aplicação da tecnologia da informação e de seus recursos geram uma grande expectativa quanto ao seu uso operacional e estratégico como alternativa para auxiliar os negócios e as atividades organizacionais, sem causar grandes impactos orçamentários. Nesse cenário, o alinhamento e a integração das estratégias com as tecnologias emergentes disponíveis passam a ter um papel de destaque na organização (REZENDE, 2008).

•  características da organização que podem in6luenciar positivamente o seu desempenho Strengths

•  características da organização que podem in6luenciar negativamente o seu desempenho Weaknesses

•  variáveis externas que podem criar condições favoráveis para a organização Opportunities

•  variáveis externas que podem criar condições desfavoráveis para a organização Threats



Aulas: 01 -‐ 13

O êxito da tecnologia da informação está relacionado ao uso efetivo da tecnologia da informação no alinhamento com o planejamento estratégico de negócios (REZENDE, 2008). O alinhamento estratégico entre TI e negócios se baseia na aplicação da tecnologia de informação de modo apropriado e harmônico com as estratégias e objetivos de negócios da organização (LUFTMAN, 2000). O conceito de alinhamento estratégico entre negócios e TI surge a partir das pesquisas sobre estratégia de negócios que reconhecem a necessidade de se alinhar os recursos organizacionais às ameaças e as oportunidades do ambiente (BRODBECK et al., 2007). Segundo IBM System Journal “o alinhamento estratégico é a adequação estratégica e integração funcional entre ambientes externos (mercado, política, fornecedores, etc.) e internos (estrutura administrativa e recurso financeiros, tecnológicos e humanos) para desenvolver as competências e maximizar a performance organizacionais”. Pode se dizer também que o alinhamento entre negócio e TI é alcançado quando um conjunto de estratégias de TI (sistemas, objetivos, obrigações e estratégias) são derivadas do conjunto estratégico organizacional (missão, objetivo e estratégias). Portanto quanto mais os sistemas provêm informações para os negócios, maior é a integração e maior a contribuição para a performance organizacional. MODELOS APLICADOS AO ALINHAMENTO ESTRATÉGICO É preciso lembrar também que o alinhamento estratégico não é um evento isolado, é um processo continuo de adaptação e mudança. Na literatura existem alguns modelos de alinhamento estratégico, entre eles encontramos o BSC BALANCED SCORECARD (BSC): KAPLAN E NORTON (92, 93, 96, 2000) A base para definição deste modelo é a revisão da estratégia da empresa que deve considerar os fatores críticos de sucesso para atuação no ramo de negócios onde a empresa está inserida. O desdobramento deste modelo será em um scorecard multidimensional da estratégia já formulada, integrando as medidas de desempenho financeiro, perspectivas dos clientes, processos de negócio, aprendizado e crescimento.

Neste modelo de alinhamento estratégico possui dois eixos principais o da comunicação e do controle da estratégia. O objetivo é disseminar o conhecimento da estratégia por todos os níveis da organização através de um mapa estratégico. O controle da estratégia ocorre pela definição das medidas de desempenho equilibradas, indicadores de tendência e de resultados, financeiras e não financeiras que permitem acompanhar o desempenho dos negócios no curto e no longo prazo.

1549_mpog_enap_conhe_espec_ii_cargo_12_anali_em_ti_mpoge_intensivao_1-13-apostila

Documents