3 ESTUDO DE CASO
3.2 Relatório do Estudo de Caso
3.2.4 Modelagem dos Dados
O levantamento dos requisitos é essencial para a modelagem dos dados, especialmente na primeira etapa, o projeto conceitual. Inicialmente, serão levantados as entidades, os atributos e os relacionamentos. As necessidades dos usuários serão, então, transformadas em um modelo ER. O projeto lógico tem o objetivo de obter um sistema mais íntegro e mais consistente, possuindo um nível de abstração menor. Assim, este estudo de caso transformará o modelo conceitual de diagrama ER em um modelo relacional.
3.2.4.1 Projeto Conceitual
Essa etapa serão levantados as entidade, os atributos, os relacionamentos e as generalizações, tendo como resultado o diagrama ER.
3.2.4.1.1 Entidades
Após o entendimento de todo o fluxo de dados, pode-se levantar as entidades que são importantes para o negócio. Essas entidades representam os objetos que se deseja manter informações. As escolhidas para representar o estudo de caso em questão podem ser observadas no Quadro 3.
Quadro 3 – Entidades levantadas
ENTIDADES DESCRIÇÃO
CAIXA Armazena as caixas que serão trabalhadas. PALLET Armazena os pallets que compõem cada projeto. PROJETO Armazena os projetos e suas características. SISTEMA Armazena os tipos de sistema da empresa. FUNCIONÁRIO Armazena os dados referentes aos funcionários. STATUS Armazena os status da caixa.
ETAPA Armazena as etapas de cada sistema. SCANNER Armazena os scanners que a empresa possui
PREPARAÇÃO Armazena os dados de produção da etapa Preparação.
RETRABALHO Armazena os dados de produção do retrabalho da etapa Preparação. DIGITALIZAÇÃO Armazena os dados de produção da etapa Digitalização.
INDEXAÇÃO Armazena os dados de produção da etapa Indexação CONFERÊNCIA Armazena os dados de produção da etapa Conferência TRATAR Armazena os dados de produção da etapa Tratar
3.2.4.1.2 Atributos
Os atributos devem ser relevantes aos usuários. Para cada entidade descrita, foram descritos os fatos úteis. O modelo de diagrama utilizado será o de Heuser (2009), como foi definido no Capítulo 2. A Figura 33 representa as entidades com seus respectivos atributos.
Figura 33 – Atributos das entidades
Fonte: elaborado pela autora, 2012.
3.2.4.1.3 Relacionamentos
Após a identificação das entidades e atributos, a próxima etapa trata-se de descrever as associações entre as entidades. A Figura 34 mostra o projeto conceitual na forma de diagrama ER, entretanto, nota-se que existe a necessidade de refinar esse modelo, já que existem relacionamentos n:n e generalizações. Essa etapa será discutida no próximo item.
ETAPAS etapa código PROJETO data inicial código data final quantidade de caixas CONTÉM meta und responsável PERTENCE PALLET pallet código PERTENCE CAIXA caixa código STATUS status código POSSUI ALOCA PRODUZ TRABALHA FUNCIONÁRIO funcionário código matrícula (1, 1) (1, n) (1, n) (1,1) (1, n) (1,1) (1, 1) (0,n) (1,1) (0, n) (1, 1) USA (1, n) (1, n) PRODUÇÃO tipo de produção (1, n) RETRABALHO código data hora inicial hora final quantidade CONFERÊNCIA código data hora inicial hora final quantidade INDEXAÇÃO código data hora inicial hora final quantidade PREPARAÇÃO código data hora inicial hora final quantidade DIGITALIZAÇÃO código data hora inicial hora final quantidade SCANNER scanner código SISTEMA (0, n) (0, n) (0, n) (0, n) (0, n) (0, n) (0, n) (1, 1) TRATAR código data hora inicial hora final quantidade
3.2.4.2 Projeto Lógico
Na fase do projeto lógico, o esquema conceitual definido, no caso o modelo entidade-relacionamento, será transformado em um esquema de relação. Dessa forma, o resultado desta etapa é uma coleção de tabelas, cada uma com um nome único atribuído. O trabalho será realizado através do método de transformação entre os modelos, que respeitará as restrições de integridade, obtendo um sistema mais consistente e íntegro.
3.2.4.2.1 Implementação inicial de entidades
Neste primeiro passo, as entidades são transformadas em tabelas e os atributos tornam-se os campos da tabela criada. Os atributos indicadores são traduzidos para as chaves primárias. Nos casos analisados, os nomes dos atributos foram alterados, tornando-os menores e sem espaços.
Para facilitar o objetivo do trabalho, nesta etapa, será demonstrada a implementação dos relacionamentos, nos casos de adição de coluna. Caso que ocorre em algumas tabelas, que convém adicionar uma coluna em uma delas, tornando uma chave primária de uma tabela em uma chave estrangeira de outra. As transformações podem ser vistas nas Figuras 35 a 42.
Entidade Pallet
Figura 35 – Transformação da entidade pallet
Entidade Caixa
Figura 36 – Transformação da entidade caixa
Fonte: elaborado pela autora, 2012.
Nesta entidade, existia a opção de utilizar a numeração da caixa como chave primária, entretanto optou-se utilizar uma numeração automática, afinal a numeração da caixa que a empresa utiliza é um pouco complicada, existindo pontos entre o número, além de ser muito extenso.
Entidade Etapa
Figura 37 – Transformação da entidade etapa
Entidade Projeto
Figura 38 – Transformação da entidade projeto
SISTEMA fluxo código ALOCA (1, 1) (1, n) PROJETO data inicial código data final quantidade de caixas Modelo Relacional
tbl_projeto (cod_projeto, projeto, qtd_caixa, data_i, data_f, cod_sistema)
cod_sistema referencia tbl_sistema
Fonte: elaborado pela autora, 2012
Entidade Funcionário
Figura 39 – Transformação da entidade funcionário
FUNCIONÁRIO
funcionário código
matrícula
Modelo Relacional tbl_func (matricula, func)
Fonte: elaborado pela autora, 2012.
Nesta entidade, optou-se utilizar a matrícula do funcionário como chave primária, já que cada funcionário possui um código de identificação (matrícula) único na empresa.
Entidade Status
Figura 40 – Entidade Status
Fonte: elaborado pela autora, 2012.
Entidade Sistema
Figura 41 – Entidade Sistema
Fonte: elaborado pela autora, 2012.
Entidade Scanner
Figura 42 – Entidade Scanner
3.2.4.2.2 Implementação de relacionamentos
Para os relacionamentos n:n, indica-se a criação de uma tabela própria, que contém as seguintes colunas:
− Colunas correspondentes aos identificadores das entidades relacionadas;
− Colunas correspondentes aos atributos do relacionamento. Conforme apresentado no caso etapa- projeto na Figura 43.
Relacionamento: Etapa – Projeto
Figura 43 – Relacionamento Etapa-Projeto
Fonte: elaborado pela autora, 2012.
Neste caso, foi necessária a criação da tabela meta, para eliminar o relacionamento n:n. Entretanto, essa tabela precisa de um campo chamado responsável, onde existirá um novo relacionamento (1:n), desta tabela meta com a tabela funcionários.
3.2.4.2.2 Implementação de generalização/especialização
Como pôde ser visto no modelo conceitual, existe uma generalização entre a entidade produção e os tipos de produção: digitalização, preparação, retrabalho, indexação, conferência e tratar, conforme apresentado na Figura 44. Para a implementação de hierarquia de generalização, uma das alternativas é o uso de uma única tabela para representar todas as hierarquias.
A tabela nova vai ser composta por:
a) Chave primária, como as informações das tabelas são semelhantes, pode ser qualquer um deles, será chamado, então, de cod_prod; b) Como foi levantado o atributo tipo de produção, ele identificará que
tipo de entidade especializada está sendo representada por cada linha, será chamando de cod_etapa;
c) Uma coluna para cada atributo das entidades genéricas: data, hora_i, hora_f e qtd;
d) Coluna com o número do scanner, que será definida como opcional, já que somente terá valor, quando a linha for referente à entidade
Figura 44 – Generalização/Especialização da Produção
Após as atividades de implementação, que transformaram o modelo ER em um modelo conceitual, pode-se esquematizar o modelo relacional no formato de diagrama. Os Quadros 4 a 12 mostram as estruturas das tabelas que sofreram modificações em função dos novos requisitos.
Quadro 4 – Estrutura da tabela Pallet
PALLET
Chave Atributo Tipo Obrigatório Restrições
<pk> cod_pallet Inteiro Sim Integridade referencial com a tabela Caixa
pallet Inteiro Sim -
<fk> cod_projeto Inteiro Sim Integridade referencial com a tabela Projeto
Fonte: elaborado pela autora, 2012.
Quadro 5 – Estrutura da tabela Caixa
CAIXAS
Chave Atributo Tipo Obrigatório Restrições
<pk> cod_caixa Inteiro Sim Integridade referencial com a tabela Pallete Produção
caixa Texto Sim -
<fk> cod_pallet Inteiro Sim Integridade referencial com a tabela Pallet <fk> cod_status Inteiro Sim Integridade referencial com a tabela Status
Fonte: elaborado pela autora, 2012.
Quadro 6 – Estrutura da tabela Etapa
ETAPA
Chave Atributo Tipo Obrigatório Restrições
<pk> cod_etapa Inteiro Sim Integridade referencial com a tabela Metae Produção
etapa Texto Sim -
<fk> cod_sistema Inteiro Sim Integridade referencial com a tabela Sistema
Fonte: elaborado pela autora, 2012.
Quadro 7 – Estrutura da tabela Projeto
PROJETOS
Chave Atributo Tipo Obrigatório Restrições
<pk> cod_projeto Inteiro Sim Integridade referencial com a tabela Metae Pallet
projeto Texto Sim -
<fk> cod_sistema Inteiro Sim Integridade com a tabela sistema
data_i Data/Hora Sim -
data_f Data/Hora Sim -
Qtd_caxia Inteiro Sim -
Quadro 8 – Estrutura da tabela Funcionário
FUNCIONÁRIO
Chave Atributo Tipo Obrigatório Restrições
<pk> matricula Inteiro Sim Integridade referencial com a tabela Produção
func Texto Sim -
Fonte: elaborado pela autora, 2012.
Quadro 9 – Estrutura da tabela Status
STATUS
Chave Atributo Tipo Obrigatório Restrições
<pk> cod_status Inteiro Sim Integridade referencial com a tabela Caixa e
Pallet
status Texto Sim -
Fonte: elaborado pela autora, 2012.
Quadro 10 – Estrutura da tabela Scanner
SCANNER
Chave Atributo Tipo Obrigatório Restrições
<pk> cod_scan Inteiro Sim Integridade referencial com a tabela Produção
scanner Texto Sim -
Fonte: elaborado pela autora, 2012.
Quadro 11 – Estrutura da tabela Meta
META
Chave Atributo Tipo Obrigatório Restrições
<pk> cod_projeto Inteiro Sim Integridade referencial com a tabela Projeto <pk> cod_etapa Inteiro Sim Integridade referencial com a tabela Etapa
meta Inteiro Sim -
und Texto Sim -
<fk> responsavel Inteiro Sim Integridade referencial com a tabela Funcionário
Fonte: elaborado pela autora, 2012.
Quadro 12 – Estrutura da tabela Produção PRODUÇÃO
Chave Atributo Tipo Obrigatório Restrições
<pk> cod_prod Inteiro Sim Integridade referencial coma tabela Caixa, Funcionário, Etapa e Scanner <fk> cod_etapa Inteiro Sim Integridade referencial coma tabela Etapa <fk> cod_func Inteiro Sim Integridade referencial coma tabela Funcionário <fk> cod_caixa Inteiro Sim Integridade referencial coma tabela Caixa <fk> cod_scan Inteiro Não Integridade referencial coma tabela Scanner
data Data/Hora Sim -
hora_i Data/Hora Sim -
hora_f Data/Hora Sim -
qtd Inteiro Sim -
3.2.4.1 Consulta para gerar indicadores
Após a elaboração do modelo, com tabelas, campos e domínios definidos, pôde-se estruturar consultas em SQL para obter os indicadores de produtividade, eficiência e utilização. Com esse objetivo, para exemplificar, as tabelas foram preenchidas com dados fictícios, respeitando as restrições de integridade, que foram vistas nas tabelas do item anterior. Assim, os Quadros 13 a 22 representam essas tabelas.
Quadro 13 – Tabela Projeto preenchida
cod_projeto Projeto cod_sistema data_i data_f qtd_caixas
1 PROJETO X 2 10/04/2012 15/05/2012 700 2 PROJETO Y 3 02/05/2012 05/06/2012 1400 3 PROJETO Z 3 04/05/2012 08/06/2012 2800
Fonte: elaborado pela autora, 2012. Quadro 14 – Tabela sistema preenchida
cod_sistema Fluxo
1 sistema 1 2 sistema 2
Fonte: elaborado pela autora, 2012. Quadro 15 – Tabela etapa preenchida cod_etapa Etapa cod_sistema
1 Cadastro 2 2 Preparação 2 3 Digitalização 2 4 Retrabalho 5 Indexação 2 6 Conferência 2 8 Tratar 2 9 Remontagem 2
Fonte: elaborado pela autora, 2012. Quadro 16 – Tabela Scanner preenchida
cod_scan Scanner 1 Fujitsu 1 2 Fujitsu 2 3 Fujitsu 3 4 Fujitsu 4 5 Fujitsu 5 6 Fujitsu 6 7 Fujitsu 7
Quadro 17 – Tabela pallet preenchida cod_pallet cod_projeto pallet
1 2 12345 2 2 12346 3 2 12347 4 2 12348 5 2 12349 6 2 12350 7 3 12351 8 3 12352 9 3 12353 10 3 12354 11 3 12355 12 1 12356
Fonte: elaborado pela autora, 2012.
Quadro 18 – Tabela status preenchida cod_status status 1 Cadastro 2 Esperando Preparação 3 Preparada 4 Esperando Digitalização 5 Digitalizado 6 Esperando Indexação 7 Indexada 8 Esperando Conferência 9 Conferida 10 Esperando Tratamento 11 Tratado
Fonte: elaborado pela autora, 2012.
Quadro 19 – Tabela meta preenchida
cod_projeto cod_etapa meta_imagem responsavel und_meta
1 3 1200 2 IMAGENS
2 3 1500 3 IMAGENS
3 3 2150 4 IMAGENS
Fonte: elaborado pela autora, 2012.
Quadro 20 – Tabela funcionário preenchida matricula Func
14435 Maria
14562 José
14882 João
14895 Ana
Quadro 21 – Tabela caixa preenchida
cod_caixa cod_pallet caixa cod_status
19 12 44.44.44.44.44.444 4 20 12 33.33.33.33.33.333 4 21 12 55.55.55.55.55.555 4 22 12 11.11.11.11.11.112 4 23 12 11.11.11.11.11.113 4 24 12 11.11.11.11.11.114 4 25 12 11.11.11.11.11.115 4 26 12 11.11.11.11.11.116 4 27 12 11.11.11.11.11.117 4 28 12 11.11.11.11.11.118 4 29 12 11.11.11.11.11.119 4 30 12 11.11.11.11.11.110 4 31 12 22.22.22.22.22.221 4 32 12 22.22.22.22.22.222 4 33 12 22.22.22.22.22.223 4 34 12 22.22.22.22.22.224 4 35 12 22.22.22.22.22.225 4 36 12 22.22.22.22.22.226 4 37 12 22.22.22.22.22.228 4 38 12 22.22.22.22.22.229 4
Fonte: elaborado pela autora, 2012. Quadro 22 – Tabela produção preenchida
cod_prod cod_etapa cod_caixa data cod_func cod_scan hora_i hora_f qtd
1 3 19 10/04/2012 14435 2 8:03 9:25 1508 2 3 20 10/04/2012 14435 2 9:26 10:47 1508 3 3 21 10/04/2012 14435 2 10:48 12:01 1405 4 3 22 10/04/2012 14435 2 13:05 14:32 1437 5 3 23 10/04/2012 14435 2 14:35 15:48 1404 6 3 24 10/04/2012 14562 3 8:04 9:58 1309 7 3 25 10/04/2012 14562 3 9:29 10:35 1558 8 3 26 10/04/2012 14562 3 10:36 11:47 1335 9 3 27 10/04/2012 14562 3 11:48 12:04 1440 10 3 28 10/04/2012 14562 3 13:10 14:38 1598 11 3 29 10/04/2012 14882 4 8:07 9:49 1400 12 3 30 10/04/2012 14882 4 9:51 10:28 1500 13 3 31 10/04/2012 14882 4 10:59 12:00 1376 14 3 32 10/04/2012 14882 4 13:01 14:28 1594 15 3 33 10/04/2012 14882 4 14:29 15:48 1400 16 3 34 10/04/2012 14882 5 8:02 9:37 1598 17 3 35 10/04/2012 14895 5 9:38 10:44 1402 18 3 36 10/04/2012 14895 5 10:45 12:07 1600 19 3 37 10/04/2012 14895 5 13:10 14:39 1455 20 3 38 10/04/2012 14895 5 14:49 15:18 1660
O SGBD que ilustra o exemplo foi elaborado em Access, utilizando a linguagem SQL para realizar as consultas. A partir da tabela Produção, utilizando junções, que são usadas quando é necessário buscar em disco dados de diversas linhas associadas pela igualdade de campos (por exemplo, buscar o nome de um funcionário através da matrícula na tabela produção) pôde-se ilustrar três consultas.
Como os indicadores são gerados diariamente, optou-se em utilizar como condição da consulta que o usuário definisse a data, o projeto e a etapa que deseja realizar a consulta. Assim, a SQL ficou da seguinte forma:
Consulta 1 (cns_prod1)
SELECT tbl_func.funcionario, tbl_digitalizacao.hora_inicial, tbl_digitalizacao.hora_final, tbl_digitalizacao.quantidade, tbl_scanner.scanner, tbl_digitalizacao.cod_etapa, tbl_pallets.cod_projeto, tbl_etapas.etapa
FROM tbl_etapas INNER JOIN (tbl_scanner INNER JOIN (tbl_func INNER JOIN ((tbl_projetos INNER JOIN (tbl_pallets INNER JOIN tbl_caixas ON tbl_pallets.cod_pallet = tbl_caixas.cod_pallet) ON tbl_projetos.cod_projeto = tbl_pallets.cod_projeto) INNER JOIN tbl_digitalizacao ON tbl_caixas.cod_caixa = tbl_digitalizacao.cod_caixa) ON tbl_func.matricula = tbl_digitalizacao.cod_func) ON tbl_scanner.cod_scan = tbl_digitalizacao.cod_scanner) ON tbl_etapas.cod_etapa = tbl_digitalizacao.cod_etapa
WHERE (((tbl_projetos.projeto)=[Informe o projeto:]) AND ((tbl_etapas.etapa)=[Informe a etapa:]) AND ((Day([data]))=[Informe o dia:]) AND ((Month([data]))=[Informe o mês:]) AND ((Year([data]))=[Informe o ano:]))
ORDER BY tbl_func.funcionario;
Para ilustrar o exemplo, foram utilizados os critérios abaixo, obtendo como resultado o Quadro 23. Nessa tabela, pode-se analisar a produção de cada operador no dia, além do scanner utilizado por cada um.
a) Projeto = Projeto X b) Digitalização c) Dia = 10 d) Mês = 4 e) Ano = 2012
Quadro 23 – Resultado da Consulta 1
Funcionário Hora Inicial Hora Final Quantidade Scanner
Ana 13:10 14:39 1455 Fujitsu 4 Ana 10:45 12:07 1600 Fujitsu 4 Ana 9:38 10:44 1402 Fujitsu 4 Ana 14:49 15:18 1660 Fujitsu 4 João 8:07 9:49 1400 Fujitsu 3 João 8:02 9:37 1598 Fujitsu 4 João 14:29 15:48 1400 Fujitsu 3 João 13:01 14:28 1594 Fujitsu 3 João 10:59 12:00 1376 Fujitsu 3 João 9:51 10:28 1500 Fujitsu 3 José 8:04 9:58 1309 Fujitsu 2 José 9:29 10:35 1558 Fujitsu 2 José 10:36 11:47 1335 Fujitsu 2 José 13:10 14:38 1598 Fujitsu 2 José 11:48 12:04 1440 Fujitsu 2 Maria 8:03 9:25 1508 Fujitsu 1 Maria 14:35 15:48 1404 Fujitsu 1 Maria 13:05 14:32 1437 Fujitsu 1 Maria 10:48 12:01 1405 Fujitsu 1 Maria 9:26 10:47 1508 Fujitsu 1
Fonte: elaborado pela autora, 2012.
A consulta 2 tem como objetivo retornar os valores da quantidade total e horas trabalhadas, agrupadas pelos operadores. Esta consulta será baseada na Consulta 1, a soma da quantidade de cada operador será chamada de Quantidade Produzida e a soma de horas, Horas Trabalhadas, estruturada conforme descrição abaixo. A função CDbl é utilizada para transformar o formato hora em formato decimal, esta é utilizada após subtrair a hora final da hora inicial. A SQL ficou da seguinte forma:
Consulta 2 (cns_prod2)
SELECT cns_prod1.funcionario, Sum(cns_prod1.quantidade) AS [Quantidade Produzida], Sum(Round(((CDbl([hora_final])*24)-(CDbl([hora_inicial])*24)),2)) AS [Horas Trabalhadas], cns_prod1.cod_projeto, cns_prod1.cod_etapa
FROM cns_prod1
O resultado pode ser verificado no Quadro 24. Quadro 24 – Resultado da Consulta 2 Funcionário Quantidade Produzida Trabalhadas Horas
Ana 6117 4,43
João 8868 7,69
José 7240 5,92
Maria 7262 6,61
Fonte: elaborado pela autora
Finalmente, a terceira consulta fornece os dados de produtividade, de eficiência e de utilização, o primeiro é calculado pela divisão da quantidade produzida pelas horas trabalhadas, o segundo, compara-se o valor da produtividade pelo que é desejável (meta) para atividade. O valor da meta é retornado de acordo com o projeto e com a etapa escolhidos. O indicador utilização é calculado pela divisão das horas trabalhadas pelas horas que a empresa deseja que o operador produza, que é 8,1 horas. A SQL é apresentada a seguir:
Consulta 3 (cns_prod3)
SELECT cns_prod2.funcionario, cns_prod2.[Quantidade Produzida], cns_prod2.[Horas Trabalhadas], tbl_meta.meta_imagem AS [Meta Hora], Round([Quantidade produzida]/[Horas Trabalhadas],0) AS Produtividade, [Produtividade]/[Meta Hora] AS Eficiência, [Horas Trabalhadas]/8.1 AS Utilização
FROM tbl_meta INNER JOIN cns_prod2 ON (tbl_meta.cod_etapa = cns_prod2.cod_etapa) AND (tbl_meta.cod_projeto = cns_prod2.cod_projeto);
Esta consulta retorna os indicadores de produtividade, eficiência e utilização, o resultado está no Quadro 24.
Quadro 25 – Resultado da Consulta 3
Funcionário Quantidade Produzida Trabalhadas Horas Meta Hora Produtividade Eficiência Utilização
Ana 6117 4,43 1200 1381 115% 55%
João 8868 7,69 1200 1153 96% 95%
José 7240 5,92 1200 1223 102% 73%
Maria 7262 6,61 1200 1099 92% 82%