Hi I am new to conceptual data modelling and is currently working on entity-relationship diagrams. Just some questions that I am not able to find an answer to:
I am designing an E-R diagram based on a given scenerio and as I match my answers against the 'model answer', it is quite different, especially the terms I use within the diamond shapes representing the relationship between 2 entities. Am i right to say that the choice of words representing the relationship can be anything so long as it is logical?
I noticed different tutorials uses different means of representing cardinality. Some uses crow foot, some uses M:N to represent many-to-many. As there are so many standards, which is the recommended standard to follow for a beginner?
Thanks in advance
A Conceptual Model is used to represent a domain of discourse to aid you and the users understand that domain. As such the wording and form of that representation should be that most aids you and the users in that understanding.
Therefore, should you choose to include an Entity Relationship Diagram as part of the Conceptual Model, the terms, notation and diagrammatic conventions used should be those that make most sense to you and the users. The terms used may be specific to your organization or business.
There is no particular best practice to recommend. As long as you and the users are happy that your Conceptual Model adequately explains the domain of discourse then the production of the model has fulfilled its objective.
Related
I'm writing game worlds and I've started working on representing the worlds not just as text and images but as a graph of topics and associations. In other words, an ontology representing the game world's characters, places, events, concepts, terms and so on.
Where I've got a bit stuck is in defining and naming the relationships between topics. It's easy enough to come up with things like "is a", "part of", "located in" etc, but as the work goes on, I realize that using the terms loosely will not work well, there are many relationships that overlap in meaning and you start wondering if this hasn't already been done. I've looked into OWL for creating ontologies, and topic maps, but what I lack is an actual data set of named associations (predicates in RDF) that I can build on, that have been vetted and used for larger projects.
What is a good strategy and resource to describe relationships between concepts in an ontology?
Schema.org is probably the definitive resource when it comes to widely accepted nomenclature for ontologies. See their page for Organizations for a good example of their property names.
I found a similar question that was addressed to the Neo4j/Cypher graph database audience, but may provide some good insights as well. A key one is the trade-offs between fine-grained relationships ('LIKES_POST') vs course-grained relationships ('LIKES'). The finer the grain, the greater the specificity, but the greater the overall complexity of the graph. In general, these trade-offs depend on your use case, where you can determine which direction best suits your needs.
I'm in the process of migrating a neo4j database into Grakn for genomics and biological data, I have the files in CSV for this but I need to an ETL Tool for solving this problem in the simplest way.
I am following this template Python migrator:
https://blog.grakn.ai/loading-data-and-querying-knowledge-from-a-grakn-knowledge-graph-using-the-python-client-b764a476cda8
Am I correct in thinking this way -
Do nodes map to entities?
Do edges in neo4j map to relationships in Grakn?
Do labels map to attributes?
While it is possible to use a direct mapping of the property-graph model to the entity-relationship model (used by Grakn), it is highly likely that limitations and shortcomings of the property graph model will be transferred. This is why Grakn does not provide or encourage a completely general migration tool. Every Grakn knowledge graph should be powered by a thought-out model (ie. schema) that is tailored to the intended domain.
To outline how one can easily (re)model a dataset in Grakn, the key is to create a schema that closely resembles how we perceive data in the real world in terms of things and their interactions. This easily maps onto the Entity-Relationship-Attribute model Grakn uses. It is common to iterate several times before settling on the final schema (though it can always be extended later).
Then we can:
ask intuitive questions (in the form of Graql queries) - using the defined Entities/Relationships/Attributes that map closely to our mental model
build an intelligent database that is capable of reasoning over data the same way we do, by adding logical, deductive rules that apply in our domain
I encourage to you check out this blog post on the challenges of working with graph databases, and for any domain specific modeling questions head over to the Grakn community forum.
Good luck and welcome to Grakn!
If you map your property graph directly to GRAKN, you will end up with relations that are most likely named as verbs connecting only two objects (one of which will appear to be a subject and the other an object). GRAKN will be fine with this, but as mentioned previously, may make leveraging all the goodness in GRAKN more difficult. In particular, converting existing graph structures to hyperedges may take some significant reengineering. But the good news is that the ETL would be straightforward.
A better solution would be to define your ideal schema first in GRAKN (taking advantage of hyperedges), then fashion an ETL to populate the schema. In such a case, the ETL might be simple or complex. It would depend on how complex your original data was and how complex the new schema was.
What is the relationship between an FDD and a DFD of the same system?
Functional decomposition is about partitioning the functionality of a big complicated system, into smaller, preferably simpler parts. The FDD is a tool that aids you in this process. Basically, you are breaking down of the capabilities of a complicated system, into a set of more specific logically grouped capabilities.
Now, a data flow diagram deals with how data flows through a system for a specific function of the system. So, each of the above mentioned capabilities might very well have their own unique data flows.
For example, if you have an FDD diagram describing a blogging system. You might have functions for say, displaying a blog post, editing a blog post and potentially sending a link to a blog post to a friend.
These three functions will all have fairly different data flows, which can be modelled separately with DFDs. So, I'd say the relationship between these two types of diagrams are that one can help identify the individual functions, which might, or might not, need to have an associated dataflow mapped.
Hope that is helpful.
I am looking at a specific problem where I need to build a recommender.
The generalized problem is as follows,
Each user has registered for (say) x courses (c1, c2, c3, .. cx)
Depending on each course, I need to provide (say) top 5 tips/recommendations to the user (e.g. study materials that could be useful etc)
I need collaborative elements to be applied to learn what recommendations are proving helpful to users.
I looked at the recommendation engines like Apache Mahout Taste, but I am unable to model my problem in a way that it looks like the examples shown. (The extra filtering criteria where a user is associated with one or more courses and each recommendation/tip could be associated with one or more courses is throwing me off.)
Please let me know if there is any good way of modeling such a problem? Any pointers to documentation/examples would be very appreciated.
I am just starting my research in this area so please bear with me if I have misunderstood any concepts.
Thanks,
Vivek
This may be too simple to need a recommender. If each course has a set of associated materials, then it seems clear that taking course c1 means they should have the associated materials for the course. Maybe rank from among all materials by popularity. That might be very easy and accomplish most of what you need.
If you want to model this as CF, you can; I don't know how much data you have. If you have just a handful of users and courses it will be too sparse to give useful answers.
Your users have relations to two things: courses and materials. You don't want to recommend courses, but rather materials. I would build two data models: one with user-course info, and one with user-material purchase info. Use the user-course data as the basis of a UserSimilarity implementation that defines user-user similarity. Then piece that together with a NearestNUserNeighborhood, a GenericUserBasedRecommender, but using the other user-material data model.
You will be using user-user similarity based on courses to make recommendations from among materials.
An answer to a question of mine on DB design suggested something called single table inheritance. I've done a bit of searching on that, but I can't seem to find that much clear information on it.
Basically what I seem to understand from it is that you have a big table with all the fields in it and also a type field - and then your ORM layer uses the type field to give you different object views. Is that correct?
More importantly, is single table inheritance an 'approved' database design technique? By that I mean is it 'sensible' to use it? Is it also safe to use it, or does it cause problems?
The other issue is how well this works in rails? I've found a few references to it from rails - but does it cause problems by doing things the non-conventional way?
Any help much appreciated.
Is it a good idea ? It depends. It breaks Normalization in that a table does not have a single purpose. What happens when you extend the base class for the nth time ? You will have to add columns to the table. Most modern DBs don't have a problem with that as you can modify the table but what about refactoring and removing a class. Now you have columns that don't have a purpose.
A rule of thumb - if most of design has been worked out, it's probably safe to use. If the design is changing frequently - you have other issues and you need to lock down your use cases/user requirements. (yes, not really XP friendly)
I don't know about the Rails effects.
STI is a way of dealing with a mismatch between object- and database-oriented thinking. It allows a reasonable representation of the information within the database and a different representation within the object model.
For example, I have an application where each of my products contains one or more fees, each calculated slightly differently. Within my object model I want to have subclasses of a Fee class, each of which knows how to calculate itself. I don't really want to have a table per fee type though: so I create Fee as the base class and fees as the table, which contains the union of all the fields needed across all the sub-types, plus a "type" column whose value corresponds to the name of the relevant sub-class. ActiveRecord handles the plumbing thereafter.
In short, Single Table Inheritance (STI) is a design pattern that allows a mapping of OOP inheritance relationships to the database. If you define any subclasses from your ActiveRecord model objects, then you should consider STI.
STI is (originally?) documented in Martin Fowler's 'Patterns of Enterprise Application Architecture' book, and is also described in DHH's canonical Rails book 'Agile Web Development with Rails' (section 18.4, I think.) I refer you to these books because they provide a much better explanation than I could hope to do in this space.
I strongly disagree with the sentiment expressed at www.matthewpaulmoore.com (linked by robintw in this thread), that STI is inherently a bad thing. This seems to be a somewhat naive view that discounts the usage of OOP inheritance. I have used STI to create some elegant solutions in Rails, but you can abuse any design pattern, I suppose.
Definitive reference. It allows a single table to store multiple objects that have a common base class.
Ruby on Rails uses a library called Active Record. This is a common Ruby framework that supports STI.
I can only speak from the (new) ADO Entity Framework perspective, which includes table-per-type (TPT) functionality.
Here is a good series of blog posts introducing the core concepts (using the Entity Framework) and there is an MSDN paper on it also here.
There also seems to be some guidance when using nHibernate for TPT, it's located here.
There's this link which explains table-per-type inheritance in SQL Server. This seems to have a pretty good summary and introduction to the concept.
I'm not sure what impact it would have on Rails.
I've just seen http://www.matthewpaulmoore.com/articles/1276-ruby-on-rails-code-quality-checklist#sti which suggests its a bad idea.
Generally I find it useful, but I've encountered some bugs
The example in that link may provide a useful picture of how you might use it.