Oregami Forum

Now that I am doing concrete implementations of our data model I find it hard to get an overview of the single parts of the datamodel.
The complete data model is a bit overwhelming I think. The forum threads are also difficult to evaluate because of their length and their different opinions (that's the nature of a discussion). Another goal would be to optimize the visibility of the "UML connections" - they are really hidden and we cannot see the history of the connections.
These are the reasons for this proposal.

I suggest that we create final documentations for (every) single aspect of the data model. These documentations should contain all details, explanations and examples for one part of the data model. We could create them in our wiki and could enclose a (mini) UML diagramm with PlantUML (see this example). A single documentation can contain a single class with all attributes, or multiple classes (with a few or even none) to explain their relationship (connections).

These examples come into my mind:

• single documentations for Game, ReleaseGroup, Release, GameTitle, CreditSet, Company, Person, Region and so on
• relationship between Game and GameTitle
• relationship between ReleaseGroup and Release
• relationship between ReleaseGroup, Release
• relationship between Hardware- and Software-(Sub)Platforms
• relationship between Release and Region
• relationships between Person and PersonalEvent
• relationships between Company and CompanyEvent

Every documentation could have a status (draft, pending acceptance, accepted).

What do you thing about it? And where con you help?

Edit: I created a first documentation page for "Game"

gene wrote:I suggest that we create final documentations for (every) single aspect of the data model. These documentations should contain all details, explanations and examples for one part of the data model.

It's funny how I had the exact same thoughts witin the last weeks. So, yes, it's about time to finalize parts of the data model, for development to get underway.

I would suggest the following workflow:

1) gene makes a wish in this thread here.
2) We discuss and model all loose ends of the part(s) to finalize.
3) We create the detailed documentation as you mentioned.

So shall we start with game titles then?

Go ahead, I'll comment when necessary

We are collecting the wiki pages for the data model finalization under this page now.

As a preparation, I finished what gene started, and converted the Connections page to PlantUML. This is better since it allows change tracking.

Will attempt to convert the main UML model next, let's see how this works out.

MZ per X wrote:Will attempt to convert the main UML model next, let's see how this works out.

Wow, this is really starting to get pleasant.

I finished the conversion of the data model to PlantUML, looks crazy enough already. Will do a final check soon, please lend an eye, too.

MZ per X wrote:I finished the conversion of the data model to PlantUML, looks crazy enough already. Will do a final check soon, please lend an eye, too.

Cardinalities are missing

gene wrote:Cardinalities are missing

Sorry, don't know what exactly you mean here.

MZ per X wrote:

gene wrote:Cardinalities are missing

Sorry, don't know what exactly you mean here.

I mean in every assiciation between two classes we need to know if it's a "1-to-1" or "1-to-many" or "many-to-1" or "many-to-many".

Here is a Wikipedia article about Cardinality in Data modeling.

You can also look at the PlantUML documentation.

gene wrote:I mean in every assiciation between two classes we need to know if it's a "1-to-1" or "1-to-many" or "many-to-1" or "many-to-many".

Ah, okay. This hasn't changed from the old Gliffy model. I added two examples in the wiki, is this sufficient?

MZ per X wrote:

gene wrote:I mean in every assiciation between two classes we need to know if it's a "1-to-1" or "1-to-many" or "many-to-1" or "many-to-many".

Ah, okay. This hasn't changed from the old Gliffy model. I added two examples in the wiki, is this sufficient?

Perfect!