The proper structure for this scenario is a SubClass / Inheritance model, and is nearly identical to the concept I proposed in this answer: http://dba.stackexchange.com/questions/71741/heterogeneous-ordered-list-of-value/72319#72319.

The model proposed in this question is actually quite close in that the `Animal` entity contains the type (i.e. `race`) and the properties that are common across all types. However, there are two minor changes that are needed:

1. Remove the Cat_ID and Dog_ID fields from their respective entities:

 The key concept here is that _everything_ is an `Animal`, regardless of `race`: `Cat`, `Dog`, `Elephant`, and so on. Given that starting point, any particular `race` of `Animal` doesn't truly need a separate identifier since:

 1. the `Animal_ID` is unique
 1. the `Cat`, `Dog`, and any additional `race` entities added in the future do not, by themselves, fully represent any particular `Animal`; they only have meaning when used in combination with the information contained in the parent entity, `Animal`.

 Hence, the `Animal_ID` property in the `Cat`, `Dog`, etc entities is both the PK and the FK back to the `Animal` entity.

1. Differentiate between types of `breed`:

 Just because two properties share the same name does not _necessarily mean_ that those properties are the same, even if the name being the same _implies_ such a relationship. In this case, what you really have is actually `CatBreed` and `DogBreed` as seperate "types"

Below is the SQL to construct the basic model. Please note:

1. The SQL is specific to Microsoft SQL Server (i.e. is T-SQL). Meaning, be careful about datatypes as they are not the same across all RDBMS's. For example, I am using `VARCHAR` but if you need to store anything outside of the standard ASCII set, you should really use `NVARCHAR`.
1. The ID field of the "type" tables (`Race`, `CatBreed`, and `DogBreed`) are _not_ auto-incrementing (i.e. IDENTITY in terms of T-SQL) because they are application constants (i.e. they are part of the application) that are static lookup values in the database and are represented as `enum`s in C# (or other languages). If values are added, they are added in controlled situations. I reserve the use of auto-increment fields for user data that comes in via the application.

This model is using the `race`-specific `breed` tables concept. This first set of tables are the lookup / types tables:

<!-- language: lang-sql -->

    CREATE TABLE Race
    (
      RaceID INT NOT NULL PRIMARY KEY
      RaceName VARCHAR(50) NOT NULL
    );
    
    CREATE TABLE CatBreed
    (
      CatBreedID INT NOT NULL PRIMARY KEY,
      BreedName VARCHAR(50),
      CatBreedAttribute1 INT,
      CatBreedAttribute2 VARCHAR(10)
      -- other "CatBreed"-specific properties as needed
    );
    
    CREATE TABLE DogBreed
    (
      DogBreedID INT NOT NULL PRIMARY KEY,
      BreedName VARCHAR(50),
      DogBreedAttribute1 TINYINT
      -- other "DogBreed"-specific properties as needed
    );


This second set of tables make up the "Animal" entity and make use of the lookup tables defined above:

<!-- language: lang-sql -->

    CREATE TABLE Animal
    (
      AnimalID INT NOT NULL IDENTITY(1, 1) PRIMARY KEY,
      RaceID INT NOT NULL, -- FK to Race
      Name VARCHAR(50)
      -- other "Animal" properties that are shared across "Race" types
    );

    ALTER TABLE Animal
      ADD CONSTRAINT [FK_Animal_Race]
      FOREIGN KEY (RaceID)
      REFERENCES Race (RaceID);
    
    
    CREATE TABLE AnimalCat
    (
      AnimalID INT NOT NULL PRIMARY KEY, -- FK to Animal
      CatBreedID INT NOT NULL, -- FK to CatBreed
      HairColor VARCHAR(50) NOT NULL
      -- other "Cat"-specific properties as needed
    );
    
    ALTER TABLE AnimalCat
      ADD CONSTRAINT [FK_AnimalCat_CatBreed]
      FOREIGN KEY (CatBreedID)
      REFERENCES CatBreed (CatBreedID);

    ALTER TABLE AnimalCat
      ADD CONSTRAINT [FK_AnimalCat_Animal]
      FOREIGN KEY (AnimalID)
      REFERENCES Animal (AnimalID);
    
    
    CREATE TABLE AnimalDog
    (
      AnimalID INT NOT NULL PRIMARY KEY, -- FK to Animal
      DogBreedID INT NOT NULL, -- FK to DogBreed
      HairColor VARCHAR(50) NOT NULL
      -- other "Dog"-specific properties as needed
    );
    
    ALTER TABLE AnimalDog
      ADD CONSTRAINT [FK_AnimalDog_DogBreed]
      FOREIGN KEY (DogBreedID)
      REFERENCES DogBreed (DogBreedID);
    
    ALTER TABLE AnimalDog
      ADD CONSTRAINT [FK_AnimalDog_Animal]
      FOREIGN KEY (AnimalID)
      REFERENCES Animal (AnimalID);


Additional Notes:

1. The concept of `breed` seems to be a focal point for confusion. It was suggested by jcolebrand (in a comment on the question) that `breed` is a property shared across the different `race`s, and the other two answers have it integrated as such in their models. This is a mistake, however, because the values for `breed` are not shared across the different values of `race`. Yes, I am aware that the two other proposed models attempt to solve this issue by making `race` a parent of `breed`. While that technically solves the relationship issue, it doesn't help solve the overall modeling question of what to do about non-common properties, nor how to handle a `race` that does not have a `breed`. But, in the case that such a property were guaranteed to exist across all `Animal`s, I will include an option for that as well.
1. The models proposed by vijayp and DavidN (which seem to be identical) do not work because:
  1. They either
     1. do not allow for non-common properties to be stored (at least not for individual instances of any `Animal`), or
     1. require that all properties for all `race`s be stored in the `Animal` entity which is a very flat (and nearly non-relational) way of representing this data. Yes, people do this all of the time, but it means having many NULL fields per row for the properties that are not meant for that particular `race` AND knowing which fields per row are associated with the particular `race` of that record.
   1. They do not allow for adding a `race` of `Animal` in the future that does not have `breed` as a property. And even if ALL `Animal`s have a `breed`, that wouldn't change the structure due to what has been previously noted about `breed`: that `breed` is dependent on the `race` (i.e. `breed` for `Cat` is not the same thing as `breed` for `Dog`).