O terceiro e último exemplo selecionado como caso de teste buscou trazer um modelo referente ao domínio considerado mais utilizado para a aplicação de persistência poliglota, o
Figura 49 – Criação de estruturas do Controle de Laboratório no Cassandra
Fonte: Autoria Própria
e-commerce, conforme descrito no Capítulo 3. Para isso utilizou-se o modelo descrito em Da-
lab (2019), pois trata-se de um modelo que retrata diversas funcionalidades envolvidas em um
website de comércio eletrônico e sua criação foi baseada em um estudo do funcionamento do
websiteda Amazon.
Outra razão para a seleção desse modelo para a aplicação do PDDM está no fato de que os Casos de Teste 1 e 2, apesar de demonstrarem a aplicação de várias regras de conversão em diferentes domínios, não aplicaram as regras R6 e R7. Estas regras demonstram a conversão de relacionamentos envolvendo entidades fracas, algo que não ocorre nos modelos descritos nas Seções 5.1 e 5.2.
A divisão por funcionalidades também não está disponível para os modelos já apresen- tados e é descrito pelos autores deste como ferramenta para melhor entendimento dos requisitos do sistema, além de servir como base para o processo de segmentação do PDDM. As funcionali- dades descritas pelos autores são: a) Controle de Usuários, b) Controle de Produtos e c) Controle de Pedidos. Para melhorar a visualização neste trabalho, alguns dos atributos do modelo original foram removidos, o que não alterou o mesmo. Uma visão geral do modelo proposto, convertido e com a identificação de funcionalidades pode ser vista na Figura 50.
A segmentação do modelo seguiu as definições fornecidas pelo modelo original. A pri- meira funcionalidade a ser tratada foi o Controle de Usuários. O MER resultante da segmentação pode ser observado na Figura 51. É possível verificar que, como não há nenhum relacionamento com cardinalidade N com entidades externas à funcionalidade, não foi necessária a criação de nenhuma réplica.
Para a definição de modelo de dados optou-se pela utilização do modelo Chave-Valor. O resultado da etapa de aplicação das regras de conversão para o modelo de agregados nesta unidade de segmentação pode ser observado na Figura 52. Para a conversão foi necessária a aplicação das seguintes regras:
∙ R1: Cria todas as entidades do MER no modelo, incluindo seus atributos;
∙ R2: Cria os relacionamentos 1 para 1 entre a Usuario e as entidades Comprador e Vende-
dor;
∙ R3: Cria os relacionamentos 1 para N entre Usuario e Endereco e entre Comprador e
Figura 50 – MER com ple to para o sistema de e-commer ce F onte: A dap tado de (D ALAB, 2019)
Figura 51 – MER segmentado para o Controle de Usuários
Fonte: Autoria Própria
Figura 52 – PDDM aplicado ao Controle de Usuários
Fonte: Autoria Própria
Como no modelo resultante não há nenhum relacionamento de composição, pode-se concluir que todas as entidades serão convertidas em agregados. O resultado dessa conversão são, portanto, cinco agregados a serem criados: Usuario, Vendedor, Comprador, Assinatura e Endereco.
Para demonstrar a aplicabilidade do método para a conversão final aos modelo de da- dos NoSQL, será realizada para esta unidade a conversão de estruturas para o formato de dados definido, neste caso o modelo Chave-Valor, utilizando o SGBD Redis. Os processos descritos aqui não fazem parte do escopo do PDDM e não seguem nenhum método pré-definido, apenas utilizam-se da experiência do autor deste trabalho no assunto e servem apenar como demonstra- ção de uma possível utilização do método na criação das bases de dados.
Como nos modelos Chave-valor não há a definição de estruturas para armazenamento de dados, mas apenas chaves vinculadas a valores, é necessário então estabelecer uma forma de organização e acesso aos dados. Para isso, utilizou-se prefixos nas chaves para a identifica- ção. Esses prefixos são compostos pelo nome da entidade seguido de uma barra "/", como por exemplo, "usuario/"ou "assinatura/". Para a definição do agregado optou-se pela utilização do formato JSON, representando os atributos das entidades como chaves do objeto gerado.
Figura 53 – Agregados do Controle de Usuários criados para a utilização no Redis
Fonte: Autoria Própria
dos e as relações entre eles. Na figura, os pares chave-valor são representados pelas caixas, onde o valor em negrito é a chave e o restante o valor. As setas são meramente ilustrativas e demons- tram as relações entre os pares chave-valor criados. Um exemplo da relação pode ser visto no par "usuario/1", que possui um registro no atributo "enderecos"com o valor "321", representando a relação com o par "endereco/321". Na Figura 54 pode ser observado um exemplo de criação do registro com chave "usuario/1"em uma base de dados Redis e o resultado de uma consulta pela sua chave.
Figura 54 – Exemplo de criação de agregado no Redis
Fonte: Autoria Própria
A próxima funcionalidade a ser convertida foi o Controle de Produtos. Como nesta funcionalidade não haviam entidades com relacionamentos de cardinalidade N para entidades externas, o processo de segmentação não exigiu a criação de nenhuma réplica. O resultado do processo de segmentação exigiu apenas a divisão do MER original com as entidades dessa uni- dade e pode ser observado na Figura 55.
A aplicação das regras de conversão ao MER resultou no modelo de agregados que pode ser visto na Figura 56. As seguintes regras foram aplicadas:
∙ R1: Cria todas as entidades do modelo com seus atributos;
∙ R2: Como todos os relacionamentos existentes no modelo são 1 para N, aplica-se a todos os relacionamentos.
Figura 55 – MER segmentado para o Controle de Produtos
Fonte: Autoria Própria
Figura 56 – PDDM aplicado ao Controle de Produtos
Fonte: Autoria Própria
Assim como na unidade de Controle de Usuários, não houve nenhum tipo de relacio- namento de composição criado e, portanto, todas as entidades irão gerar um agregado. Dessa forma, o modelo resultante possui sete agregados a serem criados, são eles: Produto, Departa- mento, Oferta, Desconto, Lista_desejos, Carrinho_compras e Avaliacao.
Para demonstrar a aplicabilidade do modelo gerado à utilização com os modelos de dados NoSQL, realizou-se o processo de transformação do modelo de agregados para o modelo de dados de família de colunas, mais especificamente para o uso no SGBD Cassandra. Para isso, é necessário inicialmente transformar os agregados em famílias de colunas ou tables, como são chamadas no Cassandra. Como toda tabela no Cassandra exige uma chave primária, no processo
de conversão o atributo chave do agregado se torna a chave primária da table e demais atributos formam as colunas. A Figura 57 demonstra a sequência de comandos para um exemplo de criação das famílias de colunas para a unidade de Controle de Produtos.
Figura 57 – Comandos em CQL para a criação do Controle de Produtos no Cassandra
Fonte: Autoria Própria
A terceira e última das funcionalidades a se aplicar o PDDM foi o Controle de Pedi- dos. Nessa funcionalidade os relacionamentos com as entidades das outras duas funcionalidades exigiram a criação de réplicas, sendo elas Pedido e Usuario. O resultado dessa segmentação e a criação das réplicas necessárias pode ser observado na Figura 58.
Figura 58 – MER segmentado para o Controle de pedidos
Fonte: Autoria Própria
É possível observar que neste caso ocorrem os primeiros exemplos de uso de entidades fracas, representadas pelas entidades Pagamento Cartão Crédito e Pagamento Cartão Presente o que permitirá aplicar as regras de conversão R6 e R7 do PDDM. O resultado final da conversão é demonstrado na Figura 59 e as seguintes regras foram aplicadas para a sua construção:
∙ R1: Cria todas as entidades do modelo com seus atributos;
∙ R3: Para todos os relacionamentos 1 para N do modelo, exceto os relacionados com enti- dades fracas;
∙ R6: Aplica-se ao relacionamento 1 para 1 entre a entidade Pagamento e Pagamento_cartao_presente. Essa regra cria o relacionamento de composição, representado pelo losângo preenchido;
∙ R7: Aplica-se ao relacionamento 1 para N entre a entidade Pagamento e Pagamento_cartao_credito. Da mesma forma que ocorre na R6, essa regra cria um relacionamento de composição en-
tre as entidades, porém com cardinalidade 1..*. Figura 59 – PDDM aplicado ao Controle de Pedidos
Fonte: Autoria Própria
Devido aos relacionamentos de composição criados pelas regras de conversão R6 e R7, as entidades Pagamento_cartao_presente e Pagamento_cartao_credito foram incorporadas à entidade Pagamento e, portanto, tem-se os seguintes agregados a serem criados: Pedido, Usu-
ario, Produto, Expedidor e Pagamento, que inclui as entidades Pagamento_cartao_presente e
Pagamento_cartao_credito.
Para demonstrar a aplicabilidade aos modelos NoSQL, neste módulo utilizou-se como modelo de dados destino o orientado a documentos, mais especificamente o SGBD MongoDB. Para melhor compreensão dessa conversão criou-se um conjunto de dados de exemplo, que pode ser visualizado na Figura 60. Os retângulos representam o conjunto de dados de um agregado, ou instâncias do agregado. No caso do modelo orientado a documentos existe a definição de
collectionsque podem ser utilizadas para retratar os agregados. Essas collections são represen-
tadas pela primeira linha em negrito no topo de cada retângulo, seguido do seu conjunto de dados em formato JSON. O atributo em negrito nos dados representa a chave de acesso ao agregado, que no caso do MongoDB deve ter sempre o nome "_id". As setas são meramente ilustrativas e demonstram os relacionamentos entre os dados.
É importante observar como os dados das entidades Pagamento_cartao_presente e Pa-
gamento_cartao_creditosão embutidos no agregado Pagamento, ao invés de possuírem apenas
uma referência à outro agregado. Isso ocorre devido ao relacionamento do tipo composição, conforme definido anteriormente.
Como no MongoDB não há necessidade de criação de estruturas lógicas para o ar- mazenamento de dados, ou collections conforme mencionado, os dados podem ser inseridos diretamente na base de dados e as collections serão criadas caso ainda não existam. Por isso,
Figura 60 – Conjunto de dados de exemplo para o Controle de Pedidos
Fonte: Autoria Própria
a sequência de comandos demonstrados na Figura 61 pode ser executada diretamente em uma base de dados MongoDB para criar os dados demonstrados na Figura 60.
Figura 61 – Exemplo de inserção de dados do Controle de Pedidos no MongoDB
Fonte: Autoria Própria