Nos módulos anteriores, introduzimos o conceito de bases de dados, discutimos os tipos de dados que armazenam, e praticamos o envio de pedidos REST API para recuperação de dados. Ao mesmo tempo, continuámos a ser um participante externo no processo e apenas solicitámos informações de várias fontes.

Está na hora de criar a sua base de dados! Neste módulo, faremos exactamente isso, compreenderemos como os dados são armazenados na base de dados e como podem ser interligados. Mas antes de mais, vamos começar com a teoria. Vamos lidar com a forma em que os dados nos chegam, bem como com as categorias em que as bases de dados estão divididas de acordo com a estrutura de dados.

Noções básicas de dados

Representação de dados

O líder absoluto na representação de dados no REST API é o formato JSON. Em todos os exemplos dos módulos anteriores, recebemos dados neste formato. Vale a pena recordar que REST não impõe restrições à escolha do formato para nós, no futuro certamente irá conhecer outros (por exemplo, XML). Ao mesmo tempo, devido ao seu peso reduzido e fácil legibilidade humana, os programadores preferem frequentemente o JSON.

JSON (JavaScript Object Notation) é um formato de intercâmbio de dados baseado em texto e baseado em JavaScript. E não deixe que o JavaScript no título o engane. O formato JSON, embora tenha origem nesta linguagem de programação, é completamente independente dele e pode ser utilizado em qualquer lugar.

Vamos ver em que consiste um objecto JSON e como é escrito.

Todos os dados que recebeu foram incluídos em braceletes encaracolados "{}". Eles são sempre colocados no início e no fim do objecto JSON.

O próprio objecto consiste num conjunto de registos, que são pares "Chave : Valor" e estão separados entre si por vírgulas ",".

A chave é o nome da entrada em si, entre aspas "". Exemplos: "nome", "valor", "região", "endereço". Pode ser qualquer palavra, o principal no desenvolvimento é certificar-se de que este significado é claro.

Os valores podem ser de vários tipos. Vamos considerá-los todos.

  1. Cordão. Contém informação de texto, um conjunto de caracteres no padrão Unicode. As cadeias de caracteres estão entre aspas "".
  2. Número de caracteres. Pode ser inteiro ou ponto flutuante. Está escrito tal como está, não é necessário incluir entre aspas.
  3. Booleano. Um de dois valores. Verdadeiro ou falso. Como um número, é escrito sem aspas.
  4. Array. Um conjunto ordenado de elementos. Cada elemento pode ser de qualquer tipo. Um conjunto é encerrado entre parênteses rectos "[]", e os seus elementos são separados por vírgulas.
  5. Objecto. O valor JSON pode ser outro objecto JSON. A ele aplicam-se as mesmas regras que ao objecto raiz. Está também encerrado em aparelho de caracóis e contém o seu próprio conjunto de registos.

Veja os dados recebidos nos primeiros módulos com esta informação em mente. Seleccione os componentes do JSON, determine a que tipo pertencem os valores recebidos.

Armazenamento de dados

Já lidámos com o JSON. Agora passamos para o essencial - bases de dados. Os dados podem ser armazenados nelas de várias maneiras. Ao mesmo tempo, desenvolveu-se historicamente para que o modelo de base de dados relacional tenha recebido a maior distribuição.

Ao utilizar o modelo relacional, os dados são armazenados sob a forma de tabelas, com um conjunto específico de dados, cuja estrutura é rigidamente especificada na fase de concepção da base de dados. A descrição de uma estrutura de dados em bases de dados relacionais é chamada esquema. Define a composição das tabelas, a estrutura dos campos destas tabelas, assim como as relações entre elas.

O SGBD utiliza a linguagem SQL para gerir os dados com um modelo relacional.

SQL - Linguagem de Consulta Estruturada. Esta é uma linguagem declarativa, o que significa que os seus comandos descrevem apenas a acção necessária (encontrar dados, apagá-los, alterá-los), e cada SGBD decide por si como executá-los.

Existem muitos SGBD relacionais diferentes. Entre os mais comuns estão Oracle, MySQL, MS SQL, PostgreSQL. A propósito, AppMaster utiliza PostgreSQL, o que significa que utiliza um SGBD avançado moderno que funciona num grande número de organizações diferentes e é também software gratuito (ou seja, não precisa de pagar dinheiro extra pela sua utilização).

Já reparou na presença da abreviatura SQL em quase todos os nomes de SGBD? Na verdade, um nome alternativo para uma base de dados relacional é uma base de dados SQL.

No entanto, existe uma abordagem alternativa. Bases de dados não relacionais, ou NoSQL. Vale a pena notar que Não neste caso não é uma negação de "não", mas uma abreviatura para Não só. Ou seja, "Não só SQL".

Os SGBD não-relacionais não utilizam um formato de consulta comum (como SQL), cada um deles implementa a sua própria forma de trabalhar com dados.

Não requerem uma estrutura de armazenamento de dados definida de forma única. Os dados em si são armazenados neles não sob a forma de tabelas rigorosas, mas sob a forma de objectos com um conjunto arbitrário de atributos (muito semelhante ao JSON). Isto pode ser relevante quando se trabalha com dados cuja estrutura está sujeita a alterações frequentes.

Ao mesmo tempo, devido à sua estrutura livre, as soluções NoSQL são mais fáceis de escalar se for necessário criar uma base de dados distribuída em múltiplos servidores.

Exemplos de SGBD NoSQL incluem MongoDB e Redis.

Concepção da base de dados

É tempo de conceber a sua própria base de dados. Para o fazer, vá para o separador Data Designer (Designer de Dados) no painel esquerdo.

Os dados na base de dados são armazenados sob a forma de tabelas especiais (modelos). E pode reparar que já dispomos de um modelo. Faz parte do módulo de autorização e está incluído em cada projecto, por defeito. Graças a ele, novos utilizadores da aplicação são criados e os já existentes são geridos. Mas não nos debruçaremos agora sobre o seu estudo, mas criaremos o nosso próprio modelo.

Imagine que estamos a desenvolver um serviço de mapas. Vamos criar um modelo que contenha informação sobre os países. Para o criar, é necessário clicar com o botão direito do rato numa área vazia da tela e seleccionar Criar modelo vazio.

Para criar, precisamos apenas de especificar o nome do modelo. Trataremos da auto-geração de pontos finais e elementos de interface de utilizador em outros módulos do curso.

Por favor note que imediatamente após a criação, o modelo já contém 4 campos. Estes são campos de sistema, cuja presença simplifica grandemente a criação inicial e posterior utilização do modelo.

  1. ID (número inteiro) - Identificador único, chave primária. É criado automaticamente para cada nova entrada na tabela e destina-se a garantir que não haja duplicados. É por ID que se pode identificar de forma única um registo numa tabela. O seu valor começa em 1 e aumenta automaticamente em 1 para cada nova entrada.
  2. CreatedAt (data/hora) - A hora a que o registo foi criado na tabela.
  3. UpdatedAt (data/hora) - A hora a que a entrada foi modificada pela última vez.
  4. EliminadoEm (data/hora) - A hora a que a entrada foi eliminada. Naturalmente, apenas se foi utilizada a remoção suave. Ou seja, tal eliminação, quando o registo é apenas marcado como eliminado e filtrado por pedidos de acesso ao mesmo, mas ao mesmo tempo permanece fisicamente na tabela. Isto é diferente do apagamento em massa, que na realidade apaga os dados por completo.

Para além dos do sistema, seria sensato acrescentar campos personalizados ao modelo criado. Suponhamos que queremos ver o nome do país e alguma descrição com informação sobre o mesmo.

A escolha de um tipo de campo não deve ser um problema. Para o nome, String é adequado, e para a descrição informativa, Texto.


Além disso, estão disponíveis mais quatro interruptores:

  1. Valores múltiplos (Array) - Usar arrays em vez de entradas únicas.
  2. Não nulo - o campo especificado não pode estar vazio, deve conter sempre dados.
  3. Único - o valor do campo deve ser único, neste modelo não pode haver dois registos cujos valores deste campo sejam os mesmos.
  4. Index - indica que será criado um índice especial para este campo, a fim de acelerar a pesquisa.

Em geral, só é correcto verificar as marcas se for realmente necessário. Por exemplo, poderíamos marcar Not null e Unique para nomes de países, assumindo que não pode haver um país sem um nome, ou dois países com o mesmo nome. No entanto, é uma boa ideia controlar isto na fase de criação da lógica da aplicação, e não colocar restrições à própria base de dados.

Da mesma forma, criar uma tabela com informações sobre as cidades. Pense em que campos de dados pode conter, que tipo são esses campos.

Os dados da base de dados não existem por si sós, sob a forma de tabelas dispersas. Estão relacionados uns com os outros de certa forma. A chave para desenvolver um modelo de dados é definir estas relações e construir relações.

Para estabelecer tais relações, é necessário traçar uma linha com o rato desde a fronteira de um modelo até ao outro. No nosso exemplo, sabemos com certeza que cada cidade está localizada em algum país, pelo que podemos criar uma ligação de país para cidade.


Existem 3 tipos diferentes de ligações:

  1. Um para um (tem um). Cada registo na tabela é mapeado para um registo da tabela associada (o mesmo se aplica ao inverso). Um exemplo simples é uma pessoa e o seu passaporte. Podemos sempre ter a certeza de que esta ligação é única. Um passaporte só pode ter um titular, e cada pessoa só pode ter um passaporte válido.
  2. Um-para-muitos (tem muitos). Cada registo de uma tabela pode ter muitos registos noutra tabela. A nossa base de dados é um exemplo semelhante. Um país pode ter muitas cidades diferentes, mas cada cidade pode pertencer apenas a um país. Esta é a ligação que iremos fazer.
  3. Muitas a muitas. Uma relação na qual vários registos de uma tabela podem corresponder a vários registos de outra. Um exemplo simples é a relação entre professores e alunos. Cada professor pode ensinar muitos estudantes, tal como cada estudante pode aprender com muitos professores diferentes.

Trabalho de casa

Imagine que tem de desenvolver uma aplicação para uma loja online. Criar um modelo de base de dados para que funcione.

  • É necessário prever a disponibilidade de bens com cartões da sua descrição, várias categorias de bens, informações sobre encomendas e sobre clientes.
  • Povoar as tabelas com campos de vários tipos (utilizar pelo menos 5 tipos).
  • Estabelecer relações entre as tabelas. Utilizar os 3 tipos de ligações.