This page is an introduction to CiviCRM's data architecture.
This should be useful for users and implementors that want to better understand the different CivICRM objects and tables and how they are related, and how they are stored in the database.
Most of the common objects in CivICRM (like contacts, activities, memberships, relationships, groups), are stored in the database as one or more tables. Most of the tables that represent common CRM objects (like contacts, activities, relationships), etc. can be segmented into different types. Most objects can be extended by adding custom data.
Entire DB Schema
Taken from CiviCRM 3.14
Please click the thumbnail to view the diagram
To download the entire diagram, click here
Contacts and relationships
Individuals, organisations and households are stored in a single table civicrm_contact.
Contact details for each contact are stored in seperate tables.
Contacts can be related to each other by applying relationships.
Activities are recorded in civicrm_activity and linked to civicrm_contact in three main ways
Memberships are record in the table civicrm_membership. Associated contributions (if there are any) are stored in civicrm_contribution and associated with the membership.
Contributions are stored in civicrm_contribution
Groups and tags
Groups and tags look similar in CiviCRM's database.
A list of objects that can be extended with custom data can be found at: http://d45.demo.civicrm.org/civicrm/admin/custom/group?action=add&reset=1 [log in with ID demo, password demo] then click on the 'Used for' drop down to see the full list.
Custom data can be applied to either all objects, e.g. all events, or restricted to objects of a certain type, e.g. only training events. When you add custom data to a CiviCRM object, you first create a custom data group and then add custom data fields. At the database layer, what you are doing is creating a new table for the custom data group and adding columns for the fields.
The diagrams on this page were created using MySQL Workbench.