IS-A relation when defining tables
The best way to enforce uniqueness in this scenario then is to not split the artist "types" into separate tables. Normalizing your schema will show that there are fields in common, so at the least your artists table would contain id, artist_type ("band" or "singer"), and name. Any fields that are not shared should be split into more generalized tables.

EDIT:

After thinking about schema designs I've seen for music catalogues, the following comes to mind.

Be consistent in nomenclature. Yes, an "artist" is a "band" or a "singer." But a "singer" is also a "band" in the sense that they are a performer onstage, billed under a specific name ("Tori Amos" and not "Amos, Tori"), and usually backed by a band of musicians. A "singer" is also an "artist," but so is every member of a "band."

In other words, don't get caught up in what type of performer it is, just call it an "artist" if that is the name you've decided on. "Artists" can have 1 - n "members," which are just "people" with the normal details you would want to store about people. So your schema would consist of:

CREATE TABLE artists
( id number(10) not null,
  artist_name varchar2(50) not null,
  contact varchar2(50) not null,
  artist_type varchar2(50) not null, /* ...not sure you really need it */
  CONSTRAINT artists_pk PRIMARY KEY (id)
);

CREATE TABLE people
( id number(10) not null,
  first_name varchar2(50) not null,
  last_name varchar2(50) not null,
  contact_number varchar2(50) not null
);

CREATE TABLE artist_members
( id number(10) not null,
  artist_id number(10) not null,
  member_id number(10) not null,
  CONSTRAINT members_pk PRIMARY KEY (id),
  CONSTRAINT artists_fk FOREIGN KEY (artist_id)
    REFERENCES artists(id),
  CONSTRAINT members_fk FOREIGN KEY (member_id)
    REFERENCES people(id)
);