This data set demonstrates a basic M:N relationship between 2 tables
The dataset is targeted to show a slim implementation of M:N
It's no question that other implementations exist. But at significantly more storage consumption.

The first is a list of members in Developer Community counting badges gained in Global Masters
The second is the reference to assigned badges from Global Masters with their titles
So we have M members that refer to the multiple badges they gained + their count
And we have a set of N Bagdes that are assigned to several members + the count of members
related to that badge and the Ids to these members.

All data result from the analysis of the member web pages in Developer Community
A utility for updates of ídentified members and the addition of new members is provided
The actual status reflects 10286 account pages downloaded and analyzed relating to 179 badges.

Relations are implemented as Lists of pure id's (not oref to save space)

/// pure ID of awarded GM badges
Property Badges As List Of %Integer;

/// pure ID of assigned members
Property Members As List Of %Integer;

A few explanations on operation structures for further extension:

• GM badges never change or get deleted - so they just can grow
• DC members can get GM badges granted, but they will never lose it It is up to you to take care of the correct maintenance of the M:N relations for DELETE or UPDATE of DC members. This is intentionally left open.

3 utility methods are provided:

• Load(): this loads and analyzes the information presented on the member's page
• Upd() : runs over every defined member using Load() for actual values
• New()  : runs past the highest known MemberId and tries to find new ones MemberId's are not given in closed sequence. So they can't be predicted but only tried

GitHub

The base class Bmap.Person defines persons within an organization distributed
by various countries. All records are indexed by (Country, PersonalId).
this structure doesn't allow use of bitmaps.

So a wrapper class Bmap.PersonQ around the data eliminates the top level of
the index (Country) and isolates the PersonalId (%Integer, MINVAL=1).
We are ready to use a Bitmap index.

A few performance figures on 300010 generated records.
You see that Relative Cost are sometimes quite misleading.

base

  select count(*) from Bmap.Person  
  300010 global references 1600446 lines executed   

demo 1

  select count(*) from Bmap.Person where Ctry='RU'  
  Relative cost = 197762  
  10015 global references 70474 lines executed    

select count(*) from Bmap.PersonQ where Bmap.Ctry('RU')=1
Relative cost = 401400
10 global references 424 lines executed

demo2

  select count(*) from Bmap.Person   
     where Ctry='RU' and home_state='MA'   
  Relative cost = 457.96    
  218 Global references 2335 lines executed   

select count(*) from Bmap.PersonQ
where Bmap.Ctry('RU')=1 and home_state='MA'
Relative cost = 2012.8
16 global references 478 lines executed

demo3

  select home_state,count(*) from Bmap.Person   
     where Ctry='RU' group by home_state  
  Relative cost = 372162   
  Row count: 50 Performance: 0.027 seconds   
  10420 global references 153708 lines  

select home_state,count(*) from Bmap.PersonQ
where Bmap.Ctry('RU')=1 group by home_state
Relative cost = 453400
Row count: 50 Performance: 0.018 seconds
817 global references 155475 lines executed

GitHub