Fala pessoal…
Hoje vamos dar continuidade em nossa trilha do SQL, e aprender uma parte conceitual muito importante para aperfeiçoarmos nossa logica na hora de estruturar um banco de dados e ate mesmo um sistema.
Esta etapa é muito importante para testarmos nossa ideia de criação de um banco de dados, suas tabelas, colunas e relacionamentos.
Hoje vamos falar sobre o Modelo Entidade Relacionamento e sobre o Diagrama Entidade Relacionamento ou simplesmente MER e DER.
MER
O Modelo Entidade Relacionamento é uma forma lógica de pensarmos na estrutura de um banco de dados e assim definir suas Entidades(tabelas), Relacionamentos (chaves) e Atributos(campos).
Como é uma parte bem conceitual, a ideia do MER é pensarmos em nosso sistema de forma estruturada. Por exemplo, vamos imaginar que estamos montando um banco de dados de uma loja de de departamento que quer vender via e-commerce .
Entidades
Então começamos a pensar nas nossas entidades principais que não dependem de outras entidades para existir, vamos definir algumas:
- Fornecedor
- Produto
- Cliente
- Departamento
Essas entidades são conhecidas como Entidades Fortes. Elas podem existir por si só e não dependem de outras para definir sua importância.
Em seguida vamos pensar em algumas entidades que necessitam das anteriores para existir, como por exemplo:
- Usuário
- Pedido de Venda
- Pedido de Compra
- Categoria
Essas entidades são conhecidas como Entidades Fracas, pois dependem de outras entidades para existir.
Também temos algumas entidades que existem para realizar a interligação entre as entidades. Elas são chamadas de Entidades Associativas, veja:
- Usuário do Cliente
- Itens do Pedido de Venda
- Itens do Pedido de Compra
- Produtos do Fornecedor
- Produtos da Categoria
- Categorias do Departamento
A ideia dessas entidades é que elas não possuem uma chave primaria própria mas sim a junção de outras chaves primarias para criar seus registos únicos, como por exemplo:
Itens do Pedido de Venda -> Código do Pedido + Código do Produto .
Relacionamentos
Agora que definimos as entidades, é necessário definirmos os relacionamentos entre elas, para isso temos três formas de relacionamentos.
- Relacionamento 1 para 1 – No relacionamento 1:1, definimos que sempre sera um registro de uma entidade vai se relacionar com apenas um registro de outra entidade. Por exemplo, um cliente pode ter apenas um usuário cadastrado para acessar o sistema.
- Relacionamento 1 para muitos – No relacionamento 1:n, definimos que um registro de uma entidade poderá ter vários registros de outra entidade. Por exemplo, um cliente pode ter vários pedidos de venda, porem um pedido de venda não pode pertencer a vários cliente.
- Relacionamento muitos para muitos – No relacionamento n:n, definimos ambas entidades podem ter mais de um relacionamento entre elas. Por exemplo, um pedido de venda pode ter vários produtos e um produto pode pertencer a vários pedidos de vendas.
Atributos
Agora vamos entender os atributos.
Os atributos são as características e informações que cada entidade possui. Eles podem ser de alguns tipos diferente:
- Atributos Nominativos – são aqueles que identificam um objeto da classe, como por exemplo o CPF de um cliente, o nome do cliente, ou até mesmo o código do cliente dentro do sistema.
- Atributos Descritivos – são aqueles que descrevem alguma informação do objeto, como por exemplo, data de nascimento do cliente, o nome do cliente também pode ser um atributo descritivo, endereço, etc…
- Atributos Referenciais – são atributos que realizam a ligação entre entidades, como por exemplo o código do cliente dentro do pedido de venda, o código do produto dentro do pedido de venda, o código da categoria dentro do produto, etc…
Além dessa divisões também podemos classificar os atributos como simples ou compostos.
Os atributos simples são aqueles que uma única informação os define, como por exemplo a data de nascimento do cliente, ou a descrição do produto.
Já os atributos compostos são aqueles que necessitam de mais de um atributo para possuírem a informação completa, como por exemplo o endereço, que necessita do atributo logradouro + complemento + bairro + cidade + estado + CEP.
Agora que entendemos o Modelo Entidade Relacionamento, podemos ver que é muito difícil desenhar todo um banco de dados somente com o MER, e por isso temos o DER que é o Diagrama Entidade Relacionamento.
DER
O Diagrama Entidade Relacionamento é a forma gráfica de representar o MER, ele se baseia em uma representação por diagramas, onde possui um nível de abstração muito maior que o MER.
Temos algumas formas de criar o nosso DER. Dois modelos muito conhecidos são:
Notação Peter Chen
Peter Chen é um cientista da computação nascido em Taiwan e Professor de ciência da computação na Louisiana State University, conhecido como criador do modelo entidade relacionamento.[1]
Consiste em uma notação que utiliza entidades (retângulos), relacionamentos (losangos), atributos (elipses) e linhas de conexão (linhas) que indicam a cardinalidade de uma entidade em um relacionamento.
A mesma é representada como o exemplo abaixo:
Notação James Martin
James Martin foi um britânico consultor e autor sobre Tecnologia da Informação, conhecido por seu trabalho em engenharia de tecnologia da informação.
Sua notação consiste na utilização de entidades (caixas), com seus atributos representados diretamente dentro da Entidade, e os relacionamentos são feitos através de linhas que representam a cardinalidade.
Esta notação exibe as informações de uma forma mais enxuta e fácil de visualizar.
Vamos montar nosso exemplo utilizado o DER do do próprio Microsoft SQL Server.
É isso pessoal, espero que ajude muito quando precisarem a estruturar um novo banco de dados.
