Agora sim, temos as definições fundamentais e importantes para conseguirmos observar um modelo de dados relacional. Eu quero comentar com você um modelo de dados muito conhecido, muito clássico, que é o modelo Northwind. Este modelo acompanha o SQL Server, acompanha Access também, nos materiais da Microsoft. Especificamente aqui eu estou trazendo a versão 2.0 deste modelo de dados. Primeiro ponto para comentar e para prestarmos atenção. Na prática, nós vamos ver modelos que, mesmo tratando de assuntos simples, como é o objetivo da base Northwind, que é uma base de aprendizagem, nós já vamos perceber que o simples visualmente já fica complexo. Nós estamos vendo aqui uma série de tabelas que estão representando uma empresa hipotética, chamada Northwind, e nós temos conceitos importantes de funcionários, de pedidos, de pedidos, linha de pedido, produtos, clientes, fornecedores, entregadores. E na prática, quando nós nos depararmos nos projetos, no nosso trabalho, nós observaremos que os CRMs e os ERPs, que estão baseados em modelos de dados relacionais, e predominam com bancos relacionais, principalmente aqui no Brasil, nós veremos que os modelos de dados relacionais serão, com certeza, muito mais complexos do que esse que eu estou trazendo aqui na tela. Mas, não se desespere, deixa eu fazer com você agora alguns comentários sobre porções específicas desse modelo, que você ficará capacitado para ler e para compreender qualquer modelo de dados relacional que você encontrar daqui para frente. Primeiramente, vamos olhar um conceito importante que é produto. Então, para nós entendermos produto do ponto de vista conceitual, as empresas vendem produtos e estes produtos terão uma série de atributos que caracterizam, que descrevem este produto. Então aqui nós temos um produto sendo armazenado em três tabelas principais relacionadas entre si. Vamos começar com a tabela do meio, produtos. Temos o identificador deste produto, que é o Product ID, que é uma chave artificial utilizada pelo banco de dados. Frequentemente essa chave é um número inteiro sequencial, então no seu trabalho, nos seus códigos que você encontrar para dar manutenção, você vai encontrar sequences no seu banco de dados. Independente de ser Oracle ou SQL Server, este número inteiro, sequencial, no seu código é uma sequence. Aí nós também temos o Product Code, que é o código do produto. Aqui é um código funcional, um código do ponto de vista de negócio. Funcional, um código do ponto de vista de negócio. Depois nós temos o nome do produto, descrição, o custo unitário padrão, custo unitário, custo alto, quantidade, se está descontinuado. Então, uma série de atributos e também metadados, como por exemplo, quando este registro foi adicionado, que é o added on, e também por quem foi adicionado, que é o added by. E a mesma coisa para modificação, quando foi modificado e por quem foi modificado. Mas além disso, nós sabemos que no mundo dos negócios, os produtos estão catalogados de alguma maneira, ou seja, possuem categorias. Então, a tabela à esquerda é a categoria de produto, Product Categories, e vai seguir o mesmo raciocínio da aplicação que nós vimos até agora, da primeira forma normal, segunda forma normal e terceira forma normal. Então, nós temos o identificador, que é um sequencial inteiro, nós temos o nome dessa categoria, um código, uma descrição, imagem dessa categoria e os mesmos metadados de controle, quando e quem acionou essa categoria e quando e quem modificou esta categoria. Destaque também para a notação é desta linha entre produto e categoria. Então nós vamos fazer uma leitura da esquerda para a direita que uma categoria de produto possui muitos produtos. Se nós fizermos a leitura da direita para a esquerda, muitos produtos possuem uma categoria de produto. E da mesma forma, na tabela mais à direita, nós temos os for três formas normais aplicadas aqui. Nós temos uma chave identificadora sequencial inteira. Nós temos o código deste produto, Product ID, que é a chave estrangeira para o produto. que é a chave estrangeira para o produto temos o identificador do fornecedor e ali o vendor ID é uma companhia então uma companhia, uma empresa como papel de fornecedor de produto então ali nós temos aqui é até interessante lendo aqui em voz alta com vocês nós vamos perceber que, na verdade, o Product Vendors representa o relacionamento de muitas empresas, muitas companhias, entregando, fornecendo muitos produtos. Em relacional, quando nós aplicamos as três formas normais, nós temos um relacionamento de muitos para muitos, sendo implementado com uma tabela intermediária, que aqui virou a tabela de Product Vendors, o fornecedor deste produto. E para complementar aqui o meu comentário, da mesma forma nós temos ali os quatro atributos de controle de metadados, quando foi adicionado, por quem foi adicionado e quando e quem modificou esse atributo. análise sobre pedidos. Aqui nós temos uma representação também de pedidos, muito comum da gente encontrar em diferentes RPs, diferentes aplicações. Então vamos começar com a tabela mais à direita, Orders, que é a tabela de pedido. Geralmente, pedido também vai ser chamado de cabeçalho do pedido. Então, imagina uma nota fiscal, e nessa nota fiscal, o cabeçalho nós temos o identificador do cliente, endereço, seu CNPJ ou CPF. E mais para baixo na nota fiscal, nós temos a relação dos produtos. Então, essa relação de produtos é o order details, ou detalhe da ordem, detalhe do pedido, e também frequentemente implementado como linha de pedido. E essa linha de pedido também vai ter um status, se já foi pago, se já foi separado no estoque, se já foi enviado para entrega. Pago, se já foi separado no estoque, se já foi enviado para entrega. Então, aqui nós temos, mais uma vez, a aplicação das três formas normais para o conceito de pedido. Então, pedido, do ponto de vista de negócio, é o ato de solicitar comprar os produtos. E, num pedido, nós podemos ter vários produtos sendo comprados. E num pedido nós podemos ter vários produtos sendo comprados. E quando a gente compra vários produtos, esses produtos serão despachados, cada um em algum momento. Isso é muito comum hoje nos principais e-commerce, nos seus principais aplicativos de compra. Não necessariamente você recebe tudo junto, são processados de maneira paralela, assíncrona. Então por isso que a gente tem aqui essa tabela também de status da linha do pedido. Vamos aqui fazer a leitura dos relacionamentos. Um pedido, ou seja, uma order, tem muitos detalhes de pedido. Muitas order details. E muitas order details vão ter um status, aquele status que eu comentei, se já foi entregue, se está em separação, se já teve pagamento realizado. E vamos fazer aqui também mais uma leitura, mais uma análise da tabela de funcionário, tabela employees. Nessa modelagem, nós vamos observar que o conceito de funcionário, que o funcionário tem o seu identificador, primeiro e último nome, tem um cargo, que aqui é o title, job title, e também tem privilégios dentro da organização. e também tem privilégios dentro da organização. Então, a gente vai perceber esses conceitos sendo distribuídos em quatro tabelas principais. Então, um cargo tem muitos funcionários, ou muitos funcionários terão um cargo, o employee em relação a title. em relação a title. Da mesma forma, nós vamos ver que um privilégio, uma permissão, faz parte de muitos conjuntos de privilégios e um funcionário tem muitos privilégios. Então, aqui um relacionamento muitos para muitos. Muitos funcionários terão muitos privilégios. Surge essa tabela intermediária, que é o employee privileges, ou seja, os privilégios deste funcionário, para modelar em relacional, obedecendo as três formas normais, um relacionamento de negócios muitos para muitos.