Projeto Conceitual

Segundo Heuser (2009) a modelagem conceitual deve capturar as necessidades da organização em relação ao armazenamento de dados, sem considerar a sua implementação.

Mecenas e Oliveiras (2005) esclarecem que, no início do projeto, a maioria dos usuários não sabe exatamente o que quer, tornando os dados incompletos. O projeto conceitual deve mostrar que dados devem está presentes e como eles se relacionam.

O projeto conceitual fornece uma visão geral da empresa. Nesta fase, segundo Silberschatz, Korth e Sudarshan (2006, p. 10):

O projetista revisa o esquema para confirmar se as necessidades estão realmente satisfeitas e se não estão em conflito entre si. O projetista também pode examinar o projeto para remover quaisquer recursos redundantes. O foco nesse momento é descrever os dados e suas relações, e não especificar detalhes do armazenamento físico (SILBERSCHATZ, KORTH E SUDARSHAN, 2006, p. 10).

Heuser (2009) declara que a técnica mais utilizada nesta fase é a abordagem entidade-relacionamento (ER), nesta técnica, um modelo conceitual é representado através de um diagrama, chamado entidade-relacionamento (DER).

A abordagem entidade-relacionamento foi criada por Peter Chen em 1976, sendo a técnica mais difundida e utilizada. Além disso, os conceitos dessa abordagem baseiam as novas técnicas que têm surgido nos últimos anos, como a UML (HEUSER, 2009).

Mecenas e Oliveira (2005, p. 34) concordam com o autor e afirmam que “a abordagem entidade-relacionamento, criada por Peter Chen tornou-se a técnica mais utilizada para modelagem de dados”.

O modelo entidade-relacionamento normalmente é usado para representar o projeto conceitual. O esquema conceitual especifica as entidades que são representadas no banco de dados, os atributos das entidades e os relacionamentos entre as entidades. O resultado é um diagrama de entidade- relacionamento, que fornece uma representação gráfica do esquema.

2.6.1.1 Entidades

Segundo Heuser (2009, p. 34) “entidade representa um conjunto de objetos da realidade modelada”. As entidades devem descrever os objetos sobre os quais se deseja manter informações.

Ao pensar em um banco de dados para ser gerenciado, a empresa deverá inicialmente identificar que dados serão necessários à administração do negocio. Normalmente, esses dados serão referentes a algum tipo de informação, como clientes ou funcionários. Essas categorias que armazena e mantém informação é chamada de entidade.

Mecenas e Oliveira (2005) afirmam que as entidades devem descrever os elementos que o negocio do usuário precisa para funcionar adequadamente. Os autores declaram que as entidades podem representar elementos concretos, como cliente ou veículo, ou abstratos, como empréstimo e consulta.

Chen (1990, p. 20) descreve entidade como “uma coisa que pode ser distintamente identificada”.

É de fundamental importância, para o sucesso do projeto, que o projetista descreva essas entidades de forma coerente, a fim de tornar o projeto sucinto e de fácil entendimento, evitando redundâncias e falta de integridade entre as entidades.

O projetista do banco de dados possui a responsabilidade de selecionar os tipos de entidades que são mais adequados para cada empresa. As entidades comporão as informações que serão utilizadas pelos usuários.

Heuser (2009) e Silberschatz, Korth e Sudarshan (2006) divergem na conotação em alguns pontos. O primeiro autor afirma que entidade é o conjunto de várias ocorrências da entidade, por exemplo, se existe uma entidade com o nome CLIENTES e caso seja necessário referir a um cliente em particular, fala-se em ocorrência da entidade. Já Silberschatz, Korth e Sudarshan (2006) esclarecem que entidade define um cliente específico e quando se deseja de todos os clientes, fala- se em conjunto de entidades, como pode ser visto na Figura 9.

Figura 9 – Conjunto de entidades cliente e empréstimo

Fonte: adaptado de Silberschatz, Korth e Sudarshan (2006).

Silberschatz, Korth e Sudarshan (2006) finalizam afirmando que um banco de dados inclui uma coleção de conjuntos de entidades, cada uma contendo qualquer número de entidades do mesmo tipo.

De forma semelhante, os autores descritos acima, representam as entidades por um retângulo que contém o nome da entidade em letra maiúscula, demonstrada na Figura 10.

Figura 10 – Representação gráfica de entidades

Fonte: Elaborado pela autora, 2012.

2.6.1.2 Atributos

Mecenas e Oliveira (2005, p. 35) descrevem atributos como “fatos úteis sobre entidades”. Os autores afirmam que para serem úteis, os atributos devem ser relevantes ao negócio do usuário.

Heuser (2009) afirma que um atributo é o dado que é associado a cada ocorrência de uma entidade, representados conforme a Figura 11.

Figura 11 – Representação de atributos

Fonte: adaptado de Mecenas e Oliveira (2005)

Mecenas e Oliveira (2009) ilustram os atributos conforme apresentado na Figura 12.

Figura 12 – Atributos de uma entidade

Fonte: adaptado de Heuser, 2009.

Silberschatz, Korth e Sudarshan (2006, pág. 138) afirmam que “para cada atributo existe um conjunto de valores permitidos, chamado o domínio, ou o conjunto de valores, desse atributo”. Os autores utilizam o diagrama da Figura 13.

Figura 13 – Conjunto de atributos cliente rua_cliente cidade_cliente nome_cliente id_cliente

Fonte: adaptado de Silberschatz, Korth e Sudarshan, 2006.

Heuser (2009) tem a mesma visão ao declarar que conjunto de valores que determinam um atributo é chamado de domínio do atributo. Esse domínio possui propriedades de valores, como tamanho em caracteres, tipo de valores (como número ou hora/data), enumeração de valores permitidos, dentre outras. Entretanto, não é comum esses domínios aparecerem no diagrama ER.

Mecenas e Oliveira (2005) classificam os atributos em: básicos, designados e derivados. Os básicos são aqueles essenciais à definição da entidade e são, predominantemente, mutáveis ao longo do tempo. Os designados são aqueles adicionados à entidade por conveniência e não por necessidade inicial dos usuários. Os atributos derivados são os definidos a partir de outros atributos.

Cada entidade possui um atributo que a caracteriza de forma única. Heuser (2009) define identificador de entidade como um conjunto de um ou mais atributos que distinguem uma ocorrência da entidade das demais. No exemplo da Figura 14, o atributo código é o identificador.

Figura 14 – Identificador simples

Fonte: adaptado de Heuser, 2009.

Neste exemplo, cada pessoa possui um código próprio, entretanto os atributos nome e endereço não são identificadores, já que o mesmo nome ou endereço podem estar associados a mais de uma pessoa.

No modelo de Silberschatz, Korth e Sudarshan (2006) o código identificador é representado pelo nome do atributo sublinhado.

2.6.1.2 Relacionamentos

Mecenas e Oliveira (2005) afirmam que os relacionamentos descrevem a capacidade das entidades de interagirem, decorrentes de uma razão relevante ao negócio. Silberschatz, Korth e Sudarshan (2006, pág. 136) complementam declarando que “um relacionamento é o associação entre várias entidades”.

Na Figura 9, as entidades cliente e empréstimo, define-se um conjunto de relacionamentos que indicam as possíveis associações entre os clientes e os empréstimos bancários que cada um possui. Por exemplo, o cliente Adams, com o código 335-57-7991, pode ter adquirido o empréstimo com o código L-19, com valor de 500.

De forma semelhante às entidades, Heuser (2009) esclarece que quando se deseja referir a uma associação especifica dentro de um conjunto, deve-se falar em ocorrência ou instância de relacionamentos.

No diagrama da Figura 15, onde as ocorrências de entidades são representadas por círculos brancos e as ocorrências de relacionamentos por círculos pretos, pode-se analisar as relações, existentes entre as entidades empregados e departamentos.

Figura 15 – Diagrama de ocorrências

Fonte: adaptado de Heuser, 2009.

É de extrema importância, para o projeto de banco de dados, que sejam definidas quantas ocorrências de uma entidade podem estar associadas a uma

determinada ocorrência de outra entidade, através de relacionamentos. Essa propriedade é chamada de cardinalidade do relacionamento.

Mecenas e Oliveira (2005) classificam a cardinalidade em três tipos: a) Um-para-um (1:1): cada ocorrência de uma entidade-origem está

associada a apenas uma ocorrência da entidade-destino;

b) Um-para-muitos (1:n): cada ocorrência da entidade-origem está associada a várias ocorrências da entidade-destino;

c) Muitos-para-muitos (n:n): várias ocorrências da entidade-origem estão associadas a várias ocorrências da entidade-destino.

Nas Figura 16, Figura 17 e Figura 18, podemos analisar três exemplos de cardinalidade máximas 1:1, 1:n e n:n elaborados por Heuser (2009).

Figura 16 – Relacionamento 1:1

Fonte: adaptado de Heuser, 2009.

No exemplo da Figura 16, um empregado só pode ficar alocado em uma mesa na empresa. Da mesma forma que a mesa só deve possuir no máximo um empregado. Assim, uma instância de empregado pode estar associada via relacionamento a, no máximo, uma instância de mesa.

Figura 17 – Relacionamento 1:n

Fonte: adaptado de Heuser, 2009.

Acima, na Figura 17, o relacionamento INSCRIÇÃO modela a inscrição de alunos em uma universidade pública, onde um curso possui muitos alunos matriculados.

Figura 18 – Relacionamento n:n

Finalmente, o relacionamento existente entre um aluno e uma disciplina, na Figura 18, onde um aluno pode estar matriculado em várias disciplinas e cada disciplina pode ter vários alunos matriculados.

Os exemplos apresentados referem-se à cardinalidade no tipo máxima. Outra informação que pode aparecer também no diagrama ER é a cardinalidade mínima, podendo ser de dois tipos: a cardinalidade mínima 0 e a cardinalidade mínima 1.

Segundo Heuser (2009, p. 45):

A cardinalidade mínima 1 também recebe o nome de “associação obrigatória”, já que ela indica que o relacionamento deve obrigatoriamente associar uma ocorrência da entidade em questão. Com base na mesma linha de raciocínio, a cardinalidade mínima 0 recebe a denominação “associação opcional” (HEUSER, 2009, p. 45).

No diagrama entidade relacionamento a cardinalidade mínima e máxima são representadas juntas, sobre a forma (l, h), onde l é a cardinalidade mínima e h, a cardinalidade máxima.

Um valor mínimo de 1 indica a participação total do conjunto de entidades no conjunto de relacionamento. Um valor máximo de 1 indica que a entidade participa no máximo em um relacionamento (SILBERSCHATZ, KORTH E SUDARSHAN, 2006).

2.6.1.3 Especialização/Generalização

Silberschatz, Korth e Sudarshan (2006) definem especialização como um conjunto de entidades que pode incluir subagrupamentos de entidades que sejam, de algum modo, distintas de outras entidades de um conjunto.

Um subconjunto de entidade dentro de um conjunto de entidades pode ter atributos que não são compartilhados por todas as entidades deste conjunto. Heuser (2009) simboliza a generalização/especialização com um triângulo isósceles, conforme a Figura 19.

Figura 19 – Generalização/Especialização

Fonte: adaptado de Heuser, 2009.