ADCONTAR

ARTIGO

MODELO LÓGICO DE BANCO

DE DADOS PROPOSTO PARA
UMA CONT ABILIDADE DE
CONTABILIDADE
PARTIDA MÚLTIPLA
Dinaldo do N. Araújo*

RESUMO balho de IJIRI (1967), onde o mesmo menci-

O presente artigo aborda conceitos de banco de dados,
visões de banco de dados, componentes de um SGBD,
projeto lógico de banco de dados, projeto físico de banco
de dados, modelos de banco de dados e Modelo Entidade-
Relacionamento (E-R), com a finalidade de propor a imple-
mentação de um projeto lógico de banco de dados que
colabore para uma contabilidade de partida múltipla.
I - INTRODUÇÃO
Do período da Revolução Industrial até o fi-
nal do século XIX, o mundo se deparou com
diversas mudanças e das mais variadas or-
dens: sociais, políticas, econômicas e cul-
turais. Uma destas mudanças foi com rela-
ção ao tratamento dado à informação . As
organizações e as pessoas passaram a tra-
tar a informação proveniente dos sistemas
existentes de uma maneira mais significativa
e valorosa. Chegando ao ponto de criarem
reservatórios de dados e de informações, o
que deu origem ao que nós chamamos de
Banco de Dados. No que tange à área con-
tábil, este tratamento especial dado à infor-
mação também teve reflexo nas teorias con-
tábeis, o que pode ser evidenciado no tra-
ona a importância da contabilidade no mo-
mento de subsidiar os usuários da contabili-
dade com informações úteis e diversas, o
que ele chama de Partidas Múltiplas e Con-
tabilidade Multidimensional.
Logo, este trabalho tem a finalidade de abor-
dar Banco de Dados como uma ferramenta
que possa contribuir de alguma forma com o
que IJIRI (1967) chama de Partidas Múltiplas.
O trabalho abordará conceitos de banco de
dados relacional e o método de partidas
múltiplas assim chamado por IJIRI (1967).
II - TERMINOLOGIA BÁSICA
BIT – Representa a menor parcela que o
computador pode manipular.
BYTE – É um grupo de bits (8 bits) que re-
presenta um único símbolo ou caractere.
CAMPO – É um agrupamento de caracteres
em uma palavra, grupo de palavras, número
ou um conjunto de números.
REGISTRO – É uma coleção de campos
de dados relacionados.

* Contador, Pós-Graduado em Sistemas de Informações e Professor do Curso de Cièncias Contábeis da UNAMA

Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003

3

ARTIGO MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
P ARA UMA CONT ABILIDADE DE P
CONTABILIDADE
PARTIDA
ARQUIVO – É um grupo de registros de
dados relacionados.
BANCO DE DADOS – É o arquivo físico,
em dispositivos periféricos, onde estão ar-
mazenados os dados de diversos sistemas,
para consulta e atualização pelo usuário.
S.G.B.D
.D.. (Sistema Gerenciador de Banco de
.G.B.D
Dados) – É o software responsável pelo ge-
renciamento (armazenamento e recuperação)
dos dados no Banco de Dados.
DADO – É o valor do campo quando é ar-
mazenado no Banco de Dados.
INFORMAÇÃO – É o valor que este campo
representa para as atividades a que se pro-
põe determinado Banco de Dados.
III - BANCO DE DADOS
Como foi mencionado na introdução des-
te trabalho, até o século XIX a informação ob-
teve um tratamento especial. Para nós fica
claro que do século XX em diante estaremos
ou teremos que gerenciar os dados e as in-
formações, atividade esta que para nós se
tornou muito importante dentro das organi-
zações. De acordo com CHEN (1990), ao
longo dos tempos, o surgimento de novas
formas de comunicação ou transações en-
tre as organizações e as pessoas e o de-
senvolvimento tecnológico, acabam nos le-
vando para uma sociedade orientada para a
informação, o que provavelmente pode se
transformar num problema: como organizar
os dados para maximizar sua utilidade?
Na realidade, este é o papel dos siste-
mas de arquivo e sistemas de Banco de
Dados baseados em computador: tentar
simplificar a tarefa de manter e recuperar uma
grande quantidade de dados e informações.
Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003
4
ADCONTAR
ARTIDA MÚLTIPLA
Dinaldo do N. Araújo
LAUNDON & LAUNDON (1999), definem
banco de dados da seguinte forma: “uma
coleção de dados organizados de tal forma
que possam ser acessados e utilizados por
muitas aplicações diferentes”.
Portanto, dentro das empresas, segundo
LAUNDON & LAUNDON (1999) em todo sis-
tema de informação os dados devem ser or-
ganizados e estruturados para que possam
ser usados com eficácia, caso contrário o
sistema não pode alcançar seu objetivo. E
para isto existem os métodos de armazena-
gem e de recuperação de informação, que
dependendo da sua construção e do seu
uso, podem levar um sistema de informação
ao sucesso ou insucesso. Exemplos exis-
tem vários no mercado, empresas com ex-
celentes hardwares, mas com softwares que
não conseguem produzir informações opor-
tunas e precisas.
Vivemos num emaranhado mundo de in-
formações, e se não planejarmos, estrutu-
rarmos e armazenarmos estas informações
de maneira lógica e de fácil acesso, corre-
mos o sério risco de nos perdermos em mo-
mentos de decisões importantes e acabar-
mos ficando desinformados. Portanto, este
é o objetivo do Banco de Dados, armazenar
dados e informações, de maneira lógica, de
fácil acesso e de maneira rápida.
IV - SISTEMA DE BANCO DE
DADOS X SISTEMA DE AR-
QUIVOS TRADICIONAIS
Um sistema de arquivos tradicional é
aquele em que os dados do sistema estão
armazenados fisicamente separados um do
outro. O acesso é feito pelos programas de
aplicação, associando o nome externo dos
arquivos e definindo todo o registro indepen-
dente da utilização dos campos.
ADCONTAR
MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
UMA CONT ABILIDADE DE P
CONTABILIDADE
Problemas do sistema de arquivos tradicio-
nal:
a ) Redundância de dados – refere-se à pre-
sença de dados duplicados em múltiplos
arquivos de dados. Em outras palavras,
um certo dado pode aparecer em mais
de um arquivo, pelo fato de se ter vários
sistemas. Ex. o nome de um funcionário
pode aparecer em vários arquivos, pelo
fato de determinada empresa ter dois ou
mais sistemas que usem o nome do fun-
cionário.
b ) Dependência de programas e dados –
refere-se ao estreito relacionamento en-
tre os dados armazenados em arquivos
e os programas que os utilizam. No caso
de alterar algum formato de dado ou na
estrutura de um arquivo, será necessário
alterar o programa que o usa. Ex. se qui-
sermos alterar o formato do CEP de um
determinado arquivo, de cinco dígitos
para oito dígitos, será necessário alterar
o arquivo e os sistemas que o usam,
exigirá um esforço considerável, princi-
palmente de tempo.
c ) Inconsistência de dados - São as incon-
sistências entre as diversas representa-
ções do mesmo fragmento de dado em
diferentes sistemas e arquivos. Ex. o en-
dereço de uma pessoa em um sistema
pode ser X (endereço velho, não atuali-
zado) e em outro sistema o endereço
pode ser Y (endereço novo), isto pode
causar sérios problemas de atualização.
d ) Custos excessivos – a manutenção se
torna onerosa, para manter os diversos
arquivos e sistemas atualizados.
Sistema de banco de dados – É aquele em
que os dados são definidos para o SGBD,
através da DDL (Linguagem de definição de
Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003
ARTIGO
PARTIDA
ARTIDA MÚLTIPLA
dados). Fisicamente estão armazenados em
um único local, sendo o acesso realizado
apenas através do SGBD. Nos programas
de aplicação, é necessário apenas definir os
campos que serão utilizados pelo programa.
Muitos dos problemas do ambiente de ar-
quivos tradicional podem ser resolvidos ado-
tando-se uma abordagem de Banco de Da-
dos para o gerenciamento e armazenamen-
to dos dados.
Vantagens do uso do Banco de Dados:
a ) Redução ou eliminação de redundâncias
– Possibilita a eliminação de dados priva-
tivos de cada sistema. Os dados, que
eventualmente são comuns a mais de um
sistema, são compartilhados por eles,
permitindo o acesso a uma única informa-
ção consultada por vários sistemas.
b ) Eliminação de inconsistências – Através
do armazenamento da informação em
um único local com acesso descentrali-
zado e, sendo compartilhada a vários sis-
temas, os usuários estarão utilizando
uma informação confiável. A inconsistên-
cia ocorre quando um mesmo campo
tem valores diferentes em sistemas dife-
rentes. Exemplo, o estado civil de uma
pessoa é solteiro em um sistema e ca-
sada em outro. Isto ocorre porque esta
pessoa atualizou o campo em um siste-
ma e não o atualizou em outro. Quando
o dado é armazenado em um único lo-
cal e compartilhado pelos sistemas, este
problema não ocorre.
c ) Compartilhamento dos dados – Permite
a utilização simultânea e segura de um
dado, por mais de uma aplicação ou
usuário, independente da operação que
esteja sendo realizada. Deve ser obser-
vado apenas o processo de atualização
concorrente, para não gerar erros de pro-
5

ARTIGO MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
P ARA UMA CONT ABILIDADE DE P
CONTABILIDADE
PARTIDA
cessamento (atualizar simultaneamente
o mesmo campo do mesmo registro).
Os aplicativos são por natureza multiu-
suário.
d ) Restrições de acesso – Define para cada
usuário o nível de acesso a ele concedi-
do (leitura, leitura e gravação ou sem
acesso) ao arquivo e/ou campo. Este
recurso impede que pessoas não autori-
zadas utilizem ou atualizem um determi-
nado arquivo ou campo.
e ) Padronização dos dados – Permite que
os campos armazenados na base de
dados sejam padronizados segundo um
determinado formato de armazenamen-
to (padronização de tabela, conteúdo de
campos, etc...) e ao nome de variáveis
segundo critérios e padrões preestabe-
lecidos pela empresa (ou analista cria-
dor do BD). Exemplo, para o campo
“Sexo” somente será permitido armaze-
namento dos conteúdos “M” ou “F”.
f ) Manutenção de integridade – Exige que
o conteúdo dos dados armazenados no
Banco de Dados possua valores coeren-
tes ao objetivo do campo, não permitin-
do que valores absurdos sejam cadas-
trados. Exemplo, um funcionário que faça
no mês 500 horas extras, ou um aluno
que tenha nascido no ano de 1860.
g ) Evitar necessidades conflitantes – Repre-
senta a capacidade que o administrador
de banco de Dados deve ter para soluci-
onar “prioridades sempre altas” de todos
os sistemas, tendo ele que avaliar a real
necessidade de cada sistema para a
empresa priorizar a sua implantação.
h ) Independência dos dados – Representa
a forma física de armazenamento dos
dados no Banco de Dados e a recupe-
ração das informações pelos programas
Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003
6
ADCONTAR
ARTIDA MÚLTIPLA
Dinaldo do N. Araújo
de aplicação. Esta recuperação deverá
ser totalmente independente da maneira
com que os dados estão fisicamente ar-
mazenados. Quando um programa reti-
ra ou inclui dados, o SGBD compacta-
os para que haja um menor consumo de
espaço no disco. Este conhecimento do
formato de armazenamento do campo é
totalmente transparente para o usuário.
A independência dos dados permite os
seguintes recursos:
• Os programas de aplicação definem os
campos que serão utilizados independen-
te da estrutura interna dos arquivos;
• Quando há inclusão de novos campos no
arquivo, será feita manutenção apenas nos
programas que utilizam esses campos,
não sendo necessário mexer nos demais
programas.
Obs: nos sistemas tradicionais este tipo de
operação requer a alteração no lay-out de
todos os programas do sistema que utilizam
o arquivo.
V - VISÕES DO BANCO DE
DADOS
Segundo LAUNDON & LAUNDON
(1999), o conceito de banco de dados dis-
tingue entre visões físicas e lógicas de da-
dos. Neste trabalho, acrescentamos alguns
outros detalhes e conceitos que os autores
chamam de visões física e lógica.
Visão Lógica ou Externa – É aquela
vista pelo usuário que opera os comandos
de manipulação e operação dos dados. Os
dados são apresentados como seriam per-
cebidos por usuários finais.
Visão Física – Mostra como os dados
ADCONTAR
ARTIGO
MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
P ARA UMA CONT ABILIDADE DE P
CONTABILIDADE ARTIDA MÚLTIPLA
PARTIDA

são de fato armazenados e estruturados no VI - COMPONENTES DE UM

meio de armazenamento físico. Em outras
palavras, é a visão dos analistas e adminis- SISTEMA GERENCIADOR
tradores do banco de dados. Podendo ain- DE BANCO DE DADOS -
da ser sub-classificada em: visão conceitu-
al e interna.
SGBD

• Visão conceitual – é aquela vista pelo Um SGBD é um sistema de propósito

analista de desenvolvimento e pelo admi-
nistrador das bases de dados. Existe a
preocupação na definição de normas e
procedimentos para manipulação dos da-
dos, para garantir a sua segurança e con-
fiabilidade. O desenvolvimento de siste-
mas e programas aplicativos possibilita a
definição no banco de dados de novos
arquivos e campos. Na visão conceitual
existem 2 (duas) linguagens de operação
que são:
geral que facilita o processo de definição,
construção e manipulação de banco de da-
dos voltados a diversas aplicações.
O SGBD permite que os dados sejam ar-
mazenados em um só lugar, disponível para
qualquer aplicação. Um sistema de gerenci-
amento de banco de dados tem três com-
ponentes: uma linguagem de definição de
dados, uma linguagem de manipulação de
dados e um dicionário de dados.

1 - Linguagem de definição dos dados (DDL) Linguagem de definição de dados

– Linguagem que define as aplicações, ar- (DDL) – Define cada elemento de dado
quivos e campos que irão compor o banco como ele aparece no banco de dados antes
de dados (comandos de criação e atualiza- de ser convertido para a forma requerida pe-
ção da estrutura dos campos dos arquivos). los diversos programas aplicativos. Usa-se
esta linguagem quando do desenvolvimen-
2 - Linguagem de manipulação dos dados to do banco de dados.
(DML) – Linguagem que define os coman-
dos de manipulação e operação dos da- Linguagem de manipulação de da-
dos (comandos de consulta e atualização dos (DML) – É a ferramenta que manipula
dos dados dos arquivos). os dados do Banco de Dados. É utilizada
em conjunto com algumas linguagens de
• Visão interna – É aquela vista pelo res- programação convencionais de terceira ou
ponsável pela manutenção e desenvolvi- quarta geração. Dispõe de recursos que tan-
mento do SGBD. Existe a preocupação com to especialistas como os usuários finais po-
a forma de recuperação e manipulação dos dem usar para extrair dados ou manipular da-
dados dentro do dos do Banco
Banco de Dados. de Dados. A
mais importan-
Desenvolvimento de
Segundo as ex- aplicações te linguagem
plicações acima,
ANALISTAS VISÃO
CONCEITUAL
utilizando recursos do
SGBD de manipula-
teríamos o seguin-
E
ADMINISTRADORE
VISÃO FÍSICA
VISÃO INTERNA
Desenvolvimento do SGBD
ção é a SQL
(Structured
ADMINISTRATORES
te quadro, para re-
S
VISÃO Utilização das
presentar tal abor- EXTERNA aplicações Query Langua-
USUÁRIO OU Desenvolvidas
dagem: LÓGICA ge), que é a lin-

Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003

7

ARTIGO MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
PARA UMA CONT ABILIDADE DE P
CONTABILIDADE ARTIDA MÚLTIPLA
PARTIDA
guagem de manipulação de dados de sis-
temas de gerenciamento de banco de da-
dos de mainframes como DB2 da IBM, com
versões de softwares para gerenciamento de
banco de dados de PC’s.
Dicionário de dados - É um arquivo au-
tomatizado que armazena definições de ele-
mentos de dados e outras características
como padrões de utilização, propriedade, re-
lacionamentos entre os elementos de dados
e a segurança. Funciona como um documen-
to de todo o banco de dados, possibilitan-
do futuras resoluções de problemas com re-
lação ao banco de dados.
Mundo Real = Estrutura Lógia de Dados = Estrutura Física de Dados
Projeto lógico de B.D.
DEPARTAMENTO
e FUNCIONÁRIO
VII - PROJETO LÓGICO DE
BANCO DE DADOS E
PROJETO FÍSICO DE
BANCO DE DADOS
O projeto de banco de dados pode ser
dividido em duas etapas: projeto lógico e
projeto físico de dados.
Segundo CHEN (1990), o projeto lógico
de banco de dados “é o processo de plane-
jar a estrutura lógica de dados para o banco
de dados”. Isto envolve uma análise do am-
biente de aplicação e dos tipos de estruturas
lógicas de dados disponíveis no sistema de
banco de dados. No momento do planeja-
mento e elaboração deste projeto lógico, o
Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003
8
ADCONTAR
Dinaldo do N. Araújo
projetista tem pouca ferramenta que o auxilie,
tendo que apelar para a sua experiência e in-
tuição (que falha), o que pode ser comprova-
do em muitos bancos de dados cujos proje-
tos lógicos são deficientes e mal projetados.
O projeto físico de banco de dados “é o
processo de selecionar uma estrutura física
de dados para uma dada estrutura lógica de
dados”. Isto é, traduzir ou tentar materializar
um projeto lógico em físico.
Seguindo o raciocínio de CHEN (1990),
adaptamos o seguinte gráfico onde tentamos
demonstrar o projeto lógico e o projeto físi-
co de dados:
Projeto físico de B.D.
DEPARTAMENTO
FUNCIONÁRIO A FUNCIONÁRIO B
VIII - MODELOS DE BANCO DE
DADOS
De acordo com LAUNDON & LAUNDON
(1999), existem três modelos de projeto de ló-
gico de banco de dados: o modelo hierárqui-
co, o modelo em rede e o modelo relacional.
Estes modelos são, na realidade, manei-
ras de como os dados são organizados em
um banco de dados e que dependem da na-
tureza de cada problema que se deseja so-
lucionar.
Modelo Hierárquico – O modelo de
Banco de Dados Hierárquico organiza os da-
dos de cima para baixo, como uma árvore,
e requer que os tipos de registros de dados
ADCONTAR MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
P ARA UMA CONT ABILIDADE DE P
CONTABILIDADE
sejam organizados em uma forma hierárqui-
ca. Um pai pode ter mais de um filho, mas
um filho só pode ter um pai.
Essa estrutura hierárquica funciona bem
com alguns bancos de dados, mas torna-
se difícil projetar banco de dados usando um
sistema hierárquico quando não existe uma
hierarquia natural entre os tipos de registro.
Exemplo
Exemplo: um departamento conectado
a diversos níveis inferiores (empregado) e
cada empregado conectado a outros seg-
mentos subordinados.
Observem a representação gráfica:
Representação gráfica
Departamento
Empregado
Desempenho Habilidade
Os SGBD’s hierárquicos são bastante
úteis para maciços processamentos, do tipo
reservas de passagens aéreas e transações
bancárias de caixas eletrônicos.
Modelo em Rede – O modelo de Ban-
co de Dados em Rede permite que um tipo
de registro tenha múltiplos tipos de regis-
tro como pais. Ou seja, um filho pode ter
mais de um pai. Estes tipos de sistemas
proporcionam capacidades mais comple-
xas de estruturas de dados do que os sis-
temas hierárquicos.
Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003
ARTIDA MÚLTIPLA
PARTIDA ARTIGO
Representação gráfica
Departamento
Empregado Habilidade
Empregado - Habilidade
Este modelo em rede, assim como o hi-
erárquico, não é de fácil adaptação a mu-
danças ou alterações de estruturas no Ban-
co de Dados.
Modelo Relacional – O modelo de Ban-
co de Dados Relacional é a mais recente es-
trutura de banco de dados. Representa to-
dos os dados do banco de dados em tabe-
las simples bidimensionais denominadas re-
lações. Sua criação se deu ao fato da limita-
ção dos dois outros modelos, apresentados
anteriormente. Assim, surgiu com a intenção
de superar as limitações dos antigos mode-
los. No modelo relacional, um elemento de
dado de um arquivo ou tabela pode ser rela-
cionado a qualquer fragmento de dado em
outro arquivo ou tabela desde que ambas
as tabelas compartilhem um elemento de
dado comum.
Exemplo: usando o mesmo exemplo anterior.
Tabela de Departamento
Nº Depart. Departamento
1 Administração
2 Produção
3 Estoque
N N
9
 ADCONTAR
ARTIGO MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
P ARA UMA CONT ABILIDADE DE P
CONTABILIDADE ARTIDA MÚLTIPLA
PARTIDA Dinaldo do N. Araújo

Tabela de Funcionário
IX - MODELO DE BANCO DE
Nº Func. Funcionário
1 Alberto DADOS RELACIONAL
2 João
3 Paulo
n N Método Entidade-Relacionamento (E-R)

O método Entidade-Relacionamento é
De acordo com a classificação mencio- um novo método para projeto lógico de
nada, teríamos o seguinte esquema: banco de dados. Surgiu na década de 70 a
partir de trabalhos inspirados
De acordo com a classificação mencionada, por Peter Chen e, desde então,
teríamos o seguinte esquema: tal teoria vem se difundindo e
Hierárquica
se desenvolvendo pelo mundo
afora. A idéia básica do méto-
Projeto lógico
de banco de dados Rede do E-R é acrescentar um está-
Pontos de gio intermediário ao projeto ló-
interesse
para a
gico de banco de dados.
empresa Relacional

Vejamos a figura a seguir:

Segundo CHEN (1990), os mé-

todos convencionais de projeto
Mundo Real = Esquema da Empresa lógico de banco de dados usual-
= Esquema do Usuário mente apresentam uma única
Hierárquica
fase: mapeamento de informa-
ções sobre objetos do mundo real
Rede diretamente em um esquema do
usuário. O método E-R para pro-
jeto lógico de banco de dados
Relacional
consiste em duas fases principais:

Ressaltamos que neste trabalho o mode-
lo que será alvo de estudo é o modelo re-
lacional
lacional, já é o mais moderno e possuir uma
melhor metodologia, o que o deixa em situ-
ação privilegiada sobre os demais, no de-
senvolvimento de projeto lógico de banco
de dados.
1) Definição do esquema da
empresa usando o diagrama de
Entidade-Relacionamento – nes-
ta fase o projetista primeiro identifica as en-
tidades e relacionamentos que são de inte-
resse para a empresa usando a técnica dia-
gramática Entidade-Relacionamento (E-R).
Isto é, o projetista deve examinar os dados
do ponto de vista da empresa como um
todo (e não restringir-se à visão do progra-
mador). Este esquema da empresa deve ser
uma tradução pura do mundo real e deve

Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003

10
ADCONTAR
MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
P ARA UMA CONT ABILIDADE DE P
CONTABILIDADE
PARTIDA
ser independente de considerações sobre
armazenamento e eficiência.
2) Tradução do esquema da empresa em um
esquema do usuário – o projetista nesta
fase tem a tarefa de traduzir o esquema
real para um esquema que possa ser com-
preensível para o usuário, entretanto, que
seja de forma lógica e válida para posteri-
or implementação.
Logo, podemos afirmar que o modelo E-
R consiste em mapear o mundo real do sis-
tema em um modelo gráfico que irá repre-
sentar o modelo e o relacionamento existen-
te entre os dados.
De acordo com CHEN (1990) o método
E-R apresenta as seguintes vantagens:
1 . A divisão da funcionalidade e trabalho em
duas fases torna o processo de projeto
de banco de dados mais simples e mais
bem organizado.
2. O esquema da empresa é mais fácil de ser
projetado do que o esquema do usuário,
uma vez que não precisa ser restrito pelas
características do sistema de banco de
dados e é independente de considerações
sobre armazenamento e eficiência.
3. O esquema da empresa é mais estável
do que o esquema do usuário. Se uma
pessoa quiser mudar de um sistema de
banco de dados para outro, provavel-
mente terá de alterar o esquema do usu-
ário, mas não necessariamente o esque-
ma da empresa, uma vez que este é in-
dependente dos sistemas de banco de
dados usados.
4. O esquema da empresa expresso pelo
diagrama de entidade-relacionamento é
mais facilmente compreendido por pes-
Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003
ARTIGO
ARTIDA MÚLTIPLA
soas não ligadas no processamento ele-
trônico de dados.
Componentes do Modelo Entidade-
Relacionamento
O modelo E-R é composto por: entida-
des, instância de entidade, atributos, domí-
nio do atributo e relacionamentos.
Entidade – Identifica o objeto de interesse do
sistema e tem “vida” própria, ou seja, a re-
presentação abstrata de um objeto do mun-
do real sobre o qual desejamos guardar in-
formações. Exemplo: clientes, fornecedores,
contas, lançamentos, funcionários, etc.
Não são entidades:
• entidade com apenas 1 elemento;
• operações do sistema;
• saídas do sistema;
• pessoas que realizam trabalhos (usuários
do sistema);
• cargos de direção.
Instância de entidade – São os ele-
mentos da entidade.
Exemplo
Exemplo: cliente 10, funcionário João,
Conta Caixa, etc..
Atributo – São informações que deseja-
mos guardar sobre a instância de entidade.
Os atributos podem ser atômicos e não atô-
micos. Os atômicos são características úni-
cas e exclusivas que somente um compo-
nente de uma dada entidade pode ter e os
não atômicos são características comuns,
que qualquer componente de uma entidade
pode ter.
Exemplo de atributo
atributo: nome do cliente,
número da nota fiscal, endereço do fornece-
dor, etc.
Exemplo de atributo atômico
atômico: matrí-
cula do aluno, código do cliente, código da
conta, etc.
Exemplo de atributo não atômico atômico:
11
 ADCONTAR
ARTIGO MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
P ARA UMA CONT ABILIDADE DE P
CONTABILIDADE ARTIDA MÚLTIPLA
PARTIDA Dinaldo do N. Araújo

nome do cliente, histórico do lançamento, Cardinalidade de Relacionamentos

nome da conta, etc.
Domínio do atributo – É o universo de
valores que um atributo pode armazenar.
Exemplo: conjunto de valores do atributo
Sexo do funcionário: M ou F;
conjunto de valores do atributo natu-
reza da conta: D ou C;
conjunto de valores do atributo nome
do cliente: 40 caracteres alfanumérico.
Relacionamento – Representa a asso-
ciação entre os elementos do conjunto de
uma entidade com outra entidade.
Exemplo
Exemplo: A loja Fura Bolo é cliente da em-
presa e está cadastrada no plano de contas.
A loja fura bolo – elemento do conjunto
de valores do atributo Nome do Cliente da
Representa a freqüência com que existe o
relacionamento entre os elementos que com-
põem as entidades que se relacionam. Temos
os seguintes tipos de relacionamentos:
a) Relacionamento 1:1 (um para um ): onde
se tem uma ocorrência para um lado e
uma ocorrência para o outro. Entenda-se:
“Um homem pode casar com mais de
uma mulher? Não, só pode casar com uma.
Uma mulher pode casar com mais de um
homem? Não, só pode casar com um homem”.
1 1
HOMEM CASAMENTO MULHER

entidade Cliente
Plano de contas – é uma entidade que
tem como um dos elementos o cliente Loja
Fura Bolo
Cadastrado – ligação existente entre um
cliente e o plano de contas
Representação Gráfica
Todos estes componentes do modelo E-
R, que ora abordamos, tem a sua própria re-
presentação gráfica, conforme abaixo:
b) Relacionamento 1:N ou N:1 (n para n):
onde para um lado temos uma ocorrência
e para o outro mais de uma ocorrência.
Exemplo: Um empregado pode estar lo-
tado em mais de um departamento? Não,
só em um departamento. Mas um departa-
mento pode lotar mais de um empregado?
Sim, N empregados
N 1
EMPREGADOS LOTAÇÃO DEPARTAMENTO

- Representação gráfica da ENTIDADE

- Representação gráfica do RELACIONAMENTO

- Representação gráfica do ATRIBUTO ATÔMICO

- Representação gráfica do ATRIBUTO NÃO ATÔMICO

Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003

12
ADCONTAR
MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
P ARA UMA CONT
CONTABILIDADE
PARTIDA
ABILIDADE DE P
c) Relacionamento N:M (n para m): onde
para um lado temos várias ocorrências e
para outro, também, várias ocorrências.
Exemplo: Um aluno pode estar matricu-
lado em mais de uma disciplina? Sim, M dis-
ciplinas. E em uma disciplina pode estar ma-
triculado mais de um aluno? Sim, N alunos.
ALUNOS MATRÍCULA DISCIPLINA
Notem que estes tipos de relacionamen-
tos levam em consideração a regra geral do
mundo real, as exceções devem ficar de fora.
Por exemplo, no caso do homem e mulher:
se por acaso o homem tiver mais de uma
mulher, é uma exceção, visto que, a regra
geral que vale para nós é o casamento com
apenas uma mulher.
Normalização de Dados
Consiste em definir o formato lógico ade-
quado para as estruturas de dados identifi-
cados no projeto lógico do sistema, com o
objetivo de minimizar o espaço utilizado pe-
los dados e garantir a integridade e confia-
bilidade das informações.
A normalização é feita, através da análise
dos dados que compõem as estruturas utili-
zando o conceito chamado “Formas Normais
(FN)”. As FN são conjuntos de restrições nas
quais os dados devem satisfazê-las.
Exemplo: pode-se dizer que a estrutura
está na primeira forma normal (1FN), se os
dados que a compõem satisfazem as restri-
ções definidas para esta etapa.
A normalização completa dos dados é
feita seguindo as restrições das três formas
normais existentes, sendo que a passagem
Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003
ARTIGO
ARTIDA MÚLTIPLA
de uma FN para outra é feita tendo como
base o resultado obtido na etapa anterior, ou
seja, na FN anterior.
Para realizar a normalização dos dados,
é primordial que seja definido um campo cha-
ve para a estrutura, campo este que permite
identificar os demais campos da estrutura.
As formas normais são:
1) Primeira Forma Normal (1FN) –
Consiste em retirar da estrutura os elemen-
tos repetitivos, ou seja, aqueles dados que
podem compor uma estrutura de vetor. Po-
demos afirmar que uma estrutura está nor-
malizada na 1FN se não possuir elementos
repetitivos.
Exemplo:
a) Estrutura original:
Arquivo de Notas Fiscais: número da NF,
Série, data emissão, código do cliente, nome
do cliente, endereço do cliente, CNPJ do cli-
ente, relação das mercadorias vendidas
(onde para cada mercadoria temos um có-
digo, descrição da mercadoria, quantidade
vendida, preço unitário, total de venda de
mercadoria).
Analisando este arquivo acima, observa-
mos que existem várias mercadorias em
uma única Nota Fiscal, sendo portanto ele-
mentos repetitivos que deverão ser retirados.
b) Estrutura na 1FN:
Arquivo de Notas Fiscais: número da NF,
série, data emissão, código do cliente, nome
do cliente, endereço do cliente, CNPJ do cli-
ente e total geral da Nota.
Arquivo de vendas: Número da NF, códi-
go da mercadoria, descrição da mercado-
ria, quantidade vendida, preço de venda uni-
tário e total da venda desta mercadoria.
> Como resultado desta etapa, ocorre um
desdobramento dos dados em duas estru-
turas, a saber:
13

ARTIGO MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
P ARA UMA CONT ABILIDADE DE P
CONTABILIDADE
PARTIDA
- Primeira estrutura (Arquivo de Notas Fis-
cais): dados que compõem a estrutura ori-
ginal, excluindo os elementos repetitivos.
- Segunda estrutura (Arquivo de vendas):
dados que compõem os elementos repetiti-
vos da estrutura original, tendo como chave
o campo chave da estrutura original (núme-
ro da NF) e o campo chave da estrutura de
repetição (código da mercadoria).
2) Segunda Forma Normal (2FN) -
consiste em retirar das estruturas que pos-
suem chaves compostas(campo chave sen-
do formado por mais de um campo), os ele-
mentos que são funcionalmente dependen-
te de parte da chave. Podemos afirmar que
uma estrutura está na 2FN, se ela estiver na
1FN e não possuir campos que são funcio-
nalmente dependentes de parte da chave.
Exemplo:
a) Estrutura na 1FN:
Arquivo de Notas FiscaisFiscais: número da
NF, série, data emissão, cód. do cliente,
nome do cliente, endereço do cliente, CNPJ
do cliente e total geral da Nota.
Arquivo de Vendas
Vendas: número da NF, có-
digo da mercadoria, descrição da mercado-
ria, quantidade vendida, preço de venda uni-
tário e total da venda desta mercadoria.
b) Estrutura na 2FN:
Arquivo de Notas FiscaisFiscais: número da
NF, série, data emissão, código do cliente,
nome do cliente, endereço do cliente, CNPJ
do cliente e total geral da Nota.
Arquivo de Vendas
Vendas: número da NF, có-
digo da mercadoria, quantidade vendida e
total da venda desta mercadoria.
Arquivo de Mercadorias
Mercadorias: código da
mercadoria, descrição da mercadoria, pre-
ço de venda unitário.
Como resultado desta etapa, houve um des-
dobramento do arquivo de Vendas (o arquivo
de notas fiscais não foi alterado por não possuir
chave composta) em duas estruturas a saber:
Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003
14
ADCONTAR
ARTIDA MÚLTIPLA
Dinaldo do N. Araújo
- Primeira estrutura (Arquivo de Vendas):
contém os elementos originais, sendo exclu-
ídos os dados que são dependentes ape-
nas do campo código da mercadoria.
- Segunda estrutura (Arquivo de Mercadori-
as): contém os elementos que são identifica-
dos apenas pelo código da mercadoria, ou seja,
independentemente da Nota Fiscal, a descrição
e o preço de venda serão constantes.
3) Terceira Forma Normal (3FN) – con-
siste em retirar das estruturas os campos que
são funcionalmente dependentes de outros
campos que não são chaves. Podemos afir-
mar que uma estrutura está na 3FN se ela
estiver na 2FN e não possuir campos depen-
dentes de outros campos não chaves.
Exemplo:
a) Estrutura na 2FN:
Arquivo de Notas Fiscais: número da NF,
série, data emissão, cód. do cliente, nome
do cliente, endereço do cliente, CNPJ do cli-
ente e total geral da Nota.
Arquivo de Vendas: número da NF, códi-
go da mercadoria, quantidade vendida e to-
tal da venda desta mercadoria.
Arquivo de Mercadorias: código da mer-
cadoria, descrição da mercadoria, preço de
venda unitário.
b) Estrutura na 3FN:
Arquivo de Notas Fiscais: número da NF,
série, data emissão, código do cliente e to-
tal geral da nota.
Arquivo de Mercadorias: código da mer-
cadoria, descrição da mercadoria, preço de
venda unitário.
Arquivo de Clientes: código do cliente,
nome do cliente, endereço do cliente e CNPJ
do cliente.
Como resultado desta etapa, houve um
desdobramento do arquivo de Notas Fiscais
por ser o único que possuía campos que não
eram dependentes da chave principal (núme-
ro da NF), uma vez que independente da
Nota Fiscal, o Nome, endereço e CNPJ do
ADCONTAR
MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
P ARA UMA CONT
CONTABILIDADE
PARTIDA
ABILIDADE DE P
cliente são inalterados. Este procedimento
permite evitar inconsistência nos dados dos
arquivos e economizar espaço por eliminar
o armazenamento freqüente e repetidas ve-
zes destes dados. A cada nota fiscal com-
prada pelo cliente haverá o armazenamento
destes dados e poderá ocorrer divergência
entre eles.
As estruturas alteradas foram pelos moti-
vos, a saber:
- Primeira estrutura (Arquivo de Notas Fis-
cais): contém os elementos originais, sen-
do excluídos os dados que são dependen-
tes apenas do campo código do cliente (in-
formações referentes ao cliente)
- Segunda estrutura (Arquivo de Clientes):
contém os elementos que são identificados
apenas pelo código do cliente, ou seja, in-
dependente da Nota fiscal, o nome, endere-
ço e CNPJ dos clientes serão constantes.
Após a normalização, as estruturas dos
dados estão projetadas para eliminar as in-
consistências e redundâncias dos dados, eli-
minando desta forma qualquer problema de
atualização e operacionalização do sistema.
A versão final dos dados poderá sofrer algu-
ma alteração, para atender as necessidades
específicas do sistema, a critério do analista
de desenvolvimento durante o projeto físico
do sistema.
X - MODELO LÓGICO DE BAN-
CO DE DADOS PROPOSTO
PARA UMA CONT ABILIDA-
CONTABILIDA-
DE DE P ARTIDA MÚLTIPLA
PARTIDA
Como mencionamos na introdução des-
te trabalho, esta é uma proposta de um mo-
delo lógico de banco de dados relacional,
que possa ajudar no desenvolvimento de um
Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003
ARTIGO
ARTIDA MÚLTIPLA
sistema contábil de partidas múltiplas, usan-
do o modelo E-R como metodologia deste
projeto.
Partidas Múltiplas
Conforme o capítulo 5 da obra The Foun-
dations of Accounting Measurement – A Ma-
thmatical, Economic and Behavioral Inquiry,
de YUJI IJIRI (1967), que menciona que des-
de a exposição do trabalho de Luca Pacioli
do método das partidas dobradas em 1494
até os dias atuais, assim podemos dizer, mui-
tos dizem que este é um sistema perfeito;
assim como um teorema, que nada pode ser
feito para melhorar e que acaba sendo con-
siderado um sistema absoluto. Entretanto,
IJIRI (1967) neste trabalho, demonstra que a
teoria contábil tem como evoluir e expandir
o conceito que está por trás do sistema das
partidas dobradas, no que se refere à parte
matemática, filosófica e comportamental que
alicerçam o sistema de partida dobrada.
No mesmo trabalho, o autor faz referên-
cia à existência de duas possíveis visões
para o sistema de partida dobrada: a classi-
ficatória e a causal.
Partida dobrada classificatória – trata de
cada aumento ou redução do valor do Ativo
independente. A dualidade vem do aumento
ou redução das duas diferentes classifica-
ções (Ativo e Passivo). É um mecanismo de
dupla classificação.
Partida causal – trata do aumento e redu-
ção como tendo um relacionamento de cau-
sa e efeito, e a dualidade vem da paridade
do aumento com a redução.
Feita esta abordagem de que o sistema
de partida dobrada tem estas duas manei-
ras de ser visualizado e entendido, o autor
ainda demonstra através de um pequeno
15
 ADCONTAR
ARTIGO MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
P ARA UMA CONT ABILIDADE DE P
CONTABILIDADE ARTIDA MÚLTIPLA
PARTIDA Dinaldo do N. Araújo

exemplo de como expandir a classificação b) Um grupo de contas pode estar cadas-

de Ativos pelas suas localizações e tempo
ou prazo de utilização. Esta evolução por
parte de IJIRI é o que ele chama de Partida
Múltipla. Em outras palavras, trata-se de uma
contabilidade que vai além do débito e do
crédito, do Ativo e do Passivo, onde pode-
mos registrar, por exemplo a localização dos
Ativos e o seu prazo de realização.
E nossa proposta neste trabalho é justamen-
te a de implementar ou projetar um projeto
lógico de banco de dados, baseado no
exemplo de IJIRI (1967), onde possamos ter
como resultado uma contabilidade de parti-
da múltipla.
a) Diagrama do Modelo Entidade-Re-
lacionamento:
1 N
NATUREZA Ter
GRUPO DE
CONTAS
1
trado mais de uma vez no plano de contas?
Sim, N vezes.
Uma conta do plano de contas pode ca-
dastrar mais de um grupo de contas? Não,
somente uma vez.
c) Uma conta do plano de contas pode ter
mais de uma localização? Não, somente
uma.
Uma localização pode estar cadastrada
em mais de uma conta? Sim, em N contas.
d) Uma conta do plano de contas pode ter
mais de um prazo? Não, somente um.
Um prazo pode estar cadastrado em mais
de uma conta do
plano de contas?
Sim, N contas.

Cadastrar
e) Uma conta pode
ser lançada mais de
N uma vez? Sim, N
1 N N
PLANO DE
1
vezes.
PRAZO Cadastrar Cadastrar LOCALIZAÇÃO
CONTAS

1 Um lançamento
Lançar
pode ter mais de
N N 1
uma conta? Não,
somente uma con-
LANÇAMENTO Lançar HISTÓRICO
ta.

Baseado em um Diagrama do Modelo Observamos que dependendo do siste-

Entidade-Relacionamento, podemos enume-
rar algumas conclusões acerca dessa abor-
dagem, analisando os relacionamentos:
a) Um grupo de contas pode ter mais de
uma natureza? Não, só uma.
ma desenvolvido, no lançamento podemos
ter mais de uma conta, entretanto, para efei-
to de facilitar o projeto lógico, consideramos
que os lançamentos devam ser realizados
um a um (individualmente).

Uma natureza pode estar em mais de um f) Um lançamento pode ter mais de um

grupo de contas? Sim, N grupos de conta. histórico padrão? Não, somente um.

Adcontar, Belém, v.4, n.2, p.27-42, nov. 2003

16
ADCONTAR
ARTIGO
MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
PARA UMA CONT
CONTABILIDADE ARTIDA MÚLTIPLA
PARTIDA
ABILIDADE DE P

Um histórico padrão pode ser lançado

em mais de um lançamento? Sim, N lança- Tabela PRAZO:
mentos. * CódigoPrazo
Prazo
b) Diagrama de estruturas:

Este diagrama demonstra o mecanismo de Tabela LOCALIZAÇÃO:

funcionamento do Banco de Dados, isto é,
* CódigoLocalização
de onde vem os dados e para onde estão
apontando (destino). Localização

GRUPO DE
NATUREZA
CONTAS
Tabela PLANO DE CONTAS:
* CódigoReduzido
PRAZO
PLANO DE
CONTAS
LOCALIZAÇÃO CódigoContábil
NomeConta
SaldoInicial
LANÇAMENTO HISTÓRICO CódigoGrupo
CódigoPrazo
CódigoLocalização

c) Tabela de dados:

Aqui devem estar previstos os dados e

sua respectiva natureza da informação, com Tabela LANÇAMENTOS:
a atribuição de um código específico. É a * CódigoLançamento
matriz onde constarão todos os tipos de da- Data
dos que serão inseridos no modelo lógico CódigoReduzido
de partidas múltiplas, com sua respectiva ValoraDébito
identificação. Exemplo:
ValoraCrédito
CódigoHistórico
Tabela NATUREZA:
Complemento
* CódigoNatureza
Natureza

Tabela HISTÓRICO:
Tabela GRUPO DE CONTAS:
* CódigoHistórico
* CódigoGrupo
Histórico
Grupo
CódigoNatureza

Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003

17
 ADCONTAR
ARTIGO MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
P ARA UMA CONT ABILIDADE DE P
CONTABILIDADE ARTIDA MÚLTIPLA
PARTIDA Dinaldo do N. Araújo

d ) Resultado que expressa uma relação de causa e efei-

Após a implementação do projeto lógico,
num sistema de Gerenciamento de Banco
de Dados, é possível vislumbrar, além de
ganho operacional, uma integração com o
sistema das partidas dobradas.
to, isto é, mostra o processo de transfe-
rência de valores entre os diversos ciclos
operacionais da empresa, permitindo que
se possa ter uma visão dinâmica das
operações executadas e não somente
“estática” como comentam vários críticos
do processo contábil”, o que é bastante
perceptível no modelo tradicional de lan-
çamentos (partidas dobradas).

ATIVO P ASSIVO LOCALIZAÇÃO PRAZO

Caixa $10 Duplic. A Pagar $20 Escritório Central $30 menos 6 meses $40

Duplic. A Receber $20 Juros a Pagar $ 1 0 Fábrica $40 menos 1 ano $10

Estoques $20 Empréstimos $40 Armazém $30 menos 2 anos $10

Imóveis $40 Capital $30 mais 2 anos $40

Equipamentos $10

Total $100 Total $100 Total $100 Total $100

O presente projeto lógico foi implemen-
tado usando a ferramenta ACCESS 2000
(Microsoft), utilizando os mesmos núme-
ros do exemplo de Ijiri, onde obtemos
como resultado de um determinado rela-
tório o mesmo quadro apresentado acima.
É possível perceber pelo exemplo que
mesmo buscando um sistema contábil de
partidas múltiplas, é necessário o uso das
partidas dobradas.
Como menciona RICCIO (1989), apoia-
do pelas palavras de Ijiri, a lógica contida
no método das partidas dobradas empres-
ta ao novo sistema características únicas
e destaca a seguinte:
“permite a criação de um registro padrão
Portanto, acreditamos que talvez este
ainda não seja o projeto lógico de banco
de dados ideal para uma contabilidade de
partidas múltiplas, mas se torna um início
e ao mesmo tempo um avanço da área
contábil aliada com a tecnologia de ban-
co de dados.
CONCLUSÃO
Cremos que ficou clara a importância
dos conceitos de Banco de Dados para o
momento que então vivemos, a era da in-
formação. E dentre os conceitos aborda-
dos, o que obteve maior relevância para
este trabalho fora o projeto lógico de ban-
co de dados, que aliado com a metodolo-

Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003

18
ADCONTAR
ARTIGO
MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
PARA UMA CONT
CONTABILIDADE ARTIDA MÚLTIPLA
PARTIDA
ABILIDADE DE P

gia ou o modelo Entidade-Relacionamen- Outro ponto forte deste trabalho, são as

to de banco de dados, acabam sendo,
sem dúvida alguma, importantes ferramen-
tas quando bem definidos e projetados
para o desenvolvimento de qualquer sis-
tema, incluindo o estudado neste ensaio
(um sistema contábil de partidas múltiplas).
Salientamos, por fim, que quando um
projeto lógico é bem definido e projetado,
certamente evita-se desperdícios de tem-
po, de custo e de futuras mudanças nos
sistemas, independente das ferramentas
de implementação usadas, como softwa-
res e hardwares.
idéias de Ijiri (1967) no que se refere a es-
tudar as partidas dobradas sob ângulos di-
ferentes, o que é também defendido e afir-
mado em Riccio (1989), dizendo que a
contabilidade deve sair do que é, da sua
concepção estática para ser uma contabi-
lidade dinâmica e, assim, mais útil e valo-
rizada. Portanto, acreditamos que a pre-
sente proposta de trabalho para a criação
e uso de um modelo lógico de banco de
dados para uma contabilidade dinâmica,
sem dúvida, contribuirá para futuras incur-
sões nesta área, tanto contábil como tec-
nológica.

Adcontar, Belém, v.4, n.2, p.27-44, nov. 2003

19
 ADCONTAR
ARTIGO MODELO LÓGICO DE BANCO DE DADOS PROPOSTO
PARA UMA CONT ABILIDADE DE P
CONTABILIDADE ARTIDA MÚLTIPLA
PARTIDA Dinaldo do N. Araújo

BIBLIOGRAFIA

CHEN, Peter. A abordagem entidade-relacionamento
para projeto lógico. Tradução: Cecília Camargo. São
Paulo: Makron Books, 1990
IJIRI, Yuji. The Foundations of Accounting Measure-
ment – A Mathmatical, economic and Behavioral In-
quiry. New jersey. Prentice Hall, 1967, Págs. 101 a 165.
OLIVEIRA, Adelize Generini. Visual Basic 5 – Manipulan-
do Banco de Dados. Santa Catarina: Visual Books, 1997.
RICCIO, Edson Luiz. Efeitos da tecnologia de informa-
ção na contabilidade – Estudo de casos de implemen-
tação de sistemas empresariais integrados – ERP. Tese
de livre docência, FEA/USP, 2001.

LAUDON, Keneth. LAUDON, Jane. Sistemas de infor- RICCIO, Edson Luiz. Uma contribuição ao estudo da
mação – com internet. Tradução: Dalton Conde de contabilidade como sistema de informação. Tese de
Alencar. 4º ed. Rio de Janeiro: LTC, 1999. doutorado. FEA/USP, 1989, Pág. 2 a 70.

Adcontar, Belém, v.4, n.2, p.27-42, nov. 2003

20