This answer is based on the additional information from the comments.
If the database is part of your system then whenever other system requests those data, your system has to offer them (let's disregard for a moment how is it done - this is true also if other system reaches directly to the database1). So from perspective of your system if other system asks for data, your system has to provide that data. So for your system the other system is an actor and the use case would be something like "Provide news data" (or anything you seem relevant).
If your system had sent the aggregated data to some other system as part of your first use case then quite theoretically it may be the only UC you have.
On the other hand you may also consider some sort of administration tasks that has to be done. Those may create additional use cases as well (e.g. add "new newsfeed" or "manage client privileges").
As a rule of thumb if your data comes in, they have to go out. If one use case has only inflow of data there must be at least one other use case which offers the outbound flow of data.
1 One can argue that this is no use case because it is automatically handled by the database engine. This is not true. As already mentioned, database is part of your system. Even if the direct access to the data is offered by database engine, it is also part of your system (even if a legacy one) so your system offers that.
Of course that is a poor way of designing system. The access to the data should be controlled by the system in a more manageable way. So I would definitely recommend building an interface for that. Anyway, you have a use case.