Is there any way to create a relational database schema from the SID model? Can you help me on this?
There is a SID User Guide that was published by the late John Reilly back in 2018 covering this subject at a more general level. I have attached the document.I hope this helps.
I'd like to question the premise underlying the question. In my view (and yes, this is my view only), the SID is a conceptual information model, not intended for actual implementation. The SID is an extremely valuable resource to create a baseline for the business and to ensure that all entities are accounted for in the context of a given functional domain.
However, there are many things about the SID that make it challenging to transform into common storage media (SQL or no-SQL), such as extreme normalization, deep class hierarchies. and more. Additionally the SID entities have very few properties/attributes, leaving the question open as to whether a SID Customer or Product (for example) reflect the real-life storage.
The Open API model is far closer to an implementable persistence model, and has the advantage that it is "field-tested", so that there is a better chance that the functional requirements are covered - certainly that's our experience as a software vendor.
Hope it helps
I agree with @Jonathan Goldberg .
SID is an information model and is not intended to be implemented directly - as such. It provides a conceptual understanding of information flowing through enterprise and eTOM processes.
There is an initiative within the TM Forum called "Data Model" (in the implementation ODA space). Basically, this is the model used by Open APIs.
Thank you very much for your replies. That was helpful.
I do agree that generating a database schema out of an information model is against the purpose of the information modelling. However, I still see some benefits of using the information model as a base to the database. As Jonathan says there must be some normalizations, or some design patterns to be used per information modelling patterns (e.g. the inheritance especially), but still the database tables that we are going to create will contain the properties and the relations of the original information model.
Regarding the suggestion of using the API resource model as the persistence model, I tend to disagree with that because of the purpose of the APIs. They are never meant to describe how the data is persisted internally. They are designed to expose the information to the external world as simple as possible while hiding the internal complexity. And regarding the "Data Model" on GitHub, the newest update is done 2 years ago. So, it looks like it is not aligned with the latest published set of APIs.
Again, thanks for your time and contribution.
Your statement about the data model publication is accurate. It does seem that TM Forum has not yet figured out an effective way to publish the consolidated Open API resource model - currently it can be deduced from the published swagger files.
Regarding persistence, our experience as a vendor (without going into details and "leaking" IP) is that using a document-oriented store (e.g. Couchbase) we find that the persistence model is quite close to the exposed API resource model. There are differences (which for obvious reasons I cannot disclose), but the fundamental direction is of similarity.
If you're a relational outfit, there will clearly be more variance, due to the need to translate between document structure and relational tables.
Yes, it is possible to create a relational database schema from the SID model. free fire name