Banco de Dados NoSQL - Modelos sem Esquema, JSON e MongoDB Atlas

Banco de Dados Prof Daniel Callegari Aula 09 Aula 09 Modelos sem esquemas prévios Formatos de dados ex JSON Prática com MongoDB Atlas Dinâmicas O que você vai aprender nessa aula Parte 1 Modelos sem esquemas prévios Parte 2 Formatos de dados Parte 3 JSON e BSON Parte 4 Prática com MongoDB Atlas Parte 5 Dinâmica Aula 9 Parte 1 Modelos sem esquemas prévios Mecanismos de armazenamento e recuperação de dados modelados de uma forma nãotabular Sistemas Gerenciados de BDs NoSQL Aula 9 Parte 2 Formatos de dados Arquivos binários padronizados ou proprietários Arquivos texto CSV XML JSON Aula 9 Parte 3 JSON e BSON Formato textual Formato binário Aula 9 Parte 4 Prática com MongoDB Atlas wwwmongodbcom Aula 9 Parte 5 Dinâmica Prática com modelos de dados sem esquemas prévios O que você vai precisar para acompanhar essa aula livesqloraclecom wwwmongodbcom O que você vai aprender nessa aula Parte 1 Modelos sem esquemas prévios Parte 2 Formatos de dados Parte 3 JSON e BSON Parte 4 Prática com MongoDB Atlas Parte 5 Dinâmica Modelagem de Dados Modelagem de dados é um processo que envolve a análise de requisitos informacionais a definição e a implantação de estruturas de dados para suportar as necessidades de negócio de uma organização Modelagem de Dados Existem diversos modelos de dados possíveis por exemplo Relacional já vimos Orientado a objetos Objetorelacional Hierárquico em Rede Modelos sem esquemas prévios foco desta aula Modelos analíticos veremos na nossa última aula Modelos sem esquemas prévios Modelos sem esquema schemaless ou schemafree Os respectivos SBGDs possuem um mecanismo de armazenamento e recuperação de dados modelados de uma forma nãotabular 1960 Navegação em Dados 1970 SBGDs Relacionais e a Linguagem SQL 1980 SBGDs para desktops 1990 SBGDs Orientados a Objetos 2000 NoSQL e NewSQL Origens 1970 Codd Relational RDBMS 2000 No SQL para apps em que o modelo relacional é inadequado ou ineficiente Dados semiestruturados grafos redes sociais dados cartográficos dados de genomas etc exigem Modelos e Sistemas específicos Mas pq Modelo Relacional se manteve Base sólida álgebra relacional Codd formato tabular é mais natural linguagem SQL vs PERFORMANCE mantendo consistência Origens Mas 2000 Coleta massiva de dados formatos muito distintos NoSQL Origem do termo A primeira ocorrência do termo data de 1998 Ironicamente era um BD Relacional que nada tinha a ver com o Movimento NoSQL recente NoSQL A Relational Database Management System httpwwwstrozziitcgibinCSAtw7IenUSnosqlHome20Page NoSQL is a fast portable relational database management system without arbitrary limits other than memory and processor speed that runs under and interacts with the UNIX1 Operating System It uses the Operator Stream Paradigm described in Unix Review March 1991 page 24 entitled A 4GL Language There are a number of operators that each perform a unique function on the data The stream is supplied by the UNIX InputOutput redirection mechanism Therefore each operator processes some data and then passes it along to the next operator via the UNIX pipe function This is very efficient as UNIX pipes are implemented in memory NoSQL is compliant with the Relational Model NoSQL Origem do termo O termo NoSQL foi reintroduzido novamente em 2009 por um grupo de SBGDs nãorelacionais Portanto não há um primeiro BD NoSQL Boost Web 20 Facebook Google Amazon É interessante saber contudo que mesmo antes do paradigma relacional já existiam soluções que hoje poderiam ser classificadas como NoSQL Este é o caso do MUMPS 1966 que armazenava dados utilizando pares chave valor cada valor era um documento NoSQL Modelo schemaless ou schemafree ou seja um mecanismo de armazenamento e recuperação de dados modelados de uma forma nãotabular httpnosqldatabaseorg NoSQL DEFINITION sempre sendo revisada Next Generation Databases mostly addressing some of the points being nonrelational distributed opensource and horizontally scalable A lista hoje conta com mais de 225 SGBDs NoSQL NoSQL Características Ausência de esquema ou esquema flexível Suporte a replicação API simples Nem sempre é consistente Escalabilidade horizontal Número de máquinas pode aumentar Inviável no modelo relacional devido à concorrência NoSQL Características Poucas operações suportadas nativamente Atualizações sobre 1 elemento por vez Filtros agregações agrupamentos MapReduce Não possui JOINs data denormalization Não há o conceito de transações Podem ter uma linguagem parecida com SQL NoSQL Tipos Com eventuais sobreposições Tipo COLUNA ex Cassandra Tipo DOCUMENTO ex MongoDB Tipo CHAVEVALOR ex Couchbase Tipo GRAFO ex OrientDB Tipo MULTIMODELOS ex ArangoDB Modelo de Dados Flexível Documentos flexíveis estilo JSON Facilita a persistência e a combinação de dados de qualquer natureza Modelo do documento é mapeado para os objetos no código da aplicação É possível modificar dinamicamente o esquema enquanto executa sem downtime Distribuído Elevada disponibilidade Elevada escalabilidade Exemplo Modelo para um Blog Em vez de TABELAS para Categorias Tags Usuários Comentários Artigos temos duas COLEÇÕES Usuários Artigos Reduzem a necessidade de realizar junções JOINs Exemplo Fichas de um paciente SBGD SuperMed ltda Noono non nonn nonon Nno oonono nnoon Modelo de dados Relacional Modelo Relacional SELECTs JOIN JOIN JOIN SuperMed ltda Noono non nonn nonon Nno oonono nnoon Modelo de dados NãoRelacional Modelo NãoRelacional SuperMed ltda Noono non nonn nonon Nno oonono nnoon FICHA MEDICO EXAME A EXAME B FICHA MEDICO EXAME A EXAME B EXAME C PACIENTE Modelo de dados NãoRelacional Modelo NãoRelacional SuperMed ltda Noono non nonn nonon Nno oonono nnoon findOne Resumo do que vimos até agora Existem vários modelos de dados nãorelacionais ou sem esquemas prévios NoSQL é indicado para aplicações que lidam com grande volume de dados exigem alto desempenho nas consultas e escritas exigem escalabilidade horizontal NoSQL não veio para substituir o modelo relacional Banco de Dados Prof Daniel Callegari Aula 09 Relembrando o conteúdo do vídeo anterior Existem vários modelos de dados nãorelacionais ou sem esquemas prévios NoSQL é indicado para aplicações que lidam com grande volume de dados exigem alto desempenho nas consultas e escritas exigem escalabilidade horizontal NoSQL não substitui o modelo relacional O que você vai aprender nessa aula Parte 1 Modelos sem esquemas prévios Parte 2 Formatos de dados Parte 3 JSON e BSON Parte 4 Prática com MongoDB Atlas Parte 5 Dinâmica Formatos de Dados Podemos armazenar dados de diversas maneiras Arquivos binários Bancos de dados relacionais formatos proprietários Bancos de dados nãorelacionais BSON Arquivos texto Arquivo de dados tabulares separados por vírgulas CSV Arquivo de objetos aninhados representados em texto formato XML Arquivo de objetos aninhados representados em texto formato JSON Formatos de Dados Textuais Valores separados por vírgula Origem do nome CommaSeparated Values Extensão CSV Formato tabular linhas e colunas codigonomecpfdatanascsexoemail 1Juliana Pires4928122550604101962Fjupiresemailcom 2Maria Souza4963882647916111952Fmariaemailcom Formatos de Dados Textuais Objetos representados em linguagem de marcação extensível Origem do nome eXtensible Markup Language Extensão XML Formato objetos aninhados em TAGs etiquetas PACIENTE codigo1codigo nomeJuliana Piresnome cpf49281225506cpf datanasc dia4 mes10 ano1962 sexoFsexo emailjupiresemailcomemail PACIENTE Formatos de Dados Textuais Objetos representados em linguagem de objetos Javascript Origem do nome JavaScript Object Notation Extensão JSON Formato objetos aninhados em sintaxe Javascript codigo 1 nome Juliana Pires cpf 49281225506 datanasc dia 4 mes 10 ano 1962 sexo F email jupiresemailcom Formatos de Dados Comparativo codigonomecpfdatanascsexoemail 1Juliana Pires4928122550604101962Fjupiresemailcom 2Maria Souza4963882647916111952Fmariaemailcom PACIENTE codigo1codigo nomeJuliana Piresnome cpf49281225506cpf datanasc dia4 mes10 ano1962 sexoFsexo emailjupiresemailcomemail PACIENTE codigo 1 nome Juliana Pires cpf 49281225506 datanasc dia 4 mes 10 ano 1962 sexo F email jupiresemailcom codigo 2 nome Maria Souza pacientescsv pacientesxml pacientesjson Dinâmica A partir do nosso banco de dados relacional do Estudo de Caso Oracle LiveSQL Representar todos os dados disponíveis sobre os Médicos crm nome e nome da especialidade Formato XML Formato JSON Extrair os dados do Oracle LiveSQL com um SELECT e produzir manualmente os arquivos solicitados Para Saber Mais Formato JSON httpswwwjsonorgjsonpthtml httpsjsoncheckercom Formato BSON httpswwwmongodbcomjsonandbson httpsbsonspecorg Resumo do que vimos até agora Podemos armazenar dados de diversas maneiras Em especial utilizando os formatos CSV XML JSON Banco de Dados Prof Daniel Callegari Aula 09 Relembrando o conteúdo do vídeo anterior Podemos armazenar dados de diversas maneiras Em especial os arquivos de texto CSV XML JSON O que você vai aprender nessa aula Parte 1 Modelos sem esquemas prévios Parte 2 Formatos de dados Parte 3 JSON e BSON Parte 4 Prática com MongoDB Atlas Parte 5 Dinâmica JSON JavaScript Object Notation JSON é um formato leve para troca de dados Para seres humanos é fácil de ler e escrever Para máquinas é fácil de interpretar e gerar Formato textual e completamente independente de linguagem Atenção por padrão não há verificação para os tipos dos atributos É constituído de duas estruturas Uma coleção de pares nomevalor Em várias linguagens isto é caracterizado como um object record struct dicionário hash table keyed list ou arrays associativos Uma lista ordenada de valores Na maioria das linguagens isto é caracterizado como um array vetor lista ou sequência Fonte wwwjsonorg Sintaxe JSON titulo Bancos de Dados pgs 287 autores Azriel Daniel disponivel true editora nome EDIPUCRS email edipucrspucrsbr livrojson BSON Binary JSON BSON significa Binary JSON A estrutura binária do BSON codifica as informações de tipo e comprimento o que permite que ela seja percorrida muito mais rapidamente em comparação com o JSON O BSON adiciona alguns tipos de dados não nativos de JSON como datas e dados binários sem os quais o MongoDB teria perdido valiosas capacidades Fonte wwwmongodbcomjsonandbson BSON Binary JSON Fonte wwwmongodbcomjsonandbson Um BD sem esquema prévio Em um banco de dados sem esquema prévio não estamos presos a um formato tabular linhas e colunas com tipos Assim podemos ter objetos com características diferentes em uma mesma coleção codigo 1 nome Juliana Pires cpf 49281225506 datanasc dia 4 mes 10 ano 1962 sexo F email jupiresemailcom codigo 2 nome Carlos Lemos Souza titeleitor 778192810 naturalde FlorianópolisSC sexo M email cls81emailcom cookies true codigo A9881 nome Ricardo sobrenome Neves telefones 5198980101 5497761203 sexo M email rinevesemailcom cookies SIM Dinâmica A partir do nosso banco de dados relacional do Estudo de Caso Oracle LiveSQL Representar todos os dados disponíveis da paciente Juliana Pires Formato XML Formato JSON Extrair os dados do Oracle LiveSQL com SELECT e produzir manualmente os arquivos solicitados Note que neste caso teremos objetos aninhados Próximo slide contém os dados das tabelas para referência visual Dinâmica CODPACIENTE NOME CPF DATANASC SEXO EMAIL 1 Juliana Pires 49281225506 04OCT62 F jupiresemailcom 2 Maria Souza 49638826479 16NOV52 F mariaemailcom 3 Jaques Lutti 378434613888 09AUG70 M jaquesemailcom 4 Carla do Santos 70719177871 13SEP84 F csantosemailcom 5 Raquel Gomes 25513392275 21JAN37 F raqgomesemailcom 6 Katia Fernandes 52616855089 21JUL38 F katia22emailcom 7 Marcelo Cunha 64271911445 19MAR75 M mcemailcom 8 Guilherme Alves 83773468423 27DEC98 M guial89emailcom 9 Marcio Perez 71317480210 03JUL94 M marciopemailcom 10 Lucas Florian 58795952268 30DEC85 M florianemailcom NROFICHA CODPACIENTE CRM DATAEXAME 1 1 38222 10SEP21 2 1 41685 12SEP21 3 2 38222 01OCT21 4 3 38222 12OCT21 5 4 10853 29OCT21 6 5 38222 30OCT21 7 6 38222 02NOV21 9 8 41685 10NOV21 10 9 29299 11NOV21 NROFICHA CODEXAME 1 1 1 6 2 1 5 2 6 3 7 7 8 9 2 9 3 9 4 10 9 CRM NOME ESPECIALIDADE 38222 Dra Dora Lima 7 29299 Dr Pedro Cunha 7 38393 Dr Juliano Costa 7 08841 Dr Mario Rui 4 39698 Dra Sara Lee 4 10853 Dra Jurema Pimentel 4 41685 Dr Roger Dutra 6 39741 Dra Paulo Lima 6 38477 Dra Samanta Apple 9 CODESPECIALIDADE NOME 1 Clínico Geral 2 Dermatologista 3 Ortopedista 4 Endocrinologista 5 Oftalmologista 6 Ginecologista 7 Cardiologista 8 Pediatra 9 Nutricionista CODEXAME SIGLAEXAME DESCRICAO VALOR PRAZODEENTREGA 1 HEMO Hemograma 50 2 2 COHDL Colesterol HDL 25 2 3 COLDL Colesterol LDL 25 2 4 TRIGL Triglicerídios 20 3 5 ACDUR Ácido Úrico 30 4 6 CREAT Creatinina 35 1 7 TGO Transaminase Oxalacética 27 4 8 TGP Transaminase Pirúvica 36 3 9 TSH Tireoestimulante 40 2 10 PSA Antígeno Prostático Específico 43 2 Resumo do que vimos até agora Podemos armazenar dados de diversas maneiras Compreensão mais detalhada do formato JSON Banco de Dados Prof Daniel Callegari Aula 09 Relembrando o conteúdo do vídeo anterior Podemos armazenar dados de diversas maneiras Em especial os arquivos de texto CSV XML JSON O que você vai aprender nessa aula Parte 1 Modelos sem esquemas prévios Parte 2 Formatos de dados Parte 3 JSON e BSON Parte 4 Prática com MongoDB Atlas Parte 5 Dinâmica Transações ACID em SGBDs relacionais ATOMICITY TRANSAÇÕES SÃO TUDO OU NADA CONSISTENCY DE UM ESTADO VÁLIDO PARA OUTRO ISOLATION PARA CONTROLE DE CONCORRÊNCIA DURABILITY RESULTADOS PERMANENTES APÓS COMMIT Conjunto de propriedades para transações de BD que garantem validade mesmo em caso de falhas e erros Teorema de Brewer CAP CONSISTENCY TODA LEITURA OBTÉM O DADOS MAIS RECENTE OU UM ERRO AVAILABILITY CADA REQUISIÇÃO RECEBE UMA RESPOSTA SEM ERRO MAS SEM GARANTIR QUE CONTENHA O DADO MAIS RECENTE PARTITION O SISTEMA CONTINUA OPERANDO MESMO COM EVENTUAIS DESCARTES OU ATRASOS DE MENSAGENS ENTRE OS NODOS DA REDE O Teorema CAP afirma que é impossível que o armazenamento distribuído de dados forneça simultaneamente mais de duas das três garantias acima Se quisermos garantir o Particionamento então deveremos optar por Consistência OU Disponibilidade Teorema de Brewer CAP Nenhum sistema distribuído está protegido contra falhas de rede portanto o particionamento geralmente deve ser suportado Na presença de partições são dadas duas opções consistência ou disponibilidade Ao escolher consistência em relação à disponibilidade o sistema retornará um erro ou um erro de timeout se informações específicas não puderem ser garantidamente atualizadas devido ao particionamento na rede Ao escolher disponibilidade sobre consistência o sistema sempre processará a consulta e tentará retornar a versão disponível mais recente da informação mesmo que não possa garantir que ela esteja atualizada devido ao particionamento NoSQL Características Grande parte dos data stores NoSQL comprometem a Consistência privilegiando Disponibilidade Particionamento e velocidade Em vez do CAP muitos SGBDs NoSQL implementam o conceito de consistência final postergada eventual consistency Mudanças são propagadas para todos os nodos mais tarde tipicamente em milissegundos o que pode gerar leituras de dados obsoletos stale data reads E algumas implementações podem ainda ocorrer escritas perdidas lost writes Dinâmica Preparar o ambiente no MongoDB Atlas MongoDB Atlas httpswwwmongodbcom 1 2 3 4 5 MongoDB Atlas Escolher o plano FREE Conferir Conferir Conferir Por fim clicar aqui poderá demorar MongoDB Atlas Digitar estudodecaso em username e escolher uma senha Depois clicar aqui poderá demorar Databases Coleções Dinâmica A partir do nosso banco de dados relacional do Estudo de Caso Oracle LiveSQL Representar todos os dados disponíveis da paciente Juliana Pires Formato XML Formato JSON Armazenar os dados JSON da paciente Juliana Pires no MongoDB Para Saber Mais Formato JSON httpswwwjsonorgjsonpthtml httpsjsoncheckercom MongoDB Atlas e BSON httpswwwmongodbcomjsonandbson httpswwwmongodbcomdocsmanualtutorialgettingstarted httpswwwmongodbcomdeveloperproductsmongodbcheatsheet httpswwwmongodbcomdocsmanualreferencesqlcomparison httpswwwmongodbcomdocsmanualreferencesqlaggregationcomparison Resumo do que vimos até agora Existem vários modelos de dados não relacionais ou sem esquemas prévios Podemos armazenar dados de diversas maneiras JSON é um formato importante para este propósito Banco de Dados Prof Daniel Callegari Aula 09 Relembrando o conteúdo do vídeo anterior Existem vários modelos de dados não relacionais ou sem esquemas prévios Podemos armazenar dados de diversas maneiras JSON é um formato importante para este propósito O que você vai aprender nessa aula Parte 1 Modelos sem esquemas prévios Parte 2 Formatos de dados Parte 3 JSON e BSON Parte 4 Prática com MongoDB Atlas Parte 5 Dinâmica Prática com o MongoDB Atlas 1 Pequena introdução à Modelagem e aos Relacionamentos entre coleções O campo especial id 2 Criação de coleções e inserção de documentos Pacientes Médicos Exames 3 Recuperação de documentos Find filter project sort Pequena introdução aos operadores do Aggregation Pipeline project sort 1 Projetando o Modelo de Dados Como já vimos no MongoDB podemos aninhar dados em um documento dados desnormalizados o que melhora o desempenho httpswwwmongodbcomdocsmanualcoredatamodeldesign Recomendado desnormalizado Possível normalizado vs Padrão embedded aninhado incorporado Normalizado sem aninhamentos documento de uma pessoa id af2e985fa nome Maria Souza documento de endereço de uma pessoa idpessoa af2e985fa referência à pessoa FK rua Av Ipiranga 6800 cidade Porto Alegre estado RS Embedded com aninhamento de documentos documento de uma pessoa e seu endereço id af2e985fa nome Maria Souza endereco rua Av Ipiranga 6800 cidade Porto Alegre estado RS repare que NÃO HÁ referência ao objetopai Relacionamentos 11 um para um Padrão embedded aninhado incorporado Normalizado sem aninhamentos documento de uma pessoa id af2e985fa nome Maria Souza documentos de endereços de uma mesma pessoa idpessoa af2e985fa referência à pessoa FK rua Av Ipiranga 6800 cidade Porto Alegre estado RS idpessoa af2e985fa referência à pessoa FK rua Av Borges de Medeiros 120 cidade Caxias do Sul estado RS Embedded com aninhamento de documentos documento de uma pessoa e seus endereços id af2e985fa nome Maria Souza enderecos rua Av Ipiranga 6800 cidade Porto Alegre estado RS rua Av Borges de Medeiros 120 cidade Caxias do Sul estado RS repare que NÃO HÁ referências ao objetopai repare que enderecos agora é um arranjo xy Relacionamentos 1N um para muitos 2 Coleções e Documentos O database clínica e sua coleção médicos crm 08841 medico Dr Mario Rui especialidade Endocrinologista 3 Recuperando documentos SELECT FROM MEDICOS SELECT crm nome FROM MEDICOS WHERE especialidade Endocrinologista ORDER BY nome Para Saber Mais SQL to MongoDB Mapping Chart httpswwwmongodbcomdocsmanualreferencesqlcomparison SQL to Aggregation Mapping Chart httpswwwmongodbcomdocsmanualreferencesqlaggregationcomparison Dinâmica A partir do nosso banco de dados relacional do Estudo de Caso Oracle LiveSQL Criar as coleções e os documentos no SBGD não relacional MongoDB Resumo do que vimos até agora Existem vários modelos de dados não relacionais ou sem esquemas prévios MongoDB é uma escolha popular Dados em JSONBSON Dados aninhados Escalabilidade