No post passado foi dito que um banco de dados armazena dados de forma organizada de forma que possibilite a extração de informações. Neste post irei mostrar como modelar um banco de dados seguindo o modelo relacional.
Os dados de um banco de dados relacional ficam armazenados em tabelas, estas são dividas em colunas, as quais armazenam dados distintos.
Imagine que queremos armazenar dados pessoais de alunos de uma escola qualquer. A primeira coisa a se fazer é pensar em quais dados precisamos armazenar. Para o exemplo deste post os dados serão: Nome, Idade, Sexo, Data de Nascimento, Endereço, Telefone
Representação da tabela Aluno
Algumas observações sobre a tabela acima
As colunas armazenam tipos de dados diferentes. Número, texto e data
A tabela contém alguns dados repetidos
As colunas podem ter dados repetidos ou não
Algumas colunas podem ter dado ou não
Chave primária
Se eu quisesse, por exemplo, pegar os dados do Fabio Henrique da primeira linha da tabela seria algo trabalhoso devido a duplicidade de dados. Para isso eu teria que criar um filtro usando mais de um dado, como critério de busca, para garantir que estou buscando pelo Fabio Henrique correto.
O filtro seria algo do tipo:
Nome = 'Fabio Henrique' e Data_Nascimento = '18/03/1990'O filtro acima me retornaria o Fabio Henrique certo porque as datas de nascimento dos dois registros da tabela Aluno são distintos.
Este tipo de abordagem é bem ruim. Isto porque mais dados podem estar duplicados e a tabela pode ainda conter uma quantidade extremamente maior de registros. E é para resolver esse tipo de situação que temos no banco de dados o que chamamos de chave primária.
Chave primária é uma forma de cada registro ter uma identificação única dentro de uma tabela. Geralmente utilizamos números inteiros para representar um chave primária.
Durante os posts de banco de dados irei utilizar o inglês para me referir a chave primária. Sendo Primary key ou simplesmente sua forma abreviada PK.
Abaixo temos a representação da tabela Aluno. Geralmente a coluna que representa a PK é nomeada da seguinte forma de <NOME_DATA_TABELA> + Id
Agora que temos PK nessa tabela o filtro que fizemos anteriormente ficaria bem mais simples
AlunoId = 1Chave estrangeira
A modelagem de um banco de dados sempre depende dos requisitos do sistema a que ele pertence. Imagine que um sistema permita que os alunos cadastrem mais de um endereço. Neste caso a nossa tabela Aluno não serviria porque ela tem apenas uma coluna para armazenar endereço.
Se você pensou em criar novas colunas por exemplo: Endereco2, Endereco3, Endereco4 etc. Essa é a abordagem mais bosta de todas e não faz sentido algum porque não há como prever quantos endereços um aluno irá cadastrar.
Para resolver esse problema vamos remover a coluna Endereco da tabela Aluno e criar uma outra tabela para armazenar apenas dados relacionados a endereços de um aluno. Vamos chamar esta nova tabela de Aluno_Endereco.
Repare que esta tabela possui uma coluna AlunoEnderecoId que representa a PK e outra coluna AlunoId que representa o código do usuário a que este endereço pertence. A coluna AlunoId é o que chamamos de chave estrangeira.
Durante os posts de banco de dados irei utilizar o inglês para me referir a chave estrangeira. Sendo Foreign key ou simplesmente sua forma abreviada FK.
A chave estrangeira é uma forma de criar relacionamento entre tabelas distintas. O valor da chave estrangeira é referente a PK de uma outra tabela. Baseado nisso podemos concluir algumas coisas:
Na tabela Aluno_Endereco a coluna AlunoId (FK) é referente a coluna AlunoId (PK) da tabela Aluno
Para criar um registro na tabela Aluno_Endereco é preciso ter ao menos um aluno cadastrado na tabela Aluno. O que faz com que a tabela Aluno_Endereco seja dependente da tabela Aluno
O aluno de AlunoId igual a 1 possui dois endereços cadastrados
Tipos de relacionamentos
Um para um - Representado pela cardinalidade (1:1) este tipo de relacionamento se dá, de forma direta entre duas tabelas, quando a chave primária do registro de uma determinada tabela pode ser utilizada uma única vez em um dos registros da outra tabela. Por exemplo, no Brasil um homem pode (do ponto de vista legal) se casar com apenas uma mulher e uma mulher poder se casar somente com um homem. Observe que a cardinalidade homem X mulher é de (1:1).
Um para muitos - Representado pela cardinalidade (1:N) este tipo de relacionamento se dá, de forma direta entre duas tabelas, quando a chave primária do registro de uma determinada tabela pode ser utilizada várias vezes em outra tabela. Por exemplo, nos países árabes um homem pode se casar com mais de uma mulher (até quatro), mas a recíproca não é verdadeira, pois uma mulher somente pode se casar com um homem. Observe que a cardinalidade homem X mulher é de (1:N), mas a cardinalidade mulher X homem é de (1:1).
Muitos para muitos - Representado pela cardinalidade (N:N) este tipo de relacionamento acontece quando vários registros de uma tabela se relacionam com vários registros de outra. Pode-se dizer que este é um relacionamento de forma indireta, pois é necessário que se crie uma terceira tabela. Por exemplo, o fato de um aluno cursar uma ou mais disciplinas e o fato de uma disciplina ser cursada por um ou mais alunos. Observe que a cardinalidade aluno X curso é de (N:N) e a cardinalidade curso X aluno é de (N:N). Neste exemplo a terceira tabela poderia ser uma tabela chamada Aluno_Disciplina que iria ter duas FK's uma proveniente da tabela Aluno e outra da tabela Disciplina.
Observações
As tabelas devem agrupar dados por assunto. Por exemplo, no exemplo deste post faria todo sentido remover o contato da tabela Aluno e colocá-lo em uma tabela separada. Por exemplo, Aluno_Contato.
A modelagem do banco de dados depende exclusivamente do negócio. Por isso é muito importante levantar os requisitos corretamente com o cliente.
Vamos analisar dois cenários com clientes de escolas distintas.
Cliente 1: "Aqui na minha escola os professores lecionam apenas uma disciplina" Para este caso podemos pensar em um relacionamento do tipo 1:1 onde um professor leciona apenas uma disciplina e uma disciplina é lecionada por apenas um professor.
Cliente 2: "Aqui na minha escola os professores podem lecionar disciplinas distintas" Para este caso podemos pensar em um relacionamento do tipo N:N onde um professor pode lecionar umas ou mais disciplinas e estas mesmas disciplinas podem ser lecionadas por um ou mais professores.
Os exemplos acima deixam claro que negócios diferentes irão possuir modelagens diferentes. Portanto, sempre que for levantar requisitos com algum cliente certifique-se de extrair o máximo de informações sobre o negócio dele.
Tenha em mente que o processo de desenvolvimento de software é bem dinâmico, requisitos de negócio podem mudar durante o processo. Isto significa que o tanto o código quanto o banco de dados estão sujeitos à alterações, algumas de baixo impacto outras de impacto gigantesco!
Comments