Translating diagram to SQL Database - sql

I'm having trouble seeing how I should translate this diagram into my database with tables. I'd like to add that I'm very new to this. This is a picture of an example that I want to translate into my SQL Database:
I'm not really sure how a diagram like this could look in my SQL Database, haven't really worked with inheritance. Would really appreciate if someone could demostrate how this could look with tables in SQL.
Thanks.
EDIT:
create table Person(
IDCode CHAR(10) UNIQUE NOT NULL,
primary key (IDCode),
);
create table Student(
IDCode CHAR(10) UNIQUE NOT NULL,
Name VARCHAR(15),
Course VARCHAR(15)
primary key (Name),
foreign key (IDCode) references Person (IDCode)
);
create table Teacher(
IDCode CHAR(10) UNIQUE NOT NULL,
Name VARCHAR(15),
Course VARCHAR(15)
primary key (Name),
foreign key (IDCode) references Person (IDCode)
);
create table StudentTeacherRelationship(
StudentName VARCHAR(15),
TeacherName VARCHAR(15),
primary key(StudentName,TeacherName),
foreign key(StudentName) references Student (Name),
foreign key(TeacherName) references Teacher (Name),

It means:
a person has a id number
both students and teachers are persons and they have their id information in person table, and one student/teacher has only one id
a student can have many teachers
a teacher can teach to many students
so there should be 4 tables(just psudo pseudo code to give you an idea):
person table:
id_person, (the primary key)
real_id (the real id, can be anything)
student table:
id_student,
id_person,
name,
other_stuff
teacher table:
id_teacher
id_person,
name,
other_stuff
a techer_student table (which make it many to many)
id_student
id_teacher

There are several ways to deal with inheritance situation in databases, JPA, for example, defines 3 strategies for inheritance in databases, these are: Single Table, Table for Class and Joined, they are all best described (including table/class examples) in the following link

Related

Composite Keys: Foreign Keying and Primary Keying [duplicate]

This question already has answers here:
Foreign key relationship with composite primary keys in SQL Server 2005
(3 answers)
Closed 2 years ago.
I am now working on a new exercise and have been given the whole ERD, just have to make the database and do some queries. A note was given that Rates table has a Composite Primary Key. I know how to make Composite Primary Keys
CONSTRAINT [name] PRIMARY KEY ([Col1],[Col2]) Col1 is an Int, Col2 is a Varchar
This table is then foreign keyed into the main table. To my knowledge there is no way to do this. Does anyone happen to know if there is a way?
Here is an example for composite keys. The database contains companies identified by some code for instance the EIN in the USA. The companies have departments and each company can decide for unique codes to identify their departments. Company A may use BD for their buying department, while company B uses BD also, but for their base department. Then each company has employees and each company uses some employee number to identify them. Employee #123 in comapny A is another person than employee #123 in company B. One employee works in one department in one company.
create table company
(
company_no decimal(9,0),
company_name varchar(100),
primary key (company_no)
);
create table department
(
company_no decimal(9,0),
department_code varchar(20),
name varchar(100),
primary key (company_no, department_code),
foreign key(company_no) references company(company_no)
);
create table employee
(
company_no decimal(9,0),
employee_no decimal(9,0),
first_name varchar(50),
last_name varchar(50),
department_code varchar(20),
primary key (company_no, employee_no),
foreign key(company_no, department_code) references department(company_no, department_code)
);
We could also add a constraint
foreign key(company_no) references company(company_no)
to the employee table, but that would be superfluous, as we already have the constraint on a department belonging to a company.

how to add constraint with columns in external tables

An easy way to explain my problem is this:
I want to create a table that will contain the information about the subjects that will be dictated in a school. The columns must be:
create table program( teacher varchar(20) references teachers(name),
classroom varchar(20) references classrooms(id),
dtime datetime)
In each one of the tables teachers and classrooms exists a column named 'subject', corresponding to the subject that is dictated by a teacher and the subject that is taught in a classroom (imagine there's no more columns in those tables).
Now, I want to create a constraint in the program table that doesn't let me insert a row where the subject dictated in the classroom is different from the subject dictated by the teacher.
You want to use composite foreign keys. This is going to be simplest by putting the subjectId in the programs table. Here is the example for teachers:
create table teachers (
teacherid int identity(1, 1) primary key,
name varchar(255) not null,
subjectid int references subjects(subjectid),
unique (teacherid, subjectid)
);
create table programs (
programid int identity(1, 1) primary key,
teacherid int references teachers(teacherid),
classroomid int references classrooms(classroomid),
dtime datetime
subjectid int references subjects(subjectid),
foreign key (teacherid, subjectid) references teachers(teacherid, subjectid),
foreign key (classroomid, subjectid) references classrooms(classroomid, subjecdtid)
);
If you don't put the subject in the programs table, then you will need to use a user defined function for the constraint. This seems like a simpler solution.

Foreign key referring to more than one primary key values(from one table) - Oracle SQL PLUS

I am still a beginner in SQL and i'm facing an issue. hope you can help me.
I have a table called Department where it has an attribute DEPARTMENT_NO as its primary key.
CREATE TABLE DEPARTMENT(
DEPARTMENT_NO INT NOT NULL,
NAME VARCHAR(25) NOT NULL,
LOCATION CHAR(15),
PRIMARY KEY(DEPARTMENT_NO));
I have another table called Doctor where it has an attribute DNUM as a foreign key referring to DEPARTMENT_NO :
CREATE TABLE DOCTOR(
DOCTOR_ID CHAR(9) NOT NULL,
DNUM INT NOT NULL,
NAME VARCHAR(20) NOT NULL,
DOB DATE,
SPECIALTY VARCHAR(20) NOT NULL,
SALARY INT,
CITY VARCHAR(15),
STREET VARCHAR(15),
START_DATE DATE,
PRIMARY KEY(DOCTOR_ID))
FOREIGN KEY(DNUM) REFERENCES DEPARTMENT(DEPARTMENT_NO));
A doctor can be working in one or two departments. So, if I have a doctor working in department 1 and 4 (the values for DNUM will include 1 and 4).
I initially chose the data type of DNUM to be INT(same as DEPARTMENT_NO data type). But INT is not ideal for multiple values.
What should the data type be? or what other solution i have if,for example, I run a query for returning the name of the doctors working in department 4.
The query should return all the names of doctors working in department 4(only) and the ones who work in multiple departments(including 4).
Thanks very much in advance and sorry for the long message.
The standard way to represent a "many to many" relationship is via a "junction" (aka "link") table:
CREATE TABLE DOCTOR_DEPARTMENT (
DOCTOR_ID INT REFERENCES DOCTOR(DOCTOR_ID),
DEPARTMENT_NO INT REFERENCES DEPARTMENT (DEPARTMENT_NO),
PRIMARY KEY (DOCTOR_ID, DEPARTMENT_NO)
);
Note the key on {DOCTOR_ID, DEPARTMENT_NO}, which ensures the same doctor cannot be connected to the same department twice.
It also implicitly creates a composite (aka. "concatenated") index on these fields in that order, which makes it very quick to find departments of a given doctor (via an index range scan). If you need to query in the opposite "direction" (for doctors of the given department), flip the order of fields. If you need both queries, then you'll need both indexes (i.e. you'll need to create one index explicitly).
Consider adding ORGANIZATION INDEX clause, if you need just one of these indexes.
You need an additional table called doctor_department
create table doctor_department
(doctor_id integer references doctor(doctor_id) not null,
dnum integer references department(dnum) not null
)
You can create another table with relation to these 2 tables
Say,
Create table Dept_Doctors(
ID int not null,
DOCTOR_ID char(9) not null,
DEPARTMENT_NO INT NOT NULL,
PRIMARY KEY (ID),
FOREIGN KEY(DEPARTMENT_NO) REFERENCES DEPARTMENT(DEPARTMENT_NO),
FOREIGN KEY(DOCTOR_ID) REFERENCES DOCTOR(DOCTOR_ID));
You can join the 3 tables and get the desired result.

How do I translate relationships (that have attributes) into relational schema/sql?

I am relatively new to database design.
I've recently learnt that relationships in EER can possess attributes, and thus, have constructed the following entities.
LibraryMembers
(memberID)
Books
(bookID)
The two entities are connected through the relationship "reserve", each book able to be reserved by 0 to 1 LibraryMember, and each LibraryMember being able to reserve 0 to many books.
Now, here comes the problem. I have assigned attributes such as time and date to the "reserve" relationship, and I have no idea how to translate this into relational schema. The relationship between LibraryMembers and Books is not a many to many, is it still possible to create a table called "reserve" to link them?
(I've been taught that an additional table is only created when the relationship maps from a many to many EER)
Help would be very much appreciated, thank you.
You can map members and books in reservations like this
CREATE TABLE members(
member_id INT,
member_name VARCHAR(64),
PRIMARY KEY(member_id)
);
CREATE TABLE books(
book_id INT,
title VARCHAR(64),
PRIMARY KEY(book_id)
);
CREATE TABLE reservations(
reservation_id INT,
book_id INT,
member_id INT,
reservation_date DATETIME,
PRIMARY KEY(reservation_id),
CONSTRAINT FOREIGN KEY (book_id) REFERENCES books (book_id),
CONSTRAINT FOREIGN KEY (member_id) REFERENCES members (member_id)
);
But you still need to implement logic that prevents a book to be reserved twice at the same time as #Najzero commented.

Mysql: enum confusion

I have an employee table, employee has interests, so the table can be designed like this:
create table emp(
id int(10) not null auto_increment,
name varchar(30),
interest varchar(50),
primary key(id)
);
or this:
create table emp(
id int(10) not null auto_increment,
name varchar(30),
interest enum('football','basketball','music','table tennis','volleyball'),
primary key(id)
);
The number of interests can be about 50.
How should i design the table? Should i use enum or others ?
Edit:
Thanks for your reponse.
Assume that a person can be a Mr. or Madame or Ms.
I make a drop down list in PHP.
<select name="role">
<option value="Mr.">Mr.</option>
<option value="Ms">Ms</option>
<option value="Madame">Madame</option>
</select>
And for the DB part, I can do this:
create table emp(
id int(10) not null auto_increment,
name varchar(30),
role varchar(50),
primary key(id)
);
or this:
create table emp(
id int(10) not null auto_increment,
name varchar(30),
role enum('Mr.','Ms.','Madame'),
primary key(id)
);
In this context, which is better?
There's a third option, creating an additional table for holding the interest values.
INTERESTS
interest_id, int, primary key
interest_value, string/varchar, unique constraint (to stop duplicates)
Many-to-Many Relationship?
However, if you want to support an employee having multiple interests you'll need a third table. This is a many-to-many relationship - the third table would sit between the EMPLOYEES and INTERESTS tables, and have foreign key relationships with both.
EMPLOYEE_INTERESTS
employee_id, primary key, foreign key to EMPLOYEES.id
interest_id, primary key, foreign key to INTERESTS.interest_id
One-to-Many Relationship?
If an EMPLOYEES record can only ever have one INTEREST, then you only need to update the EMPLOYEES.interest column to have a foreign key relationship with the INTERESTS table.
EMPLOYEES
interest_id, primary key, foreign key to INTERESTS.interest_id
You should really make 3 tables, assuming that an employee can have multiple interests. (Your current design limits each employee to 1 interest.) Something like this:
Employee (emp)
-------
id
name
Interest
-------
id
description
Employee_Interest
--------
employeeID
interestID
Regarding the edit, I'd say the enum is the better of your 2 examples as it limits you to predetermined allowable values. But many would argue that you should make a lookup table (Role with id and description) even for that