Useful Design Patterns
The cost and time to design new data models can be brought down when combining a number of typical solutions into a new one. Reusing certain design patterns is advisable because it is very efficient to have solution features which quickly lead to a reliable result.
In this message we discuss :
-(Multiple) List(s)
-(Multiple) Self Referring Trees
-A bit about Time driven modelling.
List
Let's assume we need a concept country for our solution. The most simple format we can think of is a data object called Countries. It enables us to list all countries of the world and select from them.
Multiple Lists
Now suppose we like to limit the country choice list per continent for a bit more user convenience. A typical solution would be to add a new data object Continent.
Self referring tree + List
We all know reality is more complex and therefore let's assume we need a concept called Region to store data on. This can be organised in a simple self referencing tree whereby we can model the regiontypes like continent, country, state, department,etc in a simple list.
Multiple self referring trees and link lists
When we only require geographical system this would be sufficient. However when we want regions to be member of multiple Regional groupings we need a bit more complex construction.
The data object NestedRegionTypes contains different regional grouping systems like:
Dutch system
- Country
- Province
- Community
French System
- State
- Region
- Departement
- Arrondisement
- Kanton
- Commune
Intercontinental Country Organisations
- APEC
- G7
- etc
European Country Organisations
- EU
- Benelux
- etc
American Country Organisations
- NAFTA
- OAS
- etc
Having these systems in place each Region has a mandatory geographical type so we can always find it by using the geographical ordering discussed above :
- -USA (country) of North America (continent)
- -France (country) of Europa (continent)
- -Netherlands (country) of Europa (continent)
- -Texas (state) of USA (country)
- -Haute Provence (Region) of France (country)
- -Utrecht (province) of Neth)erlands (country
- -etc
Now on top of that each region (for example a country like USA) can be member of multiple other regional grouping systems (e.g. APEC, G7, NAFTA) by entering them in the data object RegionLink.
- APEC,USA
- APEC,Japan
- G7,USA
- G7,France
- NAFTA,USA
- NAFTA,Mexico
- EU,France
- EU,Netherlands
Flexibility
One can now add grouping systems of any type to the database and directly use them without any programming effort. For example the collection of ''Kantons speaking a particular language in Switzerland'' can be added in two steps.
First create a grouping system of lingual division in the dataobject NestedRegionTypes.
Language spoken
- German
- French
- Italian
- Romansh
Secondly link the relevant Swiss Regions to their lingual group in the dataobject RegionLink
- Geneva, French
- Graubunden, Romansh
- Ticino, Italian
- Schaffhausen, German
More time driven flexibility
Finally, to add a bit more flexibility, when membership to grouping systems vary in time you can give them a start- and enddate attribute to filter out the non-current regions at any give moment.
Let's take as an example the Commonwealth of Nations established in 1931, today a group of 54 countries. The entries in the RegionLink data object look like:
- Commonwealth, Australia, 1931, today
- Commonwealth, SriLanka, 1948, today
- Commonwealth, Tanganyika, 1961, 1964
- Commonwealth, Ireland, 1931, 1949
That's it for now, hope you found any of the solutions useful for your application.
Geen opmerkingen:
Een reactie posten