If models in Master Data Services are representations of subject areas (such as customer, product, etc.), is it possible to have a domain-based attribute that uses a different model as it's source?
For example, if creating a customer model and defining an entity called Customers, this entity will have address information for the customer. City, State/Province, Country, etc.
But rather than creating an entity for CustomerCountry, can I use a Geography model that contains a Country entity and link to that? Then I can also use the Geography.Country entity for Vendors and Employees.
No, you cannot cross model boundaries - the primary reason is that a model is the unit of versioning. There are two workarounds:
Duplicate the entities in question - i.e. copy the geography entities into your customer model
Reference an entity by code - i.e. add a CITY_CODE to your customer entity
Neither of these are great options 1) is unwieldy and 2) doesn't maintain automatic integrity.
Personally I use option 2) where I can with some additional logic/business rules outside of MDS to ensure that codes match. This is easier with codes that are global and do not change such as country and city codes.
This seems quite old but this is now possible in 2016 and is accomplished though Entity Synch. The idea is you can synch your entity across models. There are two ways to run the synch, either on demand or automatically.
See https://learn.microsoft.com/en-us/sql/master-data-services/entity-sync-relationship-master-data-services for more details
Related
First time posting here as I was told to seek help from this community if I was ever stuck!!
I was recently introduced to databases this semester and I have a hard time grasping the bridge entity that is meant to erase the many-to-many relationships.
The classic example would be the relationship between STUDENT and CLASS;
where STUDENT can be in many CLASSES and a CLASS can have many STUDENTS.
The M-M relationship is fixed by introducing the ENROLL entity. Here we would read: a STUDENT can ENROLL in many CLASSES, and a CLASS may have many STUDENTS ENROLLED in it, however each STUDENT can be ENROLLED in a CLASS only once.
In my case, I tried to fix a M-M relationship issue between PRODUCT and RAW MATERIAL for a pharmaceutical company by introducing an INGREDIENT entity, which looks like this:
RAW MATERIAL 1----M INGREDIENT M----1 PRODUCT
I am not sure if the bridge works out because I have trouble interpreting it like the STUDENT-CLASS example above.
How would you interpret this?
The concept of "bridge" or "associative" entities came from network data modeling and was a way of handling many-to-many binary as well as ternary and higher relationships. Network data modeling is a simple physical data model based on representing entities as records and relationships as references/pointers.
Since the 1970s, the relational model of data has been developed which uses relations (tables) to record relationships between sets of values (which represent business entities, measurements and labels), allowing for the direct representation of many-to-many relationships and ternary and higher relationships.
The entity-relationship model was an attempt to provide more conceptual structure on top of the relational model, by distinguishing entity relations from relationship relations.
My point with the history is that in modern data modeling, we no longer resolve or erase many-to-many (or ternary or higher) relationships (unless you're using an object-relational mapper or framework based on the network data model). Tables with composite keys, consisting of two or more entity keys, directly represent relationships, and allow us to handle attributes on relationships as well, another feature missing from network data modeling.
In your case, it may be useful to add a Quantity attribute on your Ingredient relationship. The interpretation here is that Raw material refers to a type of material rather than a specific piece or selection of raw material. Students have identity, raw materials generally don't.
Note that pharmaceutical companies may well track specific batches of raw materials.
I'm trying to find out a way to find the relations of a specific entity, say one targeted for deletion.
Example setup:
Country entity can have many Currencies.
Currency entity can have Countries.
A Country may have a primary Currency.
Therefore, the setup is: Country <-> (1-n) <-> CountryCurrency <-> (n-1) <-> Currency.
In the above example it's easy to find if a Country, targeted for deletion, has any associated Currencies.
However, imagine that the above is setup in a global kind of way and usable for other modules within the application.
If another module, Address for example, used a Country in a uni-directional relationship (an Address has one Country): how can I figure out that the specific Country entity may not be deleted without trying to and thus receiving a Foreign Key constraint error?
I'm hoping that Doctrine has something for this built in, but haven't been able to find it in the documentation. Have been Google'ing it for a while now as well without success. Always in the trend of: "well, you just $entity->getSomeRelation()->count() > 0 and you know", but I'm looking for a generic solution/method that can apply to any entity.
There is no generic solution for it because it always depends on your business model.
Deleting entity with relation can lead to different scenarios:
deleting related entities as well
setting the relation to null
or disallow deleting at all.
So it's up to you to do the check mannualy, depending on your case.
I've read through a bunch of tutorials to the best of my ability, but I'm still stumped on how to handle my current application. I just can't quite grasp it.
My application is simply a read-only directory that lists employees by their company, department, or sorted in alphabetical order.
I am pulling down JSON data in the form of:
Employee
Company name
Department name
First name
Last name
Job title
Phone number
Company
Company name
Department
Company name
Department name
As you can see, the information here is pretty redundant. I do not have control over the API and it will remain structured this way. I should also add that not every employee has a department, and not every company has departments.
I need to store this data, so that it persists. I have chosen Core Data to do this (which I'm assuming was the right move), but I do not know how to structure the model in this instance. I should add that I'm very new to databases.
This leads me to some questions:
Every example I've seen online uses relationships so that the information can be updated appropriately upon deletion of an object - this will not be the case here since this is read-only. Do I even need relationships for this case then? These 3 sets of objects are obviously related, so I am just assuming that I should structure it this way. If it is still advised to create relationships, then what do I gain out of creating those relationships in a read-only application? (For instance, does it make searching my data easier and cleaner? etc.)
The tutorials I've looked at don't seem to have all of this redundant data. As you can see, "company name" appears as a property in each set of objects. If it would be advised that I create relationships amongst my entities (which are Employee, Company, Department), can someone show me how this should look so that I may get an idea of what to do? (This is of course assuming that I should use relationships in my model.)
And I would imagine that this would be the set of rules:
Each company has many or no departments
Each department has 1 or many employees
Each employee has 1 company and 1 (or no) department
Please let me know if I'm on the right track here. If you need clarification, I will try my best.
Yes, use relationships. Make them bi-directional.
The redundant information in your feed doesn't matter, ignore it. If you received partial data it could be used to build the relationships, but you don't need to use it.
You say this data comes from an API, so it isn't read-only as far as the app is concerned. Worry more about how you're going to use the data in the app than how it comes from the server when designing your data model.
Ok, so I am new to entity framework...
I have an existing SQL database with some 500 tables in it, and we are in the process of considering a move from Linq->SQL to Entity Framework as our main data access layer. We also want to consider more of a domain driven design approach with separate data contexts managing key areas of the application ( i.e. Sales, Marketing, Jobs, Shipping etc. etc. ).
If we take a common entity such as "Customer", this appears in more than one model. I have two models in my sample app so far. Entity Framework is clever enough to create only one customer class ( we are using the default Poco T4 templates for class generation ), however when I try and run the project I get the following error "Multiple types with the name 'Customer' exist in the EdmItemCollection in different namespaces. Convention based mapping requires unique names without regard to namespace in the EdmItemCollection".
So am I right in thinking that Entity Framework does not allow "Customer" to exist in more than one model ? If I really want customer appearing in more than one model, do I have to start creating different versions of the customer class to deal with it ?
Apologies in advance if this is a dumb question, but I am relatively new to EF.
Thanks...
You said that you are creating DDD with bounded context. In bounded context, you create more than one context with one or more related entities in it. Why do you want to create more than one model with the same name?
Check the Julie Lerman's link for reference:
http://msdn.microsoft.com/en-us/magazine/jj883952.aspx
Sorry if I am out of context. But, in my experience in such a scenario, we have to create two different context such as "MarketingModelContext" and SalesModelContext. MarketingModelContext will have all the dbsets related to marketingmodel along with customer entity. In the same way, SalesModelContext will have all the dbsets related to SalesModel along with customer entity. In this way, you will be creating only one customer entity or POCO which can be used by two contexts independently. This is known as bounded contexts as Julie Lerman calls it. It will help you in separation of context, concerns and helps you with better performance as only required context(fewer entities) can be loaded. The above article will help you with this.
Hope I have answered your query.
Lets say I have Customer, Order, OrderDetail classes in the business layer (It's a simplified version of my problem).
I have also an old (existing) database that has one global table where every row of the table contains the information of Customers-Orders-OrderDetails; for example:
CustomerID, CompanyName,Fax,OrderID, OrderDate,ProductID,UnitPrice,Quantity
(in this way there are duplicated information of a Customer in different rows).
In the future I'll have a new database (with different table Customers, Orders, OrderDetails), and I want to use the same program.
I want to use EF CodeFirst to mapping to the old database and in the future to the new database
Which is the best solution?
Design a business layer with a global class that contains the information of Customers-Orders-OrderDetails. So the mapping of this class
with the old database using EF4 in the data layer is trivial.
In the future I'll modify both business layer and data layer for the new database.
Design a business layer with Customers, Orders, OrderDetails classes. In this case is it possible to map these classes to the global table of the old database? How ? (the problem is that the Customer-Order is one to many).
In the future I'll modify only data layer for mapping the new database.
This will work for now and later you will have to modify everything working with a global class - it can be a lot of work.
It is not possible to map one table to three entities where two have one-to-many relation between them with EF.
Use third approach. Load one class as described in first approach but immediately convert result to three classes from the second approach. The reverse operation will be done in case of persisting changes. Wrap this code in single place - repository. Your application will use three classes and it will not have any knowledge about the way how they are persisted. Once you change the database you will only remove additional conversions from the repository and work directly with Customer, Order, OrderDetail loaded and persisted by EF.