Modelo Relacional de Dados

Há muito tempo atrás, quando os dinossauros eram gigantes... quer dizer, em 1970, um cara chamado Edgar Codd decidiu que o caos nos dados já tinha passado do ponto do "bagunça criativa" e tava mais pra um buraco negro que suga tempo e recursos. Edgar pensou bastante e bolou um jeito de organizar tudo, e de quebra — criou a base de um mundo inteiro onde os dados ficam arrumadinhos em tabelas, tipo livros numa estante de biblioteca perfeita. Linhas, colunas, ordem — e nada de "tá bom assim" ou "ah, todo mundo entende".

O modelo relacional se baseia em representar dados como tabelas, onde cada tabela tem linhas e colunas. É bem intuitivo: linhas são registros, colunas são propriedades ou atributos do registro. Esse jeito facilita muito manipular e trabalhar com os dados.

Imagina que você faz um pedido numa loja online. Pra esse pedido ser processado e entregue, o sistema precisa considerar vários detalhes: quem é você (cliente), qual serviço de entrega você escolheu, pra onde entregar, e como acompanhar o status do pacote.

Se todas essas informações ficassem numa tabela gigante, ia virar bagunça: dados duplicados, difícil de atualizar e pior ainda — achar o que precisa rapidinho. O modelo relacional ajuda a organizar, separando as informações em tabelas diferentes que podem trocar dados entre si.

Nesse esquema aqui tem um exemplo de como organizar dados pra rastrear entregas:

• Clientes - aqui ficam as infos de cada cliente – com um Número do Cliente único.
• Serviços de entrega - essa tabela tem a lista dos serviços que podem fazer entregas, cada um com seu Número do Serviço único.
• Entrega do pedido - essa é a tabela central, que liga tudo. Cada linha aqui é uma entrega específica. Ela tem seu Número da Entrega, além de referenciar o cliente, o serviço de entrega, pode referenciar o pedido, a data e o status atual.

As setas mostram como os registros da tabela Entrega do pedido se conectam com os registros das tabelas Clientes e Serviços de entrega.

Exemplo fictício da tabela Entrega do pedido:

Vantagens desse jeito:

• As infos dos clientes ou dos serviços de entrega ficam salvas só uma vez, evitando repetição em cada registro de entrega.
• As ligações por números únicos (também chamados de chaves) garantem que não vai ter, por exemplo, entrega pra cliente que não existe ou por serviço que não existe.
• Dá pra juntar dados de várias tabelas pra fazer relatórios complexos ou buscas específicas.
• Se mudar algum dado, muda só num lugar e já vale pra tudo que estiver relacionado (tipo o telefone do serviço de entrega).

Estrutura de um banco de dados relacional

O núcleo de um banco de dados relacional são as tabelas. Cada tabela tem:

• Nome (Table Name) pra gente identificar — tipo customers.
• Conjunto de colunas (Columns/Attributes), que definem as propriedades do objeto.
  • Quando nomeamos colunas que servem como números únicos (chaves primárias), normalmente usamos o padrão nome_id. O sufixo _id aqui quer dizer "identificador". Exemplo: Número do Cliente vira customer_id.
  • Por exemplo, pra tabela customers: pode ter customer_id, first_name, email e por aí vai.
• Dados nas linhas (Rows/Records) - uma linha na tabela customers: vai ter todas as infos de um cliente específico (101, Alex Song e tal).

Bora ver um exemplo de tabela — customers:

Chaves das tabelas

Pra identificar cada linha de uma tabela de forma única, a gente usa a chave primária (Primary Key, PK). É uma coluna (ou mais) que tem valores únicos pra cada linha e não pode ser vazia. Pensa nela como um número exclusivo pra cada registro, tipo o customer_id na nossa tabela customers: identifica cada cliente sem erro.

A chave primária é tipo um passaporte, ou melhor, o número dele: único pra cada objeto. E evita problemas com registros com nomes iguais.

Pra criar ligações entre tabelas, usamos a chave estrangeira (Foreign Key, FK). É uma coluna numa tabela que aponta pra chave primária de outra tabela. As chaves estrangeiras são as "pontes" entre tabelas. Muitas vezes o nome da coluna de chave estrangeira é igual ao da chave primária pra qual ela aponta. Por exemplo, na tabela deliveries a coluna customer_id vai ser chave estrangeira, guardando valores da coluna customer_id da tabela customers, assim ligando a entrega ao cliente.

Esse é o esquema que a gente já viu, mas agora tá mais realista.

• A tabela customers tem as infos dos clientes; a chave primária dela é customer_id.
• A tabela delivery_services guarda os dados dos serviços de entrega; a chave primária dela é service_id.
• A tabela orders (tá aí só pra mostrar tudo, já que tem referência order_id na tabela de entregas) serve pra infos dos pedidos, com chave primária order_id.
• A tabela deliveries é a central pra rastrear as entregas. Ela tem:
  • Sua própria chave primária: delivery_id.
  • Três chaves estrangeiras pra fazer as ligações:
    • customer_id (FK): liga a entrega ao cliente da tabela customers.
    • service_id (FK): liga a entrega ao serviço escolhido da tabela delivery_services.
    • order_id (FK): liga a entrega ao pedido correspondente da tabela orders.
  • O campo created_date mostra a data e hora que o registro da entrega foi criado.

Esse uso de chaves primárias e estrangeiras garante a integridade dos dados. O sistema não deixa criar uma entrega se o customer_id ou order_id não existir nas tabelas certas e permite buscar informações relacionadas de forma flexível.

Vantagens do modelo relacional

O modelo relacional tem várias vantagens que fazem ele ser o queridinho entre os outros jeitos de guardar dados:

1. Estrutura simples. Tabelas com colunas e linhas são fáceis de entender.
2. Flexibilidade pra trabalhar com dados. Dá pra adicionar ou mudar dados fácil, sem quebrar tudo.
3. Suporte pra consultas complexas. Com SQL dá pra buscar dados de várias tabelas, juntar, filtrar e fazer quase tudo que sua tarefa pedir. Tipo achar todos os estudantes inscritos num curso específico — tranquilo!
4. Integridade dos dados via chaves. Usar chaves primárias e estrangeiras garante que os dados do banco vão ser consistentes. Não dá, por exemplo, pra cadastrar um estudante num curso que não existe.

O modelo relacional de dados é a base dos bancos de dados modernos. Ele é simples, poderoso e ótimo pra guardar dados estruturados. Como disse Edgar Codd: "Organize ou morra!" (ok, ele falou diferente, mas a ideia é essa...). Na próxima aula a gente vai ver como o modelo relacional é diferente de outros tipos de banco de dados (tipo NoSQL) e onde cada um é melhor de usar.