I would be careful about thinking of sharing a database with another service. Every time a database change is made, you now how to verify that the change does not affect any other service that uses that database. You are back to doing monolithic releases where tests are being run against every service to see if you can release. This will be compounded if the service is owned by another team as database changes now require cross-team communication which slows down development and creates issues of scheduling etc.
One of the benefits of SOA and microservices is that the boundaries are at the API level which remains relatively stable across releases. This allows a microservice to individually release without needing to test the whole system. Having a separate database per service allows this type of development to proceed.
In terms of referential integrity, it will depend on your domain. If referential integrity is mission critical to your business, then I might propose finding less granular places to split up your monolithic. For example you might have one service that represents all the domain logic and relationships of core domain entities. You then might have supporting services, like an email service, an authentication service, etc. Your domain service might not be "micro" but if referential integrity is important, don't risk it by going too granular in your service design.
If you relax your referential integrity to be eventually consistent/application maintained, then a whole new world opens up. You can have services that are the system of record for certain domain concepts/entities and then denormalize the data for fast queries in other parts of the system. This sharing of data takes time to propagate but for most domains that is not a problem. You have to decide if it is ok to show or perform validation against this eventually consistent data.
If you have business rules that would be have to be performed by going to multiple services to be validated and performed than your domain might not be a good a choice for SOA. If instead your business represents workflows, where each service performs some step in a larger business flow, this would be a much better use case. I have found that the best place to break up a monolith is at bounded contexts. Sometimes these services end up still being pretty large, but that is the way the domain is modeled. It will be painful if you go too granular as you will be generating a large number of network requests to service queries or perform data manipulation that required a few joins in your monolith. You also won't have referential integrity as you could make a call to validate a record exists in another service and have it be deleted right after the call completes.
One way to maintain eventual consistency between records is to have a process that looks for orphaned records or that links records together. You could provide users a place to clean up these orphaned records in the UI to allow them to take action. At query time you can detect issues and let the user know as well to allow them to fix the issue.
You can use tools like rabbitmq or Kafka as a mechanism for services to share data that will be eventually consistent.
As an example I might have an eventually consistent store of user's full names from the user service in my service so that I don't need to query the user service constantly to display the full name. I might listen to events coming through kafka from the user service in order to build up my eventually consistent store. Now full name lookups are fast in my service at the cost of data duplication.
The integrity here will be strong as user's full names probably won't change that often. Other datasets that change a lot might have less integrity as the queue/kafka might be behind.
Each service that owns a record is responsible for the integrity of that record. The relationships with other records will have to be more flexible. As a consumer service of a record from another service, you will have to listen and adapt to changes that occur to the record inside its owning service since it has the final say to the current state of the record.