Using an attribute table like this is called EAV. This method is generally frowned upon in this forum but it can be useful when the attributes describing things can change or if you want to handle all attributes in pretty much the same way. If the attributes are unlikely to change much over time then I'd avoid taking this route.

If you still want to go down this route then I'd advise having a lookup table of valid parameters (ie "hair colour") and another table holding the valid responses for each parameter - then checking that values are valid before being stored in the attribute table. The normal field values ie name, sex, DOB etc would still be stored in the model table.

I personally wouldn't use surrogate keys ie 4 for "Brown hair" as it just complicates your design and code. I'd just store the values using your preferred language and then translate at the point of displaying to your users. So to search the database for models with brown hair and green eyes :

Code:

select  name
from    Models m
where   exists( select 1 from Attributes a 
              where a.id = m.id and a.type = "hair colour" and a.value = "brown" )
        and exists( select 1 from Attributes a 
              where a.id = m.id and a.type = "eye colour" and a.value = "green" )

or you can make the code easier to read by using functions to read the attribute table :

Code:

select  name 
from    Models
where   get_attribute( id, "hair colour" ) = "brown"
        and get_attribute( id, "eye colour" ) = "green"

Then you could then add a function that uses a translation table to convert any simple text ie "hair colour", "brown", "green" to each language you cover. It might be a good idea to log any missing text so it can be added at your convenience. This way you could produce a simpler system in your main language and then add the language support later. So to view all the attributes of a model in French :

Code:

select  translate( "French", a.type ), translate( "French", a.value )
from    Models m, Attributes a 
where   m.id = 1234
        and a.id = m.id

This isn't the most efficient solution but it does make the system easy to understand and build. It will also be quite easy to look after ie it's easy to add new model attributes or new languages etc. As all the attributes are treated in the same way then it should be easy build the screens as well. Assuming you don't have millions of models on your books so it should be more than fast enough.

Just my 2c. There is a lot to argue about in the above, ie using EAV at all, not using surrogate keys, a separate translation table etc but at least it's got the ball rolling.

tbl_models - holds the model ID and basic details - Name, DOB, Agency etc.

tbl_modelattributes - model_id,attribute_type,attribute_value

tbl_attributetype - attribute_type, description

tbl_attributes - attribute_type,attribute_value,attribute_description

No problem but interestingly the table and fields you list look almost like the tables and fields I'd use (and described) - weird. Is this what you'd call an object orientated design these days? If you're still in the design stage then I'd loose the "tbl_" at the start of each table name and perhaps use capitalisation to distinguish table names (ie ModelAttributes).