With the advent of computers, of course the shape of the databases saw a sea change and there was a scientific angle added to the organization of the data and access methodologies.
Early Procedural Databases -
In the early databases the data was organized in the form of records of similar structure; a structure which had to be "familiar" to the programs (queries) which were to be used to access or manipulate them (records). For example structure of record for employees may be something like - position1-position20 => name, position21-position30 => qualification, position31-position36 => birth date (ddmmyy), position37-position50 => address, position51-position65 => designation ... and so on and so forth in the following format -
Peter----BS----150185House no8 Thurlow Gardens----Manager---
Roger----MS----200286Rockspring Rd ----------------Clerk------
Queries had to be aware of this structure of records (by incorporating hard coded positions of data) for handling them (records) and so they (queries) were in the form of complete procedures (programs), and hence the term "Procedural Databases". The earlier databases had those records organized in a "hierarchical" or "network" way to depict the relationship between the records and hence such databases were also called as hierarchical or network databases respectively. Since the queries (procedures) were have to be aware of the structure, then any change in the structure would require a complete change in the procedures and vice-versa. What if I want to change the date format to ddmmyyyy from ddmmyy and want to retrieve the address or designation with the same old Query (data position aware program/procedure)?
Now imagine of such procedural scenario if you were to ask for a jugful of water to room service from a hotel suite. Telling the service boy each step - "put your left leg forward - put now right leg forward - repeat this - turn by an angle of 20 - hold the railing of stair case with left hand - put left leg down a step - put right leg down next step - repeat this ... and so on and so forth". Alas, thank god He made this world non procedural and so worth living. And further imagine the changes that will be required to be made in this procedure if there is change in the place of storage of water or layout of the hotel.
Recent Non-Procedural Databases -
Philosophically database is a mini world - set of facts of the real world. And if the real world is non-procedural then why should this mini world be also not as such? And as a proverb in the world of sciences says "old idea is the best idea", the attention was turned to the organization of data in the form of tables; the very tables any common man would use to jot down his daily expenses with date, amount and head as the columns and everyday's entry as a row, to be uniquely identified by the date.
Hurray !!! you can now just use Queries in the form of statements (not procedures) like "get me the amount of expenses on date xxxx" or "update the head of expenses on date xxxx" or "delete the entry of date xxxx". The Queries which will not change in any condition; same as in the real world you may just ask for a jugful of water from your hotel suite - "get me a jugful of water" independent of knowing the storage place of water or layout of the hotel and importantly the statement would not change if you check-in to some other suite in the hotel after 10 years or even if you check-in to some different hotel altogether. I hope you can now extend this analogy to tables and databases. And now thank "Codd" who made such non procedural databases possible by proposing the theory of RDBMS (Relational DBMS).