Application background A short description of what the application should doI'm developing an application which analyses DNA sequences. The user will load a certain file containing a DNA sequence. Then the user can click on a button to search for ORFs (parts of the DNA sequence with specific features). These ORFs can then be BLASTed (searching annotation about these sequences in a public database). One important requirement was that the DNA sequence (loaded by the user), the ORFs (found by the application) and the result form the BLAST will be saved in a database. ProcessI will first describe what I did and why I changed some things to clarify why the diagram is as it is now. I'm just new in using UML and every comment is welcome.Use case diagram version 1.0I doubted about saying that the databse is an actor, based in this question I decided that the databse is just for storage and I omitted it. resulting in the final version of my diagram.Use case diagram version 1.1 I spoke to some people about UC_07, some would argue that this would be too technical. However my vision is that extracting this common step clearly shows the limitations of the the application; while the database is not running (due to an error e.g.) all the three use cases (2,3,4) would be afflicted by this.QuestionShould UC_07 be an seperate (sub) use case or not? Further as described above (the database isn't an actor if it's just used for storage), however how could UC_07 be described if the database can't be seen as an actor? Because in general it will look something like: 1. The application opens the database connection 2. The application sends the data 2. The database stores the dataOther suggestion/improvements about the use case diagram are also really appreciatedEDIT because of comments under the answer of AmonLet's suppose I decide to ommit UC_07 should I mention the data storage in the databse in the UC_2-4 or not: 
Use case diagram (UML): Should database storage be an sub use case (in this diagram)?
uml;use case
The use case diagram gives us an overview of requirements, and illustrates how various actors interact via the system.There are many ways to actually capture use cases. An important one is single-sentence user stories. For example: As a User, I want to search ORFs. This is a valid use case. Now you are proposing a use case like As a User, I want to save data in the database. That may be a valid use case but it really does not seem like it.This is clearer if we use a tabular use case format. Here, we explicitly list the steps that the user performs, and how the system responds. For example:Search ORFsPrecondition: A file is loaded.Primary Actor: UserTrigger: The User clicks on the search button.Scenario:The User enters an ORF into the search box and submits the search.The System displays a list of all matching sequences in the loaded file.Postcondition: The system can receive the next search query. Some steps in this scenario might be so complex that they are described in another use case that would then be included. But a use case is always an ActorSystem interaction. If you have a save data in database use case where the user clicks on a save to DB button then you might have a real use case. Otherwise, the database is just an implementation detail.That the database seems to be important to your users could mean that you haven't actually captured all use cases. You mention the constraint that the database must be running in order for those use cases to work  that is a precondition, or perhaps an exception scenario. We could extend the above detailed use case with an alternative flow:Exceptions:If the database is offline or returns an error, the System displays an error message to the User.If a the database is offline check is common to many use cases, you can extract that common step into a shared use case. E.g. for web applications, we would extract the user is logged in check to a separate use case instead of repeating that in each use case.What is the user interest here? They don't want to enter a search if it can't be answered. So the use case actually is As a User, I want to see a warning when the database is down or As a User, I want to be prevented from searching when the database is down.