843784 - TCC - Pos BD - Henrique e Ricardo

IMPLEMENTAÇÃO DE UM VALIDADOR DE PADRÃO DE
NOMENCLATURA DE SCRIPTS SQL PARA BANCO DE DADOS
RELACIONAIS
PEREIRA, Henrique F. (Pós Graduação em Banco de Dados,
[email protected])
MUNDIM, Ricardo B. G. (Pós Graduação em Banco de Dados,
Correspondência: [email protected])
LOPES, Marcos (Pós Graduação em Banco de Dados,
[email protected])
SANTANA, Sônia A. (Pós Graduação em Banco de Dados,
[email protected])
SOARES, Hélio R. (Pós Graduação em Banco de Dados, [email protected])
Resumo. Este artigo releva a importância da verificação dos modelos
de dados com os padrões definidos nas organizações, para assegurar
que toda estrutura de banco de dados esteja com os padrões
adotados. Foi identificado que o processo de checagem do modelo de
dados com as normas definidas gastam um tempo precioso dos
administradores de banco de dados. O foco deste trabalho é propor
uma solução em software onde é possível realizar o cadastro de
alguns padrões e palavras reservadas que juntos formarão templates,
que serão utilizados pelos administradores de banco de dados no
auxílio da validação do padrão de nomenclatura dos modelos,
apontando no script as falhas quando encontrarem, ficando visíveis os
pontos a serem atacados, evitando retrabalhos futuros. Tendo como
resultado a visualização do script avaliado, destacando-se as falhas
encontradas conforme as regras definidas, auxiliando o responsável
pela modelagem na correção do padrão de nomenclatura do banco de
dados.
Abstract. This article highlights the importance of checking the data
models defined in the standards organizations to ensure that the whole
structure of the database is with the standards adopted. It was
identified that the process of checking the data model with defined
standards spends precious time of database administrators. The focus
of this work is to propose a software solution where it is possible to
perform the registration of some patterns and keywords that together
form templates, which will be used by database administrators to aid
the validation of the naming standard models, pointing to the script
failures when they meet, leaving visible points to be attacked, avoiding
rework future. Resulting in the display of the script evaluated,
highlighting the flaws found by the rules set by assisting responsible for
modeling the pattern correction naming database.
1. Introdução
O desenvolvimento de software é um processo que depende de vários
fatores e fases. Em todas as fases do desenvolvimento sempre existem
preocupações com as fases seguintes. Por isso, a equipe envolvida com o
projeto de desenvolvimento de software deve passar por algumas etapas, tais
como, reuniões com usuários, levantamento de requisitos, desenho da
solução, desenho dos casos de uso, modelagem do banco de dados, entre
outras, até que se inicie a codificação da aplicação.
Desde a primeira fase da construção da aplicação até a sua entrega
existe uma dependência entre as etapas, e é necessário realizar a validação
de todos os procedimentos/responsabilidades em cada fase, pois se ocorrer
alguma falha em uma delas poderá acarretar problemas futuros na aplicação
(FOWLER, 2006).
Desta forma, este artigo tem como objetivo auxiliar a validação de uma
das fases, a modelagem de dados, apresentando uma solução para realizar,
de forma eficiente, a validação da padronização da nomenclatura dos objetos
do modelo de dados.
A modelagem de dados trata-se de uma das etapas do desenvolvimento
de uma aplicação e descreve a forma na qual os dados serão armazenados,
como funcionará, a lógica e auxilia na confecção da aplicação. A modelagem
do banco de dados é dividida em três formas (ELMASRI; NAVATHE, 2006):
Modelo conceitual – responsável por representar a forma na qual o
usuário visualiza o ambiente e não leva em conta o banco de dados, mas
como serão criadas as estruturas de armazenamentos. Neste momento a
participação do usuário é fundamental (SETZE; SILVA, 2005).
Modelo lógico – defini a arquitetura na qual será criado o banco de
dados, como exemplo: banco de dados relacional, orientado a objeto,
hierárquico, etc. Também é feita a normalização geralmente até a 3ª forma
normal (Forma Normal: é constituída de cinco fases na atualidade, mas
usualmente utiliza-se até a 3ª e esse processo é realizado para tornar o
armazenamento dos dados eficiente, eliminando redundância e
inconsistência), adequação ao padrão de nomenclatura, etc (SETZE; SILVA,
2005).
Modelo Físico – a definição de qual sistema gerenciador de banco de
dados (Oracle, SQL Server, Firebird, etc.) ou como é conhecido popularmente
SGDB é determinado neste modelo, demonstra fisicamente como os dados
serão armazenados e é construído baseando-se no modelo lógico (SETZE;
SILVA, 2005).
Para construção dos modelos de dados, as equipes de desenvolvimento
utilizam ferramentas como CA Erwin Data Modeler, Power Designer, entre
outras. Também chamadas de ferramenta case, facilitam o desenvolvimento
dos modelos e aplicação das definições criadas para sua elaboração. Apesar
do uso das ferramentas case, é necessário fazer uma checagem na
padronização do modelo de dados e para realização desta verificação, podemse usar ferramentas ou codificação no sistema (SCHAEFER, 2010).
2. Sistemas relacionados
Atualmente existem diversas ferramentas para auxiliar na criação de
modelos de dados e na validação do padrão de nomenclatura desses modelos.
Destacando-se como ferramentas que auxiliam na criação dos modelos, temse CA Erwin Data Modeler e Power Designer e para a validação do padrão de
nomenclatura dos modelos, tem-se a ferramenta CA Erwin Data Model
Validator (SCHAEFER, 2010).
As ferramentas que auxiliam na criação de modelos de dados também
são utilizadas para outras atividades como documentação, projeto de banco de
dados, dentre outras. A empresa CA Techologies é detentora dos softwares
CA Erwin Data Modeler, CA Erwin Data Model Validator entre outros softwares,
e possui várias edições, o que possibilita uma maior flexibilidade de acordo
com o negócio da empresa.
A ferramenta CA Erwin Data Modeler é uma ferramenta robusta que
simplifica a criação de modelos de dados que podem ser do tipo lógico ou
físico, ou lógico e físico (ARAÚJO, 2007). Também é possível criar templates
com alguns padrões para auxiliar no desenvolvimento dos modelos. Além da
construção do modelo, a ferramenta possui outras características importantes,
tais como, a possiblidade de armazenar procedures, views, volumetria, trigger,
tornando-se uma ferramenta robusta (CA TECHNOLOGIES, 2013).
A criação do template faz com que toda modelagem siga o padrão
definido no momento da criação do objeto, na área de desenvolvimento, por
outro lado, é possível alterar qualquer regra definida no template após a
criação do objeto, deixando a modelagem vulnerável (CA TECHNOLOGIES,
2013).
A figura 1 apresenta a tela inicial da ferramenta CA Erwin Data Modeler.
Pode-se observar diversas opções no menu à esquerda e na barra de
ferramentas no topo.
Figura 1: Tela inicial do CA Erwin Data Modeler (CA TECHNOLOGIES, 2013).
A ferramenta CA Erwin Data Model Validator possui um conjunto
abrangente de diagnósticos que ajudam a validar a integridade estrutural do
esquema de banco de dados relacionais. Analisa as estruturas de dados,
chaves, índices, colunas e relações de violações das regras de design de
banco de dados relacional. Ela gera a documentação gráfica de toda a
estrutura de base de dados incluindo a coluna de referência cruzada e listas de
relacionamento (CA TECHNOLOGIES, 2011).
Os diagnósticos podem ser personalizados para refletir as exigências e
as prioridades das organizações. A falta de padronização é um dos principais
contribuintes para os altos custos e longos ciclos de desenvolvimento.
Geralmente essas falhas só são encontradas na fase de testes, acarretando
um retrabalho em todo o ciclo de vida do projeto, desde a modelagem que
pode sofrer alteração nos nomes dos objetos e em todos os processos que
estiverem diretamente ligados ao banco. A figura 2 apresenta um relatório
onde é possível visualizar a critica que a ferramenta CA Erwin Data Model
Validator apresentando-se dados referentes a tabelas, relacionamentos e
índices e realizando um diagnóstico onde se podem observar as falhas
encontradas conforme a regra aplicada para validação da modelagem (CA
TECHNOLOGIES, 2011).
Figura 2: Relatório extraído da ferramenta CA Erwin Data Model Validator.
Outro programa conhecido é o Power Designer que é um programa
modular, no qual permite aos clientes adquirir os pacotes de acordo com as
necessidades do negócio. O suporte do Power Designer é atualmente
realizado pela empresa SAP que comprou a empresa Sybase e ainda mantém
a marca. A empresa Powersoft foi comprada pela Sybase, que antes havia
adquirido a empresa SDP Technologies, nesta, o autor Xiao-Yun Wang foi o
responsável pela criação da aplicação (SYBASE, 2013).
A ferramenta Power Designer suporta diversas fases no processo de
desenvolvimento, dependendo do pacote de distribuição adquirido. Uma das
principais funções é a possibilidade de modelagem de dados. A figura 3
mostra a tela inicial do Power Designer (SYBASE, 2013).
A Microsoft por sua vez desenvolveu um componente para os
desenvolvedores
que
utilizam
o
seu
aplicativo
Silverlight
o
System.ComponentModel.DataAnnotations, este componente, por sua vez,
contém as classes que são usadas como atributos de dados na aplicação
(MSDN, 2010).
Os atributos de anotação de dados se dividem em três categorias:
validação de atributos, exibição de atributos e os atributos de modelagem de
dados. Usando as três categorias é possível validar e apresentar em tempo de
desenvolvimento algumas regras no modelo de dados.
Figura 3: Tela inicial do Power Designer.
Apesar da praticidade que as ferramentas case proporcionam no
desenvolvimento da modelagem de dados, utilizando templates personalizados
com as regras definidas nas empresas, o modelo de dados precisa passar por
um processo de checagem. Este processo, muitas vezes, é realizado de forma
manual pelo administrador ou responsável pelo banco de dados, podendo
acarretar falhas nas checagens e tempo excessivo para realização desta
tarefa.
Com a implementação de uma solução para validação do padrão de
nomenclatura de scripts SQL para banco de dados relacionais,
tem-se
o
aumento de produtividade e assertividade na checagem do modelo, uma vez
que o padrão pode variar de empresa para empresa e até mesmo de sistema
para sistema.
3. Estudo de caso
A solução proposta neste artigo foi o desenvolvimento de um software
para auxiliar o administrador de banco de dados ou o responsável pela
modelagem do banco de dados relacionais no quesito de verificação de
padrões de nomenclatura nos modelos de bancos de dados antes de entrarem
no ambiente produtivo e até mesmo antes de entrar no ambiente de
desenvolvimento, possibilitando a correção do modelo caso haja alguma regra
que não foi seguida durante o desenvolvimento da modelagem do banco de
dados relacional.
Para o seu desenvolvimento, dentre inúmeras linguagens de
programação foi utilizado à linguagem Delphi na versão RAD Studio XE3 da
Embarcadero juntamente com o banco de dados SQLite como repositório das
regras de validação. Na figura 4 é demonstrado o DER Lógico da estrutura
interna do banco de dados do software proposto para auxiliar os
administradores de banco de dados.
Figura 4. DER Lógico da estrutura do banco de dados.
A figura 5 apresenta os processos para o desenvolvimento das funções
de cadastro de objeto e de template respectivamente.
Figura 5. Processo de cadastro de objeto e template.
A ideia principal da ferramenta esta em ler as regras de uma base
previamente gravada, denominadas como templates e através de
comparações o algoritmo faz as devidas validações e sinaliza os erros
encontrados no script. A figura 6 apresenta o processo de validação do script
contendo a modelagem do banco de dados.
Figura 6. Processo de validação do script do banco de dados.
Tendo como origem os scripts da modelagem de banco de dados a
ferramenta desenvolvida utiliza templates cadastrados pelo utilizador para
capturar as regras a serem utilizadas para validar e criticar o modelo caso seja
necessário. Caso a solução encontre alguma parte do script que esteja fora
das regras cadastradas esta parte é destacada no script e também é
referenciada na tela principal acusando o tipo de objeto que possui a falha na
padronização. Como cada organização possui suas regras ou normas de
banco de dados a solução desenvolvida foi dividida em duas frentes, cadastros
e atividades.
Dividido a solução nestas duas frentes, possibilita-se que os usuários
consigam adicionar suas regras utilizando os templates assim não ficando
presos em regras pré-definidas por uma ou outra entidade, deixando desta
forma livre o que validar nos modelos.
Como a solução realiza o upload dos arquivos de banco de dados o
desenvolvimento da modelagem não fica restrito a uma ou outra aplicação,
apenas é necessário seguir o padrão de script aceito.
A primeira frente é à frente de cadastro, que está dividida em duas
etapas, são elas cadastro de objetos e cadastro de templates.
Na etapa de cadastro de objetos, cadastram-se todos os tipos de
objetos e seus respectivos prefixos, esse cadastro possibilita a solução a
verificar se foi utilizado algum prefixo nos objetos que estão fora do padrão da
organização. Como se podem ter mais de uma regra dentro da mesma
organização devido a sistemas diferente ou até mesmo a adoção de novos
padrões, é possível cadastrar mais de um prefixo para um objeto. Para isto
bastam criar o registro do objeto quantas vezes for necessário alterando o seu
prefixo, já que os padrões podem variar entre sistemas. Estes objetos
cadastrados são associados aos templates na tela de cadastro de templates. A
figura 7 mostra a tela de cadastro de objetos com alguns exemplos
cadastrados.
Figura 7: Tela cadastro de objetos.
Na tela de cadastro de templates tem-se a possibilidade de cadastrar
um ou vários templates. Estes templates são utilizados para validar o script do
banco de dados. Nele cadastram-se os seguintes itens: owner das tabelas,
prefixo e mnemônico de tabelas, views, chave primaria, chave estrangeira,
chave alternativa. Além de selecionar os objetos previamente cadastrados na
tela de cadastro de objetos, e cadastrar as palavras na lista de exceções. A
figura 8 mostra a tela de cadastro de templates.
Figura 8: Tela cadastro de templates.
Com essas duas funcionalidades de cadastro têm-se as regras para
validar o modelo, já a frente de atividades é a tela onde se encontra o processo
de validação do script. Para realizar esta validação é necessário efetuar a
leitura do arquivo contendo o script da modelagem que deseja validar. A figura
9 mostra um exemplo deste script.
CREATE TABLE dbo.tb_object
(
cod_object varchar(18) NOT NULL ,
des_object varchar(20) NULL ,
des_prefix_objectvarchar(20) NULL ,
cod_template integer NULL
)
go
ALTER TABLE dbo.tb_object
ADD CONSTRAINT pk_object PRIMARY KEY
go
NONCLUSTERED cod_object ASC)
ALTER TABLE dbo.tb_object
ADD CONSTRAINT fk_object FOREIGN KEY (cod_template) REFERENCES
dbo.tb_template (cod_template)
go
Figura 9: Exemplo de script de criação de objeto de banco.
Feito a escolha do script, deve-se selecionar o template que possui as
regras que serão aplicadas na validação. A figura 10 apresenta a rotina inicial
encarregada de separar e classificar cada linha do arquivo que está sendo
validado.
procedure TFrmValidacao.ValidarArquivo;
var
sLinha: string;
begin
FrmPrincipal.pbProgresso.Max := FMaxSize;
ResetaContadores;
rheArquivo.Lines.BeginUpdate;
for FIdx := 0 to FMaxSize do
begin
Application.ProcessMessages;
FrmPrincipal.pbProgresso.Position :=
FrmPrincipal.pbProgresso.Position + 1;
sLinha := Trim(AnsiLowerCase(rheArquivo.Lines[FIdx]));
FLinha := FIdx + 1;
case TipoObjeto(sLinha) of
toTabela : ValidarTabela(sLinha);
toView
: ValidarView(sLinha);
toChavePri: ValidarChavePri(sLinha);
toChaveEst: ValidarChaveEst(sLinha);
toChaveAlt: ValidarChaveAlt(sLinha);
toIndice : ValidarIndice(sLinha);
toNone
: Continue;
end;
end;
rheArquivo.Lines.EndUpdate;
FrmPrincipal.pbProgresso.Position := 0;
if not FErro then
begin
tvInconsistencia.Items.Clear;
tvInconsistencia.Items.Add(nil, 'Script validado com sucesso!');
end;
end;
Figura 10. Rotina de validação do script de banco de dados.
Após a fase de identificação do tipo de linha, o sistema chama o
procedimento que faz a consistência do conteúdo desta linha.
O método empregado nesta validação está baseado na procura
sequencial de palavras reservadas definidas internamente na aplicação e pelos
prefixos cadastrados no template em uso, quando o sistema esta validando
uma estrutura de tabelas é feito também a validação dos objetos que
compõem esta tabela, ou seja, o sistema faz uma verificação secundaria
através do método Validar Objeto.
Caso seja detectada alguma inconformidade durante esta validação a
rotina em uso identifica a linha e o tipo de erro encontrado destacando a
inconformidade na tela. Na figura 11 é demonstrado o procedimento de
validação de uma tabela de banco de dados.
procedure TFrmValidacao.ValidarTabela(aLinha: string);
var
bOwner: Boolean;
bAlter: Boolean;
bPrefi: Boolean;
begin
FAna := 0;
FCor := 0;
FInc := 0;
FMsg := '';
with dtmDados.FObjetosTemplate do
begin
FCriacao := Pos(createT, aLinha) > 0;
bAlter
:= Pos(alterT, aLinha) > 0;
if Owner <> '' then
bOwner := Pos(Owner,aLinha) > 0 else bOwner := True;
if Table <> '' then
bPrefi := Pos(Table,aLinha) > 0 else bPrefi := True;
if FCriacao then
begin
FAna := 1;
if bOwner = false or bPrefi = false then
FInc := 1
else
FCor := 1;
if bOwner = false then
begin
FMsg := 'Owner da Tabela não informado';
InsereErro(toTabela, MSGTabela + FormatFloat('0000',FLinha) +
' - ' + aLinha + ' / ' + FMsg,aLinha);
end;
if bPrefi = false then
begin
FMsg := 'Prefixo da Tabela não informado';
InsereErro(toTabela, MSGTabela + FormatFloat('0000',FLinha) +
' - ' + aLinha + ' / ' + FMsg,aLinha);
end;
ValidarObjeto;
end
else if bAlter then
begin
FCor := 0;
FInc := 0;
end
else
begin
FInc := 1;
FMsg := 'Sintaxe incorreta';
end;
SetaTabela(FAna,FCor,FInc);
end;
end;
Figura 11. Rotina de validação de Tabela.
Como resultado da validação tem-se os objetos analisados, separados
em tipos de objetos. Tais tipos estão separados em quantidade analisadas,
corretas e incorretas. Quando se encontra algum objeto que esteja fora do
padrão determinado, o mesmo é registrado como incorreto e apresentado na
lateral direita e também sinalizado no corpo do script que fica na aba arquivo.
A figura 12 mostra a tela de atividades, aba validação, apresentado uma
validação e as inconsistências encontradas.
Figura 12: Tela de atividades.
A figura 13 mostra a tela de atividades aba arquivo apresentando um
arquivo com os destaques nas inconsistências encontradas.
Figura 13: Tela de atividades.
4. Resultados e discussões
A ferramenta proposta foi testada com diversos arquivos contendo
modelos de dados de tamanhos diferentes e diversas falhas de padronização.
Na figura 14 mostra-se o template utilizado para realização dos testes.
Figura 14: Tela contendo o template utilizado na validação de script.
Na figura 15 apresenta-se parte do script utilizado nos testes, este script
esta dentro do padrão cadastrado no template utilizado para a análise.
CREATE TABLE dbo.tb_cpm_executive
(
id_executive
int NOT NULL IDENTITY ( 1,1 ) ,
id_manager
int NULL ,
nm_executive
varchar(120) NOT NULL ,
nr_cpf
varchar(11) NULL ,
cd_source
char(1) NULL,
nr_source
varchar(9) NULL ,
ds_email
varchar(100) NOT NULL ,
cd_cdg
varchar(3) NOT NULL)
go
ALTER TABLE dbo.tb_cpm_executive
ADD CONSTRAINT pk_cpm_executive PRIMARY KEY NONCLUSTERED
(id_executive ASC)
go
CREATE UNIQUE NONCLUSTERED INDEX ak_cpm_executive_cd_cdg ON
dbo.tb_cpm_executive
(cd_cdg ASC)
Go
Figura 15: Script de criação do banco dentro do padrão definido no template.
A figura 16 apresenta a análise realizada no script da modelagem de um
banco de dados baseando-se no template apresentado na figura 14. Pode-se
observar no lado esquerdo a quantidade de objetos analisados e do lado
direito no quadro de inconsistência a critica da ferramenta, como script
validado com sucesso. Indicando para quem possa estar utilizando a solução
proposta que o script analisado esta dentro dos padrões acordados ou
definidos no template escolhido para a análise.
Figura 16: Tela de atividades apresentado a critica na análise de um script dentro do
padrão.
Por outro lado também foram realizados testes com scripts contendo a
modelagem do banco de dados fora do padrão definido no template. Na figura
17 apresenta-se parte de um script utilizado nos testes da ferramenta onde o
script está fora do padrão.
CREATE TABLE dbo.tb_object
(
cd_object
varchar(18) NOT NULL ,
ds_object
varchar(20) NULL ,
ds_prefix_object varchar(20) NULL ,
cd_template
integer NULL,
cd_cdg
varchar(3) NOT NULL)
go
ALTER TABLE dbo.tb_object
ADD CONSTRAINT pk_object PRIMARY KEY
go
NONCLUSTERED cod_object ASC)
ALTER TABLE dbo.tb_object
ADD CONSTRAINT fk_object FOREIGN KEY (cod_template) REFERENCES
dbo.tb_template (cod_template)
Go
Figura 17: Script de criação do banco fora do padrão definido no templates.
A figura 18 apresenta a análise realizada no script que esta fora do
padrão definido no template apresentado na figura 14. Pode-se observar no
lado esquerdo a quantidade de objetos analisados e do lado direito no quadro
de inconsistência a critica da ferramenta, apontando a falha do padrão
encontrada, indicando o objeto, a linha dentro do script e a falha encontrada.
Figura 18: Tela de atividades apresentado a critica na análise de um script fora do
padrão.
Com o resultado da análise do script fornecido pelo software é possível
realizar a correção do padrão da nomenclatura do modelo de dados, uma vez
que as inconsistências são apontadas, destacando-se o tipo de objeto que
contem a falha e quais são as falhas apontando as linhas e quais os pontos
falhos.
Com as informações em mãos os responsáveis pela modelagem podem
rever a modelagem atacado os pontos destacados diretamente, não sendo
necessário ficar procurando manualmente as falhas em toda a modelagem,
aumentando assim a assertividade na validação da padronização de
nomenclatura do modelo de dados e diminuindo possíveis falhas na validação
manual.
Visando a padronização e a assertividade na modelagem do banco de
dados a ferramenta possibilita o cadastramento de vários templates baseandose nas regras necessárias para a validação da modelagem, auxiliando assim o
responsável da modelagem. Os dados cadastrados na solução tais como,
objetos, templates e palavras reservadas podem ser reaproveitados em outras
validações e até mesmo reutilizados para a confecção de novos templates,
possibilitando assim a diminuição do tempo gasto nas validações futuras de
modelagem de dados.
5. Conclusão
Conclui-se que o mercado atual disponibiliza algumas ferramentas para
auxiliar os administradores de banco de dados no momento crucial de
validação do modelo com as normas das organizações. Porém as ferramentas
mais conhecidas além de serem pagas são de alguma forma acoplada a outra
ferramenta ou até mesmo acopladas a um banco de dados específico.
Com a evolução dos sistemas a padronização fica a cada dia mais
importante nas organizações, portanto é necessário se ter em mãos uma forma
rápida e segura de realiza-se a checagem dos modelos que estão por entrarem
nos ambientes e até mesmo possibilitar realização de checagem de modelos já
em ambiente produtivo realizando a engenharia reversa destes bancos.
Atualmente a solução proposta consegue realizar a verificação de owner
das tabelas, prefixo e mnemônico de tabelas, views, chave primaria, chave
estrangeira, chave alternativa. Essas checagens já são de grande importância
quando o assunto é padronização do modelo de dados.
Fica como trabalho futuro a adição de outras regras, tais como,
validação de relacionamento, regra para formação do nome dos
relacionamentos compostos como, por exemplo, a concatenação do nome de
tabela origem e tabela destino, tamanho do nome dos campos, possibilidade
de geração de relatórios entre outros pontos que podem se tornarem
importante para a padronização dos modelos de dados e também a utilização
de técnicas de análise sintática formais para melhoramento no desempenho de
busca das regras nos scripts a serem validados.
Referências
ARAÚJO, Marco Antônio. Ferramenta Erwin, uma ferramenta CASE para
modelagem de dados. Disponível em: <http://www.devmedia.com.br/ferramen
ta-erwin-uma-ferramenta-case-para-modelagem-de-dados/8085>. Acesso em:
10 mai. 2013.
CA TECHNOLOGIES. CA Erwin Data Modeler. Disponível em: <https://suport.
ca.com/cadocs/0/CA ERwin Data Modeler r9 2-ENU/Bookshelf_Files/PDF/ERwi
n_Overview.pdf >. Acesso em: 03 mai. 2013.
CA TECHNOLOGIES. CA Erwin Data Model Validator. Disponível em: <https:
//support.ca.com/cadocs/0/CA ERwin Data Modeler r8-ENU/Bookshelf_Files/P
DF /DMV_Impl.pdf>. Acesso em: 03 ago. 2013.
ELMASRI, R.; NAVATHE. Sistemas de Banco de Dados: Fundamentos e
Aplicações. Pearson Education, 2006.
FOWLER, Martin. Padrões de Arquitetura de Aplicações Corporativas.
Bookman, 2006.
MSDN, Microsoft. Using Data Annotations to Customize Data Classes.
Disponível em: <http://msdn.microsoft.com/en-us/library/dd901590(v=vs.95).as
px>. Acesso em: 03 ago. 2013.
SCHAEFER, Roberto. Uso de Ferramentas Case – Auxilio na Modelagem
de dados. Disponível em: <http://www.inmersion.com.br/Archive/TI/Artigos e
Palestras/Palestra_Ferramenta_CASE.pdf>. Acesso em: 10 mai. 2013.
SETZE, V.; SILVA, F. S. Banco de Dados. Aprenda o que são, melhore seu
conhecimento, construa os seus. São Paulo: Edgard Blücher, 2005.
SYBASE. Power Designer 16.5. Disponível em: <http://infocenter.sybase.com/
help/index.jsp?topic=/com.sybase.infocenter.help.pd.16.5/doc/html/title.html>.
Acesso em: 28 abr. 2013.