UML Unified Modeling Language

Transcrição

1 Sistemas de Informação I UML Unified Modeling Language Implementação com BD Relacionais (jcorreia@ispgaya.pt) 2001 Mário Santos (msantos@ispgaya.pt) 2002

2 Introdução Do Projecto à Implementação Vários modelos UML contribuem com informação para a fase de escrita de código Os modelos estruturais contêm a maior parte da estrutura declarativa: - especificação das classes - atributos - hierarquia de herança - associações Os modelos dinâmicos especificam a estratégia de alto-nível para controlo do sistema: - por procedimentos - por eventos - multi-tarefa Os modelos de arquitectura orientam na organização física e lógica do código UML Implementação com Bases de Dados Relacionais 2

3 Conceitos gerais... Alternativas de Implementação Linguagens de Programação Orientadas por Objectos - a forma mais natural e simples de implementar um projecto OO Linguagens de Programação tradicionais - a inexistência de conceitos de objectos neste tipo de linguagens, como por exemplo, a falta de suporte ao mecanismo de herança, obriga a um esforço adicional na fase de implementação Bases de Dados - a versatilidade do paradigma OO permite o projecto não só de sistemas e programas como também de bases de dados, sejam elas hierárquicas, reticuladas, relacionais ou orientadas por objectos - as bases de dados relacionais são um tipo importante considerar, devido à sua popularidade - embora não tão populares, as bases de dados orientadas por objectos são importantes para diversas áreas de aplicação UML Implementação com Bases de Dados Relacionais 3

4 Bases de Dados Relacionais O mapeamento para Bases de Dados Relacionais (BDR s) não é único existem duas formas de mapear uma associação; existem três formas de mapear uma generalização; é necessário adicionar detalhes que não existem no modelo de objectos, tais como, chaves primárias e chaves candidatas, se um atributo pode ter valores nulos ou não; obriga à atribuição de um domínio a cada atributo; obriga a listar os atributos mais frequentemente acedidos; Identificadores de Objectos (O s) Por várias razões, entre as quais a simplicidade, recorre-se a atributos s, para mapear o conceito de identificador de objecto implícito à noção de objecto. A utilização de s possui vantagens (imutabilidade, independência, estabilidade) e desvantagens (conflituam com a intenção original das BDR s de manipular informação com base nos seus valores). UML Implementação com Bases de Dados Relacionais 4

5 Classes e tabelas de bases de dados A transformação das classes em tabelas da base de dados obedece a um conjunto de regras simples. A representação das tabelas segue a notação Tabela( chaveprimária, campo1, campo2, chaveestrangeira,...) A ordem de tratamento das diversas hipóteses é a seguinte: classes subclasses associações UML Implementação com Bases de Dados Relacionais 5

6 Classes Cada classe é mapeada para uma ou mais tabelas a tabela terá os mesmos atributos que a classe respectiva, mais o atributo referente ao identificador de objecto; decide-se para cada atributo da tabela se poderá ou não ter valores nulos; atribui-se a cada atributo um domínio, pré-definido ou definido pelo utilizador. Tabela Pessoa Pessoa Atributo ulos? Domínio morada idade pessoa_ morada idade ome Endereço Idade Chave candidata: (pessoa_) Chave primária: (pessoa_) Atributos mais acedidos: (pessoa_) () UML Implementação com Bases de Dados Relacionais 6

7 Associações Binárias Associações As associações entre classes podem ser traduzidas no modelo relacional de diversas formas: - com chaves estrangeiras; - com tabelas de relação; - etc. A seguir vamos referir alguns exemplos. Em geral, uma associação pode ou não ser mapeada para uma tabela, dependendo: do tipo e multiplicidade da associação das preferências do projectista em termos de extensibilidade, número de tabelas e compromissos de performance UML Implementação com Bases de Dados Relacionais 7

8 Associações de um para um As associações de um para um podem, em geral, transformar-se em chaves estrangeiras numa, ou em ambas, as tabelas relacionadas. Por exemplo, no nosso sistema judicial, uma pessoa só pode ser casada com uma outra pessoa. A figura seguinte poderia ser um modelo para esta situação. Este modelo podia transformar-se em: Pessoa numbi dataascimento é casada com Pessoa(pessoa_, numbi,, dataascimento, pessoa_conjuge) ote que pessoa_conjuge deverá referir uma outra pessoa que não a própria e, quando for preenchido, deverá ser obrigatório o preenchimento do mesmo campo da outra pessoa. UML Implementação com Bases de Dados Relacionais 8

9 Associações de um para um (cont.) Uma alternativa seria considerar-se uma tabela para pessoas (como anteriormente) e uma tabela extra para manter as associações entre pessoas casadas: ecasadacom( pessoa_marido, pessoa_mulher) este caso o casamento implicaria a criação de um registo nesta tabela e não um preenchimento intrincado de dois campos. Como se poderá ver mais à frente, esta solução é genérica e pode ser adoptada qualquer que seja a aridade da associação. ote-se que nesta solução, a tabela de relação possuiria apenas dois campos, ambos chaves primárias dessas tabelas, e chaves estrangeiras que apontam ambas para a mesma tabela - Pessoa. UML Implementação com Bases de Dados Relacionais 9

10 Associações de um para um (cont.) o caso da associação possuir atributos, estes integrar-se-ão, no primeiro caso, na própria tabela. Por exemplo, se interessar guardar a data do casamento, o modelo seria o que se mostra na figura seguinte: Para este caso, a tabela Pessoa poderia passar a ser: Pessoa( pessoa_, numbi,, dataascimento, pessoa_conjuge, datacasamento) datacasamento é casada com o caso de se considerar uma tabela em separado para a associação, esta seria: ecasadacom( pessoa_marido, pessoa_mulher, datacasamento) Pessoa numbi dataascimento UML Implementação com Bases de Dados Relacionais 10

11 Associações de um para muitos Uma associação um-para-muitos pode ser mapeada de 2 formas, em tabelas do modelo relacional: 1) adicionar uma chave-externa na tabela relativa a muitos (correspondente à chave da tabela do lado um ); 2) criação de uma tabela distinta para a associação. Exemplo: uma pessoa pode ter (pode ser dona de) zero ou mais carros (ver figura seguinte). UML Implementação com Bases de Dados Relacionais 11

12 Associações de um para muitos (cont.) este caso, a tabela com informação sobre os carros seria: Carro( carro_, numsérie, matrícula, anofabrico, pessoa_dona) A alternativa a esta solução seria a existência de uma tabela especificamente para representar a associação, como se fizera no ponto anterior. Poderia ser, por exemplo: PessoaPodeTerCarro( pessoa_, carro_) o caso da associação possuir atributos, estes ficarão na tabela do lado muitos da associação, ou na tabela correspondente a essa associação. Por exemplo, a data de aquisição de cada carro por cada pessoa, pode ser modelizada da forma como se mostra na figura seguinte. UML Implementação com Bases de Dados Relacionais 12

13 Associações de um para muitos (cont.) o primeiro caso, a tabela Carro passaria a ser: Carro( carro_, numsérie, matrícula, anofabrico, pessoa_dona, dataaquisição) o segundo, PessoaPodeTerCarro( pessoa_, carro_, dataaquisição) UML Implementação com Bases de Dados Relacionais 13

14 Associações Binárias (1 n)... Companhia morada proprietário bem 1 * Avião modelo nº série criação de uma tabela distinta data Compra não criação de uma tabela distinta Tabela Compra Atributo companhia_ avião_ data ulos? Domínio Data Tabela Avião Atributo avião_ modelo no_serie companhia_ data_compra ulos? Domínio Texto Texto Data Chave candidata: (avião_+companhia_) Chave primária: (avião_+companhia_) Atributos mais acedidos: (companhia_) (avião_) Chave candidata: (avião_) Chave primária: (avião_) Atributos mais acedidos: (avião_) (no_serie) (companhia_) UML Implementação com Bases de Dados Relacionais 14

15 Associações de muitos para muitos As associações de muitos para muitos são sempre representadas por uma tabela específica para essa associação. a chave primária será constituída pela concatenação das chaves primárias de cada uma das tabelas envolvidas na associação Por exemplo, o modelo de uma empresa que emprega uma ou mais pessoas e uma pessoa que pode estar empregada por nenhuma ou muitas empresas é o que se mostra na figura seguinte. A associação EmpresaEmpregaPessoas( empresa_, pessoa_), onde se utiliza a chave estrangeira para Empresa( empresa_, códigoempresa, ), permite portanto representar estas associações. UML Implementação com Bases de Dados Relacionais 15

16 Associações de muitos para muitos o caso de se pretender incluir atributos na associação de muitos para muitos, como se exemplifica na figura seguinte, a filosofia a seguir seria a já indicada para as restantes aridades. A tabela da associação seria definida como: EmpresaEmpregaPessoas( empresa_, pessoa_, datainicio, datafim, valorsalário). Empresa * emprega 1..* Pessoa numbi dataascimento datainicio datafim valorsalário UML Implementação com Bases de Dados Relacionais 16

17 Associações Binárias (n m) Companhia morada contratante contratado * * Contrato data de início Piloto morada brevete Tabela Contrato Atributo companhia_ piloto_ data_de_inicio ulos? Domínio Data Chave candidata: (companhia_+piloto_) Chave primária: (companhia_+piloto_) Atributos mais acedidos: (companhia_) (piloto_) UML Implementação com Bases de Dados Relacionais 17

18 Associações Ternárias Passageiro data nº voo Voo Lugar localização preço Preço Tabela Preço Atributo ulos? Domínio passageiro_ voo_ lugar_ preço Montante Chave candidata: (passageiro_+voo_+lugar_) Chave primária: (passageiro_+voo_+lugar_) Atributos mais acedidos: (passageiro_) (voo_) (lugar_) UML Implementação com Bases de Dados Relacionais 18

19 Agregações Tomemos como exemplo o modelo de Encomenda e respectivas linhas, mostrado na figura seguinte. O lado do losango costuma designar-se por todo e o outro por partes ou componentes. Encomenda dataencomenda numencomenda 1..* LinhaEncomenda quantidade dataentrega As tabelas resultantes deste modelo seriam: Encomenda( encomenda_, numencomenda, dataencomenda) LinhaEncomenda( linhaencomenda_, encomenda_, numlinha, quantidade, dataentrega) UML Implementação com Bases de Dados Relacionais 19

20 Agregações (cont.) O facto de se incluir a chave da tabela de Encomenda reforça a ligação entre estas duas entidades. ão faz sentido considerar linhas de encomendas sem o respectivo cabeçalho! Quando a agregação do lado do todo é opcional (aridade zero), a conversão deste tipo de associações é em tudo idêntico ao que foi abordado a propósito dos restantes tipos de associações. o caso em que o lado das partes da agregação possui aridade 1 (ou é opcional), é usual juntarem-se os atributos da parte na tabela do todo. UML Implementação com Bases de Dados Relacionais 20

21 Generalizações Existem três formas de se transformarem subclasses em tabelas de base de dados. Como exemplo, consideremos as classes Pessoa, Professor e Aluno da figura seguinte. Pessoa numbi dataascimento Professor valorsalario Aluno numero valorpropina UML Implementação com Bases de Dados Relacionais 21

22 Generalizações (cont.) A primeira forma possível para a transformação da super-classe e das suas duas subclasses em tabelas de uma base de dados relacional é considerar uma tabela para cada classe: Pessoa( pessoa_, numbi,, dataascimento) Aluno( pessoa_, número, valorpropina) Professor( pessoa_, valorsalário) ote-se que neste caso o campo pessoa_ é simultaneamente chave primária e estrangeira nas tabelas correspondentes às subclasses (Aluno e Professor). A principal desvantagem desta opção está no facto de, para se inserir um registo na tabela correspondente à subclasse, ser necessário inserir primeiro o registo na tabela correspondente à super-classe. Para se apagar um registo, o processo é inverso: primeiro deverá ser apagado o registo na tabela correspondente à subclasse, e depois na superclasse. A vantagem desta solução está sobretudo quando os objectos das subclasses podem existir simultaneamente (uma pessoa pode ser aluno e professor simultaneamente, por exemplo). UML Implementação com Bases de Dados Relacionais 22

23 Generalizações (cont.) Tabelas correspondentes às subclasses A segunda forma consiste em eliminar a tabela da superclasse e replicar todos os atributos dela em cada subclasse. Quando a super-classe é uma classe abstracta (nunca são criados objectos dela) e as subclasses não se sobrepõem (não há alunos que sejam também professores, por exemplo), é usual optar-se por ter uma tabela por cada subclasse, em que os atributos da super-classe são repetidos em cada uma das subclasses. este caso, seria: Aluno( aluno_, numbi,, dataascimento, número, valorpropina) Professor(professor_, numbi,, dataascimento, valorsalário) UML Implementação com Bases de Dados Relacionais 23

24 Generalizações (cont.) Tabela correspondente à super-classe A terceira forma de transformar uma super-classe e uma ou mais subclasse é colocar os atributos todos de todas as classes numa só tabela (correspondente à super-classe). o exemplo que tem sido seguido, seria: Pessoa( pessoa_, numbi,, dataascimento, número, valorpropina, valorsalário) Quando podem existir simultaneamente objectos de ambas as subclasses, esta opção é a melhor das três, embora se perca alguma semântica do modelo de objectos. UML Implementação com Bases de Dados Relacionais 24

25 Generalizações: Resumo 1. A superclasse e cada subclasse são mapeadas para tabelas distintas abordagem logicamente correcta e extensível; envolve várias tabelas, pelo que a navegação da superclasse para as subclasses pode-se tornar lenta. 2. Eliminação da navegação da superclasse-para-subclasse elimina a tabela da superclasse e replica todos os atributos dela em cada subclasse ideal, quando a superclasse possui poucos atributos e as subclasses muitos atributos; não se pode garantir a unicidade dos valores dos atributos da superclasse. 3. Uma tabela para a superclasse criação de apenas uma tabela para a superclasse; todos os atributos das subclasses são acrescentados à tabela da superclasse; cada subclasse utiliza apenas os atributos que lhe pertencem, deixando os restantes com valores nulos; viola a terceira forma normal; abordagem interessante quando em presença de poucas subclasses (2 ou 3). UML Implementação com Bases de Dados Relacionais 25

26 Generalizações: Caso 1 Tabela Pessoa Pessoa morada idade Atributo pessoa_ morada idade tipo_de_pessoa Tabela Passageiro ulos? Domínio ome Endereço Idade Tipo-Pessoa Atributo ulos? Domínio Passageiro nacionalidade Piloto brevete nº horas voo pessoa_ nacionalidade Tabela Piloto País Atributo ulos? Domínio pessoa_ brevete horas_de_voo Texto Inteiro UML Implementação com Bases de Dados Relacionais 26

27 Generalizações: Caso 2 Tabela Passageiro Atributo ulos? Domínio Pessoa morada idade pessoa_ morada idade nacionalidade ome Endereço Idade País Passageiro nacionalidade Piloto brevete nº horas voo Tabela Piloto Atributo pessoa_ morada idade brevete horas_de_voo ulos? Domínio ome Endereço Idade Texto Inteiro UML Implementação com Bases de Dados Relacionais 27

28 Generalizações: Caso 3 Passageiro nacionalidade Pessoa morada idade Piloto brevete nº horas voo Tabela Pessoa Atributo pessoa_ morada idade tipo_de_pessoa nacionalidade brevete horas_de_voo ulos? Domínio ome Endereço Idade Tipo-Pessoa País Texto Inteiro UML Implementação com Bases de Dados Relacionais 28