OK, so the next step is to work out what information you want in each table. You'll need to determine (it isn't automatically obvious) whether the references flow in the same direction as the arrows or in the opposite directions. For example look at Officers->Unit and Officers->Suspects; you would want a reference to the Unit in the Officers table (this mirrors the use of DEPTNO in the Oracle SCOTT sample schema EMP and DEPT tables) (spanner in the works: or would you? Could you have multiple rows in DEPT, one for each officer?), but would you want a reference to the Officer in the Suspects table or the other way round? If you're not sure you can try it one way and see how well it works; if it doesn't then you swap it over.
Also have a look at the one to one, one to many, many to one and many to many relationships. Officer->Unit is obviously 1->1 (unless Officers can work in "virtual teams" for multiple divisions but that's probably an unnecessary complication). Are there any other 1->1's? Is Suspects->Crimes 1->1 or 1->many? Is Officer->Suspect 1->1? What if multiple officers are involved in the arrest? What if the same officer arrests multiple suspects? What if the same suspect is arrested on multiple occasions by different officers? Does the design suggest a new table, not shown in the diagram, of individual suspects? There are six arrows, so you'll need six relationships defining.
I can't give you a lot of help with the attributes. There will be those that relate to the relationships of course, but apart from that I can't tell you what you should have. The Officers table probably needs an ID field, the officer's name, but what else? Is there more to a Unit than an ID number and a name? Suspects is probably your most complicated table. You'll probably need an ID and a name. The arrows suggest other relational attributes; is there an "arresting officer" reference? a Crimes reference? What if the suspect is charged with multiple offences? You could use a VARRAY to store a list of offence IDs, but then what if they are charged with some and let off others; you might need a list of flags that show the status of the corresponding offences. Or should a suspect charged with multiple offences result in multiple rows in the Suspects table?
There isn't necessarily a single "correct" answer to any of these questions. You might be happy for example to use the officer's name as the ID, but what if you get two officers with the same name? What if one of the officers gets married and changes her name; would you want to update all the corresponding rows in any tables that might refer to the officer? Do you use data as the key or a separate ID? Your tutor may already have suggested a preferred solution to this. (On the occasions where I have designed a database and used data as the ID I've frequently had to add a new column for the key.)
(I've used ID and key interchangeably. Sorry if that's caused confusion.)
To some extent the question of attributes can be translated into "how much work do you want to make for yourself?". It's good to do a thorough job, but how much over the bare minimum do you want to do? Should the Officer table include an ID and a name? (Yes, fairly obviously). What about the officer's address? You could argue HR would need this info (but then again, would they have their own database? Ideally no, but HR departments tend to get very protective about their data and won't share with anyone, often citing Data Protection.) Do you want to store whether the officer is married or not, has any dependents, what are their names, their friend's names, do any of them have a dog, what is the dog's name, what has the dog been immunised against? I'm not extracting the urine; this is the kind of thing you need to think about; if this has gone too far, why?
A good place to start is to determine the bare minimum you need for the whole thing to work.
Also have a think about the the queries you want to run on the tables as this may suggest other relationships that need defining. For example what if different crimes belong to different divisions, and an officer in one division arrests someone on suspicion of a crime belonging to a different division? Should a traffic officer arrest someone on suspicion of supplying drugs? Should the database prevent such entries being made? Are you ever likely to want to query the database for suspects and officers with the same first name? Are there any relationships that make certain officer/suspect combinations unsafe, for example should an officer be allowed to arrest his own brother? Does a suspect need a "status" attribute that determines where they are in the process (under investigation, arrested, charged, convicted, released, others?), and does this suggest another table? You may want to query the database for all suspects who are still under investigation. Do you want to store significant dates, for example arrest date is probably fairly important; should charge date and conviction date be kept? You may want to monitor the time it takes for suspects to move from arrested to charged, for example for officers' job performance monitoring.
Lots of stuff for you to think about there. Some questions you can reject without much thought; I would think for example listing the dog immunisations of officer's children's friends could be rejected fairly quickly. Others will take some time to answer and you may not be sure if the answer is "correct"; you may need just to pick one of the possible answers and run with it for a bit and see what happens; I would certainly need to do this with some of the questions I've asked, and I asked them! As I said before, there is no single correct answer to many of these questions and determining the "best" answer will depend on many factors.
(Heh: "quick reply". Shabbir, how about a new button, "Post extensive rambling"?)