Weak Entity containing a foreign key as a primary key

Question

I have created a table called STUDENT which consists of Unique ID as the PRIMARY KEY along with other related attributes like Name, Addr, Gender etc....

Since I don't want to increase the table size of the STUDENT, I created a weak entity called ACADEMIC RECORDS which stores the previous Academic Records of the student.But in this table i have only created a PRIMARY KEY Unique ID which references the Unique ID of the student. and there is no other attribute in conjunction with Unique ID in the weak entity ACADEMIC RECORD Table.

As I came across the definition OF A WEAK ENTITY which define its primary key as a combination of weak entity's attribute and the owner's table's primary key(in this case STUDENT)

Is my method of creating a foreign key as the only primary key in the table ACADEMIC RECORD correct??

STUDENT Table  
**UID**  NAME  GENDER  ADDRESS  PHNO.

ACADEMIC RECORD Table  
**UID**  HighschoolMarks  GradSchoolMarks

Answer 1

I'm not completely clear on what you are asking, but it sounds like you are using the correct method.

Your STUDENT table requires a primary key to provide a unique reference for each row.

Your ACADEMIC_RECORD table also requires a primary key to provide a unique reference for each row.

Each student may have zero or more academic records, and you want to identify the student to which each academic record belongs. You do this by adding a column in the ACADEMIC_RECORD table which contains the id (the primary key) of the student:

STUDENT      ACADEMIC_RECORD
             id
id <-------> student_id
name         high_school_marks
gender       grade_school_marks
address
phone_no

Assume you have three students: Alice, Bob and Dave. Alice and Dave have three academic records, and Bob has two. Your tables would look something like this (I've omitted some columns to make things clearer):

STUDENT
id    name
1     Alice
2     Bob
3     Dave

ACADEMIC_RECORD
id    student_id
1     1
2     1
3     1
4     2
5     2
6     3
7     3
8     3

Answer 2

There's nothing necessarily wrong with having a primary key that's also entirely a foreign key. It's a common way of implementing something like ‘base classes’, where an entity has a row in a base table, and may have a row in one or more extension tables (one to one-or-zero relationship).

I'm not sure it's the most appropriate schema for what you're doing though. If there really is an exactly one-to-one relationship between academic_records and students, it looks like they are part of the same entity to me.

In which case from a normalisation point of view the record columns should be part of the main students table. Maybe there's an efficiency reason to denormalise, but “I don't want to increase the table size” is not normally an adequate reason. Databases can cope with big tables.