Normalização Base de Dados Diagrama de Classes (UML)

Com o objetivo de normalizar a base de dados a desenvolver para a implementação da solução proposta, foi realizado um diagrama de classes com recurso à linguagem UML. Com este diagrama pretendem-se estabelecer as relações entre as classes a identificar e definir os atributos de cada uma das mesmas A nomenclatura a ser utilizada neste capítulo foi previamente explorada nos subcapítulos 2.4 e 2.5.

A primeira classe a definir foi a classe “Material”. Nesta será armazenada a designação do material a utilizar no processo de moldação por injeção, permitindo assim registar o material usado em cada operação graças ao atributo “id_material”. Foi ainda incluído um atributo denominado “Data_registo” de forma a registar a data e hora da inserção do material na base de dados.

De seguida foi definida a classe “Parametros_material”. Pretende-se armazenar na mesma os valores respetivamente à temperatura do molde, temperatura de fusão e temperatura máxima de fusão antes de ocorrer a deterioração do material, recomendadas pelo fabricante. Para estes registos serão utilizados os atributos “T_molde_mat”, “T_fusão_mat” e “T_max_fusao”, respetivamente. Estes valores, que descrevem o material em utilização, poderão ser usados como referência para analisar as leituras de temperatura registadas, numa outra classe, durante o processo produtivo.

A classe “Molde” foi definida para permitir a identificação do molde em utilização no processo, declarado como iniciado, sendo esta informação registada no atributo “id_molde”. Foi também criado um atributo chamado “Tempo_inicio” que servirá para registar a data e hora em que a produção com o molde é inicializada. Com recurso a um último atributo, denominado ‘id_registo’, será possível ter em conta a ordem dos registos efetuados alusivos a esta classe.

De maneira a registar as leituras dos sensores, instalados no molde inserido na máquina de injeção, foi criada a classe “Parametros_molde”. Esta é responsável pelo registo da

48

temperatura do molde obtida através de um sensor de temperatura instalado no mesmo, utilizando, para tal, o atributo “T_molde”. Foi ainda criado o atributo “Tempo_registo” que será utilizado para registar a data e hora em que ocorrem as coletas de dados provenientes dos sensores.

De forma a identificar a máquina a ser utilizada, apesar de apenas ser considerada uma na solução em apresentação, foi criada a classe “Maquina”. Esta irá permitir, num ambiente produtivo onde mais que uma máquina de injeção instrumentada se encontre em produção, a identificação da máquina cujos registos serão efetuados permitindo a distinção da fonte que originou os dados coletados. Para tal, é utilizado o atributo “id_maquina”.

Foram criadas mais 4 classes de forma a armazenar as leituras sensoriais registadas a partir dos sensores presentes na máquina de injeção, sendo estas denominadas:

• “Parametros_ambiente”, que permitirá o registo da temperatura, humidade e pressão do ambiente de produção;

• “Parametros_maquina”, que representa as leituras de temperatura do cilindro de plasticização em três zonas distintas;

• “Cinematica_extracao”, a representar o registo de aceleração associado à cinemática da placa de extração;

• “Cinematica_placa_movel”, que regista a aceleração associada à cinemática da placa móvel do molde durante a abertura e fecho do mesmo;

• “Vibracoes_extracao” que representa o registo de vibrações associado à cinemática da placa de extração;

• “Vibracoes_placa_movel”, responsável pelo registo de vibrações associadas à cinemática da placa móvel do molde.

A classe “Parametros_ambiente” possui os seguintes atributos:

• “T_amb”, usado no registo da temperatura ambiente onde ocorre o processo produtivo;

• “H_amb”, usado no registo da humidade relativa ambiente do local onde decorre o processo produtivo;

• “P_amb”, usado no registo da pressão barométrica ambiente do local onde decorre o processo produtivo;

• “Tempo_registo”, responsável por indicar a data e hora de registo dos parâmetros acima mencionados.

A classe “Parametros_maquina” possui os seguintes atributos:

• “T_zona1”, responsável por registar leituras de um sensor de temperatura localizado na zona de transição do cilindro de plasticização;

• “T_zona2”, responsável por registar leituras de um sensor de temperatura localizado na zona de medição do cilindro de plasticização;

• “T_zona3”, responsável por registar leituras de um sensor de temperatura localizado na zona do bico de injeção;

• “Tempo_registo”, responsável por indicar a data e hora de registo dos parâmetros acima mencionados.

49

A classe “Cinematica_extracao” possui os seguintes atributos:

• “acel_extracao”, utilizada no registo de aceleração do sensor de medição montado no mecanismo de extração da máquina segundo o eixo coincidente com a direção do seu movimento;

• “Tempo_registo”, utilizado para indicar a data e hora de registo dos parâmetros acima mencionados.

A classe “Cinematica_placa_movel” possui os seguintes atributos:

• “acel_placa_movel”, utilizada no registo de aceleração do sensor de medição montado no mecanismo de abertura da placa móvel da máquina segundo o eixo coincidente com a direção do seu movimento;

• “Tempo_registo”, responsável por indicar a data e hora de registo dos parâmetros acima mencionados.

A classe “Vibracoes_extracao possui os seguintes atributos:

• “vibr_x_extracao”, responsável pelo registo de rotações segundo o eixo Oxx assumido pelo sensor de medição montado no mecanismo responsável pela cinemática da placa de extração;

• “vibr_y_extracao”, responsável pelo registo de rotações segundo o eixo Oyy assumido pelo sensor de medição;

• “vibr_y_extracao”, responsável pelo registo de rotações segundo o eixo Ozz assumido pelo sensor de medição;

• “Tempo_registo”, responsável por indicar a data e hora de registo dos parâmetros acima mencionados.

A classe “Virbracoes_placa_movel” possui os seguintes atributos:

• “vibr_x_placa_movel”, responsável pelo registo de rotações segundo o eixo Oxx assumido pelo sensor de medição montado no mecanismo responsável pela cinemática de abertura e fecho do molde;

• “vibr_y_placa_movel”, responsável pelo registo de rotações segundo o eixo Oyy assumido pelo sensor de medição;

• “vibr_y_placa_movel”, responsável pelo registo de rotações segundo o eixo Ozz assumido pelo sensor de medição;

• “Tempo_registo”, responsável por indicar a data e hora de registo dos parâmetros acima mencionados.

Para efetuar o registo de cada produto produzido, atribuindo a cada um destes um código de identificação único coincidente com a etiqueta RFID do qual este se fará acompanhar após a sua produção, foi criada a classe “Produto_RFID”. Serão utilizados os atributos “id_tag” e “Tempo_registo” para registar o código único de identificação da tag RFID, e consequentemente do produto, e para o registo da data e hora em que a associação entre a etiqueta e o produto produzido é efetivada, respetivamente. Será usado, ainda, o “id_registo” para facilitar a identificação das etiquetas por meio de uma numeração continua e crescente.

Por fim, foi criada a classe “Leitura_RFID” que servirá para registar a data e hora de início da produção de uma peça, com o atributo “Tempo_inicio_peca”, coincidente com o inicio dos

50

registos de uma máquina no inicio da produção, ou término da peça anterior, e a data e hora da saída da peça da máquina, ou seja, fim de produção, com o atributo “Tempo_inicio_peca”.

Uma vez definidas as classes, definem-se agora as relações que as mesmas compartilham entre si, desta forma permitindo a compreensão da estrutura e normalização da base de dados a desenvolver.

A primeira relação a abordar será entre as classes “Parametros_material” e “Material”. Estas partilham uma relação de composição, significando isto uma relação de obrigatoriedade entre as mesmas. Com a representação apresentada na Figura 27, informa-se que a classe “Material” pode existir mesmo sem a classe “Parametros_material”, no entanto, o inverso não seria possível. Isto significaria que poderia ser utilizado no processo um material cuja caracterização relativamente às temperaturas de operação não estivesse disponível ou não fossem conhecidas, por exemplo, um novo material ou diferentes aditivos em estudo.

Figura 27 - Relação entre as classes "Parametros_material" e "Material" (UML).

A relação seguinte dá-se entre as classes “Parametros_Molde” e “Molde”. Estas partilham, tal como na previamente apresentada, uma relação de composição. A Figura 28 pretende representar que a classe “Molde” pode existir sem a classe “Parametros_molde”, no entanto, o inverso não seria possível. Esta relação representa, na realidade, a possibilidade de utilizar um molde cuja identificação é conhecida, no entanto, não estando este instrumentado com os sensores esperados pelo sistema, não serão efetuados nenhuns registos de temperatura do molde.

Figura 28 - Relação entre as classes "Parametros_molde" e "Molde" (UML).

As seguintes relações serão representadas como uma relação de generalização. Esta relação implica a existência de uma classe mãe e as suas classes filhas, sendo que estas últimas irão herdar alguns dos atributos da primeira mencionada. Em outras palavras, as classes filhas apresentam-se como mais específicas, em detrimento da classe mãe que se apresenta como mais genérica. Nesta situação relacional a classe “Maquina” é a classe mãe, e as suas classes filhas são “Parametros_ambiente”, “Parametros_maquina”, “Cinematica_extracao”, “Vibracoes_extracao” e “Vibracoes_placa_movel”. A Figura 29 pretende representar esta relação entre as classes referidas.

51

Figura 29 - Relação entre as classes "Maquina", "Parametros_ambiente", "Parametros_maquina", "Cinematica_extracao", "Cinematica_placa_movel", “Vibracoes_extracao” e “Vibracoes_placa_movel” (UML).

A próxima relação dá-se entre as classes “Material” e “Molde”, estabelecendo-se entre estas uma relação associativa. A Figura 30 pretende representar essa mesma relação. Em termos práticos, esta relação significa que poderão ser utilizados para um só molde, e consecutivamente no processo produtivo, mais do que um determinado tipo de material. Atendendo, no entanto, às regras de cumprimento relativamente à purga do cilindro de plasticização antes de ocorrer a injeção de um novo material, abordado no subcapítulo 2.1.3.8.

Figura 30 - Relação entre as classes "Material" e "Molde" (UML).

A relação seguinte ocorre entre as classes “Molde” e “Maquina” e, do mesmo modo que a anterior, estabelece-se uma relação associativa entre elas. Na Figura 31 é representada a relação em conta. O significado prático do relacionamento entre esta classes implica que poderão ser instalados, numa só máquina, diferentes tipos de moldes ao longo de um dia de produção, estando o sistema preparado para registar essas alterações efetuadas.

52

A relação que se estabelece entre as classes “Maquina” e “Produto_RFID” é, também esta, associativa, tal como se representa na Figura 32. Esta relação pretende representar que uma só máquina dá origem a vários produtos, cada um destes com uma identificação diferente.

Figura 32 - Relação entre as classes "Maquina" e "Produto_RFID" (UML)

Por fim, estabelece-se uma relação entre as classes “Produto_RFID” e “Leitura_RFID”, estabelecendo-se uma relação associativa entre estas, Figura 33. A multiplicidade entre elas indica em termos práticos que apenas pode ser lida uma etiqueta de cada vez, ainda que existam diversas destas associadas aos diferentes produtos produzidos.

Figura 33 - Relação entre as classes "Leitura_RFID" e "Produto_RFID" (UML).

Uma vez estabelecidas as classes necessárias, os atributos de cada uma destas, bem como as relações entre as mesmas, torna-se possível apresentar o diagrama de classes da base de dados desenvolvida, na Figura 34.

53

De forma a projetar a base de dados a partir do processo de normalização decorrido, utilizando o diagrama de classes apresentado na Figura 34, deve-se, primeiramente, proceder à conversão das classes em tabelas, sendo que os atributos de cada uma das primeiras serão convertidos em colunas da última mencionada. Seguidamente serão definidas, de entre os atributos ou colunas de cada tabela, as chaves primárias. Uma vez descobertas, atendendo aos relacionamentos entre as classes, agora apresentadas como tabelas, efetuar-se-ão atribuições de chaves estrangeiras a algumas das tabelas [26].

Posto isto, identificam-se de entre as classes do diagrama usado na normalização da base de dados, doze tabelas a ser geradas, sendo estas, “Parametros_ambiente”, “Parametros_maquina”, “Cinematica_extracao”, “Cinematica_placa_movel”, “Material”, “Vibracoes_extracao”, “Vibracoes_placa_movel”, “Utilizador”, “Produto_RFID”, “Molde”, “Parametros_Molde”, “Parametros_material”. De seguida, identificam-se as chaves primarias de cada tabela e as atribuições das chaves estrangeiras de acordo com as relações entre as mesmas.

As tabelas “Parametros_ambiente”, “Parametros_maquina”, “Cinematica_extracao”, “Cinematica_placa_movel”, “Vibracoes_extracao” e “Vibracoes_placa_movel”, eram previamente representadas como classes-filhas da classe-mãe “Maquina”, pelo que, herdam o atributo “id_maquina” dessa classe como chave estrangeira. No entanto, na ausência da necessidade de criação de uma tabela para a classe-mãe em questão, este será considerado como chave primária em cada uma destas tabelas na base de dados. Dos restantes atributos de cada uma das tabelas criadas, em cada uma destas, o atributo “Tempo_registo” será assumida como chave primária, sendo os restantes atributos das classes em questão convertidas em colunas de cada tabela, respetivamente. Nas tabelas Tabela 4, Tabela 5, Tabela 6, Tabela 7, Tabela 8 e Tabela 9, estão apresentadas as tabelas a criar na base de dados, segundo a respetiva ordem de apresentação das mesmas no começo do presente parágrafo.

Tabela 4 – Tabela da base de dados "Parametros_ambiente".

#id_maquina #Tempo_registo T_amb H_amb P_amb

Tabela 5 – Tabela da base de dados “Parametros_maquina”.

#id_maquina #Tempo_registo T_zona1 T_zona2 T_zona3

Tabela 6 – Tabela da base de dados “Cinematica_extracao”.

#id_maquina #Tempo_registo acel_extracao

Tabela 7 – Tabela da base de dados “Cinematica_placa_movel”.

#id_maquina #Tempo_registo acel_placa_movel

Tabela 8 – Tabela da base de dados “Vibracoes_extracao”.

#id_maquina #Tempo_registo vibr_x_extracao vibr_y_extracao vibr_z_extracao

Tabela 9 – Tabela da base de dados “Vibracoes_placa_movel”.

54

A tabela “Produto_RFID”, originária da classe do diagrama, com a mesma designação, graças à sua relação de multiplicidade com a classe “Máquina”, irá herdar o seu atributo “id_maquina”, sendo esta uma chave estrangeira. No entanto, graças à ausência de uma tabela resultante da classe “Máquina”, esta será assumida como chave primária na base de dados a utilizar. Para além desta, identifica-se o atributo “id_tag” e “id_registo”, também como chaves primárias. Na Tabela 10, encontra-se a representação da tabela em questão, a criar na base de dados.

Tabela 10 – Tabela da base de dados “Produto_RFID”.

#id_maquina #id_tag #id_registo Tempo_registo

A tabela “Molde”, representada na Tabela 11, do mesmo modo que a tabela prévia, irá herdar o atributo “id_maquina”, sendo esta uma chave estrangeira. No entanto, será assumida como chave primária na criação da mesma na base de dados pelos motivos já expostos acima. Graças, ainda, à relação de multiplicidade entre as classes “Molde” e “Material”, será herdado o atributo “id_material” desta última, pela primeira, sendo esta uma chave estrangeira na tabela a criar. Para além destas, os atributos “id_molde” e “id_registo” identificam-se como chaves primárias.

Tabela 11 – Tabela da base de dados “Molde”.

#id_registo #id_maquina #id_material #id_molde Tempo_inicio A classe “Parametros_molde”, possuindo uma relação de composição com a classe “Molde”, resultará numa tabela, gerada a partir primeira referida, que herdará o atributo “id_molde” como chave estrangeira. Existirá ainda o atributo “Tempo_registo” a assumir-se como chave primária nesta tabela, estando a mesma representada na Tabela 12.

Tabela 12 – Tabela da base de dados “Parametros_molde”.

#id_molde #Tempo_registo T_molde

No caso da tabela resultante da classe “Material”, é obrigatória a identificação do atributo “id_material” como chave primária nesta tabela. Esta obrigação é resultado da solução chegada ao criar a tabela “Molde”, que resultou nesta última a herdar o atributo “id_material” como chave estrangeira da classe “Material”. Na Tabela 13, está representada a tabela, em questão, a criar na base de dados.

Tabela 13 – Tabela da base de dados “Material”.

#id_material Data_registo

Segue-se a criação da tabela “Parametros_material”, representada na Tabela 14, que graças à sua relação de composição com a classe “Material”, deverá herdar o atributo “id_material” como chave estrangeira, não sendo identificadas outras chaves de entre os atributos desta classe, “Parametros_material”.

Tabela 14 – Tabela da base de dados “Parametros_material”.

55

Resta a criação da tabela “Leitura_RFID”, representada na Tabela 15, sendo que, graças à sua relação associativa com a classe “Produto_RFID”, deverá herdar, como chaves estrangeiras, os atributos “id_registo” e “id_tag”, da segunda mencionada, não havendo nenhuma chave primária de entre os restantes atributos.

Tabela 15 – Tabela da base de dados “Leitura_RFID”.

#id_registo #id_tag Tempo_início_peca Tempo_fim_peca

Por fim, será apresentado na Figura 35, novamente, o diagrama de classes, desta vez destacando as chaves primárias e adicionando as chaves estrangeiras identificadas, respetivas a cada classe, sendo adicionado á frente de cada atributo os símbolos “*” e “**”, para diferenciar ambas as chaves, na respetiva ordem de menção, ou seja, primárias e estrangeiras.

56