- NVivo Training
- NVivo Related Services
- NVivo Support
- Who We Are
- Contact Us
- Animated Tutorials
- NVivo 8
- NVivo 9 & 10
- Tutorial 1 - Importing sources into NVivo 9 & 10
- Tutorial 2 - where are my case nodes and casebook gone in NVivo 9 & 10?
- Tutorial 3 - auto-coding
- Tutorial 4 - coding audio or any media file
- Tutorial 5 - 'uncoding' incorrectly coded content from a node
- Tutorial 6 - Transcribing within NVivo
- Tutorial 7 - Formatting in Word for Auto-coding in NVivo - Part 1
- Tutorial 7 - Formatting in Word for Auto-coding in NVivo - Part 2
- Tutorial 8 - Using the Coding Stripes and Highlighter
- Tutorial 9 - Auto-coding Media Files in NVivo
- Tutorial 10 - Customizing the work space for coding video
- Tutorial 11 - Backing up your Data
- Tutorial 12 -Importing from Excel into NVivo
- Tutorial 13 - Using a coding strategy in NVivo
- Tutorial 14 - Exporting Video from Nodes to HTML
- Tutorial 15 - Creating & Linking NVivo Memos
- Advanced - Using NVivo Queries
- QSR Videos
- Book Your Training Now!
- My Profile
Relationship Nodes in NVivo
I responded to a query on the LinkedIn NVivo user group today from someone asking for general ideas and interesting ways of using relationship nodes in NVivo. He said:
I've finished coding & analysing my pilot data. I've realised that the content of a Parent Node A broadly comes before Parent Node B. I'm trying to structure the child nodes in A so that I keep their distinct nature and link them to the child nodes in B using Relationships. Now that I'm starting into the next phase of coding I want to be 'clever' and reflect this in my coding. Am I trying to be too 'clever'? Should my question be 'can someone describe how they have used relationships'?
I've trying looking up youtube clips re Relationships and can't find anything ..... anything on 'Links' might be helpful too....many thanks in advance....
My response was that I think it depends on the nature of the relationship between the child nodes in parent ‘A’ and ‘B’. You would first have to define the relationship type in ‘Classifications->Relationship Types. Then, form the relationships and code content that support the relationship to these new nodes. Remember, a relationship is a node in its own right. So let’s say the nature of the relationship was one of sequencing phenomena. If you believed that Node A/child 1 had to be present to influence an outcome as coded in Node B/child 1. You might define the relationship type to be ‘precedes’ or ‘is conditional on’ for example. You would then create a relationship between Node A/child 1 and Node B/child 1. Then, using a query or manually, you would code some of the content of either node that supports this hypothesis to the relationship node as means of testing or validating this hypothesis against the data. Having created a series of these relationships, you might then drop them into the modeller to represent the relationship in a more diagrammatical way as they appear quit linear when looked at as a table of relationships in nodes/relationships list view.
Sometimes, people think that because there are just two components to a relationship when you create a relationship node, Node A/child 1 to Node B/child 1 that you are limited to just two items. This is not the case. Let’s say there are several parts to the relationship instead of just two, Node A, precedes node B while node C or D will be the possible outcome. First link A to B and define the relationship type as ‘precedes’. Then link B to C and define as ‘first possible outcome’. Then link B to D and define as ‘second possible outcome’. When modelled you will have four connected nodes linked through relationships in a ‘Y’ shape. I have no facility hear to show you how this would look in the modeller but you can take my word for it that you can make sophisticated conceptual maps of the relationships across and between your nodes/codes. These models can be graphically impressive and are only limited by the scope of your analysis and your imagination when it comes to making a visual display.
Relationships nodes are often underutilised in NVivo. For me, they are a brilliant way of pulling things together at the end and for conceptualising more abstract themes whilst still ensuring that your relationships are in fact rooted in the data. They can be combined very efficiently with the modeller and of course models themselves can be exported into software with more graphical capabilities than NVivo has if that’s your cup of tea.
This is just one example of the myriad of ways that relationships can be tracked and mapped in NVivo. I’m sure others will come up with some brilliant examples from their own research project. I hope this helps!