Esquema E/R e Implementações Relacional e Objeto-Relacional: Parte 1

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (5)  (1)

Veja neste artigo um Esquema Entidade/Relacionamento simples, o mapeamento para esquema relacional (com implementação) e a implementação objeto-relacional.

Introdução

Um dos recursos orientados a objetos é a habilidade de criar e usar tipos de dados que se baseiam em um agrupamento de outros tipos de dados. Os objetos definidos pelo usuário podem então, aparecer e serem usados como qualquer outro tipo de dados. O Objetivo deste artigo é mostrar um Esquema Entidade/Relacionamento simples, o mapeamento para esquema relacional (com implementação) e a implementação objeto-relacional.

Esquema E/R - Entidade/Relacionamento

A técnica de modelagem de dados mais difundida é a abordagem entidade/relacionamento (E/R). Os conceitos básicos da abordagem E/R são: entidade, relacionamento e atributo. Para explicar os conceitos da Modelagem E/R vamos usar uma parte de uma aplicação simples de um sistema acadêmico, que possui professores, suas disciplinas e alunos dessas disciplinas. Este módulo está representado graficamente na Figura 1.

05-06pic05.JPG
Figura 1. Esquema E/R.

Uma entidade corresponde ao conjunto de objetos da realidade modelada sobre os quais deseja-se manter informações no banco de dados. Uma entidade é representada através de um retângulo que contém o nome da entidade. Na Figura 1 são apresentadas três entidades: PROFESSOR, DISCIPLINA e ALUNO.

O retângulo PROFESSOR representa o conjunto de todos os professores sobre os quais se deseja manter informações no banco de dados. Caso se deseje referir a um objeto particular (um determinado professor ou determinado aluno) fala-se em uma entidade e não um conjunto de entidades.

Um atributo corresponde ao dado que é associado a cada ocorrência de uma entidade ou de um relacionamento.  Segundo a Figura 1, podemos citar os atributos da Entidade PROFESSOR, codp, nome e fone, que correspondem ao código, nome e telefones do professor, respectivamente. Também existe atributo de relacionamento, como o atributo ano no Relacionamento LECIONA.

Cada entidade deve possuir um identificador. Um identificador é um conjunto de um ou mais atributos (e possivelmente relacionamentos) cujos valores servem para distinguir uma ocorrência da entidade das demais ocorrências da mesma entidade. O atributo codp na Entidade PROFESSOR identifica unicamente um professor. Não poderão existir dois professores com o mesmo código.

Um relacionamento corresponde ao conjunto de associações entre entidades. Um relacionamento é representado graficamente através de um losango, ligado por linhas aos retângulos representativos das entidades que participam do relacionamento. Na Figura 1 são apresentados relacionamentos denominados LECIONA e CURSA. Em cada um dos relacionamentos existem entidades participantes.

No Esquema E/R, existe a cardinalidade de relacionamento, que corresponde ao número de entidades que podem estar associadas via relacionamento. Existem dois tipos no exemplo: 1:N (um para muitos), N:M (muitos para muitos). O relacionamento 1:N, LECIONA, que associa que um professor (Entidade PROFESSOR) que leciona muitas disciplinas (Entidade DISCIPLINA), mas uma disciplina só pode ser lecionada por um professor. No relacionamento N:M, CURSA, associa que vários alunos cursam várias disciplinas. Vale ressaltar que nesse relacionamento tem um atributo ano que expressa quando o aluno cursou determinada disciplina.

Implementação Relacional

O modelo Relacional foi definido E. F Cood, em 1970. A grande aceitação comercial foi a partir de meados da década de 80. As razões dessa grande aceitação foram à simplicidade dos conceitos básicos e o poder dos operadores de manipulação. O Esquema Entidade/Relacionamento representado na Figura 1, uma vez mapeado para o Esquema Relacional, resultará nas seguintes tabelas.

PROFESSOR(codp,nome)
PROFESSOR FONE(codp,fone)
DISCIPLINA(codd,nome,codp)
ALUNO(coda,nome
)
CURSA(codd,coda,ano)

Isso se dá tendo em vista as regras de mapeamento a seguir.

REGRA 1: Para cada entidade não fraca no esquema E/R, criar uma tabela que inclui todos os atributos não multivalorados da entidade do Esquema E/R. Neste passo foram criadas as relações PROFESSOR, DISCIPLINA e ALUNO com os atributos correspondentes de cada entidade. Vale ressaltar que o atributo fone não foi colocado neste passo para a relação PROFESSOR tendo em vista que é um atributo multi-valorado e vai ser tratado na Regra 4. 

REGRA 2: Para cada relacionamento 1:N no Esquema E/R: (i) identificar a relação que representa a entidade do lado N; (ii) incluir como chave estrangeira a chave primária da relação que representa a entidade do lado 1; e (iii) incluir os atributos do relacionamento na relação. No exemplo da Figura 1, existe um relacionamento de 1:N, envolvendo as entidades PROFESSOR e DISCIPLINA, cujo relacionamento é LECIONA. A relação que representa a entidade do lado N é a DISCIPLINA. Deve ser incluído a chave da relação PROFESSOR, que representa a Entidade PROFESSOR do lado 1, como chave estrangeira na Relação DISCIPLINA. Se existissem atributos de relacionamentos deveriam ser incluídos também.

REGRA 3: Para cada relacionamento M:N no Esquema E/R: (i) criar uma nova relação para  representar o relacionamento; (ii) incluir como chave estrangeira as chaves primárias das relações que participam do relacionamento; (iii) essas chaves combinadas formarão a chave primária da relação; (iv) incluir também eventuais atributos do relacionamento. Através da Figura 1, tem-se o relacionamento CURSA, que associa as Entidades DISCIPLINA e ALUNO. Para representar esse relacionamento no esquema relacional, cria-se uma Relação CURSA inclui-se as chaves primárias (codd e coda) das tabelas DISCIPLINA e ALUNO como chaves estrangeiras nesta tabela. Essas chaves combinadas formarão a chave primária da Tabela CURSA resultante. O atributo de relacionamento ano será incluído na relação resultante como chave, tendo em vista que o aluno pode fazer mais de uma vez uma disciplina.

REGRA 4: Para cada atributo multivalorado: (i) criar uma nova relação; (ii) incluir o atributo correspondendo ao atributo multivalorado mais a chave primária da relação que tem esse atributo; (iii) incluir como chave primária da nova relação a combinação do atributo multivalorado  mais a chave primária da entidade que tinha o atributo multivalorado.

Através da Figura 1, tem-se o atributo multivalorado fone. Deve ser criada uma nova tabela FONE_PROFESSOR e incluir o atributo multivalorado fone e a chave primária da Relação PROFESSOR que tem esse atributo multivalorado. A combinação do atributo multivalorado e a chave primária da Relação PROFESSOR formarão a chave primária da tabela resultante.

A seguir é apresenta a implementação das tabelas mapeadas.

Create table PROFESSOR
   (codp number not null,
    nome varchar(30),
    constraint pk PROFESSOR primary key(codp));
/
Create table PROFESSOR FONE
   (codp number not null,
    Fone varchar(10),
    constraint pk_PROFESSOR_FONE primary key(codp,fone),
    constraint fk PROFESSOR FONE_pk_PROFESSOR foreign key(codp) references        PROFESSOR);
/
Create table DISCIPLINA
   (codd number not null,
    nome varchar(30),
    codp number,
    constraint pk_DISCIPLINA primary key(codd),
    constraint fk_DISCIPLINA_pf_PROFESSOR foreign key(codp) references PROFESSOR);
/
Create table ALUNO
    (coda number not null
,
   
nome varchar(30),
     constraint pk_ALUNO primary key(coda));
/
create CURSA
    (codd number not null,
     coda number not null,
     ano number not null,
     constraint pk_CURSA primary key(codd,coda,ano),
     constraint fk_CURSA_pk_DISCIPLINA foreign key(codd) references DISCIPLINA,
     constraint fk_CURSA_pk_ALUNO foreign key(coda) references ALUNO);

Na implementação acima, foram criadas as tabelas e as restrições de integridade das mesmas.

Implementação Objeto-Relacional

Nesta seção é mostrado como pode ser implementado através da tecnologia objeto relacional o exemplo da Figura 1. Os conceitos de tabelas de objetos, tabelas aninhadas, tipo referência são alguns conceitos que serão mostrados. A tabela de objetos é construída onde seus campos são instâncias de objetos.

Uma tabela aninhada é aquela que aparece como uma coluna em uma outra tabela, embora você possa realizar nela as mesmas operações que em outras tabelas. As vantagens de utilizar tabelas aninhadas são que os campos não precisam mais ser tipos primitivos e podem ser objetos. Vale ressaltar que a criação de um campo lista, onde o repositório será homogêneo de elementos é fazer um campo vetor. As tabelas aninhadas permitem acrescentar uma coleção esparsa de tamanho variável, para um objeto ou como campo de uma tabela. Não é possível acrescentar novas colunas em tabelas de objetos. Uma tabela aninhada não pode conter outra tabela aninhada.

create or replace type fone T as table of varchar2(10);
 /
create or replace type professor T as object (
     codp number,
     nome varchar2(30),
     fone fone T
     )
 /
create table professor of professor T (primary key (codp))
     nested table fone store as fones ST;
/

 Na modelagem relacional, para o atributo multivalorado foi criada uma nova tabela.  Na implementação objeto-relacional anterior, foi criado um tipo fone_T como uma tabela do tipo varchar2(10), onde o campo alfanumérico tem dez posições. Para não criar uma nova tabela, repetindo os códigos, foi criada uma tabela aninhada fone do tipo fone_T ao objeto professor_T. A tabela de objetos professor do tipo professor_T, possui a tabela aninhada fone e os telefones de cada professor são armazenados fisicamente em fones_ST. O ”store as” indica o local físico da tabela aninhada.

As tabelas aninhadas são tabelas onde a primeira forma normal, no processo de normalização, não é respeitada. Ou seja, os domínios dos atributos de uma tabela podem ser atômicos ou ser outra tabela. Dessa forma, tabelas podem ser armazenadas dentro de tabelas. Através de tabelas aninhadas, um objeto complexo pode ser representado por uma única tupla.  A inclusão dos dados é dada pelo comando a seguir.

Insert into professor values
     (professor_t(1,'Salete',fone T('3229-3579', '9101-1878', '3220-3256')));
/  

Para listar os telefones é necessário utilizar o alias predefinido column_value e a função the.

select column value fone from
     the (select fone from professor where codp = 1);
/

O tipo disciplina_T foi criado e o codp faz referência, através do tipo ref, a uma instância de objeto. Tabelas criadas sem o ref implica em redundância. Se um professor lecionasse 5 (cinco) disciplinas implicaria na repetição de seus dados 5 (cinco) vezes. Tabelas de objetos criadas através do tipo referência permite que um atributo seja referência a objeto do tipo especificado.

create or replace type disciplina T as object (
     codd   number,
     nome   varchar(30),
     codp ref professor T
     )
/
create table disciplina of disciplina T (primary key (codd));
/

A inclusão dos dados é dada pelo comando a seguir.

insert into disciplina
     select disciplina_t(1,'Banco de Dados',ref(p))
     from professor p where codp = 1;
/

Para listar o nome da disciplina e o professor que a ministra, uma comparação deve ser feita entre o código do professor da disciplina e a referência ao objeto professor.

select d.nome, p.nome from disciplina d, professor p
     where d.codp = ref(p);
/

Para criar a tabela representando o relacionamento N:N, a primeira alternativa é criar o tipo aluno_T. Em seguida, criar a tabela de objetos aluno.  

create or replace type aluno T as object (
     coda number,
     nome varchar(20))
/
create table aluno of aluno T(primary key(coda));
/

create table aluno disciplina
     (coda number not null,
      codd number not null,

      ano number,
      constraint PK aluno disc primary key(coda,codd,ano),
      constraint FK aluno disc_PK aluno foreign key(coda) references aluno,
      constraint FK aluno disc_PK disc foreign key(codd) references disciplina);
/

A tabela aluno_disciplina foi criada da mesma forma que no modelo relacional. O tratamento de tabela de objetos é o mesmo que tabelas no relacional. Cria-se a restrição de integridade chave primária e chaves estrangeiras.

Outra alternativa seria criar um tipo aluno_disciplina_T usando o tipo ref, onde fará referência às instâncias de objeto aluno_T e professor_T.

create or replace type aluno disciplina T as
     object
     (coda ref aluno_T,
      codd ref disciplina_T
      data number);
/
create table Aluno Disciplina of aluno disciplina T;
/

Vale ressaltar que uma vez criada uma tabela de objetos, seus campos são instâncias dos objetos. A inclusão dos objetos é dada pelo comando a seguir.

insert into aluno values (aluno T(1, 'Juliano'));
/

insert into Aluno Disciplina
     select aluno disciplina_t(ref(a),ref(d),2005)
     from aluno a, disciplina d where coda = 1 and codd = 1;

Para listar o nome da disciplina e os alunos que estão participando da mesma, uma comparação deve ser feita entre o código da disciplina e a referência a instância de objeto aluno.

select d.nome, a.nome from disciplina d, aluno a, aluno_disciplina ad
  where ad.codd = ref(d) and
        ad.coda = ref(a) and
        ano = 2005;
/ 

O comando anterior listará o nome de da disciplina e todos os alunos matriculados na referida disciplina, no ano de 2005.

Conclusões

Com a tecnologia objeto relacional é possível usar tipos dentro de tipos. Neste artigo foi apresentada a implementação de um exemplo, a partir do seu projeto, na forma relacional e objeto-relacional. Num próximo artigo iremos mostrar implementações utilizando outros conceitos da tecnologia objeto-relacional, tais como vetores variáveis.

Um grande abraço, Salete.

E-mail: salete@uepg.br

Web: http://www.deinfo.uepg.br/~salete

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?