I need to create an ER where users can add and delete their personal contacts.
Contacts can be any person including other users.
Users can also check who of the other users have added them to their contact list.
I don't know how to start. Can someone please help me draw this ER?
Person
PersonID (PK)
OtherUserInfo...
Contact
PersonId (FK to UserID)
contactId (FK to ContactID) Composite PK these 2 together.
PersonProfile
PersonID (FK to userID)
PersonCategoryID (FK to UserCategoryID) Composite PK these 2 together.
PersonCategory
personCategoryID (PK)
PersonCategory (User, Contact etc) depending on if a user can be a contact or just a contact or just a user.
when a user adds a contact the entry is put in Person table and an associated record is in personProfile with a personcategoryID for contact and the contact is linked to the person putting in the etnry via contact table
If a person is added as a contact from the other users, (found by joining person to personprofile where personcategory links to "user" entry, then an entry is saved in contact with the personId doing the seach and the personid of the contact they just added.
if a person is removed from personporfile as a contact, all entries in contact table for that contactId are removed as that person is no longer a valid contact. (assuming history isn't needed)
Just my thoughts... there's lots of ways to skin this cat based on additional requirements, desired growth etc.
Related
For the sake of simplicity, let's say I have two tables: one is called People and the other is called Contacting
People table:
ID primary key
NAME
WEBSITE
EMAIL
Contacting table:
ID (foreign key to People ID)
WAY_OF_CONTACTING
REFERENCE
The logic goes as follows: for every person there is in the People's table there could be several records on the Contacting's table. Obviously, the relationship between People and Contacting is one-to-many.
WAY_OF_CONTACTING could have only 2 values: "Email" and "Website", and the REFERENCE column contains the email or the website's name.
The primary key of the Contacting table is a composite primary key consisting of the ID and the Way_Of_Contacting (this means, for every ID, they can only have up to one email and one website)
The records on the people's table get deleted every night and get populated throughout the day.
4 things could happen in the People table:
Website and Email empty
Website empty but not Email
Email empty but not Website
Neither Website nor Email Empty
My problem is the following:
For every record in the People table
insert into Contacting a record when the ID exists in Contacting but doesn't have a record with Way_of_Contacting='Website' or when the ID doesn't exist in Contacting
insert into Contacting a record when the ID exists in Contacting but doesn't have a record with Way_of_Contacting='Website' or when the ID doesn't exist in Contacting
In other words:
If the People ID exists in the Contacting table, check if a record has the value "Email" on the field Way_of_Contacting.
If such record doesn't exist, and the Email field in the People table is not empty, insert a record.
If the ID doesn't exist and Email field in People is not empty, insert a record.
Same thing for Website
How could this be accomplished?
I've tried using merge and if not exists but I can't seem to find a correct answer
Can you try using a view instead of a table like below. The advantage being that the view is always updated based on the people table.
CREATE VIEW dbo.Contacting
AS
Select
ID
,'Website' as Way_of_Contacting
,WEBSITE as Reference
From People
Where WEBSITE is not null
Union all
Select
ID
,'Email' as Way_of_Contacting
,Email as Reference
From People
Where Email is not null
Suppose I have employees and departments and employee role where one employee can belong to a different department with a different role.
For example, Emp 1 belongs to Dept 1 with a role manager. where the same employee can belong to Dept 2 with a role service-man.
Each employee also has a child hierarchy like Emp 2, Emp 3 belongs to Dept 1 with role assistant and their parent is Emp 1.
In this case what will be the best solution for designing this concept. Please share your opinion.
Consider the entities and attributes:
Employees:
id,
name
Departments:
deptID,
dept_name
Roles:
role_id,
role_name
I'll try to state the business domain as you've outlined it, and then turn that into a schema suggestion.
The system has 0 or more employees
The system has 0 or more departments
The system has 0 or more roles
<<EDIT: your comment says that the "parent" role is department-specific>>
An employee belongs to 1 or more departments, and within that department has exactly one role and one parent (a parent is another employee)
Employee
------------
Employee_id (pk)
Name
Roles
------
Role_id (pk)
Name
Departments
-----------
Department_id (pk)
Name
Employee_deparment_role
-------------------------
employee_id (pk, fk)
department_id (pk, fk)
role_id (pk, fk)
Parent_id (pk, fk to employees)
This model only captures one state - it doesn't allow people to change departments or roles, or "parent", but you didn't mention that as a requirement.
I am using ASP.net MVC.
my question is that I have 2 tables patient and doctors and I want to create one common Userlogin table for both this table. So when I store username and password in UserLogin table it can determine whether it is Patient username or password or Doctor.
Can anyone please help me what should do? And give me some more idea about how and what I should change.
Doctors and patients are both subclasses of a more generic class, Users. You may want to research a topic called "Class Table Inheritance" There is a tag with that name here in Stackoverflow, and there are many articles on this topic on the web.
Class Table Inheritance is one way of making up for the fact that the relational model does not have a built in mechanism for inheritance.
Briefly, Your userlogin table needs a primary key, and username may not be suitable for this purpose. Call this key, UserId. Doctors and Patients do not need a unique id of their own. Instead, you can include UserId in both the doctor table and the patient table. This column should be the primary key of the doctor and patient table. In addition, this field should be named as a foreign key that references UserID in the UserLogin table.
The UserLogin table should probably include columns (fields) for all the features that are common to both doctors and patients, such as first name, last name, etc.
When you want to know if a user is a doctor or not, just join UserLogin and Doctor. Non doctors will drop out of the join.
Step-1. Create RoleMaster Table and add patient , doctors , receptionist as roleName in rolemaster table.
ColumnName Datatype
RoleId int
RoleName nvarchar(50)
Status bit
IsDeleted bit
CreatedDate datetime
step-2 Add RoleId As Reference in userLogin table and profileTable.
I have a many to many relationship between bookmarks and tags:
Bookmarks
Id
UserId
Title
Url
Tags
Id
UserId
Title
Description
TagsBookmarks (junction table)
TagId
BookmarkId
As far as I know this is normalized and valid.
However it is possible that multiple users save the same bookmarks which means duplicate URLs in the bookmarks table. Does this kind of duplication belong to normalization and should it be avoided?
Update:
The system works like this:
User logs in and create bookmarks / tags.
A bookmark should have atleast one tag attached to it. For example: "http://google.com" may belong to tag "google" and "search-engine".
When a bookmark gets deleted the relation in TagsBookmarks also get deleted. The tags do not get deleted.
A user can delete a tag if it has no bookmarks.
A bookmark cannot exist without a tag.
A tag can exist without bookmarks.
Usually, table names and table columns are singular.
I would move UserID to TagBookmark.
Bookmark
--------
BookmarkID
BookmarkTitle
BookmarkURL
Tag
---
TagID
TagTitle
TagDescription
TagBookmark
-----------
UserID
TagID
BookMarkID
The primary (clustering) key of TagBookmark would be all 3 ID fields concatenated.
I'm not sure what the difference is between a TagTitle and a BookmarkTitle, so there may be some further normalization to be done.
You should exclude UserId from Bookmarks and Tags tables and add it to your junction table, because your system is user-centric as I understood from your explanation. Like this:
Users
Id
FirstName
...
Bookmarks
Id
Title
Url
Tags
Id
Title
Description
UsersTagsBookmarks (junction table)
UserId
TagId
BookmarkId
or even you need two junction tables, but it depends on your system logics:
TagsBookmarks (junction table 1, specifies all possible tags/bookmarks combinations)
Id
TagId
BookmarkId
UsersTagsBookmarks (junction table 2)
UserId
TagBookmarkId
I'm designing a database that stores movie related information. I'm stuck on a problem and can't seem to know how to solve it.
So I'm creating a database that store movies, and for my movie table these are its attributes
-movieID NUMBER PRIMARY KEY,
-title VARCHAR(10),
-genres genre_varray,
-producers
-director
-cast
I'm going to create another tables for producers, cast and director. My problem is for the fields producers and cast I have to insert a list of people and the cast I have to add a role to each actor, I'm not sure how I would do that, I was thinking of using nested table? Another problem is that a person can be either actor, director, producer or all.
What I have so far is
supertype person_type - personID, name, sex
subtype actor_type - country
subtype director_type - country
subtype producer_type - company
table of people of type person_type
table of movie_people - profession
Thanks for any help.
Any person can perform one or more roles on a movie, and the roles they perform will be different for different movies.
I would have a table of people, a table of movies, a table of role types (eg:Actor, Director, Producer,etc) , and a table linking all three with fields of (PersonID, MovieID, RoleID)
I would also have a separate table for MovieGenres rather than the array you have detailed.
In total, you need six tables:
GENRES
GenreID
GenreName
ROLES
RoleID
RoleName
PEOPLE
PersonID
PersonName
MOVIES
MovieID
MovieName
MovieYear
CASTLIST
CastID
MovieID
PersonID
RoleID
MOVIEGENRE
MovieID
GenreID
A person can appear in the castlist of a movie in several roles, which is why I have given the table a surrogate id. Otherwise you will need a primary key composed of all three foreign keys (and that assumes that you want to list a person playing three different characters only once - check out Dr Strangelove).
Edited to include the MovieGenre table.