Os 12 mandamentos da certificação CMM
Computerworld
Somente fazendo perguntas duras o CIO poderá distinguir entre as empresas que estão exagerando as qualidades provenientes de seu CMM e aquelas comprometidas com melhorias reais.

Saiba o que deve ser questionado para certificar-se da seriedade do fornecedor de serviços de desenvolvimento de software:

1-) Quem foi o certificador? É importante saber quem examinou a fornecedora de TI para conferir um CMM. Por exemplo, se o examinador nunca avaliou uma empresa CMM nível 5 antes, ele provavelmente não estará bem qualificado para saber exatamente como uma companhia CMM nível 5 deve proceder.

2-) Que parte da empresa foi testada? Fornecedoras de TI que se apresentam como "uma empresa com CMM" pode ter apenas 10% - ou até menos - de seus projetos analisados para ganhar a certificação.

3-) Há quanto tempo isso foi feito? Se a certificação tiver mais de dois anos, há boas chances de que a empresa tenha mudado - para melhor ou para pior - e portanto o significado da certificação é relativo. Muitas vezes a fábrica de software cresceu muitas vezes em relação ao período quando foi analisada.

4-) Quanto tempo a empresa demorou para mudar de nível? Se a companhia levou menos de dois anos para sair do nível 1 para o 4, ou menos de um ano entre o nível 4 e 5, ela está fora da média e merece uma investigação mais detalhada para entender como isso foi conseguido.

5-) Onde está a evidência de melhoria contínua? CMM nível 5 implica em melhoria contínua ¿ faça o fornecedor mostrar todo o seu histórico de evolução na qualidade de produção.

6-) Quem é responsável pelo grupo de qualidade? Peça para se reunir com quem monitora e audita o processo. Deve haver mais do que um punhado de pessoas e elas devem ter o poder dentro da empresa para mudar as coisas. Elas devem se reportar diretamente ao CEO e a empresa deve ligar o sistema de qualidade a compensações e prestações de conta no nível executivo.

7-) O avaliador foi de dentro ou de fora da organização? Examinadores internos não podem ser tão objetivos quanto avaliadores externos sem ligações com a empresa.

8-) Onde estão os relatórios? Peça documentos formais que o avaliador de CMM deve prover para a companhia, sobretudo o "Final Findings Report" (considerações finais), que aborda os pontos fracos e fortes da companhia. Se a empresa se recusar a mostrar os documentos, desista de fechar contrato com ela.

9-) Que tipo de projetos foram avaliados? Por exemplo, se a sua empresa atua na área de serviços financeiros, é importante certificar-se de que pelo menos um dos projetos avaliados está relacionado com processos financeiros.

10-) O examinador prestou consultoria para a empresa que avaliou? O examinador deve ser independente e objetivo. Se ele ajudou a empresa a desenvolver o processo que agora ele está avaliando, existe um claro conflito de interesse.

Leia mais na Computerworld
30/04/2004


Posted by Felipe Machado em Sábado, Maio 08, 2004

Comentários:

Oracle Design (1)

O caso da unicidade seletiva

O Oracle é um grande banco de dados não só pela sua robustez e escalabilidade mas também pelos recursos de projeto físico que oferece.
Vejamos, por exemplo, o caso de certa aplicação que tudo o que precisava era de um repositório de dados para guardar os grupos e as tarefas associadas a cada grupo, bem como o status de cada projeto.
Após algum tempo de estudo das regras de negócio, o projetista de banco de dados propôs a seguinte tabela:

SQL> create table PROJECT

  2  (PROJECT_ID number primary key,

  3  TEAMID number,

  4  JOB varchar2(100),

  5  STATUS varchar2(20) check (status in ('ACTIVE', 'INACTIVE')));

A proposta cobria praticamente todas as regras de negócio, a saber:
- em um dado projeto há apenas um time trabalhando em um determinado job;
- um time pode trabalhar em diferentes projetos e jobs ao mesmo tempo
- projetos estao necessariamente em um de dois status: ativos or inativos
Porém , o que esta proposta ainda carecia é atender a uma outra regra de negócio:
- o job tem que ser único dentro do mesmo time para projetos ativos.

Em outras palavras: TEAMID e JOB tem que ser unique key quando STATUS=ACTIVE.

Como implementar esta regra de negócio?

Bem, para ser justo é preciso dizer que certamente a regra de negócio poderia ser implementada na aplicação. Mas, neste caso, toda e qualquer aplicação teria que construir a mesma implementação de novo.
Isto não é raro de acontecer.
Casualmente, no momento em que escrevo este artigo trabalho em um projeto onde o mesmo banco de dados Oracle é acessado por aplicações Java, ASP e Oracle Forms!
Focando então no banco de dados de novo, temos a seguintes alternativas:

Database triggers

Database triggers são recursos disponíveis em Oracle desde há muito tempo.
São ferramentas absolutamente úteis, desde que o projetista atente ao potencial problema de performance e ao infame problema das "mutating tables".
O potencial problema de performance advém do fato de que Oracle triggers não são compilados. Isto significa, em especial, que todo e qualquer acesso ao banco de dados efetuado por um database trigger passa pela fase de "hard parse".
Dependendo dos requisitos de performance e escalabilidade da aplicação, isto pode ser um real fator inibidor de uso do recurso. Uma conhecida técnica para driblar este problema de performance é criar uma stored procedure com o código que se deseja rodar e colocar no corpo do trigger apenas a chamada à stored procedure.
Como stored procedures são compiladas, a escalabilidade deste design é muito superior.
O problema de "mutanting table" é um velho conhecido de que tem alguma experiência com Oracle.
Basicamente, se uma tabela está no meio de uma transação, não é possível codificar um database trigger que lê a mesma tabela durante a transação.
Existem recursos de código para driblar esta restrição mas, francamente, são bastante deselegantes e adicionam indesejada complexibilidade à manutenção da aplicação.
Outra desvantagem deste design é que requer a construção de código para todas as operações DML (insert, delete, update).

Instead-of triggers

Apesar de que atualmente em IT basta existir para se ser declarado velho, este é um recurso relativamente novo em Oracle. Trata-se de uma ferramenta que permite ao projetista de banco de dados desenhar um mecanismo para capturar uma solicitação de um comando DML efetuada pela aplicação e definir que ações vão realmente acontecer no banco de dados.
Quando combinado com views é definitivamente um recurso que se deseja prestar atenção.

Por exemplo, no caso deste artigo, o seguinte design poderia ser implementado:

- uma view - PROJECT_VIEW - é criada com base na table PROJECT

SQL> create view project_view as select * from project;   

- um ou mais instead-of triggers são associados à view.
Estes triggers capturam os comandos DML.
No caso de um insert, o trigger primeiro acessa a tabela PROJECT para verificar se o time já está associado ao job em um outro projeto ativo. Se não é o caso, então o trigger dispara um DML de insert na tabela PROJECT.

Um exemplo de como este trigger poderia ser criado é fornecido abaixo:

create or replace trigger team_job_uniqueness

instead of insert on PROJECT_VIEW

for each row

declare

  v_count number;

begin

  if (:new.status = 'ACTIVE') then

    begin    

      select count(*)

      into v_count

      from project

      where teamid = :new.teamid

      and job = :new.job

      and status = 'ACTIVE';

      if (v_count > 0) then

        raise_application_error(-20001, 'Bla, bla, ......');

      end if;

    exception

      when others then

        raise_application_error(-20002, 'Bla, bla, ......');  

    end;

  end if;

  begin

    insert into project(project_id, teamid, job, status) values (:new.project_id, :new.teamid, :new.job, :new.status);

  exception

    when others then

        raise_application_error(-20003, 'Problemas para criar novo PROJETO');  

  end;

end;    

- à aplicação são dados privilégios de acesso à view PROJECT_VIEW mas não à tabela PROJECT.
Este design evita o enervante problema das "mutanting tables" de uma maneira mais elegante mas ainda assim é bastante verborrágica, cheia de código para se manter.

Function-based indexes (FBIs)

A vida devia ser simples e fácil. É por isto que Oracle implementou - desde a versão 8i (8.1) - a noção de índices com base em expressões/funções criadas pelo projetista/desenvolvedor.

FBIs permitem, por exemplo, a criação de índices como o apresentado abaixo:

SQL> CREATE UNIQUE INDEX

  2  JOB_UNIQUE_IN_TEAMID ON PROJECT

  3  (CASE WHEN STATUS = 'ACTIVE' THEN TEAMID ELSE NULL END,

  4  CASE WHEN STATUS = 'ACTIVE' THEN JOB ELSE NULL END); 

O resultado da existência de um índice assim criado em nosso estudo de caso é que
- apenas para projetos ativos serão criadas entradas no índice
- o fato de que o índice é UNIQUE garante que um time jamais trabalhará em um mesmo job ao mesmo tempo (para projetos ativos).
É simples de implementar e de manter, tem mínimo impacto em aplicações OLTP, é enxuto (pois existirão entradas neste índice apenas projetos ativos), é furiosamente rápido para recuperar a informação, não requer extra select para garantir a regra de negócio e é um mecanismo mantido e gerenciado pelo núcleo do banco de dados (já ví calejados projetistas de banco de dados chorando ao serem apresentados à esta técnica de design).

Conclusão

Não há nenhuma grande novidade a se descobrir aqui. O que vale é a velha regra de que para criar o projeto físico de um banco de dados a melhor opção é conhecer os recursos existente no banco de dados em questão. Eles variam imensamente de um BD para outro e entre versões de um mesmo bd.
Claro que se portabilidade de BD é um requisito importante esta conclusão deve ser repensada.
Agora... quantas vêzes realmente isto acontece?
Já perdi o número de vezes em que ví projeto de desenvolvimento de aplicações VB em Windows se recusando a usar recursos específicos de Oracle devido a uma portabilidade que ninguém pediu. VB é proprietário, Windows é proprietário mas... o BD tinha que ser portável...

---

Este artigo é uma extensão do um estudo de caso apresentado por Thomas Kyte em seu excelente livro "Effective Oracle by Design". São mais de 600 páginas de valiosos conselhos mas o capítulo Effective Schema Design por si só já vale o investimento

By Roque Luis Daudt from Canadá




Posted by Felipe Machado em Sexta-feira, Maio 07, 2004

Comentários:

IBM introduces WebSphere Business Integration Server Express
Posted May 5, 12:00 p.m. Pacific Time

IBM on Wednesday put another piece of its integration strategy in place for SMBs (small and midsize businesses), unveiling a new WebSphere-based server that helps users better integrate both business processes and people.
>> READ MORE




Posted by Felipe Machado em Quinta-feira, Maio 06, 2004

Comentários:

Cleaning of data -the part of ETL that nobody speaks

On the process of ETL we found a lot of tools today for the automation of the process
The concepts of ETL are extremely diffused in the virtual and technical community

However, information is only presented on what it is the process, its technical means, its execution alternatives and its final result.
The relative difficulties to the quality of the data, are always superficially treated.

I remind when for the first time I worked with processes of BI, to have to attend a presentation on a software for cleaning of data (very expensive in the date), but that served to wake up my concern with this subject.
The composition of the process of ETL is composed for: Identification of the sources of data, Cleaning of the Data, Validation of the data, Extraction and Transformation and Load of the Data.

What does come to be indeed Cleaning of the Data?

For the understanding of this stage it is necessary that examples of situations of data are analyzed in an origin any.

For the understanding of this stage it is necessary that situations of data are analyzed in an example:

It is necessary, for example, to extract data of an application of revenue. In the system origin of the data, customers' registrations exist with code (CGC) duplicated (primary keys don't exist in the tables). Therefore we have the same customer in more than a registration

Several invoices exist for the same customer, even so with different codes in these invoices.

Is it possible to solve this problem with cleaning of the data?

The answer is yes, even so the work of cleaning will must accomplished manually, through programming language. Several stages will be executed until a final result, that has an only registration for each customer and whole each customer's invoices pointing logically for this only registration of each one.

Now imagine the work of elaboration of the necessary queries to build for the obtaining of this result.
This intelligence is not in the tools of ETL. You can write the subjects in the tool, even so the creation is dependent of the knowledge of the structures of data and of the programming language.
To hinder more this process, the documents for payment of the value of the invoices for the customer also suffer of the same problem. Therefore we will also have of also accomplishing this process of cleaning in these documents.

The question now is: Which are the other objects related with customer's code?

If we don't analyze the system source of the data correctly, we can have to accomplish excessive works and with multiple executions, because it is impossible to accomplish the cleaning of the original data, without to accomplish together with the relationships between the data and dependences among them.

This is a constant flaw of projects of new softwares that you need to migrate of databases.

Many projects of new softwares fail in the hour of its operation for not existing a process previous of cleaning of data. Only when already this in operation is that these problems are detected. It is already late to begin and the chaos begins.

We will come back shortly to present in this blog several situations of cleaning of data, from the traditional unification of customers' registration, addresses, names, as well as duplications and registrations wandered in the most varied types of objects of a database.


Posted by Felipe Machado em Quinta-feira, Maio 06, 2004

Comentários:

A Importância da Estruturação da Gestão de Metadados

Em um projeto de Data Warehouse, o processo de Gestão de metadados deve gerar e gerenciar uma documentação sobre o levantamento de dados, do banco de dados, relatórios a serem gerados, origem dos dados que alimentam o Data Warehouse, processos de extração, tratamento e rotinas de carga dos dados e as regras de negócios da empresa e todas as suas mudanças.
Os metadados podem surgir de vários locais no decorrer do projeto. Desde o material originado das entrevistas com os usuários até a documentação dos sistemas operacionais.
Os metadados permitirão ao usuário transformar os dados "crus", em informações que gerem conhecimento e tragam vantagem competitiva.

O coração da arquitetura do ambiente de BI (Business Intelligence) é o Data Warehouse, e no seu centro nervoso está o Metadado. Sem Metadados, o Data Warehouse e seus componentes nesta arquitetura, são meramente componentes deslocados, trabalhando independentemente e com metas diferentes.
Para alcançar harmonia e unidade entre os diferentes componentes no ambiente de Data Warehouse, é necessário ter uma bem definida e disciplinada integração com metadados.



Para iniciar o gerenciamento de metadados é necessário primeiramente delimitar o escopo de atuação. É muito difícil decidir quais metadados devem ser coletados e mantidos. Uma arquitetura de informação deve ser flexível para permitir um acréscimo ou decréscimo na quantidade de metadados à medida que novas necessidades vão surgindo.

Dentre as tarefas para criar um ambiente de gestão de metadados, podemos considerar:
Definir requisitos para metadados que devem estar disponíveis para os usuários de DW;
------- Desenvolver a arquitetura de gestão dos metadados do DW;
------- Selecionar que ferramentas deveriam ser incorporadas na infra-estrutura de gestão de Metadados;
------- Desenvolver programas que integram e customizam as ferramentas selecionadas para atender as necessidades de gestão de metadados específicos da organização;
------- Desenvolver e executar um programa de treinamento para os usuários de metadados do DW.

Metadados são considerados o DNA do Data Warehouse e por esta razão, o processo de Gestão de Metadados é de vital importância para a saúde de qualquer projeto de Data Warehouse.




Posted by Felipe Machado em Quarta-feira, Maio 05, 2004

Comentários:

Uma boa oportunidade de estar com BILL INMON

Data Warehouse e Fábrica de Informações Corporativas

Entrada Franca em palestra que será realizada com TRADUÇÃO SIMULTÂNEA

Informações: SUCESU-ES, fone: (27) 3225-9955 E-mail: adm@sucesues.org.br
Local: Auditório da Rede Gazeta, situado à Rua Chafic Murad, 902 - Bento Ferreira -
Vitória - ES. Data: 18/05/2004 Horário: De 19:00 às 21:00h


Posted by Felipe Machado em Quarta-feira, Maio 05, 2004

Comentários:

Eventos em maio

SEMINÁRIO BUSINESS INTELLIGENCE e DATA WAREHOUSE

Troca de informações sobre os mais recentes estudos e desenvolvimentos ligados ao aprimoramento do uso das tecnologias da informação.



Macro-temas do evento:

- Soluções de Business Intelligence apresentadas através de cases - pelo próprio usuário e não pela empresa que detém a comercialização da solução.
- Modelagem de DW , Datamarts e ODS
- Processos de integração de dados
- Metadados e administração de ambiente de DW/BI
- Tendências e soluções em BI, metodologia e cases de sucesso em: CPM, BPM, BAM, BSC SAP SEM e outras...

Local:
Centro de Convenções SUCESU-SP / Rua Tabapuã, 627, auditório térreo / Itaim Bibi - São Paulo -SP
Data:
19 de maio das 9:00 às 16:00



Posted by Felipe Machado em Quarta-feira, Maio 05, 2004

Comentários:

Novas versões do Tomcat

O Projeto Jakarta disponibilizou para downloads as novas versões do Tomcat 3.3.2 Release Candidate 1, Tomcat 5.0.19 Stable e Tomcat 4.1.30 Stable released.

A principal diferença entre as versões são as especificações Servlet e JSP suportadas :
Servlet/JSP Spec -- Tomcat version
2.4/2.0 -- 5.0.x
2.3/1.2 -- 4.1.x
2.2/1.1 -- 3.3.x

Maiores informações e downloads podem ser encontrados em http://jakarta.apache.org/tomcat/

Posted by Felipe Machado em Quarta-feira, Maio 05, 2004

Comentários:

WebSphere tools upgraded to ease Java development

MAY 03, 2004 (COMPUTERWORLD) -

IBM today planned to announce an upgrade to its WebSphere Studio tools line that's intended to ease development in a Java environment.
The primary addition to WebSphere Studio Version 5.1.2 is support for the recently finalized JavaServer Faces standard, which simplifies the building of rich user interfaces.
WebSphere Studio also supports an early version of Service Data Objects (SDO), which provides a unified programming model for accessing data from heterogeneous systems, including XML-based data sources and Web services. SDO has yet to be finalized by the Java Community Process established by Sun Microsystems Inc. to evolve Java technology.
more >>

Posted by Felipe Machado em Quarta-feira, Maio 05, 2004

Comentários:

Sasser infections hit Amex, others (Infoworld)
Security experts maintain a yellow alert on Tuesday


Posted by Felipe Machado em Terça-feira, Maio 04, 2004

Comentários:

Especial Exportação de Software: o Brasil mostra sua cara (computerworld - 4 de Maio de 2004)



Posted by Felipe Machado em Terça-feira, Maio 04, 2004

Comentários:

Plain English About Information Quality

The 7 Habits of Highly Effective Information Professionals
Column published in DM Review Magazine, May 2004 Issue , By Larry English

Habit 2: Begin with the End in Mind

This is the fourth in a series of columns on Stephen Covey's The 7 Habits of Highly Effective People. Here we describe the second habit, "Begin with the End in Mind," and what that means for information professionals.

Lewis Carroll's marvelous story, Alice in Wonderland, contains an insightful truth in Alice's dialog with the Cheshire Cat. It goes like this:

"Would you tell me, please, which way I ought to walk from here?" asked Alice.
"That depends a good deal on where you want to get to," said the Cat.
"I don't much care where," said Alice.
"Then it doesn't matter which way you walk," said the Cat.1

The lesson here is that if we do not have a clear vision of the outcomes we desire from an information project or initiative, we may wander aimlessly. Project plans may be filled with activities that take our time, but do not produce results. We may toil forever, without ever accomplishing our mission.

"Begin with the End in Mind," is a required habit for information professionals to be able to visualize the end result for information excellence.

I cannot write a more poignant introduction to this subject than Covey:

"In your mind's eye, see yourself going to the funeral of a loved one. Picture yourself driving to the funeral parlor or chapel, parking the car, and getting out. As you walk inside the building, you notice the flowers, the soft organ music. You see the faces of friends and family you pass along the way. You feel the shared sorrow of losing, the joy of having known, that radiates from the hearts of the people there.

"As you walk down to the front of the room and look inside the casket, you suddenly come face to face with yourself. This is your funeral, three years from today. All these people have come to honor you, to express feelings of love and appreciation for your life.

"As you take a seat and wait for the services to begin, you look at the program in your hand. There are to be four speakers. The first is from your family, immediate and also extended - children, brothers, sisters, nephews, nieces, aunts, uncles, cousins, and grandparents who have come from all over the country to attend. The second speaker is one of your friends, someone who can give a sense of what you were as a person. The third speaker is from your work or profession. And the fourth is from your church or some community organization where you've been involved in service.

"Now think deeply. What would you like each of these speakers to say about you and your life? What kind of husband, wife, father, or mother would you like their words to reflect? What kind of son or daughter or cousin? What kind of friend? What kind of working associate?

"What character would you like them to have seen in you? What contributions, what achievements would you want them to remember? Look carefully at the people around you. What difference would you like to have made in their lives?"2
Covey's Habit 2 Equals Deming's Quality Point 1
The personal habit of beginning with the end in mind is reflected in W. Edwards Deming's Point 1, "Create constancy of purpose for improvement of product and service."3 The enterprise has two sets of problems, those of today and those of tomorrow. "It is easy to stay bound up in the tangled knot of the problems of today, becoming ever more and more efficient in them."4

To solve the problems of tomorrow, we must have a plan and a vision for the future. It is this plan that represents the survival and "thrival" of the enterprise. Deming was clear that any plan for the future must be driven by the needs of the customer. This obligation of constant improvement of product and service is an obligation to the customer that never ceases. "The consumer is the most important part of the production line."5

As information professionals, our "plans" for the future must understand and meet our information customers' needs. The obligation to the knowledge-worker never ceases. We must be able to visualize what that world looks like when we "perfectly" meet those needs and delight our customers.

Information Quality Journey
Every one of us - whether professional or manager, whether a custodian who keeps the enterprise clean or a CEO who charts the enterprise course - has customers. Beginning with the end in mind is a habit based on principles of personal leadership. Leadership is about doing the right things. Peter Drucker, the great management guru, equates this to effectiveness. "Efficiency is concerned with doing things right. Effectiveness is doing the right things."6

Is your personal and professional journey filled with instances of "doing the right things"? Filling our journeys with these instances requires us to have a clear vision of what we need to accomplish. Before we develop that project plan, we must visualize the end state. What will it look like when we achieve Stage 5, Maturity in Information Quality? What will it look like when we have our information assets managed as rigorously as banks manage their customers' deposits?

"End-in-Mind" Vision
Where do we start? First, forget for the moment the perceived barriers and obstacles that beset your efforts to create change in your organization. These we will overcome using the remaining habits. For now, open your minds to the "impossible."

Joel Barker, the futurist, challenges his clients with the question, "What today is impossible to do in your business, but if it could be done would fundamentally change what you do?"7 Here is my challenge to you: What is it you (and your knowledge-workers) don't know today, but if you did know, would fundamentally change what you do? In scenario analysis, this is visualizing the best-case scenario. What does it look like? What does it feel like? Play with this question. Ask it on a regular basis. And put it on paper.

Now, think about what the outcomes can be when you accomplish your vision. What accolades will you receive from family, colleagues, management and customers as you accomplish it? What will be the cost savings from eliminated waste? What increased internal and external customer satisfaction will be achieved? What sense of personal victory will you derive as you make the impossible the reality?

What is your vision of the outcomes you want to see as a result of your information initiatives? What will your customers and stakeholders say about what you helped or led them to accomplish in information quality or information management?


Larry P. English is president and principal of INFORMATION IMPACT International, Inc., Brentwood, Tennessee.

Posted by Felipe Machado em Segunda-feira, Maio 03, 2004

Comentários:

History tables and event logging

(published in Database Journal by Philipp K. Janert, Software Project Consultant, IEEE.org April 27, 2004 )

Besides holding the data that is necessary to support the primary business purpose of the system under construction, the DB is also a possible location to record information that is useful primarily for internal technical purposes, such as adminstration and maintenance of the system itself.

History tables
In a production system, you may desire to preserve the history of changes to the data in the live database. This can be achieved through the use of history (or backup) tables, and the appropriate INSERT, DELETE, and UPDATE triggers.

Each table in the DB should have a history table, mirroring the entire history of the primary table. If entries in the primary table are to be updated, the old contents of the record are first copied to the history table before the update is made. In the same way, deleted records in the primary table are copied to the history table before being deleted from the primary one. The history tables always have the name of the corresponding primary one, but with _Hist appended.

Entries to the history table are always appended at the end. The history table, therefore, grows strictly monotonically in time. It will become necessary to periodically spool ancient records to tape for archiving. Such records may, as a result, not be immediately available for recall.

The attributes of the history table should agree exactly with the attributes of the primary table. In addition, the history table records the date and type of the change to the primary table. The type is one of the following: Create, Update, or Delete.

Changes to the structure of the primary table affect the history table. When an attribute is added to the primary table, it is added to the history table as well. When an attribute is deleted from the primary table, the corresponding attribute is not deleted from the history table. Instead, this field is left blank (NULL) in all future records. Consequentially, the history table not only grows in length over time, but also in width.

Note that the choice to use such a history mechanism affects neither the overall DB layout, nor applications that access only the primary tables. During development, you can probably dispense with recording changes in this way and leave the creation of the history tables and the necessary triggers until installation time.

Event logging for fun and profit
A database can be used as an event logger. The notion of event is broad, ranging from common debugging and system specific runtime information, to events which are specific to the business domain. Possible candidates for events to be logged to the database include:

Transactions making changes to persistent data
Transactions crossing component boundaries
Errors and exceptions
Dispatching of messages to the user
Events involving financial transactions
State changes to business entities
An EventLog table to log such information contains at least these fields to record:

Timestamp
EventType (a type code)
Details (a descriptive string)
Optionally, it may identify an owner or originator of the event. The owner concept can either identify a logged-in user or admin, but it may as well describe a part or module of the system itself. In applications dealing with financial transactions, additional (optional) fields identifying the from- and to-accounts can be useful.

System config tables
Finally, it is possible to use the database as centralized storage for configurational data. Usually this information is kept distributed in miscellaneous plain-text files, such as start-up scripts or property files. The database can provide a single, managed storage facility for such information.

Besides start-up parameters, which are usually supplied to the system at boot-time, one may also think of properties that are required at runtime, such as localized strings and messages.

Lastly, the database is a possible place to keep system documentation. This is most useful, of course, for information that is naturally in tabular form (rather than free text), such as lists of assigned port numbers or shared memory keys, for instance. But this approach is not limited to codes. A data dictionary, defining the permissible values for each field, is a necessity on any non-trivial project. This also can be made accessible to all developers and administrators by storing it in the database.

In any case, the data is stored in simple key/value pairs. Additional table attributes can contain comments or pointers (URLs) to relevant offline documentation.

The primary advantage to keeping such information in the database is that the database provides a central repository for all relevant information, as opposed to the typical approach in which data is scattered over miscellaneous files.




Posted by Felipe Machado em Segunda-feira, Maio 03, 2004

Comentários: