Accessing Data Stored In A Database System

Computer-implemented methods are disclosed for accessing data stored in a database system comprising a controller configured in such a way that data is stored with relationships between data-elements of the data, and with enforcement of data integrity. The method comprises receiving, by the controller, a call by first user to a first access-procedure for accessing a first data-element, the first access-procedure including a call to second access-procedure for accessing a second data-element based on a relationship between the first and second data-elements; performing, by the controller, the call to the first access-procedure; verifying, by the controller, whether the first user is authorized to access the second data-element according to access authorization data; performing, by the controller, the call to the second access-procedure; and returning, by the controller, a result of the access to the second data-element including an indicator of authorized access to the second data-element. Computer programs and database systems suitable for performing such methods are also disclosed.

BACKGROUND

The present disclosure relates to methods, systems and computer programs for accessing data stored in a database system.

A database system is a software-based system that provides applications with access to data stored in the database system in a controlled and managed fashion. By allowing separate definition of the structure of the data, the database system frees the applications from many of the onerous details in the care and feeding of the data. A database system may be implanted in a centralized way or distributed among different computing and storage resources.

In the context of database systems, a data-element may be defined as a uniquely identifiable representation of a real-world entity by means of a collection of fields. Each field may have a name and a different type. Examples of data-elements are rows (in relational database systems), objects (in object-oriented database systems), nodes/edges (in graph database systems), etc.

Different kinds of database systems are known depending on their data model, i.e. how the data is structured in the database system. For instance, relational database systems store data in the format of tables where each table represents a type of data and each row represents a data-element.

Object oriented database systems store data in the format of objects comprising a set of fields and normally a set of methods. Graph database systems store data-elements based on nodes and edges. Document database systems store data in a semi-structured data format, such as XML or JSON. Key-value database systems store data in tables with two columns: the first column is the key of the object that will be used to find the object whenever needed and the second column is an array of bytes with the object itself.

Typical database systems may be configured to store data as well as relationship(s) between data-elements of the stored data. Some database systems support these relationships either because they are part of the data model (e.g. nodes linked to edges and edges to nodes in a graph database system) or because they are part of the database schema (i.e. a field in an object with a reference to another object). Typical database systems may comprise a controller configured to ensure integrity of the data stored in the database system. These main features (relationships and integrity) are discussed below.

Relationships between data-elements may be implemented in different ways depending on the type of database system. For instance, in a relational database system, two objects can be linked or interrelated by e.g. using a column in a table for storing a foreign key pointing to another data-element in the same or another table. Object oriented database systems may implement relationships by e.g. having a field in a class which is a reference to another object. In Graph database systems, intrinsic relationships may be implemented between nodes and edges and vice versa. Other ways of implementing relationships between data-elements are possible in database systems with functionalities aimed at that purpose.

Integrity refers to a condition of the data stored in the database system in which all the data (elements) in the database system are correct in the sense that a target state of the real world is represented by the stored data, and rules of mutual consistency are satisfied (e.g. referential integrity in relational database systems).

For example, in a relational database system, a table PERSON and a table CAR may be inter-related through a relationship indicating which cars are owned by which person. To this end, table CAR may comprise a column for storing identifiers of PERSON so that different cars may point to the same person. Besides, table PERSON may include a column for storing the number (or counter) of cars owned by the person.

Ensuring that all the identifiers of PERSON stored in table CAR are pointing to existing rows in table PERSONS implies that integrity of the data is guaranteed with respect to satisfaction of mutual consistency rules.

Keeping the counter (of cars) of a person consistent with the number of cars “pointing” to the person implies that integrity of the data is guaranteed with respect to a target state of the real world.

In order to ensure integrity, a controller of database system (or database controller) may permit defining database constraints which, in some examples, may be intrinsic to the data model of the database system. For instance, a foreign key constraint may be used to ensure that all the persons referenced in table CAR correspond to existing rows of table PERSON. This constraint will prevent deleting a person that is owner of a car.

A database controller may also permit defining triggers (by the database administrator) aimed at triggering some action when a data-element is inserted, removed or modified. A trigger may be used e.g. for updating the counter of cars of a person when a car is unlinked from the person (counter is decreased) or linked to the person (counter is increased).

Examples of typical database systems comprising the previously discussed main features (relationships and integrity) are relational database systems, object-oriented database systems, graph database systems, key-value database systems with mechanisms to enforce data integrity such as triggers (e.g. Cassandra), etc.

Examples of database systems lacking some of the previously discussed main features (relationships and integrity) are document database systems such as e.g. MongoDB (integrity is not enforced), schema-less database systems such as e.g. LevelDB (relationships are not defined), etc.

Nowadays, database systems are mainly aimed to share data among different members and/or departments within the same organization. Thus, the shared data is owned by the organization and a single database administrator (DBA) is in charge of deciding what can be accessed and by whom.

Database controllers provide mechanisms for controlling access by users to data stored in the database system. Current database systems allow users to control access to different schema elements (e.g. tables, columns, procedures . . . ), by defining privileges or permissions at the level of schema elements. Some database systems also provide functionalities for limiting which data is shown to which user (or group of users) through e.g. some kind of view mechanism based on filters (e.g. showing only those rows with a certain value in a given column).

These mechanisms based on privileges at the level of schema elements and/or views by filtering data operate under integrity constraints (defined by corresponding DBA) such that integrity of the data accessed with said mechanisms is ensured.

An object of the present disclosure is improving the methods, systems and computer programs for accessing data stored in a database system supporting relationships between data-elements and enforcement of data integrity.

SUMMARY

In an aspect, a computer-implemented method is provided for accessing data stored in a database system comprising a controller configured in such a way that the data is stored with relationships between data-elements of the data, and with enforcement of integrity of the data. A first data-element and a second data-element of the data are stored in the database system with a relationship between the first data-element and the second data-element.

The first data-element is stored in the database system encapsulated by one or more first access-procedures so that the first data-element is accessible exclusively by calling the one or more first access-procedures.

The second data-element is stored in the database system encapsulated by one or more second access-procedures so that the second data-element is accessible exclusively by calling the one or more second access-procedures.

The database system further stores access authorization data indicating, at data-element level, whether access to second data-element is authorized to a first user identified in the database system through corresponding credentials that enable the first user to log in and operate in the database system.

The method comprises receiving, by the controller, a call by the first user to a first access-procedure of the one or more first access-procedures for attempting to access the first data-element, said first access-procedure of the one or more first access-procedures including a call to a second access-procedure of the one or more second access-procedures for attempting to access the second data-element based on the relationship between first and second data-elements.

The method further comprises performing, by the controller, the call to said first access-procedure of the one or more first access-procedures, and verifying, by the controller, whether the first user is authorized to access the second data-element according to the access authorization data.

The method yet further comprises performing, by the controller, the call to said second access-procedure of the one or more second access-procedures, and returning, by the controller, a result of the attempt to access the second data-element, including an indicator of whether the first user is authorized to access the second data-element.

In the case that first user is not authorized to access the second data-element, the returned indicator may indicate that the second data-element exists but is unknown to the first user due to non-permitted access. The returned indicator may be processed by first access-procedure (of the one or more first access-procedures) so as to produce a consistent result of the access to first and second data-elements.

The proposed method thus permits the first user to obtain a consistent result of the access to first and second data-elements (following the relationship between them) irrespective of whether a consistent or inconsistent view of first and second data-elements is provided to the first user according to access authorizations (at data-element level). A result, view, etc. of interrelated data-elements is consistent if integrity constraints are satisfied.

Indeed, access authorizations defined at data-element level may permit implementing powerful data view functionalities with small granularity (data-element level). However, in some cases, such powerful views may not be consistent when e.g. first and second data-elements are interrelated and access to second data-element is not allowed to first user.

In an example, first data-element may include data of person P1, second data-element may include data of car C2whose color is Red, and a relationship between P1and C2may be defined indicating that P1owns C2. If first user is allowed to access P1but not C2, a view of which car is owned by person P1would not be consistent (in a prior art database system) because C2is not accessible by first user. That is, only the relationship part between P1and C2at the side of P1(e.g. a reference to C2) is seen by the user, but C2(i.e. the relationship part at the side of C2) is not seen by the user.

In another example, first data-element may include a number of cars NC owned by person P1, NC being equal to 1 because P1only owns car C2. In this case, an inconsistent view of person P1could also result (in a prior art database system) because NC=1 indicates that P1owns one car but C2is not accessible by first user.

These inconsistencies cannot be solved in prior art database systems based on e.g. integrity constraints or triggers.

Integrity constraints apply to the data stored in the database system as a whole and, from the point of view of the database system there is no lack of integrity because P1, C2and proper link (relationship) between P1and C2exist.

Triggers are not useful in this case either, according to similar reasons. Moreover, triggers react to events such as addition, removal, or modification, since they are operations that may break the integrity of the data stored in the database system.

Triggers may have been used to correctly update the number of cars NC owned by P1upon creation of car C2. However, triggers are useless to provide a consistent result of accessing P1with one car (NC=1) since said car is not accessible by first user.

The returned indicator is very valuable in the sense that a consistent result of accessing the data may be provided to a user, even if the data is seen by the user as inconsistent depending on access authorizations attributed to the user. The returned indicator may comprise any data structure including e.g. a list of which accesses have been successfully performed and which accesses have not been successfully performed, as well as a reason of each unsuccessful access.

In an example, the returned indicator may represent that both P1and C2have been successfully accessed. The first access-procedure (of the one or more first access-procedures) may thus receive the returned indicator and produce, based on the returned indicator, a result comprising data reflecting that person P1owns ONLY one car (NC=1) which is C2and whose color is Red. This result does not only reflect that P1owns C2, but it further indicates that C2is the ONLY car owned by P1, since the returned indicator may represent that all cars interrelated with (owned by) P1have been successfully accessed.

In another example, the returned indicator may represent that P1has been successfully accessed but C2has not successfully accessed because user is not allowed to perform such access. The first access-procedure (of the one or more first access-procedures) may therefore produce, based on the received indicator, a result comprising data reflecting that P1owns ONLY one car (NC=1) which is ‘unknown’ and whose color is also ‘unknown’. Therefore, a consistent result may be produced even though a lack of integrity exists for first user in relationship between P1and C2, since first user is not allowed to access C2.

Alternatively, the first access-procedure (of the one or more first access-procedures) may produce, based on the returned indicator, a result reflecting that P1does not own any car according to the data that the first user can view according to authorizations (at data-element level) attributed to the user. This result may be implemented by making the field NC (number of cars) consistent with the cars that the user can view. In this particular case, NC may be forced to be zero in the result provided to the user. This result is consistent even though the data viewed by the user is not consistent (P1has NC=1 but no car owned by P1is viewed by the user).

The suggested method may permit very secure access to data-elements since only access procedures encapsulating data-elements are allowed for accessing data-elements. Hence, creators (or owners) of the access procedures may implement security functionalities therein, so that e.g. data stored in the database system may be shared by multiple users subjected to suitable access authorizations (at data-element level). This may be seen as a new paradigm in the sense that each creator/user may be responsible for maintaining its own (sub) schema (or model) in the database system in comparison to prior art database systems wherein a single DBA is typically in charge of maintaining the database system.

The access performed by the method may be read access or update access.

In some examples, the database system may be a relational database system. Hence, first data-element may be a first row of a relational table, second data-element may be a second row of a relational table, and the relationship between first and second data-elements may be a relational relationship such as e.g. a foreign key included in first row pointing to second row. Access-procedures may be stored procedures.

Alternatively, the database system may be an object-oriented database system. Hence, first data-element may be a first object of a class, second data-element may be a second object of a class, and the relationship between first and second data-elements may be an object-oriented relationship such as e.g. a reference included in first object pointing to second object. Access-procedures may be class-methods.

Further alternatively, the database system may be a graph database system.

Hence, first data-element may be a node and second data-element may be an edge, or first data-element may be an edge and second data-element may be a node. The relationship between first and second data-elements may be a graph relationship intrinsically defined between node and edge, or between edge and node. Access-procedures may be graph procedures.

Access authorization data at data-element level may be stored in the database system based on that a data-element either belongs or does not belong to a set of data-elements (or dataset), as described in detail in other parts of the disclosure. The database controller may thus verify whether first user is allowed to access second data-element by consulting access authorization data according to any of said approaches, i.e. with or without datasets.

Grouping data-elements into datasets may simplify management of access authorization permissions to users, and also may allow improving efficiency since access authorizations may not require to be checked for every single access to a data-element. Instead, once an access authorization has been checked, it may not be necessarily checked again until a data-element of another dataset is accessed.

Access authorization data at data-element level (with or without datasets) may comprise a start date and/or an end date of the authorization, so that the database controller may verify whether first user is allowed to access second data-element further considering whether current date is later than start date and/or earlier than end date of the authorization.

The database system may further comprise call authorization data at access-procedure level indicating which user is authorized to call which access-procedure. The database controller may thus verify whether first user is allowed to call second access-procedure (of the one or more second access-procedures) by consulting said call authorization data.

Call authorization data at access-procedure level may be stored in the database system based on that an access-procedure either belongs or does not belong to a set of access-procedures (or function-sets), as described in detail in other parts of the disclosure. The database controller may thus verify whether first user is allowed to call second access-procedure (of the one or more second access-procedures) by consulting call authorization data according to any of said approaches, i.e. with or without function-sets.

Function-sets provide the user with an abstraction for grouping a set of access-procedures with same call authorization data. It is worthy of mention that an access-procedure may belong to several function-sets.

Call authorization data at access-procedure level (with or without function-sets) may comprise a start date and/or an end date of the authorization, so that the database controller may verify whether first user is allowed to call second access-procedure (of the one or more second access-procedures) further considering whether current date is later than start date and/or earlier than end date.

A special functionality which may be called “impersonation” may be implemented by the method. In this case, the database controller may successfully call second procedure even though first user is not explicitly allowed to perform said call. In particular, the database controller may call (in representation of first user) second access-procedure (of the one or more second access-procedures) if first user is allowed to call first procedure (of the one or more first access-procedures) and the creator of said first procedure is allowed to call second access procedure (of the one or more second access-procedures).

In an example, first user may be authorized to call a first procedure created by a hospital database administrator (DBA), returning a total number of patients with a given disease. First procedure may call, for each patient, a second procedure (also created by DBA) that returns patient data (including disease) to first procedure, which performs the appropriate counting. First user may not be authorized to call second procedure, since it returns sensitive data of individual patients, but however may be able to call first procedure since it does not return any sensitive data to first user. This logic can be implemented with the “impersonation” functionality, based on that DBA is allowed to call second procedure.

In a further aspect, a database system is provided for accessing data stored in the database system, comprising a controller configured in such a way that the data is stored with relationships between data-elements of the data, and with enforcement of integrity of the data.

A first data-element and a second data-element of the data are stored in the database system with a relationship between the first data-element and the second data-element.

The first data-element is stored in the database system encapsulated by one or more first access-procedures so that the first data-element is accessible exclusively by calling the one or more first access-procedures.

The second data-element is stored in the database system encapsulated by one or more second access-procedures so that the second data-element is accessible exclusively by calling the one or more second access-procedures.

The database system further stores access authorization data indicating, at data-element level, whether access to second data-element is authorized to a first user identified in the database system through corresponding credentials that enable the first user to log in and operate in the database system.

The controller is further configured to perform a computer-implemented method for accessing data stored in the database system such as the ones described in other parts of the present disclosure.

In a still further aspect, a further database system is provided for accessing data stored in the database system, comprising a controller configured in such a way that the data is stored with relationships between data-elements of the data, and with enforcement of integrity of the data.

A first data-element and a second data-element of the data are stored in the database system with a relationship between the first data-element and the second data-element.

The first data-element is stored in the database system encapsulated by one or more first access-procedures so that the first data-element is accessible exclusively by calling the one or more first access-procedures.

The second data-element is stored in the database system encapsulated by one or more second access-procedures so that the second data-element is accessible exclusively by calling the one or more second access-procedures.

The database system further stores access authorization data indicating, at data-element level, whether access to second data-element is authorized to a first user identified in the database system through corresponding credentials that enable the first user to log in and operate in the database system.

The controller comprises a memory and a processor, embodying instructions stored in the memory and executable by the processor, the instructions comprising functionality to execute a computer-implemented method for accessing data stored in the database system such as the ones described in other parts of the present disclosure.

In a yet further aspect, a computer program product is provided comprising program instructions for causing a computing system to perform a computer-implemented method for accessing data stored in a database such as the ones described in other parts of the present disclosure.

The computing system executing these program instructions may be a part of the database system, i.e. a sub-system inside the database system configured to reproduce a computer-implemented method for accessing data such as the ones described in other parts of the disclosure, or may be the database system itself. For example, the computing system may be a controller included in the database system.

Any of the aforementioned computer program products may be embodied on a storage medium (for example, a CD-ROM, a DVD, a USB drive, on a computer memory or on a read-only memory) or carried on a carrier signal (for example, on an electrical or optical carrier signal).

Any of said computer programs may be in the form of source code, object code, a code intermediate source and object code such as in partially compiled form, or in any other form suitable for use in the implementation of the corresponding method. The carrier may be any entity or device capable of carrying the computer program.

For example, the carrier may comprise a storage medium, such as a ROM, for example a CD ROM or a semiconductor ROM, or a magnetic recording medium, for example a hard disk. Further, the carrier may be a transmissible carrier such as an electrical or optical signal, which may be conveyed via electrical or optical cable or by radio or other means.

When any of the computer programs is embodied in a signal that may be conveyed directly by a cable or other device or means, the carrier may be constituted by such cable or other device or means.

Alternatively, the carrier may be an integrated circuit in which the computer program is embedded, the integrated circuit being adapted for performing, or for use in the performance of, the relevant methods.

These and other advantages and features will become apparent in view of the detailed description and drawings.

DETAILED DESCRIPTION OF EXAMPLES

FIG. 1is a schematic representation of a relational database system100configured to perform computer-implemented methods for accessing first data-element101interrelated with second data-element103, according to examples.

First data-element may be a first row101of a first relational table102(called Person in the figure) and second data-element may be a second row103of a second relational table104(called Car in the figure). The relationship between the first row101and the second row103may be a foreign key105included in the first row101, the foreign key being a reference105to a unique key of the second row103. In this case, the relationship is implemented as a many-to-one relationship between Person102and Car104(many people may own same car). In other examples, a many-to-many relationship may be defined between Person102and Car104through an intermediate relational table storing rows each including a unique key of Person102and a unique key of Car104(one person may own several cars, and one car may be owned by several people).

In the particular example shown, each row101of the table Person102may store data of a person, such as e.g. a unique identifier of the person (R_ID: Row ID), a foreign key or reference to a unique key identifying a car (ER_ID: External Row ID) of the table Car, and other data (Other). Each row103of the table Car104may store data of a car, such as e.g. a unique identifier of the car (R_ID: Row ID), a color of the car (Color) and other data (Other).

Only one row101is shown in table Person102corresponding to a person with identifier ‘perl’ who owns a car with identifier ‘car2’ whose data (e.g. Color=‘red’) is stored in row103of the table Car104. Row101may contain other data ‘. . . ’ of the person, and row103may contain other data of the car

First rows101may be accessible exclusively by calling (i.e. encapsulated by) first stored procedures106. That is, first rows101may not be accessed through another way different from calling first stored procedures106.

Second rows103may be accessible exclusively by calling (i.e. encapsulated by) second stored procedures107. That is, second rows103may not be accessed through another way different from calling second stored procedures107.

The concept of stored procedure is well-known in the field of relational database systems. Exclusive access to rows of a table through a stored procedure may be implemented e.g. by revoking all privileges on the table and grating “execute” privilege to the stored procedure for accessing the table.

The database system100may further comprise access authorization data109indicating whether access to second row103is authorized to first user U1identified in the database system through corresponding credentials enabling the user to log in and operate in the database system100.

Credentials may be granted at the level of user or, alternatively, at the level of role. Different users may belong to the same role. In other implementations, both approaches (user and role level) may be combined for allowing (full or restricted) operation in the database system100.

In this respect, database system100may comprise a table110(called User) containing the users (or roles) that are allowed to operate in the database system. This table User110may store rows each including a user ID (U_ID) and corresponding credentials of the user such as e.g. username (U_N) and password (Pwd).

The access authorization data may be stored according to different approaches as described below.

According to a first approach, tables102,104that are exclusively accessible through stored procedures106,107may include a column which may be a hidden column or at least modifiable only by a controller115of the database system100. This (hidden) column may be used by the controller115to store the owner (who created the row) for each record/row.

Still in relation to first approach, a “granting” table may be used to store data indicating that a user/role is allowed to access a row/record ID (in any table accessible through stored procedures). In this “granting” table, only the owner of a row/record ID is allowed to add/delete/modify the data granting access to the row/record to other users.

In a second (alternative) approach, a column may be included in tables102,104that are exclusively accessible through stored procedures106,107based on same principles as described with respect to first approach. Furthermore, a “denying” table may be used to store data indicating that a user/role is denied to access a row/record ID (in any table accessible through stored procedures). In this “denying” table, only the owner of a row/record ID is allowed to add/delete/modify the data denying access to the row/record to other users.

In a third (alternative) approach, internal structures associated to the controller115(of the database system) may be used to store data indicating which row (accessible through stored procedures) has been created by which user/role, and which user/role has permitted access to which row granted by the creator of the row. Said internal data may be structured as hash tables, or b-trees, or lists, or the like. A mechanism may be provided for enabling the creators of rows to manipulate the authorization data in such a way that only the creator of a row is allowed to set/modify/remove authorization(s) of access to said row.FIG. 1shows an example according to this third approach.

In particular, database system100may comprise a table called Access_auth109indicating whether a row (identified by R_ID) is accessible by one or more users included in a list of users ID (U_ID). This list may further comprise for each user a start date (S_D) and an end date (E_D) of the authorization granted to the user. A record (of example) is shown in table Access_auth109indicating that row103of table Car104(R_ID=‘car2’) is accessible by user U1(U_ID=‘U1’) if current date is between start date ‘d1’ and end date ‘d2’. Another row (of example) is shown in table Access_auth109indicating that row101(R_ID=‘perl’) is accessible by user U1if current date is between ‘d3’ and ‘d4’ and user U4if current date is between ‘d5’ and ‘d6’.

In alternative examples, table Access_auth109may indicate whether a user (U_ID) has permitted access to one or more rows included in a list of rows (R_ID). This list may further comprise for each accessible row (R_ID) a start date (S_D) and an ending date (E_D) of the authorization.

Database system100may further comprise one or more tables111(called R_creator) indicating the user (U_ID) that has created a row (R_ID). In some examples, a single table R_creator111may be employed for all relational tables102,104(accessible through stored procedures). In alternative examples, a table R_creator111for each relational table102,104(accessible through stored procedures) may be considered.FIG. 1shows a single table R_creator111as an example.

In the particular case shown, row101of table Person102(R_ID='perl') has been created by user U4(U_ID=‘U4’), and row103of table Car104(R_ID=‘car2’) has been created by user U2(U_ID=‘U2’). Only the creator of a given row may be allowed to add/delete/modify data in table Access_auth109for granting access to the row to other users. In the particular example ofFIG. 1, the authorization to access ‘car2’ granted to user ‘U1’ between dates ‘d1’ and ‘d2’ may have been necessarily added by user U2(creator of ‘car2’). User U2may therefore be the only user permitted to delete/modify such authorization.

The database system may further comprise call authorization data indicating which users/roles are authorized to call which stored procedures for accessing corresponding rows. These authorizations for calling stored procedures may be implemented in the database system according to different proposals as described below.

According to a first proposal, if the controller115of the relational database system includes functionalities of controlling permissions for calling stored procedures depending on which user/role has performed the call, these functionalities may be used and/or customized for the aforementioned purpose.

Based on a second (alternative) proposal, an internal structure (table, list, etc.) may be used to store data indicating which users/roles are authorized to execute which stored procedures. This structure may further keep data on which users have created which stored procedures. A mechanism may also be provided for enabling the creators (owners) of stored procedures to manipulate this authorization data, in such a way that only the creator (owner) of a stored procedure is allowed to manipulate the authorization data regarding said stored procedure.

Still in relation to second proposal, a single internal structure may be used to store authorizations for all the stored procedures in the database system or, alternatively, an internal structure for each stored procedure may be employed. The internal structure(s) and mechanism(s) to store and manipulate this authorization data may be configured to provide delegation functionalities, so that an owner of a stored procedure may delegate to other users/roles the ownership of said stored procedure. This may be considered substantially equivalent to having several owners per stored procedure.

Based on a third (alternative) proposal, an internal structure (table, list, etc.) may be used to store data indicating which users/roles are denied to execute which stored procedures. Principles commented with respect to the aforementioned second proposal may be similarly applied in this case, but taking into account that permission is denied instead of granted.

FIG. 1illustrates an example of the second proposal based on granted permissions. In particular, database system100may comprise a table called Call_auth112indicating whether an access procedure or function (F_ID) is executable by one or more users included in a list of users ID (U_ID). This list may further comprise for each user a start date (S_D) and an end date (E_D) of the authorization granted to the user. A first record (of example) is shown in table Call_auth112indicating that function F10is executable by user U1(U_ID=‘U1’) if current date is between start date ‘d7’ and end date ‘d8’. A second record (of example) is shown in table Call_auth112indicating that function F20is executable by user U1if current date is between ‘d9’ and ‘d10’, and by user U4if current date is between ‘d11’ and ‘d12’.

In alternative examples, table Call_auth112may indicate whether a user (U_ID) is allowed to call one or more functions included in a list of functions (F_ID). This list may further comprise for each callable function (F_ID) a start date (S_D) and an ending date (E_D) of the authorization.

Database system100may further comprise a table113(called F_creator) indicating the user (U_ID) that has created an access procedure or function (F_ID). In the particular case shown, function F10has been created by user U4and function F20has been created by user U3. Only the creator of a given function may be allowed to add/delete/modify data in table Call_auth112for permitting execution of the function to other users. In the particular example of the figure, the authorization to execute F10granted to user U1may have been necessarily added by user U4(creator of F10). User U4may therefore be the only user permitted to delete/modify and/or delegate such authorization.

Any of the stored procedures or functions F10-F13, F20-F22defined in the database system100may be called by a user in different ways, such as e.g. from an application (executed by the user), from another stored procedure (in representation of the user), etc. In the particular example ofFIG. 1, a call114by (e.g. an application of the) user U1to the function F10and a call108by function F10(in representation of the user U1) to the function F20are represented.

It is worthy of mention that database systems according toFIG. 1may provide functionalities permitting different users to create different functions (or stored procedures) for accessing same data-element (or row).

FIG. 2is a schematic representation of another relational database system200configured to perform computer-implemented methods for accessing first data-element201interrelated with second data-element203, according to further examples. This figure illustrates a database system200similar to database system100ofFIG. 1. However, database system200may implement the access authorizations at row level based on that the row belongs to a set of rows (dataset). Similarly, database system200may implement the call authorizations at function level based on that the function belongs to a set of functions (function-set).

Table Person202may be substantially equal to table Person102ofFIG. 1with row201and foreign key205corresponding to row101and foreign key105, respectively. Principles similar to those described with respect to table Person102may thus be of application to table Person202.

Table Car204may be similar to table Car104ofFIG. 1with row203corresponding to row103. A further row corresponding to R_ID=‘car3’ and Color=‘blue’ is represented in this case. Foundations similar to those described with respect to table Car104may therefore be of application to table Car204.

Table User210may be substantially equal to table User110ofFIG. 1.

Principles similar to those described with respect to table User110may thus be of application to table User210.

Call214by user U1to the function F10and call208by function F10to the function F20may be substantially equal to calls114and108ofFIG. 1, respectively. Accordingly, principles similar to those commented in relation to calls114and108may be applied to calls214and208.

There is no table inFIG. 1that may substantially correspond to table Data_set215. This “new” table215may be used for implementing a grouping of “relational” rows201,203(accessible through access procedures) into datasets. Table Data_set215may store records including a dataset ID (DS_ID) and a list of Row IDs (R_ID) belonging to the dataset. In the particular example illustrated, person ‘perl’ belongs to dataset ‘ds1’, and cars ‘car2’ and ‘car3’ belong to dataset ‘ds2’.

Table DS_creator211may be similar to table R_creator111ofFIG. 1. One difference may be that table DS_creator211may store data indicating which user has created (i.e. owns) which dataset instead of which row as implemented in R_creator111. Table DS_creator211may store records including a dataset ID (DS_ID) and a user ID (U_ID) that correspond to the creator (owner) of the dataset. Foundations similar to those described with respect to table R_creator111may therefore be of application to table DS_creator211, but taking into account that ownerships are stored in DS_creator211on a per dataset basis. In the particular example illustrated, user ‘U4’ is the creator/owner of dataset ‘ds1’ and user ‘U2’ is the creator/owner of dataset ‘ds2’.

Table Access_auth209may be similar to table Access_auth109ofFIG. 1. One difference may be that table Access_auth209may store data indicating which user is allowed to access which dataset instead of which row as implemented in Access_auth109. Table Access_auth209may store records including a dataset ID (DS_ID) and a list of user IDs (U_ID) that are allowed to access the rows belonging to the dataset. This list may further include a start date (S_D) and an end date (E_D) of the authorization. Principles similar to those described with respect to table Access_auth109may therefore be of application to table Access_auth209, but taking into account that authorizations at row level are represented based on that the row belongs to a set of rows (dataset). In the particular example illustrated, user ‘U1’ is allowed to access the row ‘perl’ belonging to dataset ‘ds1’ if current date is between ‘d1’ and ‘d2’, user ‘U1’ is allowed to access the rows ‘car2’ and ‘car3’ belonging to dataset ‘ds2’ if current date is between ‘d3’ and ‘d4’, and user ‘U4’ is allowed to access the rows ‘car2’ and ‘car3’ belonging to dataset ‘ds2’ if current date is between ‘d5’ and ‘d6’.

There is no table inFIG. 1that may substantially correspond to table Function_set216. This “new” table216may be used for implementing a grouping of access procedures (or functions) into sets of functions. Table Function_set216may store records including a function set ID (FS_ID) and a list of Function IDs (F_ID) belonging to the function set. In the particular example illustrated, function ‘F10’ belongs to the function set ‘fs1’, and functions ‘F20’ and ‘F21’ belong to the function set ‘fs2’.

Table FS_creator213may be similar to table F_creator113ofFIG. 1. One difference may be that table FS_creator213may store data indicating which user has created (i.e. owns) which function set instead of which function as implemented in F_creator113. Table FS_creator213may store records including a function set ID (FS_ID) and a user ID (U_ID) corresponding to the creator (owner) of the function set. Foundations similar to those described with respect to table F_creator113may therefore be of application to table FS_creator213, but taking into account that ownerships are stored in FS_creator213on a per function set basis. In the particular example illustrated, user ‘U4’ is the creator/owner of the function set ‘fs1’ and user ‘U3’ is the creator/owner of the function set ‘fs2’.

A user may create as many function-sets as desired either by selecting individual functions owned by the user, or by selecting a subset of functions included in one or more function-sets previously created by the user.

Table Call_auth212may be similar to table Call_auth112ofFIG. 1. One difference may be that table Call_auth212may store data indicating which user is allowed to call which function set instead of which function as implemented in Call_auth112. Table Call_auth212may store records including a function set ID (FS_ID) and a list of user IDs (U_ID) that are allowed to call the functions belonging to the function set. This list may further include a start date (S_D) and an end date (E_D) of the authorization. Principles similar to those described with respect to table Call_auth112may therefore be of application to table Call_auth212, but taking into account that authorizations at function level are represented based on that the function belongs to a set of functions. In the particular example illustrated, user ‘U1’ is allowed to call the function ‘F10’ belonging to the function set ‘fs1’ if current date is between ‘d7’ and ‘d8’, user ‘U1’ is allowed to call the functions ‘F20’ and ‘F21’ belonging to the function set ‘fs2’ if current date is between ‘d9’ and ‘d10’, and user ‘U4’ is allowed to call the functions ‘F20’ and ‘F21’ belonging to function set ‘fs2’ if current date is between ‘d11’ and ‘d12’.

Any database system according to the present disclosure may represent authorizations at row/function level according to any of the approaches described in other parts of the disclosure. Access authorizations at row level and call authorizations at function level may be defined without belonging to a set of rows/functions (as depicted inFIG. 1).

Alternatively, access authorizations at row level and call authorizations at function level may be defined belonging to a set of rows/functions (as depicted inFIG. 2). Further alternatively, access authorizations at row level may be defined without belonging to a set of rows and call authorizations at function level may be defined belonging to a set of functions. Still further alternatively, access authorizations at row level may be defined belonging to a set of rows and call authorizations at function level may be defined without belonging to a set of functions.

It is worthy of mention that database systems according toFIG. 2may provide functionalities permitting different users to create different functions (or stored procedures) for accessing same data-element (or row).

FIG. 3is a schematic representation of an object-oriented database system300similar to relational database system100ofFIG. 1, according to still further examples. One difference may be that database system300may be based on classes/objects instead of relational tables/rows as in the case of database system100.

Database system300, as in the case of database system100, may be configured to perform computer-implemented methods for accessing first data-element301interrelated with second data-element303.

First data-element may be a first object301of a first class302(called Person in the figure) and second data-element may be a second object303of a second class304(called Car in the figure). The relationship between first objects301(of first class302) and second objects303(of second class304) may be a property/attribute/field in first objects301including a reference305to second objects303(e.g. car=“car2” in object301). In this case, the relationship305is implemented as a many-to-one relationship between objects301of Person302and objects303of Car304(many people may own same car).

In other examples, a many-to-many relationship may be defined between Person302and Car304through an intermediate class (and corresponding objects) including one or more references to objects301of Person302and to objects303of Car304(one person may own several cars, and one car may be owned by several people). Such an intermediate class may be e.g. a list class, table class, set class, etc.

In the particular example shown, each object301of the class Person302may store data of a person, such as e.g. an identifier of the person, a name of the person, a reference to object303of the class Car304, etc. Each object303of Car304may store data of a car, such as e.g. an identifier of the car, a color of the car, etc.

Only one object301is shown in class Person302corresponding to a person with identifier ‘perl’ who owns a car with identifier ‘car2’ whose data (e.g. Color=‘red’) is stored in object303of Car304.

First objects301(of class Person302) may be accessible exclusively by calling (i.e. encapsulated by) first methods306of class Person302. That is, first objects301may not be accessed through another way different from calling first methods306of class Person302.

Second objects303(of class Car304) may be accessible exclusively by calling (i.e. encapsulated by) second methods307of class Car304. That is, second objects303may not be accessed through another way different from calling second methods307of class Car304.

In object-oriented approach, attributes (or fields) are defined as private, while access to a field (or attribute) is defined to be performed through a method in corresponding class. Hence, the aforementioned access to objects exclusively through methods may be implemented by specifying the required methods as public, so that fields of the object can be accessed only by calling corresponding public methods.

Table User310may be similar (or substantially equal) to table User110as described with respect toFIG. 1. Similar fundamentals to those proposed in relation to table User110may hence be similarly applied to table User310.

Tables O_creator311and Access_auth309may be similar to tables R_creator111and Access_auth109as described with respect toFIG. 1. One difference may be that rows of O_creator311and Access_auth309may contain an Object ID (O_ID) instead of the Row ID (R_ID) of R_creator111and Access_auth109. Similar principles to those proposed in relation to R_creator111and Access_auth109may thus be similarly applied to O_creator311and Access_auth309.

Tables F_creator313and Call_auth312may be similar to tables F_creator113and Access_auth112as described with respect toFIG. 1. Similar considerations to those suggested in relation to F_creator113and Access_auth112may therefore be similarly attributed to F_creator313and Access_auth312.

Database system300is shown inFIG. 3configured to control access and call authorizations at object and function level without belonging to a set of objects/functions. However, said authorizations at object/function level may be controlled based on that the object/function belongs to a set of objects/functions under similar foundations to those described with respect toFIG. 2. Alternatively, said authorizations at object/function level may be controlled with object-sets and without function-sets or, further alternatively, without object-sets and with function-sets.

In some examples, any of the access and call authorization data along with user/role and credentials data may be stored in objects of corresponding classes instead of the tables described with reference toFIG. 3. The skilled person will appreciate that “authorization” tables/rows may be replaced by suitable classes/objects so as to provide “authorization” functionalities similar to those provided by said tables/rows.

Call314by user U1to the method F10and call308by method F10to the method F20may be similar to calls114and108ofFIG. 1, respectively. Principles similar to those commented in relation to calls114and108may thus be applied to calls314and308, taking into account that calls314and308are calls to class methods instead of calls to stored procedures.

It is worthy of mention that database systems according toFIG. 3may provide functionalities permitting different users to create different functions (or methods) for accessing same data-element (or object).

FIG. 4is a schematic representation of a graph database system400similar to the relational database system100ofFIG. 1, according to yet further examples. One difference may be that database system400may be based on nodes/edges instead of relational tables/rows as in the case of database system100.

Database system400(similarly to database system100) may be configured to perform computer-implemented methods for accessing first data-element interrelated with second data-element.

First data-element may be a node401(with label Person402in the figure) and second data-element may be an edge405(called HAS_CAR in the figure). In this case, the relationship between first data-element and second data-element may be defined by connection between node401and edge405, wherein edge405starts at node401.

First data-element may also be an edge405and second data-element may be a node403(with label Car404in the figure). In this case, the relationship between first data-element and second data-element may be defined by connection between edge405and node403, wherein edge405ends at node403.

In the particular example shown, node401with label Person402may store data of a person, such as e.g. an identifier of the person, name of the person, etc. Edge405may store data of an ownership by person401of car403, such as e.g. an identifier of the ownership, name of the ownership, etc. Node403with label Car404may store data of a car, such as e.g. an identifier of the car, color of the car, etc.

Node401is shown with label Person402corresponding to a person with identifier ‘perl’, name ‘John’ and owning something, said “owning” relationship being implemented by connection with edge405starting at the node401.

Node403is shown with label Car404corresponding to a car with identifier ‘car2’, color ‘red’ and owned by somebody, said “owned” relationship being implemented by connection with edge405ending at the node403.

Edge405is shown corresponding to an ownership with identifier ‘link1’, name HAS CAR and date of purchase ‘I-1-2001’.

Nodes401(with label Person402) may be accessible exclusively by calling (i.e. encapsulated by) corresponding procedures406. That is, nodes401may not be accessed through another way different from calling said procedures406.

Edges405may be accessible exclusively by calling (i.e. encapsulated by) corresponding procedures (not shown), so that edges405may not be accessed through another way different from calling said (not shown) procedures.

Nodes403(with label Car404) may be accessible exclusively by calling (i.e. encapsulated by) corresponding procedures407, such that nodes403may not be accessed through another way different from calling said procedures407.

The concept of procedure is well-known in the field of graph database systems. Exclusive access to nodes/edges through procedures may be implemented e.g. by disallowing querying (nodes and edges stored in) the database system, and allowing access only through procedures. Such functionalities may be provided in a similar way as described in other parts of the description with respect to relational and object-oriented database systems.

Table User410may be similar (or substantially equal) to table User110as described with respect toFIG. 1. Similar fundamentals to those proposed in relation to table User110may hence be similarly applied to table User410.

Tables NE_creator411and Access_auth409may be similar to tables R_creator111and Access_auth109as described with respect toFIG. 1. One difference may be that rows of NE_creator411and Access_auth409may contain a Node/Edge ID (NE_ID) instead of the Row ID (R_ID) of R_creator111and Access_auth109. Similar principles to those proposed in relation to R_creator111and Access_auth109may thus be similarly applied to NE_creator411and Access_auth409.

Tables F_creator413and Call_auth412may be similar to tables F_creator113and Access_auth112as described with respect toFIG. 1. Similar considerations to those suggested in relation to F_creator113and Access_auth112may therefore be similarly attributed to F_creator413and Access auth412.

Database system400is shown inFIG. 4configured to control access and call authorizations at node/edge and function level without node/edge-sets and without function-sets, respectively. However, said authorizations may be controlled based on node/edge-sets and function-sets under similar foundations to those described with respect toFIG. 2. Alternatively, said authorizations may be controlled with node/edge-sets and without function-sets or, further alternatively, without node/edge-sets and with function-sets.

In some examples, any of the access and call authorization data along with user/role and credentials data may be stored in corresponding nodes/edges instead of the tables described with reference toFIG. 4. The skilled person will appreciate that “authorization” tables/rows may be replaced by suitable nodes/edges so as to provide “authorization” functionalities similar to those provided by said tables/rows.

Call414by user U1to procedure F10and call408by procedure F10to procedure F20may be similar to calls114and108ofFIG. 1, respectively. Principles similar to those commented in relation to calls114and108may thus be applied to calls414and408, taking into account however that calls414and408are calls to procedures (encapsulating nodes/edges) instead of calls to stored procedures.

It is worthy of mention that database systems according toFIG. 4may provide functionalities permitting different users to create different functions (or procedures) for accessing same data-element (or node/edge).

The examples disclosed with reference toFIGS. 1-4have been described in the context of a particular type of database systems, i.e. those supporting typical relationships and integrity functionalities. In particular,FIGS. 1-4refer to database systems according to relational, object-oriented and graph approaches which belong to said particular type of database systems.

The skilled person will appreciate that any other database system of said type (such as e.g. key-value database like Cassandra) includes database components similar to e.g. tables, rows and stored-procedures of relational database systems, classes, objects and methods of object oriented database systems, nodes, edges and procedures of graph database systems, etc. so that fundamentals similar to those described with respect toFIGS. 1-4may be similarly applied to said other database approaches for implementing database systems according to the present disclosure.

Any of the database systems described in relation toFIGS. 1-4may comprise a controller115,217,315,415configured to perform any of the methods for accessing data stored in the database system such as the ones described in other parts of the disclosure. In particular, database system may comprise a memory storing a computer program comprising program instructions for causing the controller115,217,315,415to perform any of said methods for accessing data stored in the database system.

Any of the database systems described in relation toFIGS. 1-4and, in general, according to the present disclosure, may be implemented in a centralized manner or distributed among different computing and storage resources. A database system may comprise, for example, several computing systems suitably connected. One or more of said computing systems may provide e.g. controller functionalities, and other one or more of said computing systems may provide e.g. storage functionalities for storing the data in the database system.

FIG. 5is a flow chart corresponding to methods for accessing data stored in a database system similar to any of the database systems illustrated by previous figures, according to examples. References fromFIGS. 1-4may therefore be reused in following descriptions aboutFIG. 5.

Access methods according to present disclosure (e.g. according toFIG. 5) may be aimed at accessing first data-element interrelated (with a relationship) to second data-element.

First and second data-elements may be e.g. first and second rows101,103with relationship105between them in relational database system100, or first and second objects301,303with relationship305between them in object oriented database system300, or a node401and an edge405with relationship between them in graph database system400, etc.

Access methods may be started at initial block500when e.g. a request for attempting to access first data-element stored in the database system occurs. This request may include a call114,214,314,414, by first user U1, to first access procedure F10for accessing first data-element. Said request may have been performed by first user U1through suitable user interface comprised in the database system. Alternatively, said request may be a request to call the first access-procedure included in another access-procedure previously called by the controller115,217,315,415.

Said first access-procedure F10may comprise a call to second access-procedure F20for attempting to access the second data-element based on the relationship between first and second data-elements.

At block501, call by first user U1to first access-procedure F10may be received by database controller. First access procedure may be a stored procedure F10included in a plurality of stored procedures106encapsulating first row101, or a method F10included in a plurality of methods306encapsulating first object301, or a procedure F10included in a plurality of methods406encapsulating first node401, etc.

At block502, call to first access-procedure F10may be performed by database controller in representation of first user U1. As commented before, first access-procedure F10may comprise a call108,308,408to second access-procedure F20. For example, first access procedure F10may be aimed at returning name of a person owning a car and color of the car. Function F10may thus include a call to second access procedure F20for obtaining data of the car following the relationship between Person and Car.

Second access procedure may be a stored procedure F20included in a plurality of stored procedures107encapsulating second row103, or a method F20included in a plurality of methods307encapsulating second object303, or a procedure included in a plurality of methods encapsulating edge405, etc.

At block503, database controller may verify whether first user is authorized to access second data-element. This verification may be performed with or without sets of data-elements. Hence, a table similar to Access_auth109,309,409(wherein access authorizations are defined without considering sets of data-elements) may be consulted. Alternatively, tables similar to Data_set215and Access_auth209(wherein access authorizations are defined based on datasets) may be consulted. This verification may further comprise checking whether current date is between start date (S_D) and end date (E_D) of corresponding authorization.

At block504, call to second access-procedure F20may be performed by database controller in representation of first user U1.

At block505, database controller may return a result of the attempt to access the second data-element including an indicator of whether the first user is allowed to access the second data-element. Once said result has been returned, a transition to final block506may be performed so that execution of the method is ended.

A method according toFIG. 5may be triggered due to a request to call the first access-procedure included in another access-procedure previously called by the controller.

For instance, an initial procedure (for accessing initial data-element) may include a call to an intermediate procedure (for accessing intermediate data-element following a relationship between initial and intermediate data-element), and intermediate procedure may include a call to final procedure (for accessing final data-element following a relationship between intermediate and final data-element).

An initial verification of whether the user is allowed to access the initial data-element may be performed and, subsequently, first and second executions of the method according toFIG. 5may be performed.

In first execution, initial data-element and initial procedure may be the first data-element and first procedure, respectively, and intermediate data-element and intermediate procedure may be the second data-element and second procedure, respectively. In this case, first execution of the method may have been triggered due to a call request from user.

In second execution, intermediate data-element and intermediate procedure may be the first data-element and first procedure, respectively, and final data-element and final procedure may be the second data-element and second procedure, respectively. In this case, second execution of the method may have been triggered due to a call request included in a procedure previously called by the controller.

FIG. 6is a flow chart corresponding to methods for accessing data stored in a database system similar to any of the database systems illustrated byFIGS. 1-4, according to further examples. The methods represented by this figure are very similar to the methods represented byFIG. 5. One difference is that methods according to this figure may further include verifying whether first user is allowed to call second access procedure.

Block603may be similar to block503ofFIG. 5. One difference may be that block603may further include verifying whether first user is allowed to call second access procedure. This verification may be performed by consulting call authorizations based on sets of procedures or not. In the first case, tables similar to Function_set216and Call_auth212(wherein call authorizations at function level are defined based on function sets) may be consulted. In the second case, a table similar to Call_auth112,312,412(wherein call authorizations at function level are defined without considering function sets) may be consulted.

Block605may be similar to block505ofFIG. 5. One difference may be that block605may further take into account whether the first user is allowed to call second procedure (verified at block603) to produce the indicator of permitted access to second data-element. In this case, access to second data-element may thus not be permitted due to not allowed access to data-element itself or due to not allowed call to access-procedure through which data-element is accessible. The returned indicator may therefore include data representing whether unsuccessful access is due to one reason or the other (or both).

In some examples, “impersonation” functionality may be provided. This functionality may permit the first user to call the second access-procedure even though the user is not “directly” authorized to do that. In particular, database controller may successfully call second access-procedure (in representation of first user) if first user is authorized to call first access-procedure and the creator of first access-procedure is allowed to call the second access-procedure. Verifications needed for implementing said “impersonation” functionality may be performed by consulting authorization tables in a similar way as described in other parts of the disclosure.

A method according toFIG. 6may be triggered due to a request to call the first access-procedure included in another access-procedure previously called by the controller. Considerations included to this respect in relation toFIG. 5may be similarly applied in this case, but considering thatFIG. 6further includes verification of call authorizations.

Although only a number of examples have been disclosed herein, other alternatives, modifications, uses and/or equivalents thereof are possible. Furthermore, all possible combinations of the described examples are also covered. Thus, the scope of the present disclosure should not be limited by particular examples, but should be determined only by a fair reading of the claims that follow.