Data-flow diagrams use arrows to show the direction of the flow of data. Whether you use Gane & Sarson or Yourdon & DeMarco), a unidirectional arrow means an unidirectional flow:
Your first diagram means that the data flows from the back-end to the front-end and only in that direction. There is no need to tell that it's read-only, because the flow is unidirectional.
If you wanted the front-end to read and write data from/to the back-end, you'd need a second arrow in the opposite direction. A common practice is to use a bidirectional arrow (Yourdon uses it in several examples, Gane and Sarson even recommend it for keeping diagrams simple).
If you want to have it read-only, but indicate the data elements used to find the relevant data, you may use Gane & Sarson's notation of "search argument specification" (which is meant to apply to data stores and not processes):
Source: Structured System Analysis, Chris Gane & Trish Sarson
Your second diagram would be misleading: not only would it show the flow in the wrong direction, but in addition, the DFD convention is to label the arrows with the kind of data that flows along:
Arrows should be named to indicate the meaning of the data that moves along the flow that is, a noun.
Data flows with a verb name signify a process that has been omitted. Data flow in and out of a process must be altered in some way.
-
Source : Visual Paradigm tutorial
This convention explain also why double-sided arrows are quite rare in practice, as soon as you label the flow: the flow back would have a slightly different name (e.g. updated data, corrected data, validated data).
The only ambiguity in your diagram is who initiates the flow: is it the front-end that reads or the back-end that writes? But this is normal: it's not the purpose of this kind of diagrams to go in such details. You could add an arrow "request data" to show that the front-end initiates the communication, but this would quickly overload your diagram and the added precision would come at the expense of the readability.
