Modelagem Semântica e Gerenciadores de Banco de Dados

Modelagem Semntica e Gerenciadores de Banco de DadosRegina Lcia de Oliveira Moraes Instituto de Computao Universidade Estadual de Campinas UNICAMP e-mail: [email protected]

Resumo Modelos Semnticos surgiram devido necessidade de se captar, com um nvel de detalhamento maior, as propriedades de uma aplicao. Apesar de no terem atingido o nvel de aceitao esperado por parte da indstria, modelos semnticos so muito utilizados como ferramentas complementares no desenvolvimento de sistemas. Esse trabalho apresenta alguns dos modelos semnticos existentes na literatura, ressaltando suas particularidades e a sua traduo para os esquemas de gerenciadores de base de dados. Abstract Semantic Models were come about due to the necessity to capture, at a more detailed level, the properties of an application. Despite their inability to reach the acceptance levels expected by the industry, semantic models are very used as complementary tools in systems' development. This work presents some of the semantic models documented by the literature, highlighting their idiosyncrasies and translations for database management systems design.

1. INTRODUOA motivao que impulsionou o desenvolvimento de sistemas de banco de dados foi a busca da flexibilidade e da eficincia no compartilhamento, gerenciamento, recuperao e armazenamento de grandes massas de dados, permitindo o compartilhamento e utilizao concorrente, a reduo da redundncia e inconsistncia dos dados, provimento de segurana e confiabilidade, proteo dos dados contra acessos perniciosos, fornecimento de mecanismos de recuperao em caso de falhas, permisso para incorporar e manter algumas restries pelo sistema de banco de dados. Os primeiros modelos que surgiram guardavam uma relao bastante estreita com a estruturao fsica dos dados. Com o modelo relacional, surge uma linguagem de manipulao e o conceito de independncia fsica dos dados. Embasado no conceito de relaes que descrevem entidades e relacionamentos, utilizam os valores de atributos e no mais ponteiros para definir os relacionamentos existentes. As propriedades de uma aplicao de banco de dados podem ser agrupadas em dois aspectos: estrutural e comportamental. O aspecto estrutural compreende os tipos de dados, relacionamentos e restries que podem ser necessrias sobre os dados; o aspecto comportamental representa as operaes e transaes que interagem sobre as entidades e relacionamentos. Os aspectos comportamentais, na maioria dos modelos existentes, so relegados s aplicaes. Esses modelos tm um conhecimento muito restrito a respeito do significado dos dados. Compreendem certos valores atmicos simples, certos relacionamentos, mas pouco mais alm disso, seria interessante se os sistemas compreendessem um pouco mais, de maneira que pudessem responder, com inteligncia, as interaes dos usurios. Embora tenha se firmado como um modelo de referncia na rea de banco de dados, no faltam crticas ao modelo relacional, no que se refere representao adequada dos diversos

MO 410 Banco de Dados

2

relacionamentos que existem numa aplicao. Numa tentativa de suprir essa deficincia surgem os modelos semnticos [1] [2], que propiciaram uma melhor captao das propriedades de uma aplicao. Infelizmente, esses modelos ainda no obtiveram o reconhecimento da indstria, que ainda hoje se apia, em sua grande maioria, nos modelos relacionais. Apesar disso, diversas pesquisas tm sido desenvolvidas nesse campo objetivando o desenvolvimento de conceitos que possam melhor representar as propriedades das aplicaes e dessa forma, a modelagem semntica tem sido difundida. O objetivo desse trabalho apresentar alguns modelos semnticos que so encontrados na literatura e a maneira como feito o mapeamento desses modelos para o sistema de banco de dados visando a persistncia desses dados juntamente com seus aspectos comportamentais. No captulo 2 so comentados alguns trabalhos relacionados que embasaram esse trabalho. Alguns modelos semnticos foram destacados no captulo 3, enquanto que no captulo 4 foram expostos alguns aspectos da traduo dos modelos apresentados para gerenciadores de banco de dados. Uma breve concluso apresentada no captulo 5.

2. TRABALHOS RELACIONADOSEsse trabalho foi fortemente influenciado pela dissertao de mestrado apresentada no Instituto de Computao [10], que props uma interface que estende a capacidade de captao semntica dos gerenciadores de banco de dados relacionais. Alguns dos modelos apresentados na dissertao suscitou o interesse para a pesquisa desse trabalho. Outros modelos foram acrescentados, como o modelo MEASUR [17] que utilizado por alunos e pesquisadores na rea de inteligncia artificial e que tambm foi pesquisado a partir de outra dissertao de mestrado do Instituto de Computao[16]. Alm desses, foi acrescentado o modelo UML uma vez que esse modelo tem apresentado um crescimento acentuado para a modelagem de banco de dados[6] [7] [9] [13].

3. MODELOS SEMNTICOSAlgumas definies ressaltam a importncia do significado da informao para os seres humanos que iro utiliz-las. Esses seres humanos interagem com os objetos existentes no mundo real, tm deles uma noo de contexto onde se inserem e que comportamento tm nesse contexto. Uma aplicao de negcios representa aspectos infinitamente ricos e complexos, o que faz da extrao de requisitos uma tarefa rdua. Modelos grficos auxiliam o entendimento e diminui a ambigidade existente na linguagem natural, sendo um forte aliado para a validao dos requisitos junto aos clientes. Os modelos relacionais, devido a sua estrutura baseada em registro, tm dificuldades de representar algumas caractersticas que normalmente esto presentes no comportamento dos objetos que representa. Dificuldades so apresentadas quando h variaes nos atributos, restrio de domnio do conjunto de objetos e a dificuldade de representar os diversos aspectos semnticos que envolvem os objetos no mundo real. Devido a essas dificuldades, surgiram os modelos semnticos. Modelos semnticos tm como objetivo a representao de determinada parte do mundo real, sendo assim, o que se busca que o modelo produzido traduza de maneira mais prxima possvel os objetos que ele representa. Segundo Date [3], a modelagem semntica uma classificao apropriada para a atividade de representar o sentido e so caracterizadas por: (i) identificao de um conjunto de conceitos semnticos que parecem teis ao se falar do mundo real; (ii) determinao de um conjunto de objetos simblicos (formais) correspondentes para Modelagem Semntica de Dados


3

representarem aqueles conceitos semnticos; (iii) determinao de um conjunto de regras de integridade ao lado dos objetos simblicos; (iv) desenvolvimento de um conjunto de operadores para a manipulao daqueles objetos simblicos. Por ter como base um contexto e a semntica que cada objeto tem para um determinado grupo de usurio dentro desse contexto, um determinado objeto no mundo real pode muito bem ser considerado uma entidade por algumas pessoas e propriedades por outras e ainda associao por outras. Uma das metas da modelagem semntica suportar tal flexibilidade de interpretao.

3.1. MODELO ENTIDADE-RELACIONAMENTOUma das principais propostas da rea de modelagem semntica e certamente uma das propostas de maior influncia foi o modelo de entidade-relacionamento proposto por Chen[1]. Um dos modelos com maior capacidade semntica, o modelo tem por base a percepo de que o mundo real formado por um conjunto de objetos chamado entidades e pelo conjunto de relacionamentos entre esses objetos. Um conjunto de entidades um conjunto de entidades de um mesmo tipo que compartilham as mesmas propriedades, ou seja, tm os mesmos atributos. Atributos so propriedades descritivas de cada entidade. Formalmente, um atributo de um conjunto de entidades uma funo que relaciona o conjunto de entidades a seu domnio [15]. Da maneira como usado no modelo entidade-relacionamento um atributo pode ser caracterizado como simples ou compostos (podem ser divididos em outros atributos), monovalorados ou multivalorados (possuem um conjunto de valores para uma nica entidade), nulos (ausncia de valor) e derivados (valor derivado de outros atributos ou entidades). Uma superchave um conjunto de um ou mais atributos que, tomados coletivamente, nos permitem identificar de maneira nica uma entidade em um conjunto de entidades e so chamadas chaves candidatas quando nenhum subconjunto dela prpria uma superchave. A chave candidata que melhor caracteriza um conjunto de entidades escolhida pelo projetista como a chave primria. Quaisquer duas entidades de um conjunto de entidades no podem ter, simultaneamente, os mesmos valores em sua chave primria. Quando no possvel identificar uma chave candidata para um dado conjunto de entidades, pode-se gerar um nmero para desempenhar essa funo e nesse caso dizemos que foi criado um surrogate. Um conjunto relacionamento um conjunto de relacionamentos de mesmo tipo. De maneira formal, a relao matemtica com n 2 conjuntos de entidades, podendo ser ou no distintos [15]. Chama-se participao, a associao entre os conjuntos de entidades. Uma instncia de relacionamento em um esquema entidade-relacionamento representa a existncia de uma associao entre essa entidade e o mundo real. Papel o nome que se d funo desempenhada por uma entidade em um relacionamento. O nmero de entidades participantes do relacionamento define o grau do relacionamento. Um relacionamento tambm pode apresentar atributos descritivos. Restries de negcio fazem parte de qualquer problema real. Uma restrio importante o mapeamento das cardinalidades que expressa o nmero de entidades s quais outra entidade pode estar associada atravs de um conjunto de relacionamentos. Para conjuntos de relacionamentos binrios podemos ter entre os conjuntos de entidades A e B, cardinalidade Um para Um, Um para Muitos, Muitos para Um e Muitos para Muitos. Essas cardinalidades dependem da semntica das situaes reais que est sendo modelada. Em muitas situaes reais, a existncia da entidade A depende da existncia da entidade B, ento A dita dependente da existncia de B, implicando na destruio de A quando B destrudo. A entidade B, nesse caso, dita entidade dominante (ou forte) e a entidade A dita entidade subordinada (ou fraca) e esta deve fazer parte de um conjunto de relacionamentos um para muitos com a entidade forte que a define. Modelagem Semntica de Dados


4

Toda estrutura lgica do banco de dados pode ser expressa graficamente atravs de um diagrama, o Diagrama Entidade-Relacionamento(DER). Esse diagrama composto por retngulos, que representam os conjuntos de entidades, elipses, que representam os atributos, losangos, que representam os conjuntos de relacionamentos, linhas, que unem os atributos aos conjuntos de entidades e os conjuntos de entidades aos conjuntos de relacionamentos, elipses duplas, que representam atributos multivalorados e retngulos em linhas duplas que representam entidades fracas. A notao do DER difere de autor para autor, assim, o exemplo da Figura 3.1, apresenta o diagrama utilizando a notao apresentada por [5] e representa parte de um modelo para o controle de txis conforme a especificao descrita no anexo A.MotoristaN

Fila Taxi

1

Taxi

Placa Marca Mod Ano

N CNH nome CNHvalid Fone Zona

DataHoraIn KMIn

Zona

Figura 3.1: Diagrama Entidade-Relacionamento Apesar de ser possvel representar a maioria dos bancos de dados apenas com os conceitos bsicos do modelo entidade-relacionamento, foi criado mais tarde por Teorey[18] e seus co-autores, uma extenso desse modelo. No modelo estendido, abstraes como generalizao, especializao, agregao, restries de projetos, como participao parcial ou total, representao para atributos multivalorados, compostos e derivados ganharam representao. A Figura 3.2 mostra uma abstrao de generalizao/especializao e uma agregao (MT) segundo a notao apresentada em [4].MT

Motorista

1

1

Dirige

N

1

Taxi

md

VanFigura 3.2: Modelo entidade-relacionamento estendido

Sedan

O modelo entidade-relacionamento estendido agregou bastante significado de representao modelagem de dados, tornando-se um modelo semntico bastante completo e representativo para esse tipo de modelagem.

Modelagem Semntica de Dados


5

3.2. RM/TO modelo relacional ampliado RM/T foi primeiramente definido por Codd [2]. Uma diferena entre RM/T e o modelo entidade-relacionamento, que o RM/T no faz distines desnecessrias entre entidades e relacionamentos que so considerados um tipo especial de entidade. Outras diferenas observadas so que os aspectos estruturais e de integridade do modelo so mais ampliados e definidos de forma mais precisa no RM/T. O modelo inclui seus prprios operadores especiais, alm dos operadores do modelo relacional bsico. O funcionamento do modelo implica [3]: entidades so representadas por relaes E, que registram a existncia das entidades e relaes P que registram certas propriedades dessas entidades. pode existir uma variedade de relacionamentos entre as entidades (associaes, subtipos, etc.). O RM/T inclui uma estrutura de catlogo formal atravs do qual o sistema toma conhecimento dos relacionamentos (restries de integridade). existem vrios operadores de alto nvel para facilitarem a manipulao dos vrios objetos RM/T (relaes E, relaes P, relaes de catlogo, etc.). So trs as categorias de entidades representadas no sistema: entidades-semente, so as entidades que tm existncia independente. entidades-caractersticas, descrevem ou caracterizam uma outra entidade. So entidades dependentes da existncia da entidade que descrevem. entidades-associativas, representam o relacionamento de muitos para muitos entre duas ou mais entidades. As entidades podem ter propriedades e qualquer entidade pode ter uma propriedade cuja funo seja identificar ou atribuir outra entidade relacionada. No RM/T todas as chaves primrias e externas so substitutos, que gerado sempre que um novo representante de entidade criado. Esse valor gerado nico com relao a todos os valores substitutos que existem ou j existiram no banco de dados e tem a garantia que nunca vai mudar (surrogate). A relao E de cada entidade contm os surrogates de todas as suas instncias. Esse surrogate a base de todas as referncias dentro do sistema. Cada entidade pode ter quantas relaes P forem necessrias para representar suas propriedades, sendo todas elas ligadas relao E da mesma entidade atravs do surrogate. O modelo, atravs de regra de integridade, probe que exista uma tupla em qualquer relao P sem que haja um surrogate relativo a essa tupla na relao E da entidade. A figura 3.3 exemplifica as relaes E e P para o exemplo do Txi. TAXI TAXI_MOTORISTA 325 368 ..... ..... 325 368 .... .... Mrio Lus ..... ....

Figura 3.3 Representao RM/T da relao E de Txi e seu relacionamento com Motorista

O relacionamento de subtipo /supertipo tambm pode ser representado no RM/T. Todas as propriedades do supertipo se aplicam automaticamente ao subtipo, mas no o oposto. O modelo RM/T inclui diversas regras de integridade novas e preservam as regras existentes no modelo relacional bsico. So elas[3]: (i) integridade de entidade as relaes E aceitam inseres e eliminaes, mas no atualizaes; (ii) integridade de propriedade se uma Modelagem Semntica de Dados


6

tupla t aparecer na relao P, ento o valor da chave primria de t deve aparecer na relao E correspondente a P; (iii) integridade de caracterstica a entidade caracterstica no pode existir, a menos que a entidade que a descreve tambm exista; (iv) integridade de associao uma entidade de associao no pode existir, a menos que cada entidade participante da associao tambm exista; (v) integridade de atribuio s pode existir se a entidade que atribui tambm existir no banco de dados; (vi) integridade de subtipo sempre que um substituto aparecer na relao E para uma entidade do tipo A, esse substituto tambm deve aparecer na relao E para qualquer tipo de entidade A, para a qual A represente um subtipo. Alm do conjunto de objetivos e regras descritos, o que distingue o RM/T da maioria de outras propostas na rea de modelagem semntica o conjunto de operadores que inclui. Estes operadores permitem, entre outras coisas, a definio de vises do usurio bastante ampla sobre o banco de dados bsico comum. O RM/T proporciona um operador nico, o operador Propriedade, cujo efeito reunir todas as propriedades imediatas para um tipo de entidade especfica numa nica relao n-ria. Um modelo ampliado como o RM/T pode ser til como auxlio ao projeto de banco de dados, contudo sua complexidade ultrapassa em muito a complexidade do modelo relacional. Parte das extenses semnticas do RM/T so feitas no dicionrio de dados do modelo relacional, atravs de relaes que descrevem os inter-relacionamentos existentes junto a novos operadores.

3.3. SDMSDM uma descrio de alto nvel para banco de dados baseado em semntica, estruturado formalmente [5]. um modelo que objetiva a captura de mais significado do ambiente de uma aplicao, atravs de um conjunto de primitivas. Uma especificao em SDM descreve um banco de dados em termos do tipo de entidades que existe no ambiente da aplicao, a classificao e agrupamento dessas entidades e a interconexo estrutural entre elas. Por acomodar informaes derivadas na especificao da estrutura do banco de dados, SDM permite que a mesma informao possa ser vista de diferentes maneiras, fazendo com que seja possvel representar diretamente uma variedade de necessidades e requisitos de processamento tpicos de aplicaes de banco de dados. Uma descrio do banco de dados utilizando SDM poder ser utilizada como uma especificao formal e uma ferramenta de documentao para um banco de dados, podendo prover a base de apoio a uma variedade de interfaces de usurios e como modelo conceitual para banco de dados na fase de projeto. Assim, um esquema SDM uma coleo de entidades organizadas em classes e conexes entre as classes e atributos derivados. Nas classes so especificados os atributos dos membros e das classes. Existem dois tipos de conexes entre as classes, uma que representa o mecanismo de agrupamento e outro que representa o mecanismo de generalizao/ especializao. Para a conexo de uma associao, esto previstas trs formas de especificao [5]: (i) controlada pelo prprio usurio, (ii) baseada no valor comum de um determinado atributo da classe base, (iii) a partir de um conjunto de subclasses derivadas de uma mesma classe base. Um exemplo de uma especificao de associaes em SDM para o sistema do txi poderia ser a apresentada na Figura 3.4. A conexo que define subclasses determinada a partir de um predicado que a conecta s superclasses envolvidas. Esto disponveis quatro formas de especificao do predicado[5]: (i) baseada nos valores dos atributos da superclasse, (ii) baseado no atributo de uma classe que tem a superclasse como contra-domnio, (iii) definidas por operaes de conjunto (unio, interseco, etc..) entre superclasses derivadas a partir de uma mesma classe base, (iv) controlada pelo usurio (incluses e retiradas sob responsabilidade do usurio). Modelagem Semntica de Dados


7

MOTORISTAS_TAXI interclass conection: grouping of motoristas on common value of taxi description: conjunto dos motoristas agrupados por txi member attributes: datahorain value class: DATES. Kmin value class: INTEGER.

Figura 3.4: Representao de especificao de associao em SDM

Um exemplo de uma especificao de subclasses em SDM para o sistema do txi poderia ser o apresentado na Figura 3.5.TAXI_VAN interclass conection: subclass of TAXI where tipo = Van description: todos os txis que so Vans member attributes: lugares value class: INTEGER Figura 3.5: Representao de especificao de subclasse em SDM

O SDM pode ser considerado uma linguagem de especificao de esquema devido estrutura natural de sua sintaxe e a grande variedade de primitivas, mas a complexidade envolvida na sua especificao inibe a possibilidade de que seja implementado por um SGBD.

3.4. TAXISTAXIS [8] uma linguagem para projetos de sistemas de informao interativos, que integra a captao dos aspectos estruturais e comportamentais de uma aplicao atravs de mecanismos de abstrao. TAXIS oferece as facilidades do gerenciamento de banco de dados relacionais, um significado para a especificao semntica de restries de integridade e um mecanismo de tratamento de excees, integrado numa nica linguagem, atravs da qual os conceitos de classe, propriedade e relacionamento de generalizao so providos. Para descrever classes, os seguintes grupos de categorias esto disponveis[8]: (i) chaves identifica uma instncia, (ii) caractersticas agrupam as propriedades invariantes ao longo do tempo, (iii) atributos abrigam as propriedades que variam ao longo do tempo. TAXIS permite a definio de meta-classes para representar seus atributos gerais. Classes so sempre relacionadas atravs de mecanismos de especializao para facilitar a representao semntica. Oferece um conjunto pr-definido de classes a partir das quais novas classes podem ser especializadas. As operaes de banco de dados atuam sobre hierarquias de objetos. Existem trs objetos em TAXIS: tokens, representam constantes, classes, descrevem conjuntos de tokens que compartilham as mesmas propriedades e metaclasses, descrevem colees de classes e podem fornecer valores totalizados das classes que pertencem coleo. Na Figura 3.6, vemos um exemplo de especificao para a classe txi. A classe variableclass uma classe pr-definida que suporta um objeto do tipo relao. Modelagem Semntica de Dados


8

VARIABLE-CLASS TAXI with keys Taxi_id: Placa characteristics Placa: integer; Marca: string; Modelo: string; AnoFab: date; Attribute-properties: AnoFab: OVER 1960; end Figura 3.6: Especificao da classe Txi no modelo TAXIS

No modelo TAXIS, transaes so consideradas classes e podem ser especificadas a partir da especializao de outras transaes, atravs da especializao de parmetros que modela a parte esttica da aplicao e da redefinio dos procedimentos. Atravs de prrequisitos, aes e resultados, o usurio poder fatorar o corpo de uma transao em restries de validao (constraint checks) semi-independentes e aes que podem estar associadas com uma transao durante a definio da mesma ou indiretamente atravs de herana. Excees tambm podem ser vistas como classes e assim, podem ser especializadas. Toda exceo estar relacionada a um procedimento de resultado ou de pr-requisito e ser ativada sempre que os procedimentos resultem num valor falso (no true). O procedimento que chama a transao dever indicar qual a transao que dever ser invocada caso a exceo seja ativada. Por exemplo, a figura 3.7 define uma exceo txi_no_encontrado, associada ao pr-requisito existente?, e definir a transao apresenta_lista para tratar a exceo.TRANSACTION-CLASS Requisita_txi .. action Atende_Chamada: Obtem_txi(zona, datahorain) exec-handler Valida_txi for txi_no_encontrado is apresenta_lista ..

Figura 3.7: Especificao de uma transao no modelo TAXIS

Em resumo, TAXIS fortemente baseada na abstrao de herana (IS-A) utilizando-a para estruturar dados e procedimentos de uma aplicao, incluindo as expresses, transaes e excees. Prov uma metodologia para tratar restries semnticas de integridade, auxilia a organizao de projetos atravs das especializaes sucessivas, propondo um formalismo para todos os aspectos envolvidos em uma aplicao.

3.5. S-SQLS-SQL uma interface que estende a capacidade de captao semntica dos gerenciadores de banco de dados relacionais que ofeream a linguagem SQL [10]. A interface implementa caractersticas semnticas, tais como, classificao, generalizao, agregao, Modelagem Semntica de Dados


9

derivao de classes, surrogates e atributos multivalorados. A idia da interface, segundo o autor[10], surgiu devido a rejeio do mercado aos modelos semnticos. Criando uma interface portvel, buscou-se prover os SGBD relacionais com mais de inteligncia para responder as interaes dos usurios preservando o investimento feito pelas empresas em SGBD relacionais. Ao se propor a interface foram propostas as linguagens de definio de dados (LDD) associada ao modelo. Para construir o esquema da aplicao, a LDD prov instrues para criar classes (Create Class), alterar classes (Alter Class), excluir classes (Drop Class), definir chaves (Key), definir subclasses (Subclass of), indicar a pertinncia da subclasse (Total / Partial), indicar o tipo de generalizao que a subclasse assume (Covering, Overllaping, Disjoint, Partitioning), declarar uma subclasse derivada (Derived subclass of), entre outras. Alguns exemplos so apresentados abaixo: Create Class Motorista (CNH integer, Nome char(30), CNHValid char(10), Fone{char(15)}) Key (CNH) Covering Subclasses of Taxi are Taxi_Van, Taxi_Sedan Alter Class Taxi add (cor char(10)) Alter Class Motorista drop (fone) Para facilitar a visualizao do modelo, a interface S-SQL prov uma representao grfica que pode ser visualizada na Figura 3.8, representando a generalizao de classes.

Taxi

Placa Marca Modelo

integer char(10) char(15)

lugares integer

Taxi_Van

Taxi_Sedan

opcional char(10)

Figura 3.8: Representao grfica da interface S-SQL

Alm da LDD, uma linguagem de manipulao de dados (LMD) foi proposta, buscando dar ao usurio uma linguagem de interao mais fcil e intuitiva do que a linguagem SQL padro. A LMD do S-SQL traduzida posteriormente para a SQL padro pela prpria interface. Atravs da LMD da S-SQL possvel a qualificao das instncias, baseado nos valores dos atributos das instncias componentes de uma agregao e efetuar consultas atravs de junes relacionais. Um surrogate criado automaticamente atravs da interface no momento de se definir uma relao. Consultas que utilizem comparaes entre surrogates podem ser efetuadas desde que essas comparaes sejam feitas entre surrogates de uma mesma classe ou entre surrogates de classes especializadas a partir da mesma classe base. O valor de um surrogate disponibilizado pela interface S-SQL atravs do atributo identificador padro, #. Para a incluso de objetos em uma agregao a S-SQL aplica predicados que identifiquem essas instncias nas suas respectivas classes e s incluir a instncia se o predicado for vlido para uma nica instncia e se for vlido para todas as instncias da classe componente. A retirada de objetos de uma agregao pode ser feita pela qualificao dos valores dos atributos das instncias componentes. O acesso aos atributos de uma superclasse, a Modelagem Semntica de Dados


10

partir de uma subclasse transparente para o usurio. A interface S-SQL prov o operador IS-A quando for necessrio especificar a qual subclasse um determinado surrogate est associado, como tambm, para especificar instncias envolvidas em uma agregao. Para tratar valores de atributos multivalorados, o operador IN provido pela interface, assim como operadores de conjuntos, igualdade(=), contm(=>) e contido( 1990 A especificao de elementos de um atributo multivalorado feita atravs da incluso dos valores dos elementos separados por vrgulas e entre chaves. Por exemplo, a sentena da S-SQL para a incluso de um motorista que tivesse dois telefones seria Insert into Motorista (CNH, nome, CNHvalid, fone) Values (02660934590, Regina Moraes, 26/12/2007, {19-3441.6645, 19-8121.6511}) A incluso e excluso de elementos de um atributo multivalorado so feitas atravs do comando Update. Os sinais + e antes da chave de valores dos elementos indicam respectivamente a incluso e a excluso de elementos do conjunto. Por exemplo, a sentena a seguir adiciona um novo nmero de telefone a uma instncia j existente. Update Motorista Set fone = +{19-3404.7105} Where Motorista.CNH = 02660934590 Uma interface que implementa um modelo semntico deve ser a nica responsvel pela coerncia do esquema tanto na criao quanto na efetivao de modificaes ao longo do tempo. A S-SQL restringiu a sete operaes bsicas, categorizadas em trs grupos[10]: 1. Modificao do contedo de uma Classe (Incluso/Excluso de um atributo, Incluso/Excluso de uma chave) 2. Modificaes no conjunto de Classes (Incluso/Excluso de uma Classe) 3. Modificaes nos Relacionamentos (Conexo de uma classe como subclasse em uma categoria existente) A interface S-SQL foi implementada como uma casca para um SGBD relacional que tem como base a linguagem SQL[10]. Essa deciso de implementao trouxe algumas vantagens, como a similaridade das operaes da interface com a linguagem SQL, facilitando o entendimento dos usurios que j estavam acostumados com a linguagem.

3.6. MEASURSemitica pode ser definida, baseado em Peirce[11], como a cincia dos signos e dos processos significativos (semiose) na natureza e na cultura. Tem por objeto de investigao, todas as linguagens possveis. A investigao semitica abrange virtualmente todas as reas do Modelagem Semntica de Dados


11

conhecimento envolvidas com as linguagens, tais como a lingstica (verbal), a matemtica (dos nmeros), a biologia (da vida), as artes (esttica) etc. A diviso da semitica sintaxe, semntica e pragmtica que trata de estruturas, significados e utilizao de sinais. Semitica Organizacional (SO) um estudo que utiliza os conceitos da semitica e tem por base que todo comportamento organizado afetado pela comunicao e interpretao de sinais pelas pessoas, individualmente ou em conjunto, no grupo onde esto inseridas[11]. MEASUR (Methods for Eliciting, Analysing and Specifying Users Requirements) foi introduzido por Stamper [17]. MEASUR um conjunto de mtodos orientado a normas (normoriented methods), que tem como objetivo lidar com todos os aspectos dos projetos de sistemas de informao que se relacionam com o uso de sinais, suas funes no significado das comunicaes e intenes e suas conseqncias sociais. Com a utilizao de MEASUR, estaremos tratando Mtodos de Articulao de Problemas (Problem Articulation Methods PAM utilizado nos estgios iniciais do projeto quando se encontra um problema vago e complexo), Mtodos de Anlise Semntica (Semantic Analysis Methods SAM auxilia os usurios a extrair e representar seus requisitos de uma maneira formal) e Mtodos de Anlise de Normas (Norm Analysis Methods NAM apresenta um significado para especificar padres gerais de comportamentos dos agentes num sistema de negcios). Alm desses mtodos principais, MEASUR ainda conta com Anlise de Controle e Comunicao (Control and Communication Analysis) e Anlise de Meta-Sistemas (Meta-Systems Analysis). Esse conjunto de mtodos permite que se inicie com um problema vago e desestruturado e gradualmente se refine esse modelo at obter um problema preciso o suficiente para derivar um conjunto de solues tcnicas. MEASUR auxilia a soluo de uma gama variada de problemas, que requeiram interveno organizacional ou social para serem solucionados[16]. No Mtodo de Anlise Semntica, aps a extrao de requisitos feita no PAM, representado o contexto do problema num modelo formal, as funes requeridas sero especificadas num modelo ontolgico que ir descrever uma viso dos agentes responsveis no domnio do negcio. O significado do sinal usado no modelo semntico, para representar o mundo do negcio, tratado como um relacionamento entre o sinal e as aes apropriadas. No anexo C, a tabela C1 apresenta os conceitos envolvidos nesse mtodo de anlise. O modelo ontolgico delineia um contexto que envolve os conceitos e as terminologias usados no domnio particular do problema. Permite uma semntica contextual porque toda palavra ou expresso ligada com seus antecedentes. Uma dependncia ontolgica pode ser definida da seguinte forma: dado dois objetos X e Y, se a existncia de Y depende da existncia de X e Y s existe enquanto X existir, ento o relacionamento de dependncia entre X e Y chamado de dependncia ontolgica. O objeto X chamado de antecedente e Y seu dependente. A dependncia ontolgica ser representada por linhas que tem antecedentes do lado esquerdo, e dependentes do lado direito. Essa modelagem exige que seja analisada cada palavra do texto que especifica o problema a ser modelado, procurando-se identificar todos os aspectos semnticos que o envolve, sejam eles explcitos ou implcitos. Devido a isso, a anlise bastante trabalhosa. Para efeito de exemplo, foi modelada apenas uma parte da especificao do sistema do txi (ref. ao anexo A) cujo modelo ontolgico apresentado na figura 3.9. A separao das caractersticas do modelo pela anlise da especificao do sistema de txis a que segue: Identificao dos agentes (substantivos que detm responsabilidades; definir agente raiz): Raiz sociedade; Agentes Empresa, Pessoas, Motorista,Usurio, Operador Identificao dos affordances (demais substantivos, verbos) Affordances: Txi, fila de txi, chamada, gerenciar, dirigir, atualizar, examinar, fazer. Identificar Determinantes: Pessoa: #id, #local; Txi: #id, #km. Modelagem Semntica de Dados


12

Agrupamento: (papel, todo/parte, genrico/especfico, relaes) Papel: Supervisor papel assumido por um operador; Genrico/Especfico: Pessoa (genrico) e Usurio, Motorista, Operador (especficos).#id, #local

fazer chamada atualizar supervisor

Pessoa Usurio Operador Motorista

sociedade

gerenciar

dirigir

empresa txi#id #km

examinar fila txi

Figura 3.9: Modelo Ontolgico para trecho da empresa de txi

3.7. UML UNIFIED MODELING LANGUAGENos anos 90, os primeiros movimentos do mundo OO comearam a sugerir meios de utilizar metodologias OO no projeto de banco de dados. Os desenvolvedores da OML Object Modeling Language publicaram um estudo que descrevia como se poderia utilizar OML para projetar bancos de dados [14]. O uso da modelagem do projeto de banco de dados muito utilizado, excedendo a utilizao da modelagem de aplicativos mas, normalmente, se restringe modelagem de tabelas, colunas e relacionamentos. Atravs do diagrama de banco de dados da UML poderemos representar aspectos complementares a esse, tais como, tablespaces, vises, restries (constraints), gatilhos (triggers), ndices, procedimentos armazenados (stored procedures) e domnios. O profile (extenso da UML que conserva seus princpios bsicos) para projeto de banco de dados da UML adiciona os esteretipos necessrios para a representao desse tipo de modelagem. Alguns cones tambm podem ser utilizados para auxiliar a visualizao dos aspectos da modelagem. No anexo D a figura D.2 apresenta esses cones. Dessa forma, uma representao para o relacionamento entre Txi e Motorista atravs da fila de txi poderia ser a apresentada na Figura 3.10.Motorista P KCNHnum CNHnome CNHvalid Fone Txi P KPlaca Marca Modelo Ano

1..*

Fila_Txi

1..1

Figura 3.10: Relacionamento entre entidades



13

A representao de um auto-relacionamento mostrada na Figura 3.11.Operador P KRG nome Fone

supervisionado

supervisor

Figura 3.11: Auto-relacionamento entre entidades

Uma viso definida na UML como uma classe, com o esteretipo . Uma viso pode ser derivada de uma ou mais tabelas. O relacionamento da viso com suas tabelas pais modelado como uma dependncia com o esteret ipo . As abstraes de generalizao/especializao e todo/parte tm representaes bastante similares s respectivas representaes no modelo entidade-relacionamento e podem ser verificadas na Figura 3.12.TxiP KPlaca

Marca Modelo Ano

Van Capacidade

Sedan Num_opcional

OpcionalP KTipo

Descrio

Figura 3.12: Representao de generalizao/especializao e todo/parte Na UML, entidades so modeladas com o padro de classes da UML. No diagrama de banco de dados, na primeira diviso teremos o nome de entidades e seu respectivo esteretipo, na segunda diviso teremos os atributos com as representaes de chave primria, estrangeira e na terceira diviso chaves adicionais , ou , restries de check , gatilhos , ndices , procedimentos armazenados . A Figura 3.13 apresenta esses conceitos representados na classe Txi. Na diviso onde se encontram os atributos, o projetista pode representar o domnio do atributo se assim o desejar. Atributos compostos so modelados como uma estrutura de domnio, onde mostrado cada um dos atributos simples que o formam (por identao). Um atributo multivalorado ser modelado como uma classe separada. Modelagem Semntica de Dados


14

P KPlaca

Txi

Marca Modelo Ano Trig_Txi( ) get_Id( ) Marca( ) Ano( ) Figura 3.13: Representao de restries, gatilhos, ndices na UML

Relacionamentos so chamados associaes na UML e suas instncias so os links. Uma associao binria representada por uma linha que conecta as entidades participantes do relacionamento e pode opcionalmente ter um nome. Um atributo de relacionamento modelado como uma caixa que conectada linha de relacionamento por uma linha tracejada. As multiplicidades dos relacionamentos so modeladas na forma de participaes mnimas e mximas de cada entidade participante de um relacionamento. Agregao deve ser modelada com um diamante vazio junto entidade que representa o todo. Composio tambm representa o relacionamento entre um objeto todo e suas partes componentes que so destrudos quando o todo destrudo e deve ser modelado com um diamante cheio junto entidade que representa o todo. Entidades fracas podem ser modeladas utilizando uma construo de associao qualificada. Um tringulo branco representa uma especializao/generalizao disjunta, enquanto que um tringulo preenchido representa a sobreposio das entidades especializadas[4] (veja Figura D.1 no anexo D). A representao das abstraes utilizadas na modelagem de dados baseados na UML so bastante similares s representaes utilizadas no modelo entidade-relacionamento estendido. Os diagramas da UML conduzem ao contexto do banco de dados. Assim, devemos estar preparados para pensar num diagrama entidade-relacionamento quando terminarmos o diagrama de seqncia e fizermos os ajustes no diagrama de classes respectivos com visibilidade, colees, atributos ou propriedades especficas da nossa necessidade. Uma importante questo a ser considerada a navegao, ela bastante importante para definirmos os relacionamentos entre as entidades. Quanto aos atributos, se tivermos um atributo de uma classe que est mapeado para um campo de uma entidade no banco de dados, devemos marc-lo com o modificador persistente. Esse modificador pode ser usado tanto para uma classe como para um atributo especfico, ou mesmo vrios atributos.

4. MAPEAMENTO PARA GERENCIADORES DE BANCO DE DADOSNessa seo iremos apresentar como feito o mapeamento dos modelos semnticos apresentados, para o esquema dos gerenciadores de base de dados. Mapear abstraes oferecidas por um modelo semntico em um SGBD, envolve uma srie de decises de implementao, tais como, desempenho, espao de armazenamento, manuteno de integridades entre outros. Quando se trata de persistncia de dados, nem sempre temos padres bem estabelecidos. Assim, quando se vai definir um esquema para traduzir uma modelagem, tenha sempre em mente que: (i) preciso compreender sua tecnologia antes de decidir aplic-la, a escolha da tecnologia pode significar a diferena entre um projeto bem-sucedido e um fracasso ilimitado; (ii) seja flexvel em sua abordagem de projeto, no tome decises de projeto definitivas antes de ter desenvolvido prottipos de suas implicaes em aplicaes de produo; (iii) se voc tem Modelagem Semntica de Dados


15

preocupao com portabilidade, preste ateno que tipo de gerenciador escolher, normalmente gerenciadores objeto-relacional e orientados a objetos ainda no atingiram uma condio que possibilite uma portabilidade tranqila [7].

4.1. MODELO ENTIDADE-RELACIONAMENTOO modelo entidade-relacionamento mais utilizado para a modelagem de sistemas que utilizam gerenciadores de banco de dados relacionais. Por esse motivo e tambm pela limitao de espao desse trabalho iremos nos restringir a esse enfoque. Toda entidade regular que apresentada no modelo entidade-relacionamento d origem a uma tabela com os mesmos nomes e os mesmos atributos. Atributo determinante d origem a chave primria e chaves estrangeiras devem ser especificadas. Uma entidade de ligao d origem a uma tabela com chave primria, atributos, mais a(s) chave(s) externa(s) e possveis atributos do(s) relacionamento(s) absorvido(s). A forma de traduzir uma entidade fraca unir essa entidade e o relacionamento que a associa entidade regular em uma tabela, contendo a chave externa da entidade regular e os atributos prprios da entidade fraca. A estrutura da chave primria de um conjunto relacionamento depende do mapeamento das cardinalidades do conjunto de relacionamentos. Se tivermos uma cardinalidade de relacionamentos de muitos para muitos, a chave primria do relacionamento ser a unio das chaves primrias dos conjuntos de entidades participantes do relacionamento. Para relacionamentos muitos para um ou um para muitos, a chave primria pode ser a chave primria do conjunto de entidades que participa do lado muitos, j se o relacionamento um para um, qualquer uma das chaves primrias pode ser usada como chave primria do relacionamento. Relacionamentos nem sempre exigem um depsito de dados (tabela) na sua implementao. Quando o relacionamento for implementado como uma tupla de uma tabela, conter tantas referncias (chaves externas) quantas forem as ocorrncias de entidades participantes, mais os eventuais atributos prprios do relacionamento. Um auto-relacionamento sempre gera tabela contendo chaves externas que apontam para ocorrncias da entidade e, eventualmente, atributos prprios do auto-relacionamento. Relacionamentos cuja existncia no obrigatria (0,1: 1 ou 0,1:N) impem a criao de um depsito de dados. Generalizao / Especializao pode ser transformada para o modelo relacional de duas maneiras distintas. Na primeira delas, cria-se uma tabela para entidade do nvel mais alto e uma tabela para cada entidade do nvel mais baixo com seus atributos, mais a chave primria da entidade do nvel superior. Na outra maneira cria-se uma tabela para cada entidade do nvel mais baixo com os atributos prprios, mais todos os atributos herdados do nvel mais alto. Esse mtodo s pode ser usado quando todas as entidades do nvel mais alto so representadas no nvel mais baixo. No anexo B pode-se encontrar um resumo das regras de mapeamento que foram descritas nessa sesso.

4.2. RM/TNo modelo RM/T, toda entidade realizada como uma tabela no banco de dados relacional. Entidade-semente por ser independente, entidade-caracterstica por definir o lado mltiplo de uma relao da qual depende (por exemplo, as linhas de uma nota fiscal ou os itens de um pedido) e entidade-associativa, pois define a relao muitos-para-muitos de uma associao entre duas entidades. Toda entidade passvel de distino e o RM/T cria um substituto (surrogate) que controlado pelo sistema. Esses substitutos esto na relao E de cada entidade e sero mapeadas como chaves primrias da relao no modelo relacional. As Modelagem Semntica de Dados


16

relaes P que possuem o mesmo substituto podem ser agrupadas numa mesma tabela relacional. O mapeamento de subtipos e supertipos pode ser feito segundo as mesmas regras j descritas para o modelo entidade-relacionamento [3].

4.3. SDMComo j dito na seo 3.3, o objetivo do SDM definir uma maneira de especificar o esquema de banco de dados e no propriamente a preocupao da implementao em um SGBD. Desta forma, o SDM pode utilizar os conceitos j descritos no modelo entidaderelacionamento para traduzir o modelo para tabelas relacionais. Cada deve ser traduzida numa tabela relacional cujos campos esto especificados na clusula member atributes: do modelo SDM e inclui seus respectivos tipos de dados e restries de campos (tais como a clusula not null). As chaves primrias da tabela esto igualmente especificadas no modelo SDM sob a clusula identifiers:.Tipos de usurios esto definidos em classes de tipos no modelo SDM e podem ser utilizados como domnio dos campos de uma tabela relacional tal como indicado no modelo SDM. Atravs da clusula interclass connection: do modelo SDM pode-se identificar os relacionamentos por agrupamento ou generalizao/especializao. Similarmente ao modelo entidade-relacionamento, pode ser feita a traduo para esses relacionamentos [5].

4.4. TAXISPouco material foi encontrado a respeito da maneira como um sistema modelado com o TAXIS deve ser traduzido para um modelo relacional. O que apresentado a seguir baseado em dedues feitas pelo autor baseadas em [8]. O modelo TAXIS fortemente baseado no conceito de generalizao/especializao. Uma VARIABLE-CLASS claramente uma representao de uma entidade generalizada, a partir da qual as especializaes devem seguir. Nesse caso, toda VARIABLE-CLASS do modelo TAXIS ir gerar uma tabela no banco de dados relacional, suas characteristics sero os campos dessa tabela, a unicidade da tabela ser definida pela keys e as restries de domnio dos campos definidas pelo attribute-properties. Uma AGGREGATE CLASS define um relacionamento entre tabelas no modelo relacional. Os componentes comportamentais do TAXIS iro direcionar algumas restries de domnio, inseres de clusulas check nas tabelas criadas, definies de triggers e stored procedures no modelo relacional.

4.5. S-SQLNa S-SQL, basicamente toda classe ir corresponder a uma tabela cuja interface acrescentar um atributo destinado a conter o surrogate da tupla. Classes que possuem atributos multivalorados iro gerar tantas tabelas quantos atributos multivalorados tiver, alm da tabela base e implicam em uma juno entre a tabela base da classe e a tabela que armazena os elementos do atributo e s possvel uma correta implementao se o SGBD utilizado prouver o outer join. Consultas que possuem mais de um atributo multivalorado numa clusula Select acaba gerando um resultado que associa cada tupla de um dos atributos com cada uma das tuplas do outro atributo e vice-versa. Cada chave declarada ir gerar automaticamente um ndice. Na traduo de transaes, cada transao S-SQL poder gerar vrias transaes SQL. Ao traduzir uma transao todos os desmembramentos necessrios so processados pela interface, que poder criar identificadores automticos que se faam necessrios. Na incluso de uma instncia, para cada surrogate, a interface gera uma consulta baseada no predicado dado, a fim de recuperar o surrogate associado e completar a cadeia de cada instncia componente que Modelagem Semntica de Dados


17

definida pelos predicados. As transaes de excluso so transformadas em transaes de consultas para que a interface possa efetuar a excluso requisitada e todas as excluses que devem ser propagadas para as tabelas relacionadas. Para as transaes que recuperam instncias de classes participantes de uma hierarquia de generalizao, o processo bastante prximo ao processo de traduo de junes implcitas, mas a interface precisar recorrer ao dicionrio de dados quando for preciso relacionar os atributos s superclasses onde esto definidos. O operador de pertinncia IS-A e o operador IN so traduzidos para o operador de igualdade (=). Para as transaes de incluso numa rede de generalizao, a interface deve determinar atravs do dicionrio de dados, a qual superclasse est associada cada atributo. Para a incluso em classes derivadas com base em predicados, a interface ir gerar para cada incluso na classe base uma incluso na classe derivada. quase obrigatria a utilizao de clusulas Group by e Having para solucionar consultas que envolvam agrupamentos. De uma forma geral, as tradues que envolveram as abstraes de agregao e generalizao foram efetuadas de uma maneira simples, o que no ocorreu com as tradues que envolvem atributos multivalorados que requisitaram tradues mais complexas. Foi apresentado um resumo das tradues da interface S-SQL para o modelo relacional, uma abordagem mais completa pode ser obtida em [10].

4.6. MEASURPara a traduo do modelo MEASUR todo agente e affordance do tipo entidade deve ser tratada como entidade e conseqentemente gerar uma tabela no modelo relacional. Affordances do tipo ao, iro gerar os relacionamentos e devem seguir as regras do modelo entidaderelacionamento para a sua traduo em tabelas relacionais. Papis representados no modelo devem gerar entidades que se relacionam numa cardinalidade 1x1. Relao parte-todo e genrido-especfico, geram entidades com relacionamentos 1xN. Determinantes geram atributos nas suas respectivas tabelas. Aps a traduo, a cardinalidade dos relacionamentos deve ser analisada e as normas associadas com o modelo semntico devem ser satisfeitas. Para a traduo desse modelo para um modelo orientado a objeto ou objeto-relacional as seguintes regras devem ser utilizadas: agentes e affordances do tipo entidade geram objetos, affordances do tipo ao, geram comunicao entre atributos ou servios, papis geram restries de atributos e conjuntos, relao parte-todo geram objetos aninhados ou separados, relao genrico-especfico geram herana de classes e finalmente determinantes geram atributos em suas respectivas classes [16].

4.7. UML UNIFIED MODELING LANGUAGEA transformao de um modelo de dados UML em um esquema de banco de dados relacional usa as tcnicas para transformar um modelo entidade-relacionamento e adiciona outras para aproveitar alguns dos recursos expandidos desses modelos. Durante a modelagem, classificadores estereotipados com e os tipos compostos so transformados em tipos de usurios no esquema de banco de dados e utilizados para a tipagem de atributos. Cada classe UML do modelo transformada em uma tabela e cada atributo dentro da classe se torna uma coluna dessa tabela. Os atributos que foram marcados com PK so definidos como uma chave primria (Primary Key). Classes que participam de relacionamentos vrios-para-vrios e ternrios, classes de ligao e classes de um relacionamento de herana devem ser mapeadas, utilizando as mesmas regras existentes para o modelo entidade-relacionamento. Quando houver uma indicao na modelagem estereotipada como isso dever gerar um surrogate (SEQUENCE no Oracle ou IDENTITY no SQL Server). Toda marca com esteretipo deve receber uma restrio UNIQUE como restrio de coluna. Para os atributos Modelagem Semntica de Dados


18

que no receberem marcadores {nullable} preciso que se adicione a palavra chave NOT NULL coluna da tabela [6]. Procedimentos armazenados e gatilhos indicados na modelagem devem gerar correspondentes procedimentos e gatilhos no seu esquema. Da mesma forma que com esquemas relacionais, voc cria um esquema objetorelacional em dois passos bsicos: a criao de tipos e tabelas (a partir de tipos persistentes e para associaes muitos-para-muitos e ternrias). A transformao de um modelo de dados UML em um esquema de banco de dados objeto-relacional admite a representao de classes e interfaces para tipos estruturados atravs de Create Type. O Oracle8, Informix e DB2 suportam essas espcies de tipo, embora com sintaxe e caractersticas diferentes. O tipo define atributos, mas no define suas conexes a outros tipos, nem define suas chaves primrias ou regras do negcio (restries check), voc ter que coloc-las diretamente nas tabelas que criar utilizando a declarao Create Table e que utilize um determinado tipo. No Oracle 8 e no DB2 possvel criar tipos estendidos e no Informix alm de tipos estendidos possvel criar a generalizao de tipos em estruturas de herana. Embora no Oracle8, voc no possa se referir diretamente a um tipo de objeto para um atributo, pode definir um REF para tal tipo. Um atributo-objeto um atributo de um tipo de objeto que ele mesmo um objeto. Nesse caso, estaramos criando a possibilidade de um objeto embutido em uma tabela e assim, cada linha dessa tabela constitui mais um objeto com identidade. Em um diagrama UML, essa uma associao com multiplicidade 1..1 ou 0..1 para a classe que representa o objeto embutido. Uma alternativa a isso usar uma referncia, que um ponteiro para um objeto armazenado em algum lugar fora da tabela atual. O ponteiro , nesse caso, o identificador do objeto, seu OID. O SGBDOR constri um OID para cada objeto de um tipo estruturado que voc cria e ento se pode referir ao objeto colocando o OID em um valor de coluna na tabela referente. Assim, em um SGBDOR voc pode representar associaes como chaves estrangeiras ou como referncias. Se voc utilizar chaves estrangeiras ter que realizar a juno das tabelas em consultas, se usar referncias, poder navegar at o objeto referenciado por intermdio de expresses SQL, evitando a juno, mas dificultando a integridade referencial, uma vez que se voc remover um objeto, quaisquer referncias quele objeto permanecem exatamente como esto, sendo necessrio utilizar gatilhos ou um esquema de encapsulamento de procedimentos armazenados para garantir essa integridade. Uma associao com multiplicidade vrios pode ser representado pelo tipo coleo, que pode ser um vetor, um conjunto ou uma tabela. O Oracle8 oferece o tipo VARYING ARRAY e tabela aninhada, o Informix oferece SET, MULTISET e LIST. O objetivo de todos esses tipos o de coletar vrios objetos em um nico valor de coluna. Para o comportamento, os bancos de dados objetos-relacionais variam ligeiramente a abordagem dos relacionais. O Oracle8 acrescenta mtodos aos tipos de objeto. No que diz respeito a regras de negcios h muito pouca diferena entre um sistema relacional e um sistema objeto-relacional. Uma diferena a presena do tipo de objeto ou estruturado que no tem restries, apenas as tabela as tem. O mapeamento de um modelo de dados UML a um esquema Orientado a Objetos (OO) direto, embora haja algumas questes a considerar. Muitas questes surgem da natureza inerente do projeto de objetos persistentes, aparecendo em todos os produtos SGBDOO e no prprio padro ODMG. O padro ODMG 2.0 uma avaliao de desempenho abrangente para as capacidades de um SGBDOO, mas ainda no so oferecidas facilidades de definio de esquemas em conformidade com o padro. Alguns, como POET e Versant, oferecem variaes sobre o padro, outros como ObjectDesign e Objectivity tm uma maneira completamente diferente de definir seus esquemas. Transaes, caching cliente/servidor, associaes complexas, chaves e extenses so conceitos externos s linguagens de programao OO, mas so essenciais para bancos de dados. No podendo ignorar essas questes, todos os produtos OO oferecem mapeamento para elas, mas de formas diferentes. Modelagem Semntica de Dados


19

Quase todos os produtos SGBDOO comearam utilizando linguagens de programao OO como suas linguagens de definio de esquemas. Acrescentando elementos de linguagem ou bibliotecas de classes para suportar a persistncia, esses produtos transformaram as definies de interface em declaraes de esquemas. Embora o processo de mapeamento para SGBDOO seja mais simples do que no caso de banco de dados relacionais, a promessa de transparncia ainda no foi cumprida. Os valores nulos so um tanto problemticos em produtos SGBDOO, pois a maioria das linguagens de programao OO no tem nenhum conceito de um valor nulo. Bindings C++, Smalltalk e Java no suportam os tipos literais nullable, nem nulos para objetos. A associao onde os produtos SGBDOO do mais trabalho na gerao do esquema. Pode-se representar um vnculo entre dois objetos de maneiras diferentes, as alternativas bsicas so: (i) Atributo colocar um nico objeto relacionado diretamente como membro do objeto relacionador, que proprietrio do objeto (isso se traduz em um objeto sem OID, e consiste em valores embutidos no objeto relacionador); (ii) Referncia embutir um nico objeto relacionado como membro de referncia do objeto relacionador utilizando um manipulador ou referncia persistente . Nesse caso, a integridade referencial deve ser gerenciada pelo aplicativo; (iii) Coleo de Objetos coloca-se um template de coleo para objetos como membro do objeto relacionador. A integridade referencial gerenciada pela coleo como propriedade dos objetos parte; (iv) Coleo de Referncia coloca-se um template de coleo para referncia de objetos como membro do objeto relacionador. A integridade referencial deve ser mantida pela aplicao; (v) Relacionamento coloca-se um template especial de coleo de referncias de objetos como membro do objeto relacionador. O template de coleo mantm integridade referencial de ambos os lados do relacionamento. Em alguns produtos SGBDOO, as referncias tambm podem permitir ativao adiada (lazy activation) de objetos, permitindo que se recupere o objeto do servidor apenas quando precisar us-lo. Outros sistemas ativam todos os objetos que pode alcanar a partir de um objeto ativado (por exemplo o SGBDOO Ozone). Com algumas raras excees, produtos SGBDOO localizam o comportamento no cliente, tornando o SGBDOO um pouco menos flexvel. A tarefa do SGBDOO materializar objetos persistentes em memria do cliente e ento deixar aqueles objetos desempenharem sua tarefa, coordenando atravs de transaes, caches compartilhados e assim por diante. A vantagem dessa abordagem a drstica simplificao da interface comportamental. Comportamento limitador simples no esquema OO. Voc cria um programa para fazlo. No h restrio ou gatilho de banco de dados no esquema OO; apenas mais um comportamento que voc anexa a uma classe. Assim o modelo OO transforma restries complexas em problemas de programao em vez de problemas de bancos de dados.

5.

CONCLUSES

O projeto de bancos de dados e a sua crescente utilizao pelas empresas esto relacionados necessidade do domnio de informaes para garantir qualidade de aplicaes, respostas consistentes, aes aderentes e rpidas s necessidades do negcio, assegurando a competitividade de um mercado altamente mutvel. Apesar de vrios modelos semnticos terem sido propostos, a maioria esmagadora das empresas utiliza o modelo entidade-relacionamento, na sua forma estendida (com a extenso foi provido alguns mecanismos tpicos para a reutilizao) que vagarosamente tem sido substitudo pelo modelo UML nos ltimos anos. Mesmo assim, essa substituio tem se dado devido a utilizao de ferramentas integradas baseadas na UML, que inicialmente so utilizadas para as demais fases de projeto e acaba levando o usurio a aderir a UML tambm para o modelo de dados. Modelagem Semntica de Dados


20

Os mecanismos do Banco de Dados Relacional so insatisfatrios para implementao da hierarquia de generalizao, e os Bancos de Dados Orientados a Objeto ainda no conquistaram espao junto s empresas para implementao de bancos de dados corporativos. possvel que quando isso acontecer (se acontecer) a substituio mais rpida do modelo entidaderelacionamento se d, devido a menor impedncia do modelo de dados baseado na UML com a representao de objetos. Na verdade, apesar de algumas crticas ao modelo entidade-relacionamento, as representaes providas pelo modelo estendido atendem quase a totalidade das necessidades da modelagem necessria para os sistemas empresariais, devendo-se a isso a sua grande aceitao. Os modelos que foram propostos ao longo desses anos, pouco complemento trouxeram s representaes j providas pelo modelo entidade-relacionamento e no justificaram o esforo necessrio para que as empresas investissem na substituio de um modelo conhecido e to bem aceito pelos profissionais envolvidos em projetos de sistemas.REFERNCIAS CHEN, P. The entity-relationship model Toward o unified view of data, ACM Transactions on Database Systems, pp. 9-36, Maro 1976. [2] CODD, E. F. Extending the database relational model to capture more meaning, ACM Transactions on Database Systems, pp. 397-494, Dezembro 1979. [3] DATE, C. J. Introduo a Sistemas de Banco de Dados, Traduo da 4 Edio Americana, p. 674, Editora Campus, 1996. [4] ELMASRI, R.; NAVATHE, S. B. Fundamental of Database Systems, 3th Edition, p. 955, Addison Wesley, 2000. [5] HAMMER, M.; MCLEOD, D. Database Description with SDM: a semantic database model, ACM Transactions on Database Systems 6(3), pp. 351-386, Setembro 1981. [6] MEDEIROS, E. Desenvolvendo Software com UML, Pearson Makron Books, p. 264, 2004. [7] MULLER, R. J. Projeto de Banco de Dados usando UML para modelagem de dados, Traduo do ttulo original Database design for smarties using UML for data modeling, Morgan Kaufmann Berkeley, p. 495, 2002 [8] MYLOPOULOS, J.; BERNSTEIN, P. A.; WONG, H. K. T. A language facility for design database-intensive applications, ACM Transactions on Database Systems 5(2), pp. 185-207, Junho 1980. [9] NAIBURG, E. J.; MAKSIMCHUCK, R. A. UML For Database Design, Object Technology Series, Addison-Wesley, p. 300, 2001, [10] OLIVEIRA, R. C. N., S-SQL: Uma Interface Semntica, Dissertao de Mestrado , Instituto de Matemtica Estatstica e Cincia da Computao, UNICAMP, Agosto 1989. [11] PEIRCE, C.S. Collected Papers, Cambridge, Mass: Harvard University Press, 1958. [12] RAMAKRISHMAN, R.;GEHRKE, J. Database Management System, 3th Edition, p., 2003. [13] REED, P.R. Jr Desenvolvendo Aplicativos com Visual Basic e UML, Makron Books, p. 462, 2000. [14] RUMBAUGH, J.; BLAHA, M.; PREMERLANI, W.; EDDY, F.; LORENSEN, W. Object-Oriented Modeling and Design, Englewood Cliffs, NJ, Prentice Hall, 1992. [15] SILBERSCHATZ, A.; KORTH, H.; SUDARSHAN, S. Sistema de Banco de Dados, p. 778, Makron Books, 1999. [16] SIMONI, C. A. C. A Prtica de Desenvolvimento de Software e a Abordagem da Semitica Organizacional., Dissertao de Mestrado, Instituto de Computao, Unicamp, Brasil, 2003. [17] STAMPER, R. K. Information in Business and Administrative Systems, John Wiley and Sons, New York, 1973. [18] TEOREY, T.;DONGQING Y.; JAMES, P. A logical design methodology for relational databases using the extended entity-relationship model, Computer Surveys 18 (2), pp. 198-222. [1]



21

ANEXO A ESPECIFICAO DO SISTEMA DE TXIO sistema de txi foi utilizado nesse trabalho para exemplificar o modelo. Uma especificao do sistema resumida apresentada nesse anexo, para que o leitor possa ter a idia do problema exemplificado. Essa especificao do problema foi disponibilizada como estudo de caso para a disciplina de Banco de Dados do Instituto de Computao no ano de 2004. Despacho e controle de Txis via terminais mveis ligados on-line com um sistema multiusurio. Uma empresa de agenciamento de corridas de txis est utilizando um sistema de rdio digital para gerenciar a frota de txis associados. A empresa tem cerca de 500 txis associados. Cada associado tem instalado no seu txi um equipamento da empresa que funciona como um terminal de computador bastante simplificado. Este equipamento tem um teclado simplificado e uma tela de cristal lquido para visualizar mensagens. Cada terminal s recebe mensagens destinadas a todos os txis ou destinadas a ele prprio. Quando um taxista envia uma mensagem de volta ao sistema o terminal, automaticamente, inclui a identificao do txi, a data, a hora e a kilometragem atual na mensagem enviada. O sistema deve poder atender a uma demanda de 10.000 transaes por dia, e at 1500 despachos por hora durante os perodos de pico. Do ponto de vista do motorista do txi, o sistema funciona da seguinte maneira: Quando o motorista comea a trabalhar, ou termina com uma corrida, ele envia uma mensagem para o sistema dizendo qual o nmero de "espera" (zona geogrfica) que deseja e aperta o boto desta transao. Sua posio na fila para aquela espera mostrada na tela LCD do terminal mvel; Quando o escritrio recebe uma chamada para um txi, ao primeiro txi na fila para aquela rea oferecida a corrida pelo computador, o qual envia um sinal (alarme sonoro) para o terminal do txi. Informaes sobre a corrida so tambm mostradas na tela; Se o motorista deseja a corrida, ele aceita apertando um boto. Se ele estiver fora do veculo ou ignorar o sinal por mais de 60 segundos, o sistema retira a corrida dele e deixa uma mensagem a respeito. O motorista pode tambm escolher que rejeita uma corrida e o sistema o leva para o fim da fila; Quando o motorista chega num endereo ele deve enviar uma transao de incio de corrida. Se nenhum cliente estiver l, ele pode apertar um boto que o colocar de volta no topo Modelagem Semntica de Dados


22

da fila (o tempo transcorrido e a kilometragem percorrida desde a aceitao da corrida at o momento de receber o passageiro controlado). Quando ele termina uma corrida o motorista deve enviar uma transao de fim de corrida. Operadores no escritrio de despacho fazem a inicializao das requisies de txis. Cada operador est sentado frente de um terminal de vdeo, no qual um formato padro de pedido est esperando entradas. medida que o operador vai digitando o nome, endereo, etc. o sistema vai movendo de campo em campo no formato padro. Um diretrio completo de ruas deve estar disponvel no disco, e o sistema automaticamente verifica o endereo entrado para verificar se o mesmo verdadeiro ou se j no houve problemas com este cliente. A corrida mais comum aquela que o cliente pede com antecedncia e determina um data/hora de incio e local de apanhar. H tambm corridas que so pedidas a qualquer momento com o cliente esperando num determinado endereo e corridas que so oferecidas para os associados a partir de um determinado evento, como por exemplo, o fim de um show. A empresa vive das mensalidades dos taxistas associados e de convnios com empresas que utilizam de "vouchers" . Estes "vouchers" so crditos que as empresas fornecem a seus clientes para utilizarem o sistema de txis. Quando a hora de iniciar uma corrida estiver prxima, o sistema determina qual a zona do endereo, e automaticamente avisa o txi no topo desta fila para oferecer a corrida. Um supervisor no escritrio pode reservar, suspender, reiniciar, ou dar prioridade a corridas para qualquer unidade. Ele tambm pode enviar mensagens confidenciais, cancelar chamadas, criar corridas que so feitas numa forma repetitiva, monitorar a carga em qualquer zona, e examinar filas de txis e corridas em tempo real.



23

ANEXO B MAPEAMENTO DO MODELO ENTIDADE-RELACIONAMENTONesse anexo apresentado um resumo do que foi descrito na sesso 4.1 a respeito do mapeamento do modelo entidade-relacionamento para esquemas de banco de dados relacionais. Dessa forma, Entidades Fortes - cada conjunto de entidades fortes no MER gera uma tabela. Entidades Fracas - gera tabelas com seus atributos, mais chave primria das entidades fortes dos quais elas dependem. Entidades De Ligao - gera tabelas com chave primria, atributos mais as chaves externas e possveis atributos dos relacionamentos absorvidos. Relacionamentos (N:N) - gera tabela que tem as chaves das entidades que ele associa mais os atributos prprios do relacionamento. Relacionamentos (1:N) Ou (1:1) - podem ser representados por novas tabelas ou atravs de chaves estrangeiras. Auto-Relacionamentos - sempre geram tabelas. Relacionamentos De Grau Maior Que Dois - sempre geram tabelas. Relacionamentos De Existencia No Obrigatria - sempre geram tabelas. Relacionamentos Diversos Com Mesmas Entidades - apenas um relacionamento pode ser absorvido, gerando tabelas dos outros relacionamentos. Generalizao E Especializao (duas alternativas) 1- Criar uma tabela para entidade do nvel mais alto e uma tabela para cada entidade do nvel mais baixo com seus atributos mais a chave primria da entidade do nvel superior. 2- Criar uma tabela para cada entidade do nvel mais baixo com os atributos prprios, mais todos os atributos herdados do nvel mais alto. Esse mtodo s pode ser usado quando todas as entidades do nvel mais alto so representadas no nvel mais baixo. Agregao relacionamentos de agregao so mapeados como tabelas com seus atributos descritivos e chave primria composta da chave primria do relacionamento, mais a chave primria do relacionamento dentro da agregao.



24

ANEXO C REPRESENTAO DOS CONCEITOS DO MTODO MEASUR

Tabela C.1: Representao dos Conceitos do Mtodo MEASUR

ConceitoAgente

SignificadoAtor que constri e interage com a realidade. indispensvel que se defina um agente raiz (por exemplo, sociedade, nao, etc.). Primitivas semnticas que representam padres possveis de aes ou comportamentos do agente. Define o limite ou o perodo relativo da existncia do affordance que se relaciona ao agente que o possui. Agentes e affordances tm propriedades que so invariantes e diferenciam um do outro. Um agente pode ter um papel para executar quando est envolvido nas relaes e nas aes. Define uma subdiviso possvel do agente ou representa uma hierarquia. Se possurem propriedades no compartilhadas ou diferentes.

Representao Empresa

Affordance Relao Ontolgica Determinante Papel Todo/Parte Genrico/Especfico

Gerenciar

#kilometragemSupervisor

Pessoa Motorista



25

ANEXO D UML UNIFIED MODELING LANGUAGENesse anexo so apresentados o diagrama de entidade-relacionamento do sistema de txi utilizando a UML, os cones utilizados pela UML para representao de objetos de modelagem semntica e as regras resumidas de mapeamento para gerenciadores de banco de dados objeto-relacional e orientado a objetos.

Logradouro LogID Nome Cidade Estado1..*

1..*

Zona Zona

1..1

Motorista CNH nome CNHvalid1..1 1..*

Limite

Endereo Complemento Bairro CEP1..1

Fila de Txi DataHoraIn KmIn

1..* *

Endereo Corrida

1..*

1..1

CorridaData Pedido DataHoraCorrida HoraApanhou HoraDeixou KmFinal

Taxi Placa Marca Modelo AnoFab

Numerao Nmero

Endereo Residencial1..* *

Cliente CliID Nome CPF CGC Figura D.1: Esquema conceitual UML para o sistema de Txi



26

Tabela Viso Domnio Chave Primria Chave Estrangeira Chave Primria/EstrangeiraP

K

F K P FK

Figura D.2: cones utilizados pela UML

Mapeamento do diagrama UML para Gerenciadores de Banco de Dados ObjetoRelacional (SGBDOR): Criar quaisquer tipos, tabelas ou objetos auxiliares de que necessita para criar e utilizar extenses SGBDOR reutilizveis, como cartuchos do Oracle8, o DataBlades do Informix ou o UDB do DB2. A classe UML torna-se o tipo de objeto (estruturado), geralmente com uma tabela correspondente quele tipo, para conter as linhas de objetos, mas possivelmente com mais do que uma s tabela dessa natureza. O tipo UML torna-se um tipo distinto se baseado em tipo embutido ou tipo de objeto, se possuir atributos. O atributo UML na classe torna-se atributo do tipo de objeto. O tipo de atributo na classe torna-se o tipo de atributo no tipo de objeto atravs da tabela de transformao de tipos e/ou objetos e tipos distintos. Se o marcador de atributo UML for {nullable}, o atributo possuir restrio Null, caso contrrio Not Null. Se o atributo UML possiuir inicializador, acrescente clusula DEFAULT coluna. Para classes sem generalizao (raiz ou independente) e identidade implcita, crie chave primria de nmero inteiro; para {oid} acrescente colunas com marcadores {oid} restrio de Primary Key; ignore agregaes compostas e classes de associao. Para subclasses, acrescente a chave de cada classe pai a uma restrio Primary Key e a uma restrio Foreign Key; alternativamente para produtos SGBDOR totalmente em conformidade com SQL3, voc poder usar uma clusula UNDER para representar o relacionamento, mas para todos os demais ter que colocar a restrio de chave estrangeira nas tabelas que definir com seu tipo de objeto. Para classes de associao, crie um tipo de objeto e acrescente uma chave primria de cada tabela de desempenho de papis restrio Primary Key e restrio Foreign Key. Se o tag for {alternate oid=}, acrescentar colunas restrio Unique. Acrescente Check para cada restrio explcita. Crie colunas Foreign Key na tabela de referenciao para cada papel 0..1, 1..1 na associao; alternativamente, use uma referncia a um tipo de objeto para declarar o objeto como atributo em si para objetos singelos ou para uma coleo como um vetor de referncias para objetos mltiplos relacionados. Modelagem Semntica de Dados


27

Crie Primary Key para agregao composta com Foreign Key para tabela de agregao (com opo Cascade); acrescente uma coluna adicional para Primary Key; alternativamente, use um tipo de objeto para armazenar o agregado na prpria tabela, quer atravs de um atributo de objeto (para um objeto simples) quer atravs de uma coleo, como um vetor ou uma tabela aninhada. Otimize classes de associao binria, mudando para tabela do lado para-muitos, onde apropriado. Crie tabelas para associaes muitos-para-muitos e ternrias sem classes de associao atravs de chaves estrangeiras. Crie restries Primary Key e Foreign Key a partir de chaves de tabelas de desempenho de papis em associaes muitos-para-muitos e ternrias. Crie mtodos para tipos de objetos para operaes nas classes UML correspondentes; utilize os formatos purity level (Oracle8) apropriados para operaes com marcador {readonly} ou {query}[6]. Mapeamento do diagrama UML para Gerenciadores de Banco de Dados Orientado a Objeto (SGBDOO): A classe UML torna-se uma classe persistentes no SGBDOO. A interface UML realizada por uma classe torna-se uma interface SGBDOO para linguagens que suportam interfaces (Java, ODL) ou uma classe de base abstrata com apenas membros virtuais puros e nenhum membro de dados para aquelas linguagens que no tm interfaces (C++, Smalltalk). Um classificador de tipo UML torna-se um enum ou typedef conforme indicado. O atributo UML na classe torna-se atributo na classe SGBDOO com transformaes e restries de tipos apropriados. Use tipo de literal nullable (nullable_short, por exemplo) se aparecer o marcador {nullable} e o binding que estiver usando suporta valores nulos (ODL); caso contrrio ignore-o (C++ ou Java). Se o atributo UML tiver um incializador, acrescente o cdigo inicializador ao construtor, ou como parte do mtodo construtor ou em uma lista de inicializao de membro C++. Para subclasses, inclua a especificao de superclasse na declarao da classe. Para classes de associaes, crie uma classe com os atributos da classe de associao. Para identidade especfica de objeto {oid} ou chave candidata {alternate oid}, especifique uma declarao de chave se o seu binding a suportar, caso contrrio, fornea mtodos apropriados para verificao de restries de singularidade sobre conjuntos de objetos (C++). Acrescente um mtodo classe apropriada para cada restrio explcita e assegure-se de que o sistema chame aquele mtodo sempre que o sistema exija que a restrio seja satisfeita. Crie um relacionamento para cada associao binria que no tenha classe de associao com o objeto ou tipo de coleo apropriados derivando das multiplicidades da associao. Use relacionamentos inversos a no ser que haja setas explcitas na associao. Crie um relacionamento em classes de associao para cada vnculo de papel a uma outra classe. Crie um cdigo ou use recursos do SGBDOO para propagar excluses de quaisquer associaes de agregao composta, conforme seu SGBDOO especfico assim o exigir. Crie uma classe de associao para associaes ternrias e relacionamentos da classe de associao para as classes associadas com os tipos de dados apropriados, dadas as multiplicidades [6]. Modelagem Semntica de Dados

Modelagem Semântica e Gerenciadores de Banco de Dados

Documents

Transcript of Modelagem Semântica e Gerenciadores de Banco de Dados