Modelagem de Dados, Notas de estudo de Processamento de Dados

Baixe Modelagem de Dados e outras Notas de estudo em PDF para Processamento de Dados, somente na Docsity!

MMOODDEELLAAGGEEMM DDEE

D

D

a

a

d

d

o

o

s

s

Guia de Estudo

Paulo Rocha Neto

Know How

São Luís



Maranhão



2007

Projeto de Software Paulo Rocha Neto

Dados e Realidade

Um dos aspectos mais importantes a ser observado pelos projetistas de Bancos de Dados e seus pares da administração de dados é que projetar um Banco de Dados é, na realidade, um intrigante exercício de simulação de um pedaço do universo da empresa. Para isso, dispomos de um conjunto tipo "lig-lig" de estruturas, símbolos, caixas e setas que, montados como num jogo de "Lego", formam uma linguagem reconhecida e digerível pelo computador. Essa simulação visa, na realidade, transformar a nuvem esquisita, amorfa e semanticamente ambígua que representa a realidade de dados e processos da empresa, em losangos e retângulos que ilustram as linguagens gráficas disponíveis nas ferramentas e metodologias de hoje. A essa técnica, de escultura quase semântica, chamamos de Modelagem de Dados. Gradativamente refinada pela prática, a Modelagem de Dados foi desenvolvida ao longo dos anos 70 e possui uma paternidade discutível. Em suas origens são encontrados DNA de Charles Bachman, James Martin, Peter Chen e outros, mas é desse último, o rótulo MER (Modelo de Entidades e Relacionamentos) que se transformou em quase sinônimo da técnica. As técnicas de Modelagem são usadas para registrar os dados nos mais diferentes níveis de abordagem (de planejamento estratégico de negócios a modelo lógico de implementação). Essa, aliás, é uma das primeiras indagações normalmente surgidas num processo de Modelagem de Dados de uma empresa ou de parte dela: o seu nível de abrangência horizontal e de profundidade vertical. Até onde se estendem os limites elásticos da modelagem de dados? Isso acontece justificado pelas características fluídicas apresentadas pelos dados, o que os levam a habitar diferentes regiões funcionais da empresa, normalmente atrelados a processos diferentes e, por vezes, encapados por sentidos e interpretações até, conflitantes. Não é à toa que esse conjunto de objetos semânticos tem o nome de "entidades" e, parece, que sua correlação com os correspondentes do sincretismo religioso não é mera coincidência.

Como o objetivo da modelagem é dar fidelidade à representação das "coisas do mundo" através do computador, as fronteiras de seus conceitos não são rigorosamente definidas. Isso confere à Modelagem de Dados um sabor muito mais de arte do que tonalidade de ciência exata. Os dados podem demonstrar toda essa sua elasticidade polimórfica (assumir várias formas), dependendo do contexto e das regras de negócio que os envolvem. Suponha, por exemplo um Banco de Dados genérico, onde a Entidade PESSOA seja o objeto maior. Essa Entidade PESSOA seria uma classe e teríamos várias subclasses para caracterizar suas peculiaridades. Um dos relacionamentos que certamente apareceriam nesse modelo seria o tipo de interações entre elas (as pessoas). Usei a palavra interação para não usar a palavra óbvia "relacionamento", pois vários tipos de relacionamentos aparecerão, como: casamento, filiação, apadrinhamento etc. Ou seja, CASAMENTO é um relacionamento entre pessoas. Razoável não? Teria dados de data, padrinhos etc. Agora, imagine o modelo de dados de um Cartório, onde desejo um sistema que controle todos os tipos de REGISTROS CÍVEIS (casamento, divórcio, morte etc.) efetuados. Certamente, agora, CASAMENTO poderia ser visto como um dos tipos de Entidades de Dados (Registro) que surgiria no modelo de dados. Ou seja, às vezes, Entidades e Relacionamentos não possuem fronteiras rígidas. Os conceitos de Entidades de Relacionamento ou Associativas, a serem discutidos nos capítulos específicos, foram cunhados exatamente para esse propósito, No fundo esses objetos darão origem a registros no momento de implementação (considerando os atuais Gerenciadores de Bancos de Dados) e aí somem todas as diferenças conceituais - Os modelos de dados estendidos cada vez mais buscam aprimorar essas representações semânticas, conforme também será discutido mais adiante.

A finalidade da modelagem de dados, que diferentemente do Brasil é para principiantes, é pavimentar esse caminho nada retilíneo e ajudar na garimpagem desses elementos e suas abstrações. Hoje, todas as linhagens metodológicas em prática, visando ao desenvolvimento de sistemas de informação, usam a análise e modelagem de dados como processo fundamental para compreensão dos dados e de sua complexa personalidade.

Extraído de: Barbiere, Carlos – Modelagem de Dados – Rio de Janeiro: Infobook, 1994.

Modelagem de Dados

Modelagem de Dados é uma atividade desenvolvida em fases variadas do processo metodológico de desenvolvimento de sistemas, com a finalidade de garimpar informações para a obtenção do modelo de dados. Um modelo de dados a nível macro pode ser obtido em fases de planejamento, por exemplo, enquanto modelos de dados detalhados podem ser obtidos em fases de análise e projeto. Tudo depende do foco que se deseja aplicar ao trabalho de levantamento e seus objetivos.

1 O Modelo de Dados

Modelo de Dados é a representação gráfica e textual das ESTRUTURAS, dos OPERADORES e das REGRAS que definem dados. As Estruturas são formadas de:

• As Regras são asserções que regulam o funcionamento dessas estruturas.
• Os Operadores, embora equivocadamente não considerados como parte dos modelos de dados, são os comandos que permitem a manipulação das estruturas segundo as regras estabelecidas. Os operadores não serão objetos diretos desse texto.

2 Como obter um Modelo de Dados

Existem várias abordagens que conduzem à obtenção e cristalização dos Modelos de Dados e dependem do "pedigree" metodológico adotado. As principais são:

• Decomposição funcional;
• Análise das regras de negócios;
• Análise de eventos.

2.1 Decomposição Funcional

A obtenção dos modelos de dados pela decomposição funcional se dá pela análise da hierarquia de Funções- Processos-Atividades. Nessa abordagem, a identificação de entidades externas, ou de depósitos de dados relacionados a cada processo, sugere entidades de dados que comporão o modelo. Essa abordagem foi muito usada nas metodologias iniciais embasadas na Análise Estruturada Convencional e não será detalhada nesse trabalho. A Análise Estruturada Convencional, promotora da decomposição funcional, está sendo modernizada pelos conceitos de Eventos trazidos pela Análise Essencial.

2.2 Análise de Regras de Negócios

Uma das áreas mais florescentes dentro da esfera que analisa dados, processos, objetos e suas correlações é o estudo das Regras de Negócios. Esse componente, que juntamente com as Entidades, os Relacionamentos e Atributos, forma o quarteto básico para a garimpagem de dados que suportam os negócios da empresa, vem ganhando aceitação crescente nas abordagens metodológicas. A idéia é aprofundar a prospecção em cima dessa, que é a mais fluídica das quatro integrantes citadas. O seu pleno entendimento e o seu registro mais formal vem ganhando interesse, promovendo debates e produzindo novos conceitos. O livro The Business Rule Book:Classifying, Defining and Modelíng de Ronald Ross, publicado em 1994 é a mais recente Bíblia do assunto. A grande e intrigante questão sobre o assunto é talvez aquela que deveria ser a mais óbvia. O que é regra de negócio e como expres¬sá-la formal e adequadamente de maneira a torná-la um conceito gerencial útil? A sua definição, como todo conceito sem paternidade definida, é hoje ambígua e sem fronteiras rigorosas. A indústria de softwares e metodologia, provavelmente por não ter ainda entendido o seus contornos, não se arvorou em padronizá-la e passa ao largo da sua utilização. A definição de regras de negócios (RN) possui vários ângulos. Alguns consideram as regras de Entidades como sua mais perfeita tradução. Outros citam as regras de opcionalidade e cardinalidade de relacionamento, tão usuais em modelagem de dados, como exemplos bem acabados de RN. Outros entendem que as regras de Domínio de atributos são mais ajustadas ao figurino RN. Outros apostam que as RN são mais válidas quando se referem a regras de inferência, como If condição then ação. Na realidade RN é de tudo um pouco.

Seria RN mais uma ação da velha e indivisível indústria do vocábulo e da consultoria, como sempre engenhosa e criativa, induzindo ações modernas através da reembalagern de conceitos antigos?

2.3 Análise de Eventos

Com o surgimento das ferramentas Case nos anos 80, os conceitos de análise estruturada, aplicados à confecção de sistemas, puderam ser efetivamente testados nas bancadas práticas dos CPD. Nesses ambientes, diferentemente dos paraísos teóricos onde foram concebidas, essas técnicas tiveram que provar a razão de seu intrigante magnetismo. Dessa forma passaram a ser consumidas pela área de Informática, até atingirem um estágio de maturação normalmente presente nessas manifestações metodológicas. De um lado surgiram as famosas metodologias definidas pelo rótulo de Engenharia de Informações, produzidas pela esperteza de alguns consultores, que com um "label" estratégico (engenharia) conferiam uma característica eminentemente técnica a algo que sempre fora considerado produto de certa inspiração. Do outro lado, apareceram as abordagens capitaneadas pelo sucesso de "best-sellers" do tipo Gayne-Sarson, Yourdon, Jackson etc. que se convencionou chamar de Análise Estruturada, pura e simplesmente. Essas duas linhagens metodológicas, inicialmente divergiram entre si, com relação a dicotomia dados-processos já discutida anteriormente. Como visto, bastou pouco tempo para que as novas versões dessas metodologias buscassem o equilíbrio desejado entre esses dois ingredientes fundamentais. Isso provocou o que seriam os primeiros sintomas dessa convivência pacífica, que hoje os objetistas (nova classe emergente) rotulam de encapsulamento. No lado dos processistas, avanços significativos aconteceram, e o principal deles, além do equilíbrio com os dados, foi a lanternagem oferecida pelos propositores da chamada Análise Estruturada Moderna, ramo que surgiu calcado em idéias publicadas em alguns livros (Yourdon, Macmenamin, Palmer e Ward), e que pode ser interpretada como a nova geração da Análise Estruturada.

No afã de evitar identificação com as imperfeições do passado, os propositores matreiramente denominaram essa nova abordagem de Análise Essencial. A justificativa se deu pelo seu dedicado e exclusivo interesse pela "essência" do sistema, independentemente dos aspectos da implementação que, erradamente, costumam ser considerados em fases conceituais do projeto. Na realidade, percebeu-se nas entrelinhas mais uma recaída da conhecida indústria do vocábulo, engrenagem virtual e operativa pilotada por empresas e consulto rés, cuja finalidade é cunhar novos termos (modelo essencial, modelo de encarnação, blitzing etc.) para definir coisas, que de certa forma já conhecemos e praticamos (talvez com ligeiras variações). A indústria do vocábulo se aproveita das marés de modismos que sempre atingem a nossa praia (área de Informática) produzindo o consumo de tecnologias variadas que têm invólucros diferentes mas o recheio de mesmice.

No fundo, as diferenças entre a Análise Estruturada Convencional (AEC) e a Análise Estruturada Moderna (AEM) ou Análise Essencial podem ser sin¬teticamente definidas por conta de dois pontos básicos:

• Abordagem por eventos.
• As técnicas de JAD.

2.3.1 Abordagem por Eventos

Com essa proposta, a AEM sugere uma cambalhota na famosa abordagem "Top-Down" transformando-a em "Middle-down/Middle-up". Isso sig¬nifica que, ao invés de se iniciar o desenho do sistema pela clássica decomposição de funções/processos/atividades, propõem-se um exercício de descoberta de eventos, como ponto de partida da técnica.

Eventos são definidos como os fatos que provocam estímulos, para os quais os sistemas deverão conter processos de resposta. Eles podem ser originados externamente por fluxos (Figura 2,3) ou internamente por um mecanismo temporal de disparo (Figura 2.4). Essa tática dribla de forma desconcertante as tediosas dissecações funcionais propostas originalmente, podendo produzir processos (num patamar intermediário) que poderão, se necessário, ser decompostos ( middle-down) ou agregados ( middle-up), dependendo de sua granularidade. Segundo os seus propositores, o particionamento por eventos oferece um conceito também mais objetivo, por fugir dos aspectos protocolares existentes nas definições de funções/processos/atividades. Tal objetividade se concretiza na medida em que os estímulos ajudam na garimpagem dos verdadeiros requerimentos do sistema, desconsiderando aspectos superficiais ou de baixa relevância. Esses requerimentos verdadeiros são, portanto, aqueles sem os quais o sistema não atinge seus objetivos.

Além disso, o modelo funcional obtido em nível de eventos apresenta-se revestido de certa facilidade de articulação, pois os processos chamados essenciais, nesse nível, estão fechados em si e só se comunicam através dos depósitos de dados, nunca via fluxos. Isso facilita a sua distribuição para implantação por equipes distintas, bastando para isso somente um consenso a implantação por equipes distintas, bastando para isso somente um consenso a respeito dos layouts dos depósitos comunicadores.

A falta de costume com a abordagem, bem como a confusão do conceito de Eventos com relação a Função e Processos leva a uma dificuldade inicial que o tempo, a experiência e o exercício contínuo se incumbem de desfazer.

Para entender o conceito de Eventos:

Os eventos são disparadores de processos. Logo, os eventos externos estão relacionados com fluxos externos de dados. Pode-se imaginar que a chegada de alguns fluxos externos (nem todos) determinam alguns eventos e, por conseqüência, o seu processo. Esses são os eventos externos.

Outros eventos são disparados por um mecanismo interno tipo "clock" sem motivações externas. São os eventos temporais. É como se existisse um relógio interno no sistema que em certos momentos disparasse processos, não provocados por fluxos externos.

Como os eventos são produtores de estímulos ao sistema, ao término deles (resposta de cada evento) o sistema retornará ao seu estado de inatividade, até ser ativado novamente por outro evento.

Analisando-se cada entidade externa no Diagrama de Contexto, e questionando a sua inter-relação com o sistema, garimpa-se facilmente os eventos externos.

Analisando-se eventos externos iniciais, pode-se obter outros pela regra de contrários (Ex.: Cliente emite pedido, e o evento contrário, cliente cancela pedido).

Analisando-se eventos externos iniciais, pode-se obter eventos sucessores e antecessores. Analise também a NÃO - ocorrência do Evento e suas conseqüências.

Deve-se atentar para o fato de eventos empacotados e falsamente percebidos como único. Para isso, analise o fluxo de chegada de um evento e verifique se para todas as ocorrências do evento os dados serão os mesmos.

Como método prático, inicie a garimpagem dos eventos pelo Diagrama de Contexto, ou seja, a visão mais macro do seu sistema. Para os casos onde o Diagrama de Contexto não pôde ainda ser obtido, inicie pela Análise de Dados, criando o Modelo de Dados e através das Entidades e Relacionamentos garimpe os Eventos. A criação, eliminação e alteração dos objetos e de seus relacionamentos é fonte fidedigna de origem de eventos. As alterações de um valor de um objeto, no fundo, representa uma mudança de estado dele e também sugere eventos. Por exemplo, Cliente e Pedidos são objetos do MER de um sistema de Materiais e um relacionamento de solicitação existe. Logo, um evento de solicitação e outro de cancelamento de Pedidos poderão ser inferidos via MER.

1. Faça algumas confirmações quando terminado o modelo dos eventos: Cada evento externo possui fluxo de entrada? Cada evento externo possui um ou mais fluxo de saída? Cada evento esta produzindo saída imediata, ou armazenando dados para processamentos posteriores?
2. Considere as seguintes regras para rotular eventos: Para eventos externos, ou seja, aqueles iniciados por uma ação externa ao sistema:

Entidade externa + verbo + objeto Ex.: Cliente emite pedido. Para eventos temporais ou internos, ou seja, aqueles disparados por um mecanismo de clock interno do sistema: É hora de / . Ex.: E hora de emitir relatório financeiro para diretoria. Alguns eventos internos podem ser disparados por acontecimentos outros, além do aspecto temporal. Por exemplo, o ponto de reabastecimento de estoque. E o caso de eventos internos, onde alguns atributos ao atingirem determinados valores pré-definidos, disparam um processo associado. São denominados Eventos Condicionais e podem ser identificados por: É hora de <ação> por causa de <condição>.

Alguns exemplos de eventos em sistemas de Informação

O Modelo Conceitual

Modelo conceitual é o modelo em que os dados são vistos como objetos conceituais em nossas mentes, isto é, estamos no mundo das idéias. Neste modelo estão incluídos todos os dados formais e informais, necessários a operação das organizações, descritos de forma adequada.

Um modelo conceitual engloba bem mais do que a simples pretensão de representar a realidade. Seu emprego encontra a utilização mais nobre relacionado ao processo criativo. Desvinculado da criação, modela-se o que existe, e, como conseqüência, muitas vezes, apenas se automatiza o que é feito de forma manual. A modelagem oportuniza contato com as práticas operacionais existentes. O questionamento destas práticas muitas vezes possibilita a descoberta de funções duplicadas ou conflitantes. Eliminar estes e outros aspectos nocivos é também criação. Um modelo é uma antecipação do futuro, sendo portanto também uma definição de como queremos o futuro.

Idêntica função tem uma planta baixa ou maquete na área da construção civil. Elas são uma linguagem gráfica simples, que o usuário precisa entender, e são usadas no processo de criação de alternativas, bem como para aprovação e obtenção da escolhida. Nelas se definem localizações de portas, janelas, corredores, paredes, tubulações embutidas, etc. A planta serve como orientação para a primeira versão e como guia do que futuramente vai ser possível ou não de se modificar. Além de auxiliar na visualização e no perfeito entendimento do que se está projetando, a planta também representa um compromisso formal entre as partes. Imagine-se um eventual proprietário de uma casa que resolve unificar dois ambientes derrubando uma parede e constata que lá existe uma tubulação qualquer. Ele poderá ficar aborrecido, mas, se esta tubulação constar da planta arquitetônica que ele aprovou, não lhe cabe outra alternativa senão reconhecer o problema como dele. Imaginemos que ele argumente não ter se dado conta de que devia ter se preocupado com estes detalhes. Neste caso pode ter acontecido que o engenheiro falhou, impondo sua solução sem validá-la exatamente com aquele que iria conviver com o produto gerado. A estes profissionais lembramos que a mais espetacular criação arquitetônica pode não satisfazer a um usuário simplório. Esta é uma analogia que visa conscientizar da importância não só da participação, mas também do entendimento e concordância do usuário. Pois sabendo ou não, ele está sendo corresponsabilizado com a solução. O mínimo de ética profissional nos indica que devemos alertá-lo para isso.

No que diz respeito aos sistemas de informações, fazer um modelo de dados conceitual significa criar uma representação da realidade, para usá-la como ferramenta de especificação de uma base de dados e de um conjunto de processos para sua geração e manutenção.

O modelo é também o instrumento de comunicação que o analista usa para induzir o usuário a descrever sua organização, sua realidade, seu negócio. Porém, o analista deve policiar sua tendência técnica (tendência a pensar em termos de sistemas, arquivos, programas, etc.), para que possa ver as coisas tanto quanto possível do ponto de vista do usuário. É imprescindível que analista, usuário e administrador de dados (AD), não só entendam o modelo, mas que também concordem e se comprometam com a solução adotada. Através dele as partes envolvidas passam a conhecer a abrangência e as informações que vão ser manipuladas. Muitos analistas e ADs tentam, através de argumentação variada, impor ao usuário a sua solução, cometendo dupla falta: uma profissional pois não estão sendo honestos com o usuário; e a segunda com o Centro de Processamento de Dados (CPD) que espera a co-autoria do usuário para também responsabilizá-lo pela solução adotada, como forma de garantir qualidade e como estratégia para manter o cliente.

Existindo tantas alternativas, o que deve ser considerado, na escolha de um modelo em detrimento aos demais? As seguintes qualidades caracterizam um bom modelo:

• Completeza: Deve possibilitar a representação de todas as características da realidade. Não deve necessitar anotações complementares;
• Precisão: A representação deve ser precisa, com associação natural às características representadas. Não deve necessitar anotações complementares;
• Simplicidade: O número de conceitos deve ser pequeno;

• Consistência: Os conceitos utilizados devem ser independentes entre si. Cada conceito do modelo deve ter um significado distinto. Todos os conceitos do modelo devem ter uma única interpretação, independente de contexto;
• Ortogonalidade: Cada característica da realidade deve ter apenas uma forma de ser representada;
• Diagramação: Os conceitos devem ter uma forma de representação gráfica. Pode-se dizer que o sucesso de um modelo depende em grande parte da sua representação gráfica. Um modelo tem boa diagramação se ele é graficamente completo e sua representação é de fácil leitura. O número de símbolos deve ser pequeno.
• Expressividade: Riqueza semântica inerente que serve de guia para expressar as restrições e as propriedades dos dados. Possibilita uma melhor compreensão do mundo real representado.

Algumas destas características desejadas se opõem como expressividade e simplicidade: Se um modelo é semanticamente rico, ele pode não ser simples, etc. Então devemos buscar por um modelo que, no conjunto de características desejadas, atinja satisfatoriamente as consideradas indispensáveis e de forma aceitável as demais.

Optamos pelo modelo entidade-relacionamento estendido, por considerarmos que ele atende satisfatoriamente os itens referentes a "precisão", "simplicidade", "consistência", "diagramação", e razoavelmente aos demais.

O Modelo entidade-relacionamento foi proposto por Peter Chen como alternativa para representar o mundo real, dentro de uma ótica simplificada, qual seja, de que a realidade consiste de entidades e seus relacionamentos.

Existem muitas propostas de extensões ao modelo original. Neste texto muitas delas foram incorporadas, outras adaptadas e outros conceitos foram propostos, sempre com o intuito de aumentar o potencial semântico do modelo adotado.

Extraído de: Barbiere, Carlos – Modelagem de Dados – Rio de Janeiro: Infobook, 1994 e Eti, Francisco – Engenharia de Informações: conceitos, técnicas e métodos – Porto Alegre: Sagra: D.C. LUZZATTO, 1993.

Funcionário possui FilhosFilhos

FiguraFiguraFiguraFigura 1 111

Zona

Filhos

define

Seção

Município

FiguraFiguraFiguraFigura 2 222

2.6 Entidade de Relacionamento

Uma entidade de relacionamento é aquela que não existe por si só. Sua existência está condicionada a existência de duas ou mais entidades, a partir da qual é concebida. Surge da necessidade de armazenarmos informações que não pertencem a nenhuma das entidades envolvidas no relacionamento. Desta forma, a entidade de relacionamento (também denominada entidade associativa) tem como finalidade prover um mecanismo de armazenamento de atributos de um relacionamento conforme mostrado na figura 3.

FiguraFiguraFiguraFigura 3 333

3 Atributo

"Um atributo pode formalmente ser definido como a função que mapeia uma entidade ou relacionamento em um conjunto de valores, ou no produto cartesiano do conjunto de valores; f:Ei ou Ri -» Vi ou Vil x Vi x... x Vin"( Chen, 1990).

Informalmente, descrevemos atributo como cada um dos valores descritivos, propriedades ou dados associados a uma entidade ou relacionamento.

É uma característica inerente a uma entidade. Os atributos representam as informações que caracterizam exclusivamente a entidade e que desejamos guardar sobre a entidade.

Um atributo é de uma entidade quando identifica uma característica que é só da entidade, independente do contexto em que ela existe e dos relacionamentos que participa. Ex: Data de nascimento.

Nem sempre existe interesse em visualizar o atributo na representação gráfica. Quando for desejado, usa-se a forma mostrada na figura 4.

Aluno

Matrícula

Nome

avaliação^ Disciplina

Código

Nome

Nota

Projeto

Número

Nome

Localização

FiguraFiguraFiguraFigura 4 444

3.1 Atributo de Relacionamento

Um atributo é de um relacionamento quando ele só existe vinculado a uma ocorrência do relacionamento. Ex: O atributo data de casamento só existe se existir uma ocorrência-de-entidade da entidade Homem associada, através do relacionamento Matrimônio, com uma ocorrência-de-entidade da entidade Mulher.

São atributos que não caracterizam exclusivamente nenhuma das entidades participantes do relacionamento, mas a própria associação dessas entidades.

Por exemplo, um Aluno cursa várias Disciplinas, essas mesmas Disciplinas podem estar sendo cursadas por diversos Alunos. Existem alguns atributos nesse relacionamento que não caracterizam nem Aluno e nem Disciplina como no caso de Nota. Nesse caso, o atributo pertence ao relacionamento (fig. 5).

Aluno

Matrícula

Nome

avaliação^ Disciplina

Código

Nome

Nota

FiguraFiguraFiguraFigura 5 555

3.2 Atributo Composto

É um atributo que tem em sua composição um ou mais de um sub-atributos. Por exemplo, o Endereço de um Contribuinte é formado por: Tipo-Logradouro , Nome-Logradouro , Numero-Logradouro.

Os atributos compostos representam um agrupamento lógico dos sub-atributos, onde o valor do atributo é a concatenação dos valores dos sub-atributos. Isso, na prática, se traduz em grande facilidade de manipulação das informações. Graficamente, pode ser representado conforme o atributo endereço-cliente da figura 6.

Empregado

SSN

Nome

Salário

Logradouro

Complemento

Número

Bairro

Endereço

FiguraFiguraFiguraFigura 6 666

Na figura 9 o atributo "Total Líquido" é agregado, pois é obtido pelo somatório (vertical) de todos os "salários líquidos".

Com atributo agregado se evita que, para se obter informações totalizadas, seja necessário acessar e acumular vários registros. Ex.: se é desejado saber o saldo da conta corrente "empréstimos a funcionários", não é preciso acessar e somar todos os lançamentos existentes.

3.6 Atributo Determinante

É um atributo que identifica (determina) uma única ocorrência da entidade.

Graficamente ele é representado no diagrama sublinhado (fig. 10).

Cliente

CPF

Nome

Endereço

FiguraFiguraFiguraFigura 10 101010

4 Relacionamento

“É uma associação entre entidades” (Chen, 1990)

O relacionamento, matematicamente, pode ser representado como um par ordenado que associa elementos (ocorrências) de entidades (fig. 11).

João * Marcos * Silvia *

Bianca *

Aluno Disciplina

• Análise
• Java
• Redes
• TGA

João * Marcos * Silvia *

Bianca *

Aluno Disciplina

• Análise
• Java
• Redes
• TGA

FiguraFiguraFiguraFigura 11 111111 É importante ressaltar que no modelo E-R, o relacionamento é um objeto e, portanto, pode possuir atributos próprios.

O relacionamento possui uma riqueza semântica muito grande, propiciando a representação das regras de negócio do usuário. Ex. um Empregado obrigatoriamente está lotado em um Departamento.

A mesma adaptação feita para “entidade” e “conjunto de entidade”, é adotada para relacionamento e “conjunto de relacionamento”. Também adotamos o termo “ocorrência-de-relacionamento”, para definir um elemento específico do relacionamento.

Um relacionamento só tem sentido quando as entidades envolvidas são consideradas: “Um relacionamento é identificado pelas entidades envolvidas” (Chen, 1990). Em um modelo conceitual as entidades são representadas por suas chaves primárias.

No diagrama E-R, os relacionamentos são representados por um losango e como nome do relacionamento é adotado geralmente um verbo inscrito no interior do losango que identifica o tipo de associação que existe entre as entidades (fig. 12). Juntamente com o nome do relacionamento, podemos incluir uma seta que indica o sentido principal da leitura. Ex. Empregado TEM Dependente.

Para relacionamentos múltiplos, adotamos uma das duas alternativas:

a) Usar como nome do relacionamento, um nome que identifique a associação. Ex. O relacionamento ternário entre Pessoa (quem solicita um porte de arma), Arma (objeto do pedido) e o Órgão policial (que autoriza), pode ser substituído (balizado) por "Licenciamento". b) Usar tantos verbos quantos forem precisos para identificar o relacionamento: Pessoa/TEM/Conta- Corrente/TEM/Cartao-Magnético

Departamento (^) lota Empregado

1 N

FiguraFiguraFiguraFigura 12 121212

4.1 Opcionalidade de Relacionamento

Dada uma entidade E e um relacionamento R em que E participa, dizemos que o relacionamento R é total em relação a E, se e somente se, toda ocorrência de E tiver que ocorrer em R, sendo representado graficamente por uma bola cheia conforme fig. 13; se ao contrário, nem toda ocorrência de E tiver que participar(ocorrer) do relacionamento R, dizemos que R é parcial em relação a E.

Por exemplo, vamos supor que todo Empregado deva estar lotado pelo menos (no mínimo) um Departamento (fig. 13). Dizemos que lota é total em relação a entidade Empregado, pois todo elemento (ocorrência) da entidade Funcionário deve ocorrer (participar) no par ordenado (relacionamento) lota no mínimo 1 (um) vez.

No diagrama E-R representamos por um "círculo preto", situado entre o símbolo do relacionamento (losango) e o símbolo da entidade (retângulo), se a entidade tiver suas ocorrências obrigatoriamente participando do relacionamento, e com uma "circulo branco", se for opcional.

Departamento tem Empregado

1 M

FiguraFiguraFiguraFigura 13 131313 O número mínimo de vezes que a entidade deverá participar do relacionamento chama-se totalidade mínima. Essa totalidade mínima deve ser expressa no diagrama Entidade-Relacionamento. Caso a totalidade mínima seja maior que 1, o número deve ser escrito em cima da bolinha cheia do relacionamento. Por exemplo, vamos supor que todo Departamento deva obrigatoriamente ter no mínimo 2 funcionários lotados, poderíamos representar essa situação como na fig. 14. Analisando o diagrama baixo, concluímos que toda ocorrência de Departamento deve participar do relacionamento pelo menos 2 (duas) vezes, ou seja, cada ocorrência da entidade Departamento deverá ter associado a ela no mínimo 2 (duas) ocorrências da entidade Empregado, devendo ocorrer 2 (duas) vezes no par ordenado lota = ( Emp, Dep ).

Departamento tem Empregado

2 N

FiguraFiguraFiguraFigura 14 141414 No momento da identificação de um relacionamento nem sempre possuímos condições para já especificarmos a natureza das entidades associadas. Muitas vezes ela fica para ser posteriormente apurada. Por isso, consideramos muito importante a especificação de símbolos distintos para identificar tanto a natureza opcional como a obrigatória. A marcação das duas naturezas propicia a rápida descoberta de omissões. Identificando, por exemplo, só as naturezas obrigatórias, as omissões são assumidas (erroneamente) como natureza opcional, e não são descobertas.

4. Faz-se a pergunta: Existindo um Departamento, qual o máximo de Empregados que podem se relacionar com este Departamento? Como a resposta é vários, a cardinalidade da entidade Empregado no relacionamento é "M".

No diagrama E-R, a cardinalidade é grafada sobre, ou ao lado, da natureza.

A cardinalidade fica bastante visível quando se representa o relacionamento em termos de uma relação matemática, conforme mostrado na figura 11. Neste exemplo, é visível que um Aluno pode cursar "M" Disciplinas e que uma Disciplina pode ser cursada por vários alunos.

A natureza e a cardinalidade das entidades nos relacionamentos complementam a riqueza semântica do modelo, possibilitando a representação precisa das regras de negócio. Na figura 15 item (e) está formalizada a seguinte regra: Um Departamento opcionalmente tem vários Empregados e um Empregado obrigatoriamente pertence a um único Departamento

4.3 Tipo de Relacionamento

É a combinação das cardinalidades das entidades associadas pelo Relacionamento. Assim temos, os relacionamentos tipo 1:1, 1:M, M:M, 1:1:M, etc.

Note-se que o tipo do relacionamento é dependente do sentido de leitura. Ex.: O relacionamento Departamento/TEM/Funcionário é de tipo 1:M; o relacionamento Funcionário/PERTENCE/Departamento (mesmo relacionamento lido no sentido inverso) é de tipo M:1.

4.3.1 Relacionamento 1 : 1

A classe de relacionamentos 1:1 significa que cada ocorrência das entidades envolvidas no relacionamento, relaciona-se com uma e somente uma ocorrência da outra entidade. Por exemplo, cada Departamento é chefiado por somente um Empregado e, um Funcionário pode chefiar um e somente um Departamento (fig. 16).

Departamento (^) chefia Empregado

FiguraFiguraFiguraFigura 16 161616

4.3.2 Relacionamento 1 : N

A classe de relacionamentos 1:N significa que cada ocorrência da entidade do lado N do relacionamento pode se relacionar com somente uma ocorrência da outra entidade e, uma ocorrência da entidade do lado 1 do relacionamento pode se relacionar com várias ocorrências de entidade no lado N.

Por exemplo, um determinado Empregado está lotado em um Departamento e, um determinado Departamento possui vários Empregados lotados (fig. 17).

Departamento (^) lota Empregado

1 N

FiguraFiguraFiguraFigura 17 171717

4.3.3 Relacionamento N : M

Nessa classe de relacionamento não há restrições na associação entre as ocorrências das entidades que participam do relacionamento. As entidades participantes podem ocorrer várias vezes nesse relacionamento.

Por exemplo, um determinado Aluno pode cursar de várias Disciplinas e, uma Disciplina pode ser cursada por vários Alunos (fig. 18).

Aluno (^) cursa Disciplina

N N

FiguraFiguraFiguraFigura 18 181818

Obs.: Quando soubermos o número exato de vezes que as ocorrências de uma entidade ocorrem num determinado relacionamento, podemos substituir o N por esse número decimal. Por exemplo, se fosse estipulado que os Alunos podem cursar no máximo 2 Disciplinas, podemos substituir a cardinalidade N da fig. 18 pelo número 2 (fig. 19).

Aluno (^) cursa Disciplina

N 2

FiguraFiguraFiguraFigura 19 191919

4.3.4 Auto-relacionamento

Se R é um relacionamento que associa elementos (ocorrências) de uma entidade E a elementos dessa mesma entidade, R é denominado auto-relacionamento (ou relacionamento reflexivo).

Por exemplo, um empregado pode chefiar vários outros empregados e um empregado pode ainda ser chefiado por apenas 1 empregado (fig. 20).

chefia Empregado

M

1

FiguraFiguraFiguraFigura 20 202020 Os auto-relacionamentos são utilizados para expressar também situações de composição. Por exemplo, uma peça é composta de várias outras peças e, uma determinada peça pode fazer parte de várias composições (fig. 21).

compõe Peça

N

M

FiguraFiguraFiguraFigura 21 212121

5 Papéis das Entidades nos Relacionamentos

"Papel de uma entidade num relacionamento é a função que ela desempenha no relacionamento. Marido e esposa são papéis" (Chen, 1990)

Muitas vezes o papel que uma entidade desempenha no relacionamento se confunde com a própria entidade. Uma situação peculiar ocorre nos auto-relacionamentos onde uma entidade desempenha mais de um papel. Por exemplo: No auto-relacionamento Pessoa/casa-com/Pessoa, a entidade Pessoa desempenha dois papéis, e uma ocorrência do relacionamento sempre associa duas ocorrências da entidade Pessoa, mas sempre cada uma delas em um dos dois papéis possíveis: marido e esposa. Nenhuma ocorrência deste relacionamento associa duas esposas ou dois maridos.

Analisando o auto-relacionamento da fig. 21, podemos dizer que o auto-relacionamento representa a composição de peças. Temos uma única entidade participando duas vezes do relacionamento. Nos relacionamentos que envolvem duas ou mais entidades, o papel desempenhado por cada entidade no relacionamento é obvio e comumente omitido, porque o nome do relacionamento traduz claramente a associação do mundo real. Já no auto-relacionamento, como no da fig. 19, faz-se necessário explicitar o