Star schema - history

Similar Questions

• Can we have several independent star schema in layer of MDB in OBIEE?

  Hi friends,

  I need to create four reports based on four star schema, so we have 4 tables of facts and independent sides associated with each, all the tables are in the same data source, I have to design RPD and I have a few questions:

  • Can we have several independent star schema in a layer of MDB model? If YES then I guess we can create a domain for each in the presentation layer, but if NOT then do we create a separate business for each star schema model?

  Early response will be appreciated, thanks.

  Hello

  The rule is simple:

  1 topic-online 1, 1 business model business model => N areas

  This is the limitation.

  So YES you can have have 4 independent stars in a single MDB, YES you can have 4 domain of the same MDB.

  The point is more in what you want your RPD to looks like planning: there are people who are trying to have a limited number of MDB and so they put in allmost all their stars even MDB, others MDB business sense, so if 4 independent stars means they have 4 different meaning that it would create 4 MDB.

• Star schema

  Hi all
  
  I applied for a new job and during my interview that I was asking what is a pattern of departure?
  I wasn't able to answer so I did not :(
  
  On their return I google it:
  

  In data warehousing and business intelligence (BI), a star schema is the simplest form of a dimensional model, in which data is organized into facts and dimensions.  A fact is an event that is counted or measured, such as a sale or login.  A dimension contains reference information about the fact, such as date, product, or customer. A star schema is diagramed by surrounding each fact with its associated dimensions. The resulting diagram resembles a star. 
  
  Star schemas are optimized for querying large data sets and are used in data warehouses and data marts to support OLAP cubes, business intelligence and analytic applications, and ad hoc queries. 

  It seems that most of the companies do not have this configuration again or they didn't need? You and me should I invest time studying this in order to be marketable employee?
  Or there is little market for this kind of work so forget about it.
  
  Or how do I convert my existing database configuration to a type of star schema?
  
  
  Thank you
  
  YX

  It seems that most of the companies do not have this configuration again or they didn't need?

  In general, there are implementations of star patterns (data warehouse, olap, analytical etc.) less than 'normal' implementations (oltp). Be able to set up and adjust a star schema requires a slightly different mindset.
  However, to go further, many more companies would implement these plans.

  How to convert my existing database configuration to a schema type star?

  You do not have. You create a star schema where it is needed. For simplicity, when you want to build a data warehouse which consolidates and maintains historical data of one or more OLTP databases, you build a star for the data warehouse schema and copy the OLTP database to the Data Warehouse.

  Hemant K Collette

• question about the star schema?

  Hi Experts,
  
  I'm new to OBIEE, can you guys help me,.
  
  I want to know can we create star schema using 2 facts and 5 dimensions (without the flakes)?
  
  Thanks in advance.

  Hello

  See below to have a clear understanding

  http://108obiee.blogspot.com/2009/08/joining-two-fact-tables-with-different.html

  Kind regards
  Young

  NOTE: Please mention if this solved your problem/still face and close the message to help others with similar problems.

• In the physical layer star schema

  Recently, I came across a question from a colleague. The discussion continues as follows:
  He asked me what is the star schema, and where you can set? Physical layer or layer MDB?
  I've explained on the star schema and responded to his rest of the doubt that we define it in the layer of MDB.
  His immediate question is why can not we define it in the physical layer? Since MDB layer allows to build three-dimensional models, therefore, we must build it into this layer itself is my answer. But later in the evening, when I started to reflect on my way to the House, I started to think about his doubts.
  Here is what am curious that we can unite our physical layer tables too, why we can't define star in the physical layer? and why only in MDB? and what are the differences in the joints that we made in the physical layer as the layer MDB?
  I got tired of getting answers to these documents and in a few other online resources, but am not to succeed. Then, approach this forum in anticipation. Can anyof you help us to better understand these concepts.

  Yes, you need to (or is at least strongly recommended) to use complex joins in the MDB layer. I know that you can also use physical layers in the layer MDB, but I don't really know what happens when you do that and what are the consequences. I think I read once your knuckles are 'fixed' and the BI server is not to choose between the joints.

  So the idea is: set the 'true' joined in the physical layer using physical joints and define complex joins in MDB layer and let the BI server decide what physical join, it should use.

• Star schema and snowflake schema

  Hi experts,
  
  
  What is the star schema and snowflake schema? What is the difference between them? What is the best?

  Hello

  The scheme must be used for a project BI/DW depends on business/needs. Therotically, a schema is a collection of database objects, including tables, views, indexes and synonyms. You can organize the objects of schema in the schema of models designed for the data warehouse in a variety of ways. Most data warehouses use a dimensional model. Below the two schemas are widely used: -.

  The star patterns *:-the star schema is the simplest scheme of data store. It is called a star schema, because the schema looks like a star, with a Center radiation points. The Star Center consists of one or multiple fact tables and the points of the star are dimension tables. The most natural to model how a data warehouse is like a star schema, where a single join establishes the relationship between the fact table and the dimensiontables. A star schema optimizes the performance of simple queries and providing an answer fast hold time. Information on each level are stored in a row.

  Snowflake patterns *:-the snowflake schema is a data warehouse model more complex that a diagram star and is a schema type star. It is called a snowflake schema, because the schema from the schema looks like a snowflake. Snowflake patterns normalise dimensions to eliminate redundancies. In other words, dimension data has been grouped into several tables instead of a large table. For example, a product in a star schema dimension table could be standard in a products table, a table product_category and a product_manufacturer table in a snowflake schema. While this saves space, it increases the number of dimension tables and requires several foreign key joins. The result is more complex queries and reduces the performance of the queries.

  Hope it help you.

  Atul K,.

• Concerns by using not in OBIEE star schema

  Hello
  
  Please list down any questions we might have if we use the structure of Star not of OBIEE outside the performance schema.
  
  
  Thank you
  Pankaj

  Hello

  I recommend these articles of the blog of Adrian Ward on the stars and snowflakes:

  http://majendi.blogspot.com/2008/12/stars-and-snowflakes.html
  http://majendi.blogspot.com/2008/12/stars-and-snowflakes_10.html
  http://majendi.blogspot.com/2009/01/OBIEE-snowflakes-and-stars-part-3.html

  It gives a glimpse into what happens when you want to use a transactional schema in OBIEE and why you should or should not use this type of diagram.

  Kind regards
  Stijn

• Star schema design

  Hello
  I have datamodel as 1 table 2 table dim. Don't have not dim table links n/b 2. But to decrease of similar intensity.
  Now, how will create prompt dashboard with constraints.
  
  Thank you
  Govind R

  Here you go...

  Create a quick region: select ID ID country and State of the column of the pane of topic area.

  In use of the ID of the column status show the SQL result and use query below:

  SELECT
  CASE
  WHEN "Dim1. «' CountryID ' = 101 THEN Dim2 «» "" StateID ' = 201
  WHEN "Dim1. «' CountryID ' = 102 THEN Dim2 «» "" StateID "= 202
  WHEN "Dim1. «' CountryID ' = 103 THEN Dim2 «» "" StateID ' = 204
  END
  IN THE "domain".

  If you have different types of CountryID and State ID VARCHAR data, you can also use:

  SELECT
  CASE
  WHEN "Dim1. "' CountryID ' ="101"THEN"Dim2. "" StateID "="201"
  WHEN "Dim1. "' CountryID ' ="102"THEN"Dim2. "" StateID "="202"
  WHEN "Dim1. "' CountryID ' ="103"THEN"Dim2. "" StateID "="204"
  END
  IN THE "domain".

  2nd way is to use Variable presentation but then requiring 2 invites.

  This is useful in case of a small list of values that you have now.

  Hope this is useful

• Cloned card scheme star in the same layer of MDB.

  I have an ID of a group of companies and SCHEMES in STAR billing with 8 dimensions-related. The STAR SCHEMA is responsible exclusively for incoming data EBS.

  
  But, due to the acquisition of another company, today I need to load data from a legacy system.

  To not create any impact on the existing and ETLs conflict of a code, we decided to clone all the star schema tables and load the data from legacy.

  To not generate inconvenience to users, we want these facts and dimensions (which have identical structures) arranged so that they appear unique.

  Example:

  fact_billing_holding

  -dimension_day

  -dimension_organization

  -dimension_vendor

  -dimension_consumer

  -dimension_transaction_type

  fact_billing_legacy

  -dimension_day_legacy

  -dimension_organization_legacy

  -dimension_vendor_legacy

  -dimension_consumer_legacy

  -dimension_transaction_type_legacy

  But you should see the structure like this:

  fact_billing_holding

  -dimension_day

  -dimension_organization

  -dimension_vendor

  -dimension_consumer

  -dimension_transaction_type

  How can I implement this solution / problem?

  Ferrara,

  When you want to combine several sources at the query level allow fragmentation for the dimension tables

  http://108obiee.blogspot.com/2009/01/fragmentation-in-OBIEE.html

  Thank you

  Angelique

• Analytics to extend for creation of star of HFM application schema

  Hello
  
  I'm trying to create the star schema via Analytics extended HFM application but with the below error
  
  21/03/2013 12:30:07: status: extraction of metadata
  Scheme did not exist before.
  Update of metadata failed. : (- 2147217900) (one or more errors occurred during the processing of the order.)
  Change of status of processing: (-2147217900)
  Data processing failed. : (- 2147217900) (one or more errors occurred during the processing of the order.)
  21/03/2013 12:30:10: status: processing completed with errors
  Export extensive Analytics completed with errors for SCM Application using Label GCS CON.
  
  What could be the reason for this?
  Also can someone please provide all appropriate references or links to learn this EA for creation of star schema.
  
  Thank you
  Amine ravi

  Roux-

  Try to remove the space from the table prefix - GCS CON--> GCSCON

  -Keith

• Schema in Star and MV

  Hi guys,.
  
  I drew a star for one of my data mart schema, and my client is after me suggesting that while I should create a MV to provide an overview. I'm trying to convience my client does not do this with the points as below:
  
  1. as we have created a star schema in the database we should enjoy the same thing and should avoid creating another layer of reporting which will increase in the future complex queries while expanding the functionality of the mart.
  
  2. we need to create a full refreshment MV and during data refresh is not available for users and the time will increase during the period of time once the data increases
  
  3. as MV are a table on a disk using a MV in this case will consume the tablespace that will increase over the time period.
  
  Please you experts you will suggest more points or additions. We use SAP BO as a reporting tool in our Organization in which a universe can be created easily for reporting.
  
  See you soon,.
  Shaz

  >
  I drew a star for one of my data mart schema, and my client is after me suggesting that while I should create a MV to provide an overview. I'm trying to convience my client doesn't not to do this
  >
  Sounds like a question of 'trade' rather than a technical problem.

  In my view, a client has no "skin in the game" with regard to the way in which the feature is implemented. Their skin is to get the results they need. The physical implementation of the system and the data must be OPAQUE to the client.

  It is the purpose of the Service Level Agreements - to define the requirements that must be met and deadlines to comply with these requirements.

  So, I would start by working with your client to define and agree on the SLA that needs to be met and as it respect the current schema of the Star. If it can meet this customer has no descendants.

  If the service LEVEL cannot be met, then you must decide what are the options to modify the system to meet the SLA.
  Normally, I'm waiting for my manager to negotiate the SLAs with customers.

• How to do this in the scheme star

  Hi experts
  
  I have 4 tables I want to turn in a star schema.
  
  Table1 (FACT) has a n: 1 to table2 (Sun)
  
  Table2 (Sun) also has 1:1 table3 (Sun) and 1:1-table4 (Sun)
  
  Is it possible to reproduce this in a star schema where table1 (fact) is a relationship n: 1 for all tables (dimensions)?
  
  I have that modeled in the administration tool and all queries between table1 and table 2 work, but they are not if I involved table 3 and 4.
  
  Not sure how to define the relationships of 1-to-1 in the physical layer.
  
  see you soon
  
  Tim

  Hello, Tim! :)

  I hope this helps...

  If you really want to make a star from the physical layer schema, I would say that you consolidate your tables in one dimension only, if they do not contain a lot of data. If it contains a large amount of data, however, I would also say that you treat your fact table so that it contains foreign keys to those of all the three dimension tables, so it could connect to them on its own. Given all the dimension tables are 1-1 relationships, the two suggestions can be relatively easy to map.

  See you soon!

  -Cha :)

• How to identify the Source of Table in a schema star

  Hello
  We have a star schema with an intermediate table (with fact, as data on sales data) and two tables of dimension (such as by location and product data). In the model, we have specified an intermediate table to have a FK relationship with these two dimension tables.
  
  Two questions:
  -How can I select staging table and the foreign key columns in a KM. There are a few options available to the general public as: FK_PK_TABLE_NAME which helps me get my dimension of array, CT_NAME, ERR_NAME, but I can not find a method to identify the intermediate table that is one of the source tables in my interface.
  
  -Is it possible to use the function getsrctableslist() somehow? For example we can use like I_TABLE or TABLE_ORD fields to identify the source table by using this function.
  
  -On the 'Control' of my interface tab, I see the constraints that have been on the target table, is it possible to check the constraints on the source table. For example I can check if the source table contains all the entries valid product by referring to the product as the forign key relationship dimension table.
  
  Pointers, advice, solutions are appreciated.
  
  Thank you

  It's Ok now...

  follow these steps...

  (1) at IKM (not ckm) create a new step.

  technology: the same to the table in step
  Logical schema: that of the table in step

  Code:
  
  <%=odiRef.getSrcTablesList( "","/*\n Will be used the table (and its alias): \n*/","","")%>

  (2) move this step just before the stage of "Flow Control".

  (3) to sewing, the same stage where is the code that you sent change me all code at 'FROM' to

  It will work.

• How to get back the "History" feature in my toolbar?

  My computer was recently newly restored and now I don't have a 'History' option in my toolbar, and I can't understand how to find and retrieve. It would show the history of each site, I went into the last day, week, and month.

  Thank you, Julie

  You can find the toolbar buttons to open the bookmarks (star) and history (clock) in the sidebar in the palette of the toolbar and drag it to a toolbar.

  • Firefox menu button > Options/Preferences > toolbars
  • View > toolbars > customize

  There are two buttons bookmark with a star in the window customize.
  
  One button star has a marker to drop that open a menu of bookmarks (you can not see the marker in the window customize).
  
  The other star button without the marker drop open bookmarks in the sidebar.

• Code and the database tables in different schemas

  Hello
  My version of db: database Oracle 11 g Enterprise Edition Release 11.2.0.3.0 - 64 bit Production
  
  I would like to understand the advantages and disadvantages of the following situation:
  We have only one request.
  The design of the db for this application has 44 paintings, of which 28 are base tables related by PK and FK relations. The other 16 are look upward and refer to tables that are not related to one.
  The team has decided to place the tables in a diagram 28 A and the other 16 in another schema B within the same database. (The reason for this is... because it's done in other projects to do it here too).
  Coming now to the code (stored procedures, functions, packages, etc.). Teams want to ask most of the code in the diagram B with the Ref 16 tables. (the reason being again the same).
  What are the advantages and disadvantages this?
  Please advice.
  
  PS:
  I have googled and find something on these lines:

  cons:  
  o harder to manage
  o harder to upgrade
  o harder to patch
  o harder to maintain
  o causes your shared pool size to increase 1,000 times (shared sql goes down the tubes)
  o takes more space
  o queries against the dictionary will be impacted
  o latching on the shared pool goes WAY up (latching = locks = serialization device = 
  slows you down)
  
  pros:
  o none that I can think of.

  From my experience, if you see natural divisions that give you smaller patterns, well contained, you should take advantage of them and start with separate schemas. If done correctly, it can greatly improve the maintainability of your application.

  Assume that your initial project will have 60 paintings and they might fall into three groups of 15, 20 and 25 tables respectively. There are also objects of code such as PL/SQL packages. Your choice is:
  -Use a single scheme of 60 paintings, suppose that with 100 objects in code.
  -Use 3 diagrams divided as described. The total code objects will probably be a little more that unique schema design, because they need to provide interfaces with others. So let's assume that schemas will have 30, 40 and 50 code objects each.

  Now, wait 3 years.

  The history of single-schema:
  -The single-schema is passed to 120 tables. There has been a corresponding increase in code, now more than 200 objects. But they are very complex. Over time, each piece of code will interact with the tables more and more and many other objects in code.
  -You (the architect or Manager) can not really apply any internal for this structure since no subsidy is required to add dependencies. Therefore, if you change a table there is a vast impact.
  -You can easily divide the responsibilities because everything affects everything else. You can't manage simultaneous development efforts because the impact widespread changes cause the same tables/components to be affected by multiple projects. If you have the project execution dependencies / as you have interdependencies technique/code.
  -You have a "big ball of mud" and it is very difficult to get out of this situation.

  Multi-schema history:
  -Each of the 3 original patterns has grown, but some more than others. A fourth was added a year ago, when there was a major expansion in a new district, as a result of "natural divisions.
  -On the inside of each of these schemas, it is always a challenge to impose internal structure. But those patterns more smaller and therefore more small problems.
  -Through schemes, subsidies are necessary to allow interaction, this is not a "wild west" where everyone can access everything (and introduce dependencies on everything). Teams to define interfaces (packages or the views that are specifically intended to be interface points) where the interactions with other scehmas are necessary.
  -If changes to a table are needed, the impact can be limited to the schema that contains naturally. You know that no one else has created dependencies at this table, because you were never issued grants on this.
  -The responsibility for these schemas was divided between 2 teams, each team having full responsibility for its 2 diagrams.
  -Teams can complete projects much more easily, even with a parallel development, because there is less than a "domino effect" with each change.

  Now, these benefits depend on "natural divisions that give you the diagrams smaller, well contained." If you make the wrong choice here, you will always have a mess. You design with the end in mind scenario.