I have a question and now I'm learning little by little on my own what is database.
good results that I have a computer retail store and the store is in Personal Service (Manager, Administrator, vendor and Support) and Clients (natural and legal), all these must have a user name and password you will have privileges access (User, Service Personnel).
As the design would make it?. what I want is to manage access privileges and so avoid some table inheritance, but not if it should apply in my case or only with Access, because from a table called PERSON alleged and another table called SALES, if for example, a person is a seller and one other staff person is a user who will buy anything at the table SALE I want to save the data of seller personnel and ladders, and if you only have one table called pERSON Would that double relationship?, should be two of the FK ID PERSON?
In a good model, you have to think in infinite-1, infinite-infinite, 1-1 relations.
So, a good model must be:
every table for a kind of object (persons, sales, etc)
every group of kind (administrator, sellerman, buyer, etc)
if you have infinite tables, you must create a table for relations.
e.g. for infinite-infinite (1 person can has 1 or more kind):
PERSONS
- Person_ID
- Firstname
- Lastname
- Address
WORK
-Work_ID
-Kind (Administrator, seller, etc)
REL_PERS_WORK
-Rel_Id
-Person_ID (from PERSONS table)
-Work_ID (from WORK table)
Related
I have a database with relations Witness, PoliceOfficer, Suspect, and many other person-like relations. Often the same person can figure in multiple relations as a police officer could be a suspect in some cases. Would it make sense to make another relation Person to store all person relevant data and just point at the person objects in all my person-like relations?
I fully agree with #Guranjan's comment.
Also consider whether a person can have multiples of the same role, and in what circumstances. You may have a person who is a Suspect in more than one case. So, each case can have many suspects, witnesses and officers, and each of those points to a unique person.
So, the tables would be:
case
case-id
crime-description
date
time
etc
case-person
case-id
person-id
type (witness, suspect, officer)
person
person-id
name
dob
address
etc
Not sure of your use case, but it would make sense to model it using a few tables: Person, Role would be the dimension tables - Person containing the details you need to store on the individuals (name, address, dob etc) Role containing the information relating to all possible roles (Witness, Police Officer, Suspect etc).
You'll need a fact table as well, joining these two for a a particular Scenario so for example:
Person 1 - in scenario 1 - is a Police officer
Person 2 - in scenario 1 - is a Witness
Person 3 - in scenario 2 - is a Suspect
Person 1 - in scenario 2 - is a Witness
Person 2 - in scenario 2 - is a Witness
The Scenario table would contain the Person and Role keys
I have an application which handles the creation of different shop entities.
The process:
1. User registers to the website
2. User creates a shop (with various attributes)
What I have so far for database tables is:
[USER]
user_id
[USER_TO_SHOP]
user_id
shop_id
[SHOP]
shop_id
The above design covers the need for 1 user to have many shop entities under their account.
What I want to achieve now, is to have shop entities which are standalone but also have shop entities which are a part of group of shops
Chain of Shops example:
McDonalds Address X Chicago
McDonalds Address X New York
McDonalds Address X Boston
How should I proceed with my database design in order to support chain of shops but also standalone ones? Best practices are really appreciated!
*by standalone I mean a shop entity that does not belong to a chain
Off the top of my head I'd have a locations table and rename shop to company so single companies go into that table but can have multiple locations. Then users are associated with a company location.
There are many ways to achieve what you want, so, answers will be subjective since we don't really have the whole picture.
From what you're saying, a shop can belong to between 0 and 1 chains? If so, I would simply add one extra table and add a foreign key to the shop table:
[CHAIN]
chain_id
chain_name
[SHOP]
shop_id
chain_id
Well, for chains, you could have something like this, just like you have for users:
[CHAIN]
chain_id
[CHAIN_TO_SHOP]
chain_id
shop_id
Not sure what you mean by a standalone shop though - if you mean a shop that isn't owned by a user or a chain, could be something like this:
[STANDALONE_SHOP]
shop_id
But I would question the need for such a table, since a standalone shop could be assumed by an absence of an entry in CHAIN_TO_SHOP or USER_TO_SHOP
I'm trying to figure out the best way to design these tables for a website I'm making for a school club. I want to set it up so each user can have multiple emails, phone numbers, and addresses tied to their account. To do this I tried to tie all these things to a contacts table and store the contacts id in the users table as a foreign key. The contacts id is also a foreign key in the emails, phone numbers, and addresses table. Is this a feasible way of relating these tables or should I just cut out the middle man (contacts table) and store the user id in the emails, phone numbers, and addresses tables?
Just in case my description of the relationships weren't enough, here is an ERD for the tables:
Sorry for such a "noob" question, it's been a while since I had to build a database with more complexity than 2 tables. Any general tips for database design are very much welcomed as well.
All you need to do is remove the Contacts table and store the user_id in the tables on the right, rather than contact_id.
Remove contact_id from Users as well.
I have dealt with this very question in the past. We did it wrong and we were sorry.
The determining factors should be these:
Will you have any other category of person that isn't a user, for whom you need to store contact information?
Will those kinds of persons somehow be "fungible" with users?
If you answer both these questions "yes," keep your contact table. Otherwise get rid of it.
The mistake made by a team I worked on was our answer to the second question. We had medical patients and doctors/nurses/etc as our categories of people. We stored their contact information together. But we shouldn't have done that because patients' contact information is very sensitive and confidential, but health care provider information is much less so. We were always wishing we didn't have the two kinds of data in just one set of tables after the system became successful.
Unless you can convince yourself you need your contact table, get rid of it, I say!
Yes I would cut out the midle man:
Although I was tempted to go the 'contact_type' route, I have found that there are usually validations and different data types which become more complicated when the contact is generic. For instance a table that has address fields is not the same as a phone number and having both presents more complexity and less readability.
This model focuses on simplicity, e.g. a user has many emails and an email belongs ot a user.
According to me you can design DB accordingly
Table 1 : Users
UserID //PK
Name
Table 2 : Contacts
ContactID //PK
UserID //FK to Users
ContactTypeID // FK to ContactType
Value
Table 3 : ContactType
ContactTypeID //PK
ContactTypeName
Description
Table 1 is pretty clear stores user information
Table 3 holds information about contacttype i.e email, home phone, mobile, home address, shipping address, etc
Table 2 holds information about user, contact type and its value
like cinatacttypeid corresponds to mobile than value is , etc.
This is a bit embarrassing but it's been a while.
When working with relational databases and linking to separate tables by primary:foreign keys, in 1-∞, such that, in a particular table, the table's foreign relationship returns an integer ID... how do you go about making this relationship intelligible to users?
For example:
You have a company table
CID
CompanyName
CompanyLocation
CompanyBusinessType
etc (not actual column names)
and an employee table
EID
firstName
surName
DOB
email
company
Employee company is related to CID. But some user putting in information about an employee would have to know the ID code for the particular company due to the nature of the relationship. You can run a query to return 'CompanyName's along with their associated 'CID's which can then be searched, but this cipher is hardly an ideal solution. I just cannot remember the theory of how one approaches this, even though I'm certain I've done it before. I need to implement it in both Microsoft Access 2010 and Microsoft SSMS (separate databases fwiw); but the execution should be relatively straightforward as soon as I remember how it's done!
Create a combo box with 2 columns. One column as the company name and the other as the company ID. You can set the width of the company ID to 0 if you don't want the user to see it.
This can be done with the Property Sheet on MS-Access Forms
Set the Row Source of the combo box to:
SELECT CompanyName, CompanyID FROM Company;
Set the Control Source of the combo box to:Employee.CompanyID
Also make sure the Row Source Type is set to Table/Query
If you need a many to many relationship (many employees belong to many companies) then you will need another table CompanyEmployees, something like this: -
If an employee only belongs to one company then this structure will do fine: -
In either case you will need to display the user with some form of drop down list when adding / editing a user to associate the users with one or more companies.
My question is about modeling a particular situation:
In my model I have tables: User, Offices and Partners.
The system has different user profiles: users of Office (counselors, principals, assistants), users for Partners (Institutions,..), admin users.
What is the best way to model the relationship between office users and partner users if:
- The users are unique (two users should have the same login - should be in only 1 table)
- An office user is associated to only one office
- A partner user is associated only with a partner.
It should be a table for office users and one for partners users?
A many to many relationships in this case would not work, right?
Thanks for your help.
You have not provided enough definition re Partners and Offices, so those parts of the model are not yet complete, but I think the main question you are asking is answered in this ▶Data Model◀. As I understand it:
User (login, UserName is unique, and you do not want that to be unclear)
Users are exclusively (that is the X in the half-circle) Office/Partner/Administrator
that requires a Supertype-Subtype structure. The cardinality is 1::0-1
Users belong to (?) an Office or a Partner, exclusively.
That may be OfficeType or OfficeTitle.
If you define that last item a bit more, I can finish the model.
Readers who are unfamiliar with the Standard for Modelling Relational Databases may find the ▶IDEF1X Notation◀ helpful.
Assuming this model will never change I would add a field to the users to determine where they belong. You could put an enum named user_type with possible values of 'office', 'partner', or 'admin'.. And then you could put in columns of office_id, and partner_id so you could join the tables as needed.
I think the best route would be to go with an account group structure, where you use an association table to determine who's in what group...
group
id | name
group_assoc
group_id | account_id