INSTITUTO TECNOLÓGICO DE AERONÁUTICA
RELATO PADRONIZADO LISTEX3 CE-240
CIRO FERNANADES MATRIGRANI
PROFESSORES ADILSON CUNHA E VIEIRA DIAS
SÃO JOSÉ DOS CAMPOS
1
INTRODUÇÃO
1.1
OBJETIVO
Esta ListEx3 visa o desenvolvimento da versão 1.0 de um Protótipo de Aplicativo de Banco de Dados (ABD), na 3ª Forma Normal (3FN), no contexto da temática escolhida pelo autor no projeto Smart Grids, visando melhorar os tempos de acesso, em termos de armazenamento e recuperação de Informações, e reduzir as anomalias de atualizações e inconsistências.
1.2
MOTIVAÇÃO
O estudo da normalização existe para manter as informações em uma base de dados para que funcionem do jeito que são administradas no mundo real. A percepção desta realidade, “forma normal”, se torna difícil sem o uso de técnicas teóricas.
Para um profissional de banco de dados, a normalização é imprescindível no começo para evitar futuras complicações, pois, em uma base dados, a tendência é o aumento do esforço para administração dos dados conforme a massa de registro vai surgindo.
2
DESCRIÇÃO DOS PRINCIPAIS PROCEDIMENTOS
As seções a seguir apresentam o desenvolvimento das formas normais 1FN, 2FN, 3FN, além da 0FN como um banco completamente desnormalizado do Projeto de Aplicativo de Banco de Dados de ILUminação INdustrial (ABD-ILU-IN) propiciando as seguintes funcionalidades:
• Monitoramento de Luzes Industriais de Emergência; • Controle de Alarmes; e
• Gerenciamento Operacional.
A seções a seguir apresentam respectivamente as formas normais 0FN, 1FN, 2FN e 3FN.
2.1
Sem Forma Normal (0FN).
A coleção de campos a seguir foi colocada de forma a atender os requisitos mostrados acima sem considerar o risco de anomalias de exclusão, inserção ou alteração.
0FN = EmergencyNumber
{
Description
, Localization, LastUsage, LastDurationUsage,
Power-Wh
}
Exemplo de tuplas:
Description Localization LastUsage LastDurationUsage Power-Wh
Lâmpada Térreo, sertor G 23/04/2007 7:15 PM 4h e 14 mim 100 Wh
Alarme ASSIS SEG. Ltda
2º andar 22° 54' 21.64"S 47° 03' 38.06"W
07/01/2011 9:45 AM 7 mim 150 Wh
Alarme ASSIS Ltda 2º andar 22° 54' 21.64"S 47° 03' 38.06"W 18/09/2010 10:20 AM 5 mim 150 Wh Luz de Emergência 6765431-7 22° 54' 21.64"S 47° 03' 38.06"W 23/09/2009 5:30 PM 2h 100Wh
A seção a seguir mostra a absorção de anomalias de inserção por meio da primeira forma normal.
2.2
Primeira Forma Normal (1FN).
Podemos ver que podem existir anomalias de inserção nos campos Description que pode ser composto de varias informações (modelo, número serial...) e Localization, podendo assumir vários tipos de descrições de localização (setor, coordenadas geográficas, descrições textuais...). Isto ocorre por que estes campos não são atômicos e suas instâncias podem assumir formatos não bem definidos.
A resolução deste problema foi a alteração destes campos por campos atômicos, possibilitando instâncias desses campos que assumirão formatos bem definidos como vemos na 1FN:
1FN = EmergencyNumber
{
PartNumber
,
SerialNumber
, Supplier, Longitude, Latitude,
LastUsage, LastDurationUsage, Power-Wh
}
Exemplo de tuplas:
PartNumber SerialNumber Supplier Longitude Latitude LastUsage LastDurationUsage Power-Wh Lâmpada 5678765-7 ASSIS SEG. LTDA 47° 03' 38.06"W 22° 54' 21.64"S 23/04/2007 7:15 PM 4h e 14 mim 100 Wh Alarme 123124-5 ASSIS SEG. LTDA 47° 03' 38.06"W 22° 54' 21.64"S 07/01/2011 9:45 AM 7 mim 150 Wh Alarme 123124-5 ASSIS SEG. LTDA 47° 03' 38.06"W 22° 54' 21.64"S 18/09/2010 10:20 AM 5 mim 150 Wh Luz de Emergência 6765431-7 ASSIS SEG. LTDA 47° 03' 38.06"W 22° 54' 21.64"S 23/09/2009 5:30 PM 2h 100 Wh
A seção a seguir mostra a absorção de parte das anomalias de atualização e exclusão por meio da segunda forma normal.
2.3
Segunda Forma Normal (2FN).
O modelo em 1FN ainda apresenta anomalias de atualização e exclusão. A modificação do nome de um Supplier ou PartNumber gerará obrigatoriedade da alteração de vários registros, como os das entradas de usabilidade. Isto ocorre porque não existe uma dependência funcional dos campos com suas chaves. Ex: LastDurationUsage depende funcionalmente de LastUsage, mas Supplier não. A alteração ou exclusão de um campo Supplier não deve interferir em LastDurationUsage.
A resolução deste problema foi a criação de outras entidades fazendo com que todos os campos permaneçam com dependência funcional de suas chaves como vemos na 2FN:
2FN = EmergencyNumber
{
PartNumber
,
SerialNumber
, Supplier, Power-Wh, Longitude,
Latitude,
}
2FN = EmergencyNumberUsage
{
PartNumber
,
SerialNumber
,
LastUsage
, LastDurationUsage,
}
Exemplo de tuplas
EmergencyNumber
:PartNumber SerialNumber Supplier Longitude Latitude Power-Wh
Lâmpada 5678765-7 ASSIS SEG. LTDA 47° 03' 38.06"W 22° 54' 21.64"S 100 Wh Alarme 123124-5 ASSIS SEG. LTDA 47° 03' 38.06"W 22° 54' 21.64"S 150 Wh Luz de
Emergência
6765431-7 ASSIS SEG. LTDA 47° 03' 38.06"W 22° 54' 21.64"S 100 Wh
Exemplo de tuplas
EmergencyNumberUsage
:PartNumber SerialNumber LastUsage LastDurationUsage
Lâmpada 5678765-7 23/04/2007 7:15 PM 4h e 14 mim
Alarme 123124-5 07/01/2011 9:45 AM 7 mim
Alarme 123124-5 18/09/2010 10:20 AM 5 mim
Luz de Emergência 6765431-7 23/09/2009 5:30 PM 2h
A seção a seguir mostra a absorção das anomalias de atualização e exclusão restantes por meio da terceira forma normal.
O modelo em 2FN ainda apresenta anomalias de atualização e exclusão. Vemos que todos os campos possuem dependência funcional em relação as suas chaves, mas não é uma dependência funcional direta. Supplier e Power-Wh depende funcionalmente de PartNumber, mas Longitude e Latitude depende funcionalmente do SerialNumber. Na Tabela EmergencyNumberUsage vemos que LastDurationUsage depende de SerialNumber e LastUsage, mas não de PartNumber.
A resolução deste problema foi a criação de outras entidades fazendo com que todos os campos permaneçam com dependência funcional direta de todas as suas chaves como vemos na 3FN:
3FN = EmergencyNumber
{
PartNumber
, Supplier, Power-Wh
}
3FN = EmergencyNumberItem
{
SerialNumber
, PartNumber, Longitude, Latitude,
}
3FN = EmergencyNumberItemUsage
{
SerialNumber, LastUsage
, LastDurationUsage,
}
Exemplo de tuplas
EmergencyNumber
:PartNumber Supplier Power-Wh
Lâmpada ASSIS SEG. LTDA 100 Wh
Alarme ASSIS SEG. LTDA 150 Wh
Luz de Emergência ASSIS SEG. LTDA 100 Wh
Exemplo de tuplas
EmergencyNumberItem
:SerialNumber PartNumber Longitude Latitude
5678765-7 Lâmpada 47° 03' 38.06"W 22° 54' 21.64"S
123124-5 Alarme 47° 03' 38.06"W 22° 54' 21.64"S
6765431-7 Luz de Emergência 47° 03' 38.06"W 22° 54' 21.64"S
Exemplo de tuplas
EmergencyNumberItemUsage
: SerialNumber LastUsage LastDurationUsage5678765-7 23/04/2007 7:15 PM 4h e 14 mim
123124-5 07/01/2011 9:45 AM 7 mim
123124-5 18/09/2010 10:20 AM 5 mim
Com estas alterações podemos concluir que anomalias de exclusão e alteração foram absorvidas pelas formas normais. É possível armazenar vários itens, vários modelos e gerenciar as operações de dispositivos de emergência mantendo a integridade dos dados.
3
PRINCIPAIS CONCLUSÕES
O termo normalização dos dados remete ao entendimento de que as informações existem no mundo real de uma “forma normal”, ou se organizam na regra de negócio a qual a base de dados se propõe a atender em uma “estrutura abstrata existente no mundo real”.
Arriscar erros no começo pode gerar anomalias de inserção, exclusão e alteração nos dados, que são agravadas conforme a base cresce tornando a manutenção mais penosa. As anomalias são defeitos perigosos para o negócio, pois, quanto mais longo os defeitos persistem, mais comuns se tornam as falhas, e os erros decorrentes destas falhas podem resultar em uma manutenção demasiadamente custosa, e uma conseqüente e inevitável entropia do sistema.