Um Banco de Dados representa uma coleção de dados que possui algum significado e objetiva atender a um conjunto de usuários. Por exemplo, um catálogo telefônico pode ser considerado um BD. Sendo assim, um BD não necessariamente está informatizado.
Quando resolvemos informatizar um Banco de Dados, utilizamos um programa especial para realizar essa tarefa. Tal programa é denominado SGBD – Sistema Gerenciador de Banco de Dados.
Podemos citar como exemplos de SGBDs: SQL Server, Oracle, Firebird, MySQL, Interbase, entre outros. Estes programas em geral são chamados SGBDs relacionais.
Em um SGBD relacional, enxergamos os dados armazenados em uma estrutura chamada tabela. Neste modelo, as tabelas de um Banco de Dados são relacionadas, permitindo assim que possamos recuperar informações envolvendo várias delas. Observe o exemplo abaixo:
Note que o cliente Marcio possui dois telefones: um residencial e um celular. A cliente Luciane possui um telefone celular, Wilkie possui um residencial e Marlos não possui telefone.
Entretanto, para que possamos implementar, de forma correta, um Banco de Dados utilizando algum SGBD, temos que passar por uma fase intermediária – e não menos importante - chamada modelagem de dados.
Quando estamos aprendendo a programar, em geral dividimos esta tarefa em três fases:
- Entendimento do problema;
- Construção do algoritmo;
- Implementação (linguagem de programação).
Em se tratando de banco de dados não é muito diferente:
- Entendimento do problema;
- Construção do modelo ER – entidade e relacionamento;
- Implementação (SGBD).
Entender determinado problema nem sempre é uma tarefa fácil, principalmente se você não está familiarizado com a área de atuação de seu cliente. O profissional de informática precisa dominar a tecnologia, e além disso precisa ter habilidade para saber ouvir o cliente e ao mesmo tempo abstrair o que realmente é necessário para a implementação de alguma solução utilizado a tecnologia (in)disponível.
Antes da implementação em um SGBD, precisamos de uma descrição formal da estrutura de um banco de dados, de forma independente do SGBD. Essa descrição formal é chamada modelo conceitual.
Costumamos representar um modelo conceitual através da abordagem entidade–relacionamento (ER). Nesta abordagem construimos um diagrama, chamado diagrama entidade-relacionamento. Observe abaixo o diagrama que originou as tabelas Clientes e Telefones:
Entidade pode ser entendida como uma “coisa” ou algo da realidade modelada onde deseja-se manter informações no banco de dados (BD). Por exemplo, em um sistema escolar, algumas entidades podem ser os alunos, professores, horário, disciplinas e avaliações. Note que uma entidade pode representar tanto objetos concretos (alunos), quanto objetos abstratos (horário). A entidade é representada por um retângulo, que contém o nome da entidade. Observe o exemplo abaixo.
A entidade ALUNO representa todos os estudantes sobre as quais se deseja manter informações no BD. Quando é necessário especificar um objeto particular (para o exemplo, determinado estudante) usa-se o termo ocorrência de entidade.
Relacionamento é um conjunto de associações entre entidades. O relacionamento é representado por um losango. Esse losango é ligado por linhas aos retângulos que representam as entidades participantes do relacionamento. O exemplo abaixo possui duas entidades, MÉDICO e PACIENTE, e um relacionamento chamado CONSULTA.
O modelo acima informa que o BD mantém informações sobre médicos, pacientes, além de um conjunto de associações (consulta), cada uma ligando um médico a um paciente. Quando é necessário especificar um relacionamento particular (para o exemplo, determinada consulta) usa-se o termo ocorrência do relacionamento. Uma ocorrência de consulta envolve a ocorrência de determinado médico e a ocorrência de determinado paciente.
Um relacionamento pode envolver ocorrências de uma mesma entidade. Neste caso, estamos diante de um auto-relacionamento. Observe o exemplo:
CASAMENTO é um relacionamento que envolve duas ocorrências da entidade PESSOA. Para facilitar o entendimento, em geral costumamos identificar o papel de cada entidade no relacionamento (para o exemplo, marido e esposa).
Cardinalidade do relacionamento
Observe o modelo abaixo:
Estamos diante de um relacionamento (possui) entre as entidades EMPREGADO e DEPENDENTE. Considere as seguintes questões:
- Um empregado pode não ter dependentes?
- Um dependente pode ter mais de um empregado associado?
- Determinado empregado pode possuir mais de um dependente?
- Pode existir dependente sem algum empregado associado?
Na realidade, as respostas desses questionamentos dependem do problema sendo modelado. Entretanto, para que possamos expressar essas idéias no modelo, é necessário definir uma propriedade importante do relacionamento - sua cardinalidade.
A cardinalidade é um número que expressa o comportamento (número de ocorrências) de determinada entidade associada a uma ocorrência da entidade em questão através do relacionamento.
Existem dois tipos de cardinalidade: mínima e máxima. A cardinalidade máxima, expressa o número máximo de ocorrências de determinada entidade, associada a uma ocorrência da entidade em questão, através do relacionamento. A cardinalidade mínima, expressa o número mínimo de ocorrências de determinada entidade associada a uma ocorrência da entidade em questão através do relacionamento. Usaremos a seguinte convenção para expressar a cardinalidade:
Número (Mínimo, Máximo)Observe as cardinalidades mínima e máxima representadas no modelo abaixo:
Para fazermos a leitura do modelo, partimos de determinada entidade e a cardinalidade correspondente a essa entidade é representada no lado oposto. Em nosso exemplo, a cardinalidade (0:N) faz referência a EMPREGADO, já a cardinalidade (1:1), faz referência a DEPENDENTE. Isso significa que:
- Uma ocorrência de empregado pode não estar associada a uma ocorrência de dependente ou pode estar associada a várias ocorrências dele (determinado empregado pode não possuir dependentes ou pode possuir vários);
- Uma ocorrência de dependente está associada a apenas uma ocorrência de empregado (determinado dependente possui apenas um empregado responsável).
Na prática, para as cardinalidades máximas, costumamos distinguir dois tipos: 1 (um) e N (cardinalidades maiores que 1). Já para a as cardinalidades mínimas, costumamos distinguir dois tipos: 0 (zero) e 1 (um).
Atributo é uma característica relevante associada a cada ocorrência de entidade ou Relacionamento. Observe no modelo abaixo a notação utilizada para atributos:
Cardinalidade do atributo
Observe que o modelo acima não informa se determinado aluno pode ter vários telefones, ou mesmo se algum aluno pode não ter telefones. Para deixar o modelo mais preciso, costumamos expressar cardinalidade para os atributos. Observe a cardinalidade do atributo telefone no modelo abaixo:
Dessa forma, podemos concluir que determinado aluno pode não ter telefone (cardinalidade mínima zero) ou pode ter vários (cardinalidade máxima N). A cardinalidade dos atributos código e nome é (1,1). Por convenção, ela foi omitida do diagrama.
No caso de atributos, a cardinalidade mínima 1 indica que o atributo é obrigatório e a cardinalidade máxima 1 indica que o atributo é monovalorado. Para o atributo telefone, a cardinalidade mínima 0 indica que o mesmo é opcional e a cardinalidade máxima N informa que ele é multivalorado.
Saiba mais sobre Banco de Dados e Modelagem de Dados ;)
- Guia de Modelagem de Dados:
Essa guia terá como objetivo apresentar a modelagem de dados, desde seus primeiros passos com banco pequenos até a modelagem para bancos Big Data. - Banco de Dados para Programadores:
Todo programador deveria entender de banco de dados para ser um profissional mais completo, mas isso não é tarefa simples. Nesse guia você irá aprofundar seus conhecimentos em SQL, modelagem, e os principais SGBDs do mercado. Vamos evoluir!
