WO2016099318A2 - Система и способ управления функционально связанными данными - Google Patents

Система и способ управления функционально связанными данными Download PDF

Info

Publication number
WO2016099318A2
WO2016099318A2 PCT/RU2014/000959 RU2014000959W WO2016099318A2 WO 2016099318 A2 WO2016099318 A2 WO 2016099318A2 RU 2014000959 W RU2014000959 W RU 2014000959W WO 2016099318 A2 WO2016099318 A2 WO 2016099318A2
Authority
WO
WIPO (PCT)
Prior art keywords
attribute
value
socket
connector
attributes
Prior art date
Application number
PCT/RU2014/000959
Other languages
English (en)
French (fr)
Inventor
Сергей Анатольевич ГОРИШНИЙ
Анатолий Александрович КОНДРИК
Original Assignee
Сергей Анатольевич ГОРИШНИЙ
Анатолий Александрович КОНДРИК
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Сергей Анатольевич ГОРИШНИЙ, Анатолий Александрович КОНДРИК filed Critical Сергей Анатольевич ГОРИШНИЙ
Priority to US15/536,733 priority Critical patent/US11567911B2/en
Priority to RU2017125210A priority patent/RU2693682C2/ru
Priority to CN201480084014.4A priority patent/CN107111490A/zh
Priority to PCT/RU2014/000959 priority patent/WO2016099318A2/ru
Publication of WO2016099318A2 publication Critical patent/WO2016099318A2/ru

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048Interaction techniques based on graphical user interfaces [GUI]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • G06F16/211Schema design and management
    • G06F16/212Schema design and management with details for data modelling support
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/31Indexing; Data structures therefor; Storage structures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/284Relational databases
    • G06F16/288Entity relationship models

Definitions

  • the invention relates to a system and methods for identifying, storing, retrieving and converting information. More specifically, the invention relates to database and data management systems in general, as well as to the structure, internal organization and methods of data interaction in particular.
  • the data management system in general, and the database in particular, is a computer system that allows users to uniquely
  • each entity of the subject area is represented by a table - conditionally, for a more visual understanding.
  • Each column of such a table contains the values of one of the attributes of the entity.
  • Each line contains all the characteristics (features) of one of the entity instances.
  • Relations between entities are represented by table attributes. For data-filled communication tables, they show which instances of one table are associated with instances of another table. The relationship is made according to the matching values of one or more columns of the related tables.
  • the relational meta-model of data does not contain any rules and pointers that link one value to another, and, accordingly, the content of the database is possible only in one way, namely, by explicitly setting attribute values in relationship tuples.
  • the objective of the present invention is to remedy these disadvantages, as well as to obtain a number of additional advantages.
  • the subject of the invention is the creation of progressive methods for the internal organization and interaction of control structures of a data management system that completely, or at least partially, eliminate the disadvantages inherent in a relational data model, and also provide a number of additional advantages.
  • the present invention makes it possible to create application programs in which the entire algorithmic part is integrated directly into the database structure, and thereby overcomes the limitations of the prior art.
  • the present invention supplements the generally accepted Data Model with a new fundamental member, and describes a data management system in which the declaration of the causal relationship of information values is implemented directly at the meta-description of the data using
  • a declarative method is disclosed. data management, using abstract connectors implemented by instances of a unified data structure to describe the causal relationship of information values, and implementing this dependence in
  • a multiprocessor device in which the distribution of declarations of subjects of metadata and
  • the present invention discloses a simple and productive method for the unified identification of all subjects of metadata, providing a compact representation of the address of the subject and high speed access to the subject.
  • any subject area of automation can be considered as a finite set of specific information values that consistently change their state over time under the influence of environmental events.
  • each such information value is an instance that is derived from the particular characteristic of some conceptual entity.
  • a single value cannot exist independently, and is encapsulated in a tuple of values (a uniquely identifiable Data Object — in the object representation, or a relation in the form of a Table record — in the relational), which is an instance derived from the description of some conceptual entity of the level of abstraction.
  • any subject area is uniquely described by a set of formalized declarations of entities called the Class (in the object representation), or the Table (in the relational), as well as their own characteristics (hereinafter, Attributes) )
  • the set of Classes and Attributes forms a meta-description of the subject area, otherwise called the Application Model.
  • each Class is characterized at least by the name of the corresponding conceptual entity and the tuple of Attributes.
  • a tuple of class attributes uniquely determines the internal structure of storing information values that is the same for all instances of a given class, which makes the order of the attributes in the tuple unchanged.
  • Each class attribute is characterized at least by the name of the characteristics of the entity, as well as
  • three levels can be distinguished in the data management system: 1) the level of the meta-model of the system itself; 2) the level of the Application Model; and 3) the level of the final information values. It is important to note that all of the above subjects of the first two levels represent a declarative description that exists in a machine-readable form suitable for long-term storage.
  • the data management system uses declarative entities to create derived instances of the next level on their basis, and does so in a unified manner. It is worth noting that the subjects of the Application Model level are generally referred to as metadata subjects.
  • an abstract Connector binds class attributes in pairs
  • the connector is used exclusively in its abstract form, which provides the convenience of visual perception of the connection of attributes.
  • the concept of a Socket is used (it is also a connector or connector).
  • a pair of end connectors are an integral part of any connector, and with their help, the connector interacts with the entities being connected. It is worth noting that in the Object Model of the application, when implementing the quantitative interaction of conceptual entities, the similar role of such connectors is performed by Attributes of the relationship, which contain in their characteristics a complete description of the properties of the relationship.
  • each of the two Connector Sockets contains a complete description of the characteristics of the declared connection for its part, and this information is enough to organize a full-fledged two-way interaction of Attributes.
  • Meta-model of a data management system by the third fundamental member — a formalized abstract meta-Socket.
  • a Meta-Socket is associated with a meta-Attribute by a child-parent relationship, just like a meta-Attribute is associated with a meta-Class.
  • the meta-Socket includes a declarative description of the characteristics of the Socket instances, which will be discussed in detail below.
  • a single Socket is characterized by at least three aspects: address, functional, and event, each of which includes a corresponding set of declarative characteristics.
  • Attribute can determine not only unitary, but also enumerable form of storage of information values derived from it.
  • the enumerable form assumes that the Attribute includes, in addition to its own name, a tuple of user-defined names of enumeration elements, and its derived value is represented by an array of values.
  • the full addressing aspect of the Socket must include the identifiers of the Class and the Class Attribute to which the opposing Socket belongs, as well as the identifier of the opposite Socket in the Attribute tuple, and
  • the parent-child relationship is expressed by the presence of the Attributes tuple in the Class, and the presence of the Sockets tuple in the Attribute.
  • Application Model Classes also form a tuple owned by a utility abstract entity called a super-Class. And it is also worth paying attention to that the mentioned Super-Class tuple can be formed directly by the Classes - instances of the meta-Class, and
  • each tuple mentioned contains a linear set of homogeneous (within the tuple) instances, and in the most general case is a dynamically expandable array. In such an array, a new cell is automatically created to accommodate each new instance, which allows each tuple instance to be uniquely and uniquely identified by the index of the tuple element. This significant feature allows us to express the full addressing aspect of the Socket with a simple formatted record, which includes four indices of the previously mentioned entities.
  • the indicated method of unified index identification of all heterogeneous instances of the Application Model derived from meta-Classes, meta-Attributes and meta-Sockets of a data management system is an important aspect of the present invention. This method allows not only to simplify and unify
  • the index identification method ensures complete independence of the Application Model from the user-defined names of Classes and Attributes, which, as a rule, are directly borrowed from the conceptual entities of the subject area, and their characteristics.
  • the mentioned index may not be initialized in two cases: 1) the target Attribute does not use an enumerated form of storage; 2) The socket addresses all elements of an enumerated form at once. In the latter case, the abstract Connector is used simultaneously and in the same way as applied to all elements of the target Attribute, thereby realizing the group dependence. If abstract
  • the Connector connects two attributes with an enumerated form of storage, and the mentioned index of the address aspect of both Sockets is not initialized, the implementation of group dependence is carried out exclusively in pairs, that is, only Attribute elements with the same index interact with each other through a common Connector.
  • the functional aspect of the Socket allows you to control the modification of the value, and includes, among other things, the identifier of the calculation method and the inversion flag.
  • each functional type of value is associated with a predefined set of computational methods (functionals) that are potentially applicable to the values of this type.
  • each method can be uniquely identified, including a numerical identifier-index.
  • Total Quantity x Price
  • this method is a multiplicative arithmetic operation.
  • Attributes can be connected by an abstract connector only if their functional types coincide, or if there is at least one predefined method in the data management system that allows you to convert a value from the functional type of one Attribute to a functional type of another.
  • the flag of the inverse of the value (Inverse) is used in elementary arithmetic and logical operations both to change the sign of the value-argument, and to change the nature of the operation, and thereby reduces the range of predefined methods of the data management system. So if the inversion flag is set to the Socket located in the tuple of the attribute-argument, then it changes the sign of the value-argument to the opposite, while the connector does not changes the passed value-argument, and only passes along with it the value of the inversion flag. If the inverse flag is set to the Socket located in the tuple of the target attribute, then this flag changes the nature of the operation. For example, in this way, multiplicative multiplication can be converted to the operation of dividing by the value-argument.
  • the event aspect of the Socket allows you to control the transmission of the value, and is characterized by the Set and Get flags, allowing the Attribute to use the Socket in the operations of extracting and sending the value.
  • the mechanism for using an abstract connector formed by a pair of Sockets is based on two basic methods provided by the Meta-Socket. At the level of current Attributes, this mechanism is implemented as follows:
  • the Get method is provided by the Socket to request a value from the opposite Socket. Regardless of the source of the event that forces the formation of a derived value, the Attribute sequentially scans its Socket tuple, and for each Socket with the Get flag set, calls the method of the same name. The Get method returns the Attribute from the connector the value to which the Attribute uses the computational method assigned to the Attribute to obtain the resulting value, taking into account the functional aspect of the Socket.
  • an attribute operates on a value that exists in an explicitly stored form.
  • Attribute methods are used only to extract the stored value, or to save the value generated somewhere outside, leading it to a form convenient for storage.
  • Dynamic (with the Dynamic flag set) An attribute, being a full-fledged Attribute in a Class tuple, in principle does not form a derived value in a stored form, and, accordingly, when accessing it for a value, it does not try to extract the value from the storage system. Instead, each time it is accessed, the dynamic Attribute generates the returned derived value by polling its Get-Sockets.
  • Total Quantity x Price
  • the Get flag determines the direction in which the value is transmitted directly. If the Get flag is set to the Socket, then the Attribute can (upon request) get the value from this connector. The Get flag is set directly when a connector is created in the corresponding direction of transferring the value of the Socket of the target Attribute.
  • the Set flag determines both the activity of the connector and the direction of transmission. If the Set flag is set on the Socket, the connector actively passes any change in the value of the Attribute to which the Set-Socket belongs to the opposite Attribute. If the Set flag is not set in any of the Sockets, then the connector does not have its own activity, and will transmit the value only upon request. Note that, by definition, a Socket tuple of a dynamic Attribute cannot have any Sockets with the Set flag set.
  • the target Attribute defines the reversible Socket (as having Get and Set flags set at the same time), using the declarations of the functional and other Get sockets, "calculates" the value of the argument that satisfies their rules, and passes this value is in a reversible socket.
  • Attribute implements the following execution cycle: 1) receiving an incoming message, including a pointer to the target data object, to the address of one of its Get sockets, Attribute 2) forms a new derived value, and it is possible
  • the Attribute performing the functions of a “factory” to create derived values, or providing a value upon request, is logically isolated, and does not have any information about its environment, the interaction with which it is carried out by receiving / sending information messages through Sockets.
  • the functions of the transmission link in the process of messaging are assigned to the computing environment of the data management system, which, regardless of the length of the chains of dependencies of the Attributes, implements all execution cycles sequentially, until they are completed successfully.
  • the total response time of a system to a single user event is determined by the length of the longest sequential chain of dependencies of all existing, excluding branches from it.
  • multiprocessing computing can simultaneously start parallel processing of an arbitrary number of external events addressed to various attributes, which significantly reduces the overall response time of the data management system.
  • An application model formed by a set of Attributes connected by abstract connectors, in which the functionality of each Attribute is isolated, and declarations are localized in a separate memory of the corresponding process,
  • an abstract Connector of two attributes can be made causally dependent on some third Attribute, the derived value of which dynamically changes the functional behavior of the dependent connector.
  • Such a dependency in the Application Model is also declared and implemented by an abstract Connector, which binds one of the dependent Sockets
  • This control Connector is essentially an addition to the main dependent Connector, which in this case is considered as the base. Accordingly, for convenience of presentation, the dependent Connector, its Sockets and associated Attributes will be called “base”, and the managing Connector, its Sockets and its controlling Attribute will be additionally highlighted by the prefix "-condition”.
  • the interaction of the base Socket and the Condition Socket, uniformly localized in the general tuple of the base Attribute, can be implemented in various ways, including through a system of mutual pointers to each other. But more preferred is the option in which the entire connector of the control connector
  • the base socket permanently allows only three positionally fixed
  • each encapsulation corresponding to one specific aspect of the functionality of the base connector, namely:
  • Encapsulation is considered relevant if it contains the address part of the opposite socket of the control connector.
  • the base Socket checks all three encapsulations, and for each of the actual ones it performs an action corresponding to its functional aspect.
  • the mechanism for using the Unset and Reset methods is quite simple: in the process of changing its derived value, before actually changing it, the static Attribute sequentially looks through its Socket tuple, and for each Socket with the Unset flag set, calls the method of the same name. After fixing a new value, the Attribute again sequentially scans its tuple of Sockets, and for each Socket that has the Reset flag set, it again calls the method of the same name. Thereby addressing the base
  • the connector is initiated first (Unset) to perform an action that is inverse to its direct effect on the dependent value (similar to de-initialization
  • the underlying Attribute which has encapsulation, retrieves the control value using the Get method and the address component of this encapsulation.
  • a control connector with a blocking aspect is created if a logical type attribute is selected as the control attribute of the condition. If there is an actual blocking encapsulation in the declarations of the base socket, in all the methods of this socket, before executing them, a request is made for the status of the control attribute (specific derived value). If the Get call to the address of the Condition attribute returns True, then the execution of the current method of the base socket will continue, otherwise (False) will be terminated.
  • identifiers of the target subjects of metadata include the identifier of the target object.
  • the identifier of a third-party data object may be present in the original object only as a value derived from a relation attribute. This means that the interconnection of Attributes of different classes is possible if only these attributes are localized in classes between which there is a quantitative interaction relation (Class relation), and should take into account the nature of this relationship.
  • Class relation quantitative interaction relation
  • An abstract connector must use relationship attributes as the Control Attributes of that connector.
  • a control connector is automatically created for one or both base socket of the connector with the corresponding relationship attribute as the control attribute, with the inclusion of this connector in the address aspect of the base socket.
  • the interaction of values through the asymmetric relationship of the many-to-one classes implies, among other things, that the set of values on the many-side forms a single value on the -one side.
  • attribute functional For example, in the class Account (Invoice) the total Account Amount (Total) is a generalization of the set of private amounts (Total) of individual Records of this account (Invoice record), which is implemented by the connector linking the Total attributes in the Invoice and Invoice Record classes, and the corresponding functionality of the Total attribute in the Invoice class, which performs the summation of the incoming set of values.
  • Rate List in the Currency class, which contains a list of records formed by pairs of rate values for a specific date (Date), derived from attributes localized in the Date class.
  • Date a specific date
  • each Rate value from the set on the side of the "many-" relationship (Date) needs to match the Date value.
  • Such a mapping is performed by the managing connector using the contextual aspect of management.
  • context value can be used not only to generate a key-value list, but also to extract a value from such a list that is implemented by a similar connector with a control context.
  • the Class contains the Self service attribute in its tuple, the existence of which is declared directly in the meta-Class.
  • the Self attribute is typed by the identifier of its Class, and accordingly, the derived value of this attribute in the data object will be the identifier of this object.
  • the value type of the Self attribute matches the value type of the Attribute of the relation in the opposite class, which allows you to associate these attributes with an abstract Connector (referential), using the Relationship Attribute on the side of the Self attribute as the attribute that controls the address aspect.
  • an abstract Connector reference to the side of the Self attribute.
  • Attribute for contextual control, the Attribute is selected by default, which is the main characteristic of the Class:
  • the attribute of the relationship on the many-side is hereinafter referred to as the attribute of the direct link
  • the attribute of the relationship on the side of the single link is referred to as the attribute of the backlink.
  • both relationship attributes are peer-to-peer, and are in fact attributes of a direct link.
  • an entity characteristic is provided, the value of which indicates whether the data object is relevant or is marked as deleted. Accordingly, any Class, among others, contains in its tuple the service attribute Delete, the existence of which is declared directly in the meta-Class. If the derived value of the Delete attribute is initialized in the data object, then the data object is considered deleted (irrelevant). According to referential integrity rules, a remote object must de-initialize all its connections with other objects in such a way that the data management system does not contain direct or backward links to this object.
  • the previously described Link Connector on the side of the Self attribute (direct link), is supplemented by a control connector with the Delete attribute with a blocking aspect (thus, all three control aspects of the base socket of the link connector localized in the tuple of the Self attribute are relevant).
  • This control connector has the permanently set Inverse flag, and when
  • initializing the value of the Delete attribute blocks the transfer function of the base connector, which in turn causes de-initialization of the connection of objects, with canceling the corresponding value in the backward link of the data object of the opposite class (the value of the direct link in the original object
  • the Delete attribute has passive abstract connectors with each backlink attribute in its class. The presence of such a connector allows the attribute functional to inspect the state of the values of backlinks, and, if there is at least one actual value, permanently block the procedure for deleting the data object.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Description

СИСТЕМА И СПОСОБ УПРАВЛЕНИЯ ФУНКЦИОНАЛЬНО СВЯЗАННЫМИ
ДАННЫМИ
ОБЛАСТЬ ТЕХНИКИ
Изобретение относится к системе и способам идентификации, хранения, извлечения и преобразования информации. Более конкретно, изобретение относится к системам управления базами данных и данными вообще, а также к структуре, внутренней организации и способам взаимодействия данных в частности.
ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
Система управления данными вообще, и базами данных в частности, представляет собой компьютерную систему, которая позволяет пользователям однозначно
идентифицировать, преобразовывать и хранить информацию в структурированном, связанном и логически целостном виде.
В основе современных методов управления данными лежит аппарат теории множеств, и в частности реляционная модель данных, предложенная Э.Ф.Коддом. Кодд показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известных в реляционной математике как отношение. В соответствии с реляционным методом каждая сущность предметной области представляется таблицей - условно, для более наглядного понимания. Каждый столбец такой таблицы содержит значения одного из атрибутов сущности. Каждая строка содержит все характеристики (признаки) одного из экземпляров сущности. Связи между сущностями представлены атрибутами таблиц. Для заполненных данными таблиц связи показывают, какие экземпляры одной таблицы связаны с экземплярами другой таблицы. Связь выполняется по совпадающим значениям одного или нескольких столбцов связанных таблиц. При этом реляционная мета-модель данных не содержит никаких правил и указателей, связывающих одно значение с другим, и, соответственно, информационное наполнение базы данных возможно только одним способом, а именно— явным заданием значений атрибутов в кортежах отношений.
Это последнее обстоятельство приводит к тому, что в современных системах управления данными, так или иначе основанных на реляционной (или производной от нее объектно- реляционной) модели, реализация внутренних правил предметной области,
функционально или событийно связывающих между собой значения, производные от атрибутов сущностей, осуществляется за пределами собственно системы управления данными, с использованием самых различных технологических приемов,
вычислительных сред и языков программирования. Тем самым реализация всей совокупности бизнес-правил прикладной программы становится самостоятельной задачей, требующей постоянного контроля за сохранением логической целостности и согласованности данных, что в свою очередь порождает самые различные ошибки, и в том числе тривиальные ошибки программирования. Взаимная изоляция данных от правил их формирования, и возникающая вследствие этого необходимость
использования традиционных форм программирования, в свою очередь приводящая к написанию и отладке большого объема программных кодов, существенно усложняет разработку приложений.
Задачей настоящего изобретения является устранение указанных недостатков, а также получения целого ряда дополнительных преимуществ.
РАСКРЫТИЕ ИЗОБРЕТЕНИЯ
Предметом изобретения является создание прогрессивных способов внутренней организации и взаимодействия управляющих структур системы управления данными, которые полностью, или по крайней мере частично, устраняют недостатки, присущие реляционной модели данных, а также обеспечивают ряд дополнительных преимуществ. Настоящее изобретение делает возможным создание прикладных программ, в которых вся алгоритмическая часть интегрирована непосредственно в структуру базы данных, и тем самым преодолевает ограничения предшествующего уровня техники.
В первом своем аспекте настоящее изобретение дополняет общепринятую Модель данных новым фундаментальным членом, и описывает систему управления данными, в которой декларация причинно-следственной зависимости информационных значений реализуется непосредственно на уровне мета-описания данных при помощи
унифицированных абстрактных соединителей.
Во втором аспекте настоящего изобретения раскрывается декларативный способ управления данными, использующий реализованные экземплярами унифицированной структуры данных абстрактные соединители для описания причинно-следственной зависимости информационных значений, и реализующий эту зависимость в
соответствии с декларациями таким образом, что полная совокупность значений сохраняет свою непрерывную согласованность и логическую целостность.
В третьем аспекте настоящего изобретения описывается мультипроцессорное устройство, в котором распределением деклараций субъектов метаданных и
производных от них значений системы управления данными в локальной памяти множества независимых процессоров, достигается высокий уровень параллелизма исполнения при реализации причинно-следственной зависимости информационных значений.
Помимо этого настоящее изобретение раскрывает простой и производительный способ унифицированной идентификации всех субъектов метаданных, обеспечивающий компактность представления адреса субъекта и высокую скорость доступа к субъекту.
Важной особенностью всех аспектов настоящего изобретения является полностью декларативный характер их внутренней реализации, который позволяет создавать прикладные программы не прибегая к написанию программных кодов в любой их форме, и тем самым делает эти программы полностью кросс-платформенными. При этом стоит упомянуть, что настоящее изобретение имеет практическую программную реализацию и использование в платформе быстрой разработки приложений Visual Data. Эти и другие особенности и преимущества настоящего изобретения будут очевидны из следующего описания и формулы изобретения.
ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ
Из предшествующего уровня техники известно, что на физическом уровне
представления любую предметную область автоматизации можно рассматривать как конечное множество конкретных информационных значений, согласованно изменяющих во времени свое состояние под воздействием событий окружающей среды. В системе управления данными каждое такое информационное значение является экземпляром, производным от частной характеристики некоторой понятийной сущности. При этом отдельное значение не может существовать самостоятельно, и инкапсулировано в кортеж значений (уникально идентифицируемый Объект данных— в объектном представлении, или отношение в форме записи Таблицы - в реляционном), который является экземпляром, производным от описания некоторой понятийной сущности уровня абстракции.
Ранее Э.Ф.Кодд доказал, что на уровне абстрактного восприятия любая предметная область однозначно описывается совокупностью формализованных деклараций сущностей, именуемых Классом (в объектном представлении), или Таблицей (в реляционном), а также входящих в их состав собственных характеристик (далее, Атрибутов). Совокупность Классов и Атрибутов образует мета-описание предметной области, иначе называемое Модель приложения.
В Модели приложения каждый Класс характеризуется по меньшей мере именем соответствующей понятийной сущности и кортежем Атрибутов. Кортеж атрибутов класса однозначно определяет внутреннюю структуру хранения информационных значений, одинаковую для всех экземпляров данного класса, что обуславливает неизменность порядка следования атрибутов в кортеже. Каждый Атрибут класса характеризуется по меньшей мере именем характеристики сущности, а также
функциональным типом и формой хранения производного от него значения. Отдельные понятийные сущности предметной области связаны между собой количественным отношением, и эта связь характеризует меру количественного взаимодействия производных экземпляров этих сущностей. В каждом из связанных между собой таким образом Классов, эта связь представлена Атрибутом отношения.
В свою очередь, декларации Классов и Атрибутов, описывающие отдельные
понятийные сущности и их частные характеристики, являются экземплярами, производными от формализованных абстрактных сущностей мета-Класс и мета- Атрибут — понятий более высокого уровня абстракции, образующих Мета-модель системы управления данными, и являющимися ее фундаментальными членами.
Таким образом, в системе управления данными можно выделить три уровня: 1) уровень Мета-модели самой системы; 2) уровень Модели приложения; и 3) уровень конечных информационных значений. При этом важно отметить, что все перечисленные субъекты первых двух уровней, представляют собой некоторое декларативное описание, существующее в машиночитаемом виде, пригодном для долговременного хранения. Система управления данными использует декларативные субъекты для создания на их основе производных экземпляров последующего уровня, и делает это унифицированным образом. Стоит обратить внимание, что субъекты уровня Модели приложения принято обобщенно именовать субъектами метаданных.
Для целей настоящего изобретения важно обратить внимание на существование причинно-следственной зависимости, связывающей между собой отдельные
информационные значения предметной области. Для примера рассмотрим строку Счета (Invoice), в которой значение Сумма (Total) является произведением значений- аргументов: Количество (Quantity) и Цена (Price). Изменение значения любого из аргументов приводит к немедленному изменению значения Сумма (Total), при этом все три значения являются перманентно согласованными. То есть, на физическом уровне зависимость действует таким образом, что все изменения связанных значений происходят синхронно и согласовано, без возможности выделить некоторое
промежуточное состояние.
Для решения задачи согласованной связанности значений, настоящее изобретение вводит абстрактное понятие универсального Соединителя. На уровне Модели приложения абстрактный Соединитель попарно связывает Атрибуты класса,
обеспечивая тем самым возможность обмена значениями между ними. Образованная таким образом декларация зависимости рассматривается вычислительной средой системы управления данными как единичное правило предметной области, согласно которому зависимый Атрибут формирует свой экземпляр значения. Такие единичные правила можно условно-бесконечно комбинировать, при соблюдении единственного ограничения, которое запрещает образование циклически замкнутых
последовательностей. При этом система управления данными, независимо от
совокупной протяженности и разветвленности сложившейся системы зависимостей, способна обеспечить синхронность и согласованность результатов за счет инкапсуляции всех промежуточных состояний.
Прямое использование Соединителя в форме декларации некоторой сущности Модели приложений не совсем удобно с точки зрения практической реализации его
взаимодействия со связываемыми атрибутами. Поэтому, в Модели приложения
Соединитель используется исключительно в абстрактной его форме, обеспечивающей удобство наглядного восприятия связи атрибутов. Для декларативного же представления Соединителя в Модели данных используется понятие Сокета (он же— коннектор, или разъем). Пара концевых коннекторов являются неотъемлемой частью любого соединителя, и с их помощью Соединитель взаимодействует со связываемыми сущностями. Стоит обратить внимание, что в объектной Модели приложения, при реализации количественного взаимодействия понятийных сущностей, аналогичную роль таких коннекторов выполняют Атрибуты отношения, содержащие в своих характеристиках полное описание свойств отношения. Аналогичным образом, каждый из двух Сокетов соединителя содержит полное описание характеристик декларируемой связи со своей стороны, и этой информации вполне достаточно для организации полноценного двустороннего взаимодействия Атрибутов.
Таким образом, на уровне Модели приложения, при декларировании причинно- следственной зависимости двух Атрибутов, каждый из них получает в свое владение Сокет, который в свою очередь является экземпляром, производным от абстрактной сущности мета-Сокет.
Важно подчеркнуть, что настоящее изобретение дополняет стандартную и
общепринятую Мета-модель системы управления данными третьим фундаментальным членом— формализованным абстрактным мета-Сокетом. Мета-Сокет связан с мета- Атрибутом отношением ребенок-родитель, точно так же, как мета- Атрибут связан с мета-Классом. Представляя собой такое же формализованное описание, как и мета- Класс или мета- Атрибут, мета-Сокет включает в себя декларативное описание характеристик экземпляров Сокета, которые будут подробно рассмотрены ниже.
Единичный Сокет характеризуется по меньшей мере тремя аспектами: адресным, функциональным и событийным, каждый из которых включает в себя соответствующий набор декларативных характеристик.
Адресный аспект позволяет Сокету однозначно идентифицировать в Модели
приложения оппозитный Сокет общего для обоих сокетов Соединителя. Следует учитывать, что Сокет не обладает собственной прямой (глобальной)
идентифицируемостью, так как локализован в кортеже Атрибута, который в свою очередь локализован в кортеже Класса. В столь сложно-структурированной
многоуровневой Модели приложения, для реализации связи Сокетов необходимо использовать максимально простую, компактную и универсальную систему организации внутренней идентификации всех субъектов Модели. При этом, для полноты картины следует вспомнить, что в объектном представлении Атрибут может определять не только унитарную, но и перечислимую форму хранения производных от него информационных значений. Перечислимая форма предполагает, что Атрибут включает в состав своих характеристик, помимо собственного наименования, кортеж пользовательских наименований элементов перечисления, а производное от него значение представлено массивом значений. Таким образом, полный адресный аспект Сокета должен включать в себя идентификаторы Класса и Атрибута класса, которым принадлежит оппозитный Сокет, а также идентификатор оппозитного Сокета в кортеже Атрибута, и
идентификатор элемента перечислимой формы Атрибута.
Обратим внимание, что в Модели приложения отношение родитель-ребенок выражается наличием у Класса кортежа Атрибутов, и наличием у Атрибута кортежа Сокетов.
Аналогичным образом, Классы Модели приложения также образуют кортеж, владельцем которого является служебная абстрактная сущность, именуемая супер-Классом. Причем стоит также обратить внимание, что упомянутый кортеж супер-Класса может быть образован как непосредственно Классами - экземплярами мета-Класса, так и
Атрибутами отношения с супер-Классом, которое (Отношение) автоматически декларирует каждый Класс при своем создании. Логически, каждый упомянутый кортеж содержит линейный набор однородных (в пределах кортежа) экземпляров, и в самом общем случае представляет собой динамически расширяемый массив. В таком массиве для размещения каждого нового экземпляра автоматически создается новая ячейка, что позволяет каждый экземпляр кортежа однозначно и уникально идентифицировать индексом элемента кортежа. Эта существенная особенность позволяет выразить полный адресный аспект Сокета простой форматной записью, включающей в себя четыре индекса упомянутых ранее субъектов.
Указанный способ унифицированной индексной идентификации всех разнородных экземпляров Модели приложения, производных от мета-Классов, мета- Атрибутов и мета-Сокетов системы управления данными, является важным аспектом настоящего изобретения. Этот способ позволяет не только упростить и унифицировать
декларативную адресацию, но и существенно ускорить реализацию методов доступа к требуемому экземпляру— субъекту Модели приложения. Кроме того, индексный способ идентификации обеспечивает полную независимость Модели приложения от используемых пользовательских наименований Классов и Атрибутов, которые, как правило, непосредственно заимствуются у понятийных сущностей предметной области, и их характеристик. При анализе адресного аспекта Сокета следует обратить внимание на следующую важную особенность использования входящего в его состав индекса элемента перечисления. При передаче значения через абстрактный Соединитель, упомянутый индекс может быть не инициализирован в двух случаях: 1) целевой Атрибут не использует перечислимую форму хранения; 2) Сокет адресует сразу все элементы перечислимой формы. В последнем случае абстрактный Соединитель используется одновременно и одинаковым образом применительно ко всем элементам целевого Атрибута, реализуя тем самым групповую зависимость. Если же абстрактный
Соединитель связывает два атрибута с перечислимой формой хранения, и упомянутый индекс адресного аспекта обоих Сокетов не инициализирован, то реализация групповой зависимости осуществляется исключительно попарно, то есть через общий Соединитель между собой взаимодействуют только элементы Атрибута с одинаковым индексом.
Функциональный аспект Сокета позволяет управлять модификацией значения, и включает в себя в том числе идентификатор метода вычисления и флаг инверсии.
В вычислительной среде системы управления данными с каждым функциональным типом значения сопоставлен предопределенный набор вычислительных методов (функционалов), потенциально применимых к значениям данного типа. При этом каждый метод может быть уникально идентифицирован, и в то числе числовым идентификатором-индексом. В приведенном ранее примере (Total = Quantity х Price), где атрибут Total связан одним соединителем с атрибутом Quantity, а другим— с атрибутом Price, таким методом является мультипликативная арифметическая операция.
Стоит обратить внимание на тот факт, что абстрактным соединителем можно связать два Атрибута только в том случае, если их функциональные типы совпадают, или если в системе управления данными существует по меньшей мере один предопределенный метод, позволяющий преобразовать значение из функционального типа одного Атрибута в функциональный тип другого.
Флаг инверсии значения (Inverse) используется в элементарных арифметических и логических операциях как для изменения знака значения-аргумента, так и для изменения характера операции, и тем самым позволяет сократить номенклатуру предопределенных методов системы управления данными. Так если флаг инверсии установлен Сокету, локализованному в кортеже атрибута-аргумента, то тем самым он изменяет знак значения-аргумента на противоположный, при этом соединитель не изменяет передаваемое значение-аргумент, а только передает вместе с ним значение флага инверсии. Если же флаг инверсии установлен Сокету, локализованному в кортеже целевого атрибута, то такой флаг изменяет характер операции. Например, таким образом можно мультипликативное умножение преобразовать в операцию деления на значение- аргумент.
Событийный аспект Сокета позволяет управлять передачей значения, и характеризуется флагами Set и Get, разрешающими Атрибуту использование Сокета в операциях извлечения и рассылки значения.
В вычислительной среде системы управления данными механизм использования абстрактного соединителя, образованного парой Сокетов, основан на двух базовых методах, предоставляемых Мета-Сокетом. На уровне действующих Атрибутов этот механизм реализуется следующим образом:
1) Метод Set предоставляется Сокетом для передачи значения оппозитному Сокету целевого Атрибута соединителя. При любом изменении своего производного значения (независимо от причины и источника изменения) Атрибут последовательно
просматривает свой кортеж Сокетов, и для каждого сокета, у которого установлен флаг Set, вызывает метод Сокета Set, не заботясь о последствиях.
2) Метод Get предоставляется Сокетом для запроса значения у оппозитного Сокета. Независимо от источника события, принуждающего к формированию производного значения, Атрибут последовательно просматривает свой кортеж Сокетов, и для каждого Сокета, обладающего установленным флагом Get, вызывает одноименный метод. Метод Get возвращает Атрибуту из соединителя значение, к которому Атрибут для получения результирующего значения применяет вычислительный метод, назначенный Атрибуту, с учетом функционального аспекта Сокета.
Для пояснения важного аспекта настоящего изобретения следует обратить внимание, что во всех современных системах управления данными, и в том числе основанных на реляционном представлении, Атрибут оперирует значением, существующим в явной хранимой форме. При этом методы Атрибута используются только для того, чтобы извлечь хранимое значение, или сохранить значение, сформированное где-то вовне, приведя его к удобной для хранения форме.
С введением в Модель приложения абстрактных соединителей, Атрибут получает способ вычисления производного значения "на лету" непосредственно в Модели данных, в том числе в момент обращения к Атрибуту. Это обстоятельство приводит к следующим важным последствиям:
1) Если хранимое производное значение Атрибута к моменту обращения к нему еще не было инициализировано (не сформировалось), то, при наличии в его кортеже Get- Сокетов, Атрибут обладает способом сформировать и сохранить это значение
непосредственно в момент обращения к нему. Иначе, при наличии хранимого значения, Атрибут вернет его, не обращаясь к кортежу Сокетов;
2) Как следствие, появляется возможность ввести в Мета-модель системы управления данными новый событийный метод Атрибута, именуемый Пересчет значения
(Recalculate), позволяющий "привязать" формирование производного значения к внешнему событию. Метод Recalculate, применимый при наличии в кортеже Атрибута Get-Сокетов, принуждает Атрибут сформировать хранимое значение заново, опросом кортежа сокетов;
3) Появляется возможность объявить Атрибут динамическим, для чего к
характеристикам атрибута добавляется свойство-флаг Dynamic. Динамический (с установленным флагом Dynamic) Атрибут, будучи полноправным Атрибутом в кортеже Класса, в принципе не образует производного значения в хранимой форме, и, соответственно, при обращении к нему за значением не пытается извлечь значение из системы хранения. Вместо этого, при каждом обращении к нему, динамический Атрибут формирует возвращаемое производное значение опросом своих Get-Сокетов.
Естественно, прямым следствием такого поведения является тот факт, что динамический Атрибут не может принять значение извне. В приведенном ранее примере (Total = Quantity х Price), атрибут Total вполне можно объявить динамическим, при
необходимости. Не динамический Атрибут, в целях отличить его в описании от динамического, далее именуется статическим Атрибутом.
Введение в Модель данных события Recalculate и динамических свойств Атрибута является важным аспектом настоящего изобретения, качественно расширяющим общую функциональность системы управления данными. Также, при этом открывается возможность неявно управлять общей физической производительностью системы, комбинируя статический и динамический способы формирования Атрибутами своих производных значений. Причинно-следственный характер декларируемой зависимости Атрибутов предполагает, что абстрактный соединитель обладает такими характеристиками как направление передачи значения и активность действия зависимости. Обе эти характеристики самым естественным образом определяются состоянием флагов Set и Get в обоих Сокетах соединителя.
Флаг Get определяет направление передачи значения опосредственно. Если Сокету установлен флаг Get, то Атрибут может (по запросу) получить значение из данного соединителя. Флаг Get устанавливается непосредственно при создании соединителя в соответствующем направлению передачи значения Сокете целевого Атрибута.
Флаг Set определяет и активность соединителя, и направление передачи. Если Сокету установлен флаг Set, то соединитель активно передает любое изменение значения Атрибута, которому принадлежит Set-Сокет, в адрес оппозитного Атрибута. Если же флаг Set не установлен ни в одном из Сокетов, то соединитель не обладает собственной активностью, и передаст значение только по запросу. Обратим внимание, что в кортеже Сокетов динамического Атрибута по определению не может быть ни одного Сокета с установленным флагом Set.
Существует частный случай, когда флаг Set может быть установлен в обоих Сокетах соединителя. В приведенном ранее примере (Total = Quantity х Price), если атрибут Total является статическим, а оба соединителя (Price -> Total и Quantity -> Total) активны (флаг Set установлен сокетам атрибутов-аргументов Quantity и Price), то атрибут Total очевидным образом не может получить произвольное значение извне, так как тем самым нарушится декларированное соединителями общее правило жесткой взаимной зависимости значений трех атрибутов, строго поддерживаемое вычислительной средой. В этом случае, разрешить прием внешнего значения в Total можно только при наличии возможности осуществить реверс изменения результирующего значения произведения в один из двух атрибутов-аргументов (например, в Price), то есть принудительно изменить значение аргумента таким образом, чтобы оно соответствовало введенному значению результата.
Для декларации возможности реверса значения Total, достаточно в его сокете
соединителя с требуемым аргументом установить флаг Set. Получив значение извне, целевой Атрибут определяет реверсивный Сокет (как обладающий одновременно установленными флагами Get и Set), используя декларации функционала и остальных Get-сокетов "вычисляет" значение аргумента, удовлетворяющее их правилам, и передает это значение в реверсивный сокет.
При этом следует обратить внимание на следующую общую важную особенность реализации вычислительной среды системы управления данными: при поступлении Атрибуту (или извлечении Атрибутом) значения из Сокета, этот Сокет исключается из всех последующих опросов (Get) и рассылок (Set) с целью как оптимизации процесса исполнения, так и блокировки нежелательных обратных связей.
Помимо прочего, в целях настоящего изобретения следует обратить внимание на такую особенность взаимодействия атрибутов через абстрактный соединитель, как
изолированность исполнения. В самом общем случае Атрибутом реализуется следующий цикл исполнения: 1) получив входящее сообщение, включающее в себя в том числе указатель на целевой объект данных, в адрес одного из своих Get-сокетов, Атрибут 2) формирует новое производное значение, и при этом возможно
дополнительным опросом своих Get-сокетов, и 3) инициирует свои Set-сокеты на отправку исходящего сообщения. То есть Атрибут, выполняя функции "фабрики" по созданию производных значений, или предоставляя значение по запросу, логически изолирован, и не располагает какой-либо информацией об окружающей его среде, взаимодействие с которой он осуществляет путем приема/отправки информационных сообщений через Сокеты. При этом функции передаточного звена в процессе обмена сообщениями возлагаются на вычислительную среду системы управления данными, которая независимо от протяженности цепочек зависимостей Атрибутов, реализует все циклы исполнения последовательно, до полного их успешного завершения.
Соответственно, общее время реакции такой "последовательной" системы управления данными на внешнее по отношению к ней событие находится в прямой зависимости от суммарного количества вовлеченных в процесс Атрибутов и их Соединителей, и может быть достаточно значимым.
Вместе с тем, можно достаточно легко представить себе вычислительную среду, в которой некоторый исходный Атрибут со всеми своими декларациями, включая декларации Сокетов, и производными значениями, занимает локальную память отдельного процессора, связанного прямыми программно-аппаратными каналами передачи данных с другими такими же независимыми процессорами, в локальной памяти которых размещены Атрибуты, связанные абстрактными соединителями с исходным Атрибутом. В такой условно-параллельной мультипроцессорной вычислительной среде, общее время реакции системы на внешнее событие будет приблизительно равным такому же времени в последовательной вьшислительной среде только в том достаточно редком случае, когда система зависимостей имеет вид строго последовательной цепочки. Во всех остальных случаях, для "разветвленной" системы зависимостей общее время реакции мультипроцессорной системы будет очевидно меньше за счет параллельного исполнения в отдельных "ветвях".
В мультипроцессорной вычислительной среде, общее время реакции системы на единичное событие пользователя определяется протяженностью наиболее длинной последовательной цепи зависимостей из всех существующих, без учета ответвлений от нее. Помимо этого, в отличие от чисто последовательной, мультипроцессорная вычислительная может одновременно начать параллельную обработку произвольного количества внешних событий, адресованных различным атрибутам, что существенно сокращает общее время реакции системы управления данными. Обыкновенно, для организации исполнения в программ в мульти-поточных вычислительных средах, приходится предпринимать определенные усилия для принудительного
распараллеливания бизнес-процессов внутри программы.
Модель приложения, образованная совокупностью Атрибутов, связанных абстрактными соединителями, в которой функциональность каждого Атрибута изолирована, а декларации локализованы в отдельной памяти соответствующего процесса,
автоматически является "параллельной" с точки зрения организации процесса исполнения в мультипроцессорной среде. Естественно, при размещении деклараций Атрибутов и производных значений в памяти процессоров таким образом, чтобы связь Атрибутов осуществлялась через каналы связи процессов.
В целях настоящего изобретения важно подчеркнуть, что различные аспекты
абстрактного Соединителя двух атрибутов могут быть поставлены в причинно- следственную зависимость от некоторого третьего Атрибута, производное значение которого динамически изменяет функциональное поведение зависимого соединителя. Такая зависимость в Модели приложения также декларируется и реализуется абстрактным Соединителем, который связывает один из Сокетов зависимого
соединителя с управляющим Атрибутом. Этот управляющий Соединитель по сути является дополнением к основному зависимому Соединителю, который в этом случае рассматривается в качестве базового. Соответственно далее, для удобства изложения, зависимый Соединитель, его Сокеты и связываемые Атрибуты будут именоваться "базовыми", а управляющий Соединитель, его Сокеты и управляющий Атрибут будут дополнительно выделяться приставкой "-условие".
Взаимодействие базового Сокета и Сокета-условие, унифицированно локализованных в общем кортеже базового Атрибута, можно реализовать различным образом, и в том числе через систему взаимных указателей друг на друга. Но более предпочтительным является вариант, при котором Соке управляющего соединителя целиком
инкапсулирован в тело базового Сокета. Преимуществом такой реализации является ряд следующих обстоятельств: 1) оппозитный Сокет, локализованный в кортеже Атрибута- условия, получает возможность адресовать не свой оппозитный сокет, а
непосредственно базовый Сокет, которому и транслирует свои события; 2) свойства управляющего соединителя полностью определяются свойствами сокета в кортеже Атрибута-условия, а инкапсулированный оппозитный сокет сохраняет только свою адресную часть; 3) фиксированный по назначению характер инкапсуляции.
Базовый сокет перманентно допускает всего три позиционно-фиксированных
инкапсуляции управляющих сокетов, при этом каждая инкапсуляция соответствует одному конкретному аспекту функциональности базового соединителя, а именно:
блокирующему, адресному и контекстному, которые будут подробно рассмотрены ниже. В целях настоящего изобретения важно подчеркнуть, что указанные инкапсуляции, и управляемые ими аспекты могут быть задействованы одновременно, и в любых комбинациях их взаимной актуальности.
Инкапсуляция считается актуальной, если содержит в себе адресную часть оппозитного сокета управляющего соединителя. При исполнении вызванного относительно него метода Set или Get, базовый Сокет проверяет все три инкапсуляции, и для каждой из актуальных выполняет соответствующее ее функциональному аспекту действие.
Следует отметить, что введение причинно-следственной зависимости Соединителя в Модель приложения, дополняет исполнительную среду системы управления данными, представленную методами Set и Get, двумя новыми методами: Unset и Reset.
Соответственно, в унифицированную структуру Сокета (мета-Сокета) добавляется два одноименных флага, разрешающих вызов соответствующего метода. Флаги Unset и Reset на практике используются применительно только к управляющим Сокетам, а разрешаемые ими методы по сути являются событиями, извещающими базовый соединитель об изменениях значения управляющего атрибута: Reset сигнализирует об инициализации управляющего значения; Unset - о его де-инициализации. При этом собственно управляющее значение не передается, базовый Сокет извлекает его при необходимости самостоятельно. Механизм использования методов Unset и Reset достаточно прост: в процессе изменения своего производного значения, перед собственно его изменением, статический Атрибут последовательно просматривает свой кортеж Сокетов, и для каждого Сокета, у которого установлен флаг Unset, вызывает одноименный метод. После фиксации нового значения Атрибут снова последовательно просматривает свой кортеж Сокетов, и для каждого Сокета, у которого установлен флаг Reset, снова вызывает одноименный метод. Тем самым адресуемый базовый
Соединитель инициируется сначала (Unset) на исполнение действия, обратного своему прямому воздействию на зависимое значение (аналогично де-инициализации
собственного значения, при исходном управляющем контекстном значении), а затем (Reset) снова инициируется, но уже на прямое действие с новым управляющим значением. В свою очередь базовый Атрибут, обладающий инкапсуляцией, извлекает управляющее значение, используя метод Get, и адресную составляющую этой инкапсуляции.
Рассмотрим самый простой в понимании аспект управления— блокировку
передаточной функции соединителя. Управляющий соединитель с блокирующим аспектом создается, если в качестве управляющего Атрибута-условия выбран атрибут логического типа. При наличии в декларациях базового сокета актуальной блокирующей инкапсуляции, во всех методах этого сокета перед их исполнением осуществляется запрос состояния управляющего атрибута (конкретного производного значения). Если вызов Get в адрес Атрибута-условия вернет значение True, то исполнение текущего метода базового сокета будет продолжено, иначе (False)— прекращено.
Стоит обратить внимание, что самостоятельный сокет управляющего соединителя, локализованный в кортеже Атрибута-условия, в свою очередь может рассматриваться в качестве целевого субъекта блокирующего управления. Это обстоятельство позволяет создавать управляющие цепочки блокировок произвольной протяженности.
Наличие в свойствах абстрактного соединителя адресного аспекта управления, позволяет связывать абстрактными соединителями атрибуты разных классов. По ходу изложения до настоящего момента неявно подразумевалось, что связанные
абстрактными соединителями атрибуты принадлежат одному классу, и, соответственно, их производные значения взаимодействуют в пределах одного производного экземпляра Класса (объекта данных). Если же абстрактный соединитель связывает атрибуты разных классов, то для получения доступа к целевому значению, принадлежащему другому объекту данных, в параметрическую часть методов сокета следует (наряду с
идентификаторам целевых субъектов метаданных: Класс, Атрибут [Элемент], Сокет) включать и идентификатор целевого объекта. Идентификатор стороннего объекта данных может присутствовать в исходном объекте только как значение, производное от атрибута отношения. А значит, взаимная связь Атрибутов разных классов возможна, если только эти атрибуты локализованы в классах, между которыми действует отношение количественного взаимодействия (отношение Классов), и должна учитывать характер этого отношения. При этом, реализация упомянутой связи в форме
абстрактного соединителя должна использовать атрибуты отношения в качестве Управляющих атрибутов этого соединителя. Таким образом, при создании абстрактного соединителя атрибутов через отношение классов этих атрибутов, для одного или обоих базовых сокетов соединителя автоматически создается управляющий соединитель с соответствующим атрибутом отношения в качестве управляющего атрибута, с включением этого соединителя в адресный аспект базового сокета.
При наличии в декларациях базового сокета актуального адресного включения
(инкапсуляции), во всех методах Set или Get этого сокета перед их исполнением осуществляется запрос значения управляющего атрибута отношения. Если вызов Get в адрес управляющего атрибута вернет пустое значение (то есть, декларированное в классах отношение, не реализовано на уровне объектов), то исполнение текущего метода базового сокета будет прекращено. Иначе, полученное значение будет включено в параметрическую часть метода, обращенного к оппозитному сокету, в качестве идентификатора целевого объекта данных.
Стоит обратить внимание, что прямой зависимостью, выраженной абстрактным соединителем, можно связать в том числе и атрибуты отношения, локализованные в разных классах.
В качестве наглядного примера такой зависимости рассмотрим следующую предметную область (в форме утверждения): "Сотрудник числится в Департаменте конкретной Компании". Если все три класса (Сотрудник, Департамент, Компания) связаны между собой очевидным отношением "многие-к-одному" (Департамент -> Компания,
Сотрудник -> Департамент, Сотрудник -> Компания), то можно декларировать не менее очевидную ссылочную зависимость, которая связывает между собой атрибуты отношения Департамент Компания и Сотрудник Компания, и реализуется через отношение Сотрудник -> Департамент. Понятийная очевидность заключается в том, что Сотрудник, в числе прочих своих характеристик, хранит указатель на свою
принадлежность к конкретной Компании, причем именно к той (и только к той), в состав которой входит Департамент, в котором он числится. Если по какой-либо причине весь Департамент целиком перейдет под юрисдикцию другой компании, то под воздействием прямого соединителя каждый Сотрудник автоматически получит у Департамента новое значение указателя на Компанию. То есть, при наличии указанной декларации, Модель данных будет способна автоматически соблюдать ссылочную целостность и
непротиворечивость, причем непосредственно на уровне хранимых данных. При этом, побочным эффектом указанной ссылочной зависимости будет являться автоматическое ограничение, осуществляемое Моделью данных при выборе Сотрудником другого Департамента в той же Компании (например, при переводе на другую работу). Из полного множества всех Департаментов всех Компаний, Модель данных предоставит к выбору только Департаменты той Компании, в которой числится Сотрудник.
Помимо рассмотренной ссылочной зависимости, существует еще по меньшей мере несколько различных вариантов зависимостей, возникающих в системе классов при различной комбинации меж-классовых отношений, и требующих соблюдения правил согласованности и взаимной непротиворечивости значений атрибутов отношений.
Рассмотрение всех этих зависимостей выходит за рамки настоящего описания, но в целях настоящего изобретения важно подчеркнуть, что все они без исключения также реализуются при помощи абстрактных Соединителей.
Взаимодействие значений через асимметричное отношение классов "многие-к-одному" подразумевает в том числе, что множество значений на стороне "многие-" образует единственное значение на стороне "-один". Такое объединение возможно только при использовании некоторых упомянутых ранее методов, предопределенных на уровне Мета-модели данных, и именуемых функционал атрибута. Например, в классе Счет (Invoice) общая Сумма счета (Total) представляет собой обобщение множества частных сумм (Total) отдельных Записей этого счета (Invoice record), которое реализуется соединителем, связывающим атрибуты Total в классах Invoice и Invoice Record, и соответствующим функционалом атрибута Total в классе Invoice, который выполняет суммирование входящего множества значений.
Наличие в свойствах абстрактного соединителя контекстного аспекта управления позволяет Модели приложения формировать комплексные значения атрибутов, представляющие собой список записей в формате "ключ-значение" (key-value). Такой список упорядочен по значению ключа (key), что позволяет при помощи ключа извлекать из него отдельные унитарные значения. Для управления списком в Мета- модели предопределен соответствующий функционал, использующий контекстно управляемый абстрактный соединитель в качестве источника значений (value) и ключей (key).
В качестве иллюстрации рассмотрим списковый атрибут Rate List в классе Валюта (Currency), который содержит список записей, образованный парами значение курса (Rate) на определенную дату (Date), производными от атрибутов, локализованных в классе День (Date). Очевидно, что для формирования такого списка атрибутом Rate List на стороне отношения "-один" (Currency), необходимо каждому значению Rate из множества на стороне отношения "многие-" (Date) сопоставить значение Date. Такое сопоставление и осуществляется управляющим соединителем, с использованием контекстного аспекта управления.
При наличии в декларациях базового сокета актуального контекстного включения (инкапсуляции), во всех методах Set и Get этого сокета перед их исполнением осуществляется запрос значения управляющего Атрибута. Если вызов Get в адрес Атрибута-контекста вернет пустое значение (значение не инициализировано), то исполнение текущего метода базового сокета будет прекращено. Иначе, полученное значение будет включено в параметрическую часть метода, обращенного к оппозитному сокету, в качестве контекстного значения, дополняющего основное значение. Далее, управляющий списком функционал использует контекстное значение в качестве ключа для локализации требуемой записи.
Следует обратить внимание, что контекстное значение может использоваться не только для формирования списка ключ-значение, но также для извлечения значения из такого списка, которое осуществляется аналогичным соединителем с управляющим контекстом.
В целях настоящего изобретения важно подчеркнуть, что абстрактный соединитель используется не только для описания и реализации причинно-следственной
зависимостей предметной области, но и для решения чисто внутренних утилитарных задач самой системы управления данными. К таким задачам относятся управление ссылочной симметрией и соблюдение ссылочной целостности.
В парадигме объектного представления данных, соблюдение ссылочной целостности жестко обеспечивается полной симметрией реализации отношения классов, которая выражается в том, что каждому значению ссылки (прямой) в исходном объекте данных на другой (оппозитный) объект, соответствует значение ссылки (обратной) в оппозитном объекте на исходный объект. Соответственно, при декларации количественного взаимодействия (Отношения) двух классов, в каждом из этих классов создается атрибут отношения, типизированный идентификатором оппозитного класса отношения. При этом ссылочное значение, производное от атрибута отношения, фактически является идентификатором целевого объекта.
Логично предположить, что оба атрибута отношения должны быть связаны активным абстрактным соединителем, именуемым далее ссылочным, который и будет
обеспечивать ссылочную целостность и симметрию отношения непосредственно на уровне Модели приложения. Но такому связыванию, реализуемому непосредственно, препятствует тот факт, что в разных классах атрибуты общего отношения имеют разный тип значения. Для пояснения механизма реализации ссылочного соединителя следует вспомнить, что Класс в числе прочих содержит в своем кортеже служебный атрибут Self, существование которого декларировано непосредственно в мета-Классе. В конкретном Классе, экземпляре мета-Класса, атрибут Self типизируется идентификатором своего Класса, и соответственно, производным значением этого атрибута в объекте данных будет идентификатор этого объекта.
Для каждого из связанных отношением классов, тип значения атрибута Self совпадает с типом значения Атрибута отношения в оппозитном классе, что позволяет связать эти атрибуты абстрактным Соединителем (ссылочным), с использованием Атрибута отношения на стороне атрибута Self в качестве атрибута, управляющего адресным аспектом. При декларировании Отношения классов, такой ссылочный Соединитель создается автоматически, непосредственно вслед за созданием атрибутов отношения, при этом базовый Сокет, локализованный в кортеже атрибута Self, автоматически же получает дополнительный, управляющий адресным аспектом Соединитель с
упомянутым Атрибутом отношения в своем классе.
В абсолютно симметричном отношении количественного типа "один-к-одному", оба атрибута отношения равноправны, поэтому ссылочный соединитель создается для каждого атрибута Self в каждом классе. Таким образом, получение атрибутом
отношения ссылочного значения в любом из объектов классов, связанных отношением "один-к-одному", немедленно приводит к получению аналогичного значения
оппозитным ему атрибутом отношения.
В отношении типа "многие-к-одному" наблюдается явная асимметрия реализации, которая выражается прежде всего в том, что только атрибут отношения на стороне "многие-" вправе инициировать обмен идентификаторами, так как значением атрибута отношения на стороне "-один" очевидно будет производный условно-пассивный список "обратных" ссьшок. Соответственно, при создании отношения такого типа, ссылочный соединитель создается только для атрибута Self на стороне "многие-".
При этом, так как упомянутый список обратных ссьшок существует по общим правилам списков, и представляет собой список записей в формате "ключ-значение", управляемый унифицированным функционалом, то ссылочный соединитель автоматически
дополняется еще одним управляющим соединителем, но теперь уже с контекстным аспектом управления. В качестве Атрибута для контекстного управления по умолчанию выбирается Атрибут, представляющий собой основную характеристику Класса:
Наименование (Name), или Событие (Date).
Указанная асимметрия отношения "многие-к-одному" порождает терминологическую разницу: атрибут отношения на стороне "многие-" далее именуется атрибутом "прямой" ссылки, а атрибут отношения на стороне "-один" - атрибутом "обратной" ссылки. В симметричном отношении "один-к-одному", оба атрибута отношения равноправны, и фактически являются атрибутами "прямой" ссылки.
И в реляционной, и в объектной реализациях системы управления данными, для управления циклом жизни объекта данных предусмотрена характеристика сущности, значение которой указывает, актуален объект данных, или он отмечен как удаленный. Соответственно, любой Класс в числе прочих содержит в своем кортеже служебный атрибут Delete, существование которого декларировано непосредственно в мета-Классе. Если в объекте данных производное значение атрибута Delete инициализировано, то объект данных считается удаленным (неактуальным). По правилам ссылочной целостности, удаленный объект должен де-инициализировать все свои связи с другими объектами таким образом, чтобы в системе управления данными не содержалось прямых или обратных ссылок на этот объект. При этом, при наличии актуальных "обратных" ссылок на объект данных, его удаление с точки зрения предметной области и Модели приложения не считается корректным, так как при этом теряется весьма значимая информация. Например, если удалить объект Счета (Invoice), то объекты Запись счета (Invoice Record) фактически останутся изолированными. Иначе говоря, при наличии хотя-бы одного объекта Invoice Record, удаление объекта Invoice следует запретить. Вместе с тем, если обеспечить условие, при котором все объекты Invoice Record будут удалены одновременно с объектом Invoice, то удаление объекта Invoice не приведет к нарушению ссылочной целостности.
Рассмотрим подробнее механизмы реализации указанных причинно-следственных зависимостей при помощи абстрактных соединителей Модели приложения. Очевидно, что атрибут Delete обладает абстрактными соединителями с каждым атрибутом отношения в своем классе, причем эти соединители создаются автоматически непосредственно при декларации отношения классов.
Рассмотренный ранее ссылочный Соединитель, на стороне атрибута Self (прямая ссылка) дополнен управляющим соединителем с атрибутом Delete с блокирующим аспектом (таким образом, актуальны все три управляющих аспекта базового сокета ссылочного соединителя, локализованного в кортеже атрибута Self). Этот управляющий соединитель обладает перманентно установленным флагом Inverse, и при
инициализации значения атрибута Delete блокирует передаточную функцию базового соединителя, что в свою очередь вызывает де-инициализацию связи объектов, с аннулированием соответствующего значения в обратной ссылке объекта данных оппозитного класса (значение прямой ссылки в исходном объекте при этом
сохраняется). В отношении типа "один-к-одному", в котором атрибуты отношения симметрично связаны ссылочными соединителями, а атрибут прямой ссылки одновременно является и атрибутом обратной ссылки, в результате инициализации значения Delete будут аннулированы оба ссылочных значения. Тем самым, при любом типе отношения классов, удаляемый объект автоматически аннулирует все внешние указатели на себя в других объектах данных.
Помимо этого, атрибут Delete обладает пассивными абстрактными соединителями с каждым атрибутом обратной ссылки в своем классе. Наличие такого соединителя позволяет функционалу атрибута проинспектировать состояние значений обратных ссылок, и, при наличии хотя бы одного актуального значения, перманентно блокировать процедуру удаления объекта данных.
По условиям предметной области возможно потребуется удалить объект данных вместе со всем множеством ссылающихся на него объектов. Например, удалить объект Invoice вместе со всеми его объектами Invoice Record. В этом случае необходимо создать абстрактный Соединитель, связывающий атрибуты Delete в классах Invoice и Invoice Record, с установленным на стороне Invoice флагом Set. Этот соединитель в классе Invoice будет автоматически дополнен управляющим Соединителем с атрибутом обратной ссылки (Invoice Record), и при этом де-активирован (сброшен флаг Get) упомянутый выше Соединитель, связывающий Delete и Invoice Record. Тогда, при инициализации значения атрибута Delete в объекте класса Invoice, он использует имеющийся список обратных ссылок Invoice Record для инициализации Delete во всех объектах Invoice Record, ссылающихся на исходный объект Invoice.
Таким образом, как было показано выше, декларация функциональной причинно- следственной зависимости значений при помощи унифицированных экземпляров Сокетов, образующих абстрактные Соединители атрибутов различного типа и назначения, является универсальным способом реализации самого сложного
функционального поведения, осуществляемой комбинацией очень простых методов и деклараций. Притом, что показательно— не только функциональности, обусловленной потребностями предметной области автоматизации, но и служебной, сугубо внутренней функциональности самой системы управления данными.
Так как все Сокеты являются простыми декларативными экземплярами мета-Сокета, а все методы исполнения являются системными и предопределенными, то тем самым целевую функциональность произвольного уровня сложности можно реализовать без написания программных кодов, простым созданием абстрактных Соединителей и установкой их флагов непосредственно на уровне Модели приложения, причем указанные действия вполне осуществимы методами прямого визуального
конструирования.
Важно подчеркнуть, что в настоящем описании были рассмотрены наиболее значимые аспекты абстрактных Соединителей и Сокетов, и наиболее значимое их поведение. Вместе с тем различные модификации упомянутого могут быть сделаны и без отступления от сущности и объема настоящего изобретения, который ограничивается только формулой изобретения и ее эквивалентами.

Claims

ФОРМУЛА
1. Система управления данными в вычислительной среде, включающей в себя по меньшей мере один компьютерный процессор для обработки данных и соединенную с процессором память для хранения данных, в которой данные представлены в том числе машиночитаемыми информационными значениями, которые являются экземплярами, производными от декларативных субъектов мета-описания, включающего в себя в том числе формализованные машиночитаемые декларации, описывающие понятийные сущности, а также характеристики этих сущностей, которые именуются атрибутами сущности, отличающаяся тем, что декларация причинно-следственной зависимости упомянутых информационных значений, является субъектом мета-описания, и принимает форму абстрактного унифицированного соединителя упомянутых атрибутов, и при этом упомянутая декларация зависимости реализуется таким образом, что каждый из связанных зависимостью атрибутов получает уникально идентифицируемый экземпляр, производный от унифицированной структуры данных, именуемой сокетом, и при этом каждый экземпляр сокета хранит полный набор адресных, функциональных и событийных характеристик упомянутого абстрактного соединителя относительно атрибута сущности, которому принадлежит.
2. Система управления данными по п.1, отличающаяся тем, что полная
совокупность упомянутых сокетов отдельного атрибута сущности образует кортеж сокетов атрибута в форме однородного массива, в котором каждый сокет уникально идентифицируется своим неизменным порядковым номером.
3. Система управления данными по п.1 , отличающаяся тем, что упомянутые адресные характеристики абстрактного соединителя представлены в том числе идентификаторами целевых атрибута сущности и сокета атрибута на противоположной стороне соединителя; упомянутые событийные характеристики абстрактного
соединителя представлены в том числе флагами, указывающими направление и определяющими условия передачи значения по соединителю; упомянутые
функциональные характеристики абстрактного соединителя представлены в том числе флагами, управляющими модификацией значения при передаче.
4. Система управления данными по п.1 , отличающаяся тем, что причинно- следственная зависимость упомянутых адресных, функциональных и событийных свойств отдельного сокета абстрактного соединителя двух атрибутов сущности от информационного значения, производного от третьего атрибута сущности, также реализуется созданием двух сокетов, образующих дополнительный абстрактный соединитель в соответствии с п.1, при этом второй сокет дополнительного соединителя принадлежит атрибуту, который владеет зависимым сокетом, и оба этих сокета связаны взаимными указателями.
5. Система управления данными по п.4, отличающаяся тем, что зависимый сокет инкапсулирует сокет дополнительного соединителя.
6. Система управления данными по п.1 , отличающаяся тем, что упомянутый атрибут понятийной сущности обладает дополнительной характеристикой, которая содержит идентификатор системного функционального метода вычисления, и при этом в полном множестве вычислительных методов упомянутой системы управления данными каждый отдельный метод вычисления обладает уникальной
идентифицируемостью.
7. Система управления данными по п.1 , отличающаяся тем, что упомянутый атрибут понятийной сущности обладает дополнительной характеристикой - флагом, установка которого изменяет поведение атрибута таким образом, что он более не ассоциирован с производным значением в хранимой форме, а формирует и возвращает производное значение в момент обращения к атрибуту, используя для этого
действующие экземпляры абстрактного соединителя.
8. Способ управления данными в вычислительной среде, включающей в себя по меньшей мере один компьютерный процессор для обработки данных и соединенную с процессором память для хранения данных, в которой данные представлены в том числе машиночитаемыми информационными значениями, которые являются экземплярами, производными от мета-описания, включающего в себя в том числе формализованные машиночитаемые декларации понятийных сущностей и характеристик этих сущностей, именуемых атрибутами сущности, отличающийся тем, что причинно-следственную зависимость упомянутых информационных значений, декларируют в абстрактной форме унифицированного соединителя упомянутых атрибутов, и реализуют
непосредственно в мета-описании путем создания у каждого из соединяемых атрибутов экземпляра унифицированной структуры данных, именуемой сокетом, и при этом упомянутые атрибуты формируют производные от них информационные значения в том числе в соответствии с зависимостями, декларированными действующим набором сокетов атрибута, таким образом, что полная совокупность информационных значений сохраняет свою непрерывную согласованность и логическую целостность.
9. Способ управления данными по п.8, отличающийся тем, что упомянутое производное информационное значение извлекают путем обращения к
соответствующему атрибуту, и при этом упомянутый атрибут, формирует возвращаемое значение в том числе путем опроса своих сокетов, после чего применяет в отношении полученного таким образом множества значений назначенный ему уникально идентифицируемый способ вычисления результирующего значения, при этом сокет возвращает значение, полученное обращением к адресуемому сокетом атрибуту, если сокет отмечен флагом, разрешающим извлечение значения из него.
10. Способ управления данными по п.8, отличающийся тем, что упомянутое производное информационное значение изменяют путем передачи нового значения соответствующему атрибуту, и при этом упомянутый атрибут использует в том числе назначенный ему уникально идентифицируемый способ вычисления результирующего значения, а также свои сокеты для передачи через них изменения производного значения, и тем самым инициирует у адресуемых сокетами атрибутов процесс формирования нового значения, при этом сокет осуществляет передачу, если отмечен соответствующим флагом.
11. Способ управления данными по п.10, отличающийся тем, что упомянутая передача изменения производного значения реализуется путем передачи адресуемому сокетом атрибуту указателей на значение до изменения и новое измененное значение.
12. Способ унифицированной идентификации субъектов метаданных компьютерной системы управления информационными значениями в которой информационные значения являются экземплярами, производными от декларативных субъектов метаданных, которые включают в себя экземпляры унифицированной структуры данных, описывающей отдельную понятийную сущность и именуемой сущность, которая в свою очередь включает в себя в том числе экземпляры унифицированной структуры данных, описывающей характеристики сущности и именуемой атрибут сущности, которая в свою очередь включает в себя в том числе экземпляры
унифицированной структуры данных, именуемой сокет атрибута и описывающей причинно-следственную зависимость атрибутов, отличающийся тем, что каждое частное множество упомянутых однородных субъектов метаданных, как то: 1) сущностей, относительной экземпляра, ассоциированного с внешней средой; 2) атрибутов отдельного экземпляра сущности; 3) сокетов отдельного экземпляра атрибута; образует относительно своего владельца кортеж однородных экземпляров в форме простого массива, в котором каждый субъект занимает положение, неизменное во времени, и уникально идентифицируется своим порядковым номером.
13. Машиночитаемый носитель информации с сохраненным на нем кодом
программы, которая будучи исполнена на компьютере или микропроцессоре реализует систему по п.1.
14. Устройство для управления данными, включающее в себя в том числе
произвольное множество независимых процессоров или процессорных ядер, которые совокупно образуют вычислительную среду, в которой каждый процессор или процессорное ядро обладает собственной, соединенной с ним локальной памятью для хранения данных и программ, а также программно-аппаратными каналами связи с другими процессорами или процессорными ядрами этого устройства, а данные представлены в том числе информационными значениями, которые являются
экземплярами, производными от деклараций понятийных сущностей и характеристик этих сущностей, характеризующееся тем, что декларации характеристик понятийных сущностей и производные от них информационные значения распределены в локальной памяти процессоров или процессорных ядер таким образом, что функционально- событийные связи упомянутых характеристик используют упомянутые каналы связи для реализации причинно-следственной зависимости упомянутых значений.
15. Устройство для управления данными по п.14, в котором упомянутые процессоры или процессорные ядра размещены на одном кристалле.
PCT/RU2014/000959 2014-12-19 2014-12-19 Система и способ управления функционально связанными данными WO2016099318A2 (ru)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US15/536,733 US11567911B2 (en) 2014-12-19 2014-12-19 System and method for management of functionally linked data
RU2017125210A RU2693682C2 (ru) 2014-12-19 2014-12-19 Система и способ управления функционально связанными данными
CN201480084014.4A CN107111490A (zh) 2014-12-19 2014-12-19 功能约束数据的管理系统和方法
PCT/RU2014/000959 WO2016099318A2 (ru) 2014-12-19 2014-12-19 Система и способ управления функционально связанными данными

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/RU2014/000959 WO2016099318A2 (ru) 2014-12-19 2014-12-19 Система и способ управления функционально связанными данными

Publications (1)

Publication Number Publication Date
WO2016099318A2 true WO2016099318A2 (ru) 2016-06-23

Family

ID=56127807

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2014/000959 WO2016099318A2 (ru) 2014-12-19 2014-12-19 Система и способ управления функционально связанными данными

Country Status (4)

Country Link
US (1) US11567911B2 (ru)
CN (1) CN107111490A (ru)
RU (1) RU2693682C2 (ru)
WO (1) WO2016099318A2 (ru)

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6735593B1 (en) 1998-11-12 2004-05-11 Simon Guy Williams Systems and methods for storing data
US7152090B2 (en) * 2001-06-01 2006-12-19 Sun Microsystems, Inc. Metadata-aware enterprise application integration framework for application server environment
US7143100B2 (en) 2001-06-13 2006-11-28 Mci, Llc Method, system and program product for viewing and manipulating graphical objects representing hierarchically arranged elements of a modeled environment
US20030126136A1 (en) * 2001-06-22 2003-07-03 Nosa Omoigui System and method for knowledge retrieval, management, delivery and presentation
US7634501B2 (en) 2003-02-05 2009-12-15 Next Generation Software Method and apparatus for mediated cooperation
EP1452963A3 (en) * 2003-02-28 2007-06-06 Sap Ag Providing runtime object by instantiating template-derived classes
US7698293B2 (en) * 2005-01-28 2010-04-13 Microsoft Corporation System and methods for capturing structure of data models using entity patterns
US20060195460A1 (en) 2005-02-28 2006-08-31 Microsoft Corporation Data model for object-relational data
US7478102B2 (en) * 2005-03-28 2009-01-13 Microsoft Corporation Mapping of a file system model to a database object
US7734593B2 (en) 2005-11-28 2010-06-08 Commvault Systems, Inc. Systems and methods for classifying and transferring information in a storage network
US8984256B2 (en) * 2006-02-03 2015-03-17 Russell Fish Thread optimized multiprocessor architecture
EP1979808B1 (en) * 2006-02-03 2011-12-07 Fish, Russell H. III. Thread optimized multiprocessor architecture
US8577940B2 (en) * 2006-03-20 2013-11-05 Parallels IP Holdings GmbH Managing computer file system using file system trees
US8332827B2 (en) * 2006-12-01 2012-12-11 Murex S.A.S. Produce graph oriented programming framework with scenario support
US8584045B2 (en) 2007-01-19 2013-11-12 Sap Ag Systems and methods for navigating, finding, and presenting data objects
US7765241B2 (en) * 2007-04-20 2010-07-27 Microsoft Corporation Describing expected entity relationships in a model
US8738669B1 (en) 2007-10-08 2014-05-27 Emc Corporation Method and apparatus for providing access to data objects within another data object
US20090259683A1 (en) 2008-04-14 2009-10-15 Fiberlink Communications Corporation System and method for business object modeling
US8271935B2 (en) 2008-07-09 2012-09-18 International Business Machines Corporation Methods and tools for data-driven application engineering
CN101515290B (zh) * 2009-03-25 2011-08-31 中国工商银行股份有限公司 具有双向互动特征的元数据管理系统及其实现方法
US8260824B2 (en) 2009-05-05 2012-09-04 Rocket Software, Inc. Object-relational based data access for nested relational and hierarchical databases
US8725767B1 (en) 2010-03-31 2014-05-13 Emc Corporation Multi-dimensional object model for storage management
US8874619B2 (en) * 2011-06-03 2014-10-28 Robert Mack Method and apparatus for defining common entity relationships
US9075616B2 (en) * 2012-03-19 2015-07-07 Enterpriseweb Llc Declarative software application meta-model and system for self-modification
US20140025650A1 (en) * 2012-07-18 2014-01-23 Microsoft Corporation Abstract relational model for transforming data into consumable content
US9065746B2 (en) * 2012-08-24 2015-06-23 Vce Company, Llc Compliance testing engine for integrated computing system
DE102013108309A1 (de) * 2013-08-01 2015-02-05 OMS Software GMBH Verfahren zum Konnektieren von Objekten in einer Softwareanwendung
US9756131B2 (en) * 2013-10-01 2017-09-05 Verizon Deutschland Gmbh Label for use in the internet of things
CN103714129B (zh) * 2013-12-12 2016-09-14 用友网络科技股份有限公司 基于条件规则的动态数据结构和关系的构建装置和构建方法

Also Published As

Publication number Publication date
US11567911B2 (en) 2023-01-31
RU2017125210A3 (ru) 2019-01-28
RU2693682C2 (ru) 2019-07-03
RU2017125210A (ru) 2019-01-21
CN107111490A (zh) 2017-08-29
US20170344585A1 (en) 2017-11-30

Similar Documents

Publication Publication Date Title
Torres et al. Twenty years of object-relational mapping: A survey on patterns, solutions, and their implications on application design
US9384182B2 (en) Systems, methods and machine readable mediums for defining and executing new commands in a spreadsheet software application
US8352478B2 (en) Master data framework
Riehle et al. Dynamic object model
US20040167862A1 (en) Method and apparatus for mediated cooperation
US8527532B2 (en) Transforming function calls for interaction with hierarchical data structures
WO2014001568A2 (en) Method and apparatus for realizing a dynamically typed file or object system enabling a user to perform calculations over the fields associated with the files or objects in the system
JPH10505693A (ja) 異種オブジェクトシステム相互間にインタオペラビリティを提供するシステム及び方法
US9043757B2 (en) Identifying differences between source codes of different versions of a software when each source code is organized using incorporated files
US20110225599A1 (en) Observing properties associated with an object in an object-oriented programming platform
Groote et al. Modelling and analysing software in mCRL2
US6748388B1 (en) Method and mechanism for storing and managing self-descriptive heterogeneous data
De Porre et al. CScript: A distributed programming language for building mixed-consistency applications
Nguyen et al. A generalized object model
RU2693682C2 (ru) Система и способ управления функционально связанными данными
JP2011514596A (ja) 公称的に互換性のない型を効率的に相関させること
CN114461181A (zh) 兼容多种数据库的方法及装置
US20130166722A1 (en) Handling incidents related to business processes
CN110647535B (zh) 一种将业务数据更新至Hive的方法、终端及存储介质
US20160171367A1 (en) Representing a system using viewpoints
Fegaras et al. The ADABTPL type system
US11847134B2 (en) Computerized system for programmatic mapping of record lineage based on data flow through data storage components
US10768912B1 (en) Platform class creation
Castro et al. Logicobjects: a linguistic symbiosis approach to bring the declarative power of prolog to java
Hýbl Data Lineage Analysis of Frameworks with Complex Interaction Patterns

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14908515

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 15536733

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017125210

Country of ref document: RU

Kind code of ref document: A

122 Ep: pct application non-entry in european phase

Ref document number: 14908515

Country of ref document: EP

Kind code of ref document: A2