• Reply to: SEQUEL Integration

    RODIN and Sequel are complementary products. You will not replace Sequel with RODIN - you will use them both together.

    Query and reporting tools such as Sequel are primarily designed to 'present' data as information, in the form of reports, charts, dashboards and the like. In simple implementations, this can be achieved by pointing the tool (Sequel) against operational data. However, for organizations, with more complex environments, this can be very challenging. Data is stored in many places - in different application databases, text files, spreadsheets XML documents and more. It is also stored in different formats in each of these places. For example the same inventory item may be in 3 or 4 (or even more) different tables, identified by different part numbers etc. Trying to tie all of this information together is a challenge, and one that most reporting tools are not designed to handle. This is where RODIN comes in. RODIN is not the presentation layer. It is the back-end piece that brings all of these disparate data sources together, sorts, organizes, standardizes, transforms, cleanses and stores it in data warehouse and data mart tables, that are then readily accessed by Sequel (or other front end tool).

    There's lots of detailed information on this site that explains how RODIN does all of this.. and more.

    Originally Posted By AJ

  • Reply to: Real-time load of data warehouse

    Hi Nathan

    The short answer is - no problem! RODIN easily handles real-time updates to any number of detail or summary tables. We don't need to roll-up or otherwise rebuild the summaries.

    Hope that helps!


    Originally Posted By AJ

  • Reply to: Real-time load of data warehouse

    Hey Nathan,

    Just to add to the previous response:

    1) Real-Time load requires the operational tables to be journaled, and RODIN change data capture active. You probably already are aware of that but just wanted to ensure you had the complete picture.

    2) You can even push any data captured in real time out to tables on another platform (Oracle, SQL Server etc), also in real-time. B)


    Originally Posted By AJ

  • Reply to: ETL Errors

    Hi DK,

    I think this page should answer your question:

    If you have any further questions, please don't hesitate to ask!

    Originally Posted By AJ

  • Reply to: Data Modeling

    Hi Siddhu,

    With RODIN you can build your data warehouse and data marts to ANY design. Unlike some other tools we don't force you into any one concept or architecture. For example, some tools only build star schemas.

    You design the database and RODIN implements it. Whether you want to use Ralph Kimball's Dimensional modeling concepts or Bill Inmon's Corporate Information factory model is your choice. Or build something entirely different!

    Hope that answers your question.

    Originally Posted By AJ

  • Reply to: Unstructured Data

    Hi Christine

    This is very easy to do in RODIN.

    The challenge with text files is of course that there is no 'column' information in the file. So RODIN provides wizards to allow you to easily describe the data. For delimited files it is fairly easy as the delimiters identify the columns. RODIN inspects the data and makes a guess at the data type and other attributes. You can then edit this if necessary. If there is a header row that can be used to name the columns.

    Fixed length text files are a little more work in that you need to place markers over the data to define the columns. Again RODIN guesses at the data type. See the screenshots below and you'll get the idea.

    Once described the text file can be accessed in and ETL process just as if it was a real table as the RODIN metadata now holds the column details.
    Excel files are just as easy. In this case you can select the spreadsheet columns to be pulled, and even use SQL to select the rows to be processed.
    The above process are a once only set-up step for each new source of data.

    The RODIN ETL process allows you to manipulate and merge this text or Excel data with any other data as needed and load it into RODIN tables. Data from these RODIN tables can then be exported to text files (fixed or delimited) or an Excel spreadsheet at the click of a button - or you can automate this to happen every day after all ETL process have completed.

    I hope that answers your question. Let us know if you want to set up a demonstration to see how easy it is.

    Originally Posted By AJ

  • Reply to: Change data capture

    Hi Jessica,

    One Change Data Capture job (we call it a CDC server) can capture changes for up to 300 tables associated with the same journal. If you have different journals, or more than 300 tables to process, you will define as many CDC servers as you need. In fact you can have several servers processing the same journal. This is a good solution for a high volume environment when you have a multi-processor LPAR.

    We can Apply the captured data at an EXACT position in a journal. We do this by sending a user defined journal entry to the journal (using a supplied command that you can embed in your nightly job at the required point. Then, when the CDC Server processes that user defined journal entry (which may be within micro-seconds, or maybe a few seconds or minutes later) , an Apply is triggered, which takes all of the captured data and moves it to the Apply tables - becoming today's batch of data. Hopefully that answers your questions, but if you need more information just let me know.

    Originally Posted By AJ

  • Reply to: How does RODIN support slowly changing dimensions?

    Hi Romano,

    Good question. RODIN handles type 2 SCD easily and mostly automatically. When you define the data warehouse table (called a data set in RODIN), you specify that it uses a surrogate key (which is necessary for SCD support), and that it tracks type 2 SCD.

    In any SCD implementation, you need certain columns to be included in the table:

    An Effective-To date is mandatory. This is used to set the range of dates for which the row is active.
    Some data modelers also include an Effective-From date, however this is not necessary, so is optional in RODIN
    Similarly you may wish to include a Current Row Flag, but again this is not necessary.
    Another requirement is an index over the table that includes the original key(s) of the data and the effective to date.
    Finally, you must of course identify those columns that are to be tracked as type 2 SCD.
    RODIN ensures that you define all of the mandatory elements when defining the data set.

    Then when you add this data set to an ETL definition, RODIN automatically generates all of the code and mappings needed to identify if one of the the type 2 SCD columns have changed when loading an existing entity, and if so, a new row is inserted using a new surrogate key. The old 'current row' is updated setting the effective to date to today, which effectively 'closes' it out.

    I hope that answers your question. Thanks for looking at RODIN!

    PS. Keep an eye on the web site.. we're planning to post a video demonstration of our SCD support soon.

    Originally Posted By AJ

  • That syntax for the IN

    "That syntax for the IN function can be used if the view is changed to Datebase *LOCALSYS with Syntax *SERVER - Then native DB2 SQL can be used.

    The same results can be achieved using database *SEQUEL with this expression:

    CAT(wewhse,wecode) IN(('03100'),('70330'))

    Or this for numeric fields :

    CAT(digits(wewhse),digits(wecode)) IN(('03100'),('70330'))"

    Originally Posted By Danc

  • This works in Excel

    DSN=fsd400;UID=user;password=pas;SYSTEM=FSD400;DBQ=QGPL rmsfiles# swiall swiallwf;DFTPKGLIB=QGPL;LANGUAGEID=ENU;PKG=QGPL/DEFAULT(IBM),2,0,1,0,512;QRYSTGLMT=-1; Thought it might be helpful

    Originally Posted By jpyatt