• Nenhum resultado encontrado

Modelagem de Atributos (Modelagem Lógica)

No documento Banco de Dados - Projeto e Implementação.pdf (páginas 109-116)

Quando estamos trabalhando com entidades e relacionamentos, devemos manter os princípios relacionais e suas regras de integridade, a integridade de identidade e a integridade referencial, pois as nossas entidades vão se transformar em tabelas relacionais e devemos visualizá-las como tais no modelo lógico.

A partir deste momento vamos iniciar a utilização também da notação gráfica para modelo ER lançada por Gordon Everest, em 1986, que elimina o losango que representa o relacionamento e simplesmente escreve sobre a linha que une as entidades a nomenclatura do relacionamento, além de utilizar os famosos "pés de galinha" para identificar a conectividade de cada lado de um relacionamento. Vamos manter ainda em conjunto a notação de Chen por ser em alguns casos mais claro o seu entendimento.

A razão para apresentarmos este outro tipo de notação justifica-se, como já citamos, pelas ferramentas CASE que dela se utilizam em sua grande maioria.

Outra característica desta notação é que, seguindo alguns preceitos de Rumbagh, os modelos apresentam no interior do retângulo da entidade a relação dos atributos que o descrevem, inclusive com suas chaves primárias em destaque. Na parte superior da caixa da entidade estão os atributos que compõem a chave primária, e os outros atributos na parte inferior da caixa, sendo destacadas as chaves estrangeiras como FK (foreign key).

Observe que o mesmo modelo anterior agora possui somente uma linha pontilhada entre as duas entidades, explicitando o relacionamento.

Como utilizamos um software CASE para este exemplo e não demos nome ao relacionamento, o software inseriu um código (R/18) para representar tal relacionamento.

Outra característica que se pode perceber é que, além das chaves primárias das entidades, o modelo apresenta as chaves estrangeiras, que realizam a efetivação lógica do relacionamento em banco de dados relacional, transformando o modelo conceitual em modelo lógico.

Este símbolo de mínimo zero indica que o relacionamento é opcional no sentido em que apresenta o símbolo.

O importante a destacar é que todas as entidades que modelamos não possuem chave estrangeira no mundo real. Ela é colocada para que se possibilite a efetivação lógica dos relacionamentos de acordo com os princípios relacionais.

Da mesma forma nem todas as entidades que serão encontradas possuem chave primária evidente, sendo muitas vezes necessária a inserção de um atributo código, como realizamos em departamento.

É importante a modelagem de atributos de chave primária, pois eles nos fornecem as restrições lógicas do mundo real para a existência das ocorrências de uma entidade.

Em seguida apresentamos um modelo ER maior para exercitar seu entendimento, pois apresentamos o problema em si e a solução adotada com um modelo ER.

O Problema

Um negócio imaginário que chamaremos de softball compreende a participação de clubes de softball em diversos campeonatos que são realizados por confederações.

Cada clube pertence a uma confederação somente, entretanto participa de campeo- natos de todas as confederações.

Nesse negócio as pessoas são os jogadores ou os organizadores dos campeonatos. Um campeonato tem muitos jogos.

Um campeonato pode ser organizado por mais de uma confederação. Elas podem realizá-lo em conjunto.

Desculpe se isso parece com o futebol brasileiro, mas não era este o objetivo.

O mesmo modelo visto sob a perspectiva da notação de Chen ficaria como na figura apresentada em seguida.

Interpretando o modelo, é importante que façamos a leitura dele.

Utilizamos nesta solução os conceitos de generalização e especialização, inserindo uma entidade pessoa que engloba tanto jogadores como organizadores, uma vez que permi- timos assim que alguns dos jogadores também sejam organizadores de uma confederação.

 Um jogador atua em muitos clubes.  Um clube tem muitos jogadores.

 Um organizador organiza uma confederação somente.  Uma confederação é organizada por muitos organizadores.  Uma confederação organiza muitos campeonatos.

 Um campeonato é organizado por muitas confederações.  Um clube é filiado a uma e somente uma confederação.  Uma confederação tem como filiados muitos clubes.  Um clube joga muitos jogos.

 Um jogo é jogado por muitos clubes (máximo 2).  Um clube participa de muitos campeonatos.  De um campeonato participam muitos clubes.

Uma crítica que o modelo ER sofre é que restrições de número máximo nos relaciona- mentos não são expressas.

Existe uma notação que utiliza a expressão dos valores máximos e mínimos em cada lado do relacionamento, deixando assim mais expressivas essas restrições. Lamenta- velmente as ferramentas CASE mais conhecidas e utilizadas no mercado não implementam essas possibilidades.

Exemplo

Agora ficam claras as limitações em cada relacionamento:

 Um clube pode ter no mínimo 15 e no máximo 25 jogadores inscritos.  Um jogador só pode estar inscrito em um e no máximo em um clube.

 Uma confederação é organizada no mínimo por um organizador e no máximo por quatro organizadores.

 Um jogo é jogado por no mínimo duas e no máximo duas equipes.  Um clube participa de nenhum ou no máximo de dois campeonatos.  Um campeonato tem no mínimo cinco clubes e no máximo quinze clubes.

 Uma confederação organiza nenhum ou no máximo três campeonatos, que são organizados por no mínimo uma ou no máximo duas confederações.

Vamos então ao modelo lógico desta solução com a visualização dos atributos e das chaves primárias e estrangeiras existentes no modelo.

Importante agora é observar que o modelo de dados possui a identificação de chaves primárias e chaves estrangeiras que efetivam os relacionamentos em um ambiente relacional.

Apresentamos até este ponto a necessidade de incluirmos campos na estrutura de dados das entidades para que se efetuem os relacionamentos, ou seja, existem campos comuns para a ligação.

Quando um campo em uma entidade caracteriza-se por ser a chave de identificação única de ocorrências dessa entidade, denomina-se, como já vimos no ambiente relacional, chave primária.

Quando em uma entidade temos um campo, que é chave primária de outra entidade, temos então a chave estrangeira dessa entidade.

Essa ligação realiza-se por comparação do valor da chave estrangeira de uma entidade com o valor da chave primária de outra entidade.

Ora, isso fornece uma expressão lógica, de comparação de valores, que explicita e estabelece uma regra para o relacionamento entre as duas entidades:

Por exemplo:

 Nome do clube em clube = Nome do clube em pessoa Esta é uma expressão de efetivação lógica de um relacionamento.

Se desejarmos saber o nome das pessoas que jogam em um clube específico, basta informarmos o valor do nome desse clube para que sejam selecionadas todas as ocorrências de pessoas cujo campo NomeClube seja igual ao valor informado.

Este é um processo de seleção, ou melhor, uma operação de projeção e seleção relacional sobre o relacionamento entre a entidade clube e a entidade pessoa.

π

Nome_pessoa (CLUBE • Clube.NomeClube = Pessoa.NomeClube PESSOA)

Veja só, já estamos navegando em um modelo de dados. Mas vamos aprender isso especificamente em álgebra relacional.

Vamos observar agora as tabelas seguintes, que simulam o conteúdo das duas entidades.

Entidade: Departamento

Código Departamento Nome Departamento Verba

01 Contabilidade 500,00

10 Vendas 1.000,00

21 Faturamento 250,00

Entidade: Funcionário

Código Nome Data Admissão Código Depto

0111 João 12/11/90 01 0112 Antônio 12/12/91 01 0271 Carlos 05/06/91 10 0108 Eduardo 03/03/90 10 0357 Luís 20/10/91 10 0097 Vera 15/02/92 21

Como estas tabelas que representam as duas entidades possuem chaves primárias e estrangeiras, conforme o modelo seguinte, podemos responder às questões:

Quais são os funcionários do departamento de vendas?

Em segundo lugar é preciso saber quais funcionários que têm código de departamento igual a 10.

Resposta= "Carlos, Eduardo e Luís."

Logo, a existência no modelo lógico de chaves primárias e chaves estrangeiras possibi- lita a recuperação de informações e efetiva logicamente os relacionamentos.

Gostaríamos de salientar que a preocupação tem sido sempre nos orientarmos para recuperar informações combinadas, não dando ênfase neste momento à inserção, manutenção ou deleção de dados, aspectos que vamos comentar adiante no livro, mas são elementos que auxiliam na descoberta do contexto e sua consolidação.

Para um bom trabalho de modelagem devemos esquecer essas operações comenta- das, preocupando-nos somente com os dados em si, não nos importando com procedimentos que serão inerentes ao sistema como um todo.

Na realidade, quando modelamos, não pensamos em sistemas, e sim em conseguir obter o entendimento de um negócio ou problema, estruturando os dados desse problema com vistas ao seu domínio e sua solução.

Para que se solidifiquem os conceitos de uma técnica, não é suficiente apenas a apresentação de um exemplo de situação e sua aplicabilidade; pelo contrário, a massificação de casos analisados é que nos dá a possibilidade de ter segurança no conhecimento adquirido. A visualização de uma massa de casos tem por objetivo, além da solidificação de uma cultura, propiciar diversidade de situações de análise.

Entendemos que quanto mais situações passarmos com esta publicação, maior fonte de consulta o leitor terá para a sua vida profissional.

No documento Banco de Dados - Projeto e Implementação.pdf (páginas 109-116)