I have tables with property ownership records of people, people personal information, their residence city only, their family number. family numbers are also multiple, one family number from father family, second may be from mother family etc.
A person can get property from his father or mother through inheritance. As well through inheritance or gift from his grand parents or he may buy his own.
Some of limitations are
data is not standardized and person name comes up with variations
for example
Alex full name is Alex Ford
his father name is Henry ford and
Mother name for example Jessica Alba
Now ownership records could have different entries some of them could have
where Alex is written with relationship of his father Henry, First name Alex and last name Henry.
At other place it is written with full name "Alex ford" and last name Henry Ford and some other places it is written like Alex last name Jessica.
Property owner name is written in the form which represent from where he is getting that property, In case inheriting from mother then her mother name is written in his last name.
Problem becomes worst when there exist exact duplicate names with same father name, person could be identified by traversing back in family tree and checking mother name or grand parent names
How could i could find approximate match of person in MS SQL 2008 R2. or how this could it be approached?
Related
I have a SQL table Users, with each user having multiple educational institutions. E.g. John may have gone to Harvard in 2019, Oxford in 2020 and Cambridge in 2021.
Since this is a one to many relationship the most obvious solution would be to create a second table - UserEducation which references userID.
However, I feel a bit wrong about this approach as a user's educational institutions are directly a part of their profile rather than a new set of data. Is there any other way to do this (which somehow keeps the idea of separate entries for each user profile) or is the way I am doing it fine?
I vote for 1:many -- 1 user to many institutions. I vote against many-to-many because of the year being involved.
The 1:many table would look like:
John may have gone to Harvard in 2019, Oxford in 2020 and Cambridge in 2021.
John Harvard 2019
John Oxford 2020
John Cambridge 2021
Leslie Cambridge 2019
"John" would probably be an "id" for JOINing to the Persons table, where you have one row for John and one for Leslie.
You may do likewise for Harvard and a different id -- if you have more information about the schools. (If there is no further info, don't bother.)
If you don't need to search or sort or Join on school, the Ali's suggestion of a JSON column with all the schools for each user, in the Persons table, would work fine.
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...
So, I'm new to BO Web Intelligence, so I'll try to explain my problem. I created a simple table below to represent my report. "Tom Smith" is a section break, which is followed by Ann Marie, etc. There is also a break on "Name", which represents clients. Client names are listed more than once since each has multiple "goals" and each goal was touched multiple times (time entered working on goals).
Basically, I want to find all the unique goals for each client in the "Goal" column of the report and see if there is a match in the "GoalTime" column. Goals in the "GoalTime" column are supposed to be the same goals as the "Goal" column, so if there is a goal that doesn't match, or an extra goal, this needs to be flagged and counted to produce totals, percentages, etc.
Is there a way to only display unique values for each client in "Goal"? I know there are ways of playing with the query, universes, filters, etc, to try to create the goal column so that only one goal type is displayed, but I'm looking for a simpler formula-based solution. I'm hoping there is some creative use of a "unique" or "distinct" function, or a creatve way of using "match" to achieve this, which can then be combined with flags to create a count.
Any help would be greatly appreciated!
Tom Smith:
Name: Goal: GoalTime:
Tim Buy a House Buy a House
Tim Find Employment Find Employment
Tim Buy a House Buy a Car
Tim Find Employment Find Employment
Chris Find Employment Find Employment
Chris Buy a House Buy a Car
Chris Buy a Car Buy a House
Chris Buy a Car Buy a Car
Ann Marie:
Name: Goal: GoalTime:
Tom Buy a House Buy a Car
Tom Find Employment Find Employment
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
Suppose we want to store university courses and their entry requirements in a database. So for example BSc Mathematics, BSc Fine Art, MSc Computer Science etc.
Each course has it's own set of requirements, and might have a different number of non-shared requirements. For example, to be eligible for the BSc Maths you might need a A in Maths and a B in Physics. Whereas the BSc Fine Art might require a A in Art and that the user has a portfolio. The MSc might have a minimum age of 25 etc.
Suppose we then have a student who has his own set of attributes. So they might have a A in Maths and a B in Physics and a C in Chemistry and be of age 19.
How can we structure our database such that it is geared towards efficient lookups. And given a student's attributes how can we retrieve all the courses which they are eligible for?
On an abstract level we are looking for all items whose requirements are a subset of the attributes given.
I'd like to implement this in MySQL. The schema could be:
courses
id
name
requirements
course_id
subject
grade
But then how to do query the table to get all eligible courses when the student has a A in Subject 1, a B in Subject 2 etc.
For a course to be a match, each one of its requirements must be satisfied.
Thanks in advance, I hope my explanation isn't too confusing.
Okay. I think you need a subject list, with a bunch of subject id's.
Now, for the query, you will start with (or generate) a bunch of subject id's and grades. The easiest thing to do is to make this into a temporary table with those columns.
Now, you can do your query, joining the subject id's, and adding a "where temp.grade <= course.grade.
The trick to this is to count the rows. If it has the same number of rows as the course has specified, then you have a successful match.
Is that enough to get you going?