A Robust Database with Powerful Features
At its core, GroverDB is a hybrid database — a merger of the best of object, relational, and graph database technologies. GroverDB has only a few types of meta-data, but when well-designed, these basic building blocks create a powerful and elegant solution.
- Object means that everything (every person, place, or thing) is stored as an object and that objects are organized into a hierarchy of object types.
- Relational means that all the data can be worked with using normal SQL commands (Select, Insert, Update, Delete) if that’s what you want to do (not required).
- Graph means that the relationships between objects are flexible and visual – like a mind map.
Object Class (Type) Hierarchy
When Object Classes (displayed as Types) are designed, most Object Classes will be defined “under” other Object Classes in a hierarchy. Whatever is true for a Class is true for its Sub-Classes – the Sub-Class inherits from the Super-Class.
Object Multi-Class allows an object to belong to multiple Classes, assign a State for each Class, and log the full history of the Object’s Classes and States for every Class.
If the Object belongs to multiple Classes, it can use all the features – all the States, State flows, Attributes, Forms, Connections, and Workflows – for every Class it belongs to.
In most Object-oriented technologies, Inheritance only applies to Attributes and methods. In GroverDB, Inheritance applies to every feature.
Inheritance also applies when the user browses Objects. By default, selecting a Super-Class includes selecting all the objects in all Sub-Classes. A Class can be set as an Abstract Class, which means it’s only there for Inheritance purposes and cannot itself be directly used by Objects. Setting a Class as Abstract is useful for a top level Class that has multiple Sub-classes and every Object should be in a Sub-Class.
GroverDB fully supports multiple Inheritance. Any Class can Inherit from multiple other Classes.
In the real world, every person, place and thing moves through a flow of States. Every Object will be in one of those States for every Class it belongs to and the Object’s State history is automatically logged in the database.
Each Class must be configured with at least one Status, and every Object of that Class will always be in one of the the Class’s defined Statuses.
GroverDB tracks not only the current State of every Object, but it also tracks the history of all the previous States. This is useful for seeing how an Object got to where is it today.
GroverDB hosts its web application and storage at a local SSAE16 Type 2 certified datacenter.
The network layer of security protects the servers on the network from hacking attacks.
- Firewall – We use dual-redundant pfSense firewalls with a default-deny policy on the firewall. Only the ports absolutely necessary to run the business are allowed through.
- Patches – pfSense patches are checked and applied weekly.
- VPN – all admin access to the servers is through an IPSec encrypted Virtual Private Network or VPN.
Penetration Testing scans the IP ports and attempts to identify security holes. PCI compliance requires a Pen Test annually or whenever there’s a significant change to the network architecture. The third-party service we use for Pen Testing performs a daily Pen Test.
Web Application to Browser Security
The Web Application connectivity level of security is how the data is protected as it is transported between the Web backend software and the client’s browser. .
- Outside Firewall – This firewall opens only the necessary ports for browser access and the VPN.
- Encryption in Flight – All data being passed between the web application server and the client browser is encrypted using a 256-bit SSL certificate to prevent hacking and man-in-the-middle attacks.
Web Application Server to SQL Server Security
This level of connectivity involves the data within our internal network, behind our outside firewall, as it’s passed between the web backend and SQL Server.
- Internal Firewall – A pfSense firewall exists between the web backend server and the internal network. No outside connection, even if they somehow get access to the DMZ network, can access the internal network.
- Encryption in Flight – All data between the Web Application Server and the SQL Server is encrypted using a 256-bit SSL certificate. Furthermore, SQL Server login credentials are automatically encrypted by Microsoft.
- SQL Server Credentials – The client database’s SQL Server IP Address, database, login account, and password are not stored with the application or passed to the client’s browser. Instead they are stored in a TejonDB master database, which is accessed by account number when the user logs in.