Within LUIS I want to create an entity for supported clothing/accessories.
I am thinking a Hierarchy entity with children of type Accessory and Outerwear. This will work for my needs, however, I need to exclude items from the entity (non-supported types of clothing).
What is the best approach to exclude items
Related
I have a lab entity with two multi-valued attribute nested inside the entity (rooms attribute that contain hardware attribute) and I need to represent it in ERD then in relational schema.
so the problem is like :
is the above representation right ?
one another way I tried to solve this problem is by making the rooms a weak entity to the lab and the hardware a weak entity to rooms like :
what is the best way of these two and is there a better idea ?
and how to map this in relational schema ? because the way I think about it I think it would take 3 tables to represent it either ways.
Using Core Data, I have two entities that have many-to-many relationships. So:
Class A <<---->> Class B
Both relationships are set up as 'ordered' so I can track they're order in a UITableView. That works fine, no problem.
I am about to try and implement iCloud with this Core Data model, and find out that iCloud doesn't support ordered relationships, so I need to reimplement the ordering somehow.
I've done this with another entity that has a one-to-many relationship with no problem, I add an 'order' attribute to the entity and store it's order information there. But with a many-to-many relationship I need an unknown number of order attributes.
I can think of two solutions, neither of which seem ideal to me so maybe I'm missing something;
Option 1. I add an intermediary entity. This entity has a one-to-many relationship with both entities like so:
Class A <<--> Class C <-->> Class B
That means I can have the single order attribute in this helper entity.
Option 2. Instead of an order attribute that stores a single order number, I store a dictionary that I can store as many order numbers as I need, probably with the corresponding object (ID?) as the key and the order number as the value.
I'm not necessarily looking for any code so any thoughts or suggestions would be appreciated.
I think your option 1, employing a "join table" with an order attribute is the most feasible solution for this problem. Indeed, this has been done many times in the past. This is exactly the case for which you would use a join table in Core Data although the framework already gives you many-to-many relationships: if you want to store information about the relationship itself, which is precisely your case. Often these are timestamps, in your case it is a sequence number.
You state: "...solutions, neither of which seem ideal to me". To me, the above seems indeed "ideal". I have used this scheme repeatedly with great performance and maintainability.
The only problem (though it is the same as with a to-one relationship) is that when inserting an item out of sequence you have to update many entities to get the order right. That seems cumbersome and could potentially harm performance. In practice, however, it is quite manageable and performs rather well.
NB: As for arrays or dictionaries to be stored with the entity to keep track of ordering information: this is possible via so-called "transformable" attributes, but the overhead is daunting. These attributes have to be serialized and deserialized, and in order to retrieve one sequence number you have to get all of them. Hardly an attractive design choice.
Before we had ordered relationships for more than 10 years, everyone used a "helper" entity. So that is the thing that you should do.
Additional note 1: This is no "helper" entity. It is a entity that models a fact in your model. In my books I always had the same example:
You have a group entity with members. Every member can belong to many groups. The "helper" entity is nothing else than membership.
Additional note 2: It is hard to synchronize such an ordered relationship. This is why it is not done automatically. However, you have to do it. Since CD and synchronizing is no fun, CD and synchronizing a model with ordered relationship is less than no fun.
I'm wondering if my textbook has a non-standard definition. I've red this question and it is not a duplicate. The book defines entities and entity sets as
An entity is an abstract object of some sort, and a collection of
similar entities forms an entity set. An entity is some ways resembles
an "object" in the sense of object-oriented programing. Likewise, an entity set bears some
resemblance to a class of objects.
When they say "class of objects" are they referring to a class as in the thing you instantiate to make new objects (I know this is just a loose comparison). It sounds like an entity set is more general than just an entity, but in this question a reply states "An entity set usually represents a slice of an entities data" which is the opposite.
I thought an entity is like a table in a database, then what's an entity set?
An entity is a real world object such as a person, a place or a thing or an abstract object such as a course, a flight reservation, etc. Here we use article 'a' or 'an' to indicate an instance of a specific person, a specific place or a specific thing as an entity. For example, I, by name 'Vidyasagar' is an entity and you are also an entity. All similar entities form entity set. Similar means each entity has the same (for simplicity) properties. All person entities will have same properties such as first name, middle name, last name, date of birth, etc. Entity and entity sets are analogous to relational database terms row/tuple and table/relation repectively. These are also analogous to OOPS terminology of objects and collection of objects respectively.
Obviously we can not store real world entities such as persons, toys, cities, etc., in a database! We can store only data about real world entities. The data consists of values for each property of entities. For example, data for city entities could be 'London' and 'UK' for London city entity, 'Paris' and 'France' for Paris city entity and 'Bangalore' and 'India' for Bangalore city entity. We use values of one or more properties (key) to refer to an entity for convenience. Hence when we say Paris entity, we mean the city Paris which is in France. That is we are referring to the pair of values Paris and France. The pair of values together is an entity. The three entities are ('London', 'UK'), ('Paris', 'France') and ('Bangalore', 'India'). There is no significance to parentheses used as such. These three entities will form an entity set, say, CITIES. Hope this is clear.
The definiton in your textbook in my opinion is not so clear. I find it very confusing.
I think you should stop at the first part of the definition:
An entity is an abstract object of some sort, and a collection of similar entities forms an entity set.
A set is simply a collection, a group of these entities. Usually the type of these entities is the same, so I suppose that saying:
an entity set bears some resemblance to a class of objects.
it means that objects in this collection/set are instance of the same class.
An entity is an abstract object of some sort, and a collection of similar entities forms an entity set. An entity is some ways resembles an "object" in the sense of object-oriented programing. Likewise, an entity set bears some resemblance to a class of objects
I'm currently writing my first project using core data, and am having trouble working out how to query the relationship between some of my data.
In sql language, i have a Country table, which joins to a CountryLink M-M table containing the following fields:
countryId1
countryId2
bearing
What would be the correct way to model this in Core Data?
So far i have set up a single Country entity and a CountryLink entity (containing only a bearing field) and have added two 1-to-Many relationships from Country to CountryLink ('CountryLink1' and 'CountryLink2').
I've run the project and looked at the Sqlite db structure produced by Core Data (found here, using this sqlite gui), and the M-M join table seems correct (it contains the bearing, CountryLink1 and CountryLink2 fields), but i'm not sure how i would go about carrying out a fetch request for a single Country NSManagedObject to return an array of related Countries and their bearings?
Any help or related links would be much appreciated.
Thanks, Ted
First a word of warning:
Core Data is not SQL. Entities are not tables. Objects are not rows. Columns are not attributes. Core Data is an object graph management system that may or may not persist the object graph and may or may not use SQL far behind the scenes to do so. Trying to think of Core Data in SQL terms will cause you to completely misunderstand Core Data and result in much grief and wasted time.
See the Tequilla advice
Now, forgetting SQL and thinking in object graphs, your entities would look something like this:
Country{
someAttribute:string // or whatever
countryLinks<-->>CountryLink.country
}
CountryLink{
countryID1:string // or whatever
countryID2:string // or whatever
country<<-->Country.countryLinks
}
As you add Country and CountryLink objects you add them to the relationships as needed. Then to find CountryLink objects related to a specific Country object, you would perform a fetch on the Country entity for Country objects matching some criteria. Once you have that object, you simply ask it for the CountryLink objects in its countryLinks relationship. And your done.
The important thing to remember here is that entities in combination with managedObjects are intended to model real-world objects, conditions or events and the relationship between the same. e.g. a person and his cars. SQL doesn't really model or simulate, it just stores.
I have two tables:
- Attendees
- Events
Normally, I would create a mapping table 'EventAttendeeMap' to link these tables into a many to many relationship.
Is this the best way of doing so?
Should I store the list of AttendeeIds in an xml column instead on the Events table?
I am using .NET 3.5/4 with Linq as the DAL (although I think this is irrelevant to the design question being asked, possibly).
Interested to see what people's opinions are.
Thanks.
Dave
A mapping table is definitely the best way to do it - the Entity Framework will convert the mapping table into a collection of entities on both sides and the table itself will essentially disappear.
In short yes - create a mapping table to hold the event id and the attendee id.
There is a good question here that might be of interest to you.