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
Related
I am creating a database for a community to store details of all their members along with those members' relations with each other.
For Instance: There is a family of 4. Mother, Father, Son and Daughter. The Son gets married to a girl from another family in the same community (Their data is also in the same database). The newly married couple has a new member soon. Also they need to add their grand parents to the database at a later stage (Parents of both the Mother and Father in this case).
What would be the best way to create a schema for such a database.
I have a schema called member_details that'll store all community members' data in a single table something like this.
member_details: ID | Name | Birthdate | Gender | Father | Mother | Spouse | Child
All members would have relations mapped to Father,Mother,Spouse,Child referenced in the same table.
Is this schema workable from a technical pov?
I just need to know if my solution is correct or is there a better way to do this. I know there are a lot of websites storing this kind of data and if someone could point me to the right direction.
I'd advice you to use two tables. One for members of community and one for relations beetween them. Something like this:
Members:
ID | Name | Birth | Gender
Relations:
First Member ID | Second Member ID | Relation
Where you use IDs from first table as foreign keys in second. That way you'll be able to add more relations types when you need it. By the way, I'd add a third table to store relation types, so it can work as a dictionary. Same thing for genders.
As usual, "it depends".
The first question is "how will you use this data?". What sort of questions do you expect the database to answer? If you want to show a person's profile with their relationships, that's pretty easy. If you want to find out how many children a person has, or who is the grandfather of a person, or the age of someone's youngest child, that could be a little harder.
The second question is "how sure are you these are the only relationships you want to store?" Perhaps you also want to store "neighbour", "team member", "engaged_to" - or maybe you need to store that information later on. Maybe you need to take account of people getting divorced, or remarrying.
The schema you suggest works fine for most scenarios, but adding a new type of relationship means you have to add a new column. There are no hard and fast rules, but in general it's better to add rows than columns when faced with events in the problem domain. Asking "who is this person's grandfather" requires a couple of self joins, and that's okay.
#ba3a suggests splitting the information about people from the information about relationships. This is much "cleaner" - and less likely to require new columns as you store more types of relationship. Showing a person's profile requires a query with lots of outer joins. Finding a grand parent requires self joins on the "relations" table.
Let's say my company is producing medical products, these products are used in many different lab testing instruments. The business logic hierarchy goes like this:
A lab has multiple locations (Up to thousands)
A location has multiple departments (Chemistry, Hematology, 3-5 per location)
A department has multiple instruments (No more than 10-20 instruments per location)
An instrument has many products.(No more than 1-5 product types per instrument)
The table structure currently mirrors the business logic, like displayed on the left. I suggested we make a small change, displayed on the right.
What are some pros and cons of each approach? I feel like the left-hand side approach might be a bit slower due to chaining so many Joins in a row.
The biggest "con" I see to the approach on the right-hand side is that you lose the association between Department and Location. For the relationships that you described atop your post, the structure on the left is correct from a design perspective.
HOWEVER...
The design that you have means that the Mass Spectrometer at your San Antonio facility will have a different ID than the one at your Denver facility. Is that intended?
------------------ revision after discussion in comments ------------------
You've described a couple of many-to-many relationships - a location will have multiple instruments and multiple locations can have the same instrument (e.g. Mass Spectrometer). To support that, you'll need cross-reference tables. Here's an initial sketch. My standard is to call the table's primary key "ID", and any field called "[table-name]_ID" is a foreign key to the corresponding table:
Lab
ID
Name
Location
ID
Lab_ID
Street_Address
City
etc.
Department
ID
Name
Location_Department -- this lists the departments at a given location
ID
Department_ID
Location_ID
Instrument -- Scale, Oscilloscope, Mass Spectrometer, etc.
ID
Name
Description
Location_Department_Instrument -- inventory at a given location
Location_Department_ID
Instrument_ID
Instrument_Serial_Number
Let me know if this makes sense.
I have these set of requirement:
For each school, the system needs to keep track of its unique name, address, classification (Value could be Elementary, Middle, or High), and number of students studying in it.
For each School System Employee, we need to keep track of the unique employee number, full name, address, salary, and the school where (s)he works. An individual works only in one school.
For each student, we keep track of the student’s name (at times, we need to refer to student’s first name, middle initial, and last name individually), address (at times, we need to refer to the street address, city, state, and zip code individually), the school (s)he attends, and what grade (s)he is in.
The system sends letters to High School students frequently, and hence, needs to keep track of each High School student along with the year when (s)he enrolled in the High School.
A system-wide list of courses offered is kept. Information about a course consists of its unique number, unique title, and number of credits.
For each school, the information about which courses are taught there is kept.
For each student, we keep a grade report that provides the grade (Value could be A, B, C, D, or F) for the student for a specific course.
The School System owns buses which are identified uniquely by their registration numbers. Some students take them to commute between their home and their school, while others use their personal means to commute. We keep track of which student takes which bus to commute. We also keep track of drivers assigned to buses (a driver is a school system employee who could be assigned to multiple buses, and a bus could have multiple drivers assigned to it – consider this a weekly assignment of buses and drivers).
Here is my attempt at the ER design:
This is my first ER design and i just wanted to know if met all the requirements and if I did it correctly? Any help will be much appreciated! Thanks!
First of all I don't like it to omit columns necessary for forein keys, e.g. a school ID in the employee table. But I don't know enough about ER diagrams to say if that would even be allowed.
The diagram looks fine to me. Some points though:
School names can change. If there is a number system available (such as NCES School ID for USA) I'd make this the PK instead.
Numbers of students must be no column in the school table; the number of students per school is implicitly given by the students related to the school.
I don't like 1:1 relations very much. Student <-> High Schooler is okay, but I'd rather have the enrollment date in the students table.
StudentID alone can't possible the PK for the grades table. It must be StudentID + Course# instead.
The line from student to course is superfluous, because the relation is given by the grades table already (which is a bridge table containing StudentID, Course# and an optional grade).
The course table's PK must not be Course# + Title, because that would mean the same course number would be allowed in combination with different titles. The PK should be the course number alone. As to the relation: I don't know if the same course can be taught at different schools. If so, the relations are correct.
Met. (though I'd break appart address into # StreetAddress, PO Box, city, state zip etc.(assuming US) Though if you want extra credit you could subtype addresses into their own table and simply have the employee, student and school addresses all in one table with a foreign key...
I'd break down Name, address just as habbit always go to
the loweest common denominator: Fname, LName, etc... (for scaling
solutions long term; combining data is easy, breaking it out later
is hard)
Looks good
Doesn't grade define Highschool? a 9th
grader is in highschool right? so why a seperate table?
4.1) now a table which lists what letters were sent to what students might be useful... but they didn't say they needed this so I'd seek clarification on the requirement.
if # is unique title doens't need to be part
of key.
Missing (you need a schoolCourses table)
Missing (I guess could be handled through your grade table though) Id call the table studentcourses and keep grade on the table... then yeah it works.
Associative/Junction table between bus/student and bus/employee
needed
Overall many-to-many need to be resolved as part of modeling. and I agree with Thorsten, I want to see all fields in all tables including the FK's and I've done enough to know the CASE tools allow it.
and while 1-1 relationships look good for 4/5th normal form. they generally are not practical anymore unless the truely represent a separate concept. So I may have a vehicle table for a vehicle database but I may also have a table for car attributes vs motorcycle attributes vs truck vs boat etc... but vehicle is the primary in this case there so little reason to separate out high school I just don't see the long term value of keeping the object separate (but maybe I just lack vision).
You'll learn that in ERD's the cardinality of the relationships between the data is THE MOST IMPORTANT (following datatype/size/scale precsion). Eliminating M-M relationships is a must. and everything really boils down to 1-M or 1-1 when your done.
Not sure what the line between the school/bus implies.... the buses are owned by the whole system... maybe you need a "System" table tie that to the schools and buses to the system. that way if you support multiple school systems you know which buses belong to what system and what schools are in what system...
Usually in self realtionship tutorials it is taught in a subordinative way. Eg.: employee X subordinated to employee Y.
I have this scenario bellow where the related players are actually the same person but with different accounts.
So I don't know whether this is right to use self relationship in this case.
(aka: also known as)
aka_id ----> id_player
One player account is not subordinated to another. Players can have multiple accounts but I'm willing to relate them so I can tell they belong to the same person. In the real scenario, there is no master account to relate them to. this is a NON-SUBURDINATIVE scenario.
I thought of not using relationship in this case and insert a random hash key tag to the aka column:
380 | player120 | ae65a3f01a
500 | player430 | ae65a3f01a
The question here is:
Is it right to use self relationships in non-subordinative scenarios?
From the way you describe the problem, you have two entities: players and aka (which I will call nicknames). These are two separate entities, and that usually suggests three tables:
Players
Nicknames
PlayerNicknames
The third table is a junction table that combines the first two. You might be able to put all the information you need about Nicknames in PlayerNicknames -- that is fine. However, if you have a requirement that all nick names be unique, then you definitely want a third table.
My guess is that you have a player name that is automatically a nick name. Great. When you create a player, also create an entry in the nicknames.
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)