It is difficult to quite get what you are trying to do. But it seems that you need to start by designing a more normalized database.
What are the entities (things) described?
(Courses would seem to be one, "State" may be another but that is not clear, and what is a "Target"?).
What does "Capacity" describe? Is it an attribute of a "State" or an attribute of a Course, or does it refer to something else? And what does it mean that a "Target" is Approved?
My guess is also that in a real world scenario, you would want to define the INSTANCES of a course as separate from the course description, so I'm guessing maybe this is a classroom exercise?
Represent each separate entity in a separate table, and show how they relate to each other.
Something like (just guess on what your intentions are):
Table:
States
Columns: StateID, StateName, Capacity
(1, 'AP', 360),
(2, 'TS', 360),
(3, 'MP', 360)
Table:
Courses
Columns: CourseID, CourseName, ...
(101, 'crs1', ...),
(102, 'crs2', ...),
(103, 'crs3', ...)
Intermediate table ties Courses and States together:
Table:
StatesCourses
Columns: StatesCoursesID, StateID, CourseID, Allocation, Approved
(1001, 1, 101, 25, 'Y'),
(1002, 1, 102, 10, 'N'),
(1003, 1, 103, 0, 'N'),
(1004, 2, 101, 10, 'N'),
(1005, 2, 102, 20, 'Y'),
(1006, 2, 103, 2, 'Y'),
(1007, 3, 101, 21, 'N'),
(1008, 3, 102, 33, 'N'),
(1009, 3, 103, 2, 'N')
Now you can get the following result showing allocated by course and state:
State, Capacity, Course, Allocated
using a query like this:
SELECT State, Capacity, Course, Allocated
FROM States as S
INNER JOIN StatesCourses as SC
ON SC.StateID = S.StateID
INNER JOIN Courses as C
ON C.CourseID = SC.CourseID
In order to get the specific layout you are looking for, you can either construct a custom query that only works for the currently known courses and states (not a very flexible solution), or you can look into PIVOT (or TRANSFORM) in your database's Help.
Until you get a handle on the relational data design, you may be better off sticking with keeping your data in a spreadsheet. That isn't necessarily a bad thing. Databases are great when you have a lot of data or it gets difficult to manage and you need more flexibility. But to get that flexibility, you need to have a reasonable design of the database. Search the web for Introduction to Relational Databases for additional help
HTH.