Сущность-связь модели: Описание взаимосвязанных данных

Введение

Модель или диаграмма, описывающая взаимосвязанные объекты.

Модель «сущность-связь» (или ER-модель) описывает взаимосвязанные объекты, представляющие интерес в конкретной области знаний. Базовая ER-модель состоит из типов сущностей (которые классифицируют интересующие объекты) и определяет связи, которые могут существовать между сущностями (экземплярами этих типов сущностей). В разработке программного обеспечения ER-модель обычно создается для представления информации, которую бизнесу необходимо хранить для выполнения бизнес-процессов. Следовательно, ER-модель становится абстрактной моделью данных, определяющей структуру данных или информации, которую можно реализовать в базе данных, как правило, реляционной. Моделирование «сущность-связь» было разработано для баз данных и проектирования Питером Ченом и опубликовано в 1976 году, хотя варианты этой идеи существовали и ранее. Сегодня оно широко используется для обучения студентов основам структуры баз данных. Некоторые ER-модели отображают супертипы и подтипы сущностей, связанные отношениями обобщения и специализации, а ER-модель также может использоваться для определения доменно-специфических онтологий.

Введение

Модель ER обычно является результатом систематического анализа для определения и описания данных, создаваемых и необходимых процессами в определенной бизнес-области. Как правило, она представляет собой записи о сущностях и событиях, отслеживаемых и управляемых бизнес-процессами, а не сами процессы. Обычно модель изображается в графической форме в виде блоков (сущностей), соединенных линиями (связями), выражающими ассоциации и зависимости между сущностями. Модель также может быть выражена в вербальной форме, например: одно здание может быть разделено на ноль или более квартир, но одна квартира может находиться только в одном здании. Сущности могут определяться не только связями, но и дополнительными свойствами (атрибутами), включающими идентификаторы, называемые "первичными ключами". Диаграммы, отображающие атрибуты, а также сущности и связи, могут называться диаграммами "сущность-атрибут-связь", а не моделями "сущность-связь". Модель ER обычно реализуется в виде базы данных. В простой реляционной базе данных каждая строка таблицы представляет один экземпляр типа сущности, а каждое поле в таблице представляет тип атрибута. В реляционной базе данных связь между сущностями реализуется путем хранения первичного ключа одной сущности в качестве указателя или "внешнего ключа" в таблице другой сущности. Существует традиция построения ER/моделей данных на двух или трех уровнях абстракции. Иерархия "концептуальный-логический-физический", используемая ниже, применяется и в других видах спецификаций и отличается от трехзвенного подхода к разработке программного обеспечения. Концептуальная модель данных Это модель ER наивысшего уровня, поскольку она содержит минимальный уровень детализации, но определяет общий объем данных, которые должны быть включены в набор моделей. Концептуальная модель ER обычно определяет основные справочные данные, которые обычно используются в организации. Разработка общекорпоративной концептуальной модели ER полезна для документирования архитектуры данных организации. Концептуальная модель ER может служить основой для одной или нескольких логических моделей данных (см. ниже). Цель концептуальной модели ER – установить общие структурные метаданные для основных данных между набором логических моделей ER. Концептуальная модель данных может использоваться для установления общих связей между моделями ER в качестве основы для интеграции моделей данных. Логическая модель данных Логическая модель ER не обязательно требует концептуальной модели ER, особенно если область применения логической модели ER ограничивается разработкой отдельной информационной системы. Логическая модель ER содержит больше деталей, чем концептуальная модель ER. В дополнение к основным данным определяются операционные и транзакционные данные. Детализируются данные по каждой сущности и устанавливаются связи между этими данными. Однако логическая модель ER разрабатывается независимо от конкретной системы управления базами данных (СУБД), в которой она может быть реализована. Физическая модель данных На основе каждой логической модели ER может быть разработана одна или несколько физических моделей ER. Физическая модель ER обычно разрабатывается для реализации в виде базы данных. Следовательно, каждая физическая модель ER должна содержать достаточно деталей для создания базы данных, и каждая физическая модель ER зависит от используемой технологии, поскольку каждая СУБД имеет свои особенности. Физическая модель обычно реализуется в структурных метаданных СУБД в виде объектов реляционной базы данных, таких как таблицы базы данных, индексы базы данных (например, индексы уникальных ключей) и ограничения базы данных (например, ограничение внешнего ключа или ограничение целостности). Модель ER также обычно используется для проектирования изменений в объектах реляционной базы данных и для поддержания структурных метаданных базы данных. На первом этапе проектирования информационной системы эти модели используются в ходе анализа требований для описания информационных потребностей или типа информации, которая должна храниться в базе данных. Метод моделирования данных может быть использован для описания любой онтологии (т.е. обзора и классификации используемых терминов и их взаимосвязей) для определенной области интересов. В случае проектирования информационной системы, основанной на базе данных, концептуальная модель данных на более позднем этапе (обычно называемом логическим проектированием) отображается в логическую модель данных, такую как реляционная модель. В свою очередь, она отображается в физическую модель во время физического проектирования. Иногда оба этих этапа называют "физическим проектированием".

An ER model usually results from systematic analysis to define and describe the data created and needed by processes in a business area. Typically, it represents records of entities and events monitored and directed by business processes, rather than the processes themselves. It is usually drawn in a graphical form as boxes (entities) that are connected by lines (relationships) which express the associations and dependencies between entities. It can also be expressed in a verbal form, for example: one building may be divided into zero or more apartments, but one apartment can only be located in one building. Entities may be defined not only by relationships, but also by additional properties (attributes), which include identifiers called "primary keys". Diagrams created to represent attributes as well as entities and relationships may be called entity attribute relationship diagrams, rather than entity–relationship models. An ER model is typically implemented as a database. In a simple relational database implementation, each row of a table represents one instance of an entity type, and each field in a table represents an attribute type. In a relational database a relationship between entities is implemented by storing the primary key of one entity as a pointer or "foreign key" in the table of another entity. There is a tradition for ER/data models to be built at two or three levels of abstraction. The conceptual logical physical hierarchy below is used in other kinds of specification, and is different from the three schema approach to software engineering. Conceptual data model
This is the highest level ER model in that it contains the least granular detail but establishes the overall scope of what is to be included within the model set. The conceptual ER model normally defines master reference data entities that are commonly used by the organization. Developing an enterprise wide conceptual ER model is useful to support documenting the data architecture for an organization. A conceptual ER model may be used as the foundation for one or more logical data models (see below). The purpose of the conceptual ER model is then to establish structural metadata commonality for the master data entities between the set of logical ER models. The conceptual data model may be used to form commonality relationships between ER models as a basis for data model integration. Logical data model
A logical ER model does not require a conceptual ER model, especially if the scope of the logical ER model includes only the development of a distinct information system. The logical ER model contains more detail than the conceptual ER model. In addition to master data entities, operational and transactional data entities are now defined. The details of each data entity are developed and the relationships between these data entities are established. The logical ER model is however developed independently of the specific database management system into which it can be implemented. Physical data model
One or more physical ER models may be developed from each logical ER model. The physical ER model is normally developed to be instantiated as a database. Therefore, each physical ER model must contain enough detail to produce a database and each physical ER model is technology dependent since each database management system is somewhat different. The physical model is normally instantiated in the structural metadata of a database management system as relational database objects such as database tables, database indexes such as unique key indexes, and database constraints such as a foreign key constraint or a commonality constraint. The ER model is also normally used to design modifications to the relational database objects and to maintain the structural metadata of the database. The first stage of information system design uses these models during the requirements analysis to describe information needs or the type of information that is to be stored in a database. The data modeling technique can be used to describe any ontology (i. e. an overview and classifications of used terms and their relationships) for a certain area of interest. In the case of the design of an information system that is based on a database, the conceptual data model is, at a later stage (usually called logical design), mapped to a logical data model, such as the relational model. This in turn is mapped to a physical model during physical design. Sometimes, both of these phases are referred to as "physical design."

Отношения, роли и основные функции

Оригинальная статья Чэна приводит пример отношения и его ролей. Он описывает отношение "брак" и две его роли: "муж" и "жена". Один человек выполняет роль мужа в браке (отношении), а другой – роль жены в этом (том же) браке. Эти слова являются существительными. Терминология Чэна также применялась к более ранним концепциям. Линии, стрелки и "вороньи лапки" некоторых диаграмм больше обязаны более ранним диаграммам Бахмана, чем диаграммам отношений Чэна. Другое распространенное расширение модели Чэна – присвоение отношений и ролей названий в виде глаголов или фраз.

Название роли

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

Проблемы с использованием модели

Пользователи моделируемой базы данных могут столкнуться с двумя хорошо известными проблемами, при которых возвращенные результаты означают не то, что предполагал автор запроса. Первая – это "ловушка веера". Она возникает с (главной) таблицей, которая связана с несколькими таблицами в отношении один ко многим. Проблема получила свое название из-за того, как выглядит модель при отображении на диаграмме "сущность-связь": связанные таблицы "расходятся веером" от главной таблицы. Этот тип модели похож на звездную схему, используемую в хранилищах данных. При попытке вычисления сумм агрегатов с использованием стандартного SQL по главной таблице могут возникать неожиданные (и неверные) результаты. Решение состоит в корректировке либо модели, либо SQL-запроса. Эта проблема чаще всего встречается в базах данных систем поддержки принятия решений, и программное обеспечение, обращающееся к таким системам, иногда включает специальные методы для ее решения. Вторая проблема – "ловушка пропасти". Ловушка пропасти возникает, когда модель предполагает наличие связи между типами сущностей, но пути между определенными экземплярами сущностей не существует. Например, здание имеет одну или несколько комнат, в которых находится ноль или более компьютеров. Можно ожидать, что при запросе модели будут показаны все компьютеры в здании. Однако компьютеры, которые в данный момент не назначены ни одной комнате (например, находятся на ремонте или в другом месте), не будут включены в список. Для учета всех компьютеров в здании требуется дополнительная связь между зданием и компьютерами. Эта последняя проблема моделирования возникает из-за того, что в модели не удалось отразить все связи, существующие в реальном мире. Подробности см. в разделе 2 "Моделирование взаимосвязей между сущностями".

Семантическая модель

Семантическая модель — это модель концепций, иногда называемая "моделью, не зависящей от платформы". Это интенсиональная модель. По крайней мере, со времен Карнапа, хорошо известно, что: "Полное значение понятия состоит из двух аспектов – интенсиональности и экстенсиональности. Первая часть охватывает включение понятия в мир концепций в целом, то есть совокупность всех его отношений с другими понятиями. Вторая часть определяет референциальное значение понятия, то есть его соответствие в реальном или возможном мире".

Модель расширения

Экстенсионная модель – это модель, которая отображается на элементы конкретной методологии или технологии и, следовательно, является "моделью, специфичной для платформы". Спецификация UML явно указывает, что ассоциации в классовых моделях являются экстенсионными, и это очевидно, если учитывать обширный набор дополнительных "декоративных элементов", предоставляемых спецификацией сверх тех, что предоставляются любыми из предшествующих "языков семантического моделирования". "UML как обозначение моделирования данных, часть 2"

Философское выравнивание

Чен придерживается философских традиций, восходящих ко временам древнегреческих философов: Платона и Аристотеля. Сам Платон отождествляет знание с постижением неизменных Идей (то есть архетипов или абстрактных представлений о различных типах вещей и их свойствах) и связей между ними.