Nessa aula vamos aplicar tudo que já aprendermos até então em um projeto completo de um cenário bastante comum: Um sistema de streaming de música, com assinatura. Criaremos a modelagem conceitual, lógica e os scripts para implementação no SGBD, além de inserções de dados arbitrários e algumas seleções.
DEFINIÇÃO DO ESCOPO E MODELAGEM CONCEITUAL
Para praticarmos tudo que já aprendemos até então vamos criar um projeto de um banco de dados completo (do levantamento de requisitos à modelagem física) de um sistema de streaming de música com assinatura usuários. Esta modelagem é parte de um cenário real e nesta sessão vamos definir o escopo do contexto, além de apresentar as etapas da modelagem conceitual.
Vamos começar pelo item principal do sistema: A música, que possui um título, uma duração, o ano em que foi gravada, a letra, o arquivo de áudio e um estilo (Jazz, Rock, Samba etc.). Cada música pertence à um artista e possui, também, uma série de TAGs associadas, que podem ser usadas para buscas (exemplo: “músicas dos anos 60”, “músicas de ninar” etc.). A música pertence à um artista. Cada artista possui um nome, uma bibliografia e um país de origem. Cada artista possui um ou mais álbuns e cada álbum possui um título, um ano de lançamento e uma gravadora. Lembre-se que o álbum é um container de músicas.
Com essa descrição já temos subsídios suficientes para criar a modelagem conceitual desta parte do projeto, que pode ser vista na figura 1. Repare cuidadosamente as cardinalidades de cada um dos relacionamentos, especialmente da música em relação ao álbum, que é dada por uma relação com entidade associativa incluindo-se o atributo “ordem” que define qual a ordenação da música em determinado álbum. É importante salientar que neste modelo a música pertence ao artista e o álbum, sendo um contêiner de músicas, relaciona-se única e exclusivamente com a música, pois imagine um álbum de vários artistas com músicas diferentes. Por isso, o álbum não é necessariamente do artista, nesta modelagem. De qualquer maneira, com um álbum, pode0se obter qual (ou quais) artistas compõe aquela coleção.
Após compreendido o sistema de armazenamento das músicas, podemos partir para o sistema dos usuários. Bom, o usuário possui um plano onde pode criar dois tipos de conta: Conta individual (valor X) ou conta família (valor X + 40%). Na conta família o usuário possui um ou mais dependentes, até 10. Lembre-se que cada dependente também é usuário do sistema. O plano possui uma vigência de renovação (30 dias, por exemplo) e é preciso armazenar o histórico de cobranças dos usuários (com os 4 últimos dígitos do cartão usado para cobrar). Os usuários ingressam no sistema por um e-mail e senha, mas podem colocar uma foto de perfil, seu nome ou apelido e dados para a cobrança automática no cartão.
Dito isso, podemos realizar a modelagem conceitual desta etapa, vista na figura 2. É muito importante entender bem essa parte pois há um processo de validação do pagamento que deverá ser feito pelo sistema baseado no modelo de dados que estamos apresentando.
Finalmente os modelos se unem considerando que o usuário autenticado e com um plano válido (em vigência) pode ouvir músicas. Isso é feito pela programação, pois o banco de dados não implementa regras de negócio. Lembre-se que o plano é validado pela diferença de dias entre a data atual e última cobrança do usuário. Se estiver dentro da vigência do plano, ele está com uma conta ativa. Entretanto o usuário também pode criar suas próprias listas de reprodução, com quantas músicas ele quiser e as listas podem ter nomes e as músicas devem ter a ordenação que o usuário informar (que inclusive pode ser alterada posteriormente). Baseado nisso, a figura 3 mostra a união das duas partes da modelagem conceitual, através da associação do usuário com a música, pela lista de reprodução.
Outro ponto a ser observado é que neste sistema apenas o cartão de crédito é considerado meio de pagamento, para facilitar a modelagem que já está suficientemente complexa para este exercício. Neste caso, após um pagamento ser efetuado no sistema (através do cartão de crédito do usuário), um novo registro deve ser incluído na entidade de cobrança. Este novo registro possui a data de pagamento e para validar se a conta do usuário está ativa, basta o software fazer a diferença de dias da data atual com a data do pagamento e subtrair da vigência de renovação do plano. Se o número for positivo, então a conta do usuário está ativa. Se for zero ou negativo, então uma nova cobrança deve ser gerada para aquele usuário. Lembre-se que usuários dependentes não possuem cobranças, apenas usuários responsáveis pela conta.
DERIVAÇÃO PARA A MODELAGEM LÓGICA
Utilizando as regras de derivação da modelagem conceitual (fig. 3) para a modelagem lógica, temos como resultado o diagrama conforme mostrado na figura 4, desenvolvida através do Oracle SQL Developer Data Modeler. Note cuidadosamente que essa derivação gerou algumas tabelas de relacionamento novas, especialmente onde há, na modelagem conceitual, a entidade associativa. Lembre-se que o atributo de uma entidade associativa se torna uma coluna na tabela de relacionamento como, por exemplo, o atributo que é capaz de identificar a ordem da música no álbum ou na lista de reprodução do usuário.
Repare também no autorelacionamento da tabela usuário que é um relacionamento não obrigatório. Cada conta de usuário, sendo uma conta familiar, poderá ter associada qual é a conta do usuário principal, que é de onde saem as cobranças do plano.
IMPLEMENTAÇÃO DA MODELAGEM FÍSICA
Após bem definidos os modelos conceituais e a modelagem lógica, podemos começar a executar a tão esperada modelagem física, gerando os scripts necessários para implementar este contexto, ou seja, os scripts da DDL do cenário em questão. O quadro abaixo mostra a criação das tabelas e respectivas restrições de integridade necessárias para implementação da modelagem lógica em questão.
