Just in case this is useful for someone:
The Star Schema was not generated because there was a size problem with the name of one of the tables it was trying to create. I.e., There was a 'Ñ' as part of the name, and that caused it to be longer thatn the 30 characters limit.
Thanks!

Similar Messages

Toplink JPA schema generation problem in Glassfish

I have problem getting Toplink to generate a proper mysql schema when run in Glassfish and using a mysql connection pool + jdbc datasource versus standalone toplink essentials and hardcoded jdbc url + user + password in the persistence.xml.
It looks like it doesn't generate Mysql specific schemas but is reverting to some sort of general SQL schema. Toplink does recognize the database as a mysql database according to the log (by printing out platform=>MySQL4Platform).
in an @Entity i have a field of type String[], in the standalone version it is mapped to a BLOB, probably using serialization or something. However if I use the exact same @Entity class in glassfish, it is mapped to a VARCHAR(255).
I have a similar problem using a @Lob String, in the standalone version it is mapped to MEDIUMTEXT, but in the glassfish version it is mapped to TEXT
In the log during deploy the database is recognized as a MySQL4Platform
JDBC Driver version: mysql-connector-java-5.0.5
Mysql version: MySQL Version: 5.0.37-log
Glassfish is the bundled glassfish from Netbeans 5.5.1
Has anybody seen this before?

Seems like your database platform is incorrect. Are you setting the platform in your persistence.xml? I'm not sure how you were getting MEDIUMTEXT, none of the TopLink platforms use this type, did you create your own database platform class?

Using two facts of two different star schemas and conformed dimensions

Hi,
I've been working as developer and database designer for years and I'm new to Business Objects. Some people says you can not use two facts of two different star schemas in the same query because of conformed dimensions and loop problems in BO.
For example I have a CUSTOMER_SALE_fACT table containing customer_id and date_id as FK, and some other business metrics about sales. And there is another fact table CUSTOMER_CAMPAIGN_FACT which also contains customer_id and date_id as FK, and some other business metrics about customer campaigns. SO I have two stars like below:
DIM_TIME -- SALE_FACT -- DIM_CUSTOMER
DIM_TIME -- CAMPAIGN_FACT -- DIM_CUSTOMER
Business metrics are loaded into fact tables and facts can be used together along conformed dimensions . This is one of the fundamentals of the dimensional modeling. Is it really impossible to use SALE_FACT and CAMPAIGN_FACT together? If the answer is No, what is the solution?
Saying "you cannot do that because of loops" is very interesting.
Thank you..

When you join two facts together with a common dimension you have created what is called a "chasm trap" which leads to invalid results because of the way SQL is processed. The query rows are first retrieved and then aggregated. Since sales fact and campaign fact have no direct relationship, the rows coming from either side can end up as a product join.
Suppose a customer has 3 sales fact rows and 2 campaign fact rows. The result set will have six rows before any aggregation is performed. That would mean that sales measures are doubled and campaign measures are tripled.
You can report on them together, using multiple SQL passes, but you can't query them together. Does that distinction make sense?

Trouble with star schema

Hi All,
I have a star schema in place with 8 dimension and 1 fact table.
But due to some specific requirement, I need to denormalize the schema. I want to copy all fields from all dimension tables to the fact table.
I know this sounds bad but I have to do it. pls dont ask why..
Now, the same can be done using a materialized view but the problem in MV is there are fields which are present in 2 or more table with the same column name, due to which I cant create a MV.
Is there some other way to achieve this goal.
BRK.

I have too many records which is affecting the performance of the database.
But now its raising performance problems.Your application had a performance problem. Somebody guessed that a star schema would solve the problem. But it hasn't. So now you intend to implement some spavined variant on star schema because somebody has suggested that complete de-normalisation might solve the problem.
Is this a demonstrable fact (you have benchmarks and explain plans to justify it) or just a guess?
I know how difficult this sort of thing can be, because I've been working through some similar scenario for a while now. The important thing is get some decent metrics on your application. Use statspack. Use the wait interface. Find out where your application is spending its time and figure out what you need to do to reduce the waits. Benchmark some alternatives. This may result in you having to re-write your code but at least you'll be doing so in the knowledge
Cheers, APC
Blog : http://radiofreetooting.blogspot.com/

Star schema in OBIEE 11G

Hi Experts,
Please tell me the places in OBIEE 11G where i can design the start schema.is it only in Physical Layer or In BBM too?
Thanks-Bhaskar

Final point, for performance reasons you should also try to model data into star schema in the physical layer.
If the data is modelled as a true star then there are database features which optimise query performance. These features are set by a DBA when the Warehouse is configured (e.g. enable_star_transformations). The results with this parameter on/off can be staggering (query time reduced from minutes to seconds), showing the power of star schema.
When snowflakes occur, these performance features will not work as designed, and performance will be degraded. There are certain criteria that have to be met by the data e.g. bitmap indices on all of the foreign key columns in the fact.
Please mark if helpful / correct,
Andy
www.project.eu.com

Resolving loops in a star schema with 5 fact tables and 6 dimension tables

Hello
I have a star schema, ie 5 FACT tables and 7 dimension tables, All fact tables share the same dimension tables, some FACT tables share 3 dimesnsions, while other share 5 dimensions.
I did adopt the best practices, and as recommended in the book, I tried to resolve them using Context, as it is the recommended option to Alias in a star schema setting. The contexts are resolved, but I still have loops. I also cleared the Multiple SQL Statement for each context option, but no luck. I need to get this resoved ASAP

Hi Patil,
It is not clear what exactly is the problem. As a starting point you could set the context up so that it only covers the joins from fact to dimension.
Fact A, joins Dim 1, Dim 2, Dim 3, and Dim 4
Fact B, joins Dim 1, Dim 2, Dim 3, Dim 4 and Dim 5
Fact C, joins Dim 1, Dim 2, Dim 3, Dim 4 and Dim 6
Fact D, joins Dim 1, Dim 2, Dim 3, Dim 4 and Dim 7
Fact E, joins Dim 1, Dim 2, Dim 4 and Dim 6
If each of these are contexts are done and just cover the joins from fact to dim then you should be not get loops.
If you could lay out your joins like above then it may be possible to specify the contexts/aliases that should work.
Regards
Alan

Why do we need SSIS and star schema of Data Warehouse?

If SSAS in MOLAP mode stores data, what is the application of SSIS and why do we need a Data Warehouse and the ETL process of SSIS?
I have a SQL Server OLTP database. I am using SSIS to transfer my SQL Server data from OLTP database to a Data Warehouse database that contains fact and dimension tables.
After that I want to create cubes using SSAS form Data Warehouse data.
I know that MOLAP stores data. Do I need any Data warehouse with Fact and Dimension tables?
Is not it better to avoid creating Data warehouse and create cubes directly from OLTP database?

Another thing to note is data stored in transactional system may not always be in end user consumable format for ex. we may use bit fields/flags to represent some details in OLTP as storage required ius minimum but presenting them as is would not make any
sense to user as they would not know what each bit value represents. In such cases we apply some transformations and convert data into useful information for users to understand. This is also in the warehouse so that information in warehouse can directly be
used for reporting. Also in many cases the report will merge data from multiple source systems so merging it on the fly in report would be tedious and would have hit on report server. In comparison bringing them onto common layer (warehouse) and prebuilding
aggregates would be benefitial for the report performance.
I think (not sure) we join tables in SSAS queries and calculate aggregations in it.
I think SSAS stores these values and joined tables and we do not need to evaluates those values again and this behavior is like a Data Warehouse.
Is not it?
So if I do not need historical data, Can I avoid creating Data Warehouse?
On the backend SSAS uses queries only to extract the data
B/w I was not explaining on SSAS. I was explaining on what happens inside datawarehouse which is a relational database by itself. SSAS is used to built cube (OLAP structures) on top of datawarehouse. star schema is easier for defining relationships
and buidling aggregations inside SSAS as its simple and requires minimal lookups to be performed. Also data would be held at lowest granularity level which can easily be aggregated to required levels inside OLAP cubes. Cube processing is very resource
intensive and using OLTP system would really have a huge impact on processing performance as its nnot denormalized and also doing tranformation etc on the fly adds up to complexity. Precreating a layer (data warehouse) having data in required format would
make cube processing easier and simpler as it has to just cross join tables and aggregate data based on relationships defined and level needed inside the cube.
Please Mark This As Answer if it helps to solve the issue Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

Star schema without a fact table?

Hi,
I'm preparing my warehouse for using with Discoverer and my question is about the star schema.
- Is a star schema directly associated with data warehouse?
- Can I talk about a star schema if a) I do not have a fact table (no summarized values) and b) if I do not have a dimension of time?
The problem is, I'm thinking of usine Discoverer but should I use it if it's not connected to a data warehouse?
As I told, I'd like to modelized my data "like" a star schema but my "center table" will contain only the foreign key of my dimensions; no time dimensions, no aggregate data in the center table (fact table).
Is there another word for the model I'd like to do?
Thank in advance.

Hi,
Is a star schema directly associated with data warehouse?Not really, a star schema is just one where there is one large fact table joined to many smaller dimension tables using key fields. You usually see this in data warehouses.
Can I talk about a star schema if a) I do not have a fact table (no summarized values) and b) if I do not have a dimension of time?A star schema must have a fact table but it doesn't need contain summarised values or a time dimension.
You can use Discoverer with any Oracle database, it doesn't have to be a data warehouse.
Rod West

Regarding Extended star schema

Hi Friends,
In Extended star schema,master data will load separately ,which will connect through sid's to dimension table .
My question is.. This master data tables can be used other than this cube ?
Please tell me i am in confusion.
Thanks in advace,
Regards,
ramnaresh.

Hi
InfoCubes are made up of a number of InfoObjects. All InfoObjects (characteristics and key figures) are available independent of the InfoCube. Characteristics refer to master data with their attributes and text descriptions.
An InfoCube consists of several InfoObjects and is structured according to the star schema. This means there is a (large) fact table that contains the key figures for the InfoCube, as well as several (smaller) dimension tables which surround it. The characteristics of the InfoCube are stored in these dimensions.
An InfoCube fact table only contains key figures, in contrast to a DataStore object, whose data part can also contain characteristics. The characteristics of an InfoCube are stored in its dimensions.
The dimensions and the fact table are linked to one another using abstract identification numbers (dimension IDs) which are contained in the key part of the particular database table. As a result, the key figures of the InfoCube relate to the characteristics of the dimension. The characteristics determine the granularity (the degree of detail) at which the key figures are stored in the InfoCube.
Characteristics that logically belong together (for example, district and area belong to the regional dimension) are grouped together in a dimension. By adhering to this design criterion, dimensions are to a large extent independent of each other, and dimension tables remain small with regards to data volume. This is beneficial in terms of performance. This InfoCube structure is optimized for data analysis.
The fact table and dimension tables are both relational database tables.
Characteristics refer to the master data with their attributes and text descriptions. All InfoObjects (characteristics with their master data as well as key figures) are available for all InfoCubes, unlike dimensions, which represent the specific organizational form of characteristics in one InfoCube.
Integration
You can create aggregates to access data quickly. Here, the InfoCube data is stored redundantly and in an aggregated form.
You can either use an InfoCube directly as an InfoProvider for analysis and reporting, or use it with other InfoProviders as the basis of a MultiProvider or InfoSet.
See also:
Checking the Data Loaded in the InfoCube
If the above info is useful, please grant me points

Hyperion Performance Scorecard - generatecube.bat

Hi,
I am using Hyperion Performance Scorecard 11.1.1.1.
I have a problem with generateCube.bat follows...
C:\Oracle\Middleware\user_projects\epmsystem1\HPS\hpsfiles\bin\generate_cube>GenerateCube.bat
Exception in thread "main" java.lang.NoClassDefFoundError: com/hyperion/hit/registry/exceptions/RegistryException
Caused by: java.lang.ClassNotFoundException: com.hyperion.hit.registry.exceptions.RegistryException
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Could not find the main class: com.hyperion.pmd.hps.toolkit.CommandLineCubeGeneration. Program will exit.
any idea?
thanks!
Edited by: user1108671 on 27/01/2012 03:32
Edited by: user1108671 on 27/01/2012 03:34

Have you checked the documentation ? http://download.oracle.com/docs/cd/E12825_01/nav/portal_1.htm
HTH
Srini

Star schema design, metrics dimension or not.

Hello Guys,
I just heard from one of my colleagues that its wise to
have an "KPI" or "metrics" dimension in my DWH star schema (later used in OBIEE).
Now, we have quite a lot of data 100 000 rows per day (botton leve, non-aggregated, the aggregations are obviously far less then that, lets say 200 rows per day) and
we have build pre-aggregated data marts for each of the 5 very static reports (OBIEE Publisher).
The table structure is very simple
e.g.
Date,County,NumberofCars,RevenuePerCar, ExpensesPerCar, BreakEvenPerCar, CarType
One could exclude the metrics "NumberofCars","RevenuePerCar", "ExpensesPerCar", "BreakEvenPerCar"
and put them into a metrics dimension.
MetricID Metric
1 NumberofCars
2 RevenuePerCar
3 ExpensesPerCar
4 BreakEvenPerCar
and hence the fact table design would be simpler.
Date,County,MetricID,Metric, CarType
Disadvanatages: A join is required
We would have to redesign our tables
tables are not aggregated anymore for specific metric types
if we notice performance is bad, we would need to go back to the old design
Advantages : Should new metrics appear, we dont have to change the design of the tables
its probably best practice
Note: date, country and cartype are already dimensions. we are just missing one to differentiate the metrics/KPI's
So I struggle a bit, what should I do? Redesign, or stick to the way I have done it, having
performance optimization in mind.
Thanks

"Usually the date is stored in sales table or product table.
ut here why they created separate Dimension table for date(Dim_date)? "
You should provide the link.
A good place to start with the basic concepts is :
http://www.ralphkimball.com/
Pick up some of his books and start going through them.
My recommendation would be
The Data Warehouse Toolkit, 2nd Edition: The Complete Guide to Dimensional Modeling
John Wiley & Sons, 2002 (436 pages
Good Luck.,

Star schema design

Hi,
I know that in classical star schema the dimension tables sits within the info cube and so we cannot use this dimension table in any other cube we need to have separate dimension table for that cube thought it might be having same data. I also know to over come this redundancy extended star schema came into picture where we have SID table and we keep the dimension table out of the cube and reuse the dimension tables across many cubes.
Now what i don't understand is that instead of having Separate SID tables for linking the dimension and fact tables why cant we make the DIMENSION table generic and keep them out of the infocube so that we can same the same dimension table for many infocube in this case we wont need SID tables.
suppose i have one info cube which has dimension vendor material and customer and its keyfigure is quantity and price and i have a separate infocube which has dimesnion material customer and location and its key figure is something else ......so here in why cant i keep the dimensions out of the infocube and use the dimension material customer for both infocube.

Your dimension tables are filled based on your transaction data - which is why dimension table design is very important you decide to group related data for the incoming transaction data into your dimension tables .
The dimension tables have SIDs which in turn point to master data = in the classic star schema - the dimension tables are outside the cube but the dim tables have the master data within them whhich is overcome using the extended star schema.
The reason why dimension tables can be reused is that the dim IDs and SIDs in the simension table correspond to the transaction data in the cube - and unless the dim IDs in both your cubes match you cannot reuse the dim tables - which means that you have exactly the same data in both the cubes - which means you need not have two cubes with the same data.
Example :
Cube 1 : Fact Table
Dim1ID | DIM2ID | KF1
1|01|100
2|02|200
Dimension Table : Dim 1 ( Assumin that there are 2 characteristics in this dimension ) - here the DIM1ID is Key
Dim1ID | SID1 | SID2
1|20|25
2|30|35
Dimension Table Dim 2 - Here the Dim2ID field is key
Dim2ID| SID1 | SID2| SID3
01| 30| 45
02|45|40
Here the Dim IDs for the cube Fact table are generated at the time of load and this is generated from the NRIV Table ( read material on Number Ranges ) - this meanns that you cannot control DIM ID generation across cubes which means that you cannot reuse Dimension Tables

Star schema versus snowflake schema

I have a question regarding dimensional data modeling. My question here is, when star schema model would be useful and when snowflake schema model would be useful.
In star schema, we have only fact and it is connected with dimensions. But in snowflake schema, we are normalizing dimension into one more level. Let us say, we have dimension product. Product can be normalized into another table called supplier. Let us take another example, customer dimension. Customer dimension can be normalized into country…
Advantage of star schema is, easy to write the query since we have only less tables. You do not need to join multiple tables when we write the query. It would improve the performance some time.
Advantage of snowflake schema is, it is little complex to write the query, since we have to join multiple tables. Performance might improve some time when we join smaller tables…
My question is, at what circumstances, we can use star and snowflake schema? I am not able to define the word sometime_
Any help is highly appreciated…

Hi,
There is a trade off on the availability and the Complex analytics.
A star schema is good if you have the functional requirements really simple. Like the dimension is not SCD Type2 (slowly changing dimension) and you don't need to do "AS IS" vs "AS WAS" reporting.
In modern Analytics in any domain dimensions are SCD Type 2 as business keep on evolving. In a star schema structure this will cause explosion of data if there are frequent changes at the higher levels of the dimensional hierarchy. That anyway will hit the performance.
As far as my experience goes, at the data model level it is better to have snow flaked dimensions. and while managing the metadata (in a BI reporting tool) you can consolidate the snowflaked dimensions in star schema structures. That will make ah hoc analytics much simple for the business users.
A lot of performance measure can be taken to improve the end user experience.
In short the trend in BI analytics demands to have a snowflaked structure rather than a simple star schema structure.
Hope this helps.

Star schema cannot be mapped to multiple tables

Hello!
I am mapping dimension in AWM.
When I am drawing lines from the source columns to the target objects "Member". I get the message "star schema cannot be mapped to multiple tables". Sometimes I can workaround the problem by drawing the lines in a different order. But this dose not always work
I have a dimension that have several levels and hierarchy and I always get the message "star schema cannot be mapped to multiple tables" no matter in witch order I draw the lines to "Member".
Why do I get this message and how do I do to solve the problem?
Best regards,
Tina N Mörnstam

Hi Tina:
Is your dimension snowflaked? Are you mapping from more than one source table to the target dimension? Is the hierarchy formed over different tables?
Hazbleydi C. Verástegui

No query rewriting in a star schema

Gentlemen,
I am facing a problem with query rewriting in a simple data warehouse star schema. I want to take advantage of the built-in roll up along dimensions of a star schema. Therefore, I created several DIMENSIONs and made sure that all foreign key/primary key relationships between fact and dimension tables are set up correctly. In addition, as many table attributes as possible are assigned the NOT NULL constraint, especially the ones that are used by the CHILD Of and ATTRIBUTE relationships.
I defined materialized views on the fact table and a couple of dimension tables to report on aggregated data. All the MVIEWs are enabled for query rewriting and I have the initialization parameter set correctly (QUERY_REWRITE_INTEGRITY is set to TRUSTED).
From my tests I learned that a query is rewritten correctly only of the corresponding MVIEW contains the fact table and one dimension table. This is true for every dimension I created. However, as soon as the MVIEW joins more than one dimension table to the fact table the rewriting mechanism fails. It appears that the roll-up (aggregation along the hierarchy) is only possible for one of the dimensions. If the original query suggests rolling-up more than one dimension (e.g., "summarize the key figures by year and product category" but the underlying dimension is based on month and product), the MVIEW is no longer rewritten at all.
Do you know this effect from your work experience? Is this a bug or have I made a mistake or forgotten to switch on a special feature?
Here are some technical data of our data warehouse: we are running an Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 on a Windows Server 2003, the size of the database is about 10 GB (excluding indexes), the star schema contains ten dimension tables each one with a simple or parallel hierarchies (e.g. a product dimension). The fact table and the MVIEWS are partitioned by month.
Any help is very welcome.
Regards,
John

Hi,
you may ask with DBMS_MVIEW why your query does not get rewritten:
Maybe you have to create a util table first with
SQL> @?/rdbms/admin/utlxrw.sql
Then you ask:
SQL> begin
DBMS_MVIEW.EXPLAIN_REWRITE('<your query without ; at the end>');
end;
The reason why it is not rewritten:
SQL> select message from rewrite_table order by sequence;
Kind regards
Uwe

Star Schema generation problem in Performance Scorecard

Similar Messages

Maybe you are looking for