Модели данных: организация, структура и применение.

Введение

Модель, организующая элементы данных и взаимосвязи между ними, а также их связь с объектами реального мира. Модель данных – это абстрактная модель, которая организует элементы данных и стандартизирует их взаимосвязи, а также связь с характеристиками объектов реального мира. Например, модель данных может определять, что элемент данных, представляющий автомобиль, состоит из ряда других элементов, которые, в свою очередь, представляют цвет и размер автомобиля и определяют его владельца. Соответствующая профессиональная деятельность обычно называется моделированием данных или, более конкретно, проектированием баз данных. Модели данных обычно разрабатываются экспертом по данным, специалистом по данным, аналитиком данных, библиотекарем данных или исследователем данных. Язык и нотация моделирования данных часто представляются в графической форме в виде диаграмм. Модель данных иногда называют структурой данных, особенно в контексте языков программирования. Модели данных часто дополняются функциональными моделями, особенно в контексте корпоративных моделей. Модель данных явно определяет структуру данных; следовательно, структурированные данные – это данные, организованные в соответствии с явной моделью данных или структурой данных. Структурированные данные противопоставляются неструктурированным и частично структурированным данным.

Обзор

Термин "модель данных" может относиться к двум различным, но тесно связанным понятиям. Иногда под ним подразумевают абстрактную формализацию объектов и связей, встречающихся в конкретной предметной области, например, клиентов, продукты и заказы в производственной организации. В других случаях это относится к набору концепций, используемых для определения таких формализаций, например, к таким понятиям, как сущности, атрибуты, отношения или таблицы. Таким образом, "модель данных" банковского приложения может быть определена с использованием модели данных "сущность-связь". В данной статье термин используется в обоих значениях. Управление большими объемами структурированных и неструктурированных данных является одной из основных функций информационных систем. Модели данных описывают структуру, обработку и аспекты целостности данных, хранящихся в системах управления данными, таких как реляционные базы данных. Они также могут описывать данные с менее строгой структурой, такие как текстовые документы, электронные письма, изображения, цифровое аудио и видео: например, XDM предоставляет модель данных для XML-документов.

Роль моделей данных

Основная цель моделей данных – поддержка разработки информационных систем путем предоставления определения и формата данных. Согласно West и Fowler (1999), «если это выполняется последовательно в разных системах, то можно достичь совместимости данных. Если для хранения и доступа к данным используются одни и те же структуры данных, то различные приложения могут обмениваться данными. Результаты этого указаны выше. Однако системы и интерфейсы часто обходятся дороже, чем следовало бы, в плане создания, эксплуатации и обслуживания. Они также могут ограничивать бизнес, а не поддерживать его. Основная причина заключается в низком качестве моделей данных, реализованных в системах и интерфейсах». Концептуальная модель данных: описывает семантику предметной области, определяя область действия модели. Например, это может быть модель области интересов организации или отрасли. Она состоит из классов сущностей, представляющих различные значимые объекты в предметной области, и утверждений об отношениях между парами классов сущностей. Концептуальная схема определяет типы фактов или утверждений, которые можно выразить с помощью модели. В этом смысле она определяет допустимые выражения на искусственном «языке» с областью действия, ограниченной областью действия модели. Логическая модель данных: описывает семантику, представленную конкретной технологией обработки данных. Она включает в себя описания таблиц и столбцов, объектно-ориентированных классов и XML-тегов, среди прочего. Физическая модель данных: описывает физические средства, используемые для хранения данных. Она касается разделов, процессоров, табличных пространств и т. п. По мнению ANSI, значимость этого подхода заключается в том, что он позволяет трем перспективам быть относительно независимыми друг от друга. Технология хранения может быть изменена без влияния на логическую или концептуальную модель. Структура таблиц/столбцов может быть изменена без (необходимого) влияния на концептуальную модель. В каждом случае структуры, конечно, должны оставаться согласованными с другой моделью. Структура таблиц/столбцов может отличаться от прямого отображения классов и атрибутов сущностей, но в конечном итоге должна выполнять цели концептуальной структуры классов сущностей. На ранних этапах многих проектов разработки программного обеспечения особое внимание уделяется проектированию концептуальной модели данных. Такой проект может быть детализирован в логическую модель данных. На более поздних этапах эта модель может быть преобразована в физическую модель данных. Однако также возможно непосредственная реализация концептуальной модели.

The main aim of data models is to support the development of information systems by providing the definition and format of data. According to West and Fowler (1999) "if this is done consistently across systems then compatibility of data can be achieved. If the same data structures are used to store and access data then different applications can share data. The results of this are indicated above. However, systems and interfaces often cost more than they should, to build, operate, and maintain. They may also constrain the business rather than support it. A major cause is that the quality of the data models implemented in systems and interfaces is poor". Conceptual data model: describes the semantics of a domain, being the scope of the model. For example, it may be a model of the interest area of an organization or industry. This consists of entity classes, representing kinds of things of significance in the domain, and relationship assertions about associations between pairs of entity classes. A conceptual schema specifies the kinds of facts or propositions that can be expressed using the model. In that sense, it defines the allowed expressions in an artificial 'language' with a scope that is limited by the scope of the model. Logical data model: describes the semantics, as represented by a particular data manipulation technology. This consists of descriptions of tables and columns, object oriented classes, and XML tags, among other things. Physical data model: describes the physical means by which data are stored. This is concerned with partitions, CPUs, tablespaces, and the like. The significance of this approach, according to ANSI, is that it allows the three perspectives to be relatively independent of each other. Storage technology can change without affecting either the logical or the conceptual model. The table/column structure can change without (necessarily) affecting the conceptual model. In each case, of course, the structures must remain consistent with the other model. The table/column structure may be different from a direct translation of the entity classes and attributes, but it must ultimately carry out the objectives of the conceptual entity class structure. Early phases of many software development projects emphasize the design of a conceptual data model. Such a design can be detailed into a logical data model. In later stages, this model may be translated into physical data model. However, it is also possible to implement a conceptual model directly.

История

Одной из самых ранних пионерских работ в области моделирования информационных систем были работы Янга и Кента (1958), которые отстаивали "точный и абстрактный способ спецификации информационных и временных характеристик задачи обработки данных". Они стремились создать "нотацию, которая позволила бы аналитику организовать задачу вокруг любого аппаратного обеспечения". Их работа стала первой попыткой создать абстрактную спецификацию и инвариантную основу для проектирования различных альтернативных реализаций с использованием различных аппаратных компонентов. Следующим шагом в моделировании ИС стало участие CODASYL, консорциума ИТ-индустрии, образованного в 1959 году, который преследовал ту же цель, что и Янг и Кент: разработку "надлежащей структуры для языка определения задач, независимого от машин, на системном уровне обработки данных". Это привело к разработке специфической информационной алгебры ИС. К концу 1960-х годов Эдгар Ф. Кодд разработал свои теории организации данных и предложил реляционную модель управления базами данных, основанную на логике предикатов первого порядка. В 1970-х годах появилось моделирование "сущность-связь" как новый тип концептуального моделирования данных, впервые формализованный Питером Ченом в 1976 году. Модели сущность-связь использовались на первом этапе проектирования информационных систем в процессе анализа требований для описания информационных потребностей или типа информации, которая должна храниться в базе данных. Этот метод может описывать любую онтологию, то есть обзор и классификацию понятий и их взаимосвязей для определенной области интересов. В 1970-х годах Г. М. Нийссен разработал метод "Анализ информации на естественном языке" (NIAM), а в 1980-х годах, в сотрудничестве с Терри Халпином, развил его в объектно-ролевое моделирование (ORM). Однако именно докторская диссертация Терри Халпина 1989 года заложила формальную основу, на которой базируется объектно-ролевое моделирование. В своей книге "Данные и реальность" (1978) Билл Кент сравнил модель данных с картой территории, подчеркнув, что в реальном мире "автомагистрали не окрашены в красный цвет, реки не имеют границ округов посередине, и на горах нельзя увидеть линии уровня". В отличие от других исследователей, стремившихся создать математически чистые и элегантные модели, Кент подчеркивал присущую реальному миру беспорядочность и задачу моделировщика данных – создать порядок из хаоса, не искажая при этом истину. В 1980-х годах, по словам Яна Л. Харрингтона (2000), "развитие объектно-ориентированной парадигмы привело к фундаментальному изменению в нашем взгляде на данные и процедуры, которые с ними работают. Традиционно данные и процедуры хранились отдельно: данные и их связи в базе данных, процедуры – в прикладной программе. Однако объектная ориентация объединила процедуру сущности с ее данными". В начале 1990-х годов три голландских математика – Гидо Бакема, Харм ван дер Лек и ЯнПитер Зварт – продолжили развитие работы Г. М. Нийссена, уделяя больше внимания коммуникационному аспекту семантики. В 1997 году они формализовали метод полностью коммуникационно-ориентированного информационного моделирования (FCO IM).

One of the earliest pioneering works in modeling information systems was done by Young and Kent (1958), who argued for "a precise and abstract way of specifying the informational and time characteristics of a data processing problem". They wanted to create "a notation that should enable the analyst to organize the problem around any piece of hardware". Their work was the first effort to create an abstract specification and invariant basis for designing different alternative implementations using different hardware components. The next step in IS modeling was taken by CODASYL, an IT industry consortium formed in 1959, who essentially aimed at the same thing as Young and Kent: the development of "a proper structure for machine independent problem definition language, at the system level of data processing". This led to the development of a specific IS information algebra. Towards the end of the 1960s, Edgar F. Codd worked out his theories of data arrangement, and proposed the relational model for database management based on first order predicate logic. In the 1970s entity–relationship modeling emerged as a new type of conceptual data modeling, originally formalized in 1976 by Peter Chen. Entity–relationship models were being used in the first stage of information system design during the requirements analysis to describe information needs or the type of information that is to be stored in a database. This technique can describe any ontology, i. e., an overview and classification of concepts and their relationships, for a certain area of interest. In the 1970s G. M. Nijssen developed "Natural Language Information Analysis Method" (NIAM) method, and developed this in the 1980s in cooperation with Terry Halpin into Object–Role Modeling (ORM). However, it was Terry Halpin's 1989 PhD thesis that created the formal foundation on which Object–Role Modeling is based. Bill Kent, in his 1978 book Data and Reality, compared a data model to a map of a territory, emphasizing that in the real world, "highways are not painted red, rivers don't have county lines running down the middle, and you can't see contour lines on a mountain". In contrast to other researchers who tried to create models that were mathematically clean and elegant, Kent emphasized the essential messiness of the real world, and the task of the data modeler to create order out of chaos without excessively distorting the truth. In the 1980s, according to Jan L. Harrington (2000), "the development of the object oriented paradigm brought about a fundamental change in the way we look at data and the procedures that operate on data. Traditionally, data and procedures have been stored separately: the data and their relationship in a database, the procedures in an application program. Object orientation, however, combined an entity's procedure with its data." During the early 1990s, three Dutch mathematicians Guido Bakema, Harm van der Lek, and JanPieter Zwart, continued the development on the work of G. M. Nijssen. They focused more on the communication part of the semantics. In 1997 they formalized the method Fully Communication Oriented Information Modeling FCO IM.

Диаграмма структуры данных

Диаграмма структуры данных (DSD) — это диаграмма и модель данных, используемые для описания концептуальных моделей данных посредством графических обозначений, документирующих сущности и их взаимосвязи, а также ограничения, которые их связывают. Основными графическими элементами DSD являются блоки, представляющие сущности, и стрелки, представляющие взаимосвязи. Диаграммы структуры данных наиболее полезны для документирования сложных сущностей данных. Диаграммы структуры данных являются расширением модели «сущность-связь» (ER-модели). В DSD атрибуты указываются внутри блоков сущностей, а не снаружи, в то время как взаимосвязи изображаются в виде блоков, состоящих из атрибутов, определяющих ограничения, связывающие сущности. DSD отличаются от ER-модели тем, что ER-модель фокусируется на взаимосвязях между различными сущностями, в то время как DSD фокусируется на взаимосвязях элементов внутри сущности и позволяет пользователям полностью видеть связи и взаимосвязи между каждой сущностью. Существует несколько стилей представления диаграмм структуры данных, основное различие между которыми заключается в способе определения кратности. Выбор делается между стрелками, перевернутыми стрелками (лапками ворона) или числовым представлением кратности.

Модель отношений между субъектами

Модель «сущность-связь» (ERM), иногда называемая диаграммой «сущность-связь» (ERD), может использоваться для представления абстрактной концептуальной модели данных (или семантической модели данных, или физической модели данных), применяемой в разработке программного обеспечения для представления структурированных данных. Существует несколько нотаций, используемых для ERM. Как и в DSD, атрибуты указываются внутри блоков сущностей, а не снаружи, а связи изображаются в виде линий, с ограничениями связи, представленными в виде описаний на этих линиях. Модель ER, хотя и надёжна, может стать визуально сложной при представлении сущностей с большим количеством атрибутов. Существует несколько стилей для представления диаграмм структуры данных, с заметным различием в способе определения кратности. Выбор заключается в использовании стрелок, перевёрнутых стрелок (так называемых «вороньих лапок») или числового представления кратности.

Диаграмма потока данных

Диаграмма потока данных (DFD) — это графическое представление «потока» данных в информационной системе. Она отличается от блок-схемы тем, что отображает поток данных, а не поток управления программой. Диаграмма потока данных также может использоваться для визуализации обработки данных (структурное проектирование). Диаграммы потока данных были изобретены Ларри Константином, первоначальным разработчиком структурного проектирования, на основе модели вычислений «граф потока данных» Мартина и Эстрина. Распространенной практикой является сначала создание диаграммы потока данных уровня контекста, которая показывает взаимодействие системы с внешними сущностями. DFD предназначена для демонстрации того, как система разделена на более мелкие части и для выделения потока данных между ними. Эта диаграмма потока данных уровня контекста затем детализируется, чтобы показать больше подробностей моделируемой системы.

Информационная модель

Информационная модель – это не тип модели данных, а скорее альтернативный подход к моделированию. В области разработки программного обеспечения как модель данных, так и информационная модель могут представлять собой абстрактные, формальные представления типов сущностей, включающие их свойства, взаимосвязи и операции, которые над ними могут выполняться. Типы сущностей в модели могут соответствовать реальным объектам, таким как устройства в сети, либо сами быть абстрактными, например, сущности, используемые в системе расчетов. Как правило, они применяются для моделирования ограниченной предметной области, которую можно описать конечным набором типов сущностей, свойств, взаимосвязей и операций. Согласно Ли (1999), в более широком смысле термин "информационная модель" используется для моделей отдельных объектов, таких как сооружения, здания, промышленные предприятия и т.п. В этих случаях концепция конкретизируется до информационной модели сооружения, информационной модели здания, информационной модели предприятия и т.д. Такая информационная модель представляет собой объединение модели объекта с данными и документацией об этом объекте. Информационная модель обеспечивает формализацию описания предметной области, не ограничивая способ сопоставления этого описания с конкретной программной реализацией. Для информационной модели может существовать множество сопоставлений, называемых моделями данных, независимо от того, являются ли они объектными моделями (например, с использованием UML), моделями "сущность-связь" или XML-схемами.

Модель объекта

Объектная модель в информатике — это совокупность объектов или классов, посредством которых программа может исследовать и манипулировать определенными частями своей среды. Иными словами, это объектно-ориентированный интерфейс к некоторому сервису или системе. Такой интерфейс именуется объектной моделью представляемого сервиса или системы. Например, Document Object Model (DOM) — это совокупность объектов, представляющих страницу в веб-браузере, используемая скриптовыми программами для изучения и динамического изменения этой страницы. Существует объектная модель Microsoft Excel для управления Microsoft Excel из другой программы, а ASCOM Telescope Driver — это объектная модель для управления астрономическим телескопом. В вычислительной технике термин «объектная модель» имеет и второе значение, обозначающее общие характеристики объектов в конкретном языке программирования, технологии, нотации или методологии, использующих их. Например, объектная модель Java, объектная модель COM или объектная модель OMT. Такие объектные модели обычно определяются с использованием понятий, таких как класс, сообщение, наследование, полиморфизм и инкапсуляция. Существует обширная литература, посвященная формализованным объектным моделям как подмножеству формальной семантики языков программирования.

Моделирование объектов и ролей

Объектно-ролевое моделирование (ORM) — это метод концептуального моделирования, который можно использовать как инструмент для анализа информации и правил. Объектно-ролевое моделирование – это метод, ориентированный на факты, для проведения системного анализа на концептуальном уровне. Качество приложения базы данных критически зависит от её проектирования. Чтобы обеспечить корректность, ясность, адаптивность и эффективность, информационные системы лучше всего сначала специфицировать на концептуальном уровне, используя понятия и язык, которые люди могут легко понять. Концептуальное проектирование может включать в себя перспективы данных, процессов и поведения, а фактическая СУБД, используемая для реализации проекта, может основываться на одной из множества логических моделей данных (реляционной, иерархической, сетевой, объектно-ориентированной и т.д.).