Apesar de ser uma forma gráfica de representar um banco de dados relacional, o modelo ER possui um elevado grau de semântica, que o torna mais simples, além de permitir uma comunicação mais otimizada entre os usuários e os profissionais de informática, desen- volvedores de sistemas.
Dentro do que utilizamos como método de desenvolvimento podemos tanto iniciar a análise por modelagem de eventos ou casos de uso quanto por modelagem de dados para depois, com as entidades definidas, analisarmos os eventos que existem relativos a cada um desses objetos.
A própria UML prega a utilização da criação dos diagramas de casos de uso como primeira etapa de um processo metodológico de desenvolvimento de aplicações. Porém, é um cacoete derivado dos conceitos de análise estruturada e análise essencial, em que destaque e importância maior sempre foram dados aos processos e não aos dados.
Voltamos a lembrar que dados são sempre mais estáveis que processos.
Observe que podemos mudar completamente um processo de faturamento, mas os dados relativos ao faturamento continuaram estáveis. Na pior das hipóteses esses dados seriam reduzidos, mas não haveria uma mudança completa dos dados utilizados para esse processo.
Os diagramas de caso de uso fornecem um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível de funcionalidade intencional mediante o recebimento de um tipo de requisição de usuário. Entretanto, no caso de iniciarmos um desenvolvimento pela especificação de casos de uso, podem conduzir-nos à criação de classes de dados redundantes ou não aderentes ao mundo real, o que obtemos sempre quando trabalhamos com modelagem de dados pura.
Já a modelagem de dados pode permitir a criação mais concisa de modelo de classes, já que um modelo de dados retrata com maior fidelidade uma realidade, ou seja, o mundo real.
A estabilidade do modelo de dados é obtida quando se investe quantidade de tempo nos aspectos conceituais de modelagem de dados, revertendo esse tempo em benefícios consideráveis durante a implementação da base de dados.
A técnica de modelagem Entidade-Relacionamento proposta por Peter Chen está definida como uma notação orientada para o desenho de um modelo conceitual, pois permite a descrição desse esquema conceitual sem preocupação com problemas de implementação física ou de performance do banco de dados.
O diagrama Entidade-Relacionamento descreve a estrutura conceitual e lógica geral de um banco de dados.
Observa-se então que o objetivo da modelagem de dados é definir o contexto dos dados em que os sistemas funcionam. Por isso, o produto da modelagem de dados deve ser o mais fiel possível ao mundo real e, além disso, possuir uma característica adicional muito importante: as suas especificações não devem implicar e tampouco estarem limitadas a nenhuma implementação física em particular. Tudo aquilo que for proposto pela modelagem de dados deve ocorrer num nível conceitual e lógico, de maneira a não viciar a análise pela restrição de pontos de vista técnicos da equipe de participantes do processo de análise. Os detalhes físicos vêm depois.
A abordagem de sistemas para bancos de dados relacionais tem como principal característica o alto nível em que ocorrem as definições necessárias à implantação de uma base de dados.
Assim, a qualidade de um projeto como um todo é muito dependente da qualidade da modelagem de dados que o antecede.
É muito importante então que exista uma metodologia simples, precisa e eficiente para a representação dos objetos modelados pelo analista e que também seja de fácil transposição para os diversos SGBD disponíveis.
É isso que se obtém com a utilização do modelo ER proposto por Peter Chen.
Elementos de um Modelo ER
Um modelo de dados ER é composto de três classes de objetos: entidades, relacio- namentos e atributos.
As literaturas existentes nunca deixam claro como podemos entender entidades e relacionamentos. Uma vez que a maioria dos profissionais de análise de sistemas tem sua cultura baseada em sistemas procedurais, em que os dados são o resultado e não o meio, existe a necessidade de que se coloque mais enfoque didático no detalhamento da definição de entidades e relacionamentos.
As técnicas orientadas a objetos, hoje utilizadas no País e que alcançaram divulgação profissional prática, baseiam-se na análise dos procedimentos, e com enfoque principalmente direcionado aos casos de uso (use case) e em diagramas de classes excessivamente preocupados em retratar não só dados e sim processo em conjunto, ou nos casos de análise essencial em diagramas de fluxo de dados, o que provoca uma derivação de foco e possibilita uma larga margem de erro de conceituação do mundo real.
Essas técnicas estruturadas colocam as informações derivadas dos procedimentos em classes de dados (OO) ou depósitos de dados (A Essenc.) as quais sintetizando-se finalmente acabam sendo convertidas em tabelas de um sistema, pura e simplesmente.
Para que se efetue então a migração dessa base cultural, é necessário que a regra bá- sica - procedimentos não nos interessam - seja atendida nesta abordagem de levantamento.
Vamos estabelecer como preocupação somente a necessidade de retratarmos as informações existentes no negócio. Nosso objetivo primordial é entendermos o negócio, para o qual projetaremos um sistema, através de seus dados.
Quando escrevemos objetos conceituais, não pretendemos inserir na orientação a objetos. Apesar de a modelagem conceitual de dados ser a base para o entendimento dessa nova abordagem tecnológica, o objetivo é na realidade ir até as raízes da conceituação de modelo Entidade-Relacionamento.
Quando Peter Chen formulou a proposta do modelo Entidade-Relacionamento, ele se baseou não na visão de um sistema de aplicação como princípio e sim na compreensão da realidade em que se situava o problema. Como vamos projetar um sistema se não entendemos o negócio para o qual será realizado?
Chen dedicou-se a destacar a importância de reconhecer os objetos que compõem esse negócio, independentemente de preocupar-se com formas de tratamento das infor- mações, procedimentos, programas etc.
Entidades
Correspondem a quaisquer coisas do mundo real sobre as quais se deseja armazenar informações.
São exemplos típicos de entidades: pessoas (físicas ou jurídicas, tais como funcionário, empresa, fornecedor e cliente); objetos materiais ou abstratos, como produto, veículo, disci- plina e projeto e eventos ou fatos como pedido, viagem, empréstimo e venda principalmente.
No modelo ER são representados por meio de um retângulo com o nome representativo da entidade (um substantivo no singular) ao centro.
Uma entidade normalmente tem várias manifestações dela mesma. Por exemplo, a enti- dade funcionário representa todos os funcionários da empresa, e não apenas um deles; a entidade produto representa todos os produtos com os quais a empresa trabalha etc.
Se fizermos uma comparação com a UML, funcionário é o um objeto, o conjunto dos objetos funcionários forma a classe de objetos funcionário, que é a nossa entidade. Então uma entidade corresponde a uma classe de objetos e as ocorrências desta entidade são os objetos funcionários.
Dizemos então que uma entidade possui ocorrências ou instâncias, e cada um dos funcionários descritos pela entidade funcionário é uma de suas ocorrências, ou instâncias.
Entidade é a principal classe de objetos sobre a qual são coletadas informações. Ela normalmente denota pessoa, lugar, coisa ou fato de interesse de informações.
É todo objeto concreto ou abstrato que tem existência própria, quando considerado o âmbito de um negócio. São coisas sobre as quais desejamos arquivar informações.
Define-se entidade como aquele objeto que existe no mundo real com uma identificação distinta e com um significado próprio.
São as coisas que existem no negócio, ou ainda, descrevem o negócio em si.
A figura seguinte apresenta o ambiente de uma clínica médica correspondente à descrição de um minimundo.
Uma clínica médica necessita controlar as consultas médicas realizadas e marcadas pelos médicos a ela vinculados, acompanhar os pacientes atendidos e manter o seu acompanhamento clínico. Para cada médico a clínica mantém uma ficha com o número de CRM, seu nome, endereço, especialidade etc. Os pacientes têm cadastro com dados pessoais, tais como nome, endereço, data de nascimento, sexo etc. Toda consulta é registrada em fichário próprio com as informações sobre médico e paciente, diagnóstico etc.
Quais são os objetos candidatos a entidades nesse ambiente em observação?
Observe com a sua capacidade de abstra- ção as coisas que existem no ambiente: médicos, pacientes, exames, consulta.
Essas coisas que fazem parte do ambiente são entidades, pois podemos manter informações sobre elas, e são participativas na existência do ambiente. Cada uma delas tem significado próprio.
Se alguma coisa existente no ambiente negócio nos proporciona algum interesse em mantermos dados sobre essa coisa (informações armazenadas sobre ele), isso a caracteriza como uma entidade do negócio.
Cada entidade será então um elemento em nosso modelo conceitual de dados.
Uma entidade é a representação de uma classe de dados de um ambiente específico, um conjunto de informações de mesmas características. Cada ocorrência da coisa que representamos como uma entidade é chamada de instância (ocorrência) e representa um conjunto particular desses dados.
Quando representamos classe de dados, atuamos em um nível de abstração de dados interpretado de acordo com o entendimento do meio, do ambiente em que nos localizamos e seus interesses e objetivos.
Uma instância de uma entidade não tem representação no diagrama ER, porém devemos sempre visualizar em uma entidade a ocorrência de linhas de uma tabela relacional, uma vez que estamos realizando análise para o contexto lógico de banco de dados relacional.
Data_da_Consulta CRM_do_Medico Identificacao_Paciente
22/04/92 21113 João Pedro Lima
22/04/92 21113 Clara Mathias
21/03/91 14442 Luís Alberto Conde
31/03/92 55555 Maria Luiza Andrade
Endereco Sexo Idade R. Silva Sá, 23/11 Masc 33 R. Dias Melhores 334/122 Fem 18 Av. Arapanés 4487/1915 Fem 44 R. Botica do Ouvidor 44/fundos Masc 29 Trav. das Camélias 661 Masc 38
Quando analisamos um ambiente, tiramos uma fotografia dele que nos apresenta as entidades que participam, ou estão naquele ambiente.
A representação gráfica de uma entidade em um diagrama ER é realizada por meio de um retângulo com o nome da classe de dados inserido em seu interior conforme apresentamos na fotografia da página anterior.
Numa visão simplista, entidade é similar a um arquivo de um sistema convencional, e é natural fazer esta correspondência: um conjunto de ocorrências de uma entidade corresponde a um arquivo, e uma única ocorrência, que podemos denominar de linha, corresponde a um registro.
Relacionamentos
Relacionamento é a representação das associações existentes entre entidades no mundo real. Muitos relacionamentos não têm existência física ou conceitual, outros dependem da associação de outras entidades.
No mundo real uma entidade muito raramente se apresenta isolada, tendo existência completamente independente de quaisquer outras.
Normalmente ocorre o contrário: é detectada a existência de uma associação entre as ocorrências de duas entidades distintas.
Essa conexão lógica entre duas ou mais entidades definimos como relacionamento, que é representado em um diagrama Entidade/Relacionamento por meio de uma linha unindo as entidades associadas, contendo ainda um losango com o nome do relacionamento (um verbo flexionado) ao centro.
Uma ocorrência em particular de um relacionamento é chamada de instância de relacio- namento, ou ocorrência. Um relacionamento é descrito em termos de grau, cardinalidade e existência.
O mais comum dos termos associados a um relacionamento é a indicação da cardinalidade entre as ocorrências das entidades relacionadas: um-para-um, um-para-muitos e muitos-para-muitos.
Como cardinalidade é um termo que não explicita muita coisa, vamos utilizar a palavra conectividade porque acreditamos que entender o conceito de conexão é mais simples. Alguma coisa se conecta a outra.
O nome do relacionamento normalmente é um verbo, pois é resultante de um fato que associa as entidades. Podemos dar dois nomes, digamos assim, a um relacionamento.
Um verbo para explicar o fato no sentido da entidade A para a entidade B, e outro verbo no sentido da entidade B para a entidade A, uma vez que a leitura de um relacionamento não possui um lado específico do modelo para ser realizada.
Entender relacionamentos e a capacidade de enxergar esses objetos, assim como a sua participação no mundo real, é fator primordial para o resultado de uma modelagem de dados com entendimento e retrato fiel do ambiente em análise.
Não devemos ter antecipadamente medo da provável complexidade de uma técnica, e sim lembrarmo-nos de que nada mais é do que uma forma estruturada de representar as coisas que existem e ocorrem no mundo real, como sempre fizemos com papel e lápis desde a infância.
Dentro deste enfoque relacionamento é um fato, acontecimento que liga dois objetos, duas "coisas" existentes no mundo real.
Considerando que estamos nos orientando para aplicações que serão desenvolvidas e administradas por um Sistema Gerenciador de Banco de Dados, poderíamos estender o conceito, principalmente para ambientes relacionais, como sendo relacionamento o fato que efetua a junção de duas ou mais tabelas de dados.
Vamos continuar a conceituação dos elementos de um modelo de dados ER, e depois voltamos ao entendimento e identificação mais clara de relacionamento no mundo relacional.
Atributos
São as características de uma entidade que a descrevem detalhadamente.
Uma ocorrência específica de um atributo em uma entidade ou relacionamento deno- mina-se valor do atributo.
Os atributos representam propriedades elementares de uma entidade ou relacionamento. Cada atributo está associado a um domínio particular, que é um conjunto de valores válidos para o atributo.
Os atributos da entidade empregado, por exemplo, são normalmente a identificação do empregado, o nome, endereço, sexo, telefone, cargo, salário.
A notação de Peter Chen original apresenta o atributo como uma elipse com o nome do atributo em seu interior e conectada à entidade a que pertence.
A simbologia utilizada por Rumbaugh em seu livro coloca uma lista de atributos dentro do retângulo da entidade, deixando sobre ele o nome da entidade. Esta é uma notação gráfica também interessante, entretanto os produtos de software para modelagem de dados utilizam mais a notação IDEF1X e a notação da engenharia de informação que veremos também neste livro.
Existem dois tipos de atributo: identificadores e descritores.
Um identificador (ou chave) é usado unicamente para determinar a identificação de uma ocorrência de uma entidade. Em nosso ambiente relacional equivale à chave primária. Observe que quando estamos executando o processo de abstração para identificar as entidades, não existem chaves primárias do tipo código.
Os atributos descritores (não chaves) são utilizados para descrever características não únicas de uma ocorrência particular da entidade.
Por exemplo, no diagrama da entidade funcionário, o atributo chave, identificador de uma ocorrência de funcionário é matrícula; endereço e nome são seus descritores.
Todo objeto para ser uma entidade tem propriedades que são descritas por atributos e valores. Esses atributos e seus valores, juntos, descrevem as instâncias de uma entidade.
Entidade: Funcionário
Matricula NomeFunc DtAdmissao Sexo
104 Carlos Pereira 2/3/2004 M
134 Jose Alves 23/5/2002 M
123 Pedro Sergio Doto 29/6/2003 M
22 Sergio Nogueira 10/2/2000 M
O que descreve funcionário?
Funcionário é descrito por um número de matrícula, um nome desse funcionário, sua data de admissão e sexo, como é representado na tabela anterior. Poderíamos ainda descrevê-lo com mais dados, tais como data de nascimento, valor de seu salário etc. Esses dados que caracterizam o objeto funcionário são os atributos inerentes à entidade funcionário.
Cada instância de funcionário, cada existência de um objeto da classe funcionário será formada por valores nesses atributos. É o conjunto desses valores representados que devemos visualizar como uma linha de uma tabela de dados da entidade.
Os valores de determinados atributos ou de um determinado atributo, nas ocorrências dessa entidade, são sempre diferentes para cada instância, caracterizando que não existem objetos repetidos dentro de uma classe de objetos, isto é, dentro de uma entidade.
Esse(s) atributo(s) cujos valores nunca se repetem, sempre tem (têm) a função de atuar como identificador(es) único(s) das instâncias da entidade. Dentro da abordagem relacional de banco de dados, denomina-se essa propriedade como chave primária de uma tabela, conceito que vamos utilizar dentro de nosso contexto, quando realizarmos o modelo lógico de dados.
Este conceito não foge de forma nenhuma do que acontece no mundo real, já que um objeto sempre possui uma forma de identificação unívoca.
Quando modelamos, independentemente de estarmos pensando em ambiente de banco de dados relacional, encontramos alguns atributos que são multivalorados, ou seja, acontecem mais de uma vez para cada ocorrência da entidade. Por exemplo, no caso de funcionário, poderíamos ter um atributo especialidades, ou habilidades, que seria mais de um para cada existência de funcionário.
Em um primeiro momento vamos representar esses atributos em destaque com uma conexão de linha dupla com a entidade.
Apesar de afirmarmos a existência de atributos identificadores e descritivos, encontra- mos entidades que são derivadas de outras, tendo parte de seus atributos identificadores igual à de outra entidade.
Estas entidades têm existência dependente, ou seja, somente existem se existir a entidade da qual possuem parte dos atributos identificadores. Exemplos claros deste caso são as entidades históricas em um negócio.
No caso da entidade funcionário seria a existência de uma entidade história dos cargos ocupados por cada ocorrência de funcionário. Mas observe que isso é uma derivação, pois inicialmente esses cargos ocupados poderiam ser entendidos como um atributo multivalorado da entidade funcionário.
O objetivo é apresentar as formas de representação de um modelo ER. Representação que exemplifica entidades, relacionamentos e atributos.