Currently I'm working with a dashboard in which I'm pulling data (this data comes from 2 tables or dimensions) from a star schema, I'm displaying the data in a table component, and this data is not being displayed correctly because it looks like there is redundancy due to the column status(This column originally calls name and it is in the pracHeaderStatus table). Here I'm adding some screenshots:
Relationships:
Result:
(The ID's repeat many times)
Note:
I do not get this problem with querying my data from sql server
Greetings!
Look at the arrows in the diagram. Notice that the Project Title is unable to filter the status Name. In order for the relationship to work as you expect, there has to be a path between the tables that doesn't go "uphill" (opposite direction of the arrows).
You should be able to fix this by changing the relationship between pracDetails and pracHeaderStatusto filter both directions. Double click on the relationship line to edit.
I talked with the people that made this database and apparently this data was being retrieved from a transactional database while power BI was interpreting it as a star schema, so in other words. The problem is that the relationships are wrong because apparently Power BI always tries to denormalize the data, thinking that is a star or snowflake schema.
Related
I am working on a project to create a simplified version of SQLite Database. I got stuck when trying to figure out how does it manages to store data of multiple tables with different schema, in a single file. I suppose it should be using some indexes to map the data of different tables. Can someone shed more light on how its actually done? Thanks.
Edit: I suppose there is already an explanation in the docs, but looking for some easier way to understand it better and faster.
The schema is the list of all entities (tables, views etc) (the database as a whole) rather than a database existing of many schemas on a per entity basis.
Data itself is stored in pages each page being owned by an entity. It is these blocks that are saved.
The default page size is 4k. You will notice that the file size will always be a mutliple of 4K. You could also, with experimentation create a database with some tables, note it's size, then add some data, and if the added data does not require another page, see that the size of the file is the same. This demonstrating how it's all about pages rather than a linear/contiguos stream of data.
It, the schema, is saved in a table called sqlite_master. This table has columns :-
type (the type e.g. table etc),
name (the name given to the entity),
tbl_name (the tale to which the entity applies )
root page (the map to the first page)
sql (the SQL used to generate the entity, if any)
note that another schema, sqlite_temp_master, may also exist if there are temporary tables.
For example :-
Using SELECT * FROM sqlite_master; could result in something like :-
2.6. Storage Of The SQL Database Schema
Good morning everybody, this is the first time I write in this forum so, i'm sorry if I do some error!!!
I'm working on a project in Visual Studio where I'm connecting to an Access Database. The most important thing is that this Database is not mine and I can't modify it because it is updated daily by another automatic software.
I have to think that this database is "Read Only".
This database only has tables with primary key but there are no relation between tables.....it really looks like different Excel sheets!!!
I don't have problem to import the tables in a DatagridView of my Visual Studio project but in these tables the data are not easy to be understood for example:
there is a column named "Color" where the color are filled like number but there is not another Table who contain the color code. I know in my mind that color 1=Red, 2=Orange, 3=Brown etc.....
What I want to do?
I want that in my DataGridView won't be show the numbers but the color name so I need to modify my DataGrid source before display data.
How is did my project?
I have my DatagridView whose data source is a BindingSource that has a Dataset as DataSource. On my Load event I use the "Fill" method of my TableAdapter to display my tables data
Could someone suggest me how modify data before display them?
Thanks a lot
Giacomo
If all you are dealing with is a limited number of values in one or two fields, you could select the records using a query and obtain the color as follows:
SELECT Table1.ID, Table1.FldA, Table1.ClrFlag, IIf([clrflag]=1,"RED",IIf([clrflag]=2,"Orange",IIf([clrflag]=3,"Brown","Unknown")))
AS MyClr
FROM Table1
If there are many lookup's to do, I would create my own database with tables of code translations and join the two databases to produce my result. The following is an example of SQL pulling from two databases:
https://support.microsoft.com/en-us/help/113701/how-to-access-multiple-databases-in-an-sql-query-in-vb-3-0
In my SSAS tabular model I have a calendar dimension, and a wave dimension for half-year data only. The data flows to these tables as such:
Fact Table ---> Wave Dim <---> Calendar
No matter what I do I cannot hide the wave table from Excel users. The table shows hidden in Visual Studio, but in Excel it shows the table with no fields in it. I have tried deleting the table and reloading it with no avail. My assumption is that it has to do with the way it's connected to the Calendar dimension, but I can't seem to find anything on my issue. Any help would be much appreciated.
This is a tough one to answer without viewing your model.bim file. Based on your information I have two guesses on what could be the issue, although this may very well not be it:
1) It sounds like you've marked all fields in the Wave table as hidden, but not the Wave table itself. Could this be the reason?
2) Perhaps you are using perspectives, and only hid the Wave table in a perspective rather than in the Model (default perspective)?
The relationships in your model should have no impact on whether a table is displayed in client tools or not.
Feel free to upload your model.bim file if the above does not help.
The setup
I have the following database setup:
CentralDB
Table: Stores
Table: Users
Store1DB
Table: Orders
Store2DB
Table: Orders
Store3DB
Table: Orders
Store4DB
Table: Orders
... etc
CentralDB contains the users, logging and a Stores table with the name of each store database and general information about each store such as address, name, description, image, etc...
All the StoreDB's use the same structure just different data.
It is important to know that the list of stores will shrink and increase in the future.
The main client communicating with this setup is an API REST Service which gets passed a STOREID in the Header of each request telling it which database to connect to. This works flawlessly so far.
The reasoning
Whenever we need to do database maintenance on one store, we don't want all other stores to be down.
Backup management should be per store
Not having to write the WHERE storeID=x every time and for every table
Performance: each store could run on its own database server if the need arises
The goal
I need my REST API Service to somehow get all orders from all stores in one query.
Will you help me figure out a way to do this without hardcoding all storedb names? I was thinking about a stored procedure on the CentralDB but I was hoping there would be other solutions. In any case it has to be very efficient.
One option would be to have a list of databases stored in a "system" table in CentralDB.
Then you could create a stored procedure that would read the database names from the table, loop through them with cursor and generate a dynamic SQL that would UNION the results from all the databases. This way you would get a single recordset of results.
However, this database design is IMHO flawed. There is no reason for using multiple databases to store data that belongs to the same "domain". All the reasons that you have mentioned can be solved by using a single database with proper database design. Having multiple databases will create multiple problems on the long term:
you will need to change structure of all the DBs when you modify your database model
you will need to create/drop new databases when new stores are added/removed from your system
you will need to have items and other entities that are "common" to all the stores duplicated in all the DBs
what about reporting requirements (e.g. get sales data for stores 1 and 2 together, etc.) - this will require creating complex union queries...
etc...
On the long term, managing and maintaining this model will be a big pain.
I'd maintain a set of views that UNION ALL all the data. Every time a store is added or deleted those views must be updated. This can be automated.
The views provide an illusion to the application that there is only one database.
What I would not do is have each SQL query or procedure query all the database names and create dynamic SQL. That would entail lots of code duplication and an unnecessary loss of performance. This approach is error prone. Better generate code once in a central place and have all other SQL code reference that generated code.
We have a program in which each user is given their own Access database. We'd like to merge these all together into a single SQL Server database.
The problem is that, using the SQL Server import/export wizard, the primary/foreign keys do not get updated. So for instance if one user has this table:
1 Apple
2 Banana
and another user has this:
1 Coconut
2 Cheeseburger
the resulting table looks like this:
1 Apple
2 Banana
1 Coconut
2 Cheeseburger
Similarly, anything that referenced Banana by its primary key (2) is now referencing both Banana and Cheeseburger, which will not make the vegans very happy.
Is there any way to automatically update the primary/foreign key references when importing, other than writing an extremely long and complex import-script?
If you need to keep them fully compartmentalized, you have to assign some kind of partitioning column to each table. Is there a reason you need your SQL Server to have the same referential integrity as Access? Are you just importing to SQL Server for read-only reporting? In that case, I would not bother with RI. The queries will all require a partitionid/siteid/customerid. You could enforce that for single-entity access by wrapping tables with a table-valued UDF which required the partitionid. For cross-site that doesn't work.
If you are just loading to SQL Server for reporting, I would also consider altering the data model to support reporting (i.e. a dimensional model is sometimes better than a normalized model) instead of worrying about transaction processing.
I think we need to know more about the underlying goals.
Need more information of requirements.
My basic question is 'Do you need to preserve the original record key?' e.g. 1:apple in table T of user-database A; 1:coconut in table T of user-database B. Table T is assumed to have the same structure in all database instances. Reasons I can suppose that you may want to preserve the original data: (a) you may have a requirement to the reference the original data (maybe a visual for previous reporting), and/or (b) there may be a data dependency in the application itself.
If the answer is 'no,' then you are probably interested only in preserving all of the distinct data values. Allow the SQL table to build using a new key and constrain the SQL table field such that it contains unique data. This approach seems to preserve the original table structure (but not the original key value or its 'location') and may suffice to meet your requirement.
If the answer is 'yes,' I do not see a way around creating an index that preserves a pointer to the original database and the key that was created in its table T. This approach would seem to require an application modification.
The best approach in this case is probably to split the incoming data into two tables: one to identify the database and original key, another to identify the distinct data values. For example: (database) table D has records such as 'A:1:a,' 'A:2:b,' 'B:1:c,' 'B:2:d,' 'B:15:a,' 'C:8:a'; (data) table T1 has records such as 'a:apple,' 'b:banana,' 'c:coconut,' 'd:cheeseburger' where 'A' describes the original database 'location,' 1 is the original value in location 'A,' and 'a' is a value that equates records in table D and table T1. (Otherwise you have a lot of redundant data in the one table; e.g. A:1:apple, B:15:apple, C:8:apple.) Also, T1 has a structure similar to the original T and is seems to be more directly useful in the application.
Ended up creating an SSIS project for this. SSIS is a visual programming tool made by Microsoft (and part of their "Business Integration Studio", which comes with SQL Server) designed for solving exactly these sorts of problems.
Why not let Access use its replication manager to merge the databases? This will allow you to identify the conflicts and resolve them before importing to SQL Server. I'm fairly confident it will retain the foreign key relationships. If I understand your situation correctly, and the databases are the same structure with different data, you could load the combined database to the application and verify the data before moving to SQL Server.
What version of Access are you using? Here's a link for Access 2000. Use the language to adjust search parameters to fit your version.
http://technet.microsoft.com/en-us/library/cc751054.aspx