Has a beginner I want to understand why there are two data types defined on a column : SQL data type and data element.
The product documentation nor help is not any good in describing the sql data type any better than repeating its name. Help says that data element usage is optional but enables stricter data typing in the design!...then whats are advantages and possible disadvantages ?
here is the context for my questions: in my first server job (from ch 2 of DS designer guide) migrating a universe table to a seq file a date field is converted to a month tag; I forgot to assign a date data element to an input column of sql type Date. Then Month.tag(dslink1.date) was giving me a date in format yyy-mm-dd instead of a month tag. I thought that SQL type date was enough for DS to use month.tag; on top of that the compiler does not complain and execution seems to go well. is the transform funtion missing any input check ? it certainly does not provide a month tag in that context.
what are best practice regarding data element usage and is it broadly followed by DS community ? I read a post from 2001 archived data saying data elements are not very used (as people feels no benefits I guess!) May be time has passed and things changes a little bit ?
please help me to understand all this
column data typing
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Data Elements are like "luggage tags" for data. They are meaningful only within DataStage.
For example, you have a ten digit number, defined with an SQL data type of Char(10). You have lots of these; they are different things. Some are telephone numbers, some are product codes, some are barcodes, and so on.
You can create Data Elements called "TelephoneNumber", "ProductCode" and "BarCode" (and "Revenue" and "Money" and so on), and tie these to the data within Columns grids. This gives four advantages.
For example, you have a ten digit number, defined with an SQL data type of Char(10). You have lots of these; they are different things. Some are telephone numbers, some are product codes, some are barcodes, and so on.
You can create Data Elements called "TelephoneNumber", "ProductCode" and "BarCode" (and "Revenue" and "Money" and so on), and tie these to the data within Columns grids. This gives four advantages.
- Usage Analysis will show where all ProductCodes appear in the project.
Some automatic conversions (for example dates in ODBC stage) will occur so that you don't have to code them.
If choosing DSTransforms in expression editor, intially only the Transforms that generate that data element are displayed; so the developer can more rapidly choose the correct one.
The Data Element definition allows you to have a place to document business rules associated with the specific data element. For example, while an Indian telephone number is always ten digits, the area code may be from two to five digits, the remainder being the line number, unless the first digit is 9, in which case the next four digits are the carrier and the remainder the instrument number. Where else (within DataStage) would it make sense to store this business metadata?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
In a word, laziness.
People know it's not essential for operation of DataStage, so don't bother. In many places the same problem exists for documentation; people realise that it's not necessary for operation of DataStage so they don't bother with that either.
It's a sad indictment on the way the world is.
People know it's not essential for operation of DataStage, so don't bother. In many places the same problem exists for documentation; people realise that it's not necessary for operation of DataStage so they don't bother with that either.
It's a sad indictment on the way the world is.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
If you're grouping a column in the Pivot stage and that column contains unique values then, just like in SQL, there's nothing to group.
Can you post a specific example?
Can you post a specific example?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact: