The next step is to look at who will use the data and how they will use it. When you design your Streamed environment, take into account considerations such as.

In short, who owns the data? Let's talk about what this means.

Data ownership refers to the right to create, change, or delete data. Data ownership can be described by a level and model.

Data ownership can be enforced at the site, user, and table levels. Table level ownership can be further subsetted at the row (horizontal) and column (vertical) levels. For instance, regional databases may have access to personnel data, however, only headquarters can make changes to the data (Site level). A further limitation could be that only HR employees are allowed to change the data (user level). However, these HR employees are only allowed to change HR data (table level). Of these HR employees, only those HR employees responsible for a division can change the records for the employees in that division (row level/horizontal). And one last limitation, only the division lead can change the salary and bonus fields for those employees (column level/vertical).

Data ownership models are more specific to the site level of ownership. Single-Site ownership means that only one site in the distributed environment is allowed to make changes to a piece of data. A standalone Oracle database provides single-site ownership enforcement by default. Dynamic ownership is a single-site ownership model, but the ownership moves to the transaction site that is changing the data at a point in time. A master-slave distributed configuration is indicative of the dynamic ownership models. These models avoid data conflict by limiting data changes to a single "owner". If data changes are made at the slave sites, they are overwritten when the master site sends its data down to the slave site. This ensures that all users will have the same picture of the data when the master change is committed and distributed. Shared ownership means that anyone can update the same piece of data at any time, at any site. A multi-master environment with asynchronous distribution is indicative of a shared ownership model. This model can lead to data divergence and conflicts, as multiple owners could be making different changes to the same data at different sites. Once these changes have been committed, the data diverges between the sites. For distributed environments using a shared ownership model with asynchronous propagation, you must implement some method of conflict resolution to reconcile the data conflicts. The conflict resolution will dictate what changes are kept, or discarded in the event of data change conflicts. Oracle's Replication provides support for the dynamic and shared ownership models.

Put the where, who, and how together and you get Single-Site ownership with unidirectional change flow or Dynamic and Shared ownership with bidirectional change flow. Amazing how it all comes together!

Distinguishing between who owns the data, and who will just use the data, will drive how changes flow through your distributed system and where capture and Apply processes must be configured. It will help you determine what conflict resolution rules are required. Each site Apply process must be configured to enforce these rules. It will also influence your table design in that you must make sure you have the necessary columns in the table to support the conflict resolution method implemented.