I don't see any difference between your 3 levels of Student?? Even if there are minor differences, then Student would probably be one "Entity", hence table.
Ditto for Instructor.
Maybe there would be a Person table, especially if a student can be a "teaching assistant, hence be both a Student and an Instructor. So, in developing your schema, you might start with
Student, Instructor, etc
then migrate to
Person, Student, Instructor, etc
This kind of "evolution of the schema" is normal in developing a schema. It is _much_ better done _before_ you commit the schema to live production!
Assuming you need "Person", then note that a Student "is a" Person. This is probably implemented thus:
CREATE TABLE Person (
person_id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
... (name, etc)
PRIMARY KEY (person_id), ... );
CREATE TABLE Student (
student_id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
person_id SMALLINT UNSIGNED NOT NULL COMMENT "for JOINing to Person",
... (student-specific fields)
PRIMARY KEY (student_id), ...);
(You may include a FOREIGN KEY and ON DELETE CASCADE, etc, if you like.)
Similarly for the Instructor table linking to the Person table.
Now, to find the teaching assistants:
SELECT p.name
FROM Person p
JOIN Student s ON s.person_id = p.person_id
JOIN Instructor i ON i.person_id = p.person_id;
> academic result record.
> Students' Financial info
> make their debt payment
You need to look deeply into security. A casual installation of MySQL is too easily hacked. Read about "sql injection", hardening passwords, locking down your machine, etc. Or get it perfectly clear that that is not part of the assignment. Seriously, if this system were to go live, you should have spent 50% of your development effort on security. So far, you querstions have been only 10% on such.
> if i can manage and complete the objectives
Maybe that answers my comment on security -- make it perfectly clear that security is outside the objective. (It is mostly orthonogal, anyway.)
> 1.How many tables involve(and what they are)
I hope I have given you enough clues to make more of an estimate of this. Would you like to list your table now?
> 2.If i want to use [Student Number] as my Primary key. How to make if any student is deleted from database, so all posts related by the student is also deleted?
Plan A: Depend on FOREIGN KEYs and "cascading deletes". (not my preference)
Plan B: Your application deals with the details -- run around to each table and delete rows (or mark them as 'deleted'), etc.
Clearly, you need student_number as a field in the Posts table. If there is a many:many relationship (eg, any "post" might talk about many Students), then you would need to have a many:many Relationship table. This _might_ have to be handled by your app, not FOREGN KEYs.
> 4.WHAT I SHOULD DO FIRST? designing web interface? designing database?
Back and forth. Each will feed off the other. Do _not_ fall into the trap of assuming that the database needs to be perfect for the web pages; it is quite acceptable for the web queries to do SUM(), GROUP BY, IF NOT EXISTS, etc to rummage through the database to get what it needs. The database should be viewed as a "source of truth", with minimal redundancy, even if it means that the web page has to do more work. OTOH, if the tables get so big that performance becomes a problem, then we can look into details about specific improvements. I have no qualms about writing web pages with twenty SELECTs, multi-table JOINs, etc, on million-row tables. (But I do have to revisit the queries, the indexes, and even the schema design, when performance is "too poor".)
> public Announcement, chat, Private messages.
Do you need to save these for posterity? Perhaps you need one table for each, perhaps one for all.
OTOH, it seems "wrong" to re-invent these wheels -- there are plenty of free mailing lists, IMs, emails, etc. Perhaps your web pages could be very thin layers in front of such tools?
> UPLOAD / DOWNLOAD any source.(lecture note, music, video, etc..)
There have been many threads on PHP details for these (see the PHP forum).
You need to decide if these functions are transient or permanent -- that is, do you need one or more `Media` tables? Do you need an "expiration" or "purging" mechanism built into the system? A la, "Do you want to leave this online for one week or one month?"