postgreSQL/PostGIS database: Table inheritance

Question

I am relatively new to postgreSQL and database design, and am currently puzzling with the method of INHERITANCE and whether it is relevant or appropriate to apply it to some of the tables in the postgreSQL/ PostGIS database I am currently creating. I would greatly appreciate any advice.

The three table scenarios I am unsure about are presented below:

1) The first case is an ecology table that holds information about flora and fauna (see below). All the attributes, except the resourceGroup and name attributes, takes the same types of input values regardless of whether the record refers to flora or fauna. The values that goes in the resourceGroup and name, refer to values from different lookup tables that are specific to either fauna or flora.

CREATE TABLE "ecology" (  
   "ecology_id" serial  NOT NULL,  
   "resourceType" varchar(5)  # ie. flora, fauna  
   "resourceUse" varchar(20)  NOT NULL,  
   "resourceGroup" varchar(20) NOT NULL # takes input from different lookup tables depending if it is  flora (ie. roots, seeds...) or fauna (ie. mammal, reptile ..)  
   "native" boolean  NOT NULL,  
   "name" varchar(30)  NOT NULL, # ie species name  
   "englishName" varchar(30)  NOT NULL,  
   "NTStatus" varchar(20)  NOT NULL,  
   "description" varchar(255)  NOT NULL,  
   CONSTRAINT "ecology_pk" PRIMARY KEY ("ecology_id")  
);  

Question: Is inheritance the answer here, ie.

CREATE TABLE "fauna" (  
  "faunaGroup" varchar(5)   
  "name" varchar(30)  NOT NULL,  
  "englishName" varchar(30)  NOT NULL) INHERITS(ecology);  

..and similar for flora, and then remove those attributes from the ecology table. Or is there a way to specify a constraint on the ecology table that when resourceType is set to ie. flora, then the input values in the resourceGroup and name fields are restricted to the lookup tables that refer to respectively flora name and flora group, and vise versa?

2)

The other potential Inheritance table scenario refers to the table documentation. This table stores information on and urls to different types of documentation methods, ie. reports AV, images, forms ect. The problem here is that some of the documentation types, such as reports and AV, share a many-to-many relationship with another main entity, while ie. images and forms are one-to-many. Besides this they share the same type of attribute information

Question: is inheritance the way to go to account for the different types of relationships, or should I just group them all together in one table (documentation) and treat all as a many-to-many relationship?

3)

This table scenario concerns certain tables that stores culturally sensitive information. There are essentially three access restrictions to some of the attributes in these tables: public, men only, and women only.

Question: Again could inheritance be the way forward here. Ie. creating two child tables for respectively men and women, that inherits all or some of the attributes from the parent table. You could then ecrypt respectively the men and women child tables? Or alternatively, would a simpler or better solution be to account for the gender and public restricted access at the schema level. So ie. creating respectively a men and women schema and group roles for each work type (ie ranger work, planning, ect ), as well as a schema that stores information that is open to the public.

Thanks in advance.

Best Ric.

Answer 1

1. ecology / fauna / flora:

   I think that inheritance is a possible way to model that. You seem to have got the table definitions wrong though: the ecology table should have the attributes that both fauna and flora have, and you only specify those rows in the inheritance children that are added.

2. documentation:

   That could also work with inheritance. Since all inheritance children are tables in their own right, they can have foreign key constraints with other tables.

3. information visible to men or women:

   That cannot be modeled well with inheritance. If you want to restrict visibility to table rows based on the database role, look into Row Level Security.