Agora que passamos formalmente pelos tipos mais comuns de database constraints, isto é, as restrições de bancos de dados, eu quero trazer para você alguns comentários sobre este conteúdo. Vamos lá! Primeiro, recomendo muito, recomendo fortemente que você fique atento às documentações específicas do banco de dados com o qual você estiver trabalhando. Agora, você já está capacitado para entender e compreender que existem regras ou limitações ou restrições de bancos de dados, que são os database constraints, que trarão comportamentos aos dados inseridos, atualizados e manipulados nas tabelas, e cada banco de dados faz isso de uma maneira mais ou menos padrão, que são esses tipos mais comuns que nós comentamos, mas existem implementações específicas. Então, por exemplo, aqui eu trouxe um trecho da documentação do banco de dados Oracle da versão 23c, onde nós podemos ver os tipos de Constraints. Então, nós temos o Check, o Primary Key, Unique Key, Referential Integrity Aqui nós vamos começar A associar Com o conceito do Foreign Key E outras opções que Aparecem de maneira de implementação específica O View Que é o Check Sobre uma View A letra O, o Hash Expression E por aí vai Então o ponto aqui não é trazer um aprofundamento de banco Oracle, e sim que você fique atento a esse tipo de documentação para você trabalhar com muito mais tranquilidade com o seu banco de escolha do seu projeto. Então, ficar atento às documentações específicas é meu primeiro comentário minha primeira recomendação para você se você não faz isso daqui pra frente passe a consultar as documentações se você já consulta as documentações continue assim segundo comentário falei bastante de database constraints e sempre mencionei banco de dados relacionais, porque este é um conceito muito forte deste tipo de tecnologia. Porém, é importante comentar o seguinte, em NoSQL nós também vamos encontrar técnicas para integridade. Então, é muito importante nós já começarmos a ter em mente que esquema flexível de dados não significa desgovernança e não significa obrigatoriamente inconsistência ou falta de integridade. Essas coisas vão acontecer se nós não nos prepararmos nos projetos para esse tipo de situação. Então aqui eu trouxe também um exemplo da documentação específica do MongoDB para possibilidades ou métodos de trabalho para tratar integridade. Então temos em MongoDB três métodos principais. As transações, para trabalhar com múltiplas coleções que estão tendo seus documentos atualizados, então aquela característica atômica que existe no documento passa a acontecer na transação, da maneira como a gente está acostumado a trabalhar num relacional. Documentos embarcados, que é algo que não existe no relacional. Então, por exemplo, o pedido, no mesmo documento de pedido, você coloca o detalhe deste pedido. Você continua fazendo aquele relacionamento de um pedido para muitos itens de pedido. Exatamente como nós vimos na aula de Foreign Key. A diferença é que no caso do MongoDBDB com a modelagem de dados documental, você implementa este relacionamento de um para muitos entre pedido e item de pedido pelo método de documento embarcado. Ou seja, você vai ter um atributo array com uma série de objetos que serão os detalhes daquele pedido. com uma série de objetos que serão os detalhes daquele pedido. Terceira técnica que a gente tem disponível em MongoDB Atlas são as triggers, então os gatilhos. Nós também encontramos este conceito em bancos de dados relacionais e os gatilhos dos relacionais geralmente estão relacionados a gatilhos de dados, de manipulação dos dados. No Atlas, você vai encontrar essa mesma possibilidade de eventos dispararem ações sobre os dados em suas coleções, mas também podem acontecer outras ações sobre outros serviços da plataforma. Então, por exemplo, com uma trigger, você pode desencadear um comando de pausar o seu cluster. Imagina que você quer ter um cronograma de que, após as 20 horas, ninguém trabalha. Então, você pausa o seu cluster de desenvolvimento e só volta a ligar ele às 8 da manhã do dia seguinte. Caso você queira ter esse tipo de comportamento, uma trigger também faz isso. Então, aqui a gente vê o conceito de trigger já expandido em relação ao que nós encontramos nos bancos de dados relacionais. Falando um pouquinho também de validação do esquema. de validação do esquema. Então, não é porque não existe um nome exato de database constraint em MongoDB ou em Cassandra ou em qualquer banco NoSQL que você esteja trabalhando no seu projeto, que o seu modelo de dados não será validado, ou seja, que você não conseguirá colocar nenhum tipo de restrição sobre este modelo. Na verdade, isso é muito possível e muito comum. Então, olha só esse trecho que nós temos aqui. Aqui nós estamos numa coleção de estudantes trazendo uma validação. Então, essa validação dessa entidade, desse objeto estudante da nossa aplicação, nos traz como campos obrigatórios. O local, o curso, o nome e o ano. E adicionalmente para o nome, o nome é uma string, ou seja, são caracteres alfanuméricos, na verdade, muito mais não numéricos e sim caracteres. Mas aqui eu tenho essa regra que não vai me deixar colocar nenhum outro tipo que não seja string neste campo. Da mesma forma, no ano, nós estamos colocando ali como inteiro e o inteiro tem um tamanho mínimo de 2017 e um máximo de 3017. Então, eu estou preparando minha coleção para ser viável, ser trabalhada durante mil anos. Está aqui. Então, o ano passa a ser obrigatório, porque está na propriedade required, e também é um numérico que não pode ser menor de 2.017, nem maior do que 3.017. Então, com isso, nós também temos uma validação do nosso esquema. Então, em MongoDB e em outros NoSQL, nós não vamos falar Database Constraint para esse tipo de regra de dados. Nós vamos falar sempre de Schema Validation ou validação do esquema JSON. Vamos falar um pouquinho também de validação de esquema grafo e aqui um exemplo de Neo4j. Então, Neo4j é um NoSQL que trabalha com grafos, que é uma técnica de modelagem de persistência de dados que você traz o destaque para o relacionamento das entidades. E é muito comum em redes sociais e também em mecanismos sofisticados de antifraude. Então, aqui nós temos também validações sendo aplicadas. Então, a pessoa vai ter o seu nome do tipo string e essa string vai ter um padrão, que é este pattern. E ali nós somente vamos ter caracteres. Vocês viram que eu me enrolei ali na hora de falar da validação do estudante, que eu falei alfanumérico, mas o nome não tem número. Então, aqui com este pattern, estamos garantindo que esta string somente tem caracteres e não terão números. Também temos aqui que o nome somente tem um, então a pessoa somente tem um único nome, então MaxCount1, e também estamos trazendo outros detalhes para o relacionamento. Então, aquele Acted In é o relacionamento e é onde essa pessoa está inserida nesse relacionamento. Então, também é possível fazer isso em outros NOS-TIC. Então, aqui temos um exemplo de Neo4j. DynamoDB também podemos ter definição do nosso esquema de dados. Nós vamos encontrar com frequência na documentação da AWS que o DynamoDB é esquimaless, sem esquema. Porém, a gente precisa e deve obrigatoriamente informar chaves de partição e chaves de ordenação nesse tipo de modelagem. Então, aqui nós estamos fazendo exatamente isso. É uma tabela de músicas, as músicas tem um artista e tem um nome, a canção tem um título e aqui nós estamos dizendo que por artista essa tabela será paticionada, ou seja, a tabela é dividida por artistas e ela será ordenada pelos títulos. Então, é isso que nós estamos trazendo aqui como definições. Logo em seguida, também estamos definindo também artista e canção, título da música, como atributo do tipo S, do tipo string. E mais abaixo, finalzinho ali, outros detalhes, curiosidades, provisionamento de throughput caso você esteja usando o modo provisionado de DynamoDB. Cassandra, aqui nós estamos fazendo criação de um key space e aqui nós temos uma criação de tabela. É interessante também que estamos definindo este modelo. Então, diferentemente do que a gente acabou de ver no DynamoDB, que tem essa questão do schema list, ou até mesmo de MongoDB, que você também não precisa previamente definir os atributos, aqui com a Castana nós estamos fazendo uma definição prévia. Então aqui nós temos rua como texto, cidade como texto, a província como texto, código postal texto, basicamente um cadastro de endereço totalmente textual. E aqui nós temos na verdade reservas. A nossa tabela reserva, então vai ter um número de confirmação, um caso particular de NoSQL que tem uma modelagem de dados bastante interessante e bastante desafiadora em alguns momentos também.