I have a question about transfering a weak entity from an e-r model to sql tables.
Specifically i am using mysql.
Lets say i have the table hotels in which i have primary key id for each hotel, named id.
Then i want to create a table for rooms. A room is considered weak entity because it cannot be identified without refering to a hotel and because it cannot exist without a hotel.
So lets say that rooms contain columns with data and two other columns.
First column is a foreign key to hotel id and a second column which is a room number.
Note than many rooms can have the same number but no room in the same hotel can have the same number. So this is a way to identify a specific room.
How can i put this into a table?
I cannot declare the number as unique because its not unique, i cannot declare it as a primary key either for the same reason. So am i creating a table without primary key?
Also, the foreign key "hotel_id" is a unique key since it is a primary key in hotels table.
I suppose i won't having problems using many rooms with the same foreign key.
To sum up.
My question is how to create the table rooms, is there any way to automatically identify each room except the obvious (identifying the room by selecting a room with specific number and hotel_id)?.
Thank you in advance.
The primary key in the Rooms table is composed of two columns (HotelID, RoomNumber). That combination must be unique for your data model to operate correctly.
You create a table rooms with an id column as primary key. This table has also the columns hotel_id (FK to hotels) and room_number. You define an unique index over (hotel_id, room_number).
That's all ;)
Related
I have problem related to my database. I have user table, which I don't think I need to explain but then i got game table. After each game it will save record of which user was winner and which was loser. What type of relation should I use? I was thinking about many to many. User can have many games and also ech game can have same user winning multiple game as well as losing many games.
Am I right?
A foreign key is a column or a set of columns in one table that references the primary key columns in another table. The primary key is defined as a column (or set of columns) where each value is unique and identifies a single row of the tabl
I am trying to figure out relationships between my tables and the notion of how it all inter-relates is not clear.
Lets say I have a Person table (first name, last name, etc) where the Primary key is social security number.
I also have a Fireman table that has just 2 columns -- date when joined the fire company, and a unique fireman number. The 3rd column would be a link back to the Person table.
Initially, I made SSN in the Fireman table to be a foreign key linking to SSN in the Person table. But doesnt it imply that every time I create a new Fireman, I can re-use the same SSN over and over? The foreign key constraint would not be violated -- so its "all good" -- but its not what I want. Does it make sense? I dont want to allow for different unique Fireman numbers all sharing the same SSN number. So how do I set this up -- whats Primary, whats foreign, whats one to one and whats one to many.
A key can be primary and foreign all at the same time in a one-to-one relationship.
You can scrap your primary key from the Fireman table, and just use SSN as the unique key. Since it's one-to-one, there's no need for a separate identifier.
Alternatively, you could create a unique index on the column SSN in your fireman table. That would prevent duplicate entry.
Note that data validation, relationships and indexes are all separate things. You can use indexes and relationships to validate data, but you can also use different concepts, like constraints.
I have read somewhere here that having primary key in each every table is a good thing to do... Let me say I have two tables "student" and "student_details" and i am using INNODB
"student" has a few columns like - student_id(Primary Key), student_name
"student_details" has a few columns like - student_id(Foreign Key), Address, Phone, Mobile, etc..
Do "student_details" still need a primary key?
Whether you know it or not, what you are doing is column partitioning the table. You can have studentdetails.studentid be both a primary key and a foreign key. No problem with that. So, you can have a primary key in the table.
There are several reasons to do column partitioning, usually related to performance on commonly used columns or to create rows with more than the maximum number of columns. I doubt either of these apply in your case.
In fact, given the nature of the data, the studentdetails table is actually storing a "slowly-changing dimension". In simpler language, students move, so their address changes. Students change their telephone number. And so on. What you should really have is an effective and end date for each student details record. Then you can add an auto-incrementing primary key (which is what I would do) or you could declare studentdetails(studentid, effdate) as the primary key.
I'm trying to understand relationships and naturally questions appear.
What does referencing table mean and what does referenced table mean? In the above example which one should be referenced and which one referencing?
Lets say for the sake of argument that the settlements table is a child table (settlement cannot exist without a country). Should this child table be referencing or referenced?
I prefer not to open a new question for such a little question:
What does that Mandatory checkbox mean? Does it mean that the settlements table is required or that country_id is required? Or maybe something else?
Found a really good explanation in the PostgreSQL documentation.
Say you have the product table that we have used several times already:
CREATE TABLE products (
product_no integer PRIMARY KEY,
name text,
price numeric
);
Let's also assume you have a table storing orders of those products. We want to ensure that the orders table only contains orders of products that actually exist. So we define a foreign key constraint in the orders table that references the products table:
CREATE TABLE orders (
order_id integer PRIMARY KEY,
product_no integer REFERENCES products (product_no),
quantity integer
);
Now it is impossible to create orders with product_no entries that do not appear in the products table.
We say that in this situation the orders table is the referencing table and the products table is the referenced table. Similarly, there are referencing and referenced columns.
The referenced table is the 'parent' table.
The referencing table is the 'child' table.
The clue is in the SQL DDL e.g.
ALTER TABLE Settlements ADD
FOREIGN KEY (country_id)
REFERENCES Countries (id);
Settlements references Countries, implies Countries is referenced.
settlements table (with the country_id field) is referencing to countries table (the id field)
I suppose mandatory checkbox has nothing to do with the relation. It is simply a not null constraint on the field. But you should consult the user manual of MySQL Workbench on this one.
The Mandatory check box, if it seems to have no effect in generated SQL, has some effect on the graphic. If unchecked, you can see little circle at concerned relation line extremity (for Relationship notation crow's foot).
It means that the foreign key could be null, aka. not mandatory.
One country can have many settlements so the country table is the referenced table and the settlement table is the referencing table. I don't know about mandatory field.
I am designing a data model for tourism-site. I have a table for places (countries, resorts, hotels) and a table for tours. The tables are pretty different in fields so the cant be merged into one. Both of them have usual auto_increment as id. Places and tours have photos so there is a third table for photos. This table has 'parent' field in which I plan to store the parent (place or tour) id.
Which is the best way to design these tables? One table for all photos and two tables as 'parents' for the photos. For now I have added 'parent_type' column to photos table, so when my script displays a tour it calls photos by its (parent) id and type (parent_type) 'tour' from the photos table...
Upd:
Is there a more graceful solution? With just 3 tables and no 'parent_type' column?
(cant post a diagram... here's the link http://share.xmind.net/yentsun/tourism-site-data-model/)
Country, hotel and resort are sub-type of a place. The place table contains all fields common to places, while country, hotel and resort tables contain fields specific to each one. One tour contains many places, one place can be a part of many tours.
Here is example code for Place and Country -- it is T-SQL, but you'll get the idea.
CREATE TABLE Place
(
PlaceID int NOT NULL ,
Type varchar(2)
);
ALTER TABLE Place
ADD CONSTRAINT PK_Place PRIMARY KEY CLUSTERED (PlaceID ASC)
;
ALTER TABLE Place
ADD CONSTRAINT FK1_Place FOREIGN KEY (ParentID) REFERENCES Place(PlaceID)
;
CREATE TABLE Country
(
PlaceID int NOT NULL
);
ALTER TABLE Country
ADD CONSTRAINT PK_Country PRIMARY KEY CLUSTERED (PlaceID ASC)
;
ALTER TABLE Country
ADD CONSTRAINT FK1_Country FOREIGN KEY (PlaceID) REFERENCES Place(PlaceID)
ON DELETE CASCADE
ON UPDATE CASCADE
;
UPDATE after comment
Sorry, four tables is my best for this one.
There are no Parents involved - you just have photos with two atttributes - Place and Tour.
So use a Photos table with two foreign keys, one for Tour, the other for Place. And then of course
a Tours table and a Places table.
If you need to know which Tours went to which Places, deal with it directly with a Tour_Places table
which justifies itself independently.
As for "Parentness", this solution still lets you identify, for a Tour (or Place), which Photos are associated.
I had the same situation a while ago. I used a 'set' type for the parent_type. Never store names for your type, use integers because they can be read much faster. And also place indexes on your foreign keys.