Para a aplicação do primeiro caso de teste foi utilizado o modelo entidade-relacionamento proposto em (SILBERSCHATZ; KORTH; SUDARSHAN, 2010). Este modelo trata um sistema de controle universitário. Entre os objetivos do modelo estão o controle de departamentos e os cursos ofertados, o prédio utilizado e orçamento disponível. Além disso, o controle de créditos dos alunos, professores e disciplinas ofertadas, controlando as salas de aula utilizadas e horários de aula. O modelo apresenta diversas características da modelagem conceitual, como relacio- namentos 1 para N, N para N, auto-relacionamento e relacionamentos parciais e totais o que permite explorar a aplicação do método PDDM de forma mais detalhada.
Para melhor adequação do modelo a este documento, foi realizada a tradução para a língua portuguesa e transformação de notação, procurando manter suas definições originais. Como o modelo proposto não possuía a definição de funcionalidades e a mesma é requisito da entrada de dados para o método, uma definição de funcionalidades foi proposta utilizando o conhecimento do autor e identificada no modelo utilizando-se diferentes cores para as entidades. Essa divisão apresenta duas funcionalidades, identificadas pelas cores das entidades no modelo, sendo: a) Controle de Cursos, com as entidades Curso e Departamento representada pela cor azul e b) Controle de Disciplinas, com as demais entidades do modelo representadas pela cor amarela. O resultado dessas transformações é demonstrado na Figura 31.
Figura 31 – MER Proposto para o Caso de Teste 1
Fonte: Adaptado de (SILBERSCHATZ; KORTH; SUDARSHAN, 2010)
Conforme descrito no Capítulo 4, a primeira etapa para a aplicação do PDDM é a seg- mentação do modelo baseado em sua definição de funcionalidades. Esse processo se inicia pela separação das entidades de cada funcionalidade em um MER específico para cada unidade de segmentação. Em seguida, são identificadas as entidades de necessitam da criação de réplicas por meio da verificação dos relacionamentos com cardinalidade N que ficam na fronteira entre as funcionalidades. No caso do Controle de Cursos, existem três relacionamentos na fronteira da unidade, com as seguintes entidades: Professor, Aluno e Seção. Porém, todos esses relacio- namentos possuem cardinalidade 1 no lado da entidade do Controle de Cursos, o que descarta a necessidade de criação de réplicas. O resultado da segmentação são apenas as entidades per- tencentes a funcionalidade, conforme demonstrado na Figura 32.
Figura 32 – MER segmentado com o Controle de Cursos
Com os modelos devidamente separados é possível realizar a etapa de definição do modelo de dados a ser utilizado. Como esse processo exigiria um detalhamento mais aprofun- dado dos requisitos e não há um método estabelecido para essa definição, utilizou-se o modelo de família de colunas apenas para permitir a demonstração do processo de transformação dos dados.
Em seguida pode ser realizada a etapa de transformação, onde serão aplicadas as regras de transformação de modelos, apresentadas na Seção 4.3.4. O objetivo dessa etapa é obter o modelo de agregados capaz de ser utilizado para os modelos de dados baseados nestas estruturas. A aplicação da etapa de transformação no Controle de Cursos é a mais simples por se tratar de apenas 2 entidades e seu resultado pode ser visto na Figura 33. Das regras de transformação propostas, duas foram aplicadas:
∙ R1: Aplica-se a todas as entidades. Por meio dela foram criadas as entidades Departamento e Curso, preservando a chave primária e demais atributos do MER;
∙ R3: Aplica-se aos relacionamentos 1 para N que podem ser vistos na Figura 32, entre as entidades Departamento e Curso e no auto-relacionamento da entidade Curso. Nessa etapa são criados os relacionamentos entre as entidades previamente criadas e os atributos
cursos, departamento e prerequisitos.
Figura 33 – Regras de conversão do PDDM aplicadas ao Controle de Cursos
Fonte: Autoria própria
Nesse ponto tem-se o modelo de agregados completo para o Controle de Cursos, onde podem ser identificados dois agregados: Departamento e Curso, compostos por suas respectivas entidades. Apesar de estar fora do escopo do PDDM, é interessante realizar a demonstração da derivação para o projeto físico dessa unidade, o que demonstra a aplicabilidade do resultado do método no projeto de banco de dados. Para isso, selecionou-se o SGBD Cassandra, por se tratar de um dos SGBDs mais utilizado tratando-se do modelo de dados família de colunas.
Os agregados no Cassandra são armazenados nas famílias de colunas, que são chamadas de tables em sua linguagem de consulta CQL. São necessárias, portanto, a criação de 2 famílias de colunas para o Controle de Cursos: departamento e curso. A Figura 34 demonstra a sequência de comandos necessários para a criação dessas estruturas no Cassandra. É possível visualizar que as colunas de relação entre as entidades são do mesmo tipo que a chave primária que referenciam como, por exemplo, a coluna departamento da table curso do tipo int que referencia a chave
primária de departamento_id da table departamento. É interessante notar a similaridade com o modelo relacional, apesar de se tratarem de estruturas de armazenamento bastante distintas.
Figura 34 – Criação das famílias de colunas para o Controle de Cursos
Fonte: Autoria própria
Em seguida foi aplicado o processo de segmentação na funcionalidade de Controle de Disciplinas. Assim como no Controle de Cursos, as entidades pertencentes à funcionalidade foram colocadas em um MER separado e seus relacionamentos com entidades externas foram analisados. Nessa unidade, os três relacionamentos existentes com as entidades Departamento e Curso possuem cardinalidade N nas entidades Professor, Aluno e Seção, o que determina que são necessárias réplicas para a unidade. As replicas são então criadas no modelo mantendo sua coloração original para facilitar a identificação da unidade de origem, mas com linhas traceja- das para identificar que tratam-se de réplicas. Na criação de réplicas o projetista pode optar pela eliminação de atributos da entidade que considere desnecessários para a unidade, com exceção de sua chave primária que deve ser mantida. Para demonstrar essa possibilidade, decidiu-se por desconsiderar os atributos prédio e orçamento da entidade Departamento, por não serem ne- cessários ao Controle de Disciplinas. A Figura 35 apresenta o MER resultante da aplicação do processo de segmentação, onde é possível observar as duas réplicas criadas.
Figura 35 – MER proposto para o Controle de Disciplinas
Fonte: Autoria própria
Para demonstração em outro modelo de dados de agregados, optou-se pela utilização do modelo de dados orientado a documentos. Durante a aplicação das regras de conversão, percebe-
se que a funcionalidade de Controle de Disciplinas possui mais entidades e relacionamentos e aplica-se um número maior de regras de conversão, conforme pode ser observado na Figura 36. São elas:
∙ R1: Recria todas as entidades com suas chaves e atributos;
∙ R3: Aplica-se a todos os relacionamentos 1 para N na forma de agregação, criando os atri- butos para relacionamento nas entidades. São exemplos desse relacionamento as relações entre as entidades Departamento e Professor, e entre Aluno e Departamento;
∙ R5: Aplica-se aos relacionamento N para N com atributos. Esse caso pode ser visto entre as entidades Aluno e Seção. Nesse caso, 2 entidades foram criadas, Aluno Seção e Seção
Aluno, representando os dois sentidos do relacionamento, o que é necessário para permitir
o acesso às entidades relacionadas em ambos os sentidos. Essas entidades associativas são criadas como composição da entidade de origem, possuem os atributos do relacionamento, além do campo de associação com a entidade oposta.
Figura 36 – PDDM aplicado ao Controle de Disciplinas
Fonte: Autoria própria
Com o modelo de agregados completo para o Controle de Disciplinas pode-se identifi- car seus agregados. Essa unidade possui 2 relacionamentos de composição, o que faz com que nem todas as suas entidades se tornem agregados, como é o caso das entidades Seção Aluno e Aluno Seção. Neste caso elas farão parte da constituição dos agregados Seção e Aluno, respec-
tivamente. Temos portanto os seguintes agregados definidos: Departamento, Curso, Professor, Aluno, Seção, Sala e Horário.
Para exemplificar a execução do projeto físico, optou-se pela utilização do MongoDB como SGBD, por ser amplamente utilizado e representa o modelo de dados orientado a docu- mentos. Empregou-se a estrutura de collections para a definição dos agregados no MongoDB, criando uma para cada agregado, porém, nenhuma outra definição lógica é necessária para o SGBD. Para permitir uma melhor compreensão criou-se então um conjunto de dados de exem- plo, para demonstrar a forma como os dados seriam armazenados e como os agregados se rela- cionam. Esse conjunto de dados pode ser visualizado na Figura 37.
Figura 37 – Exemplo de dados para o Controle de Disciplinas
Fonte: Autoria própria
Na Figura 37, cada retângulo representa um documento, e seu título - a primeira linha em negrito - representa a collection ao qual ele pertence. Foi destacado também a chave primá- ria do agregado, que no MongoDB deve possuir o nome "_id". Foram destacados também os atributos "alunos"e "secoes"dos agregados secao e aluno, respectivamente, por se tratarem das entidades associativas criadas no modelo de agregados para possibilitar o relacionamento com atributos. Foram adicionadas setas que são meramente ilustrativas e indicam os relacionamen- tos entre os agregados. Tendo definido o conjunto de dados, é possível a inserção no MongoDB conforme demonstrado na Figura 38.