Paulo Eduardo

Continnuando a falar sobre o Diagrama Entidade Relacionamento, nesse post vamos explicar as chaves primarias, estrangeiras e terminar nosso exemplo da locadora.

As Chaves Primarias são o atributo identificador da identidade, por isso sao únicos, ou seja não se repetem, e geralmente sao sequenciais, ou, como são chamados no SGBD, auto-increment, pois caso um atributo seja setado como auto-increment o propeio SGBD se incarrega de, caso um nova linha seja iserida a essa tabela utilizar o numero inteiro positivo imediatamente apos o ultimo utilizado. porem outros dados podem ser usados como chave primaria, como RG e CPF para cadastros pessoais e CNPJ para cadastros de empresas, pois já se sabe que esses atributos respeitam a condição de serem unicos.

Como já foi dito a representação das chaves primarias no DER e feita pelo circulo cheio seguido do nome do atributo identificador, porem na representação usado pelo DBDesigner as chaves primarias são mostradas com um desenho de chave ao lado esuqerdo do nome do atributo identificador, dentro da entidade.

Ainda existe a possibilidade de existirem chaves primarias compostas, ou seja, formadas por dois ou mais atributos, como acontece frequentemente nas entidades fracas, assim como na entidade fraca mostrada na parte anterior, nesse caso a combinação entre todas as chaves primarias não pode se repetir, porem as chaves primarias isoladamente podem se repetir.

Chaves estrangeiras são o elo de ligação entre as entidades, quando ocorre um relacionamento as chaves estrangeiras são “importadas” de uma entidade para outro, por exemplo, na ultima figura da parte anterior, no relacionamento entre cliente e aluguel a chave primaria de cliente é importada pela entidade aluguel, mostrando que aquele aluguel foi feito pelo client.

Porem como saber de que lado será colocado a chave estrangeira? É simples, num relacionamento 1-1 a chave estrangeira pode ficar em qualquer um dos lados, porem no caso de uma entidade para dados opcionais como foi dito anteriormente é recomendavel que a chave estrangeira esteja na entidade com os dados opcionais e nao na entidade com os dados obrigatorios, pois no caso de nenhum dado opcional ser inserido não ha necessidade de criação dessa chave estrangeira.

Já no relacionamento 1-N a chave estrangeira deve ficar do lado N, como no exemplo de clientes e alugueis, onde cada cliente pode fazer varios alugueis, a chave estrangeira fica na entidade alugueis (repare nonvamente no uso da palavra “cada”). Já no caso de relacionamento N-N, onde ocorre a criação de uma entidade fraca, as chaves estrangeiras ficam nessa entidade fraca, formando uma chave primaria composta, sim, é isso mesmo, a chave primaria é formada por duas chaves estrangeiras.

Com essas informações você já é capaz de realizar a sua propria documentação de banco de dados, porem nosso exemplo ainda está incompleto, faltando a seção de reserva de filmes, mostrada na figura abaixo:

Como havia dito na segunda parte da serie, nessa terceira parte iremos falar sobre como relacionar uma entidade com a outra os casos de relacionamento e como identificar cada um.

O relacionamento entre as entidades é reprentado por uma reta ligando as duas entidades com um losango localizado no centro dessa reta.

Seguindo nosso exemplo anterior um cliente, seja ele pessoa física ou jurídica, realiza locações de fitas de video ou DVD, cada locação tem sua identificação e e um atributo data, representando a data de retirada portanto a representação grafica disso, complementando a representação anterior ficaria dessa forma:

Com já havia sido falado, um losango faz a ligação entre as entidades relacionadas, porem a um detalhe que ainda não foi expllicado, a cor de cada uma das metades desse losango, essa divisão de cores representa o tipo de relacionamento entre as entidades.

No caso da locadora, cada cliente pode realizar varios alugueis, porem cada aluguel é feito por apenas um cliente (repare o uso da palavra “cada” que auxilia bastante na hora de classificar os relacionamento). Essa represntação e feita pelo DBDesigner, colorindo a metade chamada de ‘muitos’ de preto, ou seja, como cada cliente pode realizar muitos alugueis, o lado dos alugueis fica com a metade preta do losango, enquanto, como cada emprestimo e realizado por apenas um cliente, por isso a metade branca do losango aponta para a entidade cliente.

Porem essa representação é um pouco diferente da representação padrão onde teriamos algo assim:

Nessa imagem foram omitidos os atributos de cada entidade.

Como você pode ver ao inves de colorir os losangos indicando o tipo de relacionamento, em cada entidade é colocado um conjunto composto por dois caracteres entre virgulas, o primeiro caracter antes da virgula mostra o minimo do relacionamento, e o caracter apos a virgula o maximo do relacionamento.

No nosso exemplo, cada cliente pode fazer no minimo 1 e no maximo N (muitos) alugueis (1,N) e cada aluguel é realizado por no minimo 1 e no maximo 1 cliente (1,1). Essa metodologia mostra tanto o minimo quanto o maximo de um relacionamento, enquanto o DBDesigner só demonstra o maximo.

Alguns de voces podem estar pensando que um cliente pode ter um cadastro na locadora e nunca ter alugado nenhum filme, realmente isso pode acontecer, o que mudaria o minimo para 0 ao inves de 1, mas isso dependeria do modo como a locadora trabalha o cadastro de clientes, dado esse que deve ser levantado junto ao cliente em cada caso.

Apesar da metodologia padrão usar o minimo e o maximo, o mais importante num relacionamento é o seu maximo, que vai definir em qual das duas entidades será colocada a chave estrangeira, que faz a ligação entre as duas entidades no SGBD.

Mas antes de explicar as chaves estranjeiras vou mostrar todos os tipo de relacionamentos possiveis e uma explicação sobre eles:

Relacionamento 1-1

Esse relacionamento ocorre quando ambas as entidades se relacionam com maximo 1 para com a outra, não é um relacionamento muito usado já que na maioria dos casos quando uma entidade se relaciona dessa forma com a outra elas podem ser fundidas em apenas uma entidade, porem em alguns casos pode-se guardar infomaçoes opcionais sobre uma entidade em outra entidade, evitando assim que uma tabela de banco de dados tenha muitos atributos com valor nulo, caso todos esses valores opcionais fossem nulos não haveria nem a necessidade da criação de uma nova linha na entidade que porta esses dados opcionais

Relacionamento 1-N

É o tipo de relacionamento mais usado em banco de dados relacionais ocorrendo com o relacionamento maximo de uma tabela para outra é 1 e na ordem inversa é N, sendo esse o que foi usado no exemplo anterior e explicado atravez dele

Relacionamento N-N

Ocore quando ambas as entidades se relacionam com no maximo N para com a outra, nesse caso ocorre a criação de uma entidade fraca entre essas entidades para guardar o relacionamento entre essas duas atravez de suas chaves extrangeiras, no exemplo da locadora esse relacionamento pode ser encontrado no relacionamento entre alugueis e filmes representado abaixo:

Como se pode perceber, o DBDesigner transforma altomaticamente um Relacionamento N-N em dois relacionamento 1-N, a entidade fraca possui somente os ID`s das duas entidades com as quais se relaciona, porem pode ter outros atributos tambem.

No proximo topico iremos falar sobre Chaves Primarias e Estrangeiras e terminar nosso exemplo.

Como prometi no artigo anterior, vamos ao exemplo:

O primeiro passo para definir um banco de dados é encontrar no seu levantamento as entidades que o compões, no caso da locadora citada no artigo anterior elas são: cliente (pessoa fisica ou juridica), filmes, aluguel, e reserva. Em seguida definimos os atributos de cada entidade, os atributos são os dados que ficaram salvos sobre cada entidade.

Vamos usar o exemplo de clientes: os clientes tem nome, endereço, telefone e etc, porem no caso de clientes, alguns possuem CNPJ e outros CPF, por isso nesse momento é necessário o uso da especialização, como mostra a img abaixo:

Como vocês podem ver a simbologia utilizada pelo DBDesigner é um pouco diferente da teoria apresentada, mas em resumo, os atributos sao colocadas dentro da entidade, juntamente com o tipo de dados que sera utilizado para esse atributo, e o triangulo que representa uma especialização é representado por uma seta apontando da especialidade para sua entidade generalizadora.

Usando a metodologia padrão representariamos da seguinte forma:

Na proxima parte veremos como relacionar uma unidade com a outra, os casos de relacionamento e como identificar cada um.

Depois de um tempo sem escrever, envolvido com um projeto, vou voltar a falar sobre a documentação de projetos como havia prometido terminar a serie, só espero que esses tempinhos longos sem aparecer não se tornem frequentes.

Como proximo tema da serie temos o DER, ou Diagrama Entidade Relacionamento, velho conhecido dos administradores de banco de dados e de muitos desenvolvedores que utilizam bancos de dados relacionais em sua aplicações.

Em equipes e projetos grandes o o profissional responsavel pela construção de DER`s é o DBA porem em projetos pequenos e com poucos profissionais essa tarefa geralmente acaba nas mãos do programador.

Tambem existem varios softwares que facilitam o trabalho de diagramação do banco de dados, as imagens que vocês veram aqui são screenshots do DBDesigner que é o software de minha preferencia, outro software que tem recursos para tanto é o MS Visio, porem até mesmo softwares de imagens como Photoshop e Fireworks, e até mesmo o Paint podem ser usados, claro que para usar esse ultimo é necessario um pouco mais de, digamos, paciencia.

O DER é a representação grafica do MER, sendo representado por um conjunto muito pequeno de simbolos, o retangulo, representando a entidade, de onde saem pequenos traços com circulos em sua ponta para cada atributo dessa identidade, sendo que o circulo escuro representa a chave primaria dessa identidade, um losango, ligando atraves de retas duas entidades representando seu relacionamento e um triangulo representando as especializações de determinada entidade.

Apesar de parecer algo simples de desenhar, o DER consegue representar nesses poucos simbolos a estrutura completa de todo o banco de dados que será usada em determinada aplicação, mas para entender-mos melhor vou usar de exemplo um banco de dados simples para representar uma video locadora que loca filmes para clientes pessoa fisica e pessoa juridica armazenando nesse banco de dados as informações sobre reserva e alugueis realizados, mas isso você só vai ver no proximo post.