Table with low selectivity ratio I have one table now with million rows..

Table-1

Name, Age, Sex, Dept
Tom   25   M    Finance
.
.
.


Now, The "Finance" is reptitive...Currently, there is only one dept "Finance"..

Is it good to normalize the data to a different table..

Finance Table

Id Name
1  Finance


and refer Finance-id in the Table-1
In general, you have a heavily de-normalized table, and a bit of normalizing would do some good.

Since you appear to be new to database design, I understand you may not really be aware of what normalization is, so we'll keep it simple and say that for a normalized structure, you want each piece of data to exist in one place only, so that it is not copied repeatedly in many locations.

Of course, you'll find that the Wikipedia page on database normalization is a good start.

Let's look at your specific case:

1) You have the individual's name directly in the row data.  This is fine if a person is referenced once and only once, but what if the a person is part of the data for other tables?  Do you want to copy their name every time?  What if they get married or for some other reason they change their name?  Now you'll have to track down every instance of their name.  What if two people have the exact same name?  How do you discern between them?

In general having a table with unique person ids as

CREATE TABLE people(
  person_id int,
  first_name text,
  last_name text,
  etc...
);


would be a good idea.  Then simply place the person_id into any other relevant table.

2) So, putting someone's age into a table is a pretty bad idea.  Doing it this way, every day you need to go through the table, see if it is someone's birthday, and update any corresponding entry.

Why bother with that when you can simply store their birthday once, and all relevant information is encapsulated in that one, never changing piece of data? Futher, since it is definitively attached to the person, add their birthdate as a column entry in the previously mentioned people table.

3) You can already see where I'm going with this: this data also belongs in the people table.

4) Now we're on to your original question.  Yes, I believe you should have a separate table which lists the different departments.

CREATE TABLE depts(
  dept_id int,
  name text,
  other_info text,
  etc...
);


Lastly, joining people to departments can simply be done with a table having two integer columns:

CREATE TABLE employees(
  person_id int,
  dept_id int
);


Hope this helps!

P.S.: I've made it sound like normalization is always the right answer. In actuality, it is often the right answer, but not always.  They key is, learn to normalize an why you should, so that you can then make key decisions about why you might choose to intentionally de-normalize your data.