I'm currently solving this task: some data should be sent from AdventureWorks2012 to Anchor model tables on the same server in MsSQL.
This is my Anchor Model
At this point I have a pretty simple Integration Services project in Visual Studio and it looks like this.
Control flow:
For example Load_territories is:
The main requirement is to fill all tables of Anchor model tables in MsSQL but I'm constantly facing a problem: the amount of attributes in tables are different and some of them are repeating
At this picture in the second table basically TR_ID,TR_GRP_TR_ID, TR_TID_TR_ID, TR_TNM_TR_ID contain the same values from dwh_key but it's impossible to create a one-to-many relation between attributes. My tutor has recommended me to use Lookup but I cannot figure out how to implement them in this project
This may be considered as cheating, but if you insert data into the latest view rather than the separate 6NF tables all of those ID fields will be populated by underlying trigger logic. I suspect that this would defeat the purpose of using SSIS though, since you would effectively be loading attributes sequentially rather than in parallel.
Another option is to leave surrogate key management to the ETL tool. This would require that you switch the data type for your identities from integers to GUID:s. SSIS can then generate a GUID and you can then use that very same GUID to populate all the attributes. Note that the anchor would have to be loaded first, or you will get a foreign key violation.
The most common solution though, is to leave surrogate key management to the database (and use integers). You would have a step in which you populate the metadata column in the anchor with the desired number of new identities to be created. Using the metadata number you can then select the newly generated identities and merge them into your data flow. It doesn't matter which number gets assigned to which row. After that all attributes can be populated in parallel, including their ID columns.
Of course, if this is intended to be used for more than an initial load, you would also have to add steps to detect if the data you are loading is already known or not.
I can also recommend watching the video tutorial referenced in this blog post: https://clinthuijbers.wordpress.com/2013/06/14/ssis-anchor-modeling-example-tutorial/
Hi right I'm just creating the foriegn keys/relationships in sql server management studio, but I've come across a bit of a problem.
I have several tables lets call them
my_form1,
my_form2,
my_form3
When filling out any of these 'my_forms' I keep a record of that. In another table lets call that 'forms'
In forms I have these fields
form_id
form_type - I store the type of form (1,2,3)
myform_id - I store the id of the form.
How do I correctly show this on my sql server management relationship.
I've cut down the problem and there are obviously more fields but the situation is the same.
This kind of relationship can't be enforced with a simple foreign key, and therefore won't show up on a diagram generated with SSMS.
You can create your own diagram in Visio and draw it there. I believe this is what is called a "Subtype" entity relationship.
I have a project that is using EF6 Database first mapped to a SQL database. This is all new so I control the EF model as well as the database schema.
I currently have a table that I'll call Vehicle for simplicity. I use a discriminator column to get subclass Entities Car and Truck. This all works fine.
Now I need to do a 'soft delete' and move any deleted vehicles to a VehicleHistory table. (After trying this w/ EF i will probably use a SQL transaction). This needs to be reviewable so I need this history table mapped as well, but I would like to keep it within the inheritance hierarchy so its easily reused in other classes.
My idea was to create 'vehiclecurrent' and 'vehiclehistory' tables with FK's to Vehicle for shared columns. i would then use TPT in EF to get 'carcurrent','carhistory', ect... derived from my TPH classes(so e.g. carhistory->car->vehicle). This is not working and I get Error 3034: "Entities w/ different keys are mapped to the same row"
So my question is basically how can I pull this off? Will this approach work and how, or is there another way to accomplish this? Thanks!
This is not a duplicate of this post although the title is very similar. I am using EF4 with MSSQL Express 2008 R2 on VS2010.
A simplified version of my schema is as follows:
Table [Team]:
Id (PK)
Member1
Member2
Table [Person]:
Id (PK)
FirstName
[Team].Member1 and [Team].Member2 are foreign keys pointing to [Person].Id.
When generating the .edmx via VS2010, the navigation properties under [Team] become "Person" and "Person1" despite giving distinct names to the FKs inside SQLServer.
Is it possible to force the .edmx generator to recognize my FK names in SQL Server? I'd like these names to be Member1Person and Member2Person, for example, so I don't have to manually rename them by hand. If not, what is the preferred way to redesign the tables/FKs to bypass this altogether? Thank you.
I have had a similar issue but I believe the answer to the question is you simply have to rename the Navagation property to what you want. The Entity Framwork designer will always keep you changes to the property names on the Conceptual side of things.
I'm working on a multi-user internet database-driven website with SQL Server 2008 / LinqToSQL / custom-made repositories as the DAL. I have run across a normalization problem which can lead to an inconsistent database state if exploited correctly and I am wondering how to deal with the problem.
The problem: Several different companies have access to my website. They should be able to track their Projects and Clients at my website. Some (but not all) of the projects should be assignable to clients.
This results in the following database schema:
**Companies:**
ID
CompanyName
**Clients:**
ID
CompanyID (not nullable)
FirstName
LastName
**Projects:**
ID
CompanyID (not nullable)
ClientID (nullable)
ProjectName
This leads to the following relationships:
Companies-Clients (1:n)
Companies-Projects (1:n)
Clients-Projects(1:n)
Now, if a user is malicious, he might for example insert a Project with his own CompanyID, but with a ClientID belonging to another user, leaving the database in an inconsistent state.
The problem occurs in a similar fashion all over my database schema, so I'd like to solve this in a generic way if any possible. I had the following two ideas:
Check for database writes that might lead to inconsistencies in the DAL. This would be generic, but requires some additional database queries before an update and create queries are performed, so it will result in less performance.
Create an additional table for the clients-Projects relationship and make sure the relationships created this way are consistent. This also requires some additional select queries, but far less than in the first case. On the other hand it is not generic, so it is easier to miss something in the long run, especially when adding more tables / dependencies to the database.
What would you do? Is there any better solution I missed?
Edit: You might wonder why the Projects table has a CompanyID. This is because I want users to be able to add projects with and without clients. I need to keep track of which company (and therefore which website user) a clientless project belongs to, which is why a project needs a CompanyID.
I'd go with with the latter, having one or more tables that define the allowable relationships between entities.
Note, there's no circularity in the references you have, so the title is misleading.
What you have is the possibility of conflicting data, that's different.
Why do you have "CompanyID" in the project table? The ID of the company involved is implicitly given by the client you link to. You don't need it.
Remove that column and you've removed your problem.
Additionally, what is the purpose of the "name" column in the client table? Can you have a client with one name, differing from the name of the company?
Or is "client" the person at that company?
Edit: Ok with the clarification about projects without companies, I would separate out the references, but you're not going to get rid of the problem you're describing without constraints that prevent multiple references being made.
A simple constraint for your existing tables would be that not both the CompanyID and ClientID fields of the project row could be non-null at the same time.
If you want to use the table like this and avoid the all the new queries just put triggers on the table and when user tries to insert row with wrong data the trigger with stop him.
Best Regards,
Iordan
My first thought would be to create a special client record for each company with name "No client". Then eliminate the CompanyId from the Project table, and if a project has no client, use the "No client" record rather than a "normal" client record. If processing of such no-client's is special, add a flag to the no-client record to explicitly identify it. (I'd hate to rely on the name being "No Client" or something like that -- too fuzzy.)
Then there would be no way to store inconsistent data so the problem would go away.
In the end I implemented a completely generic solution which solves my problem without much runtime overhead and without requiring any changes to the database. I'll describe it here in case someone else has the same problem.
First off, the approach only works because the only table that other tables are referencing through multiple paths is the Companies table. Since this is the case in my database, I only have to check whether all n:1 referenced entities of each entity that is to be created / updated / deleted are referencing the same company (or no company at all).
I am enforcing this by deriving all of my Linq entities from one of the following types:
SingleReferenceEntityBase - The norm. Only checks (via reflection) if there really is only one reference (no matter if transitive or intransitive) to the Companies table. If this is the case, the references to the companies table cannot become inconsistent.
MultiReferenceEntityBase - For special cases such as the Projects table above. Asks all directly referenced entities what company ID they are referencing. Raises an exception if there is an inconsistency. This costs me a few select queries per CRUD operation, but since MultiReferenceEntities are much rarer than SingleReferenceEntities, this is negligible.
Both of these types implement a "CheckReferences" and I am calling it whenever the linq entity is written to the database by partially implementing the OnValidate(System.Data.Linq.ChangeAction action) method which is automatically generated for all Linq entities.