Databases Reference
In-Depth Information
of an application's needs, and the questions that arise in the course of satisfying this
need.
1
Here's an example of a user story for a topic review web application:
AS A
reader who likes a topic,
I WANT
to know which topics other readers who like the
same topic have liked,
SO THAT
I can find other topics to read.
This story expresses a user need, which motivates the shape and content of our data
model. From a data modeling point of view, the
AS A
clause establishes a context com‐
prising two entities—a reader and a topic—plus the
LIKES
relationship that connects
them. The
I WANT
clause then poses a question: which topics have the readers who like
the topic I'm currently reading also liked? This question exposes more
LIKES
relation‐
ships, and more entities: other readers and other topics.
The entities and relationships that we've surfaced in analyzing the user story quickly
translate into a simple data model, as shown in
Figure 4-1
.
Figure 4-1. Data model for the topic reviews user story
Because this data model directly encodes the question presented by the user story, it
lends itself to being queried in a way that similarly reflects the structure of the question
we want to ask of the data:
START
reader=
node
:users(name=
{readerName}
)
book=
node
:books(isbn=
{bookISBN}
)
MATCH
reader-[:LIKES]->book<-[:LIKES]-other_readers-[:LIKES]->books
RETURN
books.title
Nodes for Things, Relationships for Structure
Though not applicable in every situation, these general guidelines will help us choose
when to use nodes, and when to use relationships:
1. For agile user stories, see Mike Cohn,
User Stories Applied
(Addison-Wesley, 2004).
