In Galeva, data is de-structured upon insertion, making it de-identified under section 1798.140 of CCPA (California Consumer Privacy Act). It is re-structured only during an authenticated query. Not only does this protect against accidental data exposure and backdoor data breaches, it immensely lowers the risk profile of thecontrollers and processorsthat handle large quantities of sensitive data. See factored data.
Data privacy is a scarce resource. Businesses must go beyond compliance with the latest regulations in order to maintain lasting, meaningful relationships with consumers. With factored data, data at rest is unstructured and unreadable. Galeva provides fine-grained access controls over who sees what. Restrict data operations to specific roles. Restrict entities to roles. Finally, add users to those roles. Galeva's unique authentication that brings structured data into existence makes data authorization that much more powerful.
Galeva automatically optimizes your queries and automates indexing. How can Galeva possibly do this without knowing app usage patterns? It's all in the structure. Galeva's unique relational structure is consistent and has algorithmically predictable data growth. She easily and consistently handles any query and indexes efficiently. See API docs.
verb | to remove the relationships
between cells in the row of table in a relational database,
analogous to the process of factoring a polynomial into simpler
expressions
noun | relational data whose
structure has been removed in order to secure it
Galeva has an easy to use web app that makes data configuration a breeze. Configure entities and relationships, upload data, manage users and roles, and so much more. Backend maintenance is easy.
Users can be assigned roles. Access to entities can be restricted for specific roles. Access controls such as these in the data level help application developers develop robust and secure applications.
Galeva provisions all CRUD (create, retrieve, update, delete) operations and transactions in the database through intuitive REST APIs. Application development is fluid, organized, and highly productive.
Changing business requirements and application requirements usually mean re-building. Not here. An ontological architecture easily accommodates structural changes and Galeva's APIs simply work without any recompilation or re-indexing.
{ "attributes": { "CUSTOMER": [ "FIRSTNAME", "LASTNAME" ], "ADDRESS":["*"] }, "filters": { "CUSTOMER": { "FIRSTNAME": { "condition":"=", "value":"Mike" }, "LASTNAME": { "condition":"=", "value":"Johnson" } }, "ADDRESS":{} }, "join":["CUSTOMER","left","ADDRESS"], "rowcount":500 }
POST slice
POST slice
handles complex queries involving
multiple entities, joins, and filters. Slice through your data
exactly the way you want.
This request retrieves 100 or less customers named Mike Johnson and their addresses.
bactchsize: 1000 dataid: 20200211110451 startsfrom: 3000
GET set
POST set
handles large queries for batch
processing. After execution, GET set
processes
the results in multiple batches. Perfect for analytics.
This request retrieves 1000 rows after the 3000th row.
{ "1": { "operation":"insert", "entity": "EXPENSE", "row": { "name":"lunch", "amount":"210" }, }, "2": { "operation":"update", "entity": "ACCOUNT", "rowid": "21" "row": { "balance": { "oldValue":"4000", "newValue":"3790" } }, } }
POST transaction
POST transaction
initiates a transaction
involving multiple operations that must all either succeed
together or fail together.
This request performs an insert and an update which will be committed in the database together