Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aperi-dev] R3 Reporting data model design


Hey Prasenjit,

One of the things I expected to see was some new tables for mapping internal values to displayable strings. It looks like by the names of the views some of these might be such tables, but I am not sure.
Currently, Aperi does a lot of that in Java code (the infamous Constants.java).
Those mappings need to be in the schema to make them accessible to the third party report tools.
I thought at first these might represent a translation problem (that is, a we would need a part of the schema to be localizable), but they are proper names of things and so they probably don't need to be translated. They aren't globalized in the Java code anyway. They are just constant strings.

Dave Wolfe/Portland/IBM (dwolfe@xxxxxxxxxx) TL: 775-3376 Office: 503-578-3376 Personal: 503-329-3960

GUI Technical Lead, Aperi Open Source Storage Management http://www.eclipse.org/aperi http://www.ibm.com

If all of your problems look like nails you should invest in a good hammer - Unknown


Prasenjit Sarkar <psarkar@xxxxxxxxxxxxxxx>
Sent by: aperi-dev-bounces@xxxxxxxxxxx

01/07/2007 02:59 PM

Please respond to
Aperi Development <aperi-dev@xxxxxxxxxxx>

To
Aperi Development <aperi-dev@xxxxxxxxxxx>
cc
Subject
[aperi-dev] R3 Reporting data model design






This mail contains the approach for the data Model for report generation.
Comments are always welcome.

The goal is to generate a list of well-defined views on top of the Aperi
schema so that a report generator tool (such as BIRT) can use the views to
compose reports. An alternative would be to provide a set of canned reports
to the report generation tool, however in retrospect it was decided that
providing the building blocks for reports is better than trying to
anticipate an administrator's needs.

The list of views will be separate from the schema and will be maintained
in a different location. This is because the report generation tool is an
optional entity to the schema. However, the views will be synchronized with
respect to the schema, so that if the underlying schema changes, the views
will be mofidied internally to adjust to the schema changes. External
changes to the views will be discouraged to a large extent.

One corollary to the design is that exposing the views to the outside world
means that the report generation tool will have access to the database
schema. This is somewhat in contravention to the regular Aperi design which
disallows direct database access. To prevent consistency and deadlock
issues, we will allow only read access to the list of views to a specific
user id.

Another issue is the versioning of the views. There are two options here.
The first is to use the schema versioning used in Aperi. The second is to
synchronize the view definitions to the version of Aperi i.e. for Aperi v1
there will be ModelView v1, and so on. Either approach can be used in this
case.

Below is an list of proposed view definitions and sizings based on elements
of the Aperi schema. For R3, we will focus on the Data and Disk functions,
with the rest to follow later. We expect the report generation tool to
provide a couple of canned reports based on the views just as examples for
report developers, that sizing has not been factored in.


Table Function    PD (Person-days)
T_UPGRADE_LOG     Internal    1
T_IDENTIFIER      Internal    1
T_GROUP     Internal    1
T_RES_COMPUTER    Data  1
T_RES_SERVER      Suite 1
T_RES_AGENT       Data  1
T_CONFIG_SETTINGS       Internal    1)
T_ALERT_LOG       Internal    1
T_ALERT_DEFINITION      Internal    1
T_ALERT_EMAIL     Internal    1
T_RES_ATTRIBUTE   Internal    1
T_SCHEDULE        Internal    1
T_RUNS      Internal    1
T_RUN_JOBS  Internal    1
T_USER_PREFERENCES      Internal    1
T_STORM_SETTINGS        Internal    1
T_RES_CONTROLLER        Data  1
T_RES_DEV_ACCESS        Data  1
T_RES_DEVICE      Data  1
T_STAT_DISK       Data  1
T_STAT_DISK_HIST        Data  1
T_RES_LOGICAL_DISK      Data  1
T_RES_CHUNK_CLLCTN      Data  1
T_RES_CHUNK       Data  1
T_RES_SHARE       Data  1
T_RES_EXPORT      Data  1
T_RES_FILESYSTEM        Data  1
T_RES_DOMAIN      Data  1
T_STAT_COMPUTER         Data  1
T_STAT_PING_HIST        Data  1
T_STAT_SPACE_HIST       Data  1
T_STAT_FS_HIST    Data  1
T_REPORT_PREFS    Internal    1
T_FOUND_COMPUTER  Data  1
T_AGGREGATOR      Internal    1
T_SAVED_REPORT    Internal    1
T_BATCH_REPORT    Internal    1
T_RES_LDAP_TREE   Data  1
T_SCRIPT    Internal    1
T_RES_PWD   Internal    1
T_SNMP_COMMUNITY        Internal    1
T_FOUND_FILESYSTEM      Data  1
T_RES_DISK_ARRAY        Data  1
T_RES_CIMOM       Internal    1
T_RES_VOLGROUP    Data  1
T_GROUP2RES       Internal    1
T_CHART_SETTINGS        Internal    1
T_RES_LUN_WWN     Suite 1
T_RES_ENTITY_WWPN       Suite 1
T_RES_STOR_EXTENT       Data  1
T_RES_EXT_CTRLR   Data  1
T_RES_HOST        Suite 1
T_RES_SWITCH      Fabric      1
T_RES_HBA   Fabric      1
T_RES_NODE        Fabric      1
T_RES_FABRIC      Fabric      1
T_RES_ZONE  Fabric      1
T_RES_ZONE_MEMBER       Fabric      1
T_RES_ZSET        Fabric      1
T_RES_PHY_PE      Fabric      1
T_RES_TOKEN       Fabric      1
T_RES_ALIAS       Fabric      1
T_RES_STORAGE_SUBSYSTEM       Disk  1
T_RES_STORAGE_VOLUME    Disk  1
T_RES_IO_GROUP    Disk  1
T_RES_STORAGE_POOL      Disk  1
T_RES_DISK_GROUP        Disk  1
T_RES_STORAGE_EXTENT    Disk  1
T_RES_PHYSICALVOLUME2EXTENT         Disk  1
T_RES_PORT        Fabric      1
T_RES_DATA_PATH   Disk  1
T_RES_PHYSICAL_PACKAGE        Disk  1
T_RES_LPAR        Disk  1
T_RES_AUTH_ROLES        Internal    1
T_RES_REGISTERED_CIMOM        Internal    1
T_RES_SLP_ATTRIBUTES    Internal    1
T_RES_PORT2PORT   Fabric      1
T_RES_FABRIC2SWITCH     Fabric      1
T_RES_ZONE2MEMBER       Fabric      1
T_RES_ZSET2ZONE   Fabric      1
T_RES_SWITCH2PORT       Fabric      1
T_RES_PE2NODE     Fabric      1
T_RES_ZONE2ALIAS        Fabric      1
T_RES_ALIAS2MEMBER      Fabric      1
T_RES_CIMOM2NAMESPACE   Internal    1
T_RES_PHYSICAL_VOLUME   Disk  1
T_RES_SNMP_TRAP   Internal    1
T_RES_SNMP_TRAP_OID     Internal    1
T_RES_IP_TARGET   Fabric      1
T_RES_SCANNER     Fabric      1
T_RES_CIMKEY_HOST       Fabric      1
T_RES_CIMKEY_SWITCH     Fabric      1
T_RES_CIMKEY_SUBSYSTEM  Disk  1
T_RES_CIMKEY_TAPE_LIBRARY     Tape  1
T_RES_CIMKEY_PORT       Fabric      1
T_RES_CIMKEY_VOLUME     Disk  1
T_RES_NAMES_SUBSYSTEM   Internal    1
T_RES_SYSTEM_NAMES      Internal    1
T_RES_VENDOR      Internal    1
T_RES_MODEL       Internal    1
T_RES_CREATION_CLASS_NAME     Internal    1
T_RES_TAPE_LIBRARY      Tape  1
T_RES_TAPE_FRAME        Tape  1
T_RES_TAPE_DRIVE        Tape  1
T_RES_TAPE_IOPORT       Tape  1
T_RES_TAPE_MEDIA_CHANGER      Tape  1
T_RES_TAPE_CARTRIDGE    Tape  1
T_RES_TAPE_MEDIA_LOCATION     Tape  1
T_RES_REDUNDANCY        Disk  1
T_RES_CONFIG_DATA       Internal    1
T_RES_OUTBAND_AGENT     Fabric      1
T_RES_DEVICE_AGENT      Fabric      1
T_RES_SWITCH_BLADE      Fabric      1
T_RES_SWITCH_BLADE_TYPE       Fabric      1
T_RES_USER_ATTRIBUTES   Internal    1
T_RES_CAPABILITY_DATA   Internal    1
T_RES_MASKING_INFO      Disk  1
T_RES_BACKEND_CONTROLLER      Disk  1
T_RES_ELEMENT_PROBE_STATUS    Internal    1
T_RES_SCANTYPE2TABLE    Internal    1
T_RES_RCSEV2DEVICE      Internal    1
T_STAT_TOTALS     Data  1
T_RES_CLUSTER     Data  1


Prasenjit Sarkar
Almaden Research

_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev


Back to the top