Artigo da SQL Magazine 43 - Construção de modelos de dados utilizando a ferramenta System Architect

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

Capa SQl 33

Clique aqui para ler todos os artigos desta edição

Construção de modelos de dados utilizando a ferramenta System Architect

 

O objetivo deste artigo é demonstrar os principais recursos da ferramenta System Architect relacionados à fase de modelagem de banco de dados relacional, passando por todo o processo de construção dos diagramas, geração do código para criação do esquema do banco de dados e, ainda, sua utilização como ferramenta para engenharia reversa.

A System Architect foi desenvolvida pela Popkin Software, atualmente Telelogic, e, para a construção deste artigo, foi utilizada uma versão para teste cujo download foi feito do site do fabricante (ver endereço na seção Links). A System Architect incorpora características de mapeamento e modelagem de negócio, acompanhando todo o ciclo de desenvolvimento, desde o levantamento de requisitos até a fase de implementação.

Para demonstrar as funcionalidades da System Architect, foi elaborada uma aplicação em um cenário hipotético abordando um sistema para gestão de uma clínica médica.

Descrição do cenário

A clínica possui um conjunto de médicos, sendo necessário representar o seu código, nome, data de admissão, data de nascimento e a especialidade de cada médico. Além disso, os médicos podem atender diversos convênios. Para cada convênio, é necessário identificar os médicos associados, além de algumas informações, como o seu código, razão social, telefone para atendimento e endereço. Na recepção da clínica, são registradas as consultas. Cada consulta está associada a um paciente e a um único médico, além de um código, descrição, data e hora, medicação e o diagnóstico. Em relação aos pacientes, é necessário registrar seu código, nome, endereço, telefone e data de nascimento.

Criação do diagrama entidade-relacionamento

Para dar início à modelagem da aplicação proposta, será criado um novo projeto, que é denominado enciclopédia na System Architect. Esta enciclopédia é o “Workspace” do projeto, onde todos os seus diagramas serão armazenados, e pode ser manipulada através do menu File à Open Encyclopedia. Dentro do assistente de criação de enciclopédias, existem três abas: a opção “New” permite criar uma nova enciclopédia; “Existing” possibilita ao usuário navegar pelas pastas para localizar uma enciclopédia já existente; “Recent” lista as últimas enciclopédias abertas na System Architect.

No exemplo, será utilizada a opção “New”, devendo preencher o campo “Project Name” com o nome do projeto a ser criado: Clínica Médica. No campo “Location”, deve ser indicada a pasta onde o projeto deverá ser criado, que representa o Workspace.

Depois de criada uma enciclopédia, é exibida a janela para a configuração do banco de dados, como ilustrado na Figura 1.

 

 

Figura 1. Janela de configuração do banco de dados.

 

Serão deixadas as opções disponíveis nesta janela com o padrão proposto pela ferramenta. Contudo, é necessário verificar dois itens de configuração: a opção Entity Relation deve ser selecionada, pois, no exemplo, será criado um modelo Entidade-Relacionamento. Além disso, para a persistência de dados, será utilizado o SGBD SQL Anywhere que deverá ser selecionado em Target Databases.

Após selecionar estas opções, o projeto será criado. O próximo passo será criar o diagrama Entidade-Relacionamento. Para gerar um novo diagrama, deve-se selecionar File à New Diagram. Um assistente será exibido na janela com uma lista de diagramas disponíveis. Selecione  a opção Entity Relation com um duplo clique.

 

Neste momento, será exibida uma tela para configuração do diagrama. No exemplo, o nome atribuído ao diagrama foi Clinica Medica (ver Figura 2). Em DBMS, deve ser selecionado o sistema gerenciador de banco de dados a ser considerado quando da criação do script do banco de dados. No exemplo, foi selecionada a opção SYBASE SQL Anywhere.

 

 

Figura 2. Criação do diagrama Entidade-Relacionamento.

 

Depois de configurar o diagrama, pode-se começar a definir os seus elementos. Neste ponto, é disponibilizada uma paleta de componentes na parte superior da janela, na qual são exibidos os atalhos referentes às entidades e relacionamentos que podem ser utilizados (ver Figura 3).

 

 

Figura 3. Paleta de componentes a serem utilizados no diagrama.

 

Ao inserir uma entidade no diagrama (botão ), deve-se digitar seu nome e, em seguida, com um duplo clique sobre a entidade, tem-se acesso às suas propriedades. Neste ponto é possível determinar quais são os seus atributos, chaves primárias e estrangeiras. A Figura 4 exibe a janela de propriedades da entidade Medico.

 

 

Figura 4. Janela de propriedades da entidade Medico.

 

Na guia Attributes, é exibida a lista de atributos, denominada Attribute List. As colunas Data e Name são colunas de identificação de cada atributo, não sendo utilizadas na geração do script para criação do banco. As colunas PK e FK (iniciais das palavras Primary Key e Foreign Key) devem ser utilizadas para especificar se o atributo é uma chave primária ou chave estrangeira, respectivamente. A opção Allow null estabelece que um atributo seja opcional, permitindo que sejam aceitos valores vazios. A coluna Unique define se o valor atribuído àquele atributo pode se repetir. No caso da chave primária, não é necessário ativar a opção Unique, pois este tipo de chave já não permite valores repetidos. A coluna Data type representa o tipo de dados do atributo e, em Qualifiers, é definido o tamanho do campo que será utilizado para os atributos do tipo Character. Por fim, a coluna Column Name é o nome que será utilizado no script gerado a partir do diagrama. Após definir os atributos, clica-se em OK para concluir a configuração da entidade.

A configuração das demais entidades definidas na aplicação (Convenio, Consulta e Paciente) ficarão de acordo com as janelas exibidas nas Figuras 5, 6 e 7.

 

 

Figura 5. Janela de propriedades da entidade Convenio.

 

 

Figura 6. Janela de propriedades da entidade Consulta.

 

 

Figura 7. Janela de propriedades da entidade Paciente.

 

Após a criação das entidades, tem-se o diagrama ilustrado na Figura 8.

 

 

Figura 8. Diagrama após criação das entidades.

 

Com as entidades criadas, podem-se definir os relacionamentos. Existem quatro tipos de relacionamentos entre entidades na paleta de componentes (ver Figura 3). São eles: relacionamento pai/filho identificado (Identifying) (botão ), Não Identificado (Non-Identifying) (botão ), relacionamento não específico (botão ) e relacionamento super-sub (botão ).

No relacionamento Identificado (Identifying Relationship) do tipo pai/filho, a entidade pai identifica a entidade filha. Isso significa que a chave primária da entidade pai é parte da chave primária da entidade filha, não podendo receber um valor nulo, isto é, uma entidade filha fica totalmente dependente da entidade pai. Estas entidades são geralmente chamadas de Entidades Fracas no modelo Entidade-Relacionamento.

O relacionamento Não-Identificado (Non-Identifying Relationship) indica que a entidade filha não necessita da entidade pai para sua identificação. Assim, a entidade filha deve possuir sua própria chave primária. Neste caso, o atributo de chave estrangeira relacionado à entidade pai pode ser um valor nulo, dependendo da obrigatoriedade definida no modelo.

O relacionamento não específico é usado durante a modelagem conceitual, onde, eventualmente, as cardinalidades ainda não foram definidas, permitindo sua modificação posteriormente. Será utilizado este tipo de relacionamento entre as entidades Medico e Convenio, utilizando uma cardinalidade N:N.

O relacionamento super-sub é usado para efetuar relacionamentos generalização/especialização no modelo de dados, fazendo com que atributos em comum entre entidades não precisem ser descritos repetidamente. É necessário defini-los uma única vez na entidade mais genérica.

Como especificado na descrição da aplicação, as entidades se relacionarão como descrito a seguir:

·         Medico e Consulta: relacionamento 1:N não-identificado;

·         Paciente e Consulta: relacionamento 1:N não-identificado;

·         Medico e Convenio: relacionamento não específico, que será modificado para um relacionamento N:N.

 

Para construir um relacionamento, basta selecioná-lo na paleta de componentes e clicar nas entidades envolvidas, na seqüência em que será atribuída a chave estrangeira, quando esta escolha for possível. Portanto, para definir o relacionamento entre Medico e Consulta, o botão correspondente ao relacionamento do tipo “Non-Identifying Relation” deve ser selecionado na paleta. Depois disso, deve-se clicar na entidade Medico e, em seguida, na entidade Consulta, como ilustrado na Figura 9. Ao selecionar um relacionamento, é possível definir um identificador. No exemplo, será especificado como identificador do relacionamento o nome da chave estrangeira como medico_consulta.

 

Figura 9. Ordem de criação do relacionamento.

 

Ao dar um duplo clique no relacionamento, uma janela de propriedades é exibida, como mostrado na Figura 10. Na aba Relation Line Info., existem duas páginas importantes para a configuração do relacionamento. Na caixa Parent Entity (que representa a entidade Medico), a opção “Parent Identifies child” é a responsável por transformar um relacionamento identificado em um não identificado, e vice-versa. A opção “Parent is optional” ativa (ou não) a obrigatoriedade da chave estrangeira. Na caixa Child Entity (que representa a entidade Consulta), basta selecionar a opção Zero, One or Many, em Number of children, informando que este lado será de cardinalidade N.

 

Figura 10. Janela de configuração de relacionamento.

 

Ainda na aba Relation Line Info, na página 2 (ver Figura 11), podem-se definir as restrições de integridade relacionadas às chaves estrangeiras.

 

 

Figura 11. Janela de configuração de integridade referencial.

 

O relacionamento entre as entidades Paciente e Consulta é semelhante ao definido anteriormente, sendo alterado apenas o nome do identificador do relacionamento, que será paciente_consulta.

Ao definir um relacionamento, são criadas chaves estrangeiras nas entidades para representar esta ligação. Entretanto, estas chaves estrangeiras não são atribuídas às entidades automaticamente. Para isto, é necessário atualizar o diagrama, utilizando o menu Dictionary à Update FKs. Pode-se verificar esta situação retornando na configuração da entidade, onde o atributo que representa a chave estrangeira agora estará presente.

Entre as entidades Medico e Convenio, o relacionamento é do tipo N:N. Na ferramenta, foi utilizado o relacionamento “Non-Specific Relation”, pois é o relacionamento que permite ser do tipo N:N. Após definir o relacionamento, deverá ser atualizada a cardinalidade alterando a propriedade “From cardinality” e “To cardinality” para “Many”, como ilustrado na Figura 12. Além disso, o nome atribuído ao relacionamento foi “conveniado”.

 

 

Figura 12. Janela de configuração do relacionamento entre as entidades Medico e Convenio.

 

Na Figura 13, pode-se verificar o resultado final da criação do diagrama Entidade-Relacionamento.

 

 

Figura 13. Resultado final do diagrama Entidade-Relacionamento.

 

Criação do diagrama de Tabelas Relacionais

O próximo passo será a elaboração do diagrama de tabelas relacionais (DTR), ou diagrama físico de dados. No exemplo, será considerado o relacionamento “conveniado” entre as entidades Medico e Convenio. Este relacionamento deverá ser mapeado em uma nova tabela recebendo como chave estrangeira as chaves primárias das tabelas envolvidas.

Para gerar o diagrama basta selecionar na barra de menu a opção Dictionary à Create Data Model à Physical Data Model. Uma nova janela será exibida com as configurações do novo diagrama, como ilustrado na Figura 14. As opções de Super/Sub Resolution Method são referentes a como as tabelas em estruturas generalização (super) / especialização (sub) serão geradas. Separate Tables gera uma nova tabela para cada entidade envolvida neste tipo de construção. Nas opções de Merge, os atributos podem ser agrupados na tabela de generalização (super) ou especialização (sub), de acordo com a opção selecionada. Por fim, a opção Prompt for each Super/Sub Group, solicita ao usuário a confirmação se cada tabela deve ser criada. Ainda é importante que a opção “Resolve non-specific relations” esteja habilitada, pois, só assim o relacionamento N:N se tornará uma nova tabela.

 

 

Figura 14. Janela de configuração do Diagrama de Tabelas Relacionais.

 

Em seguida, outra janela será exibida com as propriedades de criação do diagrama (ver Figura 15), semelhante à janela de propriedades apresentada na criação do diagrama entidade-relacionamento. Na opção “Model”, basta informar o nome do novo diagrama. Em “Database Name”, deve ser especificado o nome que será atribuído ao banco no script de criação. Em DBMS, a opção SYBASE SQL Anywhere deve ser mantida para não alterar o formato do script.

 

 

Figura 15. Criação do diagrama de Tabelas e Relacionamentos.

 

Ao definir estas opções, o diagrama de tabelas relacionais é construído com as alterações nas chaves e nas tabelas necessárias. Na Figura 16 é representado o diagrama de tabelas relacionais criado a partir da aplicação considerada no exemplo deste artigo.

 

 

Figura 16. Resultado final do diagrama de Tabelas Relacionais.

Geração do Script de criação do banco de dados

Neste ponto, pode-se optar por gerar o script para criação do banco de dados. Na ferramenta System Architect, esta é uma operação simples, bastando clicar em Tools à DB Schema Generation. Uma janela será exibida para seleção do SGBD de destino. Na criação de cada diagrama, e no momento de exportação para o script, é necessário especificar o SGBD que será utilizado. Dentre as opções fixadas nesta janela, em “Other DBMS” podem ser especificados outros SGBDs. Entre eles, pode-se citar alguns exemplos como AS 400 SQL, AS 400 DDS, Cobol, DB2, dBase, Informix, InterBase, MS Access, outras versões do SQL Server e Oracle. No exemplo, a opção Other DBMS será selecionada, já que será utilizado um SGBD diferente do SQL Server e do Oracle.

Outra janela será exibida (ver Figura 17) com as configurações finais do script. A lista Output(s) representa os possíveis comandos que podem ser definidos no script. Para o exemplo deste artigo, devem ser selecionadas as seguintes opções: “Create Index (Primary)”, “Create Index (Secondary)”, “Create Table”, “Foreign Keys” e “Primary Key”. As opções Create Index (primário e secundário) geram os índices das colunas das entidades, podendo inclusive contribuir para um melhor desempenho do banco de dados. Create Table é o comando do script que criará as tabelas do esquema. Foreign Keys e Primary Keys determinam quais atributos serão chaves primárias e quais serão chaves estrangeiras.

Ainda nesta janela, no item de menu File à Output File, pode-se definir qual o caminho do diretório no qual o script será gerado.

 

 

Figura 17. Janela de configuração do script a ser gerado.

 

Por padrão, a System Architect insere no script comandos DROP que podem ser úteis para limpar o banco antes de gerar as tabelas. Contudo, neste exemplo, esta opção será desabilitada, pois está sendo criado um novo banco de dados. Para isto, deve ser selecionado o item de menu Environment à Database. Uma nova janela será exibida (ver Figura 18), onde se deve definir como “Do not generate DROP” as opções “Drop Table”, “Drop Indices”, “Drop Constraints”, “Drop Procedures”, “Drop UserDefinedData Types” e “Drop Views”, clicando-se então no botão OK.

 

 

Figura 18. Janela de configuração de código do script.

 

Ao concluir as configurações, basta clicar no botão “Generate” na janela da Figura 17. Como resultado, é gerado o script para criação do banco de dados (ver Figura 19).

 

 

Figura 19. Script gerado pela ferramenta.

Engenharia reversa

Engenharia reversa é um processo inverso ao que foi feito anteriormente. É um procedimento que possibilita que se chegue ao diagrama que deu origem a um banco de dados a partir do script que o gerou. É uma atividade que trabalha com um produto existente. Esta funcionalidade, embora tenha resultados satisfatórios, requer uma revisão geral do diagrama criado a partir do script para a certificação da coerência entre os elementos definidos no modelo e aqueles que serão criados quando da execução do script.

Neste artigo, será considerado o script criado nos passos anteriores. A partir deste script, será criado o diagrama de tabelas relacionais. Para dar início ao processo, deverá ser selecionada no menu principal a opção Tools à DB Reverse Engineering. Uma janela para seleção do SGBD será exibida, exatamente como foi feito na seleção de SGBD para geração de script. No exemplo, deve ser selecionada a opção “Other DBMS”.

Ao clicar em Next, outra janela será exibida. Nela deverá ser carregado o script a partir do qual o diagrama será criado. Este procedimento é feito a partir do menu File à Import DDL File. Ao selecionar o arquivo, basta definir um nome para o novo diagrama e este será automaticamente gerado.

Funcionalidades extras e add-ons

O conjunto de recursos da System Architect é muito amplo e versátil. A ferramenta apresenta ainda diversas funcionalidades extras, como a sincronização entre o modelo e o banco de dados propriamente dito. Esta funcionalidade pode ser acessada a partir do menu Tools à DB Synchronization. Esta opção está disponível para bancos de dados Oracle e SQL Server.

A ferramenta possibilita ainda a instalação de add-ons, isto é, pacotes que auxiliam no desenvolvimento de projetos.

Um recurso bastante interessante é o Spell que funciona como um corretor ortográfico. Existe na ferramenta um dicionário a partir do qual é possível incluir algumas definições. Nas telas de configuração e criação de diagramas, o botão Spell compara o que foi escrito em um campo, por exemplo, um nome de uma entidade com as entradas do dicionário. Este tipo de comparação minimiza a inserção de nomes errados no momento de criação do diagrama, e evita que estes erros sejam um problema no final do projeto.

Além do Spell, pode-se destacar também o Information Web Publisher. Trata-se de um módulo para gerar relatórios HTML, auxiliando na geração de documentação e permitindo que as equipes de um projeto que trabalham em localizações diferentes possam compartilhar as informações com mais facilidade. Utilizando o menu Report à HTML Reports, é possível acessar a janela de configuração do relatório, como exibido na Figura 20.

 

 

Figura 20. Documentação gerada pela ferramenta.

Conclusão

Neste artigo foram apresentadas algumas das principais funcionalidades da ferramenta de modelagem System Architect.

Além dos tipos de diagramas aqui descritos, a ferramenta possibilita a construção de diversos outros tipos de modelos, podendo auxiliar efetivamente em projetos que utilizem diferentes paradigmas de desenvolvimento e técnicas de modelagem. A System Architect não é uma ferramenta gratuita, mas uma versão limitada pode ser baixada no site de seu fabricante.

Uma vantagem desta ferramenta em relação a outras disponíveis no mercado é a sua versatilidade, uma vez que oferece uma grande gama de tipos de diagramas para serem construídos e, especificamente para modelos de dados, oferece uma variedade de bancos de dados que podem ser criados a partir dos scripts gerados pela ferramenta.

Links

System Architect: http://www.telelogic.com/products/systemarchitect/index.cfm

 

Ricardo de Oliveira Martins Mendes (romendes@si.granbery.edu.br) é graduando do curso de Bacharelado em Sistemas de Informação da Faculdade Metodista Granbery, monitor da disciplina Laboratório de Programação II, com a ferramenta de desenvolvimento Delphi e banco de dados Interbase.

 

Melise Maria Veiga de Paula (mmvpaula@granbery.edu.br) é Doutora em Engenharia de Sistemas e Computação pela Universidade Federal do Rio de Janeiro. Atualmente é professora do curso de Sistemas de Informação da Faculdade Metodista Granbery.

 

Marco Antônio Pereira Araújo (maraujo@granbery.edu.br) é Doutorando e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ, Especialista em Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Informática pela UFJF, Professor do Curso de Bacharelado em Sistemas de Informação da Faculdade Metodista Granbery, Analista de Sistemas da Prefeitura de Juiz de Fora.

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