Modelagem de Bancos de Dados sem Segredos — Parte 04
A terceira parte pode ser lida no seguinte link:
Modelo Lógico Relacional
Introdução
Criado nos anos 70 por Edgar F. Codd. Começou a ser utilizado pelas empresas a partir de 1987. A abordagem relacional está baseada no princípio de que as informações em uma base de dados podem ser consideradas como relações matemáticas e que estão representadas de maneira uniforme, através do uso de tabelas bidimensionais. Este princípio coloca os dados (entidades e relacionamentos) dirigidos para estruturas mais simples de armazenar dados, que são as tabelas, e nas quais a visão do usuário é privilegiada.
Definição
São conjuntos de dados vistos segundo um conjunto de TABELAS e as operações sobre elas (tabelas) são feitas por linguagens que manipulam a álgebra relacional (SQL), não sendo procedurais, ou seja, manipulando conjuntos de uma só vez.
O conceito principal vem das teorias dos conjuntos (álgebra relacional) atrelado à ideia de que não é relevante ao usuário saber onde os dados estão nem como os dados estão. Os usuários manipulam objetos dispostos em linhas e colunas das tabelas.
Vantagens
Dentre as vantagens do Modelo Lógico Relacional, podemos citar:
- Independência total dos dados;
- Visão múltipla dos dados;
- Redução acentuada na atividade de desenvolvimento de aplicações e o tempo gasto em manutenção;
- Melhoria na segurança dos dados;
- Mais agilidade na questão gerencial da informação ligada ao processo decisório da organização.
As 12 Regras de Codd
Ao definir o modelo relacional, Codd estabeleceu um conjunto de 12 regras para determinar que um banco de dados é realmente relacional.
Regra 1 — Todas as informações em um banco de dados relacional são representadas de forma explícita no nível lógico e exatamente em apenas uma forma — por valores em tabelas.
Regra 2 — Cada um e qualquer valor atômico (datum) em um banco de dados relacional possui a garantia de ser logicamente acessado pela combinação do nome da tabela, do valor da chave primária e do nome da coluna.
Regra 3 — Valores nulos devem ser suportados de forma sistemática e independente do tipo de dado para representar informações inexistentes e informações inaplicáveis.
Regra 4 — A descrição do banco de dados é representada no nível lógico da mesma forma que os dados ordinários, permitindo que usuários autorizados utilizem a mesma linguagem relacional aplicada aos dados regulares.
Regra 5 — Um sistema relacional pode suportar várias linguagens e várias formas de recuperação de informações. Entretanto, deve haver pelo menos uma linguagem, com uma sintaxe bem definida e expressa por conjuntos de caracteres, que suporte de forma compreensiva todos os seguintes itens: definição de dados, definição de “views”, manipulação de dados (interativa e embutida em programas), restrições de integridade, autorizações e limites de transações (begin, commit e rollback).
Regra 6 — Todas as “views” que são teoricamente atualizáveis devem também ser atualizáveis pelo sistema.
Regra 7 — A capacidade de manipular um conjunto de dados (relação) através de um simples comando deve-se estender às operações de inclusão, alteração ou exclusão de dados.
Regra 8 — Programas de aplicação permanecem logicamente inalterados quando ocorrem mudanças no método de acesso ou na forma de armazenamento físico.
Regra 9 — Mudanças nas relações e nas views provocam pouco ou nenhum impacto nas aplicações.
Regra 10 — As aplicações não são afetadas quando ocorrem mudanças nas regras de restrições de integridade.
Regra 11 — As aplicações não são logicamente afetadas quando ocorrem mudanças geográficas dos dados.
Regra 12 — Se um sistema possui uma linguagem de baixo nível, essa linguagem não pode ser usada para subverter as regras de integridades e restrições definidas no nível mais alto.
Chaves e Índices
Chave — designa o conceito de item de busca, ou seja, um dado que será empregado nas consultas à base de dados. É um conceito lógico da aplicação.
Índice — é um recurso físico visando otimizar a recuperação de uma informação, via um método de acesso. Seu objetivo principal está relacionado com a performance de um sistema.
Uma chave pode ser utilizada como índice, mas um índice não é necessariamente uma chave. A forma de criação do índice depende do ambiente relacional.
O Conceito de Chave no Modelo Relacional
Chave Primária (primary key) — É o campo de uma tabela que identifica de forma única um registro.
Chave Secundária (secundary key) — Serve para definir uma segunda chave. No ambiente relacional uma tabela é acessível por qualquer campo independente deste ser declarado como chave ou não. Utiliza-se a declaração de chave secundária para agilizar o acesso àquela tabela naquele campo.
Para cada chave secundária declarada, o ambiente relacional cria um índice (estratégia de acesso). Qualquer campo pode ser chave secundária.
Chave Estrangeira (foreign key) — As chaves estrangeiras constituem um conceito de vital importância no modelo relacional. São os elos de ligação entre as tabelas.
Quando dizemos que duas tabelas estão relacionadas através de campos comuns, devemos observar que provavelmente esta coluna em uma das tabelas é uma chave primária. Na outra tabela, este campo caracterizará o que é denominado de chave estrangeira.
Regras de Integridade no Modelo Relacional
O modelo relacional possui algumas regras para que os dados não sejam corrompidos e que sejam sempre confiáveis.
1 — Integridade de Identidade
A chave primária não pode conter um valor nulo (NULL). O NULL não é o 0 (zero) nem o caractere em branco, é simplesmente a não-existência de conteúdo neste campo.
2 — Integridade Referencial
Se uma determinada tabela A possui uma chave estrangeira, a qual é chave primária em uma outra tabela B, então ela deve:
- Ser igual a um valor de chave primária existente em B ou
- Ser nula (NULL).
Não pode existir na chave estrangeira um valor que não exista na tabela na qual ela é chave primária.
As regras de integridade do modelo relacional representam a garantia de que as tabelas guardam informações compatíveis. São de extrema importância para a confiabilidade das informações contidas no banco de dados.
Derivação do DER para o Modelo Relacional
Esta é a etapa aonde vamos criar o banco de dados propriamente dito, convertendo as visões do modelo conceitual para o lógico relacional.
Existem regras de conversão precisas que não dão margem de erro, sendo que uma vez projetado o DER, as tabelas que o representam podem ser obtidas de forma clara. Vamos às regras.
- Toda entidade torna-se uma tabela carregando todos os atributos. Cada atributo vira um campo da tabela criada. Cada uma das chaves gera “estruturas de acesso”. A chave primária é projetada para não permitir ocorrências múltiplas e nem valores nulos.
- Os atributos das entidades e relacionamentos (que possuam atributos) devem ser gerados na ordem que minimize o consumo de espaço de armazenamento e torne mais eficiente a recuperação.
- Existe apenas uma ocasião em que o relacionamento do modelo conceitual se torna uma tabela no banco de dados. Trata-se do relacionamento de cardinalidade N:M envolvendo entidades distintas. O relacionamento torna-se uma tabela carregando os atributos e os identificadores das tabelas que ele relaciona.
Software para Modelagem
Para facilitar a criação dos modelos existem softwares que ajudam no processo:
- DBDesigner: feito em Delphi/Kylix. Tem o código fonte aberto e foi primeiro projetado para criar modelos para o MySQL. Com o tempo surgiu o DBDesigner-Fork que gera o script do banco de dados para outros bancos: Oracle, PostgreSQL, SQL Server, Firebird, etc. Infelizmente o projeto foi abandonado, mas ainda é bastante utilizado por profissionais da área.
- MySQL Workbench: deriva do DBDesigner. Desenvolvido exclusivamente para se trabalhar com o MySQL, é uma das ferramentas gratuitas mais conhecidas e mais utilizadas para quem trabalha com este banco de dados, tanto para modelagem ER, como para execução de scripts SQL.
- Vycanis Modeler (https://vycanis.top/modeler/): criado por este autor, esse software é disponibilizado de forma gratuita para a modelagem de dados, gerando o script de dados para os seguintes bancos: Firebird, DB2, MariaDB, MySQL, Oracle, PostgreSQL e SQLite. Vamos utilizá-lo para criar nossos modelos.
Outros exemplos que podemos citar: SAP Power Designer e CA ERwin.
Padronização do Banco de Dados
Introdução
É uma boa prática que a organização defina a padronização para seus bancos de dados. No entanto, ainda é muito comum, mesmo em organizações e empresas de médio e grande porte, a falta de padronização na modelagem de dados, o que acarreta uma série de problemas no desenvolvimento de software.
Vamos apresentar neste momento um modelo de padronização de banco de dados que pode ser utilizado por qualquer organização e, logo após isso, modelaremos um grupo de tabelas utilizando o Vycanis Modeler (https://vycanis.top/modeler/) seguindo a padronização definida aqui.
Definições Gerais
- O nome da entidade deve ser escrito no singular e em maiúsculo;
- O nome deve ser o mais descritível possível e deve identificar a utilidade e aplicação da entidade. Não se deve utilizar acentos e nem o cedilha;
- Caso o nome seja composto, deve ser separado por Underline. Exemplo: RAZAO_SOCIAL;
- Se possível, deve-se evitar abreviações, a não ser que o nome fique muito grande. Deve ter no máximo 30 caracteres por conta de limitações de alguns bancos de dados (Oracle e Firebird).
- Não utilizar o nome da entidade nos atributos. Por exemplo, para a tabela CLIENTE, não utilizar o nome de atributo NOME_CLIENTE, mas apenas NOME.
PK — Chave Primária
- Usar chave primária sempre com um campo. Não utilizar chaves compostas;
- A chave primária deve sempre ser o primeiro campo da tabela;
- A chave deve sempre ser referenciada como “ID”. Deve ser autoincremento.
Índices
- O índice da chave primária deve ser nomeado apenas como PRIMARY;
- Os índices que serão criados na própria tabela para otimização de consultas devem seguir o padrão IX_NOME_TABELAn, onde o “n” é um número que vai sendo incrementado de acordo com a quantidade de índices.
Chaves Estrangeiras
O nome do campo deve ser igual à chave primária da tabela de origem concatenado com o nome da tabela. Por exemplo, a tabela PAGAMENTO deverá ter um relacionamento com a tabela FORNECEDOR. O campo que será utilizado na tabela PAGAMENTO será ID_FORNECEDOR. O nome do índice será FK_PAGAMENTO_FORNECEDOR. Caso o nome fique muito grande e não seja possível a criação por parte do banco de dados, é permitido fazer a abreviação.
Tipos de Dados
Deve-se respeitar o tipo de dado para o campo definido. Serão escolhidos os tipos que sejam comuns a todos os bancos de dados.
Sequence e Generator
Para os bancos que necessitam da criação de uma Sequence ou Generator a parte da tabela, deve-se seguir o seguinte padrão: SEQ_NOME_TABELA.
Views
Deve-se criar a view com um prefixo para que a mesma seja identificada como tal. Por exemplo: VIEW_CONTROLE_ACESSO.
Procedures, Functions, Triggers
Não serão utilizados, a princípio. Mas caso haja a necessidade de criação, deve-se utilizar um prefixo para identificação:
Procedure — SP_
Function — FUNCTION_
Trigger — TRIGGER_
Comentários
Deve-se ter como hábito fazer os devidos comentários para as tabelas e os campos na ferramenta utilizada para a modelagem do DER. Dessa forma as tabelas e campos ficam bem documentados.
Tipos de Dados
Introdução
Antes de partirmos para nosso exemplo no Vycanis Modeler, vamos primeiro analisar os tipos de dados que estão disponíveis nos bancos de dados.
O que é um tipo de dado? Quando você está utilizando o seu celular, em alguns momentos aparece um teclado com letras e números e em outras ocasiões aparece apenas o teclado numérico. Se você tentar inserir um novo contato, verá que para informar o nome do contato será disponibilizado o teclado alfanumérico (letras, números e símbolos) e para informar o número do telefone será disponibilizado o teclado numérico (apenas números). O tipo de dado define exatamente isso, o tipo de informação que pode ser armazenada.
Antes de criar uma tabela você precisa entender as diferenças entre os tipos de dados que você pode utilizar em um campo. Os tipos de dados SQL se classificam em 13 tipos de dados primários e de vários sinônimos válidos reconhecidos por tais tipos de dados. Os tipos de dados primários são:
Dependendo do banco de dados que você escolher para utilizar, os tipos poderão ser encontrados com outros sinônimos. Alguns destes sinônimos são vistos na tabela a seguir.
Seguem alguns exemplos e quais seriam os tipos de dados mais indicados.
Cada SGBD tem suas características próprias e pode definir outros tipos de dados em complemento aos que vimos aqui. Consulte a documentação do SGBD que você está utilizando para conhecer os tipos de dados utilizado por ele.
Parte 4 — Considerações Finais
Nessa parte abordamos alguns pontos do modelo lógico relacional. Vimos as 12 regras de Codd e aprendemos sobre os tipos de chaves: chave primária, chave secundária e chave estrangeira.
Aprendemos ainda as regras de integridade: integridade de identidade e integridade referencial. Conhecemos algumas ferramentas que ajudam na modelagem do banco de dados.
Nós vimos um modelo de padronização do banco de dados. É comum que as empresas adotem um modelo de padronização. Caso a empresa onde você trabalha não possua um modelo, você pode apresentar o modelo proposto aqui ou até mesmo adaptar o modelo de acordo com as necessidades da empresa. Você viu quais são os principais tipos de dados utilizados quando criamos campos nas tabelas do banco de dados.
Nós também vimos que você pode padronizar o banco de dados criando algumas regras. Aquele documento pode ser expandido criando regras para os campos do banco de dados. Por exemplo, você pode definir que os campos do tipo TELEFONE sempre serão VARCHAR tamanho 10. Dessa forma, quando uma nova tabela for criada, se ela tiver um campo do tipo TELEFONE, não existirão dúvidas sobre o tipo e tamanho do campo.
Analise novamente o estudo de caso Pedido e tente padronizar os campos para as tabelas que foram ali criadas.
Conheça o Vycanis Modeler
Faça a modelagem do seu Banco de Dados usando o Vycanis Modeler. Gere o código para vários bancos de dados: Firebird, DB2, MariaDB, MySQL, Oracle, PostgreSQL e SQLite.
Além disso, o Vycanis vai gerar um MVP com base no seu modelo. Veja o vídeo abaixo, onde em cerca de 10 minutos criamos um MVP para controle de empréstimos.
Para conhecer o Vycanis, leia o artigo abaixo:
