Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
13 views

Projek UAS Database

The document describes the conceptual, logical, and physical database design for a university database system. It includes entity identification, relationship identification, attribute specification, normalization, integrity constraints, SQL scripts for objects like sequences, functions, views, and sample queries.

Uploaded by

raymondniu31
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views

Projek UAS Database

The document describes the conceptual, logical, and physical database design for a university database system. It includes entity identification, relationship identification, attribute specification, normalization, integrity constraints, SQL scripts for objects like sequences, functions, views, and sample queries.

Uploaded by

raymondniu31
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 16

LAPORAN PROJEK UAS DATABASE

DOSEN MATA KULIAH


Desi Arisandi

DISUSUN OLEH

Raymond Niu – 825230147

Universitas Tarumanagara 2023/2024


DAFTAR ISI

BAB 1
1.1 Latar Belakang
1.2Tujuan
BAB 2
2.1 Perancangan Konseptual
2.2 Perancangan Logikal
2.3 Perancangan Fisikal
2.4 Script SQL

Perancangan Conceptual:
Step 1.1 Identify Entity Types:
a. Student
b. Teacher
c. Course
d. Classroom
e. Department

Step 1.2 Identify Relationship Types:


a. Enroll (between Student and Course)
b. Teach (between Teacher and Course)
c. Belong (between Student and Department)
d. Allocate (between Classroom and Course)

Step 1.3 Identify and Associate Attributes:

a. Student:

StudentID (Primary Key)


Name
DateOfBirth
Address
Grade
b. Teacher:

TeacherID (Primary Key)


Name
SubjectSpecialization
DateOfBirth
Address
c. Course:

CourseID (Primary Key)


CourseName
CreditHours
DepartmentID (Foreign Key)
d. Classroom:

RoomNumber (Primary Key)


Capacity
e. Department:

DepartmentID (Primary Key)


DepartmentName
Step 1.4 Determine Attribute Domains:

a. StudentID - Integer
b. TeacherID - Integer
c. CourseID - Integer
d. RoomNumber - String
e. DepartmentID - Integer
f. Name - String
g. DateOfBirth - Date
h. Address - String
i. Grade - String
j. SubjectSpecialization - String
k. CourseName - String
l. CreditHours - Integer
m. DepartmentName - String
n. Capacity - Integer

Step 1.5 Determine Candidate and Primary Key Attributes:

a. Candidate Keys:

Student: {StudentID}
Teacher: {TeacherID}
Course: {CourseID}
Classroom: {RoomNumber}
Department: {DepartmentID}
b. Primary Keys:
Student: {StudentID}
Teacher: {TeacherID}
Course: {CourseID}
Classroom: {RoomNumber}
Department: {DepartmentID}
Perancangan logical
Step 2.1 Derive Relations for Logical Data Model:
a. Student (StudentID, Name, DateOfBirth, Address, Grade)
b. Teacher (TeacherID, Name, SubjectSpecialization, DateOfBirth, Address)
c. Course (CourseID, CourseName, CreditHours, DepartmentID)
d. Classroom (RoomNumber, Capacity)
e. Department (DepartmentID, DepartmentName)
f. Enroll (StudentID, CourseID)
g. Teach (TeacherID, CourseID)
h. Belong (StudentID, DepartmentID)
i. Allocate (RoomNumber, CourseID)

Step 2.2 validate relations using normalization


Student (StudentID, Name, DateOfBirth, Address, Grade)
No non-trivial functional dependencies.

Teacher (TeacherID, Name, SubjectSpecialization, DateOfBirth, Address)


No non-trivial functional dependencies.

Course (CourseID, CourseName, CreditHours, DepartmentID


No non-trivial functional dependencies.

Classroom (RoomNumber, Capacity)


No non-trivial functional dependencies.

Department (DepartmentID, DepartmentName)


No non-trivial functional dependencies.
Enroll (StudentID, CourseID)
{StudentID, CourseID} → Grade (Assuming Grade is dependent on the
combination of StudentID and CourseID)

Teach (TeacherID, CourseID)


No non-trivial functional dependencies.

Belong (StudentID, DepartmentID)


No non-trivial functional dependencies.

Allocate (RoomNumber, CourseID)


No non-trivial functional dependencies.

Step 2: Apply Normalization Rules


Enroll (StudentID, CourseID)
No normalization needed for Enroll as it is already in 1NF.

Step 3: Verify Normal Forms


Enroll (StudentID, CourseID)
Enroll is in 1NF as it has atomic values.
No partial dependencies or transitive dependencies.
Therefore, it is already in 2NF and 3NF.

Conclusion:
All relations are either in 1NF, 2NF, or 3NF.
No further normalization is required for the given relations.

Step 2.3 Validate Against User Transaction

1. Enroll a Student in a Course:

Transaction: Insert a record into the Enroll table with the StudentID and
CourseID.
Validation: Check that both StudentID and CourseID exist in the Student and
Course tables, respectively.

2. Assign a Teacher to a Course:

Transaction: Insert a record into the Teach table with the TeacherID and
CourseID.
Validation: Verify that both TeacherID and CourseID exist in the Teacher and
Course tables, respectively.

3. Associate a Student with a Department:

Transaction: Insert a record into the Belong table with the StudentID and
DepartmentID.
Validation: Ensure that both StudentID and DepartmentID exist in the Student
and Department tables, respectively.

4. Allocate a Classroom for a Course:

Transaction: Insert a record into the Allocate table with the RoomNumber and
CourseID.
Validation: Check that both RoomNumber and CourseID exist in the Classroom
and Course tables, respectively.

5. Add a New Student:

Transaction: Insert a record into the Student table with StudentID, Name,
DateOfBirth, Address, and Grade.
Validation: Ensure that StudentID is unique and other attributes meet any
constraints.

6. Update Teacher Information:

Transaction: Update the Teacher table with changes to Name,


SubjectSpecialization, DateOfBirth, or Address for a specific TeacherID.
Validation: Confirm that the TeacherID exists in the Teacher table.

7. Delete a Course:

Transaction: Delete a record from the Course table for a specific CourseID.
Validation: Ensure that the CourseID exists and that cascading actions (if
defined) do not violate referential integrity.

8. View Courses in a Department:

Transaction: Retrieve information on courses offered in a specific department.


Validation: Join the Course and Department tables on DepartmentID and
return relevant information.

9. Check Classroom Capacity:

Transaction: Retrieve the capacity of a specific classroom.


Validation: Ensure that the RoomNumber exists in the Classroom table.

Step 2.4 Check integrity constraints


Primary Key Constraints:
Student: StudentID (Must be unique and non-null)
Teacher: TeacherID (Must be unique and non-null)
Course: CourseID (Must be unique and non-null)
Classroom: RoomNumber (Must be unique and non-null)
Department: DepartmentID (Must be unique and non-null)
Enroll: (StudentID, CourseID) (Both must exist in Student and Course tables
respectively)
Teach: (TeacherID, CourseID) (Both must exist in Teacher and Course tables
respectively)
Belong: (StudentID, DepartmentID) (StudentID must exist in Student table,
DepartmentID must exist in Department table)
Allocate: (RoomNumber, CourseID) (RoomNumber must exist in Classroom
table, CourseID must exist in Course table)
Foreign Key Constraints:

Enroll.CourseID references Course.CourseID (Ensures courses in Enrollment


table actually exist in Course table)
Enroll.StudentID references Student.StudentID (Ensures students in Enrollment
table exist in Student table)
Teach.TeacherID references Teacher.TeacherID (Ensures teachers in Teach table
exist in Teacher table)
Teach.CourseID references Course.CourseID (Ensures courses in Teach table
exist in Course table)
Belong.StudentID references Student.StudentID (Ensures students in Belong
table exist in Student table)
Belong.DepartmentID references Department.DepartmentID (Ensures
departments in Belong table exist in Department table)
Allocate.RoomNumber references Classroom.RoomNumber (Ensures
classrooms in Allocate table exist in Classroom table)
Allocate.CourseID references Course.CourseID (Ensures courses in Allocate
table exist in Course table)
Other Constraints:

Grade: Must be a valid value within the defined range (e.g., A-F, numerical
scale, etc.)
CreditHours: Must be a positive integer value
DateOfBirth: Must be a valid date value
SubjectSpecialization: Must be a valid subject area within the defined set
DepartmentName: Must be unique and non-null
Capacity: Must be a positive integer value

Bab 2.3
Bab 2.4
-- Sequence
CREATE SEQUENCE student_seq START WITH 1 INCREMENT BY 1;

-- Function
CREATE OR REPLACE FUNCTION generate_student_id RETURN INT IS
new_id INT;
BEGIN
SELECT student_seq.NEXTVAL INTO new_id FROM dual;
RETURN new_id;
END;

-- View
CREATE OR REPLACE VIEW student_view AS
SELECT s.StudentID, s.Name, s.DateOfBirth, s.Address, s.Grade, c.CourseName
FROM Student s
JOIN Enroll e ON s.StudentID = e.StudentID
JOIN Course c ON e.CourseID = c.CourseID;

-- Conditional Expression
UPDATE Student
SET Grade = CASE WHEN Grade IS NULL THEN 'NA' ELSE Grade END;

-- Subquery
SELECT *
FROM Teacher t
WHERE EXISTS (
SELECT 1
FROM Teach te
WHERE t.TeacherID = te.TeacherID
);

-- Bind Variable (Example in PL/SQL)


DECLARE
v_department_id INT;
BEGIN
v_department_id := 1; -- Assign the department ID as needed
SELECT *
FROM Belong b
WHERE b.DepartmentID = v_department_id;
END;
Link video
https://drive.google.com/file/d/11-XNu8s96vTmzKuBrsVFzZ1RWqS5vRqL/
view?usp=sharing

You might also like