Função primordial do projeto físico é a escolha do SGBD mais adequado para cada modelo de dados. Essa escolha exige uma análise criteriosa e um bom equilíbrio entre seus prós e contras é crucial para o projeto físico do banco de dados. Uma vez selecionado e implementado, a transição para outro software pode exigir grandes esforços, principalmente para os modelos de dados NoSQL. Essa dificuldade ocorre por não haver uma forma de acesso uniforme aos dados das bases de dados NoSQL, como acontece com a linguagem SQL nos bancos de dados relacionais.
A transição entre diferentes softwares NoSQL, mesmo sendo de um mesmo modelo, exige que a implementação do banco de dados seja refeita, considerando as diferentes formas
de acesso, funcionalidades e recursos de cada software, o que comprometeria o projeto físico. Essa escolha exige, portanto, o conhecimento do projetista para comparar os recursos de cada software e quais aplicações seriam necessárias, por isso, decidiu-se por deixar esse processo fora da definição do PDDM. Ainda assim, serão apresentados aqui quais os objetivos da definição de modelos de dados e os fatores que devem ser considerados. Serão tratados aqui apenas alguns exemplos do resultado de uma aplicação do PDDM até a conversão para o projeto físico.
Dada a semelhança lógica entre os modelos baseados em agregados, até esse ponto do projeto de banco de dados utilizou-se um mesmo método para o projeto lógico dos 3 modelos baseados em agregados: 1) chave-valor, 2) orientado a documento e 3) família de colunas. Porém, nesta etapa do projeto de banco de dados é necessário que processos distintos sejam definidos para os modelos de dados e especificar os processos de criação de estrutura para cada software a ser utilizado.
Para exemplificar o projeto físico, é utilizado o modelo da Figura 12 que apresenta a definição do projeto para a unidade Carrinho de Compras do modelo de exemplo, considerando que essa unidade poderia ser implementada por qualquer um dos 3 modelos de dados. Como softwares serão utilizadas as seguintes opções:
∙ Chave-valor: Redis (REDIS, 2018)
∙ Orientado a documento: MongoDB (MONGODB, 2018) ∙ Família de Colunas: Cassandra (CASSANDRA, 2018)
Para uma melhor visualização do modelo de exemplo, a Figura 26 traz uma represen- tação visual mais compreensível dos dados de um Carrinho de Compras de exemplo e serve para a representação de um agregado nos modelos descritos. Serão utilizados esses dados para os exemplos nos modelos a seguir.
Figura 26 – Representação do Carrinho de Compras como agregado
Fonte: Autoria Própria
4.4.1 Chave-Valor
Utilizou-se o Redis (2018) como software de exemplo do modelo chave-valor devido a sua popularidade no mercado, sendo indicado para uso por diversos provedores de serviços
em cloud. Assim como os demais softwares desse modelo, o Redis (2018) armazena seus dados diretamente, sem tipos de dados específicos ou quaisquer validações sobre os dados e pode ser utilizada qualquer forma de representação dos dados dos agregados. Optou-se por utilizar JSON, devido ao seu amplo uso em bancos de dados NoSQL e adaptação à linguagens de programação. Apesar da flexibilidade no armazenamento dos dados, duas informações são importan- tes para manter a coesão entre o modelo lógico definido e o modelo físico: o nome do agregado e a sua chave. Para isso é utilizada a combinação de seus dois valores para a representação do agregado, formando o valor "carrinho_compra/1", utilizado como chave para o armazenamento dos dados.
Diferente do que ocorre com o modelo relacional, os bancos de dados chave-valor não possuem nenhum tipo de criação de estrutura. Seus dados são inseridos apenas pela definição de um valor para a chave e um valor associado, sem nenhum tipo de estrutura a ser criada, como acontece com a criação de tabelas no modelo relacional. Por isso, o projeto físico restringe-se apenas à definição do formato de armazenamento de dados, que no exemplo é JSON, e o formato a ser utilizado para a sua chave, que seria "carrinho_compras/<identificador>". A Figura 27 representa os comandos para a definição e extração dos dados conforme o agregado definido, caso os dados já existam, serão substituídos pelo valor informado.
Figura 27 – Comandos para a definição e extração dos dados no Redis
Fonte: Autoria Própria
4.4.2 Orientado a Documento
O MongoDB (2018) foi escolhido como representante do modelo de dados orientado a documento por sua representatividade no mercado, estando entre os mais utilizados do modelo. Ele utiliza internamente os dados em formato BSON, mas para visualização representa seus dados em formato JSON e essa é a única restrição em relação ao formato dos dados.
O agregado pode ser representado por uma collection, para organização dos dados, que chamou-se de "carrinho_compras". A chave dos registros é representada pelo campo "_id" den- tro do documento armazenado, portanto, faz parte dos dados do documento e pode ser definido pelo usuário ou auto-gerado. A chave "_id" será utilizada para representar essa chave única. Apesar da existência do comando "db.createCollection" para a criação de novas collections na
base de dados, esse comando é útil apenas para a definição das configurações de tamanho das
collections, configurações de indexação entre outras, não sendo realmente necessário para a in-
serção dos dados. Tais configurações fazem parte de um projeto físico detalhado da base de dados, mas fogem ao escopo deste trabalho. Importante é saber que ao tentar inserir dados em uma collection inexistente, ela será automaticamente criada e pode ser utilizada normalmente. A Figura 28 demonstra um exemplo de inserção e extração dos dados condizente com o modelo de dados de exemplo.
Figura 28 – Comandos para a inserção e extração no MongoDB
Fonte: Autoria Própria
4.4.3 Família de Colunas
Para a implementação do modelo de família de colunas utilizou-se o Cassandra (2018) como software de exemplo. O modelo de família de colunas é o mais semelhante ao modelo re- lacional, não apenas pela sua estrutura composta por linhas e colunas, mas pela necessidade de criação de estruturas como tabelas, chaves primárias e índices. O Cassandra utiliza-se da lingua- gem Cassandra Query Language (CQL) que possui similaridades com a linguagem SQL, porém com as limitações do modelo de dados, como a ausência de junções. Por essa razão, o projeto físico para o Cassandra tem similaridades com o projeto físico de um banco de dados relacional, resultando em um conjunto de comandos em linguagem CQL para a criação de suas tabelas, que devem refletir a estrutura de agregados definida no projeto lógico detalhado anteriormente.
Enquanto no projeto físico de um banco de dados relacional são utilizadas múltiplas relações para a representação de um agregado com múltiplas entidades, no Cassandra os agre- gados são representados em apenas uma linha de dados por meio do uso de tipos como "tuple", que define uma sequência de tipos de dados a serem armazenados, tipos definidos pelo usuário ou coleções. As coleções podem ser dos seguintes tipos:
∙ Map: Armazena um conjunto de chave-valor; ∙ List: Armazena uma lista de valores;
∙ Set: Semelhante ao List, porém não permite itens repetidos.
Os tipos definidos pelo usuário do Cassandra permitem uma definição mais estruturada dos dados, permitindo a criação de múltiplos campos com definição de nomes e tipos de dados
para cada um deles, enquanto o tipo tuple apenas representa os tipos de dados dos campos. Para a utilização dos tipos de dados é necessário dar nomes aos tipos de dados das entidades internas dos agregados, de forma a não coincidirem com entidades externas ou tipos de outros agregados. Para isso, convencionou-se a adição do nome da entidade principal do agregado seguido de "_"e o nome da entidade interna. A Figura 29 traz a sequência de comandos na linguagem CQL para a criação da tabela referente ao agregado do carrinho de compras seguido de um comando de inserção dos dados e consulta.
Figura 29 – Comandos CQL para a criação e consulta no Cassandra
Fonte: Autoria Própria
Uma outra maneira de representar os mesmos dados é a utilização do tipo tuple, con- forme demonstrado na Figura 30. Ambas as formas de implementação são aceitáveis pois repre- sentam todos os dados necessários do agregado definido. A diferença está apenas na forma de apresentação dos dados.
A utilização de tipos de dados definidos pelo usuário ou do tipo nativo tuple não está apenas na forma visual de representação dos dados. Enquanto o tipo tuple deixa toda a estrutura mais flexível, perde as informações sobre o esquema dos dados armazenados, pois não possui nomes atribuídos aos valores armazenados. Os tipos definidos pelo usuário, por outro lado, res- tringem a estrutura dos dados apenas às estruturas criadas, por isso são menos flexíveis, mas visualmente mais compreensíveis.
A partir dessas definições do projeto físico para os modelos de dados NoSQL baseados em agregados, pode-se verificar que o mesmo processo pode ser aplicado para os SGBDs sele- cionados, distinguindo as particularidades de cada modelo e software. Com o desenvolvimento
Figura 30 – Comandos CQL para a criação e consulta no Cassandra utilizando tuple
Fonte: Autoria Própria
do projeto físico para todas as unidades de segmentação completa-se o objetivo do projeto de banco de dados que é realizar a transformação do projeto conceitual em projeto físico, dentro de uma estrutura capaz de comportar diversos modelos que se integram às camadas da aplicação.
4.5 CONSIDERAÇÕES DO CAPÍTULO
A criação do método de projeto de banco de dados PDDM prevê a transformação do modelo conceitual em modelo lógico, que pode então ser utilizado para a execução do projeto físico em sistemas onde a utilização de múltiplos modelos de dados se faz necessária para atender seus requisitos. Para atingir esse objetivo diversas sub-etapas são executadas durante o projeto lógico visando promover a correta segmentação do modelo, a definição do modelo de dados a ser utilizado e um conjunto de regras de conversão, provendo um processo formal para sua aplicação.
O método PDDM utiliza-se de uma definição de funcionalidades do sistema sobre o seu MER, que é utilizada como ponto de partida para a divisão do sistema em unidades se segmentação. Para manter a consistência das unidades, a definição de regras para a criação de réplicas se fez necessária. Essas unidades podem optar independentemente pelo uso de um dos modelo de dados suportados.
O conjunto de regras proposto pelo PDDM é capaz de transformar o resultado da seg- mentação do MER em modelos de agregados. Este conjunto de regras visa estabelecer um pro- cesso formal a ser utilizado para a transformação dos modelos, resultando em um modelo que preserva as características do modelo original enquanto permite a sua utilização nas bases de dados orientadas a agregado.
Utilizando-se dos resultados obtidos pela transformação do PDDM, pode-se realizar o projeto físico a fim de criar as estruturas de dados necessárias para a utilização dos modelos de dados selecionados durante o processo, podendo utilizar um SGBD que seja considerado mais adequado.
5 RESULTADOS
Este capítulo apresenta os resultados obtidos com a aplicação do método PDDM em 3 casos de teste, para mostrar sua usabilidade em cenários diversos. Os dois primeiros casos foram selecionados de Silberschatz, Korth e Sudarshan (2010) e Rob e Coronel (2007) por se tratarem de exemplos conhecidos na literatura no domínio de projeto de banco de dados. O terceiro caso exibe a aplicação do método no domínio de e-commerce, considerado mais comum para a utilização de persistência poliglota e bancos de dados NoSQL, conforme descrito na Seção 3. Para prover maior uniformidade na descrição dos modelos, foram realizadas conversões em todos os modelos propostos nos casos de testes para a notação de Peter Chen. Além disso, adaptações como a tradução para a língua portuguesa e remoção de atributos desnecessários foram realizadas para possibilitar uma melhor apresentação das regras que serão descritas em cada caso de teste.
Este capítulo está dividido da seguinte maneira: as Seções 5.1, 5.2 e 5.3 descrevem a aplicação do PDDM nos três casos de testes propostos. A Seção 5.4 apresenta as dificuldades encontradas na aplicação do método nos casos de teste e a Seção 5.5 contém as considerações do capítulo.