table users
userId name company company_address url
1 Joe ABC Work Lane abc.com
2 Jake ABC Work Lane xyz.com
3 tom XYZ Job Street abcde.com
4 jim XYZ Job Street fexyz.com
the second table
id name favourite_food_1 favourite_food_2
1 Sam Curry Steak
2 Lucy Chicken Burgers
if the table don't fit for the 1NF,why? thank you.
The first table fits 1NF. The second does not - there's a repeating group with the two favorite food fields. Not everyone necessarily has two favorite foods (or any favorite foods at all, or has 3+ favorite foods), so those fields are nullable, and therefore causes the table to fail 1NF.
Doesn't 1NF only mean each value has to be atomic? In other words, every relational database table is in 1NF, since sets of values aren't allowed.
1NF sets the very basic rules for an organized database:
1: Eliminate duplicative columns from the same table.
2: Create separate tables for each group of related data and identify each row with a unique column (the primary key).
The problem with your Database tables is "Name"(duplicate column).
Every relational table always satisfies 1NF. A SQL table is in 1NF if it accurately represents a relation, i.e. it has unique column names and doesn't permit nulls or duplicate rows.
Related
Please explain to me the type of relationship portrayed using this flowchart:
Also, explain the different notation for a different type of relationship i.e
One-to-one, One-to-many, Many-to-one, Many-to-many. And what about the participation i.e Total or partial
A record in table 1 maps to exactly 1 record in table 2. but a record in table 2 can map to 1 or many records in table 1.
for example if if table 1 is records of people, and table 2 is records of places of birth. each person in table 1 can only have one place of birth, but a place of birth can have many people
I'm struggling to find the best way to store entities with user-defined fields. I would like to be able to do queries on these fields, so I feel NoSQL may not be the best approach. Constant schema migrations seems like a pain, especially since different users may want different fields on similar entities.
For example, let's say we have an entity representing a village. The village has a name (West Town), a type (village), a population (114). The user may want to add their own attributes to the village, say, a nickname. This is not known up front, and may not be required for other villages.
The best technique I've come up with is a table for the entities, and then a separate table for "components" of the entities, consisting of: a component id, a foreign key to the entity it's on, the name of the component, and its value.
So, the village from the example would exist as:
Table 1 - Entity
ID
1
Table 2 - String Components
ID ENTITY_ID NAME VALUE
1 1 name West Town
2 1 type village
Table 3 - Integer Components
ID ENTITY_ID NAME VALUE
1 1 population 114
Then, if the user wanted to add a "nickname" to the village, they could push a button, select a string component, call it "nickname" and give it a value of "Wesson":
Table 2 - String Components
ID ENTITY_ID NAME VALUE
1 1 name West Town
2 1 type village
3 1 nickname Wesson
Then, when the entity needs to be displayed, we query the component tables for the entity ID, and display the information:
name: West Town
population: 114
type: village
nickname: Wesson
Is this crazy? It feels both sort of like an elegant way to represent a mutable schema in a relational database, and like trying to get around the whole point of a relational database. Is there a better way?
Answering my own question. This seems to generally be addressed using a pattern known as "entity-attribute-value" which is similar to what I've suggested.
The entities table could be a little richer, storing also information common to all entities, like "name" and maybe a foreign key into an "entity_type" table.
At its simplest, the attributes tables could be as above, with one for each data type.
https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model
I want you to know your opnion about this situation:
I have a table named "movie" with this colums
movie_id
name
price
...... etc
A movie can be available to rent, purchased or both.
If I want a movie available to rent and purchase the price change, for example:
Price for rent: $2.50
Price for purchase: $15.45
The question is:
Is better to make a duplicate in the table movie?
movie_id name price available_for ...... ........
1 300 $2.50 rent
2 300 $15.45 purchase
Or make another table adding the info of price and available_for? Like this:
Table Movie
movie_id name ...... .......... ..........
1 300
2 300
Table Movie_available_for
Id movie_id available_for price
1 1 rent $2.50
2 1 purchase $15.45
I want to know which is the best solution for this
Thanks!
Your relational approach might depend on what level of normalization you hope to achieve. Your question reminds me a lot of the Boyce–Codd normal form (BCNF) vs the 3rd normal form (3NF).
In fact, there is an example similar to your question on this wiki page: Boyce–Codd normal form (Wikipedia)
There is a lot of theory here, but it can many times come down to either what you feel the most comfortable with or whichever technique you can perform the most accurately.
Personally, in this specific case, I would go with the slightly more normalized form (your 2nd example). This is because, the "available_for" and "price" are related variables. If you end up adding more info about movies, that info is potentially going to be duplicated many times. If you add a third "availible_for" or different pricing schemes (1 day for $1.50, 5 days for $4), you will have very significant data duplication.
Besides, when it comes to code, it would be nice to have a movie object that has an array of nested "availible_for" (might name this something else like "offering" or something) objects.
I would suggest you normalize your available_for column as it is repeated and contains few fields only.Store that in another table and create a relation between two tables.
Movie_Available_type
id int, available_for varchar(50)
Then you can use either of two as pointed out by thoughtarray in above post.
I would go with:
Movie (movie_id PK, name, purchase_price, rent_price)
and make the pricing columns nullable. If you don't like nulls, you can decompose it into:
Movie (movie_id PK, name)
PurchasePrice (movie_id PK/FK, price)
RentPrice (movie_id PK/FK, price)
A question I got in my last interview:
You are given a Database of Employee details containing a id and date of joining column. Is the table in 1NF?
I was wondering if with date attribute, whether the schema can be in 1NF or not. How would the existence of date change the answer?
The whole Idea of the question was to trick you into thinking Date is not a 1NF column.
1NF specifies that all attributes store atomic values. Codd defines an atomic value as one that "cannot be decomposed into smaller pieces by the DBMS"[7] meaning a column should not be divided into parts with more than one kind of data in it such that what one part means to the DBMS depends on another part of the same column.
Simply put there should not be 2 values in the attribute of a single tuple.
This table does not satisfy 1NF. Because there are multiple phone numbers in a column.
Customer ID First Name Surname Telephone Number
------------------------------------------------------------------------------
123 Pooja Singh 555-861-2025, 192-122-1111
456 San Zhang (555) 403-1659 Ext. 53; 182-929-2929
789 John Doe 555-808-9633
To make the given table in 1NF we seperate the telephone number column into 2 seperate columns.
Customer ID First Name Surname Telephone Number1 Telephone Number2
---------------------------------------------------------------------------------
123 Pooja Singh 555-861-2025 192-122-1111
456 San Zhang (555) 403-1659 Ext. 53 182-929-2929
789 John Doe 555-808-9633
Unlike the 1st table as long as you store only 1 date, in a single column, your table will be in 1NF.
I am trying to design a Database for a Patient record.
I am stuck at one point when dealing with Medicine List.
"Table_Patient_Record" - is having a field - "Medicine_Ids" ...
and "Table_Medicine_Record" - having unique - "Id" & "Medicine_Name" ...
Now, my problem is, How to hold multiple(variable) "Id" of "Table_Medicine_Record" into "Medicine_Ids" of "Table_Patient_Record"?
Since, the number of medicines belong to a patient varies from other patients.
Then, how to design database so that from a UI we can Insert, Update and Select.
Thanks, I hope my question is to clear to understand.
If I'm correct, you have a database 'Patients' and 'Medicines'.
The easiest solution is to create a table 'PatientMedicines' that holds a userid and a medicineid.
This way you can connect multiple patients to multiple medicines and the other way around.
And still leaves the freedom that a patient does not need to have any medicine.
Hope this helps.
This seems like a many to many relationship to me. One patient can use multiple medicine, and a medicine can be used by multiple patients. Use a junction table that holds the patient id and the medicine id. Like this:
PatientId | MedicineId
1 1
1 2
2 1
2 3