Can a subtype doesn't have any local attributes?
For example, if I have to create subtypes about the phase of a tournament, as GroupStage, Quarter Finals, Semi Finals and Final I'd better create an attribute or a specialization?
Subtypes are used for specialized attributes and/or relationships, so, yes, you can have subtypes that don't have additional attributes. However, if you don't have either specialized attributes or relationships, it's simpler to add an attribute on your main entity set than to create subtypes. Changing an entity from one subtype to another also requires more effort, so try to use subtypes for roles that don't normally change, rather than for states that vary over time.
Related
In EER modelling is it possible and correct to have a disjoint specialization where none of the sub-classes have any specific attributes(local to them) but are entirely grouped on the basis of a defining attribute.For example we can have a USER entity with some attributes of which one is "role".Based on value of role(admin or author or editor) we will have the subclass entities ADMIN ,AUTHOR and EDITOR.None of them has any attributed which are only specific to them.Also please note that the specialization is disjoint and the superclass entity USER has total participation.
And if this is possible, can I convert it to relational model by creating a single relation for the superclass entity USER
Yes, it's possible and valid to do so if you want to record relationships that are restricted to the subtypes. If you don't have subtype-specific attributes or relationships, there's no point in distinguishing subtypes in the ER model. A simple role attribute on the User is sufficient for queries.
If you define subtypes in the ER model, this converts to a relation per subtype in the relational model. If you're looking for something like dependent types, you won't find it in the relational model, which corresponds to first-order logic. ER is even more limited.
I have 2 entities in Core Data which have some common properties. I have to show both the entities in a same list view. What will be the best practice to do this? Can I do some inheritance thing and put common properties in base class?
Core Data supports inheritance.
Open your core data model and select the child entity. Make sure the utilities pane is displayed (top right button in Xcode) and select "Show the data model inspector" (right most icon in the utilities pane).
Here you can select a parent entity for your entity. All attributes of the parent will be available in the child entity.
Apple documentation on Core Data inheritance
What will be the best practice to do this?
It depends on what type of entities you need to model. For example, if you have a Cat and a Dog, you should move the attributes in common in a base entity (say Animal or whatever you want). In other words, you should have a reason for doing this, i.e. entities have a sort of relationship each others.
Can I do some inheritance thing and put common properties in base class?
Yes of course. In a model you are allowed to have a sort of inheritance pattern like the following.
where
I would stress two things here.
First, you can make base entity as an Abstract Entity. In this way, you are not allowed to create instances of this entity.
As per the doc.
You can specify that an entity is abstract—that is, that you will not
create any instances of that entity. You typically make an entity
abstract if you have a number of entities that all represent
specializations of (inherit from) a common entity which should not
itself be instantiated. For example, in a drawing application you
might have a Graphic entity that defines attributes for x and y
coordinates, color, and drawing bounds. You never, though, instantiate
a Graphic. Concrete sub-entities of Graphic might be Circle, TextArea, and Line.
Second, under the hood Core Data will create a single table with all the attributes you have inserted. So, if you have a lot attributes, you will have a lot of columns for a table.
I'm trying to be a "good little programmer" and implement inverses for all relationships in my core data model. However, I've come across a situation that makes this seem impractical.
For simplicity, consider a general-purpose entity type called Location that contains an x attribute and a y attribute (and might contain other attributes, but let's keep it simple). Several different entity types may need to keep up with one or more location (players have an original location and a current location, cells have locations, destinations have locations, etc). Given all the different uses for such a general type, it seems impractical to make an inverse relationship in the location entity type for every instance in which it's used in other entities.
Is there an better alternative in Core Data for implementing a very general-purpose entity type that would prevent the need for relations without inverses?
Having received no answers, I'll share the pattern I started using to help in this situation:
Basically, I derive an entity type from the general-purpose entity type for each specific use, and then I can make relationships and inverse relationships to the derived entity type as appropriate.
For example, I can have a PlayerLocation entity type and a PlayerOrigin entity type, both with the general purpose "Location" as their parent entity type (so in object-oriented-think, they become classes derived from a Location base class). Then a Player entity type can have a to-one relationship (location) to a PlayerLocation and a to-one relationship (origin) to a PlayerOrigin, and each of those derived location types can have unique inverse relationships (owner) pointing back to the Player. Here's a pictorial:
This may cause me to create many more entity types than I originally envisioned, but it makes for a pretty clean object model with specific entity types that have clear relationships and inverse relationships.
Hope that helps others.
I am building an app around CoreData and have bumped into a dilemma. Hopefully has a simple solution.
I have an entity, 'Equipment'. Each equipment object has a name and type. When selecting a type depending on the selection, I need to add more attributes to that entity, but only to that object.
So if I have an equipment object of type bowl. I want to add the attribute containsMilk for example. Whereas if the type is knife, I want to add the attribute isBreadKnife.
Any tips on how to do this? As you can see, not every equipment object will necessarily have the same attributes and different types require unique ones.
How can I achieve this? Thanks.
Is it possible to define Inheritance Mapping and a Discriminator Property using a BD first approach.
I use the EDMX diagram to define the mapping of tables to object.
I have a DomainEntity Table that contains all my domain entities and they are descriminated by TypeID that is mapped to a DomainEntityTypes table.
If i had full control i would design the mapping this way:
Define an abstarct class DomainEntity
Inherit from the DomainEntity calss to creat concrete entities
Use the Inheritance Mapping Annotation and the IsDiscriminator Annotation over the TypeID
Use an enum to define all possible types (and i wonder what the types table is for from that point)
Could all this be defined in the EDMX file somehow ? or do i need to stop using auto generation and continue with manual mappings?
There is no "auto-generation" of inheritance mapping. When you use database first you simply load tables to your model and it will create entities with relations. Now if you want to have inheritance you must modify the mapping from the designer. Here is a nice description how to set up TPH inheritance in the designer.
You can define base entity for your inheritance hierarchy as abstract. It is property of the entity in the diagram.
You must inherit a new entity for all types you want to use and correctly set up its discriminator value in the mapping.
There are no real annotations - inheritance is a construct available in the ToolBox and discriminator is a condition defined in the mapping.
You will have no enum. Discriminator column will even not be available in your entities because it is already used to define mapping to correct type (there is limitation that each column can be used only once in the mapping so you can use it either for property or for discriminator but not for both). You will have finite set of entities to describe your inheritance hierarchy instead of enum.