A primeira parte pode ser lida no seguinte link:

Compreensão da Realidade

Como projetar um sistema se não entendermos o negócio no qual será realizado? É necessário reconhecer os objetos que compõem o negócio, independente de preocupar-se com as formas de tratamento das informações, procedimentos, programas etc.

Esses objetos que desejamos conhecer e modelar para um sistema estão classificados em dois grupos: Entidades e Relacionamentos.

Entidades

Se alguma “coisa” existente no negócio nos proporciona algum interesse em mantermos dados (informações armazenadas sobre ele), isto a caracteriza como uma Entidade do negócio. Esta entidade será então um conjunto de dados em nosso modelo conceitual. A representação de uma Entidade no modelo Entidade-Relacionamento se realiza através de um retângulo, com o nome desta entidade em seu interior.

Ao visualizar uma Entidade, devemos entendê-la como uma tabela de dados, onde cada linha da tabela representa uma instância da mesma (o conhecido registro ou tupla). Por exemplo, quando vamos a uma locadora alugar um filme, estamos consultando uma entidade <FILME> que contém diversas instâncias — as fitas disponíveis.

Para descrever melhor uma entidade precisamos do que chamamos de atributos de uma entidade. Todo objeto, para ser uma entidade, possui propriedades que são descritas por atributos e valores. Esses atributos e valores juntos descrevem as instâncias de uma entidade, formando o registro (ou tupla).

Imaginemos que em uma empresa temos uma entidade, um objeto sobre o qual desejamos manter informações armazenadas chamada Cliente. O que descreve Cliente?

Cliente é descrito por um CPF, um nome cliente e seu telefone. (Observe a tabela acima. Quantos registros temos?). Existem muitas outras coisas que descrevem um cliente, mas decidimos descrevê-lo utilizando apenas esses três atributos.

Chave Primária

Cada instância de Cliente será formada por valores nestes atributos, sendo que é o conjunto destes valores representados que devemos visualizar como uma linha de uma tabela de dados.

Devemos buscar um valor que identifique um cliente de forma singular, ou seja, de tal maneira que possamos distinguir um cliente do outro. No exemplo anterior, nós temos o atributo CPF, que é sempre diferente para cada pessoa existente no Brasil. Esse atributo é a nossa chave primária.

Às vezes é preciso mais do que um atributo para formar uma chave primária. Digamos que temos uma entidade Animal, que é utilizada dentro de uma clínica veterinária. Poderíamos ter os seguintes atributos para essa entidade: Nome, Raça, Data de Nascimento. Dois ou mais animais podem ter o mesmo nome (Ralf, por exemplo). Dois ou mais animais podem ter a mesma raça (pastor alemão, por exemplo). Dois ou mais animais podem ter a mesma data de nascimento. E agora? Qual atributo será nossa chave primária? Nesse caso podemos selecionar mais do que um atributo e formar um conjunto para ser a chave primária. Será que dois animais podem ter o mesmo nome, a mesma raça e a mesma data de nascimento ao mesmo tempo? Isso pode até acontecer, mas é bem mais difícil! Poderíamos utilizar os três atributos para formar a nossa chave primária.

Esses atributos cujo valor não se repetem são chamados de chave primária. Ela identifica uma única ocorrência dentro de uma tabela. De fato, no exemplo utilizado anterior para a clínica veterinária, deveríamos buscar por outra chave primária, uma que garantisse que dois registros não se repetiriam na tabela.

Veja na figura acima que temos duas entidades: Album e Artist. A princípio Album tem apenas um atributo (Title) e Artist também tem apenas um atributo (Name). Qual seria a chave primária? Muitos analistas partem para a solução de criar uma chave que não pertence necessariamente àquela entidade no mundo real. Ou seja, basta apenas atribuir um código para a entidade, um código que não se repete. Esse código costuma ser chamado de Identificador ou apenas ID. Você vai se deparar muito com esse Atributo em bancos de dados existentes e nos novos. É quase certo que um dia você o utilizará! O ID é uma excelente opção para nosso problema na entidade Animal.

Relembrando os Termos Utilizados até Aqui

Para que não haja confusão de palavras ou conceitos, vejamos as relações existentes entre as palavras vistas até aqui com as que são mais comumente utilizadas quando começamos a criar o banco de dados. Em parêntesis você pode ver os mesmos termos utilizados na língua inglesa.

• Entidade (Entity) — É na verdade a Tabela (Table) do banco de dados.
• Atributos (Attributes) — São os Campos (Columns) que formam a Tabela.
• Instância (Instance) — É cada linha (Row) da tabela. São os Registros (Records) da Tabela. Também chamados de Tuplas (Tuples).
• Chave Primária (Primary Key) — É o Campo que não se repete. No caso da Entidade Cliente é o Campo CPF. No caso das Entidades Album e Artist é o campo ID.

Enxergando Entidades

Em um primeiro contato com um negócio para o qual se criará um sistema, podemos não possuir conhecimento especializado do mesmo, logo devemos procurar conhecer os seus objetos principais. A descrição dos objetos ou do objeto central do negócio irá nos apresentar a realidade retratada em diversas entidades. Vejamos um exemplo prático. Utilizaremos um exemplo prático que era muito comum antes dos anos 2000, mas que praticamente desapareceu do mapa por conta de serviços de assinaturas de canais e streaming.

Locadora

Uma locadora precisa controlar os filmes que aluga. Quais os candidatos a entidades? O objetivo máximo dessa locadora é o controle dos filmes locados. Portanto existe um objeto crucial para o funcionamento do negócio: os Filmes.

Mas os filmes possuem atributos que os caracterizam efetivamente como uma entidade? Existirão várias ocorrências de filmes? Podemos representá-los sobre a forma de uma tabela com linhas e colunas? Podemos responder afirmativamente a todas essas perguntas, o que nos permite dizer que o objeto FILME é uma entidade.

O que descreve a entidade Filme. Quais os seus atributos? Poderíamos citar: Nome, Duração, Atores, Gênero.

Qual a nossa chave primária? Os quatro atributos acima certamente precisarão se repetir, por isso criaremos um quinto atributo e lhe chamaremos de Código. Esse atributo será autonumerado e, portanto, não se repetirá (poderia ser o famoso ID). Vejamos como ficaria essa entidade na forma de uma tabela de dados.

Continuando com nossa análise podemos encontrar mais entidades. Vamos encontrar pelo menos mais uma? Para que exista o aluguel dos filmes é necessário que ALGUÉM alugue os mesmos. Esse ALGUÉM são os clientes da locadora. Portanto Cliente é um objeto para o funcionamento da locadora. Esse objeto é uma entidade? Se fizermos as mesmas perguntas anteriores encontraremos um SIM a todas elas. Cliente é então uma entidade.

Quais os atributos de Cliente? Podemos citar entre muitos: Nome, Endereço e CPF. Qual a nossa chave primária? CPF. Vejamos como ficaria essa entidade na forma de uma tabela de dados.

Existem outras Entidades nesse exemplo. Vamos ficar por aqui visto que faremos um estudo de caso completo mais na frente. Por enquanto deu para perceber como fazer para observar quais os objetos que existem numa realidade e como saber se esses são ou não entidades.

Relacionamentos

Relacionamento é o fato, o acontecimento que liga dois objetos, duas “coisas” existentes no mundo real. Em se tratando de banco de dados, é o fato que efetua a junção de duas ou mais tabelas de dados.

Para um retrato dos objetos e fatos de um problema, os relacionamentos são elementos que nos dão o sentido da existência desses objetos e suas inter-relações, sem as quais ficaria de extrema complexidade o entendimento e a compreensão do domínio do problema.

Pense nos dois substantivos: João e Maria. Qual a relação entre eles? Olhando apenas para esses dois nomes não podemos ver relação nenhuma. Vamos acrescentar um verbo:

João NAMORA Maria.

Agora sim. Temos uma relação entre os dois substantivos. O verbo serve para dar sentido às coisas. Ele faz com que haja uma ligação entre as coisas.

Verbo = Expressão de um fato.

Diariamente podemos observar os mais variados tipos de entidades no mundo real. Essas entidades estão ligadas entre si através dos relacionamentos.

Exemplos:

As Pessoas MORAM em Apartamentos;
Os Apartamentos FORMAM Condomínios;
Os Condomínios LOCALIZAM-SE em Ruas ou Avenidas;
As Avenidas e Ruas ESTÃO em uma Cidade;
As Cidades FORMAM Estados;
Os Estados FORMAM Países.

Até onde poderíamos ir?

Condicionalidade

Existem dois tipos de relacionamento:

• Condicionais — Possuem uma condição, uma qualificação para acontecerem.
• Incondicionais — Não possuem esta condição, são obrigatórios.

Relacionamentos Condicionais

São aqueles relacionamentos em que nem todos os elementos de uma entidade A estão ligados com elementos da entidade B. Dizemos que este tipo de relacionamento possui opcionalidade.

Por exemplo: Se tivermos duas entidades, uma de homens e outra de mulheres. Pode haver ou não relacionamento entre um homem e uma mulher. Um dos homens pode ser casado com uma das mulheres. Pode ocorrer de haver homens e mulheres não casados. Veja a figura a seguir.

Relacionamentos Incondicionais

Todos os elementos de uma entidade estão obrigatoriamente relacionados com um elemento, no mínimo, da outra entidade.

Por exemplo: Se tivermos as entidades Mãe e Filho. Todo filho tem que ter uma mãe e toda mulher para ser mãe tem que ter, pelo menos, um filho. Portanto é obrigatória essa relação.

Representação Gráfica

Peter Chen criou uma representação gráfica para as entidades e os relacionamentos. Já vimos que as entidades são representadas por retângulos com o nome da entidade dentro. Os relacionamentos são representados por losangos com o verbo que explica o fato.

Os losangos ficam entre os retângulos, ou seja, os relacionamentos ficam entre as entidades com as arestas ligando as entidades ao losango.

Grau do Relacionamento

Quando temos um relacionamento entre duas entidades, o número de ocorrências de uma entidade que está associado com ocorrências de outra entidade determina o Grau de Relacionamento ou Cardinalidade deste fato.

No exemplo da locadora: Um Filme pode ser locado por vários clientes? Um Cliente pode locar vários filmes? O mundo real apresenta-se com três possibilidades de relacionarmos os dados. Vejamos.

Grau do Relacionamento — Um-Para-Um (1:1)

Neste grau, cada elemento da entidade relaciona-se com um, e somente um, elemento de outra entidade. Por exemplo: No caso do relacionamento ESTÁ CASADO entre a entidade Homem e a entidade Mulher, teríamos o relacionamento Um-Para-Um. Pelo menos no Brasil é assim. O relacionamento deve ser lido nos dois sentidos: Um homem está casado somente com uma mulher e uma mulher está casada somente com um homem.

Grau do Relacionamento — Um-Para-Muitos (1:N)

É o grau mais comum no mundo real. Um elemento da entidade 1 relaciona-se com muitos elementos da entidade 2, mas cada elemento da entidade 2 somente pode estar relacionada a um elemento da entidade 1. No caso das entidades Homem e Mulher, basta nos deslocarmos para um país árabe para entender o proposto. Veja a figura.

Um homem pode ser casado com várias mulheres, mas uma mulher só pode ser casada apenas com um homem. Num sentido da leitura temos o grau Um-Para-Muitos (um homem para várias mulheres). No outro sentido temos o grau Um-Para-Um (uma mulher para um homem). Sempre que isso ocorrer entre duas entidades o grau de relacionamento é Um-Para-Muitos (1:N).

Grau do Relacionamento — Muitos-Para-Muitos (N:M)

Imagine uma faculdade. Um aluno cursa várias disciplinas e uma disciplina é cursada por vários alunos.

Nos dois sentidos da leitura encontramos o mesmo grau: Muitos-Para-Muitos.

Como Identificar o Relacionamento

Vamos direto a um exemplo. Observe a figura a seguir.

Segundo o modelo visto na figura anterior, Departamento lota um ou mais funcionários e um funcionário está lotado em um e somente um departamento. Um departamento possui um ou mais escritórios. Para que existam relações entre as entidades vamos criar dados comuns a elas. Observe a tabela a seguir.

Esta estrutura de dicionário possui os campos necessários à descrição de cada uma das entidades. No entanto, não conseguimos, a partir os dados acima, relacionar as entidades.

Com base na tabela anterior vamos trabalhar o primeiro relacionamento entre Departamento e Funcionário.

• Um departamento [1] Lota muitos Funcionários [N] — (1:N)
• Um Funcionário [1] está Lotado somente em um Departamento [1] — (1:1)

Existem dois graus distintos de relacionamento quando fazemos as leituras. Adotamos o grau maior como o efetivo do relacionamento, ou seja, consideramos que este é um relacionamento Um-Para-Muitos (1:N) onde o lado que ficar com a cardinalidade N (muitos) deverá ter um campo, em sua estrutura, idêntico a um campo da outra entidade, o qual é a chave primária nesta entidade.

No nosso caso, a tabela funcionários vai ter um campo a mais, visto que existem muitos (N) funcionários em um departamento. Este campo a mais que vamos criar é chamado de Chave Estrangeira. Dessa forma, vamos pegar a Chave Primária de Departamento e adicionar na entidade Funcionário.

Vejamos agora como fica a entidade Funcionário com esse novo campo:

Lembre-se: este campo utilizado como Chave Estrangeira deve ser na outra entidade a Chave Primária.

Um dado é colocado em uma entidade que em outra é o identificador unívoco (Chave Primária). Isso é uma lógica normal do mundo real. Por exemplo: a certidão de nascimento das pessoas que têm filhos possui o nome dos filhos? Não. É a certidão de nascimento dos filhos que possui o nome dos pais. Resumindo, dependentes indicam de quem dependem.

Se você pegar sua certidão de nascimento verá que tem seu nome (Chave Primária) e mais alguns dados: data de nascimento, hora de nascimento, local de nascimento, etc. Você poderá enxergar duas Chaves Estrangeiras em sua certidão (Nome do Pai e Nome da Mãe). Esses nomes, que são Chaves Estrangeiras em sua certidão de nascimento, são Chaves Primárias em suas próprias certidões. E o seu nome (que é Chave Primária na sua certidão) será uma chave estrangeira na certidão do seu filho.

Vamos agora resolver o relacionamento entre Departamento e Escritório, já que é necessário consultar quais escritórios são de um determinado departamento. Seguindo o mesmo raciocínio: entre Departamento e Escritório existe um relacionamento Um-Para-Muitos, portanto vamos incluir o campo principal da entidade Departamento na entidade Escritório. Veja como fica:

Observe que, em ambos os casos, temos relacionamentos Um-Para-Muitos:

• Um departamento [1] Lota muitos Funcionários [N] — (1:N)
• Um departamento [1] Possui muitos Escritórios [N] — (1:N)

Mas veja que nas tabelas acima colocamos os relacionamentos com a notação (1:1). Fizemos isso para mostrar que, do ponto de vista da entidade mais fraca, o relacionamento é este: 1:1. Observe:

• Um Funcionário [1] está Lotado em apenas Um Departamento [1] — (1:1)
• Um Escritório [1] Pertence a apenas Um Departamento [1] — (1:1)

Mas, e se precisássemos saber em qual escritório trabalha determinado funcionário? Podemos saber facilmente o departamento onde o funcionário está lotado. Isso já foi definido. Mas é impossível descobrir em que escritório ele trabalha.

Por que não relacionamos o funcionário ao escritório, em vez de relacionarmos ele ao departamento? Poderia ser uma boa ideia, visto que, se soubermos o escritório onde ele trabalha, forçosamente saberemos qual o departamento, já que os escritórios estão ligados aos departamentos.

Mas existe um porém: o funcionário pode pertencer a um departamento e exercer funções em um escritório que não pertence àquele departamento. Qual a solução? Para solucionar o problema vamos colocar o identificado único (Chave Primária) de Escritório na estrutura de Funcionário. Haverá então um relacionamento direto entre essas duas entidades.

Após esta inserção na estrutura Funcionários, temos:

• Um Departamento Lota muitos Funcionários;
• Um Departamento Tem muitos Escritórios e em um Escritório Atuam muitos funcionários.

Relacionamentos — Prática

Observe as tabelas abaixo e depois tente responder às perguntas que seguem.

• Quais os funcionários do departamento de vendas? Código do departamento de vendas = 10.
• Quais os funcionários que têm o código de departamento igual a 10? Pedro e João.

Quando chegarmos no tópico SQL veremos que o código funciona exatamente assim. A ideia é fazer “perguntas” ao banco de dados e receber as respostas através de registros.

Valor Nulo

Vamos recordar alguns conceitos:

• Chave Primária — é um campo que não se repete.
• Chave Estrangeira — é a Chave Primária em outra tabela relacionada, onde o nível de relacionamento é N (muitos).

O que seria o valor NULO? Para descobrirmos vamos criar uma situação.

Suponhamos que uma escola de informática precisa controlar quais professores pertencem a determinadas turmas. (Windows, Word, Excel). Existe apenas uma turma para cada Software. Teríamos as entidades Professor e Turma. (Veja a tabela a seguir).

Observe que existe um relacionamento Um-Para-Muitos (Um professor pode ensinar em várias turmas). Poderíamos ter apenas um professor para todas as turmas. No entanto, como existe apenas uma turma de cada Software, só pode haver uma turma por professor. Observe as tabelas preenchidas.

Pode existir um caso em que uma turma nova seja formada e o professor ainda não esteja definido. Neste caso o valor para o campo professor ficará NULO, mesmo que seja por apenas um período.

NULA é a informação desconhecida, é o dado não informado. Em banco de dados o campo tem valor NULO quando este dado não é obrigado de se informar, é opcional. Quando não informamos nenhum valor para ele, torna-se seu valor NULO. Em inglês: NULL.

Relacionamento Entre Múltiplas Entidades

O princípio de descoberta dos relacionamentos é analisarmos as situações onde as entidades se relacionam aos pares. No entanto, um relacionamento pode existir envolvendo mais de duas entidades, que podem ser três, quatro ou uma quantidade indeterminada. Observe na figura a seguir um relacionamento ternário.

Como fazer para descobrir a cardinalidade? Basta seguir os seguintes passos:

1 — Separar a entidade ALUNO e analisar o par PROFESSOR/DISCIPLINA. Para cada par PROFESSOR/DISCIPLINA podemos ter N ALUNOS relacionados.

2 — Separar a entidade PROFESSOR e analisar o par ALUNO/DISCIPLINA. Para cada par ALUNO/DISCIPLINA podemos ter um e somente um PROFESSOR relacionado.

3 — Separar a entidade DISCIPLINA e analisar o par ALUNO/PROFESSOR. Para cada par ALUNO/PROFESSOR podemos ter N DISCIPLINAS relacionadas.

Observações:

• Quando um aluno está matriculado em uma disciplina, este tem sempre um professor;
• Um aluno pode estar matriculado em várias disciplinas;
• Uma disciplina tem vários alunos e somente um professor;
• Um professor leciona uma disciplina para vários alunos.

Este relacionamento é ternário, pois envolve três entidades simultaneamente. Existem características interessantes e restritivas na leitura deste relacionamento:

• Um aluno em uma disciplina SEMPRE tem um professor;
• Uma disciplina com alunos SEMPRE tem um professor;
• Um professor com aluno SEMPRE tem uma disciplina.

Na figura observamos uma cardinalidade Muitos-Para-Muitos (N:M), tendo a terceira entidade envolvida, uma cardinalidade de Participação neste relacionamento também de muitos. Ou seja, um aluno pode ter vários professores e um professor pode ensinar vários alunos.

Embora existam três entidades, quando formos criar nossas tabelas no banco de dados, precisaremos de uma quarta tabela que “controlará” os relacionamentos. Observe a seguir como ficariam as estruturas das três entidades e do relacionamento obtido que chamaremos de CURSAM:

Preste bastante atenção. O relacionamento entre as entidades será “transformado” numa tabela quando formos criar o banco de dados.

Ao preenchermos as tabelas verificamos como funciona na prática o relacionamento. Observando a tabela de dados de relacionamento CURSAM, podemos ver que existem ocorrências de ALUNO que não figuram no relacionamento (Número_do_Aluno 124), assim como existem ocorrências de PROFESSOR que também não figuram (Código_Professor 12), e igualmente DISCIPLINA (Código_da_Disciplina D55), colocando a opcionalidade no relacionamento em relação às ocorrências de cada entidade.

No entanto, vemos que sempre que existe uma ocorrência no relacionamento, esta apresenta referência às três entidades, não existindo, por exemplo, nenhuma ocorrência somente com professor e disciplina.

Relacionamento Um-Para-Um — Curiosidade

Observe a figura a seguir.

Observe que através de uma Nota Fiscal remetemos apenas um Pedido solicitado e um Pedido só é remetido por uma única Nota Fiscal.

Que problemas poderiam surgir? Quanto a operacionalidade, o fato acima a restringiu, ou seja, um pedido nunca poderá ser entregue parcialmente, já que isso implicaria em associar-se a ele mais de uma nota fiscal. Por outro lado, uma nota fiscal jamais poderá remeter dois ou mais pedidos, pela mesma implicação.

Curiosidade: já que é um relacionamento Um-Para-Um, onde colocar a Chave Estrangeira? Pela lógica poderíamos colocar em qualquer um dos lados.

Como orientação de segurança e estabilidade, a sugestão é que se coloque a Chave Estrangeira no lado que tem a possibilidade de evoluir, no futuro, para uma cardinalidade Muitos.

Erros de Interpretação

Muitas vezes ocorre de haver uma interpretação errônea ao analisar a realidade. Vejamos um exemplo clássico de Controle de Estoque.

Muitos criam uma entidade chamada Estoque para relacionar-se com outra entidade chamada Produto. Define-se um relacionamento Um-Para-Um. Existe um probleminha aí: as duas Entidades têm duas chaves primárias idênticas. Se observarmos com mais atenção chegaremos à solução correta.

Se dado um produto, este possui somente uma quantidade em estoque, considerando que esta quantidade representa o quanto temos do produto na empresa. O atributo quantidade em estoque é, na realidade, nada mais do que um campo ou atributo da entidade Produto. Não é necessário um relacionamento 1:1.

Agregação e Cardinalidade

Existem ocasiões em que ficamos em dúvida de como representar um fato que está relacionado a outro fato. No entanto, conceitualmente, não existem relacionamentos entre fatos, isto é, não existem relacionamentos entre relacionamentos. O que existe, na verdade, são relacionamentos dependentes de outros, que somente existem após a ocorrência do outro, considerado fundamental. Vamos estudar a situação mostrada na figura a seguir.

Existe um relacionamento Muitos-Para-Muitos entre a entidade Funcionário e a entidade Projeto.

Um funcionário atua em muitos projetos e um projeto tem trabalhando nele muitos funcionários. Quando um funcionário está trabalhando em um projeto, ele pode utilizar uma ou nenhuma máquina para a realização de suas atividades. Temos então uma situação de um evento decorrente de outro, sendo que a ocorrência do segundo evento é opcional. (O funcionário pode ou não usar uma máquina).

Uma máquina pode estar sendo utilizada por diversos funcionários atuando em projetos. Como devemos tratar essa situação?

Vamos tentar “ler” a situação: um Funcionário Atuando em Um Projeto caracteriza uma ocorrência de Alocado, e esta ocorrência utiliza uma ou nenhuma Máquina, por outro lado uma Máquina pode ser utilizada por “n” Funcionários Atuando em Um Projeto.

Termos então um relacionamento de Um-Para-Muitos entre Máquina e a visão de Funcionário Alocado em Projeto.

Vamos observar o dicionário de dados.

Observação: Parcial indica que o campo pode ou não ser preenchido. Total que o campo deve ser preenchido.

Este caso de agregação apresenta a decomposição de um relacionamento em dois, pois sempre encontramos dois eventos ocorrendo, sendo um dependente do outro. Funcionário Utiliza Máquina, “quando” Alocado a Projeto. Sempre que nos depararmos com um relacionamento envolvendo mais de duas entidades, devemos questionar as entidades que se ligam em um relacionamento básico, através da questão: Quando ocorre o fato?

Observe a figura a seguir:

Consegue notar a diferença? Só podemos utilizar agregação quando temos um relacionamento principal (A) Muitos-Para-Muitos, que representa um fato, pois do contrário a terceira entidade envolvida estará relacionada sempre com uma das entidades em questão.

No caso dos funcionários alocados em projetos usando máquinas, vamos supor que um funcionário só pode trabalhar em apenas um projeto. Se um funcionário trabalha em apenas um projeto, a máquina ou máquinas que ele utiliza estão relacionadas diretamente a ele. Observe a figura a seguir.

Relacionamentos Entre Fatos Independentes

Já vimos que existem relacionamentos entre fatos dependentes ou, melhor dizendo, há um relacionamento que existe por causa de um outro que vai ocorrer e depende deste. No entanto, existem ocasiões em que dois blocos do modelo parecem não estar relacionados, e no final das contas estão. Observe os diagramas:

A figura apresenta dois blocos distintos com relacionamentos Muitos-Para-Muitos em cada um expressando fatos do mundo real.

O fato número 1 retrata a situação onde um médico atende a muitos pacientes e um paciente faz consultas com muitos médicos.

O fato número 2, aparentemente dissociado, representa uma clínica que atua (ou está situada, tem muitas filiais) em muitos locais, sendo que em um local (numa cidade, por exemplo) atuam muitas clínicas.

E se eu quiser saber em que Local e Clínica foi realizada determinada Consulta? Vejamos como isso ficaria representado.

Podemos então observar que uma Clínica Atua em muitos Locais, quando uma Clínica Atua em um Local Realiza muitas Consultas, isto é, Médico Atende Paciente.

Parte 2 — Considerações Finais

Nessa segunda parte entramos na toca do coelho e descobrimos muitas coisas sobre como modelar um banco de dados.

O primeiro passo é a compreensão da realidade. É com essa compreensão que vamos achar as entidades e os relacionamentos entre essas entidades.

Aprendemos conceitos importantes, tais como: chave primária, chave estrangeira, condicionalidade, grau do relacionamento, valor nulo, cardinalidade, etc.

Essa parte deve ser lida e relida até que todos os conceitos vistos aqui sejam absorvidos. Ela abre as portas para a criação dos modelos que você fará no dia a dia.

Continua na parte 3

T2Ti ERP — Aprenda a Desenvolver um ERP

O T2Ti ERP 2.0 é feito em C#, Delphi, Java (RIA e Web) e Lazarus. São cinco projetos diferentes. Que tal aprender a desenvolver esse ERP totalmente grátis? Parece bom?

Acompanhe o canal da T2Ti no Youtube. A T2Ti está postando todos os vídeos do T2Ti ERP 2.0 no Youtube. São quase 300 módulos!

Os vídeos estão organizados em Playlists. Então se inscreva no canal e ative o sininho para receber atualizações sobre as postagens.