Database Design
Is this a bad design for a relational database. I don't see anyone doing examples that look like this.
But considering that an interview is comprised of all the different tables I have linked to the interview table it seems valid.
Except of OH Number (Oral History Number.) An oral history from one narrator may be comprised of different interviews conducted at different dates. Each individual interview is assigned a unique ID that make op a series that is assigned 1 OH Number.
I'm also thinking of putting "Interviewer, Indexer, and Transcriptionist in the same table.
I created the following mock-up for you given the details you have provided. I believe this will be a good starting place. You have an interview object and a person object. You have a joining table of InterviewPerson. This allows you to have one to many person objects per interview.
I want the database to be robust enough that if a researcher called in
and wanted all the interviews conducted by John Doe, on Race
Relations, I could pull a query for it.
To do the aforementioned as you have stated, you would join both the Interview table and the Person table on the InterviewPerson table, and then you would limit your query of that joining based on the Person.firstName, Person.lastName, Interview.topic (or title).
Please note, this is a rough draft but should be a good general idea and start.
Database Design Redux
This is what I came up with based on your suggestions.
Related
I need help to do a good database analysis and learn
I have two tables:
Patient
Specialist
These two tables have column names in common:
first_name
last name
level of education
e-mail
phone
Is it necessary to create a new table with these elements in common and that they are related to the other two tables?
or
It is not necessary in this case. I try to make a good analysis and apply good practices
PICTURE BELOW HERE
ER_Model
These are just suggestions and not an answer.
Kind of very small questions, but very difficult to answer because answers may contradict each while explaining.
explenation
That depends on your requirement actually. for example,
How many records that you going to manage inside a table?
if it is comparably small, you can keep both patients and specialists on the same table with a flag to categorize them.
comparably big, you can keep Patient and specialist tables separately with common fields inside each table.
What level of segregation do you expect from your system?
For example in microservices, keeping two different tables is better to isolate each service. But that also depends on the architecture you're going to use.
But separating common fields into a different table and managing those fields are not necessary like what we are doing with OOP concepts. because unwanted DB relations give you an extra burden to your queries.
This is my idea. You can have many from others :)
Today I was designing a database for a potential personal project of mine. Since I couldn't decide what would be a better option I asked my teacher Databases, unfortunately he couldn't tell me which of the two options is better than the other and why.
I designed the database for a dummy data generator. Since I want to generate multilangual data I thought of these tables. (But its a simplification of the tables).
(first and last)names: id, name
streets: id, name
languages: id, name
Each names.name and streets.name originates from a language, sometimes a name can have multiple origins (ex: Nick is both a Dutch as an English name).
Each language has multiple names and streets.
These two rules result in a Many-to-Many relationship. At the moment I've got only two tables, but I know I will get between 10 and 20 of these kind of tables.
The regular way one would do this is just make 10 to 20 Many-to-Many relationship tables.
Another idea I came up with was just one Many-to-Many table with a third column which specifies which table the id relates to.
At the moment I've got the design on my other PC so I will update it with my ideas visualized after dinner (2 hours or so).
Which idea is better and why?
To make the project idea a bit clearer:
It is always a hassle to create good and enough realistic looking working data for projects. This application will generate this data for you and return the needed SQL so you only have to run the queries.
The user comes to the site to get the data. He states his tablename, his columnnames and then he can link the columnnames to types of data, think of:
* Firstname
* Lastname
* Email adress (which will be randomly generated from the name of the person)
* Adress details (street, housenumber, zipcode, place, country)
* A lot more
Then, after linking columns with the types the user can set the number of rows he wants to make. The application will then choose a country at random and generate realistic looking data according to the country they live in.
That's actually an excellent question. This sort of thing leads to a genuine problem in database design and there is a real tradeoff. I don't know what rdbms you are using but....
Basically you have four choices, all of them with serious downsides:
1. One M-M table with check constraints that only one fkey can be filled in besides language and one column per potential table. Ick....
2. One M-M table per relationship. This makes things quite hard to manage over time especially if you need to change something from an int to a bigint at some point.
3. One M-M table with a polymorphic relationship. You lose a lot of referential integrity checks when you do this and to make it safe, have fun coding (and testing!) triggers.
4. Look carefully at the advanced features in your rdbms for a solution. For example in postgresql this can be solved with table inheritance. The downside is that you lose portability and end up in advanced territory.
Unfortunately there is no single definite answer. You need to consider the tradeoffs carefully and decide what makes sense for your project. If I was just working with one RDBMS, I would do the last one. But if not, I would probably do one table per relationship and focus on tooling to manage the problems that come up. But the former preference is about my level of knowledge and confidence, and the latter is a bit more of a personal opinion.
So I hope this helps you look at the tradeoffs and select what is right for you.
I'm trying to refactor some parts of a legacy database schema and am having trouble with coming up with the correct design.
The entities in question are:
samples, papers, studies
papers are associated with many samples
studies are associated with many samples
papers and studies have their own attributes not compatible with each other
samples can be associated with multiple papers and multiple studies
However, this separates out the grouping of papers and studies.
Here's how it looks:
An alternative I thought of was since both papers and studies are just grouping the samples together, I can combine these as one, and have FK from the group into their respective paper/study table.
Here's how it looks:
I'd like to know if the designs look reasonable and if there are any tradeoffs between the two different designs? Also are there alternatives to modelling the relations?
I think the first design is a right one. There are two M:M relations, Paper - Sample and Study - Sample. They are different by domain logic, so there is no sense to combine them in one relation and introduce extra entities for that purpose. First schema is a good normalized one. What is your goal? What problems do you try to resolve?
the schema doesn't have explicit grouping ...
OK, if you do require Group as a separate entity, your design could look like this:
The problem is, Group entity is weak. It is hard to propose any attribute to this entity except for ID. It is not handy to work with this scheme thought. When user edits paper's group, you have to choose, how to handle this situation. Should all other papers\studies 'see' this change too, or you have to create\search edited group and assign it to paper. I think it is wrong way to take if there is no additional business logic related to groups. Usually, when weak entities appear in a design, it means that set of abstractions has been chosen not properly. At the moment, I don't see how to justify Group entity.
I am new speaking about modelling databases. But I give my best to learn as much as possible by my own. Therefore I want to ask you, whether my first attemp make sense for the following example:
So I modeled the database as followed:
The databse is about medicine. There are several medicine items which should be dosed depending on the age of the patient. Every medicine item can belong to one ore more groups (or none).
This is just a test case to show what I learned so far. So every tip to improve my skills is welcome!
Thanks a lot!
The relationtable table name is just a placeholder, right? It should be more descriptive, maybe dosage?
Something tells me that age ranges will greatly vary. Some medicines have different rules for children under 3 years, other under 5, 10, and so on. Instead of creating a separate table, just include two extra columns (start and end) in relationtable. It will be much easier to query and I won't consider this a denormalization.
Talking about age and dose tables - get rid of unit column and use normalized, fixed unit. Years for age and mg for doses. This will make querying much simpler. Don't be afraid to use floating numbers, e.g. 0.5 to represent six months.
I agree with what Tomasz write and would like to add:
If the relationtable is the correct way to go depends on some knowledge not contained in the table. It sounds strange that one medicine can be part of different groups and that the dosage depends on that relation. I would expect that a medicine can belong to different groups (resulting in a medicine2group mapping table) and that their exist different dosages depending on the age for a medicine (so you get dosage4age table, combining the existing age and dose tables. That new table would directly reference the medicine)
Which version is correct can not be told from the table alone.
As a rule of thumb: I get skeptical when a table without a proper name and concept links more then two other table. It is possible but often hints at concept hiding somewhere.
In order to check if the proposed model is correct, ask the business experts if the table is still correct if you replace Antibiotika with Superantibiotika in one of the first three rows. If it is, this means that the dosage does not depend on the group and should not be linked to it, so the model proposed by me would be more correct.
If the altered table is not correct, your model might be the better one, but I would listen carefully about the explanation why it isn't correct.
Hi I am doing an assignment on ER modelling and there is a part that I'm stuck on, here is an extract:
Patient is a person who is either admitted to the hospital or is registered in an outpatient program. Each patient has a patient number (ID), name, dob, and tele. Resident patients have a Date Admitted. Each outpatient is scheduled for zero or more return visits, which have data and comments. Each time a patient is admitted to the hospital or registered as an outpatient, they receive a new patient number.
I can't do the last section bolded. I have attempted the question: http://tinypic.com/r/358dus9/4
Also if anyone can check if I've done it correctly, would be highly appreciated thanks!
Sometimes assignments also contain "information" that is pretty much immaterial.
The purpose is precisely to learn to filter out the 'real' information from the noise.
(With the caveat that there are dozens and dozens of ER dialects, and each has its own peculiarities,) ER does not have a way to express the information that "attribute x in entity y is to be autogenerated by the system.". For this reason, and as far as the actual ER modeling is concerned, your bold phrase is just noise.
I agree with Erwin on this one. I'll add that not having to have a consistent structure for the patient means that you don't have to create another table for the patient, you can just put it into the ER case directly.
Generally, this is a bad practice however. In reality, you would still have a regular patients table with identifiable patients over several visits. Then again, this is a class and as we all know, the #1 rule is not to disobey the teacher (no matter how insane it is). The real lesson here is to learn how to take requirements, have them clarify the requirements, explain the consequences if they don't follow your advice on how the data will be modeled and then go ahead with whatever they say as they have the final say as the client.
Depends on the course that you're taking, as well. Microsoft SQL Server/SQL Express has the autonumber setting possible, while Oracle does not feature this (although it's accomplished through this). Insofar as the modeling is concerned, there is no way to model that requirement specifically, as far as I know.
Entity-relationship diagrams are used to model the relationships and the data itself as it exists. What you're looking for is more of a UML approach to describing the process in which it has data created for that field.