Trabalho de Graduação em Banco de Dados



Baixar 162.92 Kb.
Página1/7
Encontro07.08.2016
Tamanho162.92 Kb.
  1   2   3   4   5   6   7



Trabalho de Graduação em Banco de Dados





Project Plan de Mapeamento de Classes em Tabelas em Banco de dados Objeto - Relacional

Aluno : Rodrigo Marcel Siqueira de Arruda

Orientadora : Ana Carolina Salgado



Índice

1. Descrição do Paradigma Objeto-Relacional 4

1.1 Introdução 4

1.2 Características fundamentais 4

1.3 Extensibilidade dos tipos básicos 4

1.4 Implementação de objetos complexos 6

1.5 Suporte à herança 6

1.6 Definição de Regras 7

2. Descrição do Estudo de Caso 8

2.1 Funcionalidades Necessárias 8

2.2 Cadastros da Aplicação 9

2.2.1 Cadastro de Usuário 9

2.2.2 Cadastro de Instituições 9

2.2.3 Cadastro de Cursos 9

2.2.4 Cadastro de Aluno 9

2.3 Módulo de controle de acesso 9

2.4 Módulo de realização de solicitações 9

2.5 Módulo de Cancelamento de solicitações 9

2.6 Módulo de confecção de carteiras 10

3. Estudo de Caso 10

3.1 Diagrama de classes [6] 10

3.2 Descrição do diagrama de classes 11

3.2.1 Classe pessoa 11

3.2.2 Classe usuario 11

3.2.3 Classe endereco 11

3.2.4 Classe listaTelefones 11

3.2.5 Classe telefone 11

3.2.6 Classe estudante 12

3.2.7 Classe fotografia 12

3.2.8 Classe instituição 12

3.2.9 Classe listaCursos 12

3.2.10 Classe curso 12

3.2.11 Classe solicitacao 12

4. O SGBD Oracle 8i 12

4.1 Interface relacional + interface Objeto-Relacional 13

4.2 Extensão de tipos 13

4.2.1 BINARY_INTEGER 14

4.2.2 NUMBER 14

4.2.3 PLS_INTEGER 14

4.2.4 CHAR e NCHAR 14

4.2.5 VARCHAR2 e NVARCHAR2 15

4.2.6 LONG E LONG RAW 15

4.2.7 RAW 15

4.2.8 ROWID e UROWID 15

4.2.9 LOB 16

4.2.10 BOOLEAN 16

4.2.11 DATE 16

4.2.12 REFERENCE TYPES e COMPOSITE TYPES 16

4.3 Objetos Complexos 17

4.3.1 Object type 17

4.3.2 Referências 17

4.3.3 Coleções 17

4.3.4 Object tables 18

4.4 Herança 18

4.5 Regras 18

5. Implementação do Estudo de Caso no Oracle 8i 19

5.1 Tipo fotografia 19

5.2 Tipo Endereco 19

5.3 Tipo Telefone 19

5.4 Tipo ListaTelefones 19

5.5 Tipo Curso 19

5.6 Tipo Referencia para curso 20

5.7 Tipo ListaCursos 20

5.8 Tipo Instituicao 20

5.9 Tipo Pessoa 20

5.10 Tipo Estudante 20

5.11 Tipo Usuario 21

5.12 Tipo Solicatacao 21

5.13 Object table Pessoa 21

5.14 Object table Estudante 21

5.15 Object table Usuario 21

5.16 Object table Instituicao 22

5.17 Object table Solicitacao 22

5.18 Object table Curso 22

6. Considerações sobre a implementação do estudo de caso 22

7. Conclusões 23

8. Referências 26





1.Descrição do Paradigma Objeto-Relacional

1.1Introdução

Quando surgiram os primeiros bancos de dados orientados a objetos, muitas pessoas acharam que seria o fim do modelo relacional, que haveria uma nova revolução já que no paradigma orientado a objetos se tinha uma maneira muito mais natural para se modelar qualquer objeto do mundo real. Objetos complexos que antes eram um verdadeiro tormento para os analistas seriam tratados como quaisquer outros objetos, com seus atributos e métodos próprios.

Essa impressão começou a ser modificada quando se viu que esses bancos de dados, por serem totalmente diferentes dos bancos relacionais, estavam muito aquém dos bancos relacionais em características fundamentais que os clientes exigiam como robustez, performance, capacidade de armazenamento, facilidade de consultas ad-hoc, entre outras, que os bancos relacionais forneciam. Isto se verificava porque os bancos relacionais tinham anos de desenvolvimento e aperfeiçoamento constante, e todo esse know how, tinha que ser jogado fora para se começar tudo de novo com os bancos orientados a objetos.

Essa mudança brusca de paradigma não agradou em nada nem os clientes, que estavam acostumados com todas as facilidades e potencialidades dos grandes bancos relacionais, nem as empresas que haviam investido milhões de dólares em anos de desenvolvimento dos bancos relacionais e teriam que começar tudo de novo.

Nesse contexto é que nasce o paradigma Objeto-Relacional que veio com a proposta de suprir as carências do modelo relacional, dando para o cliente toda a naturalidade para modelar objetos complexos e suas características peculiares que os bancos de dados orientados a objetos propunham, e ao mesmo tempo não abrindo mão de toda carga tecnológica desenvolvida para os bancos relacionais em anos de desenvolvimento. A proposta é dar ao cliente uma interface orientada a objetos e de forma transparente para esse, modelar tudo usando o paradigma relacional.

Outra vantagem dos bancos de dados Objeto-Relacionais é que eles continuam oferecendo uma interface relacional, para as aplicações que foram desenvolvidas no paradigma relacional, dispensando assim a necessidade de dois bancos de dados, um para as aplicações relacionais e outro para aplicações orientadas a objetos.



1.2Características fundamentais

Um banco de dados deve prover quatro características básicas para ser considerado um SGDB Objeto-Relacional : Estender os tipos básicos, implementar objetos complexos, permitir herança de dados e funções e permitir a criação de regras [4].



1.3Extensibilidade dos tipos básicos

A extensibilidade dos tipos básicos e a primeira das quatro características fundamentais de um banco de dados Objeto-Relacional. SQL-92 restringe os tipos de dados de uma determinada coluna como: inteiro, número de ponto flutuante, string de caracteres fixos ou variáveis, data ou numérico. Sobre esses tipos, SQL-92 define um conjunto restrito de funções e operadores para cada tipo. Esse conjunto restrito de tipos de dados torna a representação de muitos objetos do mundo real extremamente difícil, com performance comprometida, ou em alguns casos, torna a modelagem impossível.

Os tipos de dados extensíveis dos bancos de dados Objeto-Relacionais eliminam os problemas de modelagem de tipos complexos que em bancos de dados relacionais freqüentemente causam ineficiência, pois não são modelados de maneira natural, mais através de simulações com os tipos básicos restritos.

Em um banco de dados Objeto-Relacional pode-se criar um novo tipo de dado que modela de exatamente o objeto do mundo real, definindo-se o nome do tipo, informações sobre a forma de armazenamento do tipo, e as rotinas que converterão o novo tipo em ASCII e de ASCII para o novo tipo. Um exemplo disso é a sentença:


Create type NOVO_TIPO (

Internallegth = 8,

Imput = FUNCAO_DE_ENTRADA

Output = FUNCAO_DE_SAIDA);

Neste exemplo o nome do novo tipo criado é NOVO_TIPO, este tipo irá ser tratado a partir do momento de sua criação como qualquer tipo básico do banco de dados, como um inteiro, string ou data, sendo considerado apenas mais um tipo para o banco. Outro atributo definido em “Internallegth=8” é que o banco de dados deve reservar oito bytes para cada nova instância criada desse novo tipo. Adicionalmente a definição acima indica que duas funções chamadas aqui de “FUNCAO_DE_ENTRADA” e “FUNCAO_DE_SAIDA” que serão chamadas para converter instâncias do novo tipo para ASCII. Essas rotinas de conversão permitem grande flexibilidade para gerenciar os valores que o novo tipo pode assumir. O cliente pode definir qualquer tipo de função para transformar o dado passado ao novo tipo em uma representação de oito bytes no banco, bem como transformar a representação dos oito bytes mantida pelo banco em caracteres ASCII. Essas funções podem, por exemplo, prover algum tipo de limite aos dados de entrada, executar algum algoritmo de criptografia para segurança dos dados, fazer alguma checagem de consistência antes do armazenamento ou pode até, se o cliente que as definiu quiser, fazer as operações mais bizarras como mudar o conteúdo do dado armazenado retornando qualquer coisa, diferente do que foi armazenado, quando de uma consulta.

Depois de definido um novo tipo a ser guardado no banco de dados, é preciso definir as funções e operações que poderão ser realizadas sobre o novo tipo definido. Num banco de dados relacional quando se tem um dado do tipo inteiro, por exemplo, se pode realizar um conjunto particular de funções e operações sobre esse tipo como a função “SUM()”, que retorna o somatório de determinada coluna de uma tabela. Note que se o tipo fosse string, não se poderia aplicar a função “SUM()”, pois esta não está definida para este tipo.

Em um banco de dados Objeto-Relacional o cliente pode definir todas as funções e operações que podem ser realizadas sobre o seu novo tipo definido. No exemplo anterior, o cliente poderia definir, por exemplo, uma função “SUM()” para o tipo NOVO_TIPO definido anteriormente. Note que era de se esperar que o comportamento da função “SUM()” sobre o NOVO_TIPO se assemelhasse com o comportamento da mesma função para o tipo inteiro, mas esse comprometimento semântico não é de forma nenhuma exigido pelo banco de dados.

Da mesma forma que as funções, as operações sobre o novo tipo também terão de ser definidas pelo criador do tipo, essas operações deverão ser definidas de acordo com o comportamento do objeto no mundo real.

Tanto operações quanto funções poderão ser definidas usando SQL ou outro tipo de linguagem de programação de alto nível que o SGDB suporte. Depois de criadas as funções e operações em uma linguagem qualquer de alto nível, essas funções e operações deverão ser carregadas para o SGBD através de sintaxe definida por cada fabricante. As linguagens de alto nível aceitas pelos sistemas de bancos de dados Objeto-Relacionais também variam de fabricante para fabricante.




  1   2   3   4   5   6   7


©principo.org 2016
enviar mensagem

    Página principal