This diagram illustrates the essential and comprehensive modules necessary for effective business management, along with details regarding their data content.
The extended universal schema of information control system in any business
During the breakdown of functional blocks into smaller components, the resulting product is comprised of additional information blocks. Let's term this diagram "Data Management". Arrows interconnect the functional blocks and information blocks.
Business Module
The analysis of the Business Module (BM) commences by tracing the arrow from BM to Employees and Contractors. These information entities represent individuals directly involved in business operations. Another arrow points to Safety Management (SM), which is pivotal in modern businesses; without robust safety management and quality control, success is unlikely. The final arrow leads to the Production Management (PM) block, housing internal business aspects such as rules, operations, and principles. Additionally, there's a connection to Sales Management, which controls financial aspects of business in tandem with clients and customers.
Human Resources
This block encompasses two information entities: Employees and Contractors. These individuals can be likened to the figurative muscles of business, encompassing both intellectual and physical properties. The distinction lies in their terms of engagement; Employees are hired on a permanent basis, receiving regular pay and benefit packages, with the company handling taxes. Conversely, Contractors are engaged solely for task resolution, receiving rewards and managing their own taxes.
Addresses & Contacts
Observing Employees and Contractors reveals a commonality: Addresses and Contacts. Each person within these blocks possesses address and contact data. This represents the lowest information block, fulfilling queries from top-level management.
The composition of this information block, despite its simplicity, was often muddled by incompetent developers from monopolistic software companies in their early stages of success. They tended to create cumbersome, user-unfriendly software applications with limited functionality for managing addresses and contacts.
For a clearer picture, let's segregate Addresses and Contacts. The Addresses block includes the necessary and sufficient information to define a person's distinct allocation:
- Country
- Predominant administrative territorial entity (e.g., province or state)
- Place of residence (village, town, city) with detailed address: postal code, street name, house number, and room number
The Address area necessitates three reference tables: list of countries, list of administrative divisions, and list of places with attributes defining the place type.
Despite the complexity, defining distinct addresses is feasible, with countries divided into administrative divisions and places classified accordingly. Street names, house, and room numbers, although private, can be stored within a single field of the address table. Each country's nomenclature system for detailed levels varies, hence the practicality of labeling this information as "address".
We trust that this description enhances understanding of the diagram.
The universal schema for database storing any addresses
The PlaceType field serves to define the type of settlement, crucial as there may be different settlements with identical names within an area/state/province. The inclusion of the Continents table aids in organizing and filtering data conveniently. To achieve logical completeness in the structural design, it's imperative to introduce a detailed table where unique details about subjects are typically stored - Addresses.
As anticipated, the subject (referenced by the Id_Object field in the Object_Addresses table) can be either an Employee or a Contractor. Furthermore, this data storage principle is applicable for managing various data (Clients), suppliers (Vendors), competitors, and the like. In practical scenarios, interactions often occur with specific individuals representing clients, necessitating the storage of address data within the presented database.
While the schema can be endlessly refined or modified, the underlying principle remains unchanged: individuals may possess multiple residential addresses, including a primary home address, a country house address, an alternate residence, and so forth. Thus, the approach outlined here offers a universal means of gathering valuable information, the significance of which can be evaluated subsequently.
Similarly, the principle of segmenting information into semantic blocks extends to the realm of people's contact data. This approach, while somewhat simpler, remains powerful and invaluable for consolidating data for various analyses. A reference table, ContactType, is essential for storing types of operational communication such as "Phone", "Mobile", "Fax", "Email", "Skype", and so forth. The Contacts table facilitates direct storage of phone numbers, email addresses, Skype usernames, and other relevant contact information. Additionally, a third table, Object_Contact, akin to the one in the address scheme, is necessary to establish connections between individuals and their contact details.
The universal schema for database storing any contacts
Now, it suffices to create tables for managing the subjects themselves: employees, contractors, clients, etc., and establish pointers to unique record numbers in the Object_Address and Object_Contact tables. As evident, no difficulties arise - only maximum flexibility, which distinguishes this system from certain well-known but limited creations of less competent programmers (let's not name names - many readers will understand). This approach liberates the CRM database developer from constraints imposed by hard-coded columns for addresses and contacts, providing unlimited capacity for associating multiple addresses and contacts with one individual within the proposed database model.
You need to be registered for ability to comment articles.