I have 3 entities to represent Users, Roles and Conferences
So far I got this diagram:
So,
-A user can be associated with zero or more conferences.
-A conference may have one or more users.
and...
-The same user can have different roles depending on which conference he is.
but...
-How can I improve the diagram so i can see the different roles of a user in all the conferences he has attended?
[UPDATE]
From your description it sounds like users belong to roles, and then the combination of userRoles belongs to a conference. So, without the fancy diagram, your entities would be something like this...
Users
Id
Roles
Id
Conferences
Id
UserRoles
UserId
RoleId
ConferenceUserRoles
ConferenceId
UserId
RoleId
You may need to add a "UserRoleId" to UserRoles and use that in ConferenceUserRoles. I'm not exactly sure how EF will handle the three-way relation table.
Hope this helps!
Related
I am building a ecommerce application with two different types of users, users who shop and vendors/brands.
Should I make two tables for each user like?
User| id, email, password, username, address, stripeCustomerId
Brands| id, email, password, username/brandName, shippingRate, address, stripeAccessToken etc.
Or should I make it like so:
Users| id, email, password, username, address, stripeCustomerId
Brands| userid, etc...
This is an example of trying to model the object-oriented notion of inheritance in a relational database. If you search for that term, you'll find several answers on Stack Overflow.
In your case, I think you have 3 logical entities:
User: email, password, username, address...
Customer (is a type of user): StripeID
Vendor (is a type of user): shipping rate, stripe token
How you model those logical entities to physical objects in your database is mostly a question of trade-offs - the other answers explain those.
I assume there will be significant differences in both the behaviour and attributes between "customer" and "vendor".
I also assume your data model will evolve over time - for instance, you probably need to store more than one address for each user (shipping, billing), you probably have different lifecycles for "customers" (new, registered, registration confirmed, payment confirmed) and "vendors" (new, approved, rejected).
If those things are true, I'd just bite the bullet and have 2 tables, customer and vendor. This means you can evolve their behaviour more easily - you don't have to worry about needing a slightly different address logic between two "customer" and "vendor", you just build what you need. Your schema is a little more self-explanatory - your foreign keys go to tables that say what they do (products -> vendors, not products -> users).
It shouldn't be two tables, but three :D
1. users (id, name, password, )
2. customers (user_id, customer_specific_fields)
3. vendors (user_id, vendor_specific_fields)
What would be the correct way to normalize a scenario where we have Users and Roles where certain roles have the same attributes and other roles have different attributes? Let's take the following example:
tb_User(user_id, first_name, last_name, e_mail);
tb_Role(role_id, role)
tb_Plant(plant_id, plant)
tb_Entity(entity_id, entity)
I have roles like: Admin, General Manager and Plant Manager and Entity Manager. Admin and General Manager roles don't have any other attributes, but plant manager has a plant associated with it and Entity Manager has an entity associated with it. Should I create one table like this and have Plant/Entity have a value where it applies like this:
tb_user_role(user_role_id, user_id, role_id, plant_id, entity_id)
or have separate tables for plant and entity like this:
tb_user_role(user_role_id, user_id, role_id)
tb_user_role_entity(user_role_entity_id, user_role_id, entity_id)
tb_user_role_plant(user_role_plant_id, user_role_id, plant_id)
Another consideration is that one one user can have many plants, so one plant manager role and many plants, same thing for entity.
I appreciate your help,
I'm having a little trouble grasping CoreData relationships, i'm note sure which relationship type I should be using between my 2 entities or if my logic is correct.
1) "Person" Entity - attributes such as name, tel, address, country, etc...
2) "CountryList" - attributes such as countryName, countryLat, countryLong, etc..
The CountryList entity is pre populated on first run of the app to include all the countries in the world and their respected data.
Where i'm stuck is do I need a relationship between these two entities?
I will be allowing the user to select a country from the CountryList entity data and wish to store there selection in the country attribute for Person entity.
Do I just take the countryName from CountryList as a string and store it in country from Person? or can I make a relationship between them?
I know a user can only belong to 1 country but a country can have lots of users so is this a one to many relationship? Or is it many to many because lots of users can belong to a country but a country can have loads of users? Confused!
Could someone please enlighten me on this and point me in the right direction in what i should be doing in xcode.
Many Thanks in Advance
Matt
EDIT: Is this correct?
I have made the changes to Entity names etc and think I now have the relationship set correctly.
EDIT 2: Removed country attribute and renamed relationships
Firstly, your "CountryList" entity should be called "Country", since it represents only one country. The fact that you have many of those countries has nothing to do with its name.
After that, it seems just natural to use a relationship, one "Person" has one "Country", but one country can have many persons. Therefore, one-to-many relationship. Using a relationship will simplify many operations you might want to perform (i.e. access all the country information of one person, or get a list of all persons being in one particular country).
Oh, and this might help you understand relationships a bit better: There are no "many-to-many" relationships in CoreData per se. You always define a relation from a source to a target. So if you define a relation from Country to Person, this will be a one-to-many relationship. One country, many persons. You can then define a relationship from Person to Country, which would be a one-to-one relationship. One person, one country. If you defined this as an one-to-many relationship, you would end up with a de facto many-to-many relationship (because on person can have many countries and one country can have many persons). It's not as complex as it appears.
Now, after you've defined your two relationships, you can set them as each others "Inverse Relationship". Do it for one of the relationships, the other one will be set automatically. After you did that, CoreData will for example update a Person's country when you add the person to the country's list.
See https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdRelationships.html for further information.
CountryList should just be Country
Then you set a 'many to one' relationship between Person.county and Country
You are using Core Data so you must define relationship between Person and Country if you want to fetch person's country from database.
And in this relationship you may take one to one relationship. As One person will belong to one country only. Of Course a country will have many person but unless you want to show all people related to particular country you do not need one to many relationship..
In case you want to implement one to many relationship this tutorial link maybe helpful to you for understanding one to many relationship..
http://www.theappcodeblog.com/2011/09/29/iphone-app-development-tutorial-core-data-part-2-one-to-many-relationship/
I have task to build application for user registration. I have 3 types of user (profiles)
1. "Normal" user
2. "Company" user
3. "Company2" user - similar like 2. but with few additional fields..
All users share some specific info, like e-mail and password (Login data), role, registration date etc.... So, I'm trying to "design" classes for this type of app using only EF Code First approach, but with no luck..
Do I need table (class) for :
USER - all kind of users with all their Login data (email and password) and UserType
USERTYPE - list of all user types (1,2,3)
USER_DETAILS - details of normal user
COMPANY_DETAILS - details of company
COMPANY2_DETAILS -details of company2
My problem is how to reference USER table with USER_DETAILS, COMPANY_DETAILS, COMPANY2_DETAILS. I hope so that you understand my problem :)
My classes (user management and profile) is implemented like http://codefirstmembership.codeplex.com/ example.
Thank you in advance!
You can use a normal inheritance model with Entity Framework.
I would just use a base class User that contains the login data (please don't store the password in the DB though, use a hash - Membership should do this for you already) and other user info, then you can add another class CompanyUser that inherits from User and contains the additional properties. Finally CompanyUser2 (needs a better name) can inherit from CompanyUser.
Having this in place there are different models you can use on how EF maps your classes to tables:
1.) Table-per-Hierarchy
2.) Table-per-Type
3.) Table per Concrete Type
I am an experienced .NET developer but new to EF - so please bear with me. I will use an example of a college application to illustrate my problem. I have these user roles:
Lecturer, Student, Administrator.
In my code I envisage working with these entities as distinct classes so e.g. a Lecturer teaches a collection of Students. And work with 'is Student' 'TypeOf' etc.
Each of these entities share lots of common properties/methods e.g. they can all log onto the system and do stuff related to their role.
In EF designer I can create a base entity Person (or User...) and have Lecturer, Student and Administrator all inherit from that.
The difficulty I have is that a Lecturer can be an Administrator - and in fact on occasion a Student can be a Lecturer.
If I were to add other entities such as Employee and Warden then this gets even more of an issue.
I could presumably work with Interfaces so a person could implement ILecturer and IStudent, however I do not see how this fits within EF.
I would like to work within the EF designer if possible and I'm working model-first (coding in C#).
So any help and advice/samples would be very welcome and much appreciated.
Thanks
Don't make Student and Lecturer inherit from Person. As you say, what if "Bob" was both a student and a lecturer? This happens all the time in real colleges. You said it best yourself: These are roles, not types. A person can have many roles.
As a rule of thumb, avoid inheritance in O/R mapping when it's not strictly necessary (which is almost never). Just as when coding, favor composition over inheritance.
So you could give each Person a property Roles which is a 0..* collection of Roles. Then to get a list of students, you can do:
var students = from p in Context.People
where p.Roles.Any(r => r.Id = studentRoleId)
select p;
Or you could have a related Student type with a 0..1 relationship between Person and Student; this would allow you to add additional data for the student, e.g.:
var students = from p in Context.People
where p.StudentInfo != null
select new
{
Id = p.Id,
Name = p.Name,
Grades = p.Student.Grades
};