Yes, definitely do a logical design first. Don't even think about artificial keys yet.

You need to identify "entity" and "attribute". Roughly:

Entity = things about which you store unique data

Attribute = a single piece of data you need to store

[Naturally you have to accurately match each attribute to the appropriate entity -- sounds obvious, but can be tricky at times.]

OK, let's see what potential entities we have. Some are pretty clear:

Student

Institute

Department

Semester

Course [not directly stated in your list but common knowledge]

But what about:

Mark Sheet?

Admit Card?

You have to decide if these are true Entities, which deserve data stored about them, or if they are just attributes about relationships between the entities above.

Determine the attributes you need and assign them to the appropriate entity.

CRITICAL RULE: An attribute is a single piece of data, never repeating or a list.

You will need to create a new, special "relationship entity" for any data about the relationship between two entities.

Maybe, since a student takes courses, you will ultimately need an entity(ies) that relate Course and Student somehow.

As part of this process, you will determine and document the cardinality (1 to 1, 1 to Many, Many to Many) between entities. Naturally not all entities will have a direct relationship with every other entity.

Edit: corrected typo.