• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (1)

1 David Birmingham commented Permalink

This approach handles the majority of needs if the Netezza machine is nothing more than a load-and-query server. It does not address the data processing requirements of the back-end and the need for varying levels of access by those very aggressive processes.

For this the data processing user is divided into two users, each with distinct roles. One is the application admin and one is the application data processing. We could call these appadm and appetl
The appadm has the abiliity to create databases and tables, and generally administer the application.. For the master databases (e.g. the integration hub and reporting mart schemas) only the appadm has the ability to build tables.
The appetl user has the ability to build tables in the staging and transformation schemas, but nowhere else. This allows the appetl user to manufacture intermediate tables during the data processing cycle, and to be sure that these are not manufactured in the final target database. If any tables are manufactured in the final target, what happens if the job should fail and leave these tables behind? It creates a mess. It's better to manufacture the data in another (staging or transform) database and then copy the results to the target. Moreover, the data processing user will not be allowed to drop or modity tables in the targets, even if accidentally.
This appoach necessarily causes the data processing chain to require a "commit" or "finalize" protocol such that the data has to be deliberately added to the target rather than just trickled-in. This is a more proactive data management protocol that actively supports advanced processes like rollback and replication.
This database configuration protcol is discussed in detail in Netezza Underground 2nd Edition

Add a Comment Add a Comment