Banco de Dados I – Aula 08A

ASPÉCTO TEMPORAL

 

Modelo deve refletir o aspecto temporal

  • Certas aplicações exigem que o BD guarde o histórico de alterações de informações. Por exemplo, um BD de uma seguradora.
  • Pode ser necessário conhecer não só o segurado atual de uma apólice, mas também os do passado.
  • O modelo de um BD que armazena somente os valores atuais de uma informação é diferente do modelo do BD que armazena o histórico da informação. Portanto, é necessário considerar o aspecto temporal na modelagem de dados.
  • Não há regras gerais de como proceder neste caso, mas é possível identificar alguns padrões que se repetem frequentemente na prática.

 

Atributos cujos valores modificam ao longo do tempo

  • Alguns atributos de uma entidade, normalmente aqueles que não são identificadores da entidade, podem ter seus valores alterados ao longo do tempo (por exemplo, o endereço de um cliente pode ser modificado).
  • Algumas vezes, por necessidades futuras de informações, ou até mesmo por questões legais, o banco de dados deve manter um registro histórico das informações.
  • Um exemplo é o valor do salário do empregado.
  • Num sistema de pagamento, não interessa saber apenas o estado atual, mas também o salário durante os últimos meses, por exemplo, para emitir uma declaração anual de rendimentos de cada empregado.
  • Assim, o salário não pode ser modelado como atributo, mas sim como uma entidade.
  • Exemplo

ScreenHunter_229 Sep. 26 20.32

 

ScreenHunter_231 Sep. 26 20.53

 

Relacionamentos que modificam ao longo do tempo

  • Assim como atributos podem ter seus valores modificados ao longo do tempo, também relacionamentos podem ser modificados (instâncias dos relacionamentos podem ser modificados, adicionadas/removidas) e também neste caso pode ser requerido que o banco de dados mantenha um registro histórico das alterações.
  • Quando é considerada a história de suas alterações, relacionamentos 1:1 ou 1:n são transformados n:n.

ScreenHunter_232 Sep. 26 21.05

ScreenHunter_233 Sep. 26 21.06

 

Modelando a dimensão temporal de relacionamentos 1:1

  • Para exemplificar, consideramos o relacionamento LOCAÇÃO (a). Este relacionamento possui cardinalidade 1:1, ou seja, cada empregado está alocado a no máximo uma mesa e cada mesa tem ela alocado no máximo um empregado.
  • Este modela está correto, caso deseje-se armazenar no banco de dados apenas a alocação atual de cada mesa. Entretanto, caso deseje-se armazenar também a história das alocações, isto é, que empregados estiveram alocados a que mesas ao longo do tempo, é necessário modificar o modelo para (b).
  • O relacionamento para a ter cardinalidade N:N, já que, ao longo do tempo um empregado pode ter sido alocado a diversas mesas e uma mesa pode ter sido a ela alocados a muitos empregados.
  • Como um mesmo empregado pode ter sido alocado a mesma mesa múltiplas vezes, torna-se necessário um atributo identificador do relacionamento, a fim de distinguir uma alocação de um determinado empregado a uma mesa, das demais alocações deste emprega à mesma mesa. Com isso surge o atributo identificador data.

ScreenHunter_234 Sep. 26 21.07

ScreenHunter_235 Sep. 26 21.08

  • A figura anterior apresenta uma situação semelhante agora considerando um relacionamento de cardinalidade 1:N. Se quisermos considerar a história das lotações de empregados ao longo do tempo, é necessário transformar o relacionamento para a cardinalidade N:N, já que ao longo do tempo um empregado pode ter atuado em diferentes departamentos.
  • Neste caso pode ocorrer também que atributos da entidade EMPREGADO migrem para o relacionamento. No caso do exemplo, isso ocorrer com o atributo nr doc lotação. Este atributo, que, na primeira versão, migra, na nova versão, para o relacionamento, já que na nova versão um empregado pode estar relacionado com múltiplos departamentos.

 

Modelando a dimensão temporal de relacionamentos N:N

  • Na figura seguinte apresenta mais outro exemplo relacionamento temporal, agora um relacionamento de cardinalidade N:N. Modela-se a inscrição de participantes nos cursos oferecidos por uma empresa de treinamento.
  • Na primeira versão, considera-se apenas os cursos nos quais uma pessoa está inscrita em um determinado instante no tempo. Na segunda versão, considera-se todas as inscrições, inclusive as do passado.
  • A modificação de uma versão para a outra consta da transformação do atrubuto data em atributo identificador. Isso ocorre porque, na segunda versão, um participante pode aparecer relacionamento múltiplas vezes a um determinado curso (caso ele tenha se inscrito múltiplas vezes no curso).
  • O atributo para a distinguir uma inscrição de uma pessoa em um curso, das demais inscrições desta pessoa no mesmo curso.

ScreenHunter_236 Sep. 26 21.10

ScreenHunter_237 Sep. 26 21.10

 

Consultas a dados referentes ao passado

  • Muitas vezes, para evitar o crescimento desmedido do banco de dados, informações referentes ao passado são eliminadas.
  • Entretanto, estas informações podem ser necessárias no futuro, por exemplo, por motivos legais, para realização de auditorias ou para tomada de decisões. Portanto, é necessário planejar, desde a modelagem, por quanto tempo as informações ficarão armazenadas no banco de dados.
  • Caso informações antigas fiquem no banco de dados, podem ser necessários atributos para indicar o status da informação, se atual ou antiga.

 

Planejar o arquivamento de informações antigas

  • Para as informações que serão retiradas do banco de dados e armazenadas em arquivos convencionais, é necessário fazer um planejamento de como estas informações serão acessadas no futuro, caso venham a ser necessárias.
  • Uma solução que poderia ser considerada, é a de reincluir as informações no banco de dados, quando elas forem necessárias no futuro. Isso permite que, para buscar as informações passadas, sejam usados os mesmos procedimentos que são usados para acessar as informações atuais.
  • Entretanto, é necessário considerar que as informações em um banco de dados estão normalmente relacionadas a outras. Casos as ocorrências de entidade que se deseja devolver à base de dados estejam relacionadas a outras ocorrências, é necessário que estas estejam presentes.
  • Se elas também tiverem sido excluídas, deverão ser igualmente devolvidas à base de dados. Essa inclusão pode ser propagada em cascata para outras entidades.

 

Planejar informações estatísticas

  • Em alguns casos, informações antigas são necessárias apenas para tomada de decições. Neste caso, muitas vezes deseja-se apenas dados resultantes de cálculos ou estatísticas sobre as informações, como totais, contagens, médias, etc.
  • Assim pode ser conveniente manter o banco de dados estas informações compiladas e eliminar as informações usadas na compilação.

GitHub

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

learningdatabase.com.br

Tecnologias em Banco de Dados Relacionais, Modelagem de dados dimencionais, tecnologias SQL Servere e Oracle

Aprendendo Programação

Algorítmos, C, C++,Pascal, Python, R

WikiDBA

by Virendra Yaduvanshi - Microsoft SQL Server Database Architect | Consultant | Blogger | Specialist | DBA | Speaker

Blog - Fabiano Neves Amorim

SELECT * FROM [Coisas Da Minha Cabeça] WHERE dbo.fn_TempoParaPost() < dbo.fn_TempoLivre()

Tércio Costa, Oracle Developer, OCE SQL, ACE Associate

Guia de estudos para certificação ORACLE SQL(1Z0-047, 1Z0-051, 1Z0-061 e 1Z0-071) e PL/SQL(1Z0-144, 1Z0-146 e 1Z0-148)

Strate SQL

Data Adventures with an Architect

%d blogueiros gostam disto: