Evolutive Data Core
In modern software development, data represents the vital core of financial and banking solutions architecture.
All business logic and presentation components of a software solution require access to a persistent data storage backbone in order to function, making data a crucial foundation for the establishment, extension, evolution, and even revolution of business software.
What is data modelling?
Data modelling is the process of creating a data model for the data to be stored in a specific format in a database.
Data models identify what data is needed and how it should be organized, enabling the creation of a database that will be used to develop an app. They also ensure the quality of data via naming conventions and default values.
Data models can serve a variety of purposes, from high-level conceptual and logical models to physical data models (PDMs). We’ll briefly describe the types of data models in the next section.
Types of data models
Developing a database requires creating three main data models:
- Conceptual Model – Identifies and organizes business concepts. Addressing the business requirements, it defines what data the system contains.
- Logical Model – Defines how the data rules and structures are mapped. Addressing the data requirements, this model is the base for developing the physical mode.
- Physical Model – Describes how the data is structured in the DB. Addressing the technical and performance requirements, it is the actual structure of the database that will be used to develop an app.
From bottom to the top, each model serves as foundation of the next data model, adding data details and other properties until it fully describes the actual database structure.
Data models’ creation implies using specific data modelling techniques. These are the two major data modelling techniques:
- Entity Relationship Diagram (ERD) – A high-level conceptual data model diagram which provides a visual representation of the data and how it is interconnected.
- UML (Unified Modeling Language) – A generic data modelling language that standardizes the data, enabling the design of a system. An UML may consist of more than one ERD.
Now that we’ve walked you through the types of data models and data modelling techniques, let’s create data models from bottom to top (conceptual to physical).
While creating data models from physical to conceptual is useful in reverse engineering to extract models from existing systems, creating data models from conceptual to physical models serves as a powerful template and reference for your DB, enabling stakeholders identify gaps and make proper changes before programming an app.
Entity Relationship (ER) modeling is a best practice for producing well-designed databases. It depicts the structure of a relational databases allowing you to understand the data and how it shares information.
The main concepts of an ER data model are:
Entities and Attributes
An entity is an object representing a thing from the real world. Entities are tables in a database (DB), each column representing an attribute which stores the value of an entity characteristic. Attributes have specific properties based on the data type.
Relationships define how entities share information in the database. An important aspect of relationships is the cardinality; it defines how data is related between the entities: none, one-to-many many-to-many. Cardinality defines how records of an entity are related to the records of another entity. For example, multiple customers can have the same account type.
This section describes how to create data models from conceptual to physical models using the ER model.
STEP 1. Create the Conceptual Data Model
Identify the entities, their attributes and the relationships between entities. The conceptual data model does not provide specific details of the relationships nor details of the actual database structure.
We have two entities Customer and Account Type which are related one to another.
- Name, PIN, Place of Birth and Email are attributes of the Customer entity.
- Is Person, Has Fiscal Number and Name are attributes of the Account Type entity.
- There is a relation between the two entities.
STEP 2. Create the Logical Data Model
This model adds additional information to entities and attributes identified in the conceptual data model.
An entity is described by at least two attributes: a primary key which uniquely identifies an entity and at least another attribute which provides an entity characteristic. For example, the primary key of the Customer entity is the AccountId attribute. It uniquely identifies the records of the Customer entity.
To create the logical data model starting from a conceptual data model, for each entity define which attribute is the primary key and for all other attributes, define their type (text, numeric, date, whole number, etc.) and properties (length, required level, etc.).
Although the DB structure is still generic, the logical data model provides the baseline for the physical data model.
STEP 3. Create the Physical Data Model
Once you’ve defined the conceptual and logical data models, you can create the actual database structure by defining the relations between entities.
An important aspect of entity relationships is cardinality. Cardinality is the property of the relationship itself, specifying how records of an entity are related to the records of another entity: one-to-many or many-to-many.
To establishes a link between records of two different entities (entity relationship), you have to add an attribute of type lookup, also known as foreign key.\
When talking about relationships, we distinguish two entities: parent and child. The entity to which you add the foreign key becomes parent entity for the related entity also known as child entity.
Below is an example of a basic physical data model created in FintechOS Studio, comprised of two entities, their attributes and relationship:
You can extend the physical model with new attributes or with data from external systems, creating an Evolutive Data Core.
Evolutive Data Core
Evolutive Data Core not only ensures the modeling of the database structure, but it also extracts data from legacy systems, processes and data repositories, extending data by combining and connecting data.