This diagram shows necessary and sufficient modules required for managing a business and details of data content.

The extended universal schema of information control system in any business

During the break down of functional blocks into smaller parts, the result becomes a product that is composed of additional information blocks. Let’s call a diagram – Data Management. There are arrows connecting the functional blocks and information blocks.

Business Module

Analysis of the Business Module (BM) starts by following the arrow from BM to Employees and Contractors. These information entities represent people dealing directly with the business operations. There is an arrow pointing to the Safety Management (SM). In modern businesses it is one of the most essential parts of management. Without well established safety management and quality control, businesses are likely not to succeed.

Another arrow is pointing to the Production Management (PM) block, a database holding all internal business related aspects; business rules, operations and principles.

The last arrow points to a Sales Management block, a database gathering information controlling financial aspects of business in connection with clients and customers.

Human Resources

Two information entities are located under this block: Employees and Contractors. As it was told above these can be seen as the figurative muscles of business, intellectual and physical properties. These information blocks hold data about people and their relations to business. What is the difference between them though? If people belong to an Employees section, they are being hired on permanent terms and get paid on a regular basis. They are also receiving benefit packages. Thus, the Company takes care of taxes for its employees. As for Contractors, their role is only to proceed with resolving business tasks, receiving rewards and taking care of different taxes themselves.

Addresses & Contacts

If you look close at Employees and Contractors, you may notice something that has a commonality between people from these different blocks: Addresses and Contacts. In each block the person has an address and a contact data. So far we reached the lowest information block, supplying requests for arrows (queries) coming from the top level of management.

What is the composition of this information block? Despite its simplicity, incompetent developers from monopolistic software development companies at the beginning of their success had founded a bad tradition to overcomplicate things by creating cumbersome, unusable, and user-unfriendly software applications with limited functionality for managing addresses and contacts of people and businesses.

Take any normal person who lives somewhere in the world. Any normal place in the world has its own unique geographical attributes. In a general case - it is a country which has an administrative division that includes a village, settlement, city, town, street, house, or a flat. In a modern industrial society, those territorial attributes are complimented with means of speed communication such as telephone, mobile phone, email, etc. For compiling these things into a logical and clear picture, we can now begin creating a correct information structure.

Let's first break them into two independent areas: Addresses and Contacts. What will be placed into the Addresses block? Shown below is the information that is neseccary and sufficient to define distinct allocation of the person.

Firstly - a Country. In addition to the country, there must be a predominant administrative territorial entity, called a region (a province or a state). Lastly, a name of the place of living which can be a village name, town name, city name, and eventually an actual address: a postal code, street name, house number, and a room number. It is absolutely neseccary for the Address area to have three reference tables: list of countries, list of areas, and list of places with a distinct attribute of the place type (village, town, city, etc.).

There are around 233 countries in the world. During the process of creating an address's system, it was found that each country is divided into major administrative divisions, the amount to which is estimated at about 4567 divisions +/- 100  due to permanent rearrangments or truncation of entities. As for places, the amount is already exceeding several millions. But is not a problem, they are still countable, and each place has its own area, each area has its own country. By defining only 3 entities it is easy to allocate any object in the world.

Itemizing of the distinct address requires street name, house and room number what is is a very private attribute. It is easy to store whole enumeration in one additional field of the address table. Each country has a different system for nomenclature of that detailed level, so for the purpose of universal storage it is more practical to call this information and the field the "address".

We hope that the description above will allow the diagram to be better understood.

The universal schema for database storing any addresses

Поле PlaceType здесь для определения типа населенного пункта, поскольку часто случается, что в районе/штате/провинции встречаются разные типы населенных пунктов с одним и тем же названием. Таблица Continents добавлена для удобства группировки и фильтрации данных. Для того чтобы довести создание схемы до логического завершения необходимо добавить детальную таблицу, в которой обычно хранятся данные о субъекте - Addresses. Как вы догадались, субъектом (мы сейчас говорим о поле Id_Object в таблице Object_Addresses) может выступать как Employee, так и Contractor. Более того, этот принцип хранения данных подходит и для управления данными о клиентах (Clients), поставщиках (Vendors), конкурентах и так далее. В реальности не существует абстрактного клиента, обычно имеют дело с одушевленным представителем клиента, то есть конкретным человеком. Адресные данные для таких случаев можно элементарно хранить в представленной базе.

Конечно, можно бесконечно усложнять и модифицировать эту схему, но суть останется прежней - у любого человека может быть несколько адресов проживания, есть домашний адрес, есть адрес дачи, загородного дома, адрес любовницы и так далее. Таким образом, представленный метод хранения информации обеспечит вас максимально полезной информацией, о ценности которой вы можете догадаться сами.

Аналогичный принцип разбиения информации на смысловые блоки применим и к области контактных данных людей. Она получится немного проще, но не менее мощной в плане ценности консолидации данных для различных анализов. Необходимо иметь справочную таблицу типов оперативной коммуникации - ContactType, в которой можно хранить: "Телефон", "Мобильный", "Факс", "Email", "Скайп",.. Нужна таблица Contacts для непосредственного хранения самих телефонных номеров и адресов почты, позывных скайпа и так далее. И третья таблица Object_Contact, аналогичная той, что в адресной схеме.

The universal schema for database storing any contacts

Теперь достаточно завести таблицы учета самих субъектов: работников, контракторов, клиентов и т.п. и передавать указатель на уникальный номер записи соответственно в таблицу Object_Address и Object_Contact. Как видите, никакой сложности не наблюдается. Зато наблюдается максимальная гибкость и преимущество этой системы перед некоторыми известными творениями бездарных ремесленников от программирования (не будем указывать пальцами - многие, дочитавшие до этого места - поймут). Данный подход не ограничивает разработчика программного обеспечения в сфере управления CRM тремя-четырьмя жестко запрограммированными колонками таблицы базы данных, отведенных на адреса и контакты субъектов! В предлагаемой модели информационной базы нет ограничений на количество адресов и контактов, ассоциированных с одним человеком.