How is CMS designed?

We are doing CMS often encounter such a problem, the content type has a few, these content roughly the same field, only some fields are different.
such as news, notice (no source, more notification object), travel information (here the customer may have a cost field, easy to retrieve) similar content types.
Often we will deal with the following scenarios:
1. Set all the fields that Ken can use to a table, which has the following disadvantages
A, not very good to ensure data integrity, for example, a type of a field is required, but in type B is not, in order to add data without error, you must set the A field to be nullable.
b, the data fragmentation will become more, I do not know whether this argument is true, the type is different when the feeling will generate a lot of empty fields.
2, to define a different table for each type, this scheme has nothing to say, in a bad place, repetitive work is relatively more.
3, write the common attributes to a common attribute table, add the attached properties (not common properties), write to the respective schedule, this scheme and bar.
The previous two kinds of believe that everyone can think of, here I talk about the three how to achieve the plan.
The table structure of this scenario probably involves these table contentitem,contenttypedefinitions,contenttypecolumndefinitions,addon_xxx tables. The functions of these tables and the key fields are described below:

contentitem-contents table This table is placed in some common fields 

ContentTypeDefinitions    Content Type definition table (CTD table)-This table holds the content type, such as news, links Contenttypeid int unchecked--The primary key has nothing to say contenttypename nvarchar (unchecked)--name (such as news) Contenttypekey varchar (unchecked)--type key (for example: News) I Sbuiltin tinyint unchecked--is the built-in Displayorder int unchecked--                    TableName varchar (unchecked)--tablenameforeignkey varchar for the table holding these properties unchecked --Associated foreign key (CONTENTITEMID) page_new varchar (unchecked)--viewpage_edit varchar for new page Unchecked--viewpage_manage varchar Unchecked of the edit page--page_default_l of the admin page ist varchar Unchecked--default list page Page_default_detail varchar (unchecked) 

Contenttypecolumndefinitions The Content Type field definition table (CTCD table) defines which fields are in the schedule columnid    int    unchecked                        --contenttypeid    int    Unchecked                    --the content type idcolumnname    varchar    unchecked                --field name columnlabel    nvarchar (128)    unchecked            --field display name Isbuiltin    tinyint    unchecked                    -is built-in datatype    varchar    Unchecked                --data type length    int    unchecked-                            -length precision    varchar (unchecked)    -                - Accuracy isnotnull    tinyint    uncheckeddefaultvalue    nvarchar (+)    unchecked

The principle of this design is to put the generic content attributes into the ContentItem and put the attached properties (the non-generic attributes) in their respective schedules (e.g. news is placed in the Addon_news table)
The relationship between the two is associated with the definition in the CTCD table with the CTD table, and each time a common property is obtained, the corresponding attached property is obtained based on the content type, and the attached property is stored in the idictionary<string in the ContentItem class object> Additionalproperties.

The above contents refer to the design of the nearly CMS piece.

How is CMS designed?