I'm working on a personal project that will require a database to track religions, gods, mythologies, and sacred texts. I've been struggling with what would be best practices for design and layout of some of the pieces and wondered if this was an appropriate place to ask data architecture questions?
Add a comment
|
2 Answers
People have asked data modelling questions on dba.se before, so it's not off-topic for the site. If you have a question that's specific enough to fit the question/answer format then it's going to be considered on-topic.
Note: 'please design my database for me' is not. You will need to get to a problem that's specific enough that somebody can answer the question meaningfully.
answered Dec 28, 2015 at 15:56
I agree with @ConcernedOfTunbridgeWells, data modeling (or data architecture) questions are definitely on-topic and appropriate in DBA.SE, and they are usually encompassed within the database-design tag.
On the other hand, (a) due to the fact that you categorized the present question with the discussion tag, (b) making the assumption that you have the intention to build a relational database by means of any of the major SQL platforms, and (c) having posted a number of modeling answers myself, I am going to take this opportunity to suggest some factors that, although very basic, I find considerably convenient when contained in a modeling question.
Suggestion for a relational database modeling question
As you know, a relational database entails the storage of groups of assertions (commonly referred to as business rules) about a certain scenario that is significant to the people involved in it.
In this way, providing an explicit and detailed exposition of the specific context that you are modeling would make your question accessible to the interested users and, therefore, increase the probabilities of obtaining an accurate representation of the aforementioned assertions.
Such exposition should include the following elements:
- A description of all the pertinent entity types[1] that you already have identified, comprising their respective names and particular meaning.
- A depiction of each one of the attributes[2] that pertain to every entity type, paying close attention to those attributes that retain values that uniquely identify[3] the individual entity type occurrences.
- An explanation of the relationships that exist between the entity types of concern, including their corresponding cardinality[4].
- You might also like to incorporate some form of diagram showing the database structure that you have developed up to now, the SQL DDL statements for the platform you are employing (not forgetting to mention its name and version), or both.
I deem these aspects would really assist the readers in the comprehension of the especial semantic value of the things that you are working with, which, of course, could yield in the proposals of more complete and precise approaches and solutions.
It is important to emphasize that you should provide as much details as possible —no matter how obvious something may seem— since a determined word or expression can (i) hold a given conception when used in one context and (ii) receive a different conception when used in another one, that is why supplying the exact circumstantial meaning of the things under discussion is paramount.
All this may also help in the avoidance of extended series of clarifications and deliberations via comments, which would save valuable time to all the implicated parties.
Notes
1. It is useful to think of an entity type as the determination of a collection of things that possess the same attributes. Examples of entity types are: people, events, ideas, etc. In a concrete relational database, entity types become tables at the implementation phase.
2. An attribute is a property that is shared by all the instances of an entity type. Attributes become table columns once a database is being constructed.
3. I highly suggest focusing first on the meaningful natural primary keys of the entities. As soon as a stable logical data model has been shaped, adding surrogates only to the suitable tables is a very straightforward process.
4. Relationship cardinality can be thought of as the quantity of instances of one entity type that can be related to another quantity of instances of the same or a different entity type, e.g., one-to-many, many-to-many, etc.
