A Party is either an Individual or an Organisation. A Party can have zero, one or more PartyRole. A Party can have zero, one or more Contact information. A Contact information could be e-mail, mobile etc.
Using the model, a producer is an Individual, with the PartyRole of a producer, who has a name and a telephone number as Contact Information.
Data elements
Integration with Yamdu
The production system we use, Yamdu, can export a CSV file with all actors, contact information and information related to physical appearance as well as personal preferences.
Each column in the table is an attribute to the data element actor from an integration perspective.
Some information here are categorized as sensitive PII in GDPR and access must be restricted.
An actor is a PartyRole in the in information model. The actors contact information and the agent can also be modeled using standard model.
The challenge here is that TM Forum doesn't support physical appearance, e.g body height, for individuals, and we have to make extensions to the model and API's.
Azure SQL-server
We have setup an Azure environment, with separate servers for development, test, staging and production.
In the SQL server, we have to define tables, views and joins as usual.
The premise is to start with the basic objects in the model, e.g. Individual, Organisation and PartyRole and create tables.
As an Individual can have several Party roles, we should at least create an additional table with two attributes, PartyRole and Individual.
An Individual can belong to more than one Organization so this relationship creates need for one more table with the attributes of an Individual and an Organization.
Another decision is if we should use a separate table for physical appearance with attributes for each of columns in the CSV-file or if it's better to use value-pairs for these attributes. Pros and cons with both approaches.
Non-functional requirements as performance, security, legal regulations etc will also impact the design of the schema.
Conclusion
Without an understanding of the business terminology and use of information modelling, it's very hard to make av flexible IT-solution within a reasonable time.
When running Agile projects, you can't skip this part, unless you like to redo a lot of work at a later stage.
The fact that one person can belong to several companies is one paper a very small requirement, easily overlooked, but will create a huge impact in both UX- and database design. Not mentioning the massive changes in code, in different modules, if implemented afterwards.
You can leverage AI as a tool, but in the end, this is still design with trade-offs. Often the decisions are based on both business and IT-knowledge.